2017-04-01 00:00:08 TemptorSent: that is a maintainer script problem 2017-04-01 00:00:23 kaniini: So catching that what was previously defaulted no longer exists would be very useful. 2017-04-01 00:00:46 why God, why me? 2017-04-01 00:00:57 kaniini I'm sorry. 2017-04-01 00:01:02 i'm going to go install TempleOS now 2017-04-01 00:01:03 I'll leave you in peace. 2017-04-01 00:01:12 God and I need to have a chat 2017-04-01 00:01:20 *LOL* 2017-04-01 00:02:11 TemptorSent: i agree that having some sort of trigger to archive previous configuration versions would be desirable 2017-04-01 00:02:12 What you are doing is good, no matter what else. 2017-04-01 00:02:30 kaniini: Problem solved. 2017-04-01 00:02:31 but we need to worry about minimum viable product before we worry about that 2017-04-01 00:03:13 kaniini: As long as you don't go out of your way to make it impossible, I don't see it being much of a hassle at all to be honest. 2017-04-01 00:03:46 http://www.templeos.org/Wb/Home/Web/AppStore/AppStore.html#l1 2017-04-01 00:03:51 it has an App Store 2017-04-01 00:03:56 what more do I need? 2017-04-01 00:04:06 kaniini: Filesystems are good -- they can be subverted to just about anything without too much pain :) 2017-04-01 00:04:19 Kinda like a religion, right? 2017-04-01 00:04:29 ;) 2017-04-01 00:05:25 TemptorSent: he has a hitbox account 2017-04-01 00:05:38 TemptorSent: he spends his entire day coding TempleOS and reading The Drudge Report 2017-04-01 00:06:14 TemptorSent: he does it all from Ubuntu too 2017-04-01 00:06:20 it is quite strange 2017-04-01 00:08:12 TemptorSent: my thing is this 2017-04-01 00:09:28 TemptorSent: shipping something that is 80% of the way there is more valuable than spending time worrying about the remaining 20% 2017-04-01 00:09:43 if i took that approach to things i do, i would never get anything done 2017-04-01 00:11:41 kaniini: Understood, I tend to look a couple steps ahead because that's my background. 2017-04-01 00:12:42 kaniini: I usually have to deal with full-lifecycle support myself, so I plan ahead accordingly. 2017-04-01 00:14:26 kaniini: Different worlds, different balance. 2017-04-01 00:28:11 well for us mere mortals we need to start from a minimum viable product 2017-04-01 00:33:29 TemptorSent: but your input has been quite valuable 2017-04-01 00:40:05 kaniini: Usually I deal with products I can't fix once they go out except where I already planned a mechanism, so I don't have much choice but think ahead. 2017-04-01 00:40:38 (Because firmware doesn't update by itself :) ) 2017-04-01 00:42:12 So I try to design so I'm confident that anything I missed is contstrained and can be patched without breaking the rest. 2017-04-01 00:42:39 Which is part of why CM is such a big deal for me. 2017-04-01 00:43:51 And why I'm almost tempted by Erlang... 2017-04-01 00:44:21 (But then I look at the code base!) 2017-04-01 03:56:29 ok 2017-04-01 03:56:29 ok 2017-04-01 03:56:46 TemptorSent: i installed TempleOS 2017-04-01 03:56:54 TemptorSent: have had some chats with God 2017-04-01 04:02:42 TemptorSent: i decided aconf needs to be written in HolyC instead of just C 2017-04-01 04:03:01 TemptorSent: its okay i will include a translator with the source package 2017-04-01 04:05:57 unfortunately God told me systemd is how he intended it to be 2017-04-01 04:06:19 okay i cant continue with this, it is just too ridiculous 2017-04-01 04:06:45 TemptorSent: in all seriousness, do you think using directories to define an entire sub-tree of defaults makes sense? 2017-04-01 04:07:19 TemptorSent: so setup-disk/default/partition0/filesystem = ext4, etc 2017-04-01 05:12:56 trying to rebuild openjdk8 now to see if that fixes it 2017-04-01 07:14:27 kaniini: Just got home from running to the city to get groceries. Did God give you a mandate to cleanse systemd of it's evil before anointing it? 2017-04-01 07:14:37 kaniini :) 2017-04-01 07:15:03 no 2017-04-01 07:15:40 But realistically, I'm not sure quite how to handle some of the options in a sensical manner. 2017-04-01 07:17:34 So if I have /dev/sda2 to be given UUID=12345-67890, have a filesystem of xfs, have a size of 4TB, have a set of mount opts, and be mounted at /var, how do we represent that cleanly? 2017-04-01 07:18:11 That's the kind of case I see needing multiple keys as a real possibility. 2017-04-01 07:19:29 Now, once you start layering things, it gets even more confusing trying to have it in a directory hierarchy without some sort of consistent reference. 2017-04-01 07:20:30 So which order would you specify a luks encrypted raid 6 with ext4 on lvms? 2017-04-01 07:21:00 And how do you name things so they're discoverable. 2017-04-01 07:21:35 Those are this issues I see needing to be addressed to support the intended functions. 2017-04-01 07:22:26 Nothing insurmountable, just need to figure out a scheme and use it consistently. 2017-04-01 07:24:00 But while you've got him on the line at the Temple, ask God his opinion :) 2017-04-01 07:24:21 i honestly don't cause it wont boot 2017-04-01 07:24:25 which is probably for the better 2017-04-01 07:24:53 kaniini: Should we build a profile git? 2017-04-01 07:24:59 profiled* 2017-04-01 07:25:03 *lol* I'm almost tempted, but I don't have any more machines. 2017-04-01 07:25:10 $ make prefix=/usr profile-fast 2017-04-01 07:25:11 # make prefix=/usr PROFILE=BUILD install 2017-04-01 07:25:46 Alternatively you can run profile feedback only with the git benchmark suite. This runs significantly faster than the full test suite, but has less coverage: 2017-04-01 07:25:49 pickfire: It would be interesting to see where it's buring its time, I'm assuming you're talking for optimization? 2017-04-01 07:25:58 TemptorSent: Yeah. 2017-04-01 07:26:14 TemptorSent │ So if I have /dev/sda2 to be given UUID=12345-67890, have a filesystem of xfs, have a size of 4TB, have a set of mount opts, and be mounted at /var, how do we 2017-04-01 07:26:16 │ represent that cleanly? 2017-04-01 07:26:18 Or $ make prefix=/usr profile 2017-04-01 07:26:31 an /etc/fstab with alpine_* prefixed mount options that the installer will then filter out and install into the new system 2017-04-01 07:26:33 ;p 2017-04-01 07:26:35 e.g. alpine_size=4T 2017-04-01 07:26:35 > This may be a good tradeoff for distribution packagers. 2017-04-01 07:27:48 pickfire: It's been a long time since I played with profiled-optimizing, but it seemed to be effective mostly on compute bound code. I suspect git has a lot of fs slowdown that would benefit even more from some manual stracing 2017-04-01 07:28:07 i dont think there is any benefit at all to PGO for git 2017-04-01 07:28:24 that screams of lets PGO it because we can 2017-04-01 07:28:26 Shiz: Yes, but that doesn't fit kaniini's overall system. 2017-04-01 07:28:49 TemptorSent: Should we do that? 2017-04-01 07:28:59 do what 2017-04-01 07:29:03 kaniini: I can think of perhaps a couple chunks of git that would benefit (hashing/tree walking), but not so much the fs calls. 2017-04-01 07:29:07 is there a problem with git's performance ? 2017-04-01 07:29:11 it seems good enough 2017-04-01 07:29:21 kaniini: No 2017-04-01 07:29:21 It's not bad, IMHO. 2017-04-01 07:29:32 then why bother with all of this stuff 2017-04-01 07:29:34 Especially with the fat history of aports. 2017-04-01 07:29:35 if it's good enough 2017-04-01 07:29:47 It needs auto gc on every merge. 2017-04-01 07:29:52 T_T 2017-04-01 07:30:02 It might be worth benchmarking just to see if you get more than say a 5% speedup. 2017-04-01 07:30:16 But if not, don't waste the extra build time. 2017-04-01 07:30:38 What's it's time output look like? 2017-04-01 07:30:42 Even 5% is worth it, can be a whole lot faster when we need to git gc for so long. 2017-04-01 07:30:56 i do not need to git gc aports ever 2017-04-01 07:31:02 TemptorSent: Didn't check but probably half a minute? 2017-04-01 07:31:24 i've never ran git gc ever 2017-04-01 07:31:27 kaniini: Because you have fast computer. 2017-04-01 07:31:34 pickfire: No, how much time spent in each sys, user, io, block, wait/ 2017-04-01 07:31:36 Try using pi as your desktop. 2017-04-01 07:31:39 it's not that fast 2017-04-01 07:31:42 it's only a core i5 2017-04-01 07:32:00 kaniini: Compare core i5 to arm 4 core. 2017-04-01 07:32:13 About 10x faster. 2017-04-01 07:32:19 pickfire: Only way to see if there is a win is to give it a shot in a test build and run some benchmarks. 2017-04-01 07:32:28 TemptorSent: How? 2017-04-01 07:33:03 pickfire: More than 5% overall is probably worth messing with, but if it's a few percent in some relatively light code, it's not worth the effort. 2017-04-01 07:33:26 and then i am being told by guccifer 3.0 or whatever on #musl how a compiler works 2017-04-01 07:33:26 and it's like 2017-04-01 07:33:28 TemptorSent: Let me test it with git clone aports. 2017-04-01 07:33:37 On a pi 3. 2017-04-01 07:33:38 yeah i dumbed that shit down more than a technically correct description of how it works 2017-04-01 07:33:40 pickfire: Compile it stock, take a tarball of a git repo that grinds, (not a clone!) 2017-04-01 07:33:42 but 2017-04-01 07:33:52 But what? 2017-04-01 07:33:56 the point i was making had nothing to do with the compiler itself 2017-04-01 07:33:56 Then untar the tarbal to 3 directories. 2017-04-01 07:34:05 Do you want me to test it on a pi 1? 2017-04-01 07:34:15 kaniini: amonakov is a gcc dev iirc, hard to blame him 2017-04-01 07:34:17 :p 2017-04-01 07:34:36 shiz hes probably hacking hillary's emails right now as we speak 2017-04-01 07:34:43 *lol* 2017-04-01 07:34:46 haha 2017-04-01 07:35:31 pickfire: Anyway, I'd see if you can snag some low hanging fruit, either that, or break out valgrind and oprofile the syscalls (which I suspect are a lot of your burn on gc) 2017-04-01 07:35:45 this is what the US media portrays russian computer science as, how should i know 2017-04-01 07:35:50 Yeah 2017-04-01 07:36:23 pickfire: But unless there's a major pain point, I suspect git is not your best use of time for optimization. 2017-04-01 07:36:42 Obviously, fixing major pain points is good :) 2017-04-01 07:37:25 on raspberry pi i would look more at memory pressure and disk pressure still 2017-04-01 07:37:32 But try to narrow down what's causing the pain using some basic accounting and timing tools before you get into heavy lifting. 2017-04-01 07:38:20 disk io* 2017-04-01 07:38:23 Agreed kaniini -- although profiling may be helpful for fixing poor memory usage to some extent at least. 2017-04-01 07:38:28 Yes. 2017-04-01 07:38:36 But I won't look on memory. 2017-04-01 07:38:44 pickfire: disk/memory/context switching is going to be the part that hurts. 2017-04-01 07:39:18 So I don't do the profile? 2017-04-01 07:39:22 pickfire: Also, bad cache assumptions may be an issue in git, since it was designed on x86. 2017-04-01 07:39:39 I thought distributions should pack profiled packages? 2017-04-01 07:39:48 pickfire: Start with the basics before you profile it -- that will help you decide which profiling options to use. 2017-04-01 07:40:00 ? 2017-04-01 07:40:08 pickfire: Not necessarily always worth the effort. 2017-04-01 07:40:17 Oh, okay. 2017-04-01 07:40:47 pickfire: If you're io bound and it's the io scheduler that's eating you alive, fixing git isn't going to help. 2017-04-01 07:41:28 if youre i/o bound on a raspberry pi 2017-04-01 07:41:30 pickfire: So figure out which resource is getting consumed fastest and address that first. 2017-04-01 07:41:40 its probably because youre using the onboard NOR flash or you have a really shitty SD card 2017-04-01 07:41:42 tbh 2017-04-01 07:42:17 if the former, don't worry about it because you will need to replace your raspberry pi soon most likely 2017-04-01 07:42:23 if the latter, just buy a better SD card 2017-04-01 07:42:24 kaniini: Their usb bus is pretty crappy, so if you're running more than one device (wireless included) it can quickly slow down. 2017-04-01 07:42:24 What about laptop? 2017-04-01 07:42:37 I mean I still need gc on laptop as well. 2017-04-01 07:43:00 pickfire: If you have real disk controllers, your memory starts helping a lot more with caching. 2017-04-01 07:43:33 pickfire: Right, but what's the slow part? random seeks? sequential reads? cache misses? 2017-04-01 07:43:43 Not sure. 2017-04-01 07:43:48 Didn't trace it. 2017-04-01 07:44:20 pickfire: Read/modify/write cycles are notoriously bad for throughput for instance. 2017-04-01 07:44:51 pickfire: I'd start with time/top with a couple workloads just to figure out what's taking the time. 2017-04-01 07:45:03 time can do that? 2017-04-01 07:45:16 I mean time and top can't measure io. 2017-04-01 07:45:26 pickfire: Then try running some basic memory/disk/io benchmarks depending on what you get. 2017-04-01 07:45:39 pickfire they'll tell you how long it's blocked. 2017-04-01 07:45:59 TemptorSent: Nevermind, I guess need not to do it then. 2017-04-01 07:46:44 pickfire: It might be worth while if you have a high user time compared to real and sys 2017-04-01 07:47:02 What do you mean? 2017-04-01 07:47:04 or if sys is high and it's all from one syscall loop. 2017-04-01 07:47:25 time git gc and see what the times for user, sys, and real are. 2017-04-01 07:47:29 TemptorSent: I don't know what is the difference between real, sys and user time. 2017-04-01 07:47:55 if it takes 20mins real, 4 mins user, and 2 mins sys, it's probably io bound, not cpu. 2017-04-01 07:48:16 if you have high sys, it could be io or memory bound 2017-04-01 07:48:30 or it is badly written code 2017-04-01 07:48:34 typically, compute bound is a high user time with respect to wall clock. 2017-04-01 07:48:48 Ah 2017-04-01 07:48:53 for example epoll_wait(3) loop that never ACKs socket errors 2017-04-01 07:48:54 kaniini: Yes, that could be the cause.. and frequently is! 2017-04-01 07:48:57 will burn 100% cpu 2017-04-01 07:49:04 as sys 2017-04-01 07:49:32 Yeah, if sys looks way out of line, it's probably something like that ^^^ 2017-04-01 07:49:32 What about high user time? 2017-04-01 07:50:16 high user time is usually a good indication of cpu bound workloads, once you check you're not hitting the memory wall (top is good for that) 2017-04-01 07:51:06 so if you see 70% of the real time is user, profiling may be worth while. 2017-04-01 07:51:34 pickfire: It just lets you know which tree to bark up when you're looking for the problem. 2017-04-01 07:51:47 i don't like the security aspects of PGO 2017-04-01 07:51:51 the whole concept seems sketchy to me 2017-04-01 07:51:58 pickfire: high user, low sys, and generally slow often indicates bad loop usage. 2017-04-01 07:52:18 Ah 2017-04-01 07:52:30 TemptorSent: Nice, thanks a lot for telling me that. 2017-04-01 07:52:35 I learn something. 2017-04-01 07:52:41 kaniini: I spent some time auditing some profile-optimized binaries I did many years ago and they were pretty clean. 2017-04-01 07:53:18 kaniini: It basically was just generating the branch trees proability and using that to inform the optimizer. 2017-04-01 07:53:49 that part is fine, but it is not really reproducible on a builder 2017-04-01 07:53:59 i mean stuff like what JVM does 2017-04-01 07:54:24 kaniini: So it would unroll loops more agressively where profiling indicated it was spinning, re-order branch instructions to put the most frequent first, etc. 2017-04-01 07:55:00 kaniini: I haven't looked at the latest developments, but I wouldn't be surprised to see a previously usefull tool broken beyond use. 2017-04-01 07:55:55 i rather just fix the code 2017-04-01 07:55:57 kaniini: The biggest value I found in using it was identifying areas to optimize in the code paths. 2017-04-01 07:56:02 than deal with any of that 2017-04-01 07:57:03 TemptorSent, kaniini: http://ix.io/ptm 2017-04-01 07:57:08 kaniini: That's what I was using it for, profile and benchmark with a matrix of conditions, then determine which one gives the best performance in which case, and include all of the above, with a code-path optimizier in line 2017-04-01 07:57:13 On my laptop. 2017-04-01 07:57:15 i7 2017-04-01 07:57:54 ok that is great and all but it doesnt change that we cant really do a PGO build on the builders 2017-04-01 07:57:59 as it is not reproducible 2017-04-01 07:58:11 kaniini: Agreed. 2017-04-01 07:58:49 I really hope github accept shallow clone push. 2017-04-01 07:58:54 Shitty github. 2017-04-01 07:58:55 kaniini: If it could identify some places to put #pragmas in the git code to speed it up, it might be worth the effort. 2017-04-01 07:59:14 If they just accept it, I just clone --depth 10 2017-04-01 07:59:28 At 9 mings user, you'll want to do something like an iostat next 2017-04-01 07:59:34 Or even better, just submit patches to ML to avoid this. 2017-04-01 07:59:47 lol 2017-04-01 08:00:17 But that's enough to be possibly interesting if it's not showing that's all disk grind. 2017-04-01 08:00:33 TemptorSent: Might not be io bound. 2017-04-01 08:00:41 I use raid 0 ssd. 2017-04-01 08:01:07 on raspberry pi? 2017-04-01 08:01:08 pickfire; Looking at the low sys, it's not looking like it's spinning in syscalls, and the real isn't indicating blocking badly. 2017-04-01 08:01:08 ;) 2017-04-01 08:01:13 Well, 1 disk is encrypted. 2017-04-01 08:01:26 kaniini: On x220 i7 8gb ram 2017-04-01 08:02:54 oh well i am going to bed now 2017-04-01 08:02:55 goodnight 2017-04-01 08:03:02 Night. 2017-04-01 08:04:27 TemptorSent: Probably cpu bound 16319 ivan 20 0 597.2m 547.9m 388.1 6.9 2:27.03 S `- git 2017-04-01 08:04:44 disk on iostat shows 5% 2017-04-01 08:04:53 Goodnight kaniini. 2017-04-01 08:05:10 TemptorSent: What do I do for this case? 2017-04-01 08:05:16 pickfire: Okay, that might be worth profiling then. 2017-04-01 08:05:24 9 min but not 30 sec 2017-04-01 08:05:26 T_T 2017-04-01 08:05:56 pickfire: Like I said, good to eliminate as much as possible before banging your head against something more complex. 2017-04-01 08:06:40 pickfire: If I had to guess, it's probably in a copy and hashing tree loop. 2017-04-01 08:07:40 pickfire: I'm not sure how it's actually implemented in git, probably a red/black tree. 2017-04-01 08:08:00 Huh? 2017-04-01 08:08:02 What's that? 2017-04-01 08:08:21 pickfire: Basically a self-balancing binary tree 2017-04-01 08:08:30 Ah 2017-04-01 08:08:39 Haven't heard of red/black tree. 2017-04-01 08:08:56 I don't have much knowledge about self-balancing binary tree. 2017-04-01 08:09:08 pickfire: They're very common in binary search and hash trees. 2017-04-01 08:09:16 Ah 2017-04-01 08:10:29 It's just a b-tree that enforces a more or less equal branch structure on both sides 2017-04-01 08:11:05 Ah 2017-04-01 08:11:24 Basically, the way it works is by not growing any deeper on a given branch until that is the minimum branch depth. 2017-04-01 08:11:47 (actually, 1 link deeper maximum) 2017-04-01 08:13:17 So you count the number of black nodes you pass through to get to your leaf node, and only add another level once all black nodes have the same number of traversals to reach a leaf. 2017-04-01 08:13:44 Ah 2017-04-01 08:13:56 So basically to make the level stay the same. 2017-04-01 08:14:09 TemptorSent: And git gc does the rebalancing? 2017-04-01 08:14:21 So the maximum difference in longest distance is basically a 2:1 ratio 2017-04-01 08:14:48 It constrains your traversals and keeps your tree from getting lopsided. 2017-04-01 08:15:08 Ah 2017-04-01 08:15:42 TemptorSent: Can you please tell me more about using tools like time, top and iostat. 2017-04-01 08:15:45 ? 2017-04-01 08:16:25 pickfire: Nothing really astounding about them, they just give you different views into what resources are being used how (free being another) 2017-04-01 08:16:33 TemptorSent: Actually, the build is fast, the test is slow. 2017-04-01 08:16:38 Ah 2017-04-01 08:16:48 top is very useful for seeing when you have a sudden spike in activity in real time. 2017-04-01 08:16:52 I don't quite understand those avg-cpu: %user %nice %system %iowait %steal %idle 2017-04-01 08:17:05 don't know what is the difference. 2017-04-01 08:17:10 iostat will give you a good idea of how hard you're hitting the disk vs. the rest of the process. 2017-04-01 08:17:51 Ah 2017-04-01 08:18:03 Vs. the rest of the procell? 2017-04-01 08:18:06 process* 2017-04-01 08:18:25 %user is percent of time running userspace, %system is syscalls mostly, %iowait is blocking %idle is spinning without resource 2017-04-01 08:18:57 spinning without resource? 2017-04-01 08:19:01 %steal is steal-time accounting I believe, and %nice is related to it's nice leve? 2017-04-01 08:19:15 pickfire: In an idle loop, not burning cpu. 2017-04-01 08:19:20 Ah 2017-04-01 08:19:24 Just burning io? 2017-04-01 08:19:43 pickfire: Waiting for a callback, like a server sitting with nothign to do. 2017-04-01 08:19:51 Ah 2017-04-01 08:20:03 pickfire: No, not using any resources, just spinning idle. 2017-04-01 08:21:49 Okay. 2017-04-01 08:21:56 pickfire: Basically, once a service is up and running, it doesn't need to do much of anything until it gets a connection, so it uses something like while(1){ wait_connection(); } 2017-04-01 08:22:11 Oh 2017-04-01 08:22:27 pickfire: Or something more useful :) 2017-04-01 08:22:47 TemptorSent: Does stealing means that the process steal resources from another process? 2017-04-01 08:23:09 pickfire: It has to do with accounting more... 2017-04-01 08:23:19 Woad 2017-04-01 08:23:23 I don't really use it. 2017-04-01 08:24:17 It's basically for vms with overprovisioning of allocated resources. 2017-04-01 08:25:57 Ah 2017-04-01 08:27:29 It's a measure of how much of your allocated cpu time you're using. 2017-04-01 08:28:33 If you're not getting as much cpu time as you request, your steal time goes up IIRC 2017-04-01 08:28:41 Oh 2017-04-01 08:29:31 pickfire: It's something I don't usually worry too much about on my workloads unless something is acting haywire. 2017-04-01 08:30:47 TemptorSent: How do you normally choose file system and io scheduler? 2017-04-01 08:30:48 I'd have to check docs for the exact symantics. 2017-04-01 08:31:00 pickfire: By my intended workload mostly. 2017-04-01 08:31:02 docs? 2017-04-01 08:31:19 pickfire: kernel docs on 'Steal time accounting' 2017-04-01 08:31:38 pickfire: /usr/src/linux/Documentation 2017-04-01 08:32:43 or kernel.org/doc/Documentation 2017-04-01 08:33:01 /usr/src? 2017-04-01 08:33:18 pickfire: That's where the linux src lives when you extract it. 2017-04-01 08:33:33 Ah 2017-04-01 08:34:00 pickfire; Beyond that, UTS,L. 2017-04-01 08:34:27 UTS,L.? 2017-04-01 08:35:26 Use The Source, Luke. 2017-04-01 08:36:13 pickfire: See the Jargon file for other common (and not so common these days) abbreviations. 2017-04-01 08:36:17 Aha 2017-04-01 08:37:16 TemptorSent: Luke Skywalker Use The Force. ^^ 2017-04-01 08:37:19 Things you're come across in unix-land at random. 2017-04-01 08:37:34 pickfire: Yes, it's a bad pun on that. 2017-04-01 08:37:37 I haven't came across that. 2017-04-01 08:38:00 BOFH being one of the more common ones. Got the pin. 2017-04-01 08:39:08 But back to the original question of profiling, now that you know what part is taking all the time, you can choose your profiling flags appropriately. 2017-04-01 08:40:08 pickfire: The syscalls don't seem to be your issue, so it's going to be loop unrolling, branching, and caching in the copy/hash/index loop that you'll be looking at. 2017-04-01 08:40:43 BOFH? 2017-04-01 08:40:58 Look that one up ;) 2017-04-01 08:41:30 TemptorSent: Wow, you can even deduce that from the output of `time`. Interesting. 2017-04-01 08:41:52 Haha, Bastard Operator From Hell. 2017-04-01 08:42:01 pickfire: Well, the output of time, iostat, and the general design of git anyway. 2017-04-01 08:42:12 :) 2017-04-01 08:43:21 GC is basically walking the tree, so you've got a set of loops that read, hash, copy, compare, and copy again IIRC. 2017-04-01 08:44:02 And some time spent in rehash/reindex 2017-04-01 08:44:39 It's just the nature of DAGs, really. 2017-04-01 08:45:29 (And Merkle-DAGs/block-chains) 2017-04-01 08:45:56 (And please excuse any horribly butchered spellings) 2017-04-01 08:49:01 ACTION found too many jargons 2017-04-01 08:49:11 Too deep, can't understand much. 2017-04-01 08:49:35 DAGs are basic structures in computing - Directed Acyclic Graphs 2017-04-01 08:49:41 Ah 2017-04-01 08:49:51 I think I have seen something similar. 2017-04-01 08:50:04 Merkle DAGs are a class of hash-based DAGs 2017-04-01 08:50:09 acyclic graph traversal 2017-04-01 08:50:16 Found that in http://pkgconf.org/features.html 2017-04-01 08:50:17 Yes, exactly. 2017-04-01 08:50:30 TemptorSent: But don't know what is DAG. 2017-04-01 08:51:07 Directed simply means that you have a link from a parent to a child node. 2017-04-01 08:51:24 Acyclic means that it can't loop back on itself 2017-04-01 08:51:34 Ah 2017-04-01 08:51:43 A never ending loop 2017-04-01 08:52:35 And Graph implies that the structure is represnted by nodes (usually containing the data), and edges, which form the links, but generally only carry meta-data if anything. 2017-04-01 08:53:25 So a DAG is a set of nodes that has traversal patterns making a tree struture from the top down, but no cross links or reverse linking. 2017-04-01 08:54:01 Like a -> b -> c -> d 2017-04-01 08:54:15 Then what git does is uses those hashes as keys in an index pointing to the actual data in the pack files. 2017-04-01 08:54:22 pickfire Yes. 2017-04-01 08:55:22 d<-c<-a->b->e as well :) 2017-04-01 08:56:31 TemptorSent: Does apk uses topological sorting? 2017-04-01 08:56:40 So what gc does is traverses the tree, scans the index, scans the pack file, and prunes any orphans, then compresses and rebalances I believe. 2017-04-01 08:57:01 pickfire: I believe so? I didnt' get into it in depth yet. 2017-04-01 08:57:17 pickfire: And I'm also far from an expert on git's internals, I just know the basics. 2017-04-01 08:59:08 Ah 2017-04-01 08:59:25 pickfire: Hopefully that helps you approach profiling optimizations with a little better understanding? 2017-04-01 08:59:43 Yeah. 2017-04-01 09:00:00 And gives you an idea of what's likely to be in your hot loop. 2017-04-01 09:00:31 Cache misses there can really drag things down too. 2017-04-01 09:01:10 But I suspect that it's mostly going to turn out that git does a lot of work :) 2017-04-01 09:02:25 See if you can knock 5-10% off the top of your runtime with a profiled build -- if so, twiddle profile options until you figure out which one or combination is making the major impact, then try to fix the code-path in the source if possible. 2017-04-01 09:04:21 But really optimizing git is going to be a much bigger project than just running profile guided optimizations -- I believe it was written without using any of the matrix math functions of modern cpus... 2017-04-01 09:04:46 Find someone that's good at that kind of work take a crack at it if you want to see big speedups. 2017-04-01 09:05:55 wow 2017-04-01 09:05:56 pickfire: Just remember the law of diminishing returns 2017-04-01 09:06:09 But probably not that fast. 2017-04-01 09:06:36 pickfire: It all depends on your workload and needs. 2017-04-01 09:28:22 Alright, I'm off to bed. Goodnight pickfire. 2017-04-01 10:09:15 Night. 2017-04-01 18:33:51 So, it turns out that MirBSD's pax doesn't even know how to handle pax archives! 2017-04-01 18:34:26 Does anyone have schilytools packaged up somewhere perhaps? 2017-04-01 19:39:40 Error relocating /usr/lib/libglib-2.0.so.0: pthread_setname_np: symbol not found 2017-04-01 19:39:43 after today's update 2017-04-01 20:06:39 Okay I'm getting hunderes of these a day. 'segfault at 0 ip 00007f7b101c8908 sp 00007ffd76bad118 error 4 in ld-musl-x86_64.so.1[7f7b1017a000+88000]' 2017-04-01 20:06:44 How would I go about debugging it? 2017-04-01 20:39:20 find the process gdb it 2017-04-01 20:59:20 It's an exim process. child I guess as nothing is showing up in the exim logs. Odly. 2017-04-01 22:33:42 question for getting https://github.com/alpinelinux/aports/pull/684 into testing, i'm updating that port to 1.0 idris (yes they released 1.0 on april first) 2017-04-01 22:34:10 would the fact that the build stage uses cabal to download the dependencies invalidate it from getting into testing? 2017-04-01 22:35:12 rather, what approach for things built via ghc dependencies should be taken, to note, there are around 100 total transitive dependencies for this compiler 2017-04-02 14:48:03 %3249 I have fix tlp.initd, please review it 2017-04-02 16:05:36 fixes bad regexes in nano - https://github.com/alpinelinux/aports/pull/1189 2017-04-02 21:01:21 Okay, after much searching, the only program I could find that would actually extract the APK-TOOLS.checksum.SHA1 fields from the pax headers in the .apks is p7zip! 2017-04-02 21:02:18 I ended up writing a hideous awk script that will try to extract them and associate them with the right file from the raw tar stream, but that's fugly. 2017-04-02 21:03:24 What would it take to add command line options to apk to extract headers upon request? 2017-04-02 21:05:34 (Read as: How many pitchforks do I need to dodge and what is the policy for feature additions in apk-tools?) 2017-04-02 22:34:21 ncopa: Is the APK-TOOLS.checksum.SHA1 header ever actually used anywhere, or does it just exist in the headers for future use? I couldn't find a single place it was actually extracted unless it was writing a protected file and generating a .apk-new. 2017-04-02 23:41:27 <^7heo> ncopa: if you're around... c4175a051d4c0164855e61ed44f54cbbf020731c is the patch where all broke loose in my mkinitfs pr. 2017-04-02 23:41:44 <^7heo> That's one of your patches, so if you can take a look, I'd really appreciate it ;} 2017-04-02 23:42:32 <^7heo> I will probably solve the problem given enough time; but since you are the one who initially wrote that patch, you have more chances than me to actually fix it fast ;) 2017-04-03 00:10:25 <^7heo> ncopa: the thing now builds, but it does not pass the tests. I'll review tomorrow. I hope I can solve it, but again, if you can help; it'd be awesome 2017-04-03 00:10:32 <^7heo> good night all. 2017-04-03 05:21:15 'evening fabled. 2017-04-03 05:22:01 hi 2017-04-03 05:22:47 So I've been hunting high and low, but I can't find ANY way of getting the checksums in the pax headers of the apks out without horribly hackary. 2017-04-03 05:23:15 Are they actually implemented beyond being stored, or am I blind? 2017-04-03 05:23:44 apk-tools reads, stores and verifies them in 'audit' 2017-04-03 05:24:48 Huh, the ONLY place I saw it actually read was when it hits a conflict with a protected file. 2017-04-03 05:25:02 that's another place which checks it 2017-04-03 05:25:04 APK-TOOLS.checksum.SHA1 header. 2017-04-03 05:25:21 lbu uses 'apk audit' to generate the changed file list 2017-04-03 05:26:06 I was trying to analyze a codepath to use to add a list-apk-contents-with-checksums feature. 2017-04-03 05:27:25 apk_archive_entry_extract isn't called anywhere but on conflict that I could find, and that's the only mention of the header fingerprint I can find in apk tools, so if you can point me at where to look so I can throw away my horrible, horrible awk script and do it right, I'd much appreciate it :) 2017-04-03 05:27:58 archive_entry_extract is called for every file when an .apk is being extracted 2017-04-03 05:28:23 So the suffix is only used on conflict? 2017-04-03 05:28:45 yes 2017-04-03 05:28:50 Wow, that's a hard code path to follow! 2017-04-03 05:30:18 Okay, so the short of it appears there is no easy way to simply itterate over the members of the archvie and spit out the values without setting up an entire context and extracting. 2017-04-03 05:31:25 So all file access essentially passes through the database both ways? 2017-04-03 05:31:49 pretty much yes 2017-04-03 05:31:49 Or at least that structure... 2017-04-03 05:32:23 Okay, that's beyond a quick few lines it's looking like :/ 2017-04-03 05:33:29 I'll have to see if my awk script can put up with ugly input, absent ANY posix pax compliant tool. 2017-04-03 05:34:35 I couldn't find anything that could list the headers, but at least 7zip would dump them to directories. 2017-04-03 05:35:02 That's a pretty sad state of affairs for a supposedly standard archive format! 2017-04-03 05:35:45 Anyway, that aside, mkinitfs in my branch is refactored and supports everything the original did. 2017-04-03 05:36:08 I'm working on cleaning up the kernel updating code to actually make sense :) 2017-04-03 05:36:38 ok, do note that mkinitfs is packaged separately because it is used also to construct hard-disk install system's initramfs when linux kernel is updated 2017-04-03 05:37:09 Right, I have it to the point it should handle that or only need minor adjustments to handle that. 2017-04-03 05:37:43 It is almost exactly compatible with the existing script, including all feature names (in a compat direcotry) 2017-04-03 05:39:02 It should drop in unless someone has done custom features, in which case there's a converter script there too :) 2017-04-03 05:40:19 I'm going to suggest using the directory /usr/share/mkalpine for all of the related scripts, including mkinitfs, mkimage, update-kernel, and to be added mkmodloop. 2017-04-03 05:42:18 That would keep /etc used for user configs, not package details. 2017-04-03 05:43:44 I intend to transition the format of the files/modules entries themselves to be prefixed by the source package names so we can quickly discover what files come from what apks. 2017-04-03 05:44:08 And make very clear anything that comes from the filesystem. 2017-04-03 05:45:32 Also, the modules don't need paths specified in most cases to be discovered, so I'm going to use the modinfo output to get the filenames, which should be cannonical even if an alias is given for the module name. 2017-04-03 05:46:20 Let's see how long before iRCFrEAK hits the K-Line... 2017-04-03 05:49:59 Right at the moment, I'm working on changing update kernel to use the following pieces broken out into their own tools: stagekernel, which takes a kernel build directory or package name and a list of other build directories and apks to process. 2017-04-03 05:51:25 It installs/unpacks each to it's own directory, creates a manifest file, then links all files in all extracted/installed directories into a merged-root. 2017-04-03 05:52:22 Then it creates a merged manifest file which indicates the package name, package version, checksum, and path for each file. 2017-04-03 05:54:12 It then runs depmod and uses the manifest to make a list of package deps for modules. 2017-04-03 05:56:36 Once staged, mkmodloop and mkinitfs can use the manifest and copy/extract only what they need, while still being able to trace the origins of each file they contain to an original signed apk. 2017-04-03 05:57:07 Make sense fabled? 2017-04-03 05:59:18 The modloop and mkinitfs module handling could be merged to the point of specifying features for either in same fashion using the same definitions. 2017-04-03 06:01:10 That would allow initfs to only have what's needed for boot, while making a modloop that contains only what the user needs on their system and can be stored in ram, leaving the boot device able to be removed. 2017-04-03 06:03:02 Until that's done, using the existing kitchen sink is easy enough :) 2017-04-03 06:05:27 It will have the added bonus that the image generation will only need to stage a given kernel once. 2017-04-03 06:08:42 update-kernel itself becomes a matter of calling stagekernel and copying the required files to their destination, preferably with a manifest of everything install extracted and installed. 2017-04-03 09:50:05 <^7heo> ncopa: ping 2017-04-03 10:02:36 ^7heo: pong 2017-04-03 10:02:37 hi 2017-04-03 10:06:30 <^7heo> ncopa: hey man 2017-04-03 10:06:46 <^7heo> ncopa: so I tried to fix that mkinitfs deported header feature. 2017-04-03 10:06:52 <^7heo> Good thing is that I got the rebase through. 2017-04-03 10:06:53 <^7heo> Finally. 2017-04-03 10:07:05 good 2017-04-03 10:07:10 <^7heo> I'm not very comfortable with rebasing so much code I don't know over so much code I don't know. 2017-04-03 10:07:20 <^7heo> but I did it, and I hope I got most of the logic right 2017-04-03 10:07:50 <^7heo> it didn't compile when I finished the rebase, but that's because I blindly copy-pasted a function call around while the function signature had changed in the meanwhiel. 2017-04-03 10:07:55 <^7heo> s/whiel/while/ 2017-04-03 10:08:12 <^7heo> Now it does compile, but it does not work as intended, it does not pass the tests. 2017-04-03 10:08:22 <^7heo> So I am working on finding what is wrong now. 2017-04-03 10:08:35 <^7heo> I'm on 2e3a4f61677f2ab4c65a4f128ec57d1fce87599d 2017-04-03 10:08:44 <^7heo> And the test is not working anymore, already. 2017-04-03 10:09:07 <^7heo> I guess that if I fix that, I could probably easily get the rest fine. 2017-04-03 10:10:53 <^7heo> The thing is, as I read the patch, I don't see anything blatantly wrong: https://github.com/alpinelinux/mkinitfs/pull/11/commits/2e3a4f61677f2ab4c65a4f128ec57d1fce87599d 2017-04-03 10:12:12 <^7heo> ncopa: when I run the test, I get a crapload of `mdev: unknown user/group 'root:input' on line 8x` with x being in 5..9 2017-04-03 10:12:27 <^7heo> ncopa: Any idea where that could be coming from? 2017-04-03 10:12:45 do you have a group named "input"? 2017-04-03 10:12:58 i think its something in your /etc/mdev.conf 2017-04-03 10:13:03 <^7heo> no. I do not. 2017-04-03 10:13:08 <^7heo> Should I? 2017-04-03 10:13:22 <^7heo> I mean my computer works as intended, so... 2017-04-03 10:13:48 i think you should have a group named "input" 2017-04-03 10:14:00 <^7heo> ohmydog I don't like files which start with '# This is a sample ...' 2017-04-03 10:14:23 <^7heo> ncopa: right, under '# input stuff' 2017-04-03 10:14:42 <^7heo> I take it is pretty new, was I never saw such a message ever before. 2017-04-03 10:15:31 i dont think its new 2017-04-03 10:16:19 <^7heo> Well, my current running install is from 3.2 or something 2017-04-03 10:16:57 <^7heo> and I have upgraded it every other month (or couple thereof) 2017-04-03 10:17:07 <^7heo> but I never had anything happening with that. 2017-04-03 10:17:56 <^7heo> ok created. 2017-04-03 10:18:25 <^7heo> I'm gonna re-run the test now. 2017-04-03 10:18:34 <^7heo> To see if I get a different input. 2017-04-03 10:18:50 <^7heo> Much different. 2017-04-03 10:19:01 <^7heo> Thanks ncopa, problem half solved ;] 2017-04-03 10:33:27 <^7heo> ncopa: yeah so it has to do with the way the whole nlplug-findfs has been changed right after I submitted my patchset. 2017-04-03 10:33:42 <^7heo> ncopa: the existing variables are not holding the same data anymore. 2017-04-03 10:35:52 I see the g++ package contains C headers for java. shouldn't they be in gcc-java? https://pkgs.alpinelinux.org/contents?page=11&arch=x86_64&branch=edge&name=g%2B%2B 2017-04-03 10:52:08 the APKBUILD examples in the abuild repository and the APKBUILDs created by newapkbuild still use explicity `|| return 1` statements. Shouldn't those be removed since abuild runs with `set -e` nowadays? 2017-04-03 11:00:30 Is it in a function? 2017-04-03 11:01:13 yeah, I think that's still needed. Cos `-e` behaves differently in functions 2017-04-03 11:01:51 I never remember exactly how it behaves in a function, but I know it does behave differently 2017-04-03 11:19:21 What should I do with http://patchwork.alpinelinux.org/patch/3199/? 2017-04-03 11:20:08 ashb: actually it should only behave differently in a multi-command pipeline, when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last 2017-04-03 11:22:20 in functions it works as expected so imho we don't need the explicit `|| return 1` in the templates 2017-04-03 11:22:54 All I can remember is that it I've been stung by it in functions :D 2017-04-03 11:29:25 hello all 2017-04-03 11:31:57 anyone has knowledge about acme challenges? 2017-04-03 11:45:48 _ikke_: hi. 2.2.4 2017-04-03 11:58:30 <^7heo> ncopa: currently it seems that the test script has an issue. 2017-04-03 11:58:51 ^7heo: not surprised 2017-04-03 11:59:57 <^7heo> I mean I had to fix a couple of things along the way 2017-04-03 12:00:11 <^7heo> but yeah right now the problem I have is in the testing script. 2017-04-03 12:00:17 <^7heo> ncopa: and why aren't you surprised? 2017-04-03 12:03:26 <^7heo> Now I have a better test script, it doesn't crash on the normal testing anymore, but it crashes on the header test. 2017-04-03 12:03:30 <^7heo> So there's progress. 2017-04-03 12:16:52 clandmeter: a little bit 2017-04-03 12:24:04 /bin/sh -c 'set -e; foo() { false; echo here?; }; foo && echo "foo passed"; echo $?' 2017-04-03 12:24:21 nmeum: ^^ that's when set -e in functions behaves oddly. If the function itself is used in a compound/conditional 2017-04-03 12:24:26 That will show "here?" 2017-04-03 12:25:11 (Though if its the last statement in a function it's oka 2017-04-03 12:51:27 <_ikke_> LebedevRI: Thanks 2017-04-03 12:52:03 _ikke_: i see that .3 got skipped, and no one complained? :/ 2017-04-03 12:52:30 <_ikke_> LebedevRI: Nope, no one did. (I did see it was released, but forgot to push the updated package) 2017-04-03 12:53:24 i guess no one is using it on alpine then 2017-04-03 12:54:47 <_ikke_> I only ever heard about one person wanting it on Alpine, but never heard of them again 2017-04-03 12:55:50 i did bump the thread on the maillist, maybe someone will respond 2017-04-03 14:02:54 <^7heo> ncopa: I think I fixed it. 2017-04-03 14:03:09 <^7heo> ncopa: please review in depth if you can; but it passes the tests locally. 2017-04-03 14:05:59 <^7heo> AND IN GITHUB TOO!!!! \o/ 2017-04-03 15:10:34 <^7heo> Klowner: ping 2017-04-03 15:25:34 'morning ncopa - how's it going? 2017-04-03 15:26:20 hi 2017-04-03 15:26:45 trying to figure out why by bluetooth controller is not working 2017-04-03 15:27:28 I don't know if you caught up on the backlog, but my mkinitfs script should be able drop in as a replacement. 2017-04-03 15:27:54 Hmm, failing to initilize or failing to connect? 2017-04-03 15:28:28 [ 5.816148] Bluetooth: hci0 command 0xfc05 tx timeout 2017-04-03 15:28:28 [ 5.816155] Bluetooth: hci0: Reading Intel version information failed (-110) 2017-04-03 15:28:39 looks like kernel or firmware issue 2017-04-03 15:28:49 but reverting to older kernel didnt solve it 2017-04-03 15:29:00 neither did downgrading the firmware 2017-04-03 15:29:05 so i dunno whats wrong 2017-04-03 15:29:26 Yeah, that is a bit odd.. It's a usb->BT adapter? 2017-04-03 15:29:32 TemptorSent: do you have a pull request for mkinitfs git repo? 2017-04-03 15:29:41 yes, its on the usb bus 2017-04-03 15:29:46 but on the motherboard 2017-04-03 15:30:26 ncopa: The first thing I would suspect is something enumerating wrong and it not initilizing the endpoints fully. 2017-04-03 15:32:07 ncopa: No PR to the mkinitfs repo as of yet, I'm not sure if that's the best way of going about integrating it either... 2017-04-03 15:34:24 so you prefer that we maintain 2 different mkinitfs? 2017-04-03 15:34:29 ncopa: I could try to merge it into the existing repo, but it would probably be more confusing than not. 2017-04-03 15:35:10 ncopa: No, ideally we could transition the existing mkinitfs repo to just nlplug. 2017-04-03 15:36:19 ncopa: And provide mkinitfs with 'mkalpine' or whatever the package name would be that includes the functionality of mkinitfs, update-kerenl, etc. 2017-04-03 15:36:34 <^7heo> TemptorSent: aside from the revamp, what did you fix with your version? 2017-04-03 15:37:39 ^7heo: As far as mkinitfs itself, I refactored or rewrote the entire thing :) 2017-04-03 15:38:17 <^7heo> yes, and aside from that revamp, what did you fix? 2017-04-03 15:38:25 ^7heo: I'm not messing with nlplug at all at this point, and my proposed init changes are not integrated. 2017-04-03 15:38:44 <^7heo> yeah I know ;) 2017-04-03 15:38:50 <^7heo> I'm asking what new features you implemented. 2017-04-03 15:38:55 <^7heo> if any. 2017-04-03 15:38:56 ^7heo: File structure for features was the main goal. 2017-04-03 15:39:27 <^7heo> What is a File structure for features? 2017-04-03 15:39:31 ^7heo: So the feature definitions can be defined in a modular manner. 2017-04-03 15:39:35 <^7heo> Ah 2017-04-03 15:39:42 <^7heo> Gotchat. 2017-04-03 15:39:47 <^7heo> s/chat/cha/ 2017-04-03 15:39:56 ^7heo: Look at /etc/mkinitfs/features.d for the current state. 2017-04-03 15:40:33 <^7heo> TemptorSent: yeah that's a list of modules to load, or? 2017-04-03 15:40:35 ^7heo: Adding the 'ata' feature ends up including every ata-like driver known to man in the initfs. 2017-04-03 15:40:49 ^7heo: files/modules to be included in the initfs. 2017-04-03 15:41:12 <^7heo> ah yeah 2017-04-03 15:41:26 <^7heo> And your goal is to reduce the size of the initfs? 2017-04-03 15:42:09 ^7heo: So with them being stored in shell scripts instead of flat files, we can do things like include several feature sets in one file and have them inherit where desired. 2017-04-03 15:42:36 ^7heo: Yeah, removing everthing we don't need in an initfs :) 2017-04-03 15:44:23 ^7heo: I'm just getting ready to add the packages as tags to the files included in a feature, so 'zfs:/usr/sbin/zpool' for instance. 2017-04-03 15:45:41 ^7heo: And probably going through to change the kernel flavor handling in mkimage at the same time so everything is consistent. 2017-04-03 15:47:53 ^7heo: With the intent of doing something like 'zfs-KFLAVOR:zfs' for the modules and it just working. 2017-04-03 15:49:45 So part of the problem with splitting it out and packaging it in place of the original mkinitfs script is that the logic for handling things like kernel versions/flavors/etc would have to be duplicated for each tool that needs them. 2017-04-03 15:54:11 I'm working on replacing the update-kernel logic entirely with a seperate stagekernel tool, a mkmodloop tool, and a very simple installer. 2017-04-03 15:59:44 This gives us the ability to make modloops that are customized in their contents using the same type of definitions we're using for mkinitfs. 2017-04-03 17:49:34 Query: For custom kernel / module builds, how should we identify the version? 2017-04-03 18:21:05 Would $pkgname-$pkgver@$abirelseae be appropriate? 2017-04-03 18:23:15 Giving for instance 'zfs-0.6.5.9-r0@4.9.19-0-grsec' if one were to compile zfs themselves 2017-04-03 18:23:44 apk already uses @ for pinning to a specific repo 2017-04-03 18:25:40 kaniini: Okay, I'm not sure if that actually would conflict with the use for custom builds, but I'm open to suggestions for how to handle them :) 2017-04-03 18:28:11 kaniini: Would '=' or '%' be preferable? 2017-04-03 18:28:46 TemptorSent: @ is not an allowed character in package atoms 2017-04-03 18:29:32 kaniini: Right, but these would not be packages per-se, since they're just build directories. 2017-04-03 18:30:36 But scrap the '@' sign if it would cause confusion. 2017-04-03 18:30:48 i think it would be preferable to avoid using @ anyway, as it would be confusing 2017-04-03 18:32:41 So, '=','%','^', or '~' are options, or something more complex if we really need it. 2017-04-03 18:34:02 kaniini: The use is for staging kernel related files from custom builds for use by mkinitfs, modloop, etc. 2017-04-03 18:35:13 And creating a manifest to identify where each file came from along with checksums for it. 2017-04-03 18:36:20 Eventually, it could also handle the building of such out of tree objects automatically as well. 2017-04-03 18:36:57 And build all of your custom modules/firmware for you when you update your kernel. 2017-04-03 18:37:23 So that's the need for the versioning... 2017-04-03 18:42:12 You'd pass it something like 'make_modules_install:/usr/src/mypkg-3.1.5^4.9.19-0-grsec' and it will change to /usr/src/mypkg-3.1.5 and run make modules_install to an output directory of $staging/4.9.19-0-grsec/mypkg-3.1.5/modules 2017-04-03 18:44:39 And in the manifest would have an entry 'custom_modules:mypkg-3.1.5^4.9.19-0-grsec SHA512: ' for each file installed in that directory (as well as sha256 and sha1 currently) 2017-04-03 18:48:03 But it's needed to tell the difference between entries for mypkg-3.1.5 built for 4.9.11-1-grsec vs 4.9.19-0-grsec 2017-04-03 18:49:08 kaniini: If you have thoughts on a cleaner way to handle that, I'm all ears. 2017-04-03 18:51:38 It's also needed to allow building multiple versions of a package against the same kernel (which seems broken in apk right now) 2017-04-03 18:53:31 In fact, the whole kernel flavor handling is a bit kludgy IMHO, with module packages created for each flavor they want to support rather than just being compiled when the kernel update is. 2017-04-03 18:54:41 The module packages should be able to automatically detect which kernels are installed (install-if?) and install modules for all of them each update. 2017-04-03 18:55:50 I'll fix the rest of that later, right now I just want to nail down a consistent means of specifying it. 2017-04-03 18:59:03 The other possible gotcha is what do we do about custom kernels with the same versions as dist? Do we default to naming them -custom? -$builddate? -$hostname? 2017-04-03 19:00:20 any easy way to split an apk filename into package name and version? 2017-04-03 19:00:52 ie. mini_httpd-1.23-r0.apk _> mini_httpd and 1.23-r0 2017-04-03 19:01:17 ACTION is sure it's done all the time in apk 2017-04-03 19:01:24 tdtrask: several options, depending on the context 2017-04-03 19:01:52 shell script 2017-04-03 19:02:16 there are ways. 2017-04-03 19:02:18 In a shell script, trimming back to the last -followed by a version number works. 2017-04-03 19:02:23 there's no *easy* way. 2017-04-03 19:02:40 specifically, need to write a shell script to cleanse a local repo that contains multiple version of the same packages 2017-04-03 19:02:46 and only keep the most recent 2017-04-03 19:03:11 why do we need to care about custom builds 2017-04-03 19:03:16 they should use aports 2017-04-03 19:03:24 What I do is hack off .apk, hack off -r*, hack of -[0-9._]* 2017-04-03 19:03:30 TemptorSent: as seen in the example above, the last '-' is part of the version 2017-04-03 19:03:45 ah, three steps 2017-04-03 19:04:05 tdtrask: Yeah, that way you capture each piece of info as you go too. 2017-04-03 19:04:30 are we guaranteed to see the '-' characters in that manner? 2017-04-03 19:04:39 if so, it's easy enough to parse 2017-04-03 19:04:39 kaniini: Because MANY people custom build their own kernels or need to use some modules that require an out of tree build. 2017-04-03 19:04:58 so use aports 2017-04-03 19:05:03 tdtrask: I believe so. 2017-04-03 19:05:12 kaniini: Not realistic. 2017-04-03 19:06:07 TemptorSent: thanks 2017-04-03 19:06:23 kaniini: At least not without making aports usable without installing all of aports :) 2017-04-03 19:07:30 tdtrask: I haven't verified there are no outliers, but that's what I gathered from the spec for version numbers. 2017-04-03 19:10:07 tdtrask: Use single '%' to do the hacking, then capture by hacking what's left off what you started with. 2017-04-03 19:12:13 kaniini: This needs to work in the same environment update-kernel works currently. I'll be gut-shot, then drawn-and-quartered if I suggest installing aports to let the user update their kernel. 2017-04-03 19:13:00 you'll be drawn and quartered either way. You need to decide whom you fear more. 2017-04-03 19:13:25 The mob, methinks :) 2017-04-03 19:14:34 And I'm trying to make everything that works currently continue to work while adding some useful information. 2017-04-03 19:14:59 i will be in the mob if you break my stuff 2017-04-03 19:15:06 just sayin' 2017-04-03 19:15:18 kaniini: What would I be breaking? 2017-04-03 19:15:44 "if you breaka my tests I breaka you face" 2017-04-03 19:15:56 the more i read about this mkinitfs rewrite stuff the more i fear for its complexity 2017-04-03 19:15:57 That's what I'm trying to figure out BEFORE it bites anyone. 2017-04-03 19:16:36 Shiz: This is actually nothing to do with mkinitfs than providing it the files it needs. 2017-04-03 19:17:09 doesn't change stuff 2017-04-03 19:17:19 Shiz: It's providing a single tool to stage kernel related files. 2017-04-03 19:17:37 Shiz: Currently, what we have is broken in many use cases. 2017-04-03 19:18:07 Shiz: It only works for a specific set of configurations without major intervention. 2017-04-03 19:18:37 and you happen to be the only person who's ran into a different configuration? 2017-04-03 19:18:38 :p 2017-04-03 19:18:50 Shiz: And breaks entirely sometimes (like it did on my system, installing modules that didn't match the kernel version) 2017-04-03 19:19:22 Shiz: Have you been reading the questions here and in -linux? Dozens of people trying to work around issue.s 2017-04-03 19:20:03 Shiz: It currently does not even get the dep tree right for squashfs! 2017-04-03 19:21:20 Shiz: exactly 2017-04-03 19:21:39 skarnet: Is there anything I'm running up agasint that is likely to break any existing configuration or test? 2017-04-03 19:22:38 kaniini, Shiz, skarnet: Are you guys saying that the way the kernel and module building is handled now is GOOD? 2017-04-03 19:22:58 TemptorSent: don't ask me, I'm the comic relief. 2017-04-03 19:23:08 i am just saying 2017-04-03 19:23:10 i'm saying i sure have never ran into issues or know anyone who has w.r.t. modules 2017-04-03 19:23:11 :p 2017-04-03 19:23:13 please do not break my stuff 2017-04-03 19:23:15 skarnet: I value your opinion. 2017-04-03 19:23:36 kaniini: I'm asking what I'm going to break by making the proposed changes! 2017-04-03 19:24:04 kaniini: AFAIK, it shouldn't change ANYTHING. 2017-04-03 19:24:47 I appreciate that, but atm I'm very unable and unwilling to focus on your issue. 2017-04-03 19:25:17 You need to realize that your efforts are appreciated but are also a human resource hog. 2017-04-03 19:25:22 skarnet: No problem, just please speak up if anything sounds like it's going to be a breaker. 2017-04-03 19:25:46 No, you can't expect me or anyone to be the alarm bell for you. 2017-04-03 19:26:13 when i read about things like cpio appends 2017-04-03 19:26:16 and blah blah 2017-04-03 19:26:19 You need to pace yourself so people can review what you're doing at their own rhythm. 2017-04-03 19:26:30 i think "please do not break my stuff" 2017-04-03 19:26:34 skarnet: Unfortunately, I don't have the years with alpine to know about the idiosyncracies. 2017-04-03 19:27:35 kaniini: I'm actively trying NOT to break your stuff. 2017-04-03 19:28:40 And I'm generally trying to make sure I don't do anything that would cause any breakage for users upgrading unless they've already done something out of the ordinary, in which case I've given them tools to convert as well. 2017-04-03 19:29:42 kaniini: So telling people to use aports for their custom builds would be a regression compared to current functionality. 2017-04-03 19:30:23 TemptorSent: alpine is not slackware 2017-04-03 19:30:31 TemptorSent: you are really meant to use apk for everything 2017-04-03 19:30:45 skarnet: And the only reason I'm trying to get this done on a short timescale is ncopa requested it be done for 3.6. 2017-04-03 19:30:48 but aports is a sole alpine repo 2017-04-03 19:30:56 unless you mean 'use abuild', in which case yes 2017-04-03 19:31:04 yes, use abuild 2017-04-03 19:31:33 kaniini: Okay, you sell ncopa and fabled on that, and I'll scrap the custom build handling they setup. 2017-04-03 19:31:42 TemptorSent: if you replace the kernel with your own outside of our packaging, then we will assume you are knowledgeable enough to deal with the consequences of that 2017-04-03 19:32:01 sigh 2017-04-03 19:32:18 TemptorSent: yes, obviously the tools support custom builds 2017-04-03 19:32:36 All I was asking is how to notated the kernel version for external builds so we can keep track of which files came from where and checksum them. 2017-04-03 19:33:47 at any rate 2017-04-03 19:33:50 As it stands, nothing on the system ever checksums them, including apk audit. 2017-04-03 19:33:52 please do not break my stuff 2017-04-03 19:33:59 yes 2017-04-03 19:34:01 so 2017-04-03 19:34:09 maybe there is a theme here 2017-04-03 19:34:19 that we do not care about the integrity of said custom builds 2017-04-03 19:34:25 because we assume you are smart enough to deal with it yourself 2017-04-03 19:34:26 Unchecksummed, untracked files? 2017-04-03 19:34:43 like i said, you're really supposed to use apk to manage your custom builds 2017-04-03 19:34:48 maybe what you should do 2017-04-03 19:34:51 is make a tool 2017-04-03 19:34:58 to enable apk to track those builds more easily 2017-04-03 19:35:07 That's what I'm doing! 2017-04-03 19:35:33 then i dont udnerstand what all of this business is about 2017-04-03 19:35:34 I'm making a checksummed manifest,. 2017-04-03 19:35:39 all you really need to do is just generate an abuild 2017-04-03 19:35:47 and then run abuild on it 2017-04-03 19:35:52 er, apkbuild* 2017-04-03 19:36:04 i could seriously code this in like 10 minutes 2017-04-03 19:36:16 That requires installing the whole abuild framework. 2017-04-03 19:37:00 that's what a premature optimizator would say 2017-04-03 19:37:01 kaniini: Okay, clearly my needs are not the priorities of Alpine - I get that. 2017-04-03 19:37:54 kaniini: What I don't get is why supporting manifests of inidivual files is so counterintuitive. 2017-04-03 19:39:34 oh gnoes 2017-04-03 19:39:37 not installing abuild 2017-04-03 19:39:42 kaniini: I'm trying to get the initfs to the point it can be a set of apks you install, but that still leaves dozens of files orphaned. 2017-04-03 19:39:48 ACTION walks away from this conversation 2017-04-03 19:40:30 Look, if my work has no value, just tell me and I'll give it up as a bad job. 2017-04-03 19:41:49 I really didn't intend to get this far into it in the first place, and I can just as easily purge the whole mess and get away from the computer again. 2017-04-03 19:42:12 why is it an either/or thing 2017-04-03 19:42:27 it's either great or i am going to go raise goats 2017-04-03 19:42:56 that's right! #whynotboth 2017-04-03 19:43:14 my work is great *and* I'm going to raise goats anyway 2017-04-03 19:43:16 just because 2017-04-03 19:43:17 kaniini: Because I have other things I could be spending my time on if I'm just spinning my wheels here and you could fix the problem in a few minutes rather than me taking a few days. 2017-04-03 19:44:16 kaniini: And none of those other things involve a computer, and the weather is now getting nice, so I don't have much reason to waste time if that's all I'm doing. 2017-04-03 19:44:52 as i said, why not just leverage abuild for this 2017-04-03 19:44:56 if you are installing your own kernel, would you not want the package manager to properly be aware of it? 2017-04-03 19:45:08 kaniini: I could have solved my original problem with a drive out to Utah in less time than I've spent trying to make Alpine fit for my needs. 2017-04-03 19:45:09 gentoo have things like genkernel 2017-04-03 19:45:12 which basically do this 2017-04-03 19:45:26 kaniini: Genkernel doesn't work for shit to make a CUSTOM kernel. 2017-04-03 19:45:46 what is a custom kernel then? 2017-04-03 19:45:46 kaniini: I ALWAYS built my own kernel in gentoo/funtoo. 2017-04-03 19:46:36 I always built my own kernel no matter what distro I was using, and I hated it when distros tried to force me to use their own shitty framework. 2017-04-03 19:46:40 kaniini: One which is patched/has custom config settings/signed/etc. 2017-04-03 19:46:55 Just for reference. 2017-04-03 19:47:20 skarnet: Agreed. Thats why I'm trying to take the resulting files and do something sane with them, not modify the build process. 2017-04-03 19:47:22 skarnet: well there is nothing wrong with not using a framework, but you shouldnt expect tools dependent on that framework anyway to work with your custom kernel 2017-04-03 19:47:36 if you are that deep in, you know what you're doing 2017-04-03 19:47:37 kaniini: exactly 2017-04-03 19:47:46 and probably aren't using an initramfs anyway 2017-04-03 19:48:20 i think i'm fine with the mkinitfs thing not handling non-abuild/apk files 2017-04-03 19:48:22 personally. 2017-04-03 19:48:39 yeah, once I understood initramfs was useless in my simple case (rootfs on a good old ext2 hda), I rebuilt the kernel specifically to get rid of it. :P 2017-04-03 19:48:46 i don't think it's an unreasonable requirement to do your kernel via abuild if you really want to 2017-04-03 19:48:49 kaniini: That's going a bit far -- Often the reason you're building a custom kernel is to support just the drivers you need to load the payload into the initramfs for run-from-ram nodes. 2017-04-03 19:48:52 support that 2017-04-03 19:48:54 but 2017-04-03 19:49:05 TemptorSent: so here's my problem 2017-04-03 19:49:08 [citation needed] 2017-04-03 19:49:14 when i'm building a custom kernel, i don't include module support in the first place 2017-04-03 19:49:20 since i already can include everything i need as =y 2017-04-03 19:49:29 so... how does a custom kernel affect the initramfs at all? 2017-04-03 19:49:55 Shiz: In that case, you wouldn't be installing any modules in the initramfs. 2017-04-03 19:49:55 if you want to use alpine tools with a custom built kernel, it should be built the alpine way 2017-04-03 19:50:14 if you do not care about that, then don't use alpine tools 2017-04-03 19:50:14 kaniini: i think it's even fine to use the tools with it 2017-04-03 19:50:18 that's what the current mkinitfs does 2017-04-03 19:50:23 kaniini: How does 'make menuconfig' work with abuild? 2017-04-03 19:50:28 but going out of its way to support it... yeah 2017-04-03 19:50:44 sure, but if he wants to use apks for the initramfs or whatever it is he is doing 2017-04-03 19:51:17 essentially my proposition would be, for this situation: 2017-04-03 19:51:23 use .apks and get all the checksum/validation stuff you're working on 2017-04-03 19:51:24 kaniini: What it supports now is changing to the build directory and running make install (or zinstall) , make modules_install, make firmware_install, and make dtbs_install. 2017-04-03 19:51:26 use folders and don't 2017-04-03 19:51:56 Shiz: At the moment, apks actually don't make life easy to verify any of the kernel files. 2017-04-03 19:52:26 Shiz: You can't verify the checksums because they're not installed by apk and thus not in the database. 2017-04-03 19:52:34 anyway, abuild isn't really that heavy of a dependency. 2017-04-03 19:52:50 well... why are they not installed by apk 2017-04-03 19:52:52 Shiz: And extracting the checksums from apks is much more difficult than one might hope. 2017-04-03 19:53:26 Shiz: Because they get staged, then coppied. 2017-04-03 19:53:37 what shiz is saying is 2017-04-03 19:53:39 why not just use apk 2017-04-03 19:53:43 to unpack the apks 2017-04-03 19:53:47 thus making them installed 2017-04-03 19:53:49 into your initramfs image 2017-04-03 19:53:50 yes ^ 2017-04-03 19:53:51 kaniini: Because currently, we CAN'T 2017-04-03 19:53:53 apk --root 2017-04-03 19:53:55 it exists 2017-04-03 19:54:26 do i really have to code an initramfs generator to demonstrate this 2017-04-03 19:54:36 TemptorSent: why not? 2017-04-03 19:54:39 Shiz: Yeah, too bad that doesn't work when you're trying to verify a file installed elsewhere. 2017-04-03 19:54:41 just trying to understand the situation 2017-04-03 19:55:01 elsewhere? 2017-04-03 19:55:25 Shiz: The initramfs is made up of files that are pulled from whatever base directory is specified, with no idea what APKs they may relate to. 2017-04-03 19:55:33 yes 2017-04-03 19:55:35 what we are saying is 2017-04-03 19:55:40 right, so why don't we change that 2017-04-03 19:55:42 why don't you just generate some APKs 2017-04-03 19:55:47 and embed them 2017-04-03 19:55:49 into the initramfs 2017-04-03 19:55:52 e.g., very simply put 2017-04-03 19:55:59 and on top of that 2017-04-03 19:56:06 why couldn't we re-architecture mkinitfs to take an (eventual) list of apk package names and folders 2017-04-03 19:56:07 kaniini: That's what my whole proposal regarding init was! 2017-04-03 19:56:08 we could you know, generate some APKs as part of the archive itself 2017-04-03 19:56:22 i don't even think we need to generate new apks 2017-04-03 19:56:24 then what the hell is all of this highly complex stuff 2017-04-03 19:56:25 for that 2017-04-03 19:56:36 i mean 2017-04-03 19:56:37 Shiz: to slim them down 2017-04-03 19:56:44 we could even extend the current mkinitfs 2017-04-03 19:56:45 Shiz: like udeb vs deb 2017-04-03 19:56:51 to take a new kind of features.d entry called .packages 2017-04-03 19:56:55 e.g. zfs.packages 2017-04-03 19:57:01 and handle those through apk 2017-04-03 19:57:04 in that case 2017-04-03 19:57:04 kaniini: Supporting existing configurations so I don't get drawn and quarted when everything breaks with a new update-kernel script! 2017-04-03 19:57:23 update-kernel is an alpine tool 2017-04-03 19:57:25 Shiz: All of that has already been reimplemented. 2017-04-03 19:57:31 if it breaks for somebody who is doing things in an unexpected way 2017-04-03 19:57:36 then that's on them 2017-04-03 19:57:38 kaniini: Yeah, have you looked at it yet? 2017-04-03 19:57:52 why do i need to look at it 2017-04-03 19:57:58 TemptorSent: btw not trying to disparage your work or anything 2017-04-03 19:58:02 just trying to understand it 2017-04-03 19:58:06 kaniini: Because the mess is the interaction between update-kernel and mkinitfs. 2017-04-03 19:58:37 i still do not understand why you would use update-kernel or mkinitfs with a custom build that isn't also managed by apk 2017-04-03 19:58:38 Shiz: Take a look in the root of my branch -- there are a couple of README files. 2017-04-03 19:58:46 url? 2017-04-03 19:59:05 kaniini: Because you may only need to custom-build one set of modules for your custom-hardware! 2017-04-03 19:59:37 Shiz: https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage 2017-04-03 20:00:47 kaniini: Or you may be building the stock -grsec kernel with a few added patches and everything else from the main dist, including the modules. 2017-04-03 20:01:02 see your second example is stupid 2017-04-03 20:01:07 because if you're doing that 2017-04-03 20:01:12 you would probably just make a copy of it out of aports 2017-04-03 20:01:18 and build it the alpine way 2017-04-03 20:01:28 the second example is also flawed 2017-04-03 20:01:39 you should not use kernels and modules build using different source trees or configs 2017-04-03 20:01:44 it is not guaranteed to work 2017-04-03 20:02:23 Shiz: Of course not, but I can think of plenty of perfectly valid use cases, including building in your own keys for runnign on a secboot config. 2017-04-03 20:02:40 which is a different config 2017-04-03 20:02:50 and secure boot is not handled in the linux kernel, but in the bios 2017-04-03 20:03:07 Shiz: The kernel must have the keys to validate the modules. 2017-04-03 20:03:12 Shiz: not exactly 2017-04-03 20:03:16 point being, imo if you're building your own kernel, do not rely on distro kernel packages 2017-04-03 20:03:22 TemptorSent: that's not secue boot, just module signing 2017-04-03 20:03:33 Shiz: So if you want to use custom modules, you have to build in the keys for them. 2017-04-03 20:03:37 Shiz: if secure boot is requested, you are supposed to go all the way down 2017-04-03 20:03:42 Shiz: module signing, etc 2017-04-03 20:03:43 kaniini: 'supposed to' 2017-04-03 20:03:45 p 2017-04-03 20:03:47 :p 2017-04-03 20:03:50 Shiz: it's required by the spec. 2017-04-03 20:04:08 anyway, again 2017-04-03 20:04:13 Shiz: if we would like our bootloader signed, we have to agree to follow the spec 2017-04-03 20:04:15 using a custom kernel but distro kernel module packages 2017-04-03 20:04:17 is a bad idea 2017-04-03 20:04:19 imo 2017-04-03 20:04:27 yes 2017-04-03 20:04:28 Shiz: Point is, adding keys to a kernel would require building it. 2017-04-03 20:04:28 kaniini: good thing we don't, as far as I know 2017-04-03 20:04:33 this is what i have been saying for the past hour 2017-04-03 20:04:44 kaniini: well i don't consider mkinitfs a distro kernel package 2017-04-03 20:04:46 just the modules files 2017-04-03 20:04:51 so there may be some difference there 2017-04-03 20:04:53 :p 2017-04-03 20:05:06 Shiz: EFI secure boot support is something we actually do desire 2017-04-03 20:05:33 I'm just trying to put the required information in place so we can act on it when we get there. 2017-04-03 20:06:02 as iPXE has stated: http://ipxe.org/appnote/etoken#waiting 2017-04-03 20:06:03 :p 2017-04-03 20:06:06 Like knowing which apk we need to check the signature on to verify that we in fact have the right file in our boot. 2017-04-03 20:07:28 i also don't really see how you aim to guarantee mkinitfs integrity from within mkinitfs 2017-04-03 20:07:31 err 2017-04-03 20:07:37 s/mkinitfs/initramfs/g 2017-04-03 20:07:38 Also, we don't need M$'s tokens for secure boot, we can install our own. 2017-04-03 20:07:53 surely if i can compromise the initramfs i can patch out your /init or apk code that checks sigs 2017-04-03 20:07:59 Shiz: The stub would live in the kernel, baked in 2017-04-03 20:08:17 okay, same thing 2017-04-03 20:08:19 Shiz: Which includes apk.static and busybox.static. 2017-04-03 20:08:21 if i can compromise your initramfs 2017-04-03 20:08:25 i can also very likely compromise your kernel 2017-04-03 20:08:32 since they're 99.9% of the time stored together 2017-04-03 20:08:41 TemptorSent: it is desirable to have release media signed in such a way that it "just works" (tm) 2017-04-03 20:08:41 Shiz: It's the payload of the initramfs that's the issue. 2017-04-03 20:09:00 kaniini: Agreed, but it's not required for the featuer to be useful. 2017-04-03 20:09:24 i don't fully understand your threat model i guess 2017-04-03 20:09:38 my idea is that everything that would lead to the need to check initramfs integrity also trivially leads to kernel compromise 2017-04-03 20:09:46 which means checking the integrity is useless from within the initramfs 2017-04-03 20:09:54 baked-in or not 2017-04-03 20:09:56 Shiz: You can add anythign you want by appending it to the end of a cpio and the kernel will keep reading it. 2017-04-03 20:10:05 yes, and? 2017-04-03 20:10:08 if i can append, i can modify 2017-04-03 20:10:12 if i can modify, i can pwn your kernel 2017-04-03 20:10:14 :p 2017-04-03 20:10:31 initramfs integrity is useless if i can just run my botnet in your ring0 2017-04-03 20:10:36 Shiz: So the attack just has to keep spitting out data without having to alter anythign in line. 2017-04-03 20:10:38 and if the bootloader just checks the checksum of the initramfs (i.e. signatures), then none of this is needed 2017-04-03 20:10:58 TemptorSent: this distinction is not meaningful in any real world scenario that i know of, though 2017-04-03 20:11:09 the way it should be is 2017-04-03 20:11:12 Shiz: netcat :) 2017-04-03 20:11:19 bios checks bootloader, bootloader checks kernel and initramfs 2017-04-03 20:11:22 what about it? 2017-04-03 20:11:27 netcat is just tcp 2017-04-03 20:11:30 initramfs checks real /sbin/init 2017-04-03 20:11:34 if i can add data to your tcp connection, i've intercepted it in the first place 2017-04-03 20:11:38 meaning i can also just rewrite data 2017-04-03 20:12:00 Shiz: Say you're tftp booting, and someone spits a bunch of crap out to the end of the stream. 2017-04-03 20:12:13 it doesn't work like that, though 2017-04-03 20:12:13 unless you mean 2017-04-03 20:12:29 Shiz: tftp is very easy to spoof. 2017-04-03 20:12:32 yes 2017-04-03 20:12:35 it is very easy to spoof 2017-04-03 20:12:41 very easy to just modify packets too 2017-04-03 20:12:45 you don't need appending for it 2017-04-03 20:12:47 Shiz: So everything looks fine. 2017-04-03 20:12:57 again, the difference between appending and modifying is not meaningful here 2017-04-03 20:13:05 Shiz: The files all look right, etc on inspectino 2017-04-03 20:13:09 they are all trivially doable 2017-04-03 20:13:15 and if i can modify the files, i can compromise your kernel 2017-04-03 20:13:29 rendering the entire integrity check useless 2017-04-03 20:13:47 which is why the bootloader has to be responsible for verifying it 2017-04-03 20:13:53 yes 2017-04-03 20:13:58 not the initramfs itself 2017-04-03 20:14:00 Shiz: The kernel has signature ability. 2017-04-03 20:14:20 that's not good enough 2017-04-03 20:14:25 yes, which i'll gladly patch out if i can modify the kernel 2017-04-03 20:14:27 because we can boot a kernel with that patched out 2017-04-03 20:14:27 now what? 2017-04-03 20:15:16 Forget it. Apparently there is no point in making life hard for script kiddie.s 2017-04-03 20:15:47 i think a script kiddie would rather just replace the entire kernel immediately 2017-04-03 20:15:50 instead of doing weird append tricks 2017-04-03 20:16:22 security has a cost, and i don't mean just technical cost by that 2017-04-03 20:16:38 it has a social cost 2017-04-03 20:16:38 Shiz: Replacing the entire kernel tends not to work if you do sane things with your bootloader to at least look at a checksum 2017-04-03 20:16:46 not true 2017-04-03 20:16:53 checksums are trivially brutable 2017-04-03 20:17:09 if your bootloader is checking signatures 2017-04-03 20:17:11 then it is fine 2017-04-03 20:17:12 and if you look at a checksum, appending's not gonna work either 2017-04-03 20:17:20 (continuing from where I left...) 2017-04-03 20:17:33 security has a social cost because if we add an integrity check like this which is not actually secure 2017-04-03 20:17:36 but people THINK they are secure 2017-04-03 20:17:42 they may forego more effective security measures 2017-04-03 20:17:46 it means those people eventually die 2017-04-03 20:17:47 the only thing worse than no security is false security 2017-04-03 20:17:48 Shiz: That's the problem with the way the kernel reads, you can have the checksumed data exactly the same, then append to that and the kernel reads it transparently. 2017-04-03 20:18:00 TemptorSent: you just said your bootloader 2017-04-03 20:18:01 because the NSA got an implant on their machine 2017-04-03 20:18:04 and the cruise missile is on the way 2017-04-03 20:18:08 which is what iw as talking about 2017-04-03 20:18:23 also 2017-04-03 20:18:25 Shiz: iPXE for instance. 2017-04-03 20:18:33 believe me, i know plenty about ipxe 2017-04-03 20:18:44 if you checksum your kernel, you also checksum your initramfs 2017-04-03 20:18:44 ipxe can check signatures 2017-04-03 20:18:50 in which case appending/modification wouldn't work either 2017-04-03 20:18:57 and yes, ipxe can check asymmetric signatures 2017-04-03 20:19:00 i have that working in production actually 2017-04-03 20:19:02 :p 2017-04-03 20:19:25 Shiz: I believe that you can still get the kernel to swallow additional append data. 2017-04-03 20:19:39 as in, what? 2017-04-03 20:19:48 you can not 2017-04-03 20:19:49 kernel foo 2017-04-03 20:19:49 append bar 2017-04-03 20:19:50 append evilbar 2017-04-03 20:19:51 ? 2017-04-03 20:19:55 Shiz: It's a broken part of the kernel's loading that it keeps processing cpio data until the data stream ends. 2017-04-03 20:19:56 nothing that the bootloader can't check anyway 2017-04-03 20:20:05 TemptorSent: just like how the bootloader checks checksums 2017-04-03 20:20:08 so? 2017-04-03 20:20:19 i'd be very afraid if my bootloader did cpio parsing 2017-04-03 20:20:20 :p 2017-04-03 20:20:52 Shiz: All the bootloader does is appends them all together and hands it to the kernel. 2017-04-03 20:21:09 i think you're getting lost in your own argument 2017-04-03 20:21:16 you claim you can prevent kernel modifications by checking the checksum 2017-04-03 20:21:24 to which i say 'you can also check the initramfs checksum' 2017-04-03 20:21:27 (in the bootloader) 2017-04-03 20:21:44 how does that statement oppose that? 2017-04-03 20:21:52 Shiz the CONTENTS of the initramfs are my concern, since the checksum says nothign about the origin of those files 2017-04-03 20:22:10 Shiz: So I can't go back to something signed and verify them. 2017-04-03 20:22:12 indeed, a checksum is rather useless 2017-04-03 20:22:18 Shiz: Which I CAN do for the kernel 2017-04-03 20:22:24 how? 2017-04-03 20:22:41 you can just as simply make asymmetric signatures over the initramfs 2017-04-03 20:22:46 that's what i'm doing right now in production 2017-04-03 20:22:51 Shiz: Because that is actually installed by apk and tracked IIRC. 2017-04-03 20:22:59 but you don't get it 2017-04-03 20:23:15 Shiz: Where do the files in your initramfs COME from? 2017-04-03 20:23:31 me, which is verified by the asymmetric signature over htem 2017-04-03 20:23:45 TemptorSent: once update-kernel signs the initramfs image, it is surely good enough no? 2017-04-03 20:23:56 Shiz: That is currently the problem, it is built from files of unknown origin with no signaures or checksums. 2017-04-03 20:24:07 no it's not 2017-04-03 20:24:11 yes, but you don't get my point 2017-04-03 20:24:12 it's built from files on your machine 2017-04-03 20:24:26 the kernel is not the tiniest bit safer than your initramfs 2017-04-03 20:24:39 i can modify your kernel file and you won't notice 2017-04-03 20:24:45 sure, # apk upgrade will replace it, so what? 2017-04-03 20:24:53 apk doesn't checksum and verify your system every time it's ran 2017-04-03 20:24:56 Shiz: Will it match the sums when I go to install it? 2017-04-03 20:25:11 install what? 2017-04-03 20:25:14 it's already on your disk 2017-04-03 20:25:28 and if you mean i can compromise the channel between you and your repos, yes 2017-04-03 20:25:37 but that won't help me compromise the mkinitramfs either 2017-04-03 20:25:42 since it's built locally on your machine 2017-04-03 20:26:14 Shiz: I'm trying to ensure all files in the initramfs actually came from known sources so I can verify what's on the tftp server isn't tampered with! 2017-04-03 20:26:25 but you can't 2017-04-03 20:26:34 because the thing that verifies it is just as easily compromised as the thing it's verifying 2017-04-03 20:26:35 actually, 2017-04-03 20:26:38 it's fundamentally not real security 2017-04-03 20:26:49 the channel between you and your repos 2017-04-03 20:26:50 would fail to be compromised 2017-04-03 20:26:54 as checksum mismatch :P 2017-04-03 20:26:56 Shiz: Why not? I have a manifest of all included files, the apks they came with, and the versions. 2017-04-03 20:27:05 TemptorSent: "what is checking it"? 2017-04-03 20:27:10 the kernel booting? 2017-04-03 20:27:18 too bad, i can compromise that just as easily 2017-04-03 20:27:23 same goes for the initramfs stub in the kernel 2017-04-03 20:28:23 Does nobody do what I used to do 25 bloody years ago and actually store a manifest of checksums offline to verify against? 2017-04-03 20:28:46 if you do that, why not do the same for the initramfs in the first place? 2017-04-03 20:29:02 How the hell do you verify your system if you don't have any idea of what you put there. 2017-04-03 20:29:12 you use signatures 2017-04-03 20:29:20 and have your bootloader check whatever it's loading 2017-04-03 20:29:27 (like iPXE) 2017-04-03 20:29:54 Shiz: That's what I'm trying to accomplish - a set of manifests that can relate a file back to its original -SIGNED- source. 2017-04-03 20:30:14 so... 2017-04-03 20:30:25 While still allowing people to only include the features they actually need in their initfs. 2017-04-03 20:30:47 you're re-implementing # openssl cms? 2017-04-03 20:31:06 i'm still not sure how this helps 2017-04-03 20:31:11 why not sign the generated file instead 2017-04-03 20:31:15 So if we have a stub that only loads signed files, and we load it with a signed kernel, we can be sure we have at least the same files we put there. 2017-04-03 20:31:40 yes but 2017-04-03 20:31:48 if you have a signed kernel that you can verify is signed by the bootloader 2017-04-03 20:31:53 that very same bootloader can also verify the initramfs 2017-04-03 20:32:03 which is my point... 2017-04-03 20:32:04 Shiz: because then we have to either build, sign, and distribute every permutation of initramfs, or we have to have the user have a secure keychain and sign them himself every time. 2017-04-03 20:32:33 Shiz: So how do you make an initramfs with say zfs modules included? 2017-04-03 20:32:57 (and userspace files, which is actually the real issue, as modules can be signed) 2017-04-03 20:34:12 mkinitfs ; openssl cms -sign -binary -noattr -signer file.crt -inkey file.key -in initramfs -out initramfs.sig 2017-04-03 20:34:33 I want to be able to append a cpio with the the "initfs-fs-zfs-0.6.5.9-r0^4.9.19-0-grsec.apk" and have zfs support 2017-04-03 20:34:48 remove the sig, append, re-sign it 2017-04-03 20:34:58 Shiz: I was already shot for expecting users to create their own keys. 2017-04-03 20:35:07 just use checksums to verify the initramfs 2017-04-03 20:35:13 it is allowed by secure boot spec 2017-04-03 20:35:33 kaniini: Where do you get the list of checksums? 2017-04-03 20:35:49 inside the config file for the bootloader 2017-04-03 20:36:06 (...and this is coming right back to exactly what I'm trying to implement, namely manifests with checksums) 2017-04-03 20:36:42 kaniini: That's where you PUT the list of checksums, I'm trying to solve where you GET them and how you make sure those files match the ones that came out of your original package. 2017-04-03 20:36:47 sign it using the host key inside the system TPM 2017-04-03 20:36:56 i dont know what to tell you 2017-04-03 20:37:02 you get them by generating them? 2017-04-03 20:37:12 i know that this is a solved problem, it may be worthwhile to look at fedora or similar 2017-04-03 20:37:25 Shiz: The apks already contain SHA1 checksums in the pax headers of the apks. 2017-04-03 20:37:29 and? 2017-04-03 20:37:32 who cares 2017-04-03 20:38:06 you get the checksum by generating it when building the initramfs 2017-04-03 20:38:09 of the entire initramfs file 2017-04-03 20:38:11 I just don't understand why I'm getting killed for wanting to generate manifests of files installed in ways APK doesnt' track. 2017-04-03 20:38:27 Shiz: Please look at how mkinitfs works. 2017-04-03 20:38:29 because it seems useless 2017-04-03 20:38:37 https://bentley.link/secureboot/ 2017-04-03 20:38:38 we aren't discussing how mkinitfs works right now though 2017-04-03 20:38:46 we're discussing how we want it to work in the future 2017-04-03 20:38:48 Shiz: mkinitfs knows nothing about the source of its files. 2017-04-03 20:38:52 and that's fine 2017-04-03 20:38:57 it's literally not relevant 2017-04-03 20:39:16 Shiz: You are far more trusting than I then. 2017-04-03 20:39:22 no, not really 2017-04-03 20:39:26 i just know how to threat model 2017-04-03 20:39:27 :p 2017-04-03 20:39:30 if i can put untrusted files on your rootfs 2017-04-03 20:39:35 i can add my keys to your /etc/apk/keys folder 2017-04-03 20:39:41 and have you install my pwned 2017-04-03 20:39:50 Shiz: I want to know that the files I install haven't been modified since they were unpacked from signed distfiles 2017-04-03 20:39:56 you will always have to trust the node that generates the mkinitfs 2017-04-03 20:40:18 TemptorSent: then run # apk verify before you generate 2017-04-03 20:41:01 Shiz: That's what I'm doing. 2017-04-03 20:41:04 i mean, i'm unclear WHERE do you want to check this 2017-04-03 20:41:36 on the node that booted the initramfs? if that got fucked with ,that node's already compromised 2017-04-03 20:41:44 Shiz: I don't want it to be able to pull a file from the filesystem that may be modified without the user being aware of it. 2017-04-03 20:41:47 on the nod ethat generates the initramfs? # apk verify 2017-04-03 20:42:05 then i don't see why you need anything but # apk verify 2017-04-03 20:42:11 Shiz: The contents of mkinitfs don't come out of apks currently 2017-04-03 20:42:18 doesn't matter 2017-04-03 20:42:22 they come from the root filesystem 2017-04-03 20:42:26 which is verified with # apk verify 2017-04-03 20:42:55 Shiz: It doesn't work quite that way. 2017-04-03 20:43:31 Shiz: The problem is it's fed a glob pattern, which you can't exactly apkverify 2017-04-03 20:43:47 Shiz: Which is the problem I'm solving by creating the manifests. 2017-04-03 20:44:07 You glob against the manifest, not the filesystem. 2017-04-03 20:44:08 but.. you can? 2017-04-03 20:44:19 # apk verify $(find / -name $glob) 2017-04-03 20:44:35 Shiz: Try it, let me know what you get :) 2017-04-03 20:45:32 And we're talking more than one or two globs in many cases. 2017-04-03 20:46:05 something that tells me there is likely a bug in # apk verify that should be fixed? 2017-04-03 20:46:09 And still, that leaves you with files you can't track after the fact. 2017-04-03 20:46:23 Actually, I think you want audit :) 2017-04-03 20:46:29 verify only checks the .apk 2017-04-03 20:46:49 But the problem is the way audit stores it's information. 2017-04-03 20:47:31 It can't tell you if an arbitrary file matches it's original, only if a given file at a given install path has been modified. 2017-04-03 20:47:49 but that's the same question, no? 2017-04-03 20:47:55 So you can't verify individual files out of context. 2017-04-03 20:47:58 apk audit | cut -d' ' -f2- | grep myfilepath 2017-04-03 20:48:13 (this is where you can apply the glob too) 2017-04-03 20:48:37 or without the cut: apk audit -q | grep myfilepath 2017-04-03 20:48:56 since the files are being taken from the rootfs in the first place 2017-04-03 20:49:35 Shiz: Okay, now how do we check that after the fact? 2017-04-03 20:49:52 from where? 2017-04-03 20:50:17 Shiz: So once some file has been copied elsewhere, we still know where it came from? 2017-04-03 20:50:30 no, but i doubt the necessity of that 2017-04-03 20:50:45 Shiz: Then how do you go back and do a verification? 2017-04-03 20:50:53 you answer my question first 2017-04-03 20:51:01 Shiz: You basically have no further information at that pont to work with. 2017-04-03 20:52:05 Shiz: The simplest case is just simply detecting corrupt transfers. 2017-04-03 20:52:15 that wasn't my question 2017-04-03 20:52:21 my question was 'from where' 2017-04-03 20:52:34 Verified from where or copied from where? 2017-04-03 20:52:41 verified 2017-04-03 20:53:04 From either the running system or from an external audit. 2017-04-03 20:54:04 verifying from the running system is rather useless, as it has already been compromised if the initramfs is borked 2017-04-03 20:54:19 From within the running system it at least gives you reasonable ability to determine if you're running your expected config. 2017-04-03 20:54:21 verifying from external audit, why does it matter where the individual files came from if you can simply check the entire initramfs sig? 2017-04-03 20:54:46 Shiz: Because knowing WHAT changed is important. 2017-04-03 20:56:18 Shiz: And again, if we want to allow users to load only what they want in the initramfs without having them have to create and secure keys, we need a means of adding arbitrary content to the initramfs, but only loadign that which matches our keys. 2017-04-03 20:57:58 Shiz: So if we need to extract say /usr/sbin/zpool and /usr/sbin/zfs from the zfs package to install in the initramfs, it would be much more useful to have a signed manifest to include than requiring the entire zfs apk to be included! 2017-04-03 20:58:40 Or, at the very least, a reference to the signed apk that can be used to verify the checksums after the fact if needed. 2017-04-03 21:00:10 Shiz: Ideally, the next APK version would support signed manifests directly :) 2017-04-03 21:00:54 The pax headers are a cool idea, but are very hard to use for anything but verifying the apk itself. 2017-04-03 21:01:19 The information that audit runs against is not signed in any way IIRC. 2017-04-03 21:01:42 So we end up having to trust something that we can't verify without downloading every single apk on the system. 2017-04-03 21:01:56 ...and that's the issue I'm trying to fix. 2017-04-03 21:02:41 Or at least reduce in scope to checking a manifest to find which apk we need in order to verify. 2017-04-03 21:03:26 And being able to distinguish two versions of the same file by their checksum. 2017-04-03 21:05:01 For verification purposes, every file on the system should be able to be traced back to its point of origin and those signatures checked against a RO keychain. 2017-04-03 21:07:37 It's not just a matter of runtime security, but largely one of enabling forensics and mitigation. 2017-04-03 21:09:54 This is ESPECIALLY important if an upstream package is ever comprimised, as it gives us a fingerprint we can use to send revocation certificates against (ideally, packages would get signed with their own key which is in turn signed by the alpine key so we could blacklist individual builds if they get comprimised. 2017-04-03 21:14:33 Shiz: I've spent a lot of time doing forensic analysis after systems have been attacked, sometimes successfully, and sometimes not. The hardest thing to do is figure out what, if anything, was altered, and HOW. 2017-04-03 21:27:04 Okay, concrete example using iPXE: The kernel is a stock kernel, verified against the alpine keys from a WKS, the mkinitfs image itself is user-generated, requiring either that the user sign the image and upload the signature to a keyserver, or that untrusted initrd images be allowed by iPXE and the init stub in the verified kernel verifys the contents of anything appended. 2017-04-03 21:30:07 (in ipxe script) kernel http://untrusted.com/vmlinuz && imgverify vmlinuz https://trusted.com/keys/vmlinuz.sig && boot vmlinuz 2017-04-03 21:30:51 With that, and the rest as-is, we can have at least a mostly-trusted boot if you trust your pxe flash. 2017-04-03 21:32:54 Can we agree that given that, and a stub which verifies the contents of the initramfs, we have a boot that's at least as trustworthy as our pxe rom and the signatures? 2017-04-03 21:34:51 And that that would eliminate a lot of low-hanging fruit for exploits which can alter data in-flight, but non-transparently? 2017-04-03 21:35:55 As well as provide a much better framework for auditing and forensics than having files with no information tracked? 2017-04-03 21:43:37 sorry, i was kinda busy with stuff 2017-04-03 21:43:50 i'll read the scrollback in a bit 2017-04-04 00:22:38 tweet: How to easily compile C/C++ to asmjs using emscripten and AlpineLinux on Travis CI. Build time: 1min+. https://github.com/jirutka/emscripten-travis-example 2017-04-04 00:22:54 https://twitter.com/jakubjirutka/status/849054307680911364 2017-04-04 00:25:19 jirutka: nice 2017-04-04 00:29:27 actually I just wanted to compile script in Lua to asm.js… this is one of the side effects :) (no, I’m not bored, just insane…) 2017-04-04 02:05:01 Anyone get MESA-LOADER: could not create udev device for fd 4 when running glxgears? 2017-04-04 04:39:05 Is it intentional for 'apk search -x linux-grsec-4.9.19-r0' to fail while 'apk search -x linux-grsec' returns 'linux-grsec-4.9.19-r0'? 2017-04-04 04:40:07 It seems broken for 'exact' to fail to return the same match when supplied with the EXACT version it returns given just the package name. 2017-04-04 12:36:38 anyone tried to get a py-gst1 APKBUILD? or is there someone who maintains gstreamer1? i try to create a py-gst1 package built. it builds fine but running mopidy doesnt work because of "GstPbutils" is missing 2017-04-04 13:25:35 i pushed xorg 1.19 2017-04-04 13:25:39 hold on to your hats 2017-04-04 13:32:47 hmm 2017-04-04 13:32:57 i should try to update the opensmtpd package 2017-04-04 13:59:55 hmm 2017-04-04 14:00:03 anyone familiar with autoconf? 2017-04-04 14:00:15 I'm getting AC_CHECK_DECLS to #define the relevant config.h entry to 0 instead of undefining it 2017-04-04 14:00:17 is that expected? 2017-04-04 14:00:24 (the package in question checks with #ifdef...) 2017-04-04 14:02:18 okay, seems like it's expected to be defined to 0 2017-04-04 14:54:02 TemptorSent: apk search only searches the package name part. 2017-04-04 16:11:51 would it be useful to add a new field in APKBUILD called something like "source_mirror" or "source2", that will contain a different URL for the same source package, acting as a mirror? 2017-04-04 16:12:18 if the $source URL is down for any motivation, then, apk will use the mirror URL to grab the package. 2017-04-04 16:12:40 I think this will make the builds more reproducible. 2017-04-04 16:12:48 Any comments on this proposal? 2017-04-04 16:17:01 kaniini: Is that behaviour something that might be changed? It's unintuitive to get no match when searching for a full package name that is the same it returns on the short name. 2017-04-04 16:17:22 TemptorSent: it has always worked that way 2017-04-04 16:17:40 leitao: i agree 2017-04-04 16:19:13 kaniini: Does that mean that you think it should remain unchanged? 2017-04-04 16:19:49 TemptorSent: no i think being able to search for full package atom makes sense 2017-04-04 16:21:51 kaniini: Okay, good -- it just seems saner :) 2017-04-04 16:22:50 I'm wondering if that was intentional behaviour, or an artifact. 2017-04-04 16:23:31 leitao: i think you can set DISTFILES_MIRROR in /etc/abuild.conf 2017-04-04 16:23:49 which is a mirror for all of the packages 2017-04-04 16:24:00 eg. http://disfiles.alpinelinux.org 2017-04-04 16:24:39 ncopa, cool 2017-04-04 16:26:13 <^7heo> pickfire: I remove some of my comments on your PR; since they were redundant noise. Feel free to remove your comments as well where applicable, so it makes a smaller review :) 2017-04-04 16:26:23 <^7heo> ncopa: have you seen my work on mkinitfs? 2017-04-04 16:26:35 ncopa: RE search -x behaviour... Was it intentional to only match on the package name and not the full atom? 2017-04-04 19:21:34 leitao: I don’t think that adding another source url would be really useful 2017-04-04 19:22:14 leitao: for example in the case of LuaXML it would not work at all, b/c tarball from GitHub has different checksum 2017-04-04 19:22:38 jirutka, right, I was planning originally to point to the exact some package (same checksum) 2017-04-04 19:22:39 kaniini: ^ 2017-04-04 19:23:33 leitao: kaniini: ncopa: what will be useful is to save all sources on our servers, that’s what other distros do… but it would require a lot of space… 2017-04-04 19:24:08 jirutka there is already distfiles.alpinelinux.org 2017-04-04 19:24:10 leitao: kaniini: ncopa: we already do this, but only for snapshots 2017-04-04 19:24:18 kaniini: I know 2017-04-04 19:24:52 kaniini: maybe it’d be useful to add some simple flag that certain source file should be cached on distfiles 2017-04-04 19:25:23 kaniini: so we can use it for “unreliable” upstreams 2017-04-04 19:25:43 that is what i'm thinking yeah 2017-04-04 19:27:15 kaniini: sadly, that’s basically every upstream hosted on very own site that may vanish anytime, instead of on GH, Savannah, Gnome etc. 2017-04-04 19:28:10 kaniini: so maybe another option is to create a “blacklist” of sites that are not needed to be cached and cache everything not on this list 2017-04-04 19:28:22 distfiles.dereferenced.org has nearly 6 years uptime :) 2017-04-04 19:28:35 kaniini: nice! 2017-04-04 19:29:22 as in it hasn't been down in 6 years 2017-04-04 19:29:37 but i cheat there is a load balancer 2017-04-04 19:30:26 kaniini: it was just a rule of thumb, ofc not every upstream not hosted on some big service is unreliable; and I’m the last person saying that everything should be hosted on some big third-party service, but the reality is that I’ve never seen tarball vanished on GH or even SourceForge 2017-04-04 19:31:06 Query - is anyone aware of any out-of-tree DTBS? 2017-04-04 19:31:07 kaniini: also there are dumb upstreams that remove old versions 2017-04-04 19:32:16 Or should I say hardware which requires out of tree DTBS. 2017-04-04 20:37:37 please note that this http://patchwork.alpinelinux.org/patch/3244/ is NOT the correct solution and it should not be merged 2017-04-04 20:38:01 I think that it actually can’t even work 2017-04-04 21:11:06 any volunteer to clean the current mess with php5/php7? 2017-04-04 21:12:50 jirutka: Does a flamethrower qualify as a solution? 2017-04-04 21:13:11 TemptorSent: unfortunately it does not :( 2017-04-04 21:13:26 TemptorSent: but it’s my preferred solution too, but we can’t do that 2017-04-04 21:13:28 Oh well, had to try ;) 2017-04-04 21:14:03 I think I already have enough brick walls to bash down with my forehead for the moment, thanks. 2017-04-04 21:29:11 jirutka: is it okay to just drop php5? :) 2017-04-04 21:29:27 kaniini: hmm, that would be a solution 2017-04-04 21:29:44 kaniini: but I can’t decide that 2017-04-04 21:29:45 i'm skeptical that it will continue to receive security updates 2017-04-04 21:30:02 kaniini: http://php.net/supported-versions.php 2017-04-04 21:30:16 i agree, it is not really appropriate for me to make that decision as i do not use php at all 2017-04-04 21:31:04 jirutka: yes, but wheher or not they actually follow through is debatable 2017-04-04 21:31:12 kaniini: I have to use PHP for some stuff, but otherwise trying to avoid it as possible 2017-04-04 21:31:33 kaniini: it’s PHP, security holes are a feature, not a bug ;) 2017-04-04 21:31:44 right 2017-04-04 21:31:57 anyway i lean toward dropping php 5 2017-04-04 21:31:58 but 2017-04-04 21:32:05 maybe that isn't a good change for 3.6 2017-04-04 21:33:13 kaniini: let’s ask ncopa, clandmeter, fabled and andy 2017-04-04 21:33:57 that seems reasonable considering they all work with php stuff :) 2017-04-04 22:40:41 woo 2017-04-04 22:40:45 ACTION just packaged opensmtpd-extras 2017-04-04 22:41:16 anyone care to take a look at my apkbuild to see if what i'm doing is not overly crossing the line? 2017-04-04 22:41:24 (took some inspiration from the php5 apkbuild) 2017-04-04 22:46:39 Shiz: I hope that you’re kidding that you took inspiration from php5 abuild… 2017-04-04 22:46:51 i'm not 2017-04-04 22:46:56 Shiz: I don’t see your PR…? 2017-04-04 22:47:05 haven't posted it yet, 1sec 2017-04-04 22:47:06 :p 2017-04-04 22:56:39 pushing now 2017-04-04 23:04:42 jirutka: https://github.com/alpinelinux/aports/pull/1206 2017-04-04 23:06:37 php5 was really a very bad choice for inspiration… 2017-04-04 23:06:57 well, it is a package which is really a bunch of subpackages 2017-04-04 23:07:02 this seemed the most reasonable approach 2017-04-04 23:10:54 what do all these new pr labels mean? 2017-04-04 23:11:34 btw, probably less controversial: https://github.com/alpinelinux/aports/pull/1205 2017-04-04 23:11:36 :p 2017-04-04 23:31:33 clandmeter: just to categorize PRs, to make it easier to locate PRs that needs some attention or these which you want to review based on your skills 2017-04-04 23:32:15 clandmeter: I’m gonna write a simple bot to automatically assign these labels based on content of the PR 2017-04-04 23:38:41 clandmeter: I’ve created these labels in few minutes, but can’t figure out some sane coloring for them :( that’s why most of the new labels are just gray 2017-04-04 23:48:48 clandmeter: C stands for category, P for priority, S for status, T for type (or something like that); it’s inspired from Rust repository 2017-04-05 00:01:41 whats the difference between category and type? 2017-04-05 00:04:25 Shiz: category is something like type of aport, currently based on language: lua, ruby, python, c, … 2017-04-05 00:04:36 weird 2017-04-05 00:04:46 Shiz: type is type of the changed: adding new aport, upgrading aport, … 2017-04-05 00:04:58 Shiz: maybe it’d be better to rename type to action, not sure 2017-04-05 00:05:15 seems better 2017-04-05 00:05:28 i'd reuse category for main/testing/community personally 2017-04-05 00:05:35 the language seems soemwhat... irrelevant 2017-04-05 00:05:49 it’s not irrelevant for reviewers 2017-04-05 00:06:44 we have ppl with higher experience wirth some langs/platforms and ppl with averse towards some langs/platforms 2017-04-05 00:08:24 this can be used even to auto-suggest reviewer in future; currently we do this manually, for example when I see some Go stuff, I just cc ^7heo 2017-04-05 00:08:41 for php I usually cc Andy 2017-04-05 00:09:10 for haskell mitchty 2017-04-05 00:09:12 and so on 2017-04-05 00:10:20 <^7heo> funny thing is I actually dislike Go 2017-04-05 00:10:22 <^7heo> :p 2017-04-05 00:10:28 about repositories, currently it’s not important if it’s main or community, but it’s quite important if it’s main/community or testing 2017-04-05 00:11:53 ^7heo: well, but you are/were willing to deal with this sort of crap :) it’s kinda sacrifice :) I dislike Java stuff, but have a lot of experience with it, so I deal with java aports 2017-04-05 00:13:43 <^7heo> yeah 2017-04-05 00:13:47 Shiz: basically all C, R and most of T tags will be autoassigned by a bot 2017-04-05 00:13:58 <^7heo> I take go over java any day 2017-04-05 00:14:35 Shiz: hmm, that’s another indication that T-security is probably in wrong category, b/c I don’t know how to auto-detect that :/ 2017-04-05 00:15:13 ^7heo: well, I prefer even Java to Go… 2017-04-05 00:15:14 :p 2017-04-05 00:15:56 ^7heo: I see probaly only one lang+ecosystem+culture worse than Go, PHP :P 2017-04-05 00:16:00 <^7heo> jirutka: I guess that's what we got our auyo-assignments from 2017-04-05 00:16:26 <^7heo> jirutka: man, no, c++ is MUCH worse than go 2017-04-05 00:17:00 <^7heo> at least go has problems that can be solved in a relatively ok time 2017-04-05 00:17:04 jirutka: responded to changes for opensmtpd bump :) 2017-04-05 00:17:17 ^7heo: well, that’s true, but build system and packaging is quite mature in C++… it’s insane and bad, but when I need to package some C++ project, I’m usually able to deal with that 2017-04-05 00:17:39 <^7heo> yes 2017-04-05 00:17:46 <^7heo> with horrible tools 2017-04-05 00:17:57 <^7heo> go is actually in its infancy 2017-04-05 00:18:08 <^7heo> and ahead of natural selection 2017-04-05 00:18:27 <^7heo> so people are just being stupid with it 2017-04-05 00:18:43 <^7heo> and the less bad designs will prevail over time 2017-04-05 00:18:44 Shiz: I assume that you’ve verified that the init script really works properly? 2017-04-05 00:18:48 yep 2017-04-05 00:18:51 okay 2017-04-05 00:19:06 <^7heo> for example, small programs in go are actually ok 2017-04-05 00:19:37 ^7heo: yeah, just have 5 MiB instead of few kiB in C, but… XD 2017-04-05 00:20:00 <^7heo> long story short, go just tries to be accessible; but one cannot make up for experience in good practices with a simple toolchain 2017-04-05 00:20:29 ^7heo: wait for my toolchain for building static binaries for Lua scripts :P 2017-04-05 00:20:51 <^7heo> jirutka: I'm quite ok with that if it works well 2017-04-05 00:21:02 <^7heo> the problem isn't the size 2017-04-05 00:21:13 I need to go sleep 2017-04-05 00:21:17 <^7heo> the problem is that it *doesn't* work well 2017-04-05 00:21:22 not just to avoid discussion about go… 2017-04-05 00:21:24 <^7heo> same 2017-04-05 00:21:26 <^7heo> :p 2017-04-05 00:21:27 it’s quite late already 2017-04-05 00:21:29 <^7heo> yeh 2017-04-05 00:21:42 <^7heo> also, LUA <3 2017-04-05 00:22:14 Shiz: so you think that Action would be better name than Type…? 2017-04-05 00:22:19 yeah 2017-04-05 00:22:36 jirutka: https://github.com/alpinelinux/aports/pull/1206#discussion_r109801674 2017-04-05 00:22:38 what do you mean here? 2017-04-05 00:22:49 specifically the install_if line? 2017-04-05 00:23:55 1st install_if is usually used with two items 2017-04-05 00:24:47 2nd I don’t understand what it should do; install subpkg when pkg opensmtpd-extras is installed? 2017-04-05 00:24:51 yep 2017-04-05 00:24:53 why? 2017-04-05 00:25:10 because someone might want to just install all extras in the repo? 2017-04-05 00:25:33 hm, then you can just add all subpkgs to origin pkg depends 2017-04-05 00:25:42 I’m not sure what is better 2017-04-05 00:25:56 i'll just do that 2017-04-05 00:26:40 depends is more transparent for users, e.g. you see the package dependencies on pkgs.a.o 2017-04-05 00:26:50 install_if is currently kinda “hidden” 2017-04-05 00:27:30 but the idea about installing all subpkgs when origin pkg is installed actually makes sense in this case 2017-04-05 00:28:05 right 2017-04-05 00:28:38 Shiz: gaa, you forgot to update checksum, the build fails 2017-04-05 00:28:44 fug 2017-04-05 00:28:51 Shiz: but why the hack it didn’t fail on Travis, there’s something wrong 2017-04-05 00:28:55 Shiz: http://build.alpinelinux.org/buildlogs/build-edge-armhf/main/opensmtpd/opensmtpd-6.0.2p1-r0.log 2017-04-05 00:30:17 I’ve fixed it now 2017-04-05 00:30:23 I mean checksum 2017-04-05 00:30:38 not sure what’s the problem with the script for travis that it haven’t failed 2017-04-05 00:30:59 good night 2017-04-05 00:31:38 oh 2017-04-05 00:31:53 thanks for the review+fix :) 2017-04-05 00:31:57 good night 2017-04-05 02:32:12 I am wondering if anyone having this bug : http://tpaste.us/YnYe. I tested on x86_64. gtkmm-2.24.4 or gtkmm-2.24.5 also suffers it. 2017-04-05 02:32:47 looks like /usr/lib/atkmm-1.6/proc/m4 should have been on the above line, assigned to GMMPROC_EXTRA_M4_DIR 2017-04-05 02:33:19 this also happens to tools/Makefile and gdk/gdkmm/Makefile 2017-04-05 02:40:50 looks like in configure, $PKG_CONFIG --variable=gmmprocm4dir pangomm-1.4 atkmm-1.6 returns into 2 separate line 2017-04-05 02:41:03 this only happens in alpine 2017-04-05 02:41:11 *my alpine 2017-04-05 02:47:37 I got it 2017-04-05 03:06:30 tmh1999: pkgconf 1.3.4-r1 and 1.3.5-r0 have a workaround 2017-04-05 03:07:29 tmh1999: basically somebody did something stupid with pkg-config because they did not understand that it was not intended behaviour 2017-04-05 03:09:03 kaniini : I just made a patch ... 2017-04-05 03:09:09 thanks :)) 2017-04-05 03:16:23 kaniini : do you mind report upstream ? 2017-04-05 03:16:58 tmh1999: i already fixed it in pkgconf 2017-04-05 03:17:27 Yeah I got your patch alright. I mean it looks like upstream screws this up 2017-04-05 03:17:44 so better report to them ? kaniini 2017-04-05 03:18:23 it can go either way. this is more one of those cases imo where the bug became a feature 2017-04-05 03:19:19 I see. Thank you 2017-04-05 03:23:25 but yes, in general, --variable was not meant to be used in that way (as gtkmm is the only package that breaks in that way ;)) 2017-04-05 05:58:31 Is there a particular reason the armhf sigs come up as untrusted when trying to fetch the repos using apk from a x86_64 host. 2017-04-05 05:59:01 Once I installed the keys in the new root using --allow-untrusted, it works fine, but that's a bit disconcerting. 2017-04-05 05:59:26 Are all the arch keys not signed by the alpine main keys for some reason? 2017-04-05 06:00:52 I'm trying to finish up the kernel staging tool, but this appears to break cross-platform builds. 2017-04-05 06:27:58 Also, how difficult would it be to allow "apk --arch armhf fetch linux-grsec" to work on x86_64 without setting up an entirely new root? 2017-04-05 06:30:13 IOOW, can the apk database handle multiple archs or does it need a db-per-arch, along with downloading of keys and bootstrapping for each? 2017-04-05 07:08:58 <^7heo> moin ncopa 2017-04-05 07:09:36 'morning ^7heo, ncopa. 2017-04-05 07:09:42 <^7heo> moin TemptorSent 2017-04-05 07:10:15 I'm actually going to call it an early night. 2017-04-05 07:11:05 I'm most of the way done with the kerneltool I'm working on, but have places to be tomorrow, so I can't burn too much midnight oil. 2017-04-05 07:11:18 <^7heo> ok 2017-04-05 07:11:51 <^7heo> take care then :p 2017-04-05 07:12:06 Not gone yet, just not going to be at it long. 2017-04-05 07:12:43 <^7heo> ah yeah 2017-04-05 07:16:08 Anyway, you give the tool a staging dir, a (optionally preceeded by arch) kernel .apk/build dir/package name/version and a set of additional .apks/build dirs/package names containing modules/firmware/dtbs, and it dumps it all into a staging directory ready for installation or use by mkinitfs. 2017-04-05 07:18:28 mkinitfs is going to learn to handle staging it's own userspace files so the PITA in update kernel can go away. 2017-04-05 07:18:52 Rather than silently fail. 2017-04-05 07:37:26 morning 2017-04-05 07:45:55 <^7heo> ncopa: any chance you get to peek at my patch soonish? :) 2017-04-05 07:47:56 ^7heo: can you please ping me about that in an hour or so? 2017-04-05 07:49:18 <^7heo> You got it. 2017-04-05 09:07:03 <^7heo> ncopa: ping 2017-04-05 09:10:18 ^7heo: hi 2017-04-05 09:10:19 thanks 2017-04-05 09:10:24 the url? 2017-04-05 09:10:27 <^7heo> ncopa: you're welcome ;) 2017-04-05 09:10:29 <^7heo> One sec' 2017-04-05 09:10:59 <^7heo> Network is VERY slow over here. 2017-04-05 09:11:18 <^7heo> https://github.com/alpinelinux/mkinitfs/pull/11 2017-04-05 09:11:21 <^7heo> Here. 2017-04-05 09:11:24 <^7heo> ncopa: ^ 2017-04-05 09:30:19 ^7heo: can you please elaborate the // XXX: unsafe memset, because of mutexes; according to skarnet 2017-04-05 09:30:37 <^7heo> ncopa: in the code or here? 2017-04-05 09:31:39 here 2017-04-05 09:32:34 <^7heo> Ok. So if I remember correctly (if I don't it's likely that skarnet will read that - since we're highlighting him - and will correct me), the point is that mutexes are an opaque type, and shouldn't be initialized with null bytes. 2017-04-05 09:34:00 <^7heo> but now that I read the code below, I can see that the mutexes are now initialized properly. 2017-04-05 09:34:28 <^7heo> It most likely wasn't the case when I first wrote that comment. 2017-04-05 09:34:35 thats why i asked about it 2017-04-05 09:34:36 <^7heo> or I overlooked them for X reason. 2017-04-05 09:34:46 maybe rebase and remove the comment? 2017-04-05 09:34:50 <^7heo> yes it is a valid question ;) 2017-04-05 09:34:54 <^7heo> I can do it if you want. 2017-04-05 09:35:04 <^7heo> I mean, it literally is a few seconds to me. 2017-04-05 09:35:15 <^7heo> If you're already doing it, go ahead. 2017-04-05 09:36:12 im not 2017-04-05 09:36:20 <^7heo> Ok so I'll push in a minute. 2017-04-05 09:37:03 <^7heo> pushed. 2017-04-05 09:40:04 thanks 2017-04-05 09:40:08 https://github.com/alpinelinux/mkinitfs/pull/11/commits/8406659b1f518f5397c43b845771422fbf53adfe 2017-04-05 09:40:14 i dont think we need that in separate commit 2017-04-05 09:40:29 can you merge that with the first commit? 2017-04-05 09:40:33 <^7heo> yes. 2017-04-05 09:40:35 how you do it: 2017-04-05 09:40:40 git rebase -i 2017-04-05 09:40:49 I don't remember saying that, but it's true nonetheless (i.e. don't memset() opaque types) 2017-04-05 09:40:51 move the commit up so its under the first 2017-04-05 09:40:52 <^7heo> yeah and then squash 2017-04-05 09:40:56 <^7heo> yeah I know 2017-04-05 09:41:00 <^7heo> I use git a *lot* 2017-04-05 09:41:08 fixup in this case 2017-04-05 09:41:14 good :) 2017-04-05 09:41:15 <^7heo> nah I wanna keep the commit. 2017-04-05 09:41:23 <^7heo> s/commit/message/ 2017-04-05 09:42:03 an opaque type will have an init function or an opaque initializer, you should never need to memset() it 2017-04-05 09:42:21 for a mutex: pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; 2017-04-05 09:42:29 and that's all you need 2017-04-05 09:42:33 <^7heo> yeah, the code is actually calling a function. 2017-04-05 09:42:41 <^7heo> which does exactly that I would say. 2017-04-05 09:42:52 pthread_mutex_init(&m, &attr) 2017-04-05 09:42:53 works too 2017-04-05 09:42:57 <^7heo> that is what is called. 2017-04-05 09:43:05 <^7heo> with NULL for &attr 2017-04-05 09:43:13 yeah, that works 2017-04-05 09:43:53 <^7heo> ncopa: by "first commit" you meant 86b3ddb right? 2017-04-05 09:44:14 yes 2017-04-05 09:44:25 <^7heo> doing it now. 2017-04-05 09:44:38 i want to hide the fact that there was ever an (size_t)atoi() there 2017-04-05 09:44:53 as if it was done correctly in the first commit 2017-04-05 09:45:03 <^7heo> I see. ;) 2017-04-05 09:45:15 <^7heo> Makes sense. 2017-04-05 09:45:25 <^7heo> I have a diff conflict, I'll solve it and push. 2017-04-05 09:46:11 <^7heo> (because we changed the expression for the conf.crypt_payload_offset) 2017-04-05 09:46:21 ah, ok 2017-04-05 09:46:52 skarnet: thanks for you input wrt pthread_mutex 2017-04-05 09:47:33 np, http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html is where it's at ;) 2017-04-05 09:58:35 <^7heo> ncopa: I'm actually wondering if we're doing the sscanf if right. 2017-04-05 09:58:50 <^7heo> sscanf MUST return 1, not 1+ 2017-04-05 09:59:10 <^7heo> so we should throw an error if it returns ANYTHING else than 1, including 2. 2017-04-05 09:59:21 <^7heo> what do you think? 2017-04-05 09:59:44 sscanf is really, really hard to get right. I don't know what you're trying to do, but sscanf is dangerous to handle. 2017-04-05 10:00:05 <^7heo> skarnet: if(sscanf(EARGF(usage(1)), "%zu", &conf.crypt.payload_offset) < 1) err(1, "sscanf") ; 2017-04-05 10:00:24 <^7heo> skarnet: IMHO < should be == 2017-04-05 10:00:29 <^7heo> != sorry 2017-04-05 10:00:31 ew, more 9p macros 2017-04-05 10:00:40 <^7heo> yep 2017-04-05 10:00:49 <^7heo> (not for the ew, I kinda like them) 2017-04-05 10:01:06 <^7heo> (because I don't see why not; but feel free to explain :P) 2017-04-05 10:01:56 because there's a posix API to do the exact same thing which is more portable and more readable? 2017-04-05 10:02:26 <^7heo> skarnet: but isn't that POSIX API orders of magnitude bigger? 2017-04-05 10:02:36 <^7heo> and more complex? 2017-04-05 10:02:56 <^7heo> (I really don't know - I only assume that you can't get much more barebones than the 9p macros) 2017-04-05 10:03:18 getopt() is likely a bit more complex than ARGBEGIN/ARGEND, yes 2017-04-05 10:03:30 but that's because the magic is less hidden 2017-04-05 10:03:51 <^7heo> My opinion is that the shorter the code I read, the less hidden it is. 2017-04-05 10:04:07 <^7heo> but maybe that's not a widespread opinion. 2017-04-05 10:04:25 <^7heo> of course, intentional obfuscation aside. 2017-04-05 10:05:28 well, generally the shorter the better, yes, but ARGBEGIN/ARGEND make things shorter by magic. 2017-04-05 10:05:29 you don't want that anywhere near things you care about. 2017-04-05 10:05:44 <^7heo> What I don't get is how this is more magic than the POSIX api, 2017-04-05 10:05:52 <^7heo> is it because it's unspecified? 2017-04-05 10:05:58 <^7heo> s/un/not / 2017-04-05 10:06:51 because that's a set of macros extending the C language: https://swtch.com/plan9port/man/man3/arg.html 2017-04-05 10:07:10 getopt() is pure C, it doesn't need to hide constructs 2017-04-05 10:07:41 <^7heo> Ah, I think I start to get what you mean. 2017-04-05 10:07:58 i tend to agree with skarnet 2017-04-05 10:08:09 i think this comes from some suckless project originally 2017-04-05 10:08:17 <^7heo> it obviously does yes. 2017-04-05 10:08:22 yes, and suckless loves 9p 2017-04-05 10:08:29 <^7heo> yes they do. 2017-04-05 10:08:42 i never bothered to clean that up 2017-04-05 10:08:47 as it kinda works 2017-04-05 10:08:52 <^7heo> yeah it works for me. 2017-04-05 10:08:55 <^7heo> I won't complain. 2017-04-05 10:09:08 <^7heo> I use that code in many software I use daily. 2017-04-05 10:09:08 I can totally understand why they love 9p, but for a Unix OS I prefer using idiomatic constructs 2017-04-05 10:09:25 ^7heo: have you tested if it actually works? 2017-04-05 10:09:38 <^7heo> ncopa: the ARGBEGIN/ARGEND? 2017-04-05 10:09:45 <^7heo> ncopa: it obviously does ;) 2017-04-05 10:09:45 the detached header 2017-04-05 10:09:47 <^7heo> ah 2017-04-05 10:09:52 <^7heo> Well, there's a test for that. 2017-04-05 10:09:56 <^7heo> in the ./test.sh 2017-04-05 10:10:01 ok 2017-04-05 10:10:11 <^7heo> and it passes, by grabbing the same dynamically-generated timestamp. 2017-04-05 10:10:24 i'd say we just push it then? 2017-04-05 10:10:31 <^7heo> yeah but give me one minute please. 2017-04-05 10:10:36 ok 2017-04-05 10:10:42 <^7heo> I am still pondering if I should replace < by != 2017-04-05 10:10:59 <^7heo> in `if(sscanf(EARGF(usage(1)), "%zu", &conf.crypt.payload_offset) < 1) err(1, "sscanf") ;` 2017-04-05 10:11:17 <^7heo> I mean, in our case, sscanf MUST return 1. 2017-04-05 10:11:24 <^7heo> must it not? 2017-04-05 10:13:58 yeah, i think so 2017-04-05 10:14:04 <^7heo> ok 2017-04-05 10:14:07 <^7heo> So I'll push that. 2017-04-05 10:14:20 <^7heo> One minute, reviewing before pushing one last time. 2017-04-05 10:15:01 <^7heo> Note: the offset function is untested as of now, since I do not know how to test it properly. 2017-04-05 10:15:18 fair enough 2017-04-05 10:15:21 <^7heo> I will write a test for it as soon as I can; but I first need to experiment with the deported header. 2017-04-05 10:15:33 <^7heo> To actually get hands on with it. 2017-04-05 10:15:35 once we have pushed it, maybe you can test it in a vm 2017-04-05 10:15:48 <^7heo> I actually have a machine I want to test it with. 2017-04-05 10:16:06 <^7heo> So it's fine, I have enough machines to setup. 2017-04-05 10:16:13 <^7heo> What I'm short on are power supplies ;) 2017-04-05 10:16:31 <^7heo> Pushed one last time. 2017-04-05 10:17:26 <^7heo> ncopa: as soon as this is in the repos 2017-04-05 10:17:30 <^7heo> ncopa: I'll setup a machine with it 2017-04-05 10:17:46 <^7heo> (and write some doc' on how to use the deported header with LUKS + ZFS) 2017-04-05 10:18:09 <^7heo> next step for me is to have Alpine boot on the USB armory. 2017-04-05 10:20:57 <^7heo> ncopa: I think we can push now. 2017-04-05 10:29:26 i want to build a package for snapcast. they only have a archive from github that doesnt include alot of submodule code. whats the best way to do it? should i get the archive or clone the repo and do a git submodule update in it? but whats with the checksums then? https://github.com/badaix/snapcast 2017-04-05 10:31:14 heh, i just looked into snapcast the other day. 2017-04-05 10:32:02 its a great piece of software... i use it with mopidy alot 2017-04-05 10:32:22 didnt we have issues with mopidy on alpine? 2017-04-05 10:32:30 ye 2017-04-05 10:32:32 s 2017-04-05 10:32:47 i remember it has been some time. 2017-04-05 10:32:55 i cant get python bindings for gstreamer up and running 2017-04-05 10:33:03 they compile fine but throw a error 2017-04-05 10:33:11 when mopidy imports the module 2017-04-05 10:33:31 i think i fixed it ones local, but its so long ago. 2017-04-05 10:33:49 thats why i use mopidy within a debian docker container... and for the snapcast client i want to use alpine soon :) 2017-04-05 10:34:11 i think we can fix mopidy 2017-04-05 10:34:21 really? 2017-04-05 10:34:25 that would be perfect 2017-04-05 10:34:35 if others can we can also :) 2017-04-05 10:34:47 there is some error about pbutils cant be imported 2017-04-05 10:35:15 whats this about snapcast? 2017-04-05 10:35:21 about submodules? 2017-04-05 10:35:24 i can pastebin my APKBUILD for py-gst1 2017-04-05 10:35:58 snapcast needs some submodules to compile... 2017-04-05 10:36:08 ah inside externals 2017-04-05 10:36:21 and i dont know if i should create for everyne a package or just use the submodule in the package creation process 2017-04-05 10:37:46 its links all those libs statically? 2017-04-05 10:39:02 for py-gst1: https://gist.github.com/xsteadfastx/1e4196b71c4f99d3815117dd3c3dbfa9 2017-04-05 10:39:41 building that... and installing mopidy with "pip install mopidy" and try to start it 2017-04-05 10:40:41 we dont have mopidy in aports? 2017-04-05 10:41:03 i dont know about the static linking. but i guess yes. some are libs for flac or ogg... but other things are libs i think he coded for snapcast itself 2017-04-05 10:41:13 clandmeter: not anymore 2017-04-05 10:41:37 i think its because gstreamer1 is needed 2017-04-05 10:41:42 and its python bindings 2017-04-05 10:54:27 ncopa: clandmeter: fabled: what do you think about (a) removing php5 completely and keeping just php7 (before branching v3.6), or (b) updating all pkgs that depends on php to use only php7, if it’s supported, or only php5 if it’s not ? context: https://github.com/alpinelinux/aports/pull/1061#issuecomment-291824607 2017-04-05 10:54:42 <^7heo> ncopa: can you pull the PR? 2017-04-05 10:54:53 <^7heo> ncopa: so other PRs can be rebased on it 2017-04-05 10:55:28 <^7heo> ncopa: also https://github.com/alpinelinux/mkinitfs/pull/8/files 2017-04-05 11:00:13 jirutka: im in favor of getting rid of php5 2017-04-05 11:00:25 are there any apps of significance that does not support php7? 2017-04-05 11:00:57 ncopa: I don’t know, I’ve asked Andy and Valery about that, they will probably know 2017-04-05 11:01:22 <^7heo> ncopa: we should have an "LTS" repo for such cases. 2017-04-05 11:01:35 main = LTS 2017-04-05 11:01:35 <^7heo> ncopa: or aren't them frequent enough to justify another repo? 2017-04-05 11:01:51 <^7heo> ok LTS is the wrong term 2017-04-05 11:01:54 <^7heo> deprecated 2017-04-05 11:01:58 <^7heo> is what I meant. 2017-04-05 11:02:06 main = 2 years support, community = 6 months support, testing = no support 2017-04-05 11:02:13 we have enough repos now IMO 2017-04-05 11:02:40 <^7heo> jirutka: I think it'd be fine with moving php5 to unmaintained 2017-04-05 11:02:42 +1 2017-04-05 11:02:46 https://docs.google.com/spreadsheets/d/10nGKgwym2j7rle85pHj72I_2hEQ_VpLCd2CVKLGL_BE/edit#gid=0 2017-04-05 11:02:51 <^7heo> jirutka: *if* unmaintained was built 2017-04-05 11:02:51 looks like we can drop php5 2017-04-05 11:03:18 ncopa: these are only php-* pkgs, but not php apps like nextcloud, roundcube etc. 2017-04-05 11:03:26 <^7heo> yeah 2017-04-05 11:03:29 ok 2017-04-05 11:03:38 <^7heo> just for the sake of carefulness 2017-04-05 11:03:55 <^7heo> can't we have it stay in the repos but outside of main? 2017-04-05 11:04:06 <^7heo> as I said, @deprecated would fit 2017-04-05 11:04:10 I remember that I’ve moved roundcube, nextcloud and zabbix from main to community when moving php5 out of main; don’t know about pkgs in community now 2017-04-05 11:05:02 <^7heo> the cycle goes like: testing -> community -> main 2017-04-05 11:05:02 ^7heo: I don’t see any benefit from that, many users are already confused from three repos, adding fourth with different rules will just add another confusion :/ 2017-04-05 11:05:20 <^7heo> with that cycle we're assuming that software will always transition correctly between versions 2017-04-05 11:05:28 <^7heo> obviously that assumption is flawed. 2017-04-05 11:05:50 <^7heo> what I'm proposing here is to add an exit after main 2017-04-05 11:05:55 <^7heo> testing -> community -> main -> deprecated 2017-04-05 11:05:56 ^7heo: if someone really wants to use deprecated software, then (s)he can always build it themself 2017-04-05 11:06:10 <^7heo> jirutka: and that's the purpose of unmaintained. 2017-04-05 11:06:17 <^7heo> jirutka: but we're talking about php users here... 2017-04-05 11:06:36 ^7heo: yeah, I know! 2017-04-05 11:06:53 <^7heo> It's a bit of an edge case, I have to admit. 2017-04-05 11:06:54 ^7heo: let’s move to up-to-date version of your crappy lang or gtfo :) 2017-04-05 11:07:05 <^7heo> creating a repo for an edge case is far removed from ideal. 2017-04-05 11:07:08 i dont think its worth fixing php5 and php7 to be installed in parallel 2017-04-05 11:07:17 im ok with having a conflict there 2017-04-05 11:07:37 then i think we should delete as many of php5-* apkbuilds as possible 2017-04-05 11:07:46 so we dont need maintain those 2017-04-05 11:07:49 <^7heo> wait, are we talking about having php5 still available BUT uncompatible with php7? 2017-04-05 11:08:00 <^7heo> or are we talking about dropping php5 entirely? 2017-04-05 11:08:04 both 2017-04-05 11:08:07 however 2017-04-05 11:08:17 ncopa: if we decide to keep php5/php7, but use php5 only for pkgs that do not support php7, so remove this insane duplication of apkbuilds, then it may be okish to declare them as conflicting 2017-04-05 11:08:20 <^7heo> How can we drop php5 entirely but still have it available? 2017-04-05 11:08:50 jirutka: that is what i'd want 2017-04-05 11:08:50 ^7heo: we have multiple options how to solve this mess 2017-04-05 11:09:12 like phpldapadmin 2017-04-05 11:09:13 <^7heo> jirutka: yeah I get that; but we can't have php5 AND not have php5. That's kinda antilogic. 2017-04-05 11:09:18 make it depend on php5 2017-04-05 11:09:32 but i dont think it needs any of the php5-* packages? 2017-04-05 11:09:40 ^7heo: one of them is to remove php5 completely, another one is to keep it, but support it only for pkgs that does not support php7, so removing most of the multiversion abuilds that are currently split in separete apkbuilds 2017-04-05 11:10:00 <^7heo> I would be for that latter option personally. 2017-04-05 11:10:35 support it only for pkgs that does not support php7 2017-04-05 11:10:39 is what i'd prefer 2017-04-05 11:10:42 <^7heo> same. 2017-04-05 11:10:43 and kill most php5-* 2017-04-05 11:10:46 if not all 2017-04-05 11:10:48 however 2017-04-05 11:10:53 ncopa: ad phpldapadmin: https://github.com/leenooks/phpLDAPadmin/issues/43 2017-04-05 11:11:04 do we know how many and which php apps does not support php7? 2017-04-05 11:11:19 postfixadmin? roudcube? nextcloud? 2017-04-05 11:11:26 <^7heo> ncopa: it's often "documented" by bug reports in a per-app basis. 2017-04-05 11:11:42 <^7heo> (in the case of drupal for example) 2017-04-05 11:12:02 ncopa: I personally prefer to kill php5 with fire :) but I don’t have anything against keeping php5 as we described now, only for pkgs that do not support php7 2017-04-05 11:12:03 could we try make a report of which apps are php5 only? 2017-04-05 11:12:10 yes 2017-04-05 11:12:28 we will not push new things for php5 2017-04-05 11:12:32 ncopa: as I said, don’t now currently, I’ve asked Andy and Valery in the PR on GH, they will probably know that 2017-04-05 11:12:50 so thats an action point 2017-04-05 11:12:58 yeah! we have action points now! :) 2017-04-05 11:13:18 <^7heo> Oh cool management talk! 2017-04-05 11:13:22 :) 2017-04-05 11:13:31 <^7heo> When do we get to have standups? :D 2017-04-05 11:13:40 im trying to learn all those cool words 2017-04-05 11:13:46 <^7heo> Or should we all stand up in front of IRC to make this discussion shorter? :D 2017-04-05 11:14:00 ^7heo: LOL +1 2017-04-05 11:14:28 <^7heo> in my experience, standups are only useful with people who have personal issues. 2017-04-05 11:14:43 <^7heo> self-concious people, short attention span people, etc. 2017-04-05 11:14:49 so we should have standups in #alpine-offtopic then :) 2017-04-05 11:14:55 <^7heo> yeah I disgress. 2017-04-05 11:14:59 <^7heo> sorry. 2017-04-05 11:17:01 <^7heo> ncopa: do you need more time to decide what to do with mkinitfs? 2017-04-05 11:17:08 <^7heo> ncopa: or can we get that in so I can test it asap? 2017-04-05 11:17:28 im blue sky thinking about it 2017-04-05 11:17:46 i think i need to think outside the box 2017-04-05 11:18:05 <^7heo> ncopa: you're 50% of the way to dilbert. 2017-04-05 11:18:09 maybe we should touch base offline before close of play 2017-04-05 11:18:53 <^7heo> it's funny to be blue-sky thinking in a country where in the vast majority of the time, the sky isn't blue. 2017-04-05 11:18:54 going forward we need action that no brainer drill down 2017-04-05 11:19:11 i think i need a though shower 2017-04-05 11:19:36 <^7heo> it's tempting to derail that discussion with silly remarks 2017-04-05 11:19:39 <^7heo> but I will resist. 2017-04-05 11:19:44 :) 2017-04-05 11:19:53 im practicing my manager talk :) 2017-04-05 11:20:02 <^7heo> it was quite noticable ;) 2017-04-05 11:22:21 <^7heo> ncopa: http://dilbert.com/strip/2010-10-25 2017-04-05 11:22:26 ncopa: I’ve summarized your position in https://github.com/alpinelinux/aports/pull/1061#issuecomment-291831195 2017-04-05 11:26:05 <^7heo> ncopa: are we gonna make a release of mkinitfs before 3.6? 2017-04-05 11:27:13 ncopa: btw not sure if you’ve seen that: https://github.com/jirutka/emscripten-travis-example; it’s a practical example of using Alpine in chroot on Travis (or any other CI) that leads to much faster builds then using “official” approach (emscripten sdk) :) 2017-04-05 11:27:50 <^7heo> s/then/than/ 2017-04-05 11:29:50 <^7heo> ncopa: also it would be very cool to apply main/mkinitfs/0001-init-pull-in-libressl-instead-of-openssl-for-encrypt.patch to mkinitfs. 2017-04-05 11:29:53 ncopa: also based on my quick research, we now provides the best user experience for emscripten among major distros :) (most likely b/c emscripten is huge pile of crappy code unfriendly with distributions) :) 2017-04-05 11:30:09 <^7heo> jirutka: dude, we're really writing to ncopa almost in sync, with the same volume. 2017-04-05 11:30:22 <^7heo> jirutka: we should take turns, who goes first? ;) 2017-04-05 11:30:36 "create a list of packages in main/community that do not support php5 (and maybe subset of them that can be easily patched for php7)." 2017-04-05 11:30:52 jirutka i think you mean list of packages that requires php5 2017-04-05 11:30:53 ^7heo: it seems that we’re in sync XD good that we’re not woman, periods in sync… 2017-04-05 11:31:06 <^7heo> jirutka: that's actually a thing. 2017-04-05 11:31:19 <^7heo> ncopa: do you want me to come back at a later time for mkinitfs? 2017-04-05 11:31:44 ncopa: fixed 2017-04-05 11:31:59 <^7heo> (I could make a todolist with a few action points to do before 3.6 if you want) 2017-04-05 11:32:07 <^7heo> (for mkinitfs, not for *) 2017-04-05 11:37:00 clandmeter: sorry i misocnfigured my weechat and it removed history. did you answer me? 2017-04-05 11:37:30 xsteadfastxd: did you ask me something? 2017-04-05 11:38:20 because mopidy... you asked if there is no aport... and i answered... and thought you were checking something :) sorry 2017-04-05 11:38:35 no i didnt check it 2017-04-05 11:38:56 i did look a bit into snapcast 2017-04-05 11:39:24 looks like that dev is not really into packaging his stuff correctly 2017-04-05 11:41:02 yes. so i wonder if i need to package all this deps into seperated packages. that would be the best or? 2017-04-05 11:41:22 good luck with that... 2017-04-05 11:41:36 cause few of them are also from the same dev 2017-04-05 11:44:57 ^7heo: mkinitfs pushed 2017-04-05 11:45:18 <^7heo> ncopa: how about you also push your patch in the aports? 2017-04-05 11:45:24 <^7heo> ncopa: main/mkinitfs/0001-init-pull-in-libressl-instead-of-openssl-for-encrypt.patch 2017-04-05 11:46:39 i think it already is? 2017-04-05 11:48:33 <^7heo> ncopa: there's a PR open about it, and it is marked as "no[t] conflict[ing] with the base branch" 2017-04-05 11:48:36 <^7heo> so I think not. 2017-04-05 11:48:43 <^7heo> ncopa: https://github.com/alpinelinux/mkinitfs/pull/8 2017-04-05 11:49:15 clandmeter: xsteadfastx what about mopidy? 2017-04-05 11:49:42 scadu: a new version cant be installed because lacking of py-gst1 2017-04-05 11:49:56 <^7heo> ncopa: after it is done, I'd advise to make a release, so I can abump the APKBUILD. 2017-04-05 11:49:57 leo-unglaub: hi! 2017-04-05 11:50:00 <^7heo> (and remove the patch( 2017-04-05 11:50:04 <^7heo> s/($/)/ 2017-04-05 11:50:31 scadu: i tried to build it... mopidy could be installed via pip but throws an gstreamer error 2017-04-05 11:51:23 scadu: ah its your logs i found through googling around with that problem 2017-04-05 11:52:10 ^7heo: i dont really care what github PR's says about merge conflicts: https://git.alpinelinux.org/cgit/mkinitfs/commit/?id=c3c4721f2e9c00ae8dd8d1f7bb4061873c1e915a 2017-04-05 11:52:11 <^7heo> ncopa: about the release, I don't know if it should be 3.0.10 or 3.1.0, maybe the latter since we changed quite a few things (esp for crypto) 2017-04-05 11:54:21 <^7heo> ncopa: then someone should close that PR 2017-04-05 11:54:40 <^7heo> oh, it has been done. 2017-04-05 11:56:11 clandmeter: mopidy has been moved to unmaintained 2017-04-05 11:56:29 clandmeter: confirmed with ncopa 2017-04-05 11:56:32 for what reason? 2017-04-05 11:56:41 i guess in favor of pip? 2017-04-05 11:57:02 there is no py-gst1 2017-04-05 11:57:15 and its needed by newer mopidy version 2017-04-05 11:58:40 clandmeter: py-gst1 and some other issues I wasn't able to solve at the time or had no time for this. 2017-04-05 12:03:23 <^7heo> pickfire: in case you didn't get the github mail, your PR needs a rebase. 2017-04-05 12:04:00 scadu: clandmeter: i could not getting it working too 2017-04-05 12:04:34 13:41 <@clandmeter> cause few of them are also from the same dev 2017-04-05 12:04:40 clandmeter: what packages? 2017-04-05 12:04:53 snapcast 2017-04-05 12:04:54 scadu: that was about snapcast 2017-04-05 12:29:23 <^7heo> ncopa: also I would say that https://github.com/alpinelinux/mkinitfs/pull/10 can safely go in. 2017-04-05 12:50:18 ^7heo: if you’ve changed some behaviour (and it’s not a bugfix) or added new feature, then 3.1.0 2017-04-05 12:52:13 <^7heo> jirutka: clearly. 2017-04-05 12:52:17 xsteadfastx: i think i have an apkbuild for snapcast 2017-04-05 12:52:20 <^7heo> (clearly did so( 2017-04-05 12:52:26 <^7heo> s/($/)/ 2017-04-05 12:52:40 clandmeter: oh cool. can i see it? 2017-04-05 12:54:20 im going to push it to testing. 2017-04-05 12:55:23 yeah. cant wait to see it 2017-04-05 13:08:28 xsteadfastx: im a bit too late :) 2017-04-05 13:08:33 ncopa just pushed gcc 2017-04-05 13:09:50 jirutka: i'm unsure how the dependency tracing works, could you enlighten? 2017-04-05 13:10:03 as I understand it, right now it will see the libpq.so (e.g.) from postgresql-dev and recommend that 2017-04-05 13:10:11 but I want it to use the one from the libpq package 2017-04-05 13:10:15 Shiz: do you know tool ldd? 2017-04-05 13:10:21 i know that part 2017-04-05 13:10:24 just how it matches it to packages 2017-04-05 13:10:40 clandmeter: i think it needs the avahi deamon and dependencie 2017-04-05 13:10:45 depends what a package provides 2017-04-05 13:11:00 xsteadfastx, yes its not finished yet 2017-04-05 13:11:27 i think it needs to split the server client and add initd for server. 2017-04-05 13:11:29 ah, wait 2017-04-05 13:11:34 and probably add a test. 2017-04-05 13:11:39 the -dev provides the bare .so and libpq provides the versioned... version 2017-04-05 13:11:41 Shiz: the tracked dependencies are added as `provides` to APKINDEX 2017-04-05 13:12:38 Shiz: this `so:libpq.so.x.y` is in `provides` of pkg libpq 2017-04-05 13:12:43 xsteadfastx, but this is a start, if you want you can add a PR to add the missing parts. 2017-04-05 13:12:48 right 2017-04-05 13:12:57 then we could move it to community if it really works. 2017-04-05 13:13:14 clandmeter: yeah i will build it and check it out. nerved added initd files to my few alpine packages before 2017-04-05 13:13:20 the apkbuild isnt pretty, but atleast it works like this. 2017-04-05 13:13:28 xsteadfastx, its very easy 2017-04-05 13:13:46 openrc has a man page about it 2017-04-05 13:13:50 or split a package or something... but the wiki docs are really great 2017-04-05 13:14:48 normally what we do is split it by adding a server() and client() subpkg and and have main pkg as metapkg which pulls in both client and server. 2017-04-05 13:15:00 its make client and make server i think... so should i need to find out how i can build two packages within one APKBUILD 2017-04-05 13:15:06 ah ok 2017-04-05 13:15:29 you dont have to build it independent 2017-04-05 13:15:52 the subpkgs should just copy the files to subpkgsdir 2017-04-05 13:15:58 i found the subpackage example in the wiki 2017-04-05 13:16:07 in this case just a single file 2017-04-05 13:16:19 Shiz: I’ve renamed T to A as you suggested, so now we have: A-add, A-fix, A-improve, A-move, A-upgrade; but don’t know what to do with T-security, it does not fit to any existing category; maybe this is the only one that really belongs to T (type)? 2017-04-05 13:16:44 clandmeter: i will look into it tomorrow :) 2017-04-05 13:17:10 jirutka: I think T-security is just a high-prio A-fix, no? 2017-04-05 13:17:12 :p 2017-04-05 13:17:22 but yeah, it's more of a misc label 2017-04-05 13:17:27 Shiz: also I don’t like A-add, but can’t figure out a better word; it used to be named T-new, but all A are now verbs 2017-04-05 13:17:38 jirutka, i would like if the labels were more clear. 2017-04-05 13:17:43 A-create? 2017-04-05 13:17:51 no abbreviations 2017-04-05 13:18:43 clandmeter: we have just 5 single letter abbreviations… it’s very unpractical to use full name, then it may not even fit on single line when you combine multiple labels on single PR 2017-04-05 13:19:37 well, i prefer a clear label instead of asking or looking it up (if its even documented). 2017-04-05 13:19:56 clandmeter: what label do you consider unclear? 2017-04-05 13:21:26 all of the single letters prefixes 2017-04-05 13:21:54 clandmeter: there are just to group labels; I hope that all labels works even without the prefix 2017-04-05 13:22:06 clandmeter: I mean that they make sense even when you omit the prefix 2017-04-05 13:22:34 if it was clear, i would be asking would i? :) 2017-04-05 13:23:01 and i think more users would ask, but maybe im more stupid then most of them :) 2017-04-05 13:23:13 clandmeter: users don’t set labels, only we do 2017-04-05 13:23:27 clandmeter: these labels are mainly for reviewers and maintainers, not for contributors 2017-04-05 13:23:28 i know 2017-04-05 13:23:31 but users also see them 2017-04-05 13:24:01 clandmeter: and if they should be perfectly clear and unambiguous, then we would need to use sentences instead of short code… ;) 2017-04-05 13:24:30 I didn't saw the last bump, who messaged me? 2017-04-05 13:24:50 ^7heo: Github workflow so problematic. :( 2017-04-05 13:24:58 <^7heo> pickfire: github isn't different from git. 2017-04-05 13:25:14 <^7heo> pickfire: me I think 2017-04-05 13:25:15 ^7heo: I made changes straight on github, without going to git. 2017-04-05 13:25:27 And now need to pull and rebase 2017-04-05 13:25:36 <^7heo> pickfire: yeah you need to pull your changes with git. 2017-04-05 13:25:36 clandmeter: imagine that you have for example: “Action: upgrade”, “Status: change-requested”, “Repository: main”, “Category: python” on one PR… this would not even fit on single line on PRs list 2017-04-05 13:25:44 <^7heo> pickfire: github is okay as an interface to git. 2017-04-05 13:25:46 Can't just merge and squash? 2017-04-05 13:25:49 <^7heo> pickfire: it isn't ok as a tool 2017-04-05 13:25:56 pickfire: it’s not problematic at all, if you really know basis of git… 2017-04-05 13:26:21 pickfire: your problem is not in GH at all, but in git 2017-04-05 13:26:22 Then I say I don't know how to use git. 2017-04-05 13:26:28 How? 2017-04-05 13:26:29 Haha 2017-04-05 13:26:51 I only know what is git - the stupid content tracker. 2017-04-05 13:27:02 I know nothing else. 2017-04-05 13:27:11 Hehe ^^ 2017-04-05 13:27:13 <^7heo> omg fucking web... 2017-04-05 13:27:17 <^7heo> it's *SO* slow. 2017-04-05 13:27:26 ^7heo: Here's even slow. 2017-04-05 13:27:33 pickfire: btw I personally never edit files directly via Git interface, but it’s principally the same as working with two git repos 2017-04-05 13:27:33 Let's compare our speed. 2017-04-05 13:27:34 <^7heo> I have a quite decent machine 2017-04-05 13:27:38 github is slow recently.... 2017-04-05 13:27:47 the webif that is 2017-04-05 13:27:48 <^7heo> clandmeter: I mean the UI 2017-04-05 13:27:52 <^7heo> clandmeter: ah yeah 2017-04-05 13:27:54 clandmeter: yeah, it really is, don’t know why :/ 2017-04-05 13:27:59 jirutka: But why can't just merge into one repo? 2017-04-05 13:28:04 <^7heo> so maybe it's not me. 2017-04-05 13:28:13 <^7heo> because it's a half assed UI in ruby? 2017-04-05 13:28:16 <^7heo> anyway 2017-04-05 13:28:35 ^7heo: Here's 5 mbps. 2017-04-05 13:28:36 <^7heo> pickfire: I'll explain how to do that in /query, as it's not some information that is interesting for most people here ;) 2017-04-05 13:28:39 What about yours? 2017-04-05 13:28:41 clandmeter: I’ve started thinking about finding some CLI tool for working with PRs (not just just pull PR, but manage them, comment etc.), b/c web interface is slow 2017-04-05 13:28:50 <^7heo> pickfire: the webapp is slow, the connection speed is ok. 2017-04-05 13:28:58 Ah 2017-04-05 13:29:09 <^7heo> jirutka: that's my goal, I planned to do a python tool for that. 2017-04-05 13:29:14 <^7heo> jirutka: but maybe LUA would fit. 2017-04-05 13:29:14 You mean alpinelinux.org is slow? 2017-04-05 13:29:21 <^7heo> no, github. 2017-04-05 13:29:30 <^7heo> you're aware that github is an app on top of git, right? 2017-04-05 13:29:30 alpinelinux.org is even slow. 2017-04-05 13:29:32 clandmeter: but still better than GitLab, at least GitHub always load the page and never lost data, lol :) 2017-04-05 13:29:41 <^7heo> github is slow, git is fine. 2017-04-05 13:29:42 clean your mouth, alpinelinux.org is tha best! 2017-04-05 13:29:42 I won't be surprised even if you say it is slow. 2017-04-05 13:29:50 pickfire: no, I mean GitHub web interface 2017-04-05 13:30:05 clandmeter: alpine linux is the best, not alpinelinux.org 2017-04-05 13:30:14 pickfire: alpinelinux.org is faster than light! 2017-04-05 13:30:15 jirutka: github isfat 2017-04-05 13:30:17 FAT 2017-04-05 13:30:23 <^7heo> gitlube. 2017-04-05 13:30:36 Network hogger 2017-04-05 13:30:41 pickfire: FAT? Like File Allocation Table? 2017-04-05 13:30:48 each page is 700 MB uncompressed. 2017-04-05 13:30:56 pickfire: wtf? 2017-04-05 13:31:39 I don't know what can I do for this http://patchwork.alpinelinux.org/patch/3184/ 2017-04-05 13:31:43 jirutka, if you hook that interface on github's api, you think it will be faster? 2017-04-05 13:31:50 jirutka: Sorry, 700 KB 2017-04-05 13:32:05 or you mean a complete independent one? 2017-04-05 13:33:53 ncopa, is that ppc builder still doing its first world cycle? 2017-04-05 13:34:31 clandmeter: yes, definitely 2017-04-05 13:35:04 we maybe should have it halt on errors now 2017-04-05 13:35:47 clandmeter: did you got my point about short label names? 2017-04-05 13:36:11 clandmeter: the scheme I used is inspired from https://github.com/rust-lang/rust/issues 2017-04-05 13:36:17 phone... 2017-04-05 13:37:16 clandmeter: I’ve also considered another schemes like “Category: Python” etc. and it’s just unnecessary verbose and impractical, it would clutter the list of PRs a lot 2017-04-05 13:38:54 clandmeter: also we can get rid of prefix and use just colour to distinguish various “types” of labels, but that wouldn’t help you with selecting them using autosuggestions 2017-04-05 13:47:20 back 2017-04-05 13:47:51 jirutka, like i mentioned, its not only for me but i think its also nice for contributors to know what it means. 2017-04-05 13:48:04 alternative is to have it documented? 2017-04-05 13:51:42 clandmeter: yes, we can document it; however, I hope that e.g. S-changes requested is clear enough even without knowledge what S stands for… this is really just a helper for us to quickly select the proper label 2017-04-05 13:54:29 clandmeter: the current state is basically first draft to see how it will work for us 2017-04-05 13:56:23 ncopa, yes please cause commits channel is pretty difficult to follow now. 2017-04-05 13:57:00 are we going to finish ppc world before 3.6? 2017-04-05 13:57:11 clandmeter: the next step for me is to write a “classification algorithm” that would eat patch file and produce set of tags (mainly A, C, R) 2017-04-05 13:57:13 i think so 2017-04-05 13:57:21 sounds fun 2017-04-05 13:57:50 clandmeter: ncopa: yes, #alpine-commits is very cluttered these days 2017-04-05 13:58:21 seems like main built all except compiler-rt and ncftpd 2017-04-05 13:58:24 clandmeter: yeah, it is :) and that’s the problem, I haven’t finished many projects yet and heeey, another exciting one! :/ 2017-04-05 13:58:47 jirutka, i was refering to building world :) 2017-04-05 13:58:53 clandmeter: aha :) 2017-04-05 13:59:01 always much fun 2017-04-05 13:59:22 and i dont have access to ppc hw, so i cant help. 2017-04-05 13:59:39 clandmeter: I guess that we can ask leitao to give us some VM :) 2017-04-05 13:59:57 or just let ncopa fix it ;-) 2017-04-05 14:00:03 clandmeter: they have even a website where you can register to get access to some ppc64le, but I don’t remember the address 2017-04-05 14:00:44 okay, coffee break now and then I must really do a work I’m actually paid for :) 2017-04-05 14:01:04 its actually leitao gromero and rdutra that have been fixing ppc64le 2017-04-05 14:01:21 yes i know 2017-04-05 14:01:40 but will they finish on that pace? 2017-04-05 14:01:44 on time.. 2017-04-05 14:01:49 yes 2017-04-05 14:02:01 ok 2017-04-05 14:03:29 ^7heo: I have updated it. 2017-04-05 14:06:38 I need help with %3184 2017-04-05 14:07:10 I don't know how should I get the file name, should I do find $pkgname-*? 2017-04-05 14:07:17 ls doen't glob. 2017-04-05 14:12:31 <^7heo> pickfire: I've got the mail 2017-04-05 14:13:32 What mail? 2017-04-05 14:13:37 I haven't checked yet. 2017-04-05 14:20:10 scadu, whats the reason we dont have gst py? 2017-04-05 14:22:34 clandmeter: frankly, I don't remember. 2017-04-05 14:25:47 clandmeter: it is 7 or 8 months when mopidy has been moved to unmaintained 2017-04-05 14:35:58 clandmeter, would you like a ppc64le vm? 2017-04-05 14:36:51 leitao, ok, not sure if i can help right away though. 2017-04-05 14:37:09 but could come in handy with failures 2017-04-05 14:38:54 clandmeter, sure. If you need them, just start one at http://openpower.ic.unicamp.br/minicloud/ 2017-04-05 14:39:08 request one machine first, then you have access to a openstack instance, where you can fire up Vms 2017-04-05 14:40:49 done 2017-04-05 14:46:50 leitao: I’ve also submitted request for access, I got an idea: try to run GitLab CI runner on ppc64le :) 2017-04-05 14:47:07 jirutka, that is a good idea. 2017-04-05 15:00:35 ncopa, it seems that all the packages on 'main' are now compiled for ppc64le. 2017-04-05 15:00:38 clandmeter: might by that I have packaged py-gst1, but encountered another issue 2017-04-05 15:00:43 Should we move the target to 'community' now? 2017-04-05 15:01:31 yup 2017-04-05 15:01:36 clandmeter: yeah, probably I showed you and/or ncopa APKBUILDs for new mopidy and py-gst1 including the logs 2017-04-05 15:02:25 could be 2017-04-05 15:02:32 ncopa, ack 2017-04-05 15:03:59 leitao: i changed the build server config so it will halt on first error 2017-04-05 15:04:17 ncopa, right, it should clean up the messages on #alpine-commits now. 2017-04-05 15:04:17 because it spammed the #alpine-commits channel 2017-04-05 15:04:36 ncopa, should we look at the scripts to build the images? 2017-04-05 15:05:03 you mean to build a rootfs image for docker? 2017-04-05 15:05:22 or release images? 2017-04-05 15:05:42 i am not sure what makes sense as release image for ppc64lw 2017-04-05 15:05:44 le* 2017-04-05 15:06:07 ncopa, at the moment, the only one that does not make sense is ISO, since grub is still not "built" 2017-04-05 15:06:13 so, docker and rootfs makes sense 2017-04-05 15:09:59 the idea with rootfs is that should be the base for docker image 2017-04-05 15:10:19 currently the docker image is built separately 2017-04-05 15:33:38 xsteadfastx: clandmeter maybe you will find it useful: http://tpaste.us/Oz86 that's everything I got regarding mopidy. maybe it was a temporary issue with this moddule -- I didn't check later 2017-04-05 17:48:06 also as a note, i'll probably get agda building as well in alpine linux and get a PR out for that, I ported ghc for more reasons than just itself, but alpine linux needs more dependently typed programming languages 2017-04-05 17:48:38 how are things like emacs mode files generally handled? 2017-04-05 17:57:00 hey :) 2017-04-05 17:57:19 what did i read on the ML, grsec will be removed from the kernel? 2017-04-05 18:16:00 <_ikke_> leo-unglaub: grsec is going dark entirely 2017-04-05 18:17:06 hehe, nice. so that project is dead ... because no one is going to pay for security in an os 2017-04-05 18:17:17 its not shiney enought for people to pay for it 2017-04-05 18:18:18 <_ikke_> I believe intel is paying 2017-04-05 18:18:41 intel? are they not the company that fucked them over in the first place? 2017-04-05 18:18:56 <_ikke_> Yeah, and they have to pay now 2017-04-05 18:20:01 hahaha 2017-04-05 18:20:24 _ikke_: why is that? 2017-04-05 18:20:27 and whats alpines plan for new releases? 2017-04-05 18:21:02 <_ikke_> I heard something about apparmor 2017-04-05 18:21:12 <_ikke_> scadu: If they want to use grsec, they have to pay 2017-04-05 18:21:52 hmm, appamor is not the same as what grsecurity did 2017-04-05 18:21:57 _ikke_: I know, I know. I have to read about the details regarding Intel and grsec then ;f 2017-04-05 18:22:39 ask kaniini for the details 2017-04-05 18:23:02 roughly, apparmor+PaX offers the same functionality as what alpine was using in grsecurity 2017-04-05 18:23:27 PaX not portable 2017-04-05 18:23:30 sorry 2017-04-05 18:23:34 looked into it 2017-04-05 18:23:37 it's a mess 2017-04-05 18:24:01 kaniini: may I pm you? 2017-04-05 18:26:06 sure 2017-04-05 18:26:46 leo-unglaub: oh, grsec isn't going "dark", but they clearly like money and would prefer to just deal with people who pay money. 2017-04-05 18:32:13 i have no problem with them making some money, but i am pretty sure no one is buying it 2017-04-05 18:32:27 way to much alternatives out there 2017-04-05 18:33:03 ACTION shrugs 2017-04-05 18:45:06 also first rc for 8.2 got released yesterday, will work on getting that building 2017-04-05 18:45:10 http://downloads.haskell.org/~ghc/8.2.1-rc1/ 2017-04-05 19:42:44 ncopa, any reason we are holding back on gstreamer1? 2017-04-05 19:49:10 clandmeter: sorry, i have not noticed that? 2017-04-05 19:49:22 clandmeter: ping me tm about it please 2017-04-05 19:49:56 ok 2017-04-05 19:52:36 kaniini: sorry for not responding on that grsecurity email 2017-04-05 19:52:52 i think we will keep grsecurity for now and see what happens 2017-04-05 19:53:49 im hoping they will realize that killing the grsecurity "community" and the ecosystem with it will hurt themselves 2017-04-05 19:54:30 it seems like they might realize its not a good idea, but at the same time they will prevent kspp ripping of their work 2017-04-05 19:55:27 if they kill the ecosystem, then their customers will have to build userspace themselves 2017-04-05 19:55:34 i couldn't reply to the mailing list because of a broken mail server, but i agree 2017-04-05 19:56:27 that is true, if we drop grsec 2017-04-05 19:56:34 we probably will stop caring about paxmarking things 2017-04-05 19:56:54 i'd rather that didn't happen as i'll likely still built my own grsec kernels :p 2017-04-05 19:57:31 i guess we keep it for 3.6 then 2017-04-05 19:57:34 and see how this plays out 2017-04-05 19:58:23 ncopa: http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/ca-certificates/ca-certificates-20161130-r1.log 2017-04-05 19:58:27 ncopa: something is really broken here 2017-04-05 20:09:00 huh 2017-04-05 20:09:23 leitao: ^^^ looks like somethign broke pretty bad 2017-04-05 20:09:32 i will check it tm 2017-04-05 20:11:23 ncopa, hmm 2017-04-05 20:11:44 ncopa, how do I restart this build? 2017-04-05 20:22:19 ncopa, it seems something happened on the kernel. "BUG: soft lockup - CPU#6 stuck for 27s!" 2017-04-05 21:14:09 you have fs corruption 2017-04-05 21:14:12 probably need to fix that first 2017-04-05 21:14:19 then service aports-build start 2017-04-05 21:14:24 should in theory do it 2017-04-05 21:15:58 the soft lockup is likely due to an interrupt storm caused by the storage infrastructure (local SAS controller?) reporting errors to the supervisor domain (i do not know the specifics to how this would be on POWER), which means that you probably have a bad disk or your SAN failed 2017-04-05 21:19:53 leitao: ^ 2017-04-05 21:30:19 leitao: it is very important to stop the VM and fsck the disk image from the supervisory domain before starting it again 2017-04-05 21:30:39 kaniini, ok 2017-04-05 21:30:41 let me try that 2017-04-05 21:30:42 if you try to fsck it live, you will make the corruption worse probably 2017-04-05 21:41:11 kaniini, I am not sure this is a file system issue 2017-04-05 21:41:31 I am wondering if a process is stuck in a processor for a long term 2017-04-05 21:41:47 [1131748.030647] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 21s! [cc1plus:15218] 2017-04-05 21:41:55 it always show cc1plus in those CPU stuck 2017-04-05 21:50:23 humm 2017-04-05 21:50:32 leitao: is this dedicated to building alpine packages or? 2017-04-05 21:50:48 leitao: because the other possibility is that the CPU is overcommitted if it is shared 2017-04-05 21:51:06 kaniini, this is a VM on a big machine. 2017-04-05 21:51:11 So, the CPUs are being shared. 2017-04-05 21:51:20 kaniini, so, it might be the case. 2017-04-05 21:51:27 how do I check if it is still finding problem? 2017-04-05 21:52:18 service 'aports-build' does not seem to exist 2017-04-05 21:53:20 kaniini : random stuff. I am booting a kernel + initramfs in kvm. got to the point OpenRC is loaded. then the tty* error : http://tpaste.us/P7Ey. More info is at the end of the paste 2017-04-05 21:53:40 kaniini : would you mind have a look ? 2017-04-05 21:59:16 in the rootfs (example.img), I manually created /dev/tty* 2017-04-05 22:11:36 what filesystem is example.img 2017-04-05 22:11:45 because it sounds to me like ext4 support is not really available 2017-04-05 22:12:24 or actually 2017-04-05 22:12:28 i think actually 2017-04-05 22:12:37 you dont have services you need enabled 2017-04-05 22:12:40 if you chroot into example.img 2017-04-05 22:12:49 what does rc-update say 2017-04-05 22:13:09 because it should be starting mdev very early 2017-04-05 22:13:15 tmh1999: ^ 2017-04-05 22:13:24 example.img is ext4 as described in the paste 2017-04-05 22:14:05 rc-update returns nothing kaniini 2017-04-05 22:14:23 oh dear 2017-04-05 22:14:49 tmh1999: you need to do 2017-04-05 22:14:57 tmh1999: rc-update add bootmisc boot 2017-04-05 22:15:15 tmh1999: and the same for hostname, hwclock, modules, networking, sysctl, syslog 2017-04-05 22:15:25 tmh1999: rc-update add devfs sysinit 2017-04-05 22:15:37 tmh1999: same for dmesg, hwdrivers, mdev 2017-04-05 22:15:58 tmh1999: killprocs/mount-ro/savecache for shutdown 2017-04-05 22:16:05 tmh1999: after you do that you should be able to boot 2017-04-05 22:16:42 kaniini : damn I haven't ack about this 2017-04-05 22:16:54 I am trying them 2017-04-05 22:19:45 scadu: that's exactly what I found out. The module is in site-packages/gi but throw a error when importing. I also tried to build a newer version of gstreamer1 with same results 2017-04-05 22:20:39 xsteadfastx: scadu: I’ve tried that on Fedora and it failed in the same way until I installed pkg gstreamer1-plugins-good, after that import works and mopidy as well 2017-04-05 22:23:45 kaniiini : I did as you said and a bunch of service started. but the tty* error still there 2017-04-05 22:24:01 So you think it's a problem with gstreamer1-plugins-good in Alpine? 2017-04-05 22:24:20 kaniini : ^ 2017-04-05 22:24:46 kaniini : should we avoid checking tty[1-6] ? 2017-04-05 22:24:50 *how 2017-04-05 22:31:20 jirutka: thanks for the extensive review btw :) 2017-04-05 22:31:32 Shiz: you’re welcome :) 2017-04-05 22:32:02 gonna delay that last edit until i get table-sqlite personally working on my machine, i seem to be running into an obscure issue 2017-04-05 22:32:03 :p 2017-04-05 22:32:10 any opinions on that other opensmtpd PR I made? 2017-04-05 22:32:52 Shiz: this one? https://github.com/alpinelinux/aports/pull/1208 2017-04-05 22:33:02 correct 2017-04-05 22:33:28 Shiz: I like changing runscript from smtpd to opensmtpd 2017-04-05 22:34:06 Shiz: but not sure how to provide seamless upgrade path for existing users 2017-04-05 22:34:14 right. 2017-04-05 22:34:30 i guess one easy way could be a post-install/upgrade script 2017-04-05 22:34:57 post-upgrade 2017-04-05 22:35:09 something like 2017-04-05 22:35:18 but I’m not fan of changing some configs in post-upgrade scripts on behalf of user 2017-04-05 22:35:28 maybe just add post-upgrade message warning about this change 2017-04-05 22:35:35 right 2017-04-05 22:35:44 Shiz: like in https://github.com/alpinelinux/aports/blob/master/main/nginx/nginx.post-upgrade#L6 2017-04-05 22:36:25 i can agree that preferably you don't want to dab around too much 2017-04-05 22:36:39 although if /etc/smtpd exists and /etc/opensmtpd doesn't it would be a fairly clean case 2017-04-05 22:54:47 tmh1999: hmm 2017-04-05 22:55:00 tmh1999: are you mounting devtmpfs 2017-04-05 22:55:21 tmh1999: because devtmpfs is needed 2017-04-05 22:55:24 kaniini : I guess I didn't. How so ? 2017-04-05 22:55:32 tmh1999: can you give me latest log 2017-04-05 22:56:13 ahh 2017-04-05 22:56:16 tmh1999: in your kernel, 2017-04-05 22:56:23 tmh1999: you have CONFIG_DEVTMPFS_MOUNT disabled 2017-04-05 22:56:29 tmh1999: but in the other kernels, it is enabled. 2017-04-05 22:56:35 http://tpaste.us/6XM8 2017-04-05 22:56:36 hah 2017-04-05 22:56:38 I see 2017-04-05 22:56:49 I will recompile 2017-04-05 22:58:01 also 2017-04-05 22:58:06 it may be that on s390x 2017-04-05 22:58:19 /dev/tty0 is the only tty you need 2017-04-05 22:58:23 so try messing with /etc/inittab 2017-04-05 22:59:34 kaniini : thanks. let me try and get back 2017-04-05 23:01:49 kaniini: in the apk-tools rewrite, do we plan on upgrading to non-sha1 hashes too? 2017-04-05 23:01:51 :p 2017-04-05 23:02:01 Shiz: yes we are upgrading to md2 hashes 2017-04-05 23:02:04 Shiz: what do you think 2017-04-05 23:02:14 i don't think anything 2017-04-05 23:02:22 Shiz: a whole 128 bits of security. bank level. 2017-04-05 23:03:39 Shiz: but in all seriousness, sha2-512 is likely what will be used 2017-04-05 23:03:44 Shiz: as in apkbuild 2017-04-05 23:03:56 right, i'm thinking of the .SIGN.RSA.* stuff 2017-04-05 23:03:59 fwiw 2017-04-05 23:04:18 also something something eddsa keys would be nice ;P 2017-04-05 23:06:39 yes, that too 2017-04-05 23:06:56 we are probably going to use Ed25519 2017-04-05 23:07:01 but maybe not 2017-04-05 23:07:05 because NSA quit using ECC 2017-04-05 23:07:10 so maybe they know something 2017-04-05 23:07:11 that we do not 2017-04-05 23:07:19 its hard to say either way 2017-04-05 23:07:31 post quantum post quantum post quantum 2017-04-05 23:07:51 i think most likely if they know something, it is a way to linearly attack ECC, i.e. not quantum 2017-04-05 23:08:19 yeah was foolin' 2017-04-05 23:10:19 post quantum ergo proper quantum 2017-04-05 23:11:06 then again, suite B never used RSA in the first place 2017-04-05 23:11:13 so it's hard to correlate with 'just' ECC being dropped 2017-04-06 01:11:32 https://pastebin.com/raw/TbZdhVwq 2017-04-06 01:11:33 hmm... 2017-04-06 02:55:22 https://github.com/SirCmpwn/sway/issues/1139#issuecomment-291476127 2017-04-06 02:55:39 Is there an alternative to paxctl for alpine? 2017-04-06 02:56:00 http://pkgs.alpinelinux.org/packages?name=paxctl&branch=&repo=&arch=&maintainer= 2017-04-06 02:56:02 ? 2017-04-06 03:00:38 Shiz: No, I mean is there other programs that is installed by default that is similar to paxctl? 2017-04-06 03:01:09 why can't you use paxctl? 2017-04-06 03:01:11 not that i know of 2017-04-06 03:02:25 you may be able to use the attr package to set the xattr variant 2017-04-06 03:02:47 setfattr -n user.pax.flags -v m /bin/myfile 2017-04-06 03:02:49 like such 2017-04-06 03:03:02 where what comes after -v is what you'd normally pass to paxctl, minus - 2017-04-06 03:04:48 kaniini: why did paxctl get plonked in edge? 2017-04-06 03:05:12 we only use xattr 2017-04-06 03:05:36 paxmark is the replacement it pretty much works the same as paxctl 2017-04-06 03:05:56 beyond that paxctl is not cross-endian safe 2017-04-06 03:07:00 ah, didn't know of paxmark 2017-04-06 03:07:16 paxmark sets xattrs 2017-04-06 03:07:51 so basically 2017-04-06 03:08:07 got dropped cuz it was outdated and broken for crosscompiling 2017-04-06 03:23:22 kaniini : so I enabled CONFIG_DEVTMPFS_MOUNT, rc-update add services you mentioned. and I have to # rc-update del networking boot because I don't have network config for kvm for now. and I am stuck at this : http://tpaste.us/Vbqz. I guess there is no tty available. 2017-04-06 03:24:21 check your inittab file 2017-04-06 03:24:21 kvm option -append "console=tty0" doesn't help 2017-04-06 03:24:54 try using /dev/console for the getty 2017-04-06 03:25:11 Shiz : I had to disable all tty[1-6] in inittab because it thrown not found error before 2017-04-06 03:25:18 which might be the way to go by default 2017-04-06 03:26:10 kaniini : set it in inittab or kvm option ? 2017-04-06 03:26:16 inittab 2017-04-06 03:28:02 >[ 3.194544] console [ttyS1] enabled 2017-04-06 03:28:05 seems like this is the on you want 2017-04-06 03:28:07 not tty0 2017-04-06 03:30:46 Shiz: How do I get the attr? 2017-04-06 03:30:54 pickfire: apk add attr 2017-04-06 03:30:59 Huh? 2017-04-06 03:31:03 setfattr -n user.pax.flags -v m /bin/myfile 2017-04-06 03:31:17 oh 2017-04-06 03:31:23 getfattr -n user.pax.flags /bin/myfile 2017-04-06 03:32:12 Shiz: Is there any man pages where I can know more about attr and stuff. 2017-04-06 03:32:22 I don't know which to set for /usr/bin/sway 2017-04-06 03:33:11 https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart#paxctl 2017-04-06 03:33:13 flag overview is here 2017-04-06 03:34:26 Shiz : I tried ttyS1 and did't work 2017-04-06 03:34:36 kaniini Shi : /dev/console defintely work ! 2017-04-06 03:34:43 kaniini : thank you :) 2017-04-06 03:34:59 Looks like getcap /usr/bin/sway works as well 2017-04-06 03:37:33 those are entirely different things 2017-04-06 03:37:56 PaX looks complicated. 2017-04-06 03:38:12 not particularly 2017-04-06 03:38:24 Shiz: They called me to do sudo setcap cap_sys_ptrace,cap_sys_tty_config=eip /usr/bin/sway 2017-04-06 03:38:33 And it works 2017-04-06 03:38:39 that has nothing to do with pax 2017-04-06 03:38:47 But still mouse and keyboard doesn't move. 2017-04-06 03:38:59 Shiz: What does that relates to? 2017-04-06 03:39:08 They said it is related to grsec 2017-04-06 03:39:13 http://man7.org/linux/man-pages/man7/capabilities.7.html 2017-04-06 03:39:18 sudo setcap cap_sys_ptrace,cap_sys_tty_config=eip /usr/bin/sway 2017-04-06 03:39:19 it has nothing to do with grsec either 2017-04-06 03:39:31 https://github.com/SirCmpwn/sway/issues/1139#issuecomment-291441398 2017-04-06 03:40:10 the only one mentioning setcap in that thread is you... 2017-04-06 03:40:34 I heard setting capabilities is nice but need a lot of effort compared to setuid bit. 2017-04-06 03:40:50 Shiz: Yeah, they told me to do so. 2017-04-06 03:40:58 https://github.com/SirCmpwn/sway/issues/1139#issuecomment-289421389 2017-04-06 03:41:01 anyway, it has nothing to do with grsec or pax 2017-04-06 03:41:06 that's just linux capabilities 2017-04-06 03:41:14 Shiz: What does it have to do with? 2017-04-06 03:41:20 05:39:12 Shiz │ http://man7.org/linux/man-pages/man7/capabilities.7.html 2017-04-06 03:42:18 Ah 2017-04-06 03:42:29 Shiz: capabilities relates to setcap right? 2017-04-06 03:42:34 yes 2017-04-06 03:42:42 And grsec relates to setfattr 2017-04-06 03:42:47 Oh, I think I get it now. 2017-04-06 03:43:03 Before that, I assume setcap == setfattr 2017-04-06 03:43:04 no, pax relates to the user.pax.flags xattr, which you can manipulate through setfattr 2017-04-06 03:43:11 but yes, they are different things 2017-04-06 03:45:19 tmh1999: so that means we have boot on s390x?? :D 2017-04-06 03:45:47 kaniini : technically I don't call it a boot process ?! 2017-04-06 03:46:02 kaniini : or I don't know 2017-04-06 03:46:05 tmh1999: well i mean you booted to something inside qemu :) 2017-04-06 03:46:26 kaniini : yes :) 2017-04-06 03:46:44 kaniini : it's strange that I did nothing :| 2017-04-06 03:47:09 build the linux-vanilla thing, install it in a rootfs 2017-04-06 03:47:18 then copy /boot/* stuff 2017-04-06 03:47:20 then "boot" 2017-04-06 03:52:19 kaniini : oh man such a feeling 2017-04-06 04:54:07 jirutka: xsteadfastx oh, I missed this one. btw, gst would require update. I will try to take a look this weekend, but I don't promise anything. 2017-04-06 05:47:41 scadu: if you find something out, tell me please :) 2017-04-06 06:38:15 xsteadfastx: sure thing 2017-04-06 09:05:12 clandmeter: im trying to split snapcast into a snapcast-client and snapcast-server subpackage. https://gist.github.com/xsteadfastx/b42ff77704227b40c0c8d1aae424506a is it right that package() is almost empty? or how should i handle that? 2017-04-06 09:09:24 xsteadfastx, yes thats right 2017-04-06 09:09:32 it will be a a meta pkg 2017-04-06 09:09:49 so what you can do is, make it depend on both server and client 2017-04-06 09:10:00 then when you add the meta, it will pull in both. 2017-04-06 09:10:55 ah thats cool 2017-04-06 09:11:19 you could also patch the makefile and remove bash from makedepends 2017-04-06 09:11:31 not sure why he wants bash in makefile 2017-04-06 09:11:48 thats what i though too 2017-04-06 09:12:19 now one question: what about the docs subpackage? 2017-04-06 09:12:28 this fails now 2017-04-06 09:12:45 ah right 2017-04-06 09:12:52 make install... has been removed. 2017-04-06 09:13:23 i would bring back make install... and then move the bins from pkgdir to subpkgdir 2017-04-06 09:13:29 i thought this wasnt needed if i use this as meta package 2017-04-06 09:13:39 and doc would have both server and client man pages. 2017-04-06 09:13:55 it isnt 2017-04-06 09:14:06 but then you need to manually copy the man files 2017-04-06 09:14:24 but... wouldnt apk add snapserver now install just the stuff from make install and not just the subpackages? 2017-04-06 09:15:04 make install.. will install in pkgdir 2017-04-06 09:15:16 it installs the bins and man files (if im correct) 2017-04-06 09:15:51 if you move the bins to subpkgs, then the default_doc function will move the man files to -doc 2017-04-06 09:16:14 so main pkg (pkgdir) will be empty and a meta pkg 2017-04-06 09:16:21 aahhh ok now i understand 2017-04-06 09:16:30 because im moving them out... there are not in there anymore 2017-04-06 09:16:35 so you can do it whatever way you want to do it. 2017-04-06 09:16:35 in the final package 2017-04-06 09:16:48 they way i tell you will save you one line :) 2017-04-06 09:17:19 hehehe... and it makes more sense... and docs are working... i will try it now 2017-04-06 09:17:58 some projects dont have a proper makefile (missing make install) so you will have to copy the bins/files yourself. 2017-04-06 09:19:12 i just hope this guy's code is better then his packaging :) 2017-04-06 09:21:08 i dont know about the code... but the software works pretty neat 2017-04-06 10:05:13 fabled, do we already support LAZY in edge? 2017-04-06 10:22:18 uh? We have two perl-list-moreutils pacakges 2017-04-06 10:22:25 one in main, one in community 2017-04-06 10:23:22 I would remove the one one in community 2017-04-06 10:39:46 xsteadfastx, scadu, jirutka: we fixed mopidy (py-gst1). 2017-04-06 10:39:55 clandmeter: \o/ 2017-04-06 10:40:12 http://tpaste.us/nZkv 2017-04-06 10:40:19 wwuuaaattt??? :) 2017-04-06 10:40:56 unbelievabl 2017-04-06 10:40:58 e 2017-04-06 10:41:04 that makes me really happy 2017-04-06 10:52:02 xsteadfastx: https://git.alpinelinux.org/cgit/aports/commit/?id=7e0a0e26 2017-04-06 10:52:26 clandmeter: wololo, really? 2017-04-06 10:52:43 scadu, yes :) 2017-04-06 10:52:47 clandmeter: I suspected some missing switch, but... 2017-04-06 10:53:14 glad it's fixed. now, the only thing to do is moving mopidy from unmaintained to testing :P 2017-04-06 10:53:33 yeah we could 2017-04-06 10:53:41 do you prefer that over pip? 2017-04-06 10:54:12 clandmeter: not sure, I don't use mopidy on Alpine nowadays. xsteadfastx? 2017-04-06 10:54:22 clandmeter: maybe we could stick with pip for now. 2017-04-06 10:54:58 i will commit py-gst1 to aporst soonish 2017-04-06 10:55:24 \o/ 2017-04-06 10:55:26 i think it needs to have support for both pythons 2017-04-06 10:55:39 I think so 2017-04-06 10:55:44 similar like gobject py 2017-04-06 10:56:22 and ill check if we can upgrade gst to latest stable 2017-04-06 11:01:22 grrrr, error: An unknown error occurred To learn more, run the command again with --verbose. make: *** [Makefile:65: dist] Error 101 2017-04-06 11:01:34 trying to build latest rustc… 2017-04-06 11:02:32 xsteadfastx, i added py-gst1 also to testing (just py2 support for now) 2017-04-06 11:02:47 and I’m already running it with --verbose 2017-04-06 11:03:01 you should be able to add mopidy from pip and make sure you have all gst plugins 2017-04-06 11:04:05 screw it, should go to work instead 2017-04-06 11:05:41 <^7heo> yeah same here 2017-04-06 11:05:45 <^7heo> I just arrived @work 2017-04-06 11:17:02 ^7heo: deref @work 2017-04-06 11:20:31 <^7heo> no please :D 2017-04-06 11:20:34 <^7heo> I need it. 2017-04-06 11:21:11 ok, other way: locate @work 2017-04-06 11:21:21 <^7heo> ah you meant to GET the reference 2017-04-06 11:21:24 <^7heo> not destruct it. 2017-04-06 11:21:26 <^7heo> I see. 2017-04-06 11:21:26 <^7heo> :D 2017-04-06 11:21:30 yeah 2017-04-06 11:43:47 clandmeter, yes, i cherry-picked LAZY stuff to edge 2017-04-06 11:51:29 fabled: what’s LAZY stuff? o.O 2017-04-06 11:52:17 wow, build of the latest rustc did NOT failed! \o/ 2017-04-06 13:06:33 guys, can we add minor release numbers like r7.2 for packages for testing purposes? It does seem that apk discards x.2 or so. 2017-04-06 13:06:52 <^7heo> terra: what software are you referring to? 2017-04-06 13:07:03 <^7heo> also, gpg2 is "broken" 2017-04-06 13:07:15 <^7heo> at least according to its -doc package. 2017-04-06 13:07:17 packages in general 2017-04-06 13:07:29 <^7heo> terra: packages in general don't have a version number starting with r. 2017-04-06 13:08:36 ^7heo: I'm talking about "release" numbers 2017-04-06 13:08:56 <^7heo> terra: you mean patch numbers? 2017-04-06 13:13:33 ^7heo: pkgrel="" in APKBUILD 2017-04-06 13:15:45 <^7heo> yeah that. 2017-04-06 13:16:00 <^7heo> our internal revision numbering. 2017-04-06 13:16:13 for example, musl is r7 now but I'm doing some tests but I don't want to increase package release number during upgrades so I think increasing minor number would be good idea. 2017-04-06 13:16:40 <^7heo> "I don't want to increase package release number" How is that our problem? 2017-04-06 13:16:46 r7.1 detected by apk upgrade but 7.2 doesn't 2017-04-06 13:17:01 <^7heo> look, just increase the $pkgrel 2017-04-06 13:17:22 <^7heo> everyone does that, and unless you have a technical, not religious problem with it, it won't change. 2017-04-06 13:17:39 ^7heo: in that case official release will be discarded.. 2017-04-06 13:18:19 I also want to in track with official releases 2017-04-06 13:18:35 <^7heo> well, not if you send your patch for it. 2017-04-06 13:18:38 <^7heo> and it gets in. 2017-04-06 13:19:04 <^7heo> I don't see anything that cannot be solved by tagging anyway. 2017-04-06 13:19:29 we are talking about different purposes. 2017-04-06 13:19:34 <^7heo> if you install your package with apk add $file.apk it won't get upgraded automatically on apk upgrade AFAIK 2017-04-06 13:19:54 <^7heo> if you install your package via your own repository, just tag it like @personal 2017-04-06 13:20:01 <^7heo> and install musl@personal 2017-04-06 13:21:19 my idea is better because it deviates minimum from official 2017-04-06 13:22:07 <^7heo> whatever, this is a waste of time. 2017-04-06 13:23:01 contrary, I find it very useful if apk supports minor package release number for testing puposes 2017-04-06 13:24:06 <^7heo> the world doesn't orbit around you; submit patch you wrote on your own time, get it rejected, or not, not my problem. 2017-04-06 13:24:21 <^7heo> until then, feel free to use the solution I wrote above. 2017-04-06 13:29:59 ^7heo: neither around you.. 2017-04-06 13:37:48 ^7heo: why is gpg2 broken? 2017-04-06 13:38:10 <^7heo> nmeum: because the documentation documents options that aren't there. 2017-04-06 13:38:31 <^7heo> nmeum: the documentation documents --receive-keys / --recv-keys but only the latter is implemented. 2017-04-06 13:38:31 which ones? 2017-04-06 13:38:44 <^7heo> that ^ at least; I have not found more yet. 2017-04-06 13:39:51 well…send upstream a bug report? :p 2017-04-06 13:39:58 <^7heo> no time for that. 2017-04-06 13:40:09 I know that feel 2017-04-06 13:40:31 <^7heo> The funny thing is that I wasted so much time trying to explain terra how to use apk 2017-04-06 13:40:40 <^7heo> and then I lack time for relevant things. 2017-04-06 13:40:50 <^7heo> well, I'm not good at time management, that is sure. 2017-04-06 13:40:52 :) 2017-04-06 13:40:56 <^7heo> Anyway, laters. 2017-04-06 13:41:00 cu 2017-04-06 13:47:01 i'll jump in and say gpg1 > gpg2 2017-04-06 13:47:02 :p 2017-04-06 13:47:33 <^7heo> Shiz: do we have gpg1 in the repos? 2017-04-06 13:47:39 yes 2017-04-06 13:47:43 it's just called gpg1 2017-04-06 13:47:47 <^7heo> thanks a lot. 2017-04-06 13:47:49 and replaces= gpg2 2017-04-06 13:47:51 afaik 2017-04-06 13:47:54 <^7heo> are both intercompatible? 2017-04-06 13:48:01 <^7heo> ok they must be since they replace each other. 2017-04-06 13:48:01 for most purposes, yes 2017-04-06 13:48:02 <^7heo> ok 2017-04-06 13:48:32 jirutka │ wow, build of the latest rustc did NOT failed! \o/ 2017-04-06 13:48:35 nice, making progress? 2017-04-06 13:49:13 <^7heo> Shiz: I don't find it. 2017-04-06 13:49:27 huuh what the hell 2017-04-06 13:49:38 <^7heo> Shiz: do you mind running `apk info --who-owns $(which gpg1)`? 2017-04-06 13:49:43 oh 2017-04-06 13:49:45 gnupg1 2017-04-06 13:49:47 sorry my bad 2017-04-06 13:49:48 <^7heo> thanks ;) 2017-04-06 13:49:57 <^7heo> better ;) 2017-04-06 13:50:03 and the binary is just called gpg, not gpg1 2017-04-06 13:50:05 :p 2017-04-06 13:50:27 <^7heo> yeah, that's what I was using anyway, and I guess it was a symlink to gpg2 2017-04-06 13:50:29 <^7heo> lemme try that now. 2017-04-06 13:51:39 <^7heo> well, doesn't change anything, tbh 2017-04-06 13:51:58 <^7heo> ah it does. 2017-04-06 13:52:01 <^7heo> The doc is right. 2017-04-06 13:52:01 <^7heo> :D 2017-04-06 13:52:04 :) 2017-04-06 13:52:13 <^7heo> thanks Shiz ;) 2017-04-06 14:08:44 jirutka: https://linux.die.net/man/3/dlopen RTLD_LAZY 2017-04-06 14:26:14 ncopa, we built go 1.8 on alpine/ppc64le from upstream. 2017-04-06 14:26:48 current go version on alpine is 1.7.4 2017-04-06 14:26:57 I think that 1.7.4 has issues with ppc64le. 2017-04-06 14:27:11 Is it possible to bump go to 1.8? 2017-04-06 14:27:25 or maybe disable go on ppc64le for 3.6 2017-04-06 14:29:28 hum 2017-04-06 14:29:34 thtas a good question 2017-04-06 14:29:38 i think we want go 1.8 2017-04-06 14:30:05 there was a pull request for go 1.8 2017-04-06 14:31:16 nice 2017-04-06 14:31:23 it seems like a good thing to include before 3.6 2017-04-06 14:31:28 with the docker community and all 2017-04-06 14:31:33 (same for rust, tbh) 2017-04-06 14:46:29 has anybody planned to build galera packages for alpine? :D 2017-04-06 14:47:33 ah... it's included within the mariadb package 2017-04-06 14:47:53 mosez: "There are no longer separate MariaDB Galera Cluster releases for MariaDB 10.1 and above. Simply download MariaDB (10.1 or above) and configure your cluster as normal." 2017-04-06 14:47:55 yes 2017-04-06 14:47:57 :p 2017-04-06 14:48:11 Shiz: yeah, I’d like to move rust into community before v3.6, but there are some issues not yet solved 2017-04-06 14:48:30 what are we looking at? 2017-04-06 14:48:30 Shiz: currently we use hack to link it dynamically with musl that has some negative consequences 2017-04-06 14:48:39 hmm 2017-04-06 14:48:43 Shiz: but hopefully this can be avoided now 2017-04-06 14:48:48 didn't the latest rust have an option for static/dynamic? 2017-04-06 14:48:55 Shiz: upstream merged support for static/dynamic switching 2017-04-06 14:49:03 :) 2017-04-06 14:49:37 Shiz: next issue is that currently it downloads some crates from internet during build 2017-04-06 14:49:50 and the builder is separate 2017-04-06 14:49:52 yeah 2017-04-06 14:50:24 I hope that I will manage to somehow solve it before v3.6 2017-04-06 14:50:58 do you have a current apkbuild somewhere? 2017-04-06 14:51:20 I’ll push updated apkbuild today at evening 2017-04-06 14:52:10 :) 2017-04-06 14:52:48 would be cool too to get idris/ghc into community for 3.6 too 2017-04-06 14:53:02 agda is... a bit more involved but next on my list 2017-04-06 14:56:29 mitchty: yeah, definitely! 2017-04-06 15:03:24 shiz: are you sure that it's enabled on alpine? i'm not sure which .so should be added as wsrep_provider 2017-04-06 15:05:22 https://forum.alpinelinux.org/forum/installation/installing-mariadb-where-wsrep-provider -.- 2017-04-06 15:06:52 the only wsrep file within the plugins dir is wsrep_info.so.so 2017-04-06 15:07:02 wsrep_info.so of course 2017-04-06 16:32:17 I tried building tup for alpine but it shows tup warning: unshare(CLONE_NEWUSER) failed, and tup is not privileged. Subprocesses will have '.tup/mnt' paths for the current working directory and some dependencies may be 2017-04-06 16:32:21 missed. 2017-04-06 16:32:24 During bootstrap 2017-04-06 16:33:45 What permission do I need to add? 2017-04-06 18:03:19 ncopa: does chromium work for you without the stack size patch for the shutdown detector? 2017-04-06 18:20:31 I don’t know if Rust devs just don’t give a fuck about musl-based systems or their build system is so complex and messed that even they are not able to change wrong assumptions they implemented into it… 2017-04-06 18:21:17 what's up 2017-04-06 18:21:38 just reading some issues about building Rust on musl-based systems… 2017-04-06 18:21:51 like this one https://github.com/rust-lang/rust/pull/40113 2017-04-06 18:22:31 jirutka: #whynotboth 2017-04-06 18:25:51 should I work in community or testing for new packages before commit ? 2017-04-06 18:26:56 terra: new packages → testing 2017-04-06 18:27:36 jirutka: thanks 2017-04-06 18:38:14 jirutka: I believe it's the latter 2017-04-06 18:39:38 it seems that the main problem is that they fucked it up before and now insists on preserving wrong behaviour for backward compatibility… 2017-04-06 18:42:18 I've been briefly using rust this year for embedded development and I believe they fucked up the entire language 2017-04-06 18:43:02 why do you think? 2017-04-06 18:43:14 so 2017-04-06 18:43:15 Conceptually, I like it -- but the details are a mess. 2017-04-06 18:44:03 The language is a work-in-progress, and feels like it. 2017-04-06 18:44:41 well, it’s still young; but they strongly preserve backward compatibility since 1.0 2017-04-06 18:45:55 jirutka: Yeah, that's the problem I think... the language isn't mature enough to have that backwards compatability be a good thing :) 2017-04-06 18:46:24 jirutka: It prevents them from overhauling major design decisions. 2017-04-06 18:46:26 TemptorSent: yeah, I think that I can agree with that 2017-04-06 18:48:31 I tend to agree with TemptorSent. Besides if you are using it without libstd you need nightly features for basically everything 2017-04-06 18:48:58 not for everything, basically just for compiler plugins… 2017-04-06 18:50:50 should we avoid release candidate versions of packages? abuild doesn't accept -rc3 version for instance. 2017-04-06 18:51:04 terra: the correct format is _rc3 2017-04-06 18:51:12 pff 2017-04-06 18:51:18 terra: what? 2017-04-06 18:51:40 terra: and yes, if you don’t have a special reason, then it’s better to stick to stable releases 2017-04-06 18:51:47 jirutka: nothings. thanks btw. 2017-04-06 18:52:02 Query: Preferred default location for staging directory for kernel/mkinitfs? /var/tmp/staging? /var/cache/staging? Something else? 2017-04-06 18:53:12 TemptorSent: what exactly is the staging directory? 2017-04-06 18:54:48 jirutka: The directory to unpack the kernel, modules (including externally packaged), firmware, dtbs, headers, etc. before installation/creating modloop/building initramfs. 2017-04-06 18:55:15 jirutka: As well as staging userspace needed in initfs. 2017-04-06 18:56:03 TemptorSent: /var/tmp 2017-04-06 18:56:19 but not /var/tmp/staging, too general name 2017-04-06 18:56:38 jirutka: Thanks. We don't clear automatically, correct? 2017-04-06 18:56:47 maybe use mktemp? 2017-04-06 18:57:11 jirutka: That doesn't work out well as the name changes each time. 2017-04-06 18:57:14 TemptorSent: I think that /var/tmp is not cleared automatically, but not 100% sure 2017-04-06 18:57:59 mktemp seems fine for this 2017-04-06 18:58:04 not sure why you'd want a certain fixed directory 2017-04-06 18:58:05 jirutka: We want the staging directories to persist, especially for building images or cross/platform 2017-04-06 18:58:52 Shiz: Because it caches the downloaded/extracted files per arch (and per krel for kernel artifacts) 2017-04-06 18:59:18 Shiz: So multiple invocations shouldn't be starting from scratch. 2017-04-06 18:59:19 it should use /var/cache/distfiles for that 2017-04-06 18:59:49 Shiz: That doesn't work for multiple arch apk roots. 2017-04-06 19:00:18 TemptorSent: aha, then /var/cache/ for caching files used for multiple invocations (just these) 2017-04-06 19:00:25 i mean, it should cache the downloads there 2017-04-06 19:00:29 as they are ostensibly agnostic 2017-04-06 19:00:37 and for the building work, just use a mktemp 2017-04-06 19:00:47 . /var/cache// 2017-04-06 19:00:54 Shiz: For each arch, you need to have an apkroot initilized with 'apk --arch $arch -p $root add --initdb' 2017-04-06 19:02:13 jirutka: That's what I was leaning towards, the structure below the root is /// 2017-04-06 19:02:54 /var/cache/mkalpine/staging perhaps? 2017-04-06 19:03:47 so you already have a name for your baby, mkalpine? :) 2017-04-06 19:03:56 Since it will be used by update-kernel, mkinitfs, mkimage, for the modloop 2017-04-06 19:04:12 jirutka: Well, mkimage certainly isn't in scope any more :) 2017-04-06 19:04:44 that’s what terrifies me… 2017-04-06 19:05:17 jirutka: Why? Becasue I seperated functionality into a distinct tool? 2017-04-06 19:05:36 jirutka: That's the unix way :) 2017-04-06 19:05:50 aha, so this is a name for a set of tools/scripts? 2017-04-06 19:06:21 Right now, each tool is handling (or NOT handling in many cases!) staging it's own files. 2017-04-06 19:06:30 aha, okay 2017-04-06 19:06:32 jirutka: Yes, it's a suite of related tools. 2017-04-06 19:06:56 jirutka: With common infrastruture to avoid duplicating things needlessly. 2017-04-06 19:07:06 that sounds good 2017-04-06 19:07:35 jirutka: That way we only have to define arch-specific stuff in one place, rather than having it scattered through scripts with special cases. 2017-04-06 19:09:19 jirutka: And handling custom kernels reduces to a set of definitions for the targets we need (and one custom install step, since the kernel 'make install' target does NOT do what we want) 2017-04-06 19:11:06 jirutka: so it will look something like 'kerneltool --arch s390x --stage all:/usr/src/linux --stage modules:zfs --stage firmware:linux-firmware' 2017-04-06 19:11:36 With zfs and linux firmware using packaged versions. 2017-04-06 19:12:03 It will check the flavor and version match for modules :) 2017-04-06 19:13:02 Syntax not at all set in stone, suggestions welcome. 2017-04-06 19:13:52 It detects the configured arch and kernel release from the build directory or an explicit apk automatically. 2017-04-06 19:17:40 I haven't yet setup anything for downloading/extracting kernel sources, but I've considered how to make it so abuild can use it to build modules for multiple flavors of a kernel at one go. 2017-04-06 19:22:43 Ideally, mkinitfs wouldn't have to deal with modules at all, we can just have it give a list of module sets it wants and let kernel tool figure out the deps and cpio them up for mkinitfs to include. 2017-04-06 19:24:09 That should eliminate most of the initfs breakage since we will know which packages we need installed and check that we've actually included the requested modules AND all deps (depmod -e) 2017-04-06 19:26:00 'mkmodloop' can use the exact same mechanism to allow us to specify modules for inclusion to trim the size depending on the needs of the system. 2017-04-06 19:34:55 jirutka: if you have the apkbuild somewhere, i'd like to take a look ;) 2017-04-06 19:35:01 ACTION feeling up for some apkbuild hacking 2017-04-06 19:35:29 <^7heo> APKBUILDs shouldn't need hacking 2017-04-06 19:37:06 for the best definition of the word hacking 2017-04-06 19:37:08 ;p 2017-04-06 19:37:28 <^7heo> Installing NetBSD on a toaster? 2017-04-06 19:43:27 duncaen: i dont know, i think i just copied the patch from void. (thanks!) 2017-04-06 19:44:11 afaik no, the last commit just changed the version thats why i ask 2017-04-06 19:44:35 <^7heo> ncopa: any chance to release mkinitfs? 2017-04-06 19:44:46 ^7heo: not tonight 2017-04-06 19:45:28 ^7heo: ping me tm and i'll try get it done 2017-04-06 19:46:35 <^7heo> ncopa: awesome thanks 2017-04-06 19:47:26 ncopa, ^7heo: Other than the mkinitfs script itself, initramfs-init, and the /usr/share files, is anything but nlplug-findfs in use? 2017-04-06 19:48:15 (basically, bootchart :) 2017-04-06 19:48:23 not really 2017-04-06 19:48:33 i dont think we have used it for years 2017-04-06 19:48:41 fabled: do we still use bootchart? 2017-04-06 19:48:53 not for a while 2017-04-06 19:48:58 i was hoping to use the new thing 2017-04-06 19:49:06 but it's still work-in-progress 2017-04-06 19:49:14 but we can rip out the old bootchart? 2017-04-06 19:49:18 In other words, could nlplug-findfs become its own package, since it require compilation, and make mkinitfs arch independent? 2017-04-06 19:49:31 TemptorSent: it could 2017-04-06 19:50:10 i just dont think i makes much sense to run initramfs without initramfs-init 2017-04-06 19:50:11 It seems like that might clean up the tree a bit. 2017-04-06 19:50:43 we should probably move all your work out to a separate git tree 2017-04-06 19:50:55 ncopa: Right, but initramfs is a script as opposed to a compiled artifact. 2017-04-06 19:51:44 i can move nlplug-findfs out to separate git repo if you feel strong for it 2017-04-06 19:51:54 ncopa: Agreed. If you approve, perhaps a top-level mkalpine for all of the various mk-tools? 2017-04-06 19:51:58 or we could create a subpakcage of it 2017-04-06 19:52:25 ncopa: I don't feel terribly strongly about it, but I figure it would make tracking it in git much clearer. 2017-04-06 19:52:33 ok 2017-04-06 19:53:27 ncopa: That way changes to scripts don't change the repo for nlplug-findfs and make merges more complex. 2017-04-06 19:54:29 initramfs-init is kind of tied to nlplug-findfs though 2017-04-06 19:54:50 We have the existing tools of mkinitfs, mkimage, and update-kernel, to which I would like to add mkmodloop and kerneltool. 2017-04-06 19:55:15 sounds good to me 2017-04-06 19:55:36 so we keep nlplug-findfs in separate repo 2017-04-06 19:55:58 and the others in your new repo? 2017-04-06 19:56:30 and make mkinitfs a subpackage of alpine-mktools? 2017-04-06 19:56:35 ncopa: Not necessarily, as nlplug-findfs could be used by someone rolling their own without the tools, and we could use mkinitfs to make inits that use very simple shims without nlplug-findfs 2017-04-06 19:57:18 ok 2017-04-06 19:57:25 do subpackage dependencies implicitly inherit the dependencies of the main package? 2017-04-06 19:57:41 I'm trying to install librbd, and it brings in all of ceph, but from https://git.alpinelinux.org/cgit/aports/plain/testing/ceph/APKBUILD, it doesn't look like it should need to 2017-04-06 19:57:51 tsuraan: no 2017-04-06 19:57:55 or well 2017-04-06 19:57:59 tsuraan: i think it does 2017-04-06 19:58:00 if the subpackage didn't override depends=, then yes 2017-04-06 19:58:07 if it does, only if the override includes $depends 2017-04-06 19:58:09 :P 2017-04-06 19:58:15 ncopa: That would work, I'd have to make a couple changes to the layout of the dirs, but that's no problem. 2017-04-06 19:58:20 so if the subpackage doesn't specify any deps, yes it wil 2017-04-06 19:58:30 in this case, the override for librbd() does replace depends with "librados" 2017-04-06 19:58:47 and then, librados doesn't replace depends. so it's inheriting everything. makes sense 2017-04-06 19:58:59 TemptorSent: how the git repo dirs are organized and how we make subpackages is not really related 2017-04-06 19:59:06 mama mia what a package 2017-04-06 19:59:35 the ceph one? yeah, it's pretty good :) 2017-04-06 19:59:56 ncopa: Right, but it would make more logical sense than pulling files from three different directories. 2017-04-06 20:00:17 nah 2017-04-06 20:00:28 when we build a package 2017-04-06 20:00:33 and "make install" 2017-04-06 20:00:34 ncopa: There is a subset of files used by all tools. 2017-04-06 20:01:04 the source file organization becomes completely irellevant 2017-04-06 20:01:11 oh 2017-04-06 20:01:19 so you have some shared files 2017-04-06 20:01:32 thats no problem 2017-04-06 20:01:32 ncopa: So if we want to have just what we need for mkinitfs, and not necessarily everything for mkimage, it would make sense to change a few things. 2017-04-06 20:01:46 sure 2017-04-06 20:01:49 does alpine have a good way to provide different versions of a package? My ceph cluster is currently at 10.2, while 11.2 is probably recommended, and 12.x is coming out. 2017-04-06 20:02:04 mkinitfs needs to run alone 2017-04-06 20:02:30 tsuraan: not particularly right now 2017-04-06 20:02:38 we typically solve it with different packages 2017-04-06 20:02:46 (and replaces= if they conflict with eachother) 2017-04-06 20:02:49 ncopa: Basically, the mkimage branch I have includes mkimage, mkinitfs, and update-kernel as modular components. 2017-04-06 20:02:50 or conflicts= 2017-04-06 20:03:06 good 2017-04-06 20:03:13 but some shared shell functions? 2017-04-06 20:03:27 i think we can sort that out 2017-04-06 20:03:29 ncopa: so mkinitfs needs to know about it's feature and load those. 2017-04-06 20:03:48 okay, that'll work for me 2017-04-06 20:04:07 need to go 2017-04-06 20:04:07 ncopa: the plugin loader can already handle it, and the mkinitfs wrapper script is only loading a subset already. 2017-04-06 20:04:26 ncopa: Okay, take care, and thanks for the input! 2017-04-06 20:04:27 TemptorSent: thanks for working on this 2017-04-06 20:05:01 ncopa: No problem, it will help save a few shreds of my sanity in the long run :) 2017-04-06 20:06:34 ncopa: It also will stage everything, create manifests, and cache the stage dir per arch/krel, so we don't have to keep doing the same thing over and over again :) 2017-04-06 20:07:31 ncopa: mkmodloop will be able to use the same feature sets as mkinitfs with very little additional work, for instance. 2017-04-06 20:09:10 perfect 2017-04-06 20:09:18 thats what i wanted for some time 2017-04-06 20:09:32 im super happy that you help us clean up the mess :) 2017-04-06 20:14:22 :) 2017-04-06 20:21:29 ncopa: I still have a bit more rolling-refactoring to do before it's all cleaned up, but it's moving that way while still keeping compatability with the old system as close as possible. 2017-04-06 20:24:33 ncopa: One BIG request for apk -- can we have 'apk search -x' allow searching with the full atom, for instance 'apk search -x linux-grsec-4.9.20-r0'? 2017-04-06 20:25:09 ncopa: That's one of the big problems I'm having to work around currently. 2017-04-06 20:28:01 ncopa: The other is extracting a manifest with signatures from the .apk, although I have an awk script that appears to work reading the tar file directly :) 2017-04-06 20:44:21 Question, how do we specify an arch and kernel release combination? is $arch/$krel appropriate? 2017-04-06 20:45:30 (i.e. 'x86_64/4.9.20-0-grsec') 2017-04-06 20:46:36 Or is ${arch}_${krel} better? (i.e. x86_64_4.9.20-0-grsec) 2017-04-06 20:48:12 should I subscribe alpine-aports mailing list before sending patches via git? 2017-04-06 20:49:21 The former is convenient for dir structure, and my preference if not objectionable for some unforseen reason. 2017-04-06 20:50:48 And is there an existing notation for packages including arch? 2017-04-06 20:54:18 oh, I just saw my post on aports mailing list :) 2017-04-06 20:56:12 TemptorSent: the existing convention is ::, afaik 2017-04-06 20:56:20 e.g. mypkg::noarch 2017-04-06 20:56:51 but that my just be an artifact of some implementation thing in abuild 2017-04-06 21:29:46 well found a bug in the ghc testsuite for 8.2 :) 2017-04-06 21:30:20 also learnt of a new "feature" of python 3.6 argv handling 2017-04-06 21:38:48 oh? 2017-04-06 21:39:24 yeah if you pass a tuple in, don't do this ("", ...) or if you have to, do (" ", ...) 2017-04-06 21:39:32 the first is invalid in 3.6 2017-04-06 21:51:11 Shiz: Thanks. I'm afraid the colon may break things in odd ways, but I suppose that could be mitigated with some escaping... 2017-04-06 21:52:29 Shiz: For instance, what would you get if you used that format in a url? 2017-04-06 21:52:47 why would you use it in a url 2017-04-06 21:53:54 Shiz: Because you may want to use it in a script that pulls configs from a remote site. 2017-04-06 21:54:15 seems like overengineering 2017-04-06 21:54:31 Shiz: Not that it's currently implemented, but I can see the feature being useful to many. 2017-04-06 21:54:37 colons work fine in urls, so? 2017-04-06 21:55:30 Shiz: They sometimes need to be escaped. 2017-04-06 21:56:01 then curl or wget can handle that 2017-04-06 21:56:05 Shiz: But the point is that the colon is treated as a special char by the fs and such. 2017-04-06 21:56:10 no? 2017-04-06 21:56:18 : is not a special char in any *nix file system that i know of 2017-04-06 21:56:51 Shiz: Many tools treat it as the host:file. 2017-04-06 21:56:57 please don't highlight me every line 2017-04-06 21:57:03 tar for instance. 2017-04-06 21:57:12 that has nothing to do with the file system, and that's the problem of those tools 2017-04-06 21:58:30 Okay, I can't use it transparently as a file name, how about that? 2017-04-06 21:58:46 but you can 2017-04-06 21:58:51 Just like I can't name files with a leading '-' and expect them to be handled correctly. 2017-04-06 21:59:02 but you also can 2017-04-06 21:59:11 that's what -- was invented for 2017-04-06 21:59:46 'touch a::b ; tar -cvf blah::blah.tar a::b' 2017-04-06 22:00:02 Try it. 2017-04-06 22:00:30 Having to use -- every invocation isn't reasonable, and not all tools even support it! 2017-04-06 22:01:13 it worked 2017-04-06 22:01:15 do i win now? 2017-04-06 22:01:51 even if it didn't, you can't reasonably expect to workaround every shitty piece of software that thinks it needs to be clever 2017-04-06 22:01:53 Okay, let me clarify my criteria: I need a fs-transparent means of indicating arch/pkgname-pkgver. 2017-04-06 22:02:10 if some tar implementation doesn't accept filenames with colons, it's that tar implementation's fault 2017-04-06 22:02:14 : is fs-transparent 2017-04-06 22:02:30 Then why does the shell want to quote it in completion? 2017-04-06 22:02:53 i don't know, posix doesn't say it should 2017-04-06 22:02:58 http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html 2017-04-06 22:03:01 The application shall quote the following characters if they are to represent themselves: 2017-04-06 22:03:03 | & ; < > ( ) $ ` \ " ' 2017-04-06 22:04:02 type 'echo "$PATH"' 2017-04-06 22:04:24 what about it 2017-04-06 22:20:57 I'm trying to break LESS things unintentionally. 2017-04-06 22:24:30 So if ::$arch is used safely and universally already, that's fine, but if it's an artifact from on particular use that never was considered in terms of using it elsewhere, I'd prefer not to perpetuate that. 2017-04-06 22:25:31 But the inability for the tar built into busybox to handle it in an output filename is enough to cause problems without having to look very hard. 2017-04-06 22:29:23 Whereas the '/' does the right thing automatically and creates the tar file under the arch dir, with the requirement the directory exist, and '_' allows for flattening the filesystem, if that is desirable. 2017-04-06 22:30:47 busybox tar can handle it just fine though? 2017-04-06 22:30:51 you're thinking of gnu tar, probably :p 2017-04-06 22:31:17 but yeah im not sure on arch conventions, i think fabled would know best 2017-04-06 22:32:07 Thank you. And I get an io error when I try on my system. 2017-04-06 22:32:32 It looks like I did end up with gnu tar on here somehow :/ 2017-04-06 22:35:14 And the sad thing is that NONE of the tar programs available in packages that I've found can acutally read the PAX headers and spit them out properly! 2017-04-06 22:36:47 ;p 2017-04-06 22:36:55 i think gnu tar may be part of build-base or alpine-sdk 2017-04-06 22:37:32 Yeah, I didn't notice that it had overwritten the bb link. 2017-04-06 22:37:46 $ apk info -r tar 2017-04-06 22:37:48 tar-1.29-r1 is required by: 2017-04-06 22:37:50 abuild-2.29.0-r2 2017-04-06 22:38:19 Yeah, I'll have to make sure and test against bb tar explicitly and make sure no gnuisms get in there. 2017-04-06 22:41:34 Anyway, I'm working on unmangling the kernel/module installation handling, hence the interest. 2017-04-06 22:42:04 hey, as long as you retain the option to build an initramfs without any kernel stuff in it 2017-04-06 22:42:06 :p 2017-04-06 22:43:50 Actually, that's largely what I'm working on improving. 2017-04-06 22:44:24 And fixing it so it actually makes sure you have the required packages you need to install the files in the initfs features. 2017-04-06 22:45:51 The entire kernel staging mess for modloop,update-kernel, and mkinitfs is getting extracted to its own tool. 2017-04-06 22:46:52 Currently, it will silently fail in an unbootable manner if something didn't update right during an upgrade. 2017-04-06 22:47:21 This way, the upgrade is essentially atomic. 2017-04-06 23:27:23 jirutka: you around? 2017-04-06 23:27:34 kaniini: sort of… 2017-04-06 23:27:48 jirutka: i think i have a solution to this php5/php7 php-config conflict 2017-04-06 23:27:58 kaniini: continue… 2017-04-06 23:28:10 jirutka: we just use .post-install script to set up the symlink to the right php-config binary (ghetto alternatives) 2017-04-06 23:28:19 kaniini: no 2017-04-06 23:28:30 jirutka: that is all we can do 2017-04-06 23:28:51 kaniini: how you can specify what should be the default? 2017-04-06 23:29:36 jirutka: the idea is that php-config by default points to php-config7, but if it does not already exist, then php-config5 could claim it. but php7-dev will always set it to php-config7. 2017-04-06 23:31:02 kaniini: I really don’t like idea of introducing semi-working hackish update-alternatives in this way; since we agreed to keep only php5 pkg and use it as dependency only in app pkgs that require php5, it’s imo better to just add version suffix to all php5 binaries (without any symlinks 2017-04-06 23:31:10 or to let them in conflict 2017-04-06 23:31:56 jirutka: i can go that way too. but i intend to solve this now, as in right now. so i will go that way 2017-04-06 23:32:25 it is blocking my rebuild 2017-04-06 23:32:25 I’m afraid that once we do this, other will start using it too and there will not be motivation to create a real solution instead of this hack 2017-04-06 23:32:43 i agree 2017-04-06 23:32:57 lets just fix php5 by removing the php-config symlink (and make it php-config5 instead) 2017-04-06 23:33:03 I’d prefer to start with removing php5-* pkgs 2017-04-06 23:33:09 then add version suffix to php5 2017-04-06 23:33:18 this should solve issue with building 2017-04-06 23:33:59 do you know which php5-* packages can be nuked? 2017-04-06 23:34:04 there are also two PRs from Vakartel about refactoring php5/php7 pkg, but it’s really huge and still didn’t have time and mood to review it 2017-04-06 23:34:29 IIRC Valery said that basically all of them 2017-04-06 23:34:58 b/c existing pkgs that require php5, like phpldapsomething, don’t need any php5-* extensions 2017-04-06 23:35:15 remove everything and see what builds 2017-04-06 23:35:17 :p 2017-04-06 23:39:09 omg, rustc doesn’t work, b/c it somehow hard-coded wrong absolute paths into rlibs >_< 2017-04-06 23:39:32 oh! i think i had that one too 2017-04-06 23:39:33 fun innit 2017-04-06 23:40:26 or at least it looks like this… 2017-04-06 23:40:34 not entirely sure when reading stack trace again 2017-04-06 23:41:01 hm, looks more like two unrelated issues 2017-04-06 23:41:21 crt1.c:(.text+0x0): multiple definition of `_start' 2017-04-06 23:41:29 what does this really mean? 2017-04-06 23:42:42 jirutka: it means crt1.o got linked in twice 2017-04-06 23:42:45 i think 2017-04-06 23:42:50 huh 2017-04-06 23:43:14 maybe it's also foolishly linking in crt1.o into libraries? 2017-04-06 23:43:20 okay, gonna write bug report 2017-04-06 23:43:34 i don’t know; I’ve used this patch https://github.com/rust-lang/rust/pull/40113 2017-04-06 23:43:36 or maybe it supplies its own start() 2017-04-06 23:43:38 probably not complete yet? 2017-04-06 23:43:39 but that sems VERY unlikely 2017-04-06 23:43:54 jirutka: have you looked at void's patch for the same? 2017-04-06 23:44:07 Shiz: yes, they use my old method 2017-04-06 23:44:10 ah 2017-04-06 23:44:36 Shiz: that has some negative consequences, so not really suitable for anything but testing 2017-04-06 23:44:49 gotcha 2017-04-06 23:44:49 Shiz: this patch should be more clean, but something is still fucked 2017-04-06 23:45:05 the latest comment in that link: 2017-04-06 23:45:07 "About figuring out when to pass -nostdlib and crt*, I found the easiest way to get things working both shared and static was to remove them entirely. In other words, if we just let the linker find libc and the startup files, we don't need any overriding at all (no linker flags, no musl root), as long as the linker knows where to find the files. And if the compiler is native, an appropriate cross linker 2017-04-06 23:45:09 exists, or musl-gcc exists, that is a valid assumption. " 2017-04-06 23:45:11 this seems like the ideal approach 2017-04-06 23:45:15 but not what the PR does right now 2017-04-06 23:45:56 I heard that Julia is quite fucked… and still it was so less pain to build it on musl, just a matter of days 2017-04-06 23:45:57 so the appropriate change seems to be to remove it passing -nostdlib and the crt files 2017-04-06 23:46:13 it’s almost a year since I started dealing with this 2017-04-06 23:46:16 i think rust's main issue is simply treating musl as a non-native target 2017-04-06 23:46:29 I’ve already removed -nostdlib 2017-04-06 23:46:38 jirutka: then don't pass crt*.o either 2017-04-06 23:46:40 that is your issue 2017-04-06 23:46:42 :p 2017-04-06 23:46:43 hmm, but how? 2017-04-06 23:46:58 https://github.com/rust-lang/rust/pull/40113/files#diff-76b86accb738e520d5b72633f76a77f5L59 2017-04-06 23:47:00 remove this 2017-04-06 23:47:09 haa 2017-04-06 23:47:14 and the stuff around it 2017-04-06 23:47:31 the crt*.o stuff is implied if you don't pass -nostdlib 2017-04-06 23:47:39 no wonder you get a dupe start definition if you als pass it explicitly 2017-04-06 23:47:42 they get linked in twice :D 2017-04-06 23:47:54 btw every bigger software team, especially when developing new lang, should have at least one person with experience from packaging for some linux distro 2017-04-06 23:48:03 these all issues would not happen then 2017-04-06 23:48:13 well, the issue here is, this all works for glibc 2017-04-06 23:48:24 their problem is treating musl like primarily an xcompile/non-native target 2017-04-06 23:48:27 which leads to huge issues for us 2017-04-06 23:48:28 grrrr 2017-04-06 23:48:31 no, the issue is that they made some very stupid assumptions and they are rooted to bones of their build system 2017-04-06 23:48:32 we need to solve this php5 thing 2017-04-06 23:48:40 kaniini: yes 2017-04-06 23:48:44 kaniini: like i said :P 2017-04-06 23:48:45 kaniini: it’s broken as hell, I know 2017-04-06 23:48:47 remove all php5- packages 2017-04-06 23:48:50 see which builds break 2017-04-06 23:48:55 re-add the ones that are needed 2017-04-06 23:49:09 kaniini: but why it bothers you now? already branching v3.6? 2017-04-06 23:49:26 Shiz: no, this is not a good approach… we already seen this and it created a lot of mess 2017-04-06 23:49:37 okay 2017-04-06 23:49:45 jirutka: i am doing a rebuild on my own machines to determine where we are at 2017-04-06 23:49:52 kaniini: aha 2017-04-06 23:50:00 so just remove all php5 craps locally? 2017-04-06 23:50:15 jirutka: fwiw i was never claiming to do it in the main git 2017-04-06 23:50:17 just locally 2017-04-06 23:50:18 do you know what mailing list or github or whatever 2017-04-06 23:50:20 for testing 2017-04-06 23:50:23 vakartel said this plan on 2017-04-06 23:50:33 because i can test it, but i need to know what he actually proposed 2017-04-06 23:50:58 kaniini: https://github.com/alpinelinux/aports/pull/1061 (bottom of page) 2017-04-06 23:51:12 ok 2017-04-06 23:51:18 i was looking in patchwork and aports list 2017-04-06 23:51:22 kaniini: he hasn’t, I’ve proposed solution after discussion with few core devs (including you actually :P) 2017-04-06 23:51:55 kaniini: the last patch for php I’ve seen in Patchwork from Vakartel was just trying to broke it even more 2017-04-06 23:52:27 okay 2017-04-06 23:52:32 i see what to do on 1061 2017-04-06 23:52:39 kaniini: he added replaces= to php5/php7… imo he doesn’t have a clue what it really means, because it would totally broke it 2017-04-06 23:52:39 i will test it and if it is good, i will push 2017-04-06 23:52:54 it is nice having an e5-2690v2 sitting in my closet 2017-04-06 23:53:02 i can sit here and do test runs all day 2017-04-06 23:53:04 only v2? 2017-04-06 23:53:05 pleb 2017-04-06 23:53:07 :p 2017-04-06 23:53:19 i will start a go fund me 2017-04-06 23:53:21 to get a new one 2017-04-06 23:53:24 if u want to donate 2017-04-06 23:53:28 :))))) 2017-04-06 23:54:15 kaniini: 1061 looks okay, but I read it only in hurry 2017-04-06 23:54:53 ACTION has a E5-2679 v4 lying around 2017-04-06 23:55:00 kaniini: only single CPU board? 2017-04-06 23:55:16 dual cpu 2017-04-06 23:55:39 kaniini: I use 2 * 12 cores / 64 GiB RAM / 2x VelociRaptor for testing :P 2017-04-06 23:55:43 40 threads total 2017-04-06 23:55:47 256gb ram 2017-04-06 23:55:55 uh… ookay… 2017-04-06 23:56:13 I’m ashamed now XD 2017-04-06 23:56:26 hehehe 2017-04-06 23:56:29 i have 3 of them 2017-04-06 23:56:33 wut?! 2017-04-06 23:56:36 i am going to make a rebuild server someday 2017-04-06 23:56:41 that lets me build in parallel across all 3 2017-04-06 23:56:44 I should say my boss that I need new servers… 2017-04-06 23:57:07 something like debian's rebuildd 2017-04-06 23:57:20 except obviously working with aports trees 2017-04-06 23:57:22 instead 2017-04-06 23:57:50 jirutka: you can get cheap v2s on ebay these days too 2017-04-06 23:58:15 yes, these 3 came from eBay 2017-04-06 23:58:16 probably 2017-04-06 23:58:17 some vps company 2017-04-06 23:58:18 or some such 2017-04-06 23:58:30 Shiz: I don’t wanna pay for them, I have already many servers around, just no one so powerful :/ 2017-04-06 23:58:37 heh 2017-04-06 23:58:49 i had to replace the HDDs though 2017-04-06 23:58:52 my only server is an E3-1231 v3 2017-04-06 23:58:54 they all basically failed 2017-04-06 23:59:07 cuz they were seagate junk 2017-04-06 23:59:11 replaced them with HGST 2017-04-06 23:59:13 i was considering making my next workstation from second hand xeons 2017-04-06 23:59:18 seems OK so far 2017-04-06 23:59:21 you can get 40 cores + mobo + 64gb ram for... #350 2017-04-06 23:59:23 $350 2017-04-06 23:59:25 roughly 2017-04-06 23:59:30 40 threads* 2017-04-06 23:59:53 anyway 2017-04-07 00:07:09 okay, next round (rustc) 2017-04-07 00:08:02 progress? 2017-04-07 00:09:55 compiling 2017-04-07 00:10:57 it takes forever to compile it 2017-04-07 00:11:21 seems to solve it 2017-04-07 00:11:37 no dependency graph breaks 2017-04-07 00:11:48 more cleaning is necessary though 2017-04-07 00:12:27 i was wondering... 2017-04-07 00:12:34 what happened to py3-pip? 2017-04-07 00:12:46 humm 2017-04-07 00:12:48 should be there 2017-04-07 00:13:28 tried to install it in a docker container for alpine:3.5 and it gave a weird dependency break that the resolver couldn't print 2017-04-07 00:13:35 and couldnd't find it on pkgs.a.o either 2017-04-07 00:13:45 humm 2017-04-07 00:13:48 python3 provides pip 2017-04-07 00:13:54 so there’s no separate py3-pip pkg 2017-04-07 00:14:02 python3 may want to provides=py3-pip 2017-04-07 00:14:05 just to avoid surprises 2017-04-07 00:14:16 jirutka: i figured that was the case, just wondering on why it broke apk 2017-04-07 00:14:18 I think that it’s alrewady there, but not sure now 2017-04-07 00:14:18 :p 2017-04-07 00:14:24 (it's not) 2017-04-07 00:14:38 yes, provides=py3-pip 2017-04-07 00:14:38 oh wait 2017-04-07 00:14:42 i was on the wrong branch 2017-04-07 00:14:47 still weird that it broke apk then 2017-04-07 00:15:29 IIRC there’s some problem when it’t used in makedepends 2017-04-07 00:15:37 it doesn’t not resolve it via provides 2017-04-07 00:15:50 however, there should not be any makedepends=py3-pip in aports tree… 2017-04-07 00:16:03 and it’s really not 2017-04-07 00:16:08 so where’s the problem? 2017-04-07 00:16:09 i just did # apk add py3-pip 2017-04-07 00:16:12 and it broke it 2017-04-07 00:16:21 i'll try to repro 2017-04-07 00:16:23 1sec 2017-04-07 00:16:33 it do nothing when I run it 2017-04-07 00:16:46 maybe my alpine:3.5 base is outdated 2017-04-07 00:16:46 maybe b/c I have python3 currently installed? 2017-04-07 00:18:06 okay, repro'd 2017-04-07 00:18:10 it doesn't repro when I *just* add it 2017-04-07 00:18:24 https://txt.shiz.me/ZjQyZjFjYT 2017-04-07 00:18:32 ^ docker log 2017-04-07 00:19:42 if i add python3 to that add line it works 2017-04-07 00:21:34 fffff 2017-04-07 00:21:39 i wonder if provides broke in apk-tools 2017-04-07 00:21:59 okay, i will look into that 2017-04-07 00:22:06 because it used to work 2017-04-07 00:22:11 lemme see if updating my alpine base image works 2017-04-07 00:22:22 i'm fixing php5 first 2017-04-07 00:22:30 nope 2017-04-07 00:22:36 huh, supervise-daemon doesn’t have any option how to limit how many times it can restart crashed service?! 2017-04-07 00:24:35 nope, doesn't look like it 2017-04-07 00:24:37 from the code either 2017-04-07 00:24:58 I know that skarnet warned me… 2017-04-07 00:25:09 but that it’s really soo bad? 2017-04-07 00:25:21 it's just very simple, mostly 2017-04-07 00:25:40 I’d say even dangerous if it doesn’t have any limits 2017-04-07 00:25:40 i still have dreams of one day finishing my own hybrid rc of openrc and s6 :p 2017-04-07 00:25:50 s6 for supervision, openrc for the... interface 2017-04-07 00:26:38 if this run passes 2017-04-07 00:26:57 i am pushing php5 change 2017-04-07 00:27:09 seems prudent to check with the ohters first 2017-04-07 00:27:34 Shiz: that’s exactly what I’d like to have too! 2017-04-07 00:27:42 :) 2017-04-07 00:28:16 so I’ve tried to use supervise-daemon, start service, kill it multiple times, every time it started it again… what could possibly go wrong… 2017-04-07 00:28:31 free ASLR bruteforce vector 2017-04-07 00:28:33 ;P 2017-04-07 00:32:11 “One reason the Omnibus package is more reliable is its use of Runit to restart any of the GitLab processes in case one crashes.” … yeah, when it constantly crashes, just use supervisor to restart it immediately… sure… very reliable… omfg 2017-04-07 00:32:58 “The GitLab Rails application code suffers from memory leaks. For web requests this problem is made manageable using unicorn-worker-killer which restarts Unicorn worker processes in between requests when needed.” … sarcasm? 2017-04-07 00:33:25 lol 2017-04-07 00:33:33 gitlab is not great resource-wise 2017-04-07 00:33:35 in my own experience 2017-04-07 00:33:36 it’s from official manual 2017-04-07 00:33:38 switched to gitea and it's a delight 2017-04-07 00:33:43 I know 2017-04-07 00:33:44 i had to restart gitlab every ~20 hours 2017-04-07 00:33:47 because it would just hang 2017-04-07 00:33:57 that must be a problem on your side 2017-04-07 00:34:11 ¯\_(ツ)_/¯ 2017-04-07 00:34:14 i used the official docker image 2017-04-07 00:34:23 I manage GitLab on faculty for… hmm… 4 years? and I don’t remember any situation when I needed to restart it 2017-04-07 00:34:36 and ofc it runs on Alpine :) 2017-04-07 00:34:49 https://github.com/jirutka/user-aports/tree/v3.5/bundles/gitlab-ce 2017-04-07 00:34:55 gitlab is fine without omnibus. it is not good with omnibus. 2017-04-07 00:34:57 all i know is that the site wouldn't load anymore 2017-04-07 00:35:01 or the ssh 2017-04-07 00:35:01 aha, that’s why it crashes :) 2017-04-07 00:35:11 and restarting the container would fix it 2017-04-07 00:35:18 heh 2017-04-07 00:36:12 I should finally write to GitLab and offer them my packages; i’m quite tired updating them and fixing what they screwed all the time :/ 2017-04-07 00:36:43 upstream them to alpine 2017-04-07 00:36:45 :p 2017-04-07 00:37:08 1st I can’t, beucase it’s a bundle, so it violates Alpine policy :/ 2017-04-07 00:37:24 2nd who else would maintain it? ;) 2017-04-07 00:37:41 but I’d like to open discussion about adding new repository: bundles, for stuff like this 2017-04-07 00:38:08 b/c it’s total nonsense to package very GitLab’s dependency separately 2017-04-07 00:38:35 uff, so pkg upgrade to 8.17.5 almost finished 2017-04-07 00:38:54 that's why people use containers :P 2017-04-07 00:38:58 how's rustc? 2017-04-07 00:39:08 to restart them all the time…? XD 2017-04-07 00:39:14 no, still compiling… 2017-04-07 00:40:28 one of these days i may make a PR against gitea for LDAP group support 2017-04-07 00:40:33 so much stuff lacks LDAP group support :/ 2017-04-07 00:41:02 I’d rather write truly lightweight alternative in some sane lang… 2017-04-07 00:42:12 i've got little issues with gitea 2017-04-07 00:42:17 not a huge fan of go, but it seems light enough 2017-04-07 00:42:25 with a good set of features 2017-04-07 00:45:13 Shiz: rustc still doesn’t work :( 2017-04-07 00:45:19 :( 2017-04-07 00:45:22 same err? 2017-04-07 00:45:36 Shiz: https://hastebin.com/raw/lamewiwaze 2017-04-07 00:45:54 ah 2017-04-07 00:45:58 tihs is just forgetting -lunwind 2017-04-07 00:46:00 i think 2017-04-07 00:46:11 or -lgcc_eh? 2017-04-07 00:46:13 one of these two 2017-04-07 00:46:18 but where the heck should I add it? 2017-04-07 00:46:29 and why it’s not here already? 2017-04-07 00:47:34 libunwind is somewhat special 2017-04-07 00:47:36 iirc 2017-04-07 00:48:07 jirutka: see if 2017-04-07 00:48:16 /usr/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-1e0a4dc78495337e.rlib 2017-04-07 00:48:18 has that symbol 2017-04-07 00:48:47 why oh why are people talking about supervise-daemon 2017-04-07 00:48:56 go to bed skarnet :p 2017-04-07 00:49:10 yes daddy 2017-04-07 00:49:47 skarnet: I’ve just discovered that you were not overreacting when you said that it’s a total shit 2017-04-07 00:50:01 I was being moderate 2017-04-07 00:50:17 jirutka: https://github.com/rust-lang/rust/blob/1a9b382168cbf405589fbba7215ace700c067879/src/libunwind/build.rs#L17 2017-04-07 00:50:19 but hey, there's worse: immortal 2017-04-07 00:50:19 the issue right here 2017-04-07 00:50:34 i think 2017-04-07 00:51:21 Shiz: this is patched in that PR 2017-04-07 00:51:29 what does the new ver say? 2017-04-07 00:53:55 ah, i see it now 2017-04-07 00:54:05 https://github.com/smaeul/rust/blob/706fc559532f24e77d0f0c1319723848ed82eb67/src/libunwind/lib.rs#L32 2017-04-07 00:54:07 this, right? 2017-04-07 00:54:30 i think libgcc_s doesn't include unwind stuff 2017-04-07 00:55:15 oh, it does 2017-04-07 00:57:08 hmm 2017-04-07 00:57:14 i think it's not getting linked in properly somehow 2017-04-07 00:57:21 jirutka: i'd check the above libunwind-*.rlib 2017-04-07 00:57:26 see what it links against and its symbols 2017-04-07 01:03:50 Shiz: if you wanna continue: https://github.com/jirutka/alpine-aports/commit/e7f48af4953453d4b1b5b9a3812088eca6b6722f 2017-04-07 01:03:58 Shiz: I’m going to sleep, too tired 2017-04-07 01:03:59 :) 2017-04-07 01:04:02 sleep well 2017-04-07 01:04:57 thanks 2017-04-07 01:15:47 jirutka: fwiw, the abuild isn't working because wrong stdlib and cargo-nightly checksums 2017-04-07 01:15:57 if i fix them, it complains about stdlib being compiled with a different rust 2017-04-07 01:16:07 = help: please recompile that crate using this compiler (rustc 1.16.0) 2017-04-07 01:16:08 = note: crate `std` path #1: /alpine-aports/testing/rust/src/stage0/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd_unicode-e7785092bfb3c649.rlib compiled by "rustc 1.16.0 (30cf806ef 2017-03-10)" 2017-04-07 01:18:41 it works if i change the rust-std url to https://repo.voidlinux.eu/distfiles/rust-std-$pkgver-$_arch-unknown-linux-musl.tar.gz 2017-04-07 01:19:52 after that it fails with "error[E0432]: unresolved import `syntax::ast`" 2017-04-07 01:19:53 :p 2017-04-07 01:35:15 (the new rust-std url also has the same checksum as your apkbuild, so that part's fixed) 2017-04-07 01:40:23 jirutka: ok, found the matching cargo gitrev too (not the one in the APKBUILD): 333a79884d2463b11f279d815284b6406656c949 2017-04-07 01:40:41 using that one fixes the last error too 2017-04-07 01:41:54 the gitrev you put in there is way too new 2017-04-07 01:43:11 iow: https://txt.shiz.me/OWJiOGE0Nz for it to start building in the first place :P 2017-04-07 02:03:32 and repro'd your error :) 2017-04-07 02:14:12 jirutka: got it to compile by manually adding -lgcc_s \o/ 2017-04-07 02:47:47 / # rustc -o hello hello.rs 2017-04-07 02:47:49 / # ./hello 2017-04-07 02:47:51 The program "+ + * - /" calculates the value 1 2017-04-07 02:47:53 :) 2017-04-07 02:47:55 bit of a hacky patch, but whatev 2017-04-07 02:49:30 jirutka: https://txt.shiz.me/MTM4NjNmN2 2017-04-07 02:49:45 patch to your APKBUILD for a (superficially) working rustc 2017-04-07 02:52:20 there's a nasty duplication of libs in /usr/lib and /usr/lib/rustlib/$(triplet)/lib right now, though 2017-04-07 02:53:56 error: specifying the `crt-static` target feature is only allowed on the nightly channel with `-Z unstable-options` passed as well 2017-04-07 02:53:59 and we should patch out this 2017-04-07 02:55:56 So, I have a stupid question -- is it possible to tell apk to fetch by complete package atom, or are we stuck with fetching by name and hoping the versions line up? 2017-04-07 03:01:37 jirutka: we should also patch https://github.com/rust-lang/rust/blob/a5dac7a2af3ee444817eb7bfbba3539be8c06cf1/src/librustc_back/target/linux_musl_base.rs to include base.no_default_libraries = false; 2017-04-07 03:02:11 TemptorSent: apk add pkg=ver 2017-04-07 03:14:19 Shiz: Ouch. Okay, I can't use what apk search -x gives me back the :/ 2017-04-07 03:14:49 ? 2017-04-07 03:16:01 Shiz: I'm trying to pin the atoms fetched to the atoms returned when I first start staging. 2017-04-07 03:16:26 Shiz: And in some cases, I have complete atoms with versions, in others I don't. 2017-04-07 03:16:27 why does that mean you can't use what apk search -x gives you back? 2017-04-07 03:17:24 for $pkg in pkgs; do apk fetch $(apk search -x $pkg) ; done 2017-04-07 03:17:41 apk fetch doesn't do versions, no 2017-04-07 03:17:53 just trim the last two - 2017-04-07 03:18:23 Yeah, it means I have to download everthing, then double check that the version didn't change while I was in the process of staging. 2017-04-07 03:18:45 i don't really see why you need to check the versions so strictly until you start fetching them anyway 2017-04-07 03:18:49 Otherwise, broken system -- it happened to me on my previous kernel version. 2017-04-07 03:19:33 Because they're staging into a kernel-version/arch/and kernel flavor specific directory. 2017-04-07 03:21:31 So if between staging the kernel 'linux-grsec-4.9.20-r0' and the zfs modules, the repo bumped a version, I'd end up with missmatched kernel and modules, and if doing so using fetch ...| tar -x, it breaks systems. 2017-04-07 03:23:05 I guess the solution is to download everything, iterate through and verify versions, then rerun the fetch if anything has changed or if there is any missmatch, then run verify, then untar them. 2017-04-07 03:24:10 I'm wasting more time working around limitations in apk than I am actually coding useful logic at this point. 2017-04-07 03:29:56 maybe you should join the apk project :) 2017-04-07 03:30:13 MAGA make apk great again 2017-04-07 03:30:19 think of the hats 2017-04-07 03:30:48 hats are the most important component of a FOSS project 2017-04-07 03:37:04 kaniini *lol* 2017-04-07 03:37:25 I don't like creating race conditions :( 2017-04-07 03:37:57 i'm serious we could use the help 2017-04-07 03:38:24 the exciting world of package management has never been more exciting 2017-04-07 03:39:17 Yeah, let me get the major overhaul done on what I'm in the middle of, then I'll probably jump in. 2017-04-07 03:39:39 ncopa wants the functionality I'm working on now yesterday apparently. 2017-04-07 03:41:01 and doing it right so it will put up with being fed some pretty random formatted version strings is turning out to be entertaining. 2017-04-07 03:41:57 The kernel versions vs. package names aren't consistent, unfortunately, which is leading to things like extracting the /usr/share/kernel directory of the tar file to stdout 2017-04-07 03:42:54 And I know I'm going to have a headache to work out on the bloody reverse-parsing of the kernel arch from .config to our system arch. 2017-04-07 03:43:52 but the result should be a set of simple tools and configurations that handle all of the kernel-artifact related tasks. 2017-04-07 03:46:10 TemptorSent: it is true that we are getting very close to getting into release mode 2017-04-07 03:46:18 kaniini: But I definitely have some thoughts on how to improve auditing, authentication, and versioning capabilities in apk, as well as some tools that would be very useful to expose externally. 2017-04-07 03:46:48 Yeah, and apparently I'm not the only one running into issues with the current setup, so fixing it is needful. 2017-04-07 03:46:49 ncopa wants to know about this work because it's something he wants to include in the release 2017-04-07 03:47:11 like this is just solely a matter of release engineering at this point 2017-04-07 03:47:13 mkinitfs has many broken bits as it stands. 2017-04-07 03:47:30 we are trying to figure out what our position presently is, so we can figure out what to do next in terms of preparing the release 2017-04-07 03:47:39 yes, no doubt 2017-04-07 03:47:56 i am just saying 2017-04-07 03:47:59 don't stress quite yet 2017-04-07 03:48:01 The fixes for that are part of what I'm working on, which is high-priority apparently. 2017-04-07 03:48:16 you still have probably 2 or 3 weeks 2017-04-07 03:48:20 People are endeing up with unbootable systems when a repo does weird things. 2017-04-07 03:48:25 before a final decision has to be made 2017-04-07 03:48:31 Yeah, how about some testing time in there? :) 2017-04-07 03:49:05 you mean before freeze? because fixes are allowed through after freeze :) 2017-04-07 03:49:11 Anyway, mkinitfs itself I have reimplemented and working AFAIK, emulating the existing script cleanly. 2017-04-07 03:49:45 kaniini: Yeah, it's a pretty major overhaul for a 'fix', considering the entire code of mkinitfs and update kernel are going away and being replaced essentially. 2017-04-07 03:49:55 i meant 2017-04-07 03:50:04 if you get the rewrite in before we freeze 2017-04-07 03:50:05 then we can fix it 2017-04-07 03:50:08 if there is problems 2017-04-07 03:50:26 because what we start doing is mock releases 2017-04-07 03:50:31 every day or two 2017-04-07 03:50:41 and then some of those mock releases are done as RCs 2017-04-07 03:50:49 (only the mkinitfs script, NOT nlplug-findfs -- we discussed splitting that to it's own repo so we don't have arch-dependent and arch-independent repos comingled needlessly. 2017-04-07 03:51:28 Yeah, I like to have stuff not broken before going into mainline if I can help it :) 2017-04-07 03:51:50 right, it makes sense 2017-04-07 03:52:38 But mostly, I'm trying to finish doing the rolling-refactor from the original scripts to somethign that is modular, and thus have some more general cleanup of globals and such to finish before it even can be called baked. 2017-04-07 03:53:12 In the mean time, I'm still renaming functions and rearranging directories periodically to keep everythign making sense. 2017-04-07 03:53:44 i mean, your dedication to this stuff is certainly admirable 2017-04-07 03:54:09 That's why I haven't commiteed the current chunk of crap I'm hacking on, it's still too tangled. 2017-04-07 03:54:40 I want it to work without giving me grief, and if it goes mainline, that's less hassle for me :) 2017-04-07 03:54:46 meanwhile i am just doing test rebuilds and trying to make sure that when we freeze it goes smoothly :P 2017-04-07 03:56:24 Testing is the most critical part. 2017-04-07 03:56:49 By cleaning this up and isolating the functions, we should be able to actually write tests against it. 2017-04-07 03:58:23 I think we can unscrew the kernel/module package building mess using it too, and maybe make abuild use it to generate the packages from a single package file instead of dozens. 2017-04-07 03:59:46 Do you know if any of the modules are building with something other than kbuild? 2017-04-07 04:04:49 Also, is there any good reason whatsoever to NOT compress the modules? 2017-04-07 04:45:20 kaniini: For splitting package name off, is "${pkg%%-[0-9]*}" safe to use? 2017-04-07 04:45:48 no 2017-04-07 04:45:54 well 2017-04-07 04:45:55 actually 2017-04-07 04:45:57 i think so 2017-04-07 04:46:02 IOOW, do we have any stupid crap to worry about like gtk-3, or are they underscored? 2017-04-07 04:46:09 oh 2017-04-07 04:46:10 we do 2017-04-07 04:46:17 there is stuff like 2017-04-07 04:46:20 gtk+3.0 2017-04-07 04:46:59 *facepalm* Okay, what is the SAFE way to split the package version, since I can't just pass it the full atom! 2017-04-07 04:48:15 If we can't depend on the first '-' followed by a digit, this is going to get ugly, fast.! 2017-04-07 05:54:08 Query - is it expected that the kernel pkgver and module pkgver in their respective .PKGINFO files match exactly? It appears the install-if does not. 2017-04-07 06:24:37 jirutka, is cargo broken atm? 2017-04-07 06:33:37 ah, i guess rust needs a version bump? 2017-04-07 06:44:17 TemptorSent: ${pkg%-*} twice 2017-04-07 06:55:09 Thank you Shiz, time to go chase code -- probably tomorrow, because I'm too tired to do it now. 2017-04-07 07:10:15 Shiz: Confirmed that quite a number of packages do in require the annoying form. 2017-04-07 07:12:01 Although it appears that all packages DO work with "${pkg%-*-*}" that I can check with a loop through the result of apk search 2017-04-07 07:13:36 morning 2017-04-07 07:13:50 ncopa wants the functionality I'm working on now yesterday apparently. 2017-04-07 07:14:03 TemptorSent: dont stress with it 2017-04-07 07:14:16 might be we merge it in right after v3.6 release 2017-04-07 07:14:30 which probably is more sane that rush it 2017-04-07 07:14:41 then we also have longer testing period for 3.7 2017-04-07 07:15:46 i was hoping that we could use your stuff for v3.6, or at least bits of it 2017-04-07 07:16:08 but its not worth burning out people 2017-04-07 07:16:14 ncopa: I'm not stressing, just prioritizing :) 2017-04-07 07:16:19 good 2017-04-07 07:16:31 if we reach it, the fine 2017-04-07 07:16:38 if not, then we'll do it for v3.7 2017-04-07 07:16:51 And getting a little frustrated with spending more time working around apk than actually writing logic at the moment. 2017-04-07 07:17:04 Not being able to fetch by complete atom is painful. 2017-04-07 07:18:00 It means trimming every package every time I need to do something with it, then double checking that the version didn't change on me while I wasn't looking. 2017-04-07 07:18:22 so we should probably fix apk-tools first 2017-04-07 07:18:25 ncopa: Any chance there's and easy fix for that in apk? 2017-04-07 07:18:38 fabled is the right person to ask 2017-04-07 07:18:54 Yeah, I figured as much, but haven't seen him on while I've been on. 2017-04-07 07:18:57 you need apk search $pkgname=$version 2017-04-07 07:19:05 and apk fetch $pkgname=$version 2017-04-07 07:19:38 that means that it needs to go via the dependency resolver 2017-04-07 07:19:45 ideally, take the result of apk search -x $pkgname 2017-04-07 07:20:09 do you have example of shell syntax you want? 2017-04-07 07:20:19 i mean, do you need the apk search at all? 2017-04-07 07:20:26 so apk search -x $pkgname-$pkgver would ideally return the same as apk search -x $pkgname 2017-04-07 07:21:01 Yes, because I check the package exists and get the version. 2017-04-07 07:21:35 why do you need the version? 2017-04-07 07:21:42 essentially, it would be great if apk would accept atoms specified in the same form it returns them from 'apk search -x $pkgname' 2017-04-07 07:22:02 because kernels and modules don't tend to get along too well if they don't match. 2017-04-07 07:22:37 I had my system partially broken for a while because I had a mismatch when a repo was acting up. 2017-04-07 07:22:44 ok 2017-04-07 07:23:01 in which case you should have gotten an error message 2017-04-07 07:23:18 so you get the kernel and moduels with apk fetch? 2017-04-07 07:23:28 and they need to match? 2017-04-07 07:23:44 So if I get a list of packages for 4.9.20-r0-grsec and 4.9.21-r0-grsec comes out while I'm working, it'd be nice to throw an error rather than silently breaking things. 2017-04-07 07:23:57 i understand 2017-04-07 07:24:02 and i agree 2017-04-07 07:24:22 do you apk fetch the kernel package and modules packages in same shot 2017-04-07 07:24:29 or in different apk fetch calls? 2017-04-07 07:24:50 Multiple calls, and with apks staged in a cached direcotry. 2017-04-07 07:25:38 so 2017-04-07 07:25:42 I need the apks themselves because I'm parsing them with an awk script to extract the checksum headers. 2017-04-07 07:26:08 one option is to have apk check the cached directory that dependencies are met? 2017-04-07 07:26:12 As well as allowing a user to download a set of apks for offline work. 2017-04-07 07:27:10 This allows including both apks and custom built kernels/modules, so dep resolution might not work. 2017-04-07 07:27:27 All deps are being resolved using depmod/modinfo 2017-04-07 07:27:48 so kernel modules might not be in an apk package 2017-04-07 07:27:57 and apk cannot check that 2017-04-07 07:28:01 Right. 2017-04-07 07:28:30 other option would be to have depmod exit with error if deps are unmet? 2017-04-07 07:28:32 People building custom modules, but using stock kernels is an issue there. 2017-04-07 07:28:47 Yeah, I'm going to run depmod with -e 2017-04-07 07:29:28 So everything will be fully resolved, AND I'll have a link between packages and files installed even after slicing and dicing for both modloop and mkinitfs 2017-04-07 07:30:04 i think fabled is busy this week 2017-04-07 07:30:08 and i will not have time today either 2017-04-07 07:30:21 Which means we don't have too much of a kitchen-sink problem any more. 2017-04-07 07:31:14 A user could select only the modules he needs and they'd all be resolved without including a bunch of unneeded cruft. 2017-04-07 07:31:36 that is great 2017-04-07 07:31:48 and it could pull in the firwmare needed too 2017-04-07 07:31:55 Right now, mkinitfs will silently not find files and give you an unbootable machine. 2017-04-07 07:32:03 yeah 2017-04-07 07:32:03 Yeah, already has that logic :) 2017-04-07 07:32:22 ok 2017-04-07 07:32:36 i think what we can do for now 2017-04-07 07:32:50 1) report the needed feature on bugs.alpinelinux.org 2017-04-07 07:32:54 eg create issue 2017-04-07 07:32:57 with the details 2017-04-07 07:32:57 It can also handle installing headers from custom builds. 2017-04-07 07:33:22 2) separate out your work from the aports git tree, into its own git repo 2017-04-07 07:33:30 so we handle this as a separate project 2017-04-07 07:33:48 3) separate out nlplug-findfs into its own git repo 2017-04-07 07:33:50 Okay, what's the best way of splitting it out so it doesn't get confusing? 2017-04-07 07:34:01 good question 2017-04-07 07:34:11 also, how do we do it and keep the hisotry? 2017-04-07 07:34:17 how much history do we need to keep? 2017-04-07 07:34:59 I'm not sure, TBH. 2017-04-07 07:35:04 for nlplug-findfs i think we could probably just rename mkinitfs.git -> nplug-findfs and purge the shell scripts 2017-04-07 07:35:19 This is one of those corner-cases I haven't gotten myself into before :) 2017-04-07 07:35:19 since the mkinitfs shell scripts is moving out 2017-04-07 07:35:27 agreed, that would make sense 2017-04-07 07:35:56 or initfs-helpers perhaps? 2017-04-07 07:36:21 I could see other small tools joining it in time. 2017-04-07 07:37:20 one way to separate from aports: 2017-04-07 07:37:26 git log scripts/ 2017-04-07 07:37:42 all those commits should not touch the APKBUILDs 2017-04-07 07:38:04 so we can probably just carve out those commits 2017-04-07 07:38:06 Right, I didn't touch anything outside the scripts dir in my working tree. 2017-04-07 07:38:12 and apply them to new git repo 2017-04-07 07:38:29 Then do a git mv to put things where they belong? 2017-04-07 07:40:00 Bug or Feature tracker? 2017-04-07 07:45:33 i suppose feature 2017-04-07 07:45:43 yes then git mv where they belong 2017-04-07 07:45:48 that way we keep the history 2017-04-07 07:46:03 Sounds sane :) 2017-04-07 07:46:28 the scripts/bootstrap.sh 2017-04-07 07:46:32 do you ever touch it? 2017-04-07 07:47:10 Haven't touched it :) 2017-04-07 07:47:15 ok good 2017-04-07 07:47:18 im looking at the commits 2017-04-07 07:47:29 I did my best to keep it as clean as possible. 2017-04-07 07:47:38 then we need to filter out the commits that touches scripts/bootstrap.sh 2017-04-07 07:47:42 and keep that in aports 2017-04-07 07:47:57 sounds like we have a plan 2017-04-07 07:47:59 I haven't commited a large chunk of work on the kerneltool quite yet. 2017-04-07 07:48:02 Indeed. 2017-04-07 07:48:26 i need to work on the s390x builder 2017-04-07 07:48:28 I may need a little help figuring out how to split the bootstrap commits out. 2017-04-07 07:48:47 I *think* I have most of whats needed in place for that already in mkimage. 2017-04-07 07:49:16 I picked up an account to play with it, but haven't gotten there quite yet. 2017-04-07 07:49:42 $ git log --format=oneline scripts/ 2017-04-07 07:50:18 But it already knows about the s390x arch. 2017-04-07 07:50:34 good 2017-04-07 07:51:24 Oh, not too bad, only 5 commits to bootstrap 2017-04-07 07:51:45 its doable 2017-04-07 07:51:48 What else is needed for the s390x builder? 2017-04-07 07:52:07 i need make sure the build logs are copied 2017-04-07 07:52:13 and that the builder can upload the packages 2017-04-07 07:52:24 thats basically it 2017-04-07 07:52:35 i will have to go in 30 mins 2017-04-07 07:52:38 so kinda busy now 2017-04-07 07:52:42 Cool, so building images should be able to be tested soon :) 2017-04-07 07:53:14 No problem, I'll post the feature request and then get some sleep. 2017-04-07 07:53:59 It's pouring rain here right now, so I'm expecting to have a power-outage to deal with at some point... My poor UPS isn't going to take much more of this. 2017-04-07 08:05:14 s390x builder is up! 2017-04-07 08:06:58 Awesome! 2017-04-07 08:08:15 Alright, I'm heading to bed -- I have a workaround that doesn't appear to break anything currently in the x86_64 repo at least :) 2017-04-07 08:49:34 kaniini: thank you! for the mate update 2017-04-07 08:49:42 was hoping to get that in before v3.6 2017-04-07 08:50:23 so then we have llvm 4 and php5 cleanup left? 2017-04-07 08:50:26 of the big things 2017-04-07 08:50:41 and uefi support in installer? 2017-04-07 08:50:52 need to go out for a while 2017-04-07 08:54:22 @ncopa │ s390x builder is up! 2017-04-07 08:54:23 nice :) 2017-04-07 08:54:34 speaking of builders, any reason why the buildlogs/ dirs are mostly empty for x86_64 at least? 2017-04-07 08:54:43 ncopa: llvm 4.0 may be an issue 2017-04-07 08:54:55 jirutka is trying to package rust in community/ before 3.6 and it does not like llvm4 2017-04-07 09:00:01 clandmeter: i created a PR for the snapcast splitting https://patchwork.alpinelinux.org/patch/3271/ 2017-04-07 09:00:43 xsteadfastx, is it possible to create a gh pr? 2017-04-07 09:01:57 sure... you mean i clone aports from github, make the changes and do the PR on github? 2017-04-07 09:02:30 yep thats it 2017-04-07 09:02:49 i try to keep away from patchwork 2017-04-07 09:03:14 hehe ok :) 2017-04-07 09:04:24 and i dont have an mail client setup on my alpine container 2017-04-07 09:04:48 do you think you can also add check() and initd? 2017-04-07 09:05:11 there are issues with qt5-qttools-dev 2017-04-07 09:05:37 clandmeter: sure... but how does the check work? what kind of test should i write? 2017-04-07 09:05:52 the basic is --help :) 2017-04-07 09:06:08 if that doesnt return an error, we concider its working 2017-04-07 09:06:22 just pipe it to devnull 2017-04-07 09:06:31 err redirect.. 2017-04-07 09:07:29 ok 2017-04-07 09:07:38 i never wrote a initd... i have to dig the wiki 2017-04-07 09:08:40 xsteadfastx: i'd check the openrc-run manual :) 2017-04-07 09:08:45 and existing good .initd scripts 2017-04-07 09:08:48 man openrc-run 2017-04-07 09:08:53 Shiz! 2017-04-07 09:08:54 (if it doesn't have a manual start()/stop() implementation, it's likely good) 2017-04-07 09:08:54 ok cool... i will do that 2017-04-07 09:08:55 :p 2017-04-07 09:08:56 hullo 2017-04-07 09:09:27 the base openrc-run script is like 2017-04-07 09:09:32 #!/sbin/openrc-run 2017-04-07 09:09:35 depend() { ... } 2017-04-07 09:09:39 command=... 2017-04-07 09:09:49 command_args=" ..." 2017-04-07 09:09:52 command_background=yes 2017-04-07 09:09:57 pidfile=/run/$RC_SVCNAME.pid 2017-04-07 09:09:58 <_ikke_> Shiz: please use a pastebin 2017-04-07 09:10:04 sorry, i typed all of those out myself 2017-04-07 09:10:06 :p 2017-04-07 09:10:52 and also... im sure snapcast-server should have a own user 2017-04-07 09:11:15 check the pre-install scripts 2017-04-07 09:11:21 in aports tree 2017-04-07 09:11:29 or the wiki 2017-04-07 09:12:02 and if you really wanna impress you should provide a sample conf ;-) 2017-04-07 09:12:28 hehehehe... ok... step by step... first check... :) 2017-04-07 09:13:00 you can add all to one pr if you like 2017-04-07 09:13:11 thats what i want to do 2017-04-07 09:13:33 and travis will check your skillz 2017-04-07 09:15:10 xsteadfastx, ill reject your patchwork patch (although it looks good) :) 2017-04-07 09:15:26 ok... do that 2017-04-07 09:15:28 :) 2017-04-07 09:22:39 clandmeter: would be "snapclient --help > /dev/null 2> /dev/null || return 1" ok? 2017-04-07 09:23:22 or even --version 2017-04-07 09:23:32 fabled: can i use apk info also on a specified apk version? its seems currently it will list info about all version found of an apk. 2017-04-07 09:24:04 is &> not posix? 2017-04-07 09:24:59 not sure it matters --version/--help 2017-04-07 09:26:17 sure &> should work too i think... 2017-04-07 09:26:21 shorter 2017-04-07 09:26:37 i think its not posix, but our ash shell supports it 2017-04-07 09:27:02 im sure there are users who will be against using it skarnet? 2017-04-07 09:31:40 qt5 should be upgraded to 5.8.0, it's going to be huge.. 2017-04-07 09:36:43 fcolista, sounds like a busy weekend for you :) 2017-04-07 09:38:39 I think we need a script to update those packages (qt/gtk/mate/xfce) 2017-04-07 09:39:24 xsteadfastx, i think it would even make more sense to only redirect stdout. 2017-04-07 09:39:44 so we can see on builders log what actually was the error msg. 2017-04-07 09:44:21 clandmeter: ok... i will do that 2017-04-07 09:53:33 Shiz: aha, sorry for that, I’ve changed it many times and probably messed something; that’s why WIP :) 2017-04-07 09:59:46 Shiz: that should not be a problem, we will just move current llvm to llvm3.8 and update llvm to latest version 2017-04-07 10:09:32 ncopa: I’d like to also move ghc, cabal and maybe idris to community before branching v3.6 2017-04-07 10:10:29 ncopa: TemptorSent: about extracting scripts into separate repo, I’ll do that, I’ve already done this few times :) 2017-04-07 10:10:42 ncopa: TemptorSent: just let me know when I should do it 2017-04-07 10:33:00 snapcast wants it config in /etc/default... would that be allright? 2017-04-07 10:37:47 xsteadfastx: no, this is for debian(?), just remove it 2017-04-07 10:38:09 thats where snapcast looking for its config... 2017-04-07 10:39:50 &> is not posix indeed, and confusing (think people who just learned what >& does and see &> and go wtf?) 2017-04-07 10:40:32 (or just people who casually glance at the code while not being entirely awake or in full possession of their brain cells. Like me.) 2017-04-07 10:40:59 skarnet: &> redirects both 1 and 2 and yes, it’s not POSIX and hence should not be used 2017-04-07 10:41:48 xsteadfastx: IIRC /etc/default is for configs for runscripts…? so the same as /etc/conf.d on Alpine 2017-04-07 10:42:08 now i need to find out how to patch snapcast to use this instead 2017-04-07 10:42:17 xsteadfastx: if it really looks for application config here, then move that to /etc/snapcast.conf or /etc/snapcast/whatever.conf or something like that 2017-04-07 10:47:26 jirutka: anyway it works :D 2017-04-07 10:47:28 rustc that is 2017-04-07 10:47:48 Shiz: what does it produce for you? statically or dynamically linked executable? 2017-04-07 10:47:54 dynamic 2017-04-07 10:48:05 and with -C prefer-dynamic, dynamic rust libraries too 2017-04-07 10:48:09 (and a small additional patch) 2017-04-07 10:49:11 Shiz: can you try to specify `-C target-feature=+crt-static` ? 2017-04-07 10:49:33 already did 2017-04-07 10:49:35 doesn't work 2017-04-07 10:49:38 since it's anightly feature 2017-04-07 10:49:44 see your highlight log above 2017-04-07 10:49:47 i documented all of that :p 2017-04-07 10:49:58 04:53:56 Shiz │ error: specifying the `crt-static` target feature is only allowed on the nightly channel with `-Z unstable-options` passed as well 2017-04-07 10:49:59 04:53:58 Shiz │ and we should patch out this 2017-04-07 10:50:24 Shiz: yeah, that’s what I thought… so I will patch this stupidity out 2017-04-07 10:51:07 jirutka: in base_linux_musl.rs, set base.no_default_libraries = true; 2017-04-07 10:51:10 to make -C prefer-dynamic right 2017-04-07 10:51:15 err 2017-04-07 10:51:16 Shiz: why the hell Rust team must throw stones and sticks on my road all the way? 2017-04-07 10:51:27 or maybe = false; 2017-04-07 10:51:34 either way you want to make it omit the -nodefaultlibs stuff 2017-04-07 10:51:38 what no_default_libraries do? 2017-04-07 10:51:39 when doing -C prefer-dynamic 2017-04-07 10:51:43 it emits -nodefaultlibs 2017-04-07 10:51:45 which you don't want 2017-04-07 10:51:57 afk for a b it 2017-04-07 10:52:33 jirutka: also we have a nasty rust lib duplication right now 2017-04-07 10:52:46 rustc links against the rust libraries in /usr/lib, but they are also in /usr/lib/rustlib/$(target)/lib 2017-04-07 10:52:51 Shiz: I think that I’ve already solved that by symlinks 2017-04-07 10:52:58 considering their names, it would be preferable to have them link to the ones in rustlib 2017-04-07 10:53:05 and have them not in /usr/lib at all 2017-04-07 10:53:07 :) 2017-04-07 10:53:09 brb 2017-04-07 10:53:11 for real now 2017-04-07 10:53:53 I prefer opposite, symlink from /usr/lib to /usr/lib/rustlib/$target/lib; currently it does not matter, b/c rust depends on rust-stdlib, but theoretically you may use rust without stdlib… 2017-04-07 10:54:26 but not sure what is really better 2017-04-07 10:56:11 okay, now I verified that RUST_CRT_STATIC really works; I was in suspect that it has no effect, b/c I don’t see any target-feature=-crt-static in logs and also when no static, it should link gcc_s (or how’s that called) instead of unwind 2017-04-07 10:59:23 <^7heo> ncopa: ping mkinitfs release 2017-04-07 11:02:55 Shiz: lol, the title :) https://github.com/rust-lang/rust/issues/39998 2017-04-07 11:18:08 hum its friday 2017-04-07 11:18:48 i was thinking i should spend rest of the day on things that i want work on, not on things that i have to work on 2017-04-07 11:19:13 why not do that the other days too? :P 2017-04-07 11:19:31 ncopa: hm, I start my shift in one hour :p 2017-04-07 11:19:49 because then the things that *needs* to be done will never get done 2017-04-07 11:22:32 jirutka: can we upgrade llvm to 4.0? 2017-04-07 11:22:46 or will that cause problems for rustc ghc and others? 2017-04-07 11:22:57 ncopa: yes, just copy current llvm to llvm3.8 2017-04-07 11:23:19 ha 2017-04-07 11:23:25 ncopa: then check what pkgs depending on llvm are compatible with llvm 4.0 and replace llvm with llvm3.8 for the ones that do not like 4.0 2017-04-07 11:23:35 i was hoping to hear: "no we cannot upgrade. lets stay on 3.8 for now" 2017-04-07 11:23:37 :) 2017-04-07 11:24:04 <^7heo> unfortunately we cannot stay on a given version for all time. 2017-04-07 11:24:06 <^7heo> we're not debian. 2017-04-07 11:24:10 yeah 2017-04-07 11:24:40 ncopa: we already have llvm3.7, so this can be used as template for llvm3.8; but don’t remember how many differences are here 2017-04-07 11:24:50 ncopa: I’ll look at it later today 2017-04-07 11:25:49 can we get rid of llvm3.7? 2017-04-07 11:26:02 ncopa: not sure 2017-04-07 11:26:07 and upgrade everything that needs llvm3.7 to llvm3.8 2017-04-07 11:26:14 llvm is very problematic in regards of backward compatibility 2017-04-07 11:26:18 :-/ 2017-04-07 11:26:44 so we risk to need to maintain infinite versions of llvm 2017-04-07 11:26:44 ncopa: ghc requires llvm3.7 and IIRC mitchty told me that it does not work with llvm 3.8 2017-04-07 11:26:50 <^7heo> well, when you have GCC as an example of backwards compatibility, I can understand why you wouldn't want that... 2017-04-07 11:27:31 <^7heo> ncopa: if it's just a version that is "set in stone", it's a bit much to call it "maintain" 2017-04-07 11:27:42 ncopa: and since he already invested A LOT of time to get ghc working on Alpine and really like to finally see it in community, I’d rather not ask him about trying to update it to llvm3.8 :) 2017-04-07 11:27:43 <^7heo> maybe "serve in our repos" at the most. 2017-04-07 11:28:29 ncopa: I’ll try to find or ask Rust guys what LLVM version they currently targets 2017-04-07 11:28:36 <^7heo> jirutka: yeah but maybe it would be worth letting him know of the evolution on the llvm side... 2017-04-07 11:28:38 ok 2017-04-07 11:28:47 <^7heo> jirutka: just, you know, in case he has a LOT of free time right now ;) 2017-04-07 11:28:48 ^7heo: he knows that 2017-04-07 11:28:56 <^7heo> ok then 2017-04-07 11:29:00 jirutka: sounds good to me 2017-04-07 11:29:02 ^7heo: but as you know, LLVM is real PITA 2017-04-07 11:29:14 <^7heo> no I don't 2017-04-07 11:29:19 <^7heo> I'm not much looking at compilers atm. 2017-04-07 11:29:24 <^7heo> and for quite some time. 2017-04-07 11:29:36 ncopa: btw it’s even worse… do you know about emscripten-fastcomp? :) 2017-04-07 11:30:21 ncopa: that’s emscripten’s fork of LLVM, emscripten currently does not work with upstream LLVM… they should merge JS backend someday, but not done yet 2017-04-07 11:30:38 (merge into upstream) 2017-04-07 11:31:02 that is the C compiler to asmjs? 2017-04-07 11:31:05 <^7heo> You know all hope is lost when people start forking a project rather than using it. 2017-04-07 11:31:23 ncopa: yes, basically 2017-04-07 11:31:59 problem is that people dont seem to think longterm maintenance 2017-04-07 11:32:35 make it run and get famous. job accomplished 2017-04-07 11:33:27 yes, that’s emscripten exactly 2017-04-07 11:34:12 ncopa: look at number of patches to make it at least a bit friendly with distribution: https://github.com/alpinelinux/aports/tree/master/testing/emscripten 2017-04-07 11:34:39 ncopa: the whole directory structure of emscripten is huge mess 2017-04-07 11:35:33 <^7heo> ncopa: http://4.bp.blogspot.com/-RO-OobNCXG4/UYiJq-d8LHI/AAAAAAAALnI/Jlvw0-HZLMk/s1600/bush-mission-accomplished-iraq-thumbsup.jpg 2017-04-07 11:35:57 lul 2017-04-07 12:01:40 <_ikke_> scadu: I would not say that to a dutch person :P 2017-04-07 12:03:16 _ikke_: meh, this language is really weird :P 2017-04-07 12:15:00 Want to make a Cmake package via "newapkbuild -C $pkgname" but it isn't working. Says "Illegal option -C". Is this a bug? 2017-04-07 12:16:00 jirutka: i mean, not having any rust libs in /usr/lib 2017-04-07 12:16:07 and jamming them all in /usr/lib/rustlib/$(target)/lib 2017-04-07 12:16:10 because their names are rather... generic 2017-04-07 12:16:31 no symlinks from /usr/lib either 2017-04-07 12:17:18 jirutka: rust targets llvm <4 2017-04-07 12:17:23 it supports 3.9 afaik 2017-04-07 12:17:52 terra: not a bug, just using it incorrectly ;) 2017-04-07 12:18:50 Shiz: yeah, that’s probably a good idea 2017-04-07 12:19:07 jirutka: Any link for this? I just need a standard Cmake APKBUILD template. 2017-04-07 12:20:15 terra: newapkbuild -n -d -u -C 2017-04-07 12:21:31 jirutka: hmm. I thought it is going to be simpler like "newapkbuild -a $pkgname" 2017-04-07 12:22:19 terra: newapkbuild --help 2017-04-07 12:22:48 terra: you should specify at least -n NAME, otherwise how can it know where you want to create the apkbuild? 2017-04-07 12:23:20 terra: but you should fill desc, pkgurl and srcurl anyway, so why not feed it right into newapkbuild? 2017-04-07 12:24:13 jirutka: but newapkbuild -a works as expected 2017-04-07 12:24:29 terra: aha, din’t know that 2017-04-07 12:24:46 jirutka: I don't know why situation is different for -C ? 2017-04-07 12:24:53 terra: aha, yeah, according to --help it’s also valid, hm 2017-04-07 12:28:10 Shiz: I’ve tried another way, removed all expect lines 14, 24 and 72 from opts() in https://github.com/rust-lang/rust/blob/master/src/librustc_back/target/linux_musl_base.rs … and it also works :) 2017-04-07 12:28:58 Shiz: so it’s *again* problem with these stupid hackery to compile against musl and link statically on glibc systems 2017-04-07 12:30:39 hm, but `rustc -C target-feature=+crt-static test.rs` fails with undefined reference to `_Unwind_Resume' 2017-04-07 12:31:07 Shiz: so I need to make these options conditional 2017-04-07 12:32:49 kay, it’ll be probably the best to summarize what we found to that PR now, and then try to figure out how to fix it 2017-04-07 12:56:45 ncopa: I suggest to copy pkg llvm to llvm3.9, update it to 3.9 and update pkg llvm to 4.0 2017-04-07 13:11:29 and drop llvm3.8? 2017-04-07 13:12:33 ncopa: yes 2017-04-07 13:13:03 is that better than dropping 3.9 and keep 3.8? 2017-04-07 13:13:04 ncopa: it seems that it’s not needed, but I’ve checked it only briefly now 2017-04-07 13:13:52 ncopa: I guess that newer is better 2017-04-07 13:13:59 except that it means more work 2017-04-07 13:14:04 3.8 works as is now 2017-04-07 13:14:11 3.9 may need rebase the patches 2017-04-07 13:14:17 ncopa: hm, that’s true 2017-04-07 13:14:44 what needs llvm 3.8 or 3.9? rust? 2017-04-07 13:14:55 yea 2017-04-07 13:14:56 ncopa: so start with llvm3.8 and then maybe upgrade it to llvm3.9? 2017-04-07 13:14:58 and ghc? 2017-04-07 13:15:09 ncopa: as Shiz said, both 3.8 and 3.9 should be okay for rustc 2017-04-07 13:15:11 i thought ghc needs llvm3.7 2017-04-07 13:15:13 Shiz: ghc needs 3.7 2017-04-07 13:15:22 right 2017-04-07 13:15:37 Julia currently use 3.7 too, but it’s outdated, I don’t know what version the latest Julia needs 2017-04-07 13:15:46 I’ll check this later 2017-04-07 13:15:55 ok 2017-04-07 13:16:39 are there any reason to not upgrade go to 1.8? 2017-04-07 13:16:46 i think ppc64le needs go1.8 2017-04-07 13:24:14 I’m using our yesterday’s conversation on IRC as backlog to write a bug report to rust-lang/rust :) without that I’d be quite lost, don’t remember all steps I did 2017-04-07 13:24:18 Shiz: ^ 2017-04-07 13:30:11 :) 2017-04-07 13:58:33 is anyone having issues with the kernel 4.9.20-r0 and zfs.ko missing? 2017-04-07 13:59:12 i've upgraded the kernel to get rid of the sshd delay on startup but then it brought me the missing zfs module 2017-04-07 13:59:26 are you on edge? 2017-04-07 13:59:46 3.5 - only wanted to upgrade the kernel to solve the sshd delay issue 2017-04-07 14:00:01 but now zfs is broken 2017-04-07 14:00:12 had to rollback to 3.5 again and leave the edge kernel out 2017-04-07 14:00:39 dunno about 3.5 but on edge a kernel upgrade removes the /lib/modules for the running kernel 2017-04-07 14:01:46 maybe i misunderstand you. sorry for confusing you, ignore what i said. 2017-04-07 14:02:21 no problemo man 2017-04-07 14:02:23 https://git.alpinelinux.org/cgit/aports/tree/main/linux-grsec/APKBUILD 2017-04-07 14:02:39 there's a mention of zfs-fix.patch but i'm not sure if this is working 2017-04-07 14:02:46 dfs: if you upgrade the kernel to edge, you should also add zfs-grsec@edge 2017-04-07 14:02:54 since kernel versions and kmod versions need to match 2017-04-07 14:03:00 hmmmm 2017-04-07 14:03:06 Shiz: let me try that then 2017-04-07 14:03:27 Shiz: https://github.com/rust-lang/rust/pull/40113#issuecomment-292544819 2017-04-07 14:05:43 Shiz: works :) thanks man 2017-04-07 14:11:53 jirutka: nice 2017-04-07 14:14:46 I wanted to create a breeze gtk theme engine package for alpine. 2017-04-07 14:15:09 But I found out that there are no common naming scheme for that. 2017-04-07 14:15:36 What should I choose? gtk-engines-breeze? gtk-breeze-engine? 2017-04-07 14:16:05 Should I split it into gtk2 and gtk3? Or split it as dark and light theme? 2017-04-07 14:17:41 i'd do gtk2-breeze or gtk2-engine-breeze 2017-04-07 14:17:47 it should be split in gtk2/3 i think 2017-04-07 14:32:39 Hi 2017-04-07 14:40:12 Ah 2017-04-07 14:40:33 But not gtk-engines-*? 2017-04-07 14:40:58 ACTION personally think that gtk-engines-* name is ugly. 2017-04-07 14:42:48 Shiz: reaction from japaric https://github.com/rust-lang/rust/pull/40113#issuecomment-292555595 2017-04-07 15:27:03 ok its weeked for me 2017-04-07 15:27:21 and im happy with the status of ppc64le and s390x 2017-04-07 15:27:42 and very happy with the alpine team in general 2017-04-07 15:27:45 have a nice week-end :) 2017-04-07 15:27:49 have a nice weekend everyone 2017-04-07 15:34:57 how often the binaries from the builder is synced with http://rsync.alpinelinux.org/alpine/ ? 2017-04-07 15:39:01 leitao: IIRC once per 15 minutes or something like that 2017-04-07 15:39:35 leitao: I’d like to shorten it, it took forever when I need new package to be available for another build :/ 2017-04-07 15:40:13 jirutka: yes, I am not able to try to reproduce some build issues I am seeing at #alpine-commits 2017-04-07 15:59:21 Sync is after build 2017-04-07 15:59:26 Directly 2017-04-07 16:00:12 clandmeter: so why it always take some time until pkg is avaialable at nl.a.o? 2017-04-07 16:00:18 Leitao ^ 2017-04-07 16:00:37 Cause that's another box 2017-04-07 16:00:49 clandmeter: so what is actually the primary source? 2017-04-07 16:00:59 Nl2 2017-04-07 16:02:09 nl.a.o has long time been non master 2017-04-07 16:02:53 We changed to fr.a.o 2017-04-07 16:03:03 And now nl2 2017-04-07 16:03:42 omg, can we create some web site that will just show what is the primary source this week? 2017-04-07 16:03:51 it’s changing all the time XD 2017-04-07 16:07:45 jirutka: Thank you for offering to help with the splitting. We're probably a couple of days before doing that, but not more than a week I would think. 2017-04-07 16:08:05 TemptorSent: ok, just let me know when it’s ready 2017-04-07 16:19:39 jirutka: Will do. 2017-04-07 21:01:25 Shiz: are you here? 2017-04-07 21:01:33 yeah 2017-04-07 21:02:19 Shiz: I’m trying to understand what’s going on in rustc 2017-04-07 21:03:17 Shiz: to recap, now we are able to build rustc and use it with dynamic linking, but static linking is broken 2017-04-07 21:04:00 Shiz: we need to somehow get work both 2017-04-07 21:04:46 yeah 2017-04-07 21:05:47 jirutka: does -C prefer-dynamic work? 2017-04-07 21:05:49 Shiz: if I understand it correctly, we don’t need rustc to pass crt*.o files for static linking, it can (and probably should) use system-provided, since we’re on actual musl system 2017-04-07 21:05:54 yes 2017-04-07 21:06:16 jirutka: rustc has 3 modes of linking 2017-04-07 21:06:27 default: statically link rust libs, dynamically link crt 2017-04-07 21:06:34 -C prefer-dynamic: dynamically link rust libs, dynamically link crt 2017-04-07 21:06:45 -C +static-crt: statically link rust libs, statically link crt 2017-04-07 21:06:54 does -C prefer-dynamic work in your current ver? 2017-04-07 21:08:52 Shiz: https://hastebin.com/raw/yizaxibame 2017-04-07 21:09:05 yep 2017-04-07 21:09:13 jirutka: to fix the -C prefer-dynamic thing, a simple patch is needed 2017-04-07 21:09:17 that I forwarded last night to you 2017-04-07 21:09:19 :p 2017-04-07 21:09:22 at least, the idea 2017-04-07 21:09:29 https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/hack-linux_musl_base.patch 2017-04-07 21:09:40 Shiz: what bothers me more is that -C target-feature=+crt-static does not work… 2017-04-07 21:09:41 add + base.no_default_libraries = false; to this patch 2017-04-07 21:09:46 jirutka: got an error? 2017-04-07 21:10:48 Shiz: but what exactly does this option do? I know that it disables passing -nodefaultlibs to linker, but how will it affect dynamic/static linking? 2017-04-07 21:10:50 very strange that it works with -C prefer-dynamic -C target-feature=-static-crt 2017-04-07 21:10:55 Shiz: ad error, see https://github.com/rust-lang/rust/pull/40113#issuecomment-292544819 2017-04-07 21:11:02 jirutka: it erroneously passes -nodefaultlibs to the linker 2017-04-07 21:11:06 which inhibits linking libc 2017-04-07 21:11:08 Shiz: the second stack trace 2017-04-07 21:11:10 while it is dynamically linking 2017-04-07 21:11:18 that's why oyu get //lib/libc.musl-x86_64.so.1: error adding symbols: DSO missing from command line 2017-04-07 21:11:50 ah yes, unwind 2017-04-07 21:13:46 Shiz: I didn’t get DSO missing… 2017-04-07 21:13:56 it's right there in your log? 2017-04-07 21:14:04 23:08:52 jirutka │ Shiz: https://hastebin.com/raw/yizaxibame 2017-04-07 21:14:19 Shiz: aha, tihs one, pardon 2017-04-07 21:14:23 :) 2017-04-07 21:14:28 Shiz: I’d like to solve static linking problem now 2017-04-07 21:14:32 yeah 2017-04-07 21:14:50 just giving you a solution to make -C prefer-dynamic work without target-feature=-crt-static 2017-04-07 21:14:55 re:static linking... 2017-04-07 21:15:13 Shiz: hm, should the first example work at all? this is trying to statically link C, but dynamically Rust… 2017-04-07 21:15:13 i have a feeling this is not adequately solved by the parti n libunwind 2017-04-07 21:15:28 jirutka: why would it statically link libc? 2017-04-07 21:15:38 did we not flip the switch? 2017-04-07 21:15:45 my rustc links dynamically by default... 2017-04-07 21:16:18 Shiz: that’s because of https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/hack-linux_musl_base.patch#L54, I’ve already put it back 2017-04-07 21:16:37 why put it back? 2017-04-07 21:16:55 i think it's not unreasonable that alpine-packed rustc links dynaically by default 2017-04-07 21:17:01 Shiz: I’d like to stick to the default behaviour, to not confuse ppl even more, so link statically on musl by default 2017-04-07 21:17:20 Shiz: we can use -C target-feature=-crt-static to link dynamically 2017-04-07 21:17:39 in that case i think -C prefer-dynamic should imply -C target-feature=-crt-static 2017-04-07 21:17:45 should be a simple patch i think 2017-04-07 21:17:49 anyway, back to static linking then 2017-04-07 21:18:29 Shiz: the current default behaviour, when glibc is dynamically linked by default, but musl libc is statically linked, is IMO bad, it’s inconsistent, but that’s what rustc currently do on all other platforms… 2017-04-07 21:18:43 i think it's fine for us to differ on that 2017-04-07 21:18:52 if people want to really statically link, they can use -C target-feature=+crt-static... 2017-04-07 21:18:56 anyway 2017-04-07 21:19:04 Shiz: let’s discuss this later 2017-04-07 21:19:07 yes 2017-04-07 21:19:09 :) 2017-04-07 21:19:13 im looking at rustc atm 2017-04-07 21:19:48 Shiz: when we look at https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/hack-linux_musl_base.patch; is -nostdlib really needed for static linking on musl host? 2017-04-07 21:20:19 i'm not sure what they put in liblibc.rlib 2017-04-07 21:20:39 however, the linker already passes -nodefaultlibs 2017-04-07 21:21:01 yes… and should it really pass this on musl host? 2017-04-07 21:21:02 and that is correct 2017-04-07 21:21:07 yes 2017-04-07 21:21:13 jirutka: i believe liblibc.rlib statically embeds libc.a 2017-04-07 21:21:15 so that is fine 2017-04-07 21:21:20 hmm… 2017-04-07 21:21:30 -nodefaultlibs inihibts linkage of libc and (i think?) libgcc 2017-04-07 21:21:35 Shiz: https://github.com/rust-lang/rust/pull/40113#issuecomment-292561266 2017-04-07 21:21:36 but DOES include the platform start files 2017-04-07 21:21:38 which is what you want 2017-04-07 21:21:40 (crt*.s/c) 2017-04-07 21:22:33 Shiz: rustc build system assumes that musl is used only as a target on non-musl system, so they somehow bundle musl libc… I don’t think that we want this behaviour, it’d be imo better to make it use our system-provided libc.a 2017-04-07 21:22:53 i'd agree, but i don't think you can fi that easily 2017-04-07 21:23:14 okay 2017-04-07 21:23:33 jirutka: essentially rust presumes the .rlibs have all dependencies 2017-04-07 21:23:41 rust code itself doesn't rely on libc except if you use liblibc 2017-04-07 21:23:48 so liblibc statically embeds libc.a 2017-04-07 21:23:50 so since linker passes -nodefaultlibs, -nostdlib is not necessary for static linking, do i understand it correctly? 2017-04-07 21:23:52 special-casing libc is going to be hard for that 2017-04-07 21:23:54 jirutka: correct 2017-04-07 21:24:01 jirutka: essentially, it's like this: 2017-04-07 21:24:15 -nostartfiles: don't include the C runtime startup files (crt*.s/c) 2017-04-07 21:24:23 -nodefaultlibs: don't implicitly link libc/libgcc* 2017-04-07 21:24:32 -nostdlib: -nostartfiles and -nodefaultlibs 2017-04-07 21:24:49 for static linking we do want the start files, since they boot up the C environment 2017-04-07 21:24:56 but we don't want libc, since liblibc.rlib embeds it 2017-04-07 21:25:02 so -nodefaultlibs is accurate 2017-04-07 21:25:06 okay 2017-04-07 21:25:34 the issue is, that unwind isn't being linked in properly 2017-04-07 21:25:40 and I think this is the patch's mistake 2017-04-07 21:25:49 it shouldn't try to link in libunwind statically in rust's libunwind 2017-04-07 21:25:58 because other code seems to implicitly use it too 2017-04-07 21:26:10 maybe libunwind should only be added to the final linking step? 2017-04-07 21:26:25 do we want to avoid -nodefaultlibs when linking dynamically? 2017-04-07 21:26:28 yes 2017-04-07 21:26:31 but it already does this 2017-04-07 21:26:39 see your command line when you link with -C target-feature=-crt-static 2017-04-07 21:28:29 jirutka: can you update your repo with your current apkbuild so i can keep up? 2017-04-07 21:28:34 and we don't test things on diverging builds 2017-04-07 21:28:36 :p 2017-04-07 21:29:13 Shiz: no, it passes -nodefaultlibs even when linking dynamically https://hastebin.com/raw/uwajojozoz 2017-04-07 21:29:26 oh 2017-04-07 21:29:28 hum 2017-04-07 21:29:30 well that is not an issue 2017-04-07 21:29:34 since it explicitly passes -lgcc and -lc 2017-04-07 21:29:36 in that case 2017-04-07 21:29:52 so it is nothing to worry about 2017-04-07 21:29:58 updated 2017-04-07 21:30:10 so gcc just ignores it? 2017-04-07 21:30:11 thanks :) 2017-04-07 21:30:17 well, it's not ignored 2017-04-07 21:30:28 but the result is the same? 2017-04-07 21:30:29 gcc just drops the implicit -lc and -lgcc* 2017-04-07 21:30:31 yes 2017-04-07 21:30:32 okay 2017-04-07 21:30:35 since they are added in the commandline again 2017-04-07 21:30:37 :p 2017-04-07 21:30:46 so it's fine like that 2017-04-07 21:31:06 i'll guet the build on 2017-04-07 21:32:28 Shiz: https://hastebin.com/raw/sifezukazu 2017-04-07 21:32:41 Shiz: it should not pass -pie when linking statically :/ 2017-04-07 21:32:46 why not? 2017-04-07 21:32:48 static PIE is fine 2017-04-07 21:32:58 at worst, the compiler will ignore it 2017-04-07 21:33:03 at best, you'll get a static PIE binary 2017-04-07 21:33:07 really? I thought that PIE cannot be used together wih static 2017-04-07 21:33:12 that's pretty old info ;P 2017-04-07 21:33:13 and what the heck: "-Wl,-Bstatic" "-Wl,-Bdynamic" 2017-04-07 21:33:27 static PIE exists these days, although i'm not 100% sure if alpine gcc supports it 2017-04-07 21:33:36 jirutka: check the result binary with # file 2017-04-07 21:33:36 aha, good to know! :) 2017-04-07 21:33:44 if it's an ELF dynamic object, it's static PIE 2017-04-07 21:33:46 there’s no result binary, because it fails… 2017-04-07 21:33:50 uh, right 2017-04-07 21:33:52 derp 2017-04-07 21:33:54 sorry 2017-04-07 21:33:55 :P 2017-04-07 21:33:56 check when we get this working 2017-04-07 21:33:58 :) 2017-04-07 21:34:07 I’ll note it for my future myself :P 2017-04-07 21:34:15 building now 2017-04-07 21:34:20 why "-Wl,-Bstatic" "-Wl,-Bdynamic" ? 2017-04-07 21:34:47 it doesn't really do anything, luckily 2017-04-07 21:34:54 okay… 2017-04-07 21:34:59 afaik -Bstatic and -Bdynamic are used to indicate what kind of file to use for -lfoo invocations 2017-04-07 21:35:04 but there are no -lfoo arguments there 2017-04-07 21:35:07 -Bstatic: libfoo.a 2017-04-07 21:35:12 -Bdynamic: libfoo.so 2017-04-07 21:36:20 jirutka: apparently when linking a static rlib it adds -Bstatic to the cmdline 2017-04-07 21:36:27 okay, next spec: base.pre_link_objects_exe.push("crt1.o".to_string()); and similar are probably okay to get rid of for both static and dynamic on musl host, right? 2017-04-07 21:36:28 and at the end of its processing it adds -Bdynamic 2017-04-07 21:36:31 dumb, but harmless 2017-04-07 21:36:34 jirutka: yes, yes, yes 2017-04-07 21:36:35 :p 2017-04-07 21:36:43 the current patch is basically fine, except for broken static linking 2017-04-07 21:36:51 you never want to ship your own crt*.o, it's very dumb 2017-04-07 21:36:52 great! 2017-04-07 21:36:53 well, WE don't 2017-04-07 21:37:11 so the only problem is with unwind 2017-04-07 21:37:45 yeah 2017-04-07 21:37:49 what’s so special about libunwind? 2017-04-07 21:37:54 https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/support-dynamically-linked-musl.patch#L377 2017-04-07 21:37:57 this is still fishy imo. 2017-04-07 21:38:05 jirutka: actually 2017-04-07 21:38:07 riddle me this 2017-04-07 21:38:16 I remember that I hit some problems with libunwind before, but don’t remember where 2017-04-07 21:38:21 what if you add this line 2017-04-07 21:38:32 #[link(name = "gcc", kind = "static", cfg(target_feature = "crt-static"))] 2017-04-07 21:38:35 below the unwind one 2017-04-07 21:38:45 wild guess (my rustc is still building) 2017-04-07 21:39:15 what is this supposed to do? 2017-04-07 21:39:18 libunwind provides runtime stack unwind support 2017-04-07 21:39:25 it links in libgcc (static version) on crt-static config 2017-04-07 21:39:37 maybee… `cfg(target_feature = "crt-static")` doesn’t really work for some reason…? 2017-04-07 21:39:37 libgcc_s = libgcc, shared (dynamic) version 2017-04-07 21:39:50 libgcc = libgcc.a, static version 2017-04-07 21:39:56 i think that one works 2017-04-07 21:40:08 but maybe... 2017-04-07 21:40:16 hmm 2017-04-07 21:40:22 well, then how can `#[link(name = "gcc", kind = "static", cfg(target_feature = "crt-static"))]` work if gcc is dynamic version…? 2017-04-07 21:41:04 read again 2017-04-07 21:41:05 :) 2017-04-07 21:41:10 gcc_s is the dynamic version 2017-04-07 21:41:13 gcc is the static version 2017-04-07 21:41:18 aha, pardon 2017-04-07 21:41:43 but do we really wanna link whole gcc into static binaries…? 2017-04-07 21:41:47 hehe 2017-04-07 21:41:48 it's libgcc 2017-04-07 21:41:51 not the entirety of gcc 2017-04-07 21:41:57 well, libgcc… 2017-04-07 21:42:06 that response tells me you're unfamiliar with what libgcc is 2017-04-07 21:42:08 :p 2017-04-07 21:42:12 it's not the gcc compiler or anything 2017-04-07 21:42:16 it's gcc's runtime library 2017-04-07 21:42:19 I know 2017-04-07 21:42:20 every static binary needs it 2017-04-07 21:42:22 this https://pkgs.alpinelinux.org/package/edge/main/x86_64/libgcc 2017-04-07 21:42:27 every static binary links it in statically 2017-04-07 21:42:33 else it just won't run 2017-04-07 21:42:35 aha, okay 2017-04-07 21:42:43 it's also fairly small 2017-04-07 21:43:04 or at least 2017-04-07 21:43:07 after linker optimisation 2017-04-07 21:43:08 ;p 2017-04-07 21:43:25 jirutka: if you compile a binary with cc -static, it already implicitly adds libgcc.a 2017-04-07 21:43:26 :) 2017-04-07 21:44:15 Shiz: https://hastebin.com/raw/aqeqakopey 2017-04-07 21:44:29 well 2017-04-07 21:44:31 we're making progress 2017-04-07 21:44:43 yeah that actually doesn't work, i'm silly 2017-04-07 21:44:49 jirutka: got another idea 2017-04-07 21:45:19 jirutka: can you get the full final link step it tries to do? 2017-04-07 21:45:21 the link arg 2017-04-07 21:45:23 wanna test something 2017-04-07 21:46:09 final link step in building rustc or hello_world…? 2017-04-07 21:46:17 hello world 2017-04-07 21:47:13 libgcc.a is not in /usr/lib, but /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/, so maybe it just can’t find it on path…? 2017-04-07 21:47:35 yeah i know what causes it 2017-04-07 21:47:40 you're not supposed to add -lgcc manually 2017-04-07 21:47:48 jirutka: in the final link args, try executing it manually 2017-04-07 21:47:52 and replace 2017-04-07 21:47:54 well 2017-04-07 21:47:56 remove -lgcc 2017-04-07 21:48:01 nd add after -nodefaultlibs 2017-04-07 21:48:03 -static-libgcc 2017-04-07 21:48:11 (rustc has an option to preserve artifacts) 2017-04-07 21:48:36 Shiz: I think that this is what you’ve asked for: https://hastebin.com/raw/sifezukazu ? 2017-04-07 21:48:46 aha 2017-04-07 21:48:57 huh, that one doesnt have -lgcc? 2017-04-07 21:49:13 yep, it doesn’t 2017-04-07 21:49:14 or did you remove the line and rebuild already 2017-04-07 21:49:16 :p 2017-04-07 21:49:19 brb 2017-04-07 21:49:26 I haven’t removed it 2017-04-07 21:51:16 Shiz: I’ve tried to add -static-libgcc after -nodefaultlibs, but the same error about undefined reference to unwind 2017-04-07 21:53:46 back 2017-04-07 21:53:51 jirutka: hmm. 2017-04-07 21:53:57 that is somewhat odd 2017-04-07 21:54:18 ah 2017-04-07 21:54:23 static libgcc doesn't have the unwind stuff.. 2017-04-07 21:54:45 but static libgcc_eh does... 2017-04-07 21:55:04 so how do we get it to link libgcc_eh 2017-04-07 21:56:05 or maybe it's because the symbols are hidden 2017-04-07 21:56:19 just adding -lgcc_eh doesn’t work 2017-04-07 21:56:24 still same error 2017-04-07 21:56:57 yeah that won't work 2017-04-07 21:58:28 hmm 2017-04-07 21:59:36 this is somewhat odd 2017-04-07 21:59:51 jirutka: so, shot in the dark 2017-04-07 22:00:01 what if you just add -lgcc_s instead of -static-libgcc 2017-04-07 22:00:03 :p 2017-04-07 22:01:16 still the same error 2017-04-07 22:03:23 ah, my own rustc compiled now 2017-04-07 22:05:12 right, so i'm looking at the cause 2017-04-07 22:05:29 every error is caused by a use of rust's libunwind in some library code 2017-04-07 22:05:44 ( https://github.com/rust-lang/rust/tree/1.16.0/src/libunwind ) 2017-04-07 22:05:59 because the dynamic version links -lgcc_s, it provides those symbols 2017-04-07 22:06:05 but where are the symbols in static... 2017-04-07 22:06:47 Shiz: Do you have a .a file for it to link? 2017-04-07 22:07:20 libunwind.a simply doesn't have the necessary symbols 2017-04-07 22:07:48 Does it have an additional library it needs linked as well to provide the remaining syms? 2017-04-07 22:09:01 well, i'm trying to find out where static versions of _Unwind_* live 2017-04-07 22:09:06 the dynamic ones live in libgcc_s.so 2017-04-07 22:09:35 Were they even built/installed in the first place? 2017-04-07 22:09:46 yes... 2017-04-07 22:09:56 jirutka: i think it may be a build issue (yet again) 2017-04-07 22:10:09 i have a feeling it should pass -static-libgcc to the build of rust's libunwind.rlib 2017-04-07 22:10:16 Shiz: what else? :) 2017-04-07 22:10:46 Shiz: but how it works on non-musl system when targeting static musl? o.O 2017-04-07 22:10:59 well libgcc is kinda magic 2017-04-07 22:11:03 it's a dded by the compiler 2017-04-07 22:11:13 so a glibc-hosting compiler may behave differently than a musl-hosting compiler 2017-04-07 22:11:15 :p 2017-04-07 22:11:34 i'm not sure though... 2017-04-07 22:13:38 jirutka: also, this patch changed semantics for static musl libunwind linking 2017-04-07 22:13:44 so it's not that unsurprising if it would break it 2017-04-07 22:13:46 :p 2017-04-07 22:14:09 specifically https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/support-dynamically-linked-musl.patch#L344-L382 2017-04-07 22:14:38 yeah 2017-04-07 22:15:06 can’t we just move that condition static/dynamic to https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/support-dynamically-linked-musl.patch#L353 ? 2017-04-07 22:16:20 i don't think build.rs has access to that info 2017-04-07 22:16:25 or the author would've done it already 2017-04-07 22:16:44 well, maybe it does through RUST_CRT_STATIC 2017-04-07 22:16:49 that might be a hint 2017-04-07 22:17:04 but i'm not sure if that propagates through the build script 2017-04-07 22:17:11 hmm… I’ll try it 2017-04-07 22:17:36 i think it's only passed to the rustc bootstrap 2017-04-07 22:18:16 sigh 2017-04-07 22:18:17 this is so fucked 2017-04-07 22:18:28 why can't they just have rust-shared/static native-shared/static flags 2017-04-07 22:18:30 :p 2017-04-07 22:18:49 yes, you’re right, it’s only for bootstrap 2017-04-07 22:23:14 cargo exposes it via env var CARGO_CFG_TARGET_FEATURE 2017-04-07 22:24:44 ah 2017-04-07 22:25:05 https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md 2017-04-07 22:52:23 back 2017-04-07 23:27:03 Shiz: FUCK YEAH!!! 2017-04-07 23:28:30 it works! 2017-04-07 23:29:00 so the last issue is -C target-feature=+crt-static -C prefer-dynamic 2017-04-07 23:34:33 oh? 2017-04-07 23:34:35 what did you do? 2017-04-07 23:34:41 jirutka: that one will never work, probably 2017-04-07 23:38:18 what the hell… 2017-04-07 23:38:25 no, it does not work :( 2017-04-07 23:39:18 I’m idiot, I’ve run ldd on hello_world.rs instead of hello_world… somehow it always links dynamically now :( 2017-04-07 23:39:30 ;p 2017-04-07 23:39:32 nooooooo 2017-04-07 23:39:50 I’ve updated my branch, so you can see what I did 2017-04-07 23:40:00 I’ve modified support-dynamically-linked-musl.patch 2017-04-07 23:41:04 lessee 2017-04-07 23:43:03 Shiz: but something has changed, see the end of command: https://hastebin.com/raw/kejigucaka 2017-04-07 23:43:35 and https://hastebin.com/raw/sewemiceha 2017-04-07 23:44:32 yeah, because the code is wrong 2017-04-07 23:44:33 :p 2017-04-07 23:45:01 if features.contains("crt-static") { 2017-04-07 23:45:02 try 2017-04-07 23:45:16 if !features.contains("-crt-static") { 2017-04-07 23:45:53 hmm 2017-04-07 23:45:54 or is it 2017-04-07 23:45:59 no, this should be righ 2017-04-07 23:46:01 see the RFC 2017-04-07 23:46:21 yeah but the pull request rearranges stuff 2017-04-07 23:47:29 but not this 2017-04-07 23:47:43 im unsure too 2017-04-07 23:47:44 https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md#lowering-cfg-values-to-cargo-build-script-environment-variables 2017-04-07 23:47:45 double-checking 2017-04-07 23:48:06 but if it doesn't, it's weird that gcc_s somehow gets added 2017-04-07 23:48:28 it’s going through default branch of the condition 2017-04-07 23:49:03 I think that CARGO_CFG_TARGET_FEATURE is not set 2017-04-07 23:49:10 ... oh 2017-04-07 23:49:11 ./honk.patch:++ // To prevent some nasty linking errors, link in libgcc_s here. 2017-04-07 23:49:13 ./honk.patch:++ base.pre_link_args.push("-lgcc_s".to_string()); 2017-04-07 23:49:23 thats just a local patch 2017-04-07 23:49:24 nvm 2017-04-07 23:49:34 yeah... 2017-04-07 23:49:43 or maybe it just works totally differently 2017-04-07 23:49:55 I don’t use this patch 2017-04-07 23:50:08 jirutka: ... right 2017-04-07 23:50:16 yeah it was just a leftover 2017-04-07 23:50:20 jirutka: maybe our cargo is too old 2017-04-07 23:50:26 buut 2017-04-07 23:50:30 this lib is built when building rustc 2017-04-07 23:50:34 this doesnt make sense 2017-04-07 23:50:38 yeah 2017-04-07 23:50:39 then it does not build it from source, doesn’t it? 2017-04-07 23:50:41 the build.rs is for libunwind 2017-04-07 23:50:52 the commandline you posted is for a simple hello.rs 2017-04-07 23:50:52 so this modification in build.rs is totally useless 2017-04-07 23:51:03 where does the gcc_s come from? 2017-04-07 23:51:06 that's so weird 2017-04-07 23:51:12 right 2017-04-07 23:51:16 so it somehow affects it 2017-04-07 23:51:19 no, since the issue is in libunwind 2017-04-07 23:51:20 omg i have no clue 2017-04-07 23:51:22 to tired 2017-04-07 23:51:22 hehe 2017-04-07 23:51:30 lemme do a rebuild from your updated repo 2017-04-07 23:51:47 (also, I hope we're not using VERBOSE=1 in the final APKBUILD...) 2017-04-07 23:52:39 why not? 2017-04-07 23:53:01 it seems unnecessary verbose, but may be just me 2017-04-07 23:53:05 I almost always build with verbose, so I can see what’s going on 2017-04-08 00:10:22 fabled: When you see this, check APK Redmine - I just made some work for you I'm afraid, as I'm not up to speed on the guts of apk enough to handle it easily yet. 2017-04-08 00:13:25 fabled: Issue #7100 #7101 #7102 #7103 2017-04-08 00:13:43 Oops :) 2017-04-08 00:14:24 okay, can repro... 2017-04-08 00:14:38 jirutka: so strange that it's dynamic default now 2017-04-08 00:15:16 jirutka: actually, i can't get it to build statically anymore... 2017-04-08 00:17:09 Question: Is sha1 going to remain the default checksum for files in .apks for the forseeable future? 2017-04-08 00:18:28 jirutka: okay so 2017-04-08 00:18:36 -static-libgcc doesn't seem to pass libgcc to the linker... 2017-04-08 00:18:41 TemptorSent: no 2017-04-08 00:19:57 Shiz: Okay, will we be going to sha512 instead? 2017-04-08 00:20:06 yes 2017-04-08 00:20:14 jirutka: still here? 2017-04-08 00:20:41 Thank you, any idea on timing? Will the sha1 sums in the pax headers continue as well? 2017-04-08 00:21:06 jirutka: i got the magic combo 2017-04-08 00:21:08 :p 2017-04-08 00:21:22 no clue, ask kaniini/fabled 2017-04-08 00:21:51 Up,Up,Down,Down,Left,Right,Left,Right,B,A,B,A,Select,Start? 2017-04-08 00:23:12 Will do. 2017-04-08 00:24:44 <^7heo> TemptorSent: not sure anyone here knows that konami reference 2017-04-08 00:30:20 *lol* Yeah ^7heo, I get to feel old again :P 2017-04-08 03:23:09 jirutka: it works! 2017-04-08 03:23:11 https://txt.shiz.me/OGViNmYxYW 2017-04-08 03:27:36 hey guys 2017-04-08 03:28:10 allah is doing 2017-04-08 03:28:15 sun is not doing allah is doing 2017-04-08 03:28:18 to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger 2017-04-08 03:38:03 jirutka: https://txt.shiz.me/MGI3NjEzNz 2017-04-08 03:38:11 working patch on top of the current 1.10.0 apkbuild 2017-04-08 03:38:19 now we clean it up 2017-04-08 03:38:28 (and make our own bootstrap files, hopefully) 2017-04-08 03:44:43 if i was not using matrix i would have kickbanned that chatter29 2017-04-08 03:44:47 with something like 2017-04-08 03:44:49 'allah is banning' 2017-04-08 03:54:07 Shiz : may I ask what is your implementation at : https://txt.shiz.me/ ? 2017-04-08 03:54:39 TemptorSent : you must have a good relationship with thunder and such lol 2017-04-08 04:04:37 tmh1999: https://txt.shiz.me/self 2017-04-08 04:05:06 Shiz : wow! Thank you. 2017-04-08 04:05:25 https://github.com/Shizmob/upaste 2017-04-08 04:05:35 im not sure how up to date the repo version is, but it has the other files 2017-04-08 04:06:30 Thank you. I have been looking for simple pastebin implementation show I can put in ggappengine ... 2017-04-08 04:13:12 tmh1999: Yeah, I'm just glad we didn't have any direct strikes. It was impressive. 2017-04-08 05:26:52 kaniini : with this commit : https://git.alpinelinux.org/cgit/abuild/commit/abuild.in?id=ecc1f509c6d469223cfbf4ef3f7c574de286ba6e, is it safe to remove update_config_sub in APKBUILD where the source package does not provide config.sub ? 2017-04-08 05:37:36 yes 2017-04-08 05:39:23 kaniini : Thanks 2017-04-08 09:03:41 Shiz: excellent! \o/ 2017-04-08 09:03:54 Shiz: great catch with libunwind! 2017-04-08 10:38:27 Shiz: in what timezone do you live…? 2017-04-08 10:40:08 Shiz: now I see that you’ve also fixed static PIE, great job! 2017-04-08 11:14:25 kaniini: fabled: is it okay to use /etc/ld.so.conf on Alpine? 2017-04-08 11:17:14 no 2017-04-08 11:17:24 if anything, /etc/ld-musl-$ARCH.conf 2017-04-08 11:17:36 um 2017-04-08 11:17:43 /etc/ld-musl-$ARCH.path 2017-04-08 11:19:40 kaniini, hi. Can you help me with https://github.com/alpinelinux/abuild/pull/15 ? 2017-04-08 11:26:52 skarnet: are you sure? there’s no track about ld-musl-*.path in any existing abuild 2017-04-08 11:27:17 then it's not used in Alpine 2017-04-08 11:27:52 but yes, I'm sure that /etc/ld.so.conf is glibc-only, and the musl equivalent is what I wrote 2017-04-08 11:28:51 skarnet: what is better when I have bunch of .so libs that should be treat as private for certain bins only? use rpath, symlink them into /usr/lib or use ld-musl-*.path… or something different? 2017-04-08 11:29:12 private for certain bins -> rpath 2017-04-08 11:29:18 okay 2017-04-08 11:29:33 (statically linking them would be even better, but unfortunately not always possible) 2017-04-08 11:30:15 ld-musl-*.path and /usr/lib are global, so should only be used for public accessible .so's 2017-04-08 12:01:49 <^7heo> why was #6217 closed while it was solved already? 2017-04-08 12:21:41 jirutka: same as yours, just with weird sleeping patterns 2017-04-08 12:21:43 :P 2017-04-08 12:21:50 Shiz: aha :) 2017-04-08 12:22:32 Shiz: unfortunately static linking doesn’t work, it still produces dynamically linked binary: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped, with debug_info 2017-04-08 12:22:39 jirutka: that is fine 2017-04-08 12:22:43 that is what a static PIE binary *is* 2017-04-08 12:22:43 Shiz: but linked just with ldd: ldd (0x2fc3768f000) 2017-04-08 12:22:49 Shiz: really? 2017-04-08 12:22:50 yes 2017-04-08 12:22:56 try using readelf -d instead of ldd 2017-04-08 12:22:58 :p 2017-04-08 12:23:04 Shiz: and will it work on any Linux system? 2017-04-08 12:23:18 static PIE binaries are dynamic binaries without a loader or any RT_NEEDED entries 2017-04-08 12:23:20 yep 2017-04-08 12:23:46 aha, that’s why I thought that PIE doesn’t work with static, b/c I checked just file and ldd 2017-04-08 12:24:25 really, it works on glibc system! 2017-04-08 12:42:47 Shiz: is that okay (the description)? http://tpaste.us/40v1 2017-04-08 12:54:24 jirutka: i made a typo it's DT_NEEDED not RD_NEEDED 2017-04-08 12:54:26 :p 2017-04-08 12:54:34 okay :) 2017-04-08 12:54:57 i'm unsure about the windows linker arg, i have to verify 2017-04-08 12:54:59 also 2017-04-08 12:55:04 >From: Contributor: Shiz 2017-04-08 12:55:07 looks slightly broken 2017-04-08 12:55:09 rest LGTM! 2017-04-08 12:57:02 want me to add a comment to the rust PR? 2017-04-08 13:02:07 Shiz: yes plese :) 2017-04-08 13:03:52 <^7heo> hey guys 2017-04-08 13:05:17 Shiz: fixed patch http://tpaste.us/aQvB 2017-04-08 13:05:20 ^7heo: hi! 2017-04-08 13:08:56 <^7heo> So now I have to work this week end, by installing the potential 3.6 release, on a recent laptop 2017-04-08 13:09:15 <^7heo> with zfs over cryptsetup 2017-04-08 13:09:53 ^7heo: please keep us updated \o/ 2017-04-08 13:11:10 https://github.com/rust-lang/rust/pull/40113#issuecomment-292717038 2017-04-08 13:11:17 jirutka: ^ 2017-04-08 13:12:06 Shiz: thanks! 2017-04-08 13:12:20 Shiz: but please don’t link my branch, I’ll remove it after merging into aports 2017-04-08 13:12:39 (let's clean it up first) 2017-04-08 13:12:40 Shiz: it’d be better to add the relevant patches as attachment to your comment 2017-04-08 13:12:41 :p 2017-04-08 13:12:43 right 2017-04-08 13:12:50 Shiz: I’m currently working on cleaning 2017-04-08 13:12:58 i don't think you can attach patches... 2017-04-08 13:13:04 i'll host them on up.shiz.me 2017-04-08 13:15:25 <^7heo> scadu: ok ;) 2017-04-08 13:16:05 Shiz: you can, but maybe need to change .patch to .txt or something like that, b/c of stupid file extension checking… 2017-04-08 13:16:21 i just linked to entries on txt.shiz.me 2017-04-08 13:16:23 also works :p 2017-04-08 13:17:15 yeah :) 2017-04-08 13:35:54 congrats guys 2017-04-08 13:35:57 good work! 2017-04-08 13:46:22 :) 2017-04-08 14:06:28 jirutka: any thoughts on the /usr/lib vs /usr/lib/rustlib thing? 2017-04-08 14:07:25 Shiz: Fedora keeps *.so only in /usr/lib/rustlib/$arch/lib and adds this path to ld.so.conf.d/rust 2017-04-08 14:07:33 hmm... 2017-04-08 14:07:37 i wonder how they do it 2017-04-08 14:07:38 :p 2017-04-08 14:08:40 Shiz: I’ve discussed this with skarnet and the conclusion is to not put de-facto private so libs into /usr/lib or /etc/ld-musl-$ARCH.path (equivalent of /etc/ld.so.conf on musl) and use rpath 2017-04-08 14:08:54 sounds reasonable 2017-04-08 14:09:12 why do we add --disable-rpath to configure right now? 2017-04-08 14:10:01 Shiz: b/c I thought that it’s a good idea… :) 2017-04-08 14:10:16 :p 2017-04-08 14:10:31 Shiz: I’ve removed it now and gonna fix rpath with chrpath to /usr/lib/rustlib/$ARCH/lib 2017-04-08 14:10:40 Shiz: need to do some chore now, afk 2017-04-08 14:10:46 i'm not sure that's the best approach... 2017-04-08 14:10:52 good luck :) 2017-04-08 14:11:08 Shiz: what would you prefer? 2017-04-08 14:11:18 ideally i'd want the rust toolchain to handle all of it already 2017-04-08 14:11:22 no manual chrpath stuff 2017-04-08 14:11:56 Shiz: yes, but unfortunately rustc and rustdoc have rpath pointing to /usr/lib :/ 2017-04-08 14:12:33 hmm 2017-04-08 14:12:40 i'll see what i can do from here :) 2017-04-08 14:28:50 jirutka: think i may have jemalloc work 2017-04-08 14:32:56 Shiz, jemalloc performs better then system malloc? 2017-04-08 14:33:19 it's not that big of difference i think, but there is some 2017-04-08 14:33:28 more importantly, it's the default they use 2017-04-08 14:33:32 so we don't have to hack around it 2017-04-08 14:33:33 :p 2017-04-08 14:33:46 <^7heo> what's the difference between /dev/shm and /tmp ? 2017-04-08 14:34:06 <^7heo> or rather, why can't the programs using /dev/shm use /tmp instead? 2017-04-08 14:34:41 they could, but you don't want them to 2017-04-08 14:34:45 /tmp is not always a tmpfs 2017-04-08 14:34:49 /dev/shm is guaranteed to be if it's present 2017-04-08 14:34:52 (also Linux-only) 2017-04-08 14:35:12 <^7heo> hmm ok 2017-04-08 14:35:16 the shared memory API creates files in /dev/shm, you don't want them to mix with /tmp files 2017-04-08 14:35:49 but /dev/shm *could* be a link to a place in an already-mounted tmpfs 2017-04-08 14:36:21 (that's what I do on my systems to reduce the number of useless mounts) 2017-04-08 14:36:34 <^7heo> skarnet: I mean, it could be /tmp/shm 2017-04-08 14:36:55 if you have the guarantee that /tmp is a tmpfs, then yes, it could be 2017-04-08 14:36:58 <^7heo> ok 2017-04-08 14:42:19 <^7heo> thanks skarnet and Shiz ;) 2017-04-08 14:44:59 <^7heo> another question, why would programs define their own error printing routines when they can use assert.h? 2017-04-08 14:46:22 jirutka: actually, i think this issue will fix itself 2017-04-08 14:46:54 ^7heo: ? 2017-04-08 14:47:00 assert.h is for assertions, not errors 2017-04-08 14:47:05 assertions get compiled out in release builds 2017-04-08 14:48:55 <^7heo> right 2017-04-08 14:49:07 err.h, on the other hand... 2017-04-08 14:49:10 but nonstandard afaik 2017-04-08 14:50:05 <^7heo> stupid me, it's defined to ((void)0) when NDEBUG is defined 2017-04-08 14:51:18 :) 2017-04-08 14:53:22 whoo, segfaulting rustc 2017-04-08 15:19:56 ^7heo: skarnet: /dev/shm is a symlink to /run/shm on some systems and /run is tmpfs 2017-04-08 15:20:15 Shiz: how it can fix itself? :) 2017-04-08 15:20:51 Shiz: you’ve compiled rustc with jemalloc, haven’t you? ;) 2017-04-08 15:20:56 yes :p 2017-04-08 15:21:02 i tried to see if i could get jemalloc working 2017-04-08 15:21:07 Shiz: yes, then it’s segfaulting :P 2017-04-08 15:21:09 re-compiling in debug mode 2017-04-08 15:21:30 Shiz: we don’t hack around it, Rust provides compile option to disable-jemalloc 2017-04-08 15:21:42 :) 2017-04-08 15:21:48 well, we hack around it with the tests 2017-04-08 15:21:54 still, it's something i'd like to see work 2017-04-08 15:21:56 :p 2017-04-08 15:23:00 ah, yes 2017-04-08 15:23:13 tests are kinda broken now, but haven’t investigated it yet 2017-04-08 15:38:13 “Plus isn't it fun to pass a flag to a tool to pass a flag to pass a flag to a tool to change a flag in a binary?” XD 2017-04-08 15:38:51 ;p 2017-04-08 16:02:37 jirutka: might've found a jemalloc fix :) 2017-04-08 16:04:27 Shiz: might’ve found simple fix for rpath :) 2017-04-08 16:04:39 oh? 2017-04-08 16:04:40 teamwork, yeah! \o/ 2017-04-08 16:24:51 leitao: i'd rather not pull lzip in as a dependency right now 2017-04-08 16:30:56 leitao: but fine, i did it 2017-04-08 16:54:12 jirutka: jemalloc works 2017-04-08 16:55:03 Shiz: great! how you did it? 2017-04-08 16:55:43 tiny patch and using the vendored jemalloc 2017-04-08 16:56:15 why vendored? 2017-04-08 16:56:51 https://txt.shiz.me/Y2Y1N2EwZT 2017-04-08 16:56:59 jirutka: see the patch :p 2017-04-08 16:57:07 jemalloc borks if it uses the same symbol names as libc malloc 2017-04-08 16:57:13 so i added musl to the list of targets to use the je_* prefix for 2017-04-08 16:57:20 but our alpine jemalloc uses the unprefixed symbols 2017-04-08 16:58:12 ahaa 2017-04-08 16:58:34 could you please write a comment to your fix-jemalloc-musl.patch ? 2017-04-08 16:58:38 ofc 2017-04-08 16:58:42 this is just my local diff atm 2017-04-08 16:58:44 :p 2017-04-08 17:01:42 jirutka: whats your rpath solution look like? 2017-04-08 17:01:53 Shiz: not-working :( 2017-04-08 17:01:57 aw 2017-04-08 17:02:02 Shiz: trying different one, more invasive, now 2017-04-08 17:03:33 hmm 2017-04-08 17:03:42 i'm wondering how to make rustc use the rustlib path... 2017-04-08 17:03:46 I thought that I can --disable-rpath and then pass env. var RUSTC_FLAGS="-Wl,-rpath,$ORIGIN/../lib/rustlib/x86_64-unknown-linux-musl/lib", but that doesn’t work 2017-04-08 17:04:10 so now I’m trying to directly patch src/bootstrap/bin/rustc.rb 2017-04-08 17:04:33 Some(format!("-Wl,-rpath,$ORIGIN/../lib/rustlib/{}/lib", target)) 2017-04-08 17:06:22 afk 2017-04-08 17:06:40 i wonder if ./configure --libdir=lib/rustlib/x86_64-unknown-linux-musl/lib works 2017-04-08 17:17:13 jirutka: making progress in rpath 2017-04-08 17:17:15 :p 2017-04-08 17:24:25 <^7heo> the setup-bootable script reports a lot of errors with vfat. 2017-04-08 17:24:29 <^7heo> But it still works I think. 2017-04-08 17:24:53 <^7heo> Maybe it would be worth it to suppress those errors? 2017-04-08 17:25:35 <^7heo> (it's only `cp: can't preserve ownership of '...': Operation not permitted` errors) 2017-04-08 17:38:40 Shiz: my patch for rpath works :) 2017-04-08 17:39:08 my approach doesn't need patching 2017-04-08 17:39:09 Shiz: that would affect even rustlib 2017-04-08 17:39:09 :D 2017-04-08 17:39:13 and does the same 2017-04-08 17:39:17 but i'm still checking if it works 2017-04-08 17:39:35 Shiz: really? doesn’t it also move location of rustlib…? 2017-04-08 17:39:51 i'm checking.. but i think it has some special thing 2017-04-08 17:39:54 it's still compiling 2017-04-08 17:39:56 :p 2017-04-08 17:39:59 okay 2017-04-08 17:41:43 jirutka: do you only patch in bootstrap? 2017-04-08 17:41:47 or what does your patch touch 2017-04-08 17:41:52 if so that is probably okay too 2017-04-08 17:41:53 Shiz: yes, only bootstrap 2017-04-08 17:42:44 Shiz: IIRC I’ve already tried changing --libdir yesterday and it also moved rustlib, but I’m not 100% sure, my bad memory :/ 2017-04-08 17:45:44 :p 2017-04-08 17:46:22 yeah, it does... 2017-04-08 17:46:24 bwuh 2017-04-08 17:48:26 jirutka: okay, that bootstrap patch looks fine judging from rustc.rs 2017-04-08 17:56:16 jirutka: i found an interesting option 2017-04-08 17:56:51 Shiz: which one? 2017-04-08 17:57:01 well not option, but function 2017-04-08 17:57:18 https://github.com/rust-lang/rust/blob/1.16.0/src/bootstrap/lib.rs#L780 2017-04-08 17:58:02 hmm 2017-04-08 17:58:09 https://github.com/rust-lang/rust/blob/1.16.0/src/bootstrap/util.rs#L122 2017-04-08 17:58:10 looks like a better place where to patch 2017-04-08 17:58:11 also of relevance 2017-04-08 17:59:36 yeah i think the latter is even better 2017-04-08 18:00:42 but look at this https://github.com/rust-lang/rust/blob/1.16.0/src/bootstrap/bin/rustc.rs#L194 2017-04-08 18:01:13 it directly passes flag for linter and it does not call that function from util.rs 2017-04-08 18:03:08 yeah we need to change that 2017-04-08 18:03:10 but it's easy 2017-04-08 18:04:01 but why? it will just affect more code…? 2017-04-08 18:04:13 it'll make it cleaner 2017-04-08 18:04:20 and possibly remove some duplication 2017-04-08 18:04:47 Shiz: http://tpaste.us/qMYy 2017-04-08 18:04:58 this is all what I needed to change 2017-04-08 18:07:11 yeah but it's less suitable for upstreaming 2017-04-08 18:07:24 aha 2017-04-08 18:07:37 I was thinking about this as only downstream patch 2017-04-08 18:12:18 hmm 2017-04-08 18:12:23 well, it's buidling now 2017-04-08 18:12:26 we'll see... 2017-04-08 18:12:42 your patch works now either way, i'm just seeing if i can make it slightly cleaner/upstreamable 2017-04-08 18:12:43 should we want to 2017-04-08 18:12:45 :) 2017-04-08 18:14:15 I’m afraid that upstream wants it as is, for whatever reason, otherwise why they did more work to install these libs into two locations? 2017-04-08 18:15:31 https://github.com/rust-lang/rust/issues/37971 2017-04-08 18:16:27 https://github.com/rust-lang-nursery/rustup.rs/issues/837 2017-04-08 18:18:40 rustc_llvm, rustc and rustc_driver 2017-04-08 18:18:49 always the same components taking so long 2017-04-08 18:18:51 :p 2017-04-08 18:19:14 yeah 2017-04-08 18:19:17 jirutka: advantage of my patch is that i believe the libs wouldn't get installed to lib/ in the first place 2017-04-08 18:19:18 it takes forever to compile 2017-04-08 18:19:23 so we don't have to do manual removal/tracking of that 2017-04-08 18:19:27 :p 2017-04-08 18:19:43 ehm… 2017-04-08 18:20:07 but your patch affects more code, so it’d be harder to maintain 2017-04-08 18:20:31 true, but it's only relatively simple utility functions it affects 2017-04-08 18:20:57 jirutka: you on the rust irc? 2017-04-08 18:21:17 but still… why? if it will remain as downstream patch, then it’s better to affect less code 2017-04-08 18:21:20 nope, I’m not 2017-04-08 18:31:15 error[E0523]: found two different crates with name `rustc` that are not distinguished by differing `-C metadata`. This will result in symbol conflicts between the two. 2017-04-08 18:31:18 interesting errors 2017-04-08 18:31:19 :p 2017-04-08 18:32:09 how you did that? 2017-04-08 18:32:50 my libdir patch 2017-04-08 18:35:03 i will shelve this patch for now 2017-04-08 18:38:41 jirutka: https://txt.shiz.me/M2NhNjEwZm 2017-04-08 18:55:06 Shiz: thanks! 2017-04-08 18:55:17 Shiz: could you please also open a PR on rust-lang/rust? 2017-04-08 19:00:08 Shiz: is this useful for us? https://src.fedoraproject.org/cgit/rpms/rust.git/tree/rust.spec#n192 2017-04-08 19:02:12 jirutka: already part of stock alpien gcc 2017-04-08 19:02:28 Shiz: that’s what I thought :) 2017-04-08 19:06:40 Shiz: any idea why make check produces dozens of failures? 2017-04-08 19:11:06 i'd need to see them :p 2017-04-08 19:11:23 Why, oh why, is apk segfaulting on me THIS time? 2017-04-08 19:12:50 Ah, bad input again -- filename out of order and CRASH :) 2017-04-08 19:15:37 jirutka: also fixed the LD_LIBRARY_PATH issue btw 2017-04-08 19:15:50 Shiz: patch plz :) 2017-04-08 19:16:11 hold on, not fully yet it seems 2017-04-08 19:16:18 (it broke somewhere middle in the build process) 2017-04-08 19:17:45 jirutka: also why do we --disable-docs right now? 2017-04-08 19:18:13 Shiz: ’cause it produces just HTML pages that you can view online; I don’t really want to bother with that :) 2017-04-08 19:18:19 okay 2017-04-08 19:18:52 jirutka: also 2017-04-08 19:18:54 https://github.com/alpinelinux/aports/pull/1222/files#diff-0d0f9a278fdcdf00a9167fd4861cdfe7R108 2017-04-08 19:18:57 this local stanza seems unneeded? 2017-04-08 19:19:23 Shiz: yeah, good catch! I forgot to remove it 2017-04-08 19:20:02 also that ldpath= seems unused 2017-04-08 19:20:03 :P 2017-04-08 19:21:20 nn, it’s used by abuild for tracking deps 2017-04-08 19:21:51 oh 2017-04-08 19:21:54 i didnt know that 2017-04-08 19:25:04 Shiz: I’m thinking if we should bother with creating rust-bootstrap for cross-compiling rustc on glibc-based system to musl, or rely on binaries from VoidLinux for bootstrapping 2017-04-08 19:25:39 Shiz: it doesn’t look like upstream will provide prebuilt binaries for musl soon :/ 2017-04-08 19:25:56 can't we use our own builds to bootstrap? 2017-04-08 19:26:06 jirutka: how about a -bootstrap() subpackage? 2017-04-08 19:26:09 that packages make dist 2017-04-08 19:26:14 that should recreate what void gives 2017-04-08 19:26:16 us 2017-04-08 19:27:17 we can, but IIRC Alpine’s approach is to be able to bootstrap complete distro from nothing, without relaying on previous builds 2017-04-08 19:27:25 kaniini: ? ^ 2017-04-08 19:41:07 jirutka: making a PR for jemalloc atm 2017-04-08 19:42:14 jirutka yes indeed that is the goal 2017-04-08 19:44:41 what we did for haskell was basically to use docker iirc 2017-04-08 19:47:56 kaniini: I know 2017-04-08 19:48:26 imo 2017-04-08 19:48:38 what we should do is look at either that as an option 2017-04-08 19:49:36 or there is... the option of using the glibc packaging 2017-04-08 19:49:37 to run rustc 2017-04-08 19:49:42 but that one i don't like 2017-04-08 19:49:43 because 2017-04-08 19:49:53 it may encourage other bad things 2017-04-08 19:56:45 kaniini: like installing glibc on Alpine? I’d rather not open this Pandora box 2017-04-08 19:57:06 somebody already opened that box 2017-04-08 19:57:31 https://github.com/sgerrand/alpine-pkg-glibc 2017-04-08 20:00:01 jirutka: my LD_LIBRARY_PATH solution still requires you to pass it to make, but at least you don't have to delete the lines from bootstrap anymore 2017-04-08 20:00:08 since bootstrap actually gets it right 2017-04-08 20:00:10 :p 2017-04-08 20:00:33 jirutka: also, a proper solution for LD_LIBRARY_PATH would be to use -rpath properly on the binaries we use to bootstrap 2017-04-08 20:00:36 so we wouldn't need it anymore 2017-04-08 20:02:23 Shiz: https://src.fedoraproject.org/cgit/rpms/rust.git/tree/rust.spec#n185 2017-04-08 20:03:09 jirutka: so we only want to use strip -g? :) 2017-04-08 20:03:21 Shiz: when I run `strip` on some Rust’s *.so lib and then check objdump -h, I still see the section .rustc; does it mean that our strip does not strip that section? 2017-04-08 20:03:54 i think fedora uses a more agressive strip 2017-04-08 20:04:02 jirutka: what made you add !strip in the first place? 2017-04-08 20:04:02 so we should be safe? 2017-04-08 20:04:04 did it not work before? 2017-04-08 20:04:12 Shiz: I can’t remember :( 2017-04-08 20:04:30 :p 2017-04-08 20:04:44 we're not sure if that's the whole reason, do we 2017-04-08 20:04:47 Shiz: it was probably just temporal 2017-04-08 20:05:20 jirutka: https://txt.shiz.me/N2Q0ODM1MD 2017-04-08 20:05:22 what do you think of this? 2017-04-08 20:07:21 uh, rustc now produces much bigger static binaries 2017-04-08 20:07:31 maybe because of jemalloc? 2017-04-08 20:07:46 how much bigger is much bigger? 2017-04-08 20:08:05 or that I’ve added --enable-debuginfo? but that should affect only rustc itself, right? 2017-04-08 20:08:21 like 4.9 MiB for hello_world instaed of 2.2 MiB (unstripped) 2017-04-08 20:08:28 that's definitely not jemalloc i think 2017-04-08 20:08:32 my jemalloc hello_world was 2.5mb 2017-04-08 20:08:45 stripped 358 kiB instead of ~160 kiB 2017-04-08 20:08:49 or something like that 2017-04-08 20:08:52 jirutka: i think --enable-debuginfo also includes libstd and the like 2017-04-08 20:08:56 which then get statically linked in 2017-04-08 20:08:58 :p 2017-04-08 20:12:03 ad https://txt.shiz.me/N2Q0ODM1MD: not sure, it seems maybe more hackish than my approach, b/c you lie to rustc about the version of stage0 2017-04-08 20:12:26 I’m surprised that it works 2017-04-08 20:12:36 it used to be harder to cheat it 2017-04-08 20:12:45 they removed they key stuff 2017-04-08 20:12:54 but yeah im not sure either 2017-04-08 20:13:06 jirutka: this would not be a problem if our bootstrap binaries had proper rpath 2017-04-08 20:13:08 :p 2017-04-08 20:13:49 yeah let's drop that patch 2017-04-08 20:13:53 it's more unstable 2017-04-08 20:14:06 jirutka: although i still would recommend at least adding the change in cargo revision to your apkbuild 2017-04-08 20:14:12 that's the "official" cargo it's supposed to be abuilt with 2017-04-08 20:14:15 from src/stage0.txt 2017-04-08 20:23:55 Shiz: okay 2017-04-08 20:24:28 also maybe we should call rust-stdlib rust-libs? 2017-04-08 20:24:39 more in line with other alpine package names 2017-04-08 20:24:50 and considering they also provide the compiler-needed libraries 2017-04-08 20:33:42 Shiz: -libs has different semantic 2017-04-08 20:33:53 Shiz: maybe more appropriate would be -libs-static 2017-04-08 20:34:06 Shiz: does not contain compiler-needed libs anymore :) 2017-04-08 20:35:52 ? re: the latter 2017-04-08 20:37:31 Shiz: I’ve already moved *.so to the base pkg 2017-04-08 20:40:55 Shiz: https://github.com/alpinelinux/aports/pull/1222 2017-04-08 20:42:24 what does rust-dbg contain btw? 2017-04-08 20:42:32 same but unstripped? 2017-04-08 20:42:42 .debug objects 2017-04-08 20:43:37 also, why do we depend on musl-dev? 2017-04-08 20:43:41 the crt* files? 2017-04-08 20:44:23 foo.debug is a complement to foo binary; the former contains debug symbols that has been stripped from the latter 2017-04-08 20:44:28 right 2017-04-08 20:44:29 yes, crt files 2017-04-08 20:44:48 gotcha 2017-04-08 20:45:59 https://github.com/rpm-software-management/rpm/pull/192 2017-04-08 20:46:01 problem first discovered in alpine 2017-04-08 20:46:40 all distros that provide pkg-config metadata appear to have metadata corruption caused by pkg-config stupidity 2017-04-08 20:48:16 in our case it was corrupting modemmanager-dev provides list 2017-04-08 20:48:28 :) 2017-04-08 20:48:33 jirutka: https://github.com/rust-lang/rust/pull/41168 2017-04-08 20:56:09 gonna make a cargo package i think 2017-04-08 20:57:56 Shiz: we already have cargo pkg ;) 2017-04-08 20:58:12 do we? 2017-04-08 20:58:17 Shiz: how can I reliably detect if some binary is correct static PIE binary? 2017-04-08 20:58:22 oh we do 2017-04-08 20:58:31 https://pkgs.alpinelinux.org/package/edge/testing/x86_64/cargo 2017-04-08 20:59:30 jirutka: no DT_INTERP or DT_NEEDED entries 2017-04-08 20:59:43 and PIE in FLAGS_1 2017-04-08 21:00:09 s/DT_INTERP/PT_INTERP/ 2017-04-08 21:00:24 Shiz: using readelf -d ? 2017-04-08 21:00:37 for NEEDED, yes 2017-04-08 21:00:40 INTERP is part of the program headers 2017-04-08 21:01:01 i’d like to add test to check() for this 2017-04-08 21:01:03 readelf -l mybinary | grep -q INTERP 2017-04-08 21:01:11 readelf -d mybinary | grep -q NEEDED 2017-04-08 21:01:21 readelf -d mybinary | grep FLAGS_1 | grep -q PIE 2017-04-08 21:01:25 first two need to fail, last one needs to pass 2017-04-08 21:01:31 thanks! 2017-04-08 21:06:55 jirutka: the cargo package probalby needs an update :p 2017-04-08 21:06:57 ACTION gets on it 2017-04-08 21:07:01 I know 2017-04-08 21:09:12 also, do we want to make the rust apkbuild multi-arch compatible? 2017-04-08 21:09:19 it's currently a lonely single arch 2017-04-08 21:16:25 yes, this is next step 2017-04-08 21:17:34 :) 2017-04-08 21:28:26 i also have an idea for verifying cargo deps... 2017-04-08 21:36:14 Shiz: it seems that downgrading cargo has fixed tests :) 2017-04-08 21:36:27 to the recommended one? 2017-04-08 21:36:30 yeah 2017-04-08 21:36:33 fascinating 2017-04-08 21:36:36 :) 2017-04-08 21:36:46 jirutka: meanwhile my check() for the cargo package is being killed by grsec 2017-04-08 21:36:48 :p 2017-04-08 21:36:48 it seems that the newer one runs linters that the older one does not 2017-04-08 21:36:52 null deref 2017-04-08 21:37:44 I have one failure https://hastebin.com/raw/azizoceson 2017-04-08 21:37:57 that is quite expected :) 2017-04-08 21:38:05 hmm, I run on grsec system, but no problem 2017-04-08 21:39:35 anyway 2017-04-08 21:39:41 implementing my solution to verify cargo deps now 2017-04-08 21:39:43 :) 2017-04-08 21:41:13 how? 2017-04-08 21:41:46 I have a plan how to solve this generally for rust pkgs, but not implemented yet 2017-04-08 21:41:56 fetch() implementation which calls `cargo fetch` and tars up the result 2017-04-08 21:46:32 sounds good :) 2017-04-08 21:55:36 static binary is still huge af 2017-04-08 21:56:03 maybe it’s caused by stripping of rustc and libs? but that would be really weird… 2017-04-08 21:56:27 hmm 2017-04-08 21:58:50 are you sure that it’s not caused by jemalloc? 2017-04-08 22:00:59 i mean, i thought i was 2017-04-08 22:01:04 btw good news, the method works 2017-04-08 22:01:06 :) 2017-04-08 22:01:31 https://txt.shiz.me/MTgyNjc0YT 2017-04-08 22:03:41 that’s quite nasty 2017-04-08 22:04:04 but nice idea 2017-04-08 22:04:13 it's a tiny bit of added nasty because this has to use the bootstrap cargo 2017-04-08 22:04:45 the main issue i see is that it's kinda volatile... 2017-04-08 22:04:50 i don’t like that you have to unpack tarball yourself 2017-04-08 22:05:02 jirutka: we can always include the Cargo.toml separately 2017-04-08 22:05:06 as a separate distfile 2017-04-08 22:05:14 hm, true 2017-04-08 22:05:25 or even the cargo.lock 2017-04-08 22:05:28 thats a lot better in fact 2017-04-08 22:05:33 WDYT? https://github.com/alpinelinux/aports/pull/1222/commits/206fc4252cfe4d39109405d46501723d801a2407 2017-04-08 22:05:34 that way we remove the volatility 2017-04-08 22:06:33 i think we need more infra in abuild for this 2017-04-08 22:06:35 :p 2017-04-08 22:12:23 jirutka, Can you review https://github.com/alpinelinux/aports/pull/1223 please? 2017-04-08 22:13:11 jirutka: looks like we can't add Cargo.toml/lock ourselves 2017-04-08 22:13:16 it may rely on files within the source dir... 2017-04-08 22:19:49 leitao: done 2017-04-08 22:19:59 jirutka, thanks! 2017-04-08 22:20:48 I didn't want to push directly because of the checksum change. 2017-04-08 22:23:05 okay 2017-04-08 22:23:09 confirmed it works properly now 2017-04-08 22:23:42 it is somewhat nasty, sdaly 2017-04-08 22:30:12 jirutka: i'd put those tests in a separate shell script 2017-04-08 22:30:14 btw 2017-04-08 22:30:18 to make the apkbuild cleaner 2017-04-08 22:36:06 wtf is wrong with the rust tests 2017-04-08 22:36:34 it somehow randomly fails or what 2017-04-08 22:37:46 and also when I run abuild check and then rerun it again, it fails to run my custom tests b/c some .so lib does not exist o.O 2017-04-08 22:39:52 but it does not modify what is then installed, at least 2017-04-08 22:40:57 hm, maybe I should not run these custom tests on files from stage2? 2017-04-08 22:44:18 hm, when I build hello_world with unstripped rustc, it produces smaller binary (2.5 MiB instead of 4 MiB), but stripped size is same (358 kiB) 2017-04-08 22:44:30 o_O 2017-04-08 22:44:41 but IIRC it used to be really smaller 2017-04-08 22:44:43 stripped 2017-04-08 22:44:52 I’ll try without jemalloc 2017-04-08 23:00:35 >>> cargo-doc*: Preparing subpackage cargo-doc... 2017-04-08 23:00:37 >>> ERROR: cargo-doc*: Missing /home/builder/alpine-aports/testing/cargo/pkg/cargo-doc 2017-04-08 23:00:39 >>> ERROR: cargo-doc*: prepare_package failed 2017-04-08 23:00:41 que 2017-04-08 23:11:44 Okay, staging is working, but extracting the checksums from the apk with awk takes PAINFULLY long for the kernel/firmare/etc. 2017-04-08 23:14:54 Shiz: have I messed something? 2017-04-08 23:15:17 im unsure what would even CAUSE this error 2017-04-08 23:15:19 :P 2017-04-08 23:15:34 that there are no docs 2017-04-08 23:15:40 but there are 2017-04-08 23:15:49 hm 2017-04-08 23:15:52 aha, that’s cargo 2017-04-08 23:16:00 >cp /home/builder/alpine-aports/testing/cargo/src/cargo-0.17.0//src/etc/man/*.1 /home/builder/alpine-aports/testing/cargo/pkg/cargo/share/man/man1 2017-04-08 23:16:06 looks like docs to me 2017-04-08 23:16:08 :p 2017-04-08 23:26:02 jirutka: care to give this a shot? https://txt.shiz.me/MzU4ODFhMm 2017-04-08 23:26:37 Shiz: I care, ofc, but can’t now, I’m in middle of migrating and upgrading GitLab 2017-04-08 23:26:45 haha 2017-04-08 23:26:47 good luck 2017-04-09 00:21:42 Okay, so who do I have to know to edit my own issues in Redmine? 2017-04-09 00:24:20 I want to change the target version for Issue #7104 to 3.6. 2017-04-09 00:26:45 done 2017-04-09 00:27:21 jirutka: GitLab migration done? 2017-04-09 00:27:22 you can’t edit your own issues on Redmine; I don’t know if it’s Redmine’s limitation or just current setting, but I agree that it sucks 2017-04-09 00:27:55 jirutka: It can definitely be configured to allow it for logged in users, I've used it somewhat extensively for other projects in the past. 2017-04-09 00:28:09 clandmeter: ^ 2017-04-09 00:29:47 It's just a matter of setting the roles up and having the right permissisions assigned. 2017-04-09 00:35:21 Shiz: static stripped without jemalloc: 186 kiB, with jemalloc: 358 kiB 2017-04-09 00:35:27 right 2017-04-09 00:35:30 that makes some amount of sense 2017-04-09 00:35:33 what about unstripped? 2017-04-09 00:35:35 Shiz: => I’m gonna kill jemalloc with fire! :) 2017-04-09 00:35:44 ACTION shrugs 2017-04-09 00:35:45 Shiz: unstripped 2.2 MiB 2017-04-09 00:36:10 why it’s so bigger with jemalloc? 2017-04-09 00:36:16 because it embeds jemalloc 2017-04-09 00:36:17 :P 2017-04-09 00:36:19 I’m really not sure if it’s worth it 2017-04-09 00:36:24 probably not 2017-04-09 00:36:53 isn’t that just some mistake in configuration? 2017-04-09 00:37:05 or it really makes binary so bigger and we can’t do anything about it? 2017-04-09 00:38:13 it’d be probably useful if we can enable/disable jemalloc with some option for rustc 2017-04-09 00:38:35 btw Fedora disabled jemalloc too, but don’t know the reason 2017-04-09 00:39:18 tired, sleep, good night :) 2017-04-09 00:40:50 jirutka │ it’d be probably useful if we can enable/disable jemalloc with some option for rustc 2017-04-09 00:40:52 i... think you can 2017-04-09 00:41:38 FFS, they STILL haven't closed the feature request in the mainline of redmine? WTF? The patch has been there 7 years! 2017-04-09 00:58:38 kaniini : do you have know is there any reason why we should make the return value of update_config_sub as false (thus forcing fail with set -e), when there is no such config.sub file exists ? 2017-04-09 00:59:12 kaniini : I thought the idea is : do the ./config.sub command when it exists in the source code, if it doesn't just peacefully quit : https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n537 2017-04-09 00:59:12 that is why it should fail 2017-04-09 00:59:31 not every source package comes with config.sub 2017-04-09 00:59:36 only some come with 2017-04-09 01:01:53 so not having config.sub in the source code is a bad thing ? 2017-04-09 01:04:17 if we are calling update_config_sub it could be 2017-04-09 01:07:35 Okay I guess I just strip out update_config_sub in APKBUILD ... 2017-04-09 03:08:50 fcolista : Hi. It looks like v4l-utils is broken at dvbv5(). Would you mind give it a look ? 2017-04-09 03:09:21 fcolista : It failed for both s390x and x86_64 : http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/v4l-utils/v4l-utils-1.12.3-r0.log 2017-04-09 09:27:02 Shiz: how? :) 2017-04-09 14:07:25 jirutka: hmm? 2017-04-09 15:08:47 jirutka: oh 2017-04-09 15:51:30 <^7heo> is it normal that setup-bootable doesn't work with ext4 and vfat? 2017-04-09 15:51:43 <^7heo> (I'm currently trying ntfs but mkfs.ntfs takes AGES) 2017-04-09 17:41:24 ^7heo: I'd have to take a look at how setup-bootable works, but it didn't appear to have much flexability in terms of layout. 2017-04-09 17:46:38 ^7heo: I'm not sure what exactly it is intended to work reliably for, but at the end it looks like it's doing a blind copy of an mbr for syslinux to the device, so expect problems on anythin other than expected setup. 2017-04-09 17:49:14 ^7heo: How is it failing? 2017-04-09 18:07:09 curious what the new labels in github indicate 2017-04-09 18:08:34 also T-new doesn't appear to be in the list https://github.com/alpinelinux/aports/labels 2017-04-09 18:10:24 A = PR action 2017-04-09 18:10:38 C = category 2017-04-09 18:10:43 P = priority 2017-04-09 18:10:45 R = repository 2017-04-09 18:10:49 S = status 2017-04-09 18:11:21 T = testing? 2017-04-09 18:11:31 T is just... a special label right now 2017-04-09 18:11:42 not sure, ask jirutka 2017-04-09 18:12:02 <_ikke_> there is also R-Testing 2017-04-09 18:12:04 ah, k, was curious as T-new was added to my idris pr but not in the labels list https://github.com/alpinelinux/aports/pull/684 2017-04-09 18:12:20 not a big deal just trying to understand, thanks Shiz! 2017-04-09 18:12:22 mitchty: I’ve renamed T-new to A-add 2017-04-09 18:12:27 :) 2017-04-09 18:12:35 yeah it says A-add to the right now 2017-04-09 18:12:40 the github message below is just pre-label-rename 2017-04-09 18:12:58 cool beans 2017-04-09 18:13:02 there are currently no T-* labels 2017-04-09 18:13:05 looks very rust inspired 2017-04-09 18:13:12 mitchty: yes :) 2017-04-09 18:13:35 jirutka: there's T-security 2017-04-09 18:13:36 :p 2017-04-09 18:13:50 Shiz: ah, right 2017-04-09 18:19:00 also a note on ghc size, as everyone was wondering why, short answer, is ghc by default in effect builds 4 versions of itself, the default, which uses shared libraries for things, threaded, self explanatory, profiled, and the fourth (slightly hidden) is for the repl ghci, which basically is the same as profiled 2017-04-09 18:19:38 fixing it is... not a simple task, but that is the general why 2017-04-09 18:19:49 in effect you build 4 versions of ghc 2017-04-09 18:19:49 :p 2017-04-09 18:20:52 short answer to why its never been fixed: nobody has put in the effort, and its all volunteer, and the build system is 27 years old 2017-04-09 18:21:02 i might try if i get a bug up my butt 2017-04-09 18:25:17 a bug up the cloud? o.O 2017-04-09 18:25:44 no response from the rust guys yet :( 2017-04-09 19:35:55 Shiz: we have a problem with statically linked exec :/ fatal runtime error: failed to initiate panic, error 5 2017-04-09 19:36:45 that's an interesting one 2017-04-09 19:36:49 jirutka: we have more failures actually 2017-04-09 19:36:55 Shiz: simple test: fn main() { panic!("Whoaa!"); } 2017-04-09 19:36:58 i ran into a miscompiled cargo 2017-04-09 19:37:12 Shiz: it works when dynamically linked, but not statically 2017-04-09 19:37:21 Shiz: what do you mean with miscompiled? 2017-04-09 19:38:48 it's static PIE with DT_NEEDED entries 2017-04-09 19:38:55 <^7heo> TemptorSent: Don't remember don't care, it worked in the end. 2017-04-09 19:39:22 jirutka: btw that code is _URC_END_OF_STACK = 5, 2017-04-09 19:39:22 <^7heo> TemptorSent: just use vfat and reformat every time you use setup-bootable 2017-04-09 19:40:14 from _Unwind_RaiseException: Debug (1, "no handler found\n"); 2017-04-09 19:40:16 return _URC_END_OF_STACK; 2017-04-09 19:41:30 Shiz: have you compiled it with -C target-feature=-crt-static ? 2017-04-09 19:41:35 no... 2017-04-09 19:41:40 ;) 2017-04-09 19:41:47 i don't think you get the point 2017-04-09 19:41:57 probably not…? 2017-04-09 19:42:01 it's supposed be either a proper dynamic binary or a static PIE one 2017-04-09 19:42:04 i don't care either way 2017-04-09 19:42:06 but this is neither 2017-04-09 19:42:10 so it's a bug in rustc 2017-04-09 19:42:10 huh 2017-04-09 19:42:14 wtf 2017-04-09 19:42:27 :p 2017-04-09 19:42:39 jirutka: rustc passes the final deps as -l ... after -Wl,-Bdynamic 2017-04-09 19:42:42 which is the reason 2017-04-09 19:42:51 it shouldn't do that... 2017-04-09 19:43:54 jirutka: re: your own error... 2017-04-09 19:44:04 i suggest rolling your own libunwind with debug enabled and retrying 2017-04-09 19:46:58 Shiz: how do you identify that a binary is static PIE? currently I test if it contain NEEDED entries or INTERP, as you told me, if it does not contain these, then I assumed that it’s static 2017-04-09 19:47:06 that is correct 2017-04-09 19:47:13 and the PIE flag 2017-04-09 19:47:25 yes 2017-04-09 19:47:53 you said that you get “static PIE” with NEEDED entries… 2017-04-09 19:48:38 well 2017-04-09 19:48:44 static PIE *except* for the NEEDED entries 2017-04-09 19:48:46 :p 2017-04-09 19:49:17 then it’s not static… 2017-04-09 19:49:30 you know what i mean... 2017-04-09 19:49:39 actually I don’t :( 2017-04-09 19:49:59 how it’s different from “proper dynamic binary”? 2017-04-09 19:50:03 it has no INTERP 2017-04-09 19:50:09 and libc statically linked in 2017-04-09 19:50:12 aha, this is mandatory? 2017-04-09 19:50:17 yeah 2017-04-09 19:50:18 INTERP? 2017-04-09 19:50:22 hmm… should fix my test 2017-04-09 19:50:25 interp points to the dynamic loader 2017-04-09 19:50:30 /lib/ld-musl-$(arch).so.1 2017-04-09 19:50:32 :) 2017-04-09 19:50:59 cargo tests when compiled dynamically: https://hastebin.com/nevulocejo 2017-04-09 19:51:34 nice 2017-04-09 19:52:31 btw interesting thing: when I compiled tests statically (actually by accident), then the test was killed by grsec… when I paxmarked it, then it segfaulted 2017-04-09 19:54:27 it segfaulted in both cases for me 2017-04-09 19:54:29 no need for paxmark 2017-04-09 20:28:51 oh crap, there are two libunwind projects… from GNU and from LLVM 2017-04-09 20:31:07 :p 2017-04-09 20:31:13 the other one is not gnu 2017-04-09 20:31:13 i think they are api compatible 2017-04-09 20:31:37 kaniini: what is the difference between them? 2017-04-09 20:31:39 https://github.com/libunwind/libunwind/blob/master/AUTHORS 2017-04-09 20:31:41 ;p 2017-04-09 20:32:02 I don’t know this guy, should I? 2017-04-09 20:32:04 one is BSD licensed and depends on kk men 2017-04-09 20:32:07 er 2017-04-09 20:32:07 no, but he's not gnu 2017-04-09 20:32:09 llvm 2017-04-09 20:32:15 stupid autocorrect 2017-04-09 20:32:27 the other libunwind is MIT 2017-04-09 20:32:28 :P 2017-04-09 20:32:37 yeah so 2017-04-09 20:32:41 >Copyright (c) 2002 Hewlett-Packard Co 2017-04-09 20:32:41 idk 2017-04-09 20:32:43 well, rustc apparently doesn’t work with our libunwind, so should I try to enable some more flags to our libunwind or just add llvm-libunwind? 2017-04-09 20:32:43 ;p 2017-04-09 20:32:52 i think you should just debug it first 2017-04-09 20:33:01 they do the same thing 2017-04-09 20:33:02 compile libunwind in debug mode 2017-04-09 20:33:04 :P 2017-04-09 20:33:06 one just uses llvm to do it 2017-04-09 20:33:23 and rustc uses LLVM to compile code… so? 2017-04-09 20:33:27 the llvm one is probably better but it depends on llvm 2017-04-09 20:34:09 Shiz: I don’t have much experience with debugging C stuff :/ 2017-04-09 20:35:06 jirutka: in debug mode it will print messages to stdout... 2017-04-09 20:35:09 that's the nice part 2017-04-09 20:35:11 :p 2017-04-09 20:37:02 Shiz: what about these additional flags? https://hastebin.com/raw/ibewojutoc 2017-04-09 20:37:45 just --enable-debug should be fine 2017-04-09 20:37:56 also when I run libunwind tests, some of them fails… but at least some of them clearly tests disabled features 2017-04-09 20:39:49 hm, no, the docs are probably wrong, b/c it currently builds even coredump, ptrace,etc. 2017-04-09 20:40:27 but it’s also quite possible that some tests fail due to grsec or that I run it in restricted lxc container 2017-04-09 20:40:28 jirutka: meanwhile i'm writing a decoder for rustc's metadata format to try to see what's going on 2017-04-09 20:40:30 :p 2017-04-09 20:40:40 you’re doing WHAT?! 2017-04-09 20:40:45 https://txt.shiz.me/OTY1MDQzMT 2017-04-09 20:40:58 O.O 2017-04-09 20:41:41 it's pretty easy luckily 2017-04-09 20:41:49 i've written my own binary decoder library before 2017-04-09 20:41:57 so it's mostly declarative structure definitions 2017-04-09 20:46:47 okay :) this is too low-level for me :) 2017-04-09 20:48:15 https://txt.shiz.me/M2E0ODIyZT 2017-04-09 20:48:16 ;) 2017-04-09 20:53:01 ^7heo: That sounds about right :P I'm not sure I even want to get into that. 2017-04-09 21:35:03 Shiz: I’ve built unstripped rust with unstripped libunwind, but https://hastebin.com/raw/daxezobane 2017-04-09 21:35:36 built libunwind with --enable-debug? 2017-04-09 21:35:47 Shiz: there’s strace https://hastebin.com/utokubupeb 2017-04-09 21:35:49 Shiz: yes 2017-04-09 21:37:06 oh jeez 2017-04-09 21:37:09 it has an additional layer 2017-04-09 21:38:07 jirutka: right 2017-04-09 21:38:09 jirutka: run with 2017-04-09 21:38:15 UNW_DEBUG_LEVEL=100 2017-04-09 21:38:19 in env 2017-04-09 21:39:36 https://hastebin.com/raw/qeyuhidiyu 2017-04-09 21:40:36 see, isn't that far more useful 2017-04-09 21:41:00 you’re joking now, right? XD 2017-04-09 21:41:18 well, it is 2017-04-09 21:41:25 just not to have the relevant people read it 2017-04-09 21:41:29 maybe dalias cna help you there 2017-04-09 21:41:31 :P 2017-04-09 21:41:56 you can’t read it? 2017-04-09 21:42:25 not well enough to be able to deal with it while doing the other stuff i'm doing right now 2017-04-09 21:42:27 :p 2017-04-09 21:42:45 to me it looks like the cursor it's given is wrongi n the first place 2017-04-09 21:42:51 0x3afa3d81068 seems like a weird addr 2017-04-09 21:43:27 I see a lot of weird stuff, right under "stack backtrace:" till the EOF :P 2017-04-09 21:44:31 i think the #musl peeps can help you with this :) 2017-04-09 21:45:19 nah, I’m trying to build rustc against llvm-libunwind now :) 2017-04-09 21:48:35 i dont think it will help 2017-04-09 21:49:56 kaniini: hmm, why? 2017-04-09 21:50:31 libunwind and the llvm one implements the same API and should have the same behaviour 2017-04-09 21:50:44 also, if libunwind is being invoked to begin with, it means the failure has already occured 2017-04-09 21:50:47 there’s no such problem when you compile statically linked binary with musl on gnu system, so why it happens on native musl? 2017-04-09 21:50:59 I’ve panicked it intentionally 2017-04-09 21:51:02 to test unwind 2017-04-09 21:51:08 ah 2017-04-09 21:51:21 is the statically linked binary with musl static-PIE? 2017-04-09 21:51:29 because on native it would be 2017-04-09 21:51:36 this smells of a PIE issue 2017-04-09 21:51:40 ahaa 2017-04-09 21:51:44 yeah, this is different 2017-04-09 21:51:50 I’ve almost forgot about it 2017-04-09 21:58:58 also llvm-libunwind does not build on aarch64 :P 2017-04-09 22:01:28 kaniini: I’m working on it now 2017-04-09 22:02:37 kaniini: it’d be really helpful if other builds will not be stuck again :( 2017-04-09 22:02:58 kaniini: I don’t know if it’s gonna work on x86 and armhf 2017-04-09 22:03:24 x86 is MIA 2017-04-09 22:03:28 kaniini: aah, x86 builder is gone 2017-04-09 22:04:08 yes, i think need to poke ncopa about that cause he maintains it iirc 2017-04-09 22:04:09 oh crap, I forgot to recompute checksum :( 2017-04-09 22:04:45 aha, no, forgot to actually add the patch 2017-04-09 22:05:17 i need to write some checking script for this, it’s quite embarrasing mistake 2017-04-09 22:06:43 yeah, it works! 2017-04-09 22:06:55 i mean, lua-libunwind on aarch64 2017-04-09 22:07:09 rustc still building >_< 2017-04-09 22:08:45 https://txt.shiz.me/NGEzNTUxMW 2017-04-09 22:08:48 progress 2017-04-09 22:08:49 :p 2017-04-09 22:09:21 what’s that? :) 2017-04-09 22:10:06 partial decoding of rust's metadata files 2017-04-09 22:10:21 from rust binaries? 2017-04-09 22:10:39 from .rlib files yeah 2017-04-09 22:10:46 aha 2017-04-09 22:15:52 hm, okay, you were right 2017-04-09 22:16:00 *but* it does not behave identically 2017-04-09 22:16:15 but still segfaults 2017-04-09 22:45:06 :p 2017-04-09 23:01:09 Shiz: without your static-pie.patch rustc produces binary dynamically linked against libc >_< 2017-04-09 23:01:25 yep 2017-04-09 23:01:28 (and it does not segfault) 2017-04-09 23:01:35 that patch includes stuff to make static work in the first place 2017-04-09 23:01:37 for musl 2017-04-09 23:01:50 I see 2017-04-09 23:02:10 mostly the addition of the -static flag to the command line 2017-04-09 23:02:14 what is -MT ? 2017-04-09 23:02:22 msvc's -static equivalent 2017-04-09 23:02:28 aha 2017-04-09 23:02:39 jirutka: you can try patching linux_musl_base.rs to disable PIE 2017-04-09 23:02:46 and see what it does 2017-04-09 23:02:47 how the heck it works on gnu with musl target? 2017-04-09 23:02:51 barely. 2017-04-09 23:03:00 barely? 2017-04-09 23:05:48 Shiz: so this http://tpaste.us/je1o ? 2017-04-09 23:06:14 yeah 2017-04-09 23:06:28 and then re-add target.position_independent_executables = false; 2017-04-09 23:06:31 to linux_musl_base.rs 2017-04-09 23:06:42 or 2017-04-09 23:07:06 no nvm 2017-04-09 23:07:10 that's not necessary 2017-04-09 23:07:37 actually, it may be anyway 2017-04-09 23:07:39 do it to be sure 2017-04-09 23:28:44 jirutka: https://txt.shiz.me/M2MyMTE2MW 2017-04-09 23:28:46 :) 2017-04-09 23:29:28 nice :) 2017-04-09 23:29:36 but how is this gonna help you? 2017-04-09 23:36:58 gonna figure out how it encodes the native library dependencies 2017-04-09 23:37:16 rust's metadata system is how it passes the native library deps of the crate dependencies to the final linker 2017-04-09 23:43:26 Shiz: shit, you were right, I haven’t re-added that stuff, b/c I’ve already started compiling, and it still builds dyn PIE 2017-04-09 23:43:39 need to go sleep now 2017-04-09 23:43:44 :) g'night 2017-04-10 01:01:26 Shiz: I’m idiot… I forgot to replace certs and remember that before bad… and after that I checked recompiled rustc and realized that I forgot to add the modified patch to sources… 2017-04-10 01:01:43 hehe 2017-04-10 04:43:10 Looking for input on why keys for arch x86_64 come up with aarch64 package signatures being untrusted. 2017-04-10 04:45:59 I'm a bit stuck until I can figure that out as far as cross-arch building. 2017-04-10 05:09:47 because the keys are different 2017-04-10 05:09:53 https://git.alpinelinux.org/cgit/aports/tree/main/alpine-keys/APKBUILD 2017-04-10 05:20:28 Is there a way to fetch the keys for the other archs from the host arch using some trusted key? 2017-04-10 05:22:04 Or do we have to install the keys package first, thus play chicken-and-egg? 2017-04-10 05:35:35 (grumbles or, option C, yet another disgusting hack of dumping it through tar and only extracting the /usr/share/apk directory BEFORE setting the target arch 2017-04-10 05:41:30 all keys are in /usr/share/apk 2017-04-10 05:41:39 even for the other arches 2017-04-10 05:41:55 just copy from /usr/share/apk/keys/targetarch 2017-04-10 05:47:48 <^7heo> moin Shiz 2017-04-10 05:47:54 <^7heo> Shiz: do you ever sleep? ;) 2017-04-10 05:48:01 no 2017-04-10 05:48:25 <^7heo> I thought one would have problems doing that. 2017-04-10 05:49:09 well you've seen Shiz, now you understand why he's that way 2017-04-10 05:49:22 Shiz: Yeah, I was trying to maintain encapsulation a bit better than that. 2017-04-10 05:50:17 skarnet: i take insult to this 2017-04-10 05:50:27 it was a joke! 2017-04-10 05:50:35 TemptorSent: the key package is always installed on the host, so... 2017-04-10 05:51:03 (you'd know a joke from an insult if you had slept) 2017-04-10 05:51:34 Shiz: Yeah, supposing the host is alpine of course. 2017-04-10 05:52:18 i don't think that's an unfair assumption, considering you're likely also invoking apk 2017-04-10 05:52:32 I'm trying to take as little for granted as I can about exactly what the host is. 2017-04-10 05:52:46 if you have apk, you have alpine-keys 2017-04-10 05:52:53 apk.static... 2017-04-10 05:53:41 Anyway, I have a work around I think... and it makes sure I'm using the latest keys. 2017-04-10 05:54:11 don't make things more difficult than they need to be 2017-04-10 05:54:48 For a somewhat general-purpose tool, I'm not going to make too many assumptions. 2017-04-10 05:55:24 apk may be abuild-apk or apk.static just as easily as /sbin/apk. 2017-04-10 05:57:42 i5t's not general purpose though 2017-04-10 05:58:19 So we must be hosted on alpine to build alpine components? 2017-04-10 05:59:30 i think that is a fair assumption, yes 2017-04-10 05:59:53 if you just want to rely on apk being available, install alpine-keys yourself 2017-04-10 06:00:36 Yeah, that's what I'm doing basically, but only the part that isn't for the wrong arch, then I fetch the one for the right arch. 2017-04-10 06:01:14 you don't really need to do the latter if you can just copy the keys over 2017-04-10 06:01:55 Right, I mean I fetch it out of the directory 2017-04-10 06:02:42 cp -L "$staging_apkroot/usr/share/apk/keys"/* "$staging_apkroot/etc/apk/keys" 2017-04-10 06:02:48 don't do that 2017-04-10 06:02:56 at least use the proper arch subdirectory 2017-04-10 06:03:06 now you're copyingg a bunch of stuff in the staging keydir that is not relevant to it 2017-04-10 06:03:15 er, oops - yes, arch is actually in my command. 2017-04-10 06:03:39 That's what I get for typing without looking at it. 2017-04-10 06:06:28 Anyway, much bigger issue is breakage related to the spurious warning ending up in my kernel verion when querying "WARNING: Ignoring /home/chrisgio/packages/testing/aarch64/APKINDEX.tar.gz" when I have not aarch64 repo at all in my personal directory, but do have x86_64. 2017-04-10 06:06:48 fabled: Any thoughts ^^^ 2017-04-10 06:07:18 I can't shut it up either with -q 2017-04-10 06:09:26 And somehow I don't think having a sed hack to remove my own personal repo from the repos file is going to be a good call ;) 2017-04-10 06:16:25 <^7heo> does anyone here know what packages are needed for zfs to work? 2017-04-10 06:16:46 <^7heo> zfs, zfs-libs and zfs-utils-py I suppose? 2017-04-10 06:17:09 <^7heo> maybe zfs-grsec too? 2017-04-10 06:21:05 TemptorSent: redirect 2>/dev/null ? 2017-04-10 06:21:38 ^7heo: You need zfs-grsec, spl-grsec, and zfs 2017-04-10 06:22:15 TemptorSent: also, apk --repositories-file= exists 2017-04-10 06:22:17 :p 2017-04-10 06:22:18 Shiz: Not really a great solution, because then actual errors get burried. 2017-04-10 06:24:05 <^7heo> TemptorSent: but I guess those will pull other stuff, like zfs-libs? 2017-04-10 06:24:06 Shiz: The problem is that my repositories file has my local repo in it (as I suspect many users do), but I don't happen to have ANY aarch64 directory, let alone packages there. Rather than throwing a warning, it should show a message 'no index for arch '$arch' in repo '$repo', ignoring... displayed with verbose. 2017-04-10 06:24:21 i think a warning is perfectly valid 2017-04-10 06:24:26 you gave it a repo, that repo doesn't exist 2017-04-10 06:24:31 plenty of reason for a warning 2017-04-10 06:24:32 ^7heo: Yes, the rest SHOULD follow. 2017-04-10 06:25:03 <^7heo> TemptorSent: I'm asking because I'm attempting to copy the right packages in the default install distrib 2017-04-10 06:25:16 Shiz: Okay, great - let's break everything in unexpected ways because we only have packages for x86_64 in our custom repo at the moment. 2017-04-10 06:25:19 <^7heo> so... any way to see the dependency graph with APK 2017-04-10 06:25:21 <^7heo> ? 2017-04-10 06:25:27 not apk's fault you gave it a repo that doesn't exist... 2017-04-10 06:25:42 i don't understand why you're invoking apk without the proper --root anyway 2017-04-10 06:26:06 So if a repo happens to be down at the moment, we want to have things fail strangely rather than just skip it? 2017-04-10 06:26:08 <^7heo> Shiz: you're answering TemptorSent right? 2017-04-10 06:26:12 yes 2017-04-10 06:26:26 <^7heo> to both questions? 2017-04-10 06:26:32 yes 2017-04-10 06:26:38 <^7heo> danke 2017-04-10 06:26:39 yes 2017-04-10 06:26:40 ( ≖‿≖) 2017-04-10 06:26:46 TemptorSent: nothing fails, it gives you a warning 2017-04-10 06:26:48 on stderr 2017-04-10 06:26:53 literally the best possible thing it can do 2017-04-10 06:27:00 i don't understand how it fucks up your kernel version request 2017-04-10 06:27:08 <^7heo> "nothing fails, it gives you a warning" 2017-04-10 06:27:09 ^7heo: # apk dot btw 2017-04-10 06:27:10 <^7heo> wait wat? 2017-04-10 06:27:19 ^7heo: failure is fatal 2017-04-10 06:27:25 this is not a failure, it's a warning 2017-04-10 06:27:34 ^7heo: You can see the depends by doing 'apk fetch --simulate --recursive zfs zfs-grsec spl-grsec 2017-04-10 06:27:36 <^7heo> ah no fail as in 'no fatal' 2017-04-10 06:27:56 <^7heo> TemptorSent: yeah maybe better than having to read the dot graph. 2017-04-10 06:27:59 <^7heo> thanks 2017-04-10 06:28:02 TemptorSent: speaking of overthinking 2017-04-10 06:28:09 how about # apk info -R zfs zfs-grsec spl-grsec 2017-04-10 06:28:11 :P 2017-04-10 06:28:35 Shiz: Every script that uses the output from 'apk search' directly goes straight to hell. 2017-04-10 06:28:43 this is apk info 2017-04-10 06:28:45 not apk search 2017-04-10 06:28:48 and nobody said anything about sripts 2017-04-10 06:29:23 Shiz: the warning from APK is what's breaking my scripts, as well as severeral existing scripts. 2017-04-10 06:29:55 Shiz: apk info only works if you have the packages installed IIRC 2017-04-10 06:30:09 i think i said something a while ago about not highlighting me in rapid succession 2017-04-10 06:30:11 and no, it does not 2017-04-10 06:30:36 https://txt.shiz.me/NTkyZTJhND 2017-04-10 06:30:38 <^7heo> guys, the MBR is supposed to be 512 bytes right? 2017-04-10 06:30:47 448 bytes 2017-04-10 06:30:56 <^7heo> yeah so less than 512 2017-04-10 06:31:06 <^7heo> how come I have stuff after it? 2017-04-10 06:31:11 <^7heo> syslinux? 2017-04-10 06:31:15 the partition table 2017-04-10 06:31:26 <^7heo> isn't the mbr including the partition table? 2017-04-10 06:31:35 <^7heo> well, obviously not but... 2017-04-10 06:31:37 <^7heo> I thought it was. 2017-04-10 06:32:14 ^7heo: https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout 2017-04-10 06:32:16 :) 2017-04-10 06:32:41 <^7heo> damn doc, all the things are on the web... 2017-04-10 06:32:54 <^7heo> I wish I could just fetch a CLI friendly and readable version... 2017-04-10 06:33:09 links exists 2017-04-10 06:33:10 <^7heo> thanks 2017-04-10 06:33:16 <^7heo> ? 2017-04-10 06:33:23 i mean links(1) 2017-04-10 06:33:26 :p 2017-04-10 06:33:42 <^7heo> ah 2017-04-10 06:33:59 <^7heo> yeah no not a fan of adding problems to my problems in order to not see the original problem. 2017-04-10 06:34:06 TemptorSent: i see your point in that it's not printing to stderr 2017-04-10 06:34:07 it should do that 2017-04-10 06:34:29 Yeah, like I said, it behaves badly. 2017-04-10 06:34:50 <^7heo> it could be worse. 2017-04-10 06:34:56 <^7heo> it could behave badly AND be orange. 2017-04-10 06:35:05 *LOL* 2017-04-10 06:35:53 ah 2017-04-10 06:35:54 <^7heo> (and waste most of its time playing golf) 2017-04-10 06:35:57 looks like it's relatively easy to fix 2017-04-10 06:35:58 Anyway, turns out the warning was masking the REAL problem, namely that I'm not getting a result. 2017-04-10 06:36:08 TemptorSent: btw 2017-04-10 06:36:14 -q should prevent it, i think 2017-04-10 06:37:12 Yeah, but turns of warnings I want to see as well. I'll have to go insert it strategically in a few places because I can't just drop it in my _apk wrapper for apk without breaking things I want warnings for. 2017-04-10 06:37:33 ¯\_(ツ)_/¯ 2017-04-10 06:37:44 Basically, I want warnings for anything BUT that. 2017-04-10 06:37:52 And, preferably, to stderr :) 2017-04-10 06:37:54 i think that's a silly request 2017-04-10 06:37:58 to stderr can be done, however 2017-04-10 06:40:23 Warning that a particular repo doesn't have your arch seems a bit different than warning that a signature is unverified. 2017-04-10 06:40:50 not really 2017-04-10 06:40:58 they both just mean the repo is unavailable 2017-04-10 06:41:52 One of them is essentially a normal condition for anyone who works on multiple archs and uses the same repo list, the latter indicates a misconfiguration in-fact. 2017-04-10 06:42:25 both are misconfigurations 2017-04-10 06:42:44 But a query - is taking the return value of a variable assignment containing a command substitution POSIXly correct? 2017-04-10 06:43:25 I'd argue that my repos file isn't misconfigured, I just haven't cross-built anything to aarch64 yet. 2017-04-10 06:43:34 it's fine to not have packages 2017-04-10 06:43:38 it's not fine to not have an index 2017-04-10 06:43:40 Once I do, it will magically work. 2017-04-10 06:43:55 also, needs example 2017-04-10 06:44:06 It doesn't even have a directory, so it's the same as a repo that has the host down. 2017-04-10 06:44:18 which is also bad 2017-04-10 06:44:20 anyway 2017-04-10 06:44:22 https://txt.shiz.me/MWE2YjE2Zj 2017-04-10 06:44:22 It should silently fail to the next one, unless it was pinned. 2017-04-10 06:44:24 here's your apk patch 2017-04-10 06:44:28 definitely not 2017-04-10 06:44:33 it should definitely not silently fail 2017-04-10 06:44:52 So we shouldn't allow repos to cascade cleanly? 2017-04-10 06:45:03 it does cascade cleanly 2017-04-10 06:45:05 it just warns you about it 2017-04-10 06:45:06 I thought that was the whole point of CDNs 2017-04-10 06:45:08 why is this so hard 2017-04-10 06:45:18 CDNs operate on the same single domain or even IP 2017-04-10 06:45:21 so this has nothing to do with CDNs 2017-04-10 06:45:34 Because warnings on a normal occurence break things. 2017-04-10 06:45:55 https://txt.shiz.me/M2I2OTc0ZW 2017-04-10 06:45:58 And yes, a set of mirrors is a CDN, if not the typical usage of the term these days. 2017-04-10 06:45:58 botched some whitespace 2017-04-10 06:46:04 wrong 2017-04-10 06:46:31 anyway, with this patch it doesn't break things anymore 2017-04-10 06:46:42 feel free to forward it to ncopa/fabled 2017-04-10 06:46:44 :p 2017-04-10 06:47:04 Thank you! 2017-04-10 06:47:11 i think that whitespace is still botched thanks to my terminal... 2017-04-10 06:47:16 i'll just upload the git-format-patch 2017-04-10 06:47:37 That would probably be ideal :) 2017-04-10 06:48:22 https://up.shiz.me/priv/0001-print-print-warnings-and-errors-to-stderr.patch 2017-04-10 06:48:24 there 2017-04-10 06:49:35 That cleans it up nicely, and appears to allow use of an alternate FD with a little work, thanks. 2017-04-10 06:52:22 Let's see if I can not botch the bug report :) 2017-04-10 06:56:41 fabled, please see Issue #7107 - patch by Shiz. 2017-04-10 06:57:48 Shiz: Anyway, regarding checking the return value of a variable assignement containing a command substitution, are you aware of anything non-posix about such a usage? 2017-04-10 07:05:23 Shiz: So, get this -- I CAN'T use the -q flag with 'apk search -x' because it gives me a different result, namely, just the package name and not the version! 2017-04-10 07:07:27 Which, unfortunately, is going go break all sorts of other things if I try to run with a global quiet flag. 2017-04-10 07:12:28 Perhaps a '--no-warn' option? 2017-04-10 07:21:51 does "install="$pkgname.pre-install"" gets executed even if i install a meta package? 2017-04-10 07:23:54 xsteadfastx: i see no reason why not from the top of my head 2017-04-10 07:24:03 meta-packages aren't actually anything special for apk 2017-04-10 07:33:31 ok... what can i do to test a open-rc init script? 2017-04-10 07:34:07 run it 2017-04-10 07:35:23 Shiz, did you guys get rust going? 2017-04-10 07:35:48 clandmeter: the basics work, weeding out issues now 2017-04-10 07:36:25 clandmeter: it gives me "* WARNING: snapcast-server is already starting" and nothing happens" 2017-04-10 07:36:38 is it running? 2017-04-10 07:36:42 if not zap it 2017-04-10 07:37:28 its not doing anything 2017-04-10 07:37:40 i tried to start it in my devel docker container 2017-04-10 07:37:45 i installed openrc 2017-04-10 07:37:54 huh? 2017-04-10 07:38:00 are you running it on docker? 2017-04-10 07:38:00 openrc doesn't run in docker 2017-04-10 07:38:32 xsteadfastx: you normally dont run the init.d script in docker 2017-04-10 07:39:51 ok i try to run start-stop-daemon command itself... and it has a problem with "--exec" 2017-04-10 07:40:03 if i do a "start-stop-daemon -S snapserver" it runs 2017-04-10 07:40:16 "start-stop-daemon -S -x snapserver" not 2017-04-10 07:40:55 you do not have a regular alpine env? 2017-04-10 07:41:04 no 2017-04-10 07:41:07 :( 2017-04-10 07:41:25 if the openrc script invokes start-stop-daemon, it's likely not a very good openrc script 2017-04-10 07:41:27 just a side-note 2017-04-10 07:41:36 xsteadfastx: --exec takes an absolute path 2017-04-10 07:41:49 yes, you dont need to use those in your initd 2017-04-10 07:41:50 not a binary name 2017-04-10 07:42:02 openrc takes care of that. 2017-04-10 07:42:28 Shiz: not? what else to do? 2017-04-10 07:42:37 man openrc-run 2017-04-10 07:42:44 command=/usr/bin/mycommand 2017-04-10 07:42:47 command_args=... 2017-04-10 07:42:50 command_background=yes 2017-04-10 07:42:57 pidfile=/run/$RC_SVCNAME.pid 2017-04-10 07:43:09 that should be the full contents of your initd file (with the #!/sbin/openrc-run hashbang) 2017-04-10 07:43:18 with command_args filled in to have it run in the foreground 2017-04-10 07:43:23 openrc will take care of everything 2017-04-10 07:43:45 xsteadfastx, instead of docker you can also try lxc 2017-04-10 07:43:58 which would make a beter env to test things like that. 2017-04-10 07:44:25 mh ok... 2017-04-10 07:44:33 looks like snapserver runs in the foreground by default, so command_args= can be empty or even better, command_args="$SNAPCAST_SERVER_OPTS" 2017-04-10 07:44:39 so people can override/add options in /etc/conf.d 2017-04-10 07:45:16 right now i add a default config file 2017-04-10 07:45:17 or filled with the other options you'd normally pass it (without -d) and then $SNAPCAST_SERVER_OPTS 2017-04-10 07:46:06 and if it logs to console you can redirect it to log file(s) with start-stop-daemon options 2017-04-10 07:46:38 there is so much... i think my head explodes ;-) 2017-04-10 07:47:09 its actually not that hard ones you have done it :) 2017-04-10 07:47:34 and the man pages has a good example(s) 2017-04-10 07:48:04 https://git.alpinelinux.org/cgit/aports/tree/main/opensmtpd/smtpd.initd 2017-04-10 07:48:06 see this example :) 2017-04-10 07:48:29 (totally not written by yours truly) 2017-04-10 07:49:08 and skip the mta line :) 2017-04-10 07:49:27 well, rewrite depends() as is fit, of course 2017-04-10 07:50:54 start-stop-daemon tells me that --stdout and -stderr or only working when using --background 2017-04-10 07:51:13 command_background=yes 2017-04-10 07:51:24 that should add it automagically 2017-04-10 07:51:26 see the lines i pasted above :P 2017-04-10 07:51:34 the opensmtp examples lookgs great 2017-04-10 07:51:36 but 2017-04-10 07:51:51 and read the man page :p 2017-04-10 07:52:03 snapserver doesnt have a config option or sometrhing 2017-04-10 07:52:06 dont scroll it, read it! ;-) 2017-04-10 07:52:14 stuff needs to be sourced from a file 2017-04-10 07:52:31 xsteadfastx: right, and? 2017-04-10 07:52:36 that sets some environemtn variables snapserver reads 2017-04-10 07:52:46 start_pre() { 2017-04-10 07:52:54 . someconfigfile 2017-04-10 07:52:56 } 2017-04-10 07:53:03 ok 2017-04-10 07:53:18 again, man openrc-run is your friend 2017-04-10 07:53:19 :) 2017-04-10 07:53:34 start-stop-daemon also support env variables. 2017-04-10 07:55:02 yeah sorry for my questions. i never really did some serious packaging. i know its pretty straight forward but sometimes i make things hard for myself 2017-04-10 07:56:33 its fine, we will start to shout or stay silent when we have enough of you. 2017-04-10 07:59:38 <^7heo> guys 2017-04-10 08:00:03 <^7heo> is the content of /usr/share/syslinux/mbr.bin the only payload that is written to disk to install mbr? 2017-04-10 08:00:22 yes 2017-04-10 08:00:30 at least 2017-04-10 08:00:33 the mbr part 2017-04-10 08:00:39 extlinux writes a vbr too 2017-04-10 08:01:16 You'll also need to run syslinux against it I believe, or something which fixes up devnames 2017-04-10 08:01:47 <^7heo> TemptorSent: I'm not interested in knowing how the /boot works, but what is the layout on disk. 2017-04-10 08:02:08 Read install-bootable, it does a bit of twiddling with UUID, but I'm not sure if it's actually baked in. 2017-04-10 08:02:30 <^7heo> you mean setup-bootable? 2017-04-10 08:02:51 er, yeah -- getting tired :) 2017-04-10 08:03:43 <^7heo> what I don't get is: 2017-04-10 08:03:45 syslinux wants access to an unmounted device, which implies it's twiddling bits. 2017-04-10 08:04:11 <^7heo> I have bytes in the middle of that mbr.bin 2017-04-10 08:04:33 <^7heo> I mean, on disk, the mbr.bin is split in parts with seemingly unrelated bytes in the middle. 2017-04-10 08:04:51 Hmm, lemme look at my with xdd 2017-04-10 08:05:00 er xxd 2017-04-10 08:05:16 <^7heo> what I'm comparing: 2017-04-10 08:05:24 <^7heo> $ xxd /usr/share/syslinux/mbr.bin 2017-04-10 08:05:25 <^7heo> and 2017-04-10 08:05:54 <^7heo> $ sudo dd if=/dev/sda ibs=440 count=1 2>/dev/null | 2017-04-10 08:05:55 <^7heo> xxd 2017-04-10 08:06:51 Hmm, I think you're missing an offset... 2017-04-10 08:07:02 no 2017-04-10 08:07:26 <^7heo> no it's that. 2017-04-10 08:07:33 Should be 446 2017-04-10 08:07:36 no 2017-04-10 08:07:38 it should be 440 2017-04-10 08:07:44 ^7heo: they don't differ at all on my machine 2017-04-10 08:07:50 <^7heo> they do here... 2017-04-10 08:07:52 immunity:~# dd if=/dev/vda of=mbr.bin bs=440 count=1 2017-04-10 08:07:54 1+0 records in 2017-04-10 08:07:56 1+0 records out 2017-04-10 08:07:58 Hmm, spec says 446 2017-04-10 08:07:58 immunity:~# diff mbr.bin /usr/share/syslinux/mbr.bin 2017-04-10 08:08:00 immunity:~# 2017-04-10 08:08:04 <^7heo> damn 2017-04-10 08:08:09 TemptorSent: no, spec says the partition table starts at offset 446 2017-04-10 08:08:11 :P 2017-04-10 08:08:35 <^7heo> Shiz: lemme paste my xxd output to show you what I got. 2017-04-10 08:09:00 <^7heo> http://ix.io/qbp 2017-04-10 08:09:06 <^7heo> my on-disk mbr 2017-04-10 08:09:23 Okay, point Shiz - AVAILABLE space for code prior to partition table is 446 bytes, any of which that are unused should be 0. 2017-04-10 08:09:26 <^7heo> my mbr.bin: http://ix.io/qbq 2017-04-10 08:09:50 <^7heo> as you can see, they differ, greatly. 2017-04-10 08:10:00 Whats your disk's UUID? 2017-04-10 08:10:10 ^7heo: are you sure you don't have gptmbr.bin? 2017-04-10 08:10:29 <^7heo> no I'm not. 2017-04-10 08:10:33 <^7heo> but I shouldn't have that. 2017-04-10 08:10:48 or mbr_c mbr_f ? 2017-04-10 08:10:55 <^7heo> what are those btw? 2017-04-10 08:11:18 ^7heo: that is not the syslinux mbr 2017-04-10 08:11:20 i can tell you that 2017-04-10 08:11:22 :p 2017-04-10 08:11:32 No, not in any of those versions. 2017-04-10 08:11:47 Alternate mbr it appears, see /usr/share/syslinux 2017-04-10 08:12:07 it's not that 2017-04-10 08:12:10 it looks like a windows mbr... 2017-04-10 08:12:20 Wait a sec, any chance it eltorito from xorriso? 2017-04-10 08:12:33 with the compat header? 2017-04-10 08:12:38 these are windows mbr error messages, ^7heo 2017-04-10 08:12:41 https://technet.microsoft.com/en-us/library/cc977213.aspx 2017-04-10 08:12:43 see here 2017-04-10 08:13:36 TemptorSent: it's not any MBR that belongs to syslinux 2017-04-10 08:13:40 <^7heo> Shiz: ah 2017-04-10 08:13:44 <^7heo> Shiz: well, to be fair... 2017-04-10 08:14:00 <^7heo> Shiz: I have installed alpine first and windows second... 2017-04-10 08:14:04 there you go 2017-04-10 08:14:06 <^7heo> Shiz: so... it might be ;) 2017-04-10 08:14:09 windows always overwrites the mbr 2017-04-10 08:14:10 :P 2017-04-10 08:14:27 <^7heo> Shiz: thanks for making sense of my stuff. 2017-04-10 08:14:59 <^7heo> but if I overwrite the mbr with the syslinux one, won't I lose my partitions if I write after 440? 2017-04-10 08:15:06 yes, so don't write after 440 2017-04-10 08:15:19 the syslinux mbr.bin is only 440 bytes long in the first place 2017-04-10 08:15:19 <^7heo> :D 2017-04-10 08:15:23 <^7heo> yeah 2017-04-10 08:15:28 <^7heo> nah but all makes sense now. 2017-04-10 08:15:39 <^7heo> so fdisk would only write from 446 to 512? 2017-04-10 08:16:29 on mbr systems at least, yes 2017-04-10 08:16:32 and to 510 2017-04-10 08:16:37 511 512 is the boot signature 2017-04-10 08:16:39 0xAA55 2017-04-10 08:16:40 <^7heo> ah 2017-04-10 08:16:46 <^7heo> how come you know that so well? 2017-04-10 08:17:05 i've written an OS before 2017-04-10 08:17:07 lol 2017-04-10 08:17:14 <^7heo> ah. 2017-04-10 08:17:24 <^7heo> is the source anywhere? 2017-04-10 08:17:31 only in my shameful local archives 2017-04-10 08:17:36 (it's not very interesting and VERY old) 2017-04-10 08:17:47 Yup, you start throwing a lot of 0xDEADBEEF around to figure out whats REALLY going on :) 2017-04-10 08:18:08 ask me anything about A20 lines 2017-04-10 08:18:10 ACTION grumbles 2017-04-10 08:18:15 <^7heo> A20? 2017-04-10 08:18:31 <^7heo> Shiz: yeah I suspected it to be old; but I still am interested to know how far you went. 2017-04-10 08:18:36 <^7heo> anyway 2017-04-10 08:18:41 <^7heo> backing up the mbr 2017-04-10 08:18:42 https://en.wikipedia.org/wiki/A20_line 2017-04-10 08:18:43 Yeah, you were having page hell. 2017-04-10 08:19:33 you need it to access more than 1MB of memory 2017-04-10 08:19:53 it's an electircal connection on the KEYBOARD CONTROLLER 2017-04-10 08:19:57 Thank you intel. 2017-04-10 08:19:58 because IBM PC is hacks on top of hacks on top of hacks 2017-04-10 08:20:24 <^7heo> v_v 2017-04-10 08:20:51 <^7heo> ok so writing down the syslinux mbr now. 2017-04-10 08:21:01 <^7heo> any precaution I should take? 2017-04-10 08:21:27 just dd if=/usr/share/syslinux/mbr.bin of=/dev/sda bs=440 count=1 should work fine 2017-04-10 08:21:29 i've done it tonnes of times 2017-04-10 08:21:35 <^7heo> ok 2017-04-10 08:21:35 Stretch after every dozen characters or so and make sure you write neatly :) 2017-04-10 08:22:12 <^7heo> okay, rebooting. 2017-04-10 08:22:15 <^7heo> banzaiiiii 2017-04-10 08:22:20 Good luck! 2017-04-10 08:22:38 Shiz, cargo is not yet updated right? 2017-04-10 08:22:57 not yet 2017-04-10 08:23:07 i have an updated apkbuild locally but i ran into some rustc bugs 2017-04-10 08:24:00 ah cargo is not written in rust? 2017-04-10 08:24:26 it is 2017-04-10 08:24:33 why do you think i ran into rustc bugs 2017-04-10 08:24:35 :P 2017-04-10 08:24:42 <^7heo> okay, I'm now booting via the syslinux mbr 2017-04-10 08:24:56 <^7heo> it does the same, but prints hex stuff on the screen for an instant at boot 2017-04-10 08:25:05 hehe 2017-04-10 08:25:25 ^7heo: fwiw, syslinux's mbr code is very basic 2017-04-10 08:25:29 (as it has to fit into 440 bytes) 2017-04-10 08:25:37 it reads the partition table, finds the first partition with the bootable flag set 2017-04-10 08:25:41 <^7heo> yeah but windows's mbr fits in the same size 2017-04-10 08:25:41 and jumps to that partition's VBR 2017-04-10 08:25:44 (volume boot record) 2017-04-10 08:25:47 well, window's mbr does the same 2017-04-10 08:25:49 Shiz, right now i see, it needs itself. 2017-04-10 08:25:55 i didnt see rust as makdep 2017-04-10 08:26:03 ah 2017-04-10 08:26:10 should be added 2017-04-10 08:26:22 actually, should also be a depends= in general for it 2017-04-10 08:26:25 <^7heo> so I did well to activate my boot partition 2017-04-10 08:26:27 <^7heo> right? 2017-04-10 08:26:38 <^7heo> or it wouldn't have jumped to the right vbr... 2017-04-10 08:26:41 clandmeter: rust is already in its normal depends 2017-04-10 08:26:44 even in the current file 2017-04-10 08:26:46 :P 2017-04-10 08:26:55 ^7heo: yes, if your boot part wasn't marked as active/boot it wouldn't have worked 2017-04-10 08:27:01 <^7heo> \o/ 2017-04-10 08:27:01 heh, right 2017-04-10 08:27:07 <^7heo> with windows it would have, I bet. 2017-04-10 08:27:11 looked over it... 2017-04-10 08:27:22 ^7heo: unlikely, actually 2017-04-10 08:27:24 anyway 2017-04-10 08:27:35 the VBR is what extlinux --install (or update-extlinux) writes to 2017-04-10 08:27:53 afaik it hardcodes the FS offset to extlinux.conf and syslinux.c32 in there 2017-04-10 08:27:54 ok finnally i created a PR on github for snapcast 2017-04-10 08:27:59 sorry, ldlinux.c32 2017-04-10 08:28:08 then it loads these in the VBR code and jumps to them 2017-04-10 08:28:08 <^7heo> Shiz: I'll need you to review my installation documentation when it's done. 2017-04-10 08:28:14 and ldlinux.c32 is... syslinux :) 2017-04-10 08:28:33 <^7heo> so to get it right 2017-04-10 08:28:37 err, ldlinux.sys 2017-04-10 08:28:45 <^7heo> when I setup a disk 2017-04-10 08:28:47 <^7heo> I do: 2017-04-10 08:28:53 <^7heo> fdisk /dev/sdX 2017-04-10 08:29:01 <^7heo> then I create the label, the partitions, etc. 2017-04-10 08:29:06 <^7heo> I write that to disk, and then 2017-04-10 08:29:21 <^7heo> dd if=/usr/share/syslinux/mbr.bin of=/dev/sda bs=440 count=1 2017-04-10 08:29:33 <^7heo> That is enough for a bare simple disk. 2017-04-10 08:29:40 you forgot extlinux --install /boot 2017-04-10 08:29:50 <^7heo> Then I have to run syslinux/extlinux for installing the VBR 2017-04-10 08:29:55 yep 2017-04-10 08:29:59 <^7heo> but that's the PARTITION's business, not the disk ;) 2017-04-10 08:30:06 right 2017-04-10 08:30:10 <^7heo> (I know, it's kinda the same thing, but I'm talking offsets here) 2017-04-10 08:30:14 syslinux's boot chain is essentially 2017-04-10 08:30:16 <^7heo> (therefore it's not really) 2017-04-10 08:30:18 <^7heo> yeah 2017-04-10 08:30:22 <^7heo> totally gotcha 2017-04-10 08:30:25 MBR -> VBR -> ldlinux.sys + extlinux.conf -> your kernel + initramfs 2017-04-10 08:30:32 <^7heo> makes sense, and it's REALLY cool to actually find someone who knows this stuff. 2017-04-10 08:30:38 <^7heo> I just wouldn't have expected it to be you :D 2017-04-10 08:30:47 <^7heo> (no offense, it's just that I expect only old dudes to know that) 2017-04-10 08:30:48 :p 2017-04-10 08:30:51 i'm full of useless facts 2017-04-10 08:31:00 <^7heo> it's far from useless actually. 2017-04-10 08:31:05 well, otherwise useless 2017-04-10 08:31:30 <^7heo> "magic man in the sky following flock useless" isn't my exact definition of useless. 2017-04-10 08:31:38 like the two main interface types in japanese visual novels 2017-04-10 08:31:44 full of random facts 2017-04-10 08:31:46 :p 2017-04-10 08:31:58 <^7heo> yeah makes you INTERESTING|GOOD_RNG 2017-04-10 08:32:19 <^7heo> anyway, that's actually really cool info you gave me. 2017-04-10 08:32:30 :) 2017-04-10 08:32:34 np 2017-04-10 08:32:41 <^7heo> because: when I create my label, and my partitions, that goes into 446-510 2017-04-10 08:32:49 <^7heo> the mbr goes in 0-440 2017-04-10 08:33:08 <^7heo> and the whole boot record (which should be called mbr but whatever) is 0-512 2017-04-10 08:33:20 <^7heo> what I do not get is: 2017-04-10 08:33:41 actually 2017-04-10 08:33:42 <^7heo> I have stuff past that point 2017-04-10 08:33:44 the entire thing is called the mbr 2017-04-10 08:33:52 typically 0-446 is called the boot code 2017-04-10 08:33:52 <^7heo> yeah exactly. 2017-04-10 08:34:06 <^7heo> but people (and mbr.bin too) calls that boot code the mbr 2017-04-10 08:34:08 <^7heo> which is confusing. 2017-04-10 08:34:20 what do you mean by stuff beyond that point? 2017-04-10 08:34:21 <^7heo> why is it 446 and not 440? 2017-04-10 08:34:38 <^7heo> (I'll wait for you to answer so we don't cross fire questions so much ;)) 2017-04-10 08:35:22 no special reason, i think syslinux's mbr.bin is just 440 bytes 2017-04-10 08:35:28 they saved a whole 6 bytes 2017-04-10 08:35:30 <^7heo> ok 2017-04-10 08:35:30 :p 2017-04-10 08:35:37 <^7heo> now about your question: well, if I run `dd if=/dev/sda ibs=440 count=1 skip=1 2>/dev/null | xxd`, it's not showing zeros... It's showing syslinux related stuff. 2017-04-10 08:35:58 apparently some OSes like some form of signature at offset 440 2017-04-10 08:36:07 <^7heo> sorry, I meant to use ibs=512 2017-04-10 08:36:12 ^7heo: so my counter-question to that is 2017-04-10 08:36:15 what do you think comes after the mbr 2017-04-10 08:36:17 <^7heo> but same story still. 2017-04-10 08:36:17 :P 2017-04-10 08:36:39 <^7heo> well, I would expect that the mbr code uses the mbr label to jump to the right partition 2017-04-10 08:36:43 <^7heo> and execute THAT vbr 2017-04-10 08:36:50 right 2017-04-10 08:36:52 <^7heo> so after the mbr should be nothing, until the partition starts. 2017-04-10 08:36:59 so 2017-04-10 08:37:05 couldn't it be that the first partition starts after the first sector? 2017-04-10 08:37:07 :P 2017-04-10 08:37:18 <^7heo> (unless you have cryptsetup like I do, but that's another story, it's not LUKS code I can see it) 2017-04-10 08:37:31 <^7heo> nah my partition is aligned much farther in the disk. 2017-04-10 08:37:39 <^7heo> lemme find where. 2017-04-10 08:38:52 <^7heo> the problem is 2017-04-10 08:39:01 <^7heo> that disk has been used MANY times for wildly different stuff. 2017-04-10 08:39:16 <^7heo> there's no way to know if I have dead bytes or not at a given offsent. 2017-04-10 08:39:20 <^7heo> s/sent/set/ 2017-04-10 08:39:38 <^7heo> DAMN. 2017-04-10 08:39:52 <^7heo> 8225280 bytes 2017-04-10 08:39:59 <^7heo> that's the space BEFORE my first partition... 2017-04-10 08:40:07 <^7heo> it's... big. 2017-04-10 08:40:18 hehe 2017-04-10 08:40:25 Device Boot Start End Blocks Id System 2017-04-10 08:40:27 /dev/vda1 * 3 206 102400 83 Linux 2017-04-10 08:40:36 <^7heo> start: 2048 (Units = sectors of 1 * 512 = 512 bytes) 2017-04-10 08:41:02 <^7heo> 2048 * 512 = 1048576 2017-04-10 08:41:28 <^7heo> yet if I use "cylinders" instead of sectors as units... 2017-04-10 08:41:31 <^7heo> I get 8225280 2017-04-10 08:41:34 <^7heo> wtf... 2017-04-10 08:41:56 <^7heo> that's weird. 2017-04-10 08:42:21 <^7heo> ooh, I get it. 2017-04-10 08:42:44 <^7heo> windows decided to disregard the cylinder boundaries when creating the partitions 2017-04-10 08:42:55 <^7heo> and aligned them with nothing in particular, or something I'm not aware of. 2017-04-10 08:43:06 <^7heo> which also explains the: Partition 1 does not end on cylinder boundary 2017-04-10 08:43:30 <^7heo> so fdisk -l reports 1 as in "1 cylinder" but it's not accurate, since it's rounding up. 2017-04-10 08:44:02 <^7heo> windows... 2017-04-10 08:44:31 <^7heo> anyway, I still have 1048576 bytes of free space before my first partition. So why the heck do I have stuff after the MBR? 2017-04-10 08:44:39 olds tuff 2017-04-10 08:44:41 probably 2017-04-10 08:44:50 <^7heo> yeah but it mentions "SYSLINUX" 2017-04-10 08:45:16 mh i cant install the pulseaudio-dev package 2017-04-10 08:45:23 <^7heo> why would you? 2017-04-10 08:45:39 <^7heo> the point of pulseaudio is to uninstall it ;) 2017-04-10 08:45:44 xsteadfastx: it's only in edge 2017-04-10 08:46:17 <^7heo> Shiz: at offset 512 it starts with: eb58 9053 5953 4c49 4e55 58 2017-04-10 08:46:39 yes... it has some "Error relocating /usr/lib/libglib-2.0.so.0: pthread_setname_np: symbol not found".... oh noez 2017-04-10 08:46:42 <^7heo> which is 0xEB 'X' 0x90 'SYSLINUX' 2017-04-10 08:46:55 ah 2017-04-10 08:46:57 <^7heo> which must be some kind of magic number. 2017-04-10 08:46:59 that seems problematic 2017-04-10 08:47:01 <^7heo> I would assume. 2017-04-10 08:47:05 ^7heo: its pretty good for getting sound of a docker container 2017-04-10 08:47:07 0x90 is nop 2017-04-10 08:47:18 <^7heo> dude, WHY would you know that? :D 2017-04-10 08:47:21 <^7heo> ACTION hides 2017-04-10 08:47:21 before i had that task i refused to use it 2017-04-10 08:47:28 xsteadfastx: methinks alsa works better 2017-04-10 08:47:29 :P 2017-04-10 08:47:34 ^7heo: i do reverse engineering 2017-04-10 08:47:36 <^7heo> +1 2017-04-10 08:47:44 yes it does.... but i never got this out of a container before 2017-04-10 08:47:45 0xEB is jump 2017-04-10 08:47:58 <^7heo> Shiz: do you often program via xxd? 2017-04-10 08:48:12 i think i could link the soundcast device itself to the container 2017-04-10 08:48:22 i've stared at enough assembly in my life to recognize an x86 jmp 2017-04-10 08:48:24 :p 2017-04-10 08:48:26 <^7heo> < Shiz> Why use gcc when you have xxd -p? 2017-04-10 08:48:46 <^7heo> (xxd -p -r in that case, but still) 2017-04-10 08:53:37 works. alsa through a sounddevice in a docker container. much less hassle 2017-04-10 08:53:55 <^7heo> yeah alsa FTW ™ 2017-04-10 08:54:10 <^7heo> pulseaudio is just meant as an incentive to pay admins. 2017-04-10 08:54:16 <^7heo> "I have no sound" 2017-04-10 08:54:36 <^7heo> "Ok I'll fix it for you" - $PKGMGR $DEL_OP pulse-audio 2017-04-10 08:54:51 <^7heo> "Wow, it works, thanks! I'm glad that I can see how you're useful for once." 2017-04-10 08:58:27 it most of the time alot more than you need 2017-04-10 08:58:42 i can see that you can do streaming stuff with it and things... but most of the time you only want sound 2017-04-10 08:59:51 <^7heo> Shiz: I think I know what's up 2017-04-10 09:00:03 <^7heo> Shiz: the LUKS header might be in the partition... 2017-04-10 09:01:11 <^7heo> Shiz: you are right, the .X.SYSLINUX is the VBR start. 2017-04-10 09:01:18 ;) 2017-04-10 09:01:34 <^7heo> I checked the start of my boot partition 2017-04-10 09:01:57 for your information 2017-04-10 09:01:58 <^7heo> I have *exactly* the same code. 2017-04-10 09:02:02 0xEB jumps bytes ahead 2017-04-10 09:02:08 so it skips over the SYSLINUX indicator 2017-04-10 09:02:09 <^7heo> yeah I know 2017-04-10 09:02:12 <^7heo> I mean 2017-04-10 09:02:14 <^7heo> I figued. 2017-04-10 09:02:17 <^7heo> s/ue/ure/ 2017-04-10 09:03:18 <^7heo> so essentially 2017-04-10 09:03:27 <^7heo> the LUKS header IS in the partition it points to. 2017-04-10 09:03:33 <^7heo> at the start of it. 2017-04-10 09:32:29 py-gst1 still seems to be broken... so strange. cant import gi 2017-04-10 09:35:53 xsteadfastx: apk add py-gobject3 2017-04-10 09:37:41 YES! that was it 2017-04-10 09:38:03 but should not be py-gobject3 a dependency for py-gst1? 2017-04-10 09:39:44 there is "depends_dev" for it.... but if you cant import the bindings its broken or? 2017-04-10 09:41:08 <^7heo> Shiz: I have one question: since syslinux presents the user with a menu, it means that the mbr will anyway jump to *a* partition's VBR first, which will list all available boot options, right? 2017-04-10 09:41:31 <^7heo> (because the menu is contained in a file, not in a binary form on the hard drive, afaik) 2017-04-10 09:42:33 <^7heo> and so ONLY that partition needs to be active, the rest (even if they hold copies of the same partition that the options point to) don't need to be active, right? 2017-04-10 09:42:59 yes 2017-04-10 09:44:12 sec, in a meeting 2017-04-10 09:44:15 <^7heo> ok 2017-04-10 09:44:29 <^7heo> I'll write here, answer when you can ;) 2017-04-10 09:46:19 <^7heo> so if I'm correct: MBR code -> active partition's VBR code -> syslinux's menu -> initramfs -> OS 2017-04-10 09:46:23 <^7heo> am I missing something? 2017-04-10 09:54:54 <^7heo> Damn 2017-04-10 09:55:05 <^7heo> pickfire: wasn't it you doing zfs over cryptsetup with a pool? 2017-04-10 09:55:37 <^7heo> 'cause I currently have a chicken-egg problem with zfs + cryptsetup. 2017-04-10 10:00:59 clandmeter: should i set myself as maintainer in the snapcast pkg? 2017-04-10 10:01:24 yes please. 2017-04-10 10:02:07 <^7heo> yeah the post I found on serverfault is actually documenting LUKS on top of ZRAID 2017-04-10 10:02:19 <^7heo> not the opposite, since it can't deal with multiple drives. 2017-04-10 10:02:28 <^7heo> it == cryptsetup 2017-04-10 10:02:46 ok. and i also have a question about py-gst1... it needs py-gobject3 to get it working. else python cant import it. its set in depends_dev... but i think its something for "depends" 2017-04-10 10:03:56 xsteadfastx, yes it still needs love 2017-04-10 10:04:40 should i just add it? 2017-04-10 10:05:02 you can, but i think it also needs python2 support. 2017-04-10 10:05:11 for both 2017-04-10 10:05:30 py-gobject3 is python2 2017-04-10 10:06:04 then we need to add py3 :) 2017-04-10 10:06:59 however you can also just fix the things you need now. 2017-04-10 10:07:02 we can add that later. 2017-04-10 10:09:15 ok 2017-04-10 10:37:18 <^7heo> how does alpine linux boot over a Z-Raid? 2017-04-10 10:37:25 <^7heo> Klowner: have you attempted that? 2017-04-10 10:37:31 <^7heo> did anyone attempt that? 2017-04-10 10:39:12 Shiz: reminder https://github.com/alpinelinux/aports/pull/1206 :) 2017-04-10 11:04:06 Shiz: cc on Alpine implicitly compiles with -pie, so even when I disable pie in rustc, it still produces static PIE 2017-04-10 11:04:54 Shiz: when I invoked cc command manually and added -no-pie, then it produced statically linked no-PIE binary that works (i.e. no segfault on panic) 2017-04-10 11:08:06 Shiz: is this really a bug in Rust? what if libunwind just don’t work with static PIE in general, does that make sense? 2017-04-10 11:17:55 Shiz: maybe relevant https://github.com/rust-lang/rust/issues/22885 2017-04-10 11:21:41 Shiz: or instead of manually invoking cc, `rustc -Clink-arg=-no-pie main.rs` (-Z print-link-args prints cc command) 2017-04-10 11:35:28 i'm not entirely convinced libunwind fails with static pie 2017-04-10 11:36:03 and that bug is afaik outdated 2017-04-10 11:36:13 if it was pax it would fail to launch in the first place 2017-04-10 11:36:34 jirutka: how did llvm-libunwind turn out? 2017-04-10 11:38:02 Shiz: no difference for static PIE 2017-04-10 11:46:44 jirutka: tried compiling with debug? :P 2017-04-10 11:48:42 emm, not yet :P 2017-04-10 11:49:24 i found out that it really does not fix the problem, so put back original libunwind 2017-04-10 11:50:19 it might provide more useful debug info 2017-04-10 11:50:24 maybe 2017-04-10 11:50:42 Shiz: llvm-libunwind is in testing, so you can try it 2017-04-10 12:59:32 Guys, according to feedback, my new aport request needs some changes. Should I prepare new patch from scratch or only changes over previous request? 2017-04-10 13:06:49 <_ikke_> terra: A complete new patch usually 2017-04-10 13:08:47 <_ikke_> terra: usually you call that patch vX where X is the iteration number (v2 for example) 2017-04-10 13:10:05 _ikke_: got it. thanks. 2017-04-10 13:15:58 Is Alpine still on Soft freeze? 2017-04-10 13:18:16 <^7heo> I don't think it has been soft-frozen yet. 2017-04-10 13:20:48 nmm, I receive an email saying "We are imposing a soft freeze in edge for now, as part of preparation for the 3.6 release." 2017-04-10 13:21:04 The email title is 'Soft freeze imposed for 3.6 release prep" 2017-04-10 13:24:41 <^7heo> yeah but I'm not sure if it was followed on. 2017-04-10 14:00:10 tmh1999: hi 2017-04-10 14:00:23 looks like disk went full on build-edge-s390x 2017-04-10 14:00:43 something appeared to go wrong with community/monitoring-plugins 2017-04-10 14:00:48 it hadd 100G build log 2017-04-10 14:00:54 i just purged it 2017-04-10 14:01:44 <^7heo> wow 100G of log. 2017-04-10 14:22:19 ncopa: x86 builder is missing 2017-04-10 14:22:31 ok 2017-04-10 14:24:13 its back now 2017-04-10 15:07:20 Shiz: r u here? 2017-04-10 15:12:55 ? 2017-04-10 15:12:59 Someone bumped me? 2017-04-10 15:13:37 <_ikke_> pickfire: ^7heo highlighted you 2017-04-10 15:13:50 jirutka: sorta 2017-04-10 15:14:01 Shiz: any progress with rust? 2017-04-10 15:14:03 _ikke_: What did he said? 2017-04-10 15:14:17 i've been at work today 2017-04-10 15:14:18 :P 2017-04-10 15:14:33 I wonder if I can do reverse search on irssi. 2017-04-10 15:14:33 i found the root cause for a static pie issue though 2017-04-10 15:14:58 Shiz: Ah, nice. Didn't know you are working on the static rust thing. 2017-04-10 15:15:02 Shiz: I’ve disabled PIE for static, build cargo and… what the hell… it builds broken binary, the same problem as you’ve said, dynamically linked without link to libc 2017-04-10 15:15:20 Shiz: really? where? :) 2017-04-10 15:16:09 <_ikke_> pickfire: ^7heo │ pickfire: wasn't it you doing zfs over cryptsetup with a pool? 2017-04-10 15:16:50 <^7heo> thanks a bunch irclogger_com 2017-04-10 15:16:51 Ah 2017-04-10 15:16:52 No 2017-04-10 15:16:52 <^7heo> _ikke_: 2017-04-10 15:17:11 ^7heo: I use brtrs raid 1 with one disk on luks. 2017-04-10 15:17:18 raid 0* 2017-04-10 15:18:23 <^7heo> ah yeah 2017-04-10 15:18:28 <^7heo> ok so please disregard my question 2017-04-10 15:34:02 ncopa : there are packages hosted at distfiles.alpinelinux.org that is 404. can you bring up the host online ? 2017-04-10 15:35:01 ncopa : I actually have built up to half of community. I am checking what's wrong with monitoring-plugins 2017-04-10 15:38:26 also the website is not regenerating when new git events happen 2017-04-10 15:49:00 rnalrd : Hi, looks like you applied old version of my patch instead of v2 : http://patchwork.alpinelinux.org/patch/3286/, http://patchwork.alpinelinux.org/patch/3291/ . Can you change it ? 2017-04-10 15:57:07 the v2 patch status is accepted in patchwork but it is not merge in aports tree 2017-04-10 16:05:04 ok, i'll have a look at distfile 2017-04-10 16:05:10 i thought it was working... 2017-04-10 16:07:48 thanks ! 2017-04-10 16:35:00 distfiles.alpinelinux.org should work again 2017-04-10 16:35:07 there used to be a limit on filesize 2017-04-10 16:35:15 i wonder if it is still the case 2017-04-10 17:20:59 jirutka: hello, back 2017-04-10 17:33:47 fabled - are you on by chance? 2017-04-10 18:19:11 fabled: Would you please take a look at Issue #7107 and Shiz's attached patch and drop a point release of apk addressing at least that issue? Thanks! 2017-04-10 18:21:01 TemptorSent, looks about right 2017-04-10 18:22:04 Hi fabled - that, combined with the fact that 'apk search -x -q $pkg' returns differnt results thant 'apk search -x $pkg' breaks cross-platform building for me. 2017-04-10 18:24:34 I have in my repositories file my local repo, which I need for staging packages I've built on x86_64, but the fact that repo entry exists, but has no aarch64 (or whatever) packages, throws a warning when trying to run 'apk search -x $pkg' to obtain the full package version, which 'apk search -x -q $pkg' omits. 2017-04-10 18:25:55 Also, if you have time, please take a look at 7100-7104 2017-04-10 18:31:31 ^7heo: zfs raid? I've got that working 2017-04-10 18:32:00 just make your pool all raid'y and go nuts 2017-04-10 18:33:15 Klowner: I think ^7heo was asking about boot from raidz. 2017-04-10 18:33:53 ohhh, booting, no 2017-04-10 18:34:23 If your using a detached header, why not just use that to boot off as well? 2017-04-10 18:35:47 Leaves nothing but encrypted disks behind with no information about them to aid someone who gets physical access to a powered off machine (You DO have tripwires to that kill power on physical intrusion, RIGHT?) 2017-04-10 19:00:58 looks like jenkins is broken 2017-04-10 19:09:23 I'm really beginning to curse at Redmine on a regular basis. I commented on Issue #6591 and somehow lost at /p on the sed script, would someone in the APK project please fix the original comment and delete my reply to my reply? 2017-04-10 19:11:46 Thanks... 2017-04-10 19:35:20 Shiz: i found the root cause for a static pie issue though … I’m curious :) 2017-04-10 19:55:42 leitao: hi 2017-04-10 19:56:33 leitao: I’ve tried to build neovim and it correctly uses system-provided LuaJIT on my system 2017-04-10 20:29:14 <^7heo> Klowner: do you have zfs root? 2017-04-10 20:29:28 <^7heo> Klowner: and if yes, are you using that over LUKS? 2017-04-10 20:31:02 I have zfs root but not doing anythign with LUKS 2017-04-10 20:31:10 just zfs on linux 2017-04-10 20:31:44 <^7heo> Ok 2017-04-10 20:31:51 <^7heo> I'm attempting ZFS over LUKS 2017-04-10 20:32:10 <^7heo> and possibly Z-RAID ZFS over LUKS with detached header. 2017-04-10 20:32:17 <^7heo> it's... challenging ;) 2017-04-10 20:37:22 that sounds like a project :D 2017-04-10 20:50:47 jirutka, hm, here it download it from the web 2017-04-10 20:52:51 leitao: does it pull luajit pkg? 2017-04-10 20:55:12 <^7heo> Klowner: I'm currently exchanging via ML with the guys who wrote LUKS/Cryptsetup/dm-crypt with the hope that it will be easy to use one detached header for many disks. 2017-04-10 20:55:24 <^7heo> Klowner: in that case, this would be awesome news. 2017-04-10 21:00:38 <^7heo> Klowner: also, I am writing a documentation on how to do that. 2017-04-10 21:01:29 <^7heo> omg. 2017-04-10 21:01:40 <^7heo> apk dot generates SUCH a mess of a graph... 2017-04-10 21:01:47 <^7heo> http://webgraphviz.com/ 2017-04-10 21:01:57 <^7heo> source: http://ix.io/qeU 2017-04-10 21:02:18 <^7heo> that is the offspring of Baal, the devourer of the souls. 2017-04-10 21:23:46 its meant to be visualized yes :p 2017-04-10 21:24:22 <^7heo> ? 2017-04-10 21:24:36 apk dot graphs 2017-04-10 21:25:02 you can do the same with pkgconf, too. pkgconf --digraph <.pc files here> 2017-04-10 21:25:02 <^7heo> yeah but still, it's useless 2017-04-10 21:25:10 <^7heo> there's WAY too much clutter to visualize anything with it. 2017-04-10 21:25:47 tbh, largely it's meant to be used for visualizing the exact solution the dep solver came up with 2017-04-10 21:26:00 it might be nice to declutter the graph for other uses though :) 2017-04-10 21:26:26 <^7heo> yeah totally. 2017-04-10 21:26:39 <^7heo> esp since most usages won't need the exact versions of all the things. 2017-04-10 21:27:00 <^7heo> in my case, for instance, I could have almost used the http://pkgs.alpinelinux.org/package/v3.5/main/aarch64/* pages 2017-04-10 21:27:07 <^7heo> starting with the pages I want to install 2017-04-10 21:27:22 <^7heo> and (manually) recursively list all of them. 2017-04-10 21:27:33 <^7heo> ofc using that with a dot file is much nicer since it does the recursion for you. 2017-04-10 21:27:55 <^7heo> but yeah in the end it's kinda faster to process the output of apk directly than to read the graph, 'cause it's HUGE. 2017-04-10 21:35:09 jirutka: so 2017-04-10 21:35:28 .g. libssh2-sys specifies a static=ssh2 attribute 2017-04-10 21:35:36 rust seems to strip the static= from that 2017-04-10 21:35:41 in the resulting metadata 2017-04-10 21:46:43 <^7heo> If anyone ever wants to generate the list of packages to copy on the install media for a given package to be available via the install media, the command is: 2017-04-10 21:46:50 <^7heo> apk dot $packagename | sed '1,3d; $d; s/^ //; s/->.*$//; s/"//g; s/-[0-9r.-]\+//' | sort -u | while read package; do ls $install_disk_mountpoint | grep -q "$package" || echo "Package $package"; done 2017-04-10 21:51:52 <^7heo> wait no that will miss the dependencies that don't have any. 2017-04-10 21:51:58 <^7heo> which CAN happen. 2017-04-10 21:53:53 ^7heo: I'm working on solving that problem permentently :) 2017-04-10 21:55:00 Currently, I'm finishing up the kernel and module staging tool, which manifests everything it installs with checksums, so you can get a complete dep tree of not just packages, but individual files. 2017-04-10 21:55:45 <^7heo> myeah 2017-04-10 21:57:00 so tired 2017-04-10 21:59:25 <^7heo> yeah. 2017-04-10 21:59:26 <^7heo> totally. 2017-04-10 21:59:57 ^7heo: Hopefully, I'll be ready to push that shortly, still getting it working right. 2017-04-10 22:00:23 <^7heo> well, my sed expression works very well. 2017-04-10 22:00:30 <^7heo> I corrected it and now it works REALLY well. 2017-04-10 22:03:06 You're just looking for packages needed? 2017-04-10 22:04:38 <^7heo> yeah. 2017-04-10 22:04:47 <^7heo> $ install_media_extra_deps /media/sdc1/apks/x86_64 zfs 2017-04-10 22:04:48 <^7heo> keyutils-libs 2017-04-10 22:04:48 <^7heo> krb5-conf 2017-04-10 22:04:49 <^7heo> ... 2017-04-10 22:07:24 krb5-conf? for what do you need krb? 2017-04-10 22:07:51 Shiz: no wonder, since you don’t sleep :) 2017-04-10 22:11:26 i took a nap from when i got home until just now, actually 2017-04-10 22:11:28 :P 2017-04-10 22:13:38 <^7heo> jirutka: zfs 2017-04-10 22:14:00 ^7heo: why the heck ZFS needs Kerberos?! 2017-04-10 22:14:38 It handles encryption and authentication with it for nfs 2017-04-10 22:17:14 eww 2017-04-10 22:17:36 yet another reason why I’m not fan of ZFS… 2017-04-10 22:17:48 <^7heo> I dunno, I am trying it currently. 2017-04-10 22:17:52 <^7heo> it seems "cool" 2017-04-10 22:18:08 <^7heo> but I'll tell you more when I see how it performs. 2017-04-10 22:19:44 jirutka: i might be able to cook up a patch for the library issue 2017-04-10 22:19:48 meanwhile, whats the overall status? 2017-04-10 22:24:54 <^7heo> jirutka: the thing with zfs is that it is supposed to work in RAID intelligently and recover from errors and perform encryption, checksum, etc. 2017-04-10 22:25:15 <^7heo> (encryption coming soon, not yet avail) 2017-04-10 22:25:38 <^7heo> and by "checksum" I meant "recovery based on redundancy and silent corruption detection" 2017-04-10 22:25:50 <^7heo> and so forth 2017-04-10 22:26:05 <^7heo> the problem you'd have with it has more to do with the zero-admin I think. 2017-04-10 22:26:34 <^7heo> which is why the kerberos deps are pulled, instead of a per-setup dep. 2017-04-10 22:27:34 ^7heo: zfs supports exporting to nfsv4 and CIFS, both of which use kerberos based authentication. 2017-04-10 22:28:19 <^7heo> TemptorSent: if it wasn't automatically managed, the dependency would be pulled by the person installing it instead of "just in case" 2017-04-10 22:28:28 ^7heo: You could probably do without those deps unless you're using those exports. 2017-04-10 22:28:48 <^7heo> I guess, but the graph listed them so... 2017-04-10 22:28:54 ^7heo: Try a lddtree on each binary and see what actually uses it. 2017-04-10 22:28:59 <^7heo> nah no time for that. 2017-04-10 22:29:06 <^7heo> first I do the thing, THEN I'll iterate ;) 2017-04-10 22:29:40 It looks like nvpair is the one that needs it 2017-04-10 22:31:00 jirutka: it seems their own musl build uses llvm libunwind btw 2017-04-10 23:14:48 Shiz: great! overall status is that it’s kinda fucked up :/ 2017-04-10 23:15:05 do we have a list of issues? 2017-04-10 23:15:08 1) panic! broken 2017-04-10 23:15:16 2) it tries to link in dynlibs to a static-PIE lib 2017-04-10 23:15:18 Shiz: I know that it uses llvm’s libunwind, that’s why I’ve tried it 2017-04-10 23:15:19 anything else? 2017-04-10 23:15:43 Shiz: panic is broken on static PIE, works on classic on-PIE static; I have a patch to make non-PIE static working 2017-04-10 23:16:06 Shiz: but rustc and cargo tests fails on both and don’t know why yet 2017-04-10 23:16:40 and it fails quite strangely… 2017-04-10 23:16:55 i'm discussing it with the #musl people 2017-04-10 23:16:57 or at least, trying 2017-04-10 23:16:59 :D 2017-04-10 23:17:45 Shiz: cargo tests failing when compiled with dynamic https://hastebin.com/nevulocejo 2017-04-10 23:18:06 yeah this is an interesting one 2017-04-10 23:18:12 Shiz: note: relocation R_X86_64_PC32 against protected symbol `_ULx86_64_local_addr_space' can not be used when making a shared object 2017-04-10 23:18:13 luckily it's just one error 2017-04-10 23:18:46 yes 2017-04-10 23:19:13 i ran into this before 2017-04-10 23:19:15 2017-03-08 23:30:27 the .o file containing that reloc was miscompiled 2017-04-10 23:19:17 2017-03-08 23:30:32 so Ltrace.o I think 2017-04-10 23:19:19 2017-03-08 23:30:43 TPOFF32 is not a valid TLS reloc type in shared libraries 2017-04-10 23:20:17 when I’ve tried to build it as non-PIE static, it failed even compile… don’t remember details now… I have to retry it; I was in hurry and forgot to log it 2017-04-10 23:20:48 jirutka: i think my patch may actually solve this properly 2017-04-10 23:20:57 :) 2017-04-10 23:20:59 jirutka: so the issue is 2017-04-10 23:21:04 can you please share? 2017-04-10 23:21:08 i haventm ade it yet 2017-04-10 23:21:10 :P 2017-04-10 23:21:16 rustc passes a final -Wl,-Bdynamic to the linker commandl ine 2017-04-10 23:21:30 i think it 'just' needs to omit this for crt-static 2017-04-10 23:21:37 that's all 2017-04-10 23:22:17 I still don’t understand why it happens only on musl host; rustc supports musl for years, to build statically linked executables on non-musl systems 2017-04-10 23:22:49 it even does not pass -static, only -Bstatic 2017-04-10 23:23:02 I mean does not pass -static before your patch 2017-04-10 23:23:14 <^7heo> /usr/bin/xxd is owned by vim-8.0.0027-r0 2017-04-10 23:23:16 <^7heo> Weird. 2017-04-10 23:23:59 jirutka: yes but 2017-04-10 23:24:06 jirutka: it's not static PIE 2017-04-10 23:24:09 aha, I remembered; when I’ve tried to build cargo as static non-PIE, it produced dynamic binary with no link to libc 2017-04-10 23:24:12 which probably confuses it 2017-04-10 23:24:54 Shiz: this is the patch to fix non-PIE static http://tpaste.us/eD6B 2017-04-10 23:25:27 Shiz: it’s based on your patch, I added --no-pie, b/c cc on Alpine builds --pie by default 2017-04-10 23:25:49 :( 2017-04-10 23:26:05 don't do that :P 2017-04-10 23:26:09 why? 2017-04-10 23:26:52 non-pie static is better than broken pie static; since you’re working on fixing pie static, I’ve tried non-pie 2017-04-10 23:32:21 we want static PIE though :p 2017-04-10 23:32:37 question. 2017-04-10 23:32:38 how does llvm version bumps effect rust? 2017-04-10 23:32:47 or does rust link against llvm statically 2017-04-10 23:33:10 kaniini: rust needs llvm 3.7, 3.8 or 3.9 2017-04-10 23:33:14 kaniini: does not work with 4.0 yet 2017-04-10 23:33:23 sure. that's not my question though 2017-04-10 23:33:42 rust links against llvm 3.8 dynamically. what happens when we upgrade to 3.9? 2017-04-10 23:33:47 kaniini: to be honest, I don’t care for now if it’s PIE or not, I want to FINALLY have working rustc into v3.6 2017-04-10 23:33:59 kaniini: then rustc must be recompiled ofc 2017-04-10 23:34:13 but rustc requires rust? 2017-04-10 23:34:17 kaniini: rustc can be linked against llvm even statically if needed 2017-04-10 23:34:32 kaniini: yes, currently we use binaries from VoidLinux for bootstrapping 2017-04-10 23:34:33 yes, i think we should link rustc statically 2017-04-10 23:34:38 kaniini: why? 2017-04-10 23:34:51 so that we do not have to rebootstrap it every time 2017-04-10 23:35:06 it’s not needed to rebootstrap every time 2017-04-10 23:35:14 just rebuild rust package, that’s all 2017-04-10 23:35:22 single package 2017-04-10 23:35:25 but the rust package requires the old llvm 2017-04-10 23:35:35 yes 2017-04-10 23:35:37 and? 2017-04-10 23:35:57 we need to keep 3.8 or 3.9 anyway 2017-04-10 23:36:01 so it will fail to run, when the new llvm is installed 2017-04-10 23:36:03 and also 3.7, for ghc 2017-04-10 23:36:27 unless we unconditionally build our rust against VoidLinux's toolchain which seems all sorts of terrible idea 2017-04-10 23:36:43 no, when we upgrade llvm to 4.0, then we will also create llvm3.8 (or llvm3.7) and build rustc against it 2017-04-10 23:36:50 the same as llvm3.7 that we already have 2017-04-10 23:37:14 and VoidLinux’s rust links llvm statically 2017-04-10 23:37:40 so then we have 3 llvm packages installed on our machine for ghc, rust and dotnet-core 2017-04-10 23:37:46 jirutka: okay, i have something 2017-04-10 23:37:51 so much for minimalism 2017-04-10 23:37:55 a patch that is 2017-04-10 23:38:15 so you prefer to “hide” it or what? 2017-04-10 23:38:25 yes, LLVM is PITA, we all know that 2017-04-10 23:38:29 https://txt.shiz.me/OTk4YzliND 2017-04-10 23:38:33 completely untested 2017-04-10 23:38:34 and there’s unfortunately nothing we can do about that :( 2017-04-10 23:38:35 gonna try it now 2017-04-10 23:38:49 jirutka: you didn't push the no-static-pie patch to aports yet, right? 2017-04-10 23:38:58 Shiz: no, I did not 2017-04-10 23:39:07 :) 2017-04-10 23:39:52 kaniini: eventually we will bootstrap rustc using prebuilt binary from upstream, maybe in ten years they will FINALLY dammit provide it; or we cross-compile it from fucking glibc binary in same way as ghc :/ 2017-04-10 23:40:07 jirutka: i mean, i guess. it just seems like a mess 2017-04-10 23:40:32 omg, I’m really fan of Rust, but since I’ve started trying to compile it on Alpine, I have really VERY mixed feeling about it… 2017-04-10 23:40:40 kaniini: and what do you propose instead? 2017-04-10 23:40:43 i was a fan of Rust until I started using it 2017-04-10 23:40:46 it has mellowed a bit since 2017-04-10 23:40:49 it's a nice community though 2017-04-10 23:40:54 also, depending on VoidLinux to bootstrap is not a situation i think we should be in 2017-04-10 23:41:02 kaniini: ofc, this is just temporary 2017-04-10 23:41:34 kaniini: anyone is welcome to write script for bootstrapping from glibc binary :) now we have bigger issues, like that our rustc is completely broken 2017-04-10 23:41:56 jirutka: i don't have a solution for the "different projects depend on different llvm versions" problem, but i think that clear bootstrapping methods should be required as a deliverable for each language that requires bootstrap 2017-04-10 23:41:59 kaniini: once we have our own binraies out we can simpy use those to bootstrap 2017-04-10 23:42:15 voidlinux is mostly until we have a stable build of our own with the bugs weeded out 2017-04-10 23:42:27 Shiz: but if they depend on llvm (there is no llvm3.8 package right now), then we cannot, as llvm will be upgraded 2017-04-10 23:42:33 kaniini: I know, but once again, we have bigger issues now… 2017-04-10 23:43:13 i think we should move llvm to llvm3.8 2017-04-10 23:43:50 to ensure that we solve this before it becomes a future problem 2017-04-10 23:43:58 so, basically 2017-04-10 23:43:59 kaniini: I’ve cross-compiled rustc ~9 months ago when I’ve created first version of our rust pkg and it was not very pleasure experience, so I’m not eager to it now, but I’ll eventually do it 2017-04-10 23:44:00 llvm packages MUST be versioned 2017-04-10 23:44:10 something like how we handle Gtk 2017-04-10 23:44:22 there’s on the todo list 2017-04-10 23:44:34 okay 2017-04-10 23:44:40 but the problem is 2017-04-10 23:44:40 but I’d like to first try to update llvm to 3.9 and create llvm3.9 instead of 3.8 2017-04-10 23:44:52 okay 2017-04-10 23:45:01 if you want to do that, that's fine. i will work on that front 2017-04-10 23:45:20 then we can rebuild rust against llvm3.9 2017-04-10 23:45:28 and then remove llvm from the distro 2017-04-10 23:45:31 yes, that works for me 2017-04-10 23:45:41 I wouldn’t say that I want to do that :) 2017-04-10 23:45:59 i mean, if that is the approach you want to take, using llvm 3.9 with rust 2017-04-10 23:46:13 it’d be better, but not necessary 2017-04-10 23:46:21 may as well do it 2017-04-10 23:46:21 depends on how difficult it will be to port our patches 2017-04-10 23:46:41 we just need to keep the transitional llvm package for now 2017-04-10 23:46:53 until we get that done 2017-04-10 23:47:02 transational? 2017-04-10 23:47:40 yes, the current llvm (not versioned) packages 2017-04-10 23:47:42 Shiz: looking at your patch… it seems that rust build system is really broken 2017-04-10 23:47:55 Shiz: b/c this change is like very obvious 2017-04-10 23:47:58 because removing it will break the dependencies of everything dependent on llvm right now 2017-04-10 23:48:13 yes 2017-04-10 23:48:19 so we need to shift those to llvm3.9 deps 2017-04-10 23:48:37 but since rust needs rust to build, we need to keep main/llvm in the distro for now 2017-04-10 23:48:57 crystal is the other one to figure out, but that will wait for 3.7 2017-04-10 23:49:22 kaniini: no, we don’t 2017-04-10 23:49:30 jirutka: currently building against it 2017-04-10 23:49:44 kaniini: once again, rust from VoidLinux we use for bootstrapping is statically linked against LLVM, so we don’t need LLVM to use it 2017-04-10 23:49:44 jirutka: we do if we wnat to remove the main/llvm 2017-04-10 23:50:01 jirutka: okay 2017-04-10 23:50:19 kaniini: or maybe I don’t understand the issue, that’s quite possible, I’m a bit drunk now 2017-04-10 23:50:24 i presume we do want to still support the case of the user doing # apk add llvm 2017-04-10 23:50:32 and have it install the 'newest' llvm by default 2017-04-10 23:50:42 Shiz: that's easy. we use provides= for that :) 2017-04-10 23:50:44 yes 2017-04-10 23:50:47 just making a note 2017-04-10 23:50:47 Shiz: agree, llvm can be a metapackage depending on the newest llvm or something liek that 2017-04-10 23:50:49 :) 2017-04-10 23:50:53 kaniini: yeah, or that, better :) 2017-04-10 23:51:08 Shiz: it will pick the newest provider for it 2017-04-10 23:51:18 I’m quite pissed of from this situation with Rust :( 2017-04-10 23:51:53 when I pushed recent changes to repo I thought that it’s finally complete and then found out that it’s more like completely broken 2017-04-10 23:52:01 jirutka: i'm talking to rust devs about it and they seem very agreeable at least 2017-04-10 23:52:02 jirutka: for bootstrapping, yes voidlinux binaries are used. what this is about more is trying to ensure rust lands with the right dependencies off the bat 2017-04-10 23:52:15 Shiz: agreeable that their build system is broken as hell? 2017-04-10 23:52:29 at least agreeable on that the behavior we want is the correct behavior 2017-04-10 23:52:32 from rust 2017-04-10 23:52:33 :P 2017-04-10 23:52:54 all of these LLVM languages are annoying 2017-04-10 23:53:03 yeah, we want static binary to be really static and not somehow mixed and dynamic binary be really dynamic, linked against libc, that’s obviously correct behaviour :)) 2017-04-10 23:53:18 not languages, just LLVM itself 2017-04-10 23:53:18 ghc, rust, crystal (which exists only in third-party repo), and probably 10 others people want that i dont yet know about :) 2017-04-10 23:53:29 they are annoying for depending on LLVM :) 2017-04-10 23:53:33 yeah 2017-04-10 23:53:40 annoyance by association 2017-04-10 23:53:51 unfortunately there’s currently nothing better with same performance :( 2017-04-10 23:54:34 but the same, when I see LLVM somewhere, I’m sad 2017-04-10 23:54:59 Julia also uses LLVM 2017-04-10 23:55:17 IIRC this was my first fight with LLVM insanity 2017-04-10 23:55:37 surprisingly, in my time with rust llvm has not been the source of errors 2017-04-10 23:55:39 :P 2017-04-10 23:56:14 heh, yes :) 2017-04-10 23:56:30 also to come back to your question jirutka 2017-04-10 23:56:34 yes, julia is the other one i was thinking about. 2017-04-10 23:56:41 i think the reason a lot of stuff worked before is that they simply bypassed a lot of toolchain stuff 2017-04-10 23:56:51 which was reason for a ton of breakage here but they didn't notice because they didn't use it 2017-04-10 23:57:02 now that we removed the silly toolchain bypasses (linking crt*.o manually, really?!) 2017-04-10 23:57:08 those things come to surface 2017-04-10 23:57:58 crystal is the one that is still missing, but i am working with the upstream maintainer who packages it to come up with a plan to get it into actual alpine 2017-04-10 23:58:54 and dotnet-core, but that is more of a conversation that i am planning to have, as i do not want to do much of the lifting on that one personally considering microsoft is hungry to support alpine 2017-04-10 23:59:50 btw what are preferred boolean values in CMake? ON/OFF, TRUE/FALSE, YES/NO…? 2017-04-11 00:00:17 MS wants to support Alpine? 2017-04-11 00:00:53 yes, alpine is a primary goal for them for .net core 2017-04-11 00:01:31 docker docker docker docker 2017-04-11 00:01:41 hmm 2017-04-11 00:01:54 still compiling rust... 2017-04-11 00:01:57 my patch had a small error 2017-04-11 00:03:34 kaniini : can I ask you a favor :D 2017-04-11 00:03:56 ? 2017-04-11 00:04:39 Shiz: amongst other reasons, yes :) 2017-04-11 00:04:49 these 2 are marked Accepted http://patchwork.alpinelinux.org/patch/3286/, http://patchwork.alpinelinux.org/patch/3291/, but only the first one is merged in aports tree. The first one is v1, the second one is v2 I submitted. 2017-04-11 00:04:55 kaniini : ^ 2017-04-11 00:05:46 kaniini : https://git.alpinelinux.org/cgit/aports/commit/?id=ca4896137afab172462b49af6719d3f1a4a4f249 2017-04-11 00:05:51 tmh1999: patch fails to apply 2017-04-11 00:06:00 tmh1999: please rebase and send me a .mbox 2017-04-11 00:06:23 kaniini : yes because the 1st one is not supposed to be applied ... OKay I'll send another one 2017-04-11 00:07:06 tmh1999: or just open pull request on GitHub to avoid such stupid problems… 2017-04-11 00:07:24 :P 2017-04-11 00:12:28 kaniini : http://tpaste.us/kqnb 2017-04-11 00:14:07 tmh1999: ok give me 15 min and it will be done 2017-04-11 00:14:15 kaniini : thank you :) 2017-04-11 00:14:59 kaniini: btw can’t be simply update config/guess automatically when outdated? 2017-04-11 00:15:04 s/be/we/ 2017-04-11 00:15:10 yes 2017-04-11 00:15:22 i thought of that earlier doing it in prepare 2017-04-11 00:16:05 abuild is already able to find config/guess file and has own copy of them, so it should be just a matter of ~2 lines to automatically update when old 2017-04-11 00:21:52 hmm, maybe I’ve already ported these llvm patches, when creating emscripten-fastcomp 2017-04-11 00:22:15 I’m not sure on which version it’s based 2017-04-11 00:23:15 kaniini: not sure if you know, we have even more llvm pkgs, emscripten-fastcomp is emscripten’s fork of LLVM… yeah, everyone has it’s own fork of LLVM… unfortunatelly Emscripten does not work with vanilla LLVM yet :( 2017-04-11 00:23:33 this world is insane… 2017-04-11 00:24:25 jirutka: testing my patch now 2017-04-11 00:24:27 :) 2017-04-11 00:24:38 jirutka: also i remember the times rustllvm wasn't upstream-compatible either 2017-04-11 00:24:42 fun times 2017-04-11 00:24:57 yeah and they still have own fork of LLVM… 2017-04-11 00:25:05 tmh1999: done 2017-04-11 00:25:19 jirutka: at least they support mainline now 2017-04-11 00:25:21 they didn't back in the day 2017-04-11 00:25:24 yeah 2017-04-11 00:25:29 kaniini : I appreciate it 2017-04-11 00:25:30 what's actually different in their fork? 2017-04-11 00:25:35 do you happen to know? 2017-04-11 00:25:40 Shiz: that’s the billion dollar question! 2017-04-11 00:26:28 jirutka: apparently it's because some platforms don't have a system LLVM 2017-04-11 00:26:30 like osx 2017-04-11 00:27:05 and an optional patch: https://github.com/rust-lang/llvm/commit/ed0d1402540eeb8c9ac610234c581c9612542b28 2017-04-11 00:27:32 even their travis buildbot uses system llvm 2017-04-11 00:30:47 jirutka: good news :) 2017-04-11 00:30:55 Shiz: it works? 2017-04-11 00:31:02 well, it fails because we have no libgit2.a 2017-04-11 00:31:05 or libcurl.a 2017-04-11 00:31:06 but... yes 2017-04-11 00:31:08 :p 2017-04-11 00:31:41 yay! 2017-04-11 00:31:45 I’ll add libgit2.a 2017-04-11 00:32:22 = note: /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lgit2 2017-04-11 00:32:24 /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lcurl 2017-04-11 00:32:26 collect2: error: ld returned 1 exit status 2017-04-11 00:32:31 slightly weird since libcurl.a is right there under curl-dev 2017-04-11 00:32:33 hmmm 2017-04-11 00:33:20 Shiz: btw I’m impressed by your skills! :) 2017-04-11 00:33:31 of what? :P 2017-04-11 00:33:35 (thanks for the compliment though!) 2017-04-11 00:33:53 skills… is that correct word for it? 2017-04-11 00:34:31 you're rather pleasant to work with yourself :) 2017-04-11 00:34:40 we're doing well in tackling this thing together i feel ;p 2017-04-11 00:37:11 yeah, but currently it’s more your merit than mine, I don’t have enough experience with analyzing ELF binaries etc. to solve this and also not enough patience for it anymore 2017-04-11 00:38:42 nonsense 2017-04-11 00:38:45 we're just doing different things :) 2017-04-11 00:38:49 also 2017-04-11 00:39:01 it seems we do not in fact ship libcurl.a 2017-04-11 00:39:18 https://git.alpinelinux.org/cgit/aports/tree/main/curl/APKBUILD?h=3.4-stable#n70 2017-04-11 00:39:19 :( 2017-04-11 00:39:28 https://git.alpinelinux.org/cgit/aports/tree/main/curl/APKBUILD?h=master#n62 even 2017-04-11 00:39:38 I’ll fix it asap 2017-04-11 00:39:58 is there some “standard” flag for CMake to force it install .a archive? 2017-04-11 00:40:07 i'll compile locally 2017-04-11 00:40:14 i presume it's 2017-04-11 00:40:29 -DBUILD_STATIC_LIBS=True 2017-04-11 00:41:57 I’ve tried that with another lib and it didn’t work, so not sure how “standard” it really is 2017-04-11 00:44:03 hmm 2017-04-11 00:44:53 jirutka: ugh 2017-04-11 00:45:03 jirutka: you need to set -DBUILD_SHARED_LIBS=False 2017-04-11 00:45:06 build 2017-04-11 00:45:10 ’kay, I’ll solve it in same way as with llvm-libunwind 2017-04-11 00:45:10 and then rebuild with that to =True 2017-04-11 00:45:12 :P 2017-04-11 00:45:15 i.e. build twice 2017-04-11 00:45:28 but it’s silly :/ 2017-04-11 00:46:04 or I’ll try to patch this CMakeLists.txt 2017-04-11 00:54:50 jirutka: want an updated static-pie.patch? 2017-04-11 01:03:40 jirutka: https://txt.shiz.me/MDQ5NjE4Yz 2017-04-11 01:41:14 jirutka: \o/ static pie works 2017-04-11 01:41:31 we may need to add -Wl,-( and -Wl,-) back to the linker command line, though 2017-04-11 01:52:14 Shiz: excellent! \o/ 2017-04-11 01:52:37 we do need to add -Wl,-( and -Wl,-) back 2017-04-11 01:52:44 do you remember what that broke/why we deleted it in the first place? 2017-04-11 01:52:52 Shiz: I’ve added static lib to libgit2 and curl and pushed 2017-04-11 01:52:57 :) 2017-04-11 01:53:11 Shiz: it didn’t break anything IIRC, just thought that it’s not needed 2017-04-11 01:53:35 ah 2017-04-11 01:53:36 I need to go sleep, gn 2017-04-11 01:53:39 it is needed for static linking 2017-04-11 01:53:42 good night! 2017-04-11 02:54:06 leitao : have you tried to build on x86/x86_64 ? This commit breaks newsbeuter : https://git.alpinelinux.org/cgit/aports/commit/main/newsbeuter?id=eb4f085009a73d1f2bd65abe5a8c86894155be23 2017-04-11 03:25:13 kaniini : reading your previous conversation, looks like there's a plan to move to llvm3.9 soon? 2017-04-11 03:26:25 s/move/add/ 2017-04-11 04:23:07 yes 2017-04-11 04:23:21 and then drop llvm (which is 3.8.1) 2017-04-11 04:23:47 so that rust and julia are built against a versioned llvm 2017-04-11 05:37:43 Good evening fabled. 2017-04-11 08:31:30 for python packages pkgs... shouldnt be python in the "depends"? 2017-04-11 08:31:36 i ask for the py-gst1 package 2017-04-11 08:34:59 xsteadfastx: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python 2017-04-11 08:35:36 but this does not include a makefile variant 2017-04-11 08:35:43 but the idea is the same. 2017-04-11 08:36:20 i just dont know... i mean py-gst1 doesnt work without gstreamer1 installed... shouldnt be all this deps if its not working else? 2017-04-11 08:36:38 yes it should 2017-04-11 08:36:49 gst1 is in testing for a reason 2017-04-11 08:37:35 i will add it and do a PR and wait for some reactions :) 2017-04-11 08:37:46 btw did you saw already the changes on snapcast i added? 2017-04-11 08:37:50 yes that would be best 2017-04-11 08:37:57 no i didnt look yet 2017-04-11 08:39:34 xsteadfastx, did you try the snapcast-server.conf? 2017-04-11 08:39:53 yes 2017-04-11 08:39:57 doesnt it work? 2017-04-11 08:40:29 it looks more like an confd file then a config file. 2017-04-11 08:40:58 thats how snapcast is doing that 2017-04-11 08:41:00 dont ask me why 2017-04-11 08:41:47 you mean to add this to /etc/conf.d/? 2017-04-11 08:41:54 im looking 2017-04-11 08:42:26 yes 2017-04-11 08:42:29 this is not how it should work 2017-04-11 08:43:12 mh ok... i rework it 2017-04-11 08:43:12 you should make that a confd file and adjust your initd to use the variables 2017-04-11 08:43:50 you should also remove the start_pre 2017-04-11 08:44:11 openrc will automatically source confd file 2017-04-11 08:44:24 when its the same name? 2017-04-11 08:44:30 correct 2017-04-11 08:45:04 so its /etc/conf.d/snapserver 2017-04-11 08:45:08 i guess you didnt try this initd yet, cause it wont work like this :) 2017-04-11 08:47:59 Shiz: I’ve built rustc with your updated patch for static-pie and with "-Wl,-(" / "-Wl,-)", but static binary still fails on panic 2017-04-11 08:48:10 the readme makes assumptions you are using it on an debian like system. 2017-04-11 08:49:02 maybe i will ditch the initd file... i tried it just running it. but i have no env to test it right now 2017-04-11 08:49:23 leave it. 2017-04-11 08:49:37 ill test it for you 2017-04-11 08:50:05 is a "snapserver.confd" that gets a /etc/conf.d/snapserver allright? 2017-04-11 08:50:57 yes its alright 2017-04-11 08:51:27 it introduces USER_OPTS and SNAPSERVER_OPTS which you can or should use in the initd 2017-04-11 08:51:57 and its get sourced by openrc? 2017-04-11 08:52:26 yes, names matching init.d and in conf.d 2017-04-11 08:53:20 Folks 2017-04-11 08:53:32 ok 2017-04-11 08:53:40 https://git.alpinelinux.org/cgit/apk-tools/tree/src/add.c 2017-04-11 08:54:04 At add.c:95 we have an apk_error() function a bad format 2017-04-11 08:54:13 *with a bad format string 2017-04-11 08:54:28 %s is given but no string is following 2017-04-11 09:10:57 clandmeter: updated my PR... but the stupid thing is... my py-gst1 changes are also in there 2017-04-11 09:11:20 you put them in the same branch? 2017-04-11 09:11:58 ah you are using master branch on your local repo 2017-04-11 09:12:02 you should use a feature branch 2017-04-11 09:12:03 ok maybe i will change that... sorry 2017-04-11 09:12:18 true... i forgot. usually i do this 2017-04-11 09:13:51 :) 2017-04-11 09:14:13 should be good not 2017-04-11 09:14:14 now 2017-04-11 09:14:16 create 2 features branches and move the specific commits to those branches 2017-04-11 09:14:23 ill check 2017-04-11 09:15:43 i see a single commit, so i guess that part is ok. 2017-04-11 09:15:53 i see you also changed to confd style 2017-04-11 09:16:06 but you are not using the conf options in confd 2017-04-11 09:16:52 SNAPSERVER_OPTS should be similar like command_args 2017-04-11 09:17:17 command_args="$SNAPSERVER_OPTS" 2017-04-11 09:18:11 actually like its desinged now it should be something like command_args="$USER_OPTS $SNAPSERVER_OPTS" 2017-04-11 09:18:14 where is the facepalm emoticon? ;-) 2017-04-11 09:19:47 what we mostly use is shells parameter expansion to set default values. 2017-04-11 09:20:22 similar like http://wiki.bash-hackers.org/syntax/pe#use_a_default_value 2017-04-11 09:22:31 so you mean i should do this for the USER_OPTS? 2017-04-11 09:24:26 yes, so without the confd it would still work. 2017-04-11 09:26:56 command_args="${USER_OPTS:-snapcast:snapcast} $SNAPSERVER_OPTS" 2017-04-11 09:26:59 like this? 2017-04-11 09:27:34 almost 2017-04-11 09:27:42 i think you are missing the --user when its not set 2017-04-11 09:29:40 almost mand_args="${USER_OPTS:---user snapcast:snapcast} $SNAPSERVER_OPTS" 2017-04-11 09:29:45 sorry 2017-04-11 09:30:40 i think that should work :) 2017-04-11 09:32:00 updated the PR 2017-04-11 09:34:59 ok ill check it 2017-04-11 09:35:13 Where can I send a pull request? 2017-04-11 09:35:17 Github? Mailing list? 2017-04-11 09:35:39 consus, github is ok, but ml also. whichever you prefer. 2017-04-11 09:35:44 okay 2017-04-11 09:37:44 Is it okay to use common compiler extensions? 2017-04-11 09:38:31 what do you mean? 2017-04-11 09:38:34 clandmeter: thanks for all your help... im learning alot 2017-04-11 09:38:50 xsteadfastx, that was the idea :) 2017-04-11 09:38:58 yeah :) 2017-04-11 09:39:01 I want to mark apk_error and other functions so gcc/clang/whatever will check the printf-like arguments 2017-04-11 09:39:35 you will have to talk to fabled 2017-04-11 09:39:50 or leave a msg in the pr/patch 2017-04-11 09:40:11 Ok 2017-04-11 10:01:23 xsteadfastx, did you try snapserver? 2017-04-11 10:18:38 xsteadfastx, updated pr. 2017-04-11 10:23:00 yes... it worked for me 2017-04-11 10:23:31 yes, it didnt for me (was still running in bg)... 2017-04-11 10:23:46 snapclient also worked fine... even through docker 2017-04-11 10:54:00 any idea why its not working? 2017-04-11 10:54:08 the initd or the command itself? 2017-04-11 11:07:29 like it said, my mistake, it was still running in the background... 2017-04-11 11:08:13 ah ok :) 2017-04-11 11:08:15 good 2017-04-11 11:21:27 xsteadfastx, are you looking at py-gst1? 2017-04-11 11:32:33 I want to find out who maintains a package. Can I do so with CLI apk tool? 2017-04-11 11:33:08 no i dont think so 2017-04-11 11:33:11 :( 2017-04-11 11:33:30 you can use pkgs.a.o 2017-04-11 11:33:35 or grep aports 2017-04-11 11:33:47 Also is there a way to froce apk to install e.g. foo-doc package when I install foo? 2017-04-11 11:33:54 yes 2017-04-11 11:33:57 How? 2017-04-11 11:34:08 its a secret 2017-04-11 11:34:24 =/ 2017-04-11 11:34:25 =\ 2017-04-11 11:34:26 i forgot which metapkg its is :) 2017-04-11 11:34:34 eh? 2017-04-11 11:35:09 I have to install some metakpg in order to ask apk to install additional packages? P_P 2017-04-11 11:35:27 the meta pkg has an install if 2017-04-11 11:35:33 Oh 2017-04-11 11:35:39 so if you add any pkg, it will pull also the doc pkg 2017-04-11 11:35:43 Nice one 2017-04-11 11:35:44 if it has one 2017-04-11 11:35:56 I was thinking about writing the exact same thing 2017-04-11 11:35:59 but i keep forgetting hwich one it is 2017-04-11 11:36:04 And started diving into apk 2017-04-11 11:36:06 And found a bug :D 2017-04-11 11:36:10 alpine-doc? 2017-04-11 11:36:16 if that even exists 2017-04-11 11:36:32 Seems likely 2017-04-11 11:36:50 Nah =/ 2017-04-11 11:36:56 heh 2017-04-11 11:37:03 > Text-based email client, friendly for novices but powerful (documentation) 2017-04-11 11:37:06 :D 2017-04-11 11:37:19 Guess what 2017-04-11 11:37:27 I think we should find out it right now 2017-04-11 11:37:31 And add it to the FAQ 2017-04-11 11:37:36 _ikke_, do youi remember which one it is? 2017-04-11 11:38:05 docs 2017-04-11 11:38:09 apk add docs :D 2017-04-11 11:38:17 YAY 2017-04-11 11:38:31 But for some reason it installs man 2017-04-11 11:38:47 Ah 2017-04-11 11:38:50 I got it 2017-04-11 11:38:52 It's a virtual 2017-04-11 11:38:55 you shoudl remove the smiley else you will pull in all smileys ;-) 2017-04-11 11:39:43 You made my day 2017-04-11 11:40:03 Alpine looks the right choice for me now :D 2017-04-11 11:40:29 I want to migrate a bunch of my internal services like cgit, smtp server and stuff like that 2017-04-11 11:40:35 From my Gentoo servers 2017-04-11 11:40:45 sounds like a fit 2017-04-11 11:40:52 Yep 2017-04-11 11:41:04 Alpine is much easier to maintain via ansible 2017-04-11 11:42:00 Though openstmpd still crashes :D 2017-04-11 11:42:13 When there will be the next release? 2017-04-11 11:42:13 from edge? 2017-04-11 11:42:20 Nah, from stable (I guess) 2017-04-11 11:42:21 3.5.2 2017-04-11 11:42:26 try edge 2017-04-11 11:42:33 Sounds like it 2017-04-11 11:42:43 Is it safe to seat on edge? 2017-04-11 11:42:45 i think it could be fixed but not applied to stable 2017-04-11 11:42:53 It was fixed, yes 2017-04-11 11:42:55 you can pin it 2017-04-11 11:43:06 check wiki for repo pinning 2017-04-11 11:43:12 Yeah already 2017-04-11 11:43:20 Sounds like a plan 2017-04-11 11:43:31 if its broken on stable it needs to be fixed 2017-04-11 11:43:43 Shiz, is it broken on stable? 2017-04-11 11:43:51 Oh yeah 2017-04-11 11:44:09 Let my try it one more time 2017-04-11 11:48:38 Oh 2017-04-11 11:48:39 Nah 2017-04-11 11:48:42 It fixed now 2017-04-11 11:51:45 Hm... Gentoo has a very badly written script, that installs webapps to /var/www. Do alpine have something like it or should I copy the files myself? 2017-04-11 11:52:38 The reason I want to do it is that cgit.cgi is not marked executable in the package (on purpose?) so I have to chmod +x it because fcgispawn will not have it any other way 2017-04-11 11:53:11 And of course chmod'ing a file owned by a package manager is pretty dumb idea 2017-04-11 11:53:51 if a program can be compiled for both gtk2 and gtk3, which one should I choose for packaging? 2017-04-11 11:54:40 Err 2017-04-11 11:54:51 Also why do I have user squid in my /etc/passwd? 2017-04-11 11:54:58 I don't have squid installed 2017-04-11 11:55:21 Or cyrus 2017-04-11 11:55:24 Or vpopmail 2017-04-11 11:55:31 Or xfs 2017-04-11 11:58:40 cat /etc/shadow 2017-04-11 11:58:59 Hm? 2017-04-11 11:59:20 oops 2017-04-11 12:09:27 clandmeter: So how about expanding FAQ? 2017-04-11 12:10:15 ? 2017-04-11 12:11:10 I think that docs is worth mentioning in the wiki 2017-04-11 12:11:23 oh that part 2017-04-11 12:11:38 yes please add it. 2017-04-11 12:11:51 Ok 2017-04-11 12:19:50 Hmmm 2017-04-11 12:20:11 I can add a package to the virtual via apk add -t foo one two 2017-04-11 12:20:17 But how do I remove e.g. one? 2017-04-11 13:18:32 Shiz: r u here? :) 2017-04-11 13:19:19 leitao : Hi, have you tried to build on x86/x86_64 ? This commit breaks newsbeuter on s390x and x86_64 for me: https://git.alpinelinux.org/cgit/aports/commit/main/newsbeuter?id=eb4f085009a73d1f2bd65abe5a8c86894155be23 2017-04-11 13:21:30 tmh1999, hum, let me check 2017-04-11 13:21:39 leitao : thanks 2017-04-11 13:25:00 clandmeter: i will add a PR 2017-04-11 13:25:14 xsteadfastx, i fixed it locally 2017-04-11 13:25:24 im cleaning up gobject now 2017-04-11 13:25:34 will push soon 2017-04-11 13:29:55 and what about the depends? 2017-04-11 13:34:57 its fixed 2017-04-11 13:35:15 was my mistake... 2017-04-11 13:35:17 ok... i just pushed my changes 2017-04-11 13:35:37 but now im in dependeny hell 2017-04-11 13:38:53 py-gst1 -> py-gobject3 -> py-cairo.... all of them dont have py3 support in aports. 2017-04-11 13:42:23 tmh1999, it seems I broke newsbeuter. Working to fix it. 2017-04-11 13:42:39 leitao : thank you 2017-04-11 13:42:53 clandmeter: Can I sent emails to the mailing list without subscription? 2017-04-11 13:43:18 idk 2017-04-11 13:43:21 :( 2017-04-11 13:43:27 but you can try 2017-04-11 13:43:32 I did 2017-04-11 13:43:35 Nothing happened 2017-04-11 13:43:40 So either it is being moderated 2017-04-11 13:43:52 Or was dumped to the /dev/null on your spam server 2017-04-11 13:43:52 xD 2017-04-11 13:44:13 clandmeter: oh noes 2017-04-11 13:45:13 Anyway, everything works fine. I was able to setup all my services on Alpine Linux. PostgreSQL configuration lives in a strange place though, but nevermind. 2017-04-11 13:49:27 i wish i had more time... else i would look into the python2 python3 stuff 2017-04-11 13:49:34 thats on the top of my list 2017-04-11 13:54:43 I’ve upgraded one of my VMs from 3.4.5 to 3.4.6 and it does not boot; I’ve reproduced it three times, checked configs, haven’t found anything wrong 2017-04-11 13:55:27 I get into syslinux menu, but right when it should start booting, it starts counting again… and again… in a loop 2017-04-11 13:55:34 anyone have a clue what may be wrong? 2017-04-11 14:08:16 Hmmm 2017-04-11 14:08:31 Is there a way to define my domain name without manually editing hosts file? 2017-04-11 14:31:48 jirutka: yeah 2017-04-11 14:32:33 clandmeter: is what broken? 2017-04-11 14:58:01 Shiz: : I’ve built rustc with your updated patch for static-pie and with "-Wl,-(" / "-Wl,-)", but static binary still fails on panic 2017-04-11 14:58:14 correct, it doesn't fix THAT issue 2017-04-11 14:58:17 it does fix however cargo working 2017-04-11 14:58:20 :) 2017-04-11 14:58:29 i've got a static-PIE cargo now that works, for instance 2017-04-11 14:58:55 Shiz: btw I’ve extended check-rustc to test panic http://tpaste.us/VbYz 2017-04-11 14:59:05 :) 2017-04-11 14:59:11 i'll give you my latest patch that includes -Wl,-) 2017-04-11 14:59:13 Shiz: aha :) I haven’t tried static cargo with that 2017-04-11 14:59:22 Shiz: I’ve already updated it :) 2017-04-11 14:59:30 http://tpaste.us/mMeV 2017-04-11 14:59:31 well i structured it a bit differently 2017-04-11 14:59:34 aha 2017-04-11 14:59:41 yeah i didn't do that :P 2017-04-11 15:00:51 https://txt.shiz.me/MTRhMjg0ND 2017-04-11 15:15:12 ncopa: I’ve upgraded one of my VMs from 3.4.5 to 3.4.6 and it does not boot; I’ve reproduced it three times, checked configs, haven’t found anything wrong; I get into syslinux menu, but right when it should start booting, it starts counting again… and again… in a loop… any idea what may be wrong? 2017-04-11 15:15:45 ncopa: it’s not the first time I hit such issue, so it looks like some bug on our side / 2017-04-11 15:15:50 ncopa: I mean in Alpine 2017-04-11 15:16:14 huh 2017-04-11 15:16:23 from 3.4.5 to 3.4.6? 2017-04-11 15:16:25 yes 2017-04-11 15:16:36 Shiz, opensmtpd 2017-04-11 15:16:54 we need to look at that :-/ 2017-04-11 15:17:07 does it help to re-run syslinux? 2017-04-11 15:17:16 ncopa: I just pushed acf-nsd repo to git.a.o. Can you please publish it? 2017-04-11 15:17:27 ncopa: I’ve copied old vmlinuz and initramfs back to /boot as .old and added that into syslinux, it boots without problem when i select the old kernel in syslinux menu 2017-04-11 15:17:46 ncopa: so it doesn’t look like a problem with syslinux itself 2017-04-11 15:18:40 sounds like kernel issu 2017-04-11 15:18:41 ncopa: maybe some unintentionally removed module? 2017-04-11 15:18:52 ncopa: it’s virtgrsec btw 2017-04-11 15:18:58 ok 2017-04-11 15:19:08 i dont have time right now 2017-04-11 15:19:12 but we should fix that 2017-04-11 15:19:19 yeah 2017-04-11 15:20:16 jirutka, why not 3.5? 2017-04-11 15:21:27 this kind of breakage should not happen anyways 2017-04-11 15:21:51 didnt we change some kernel settings at that point? 2017-04-11 15:22:04 related to efi 2017-04-11 15:22:33 clandmeter: b/c it’s a production app and I didn’t want to upgrade it to v3.5 right now, but later 2017-04-11 15:23:17 tdtrask: where did you publish it? 2017-04-11 15:23:22 in your $HOME? 2017-04-11 15:24:29 brb 2017-04-11 15:52:16 ncopa: I followed the instructions: scp -r myrepo.git git.alpinelinux.org:cgit/ 2017-04-11 16:00:20 ncopa: Oh hi! 2017-04-11 16:00:29 ncopa: I think you're the one I need :D 2017-04-11 16:01:16 ncopa: renamed /home/tdtrask/cgit/ to /home/tdtrask/acf-nsd.git/ 2017-04-11 16:01:21 tdtrask: ok 2017-04-11 16:01:28 i'll move it 2017-04-11 16:01:35 actually 2017-04-11 16:01:53 what happens if you git push git@git.alpinelinux.org:acf/acf-nsd.git ? 2017-04-11 16:02:13 consus: hi. how can i help you? 2017-04-11 16:02:44 ncopa: What is the intended way to configure ownership on /run/uwsgi? 2017-04-11 16:02:58 ncopa: It's root:root by default 2017-04-11 16:03:08 sounds liek a bug 2017-04-11 16:03:18 ncopa: Which means I'm not able to drop privs 2017-04-11 16:03:21 ncopa: from within the local non-bare repo? 2017-04-11 16:03:29 tdtrask: yes 2017-04-11 16:03:58 fatal: The remote end hung up unexpectedly 2017-04-11 16:04:06 ok, i'll move it 2017-04-11 16:04:22 ncopa: thanks 2017-04-11 16:04:32 consus: i think changing permissions in /run needs to be done from the startup script 2017-04-11 16:04:39 eg from the /etc/init.d/* script 2017-04-11 16:04:43 /etc/conf.d/then? 2017-04-11 16:04:44 ACTION thinks a post hook to create the snapshot needed too 2017-04-11 16:04:46 if it doesnt, then its probably a bug 2017-04-11 16:04:49 /etc/conf.d/uwsgi 2017-04-11 16:04:52 Well 2017-04-11 16:05:04 Gentoo has root:uwsgi 2017-04-11 16:05:13 AFAIR 2017-04-11 16:07:11 Err 2017-04-11 16:07:26 Seems like you cannot affect it via /etc/conf.d/uwsgi 2017-04-11 16:07:42 And patching /etc/init.d/uwsgi is wrong 2017-04-11 16:07:56 So... 2017-04-11 16:08:47 Ah 2017-04-11 16:08:49 You can 2017-04-11 16:08:58 It uses lowercase for some reason 2017-04-11 16:10:40 The problem is that mode is hardcoded 2017-04-11 16:10:43 0755 2017-04-11 16:10:50 So changing group doesn't help much 2017-04-11 16:11:44 consus: i think the init.d needs to be fixed 2017-04-11 16:11:50 +1 2017-04-11 16:12:00 AFAIR I was asking gentoo guys to do the same 2017-04-11 16:12:12 i'll help you in a bit 2017-04-11 16:12:17 need help tdtrask first 2017-04-11 16:12:17 mode 0775 should be pretty okay 2017-04-11 16:12:43 tdtrask: afaics, the proper way to create new git repo is via git push 2017-04-11 16:14:30 yeah 2017-04-11 16:15:25 tdtrask: http://tpaste.us/9yX4 2017-04-11 16:17:57 tdtrask: can you from your local checkout try: git push git@git.alpinelinux.org:acf/acf-nsd master 2017-04-11 16:23:41 ncopa: FWIW, 'kerneltool' can now stage kernel, modules, firmware, dtbs, and headers from a list of packages. It creates a manifest for each subset and checks the modules vermagic matches the kernel release so we shouldn't have any more problems with installing mis-matched modules. 2017-04-11 16:24:08 Finishing up some rearranging before pushing. 2017-04-11 16:24:16 ok 2017-04-11 16:24:20 soudns good 2017-04-11 16:24:43 i am still worried about how to start using it 2017-04-11 16:25:27 consus: cannot you override the user too? 2017-04-11 16:26:28 ncopa: The Emperror will not be able to create a process with another privs 2017-04-11 16:26:43 ncopa: If I'll change it's user from root to anything else 2017-04-11 16:26:43 ok 2017-04-11 16:26:49 so you need it to run as root 2017-04-11 16:26:52 ncopa: Well 2017-04-11 16:26:55 ncopa: It kinda works 2017-04-11 16:27:01 ncopa: Nothing else needs to be modified outside update-kernel & mkinitfs AFAIK. 2017-04-11 16:27:11 ncopa: I just want to store all sockets/logs in /run/uwsgi and /var/log/uwsgi 2017-04-11 16:27:17 but you need group settings of the /run/uwsgi 2017-04-11 16:27:25 makes sense 2017-04-11 16:28:13 consus: does this solve it for you? http://tpaste.us/nZNv 2017-04-11 16:28:37 It will make /var/log/uwsgi group writable 2017-04-11 16:28:40 Is it okay? 2017-04-11 16:28:50 (it works, already tested it) 2017-04-11 16:29:03 /run/uwsgi : (root:uwsgi) - 0775 2017-04-11 16:29:03 /var/log/uwsgi : (root:uwsgi) - 0755 2017-04-11 16:29:05 I suggest this 2017-04-11 16:29:15 Split checkpath in two 2017-04-11 16:29:39 do we even need the second checkpath? 2017-04-11 16:29:46 Good point 2017-04-11 16:31:06 is /var/log/uwsgi included in the apk? 2017-04-11 16:31:35 no its not 2017-04-11 16:31:37 ok 2017-04-11 16:31:40 we need it then 2017-04-11 16:31:43 Why? 2017-04-11 16:31:53 I'm not familiar with apk much 2017-04-11 16:31:57 either that or we ship the empty dir with the apk 2017-04-11 16:32:03 Aha 2017-04-11 16:32:14 i suppose we could ship an empty //var/log/uwsgi with the right permissions 2017-04-11 16:32:23 And let the user handle it 2017-04-11 16:32:25 or have it created from init.d 2017-04-11 16:32:47 the problem with shiping it with apk is that it will be reset every apk upgrade 2017-04-11 16:33:30 but i suppose group owner "uwsgi" is a good option 2017-04-11 16:33:33 isnt it? 2017-04-11 16:34:59 Yep 2017-04-11 16:35:21 Also it's funny 2017-04-11 16:35:34 drwxr-x--- 2 root uwsgi 464 Apr 9 03:10 /var/log/uwsgi 2017-04-11 16:35:44 That's my Gentoo's uwsgi log directory 2017-04-11 16:35:49 It works fine 2017-04-11 16:36:00 uwsgi child is able to create a logfile there 2017-04-11 16:36:12 In Alpine it's not with the exactly the same permissions 2017-04-11 16:36:23 huh 2017-04-11 16:36:23 Maybe it's the cgi plugin 2017-04-11 16:36:47 Or maybe it's the user/group settings through the vassals's owner/group 2017-04-11 16:37:24 uid = reviewboard 2017-04-11 16:37:25 gid = reviewboard 2017-04-11 16:37:25 chown-socket = root:nginx 2017-04-11 16:37:25 uwsgi-socket = /run/uwsgi-reviewboard.sock 2017-04-11 16:37:25 chmod-socket = 660 2017-04-11 16:37:34 I have this kind of configuration options in my gentoo box 2017-04-11 16:37:58 In alpine things handled differently 2017-04-11 16:38:10 So it's either rwxrwxr-x root:uwsgi 2017-04-11 16:38:17 Or no logs for vassals in /var/log/uwsgi =/ 2017-04-11 16:39:05 im going for this: http://tpaste.us/zbgW 2017-04-11 16:39:22 Let me check one more thing 2017-04-11 16:39:34 Maybe I will be able to find what's different 2017-04-11 16:42:52 Yeah 2017-04-11 16:42:53 Right 2017-04-11 16:42:58 It's the tyrant mode 2017-04-11 16:43:21 so 775 for /var/log/uwsgi is ok? 2017-04-11 16:43:29 In tyrant mode uwsgi drops privs to uwsgi:uwsgi 2017-04-11 16:43:38 So it's children cannot write there 2017-04-11 16:43:46 Well I guess 0775 it is 2017-04-11 16:44:04 Let me test it 2017-04-11 16:47:29 Okay 2017-04-11 16:47:30 Works 2017-04-11 16:48:11 thanks. pushed 2017-04-11 16:48:59 We could probably write it as pid_dir_mode and log_dir_mode 2017-04-11 16:49:05 But I think it's fine 2017-04-11 17:21:09 Hmm, running awk over a 42mb kernel apk takes forever :/ 2017-04-11 17:27:55 fabled: When you pop on, I could really use a few minutes of your time to straighten out apk. - Thanks! 2017-04-11 17:34:22 Currently, I'm burning nearly 3 minutes extracting the SHA1 checksums from the kernel apk to a manifest using zcat $apk | awk with a fairly simple awk script to parse the tar file and extract the headers. 2017-04-11 17:35:11 That should be a few seconds work for apk. 2017-04-11 17:36:22 ncopa: I wonder why the tyrant mode was chosen 2017-04-11 18:01:00 damn, php7-memcached@testing seems to be broken :( 2017-04-11 18:03:24 memcached.so gets placed into /usr/lib/php7/memcached.so instead of /usr/lib/php7/modules/memcached.so and even if i change the pathin within the 20_memcached.ini i still get PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php7/memcached.so' - Error relocating /usr/lib/php7/memcached.so: php_var_unserialize_init: symbol not found in Unknown on line 0 2017-04-11 18:13:36 mosez: i think you php7 from teting too 2017-04-11 18:13:39 testing* 2017-04-11 18:19:49 mosez: yes, php is completely broken now :/ 2017-04-11 18:21:03 tmh1999, I fixed the newsbeuter issue. The PR is https://github.com/alpinelinux/aports/pull/1233 2017-04-11 18:40:59 leitao : I appreciate it 2017-04-11 18:59:24 kaniini: r u here? 2017-04-11 19:08:09 ncopa: I created the repo using git push. Not sure how to add description and hook for creating snapshots. 2017-04-11 20:48:59 ncopa: oh nos :D 2017-04-11 21:17:48 $ echo 123 | sendmail root 2017-04-11 21:17:48 zsh: done echo 123 | 2017-04-11 21:17:48 zsh: segmentation fault sendmail root 2017-04-11 21:17:49 :( 2017-04-11 21:19:28 clandmeter: dunno aboutstable, but not in edge 2017-04-11 21:57:14 ncopa: have you somehow solved the second error (print_context.c)? https://gist.github.com/ncopa/2e97b2b545cf9e5511ff 2017-04-11 21:59:42 jirutka: hi 2017-04-11 21:59:45 im back :P 2017-04-11 21:59:46 Shiz: hi 2017-04-11 22:00:05 i need to find someone who knows about unwinding i guess 2017-04-11 22:00:08 Shiz: btw currently building llvm3.9, gonna switch rust from 3.8 to 3.9 2017-04-11 22:00:14 :) 2017-04-11 22:00:29 jirutka: want my cargo APKBUILD? 2017-04-11 22:00:38 i don't think it's quite ready for primetime yet, but it builds a mostly working cargo 2017-04-11 22:00:51 Shiz: the only one I know that _may_ now something about that is skarnet :/ 2017-04-11 22:01:11 i don't think skarnet is heavily into C++ runtimes, but I'll check with him 2017-04-11 22:01:51 Shiz: I’ve already updated cargo locally, but send me your apkbuld :) 2017-04-11 22:01:59 Shiz: aha, no, he’s not into C++ 2017-04-11 22:02:12 unwinding is very much a low-level C++ runtime thing 2017-04-11 22:02:14 :P 2017-04-11 22:03:58 jirutka: https://txt.shiz.me/MjY1MDhkMz 2017-04-11 22:10:02 Shiz: what about the failures in dynamically linked cargo, have any idea what may be the cause? 2017-04-11 22:10:12 vaguely 2017-04-11 22:10:18 i talked to dalias about it before 2017-04-11 22:12:58 who’s dalias? 2017-04-11 22:13:34 musl author 2017-04-11 22:13:51 aha, THAT dalias 2017-04-11 22:14:44 that failure is even more urgent, we can live without static PIE, but barely without dynamic linking :( 2017-04-11 22:16:19 :P 2017-04-11 22:18:22 jirutka: http://git.musl-libc.org/cgit/musl/commit/?id=5bf7eba213cacc4c1220627c91c28deff2ffecda 2017-04-11 22:21:28 jirutka: looks like it may be a musl bug 2017-04-11 22:21:34 re:static PIE 2017-04-11 22:21:37 aha 2017-04-11 22:21:38 not sure about the dynamic linking thing 2017-04-11 22:21:47 i know what causes it, but not entirely sure WHY 2017-04-11 22:21:49 :p 2017-04-11 22:23:26 jirutka: http://git.musl-libc.org/cgit/musl/commit/?id=5bf7eba213cacc4c1220627c91c28deff2ffecda 2017-04-11 22:24:54 i wanted to recompile musl anyway for that dynamic link issue 2017-04-11 22:24:56 so i'm happy 2017-04-11 22:29:41 Shiz: do you wanna backport http://git.musl-libc.org/cgit/musl/commit/?id=5bf7eba213cacc4c1220627c91c28deff2ffecda to our musl pkg? 2017-04-11 22:29:51 i think it's already in there 2017-04-11 22:30:00 okay 2017-04-11 22:30:09 it's another thing i think dalias is prepping 2017-04-11 22:30:18 00:19:04 dalias │ also even if AT_PHDR were set i think the code is wrong 2017-04-11 22:30:26 .. 2017-04-11 22:30:28 00:19:44 dalias │ in practice i think PT_PHDR is first so it works 2017-04-11 22:30:30 00:19:45 dalias │ but it's wrong 2017-04-11 22:30:32 00:20:11 dalias │ do you want to test a fix matching the above commit? 2017-04-11 22:30:34 00:20:24 dalias │ i think it will solve your problem 2017-04-11 22:31:35 jirutka: aha 2017-04-11 22:31:50 jirutka: i found something 2017-04-11 22:31:56 jirutka: https://github.com/rust-lang/rust/pull/40113#issuecomment-293354149 2017-04-11 22:32:39 jirutka: that should fix the dynlink issue 2017-04-11 22:32:44 i was JUST looking around liblibc trying to fix that 2017-04-11 22:32:46 :D 2017-04-11 22:33:02 I need some help debugging smtpctl segfault 2017-04-11 22:33:40 realloc(NULL, 8) produces very strange address 2017-04-11 22:34:18 I tend to think that it may be somehow related to musl 2017-04-11 22:35:04 Shiz: \o/ 2017-04-11 22:36:13 consus: testing locally, the addresses look correct to me? 2017-04-11 22:36:24 Heh 2017-04-11 22:36:27 That's the thing 2017-04-11 22:36:31 https://txt.shiz.me/ZWM4NmFjNW 2017-04-11 22:36:35 and i can write to them 2017-04-11 22:36:38 as the .c file tests 2017-04-11 22:36:43 $27 = (void *) 0xfffffffff75ceca0 2017-04-11 22:36:54 That's what realloc produces in smtpctl 2017-04-11 22:37:15 When I'm trying to reproduce it with simple realloc(NULL, 8) in my test.c everything works ok 2017-04-11 22:37:25 that looks like zero-extension 2017-04-11 22:37:48 consus: do you have the surrounding code/types? 2017-04-11 22:37:59 I do 2017-04-11 22:38:04 (just a link to the source code is fine too) 2017-04-11 22:38:09 Sec 2017-04-11 22:38:33 https://paste.pound-python.org/show/n7Dc4blOVCYFZH1xSTcy/ 2017-04-11 22:38:37 That's the high level code 2017-04-11 22:38:54 The line in question is 23 2017-04-11 22:39:42 hmm 2017-04-11 22:39:46 https://paste.pound-python.org/show/QAAskOdxgp8Ioj2tESOM/ 2017-04-11 22:39:48 reallocarray() 2017-04-11 22:40:01 is that value you posted directly returned from realloc()? 2017-04-11 22:40:06 Yes 2017-04-11 22:40:12 I traced arguments to realloc() 2017-04-11 22:40:17 It's 0x0 and 8 2017-04-11 22:40:32 size = 1, nmemb = 8 2017-04-11 22:40:32 so an address with the high bit set in x86_64 linux is a kernel address 2017-04-11 22:40:35 so it's very obviously wrong 2017-04-11 22:40:38 Yes 2017-04-11 22:40:39 but it can also be type fuckery 2017-04-11 22:40:49 It's void * 2017-04-11 22:40:49 since it matches the pattern of a typical sign extension 2017-04-11 22:40:59 As you can see 2017-04-11 22:41:19 yeah. 2017-04-11 22:41:42 okay, putting a debug printf("%p\n") 2017-04-11 22:41:51 Just to be sure that there is no some obscure gdb bug 2017-04-11 22:41:58 :P 2017-04-11 22:43:11 size = 8, nmemb = 1, optr = 0, p = 0x7ffff75ceca0 2017-04-11 22:43:13 :D 2017-04-11 22:43:16 Riight 2017-04-11 22:43:53 So there is some obscure gdb stuff 2017-04-11 22:44:07 hehehe 2017-04-11 22:44:15 Still, this memory cannot be accessed 2017-04-11 22:44:21 And I get SIGSEGV 2017-04-11 22:47:03 Stupid me 2017-04-11 22:47:44 Wait, no 2017-04-11 22:47:49 Not stupid me 2017-04-11 22:48:08 pictured: the cycle of debugging 2017-04-11 22:48:58 xD 2017-04-11 22:49:04 Well this is kinda nuts 2017-04-11 22:49:08 To be frank 2017-04-11 22:53:38 Okay, clang to the rescue 2017-04-11 22:53:44 oh? 2017-04-11 22:53:54 jirutka: care to try that patch? :) 2017-04-11 22:54:03 Shiz: yes! 2017-04-11 22:54:23 the one on github i mean btw 2017-04-11 22:56:50 Funny, it's the same address every goddamn time 2017-04-11 22:57:02 Shiz: yeah, gonna build it 2017-04-11 22:57:07 :) 2017-04-11 22:57:13 consus: that seems... odd 2017-04-11 22:57:18 Yes 2017-04-11 22:57:23 Clang not helping 2017-04-11 22:57:31 So it's not some obscure gcc bug 2017-04-11 22:58:27 and the musl source defines realloc(NULL, n) as malloc(n) 2017-04-11 22:58:32 http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n386 2017-04-11 22:58:37 so it seems like possibly corrupted malloc state 2017-04-11 22:58:39 somehow 2017-04-11 22:58:43 How? 2017-04-11 22:58:49 Any ideas? 2017-04-11 22:59:50 ok adding musl-dbg 2017-04-11 22:59:54 Let's dive into it 2017-04-11 22:59:56 :P 2017-04-11 23:00:08 i'm honestly not entirely sure, musl's malloc code is kinda black magic to me 2017-04-11 23:00:10 No sleep for me tonight 2017-04-11 23:00:16 but this 2017-04-11 23:00:18 to me 2017-04-11 23:00:24 screams "delayed result of earlier corruption" 2017-04-11 23:00:34 Likely 2017-04-11 23:00:46 Since gcc is out of the question 2017-04-11 23:00:50 in other words, the realloc() call is not the right castle you're looking for the princess for 2017-04-11 23:00:52 :P 2017-04-11 23:00:57 :D 2017-04-11 23:01:21 Someone's being naughty and ruining our heap? 2017-04-11 23:01:36 sounds like it! or something like that 2017-04-11 23:01:43 either way, the malloc state at least 2017-04-11 23:01:54 heaptrace should be my guide then 2017-04-11 23:02:07 consus: might be useful to figure out if there's a system call happening during the realloc() 2017-04-11 23:02:17 mmap() specifically 2017-04-11 23:02:38 Well first I have to understand what's going on in realloc() itself 2017-04-11 23:02:49 Maybe it's stack corruption that I can't see at this level 2017-04-11 23:02:53 right 2017-04-11 23:04:24 okay 2017-04-11 23:04:35 that's weird 2017-04-11 23:04:50 i'm in __malloc0 with size 3 2017-04-11 23:06:22 just send a signal when you want me to send down the rescue workers 2017-04-11 23:06:43 Breakpoint 2, realloc (p=0x0, n=8) at src/malloc/malloc.c:371 2017-04-11 23:06:51 Pretty much okay at this point 2017-04-11 23:06:56 right, so 2017-04-11 23:07:00 Breakpoint 3, malloc (n=8) at src/malloc/malloc.c:311 2017-04-11 23:07:04 And at this too 2017-04-11 23:07:14 So... It's heap-based corruption I guess 2017-04-11 23:07:27 it's fine to be in __malloc0 2017-04-11 23:07:36 remember 2017-04-11 23:07:45 My bad, that was some other malloc() call 2017-04-11 23:07:48 realloc() calls malloc(), not __malloc() 2017-04-11 23:07:58 malloc() is alised to __simple_malloc() is aliased to __malloc0() 2017-04-11 23:08:32 or, wait 2017-04-11 23:08:38 no, nvm 2017-04-11 23:08:50 im reading stuff wrong 2017-04-11 23:08:52 :P 2017-04-11 23:09:48 disregard that 2017-04-11 23:10:17 :D 2017-04-11 23:10:29 Well that's kinda odd 2017-04-11 23:10:43 This very code works in my productions Gentoo machines 2017-04-11 23:10:46 In openbsd 2017-04-11 23:11:03 In debian 2017-04-11 23:11:16 But gives my SIGSEGV only in Alpine 2017-04-11 23:11:17 of note is that i recently upgraded opensmtpd in edge to an actual somewhat recent version 2017-04-11 23:11:30 The test is simple 2017-04-11 23:11:36 echo 123 | sendmail root 2017-04-11 23:12:30 does that crash smtpd or sendmail? 2017-04-11 23:12:57 smtpctl that mimics sendmail 2017-04-11 23:13:05 right 2017-04-11 23:13:13 immunity:~# echo 123 | sendmail root 2017-04-11 23:13:15 Segmentation fault 2017-04-11 23:13:17 wee 2017-04-11 23:13:18 :D 2017-04-11 23:13:21 Told ya 2017-04-11 23:13:41 That's bad 2017-04-11 23:13:42 that's with the latest version in edge 2017-04-11 23:13:45 That's very very bad 2017-04-11 23:13:45 6.0.2 2017-04-11 23:14:39 yes, i agree 2017-04-11 23:15:13 So the main questions is 2017-04-11 23:15:26 How the hell musl got so fucked up it gives us the wrong address 2017-04-11 23:16:01 Okay, no mmap 2017-04-11 23:16:52 my first action would be breaking on http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n340 2017-04-11 23:17:01 and see the value of maks 2017-04-11 23:17:03 mask 2017-04-11 23:17:32 I'm downloading musl source code 2017-04-11 23:17:41 As -dbg package does not include it for some reason 2017-04-11 23:18:30 -db includes debug symbols afaik 2017-04-11 23:18:32 not the source code 2017-04-11 23:18:40 Yep 2017-04-11 23:18:57 But e.g. on centos -debug packages include source code 2017-04-11 23:19:01 Which makes sense 2017-04-11 23:19:17 Because how else I would debug the troubles? 2017-04-11 23:19:38 In Alpine musl have about 30 patches 2017-04-11 23:19:43 *has 2017-04-11 23:20:36 we typically expect the source code to be available easier online 2017-04-11 23:20:47 You have to apply all those patches 2017-04-11 23:20:59 In order to get 1:1 source <-> binary mapping 2017-04-11 23:21:24 So it's easier to just run abuild on musl lol 2017-04-11 23:28:54 Shiz: I’ve pushed llvm3.9 to testing, currently building 2017-04-11 23:29:01 :) 2017-04-11 23:29:19 Dammit, it's all optimized out 2017-04-11 23:29:54 Okay, I'm building my own musl now 2017-04-11 23:30:02 With CFLAGS='-O0 -ggdb' 2017-04-11 23:30:08 Let's party 2017-04-11 23:38:24 Shiz: So what was your idea about mask? 2017-04-11 23:49:54 Oka 2017-04-11 23:49:55 Okay 2017-04-11 23:49:58 Fucking 2017-04-11 23:49:59 Weird 2017-04-11 23:50:00 Shit 2017-04-11 23:50:15 I print the value that malloc returns 2017-04-11 23:50:17 It's okay 2017-04-11 23:50:23 I copied it 2017-04-11 23:50:36 And put it to the corrupted variable 2017-04-11 23:50:38 Guess what 2017-04-11 23:50:43 Everything works great 2017-04-11 23:50:51 So it's not heap corruption 2017-04-11 23:51:07 hmm 2017-04-11 23:51:47 https://paste.pound-python.org/show/U4FghbEGfwB3M2zHWBVp/ 2017-04-11 23:51:50 Boom, like that 2017-04-11 23:52:17 So what, stack corruption now? 2017-04-11 23:52:45 you sure that's right? 2017-04-11 23:52:58 i don't see it actually executing the line that access msg.rcpts 2017-04-11 23:53:00 Well it's not crashing anymore 2017-04-11 23:53:08 788 msg.rcpts[msg.rcpt_cnt++] = qualify_addr(addr); 2017-04-11 23:53:10 This one 2017-04-11 23:54:29 it shows the statement it's about to execute, afaik? 2017-04-11 23:54:35 next line 2017-04-11 23:54:36 (gdb) 2017-04-11 23:54:40 It was executed 2017-04-11 23:54:47 I'm waiting for input now :D 2017-04-11 23:54:48 i mean, after you enter n on that line 2017-04-11 23:54:53 it shows 2017-04-11 23:54:59 I have more 2017-04-11 23:55:01 Later 2017-04-11 23:55:06 I just didn't copy it 2017-04-11 23:55:28 788 msg.rcpts[msg.rcpt_cnt++] = qualify_addr(addr); 2017-04-11 23:55:29 (gdb) 2017-04-11 23:55:29 (gdb) c 2017-04-11 23:55:29 Breakpoint 2, malloc (n=0) at src/malloc/malloc.c:311 2017-04-11 23:55:29 311 { 2017-04-11 23:55:31 Continuing. 2017-04-11 23:55:33 Breakpoint 2, malloc (n=4294962681) at src/malloc/malloc.c:311 2017-04-11 23:55:36 311 { 2017-04-11 23:55:38 (gdb) c 2017-04-11 23:55:41 Continuing. 2017-04-11 23:55:43 Breakpoint 2, malloc (n=8589934592) at src/malloc/malloc.c:311 2017-04-11 23:55:46 311 { 2017-04-11 23:55:48 (gdb) c 2017-04-11 23:55:51 Continuing. 2017-04-11 23:57:42 ah 2017-04-11 23:58:11 yeah it seems like somehow the ret val gets sign extended... 2017-04-11 23:59:04 AHha 2017-04-11 23:59:19 But how? 2017-04-11 23:59:21 It's void * 2017-04-11 23:59:31 The max possible value in stock 2017-04-11 23:59:38 What bothers me is this 2017-04-11 23:59:51 return CHUNK_TO_MEM(c); 2017-04-11 23:59:56 #define CHUNK_TO_MEM(c) (void *)((char *)(c) + OVERHEAD) 2017-04-12 00:00:04 #define OVERHEAD (2*sizeof(size_t)) 2017-04-12 00:00:16 I used this formula to get the working address 2017-04-12 00:01:05 But the compiler can screw things up 2017-04-12 00:03:40 if it did that i think we would have issues in everything that uses malloc() in alpine 2017-04-12 00:03:48 i think it's in opensmtpd code somehow... 2017-04-12 00:04:00 Perhaps 2017-04-12 00:04:06 Then why and how =/ 2017-04-12 00:04:13 Cause code looks pretty normal to me 2017-04-12 00:04:29 I guess it's time for hardcore asm dumping shit 2017-04-12 00:06:01 https://paste.pound-python.org/show/J41EG8uBGDXTFd7Xrgot/ 2017-04-12 00:06:52 > 18 2017-04-12 00:06:52 down vote 2017-04-12 00:06:52 2017-04-12 00:06:55 cltq promotes an int to an int64 2017-04-12 00:07:10 that seems somewhat weird 2017-04-12 00:07:13 since that sounds like 2017-04-12 00:07:14 sign extension 2017-04-12 00:07:16 :P 2017-04-12 00:07:20 :D 2017-04-12 00:07:30 Oh yeaaah 2017-04-12 00:07:44 >Effect 2017-04-12 00:07:46 It sign extends 4 bytes into 8 bytes 2017-04-12 00:07:48 booya 2017-04-12 00:07:51 Yes 2017-04-12 00:07:55 The question is 2017-04-12 00:07:55 WHY 2017-04-12 00:08:00 i think i nkow why 2017-04-12 00:08:01 actually 2017-04-12 00:08:05 Huh? 2017-04-12 00:08:15 opensmtpd fails to include the correct header for reallocarray 2017-04-12 00:08:23 and thus the C compiler assumes a signature of int reallocarray(...) 2017-04-12 00:08:27 and sign-extends as necessary 2017-04-12 00:08:47 Good point 2017-04-12 00:08:50 Gonna check 2017-04-12 00:12:00 consus: ../../smtpd/util.c:599:8: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration] 2017-04-12 00:12:01 tmp = reallocarray(args->list, nalloc, sizeof(char *)); 2017-04-12 00:12:03 yayaya 2017-04-12 00:12:06 Yap 2017-04-12 00:12:11 Sound like it 2017-04-12 00:12:17 ../../smtpd/enqueue.c:783:16: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration] 2017-04-12 00:12:19 if ((nrcpts = reallocarray(msg.rcpts, 2017-04-12 00:12:21 ^~~~~~~~~~~~ 2017-04-12 00:12:23 and there's our issue 2017-04-12 00:12:29 Yes 2017-04-12 00:12:41 it's not adding -include openbsd-compat.h 2017-04-12 00:12:41 With defined prototype it works 2017-04-12 00:12:43 for some reason 2017-04-12 00:12:50 Just missed that 2017-04-12 00:12:59 I guess I should send them a patch 2017-04-12 00:13:31 hmm wait 2017-04-12 00:14:35 783 if ((nrcpts = reallocarray(msg.rcpts, 2017-04-12 00:14:36 0x0000000000005dd3 <+84>: movslq %eax,%rcx 2017-04-12 00:14:36 0x0000000000005dd6 <+87>: mov 0x23cd7b(%rip),%rax # 0x242b58 2017-04-12 00:14:38 0x0000000000005ddd <+94>: mov $0x8,%edx 2017-04-12 00:14:41 0x0000000000005de2 <+99>: mov %rcx,%rsi 2017-04-12 00:14:43 0x0000000000005de5 <+102>: mov %rax,%rdi 2017-04-12 00:14:46 0x0000000000005de8 <+105>: callq 0x2a3b3 2017-04-12 00:14:48 0x0000000000005ded <+110>: mov %rax,0x28(%rsp) 2017-04-12 00:14:51 0x0000000000005df2 <+115>: cmpq $0x0,0x28(%rsp) 2017-04-12 00:14:53 0x0000000000005df8 <+121>: jne 0x5e30 2017-04-12 00:14:56 cltq is gone 2017-04-12 00:14:59 :D 2017-04-12 00:15:01 clit queue 2017-04-12 00:15:04 sorry 2017-04-12 00:15:38 please use a pastebin for that in the future 2017-04-12 00:15:40 :p 2017-04-12 00:15:46 i'll figure out why it doesn't work 2017-04-12 00:15:58 and format a patch for the alpine package at least 2017-04-12 00:16:07 What doesn't work? 2017-04-12 00:16:13 the openbsd-compat.h include 2017-04-12 00:17:21 It's not that simple 2017-04-12 00:17:30 There is a HAVE_REALLOCARRAY macro 2017-04-12 00:17:46 yes 2017-04-12 00:17:55 i know :p 2017-04-12 00:17:57 it's from config.h 2017-04-12 00:18:05 It set to one =/ 2017-04-12 00:18:07 Strange 2017-04-12 00:19:25 yeah... 2017-04-12 00:19:34 Shiz: unfortunately it didn’t fix the bug with dynamic linking of cargo :( 2017-04-12 00:19:54 so it's just not sending the right includes 2017-04-12 00:19:57 jirutka: that is odd... 2017-04-12 00:20:03 Shiz: https://hastebin.com/raw/aracuhasar 2017-04-12 00:20:25 jirutka: it did though! 2017-04-12 00:20:31 Shiz: what? 2017-04-12 00:20:33 Shiz: I got it 2017-04-12 00:20:39 jirutka: it fixed part of it 2017-04-12 00:20:41 :) 2017-04-12 00:20:43 Shiz: includes.h does not include config.h 2017-04-12 00:20:49 consus: that's not relevant 2017-04-12 00:20:51 Shiz: then I’m blind… 2017-04-12 00:20:52 openbsd-compat.h does 2017-04-12 00:21:02 jirutka: it failed against different symbols before 2017-04-12 00:21:17 Shiz: really? it looks exactly the same from firsh sight 2017-04-12 00:21:27 the symbols you gave me before were from libc 2017-04-12 00:21:29 Shiz: no it's not 2017-04-12 00:21:29 this is not from libc 2017-04-12 00:21:35 Shiz: in latest git at least 2017-04-12 00:21:45 aha, yes 2017-04-12 00:21:47 hmm 2017-04-12 00:22:29 consus: https://github.com/OpenSMTPD/OpenSMTPD/blob/portable/openbsd-compat/includes.h#L19 2017-04-12 00:22:31 ? 2017-04-12 00:22:37 jirutka: so it seems easy to fix 2017-04-12 00:22:40 there's two more things here 2017-04-12 00:22:45 Huh 2017-04-12 00:22:46 ok 2017-04-12 00:22:48 libunwind should apparently be linked dynamically 2017-04-12 00:22:51 or not dynamically 2017-04-12 00:22:54 but without static= 2017-04-12 00:22:56 and 2017-04-12 00:23:08 jirutka: if -C prefer-dynamic is passed, it should imply -C rpath 2017-04-12 00:23:11 for alpine 2017-04-12 00:23:16 because we don't ship dupe libs in /usr/lib 2017-04-12 00:23:34 consus: the issue is that it sees reallocarray as defined 2017-04-12 00:23:39 and arc4random stuff 2017-04-12 00:23:42 Shiz: but we don’t wanna link rust libs dynamically 2017-04-12 00:23:44 which may be true 2017-04-12 00:23:48 but then it's not including the right headers 2017-04-12 00:23:55 jirutka: that's where the failures come from 2017-04-12 00:24:12 jirutka: also, we have little say in this 2017-04-12 00:24:26 we surel shouldn't dictate for our users if they want to link rust dynamically 2017-04-12 00:24:32 and those test cases are testing -C prefer-dynamic cases 2017-04-12 00:24:52 aha 2017-04-12 00:25:06 Shiz: How does it discover that you have/have not reallocarray? 2017-04-12 00:25:32 consus: configure.ac test 2017-04-12 00:25:47 jirutka: in support-dynamically-linked-musl.patch 2017-04-12 00:25:50 i think we should change this 2017-04-12 00:25:52 +#[link(name = "unwind", kind = "static", cfg(target_feature = "crt-static"))] 2017-04-12 00:25:54 +#[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] 2017-04-12 00:25:56 to 2017-04-12 00:26:00 #[link(name = "unwind")] 2017-04-12 00:26:02 and it'll be all good 2017-04-12 00:26:11 yeah, I was thinkign about this 2017-04-12 00:26:21 and then we must probably fix similar problem in all other libs… omfg, rust! 2017-04-12 00:27:31 jirutka: i don't think that many libs are hit by using target_feature = crt-static actually 2017-04-12 00:27:34 since it's pretty new 2017-04-12 00:27:45 and also not relevant to a lot of stuff 2017-04-12 00:27:53 Shiz: They changed the check 2017-04-12 00:27:57 Shiz: In later versions 2017-04-12 00:28:02 well 2017-04-12 00:28:08 i'm checking against opensmtpd 6.0.2 2017-04-12 00:28:12 which isn't the newest, but 2017-04-12 00:28:13 :P 2017-04-12 00:28:17 #if !defined(HAVE_REALLOCARRAY) || defined(LIBRESSL_VERSION_NUMBER) 2017-04-12 00:28:23 consus: do you have a commit #? 2017-04-12 00:28:43 Seems like libressl defines reallocarray already 2017-04-12 00:29:03 f948b923873a93472dea9b786cf60a3472b0ddc8 2017-04-12 00:29:10 fix compatibility with libressl 2017-04-12 00:29:17 ah right 2017-04-12 00:29:18 nice 2017-04-12 00:29:27 This avoids implicit function declarations and the resulting crashes due 2017-04-12 00:29:29 to pointer truncation. 2017-04-12 00:29:30 xD 2017-04-12 00:29:32 Dammit 2017-04-12 00:29:44 i'll add that to the 6.0.2 apkbuild 2017-04-12 00:29:55 and request for a backport to 3.5 2017-04-12 00:29:56 Just bump the whole stuff 2017-04-12 00:30:05 well, yes 2017-04-12 00:30:07 6.0.2 is the latest release 2017-04-12 00:30:18 It's clearly not being used by anyone 2017-04-12 00:30:26 ¯\_(ツ)_/¯ 2017-04-12 00:30:30 we can't ship unreleased versions 2017-04-12 00:30:31 Except for me 2017-04-12 00:30:52 > Date: Wed Jan 11 17:35:29 2017 -0600 2017-04-12 00:30:57 yes, 6.0.2 is from oct 2016 2017-04-12 00:31:00 Now I feel really stupid 2017-04-12 00:31:03 they're currently doing a big rewrite 2017-04-12 00:31:07 also jirutka small world 2017-04-12 00:31:17 Shiz: ? 2017-04-12 00:31:21 the guy who made this libressl patch is the same guy who did the initial musl dynamic support patch for rust 2017-04-12 00:31:22 :P 2017-04-12 00:31:35 wow :) 2017-04-12 00:32:28 Okay 2017-04-12 00:32:36 It was good and productive 2017-04-12 00:32:43 consus: rebuilt locally 2017-04-12 00:32:46 gonna check if it works 2017-04-12 00:33:04 It could've been much more productive if we'd care for git log's 2017-04-12 00:33:06 But well 2017-04-12 00:33:10 It's the way it is xD 2017-04-12 00:35:02 Shiz: Thank you for your help 2017-04-12 00:36:55 np 2017-04-12 00:36:57 https://txt.shiz.me/ZWYxN2I1MW 2017-04-12 00:36:59 gonna PR this to aports in a bit 2017-04-12 00:37:01 look good to you? 2017-04-12 00:37:40 / # echo 123 | sendmail root 2017-04-12 00:37:42 / # 2017-04-12 00:37:44 :) 2017-04-12 00:38:05 :D 2017-04-12 00:38:09 wat? XD 2017-04-12 00:38:13 Looks good 2017-04-12 00:38:39 How someone becomes a maintainter? 2017-04-12 00:41:49 consus: https://github.com/alpinelinux/aports/pull/1235 2017-04-12 00:41:51 :) 2017-04-12 00:42:39 consus: you step up to the ask ;) 2017-04-12 00:42:48 might be useful to contatct the current maintainer to see if they are still interested though 2017-04-12 00:42:50 s/ask/task/ 2017-04-12 00:43:17 although i'm currently semi-maintaining opensmtpd i'm not the official maintainer (and i'd be happy to offload it to you :p) 2017-04-12 00:49:43 thx jirutka :) 2017-04-12 00:49:50 Shiz: yw 2017-04-12 00:50:16 this patch probably needs a backport to 3.5 2017-04-12 00:50:22 who's in charge of those decisions? 2017-04-12 00:50:45 Shiz: opensmtpd in v3.5 is also affected, i.e. broken? 2017-04-12 00:50:50 yes 2017-04-12 00:51:01 afaik that is 2017-04-12 00:51:42 Shiz: there’s 5.9.2p1 in v3.5, could you please backport your patch to this version? 2017-04-12 00:51:59 Shiz: and open a PR against 3.5-stable 2017-04-12 00:52:14 i'll double-check first 2017-04-12 00:52:15 :) 2017-04-12 00:52:33 confirmed 2017-04-12 00:52:37 i'll backport it 2017-04-12 00:54:00 jirutka: btw, motion to move the rust pkg to llvm-libunwind 2017-04-12 00:54:04 since that is what upstream uses too 2017-04-12 00:54:08 if we haven't changed that already 2017-04-12 00:54:27 okay 2017-04-12 00:54:47 (and it's easier to debug) 2017-04-12 00:54:49 (4real) 2017-04-12 01:03:41 backporting... 2017-04-12 01:09:16 llvm3.9 landed in the testing repo 2017-04-12 01:09:20 going sleep 2017-04-12 01:09:21 gn 2017-04-12 01:10:09 Shiz: if you’d like to build rustc against llvm 3.9, just change llvm-root from /usr to /usr/lib/llvm3.9 2017-04-12 01:10:33 gotcha :) 2017-04-12 01:10:36 night! 2017-04-12 01:54:07 jirutka: the static PIE issue is resolved! 2017-04-12 01:54:20 it takes a patch to musl 2017-04-12 01:54:47 and llvm-libunwind 2017-04-12 02:08:05 beautiful work jirutka :) I have been waiting for llvm3.9 for a while 2017-04-12 03:02:25 jirutka: btw, that build failure on x86 for llvm-libunwind should be an easy fix 2017-04-12 03:35:22 oh, somebody already did llvm3.9? 2017-04-12 03:36:04 cool 2017-04-12 03:36:15 jirutka: great work on llvm3.9 :) 2017-04-12 03:36:31 jirutka: i think it can go to main 2017-04-12 03:37:03 assuming rust is good, anyway 2017-04-12 03:48:02 kaniini: we're weeding out the last stuff in rust :P 2017-04-12 03:48:09 kaniini: on that note, musl patch incoming 2017-04-12 03:48:26 give me an mbox and i will take care of it 2017-04-12 03:56:34 kaniini: https://txt.shiz.me/YmE2ZGYwZD 2017-04-12 04:45:51 jirutka: list of remaining test failures in cargo and their reason: https://txt.shiz.me/OTU3YzBmNz 2017-04-12 04:50:09 Shiz: done 2017-04-12 04:50:15 \o 2017-04-12 07:53:38 jirutka: i dont remember llvm print_context.c 2017-04-12 11:29:43 hi all 2017-04-12 11:30:32 hiya 2017-04-12 11:31:02 Guys 2017-04-12 11:31:14 How do you (auto-)test your packages? 2017-04-12 11:31:22 a good question 2017-04-12 11:31:34 a relatively new feature in edge is that APKBUILDs will define a check() function 2017-04-12 11:31:38 that performs automated tests 2017-04-12 11:31:44 Hm 2017-04-12 11:32:02 as policy, all new packages (and preferably the existing ones too) should have that check(), or explicitly opt out with features=!check 2017-04-12 11:32:17 in the future I think abuild will reject APKBUILDs that do neither 2017-04-12 11:32:29 And what check should a maintainer write for e.g. a opensmtpd? 2017-04-12 11:32:45 well, if the package has a test suite, running that would be appropriate 2017-04-12 11:32:56 I was thinking about autotesting the packages that I use daily 2017-04-12 11:32:59 also I don't think you caught my last message to you yesterday 2017-04-12 11:33:09 Shiz │ consus: you step up to the ask ;) 2017-04-12 11:33:10 Like setting up a VM that will grab new stuff and test it for me 2017-04-12 11:33:11 Shiz │ might be useful to contatct the current maintainer to see if they are still interested though 2017-04-12 11:33:13 Shiz │ s/ask/task/ 2017-04-12 11:33:15 Shiz │ although i'm currently semi-maintaining opensmtpd i'm not the official maintainer (and i'd be happy to offload it to you :p) 2017-04-12 11:33:36 Oh, nice 2017-04-12 11:33:40 Much easier than Gentoo 2017-04-12 11:33:50 With all that insane interview crap 2017-04-12 11:33:57 i would recommend getting approval from the existing maintainer 2017-04-12 11:34:01 Of course 2017-04-12 11:34:09 consus: well, with alpine being a maintainer doesn't mean you have commit access 2017-04-12 11:34:13 so it's a bit different from Gentoo 2017-04-12 11:34:22 you still have to get your updates through github PRs with peer review 2017-04-12 11:34:24 :p 2017-04-12 11:34:26 Being maintainter in Gentoo doesn't mean that too 2017-04-12 11:34:29 ah 2017-04-12 11:34:35 i thought it did 2017-04-12 11:34:36 Proxy-maint 2017-04-12 11:34:38 And stuff 2017-04-12 11:34:51 I was trying to become a full-blown developer 2017-04-12 11:35:08 The fact is -- those guys are really touchy 2017-04-12 11:35:27 eh, I can see why they would need to 2017-04-12 11:35:40 it's also something that kinda changes with project scale -- at some point it's hard to keep tabs on everybody 2017-04-12 11:35:50 I mean I was literally banned from IRC for cursing about some stuff during my debug session 2017-04-12 11:35:50 not sure if that's the approach Alpine will take, but I can see some reasons why they would do it 2017-04-12 11:35:56 heh 2017-04-12 11:36:06 Yeah 2017-04-12 11:36:12 ah so we know what to expect :p 2017-04-12 11:36:15 :D 2017-04-12 11:36:20 Hey, I'm a nice guy 2017-04-12 11:36:38 when all goes well ;-) 2017-04-12 11:36:38 <^7heo> So you're a terrible person? 2017-04-12 11:36:59 I just something use the f word during the late-night attempt to fix some crashing app 2017-04-12 11:37:07 *sometimes 2017-04-12 11:37:08 ^7heo, we dont want to remove your title. 2017-04-12 11:37:08 <^7heo> (When people communicate about themselves, they usually communicate only to hide their flaws/shortcomings) 2017-04-12 11:37:20 <^7heo> clandmeter: I'm totally okay when I have eaten. 2017-04-12 11:37:28 ^7heo: +1 2017-04-12 11:37:36 <^7heo> consus: about which part? 2017-04-12 11:37:42 About the food 2017-04-12 11:37:44 <^7heo> ah yeah 2017-04-12 11:37:51 <^7heo> Well, that's the pyramid of needs 2017-04-12 11:37:58 <^7heo> Maslov's pyramid or whatnot. 2017-04-12 11:38:01 For sure 2017-04-12 11:38:26 Shiz: So there is no some adopted autotesting toolset that you guys have, right? 2017-04-12 11:38:28 <^7heo> the 1# guideline to social life. 2017-04-12 11:38:50 consus: not as i know it, but I'm not intimately familiar with Alpine's infra 2017-04-12 11:39:00 I just create and edit APKBUILDs, mostly 2017-04-12 11:39:04 maybe clandmeter knows more definitively 2017-04-12 11:39:06 :) 2017-04-12 11:39:06 Got it, I'll ask around 2017-04-12 11:39:12 <^7heo> and our society is kinda perverted about the priority according to that hierarchy of needs; but le'ts talk about that on -offtopic instead. 2017-04-12 11:39:24 <^7heo> consus: you're not there btw. 2017-04-12 11:39:33 (don't go to -offtopic) 2017-04-12 11:40:07 Shiz: So how long it will took the 6.x opensmtpd to go through all the necessary step to 3.5.x? 2017-04-12 11:40:26 consus: i don't think 6.0.2 is going to land in 3.5 2017-04-12 11:40:31 i backported the crash patch to 3.5 though 2017-04-12 11:40:31 =/ 2017-04-12 11:40:33 Oh 2017-04-12 11:40:35 Okay 2017-04-12 11:40:37 So how long? 2017-04-12 11:40:41 uhm 2017-04-12 11:40:49 when someone merges my PR and then when a new point release of 3.5 is made 2017-04-12 11:40:51 :P 2017-04-12 11:40:53 until check() it was up to the maintainer to manually verify the aport. 2017-04-12 11:40:59 Wow 2017-04-12 11:41:02 It's a long run 2017-04-12 11:41:13 https://github.com/alpinelinux/aports/pull/1236 2017-04-12 11:41:18 this is the backport PR if you're interested in tracking it 2017-04-12 11:41:26 I suspect jirutka will merge it today for me 2017-04-12 11:41:28 :P 2017-04-12 11:41:29 Okay, I can use aports of course 2017-04-12 11:41:44 as for point releases, i have honestly no idea when those are made 2017-04-12 11:41:58 Hmm 2017-04-12 11:42:00 clandmeter: is it right that point releases only matter to ISO distributions or am I wrong there? 2017-04-12 11:42:10 as in, stable will always get what's new in the 3.x-stable branch in aports 2017-04-12 11:42:12 So the repo is fixed in time or what? 2017-04-12 11:42:16 Ah 2017-04-12 11:42:18 consus: that's what I'm asking clandmeter 2017-04-12 11:42:20 :P 2017-04-12 11:42:38 I guess so 2017-04-12 11:43:07 my (maybe wrong) interpretation is that edge gets branched off to 3.x-stable for a 3.x release, and that the repo mirrors are always up-to=date with that branch 2017-04-12 11:43:08 How else whould you land security fixes fast? 2017-04-12 11:43:18 and that point releases only matter for the .isos on the site 2017-04-12 11:43:36 E.g. in case of another heartbleed you should act as fast as you can 2017-04-12 11:43:40 yup 2017-04-12 11:43:56 And waiting for a point release in that case would be a huge design drawback 2017-04-12 11:43:56 so in that case it would be whenever my PR is merged and the buildbots are done with it 2017-04-12 11:43:58 :) 2017-04-12 11:43:59 we generate our iso/tarballs from tags in stable repo 2017-04-12 11:44:23 err stable branch 2017-04-12 11:44:28 clandmeter: right, but the apk repo? 2017-04-12 11:44:35 like, dl-cdn etc 2017-04-12 11:44:46 the ones users use to get packages on an installed system :P 2017-04-12 11:44:59 it follows the branch? 2017-04-12 11:45:00 clandmeter: My point is -- can I receive critical updates on openstmtpd before the next point release? 2017-04-12 11:45:04 right 2017-04-12 11:45:07 clandmeter: Through the regular channesl 2017-04-12 11:45:08 clandmeter: that was my question 2017-04-12 11:45:11 clandmeter: And not aports 2017-04-12 11:45:21 so whenever my PR is merged, it will be available for 3.5 users once the buildbots are done, right? 2017-04-12 11:46:00 the pr's are against master 2017-04-12 11:46:10 It's against 3.5-stable 2017-04-12 11:46:10 no 2017-04-12 11:46:13 https://github.com/alpinelinux/aports/pull/1236 2017-04-12 11:46:13 my PR is against 3.5-stable 2017-04-12 11:46:15 :P 2017-04-12 11:46:25 it's a backport of a fix in master 2017-04-12 11:46:28 that already got merged 2017-04-12 11:46:49 ah right 2017-04-12 11:46:58 yes that will get into 3.5 repo 2017-04-12 11:47:06 :) 2017-04-12 11:47:45 =/ 2017-04-12 11:47:52 consus: ? 2017-04-12 11:47:58 zsh has wrong PS1 2017-04-12 11:48:07 Due to sourcing /etc/profile and not defining it's own 2017-04-12 11:48:24 'wrong'? 2017-04-12 11:48:30 \h:\w$ 2017-04-12 11:48:37 It's not expanded in zsh 2017-04-12 11:48:42 Because it has no meaning 2017-04-12 11:48:51 For zsh 2017-04-12 11:49:15 ah 2017-04-12 11:50:54 Shiz, i think thats the first time ive seen a PR against stable branch. 2017-04-12 11:51:03 that's what jirutka told me to do 2017-04-12 11:51:28 clandmeter: that’s quite possible :) 2017-04-12 11:51:31 the patch required manual adjustments so it couldn't be trivially cherry-picked from edge 2017-04-12 11:51:32 jirutka: For the love of god, push it! :) 2017-04-12 11:51:33 clandmeter: it’s a backport 2017-04-12 11:51:39 and travis runs on edge, but maybe jirutka changed something? 2017-04-12 11:52:14 clandmeter: no, still runs on edge, but that doesn’t matter, I just needed a patch and not a fan of sending patches via email ;) 2017-04-12 11:53:20 btw 2017-04-12 11:53:32 https://github.com/alpinelinux/aports/pull/1204 2017-04-12 11:53:36 this PR now LGTM 2017-04-12 12:06:14 consus: and it's merged 2017-04-12 12:06:31 so when the buildbots are done, it'll be in your local 3.5 2017-04-12 12:08:02 jirutka: did you see my messages from last night? 2017-04-12 12:08:30 Shiz: ^^ 2017-04-12 12:09:25 clandmeter: Shiz what msg? 2017-04-12 12:09:34 Shiz │ jirutka: the static PIE issue is resolved! 2017-04-12 12:09:36 Shiz │ it takes a patch to musl 2017-04-12 12:09:38 Shiz │ and llvm-libunwind 2017-04-12 12:09:40 Shiz │ jirutka: btw, that build failure on x86 for llvm-libunwind should be an easy fix 2017-04-12 12:09:42 Shiz │ jirutka: list of remaining test failures in cargo and their reason: https://txt.shiz.me/OTU3YzBmNz 2017-04-12 12:09:57 Shiz: wow! that’s awesome! \o/ \o/ 2017-04-12 12:10:05 Shiz: you’re our hero! 2017-04-12 12:10:37 :p now now 2017-04-12 12:12:09 Yay! 2017-04-12 12:12:12 smtp is working! 2017-04-12 12:13:05 :) 2017-04-12 12:21:02 Shiz: I’ve pushed updated rust and cargo to testing 2017-04-12 12:21:27 and go to lunch now 2017-04-12 12:22:48 Hmm 2017-04-12 12:22:54 Who creates /var/mail symlink? 2017-04-12 12:22:56 What package? 2017-04-12 12:23:43 could please someone verify if mesa (https://pkgs.alpinelinux.org/package/edge/main/x86_64/mesa) is compatible with llvm 3.9 and try to build it against it? 2017-04-12 12:23:58 and also afl (https://pkgs.alpinelinux.org/package/edge/testing/x86_64/afl) 2017-04-12 12:24:35 so we can eventually get rid of llvm 3.8 2017-04-12 12:24:41 afk 2017-04-12 12:24:52 Shiz: A sidenote 2017-04-12 12:25:05 Shiz: OpenSMTPD fails to deliver to mailbox if /var/mail does not exist 2017-04-12 12:26:10 It may be a good idea to add /var/mail -> /var/spool/mail 2017-04-12 12:26:21 Either to the opensmtpd or to the base layout 2017-04-12 12:26:49 Since mailx and other tools will look there for mboxes 2017-04-12 12:27:42 $ strace mail 2>&1 | grep /var 2017-04-12 12:27:42 open("/var/mail/root", O_RDONLY) 2017-04-12 12:27:43 E.g. 2017-04-12 12:28:31 clandmeter: Who maintains the base layout in Alpine? 2017-04-12 12:29:02 <^7heo> ncopa, clandmeter, fabled, and a few others. 2017-04-12 12:29:13 I have a proposition, where to send? 2017-04-12 12:29:33 our ml 2017-04-12 12:29:56 http://bugs.alpinelinux.org/issues/5091 2017-04-12 12:29:56 Ah 2017-04-12 12:29:59 There is already one 2017-04-12 12:30:19 http://bugs.alpinelinux.org/issues/5604 2017-04-12 12:30:21 And this 2017-04-12 12:30:39 Target versions set to 3.6 =/ 2017-04-12 14:05:09 Shiz: you’ve said that llvm-libunwind’s build failure on x86 can be easily fixed… how? -fno-stack-protector? 2017-04-12 14:30:36 Seems like /etc/init.d/hostname ignores /etc/conf.d/hostname 2017-04-12 14:30:51 How about removing /etc/conf.d/hostname? 2017-04-12 14:31:31 consus: /etc/conf.d/hostname is for /etc/init.d/hostname 2017-04-12 14:31:49 jirutka: look at the /etc/init.d/hostname 2017-04-12 14:31:56 consus: I did it 2017-04-12 14:31:59 jirutka: it does not use the provided variable 2017-04-12 14:32:09 jirutka: it looks at /etc/hostname 2017-04-12 14:32:11 consus: aha, right 2017-04-12 14:32:23 consus: yes, then we should remove conf.d/hostname, good point! 2017-04-12 14:32:28 :) 2017-04-12 14:44:46 Should I file a bug or something? 2017-04-12 15:46:19 clandmeter: so now im back. what you wrote about the circular dependencies for snapcast 2017-04-12 15:46:37 but what if someone wants to install both through apk add snapcast 2017-04-12 15:46:43 thats wouldnt work no more 2017-04-12 15:46:50 its no meta package no more 2017-04-12 15:53:19 recovered 2017-04-12 15:53:25 jirutka: no, that'd just be a hack 2017-04-12 15:53:27 :P 2017-04-12 15:53:38 Shiz: okay, so how? :) 2017-04-12 15:53:44 jirutka: do you have an x86 builder i could access? 2017-04-12 15:53:47 i don't have one myself : 2017-04-12 15:53:48 ( 2017-04-12 15:54:03 jirutka: it's not linking in -lssp_nonshared because of -nodefaultlibs i think 2017-04-12 15:54:10 Shiz: no, I haven’t seen x86-only machine for more than 10 years… 2017-04-12 15:54:12 and it should 2017-04-12 15:56:32 *LOL* I'm using an x86 only machine for my daily use still browsing on windoze. It's painful, but I'm stuck with it because of some proprietary crap I need to support. 2017-04-12 16:37:48 time to boot an x86 iso 2017-04-12 16:52:23 lol 2017-04-12 16:52:31 i can't compile libunwind because the x86 builder is MIA 2017-04-12 16:52:33 cc jirutka 2017-04-12 16:53:30 (for the llvm3.9 dep) 2017-04-12 16:55:09 libunwind doesn't build unpatched on x86_32 last I checked, it needs some fluffing first 2017-04-12 16:55:17 awilfox: i already fixed the issue 2017-04-12 16:55:19 :) 2017-04-12 16:55:21 just now 2017-04-12 16:55:23 I have an x86_32 builder here, but it's an adelie builder, not alpine one 2017-04-12 16:55:39 Shiz: oh nice! let me know when the patch is published, it'd be very helpful :3 2017-04-12 16:56:51 xsteadfastx, check https://github.com/alpinelinux/aports/blob/c0722a089a60fe9b1e957735939774a1cf6ba4f9/testing/snapcast/APKBUILD 2017-04-12 16:59:08 so fr some reason -DCMAKE_SHARED_LINKER_FLAGS isn't working... 2017-04-12 17:00:13 So you did it by yourself? 2017-04-12 17:00:44 And an empty depends does what? 2017-04-12 17:05:30 Unset the main deps 2017-04-12 17:05:50 Shiz: MIA? 2017-04-12 17:06:19 Missing in action? 2017-04-12 17:06:34 aha :) 2017-04-12 17:07:02 Shiz: maybe it prioritizes flags with release_type suffix 2017-04-12 17:07:11 That's a band from the 90 2017-04-12 17:07:22 Shiz: something like CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL ? 2017-04-12 17:07:36 i'll try that 2017-04-12 17:08:18 Shiz: this is probably wrong, run cmake -LAH and see what flags are there 2017-04-12 17:08:28 sadly no cigar 2017-04-12 17:08:28 I don’t remember all these crazy cmake flags from head :) 2017-04-12 17:08:34 cigar? 2017-04-12 17:08:54 https://en.wiktionary.org/wiki/close,_but_no_cigar 2017-04-12 17:08:56 :P 2017-04-12 17:09:10 heh 2017-04-12 17:09:33 I don't get it. So if I install snapcast-client... How does the package know to install the meta main package? 2017-04-12 17:09:47 so the flag is there 2017-04-12 17:09:50 i guess it's just not used... 2017-04-12 17:10:07 xsteadfastx: it doesn't and it shouldn't 2017-04-12 17:10:10 it's the other way around 2017-04-12 17:10:10 It's different now 2017-04-12 17:10:18 when you install the meta package it installs both -server and -client 2017-04-12 17:11:03 So no seperation 2017-04-12 17:11:06 I'm on mobile now... Difficult to type... 2017-04-12 17:11:15 Me too 2017-04-12 17:11:46 The subpkg will now install the user 2017-04-12 17:12:08 install the user? we have scripts to install our users now? wow! :) 2017-04-12 17:12:12 So no need for main PKG to do that, so no reason to pull it in 2017-04-12 17:12:25 but I’d more appreciate the script to uninstall the user :) 2017-04-12 17:12:30 xsteadfastx: it's like this 2017-04-12 17:12:40 you can install snapcast, which will install both the server and client 2017-04-12 17:12:46 or you can install snapcast-server and snapcast-client separately 2017-04-12 17:12:50 that's the idea 2017-04-12 17:13:30 Your version would introduce circular deps 2017-04-12 17:13:40 We try to prevent that 2017-04-12 17:14:03 clandmeter: circular dep between origin and subpkgs? 2017-04-12 17:14:17 Yes 2017-04-12 17:14:32 clandmeter: then it’s more a bug (or missing feature) in abuild imo… 2017-04-12 17:14:43 clandmeter: we can/should handle this situation 2017-04-12 17:14:53 clandmeter: also I’ve already used this few times and no problem so far o.O 2017-04-12 17:14:59 circular deps? 2017-04-12 17:16:39 Ncopa, save me with your keyboard :-) 2017-04-12 17:17:56 ACTION slaps clandmeter with the keyboard 2017-04-12 17:18:04 feel better? 2017-04-12 17:18:11 Yes 2017-04-12 17:18:17 <^7heo> #alpine-bdsm 2017-04-12 17:18:18 :) 2017-04-12 17:18:38 <^7heo> that would go well along with skarnet's #alpine-fantaisies suggestion. 2017-04-12 17:19:27 jirutka: you could use `pushd gcc; abuild` if you want to uninstall a user from a laptop at least 2017-04-12 17:19:46 not sure about desktops, they don't usually cause third degree burns while building a compiler 2017-04-12 17:20:38 jirutka: success! 2017-04-12 17:20:39 what? :) 2017-04-12 17:21:55 clandmeter: actually, I’m quite sure that it does not cause any problem, I’ve used it even in rust pkg 2017-04-12 17:23:33 jirutka: https://txt.shiz.me/NDE2MDI3OT 2017-04-12 17:23:47 this patch is against llvm-libunwind 3.8 since i can't build 3.9 on x86 (because no llvm3.9 because missing builder) 2017-04-12 17:23:53 but i think it should work for 3.9 too 2017-04-12 17:24:40 Shiz: nice! 2017-04-12 17:28:31 Shiz: the resulting binaries are exactly the same on x86_64 :) 2017-04-12 17:28:39 :) 2017-04-12 17:28:50 it just removes some nonsense 2017-04-12 17:28:55 not sure why they use -nodefaultlibs at all 2017-04-12 17:29:03 it just makes you vulnerable to deviating compilers (like ours) 2017-04-12 17:29:14 because they're just re-adding the implicit deps manually... 2017-04-12 17:31:52 jirutka: btw can you look at pr 1204? 2017-04-12 17:32:00 https://github.com/alpinelinux/aports/pull/1204 2017-04-12 17:32:18 not now, later 2017-04-12 17:33:05 \o 2017-04-12 19:12:19 gromero, have you ever heard about pt_regs redefinition ? 2017-04-12 19:12:33 /usr/include/bits/user.h:1:8: error: redefinition of 'struct pt_regs' 2017-04-12 19:12:33 and 2017-04-12 19:12:38 /usr/include/asm/ptrace.h:31:8: note: originally defined here 2017-04-12 19:18:46 ah yes, a classic 2017-04-12 19:22:22 Shiz, what would you recommend? 2017-04-12 19:22:31 one pt_regs come from the kernel 2017-04-12 19:22:32 package compilation error? 2017-04-12 19:22:37 the other one from musl-dev 2017-04-12 19:22:37 yes 2017-04-12 19:22:47 http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/psmisc/psmisc-22.21-r2.log 2017-04-12 19:23:34 yeah it's because the kernel headers don't particularly interact nicely with the userspace headers 2017-04-12 19:23:41 it's being worked on upstream, but in the meantime you can hac karound it 2017-04-12 19:24:03 i see something like this used elsewhere: 2017-04-12 19:24:35 https://txt.shiz.me/ODM0MDRiMG 2017-04-12 19:24:47 keeping in mind that its a rather ugly hack until kernel upstream fixes their stuff 2017-04-12 19:26:23 Shiz, nice, let me try it 2017-04-12 19:33:26 Shiz, why would #define pt_regs uapi_pt_regs avoid the naming clash? 2017-04-12 19:34:15 leitao: when the kernel header file does struct pt_regs { ... } 2017-04-12 19:34:22 it will be expanded to struct uapi_pt_regs { ... } 2017-04-12 19:34:25 thus avoiding the clash 2017-04-12 19:36:20 makes sense. 2017-04-12 19:36:20 " ah yes, a classic" yes, it is 2017-04-12 19:36:32 for instance: strace: ah yes, a classic 2017-04-12 19:36:37 sorry: https://github.com/alpinelinux/aports/commit/70e8624cec8394b1517a6a0dcba72bbb0c9b9e74 2017-04-12 19:36:57 i see that works around it in a different way 2017-04-12 19:36:58 leitao: so just workaround at the moment... 2017-04-12 19:37:23 yeah 2017-04-12 19:37:27 there's upstream work to fix it though 2017-04-12 19:37:29 or at least, a discussion 2017-04-12 19:37:38 dalias sparked one on the kernel ML i think 2017-04-12 19:37:56 Shiz: recently or that one: http://www.openwall.com/lists/musl/2016/12/30/5 2017-04-12 19:38:16 gromero: kernel ML, not musl ML 2017-04-12 19:38:18 :P 2017-04-12 19:38:31 Shiz: ah, ok 2017-04-12 19:38:52 Shiz: reading too fast... 2017-04-12 19:38:55 i think it was at least somewhere this year 2017-04-12 19:39:01 forget exactly when, don't have a link handy either 2017-04-12 19:39:40 Shiz: ok. I talked to him a couple of weeks ago a he said there is no solution at the moment, just workarounds... 2017-04-12 19:39:52 yeah, as of right now, sadly not 2017-04-12 19:39:52 *and he said 2017-04-12 19:39:57 but there's hope, maybe.... 2017-04-12 19:39:58 yep... 2017-04-12 19:40:04 hope for the future 2017-04-12 19:40:33 I *do* really hope for the future :) 2017-04-12 19:47:22 jirutka: ping? 2017-04-12 20:28:13 Shiz: pong 2017-04-12 20:28:36 got a patch for rust for you 2017-04-12 20:28:45 Shiz: great! 2017-04-12 20:28:58 also 2017-04-12 20:29:08 the remaining cargo failures are a logical result of creating a dylib on crt-static 2017-04-12 20:29:13 of courrse that won't work 2017-04-12 20:31:06 jirutka: https://txt.shiz.me/Y2NjMzFmZT 2017-04-12 20:31:59 Shiz: why you’ve removed llvm-dev? o.O 2017-04-12 20:32:06 it's already in depends= 2017-04-12 20:32:21 i removed llvm-libunwind-dev that is 2017-04-12 20:32:23 not llvm-dev 2017-04-12 20:33:26 no, see your patch… 2017-04-12 20:33:46 you’ve removed llvm$_llvmver-dev from makedepends 2017-04-12 20:33:56 aha, pardon 2017-04-12 20:34:10 too tired… 2017-04-12 20:34:16 :P 2017-04-12 20:34:38 I’ll rather apply it and examine in terminal 2017-04-12 20:37:40 aand now I see it better; yes it’s okay, sorry for false negative :) 2017-04-12 20:38:39 i'm going to make an internals.rust-lang.org post about CRT-static semantics 2017-04-12 20:39:20 Shiz: is this patch ”only” quality improvement or does it solve some bug? 2017-04-12 20:40:00 it solves a bug 2017-04-12 20:40:08 specifically, libunwind being linked wrongly possibly 2017-04-12 20:40:32 and it simplifies the patch even too 2017-04-12 20:40:37 where/how does this bug manifest? 2017-04-12 20:40:43 I see that it simplifies it :) 2017-04-12 20:40:53 does anyone ever got "sh -x /usr/bin/abuild -r" working but "/usr/bin/abuild -r" not working? 2017-04-12 20:40:55 there were some cargo build errors 2017-04-12 20:41:09 of linking against libunwind symbols 2017-04-12 20:41:14 err 2017-04-12 20:41:15 not build 2017-04-12 20:41:17 test errors 2017-04-12 20:41:28 ah, these errors 2017-04-12 20:41:30 great! 2017-04-12 20:41:48 so the rest build errors in static and dynamic cargo are only incompatible tests? 2017-04-12 20:42:07 do you mean those as two things or one thing? 2017-04-12 20:42:27 as two 2017-04-12 20:42:37 there are some failures for both static and dynamic 2017-04-12 20:42:40 oh? 2017-04-12 20:42:44 oh right 2017-04-12 20:42:46 the -lstd thing 2017-04-12 20:42:52 yes, exactly 2017-04-12 20:42:56 aha, but I know why this 2017-04-12 20:43:02 right, rpath. 2017-04-12 20:43:10 it’s because we don’t have rust libs on ld path 2017-04-12 20:43:11 jirutka: we probably need to make -C rpath default 2017-04-12 20:43:13 with that patch too 2017-04-12 20:43:23 should be easy enough 2017-04-12 20:43:25 yeah, that’d be perfect 2017-04-12 20:45:47 btw I was thinking about your idea to change default linking to dynamic on Alpine… I’ve changed my mind; it’s a compiler after all, we (and even other distros) already change some default settings for gcc and clang 2017-04-12 20:45:56 :) 2017-04-12 20:46:13 if people want static linking, they can simply pass RUSTFLAGS='-C target-feature=+crt-static' to cargo 2017-04-12 20:46:16 which is easy enough 2017-04-12 20:46:29 and also our static is not “standard” as well, b/c we use PIE :) 2017-04-12 20:46:38 (making it even better!) 2017-04-12 20:46:42 yes 2017-04-12 20:46:52 after the uhm 2017-04-12 20:46:55 yes, but it’s also quite distro-specific, b/c -C target-feature is not normally allowed in stable rustc 2017-04-12 20:46:55 musl bugfix 2017-04-12 20:46:59 ACTION whistles and crabwalks away 2017-04-12 20:47:40 jirutka: one thing i want to address in my internals.r-l.org post is whether crt-static will be stabilized or not 2017-04-12 20:47:41 well, this was the only one problem on the musl side, all others were on Rust side (or ours, libunwind…) 2017-04-12 20:48:15 dalias was very helpful in finding the bug btw :P 2017-04-12 20:48:39 Shiz: Alex wrote in the RFC for crt-static that it will be never stabilized, but don’t understand why… 2017-04-12 20:48:49 no no 2017-04-12 20:48:56 that's not what wasn't going to be stabilized 2017-04-12 20:49:03 #[link(cfg(...))] isn't 2017-04-12 20:49:35 but it says nothinga bout the crt-static target-feature satbilisation 2017-04-12 20:49:37 stabilisation. 2017-04-12 20:49:45 aha, yes, you’re right 2017-04-12 20:49:56 I’ve read it once more time https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md 2017-04-12 20:52:37 Shiz: will you also write some summary to https://github.com/rust-lang/rust/pull/40113 ? 2017-04-12 20:53:02 I will write it as background, yes 2017-04-12 21:02:28 Shiz: hm, but how rpath in rust works? I’m afraid that it will use rpath even for non-rust libs 2017-04-12 21:02:38 i don't think it will 2017-04-12 21:02:47 and if it does, does it matter? :P 2017-04-12 21:03:46 well, as with other software, when the shared lib is on standard path, then rpath should not be used 2017-04-12 21:03:54 will try that 2017-04-12 21:06:11 Shiz: it looks okay https://hastebin.com/raw/amomekazod 2017-04-12 21:06:24 :) 2017-04-12 21:06:40 jirutka: i think it should only enable rpath when doing -C prefer-dynamic... 2017-04-12 21:07:03 Shiz: yes, that would be logical… but not how it works now :/ 2017-04-12 21:07:16 Shiz: however, this should not harm, or does it? 2017-04-12 21:08:56 Shiz: but it seems that there’s no config option in Cargo to enable rpath by default, so it will require patching it anyway, so we can also add a logic to use it by default only in combination with prefer-dynamic 2017-04-12 21:09:08 Shiz: but not entirely sure if this should be patched in cargo or rustc 2017-04-12 21:09:24 rustc, evidently 2017-04-12 21:10:32 but then user would not be able to disable it, right? 2017-04-12 21:10:49 or is there some option opposite to -C rpath? 2017-04-12 21:11:15 btw Cargo allows to set defaults via profiles and this includes even rpath; but it seems that the default profile is hard-coded 2017-04-12 21:11:33 hehe 2017-04-12 21:11:43 well, i'm not sure if it's reasonable for the user to disable it 2017-04-12 21:11:51 if it's implied by -C prefer-dynamic, it HAS to have rpath to even work at all 2017-04-12 21:11:57 since libstd is in the rustlib folder 2017-04-12 21:12:03 hm, right 2017-04-12 21:12:24 and rustlibs does not have stable ABI, so it will not be usable on other system anyway 2017-04-12 21:12:33 s/does/do/ 2017-04-12 21:13:08 well, maybe theoretically on the same version, but still, it’s quite useless 2017-04-12 21:14:50 and actually only compiler plugins use prefer-dynamic 2017-04-12 21:19:51 jirutka: possible for you to push that patch I linked if you approve of it? 2017-04-12 21:19:59 I want to include it in my patch overview in the internals post 2017-04-12 21:20:19 yes, ofc, I just wanted to enable rpath by default together with that 2017-04-12 21:20:27 I think that this https://github.com/rust-lang/rust/blob/master/src/librustc_trans/back/linker.rs#L275 may be the right place 2017-04-12 21:20:46 hmm? 2017-04-12 21:20:52 rpaths are not just for dylibs 2017-04-12 21:20:56 they are for final dynamic executables too 2017-04-12 21:21:02 eh, right 2017-04-12 21:21:10 also this seems too low-level 2017-04-12 21:21:23 i think you should simply check if the prefer-dynamic codegen option is set and then also set rpath 2017-04-12 21:21:30 wherever codegen options are processed 2017-04-12 21:23:01 yes, but the question is where to put this 2017-04-12 21:25:36 okay, this looks like the code that really adds rpath to args https://github.com/rust-lang/rust/blob/910c4816fdee01a1299d11a5e85ebb4aceee6d1a/src/librustc_trans/back/link.rs#L985 2017-04-12 21:26:08 hm, maybe not 2017-04-12 21:26:28 jirutka: https://github.com/rust-lang/rust/blob/da32752d92589e99feab80921b9eecb6090cf310/src/librustc/session/config.rs#L1433 2017-04-12 21:26:30 after here. 2017-04-12 21:26:46 https://github.com/rust-lang/rust/blob/da32752d92589e99feab80921b9eecb6090cf310/src/librustc/session/config.rs#L1526 2017-04-12 21:26:48 i'd put it here 2017-04-12 21:28:09 if cg.prefer_dynamic { 2017-04-12 21:28:11 // Force rpath addition on prefer-dynamic output. 2017-04-12 21:28:13 cg.rpath = true; 2017-04-12 21:28:15 } 2017-04-12 21:29:47 okay! :) 2017-04-12 21:37:51 for the first time we have alpine running on a POWER9 machine 2017-04-12 21:37:51 # cat /etc/os-release | head -n 1 2017-04-12 21:37:52 NAME="Alpine Linux" 2017-04-12 21:37:52 # cat proc/cpuinfo | head -n 2 2017-04-12 21:37:52 processor : 0 2017-04-12 21:37:52 cpu : POWER9 (raw), altivec supported 2017-04-12 21:39:22 leitao: good job :) 2017-04-12 21:51:06 leitao: where can i purchase 2017-04-12 21:51:09 :D 2017-04-12 21:57:26 jirutka: https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085 2017-04-12 21:57:28 here's my post 2017-04-12 21:57:41 care reading through it to see if I'm not saying something wrong? 2017-04-12 22:01:13 Shiz: http://tpaste.us/5vP7 ? 2017-04-12 22:01:33 Shiz: wow, such long post! 2017-04-12 22:01:48 :P 2017-04-12 22:01:55 jirutka: i'd append it to the current rpath patch, but yes 2017-04-12 22:02:00 i think all rpath changes should be in a single patch file 2017-04-12 22:02:35 Shiz: I was thinking about it, but the current rpath patch do quite different thing 2017-04-12 22:02:59 Shiz: it’s to link rustc and rustdoc against libs in /usr/lib/rustlib//lib 2017-04-12 22:03:05 right 2017-04-12 22:03:13 fine then 2017-04-12 22:03:22 just let me know the filename of the patch so I can edit in the internals.rust-lang.org post 2017-04-12 22:03:24 :P 2017-04-12 22:03:42 Shiz: force-rpath-on-prefer-dynamic.patch 2017-04-12 22:04:07 Shiz: I’m still building rust, wanna verify that it really works as intended before pushing 2017-04-12 22:04:16 :) 2017-04-12 22:04:29 it may not directly work for cargo yet 2017-04-12 22:05:07 Shiz: “in Windows, dynamic libraries can have their own statically linked C runtimes” … WHAT?! 2017-04-12 22:05:14 Shiz: this sounds like quite crazy idea 2017-04-12 22:05:19 jirutka: yep 2017-04-12 22:05:22 Shiz: Windows really allows that? 2017-04-12 22:05:25 yeah 2017-04-12 22:05:35 there's a _DLLMainCRTStartup() functio that gets called for every DLL 2017-04-12 22:05:40 that start ups that DLL's CRT runtime 2017-04-12 22:06:06 if you're thinking "this means i can't share data between DLLs with different C runtimes" 2017-04-12 22:06:08 you're right 2017-04-12 22:06:13 at least, not libc-specific data like a FILE* 2017-04-12 22:11:39 wow 2017-04-12 22:12:35 you’re also a Windows programmer? 2017-04-12 22:13:22 no, i just know a bit about it 2017-04-12 22:13:28 and i talked to someone in #rust-internals about it 2017-04-12 22:13:30 :P 2017-04-12 22:14:38 aha :) 2017-04-12 22:15:03 your post https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085 is excellent, I’ve already read it 2017-04-12 22:15:28 :) 2017-04-12 22:15:57 just one note, I’d also add a note that we actually don’t use jemalloc, b/c it increases size of static binaries significantly for just a little performance gain (that may be even negative in some tests) 2017-04-12 22:16:25 I’ve described it in https://github.com/alpinelinux/aports/commit/eadd59359eb8e801e4e15a6611b4981e6d967ad2 2017-04-12 22:17:26 the exact numbers would be a bit different now, after some changes (probably updating llvm and also switching to llvm-libunwind), statically linked binary is even smaller (~ 168 kiB or something like that) 2017-04-12 22:18:12 I think that jemalloc has more importance for glibc than for musl :) 2017-04-12 22:26:41 righ, but it's a patch that's already merged anyway 2017-04-12 22:26:43 :P 2017-04-12 22:26:54 also: https://twitter.com/dev_console/status/852285655564550145 2017-04-12 22:27:05 tweeted about it since it may be interesting to people tracking rust progress on alpine 2017-04-12 22:30:40 Shiz: works great! pushed to aports 2017-04-12 22:30:46 \o 2017-04-12 22:52:37 Shiz: and maybe I’d also add that installing (duplicated) rust shared libs into /usr/lib is not just waste of space, but also wrong, b/c of unstable ABI etc. 2017-04-12 22:52:47 ? 2017-04-12 22:52:50 how do you mean 2017-04-12 22:54:29 Shiz: as stated in commit msg https://github.com/alpinelinux/aports/commit/eadd59359eb8e801e4e15a6611b4981e6d967ad2 2017-04-12 22:54:38 Shiz: pardon, not this one 2017-04-12 22:55:09 Shiz: and also not a commit message, but patch :P https://github.com/alpinelinux/aports/blob/eadd59359eb8e801e4e15a6611b4981e6d967ad2/testing/rust/change-rpath-to-rustlib.patch 2017-04-12 22:55:29 jirutka: this is fine though 2017-04-12 22:55:32 since they are suffixed with a hash 2017-04-12 22:55:40 that's kind of there for that reasonafaik 2017-04-12 22:56:24 Shiz: so when you update rust-stdlib, you get probably totally different has, and so different lib and your binary linked against it is now unusable 2017-04-12 22:56:36 sure, but that has no bearing whether it's in /usr/lib or elsewhere 2017-04-12 22:56:38 s/has/hash/ 2017-04-12 22:57:12 hm… 2017-04-12 22:57:50 i think that from this nature, they really should be treat as private libs 2017-04-12 22:58:08 and as skarnet told me, such libs should not be in /usr/lib or other standard LD path 2017-04-12 23:39:59 i agree with that, it shouldn't be in /usr/lib 2017-04-12 23:40:31 oh, i dont disagree 2017-04-12 23:40:40 i think because of their overly-generic names they shouldnt be there anyway 2017-04-12 23:40:49 it just has no bearing on wrongness from their perspective i think 2017-04-12 23:40:53 just from ours as a distro one 2017-04-12 23:41:56 sure 2017-04-12 23:42:21 so that's why i didn't mention it in the post i made on their forum :P 2017-04-12 23:48:50 Shiz: @rustlang liked https://twitter.com/jakubjirutka/status/852296489355423744 :) 2017-04-12 23:49:05 yeah saw it 2017-04-12 23:49:07 :p 2017-04-12 23:49:11 also liked my orig tweet 2017-04-12 23:49:24 maybe gotta poke ncopa to rt it on the alpine linux twitter 2017-04-12 23:49:26 wee visibility 2017-04-12 23:50:07 Shiz: ncopa unfortunately don’t retweet even his own tweets about Alpine :( 2017-04-12 23:50:25 Shiz: via Alpine account 2017-04-12 23:50:42 :P 2017-04-12 23:57:43 i think clandmeter actually runs the twitter 2017-04-12 23:57:46 not sure 2017-04-12 23:59:58 IIRC it’s ncopa 2017-04-13 00:01:47 i think we need a marketing team which handles that stuff 2017-04-13 00:04:50 i think that one person would be enough for now :P 2017-04-13 00:05:32 well it would be good option to spread the burden out 2017-04-13 07:34:10 clandmeter: one last question. why doest apk add snapcast-client trigger the pre install script? its only defined in the global install section. or is this section valid for all subpackages? 2017-04-13 07:34:48 does or doesnt? 2017-04-13 07:35:18 i mean it works. apk add snapcast-client triggers the pre install script just fine 2017-04-13 07:35:28 *does 2017-04-13 07:35:51 the install scripts name should match the pkgname 2017-04-13 07:36:06 then they are added to to correct pkg 2017-04-13 07:36:19 if they are defined in "install=" 2017-04-13 07:36:21 ? 2017-04-13 07:36:24 yes 2017-04-13 07:36:27 ok ok 2017-04-13 07:36:56 that was complicated for me to understand. but now it works... the thing is... you did all the work ;-) 2017-04-13 07:37:03 $pkgname.pre-install $subpkgname.pre-install (iirc) 2017-04-13 07:38:03 well, you need to know how it works if you want to maintain it :) 2017-04-13 07:38:10 thats what we did now. 2017-04-13 07:38:28 true 2017-04-13 07:38:52 soon i will migrate my personal snapcast and mopidy setup to alpine... and i will be happy :) 2017-04-13 07:39:11 im waiting for rust to land in alpine 2017-04-13 07:39:20 then we can add spotify :) 2017-04-13 07:42:45 hahaha cool... maybe i should add a mopidy pkg again 2017-04-13 07:44:38 clandmeter: spotify uses rust? 2017-04-13 07:44:51 check librespotify 2017-04-13 07:45:10 https://github.com/plietar/librespot 2017-04-13 07:45:17 Rust 1.15.0 or later is required to build librespot. 2017-04-13 07:45:22 heh 2017-04-13 07:45:31 there's always also despotify 2017-04-13 07:45:33 ;P 2017-04-13 07:45:59 that works? 2017-04-13 07:46:02 its 8 years old 2017-04-13 07:46:04 i dunno 2017-04-13 07:46:48 i think we need librespot, atleast thats what ive seen works. 2017-04-13 07:48:25 :p 2017-04-13 07:48:33 clandmeter: rust is in testing right now so 2017-04-13 07:48:39 feel free to give it a shot 2017-04-13 07:48:44 does cargo work? 2017-04-13 07:48:51 yes 2017-04-13 07:49:16 the only issue is that we can't properly verify cargo deps yet 2017-04-13 07:49:27 i wrote a hack for it but it's not very great 2017-04-13 07:49:51 (involves # cargo fetch during fetch(), taring it up and checking that sum) 2017-04-13 07:55:10 any way to do a check() for python modules? 2017-04-13 07:57:08 not if it doesnt provide something itself. 2017-04-13 07:57:30 the simplest way to do a check if just checking if the binary that belongs to the package runs with e.g. --version 2017-04-13 07:57:35 if there is nothing else 2017-04-13 07:57:51 thats hard with a python module :) 2017-04-13 07:58:08 there's also python setup.py test apparently 2017-04-13 07:58:16 not sure how many packages support integration with that... 2017-04-13 07:58:21 yes, if they provide it then thats sane to use. 2017-04-13 07:58:58 you could write your own tests, but thats out of the scope of package maintaining imho. 2017-04-13 07:59:15 yeah 2017-04-13 08:02:05 morning 2017-04-13 08:02:16 any volunteer for marketing team? 2017-04-13 08:02:37 who can do the @alpinelinux twitter? 2017-04-13 08:07:17 :P 2017-04-13 08:07:20 morning 2017-04-13 08:11:40 first thought was a python -m modulename but that doesnt work if there is now __main__ 2017-04-13 09:32:50 <_ikke_> xsteadfastx: python -i? 2017-04-13 09:34:22 mh i dont know about that one 2017-04-13 09:34:43 else just check for the location? but thats not really a test if the pkg is working 2017-04-13 10:14:57 is "misery" here? 2017-04-13 10:18:55 <^7heo> misery is everywhere in this world. 2017-04-13 10:18:58 <^7heo> ACTION hides 2017-04-13 10:23:11 ncopa: i have some left if you want :) 2017-04-13 10:36:19 Shiz, any idea about this one? http://tpaste.us/DkOz 2017-04-13 10:44:54 clandmeter: yeah sec 2017-04-13 11:06:12 clandmeter: it happens when you try to create a dylib with static-crt 2017-04-13 11:06:15 which is not correct 2017-04-13 11:10:52 ncopa: I’m not a marketing person, but I think that I can handle @alpinelinux Twitter, if no one more competent show up :) 2017-04-13 11:11:28 i'd prefer you spend you time on coding 2017-04-13 11:11:41 :) 2017-04-13 11:28:58 ncopa: okay :) 2017-04-13 11:41:19 im looking at mseon build system 2017-04-13 11:41:23 meson 2017-04-13 11:41:26 looks pretty nice 2017-04-13 11:41:49 however, it depends on python 2017-04-13 11:42:09 yeah, i kinda like meson idea too 2017-04-13 11:42:11 what do you guys think about the one from void? 2017-04-13 11:42:44 would be nice to port meson to lua 2017-04-13 11:42:46 or even C 2017-04-13 11:42:58 not sure meson is of that kind, but it reminds me anyway 2017-04-13 11:43:07 is it a make system? 2017-04-13 11:43:14 hiro: void? 2017-04-13 11:43:19 its a autoconf replacement 2017-04-13 11:43:28 cmake/autoconf alternative 2017-04-13 11:43:31 oh! 2017-04-13 11:43:37 generate ninja files 2017-04-13 11:43:49 sorry to intrude then, i hate those kinds of things! :P 2017-04-13 11:43:54 ninja is a better make 2017-04-13 11:44:31 what do you think about https://github.com/gittup/tup ? 2017-04-13 11:44:41 I don’t know much about it, found it by accident 2017-04-13 11:44:55 too many people tried to make me use their make systems haha 2017-04-13 11:44:55 dunno 2017-04-13 11:45:08 but i really like ninja as backend 2017-04-13 11:45:20 but ninja files needs to be generated 2017-04-13 11:45:32 gnu make you dont really need to generate 2017-04-13 11:45:33 hiro: well, I think that anything is better than autohells, make and cmake… 2017-04-13 11:46:06 you can use gnu make without generating them, but it gets quickly unreadable 2017-04-13 11:46:19 speaking about Lua: https://github.com/sebnow/lake (but it’s very outdated and unmaintained) 2017-04-13 11:46:21 and if you generate it, then better use ninja 2017-04-13 11:46:31 i heard of lake yes 2017-04-13 11:46:33 but not maintained 2017-04-13 11:46:41 i'm against generating it 2017-04-13 11:46:43 <_ikke_> I'm currently using redo 2017-04-13 11:46:48 eh, no, this is more up-to-date source: https://github.com/stevedonovan/Lake 2017-04-13 11:47:01 <_ikke_> anyone heard of it? 2017-04-13 11:47:03 but i like ninja :) 2017-04-13 11:47:10 _ikke_: nope 2017-04-13 11:47:16 ninja scales 2017-04-13 11:47:31 beucase it includes real ninjas inside? :P 2017-04-13 11:47:36 a bad thing possibly 2017-04-13 11:47:48 scale is an excuse for useless complexity sometimes 2017-04-13 11:47:51 you can build huge things like chromium with it 2017-04-13 11:48:09 few other build systems can scale that 2017-04-13 11:48:21 yes, creating less chances for a more sane chrome alternative to ever come up 2017-04-13 11:48:24 With make you can build Linux kernel 2017-04-13 11:48:43 i don't care if google gets problems compiling chrome or not! 2017-04-13 11:48:44 @ncopa │ you can use gnu make without generating them, but it gets quickly unreadable 2017-04-13 11:48:46 hiro: true when done wrong, that’s unfortunately most of the time :/ 2017-04-13 11:48:49 i object to this statement 2017-04-13 11:48:59 consus: goodd point, hahaha 2017-04-13 11:49:20 That's what I call scalability 2017-04-13 11:49:23 jirutka: what is true? 2017-04-13 11:49:28 i think thre are some project of using ninja for kernel 2017-04-13 11:49:29 Though they do have their own configuration language 2017-04-13 11:49:34 hiro: "scale is an excuse for useless complexity sometimes" 2017-04-13 11:49:41 https://github.com/rabinv/kninja 2017-04-13 11:50:01 jirutka: ah, yes i agree 2017-04-13 11:50:05 Shiz, do you have an idea on how to fix that error? 2017-04-13 11:50:13 kernel would be better built with ninja 2017-04-13 11:50:19 clandmeter: i've talked about it in my post on rust-internals 2017-04-13 11:50:21 i mean faster 2017-04-13 11:50:21 :P 2017-04-13 11:50:30 i think the best way is just to... ignore building the dylib 2017-04-13 11:50:42 when target-feature=crt-static is set 2017-04-13 11:50:45 i have no experiance with rust or cargo 2017-04-13 11:50:45 ncopa: i don't need the kernel to build faster 2017-04-13 11:51:01 any hint would be appreciated :) 2017-04-13 11:51:06 It would be nice to run a benchmark on a full build 2017-04-13 11:51:10 clandmeter: what are you trying to solve? 2017-04-13 11:51:23 clandmeter: evacuate 2017-04-13 11:51:48 clandmeter: press the fire alarm, call in sick the rest of the month 2017-04-13 11:51:48 On a webpage there is a comparison between make -j8 and ninja when nothing changes 2017-04-13 11:51:52 jirutka: http://tpaste.us/BeX4 2017-04-13 11:51:54 Only 2 seconds gain 2017-04-13 11:51:57 hiro: well, i need *everything* to build faster :) 2017-04-13 11:52:15 specifically autoconf stuff 2017-04-13 11:52:24 clandmeter: it's better for the tax payer in the end than if you go total lunatix with rust 2017-04-13 11:52:36 clandmeter: it'd need a cargo patch 2017-04-13 11:52:40 Well autoconf repeatedly checks for the presence of 2017-04-13 11:52:41 not sure if i have time for it today 2017-04-13 11:52:44 These people are insane 2017-04-13 11:53:06 clandmeter: pkgs for software written in rust would be a bit more complicated b/c of dependencies; it’s on my priority list 2017-04-13 11:53:23 jirutka, it worked befroe with old rust 2017-04-13 11:53:40 not sure its because of rust/cargo or this project evolving. 2017-04-13 11:54:02 clandmeter: try to add RUSTFLAGS="-C target-feature=-crt-static" 2017-04-13 11:54:15 clandmeter: I’ll look at it later, have to go to lunch now 2017-04-13 11:54:23 yeah that one makes it work 2017-04-13 11:55:00 clandmeter: I’m gonna set dynamic linking for our rust as default, then this will not be needed 2017-04-13 11:55:01 btw, what are we planning to do with cargo files like git and registry? 2017-04-13 11:55:50 clandmeter: I don’t know yet, have to do some research 2017-04-13 11:56:59 clandmeter: I’d like to get rid of need to clone registry repo and have just Cargo.lock and crate packages, but not sure if it’s currently possible 2017-04-13 11:57:32 think we should prevent it to polute $HOME, but using $srcdir takes too much time... 2017-04-13 11:57:40 clandmeter: cause it’s insane to always have entire registry.io clone that is dozens of megabytes when all the needed information is already in Cargo.lock 2017-04-13 11:58:02 clandmeter: ofc, we set CARGO_HOME to $srcdir, to not pollute $HOME 2017-04-13 11:59:20 you can't use cargo.lock without the registry 2017-04-13 11:59:23 sadly 2017-04-13 11:59:27 btw we need to make rust-bootstrap pkg to cross-compile rustc from glibc to musl, to not rely on binaries from VoidLinux… ghc-bootstrap may be useful as example… 2017-04-13 12:00:00 Shiz: I hope that cargo can be somehow *forced* to it… :) 2017-04-13 12:00:28 rust is slow... 2017-04-13 12:02:02 looks like its getting a bit further. 2017-04-13 12:02:53 jirutka: negative 2017-04-13 12:02:55 as far as i know 2017-04-13 12:03:07 Finished release [optimized] target(s) in 332.45 secs 2017-04-13 12:03:16 yeah rustc is slow... 2017-04-13 12:03:17 \o/ 2017-04-13 12:04:29 jirutka: clandmeter: i may have found a nice approach 2017-04-13 12:04:49 for the error you got, clandmeter 2017-04-13 12:04:58 ok 2017-04-13 12:05:25 in what way is it better then the current fix? 2017-04-13 12:05:30 uhm 2017-04-13 12:05:33 the current fix isn't really a fix 2017-04-13 12:05:35 it's just a workaround 2017-04-13 12:05:37 :P 2017-04-13 12:05:48 it tells it to link everything dynamically 2017-04-13 12:05:49 it fixes my build :p 2017-04-13 12:05:56 which is what we want to default to in the end 2017-04-13 12:05:58 BUT 2017-04-13 12:06:02 it doesn't change that static linking is somewhat broken atm 2017-04-13 12:06:07 and i can fix that in the core compiler 2017-04-13 12:06:12 i know exactly where to put it 2017-04-13 12:06:14 :P 2017-04-13 12:06:48 you want me to compile it static? 2017-04-13 12:07:34 no, just saying my fix fixes the fundamental issue 2017-04-13 12:07:41 not just the symptoms you saw 2017-04-13 12:08:48 ah ok, so the result is the same/ 2017-04-13 12:08:49 ? 2017-04-13 12:12:32 yeah 2017-04-13 12:13:07 Shiz: hm, I built rustc with dynamic as default and now almost all cargo tests pass… 2017-04-13 12:13:29 jirutka: :) 2017-04-13 12:13:36 because it doesn't tryo create dylibs on crt-static anymore 2017-04-13 12:13:39 which was the root cause remember 2017-04-13 12:14:22 not sure, there were more problems 2017-04-13 12:14:33 btw we didn’t run ALL cargo tests before 2017-04-13 12:15:04 now we do, with --no-fail-fast 2017-04-13 12:15:25 ah 2017-04-13 12:15:27 got a log? 2017-04-13 12:31:33 Shiz: cargo built as dynamic with rustc building static as default: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/cargo/cargo-0.17.0-r1.log 2017-04-13 12:32:32 right 2017-04-13 12:32:49 Shiz: cargo built as dynamic wirth rustc building dynamic as default: https://hastebin.com/raw/ahehubijay 2017-04-13 12:33:09 rust/cargo is x86_64 only for now? 2017-04-13 12:34:17 clandmeter: yes, for now 2017-04-13 12:34:59 clandmeter: I hope that we can use abuild support for cross-compiling to compile it for other arches, but as i know there’s no documentation at all for it, so must fabled how it works 2017-04-13 12:41:55 Error loading shared library libstd-08ebb426f9085302.so: No such file or directory (needed by target/debug/foo) 2017-04-13 12:41:57 hmm 2017-04-13 12:43:54 jirutka: 4 failures isnt bad 2017-04-13 12:43:56 :P 2017-04-13 12:44:13 yeah, and I’ve fixed one of them right now 2017-04-13 12:44:27 just stupidity, he assets User-Agent header that contains version of libgit2… 2017-04-13 12:44:28 jirutka: i don't think the http_auth one is our fault 2017-04-13 12:44:30 ah 2017-04-13 12:44:31 asserts 2017-04-13 12:44:32 :D 2017-04-13 13:06:01 Shiz: pushed updated testing/rust with dynamic linking as default and cargo with fixed test build-auth:http_auth_offered 2017-04-13 13:06:49 Shiz: and now I must really go back to work, I have done almost nothing this week, can’t unbind myself from this :) 2017-04-13 13:08:14 jirutka: i hope you put the dynlink-default in a separate patch 2017-04-13 13:08:16 :P 2017-04-13 13:08:18 good luck! 2017-04-13 13:08:36 Shiz: hm, no, I put it into fix-linux_musl_base.patch 2017-04-13 13:08:48 :( 2017-04-13 13:08:54 that fucks up my internals post 2017-04-13 13:08:56 :P 2017-04-13 13:09:01 aha, sorry :( 2017-04-13 13:09:03 since those three patches are supposed to be upstreamable 2017-04-13 13:09:16 okay, I’ll change it 2017-04-13 13:09:21 thanks :) 2017-04-13 13:09:32 jirutka: uh, can i still ping you if you're working 2017-04-13 13:09:39 i got an incoming patch for you once i'm done testing it 2017-04-13 13:09:47 :) 2017-04-13 13:10:06 yes, also please remind me to split the patch we’ve talked about 2017-04-13 13:10:07 afk 2017-04-13 13:10:10 \o 2017-04-13 13:19:17 Shiz: fix-linux_musl_base.patch currently depends on static-pie.patch… 2017-04-13 13:19:54 right 2017-04-13 13:19:57 and? :P 2017-04-13 13:20:22 just saying, if you aware of it 2017-04-13 13:21:05 we have about four patches that modifies linux_musl_base :/ 2017-04-13 13:21:05 yeah i am 2017-04-13 13:21:11 i want to upstream static-pie.patch too 2017-04-13 13:21:26 but yeah the patches are kind of order-dependent atm 2017-04-13 14:02:52 Shiz: changes in patches done 2017-04-13 14:02:57 Shiz: what about your new patch? :) 2017-04-13 14:03:12 weeding out some issues.. 2017-04-13 14:03:20 error: cannot produce dylib for `rustdoc v0.0.0 (file:///home/builder/aports/testing/rust/src/rustc-1.16.0-src/src/librustdoc)` as the target `x86_64-unknown-linux-musl` does not support these crate types 2017-04-13 14:03:22 :P 2017-04-13 14:05:25 Shiz: I have an idea… what if we create new profile, $arch-alpine-linux-musl, with dynamic linking as default, and keep unknown-linux-musl with static linking as default? 2017-04-13 14:05:48 i have thought of that, but it seemed... invasive? 2017-04-13 14:06:02 Shiz: maybe it’d be more convenience than -C target-feature=[+-]crt-static 2017-04-13 14:06:45 Shiz: I’d be more convenience in abuilds, because our triple is x86_64-alpine-linux-musl 2017-04-13 14:06:54 Shiz: now we must change it to x86_64-unknown-linux-musl 2017-04-13 14:07:03 for rust stuff 2017-04-13 14:07:33 hm, no, this would not work 2017-04-13 14:07:57 b/c /usr/lib/rustlib/… 2017-04-13 14:07:58 :P 2017-04-13 14:08:06 i mean that part would work fine 2017-04-13 14:08:15 since we only distrib dynamically linked binaries for alpine, right 2017-04-13 14:08:28 if people wanna do normal or even static, it wouldnt affect it 2017-04-13 14:08:36 only if they do -C prefer-dynamic, at that point you're not portable ANYWAY 2017-04-13 14:09:16 I think that I didn’t get your point now…? 2017-04-13 14:11:23 eh, screw it, this is not important issue 2017-04-13 14:13:06 my point is, changing the target is fine for rustlib 2017-04-13 14:13:11 i don't see why it'd be an issue there? 2017-04-13 15:03:38 please, someone, fix qt5-qtscript, it’s blocking armhf for several days… 2017-04-13 15:33:28 kaniini: we should really somehow get founding from docker… that’s how (most?) people see what we are doing here… :/ https://twitter.com/rhy0lite/status/852527145746345984 2017-04-13 15:35:29 s/founding/funding/ 2017-04-13 15:39:12 leo-unglaub: hi! we have great news for you! 2017-04-13 15:39:31 jirutka: really? 2017-04-13 15:39:51 diched the linux kernel for an openbsd kernel? ;) 2017-04-13 15:40:26 leo-unglaub: yeah! thanks to Shiz we have fully working rustc with support for both dynamic PIE and static PIE linking on Alpine! 2017-04-13 15:40:30 leo-unglaub: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rust 2017-04-13 15:40:57 very nice work ! 2017-04-13 15:41:02 leo-unglaub: our rustc use dynamic linking by default, but you can switch it to static using `-C target-feature=+crt-static` 2017-04-13 15:41:18 damn, have to go 2017-04-13 15:41:22 leo-unglaub: and that will produce statically linked PIE binary! 2017-04-13 15:42:38 leo-unglaub: it required a lot of effort, we found many bugs/issues in Rust build system… 2017-04-13 15:42:57 leo-unglaub: you may be also interested in this excellent post by Shiz https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085 2017-04-13 15:43:36 leo-unglaub: I believe that we will be able to push rust and cargo into community before branching v3.6 2017-04-13 16:30:00 ncopa: to fix the go package in ppc64le, we will need to generate a go 1.8 apk and upload it to somewhere to be able to compile go. 2017-04-13 16:30:00 The problem is that go-bootstrap 1.4 version (that is the last version that does not have go code) is not supported in power, so we had to do a cross-compilation 2017-04-13 17:27:27 Dear experts, what a dot "." means at APKBUILD? I found it at community/libevhtp/APKBUILD. 2017-04-13 17:27:41 http://tpaste.us/bKPB 2017-04-13 17:27:54 it seems to FTBFS on ppc64le 2017-04-13 17:28:23 '.' = source in shell script. 2017-04-13 17:29:10 Although the usage in the referenced file is very strange indeed. 2017-04-13 17:29:12 it seems that '.' is located in a single line 2017-04-13 17:29:15 TemptorSent, yup 2017-04-13 17:29:40 it is there since the beginning. 2017-04-13 17:30:04 Hmm, source with no args... 2017-04-13 17:30:04 Ahh 2017-04-13 17:30:10 it is being escaped. 2017-04-13 17:30:23 it should be part of cmake line? 2017-04-13 17:31:29 no, there is an empty line between both. 2017-04-13 17:31:31 No, it looks like there's an extra line.. 2017-04-13 17:31:37 right 2017-04-13 17:31:51 yea, I am not smart enough to understand it. 2017-04-13 17:31:53 I think it was intentended to be cmake command in current dir. 2017-04-13 17:32:09 But someone added some spacing? 2017-04-13 17:32:38 Try it with it following the last escaped line 2017-04-13 17:32:46 sure 2017-04-13 17:33:23 it works 2017-04-13 17:33:24 http://tpaste.us/7BE1 2017-04-13 17:33:32 ./ would be better perhaps, but sometimes the trailing slash confuses things. 2017-04-13 17:33:32 it seems that ncopa added that line 2017-04-13 17:34:09 Yeah, looks like a random newline got in there :) 2017-04-13 17:34:28 I am assuming that this is a regression, and push this fix 2017-04-13 17:34:50 It was supposed to be immediately following the previous \ escaped line for clarity I believe. 2017-04-13 17:35:04 yea 2017-04-13 17:35:30 I'd do that, rather than simply appending it to the previous line. 2017-04-13 17:36:07 Hello fabled__? 2017-04-13 17:57:47 it's weekend man 2017-04-13 18:04:31 no, it’s not (ye) :P 2017-04-13 18:04:33 yet 2017-04-13 18:05:08 no it is for me 2017-04-13 18:06:22 hiro: lucky you 2017-04-13 18:38:02 Shiz: okay I know how to deal with Rust pkgs :) 2017-04-13 18:53:09 leitao: hte dot means "current directory" 2017-04-13 18:53:31 look like it is suppsed to be cmake -DBLA_BLA . 2017-04-13 18:53:49 ncopa, yes, i just fixed it. 2017-04-13 18:54:05 thanks for cleanin up my mess :) 2017-04-13 18:55:13 ncopa, no worries, by the way, it seems that we are reaching an end in the community archive 2017-04-13 18:55:22 \o/ 2017-04-13 18:55:30 I hope to start working on testing next week 2017-04-13 18:55:37 good 2017-04-13 18:55:55 testing is not that critical, at least not for 3.6 release 2017-04-13 18:56:14 right 2017-04-13 18:56:15 but it would be nice to have it cleaned up 2017-04-13 18:56:29 is 3.6 still scheduled for 5/1? 2017-04-13 18:56:29 if you have something thats broken, and nobody has touched it for more than 6 months 2017-04-13 18:56:39 in testing 2017-04-13 18:56:41 <^7heo> ncopa: speaking of testing, I'm gonna have to try again to install the computer with the detached header this week end. 2017-04-13 18:56:53 <^7heo> (not @testing, but the verb) 2017-04-13 18:56:54 and it looks like its non-trivial 2017-04-13 18:57:04 then we can move it to unmaintained 2017-04-13 18:57:11 ncopa, ok 2017-04-13 18:57:19 also 2017-04-13 18:57:24 the stuff we have in unmaintained 2017-04-13 18:57:29 thats older than 6months 2017-04-13 18:57:32 should be pruged 2017-04-13 18:57:44 the "unmaintained" is like trashcan :) 2017-04-13 18:58:22 ^7heo: great 2017-04-13 18:59:38 ^7heo: Do you have that refined script handy? I'm about finished with the nasty part (kernel/module/firmware mess) and ready to remove the last vestiges of the broken mkinitfs behavior. 2017-04-13 19:00:16 ncopa, by the way, the current package that fails on ppc64le is obnam 2017-04-13 19:00:25 it depends on a package that was not in the archive before. 2017-04-13 19:00:44 <^7heo> TemptorSent: what do you mean? 2017-04-13 19:00:46 I added it at testing/py-packaging 2017-04-13 19:00:50 should it be moved to community? 2017-04-13 19:01:04 or I can cross reference dependencies? 2017-04-13 19:01:23 ^7heo: The one you used for deps and the rest of whats needed to make the detached header function properly. 2017-04-13 19:02:27 I have it fixed so we won't get broken modules any longer without really trying :) 2017-04-13 19:03:00 <^7heo> TemptorSent: dude I'm working; I have no time to try X times to re-read what you wrote to make sense of it. 2017-04-13 19:03:07 <^7heo> TemptorSent: sorry =/ 2017-04-13 19:03:42 ^7heo: Do you have the script you used to make the detached header work? I want to see it 2017-04-13 19:04:03 that's how I read it, anyway 2017-04-13 19:06:24 ^7heo: Sorry, I would like to know what changes you needed to make and what commands you use to generate a working detached-headder configuration once you get it done. 2017-04-13 19:06:34 what detached header? 2017-04-13 19:06:52 I know detached head, from git if it works. 2017-04-13 19:06:56 ^7heo: And include any fixes that might be needed in mkinitfs itself. 2017-04-13 19:07:04 LUKS 2017-04-13 19:08:29 Essentially, leaving the entire disk encrypted with no interesting plaintext because you carry the 'detacthed' headders on a usb key. 2017-04-13 19:08:59 leitao: packages can only depend from same repo or main 2017-04-13 19:09:07 testing can depend on both main or community 2017-04-13 19:09:27 its weekend here now 2017-04-13 19:09:31 have a nice evening! 2017-04-13 19:09:39 This is something I very much would like to support, so if anything is missing to make it generally workable, I'd like to get that addressed asap. 2017-04-13 19:09:52 ncopa: Have a great weekend. 2017-04-13 19:12:25 leitao: to be more formal, repositories are in hierarchy: main < community < testing; pkgs in repo X can depend on pkgs in X and all repos on left from X, but not on right from X 2017-04-13 19:12:43 ncopa: nice weekend and Easter! 2017-04-13 19:15:33 <^7heo> awilfox: thanks ;) 2017-04-13 19:15:53 <^7heo> TemptorSent: there was no such script. 2017-04-13 19:16:01 huh, is Friday a holiday in Europe? 2017-04-13 19:16:08 <^7heo> at least in .de 2017-04-13 19:16:09 it definitely isn't here (though it is my birthday!) 2017-04-13 19:16:10 Long weekend for easter. 2017-04-13 19:16:18 Happy Birthday! 2017-04-13 19:16:19 <^7heo> TemptorSent: to make the detached header work I used my brain and vi. 2017-04-13 19:16:23 <^7heo> TemptorSent: not a script. 2017-04-13 19:16:31 <^7heo> TemptorSent: I still don't get what you want. 2017-04-13 19:16:37 <^7heo> and yes 2017-04-13 19:16:44 <^7heo> awilfox: HAPPY BIRTHDAY! ;) 2017-04-13 19:16:45 awilfox: in some countries 2017-04-13 19:16:50 ^7heo: What does it need to BOOT, as far as any changes to initramfs-init 2017-04-13 19:16:57 jirutka, ok, makes sense. 2017-04-13 19:16:59 ^7heo: thanks :3 2017-04-13 19:17:21 there is one package in community called obnam that "depends" on py-packaging. 2017-04-13 19:17:36 <^7heo> TemptorSent: aah, you mean, what did I need to change to the script to make it work? 2017-04-13 19:17:47 Yes :) 2017-04-13 19:17:58 jirutka, i.e, it is not marked as a dependency, but obnam does not compile if you do not have py-packaging installed. 2017-04-13 19:18:01 awilfox: it’s Good Friday (also referred as Easter Friday); for example in Czech Republic this became a state holiday just few years ago 2017-04-13 19:18:11 awilfox: and happy birthday to you! 2017-04-13 19:18:27 ^7heo: I want to generate the initfs so it just works. 2017-04-13 19:18:28 jirutka, should we migrate py-packaging to community and make obnam dependent of py-packaging? 2017-04-13 19:19:25 leitao: yes, but please open a PR for it; I see some issues in this package 2017-04-13 19:19:40 hm, like, many issues :/ 2017-04-13 19:19:49 leitao: do you know https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python ? 2017-04-13 19:20:42 jirutka, ok, I will review this package before opening a PR. 2017-04-13 19:21:19 <^7heo> TemptorSent: https://github.com/alpinelinux/mkinitfs/commit/5ee279f6b475306659af256f724847c65b335040 2017-04-13 19:21:24 ^7heo: And if you have the list of deps, you needed to install in the initfs a well, that would be quite helpful.. 2017-04-13 19:21:31 TY 2017-04-13 19:22:14 ^7heo: We are pretty close to splitting nlplug-findfs to it's own package and moving the mkalpine tools to a top level repo 2017-04-13 19:25:19 jirutka: I see. also, thanks! 2017-04-13 19:25:57 ^7heo: Okay, very, very minor changes required - just passing along the correct cryptopts for cryptheader and cryptoffset it appears. 2017-04-13 19:30:14 <^7heo> yes 2017-04-13 19:55:50 Guys, what is the procedure for taking over an unmaintained package? Should I contact with maintainer first? 2017-04-13 19:58:26 <^7heo> yeah. 2017-04-13 19:58:48 <^7heo> what's the package? 2017-04-13 20:43:37 jirutka: oh? 2017-04-13 21:12:37 ^7heo: unmaintained/vdr 2017-04-13 21:26:33 terra: you don’t need to ask for pkgs in unmaintained 2017-04-13 21:26:35 Shiz: ? 2017-04-13 23:58:51 jirutka: jirutka │ Shiz: okay I know how to deal with Rust pkgs :) 2017-04-14 00:34:48 Shiz: example: https://gist.github.com/jirutka/59be5141dd442abcbc183431e0cef8eb 2017-04-14 00:35:41 jirutka: nice! 2017-04-14 00:35:43 looking good 2017-04-14 00:36:00 Shiz: this is NOT a final solution, just a draft; also note that acargo-dep-uris is basically a hack, parsing TOML file with sed is not very good approach… 2017-04-14 00:36:21 :p 2017-04-14 00:36:26 relevant source: https://github.com/rust-lang/cargo/pull/2857 2017-04-14 00:38:46 the good thing is that Cargo already provides all what we need for sane packaging… not like… ehm… Go… 2017-04-14 00:39:44 I have also prototype of acargo-dep-uris in Lua https://hastebin.com/raw/eticukuzay 2017-04-14 00:40:15 should also note that this approach requires copying Cargo.lock into abuild’s directory, along with APKBUILD 2017-04-14 00:40:50 b/c it uses it to fill $source with URIs for all crate dependencies 2017-04-14 00:43:12 initially I wanted to fill these URIs directly to abuild’s $source and later provide some shortcut like cargo:-, but then there would be dozens of lines just with generated content :/ 2017-04-14 00:43:32 so maybe it’s better to just copy Cargo.lock 2017-04-14 00:43:42 i think i'm more comfortable with acargo-dep-uris in sh :p 2017-04-14 00:45:16 okay, need to go sleep, gn! 2017-04-14 00:46:14 night! 2017-04-14 00:46:17 good work :) 2017-04-14 05:26:53 Good evening. 2017-04-14 07:04:36 skarnet: so i think for aconf, using tarballs makes more sense than just a bare directory tree (because we do not want to waste inodes in tmpfs setups) 2017-04-14 07:07:42 kaniini: How would you store values and meta data? Just contents of files? tar headers as well? 2017-04-14 07:08:12 contents of files for the values, extended tar headers for metadata (SCHILY.xattr) 2017-04-14 07:09:00 kaniini: would it be as simple as 'tar -xvzf $aconf -O /path/to/information/you/want' 2017-04-14 07:09:19 Do we have a tool that can actually read/write pax headers? 2017-04-14 07:09:34 (Schilly tar, for instance :) ) 2017-04-14 07:09:34 sure, apk 2017-04-14 07:09:55 there are ... ways 2017-04-14 07:10:17 kaniini: It's pretty deep in apk, and not exposed without going through the database (I asked :( ) 2017-04-14 07:11:04 kaniini: I need something better than the fugly awk script I'm running to extract the SHA1 sums from the headers to make a manifest of the APKs I tear apart. 2017-04-14 07:12:25 but anyway, a pax archive sounds like a good, sane, and flexible way of handling aconf, given a decent pax tool :) 2017-04-14 07:13:48 It would probably be good to make apk a bit more pax-compliant anyway. 2017-04-14 07:15:49 Anyway, let me know when you're ready for some testing. 2017-04-14 08:17:32 TemptorSent, maybe we should do apk applet for that; we are planning to change .apk format anyways... 2017-04-14 08:19:36 Hello fabled, long time no see! 2017-04-14 08:21:41 Since you probably haven't caught up on your backlogs, please take a look at Issues #7100 #7101 #7102 #7103 #7104 and #7107 , which are in part related. 2017-04-14 08:25:30 fabled: What do you have in mind regarding changes to the format? 2017-04-14 08:26:12 we would like to rewrite apk's way to handle indexes and packages. both formats would be re-designed. 2017-04-14 08:26:21 i have some private code and notes ready 2017-04-14 08:26:38 but it's long term thing 2017-04-14 08:26:42 fabled: The availability of checksummed manifests would be greatly helpful. 2017-04-14 08:31:08 When you have a moment, please take a look at the most recent work in my work branch (https://github.com/TemptorSent/tree/aports/mkimage-refactor-scripts/scripts/mkimage) 2017-04-14 08:32:43 I'm using the manifests rather than the filesystem to do the lookups for modules/firmware, so we actually know when something is missing. 2017-04-14 08:33:46 By far, the most painful part is using awk to extract the pax headers from the kernel and firmware packages -- several minutes on a fast machine! 2017-04-14 08:37:45 Will the new format allow for better trust management on packages (Such as only install those packages directly signed by a whitelist of trusted people) and verification (Determine source/build information from checksum of file) 2017-04-14 08:50:13 morning 2017-04-14 08:50:25 'morning 2017-04-14 08:50:34 fabled, do we support rpi zero w? 2017-04-14 08:50:53 kaniini: are inodes a scarce resource on a tmpfs? users won't write many things into the tmpfs, is the system in danger of almost exhausting inodes already? 2017-04-14 08:51:11 clandmeter, not sure if the kernel patch / bootloader are updated for that. but it should be matter of just bumping those two elements 2017-04-14 08:51:16 i'm off for lunch 2017-04-14 08:51:26 ok thx 2017-04-14 08:53:52 clandmeter: The image builder should theoretically work for it with just those bumps as well. 2017-04-14 08:54:55 although I suspect I may have broken some things in pi-land because I haven't sorted out it's odd directory layout yet for boot files and dtbs. 2017-04-14 08:56:26 fabled: FWIW, we can now build modloops with any arbitrary set of modules and have ALL the module/firmware depends pulled in. 2017-04-14 10:39:49 fabled: can you please explain me how cross-compiling support in abuild works? :) 2017-04-14 10:40:17 jirutka, it's supported only to the extent of running bootstrap.sh currently 2017-04-14 10:40:30 fabled: ? 2017-04-14 10:40:37 but basically "CHOST= abuild" triggers the cross build 2017-04-14 10:41:05 you need to first build the cross-compiler yourself, since we don't ship cross compilers currently in the repositories 2017-04-14 10:42:38 fabled: hm, does cross-compiling in https://github.com/alpinelinux/aports/blob/master/testing/ghc/APKBUILD actually work? 2017-04-14 10:42:58 it should, i bootstrapped armhf of ghc by cross-compiling it 2017-04-14 10:43:27 to bootstrap build new architecture, use aports/scripts/bootstrap.sh 2017-04-14 10:43:40 that's the script that cross-builds initial set of .apks for new arch 2017-04-14 10:43:43 so it must be run manually? 2017-04-14 10:44:11 I don’t need to build new arch, just cross compile rust from x86_64 to armhf for example 2017-04-14 10:46:26 but actually not sure if it’s the best approach; alternatively we can bootstrap it from glibc binaries from armhf, we need to do that even for x86_64 anyway :/ 2017-04-14 10:47:06 yay native builds on armhf 2017-04-14 10:47:23 or: how to wait a week for your build to eventually fail 2017-04-14 10:47:45 jirutka, the very first rust may need to be built from "foreign" system... however, we prefer that the APKBUILD supports cross-building so when we bootstrap new arch, an automated process can do it 2017-04-14 10:47:59 skarnet: our armh xgene server isnt that bad actually 2017-04-14 10:48:06 armhf 2017-04-14 10:48:14 gcc, rust and go already support this 2017-04-14 10:48:32 fabled: how can I declare a cross-build in APKBUILD? 2017-04-14 10:49:50 fabled: well, but I have still no idea what to do :( these CROSS_COMPILE, makedepends_host, … variables and the entire cross-compilation process in abuild is not documented at all :/ 2017-04-14 10:49:52 it just needs to honor CHOST, CTARGET and few other environment variables set on cross-build. also need to distinguish which build dependencies go to build, host and target 2017-04-14 10:50:16 makedepends_* need to be set right 2017-04-14 10:50:31 but on self-hosting compiler it may be little bit trickier 2017-04-14 10:50:51 abuild tries to set all the common environment variables right for autoconf et al 2017-04-14 10:50:52 CHOST = build arch and CTARGET = target arch? 2017-04-14 10:50:57 are those gcc triplets? 2017-04-14 10:51:26 inside apkbuild those are gcc triplets, yes 2017-04-14 10:51:37 CBUILD="the computer we are running on" 2017-04-14 10:51:51 CHOST="the computer that will execute produced files" 2017-04-14 10:51:55 ok, so you have CBUILD too 2017-04-14 10:52:13 CTARGET="on gcc, the computer for which the generated compiler will produce files for" 2017-04-14 10:52:32 normally CBUILD=CHOST _or_ CHOST=CTARGET 2017-04-14 10:52:36 yeah, so unless you're packaging a compiler, CTARGET shouldn't be used 2017-04-14 10:52:41 yes 2017-04-14 10:52:42 you build from CBUILD to CHOST 2017-04-14 10:52:56 yes, that the gcc / autoconf idom 2017-04-14 10:52:59 idiom* 2017-04-14 10:56:36 fabled: is there some better way how to cross-compile from glibc on our infra than using docker like in ghc? 2017-04-14 10:57:00 depends on a lot of things 2017-04-14 10:57:51 ? 2017-04-14 10:58:29 why would you need docker? you just need a proper, non-leaky toolchain 2017-04-14 10:58:48 if you can't avoid leaking, a chroot is enough, you don't need a full container 2017-04-14 10:58:49 skarnet: +1 2017-04-14 10:59:00 skarnet: that’s exactly what i was thinking about 2017-04-14 10:59:16 skarnet: imo docker is totally unnecessary for this 2017-04-14 10:59:38 probably yes. it's matter of preference and ease of scripting for the one writing the bootstrap script 2017-04-14 10:59:42 I have proper musl toolchains at http://skarnet.org/toolchains/ but they're not Alpine-branded 2017-04-14 11:00:15 the problem with compilers written on their own language is that you need binary compiler to get started with 2017-04-14 11:00:38 so as long as we have some compiler that runs on alpine, and can be used to build the initial .apk, we are good to go 2017-04-14 11:01:01 fabled: we can download prebuilt binary linked against glibc from upstream 2017-04-14 11:01:12 if it works on musl, then great 2017-04-14 11:01:20 fabled: it doesn’t 2017-04-14 11:01:23 fabled: glibc 2017-04-14 11:01:48 fabled: unfortunately they still don’t provide actually portable binary or binary linked against musl 2017-04-14 11:01:50 so then we need someone to build it against musl, make static build out of it, or fix musl's glibc compat so the glibc version works 2017-04-14 11:02:19 currently I use rustc built against musl from VoidLinux 2017-04-14 11:02:26 before that I cross-compiled one myself 2017-04-14 11:03:04 actually the current binary in VoidLinux is probably initially built with mine 2017-04-14 11:03:34 but as I understand, we don’t wanna rely on binary from VoidLinux; moreover they don’t have rustc for armhf etc. 2017-04-14 11:03:51 (and rustc unfortunately cannot be statically linked) 2017-04-14 11:06:52 ah, the joys of modern languages designed by people who don't understand bootstrap 2017-04-14 11:09:19 <^7heo> ;) 2017-04-14 11:09:26 <^7heo> moin alle 2017-04-14 11:16:35 fabled: "or fix musl's glibc compat so the glibc version works" … not sure if it’s possible, https://hastebin.com/raw/eqajesewos 2017-04-14 11:17:24 jirutka, check on #musl 2017-04-14 11:22:03 10 bucks says rustc uses some dirty glibc ABI that kills binary compatibility with musl :P 2017-04-14 11:24:39 imo not rustc itself, but llvm… 2017-04-14 11:27:55 no, that’s probably nonsense 2017-04-14 11:32:02 when binary uses __register_atfork symbol, it should appear somewhere in the source code, right? 2017-04-14 11:32:31 b/c i can’t find "register_atfork" in rustc, liblibc or compiler-rt codebase 2017-04-14 11:37:03 skarnet: ^ did I wrote total nonsense or not? :) 2017-04-14 11:39:13 honestly I'm not sure. I don't know llvm or rustc, and how symbols are generated and appear in object files is still mysterious to me even with gcc. 2017-04-14 11:39:46 I don't think you wrote nonsense because that's the exact kind of question I could ask: "where does that fkn symbol come from?" 2017-04-14 11:39:54 but I don't have the answer. :P 2017-04-14 11:44:24 okay :) 2017-04-14 12:39:24 I’m gonna use VoidLinux for bootstrapping rust for Alpine :) it can be easily installed into chroot in the same way as Alpine 2017-04-14 12:57:00 i just used docker for the ghc-bootstrap port out of laziness, that and it did save a lot of time in not having to redo things like building cross compilers etc... 2017-04-14 13:28:35 skarnet: do you know about some more secure way how to do chroot without needing to allow mount command, to bind /proc, /sys, /dev? 2017-04-14 13:29:59 skarnet: or ideally some method that does not require root privileges, or just a minimum subset? some very minimal bare support for user “containers” :) 2017-04-14 13:30:57 I don't, but that shouldn't be a problem: mount your filesystems in your chroot, perform the chroot, then drop privileges before getting back to the user. 2017-04-14 13:31:21 skarnet: the second question is more an open question for discussion, it’s probably not possible, at least from what I know, but maybe you have some interesting ideas 2017-04-14 13:31:33 if it's a program that must be called in an apkbuild, then I'm afraid you need a setuid helper for this 2017-04-14 13:31:56 it's an open question really 2017-04-14 13:32:05 work on user containers is under way 2017-04-14 13:32:14 I remember that you have some interesting helper for sudo using sockets or something like that that allows better separation 2017-04-14 13:32:15 some things work, others don't yet 2017-04-14 13:32:42 yes, I do, but it requires running a server 2017-04-14 13:34:56 the problem is that we don’t allow mount in LXC containers for security reasons, so doing mount and then dropping privileges can’t help there; my only idea is to prepare proc sys and dev in advance, when starting lxc container 2017-04-14 13:35:10 i.e. if you want to run "foobar" as user foo, instead of making "foobar" suid foo, you run a daemon as user foo that does "s6-sudod foobar", and a client that wants to run foobar basically runs "s6-sudo socket-to-that-daemon", which runs foobar as user foo on the client's behalf 2017-04-14 13:36:00 yeah, that's a real problem 2017-04-14 13:36:27 you need root privileges at some point to mount the filesystems, so you kinda need to prepare your container in advance 2017-04-14 13:36:32 I don't have a good solution for this 2017-04-14 13:36:36 brb 2017-04-14 13:37:12 but not whole rootfs, just these binds 2017-04-14 14:15:42 jirutka: ping 2017-04-14 14:44:36 i have qt 5.8.0 in my queue 2017-04-14 14:44:59 i also move qt5*, vlc and wireshark to community 2017-04-14 14:45:39 i think im good to push, but i wonder if i should maybe wait til monday in case things break 2017-04-14 14:47:19 armhf is arelady broke 2017-04-14 14:47:25 so i push and hope it fixes things :) 2017-04-14 14:48:04 :P 2017-04-14 14:48:14 ncopa: i think we're almost done with rust to have it into a fully working state 2017-04-14 14:48:22 i have 1 patch to present to jirutka and one more to write 2017-04-14 14:48:27 and then it should be fully working... 2017-04-14 14:52:11 wow 2017-04-14 14:52:13 very nice 2017-04-14 14:52:23 thats a nice thing to have in the 3.6 release notes :) 2017-04-14 14:53:15 :) 2017-04-14 14:56:23 get ghc and idris in too please :) 2017-04-14 14:56:40 agda is a bit more involved but i'm working on it 2017-04-14 15:46:11 Shiz: I’m here, waiting for patch :) 2017-04-14 15:46:19 :P 2017-04-14 15:47:29 jirutka: https://txt.shiz.me/MDBkZjE1ND 2017-04-14 15:57:02 Shiz: perfect! 2017-04-14 15:57:11 one more patch left.. 2017-04-14 15:57:14 with the rpath :P 2017-04-14 16:20:10 since no one replied last time, I ask again: shouldn't pkgs, which depend on ncurses-terminfo, rather depend ncurses-terminfo-base since it's much smaller? 2017-04-14 16:23:41 xentec: Good question -- do all packages which currently depend on ncurses-terminfo work for all expected cases with only -base installed? 2017-04-14 16:24:34 I would think so, since the only thing -termbase provides is legacy 2017-04-14 16:45:01 jirutka: building with hopefully the final patch :) 2017-04-14 17:00:37 on the 4.9 kernel has anyone noticed "net.c:592: sendmsg() failed: Operation not permitted" (for dns queries - even with everything outbound allowed in iptables / ip6tables) - doesn't happen on the stable kernel 2017-04-14 18:10:18 jirutka: currently testing rustc with our build triple 2017-04-14 18:10:20 :) 2017-04-14 18:23:28 sup fellas 2017-04-14 18:29:00 hiya 2017-04-14 18:33:06 hey there shiz 2017-04-14 18:33:51 im curious, how many of you out there are building your own alpine iso's with your commonly installed apps on there 2017-04-14 18:43:42 mitchty: question 2017-04-14 18:43:53 mitchty: how do you bootstrap ghc onto a new architecture ? 2017-04-14 18:50:36 geekblogtv: i mostly use lbus for that 2017-04-14 18:50:39 no need for own alpine isos 2017-04-14 18:55:16 geekblogtv: I'm working on mkimage, including autoconfiguration of services. 2017-04-14 19:14:08 kaniini: iirc you crosscompile it from a debian glibc host using docker (see testing/ghc-bootstrap) 2017-04-14 19:35:38 kaniini: i was doing what nmeum_ was doing, but fabled setup the cross compile stuff so we should be able to use the x86_64 ghc and cross compile to the target arch 2017-04-14 19:36:10 so ghc-bootstrap become/became more an historical artifact of this is how we got x86_64 from a debian glibc to alpine linux setup 2017-04-14 19:37:57 oh, that's nice didn't know about that 2017-04-14 19:41:52 it should be somewhat easy to flesh out the rest of the architectures, but i don't have a ppc setup or armv8 (latter yet, working on getting one) or i'd port ghc to that too 2017-04-14 19:42:37 but ghc does have what is called an unregisterised build which should work, it might not be as speedy, but ironically enough the arm cross port is probably the hardest due to it requiring llvm 2017-04-14 19:43:19 that and i'm trying to use my ghc port to build other things to play with :) dependent types are... fun 2017-04-14 19:46:05 got it 2017-04-14 19:47:52 on that note, i have ghc 8.2 working as well its in rc status, but should I be keeping the ghc-bootstrap port up to date with what the ghc version is? 2017-04-14 19:48:49 getting that working is a lot of busy work, but not sure if it matters to keep the glibc->musl bridge up to date 2017-04-14 19:49:05 i wanted to work with the upstream to get musl libc to be more of a tier 1 platform 2017-04-14 19:59:05 kaniini: btw, bootstrapping rust will be doable i think 2017-04-14 19:59:07 from a glibc host 2017-04-14 20:13:56 Building stage1 compiler artifacts (x86_64-unknown-linux-musl -> x86_64-alpine-linux-musl) 2017-04-14 20:13:58 :) 2017-04-14 20:22:26 Shiz: you mean "x86_64-unknown-linux-gnu", don't you? 2017-04-14 20:23:03 doesn't rust use an embedded musl for its compiler or am I misremembering 2017-04-14 20:26:06 xentec: no? 2017-04-14 20:26:41 mitchty: only for distributions 2017-04-14 20:26:58 nevermind then 2017-04-14 20:28:40 Shiz: ok cool, i remember going through some of how rust worked and hit the embedded musl libc and decided the build process was complex and left it at that :) 2017-04-14 20:28:44 xentec: i'm just doing a local bootstrap now, not a glibc bootstrap 2017-04-14 20:28:46 :P 2017-04-14 20:39:35 ncopa, you there? I was wondering, why ncurses handles terminfo files the way it does (symlinking to /etc) and why everything ncurses related depends on the 6.5 MiB big ncurses-terminfo instead of much smaller ncurses-terminfo-base. 2017-04-14 20:40:20 the detailed technical explanation is that ncurses is a steaming pile 2017-04-14 20:41:38 I know that since the moment I've tried to use ranger on alpine :P 2017-04-14 20:52:49 Shiz: this may help you: https://gist.github.com/japaric/52b8816a4c86f5a4699bcc50ebc3e020 2017-04-14 20:53:14 jirutka: btw, we now have an x86_64-alpine-linux-musl rustc 2017-04-14 20:53:16 :) 2017-04-14 21:37:38 VoidLinux provides pkg cross-x86_64-linux-musl (also for arm and others), so we don’t even need to build own toolchain 2017-04-14 21:38:24 jirutka: ping 2017-04-14 21:38:26 :P 2017-04-14 21:38:55 Shiz: well, I know that I’ve suggested x86_64-alpine-linux-musl, but then I’ve realized that it’s maybe a bad idea 2017-04-14 21:39:11 jirutka: I provide better toolchains than Void does :P but aiui Alpine wants Alpine-branded toolchains 2017-04-14 21:39:40 x86_64-alpine-linux-musl instead of x86_64-linux-musl 2017-04-14 21:39:52 jirutka: actually, it's a very good idea 2017-04-14 21:40:04 because it allows us to cleanly separate our toolchain changes into a separate target 2017-04-14 21:40:08 static PIE support, mandatory rpath, etc 2017-04-14 21:40:14 skarnet: I believe that, but how it can help us with cross-compiling rustc on glibc system…? 2017-04-14 21:40:34 jirutka: i also reordered all patches kinda locally 2017-04-14 21:40:47 i've got a huge diff against upstream aports now 2017-04-14 21:40:49 D: 2017-04-14 21:40:54 jirutka: my toolchains are fully static, they don't care what system they're running on 2017-04-14 21:40:56 (but the patches are more cleanly separated now) 2017-04-14 21:41:23 Shiz: and what about x86_64-unknown-linux-musl, would this be still usable? 2017-04-14 21:41:40 jirutka: yes :) 2017-04-14 21:41:48 jirutka: it would be static by default, as with upstream 2017-04-14 21:41:51 and not support static pie 2017-04-14 21:42:40 skarnet: okay, I believe that they are awesome, but still, we just need to somehow bootstrap Rust, we must use “foreign” system for it and since Void already provides cross-compiling toolchain, I don’t see a reason why not use it, if it will work 2017-04-14 21:43:54 eh, not my problem if you want Alpine to be dependent on Void 2017-04-14 21:43:54 jirutka: https://txt.shiz.me/MTMzYTczMT 2017-04-14 21:44:00 this is what my APKBUILD looks like right now 2017-04-14 21:44:38 Shiz: “# Make sure to use the bundled LLVM.” what? 2017-04-14 21:44:52 jirutka: if build != host/target, it will attempt to recompile LLVM 2017-04-14 21:45:00 --llvm-root only applies to --build= 2017-04-14 21:45:20 but *bundled*? 2017-04-14 21:45:24 oh 2017-04-14 21:45:27 that should say 'not' 2017-04-14 21:45:28 system-provided… 2017-04-14 21:45:29 :) 2017-04-14 21:45:31 aha :) 2017-04-14 21:46:26 the only major difference is the re-organized patches and install() using make dist instead of make install 2017-04-14 21:46:36 because make install doesn't work on xcompilations 2017-04-14 21:47:20 why so? 2017-04-14 21:47:43 it will attempt to install $build 2017-04-14 21:47:50 instead of $host/$target... 2017-04-14 21:47:52 and it can’t be changed? 2017-04-14 21:47:56 believe me, I tried 2017-04-14 21:48:00 okay 2017-04-14 21:48:01 and turns out 2017-04-14 21:48:07 make install is an alias for the exact thing we're doing in APKBUILD 2017-04-14 21:48:09 :P 2017-04-14 21:48:32 minus the fucky build/host/target checking 2017-04-14 21:49:01 you don’t need _ctarget, just use CTARGET variable ;) 2017-04-14 21:49:09 this will also work for cross-compilation 2017-04-14 21:49:11 that is right 2017-04-14 21:49:13 :) 2017-04-14 21:51:07 jirutka: what do you think of the re-organized patches 2017-04-14 21:51:15 i used the following naming: 2017-04-14 21:51:24 musl-*: musl support patches that are intended to go upstream 2017-04-14 21:51:33 prefixless: othe rpatches that may go upstream 2017-04-14 21:51:38 alpine-*: patches that will likely never go upstream 2017-04-14 21:53:02 looks good! 2017-04-14 21:53:20 btw about filecheck, I’ve added it to llvm3.9-dev 2017-04-14 21:53:47 it’s in /usr/lib/llvm3.9/bin/FileCheck 2017-04-14 21:54:52 ah, so we don't need that anymore? 2017-04-14 21:55:17 it’s needed for codegen tests 2017-04-14 21:55:38 hm, I would keep that patch anyway 2017-04-14 21:55:44 why's that 2017-04-14 21:56:21 b/c it’s really not needed for build, only for tests 2017-04-14 21:56:36 well, then there's also no reason to keep the patch, is there? 2017-04-14 21:56:37 P 2017-04-14 21:56:40 :P 2017-04-14 21:56:49 we can add /usr/lib/llvm3.9/bin to PATH for tests, but I don’t feel like to add it even for build 2017-04-14 21:57:02 jirutka: not needed 2017-04-14 21:57:22 not needed in reality, but this build script still checks if it’s available 2017-04-14 21:57:42 yes but 2017-04-14 21:57:49 you don't need to add /usr/lib/llvm3.9/bin to path 2017-04-14 21:57:51 even if it did 2017-04-14 21:57:55 it will find it there automatically 2017-04-14 21:58:01 really? 2017-04-14 21:58:03 yes 2017-04-14 21:58:13 aha, didn’t know that! 2017-04-14 21:58:16 because of --llvm-root/llvm_config= 2017-04-14 21:58:17 then get rid of the patch :) 2017-04-14 21:58:55 doing a final build now 2017-04-14 21:59:00 before throwing my huge patch at you 2017-04-14 21:59:02 :D 2017-04-14 22:02:53 jirutka: btw what was the trouble you were getting with the tests? 2017-04-14 22:12:27 Shiz: tests in rust? 2017-04-14 22:12:36 yeah 2017-04-14 22:12:42 the XXX'd out make test one 2017-04-14 22:12:42 well… try yourself… ;) 2017-04-14 22:12:45 or make check 2017-04-14 22:13:33 also I can’t find a way how to tell them to not stop after first suite failure 2017-04-14 22:13:50 and the order is random… 2017-04-14 22:14:15 https://github.com/rust-lang/rust/issues/40219 2017-04-14 22:32:46 jirutka: build complete :) 2017-04-14 22:33:39 https://txt.shiz.me/NWNiNTc4NW 2017-04-14 22:35:16 have you tried to compile something with --target=x86_64-unknown-linux-musl ? 2017-04-14 22:36:12 i'm running cargo tests rn 2017-04-14 22:36:32 but yeah, gimme a sec 2017-04-14 22:44:05 jirutka: down to 3 cargo test failures :) 2017-04-14 22:45:20 jirutka: right, we don't install the stdlib for x86_64-unknown-linux-musl 2017-04-14 22:45:44 and that’s what I was afraid about 2017-04-14 22:45:59 do you want it added to rust-stdlib? 2017-04-14 22:46:09 ? 2017-04-14 22:46:18 the stdlib for x86_64-unknown-linux-musl 2017-04-14 22:46:44 this should be the same as x86_64-alpine-linux-musl, no? 2017-04-14 22:46:51 i wonder 2017-04-14 22:46:59 but i think so, yes 2017-04-14 22:47:04 maybe what if you just create symlink in /usr/lib/rustlib …? 2017-04-14 22:47:40 just tried 2017-04-14 22:47:41 doesn't work 2017-04-14 22:47:46 it checks a triple in the metadata 2017-04-14 22:47:55 hm :/ 2017-04-14 22:48:11 that’s why I eventually wrote that it’s maybe not a good idea to use different triplet 2017-04-14 22:48:24 but still not sure… 2017-04-14 22:48:45 well 2017-04-14 22:48:47 the thing is 2017-04-14 22:49:04 what do you want to achieve with using the same triplet as upstream? 2017-04-14 22:49:07 our features are different 2017-04-14 22:49:19 so i think it makes sense to have a different triplet 2017-04-14 22:49:38 yes, I agree with that 2017-04-14 22:50:10 and it's not too hard to add x86_64-unknon-linux-musl stdlib stuff if we want upstream compat 2017-04-14 22:50:40 but it’s quite silly, the binaries would be the same, except metadata… 2017-04-14 22:50:47 they might not be 2017-04-14 22:50:52 nothing guarantees this, after all 2017-04-14 22:51:04 how can they be different? 2017-04-14 22:51:10 rlibs 2017-04-14 22:51:22 PIE does not affect static libraries, right? 2017-04-14 22:54:02 the llvm target is different 2017-04-14 22:54:14 so it depends on to what extent we patch llvm too 2017-04-14 23:04:56 jirutka: anyway 2017-04-14 23:04:59 want my patches? :P 2017-04-14 23:05:04 yeah! 2017-04-14 23:11:05 jirutka: https://txt.shiz.me/ZGU2Nzk0Nz 2017-04-14 23:24:11 Shiz: thanks! I’ll review it and apply tomorrow; I go to sleep now 2017-04-14 23:24:18 :) 2017-04-14 23:24:20 sleep well 2017-04-14 23:36:37 jirutka: Goodnight. We should be ready to rearrange repos early next week for mkinitfs/mkimage & friends. 2017-04-15 01:03:28 jirutka: dont merge yet, updated patch on its way tomorrow somewhere 2017-04-15 01:03:32 should fix all cargo tests 2017-04-15 01:12:27 jirutka: all cargo tests pass! \o/ 2017-04-15 01:51:39 Nice work Shiz & jirutka! 2017-04-15 08:51:04 morning 2017-04-15 10:06:59 jirutka: https://txt.shiz.me/ZTJiNGM1Nz 2017-04-15 10:07:05 final patch from me I think 2017-04-15 10:12:15 hi guys 2017-04-15 10:12:28 qt5-qtbase-dev is broken 2017-04-15 10:12:29 apk add qt5-qttools-dev 2017-04-15 10:12:29 ERROR: unsatisfiable constraints: 2017-04-15 10:12:29 openssl-dev-1.0.2k-r0: 2017-04-15 10:12:29 conflicts: libressl-dev-2.4.5-r0[pc:libcrypto=1.0.2k] libressl-dev-2.4.5-r0[pc:libssl=1.0.2k] libressl-dev-2.4.5-r0[pc:openssl=1.0.2k] 2017-04-15 10:12:32 satisfies: world[openssl-dev] freerdp-dev-1.2.0-r2[pc:libssl] 2017-04-15 10:12:34 libressl-dev-2.4.5-r0: 2017-04-15 10:12:36 conflicts: openssl-dev-1.0.2k-r0[pc:libcrypto=2.4.5] openssl-dev-1.0.2k-r0[pc:libssl=2.4.5] openssl-dev-1.0.2k-r0[pc:openssl=2.4.5] 2017-04-15 10:12:39 satisfies: qt5-qtbase-dev-5.8.0-r0[libressl-dev] freerdp-dev-1.2.0-r2[pc:libssl] 2017-04-15 11:34:05 fcolista: apk del openssl-dev 2017-04-15 11:46:12 Shiz: great work! 2017-04-15 11:46:46 Shiz: could you please separate actual changes and reorganization of patches into separate commits? it’s hard to spot what have you changed now 2017-04-15 11:48:17 Shiz: actually there should be at least three commits: reorganization of patches, custom alpine target and the one that fixed remaining cargo tests 2017-04-15 12:04:40 i fixed some of the patches while reorganizing them :P 2017-04-15 12:07:43 and that’s the problem, then it’s hard to recognize that have been actually fixed 2017-04-15 13:19:38 Shiz, gr8 2017-04-15 13:19:39 thx 2017-04-15 16:31:56 re: rust + llvm4: rkruppe │ Yeah we're almost done upgrading to LLVM 4.0 2017-04-15 16:40:10 if lld becomes production ready, would it be feasible to use musl+libc++ with clang and llvm as system backbone and drop gcc/use it only for kernel compilation? 2017-04-15 16:59:37 feasible: maybe 2017-04-15 16:59:42 desirable: not sure 2017-04-15 18:15:52 Shiz: how it looks with your patches? 2017-04-15 18:17:14 not sure how to start approaching it 2017-04-15 18:17:39 well, you have created them, so you should now better than me ;) 2017-04-15 18:17:58 well, it's just that i chanaged and reorganized a lot 2017-04-15 18:18:07 it's such a pain to manually undo all of it 2017-04-15 18:18:09 :( 2017-04-15 18:20:04 now imagine how difficult it must be for anyone else to recognize what you have actually changed if it’s even for you hard to reapply them 2017-04-15 21:38:25 <^7heo> Do ew have to add the || return 1 in new APKBUILDs? 2017-04-15 21:38:39 <^7heo> s/ew/we/ 2017-04-15 21:38:43 no 2017-04-15 21:38:47 <^7heo> ok 2017-04-15 21:39:37 xentec: clang iirc needs to be hardened a bit (static PIE, dynamic PIE) 2017-04-15 21:41:37 <^7heo> kaniini: https://github.com/alpinelinux/aports/pull/1260 2017-04-15 21:41:55 <^7heo> if you feel like you have too much free time right now ;) 2017-04-15 21:44:20 ^7heo: done 2017-04-15 21:44:49 <^7heo> :D 2017-04-15 21:45:00 <^7heo> thanks! ;) 2017-04-15 21:45:36 <^7heo> that's pretty cool, now we have irssi otr. 2017-04-15 21:45:38 <^7heo> btw 2017-04-15 21:45:44 <^7heo> I tried to upgrade irssi to 3.5 today 2017-04-15 21:45:50 <^7heo> the -perl package wouldn't work. 2017-04-15 21:46:06 <^7heo> I dunno if anyone tested it... 2017-04-15 21:56:07 is kunkun here? 2017-04-15 21:56:16 sry, kunkku 2017-04-15 21:56:43 kunkku: your commit failed: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/zoneminder/zoneminder-1.30.2-r3.log 2017-04-15 21:57:42 kunkku: quite obviously, because source filename is the same, so builder used the old cached source 2017-04-15 22:04:41 jirutka: the problem is that upstream has changed an already published version 2017-04-15 22:05:46 kunkku: I understand that, but builder still uses the old cached version 2017-04-15 22:06:10 ok I need to rename the file 2017-04-15 22:06:13 i lack sufficient whiskey to debug this ppc64le chicken problem 2017-04-15 22:06:18 so disabled it for the moment 2017-04-15 22:06:42 kunkku: so you have to rename the tarball, e.g. add $pkgrel to it (e.g. zoneminder-$pkgver-r$pkgrel.tar.gz) 2017-04-15 22:07:38 kunkku: and please speak to upstream with a baseball ball… :) 2017-04-15 22:10:00 sure... 2017-04-15 22:13:48 baseball bat, you mean 2017-04-15 23:23:30 kaniini: eh, typo, I meant baseball rocket :) 2017-04-15 23:24:23 huh, no, it’s really called baseball bat o.O 2017-04-16 00:30:23 jirutka: Personally, I prefer a good ol' clue-by-four :) 2017-04-16 01:08:14 Does anyone have a fast way of comparing a potentially long list of file globs against filenames in a file (fnmatch style)? 2017-04-16 01:09:07 (without resorting to gawk extensions) 2017-04-16 10:53:39 <^7heo> hiro: the people on the main channel aren't all knowledgable. 2017-04-16 10:53:53 <^7heo> hiro: look at how many of use are *NOT* on the main channel 2017-04-16 10:53:58 hahaha 2017-04-16 10:53:59 <^7heo> hiro: just to avoid them 2017-04-16 10:54:06 i guess i'll have to do the same 2017-04-16 10:54:13 <^7heo> yeah it's a sensible thing to do. 2017-04-16 10:54:16 guilty as charged 2017-04-16 10:54:22 <^7heo> exactly 2017-04-16 10:54:32 also reminds me: i should run 9front for my irc sessions again 2017-04-16 10:54:45 then i don't have to fear being attacked by his stupid 0day irssi exploits 2017-04-16 10:55:21 <^7heo> ? 2017-04-16 10:55:28 <^7heo> How would 9front help with that? 2017-04-16 10:55:45 ^7heo: lack of market 2017-04-16 10:55:53 ^7heo: for 9front there are no usable exploits sold 2017-04-16 10:55:59 ^7heo: so he'll be hopeless 2017-04-16 10:56:10 ^7heo: he'd have to understand how to use the rc shell 2017-04-16 10:56:15 ^7heo: i'm sure that's too much for him. 2017-04-16 10:56:27 <^7heo> ahhh, that's the sarcastic continuation of the disucssion from the main channel 2017-04-16 10:56:48 yes :) 2017-04-16 10:56:55 i thought that's what you were refering to 2017-04-16 10:57:00 <^7heo> to make fun of that stupid luser who knows nothing about security whatsoever but has a HUGE mouth 2017-04-16 10:57:17 <^7heo> yeah I was referring to that when I wrote what skarnet answerded to ;) 2017-04-16 10:58:23 <^7heo> but I didn't follow the logic of the joke up to chrome -> opera == anything -> 9front 2017-04-16 10:58:27 <^7heo> while it is completely valid ;) 2017-04-16 10:58:44 <^7heo> (at least about the size of the user base) 2017-04-16 11:06:06 <^7heo> what a fucking waste of time. 2017-04-16 11:09:06 <^7heo> can someone paste the topic of #alpine-linux in a query with me please? ;) 2017-04-16 11:09:31 <^7heo> I can't get it via chanserv... 2017-04-16 11:09:37 <^7heo> (or I don't know how) 2017-04-16 12:47:12 this reminds me 2017-04-16 12:47:35 who in the devil's name has included gr-sec stuff in alpine? 2017-04-16 12:47:46 this is the shit that attracts retards like that... 2017-04-16 12:48:04 all snakeoil shit giving them an excuse for their existence 2017-04-16 12:59:54 hiro: pardon me? 2017-04-16 13:01:09 jirutka: you put it in? 2017-04-16 13:01:10 hiro: grsecurity is in Alpine for very long time, it increases security and Grsecurity project used to be open before… now the situation is very different, actually we’re already discussing about removing grsecurity from Alpine 2017-04-16 13:01:25 oh wow! 2017-04-16 13:01:35 that makes me quite happy actually, haha 2017-04-16 13:01:44 hiro: no, I didn’t, it was here before I came to Alpine 2017-04-16 13:02:17 hiro: you can talk with kaniini about it, he’s probably most involved in replacing grsecurity 2017-04-16 13:02:20 i'm not sure why you're convinced it increased security. but then i'm not that well versed on the topic anyway, so... 2017-04-16 13:02:45 what is it being "replaced" with? 2017-04-16 13:03:59 hiro: I don’t know, please ask kaniini 2017-04-16 13:04:29 thanks 2017-04-16 13:04:53 were the discussions on the mailing list? 2017-04-16 13:05:05 i might just read those to waste less time of people here 2017-04-16 13:05:59 it's being replaced with apparmor+PaX, AFAIK. And I don't know much more 2017-04-16 13:06:49 I'm not convinced either that it's useful (it's always been detrimental to me), but apparently corporate loves it, so... 2017-04-16 13:08:58 great reason *ugh* 2017-04-16 13:09:17 as an individual user, you don't have to use it 2017-04-16 13:09:56 i guess somebody receives money then oO 2017-04-16 13:10:14 hiro: unfortunately no… 2017-04-16 13:10:22 for grsec? no, but Alpine receives users 2017-04-16 13:10:54 you shouldn't try to attract users with *features* 2017-04-16 13:11:01 then they can just use redhat 2017-04-16 13:11:16 and *you* shouldn't try to tell Alpine devs what they should or should not do. :P 2017-04-16 13:11:22 the opposite would be the appropriate behavior for alpine's niche :) 2017-04-16 13:11:36 skarnet: you mean it's a waste of my time? 2017-04-16 13:11:48 skarnet: i've been probably wasting all my day talking today 2017-04-16 13:11:50 hiro: please calm down with this aggressive attitude… 2017-04-16 13:12:11 skarnet: so i agree that it's probably not productive enough. 2017-04-16 13:12:46 jirutka: in this channel here? 2017-04-16 13:12:49 that, and also it's disrespectful to Alpine devs, who actually have assessed the advantages and drawbacks of providing, or not providing, those features, and if they've chosen to provide them, maybe there's a reason. 2017-04-16 13:13:01 hiro: if you have better security enhancement for Linux kernel and wanna integrate it into Alpine, we’d welcome it 2017-04-16 13:13:41 Again, I don't like grsec more than you do, but as long as I can opt out, I'm not going to complain, especially if Alpine's success comes at this price. 2017-04-16 13:13:44 skarnet: i'm not sure i know the devs personally, as long as i don't i expect them to take a user's complaint professionally and try to concentrate on the actual points rather than it's tone. 2017-04-16 13:14:25 jirutka: my security enhancement consists of rebuilding the kernel myself with only the stuff activated that i need. 2017-04-16 13:14:39 jirutka: i doubt there's a better way for anybody else, but it requires manual work obviously. 2017-04-16 13:14:54 *individual* manual work 2017-04-16 13:15:30 hiro: that's because you control what you run on your machine. grsec, and equivalent functionality, is aimed at sysops who *don't* control their whole stack, and need confinement. 2017-04-16 13:15:44 Yes, I deplore that it's necessary. But that's the real world. 2017-04-16 13:15:51 i don't know what alpine devs do, how many there are, how much work it was. i will never know for sure. 2017-04-16 13:16:04 and thus i don't *allow* them to feel judged by me, regardless of what i say :P 2017-04-16 13:17:09 skarnet: you might be right that alpine would have less users if only individuals like me used it... but i'll always ask for what i *personally* need, cause that's the only thing i know about. 2017-04-16 13:17:29 and that's fine. And the answer is: use alpine-vanilla. 2017-04-16 13:17:53 sorry 2017-04-16 13:38:22 ^7heo │ I can't get it via chanserv... 2017-04-16 13:38:27 /list #alpine-linux 2017-04-16 14:03:05 <^7heo> ah thanks Shiz 2017-04-16 14:34:43 Happy easter. Is anyone of the Wiki admins online? 2017-04-16 14:36:21 Kind of 2017-04-16 14:36:27 I'm a technical writer and registered a new Wiki account, but can't post the new documentation I wrote, because the Wiki tells me that new users are not allowed to add links to the Wiki. 2017-04-16 14:36:37 Yes 2017-04-16 14:36:47 The only external link my procedure contains is to the Alpine Linux download page 2017-04-16 14:36:50 Takes 5 hours 2017-04-16 14:37:31 I can post it 5h after I created the account? 2017-04-16 14:37:50 That's what they told me 2017-04-16 14:37:59 It was 5 days before 2017-04-16 14:38:42 Ok, that's fine. I can try it later again. 2017-04-16 14:38:52 Sorry about that 2017-04-16 14:40:23 No problem. In the Samba team, new users have to request a password from us before they can log in to the Wiki. We also had this spam problem in the past. 2017-04-16 14:41:01 One further question: I added an email address to my Wiki account, but no confirmation mail was sent. When I click to "confirm your email addresses" in my preferences, it tells me that my email address is invalid. 2017-04-16 14:41:54 Are mail addresses blocked that contain "alpine.linux" in the prefix? I created an email alias on my mailserver for AL. 2017-04-16 14:42:13 not that i know of 2017-04-16 14:44:49 I requested the mail again (the same way). Now it was sent. Maybe there's a kind of delay for spam protection, too. 2017-04-16 14:46:42 I removed the external link to the AL download page for now. I will add it later. 2017-04-16 14:48:02 And here is the new doc: https://wiki.alpinelinux.org/wiki/LVM_on_LUKS I rewrote the whole procedure because it was outdated and some important steps missing to get a bootable system. Additionally, the previous version was basically just a list of commands without details. I hope the new documentation is useful. 2017-04-16 14:48:10 Keep up the great work on AL. 2017-04-16 14:50:55 Marc_M: very nice, we needed an updated page on that :) 2017-04-16 14:50:59 good job 2017-04-16 14:54:11 Shiz, yw 2017-04-16 16:46:53 llvm and clang 4.0: https://github.com/alpinelinux/aports/pull/1261 2017-04-16 17:13:51 jirutka: doing a final compile now 2017-04-16 17:13:58 after pulling apart 2017-04-16 17:14:02 pulling everything apart* 2017-04-16 17:15:41 we are leaving grsec alone for now and seeing what happens actually 2017-04-16 17:16:26 good 2017-04-16 17:58:14 jirutka: running tests... 2017-04-16 18:06:43 jirutka: all tests passed! \o/ 2017-04-16 18:11:18 jirutka: just gonna PR this one because it's so many patches 2017-04-16 18:11:20 lol 2017-04-16 18:22:01 Shiz: thanks! I’m very happy that you did it, I was afraid that I will have to refactor them myself 2017-04-16 18:23:03 Shiz: kaniini: you may be interested in helping with https://github.com/alpinelinux/aports/pull/1261 :) 2017-04-16 18:24:07 jirutka doing easter shit but after that i will review it 2017-04-16 18:24:16 jirutka: https://github.com/alpinelinux/aports/pull/1262 2017-04-16 18:24:35 i didn't bump the cargo pkgrel because it's just a change in the APKBUILD, not in its result product, I think 2017-04-16 18:26:57 maybe I'm wrong though -- would need to double-check 2017-04-16 18:27:06 jirutka: looks like Rust will be getting LLVM 4.0 support in 1.18, most likely 2017-04-16 18:27:21 which is ... 2017-04-16 18:27:26 ACTION takes out calendar 2017-04-16 18:27:44 barely not in time for 3.6, i think 2017-04-16 18:33:20 jirutka: you sure there's nothing that depends on llvm3.8? 2017-04-16 18:33:36 Shiz: I’m not, we must to find out 2017-04-16 18:34:01 also, you should update compiler-rt together with llvm, most likely 2017-04-16 18:34:07 Shiz: I hope that all what currently depends on llvm 3.8 can use 4.0, 3.9 or 3.7 :) 2017-04-16 18:34:11 :P 2017-04-16 18:34:16 what do we keep 3.7 around for 2017-04-16 18:34:17 yes, it’s on TODO list ;) 2017-04-16 18:34:18 ghc? 2017-04-16 18:34:21 yes 2017-04-16 18:34:35 3.9 for Rust and probably Julia 2017-04-16 18:34:51 right 2017-04-16 18:34:52 that needs to be updated as well :/ 2017-04-16 18:35:07 so packages im fairly sure will be fine with llvm4: 2017-04-16 18:35:11 main/compiler-rt 2017-04-16 18:35:15 testing/lldb 2017-04-16 18:35:21 (may need updating themselves though) 2017-04-16 18:35:39 i think mesa is fine too with llvm4 2017-04-16 18:38:01 jirutka: does that list also include packages that rely on clang? 2017-04-16 18:38:13 hmm… 2017-04-16 18:38:15 not sure tbh 2017-04-16 18:38:37 crystal & dotnet-core require 4 2017-04-16 18:38:39 because those may rely on libclang or whatever 2017-04-16 18:38:40 no, it does not 2017-04-16 18:38:43 well, crystal can work on 3.8/3.9/4 2017-04-16 18:38:54 but they recommend 4 2017-04-16 18:39:37 i think moving to 4 and dropping 3.8 is safe 2017-04-16 18:39:50 only afl depends on clang-libs 2017-04-16 18:39:52 but i will set up an exp-run when i get back 2017-04-16 18:41:03 i'd really like to put ghc on 3.9 though but i understand it's a bunch of effort 2017-04-16 18:41:17 btw who’s Travis Tilley? is he still active? 2017-04-16 18:41:57 ttilley is not active anymore i do not believe :( 2017-04-16 18:44:15 okay, any volunteer to take mainteinership of llvm packages? :) currently main/llvm is assigned to Tilley, llvm3.7, llvm3.9 and new llvm4 to me, but I don’t feel very competent to maintain llvm pkgs 2017-04-16 18:44:53 wasn't there someone doing ghc stuff lately? 2017-04-16 18:44:56 i seem to recall such a thing 2017-04-16 18:45:05 yes, Mitch 2017-04-16 18:45:19 maybe ask him :P 2017-04-16 18:45:32 not before we move ghc into community… :) 2017-04-16 18:45:46 jirutka: btw, you got to take a look at PR1204? 2017-04-16 18:46:04 i'd feel sorry if we didn't merge after he did everything we asked 2017-04-16 18:46:06 :P 2017-04-16 18:47:22 Shiz: hm, I see, yet another broken daemon how insists to manage PID file itself, even when you tell it to not daemonize 2017-04-16 18:47:32 Shiz: I’ve patched similar case just few days ago in different pkg 2017-04-16 18:47:34 not a problem here at least 2017-04-16 18:47:43 what does it matter if ssd and the daemon write the same pid to the same pidfile 2017-04-16 18:47:45 :P 2017-04-16 18:47:53 "pdns will always format the pid filename as pdns.pid" ? 2017-04-16 18:48:32 jirutka: pdns has a concept of instances 2017-04-16 18:48:56 the main instance is pdns.pid, other named instances are pdns-$name.pid 2017-04-16 18:48:57 but each instance is started by init system, right? 2017-04-16 18:48:58 apparently 2017-04-16 18:49:00 yes 2017-04-16 18:49:04 aha, so it even manages it’s own instances?! 2017-04-16 18:49:10 well 'manages' 2017-04-16 18:49:14 it writes a pidfile for them 2017-04-16 18:49:20 omg, don’t tell this skarnet… 2017-04-16 18:49:28 ln -s pdns /etc/init.d/pdns.myinstancename 2017-04-16 18:49:35 # service start pdns.myinstancename 2017-04-16 18:49:36 is how it works 2017-04-16 18:49:56 so it's still managed by the init system 2017-04-16 18:50:00 all it does is write its own pidfiles 2017-04-16 18:50:02 this is the result of decades with shitty init system like SysV init… software doing work that init system should do 2017-04-16 18:50:18 well, so where’s the problem? 2017-04-16 18:50:45 if all instances is started by OpenRC and OpenRC writes the pid file, not the daemon itself, then the daemon should not care about the pidfile name…? 2017-04-16 18:51:28 yeah, it's not a problem 2017-04-16 18:51:38 it's just that there would be multiple pidfiles in /run 2017-04-16 18:51:41 but that's now all resolved 2017-04-16 18:51:43 :p 2017-04-16 18:51:49 aha, I understand now, reading too quickly… 2017-04-16 18:51:56 but 2017-04-16 18:52:04 it seems like it doesn't actually write the pidfile when you tell it --daemon=no 2017-04-16 18:52:06 :P 2017-04-16 18:52:08 so yeah 2017-04-16 18:52:33 so it’s how I assumed, pdns alyways creates pid file, so if you choose different name for pidfile in OpenRC, then you end up with two pid files for one process, right? 2017-04-16 18:52:52 that's what i thought too until i read the pdns code just now 2017-04-16 18:52:58 it doesn't write a pidfile with --daemon=no, which is what we pass it 2017-04-16 18:53:01 so it's a non-issue after all 2017-04-16 18:53:52 okay, so we can replace `/run/${RC_SVCNAME/./-}.pid` with just `/run/$RC_SVCNAME.pid` ? 2017-04-16 18:54:27 lemme double-check 2017-04-16 19:01:50 jirutka: okay i was wrong 2017-04-16 19:01:56 it always writes the pidfile unless you give it a speciifc option 2017-04-16 19:01:59 thati 'm trying to find 2017-04-16 19:04:23 jirutka: --write-pid=no 2017-04-16 19:04:25 :) 2017-04-16 19:04:30 bingo! :) 2017-04-16 19:04:38 jirutka: so replace `/run/${RC_SVCNAME/./-}.pid` with just `/run/$RC_SVCNAME.pid` and add --write-pid=no to the args 2017-04-16 19:04:46 i propose we do it for him, guy has already changed so much 2017-04-16 19:04:48 :P 2017-04-16 19:06:28 okay 2017-04-16 19:33:16 lolpdns 2017-04-16 19:45:03 skarnet: tbh pdns is really good when you're running a hosting company 2017-04-16 19:45:52 and systemd is really good when you don't know anything better 2017-04-16 19:46:29 i don't think that is fair. pdns sql backend is really powerful 2017-04-16 19:47:42 DNS data is key-value, you don't need a relational database to store it, so why is "sql backend for DNS" even a thing 2017-04-16 19:47:47 in fkn 2017 2017-04-16 19:48:23 skarnet: customer portal 2017-04-16 19:49:08 is that the fashionable answer for every bad technical decision? 2017-04-16 19:49:22 it's not the /fashionable/ answer 2017-04-16 19:49:44 the fashionable answer is "startup customer portal" 2017-04-16 19:50:15 but then sql is not fashionable, so it's very hard to determine just how fashionable a startup consumer portal based on sql would be in practice. 2017-04-16 19:50:23 i would err on the side of "out of style" 2017-04-16 20:08:38 actually i like the pdns pipe backend, where i can script my responses, allows for very flexible hacks with different responses based on e.g. who is asking. perfect for abusing dns (clients) 2017-04-16 23:18:32 skarnet: i managed a DNS server cluster with millions of domains and also many rdns zones and having it all via SQL made it very convenient to build out customer access 2017-04-16 23:19:44 I don't doubt that it's workable 2017-04-16 23:19:58 or even convenient, if the software modules already exist 2017-04-16 23:20:14 I'm just saying that's overengineered. 2017-04-16 23:20:46 (and that sql should die, but that's a personal opinion) 2017-04-16 23:21:36 as if the rest isn't a personal opinion 2017-04-16 23:21:38 :P 2017-04-16 23:22:05 I've backed the rest up with scientific reasoning. 2017-04-16 23:22:38 then i'm either blind or your messages didn't come through 2017-04-16 23:22:39 :P 2017-04-16 23:22:54 DNS data is key-value, you don't need a relational database to store it, so why is "sql backend for DNS" even a thing 2017-04-16 23:23:49 now of course if you mix DNS data with regular user data you need a relational db for... >.> 2017-04-16 23:25:50 its convenient to use the same methods for storing DNS data if you already use SQL for a customer portal :) 2017-04-16 23:26:05 I guess. 2017-04-16 23:26:39 wlel, that is how features at hosting companies like "update my RDNS inside the portal" work :) 2017-04-16 23:26:40 ACTION envisions skarnet's DNS with /var/dns/mydomain.tld/A/ managed by unix permissions 2017-04-16 23:26:42 ;p 2017-04-16 23:27:17 Shiz: I would actually love that :D 2017-04-16 23:27:41 Shiz: don't give him ideas 2017-04-17 00:44:20 skarnet: Any thoughts on a posixish fast means of running fnmatch globs against a field in a file more quickly than a looped case statement checking per line of input? 2017-04-17 00:46:08 premature optimization detected 2017-04-17 00:47:13 Okay... 2017-04-17 00:47:42 if you want real speed: convert your fnmatches to regexes and use grep -f :) 2017-04-17 00:48:12 Yeah, that's what I've done everywhere else, but I need to work with existing globs. 2017-04-17 00:49:01 grep using fnmatch globbing would be ideal, but while I recall such an animal being around many years ago, I haven't turned it up again with a casual search. 2017-04-17 00:49:28 yeah, I'm not aware of anything doing that 2017-04-17 00:49:53 but unless you benchmark and it really proves to be a bottleneck, don't worry about it and shellscript away 2017-04-17 00:50:25 Considering how BRE swallows patterns vs globbing, I can't think of a quick, easy sed script to fix it. 2017-04-17 00:51:12 Yesh, it's one of the bigger issues I'm hitting. I've already cut total run time in half by using grep -F -f wherever possible and using intermediate files rather than pipes. 2017-04-17 00:51:36 I've never wondered about that before, but how hard is it to convert fnmatches to regexes 2017-04-17 00:51:53 shouldn't be that hard in this direction 2017-04-17 00:52:12 It seems like it should be easy, but then you run into greediness differences. 2017-04-17 00:52:55 anything you can't fix by using EREs ? 2017-04-17 00:53:08 Probably not, but then the speed benefit is gone. 2017-04-17 00:53:58 3900+- lines to scan for somewhere between a dozen and a couple hundred globs. 2017-04-17 00:56:08 lolwut 2017-04-17 00:56:12 Fast enough if it can be scanned using a simple table and DAG, not fast if it has to start doing lookbehind regexes to emulate globbing. 2017-04-17 00:56:26 but it shouldn't 2017-04-17 00:56:51 The list of modules and firmware in a manifest file vs. the set of globs for the initfs features. 2017-04-17 00:58:20 why would regexec() be slow where fnmatch() is fast 2017-04-17 00:59:01 ah, foo/*/* 2017-04-17 00:59:32 meh, just write a specific C program if you need to avoid the shell's overhead. 2017-04-17 01:14:36 skarnet: "(and that sql should die, but that's a personal opinion)" … are you kidding?! 2017-04-17 01:16:08 nope, not kidding. But I hope I'm allowed to have personal opinions without every single one being questioned and debated. 2017-04-17 01:18:14 okay… 2017-04-17 01:18:23 i’d rather go sleep :) 2017-04-17 01:35:08 skarnet: Not to start a debate (because I somewhat agree), but what would you use in place of SQL? 2017-04-17 01:37:53 I wouldn't use a programming language. I'd design a C API to perform reldb requests, and binding in other languages. 2017-04-17 01:38:19 If a protocol was needed, I'd design a protocol that's easily parsable and writable programmatically. 2017-04-17 01:38:26 With proper quoting, no injection. 2017-04-17 01:39:18 SQL mixes 3 different purposes in one bastard tool, that's why it sucks. 2017-04-17 01:39:31 And I also need to go to sleep. :) 2017-04-17 03:08:09 C APIs tend to translate shittily to other languages 2017-04-17 11:55:31 skarnet: it seems for me that you don’t understand the purpose of SQL… 2017-04-17 11:56:41 it seems to me that I had clearly expressed my lack of interest in discussing this 2017-04-17 11:57:08 okay, sry :) 2017-04-17 15:12:02 heyo 2017-04-17 15:12:39 Shiz: hi! 2017-04-17 15:15:17 hows life 2017-04-17 15:17:26 <^7heo> does anyone here know how the kernel decides how many CHS/tracks there are on a given drive? 2017-04-17 15:17:49 <^7heo> and how to ensure it is consistent and doesn't cause problems during use? 2017-04-17 15:18:10 quite good, but don’t feeling well know 2017-04-17 15:18:14 <^7heo> I'm struggling because I have a 16GB drive that is seen with 32 sectors/track 2017-04-17 15:18:38 ^7heo: isn’t this number total irrelevant these days? 2017-04-17 15:18:45 <^7heo> I have NO clue. 2017-04-17 15:18:50 <^7heo> I see fdisk warning me about various stuff 2017-04-17 15:18:53 <^7heo> so I'm asking. 2017-04-17 15:19:15 <^7heo> also if you know where to ask, I'd be very glad. 2017-04-17 15:19:33 me neither, just remember settings this like 15 years ago in BIOS and even when I set some absurd values here, it somehow worked 2017-04-17 15:19:41 <^7heo> yeah 2017-04-17 15:19:45 <^7heo> but really 2017-04-17 15:19:54 <^7heo> I do NOT understand any of this. 2017-04-17 15:20:02 <^7heo> LBA would be great, but fdisk is always using CHS for some reason. 2017-04-17 15:20:02 me neither tbh 2017-04-17 15:20:11 wait… what? 2017-04-17 15:21:01 <^7heo> well it's at least DIPLAYING the CHS 2017-04-17 15:21:20 jirutka: be well 2017-04-17 15:21:25 dont overexert yourself 2017-04-17 15:21:39 <^7heo> I have some mail from Theodore Tso in my mail somewhere explaining something about CHS if I recall correctly 2017-04-17 15:21:44 <^7heo> I wrote him directly and he was nice enough to answer. 2017-04-17 15:22:07 <^7heo> maybe I should start by checking that, at least I know where to search 2017-04-17 15:22:12 i think fdisk's CHS values are just inferred/made up 2017-04-17 15:22:30 <^7heo> Shiz: but why is there a warning about the partition not ending on a cylinder then? 2017-04-17 15:22:45 <^7heo> and why is there an automatic "rounding up to the next cylinder end"? 2017-04-17 15:22:51 <^7heo> when creating a partition. 2017-04-17 15:22:53 <^7heo> that is just bs. 2017-04-17 15:22:55 legacy 2017-04-17 15:23:06 <^7heo> yeah but it creates totally arbitrary partitions 2017-04-17 15:23:16 <^7heo> with a size nowhere near the one asked. 2017-04-17 15:23:20 <^7heo> I mean really. 2017-04-17 15:23:48 <^7heo> "Blocks" are units of 1k right? 2017-04-17 15:23:48 do I understand correctly that I can #include basically anything in C? 2017-04-17 15:23:52 not just header files 2017-04-17 15:23:56 <^7heo> yeah you can 2017-04-17 15:23:57 <^7heo> but it's terrible. 2017-04-17 15:24:04 <^7heo> (to do so) 2017-04-17 15:24:12 <^7heo> nothing prevents you from doing bs. 2017-04-17 15:24:18 <^7heo> that's the whole idea of C. 2017-04-17 15:24:27 <^7heo> so people *can* know better than the toolchain. 2017-04-17 15:24:41 <^7heo> but usually they don't. 2017-04-17 15:24:45 <^7heo> really not. 2017-04-17 15:27:28 and preprocessor do just a substitution, i.e. place content of foo in place of #include "foo"? 2017-04-17 15:27:54 <^7heo> yeah. 2017-04-17 15:27:59 <^7heo> hence the ifdef-hell 2017-04-17 15:28:37 <^7heo> especially since you sometimes have stuff including stuff including stuff including... 2017-04-17 15:28:40 <^7heo> you got it. 2017-04-17 15:28:59 this is insane 2017-04-17 15:29:11 <^7heo> that is how stuff works in any case. 2017-04-17 15:29:46 well 2017-04-17 15:29:49 #pragma once 2017-04-17 15:29:51 etc 2017-04-17 15:30:13 <^7heo> jirutka: I mean, whatever you use, it's either implemented in asm or C, in the end. 2017-04-17 15:30:16 <^7heo> so... 2017-04-17 15:30:26 or go 2017-04-17 15:30:28 or rust 2017-04-17 15:30:30 :P 2017-04-17 15:31:59 <^7heo> rust compiles itself? 2017-04-17 15:32:24 yes 2017-04-17 15:34:34 <^7heo> Shiz: oh nice. 2017-04-17 15:34:37 <^7heo> Shiz: I didn't know that. 2017-04-17 15:34:45 <^7heo> Shiz: so yeah or go, or rust. 2017-04-17 15:34:48 not so nice for bootstrapping 2017-04-17 15:34:50 :P 2017-04-17 15:38:09 <^7heo> right 2017-04-17 16:00:02 <^7heo> so how does one generate an APKINDEX for use in a repo? 2017-04-17 16:00:23 <^7heo> oh, `apk index` 2017-04-17 16:00:25 <^7heo> interesting. 2017-04-17 16:04:54 :P 2017-04-17 16:05:46 and then abuild-sign to sign it 2017-04-17 16:19:46 ncopa - Are you around by chance? 2017-04-17 16:26:26 I'd like to propose a packaging change for the kernel, modules, and initfs components that would eliminate the need to run mkinitfs for kernel upgrades and make supporting various initfs features much cleaner in general. 2017-04-17 16:29:22 Simply put, use the fact that the initramfs is a set of cpio.gz archives appended together to split the various components into standard apk packages with normal dep resolution, each of which supplies a .cpio.gz. 2017-04-17 16:34:31 A kernel update then resolveds to a normal apk installation, with version numbered files being installed. mkinitfs becomes 'cat initfs-feature-*-*.cpio.gz initfs-modules-*-$krel.cpio.gz > /boot/initramfs-$krel' 2017-04-17 16:39:22 Additionally, each package would supply a manifest of arch, package, and version tagged checksummed files, and a checksum deptree file. 2017-04-17 16:44:22 I have most of the functionality on the kernel component side implemented and tested lightly (verifying output files contain whats expected, depmod run with warnings gives expected output) 2017-04-17 16:45:37 The problem is it entails a lot of useless recomputation that we could and should do once on the build host when we generate each versioned/flavored set of kernel and modules. 2017-04-17 17:56:59 Hi guys 2017-04-17 17:57:31 hi 2017-04-17 17:57:51 Is leading '/' omitted on purpose in `apk info -L without cd'ing to / first 2017-04-17 17:58:12 Which I really like to do sometimes 2017-04-17 17:59:44 yes, because it's about the package contents 2017-04-17 17:59:52 you can trivially add it back with something like 2017-04-17 17:59:59 Well 2017-04-17 18:00:10 Almost every other package manager gives me the whole path 2017-04-17 18:00:15 sed -e 's.^./.g' 2017-04-17 18:00:23 dpkg, qlist, rpm, even pkg_info 2017-04-17 18:00:38 And it's kinda handy 2017-04-17 18:01:03 but the root is not necessarily / 2017-04-17 18:01:28 apk supports different root? 2017-04-17 18:01:33 yes 2017-04-17 18:01:36 apk --root ... 2017-04-17 18:01:43 Oh 2017-04-17 18:01:44 Nice 2017-04-17 18:02:09 But it's only for installing? Or I can run queries against it too? 2017-04-17 18:02:30 all operations are supported as usual 2017-04-17 18:03:12 So `apk --root /tmp/foo/bar info -L ' can output something like /tmp/foo/bar/etc/baz.cfg? 2017-04-17 18:03:32 But I got your point 2017-04-17 18:04:06 It definitely depends on the usage pattern 2017-04-17 18:06:53 i guess it could 2017-04-17 18:06:55 yeah 2017-04-17 18:19:17 consus: I typically just wrap my command in a subshell and cd, such as 'apk info -L | (cd / && xargs grep )' for your example 2017-04-17 18:20:18 TemptorSent: I know 2017-04-17 18:20:22 TemptorSent: I can do that 2017-04-17 18:37:52 <^7heo> so guys 2017-04-17 18:38:00 <^7heo> imagine a user downloads an installation disk 2017-04-17 18:38:07 <^7heo> and wants to add 3 packages to it 2017-04-17 18:38:19 <^7heo> (or simply wants to add the missing dependencies needed for some of the packages there) 2017-04-17 18:38:27 <^7heo> how can that be made? 2017-04-17 18:40:56 <^7heo> I didn't find a single configuration file; it looks like it's all compiled in the binaries. 2017-04-17 18:41:20 <^7heo> there's the APKINDEX, but if you change that with a key that isn't an official key, the install media won't boot anymore. 2017-04-17 18:41:22 Which binaries? 2017-04-17 18:41:35 <^7heo> well, the stuff in boot 2017-04-17 18:41:43 <^7heo> initramfs and shit 2017-04-17 18:41:50 Take a look at my branch for that. 2017-04-17 18:42:03 <^7heo> your branch won't get merged anytime soon 2017-04-17 18:42:12 <^7heo> this is an important problem affecting the current distribution 2017-04-17 18:42:17 I'm trying to make modules not suck right at the moment, because running modinfo 3900*n times blows. 2017-04-17 18:42:27 <^7heo> i.e. people HAVE to download huge images if they need only 3 packages more. 2017-04-17 18:42:45 It's looking like 3.6 unless somethign goes wrong. 2017-04-17 18:42:54 Testing would very much help that. 2017-04-17 18:43:06 <^7heo> yeah but I have no time to test your stuff, I need to test MY stuff first ;) 2017-04-17 18:43:09 <^7heo> sorry D: 2017-04-17 18:43:11 <^7heo> s/D:/:D/ 2017-04-17 18:43:48 <^7heo> long story short, it sucks that there's no way to specify an ADDITIONAL line in the repo list in the install medias. 2017-04-17 18:43:51 Well, as it sits there's a drop-in replacement for mkinitfs that actually works for the most part. 2017-04-17 18:43:59 <^7heo> because yeah, it would be needed to be loaded manually; but at least it COULD work. 2017-04-17 18:44:09 <_ikke_> ^7heo: Not sure if htat's what you mean, but isn't it a matter of adding packages to something like https://git.alpinelinux.org/cgit/alpine-iso/tree/alpine-virt.packages and create a new iso? 2017-04-17 18:44:32 <^7heo> _ikke_: it's a little overkill for adding 3 packages to an existing iso, isn't it? 2017-04-17 18:44:35 *lol* alpine-iso is so depreciated it's not funny. 2017-04-17 18:44:47 <^7heo> isn't it deprecated? 2017-04-17 18:44:52 <_ikke_> ^7heo: Isn't the installation medium read-only? 2017-04-17 18:44:54 <^7heo> (as opposed to depreciated) 2017-04-17 18:44:55 I found that out hte hard way AFTER I made it work. 2017-04-17 18:45:00 <_ikke_> iso9660 2017-04-17 18:45:07 <^7heo> _ikke_: nah it's not. 2017-04-17 18:45:08 Yeah, I can't type :P 2017-04-17 18:45:23 <^7heo> _ikke_: not after your flash it to a usb drive with setup-bootable. 2017-04-17 18:45:48 Anyway, what you probably want is an overlay TBH for a quick fix. 2017-04-17 18:46:14 <^7heo> what do you mean an overlay? 2017-04-17 18:46:23 <_ikke_> ^7heo: right, which is basically just extracting the files from the iso 2017-04-17 18:46:33 <^7heo> _ikke_: yes, and making it read/write 2017-04-17 18:46:36 A tarball that gets extracted by the initfs init at boot. 2017-04-17 18:46:48 <^7heo> TemptorSent: does that happen automatically? 2017-04-17 18:46:53 Yep. 2017-04-17 18:46:59 <^7heo> TemptorSent: is that documented anywhere? 2017-04-17 18:47:08 apkovl.tar.gz IIRC 2017-04-17 18:47:13 <^7heo> ah that 2017-04-17 18:47:49 It will load it ONLY if its the only overlay file in the root apparently? I'm confused on what the intent was there. 2017-04-17 18:47:50 <^7heo> so the real way to add packages to the repo isn't to add them to the repo; but rather to make a secondary "virtual repo" in a tarball 2017-04-17 18:48:06 <^7heo> the intent was to allow alpine to boot in RAM 2017-04-17 18:48:09 <^7heo> every time 2017-04-17 18:48:21 <^7heo> while saving the packages and content of /etc in a file. 2017-04-17 18:48:23 ^7heo: At least without remastering an image, that's probably the best bet. 2017-04-17 18:48:28 <^7heo> you're right. 2017-04-17 18:48:39 <^7heo> and remastering an image is completely overkill for my use case. 2017-04-17 18:48:42 <^7heo> so I'll opt for that. 2017-04-17 18:48:45 <^7heo> Thanks a bunch TemptorSent ;) 2017-04-17 18:48:45 <_ikke_> alpine is still used a lot in a run-from-ram way 2017-04-17 18:48:50 No worries. 2017-04-17 18:48:59 <^7heo> _ikke_: yeah I guess. 2017-04-17 18:49:05 <^7heo> _ikke_: one of my machines does it that way 2017-04-17 18:49:11 <^7heo> _ikke_: it's a little cumbersome tho. 2017-04-17 18:49:13 Remastering an image is getting close to just give it a profile and it gives you your image. 2017-04-17 18:49:27 <^7heo> TemptorSent: the problem with that is the keys. 2017-04-17 18:49:36 <^7heo> TemptorSent: if there was a directory with the keys 2017-04-17 18:49:46 <^7heo> TemptorSent: I'd have dropped my key in there 2017-04-17 18:49:49 Not a problem, it includes the keys of your choice too. 2017-04-17 18:49:52 <_ikke_> /etc/apk/keys? 2017-04-17 18:49:54 <^7heo> TemptorSent: and all good 2017-04-17 18:50:01 <^7heo> _ikke_: not existing in the iso. 2017-04-17 18:50:10 <_ikke_> it's part of the overlay 2017-04-17 18:50:13 <^7heo> _ikke_: the iso only has apks and boot 2017-04-17 18:50:15 <^7heo> I guessed. 2017-04-17 18:50:21 <^7heo> but to change that you need to remaster an image. 2017-04-17 18:50:24 <^7heo> obviously. 2017-04-17 18:50:36 <^7heo> which is the whole thing I'm trying to avoid - because I'm writing a guide. 2017-04-17 18:50:43 <^7heo> Guide to install alpine linux: do it yourself. 2017-04-17 18:50:45 <^7heo> yay. 2017-04-17 18:50:47 Gotcha. 2017-04-17 18:51:03 <^7heo> so the simplest the method, the better. 2017-04-17 18:51:12 <^7heo> the apkovl thing is simple enough; I'll use that. 2017-04-17 18:51:29 <^7heo> anything else that could be done very simply (adding a public key, etc) isn't actually implemented 2017-04-17 18:51:35 You might at least want to take a look at the kerneltool I added then, it will make a modloop/cpio.gz file given a list of modules. 2017-04-17 18:51:37 <^7heo> and therefore isn't doable without being officially implemented. 2017-04-17 18:51:54 It'll be implemented in a week or so ;) 2017-04-17 18:51:57 <^7heo> TemptorSent: that's cool, but I need my guide to work with 3.5 2017-04-17 18:52:05 <^7heo> TemptorSent: I'll update it for 3.6 2017-04-17 18:52:48 Right, just letting you know there are tools out there now that take a lot of pain out. 2017-04-17 18:53:09 <^7heo> I guess 2017-04-17 18:53:15 <^7heo> I'll check them out when I'm done 2017-04-17 18:53:24 <^7heo> that apkovl thing that I totally forgot is my ticket out for today. 2017-04-17 18:53:28 <^7heo> later, diff story 2017-04-17 18:53:32 Not perfect yet, but generally useful regardless of the rest of the system if you need to make custom modloops and such. 2017-04-17 18:54:34 <^7heo> yeah 2017-04-17 18:54:35 <^7heo> well 2017-04-17 18:54:40 <^7heo> I'll tell you in a week or so 2017-04-17 18:54:41 Yeah, the other is that you can append cpio.gz archives directly to the existing initfs if you need to add modules or userspace in there. 2017-04-17 18:54:42 <^7heo> bbl 2017-04-17 18:55:09 Between that and the overlay, you can do pretty much anything you need. 2017-04-17 18:56:29 (such as extracting /lib/modules from zfs-$flavor and the userspace from zfs and adding them a cpio.gz) 2017-04-17 18:59:00 ^7heo: Unclustering the whole initfs mess should eliminate a whole slew of pain points. 2017-04-17 20:18:04 xsteadfastx, this snapcast works nicely with librespot :) 2017-04-17 20:19:14 Never heard about librespot 2017-04-17 20:20:19 Ah, Spotify :) 2017-04-17 20:21:02 running it on my nas and output to rpi3 and my android device 2017-04-17 20:30:45 It appears that the deps for thw Twisted package are missing. 2017-04-17 20:31:44 Could it be cos it's trying to parse setup.py and not detecting it as twisted does it in a (valid python but) non-standard way? 2017-04-17 20:31:44 https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_setup.py#L233-L235 2017-04-17 20:33:06 Nope, looks like it just doesn't have half the depends it should 2017-04-17 20:36:35 ashb, maintainer should take care of the deps 2017-04-17 20:37:18 and looks like they are also pyver depended 2017-04-17 20:37:32 pyver? 2017-04-17 20:37:41 oh 2 vs 3? 2017-04-17 20:37:45 https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_setup.py#L227 2017-04-17 20:38:20 please submit a pr if you can. 2017-04-17 20:38:50 Step 1: fix the deps on twisted's dep - py-crypto is also missing things 2017-04-17 20:39:49 https://github.com/pyca/cryptography/blob/master/setup.py#L36-L42 vs https://git.alpinelinux.org/cgit/aports/tree/main/py-crypto/APKBUILD#n11 2017-04-17 20:41:03 How do we want to handle dual-life modules. i.e. one's that use six to support py2 and py3 2017-04-17 20:43:45 ? 2017-04-17 20:45:53 should there be a py2-twisted and a py3-twisted? 2017-04-17 20:47:22 yes 2017-04-17 20:50:48 And I guess that's what the _py2 and _py3 functions in APK build do? What invokes those? 2017-04-17 20:53:20 ashb, the pyver depended deps are a mess. 2017-04-17 20:53:55 it means we need to support both in aports which we kind of not want. 2017-04-17 20:55:58 Is there some auto dep parsing going on? Or is it cos the same APKBUILD file (with the same deps) is used to make py2-$x and py3-$x? 2017-04-18 00:17:09 ncopa, any reason why we are using chronyd as default ntpd intead of the supplied bb ntpd? 2017-04-18 02:20:21 Query - is there any good reason to not default to using the host apk keys and repositories unless otherwise specified? 2017-04-18 02:46:17 Building zfs modules cpio.gz is down to the following: 'kerneltool --repositories-file /etc/apk/repositories --keys-dir /etc/apk/keys stage latest zfs spl ; kerneltool --repositories-file /etc/apk/repositories --keys-dir /etc/apk/keys mkmodcpiogz modsubset=zfs zfs' 2017-04-18 02:47:32 Assuming we're safe to default the repo file and keys dir, it becomes: 'kerneltool stage latest zfs spl ; kerneltool mkmodcpiogz modsubset=zfs zfs' 2017-04-18 02:53:25 A custom modloop is 'kerneltool stage latest zfs spl xtables-addons ... && kerneltool mkmodloop zfs kernel/drivers/scsi/ */*3c* ...' 2017-04-18 02:57:49 Existing initfs globs are supported, but it would probably be wise to add a source tag directly to the glob, allowing simple usage such as 'kmod:zfs:extra/' to indicate type, source package, and glob. 2017-04-18 02:58:29 s/kmod/kpkg/ 2017-04-18 05:51:52 Hello fabled - are you around? 2017-04-18 07:24:54 clandmeter: i created a PR for snapcast. the pre script doesnt create a user home directory 2017-04-18 07:31:34 xsteadfastx, against my latest changes? 2017-04-18 07:32:58 shouldnt it be created? i thought i forgot to add it 2017-04-18 07:33:10 sorry then 2017-04-18 07:34:29 it probably should 2017-04-18 07:35:01 i checked the pre script in a fresh aports fetch 2017-04-18 08:12:36 so i wanted to recreate my mopidy docker image... and it tells me something about missing gobject... wasnt there soemthing about it? 2017-04-18 08:16:53 i get this "ImportError: Error relocating /usr/lib/libglib-2.0.so.0: pthread_setname_np: symbol not found" 2017-04-18 08:19:13 i tried it last week and mopidy was working 2017-04-18 08:26:56 if i do a "apk add" and it tells me "2 errors"... "-v" doesnt give me better output? is there a debug mode? 2017-04-18 08:30:16 there must have been some changes if it worked last week 2017-04-18 08:30:39 again some strange gstreamer python bindings problems with gobject and stuff... argh 2017-04-18 08:33:38 all i do is "import gi" in the python shell 2017-04-18 09:01:30 apk fix 2017-04-18 09:03:29 ok thanks 2017-04-18 09:03:40 i wonder whats happening with py-gst1 2017-04-18 09:05:17 i think i have it working locally 2017-04-18 09:05:21 or had 2017-04-18 09:05:30 <^7heo> Guys 2017-04-18 09:05:31 but do check, could be my tests are incorrect 2017-04-18 09:05:48 <^7heo> how come I can sign an APKINDEX while I didn't generate a key on the machine I'm using for that? 2017-04-18 09:06:56 i started a fresh alpine:edge container and installed py-gst1...cant import gi. at least for python2 2017-04-18 09:07:05 <^7heo> Is apk using a "dummy key" for this kind of operation? 2017-04-18 09:07:13 thats what mopidy needs 2017-04-18 09:07:46 i think im gonna push libressl 2.5 2017-04-18 09:09:13 2.5.3 ? 2017-04-18 09:09:18 yes 2017-04-18 09:10:16 xsteadfastx. what does your apk info |grep py say? 2017-04-18 09:12:50 libressl 2.5 means rebuild of 142 packages in main 2017-04-18 09:13:07 60 packages in community 2017-04-18 09:13:24 49 packages in testing 2017-04-18 09:17:49 clandmeter: py-gobject3 2017-04-18 09:17:51 py-gst1 2017-04-18 09:17:53 python2 2017-04-18 09:17:55 py2-cairo 2017-04-18 09:17:57 py2-gobject3 2017-04-18 09:17:59 py2-gst1 2017-04-18 09:18:01 but 2017-04-18 09:18:04 apk fix tries to install glib and fails with the same error 2017-04-18 09:18:19 what is the error? 2017-04-18 09:18:21 Error relocating /usr/lib/libglib-2.0.so.0: pthread_setname_np: symbol not found 2017-04-18 09:18:35 apk fails with that error? 2017-04-18 09:19:07 are you mixing repositories? 2017-04-18 09:19:11 apk fix does 2017-04-18 09:19:21 i have testing enabled 2017-04-18 09:19:28 else i couldnt install py-gst1 2017-04-18 09:19:36 make it all testing 2017-04-18 09:19:39 dont mix repos 2017-04-18 09:19:45 err all edge 2017-04-18 09:21:18 i guess its some apk post install/upgrade script that errors 2017-04-18 09:21:57 even its all edge? 2017-04-18 09:22:10 i mean its all edge... 2017-04-18 09:22:16 and still get the error 2017-04-18 09:37:20 xsteadfastx, did you try: apk -U upgrade --available 2017-04-18 09:40:15 wuat? why did that worked? 2017-04-18 09:40:23 ;-) 2017-04-18 09:40:39 rtfm 2017-04-18 09:40:40 :p 2017-04-18 09:42:29 mh ok... upgrade installed packages 2017-04-18 09:42:46 maybe my alpine edge image is too old 2017-04-18 09:50:04 xsteadfastx, was that image always edge? 2017-04-18 09:50:33 yes it was. but pretty old pull. i did a fresh docker pull alpine:edge and it worked... without the apk upgrade 2017-04-18 09:51:21 but i will add the apk -U upgrade --available to my dockerfile 2017-04-18 11:46:27 if i install ca-certificates (the package) and do a update-ca-certificates it tells me no certificate is installed. is this command only for self installed cas? 2017-04-18 11:46:37 i need this to get the mopidy youtube plugin working 2017-04-18 11:59:16 ca-certificates should work as is 2017-04-18 11:59:36 ah ok i found it it 2017-04-18 11:59:48 py-requests needs to set a enviornment variable where to find the certs 2017-04-18 12:00:02 REQUESTS_CA_BUNDLE 2017-04-18 12:00:07 yes thats possible 2017-04-18 12:00:13 to /etc/ssl/certs 2017-04-18 12:00:40 it currently doesnt do that? 2017-04-18 12:00:46 i mean it doesnt work without? 2017-04-18 12:02:29 shoudlnt it point to the bundle itself? 2017-04-18 12:02:36 /etc/ssl/certs/ca-certificates.crt 2017-04-18 12:59:23 i dont know... /etc/ssl/certs works 2017-04-18 12:59:59 i will check 2017-04-18 13:21:51 ncopa: hi 2017-04-18 13:23:44 ncopa: to compile go package in ppc64le, we need to use a new version of go-bootstrap package (as version 1.4 does not have support for ppc64le). I created a new version of go-bootstrap (cross-compiling it) and this version is able to compile the go package in ppc64le. It is hosted at: ftp://ftp.unicamp.br/pub/ppc64el/alpine/go-bootstrap/ 2017-04-18 13:24:28 ncopa: any idea how we can use this go-bootstrap in alpine build to compile go package for ppc64le? 2017-04-18 13:30:00 rdutra i think we will have to add it manually to the builder 2017-04-18 13:33:59 isnt go already part of our boostrap tools? 2017-04-18 13:34:05 rdutra: i manually installed the go-bootstrap on build-edge-ppc64le 2017-04-18 13:34:06 thought fabled worked on that 2017-04-18 13:35:09 yes, go should be bootstrap compileable via bootstrap.sh 2017-04-18 13:35:29 clandmeter: the last go-bootstrap package is the version 1.4 (that is the version that do not have go code - just C), and this version has no support for ppc64le 2017-04-18 13:35:57 go-boostrap is the last go version that can be compiled with C-compiler 2017-04-18 13:36:03 it can target only limited number architectures 2017-04-18 13:36:11 ncopa: you mean you installed it now or it was already installed? 2017-04-18 13:36:33 i manually installed it 2017-04-18 13:36:44 newer go depends on go. and to bootstrap arch that is supported by newer go only, we need to crosscompile it using bootstrap.sh 2017-04-18 13:37:19 fabled: rdutra already crosscompiled a go package 2017-04-18 13:37:29 ncopa: ok, so can I send a patch to enable go in ppc64le? the go-bootstrap package will still be disabled as no support for 1.4 version 2017-04-18 13:37:48 yes 2017-04-18 13:38:03 ncopa: cool, let me do it here 2017-04-18 13:39:48 ncopa, what was the reason again for install files not to be included in checksums? 2017-04-18 13:47:05 ncopa: https://github.com/alpinelinux/aports/pull/1269 2017-04-18 13:49:26 clandmeter because git has the checksum 2017-04-18 13:49:38 but yeah, we could include them for consistency 2017-04-18 13:50:06 right, same case as initd/confd files 2017-04-18 14:04:24 ncopa, how do we force luajit to be recompiled? 2017-04-18 14:04:33 it seems that the current version is the one that segfaults. 2017-04-18 14:12:47 bump pkgrel 2017-04-18 14:34:37 yes, bump pkgrel 2017-04-18 14:41:18 ok 2017-04-18 15:45:20 ncopa: leitao: https://github.com/alpinelinux/aports/pull/1270 2017-04-18 15:49:27 rdutra, why bump luajit? 2017-04-18 15:50:17 clandmeter: there was a fix for ppc64le (segfault problem) and needed to recompile the package 2017-04-18 15:50:56 and the fix didnt go into luajit? 2017-04-18 15:51:42 anyway, i need to run home. nice evening. 2017-04-18 15:51:44 clandmeter: yes the fix was in luajit, but I did not bump the pkgrel to force it recompile 2017-04-18 15:52:14 ah i see now. 2017-04-18 15:52:59 well, normally you dont need to bump it if it didnt build. builder should try it again (when next in line) 2017-04-18 15:53:41 clandmeter: the package was building in ppc64le but the generated binary was getting a segfault 2017-04-18 15:54:02 clandmeter: guess that's why I needed to bump it 2017-04-18 15:56:09 clandmeter, we fixed luajit but didn't upgrade the pkgrel. So, we were not seeing the fixed package being used. 2017-04-18 15:59:16 ncopa, fabled: What is the feasiblity of making some changes to the kernel packaging before 3.6? 2017-04-18 16:02:27 Specifically, building the kernel and all associated external modules to be packaged for each krel, then building a master manifest with checksums, and a deptree of checksums. 2017-04-18 16:13:43 TemptorSent i will not have time for that before 3.6 release 2017-04-18 16:15:25 ncopa: I already have the code to do the generation done, it just takes a long time to properly traverse the dep tree and get all the required files (the existing depmod misses several for some reason) 2017-04-18 16:16:09 will this depend on the mkimage work you did? 2017-04-18 16:16:16 ncopa: If it can't make 3.6, it's not a big deal. 2017-04-18 16:16:34 i'd rather get your mkimage work in 2017-04-18 16:16:39 It uses some files in common, but I've just about finished splitting the functions off. 2017-04-18 16:16:56 lets focus on getting the mkimage in instead 2017-04-18 16:16:59 It's necessary to have mkimage work properly. 2017-04-18 16:17:29 you mean mkimage depends on the kernel refactoring? 2017-04-18 16:17:47 It's done and working as far as creating the modloop and initfs modules. 2017-04-18 16:18:33 mkimage needs the fixes I'm introducing, but the packaging is a user convenience issue. 2017-04-18 16:19:28 Right now, you can make a modloop or initfs modules cpio with two commands :) 2017-04-18 16:19:54 im not following. can we merge/add mkimage, mkinitfs, update-kernel without you refacotr linux kernel APKBUILDs? 2017-04-18 16:20:01 Yes. 2017-04-18 16:20:09 lets do that then 2017-04-18 16:20:13 how do i do it? 2017-04-18 16:20:29 did you export it to a separate git repo? 2017-04-18 16:20:33 jirutka offered to do the splitting, and I think we're just about there. 2017-04-18 16:20:37 ok 2017-04-18 16:20:58 lets do that first then 2017-04-18 16:21:01 git log on the directory I believe is the accepted approach? 2017-04-18 16:21:13 okay 2017-04-18 16:21:54 Please take a look and let me know what we want to do for command line options and such -- I've just carried through more or less what existed, which may not be ideal in some cases. 2017-04-18 16:22:34 if the tools have the same names as the old ones 2017-04-18 16:22:45 then they needs to be backwards compatible 2017-04-18 16:23:06 if they have new names, then they dont need to be backwards compatible 2017-04-18 16:25:44 Yeah, the backwards compatible part is working, but overly verbose in places (--repositories-file for instance) 2017-04-18 16:27:16 The interesting new stuff is mostly 'kerneltool', which stages, subsets, and squashes/cpios/tars modules and handles the rest of the kernel artifacts. 2017-04-18 16:28:15 I have NOT tested custom builds as of yet, but the supporting framework is there and should work with little problem once any obvious bugs get knocked out. 2017-04-18 16:29:56 What probably does not work currently is the reverse-lookup for currently configured arch for the kernel. To fix that, we probably need to parse more of .config to figure out the bits and endiness. 2017-04-18 16:31:23 I'm just about ready to finish off the last of the transition for mkinitfs to use the new staging code. 2017-04-18 16:32:44 But realisitically, we don't need the initfs created by mkinitfs to be rebuilt every time the kernel is updated, we just need to update the modules. 2017-04-18 16:42:01 ncopa: The other issue I'd like to work out is nailing down a generally-useful manifest format. 2017-04-18 16:43:43 Which probably needs to include filetype/size/owner/perms in addition to the checksum, source package, and path. 2017-04-18 16:44:51 the contents of /lib/apk/db/installed doesn't seem to be usable in the general case unfortunately. 2017-04-18 16:57:11 Question: Where does the apk 'dot' output come from? 2017-04-18 16:57:45 <_ikke_> TemptorSent: https://git.alpinelinux.org/cgit/apk-tools/tree/src/dot.c ? 2017-04-18 16:59:41 _ikke_: I should have been more specific -- is it directly generated from the APKINDEX files and spit out by apk, or is there additional magick involved :) 2017-04-18 17:00:35 <_ikke_> TemptorSent: From reading the code, it reads packages from the apk database 2017-04-18 17:03:07 _ikke_: It's picking up the entire package list, not just installed, so I'm guessing it's parsing all APKINDEX..gz files. 2017-04-18 17:03:55 <_ikke_> right, was verifying what file it was actually reading 2017-04-18 17:04:19 <_ikke_> TemptorSent: there is also /lib/apk/db/* 2017-04-18 17:04:39 <_ikke_> But it makes sense it uses the repository index for this 2017-04-18 17:04:55 _ikke_: Yeah, /lib/apk/db doesn't cut it unfortunately. 2017-04-18 17:05:37 <_ikke_> openat(4, "APKINDEX.3f8e9ca0.tar.gz", O_RDONLY|O_CLOEXEC) = 6 2017-04-18 17:06:02 _ikke_: What I'm trying to do is get a list of packages required for a given FILE, which gets entertaining :) 2017-04-18 17:06:37 <_ikke_> meaning, pkg x provides file f, pkg x requires pkg, y, etc? 2017-04-18 17:08:10 Basically... Given a file, say /usr/sbin/zfs, I need to generate the list of packages required to meed the lib deps, but don't care about the 'normal' deps. 2017-04-18 17:09:10 lddtree resolved to packages. 2017-04-18 17:11:41 _ikke_: Any idea where the APKINDEX format is documented? It looks like it will be easier to parse that directly for so libs. 2017-04-18 17:11:57 <_ikke_> TemptorSent: sorry, I don't 2017-04-18 17:12:58 No problem, I'm going to take a stab in the dark that D: is deps and p: is provides 2017-04-18 17:13:28 <_ikke_> TemptorSent: I think the source is the best documentation there is (but I can be mistaken) 2017-04-18 17:14:12 Yeah, unfortunately the source is a bit hard to follow at times due to the way everything passes through the database. 2017-04-18 17:14:25 Time to go poking around. 2017-04-18 17:22:00 jirutka: hi. Is lua-rapidjson building fine on your env? 2017-04-18 17:22:42 <^7heo> kaniini, jirutka, clandmeter: https://github.com/alpinelinux/aports/pull/1271 2017-04-18 17:22:47 <^7heo> I tested it locally. 2017-04-18 17:22:52 <^7heo> Sixel support is AWESOME. 2017-04-18 17:24:36 Wow, it's hidden pretty well, I can find f: s: q: r: Z: R: M: a: and F:, but not p: or D: 2017-04-18 17:27:00 Ahh, nothing to do with database, index, or anything else.. it's in apk_pkg_add_info of course? 2017-04-18 17:34:14 _ikke_: Found the "documentation" starting at line 833 of package.c FWIW :) 2017-04-18 17:36:36 fabled: A little help please? Is there any documentation for the various atom formats used in the APKINDEX fields available? 2017-04-18 17:37:37 And what is the difference between origin and provides in that case? 2017-04-18 18:06:14 origin is what source package or apkbuild it came from 2017-04-18 18:30:54 kaniini: Okay, thanks. What atom formats are accepted where? 2017-04-18 18:32:09 kaniini: For instance, can origin contain versions? 2017-04-18 18:32:55 no 2017-04-18 18:33:17 it is just the name of the source package/apkbuild/whatever 2017-04-18 18:33:39 Okay, it looks like that won't work either then :/ 2017-04-18 18:34:06 Kernel versioning is really quite fubar. 2017-04-18 18:35:48 kaniini: Any thoughts as to how to ensure kernel packages don't get mismatches without actually scanning them all (which is what I'm doing currently)? 2017-04-18 18:36:43 <^7heo> kaniini: if you have some time: https://github.com/alpinelinux/aports/pull/1271 2017-04-18 18:37:17 As it stands, it's rather difficult to ensure a full set of matching kernel/modules/headers/dtbs is fetched atomically. 2017-04-18 18:42:18 And something seems broken, because the dot output is showing zfs-vanilla-4.4.59-r0 -> spl-vanilla-4.4.59-r0 AND -> spl-vanilla-4.9.21-r0... 2017-04-18 18:44:42 ...and each of the kernel packages have - as the origin, not , which pretty much shoots my hopes of detecting which packages should be pulled rather than guessing. 2017-04-18 18:46:57 kaniini: Would you mind doing 'apk dot | grep zfs' and telling me if you're seeing very strange results or if I just somehow fubared my apk database? 2017-04-18 19:01:11 <^7heo> kaniini: many thanks 2017-04-18 19:24:28 SCis there any progress on moving/mirroring/whatever this channel to OFTC or some other net? 2017-04-18 19:26:27 <_ikke_> Any reason to? 2017-04-18 19:34:19 awilfox: ironically freenode has been better behaved since PIA has taken over 2017-04-18 19:34:32 awilfox: they quit letting staff just k-line people for the fuck of it 2017-04-18 19:36:51 It also seems more stable than I remember it being a few years ago -- my local net is usually the cause of drops now rather than the irc server. Net splits seem down as well. 2017-04-18 19:37:39 kaniini: that doesn't make me feel any better about a private company controlling freenode. for the same reason I don't enjoy a private company controlling github. 2017-04-18 19:38:22 The real fix is to decentralize again, but that requires irc server software that doesn't suck to actually happen. 2017-04-18 19:38:29 awilfox: the eventual goal is to mirror the IRC channel to other platforms, but we probably wont leave freenode 2017-04-18 19:40:03 How are things looking on EF these days? 2017-04-18 19:42:35 i mean, it's looking like a good place to get ddosed because some kid wants your nickname 2017-04-18 19:42:53 IRC is trash :) 2017-04-18 19:42:56 Yeah, I guess that hasn't changed :P 2017-04-18 19:43:39 <_ikke_> Like slack is any better :P 2017-04-18 19:44:12 IM is a dumpster fire all around 2017-04-18 19:45:08 <_ikke_> at least irc is not commercialized yet 2017-04-18 19:46:42 _ikke_: True, probably in part because it's so broken in so many ways :) 2017-04-18 19:47:37 <_ikke_> Whatever it takes :D 2017-04-18 19:50:08 _ikke_: If people get together on a modern irc RFC, we might have both less broken IRC, and be able to distribute services away from any major holdings. 2017-04-18 19:52:31 <_ikke_> What is preventing that from happening? 2017-04-18 19:52:54 _ikke_: Critical mass of people getting together to do it :) 2017-04-18 19:53:06 https://github.com/ircv3/ircv3-specifications 2017-04-18 19:53:14 LOLS 2017-04-18 19:53:16 :) 2017-04-18 19:53:19 ircv3 is trasssssssssh 2017-04-18 19:53:32 <_ikke_> kaniini: I suspected you would say that 2017-04-18 19:53:37 Yeah, it's a mess. 2017-04-18 19:53:43 Wrong approach. 2017-04-18 19:54:07 they spent 3 years bikeshedding about how to migrate all users to TLS 2017-04-18 19:54:33 kaniini: And made everything MORE complex, not less. 2017-04-18 19:54:48 capability negotiation is good 2017-04-18 19:54:54 Gravitars? Really? 2017-04-18 19:55:08 the way they implement a lot of 'presence' type things is very odd 2017-04-18 19:55:20 they did not really like my ideas on the matter 2017-04-18 19:55:22 sooo lol 2017-04-18 19:55:46 I want dead simple, the rest can sit on top of a solid foundation. 2017-04-18 19:56:31 i guess they wouldn't be surprised to know that i think they have spent the past 3 years doing basically fuck all, like failing to solve things like push notifications to my phone 2017-04-18 19:56:37 e.g. things that would be useful to solve 2017-04-18 19:56:40 but hey i hear they have a bunch of specs on how to move everyone to TLS :) 2017-04-18 19:57:25 TemptorSent: the worst part of ircv3 group is they have a public submission process that allows any idiot to submit specifications that are just completely whack 2017-04-18 19:57:45 TemptorSent: and then they do not do anything to actually scrutinize these submissions 2017-04-18 19:57:59 How about we just forget about the transport layer for a moment (since that should be pluggable!), and start looking at how to do federation on unreliable or partitioned networks RIGHT? 2017-04-18 19:58:32 well, they want to move IRC users onto mandatory TLS because apparently there is a thing called the NSA 2017-04-18 19:58:40 but their spec to do it can be interdicted by the NSA anyway, so... 2017-04-18 19:58:55 A lot of their bullet points look good, but those are client features, not server or protocol issues beyond the basic level. 2017-04-18 19:59:18 TLS doesn't save you from anything. 2017-04-18 19:59:38 i think the ircv3 people lost their way at some point in the ircv3.2 process 2017-04-18 19:59:39 And I don't WANT authentication on IRC. 2017-04-18 19:59:53 the SASL binding for IRC was good (oh wait that was my doing) 2017-04-18 20:00:11 SASL actually makes senese. 2017-04-18 20:00:32 <_ikke_> heh 2017-04-18 20:00:37 the way message tags was done is hilariously bad 2017-04-18 20:00:46 512/512 split 2017-04-18 20:00:51 because that's how parsers work, right? 2017-04-18 20:00:54 Authentication when you want it, not when you don't. 2017-04-18 20:01:04 Apparently. 2017-04-18 20:01:13 the good news is basically no actual implementation follows the 512/512 split rule, because largely it's stupid 2017-04-18 20:01:43 Why do message tags need anythign special at all other than maybe a non-printing character to demarc? 2017-04-18 20:02:01 well 2017-04-18 20:02:10 the 512/512 split was for legacy compatibility ostensibly 2017-04-18 20:02:34 so you could hardcode a buffer size of 512 for the tags and a separate buffer for the message itself 2017-04-18 20:02:42 nevermind that is a terrible way to code an irc parser 2017-04-18 20:02:56 Yeah, give me CTCP over that mess. 2017-04-18 20:03:11 well, CTCP is awful too 2017-04-18 20:03:11 but 2017-04-18 20:03:21 it is better than an ambiguous spec that is hard to follow 2017-04-18 20:03:48 and in general, there's nothing wrong with message-tags 2017-04-18 20:03:54 What was the point of all the autonegotiation if it can't negotiate a buffer (subpacket?) size? 2017-04-18 20:03:56 except there's 3 different specs for client-to-client tags 2017-04-18 20:04:05 right 2017-04-18 20:04:06 that is what i am saying 2017-04-18 20:04:08 if you speak tags 2017-04-18 20:04:14 then clearly you can handle a buffer size of 1024 2017-04-18 20:04:23 so if you can handle a buffer size of 1024 2017-04-18 20:04:28 TemptorSent: so should I split it now? 2017-04-18 20:04:33 then you should be able to support any kind of payload that is 1024 2017-04-18 20:05:01 but then they were like "oh but people using old clients" 2017-04-18 20:05:04 TemptorSent: also let me know if you want to somehow change the structure; probably move all from /scripts to /…? 2017-04-18 20:05:12 jirutka: If you can take a look and review it somewhat first, I'd appreciate catching anythign ulgy before we get there.. 2017-04-18 20:05:15 and at that point i nearly had a stroke and my doctor advised me to stop talking to those people 2017-04-18 20:05:18 ;) 2017-04-18 20:06:02 jirutka: Basically, scripts/mkimage becomes a new root for repo mkalpine 2017-04-18 20:06:03 leitao: yes, lua-rapidjson is building fine on my env and IIRC even on all builders except ppc64le (I don’t know about s390 or how is that called) 2017-04-18 20:06:36 kaniini: Yeah, I'm kinda amazed by how little reality makes it through to people. 2017-04-18 20:06:46 TemptorSent: don’t have time for the review now :( 2017-04-18 20:07:18 TemptorSent: handling old clients is simple: don't 2017-04-18 20:07:24 jirutka: Okay, let's hold a day or two then so I can hopefully get at least one more set of eyeballs on it. 2017-04-18 20:07:26 jirutka, hmm, this is a noarch package. I wasn't expecting any issue 2017-04-18 20:07:43 kaniini: Let old clients connect using old protocol and strip off anythign new before sending it to them. 2017-04-18 20:07:46 TemptorSent: if that is not a good answer for whatever reason, split the message 2017-04-18 20:08:31 you can't connect an IRC client from the 1980s to a modern IRC server anyway 2017-04-18 20:08:47 leitao: me neither, but it’s a problem with LuaJIT on ppc64le; your colleague has already debuged it and said that there’s some problem with PIE, so we’ve disabled PIE for main/luajit for ppc64le for now 2017-04-18 20:08:47 kaniini: After the 3.6 drop, we should get a group together to talk about this in depth... 2017-04-18 20:09:06 leitao: https://github.com/alpinelinux/aports/pull/1266 2017-04-18 20:09:23 TemptorSent: as for federation, that largely has to do with the fact that IRC is a monoculture. FOSS should dump IRC for matrix or something else that is modern 2017-04-18 20:09:45 leitao: aha, but he forgot to bump pkgrel… 2017-04-18 20:10:05 jirutka, right. 2017-04-18 20:10:11 it seems luajit is enabled back 2017-04-18 20:10:12 kaniini: Or at least adopt some of the concepts into an IRC type platform. 2017-04-18 20:11:23 kaniini: well, still better ancient IRC that is at least open, standardized and federated protocol, then these hipster shits like Slack and similar; maybe Telegram is one of few at least quite interesting, IIRC they have thoroughly documented protocol 2017-04-18 20:11:26 kaniini: Do you have a few minutes to eyeball the current state of my branch before jirutka splits the repo? I'm finishing up some refactoring, but I want to catch anything ugly that I missed before he does. 2017-04-18 20:12:38 jirutka: Exactly. We need a more modern open, standardized, federated protocol that still allows for anon access and ad-hoc linking. 2017-04-18 20:13:35 so... matrix in other words? 2017-04-18 20:13:36 :p 2017-04-18 20:14:08 TemptorSent: I’d insist on anon access (i.e. without any registration of any kind), I actually don’t consider this as a good thing, but definitely open and federated (!) 2017-04-18 20:14:24 kaniini: yes, probably, I haven’t tried Matrix yet :( 2017-04-18 20:14:39 TemptorSent: s/I’d/I’d not/ 2017-04-18 20:14:55 matrix isn't perfect by any means 2017-04-18 20:15:05 but what's cool is, we can use matrix to federate the alpine chats to gitter 2017-04-18 20:15:12 and other platforms like that 2017-04-18 20:15:14 why gitter?! 2017-04-18 20:15:23 because thats where people are now 2017-04-18 20:15:28 wtf 2017-04-18 20:15:34 alpine needs to be where people are, that is how you get new contributors 2017-04-18 20:15:50 that’s why we’re on GitHub 2017-04-18 20:15:57 exactly 2017-04-18 20:16:14 where do you think github users go to talk about their stuff? 2017-04-18 20:16:15 jirutka: The reason for anon access is at least two-fold -- 1) Privacy/security concerns. 2) Deniability. 2017-04-18 20:16:16 hint: not freenode 2017-04-18 20:17:16 kaniini: depends, hipster freaks go to Slack, then have dozens of accounts on Slack and complain about missing history etc. 2017-04-18 20:17:30 kaniini: and doing workaround to allow auto-join new ppl 2017-04-18 20:17:41 kaniini: serious projects use IRC 2017-04-18 20:18:13 awilfox: *lol* Looks like a lot of us on the same pakge. 2017-04-18 20:18:28 not from what i see. some projects offer both, but a few serious projects have been moving to gitter. 2017-04-18 20:18:30 s /pakge/page/ 2017-04-18 20:18:55 I’ve logged like two times on Gitter, then after a year found out, totally by accident, that some ppl tried to contact me via Gitter… 2017-04-18 20:19:46 The whole offline messaging issue is a real mess, and I haven't seen any implementations that don't suck. 2017-04-18 20:19:49 either way, your opinion on those services aside, we use github for the same reason we would want to federate our chat resources 2017-04-18 20:19:57 we can also just run our own IRC or any other server 2017-04-18 20:20:03 yes 2017-04-18 20:20:33 Ideally, every project would run host their own irc server and federate access. 2017-04-18 20:20:48 the nice thing about matrix is, largely it is plumbing for federation so you can run your own IRC server and connect the channels there onto other platforms (freenode, gitter, telegram, etc.) 2017-04-18 20:21:25 through matrix, it is possible to have events on #alpine-devel pushed to my phone (like when i am highlighted) 2017-04-18 20:21:28 I don’t like IRC very much, it’s ancient and a many natural features must be workarounded (like using ZNC)… but I still don’t see any good alternative, maybe except Matrix (as I said, haven’t tried it yet) 2017-04-18 20:21:31 without murdering battery 2017-04-18 20:21:40 kaniini: I'm talking mostly federation across networks of the same service primarily, with federation to other services being a secondary concern. 2017-04-18 20:21:53 TemptorSent: matrix can do that too 2017-04-18 20:22:04 TemptorSent: matrix can bridge anything to anything 2017-04-18 20:22:06 yes, that integration of many services is the most interesting feature of Matrix for me 2017-04-18 20:22:47 basically my concept is 2017-04-18 20:22:50 Yeah, I'm looking at matrix -- it looks like it's great for plumbing, but I'm not seeing it as a community server quite as much. 2017-04-18 20:22:56 if you want to interact with alpine via freenode, you continue to do so 2017-04-18 20:23:12 if you want to interact with alpine via oftc, then through matrix that could be possible 2017-04-18 20:23:31 if you want to interact with alpine via gitter or telegram, that can be possible 2017-04-18 20:23:57 now I use Slack via IRC, b/c some ppl in work wanted to use Slack… don’t bother me too much, b/c I just added it to ZNC and use it as any other IRC network; but I’d like to also integrated FB Messenger (well, b/c there are almost no girls on IRC…) and Twitter personal messages… that’s what is Matrix made fo 2017-04-18 20:24:31 TemptorSent: the client story for matrix's native protocol is kind of missing right now (although they have riot which is kind of a mashup between the xchat and slack UIs, which looks pretty ok) 2017-04-18 20:24:54 actually, it bothers me a little, b/c I must still explain them that I don’t see their fucking emoticons and other crap 2017-04-18 20:25:00 kaniini: I'll have to dig into matrix a bit deeper, but it seems awfully heavy for the individual server. 2017-04-18 20:25:15 and also written in Python… 2017-04-18 20:25:30 but there’s already a project for Matrix server in Rust! :) 2017-04-18 20:26:40 TemptorSent: there are newer implementations under development, synapse was basically meant to be a proof of concept 2017-04-18 20:27:59 kaniini: I'm not really a fan of the whole stateless model nor json for content interchange. A single word message ends up a couple k it appears. 2017-04-18 20:28:03 one platform to bridge them all and in the darkness absorb them 2017-04-18 20:28:39 TemptorSent: stateless is necessary if you do not want to murder battery 2017-04-18 20:28:44 TemptorSent: it gets better, it also uses WebRTC. 2017-04-18 20:28:52 TemptorSent: at least it’s not XML or some binary protocol; JSON is totally okay for this purpose IMO 2017-04-18 20:28:57 TemptorSent: keeping conncetions open means you're keeping the radio on 2017-04-18 20:29:06 awilfox: yes, for an optional extension 2017-04-18 20:29:13 awilfox: that you do not have to use or implement 2017-04-18 20:29:32 kaniini: I'd rather see it done with a psudo-stateful connection manager then... 2017-04-18 20:30:16 jirutka: It's not so much the json format itself, as the rather large amount of meta-data it has to transmit with each message. 2017-04-18 20:31:46 kaniini: Something which allows the client to use a queue and checkpoints would be much more appropriate than the statless model it appears to use IMHO. 2017-04-18 20:32:02 they do use checkpoints, actually. 2017-04-18 20:32:32 you connect and you ask how many events have come in since 2017-04-18 20:33:40 yeah, I see that -- but it requires far too much recordkeeping because it's split between many event sources. 2017-04-18 20:34:38 no the 'homeserver' handles that for you 2017-04-18 20:35:08 or do you mean how it has different URIs for eahc object 2017-04-18 20:35:42 What really gets me is stuff such as '"ephemeral": { "events": [ "type": "m.typing", "content": { "user_ids": ["@alice:example.com"]}}]} 2017-04-18 20:36:23 Yeah, you can't simply request the stream for the last 5 minutes for all activity. 2017-04-18 20:37:16 TemptorSent: what bothers you on this? I assume that you can disable notifications about someone typing if you want 2017-04-18 20:37:54 How many bytes does it take to print '...' while someone is typing? How many hundreds of times a minute is that sent? 2017-04-18 20:37:58 TemptorSent: I also don’t like it, it feel like someone is watching behind me back, but some ppl consider this useful 2017-04-18 20:38:29 TemptorSent: it contains only minimum information needed 2017-04-18 20:38:33 IMHO, that belongs in an IM tool, not a general chat server. 2017-04-18 20:38:55 it was added because slack does it 2017-04-18 20:39:00 and people asked for it 2017-04-18 20:39:09 you do not have to use a client which sends those messages if you don't want 2017-04-18 20:39:11 kaniini: not just Slack, even ancient ICQ had this feature 2017-04-18 20:39:13 Yeah, not a good thing IMHO. 2017-04-18 20:39:14 hint: the ircv3 guys are doing the same thing 2017-04-18 20:39:37 If you want to do that sort of thing, do it OOB. 2017-04-18 20:39:40 it is coming whether you want it to or not 2017-04-18 20:39:48 even to IRC 2017-04-18 20:40:02 how would that IM tools do it, if it was not in protocol? send smoke signals? 2017-04-18 20:40:35 or just keep it unstandardized, so every client would use different message for this? 2017-04-18 20:40:37 UDP would probably be my choice.. 2017-04-18 20:40:50 that’s non-sense 2017-04-18 20:41:07 it would just increase complexity of the protocol for few bytes to save? 2017-04-18 20:41:09 come on 2017-04-18 20:41:23 If you want to send a packet per keystroke, do you really need to establish a tcp connection, post a request, receive a json reply, parse that, and eventually display it? 2017-04-18 20:41:46 TemptorSent: it is not per keystroke. there are usually timers involved 2017-04-18 20:41:48 If it's stateless, it should use a stateless protocol. 2017-04-18 20:41:50 also don’t forgot that many (most?) ppl have actually broken Internet, because of NATs… so no P2P connection 2017-04-18 20:42:22 TemptorSent: you’re talking about micro-optimizations for one particular even not important type of message 2017-04-18 20:42:26 jirutka: That's fine, a simple repeater on a port on the server works just as well. 2017-04-18 20:42:30 AIM uses "typing for at least 500msec or 3 keystrokes" -> "Foo is typing..." message, and then either "stops typing for at least 2 sec" or "send message" as "Foo is not typing" message 2017-04-18 20:42:51 s/even/event/ 2017-04-18 20:42:53 Actually, most of the messaging could be done by UDP rather than TCP. 2017-04-18 20:42:56 but this is all silly, if it wasn't using bloated dumb json it wouldn't be such a waste. you already have TCP connection established. 2017-04-18 20:43:01 eh, no, it was right, even 2017-04-18 20:43:16 exactly 2017-04-18 20:43:35 you don’t have to (and really should not) establish plain new TCP connection for each message 2017-04-18 20:43:49 My point is that using a stateless protocol over TCP is counterproductive. 2017-04-18 20:44:01 no, it’s not 2017-04-18 20:44:01 If you really want to save battery life, use UDP. 2017-04-18 20:44:27 push notifications can't use UDP on most/all phones 2017-04-18 20:44:27 TCP vs. UDP is not just about state(less) 2017-04-18 20:44:38 No, it's also about reliability. 2017-04-18 20:44:42 and TCP is for streaming 2017-04-18 20:44:49 and this is a stream of stateless messages 2017-04-18 20:44:50 it’s about guarantee that the message has been really received by the receiver 2017-04-18 20:45:11 jirutka: also ordering. 2017-04-18 20:45:14 yes 2017-04-18 20:45:17 Establish a tcp connection to the stream, send udp messages, if they don't show up, resend. 2017-04-18 20:45:36 TemptorSent: you kinda just re-invented TCP but using UDP on top of it. that seems silly 2017-04-18 20:45:42 what actually Matrix use? HTTP? 2017-04-18 20:45:49 Yeah. 2017-04-18 20:45:49 awilfox: exactly 2017-04-18 20:46:37 TemptorSent: do you know how expansive HTTP is for this kind of communication? and you’re talking about TCP vs. UDP? 2017-04-18 20:47:17 TCP is fine for reading an incoming stream (but not so much for push updates), but for individual messages, especially of an ephemeral nature, udp makes more sense. 2017-04-18 20:47:21 TemptorSent: I’d rather complain about this; for example FB Messenger uses MQTT and that was IMO actually very good idea, especially for phones with bad network connection 2017-04-18 20:47:41 nevermind that UDP is not NAT friendly 2017-04-18 20:47:48 and what are phones behind? NAT 2017-04-18 20:48:05 yeah 2017-04-18 20:48:25 yes, MQTT is an excellent transport because you can pick up where you left off 2017-04-18 20:48:49 That's essentially what I was saying should be used, rather than the REST api matrix has. 2017-04-18 20:49:15 and it also provides 3 levels of QoS, so you can choose e.g. 0 (no guarantees) for this “typing…” messages and 2 for important messages 2017-04-18 20:49:24 I just think for ephemeral messaging TO the server, UDP would be appropriate. 2017-04-18 20:49:54 TemptorSent: no, you was saying that it should use UDP for “typing…” messages, which is just plain silly… 2017-04-18 20:50:22 all i know is that if you dont use a stateless protocol you have to keep the connection open which keeps the radio hot 2017-04-18 20:50:25 jirutka: For sending ephmemeral data (such as typing) to the server. 2017-04-18 20:50:26 which kills battery 2017-04-18 20:50:33 that's just the reality of it 2017-04-18 20:51:05 if apple did anything of value in the past decade, it was driving that point home to stupid developers 2017-04-18 20:51:11 kaniini: Yeah, I work mostly in non TCP land when I'm dealing with embedded hardware, we're looking for a few hundred ms wakeup per minute mx. 2017-04-18 20:51:19 TemptorSent: but this is not just about some laboratory environment, you really didn’t considered all consequences 2017-04-18 20:52:07 jirutka: Are you saying outgoing udp from devices to services is likey broken as well? 2017-04-18 20:52:39 most phones cant just send udp packets anyway 2017-04-18 20:52:54 android and ios make you go through a lot of hoops to send udp packets 2017-04-18 20:53:02 Ouch. 2017-04-18 20:53:04 because it turns out people get upset when their phones start participating in ddos attacks 2017-04-18 20:53:39 you have to consider data usage efficiency too 2017-04-18 20:53:52 if your phone is sitting there sending a bunch of redundant udp packets 2017-04-18 20:54:04 it means the user of the app is consuming more data than competitor apps 2017-04-18 20:54:13 so they might quit using your app 2017-04-18 20:54:19 because they do not want to waste their data 2017-04-18 20:54:28 Not necessarily, you'd window the output. 2017-04-18 20:54:44 unlimited data packages are really a US thing 2017-04-18 20:54:58 UDP has less overhead per packet than TCP generally. 2017-04-18 20:55:09 yes, I have ~2 GiB/month and that’s luxury there… 2017-04-18 20:55:10 We don't have unlimited data here either. 2017-04-18 20:55:19 and don’t even ask how much money I pay for this 2017-04-18 20:55:21 i do 2017-04-18 20:55:34 a lot? 2017-04-18 20:55:36 :D 2017-04-18 20:55:41 I don't even have a smart phone, so it's kinda moot :P 2017-04-18 20:56:14 jirutka: well unlimited data packages in the US aren't 2017-04-18 20:56:35 you get X GiB at 4G speeds and then they throttle you to like 128kbps for the rest of the billing period 2017-04-18 20:56:52 or you can pay extra and then 2017-04-18 20:56:53 around 450 Kč (18 USD) per month and that’s special tariff for small company (it’d be twice otherwise) 2017-04-18 20:57:26 128 kbps? that would be excellent! 16 or 32 kbps here (donjt remember exact number)… 2017-04-18 20:57:48 you get X GiB at 4G speeds and then they only throttle you if the network is busy 2017-04-18 20:57:54 but the extra is like 20-30 USD 2017-04-18 20:57:55 if that is even an option 2017-04-18 20:57:57 Yeah, I'm paying US 45/mo for my unlimited voice/no data plan, and I don't even get service most of the time. 2017-04-18 20:58:30 jirutka: geeze 2017-04-18 20:58:30 (btw when comparing prices, also remember that there are very different salaries per countries) 2017-04-18 20:58:53 yes 2017-04-18 20:58:56 18 USD probably has a lot more buying power 2017-04-18 20:59:04 in .cz? 2017-04-18 20:59:08 Yeah, and total cost of living. 2017-04-18 20:59:12 i think .cz 2017-04-18 20:59:13 i could be wrong 2017-04-18 20:59:32 here 18 USD doesn't get you much 2017-04-18 20:59:34 hm, actually, if nothing changed, than some time ago they decided to totally disable your data when you’re out of limit… just remembered that there was some cause about this a year ago 2017-04-18 21:00:10 well 2017-04-18 21:00:17 the funny thing is 2017-04-18 21:00:19 beer costs around 1.1 USD in CZ 2017-04-18 21:00:27 america went from unlimited being the only option 2017-04-18 21:00:34 to really capped plans 2017-04-18 21:00:38 where if you ran out of data 2017-04-18 21:00:42 they would charge you like 2017-04-18 21:00:46 $30 per GiB 2017-04-18 21:00:57 so people were getting like $400+ bills 2017-04-18 21:01:11 i'm sure the carriers loved that 2017-04-18 21:01:22 here it’s around 4 USD per 100 MiB… 2017-04-18 21:01:25 then the FCC started to crack down on it 2017-04-18 21:01:30 and now they have been moving back to unlimited plans 2017-04-18 21:01:43 jirutka: A decent beer on tap here is $5-$9US! 2017-04-18 21:02:15 and you can’t even get unlimited data plan if you’re not a big company… there are not data plans with more than around 5 GiB/month for public… 2017-04-18 21:02:42 here you can literally go as high as 100GB if you want to 2017-04-18 21:02:48 from some carriers 2017-04-18 21:02:58 although i think they dropped those big plans and just launched 'unlimited' again 2017-04-18 21:05:13 I don't think I could pull 100GB a month over my DSL line! 2017-04-18 21:05:47 I’m happy that I have fiber optic :) 2017-04-18 21:06:07 whats funny is 2017-04-18 21:06:08 i could go to CZ 2017-04-18 21:06:17 and blow through 50GB roaming 2017-04-18 21:06:23 and it costs me nothing 2017-04-18 21:06:32 heh 2017-04-18 21:06:34 that's how saturated the cell market is in america 2017-04-18 21:06:48 they now offer unlimited international 4G roaming 2017-04-18 21:07:09 they can afford to do that 2017-04-18 21:07:17 that shows you how profitable that industry is 2017-04-18 21:07:56 if I went to USA and blow through 50 GiB roaming, then I’d have to probably sell my apartment to pay it… 2017-04-18 21:08:00 jirutka: I'm about a half-mile of moderately solid rock worth of trenching to fibre. 2017-04-18 21:08:43 What gets me is that with the density of radios we have now, telcos are still making a killing when the mesh capacity exceeds their backhaul. 2017-04-18 21:09:54 actually fiber optic to home is far from the standard thing in CZ, this is a good luck, many of my friends have just shitty DSL even in Prague and pay more than I pay for fiber 2017-04-18 21:10:01 it very depends on locality 2017-04-18 21:10:08 jirutka: same in France really. 2017-04-18 21:10:33 cities are fine, with state-of-the-art connectivity 2017-04-18 21:11:06 the rural parts of the country, which there are still a lot of, still live in the XXth century or something. 2017-04-18 21:12:38 I have 30/30 Mbps for $12/month, if I’d pay $16/month, I can have 100/100 Mbps; this is probably the best offer I heard about and even quality is excellent; it’s a small local ISP 2017-04-18 21:12:52 Yeah. It's funny up where I live. I'm about 20 miles from the nearest city, and I've got ADSL2+ running at somewhere around a meg. My friend Lu lives in Iowa Hill, a smaller town than mine about 10 miles as the crow flies. They still don't have electricity, but she has 100mbps fiber to her home! 2017-04-18 21:13:25 jirutka: that's pretty nice indeed. Good thing you still have small local ISPs, those are the only ones doing good work! 2017-04-18 21:13:36 jirutka: Damn, I'm jealous! 2017-04-18 21:13:38 we have the biggest penetration of WiFi providers here… b/c local telcos are so bad, that ppl started building local WiFi networks in cities 2017-04-18 21:13:51 skarnet: well, still don’t have IPv6 :( 2017-04-18 21:13:58 skarnet: but otherwise I can’t complain 2017-04-18 21:14:01 TemptorSent: and how do they power their fiber? steam engines? :P 2017-04-18 21:14:37 Likewise -- I don't get why the ISPs aren't deploying IPV6 as fast as possible. 2017-04-18 21:14:49 skarnet: Solar, generators, and yes, a few steam engines! 2017-04-18 21:14:50 (I mean biggest penetration worldwide, in CZ) 2017-04-18 21:15:06 skarnet: As well as some micro hydro. 2017-04-18 21:15:15 USA: the most advanced third world country 2017-04-18 21:15:33 TemptorSent: b/c most users don’t have a clue what IPv6 is, so they do not demand it… 2017-04-18 21:15:53 TemptorSent: and it cost money to deploy IPv6, so when only few customers demands IPv6, why bother…? 2017-04-18 21:15:57 skarnet: I'm actually specing out a steam system for a micro-biomass plant. 2017-04-18 21:16:57 if e.g. FB or Google go only via IPv6, then it would go very, very fast with deploying IPv6… 2017-04-18 21:17:08 jirutka: Because all the damn IoT crap they are drooling to support would be much easier if they had IPV6? My local ISP also runs the security systems, so they have thousands of addressible camers, monitors, etc. 2017-04-18 21:17:20 but no one “content provider” can afford to provide services only via IPv6 2017-04-18 21:17:38 TemptorSent: they just deploy NATs over NATs over NATs… 2017-04-18 21:17:45 TemptorSent: yes, it’s insane stupidity… 2017-04-18 21:17:54 jirutka: Why isn't every bloody phone just and IPV6 address away? 2017-04-18 21:18:44 TemptorSent: crappy Android, unfortunately most used mobile OS, didn’t even have propoer IPv6 support quite recently… 2017-04-18 21:18:51 Fine, support IPV4 legacy clients, but why the hell not avoid the whole mess where you can and allocate a few thousand addresses per home/person. 2017-04-18 21:18:52 TemptorSent: DHCPv6 was missing IIRC 2017-04-18 21:19:16 Forward thinking :P 2017-04-18 21:19:37 TemptorSent: why? ppl don’t understand it, they just install router with NAT and use shitty centralized services for all things… they don’t need P2P connections… 2017-04-18 21:20:32 Yeah, how good is YOUR router? The crap the telcos provide can't handle more than a few active connections to track. 2017-04-18 21:20:55 Not to mention the whole mess with QoS over NAT 2017-04-18 21:21:03 quite shitty actually, should replace it soon 2017-04-18 21:21:34 I need to find a good MODEM ONLY ADSL/VDSL unit. 2017-04-18 21:21:40 not sure if you understand my position, I’m fully with you, I’m just trying to explain you the situation, why most ppl don’t demand IPv6 2017-04-18 21:22:00 and why telcos are not very hurry to support IPv6 2017-04-18 21:22:05 Oh, I know - I just want to beat them into it. 2017-04-18 21:22:42 But what I don't understand is why telcos that are providing 'converged' services aren't doing so, if nothing else than to save their own money and time. 2017-04-18 21:23:25 what converged services? 2017-04-18 21:23:28 VoIP + Video Chat + streaming videos/music + gaming. 2017-04-18 21:23:40 they don’t, at least here 2017-04-18 21:23:51 just IPTV 2017-04-18 21:24:16 Ahh, that's the big thing here, the so-called 'Triple-Play' Phone / TV / Internet 2017-04-18 21:25:10 With home security/'smart home' features being a big up and coming segment for our ISPs/telcos. 2017-04-18 21:25:14 TemptorSent: my router is excellent 2017-04-18 21:25:24 kaniini: What are you running? 2017-04-18 21:25:26 the biggest pain is that you can’t just switch to IPv6, you still need even IPv4 :/ 2017-04-18 21:25:28 TemptorSent: once i finish the alpine mips64 port, it will be running alpine 2017-04-18 21:25:40 TemptorSent: right now it runs some commercial distribution of Vyatta 2017-04-18 21:25:42 kaniini: Nice! 2017-04-18 21:25:45 so it’s not about replacing one already almost dead protocol with better protocol, but about supporting additional protocol 2017-04-18 21:25:52 kaniini: What's the hardware under it? 2017-04-18 21:26:18 jirutka: Right, and allowing multiple devices without NAT. 2017-04-18 21:26:34 TemptorSent: https://www.ubnt.com/edgemax/edgerouter-poe/ 2017-04-18 21:26:49 Ubiquity? Nice stuff. 2017-04-18 21:26:56 TemptorSent: i have the highend version as a porting machine 2017-04-18 21:26:58 TemptorSent: yes, that’s even worse, b/c then you don’t have two symmetrically configured network, but two very different networks 2017-04-18 21:27:31 TemptorSent: and that causes many issues, some affects even customers and try explain BFU why something does not work b/c of IPv4 vs. IPv6… 2017-04-18 21:27:42 TemptorSent: so basically my goal is to enable people to buy the edgerouter and then liberate it by installing alpine 2017-04-18 21:28:30 does anyone here heard about Turris router? 2017-04-18 21:28:32 jirutka: Ideally, they would provide IPV6 for everything, and an IPV4 tunnel for legacy. 2017-04-18 21:28:34 https://www.turris.cz/en/ 2017-04-18 21:28:42 kaniini: I like it :) 2017-04-18 21:28:44 TemptorSent: the hardware is unremarkable, it is basically just a cavium octeon2 board inside with an ethernet switch chip 2017-04-18 21:28:54 TemptorSent: all supported by stock linux 2017-04-18 21:29:19 kaniini: How are the magnetics? 2017-04-18 21:29:33 late reminder that irc <-> matrix federation is absolute garbage 2017-04-18 21:29:41 it's better than slack's, but only a little 2017-04-18 21:29:52 Shiz: uh, why? 2017-04-18 21:30:03 jirutka (IRC): do you like highlights like this? 2017-04-18 21:30:13 Shiz: no, I don’t 2017-04-18 21:30:26 jirutka (IRC): or a text link to some rando server containing text contents if your message exceeds 512 chars 2017-04-18 21:30:34 Shiz: WTH?! 2017-04-18 21:30:43 ??? WTF? 2017-04-18 21:31:07 Shiz: even that stupid Slack can handle bigger message, just splits it into multiple messages 2017-04-18 21:31:17 I mean Slack IRC gateway 2017-04-18 21:31:21 not to mention all matrix users having that stupid [m] in their name 2017-04-18 21:31:23 Shiz[m] 2017-04-18 21:31:25 jirutka[m] 2017-04-18 21:31:29 Shiz: and irccloud doesn't also have those behaviours? :) 2017-04-18 21:31:36 can’t this be just disabled? 2017-04-18 21:31:46 probably, but its on by default and everbody uses it 2017-04-18 21:31:52 ACTION does not have an [m] by my name 2017-04-18 21:31:54 kaniini: im not sure how irccloud is related to any of this, it's shit too 2017-04-18 21:31:59 <^7heo> ncopa: did you get my mail answer? 2017-04-18 21:32:13 kaniini[m]: you think you don't 2017-04-18 21:33:00 lols 2017-04-18 21:33:07 i admit i did have to check to be sure 2017-04-18 21:33:41 * Achievement Unlocked * You successfully trolled kaniini. 2017-04-18 21:33:45 kaniini: Hmm, I can't find the isolation voltage specs in the ubnt datasheet -- Do you have any info? I've got a few sites with MAJOR lightning and RADAR! problems. 2017-04-18 21:33:52 skarnet: \o/ XD 2017-04-18 21:33:55 Well played skarnet! 2017-04-18 21:35:23 Shiz: i would argue that automatic pastebinning of very large text is a feature though 2017-04-18 21:35:36 like something that would otherwise be 10+ lines in irc 2017-04-18 21:36:02 i would argue that i dont want chat contents to be accessible over http on a random matrix server 2017-04-18 21:36:08 if you need to pastebin, use a pastebin site... 2017-04-18 21:37:27 kaniini - Do you think we can get alpine running on this :) : https://www.ubnt.com/airmax/powerbeam-ac-iso/ 2017-04-18 21:37:33 anyway, my point largely has to do more with 2017-04-18 21:37:44 we should federate the chat resources as we did the git resources 2017-04-18 21:39:30 i do not think a third-party platform (private internet access née freenode) should be the gatekeeper on who gets to participate on #alpine-* channels 2017-04-18 21:40:16 and that as time goes on, we will continue to miss out on contributors who think IRC is really outdated (aka: millenials) 2017-04-18 21:40:33 matrix was just one way to accomplish that type of federation 2017-04-18 21:40:40 Shiz: ^ 2017-04-18 21:41:10 kaniini: https://xkcd.com/1782/ 2017-04-18 21:41:12 i dont disagree with federation, btw 2017-04-18 21:41:24 exactly jirutka 2017-04-18 21:41:43 kaniini: I meant that IRC will not die! XD but I agree with you 2017-04-18 21:41:45 i think the clone to github was really well for us 2017-04-18 21:42:00 and having some kind of federation across platforms is good 2017-04-18 21:42:07 we should also be on bitbucket and on gitlab 2017-04-18 21:42:11 be on all the things 2017-04-18 21:42:14 i just get itches everytime someone mentions matrix 2017-04-18 21:42:18 kaniini: and I think that we all don’t want some shit like Slack, so we’ll choose something sane 2017-04-18 21:45:15 oh hell no 2017-04-18 21:45:15 no slack 2017-04-18 21:45:43 i use slack for work, it is way better for most people than our attempt at using irc was 2017-04-18 21:45:44 but 2017-04-18 21:45:50 slack is for small business setups 2017-04-18 21:45:56 it's not FOSS scale 2017-04-18 21:46:01 yeah 2017-04-18 21:47:15 but i do think federating with gitter has value 2017-04-18 21:47:30 because it's an untapped demographic 2017-04-18 21:47:34 I totally hate how Slack basically just reinvented IRC with nicer client, closed proprietary protocol, and their market value is bigger than ((IIRC) even SpaceX that actually do something innovative and amazing 2017-04-18 21:47:44 Okay, I guess I'm going to have to go find out what glitter is. 2017-04-18 21:48:02 TemptorSent: gitter is gitlab's proprietary slack clone 2017-04-18 21:48:06 if by 'reinvented irc' you mean 'has chat' 2017-04-18 21:48:10 and 'has channels' 2017-04-18 21:48:15 there's nothing much more in common, namely 2017-04-18 21:48:20 and has # everywhere 2017-04-18 21:48:27 I use Slack as first example of start-up culture, VC and what’s wrong with money redistribution 2017-04-18 21:48:42 and slack is big because it's useful 2017-04-18 21:48:46 yes, how the fuck is slack worth billions 2017-04-18 21:48:48 Gitter is not GitLab’s… or did they bought them? 2017-04-18 21:48:57 gitlab bought gitter 2017-04-18 21:49:08 wow, didn’t know about that 2017-04-18 21:49:41 Okay, just going to their webpage is enough for me to run screaming! 2017-04-18 21:49:45 i mean, i don't like gitlab, inc either 2017-04-18 21:49:46 but i think they are at least more trustworthy than private internet access 2017-04-18 21:50:14 TemptorSent: it's not for a well-established Gen-Xer like yourself 2017-04-18 21:51:47 well, i have the solution 2017-04-18 21:51:50 we clearly need to move to rizon 2017-04-18 21:51:57 move to what? 2017-04-18 21:53:28 Shiz: You mean AMD's latest and greatest disappointment? 2017-04-18 21:53:59 that's ryzen 2017-04-18 21:54:07 and people seem to disagree on that one 2017-04-18 21:55:00 Let me know when we can actually generate fast code for it, then I'll give it a fair shake. 2017-04-18 21:55:30 Okay, so that aside, WTF is rizon then? 2017-04-18 21:55:47 I'm apparently not buzz-word compliant. 2017-04-18 21:55:57 or google-compliant, apparently 2017-04-18 21:56:14 Same thing :P 2017-04-18 21:57:11 Shiz: +1 XD 2017-04-18 21:57:45 Oh, "Network features built-in entertainment and very simple access to over 20 servers across the network." How inspiring. 2017-04-18 21:58:56 Ahh, it came up somewhat after I got out of things back then, that's why I'd never heard of it. 2017-04-18 21:59:57 ^7heo: re nginx? yes. you and jirutka can fight about who will take it 2017-04-18 22:00:24 ncopa: ^7heo: too late, I already did it, just going to push XD 2017-04-18 22:00:31 i'm gonna push libressl 2.5 in a minute + 200+ rebuilds 2017-04-18 22:00:48 jirutka: can you hold it 30 sec? 2017-04-18 22:01:01 Sounds like fun -- we'll see how much carnage comes out of that :) 2017-04-18 22:01:02 ncopa: yes, why? 2017-04-18 22:01:11 so it gets built with libressl 2.5 2017-04-18 22:01:39 ncopa: I haven’t bumped yet, just claimed maintainership and added _url variable for every external module to make you happy :) 2017-04-18 22:02:12 libressl 2.5 pushed 2017-04-18 22:02:23 thanks! 2017-04-18 22:02:33 ncopa: now I’m going to integrate some of good changes from Valery’s mega-commit 2017-04-18 22:03:02 super thanks for taking care of it 2017-04-18 22:03:26 i owe you another beer 2017-04-18 22:03:40 oh, so many commits! if clandmeter has server still in his office, he would not be able work tonight XD 2017-04-18 22:04:00 he might not be able to work tm morning either :) 2017-04-18 22:04:06 XD 2017-04-18 22:04:19 ncopa: Do you have any objection to removing the modules from the building of the initfs.cpio.gz and appending them upon install? 2017-04-18 22:05:11 ncopa: btw have you looked at https://github.com/alpinelinux/aports/pull/1261 ? :) 2017-04-18 22:05:15 the only objection i have right now is anythign that can prevent me from go to bed :) 2017-04-18 22:05:39 TemptorSent im not sure what you mean 2017-04-18 22:05:48 but i really need to go 2017-04-18 22:05:51 ncopa: Basically creating two distinct cpio.gz, one with only userland, one with only kernel artifacts, then appending them after the fact. 2017-04-18 22:06:01 ncopa: No problem, get some rest! 2017-04-18 22:06:36 ncopa: VVV 2017-04-18 22:08:13 One cpio.gz is created out of the kernel staging and contains only the kernel-specific artifacts, such as the kernel, symbols, modules, dtbs, firmware, etc., and is named for instance modules-$krel.cpio.gz. 2017-04-18 22:10:31 The other is generated by staging the required userspace files using fkrt, apk, globs, and checksums, and creating a cpio.gz such as initfs-$date.cpio.gz. 2017-04-18 22:11:37 To install, simply cat the two together 'cat initfs-$date.cpio.gz modules-$krel.cpio.gz > initramfs-$krel' 2017-04-18 22:12:38 I’m dead, going to bed; good night! 2017-04-18 22:13:03 You could also just append both in the bootloader, which may be a way around any license issues with things such as zfs, as you can make a seperate cpio.gz, say modules-zfs-$krel.cpio.gz and append that in the bootloader. 2017-04-18 22:13:50 Same goes for userspace. Taken to the logical conclusion, this means we could ship everything prebuilt as fragments and append those together rather than creating them on the client machines. 2017-04-18 22:14:56 Goodnight jirutka! 2017-04-18 22:16:23 It's not him 2017-04-18 22:16:35 He doesn't go to bed at this time 2017-04-18 22:21:07 clandmeter: I do, sometimes, after afternoon walking around shops to find good couch :) 2017-04-18 22:21:43 clandmeter: and I’m not going to sleep right now, wanna watch one episode of Mr. Robot and then sleep :) 2017-04-18 22:22:11 See there he is 2017-04-18 22:22:32 I didn't like the last season 2017-04-18 22:22:40 Too weird 2017-04-18 22:23:58 yeah, my colleague already warned me that 2nd season is not very good, I’m watching the first session now 2017-04-18 22:24:12 ep 7 now 2017-04-18 22:38:11 <^7heo> ncopa: meh ok. Maybe it's worth fixing the ML tho. It's not the first time that happened to me. 2017-04-18 22:38:40 <^7heo> also mr robot is kinda shit 2017-04-18 22:38:53 <^7heo> the first episode is great 2017-04-18 22:39:17 <^7heo> maybe the first episodeS to be nice 2017-04-18 22:39:28 <^7heo> but yeah, nah, waste of time 2017-04-18 23:12:20 ^7heo: I don’t see any email from you from yesterday on ML o.O 2017-04-18 23:13:03 <^7heo> jirutka: yes exactly. 2017-04-18 23:13:09 <^7heo> jirutka: my point. 2017-04-18 23:14:22 ^7heo: I’ve just seen s01e07 and it’s still good; the scene where Eliot told Krista the truth was really terrifying… if someone would tell me something like this I’d shit my pants 2017-04-18 23:14:58 <^7heo> meh 2017-04-18 23:15:07 ^7heo: she probably didn’t have a clue what he really is, really serious psychopath 2017-04-18 23:15:09 <^7heo> nothing to do with hacking tho 2017-04-18 23:15:20 <^7heo> yeah I dunno 2017-04-18 23:15:35 <^7heo> just not what I wanted to see I guess 2017-04-18 23:15:40 yes, but quite interesting from me from sociological and psychological PoV 2017-04-18 23:15:49 s/from/for/ 2017-04-18 23:16:55 <^7heo> yeah but I will check other series for that 2017-04-18 23:17:07 <^7heo> hence mr robot == shit imho 2017-04-18 23:17:32 it has very good ratings and many ppl recommended it to me 2017-04-18 23:21:38 <^7heo> wait are we still talking about ubuntu? 2017-04-18 23:22:12 uh… wha… okay… well played, really well played! 2017-04-18 23:23:14 but still, I’d not say that this show is a shit, it’s just different than what we expected 2017-04-18 23:23:20 noot noot 2017-04-18 23:23:24 <^7heo> jirutka: thanks 2017-04-18 23:23:26 <^7heo> :p 2017-04-18 23:24:10 <^7heo> jirutka: maybe it's good if you're okay with unmet expectations 2017-04-18 23:24:18 <^7heo> jirutka: I wouldn5t know 2017-04-18 23:24:27 <^7heo> wouldn't* fuckin phone 2017-04-18 23:24:43 I can adapt ;) 2017-04-18 23:25:10 <^7heo> yeah 2017-04-18 23:25:11 b/c the new theme is interesting for me as well 2017-04-18 23:25:35 <^7heo> cameleon jirutka. 2017-04-18 23:25:47 so I’m not dissapointed that it’s not mainly about hacking 2017-04-18 23:26:05 <^7heo> but yeah, I was really hoping for something with real hacking 2017-04-18 23:26:15 unrealistic expectations 2017-04-18 23:26:25 ^ agree 2017-04-18 23:26:27 <^7heo> and things I could relate to 2017-04-18 23:26:43 <^7heo> I'm not a psycho who dreams his father out 2017-04-18 23:26:49 <^7heo> I can't get that 2017-04-18 23:27:04 <^7heo> it's just too... far fetched 2017-04-18 23:27:16 but what I really don’t like about this show is this stereotype that hackers == crazy junkies 2017-04-18 23:27:55 <^7heo> yeah, kinda my point 2017-04-18 23:28:04 why every movie about hackers shows them as underground freaks on drugs? 2017-04-18 23:28:24 ^7heo: no spoilers damn! 2017-04-18 23:28:34 <^7heo> oooh sorry 2017-04-18 23:29:11 <^7heo> yeah well how can you explain cleverness and genius to stupids? 2017-04-18 23:29:14 <^7heo> drugs! 2017-04-18 23:29:21 <^7heo> they can understand drugs. 2017-04-18 23:29:25 I don’t know any hacker group tbh, but still don’t think that every hacker must be junky 2017-04-19 03:43:16 Okay, this working around not being able to use full package atoms to apk is getting beyond annoying now -- I'm having to loop over or sed out every package atom just to ask apk what files it contains (apk info -L $pkgatom) 2017-04-19 03:47:43 What I want to do is "apk info -v | xargs apk info -L | awk -e '/contains:$/ { pkg=$1 ; next } ..... 2017-04-19 07:08:07 i want to add opus to gstreamer 2017-04-19 07:43:23 xsteadfastx: http://dup.pw/aports/f8594a59 2017-04-19 07:44:31 ok that was fast 2017-04-19 07:44:33 i did the same 2017-04-19 07:44:39 but wanted to test it first ;-) 2017-04-19 07:44:55 sudo apk -U upgrade and test ;-) 2017-04-19 07:46:18 but yes this was fast as the change is not intrusive, and having opus support makes sense :) 2017-04-19 07:46:37 soemtimes its sooo easy :-) 2017-04-19 08:08:00 <^7heo> ncopa: have you built firefox with PIE after version 48? 2017-04-19 08:09:14 woohoo, never ending backlog story :P 2017-04-19 08:10:03 <^7heo> moin scadu 2017-04-19 08:10:10 ^7heo: https://git.alpinelinux.org/cgit/aports/tree/testing/firefox/APKBUILD#n127 2017-04-19 08:11:01 ^7heo: morning 2017-04-19 08:11:22 <^7heo> ncopa: I've seen that. 2017-04-19 08:11:38 <^7heo> ncopa: I meant continuously 2017-04-19 08:12:14 ^7heo: probably I have to try freenode@matrix and riot on the phone. I can't keep up the logs on the phone with weechat :p 2017-04-19 08:13:47 <^7heo> ncopa: I'm asking because a friend of mine is trying to build firefox on BSD with PIE, and examples of patches would help him a lot 2017-04-19 08:14:59 file /usr/lib/firefox-52.0.2/firefox 2017-04-19 08:14:59 /usr/lib/firefox-52.0.2/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=467fe507f3c4f58264461cba7d348efb783db9c9, stripped, with debug_info 2017-04-19 08:15:12 it says "shared object", so its built with PIE 2017-04-19 08:15:21 <^7heo> ah 2017-04-19 08:15:44 <^7heo> but so do we have a patch for that? 2017-04-19 08:17:51 i think firefox supports it upstream? 2017-04-19 08:18:12 https://bugzilla.mozilla.org/show_bug.cgi?id=857628 2017-04-19 08:18:38 looks like support for build with PIE have been there since firefox 35 2017-04-19 08:18:54 anything else you need help to google? :-p 2017-04-19 08:50:57 nmeum, i added your newapkbuild patch to aports, else it doesn't do much until new version arrives. 2017-04-19 08:51:08 atleast i think its you :) 2017-04-19 08:52:12 how long does it take if a package got built on the build server to appear in the repos? 2017-04-19 08:52:16 clandmeter: good idea, I considered doing that as well but didn't get around to it - thanks 2017-04-19 08:52:37 xsteadfastx, depends on the repo's 2017-04-19 08:54:17 i want to test the gst-plugins-base1-r1 it just got built 2017-04-19 08:54:45 for x86_64 2017-04-19 08:55:11 i mean which mirror :) 2017-04-19 08:56:08 update freq is probably 15min,30min,1h,1d (depending on the mirror) 2017-04-19 08:56:14 ah ok 2017-04-19 08:56:29 i use dl-cdn.alpine.linux.org... so i just wait a little 2017-04-19 08:56:50 ncopa, do you know the update freq of cdn 2017-04-19 08:56:51 ? 2017-04-19 08:57:09 maybe its a good thing to add that to the metadata of mirrors 2017-04-19 09:02:49 why polling and not notifications 2017-04-19 09:03:13 cause we have no control over those mirrors 2017-04-19 09:03:29 ugh 2017-04-19 09:08:56 actually its already possible to trigger on notifications if somebody would implement it. you can sub on our mqtt and listen for upload msg's. 2017-04-19 09:10:57 there is a mqtt server? thats neat. like this its not that hard to get notifications 2017-04-19 09:11:27 <^7heo> ncopa: let's be clear, I merely relay a request from a maintainer in another OS. 2017-04-19 09:11:45 <^7heo> ncopa: and I think he knows how to google. 2017-04-19 09:56:43 skarnet, we could still use a partner with a geo located infra to share with us. 2017-04-19 10:07:25 why are you looking at me like that? O.O 2017-04-19 10:08:40 (on a totally unrelated note, can an Alpine cdn note be implemented over busybox httpd and simple sh scripting?) 2017-04-19 10:08:46 s/note/node/ 2017-04-19 10:10:53 @ncopa │ it says "shared object", so its built with PIE 2017-04-19 10:10:57 that is not inherently true 2017-04-19 10:11:08 # readelf -d /bin/ls | grep FLAGS_1 2017-04-19 10:11:10 0x000000006ffffffb (FLAGS_1) Flags: NOW PIE 2017-04-19 10:11:12 this is how you tell it's PIE 2017-04-19 10:11:14 :p 2017-04-19 10:11:15 ah 2017-04-19 10:11:18 thanks 2017-04-19 10:11:22 yes, you are right ofc 2017-04-19 10:11:56 pie or not, I don't like when ldd or readelf or whatever says "dynamically linked" when run on a static binary :( 2017-04-19 10:12:55 it makes me go "shit, what did I do wrong, what build system braindeadness did I fail to work around this time?" 2017-04-19 10:13:21 well 2017-04-19 10:13:24 you can blame ELF for that 2017-04-19 10:13:34 static PIE binaries ARE ELF shared objects 2017-04-19 10:13:36 :P 2017-04-19 10:13:46 ugh 2017-04-19 10:13:54 WHY 2017-04-19 10:14:57 because only shared objects are reloctable, or something 2017-04-19 10:14:58 and can I blame the tools for not specialcasing it and printing a line "it's static pie, don't worry, you're gonna be okay" ? 2017-04-19 10:15:02 it's some brokenness that nobody ever fixed 2017-04-19 10:16:09 skarnet, because you are old and know ppl ;-) 2017-04-19 10:16:39 do I know people? 2017-04-19 10:16:42 I know you guys 2017-04-19 10:16:50 that's about it :P 2017-04-19 10:17:32 right, they are the most important anyways :p 2017-04-19 10:18:03 I also know academics who'd be the type to host Haskell or TeX, OpenBSD people who stop listening when I say "Linux", and slash fanfiction writers 2017-04-19 10:18:23 I don't think any of those would be useful to you 2017-04-19 10:20:32 what about crack fanfiction writers 2017-04-19 10:20:44 she does that too 2017-04-19 14:18:18 skarnet: I’m quite glad that I’m not the only one who was surprised that static PIE is not reported as static by ldd :) I thought that it was just my lack of knowledge; but what problem do you see on that? I’ve already verified that it really works on system with different libc and even older kernel 2017-04-19 14:19:05 skarnet: now I just use `readelf -dl` instead of ldd as Shiz showed me 2017-04-19 14:20:59 ncopa, is it new that when arch is disabled you get an all failed error with abuild? 2017-04-19 14:22:00 possibly 2017-04-19 14:22:06 i think its due to the set -e change 2017-04-19 14:22:15 i dont remmeber if it exited with success earlier 2017-04-19 14:22:19 it probably did 2017-04-19 14:22:26 clandmeter: i think its a bug 2017-04-19 14:26:28 <^7heo> ncopa: so you never patched anything particular to build firefox as PIE? 2017-04-19 14:26:58 i dont think so 2017-04-19 14:27:13 i remember there were some patches to make it work un der PAX 2017-04-19 14:27:18 that i actually tried 2017-04-19 14:27:38 but we removed those 2017-04-19 14:27:54 and disabled the pax memory protection instead 2017-04-19 14:28:56 <^7heo> ncopa: not "un der PaX" but "uhr der PaX" 2017-04-19 14:29:19 ^7heo: lol 2017-04-19 14:29:34 he 2017-04-19 14:29:38 he 2017-04-19 14:29:41 he 2017-04-19 14:29:44 :) 2017-04-19 14:30:14 ^7heo: Wir sind nicht in Deutschland! 2017-04-19 14:31:57 <^7heo> jirutka: oh du sprichst Deutsch? 2017-04-19 14:32:23 <^7heo> Du* 2017-04-19 14:33:11 eins zwei polizei 2017-04-19 14:33:39 clandmeter: XD 2017-04-19 14:33:46 ^7heo: Nein, aber ich benutze Google Translator. ;) 2017-04-19 14:34:30 <^7heo> drei vier grenadier 2017-04-19 14:34:39 <^7heo> jirutka: bwwaah 2017-04-19 14:34:57 <^7heo> Ich benutze 3g mann 2017-04-19 14:35:59 ^7heo: we are waiting for you on -offtopic : > 2017-04-19 15:47:11 jirutka: i have problem with nginx :-/ 2017-04-19 15:47:30 ncopa: don’t worry, I’ll update it and fix today 2017-04-19 15:47:43 1.10.3 does not build with libressl 2017-04-19 15:47:54 and 1.12.0 has modules that does not build 2017-04-19 15:47:55 ok 2017-04-19 15:49:17 i set arch="" in testing/wok meanwhile 2017-04-19 15:49:24 thanks! 2017-04-19 15:50:03 testing/wok? o.O 2017-04-19 15:50:41 depends on nginx 2017-04-19 15:51:08 which cannot be installed now due to missing libcrypto.old 2017-04-19 15:52:04 Hmmmm... i thought there was a wireguard port for alpine already in some official repos, but that's not the case? Or am I unable to use pkgs.alpinelinux.org ;-) 2017-04-19 15:52:27 i think its in testing? 2017-04-19 15:52:32 edge/testing 2017-04-19 15:52:42 we should probably move it before v3.6 2017-04-19 15:53:13 ah got it, thanks! 2017-04-19 15:53:23 ncopa: is ipv6.patch in nginx still needed? there’s no comment why it was added and what problem does it solve 2017-04-19 16:06:13 dunno 2017-04-19 16:06:31 commit message says it was needed to listen on ipv6 by default 2017-04-19 16:07:15 kill it 2017-04-19 16:07:28 if its needed then it should go upstream 2017-04-19 16:07:30 I’ve read that, but was it really needed? if you want nginx to listen on IPv6, you specify listen [::]:443 (for example) 2017-04-19 16:07:46 yeah 2017-04-19 16:07:47 kill it 2017-04-19 16:07:51 I really hate when someone put a patch without any proper description why the heck it’s needed and what it actually do 2017-04-19 16:09:14 btw these guys from IBM have very good documentation habits, they always thoroughly explain what and why the commits changes :) 2017-04-19 16:10:24 jirutka: :) 2017-04-19 16:27:47 “The libressl library is not officially meant to be used by 3rd-party applications as a standalone SSL library anyway.” o.O https://github.com/openresty/lua-nginx-module/issues/1035#issuecomment-292275955 2017-04-19 16:49:10 it's written on the internet, so it must be true 2017-04-19 16:50:18 skarnet: I’ve put it here, so someone more informed about LibreSSL can respond to it, if it’s not true ;) 2017-04-19 16:50:44 <^7heo> I wouldn't assume it to be true. 2017-04-19 16:52:07 well that statement makes zero sense, and that's being generous 2017-04-19 16:52:31 skarnet: could you please respond to the linked issue? 2017-04-19 16:52:41 no I can't, the thread has been closed 2017-04-19 16:53:12 and correcting every wrong sentence on the Internet is not one of my life's goals 2017-04-19 16:53:32 closed, but not locked 2017-04-19 16:54:42 <^7heo> skarnet: whyyyy!? Aren't you aware of https://www.xkcd.com/386/ ? 2017-04-19 16:54:45 rdutra. did you write the libbsd patch? 2017-04-19 16:55:04 clandmeter: yes 2017-04-19 16:55:40 i think you can invert the ifdef to x86 and x86_64 2017-04-19 16:55:54 then all archs will probably work 2017-04-19 16:56:22 ^7heo: I'm very aware of it and I've spent too much time doing it already 2017-04-19 16:57:23 clandmeter: I see. Well, I can do it soon and send a PR 2017-04-19 16:57:50 <^7heo> skarnet: it was a rethorical question ;) Ofc you're aware of it :D 2017-04-19 17:00:21 rdutra, i think i succesfully build it on arm32/64 so please enbable them. 2017-04-19 17:00:38 not behind my pc now 2017-04-19 17:07:56 RFC - Manifest format: Currently, I'm using the following format for entries in manifest files '%s:%s/%s-%s\t%s:%s\t%s' . 2017-04-19 17:09:27 Symlinks are handled by sumtype 'linkto' and the sum being the link target. Devices are not yet handled, nor are ownership/permissions. 2017-04-19 17:11:07 Ideally, such manifests would be either distributed with packages or calculated by apk at installation time, rather than being computed after the fact of extraction. 2017-04-19 17:13:23 I'm looking for any input regarding the format and content for manifests of both package specific and arbitrary file sets. 2017-04-19 17:36:58 ncopa: I’m afraid that we have more issues with nginx vs. new LibreSSL… I’ve run nginx testsuite and many TLS-related tests fails, both on the current version and 1.12.0 2017-04-19 17:37:53 ncopa: the same tests passes on v3.5 against main/nginx@edge 2017-04-19 17:38:36 ncopa: http://tpaste.us/Ynw6 2017-04-19 18:36:45 jirutka : did you check on main/llvm recently ? it fails on x86_64, s390x with this bug : https://git.alpinelinux.org/cgit/aports/tree/testing/llvm4/disable-FileSystemTest.CreateDir-perms-assert.patch 2017-04-19 18:36:55 I mean, the same bug with that patch 2017-04-19 18:37:37 besides, even with that patch, still fail with building doc subpackage 2017-04-19 18:38:35 tmh1999: probably, but don’t remember any failure; btw https://github.com/alpinelinux/aports/pull/1261 2017-04-19 18:39:32 jirutka : beautiful. Guess we I just wait for it. 2017-04-19 18:39:38 thank you 2017-04-19 18:40:42 tmh1999: it’d be better to help with it ;) 2017-04-19 18:41:22 jirutka : oh sure 2017-04-19 18:59:58 ncopa: it’s very bad, nginx with LibreSSL 2.5 accepts connections that should be rejected due to invalid cert… or it’s a bug in some Perl TLS library (tests for nginx are written in Perl), but I’ve already checked them and it’s not likely… 2017-04-19 19:07:37 could please someone else try to build and check http://tpaste.us/oZNL on latest edge? 2017-04-19 19:13:48 <_ikke_> jirutka: I'll try 2017-04-19 19:15:49 huh 2017-04-19 19:15:55 that sounds bad 2017-04-19 19:19:47 <_ikke_> jirutka: I get unsatisfiable constraints 2017-04-19 19:19:55 _ikke_: log pls? 2017-04-19 19:20:57 <_ikke_> jirutka: http://tpaste.us/je0V 2017-04-19 19:21:05 apk update… 2017-04-19 19:21:41 <_ikke_> I just did that 2017-04-19 19:21:48 arch? 2017-04-19 19:21:50 <_ikke_> apk upgrade -U --available 2017-04-19 19:22:01 use nl.alpinelinux.org 2017-04-19 19:22:08 <_ikke_> ok 2017-04-19 19:22:16 <_ikke_> jirutka: 64 bit 2017-04-19 19:22:23 <_ikke_> x86_64 2017-04-19 19:22:39 then you use some mirror that is out-of-sync 2017-04-19 19:22:54 <_ikke_> dl-cdn 2017-04-19 19:23:13 dl-cdn is like a Russian roulette :/ 2017-04-19 19:23:17 <_ikke_> hehe 2017-04-19 19:23:18 perl-protocol-websocket (missing): 2017-04-19 19:23:27 <_ikke_> Now it's continuing 2017-04-19 19:23:31 use nl.alpinelinux.org or https://repository.fit.cvut.cz/mirrors/alpine/ 2017-04-19 19:23:43 these are surely up-to-date 2017-04-19 19:24:01 i though i had that 2017-04-19 19:24:04 rsync.a.o 2017-04-19 19:24:22 yeah, or the source, rsync.a.o, but someone told me that I should not propagate it :P 2017-04-19 19:24:36 <_ikke_> jirutka: Yeah, switched to nl.a.o 2017-04-19 19:24:44 <_ikke_> building now 2017-04-19 19:24:52 we should really solve this issue with mirrors, many mirrors on the list are not reliable 2017-04-19 19:26:14 i suppose i could have built perl-protocol-websockets locally 2017-04-19 19:27:44 i wonder if that error happens with libressl2.4? 2017-04-19 19:27:54 ./h2_ssl_verify_client.t ............... Dubious, test returned 1 (wstat 256, 0x100) 2017-04-19 19:27:54 Failed 1/5 subtests 2017-04-19 19:28:58 ncopa: why? it’s already in repo, at least for x86_64 and x86, b/c other builders are stuck again or something 2017-04-19 19:29:19 ncopa: I’ve tried to that test suite on v3.5 and all tests passes 2017-04-19 19:29:25 ok 2017-04-19 19:29:27 tried to run 2017-04-19 19:29:31 that answers the question 2017-04-19 19:30:06 i suppose we have to ask libressl and nginx 2017-04-19 19:30:07 I have no clue what’s wrong, but this kind of error really terrifies me… 2017-04-19 19:30:11 yes 2017-04-19 19:30:13 yes 2017-04-19 19:30:50 if TLS would not work at all, segfault or whatever, ok, but it silently accepts connections that should not be accepted, just after update of ssl lib? this is really bad 2017-04-19 19:31:01 yup 2017-04-19 19:41:44 Can someone explain me how the docs magic work? I cannot find any pre/post hooks in the package 2017-04-19 19:42:01 No mentions in apk-tools code 2017-04-19 19:42:24 consus : abuild code ? 2017-04-19 19:42:49 consus: what do you mean, `apk add docs`? 2017-04-19 19:42:53 aha 2017-04-19 19:43:04 And then all my *-doc are pulled in 2017-04-19 19:43:05 How? 2017-04-19 19:43:31 consus : https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1525 ? 2017-04-19 19:44:10 no, this line https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1476 2017-04-19 19:44:13 Oh 2017-04-19 19:44:25 So that's how it works 2017-04-19 19:44:31 A hook in abuild 2017-04-19 19:44:35 yeah, no magic here ;) 2017-04-19 19:45:06 I was expecting to find this kind of code in apk itself 2017-04-19 19:45:55 Thanks 2017-04-19 20:13:59 ncopa: Do you have a second RE: naming conventions and manifest format? 2017-04-19 22:06:15 jirutka: responded to some stuff 2017-04-19 22:07:17 jirutka │ I really hate when someone put a patch without any proper description why the heck it’s needed and what it actually do 2017-04-19 22:07:18 hehehehe 2017-04-19 22:07:41 Shiz: heh, but this message was not addressed to you, really :) 2017-04-19 22:11:00 i'll add descriptions now 2017-04-19 22:11:26 thanks :) 2017-04-19 23:15:30 jirutka: still awake? :P 2017-04-19 23:41:17 Shiz: yes 2017-04-19 23:45:00 writing descriptions now actually 2017-04-19 23:53:46 jirutka: pushed 2017-04-19 23:54:35 jirutka: also what was the edit you made to the PR? 2017-04-20 00:06:21 i didn’t made any edit 2017-04-20 00:06:27 or what do you mean? 2017-04-20 00:09:12 gn 2017-04-20 00:10:38 jirutka: the PR said 'edited by jirutka' in the first post 2017-04-20 00:10:40 so not sure 2017-04-20 00:13:10 hm, that’s probably caused by Octoroid (Android client for GitHub) 2017-04-20 00:13:53 ah 2017-04-20 00:13:56 I’ve updated labels, but Octodroid has single form for updating anything in issue… 2017-04-20 00:15:07 that kinda sucks :/ I should probably finally switch GH client, Octodroid is abandoned :/ 2017-04-20 00:15:25 kay, but now really gn :) 2017-04-20 00:16:59 nite \o 2017-04-20 08:50:20 fabled : Hi, are we abandoning patchwork.a.o and moving to github pr, or everyone's too busy this time ? 2017-04-20 08:51:48 oh, it's this suggestion again! Hello my old friend, it's been a long time! 2017-04-20 09:04:51 XD 2017-04-20 09:42:14 skarnet : I'm sorry ? :D 2017-04-20 13:07:07 tmh1999: that would be great, but unfortunately it’s more the further option… anyway, you have greater chance to get your patches merged soon via GH 2017-04-20 13:10:53 <^7heo> skarnet: I don't get why you're so uptight about github; forking is caring, isn't it? :D 2017-04-20 13:11:07 <^7heo> ACTION runs to hide behing the biggest rock he can find 2017-04-20 13:11:31 ^7heo: please don’t provoke him ;) 2017-04-20 13:11:59 <^7heo> jirutka: it's a friendly provocation; implicitely agreeing with his point; can't you see? 2017-04-20 13:12:34 <^7heo> jirutka: use sarcasm on it; it's very effective. 2017-04-20 13:50:58 kaniini: libuv test suite fails in fakeroot 2017-04-20 13:51:01 due to setuid 2017-04-20 13:51:24 i wonder if we should have an option to make the test run as non-fakeroot? 2017-04-20 13:51:53 ncopa: definitely not 2017-04-20 13:51:57 or always run the tests as non-fakeroot and have an option to run them as fakeroot for those who needs it 2017-04-20 13:52:06 ncopa: it used to run as non-fakeroot, fabled fixed it after my report 2017-04-20 13:52:37 are there many that requires to run as root/fakeroot? 2017-04-20 13:53:12 im thinking: options="check-fakeroot" 2017-04-20 13:53:34 or: options="check-as-normal-user" 2017-04-20 13:53:50 alternatively i just disable the tests that fails 2017-04-20 13:54:01 dunno, but running check without any isolation is not a good idea 2017-04-20 13:54:38 is running check worse than running build? 2017-04-20 13:54:40 the problem is that some tests may do bad things 2017-04-20 13:54:49 no 2017-04-20 13:54:56 but build runs in fakeroot, doesn’t it? 2017-04-20 13:55:01 no 2017-04-20 13:55:05 huh o.O 2017-04-20 13:55:06 only make install 2017-04-20 14:02:11 I’m trying to find where I wrote the issue with check after that fabled changed it to run in fakeroot, but cannot find it :( 2017-04-20 14:03:53 but tbh I’m really surprised now that build does not run in fakeroot, I thought that everything run in fakeroot, except check (before it was changed) 2017-04-20 14:06:51 building as normal user and not in fakeroot was done very early 2017-04-20 14:07:03 and that was the reason that package() got its own function 2017-04-20 14:07:21 because fakeroot woudl kill the parallelism of make -j 2017-04-20 14:07:38 IIRC the problem I had was that script was able to created some files in /, so it run with root privileges or used sudo or something 2017-04-20 14:07:49 (script run in check) 2017-04-20 14:08:03 running sudu could make damage yes 2017-04-20 14:08:07 sudo* 2017-04-20 14:08:26 I wrote that to fabled and he come with idea to run check in fakeroot 2017-04-20 14:08:34 yeah 2017-04-20 14:08:39 its probably good to do so 2017-04-20 14:08:49 I thought that, but not sure now 2017-04-20 14:09:08 i disabled the tests in libuv 2017-04-20 14:09:20 the setuid/setgid tests 2017-04-20 14:09:58 Hi 2017-04-20 14:10:01 btw I’d like to propose the following change: run check _after_ package; to be sure that badly written `make check` will not rebuild binaries with different parameters 2017-04-20 14:10:20 might be good idea yes 2017-04-20 14:10:40 hum 2017-04-20 14:10:43 might not work 2017-04-20 14:10:45 Would anyone know how if there is any package providing kernel sources for alpine ? 2017-04-20 14:10:53 well should work 2017-04-20 14:11:00 i was thinking that we split the pkgs 2017-04-20 14:11:03 but that does not matter 2017-04-20 14:11:07 serge: not that i know of 2017-04-20 14:11:13 serge: no 2017-04-20 14:11:25 ok 2017-04-20 14:11:27 Next question then 2017-04-20 14:11:44 If I want to add scup kernel module to alpine, how am I supposed to do then ? 2017-04-20 14:11:50 sctp* 2017-04-20 14:12:09 clone aports, setup build env 2017-04-20 14:12:21 change the kernel config to what you want, build with abuild and install 2017-04-20 14:12:23 :P 2017-04-20 14:12:50 https://wiki.alpinelinux.org/wiki/Setup_your_system_and_account_for_building_packages 2017-04-20 14:13:25 looks like we already build sctp as module? 2017-04-20 14:13:45 $ grep SCTP * | tpaste 2017-04-20 14:13:45 http://tpaste.us/pQxk 2017-04-20 14:13:46 yeah looks like it 2017-04-20 14:13:49 just modprobe sctp 2017-04-20 14:13:53 or add to /etc/modules 2017-04-20 14:14:56 Well.. that must come from the specific version I use then :/ 2017-04-20 14:15:04 "Linux moby 4.9.13-moby #1 SMP Sat Mar 25 02:48:44 UTC 2017 x86_64 Linux" 2017-04-20 14:15:15 ha! 2017-04-20 14:15:37 I'm in the hyperkit vm used by docker (for Mac) 2017-04-20 14:15:41 that doesn't look like an alpine kernel 2017-04-20 14:15:43 thats not alpine kernel 2017-04-20 14:15:43 :P 2017-04-20 14:16:01 well... any clues to help me ? :/ 2017-04-20 14:16:16 i think they opensourced moby recently? 2017-04-20 14:16:27 or was renamed to linuxkit 2017-04-20 14:17:02 moby is part of linuxkit 2017-04-20 14:17:04 afaik 2017-04-20 14:17:21 https://github.com/linuxkit/linuxkit/tree/master/src/cmd/moby 2017-04-20 14:17:43 # CONFIG_IP_SCTP is not set 2017-04-20 14:17:43 https://github.com/linuxkit/linuxkit 2017-04-20 14:17:48 (from: https://github.com/linuxkit/linuxkit/blob/master/kernel/kernel_config ) 2017-04-20 14:17:48 yes 2017-04-20 14:17:53 there is where you build it 2017-04-20 14:18:00 clone that and build the kernel there 2017-04-20 14:18:18 this kernel config is quite a mess... 2017-04-20 14:18:25 it enables iptables tracking for SCTP but not SCTP itself 2017-04-20 14:18:27 :P 2017-04-20 14:18:39 Thanks Shiz :D 2017-04-20 14:19:03 i suppose you could make PR to linuxkit 2017-04-20 14:19:59 ncopa: unrelatedly: apparently alpine is the only linux distro supported by openbsd's new vm mechanism :P 2017-04-20 14:20:30 thats cool :) 2017-04-20 14:24:32 <^7heo> Did docker move to moby because of the bad connotation with the docker name? 2017-04-20 14:24:39 <^7heo> much like ie -> edge? 2017-04-20 14:24:47 Hi! What version of GCC will ship with Alpine 3.6? As per https://gcc.gnu.org/ml/gcc/2017-04/msg00080.html, GCC 7.1 will be out by the end of the month. 2017-04-20 14:24:50 moby doesnt replace anything about docker 2017-04-20 14:25:01 <^7heo> Shiz: it does replace the docker name tho. 2017-04-20 14:25:07 not really? 2017-04-20 14:25:16 <^7heo> Shiz: https://github.com/docker/docker 2017-04-20 14:25:19 <^7heo> Shiz: please check. 2017-04-20 14:25:41 bleh 2017-04-20 14:25:45 news that came out two days ago is cheating! 2017-04-20 14:25:47 <^7heo> Bleh yourself. 2017-04-20 14:25:51 <^7heo> :D 2017-04-20 14:26:20 they have dockercon now 2017-04-20 14:26:52 and i know they were announcing this new stuff 2017-04-20 14:27:21 hmm 2017-04-20 14:27:27 3.6 is due to release late may, right? 2017-04-20 14:27:40 im a bit wary about a month's time to switch to a new version of the base system compiler 2017-04-20 14:27:44 considering regressions 2017-04-20 14:28:07 pbr: also, did they just skip gcc 7.0? 2017-04-20 14:28:10 i know, it's pretty close.. 2017-04-20 14:28:21 early may 2017-04-20 14:28:32 we will not upgrade kernel for v3.6 2017-04-20 14:28:43 as per the new naming scheme 7.0, 8.0 etc are the pre-release versions. the first stable, actual release is N.1 2017-04-20 14:28:53 there was no 6.0 either 2017-04-20 14:28:55 lol 2017-04-20 14:29:02 Shiz, they do it since 6.1, because .1 seems more stable for some 2017-04-20 14:29:18 because it was, mostly 2017-04-20 14:29:23 im have been setting up the builders for 3.6 today 2017-04-20 14:29:25 x.0 releases of gcc were notoriously buggy 2017-04-20 14:29:27 :P 2017-04-20 14:29:39 ncopa: i hope we can fix the opensmtpd issues before release then... 2017-04-20 14:29:51 yes 2017-04-20 14:30:05 once the builders are up we should focus on fixing things 2017-04-20 14:30:05 alright, so alpine 3.6 will come with gcc 6.3? 2017-04-20 14:30:11 and not introduce new stuff 2017-04-20 14:30:14 and new breakages 2017-04-20 14:30:20 pbr yes 2017-04-20 14:30:22 gcc 6.3 2017-04-20 14:30:34 cool, thanks! 2017-04-20 14:31:54 ncopa: have you reported that bug in nginx/libressl, or should I do it? 2017-04-20 14:32:16 speaking of getting things in before the builders 2017-04-20 14:32:26 jirutka i havent 2017-04-20 14:32:27 ACTION chases jirutka for the Rust PR 2017-04-20 14:32:29 please do 2017-04-20 14:32:29 :p 2017-04-20 14:32:49 Shiz: I know, I know, at evening, I’m at work now 2017-04-20 14:32:55 :) 2017-04-20 14:33:11 Shiz: maybe you can report that bug with nginx/libressl meanwhile, instead of me? :) 2017-04-20 14:33:18 do you have a reference? 2017-04-20 14:33:21 im not sure what its about so 2017-04-20 14:34:07 since no one replied last time, I ask again: shouldn't pkgs, which depend on ncurses-terminfo, rather depend ncurses-terminfo-base since it's much smaller? 2017-04-20 14:35:04 theyren ot identical though 2017-04-20 14:35:20 -base is the stuff in /etc, normal terminfo is the stuff in /usr/share 2017-04-20 14:35:49 yes, but ncurses searches for both as indicated in APKBUILD 2017-04-20 14:37:25 it's just that ncurses-terminfo is really big and contains terminfo data nearly no one would use in these days 2017-04-20 15:11:15 jirutka actually i fixed it 2017-04-20 15:11:19 :p 2017-04-20 15:11:27 kaniini: what? 2017-04-20 15:11:58 jirutka: https://git.alpinelinux.org/cgit/abuild/commit/?id=1ddc910eb328b4534234bd2f97e631a075241abd 2017-04-20 15:12:39 kaniini: I know about this 2017-04-20 15:13:13 kaniini: the problem is that ncopa has some test that doesn’t work in fakeroot b/c it uses setuid 2017-04-20 15:13:45 oh well 2017-04-20 15:14:02 sounds like a defective test to me 2017-04-20 15:14:33 unless it specifically is testing some behaviour under serious 2017-04-20 15:14:34 err 2017-04-20 15:14:45 setuid 2017-04-20 15:15:42 agree with you 2017-04-20 15:16:58 i disabled the tests involving setuid setgid 2017-04-20 15:43:05 Thanks again 2017-04-20 15:43:30 I just did the PR and solved my fuck** issue with scup support over containers \o/ 2017-04-20 17:23:57 Shiz: what does `fully_static` mean? static without PIE? 2017-04-20 19:37:28 im starting up the 3.6 builders 2017-04-20 19:39:40 \o/ 2017-04-20 19:43:55 3.6 builders are up 2017-04-20 19:43:59 except ppc64le 2017-04-20 19:44:03 will do that tm 2017-04-20 19:44:32 i suspect the new ppc64le machine will easily catch up :) 2017-04-20 19:53:55 what, already?! 2017-04-20 19:54:10 we haven’t pushed rust and ghc into community yet 2017-04-20 19:54:18 and I’d like to improve few things in abuild 2017-04-20 20:33:55 ooh ooh idris too! lets get 3 languages into community >.< 2017-04-20 20:34:01 i think i got all the comments fixed 2017-04-20 20:34:29 idris being my new favorite "beat my head against the wall" thing to learn 2017-04-20 21:05:52 Question: Does 'apk --print-arch' always give the arch of the host, even when a different root has a different arch in use? 2017-04-20 21:07:25 If so, would it make sense to rename it to '--host-arch' and make '--print-arch' return the arch of the current apk root? 2017-04-20 21:09:58 TemptorSent : I think if it is apk.static, then it will print the arch of that apk 2017-04-20 21:10:20 if it is no static, then the arch it is running in. 2017-04-20 21:12:48 TemptorSent : https://git.alpinelinux.org/cgit/apk-tools/tree/src/apk.c#n52 2017-04-20 21:20:55 tmh1999: Thanks. Talk about confusing behavior! 2017-04-20 21:23:56 jirutka: just fully static :P 2017-04-20 21:24:31 Shiz: how that different from crt-static? 2017-04-20 21:24:45 in crt-static only the c runtime is static 2017-04-20 21:24:49 instead of every library 2017-04-20 21:43:20 how do you make the crt static when other libraries are dynamic ?... 2017-04-20 21:43:39 how do those libraries resolve their deps to the crt ? 2017-04-20 21:44:17 if A depends on B, I can see both A and B being static, both being dynamic, and A being static while B is dynamic, but certainly not the reverse 2017-04-20 21:58:17 skarnet: on unix, you can't 2017-04-20 21:58:28 that's why in our patches, crt_static implies fully_static for unices 2017-04-20 21:58:30 on windows, you can 2017-04-20 21:58:37 since dlls can carry their own C runtime 2017-04-20 21:59:01 and people wonder why Windows is so heavy 2017-04-20 21:59:10 can does not mean "they all do" 2017-04-20 21:59:20 I very much hope they don't 2017-04-20 21:59:47 and that basically mean no state in the crt 2017-04-20 21:59:52 how do they even pull it off 2017-04-20 21:59:56 means* 2017-04-20 22:00:00 it doesn't 2017-04-20 22:00:04 what makes you think that 2017-04-20 22:00:05 :p 2017-04-20 22:00:16 if you have several copies of the crt... 2017-04-20 22:00:21 yes? 2017-04-20 22:00:28 state is gonna desync fast 2017-04-20 22:00:46 thats why you dont share CRT stuff of different versions between DLLs 2017-04-20 22:00:48 like FILE*s 2017-04-20 22:32:38 Shiz: so this logic was basically totally broken whole time, in Rust build system? o.O 2017-04-20 22:33:47 you sound surprised 2017-04-20 22:33:57 to be honest, I am 2017-04-20 22:38:02 I thought that it was just buggy 2017-04-20 22:41:08 Shiz: please restore my trust in Rust developers… 2017-04-20 22:52:20 jirutka: their static linking logic was kinda flaky at best, yes 2017-04-20 22:52:46 (was traveling) 2017-04-20 22:54:29 jirutka: is the missing patch desc all that is needed? 2017-04-20 22:54:42 Shiz: yes 2017-04-20 22:54:49 time for another rebase 2017-04-20 22:54:51 :P 2017-04-20 22:54:53 :) 2017-04-20 22:54:55 gimme... 5 mins 2017-04-20 23:05:30 jirutka: done 2017-04-21 00:24:59 kaniini: are you here? 2017-04-21 00:30:31 jirutka: yes and no 2017-04-21 00:30:57 kaniini: huh, like Schrödinger’s cat? :P 2017-04-21 00:31:19 jirutka: if you need a rebuild or such i can set it up in about 2 hours, presently driving (stopped to take a break) 2017-04-21 00:31:59 kaniini: nn, just wanna ask, is it possible to use clang with different version of llvm? like clang 4.0 and llvm 3.9 2017-04-21 00:32:16 kaniini: cause currently we have just one clang pkg… 2017-04-21 00:34:35 from what i've seen from llvm ir and stuff like ghc, i'd be surprised if that worked :) 2017-04-21 00:35:03 it was interesting seeing how much ir can change incompatibly in one version 2017-04-21 00:36:22 also no rush on it but curious if the changes i made for idris make it ok...ish https://github.com/alpinelinux/aports/pull/684 2017-04-21 00:37:36 jirutka: id very much doubt it 2017-04-21 00:39:47 Okay, is there anything other than the skel passwd/group/fstab and initramfs-init that come from anywhere other than directly from apks needed in the userland of the initfs? 2017-04-21 00:45:13 jirutka i don't think so 2017-04-21 01:11:31 kaniini: about rebuild, could you please build and verify clang 4 on armhf and aarch64 then? https://github.com/alpinelinux/aports/pull/1261 2017-04-21 01:25:03 kaniini: also please take a look at https://github.com/alpinelinux/aports/pull/1273 :) 2017-04-21 02:26:36 uh.. building cross compiling tools is broken on edge. for having such a nice distribution for embedded devices, you're making it sometimes really painful to work with. :( 2017-04-21 02:28:33 in abuild, after fakeroot was set, including functions.sh results in termination. more specifically after CBUILDROOT (functions.sh:123) was set 2017-04-21 02:30:16 xentec: I'm not currently messing with abuild, but I have a pretty good solution for fakeroot included in my work on mkimage/mkinitfs/etc. 2017-04-21 02:32:27 xentec - take a look at utils/utils-fkrt.sh under https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage/ 2017-04-21 02:32:59 You can source it and use it from your interactive shell if you need to even! 2017-04-21 02:35:13 jirutka: Nearly ready to split, need to confirm everything has an appropriate home and finalize filenames. 2017-04-21 02:35:58 thanks, but thats overkill in this case. functions.sh:123 fails, because it is the last instruction in readconfig() and the condition check triggers set -e to terminate 2017-04-21 02:36:23 I could *REALLY* use some additional eyeballs on the code and some testing of the various base functionality before we go live with it. 2017-04-21 02:36:37 xentec: Ahh, a victim of the great 'set -e' :) 2017-04-21 02:37:20 appending a simple || true fixes it 2017-04-21 02:37:48 Yeah, those are easy ones :) 2017-04-21 02:38:14 The messy ones are where you have multiple fakeroot invocations, which usually breaks horribly. 2017-04-21 02:40:01 considering "additional eyeballs" I'd be already happy if binutils and gcc would be tested for cross compilation 2017-04-21 02:40:08 The other outstanding question is how do we want to handle non-apk sourced files to be included in the initfs. 2017-04-21 02:40:56 xentec: Yeah, I've run into a few gotchas on cross-building that I'm trying to get fixed in apk. 2017-04-21 02:40:57 apkovl? 2017-04-21 02:41:41 No... I'm working on replacements for mkinitfs and update-kernel. 2017-04-21 02:42:34 So artifacts to be built into an initfs (userland) which don't come directly from apks. 2017-04-21 02:42:40 I know. If by "non-apk" you mean configs in /etc or some other files, you could use the apkovl format 2017-04-21 02:42:55 Thus far, the only ones I'm aware of are the contents of /usr/share/mkinitfs 2017-04-21 02:43:26 Nope, it doesn't work that way -- the initfs is a set of gziped cpio archives. 2017-04-21 02:43:47 The apkovl gets extracted by the initscript which is included in the initfs. 2017-04-21 02:45:05 xentec: whoops 2017-04-21 02:45:07 lol 2017-04-21 02:45:16 I have lots of tools for building apkovls too though :) 2017-04-21 02:45:43 Isn't lbu not good enough? ;) 2017-04-21 02:46:17 xentec: Not really great for automation purposes. 2017-04-21 02:46:59 mkimage can build overlays with baked-in ssh keys, preloaed data, etc. 2017-04-21 02:47:59 xentec: So you can build one-off images with the exact config required for each one with a few lines. 2017-04-21 02:49:14 And I just got through making it downright easy to build custom modloops, initfs module subsets, and initfs userspace file subsets. 2017-04-21 02:51:30 Shiz: Any thoughts on handling non-apk managed files in mkinitfs? Directory structure in /usr/share/mkalpine/initfs perhaps? 2017-04-21 02:51:42 none 2017-04-21 02:52:10 Hmm... where's fabled or ncopa when you need them? :P 2017-04-21 02:55:54 xentec: What systems are you building for? 2017-04-21 02:55:59 armhf 2017-04-21 02:56:12 https://github.com/alpinelinux/abuild/pull/16 kaniini or fabled: would you take a look? 2017-04-21 02:56:12 Bootloader? 2017-04-21 02:56:24 more specifally rpi3 2017-04-21 02:57:13 Ahh, gotcha - yeah, have that theoretically suppored in mkimage already, and have plans for a few specific projects based on the rpi3. 2017-04-21 02:57:42 Are you using any of the GPU accelerated code? 2017-04-21 02:58:57 not really, it's more for work using rpi3 as a base for our IoT project 2017-04-21 02:59:25 well rpi3 and alpine :) 2017-04-21 02:59:42 *shakes head* the IoT is taking over the world, mostly in a bad way :( 2017-04-21 03:00:04 I know, that's why I'm working extra hard not to fuck it up 2017-04-21 03:00:20 I really don't need my vodka bottles running wifi hotspots, thank you! 2017-04-21 03:00:28 (Yes, seriously) 2017-04-21 03:28:24 TemptorSent: I've looked over your mkimage overhaul. Imo it looks like overkill but I look forward to use it :D 2017-04-21 03:32:07 Oops, I need to set my flags to keep track of which channel again. Haven't taken the time to configure bx the way I like it and can't find my old config. 2017-04-21 03:32:46 xentec: Which part was looking overkill to you? 2017-04-21 03:33:43 everything. Or maybe I'm just underestimating the complexity of such an endeavor 2017-04-21 03:36:04 xentec: It handles everything required to build images, including the mkinitfs tool, the update-kernel tool, a kernel staging tool, an apkroot staging tool, support for configuring and setting up various bootloaders, building the output images, and building apkoverlays. 2017-04-21 03:37:21 Since it requires the functionality of system tools to work, and the existing tools (mkinitfs, update-kernel) were broken, this is replacing the mkinitfs package as well as the old mkimage package and moving to a top level repo 'mkalpine' 2017-04-21 03:38:52 Did you also rewrote initramfs-init? 2017-04-21 03:39:07 s/Did/Have/ 2017-04-21 03:39:47 It also contains a replacement 'fkrt' wrapper for faked instead of the fakeroot tool, a number of basic utilities for scripts, and a lot more sanity checking :) 2017-04-21 03:40:16 Yes, although that is pending and not likely to be in 3.6.0 2017-04-21 03:41:46 I can support reasonably secure boot (if you can secure your kernel) and verification of integrity in the initfs, although the existing apk implementation needs fixing to work well. 2017-04-21 03:43:22 A couple of packaging changes would be very helpful, as probably 30%+ of the code in there is working around apk bugs or deficiencies. 2017-04-21 03:44:53 Manifests, indexes, and deptrees by checksum are the most important, as right now it can take entirely too long to build the manifest and deptree for the kernel modules. 2017-04-21 03:45:36 It would be awesome, if you could establish some central shell framework for abuild/alpine-sdk and alpine-conf. 2017-04-21 03:45:40 And extracting pax headers from the raw tarstream from uncompressing the .apk for the sha1sums using awk is painful. 2017-04-21 03:45:54 Yeah, that's what I'm working towards. 2017-04-21 03:47:19 The utils could use some cleaning up still, but they are very useful for common tasks ( mkdir_is_writable being one I use all the time to do both the mkdir -p and the test for dir rwx) 2017-04-21 03:50:02 The list utils are currently slow, but quite useful. Some optimizaion is needed there, as well as support for unsorted lists and ordered lists in addition to the current sorted lists. I also plan a general stack utility and a fifo utility, but I'll get to those as needed. 2017-04-21 03:52:39 apkroottool supports building an apkroot for an arbitrary arch, setting up it's repo/keys, and running arbitrary apk commands or general commands in that root, all under fkrt with stored state. 2017-04-21 03:53:42 Then dumping a subset (with all deps) based on a set of globs directly to a cpio archive (optionally compressed). 2017-04-21 03:54:17 with various compression formats? 2017-04-21 03:54:46 And mkinitfs now has modular configuration files (which will be gaining further functionality soon), so you can include various features sanely. 2017-04-21 03:55:24 Currently gzip -9 is implemented there, but I have the logic for doing everything the kernel supports already done :) 2017-04-21 03:56:08 I'm trying to refactor out as much of the old code and logic as I can so we have a set of individually useful tools and a bit of glue. 2017-04-21 03:57:47 multitool and the plugin loader will eventually handle everything, with the last of mkinitfs and mkimage turning into tools so we can parse the common options in one place. 2017-04-21 03:58:39 would rename from mkimage to buildbox :D 2017-04-21 03:58:48 I'm just trying to track down any important corner cases before I do the re-overhaul of mkinitfs (I already rewrote it once :) 2017-04-21 03:58:53 actually, mkalpine. 2017-04-21 03:59:10 fine too 2017-04-21 03:59:12 It will be the basis of the installer as well. 2017-04-21 04:00:10 So I guess this will be the base for alpine 4.0? 2017-04-21 04:00:38 And once I get done with the refactoring, the various tools will be able to be installed independently and autoload their deps. 2017-04-21 04:00:47 3.6 hopefully, at least in part. 2017-04-21 04:02:44 I just need to firm up filenaming/directories/formats with ncopa and fabled, finish cutting over to the new staging tools, and axe the old code. The repo split is ready to happen any day now, with nlplug-findfs becoming it's own package. 2017-04-21 04:03:36 But what is really needed is testing of the various functions that follow EXISTING functionality to make sure it's not breaking things. 2017-04-21 04:04:15 There are a couple whole classes of cases I haven't even touched yet because I haven't experimented with them on runnign hardware yet. 2017-04-21 04:04:25 Such as boot on arm :) 2017-04-21 04:05:15 If I had a good document explaining where, say, rpi1 vs rpi2 vs rpi3 find their various artifacts, I could close that out. 2017-04-21 04:05:25 *wink* 2017-04-21 04:07:01 The other thing I know is broken is reverse detection of arch from kernel .config files, which needs to be fixed to make custom-build kernel directories reliable. 2017-04-21 04:07:55 Basically, I need a matrix of header + config opts for each arch .config 2017-04-21 04:08:57 Because x86_64 is indicated as 'x86' in the .config files, and I need to parse for BITS to find out if I'm 32 or 64 (or x32!?). 2017-04-21 04:11:54 xentec: Does your boot config look essentially standard or do you use a custom boot setup. 2017-04-21 04:26:43 right now I use the more or less standard "run-in-ram" variant, but my plan is to use a custom design. An immutable squashfs-root with overlaytmpfs and and apkovl+apk upgrade on top of it 2017-04-21 04:27:56 >TemptorSent: If I had a good document explaining where, say, rpi1 vs rpi2 vs rpi3 find their various artifacts, I could close that out. 2017-04-21 04:28:40 all rpis with arm32 use bootcode.bin,start.elf,fixup.dat 2017-04-21 04:29:12 or start_cd.elf+fixup_cd.dat if gpu_mem=16 has been set in config.txt 2017-04-21 04:29:53 rpi3 with aarch64 uses uboot afaik 2017-04-21 04:31:18 there are funny bits here and there. e.g. rpi3 not always finding its firmware if boot partition has a label in it 2017-04-21 04:37:39 I see some funny existing code putting things in different places on different pi 2017-04-21 04:37:57 in current mkimage? 2017-04-21 04:38:55 in existing update-kernel IIRC. 2017-04-21 04:39:30 ah yes, I forgot about device trees 2017-04-21 04:39:53 Take a look at the bottom of /sbin/update-kernel... it's confusing what exactly the intent is there. 2017-04-21 04:40:23 What's the differnce between MEDIA and non-MEDIA on a rpi anyway? 2017-04-21 04:40:27 I've been rewriting it for my goals, so I pretty much know that you mean. 2017-04-21 04:41:05 Oh, what are you trying to get it to do? 2017-04-21 04:41:32 my custom boot 2017-04-21 04:41:52 also only installing overlays I've specified in config.txt 2017-04-21 04:42:21 Right, what do you need for that? I'd be surprised if mkimage and friends can't already do most of that, including the bootloader config. 2017-04-21 04:43:02 ah and since I'm compiling my own kernel with some firmware blobs included, I needed to purge the linux-firmware parts in it 2017-04-21 04:43:32 TemptorSent> What's the differnce between MEDIA and non-MEDIA on a rpi anyway? 2017-04-21 04:43:50 Right, no assumption on firmware, and multiple custom build directories are coded and supported, given a bit of testing and tweaking. 2017-04-21 04:43:57 good question. rpi only looks in /boot for device trees 2017-04-21 04:44:22 Got it. That's where we'll install them then :) 2017-04-21 04:45:33 I need to flesh out some device support in addition to the arch support for strangeness like that. 2017-04-21 04:46:35 But it's staged in such a manner you can grab what you need and copy it into place easily. 2017-04-21 04:47:28 you should a an optional filter for device tree overlays that parses config.txt. something like http://npaste.de/p/JN/ 2017-04-21 04:47:36 What sort of format are the custom firmware blobs coming in? I still have generic directory/tarball support. 2017-04-21 04:47:50 Sounds good! 2017-04-21 04:49:03 No problem. 2017-04-21 04:49:22 http://npaste.de/p/6fLW/ corrected a path* 2017-04-21 04:51:04 however the device trees themselves are a bit trickier to filter 2017-04-21 04:51:25 http://npaste.de/p/6k/ this is the full list 2017-04-21 04:52:24 if all are present in /boot, rpi will select a fitting one. if I can't find one, boot will simply fail 2017-04-21 04:52:39 If it* 2017-04-21 04:54:39 Ahh, okay - and they get rendered to .dtbo? 2017-04-21 04:55:16 no, the dtbos (the overlays) are layered on them 2017-04-21 04:55:36 (dtbo and dtbo are both binary) 2017-04-21 04:55:52 dtb and dtbo* damn it 2017-04-21 04:57:51 Okay, so ideally we want to figure out both deps and install only those? 2017-04-21 04:58:05 How large are the dtbs? 2017-04-21 04:59:03 yes, *ideally*. but for a standard image you'd want to put all of them in there so it always boots 2017-04-21 04:59:20 they are not large. biggest is 15.2 KiB 2017-04-21 04:59:41 Methinks we'll end up wanting a rpitool at some point because it has so very many oddities. 2017-04-21 04:59:44 smallest 8.8 KiB 2017-04-21 05:00:39 Okay, nothing I'm going to cry over on a sd card, and not even ugly over a slow radio modem, I can live with installign all of them :) 2017-04-21 05:00:41 all together with overlays sum up to 740 KiB 2017-04-21 05:01:24 correction: 347 KiB 2017-04-21 05:01:26 We can filter as needed where needed, but not something that's going to be an issue on a standard image. 2017-04-21 05:07:23 I scratched the filter into my working dir for when I add the devices directory to the tree. 2017-04-21 05:08:28 The kerneltool-kbuild.sh tool is pretty flexible in terms of what it supports for targets and config opts, let me know how far that is from meeting your needs. 2017-04-21 05:08:56 Hello fabled_? 2017-04-21 06:18:36 xentec: it looks okay to me. i will integrate it in a bit 2017-04-21 06:19:54 thanks! 2017-04-21 09:53:02 Hum, looks like sourceforge screwed up pyxml package 2017-04-21 09:54:41 unfortunately its not the only thing they screwed up... 2017-04-21 11:00:04 <^7heo> So yeah, the xterm in community now has sixel support 2017-04-21 11:00:11 <^7heo> \o/ 2017-04-21 11:00:30 <^7heo> I wonder if someone can display sixels on IRC. 2017-04-21 11:00:35 <^7heo> technically it should be possible... 2017-04-21 11:02:43 <^7heo> I guess not, since ansi colors cannot be sent over IRC. 2017-04-21 11:45:07 Why do you say that. 2017-04-21 11:46:32 <^7heo> skarnet: #define that 2017-04-21 11:46:40 <^7heo> (I'm unsure as to what to answer) 2017-04-21 11:48:04 sending ansi colours over IRC looks doable to me 2017-04-21 11:48:34 (I said nothing about desirability) 2017-04-21 11:48:36 <^7heo> Well, IRC has its own serializing for colors, does it not? 2017-04-21 11:49:05 yes it does, but afaik it's 16-color ansi encoding 2017-04-21 11:49:06 <^7heo> as in, it is the job of the irc client to convert those colors in a way that the terminal/window can display. 2017-04-21 11:49:09 it's not rgb or anything :P 2017-04-21 11:49:19 <^7heo> well they have 256 color support I think 2017-04-21 11:49:30 <^7heo> s/they have/it has/ 2017-04-21 11:49:35 maybe 2017-04-21 11:49:45 <^7heo> But yeah, however 2017-04-21 11:49:54 anyway I like a medium that focuses on content 2017-04-21 11:49:58 not on pretty colours 2017-04-21 11:50:00 <^7heo> It doesn't have the support for other ANSI codes than color, I think. 2017-04-21 11:50:07 <^7heo> I mean, arbitrary ANSI codes. 2017-04-21 11:50:21 <^7heo> for example, the clear screen is a feature of the client. 2017-04-21 11:50:26 <^7heo> you can't clear the screen of the people remotely ;) 2017-04-21 11:50:32 arbitrary ansi codes? what could possibly go wrong 2017-04-21 11:50:37 <^7heo> hahah ;) 2017-04-21 11:50:42 <^7heo> Right. 2017-04-21 11:50:49 <^7heo> But Sixel is using ansi codes. 2017-04-21 11:50:53 <^7heo> and so does ReGIS. 2017-04-21 11:51:57 <^7heo> and using Sixel/ReGIS support would allow for graphics IN irc. 2017-04-21 11:51:59 I strongly suspect those words refer to something graphical I'm happy not to care about 2017-04-21 11:52:07 <^7heo> That might be true. 2017-04-21 11:52:20 <^7heo> But on the other hand, I struggle to get people to adopt irc because of the lack of graphical support. 2017-04-21 11:52:24 I'm also quite certain I do NOT want graphics in IRC 2017-04-21 11:52:50 <^7heo> of course, like with colors, there must be a channel mode to refuse graphics. 2017-04-21 11:53:13 those people can use fancy-IM-app-of-the-month for their special needs 2017-04-21 11:53:26 <^7heo> But refusing the support of something others might need/want just because you don't want it is the wrong behavior. 2017-04-21 11:53:34 <^7heo> Not caring about it is fine. 2017-04-21 11:53:39 that's not what I'm doing 2017-04-21 11:53:43 <^7heo> yeah ;) 2017-04-21 11:53:47 I'm saying IRC is the wrong protocol for this 2017-04-21 11:53:51 <^7heo> I'm not sure. 2017-04-21 11:54:11 <^7heo> Afterall, it's all printable characters. 2017-04-21 11:54:23 text 2017-04-21 11:54:25 <^7heo> yeah. 2017-04-21 11:54:30 KISS 2017-04-21 11:54:37 <^7heo> (aside from the control characters in the beginning) 2017-04-21 11:54:43 <^7heo> well yes, KISS. 2017-04-21 11:54:48 <^7heo> Sixel and ReGIS are kiss. 2017-04-21 11:54:53 of course 2017-04-21 11:55:07 tell that to IRC client implementors 2017-04-21 11:55:37 <^7heo> I did, they came up with a concern about spam countermeasures. 2017-04-21 11:55:40 <^7heo> Which is valid. 2017-04-21 11:55:48 <^7heo> But so is copy/pasting a file over IRC. 2017-04-21 11:55:52 <^7heo> so... 2017-04-21 11:56:18 <^7heo> I dunno. 2017-04-21 11:56:26 <^7heo> I feel like it would be worth having that in the protocol. 2017-04-21 11:56:27 it won't surprise you if I tell you I find that feature of IRC is bad engineering 2017-04-21 11:56:32 <^7heo> of course it could be possible to implement that as plugins. 2017-04-21 11:56:53 <^7heo> the counter-spam measures? 2017-04-21 11:57:05 copypasting a file, dummy. 2017-04-21 11:57:14 <^7heo> but it's not a feature of IRC... 2017-04-21 11:57:43 DCC is 2017-04-21 11:57:48 <^7heo> ah DCC is. 2017-04-21 11:57:50 <^7heo> but DCC isn't spam. 2017-04-21 11:57:59 <^7heo> copy/pasting a file in a channel is spam. 2017-04-21 11:58:08 <^7heo> (and that is what I referred to) 2017-04-21 11:58:14 ah, ok, got it now. 2017-04-21 11:58:17 <^7heo> yeah. 2017-04-21 11:58:24 <^7heo> so basically, my point is: 2017-04-21 11:58:38 <^7heo> people who copy/paste files on IRC are ejected by counter-spam measures. 2017-04-21 11:58:46 <^7heo> and so would people copy/pasting sixels on IRC. 2017-04-21 11:58:59 <^7heo> however having the sixel support might help the adoption. 2017-04-21 11:59:09 I disagree 2017-04-21 11:59:20 <^7heo> it could be supported in many other ways than one-to-many (channel) communication. 2017-04-21 11:59:21 call me conservative 2017-04-21 11:59:53 but the people who would adopt IRC because it can have graphixx won't stop there 2017-04-21 11:59:59 <^7heo> I definitely can see bots using ReGIS to display graphs or stuff. 2017-04-21 12:00:05 next thing they'll ask for audio chat or something 2017-04-21 12:00:22 those are not the people who *use* irc 2017-04-21 12:00:22 <^7heo> for monitoring, code tendencies, etc. 2017-04-21 12:00:42 <^7heo> maybe. 2017-04-21 12:00:47 <^7heo> but IRC is gonna die because of this... 2017-04-21 12:00:53 <^7heo> which is sad. 2017-04-21 12:00:54 no 2017-04-21 12:01:01 <^7heo> look at matrix. 2017-04-21 12:01:17 <^7heo> I can't tell if it's just hype or actually adopted enough to weaken IRC. 2017-04-21 12:01:24 it's gonna die because nobody can take the time and energy to design a decent unifying version of the protocol 2017-04-21 12:01:30 i feel that the only way IRC can differentiate itself is by being conservative 2017-04-21 12:01:33 it's dying from vendor lock-in 2017-04-21 12:01:41 <^7heo> skarnet: maybe yes. 2017-04-21 12:01:45 adding more features won't help that 2017-04-21 12:01:54 if IRC tries to be another matrix, or discord, it has already lost 2017-04-21 12:01:59 ^ 2017-04-21 12:02:00 <^7heo> skarnet: ok you're right. 2017-04-21 12:02:18 the reason people use IRC in 2017 is precisely because it's not matrix, or discord 2017-04-21 12:02:36 I'm with asie there 2017-04-21 12:02:43 <^7heo> That's true. 2017-04-21 12:02:43 it's simple, runs on anything and is not dependent of any large commercial entity that needs to monetize to survive 2017-04-21 12:02:53 <^7heo> nah, you're right. 2017-04-21 12:03:23 the one thing that could happen is unifying nickserv/chanserv/etc. behaviour to not be a hack on top of IRC, but see the xkcd standards comic for how that would end 2017-04-21 12:03:28 <^7heo> But then *someone* would need to take the time and energy to design a decent unifying version of the protocol 2017-04-21 12:03:31 IRC is 25 years old and writing a client is very simple. therefore, we have very many clients 2017-04-21 12:03:38 <^7heo> before we end up being 3 or 4 per server/channel 2017-04-21 12:03:49 you won't create a unifying version of the protocol because you won't make everyone agree on it 2017-04-21 12:03:52 <^7heo> a lot of communities have already moved over to gitter/slack 2017-04-21 12:03:53 it's about 15 years too late for that 2017-04-21 12:04:00 <^7heo> yeah 2017-04-21 12:04:03 yes, for dev communities it's gitter/slack 2017-04-21 12:04:05 for gamers it's discord 2017-04-21 12:04:08 etc, etc 2017-04-21 12:04:16 <^7heo> yeah but what do we do now? 2017-04-21 12:04:21 <^7heo> do we just watch it die? 2017-04-21 12:04:26 yes, or make something **new** 2017-04-21 12:04:30 that is not irc 2017-04-21 12:04:33 can be backwards compatible 2017-04-21 12:04:36 and should be, even 2017-04-21 12:04:40 but is fundamentally not called IRC 2017-04-21 12:04:52 what do we do now? I for one will enjoy the sunshine and the scent of the flowers 2017-04-21 12:05:00 i wouldn't be opposed to the idea of a new protocol-based server with limited IRC backwards compatibility 2017-04-21 12:05:08 but the moment you break an IRC client is the moment you failed to unify IRC 2017-04-21 12:05:19 <^7heo> skarnet: there's no sunshine and scent of flowers in Germany. 2017-04-21 12:05:24 <^7heo> skarnet: enjoy it where you are. 2017-04-21 12:05:26 look better 2017-04-21 12:05:32 <^7heo> I can't. 2017-04-21 12:05:38 <^7heo> The sky is freaking bright, but white. 2017-04-21 12:05:46 <^7heo> it's like the sky is made of neon lights. 2017-04-21 12:05:52 Take a hike in the country 2017-04-21 12:06:00 <^7heo> yeah I should go to the south. 2017-04-21 12:06:05 <^7heo> to remember how it is to feel alive. 2017-04-21 12:06:53 <^7heo> Anyway, the IRC discussion was borderline -offtopic but the weather-sun-alive discussion definitely is. 2017-04-21 12:06:57 <^7heo> ;) 2017-04-21 14:22:48 https://twitter.com/n_copa/status/855426268111802374 2017-04-21 14:23:08 this is crazy... 2017-04-21 14:23:34 but i wonder if the ppc64le config is a bit smaller than the x86* 2017-04-21 14:25:31 Woah! 2017-04-21 14:25:40 That's insanity. 2017-04-21 14:26:51 yup... total insane 2017-04-21 14:27:09 Massive parallelism works :) 2017-04-21 14:27:22 thats what i wanted to test :) 2017-04-21 14:27:25 now 2017-04-21 14:27:32 add a configure script... 2017-04-21 14:27:41 and guess what happens 2017-04-21 14:27:55 Yeah, bottleneck time. 2017-04-21 14:29:35 You'd need dispatchers and a workqueue to get any of the efficiencies of scale when building out packages. 2017-04-21 14:29:55 yeah i thought about that today 2017-04-21 14:30:15 thanks to autoconf it is probably better to build multiple packages at the same time with make -j1 2017-04-21 14:31:04 Or run a configure round with -j1, then a build round with -j 32 x 8 2017-04-21 14:31:31 Keep the cache misses from getting totally out of hand anyway. 2017-04-21 14:31:48 best would be get rid of configure/autoconf 2017-04-21 14:33:00 Yeah -- I remember being happy when a package had a configure script and I didn't have to hand-edit the source to run it on linux, but now we've got configure scripts that take longer to run than it does to compile the software they build! 2017-04-21 14:33:26 and is bigger than the application itself 2017-04-21 14:33:31 both source and compiled 2017-04-21 14:34:06 Sanely, nearly everything autotools does should be checked once and cached. 2017-04-21 14:34:23 i think that is problematic 2017-04-21 14:35:34 Once it knows which functions my libc supports and how to handle the bugs, it doesn't need to rerun the bloody test on EVERY package I install. 2017-04-21 14:36:04 We're talking something between 50 and 1000 tests! 2017-04-21 14:37:00 i know gentoo experimented with configure cache 2017-04-21 14:37:09 but i think it was not really recommended 2017-04-21 14:37:12 caused some issues 2017-04-21 14:37:16 i dont remember the details 2017-04-21 14:37:51 Mostly, it was because configure was broken IIRC 2017-04-21 14:39:17 You had to have autoconf-2.13 or whatever for EVERY package, because minor point releases broke things. 2017-04-21 14:39:37 ah 2017-04-21 14:39:40 that makes sense 2017-04-21 14:39:44 And it still took a long time just to scan the cache. 2017-04-21 14:40:41 It was just a raw cache, no versioning, checksums, timestamps, etc, so it was easy to break :) 2017-04-21 14:42:00 The whole design of the autotools caching mechanism is horribly ugly. 2017-04-21 14:43:39 And some config scripts break just because you use a cache because they rely on side-effects of one check to run another. 2017-04-21 14:45:38 Or in other words, autotools has outlived its usefulness, especially for building large quantities of simple packages. 2017-04-21 14:49:48 ncopa: Do you have a few minutes to go over boring details, like file naming, installation directories, and the like for the mkalpine toolsuite? 2017-04-21 14:50:26 not really 2017-04-21 14:50:31 do you have a proposal? 2017-04-21 14:50:43 do you want be backwards compat? 2017-04-21 14:51:09 or we drop backwards compat and introduce this as something new 2017-04-21 14:51:13 which replaces the old 2017-04-21 14:51:33 I've just thrown in something usable for the moment, but names for manifests, indicies, and deplists is one issue. 2017-04-21 14:52:05 For the most part, not much is an issue for backwards compat in that regard. 2017-04-21 14:52:22 ok 2017-04-21 14:52:28 It's more forward compat I'm looking at, as well as consistency 2017-04-21 14:52:35 ok 2017-04-21 14:53:42 /usr/share/mkalpine for the tools / standard files, /var/cache/mkalpine for staging 2017-04-21 14:54:01 sounds good 2017-04-21 14:54:20 /usr/share/mkinitfs can stay or go, depending on preference. 2017-04-21 14:54:54 mkinitfs will be a standalone tool right 2017-04-21 14:55:10 which can be installed separately 2017-04-21 14:55:15 What I'm doing currently is dropping the manifest/index/deps in the root of the staging dir. 2017-04-21 14:55:50 Actually, mkinitfs becomes a couple calls to kerneltool and a couple calls to apkroottool 2017-04-21 14:57:56 which needs /usr/share/mkalpine? 2017-04-21 14:58:33 if we can have mkinitfs without dependencies in /usr/share/mkalpine, then i think it makes sense with /usr/share/mkinitfs 2017-04-21 14:59:52 kerneltool stage latest-$flavor ; kerneltool mkmodcpiogz ; apkroottool setup ; apkroottool apk add --no-scripts ; apkroottool subset-cpiogz 2017-04-21 15:01:16 So yes, all of the tool use the common functions in mkalpine. The only thing currently in /usr/share/mkinitfs is a set of skel passwd/group/fstab files and the initramfs-init itself. 2017-04-21 15:03:19 Also, since kerneltool can do all of the fetching, we can call it to update the kernel without doing an apk upgrade. 2017-04-21 15:04:36 mkinitfs' job becomes just translating the arguments to commands, then doing the final copy of files to their destination. 2017-04-21 15:05:51 update-kernel is the same way, all it needs to do is the unmounting/mounting and copying of generated files to their dests. 2017-04-21 15:07:24 To build the initfs, mkinitfs will take the two generated cpio.gz from kerneltool and apkroottool, along with a third containing the skel files/init, and cat them together. 2017-04-21 15:08:39 So really what I'm after is where do we want to keep the files it includes in that last cpio.gz, which currently live in /usr/share/mkinitfs, and do we need to handle any other external files besides those? 2017-04-21 15:09:12 As well as where do we want to install manifests/deps/indicies on the system for what we've actually installed? 2017-04-21 15:10:10 Ideally, apk learns to handle the manifests itself and we can get rid of a heaping chunk of the code in mkalpine. 2017-04-21 15:11:26 Failing that, I'll probably end up writing a manifest tool in C that can offload most of the slow work. 2017-04-21 15:14:15 So nailing down file/field formats for the manifests is a reasonably high priority. 2017-04-21 15:15:52 And there are still a few pain points I think I can shave some time off with a refactor of the order of operations before having to go there. 2017-04-21 15:19:00 I haven't replumbed the last bits of mkinitfs/update-kernel yet, as I want to make sure I'm missing any major corner cases in their use. 2017-04-21 15:19:24 For instance, WTF is with MEDIA vs non MEDIA on rpi? 2017-04-21 15:20:34 And generally, is MEDIA supposed to just be used for images, or is that also intended for other uses? 2017-04-21 17:14:27 No armhf builds of mongodb (oddly?) http://pkgs.alpinelinux.org/packages?name=mongodb*&branch=&repo=&arch=&maintainer= 2017-04-21 17:17:09 Oh, possibly because mongodb doesn't support 32bit platforms, or non linux 2017-04-21 17:22:30 clandmeter : could you put pyxml package on dev.a.o or distfiles.a.o for now ? 2017-04-21 17:23:11 clandmeter : looks like it's already there : http://distfiles.alpinelinux.org/distfiles/PyXML-0.8.4.tar.gz 2017-04-21 17:23:54 i think we shoudl set the DISTFILES_MIRROR in /etc/abuild.conf 2017-04-21 17:31:42 ncopa : hah never come across DISTFILES_MIRROR before. seems cool. so pr to abuild ? 2017-04-21 17:41:06 It would be nice if apk could resolve mirrors when one craps out... 2017-04-21 17:49:46 tmh1999: abuild has support for DISTFILES_MIRROR 2017-04-21 17:49:49 its just a config option 2017-04-21 17:49:58 but we should probably use it for s390x 2017-04-21 17:50:11 ncopa : yeah I mean make it default on /etc/abuild.conf 2017-04-21 17:50:16 ok cool 2017-04-21 18:48:50 ragechin_ : Probably here if it has to do with the build system. 2017-04-21 18:55:33 I'm trying to create a custom package for personal use. The end goal is that I have services running on my server and I provide the config files for those services through the custom packages. 2017-04-21 18:56:33 In my first attempt at this, I'm simply trying to provide a custom /etc/dnsmasq.conf through the 'test-package' package. Well, this happens.. 2017-04-21 18:56:35 ragechin_: Hmm, I'm not sure a package is the appropriate means of doing that unless the config is static. 2017-04-21 18:56:35 ERROR: test-package-0.01-r3: trying to overwrite etc/dnsmasq.conf owned by dnsmasq-2.76-r0. 2017-04-21 18:56:44 TemptorSent: It is in my case. 2017-04-21 18:56:48 Or close enough to static. 2017-04-21 18:56:58 You probably want to use overlays, not packages. 2017-04-21 18:57:01 I'm trying to discern the best way to go about it from a package perspectivel. 2017-04-21 18:57:32 Is this for provisioning new builds? 2017-04-21 18:57:41 No, not necessarily. 2017-04-21 18:58:24 The other option I could think of is to roll my own custom version of dnsmasq and include my custom config file in it. I'd prefer to not do that, if it can be avoided. 2017-04-21 18:58:44 My suggestion is to either use lbu or create a tarball with the required files in the right places, then apply that as an overlay. 2017-04-21 18:59:14 Changes to overlays require a reboot, correct? 2017-04-21 18:59:25 No, you can just untar them :) 2017-04-21 18:59:36 Hmmm 2017-04-21 18:59:50 So install the new overaly, and untar it to apply. 2017-04-21 19:00:13 That is an option. 2017-04-21 19:00:15 I'm working on tools that handle most of the config stuff. 2017-04-21 19:00:35 But right now it's somewhat tied to mkimage. 2017-04-21 19:00:46 must you bring mkalpine into everything 2017-04-21 19:00:50 lbu already just works 2017-04-21 19:01:26 lbu isn't great for making a config for distribution from my experiences with it. 2017-04-21 19:01:36 has always worked for me 2017-04-21 19:02:28 So how do you package up just a couple of specific files using lbu without taking care to not touch anything else? 2017-04-21 19:02:43 My lbu-foo is lacking ;) 2017-04-21 19:03:45 lbu ex / 2017-04-21 19:03:49 lbu in /myfile1 2017-04-21 19:03:52 lbu in /myfile2 2017-04-21 19:03:54 etc 2017-04-21 19:04:07 Doesn't that alter the entire state? 2017-04-21 19:04:58 ? 2017-04-21 19:05:07 the entire point of lbu is that it captures the system state... 2017-04-21 19:05:07 Say I wanted to send out ragechin_'s "/etc/dnsmasq.conf", is there an lbu command to just extract that file to an overlay? 2017-04-21 19:05:40 sure, # tar -cf toot.apkovl.tar.gz etc/dnsmasq.conf from / 2017-04-21 19:05:47 Right, which is not so great when you want to extract portions of it independent of the rest. 2017-04-21 19:05:55 ...which is exactly what I suggested :) 2017-04-21 19:05:55 which is not the point of lbu 2017-04-21 19:06:01 the point is to capture the system state 2017-04-21 19:06:08 if you need to pack up individual files, that's what tar is for 2017-04-21 19:06:14 lbu doesn't /need/ to support that use-case 2017-04-21 19:06:32 Can it conveniently apply such tarfiles TO the system? 2017-04-21 19:07:14 (as in add them to be tracked upon overlaying) 2017-04-21 19:08:31 so you only care about system state when unpacking, but not creating? 2017-04-21 19:08:33 that seems rather silly 2017-04-21 19:08:45 Hmm, doesn't look like it, which means you need to manually add it. 2017-04-21 19:09:00 Did you read what ragechin_ is trying to accomplish? 2017-04-21 19:09:27 i diid, and they can do it just fine with lbu 2017-04-21 19:09:40 He wants something he can distribute and install that will replace /etc/dnsmasq.conf. 2017-04-21 19:10:11 yes, so an apkovl 2017-04-21 19:10:15 Not the entire system state. 2017-04-21 19:10:23 he said absolutely nothing about tracking it further after unpacking 2017-04-21 19:10:41 which is also not something they'd get through packages, their initial idea 2017-04-21 19:10:45 Then upon reboot, it's gone. 2017-04-21 19:11:01 apkovl= command line parameter exists 2017-04-21 19:11:01 package in world = persisted. 2017-04-21 19:11:20 Yeah, take a look at how it's implemented. 2017-04-21 19:11:28 i already have 2017-04-21 19:11:40 It will pick up the default iff there is ONE apkovl in the root. 2017-04-21 19:11:58 Otherwise, it requires explicit modification to the boot config. 2017-04-21 19:12:15 I'll chime in here - define "packaging" 2017-04-21 19:12:18 er, "trackign" 2017-04-21 19:12:29 So to have it persist, it needs to be applied to the apkovl as well as the running system. 2017-04-21 19:12:54 Persisted across reboots and available for backup by lbu so a restore returns the system to the same state. 2017-04-21 19:13:18 Preferably without manual intervention or scripting required. 2017-04-21 19:13:24 but this is not something they mentioned at all 2017-04-21 19:13:28 you're making up use-cases now 2017-04-21 19:14:21 Shiz: Go grab a cup of coffee, then read the last page in the backlog. 2017-04-21 19:14:25 He's actually not. 2017-04-21 19:14:36 I need a way to distribute custom configuration files, ideally through packages. 2017-04-21 19:14:51 I don't want chef, puppet, or any of that. I want a repo that I can generate a package from. 2017-04-21 19:15:09 SSH into $(X) machines, apply updates, restart services as needed, done 2017-04-21 19:15:22 TemptorSent: you can just point me to where i'm wrong instead of condescendingly implying things 2017-04-21 19:15:54 anyway. 2017-04-21 19:16:32 I figured you missed it on the first reading, since it was one of the first thing ragechin_ said. The coffee is to make the task more pleasurable :) 2017-04-21 19:16:39 i don't like coffee 2017-04-21 19:16:43 so i doubt it will 2017-04-21 19:16:46 (Tea works too, or a nice scotch if that's your preference) 2017-04-21 19:16:59 my point was that there was nothing said about creating a new version from the machines those configs are applied to 2017-04-21 19:17:04 which is part two of what you said 2017-04-21 19:17:51 so it's better to ask them directly 2017-04-21 19:17:55 ragechin_: is that part of your use case :P 2017-04-21 19:17:59 The requrest was for a means of creating a package to be distributed to machines that would override an existing configuration file, and presumably ONLY tha configuration file, in a persistnet manner. 2017-04-21 19:18:59 ragechin_: fwiw, i do think packages are a wrong way toapproach this, as packages should never conflict in the files they install 2017-04-21 19:19:09 ragechin_: what if it would work, and say 2017-04-21 19:19:15 dnsmasq gets updated, so you upgrade 2017-04-21 19:19:20 Breaking other standard behavior (i.e. not persistign on reboot) compared to a package isn't useful. 2017-04-21 19:19:33 if the package manager would never overwrite config files, you'd keep your old custom config files 2017-04-21 19:19:36 That's exactly what I said above. 2017-04-21 19:19:48 but that'd also mean it wouldn't update config files when your custom package updates, which would be presumably the intention 2017-04-21 19:20:09 i think by design packages shouldn't conflict in their files since it creates weird update situations like that 2017-04-21 19:20:15 An overlay is the appropriate solution because it's already manged properly by both apk and lbu. 2017-04-21 19:21:07 The problem is only in how to apply one to a running system in such a manner that it persists the same way it would if it had been added to the overlay and the machine restarted. 2017-04-21 19:21:28 fwiw, I don't really care about the system state. 2017-04-21 19:21:45 TemptorSent: i'm not sure if that is what needed at all 2017-04-21 19:21:48 So you couldn't tell the differnce between a machine which had it applied live, vs one which it was applied to the overlay and the machine rebooted. 2017-04-21 19:21:52 The larger goal is that I can take this device, nuke it, do a reinstall of base, then add my custom packages.. and be done 2017-04-21 19:21:57 ragechin_: right 2017-04-21 19:22:18 TemptorSent: mabye i'm understanding you wrong, but 2017-04-21 19:22:29 ragechin_: Presumably, you don't want to have to reboot for changes to take effect, and you don't want changes lost upon reboot, correct? 2017-04-21 19:22:30 your implication seems to be that it should also survive local changes made after applying the apk overlay? 2017-04-21 19:22:37 TemptorSent: Correct. 2017-04-21 19:22:40 and i'm not sure i saw that mentioned anywhere 2017-04-21 19:22:56 That's simply normal expected behavior. 2017-04-21 19:23:11 Rebooting to install changes is a Windoze thing. 2017-04-21 19:23:16 The most I want to bounce are local services - and that, too, is expected behavior. 2017-04-21 19:23:35 i'm not talking at all about rebooting though? 2017-04-21 19:23:49 So the idea is business as normal, but with added custom overlay for config files. 2017-04-21 19:23:59 so i'll ask again directly :P 2017-04-21 19:24:06 ACTION grabs popcorn 2017-04-21 19:24:18 *lol* 2017-04-21 19:24:32 ragechin_: is it in your use case that local changes not in your custom config system (however you do it, packages or otherwise), survive reboot? 2017-04-21 19:24:47 e.g. say the system installs a custom dnsmasq.conf 2017-04-21 19:24:49 you edit it locally 2017-04-21 19:24:51 you reboot 2017-04-21 19:25:01 should those changes survive or should it be reverted to the custom dnsmasq.conf from before 2017-04-21 19:26:20 They should act exactly as they would had you installed a package which installed the same files, if you stored your modifications with lbu, they should be applied presumably. To act otherwise is unexpected behavior. 2017-04-21 19:26:33 i'm expecting them to answer, not you 2017-04-21 19:27:14 I'm stating expected behavior from the standpoint of consistency. 2017-04-21 19:27:58 and i'm stating that when i explicitly addressed them to clear a confusion up you shouldn't bump in with assumptions 2017-04-21 19:28:00 :P 2017-04-21 19:28:05 Shiz, let's say that dnsmasq does an update, and the default dnsmasq.conf is thrown back into /etc/dnsmasq.conf. I would expect the package manager to notice that I've modified the config - in some way - and not blow away my configs. 2017-04-21 19:28:15 ragechin_: right, it already does that 2017-04-21 19:28:17 Perhaps save the new default config as /etc/dnsmasq.conf.rpm or whatever. 2017-04-21 19:28:18 Ok. 2017-04-21 19:28:34 it'll save as .apk-new i think 2017-04-21 19:28:43 FWIW, I won't be editing these configs locally on disk. 2017-04-21 19:28:48 alright 2017-04-21 19:28:51 Unless it's an emergency 2017-04-21 19:28:52 The system behavior must be consistent regardless of the tools used, otherwise things will break if done in different order or on different configs. 2017-04-21 19:29:10 and honestly - in that case, I'd prefer that my out-of-band changes are *NOT* persistent. 2017-04-21 19:29:16 right 2017-04-21 19:29:28 So that I can go through and commit my changes to the appropraite development cycle and (...) 2017-04-21 19:29:31 ragechin_: so the fun part of lbu, and this may be a bit subjective cause i'm using it in prod 2017-04-21 19:29:34 (:P) 2017-04-21 19:29:37 I'm spending enough time fixing 'special cases' scattered through code as it is. 2017-04-21 19:29:58 that in a lot of cases you don't even need a persistent install at all 2017-04-21 19:30:06 not all cases, of course 2017-04-21 19:30:22 but its funny how much you can get away with, and then you have a system completely bootstrapping itself on every boot and applying lbu changes 2017-04-21 19:30:31 A workaround, I guess, would be an overlay thrown into a package and have it untarr'd? 2017-04-21 19:30:44 By persist, it need not be resident, mearly stored in a manner that restores to the same state. 2017-04-21 19:31:29 Shiz: that's fair, are you fetching the overlays from external, or do they reside on disk? 2017-04-21 19:31:34 externally 2017-04-21 19:31:36 ragechin_: That might be a sane option for now, although I'm lobbying to get apkovl handling in apk itself improved for such needs. 2017-04-21 19:31:58 ragechin_: the initramfs allows fetching apkovls over http 2017-04-21 19:32:15 and when you put packages in /etc/apk/world that's stored into the apkovl, it'll automatically install them 2017-04-21 19:32:17 Shiz: Interesting. Unfortunately that doesn't scale as well for me. My intiial use case is my home router. I need to bring up all of my VLANs and other interfaces before I allow outbound traffic. 2017-04-21 19:32:18 I have code that takes a set of features and spits out a configured overlay. 2017-04-21 19:32:41 Shiz: Indeed. I took advantage of that to bootstrap an EC2 instance to create an AMI. 2017-04-21 19:32:54 of course, you can also store the apkovl on some local medium 2017-04-21 19:32:56 What we need is /etc/apk/overlays or some such 2017-04-21 19:32:59 it doesn't make a difference for the boot process much 2017-04-21 19:33:05 Fair enough. 2017-04-21 19:33:37 Which would load overlays stored on the rootfs early in the init process. 2017-04-21 19:33:44 How does it handle multiple overlays? I could, in theory, have multiple services w/custom configs that need to be put in place. 2017-04-21 19:33:54 right now, not very much 2017-04-21 19:33:56 :P 2017-04-21 19:33:59 That's what it doesn't do now. 2017-04-21 19:34:00 That's unfortunate. 2017-04-21 19:34:04 however 2017-04-21 19:34:13 You can simply concat them all together though :) 2017-04-21 19:34:36 I'll take "that doesn't scale" for 1,000, Alex. 2017-04-21 19:34:43 hehe 2017-04-21 19:34:46 It only accepts one overlay, but I think it will keep reading through headers. 2017-04-21 19:35:07 ragechin_: so what you could do 2017-04-21 19:35:08 Right, that's why I'm working on fixing the root problem, namely the support for only a single apk in the root of the boot media 2017-04-21 19:35:14 heh. I'm trying to get away from unicorn-purposed servers, not add more. 2017-04-21 19:35:27 TemptorSent: I've come to the conclusion that you like to talk for the sake of talking 2017-04-21 19:35:49 is have one apkovl that contains a simple /etc/local.d script that reads a list of apkovls and unpacks them 2017-04-21 19:36:08 (Or bake that into a package, if I so choose) 2017-04-21 19:36:19 yes, that is one thing you can do in a package :) 2017-04-21 19:36:49 *facepalms*... see suggestion above to load contents of /etc/apk/overlays above. 2017-04-21 19:37:20 Isn't that file managed by another package? 2017-04-21 19:37:27 the file doesn't exist 2017-04-21 19:37:31 he's thinking of a hypothetical file 2017-04-21 19:37:32 It doesn't exist, so make it. 2017-04-21 19:37:36 that would hypothetical apk integration 2017-04-21 19:37:49 and don't add random files to /etc/apk, the package manager might use them in the future in a different way than you'd expect 2017-04-21 19:38:17 Um, what part of my suggestion as an addition to apk did you not see there? 2017-04-21 19:38:25 yes, and it's just that 2017-04-21 19:38:27 a suggestion 2017-04-21 19:38:38 unless you can guarantee it gets exactly added to apk in the way you specify, it is useless 2017-04-21 19:38:42 don't barge into restricted namespaces 2017-04-21 19:39:02 unless you're the owner of that namespace, aka apk :P 2017-04-21 19:39:06 Bloody hell, I submit patches AFTER I test tme. 2017-04-21 19:39:13 yes, that's fine 2017-04-21 19:39:17 who says they'll be accepted? 2017-04-21 19:39:27 patches get judged on more of whether they work or not 2017-04-21 19:39:46 So you're saying don't mess with apk, go create your own solution instead of contributing it to the primary tool. 2017-04-21 19:39:52 all i'm saying is, don't go preparing that /etc/apk/overlays is gonna work unless your patch is in HEAD 2017-04-21 19:40:05 until it is, use some other path... 2017-04-21 19:40:10 Chicken, meet egg. 2017-04-21 19:40:25 anyway 2017-04-21 19:40:27 side-tracking aside 2017-04-21 19:40:32 Fine, call it /etc/notapk/overlays 2017-04-21 19:40:38 ragechin_: i think that's the path of least-resistance for you 2017-04-21 19:40:49 an apkovl or package that adds a simple script to read and extract apkovls on boot/init time 2017-04-21 19:40:58 and those apkovls contain your custom config overrides 2017-04-21 19:41:08 The point is the solution is simple enough, requires no significant modifications, and uses existing tools. 2017-04-21 19:42:03 Ideally, it gets baked into apk (at least the apk package) so it can be generally used by all, not just one special case. 2017-04-21 19:42:33 ragechin_: And I don't particularly like to talk, I do like to actually solve problems. 2017-04-21 19:42:39 i don't see at all how it's apk's responsibiltiy to have anything to do with apkovls, but let's leave that for another time 2017-04-21 19:42:51 Shiz: That handles boot, fair enough. I'm still struggling with runtime config changes. 2017-04-21 19:43:05 Because it needs to know about them when extracting apks to not overwrite things at boot. 2017-04-21 19:43:07 ragechin_: right so 2017-04-21 19:43:19 tar works :) 2017-04-21 19:43:26 ragechin_: there the case is more so 2017-04-21 19:43:35 do you still expect to run a command on your boxes when the config updates? 2017-04-21 19:43:42 (e.g. # apk update as before with the package istuation) 2017-04-21 19:43:49 Yeah, something like that. 2017-04-21 19:43:51 right 2017-04-21 19:43:53 in that case 2017-04-21 19:43:55 In some form. It might be automated later. 2017-04-21 19:43:56 I believe that hooks can handle that. 2017-04-21 19:43:59 you could simply restart the local service 2017-04-21 19:44:01 :P 2017-04-21 19:44:06 and it'll re-fetch/extract apkovls 2017-04-21 19:44:50 maybe something with lbu first to reset stuff... 2017-04-21 19:45:14 Yeah, there should be nothing different between running it live and running after reboot, so long as you have it persisted with lbu for anything needed at boot. 2017-04-21 19:46:22 IIRC there's a way to have a directory monitored for changes, and a script executed at that point. 2017-04-21 19:46:33 Then you can package up custom configs as packages and have them selected by a single config file 2017-04-21 19:46:39 inotify 2017-04-21 19:46:45 inotify or fanotify, yes 2017-04-21 19:46:53 but that's heavy for the application 2017-04-21 19:46:56 or dnotify 2017-04-21 19:46:59 there's like 3 kernel mechanisms 2017-04-21 19:47:18 Here's my current thought... 2017-04-21 19:47:24 incron is good for monitoring for files, but this really is a case of you know when the changes happen. 2017-04-21 19:48:45 Custom configs into an overlay, included in a package. On package install, the APKVOL is moved to /usr/local/apkovl_storage. I have a local.d service that is told that something changed (either through SIGINFO, or whatever mechanism I choose), and it goes back through apkovl_storage and extracts the new contents somewhere. 2017-04-21 19:49:18 hmm 2017-04-21 19:49:20 It's a little heavy. 2017-04-21 19:49:21 so my question there is 2017-04-21 19:49:34 why include the overlays in a package, and not just simply a list of URLs? 2017-04-21 19:49:40 for instance 2017-04-21 19:50:25 My CI lifecycle is geared a bit towards packaging and I've invested a significant amount of time in developing it. 2017-04-21 19:50:30 I really don't want to start it from scratch 2017-04-21 19:50:34 :P 2017-04-21 19:50:53 ragechin_: so if you include it in a package 2017-04-21 19:51:03 you can actually simply extract the apkovls in a post-install script 2017-04-21 19:51:08 don't need the local.d service 2017-04-21 19:51:15 as soon as you # apk upgrade, the post-install script gets run 2017-04-21 19:51:37 and apk doesn't complain about the file conflicts because dnsmasq.conf isn't a file that the package profides. 2017-04-21 19:51:46 It's dnsmasq_config.apkovl.tar.gz or whatever 2017-04-21 19:51:46 right. 2017-04-21 19:52:05 I can install it to /tmp/, and delete the apkovl when I'm done 2017-04-21 19:52:37 it's a bit abuse of packaging, but it'd work I suppose 2017-04-21 19:52:43 Heh. 2017-04-21 19:52:49 I think the apkovl url list is cleaner, but it's up to you and your existing investment 2017-04-21 19:52:51 of course 2017-04-21 19:53:01 Well, my "prod" isn't public facing. 2017-04-21 19:53:05 It's my home network. 2017-04-21 19:53:40 I have a horrible tendency to edit my code in production and cause problems for the Mrs when I'm not home. 2017-04-21 19:53:43 Ba didea. 2017-04-21 19:53:44 bad idea* 2017-04-21 19:53:50 hehe 2017-04-21 19:54:09 i would like to add multiple apkovl support to mkinitfs 2017-04-21 19:54:14 it should be fairly trivial 2017-04-21 19:54:16 brb, testing this out 2017-04-21 19:55:40 Hrmm. I do need to create the archive before I create the package... 2017-04-21 20:45:00 ragechin_: if you wanna override some files installed by another package, then use "replaces" (e.g. replaces="dnsmasq" 2017-04-21 21:07:36 Question, do we need anything in the initfs for apk to be fully functional besides /etc/apk/(arch|keys/|repositories)? 2017-04-21 21:13:51 hmm 2017-04-21 21:14:00 it seems like a bad/unstable idea to rely on a few files being there 2017-04-21 21:14:07 is it not possible to look at what apk --initdb creates? 2017-04-21 21:21:41 Shiz: The problem is apk --initdb creates a whole lot we don't need in the initfs too. 2017-04-21 21:21:57 like? 2017-04-21 21:22:01 honest question, i dont know 2017-04-21 21:22:10 A rather extensive directory structure. 2017-04-21 21:22:51 We want to be able to run apk --initdb from within the initfs, and to actually do anything, we at least need keys and a repository file. 2017-04-21 21:24:10 And unless it's customized, we probably want to default to the user's current alpine release official repos. 2017-04-21 21:24:19 ...but I'm not sure how to get that either. 2017-04-21 21:24:28 hi why is the u-boot directory empty in https://nl.alpinelinux.org/alpine/v3.5/releases/armhf/alpine-uboot-3.5.2-armhf.tar.gz but not in alpine-uboot-3.4.6-armhf.tar.gz? 2017-04-21 21:25:11 Shiz: We want just enough to overcome the chicken and egg problem. 2017-04-21 21:27:09 the uboot-3.4.6-armhf.tar.gz contains u-boot for wandboard_quad, Cubieboard2, rpi_2, wandboard_dl, wandboard_solo, am335x_boneblack and rpi 2017-04-21 21:37:12 HRio: No idea, are any of them relocated in the new package? 2017-04-21 21:37:37 i dont think thats handled by any package 2017-04-21 21:39:10 the are built e.g. http://nl.alpinelinux.org/alpine/v3.5/main/armhf/u-boot-beagleboard-2016.07-r2.apk but not packaged in the .tar.gz anymore 2017-04-21 21:39:36 Ahh, looks like they were split out to individual packages then. 2017-04-21 21:39:59 right 2017-04-21 21:40:12 Does extracting that new apk result in the expected files? 2017-04-21 21:40:27 the package have the same names in 3.4 TemptorSent 2017-04-21 21:40:35 It likely has a trigger? 2017-04-21 21:42:04 I was a developer for ArchStrike a archlinux based pentest distribution, I see there are some security pkgs being added to alpine 2017-04-21 21:42:12 Hmm, I haven't looked at uboot. 2017-04-21 21:42:37 would it be acceptable to work on adding in more pkgs to alpine that are security-related as apkgbuilds are basically ArchLinux pkgbuilds 2017-04-21 21:42:45 the expected files are in u-boot-beagleboard-2016.07-r2.apk under usr/share/u-boot/am335x_boneblack 2017-04-21 21:44:02 HRio u-boot should use that if installed I would guess. try installing u-boot-all 2017-04-21 21:44:39 arch3y: Keep in mind libc and shell differences. 2017-04-21 21:44:40 in 3.5 that is. for v3.4 the file is u-boot-beagleboard-2015.04-r1.apk and the path is usr/share/u-boot/am335x_boneblack/ so looks same 2017-04-21 21:46:09 but its still a bit unexpected to find an empty u-boot/ dir in alpine-uboot-3.5.2-armhf.tar.gz as its described as "Includes the uboot bootloader" on https://alpinelinux.org/downloads/ 2017-04-21 21:46:45 Hmm, yeah, that part seems off. Possibly a package version issue caught the builder flat-footed? 2017-04-21 21:47:01 yeah it seems like a bug HRio 2017-04-21 21:47:05 definitely not indended 2017-04-21 21:48:02 Yeah, it sounds like the profile was missing a few things perhaps or something was otherwise changed. 2017-04-21 21:48:23 Looks like one of the issues I'll have to make sure I have fixed in the new image building logic. 2017-04-21 21:49:43 Just checked on what I have and it appears it should work, but having not tested it, I'm not going to swear to it. 2017-04-21 21:50:43 http://bugs.alpinelinux.org/issues/7181 created 2017-04-21 21:51:02 I also don't have any u-boot configurator code yet, so if you have thoughts there, I'll gladly add them. 2017-04-21 21:51:46 TemptorSent: understood I plan on building an lxc container and making sure I understand the build process before I work on building stuff 2017-04-21 21:52:16 TemptorSent: Ill play around with alpine locally before I build and focus on maintaining any pkgs 2017-04-21 21:53:31 arch3y: Yeah, but ask here before you start working on anything too much -- I got bit by that after spending a few weeks turning the old iso builder into something useful before finding out it was ancient and had been replaced by mkimage 2017-04-21 21:53:59 TemptorSent: sure understood I will be around here and talking daily 2017-04-21 21:54:07 Cool deal arch3y :) 2017-04-21 21:54:12 I am looking for a new home and very used to maintaining pkgkbuilds 2017-04-21 21:54:43 I'm working on some basic auditing and verification abilities for the installed system. 2017-04-21 21:55:14 TemptorSent & Shiz thanks. time for bed ;-) 2017-04-21 21:55:20 that should be interesting, I am used to compiling most of the pkgs via gcc so I wonder how musl will work 2017-04-21 21:55:54 uhm 2017-04-21 21:55:58 musl also uses gcc? 2017-04-21 21:56:01 or well, alpine does 2017-04-21 21:57:39 my bad still used to the idea havent used alpine at all yet 2017-04-21 21:57:45 but Ill learn quickly 2017-04-21 21:59:15 gcc is the compiler, different from the libc 2017-04-21 21:59:30 musl is the libc, as opposed to e.g. glibc 2017-04-21 22:00:39 gotcha makes more sense apologies for the confusion, I hope to test builds on armv6, armv7 and aarch64 as well as x86_64 and i686 2017-04-21 22:00:48 so it should be an interesting project 2017-04-21 23:38:23 jirutka : Thank you ^^ 2017-04-22 00:52:06 I’ve finished upgrade of LLVM and its components to 4.0.0, replaced main/llvm with main/llvm4 (that provides=llvm) etc. https://github.com/alpinelinux/aports/pull/1261 2017-04-22 00:56:29 nice, good work 2017-04-22 01:50:22 great work ! 2017-04-22 02:25:06 jirutka: really nice work! but why not shipping lld linker? 2017-04-22 03:29:27 hey guys 2017-04-22 03:29:29 allah is doing 2017-04-22 03:29:34 sun is not doing allah is doing 2017-04-22 03:29:38 to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger 2017-04-22 10:17:30 xentec: I don’t know…? 2017-04-22 10:32:32 jirutka: llvm 4.0 ships with lld but I couldn't find it in the llvm4 package 2017-04-22 15:46:11 xentec: I’ve pushed lld to testing 2017-04-22 15:47:02 awesome! 2017-04-22 15:48:16 xentec: please let me know if it actually works 2017-04-22 15:49:31 jirutka: maybe not with linux kernel or gcc ;), but I'm going to link some various packages with it later and run some tests 2017-04-22 17:03:26 can I ask a question not trying to offend here, but is alpine basically arch with openrc instead of systemd and libmusl instead of libc 2017-04-22 17:04:40 no, 2017-04-22 17:04:44 NEXT! 2017-04-22 17:05:31 ok no issue here I respect the ability to build a system from scratch 2017-04-22 17:05:37 wasnt trying to upset ppl 2017-04-22 17:05:56 I know you weren't :) 2017-04-22 17:06:20 k cool can you tell me how its different or is there a wiki link I havent found yet 2017-04-22 17:06:51 I'm the wrong person for this. I just don't understand the fascination with Arch or how it's different from mainstream distros. 2017-04-22 17:07:04 Why it's used as a comparison point, if you will. 2017-04-22 17:07:15 What I do know is that Alpine is its own thing. 2017-04-22 17:07:16 Ive been an arch user for a very long time 2017-04-22 17:07:33 I can see that apline is its own thing, but it definitely takes after arch in some ways 2017-04-22 17:08:08 I am looking to start contributing to alpine, so I was looking at the differences, but as I can tell the biggest hurdle will be libmusl 2017-04-22 17:08:14 in what ways? 2017-04-22 17:08:17 other then that building a pkg is still just a pkgbuild 2017-04-22 17:08:26 well they have apkgbuild as a file 2017-04-22 17:08:26 <_ikke_> arch3y: The first announcement of alpine: http://git.net/ml/linux.leaf.devel/2005-08/msg00039.html 2017-04-22 17:08:44 _ikke_: thanks 2017-04-22 17:09:00 my reasoning wanting to help is becuase it is somewhat similiar to arch 2017-04-22 17:09:19 <_ikke_> The only thing similar is the same kind of way to define how to build a package 2017-04-22 17:09:35 so the biggest difference is its meant to be smaller and pkgs run in memory 2017-04-22 17:09:47 _ikke_: gotcha well that makes it easier to contribute for sure 2017-04-22 17:09:51 <_ikke_> There are a lot of differences 2017-04-22 17:10:08 <_ikke_> There are more differences than similarities 2017-04-22 17:10:23 and its meant to be secure by default 2017-04-22 17:10:31 whereas AL is not Im seeing that now 2017-04-22 17:10:35 <_ikke_> so it's not a good description to describe alpine in terms of archlinux 2017-04-22 17:10:48 <_ikke_> (I'm an avid arch user myself) 2017-04-22 17:11:10 I was just seeing similiarities but you are correct under the hood its very different 2017-04-22 17:11:37 mainly with the way pkgbuilds for each pkg 2017-04-22 17:12:20 I am a former developer of a archlinux based pentest distro, so I was hoping to be able to bring some of those pkgs to alpine if I can 2017-04-22 17:12:48 so I have been reviewing it and working on testing out pkgs and making sure I understand how the system works before I get to far in 2017-04-22 17:12:54 <_ikke_> arch3y: Sure, alpine is pretty receptive for packages 2017-04-22 17:13:23 the main reason I left my former home is because the community was small and the other devs werent inclined to help it grow 2017-04-22 17:13:48 so I hope to help out and contribute a large amount to the growth of alpine once I understand it 2017-04-22 17:15:22 just have to find time to start working on it 2017-04-22 17:34:38 ooh lld, i need to see how well ghc build times go down with that 2017-04-22 21:38:54 arch3y, like our website states, we are small simple and secure. arch philosophy is different. 2017-04-22 21:42:26 some ppl are just unknown about the history of both arch and alpine and confuse about its evolution, you can see it for instance on arch wiki where ppl mention alpine is based on arch (which is completely bs). 2017-04-22 22:12:09 yeah I think tonight Ill take a spare laptop and drop alpine on it 2017-04-22 22:12:36 I do agree arch is not built for security by default, alot of the pkgbuilding ideas are similiar which I do like 2017-04-22 22:15:18 well, a single one, the APKBUILD format 2017-04-22 22:15:20 :P 2017-04-22 22:16:31 is there anything like namcap in apline 2017-04-22 22:16:39 to make sure things are built to standards 2017-04-22 22:17:30 and I assume pkgs are built in clean chroots or that can be accomplished 2017-04-22 22:18:40 it's integrated in abuild itself, kinda 2017-04-22 22:18:56 although probably not as extensive as namcap is 2017-04-22 22:19:25 ok thats good, so it could be a feature added down the road 2017-04-22 22:20:36 i dont think theres proper chroot separation yes, but i agree that it's something desirable 2017-04-22 22:48:37 it would be ideal to install say a base of pkgs needed to build 2017-04-22 22:48:55 then it would insure that each apkgbuild had the correct deps to run a pkg 2017-04-22 23:00:48 Ill find this out for myself ofc, but it alpine meant to be versatile meaning can it be used as a desktop or a server or a media server etc 2017-04-22 23:00:57 yeah 2017-04-22 23:01:04 i ran it on my desktop for a while 2017-04-22 23:01:08 run it on most of my server 2017-04-22 23:01:12 friend uses it on his laptop 2017-04-22 23:01:26 cause I notcied it runs in ram or at least at the start 2017-04-22 23:01:43 Im still a bit confused by that part but I plan on doing an install after I eat so Ill figure it out 2017-04-22 23:01:51 just the livecd runs from ram 2017-04-22 23:01:58 alpine can run from ram, it can also be installed to the hard disk 2017-04-22 23:02:07 setup-alpine will ask you what kind of install you want 2017-04-22 23:02:15 kk 2017-04-22 23:02:40 Ill have to get used to openrc, but I assume pkgbuilders are bringing in init files for each pkg they build 2017-04-22 23:02:53 what do you mean by bringing in? 2017-04-22 23:03:18 well say a person builds a pkg that needs a service file to run 2017-04-22 23:03:37 as in it runs a daemon, that builder is providing the file needed to start the service 2017-04-22 23:04:47 those files are part of aports 2017-04-22 23:04:59 they don't really get used by the builder except for being packaged up 2017-04-22 23:05:05 in the final package file 2017-04-22 23:05:07 :P 2017-04-22 23:05:25 yeah as the apkg is basically a tarball of sorts which is dropped and unpacked on the filesystem once its installed 2017-04-22 23:05:55 so a dude just asked about the alpine iso in the archlinux channel lol 2017-04-22 23:05:57 if you mean apk, it's a bit more than that 2017-04-22 23:06:08 it also has a signature and pre/post-install trigger scripts 2017-04-22 23:06:12 well yeah I dont know all of the details of how pacman works either 2017-04-22 23:06:20 but yeah 2017-04-22 23:06:26 but yeah and the postinstall and checks sigs if needed 2017-04-22 23:06:27 in its base, it's two tarballs 2017-04-22 23:06:31 concat'd together 2017-04-22 23:06:38 control tarball, data tarball 2017-04-22 23:06:42 so like stage1 and stage2 tarballs of gentoo 2017-04-22 23:06:53 cause I remember them saying it was closer to gentoo 2017-04-22 23:07:18 nope 2017-04-22 23:07:31 for one, stage1/2 gentoo tarballs are entire FS images 2017-04-22 23:07:38 and they represent different levels of the build process 2017-04-22 23:07:50 in .apk the control tarball just has the pre/post-install trigger scripts and possibly some other stuff 2017-04-22 23:07:55 while the data tarball gets extracted to / 2017-04-22 23:08:14 understood for a pkg specifically 2017-04-22 23:08:30 I got offtopic 2017-04-22 23:09:08 time to find my charger so I can do an actual install 2017-04-22 23:09:21 :) 2017-04-22 23:10:06 I promise Im not as noob as I sound lol just every variation of linux is a bit different its why we enjoy linux we can make it into whatever we desire 2017-04-22 23:10:58 wasnt assuming anything like that 2017-04-22 23:11:08 and Im assuming any patch files are in ports as well to be applied to a pkg to make it compliant with alpine standards 2017-04-22 23:11:24 nah I know sometimes too many questions can make ppl question a user 2017-04-22 23:11:37 but ask the right questions in a sane manner and its all good 2017-04-22 23:11:47 yeah 2017-04-22 23:11:52 (re: the former) 2017-04-22 23:12:02 all auxiliary files that are not part of the upstream package are stored in aports 2017-04-22 23:12:04 well, within certain limits 2017-04-22 23:12:09 as long as they come from us 2017-04-22 23:12:11 :P 2017-04-22 23:12:17 or are vetted by us, as with some patches 2017-04-22 23:14:36 yeah I mean every patch I apply is to keep things fhs compliant 2017-04-22 23:14:46 so Id think that wouldnt be too big of an issue 2017-04-22 23:15:26 man too many ppl are getting arch and alpine confused they keep joing archlinux and asking a question 2017-04-22 23:15:40 about alpine but its apparent they probably shouldnt be using either in the first place 2017-04-22 23:25:43 sigh... 2017-04-22 23:26:58 just a heads up the isos verify fine 2017-04-22 23:27:28 there definetly some user error, its never fun when a distro gets popular and in comes the ppl who probably shouldnt be using it lol 2017-04-22 23:27:45 but its also a good thing to so its a trade off 2017-04-22 23:27:48 what do you mean "shouldn't be using"? 2017-04-22 23:28:10 well its like how when everyone started installing arch cuase it was popular 2017-04-22 23:28:21 and but they struggle so much they probably should use mint 2017-04-22 23:28:24 or even ubuntu 2017-04-22 23:28:43 eh, i'd like to at least try to welcome everybody 2017-04-22 23:28:48 I think distros like arch, alpine, gentoo, and slack are for advanced users 2017-04-22 23:28:54 it being hard to use is in a lot of cases a bug 2017-04-22 23:28:56 yeah everyone can learn for sure 2017-04-22 23:29:01 i discard notions of 'for advanced users' 2017-04-22 23:29:05 don't like elitism 2017-04-22 23:29:07 :P 2017-04-22 23:29:18 Im not trying to promote elitism 2017-04-22 23:29:38 but sometimes it can be difficult to spend hours helping somone do something like partition a hdd 2017-04-22 23:29:56 is my main point everyone can learn but they need to willing to want to help themselves a bit too 2017-04-22 23:30:04 fair 2017-04-22 23:30:18 (also, good thing setup-disk can and will unless told not to autopartition for you) 2017-04-22 23:30:20 :p 2017-04-22 23:30:34 for sure 2017-04-22 23:31:08 when I was building ArchStrike we added an installer and got alot more users, but we also got ppl that even messed up a click click installer 2017-04-22 23:31:13 so it takes all kinds 2017-04-22 23:56:37 I like the builtin fastest mirror checker into setup-alpine 2017-04-22 23:57:09 ash confused me when it ran it said it was changing mypassword but never prompted me to type it in, I had to hit enter a few times but meh 2017-04-23 00:23:05 I keep wanting to type in apkg not apk 2017-04-23 00:23:13 gonna have to get used to that 2017-04-23 00:28:51 Im guessing /etc/apk/world is updated eachtime a pkg is installed 2017-04-23 00:39:03 yes 2017-04-23 00:39:12 it's the list of packages you explicitly requested for install 2017-04-23 00:39:59 k thought so thats nice for a backup of files 2017-04-23 00:40:08 err backup of pkgs installed 2017-04-23 00:58:59 got everything up but sound, I had to fiddle with the lxdm setup because the instr arent clear enough on insatlling xfce 2017-04-23 00:59:13 I assume I can drop on alsa or pulse which ever I choose 2017-04-23 01:03:27 the wiki docs can be outdated in places, yes 2017-04-23 01:03:38 and the passing recommendation here seems to be to use alsa :p 2017-04-23 01:05:50 yeah I pretty much always use alsa 2017-04-23 01:06:11 yeah wikis do get outdated things are ever changing I just used AL docs to solve it 2017-04-23 01:38:28 got myself oriented with an xfce install for now Ill mess with it more later 2017-04-23 10:13:50 hi there 2017-04-23 10:14:11 my docker image stopped building lately: ERROR: unsatisfiable constraints: so:libcrypto.so.41 (missing): php7-openssl-7.1.3-r1[so:libcrypto.so.41] 2017-04-23 10:14:15 any ideas? :( 2017-04-23 10:23:08 grzes_: php is currently totally messed in alpine, so no wonder… we will fix it until v3.6 2017-04-23 10:50:26 jirutka: when 3.6 release is planned? 2017-04-23 10:50:35 grzes_: next month 2017-04-23 14:57:56 i put build-3-6-armhf builder to stop on fail. this is the list that currently is not able to build. http://tpaste.us/xWKl 2017-04-23 14:59:00 buildlogs are here http://build.alpinelinux.org/buildlogs/build-3-6-armhf/ 2017-04-23 15:43:09 >>> docker: Checking sha512sums... 2017-04-23 15:43:11 docker-17.04.0.tar.gz: FAILED 2017-04-23 15:43:13 huh... 2017-04-23 15:51:12 the mmh build error is also very strange 2017-04-23 15:51:14 > /usr/bin/install -c -g buildoze -m 2755 inc /home/buildozer/aports/community/mmh/pkg/mmh/usr/bin/$cmd; 2017-04-23 15:51:19 > install: unknown group buildoze 2017-04-23 15:51:35 the group is actually called buildozer of cause 2017-04-23 15:52:38 but mmh's configure script figures out this particular group by looking at the group who owns the directories /var/mail, /var/spool/mail, … 2017-04-23 16:44:29 Question regarding keymaps -- is it desired that the initfs be built with the same keymap as the host system? 2017-04-23 16:45:11 the initfs doesnt need a keymap 2017-04-23 16:46:17 There is currently an initfs feature 'keymap' that include files '/etc/keymap/*' 2017-04-23 16:49:24 Should the new version detect the host keymap and install that file from bkeymaps to etc/keymap, or should it instead include all keymaps in /usr/share/bkeymaps and allow a kernel cmdline option to select which one is used? 2017-04-23 16:51:06 The problem is that the old mkinitfs drew files from the running system rather than from packages, so we have no way of knowing what we're getting. 2017-04-23 16:52:17 If a package wasn't installed, it would silently create a bad initfs, so we're now building the initfs directly from packaging + a small handful of external files. 2017-04-23 16:52:43 Leaving things such as the desired behavior of keymaps somewhat ambiguous. 2017-04-23 16:58:19 So, better question: How do we want to deal with host-specific configurations that were previously reflected in the initfs as a side-effect? 2017-04-23 17:05:45 they should be 2017-04-23 17:05:51 like mdadm.conf 2017-04-23 17:14:17 Okay, so something like checking the glob against files in etc. and adding any that match. 2017-04-23 17:14:51 I think we're going to need to tag the globs with a source to keep from turning that into a mess. 2017-04-23 17:15:45 The user config should be kept seperate from the package contents. 2017-04-23 17:17:35 Can you thing of any files outside the /etc structure that we would even want to consider the host versions of over what we get from fresh packages? 2017-04-23 17:17:42 s/thing/think/ 2017-04-23 17:20:09 This is the only remaining mess to clean up for the new mkinitfs/update-kernel to be merged that I'm aware of, the rest is plumbing and bug-smacking. 2017-04-23 17:26:57 Currently, the only globs including /etc are '/etc/mdadm.conf' '/etc/modprobe.d/*.conf' '/etc/mdev.conf' and '/etc/keymaps/*' 2017-04-23 17:28:08 Of those, only mdadm.conf appears to have actual user configuration in normal cases, with the configuration of keymaps by simple inclusion. 2017-04-23 18:15:19 mdev.conf can have user config perfectly fine 2017-04-23 18:15:22 as does modprobe 2017-04-23 18:18:02 Shiz: The question is do we want the user-configured mdev.conf in the initfs, or should it use the packaged version for consistency? 2017-04-23 18:28:10 The existing initramfs-init doesn't seem to actually use mdev for anything but nlplug-findfs, so I guess the requirements of nlplug-findfs should determine the handling of mdev.conf. 2017-04-23 18:29:11 initfs is host system bound. it should reflect some changes from /sysroot. keymap for example should be the same the user set it to. one thing you don't want is beeing logged in initfs as root after an emergency without a fitting keymap. 2017-04-23 18:30:26 And rather than including every file in modprobe.d, each feature should probably include its own module config file globs, and the base include only system configs. 2017-04-23 18:31:41 xentec: Understood -- currently, it only installs the host keymap and no others, so if you have to recover on system with a different keymap, you're SOL. 2017-04-23 18:34:38 xentec: My thought is that either all bkeymaps should be installed in /usr/share/bkeymaps and the current host keymap linked, with a kernel cmdline option to override, or splitting the features out so the keymap is specified by the feature name (keymaps_all or keymap_, respectively.) 2017-04-23 19:41:51 One other issue is what do we do about the "module=" kernel command line options? Add a new config file? 2017-04-23 19:54:14 Why exactly do armhf/aarch64 have a '/etc/modprobe.d/i386.conf' in alpine-baselayout? 2017-04-23 19:58:53 Also, is there any reason not to use the passwd/group that comes with baselayout by default for the initramfs instead of the rather screwball version currently included in /usr/share/mkinitfs? 2017-04-23 20:07:16 I don't know any default passwd/group in *any* distro that doesn't qualify as screwball 2017-04-23 20:07:51 *lol* fair enough, but we could at least not be using one that obviously is setup for gentoo with portage and distcc users :) 2017-04-23 20:08:32 I can agree with that 2017-04-23 20:09:08 What I would personally like to see is a 'master' system set of passwd/group files that defines all the known system users/groups used by any alpine packages, then extract the minimal subset of that needed for the initfs. 2017-04-23 20:09:58 that's bad design: it requires centralization of information 2017-04-23 20:10:03 Or at least a master list of system user/group accounts that could be used to generate skeleton group/passwd/shadow files as needed. 2017-04-23 20:10:12 currently a package that wants to create its own users/groups can do so 2017-04-23 20:10:16 It's required to avoid conflicts with UIDs 2017-04-23 20:10:35 not with dynamic useradd 2017-04-23 20:11:14 For instance, 'shadow' has a group id of '42' which is hardcoded into alpine-baselayout. 2017-04-23 20:11:41 it's normal to have a static base. 2017-04-23 20:12:28 Not static, it's added by 'addgroup -S -g 42 shadow 2>/dev/null' in the .pre-upgrade script. 2017-04-23 20:12:54 static as in static numbers. 2017-04-23 20:13:30 alpine-baselayout can do that. 2017-04-23 20:13:34 app packages should not. 2017-04-23 20:13:49 That seems pretty obvious, doesn't it? 2017-04-23 20:17:24 Let's see.. 'nut' uses UID=84, ceph:UID=167, dovecot:UID=90, dovenull:UID=91, seafile:UID=800 2017-04-23 20:19:00 Oh, and we have GID=82 assigned for www-data in several packages. 2017-04-23 20:20:16 that should either be documented and centralized, or fixed to use dynamic uids. 2017-04-23 20:20:18 netdev:GID=28, avahi:GID=86 2017-04-23 20:20:55 Yeah, I'd go with the documented and centralized for the system accouts below 100 at the very least, if not below 500 2017-04-23 20:21:42 The other big problem is the IIRC the tarballs are stored with numeric UID/GID in several places. 2017-04-23 20:22:31 what tarballs? 2017-04-23 20:23:17 The tarballs of the apks themselves.. I recall seeing a '--numeric-owner' somewhere in the build system. 2017-04-23 20:24:03 Also, obviously having system accounts with different UIDS is a mess in shared environment. 2017-04-23 20:24:14 well tarballs should always be created with --owner=0 --group=0 --numeric-owner 2017-04-23 20:24:59 So, how do you store user info when you have files that must be owned by someone other than root? 2017-04-23 20:25:46 it's rare, but sure, in that case you omit those options 2017-04-23 20:25:57 Or, more pressingly, by a GID other than 0, which is reqired in MANY places. 2017-04-23 20:26:49 it really shouldn't, the habit of using non-root gids everywhere is a dumb redhat idea that everyone copied 2017-04-23 20:27:01 (devices, man, chron, etc.) 2017-04-23 20:27:38 that's utterly idiotic 95% of the time 2017-04-23 20:27:46 No, it's been a standard administrative practices since before I started using unix in the 1980s. 2017-04-23 20:28:01 wheel, tty, mem, etc. 2017-04-23 20:28:13 still useless 2017-04-23 20:28:17 ?? 2017-04-23 20:29:05 You lost me, how is it useless to distinguish groups from the root group for devices/services which may be used by non-root users? 2017-04-23 20:29:11 anyway if you need to include uid/gid info in a tarball, either don't use the --owner/--group option, or have extraction scripts that do the right thing 2017-04-23 20:29:13 And how would setgid ever work? 2017-04-23 20:30:55 I'll gladly teach a Unix design course another day 2017-04-23 20:31:03 Anyway, all that aside, it seems that a minimal consistent passwd/group file should be establish which contains at least all known static assignments for UID/GID. 2017-04-23 20:31:17 skarnet: Teach K&R :) 2017-04-23 20:32:14 you mean the people who decided that ln should do unlink() then link() instead of link() then rename()? yeah, I could teach them. 2017-04-23 20:32:18 And get rid of any that are dynamically assigned. 2017-04-23 20:33:57 *lol* Yeah, I don't LIKE a lot of design decisions in unix, but the fact is that's what we're working with and supporting idiomatic usage is required until we're ready to take on rewriting a lot more than a few config file formats :) 2017-04-23 20:34:42 says the guy rewriting the initramfs :P 2017-04-23 20:34:47 I just want things to not break using the existing idiom wherever possible. 2017-04-23 20:34:58 *grin* Got me there :P 2017-04-23 20:35:53 Of course, that coming from the guy who rewrote most of the primitaves into something sane.... 2017-04-23 20:37:11 Anyway, I'm going to ditch the existing /usr/share/mkinitfs/(passwd|group) in favor of the ones from baselayout. 2017-04-23 20:37:43 check with ncopa/fabled first, but that shouldn't hurt 2017-04-23 20:38:13 Yeah, I'll verify it, but it couldn't possibly be worse than whats there now. 2017-04-23 20:38:36 That just leaves what to do with the /usr/share/mkinitfs/fstab 2017-04-23 20:40:43 The only difference between it, and the one in baselayout is that baselayout omits /dev/fd0 2017-04-23 20:41:28 Which, considering I don't believe we can actually fit on a floppy, is probably correct. 2017-04-23 20:44:29 skarnet: Also, are you aware of /etc/modprobe.d/i386.conf which is installed on armhf/aarch64 as well as x86*, is actually used on those archs? If so, it probably should be renamed, if not, it probably should be removed from baselayout on those archs. 2017-04-23 20:49:16 I have no idea, I'm not involved in the installer at all. Ask the real devs ^^' 2017-04-23 20:57:42 Who's the resident baselayout expert besides ncopa/fabled, who are nearly impossible to catch on it seems. 2017-04-23 21:00:18 on Sunday nights EU time, there's no resident expert. 2017-04-23 21:01:07 (you only caught me because I happened to be there and made the mistake of answering. :P) 2017-04-23 21:02:10 *grin* Sunday is a good day for me to work on Alpine as I don't have anything else I have to do. 2017-04-23 21:04:15 Although now that the weather is getting good, there are other things I *WANT* to do, so I'll probably be out and about rather than at the terminal more than less on weekends soon. 2017-04-23 21:49:01 Where busybox provides a given tool (/usr/sbin/nbd-client for instance) that's also available through a stand alone package (nbd-client for instance), is there any compelling reason to install the independent package by default unless we know BB doesn't actually support the functionality we need? 2017-04-23 21:52:20 In the same vein, is there a reason why busybox doesn't 'provide' such files in a way that is clear from a package-management standpoint (something requires nbd-client, busybox is installed, busybox provides nbd-client and nbd-client package is not installed > use nbd-client from BB) 2017-04-23 21:58:24 because busybox doesn't provide nbd-client 2017-04-23 21:58:28 it provides /usr/sbin/nbd-client 2017-04-23 21:58:37 and that part should be part of its autogenerated deps 2017-04-23 21:58:39 afaik 2017-04-23 21:58:41 err 2017-04-23 21:58:43 autogenerated provides 2017-04-23 21:58:48 just like clang provides /usr/bin/clang 2017-04-23 21:59:40 Okay, where would one find such autogenerated provides and how do I tell apk that I need at least one provider of /usr/sbin/nbd-client installed? 2017-04-23 22:01:41 hmm actually that might only happen for so's 2017-04-23 22:01:52 that would go through for instance 2017-04-23 22:01:55 apk add so:libssl.so.39 2017-04-23 22:02:03 that'll install any package that provides that .so 2017-04-23 22:09:37 Yeah, for the libs I can manage, but the binaries and especially config/aux files are a real problem. 2017-04-23 22:13:27 It might almost make sense to make subpackages for each of BB's toolsets, such as bb-nbd-client, bb-findutils, bb-vi, etc. 2017-04-23 22:14:41 But I think there is an issue that needs to be addressed at a higher level of abstraction in apk to make things work sanely with such deps. 2017-04-24 03:19:14 it may be worth adding file: capabilities for stuff in /usr/bin and so on 2017-04-24 03:30:58 How so? 2017-04-24 04:10:38 so that you can do 2017-04-24 04:10:40 `apk add file:/usr/bin/clang` and it will find it 2017-04-24 04:12:33 ahh, okay, as a type tag. 2017-04-24 04:12:55 That's what I have in the manifest system I'm using currently to make dep tracking sane. 2017-04-24 04:13:48 And something of the sort probably needs to be added to apks in general. 2017-04-24 04:14:19 kaniini: where is the provides info actually stored, i can't find it in the .PKGINFO 2017-04-24 04:14:22 So we can distribute a manifest of files that can ve versioned. 2017-04-24 04:14:46 It's not currently stored in a usable manner that I have found. 2017-04-24 04:15:16 It looks like it's derived by magick in the APKINDEX 2017-04-24 04:16:50 Shiz: it is definitely in .PKGINFO, https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1153 2017-04-24 04:17:12 huh 2017-04-24 04:17:14 kaniini: file info is? 2017-04-24 04:17:30 oh, i was using the wrong .apk 2017-04-24 04:17:31 makes sense 2017-04-24 04:17:35 The only way I can find it is by extracting the pax headers from the .apks. 2017-04-24 04:18:06 TemptorSent: we are talking about capability tags in provides field 2017-04-24 04:18:16 i do not know what you are referring to :P 2017-04-24 04:19:28 Oh, okay -- I was looking at general case 'pkg requires file foo, and bah, bar, and, baz all contain file foo' 2017-04-24 04:20:09 So if you want to tell the difference between the files, you need to tag them with both the package and checksum. 2017-04-24 04:20:57 Then when apk requests an arbitrary file, it will have a list to compare against the current installed tree and dep tree to see if it is a hit or near match for existing packages 2017-04-24 04:21:56 I haven't implemmented the distance heuristics, but I already calculate the entire deptree for every bin and script with a checksum tree for each. 2017-04-24 04:23:21 Unless somehow apk can derrive that during install :) 2017-04-24 04:27:20 Um, I think we can do much better very shortly. 2017-04-24 11:13:52 <_ikke_> looks like rsync.a.o is down 2017-04-24 11:14:11 yes it is 2017-04-24 11:14:22 <_ikke_> (I'm monitoring it :-) ) 2017-04-24 11:14:23 hold on to your seats please 2017-04-24 11:14:30 <_ikke_> np 2017-04-24 11:14:31 we are going for a joyride 2017-04-24 11:14:50 ACTION grabs the popcorn. 2017-04-24 11:14:52 we are going to increase it with 150 Horse power 2017-04-24 11:17:39 and scaleway has a nice way of allowing you to attache additonal volumes, we have to wait for some time. 2017-04-24 11:23:46 How big is the alpine package repo? 2017-04-24 11:27:22 depends 2017-04-24 11:27:36 only packages is less 2017-04-24 11:27:41 we also have releases 2017-04-24 11:27:47 and its not all we got 2017-04-24 11:28:00 right now is it in the order of: 1g? 5g? 10g? 50g? 2017-04-24 11:28:35 x10 2017-04-24 11:36:58 small simple secure gets pretty large over time :) 2017-04-24 11:40:26 the important thing is that it's possible to only strictly install what you need 2017-04-24 11:40:45 the size of the entire package database is irrelevant 2017-04-24 11:41:36 It is when you need to distribute it. 2017-04-24 11:42:20 but thats not a user problem. 2017-04-24 11:42:23 indeed. 2017-04-24 11:43:32 <^7heo> moin 2017-04-24 11:49:22 yeah, I was idly curious how much space it would take to mirror it 2017-04-24 11:52:02 apk fetch $(apk info) && du -sh 2017-04-24 11:52:35 that would only get it for the current release. There are 3? 4? "current" ones 2017-04-24 11:52:44 or you parse all sizes from $(apk info) 2017-04-24 11:53:52 fill your repofile with all versions and then parse apk info -s 2017-04-24 12:37:51 ncopa: hi 2017-04-24 12:38:42 ncopa: I am trying to compile grub for ppc64le but it is failing. The problem is that grub is compiled in 32 bits mode for ppc64le but seems that Alpine gcc does not have support to compile for 32 bits (it shows --disable-multilib). Any idea of what I can do? 2017-04-24 12:43:27 rdutra, isnt that only a problem for bios build? 2017-04-24 12:43:45 iirc 2017-04-24 12:47:10 clandmeter: well, if I understood the grub build correctly for x86_64 it builds "bios" and "efi" configurations but for ppc64le the valid configuration is "ieee1275" 2017-04-24 12:47:53 right, for aarch64 i build it only for efi 2017-04-24 12:48:02 im not sure about ppc though 2017-04-24 12:48:34 clandmeter: yes, it uses --with-platform=efi, right? 2017-04-24 12:49:03 yes 2017-04-24 12:49:18 if you need another platform you can add your own. 2017-04-24 12:50:15 clandmeter: looking the configure file, for ppc64le needs --with-platform=ieee1275 2017-04-24 12:50:24 but for ppc64le the grub compile for 32 bits and it is failing with Alpine gcc 2017-04-24 12:50:37 ah you already added that 2017-04-24 12:51:10 clandmeter: yes, it is failing after I add the correct --with-platform parameter 2017-04-24 13:22:34 rdutra: how does that work? is it just called with -m32? 2017-04-24 13:22:50 i suppose the correct thing to do there is have a proper crosscompiler 2017-04-24 13:22:54 for 32bit 2017-04-24 13:23:21 there is a similar situation for xen on x86_64 2017-04-24 13:23:25 hvmloader is 32bit 2017-04-24 13:23:46 the problem there was that it pulled in the system libc headers 2017-04-24 13:23:58 so stdint.h got painfully wrong 2017-04-24 13:24:24 on glibc it does not happen because they support 32bit mode 2017-04-24 13:24:58 ncopa: the CFLAGS variable in configure has the -m32 and in config.log I see the error: error: -m32 not supported in this configuration 2017-04-24 13:25:10 ncopa: yes, glibc has 32 bit mode 2017-04-24 13:27:39 ncopa: regarding the xen on x86_64, you mean the --target flag in its configure? 2017-04-24 13:28:27 no 2017-04-24 13:28:42 the makefile for hvmloader adds -m32 to gcc 2017-04-24 13:28:52 ah, ok 2017-04-24 13:29:35 hm, I don't understand. stdint.h must have the right types for both 32/64bit. 2017-04-24 13:30:22 royger they dont with musl 2017-04-24 13:30:26 musl does not support that 2017-04-24 13:31:14 ncopa: what you mean with "have a proper crosscompiler for 32 bit"? 2017-04-24 13:31:35 hm, really? that's kind of weird. musl only supports 64bits? 2017-04-24 13:33:19 do you install a different stdint.h depending on whether it's 32/64bits? because that's very weird. A proper stdint.h file should be done using the __LP64__ define, and should be the same for 32/64 bits 2017-04-24 13:34:26 I can understand that musl doesn't support linking a 32bit binary against a 64bit libc, but the headers should work fine 2017-04-24 13:34:34 they dont 2017-04-24 13:34:40 i talked with dalias about it 2017-04-24 13:34:44 and they will not support it 2017-04-24 13:34:56 the "proper" way is to crosscompile the libc (headers) 2017-04-24 13:35:08 and install them in different location 2017-04-24 13:35:21 and append -I /usr/location/include 2017-04-24 13:35:40 i think xen also does cross compile of newlibc 2017-04-24 13:35:47 in the xen case i was able to work around it 2017-04-24 13:35:52 with a hack 2017-04-24 13:35:57 ncopa: yes, that's another can of worms. 2017-04-24 13:36:16 but the headers thing, well, I will better not comment about it. 2017-04-24 13:36:34 talk with dalias about it 2017-04-24 13:37:09 the problem with -m32 and support "multilib" is that you cannot guarantee that nay other libs (headers) support it 2017-04-24 13:37:57 ncopa: regarding the xen case, where you did the hack? in the APKBUILD file itself or some other place? 2017-04-24 13:38:04 yes, but that should be a link-time issue, not a compile time one 2017-04-24 13:38:07 the way it coudl be fixed would be to install 32bit headrs at different location and patch gcc to replace the -I /path/to/ when -m32 is specified 2017-04-24 13:38:19 well, yes, compiletime too 2017-04-24 13:38:31 ncopa: Does that also imply that no x32 support is forthcoming? 2017-04-24 13:38:40 since the headers need have support for multilib too 2017-04-24 13:38:44 (in theory) 2017-04-24 13:38:55 i suspect in most cases it just happens to work 2017-04-24 13:39:03 because the headeres does not do anything funky 2017-04-24 13:39:09 in the hvmloader case for example, this is a standalone kernel. It's not going to link against anything 2017-04-24 13:39:10 but there is no guarantee for it 2017-04-24 13:39:29 which is why my hack works (worked) 2017-04-24 13:39:36 (one could argue that then has no business using the libc headers...) 2017-04-24 13:39:55 exactly 2017-04-24 13:40:08 it shouldnt 2017-04-24 13:40:48 but come one, it's just int types... 2017-04-24 13:40:53 rdutra: what i did was replace #include with #include 2017-04-24 13:41:11 and just provided the needed inttypes 2017-04-24 13:41:38 royger: yes, so its trivial to provide a int types header for hvmloader 2017-04-24 13:42:10 but musl sees it from libc POV 2017-04-24 13:43:21 oh, libc guys, they are just like compiler guys... 2017-04-24 13:44:08 anyway, I'm quite sure upstream would be have to remove stdint.h inclusion and simply provide the typedefs for uint* whatever that hvmloader needs 2017-04-24 13:44:22 s/have/happy/ 2017-04-24 13:50:26 ncopa: Do you have any particular attachment to the passwd/group/fstab files in /usr/share/mkinitfs? Any objections to taking the defaults from alpine-baselayout directly instead? 2017-04-24 13:52:36 royger: you can look at the patch in aports/main/xen 2017-04-24 13:52:41 i suppsoe i should have upstreamed it 2017-04-24 13:52:49 but i think it needs a bit cleanup 2017-04-24 15:49:45 <_ikke_> rsync.a.o is up again? 2017-04-24 15:50:21 <_ikke_> just not http yet 2017-04-24 15:51:31 now it is 2017-04-24 15:51:43 do you guys have any docs on a developers workflow? I did see on the docs about contributing and you submit pkgs and fixes via git commits via email 2017-04-24 15:52:10 <_ikke_> arch3y: You can also submit pull requests through github 2017-04-24 15:52:23 <^7heo> arch3y: docs aren't the only problem we have atm; but yeah there are three different ways to contribute 2017-04-24 15:52:27 <^7heo> arch3y: 1. gh 2017-04-24 15:52:33 <^7heo> arch3y: 2. ML 2017-04-24 15:52:39 <^7heo> arch3y: 3. patchwork 2017-04-24 15:52:40 yeah gh is fine too 2017-04-24 15:52:52 yeah docs can ben a problem to develop and keep up to date 2017-04-24 15:53:04 <^7heo> especially when you only have a mediawiki 2017-04-24 15:53:17 I am still figuring out how abuild works and how APKG are structured Im used to pkgbuilds so its similiar but a bit different 2017-04-24 15:53:26 yeah for mediawiki is a bitch to maintain 2017-04-24 15:53:34 <^7heo> and contributors (like me) don't want to have to use firefox every time they want to do a small update in the docs 2017-04-24 15:53:42 it makes you miss hthe days of markdown 2017-04-24 15:53:56 <^7heo> mediawiki is actually older than markdown... 2017-04-24 15:54:00 yeah cant lynx handle it if all you want it text 2017-04-24 15:54:09 yeah I know that but I just meant markdown format is nice to use 2017-04-24 15:54:21 <^7heo> sure 2017-04-24 15:54:28 <^7heo> anything is nicer to use than mediawiki. 2017-04-24 15:54:38 <^7heo> I'd even write my doc in perl using XML only than use mediawiki 2017-04-24 15:54:43 yeah well sometimes the overhead of a db is not needed 2017-04-24 15:54:51 <^7heo> It's not the DB 2017-04-24 15:54:55 but its the most common 2017-04-24 15:55:03 <^7heo> I don't care how it works under the hood 2017-04-24 15:55:07 <^7heo> it's more about the UI/UX 2017-04-24 15:55:13 ah gotcha 2017-04-24 15:55:51 <^7heo> having to click in the most annoying website ever to get what I want after my brain works full power for seconds at a time to find the "logic" in that mess... 2017-04-24 15:56:00 we had ours built in laravel and we just pushed md files via git 2017-04-24 15:56:07 it was alot simpler and still looked nice 2017-04-24 15:56:36 <^7heo> and finally get a tiny-timsy little microsoft-eula-formatted textarea in which I have to edit gigantic amounts of text... 2017-04-24 15:57:02 <^7heo> yeah the main issue that is brought up every time is the conversion 2017-04-24 15:57:09 <^7heo> from markdown or asciidoc to whatever. 2017-04-24 15:57:24 <^7heo> at least github is doing that automatically 2017-04-24 15:57:31 yeah true true 2017-04-24 15:57:36 <^7heo> so for now we have docs (unofficial atm) on github 2017-04-24 15:57:46 <^7heo> https://github.com/adocs/adocs 2017-04-24 15:57:49 <^7heo> but... 2017-04-24 15:57:52 <^7heo> it's mostly empty. 2017-04-24 15:57:56 gotcha 2017-04-24 15:58:03 <^7heo> I want to make a bot that mirrors the media wiki there... 2017-04-24 15:58:05 <^7heo> no time yet. 2017-04-24 15:58:30 do you guys want sqaushed commits as well so the history stays quiet 2017-04-24 15:58:40 <^7heo> it's better squashed yes. 2017-04-24 15:58:50 <^7heo> usually, people contribute in aports 2017-04-24 15:58:58 yeah thats my plan 2017-04-24 15:59:04 <^7heo> and in this repo the rule of thumb is: 'one aport, one commit' 2017-04-24 15:59:08 yep 2017-04-24 15:59:14 always 2017-04-24 15:59:19 never anymore then that 2017-04-24 15:59:19 <^7heo> ofc you can rework your stuff after it's comitted 2017-04-24 15:59:30 <^7heo> in a subsequent commit 2017-04-24 15:59:41 yeah how does the build system pick it up 2017-04-24 15:59:53 every pkg goes in testing first 2017-04-24 15:59:55 <^7heo> but usually it's not a good thing to cut features in too many commits. 2017-04-24 16:00:13 yeah Im of the mind to not commit anything until I have it working 2017-04-24 16:00:21 <^7heo> on gh, packages are built in travis; and if they fail the PR is marked as failing 2017-04-24 16:00:24 then I commit deps first before I commit the main pkg 2017-04-24 16:00:31 <^7heo> then if they suceeded, the PR is merged in 2017-04-24 16:00:31 yeah I remember reading about that 2017-04-24 16:00:41 makes sense 2017-04-24 16:00:44 <^7heo> and if merged in, they are built by our builders 2017-04-24 16:00:52 <^7heo> and eventually end up on the repos 2017-04-24 16:01:06 but they need to be put into testing first 2017-04-24 16:01:11 <^7heo> different repos just mean different care in maintaining packages 2017-04-24 16:01:17 and after proper built and signoff they go into main 2017-04-24 16:01:25 <^7heo> main == extra care, stuff there MUST work and be maintained 2017-04-24 16:01:26 or core I forget which ones there are 2017-04-24 16:01:37 <^7heo> community == yeah it's supposed to work 2017-04-24 16:01:54 <^7heo> testing == well, it should work, but if it breaks, you get to keep both parts. 2017-04-24 16:02:06 <^7heo> usually new packages start in testing 2017-04-24 16:02:19 <^7heo> and after a time of them not being an integration problem with others 2017-04-24 16:02:25 <^7heo> they might be moved to community 2017-04-24 16:02:34 <^7heo> and eventually to main if they are important 2017-04-24 16:02:34 yeah my plan would be put any libs I need for the pkg in testing then move it into main or wherever you guys want it 2017-04-24 16:02:44 <^7heo> well 2017-04-24 16:02:48 yeah well a few of these are libs 2017-04-24 16:02:57 <^7heo> about libs, it really depends 2017-04-24 16:02:59 community repo is mostly maintained by maintainers not developers (developers commit the changes on the maintainer's behalf) 2017-04-24 16:03:09 <^7heo> true also 2017-04-24 16:03:26 k just want to make sure that I commit to the correct place 2017-04-24 16:03:31 main is largely maintained by developers (although it is possible to send patches for consideration) 2017-04-24 16:03:33 so I dont make a mess of things 2017-04-24 16:03:36 <^7heo> arch3y: commit to testing 2017-04-24 16:03:51 thats my plan 2017-04-24 16:03:53 <^7heo> arch3y: if wrong, you can always `git mv` and `git amend` in the PR. 2017-04-24 16:03:59 <^7heo> arch3y: you'll see comments then. 2017-04-24 16:04:08 yeah Ive never used amend 2017-04-24 16:04:15 but Im familiar with mv obvs 2017-04-24 16:04:17 <^7heo> it's normally git commit --amend 2017-04-24 16:04:27 ah gotcha to add comments why it was moved 2017-04-24 16:04:36 <^7heo> but I have an alias everywhere for `git amend` to call `git commit --amend` 2017-04-24 16:04:40 <^7heo> because I do it quite a lot. 2017-04-24 16:04:43 <^7heo> so... 2017-04-24 16:04:58 yeah makes sense aliaes are life 2017-04-24 16:05:22 <^7heo> depending on your workflow, but yeah typing less commands == coding more ;) 2017-04-24 16:05:32 <^7heo> moin skarnet 2017-04-24 16:05:35 I was looking at libcli as it in unmaintained but needed by the pkg Im adding 2017-04-24 16:05:46 so Ill have to work on fixing it or trying to at least 2017-04-24 16:05:49 <^7heo> well then try to take it from unmaintained 2017-04-24 16:05:56 <^7heo> then `abuild -r` it locally 2017-04-24 16:06:05 <^7heo> and when you actually get an .apk out of it, git push. 2017-04-24 16:06:08 <^7heo> and open a PR 2017-04-24 16:06:37 but all I should ever push is the APKBUILD and any necesary patches correct 2017-04-24 16:06:58 sounds good Ill fork tonight from github and submit a few prs 2017-04-24 16:07:02 yes 2017-04-24 16:07:55 do you guys have a gitignore setup in aports or is it just implied that someone wont commit more then necesary 2017-04-24 16:08:09 Im always careful when I commit, but I know ppl who love to use -a 2017-04-24 16:08:27 <^7heo> arch3y: it's implied that people don't add shit in their indexes :D 2017-04-24 16:08:38 <^7heo> just don't use -a 2017-04-24 16:08:38 good good 2017-04-24 16:08:39 there is a .gitignore iirc, but ^ 2017-04-24 16:08:43 yeah I never do 2017-04-24 16:08:59 <^7heo> the same as "don't use the master branch for all your fixes" 2017-04-24 16:09:04 <^7heo> master == release 2017-04-24 16:09:16 <^7heo> git has branches for a reason ;) 2017-04-24 16:09:20 I always got mad cuase I worked with other devs who did and they built a massive gitignore 2017-04-24 16:09:29 <^7heo> pricks also code. 2017-04-24 16:09:35 <^7heo> that's a problem; but what can you do... 2017-04-24 16:09:49 true so each fix or patch should be its own branch and then submitted as a pr 2017-04-24 16:10:02 <^7heo> that's what I do. 2017-04-24 16:10:12 k thats doable 2017-04-24 16:10:18 <^7heo> ofc in aports, since a merged PR is a release 2017-04-24 16:10:29 <^7heo> then you open a PR from your branch to the aports master. 2017-04-24 16:10:35 yeah 2017-04-24 16:10:42 thats how I would do it 2017-04-24 16:10:45 <^7heo> yeah 2017-04-24 16:10:56 <^7heo> and locally it's your own stuff. 2017-04-24 16:11:02 <^7heo> you can do mess it up if you want ;) 2017-04-24 16:11:06 <^7heo> but I wouldn't recommend that. 2017-04-24 16:11:07 I did run into an issue with abuild that I was trying to solve 2017-04-24 16:11:15 <^7heo> we need good maintainers, not messes ;) 2017-04-24 16:11:19 nah I try to follow strict workflows and be clean as possible 2017-04-24 16:11:30 <^7heo> :+1: 2017-04-24 16:11:31 well I come from a long line of maintaining AL pkgbuilds 2017-04-24 16:11:43 so I know all about trying to stay clean and work out issues 2017-04-24 16:11:52 <^7heo> Gut gut. 2017-04-24 16:12:02 <^7heo> Let's see that in practice ;) 2017-04-24 16:12:24 I may need some leeway while I learn the processes you guys have 2017-04-24 16:12:34 but once I figure it out Ill be good to go 2017-04-24 16:12:57 <^7heo> we usually don't bark at interested newcomers. 2017-04-24 16:13:08 <^7heo> I mean, I used to; especially people with "arch" in their nick... 2017-04-24 16:13:15 <^7heo> but I try to be nicer. 2017-04-24 16:13:35 lol I understand I used to as well 2017-04-24 16:13:54 but luckily Im not someone who has never maintained it before and yes I do love Arch 2017-04-24 16:14:06 <^7heo> yeah let's not talk about arch, we're gonna fight. 2017-04-24 16:14:17 but Id like to see where you guys go and it will be fun to be on the ground floor of something 2017-04-24 16:14:21 sure we wont 2017-04-24 16:14:27 <^7heo> but anyhooo 2017-04-24 16:14:35 <^7heo> have fun PR'ing ;) 2017-04-24 16:14:55 yep I actually have a question about abuild 2017-04-24 16:15:12 when building libcli it complains about how the src is named 2017-04-24 16:15:32 why do we not want the src to match the github version 2017-04-24 16:15:52 <^7heo> can you please pastebin something? 2017-04-24 16:16:01 <^7heo> so I see what you mean? 2017-04-24 16:16:06 one sec 2017-04-24 16:17:50 https://pastebin.com/PfTueJJu ^7heo 2017-04-24 16:18:04 I can paste the apkbuild as well if needed 2017-04-24 16:18:07 <^7heo> yeah one sec 2017-04-24 16:18:11 <^7heo> I need to plug my laptop 2017-04-24 16:18:57 sure no worries I get the fix rename the tarball that is downloaded 2017-04-24 16:18:58 <^7heo> ok back 2017-04-24 16:19:51 <^7heo> arch3y: ok 2017-04-24 16:20:09 yep Im here 2017-04-24 16:20:19 <^7heo> arch3y: so that's because your downloaded file is named 'v${pkgver}.tar.gz' 2017-04-24 16:20:34 arch3y: ^7heo: no, don’t squash commits, unless told to 2017-04-24 16:20:37 <^7heo> while it's supposed to be named '$pkgname-$pkgver.tar.gz' 2017-04-24 16:20:45 kk 2017-04-24 16:20:49 thats an easy fix 2017-04-24 16:20:50 <^7heo> jirutka: wait wat? 2017-04-24 16:20:56 <^7heo> arch3y: wait 2017-04-24 16:21:00 arch3y: if commits needs to be squashed, the committer can do it 2017-04-24 16:21:14 <^7heo> jirutka: there's a flag on github to avoid comitters from changing the PR. 2017-04-24 16:21:23 <^7heo> jirutka: or do you mean something else? 2017-04-24 16:21:24 ^7heo: ? 2017-04-24 16:21:35 ^7heo: we don’t push via GH interface 2017-04-24 16:21:38 <^7heo> jirutka: I'm not sure what you mean; but I get your point. 2017-04-24 16:21:44 <^7heo> jirutka: right. 2017-04-24 16:21:51 <^7heo> jirutka: then please ignore what I said. 2017-04-24 16:21:54 will do 2017-04-24 16:22:01 <^7heo> arch3y: long story short 2017-04-24 16:22:14 I can fix libcli without an issue, Ill pull the other patch file I made for a different project 2017-04-24 16:22:17 <^7heo> arch3y: what did you fix your 'needs to be renamed' problem? 2017-04-24 16:22:43 ^7heo: oh I just did source=$pkgname-$pkgver.tar.gz::urltosource 2017-04-24 16:22:58 to change the way the pkg is downloaded 2017-04-24 16:23:09 ^7heo: commits go to the primary repository at git.a.o, then synced to GH; we just git am patches from PRs to the master and rebase/squash/whatever if needed, that’s why we use https://github.com/jirutka/github-pr-closer :) 2017-04-24 16:23:29 <^7heo> arch3y: ok fine 2017-04-24 16:23:38 <^7heo> arch3y: that's the right fix; I wasn't sure what you went for. 2017-04-24 16:24:00 ^7heo: yeah no worries 2017-04-24 16:24:06 <^7heo> jirutka: I see. 2017-04-24 16:24:12 I have the patch for liblci as well so itll be fixed in a moment 2017-04-24 16:25:46 I had to patch for gcc >5.2 2017-04-24 16:26:03 do you guys have any issues with sed statements in a prepare func 2017-04-24 16:26:11 or does it need to be an actual patch file 2017-04-24 16:26:20 this was a simple one line fix 2017-04-24 16:26:41 <^7heo> arch3y: usually people don't make a prepare function. 2017-04-24 16:26:49 <^7heo> arch3y: we just name the file .patch 2017-04-24 16:26:53 <^7heo> and it's automatically patched. 2017-04-24 16:26:57 ok well this had a prepare 2017-04-24 16:27:10 <^7heo> probably why it was in unmaintained/ 2017-04-24 16:27:11 how does it get automatically patch without calling patch -i 2017-04-24 16:27:29 <^7heo> (lots of APKBUILDs of questionnable quality have been moved to unmaintained/) 2017-04-24 16:27:35 it was a simple one line fix though, I will look at other examples 2017-04-24 16:27:42 yeah I have seen alot of questionable stuff 2017-04-24 16:27:49 like ppl doing make || return 1 2017-04-24 16:27:55 its ugly lol 2017-04-24 16:27:57 <^7heo> that actually was the case until recently. 2017-04-24 16:28:07 <^7heo> because we didn't run the abuild with set -e 2017-04-24 16:28:10 arch3y: see default_prepare in /usr/bin/abuild 2017-04-24 16:28:17 jirutka: will do 2017-04-24 16:28:23 arch3y: there is code handling patches 2017-04-24 16:28:28 jirutka: thats cool 2017-04-24 16:28:39 thats a cool feature to have 2017-04-24 16:29:07 <^7heo> arch3y: but anyway, long story short, the || return 1 was a requirement until a few weeks ago. 2017-04-24 16:29:14 gotcha 2017-04-24 16:29:18 well Im glad that has changed 2017-04-24 16:29:27 <^7heo> arch3y: so even if it's ugly, it's not what I referred to with "questionable quality" ;) 2017-04-24 16:29:33 thanks to the devs for fixing it 2017-04-24 16:29:46 ^7heo: makes sense 2017-04-24 16:30:19 I really have to stop typing PKG and type APK lol darn muscle memory 2017-04-24 16:30:53 is there anything like namcap for the binaries to scan for missing deps 2017-04-24 16:30:55 <^7heo> I bet you can make your shell/vi correct it. 2017-04-24 16:31:07 for sure especially on my alpine box 2017-04-24 16:31:30 <^7heo> arch3y: what do you mean? missing build deps? 2017-04-24 16:31:35 <^7heo> arch3y: or missing runtime deps? 2017-04-24 16:32:05 runtime deps 2017-04-24 16:32:14 <^7heo> they are automatically computed. 2017-04-24 16:32:57 k let me paste the messy apkbuild 2017-04-24 16:32:59 if I may 2017-04-24 16:33:02 <^7heo> ofc. 2017-04-24 16:35:41 ^7heo: http://dpaste.com/27HS29S 2017-04-24 16:35:58 Im going to clean it up a bit more and change maintainer and move the prepare to a patch file 2017-04-24 16:36:08 <^7heo> Wow, it's full of html 2017-04-24 16:36:26 remove the empty vars, they're useless 2017-04-24 16:36:28 :p 2017-04-24 16:36:34 Shiz: yeah I was going to for sure 2017-04-24 16:36:40 I hate wasted space 2017-04-24 16:36:44 <^7heo> with pastebin I knew how to access the /raw/ 2017-04-24 16:36:48 <^7heo> but with dpaste... 2017-04-24 16:36:52 I just wanted to make sure I was removing the right onces 2017-04-24 16:36:56 just add .txt, ^7heo 2017-04-24 16:37:10 pastebin threw off captcha 2017-04-24 16:37:16 so was like screw this lol 2017-04-24 16:37:18 <^7heo> Shiz: gosh 2017-04-24 16:37:21 <^7heo> Shiz: "logical" 2017-04-24 16:37:26 makes sense to me 2017-04-24 16:37:32 unexpand ;) 2017-04-24 16:37:34 <^7heo> not to me. 2017-04-24 16:37:44 <^7heo> it's /raw/ on pastebin 2017-04-24 16:37:49 <^7heo> it's /plain/ on other bins 2017-04-24 16:37:52 <^7heo> sometimes /text/ 2017-04-24 16:38:02 <^7heo> sometimes it's another subdomain 2017-04-24 16:38:09 <^7heo> sometimes an HTTP header... 2017-04-24 16:38:11 <^7heo> I mean wtf. 2017-04-24 16:39:04 apologies for causing confusion I could of used an encrypted pastebin luckily I decided not too 2017-04-24 16:39:17 lol 2017-04-24 16:39:32 arch3y, try unexpand APKBUILD > APKBUILD.new 2017-04-24 16:39:46 do I have to call cd $srcdir or can I call $pkgname-$pkgver directory 2017-04-24 16:39:48 clandmeter: sure 2017-04-24 16:40:18 k done 2017-04-24 16:40:34 <^7heo> unexpand, the natural enemy of python developers. 2017-04-24 16:40:39 what does unexpand do might I ask 2017-04-24 16:40:46 <^7heo> soft tabs to hard tabs. 2017-04-24 16:40:48 Ive never seen it before 2017-04-24 16:40:49 gotcha 2017-04-24 16:40:59 you learn new stuff everyday Isee 2017-04-24 16:41:01 its nice when you do a lot of copy pasta 2017-04-24 16:41:10 <^7heo> I don't know. 2017-04-24 16:41:12 yeah thats true Ill have to remember that 2017-04-24 16:41:14 thanks clandmeter 2017-04-24 16:41:14 <^7heo> I like to use it only at the end. 2017-04-24 16:41:27 why would it be a natural enemy of python devs 2017-04-24 16:41:31 python works with hard tabs just fine 2017-04-24 16:41:47 <^7heo> Shiz: trolls happen on -offtopic and you know it ;) 2017-04-24 16:41:54 but this is -devel 2017-04-24 16:41:55 :p 2017-04-24 16:42:06 <^7heo> indeed it is ;) 2017-04-24 16:44:46 so I see the subpackage param is that for split pkgs 2017-04-24 16:45:01 or do you guys support split pkgs in one apkbuild file 2017-04-24 16:48:17 is there a flag I can pass to abuild so that it wont clean up my pkg and src dir 2017-04-24 16:48:35 I like to keep it handy in case I need to look at the layout of the pkgdir on the disk 2017-04-24 16:49:11 ah I see -K should do what I want 2017-04-24 16:50:40 cehck abuild.conf 2017-04-24 16:50:52 k thanks will do 2017-04-24 16:51:14 do I need to add my patch file in the src line inorder for abuild to see it 2017-04-24 16:51:24 yes 2017-04-24 16:51:31 all files need to go inside of it 2017-04-24 16:51:51 k thought so 2017-04-24 16:52:04 then it run checksum to gen sums for all files 2017-04-24 16:52:10 right 2017-04-24 16:52:37 roger that 2017-04-24 16:52:41 you just raised one level in apkingdom 2017-04-24 16:53:19 <^7heo> now you can use a wooden sword. 2017-04-24 16:53:26 oh Im just getting started lol 2017-04-24 16:53:44 <^7heo> sounds like someone spent too much time on dotarch. 2017-04-24 16:53:45 I used to maintain most of the pkgs for archstrike, so Im quite familiar with the processes 2017-04-24 16:53:51 lol yrs 2017-04-24 16:53:52 <^7heo> ACTION hides 2017-04-24 16:54:14 nah I like this community its a bit different but its fresh 2017-04-24 16:54:22 and you guys are open to ppl helping out 2017-04-24 16:54:30 <^7heo> depends 2017-04-24 16:54:32 I did mess up my source line 2017-04-24 16:54:35 true 2017-04-24 16:54:44 but you are open to the idea 2017-04-24 16:54:49 until they screw you over lol 2017-04-24 16:54:52 if you use the s word ppl start to be less friendly 2017-04-24 16:54:56 <^7heo> on the day, on my hunger, on my recent exprience with arch-related people, etc. 2017-04-24 16:55:23 well Ill do my best to not offend and be friendly 2017-04-24 16:55:28 <^7heo> < arch3y> but you are open to the idea 2017-04-24 16:55:28 <^7heo> arch3y> until they screw you over 2017-04-24 16:55:31 <^7heo> Exactly. 2017-04-24 16:55:55 <^7heo> But heh for some reason I didn't bark yet while you have arch in your nick. 2017-04-24 16:55:56 and I completely understand you have to be hard on ppl to maintain the intergrity of your system 2017-04-24 16:56:03 <^7heo> So it must be one of my good days. 2017-04-24 16:56:07 well Im competent thats the problem lol 2017-04-24 16:56:11 probably so 2017-04-24 16:56:26 <^7heo> let's hope you are as competent as advertized. 2017-04-24 16:56:30 <^7heo> and no harm will be done ;) 2017-04-24 16:56:42 ^7heo: You must have eaten recently ;) 2017-04-24 16:56:48 <^7heo> TemptorSent: I have indeed. 2017-04-24 16:56:50 how can you measure competence? 2017-04-24 16:56:57 well I guess you cant really 2017-04-24 16:57:06 but all you can do is show in your work and demeanor 2017-04-24 16:57:13 <^7heo> clandmeter: in terms of bugfixes/features. 2017-04-24 16:57:14 that you will work hard and put in effort 2017-04-24 16:57:14 generally, the more competent, the less verbose in IRC. :P 2017-04-24 16:57:25 ouch lol 2017-04-24 16:57:27 haha 2017-04-24 16:57:31 <^7heo> skarnet: indeed. 2017-04-24 16:57:32 ^7heo ^ 2017-04-24 16:57:32 but makes sense 2017-04-24 16:57:37 <^7heo> clandmeter: wat? 2017-04-24 16:57:41 <^7heo> clandmeter: you were on IRC all day... 2017-04-24 16:58:21 arch3y: subpckages= is for split packages, yes 2017-04-24 16:58:29 Shiz: thanks 2017-04-24 16:58:46 I guess the go to for splits would -doc pkgs 2017-04-24 16:59:02 a function according to the subpackage name (or a different one delimited with colon) gets invoked to move the files from the main package dir to the subpkgdir 2017-04-24 16:59:04 yeah 2017-04-24 16:59:11 abuild has a default doc() that you usually don't need to override 2017-04-24 16:59:17 it automatically moves manpages out of the way 2017-04-24 16:59:23 (if you have $pkgname-doc in your subpackages) 2017-04-24 16:59:49 ah nice 2017-04-24 16:59:53 thats good to know 2017-04-24 17:00:06 there's also a default dev() afaik 2017-04-24 17:00:06 Im used to havng to split it by hand 2017-04-24 17:00:11 for header files and static libraries 2017-04-24 17:00:28 trying to get it to see my patch file now 2017-04-24 17:00:48 add it to sources= 2017-04-24 17:01:01 just the filename if it's in the same dir as the APKBUILD 2017-04-24 17:01:02 I did but it needs to be one per line 2017-04-24 17:01:05 yeah it is 2017-04-24 17:01:06 not per line 2017-04-24 17:01:12 it's just split using standard shell splitting afaik 2017-04-24 17:01:16 so more like split by whitespace 2017-04-24 17:01:39 k 2017-04-24 17:01:55 but adding it to sources= and running # abuild checksum should make it work 2017-04-24 17:02:04 if you override prepare(), be sure to call default_prepare() in your overridden function 2017-04-24 17:02:09 no I see my problem 2017-04-24 17:02:11 I cant type 2017-04-24 17:02:27 ah you fit right in 2017-04-24 17:02:30 fixed 2017-04-24 17:03:26 darn now my package func hates my cd to $pkgname-$pkgver 2017-04-24 17:04:06 do you guys have any style like vars being enclosed with {} or " " 2017-04-24 17:04:18 no {} if it's not needed 2017-04-24 17:04:26 k 2017-04-24 17:04:27 quote if needed/reasonable 2017-04-24 17:04:35 yeah Im just using qoutes 2017-04-24 17:04:37 so, in most situations unless you're very sure it's not 2017-04-24 17:04:39 :p 2017-04-24 17:04:46 roger that 2017-04-24 17:05:02 k libcli is fixed and building on x86_64 2017-04-24 17:05:15 do you guys have any plans for armv7 or armv6 2017-04-24 17:05:24 <^7heo> Shiz: wait, you ONLY need to declare a subpackage with -doc 2017-04-24 17:05:31 <^7heo> and it finds the manpages?! 2017-04-24 17:05:35 yes 2017-04-24 17:05:38 <^7heo> \o/ 2017-04-24 17:05:46 <^7heo> That is fucking awesome, I didn't kno! 2017-04-24 17:05:48 <^7heo> know* 2017-04-24 17:05:53 <^7heo> a lot more of my packages are gonna have doc now. 2017-04-24 17:05:54 https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1472 2017-04-24 17:05:56 ;p 2017-04-24 17:06:06 yeah thats pretty awesome 2017-04-24 17:06:11 its a smarter builder 2017-04-24 17:06:15 <^7heo> yeah 2017-04-24 17:06:36 Ill definetly have to commend you guys on that one 2017-04-24 17:06:42 thanks alot 2017-04-24 17:08:03 do you guys use abuild -i to specifically install the apkg locally when testing 2017-04-24 17:08:17 If all goes well we will have arm7 later this year 2017-04-24 17:09:17 Im used to building on armv6 armv7 and aarch64 2017-04-24 17:09:34 directly on live hardware, I did see you guys hooked up with scaleway which is awesome 2017-04-24 17:09:51 We have both armhf and aarch64 2017-04-24 17:10:26 is it built board specific or by processor 2017-04-24 17:10:30 Don't mention that name today please.... 2017-04-24 17:10:41 my apologies 2017-04-24 17:11:08 <^7heo> you coulnd't know 2017-04-24 17:11:17 <^7heo> but for alpine-scaleway, today was a black day. 2017-04-24 17:11:47 what happened? 2017-04-24 17:12:01 <^7heo> shit hit the fan in the scaleway world. 2017-04-24 17:12:16 <^7heo> and we were without a master for a few hours. 2017-04-24 17:12:25 <^7heo> (yay) 2017-04-24 17:12:41 oh, hw issues. 2017-04-24 17:13:04 No worse 2017-04-24 17:13:10 Shortage 2017-04-24 17:14:34 <^7heo> And the levenshtein distance between shor and sabo is 3. 2017-04-24 17:16:02 scaleway does not guarantee the hardware you run on. so if you reboot and somebody else takes your node.... 2017-04-24 17:16:15 .... 2017-04-24 17:18:31 <^7heo> magic happens! 2017-04-24 17:23:44 and I was going to create account on scaleway :x 2017-04-24 17:23:56 <^7heo> by all means, do :{ 2017-04-24 17:24:05 <^7heo> They obviously need more business ;) 2017-04-24 17:25:33 ^7heo: I should avoid reboots too then 2017-04-24 17:25:56 <^7heo> scadu: who needs to reboot? 2017-04-24 17:26:05 <^7heo> scadu: you can run a Linux box on 2.6 2017-04-24 17:26:46 ^7heo: only stable and well-tested software, bro 2017-04-24 17:27:03 ACTION hides at offtopic bar 2017-04-24 17:27:14 scadu, its amsterdam that has issues now 2017-04-24 17:27:24 dunnot about france 2017-04-24 17:27:42 <^7heo> s/not/no/ 2017-04-24 17:27:52 <^7heo> clandmeter: France will have issues in 5 years. 2017-04-24 17:27:59 <^7heo> clandmeter: for now, we're still okay I think. 2017-04-24 17:28:09 thats quite unfortunate 2017-04-24 17:29:50 <^7heo> life is unfortunate. #DealWithIt. 2017-04-24 17:29:54 <^7heo> ACTION hides 2017-04-24 17:31:24 clandmeter: welp, I prefered Amsterdam, but now I'm not so sure 2017-04-24 17:33:34 the far right is taking over everywhere :/ 2017-04-24 17:33:47 <^7heo> Nah, not the syria. 2017-04-24 17:33:50 ACTION waits for america to be great again (yeah right) 2017-04-24 17:33:50 <^7heo> ACTION hides 2017-04-24 18:14:19 Shiz: fwiw, I ended up throwing the contents of my custom package to /etc/custom-packages/(...), then using the postinstall scripts to move the various contents in place 2017-04-24 18:30:16 are pkgs like flex and bison considered default when compiling from a base build 2017-04-24 18:30:42 arch3y: i dont think so 2017-04-24 18:30:46 check the build-base metapkg to be sure 2017-04-24 18:31:13 apk info -R build-base 2017-04-24 18:31:22 Shiz: thanks 2017-04-24 18:31:43 or alpine-sdk 2017-04-24 18:31:45 it seems to be in neither 2017-04-24 18:32:53 k so it has to be added to makedeps for each pkg that needs it got it 2017-04-24 19:12:47 Has anyone seen fabled around lately? 2017-04-24 19:13:43 <_ikke_> last week wednesday 2017-04-24 19:23:19 _ikke_ : Thanks. I really need those fixes in APK and I'm not sure who else can help there. 2017-04-24 20:27:36 Oh, FFS - Why do we have kernel package version that don't match their release? 2017-04-24 20:30:31 Vanilla only *SOMETIMES* as a revision, so we have to guess what the kernel release string is until we get it right :/ 2017-04-24 20:41:24 <^7heo> TemptorSent: In case of doubt, use brutefore. In case it fails, use more. 2017-04-24 20:41:54 ^7heo: Yeah, 60% of the code is bruteforceing around APK problems :( 2017-04-24 20:42:45 I need to know the kernel release BEFORE installing the kernel, and worse, I need to parse the kernel release and determine a kernel-package vrom that. 2017-04-24 20:43:05 <^7heo> TemptorSent: then you're doing it right ;) 2017-04-24 20:43:27 <^7heo> TemptorSent: also, if you wanna learn German, 'vrom' isn't the right translation for 'from' 2017-04-24 20:43:50 I have several hundred lines already trying to get a consistent result, and then I find some random corner case that breaks EVERYTHING. 2017-04-24 20:44:17 Yeah, yeah. I'll talk to my neurologist again about it :/ 2017-04-24 20:44:30 <^7heo> Gut gut. 2017-04-24 20:44:33 <^7heo> ACTION hides 2017-04-24 20:45:48 I've had a couple nasty impacts to the brain and some peripherial nerve damage -- when I type "fast", my error rate sucks. I used to be clean at over 110WPM :( 2017-04-24 20:48:49 ^7heo: The PITA with the kernel verision is I need to be able to accept apk atoms, uname output, custom built versions, and kernel-release specs interchangably. 2017-04-24 20:48:50 <^7heo> yeah, finger race condition... 2017-04-24 20:49:01 <^7heo> it increases with faulty hardware. 2017-04-24 20:49:05 EBBAC error. 2017-04-24 20:49:19 <^7heo> more like EBBAK 2017-04-24 20:50:16 *lol* Yeah, that too. Error Between Board and Chair 2017-04-24 20:50:37 2017-04-24 20:51:39 ...when you're the cause of the noise on the oscope, not the circuit you're probing. 2017-04-24 20:52:01 <^7heo> TemptorSent: oh it wasn't "error between brain and chair" intially? 2017-04-24 20:52:13 <^7heo> TemptorSent: that I corrected s/chair/keyboard/ ? 2017-04-24 20:52:46 ^7heo: Same gag, different realm, same pronounciation. 2017-04-24 20:52:49 <^7heo> and if I had to chose, I'd rather be the cause of the noise on the oscope than on the geiger. 2017-04-24 20:53:09 Yeah, I tick a bit. 2017-04-24 20:53:13 <^7heo> huhu 2017-04-24 20:53:20 <^7heo> as long as you don't glow... 2017-04-24 20:53:32 Nah, not yet ;) 2017-04-24 20:54:34 I don't spend that much time working with carnatite. 2017-04-24 20:55:44 the common acronym is PEBKAC 2017-04-24 20:56:02 Persistent Error Between Keyboard And Chair? 2017-04-24 20:56:06 problem exists 2017-04-24 20:56:37 So many versions, and all accurate. 2017-04-24 20:57:30 skarnet: Any thoughts on a sane means of determining the kernel package a given kernel release should be contained within? 2017-04-24 21:00:00 nope, you're not taking me as a hostage tonight 2017-04-24 21:00:32 Since sometimes vanilla comes up with the form '4.9.22', and sometimes '4.9.22-0', vs. grsec which appears to always be the form '4.9.22-0-grsec' 2017-04-24 21:01:42 lol 2017-04-24 21:02:16 No worries. At this point, I'm probably going to stop wasting my time trying to work around problems and wait until they're fixed to proceed. My code is getting downright ugly with the need to ' apk ... | grep -v "WARNING' | ... 2017-04-24 21:03:28 And since I can't seem to raise fabled, it looks like my work is on hold until the next release. 2017-04-24 21:03:59 that's why you apk() { apk "$@" | grep -v WARNING | ... } 2017-04-24 21:04:01 centralise the filtering 2017-04-24 21:05:56 Shiz: Yeah -- your patch just needs to get merged and that part would be fine. Otherwise, no warnings even when I want them :( 2017-04-24 21:06:51 But the one that is absolutely killing me is the inability to give a full atom with version to apk, meaning every single invocation ends up with a loop to strip off "-*-* 2017-04-24 21:08:22 that's what functions are for 2017-04-24 21:08:30 But then, of course package names break, so I have to check for a version FIRST, then strip the version, then operate on the package, then add it back again. 2017-04-24 21:08:55 No, functions don't fix the inability for apk to accept the atom. 2017-04-24 21:09:16 Can you say race condition? 2017-04-24 21:10:04 ...and this is exactly why I'v ended up with a broken system twice after running apk upgrade on my live system, my net flaked out and I ended up with the kernel and modules installed not matching. 2017-04-24 21:10:46 Right now, almost a third of my code is parsing and handling various issues that should be the baliwick of apk. 2017-04-24 21:11:30 And a third more could be eliminated with the addition of manifests to the packaging. 2017-04-24 21:13:05 So right now, I'm not actually making any headway on improving anything, I'm simply writing layer upon layer of conditionals to handle all the various idisyncratic constructs. 2017-04-24 21:16:52 It should not take 200+ lines to parse a kernel release, determine it's already staged, if not then create a directory and fetch/install, othewise use the existing and make sure it's current. 2017-04-24 21:18:12 But that's about what it takes because of the mess of the kernel version vs. kernel release vs. pkgver vs. kernel flavor vs. custom build 2017-04-24 21:22:16 And, to top it off, to remain compatabile, mkinitfs needs to take the (uname -r) output and figure out not just which kernel package it belongs to, but which modules it's supposed to use. 2017-04-24 22:40:01 Shiz: what patch is this 2017-04-24 22:40:59 kaniini: A very small patch to fix the output of apk warnings to go to stderr rather than stdout. 2017-04-24 22:41:47 Issue #7107 2017-04-24 22:42:02 link ? 2017-04-24 22:42:03 i'll merge it 2017-04-24 22:42:15 its in that link 2017-04-24 22:43:35 https://git.alpinelinux.org/cgit/apk-tools/commit/?id=5ba27c90007b2441f1fe35365c753a5365f3a2de 2017-04-24 22:43:42 Thank you! 2017-04-24 22:44:51 \o 2017-04-24 22:45:15 If anyone has any thoughts on fixing #7100, much of the remaining pain would go away :) 2017-04-24 22:45:23 And thank you Shiz for the patch. 2017-04-24 22:46:04 #7100 not possible 2017-04-24 22:47:56 done 2017-04-24 22:48:01 apk-tools 2.7.0-r4 2017-04-24 22:48:27 woo new apk-tools 2017-04-24 22:52:14 kaniini : forgot checksum for new patch for apk-tools 2017-04-24 22:52:53 I DO WHAT I WANNNNNNNNNNT 2017-04-24 22:53:50 lol 2017-04-24 22:54:39 anyway 2017-04-24 22:55:06 anyway ? 2017-04-24 22:55:13 TemptorSent: #7100 fundamentally not possible as the depsolver does nto really think in terms of 'atoms', but 'dependencies' and most places that take pkgname really takes a dependency 2017-04-24 22:55:48 TemptorSent: what you *could* do is try `apk fetch linux-grsec=4.9.whatever` 2017-04-24 22:56:18 TemptorSent: e.g. flip the last - into a =, which would make it a valid dependency that describes the atom 2017-04-24 23:01:25 kaniini: Crap. That kills it for me. The inability to feed search results back into fetch essentially makes the entire process a giant mess. 2017-04-24 23:02:04 I think I'm going to give it up as a bad job. 2017-04-24 23:03:24 It's been fun playing, but my the dent in my forehead is getting a bit too large from banging my head against the wall. 2017-04-24 23:04:47 Someone ping me when there's a new package format that doesn't have the limitations and I might try again. 2017-04-24 23:05:57 It doesn't look like I'll be able to functionally use alpine for my original intended purpose until then. 2017-04-24 23:08:14 I can't reliably make mkinitfs work without the occasional failure and start from scratch due to package-bumps mid-process. 2017-04-24 23:08:37 in fact, apk search is the only thing that outputs like that 2017-04-24 23:08:39 TemptorSent: what exactly are you trying to do? 2017-04-24 23:08:41 I'm guessing people with fast,reliable connections never see this. 2017-04-24 23:09:34 How about this "apk search -x `apk search -x zfs`" 2017-04-24 23:09:47 Something other than no-results would be nice. 2017-04-24 23:11:20 In other words, every time I query a package, I have to strip the version, do apk search -x on the package name, compare the version I get against the version specified, then use the stripped name to fetch the packages, then check the versions, then unpack the kernel version file from the kernel so I can find the REAL kver.... 2017-04-24 23:11:39 In other words, I spend all of my time and code manipulating version strings back and forth. 2017-04-24 23:12:25 And I can't do it generically because it's not actually consistent nor reliable (see meta-packages) 2017-04-24 23:12:45 So every time I fetch -o, I'm taking a gamble. 2017-04-24 23:13:10 er apk fetch -s 2017-04-24 23:13:38 I have absolutely no guarentee that the package I just searched for by name is actually the one I fetch. 2017-04-24 23:13:55 So I have to download each and every apk to a file first, verify that, then extract from that. 2017-04-24 23:14:04 You can see where this quickly gets absurd. 2017-04-24 23:14:37 do you guys want kernel style commit messages? 2017-04-24 23:15:45 kaniini: By the time I'm done, I end up with somethign that's both fragile and slow. 2017-04-24 23:17:57 kaniini: It means every time I have a list of packages, I have to run through a loop at a minimum of three times. 2017-04-24 23:19:56 kaniini: And it makes parsing ugly, because every place I touch a package or apk, I need to handle the same thing. 2017-04-24 23:21:10 For instance: You can specify a kernel as either an explicit .apk file, a build directory, a kernel release, or a package (with or without version) 2017-04-24 23:22:11 But it immediately becomes ambiguous because you don't have a of making sure you don't fetch the wrong version without going through another round of hoops. 2017-04-24 23:22:25 ^way 2017-04-24 23:24:09 What I don't understand is why the parser can't understand the exact same format it uses for apk files and search output. 2017-04-24 23:25:07 Clearly, it's unambiguous somewhere in apk. 2017-04-24 23:25:20 what does the `linux-grsec-4.3-4.3.49-r0` atom describe? 2017-04-24 23:25:39 is the version 4.3-4.3.49-r0? 2017-04-24 23:25:45 ? 2017-04-24 23:25:48 or is it 4.3.49-r0 2017-04-24 23:26:12 this is assuming that you make it the same as `linux-grsec-4.3=4.3.49-r0` 2017-04-24 23:26:19 Given what I've been using, it would reslove as 4.3.49-r0 2017-04-24 23:26:29 so, what you can do is 2017-04-24 23:26:42 linux-grsec= 2017-04-24 23:26:44 What I want is linux-grsec-4.3.49-r0 2017-04-24 23:26:45 try that with apk fetch 2017-04-24 23:26:48 you can also do 2017-04-24 23:26:52 yes 2017-04-24 23:26:52 so 2017-04-24 23:27:00 try linux-grsec=4.3.49-r0 2017-04-24 23:27:02 instead 2017-04-24 23:27:06 or would it be helpful 2017-04-24 23:27:10 if we had an option 2017-04-24 23:27:14 to make apk search output 2017-04-24 23:27:17 Here's the problem, that means EVERY time, I need to either do 3 variable transforms per atom or a sed script. 2017-04-24 23:27:18 as linux-grsec=4.3.49-r0 2017-04-24 23:27:24 ok 2017-04-24 23:27:26 so 2017-04-24 23:27:35 Take a apk filename, try to find the package based on that. 2017-04-24 23:27:58 if we change apk search 2017-04-24 23:28:15 to output something that would be a valid dependency description instead 2017-04-24 23:28:15 would that solve your problem? :) 2017-04-24 23:28:26 on that one 2017-04-24 23:28:26 would something like 2017-04-24 23:28:51 apk info --version --format="%{name}=%{version}" 2017-04-24 23:28:57 solve the problem? 2017-04-24 23:29:31 That's the problem, I have to do apkfile="$(apk search -x "${pkg%-*-*})" ; 2017-04-24 23:30:10 Not really, because it still doesn't give me the same thing as the apk file, which is what I then have to open and operate on. 2017-04-24 23:30:27 So it still leaves me at least one more step in a loop 2017-04-24 23:31:03 but what i am saying is 2017-04-24 23:31:14 you could do 2017-04-24 23:31:54 apk fetch $(apk search -x --format "%{pkg}=%{version}") 2017-04-24 23:32:27 For instance, in staging modules I need to check first for the "flavored" version of a package (zfs-grsec) before the unflavored version (zfs), but still have to check unflavored so things such as linux-firmware work. 2017-04-24 23:33:12 k first commit going out lets hope its a winner 2017-04-24 23:33:13 i guess i just dont understand what you want changed in apk 2017-04-24 23:33:19 oh well 2017-04-24 23:33:20 Yeah then I have to do: 2017-04-24 23:33:57 you said you wanted the ability to pass output from apk search into apk fetch 2017-04-24 23:34:00 tar -tvf "$(apk search -x "${pkg%-*-*}" 2017-04-24 23:34:01 i proposed a way to do it 2017-04-24 23:34:38 I need the output from apk search -x to remain the same, as I rely on that to figure out which file I'm operating on! 2017-04-24 23:36:21 Also, file/direcotry names with the equal are not my idea of wonderful. 2017-04-24 23:36:23 so if we made - equivilant to = for dependency nodes, would that solve your problem? 2017-04-24 23:36:55 If it would allow it to accept the atom as it appears in apk filenames and the output of search -x, it should. 2017-04-24 23:37:15 oops, i mean, equivalent 2017-04-24 23:38:33 It seems it should be possible to check against the list of atoms before invoking the depsolver, since everything uses the database anyway. 2017-04-24 23:39:16 Check the index for an exact match and preload that for the depsolver if found. 2017-04-24 23:39:49 well 2017-04-24 23:39:51 I just haven't learned my way around the guts of apk yet, as it's bounces all over the place and comments are few. 2017-04-24 23:39:52 the problem is 2017-04-24 23:39:56 apk fetch 2017-04-24 23:40:08 calls apk_package_foreach_name_matching 2017-04-24 23:40:13 er 2017-04-24 23:40:18 apk_name_foreach_matching() 2017-04-24 23:40:31 file/line so I can follow along? 2017-04-24 23:42:08 fetch.c:326 2017-04-24 23:42:43 ^7heo: you around by chance? 2017-04-24 23:42:44 Ahh, I was up in the wrong chunk of the file. 2017-04-24 23:44:15 kaniini: Okay, I'm seeing that -- why couldnt' apk_name_foreach_matching do the match for the first level and replace the atoms, then recurse? 2017-04-24 23:44:37 Is there a TOC function on github somewhere? 2017-04-24 23:45:46 TemptorSent: because apk_name_foreach_matching only deals in linux-grsec portion, not the full 'atom' 2017-04-24 23:46:18 So it has no ability to fetch a specific version? 2017-04-24 23:46:56 exactly 2017-04-24 23:46:57 what you could do i think is 2017-04-24 23:46:58 let me try something 2017-04-24 23:47:28 Shit, that pretty much means I have no choice but to download the files to a tmp dir and manually verify them. 2017-04-24 23:47:43 haha i think i found a solution 2017-04-24 23:47:52 it is really bad, but it will work 2017-04-24 23:48:17 If *you're* saying its bad, it must be BAD! 2017-04-24 23:48:37 raccoon:/home/kaniini/apk-tools/src# apk fetch --recursive .mkinitfs-dep 2017-04-24 23:48:37 Segmentation fault 2017-04-24 23:48:47 do you see where i am going with this 2017-04-24 23:49:21 Other than pointing out apk really shouldn't segfault with bad input? :P 2017-04-24 23:49:22 would you like to know why that segfaults? 2017-04-24 23:49:48 .mkinitfs-dep is an injected virtual that depends on linux-grsec=4.9.22-r0 2017-04-24 23:49:54 Because it's attempting to treat that as a package name and it's probably in a dep loop. 2017-04-24 23:50:07 nope 2017-04-24 23:50:11 it's because 2017-04-24 23:50:19 it has no source URL 2017-04-24 23:50:30 Oh, bloody hell. 2017-04-24 23:50:32 so it tries to fetch NULL 2017-04-24 23:50:34 ! 2017-04-24 23:50:47 one sec 2017-04-24 23:50:48 i got this 2017-04-24 23:50:49 I GOT THIS 2017-04-24 23:50:52 Okay, that get's us half way to hell :) 2017-04-24 23:50:55 you will have to do 2017-04-24 23:50:58 linux-grsec=4.9.22-r0 2017-04-24 23:51:04 as the pin 2017-04-24 23:51:07 but 2017-04-24 23:51:15 then you can apk fetch --recursive on the virtual 2017-04-24 23:51:21 and it will work 2017-04-24 23:51:37 as soon as i fix this NULL thing 2017-04-24 23:51:40 Hmm, then how do I find out what I ended up with for file names? 2017-04-24 23:51:52 it will be back to 2017-04-24 23:51:56 linux-grsec-4.9.22-r0 2017-04-24 23:51:59 once fetched 2017-04-24 23:52:06 it is just the argument on the commandline 2017-04-24 23:52:11 one sec 2017-04-24 23:52:27 Right, and how do I conveniently transform the equal at the second slash in shell script again? :P 2017-04-24 23:52:39 But it's at least getting closer. 2017-04-24 23:54:46 it is called 2017-04-24 23:54:47 you save the original arg 2017-04-24 23:54:47 :p 2017-04-24 23:56:46 /sbin/apk: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped, with debug_info 2017-04-24 23:56:50 time to gdb this 2017-04-25 00:00:52 # apk fetch --recursive .mkinitfs-dep 2017-04-25 00:00:53 .mkinitfs-dep: unable to select package (or it's dependencies) 2017-04-25 00:00:54 getting closer 2017-04-25 00:12:38 Okay, what does it take to read against the apk_pkg_format_cache_pkg cache? Could we check against the string in that and render the dep automatically perhaps? 2017-04-25 00:16:02 actually if apk_name_foreach_matching is doing the work, and the strings are in the apk_string_array *filter, and the database is passed, what prevents checking right there? 2017-04-25 00:18:12 is genid simply to prevent backtracking? 2017-04-25 00:18:25 ACTION sent a long message: kaniini_2017-04-25_00:18:24.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/xRPKBtKjbCeQJRxNSjVBEGIU 2017-04-25 00:18:27 BAM 2017-04-25 00:18:45 Crap, I have to type that? 2017-04-25 00:19:11 type what? 2017-04-25 00:19:23 The URL for your message to see what you did. 2017-04-25 00:19:32 I don't have a browser on my dev box. 2017-04-25 00:20:03 I don't have GUI on it at all for that matter! 2017-04-25 00:20:16 lol 2017-04-25 00:20:21 the point is it worked 2017-04-25 00:20:24 oh 2017-04-25 00:20:26 oh 2017-04-25 00:20:28 i see 2017-04-25 00:20:30 b/c matrix is shit 2017-04-25 00:20:33 gotcha 2017-04-25 00:20:41 i'll paste it, it's only 4 lines 2017-04-25 00:20:43 raccoon:~/apk-tools$ sudo apk fetch --recursive .mkinitfs-dep 2017-04-25 00:20:45 Downloading linux-grsec-4.9.22-r0 2017-04-25 00:20:47 Downloading device-mapper-libs-2.02.168-r3 2017-04-25 00:20:49 Downloading zlib-1.2.11-r0 2017-04-25 00:20:51 TemptorSent: ^ 2017-04-25 00:21:04 Thank you! 2017-04-25 00:21:15 Really? It pastebinned four lines? 2017-04-25 00:21:20 :matrix: 2017-04-25 00:21:45 now 2017-04-25 00:21:50 we just need a --recursion-depth flag 2017-04-25 00:21:52 so we can do 2017-04-25 00:22:07 apk fetch --recursive --recursion-depth=1 .mkinitfs-dep 2017-04-25 00:22:30 which is probably useful anyway 2017-04-25 00:22:37 Can we also have a flag to have fetch just give us the list of names as it fetches too? 2017-04-25 00:22:48 you mean without "Downloading" ? 2017-04-25 00:22:50 --pretend? 2017-04-25 00:22:51 That would probably eliminate at least one loop 2017-04-25 00:22:53 Yeah. 2017-04-25 00:23:00 actually 2017-04-25 00:23:02 --simulate 2017-04-25 00:23:14 Yeah, that's nice, now I get to run apk 3 times, not just twice! 2017-04-25 00:24:16 Once to search, followed by a loop to translate to deps (unless we can fix that somehow), then a loop to fetch, then another loop to figure out what we fetched. 2017-04-25 00:24:55 Also, simulate isn't very helpful if your actual download is crapping out on a particular file. 2017-04-25 00:25:13 TemptorSent: i was thinking about having apk search optionally format as dependency node 2017-04-25 00:25:42 TemptorSent: but you have to pin to a virtual, so the depsolver is actually invoked to do the fetch 2017-04-25 00:25:46 That would possibly help some, but the real pain point is having to do translations back and forth to deal with files vs. packages. 2017-04-25 00:26:13 TemptorSent: at least with this patch you can do 2017-04-25 00:26:40 So, I'll still have to loop over and first get one package, then get it's version, then set the pin to that, then get all packages. 2017-04-25 00:26:45 TemptorSent: apk add --virtual .mkinitfs-dep linux-grsec=blah && apk fetch --recursive .mkinitfs-dep && apk del .mkinitfs-dep 2017-04-25 00:27:25 TemptorSent: it's perverse but it works 2017-04-25 00:27:39 TemptorSent: what is cool is, 2017-04-25 00:27:42 Hmm, not sure how I get it to do what I need with that. 2017-04-25 00:27:43 TemptorSent: you can declare your dependencies on the virtual in one go, and then apk fetch them all at once 2017-04-25 00:28:05 The problem is I don't know what my deps are until I have my kernel package downloaded. 2017-04-25 00:28:36 that is problematicv 2017-04-25 00:28:38 so if I pin my kernel version, I might still end up with the wrong mods. 2017-04-25 00:28:38 -v 2017-04-25 00:29:01 anyway 2017-04-25 00:29:09 try latest apk-tools git and see if it works for you 2017-04-25 00:29:19 if the concept is sound, i will clean it up a little more 2017-04-25 00:29:45 So what I do is fetch the kerenel to a temp dir, check its version, then set that the pin for the mods, then see which ones don't work, then try again without the pin? 2017-04-25 00:30:03 probably :) 2017-04-25 00:30:11 (since things like firmware don't follow the kernel version) 2017-04-25 00:30:25 See the problem? 2017-04-25 00:32:44 So the pinning may not work out too well without another set of checks either before or after. 2017-04-25 00:34:40 Shiz: may I pm you a moment? 2017-04-25 00:34:46 And I still can't sanely parse a kernel package :/ 2017-04-25 00:34:48 what you do is 2017-04-25 00:34:48 sure? 2017-04-25 00:35:16 you do 2017-04-25 00:36:03 apk add --virtual .mkinitfs-dep linux-firmware linux-grsec=4.9.22-r0 dadhi-linux-grsec=4.9.22-r0 2017-04-25 00:36:12 apk fetch --recursive .mkinitfs-dep 2017-04-25 00:36:16 apk del .mkinitfs-dep 2017-04-25 00:36:42 Right, again, that means I need to know the difference between the packages before I fetch them, which I don't 2017-04-25 00:36:43 you use the virtual to make a dependency tree 2017-04-25 00:37:04 you don't, apk will handle it because the depsolver will fail 2017-04-25 00:38:17 so if the information I have is the following, how does it resolve? krel:4.9.22-r0-grsec packages "linux dadhi-linux zfs spl" 2017-04-25 00:38:37 add linux-firmware, and the whole mess breaks. 2017-04-25 00:41:04 What I'm doing now is doing is splitting off the flavor, then doing something like 'pkgname="$(apk search -x $pkg-$flavor || apk search -x $pkg)" 2017-04-25 00:42:24 What I want is to do apk search -x $pkg-$flavor-$version instead, so I don't get wrong versions, and I find unflavored packages properly still. 2017-04-25 00:43:09 And once I have that set of atoms, I pass them around and use them in all the other loops. 2017-04-25 00:43:53 *lol* And I can't build anything until I upgrade due to a mismatched libssl it seems! 2017-04-25 00:44:22 6%..... 2017-04-25 00:44:59 10%.... 2017-04-25 00:45:38 (And this folks, is how I can get version-mismatches) 2017-04-25 00:46:12 16% 2017-04-25 00:47:27 Rolling updates + slow, unreliable network + lack of explicit versioning = random results :) 2017-04-25 00:47:46 29% 2017-04-25 00:54:08 Here's an example of an inner fetch loop currently : '_pkgfile="$_ddir/$_pkg.apk" ; for _a_ in 1 2 ; do apk file_exists "$_pkgfile" || fetch -o "$_ddir" "${_pkg%-*-*}" ; apk verify "$_pkgfile" && return 0 ; rm -f "$_pkgfile" ; done ; return 1 2017-04-25 00:55:10 Adding the virtual fix makes this much longer, but at least I actually get the version I specified. 2017-04-25 00:56:46 My goal was to REDUCE my code complexity, so while it fixes A problem, it doesn't fix THE problem, and frankly, it's not worth me wasting any more of my time or anyone elses working on this if the code complexity can't be reduced significantly. 2017-04-25 00:57:48 Awesome, broken modules again! 2017-04-25 00:59:32 'depmod: WARNING: could not open /lib/modules/4.9.22-0-grsec/modules.builtin: No such file or directory 2017-04-25 01:00:32 All I have in /lib/modules/4.9.22-0-grsec is the contents of zfs! 2017-04-25 01:00:44 And this is STOCK everything upgrading. 2017-04-25 01:01:29 Conveniently, I got a full set of kernel modules for 4.9.20-0-grsec thought. 2017-04-25 01:01:38 Yeah, I give up. 2017-04-25 01:02:10 This happens about every other apk upgrade for me, which is the whole thing I started trying to fix in the first place!!! 2017-04-25 01:02:29 I think I'll just go back to funtoo :/ 2017-04-25 01:05:53 If it's going to take 500 lines of shell script just to ensure I can get a consistent kernel/modules (possibly after several tries), then start worrying about other deps, I'm probably in the wrong place anyway. I was after simple and intuitive, and this is anything but. 2017-04-25 01:07:44 : / 2017-04-25 01:09:24 Design principle: black magick should be done in the database, not through a sequence of scripts, intermediate files, check loops, and retries. Otherwise, WHY have a database? 2017-04-25 01:11:22 Also, kernel version from (uname -r) should match the version from the package for vanilla kernels!! 2017-04-25 01:12:22 I've been trying to fix the symptoms, but the underlaying cause apperars to be too deep to script over sanely. 2017-04-25 01:15:14 kaniini: Unfortunately, apk-tools git isn't building for me, pkgconfig problems with openssl. 2017-04-25 01:15:35 Where is config.mk that it's pulling in? 2017-04-25 01:16:25 apk add libressl-dev file-dev lua5.2-dev zlib-dev 2017-04-25 01:17:59 kaniini: Ahh, undocumented deps are fun :) 2017-04-25 01:18:42 also libfetch-dev 2017-04-25 01:18:54 <^7heo> arch3y: sorry was eating 2017-04-25 01:19:13 <^7heo> and now, night everyone 2017-04-25 01:19:18 kaniini: Yeah, just hit that one too. 2017-04-25 01:19:28 ^7heo: G'night. 2017-04-25 01:21:45 Well, at least the damn warnings to stdout is fixed! 2017-04-25 01:25:22 no problem 2017-04-25 01:25:41 I just realized I did something dumb and pushed a pr gonna close it and fix up my stuff 2017-04-25 01:26:42 you can always just force push 2017-04-25 01:26:47 it'll fix the pr up too 2017-04-25 01:26:52 no reason for duplicate prs 2017-04-25 01:28:20 well I realized I messed up my branch but its all right I already closed it 2017-04-25 01:28:27 cleaning up local then Ill resubmit 2017-04-25 01:33:46 k I think its all fixed up now 2017-04-25 01:48:05 are there any examples of pkgs where libtool is ran in the post-install 2017-04-25 01:48:13 I have been grepping to see if I can find any lol 2017-04-25 01:51:37 why would libtool be in the po-stinstall? 2017-04-25 01:52:15 I dont know all of the particulars but after some pkgs compile they mention run libtool --finish /usr/lib/blah 2017-04-25 01:52:39 but I see ppl doing libtoolize --force as well and that seemed to fix it 2017-04-25 01:52:53 right, don't just say post-install like that, that's understood as referring to the package hooks that run on the systems packages get installed on 2017-04-25 01:52:55 heh 2017-04-25 01:53:37 yeah my apologies I should of phrased my question better 2017-04-25 01:53:52 but it seems to be solved by adding the libtoolize in the build func 2017-04-25 01:53:59 personally i'd go with the simplest build that works 2017-04-25 01:54:40 yeah I basically have been making minor tweaks to things in unmaintained and getting them building 2017-04-25 10:07:20 kaniini, i'm lurking here. please ping me / email me if you need things. yes, apk-tools would probably use a dot release soon 2017-04-25 10:07:33 kaniini, ncopa pointed out that we earlier changed stderr->stdout in https://git.alpinelinux.org/cgit/apk-tools/commit/?id=517378721855280d2e23d25d7529e6b9cbae9136 2017-04-25 10:07:52 kaniini, but making errors go in stderr makes sense. how it does not cause any regressions though 2017-04-25 10:30:00 How would you detect (#ifdef) an OpenSSL 1.0 style API vs 1.1 regardless if it is actually libressl? 2017-04-25 10:45:09 OPENSSL_VERSION_NUMBER or SHLIB_VERSION_NUMBER? 2017-04-25 10:45:24 just from a look at include/openssl/opensslv.h 2017-04-25 10:46:02 hm, not the shlib thing, the numbering isn't the same 2017-04-25 10:46:14 but OPENSSL_VERSION_NUMBER should tell you everything you need to know 2017-04-25 10:47:58 What is did is #if (OPENSSL_VERSION_NUMBER <= 0x10100000L) 2017-04-25 10:48:39 I don't support anything below 1.0 so this should be enough, right? 2017-04-25 10:49:58 I don't know, it sounds good, but test it and tell us if it does what you expect it to :) 2017-04-25 10:54:51 you could also grep aports tree for libressl :) 2017-04-25 11:46:28 ScrumpyJack, yo uaround? 2017-04-25 11:46:57 This patch contains a wrong comment 2017-04-25 11:46:58 http://patchwork.alpinelinux.org/patch/3202/ 2017-04-25 11:47:09 upgrade is from 2.6.6 to 2.6.7 2017-04-25 11:47:13 I've updated it 2017-04-25 12:50:12 I just want to say that I do love the features youve added into abuild it makes it easier to build pkgs and helps when you miss stuff 2017-04-25 13:03:10 skarnet: I couldnt create a ifdef without mentioning libress. Guess I have to live with that: https://gist.github.com/ganwell/5da1a98932b2f8ce6b27e194d205e9d1 2017-04-25 13:11:53 Ganwell: I still think you shouldn't have to do that. You could just write your program with the libressl or openssl-1.1 API, and it will fail to build on older versions, and that's it. Not supporting openssl-1.0.* isn't an issue in 2017. 2017-04-25 13:15:11 skarnet: Well the slow distros like Debian still have OpenSSL 1.0, right? I don't want to force them to a non-standard TLS-lib. 2017-04-25 13:16:22 the poor things 2017-04-25 13:17:02 it's nice of you to show so much concern for slow distros, I'm certain they're also very concerned with your well-being 2017-04-25 13:20:19 skarnet: lol 2017-04-25 13:33:12 fcolista: thanks dude! good spot! 2017-04-25 15:29:15 so close to getting massscan working if only I can figure out a libmusl issue with AF_LINK 2017-04-25 15:32:45 <^7heo> hey arch3y 2017-04-25 15:32:54 <^7heo> still need me? ;) 2017-04-25 15:33:00 <^7heo> (since you highlighted me last night) 2017-04-25 15:33:46 ^7heo: nah I figured out my issue with the apkbuild 2017-04-25 15:33:56 <^7heo> gut gut :) 2017-04-25 15:34:07 I have 4 prs in the wings 2017-04-25 15:34:28 working on masscan now, I just have to figure out why musl has issues when doing ifdef AF_LINK 2017-04-25 15:44:37 arch3y: AF_LINK is a BSD extension, not a Linux thing, so maybe glibc supports it but chances are it aliases it to AF_PACKET 2017-04-25 15:45:04 just patch the app's code replacing AF_LINK with AF_PACKET and it should work 2017-04-25 15:45:41 skarnet: thanks I will do that 2017-04-25 15:59:12 its close but still no cigar, its being a pain in the butt lol 2017-04-25 15:59:18 ^7heo whast the staus on perl-time-hires? 2017-04-25 15:59:24 we need the builder to move on 2017-04-25 15:59:35 i think i just disable tests for now 2017-04-25 16:05:18 <^7heo> ncopa: I'll try to work on it a bit later on today. 2017-04-25 16:05:21 <^7heo> ncopa: is it urgent? 2017-04-25 16:05:39 <^7heo> oh okay I didn't get the urgency of the task. 2017-04-25 16:05:44 nah, i disabled tests for now 2017-04-25 16:05:48 <^7heo> good 2017-04-25 16:05:52 it is blocking build server 2017-04-25 16:05:55 <^7heo> yeah sure. 2017-04-25 16:05:59 <^7heo> makes a lot of sense to disable for now. 2017-04-25 16:06:00 need get the 3.6 packages built 2017-04-25 16:10:34 clandmeter: py-gobject3 added depndency of gnome-common. was that intentional? 2017-04-25 16:12:11 https://git.alpinelinux.org/cgit/aports/commit/main/py-gobject3?id=5bb8b3f9f4cead2c5ce2427a4ea85d657181a84a 2017-04-25 16:12:46 i ask because gnome-common is not in main repo 2017-04-25 16:15:01 i moved gnome-common to main 2017-04-25 16:24:43 skarnet: trying to fix the af_link code did not go well for me, but its close 2017-04-25 16:24:49 Im stil gonna hammer away at it 2017-04-25 16:25:05 just feeling like Im getting paste my knowledge point lol 2017-04-25 16:25:21 jirutka did you submit bugreport for nginx/libressl2.5? 2017-04-25 16:35:06 arch3y: fwiw, it's musl, not libmusl 2017-04-25 16:35:09 there's no lib in its name 2017-04-25 16:35:11 :p 2017-04-25 16:35:21 it provides a libc though 2017-04-25 16:36:55 Shiz: gotcha stil learning the nomenclature 2017-04-25 16:36:57 thanks 2017-04-25 16:37:10 yeah I have had to patch a few things because of it but not too bad 2017-04-25 16:39:59 I have found by putting musl into google I sometimes get muscle lol 2017-04-25 16:53:33 ncopa: eh… well… not yet, sorry 2017-04-25 17:03:32 ncopa, yes or it failed to build. 2017-04-25 17:16:10 ncopa: https://github.com/libressl-portable/portable/issues/307 2017-04-25 17:17:01 ncopa: any notes about the bug report before I sent it to nginx? 2017-04-25 17:17:08 s/sent/send/ 2017-04-25 17:17:39 i mentiond it to void linux ppl 2017-04-25 17:17:44 seems that they can reproduce too 2017-04-25 17:18:15 on musl, glibc or both? 2017-04-25 17:19:00 glibc 2017-04-25 17:20:40 i suspect nginx does some #ifdefs 2017-04-25 17:21:11 #if OPENSSL_VERSION> something || defined(LIBRESSL_VERSION_NUMBER) 2017-04-25 17:21:24 and end up with some bad codepath 2017-04-25 17:39:03 what the hell? `#if OPENSSL_VERSION_NUMBER >= 0x10001000L` 2017-04-25 17:39:15 `#if OPENSSL_VERSION_NUMBER >= 0x0090707fL` 2017-04-25 17:48:25 ncopa: reproduced even on OpenBSD https://github.com/libressl-portable/portable/issues/307#issuecomment-297108714 2017-04-25 17:48:42 not surprised 2017-04-25 17:48:54 this may result in a CVE :) 2017-04-25 17:50:00 yipes. 2017-04-25 17:50:16 Okay, why the hell do I have kernel version stuck at 4.9.20-r0, while it's updating everythign else to 4.9.22-r0 for linux-grsec 2017-04-25 17:50:32 ncopa: hm, maybe I should reported that privately to nginx… 2017-04-25 17:50:42 but too late, https://trac.nginx.org/nginx/ticket/1257 2017-04-25 17:50:45 My system is officially bjorked. 2017-04-25 17:52:51 ncopa: hm, I’ve never reported CVE issue, how does it work? who promotes issues for CVE…? 2017-04-25 17:55:01 MITRE 2017-04-25 17:55:11 but let's first determine if this is an actual vulnerability first 2017-04-25 17:55:15 yes 2017-04-25 17:55:31 and jirutka: nice catch! :) 2017-04-25 17:55:52 ncopa: I’ve just run upstream tests, nothing more :) 2017-04-25 17:56:22 isnt that what most of the "security researchers" does nowdays? 2017-04-25 17:56:56 no, they also run fuzzers duh 2017-04-25 17:57:09 I dunno, I always thought that CVEs are result of some more sophisticated work then just running provided test suite 2017-04-25 17:57:24 CVEs are just that, vulnerability identifiers 2017-04-25 17:57:29 I know 2017-04-25 17:57:30 how that vulnerability was discovered can differ widely 2017-04-25 17:57:50 like google discovering the glibc dns buffer overflow CVE because their internal hostnames were too long 2017-04-25 17:57:57 lol 2017-04-25 17:59:24 grr, I don’t like when I can’t modify the issue, like fixing typos and grammar mistakes :/ 2017-04-25 17:59:27 btw since it's somewhat confusing, i'll note it down here for future reference: 2017-04-25 17:59:38 IF it is a CVE: 2017-04-25 17:59:52 IF the issue is in nginx: request the CVE through the DWF: http://iwantacve.org 2017-04-25 18:00:05 IF the issue is in libressl: request the CVE through MITRE: https://cveform.mitre.org/ 2017-04-25 18:00:38 why different path for nginx and libressl? 2017-04-25 18:00:51 and why the heck is the first one some crappy google form? 2017-04-25 18:01:09 MITRE delegates CVE allocation to CVE numbering authorities (CNA) 2017-04-25 18:01:17 the DWF is the catch-all CNA for open-source projects 2017-04-25 18:01:26 open-source projects can also have their own CNA (openSSL does for instance) 2017-04-25 18:01:36 but MITRE acts as the CNA for libressl specifically 2017-04-25 18:01:47 interesting 2017-04-25 18:01:58 hum 2017-04-25 18:02:01 libbsd is a problem 2017-04-25 18:02:27 has anyone seen faffolter recently 2017-04-25 18:02:50 arch3y not here 2017-04-25 18:03:16 ncopa: whats hte issue? 2017-04-25 18:03:27 has he stopped contributing or just curious cause most pkgs I end up modifying are his 2017-04-25 18:03:28 it does not build on a number of archs 2017-04-25 18:03:53 but its not a big deal, dont want to derail the conversation 2017-04-25 18:04:16 if they are in unmaintained/, it's likely he stopped 2017-04-25 18:04:18 :p 2017-04-25 18:04:34 gotcha 2017-04-25 18:04:36 some things depends on libbsd 2017-04-25 18:04:45 abuilds in unmaintained/ are… well… unmaintained :P 2017-04-25 18:04:47 ncopa: got logs? 2017-04-25 18:04:56 also, we should totally become our own CNA *gets shot* 2017-04-25 18:05:31 :) 2017-04-25 18:05:33 http://build.alpinelinux.org/buildlogs/build-3-6-armhf/main/py-libvirt/py-libvirt-3.2.0-r0.log 2017-04-25 18:05:42 makes sense, just doing my duty to fix them and update them 2017-04-25 18:05:46 libvirt has the archs disabled 2017-04-25 18:06:09 Shiz: btw have you opened PR in rust-lang/rust for your recent patches? 2017-04-25 18:06:10 i think also some package using libbsd on s390x had problem 2017-04-25 18:06:30 jirutka: not yet, im waiting for #40113 to get merged because they depend on them 2017-04-25 18:06:53 <_ikke_> 404 2017-04-25 18:06:56 algitbot: you’re not very useful right now! >_< 2017-04-25 18:07:00 rust PR 40113, _ikke_ 2017-04-25 18:07:02 <_ikke_> haha 2017-04-25 18:07:02 :P 2017-04-25 18:10:05 ncopa - is there anywhere currently to document architecture discusison and decisions? 2017-04-25 18:10:15 for the rust people the llvm 4 stuff got merged https://github.com/rust-lang/rust/pull/40123 2017-04-25 18:10:32 very good 2017-04-25 18:10:34 i wonder if it can be backported 2017-04-25 18:10:46 TemptorSent we havent really had any official meetings 2017-04-25 18:11:14 and no, we dont have any current architecture docs 2017-04-25 18:11:16 ncopa Unofficial? Scratchings? 2017-04-25 18:12:02 hm, clandmeter showed us a diagram today for server infra 2017-04-25 18:12:06 Got it. I think something at least in broad strokes is needful. 2017-04-25 18:12:15 yes 2017-04-25 18:12:19 the historical precedent is "meet Alpine people somewhere, on IRC if you can't IRL, and try to grab their attention for an architecture discussion" 2017-04-25 18:12:44 yeah, that works when you aare small 2017-04-25 18:12:54 It could definitely benefit from improvements :P 2017-04-25 18:12:54 Yeah, but if such discussion never gets recorded for reference, it's very hard to know what's going on. 2017-04-25 18:13:02 yes 2017-04-25 18:13:04 so 2017-04-25 18:13:13 At least comments in code would help ;) 2017-04-25 18:13:15 the original idea was to use the mailing list 2017-04-25 18:13:27 that's something I often wonder about 2017-04-25 18:13:34 why isn't the mailing-list more used for this 2017-04-25 18:13:39 IMHO, the documents should be with the tools. 2017-04-25 18:13:52 i wish we had somewhat documented the discussion we had at FOSDEM 2017-04-25 18:13:54 it was fruitful imo 2017-04-25 18:14:06 we need a secretary :) 2017-04-25 18:14:12 skarnet: why not using -devel and hide discussion between spam :P 2017-04-25 18:14:16 That would not be me! 2017-04-25 18:14:31 alpine-illuminati mailing list 2017-04-25 18:14:44 Can we set a bot and keyword discussions? 2017-04-25 18:14:55 I'd rather have signal on the -devel ML than only spam tbh 2017-04-25 18:15:52 Finding things in context in the logs can be difficult -- I've tried :) 2017-04-25 18:16:08 I'd rather not rely on IRC for architecture things 2017-04-25 18:16:19 it's excellent for informal things, but there needs to be a trace somewhere else 2017-04-25 18:16:25 jirutka: hmm 2017-04-25 18:16:35 jirutka: ya think its worth trying to backport llvm4 fixes to our in-tree rust? 2017-04-25 18:16:35 Yeah, I wouldn't want to rely on it, but it would be a convenient tool to archive such discussions. 2017-04-25 18:18:46 Something like an arch-bot to query perhaps, and a muted channel to join to follow? 2017-04-25 18:18:58 Shiz: ? I’ve already ported some fixes from rust to our llvm3.9 2017-04-25 18:19:13 well i mean 2017-04-25 18:19:16 upgrading our rust to llvm4 2017-04-25 18:21:16 Shiz: does the latest Rust already support llvm 4? 2017-04-25 18:21:40 yes 2017-04-25 18:21:45 see mitchty's link at 20:10 2017-04-25 18:22:11 What really would help is if related messages stayed together over several lines, which might mean using a little "markup" that the bot could parse and spit out to files. 2017-04-25 18:22:18 I’ve suggested it some time ago to ncopa, it may be useful to agree on some periodical online meetings, once per two weeks or something like that, to discuss important things 2017-04-25 18:22:42 jirutka - I think that's an excellent idea. 2017-04-25 18:22:53 i think its needed yes 2017-04-25 18:23:12 not sure if do it via text or speech 2017-04-25 18:23:12 can we do that after v3.6 release? 2017-04-25 18:23:26 Setup a sub-channel for meetings perhaps so the regular devel traffic isn't intermixed. 2017-04-25 18:23:31 or mimics :P 2017-04-25 18:23:40 i just want the 3.6 release out now 2017-04-25 18:23:53 ncopa: please warn me *before* you branch out v3.6 2017-04-25 18:24:02 Text - voice conferencing is way too painful with more than a few users at a time. 2017-04-25 18:24:08 and not take any architectual discussions now 2017-04-25 18:24:19 can we do this after v3.6 release? 2017-04-25 18:24:43 well, we could have meetings about release progress :) 2017-04-25 18:25:04 we’d like to move rust and ghc to community for v3.6, but it’s not ready yet; rust currently depends on binaries from VoidLinux for bootstrap and ghc needs more review 2017-04-25 18:25:06 i agree with delaying it until after 3.6 2017-04-25 18:25:14 and also php is blocking, it’s currently in horrible state 2017-04-25 18:25:16 Probably wise, especially if 3.7 (4.0?) gets fast-tracked after doing the arch work. 2017-04-25 18:25:22 aw 2017-04-25 18:25:24 php 2017-04-25 18:25:38 who is following up php? 2017-04-25 18:25:41 jirutka: with my latest changes, the rust issue is trivially solvable 2017-04-25 18:25:43 :) 2017-04-25 18:25:51 Shiz: how? 2017-04-25 18:26:11 Shiz: upstream still do not provide prebuilt binaries that can run on musl-based system and it doesn’t look like they will provide them soon 2017-04-25 18:26:17 jirutka: but... we do! 2017-04-25 18:26:23 Shiz: but bootstrapping… 2017-04-25 18:26:38 the latest apkbuild should allow cross-compilation from glibc 2017-04-25 18:26:44 if you get abuild running on a glibc host 2017-04-25 18:26:50 we need figure out how to do bootstrapping 2017-04-25 18:26:56 but lets do that after 3.6 release 2017-04-25 18:26:57 and replace the relevant sources= lines 2017-04-25 18:27:10 openjdk will need bootstrap, go, needs it and now rust 2017-04-25 18:27:15 ncopa: so you’re okay with moving rust into community before solving bootstrapping issue? 2017-04-25 18:27:33 will it build on all archs? 2017-04-25 18:27:33 i mean solving without relaying on binaries from VoidLinux 2017-04-25 18:27:47 which archs will have it? 2017-04-25 18:28:10 Once bootstrapped, can it rebuild itself and newer revs at least? 2017-04-25 18:28:17 yes 2017-04-25 18:28:34 jirutka im kinda ok with it 2017-04-25 18:28:34 no, currently just on x86_64; we can cross-compile our rust for other arches, but we need someone’s help, probably fabled, I still don’t understand how cross- support in abuild works 2017-04-25 18:28:44 Then it shouldn't be an issue from the end-user's POV. 2017-04-25 18:29:00 firefox 53 needs rust 2017-04-25 18:29:17 it’s not issue for end-user, it’s issue for us, b/c we can’t bootstrap distro out of blue 2017-04-25 18:29:36 Right, I mean as far as community vs testing. 2017-04-25 18:30:11 From the end users pov, the generated package is stable (relatively). 2017-04-25 18:30:40 So it either breaks or not before a package is generated. 2017-04-25 18:31:15 ad php, we have bunch of patches from Valery, but no time to review them; tbh I don’t care about php very much, so I’ve decided to invest my time to rust and other issues 2017-04-25 18:31:21 For me, that's good enough to use in community in a non-testing sense. 2017-04-25 18:31:59 Ncopa, which Arch's do not build with libbsd? 2017-04-25 18:32:15 armhf and aarch64 apparently 2017-04-25 18:32:16 As long as broken packages won't actually be generated, it's fine IMHO to be in community. 2017-04-25 18:32:18 im working on it 2017-04-25 18:32:23 It can 2017-04-25 18:32:32 we should have configure test for linux/a.out.h 2017-04-25 18:32:41 Refactor the patch 2017-04-25 18:32:49 thats what im doing 2017-04-25 18:32:54 Ok 2017-04-25 18:32:57 there was a patch some time ago for s390x 2017-04-25 18:33:04 Yes 2017-04-25 18:33:11 btw I’m afraid that llvm4 does not work on x86 correctly; probably I made some mistake when updating the patches (there were a lot of changes) 2017-04-25 18:33:21 so much to do 2017-04-25 18:33:24 :D 2017-04-25 18:33:25 I asked the author to fix it 2017-04-25 18:33:28 wait, not llvm, but clang 2017-04-25 18:33:54 I’ve kinda verified that clang 4.0.0 works on x86_64, someone tried it on s390x 2017-04-25 18:34:05 https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-support/libbsd/libbsd/0003-Fix-build-breaks-due-to-missing-a.out.h.patch 2017-04-25 18:34:08 a.out.h is x86*onlyafaik 2017-04-25 18:34:16 hmm… a.out.h… this reminds me something… 2017-04-25 18:34:17 Okay, ignoring the whole mess of the initfs and kernel, what is the most pressing work that needs to get done for 3.6 to drop aside from rust/php/libbsd? 2017-04-25 18:34:29 Any other showstoppers? 2017-04-25 18:34:57 TemptorSent: check #alpine-commits 2017-04-25 18:35:01 those are the build errors 2017-04-25 18:35:03 id like uefi boot to work but i have no idea what the status on that one is 2017-04-25 18:35:23 no, that’s different issue: "hidden symbol `__stack_chk_fail_local' isn't defined" 2017-04-25 18:35:34 oh 2017-04-25 18:35:36 it's THAT issue 2017-04-25 18:36:34 I suspect this: https://github.com/alpinelinux/aports/blob/master/main/clang/clang-0004-Add-musl-targets.patch#L56 2017-04-25 18:36:53 should there be i386, not i486, or i686 or how is that already dead arch named these days…? 2017-04-25 18:37:31 jirutka i386 is correct still I believe for the minimal supported cpu. 2017-04-25 18:37:54 it builds fine even on x86, but we don’t run tests for clang, b/c it depends on some sources from llvm, so it needs some more work to get it working 2017-04-25 18:37:57 There is some embedded stuff that still uses it. 2017-04-25 18:38:13 TemptorSent: I’ll show more context… 2017-04-25 18:38:15 And my old laptop :) 2017-04-25 18:38:56 jirutka btw, are you using smart quotes or something? I'm getting default chars instead of ' and . from you. 2017-04-25 18:39:01 jirutka: afaik the canonical alpine arch is i586 2017-04-25 18:39:05 i586-alpine-linux-musl 2017-04-25 18:39:18 this is important: https://github.com/llvm-mirror/clang/blob/release_40/lib/Driver/ToolChains.cpp#L4345 2017-04-25 18:39:46 oh, it's used for that 2017-04-25 18:39:59 TemptorSent: I’m using *correct* quotation characters, not a symbol for inches or seconds 2017-04-25 18:40:02 in that case 2017-04-25 18:40:03 http://pkgs.alpinelinux.org/contents?branch=edge&name=musl&arch=x86&repo=main 2017-04-25 18:40:11 it's i386 2017-04-25 18:40:22 hm, right, so this is ok 2017-04-25 18:40:26 Hmm, looks like irc logs aren't updating :/ 2017-04-25 18:40:32 stupid me, I could verify this myself 2017-04-25 18:41:16 jirutka: Yes, typographic quotes -- I know them well from my years doing DTP :) 2017-04-25 18:41:50 anyway, I’ve switched lldb and creduce to clang and both fails to build on x86 with the same error, so I suspect there’s some problem in clang 2017-04-25 18:41:51 jirutka I apparently have a charset that doesn't map them properly. 2017-04-25 18:42:11 TemptorSent: don’t tell me that you don’t use UTF-8… 2017-04-25 18:42:53 *lol* jirutka Yeah, I'm sitting on a console terminal with no custom font loaded. 2017-04-25 18:43:29 jirutka running bx full screen. 2017-04-25 18:44:29 re libbsd 2017-04-25 18:44:46 TemptorSent: well, then I’m sorry, but I refuse to use *incorrect* symbols just b/c someone still live in 1970… 2017-04-25 18:44:51 http://patchwork.alpinelinux.org/patch/3350/ 2017-04-25 18:46:01 TemptorSent: Czech lang uses characters that are not in ASCII, so I’m very allergic to ancient charsets and neverending problems with them 2017-04-25 18:47:04 Shiz: so you propose to backport these patches to our rust pkg? https://github.com/rust-lang/rust/pull/40123/files 2017-04-25 18:47:55 our llvm4 package and then link rust against llvm4 2017-04-25 18:47:59 it seems there's actual changes to rustc 2017-04-25 18:48:05 llvm3.9 is currently used just for rust; but I think that we should keep llvm3.9 in community anyway 2017-04-25 18:48:15 there's no actual changes* 2017-04-25 18:48:51 Shiz: this PR doesn’t look like no actual changes… 2017-04-25 18:49:19 Shiz: agree with backporting fixes to llvm4! 2017-04-25 18:49:49 yeah the PR has changes in the rust-lang/llvm stuff 2017-04-25 18:49:54 which is their llvm branch 2017-04-25 18:49:55 :P 2017-04-25 18:51:06 Shiz: for example this https://github.com/rust-lang/rust/pull/40123/files#diff-2eac1efa08534eca4e1fb606ec02139b is definitely in rust code-base ;) 2017-04-25 18:51:48 jirutka: yes but those are irrelevant to us 2017-04-25 18:51:51 since we're not mingw 2017-04-25 18:51:53 :P 2017-04-25 18:52:31 yeah, it was just an example; but tbh I’ve just skimmed it, no time now to read it all 2017-04-25 18:57:48 jirutka: Oh, no complaint - just wanted to verify what was going on :) 2017-04-25 18:58:54 ad php: we’ve already removed all php5-* pkgs and keep only php5 itself, plus moved to community; this simplifies (avoids) the problem a lot; community/php7 should be updated to the latest version (7.1.3) and testing/php7 removed; then all working testing/php7-* pkgs moved from testing to community; relevant PRs: https://github.com/alpinelinux/aports/pulls?q=is%3Aopen+is%3Apr+label%3AC-php+label%3AP-high 2017-04-25 18:59:06 jirutka: Although perhaps changing the default consolefont would be wise, since I'm on default everything. 2017-04-25 19:01:10 I’ll hopefully allocate some time for it, get in touch with Andy and somehow solve it together 2017-04-25 19:01:33 but if someone else would do it, I’ll be happy :) 2017-04-25 19:02:21 Um, do I need to create a distinct account for the wiki? Not the same credentials as Redmine? 2017-04-25 19:02:40 TemptorSent: unfortunately yes, you need different account 2017-04-25 19:02:58 Okay, thanks -- that's slightly irritating. 2017-04-25 19:04:00 TemptorSent: that’s yet another thing nice to have, centralized user accounts management and ideally some login gateway (OpenID Connect) 2017-04-25 19:04:03 Bloody hell, an ambiguous captcha?! 2017-04-25 19:04:21 Given the number ....., what's the second digit? 2017-04-25 19:04:30 WTF?!@? 2017-04-25 19:04:52 I usually do this with LDAP, b/c it’s supported by most apps, but not sure if we really want LDAP… 2017-04-25 19:04:53 Second in place value or second in reading order? 2017-04-25 19:05:14 I'll take ldap or a sane datbase backend any day. 2017-04-25 19:05:49 uff, there’s sooo many things need to do and so little time that it depresses me 2017-04-25 19:06:46 jirutka: welcome to my world 2017-04-25 19:07:39 I have even very simple single-purpose app for changing password in LDAP for end-users, but written in Python :/ and most importantly it lacks password reset feature (it’s okay for company, but not for us I guess) https://github.com/jirutka/change-password 2017-04-25 19:09:16 skarnet: no, that’s MY world, so you welcome to my world! XD :P 2017-04-25 19:17:04 Hmm, seeing spl-vanilla failing on s390x -- is zfs actually suppored there currently? 2017-04-25 19:20:15 MediaWiki is broken, spitting out backtrace, error about version of user to be saved is older than the current version. 2017-04-25 19:20:32 Can't resend the verification email. 2017-04-25 19:41:08 ncopa : the libbsd fix I already submitted to github, so the one you just merged on patchwork is obsolete :( 2017-04-25 19:41:29 tmh1999 not really 2017-04-25 19:41:44 the patches on github fixed only ppc64 and s390x 2017-04-25 19:41:49 explicitly 2017-04-25 19:42:13 okay understand 2017-04-25 19:42:16 the one you sent earlier, from yokoto or what its called 2017-04-25 19:42:19 fixes it on all arches 2017-04-25 19:42:29 yeah technically they are all the same 2017-04-25 19:42:36 arm and aarch64 had smae issue 2017-04-25 19:43:54 ncopa : other thing, llvm4 build good on my test s390x machine, and it fails on the builder both edge and 3.6. is there something ? 2017-04-25 19:44:06 ah yeah 2017-04-25 19:44:15 its the bootstrap go 2017-04-25 19:45:37 go bootstrap effect llvm4 ? 2017-04-25 19:45:45 *affects 2017-04-25 19:45:49 apparently 2017-04-25 19:45:55 hum... 2017-04-25 19:46:02 tmh1999: the problem is that somehow Go remained on the build server and stupid autodetection in LLVM build system detected it and enabled some Go integration that fails 2017-04-25 19:46:37 jirutka, ncopa : wow, I have never acknowledged that before. can you fix it on the builder ncopa ? 2017-04-25 19:46:53 om in oit 2017-04-25 19:46:58 hum 2017-04-25 19:47:00 ncopa : appreciate it 2017-04-25 19:47:21 i think i already fixed it 2017-04-25 19:48:53 ah right. it's done. thank you ! 2017-04-25 19:49:35 wait a moment, this is a different issue 2017-04-25 19:49:48 llvm3.7 failed on s390x due to Go 2017-04-25 19:49:54 llvm4 is different http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/llvm4/llvm4-4.0.0-r0.log 2017-04-25 19:50:40 the latest log http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/llvm4/llvm4-4.0.0-r2.log … please note that the test errors are still here, they are just ignored (i.e. it does not fail the build) 2017-04-25 19:51:12 ncopa: tmh1999: ^ 2017-04-25 19:52:03 jirutka : hum... 2017-04-25 19:52:31 Would someone please bump the irclogger, it appears to be lost. 2017-04-25 19:53:05 TemptorSent: alternatively you can use http://www.irclogger.com/.alpine-devel/2017-04-25 2017-04-25 19:53:30 Thanks jirutka, I was trying to follow commits with my browser. 2017-04-25 19:53:47 I kinda like its retro look&feel, but it’s not very good for searching in history of multiple days 2017-04-25 19:54:09 aha, #alpine-commits are not logged on irclogger.com 2017-04-25 19:54:30 Drat. 2017-04-25 19:54:52 I’ve clicked to #alpine-linux just for curiosity… the first thing spotted “php in docker image”… as expected, closed it immediatelly XD 2017-04-25 19:55:01 I was going to try to look at some of those logs real quick, but there's nothing real quick about it if I have to type 'em :) 2017-04-25 19:55:54 but happy that some more patient of us are even in #alpine-linux, so I don’t have to :) 2017-04-25 19:56:33 TemptorSent: it’s probably better to aggregate messages from relevant MQTT topics instead of parsing irc log 2017-04-25 19:56:57 TemptorSent: mosquitto_sub -h msg.alpinelinux.org -v -t 'build/build-edge-s390x' 2017-04-25 19:57:18 Yeah, that's the problem, the browser is a pos 32bit windoze box. 2017-04-25 19:57:47 (which shares nothing with my dev box except the external network) 2017-04-25 20:04:03 jirutka, ncopa : re llvm4 test fail, skimming the bug and llvm source, I guess the test are about creating/editing filesystem. It is maybe due to we are running the s390x build in lxc. 2017-04-25 20:04:54 tmh1999: x86_64, x86, armhf, aarch64 also runs in lxc 2017-04-25 20:05:21 Finally got the wiki to send the confirmation email... might want to check the logs and see whats going on there. 2017-04-25 20:05:22 I thought they all run on alpine ? 2017-04-25 20:05:34 native alpine 2017-04-25 20:06:22 yes, native Alpine, but inside LXC container running on Alpine ;) 2017-04-25 20:06:42 it’s Alpine all the way down and then just turtles… 2017-04-25 20:08:00 hum let me work on it more 2017-04-25 20:10:19 What Wiki category shall I start the architecture pages under? Developer Documentation? 2017-04-25 20:12:34 TemptorSent: probably 2017-04-25 20:13:08 Okay, will do -- I'll stub it and someone that actually knows how things works currently can fill in the details :) 2017-04-25 20:17:01 jirutka : spl-vanilla s390x fail on checking whether modules can be built... yes , probably the linux-vanilla s390x config missed some CONFIG you think ? 2017-04-25 20:17:13 checking whether modules can be built... no 2017-04-25 20:17:17 http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/spl-vanilla/spl-vanilla-4.9.24-r0.log 2017-04-25 20:21:52 seems like it cannot build any kernel module at all 2017-04-25 20:22:27 probably I should disable spl-vanilla zfs-vanilla, I might misunderstood them before 2017-04-25 20:23:19 hmm 2017-04-25 20:23:21 that's odd 2017-04-25 21:21:38 Okay, take a look at https://wiki.alpinelinux.org/wiki/Architecture 2017-04-25 21:22:35 its coming along 2017-04-25 21:23:20 There are some stubs to start from anyway. 2017-04-26 00:12:11 I’ve tries to rebuild LibreSSL 2.5.3 with reverted https://github.com/libressl-portable/openbsd/commit/ddd98f8ea741a122952185a36c1396c14c2fda74 and now all nginx tests pass! /cc ncopa 2017-04-26 00:13:13 ... 2017-04-26 00:13:17 this definitely seems worth SOME cve 2017-04-26 00:13:22 yes 2017-04-26 00:13:28 how should I proceed? 2017-04-26 00:26:04 Shiz: how about CVE? 2017-04-26 00:30:41 i'd first bring it up on the issue in question that it may be CVE worthy as its an obvious semantics change 2017-04-26 00:54:50 jirutka: as this bypasses the entire SSL verify mode if the callback returns success... 2017-04-26 00:55:31 or does it 2017-04-26 00:55:34 it's kind of hard to follow 2017-04-26 00:56:11 jirutka: hmm actually 2017-04-26 00:56:14 it may just be nginx tests... 2017-04-26 01:10:32 Shiz: I’ve updated nginx bug report with more info https://trac.nginx.org/nginx/ticket/1257#comment:3 2017-04-26 01:11:10 right 2017-04-26 01:11:39 >Non-zero exit status: 255 2017-04-26 01:11:41 ??? 2017-04-26 01:12:15 but yeah, looks like an nginx problem indeed 2017-04-26 01:13:06 jirutka: i think this qualifies as an nginx CVE, probably 2017-04-26 01:13:16 it should not by any means always return 1 2017-04-26 01:19:03 srsly, OpenBSD still use CVS? they are really masochists… 2017-04-26 01:30:06 kaniini : I am reading gcc APKBUILD and there is this commit : https://git.alpinelinux.org/cgit/aports/commit/main/gcc?id=3ec4774bf40a3673935c0e87c917dab70751d33a lol 2017-04-26 01:31:14 and right before that is the commit you added yourself about powerpc triplet lol 2017-04-26 03:04:15 Question - what would be the immediate feasiblity of adding the exact kernel release string to all kernel related packages in the .PKGINFO? 2017-04-26 03:04:59 That would solve the ugliest problem with version not matching releases. 2017-04-26 03:35:13 Out of curiosity how are we supposed to handle kernel modules in packages? I've tried to find some apk examples, but I think I'm just leading myself in the wrong direction 2017-04-26 03:37:38 depends on the kernel module in question 2017-04-26 03:37:41 what are you thinking of? 2017-04-26 03:38:32 https://git.alpinelinux.org/cgit/aports/tree/main/xtables-addons-grsec/APKBUILD 2017-04-26 03:38:35 I'm trying to package wireguard and it compiles into a .ko or dkms 2017-04-26 03:38:36 generally something like this is followed 2017-04-26 03:39:07 the extra stuff is to ensure the package matches with the kernel ver or the build fails 2017-04-26 03:41:46 Awesome, thanks for pointing me in the right direction 2017-04-26 03:43:09 poptart - wireguard-tools / -grsec / -vanilla - already in testing 2017-04-26 03:43:53 Oh! Wonderful 2017-04-26 03:44:39 checkout 'pass' by the same author - it's great 2017-04-26 03:44:53 passwordstore.org 2017-04-26 03:45:27 see the README.alpine for making the clipboard work over ssh for root 2017-04-26 03:45:38 I'm well aware of zx2c4, he's wonderful 2017-04-26 03:45:52 yes 2017-04-26 04:45:42 jirutka, ncopa : llvm4, spl-vanilla, zfs-vanilla all build good on my test s390x machine. So it is probably due to the builder. Hum... 2017-04-26 05:53:12 fabled ? You actually here? 2017-04-26 06:00:16 TemptorSent, yes 2017-04-26 06:00:42 Hello fabled, long time no see! How are things? 2017-04-26 06:02:08 TemptorSent, okish, been doing non-alpine things for a while 2017-04-26 06:02:44 fabled: Any insights as to resolving the showstopper with apk being unable to install multiple versions of the kernel in parallel? 2017-04-26 06:02:45 hope to get back on track 2017-04-26 06:03:06 It's bricking systems at random for multiple people it seems, not just me. 2017-04-26 06:03:14 TemptorSent, it's a design feature that multiple version of same pkgname cannot currently co-exist 2017-04-26 06:03:28 you can have linux-vanilla and linux-grsec coexist 2017-04-26 06:03:47 Yeah, which means I have an unbootable system until I go manually fix it. 2017-04-26 06:03:56 My modules don't match my kernel. 2017-04-26 06:04:05 it's more of package naming then 2017-04-26 06:04:15 should maybe include version id in pkgname 2017-04-26 06:04:21 kaniini was looking into that. 2017-04-26 06:04:32 and use some provides name instead 2017-04-26 06:05:07 The other major issue is the design of the parser that makes it impossible to use package atoms for fetch/search. 2017-04-26 06:05:08 currently the fact that only one version of each pkgname can exist is pretty hardwired 2017-04-26 06:05:28 TemptorSent, ? 2017-04-26 06:05:33 atoms? 2017-04-26 06:05:53 Yeah, 'apk search -x `apk search -x linux-grsec`' 2017-04-26 06:06:16 oh, you mean the foo-1.2-r1 format? 2017-04-26 06:06:27 Yes. 2017-04-26 06:06:44 The complete $pkgname-$pkgver string. 2017-04-26 06:06:53 i don't really like that format. it's sort of gentoo heritage from times before i came aboard. 2017-04-26 06:07:40 i'm planning to rework apk-tools 2017-04-26 06:07:59 though. i've been talking about that for a while and i'm now a few months late :P 2017-04-26 06:08:04 i do have some code already 2017-04-26 06:08:13 but it's still long way 2017-04-26 06:08:14 Well, the problem lies in the fact that you can't fetch a package by it's complete name, so you have to strip the version and hope that what you get matches what you want, then check the version. 2017-04-26 06:08:20 yes 2017-04-26 06:08:42 In the mean time, we have bjorked systems popping up. 2017-04-26 06:08:49 do you have notes, or written somewhere all the apk commands you are missing? 2017-04-26 06:09:40 See: Issue #7100 2017-04-26 06:09:49 Issue #7101 2017-04-26 06:09:57 Issue #7102 2017-04-26 06:10:05 Issue #7103 2017-04-26 06:10:18 Issue #7104 2017-04-26 06:10:54 Issue #7107 is actually fixed in git now thanks to Shiz and kaniini. 2017-04-26 06:12:08 Issue #7107 caused regression 2017-04-26 06:12:09 Those are the ones that could probably be supported with the existing apk with some reworking in the parsing for fetch/search. 2017-04-26 06:12:16 What? 2017-04-26 06:12:31 Having errors to stderr causes a regression? 2017-04-26 06:13:23 You mean I have to go put my grep -v WARNING in every place it breaks things when it issues a spurious warning about my extra repo in the repo file and I'm on a different arch? 2017-04-26 06:13:52 I'm sorry, but warnings to stdout is simply insane. 2017-04-26 06:14:02 updated https://bugs.alpinelinux.org/issues/7107 2017-04-26 06:14:18 And -q will not work, since the output for apk search -x differs! 2017-04-26 06:14:27 wut 2017-04-26 06:15:21 TemptorSent, yes, the output / certain input are not cohorent in all places. it's largely due to historical reasons 2017-04-26 06:15:49 *facepalm* 2017-04-26 06:15:54 we've spoken about fixing it 2017-04-26 06:16:09 but it's been pending due to various different legacy and time allocation reasons 2017-04-26 06:16:11 that regression seems very odd... 2017-04-26 06:16:30 No kidding, I can't see what's going on there. 2017-04-26 06:17:21 i think it's some sort of stdio caching issue 2017-04-26 06:17:41 The fflush should have handled that. 2017-04-26 06:18:11 Oh, wait -- is apk_log_err missing a fflush call perhaps? 2017-04-26 06:18:19 it's not, it's handled in log() 2017-04-26 06:18:23 log() does it now 2017-04-26 06:18:30 maybe apk_progress_force should only be set in apk_log 2017-04-26 06:18:31 but what i think is one issue 2017-04-26 06:18:33 Yeah, the va wrapping shouldn't change that... 2017-04-26 06:18:34 instead of apk_log_err... 2017-04-26 06:18:51 the progress bar printing uses a sort of nasty trick 2017-04-26 06:19:02 after writing the bar 2017-04-26 06:19:15 it also puts a control sequence to the buffers 2017-04-26 06:19:21 and expects next write to go to the same FILE 2017-04-26 06:19:30 Let me guess, you're resetting the line position with the escape sequence. 2017-04-26 06:19:48 Why doesn't it run on a different FD? 2017-04-26 06:20:07 yes, it resets cursor 2017-04-26 06:20:16 fflush(stdout); 2017-04-26 06:20:17 fputs("\e8\e[0K", stdout); 2017-04-26 06:20:27 Ug, yeah -- that would do it. 2017-04-26 06:20:39 and now that stderr, and stdout are mixed 2017-04-26 06:20:48 the control sequence is not printed 2017-04-26 06:20:54 until next regular log 2017-04-26 06:21:17 in fact 2017-04-26 06:21:20 How about having the progress bar use fd3 instead? 2017-04-26 06:21:26 ? 2017-04-26 06:21:29 they all share same console 2017-04-26 06:22:25 You can get a bit cute recombining them and control the fflush 2017-04-26 06:22:57 Since that's what appears to be ending up out of order. 2017-04-26 06:23:16 the commands are 2017-04-26 06:23:25 "Restore cursor position and attributes" + "Clear line from cursor right" 2017-04-26 06:23:34 the idea is that it'll erase the progress bar 2017-04-26 06:24:20 Right, what I mean is if you can sequence the order of the output, it will work as expected. 2017-04-26 06:24:34 so writing to stderr, should first fflush stdout 2017-04-26 06:24:43 Right. 2017-04-26 06:24:47 i think adding fflush(stdout) in error logging should fix it 2017-04-26 06:25:39 wrap fflush with a macro or inline so it always flushes in the right order. 2017-04-26 06:26:50 i think http://sprunge.us/eRQB should do it 2017-04-26 06:27:47 You might want to put that right in apk_log 2017-04-26 06:28:04 er log 2017-04-26 06:28:12 why? 2017-04-26 06:28:38 Since that's wher the actual output takes place. 2017-04-26 06:28:51 It will fix other such cases if they happen to exist somewhere. 2017-04-26 06:29:00 but it needs flush only when writing to stderr 2017-04-26 06:29:40 That means thigns might break with interesting redirections. 2017-04-26 06:29:50 ? 2017-04-26 06:29:53 no 2017-04-26 06:30:25 redirections manipulate the actual fds 2017-04-26 06:30:28 so no, it won't break stuff 2017-04-26 06:31:01 the other option is http://sprunge.us/DdJc 2017-04-26 06:31:09 So if the dest FD happens to be going to the console as well? 2017-04-26 06:31:28 latter option seems better 2017-04-26 06:31:50 Agreed. 2017-04-26 06:31:53 in current codebase, they do the same thing. you can call log_internal only from the two exposed functions 2017-04-26 06:32:04 but in case log_internal is ever used more, it's a bit safer 2017-04-26 06:32:42 also, it looks like a length-check may be needed? 2017-04-26 06:33:54 i'll commit the latter fix then 2017-04-26 06:33:57 TemptorSent, length-check? 2017-04-26 06:34:12 Buffer sizes, or is that handled a layer up? 2017-04-26 06:34:30 what buffer sizes 2017-04-26 06:34:42 format, va 2017-04-26 06:34:47 ?? 2017-04-26 06:34:52 those aren't buffers 2017-04-26 06:35:18 Ahh, const - nm. 2017-04-26 06:36:21 presumably there are no copy semantics in the chain to be concerned with? 2017-04-26 06:36:39 no 2017-04-26 06:37:02 see also https://git.alpinelinux.org/cgit/apk-tools/commit/?id=517378721855280d2e23d25d7529e6b9cbae9136 2017-04-26 06:37:08 we used to log everything to stderr 2017-04-26 06:37:34 i think the primary reason for changing that was to put progress bar printing to stdout 2017-04-26 06:37:45 and to have the reset sequence cached in the FILE 2017-04-26 06:37:51 musl seems to have uncached stderr 2017-04-26 06:38:19 Ahh, while stdio is buffered io 2017-04-26 06:38:41 yes 2017-04-26 06:38:52 stdout is line-buffered 2017-04-26 06:38:55 stderr is not buffered 2017-04-26 06:39:09 in addition to referring to different FDs 2017-04-26 06:39:19 the backing device is same (/dev/something) 2017-04-26 06:40:15 Right, that makes things potentially entertaining. 2017-04-26 06:41:11 yes, it's easy to mess things up unless you know the differences :) 2017-04-26 06:41:24 i think glibc somehow synchronizes stdout/stderr different 2017-04-26 06:41:32 musl is a bit more explicit on it 2017-04-26 06:41:43 Would it be possible to do the progress bar with line-updates and just treat it as a single operation each call? 2017-04-26 06:42:21 could use ncurses or similar 2017-04-26 06:42:41 That's probably getting heavier than necessary for a simple progress bar :) 2017-04-26 06:42:45 but wanted to keep that dependency out 2017-04-26 06:43:25 The escape codes should work, you'd just need to update the buffer and rewrite the entire line with each call. 2017-04-26 06:43:46 yes, the "hack" just allows not keeping any state 2017-04-26 06:44:21 Yeah, you'd need to count output lines otherwise or pick an absolute position 2017-04-26 06:45:05 vt102 based, right? 2017-04-26 06:45:59 iirc, it's ansi escape sequence which should be supported in most term flavors 2017-04-26 06:46:11 Right, vt100/vt102 2017-04-26 06:50:49 you could probably use the esc-7 sequence and esc 8 sequences together to make it work. 2017-04-26 06:51:23 On any other output, send esc-7, then have the esc-8 in the progress bar line. 2017-04-26 06:53:41 Either that, or just directly set it using esc [ h 2017-04-26 06:54:42 Anyway, all that aside -- is it possible to accept the $pkgname-$pkgver string as valid input and pass it to the dep parser in a format that will get the correct packge or fail? 2017-04-26 06:57:55 fabled: Also, kaniini's suggested solution for kernel package naming is something to the effect of $pkgname-$kver-$pkgver, making the actual package name '$pkgname-$kver' and allowing multiple versions to be installed while still being tracked by apk for the minor version 2017-04-26 06:58:54 actually s/$kver/$krel/g 2017-04-26 07:00:06 We want the exact release string from the kernel in the package name, otherwise we don't know the real kernel release string until we download the kernel and extract /usr/share/kernels/*/kernel.release 2017-04-26 07:01:58 This gives us 'linux-grsec-4.9.22-0-grsec-4.9.22-r0' and 'linux-vanilla-4.9.22-4.9.22-r0' for instance. 2017-04-26 07:03:20 (but sometimes it's 'linux-vanilla-4.9.22-0-4.9.22-r0', just to keep life interesting) 2017-04-26 08:44:58 royger: i have a question on xen network setup 2017-04-26 08:45:23 currently our alpine-xen iso will suggest a br0 interface at install 2017-04-26 08:45:34 is that a common way to set up xen hosts? 2017-04-26 08:46:08 i see that lxc on ubuntu has an lxcbr0 interface for bridge of your containers 2017-04-26 08:46:17 libvirt sets up virbr0 2017-04-26 08:46:35 and both set up dnsmasq on it 2017-04-26 08:46:47 <^7heo> ncopa: in my experience, the "common" way to set xen up isn't always the most reliable 2017-04-26 08:46:57 so guests can get dhcp addr of the private network 2017-04-26 08:46:58 <^7heo> or the simpler 2017-04-26 08:47:14 my question is if it would make sense to set up a xenbr0 interface 2017-04-26 08:47:18 and have dnsmasq on it 2017-04-26 08:47:29 <^7heo> also it really depends on the xen version 2017-04-26 08:48:21 i am thinking for alpine-xen-3.6 2017-04-26 08:48:27 with xen 4.8 2017-04-26 08:48:34 <^7heo> but I remember the network with Xen (on debian) as a giant pain 2017-04-26 08:48:51 i want make it a pleasant experience on alpine 2017-04-26 08:48:57 <^7heo> because of the lack of proper error reporting 2017-04-26 08:49:08 <^7heo> and weird presets 2017-04-26 08:49:46 <^7heo> so let's try to document that right at least 2017-04-26 08:50:07 <^7heo> anyhoo, br0++ 2017-04-26 08:50:09 ncopa: hm, the classic Xen bridge is/was xenbr0 IIRC 2017-04-26 08:50:12 <^7heo> on my side 2017-04-26 08:50:20 <^7heo> yeah 2017-04-26 08:50:31 but I'm not sure why all those solutions couldn't use br0 or bridge0 2017-04-26 08:50:47 royger: and then you do port forward to the guest on the host? 2017-04-26 08:51:21 ncopa: yes, default bridge is xenbr0 https://xenbits.xen.org/docs/unstable/man/xl.conf.5.html but alpine could ship a slightly custom xl.conf with a different default bridge (see vif.default.bridge="NAME") 2017-04-26 08:51:26 <^7heo> nah you do routing 2017-04-26 08:51:44 ok 2017-04-26 08:51:44 <^7heo> with IP forward 2017-04-26 08:51:52 <^7heo> nat is discouraged 2017-04-26 08:51:59 ncopa: hm, no, I don't do that, I don't filter anything on the bridge 2017-04-26 08:52:12 <^7heo> bridging/routing is cleaner 2017-04-26 08:52:14 so routing instead 2017-04-26 08:52:44 ok. so having an /etc/init.d/xen-net service makes sense 2017-04-26 08:52:54 ncopa: the simple setup is to just add the virtual interface to the bridge and that's all. 2017-04-26 08:52:55 which by default creates a xenbr0 interface 2017-04-26 08:53:09 and sets up dnsmasq on it 2017-04-26 08:54:07 hm, the "simple" setup would be to create a bridge and just add your primary interface to it. 2017-04-26 08:54:18 thats what we do now 2017-04-26 08:54:54 but what's the point in adding dnsmasq, do you what to provide a dns/dhcp server for the guests? 2017-04-26 08:55:06 yes 2017-04-26 08:55:09 <^7heo> yeah do not add dnsmask 2017-04-26 08:55:17 provide dhcp for guests 2017-04-26 08:55:26 have a guest network with dhcp 2017-04-26 08:55:27 <^7heo> I would use a proper dhcpd 2017-04-26 08:55:29 hm, but if a real interface is added there, isn't this going to cause issues? 2017-04-26 08:55:34 yes 2017-04-26 08:55:47 so the options are: 2017-04-26 08:56:01 br0 + real interface. no dhcp service provided 2017-04-26 08:56:02 <^7heo> and also, when I managed a xen network 2017-04-26 08:56:20 xenbr0, private net, dhcp provided from dnsmasq 2017-04-26 08:56:23 <^7heo> I had a script manage the IPs on the host 2017-04-26 08:56:35 <^7heo> since it's all local to the host 2017-04-26 08:56:47 <^7heo> no need for network protocol 2017-04-26 08:56:52 ncopa: and do forwarding to the real interface from xenbr0? 2017-04-26 08:57:06 leave that to the user 2017-04-26 08:57:17 you can forward or route 2017-04-26 08:57:34 or you can set up your own net the way you want. this is to have a simple default 2017-04-26 08:57:42 OK, I think we should have an easy way, very easy, to allow the VMs to access the network. Or else it's goign to be a PITA for users 2017-04-26 08:57:51 <^7heo> +1 2017-04-26 08:58:02 yes 2017-04-26 08:58:39 <^7heo> I would say the real show stopper is any unconfigured network setting 2017-04-26 08:58:42 this is also going to be a problem for people trying to ssh or whatver into the VMs from outside the host, but maybe that's good... 2017-04-26 08:59:09 we have 2 options to do that: 1) br0, hosts interface. real bridge. guests are on the hosts network. 2) set up a private net xenbr0 with dnsmasq 2017-04-26 08:59:19 <^7heo> the farther away from what people are used to configure, the more problematic 2017-04-26 08:59:31 <^7heo> 1 2017-04-26 08:59:37 <^7heo> def 1 2017-04-26 08:59:56 ok, so option 1 is the default setup 2017-04-26 09:00:08 <^7heo> imho yes 2017-04-26 09:00:24 option 2 is how lxc and libvirt set up the defaul 2017-04-26 09:00:33 <^7heo> it's easier on the guests 2017-04-26 09:00:40 <^7heo> (the opt 1) 2017-04-26 09:00:42 but you normally dont run xen on a desktop 2017-04-26 09:00:51 ncopa: I'm not oposed to the xenbr0 + dnsmask, but it's not common (most dristros just bridge the primary network card), and I think there needs to be a very simple way (like xenbr0.allow_network=1) or similar to allow the interfaces on xenbr0 to access the host network 2017-04-26 09:01:32 ok 2017-04-26 09:01:51 oh, didn't know libvirt did that... maybe people is used to that kind of setup then. I'm not a system administrator FWIW 2017-04-26 09:01:59 <^7heo> also opt 2 is definitely doing more magic from the user pov 2017-04-26 09:02:07 yes 2017-04-26 09:02:28 <^7heo> royger: nah but libvirt isn't a good example imho 2017-04-26 09:02:31 well, I don't administer *any* system at all, so my opinion here is probably pointless 2017-04-26 09:02:40 :) 2017-04-26 09:02:49 <^7heo> alpine should not strive to follow bad examples 2017-04-26 09:02:50 (on purpose) 2017-04-26 09:02:56 <^7heo> no matter how popular 2017-04-26 09:03:24 ok next question 2017-04-26 09:03:43 woudl it make sense to rename "br0" to "xenbr0"? 2017-04-26 09:03:50 <^7heo> yes 2017-04-26 09:04:06 even if host network is bridged? 2017-04-26 09:04:12 <^7heo> more specific, better for inter-operability 2017-04-26 09:04:37 ok 2017-04-26 09:04:52 thanks for your input 2017-04-26 09:04:54 i have a plan 2017-04-26 09:05:44 <^7heo> well, people won't assume a private network and dnsmask because the bridge name is xenbr0 as opposed to br0 2017-04-26 09:05:51 <^7heo> at least I hope 2017-04-26 09:06:01 <^7heo> for our world 2017-04-26 09:06:29 i will give them the option 2017-04-26 09:06:35 both will be possible 2017-04-26 09:06:37 both will be simple 2017-04-26 09:06:46 when you do setup-alpine 2017-04-26 09:06:54 it will suggest create xenbr0 2017-04-26 09:07:01 it currently suggests br0 2017-04-26 09:07:11 and will bridge the hosts network 2017-04-26 09:07:21 it will continue as ususal 2017-04-26 09:07:37 so the only change will be rename br0 to xenbr0 2017-04-26 09:08:08 if you dont set up that on the host setup, you will still be able to: apk add xen-net 2017-04-26 09:08:21 and /etc/init.d/xen-net start 2017-04-26 09:08:45 which will do the xenbr0 + dnsmasq magic for you if you want that behavior 2017-04-26 09:09:51 i will also create a similar lxc-net service 2017-04-26 09:13:01 ncopa: FWIW, on FreeBSD the default is bridge0 2017-04-26 09:13:12 ok 2017-04-26 09:13:24 freebsd has also different network interface 2017-04-26 09:13:28 interfaces 2017-04-26 09:13:29 not eth0 2017-04-26 09:13:53 right, but bridges can be named as you wish, xenbr, br or bridge 2017-04-26 09:14:00 i suppose xenbr0 makes sense if xen use that as default 2017-04-26 09:14:13 I just don't think the "xen" prefix adds any value to it, unless it means something for the admin 2017-04-26 09:14:33 I assume Linux ppl is used to that. 2017-04-26 09:14:54 it adds a sense of fraternity among xenbr0s 2017-04-26 09:17:20 bridging host network is a bit annoying when you run it in vmware fusion which i used to test the alpine-xen iso 2017-04-26 09:17:27 but i suppose thats not the common usecase 2017-04-26 09:17:43 i had to enter password on boot to give access to promisc mode 2017-04-26 09:21:42 if i have a mounted /media/usb and I changed the usb, how should I tell to Alpine to recheck the partition table and figure out the new size? 2017-04-26 09:22:06 restarting modloop is not enough 2017-04-26 09:22:56 server has an uptime of > 500 days 2017-04-26 09:23:21 so a reboot is not doable 2017-04-26 09:24:29 :D 2017-04-26 09:24:50 how did you change it? 2017-04-26 09:24:58 did you unplugged it? 2017-04-26 09:25:13 or just resized the partition 2017-04-26 09:25:28 changed it 2017-04-26 09:25:40 (wasn't me..but this is another story) 2017-04-26 09:26:03 i think you can unmount it and unplug it physically 2017-04-26 09:26:07 and insert it again 2017-04-26 09:26:16 I dont' have physical access 2017-04-26 09:26:20 :) 2017-04-26 09:26:44 i think kernel will not use the new partition table if it was "in use" when the change happened 2017-04-26 09:26:53 there are some command, partprobe i think 2017-04-26 09:26:57 that might be able to do it 2017-04-26 09:27:10 yes 2 if i remember 2017-04-26 09:27:11 but i dont know if you need to unmount it first 2017-04-26 09:27:13 kpartx, partprobe o re-read the partition table 2017-04-26 09:27:21 with /proc fs 2017-04-26 09:27:25 one of this way i think 2017-04-26 09:27:31 so, i shold: 2017-04-26 09:27:36 stop modloop 2017-04-26 09:27:45 umount /media/usb too 2017-04-26 09:27:50 make sure its unmounted 2017-04-26 09:27:55 umoun /media/usb 2017-04-26 09:28:01 re-read the partition table 2017-04-26 09:28:05 adn then remount 2017-04-26 09:28:08 yes 2017-04-26 09:28:13 i think that should work 2017-04-26 09:29:08 this does not affect what is running right? 2017-04-26 09:29:34 no 2017-04-26 09:30:01 if its a regular run from ram install. 2017-04-26 09:30:09 depends on if you have something else mounted on the disk 2017-04-26 09:30:22 if you have /var mounted there too then you'll have problem 2017-04-26 09:31:42 no, var is on raid disk 2017-04-26 09:32:21 then it shoudl be all good 2017-04-26 09:39:04 heh 2017-04-26 09:39:23 that's interesting 2017-04-26 09:39:26 rc-service modloop stop 2017-04-26 09:39:28 partx -va /dev/sda 2017-04-26 09:39:35 rc-service modloop start <-fail 2017-04-26 09:39:47 ls /dev/sda 2017-04-26 09:39:49 is /media/usb mounted? 2017-04-26 09:39:51 there's no sda1 2017-04-26 09:39:54 no 2017-04-26 09:40:12 fdisk /dev/sda 2017-04-26 09:40:17 it exists 2017-04-26 09:40:19 does it show sda1 2017-04-26 09:40:31 Command (m for help): p 2017-04-26 09:40:31 Disk /dev/sda: 28.9 GiB, 31009800192 bytes, 60566016 sectors 2017-04-26 09:40:32 Units: sectors of 1 * 512 = 512 bytes 2017-04-26 09:40:32 I/O size (minimum/optimal): 512 bytes / 512 bytes 2017-04-26 09:40:32 Sector size (logical/physical): 512 bytes / 512 bytes 2017-04-26 09:40:34 Disklabel type: dos 2017-04-26 09:40:36 Disk identifier: 0x4387b4f9 2017-04-26 09:40:38 Device Boot Start End Sectors Size Id Type 2017-04-26 09:40:40 yes 2017-04-26 09:40:42 ok 2017-04-26 09:40:42 Device Boot Start End Sectors Size Id Type 2017-04-26 09:40:48 and in /proc/partitions? 2017-04-26 09:40:55 /dev/sda1 * 32 60565503 60565472 28.9G c W95 FAT32 (LBA) 2017-04-26 09:41:08 yes 2017-04-26 09:41:09 can-f1-ter-lxc-1:~# cat /proc/partitions 2017-04-26 09:41:09 major minor #blocks name 2017-04-26 09:41:09 8 0 30283008 sda 2017-04-26 09:41:09 8 1 30282736 sda1 2017-04-26 09:41:12 ok 2017-04-26 09:41:13 also there 2017-04-26 09:41:16 then: mdev -s 2017-04-26 09:41:25 its just the node that needs be created 2017-04-26 09:41:29 modprobe: can't change directory to '/lib/modules': 2017-04-26 09:41:32 the devnode 2017-04-26 09:41:37 but 2017-04-26 09:41:41 now it exists 2017-04-26 09:41:51 then you shoudl be able to mount /media/usb 2017-04-26 09:41:54 and start modloop 2017-04-26 09:41:56 yes 2017-04-26 09:42:01 it does it work 2017-04-26 09:42:45 bah 2017-04-26 09:42:47 still 2GB 2017-04-26 09:42:50 /dev/sda1 2.0G 1.9G 123.9M 94% /media/usb 2017-04-26 09:42:59 (this is the df result9 2017-04-26 09:43:11 partition may be bigger 2017-04-26 09:43:15 that filesystem 2017-04-26 09:43:24 fs is fat32 2017-04-26 09:43:30 with ext4 you'd resize2fs after chanign partition size 2017-04-26 09:43:44 i dont think fat has good support for resizing 2017-04-26 09:43:53 that's not a resize 2017-04-26 09:43:58 it's another usb pen 2017-04-26 09:45:01 not following, was not the partition of the same usbpen modified? 2017-04-26 10:34:23 https://grsecurity.net/passing_the_baton.php 2017-04-26 10:37:34 oh wow 2017-04-26 10:39:38 see the faq also 2017-04-26 10:39:50 we need rename linux-grsec to something else 2017-04-26 10:39:57 i suggest we rename it to linux-gsec 2017-04-26 11:05:35 linux-the-patch-formerly-known-as-grsec 2017-04-26 11:10:32 ncopa: what about just -hardened 2017-04-26 11:11:02 thats a good suggestion 2017-04-26 11:11:04 i like it 2017-04-26 11:11:21 there are many ways to harden a Linux 2017-04-26 11:11:29 exactly 2017-04-26 11:11:31 looks like PaX patches are still public, despite their FAQ... https://grsecurity.net/~paxguy1/pax-linux-4.9.24-test7.patch 2017-04-26 11:12:07 who knows about future ones though 2017-04-26 11:12:10 they have probably just not removed it yet 2017-04-26 11:12:14 yes 2017-04-26 11:12:24 better save them before they disappear :P 2017-04-26 11:12:31 i did 2017-04-26 11:12:32 skarnet: there's already grsec-scrape 2017-04-26 11:12:34 :) 2017-04-26 11:12:37 ha 2017-04-26 11:12:40 https://github.com/slashbeast/grsecurity-scrape 2017-04-26 11:12:52 grsec-me-harder 2017-04-26 11:13:35 i really liked the -hardened suggestion 2017-04-26 11:13:47 we give users a hardened kernel option 2017-04-26 11:14:00 how we harden it may change over time 2017-04-26 11:29:26 :) 2017-04-26 11:31:01 ncopa: i wonder how viable it would be to coordinate with other distros (gentoo's, any others?) hardened teams on to see if there's an animo/development power for at least forward-porting the current grsec feature set to new kernels 2017-04-26 11:31:11 it's something i'd be at least willing to put development time in 2017-04-26 11:43:14 fabled: i don't really like that format. – what format specifically? I hope that you don’t wanna drop Gentoo-style versioning format, I mean $pkgver part?! 2017-04-26 11:43:58 the pkgname-pkgver-rpkgrel can be ambiguous to parse in certain cases 2017-04-26 11:48:27 should use a different delimiter maybe 2017-04-26 11:48:32 as yes, - is already usedi n package names 2017-04-26 11:48:34 maybe : :p 2017-04-26 11:49:27 fabled: in what cases? it’s very well defined, pkgver cannot contain dash and -r\d is always the last 2017-04-26 11:52:45 currently it's not enforced in the strictest sense 2017-04-26 11:52:51 and e.g. linux-kernel-2.6 2017-04-26 11:53:00 is the last part a version number, or part of the pkgname? 2017-04-26 11:53:39 also linux-kernle-2.6-2.6.32-r1 looks slightly confusing 2017-04-26 11:54:02 it's certainly something we can live with, and probably something a simple heuristic can figure out 2017-04-26 11:54:59 i would just prefer that the character separating pkgname<->pkgver was not valid in pkgname so there would be no possibility for ambiguity 2017-04-26 11:56:20 if nothing else, : is invalid afaik, because subpackage stuff 2017-04-26 12:10:03 ncopa: details about LibreSSL + nginx bug https://trac.nginx.org/nginx/ticket/1257#comment:3 2017-04-26 12:10:30 Shiz: nginx responded… https://trac.nginx.org/nginx/ticket/1257#comment:4 (WTF) 2017-04-26 12:10:49 yeah, saw it just now 2017-04-26 12:10:51 lol 2017-04-26 12:11:54 really, WTF such arrogance?! 2017-04-26 12:12:22 don't attribute to malice what can be just an oversight 2017-04-26 12:12:35 i presume the nginx devs have too little hours in a day to fully read everything 2017-04-26 12:13:07 we’re talking about very critical security error here… 2017-04-26 12:14:02 but still, the main problem is in LibreSSL… it supposed to be more secure and reliable than OpenSSL, right? doesn’t look so now… 2017-04-26 12:14:20 libressl is not the issue 2017-04-26 12:14:26 it had a bug before that was fixed now 2017-04-26 12:14:31 it is, they changed the existing behaviour 2017-04-26 12:14:38 apps not understanding the openssl api is a different issue 2017-04-26 12:15:15 yes, but this fix leads to serious regression in third-party apps, so it’s very unresponsible 2017-04-26 12:15:37 and OpenSSL API is horrible piece of shit, so you can’t blame devs to not understand it 2017-04-26 12:16:37 i found this one to be pretty clear though :P 2017-04-26 12:16:57 btw, running a musl build with the new stuff 2017-04-26 12:17:02 s/musl/rust/ 2017-04-26 12:17:10 the CI infra fixes that will make the musl PR mergeable 2017-04-26 12:17:13 (hopefully) 2017-04-26 12:31:07 jirutka and Shiz thanks for following it up 2017-04-26 12:31:53 ncopa: we’re discussing it in #xbps right now 2017-04-26 12:46:59 TemptorSent: hi 2017-04-26 12:47:21 I am testing the release scripts and adding support for ppc64le. Seems that the main script is aports/scripts/mkimage.sh. In order to generate the ISO, should I run it with --profile standard? 2017-04-26 12:48:36 rdutra yes 2017-04-26 12:48:50 but it will generate an iso which boots with syslinux 2017-04-26 12:49:03 i dont know if it makes sense for ppc64le 2017-04-26 12:51:48 jirutka: sigh 2017-04-26 12:51:54 how can one build infra be this broken 2017-04-26 12:52:06 what happened? 2017-04-26 12:52:09 rust, again 2017-04-26 12:52:11 :P 2017-04-26 12:52:29 no matter what targets you get/if it's a cross-compilation, it ALWAYS uses system cc to link 2017-04-26 12:52:32 even for cross-compile targets... 2017-04-26 12:52:47 i thought it was me who broke our build server -> master ... 2017-04-26 12:52:48 :) 2017-04-26 12:52:54 ah no, not today 2017-04-26 12:52:56 :p 2017-04-26 12:55:10 ncopa, yea, syslinux is not supported on ppc64le. We would need grub. 2017-04-26 12:55:28 is there any arch that uses grubs currently? 2017-04-26 12:56:21 we need to use it for our aarch64 2017-04-26 12:56:34 thunderx platform 2017-04-26 12:57:45 leitao: ncopa: btw, I tried to build with --profile standard in ppc64le and it failed missing "linux-grsec" package. The build of this packages is not enabled in ppc64le, do we need it? 2017-04-26 12:59:28 rdutra, you are talking about grub? 2017-04-26 13:01:06 clandmeter: ah no, I tried to build with --profile standard but I guess not using grub 2017-04-26 13:02:24 rdutra: there's no grsec for ppc64 afaik 2017-04-26 13:02:37 or maybe there is, but i dont think we use it? 2017-04-26 13:03:45 there is? 2017-04-26 13:06:17 i thought grsec was only x86, x86_64 and arm (32bit) 2017-04-26 13:06:59 rdutra, i still dont understand what you try to build? 2017-04-26 13:07:11 if its grub, then this doesnt depend on kernel. 2017-04-26 13:07:59 leitao i dont think we have any release image that uses grub atm 2017-04-26 13:08:26 rdutra i think you should use --profile vanilla 2017-04-26 13:08:27 clandmeter: ok, I am trying to adapt the script to generate ppc64le iso (bit lost yet but trying to understand how it works) 2017-04-26 13:08:41 ah ok 2017-04-26 13:09:03 i think the easiest is to start with minirootfs 2017-04-26 13:09:14 which is very simplistic 2017-04-26 13:09:24 designed for docker image 2017-04-26 13:10:27 ncopa: I see...the minirootfs already have support for ppc64le. Fabiano Rosas added it 2017-04-26 13:10:46 and it works? 2017-04-26 13:10:46 ncopa: this seems to imply as much: https://forums.grsecurity.net/viewtopic.php?f=3&t=4158 2017-04-26 13:10:48 but i may be wrong 2017-04-26 13:11:31 Shiz oh ok 2017-04-26 13:11:36 looks like you are right 2017-04-26 13:11:56 i know for sure that aarch64 is not supportted 2017-04-26 13:12:14 that is right 2017-04-26 13:13:15 ncopa: yes, it works. It generates the minirootfs tar.gz 2017-04-26 13:13:34 thats great 2017-04-26 13:14:10 i'd aim for --profile vanilla as next target 2017-04-26 13:16:35 ok, will try it 2017-04-26 13:24:00 rdutra grub fails to build on ppc64le. you need freetype-dev in makedepends 2017-04-26 13:24:12 looks good otherwise 2017-04-26 13:26:17 ncopa: ok, will add the freetype-dev 2017-04-26 13:35:53 Shiz: which build infra, rust’s? 2017-04-26 13:36:00 yeah. 2017-04-26 13:45:53 why I’m not surprised :( 2017-04-26 14:11:23 Quick question, is there a branch for 3.6? If there is a FTBFS on 3.6, where should I fix? 2017-04-26 14:15:45 Hi there, how do I report a broken package in testing without registering yet another one time use account on a bug tracker? 2017-04-26 14:16:13 Or do I just have to go through all this account registration stuff yet again? 2017-04-26 14:19:27 I don't really want to bother the maintainer by sending a mail directly, but it seems like the most reasonable way to do so? 2017-04-26 15:13:43 FooBaer: well, you can write it here on IRC… 2017-04-26 15:13:57 FooBaer: maybe maintainer of the pkg is here, if you’re lucky 2017-04-26 15:19:11 ncopa: https://grsecurity.net/passing_the_baton.php 2017-04-26 15:20:50 TL;DR - Open Source Security, Inc. no longer releasing open source software 2017-04-26 15:28:00 jirutka, ncopa: Quick question, is there a branch for 3.6? If there is a FTBFS on 3.6, where should I fix? 2017-04-26 15:30:16 leitao: no, v3.6 has not been branched yet 2017-04-26 15:30:37 leitao: v3.6 builders builds from the master branch, so the same as edge 2017-04-26 15:30:59 jirutka, makes sense. Thanks! 2017-04-26 15:33:24 oh question on that, for moving packages from testing to community should i just ask in here? 2017-04-26 15:33:34 leitao we branch at the same time as we tag v3.6.0 2017-04-26 15:33:51 second question, for things in testing moving to community, does the builders for community have access to the testing packages? 2017-04-26 15:33:51 mitchty yes, you can ask here 2017-04-26 15:34:19 primary reason i ask is ghc an ghc-bootstrap are a bit unique and have cross compilation for armhf 2017-04-26 15:34:23 and even 2017-04-26 15:34:31 if you mean if you can have dependencies/makedepends in testing, then no 2017-04-26 15:34:41 all dependencies needs to be in community or main 2017-04-26 15:35:14 so it needs bootstrapping? 2017-04-26 15:35:20 ghc needs bootstrap? 2017-04-26 15:35:22 yep 2017-04-26 15:35:31 well for non x86_64 arches 2017-04-26 15:35:41 we have the same issue with go 2017-04-26 15:35:53 if I make a pr on a unmaintained pkg and fix it so it builds, does it stay in unmaintained cuase I didnt move it 2017-04-26 15:36:00 ghc-bootstrap has a cross compiled ghc from a debian install 2017-04-26 15:36:09 that can be used to build x86_64 ghc 2017-04-26 15:36:19 the only reason I didnt move it is I figured someone would to review first 2017-04-26 15:36:31 technically it could probably cross compile as well but i've never tested it 2017-04-26 15:37:15 arch3y: move it and make the modifications in the pr 2017-04-26 15:37:32 i'll see if I can't track fabled down and find out how we'd migrate it 2017-04-26 15:37:47 to community or to other archs? 2017-04-26 15:37:47 ncopa: sure thing I will them out into testing 2017-04-26 15:37:49 its not a huge deal but 8.2 is in rc now so would be nice to migrate it 2017-04-26 15:37:53 community for now 2017-04-26 15:38:04 other arches I don't have much access to test with 2017-04-26 15:38:20 yet, getting an armv8 box someday 2017-04-26 15:41:39 just make sure to get a c2 2017-04-26 15:41:41 when you do 2017-04-26 15:41:53 I can test on armv6 arm7 and aarch64 if needed 2017-04-26 15:49:46 sure, until friday i'll be a bit busy at work with a release, but after then could be pressed into getting it working 2017-04-26 15:50:17 let me know if you need a test on actual arm hardware and Ill be glad to help just ping me 2017-04-26 15:50:29 my ulterior goal is using idris to control gpio stuff, so ghc is just a road bump in most ways :) 2017-04-26 15:50:41 ghc is for haskell right 2017-04-26 15:50:46 yep 2017-04-26 15:51:08 so you could now build say, pandoc, or xmonad 2017-04-26 15:51:08 I geuss you prefer haskell over say python 2017-04-26 15:51:19 yeah pandoc is nicd for markdown conversions 2017-04-26 15:51:30 dependent types are nice 2017-04-26 15:51:40 xmonad is cool looking but Ive never liked haskell personally 2017-04-26 15:51:49 but again I never liked awesome either cuase of lua lol 2017-04-26 15:51:53 but going through a bunch of type theory course books 2017-04-26 15:52:03 yeah but to each his own 2017-04-26 15:52:05 eh, its just a language 2017-04-26 15:52:31 lens in haskell as an example is one of the more interesting things i've ever used 2017-04-26 15:52:31 main issue with things like awesome was they update and break the lang which breaks your config 2017-04-26 15:52:42 which was offputting 2017-04-26 15:52:58 less chance of that in haskell, its all just functions :) 2017-04-26 15:53:15 yeah Ill stick with i3 personally 2017-04-26 15:53:22 I dont have to mess with stuff as much 2017-04-26 15:55:49 ncopa: thanks I have updated all of my prs and moved them 2017-04-26 15:56:11 to limit on the number of prs I make I will hold off on making more until the number comes down a bit 2017-04-26 15:56:19 dont want to overwhelm you guys 2017-04-26 15:58:10 tbh, i just use OS X for my local laptop and run in fullscreen with tmux 2017-04-26 16:01:18 i run alpine on my macbook :) 2017-04-26 16:02:02 nice 2017-04-26 16:02:36 you can use xmonad with osx via xquartz cant you 2017-04-26 16:25:33 hi 2017-04-26 16:25:36 https://grsecurity.net/passing_the_baton.php seems dead from all the traffic ;) 2017-04-26 16:29:16 <^7heo> wow that made no sense. 2017-04-26 16:29:36 <^7heo> s/seems dead from all the traffic ;)/is apparently DDoSed from the ingress/ 2017-04-26 16:29:39 <^7heo> here, fixed. 2017-04-26 16:30:03 <^7heo> and people usually pass a torch... 2017-04-26 16:30:08 <^7heo> if it's already a baton, we're too late. 2017-04-26 16:30:54 <^7heo> (actually my translation isn't perfect either - 'from' should be 'due to') 2017-04-26 16:34:34 well in a relay sprint, the thing you pass is a baton, not a torch 2017-04-26 16:34:49 (else you could seriously burn yourself) 2017-04-26 16:35:47 <^7heo> right 2017-04-26 16:39:13 kunkku: in awall (at least in AL 3.5) log's prefix doesn't support spaces, which is a bit inconvenient (and was quite unexpected) 2017-04-26 16:55:17 http://dl-5.alpinelinux.org/ was unresponsive for some time, but seems fine now 2017-04-26 17:09:45 ncopa: Shiz: https://github.com/libressl-portable/portable/issues/307#issuecomment-297469867 LibreSSL acknowledged bug :) 2017-04-26 18:07:28 jirutka, Shiz: nice work! 2017-04-26 18:07:32 very nice 2017-04-26 18:09:36 I wonder if this is candidate for CVE, I’ve never reported serious security issue before, so I’m curious :) 2017-04-26 18:27:54 przemoc: I will look at the problem 2017-04-26 20:45:32 jirutka: it looks like one to me 2017-04-26 21:54:19 Guys 2017-04-26 21:54:33 Does alpine follow fhs? 2017-04-26 21:59:24 I suggest slightly fixing this patch http://lists.alpinelinux.org/alpine-aports/4573.html in order to actually create /var/mail -> /var/spool/mail, because /var/mail should replace /var/spool/mail according to FHS. 2017-04-26 21:59:53 > However, programs and header files must be changed to use /var/mail. 2017-04-26 22:00:02 From here http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.txt 2017-04-26 22:23:37 FHS is actually a very bad standard and /var/mail is one of the reasons why it's the case 2017-04-26 22:24:24 (not that /var/spool/mail is any better, but the fact that FHS insists on this kind of details without addressing the real problem proves how little thought has gone into it) 2017-04-26 22:35:00 Excuse me? 2017-04-26 22:35:52 FHS mainly defines more-or-less unified hier 2017-04-26 22:36:05 Just like POSIX defines more-or-les unified API 2017-04-26 22:37:03 So I suggest to make maintainters' life easier and follo FHS here 2017-04-26 22:37:24 Because I think opensmtpd is not the only program that expects it to exist 2017-04-26 22:37:28 FHS defines a bunch of semi-random rules that don't actually make much sense and lead to unneeded complexity in many cases. 2017-04-26 22:37:29 AFAIR mailx too 2017-04-26 22:38:34 Well, not following FHS is leading to much complexity right now :) 2017-04-26 22:38:40 The problem is storage layout vs FHS often results in mixing high-volume, low importance files with low-volume, high importance file in the same directory structure. 2017-04-26 22:39:14 In other words, transactional stuff and semi-static database and cache material shouldn't both be in /var/* 2017-04-26 22:39:51 Mail and news really should use /var/spool, which is intended for transactional loads. 2017-04-26 22:41:35 But /var/mail containts user mailboxes 2017-04-26 22:42:41 I hardly see mbox as "transactional load" 2017-04-26 22:51:07 consus: does OpenSMTPD provide configuration option to change location of this directory, e.g. in build time? 2017-04-26 22:51:18 Yes 2017-04-26 22:51:24 The patch is exactly about this 2017-04-26 22:51:45 patching is not a configuration option… 2017-04-26 22:51:55 or what patch do you mean? 2017-04-26 22:51:58 Have you read it? 2017-04-26 22:52:11 I mean a patch to abuild repo 2017-04-26 22:52:14 aha 2017-04-26 22:52:16 It patches APKBUILD 2017-04-26 22:52:23 In order to change mbox path 2017-04-26 22:52:30 <^7heo> wtf 2017-04-26 22:52:52 My point is -- it is better to create one symlink than track all softwre that users this dir 2017-04-26 22:53:17 But /var/mail containts user mailboxes 2017-04-26 22:53:21 that's the very point... it does 2017-04-26 22:53:22 <^7heo> we should do an APKBUILD obfuscation contedt 2017-04-26 22:53:26 <^7heo> contest 2017-04-26 22:53:36 It does 2017-04-26 22:53:45 So? 2017-04-26 22:53:45 and it's a very bad idea to put user mailboxes in any other place than users' homedirs 2017-04-26 22:53:56 for several reasons that you can look up 2017-04-26 22:53:59 Okay 2017-04-26 22:54:08 skarnet: lol, no… 2017-04-26 22:54:17 <^7heo> yeah it is 2017-04-26 22:54:20 quotas being the most common. 2017-04-26 22:54:20 So what about the actual problem? :D 2017-04-26 22:54:28 skarnet: this used to be reasonable like in 1970 2017-04-26 22:54:33 to be perfectly clear, I am not objecting to making a symlink or whatever makes existing, crappy, software happy 2017-04-26 22:54:53 Let's dump the "let's rewrite everything" thing 2017-04-26 22:54:57 skarnet: nowadays you usually don’t have unix account for every email user 2017-04-26 22:54:57 I'm just saying that blindly following FHS is not a good idea 2017-04-26 22:54:59 I'm talking about the nasty reality 2017-04-26 22:55:11 <^7heo> jirutka: in 1970, when ONE hard drive was all you could afford? 2017-04-26 22:55:15 skarnet: so it doesn’t make any sense to store mailboxes in home directories, cause these users does not have any unix home directories 2017-04-26 22:55:21 consus: then you should ignore most of what I'm saying, because I'm very much about rewriting everything that's badly designed 2017-04-26 22:55:24 Where at least mailx and opensmtpd are for now broken is this regard 2017-04-26 22:55:29 and it so happens that FHS is badly designed 2017-04-26 22:55:29 The nasty reality is that FHS is very poorly conceived and does not scale well to real workloads. 2017-04-26 22:56:10 <^7heo> jirutka: actully using UNIX users for mail isn't a bad idea 2017-04-26 22:56:15 Fix the root cause, not the symptom. 2017-04-26 22:56:21 if OpenSMTPd provide configuration option to change this, and it does, then what exactly is broken here? that it uses different *default* option than we want? 2017-04-26 22:56:23 jirutka: if you don't follow the 1 uid = 1 email user way, then you have no business storing mail under /var/mail anyway. 2017-04-26 22:56:28 <^7heo> it's like using UNIX users fr db access 2017-04-26 22:56:30 <^7heo> for* 2017-04-26 22:56:32 no, there’s nothing broken here 2017-04-26 22:56:43 And since I fail to see any technical reasons not to create /var/mail -> /var/spool/mail for Alpine in order to stop getting weird bugs I suggest to do so 2017-04-26 22:56:45 I mean with OpenSMTPD and our approach 2017-04-26 22:56:54 <^7heo> that's what postgresql does and it's perfect 2017-04-26 22:56:58 I’m not talking about FHS, that’s broken by design, but that’s to totally diferent discussion 2017-04-26 22:57:04 It just does not work 2017-04-26 22:57:18 /var/spool/mail is not the same thing as the user mailbox. 2017-04-26 22:57:36 So you may break other things, like actual mail spooling. 2017-04-26 22:57:41 <^7heo> TemptorSent: I think the point was about /var/mail 2017-04-26 22:57:42 How? 2017-04-26 22:57:47 mail spooling in /var/spool is so 1990 2017-04-26 22:58:16 ^7heo: mapping unix users to DB users is only on of many options in Pg, it makes sense e.g. for user postgres, it does not for almost all other use cases 2017-04-26 22:58:18 /var/spool/mail is used for both now 2017-04-26 22:58:23 consus Because the mail spool and the user inboxes may conflict. 2017-04-26 22:58:37 I cannot remember any bugs related to this 2017-04-26 22:58:44 Can you provide some additional info? 2017-04-26 22:58:45 Yeah, that's bad form. 2017-04-26 22:58:50 well, with a /var/mail symlink to /var/spool/mail, it would *still* be used for both 2017-04-26 22:58:55 I mean it works fine everywhere 2017-04-26 22:59:10 that’s not a valid argument imo… 2017-04-26 22:59:13 In OpenBSD, in Gentoo, in CentOS 2017-04-26 22:59:14 Sure, as long as you don't run out of space. 2017-04-26 22:59:21 <^7heo> jirutka: for mail too 2017-04-26 22:59:34 Well 2017-04-26 22:59:37 The problem is if a user mailbox grows too large, ALL incoming mail fails. 2017-04-26 22:59:41 The fix does exactly te same thing 2017-04-26 22:59:51 Real world problems here, not toybox size. 2017-04-26 22:59:55 I mean the proposed by the maintainer 2017-04-26 23:00:02 *the one 2017-04-26 23:00:05 if /var/spool/mail and /var/mail are semantically different, as TemptorSent says, if I understand that correctly, and if this still applies at 21st century, then symlinking them doesn’t look like a good solution imo… 2017-04-26 23:00:16 Errr 2017-04-26 23:00:22 Hear me out please 2017-04-26 23:00:24 how about doing things right and putting mail for /etc/passwd users into their homedir, and for non-/etc/passwd users, properly configuring the MDA so it has sane defaults? 2017-04-26 23:00:31 b/c that would change it for all, not just OpenSMTPD 2017-04-26 23:00:33 The ix in APKBUILD does the *VERY SAME THING* 2017-04-26 23:00:43 But with compile-time option 2017-04-26 23:00:50 no, thhat’s different 2017-04-26 23:00:54 No it's not 2017-04-26 23:01:05 If you want to have things fail sanely, you want /var/spool/mail on a different partition/dataset than /var/mail or $HOME/mail 2017-04-26 23:01:07 The opensmtpd will deliver the mail there 2017-04-26 23:01:07 hey, this is not OpenBSD 2017-04-26 23:01:23 OpenSMTPD does not have exclusive rights for /var/mail or /var/spool/mail, does it? 2017-04-26 23:01:29 No it does not 2017-04-26 23:01:44 how can we know if some other software use one of these as well…? 2017-04-26 23:01:59 You can get away with doing it wrong, but expect things to REALLY break when something gets fubared, not just fail to deliver to the impacted user. 2017-04-26 23:02:04 ERr 2017-04-26 23:02:07 Because it does! 2017-04-26 23:02:09 telling OpenSMTPD to use /var/spool/mail instead of /var/mail is local setting for single app, making symlink aaffects global space 2017-04-26 23:02:20 Say mailx uses /var/mail 2017-04-26 23:02:33 <^7heo> ok too much spam here for this hour of the day 2017-04-26 23:02:40 <^7heo> have fun trolling everyone 2017-04-26 23:02:43 ^7heo: you're one to talk 2017-04-26 23:03:01 <^7heo> skarnet: nah actually 2017-04-26 23:03:10 consus: please continue 2017-04-26 23:03:11 for once there's a mildly interesting discussion on what the right thing is 2017-04-26 23:03:16 The point is simply that the mail spool should be used for the transactional load, and the users mailboxes should not be in the same place on a production box. 2017-04-26 23:03:36 <^7heo> skarnet: maybe it's my screen being to small 2017-04-26 23:03:47 <^7heo> skarnet: but I can't follow shit 2017-04-26 23:03:54 your screen? is that how you call it? 2017-04-26 23:04:00 ACTION is already out 2017-04-26 23:04:02 *LOL* 2017-04-26 23:04:29 <^7heo> skarnet: that's too far fetched for being funny 2017-04-26 23:04:49 <^7heo> skarnet: plus, I am actually annoyed at my phone 2017-04-26 23:05:09 phone? ok, it IS your screen being too small 2017-04-26 23:05:10 <^7heo> it sucks a LOT. I guess I cnt easily be amused anyway 2017-04-26 23:06:25 <^7heo> anyway, I am being offtopic; please continue your discussion on FHS and how to do mail in the least bad way 2017-04-26 23:06:28 <^7heo> o/ 2017-04-26 23:06:37 ANYWAY. If there really is a problem with opensmtpd or whatever else in their default config, the right thing is to check the config and make sure they have sane defaults. 2017-04-26 23:06:41 /var/spool/mail is for mail queues; /var/mail is for mailboxes 2017-04-26 23:06:50 And sane defaults means not FHS. 2017-04-26 23:07:39 this is the way it has always been done, and I can go any way you want for this: nixos, fhs, sendmail, opensmtpd, postfix, qmail 2017-04-26 23:07:39 awilfox : Correct -- you're expected to clean out the spool when you check your mail. It's essentially 'Incoming'. 2017-04-26 23:07:42 awilfox: yes. (If you're using a badly designed MTA.) 2017-04-26 23:08:02 TemptorSent: no, OUTGOING queues 2017-04-26 23:08:04 TemptorSent: no. 2017-04-26 23:08:14 awilfox: stop typing faster than me! 2017-04-26 23:08:20 <^7heo> huhu 2017-04-26 23:08:21 TemptorSent: what the fuck is an incoming queue, that isn't how this works; mail is stored in either ~/.maildir or /var/mail/$USER 2017-04-26 23:08:39 or ~/Mailbox 2017-04-26 23:08:43 /var/spool/mail/$USER = incoming mail queue. 2017-04-26 23:08:50 <^7heo> or ~/Mail 2017-04-26 23:09:15 Gentoo and CentOS symlinks /var/mail to /var/spool/mail 2017-04-26 23:09:25 TemptorSent: why is an MDA queuing incoming mail? unless maildir is full, in which case it should be either refusing to deliver (Sorry, that mailbox is full) or screaming at the postmaster 2017-04-26 23:09:45 jirutka: yeah, so Gentoo and CentOS are doing something idiotic, what else is news? 2017-04-26 23:10:00 jirutka: I don't care what broken distros do. this about doing the Right Thing, what users and MTAs/MDAs expect, not being compatible with brain damage 2017-04-26 23:10:15 awilfox: It's pretty common when something such as POP3 is in use. 2017-04-26 23:10:24 I’m not sure if it’s really idiotic… 2017-04-26 23:10:26 pop3 should read from user mailboxes 2017-04-26 23:10:34 TemptorSent: no, I have run pop3 servers, the pop3d reads from maildir. 2017-04-26 23:10:42 awilfox: So it's you who will track down every program in tree and test that it does not use /var/mail, right? 2017-04-26 23:11:26 consus: we're not very much for passive-aggressiveness around here 2017-04-26 23:11:28 awilfox: I'm referring to having the mailbox full and needing to queue files. 2017-04-26 23:11:28 consus: I don't know if that would be accepted even if I did it 2017-04-26 23:11:52 skarnet: So don't be one :) 2017-04-26 23:12:06 I'm sorry? 2017-04-26 23:12:07 We just discussed it with jirutka 2017-04-26 23:12:12 awilfox: Although such configs are much less common these days because most everyone is always-on. 2017-04-26 23:12:20 E.g. the mail program searches /var/mail for it's mail 2017-04-26 23:12:21 So 2017-04-26 23:12:38 If the patch in question will be accepted then opensmtpd cannot be used with mail 2017-04-26 23:12:48 this is just making me feel like I need to /disconnect freenode quicker tbh; forget I even contributed my opinion 2017-04-26 23:12:50 So we have to patch mail too 2017-04-26 23:12:52 you will break what you will 2017-04-26 23:12:59 have ~lots~ of fun 2017-04-26 23:13:01 awilfox: please don't leave me 2017-04-26 23:13:03 I need you 2017-04-26 23:13:33 it’s just damn directory location, what matters the most here what most of the programs expect 2017-04-26 23:13:41 /var/spool/mqueue is outgoing, at least for sendmail. 2017-04-26 23:13:45 jirutka: Finally, the voice of reason 2017-04-26 23:14:01 jirutka: the job of a *distribution* is to *configure* programs, to implement a *distribution policy* 2017-04-26 23:14:12 preferably a sane policy 2017-04-26 23:14:14 skarnet: yes, of course 2017-04-26 23:14:23 so how about doing that 2017-04-26 23:14:29 instead of catering to brain damage 2017-04-26 23:14:51 skarnet: You have the tree publicly available. We want patches, and we want them now. 2017-04-26 23:14:51 skarnet: but for what reasons do you configure /var/spool/mail as right policy and /var/mail as bad policy? 2017-04-26 23:15:08 <^7heo> gosh so much tension in here 2017-04-26 23:15:17 jirutka: I don't find either is good policy 2017-04-26 23:15:34 skarnet: yeah, see? 2017-04-26 23:15:52 <^7heo> consus: who are you exactly to demand patches? let alone now... it's the first time I see you here. 2017-04-26 23:16:03 ^7heo: no it's not 2017-04-26 23:16:11 <^7heo> yeeeess it is 2017-04-26 23:16:16 ^7heo: No 2017-04-26 23:16:20 that's why I don't care about symlinks and I'm saying FHS is bad: correct policy for MTAs and MDAs does not involve either 2017-04-26 23:16:26 ^7heo: And I have proofs, my friend 2017-04-26 23:16:28 <^7heo> you can't tell me what I see for the first time 2017-04-26 23:16:33 ^7heo: Oh I can 2017-04-26 23:16:39 <^7heo> I'm everything but your friend 2017-04-26 23:16:43 <^7heo> trust me 2017-04-26 23:16:48 ^7heo: You are now 2017-04-26 23:16:50 <^7heo> I know who you are 2017-04-26 23:16:57 Ideally, mail actually delivered to users (as opposed to left for them to pick up) should go directly to their home directories. 2017-04-26 23:17:11 TemptorSent: that's right. 2017-04-26 23:17:21 Or to a MDA-configured database, for non-/etc/passwd users. 2017-04-26 23:17:37 skarnet: we both know that FHS is broken by design, but we still use it in Alpine, deal with that; if you see both options as bad, then it’s about choosing less evil for now, until we finally reject FHS and redesign complete system 2017-04-26 23:17:50 and that INCLUDES mail "left for them to pick up" 2017-04-26 23:18:01 skarnet: I see as less evil to use the location which most programs expect 2017-04-26 23:18:01 Mail that is sitting in /var/spool/mail is basically sitting in the po box, waiting for the owner to come pick it up, but it can't be delivered directly. 2017-04-26 23:18:47 jirutka: delivering mail to homedirs isn't exactly revolutionary or FHS-breaking 2017-04-26 23:18:58 /var/mail and /var/spool/mail can remain in the base layout for all I care 2017-04-26 23:18:59 skarnet: /var/spool/mail is appropriate for virtual users and such where there is no unix home directory. 2017-04-26 23:19:08 skarnet: we use /run instead of /var/run and still keep /var/run symlink to /run; isn’t this quite the same? 2017-04-26 23:19:17 not at all 2017-04-26 23:20:35 TemptorSent: I, too, have run pop3d and imapd servers, and like awilfox, I can assure you that those servers will look inside user's mailboxes, not inside whatever "pobox" you're thinking of. 2017-04-26 23:21:37 jirutka: /run makes sense, this is one of the few creations from main distros that actually make sense - because you need a rw tmpfs before mounting filesystems 2017-04-26 23:22:06 skarnet: What did you do when you didn't have real users and you were using vpop? 2017-04-26 23:22:30 skarnet: Say 12,000 or so mail-only users with no unix accounts. 2017-04-26 23:22:32 "You have the tree publicly available. We want patches, and we want them now." 2017-04-26 23:22:39 and its function basically duplicates the function of /var/run, except you need it before /var, so creating /run as a tmpfs and making /var/run a symlink to it for compatibility makes perfect sense. 2017-04-26 23:22:39 consus: do you have a commit bit on the tree 2017-04-26 23:22:48 consus: can you directly commit to alpine 2017-04-26 23:22:59 awilfox: No, I can't 2017-04-26 23:23:02 awilfox: Why? 2017-04-26 23:23:09 okay, so the "we" you speak of is the community 2017-04-26 23:23:32 TemptorSent: it's exactly what I have right now, and I configured the MDA to use its own place. 2017-04-26 23:23:34 consus: because that behaviour would be enough for me to /part #alpine-* and stop recommending the distro to anyone, if you were an actual developer for it and actually were speaking for the project itself 2017-04-26 23:23:38 I speak for people who have broken software because some dude wants ponies and rainbows :) 2017-04-26 23:24:11 TemptorSent: I use vpopmail, and created a /home/vpopmail place to store the user mailboxes (actually maildirs) 2017-04-26 23:24:14 skarnet: Yeah, it's obviously saner to use a locally configured directory. 2017-04-26 23:24:27 And I really want to remove that /var/mail -> /var/spool/mail from my ansible configuration. Because that's what package managers are for :D 2017-04-26 23:24:55 awilfox: wtf? why are you escalating this…? 2017-04-26 23:25:21 awilfox: we’re just discussing it 2017-04-26 23:25:42 jirutka: I was not the one making unreasonable demands from the community 2017-04-26 23:25:56 awilfox: You take it too serious 2017-04-26 23:25:58 and I will not apologise for calling out abusive behaviour in projects 2017-04-26 23:26:07 that is how you end up with gentoo 2017-04-26 23:26:32 skarnet: Got it - I used to run several medium-to-large mail servers, and we broke things out using ldap on a number of linked servers, so /var/spool/mail ended up being the best bet. 2017-04-26 23:26:33 not every version of linux is everyones cup of tee 2017-04-26 23:26:38 No, Gentoo is a very different beast. They so obsessed with politeness and rules they stuck with the enormous lack of manpower. 2017-04-26 23:26:40 as skarnet said, I have a directory (mine is /srv/vpopmail for virtual users, but that's just down to my own preference) 2017-04-26 23:26:47 everyone has an opinin the devs will build it how they see fit 2017-04-26 23:27:16 the correct default behaviour would be to use /var/mail and allow users to change it 2017-04-26 23:27:18 TemptorSent: lolldap - no wonder you had trouble :D 2017-04-26 23:27:26 cite: 17 years of maintaining email servers 2017-04-26 23:28:06 <^7heo> consus: no awilfox does not take it oo serious 2017-04-26 23:28:08 awilfox: no, the correct default behaviour would be to choose a distro policy, stick to it by configuring all the MDAs' APKBUILDs, and document it 2017-04-26 23:28:27 and /var/mail is a bad technical choice 2017-04-26 23:28:28 <^7heo> consus: we're many finding your behavior despicable 2017-04-26 23:28:38 <^7heo> too serious* 2017-04-26 23:28:43 awilfox: do you know when I sent the last patch to Gentoo? when some reviewer wanted from me to use some specific style of commit message that I haven’t found in last 100 commits in the aports and when I pointed this, he senselessly assumed that I’m arguing with commit style in my fork, not official aports, that would obvious don’t make any sense, so I’ve responsed that I’m not an idiot to do that… and he sent me email with serious 2017-04-26 23:28:43 warning about violating Code of Conduct 2017-04-26 23:29:14 Oh my god 2017-04-26 23:29:21 Yes 2017-04-26 23:29:29 I was threated with a goddamn lawsuite 2017-04-26 23:29:33 In Gentoo 2017-04-26 23:29:36 awilfox: you know as much as I do that most users will not change the default, and that's why distros must provide good defaults 2017-04-26 23:30:03 skarnet: what is your rationale for /var/mail being a bad technical choice? 2017-04-26 23:30:27 That was fun 2017-04-26 23:30:41 awilfox: I didn’t call him idiot, I just asked him to not treat me as an idiot or something in this sense… so please, don’t take it so seriously ;) 2017-04-26 23:30:59 that is the standard, and beyond just being the standard, it is where it makes the most sense imo 2017-04-26 23:31:13 enforcing that root delivers the mail (for writing rights in /var/mail) instead of the mda running as the user; enforcing mbox format; making quotas more difficult to compute 2017-04-26 23:31:38 as a qmail user, you should know all this :) 2017-04-26 23:31:41 > for writing rights in /var/mail 2017-04-26 23:31:43 Whaat? 2017-04-26 23:31:48 skarnet: why would root need to deliver the mail? that is why qmail runs as its own uid. 2017-04-26 23:31:53 OpenSMTPD uses privsep for that 2017-04-26 23:31:59 postfix uses privsetp for that afair 2017-04-26 23:32:07 consus: heh, funny, I’ve heard quite recently that Gentoo has serious problem with not enough contributors… maybe that’s why 2017-04-26 23:32:16 jirutka: Yep 2017-04-26 23:32:29 jirutka: They're too elite for the regular people 2017-04-26 23:32:37 if you want to be able to create a mailbox in /var/mail, you need to be root 2017-04-26 23:32:53 jirutka: I got banned on irc for cursing while DEBUGGING THEIR PACKAGE BUGS 2017-04-26 23:33:39 qmail-local runs as the user it's delivering to, because it only has to write to the user's homedir, which is guaranteed writable for the user 2017-04-26 23:33:39 skarnet: drwxrwsr-t 2 root mail 120 Jan 9 2016 /var/spool/mail 2017-04-26 23:33:41 jirutka: consus: I am ex-gentoo. was run out by the leadership telling me to "stop being so controversial". the controversy I started? filing a coc complaint after some other dev followed me to personal blog and made bunch of slurs because I am not in perfectly standard sexuality 2017-04-26 23:33:42 skarnet: Yeah 2017-04-26 23:33:45 skarnet: Right 2017-04-26 23:33:51 skarnet: Ever heard of groups? :D 2017-04-26 23:35:12 drwxrwx--- 11 qmail qmail 4096 May 25 2014 /var/mail 2017-04-26 23:35:13 of course you can do that, but that doesn't help with the same problem 2017-04-26 23:35:38 namely, if an attacker takes control of the MDA, they can read every user's mailbox 2017-04-26 23:35:39 if they are virtual users, it can't be owned by any other user. 2017-04-26 23:35:51 I thought that was the whole point of this discussion 2017-04-26 23:35:52 virtual users 2017-04-26 23:36:08 if they have real logins on the box, deliver to ~/.maildir and get off my lawn 2017-04-26 23:36:24 awilfox: it's exactly what I've been saying from the start 2017-04-26 23:36:27 but those two configurations are very difference 2017-04-26 23:36:30 deliver to the homedir 2017-04-26 23:36:30 different* 2017-04-26 23:36:38 If an attacker gains user uid it can do pretty much everything. So delivering to $HOME is no less dangerous. 2017-04-26 23:36:50 consus: you misunderstand me. 2017-04-26 23:37:11 Perhaps. Could you clarify your point? 2017-04-26 23:37:15 with the MDA running as a user, if an attacker gains control of it, it can read that user's mail. 2017-04-26 23:37:22 Yes 2017-04-26 23:37:40 with the MDA running as group mail and every mail in /var/mail, if an attacker gains control of it, it can read EVERYONE's mail. 2017-04-26 23:37:55 That's not quite true 2017-04-26 23:38:08 $ ls -l /var/spool/mail 2017-04-26 23:38:08 total 0 2017-04-26 23:38:09 -rw------- 1 consus mail 0 Jan 9 2016 consus 2017-04-26 23:38:21 skarnet: so then there is important thing to discuss here: if you are ISP, let us say you serve San Francisco - area has 1.3m people. you will probably have more than 65535 users of your ISP (if you are good). what do you do for email? you can't give them all uids on the mail box, unless maybe you have a bunch of mail boxes... 2017-04-26 23:38:31 and how does that mailbox get appended 2017-04-26 23:38:54 very simple -- opensmtpd spawns a process with uid = user-users-uid 2017-04-26 23:39:02 *your-user-uid 2017-04-26 23:39:15 so you use virtual users, i.e. logins are in a db, and mail is delivered to: ....? 2017-04-26 23:39:22 awilfox: of course you need virtual users, that's not the point 2017-04-26 23:39:34 skarnet: where is mail delivered to virtual users? who owns those boxes? 2017-04-26 23:39:48 And *YOU* can create a mbox in /var/spool/mail without bein root too 2017-04-26 23:39:53 awilfox: who cares? it's MDA-specific policy. 2017-04-26 23:39:54 Because you're in the mail group 2017-04-26 23:40:00 That's what I'm talking about 2017-04-26 23:40:34 So everything goes in your uid space 2017-04-26 23:40:50 consus: the MDA runs as uid user and group mail? 2017-04-26 23:41:07 The MDA runs as root 2017-04-26 23:41:11 Ah 2017-04-26 23:41:12 No 2017-04-26 23:41:15 MDA runs uid user 2017-04-26 23:41:16 Sorry 2017-04-26 23:41:23 skarnet: I think the point is that most people running alpine are not running sdf.org-style servers where people have uids, they are running webby bullshit like docker and ruby and are going to more than likely have virtual users. so alpine should default to that config (but hopefully the agent makes it easy to reconfigure to ~ for the good case) 2017-04-26 23:41:24 and group mail 2017-04-26 23:42:51 The daemon runs as root, the MTA runs as smtpd user, the queue handler runs as smtpq user 2017-04-26 23:42:54 awilfox: I totally understand what you're saying, and I'm not advocating a lack of virtual users, at all. I'm just saying /var/mail may not be the best place to store mail dbs for virtual users. But then again, it's a suitable place too, and I really don't care. 2017-04-26 23:43:05 The MDA runs as your-user-uid 2017-04-26 23:44:57 consus: ok, I don't see any obvious problems with that setup. Still, it's way more complicated than it needs to - if the MDA just delivers in a user's homedir, it doesn't need specific group rights, you don't need a sticky bit, etc. etc. And I don't like things that are more complicated than they need to be - chances are there are evil corner cases we don't see. 2017-04-26 23:45:56 skarnet: You can drop the sticky bit 2017-04-26 23:46:11 skarnet: It's Gentoo thing that does not have to be there for the whole thing to work 2017-04-26 23:46:18 no you can't: you don't want an attacker to delete other people's mailboxes 2017-04-26 23:46:28 Err 2017-04-26 23:46:33 Yes, you do not want 2017-04-26 23:46:47 So let them be consus:consus instead of consus:mail 2017-04-26 23:47:08 Since MDA delivers as your UID it doesn't care for the group 2017-04-26 23:47:23 and now you can't create mailboxes 2017-04-26 23:47:26 Why? 2017-04-26 23:47:30 /var/lib/mail 2017-04-26 23:47:36 0770 2017-04-26 23:47:40 No sticky bit 2017-04-26 23:47:49 Your user in group mail 2017-04-26 23:47:56 Can't see what's wrong with that 2017-04-26 23:48:29 what are the rights for /var/mail 2017-04-26 23:48:34 0770 2017-04-26 23:48:42 uid:gid 2017-04-26 23:48:49 Say root:mail 2017-04-26 23:49:44 if the MDA has group mail rights, it can delete other people's mailboxes 2017-04-26 23:49:56 if it doesn't, it can't create mailboxes 2017-04-26 23:50:02 (unless it's running as root) 2017-04-26 23:50:13 Err 2017-04-26 23:50:23 Okay 2017-04-26 23:50:26 Let's try it out 2017-04-26 23:51:12 Well yeah 2017-04-26 23:51:14 It can 2017-04-26 23:51:31 I see your point 2017-04-26 23:53:28 Even sticky is a problem, because you can create a mailbox that collides with a username that has no mail currently, and either receive their mail (if the MDA doesn't check) or DOS them. 2017-04-26 23:54:06 that's the corner case I was talking about 2017-04-26 23:54:22 You cannot create a mailbox or another user 2017-04-26 23:54:29 Yeah, and it's an ugly one that has been used for real exploits. 2017-04-26 23:54:37 *for 2017-04-26 23:54:46 If MDA is running with uid of that user 2017-04-26 23:54:55 touch /var/mail/foo 2017-04-26 23:54:58 Done. 2017-04-26 23:55:01 Err 2017-04-26 23:55:04 Permission denied 2017-04-26 23:55:05 :D 2017-04-26 23:55:14 not if you have group mail rights 2017-04-26 23:55:16 GID. 2017-04-26 23:55:30 Also you forgot about the ownership 2017-04-26 23:55:38 a compromised MDA can DoS other people 2017-04-26 23:56:03 Or worse, allow a leak. 2017-04-26 23:56:24 iow, /var/mail is shit, which I've been saying for an hour now 2017-04-26 23:56:41 so I'll now retire for the night. 2017-04-26 23:57:04 It's only appropriate for virtual users IMHO, where the perms have nothing to do with the user. 2017-04-26 23:57:43 If mda is running with pwuid:pwgid it cannot write to another users file 2017-04-26 23:57:44 And that should probably be in a locally configured place. 2017-04-26 23:58:09 Sure it can, all you have to do is set the perms to 666 2017-04-26 23:58:33 Right 2017-04-26 23:58:36 Good point :D 2017-04-26 23:58:37 Anyway, I'm off for dinner.. 2017-04-26 23:58:55 There are a lot of ugly corner cases to consider. 2017-04-26 23:59:08 Off to sleep 2017-04-26 23:59:27 Or at least for something that is left of it 2017-04-27 00:00:19 Funny 2017-04-27 00:02:05 OpeBSD has /var/mail as root:wheel 0755 2017-04-27 00:02:43 So I guess opensmtpd first touches the file as root and then deliver as user 2017-04-27 06:26:31 jirutka: so 2017-04-27 06:26:58 jirutka: how do you feel about the test suite policy change causing us to bag a libressl CVE 2017-04-27 06:27:01 lol 2017-04-27 06:30:26 kaniini: https://media1.giphy.com/media/l2SpKjO20hPyhr1fy/giphy.gif 2017-04-27 06:30:58 what. 2017-04-27 06:34:42 kaniini, did you forget about https://github.com/alpinelinux/abuild/pull/16 ? ;) 2017-04-27 06:35:33 xentec: handled 2017-04-27 06:35:51 kaniini: you asked how jirutka feels about this, so here is a react gif :< 2017-04-27 06:36:57 thanks 2017-04-27 06:40:54 can't wait 2017-04-27 06:41:02 for my new build machine to arrive 2017-04-27 06:41:18 quad E7 4850v4 2017-04-27 06:41:37 128 threads 2017-04-27 06:41:45 gonna build all of alpine in like an hour 2017-04-27 06:41:50 kaniini, did you write the apkbuild at http://patchwork.alpinelinux.org/patch/3327/ ? 2017-04-27 06:42:08 fabled: nope 2017-04-27 06:42:21 if i did, i would just commit it, wouldn't i? :p 2017-04-27 06:42:22 it says you did ;) 2017-04-27 06:42:37 the other one is similar in the same series 2017-04-27 06:42:58 trying to go through some of the patchworks/githubPR backlog now 2017-04-27 06:43:15 should probably look at go1.8 2017-04-27 06:43:21 i took care of linux-hardened rename 2017-04-27 06:43:22 it's in both places 2017-04-27 06:43:36 kaniini, i saw. thanks. hope it does not cause any other issues 2017-04-27 06:44:06 kaniini - any progress on kernel packaging changes? 2017-04-27 06:44:13 TemptorSent: that isnt happening until 3.7 2017-04-27 06:44:36 kaniini: Damn, okay - I think I found a work around, but it means the kernel isn't actually managed by apk. 2017-04-27 06:44:42 (also apparently matrix's irc relay is messed up, so back to using an oldschool irc client for now :/) 2017-04-27 06:45:05 (and it's still ugly and fragile in places) 2017-04-27 06:45:42 fabled: pickfire is the person who submitted those patches you linked 2017-04-27 06:46:09 pickfire, care to fix the Contributor/Maintainer fields of the patches? 2017-04-27 06:46:34 I'm seeing multiple requests daily for working zfs initfs and means of building in modules. 2017-04-27 06:46:35 fabled: Where? 2017-04-27 06:46:39 Which one? 2017-04-27 06:46:50 pickfire, http://patchwork.alpinelinux.org/patch/3327/ 2017-04-27 06:47:16 Ahhhhh 2017-04-27 06:47:27 Sorry, I copied straight from his name. 2017-04-27 06:47:30 and 3328 2017-04-27 06:47:38 i close them as changes requested 2017-04-27 06:47:46 Can't fix right now, not in alpine. 2017-04-27 06:48:01 no prob 2017-04-27 06:48:08 resend when you get a moment 2017-04-27 06:52:12 Okay, probably when I restart from arch. 2017-04-27 06:54:11 kaniini, if your still here I'd like you to look at another simple PR of mine https://github.com/alpinelinux/abuild/pull/17 2017-04-27 06:54:20 *you're 2017-04-27 06:54:55 i prefer ncopa look at that one 2017-04-27 06:59:19 kaniini: huh, you keep this E7 at home? 2017-04-27 06:59:21 ACTION jelly 2017-04-27 06:59:34 scadu: yes 2017-04-27 06:59:43 scadu: will be the plan once i set it up 2017-04-27 07:00:55 scadu: i have a rack in a closet 2017-04-27 07:01:03 scadu: with dedicated 20A 240V circuit 2017-04-27 07:03:01 scadu: my goal is to have at least one of every arch alpine supports, an older image of the setup when i was racking an edgerouter pro (planned mips64 porting box); https://mastodon-dereferenced-org.s3-us-east-2.amazonaws.com/media_attachments/files/000/000/003/original/26a2dcdb07cc8ba6?1492243620 2017-04-27 07:03:14 scadu: the E7 will be 4U though, so it is going to be annoying to haul upstairs :/ 2017-04-27 07:04:08 Nice, you'll be able to make coffee on top of that sucker :) 2017-04-27 07:04:28 that closet is like sauna already tbh 2017-04-27 07:05:12 humm 2017-04-27 07:05:26 Soekris (the company which makes the NET4801 and other machines like that) is shutting down 2017-04-27 07:05:49 that sucks 2017-04-27 07:06:34 Sounds like your closet needs a dedicated 2t ac unit! 2017-04-27 07:07:25 the powers that be (HOA) will not allow such things unfortunately 2017-04-27 07:09:03 you are not even allowed to have a window unit 2017-04-27 07:09:07 100% 2017-04-27 07:09:45 kaniini WTF? What kind of concentration camp are you living in? 2017-04-27 07:10:14 TemptorSent: it is kind of stupid 2017-04-27 07:10:17 TemptorSent: because 2017-04-27 07:10:28 Claim it as a medical necessity since you'll end up dying of heat stroke otherwise! 2017-04-27 07:10:39 next door to me, some young couple moved in 2017-04-27 07:11:01 and their kids kicked out some chunk of cast iron metalwork 2017-04-27 07:11:05 off their balcony 2017-04-27 07:11:13 and i guess nothing happened over it 2017-04-27 07:11:22 but 2017-04-27 07:11:28 to be honest with you 2017-04-27 07:11:42 Ah, selective enforcement, how quaint. 2017-04-27 07:12:10 we have a 3x industrial chillers for all of the units 2017-04-27 07:12:16 or is it 4 2017-04-27 07:12:17 i forget 2017-04-27 07:12:28 two, one at each parking lot. 2017-04-27 07:12:32 we have plenty of plant, i just do not wish to keep the door open 2017-04-27 07:12:35 because it is loud 2017-04-27 07:12:50 and it's not so hot in there that it's bad for the servers 2017-04-27 07:13:10 like literally to enter that closet 2017-04-27 07:13:15 you really should wear earplugs 2017-04-27 07:13:32 and they did install a power circuit for me, very useful that 2017-04-27 07:13:37 i am sure they regret this now 2017-04-27 07:13:38 Ouch, yeah - that's bad. Time to think about liquid cooling if you're going to add any more! 2017-04-27 07:13:38 LOL 2017-04-27 07:13:58 (actually i think they are probably paying flat rate for the power) 2017-04-27 07:14:58 TemptorSent: honestly, the largest problem i have is millenials feeling that my parking spaces are their parking spaces 2017-04-27 07:15:11 TemptorSent: even though i pay money to lease them 2017-04-27 07:15:35 First world problems :) 2017-04-27 07:16:14 it is actually a problem, because very frequently when my parking spaces are hijacked it is usually about to hail 2017-04-27 07:16:28 this happens to awilfox too 2017-04-27 07:17:07 kaniini: it sure doesn't happen to me any more 2017-04-27 07:17:13 kaniini: since the office gave me tow-away stickers 2017-04-27 07:17:14 Wow, tough neighborhood :) 2017-04-27 07:17:25 awilfox: i can get tow-away stickers???????? 2017-04-27 07:17:27 kaniini: yep 2017-04-27 07:17:35 god 2017-04-27 07:17:41 i've just been using a traffic cone 2017-04-27 07:17:49 to block the space that is not immediately in use 2017-04-27 07:18:13 hi kaniini 2017-04-27 07:18:24 re grsec->hardened rename 2017-04-27 07:18:28 oh no 2017-04-27 07:19:01 i've upgraded my edge box and ended up without kernel (it's expected) 2017-04-27 07:19:09 rnalrd: hmm... apk upgrade --available should be pulling it in 2017-04-27 07:19:10 i installed the hardeden flavor than 2017-04-27 07:19:15 then* 2017-04-27 07:19:32 rnalrd: how did you upgrade 2017-04-27 07:19:33 my point is 3.5->3.6 hard disk installatinos 2017-04-27 07:19:41 apk upgrade -Ua 2017-04-27 07:19:48 hmm 2017-04-27 07:19:55 was linux-grsec in /etc/apk/world ? 2017-04-27 07:19:59 yes 2017-04-27 07:20:06 this smells like a bug 2017-04-27 07:20:12 shouldn't we add "provides=linux-grsec" 2017-04-27 07:20:20 because linux-hardened provides linux-grsec=4.9.24-r1 2017-04-27 07:20:25 and do the same for all *-grsec packages 2017-04-27 07:20:27 so it should be favored for upgrade 2017-04-27 07:20:29 yes 2017-04-27 07:20:31 i did that 2017-04-27 07:20:35 the provides entries are there 2017-04-27 07:20:58 sorry i did not check 2017-04-27 07:21:04 so i'm confused 2017-04-27 07:21:12 i thought they were not there since my kernel got purged 2017-04-27 07:21:19 fabled: i think there is a bug with provides on upgrade 2017-04-27 07:21:28 i'm on edge hdd install 2017-04-27 07:21:53 an alternate solution would be to do what we did with pkg-config 2017-04-27 07:21:59 which is provide an explicit virtual 2017-04-27 07:22:06 now in my world I have: 2017-04-27 07:22:09 linux-grsec 2017-04-27 07:22:13 linux-hardened 2017-04-27 07:22:16 -- 2017-04-27 07:22:19 weird 2017-04-27 07:22:42 apk policy linux-grsec ? 2017-04-27 07:23:00 no output 2017-04-27 07:23:29 $ sudo apk add linux-grsec 2017-04-27 07:23:31 (1/1) Installing linux-hardened (4.9.24-r1) 2017-04-27 07:23:35 what happens when you do that? 2017-04-27 07:24:00 "OK" 2017-04-27 07:24:11 umh 2017-04-27 07:24:12 hmmmm 2017-04-27 07:24:19 it works with apk upgrade for two times 2017-04-27 07:24:27 first apk upgrade removes linux-grsec 2017-04-27 07:24:35 kaniini: Hmm, I wonder how hard it would be to tap a duct and extend it directly into your server closet? 2017-04-27 07:24:37 second apk upgrade installs linux-hardened 2017-04-27 07:24:58 TemptorSent: pretty hard, they are overhead 2017-04-27 07:25:06 fcolista, I had to explicitly add linux-hardened here 2017-04-27 07:25:22 not here rnalrd 2017-04-27 07:25:24 let me pastebin the commands 2017-04-27 07:25:27 this smells like an apk bug 2017-04-27 07:25:42 i think provides are not properly considered when calculating the upgrade transaction 2017-04-27 07:25:52 kaniini: Hmm, depends on how tight the space is, but that might be a good option! 2017-04-27 07:26:06 rnalrd, kaniini : 2017-04-27 07:26:06 https://dpaste.de/2mrS 2017-04-27 07:26:27 i didn't run apk upgrade twice actually 2017-04-27 07:26:43 kaniini: Yeah, I noticed that on upgrade on a couple occasions, libressl was one that broke until I did upgrade a second time IIRC, and my kernel is always broken :) 2017-04-27 07:27:34 while you are technically not "allowed" to have a window unit, what I just did was get a portable 2017-04-27 07:27:48 and paint the duct the same as the exterior fascia 2017-04-27 07:27:53 awilfox: lol 2017-04-27 07:27:54 Also, fwiw, I think I have a temporary solution that's workable for getting an atomic set of kernel artifacts now. 2017-04-27 07:28:01 and nobody's noticed 2017-04-27 07:28:02 awilfox: that is one way to do it 2017-04-27 07:28:04 awilfox: lol 2017-04-27 07:29:07 The biggest change needed to packaging is to include the actual kernel relase string in the package name so it can be used BEFORE downloading and extracting. 2017-04-27 07:29:14 dpaste.com/0D35NZ2 2017-04-27 07:30:47 awilfox: Nicely done. If they're really bad about it, mirror the face of it so it looks like a window from afar :) 2017-04-27 07:32:23 TemptorSent: lol 2017-04-27 07:35:05 kaniini, awilfox: I certainly couldn't live like that. If I can't shoot off my back deck, I'm too close to the neighbors! 2017-04-27 07:35:24 rnalrd: i think the solver computes half the solution (purge linux-grsec itself), and then the other half on the second apk upgrade run 2017-04-27 07:36:05 kaniini: Should the solver rerun itself whenever there is a purge to recalculate new dep tree? 2017-04-27 07:36:30 You're dropping nodes without recalculating those edges. 2017-04-27 07:37:45 In fact, in complex cases, you may have to re-run until you get a steady-state solution... 2017-04-27 07:38:26 Snipping out the middle of a tree and restoring connectivity is a hard problem. 2017-04-27 07:38:40 (in the computational sense) 2017-04-27 07:41:32 rnalrd: https://bugs.alpinelinux.org/issues/7250 2017-04-27 07:41:34 Another option may be runing the revdep solution first, then trimming entire branches and rebuilding them. 2017-04-27 07:42:00 in this case, we just need to split into 2 transactions 2017-04-27 07:42:07 I don't know the DB structure well enough to nail it down 2017-04-27 07:42:39 Once cycle to solve all removals, then a second to rebuild from each of the pruned nodes? 2017-04-27 07:43:20 yes 2017-04-27 07:43:31 but it probably should be 2017-04-27 07:43:41 while(!inconsistent) upgrade(); 2017-04-27 07:43:57 er, while(!consistent) 2017-04-27 07:43:58 Yeah, that's pretty much the simplest solution 2017-04-27 07:44:31 And the tree is never so big that it's really painful compared to more targeted solutions. 2017-04-27 07:45:03 So that's proably the best overall solution in a genericish sense :) 2017-04-27 07:45:21 It will solve other classes of similar bugs as well as a bounus. 2017-04-27 07:45:55 You probably want to put a stuck-loop counter in there to ensure it's not stuck in a cycle. 2017-04-27 07:46:37 while(!consistent && watchdog) 2017-04-27 07:47:01 package management is hard, lets upgrade to OSTree 2017-04-27 07:47:13 With watchdog starting at something sane, like a dozen or so. 2017-04-27 07:48:00 better yet, 'while(!consistent && watchdog--)' 2017-04-27 07:48:47 It would be interesting to run some statistics to see how many cycles it takes with various numbers of deps installed. 2017-04-27 07:50:11 just upgrading now 2017-04-27 07:50:22 first line: (1/475) Purging linux-grsec (4.9.17-r0) 2017-04-27 07:50:24 kaniini, sounds ok to me, we just need to make sure to tell that to users when wrinting release notes for AL3.6 2017-04-27 07:51:06 rnalrd: users don't read release notes :) 2017-04-27 07:51:28 yeah, like when you take medicines 2017-04-27 07:51:38 Users don't read 'READ_ME_FIRST_BEFORE_YOU_BRICK_YOUR_COMPUTER' 2017-04-27 07:51:39 you trust your doctor :) 2017-04-27 07:51:39 but you have been warned :P 2017-04-27 07:51:55 ooh, that reminds me of a bash.org quote 2017-04-27 07:53:03 rnalrd: i think we just fix apk instead 2017-04-27 07:53:33 rnalrd: it should be easy to make it handle the swap 2017-04-27 07:53:40 Seriously, if you gave a user a can of cyanide and a bottle of HCL and printed every symbol for death on them both, they'd probably still mix them, just to see what happens. 2017-04-27 07:54:00 http://www.bash.org/?4753 2017-04-27 07:54:07 rnalrd: i mean it *should* be documented because people *should* apk add linux-hardened && apk del linux-grsec just to clean up their /etc/apk/world 2017-04-27 07:54:11 rnalrd: but we need fix the bug anyway 2017-04-27 07:54:19 for the average user (aka docker user) it'd be great 2017-04-27 07:54:50 giving docker users a can of cyanide would be great ? :p 2017-04-27 07:55:03 THATS NOT VERY NICE 2017-04-27 07:55:11 ScrumpyJack: Exactly. Stop protecting stupid people from themselves, it only makes them dumber and allows them to multiply. 2017-04-27 07:55:24 heh 2017-04-27 07:55:33 *LOL* kaniini! 2017-04-27 07:55:43 ACTION zzz 2017-04-27 07:56:06 if apk not fixed soon, will make linux-grsec transitional package instead of provides entry 2017-04-27 07:56:38 You can give me all the KCN you want, just make sure it's buffered at pH 10 or better! 2017-04-27 07:57:20 kaniini: Basically a replaces entry? 2017-04-27 07:58:43 k, not saying that all docker users are average, but an apt user would not expect to run "apk ugprade" twice or expect to explicitly reinstall the kernel after a AL release upgrade :) 2017-04-27 07:58:56 wouldn't it be enough to change /boot/extlinux.conf to boot linux-hardened? 2017-04-27 07:59:25 so an apk feature enhancement/bugfix is welcome 2017-04-27 07:59:43 kaniini: woohoo, nice stuff. can I visit you xD 2017-04-27 08:02:37 rnalrd: indeed, it is definitely a bug 2017-04-27 08:02:57 rnalrd: i'm going to dig on it tomorrow, worst case we use a transitional package, but i rather just fix apk if we can 2017-04-27 08:03:36 kaniini, : 2017-04-27 08:03:37 apk add linux-hardened 2017-04-27 08:03:37 OK: 4389 MiB in 1408 packages 2017-04-27 08:03:37 10:03 (root@2ua4020qdl) ~# apk del linux-grsec 2017-04-27 08:03:37 linux-grsec: linux-hardened xtables-addons-hardened 2017-04-27 08:03:37 World updated, but the following packages are not removed due to: 2017-04-27 08:04:06 this after upgrading 2017-04-27 08:04:14 following what you mention in the ml 2017-04-27 08:04:41 silly question: can those step be temporary set on post-install script? 2017-04-27 08:04:50 *can't 2017-04-27 08:05:45 calling apk from inside apk is not allowed 2017-04-27 08:06:02 ok 2017-04-27 08:06:09 ah i see 2017-04-27 08:06:10 so a post-install message 2017-04-27 08:06:21 yes a post-install message might be good to add 2017-04-27 08:06:32 but really we should fix apk itself 2017-04-27 08:06:36 like previously mentioned :p 2017-04-27 08:06:44 the apk add/del stuff is just to do housekeeping 2017-04-27 08:07:01 so that you do not wind up without a kernel whenever we decide to drop linux-grsec provides entry 2017-04-27 08:07:33 Well one thing works for sure in my new kerneltool -- if you're missing any deps for a mod, it lets you know in no uncertain terms! 2017-04-27 08:07:41 +1, but due to the sensitivity and the fact that not all alpine's ppl is subscriberd to alpine ml, they will end-up in a unbootable device 2017-04-27 08:07:50 without knowing why 2017-04-27 08:08:06 yes 2017-04-27 08:08:15 which means most likely 2017-04-27 08:08:22 we wont be dropping linux-grsec provides for a long time 2017-04-27 08:08:37 the apk upgrade issue is a bug, we need to fix that before 3.6 release 2017-04-27 08:08:48 right...and this undermine the confidence to alpine 2017-04-27 08:08:51 as previously mentioned, worst case we just anchor it to a real linux-grsec package 2017-04-27 08:09:10 ok 2017-04-27 08:11:54 Considering the number of breakages due to upgrades gone wrong, I'd say this is an area of critical concenrn. 2017-04-27 08:13:17 TemptorSent: yes, which means we want to fix the actual problem instead of use duct tape 2017-04-27 08:13:21 however 2017-04-27 08:13:40 i did just push a linux-grsec transitional package for now 2017-04-27 08:13:45 Agreed, but stop the bleeding ASAP :) 2017-04-27 08:14:20 People seeing failures on -linux... 2017-04-27 08:14:59 that isnt necessarily related 2017-04-27 08:15:08 but 2017-04-27 08:15:15 linux-grsec fake package is in 2017-04-27 08:15:21 apk bug report is made 2017-04-27 08:16:16 kaniini Um, that's breaking things for ME now. 2017-04-27 08:17:11 breaking how 2017-04-27 08:17:13 kaniini: My build system just broke because of that last change. 2017-04-27 08:17:37 Retrieving a different package than I requested. 2017-04-27 08:17:45 Thus filenames missmatch. 2017-04-27 08:18:04 TemptorSent: yeah that kinda happens when you rename the kernel... 2017-04-27 08:18:27 Yeah, kinda breaks things when the filename doesn't match the package name :) 2017-04-27 08:19:19 anyway, something something needs of many outweight needs of few 2017-04-27 08:19:31 This is that whole issue with not being able to use the results of search -x directyl. 2017-04-27 08:20:03 i'll figure out why apk is not calculating the right transaction tomorrow 2017-04-27 08:20:07 in meantime 2017-04-27 08:20:15 virtual linux-grsec package will make sure ntohing breaks 2017-04-27 08:20:19 Okay, but what's causing it to break is uname -r not matching 2017-04-27 08:20:28 ...which is going to break a LOT of things 2017-04-27 08:20:33 Including probably mkinitfs. 2017-04-27 08:20:42 So it's going to brick systems I think. 2017-04-27 08:20:49 $ uname -r 2017-04-27 08:20:51 4.9.24-1-hardened 2017-04-27 08:21:06 seems working fine for me 2017-04-27 08:21:28 Hmm, did you upgrade before or after you changed that last file? 2017-04-27 08:21:48 that last file just pulls in linux-hardened as a dependency 2017-04-27 08:21:55 it's literally what i did before, except with a package 2017-04-27 08:22:09 if uname -r is ...-grsec and update-kernlel gets ahold of it.. 2017-04-27 08:22:32 Hmm, I'll havve to look at little closer at update-kernel/mkinitfs. 2017-04-27 08:22:33 TemptorSent: it counts as a new kernel image being installed not an update 2017-04-27 08:22:49 like going from grsec to vanilla 2017-04-27 08:22:52 or vice versa 2017-04-27 08:23:42 Okay... as long as it bypases update-kernel's normal logic. 2017-04-27 08:24:58 'FLAVOR=$(uname -r | cut -d - -f 3-)' 2017-04-27 08:25:23 blah blah blah 2017-04-27 08:25:30 Which will break external modules I suspect. 2017-04-27 08:25:50 I can't even get apk upgrade to run anymore 2017-04-27 08:26:32 uh huh 2017-04-27 08:26:37 Conflict with history.3.gz is causing a totally broken system. 2017-04-27 08:27:00 libedit-doc vs. readline-doc 2017-04-27 08:27:11 you're aware that's a manpage and has nothing to do with linux-grsec package right? 2017-04-27 08:27:17 and fix doesn't work. 2017-04-27 08:27:21 yes 2017-04-27 08:27:25 uninstall one of them 2017-04-27 08:27:31 :D 2017-04-27 08:27:33 Yes, but it's likely the same problem that caused it. 2017-04-27 08:27:38 ? 2017-04-27 08:27:51 TemptorSent: which problem is that 2017-04-27 08:28:01 And upgrade that didn't fully resolve the tree. 2017-04-27 08:28:07 ah yes 2017-04-27 08:28:09 possible 2017-04-27 08:28:14 unfortunately it is 2017-04-27 08:28:18 03:28am right now 2017-04-27 08:28:32 and i do not have the mental capacity to expend on debugging a satsolver at this time 2017-04-27 08:28:42 Hmm, which is SUPPOSED to be installed? 2017-04-27 08:28:51 Goodnight kaniini :) 2017-04-27 08:28:56 not sure, /etc/apk/world would let you know 2017-04-27 08:29:04 my immediate concern right now 2017-04-27 08:29:10 is just making sure that the bug is worked around 2017-04-27 08:29:36 Um, NEITHER in world. 2017-04-27 08:29:47 So I have conflicting deps somwhere. 2017-04-27 08:29:53 do you have 'docs' package installed? 2017-04-27 08:30:00 Yes, docs is installed 2017-04-27 08:30:06 ouch ;) 2017-04-27 08:30:12 it's because of install_if rule 2017-04-27 08:30:17 try 2017-04-27 08:30:27 apk add "!libedit-doc" 2017-04-27 08:30:59 Thank you, that did it! 2017-04-27 08:31:14 (207/475) Upgrading perl-libwww (6.24-r0 -> 6.26-r0) 2017-04-27 08:31:14 44% [#################################### ]ERROR: perl-libwww-6.26-r0: Permission denied 2017-04-27 08:31:25 If it happened to me, I suspect anyone with docs enabled is going to hit the same. 2017-04-27 08:31:46 oops, sorry 2017-04-27 08:31:47 TemptorSent: yes, likely 2017-04-27 08:32:23 Ouch, - just had my ZFS modules purged, no replacement. 2017-04-27 08:32:30 fcolista: i did linux-grsec fake package for now 2017-04-27 08:32:47 saw that in ml kaniini 2017-04-27 08:33:21 i think that those cnages, anyway, should be thorougly tested before push 2017-04-27 08:33:31 Oh well, it's about as broken as it was before, just in the opposite direction :) 2017-04-27 08:33:56 'cause the side effect are serious 2017-04-27 08:34:25 TemptorSent: run the upgrade again 2017-04-27 08:34:30 it will come back 2017-04-27 08:35:12 Yeah, give it a minute to finish the cycle and I'll see if that worked. I might have to run it a third time, since my network is flaking. 2017-04-27 08:35:33 Oh, this is awesome, no kernel AND no modules! 2017-04-27 08:35:38 fcolista: the change to aports was technically correct, and linux-grsec dependency was met in my repo. the problem is with APK, which was unforeseen 2017-04-27 08:36:20 Nope, gets zfs-hardened and spl-hardened, but no kernel. 2017-04-27 08:36:44 apk info --depends linux-grsec ? 2017-04-27 08:36:49 kaniini, of course this is unforseen. I'm saying that due to the potential side-effect this kind of change has (and we never did it before), it would be better to test it before pushing. 2017-04-27 08:37:01 No /lib/modules/4.9.24-1-hardened/modules.order 2017-04-27 08:37:28 fcolista: that is kind of the point of edge 2017-04-27 08:37:42 fcolista: maybe we need something edgier than edge 2017-04-27 08:38:22 that's also true. 2017-04-27 08:38:22 linux-hardened-4.9.24-r1 depends on mkinitfs linux-firmware 2017-04-27 08:38:40 edge is for that purpose (also) 2017-04-27 08:39:05 TemptorSent: what mirror are you on 2017-04-27 08:39:10 TemptorSent: you should have 2017-04-27 08:39:11 No joy -- I guess I'd better manually install a kernel 2017-04-27 08:39:17 linux-grsec-4.9.24-r1 depends on: 2017-04-27 08:39:19 linux-hardened>=4.9.24-r1 2017-04-27 08:39:42 dl-cdn 2017-04-27 08:39:48 that's why 2017-04-27 08:39:50 needs to update 2017-04-27 08:39:55 try rsync.alpinelinux.org :P 2017-04-27 08:40:17 i'm going to test 3.5-stable->edge upgrade path from rsync mirror 2017-04-27 08:41:20 updating to rsync... 2017-04-27 08:42:22 Now I have linux-grsec-4.9.24-r1 depends on linux-hardened>=4.9.24-r1, but upgrade doesn't even try to fetch it. 2017-04-27 08:42:46 It's in limbo somehow, even though it's in world. 2017-04-27 08:42:55 It doesn't realize it's not installed. 2017-04-27 08:43:15 apk fix --reinstall ? 2017-04-27 08:43:23 it's because of the provides on linux-hardened 2017-04-27 08:43:26 the loop cancels it 2017-04-27 08:43:28 grrrrrrr 2017-04-27 08:43:52 Yeah... It's bjorked :) 2017-04-27 08:44:15 Time to hurry up and make my kerneltool actually install, not just stage :P 2017-04-27 08:46:00 fucking 2017-04-27 08:46:03 garbage 2017-04-27 08:47:01 Okay, I was able to pull it manually and stage it, so I can fetch the file, but it can't resolve. 2017-04-27 08:49:42 waiting for kernel rebuild as 3.5-stable -> edge upgrade is broken 2017-04-27 08:55:26 same 2017-04-27 08:56:00 rnalrd: do you get "unsatisfiable constraints" error? 2017-04-27 08:56:11 rnalrd: if so, i believe edge will be green after new rebuild 2017-04-27 08:56:31 kaniini yes 2017-04-27 08:56:33 right 2017-04-27 08:57:27 rnalrd: that is what ig et too after linux-grsec fake package was introduced 2017-04-27 08:57:43 so that should solve that 2017-04-27 08:57:49 +1 2017-04-27 08:58:04 of course, the fake package should not be needed 2017-04-27 08:58:17 which means something whack is going on with the solver 2017-04-27 08:58:36 we already had transitional packages in the past 2017-04-27 08:58:47 and also other distros have it 2017-04-27 08:59:36 yes 2017-04-27 08:59:54 that's how we did pkg-config -> pkgconf for example 2017-04-27 09:00:14 but the new apk-tools 2.x solver normally can handle this 2017-04-27 09:02:16 hum 2017-04-27 09:02:33 i think transitional package is broken 2017-04-27 09:02:42 pkgrel isn't bumped 2017-04-27 09:02:50 for depends 2017-04-27 09:03:25 it should fish out pkgver and pkgver from linux-hardened 2017-04-27 09:03:41 ah no 2017-04-27 09:03:45 it's => 2017-04-27 09:05:23 yeah it's >= 2017-04-27 09:05:25 so should be fine 2017-04-27 09:05:31 y 2017-04-27 09:06:54 ACTION waits patiently 2017-04-27 09:10:34 rnalrd: okay, x86_64 is building modules 2017-04-27 09:10:41 so should be next 5-10 minutes i guess 2017-04-27 09:10:47 *yay* 2017-04-27 09:11:38 linux-headers is still on 4.4.6, why? 2017-04-27 09:12:20 probably patches needs to be revisited 2017-04-27 09:12:21 good question 2017-04-27 09:12:30 and yes, probably because of the userspace patches 2017-04-27 09:13:43 Once something gets to the halfway-sane point, it would probably be a good idea to revisit the entire kernel ecosystem and make it reflect current reality -- I noticed some headers missing defines because they're out of date. 2017-04-27 09:14:29 we are going to overhaul kernel packaging for 3.7 2017-04-27 09:14:34 this is a disaster in general 2017-04-27 09:15:49 Yeah, it's a bit of a house-of-cards. 2017-04-27 09:16:07 the apk bug pisses me off the most 2017-04-27 09:16:19 because i have hit it before 2017-04-27 09:16:27 but could never come up with a reproducer 2017-04-27 09:16:36 Realisitically, the kernel doesn't fit in the same upgrade cycle as the rest of the system (unless we can hot-patch :) ) 2017-04-27 09:16:52 Well, you found one! 2017-04-27 09:17:16 Too bad it's probably the longest build time of anything outside huge gui apps. :P 2017-04-27 09:18:13 (26/29) Installing linux-hardened (4.9.24-r2) 2017-04-27 09:18:15 (27/29) Upgrading linux-grsec (4.4.59-r0 -> 4.9.24-r1) 2017-04-27 09:18:17 BAM 2017-04-27 09:18:21 Damn, STILL only giving me the modules. 2017-04-27 09:18:50 I now have spl- and zfs- hardened-4.9.24-r2, but still no kernel! 2017-04-27 09:19:11 I think I broke the database by upgrading at the wrong time :/ 2017-04-27 09:19:24 Any way to fix that? apk fix does nothing. 2017-04-27 09:19:26 poking @ that to see 2017-04-27 09:20:10 maybe apk add "!linux-grsec" "!linux-hardened" 2017-04-27 09:20:20 then apk add linux-hardened? 2017-04-27 09:20:47 Or is that going to put two conflicting entries in the database? 2017-04-27 09:21:31 oh god why did i tell you about that 2017-04-27 09:22:14 I'm suspecting it would break things worse. 2017-04-27 09:22:33 But currently, I can't seem to force apk to actually install the kernel 2017-04-27 09:22:41 what are you getting 2017-04-27 09:22:47 youre on x86_64 right? 2017-04-27 09:22:50 yes. 2017-04-27 09:22:53 because the x86 builder is still building 2017-04-27 09:23:26 apk upgrade upgraded the zfs and spl modules, but I still have no kernel, and apk fix does nothing. 2017-04-27 09:23:58 Its as if it thinks it's already installed and up to date or something. 2017-04-27 09:24:14 apk policy linux-grsec linux-hardened 2017-04-27 09:25:06 "apk upgrade -Ua" on 3.5-stable->edge just worked, running it only one 2017-04-27 09:25:09 only once* 2017-04-27 09:25:33 rnalrd: yes, i think it is good enough for the moment 2017-04-27 09:25:37 +1 2017-04-27 09:25:48 http://termbin.com/9xwf 2017-04-27 09:26:02 rnalrd: but i think this APK bug is screwing up installs in other ways 2017-04-27 09:26:22 smell yes 2017-04-27 09:26:25 TemptorSent: dont mix edge and 3.5, that's why 2017-04-27 09:26:54 Ahh, need to kill the older repo, not let it fail over.. 2017-04-27 09:27:13 TemptorSent: if youre mixing versions you need to tag edge repo 2017-04-27 09:27:15 Odd, the modules upgrade... 2017-04-27 09:27:20 otherwise things can go really south 2017-04-27 09:27:38 I'll drop 3.5 and see what breaks. 2017-04-27 09:27:39 even downgrade edge->3.5-stable works :) 2017-04-27 09:28:28 Well, it upgraded libquadmath, but STILL no kernel 2017-04-27 09:28:40 TemptorSent: apk policy again 2017-04-27 09:28:45 i have rebased a linux-header patch, which was trivial 2017-04-27 09:28:57 TemptorSent: also try: apk upgrade --available 2017-04-27 09:29:07 http://termbin.com/dtkt 2017-04-27 09:29:23 TemptorSent: ok now, apk upgrade --available 2017-04-27 09:29:29 Holyshit, 142 packages! 2017-04-27 09:29:45 Might be a while before I know if it got the kernel :) 2017-04-27 09:29:54 TemptorSent: you were not doing the full distribution upgrade, that's why ;) 2017-04-27 09:30:35 Yeah, I didn't particularly WANT to do the full distribution upgrade. 2017-04-27 09:30:51 kinda have to play the game with edge 2017-04-27 09:31:02 it's not for the faint of heart 2017-04-27 09:31:08 Most of that crap I installed because some dep wanted it for me to build, and I don't feel like figuring out what can go. 2017-04-27 09:31:21 ohh 2017-04-27 09:31:23 dudeeeee 2017-04-27 09:31:33 apk add --virtual .thing-deps 2017-04-27 09:31:37 then you can do 2017-04-27 09:31:40 apk del .thing-deps 2017-04-27 09:31:45 Yeah, it was a bit more complex than that :) 2017-04-27 09:31:46 and it will delete whatever you pulled in 2017-04-27 09:31:55 you can have as many as you want 2017-04-27 09:32:09 Yeah, I didn't realized what I was getting into when I started. 2017-04-27 09:32:17 it's underdocumented 2017-04-27 09:32:43 anyway 2017-04-27 09:32:46 I was building some packages for postgis, gdal, and friends. 2017-04-27 09:33:01 So yeah, I need to go on a purging spree. 2017-04-27 09:33:05 where we are right now is that for 99% of the time, upgrading to edge wont hose your system 2017-04-27 09:33:32 fixing apk will get the remaining 1% 2017-04-27 09:33:33 Those packages don't have their deps even close to right, so I was manually pulling at random. 2017-04-27 09:33:40 and then we can nuke the transitional package 2017-04-27 09:33:45 Yeah, all the core stuff I had already upgraded. 2017-04-27 09:34:09 anyway --virtual is quite useful for this 2017-04-27 09:34:19 i really need to take a nap 2017-04-27 09:34:50 Yeah, I bet! I'm about there, and I'm a couple TZs west. 2017-04-27 09:35:21 And no, STILL no kernel :( 2017-04-27 09:36:38 http://termbin.com/xqlw 2017-04-27 09:36:57 So, I'll screw with it in the morning. 2017-04-27 09:40:16 Goodnight, get some rest -- my problems will wait. 2017-04-27 10:14:10 : "jirutka: how do you feel about the test suite policy change causing us to bag a libressl CVE" – what test policy change? 2017-04-27 10:20:05 kaniini: Shiz: wanna help me with CVE for LibreSSL? :) I have no experience with that 2017-04-27 10:23:55 jirutka, it's simple now, just fill in https://cve.mitre.org/cve/request_id.html 2017-04-27 10:24:29 more exact, the web form at https://cveform.mitre.org/ 2017-04-27 10:27:57 ok, I’ll do it later and ask more questions :) 2017-04-27 11:02:09 If I'm updating an APKBUILD for a CVE fix is there any convention to follow for the commit message? 2017-04-27 11:34:25 ashb: I think something like "fix CVE-XXX" should be enough 2017-04-27 12:05:37 Oh it's not actually vuln. 2017-04-27 12:05:42 Thanks though 2017-04-27 12:29:18 scadu: ashb: not just that 2017-04-27 12:29:47 ashb: see https://github.com/alpinelinux/aports/blob/master/main/openssl/APKBUILD#L31-L33 for example 2017-04-27 12:29:49 It's okay. the CVE i thought was in 2.2.27 which is the current version (though Dovecot didn't do a good job of highlighting it as a CVE in their changelog) 2017-04-27 12:29:58 Ah, good to know though 2017-04-27 12:51:49 jirutka: just wanted to correct myself and mentioned one of examples, but had to do something else first ;x 2017-04-27 12:52:26 scadu: np 2017-04-27 12:52:38 s/metioned/mention/ 2017-04-27 13:15:16 if anyone is looking for unoffical packages of gnuradio(osmocom,usrp,hackrf,rtlsdr), kicad, openscad, silversearcher, trousers/tpm-tools, ent, dwdiff, look here: https://github.com/stef/aports-ugly 2017-04-27 13:16:44 aFQIyRYSK2g8: aports-ugly? :) 2017-04-27 13:17:21 aFQIyRYSK2g8: this guide may come handy, to automatically build pkgs on Travis CI or other public CI: https://github.com/jirutka/user-aports#how-to-setup-your-own-repository 2017-04-27 13:18:38 ugly because they not necessarily comply with official packages high standards, and i'm not keen spending much time on indentation and stuff 2017-04-27 13:26:56 https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers#Generating_new_APKBUILDs mentions an `apkbuild-pypi`. Does that script/util exist anymore? 2017-04-27 13:30:15 I see a .in version of it https://git.alpinelinux.org/cgit/abuild/tree/ but the abuild apk doesn't seem to include any of the apkbuild-* 2017-04-27 13:32:12 Also: why are there patches for abuild in aports? that is somewhat suprising https://git.alpinelinux.org/cgit/aports/tree/main/abuild?h=master 2017-04-27 13:32:26 (i.e. why aren't they just made against the abuild repo directly? 2017-04-27 13:36:38 ashb: maybe, but it’s definitely very outdated, so don’t use it 2017-04-27 13:37:06 ashb: https://github.com/alpinelinux/abuild ? 2017-04-27 13:37:17 Ah fair 2017-04-27 13:37:57 I might noodle away at making a python version of it that works and gets deps right. 2017-04-27 13:38:49 ashb: yeah, that would be very useful; we would prefer to write it in Lua, but since it’s for Python modules, Python is okay here 2017-04-27 13:40:04 ashb: I’ve started https://github.com/jirutka/sh-parser for such scripts, to sensibly programatically modify APKBUILDs, but that part is not done yet (the parse itself is basically done) 2017-04-27 13:41:04 Yeah, using pip libs might make it worth using python for 2017-04-27 13:41:05 ashb: and ad python pkgs, see https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python 2017-04-27 13:46:16 ashb: I think that it’d be best if you start with it in your own repository and then we will transfer the repo under alpinelinux org, if you like 2017-04-27 13:46:28 Sure sure 2017-04-27 13:47:01 I make no promise as to how speedy I'll get it done 2017-04-27 13:47:13 But a slow chip away at it 2017-04-27 13:47:38 okay, I’m looking forward to it, let us know :) 2017-04-27 13:49:15 ncopa: have you find someone to manage alpinelinux twitter account? I’d like to tweet about new sponsor for master mirror (vpsFree) 2017-04-27 14:03:11 Good morning, I am a member of the Applied CS Labs at Clarkson University and we host a mirror for the Northeast US. We mirror Alpine at http://mirror.clarkson.edu/alpine/ and we are interested in being added onto the mirrors list. 2017-04-27 14:16:17 lannonbr: Hi, that’s great! :) Could you please add it to https://github.com/alpinelinux/aports/blob/master/main/alpine-mirrors/mirrors.yaml and open a pull request? 2017-04-27 14:16:44 Sounds good! 2017-04-27 14:23:54 Just pushed the PR 2017-04-27 14:56:25 good morning 2017-04-27 14:56:28 jirutka: sup 2017-04-27 14:56:41 Shiz: sup? 2017-04-27 14:56:52 Shiz: good morning, in what timezone do you live? :) 2017-04-27 14:57:09 one where today is a holiday and i slept like shit yesterday 2017-04-27 14:57:10 :D 2017-04-27 14:57:37 ah, Netherlands! 2017-04-27 14:58:03 i see there's a lot to read back about 2017-04-27 14:58:09 jirutka: did the CVE work out? :) 2017-04-27 14:58:23 Shiz: I haven’t submitted it yet, no time yet 2017-04-27 14:59:01 I can help :P 2017-04-27 14:59:04 now that I'm actually awake 2017-04-27 14:59:22 Shiz, shouldnt you get out partying? 2017-04-27 14:59:31 i don't celebrate king's day 2017-04-27 14:59:46 it would be somewhat inappropriate if I don't like the monarchy 2017-04-27 14:59:48 :p 2017-04-27 15:00:04 Shiz: monarchy is cool! :) 2017-04-27 15:00:12 lol, like most of them 2017-04-27 15:00:30 I dont believe half of them support monarchy 2017-04-27 15:00:42 its just an excuse to get drunk 2017-04-27 15:00:55 or sell rubbish 2017-04-27 15:01:04 we don't work on May 1st, "fête du travail", i.e. "work's day". Do you think we like work? 2017-04-27 15:01:05 Shiz: i think that it’s quite nice tradition; and it’s not true monarchy, but constitutional, so basically the same as classic democracy with parlament, isn’t it? 2017-04-27 15:01:24 clandmeter: yeah, but i was never much of a party animal 2017-04-27 15:01:25 heh 2017-04-27 15:01:50 jirutka: it's fine from a political perspective as they don't have much power (although they technically can still veto laws) 2017-04-27 15:01:55 it's just... kind of a waste 2017-04-27 15:01:55 ah thats a much better reason :) 2017-04-27 15:02:22 Shiz: even our drunk president can veto laws… 2017-04-27 15:02:28 i would have gone out if the weather wasnt that crappy 2017-04-27 15:02:29 Shiz: same as most presidents imo 2017-04-27 15:02:31 the best party is alone at your computer doing things you like! 2017-04-27 15:02:48 skarnet: you’re my man! 2017-04-27 15:02:52 stop watching those dirty videos skarnet 2017-04-27 15:03:21 oh crap, wrong channel :p 2017-04-27 15:03:30 XD 2017-04-27 15:04:33 jirutka: we don't have a president 2017-04-27 15:04:35 :) 2017-04-27 15:05:00 we dont? 2017-04-27 15:05:02 Shiz: I know, I just noted that even presidents in democracy with parliament can veto laws 2017-04-27 15:05:20 clandmeter: we have a minister-president, which is wholly different 2017-04-27 15:05:24 and he has no such veto powers 2017-04-27 15:05:35 right, but its still a president :p 2017-04-27 15:05:49 not really 2017-04-27 15:05:51 :P 2017-04-27 15:05:57 just because the name is similar doesn't mean the function is 2017-04-27 15:06:06 i didnt say that ;-) 2017-04-27 15:08:09 jirutka: i'm playing around with the CVE forms :P 2017-04-27 15:08:18 Shiz: thanks! :) 2017-04-27 15:08:38 i just need an email address to use since my email server is down 2017-04-27 15:08:40 lol 2017-04-27 15:10:45 you can use mine ;) 2017-04-27 15:10:58 jakub@jirutka.cz 2017-04-27 15:11:37 for ppl who are interested, scaleway just introduced arm64 servers 2017-04-27 15:14:41 rnalrd: are you here? 2017-04-27 15:15:17 rnalrd: git blame on you, where you get this patch? https://github.com/alpinelinux/aports/blob/master/main/openldap/openldap-mqtt-overlay.patch 2017-04-27 15:17:21 scaleway even name dropped us https://blog.online.net/2017/04/27/scaleway-disruptive-armv8-cloud-servers/ 2017-04-27 15:18:22 nice! 2017-04-27 15:24:35 ncopa : when you have a moment, please paste me the config log of spl-vanilla on s390x builder. it built good on my test machine. 2017-04-27 15:24:42 jirutka: could you check the writeup I did for accuracy? 2017-04-27 15:24:57 https://txt.shiz.me/MWM4OTNlOT.txt 2017-04-27 15:27:41 Shiz: it’s perfect! I’d just replace `true` with 1 and `false` with 0, to be consistent with documentation etc. and link to bug report https://github.com/libressl-portable/portable/issues/307 2017-04-27 15:27:56 right 2017-04-27 15:28:04 I linked to the bug report in the references field 2017-04-27 15:28:06 :) 2017-04-27 15:28:26 also guys in #xbps mentioned some other soft affected 2017-04-27 15:28:47 : looks like umurmur is affected too 2017-04-27 15:29:40 i did not really test it, just a fast look at the code 2017-04-27 15:30:03 im not sure if ti even supports client certificates 2017-04-27 15:30:07 i don't think it does 2017-04-27 15:30:14 it is affected, rather 2017-04-27 15:30:18 since it doesn't call SSL_get_verify_result in the first place 2017-04-27 15:30:45 true 2017-04-27 15:30:49 but how to exploit it 2017-04-27 15:30:56 it does basically no verififcation at all 2017-04-27 15:31:18 yeah 2017-04-27 15:31:49 jirutka: i'll just add a quick line indicating you discovered it and duncaen and i further investigated; that ok? 2017-04-27 15:32:02 Shiz: yes please :) 2017-04-27 15:32:11 (that's why I wanted your email, duncaen :p) 2017-04-27 15:32:17 Shiz: Jakub Jirutka from Alpine Linux and from VoidLinux 2017-04-27 15:32:24 duncaen: what is your real name? 2017-04-27 15:32:31 Duncan Overbruck 2017-04-27 15:33:34 duncaen: hm, you’ve mentioned OpenBSD in the bug report, so should we mention VoidLinux or OpenBSD? 2017-04-27 15:33:36 yeah, umurmur skips any verification 2017-04-27 15:34:00 jirutka: que 2017-04-27 15:34:17 Void, I just tested it on openbsd to make sure its not something linux related 2017-04-27 15:34:33 (which doesnt make much sense) :D 2017-04-27 15:34:41 :) 2017-04-27 15:34:46 i was gonna say 2017-04-27 15:34:54 just because he tested it on openbsd does not make him an openbsd dev :p 2017-04-27 15:35:31 i port openbsd stuff to linux, not the other way around :D 2017-04-27 15:35:58 i need to see if python is affected by this 2017-04-27 15:36:59 Shiz: maybe give credits to nginx for nginx-tests suite (https://github.com/nginx/nginx-tests)? 2017-04-27 15:37:45 Shiz: python sets the callback to NULL 2017-04-27 15:37:51 alright 2017-04-27 15:38:09 i just remember python having a similar kind of callback that definitely did not give you a preverify_ok parameter 2017-04-27 15:38:12 guess it is invoked manually 2017-04-27 15:38:14 :) 2017-04-27 15:38:33 php uses the callback but looked ok 2017-04-27 15:39:25 maybe some other python openssl lib? 2017-04-27 15:39:44 i just checked Python-2.7.13/Modules/_ssl.c 2017-04-27 15:39:54 yeah, Python doesn't seem affected 2017-04-27 15:40:01 I don't think a lot of things use the non-standard ssl lib in python 2017-04-27 15:40:10 let's check pyopenssl 2017-04-27 15:41:04 i think pyopenssl is fine too 2017-04-27 15:41:21 I have to say i was scared that mupdf matched my set_verify grep 2017-04-27 15:42:06 ... wat 2017-04-27 15:42:18 oh dear 2017-04-27 15:42:19 mupdf-1.11-source/source/pdf/pdf-pkcs7.c: X509_STORE_set_verify_cb_func(cert_store, verify_callback); 2017-04-27 15:42:20 pyopenssl is affected 2017-04-27 15:42:26 https://github.com/pyca/pyopenssl/blob/master/src/OpenSSL/SSL.py#L221 2017-04-27 15:42:35 or well 2017-04-27 15:42:39 affected by adding the bug thmselves 2017-04-27 15:42:41 :/ 2017-04-27 15:42:42 XD 2017-04-27 15:43:02 they have no get_verify_result eiter.... 2017-04-27 15:44:01 lol 2017-04-27 15:44:53 ah yes inspircd looked bad too 2017-04-27 15:45:45 certinfo->invalid = (SSL_get_verify_result(session->sess) != X509_V_OK); 2017-04-27 15:45:55 return 1 in all cases 2017-04-27 15:46:15 yeah, but ->invalid is not used afaics 2017-04-27 15:46:29 lol 2017-04-27 15:46:37 only in error output 2017-04-27 15:46:39 :) 2017-04-27 15:46:47 https://github.com/inspircd/inspircd/blob/42888e2907dacb829e2a29effbee83efb5bef6ec/include/modules/ssl.h#L124 2017-04-27 15:47:43 although it may be used later in IsCAVerified() 2017-04-27 15:48:11 ah yes 2017-04-27 15:48:17 it is 2017-04-27 15:48:21 so yeah, inspircd is affected 2017-04-27 15:49:21 checking more what VerifyCertificate(0 does to be sure 2017-04-27 15:50:03 okay so it looks like inspircd is affected 2017-04-27 15:50:51 SSL_get_verify_result() returns X509_V_OK -> invalid becomes false -> together with non-self-signed cert trusted becomes true and unknownsigner becomes false -> IsCAVerified() returns true 2017-04-27 15:51:30 this bypasses inspircd's requiressl="trusted" 2017-04-27 15:56:13 charybdis may be affected too 2017-04-27 15:56:37 but it looks not significantly, as they don't care about verification in the first place 2017-04-27 15:58:13 jirutka: got pgp? ;p 2017-04-27 15:58:49 Shiz: 35C69BBA 2017-04-27 15:59:07 Shiz: oh crap, expired 2017-04-27 15:59:17 Shiz: shit, I need to renew my GPG key 2017-04-27 15:59:50 hehe 2017-04-27 16:02:18 jirutka: duncaen: https://txt.shiz.me/NzNiNDA2NW.txt ok? 2017-04-27 16:04:39 nice looks good 2017-04-27 16:05:32 Shiz: excellent! why not admit that you’re from Alpine too? :) 2017-04-27 16:05:41 i don't know, am I? 2017-04-27 16:06:03 i'm wary of advertising affiliations that aren't official :p 2017-04-27 16:06:34 Shiz: dunno, we don’t have any official list :P 2017-04-27 16:07:47 Would you have looked at it if not for alpine :D? 2017-04-27 16:10:34 pff, if this makes ncopa mad at me 2017-04-27 16:10:39 duncaen: would you? :D 2017-04-27 16:11:01 Shiz: I really don’t think so 2017-04-27 16:11:17 Shiz: there’s no reason why ncopa should be mad at you for propagating Alpine Linux! 2017-04-27 16:12:04 I wouldnt have noticed if ncopa asked if we can reproduce this 2017-04-27 16:12:11 *not 2017-04-27 16:12:13 CVE request submitted 2017-04-27 16:12:18 you should be getting an email soon, jirutka 2017-04-27 16:12:20 <^7heo> about what, again? 2017-04-27 16:12:29 <^7heo> libressl? 2017-04-27 16:12:38 yeah 2017-04-27 16:12:44 We give him an Alpine email address. This way he can't hide it anymore ;) 2017-04-27 16:13:01 ACTION won't be one to complain 2017-04-27 16:13:10 <^7heo> who has an alpine address? 2017-04-27 16:13:13 <^7heo> jirutka? 2017-04-27 16:13:28 Only CEO haha 2017-04-27 16:13:35 <^7heo> ah 2017-04-27 16:13:37 Shiz: thanks A LOT for your help, I own you a beer! :) 2017-04-27 16:13:44 <^7heo> jirutka: owe 2017-04-27 16:13:54 <^7heo> really, you don't want to own someone a beer. 2017-04-27 16:13:55 jirutka: lmk when you got the confirmation so i can stop being anxious about having typed your email correctly 2017-04-27 16:13:57 ;) 2017-04-27 16:14:01 ^7heo: aha, right, thanks :) 2017-04-27 16:14:07 <^7heo> :{ anytime 2017-04-27 16:14:22 Shiz: I got confirmation email already 2017-04-27 16:14:26 nice 2017-04-27 16:14:33 I don’t have @alpinelinux.org email 2017-04-27 16:14:57 not sure if I need yet another email address :) 2017-04-27 16:15:05 who actually does 2017-04-27 16:15:07 ACTION curious 2017-04-27 16:15:15 well, quite many ppl actually 2017-04-27 16:15:51 <^7heo> Shiz: only ncopa does 2017-04-27 16:16:02 <^7heo> jirutka: nah, just ncopa; or? 2017-04-27 16:18:39 https://hastebin.com/raw/fuxumasuqo maybe more 2017-04-27 16:18:46 this is what I’ve parsed from abuilds 2017-04-27 16:19:06 eh, gmail.com should not be on the list 2017-04-27 16:26:48 <^7heo> jirutka: nice parsing :D 2017-04-27 16:34:47 <^7heo> jirutka: you missed aphrael 2017-04-27 16:36:02 <^7heo> and msmith 2017-04-27 16:36:12 <^7heo> also, where did you find clandmeter@? 2017-04-27 16:36:37 <^7heo> I don't have it in aport's history... 2017-04-27 16:36:38 ./main/mpd/APKBUILD:# Maintainer: Carlo Landmeter 2017-04-27 16:36:39 :) 2017-04-27 16:36:42 <^7heo> AHH. 2017-04-27 16:36:45 <^7heo> THAT. 2017-04-27 16:36:53 and a bunch of others 2017-04-27 16:36:53 <^7heo> git log --format=format:'%aE %cE' | tr ' ' '\n' | sed '/@alpinelinux.org/!d' | sort -u 2017-04-27 16:37:01 <^7heo> that's how I generated MY list. 2017-04-27 16:37:19 <^7heo> I parsed the git info, not the repo info. 2017-04-27 16:37:51 grep -hrF Maintainer: . | sed -e 's/.*Maintainer:\s*//g' -e 's/\s*$//g' | grep -F @alpinelinux.org | sort -u 2017-04-27 16:37:53 :P 2017-04-27 16:40:37 <^7heo> funny 2017-04-27 16:40:40 <^7heo> we have almost the same. 2017-04-27 16:40:44 <^7heo> why hF tho? 2017-04-27 16:40:52 <^7heo> grep -r 'Maintainer:' . | sed '/Maintainer:\s*$/d; s/^[^<]*<\([^@]*@[^>]*\)>.*$/\1/' | sed '/@alpinelinux.org/!d' | sort -u 2017-04-27 16:40:56 <^7heo> Here is mine. 2017-04-27 16:41:09 :) 2017-04-27 16:41:13 <^7heo> also, aside from the original grep, you don't need grep. 2017-04-27 16:41:33 <^7heo> And I'm stupid: grep -r 'Maintainer:' | sed '/Maintainer:\s*$/d; s/^[^<]*<\([^@]*@[^>]*\)>.*$/\1/; /@alpinelinux.org/!d' | sort -u 2017-04-27 16:41:34 -F makes grep faster, searches for the string only instead of POSIX BRE 2017-04-27 16:41:36 <^7heo> That is definitely better. 2017-04-27 16:41:42 -f doesn't print the filename 2017-04-27 16:41:43 <^7heo> ah ok. 2017-04-27 16:41:50 sorry 2017-04-27 16:41:52 -h* 2017-04-27 16:41:56 <^7heo> yeah 2017-04-27 16:42:11 <^7heo> Anyway 2017-04-27 16:42:22 <^7heo> we should have both the same output. 2017-04-27 16:42:47 <^7heo> and I have to admit, I giggled at fcolistæ@alpinelinux.org 2017-04-27 16:42:49 <^7heo> :D 2017-04-27 16:43:15 <^7heo> also funny to have ncop@alpinelinux.org 2017-04-27 16:43:26 call the ncops 2017-04-27 16:43:31 <^7heo> and we have BOTH rnalrd and@ rnarld@ 2017-04-27 16:43:34 <^7heo> oops 2017-04-27 16:43:40 <^7heo> rnalrd@ and rnarld@ 2017-04-27 16:45:37 i’ve also noticed these errors and filtered them out 2017-04-27 16:48:50 <^7heo> yeah well I'm gonna do a PR to fix them. 2017-04-27 16:50:10 <^7heo> rnalrd: do you also have larena@alpinelinux.org or is it a faulty email? 2017-04-27 16:50:27 <^7heo> it's in 5 APKBUILD files... 2017-04-27 16:50:31 <^7heo> I would imagine it to be faulty. 2017-04-27 16:52:28 https://github.com/chneukirchen/xtools/blob/master/xnew ;) 2017-04-27 16:55:13 <^7heo> https://github.com/alpinelinux/aports/pull/1328 2017-04-27 16:55:19 <^7heo> jirutka, Shiz, ncopa ^ 2017-04-27 16:56:56 <^7heo> Shiz: { grep -r 'Maintainer:\|Contributor:' | sed '/Maintainer:\s*$/d; s/^[^<]*<\([^@]*@[^>]*\)>.*$/\1/; /@alpinelinux.org/!d'; git log --format=format:'%aE %cE' | tr ' ' '\n' | sed '/@alpinelinux.org/!d' | sort -u; } | sort -u 2017-04-27 16:57:14 :p 2017-04-27 16:57:30 <^7heo> actually the /Maintainer:\s*$/d; at the start of the sed expression is totally useless 2017-04-27 16:57:44 <^7heo> it's an artefact of some filtering I did when I was building the command. 2017-04-27 16:57:54 <^7heo> but yeah long story short 2017-04-27 16:58:05 <^7heo> we now have a non-bogus list of mails in APKBUILDs too. 2017-04-27 16:58:31 <^7heo> and we have 10 @alpinelinux.org mails: http://ix.io/rZB 2017-04-27 17:01:20 <^7heo> aphrael@alpinelinux.org and msmith@alpinelinux.org do not seem active anymore. 2017-04-27 17:02:23 <^7heo> clandmeter: also, why don't you use your alpinelinux.org address? 2017-04-27 17:02:47 ^7heo: you must be really boring today… ;) 2017-04-27 17:03:00 s/boring/bored/ 2017-04-27 17:03:26 <^7heo> nah I like correct information. 2017-04-27 17:04:23 <^7heo> jirutka: also I need some successful stuff at some point. 2017-04-27 17:04:35 <^7heo> jirutka: I've been griding my brain at some complex SQL query for days... 2017-04-27 17:04:37 ^7heo: understood :) 2017-04-27 17:04:40 <^7heo> without success 2017-04-27 17:04:44 <^7heo> that commit was easy 2017-04-27 17:04:50 <^7heo> but it was a success ;) 2017-04-27 17:08:46 Shiz: CVE-2017-8301 :) 2017-04-27 17:10:11 nice 2017-04-27 17:11:00 so what’s next? 2017-04-27 17:11:41 I'll notify the libressl devs of the assigned CVE number 2017-04-27 17:11:47 maybe it's a good idea to make a mailing to oss-security about it 2017-04-27 17:12:05 jirutka: did we revert the patch in our libressl abuild yet? 2017-04-27 17:12:27 Shiz: not yet 2017-04-27 17:12:37 seems like now is the time ;p 2017-04-27 17:13:04 Shiz: CVE database doesn’t know CVE-2017-8301 yet, so it takes some time or another action is required? 2017-04-27 17:13:11 it just takes some time 2017-04-27 17:13:14 okay 2017-04-27 17:13:24 it'll probably appear in a few hours 2017-04-27 17:13:35 "A CVE name has been assigned, but it has not yet been uploaded to the CVE web site. This can happen when a security problem is new." 2017-04-27 17:13:37 :) 2017-04-27 17:13:54 according to https://twitter.com/CVEnew/ they're about 3 CVE #s behind 2017-04-27 17:13:57 so give it time 2017-04-27 17:15:31 ^7heo When it gets really ugly, I start writing custom SQL functions to handle the ugly part. 2017-04-27 18:06:08 Shiz: do you know that your email is broken? I got Delayed Mail (still being retried) 2017-04-27 18:07:42 yes 2017-04-27 18:07:49 tried to email me something 2017-04-27 18:07:50 ? 2017-04-27 18:08:29 yes 2017-04-27 18:08:38 just forwarded response from cve 2017-04-27 18:08:42 ah 2017-04-27 18:08:46 yeah my email is kinda down right now 2017-04-27 18:09:37 jirutka: let me see if i can try something... 2017-04-27 18:12:15 jirutka: can you pm me their reply otherwise? 2017-04-27 18:12:49 is the response interesting or just, here you go CVE-2017-XXX? 2017-04-27 18:12:56 btw the CVE is up: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8301 2017-04-27 18:13:41 duncaen: not interesting, it’s https://paste.fedoraproject.org/paste/M-ZDc841WRyIZ7DSpXvoEl5M1UNdIGYhyRLivL9gydE=/raw 2017-04-27 18:15:55 Shiz: I know, but where’s the Additional Information? 2017-04-27 18:16:05 dunno 2017-04-27 18:17:05 jirutka: i do propose we make a post to oss-security with this info though 2017-04-27 18:17:22 Shiz: agree :) 2017-04-27 18:18:36 <^7heo> ofc there's absolutely NO public record of that CVE yet. 2017-04-27 18:19:03 jirutka: we also need to rebuild packages against the new libressl 2017-04-27 18:19:09 don't think that happens automatically? 2017-04-27 18:19:10 <^7heo> https://nvd.nist.gov/vuln/detail/CVE-2017-8301 2017-04-27 18:19:12 otoh 2017-04-27 18:19:13 true there are a few other uses that dont know about it yet 2017-04-27 18:19:16 it's not needed probably 2017-04-27 18:19:17 <^7heo> well at least they synchronized. 2017-04-27 18:19:19 because dynamic liinking 2017-04-27 18:19:24 and it's no big ABI bump 2017-04-27 18:19:26 Shiz: I don’t think that we need to rebuild them 2017-04-27 18:19:38 i'm not sure if anything statically links against libressl in our package base... 2017-04-27 18:19:44 Shiz: except pkgs that links it statically, but I think that we donjt have any…? 2017-04-27 18:19:48 wouldn't be surprised if rust did 2017-04-27 18:19:49 <^7heo> Shiz: did you write the CVE description? 2017-04-27 18:19:50 fwiw 2017-04-27 18:20:01 ^7heo: i wrote the additional info section in the thing jirutka linked 2017-04-27 18:20:05 they condensed that into the CVE description 2017-04-27 18:20:07 :P 2017-04-27 18:20:11 <^7heo> Ah ok 2017-04-27 18:20:17 <^7heo> yeah it's a little... condensed. 2017-04-27 18:20:40 <^7heo> Shiz: do you have the original text? 2017-04-27 18:20:45 freebsd has a recently started to provide libressl ports 2017-04-27 18:20:45 see jirutka's 2017-04-27 18:20:46 maybe it’ll be available later once they confirm it? 2017-04-27 18:20:51 fedoraproject paste link 2017-04-27 18:20:56 <^7heo> jirutka: do you have the original text? 2017-04-27 18:21:00 │ ageis 2017-04-27 18:21:02 err 2017-04-27 18:21:02 <^7heo> ah ok I'll grep the log. 2017-04-27 18:21:04 20:13:41 jirutka │ duncaen: not interesting, it’s https://paste.fedoraproject.org/paste/M-ZDc841WRyIZ7DSpXvoEl5M1UNdIGYhyRLivL9gydE=/raw 2017-04-27 18:21:06 lazy bum 2017-04-27 18:21:08 :P 2017-04-27 18:21:08 <^7heo> thanks ;) 2017-04-27 18:21:18 <^7heo> Shiz: how am I supposed to know that the link was pasted here? 2017-04-27 18:21:39 <^7heo> Wow it's LONG 2017-04-27 18:22:09 <^7heo> ncopa: we should provide jirutka with an alpinelinux.org mail IMHO 2017-04-27 18:22:13 <^7heo> ncopa: and shiz too. 2017-04-27 18:23:08 <^7heo> I mean, from the CVE report, you can see: (Discoverer] 2017-04-27 18:23:09 <^7heo> Jakub Jirutka , Duncan Overbruck , Shiz 2017-04-27 18:23:37 <^7heo> while it's coole for jirutka and shiz to have their name there; they actually discovered that while working for Alpine 2017-04-27 18:23:50 <^7heo> it would be good if that would be reflected, for future reference. 2017-04-27 18:24:35 <^7heo> I mean the text says so, but the text has been... Summarized. 2017-04-27 18:24:46 ^7heo: "This issue was discovered by Jakub Jirutka from Alpine Linux" 2017-04-27 18:25:08 <^7heo> yeah 2017-04-27 18:25:24 <^7heo> that text is missing from any text but that obscure paste on the fedoraproject pastes... 2017-04-27 18:25:32 <^7heo> i.e. *nobody* will ever see that. 2017-04-27 18:25:44 <^7heo> (aside us and the people who summarized it) 2017-04-27 18:25:49 that’s what i don’t know 2017-04-27 18:26:01 why they want to enter Additional Information if not displayed anywhere? 2017-04-27 18:26:07 ^7heo: that's why we're going to post the same description to oss-security 2017-04-27 18:26:07 <^7heo> yeah but if you had an alpinelinux.org address; that wouldn't happen. 2017-04-27 18:26:08 maybe it’s available later? 2017-04-27 18:26:09 ;p 2017-04-27 18:26:16 jirutka: possibly 2017-04-27 18:26:19 i don't know the CVE process 2017-04-27 18:26:34 ^7heo: as you can see, there are not even our mail addresses: https://nvd.nist.gov/vuln/detail/CVE-2017-8301 2017-04-27 18:26:36 <^7heo> Shiz: well yeah; but honestly... Wouldn't it just be simpler to make you both alpinelinux.org addresses? 2017-04-27 18:26:59 <^7heo> jirutka: not there no; because they don't list discoverers/reporters. 2017-04-27 18:27:07 they never list the reportersp ublically 2017-04-27 18:27:12 they said as much in the web form 2017-04-27 18:27:21 anyway this seems pointless 2017-04-27 18:27:29 i guess they "received by the NVD and has not been analyzed." publish more after they see its not garbage 2017-04-27 18:27:36 the issue is the acutal issue in libressl, not who gets credit for it 2017-04-27 18:27:41 ;) 2017-04-27 18:27:46 <^7heo> Shiz: ah ok. Well. 2017-04-27 18:27:56 <^7heo> duncaen: possibly too. 2017-04-27 18:28:05 who cares about libressl anyways :D 2017-04-27 18:28:32 <^7heo> huhu 2017-04-27 18:35:35 Shiz: I think that I can just paste https://paste.fedoraproject.org/paste/M-ZDc841WRyIZ7DSpXvoEl5M1UNdIGYhyRLivL9gydE=/raw to email for oss-security, right? 2017-04-27 18:35:47 Shiz: I mean paste content, not that link 2017-04-27 18:39:01 lol 2017-04-27 18:39:01 well, strip the PGP signature 2017-04-27 18:39:01 and the MITRE signature 2017-04-27 18:40:15 ofc :) 2017-04-27 18:40:30 I’ll also slightly reformat it and strip some not so interesting stuff 2017-04-27 18:40:46 :) 2017-04-27 18:42:01 jirutka: good news: i now also have an aarch64 box to test on 2017-04-27 18:48:08 Shiz: https://paste.fedoraproject.org/paste/YMGTE4fkRowTqb7Kg~DXKl5M1UNdIGYhyRLivL9gydE=/raw ok? 2017-04-27 18:48:21 Shiz: that’s great! :) 2017-04-27 18:48:55 i'd rename the subject to CVE-2017-8301: TLS verification vulnerability in LibreSSL 2.5.1 - 2.5.3 2017-04-27 18:49:05 ok 2017-04-27 18:49:10 and add the MITRE CVE page to references 2017-04-27 18:49:11 rest LGTM 2017-04-27 18:49:26 ah right forgot to that 2017-04-27 18:49:30 you forgot to space between InspIRCD and [4[ btw 2017-04-27 18:49:32 [4] 2017-04-27 18:50:09 good catch! I have headache, so hard to focus to anything :/ 2017-04-27 18:50:39 you can actually move all links in the main desc to the reference section 2017-04-27 18:50:41 :P 2017-04-27 18:51:11 add [6] to verified by vendor here, add it as [6], and move al the links to the ref section 2017-04-27 18:52:00 already did it :) 2017-04-27 18:52:13 also link to nginx bug tracker is here twice, so also fixed 2017-04-27 18:52:17 yea 2017-04-27 18:54:10 jirutka: apparently this version in openBSD 6.1... 2017-04-27 18:56:23 https://up.shiz.me/ZDhlMWU2.png 2017-04-27 18:56:25 :) 2017-04-27 18:56:55 jirutka: unrelatedly, rust 1.17 got released 2017-04-27 18:56:58 dare we take the plunge? 2017-04-27 19:16:04 Shiz: http://www.openwall.com/lists/oss-security/2017/04/27/11 2017-04-27 19:17:31 nice! 2017-04-27 19:39:16 jirutka: im gonna try upgrading rust to 1.17 2017-04-27 19:39:18 hehe 2017-04-27 19:52:03 Shiz, now that Alpine has a complete Rust compiler, do you even need to bootstrap it everytime? 2017-04-27 19:52:14 yes 2017-04-27 19:52:24 rust always needs to be bootstrapped :P 2017-04-27 19:53:17 Shiz: you can compile 1.17 with rustc 1.16 2017-04-27 19:54:08 yeah 2017-04-27 19:54:10 i know :p 2017-04-27 19:54:58 why bootstrap it then? 2017-04-27 19:55:14 because that's still bootstrapping, no matter where the compiler comes from 2017-04-27 19:55:20 and i don't think we want our aports to rely on a previous aports state 2017-04-27 19:56:03 Shiz: we don’t, still need rust-bootstrap for bootstrapping from glibc binary :/ 2017-04-27 19:56:18 jirutka: do we have a rust-bootstrap now? 2017-04-27 19:56:24 nope 2017-04-27 19:56:29 ah 2017-04-27 19:56:41 fabled: are you here? 2017-04-27 19:56:42 So what about gcc then? Would that break this rule? 2017-04-27 19:56:56 s/Would/Wouldn't/ 2017-04-27 19:58:10 xentec: in what way? 2017-04-27 19:58:21 you can use any gcc to build alpine gcc 2017-04-27 19:58:26 alpine/aports gcc 2017-04-27 20:01:33 I kinda see what you meant. So you can't do the same with rustc yet? 2017-04-27 20:01:47 nope 2017-04-27 20:01:54 rustc needs an explicit version 2017-04-27 20:02:02 i think it's - 1 these days 2017-04-27 20:02:08 e.g. rustc 1.17.0 needs rustc 1.16.0 2017-04-27 20:03:08 or 1.17.0 :P 2017-04-27 20:07:16 Just wondering... why not using existing package of previous version but relying on foreign distfiles (as seen in rust APKBUILD) to rebuild rustc. 2017-04-27 20:08:26 ACTION should have joined here earlier 2017-04-27 20:09:32 xentec: we want to be independent from void, as cool guys as they are 2017-04-27 20:09:34 :P 2017-04-27 20:11:15 I've got a PR out to mkinitfs that fixes #7037 that correctly handles kernel console= params for serial consoles. Can someone take a look or are the tree frozen? 2017-04-27 20:11:36 it's still open for bugfxies to the best of my knowledge 2017-04-27 20:11:56 and i've seen that bug before too, can ack 2017-04-27 20:12:55 Shiz: nice. We've worked around it but the fix is good to have 2017-04-27 20:13:12 I guess I'll also follow up with some more debugging of #6713 2017-04-27 20:13:20 you probably wanna poke fabled or ncopa for it, they are the maintainers for mkinitfs afaik 2017-04-27 20:13:39 maybe ^7heo 2017-04-27 20:14:04 yeah I figured I would go checkout git blame for pepole top poke soonish 2017-04-27 20:14:28 Shiz, what I meant was: why not having a makedepends_build="rust=" in APKBUILD for rust but download prebuild versions now that Alpine has a rust package? 2017-04-27 20:14:39 aka doing the same as with gcc 2017-04-27 20:14:48 i don't think that's what we do with gcc 2017-04-27 20:14:50 heh 2017-04-27 20:15:00 https://git.alpinelinux.org/cgit/aports/tree/main/gcc/APKBUILD#n17 2017-04-27 20:15:11 but its there? 2017-04-27 20:15:16 ah yeah 2017-04-27 20:15:28 well, mostly because it's hacky and we want to avoid it as it's special-casing stuff 2017-04-27 20:25:37 kaniini: btw what's the nature of our current grsec patch anyway 2017-04-27 20:25:41 it's definitely not an upstream patch 2017-04-27 20:26:12 Shiz: we forked grsec 2 years ago basically 2017-04-27 20:26:17 Shiz: sometimes it gets rebased 2017-04-27 20:26:22 right. 2017-04-27 20:27:03 Shiz: i guess that will not be happening anymore though ;) 2017-04-27 20:27:44 well, I would have no issues if we were to forward-port the last public patch to newer kernels :P 2017-04-27 20:27:46 work, though 2017-04-27 20:29:11 Shiz: rebasing the patch on a newer kernel is really a massive pain in the ass 2017-04-27 20:29:27 Shiz: we've done it, it results in several weeks of working out the regressions 2017-04-27 20:29:28 hence my exclamation of "work, though" 2017-04-27 20:29:31 :P 2017-04-27 20:30:59 as of right now i'm interested in what the other distros using grsec are gonna do 2017-04-27 20:31:02 gentoo hardened, etc 2017-04-27 20:37:06 kaniini: What would be the difficulty of adding an option to list files with checksums in apk? 2017-04-27 20:37:46 TemptorSent: not hard 2017-04-27 20:38:31 jirutka: building rust 1.17... 2017-04-27 20:38:47 kaniini: That is a show-stopper for my work, as taking 5 minutes to extract the checksums from the kernel apk using awk is a deal-breaker for the user-experience. 2017-04-27 20:39:51 kaniini: And a manifest output would elimintate probably 20% more of my code. 2017-04-27 20:40:15 TemptorSent: presently composing a test for the solver bug 2017-04-27 20:43:24 (kapk:$arch/$krel/$pkg\tshaX:$sum\t$path is what I'm using for the kernel packages) 2017-04-27 20:44:34 But generally: 'apk:$arch/$pkg' would be fine for tagging. 2017-04-27 20:45:00 kaniini: Good deal - that was a nasty little surprise. 2017-04-27 20:46:24 It looks like it was hitting a lot of other cases, but was less than apparent usually due to it often self-resolving on a subsequent update. 2017-04-27 21:03:55 so far so good for rustc 1.17 2017-04-27 21:06:11 kaniini: A manifest format is one of the issues that probably should be discussed before we go too much further with apk. 2017-04-27 21:10:46 One additional wrinkle is that some files may get compressed/decompressed upon installation/use (kernel modules/man pages/etc.), thus we need to have a canonanical checksum for the file content and a checksum for the actual file. 2017-04-27 21:12:23 man pages don't get compressed or decompressed at all during installation 2017-04-27 21:12:37 they get compressed once during packaging and that's it 2017-04-27 21:12:48 thus their checksum should always be the compressed version 2017-04-27 21:13:39 Man pages are less of an issue as far as handling, it's modules that are a big one. 2017-04-27 21:14:28 If you want a deptree of checksums, you need to be comparing the modules themselves, not a compressed version. 2017-04-27 21:14:46 what's the compressed version of module 2017-04-27 21:15:11 Any flavor you choose - gz, xz, lzo, bz2, etc. 2017-04-27 21:15:32 i dont see any compressed modules... 2017-04-27 21:15:44 And in some cases, they may be stored compressed in one location and uncompressed in another. 2017-04-27 21:16:21 Yeah, which is currently a problem - we're wasting space with uncompressed modules :) 2017-04-27 21:16:49 But if they're being stored in a squashfs, there is no point in compressing them twice.. 2017-04-27 21:16:50 ... 2017-04-27 21:16:58 i think we're just fine with uncompressed modules 2017-04-27 21:17:31 Really? How large is /lib/modules/`uname -r` and /lib/firmware? 2017-04-27 21:17:47 the question is not 'how large is it' 2017-04-27 21:18:00 the question is 'how much does compression make it smaller'' 2017-04-27 21:18:07 until there's numbers on that, this is a useless discussion 2017-04-27 21:18:08 279MB 2017-04-27 21:18:09 :P 2017-04-27 21:19:31 279MB for /lib/modules/4.9.24-2-hardened 2017-04-27 21:21:23 Hmm.. need an easy way to parallelize find 2017-04-27 21:22:19 ... or at least xargs. 2017-04-27 21:22:38 74MB after gzip -9 2017-04-27 21:22:44 Yeah, I think that's a bit of a savings. 2017-04-27 21:25:37 277% more space. 2017-04-27 21:26:09 So Shiz, not such a useless discussion? 2017-04-27 21:28:03 When compressed size is 26.5% of uncomressed size, for a savings of 205MB, I think it's worth considering. 2017-04-27 21:28:26 sure, but then the question remains 2017-04-27 21:28:30 why checksum the uncompressed version? 2017-04-27 21:28:40 the module tools take the compressed versions directly 2017-04-27 21:28:48 so there is no reason for the uncompressed version to exist on disk ever 2017-04-27 21:29:12 Because if I'm sticking the same modules in a modloop which is on a comressed filesystem, I'm wasting space by trying to compress them again. 2017-04-27 21:29:35 And it might well be that some users choose a different compression for speed/memory reasons. 2017-04-27 21:29:53 you're not wasting space, at most you're not making any extra gains 2017-04-27 21:30:10 The point is that the dep tree should depend on the uncompressed module checksums, since those are consistent. 2017-04-27 21:30:59 dont see why :| 2017-04-27 21:34:47 Shiz: Because relying on a particular compressed version of a file to match is fragile compared to looking at the uncompress file checksum. 2017-04-27 21:35:18 why, do we expect to re-compress them? 2017-04-27 21:35:25 binaries are just as fragile as compressed anything as they are not reproducable 2017-04-27 21:35:52 I can compress the same module in 6 different formats validly, and the only checksum that stays the stame is the result of uncompressing ANY of those. 2017-04-27 21:36:31 you don't get it 2017-04-27 21:36:36 why do we expect the compressed version to change, ever 2017-04-27 21:36:49 after the initial compression 2017-04-27 21:36:53 which would be part of packaging 2017-04-27 21:36:59 Look, I'm not going to waste either of our time debating this right now. I have real-world experience with issues related to this, and I'm not willing to do it wrong. 2017-04-27 21:37:19 Because we still allow custom kernels, right? 2017-04-27 21:38:05 And firmware couldn't conceivelby start being comressed, with the actual binary unchanged, right? 2017-04-27 21:38:59 Or any other artifact on the system for that matter -- You want to know if what you're looking at matches the original contents of the file for semantic reaons, not just for entertainment. 2017-04-27 21:39:30 i still don't see the meaning, but you're right, i also don't have time to waste on debating 2017-04-27 21:40:31 There is a reason, it's not just random, and it works properly when done as I suggest, while sometimes breaking otherwise. 2017-04-27 21:40:39 TemptorSent: https://paste2.org/5afXCk68 2017-04-27 21:41:43 LOOK FAMILIAR?!!!!?! 2017-04-27 21:42:21 kaniini : Bingo! 2017-04-27 21:43:22 And with my fubared split repo and poorly timed update, I managed to break the lat one so it wouldn't even try. 2017-04-27 21:43:36 I think that nails it. 2017-04-27 21:49:44 now... to figure out why this occured 2017-04-27 21:51:23 disqualify_package: a-1-r0 (conflicting provides) 2017-04-27 21:51:25 BAM 2017-04-27 21:52:12 https://paste2.org/2ZgbwEB4 2017-04-27 21:52:14 so 2017-04-27 21:52:16 this is interesting 2017-04-27 21:52:27 the solver seems to *want* b 2017-04-27 21:56:15 but i think when that disqualify happens 2017-04-27 21:56:20 it disqualifies the entire name 2017-04-27 21:56:22 humm 2017-04-27 21:59:05 yep 2017-04-27 21:59:08 that's what is going on 2017-04-27 21:59:10 cool 2017-04-27 21:59:14 that means this is probably an easy fix 2017-04-27 22:03:10 jirutka: rust and cargo both upgraded and working 2017-04-27 22:03:32 ok 2017-04-27 22:03:38 i think i have this sorted out 2017-04-27 22:03:53 installing B is not inserted into changeset 2017-04-27 22:09:04 jirutka: https://txt.shiz.me/MzljMDRjMz 2017-04-27 22:09:07 rust -> 1.17.0 2017-04-27 22:09:25 jirutka: https://txt.shiz.me/NTRkOTlmYj 2017-04-27 22:09:29 cargo -> 0.18.0 2017-04-27 22:09:46 all cargo tests still pass 2017-04-27 22:10:38 is nginx broken on edge? 2017-04-27 22:11:12 any specific reason for asking? 2017-04-27 22:11:27 i cant install it :) 2017-04-27 22:12:11 that seems problematic 2017-04-27 22:12:23 seeing the same here 2017-04-27 22:12:40 old libssl.so.* version 2017-04-27 22:12:45 nginx needs a rebuild, cc kaniini 2017-04-27 22:13:19 Shiz: it doesnt build on 3.6 2017-04-27 22:13:24 Shiz: meaning it will stall builder 2017-04-27 22:13:27 ah. 2017-04-27 22:13:33 Shiz: send fix for 3.6 build and i will take care of it 2017-04-27 22:13:39 got log? 2017-04-27 22:13:54 Shiz: http://build.alpinelinux.org/buildlogs/build-3-6-x86/main/nginx/nginx-1.10.3-r5.log 2017-04-27 22:13:58 thanks 2017-04-27 22:14:12 what about edge? 2017-04-27 22:14:17 yay, libssl 2017-04-27 22:14:25 clandmeter: if it won't build on 3.6, it's likely not gonna build on edge either 2017-04-27 22:14:27 :P 2017-04-27 22:14:31 3.6=edge :) 2017-04-27 22:14:38 exactly 2017-04-27 22:14:46 i'll take care of that patch 2017-04-27 22:14:53 clandmeter: triggering a rebuild will put it in the same position as 3.6 builder 2017-04-27 22:15:03 clandmeter: so... "please, can we not?" 2017-04-27 22:15:20 what is the position of the 3.6 builder? 2017-04-27 22:15:26 clandmeter: it fails to build 2017-04-27 22:15:32 clandmeter: so the builder is stalled 2017-04-27 22:15:55 i see 2017-04-27 22:16:37 we need a commits channel per arch... 2017-04-27 22:17:16 kaniini: identified the fix, gonna try compiling now 2017-04-27 22:17:16 should be trivial 2017-04-27 22:17:17 cool 2017-04-27 22:17:52 btw 1.10 is legacy now 2017-04-27 22:17:57 do we want to upgrade to 1.12 before 3.6? 2017-04-27 22:18:03 i can take care of the work for that 2017-04-27 22:18:59 kaniini: build succeeded lol 2017-04-27 22:19:07 patch incoming as soon as check() passes 2017-04-27 22:20:57 Shiz, looks like there is already a 1.12 pr 2017-04-27 22:21:21 link? 2017-04-27 22:21:38 https://github.com/alpinelinux/aports/pull/1323 2017-04-27 22:22:22 ah, jirutka 2017-04-27 22:22:23 :P 2017-04-27 22:22:43 he cant sit still :p 2017-04-27 22:24:06 disqualify_package: a-1-r0 (conflicting provides) 2017-04-27 22:24:08 record_change: old: a new: ??? 2017-04-27 22:24:18 getting there 2017-04-27 22:24:34 is there any way to re-trigger the CI build for that aport? 2017-04-27 22:24:39 it failed because of the libressl bug we fixed now 2017-04-27 22:24:46 it otherwise LGTM 2017-04-27 22:24:50 aport PR* 2017-04-27 22:26:48 you mean the 1.12? 2017-04-27 22:27:20 yeah 2017-04-27 22:27:30 you want to apply your patch against 1.12? 2017-04-27 22:27:38 no 2017-04-27 22:27:46 that PR already fixes the same issue 2017-04-27 22:27:48 :) 2017-04-27 22:27:54 ah ok 2017-04-27 22:27:57 it should be used instead of my patc as it also upgrades nginx to stable 2017-04-27 22:28:59 whats that perl module doing? 2017-04-27 22:29:05 its a depend? 2017-04-27 22:30:41 it's a separate commit he put into the same PR 2017-04-27 22:30:43 new aport 2017-04-27 22:30:47 external module, probably 2017-04-27 22:31:20 ok, as its in testing. 2017-04-27 22:32:05 jirutka, any reason not to push this? 2017-04-27 22:32:57 clandmeter: if you fix that damn builders, I can push fixed nginx… ;) 2017-04-27 22:33:20 jirutka: im running into something weird 2017-04-27 22:33:22 clandmeter: i’ve postponed it b/c of libressl bug 2017-04-27 22:33:36 i didnt need that fix-libresssl.patch to fix the lua module build 2017-04-27 22:33:38 only a bump to 10.8 2017-04-27 22:33:46 the builders are stuck because of nginx right? 2017-04-27 22:33:51 no 2017-04-27 22:34:21 i donjt know why build-edge-x86{,_64} does not work now :/ 2017-04-27 22:35:04 https://github.com/alpinelinux/aports/pull/1323 2017-04-27 22:35:47 the builder doesn't have the new libressl 2017-04-27 22:36:26 exactly 2017-04-27 22:36:43 https://github.com/alpinelinux/aports/commit/500f378f52a862e91c61de633df00197d4afd366 2017-04-27 22:36:44 well 2017-04-27 22:36:54 maybe the builder is stuck because of nginx and now it can't build the new libressl because it's stuck 2017-04-27 22:36:57 and thus not the fixed nginx? 2017-04-27 22:36:59 :D 2017-04-27 22:37:03 https://pkgs.alpinelinux.org/packages?name=libressl&branch=edge&repo=&arch=&maintainer= 2017-04-27 22:37:22 and armhf doesn’t have even 2.5.3, so it’s like weeks behind…? 2017-04-27 22:37:37 no, these builders are not stuck b/c of nginx 2017-04-27 22:37:48 they does not respond to algitbot commands 2017-04-27 22:38:13 record_change: old: a new: ??? 2017-04-27 22:38:14 REMOVE a 2017-04-27 22:38:14 I’ve already reported it in #alpine-infra, but we have classic situation when only two ppl have access to the builders and they are not here :( 2017-04-27 22:38:16 REMOVE?!!! b 2017-04-27 22:38:17 http://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/libressl/libressl-2.5.3-r1.log 2017-04-27 22:38:24 :( 2017-04-27 22:38:27 isnt that new libressl? 2017-04-27 22:38:31 yes 2017-04-27 22:39:02 build-3-6 are stuck b/c of nginx thought 2017-04-27 22:39:26 hm, i’ll just push it, maybe it will unblock at least 3.6 builders 2017-04-27 22:39:35 i think edge builders have nothing to build 2017-04-27 22:39:42 kaniini: Hmm, that could be a minor problem ;) 2017-04-27 22:39:44 nginx fails to build here 2017-04-27 22:39:49 clandmeter: i don't have new libressl on aarch64 btw 2017-04-27 22:39:52 failed test 2017-04-27 22:39:53 no, they should build fixed libressl 2017-04-27 22:39:54 so the aarch64 builder may be mia? 2017-04-27 22:39:59 i know why its doing it now 2017-04-27 22:40:03 I think that's how I ended up with the zfs modules installing and the kernel removing itself. 2017-04-27 22:40:08 TemptorSent: it is processing the changeset instruction wrong 2017-04-27 22:40:17 ./proxy_bind_transparent.t (Wstat: 512 Tests: 3 Failed: 2) 2017-04-27 22:40:17 because the name is different 2017-04-27 22:40:40 *facepalm* Yeah, that sounds about right. 2017-04-27 22:41:14 Same logic error that bit me trying to do it manually before I forced the issue. 2017-04-27 22:41:18 clandmeter: is that with the new libressl? 2017-04-27 22:41:25 because the CI reference in the PR uses the old one 2017-04-27 22:41:49 what CI reference? 2017-04-27 22:41:52 (10/42) Purging libressl-dev (2.5.3-r1) 2017-04-27 22:42:02 referenced* 2017-04-27 22:42:05 the edge builders are fine 2017-04-27 22:42:06 -r1, that’s correct 2017-04-27 22:42:09 kaniini: Easily fixable? 2017-04-27 22:42:13 they have new ssl 2017-04-27 22:42:14 no, they are fucking not fine 2017-04-27 22:42:32 I don’t see libressl -r1 here https://pkgs.alpinelinux.org/packages?name=libressl&branch=edge&repo=&arch=&maintainer= 2017-04-27 22:42:41 i see it on my box? 2017-04-27 22:42:52 aha, so just sync with pkgs.a.o is broken? 2017-04-27 22:42:58 p.a.o takes a bit to update 2017-04-27 22:43:00 usually 2017-04-27 22:43:03 i dont know, just stay calm :) 2017-04-27 22:43:14 yes 2017-04-27 22:43:28 i’ve restarted travis, let’s see what it will pull 2017-04-27 22:43:50 Installing libressl (2.5.3-r0) ofc :/ 2017-04-27 22:44:01 which mirror? 2017-04-27 22:44:01 :/ 2017-04-27 22:44:06 nl ? 2017-04-27 22:44:09 nl 2017-04-27 22:44:15 hmm 2017-04-27 22:44:18 thats correct 2017-04-27 22:44:24 ncopa forgot something 2017-04-27 22:44:28 fetch http://nl.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz 2017-04-27 22:44:29 it still thinks its master 2017-04-27 22:44:30 v3.5.0-4354-g56905f47f8 [http://nl.alpinelinux.org/alpine/edge/main] 2017-04-27 22:44:32 OK: 5527 distinct packages available 2017-04-27 22:44:34 is what it says 2017-04-27 22:44:42 we really need to rebuild builders infra, i’m getting really tired of troubleshooting builder failures each day :( 2017-04-27 22:44:43 so it doesnt pull from new master 2017-04-27 22:44:55 REMOVE: chosen name: b; installed name: a 2017-04-27 22:44:57 keep calm please 2017-04-27 22:44:57 indeed 2017-04-27 22:45:05 so, new mirror in builder cfg? 2017-04-27 22:45:08 its because of the recent master switch 2017-04-27 22:45:53 i will fix nl.a.o now 2017-04-27 22:45:54 even closer 2017-04-27 22:45:59 TemptorSent: i now have this: 2017-04-27 22:46:03 ah 2017-04-27 22:46:07 https://github.com/alpinelinux/aports/blob/c12931e8863fa9fddc90390db24a4a591f43043e/.travis/common.sh#L6 2017-04-27 22:46:10 may be useful to set this to dl-cdn 2017-04-27 22:46:12 :p 2017-04-27 22:46:14 I’m sorry, I’m really tired and have headache 2017-04-27 22:46:49 you’ve switched CNAME rsync to new master, so other mirrors should be okay, no? 2017-04-27 22:47:08 no, dl-cdn resolves to random mirrors and some of them are broken 2017-04-27 22:47:28 oh, i thought dl-cdn was a separate CDN thing 2017-04-27 22:47:30 raccoon:~/apk-tools$ sudo apk --root ~/apktestenv/ add --initdb -X ~/apktest/repo1 --keys-dir /etc/apk/keys a 2017-04-27 22:47:32 (1/1) Installing a (1-r0) 2017-04-27 22:47:34 OK: 0 MiB in 1 packages 2017-04-27 22:47:36 raccoon:~/apk-tools$ sudo apk --root ~/apktestenv/ upgrade -X ~/apktest/repo2 --keys-dir /etc/apk/keys --available 2017-04-27 22:47:38 (1/1) Installing b (2-r0) 2017-04-27 22:47:40 OK: 0 MiB in 2 packages 2017-04-27 22:47:42 TemptorSent: getting closer ^^^ 2017-04-27 22:47:46 no, try curl -Lv, it returns random mirros from some list 2017-04-27 22:47:53 i trust you :) 2017-04-27 22:48:09 ok cron restored 2017-04-27 22:48:39 TemptorSent: i think solution may be simpler 2017-04-27 22:49:55 clandmeter: sorry once again, you were right, build-edge-x86{,_64} are okay, they’re building nginx now; I’ve told algitbot to retry master and nothing happened on build.a.o on these builders and I’ve wrongly interpreted it 2017-04-27 22:50:36 nl is syncing 2017-04-27 22:50:40 i need to go to bed 2017-04-27 22:50:58 seems a lot of armhf changes 2017-04-27 22:51:24 :) 2017-04-27 22:51:26 that’s good, b/c armhf is miles behind :/ 2017-04-27 22:51:39 i can bump armhf tomorrow 2017-04-27 22:51:46 not sure what is holding it back 2017-04-27 22:51:53 i tried to fix it a few times 2017-04-27 22:52:03 but nobody is looking after it 2017-04-27 22:52:18 it’s simply, armhf is broken half of the year and moreover it’s quite slow :) 2017-04-27 22:52:35 so it’s behind other builders very often 2017-04-27 22:52:37 try a raspberry 2017-04-27 22:52:47 that’d be even worse 2017-04-27 22:52:54 or not? 2017-04-27 22:52:54 its not that slow 2017-04-27 22:53:07 raspberry is very slow, not sure what we currently have for armhf 2017-04-27 22:53:15 we could setup a few scaleways for arm 2017-04-27 22:53:15 xgene 2017-04-27 22:53:21 its not slow 2017-04-27 22:53:23 believe me 2017-04-27 22:53:26 jirutka: thanks for adding labels on my prs 2017-04-27 22:53:28 sync done 2017-04-27 22:53:33 nl up2date 2017-04-27 22:53:54 pefect! : 2017-04-27 22:53:55 ) 2017-04-27 22:54:48 : "only a bump to 10.8" – bump what? 2017-04-27 22:54:50 this is what we use 2017-04-27 22:54:52 http://b2b.gigabyte.com/Server-Motherboard/MP30-AR0-rev-11#ov 2017-04-27 22:54:57 jirutka: lua module 2017-04-27 22:54:59 0.10.8 2017-04-27 22:55:25 the problem is single thread operations 2017-04-27 22:55:31 which is even slower on the thudnerx 2017-04-27 22:55:38 clandmeter: it looks powerful 2017-04-27 22:55:41 aha 2017-04-27 22:55:58 for sure with recent check 2017-04-27 22:56:08 many of the test run single thread 2017-04-27 22:56:23 Shiz: that’s quite weird 2017-04-27 22:56:29 ok im to bed 2017-04-27 22:56:29 the cpu my aarch64 setup uses is... interesting 2017-04-27 22:56:31 gnite 2017-04-27 22:56:32 [ 0.000000] Boot CPU: AArch64 Processor [431f0a11] 2017-04-27 22:56:34 very clear 2017-04-27 22:57:24 clandmeter: good night! 2017-04-27 22:57:32 night clandmeter \o 2017-04-27 22:57:35 aha 2017-04-27 22:58:58 Got it? 2017-04-27 23:02:38 kaniini: What's the status of virtgrsec, is it now virthardened? 2017-04-27 23:03:28 Ive had pretty good luck building directly on odroid hardware like the c2 and xu4 2017-04-27 23:03:43 Hmm, looks like it -- cool :) 2017-04-27 23:03:44 wed use nspawns to build each pkg in a clean chroot 2017-04-27 23:05:07 (1/2) Purging a (1-r0) 2017-04-27 23:05:09 (2/2) Installing b (2-r0) 2017-04-27 23:05:11 BOOM 2017-04-27 23:05:31 TemptorSent: ^ 2017-04-27 23:05:32 Nice work! 2017-04-27 23:06:10 Do you just backtrack up to the prune point, then start the solver again? 2017-04-27 23:06:26 Or did you find a more elegant solution? 2017-04-27 23:06:38 what the heck is wrong with proxy_bind.t 2017-04-27 23:08:39 kaniini: Now I shouldn't have anything breaking any more, at worst I'll have a half-update, not everything gone :) 2017-04-27 23:09:09 okay, i can reproduce it locally… weird, maybe it’s caused by the few options i’ve added recently? 2017-04-27 23:09:33 that’s why i didn’t want to merge it yet… 2017-04-27 23:09:59 Once we have the kernel packages versioned, we shouldn't have bricked systems on failed partial updates anymore! 2017-04-27 23:10:20 nevermind, it seems that it fails b/c of some restriction on the host system, so i’m gonna just disable this test 2017-04-27 23:10:42 whats the error? 2017-04-27 23:10:48 TemptorSent: no 2017-04-27 23:11:04 no? 2017-04-27 23:11:19 TemptorSent: the solver was generating the correct solution, but due to incorrect assumptions it was being handled as a removal instead of an adjustment 2017-04-27 23:11:50 Shiz: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/nginx/nginx-1.12.0-r0.log 2017-04-27 23:12:03 Ahh, okay - failed to collide, so was treated as a new operation. 2017-04-27 23:12:04 TemptorSent: which basically means some aspects of the code were not properly understanding the concept of a package being provided by another name 2017-04-27 23:12:06 it’s wrong test 2017-04-27 23:12:16 TemptorSent: right 2017-04-27 23:12:19 TemptorSent: kind of 2017-04-27 23:12:41 TemptorSent: the patch is more explanatory 2017-04-27 23:13:07 jirutka: "Enabling this socket option requires superuser privileges (the CAP_NET_ADMIN capability)." 2017-04-27 23:13:11 re: IP_TRANSPARENT 2017-04-27 23:13:13 :) 2017-04-27 23:13:39 yeah, I have disabled this capability in my LXC container :) 2017-04-27 23:14:08 seems best to disable the test yes 2017-04-27 23:14:09 Okay -- what I ended up doing to solve my issue was backtracking a step, substituting the new name in the lookup, then retrying, and treating it as the same if it then hit. 2017-04-27 23:14:10 w/ 61 2017-04-27 23:15:44 TemptorSent: basically we had nodes in the solution {old: a, new: b}, and because a != b it was only generating a remove instead of a change 2017-04-27 23:15:45 kaniini: Looking forward to the patch and having that mainlined. 2017-04-27 23:16:44 exactly the same logic error I was hitting as a result of apk's fetching a different name than I was giving it. 2017-04-27 23:18:13 TemptorSent: http://turtle.dereferenced.org/~kaniini/apk-tools-fix-provides-upgrade-clobbering.patch.txt 2017-04-27 23:18:31 btw I’m not sure if nginx lua module actually works, they do not support 1.12.0 yet, nor libressl :( and many tests depends on many third-party modules, so I’m not sure which fail b/c of missing module and which b/c of error 2017-04-27 23:21:47 TemptorSent: does it look sane to you? 2017-04-27 23:21:53 ha, someone deployed updated http://build.alpinelinux.org/, so we have links to logs! \o/ 2017-04-27 23:21:53 Looks sane. 2017-04-27 23:23:47 kaniini: the best about it are these explanatory comments! +1 2017-04-27 23:25:04 kaniini: I agree with jirutka on that! APK needs more comments badly, as it's not exactly what you might consider 'self documenting' code ;) 2017-04-27 23:27:13 kaniini: Changing the logic to treat everything as a change first is much saner in general, and probably should be the case nearly everywhere. 2017-04-27 23:27:43 TemptorSent: it was the way it was for historical reasons 2017-04-27 23:27:48 TemptorSent: provides came later 2017-04-27 23:28:10 Yeah, bottom up design works great, until it doesn't ;) 2017-04-27 23:28:54 That's why I do so much refactoring I think, I don't let existing design decisions stand unless I can justify them. 2017-04-27 23:30:23 kaniini: APK 3 needs to have the whole structure and process laid out before starting the implementation IMHO. 2017-04-27 23:31:26 So at least unhandled areas are explicitly known and provision made to not break. 2017-04-27 23:31:28 ACTION checking if modules are upgraded, if it's good, will push to edge 2017-04-27 23:31:40 Sounds good. 2017-04-27 23:32:52 TemptorSent: don’t forget about writing tests… ;) 2017-04-27 23:33:30 jirutka: Yes, tests are rather helpful, especially once you know what you expect :) 2017-04-27 23:33:37 (25/29) Purging zfs-grsec (4.4.59-r0) 2017-04-27 23:33:39 (26/29) Purging spl-grsec (4.4.59-r0) 2017-04-27 23:33:41 (27/29) Installing spl-hardened (4.9.24-r2) 2017-04-27 23:33:43 (28/29) Installing zfs-hardened (4.9.24-r)2 2017-04-27 23:33:45 BAM 2017-04-27 23:33:51 Perfect! 2017-04-27 23:34:21 er, wait... that's a typo on zfs-hardened, right? 2017-04-27 23:34:25 yes 2017-04-27 23:34:32 Okay, just checking :) 2017-04-27 23:34:32 paste lag 2017-04-27 23:35:17 TemptorSent: https://www.dropbox.com/s/8mwoh5hwal7vo8x/Screenshot%202017-04-27%2018.35.14.png?dl=0 2017-04-27 23:35:28 kaniini: "(4.9.24-r)2" ? 2017-04-27 23:35:29 After the last entertainment with apk's output buffering, wanted to be sure :) 2017-04-27 23:36:09 jirutka: paste lag, see screenshot 2017-04-27 23:36:15 jirutka: tl;dr weechat is shit 2017-04-27 23:36:18 news at 11 2017-04-27 23:36:22 :) 2017-04-27 23:36:40 nginx 1.12.0 landed in edge 2017-04-27 23:37:25 Thanks for fixing that kaniini - it was driving me absolutely insane. 2017-04-27 23:37:44 No more upgrade-russian-roulette. 2017-04-27 23:38:19 Now if we could just get it to download all the apks before installing so we don't get a broken system in case of a network failure at a bad time, we'd be set. 2017-04-27 23:38:20 i think it has been there for a while 2017-04-27 23:38:25 i had weirdness with 3.4 and 3.5 too 2017-04-27 23:38:42 but bricking upgrades due to leaving no kernel 2017-04-27 23:38:45 was the final straw 2017-04-27 23:38:48 Probably, it just took your kernel package change to make it painfully obvious what was going on. 2017-04-27 23:39:01 :) 2017-04-27 23:39:23 No more bricks :) 2017-04-27 23:40:44 https://git.alpinelinux.org/cgit/aports/commit/?id=3de012bb 2017-04-27 23:40:48 ACTION whistles @ commit message 2017-04-27 23:41:10 I'm guessing that in some of the more insidious cases it actually caused multiple layers of faulty removals that were partially masked by subsequent upgrades, but still left holes. 2017-04-27 23:41:15 yes 2017-04-27 23:41:17 likelyt 2017-04-27 23:41:19 -t 2017-04-27 23:41:50 Which explains how I got inconsistent results doing the same thing but in slightly different order. 2017-04-27 23:41:51 anything that was swapped with a new package using provides entries would be suspect 2017-04-27 23:42:01 which there is a lot of that these days 2017-04-27 23:42:02 sooo 2017-04-27 23:42:15 hehe 2017-04-27 23:42:36 # apk upgrade 2017-04-27 23:42:38 (1/2) Upgrading libressl2.5-libcrypto (2.5.3-r0 -> 2.5.3-r1) 2017-04-27 23:42:40 (2/2) Upgrading libressl2.5-libssl (2.5.3-r0 -> 2.5.3-r1) 2017-04-27 23:42:42 OK: 10 MiB in 21 packages 2017-04-27 23:42:44 aarch64 builder kicked back into motion :) 2017-04-27 23:43:44 Nice commit message :) 2017-04-27 23:45:06 I suspect you just saved Alpine a LOT of hassles in the near future. 2017-04-27 23:46:33 nicely in time for 3.6 2017-04-27 23:46:49 Nightmare averted. 2017-04-27 23:50:15 It was getting to the point I was nervous every time the power went out because my if my UPS died, I could randomly be hosed if I had run and update and not made sure I actually had everthing. 2017-04-27 23:51:57 The changeset handling change should fix that, even if it had another vector causing it. 2017-04-27 23:52:31 (I think there is some weirdness in a corner-case for install-if) 2017-04-27 23:53:14 Same issue with orphans I suspect. 2017-04-28 00:03:42 TemptorSent: let me know if theres any more discrepancy 2017-04-28 00:08:24 with that fixed, i think it is safe to dump linux-grsec transitional package and use provides again 2017-04-28 00:22:46 kaniini: Give it a shot -- what's the WORST that could happen? ;) 2017-04-28 00:22:59 finally identified my Scaleway ARM CPU 2017-04-28 00:24:54 ThunderX T88 dualcore 2017-04-28 00:24:58 ARMv8.1-A 2017-04-28 00:53:53 Shiz: are you testing my attention? :) https://txt.shiz.me/MzljMDRjMz#l-152 2017-04-28 00:54:05 ? 2017-04-28 00:54:14 ah 2017-04-28 00:54:19 no, i just thought it looked better the other way around 2017-04-28 00:54:21 :P 2017-04-28 00:54:21 why you’ve switched order in this conditon? o.O 2017-04-28 00:54:30 as in (check_need || check_special_condition) 2017-04-28 00:54:38 as opposed to the other way it was before 2017-04-28 00:54:50 actually it was theoretically more performant before 2017-04-28 00:55:01 var check vs. func call 2017-04-28 00:55:05 and i needed to redo that patch anyway 2017-04-28 00:55:31 well, performant for something being called a single time in creating the final executable? 2017-04-28 00:55:32 ? 2017-04-28 00:55:33 :P 2017-04-28 00:55:46 feel free to change it back though if you wanna 2017-04-28 00:55:56 i mean, it'd be a function called a single time in the entire process 2017-04-28 00:55:57 I know, it doesn’t make sense, just arguing that the previous variant was slightly better :P 2017-04-28 00:56:36 this https://txt.shiz.me/MzljMDRjMz#l-117 used to be in a separate patch, didn’t it? 2017-04-28 00:59:55 uhm, if it was, it was before the patch reorganisation 2017-04-28 00:59:55 it makes more sense in the 'fix static linking patch' since it's needed for that 2017-04-28 00:59:55 :P 2017-04-28 00:59:55 this patch just addds those features for anewly added linker impl they added in 1.17.0 2017-04-28 00:59:56 (EmLinker, can you guess what for?) 2017-04-28 01:00:33 but then it have to be removed from the original patch, haven’t it? 2017-04-28 01:00:37 Emscripten? 2017-04-28 01:00:48 yeah 2017-04-28 01:00:52 jirutka: no? 2017-04-28 01:00:59 between 1.16.0 and 1.17.0 a new linker impl was added in Rust 2017-04-28 01:01:07 this addition just implements these 3 functions for that new linker 2017-04-28 01:01:13 as these 3 functions are added by our patches 2017-04-28 01:01:30 eh, aha, i see now 2017-04-28 01:02:51 okay, merged, thanks a lot! :) 2017-04-28 01:02:56 and i go sleep now 2017-04-28 01:02:56 \o/ 2017-04-28 01:03:01 good night :) 2017-04-28 01:04:50 hm, build-3-6-* builders are fucked up, they still have unpatched libressl 2017-04-28 03:42:17 TemptorSent: do i go for it? do i kill the linux-grsec transitional package now that i fixed apk itself?? 2017-04-28 03:44:26 kaniini: Might as well... After all, it can't break any worse, right? 2017-04-28 03:44:46 TemptorSent: it should be fine i think 2017-04-28 03:46:12 'should' and 'I think' in the same sentence... what could possibly go wrong? :P 2017-04-28 03:47:06 at least apk always upgrades itself first :) 2017-04-28 03:51:34 TemptorSent: https://git.alpinelinux.org/cgit/aports/commit/?id=1e735e4a 2017-04-28 03:53:05 *LOL* Oh, that's an awesome commit message! 2017-04-28 03:54:05 that's pretty impressive indeed lol 2017-04-28 03:54:44 do all the previous -grsec modules also provide their -hardened variants now? 2017-04-28 03:54:49 err, other way around but you get what i mean 2017-04-28 03:54:59 Shiz: yes 2017-04-28 03:55:03 Shiz: they always did 2017-04-28 03:55:11 ocool 2017-04-28 03:55:15 Shiz: i just put linux-grsec in as a temporary workaround while i debugged apk 2017-04-28 03:55:29 because SAT solvers are not things meant to be debugged at 03:45am 2017-04-28 03:56:11 :P 2017-04-28 03:56:23 Damn good work nailing it down in the first place. 2017-04-28 04:00:34 We really need to do somethign about the kernel building system -- it shouldn't take that many changes to bump a kernel version 2017-04-28 04:03:17 :D 2017-04-28 04:03:47 REMEMBER THAT TIME I BROKE THE ENTIRE DISTRO OH WAIT IT WAS LAST NIGHT 2017-04-28 04:04:51 *lol* 2017-04-28 04:06:01 hopefully renaming the package will have a positive impact such as 2017-04-28 04:06:12 making the "grsec is 100% of alpine's security" crowd fuck off 2017-04-28 04:06:15 that would be pretty cool 2017-04-28 04:06:21 Agreed. 2017-04-28 04:06:30 Maybe we can do some actual hardening. 2017-04-28 04:06:35 because they are quite annoying 2017-04-28 04:06:46 oh, grsec is great for what it is 2017-04-28 04:06:52 it's just that 2017-04-28 04:07:21 there's a lot more going on than just grsec re: security in alpine, and if you don't want to run grsec it doesn't really change your security exposure that much 2017-04-28 04:07:26 But simple stuff like canary checks and syscall auditing have more day-to-day impact against the classes of exploits we're likely to see. 2017-04-28 04:07:38 right, which is why we do all of that too 2017-04-28 04:08:23 Replace the missing roof before you worry about the open window. 2017-04-28 04:09:02 right 2017-04-28 04:09:35 way i put it is 2017-04-28 04:10:19 grsecurity is like having a 12 gauge vs having a 20 gauge shotgun to protect your house 2017-04-28 04:10:28 12 gauge is a little better 2017-04-28 04:10:31 but both are good 2017-04-28 04:10:50 it's sometimes nice to have the additional kernel security hardening that grsecurity provides 2017-04-28 04:10:56 And in in both cases, the ammo is more of a consideration than the bore. 2017-04-28 04:11:03 exactly 2017-04-28 04:11:08 point is 2017-04-28 04:11:13 it's just one of many variables 2017-04-28 04:11:35 fwiw 2017-04-28 04:11:46 seems like the gentoo hardened folks are setting up a hardened kernel project 2017-04-28 04:11:51 I found bits and pieces of grsec useful, but not so much overall. 2017-04-28 04:11:52 https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project 2017-04-28 04:11:52 T_T 2017-04-28 04:11:57 They've had a hardened kernel for ages. 2017-04-28 04:12:00 (also im still not asleep) 2017-04-28 04:12:04 TemptorSent: please read the actual page. 2017-04-28 04:12:08 Latest alpine update turn my laptop into a brick. 2017-04-28 04:12:13 they had hardened-sources for years 2017-04-28 04:12:15 not the same 2017-04-28 04:12:23 T_T 2017-04-28 04:12:52 The change of `vmlinux-linux` 2017-04-28 04:13:02 Into `vmlinuz-hardened` T_T 2017-04-28 04:13:15 Need to flash coreboot again and fix that. 2017-04-28 04:13:21 lol 2017-04-28 04:13:30 Okay, looks like they're turning it into a larger community project, cool. 2017-04-28 04:16:02 BTW - are we tracking their hardened-musl project? 2017-04-28 04:16:19 it's not very interesting to us 2017-04-28 04:16:27 they do nothing we don't, afaik 2017-04-28 04:16:33 Shiz: why do you think we moved to just -hardened? :) 2017-04-28 04:16:44 kaniini: because i suggested the name to ncopa 2017-04-28 04:16:49 i'm just saying a project actually exists now 2017-04-28 04:16:51 :P 2017-04-28 04:17:13 Shiz: anyway, we might collaborate with them, but we are watching first to see if they actually bring something to table 2017-04-28 04:17:20 sounds fair 2017-04-28 04:17:30 i talked to strcat in #pax today about such a project 2017-04-28 04:17:39 and he seemed interested in it as well, as long as he didn't have to do x86_64 work 2017-04-28 04:17:40 before or after he was banned 2017-04-28 04:17:41 :P 2017-04-28 04:17:42 ;) 2017-04-28 04:17:46 that was #grsecurity 2017-04-28 04:17:48 ;p 2017-04-28 04:17:50 #pax has no ops 2017-04-28 04:18:46 but it's nice since uhm 2017-04-28 04:18:50 strcat is at least competent 2017-04-28 04:20:21 The patchsets in gentools proj/musl.git look potentially useful for reference. 2017-04-28 04:21:45 They may save some people time porting. 2017-04-28 04:22:08 i ran gentoo musl befor 2017-04-28 04:22:12 eit's not nearly as advanced as alpine 2017-04-28 04:22:17 things would break every 3 packages 2017-04-28 04:22:39 Yeah, just noticing some recent patches for things such as libvirt that may be of interest. 2017-04-28 04:22:40 it's also run by two people 2017-04-28 04:22:40 but yeah, they may have patches for packages we don't carry yet, same with void etc 2017-04-28 04:22:43 and I'm one of the two 2017-04-28 04:22:54 and I haven't written open source code in six months 2017-04-28 04:22:59 so there's that too 2017-04-28 04:23:10 :p 2017-04-28 04:23:56 they have a patch to boehm-gc that fixes a correctness issue on musl/x86_64 that doesn't exist on any other arch but is bad enough to make w3m broken if you don't apply it; I don't think alpine packages either boehm-gc nor w3m (when I looked anyway) so it isn't relevant but 2017-04-28 04:24:01 yes they do have patches for things alpine doesn't 2017-04-28 04:24:09 alpine also has a much more comprehensive gcc patchset 2017-04-28 04:24:12 And some interesting workarounds for nss... 2017-04-28 04:24:20 void took the kde packages from ad�lie too 2017-04-28 04:24:21 nss shouldn't be worked out 2017-04-28 04:24:23 it should be excluded 2017-04-28 04:24:25 :P 2017-04-28 04:24:29 awilfox: your encoding's broken 2017-04-28 04:24:43 nss is much better than openssl 2017-04-28 04:24:47 it's a shame less things use it 2017-04-28 04:24:55 no, other nss :) 2017-04-28 04:25:03 oh 2017-04-28 04:25:05 that 2017-04-28 04:25:11 name service switch 2017-04-28 04:25:18 the only thing i remember from NSS the security library is that it didn't support DH keys >1024 or so bits a couple of years back 2017-04-28 04:25:21 because "DoS reasons" lol 2017-04-28 04:25:26 both should be eradicated 2017-04-28 04:25:50 anyway, i don't care about grsecurity itself 2017-04-28 04:25:58 my problem is the grsec fanboys who show up 2017-04-28 04:26:04 they are unpleasant 2017-04-28 04:26:12 well, i'm a grsec fanboy 2017-04-28 04:26:15 they make ircd fanboys look tolerable 2017-04-28 04:26:16 am i that unpleasant 2017-04-28 04:26:27 Shiz: i mean the "grsec is 100% of alpine's security story" crowd 2017-04-28 04:26:33 :P 2017-04-28 04:26:44 i'll admit it's a big reason why i picked alpine back when i did 2017-04-28 04:26:47 bahamut master race 2017-04-28 04:26:48 if you've sat on #alpine-linux you know exactly what i am talking about 2017-04-28 04:26:55 and now i run my own kernels always anyway 2017-04-28 04:27:17 there's nothing wrong with carrying grsecurity patch as an option 2017-04-28 04:27:33 i do consider it a way that alpine does provide more choices than most distributions 2017-04-28 04:27:43 but it doesn't mean grsec is the only aspect of our security plans either 2017-04-28 04:28:17 that's the part i don't like about the grsec fanboy crowd that shows up on #alpine-linux 2017-04-28 04:28:19 I'd be happy with a couple of PaX features and the gcc plugins out of it. 2017-04-28 04:28:21 it's just so ignorant 2017-04-28 04:28:34 anyway 2017-04-28 04:28:35 The rest was take it or leave it IMHO, and not terribly portable. 2017-04-28 04:28:49 low-level protections are inherently unportable 2017-04-28 04:28:50 so i am happy that we call it -hardened now 2017-04-28 04:28:50 that's how it works 2017-04-28 04:29:01 imo it should've been -hardened in the first place 2017-04-28 04:29:04 anyway 2017-04-28 04:29:10 Yeah, unportable in ways they don't need to be. 2017-04-28 04:29:29 if a viable/competent hardening project shows up, i think it'd be nice if we could contribute to it 2017-04-28 04:29:35 i'd be willing to invest work in it 2017-04-28 04:29:56 Shiz: i just find it irritating that people show up and have that attitude re: grsec, given that we have done a lot of work outside of grsec to build a hardened distribution that people can actually use 2017-04-28 04:30:07 and yes 2017-04-28 04:30:09 i agree 100% 2017-04-28 04:30:32 we should continue to innovate with the kernel instead of duplicate 2017-04-28 04:30:34 Agreed. 2017-04-28 04:31:20 so kaniini, now that you broke all of Alpine, any thoughts on manifesting? 2017-04-28 04:31:25 ;) 2017-04-28 04:32:14 Hmm, no kernel upgrade with apk upgrade... 2017-04-28 04:32:23 TemptorSent: x86_64 hasn't landed yet 2017-04-28 04:32:43 TemptorSent: presently building zfs-hardened: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/zfs-hardened/zfs-hardened-4.9.24-r3.log 2017-04-28 04:32:47 Ahh, okay -- apk-tools has, which makes me smile. 2017-04-28 04:33:52 TemptorSent: http://build.alpinelinux.org/ 2017-04-28 04:34:46 57% on ZFS. 2017-04-28 04:34:52 3.6 builders are building again 2017-04-28 04:34:54 yay 2017-04-28 04:35:14 theoretically, spl is done then. 2017-04-28 04:35:18 TemptorSent: that's 57% of the packages in queue 2017-04-28 04:35:21 :P 2017-04-28 04:35:29 Right, 2017-04-28 04:35:53 Meaning as soon as zfs is done, everything I need should be built. 2017-04-28 04:36:22 Packaging... 2017-04-28 04:36:27 and it is done 2017-04-28 04:36:34 but packages only get uploaded at the end of the run 2017-04-28 04:36:36 afaik 2017-04-28 04:37:08 Looks that way. 2017-04-28 04:37:12 Almost ther. 2017-04-28 04:37:46 Bing! 2017-04-28 04:38:04 Should show up from -commits in a sec 2017-04-28 04:38:32 Well shit, no kernel. 2017-04-28 04:38:44 what mirror ? 2017-04-28 04:38:47 rsync :P 2017-04-28 04:39:07 yep, rsync 2017-04-28 04:39:25 It installed spl and zfs, but I have a bricked system again :( 2017-04-28 04:40:10 Something is still very wrong 2017-04-28 04:40:20 with --available ? 2017-04-28 04:40:42 Yes. 2017-04-28 04:41:10 I can see it with policy, but it's not even trying. 2017-04-28 04:41:37 let me test clean upgrade 2017-04-28 04:42:03 So I now have spl and zfs at 4.9.24-r3, but my kernel is stuck at 4.9.24-r2 2017-04-28 04:44:15 clean upgrade i get 2017-04-28 04:44:17 (24/29) Installing linux-hardened (4.9.24-r3) 2017-04-28 04:44:19 (25/29) Purging zfs-grsec (4.4.59-r0) 2017-04-28 04:44:21 (26/29) Purging spl-grsec (4.4.59-r0) 2017-04-28 04:44:23 (27/29) Installing spl-hardened (4.9.24-r3) 2017-04-28 04:44:25 (28/29) Installing zfs-hardened (4.9.24-r3) 2017-04-28 04:44:40 what happened to the kernel there? 2017-04-28 04:44:46 linux-grsec was purged 2017-04-28 04:44:54 sec, pastebinning entire install log 2017-04-28 04:44:55 Right, I'm already on hardened. 2017-04-28 04:45:12 It's failing to update from hardened to hardened. 2017-04-28 04:45:24 I have hardened in my world. 2017-04-28 04:45:49 http://sprunge.us/PVKE 2017-04-28 04:45:56 Something is fubar somewhere. 2017-04-28 04:46:09 /etc/apk/world ? 2017-04-28 04:47:04 Oh, FFS -- something somehow pinned 'linux-grsec=4.9.20-r0' in my world file, and I didn't do it. 2017-04-28 04:47:19 :D 2017-04-28 04:47:21 :P 2017-04-28 04:47:30 inb4 there was never a bug at all 2017-04-28 04:47:39 Shiz: there was a bug in APK 2017-04-28 04:47:45 i kid, i kid 2017-04-28 04:48:05 but i'm pretty sure that is 100% fixed now :) 2017-04-28 04:48:46 I think it was one of the updates that did that, as I didn't have it in there before this mess started, and that's my currently running kernel. 2017-04-28 04:49:19 :D :D :D :D :D :D :D :D :D :D :D 2017-04-28 04:49:42 Because I was getting the same behavior in a fresh apkroot as well 2017-04-28 04:50:00 updates don't edit /etc/apk/world 2017-04-28 04:50:02 lol 2017-04-28 04:50:23 Then how exactly would that get there? 2017-04-28 04:50:41 IDK 2017-04-28 04:50:55 but /etc/apk/world is user selections only 2017-04-28 04:51:12 That's nice, but I never tagged it. 2017-04-28 04:51:16 apk itself will never write to it unless a mutation is requested 2017-04-28 04:51:22 so, i dunno 2017-04-28 04:51:28 well 2017-04-28 04:51:29 wait 2017-04-28 04:51:31 wait 2017-04-28 04:51:33 wait 2017-04-28 04:51:35 i know 2017-04-28 04:51:42 it might be from messing with 2017-04-28 04:51:54 apk add --virtual .mkinitfs-dep linux-grsec=4.9.20-r0 2017-04-28 04:52:01 i told you about that 2017-04-28 04:52:07 and then made it possible to fetch on a virtual 2017-04-28 04:52:12 so it might be from that 2017-04-28 04:52:19 Yeah, but I never executed that in my apkroot 2017-04-28 04:52:25 dunno then 2017-04-28 04:52:41 that's all i got 2017-04-28 04:52:44 Unless it breaks with an alternate root in a weird way... 2017-04-28 04:53:28 Wait, how about the virtual package for the transitional package? What was that dep? 2017-04-28 04:53:41 linux-hardened>=4.9.21-r1 2017-04-28 04:53:43 but 2017-04-28 04:53:49 if you have linux-grsec=4.9.20-r0 pinned 2017-04-28 04:53:52 you wouldnt have gotten it 2017-04-28 04:53:54 :p 2017-04-28 04:53:57 Because here's the weird thing -- the LAST time I did the upgrade it upgraded the kernel! 2017-04-28 04:54:18 Yeah, so why was I getting modules every time and the kernel occasionally? 2017-04-28 04:54:50 And I had explicitly removed linux-grsec from my world file to get it to fetch hardened in the first place! 2017-04-28 04:54:59 Somethign is still fishy. 2017-04-28 04:55:15 Modules shouldn't be upgrading to a different version than the kernel, no matter what. 2017-04-28 04:55:22 That is broken resolving. 2017-04-28 04:56:33 Yeah, if that was pinned, I also wouldn't have had the rest of the symptoms... somethign is very weird. 2017-04-28 04:56:46 (1/4) Purging linux-grsec (4.9.24-r1) 2017-04-28 04:56:47 (2/4) Upgrading linux-hardened (4.9.24-r2 -> 4.9.24-r3) 2017-04-28 04:56:49 (3/4) Upgrading spl-hardened (4.9.24-r2 -> 4.9.24-r3) 2017-04-28 04:56:51 (4/4) Upgrading zfs-hardened (4.9.24-r2 -> 4.9.24-r3) 2017-04-28 04:57:04 humm, it upgraded all the modules for me just now outside the apkroot 2017-04-28 04:57:30 Yeah, but why would it upgrade the modules but NOT the kernel in ANY case? 2017-04-28 04:57:51 it shouldn't, 2017-04-28 04:57:55 That shouldn't happen -- if it's pinned at an earlier version, it should either get those modules or fail. 2017-04-28 04:58:25 Try pinning your kernel, then retrying that... 2017-04-28 04:58:42 raccoon:~/aports$ sudo apk --root ~/apkupgrade/ info spl-hardened --depends 2017-04-28 04:58:44 spl-hardened-4.9.24-r3 depends on: 2017-04-28 04:58:46 hmmmm 2017-04-28 04:59:17 looks like you may be onto something here, these kernel module packages are missing dependency on linux-hardened 2017-04-28 04:59:19 Yeah, that's starting to make sense. 2017-04-28 04:59:21 i wonder when /that/ broke 2017-04-28 04:59:38 A long time ago, because it was broken on -grsec before any of this. 2017-04-28 05:00:09 sigh, i don't want to do *another* rebuild 2017-04-28 05:00:25 lol 2017-04-28 05:00:35 I'm sorry -- I just seem to be good at turning up corner cases for some reason. 2017-04-28 05:00:46 depends="" 2017-04-28 05:00:48 indeed... 2017-04-28 05:00:51 this is definitely wrong 2017-04-28 05:01:07 should be depends=linux-hardened=${_kpkgver} 2017-04-28 05:01:18 Agreed. 2017-04-28 05:01:37 lets see if -vanilla modules are fucked too 2017-04-28 05:01:40 i predict yes 2017-04-28 05:01:54 depends="" 2017-04-28 05:01:56 depends_dev="linux-vanilla-dev=$_kernelver" 2017-04-28 05:01:58 and what do you know 2017-04-28 05:01:59 Likely, yes -- this whole thing of having the flavor for the package name fubars it. 2017-04-28 05:02:00 i was right 2017-04-28 05:02:35 yes but it is too close to release to just completely overhaul the packaging imo 2017-04-28 05:02:40 Fixing the package naming will largely eliminate that, since we can just dep on the proper package. 2017-04-28 05:02:41 ON THE OTHER HAND 2017-04-28 05:02:46 KIND OF GOOD WE FOUND THAT BUG LOL 2017-04-28 05:03:05 Yeah, that might be a problem for a few people when upgrade time comes :) 2017-04-28 05:03:16 okay 2017-04-28 05:03:18 so basically 2017-04-28 05:03:22 all the APKBUILDs need to be fixed 2017-04-28 05:03:36 to reference linux-hardened=${_kpkgver} or similar 2017-04-28 05:03:38 It looks that way. 2017-04-28 05:04:06 who wants to take that one on 2017-04-28 05:04:15 A single abuild for each that references linux-$_flavor=$_kpkgver would be ideal. 2017-04-28 05:04:16 its simple work, just tedious and annoying 2017-04-28 05:04:29 sed -i ? 2017-04-28 05:04:42 TemptorSent: cant, not all the APKBUILDs use the same variable names ;/ 2017-04-28 05:04:57 Oh, FFS. 2017-04-28 05:05:01 h/o 2017-04-28 05:05:04 i am git blaming this 2017-04-28 05:05:08 i'll do it 2017-04-28 05:05:10 when i wake up again 2017-04-28 05:05:34 Can we fix the variable names at least so they're consistent across all the kernel builds? 2017-04-28 05:05:57 :D 2017-04-28 05:05:58 So we can update such things in the future without so much pain. 2017-04-28 05:07:09 well 2017-04-28 05:07:11 git blame 2017-04-28 05:07:13 was inconclusive 2017-04-28 05:07:21 wait 2017-04-28 05:07:24 3.5 is probably fucked too 2017-04-28 05:07:27 to 3.5! 2017-04-28 05:07:29 In other words, it's been broken for ever? 2017-04-28 05:07:35 Awesome! 2017-04-28 05:08:17 And somehow I just now turned up with actual breakage? How the hell did people get that lucky, that long? 2017-04-28 05:08:24 ohhhhh 2017-04-28 05:08:30 clandmeter!!!! 2017-04-28 05:08:54 TemptorSent: good news! 2017-04-28 05:08:58 TemptorSent: seems it's just zfs 2017-04-28 05:09:09 .oO{ is it bad I am kind of hoping `git blame` turns up like alpine 1.1 because that would just be the most hilarious kind of schrodinbug } 2017-04-28 05:09:09 Oh! 2017-04-28 05:09:44 Sounds like it might have been there as long as zfs anyway ;) 2017-04-28 05:10:10 TemptorSent: working on it 2017-04-28 05:10:13 TemptorSent: and yes!!! 2017-04-28 05:10:44 Woohoo! 2017-04-28 05:12:21 Wait, the APKBUILD looks more broken than that... 2017-04-28 05:12:48 the kernel release string might be broken... 2017-04-28 05:13:42 Yep, vanilla kernels don't always have the -0 for the release string, so the vanilla modules need a check I think. 2017-04-28 05:14:39 That needs to be fixed, because having 4.9.24-0 in one place and 4.9.24 in another breaks things. 2017-04-28 05:16:55 kaniini: also, the install-if in zfs-hardened appears wrong. 2017-04-28 05:17:13 it references -grsec still 2017-04-28 05:17:59 it will work, but good catch 2017-04-28 05:19:32 The vanilla abiversion mismatch won't work though I suspect. 2017-04-28 05:19:32 TemptorSent: vanilla kernels need same 2017-04-28 05:22:18 Hmm, I wonder if that will randomly fix the s390x build? 2017-04-28 05:22:36 nope 2017-04-28 05:22:39 s390x fucked 2017-04-28 05:22:39 How do I tell algitbot to retry? 2017-04-28 05:22:43 for other reasons 2017-04-28 05:23:00 Looks like spl has version missmatch. 2017-04-28 05:24:12 nope 2017-04-28 05:24:24 s390x kernel config is missing stuff 2017-04-28 05:24:27 needed by spl 2017-04-28 05:24:30 is why its broken there 2017-04-28 05:25:24 Ahh, lack of kmem accounting. 2017-04-28 05:25:50 And possibly other issues... 2017-04-28 05:26:23 Are detailed build results available anywhere? 2017-04-28 05:26:44 (config.status, config.cache, etc?) 2017-04-28 05:26:55 just deploy an IBM LinuxOne(R) instance and rebuild it 2017-04-28 05:26:57 duhhhhh 2017-04-28 05:27:09 Yeah - have one I haven't played with yet. 2017-04-28 05:27:14 Expires soon :) 2017-04-28 05:27:27 hop to it 2017-04-28 05:28:23 well 2017-04-28 05:28:26 that should solve that 2017-04-28 05:28:42 Yeah, expires in two days, might be worht extending it first :) 2017-04-28 05:31:30 I heard there was some word in here earlier about the grsec matter 2017-04-28 05:32:08 minimalism: yes!!! 2017-04-28 05:32:16 minimalism: we are going to send ISIL to spender's house!!! 2017-04-28 05:32:25 minimalism: who will, *ahem* "convince" him to change his mind!!! 2017-04-28 05:32:28 I'm mainly a gentoo user, but it seems everyone concerned about it is busy having internal strife over it 2017-04-28 05:32:36 not us! 2017-04-28 05:32:40 so it seems 2017-04-28 05:32:41 we're pretty much chill about the whole thing 2017-04-28 05:32:50 spender's gonna spend, etc 2017-04-28 05:32:53 You said you were willing to collaborate with other distros, right? 2017-04-28 05:33:05 sure if they actually bring something to the table 2017-04-28 05:33:11 otherwise we'll just do our own thing, it's cool 2017-04-28 05:33:27 well, this is what's generally being argued in other channels 2017-04-28 05:33:34 a) we can't live without grsec, let's pay the piper 2017-04-28 05:33:41 b) it will take too long to develop a community alternative 2017-04-28 05:33:48 we can definitely live without grsec 2017-04-28 05:33:50 it's all good 2017-04-28 05:33:59 c) let's build our own 2017-04-28 05:34:18 and i care why ? 2017-04-28 05:34:43 i wasn't aware the woes of gentoo users were alpine's problem 2017-04-28 05:34:56 c is probably the only way it's worth going, possibly in coordination with other groups. 2017-04-28 05:34:58 Not saying they are 2017-04-28 05:35:08 maybe you can solve it with USE flags and CFLAGS strings at least 1KB long 2017-04-28 05:35:21 just saying everyone's being kind of difficult about it in favor of their own solution that might not be as good as a real community effort 2017-04-28 05:35:29 minimalism: it doesn't really bug us either way 2017-04-28 05:35:42 minimalism: we've basically been running a grsec *fork* for 2 years anyway 2017-04-28 05:35:48 Long term, we want some kernel security improvements, but grsec isn't the end-all-be-all-at-all :) 2017-04-28 05:36:01 we're just gonna keep doing what we do maaaaaaaan 2017-04-28 05:36:21 if some peeps bring something concrete to the table we might come play 2017-04-28 05:36:27 if they dont, we wont 2017-04-28 05:36:31 it's all good either way 2017-04-28 05:36:41 is this table a non-distro table? 2017-04-28 05:36:48 could be 2017-04-28 05:36:58 any table is good 2017-04-28 05:37:05 distro/non-distro/whatever 2017-04-28 05:38:23 It would generally be preferable to have it non-disto-centric for maintainability. 2017-04-28 05:38:46 minimalism: basically end of the day we want to see commitment before we come play 2017-04-28 05:38:53 is really it 2017-04-28 05:39:15 because we know that doing security at distro scale is hard 2017-04-28 05:39:28 and we know that doing kernel security at distro scale is even harder, because we already do it! 2017-04-28 05:39:45 so, need to see proof that something is concrete before we commit to anything 2017-04-28 05:39:48 is basically the bottom line 2017-04-28 05:39:56 if nothing surfaces, no harm no foul, it's all gooooood 2017-04-28 05:40:18 are you on those dank leaves again 2017-04-28 05:40:42 ACTION checks room name 2017-04-28 05:40:47 In the mean time, cherry pick the good, maintainable code and keep it rebased, and find solutions for anything really critical. 2017-04-28 05:40:56 Shiz: no, this is #alpine not #atheme, I doubt he is 2017-04-28 05:40:59 This is Alpine, we're supposed to be high. 2017-04-28 05:41:08 boo 2017-04-28 05:41:22 what TemptorSent said obviously! 2017-04-28 05:41:55 minimalism: but in all seriousness, like i said, we will come play if someone produces something that is interesting to us that we feel isn't a waste of our resources 2017-04-28 05:42:42 The KSPP works looks interesting, but there's another set of politics and some technical problems there too. 2017-04-28 05:42:57 minimalism: we generally think that having multiple stakeholders for a grsecurity replacement is a good thing, but again, if it doesn't happen we have other options 2017-04-28 05:43:09 minimalism: we have been planning for this eventuality for the past 2 years 2017-04-28 05:43:15 KSPP has a few issues, most of them being that upstreaming is hard and their work has lead ot incomplete/lacking replacements supposedly 2017-04-28 05:43:44 Shiz: arguably any replacement that does not generate revenue for spender is lacking though! 2017-04-28 05:43:49 Yeah, good, upstreamable solutions should be top priority. 2017-04-28 05:43:51 gotta keep that one in mind :) 2017-04-28 05:44:43 Meaning wherever possible, surgical and easily tested, or linus will send it to the bit bucket. 2017-04-28 05:45:53 minimalism: in fact, it appears we have been planning for this eventuality for many orders of magnitude longer than these other distributions! quite funny, that! 2017-04-28 05:46:14 keep it in your pants 2017-04-28 05:46:17 minimalism: so basically, here's the talking points 2017-04-28 05:46:18 kaniini: well yes.. some details like that were brought up in regards to spender's personality 2017-04-28 05:46:29 I said 2015 should've been enough indication he was unstable 2017-04-28 05:46:31 I don't know if ted ever drops in here, but I'm sure he can offer some very good advice on how to get something to actually land in the mainline in a reasonable time. 2017-04-28 05:46:31 and may do this 2017-04-28 05:46:49 minimalism: we have been planning for this outcome since 2011 actually 2017-04-28 05:46:53 damn 2017-04-28 05:47:41 minimalism: we kinda want to get in on this $ for patch game tho 2017-04-28 05:47:45 minimalism: what do you think is good pricing 2017-04-28 05:47:54 *LOL* 2017-04-28 05:48:12 well, this is officially a sperg's nightmare.. Microsoft is winning in here 2017-04-28 05:48:18 gonna wake up now 2017-04-28 05:48:28 i am kidding about that 2017-04-28 05:48:33 I know 2017-04-28 05:49:07 there's a few aspects of our plan that have been in effect for many years 2017-04-28 05:49:17 although we have been pushing much harder since 2015 2017-04-28 05:49:36 securing userspace has been a high priority for us (which is largely why we switched to musl) 2017-04-28 05:50:20 reverse engineering PaX has been an ongoing thing for some time, i have built prototype LSMs that emulate some PaX features in 2011 when spender first started threatening this 2017-04-28 05:50:55 Whats the status on the gcc plugins? 2017-04-28 05:51:13 letting the KSPP guys handle that one, they seem to have it on lock 2017-04-28 05:51:24 Cool. 2017-04-28 05:51:45 And the stack protection / NX perms? 2017-04-28 05:52:03 stack protection is done for years on -vanilla ;) 2017-04-28 05:52:11 the wiki page on the gentoo project seems to have an overview what is upstream and not 2017-04-28 05:52:21 https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project#Progress_tracking 2017-04-28 05:52:34 NX is in hardware honestly it's good enough for 99% of our installs 2017-04-28 05:52:50 Right, but is the logic there? 2017-04-28 05:52:52 it seems they managed to get kees onboard 2017-04-28 05:52:54 that's nice 2017-04-28 05:53:30 minimalism: so basically 2017-04-28 05:53:53 minimalism: we're probably going to work with KSPP and get the parts we already came up with shot over there so they can do something useful with them 2017-04-28 05:54:14 in the immediate term we are more worried about shipping 3.6 2017-04-28 05:54:43 minimalism: one thing we want to do is switch system compiler to clang with CFI plugin and adapt the kernel to build under such a setup 2017-04-28 05:55:07 There's a way to use clang without any dependency on gcc whatsoever? 2017-04-28 05:55:10 which honestly between that and NX support is good enough 2017-04-28 05:55:31 minimalism: yes, compiler-rt provides a libgcc replacement 2017-04-28 05:55:38 UDEREF is pretty big 2017-04-28 05:55:47 You may be able to completely de-GNU Alpine? 2017-04-28 05:55:53 and well, MPROTECT 2017-04-28 05:55:55 minimalism: yes 2017-04-28 05:56:00 amazing 2017-04-28 05:56:08 Shiz: MPROTECT can be done with LSM, i built a prototype 5 years ago 2017-04-28 05:56:15 Yes, UDEREF/MPROTECT are the intersting parts of GRSEC IMHO. 2017-04-28 05:56:37 And they're really not grsec dependent that I can see 2017-04-28 05:56:49 they are pax features 2017-04-28 05:56:51 nothing is "grsec dependent" 2017-04-28 05:56:53 :P 2017-04-28 05:57:10 UDEREF is a lot trickier 2017-04-28 05:57:12 Well, it's not tied to much of the rest of their infrastructure. 2017-04-28 05:57:47 UDEREF has a lot of possible problems to address. 2017-04-28 05:58:19 Various semantic changes could break things in subtle ways. 2017-04-28 05:58:53 UDEREF honestly 2017-04-28 05:58:56 does not matter that much 2017-04-28 05:59:03 imo uderef is pretty big 2017-04-28 05:59:07 it's really not 2017-04-28 05:59:17 Well, proper segmentation anyway. 2017-04-28 05:59:18 if you're running on x86_64 it is a complete waste of time 2017-04-28 05:59:31 There's a reason it's called a 'segmentation fault'. 2017-04-28 05:59:46 Enforcing that is a good thing. 2017-04-28 05:59:58 and code instrumentation does a reasonably good job at emulating the effects of UDEREF anyway 2017-04-28 06:00:13 that's why GCC plugins is where all the hotness is these days 2017-04-28 06:00:19 dont see at all how it's a waste of time 2017-04-28 06:00:33 because x86_64 is not segmented 2017-04-28 06:01:39 IIRC UDEREF essentially segments it with a layer of indirection tables. 2017-04-28 06:02:34 right 2017-04-28 06:02:39 like i said 2017-04-28 06:02:47 waste of time verses what can be done with instrumentation 2017-04-28 06:03:18 Yes, most of the time, but it does catch some very nasty classes of bugs and exploits I believe. 2017-04-28 06:03:47 yes, but those bugs/exploits can be caught using instrumentation (which is how modern UDEREF works anyway) 2017-04-28 06:04:08 modern UDEREF works through SMEP/SMAP 2017-04-28 06:04:10 lol 2017-04-28 06:04:38 that too 2017-04-28 06:04:42 which is available in vanilla 2017-04-28 06:04:44 Right, it abuses the extended page tables in creative ways. 2017-04-28 06:04:50 sorry, i was thinking about KERNEXEC 2017-04-28 06:05:04 i was wondering where this was going 2017-04-28 06:05:05 lol 2017-04-28 06:05:13 Ahh, yeah - kernexec makes sense. 2017-04-28 06:06:11 The problem with UDEREF is mostly copy semantics. 2017-04-28 06:06:33 copy_[to|from]_user() has been considerably hardened in recent years 2017-04-28 06:06:38 so i still question the value of UDEREF ;) 2017-04-28 06:06:40 anyway :) 2017-04-28 06:06:52 That's not the problem it solves, its the problem it creates. 2017-04-28 06:07:13 the problem it solves is bogus pointers suddenly wormholing to userspace 2017-04-28 06:07:38 yeah, the problem is the *lack* of usage of copy_*_user() 2017-04-28 06:07:43 through incompetence or pointer manip or otherwise 2017-04-28 06:08:22 Pretty much, or sometimes through rather intentional tricks, which need to be worked around if UDEREF is implemented with special cases. 2017-04-28 06:08:38 that's what pax_open_kernel/pax_close_kernel does 2017-04-28 06:08:40 :P 2017-04-28 06:09:25 Zero-copy semantics are the hardest to handle, since you really can't know which are valid pointers or not in many cases. 2017-04-28 06:10:31 So fast network handling, encryption, and a few other things may end up breaking, possibly in insecure ways if care isn't used. 2017-04-28 06:10:40 (such as leaking encryption keys) 2017-04-28 06:11:12 sure 2017-04-28 06:11:38 and if somebody wants to split that out 2017-04-28 06:11:46 obviously we will carry it :P 2017-04-28 06:11:57 I'd say any of the encryption/packet acceleration hardare driver/userland interfaces would require extensive auditing before using with something like UDEREF. 2017-04-28 06:12:12 yes 2017-04-28 06:13:15 So UDEREF isn't what I'd call low-hanging fruit, and it's value is somewhat tempered on many platforms without some serious effort. 2017-04-28 06:13:30 hard but needed work :P 2017-04-28 06:14:36 I'd go after finer-grained page permissions first, and possibly look at the copy semantics themselves. 2017-04-28 06:17:58 I've got to call it an early night tonight, have a meeting to crash in the morning. 2017-04-28 06:20:02 TemptorSent: i already have LSM that implements MPROTECT W^X and similar around here somewhere, NX-emulation is likely possible through playing with segments or PTEs on x86 (but honestly not sure if it is worth it) 2017-04-28 06:20:49 Anway, if you get some spare time kaniini, would you please look into getting apk to spit out the checksums and file listing for an apk on demand? 2017-04-28 06:21:16 Cool. I'll take a look at that this weekend. 2017-04-28 06:24:07 kaniini Perhaps an option to 'apk verify'? 2017-04-28 06:26:16 kaniini: 'apk verify -v --sums' 2017-04-28 06:26:51 verify the file, and compute the requested sums. 2017-04-28 06:27:26 kaniini: output as ':' ie 'sha1sum:... 2017-04-28 06:27:46 kaniini: Feasible? 2017-04-28 06:29:43 So the listing would look essentially the same as a sha1sums run against the extracted file, with "sha1:" (oops, not sha1sum) prepended to each sum. 2017-04-28 06:30:15 Ideally, it would also compute any requested sum after verifying the stored sum against the file contents. 2017-04-28 06:32:53 So 'apk verify -v --sha512sums linux-hardened-4.9.24-r3.apk' would verify the contents using the sha1 sums in the PAX headers, then calculate the sha512 sums for the files, and print entries for each. 2017-04-28 06:34:18 Anyway, g'night. 2017-04-28 06:56:21 morning climbers 2017-04-28 06:56:26 almost weekend! 2017-04-28 06:59:38 \o/ 2017-04-28 07:40:48 jirutka, can you look at openjdk on arm? 2017-04-28 11:21:10 clandmeter: sorry, not now, no time 2017-04-28 12:44:58 hi 2017-04-28 12:52:19 hi 2017-04-28 13:10:44 clandmeter: oh crap, gcj started segfaulting on armhf? that’s not good 2017-04-28 13:39:06 yello 2017-04-28 13:43:41 jirutka, hi there. regarding https://github.com/alpinelinux/aports/pull/1318, should I disable the broken test on all platform? 2017-04-28 13:44:04 yell/w 74 2017-04-28 13:44:06 whoops. 2017-04-28 13:44:37 leitao: what’s wrong with that test? 2017-04-28 13:51:12 jirutka, I am not smart enough to understand. 2017-04-28 13:51:33 http://build.alpinelinux.org/buildlogs/build-3-6-ppc64le/main/mosh/mosh-1.3.0-r3.log 2017-04-28 13:51:47 fcolista might know better 2017-04-28 13:52:28 hm, me neither 2017-04-28 13:52:49 well, let’s disable it for all arches, until someone figure out what’s wrong 2017-04-28 14:02:16 good morning 2017-04-28 14:02:41 TemptorSent: i was thinking something like sha1sum output yes 2017-04-28 14:04:54 sha1 :( 2017-04-28 14:05:41 https://github.com/mobile-shell/mosh/blob/master/src/tests/unicode-later-combining.test 2017-04-28 14:05:47 # XXX This test is fragile because it depends on tmux's unicode rendering. 2017-04-28 14:05:49 # The baseline and variant tests produce different (but valid) outputs 2017-04-28 14:05:51 # that are visually identical. The variant test is not run or validated. 2017-04-28 14:06:09 jirutka, updated the PR? Do you mind merging it? 2017-04-28 14:06:09 Shiz: sha1 is what the embedded file hashes in apks are 2017-04-28 14:06:28 leitao: please update the PR with details provided by Shiz 2017-04-28 14:06:58 afk 2017-04-28 14:07:34 leitao: done 2017-04-28 14:08:21 ncopa, fabled: i think we need to cut apk-tools-2.7.1 release because of the solver bug 2017-04-28 14:08:34 kaniini, you foudn a fix? 2017-04-28 14:08:37 yes 2017-04-28 14:08:43 2.7.0-r5 has the fix 2017-04-28 14:08:45 git log 2017-04-28 14:09:15 checking 2017-04-28 14:10:22 problem was we would result in states like {old: nameA, new: nameB} and only a remove would be synthesized 2017-04-28 14:11:01 wehn we needed a remove and an add 2017-04-28 14:12:33 ah, ok 2017-04-28 14:12:35 good 2017-04-28 14:12:40 would be good to get test case for that too 2017-04-28 14:13:33 i guess i could just tag a new version now 2017-04-28 14:13:38 there's one more commit coming up though 2017-04-28 14:13:55 not sure 2017-04-28 14:14:03 how to work it into testsuite 2017-04-28 14:14:15 but i can give you the files i used to generate a reproducer 2017-04-28 14:14:17 :) 2017-04-28 14:14:33 if you can, i can do the test suite update 2017-04-28 14:14:38 please email them 2017-04-28 14:15:15 fabled: http://turtle.dereferenced.org/~kaniini/reproducer.tgz 2017-04-28 14:15:39 good job kaniini <3 2017-04-28 14:16:17 i'm glad we tracked it down before 3.6 release 2017-04-28 14:16:34 yeah 2017-04-28 14:16:38 good work 2017-04-28 14:16:41 we can thank spender for killing grsec off at this time which exposed the bug :P 2017-04-28 14:16:54 ok, the other patch was pushed to apk-tools.git too 2017-04-28 14:17:00 ACTION wonders what the GCC compiler plugins business is like 2017-04-28 14:17:07 xentec: I'm not sure what that was in reference to? 2017-04-28 14:17:36 CTARGET <-> CTARGET_ARCH 2017-04-28 14:18:02 e.g. armhf is armv6 2017-04-28 14:19:51 kaniini, so.. the trigger is to have state with 'a' installed, and then swap repository to provide only b and do upgrade? 2017-04-28 14:19:58 fabled: yes 2017-04-28 14:20:06 fabled: b provides a 2017-04-28 14:20:14 ok, i'll do test case it for it, thx 2017-04-28 14:20:22 fabled: literally same as what happened when i did the -grsec rename to -hardened 2017-04-28 14:20:23 i'll tag a release after that 2017-04-28 14:25:20 great 2017-04-28 14:29:02 kaniini: Actually having modules with deps helps too :) 2017-04-28 14:32:31 xentec: Ahh, thank you. Any idea where the original definition is? gcc spec file? 2017-04-28 14:33:11 afaik this pretty much is the original definition 2017-04-28 14:34:05 how can I pass flags to gcc via APKBUILD? e.g. if I want to compile a binary with "-pg" flags 2017-04-28 14:34:11 is CFLAGS ? 2017-04-28 14:34:45 I mean the triples... arm*-*-*-*eabi and armv6*-*-*-*eabihf ...etc 2017-04-28 14:35:31 yeah, they're part of gcc spec 2017-04-28 14:36:04 Okay, that's what I figured. At some point, extracting the machine defs would be useful. 2017-04-28 14:36:22 'gcc -dumpmachine' ? 2017-04-28 14:37:01 Yeah, but arm is tricky IIRC, because it supports multiple instruction sets. 2017-04-28 14:37:41 I'm going even going to get into THUMB mode :P 2017-04-28 14:38:21 Looking at feasiblity of supporting smaller arm chips. 2017-04-28 14:40:32 kaniini: FWIW, we should consider compressing the kernel modules on installation (or packaging time) -- They go from ~279MB to 74MB in installed size. 2017-04-28 14:46:39 kaniini, test cased pushed 2017-04-28 15:09:45 TemptorSent, then you might want to decompress them before building modloop 2017-04-28 15:10:11 xentec: Yes, exactly -- I had a debat with Z 2017-04-28 15:10:17 Shiz about the need for that. 2017-04-28 15:12:02 The only problem is it takes quite a while to do on the host machine, but we could probably spawn that off and complete in the background. 2017-04-28 15:13:52 When we build the dep tree, we want to use the checksums of the uncompressed modules, but if we're installing them on the host, we want to install them compressed to save significant storage. Even the initramfs modules should probably be compressed inside the cpio archive, as that saves ram for a little time. 2017-04-28 17:13:58 TemptorSent: i'm not sure busybox module tools support compressed modules 2017-04-28 23:18:08 andypost: are you here? 2017-04-28 23:23:50 omfg! of course I was right when I didn’t want to introduce two php7 pkgs, one in testing and the other one in community! tracked dependencies are totally messed 2017-04-28 23:43:09 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c 2017-04-28 23:43:15 they reverted it now 2017-04-28 23:45:12 duncaen: why i don’t see it in GH mirror? 2017-04-28 23:46:13 no idea how long it takes to sync 2017-04-28 23:46:24 kk 2017-04-28 23:46:32 but there are 4 cvs revs for this fix, something went wrong 2017-04-28 23:46:43 ? 2017-04-28 23:47:28 ah 2017-04-28 23:47:32 actually, naming the other php7 differently would not help at all, just cause less confusion, b/c tracked deps does not implicitly contain pkgname 2017-04-28 23:47:39 just one accidential without a commit message 2017-04-28 23:48:02 the other ones are for the 6.1 branch and one for -current 2017-04-29 02:42:46 kaniini: we need to do kernel bumps for 3.3 and 3.2 as they are still affected by a bad CVE and are still supported 2017-04-29 15:07:09 tot 2017-04-29 15:07:23 ncopa: ping 2017-04-29 15:07:37 Shiz: pong 2017-04-29 15:22:04 hey all, I heard that alpine is planning on maintaining a grsecurity fork since it's going private. I'm starting a distro independent project to 1. upstream as much of the grsec features as possible and 2. maintain a patchset of these features that haven't made it to upstream. (https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project) 2017-04-29 15:23:27 I welcome any contributions/comments from the alpine folks 2017-04-29 15:51:39 nmatt how does that differ from KSPP? 2017-04-29 16:04:38 IIUC, HKP is about bringing grsec/pax features to the kernel. KSPP is about hardening kernel, not necessarily by merging grsec/pax features, but indeed it was mostly the case (often w/ different implementation, IIRC), so far if I'm not mistaken. so difference seems subtle so far. Kees Cook is already mentioned on HKP page as KSPP/Upstream Liaison 2017-04-29 16:05:18 s/so far// overloaded 2017-04-29 16:05:39 afaics, HKP intends to work with KSPP to port grsec/pax features, and maintain its own patchset where that is unfeasible or not done yet 2017-04-29 16:05:45 correct me if I'm wrong, nmatt 2017-04-29 16:30:09 When I tried bumping unbound to 1.6.2, I am surprised that it failed to build. 2017-04-29 16:45:20 andypost: are you here? I need help :) 2017-04-29 16:45:38 pickfire: time to fix build issues :P 2017-04-29 16:46:52 Shiz: I don't like those. 2017-04-29 16:46:57 I just hope it works. 2017-04-29 16:47:07 Ill do it let me take a look 2017-04-29 16:47:20 arch3y_: Nice. 2017-04-29 16:47:33 pickfire: welcome to real world 2017-04-29 16:47:46 pickfire: you thought that it’s as easy as just editing single line in apkbuild…? 2017-04-29 16:48:21 hey now 2017-04-29 16:48:22 it never is 2017-04-29 16:48:27 there's also running # abuild checksum 2017-04-29 16:48:29 tahts pkgbuilding for you 2017-04-29 16:48:36 and you may need to reset the pkgrel 2017-04-29 16:48:42 jirutka: Yes! 2017-04-29 16:48:48 Not even editing. 2017-04-29 16:48:51 Just abump. 2017-04-29 16:48:58 so many return ones bleh 2017-04-29 16:49:03 got to fix all of that first 2017-04-29 16:49:16 Shiz: Need not to run abuild checksum. 2017-04-29 16:49:26 pickfire: we wouldn’t need any contributors for that, don’t you think? 2017-04-29 16:49:29 well, with abump you don't 2017-04-29 16:49:32 Just abump unbound-1.6.2 2017-04-29 16:49:36 with manual editing you do 2017-04-29 16:49:39 ACTION doesn't use abump 2017-04-29 16:49:47 I do some manual editing sometimes. 2017-04-29 16:50:02 Just remove the _builddir old stufff. 2017-04-29 16:50:35 Im sure its more love then that 2017-04-29 16:56:09 It's always good to put eyeballs on the actual file contents and make sure everything is sane. abump just makes bad APKBUILDS build newer broken packages :) 2017-04-29 16:56:59 (See the kernel modules mess from a couple days back with empty depends="" ) 2017-04-29 16:57:32 I still have no idea how that managed to be missed for YEARS without horribly bricking things. 2017-04-29 16:58:02 i can tell you but i'm not sure you'd like the answer 2017-04-29 16:58:21 Dumb luck? 2017-04-29 16:58:33 <^7heo> lamd duck 2017-04-29 16:58:45 <^7heo> s/md/mb/ 2017-04-29 16:58:48 more in the vein of 'most people dont have terrible internet that interrupts kernel+module upgrade transactions' 2017-04-29 16:58:51 so yes, to a degree dumb luck 2017-04-29 16:59:27 the build issues seem to be related to flex issues pulling a fix in now 2017-04-29 16:59:56 It was worse that that though, the only reason it would upgrade properly is by pure chance that all the packages in the repo were the same version at more or less the same time. 2017-04-29 17:00:30 So it would also happen any time the repo was in the process of syncing too. 2017-04-29 17:02:26 Yet more weight to the kernel packaging needing to be changed to reflect the kernel release in the package name. 2017-04-29 17:02:30 TemptorSent: as I said, I’ve bricked one of my production server b/c of broken kernel just few weeks ago… fortunately I usually do snapshot of the system volume before upgrading 2017-04-29 17:03:22 jirutka: Yeah, I'm guessing it was happening sporadically, but non-obvious in its cause until I looked at it and kaniini pushed fixes. 2017-04-29 17:03:55 The whole -grsec -> -hardened change brought out corner cases left and right. 2017-04-29 17:04:05 I think I hit every one of them too :) 2017-04-29 17:04:20 TemptorSent: also kernel configs are currently in horrible state, it’s not modularized, so I’d be quite surprised if two kernel variants have the same flags that should be the same 2017-04-29 17:04:40 Oh, when I am bumping poppler and poppler-qt4, I found that poppler doesn't install dependencies since texlive required the old libpoppler, how do I solve this without removing texlive to bump poppler-qt4? 2017-04-29 17:04:57 jirutka: The problem was they didn't depend on the kernel even! Not to mention a version string... 2017-04-29 17:05:38 So apk add zfs-hardened would happily just pull in the lastest -hardened modules for whatever the kernel version happens to be in the repo. 2017-04-29 17:05:57 current issue with unbound and flex https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1223 since the maintainers of flex has not released flex 2.6.4 the issue still exists 2017-04-29 17:06:01 And no kernel :) 2017-04-29 17:06:31 musl1.1.16-r8nuevaedgemainTimo Teräs2017-04-29 16:43:11 2017-04-29 17:06:32 What? 2017-04-29 17:06:40 jirutka: I've got most of a solution I think, but I could use some help with the packaging portion. 2017-04-29 17:06:42 TemptorSent: that’s why apk/abuild should imo support ==, not just > and >=, to specify exact dependency version, not just range 2017-04-29 17:06:53 jirutka: Agreed. 2017-04-29 17:06:57 There's a new version of musl called nueva 2017-04-29 17:07:10 TemptorSent: so kernel modules can depend on exact kernel version, not just some random or greater than 2017-04-29 17:07:21 Looks like someone spam us, the message is asdasdd 2017-04-29 17:07:27 jirutka: I've basically worked around all the apk bugs in my build system now I think, so we could use that to GENERATE the kernel packages. 2017-04-29 17:08:12 jirutka: Yeah, actually the modules should depend on the exact version magic string. 2017-04-29 17:08:16 TemptorSent: I’d perfer to fix/improve apk then workaround it… we’re not debian to workaround all the crap instead of solving underlaying problems ;) 2017-04-29 17:08:55 jirutka : Yes, but the kernel still has a special place in hell because we need to maintain multiple versions at the same time. 2017-04-29 17:09:16 TemptorSent: actually, this is not special for kernel 2017-04-29 17:09:32 TemptorSent: for example, to upgrade PostgreSQL, you need both old and new version simultaneously… 2017-04-29 17:09:36 Since I stage everything by kernel release, I can build atomically. 2017-04-29 17:10:21 TemptorSent: this can be workarounded by adding major.minor suffix to pkgname, but… 2017-04-29 17:10:24 jirutka: Right, full multislotting would be nice, but that's a major overhaul to apk. 2017-04-29 17:10:32 TemptorSent: I know 2017-04-29 17:11:00 TemptorSent: currently it’s probably not worth it 2017-04-29 17:11:25 i would like slotting, but yeah it's hard 2017-04-29 17:11:39 together with some kind of alternatives system ;p 2017-04-29 17:11:47 TemptorSent: but once we get rid of FHS, it’d be much easier to have multiple versions of same pkg in the system, and so it’d be maybe worth to add this support to apk 2017-04-29 17:11:54 For now, things like pgsql with major.minor is fine. With the kernel, the semantics are a lot uglier because we have not just version, we have flavor/custom 2017-04-29 17:12:05 Shiz: alternative system is MUST have, we already needed it badly 2017-04-29 17:12:21 jirutka: Agreed, FHS is the underlying problem that makes it hard to do right. 2017-04-29 17:12:22 although i never liked the term 'alternative' 2017-04-29 17:12:24 Shiz: but lack of people and time… :/ 2017-04-29 17:12:31 Shiz: me neither 2017-04-29 17:12:59 I sorta have that at image build time, and it could be adapted to system use I think. 2017-04-29 17:13:05 anyway, I’d like to fix that damn php and then get some rest for today 2017-04-29 17:13:27 Such as you can choose which ntp provider, which ssh provider, etc. 2017-04-29 17:13:48 we already kind of do that 2017-04-29 17:13:51 And it builds configureation for and activates the specified one in the overlay. 2017-04-29 17:13:55 APKBUILDs can provide= a virtual 2017-04-29 17:14:00 it's more of a file basis 2017-04-29 17:14:40 Yeah, we can probably work a combination of that for deps, and what I'm working on for scripts to make selecting providers doable. 2017-04-29 17:15:26 With 'features' being the term I'm currently using. 2017-04-29 17:16:31 such as 'feature ntp provider=chrony' in a config file. 2017-04-29 17:17:21 So once the FHS mess is gone, parallel features can work with little or no pain. 2017-04-29 17:18:06 Just have apk build a providers manifest and pick the one you want :)_ 2017-04-29 17:18:48 That should allow solving the UI problem at the same time. 2017-04-29 17:21:49 devs how do you handle libtool issues like https://gist.github.com/archey/dfe871871f9ac571d0223d53adb7acd9 2017-04-29 17:22:05 ignore them 2017-04-29 17:22:12 umm ko 2017-04-29 17:22:18 since right after it's already ran 2017-04-29 17:22:20 as from your log 2017-04-29 17:22:22 :P 2017-04-29 17:22:30 mostly it's irrelevant afaik 2017-04-29 17:22:35 k then Ill push the fix for unbound to upgrade to 16.2 2017-04-29 17:26:29 I guess I need to sleep soon, it's so late now. 2017-04-29 17:26:49 But still libreoffice haven't finished building for like an hour. 2017-04-29 17:29:58 k pr pushed 2017-04-29 17:31:42 see pickfire that took about five mins to fxi lol 2017-04-29 17:31:51 sometimes the bad builds can be simple to resolved 2017-04-29 17:32:53 jirutka: BTW, speaking of pgsql, do you know off hand who's doing the work there? 2017-04-29 17:33:07 TemptorSent: yes 2017-04-29 17:34:14 jirutka: It looks like some work is needed to clean it up, which I might attack if it's not already in the works. 2017-04-29 17:34:34 TemptorSent: what exactly? 2017-04-29 17:34:35 Mostly in terms of deps IIRC, as well as extensions. 2017-04-29 17:35:10 TemptorSent: interesting, I haven’t recognized any problem with deps and extensions 2017-04-29 17:35:11 I was working on the postgis stuff and hit some oddities. 2017-04-29 17:35:29 postgis is a quite different beast 2017-04-29 17:35:31 python I think was one. 2017-04-29 17:36:17 oh crap, why the heck postgresql-python3 does not declare dependency on python3 2017-04-29 17:36:18 Yeah, I know - but the postgres packaging may need a couple tweaks to make extensions saner. 2017-04-29 17:36:29 Yeah, that kind of stuff :) 2017-04-29 17:36:36 s/postgresql-python3/postgresql-plpython3/ 2017-04-29 17:36:46 I’ve probably overlooked that 2017-04-29 17:36:56 Like I said, I hit the corner cases ;) 2017-04-29 17:37:06 actually 2017-04-29 17:37:08 this is not a corner case, but simple bug :) 2017-04-29 17:37:10 most python packages don't have a dep on python3 2017-04-29 17:37:14 i thought that was policy 2017-04-29 17:37:26 Shiz: py3-* pkgs? 2017-04-29 17:37:34 yeah 2017-04-29 17:37:35 Breaks building things because python3 never gets installed! 2017-04-29 17:37:55 no, it’s not policy 2017-04-29 17:38:07 So when I was trying to get the postgis stuff working, it failed on python. 2017-04-29 17:38:18 okay, I’ll add that to my todo list and look at it soon 2017-04-29 17:38:19 PostGIS is a bigger mess yet. 2017-04-29 17:38:47 No worries, just wanted to know if it something I needed to look into :) 2017-04-29 17:39:41 When I get back to poking at PostGIS, I'll see if anything else turns up sideways. 2017-04-29 17:40:35 The gdal stuff is where it gets really ugly, and I'm not sure what to do about packaging because of all the proprietary crap. 2017-04-29 17:41:19 it’s weird that python2 is autodetected via dynamic links and python3 is not 2017-04-29 17:41:21 MrSID, JP2000, ECW, etc. 2017-04-29 17:41:52 Probably and artifact of the py2/3 split somehow. 2017-04-29 17:42:24 That's a whole mess in and of itself too :/ 2017-04-29 17:42:26 don’t think so, postgresql-plpython3 contains plpython3.so, that lib should depend on python3 lib 2017-04-29 17:43:03 my build box is broken lol 2017-04-29 17:43:05 [168216.126675] hrtimer: interrupt took 316183800 ns 2017-04-29 17:43:07 Hmm, does the dep show with search? 2017-04-29 17:43:07 [171445.337551] make[1053]: unhandled level 0 translation fault (11) at 0x00000048, esr 0x92000004 2017-04-29 17:43:09 randomly 2017-04-29 17:43:32 Well THAT'S not good Shiz. Bad instruction? 2017-04-29 17:43:42 no, it just randomly happens 2017-04-29 17:43:50 Memory okay? 2017-04-29 17:43:57 who knows... 2017-04-29 17:44:00 Core temps? 2017-04-29 17:44:10 You DON'T run ECC? 2017-04-29 17:44:25 it's ARM 2017-04-29 17:44:26 what ECC lol 2017-04-29 17:44:30 Ahh. 2017-04-29 17:44:57 Hmm, Don't some of the ARMs support ECC these days too? 2017-04-29 17:45:25 probably not this one 2017-04-29 17:45:33 and translation faults shouldn't be related to bad memory 2017-04-29 17:45:40 except if the bad memory somehow corrupts the paging table 2017-04-29 17:45:49 Anyway, check the physical variables -- I've seen that sort of behavior most often from overheating or poor contacts. 2017-04-29 17:46:12 Yeah, my memory controller on my i7 cooked and started doing that. 2017-04-29 17:46:33 Every time it was under load, it would start corrupting pages. 2017-04-29 17:47:23 Any dmesg entries? 2017-04-29 17:49:04 just that 2017-04-29 17:49:35 What chip/board? 2017-04-29 17:49:55 I'll check for a HW errata. 2017-04-29 17:50:14 thunderx t88 2017-04-29 17:50:18 none exist that i know of 2017-04-29 17:50:59 Ahh, pass 1 or pass 2? 2017-04-29 17:51:21 2 2017-04-29 17:52:29 Check google, looks like some stuff required to differentiate the two versions, don't know if it's mainline. 2017-04-29 17:53:30 There is an erata -- 'Cavium erratum 27456' 2017-04-29 17:54:06 i know it's pass 2 :P 2017-04-29 17:54:23 yeah, just no public errata 2017-04-29 17:56:51 Google "CAVIUM_ERRATUM_27456" 2017-04-29 17:57:13 Broadcast TLBi instruction may cause the icache to become invalid 2017-04-29 17:57:42 Check your .config :) 2017-04-29 17:59:53 It's less than a dozen lines each in the cpu_errata.c and proc.S files. 2017-04-29 18:00:40 What does that mean? 2017-04-29 18:00:40 ERROR: unsatisfiable constraints: 2017-04-29 18:00:40 x265-2.3-r0: 2017-04-29 18:00:40 breaks: x265-dev-2.4-r0[x265=2.4-r0] 2017-04-29 18:00:41 satisfies: world[x265] ffmpeg-libs-3.2.4-r1[so:libx265.so.110] 2017-04-29 18:00:59 arch3y_: How do you fix it? 2017-04-29 18:01:06 Erratum looks like a good possibility for a match to your error. 2017-04-29 18:01:19 TemptorSent: Huh? 2017-04-29 18:01:39 That's re Shiz: above :) 2017-04-29 18:01:39 arch3y_: Can I see how do you fix it? 2017-04-29 18:01:59 He doesn't like me highlighting him every line. 2017-04-29 18:02:12 Ah 2017-04-29 18:02:12 TemptorSent: neat, thanks 2017-04-29 18:02:43 NP, tracking down HW bugs is something I have too much practice with ;) 2017-04-29 18:02:49 arch3y_: Just bump me the link, need to sleep. 2017-04-29 18:04:22 yeah it has all the errata 2017-04-29 18:04:24 enabled 2017-04-29 18:04:58 Manufactures hate me -- I triggered a couple major bugs that led to a popular PLC not properly reading the first contact closure and proceedign to ignore the press of a stop button! 2017-04-29 18:05:28 Hmm, up your kernel debug level and see if you can track it down a bit. 2017-04-29 18:05:58 Might have to drag out the debugger. 2017-04-29 18:06:28 Should I just do git send-email -2? 2017-04-29 18:06:46 Do you have a logic probe that can keep up with the address lines? 2017-04-29 18:07:01 ? 2017-04-29 18:07:26 Sorry pickfire, ^^ RE: Shiz again. 2017-04-29 18:07:27 ACTION is sending it 2017-04-29 18:07:30 Okay. 2017-04-29 18:07:49 pickfire: https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0 2017-04-29 18:08:45 Shiz: If you can find a reproducer, punt it back to the HW manufacture to fix and distribute. 2017-04-29 18:08:48 arch3y_: https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0#diff-15f5d130ed00181fc2da878844f5cd3cR31 2017-04-29 18:08:53 Where do you even search that? 2017-04-29 18:09:04 By the way, what is --enable-pie? 2017-04-29 18:09:13 And --enable-relro-now 2017-04-29 18:09:25 pickfire: pie is a position independent executable 2017-04-29 18:09:25 it enables position-independent code and read-only bind-fast relocations 2017-04-29 18:09:27 hardening features 2017-04-29 18:09:31 yes 2017-04-29 18:09:36 thanks for answering faster lol 2017-04-29 18:09:36 Do we not need || return 1? 2017-04-29 18:09:41 not anymore 2017-04-29 18:09:42 no we dont 2017-04-29 18:09:47 and Im so gald 2017-04-29 18:09:49 in edge, apkbuilds are set -e by default 2017-04-29 18:09:49 err glad 2017-04-29 18:09:52 Nice 2017-04-29 18:09:54 so they exit on error automatically 2017-04-29 18:10:00 I doesn't know about that. 2017-04-29 18:10:17 I thought need to wait for 3.6 2017-04-29 18:10:31 all pkgs are built on edge as I understand it 2017-04-29 18:10:32 Although you may still want to use them for semantic clarity where you're checking conditions or failing. 2017-04-29 18:10:44 arch3y_: no 2017-04-29 18:10:46 I will not be using them 2017-04-29 18:11:05 packages are built for edge on edge, and for stable branches separately 2017-04-29 18:11:12 those are the 3.x-stable branches of the aports git repo 2017-04-29 18:11:14 makese sense 2017-04-29 18:11:16 yep yep 2017-04-29 18:11:16 arch3y_: https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0#diff-15f5d130ed00181fc2da878844f5cd3cR63 2017-04-29 18:11:25 Why do you even do a line that is so long? 2017-04-29 18:11:39 It's beginning to look like PKGBUILD 2017-04-29 18:11:39 arch3y_ as in '[ -e "$file" ] || return 1', as opposed to just '[ -e "$file" ]' 2017-04-29 18:11:54 becuase it is a pkgbuild lol 2017-04-29 18:12:01 APKBUILD* 2017-04-29 18:12:06 pickfire: you mean the sha512sums? 2017-04-29 18:12:11 those are generated by abuild checksum 2017-04-29 18:12:19 Shiz: No, I mean the column is over 100 2017-04-29 18:12:22 that's just how long sha512sums, can't really break them up 2017-04-29 18:12:24 https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0#diff-15f5d130ed00181fc2da878844f5cd3cR63 2017-04-29 18:12:28 oh i was looking at the wrong line 2017-04-29 18:12:34 Not sha512sum 2017-04-29 18:12:37 and personally I dont like all of the \ lines it just looks weird to me 2017-04-29 18:12:45 yeah some linebreaks would help probably 2017-04-29 18:12:55 but if thats style changes you guys want then Ill comply or stop comitting lool 2017-04-29 18:13:06 lool 2017-04-29 18:13:07 how would the line breaks help 2017-04-29 18:13:31 So basically just `export LEX=:` 2017-04-29 18:13:31 I tend to let the editor/pager do the line-breaking and try to lay it out so it's clear broken or not (less -S) 2017-04-29 18:13:42 yep 2017-04-29 18:13:43 arch3y_: It helps to read. 2017-04-29 18:13:48 well I have eyes 2017-04-29 18:13:50 Doesn't hurt my eyes. 2017-04-29 18:13:51 so I use them to read 2017-04-29 18:13:58 arch3y_: Use them wisely. 2017-04-29 18:14:03 well we are of differing opinions the \ hurt my eyes 2017-04-29 18:14:04 I do 2017-04-29 18:14:23 Then that just look like arch's PKGBUILD. 2017-04-29 18:14:29 exactly 2017-04-29 18:14:34 They have like over 100 for each line. 2017-04-29 18:14:39 these are basically pkgbuilds with a fiw differences 2017-04-29 18:14:43 I can't stand having line breaks at 80 cols -- I develop on the console and have 240 columns. 2017-04-29 18:15:08 look if guys dont like it dont accept the commit and we can move on 2017-04-29 18:15:09 Mine have like 87. 2017-04-29 18:15:26 pickfire Use something that does sane line-wrapping :) 2017-04-29 18:15:42 Also, leave spaces between long lines so the wrap is distinct from the line below. 2017-04-29 18:15:44 Well, I just don't like it. Not saying not to accept the commit. The commit itself is nice. 2017-04-29 18:16:04 style is definetly a personal choice for sure 2017-04-29 18:16:08 TemptorSent: Yeah. 2017-04-29 18:16:18 arch3y_: Maybe because I use neovim here? 2017-04-29 18:16:20 pickfire: You should consider tuning your tools to your needs rather than the code. 2017-04-29 18:16:51 I dont know I use straight up vim with very little options 2017-04-29 18:16:55 I'm on standard vim. 2017-04-29 18:17:03 Same. 2017-04-29 18:17:03 No options, nothing fancy. 2017-04-29 18:17:12 but yes Im used to building pkgbuilds so my commits will look like pkgbuilds 2017-04-29 18:17:15 I do some options, just like some color change. 2017-04-29 18:17:23 but to me its clean and it builds nicely so what does it matter 2017-04-29 18:17:25 Or sometimes I use kak, rarely vis 2017-04-29 18:17:29 They don't do wrap. 2017-04-29 18:17:30 just my opinion though 2017-04-29 18:17:51 Yeah, I get sick of copying settings between accounts and machines, so I'm pretty much used to the stock config. 2017-04-29 18:17:59 Ah 2017-04-29 18:18:01 me too 2017-04-29 18:18:10 TemptorSent: Don't store dotfiles? 2017-04-29 18:18:45 Nope, I log in to machines all over the place with no common anything. 2017-04-29 18:18:57 Wow, 2017-04-29 18:19:40 I sometimes use vim without config, the blue is just too dark here since my brightness is low and st have dark blue. 2017-04-29 18:19:59 st - simple terminal 2017-04-29 18:20:07 You think that's bad, wait 'till you log into an older solaris box and try to remember how to not break it with their weird vi oddities. 2017-04-29 18:20:30 I'd fix the color definition in st then! 2017-04-29 18:20:49 Ah 2017-04-29 18:20:58 Use the right layer of abstraction ;) 2017-04-29 18:21:04 :) 2017-04-29 18:21:05 By 2017-04-29 18:21:07 e 2017-04-29 18:21:53 Because that way, you fix it EVERYWHERE the blue is too dark to read. 2017-04-29 18:24:29 In fact, it looks like you can use an iterm2 color scheme and convert it with st... 2017-04-29 18:26:29 pickfire: See http://st.suckless.org/migrating 2017-04-29 18:28:44 <^7heo> well you can setup a highlight group in vi 2017-04-29 18:28:52 <^7heo> with a regex 2017-04-29 18:28:59 <^7heo> works in any terminal 2017-04-29 18:29:12 jirutka: ^7heo: do we have a check() policy for prohibitively long unit tests? 2017-04-29 18:29:24 i'm looking at grpc's testing infra and their complete tests take an hour to complete 2017-04-29 18:29:29 <^7heo> noch niht 2017-04-29 18:29:32 <^7heo> nicht 2017-04-29 18:29:32 WAITING: ETA 2848.9 sec; 3477 queued, 1 jobs running, 158 complete, 0 failed 2017-04-29 18:29:36 <^7heo> wow 2017-04-29 18:29:43 ^7heo: Yeah, the issue at hand is that when logging into different boxes at random, keeping vim highlighting in sync is a pita. 2017-04-29 18:29:43 <^7heo> yeah that's long 2017-04-29 18:30:05 Shiz: check() is intended for integration tests, no unit tests; it doesn’t make much sense to run unit tests in pkgs 2017-04-29 18:30:19 right 2017-04-29 18:30:21 <^7heo> TemptorSent: nah it's fine as long as you do it from the vimre 2017-04-29 18:30:25 <^7heo> rc even 2017-04-29 18:30:27 jirutka: it's more that it's all the same for grpc 2017-04-29 18:30:29 :P 2017-04-29 18:30:38 Shiz: hm, typical fucked up tests… 2017-04-29 18:30:40 <^7heo> and AFTER you load the colorscheme 2017-04-29 18:30:42 And that having colors too dark to read on your terminal isn't too useful, so fix the terminal color scheme first. 2017-04-29 18:30:50 <^7heo> yeah 2017-04-29 18:30:51 jirutka: i'll try to see if interop tests between C and C++ suffices 2017-04-29 18:30:52 Shiz: so no options to run just a subset? 2017-04-29 18:31:36 ^7heo: I tend to log into boxes that have no common files or are freshly built more often than not, so I've just gotten used to the vim defaults. 2017-04-29 18:33:51 <^7heo> In a company that was popping up new boxes every other hour, I actually configured ssh to send a command before connecting; so to probe for a file or setup my home 2017-04-29 18:34:15 <^7heo> that was a bit hackish but handy 2017-04-29 18:34:36 <^7heo> ofc the best is to have the ops team adding your files therw 2017-04-29 18:34:39 <^7heo> there 2017-04-29 18:34:40 >>> grpc: Entering fakeroot... 2017-04-29 18:34:42 Running interop servers is only supported with --use_docker option enabled. 2017-04-29 18:34:44 fucking grpc 2017-04-29 18:35:34 it’s Google’s project, so… 2017-04-29 18:35:44 don’t expect any good habits ;) 2017-04-29 19:25:27 <^7heo> guys 2017-04-29 19:25:35 <^7heo> I updated my Alpine 2017-04-29 19:25:40 <^7heo> it won't boot 2017-04-29 19:25:54 <^7heo> it's stuck into a dhcp loop 2017-04-29 19:26:19 <^7heo> and won't boot until I deactivate all my interfaces from the BIOS 2017-04-29 19:26:23 wut 2017-04-29 19:26:30 <^7heo> yep 2017-04-29 19:30:48 <^7heo> So yeah 2017-04-29 19:31:58 <^7heo> quite annoying 2017-04-29 19:32:34 <^7heo> I mean, as long as I can deliver a DHCP answer to the dhcpd it's fine 2017-04-29 19:33:50 <^7heo> but if I do not, it's stuck in a loop of dhcp requests 2017-04-29 19:35:55 Question - Is anyone aware of any libs ending in anything other than .a .so or .so.* that need to be dep-tracked? 2017-04-29 19:37:24 .rlib 2017-04-29 19:37:53 Got it, thanks. 2017-04-29 19:38:26 That's the extension right, no following version? 2017-04-29 19:38:44 afaik, yes 2017-04-29 19:39:36 tag of 'librust:' okay? 2017-04-29 19:40:15 (others currently being tagged ast 'libso:' and 'liba:') 2017-04-29 19:41:58 And do we have any binary deps that aren't either the target of the shebang or the output of objdump -p | grep NEEDED? 2017-04-29 19:44:03 'libso' seems somewhat... double 2017-04-29 19:44:05 :P 2017-04-29 19:45:18 Yes, but for a tag it's much clearer than just so:, and makes it easy to grab all libs by just greping for lib.*: 2017-04-29 19:45:56 TemptorSent: but we already use tag “so:” 2017-04-29 19:46:02 TemptorSent: what are you doing? 2017-04-29 19:46:05 I'm trying to determine how much of lddtree I really need, because it seems a bit messy. 2017-04-29 19:46:43 jirutka: Creating an index of files vs. checksums, then building the deptree of checksums for each lib, then buildning the complete deptree. 2017-04-29 19:47:09 abuild (https://github.com/alpinelinux/abuild/blob/master/abuild.in) already contain code for tracking deps 2017-04-29 19:47:13 jirutka: Which I can then dep the binaries against and have their full deptree. 2017-04-29 19:47:32 I think that this part is worth separating out of abuild and reimplementing in Lua or C 2017-04-29 19:47:51 it’s quite complex for shell script and currently quite slow, b/c shell… 2017-04-29 19:48:22 I actually got it up to reasonable speed and minimal complexity in shell.. 2017-04-29 19:48:23 so you may start with this :) 2017-04-29 19:49:05 but pls stop reinventing wheels, apk/abuild already define tags like so: 2017-04-29 19:50:36 jirutka: Hmm, looking at it I don't think what I have works quite the same way... 2017-04-29 19:50:53 TemptorSent: you’re looking at it for the first time now?! 2017-04-29 19:52:03 jirutka: I hadn't stumbled across that particular file while looking at my deps -- everything else is using lddtree that I encountered in mkinitfs 2017-04-29 19:52:39 Also, I think mine is potentially MUCH faster 2017-04-29 19:52:50 please, get familiar with that we already have *before* reimplementing it… 2017-04-29 19:53:34 jirutka: I've been trying to -- lack of documentation is somewhat problematic, because I have no idea what's implemented where. 2017-04-29 19:53:54 yes, lack of documentation is a problem 2017-04-29 19:54:13 but if you’ve created at least one apkbuild, then you should now that there’s some sort of deps tracking ;) 2017-04-29 19:54:20 jirutka: What I'm doing in my implementation is building the manifest and index, the resolving on that. 2017-04-29 19:55:06 as i said, the current impl. in abuild is complex and slow, so if your is better, it’s worth separting it into a standalone module/script and using it even from abuild 2017-04-29 19:55:10 Yeah, I didn't realized it was pulled out in abuild in that manner -- I thought there was some apk magick involved in the resolution. 2017-04-29 19:56:04 Yeah, that's where I'm heading with it.. If we can get proper manifest support in apk, it can be downright fast with a bit of c for tooling. 2017-04-29 19:57:19 I run it as multiple phases, first manifest, then index, then index-deps, then tree-deps, then extract subset by simple grep -f 2017-04-29 19:58:40 Hmm, .c32 is a nosys lib right? 2017-04-29 20:00:02 what do you mean by nosys 2017-04-29 20:00:05 abuild.in is 2358 lines... yeah, that might be why I didn't find it on first glance. 2017-04-29 20:00:29 Raw libs with no crt or system libs linked. 2017-04-29 20:00:36 grub/syslinux 2017-04-29 20:00:45 What's a proper name for them? 2017-04-29 20:00:50 TemptorSent: yes, it’s awfully long and quite big part of it is deps tracking and related code 2017-04-29 20:01:27 jirutka: At least the libs/bin deps I have in a few hundred lines, including extracting subsets. 2017-04-29 20:01:56 few hundred?! 2017-04-29 20:02:16 jirutka: Yeah, I think so... 2017-04-29 20:02:40 I have some convenience functions that help knock that down. 2017-04-29 20:03:46 Multipass parsing makes it much more tractable, as I had a bloody mess before when I was trying to use lddtree-like semantics. 2017-04-29 20:04:12 i mean few hundreds is not small amount… 2017-04-29 20:04:16 A couple short awk scripts do most of the ulgy work. 2017-04-29 20:05:21 <^7heo> So, I boot my machine, it starts the initramfs-grsec with some files (is the initramfs-grsec the whole image that gets loaded in ram?) 2017-04-29 20:05:46 <^7heo> and then it starts my kernel with the openrc init. 2017-04-29 20:06:11 <^7heo> I guess the openrc is what starts my network; so where should I look to find the scripts that actually do that? 2017-04-29 20:06:15 It's not perfect, but it seems to work pretty well, is reasonably fast, and the complexity is limited. 2017-04-29 20:06:48 It handles link tracking, package tracking, etc. 2017-04-29 20:07:51 ^7heo /etc/init.d/networking IIRC 2017-04-29 20:08:33 ^7heo ifup 2017-04-29 20:09:10 ^7heo: /etc/init.d/networking (you can symlink it to net.), reads /etc/network/interfaces, uses busybox ifup or something like that 2017-04-29 20:10:23 jirutka: Looks like ~500 lines for the whole thing, including subsetting. 2017-04-29 20:11:08 <^7heo> jirutka: thanks 2017-04-29 20:11:20 ^7heo: yw 2017-04-29 20:12:26 jirutka: And that generates the manifest, the lib and bin index, the lib and bin deptrees, and the subsets of each. 2017-04-29 20:13:33 jirutka: The kernel modules I have tracked similarly, with full sanity checking -- I'm working on integrating everthing common into one tool then using that for both functions. 2017-04-29 20:14:15 Basically, given an index and an unresolved list of deps for each entry, it will generate a resolved complete deptree for each entry. 2017-04-29 20:15:43 Figuring out exactly how we want the semantics to work is about all that's left. 2017-04-29 20:16:13 Doing pkgconfig should be a few dozen lines more. 2017-04-29 20:16:41 Essentially, if we can generate a list of deps for a given file, it solves the rest. 2017-04-29 20:17:23 Anyway, I need to get running errands, so I'm out for the day. 2017-04-29 20:18:36 (line count includes comments/blanks, not sloc) 2017-04-29 20:43:02 <^7heo> Wait, openrc is distributing scripts? 2017-04-29 20:43:10 <^7heo> We're not using the alpine scripts? 2017-04-29 20:43:35 ? 2017-04-29 20:43:45 the initscripts are a combination of alpine and openrc scripts 2017-04-29 20:44:02 networking is alpine iirc 2017-04-29 20:44:11 <^7heo> https://github.com/OpenRC/openrc/blob/master/init.d/network.in 2017-04-29 20:44:20 <^7heo> looks like it's OpenRC's to me. 2017-04-29 20:44:33 doesn't look like that to me 2017-04-29 20:44:34 <^7heo> oh wait 2017-04-29 20:44:35 <^7heo> networking.initd 2017-04-29 20:44:37 <^7heo> I see. 2017-04-29 20:44:46 <^7heo> I didn't see networking in there, sorry. 2017-04-29 20:54:35 ^7heo: actually I’d prefer OpenRC network scripts (called netifrc), they are more flexible than this debian-like thing 2017-04-29 20:55:10 netifrc isn't part of openrc, it's a separate thing 2017-04-29 20:55:11 <^7heo> I dunno; I really have to look in what's wrong with mine. 2017-04-29 20:55:18 <^7heo> because if it's a bug affecting other people... 2017-04-29 20:57:57 <^7heo> It's not guaranteed that most users would know how to de-activate their ethernet interface... 2017-04-29 20:58:08 <^7heo> let alone it being possible. 2017-04-29 21:01:45 anyone here that can shed some light on how the go/ghc bootstrapping works? 2017-04-29 21:01:49 im looking at whats needed for rust 2017-04-29 21:09:31 ncopa: leitao: can you take a look at this PR please https://github.com/alpinelinux/aports/pull/1336 ? 2017-04-29 21:14:10 rdutra, sounds good for me 2017-04-29 21:29:46 Shiz: I’m afraid that fabled (and maybe ncopa) is the only one who know it… :/ 2017-04-29 21:37:28 Shiz, it is a cross-build. basically scripts/bootstrap.sh builds the initial compiler 2017-04-29 21:37:41 yeah, i get as much 2017-04-29 21:37:53 i'm just confused how go-bootstrap relies on go and go relies on go-bootstrap 2017-04-29 21:37:55 :P 2017-04-29 21:37:58 oh 2017-04-29 21:38:02 that's legacy on Go part 2017-04-29 21:38:04 the reason is 2017-04-29 21:38:21 for x86_64, we bootstrap Go using go-bootstrap package. it can be built with gcc present only 2017-04-29 21:38:27 it's old Go 2017-04-29 21:38:35 one of those that did not require Go to build Go 2017-04-29 21:38:39 ah right 2017-04-29 21:38:43 for pretty much all other architectures 2017-04-29 21:38:53 it's bootstrap.sh cross-building go package 2017-04-29 21:38:58 now because there's two flavors 2017-04-29 21:39:05 go makedepends on go-bootstrap 2017-04-29 21:39:09 but also provides it 2017-04-29 21:39:21 fabled: Shiz: maybe ghc-bootstrap is more closer example? 2017-04-29 21:39:26 yes 2017-04-29 21:39:33 so the situation for rust is 2017-04-29 21:39:38 ghc for x86_64 was bootstrapped from non-alpine host 2017-04-29 21:39:42 right 2017-04-29 21:39:45 and manually installed to edge builders 2017-04-29 21:39:48 yeah that's similar to what we 'want' rust to do 2017-04-29 21:39:55 other architectures were cross-built 2017-04-29 21:40:15 fabled: could you please exmplain how exactly it work? how is this -bootstrap pkg build (as all other or somehow specially?), how cross-compilation is handled etc. 2017-04-29 21:40:31 -bootstrap package exist only for go 2017-04-29 21:40:36 and ghc 2017-04-29 21:40:39 ghc-bootstrap 2017-04-29 21:40:54 that's historical then, it's not used 2017-04-29 21:41:00 omfg 2017-04-29 21:41:05 :P 2017-04-29 21:41:10 why we have historical bloat in repository that is actually not used? 2017-04-29 21:41:20 so ghc-bootstrap can be removed? 2017-04-29 21:41:22 yes 2017-04-29 21:41:31 fabled: is there any automation on how ghc is bootstrapped on a non-alpine host? 2017-04-29 21:41:33 great, at least I haven’t wasted my time with review yet 2017-04-29 21:41:33 any scripts out there etc 2017-04-29 21:41:39 or does the non-alpine host also use the APKBUILD 2017-04-29 21:41:40 i think i wanted to keep it around until we have ghc in a stable release 2017-04-29 21:41:40 so how exactly is it bootstrapped? 2017-04-29 21:42:00 i think ghc bootstrap was basically 2017-04-29 21:42:11 - make docker image that builds initial build that can target musl/alpine 2017-04-29 21:42:15 - export tarball 2017-04-29 21:42:26 right, but is that automated anywhere? 2017-04-29 21:42:27 - apkbuild just rewraps tarball to apk 2017-04-29 21:42:29 I wanted to move ghc into community already, but I thought that ghc-boostrap must be moved with that and it’s quite huge and messy, so I postponed review 2017-04-29 21:42:30 or was that just someone's manual work 2017-04-29 21:42:32 :P 2017-04-29 21:42:34 that's what ghc-bootstrap did 2017-04-29 21:43:02 or does (though arch="" now; so it's effectively disabled) 2017-04-29 21:43:11 yes and how is it bootstrapped now, if ghc-bootstrap is not used at all? 2017-04-29 21:43:24 it's not 2017-04-29 21:43:28 not? 2017-04-29 21:43:29 it's self-dependent like gcc 2017-04-29 21:43:30 https://git.alpinelinux.org/cgit/aports/tree/testing/ghc-bootstrap/APKBUILD 2017-04-29 21:43:32 ah yes i see now 2017-04-29 21:43:43 for new architectures it's bootstrapped via bootstrap.sh cross-compiling it 2017-04-29 21:43:44 so you need existing alpine pkg to build next one? 2017-04-29 21:43:47 yes 2017-04-29 21:43:49 aha 2017-04-29 21:43:58 someone told me that this is exactly what we don’t want in Alpine 2017-04-29 21:43:59 same as with all compilers that are written in the same language 2017-04-29 21:44:02 so it’s not true? 2017-04-29 21:44:07 we can't avoid it 2017-04-29 21:44:19 then we don’t need rust-bootstrap at all… 2017-04-29 21:44:23 no 2017-04-29 21:44:37 we may need to do same with java in future 2017-04-29 21:44:42 gcc is dropping gcj 2017-04-29 21:44:45 currently we use prebuilt binary from VoidLinux for bootstrapping and we already have our Alpine binary now, so we can use it to build another rusts 2017-04-29 21:44:50 :) 2017-04-29 21:44:55 we do need a rust-bootstrap package 2017-04-29 21:45:01 so it can be provided by rust and makedepended on 2017-04-29 21:45:04 for the sake of the cross build 2017-04-29 21:45:14 not necessarily 2017-04-29 21:45:19 why? it’s not needed for ghc… 2017-04-29 21:45:20 well i mean 2017-04-29 21:45:21 we need it in name 2017-04-29 21:45:23 i'm ok if we just hand build first rust 2017-04-29 21:45:24 jirutka: it is though 2017-04-29 21:45:31 jirutka: https://git.alpinelinux.org/cgit/aports/tree/testing/ghc/APKBUILD#n23 2017-04-29 21:45:31 inject it to builder, and then push the apkbuild 2017-04-29 21:45:38 that sounds hacky.... 2017-04-29 21:45:46 other/new architectures can be then just cross-built 2017-04-29 21:45:54 not really 2017-04-29 21:45:57 Shiz: I guess that this is yet another unused legacy noise… isn’t it? 2017-04-29 21:45:58 that's how it's done 2017-04-29 21:46:05 jirutka: i don't think it is 2017-04-29 21:46:18 as I understand it, first the actual ghc-bootstrap package was used to get a working package 2017-04-29 21:46:26 but in newer cycles the ghc package provides ghc-bootstrap 2017-04-29 21:46:29 (see provides= in the ghc package) 2017-04-29 21:46:34 yes, the makedepends/provides of ghc-bootstrap is legacy now 2017-04-29 21:46:35 since the build host does need ghc 2017-04-29 21:46:41 we could drop provides, and makedepends=ghc 2017-04-29 21:46:57 right 2017-04-29 21:48:03 fabled: please, please, can you document at least briefly this stuff? we’ve already wasted some time trying to figure out how to do that based on ghc-bootstrap etc. 2017-04-29 21:48:14 you have irc-log now :) 2017-04-29 21:48:19 but yeah 2017-04-29 21:48:21 fabled: there’s not even stupid one line comment in ghc-bootstrap explaining that it’s not used 2017-04-29 21:48:28 fabled: no, irc log is not a documentation 2017-04-29 21:48:36 fabled: no one will find it in future 2017-04-29 21:49:40 well 2017-04-29 21:49:48 so right now we can move rust to community, then (?) remove dependency on binaries from Void and add rust to makedepends, right? 2017-04-29 21:49:50 the thing is that not often we get language that depend on themselves 2017-04-29 21:50:30 well, but cross-compiling is not so uncommon and this is also totally undocumented…? 2017-04-29 21:50:32 also there's a gotcha on moving from testing -> community 2017-04-29 21:50:40 since community can't depend on testing 2017-04-29 21:50:59 I know, that’s why I suggested to first move it, build with prebuilt binaries from Void and then drop them 2017-04-29 21:51:04 yes 2017-04-29 21:51:08 if that works now 2017-04-29 21:51:09 then it's good 2017-04-29 21:51:13 yes it works 2017-04-29 21:51:14 i'm ok doing that 2017-04-29 21:51:25 okay, I’m gonna do it right now :) 2017-04-29 21:51:28 and then open a whine XD 2017-04-29 21:51:35 i think we should keep ghc-bootstrap until ghc is in community 2017-04-29 21:51:35 wine 2017-04-29 21:52:11 i'm hoping we can support cross-building better in future, and document it 2017-04-29 21:52:23 so far it's been implemented only to the extent of bootstrapping new arch 2017-04-29 21:52:30 another question, how to cross-compile rust to other arches using abuild? 2017-04-29 21:52:41 use bootstrap.sh for now 2017-04-29 21:52:48 apkbuild needs to support cross-building for that 2017-04-29 21:52:51 okay, I’ll look at it 2017-04-29 21:52:59 currently we don't ship cross compilers 2017-04-29 21:53:05 another thing i hope we can change in future 2017-04-29 21:53:06 just for sure, these cross variables and other stuff in ghc abuild, are they actually used…? :) 2017-04-29 21:53:11 bootstrap.sh basically does that for you 2017-04-29 21:53:15 yes 2017-04-29 21:53:21 read bootstrap.sh 2017-04-29 21:53:35 it basically executes "CHOST= abuild foo" 2017-04-29 21:53:38 in predetermined order 2017-04-29 21:53:47 Shiz: hm, we have still disabled rust tests 2017-04-29 21:53:49 it triggers lots of stuff happen 2017-04-29 21:54:04 it sets up environment variables for cross-building 2017-04-29 21:54:12 and abuild also handle makedepends_* differently 2017-04-29 21:54:24 so, the nice thing about the rust APKBUILD is 2017-04-29 21:54:33 cross-building is a chapter of it's own. especially for gcc. 2017-04-29 21:54:33 with some teeny tiny changes you could run it on a glibc host with apk/abuild installed 2017-04-29 21:54:37 and cross-compile it :) 2017-04-29 21:54:48 (and these are actually very minor changes) 2017-04-29 21:54:49 Shiz: yes 2017-04-29 21:55:26 jirutka: want me to make these changes? 2017-04-29 21:55:41 Shiz: but since fabled said that it’s not needed and I hope that upstream will someday finally provide prebuilt binary of rustc that is actually portable or linked against musl, then I’d prefer to not waste time with that 2017-04-29 21:56:11 ok 2017-04-29 21:56:13 Shiz: could you please try to run uncomment check() in rust pkg and try to run them? 2017-04-29 21:56:19 sure 2017-04-29 21:56:51 running 2017-04-29 21:57:48 btw i found out that php is broken even more than i thought, when I try to run tests, all fails b/c of linking problem; it seems that some extensions does not work when built as shared… 2017-04-29 21:59:57 fabled: thanks for the information! we’ll look at bootstrap.sh 2017-04-29 22:00:57 thanks for your work too... i'm surprised how many new self-hosting compilers there are around 2017-04-29 22:01:07 too many 2017-04-29 22:01:08 :( 2017-04-29 22:01:10 yeah 2017-04-29 22:01:22 and it's sad that in some cases they have no idea how to make it bootstrappable 2017-04-29 22:01:40 even rust's package manager needs to be bootstrapped 2017-04-29 22:01:43 it uses itself to build itself 2017-04-29 22:01:45 :/ 2017-04-29 22:01:56 fabled: yes; and you don’t wanna know how many issues in rust build system Shiz fixed to make it even work :( 2017-04-29 22:02:19 i looked that we do carry a bunch of patches... indicating someone banged their head a lot on it 2017-04-29 22:02:22 so kudos 2017-04-29 22:08:29 btw: does $CARCH reflect builder or target? 2017-04-29 22:12:40 target 2017-04-29 22:12:46 CHOST reflects builder 2017-04-29 22:13:01 erf 2017-04-29 22:13:09 no 2017-04-29 22:13:13 CHOST reflects target 2017-04-29 22:13:19 CBUILD reflects builder 2017-04-29 22:14:03 may need to do a small edit to the rust apkbuild then 2017-04-29 22:14:14 i need to get the builder arch 2017-04-30 00:02:37 kaniini: fwiw im working on fwd-patching 4.1.20 2017-04-30 00:14:35 Shiz: how does it look with rust tests? 2017-04-30 00:15:37 ha, i finally get these f*cking php tests working! 2017-04-30 00:19:27 jirutka: test result: FAILED. 2238 passed; 369 failed; 20 ignored; 0 measured 2017-04-30 00:19:29 thanks for reminding me 2017-04-30 00:19:44 Shiz: does not look good :/ 2017-04-30 00:20:08 Shiz: and these are not all tests, b/c it halts suite after first error 2017-04-30 00:20:21 most failures seem to be related to fatal runtime error: failed to initiate panic, error 5 2017-04-30 00:20:35 weird, we have fixed panic… 2017-04-30 00:22:12 i’d be good to run at least some high-level tests 2017-04-30 00:22:19 we can ignore unit tests and so 2017-04-30 01:26:19 TemptorSent: I have never seen iterm2 color scheme. 2017-04-30 01:36:16 compiling... 2017-04-30 02:52:04 after some more fixes, 4.1.39 done 2017-04-30 04:25:39 can i hand-off a file for someone to upload on dev.a.o for APKBUILD usage? 2017-04-30 06:18:02 Shiz, still need it? 2017-04-30 06:18:15 yea 2017-04-30 06:49:30 Now that I have a phoneline and network again, just pushed changes to my work that includes updated dep resolver... 2017-04-30 06:55:58 Do we have any COM32 *libraries* that don't fit the glob 'lib*.c32'? 2017-04-30 06:58:21 the .c32 files in /boot aren't com32 2017-04-30 06:58:54 Really? That's what they apper to be referred to by Syslinux? 2017-04-30 06:59:16 yeah, just by tradition 2017-04-30 06:59:26 they're regular ELF shared objects 2017-04-30 06:59:29 (32-bit, but still) 2017-04-30 06:59:42 they were COM32 objects in the DOSLinux days 2017-04-30 06:59:49 Brilliant -- the error message is actually THAT wrong? 'Failed to load COM32 file menu.c32' -- brilliant! 2017-04-30 07:00:38 Okay, what should they be called? (My net crapped out just after last time I asked and has been out all day) 2017-04-30 07:01:49 Should they just be 'libc32:'? 2017-04-30 07:01:59 https://github.com/geneC/syslinux/blob/master/mk/elf.mk#L108 2017-04-30 07:02:01 :P 2017-04-30 07:02:11 so: is fine imo 2017-04-30 07:02:55 if you're looking for why it's called com32, a bit of legacy: http://www.syslinux.org/doc/comboot.txt 2017-04-30 07:02:59 (that doesnt apply anymore) 2017-04-30 07:03:23 Yeah, I remember using it back in the old days and booting from dos :) 2017-04-30 07:04:59 I'm trying to keep things semantically separated as much as possible so we can determine not just the file format, but the semantic type. 2017-04-30 07:06:27 Executables I have tagged with 'script:' for those with a shebang, and 'bin:' for anything that objdump recognizes that isn't a lib. 2017-04-30 07:09:26 The corner case there is non-executable binaries -- do we need to worry about deps there? 2017-04-30 07:10:34 Hmm, also scripts lacking shebangs aren't handled at the moment, but I suppose could be by a check for known extensions. 2017-04-30 07:12:05 Do compiled perl/python libs have any odd extensions to consider? go? etc? 2017-04-30 07:16:35 ncopa: Can you please allow me to take maintainership of testing/s-nail? 2017-04-30 07:17:09 I don't like the way currently it is built, no IMAP and SSL built in T_T 2017-04-30 07:18:54 hi 2017-04-30 07:19:10 hi kaniini 2017-04-30 07:19:40 kaniini: hi 2017-04-30 07:29:46 kaniini: How's the heater installation going? 2017-04-30 07:40:19 pickfire, its in testing right? if so you can just send pr/patch and claim it. 2017-04-30 07:51:21 clandmeter: I was the one who sent the patch at first but then someone else modified it and put to master. 2017-04-30 07:51:42 master? 2017-04-30 07:51:43 I think it is my fault for sending too many packages at once. 2017-04-30 07:51:47 clandmeter: testing. 2017-04-30 07:51:53 I meant the master branch. 2017-04-30 07:51:55 thats fine 2017-04-30 07:52:05 just make your changes and send a new pr/patch 2017-04-30 07:52:10 I can just claim it and modify the packages? 2017-04-30 07:52:14 yes 2017-04-30 07:52:18 Nice! 2017-04-30 07:52:31 and if it works correctly we can move it to community 2017-04-30 08:00:05 Grr... Back, anyway - hi kaniini, how's the new server coming? 2017-04-30 13:37:12 Regarding https://bugs.alpinelinux.org/issues/6635 there has been an upstream commit: https://github.com/openbsd/src/commit/edb2eeb7da8494998d0073f8aaeb8478cee5e00b 2017-04-30 13:39:30 how to test this and/or get it included in Alpine? 2017-04-30 13:42:26 this is entirely wrong 2017-04-30 13:43:09 the blocking behaviour is the very POINT of getrandom() 2017-04-30 13:43:32 without it, getrandom() is useless, because /dev/urandom accomplishes the same thing 2017-04-30 13:44:34 the long delay is unavoidable if you want a cryptographically secure system 2017-04-30 13:45:22 it's a feature, and the correct way to reduce the delay is to have more entropy sources in the machine 2017-04-30 13:45:34 <_ikke_> https://www.2uo.de/myths-about-urandom/ 2017-04-30 13:45:56 I know that page, and this has nothing to do with what I'm talking about 2017-04-30 13:47:12 getrandom() is basically /dev/urandom *except that* it blocks as long as the entropy pool hasn't been initialized 2017-04-30 13:47:22 i.e. it will block for some time at boot time, and then will never block again 2017-04-30 13:47:38 where "some time" appears to be infinite on my machine... 2017-04-30 13:47:42 and the initialization of the entropy pool is *necessary* 2017-04-30 13:48:00 then your machine doesn't have an entropy generator 2017-04-30 13:48:06 and that's what should be fixed 2017-04-30 13:48:37 if it's a VM, plug the entropy to the host's entropy - ISTR there's an option in the kernel to do that 2017-04-30 13:48:47 quite possible... but it's headless, on a pretty quiet local network, only handles SMTP and SSH, so not mucht traffic... where will entropy come from? 2017-04-30 13:49:09 that's a good question 2017-04-30 13:49:52 I don't have a good answer to that, but if you pull random data before the pool has been initialized, you'll get predictable seeds 2017-04-30 13:50:12 which is the case with /dev/urandom and exactly what getrandom() is supposed to fix 2017-04-30 13:50:49 you'd think OpenBSD, with their obsession with security, would understand that, but since it's Linux, they won't even put in the effort 2017-04-30 13:51:08 so basically what their patch is doing is demoting getrandom() to /dev/urandom 2017-04-30 13:51:12 hmm, well, the current behaviour (ssh never comes up after reboot) means that I don't reboot... and consequently I don't apply security updates. That's not great either... 2017-04-30 13:52:35 I have no good answer, but I know that OpenBSD's "fix" is not a fix, it's a regression 2017-04-30 13:53:24 how about keeping random seed across reboots? would that help? 2017-04-30 13:53:50 certainly 2017-04-30 13:54:34 I'm not sure to what extent (dunno if writing enough data to /dev/urandom can fill up the entropy pool entirely, or if it's still waiting for data from other sources) 2017-04-30 13:54:40 but it can't hurt 2017-04-30 13:55:54 I seem to recall doing this a decade ago (on Red Hat linux, before Fedora/Core) but have forgotten the details entirely. 2017-04-30 13:58:02 g2g now, but Alpine should already have a mechanism to do that - if it's not the case, it's time to add one. 2017-04-30 13:59:16 <_ikke_> http://www.issihosts.com/haveged/ ? 2017-04-30 14:00:40 there are some others like that btw: 2017-04-30 14:00:50 https://www.kernel.org/doc/ols/2014/ols2014-mueller.pdf 2017-04-30 14:00:58 https://www.kernel.org/doc/ols/2014/ols2014-harris.pdf 2017-04-30 14:06:40 <^7heo> omg... https://www.enlightenment.org/docs-efl-start#Dependencies 2017-04-30 14:07:48 <^7heo> 45 deps... 2017-04-30 14:08:15 <^7heo> 43 even. 2017-04-30 14:09:37 <^7heo> including bullet, vlc, openssl... 2017-04-30 14:10:23 <^7heo> for those who don't know, enlightenment is a window manager, and bullet a physics engine. 2017-04-30 14:10:26 <^7heo> (for games) 2017-04-30 14:11:04 <^7heo> Wtf really. 2017-04-30 14:11:14 <^7heo> Now I understand why enlightenment isn't in the repos. 2017-04-30 14:15:47 enlightenment has a ui framework and apps as well afaik 2017-04-30 14:16:45 <^7heo> yeah 2017-04-30 14:16:48 <^7heo> it's gigantic. 2017-04-30 14:16:58 <^7heo> last time I checked it out was in 2004 or so 2017-04-30 14:17:02 <^7heo> maybe 2005 2017-04-30 14:17:16 <^7heo> it wasn't that bloated at the time. 2017-04-30 16:59:52 Hello all. What is the chance of getting a package change done before the new release? I'm refering to issue #6964 (https://bugs.alpinelinux.org/issues/6964) where the extended DAV module is needed for full WebDAV support in nginx 2017-04-30 17:19:16 I don't mean to keep pestering about this issue, but is anyone considering implementing this? It would be tremendously useful for me: https://bugs.alpinelinux.org/issues/5011 2017-04-30 17:19:52 (Make GCC able to compile exe binaries) 2017-04-30 17:21:09 https://up.shiz.me/MTllNmZi.png 2017-04-30 17:21:12 thanks, scaleway.... 2017-04-30 17:21:50 <_ikke_> Shiz: ? 2017-04-30 17:22:07 i requested a reboot 37 mins ago because the server wasn't responding to anything 2017-04-30 17:22:09 it sitll hasn't happened 2017-04-30 17:22:25 the ponies got out of the stable again 2017-04-30 17:22:32 they are having to wrangle them back up 2017-04-30 17:22:44 ha ha get it 2017-04-30 17:22:50 because their IP transit business is poney telecom 2017-04-30 17:25:10 XDD 2017-04-30 17:25:26 Kruge: doens't winegcc work? 2017-04-30 17:28:44 Shiz: I've not had any success, but I'm largely flailing around. If fcolista hasn't managed to get it to compile, I'm fairly sure I won't be able to 2017-04-30 17:29:47 Kruge: immediately we're mainly trying to get 3.6 out the door, but it does seem like a worthwhile feature 2017-04-30 17:30:30 i wonder if something like crossdev for alpine would be a more useful general solution 2017-04-30 17:31:04 kaniini: I'd make my life significantly better, and I'm sure my company would happily sponsor this feature if that was of any use 2017-04-30 17:31:17 Shiz: killer idea: cross-compilation to midipix from alpine ;) 2017-04-30 17:31:23 :p 2017-04-30 17:31:24 But I understand what you mean about 3.6 2017-04-30 17:31:44 ACTION starts a crossdev version for alpine and calls it crossdress 2017-04-30 17:31:51 Kruge: mentioning that on the bug item might be helpful 2017-04-30 17:33:14 kaniini: just realised that this may even be handy in bootstrapping alpine... 2017-04-30 17:33:16 hmmmmmmmm 2017-04-30 17:33:51 not really helpful there -- we want to use the bootstrap.sh so that we bootstrap using official APKBUILDs 2017-04-30 17:33:59 kaniini: How is the pipeline for adding features to packages? In my case issue #6964 2017-04-30 17:34:06 Mr_H: frozen 2017-04-30 17:34:10 kaniini: well, this system would integrate with abuild 2017-04-30 17:34:12 :) 2017-04-30 17:34:38 Shiz: i mean that we want the cross compiler to have the same patches that we normally apply 2017-04-30 17:34:48 yeah 2017-04-30 17:34:53 still doesn't change anything ;P 2017-04-30 17:35:49 kaniini: How quick may such package appear in the repo after being changed? 2017-04-30 17:36:11 if you're using edge, almost immediately 2017-04-30 17:36:50 I'm using the alpine docker image, I think thats based on stable? 2017-04-30 17:37:19 you can change it to be based on edge 2017-04-30 17:37:21 FROM alpine:edge 2017-04-30 17:37:24 instead of :latest 2017-04-30 17:47:14 Mr_H: okay, I’ll try to add this module to nginx pkg, if it works with 1.12 2017-04-30 17:48:36 jirutka: Thank you very much! :) 2017-04-30 17:48:56 and thanks Shiz for the edge tip :) 2017-04-30 17:52:25 jirutka: is there any thing I can do to help? I'm very new to Alpine Linux, but love the mindset 2017-04-30 17:52:49 Mr_H: just reminding it to me :) 2017-04-30 17:54:21 jirutka: Hehe, I'll remind the hell out of you if you're not more specific on when you think you're able to do it :'D 2017-04-30 17:58:52 Is there any good articles on how to build packages? If I want to try modifying an APKBUILD file and test changes myself? 2017-04-30 18:00:44 https://wiki.alpinelinux.org/wiki/Setting_up_the_build_environment_on_HDD 2017-04-30 18:00:46 :) 2017-04-30 18:01:06 actually, https://wiki.alpinelinux.org/wiki/Include:Setup_your_system_and_account_for_building_packages 2017-04-30 18:01:11 more accurate for an existing environment 2017-04-30 18:01:32 thank you Shiz! 2017-04-30 19:24:11 scaleway box still down lol 2017-04-30 19:25:03 <_ikke_> ugh 2017-04-30 19:25:17 <_ikke_> annoying 2017-04-30 19:30:21 do we still use scaleway for build servers? 2017-04-30 20:10:32 scadu: we moved i think 2017-04-30 20:34:45 before I create a bug for it, is it intended behavior to create a 512kB sda2 (swap) if performing an installation with SWAP_SIZE=0? I would have expected sda2 to become the sysroot in that scenario... 2017-04-30 20:34:59 fwiw this "fix" results in a working system with just sda1 and sda2: https://pastebin.com/V3APdVEk 2017-04-30 20:59:24 it seems that floats in php are seriously fucked up… many test fails b/c of different precision 2017-04-30 20:59:39 but not surprised… 2017-04-30 23:30:47 TemptorSent: to answer your question, i am awaiting HDDs 2017-04-30 23:40:46 kaniini: Ahh, gotcha - what's installed storage capacity going to be? 2017-04-30 23:41:59 8x2tb raidz1 2017-04-30 23:42:01 probably 2017-04-30 23:43:30 kaniini: At that point, why not raidz2 and eliminate the chance of failure during rebuild wiping out the array? 2017-04-30 23:44:01 That's a fair chunk of data to regenerate... 2017-04-30 23:44:23 i might 2017-04-30 23:44:59 TemptorSent: i am also awaiting enough of a fuck to drag it upstairs to where the other gear is 2017-04-30 23:45:15 the machine weighs 100 lbs 2017-04-30 23:45:27 kaniini: That's what the red-light district is for? ;) 2017-04-30 23:45:34 Yeah, that's a chunk of iron! 2017-04-30 23:45:45 kaniini: can i give you a file to throw on distfiles? 2017-04-30 23:45:58 Shiz: i'm not 100% sure how to do that these days :/ 2017-04-30 23:46:08 lol rip 2017-04-30 23:46:13 im still here :) 2017-04-30 23:46:23 dont tell anybody though 2017-04-30 23:46:31 guys 2017-04-30 23:46:34 clandmeter is here 2017-04-30 23:46:37 oh 2017-04-30 23:46:39 heyo 2017-04-30 23:46:41 in that case: https://up.shiz.me/priv/linux-4.1.y-rpi-20170501.patch 2017-04-30 23:46:43 :) 2017-04-30 23:47:49 pls check 2017-04-30 23:48:24 yup its there 2017-04-30 23:48:26 thanks 2017-04-30 23:51:38 kaniini: can you check if my kernel upgrade patch for 3.3 makes sense? 2017-04-30 23:51:41 not sure if i covered all bases 2017-04-30 23:52:39 http://immunity.shiz.me/0001-main-linux-upgrade-to-4.1.39-and-fix-CVE-2016-10229.patch 2017-04-30 23:55:30 oh i need to bump the versions in testing/ too 2017-04-30 23:56:35 there, patch updated