| IRC logs at
Set by AlexDaniel on 12 June 2018.
jnthn Hm, given we've the Azure pipelines set up, is there any reason we still keep Travis CI around? From what I've read, they're not (easily) granting open source build credits any more (or at least, not on a recurring basis), so maybe we should remove it? 01:01
02:04 MasterDuke left 04:28 japhb joined 05:20 japhb left 05:22 japhb joined
nine jnthn: the only reason is that no one dared to turn it off yet. 08:21
08:50 MasterDuke joined
MasterDuke nine: do you want to look at before i merge it? there's no particular urgency for merging, so if you want to, but can't right away, that's fine 08:52
El_Che jnthn: with github actions, do (direct) azure pipelines make sense 09:02
on of the ideaś for the refactoring of moving rakudo-pkg from travis to github actions is that everyone can just fork the repo and run the actions, big plus of github actions 09:07
MasterDuke El_Che: but travis/azure/etc are just configured from files in the repo, so you get them also if you fork. not sure what you mean? 09:27
El_Che MasterDuke: for travis you need to enable the travis integration and have a travis accoun 09:43
for github: no setup, no (explicit) account
on travis there is also some actions that need to be done on travis and the cli, like encrypting secrets 09:44
nine I submitted writing a libgccjit backend for our JIT(s) as a GSOC project idea: 09:59
lizmat nine: one nit: s/bot JIT/both JIT/ 10:36
that would be a cool project :-)
10:42 MasterDuke left 10:47 MasterDuke joined
MasterDuke nine++ 10:48
El_Che: ah, forgot you had to have a travis account
nine Oh... running methods on the object's perl interpreter is a good idea. But what about class methods? For those I'm gonna have to use the thread's perl interpreter anyway 11:49
MasterDuke huh, could be annoying for us 12:16
12:23 raku-bridge left, raku-bridge joined 13:41 ggoebel_ left, ggoebel_ joined 14:09 MasterDuke left
nine This is the second time I've seen this segfault: 14:44
Sadly it only seems to appear under heavy load and even then quite rarely
El_Che I am running litterally hundreds of builds the last days. Once in a while I get a segfault or flapping tests. Should I report this? Just mention it here? Shut up en rerun the job? The latest example from just now: 14:47
15:14 MasterDuke joined
MasterDuke nine: huh, that looks like sort of like the stuff i'm getting on my branch after i've added the removing of candidates 15:16
El_Che: i'd say report it. if we see the same thing again and again that helps raise its priority 15:17
nine MasterDuke: yes, I found that curious as well 15:26
I've seen segfaults during build on OBS as well every now and then. But no information to go on 15:27
MasterDuke makes we wonder if i'm just triggering something pre-existing more reliably (because with MVM_JIT_DISABLE=1 MVM_SPESH_BLOCKING=1 it is 100% reliable) 15:28
nine El_Che: core dumps or back traces would be helpful
MasterDuke i think it's julia that automatically saves a rr recording of segfaults to attach to error reports. that would be awesome 15:29
El_Che I created this one: 15:32
once I finish the migration I can maybe look on how to keep core files if useful 15:36
MasterDuke El_Che: your full log links just gives `{"count":11,"value":"Uri expired"}` 15:40 15:42
El_Che damn 15:43
I'll put it i a gist?
or the ticket itself?
added as a comment 15:44
I guess the same advice or creating issues is for flapping tests? 16:07
got an other one :)
nine El_Che: any chance of obtaining a backtrace for the segfaults? 18:02
El_Che sadly, not at the moment 18:14
I include some options for core devs to run all the builds, e.g. from a specific commit 18:15
maybe adding core dumps and backtraces to the artifacts could be useful 18:16
18:16 raku-bridge left
El_Che now the only artefacts I keep are the sources used to build and the packages 18:16
the idea is that you fork the repo, enable the included action and change the versions file to whatever you want to test 18:17
I don't know if it's user friendly enough
nine Honestly with 2 largish ongoing development efforts on Rakudo on my plate and the surprise task on Inline::Perl5 this week, trying to reproduce one of these build segfaults and obtaining a core dump feels like misspent time :/ 18:20
El_Che if you can point me to doc on how to enable the extra output, I'll gladly ask it to the build. I am not releasing packages yet 18:21
of we can do it in a few weeks
(but the trace idea is great!) 18:22
ok, t/04-nativecall/02-simple-args.t failed on debian 9 (flapper) 18:23
if someone points me on how run tests with more debugging, I can have a look
18:43 MasterDuke left
nine El_Che: you need to do a MoarVM debug build (perl --debug --optimize=0) and ensure that coredumps are created on the system you're building on. Then if a segfault occurs, you should get a core file 18:46
El_Che do I pass the same params to npq and rakudo? 18:48
I'll make it a setting option
nine no, just MoarVM 18:49
El_Che thx
19:40 MasterDuke joined 19:49 zakharyas joined
El_Che so the core files would be core* in the working dir? 20:06
agh, probably system dependant 20:07
cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %d %P %E
on my desktop
on the other hand, I could set it but no idea it works on a container 20:09
(pretty certain it won't) 20:29
nine No I think its a global setting. 21:21
El_Che it is 21:22
I am inspecting if there is a workaround
(unlikely) 21:23
nine But the same setting can work for host and container 21:26
El_Che yeah, but in github action the setting is set to readonly 21:27
and it's a pipe to apport
nine Apparently that's some Ubuntu thing, geared towards desktop usage 21:29
El_Che yeah
as a ubuntu user is the first thing I remove
the GUI is a popup you get when sonmething crashes
I am thinking on a workaround if the didn't disabled cores 21:30
let's see
21:37 patrickb joined 21:57 zakharyas left 22:46 patrickb left 22:48 sxmx joined
El_Che ik zal me eens moeien: 22:49
now that I hope that moarvm segfaults, it doesn't :) 23:12
23:15 MasterDuke left