all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: 57491@debbugs.gnu.org, Daniel Sockwell <daniel@codesections.com>
Subject: [bug#57491] [PATCH] patch series: Update Raku ecosystem
Date: Wed, 7 Sep 2022 23:56:47 +0200	[thread overview]
Message-ID: <e01718cc-4ff3-d82f-c450-1948a529b8aa@telenet.be> (raw)
In-Reply-To: <b7d3322144715c3f38fe1f99d543ec64@codesections.com>


[-- Attachment #1.1.1.1: Type: text/plain, Size: 4261 bytes --]

> -@item Great Unicode support, with strings represented at grapheme level
> +@item Unusually strong Unicode support enabled by strings represented at
> +grapheme level and an embedded copy of the Unicode Character Database

IIUC, this means that previously, it didn't include a copy, and now it 
does? If so, that's bundling, which is to be avoided in Guix such that 
there is only a single copy to keep up-to-date. From (guix)Submitting 
Patches:

>   8. Make sure the package does not use bundled copies of software
>      already available as separate packages.
>
>      Sometimes, packages include copies of the source code of their
>      dependencies as a convenience for users.  However, as a
>      distribution, we want to make sure that such packages end up using
>      the copy we already have in the distribution, if there is one.
>      This improves resource usage (the dependency is built and stored
>      only once), and allows the distribution to make transverse changes
>      such as applying security updates for a given software package in a
>      single place and have them affect the whole system—something that
>      bundled copies prevent.

(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.)

I noticed you removed the mention of the garbage collector, is this 
intentional? Seems a useful feature to me ...

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 (including tests, maybe it even adds a 
shebang for the make.nqp)?

On nqp: why the switch from downloading the source code from the 
apparent official site "rakudo.perl6.org" to GitHub?

> +             (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.

On the new package description: everything in Guix is free software, the 
"open source" is superfluous. The information on who designed it is 
interesting from a historical perspective, but I don't think it is 
useful information for package descriptions. It's getting close to 
marketing phrases (see (guix)Synopses and Descriptions) with 
"prioritizes expressiveness", "optimised for fun" and "superpowers", 
"linguistically inspired" (I mean, doesn't every new language try to 
gain those properties, and how would you objectively-ish verify those 
compared to other languages (ignoring C and assembly and such), and what 
does "linguistically inspired" even mean?).  The other things can stay I 
suppose.

I've noticed the environment variable changed (PERL6LIB -> RAKULIB), but 
(guix build rakudo-build-system) hasn't changed PERL6LIB to RAKULIB.  
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?

You add some patches, but they need to be registered in gnu/local.mk as 
well, please do so.
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.

On commit messages: they don't follow our conventions.  Running "git 
log" will result in plenty of examples, also see 
<https://www.gnu.org/prep/standards/html_node/Change-Logs.html>. (They 
tend to be a bit terse, but you can always add additional information to 
them even when not strictly required.)

A new copyright line can also be added.

Greetings,
Maxime.


[-- Attachment #1.1.1.2: Type: text/html, Size: 5684 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  parent reply	other threads:[~2022-09-07 21:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 16:31 [bug#57491] [PATCH] patch series: Update Raku ecosystem Daniel Sockwell via Guix-patches via
2022-08-30 16:45 ` Daniel Sockwell via Guix-patches via
2022-08-30 16:49 ` Daniel Sockwell via Guix-patches via
2022-08-30 16:59 ` Daniel Sockwell via Guix-patches via
2022-09-07 16:26 ` Daniel Sockwell via Guix-patches via
2022-09-07 21:56 ` Maxime Devos [this message]
2022-09-08  2:18   ` Daniel Sockwell via Guix-patches via
2022-09-08  9:15     ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e01718cc-4ff3-d82f-c450-1948a529b8aa@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=57491@debbugs.gnu.org \
    --cc=daniel@codesections.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.