unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* package systems, before and after the core-updates merge
@ 2019-10-17 20:40 Christopher Baines
  2019-10-19 21:02 ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Christopher Baines @ 2019-10-17 20:40 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

Hey,

One thing that I was aware of before the recent core-updates merge was
that the Guix Data Service [1] didn't generate derivations for systems
other than x86_64-linux and i686-linux, at least to the same extent as
the master branch before the recent core-updates merge.

1: http://data.guix.gnu.org/revision/2fa55c72476c73211cbb2d6b29c05a1ad58a6cf9
   (see the Derivations table)

I put this down to a bug I wasn't seeing, but now that the core-updates
branch has been merged, and now that this effect is showing up on the
master branch, I've investigated a little more.

I think this is down to the use of package-transitive-supported-systems
within the Guix Data Service, but the output of this function for a
package can also be seen by running guix package --show.

Before the recent core-updates merge:

  ./pre-inst-env guix package --show=hello
  …
  systems: x86_64-linux i686-linux armhf-linux aarch64-linux mips64el-linux

After the recent core-updates merge:

  → guix package --show=hello
  …
  systems: x86_64-linux i686-linux

Looking at the implementation of package-transitive-supported-systems,
I'm pretty sure the change in behaviour is to do with the
supported-systems for the new packages involved in the bootstrap
process.

So in terms of questions I now have, what's the "systems: " output by
guix package --show meant to mean, and what does the recent change
removing the 3 systems above from most packages in Guix mean?

Also, for the Guix Data Service, all I want to know is for a given
package, is for which systems and targets a derivation can be reasonably
computed. Maybe it is wrong to use package-transitive-supported-systems
for this.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: package systems, before and after the core-updates merge
  2019-10-17 20:40 package systems, before and after the core-updates merge Christopher Baines
@ 2019-10-19 21:02 ` Ludovic Courtès
  2019-11-19 16:39   ` zimoun
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2019-10-19 21:02 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

Hi,

Christopher Baines <mail@cbaines.net> skribis:

> One thing that I was aware of before the recent core-updates merge was
> that the Guix Data Service [1] didn't generate derivations for systems
> other than x86_64-linux and i686-linux, at least to the same extent as
> the master branch before the recent core-updates merge.

Indeed, see this bug fix that landed before the merge:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=bc60349b5bc58a0b803df5adce1de6db82453744

> I think this is down to the use of package-transitive-supported-systems
> within the Guix Data Service, but the output of this function for a
> package can also be seen by running guix package --show.

The patch below fixes ‘guix show’ but it has a noticeable performance
impact that makes me thing something’s not quite right with memoization
in ‘package-transitive-supported-systems’:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 660 bytes --]

diff --git a/guix/ui.scm b/guix/ui.scm
index 3e4bd5787e..426e517b54 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -1259,7 +1259,8 @@ WIDTH columns.  EXTRA-FIELDS is a list of symbol/value pairs to emit."
   (format port "version: ~a~%" (package-version p))
   (format port "outputs: ~a~%" (string-join (package-outputs p)))
   (format port "systems: ~a~%"
-          (string-join (package-transitive-supported-systems p)))
+          (string-join (filter (cut supported-package? p <>)
+                               %supported-systems)))
   (format port "dependencies: ~a~%"
           (match (package-direct-inputs p)
             (((labels inputs . _) ...)

[-- Attachment #3: Type: text/plain, Size: 363 bytes --]


> Also, for the Guix Data Service, all I want to know is for a given
> package, is for which systems and targets a derivation can be reasonably
> computed. Maybe it is wrong to use package-transitive-supported-systems
> for this.

You can use ‘supported-package?’ as above.  This is also what (gnu ci)
does.

Let me know if this helps!

Ludo’.

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: package systems, before and after the core-updates merge
  2019-10-19 21:02 ` Ludovic Courtès
@ 2019-11-19 16:39   ` zimoun
  0 siblings, 0 replies; 3+ messages in thread
From: zimoun @ 2019-11-19 16:39 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

Hi,

On Sat, 19 Oct 2019 at 23:03, Ludovic Courtès <ludo@gnu.org> wrote:

> > I think this is down to the use of package-transitive-supported-systems
> > within the Guix Data Service, but the output of this function for a
> > package can also be seen by running guix package --show.
>
> The patch below fixes ‘guix show’ but it has a noticeable performance
> impact that makes me thing something’s not quite right with memoization
> in ‘package-transitive-supported-systems’:

How the performances can be tested?


All the best,
simon

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-11-19 16:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-17 20:40 package systems, before and after the core-updates merge Christopher Baines
2019-10-19 21:02 ` Ludovic Courtès
2019-11-19 16:39   ` zimoun

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).