07:25 melezhik_ joined
melezhik_ [Coke]: those are modules that failed 07:25
librasteve: let's see, bit busy right now )) thanks for the offer 07:26
ok - brownie 2025.10 finished, this is diff between 2025.11-2025.10 - brw.sparrowhub.io/report/brw-reporter/3152 , not many , which is probably good, Proc:Q could be ignored as it's tests are wobbly as the output says 07:27
so we have UpRooted - brw.sparrowhub.io/file_view/brw-rep...Rooted.log
LWP::Simple could also be ignored as t/get-perl6-org.t probably just hit in bad time 07:28
Cro::RPC::JSON - t/060-websocket.rakutest , probably not rakudo related 07:29
Cache::Async - t/03-expiry.rakutest
07:35 melezhik_ left, melezhik_ joined 07:37 melezhik_ left, melezhik_ joined 08:00 melezhik_ left, melezhik_ joined
melezhik_ [Coke]: ab5tract: patrick: I've added timeouts (10 minutes per zef install Foo ) as guard against long running / infinite modules, please pull the latest version, thanks 08:18
08:36 melezhik_ left 09:38 librasteve_ left 10:13 melezhik_ joined
melezhik_ failed modules ( artifacts in sorted order ) - brw.sparrowhub.io/report/brw-reporter/3209 10:18
10:30 melezhik_ left, melezhik_ joined 10:38 melezhik_ left, melezhik_ joined 10:46 melezhik_ left 12:43 melezhik_ joined 12:50 melezhik_ left, melezhik_ joined 13:12 melezhik_ left, melezhik_ joined 13:18 melezhik_ left, melezhik_ joined 13:24 melezhik_ left, melezhik_ joined 13:35 melezhik_ left 13:42 melezhik joined
melezhik [Coke]: can we test timeouts on 2025.08 ? Need to pull the latest commit 13:44
When you can, no rush 13:51
[Coke] seeing a failure on String::Koremutake http 413 14:43
melezhik: ok to update the container in place?
did /opt/brownie/agent/upgrade.sh, let me know if I need to do more 14:44
melezhik Yep 14:48
Let me check 14:49
Started 2025.08 14:50
Your agent is up and running , see itā€™s pings , it will start receiving load soon
[Coke]: can you please check if there any errors on agent ? 15:01
Suspiciously only see pings , no reports so far
Or probably itā€™s just takes some time for the first report 15:02
Letā€™s wait
PIDs remain the same and cpu time increases so looks good ) 15:04
Ok , first report had arrived - brw.sparrowhub.io/report/job.1.report/3362 15:09
[Coke] +1 15:19
melezhik Ok. 10 minutes timeout exceeded for. MUGS::UI::WebSimple. brw.sparrowhub.io/report/job.1.report/3371 15:20
Probably need to make a bit bigger
[Coke] I'd be fine with something even as high as 30 - we just want to avoid stuff like paraseq 15:30
Oof, azure bill was a little higher this month (probably due to the windows box I setup for testing) 15:45
16:02 librasteve_ joined
melezhik Oh. Sorry for that 16:52
Another thing to think about . I donā€™t get why some modules successfully pass tests in one Rakudo and the same modules fail to pass tests on another - I doubt itā€™s Rakudo impact , reports do not show any reason either . Example - brw.sparrowhub.io/file_view/brw-rep...::Fuzz.log 16:54
[Test::Fuzz] Parse errors: Subtest 12 expected 97 but contains 81 tests
But why this happens in 2025.10 but does not in 2025.08 ? 16:55
Or this is just a module test itself flaky , unpredictable, wobbly ?
Set timeout to 20 16:59
github.com/melezhik/brownie/commit...07cc7e7b54
[Coke] blin has some accomodation for flaky modules - will run it X times to avoid failing on a flapper. 17:00
(which is honestly, not something it should hide, it should be considered a soft failure)
melezhik Yeah. Same thoughts . Will see how can we handle it in brownie . Itā€™s though not a critical one , as there is still a human who validates reports from brownie and makes a final decision where this is blocker or not 17:10
Considering comparison does not have too many modules that failed this imho is bearable 17:12
Rakudo::Options has started to fail since 2025.10 - brw.sparrowhub.io/file_view/brw-rep...ptions.log 18:05
Failed test 'did we run with -Ilib (2)
[Coke] That test passes here. 18:08
(on my mac with 2025.11)
with 'zef look Rakudo::Options' then 'zef --verbose test .' 18:09
melezhik Interesting 18:11
Which version of module do you test btw ? 18:12
[Coke] ===> Testing [OK] for Rakudo::Options:ver<0.0.3>:auth<zef:lizmat>
zef look gets you the same one you'd get by doing an install with no version/api/auth info 18:13
So, not sure if it's because of how brownie is setting things up for the test.
or if it works on mac and not linux?
(didn't install deps because it doesn't have any)( 18:14
melezhik ok $ro.includes, 'did we run with -Ilib (1)';
Yeah . Worth try on Linux
Also brownies does the same . zef look && zef install ā€”deps-only . && zef ā€”verbose test . 18:15
[Coke] tried it inside the agent's container. 18:16
melezhik Yeah
[Coke] ... and zef look fails.
melezhik You need to unset ZEF_INSTALL_TO
ah, you still need to do that , but this is not relevant 18:17
[Coke] having it blank is not sufficient?
melezhik It shouldnā€™t be blank 18:18
[Coke] yah, same result.
I just did an exec bash to get in the container. env showed 'ZEF_INSTALL_TO=' - I unset it it, ran it again, same error
Looks like we're also several releases of raku behind. 18:19
18:27 melezhik_ joined
melezhik_ gist.github.com/melezhik/587c356b9...6f98940fbb 18:27
melezhik I guess zef look probably does not work as expected , I just took itā€™s output ( name of temp dir ) and cd to the dir explicitly 18:29
This is basically the same what sparrow plugin does , do not know why it does not work strut away via cli
Anyway zef ā€”verbose test . passes 18:30
Several release of Raku behind ? 18:31
18:33 melezhik_ left
melezhik www.irccloud.com/pastebin/2jvsGdca 18:33
[Coke] the container is using 2025.08, no? 18:34
melezhik The error I am talking about started in 2025.10
[Coke] docker exec -it agent raku --version 18:35
Welcome to Rakudoā„¢ Star v2025.08.
melezhik Container had some default Rakudo , but brownie uses whatever able Rakudo by setting PATH
Exactly what I did in gist
For example 18:36
export PATH=/tmp/whateverable/rakudo-moar/fe0e20c28859ea709eefad19af452c9d35dff20d/share/perl6/site/bin/:/tmp/whateverable/rakudo-moar/fe0e20c28859ea709eefad19af452c9d35dff20d/bin//:$PATH
[Coke] Yes, I understand you're not using that raku to run the tests.
melezhik But the problem is when I run the same way zef test for Rakudo::Options inside container - it passes . Wait a sec - I did it on Mac OS as well as 18:37
Need to check on Linux
My laptop battery flat right now
ā€œ9:36 PM <[Coke]> Yes, I understand you're not using that raku to run the tests.ā€ Yep . Basically if you repeat steps from gist ā€¦ on Linux agent , but your is Mac as well , right? )) 18:39
So need to check on Linux )) 18:40
18:48 melezhik_ joined
melezhik_ let me probably reconsider my initial idea, Mac OS VS Linux is not relevant, as we run inside container with Debian anyway 18:55
[Coke] my test on the mac had nothing to do with the container and used latest raku 18:58
melezhik_ ok, I mean I tested actually inside agent container which is Debian Linux and test passed 19:00
run Rakudo::Options test THE SAME way as brownie agent does and it also passes - gist.github.com/melezhik/ed8dafc72...69b4c1ea2e 19:06
which makes me think that maybe Rakudo::Options is flaky, or maybe brownie makes it flaky somehow ...
can you bash exec to your agent and run the same ? basically just `s6 --task-run .@rakudo_version=fe0e20c28859ea709eefad19af452c9d35dff20d,module=Rakudo::Options` 19:07
from /opt/brownie/agent/tasks/run-test directory
I wonder what will we get 19:08
lizmat fwiw, Rakudo::Options tests clean on my Mac with HEAD 19:11
melezhik_ Ok github.com/lizmat/Rakudo-Options/issues/1
could this somehow relate to this flaky behavior ? 19:12
dunno šŸ¤·ā€ā™‚ļø 19:13
19:15 melezhik_ left, melezhik_ joined
melezhik_ raku -MRakudo::Options -e 'say $*RAKUDO-OPTIONS' 19:15
Rakudo::Options.new(includes => [], modules => ["Rakudo::Options"], ll-exception => Empty, stagestats => Empty, n => Empty, p => Empty, e => "say \$*RAKUDO-OPTIONS", executable => "/tmp/whateverable/rakudo-moar/fe0e20c28859ea709eefad19af452c9d35dff20d/bin/rakudo", program => ("-e", "say \$*RAKUDO-OPTIONS"), profile => Empty, optimize => Empty, encoding => Empty, target => Empty)
I wonder how this passes github.com/lizmat/Rakudo-Options/b...st#L10-L11
intersting if run as `raku t/01-basic.rakutest` it fails - gist.github.com/melezhik/8d815d234...a196368929 19:18
^^ lizmat:
I guess I should have run as raku -I lib ? 19:19
or raku -I . 19:21
my guess is only that - this somehow SOMETIMES does not happen during zef --verbose test . and I dunno why 19:22
lizmat yeah, it expects to be run with -Isomething and without -Msomething 19:23
but it isn't particular about what is specified with -I 19:24
melezhik_ ok another interesting finding
I managed to reproduced that
I fails under SYSTEM, not whateverable rakudo 19:25
let me share gist
gist.github.com/melezhik/97eb2ed7d...5e372a2c6e 19:27
but this one is v2025.10 Rakudoā„¢ Star bundle 19:28
I guess somehow is different from Rakudoā„¢
lizmat that gist shows the same 2 tests failing, because apparently they're being run without -I ?? 19:35
melezhik_ the only question what is left, why it SOMETIMES also fails under whatevearble rakudo, as shown here - brw.sparrowhub.io/file_view/brw-rep...ptions.log
lizmat that shows an empty page for me 19:36
melezhik_ ` because apparently they're being run without -I ??` - probably right, but tests are run via standard zef --verbose test .
and my assumption that it should take care about -I lib / -I .
lizmat zef test --verbose . passes for me on HEAD 19:37
melezhik_ gist.github.com/melezhik/39a052d4f...9dc65587d8
you can use this link
anyways - it falls under Rakudo Start bundle, rakudo version 2025.11 19:38
here - gist.github.com/melezhik/97eb2ed7d...5e372a2c6e
so it's not a Rakudo::Options issue I guess, but zef bundled into Rakudo Start 19:39
because exactly under this zef we have an issue
19:40 melezhik_ left, melezhik_ joined
lizmat I'll make a new Rakudo::Options release without the -I test shortly, just to be on the safe side :-) 19:41
afk&
melezhik_ liz - sure, no rush 19:44
lizmat: [Coke]: - another interring finding Rakudo::Options is only reproduced on flamboyant-moore-63797432 agent (the one bug guns agent running by patrickb:) , but not on coke agent and not on my local agent 19:46
which makes me think that this is agent related issue
patrickb: could you please run following on your agent and run this `cd /opt/brownie/agent/tasks/run-test/ && s6 --task-run .@rakudo_version=fe0e20c28859ea709eefad19af452c9d35dff20d,module=Rakudo::Options` 19:48
I have some filling the issue will be reproduced ( please share the output here via Pastebin or gist )
brw.sparrowhub.io/file_view/brw-rep...ptions.log - see [agent] for failed (rakudo 2025.11) and for passed ( old - rakudo 2025.08) 19:51
the same brw.sparrowhub.io/file_view/brw-rep...ptions.log - test passed on coke bot agent ( with rakudo 2025.08) and fails on Patricks agent (flamboyant-moore-6 rakudo 2025.10) 19:52
melezhik Also if your agent has anything in bashrc and or bash profile related to Raku / zef env vars this is also will be valuable , thanks 19:58
patrickb: the last question do you run agent with - BRW_AGENT_CAP_INSTALL_FROM_SOURCE_FORCE=1 ? 20:07
If so this force to install Rakudo/zef from source for commit rather then use whatever able binary 20:08
And this may end up in different behavior with regards to automatic including -I lib or -I . 20:09
github.com/melezhik/brownie/blob/5.../run.sh#L7
This option only required if someone runs agent on none x86-64 boxes 20:10
Installing from the source logic is here - github.com/melezhik/brownie/blob/m.../task.bash 20:12
I did quick analysis of diffs between Rakudo 2025.11 vs 2025.10 and Rakudo 2025.10 vs 2025.08 , interesting many tests failures happend on flamboyant-moore-63797432 agent 20:20
And on the same modules passed on Coke bot agent
brw.sparrowhub.io/file_view/brw-rep...::Fuzz.log
As example 20:21
21:33 melezhik_ left, melezhik_ joined 21:39 melezhik_ left, melezhik_ joined
lizmat fwiw, 0.0.4 of Rakudo::Options just uploaded to fez 22:45
22:46 melezhik_ left, melezhik_ joined 22:51 melezhik left

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!