On 08-09-2022 04:18, Daniel Sockwell wrote:
> (If this was already the case in the previous version, that's still bad,
>> but then it can be left for later, being independent of this patch.)
> Understood.  I'll put that on the to-do list for future patches (though
> pinning specific versions of MoarVM/Rakudo to specific versions of the UCD
> is important, so unbundling might mean including more up-to-date versions
> of the UCD, unless Guix already stays very current there).
If having a specific version (and not just a sufficiently recent version)
is important, you can look at the 'ucd-next' package and make a similar
package variant, except for whatever version MoarVM and Rakudo need
>> I noticed you removed the mention of the garbage collector, is this
>> intentional?
> I cut the GC from the list of features in an effort to stay within Guix's
> length guidelines for descriptions (and because having a GC doesn't do much
> to distinguish Raku from Perl/Python/nearly all Lisps/JS, etc.)  But the GC
> is very much still present :)
OK.
>> On nqp-configure: Are you sure that 'bin' should be installed in '.../bin'?
>> Looking at the Git repository, make.nqp does not have a shebang and can hence
>> not be directly run, maybe you should add a shebang?
>>
>> Also, is there appear to be some tests in 't', why aren't they run? There is a
>> 'rakudo-build-system', maybe this rakudo-build-system can properly build this
>> package
> I'll double check the above.
>
>> On nqp: why the switch from downloading the source code from the apparent official site
>> "rakudo.perl6.org" to GitHub?
> The Rakudo site no longer hosts NQP, just Rakudo.  See https://rakudo.perl6.org/downloads
>
OK.
>>> + (substitute* "t/09-moar/01-profilers.t"
>>> + (("ok.*\\$htmlpath" html-test-text)
>>> + (string-append "todo \"harness5 fails to write html profile\";"
>>> + html-test-text)))))
>> What's the issue here? Is it a limitation of the Guix packaging, or could it perhaps
>> be an upstream bug? If the latter, upstream needs to be informed such that they can
>> fix the bug.
> I'm honestly unsure.  I can't understand why it would be a Guix-specific issue, but I've
> also never had that test fail when building from source on other distros.  More investigation
> is called for.
OK, I suppose it isn't a blocker.
>> On the new package description: ... It's getting close to marketing phrases
> Thanks.  I could tell I was getting a bit close to that line and guess I let my enthusiasm
> carry me away a bit; I'll rein it in.
>
>> Can you verify that our various perl6-... libraries still build, and that when doing, say,
>> "guix shell rakudo perl6-json-name -- whatever-rakudos-binary-name-is", you can still use
>> perl6-json-name in whatever is rakudo's name for a REPL?
> Will do.  (Everything *should* be backwards compatible, but it's 100% worth checking)
I meant, the rakudo-build-system expects PERL6LIB, but the package now has a
RAKULIB search path instead.
>> You add some patches, but they need to be registered in gnu/local.mk as well, please do so.
> Will do.
>
>> On the patch file name: it looks a little suspect, perhaps if you run the linter on the
>> packages it will have a comment about the file names.
> I ran the linter and its only comment was that patches need to start with the package name.
Possibly it expects the package name to be followed by a - instead of a .
> Is there another rule?
Patches should have a comment at the top explaining what they are for, 
but you already did that.

Greetings,
Maxime