|
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 20 September 2016. |
|||
|
01:48
ilbot3 joined
|
|||
| moderator | 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 | ||
|
05:22
zengargoyle joined
|
|||
| zengargoyle | is this the place for when rakudobrew / zef does something weird? | 05:23 | |
|
05:24
domidumont joined
05:29
domidumont joined
05:50
domidumont joined
|
|||
| nine | zengargoyle: here or #perl6 | 07:11 | |
| zengargoyle | gist.github.com/zengargoyle/d967d5...a09f2a9d16 | 07:48 | |
| use rakudo to build moar-blead, success, then tries to re-something zef which builds and tests and then fails to install since it's already installed before. then rakudobrew barfs. | 07:49 | ||
| nine | zengargoyle: why are you using rakudobrew? | 07:51 | |
| zengargoyle | could probably be fixed with a nuke and start from scratch... but it seems the old redo panda and reinstall modules automagic isn't quite working zef-wise. | ||
| nine: is rakudobrew deprecated or something? | |||
| nine | zengargoyle: rakudobrew is a tool for core developers who may have a reason to install and use multiple versions of rakudo with separate module repositories. It is not a tool aimed at end users. | 07:52 | |
| It is also not a tool that's really maintained. | |||
| There is no reason at all to reinstall any modules when upgrading rakudo. | |||
| zengargoyle | so is nuke and start from scratch the goto method... i am indending to work on core-ish stuff. i did before but have been away for many months. | 07:53 | |
| nine | I work quite a bite on the core, too but have never really felt a need for rakudobrew | 07:54 | |
| zengargoyle | just expected it to sorta mostly work (actually epected it to re-install everything like it did once before) | ||
| i never got to the point of doing nqp/moar/rakudo all by my lonesome. :) | 07:55 | ||
| nine | As I said, you don't have to re-install anything just because you upgraded | ||
| zengargoyle: just try it. It's a one liner :) | |||
| git clone gitgithub.com:rakudo/rakudo.git && cd rakudo && perl Configure.pl --gen-moar --make-install | 07:56 | ||
| zengargoyle | nods. just sorta like the *brew type of things to keep multiple versions to easily switch between to keep some scripts working and some breakable. | 07:57 | |
| a rakudobrew that does provide the easy switch between blead and latest-stable and older versions would be a nice thing eventually. | 08:01 | ||
| it also might just be the zef part. i haven't tried panda this time around, don't know if it has the same weirdness. | 08:02 | ||
| nine | Well we would rather just be really backwards compatible, so users don't have to switch between rakudo versions | 08:03 | |
| zengargoyle | :) | 08:04 | |
| i also find that zef will fail to install Task::Star, it will install all the dependent modules but fail the actual Test::Star part. but will say nothing to do if you try to install Task::Star again. probaby more a zef issue with bundle type modules. | 08:07 | ||
| hrm, if modules are now backwards compatable enough, maybe rakudobrew should just not try to do the panda/zef re-install, re-install all current modules thing. or maybe have smarts to know if it should re-install panda/zef/modules for some reason or another. | 08:32 | ||
|
09:00
lizmat joined
|
|||
| nine | Well, rakudobrew is hardly maintained. But if you want to step up, please just do :) | 09:06 | |
|
09:54
domidumont joined
10:00
domidumont1 joined
10:14
domidumont joined
10:33
TimToady joined
10:42
tadzik joined
11:41
domidumont joined
|
|||
| ugexe | zengargoyle: why does the test fail (run with `-v` to get test output)? Task::Star installs on my end so I cant reproduce | 14:34 | |
| `ZEF_PLUGIN_DEBUG=1 perl6 -Ilib bin/zef --debug install Task::Star > zef_output.txt 2>&1` If you give me the output from this i'll be able to figure it out. I think the test adapter it chooses for your system doesn't like a missing `t/` directory | 14:39 | ||
| stmuk | ugexe: BTW zef fails to install for me on OpenBSD at the moment | 15:26 | |
| panda even core dumps on that platform which I'm trying to golf | 15:27 | ||
| ugexe | does zef give any hint at the error? | 15:28 | |
| mst | Error: no zef for you | 15:30 | |
| stmuk | nope its core dumping too ... there are reports of panda breakage on FreeBSD as well so maybe its *BSD specific | 15:33 | |
| ugexe | do they reach the actual installation stage, or do they dump before testing? | 15:37 | |
| stmuk | I've only looked at panda in detail and its the use of --prefix=inst#foo in a module bootstrap (using the uninstalled panda) which is to blame | 15:39 | |
| I also have a gdb backtrace on moar.core | 15:40 | ||
| its the actual installation phase, building and testing are fine | 15:42 | ||
| ugexe | ah. so its in CompUnit::Repository::Installation (or the PrecompilationRepository) | 15:43 | |
| probably a lock or permissions issue | |||
| stmuk | yes maybe this line (from panda) | 15:44 | |
| github.com/tadzik/panda/blob/maste...ler.pm#L39 | 15:46 | ||
| ugexe | hmmm i would suspect #L61 | 15:52 | |
| stmuk: maybe `RAKUDO_MODULE_DEBUG=1` will give additional clues | 16:00 | ||
| stmuk | it doesn't show anything at the install point before the coredump .. I think it's L39 from putting dies in | 16:06 | |
| ugexe | weird. does `perl6 -e 'say CompUnit::RepositoryRegistry.repository-for-spec("inst#foo", :next-repo($*REPO))'` crash? | 16:09 | |
| stmuk | not when I tried it yesterday | 16:10 | |
| stmuk tries again for luck | 16:13 | ||
| nope | |||
| ugexe | heh, i was hoping it would because that would make more sense (to me anyway) | ||
| when you said `--prefix=inst#foo` do you mean you passed this to panda or that you build rakudo with it? | 16:14 | ||
| stmuk | FreeBSD behaves in the same way .. my guess is there some assumption about file system behaviour which doesn't hold with ufs/ffs | ||
| passed to panda | |||
|
16:24
domidumont joined
|
|||
| ugexe | i'll try to reproduce locally tonight | 16:47 | |
| zengargoyle: the issue with task::star tests reporting a failure should be fixed. one of the non-default/backup test adapters indeed did not play nice with a missing `t/` | 16:50 | ||
| i'm assuming you're on osx | 16:55 | ||
|
18:17
edehont joined
|
|||
| zengargoyle | ugexe: looks like it might have been my using `zef --serial install Task::Star` (which fails at the end) under the assumption that zef installs all or none and '--serial' would at least install modules that didn't fail tests. | 20:45 | |
| without '--serial' it doesn't fail at the end. and i'm on Debian so it probably wouldn't have failed in the first place w/o the '--serial' flag. | 20:50 | ||
|
21:00
hoelzro joined
|
|||
| zengargoyle | with '--serial' it ends with '===> Install [OK] for Task::Star' then an error message: '!!!> Install failures: Task::Star, <looks like all modules>'. | 21:05 | |
| i probably just mis-grokked the purpose of '--serial' :/ | 21:06 | ||
|
21:45
camelia joined
|
|||
| ugexe | zengargoyle: you understand correctly. your clarification pointed me in the right direction and its fixed now (everything was being installed correctly, it was just reporting wrong at the end) | 21:48 | |
| --serial ended up needing to flatten its array of candidates before passing it to the reporter | 21:49 | ||
| zengargoyle | yay :) | 22:08 | |