Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 8 February 2016.
patrickz gotta go to sleep now. Will be back tomorrow... 00:01
01:00 sufrostico joined
ugexe patrickz: i added ZEF_BUILDPM_DEBUG=1 to output the relevant build info so i can manually emulate the Build.pm process 01:32
from the output
the only thing i can think of would be a rakudo bug somehow related to a rw class attribute not updating its value on reassignment, but thats grasping at straws 01:35
jdv79: `list` command is enabled for cpan. im using 100 results, if thats too high let me know 01:36
03:24 Kassandry joined
jdv79 ugexe: i don't see it in the zef repo 05:25
ugexe the commit message doesnt show the `zef list` part of the message because of the ` i guess. it just says "for CPAN (most recent 100)" 05:28
github.com/ugexe/zef/commit/19f21f...a0c67c7335 05:29
jdv79 oh, my mistake. thanks!
its curious that you have mirrors in the cpan code. the p5 mc has no mirror afaik. 05:37
i guess we could if we dumped the db periodically for mc6. idk how realistic that is what with user info and lag issues. 05:38
ugexe its mostly because thats the framework that was already there for p6c where i do use the mirrors. but, something like mirrors could be used for absolutifying the download_url against cpan/backpan mirrors 05:42
jdv79 right 05:43
07:03 domidumont joined 07:09 domidumont joined 07:48 FROGGS joined 09:41 leont joined 11:14 FROGGS joined 12:07 ribasushi joined 12:40 sufrostico joined 14:06 prammer joined 14:28 sufrostico joined 15:03 domidumont joined 15:36 domidumont joined 16:06 domidumont joined 17:27 prammer joined 17:37 prammer joined 18:01 Kassandry joined 18:27 leont joined 18:52 patrickz joined 19:06 FROGGS joined 19:10 domidumont joined, prammer joined 19:13 sufrostico joined
patrickz ugexe: paste.debian.net/379645/ 19:17
It seems the build silently failed. My perl was borked 19:18
I missed the -fPIC option... 19:22
jdv79 i've done that 19:25
nine I wonder if that is easily detectable 19:43
Seems like perl -MConfig -E 'say %Config{cccdlflags}' gives me "cccdlflags-fPIC". But I don't know if it always does that for a perl built with -Duseshrplib 19:44
Unfortunatly -Duseshrplib is not the only way to get a suitable libperl, as we can use a libperl.a as well. 19:46
19:52 prammer joined 19:55 leont joined 20:02 prammer joined 20:12 prammer joined
jdv79 does $Config{libperl} not cover both? 20:20
21:13 prammer joined
ugexe patrickz: ahh, glad we know. its hard to handle Build.pm because some people die, some dont return any value from the method, and some dont seem to handle their errors so the script still exits 0 even though it fails and outputs on stderr 21:28
leont wonders what the question was that jdv79 answered 21:29
21:39 prammer joined 21:42 b2gills1 joined 21:49 ribasushi joined
jdv79 leont: irclog.perlgeek.de/perl6-toolchain/...i_12019353 22:07
leont Right, there's a log :-) 22:13
ugexe hmm seems like im getting some of that run/shell giving me the wrong exitcode stuff 22:14
leont Using the configuration values for compiling it tricky, they don't always mean what you'd expect 22:15
cccdlflags will always contain whatever flags are needed on that platform for compiling object files for a shared object 22:16
(erm, if that perl is shrplib) 22:17
22:21 b2gills joined 22:23 camelia joined
ugexe seems i can get the correct exitcode by switching `$proc.out.close` to `$proc.out.close unless +@err;`, where `my @err = $proc.err.lines;` 23:12
leont Could it be a pipe buffering issue? 23:25
ugexe dunno. if i simply don't call $proc.out.close it also works. but not closing $proc.out when the process was a success has its own ramifications on exitcode 23:40
jdv79 ugexe: paste.scsys.co.uk/505240 23:48
you master branch isn't terribly stable lately i've noticed:) 23:49
i just wanted to try the list feature
oh. nm. my fault. 23:51
Skipping... (use :force to override) is kinda weird when someone doesn't know that --force is :force maybe 23:52
patrickz All of this instability stuff will be loads better once cpan lifts of because people will start doing actual *releases* of their modules with version number and all. 23:56
23:57 ranguard joined
jdv79 its a long road to that point 23:57
ugexe yeah its because the message is generated in Zef::App. if zef::app was being used without bin/zef i wouldnt want it to say --force. i do agree with you however, i just picked something to fill in until i pass exceptions back or something 23:58
what really surprises me is `zef :force -v install xxx` actually does a force install
jdv79 its not an exceptional cause though is it?
really?
ugexe yeah 23:59