[01:01] 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? [02:04] *** MasterDuke left [04:28] *** japhb joined [05:20] *** japhb left [05:22] *** japhb joined [08:21] jnthn: the only reason is that no one dared to turn it off yet. [08:50] *** MasterDuke joined [08:52] nine: do you want to look at https://github.com/MoarVM/MoarVM/pull/1344 before i merge it? there's no particular urgency for merging, so if you want to, but can't right away, that's fine [09:02] jnthn: with github actions, do (direct) azure pipelines make sense [09:07] 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:27] 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:43] MasterDuke: for travis you need to enable the travis integration and have a travis accoun [09:43] t [09:43] for github: no setup, no (explicit) account [09:44] on travis there is also some actions that need to be done on travis and the cli, like encrypting secrets [09:59] I submitted writing a libgccjit backend for our JIT(s) as a GSOC project idea: https://github.com/perl-foundation-outreach/gsoc-2021-ideas/pull/1 [10:36] nine: one nit: s/bot JIT/both JIT/ [10:36] that would be a cool project :-) [10:42] *** MasterDuke left [10:47] *** MasterDuke joined [10:48] nine++ [10:48] El_Che: ah, forgot you had to have a travis account [11:49] 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 [12:16] huh, could be annoying for us https://www.phoronix.com/scan.php?page=news_item&px=GSoC-2021-Less-Interesting [12:23] *** raku-bridge left [12:23] *** raku-bridge joined [13:41] *** ggoebel_ left [13:41] *** ggoebel_ joined [14:09] *** MasterDuke left [14:44] This is the second time I've seen this segfault: https://gist.github.com/niner/73a60d1cc54abfa56adced5e75f260ae [14:44] Sadly it only seems to appear under heavy load and even then quite rarely [14:47] 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] https://pipelines.actions.githubusercontent.com/Y5G2ylMUHHwm4vhuL6yZLVSTiCXgYiF5OsCtCLYE4evxAvJvJg/_apis/pipelines/1/runs/186/signedlogcontent/28?urlExpires=2021-01-31T14%3A46%3A53.0393723Z&urlSigningMethod=HMACV1&urlSignature=AiQ8%2BEq5e4yaPUYE903qo7BQNmzH2fL7%2FkFBhR0oWNI%3D [15:14] *** MasterDuke joined [15:16] 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:17] El_Che: i'd say report it. if we see the same thing again and again that helps raise its priority [15:26] MasterDuke: yes, I found that curious as well [15:27] I've seen segfaults during build on OBS as well every now and then. But no information to go on [15:28] 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] El_Che: core dumps or back traces would be helpful [15:29] i think it's julia that automatically saves a rr recording of segfaults to attach to error reports. that would be awesome [15:32] I created this one: https://github.com/Raku/nqp/issues/695 [15:36] once I finish the migration I can maybe look on how to keep core files if useful [15:40] El_Che: your full log links just gives `{"count":11,"value":"Uri expired"}` [15:42] https://julialang.org/blog/2020/05/rr/ [15:43] damn [15:43] I'll put it i a gist? [15:43] or the ticket itself? [15:44] added as a comment [16:07] I guess the same advice or creating issues is for flapping tests? [16:07] got an other one :) [18:02] El_Che: any chance of obtaining a backtrace for the segfaults? [18:14] sadly, not at the moment [18:15] I include some options for core devs to run all the builds, e.g. from a specific commit [18:16] maybe adding core dumps and backtraces to the artifacts could be useful [18:16] *** raku-bridge left [18:16] now the only artefacts I keep are the sources used to build and the packages [18:17] 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 [18:20] 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:21] 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 [18:22] (but the trace idea is great!) [18:23] 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 [18:46] El_Che: you need to do a MoarVM debug build (perl Configure.pl --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:48] do I pass the same params to npq and rakudo? [18:48] I'll make it a setting option [18:49] no, just MoarVM [18:49] thx [19:40] *** MasterDuke joined [19:49] *** zakharyas joined [20:06] so the core files would be core* in the working dir? [20:07] agh, probably system dependant [20:07] cat /proc/sys/kernel/core_pattern [20:07] |/usr/share/apport/apport %p %s %c %d %P %E [20:07] on my desktop [20:09] on the other hand, I could set it but no idea it works on a container [20:29] (pretty certain it won't) [21:21] No I think its a global setting. [21:22] it is [21:22] I am inspecting if there is a workaround [21:23] (unlikely) [21:26] But the same setting can work for host and container [21:27] yeah, but in github action the setting is set to readonly [21:27] and it's a pipe to apport [21:29] Apparently that's some Ubuntu thing, geared towards desktop usage [21:29] yeah [21:29] as a ubuntu user is the first thing I remove [21:29] the GUI is a popup you get when sonmething crashes [21:30] 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 [22:49] ik zal me eens moeien: https://github.com/goreleaser/nfpm/issues/288 [22:49] :) [23:12] now that I hope that moarvm segfaults, it doesn't :) [23:15] *** MasterDuke left