Re: GUIX_EXTENSIONS_PATH error?

[zimoun]

Hi Ricardo,

About the precedence, i.e., extension that overrides default command,
see patch#45910.




On Fri, 15 Jan 2021 at 23:42, Ricardo Wurmus  wrote:
> zimoun  writes:

> We can change this, but we’d need to agree on an as yet unused directory
> as the root for extensions.

I do not know, maybe I will change my mind after a good ol’ black
coffee. :-)

We could say that:

 1. the prototype of GUIX_EXTENSIONS_PATH is path/to/guix
 2. the folder /extensions is implicitly appended 
 3. ~/.config/guix is implicitly appended

The patch attached does that.  But, the definition of the package ’guix’
needs to be tweaked (not done) in agreement, especially:

--8<---cut here---start->8---
  (native-search-paths
   (list (search-path-specification
  (variable "GUIX_EXTENSIONS_PATH")
  (files '("share/guix/extensions")
--8<---cut here---end--->8---


>> Moreover, it could nice to have GUIX_EXTENSIONS_PATH look by default
>> in ~/.config/guix/extensions, i.e., by default
>> GUIX_EXTENSIONS_PATH=~/.config.
>
> The last part of this sentence is what I meant above: we need to avoid
> that, because that would cause
> ~/.config/guix/current/share/guile/site/3.0/guix/scripts/ to be included
> in the search for extensions.

It is easy to filter out by adding rules in ’extensions-directories’. :-)

> I have added a search path specification to the “guix” package itself,
> so that it will set GUIX_EXTENSIONS_PATH to
> $profile/share/guix/extensions automatically.  The idea is to update the
> format of the “channels.scm” file to allow for the installation of extra
> packages into the “guix pull” profile (by default that’s
> ~/.config/guix/current).

I see.  Well, I need to fail myself to really understand…

> This way I could say that I want the freshly pulled Guix to also install
> the “gwl” package in the same profile, and that new Guix would
> automatically have the “gwl” extension’s “workflow” sub-command.

I agree.


Cheers,
simon
--

diff --git a/guix/ui.scm b/guix/ui.scm
index ad78d5cedd..e918b5b64f 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -2066,8 +2066,10 @@ contain a 'define-command' form."
 (define (extension-directories)
   "Return the list of directories containing Guix extensions."
   (filter file-exists?
-  (parse-path
-   (getenv "GUIX_EXTENSIONS_PATH"
+  (map (cut string-append <> "/extensions")
+   (parse-path
+(string-append (config-directory) ":"
+ (getenv "GUIX_EXTENSIONS_PATH"))
 
 (define (commands)
   "Return the list of commands, alphabetically sorted."

Re: GUIX_EXTENSIONS_PATH error?

[Ricardo Wurmus]

zimoun  writes:

>> I have added a search path specification to the “guix” package itself,
>> so that it will set GUIX_EXTENSIONS_PATH to
>> $profile/share/guix/extensions automatically.  The idea is to update the
>> format of the “channels.scm” file to allow for the installation of extra
>> packages into the “guix pull” profile (by default that’s
>> ~/.config/guix/current).
>
> ...because yeah that's the aim. :-)  Provide extensions as channels.

It’s very similar to providing extensions as channels, but without
actually using the channel mechanism.   Channels are a little different
from regular packages.  They consist solely of Guile source files, they
are not compiled ahead of time but built during “guix pull”, and they
cannot have inputs other than channels.

Extensions like the GWL have non-trivial dependencies, which cannot be
included when the GWL is treated as a channel.

Maybe there’s a way to express channels themselves as regular packages,
but I’m not seeing it.  So until we can unify this, extensions should be
installed as packages once “guix pull” has finished building the new
Guix (with all its channels).

Does this make sense?

-- 
Ricardo

Re: GUIX_EXTENSIONS_PATH error?

[zimoun]

Re,

On Fri, 15 Jan 2021 at 23:42, Ricardo Wurmus  wrote:
> zimoun  writes:
>
> >> So if the file is at /tmp/foo/guix/extensions/bar.scm then
> >> $GUIX_EXTENSIONS_PATH should be /tmp/foo/guix/extensions.
> >
> > Well, I will propose to have the thing as you said before.  Because
> > fixing (guix extensions bar) and the path $GUIX_EXTENSIONS_PATH/foo
> > seems reasonable but $GUIX_EXTENSIONS_PATH/foo/guix/extensions is too
> > redundant.
>
> It does seem so, but the idea was to reduce the number of files that
> Guix will have to parse before finding an extension.
>
> Extensions would be installed to the same prefix /share/guix/extensions,
> so Guix can set GUIX_EXTENSIONS_PATH to $profile/share/guix/extensions
> and not worry about having to parse all the Scheme files in
> $profile/share, which may be a lot — for example Guix’s own commands are
> defined in files under $profile/share, so they would end up as
> extensions…

Ah I see.

> We can change this, but we’d need to agree on an as yet unused directory
> as the root for extensions.

Well, I have to rehash a bit and then see what could be "user
friendly" without typing redundancy.

> > Moreover, it could nice to have GUIX_EXTENSIONS_PATH look by default
> > in ~/.config/guix/extensions, i.e., by default
> > GUIX_EXTENSIONS_PATH=~/.config.
>
> The last part of this sentence is what I meant above: we need to avoid
> that, because that would cause
> ~/.config/guix/current/share/guile/site/3.0/guix/scripts/ to be included
> in the search for extensions.

Ah I see.  But we could filter out this "current" from the path.  In
the case of default to "~/.config/guix/extensions/".

Well, need some thoughts...

> I have added a search path specification to the “guix” package itself,
> so that it will set GUIX_EXTENSIONS_PATH to
> $profile/share/guix/extensions automatically.  The idea is to update the
> format of the “channels.scm” file to allow for the installation of extra
> packages into the “guix pull” profile (by default that’s
> ~/.config/guix/current).

...because yeah that's the aim. :-)  Provide extensions as channels.


Cheers,
simon

Re: GUIX_EXTENSIONS_PATH error?

[Ricardo Wurmus]

zimoun  writes:

>> So if the file is at /tmp/foo/guix/extensions/bar.scm then
>> $GUIX_EXTENSIONS_PATH should be /tmp/foo/guix/extensions.
>
> Well, I will propose to have the thing as you said before.  Because
> fixing (guix extensions bar) and the path $GUIX_EXTENSIONS_PATH/foo
> seems reasonable but $GUIX_EXTENSIONS_PATH/foo/guix/extensions is too
> redundant.

It does seem so, but the idea was to reduce the number of files that
Guix will have to parse before finding an extension.

Extensions would be installed to the same prefix /share/guix/extensions,
so Guix can set GUIX_EXTENSIONS_PATH to $profile/share/guix/extensions
and not worry about having to parse all the Scheme files in
$profile/share, which may be a lot — for example Guix’s own commands are
defined in files under $profile/share, so they would end up as
extensions…

We can change this, but we’d need to agree on an as yet unused directory
as the root for extensions.

> Moreover, it could nice to have GUIX_EXTENSIONS_PATH look by default
> in ~/.config/guix/extensions, i.e., by default
> GUIX_EXTENSIONS_PATH=~/.config.

The last part of this sentence is what I meant above: we need to avoid
that, because that would cause
~/.config/guix/current/share/guile/site/3.0/guix/scripts/ to be included
in the search for extensions.

I have added a search path specification to the “guix” package itself,
so that it will set GUIX_EXTENSIONS_PATH to
$profile/share/guix/extensions automatically.  The idea is to update the
format of the “channels.scm” file to allow for the installation of extra
packages into the “guix pull” profile (by default that’s
~/.config/guix/current).

This way I could say that I want the freshly pulled Guix to also install
the “gwl” package in the same profile, and that new Guix would
automatically have the “gwl” extension’s “workflow” sub-command.

-- 
Ricardo

Re: GUIX_EXTENSIONS_PATH error?

[zimoun]

Hi,

On Fri, 15 Jan 2021 at 23:25, Ricardo Wurmus  wrote:

> Oh, my bad:  $GUIX_EXTENSIONS_PATH must actually include the
> “/guix/extensions” sub-directory.

Thanks.  It works! \o/
Awesome :-)


> So if the file is at /tmp/foo/guix/extensions/bar.scm then
> $GUIX_EXTENSIONS_PATH should be /tmp/foo/guix/extensions.

Well, I will propose to have the thing as you said before.  Because
fixing (guix extensions bar) and the path $GUIX_EXTENSIONS_PATH/foo
seems reasonable but $GUIX_EXTENSIONS_PATH/foo/guix/extensions is too
redundant.
Moreover, it could nice to have GUIX_EXTENSIONS_PATH look by default
in ~/.config/guix/extensions, i.e., by default
GUIX_EXTENSIONS_PATH=~/.config.


Cheers,
simon

Re: GUIX_EXTENSIONS_PATH error?

[Ricardo Wurmus]

zimoun  writes:

>>> --8<---cut here---start->8---
>>> $ cat /tmp/foo/bar.scm
>>> (define-module (guix extensions bar)
>>>   #:use-module (guix scripts))
>>
>> This right here is the problem.  The module name and the file name do
>> not match.  The file must be
>> $GUIX_EXTENSIONS_PATH/guix/extensions/bar.scm and provide the module
>> (guix extensions bar).
>
> Ah yeah, that makes sense.  Now, no error but nothing showed:
>
> --8<---cut here---start->8---
> $ cat $GUIX_EXTENSIONS_PATH/guix/extensions/bar.scm
> (define-module (guix extensions bar)
>   #:use-module (guix scripts)
>   #:export (guix-bar)
>   )
>
>
> (define-command (guix-bar . args)
>   (category extension)
>   (synopsis "a bar with beer")
>
>   (pk "dumb"))
>
> $ guix --help | grep bar
> --8<---cut here---end--->8---

Oh, my bad:  $GUIX_EXTENSIONS_PATH must actually include the
“/guix/extensions” sub-directory.

So if the file is at /tmp/foo/guix/extensions/bar.scm then
$GUIX_EXTENSIONS_PATH should be /tmp/foo/guix/extensions.

Sorry for the confusion!

-- 
Ricardo

[Emacs-Guix] make: Error 255

[zimoun]

Hi,

Giving a look at the “lagging” build utility with Emacs-Guix, I have
checked out and run ’make’.  But I get a couple of errors:

--8<---cut here---start->8---
make[1]: [Makefile:1283: elisp/guix-build-config.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-config.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-auto-mode.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-utils.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-external.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-profiles.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-scheme.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-env-var.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-guile.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-geiser.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-repl.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-help-vars.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-read.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-help.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-about.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-misc.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-build-log.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-command.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-devel.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-graph.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-hash.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-derivation.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-license.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-location.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-package.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-service.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-pcomplete.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-prettify.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-popup.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-messages.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-license.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-profile.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-store-item.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-lint-checker.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-package.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-package-location.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-generation.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-system-generation.elc] Error 255 
(ignored)
make[1]: [Makefile:1283: elisp/guix-ui-service.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-service-location.elc] Error 255 (ignored)
make[1]: [Makefile:1283: elisp/guix-ui-system.elc] Error 255 (ignored)
--8<---cut here---end--->8---

Is it expected?  Do I miss something?


All the best,
simon

Re: New “ungrafting” branch

[Leo Famulari]

On Fri, Jan 15, 2021 at 12:57:50AM -0500, Mark H Weaver wrote:
> Ludovic Courtès  writes:
> 
> > Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> > that does nothing but ungraft things.
> >
> > The rationale is that grafts incur additional overhead when installing
> > things (the time to create those grafts), so it’s good to clean them up
> > once in a while.  Ungrafting in a dedicated branch means we know the
> > branch is “safe”, unlike more exploratory branches like ‘staging’ and
> > ‘core-updates’.
> >
> > The plan is to start building it later today, and to hopefully be done
> > in a week or so.
> 
> This is a good initiative, but it seems to have stalled.  Is there a
> reason that it has not yet been merged into 'master'?

The ungrafting branch was merged into the staging branch. Unfortunately,
the staging branch is moving very slowly. I perceive a lack of
interest in working on it :/

I think that the ungrafting branch should have been kept separate and
merged into master quickly.

Re: GUIX_EXTENSIONS_PATH error?

[zimoun]

Hi,

On Fri, 15 Jan 2021 at 21:45, Ricardo Wurmus  wrote:
> zimoun  writes:
>
>> In the mood for documenting the recent GUIX_EXTENSIONS_PATH, I am
>> missing something because I hit an error.
>
> It’s not your fault.  It’s hard to do this without documentation.

It’s so cool that I would like to document it. ;-)  Sorry to not dive in
the code first.

>> --8<---cut here---start->8---
>> $ cat /tmp/foo/bar.scm
>> (define-module (guix extensions bar)
>>   #:use-module (guix scripts))
>
> This right here is the problem.  The module name and the file name do
> not match.  The file must be
> $GUIX_EXTENSIONS_PATH/guix/extensions/bar.scm and provide the module
> (guix extensions bar).

Ah yeah, that makes sense.  Now, no error but nothing showed:

--8<---cut here---start->8---
$ cat $GUIX_EXTENSIONS_PATH/guix/extensions/bar.scm
(define-module (guix extensions bar)
  #:use-module (guix scripts)
  #:export (guix-bar)
  )


(define-command (guix-bar . args)
  (category extension)
  (synopsis "a bar with beer")

  (pk "dumb"))

$ guix --help | grep bar
--8<---cut here---end--->8---


Cheers,
simon

Re: GUIX_EXTENSIONS_PATH error?

[Ricardo Wurmus]

zimoun  writes:

> In the mood for documenting the recent GUIX_EXTENSIONS_PATH, I am
> missing something because I hit an error.

It’s not your fault.  It’s hard to do this without documentation.

> --8<---cut here---start->8---
> $ cat /tmp/foo/bar.scm
> (define-module (guix extensions bar)
>   #:use-module (guix scripts))

This right here is the problem.  The module name and the file name do
not match.  The file must be
$GUIX_EXTENSIONS_PATH/guix/extensions/bar.scm and provide the module
(guix extensions bar).

> $ export GUIX_EXTENSIONS_PATH=/tmp/foo
>
> $ guix --help
> Usage: guix COMMAND ARGS...
> Run COMMAND with ARGS.
>
> COMMAND must be one of the sub-commands listed below:
> Backtrace:
>4 (primitive-load "/home/simon/.config/guix/current/bin/guix")
> In ice-9/boot-9.scm:
>   1731:15  3 (with-exception-handler # ice-9/boot-9.scm:1815:7 (exn)> _ # _ …)
> In guix/ui.scm:
>   2105:20  2 (show-guix-help)
> In srfi/srfi-1.scm:
>691:23  1 (filter-map # _ . _)
> In guix/ui.scm:
>2023:2  0 (source-file-command _)
>
> guix/ui.scm:2023:2: In procedure source-file-command:
> Throw to key `match-error' with args `("match" "no matching pattern" ("tmp" 
> "foo" "bar.scm"))'.

But it still shouldn’t throw an error like that.  I’ll fix it.  Sorry!

-- 
Ricardo

GUIX_EXTENSIONS_PATH error?

[zimoun]

Hi,

In the mood for documenting the recent GUIX_EXTENSIONS_PATH, I am
missing something because I hit an error.  Before diving, maybe my
daily coffee dose is not enough…


--8<---cut here---start->8---
$ cat /tmp/foo/bar.scm
(define-module (guix extensions bar)
  #:use-module (guix scripts))


(define-command (guix-bar . args)
  (category extension)
  (synopsis "a bar with beers")

  (pk "dumb"))


$ export GUIX_EXTENSIONS_PATH=/tmp/foo

$ guix --help
Usage: guix COMMAND ARGS...
Run COMMAND with ARGS.

COMMAND must be one of the sub-commands listed below:
Backtrace:
   4 (primitive-load "/home/simon/.config/guix/current/bin/guix")
In ice-9/boot-9.scm:
  1731:15  3 (with-exception-handler # _ # _ …)
In guix/ui.scm:
  2105:20  2 (show-guix-help)
In srfi/srfi-1.scm:
   691:23  1 (filter-map # _ . _)
In guix/ui.scm:
   2023:2  0 (source-file-command _)

guix/ui.scm:2023:2: In procedure source-file-command:
Throw to key `match-error' with args `("match" "no matching pattern" ("tmp" 
"foo" "bar.scm"))'.
--8<---cut here---end--->8---

What do I miss?


All the best,
simon

Re: Staging branch [substitute availability armhf-linux]

[Leo Famulari]

On Fri, Jan 15, 2021 at 09:27:36AM +0100, Vincent Legoll wrote:
> On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari  wrote:
> > Specifically about armhf, if anybody wants to use it with Guix, I hope
> > they will speak up.
> 
> I am interested, I have tried, and failed to get anything (apart from guix
> on foreign armbian). But I am more interested in guixsd though.

Okay, thanks for letting us know.

> I even attempted building the pinebook pro image without success.

Hm... it's a shame we are building this and it doesn't work.

Do you also use some armhf (32-bit) hardware?

Re: Staging branch [substitute availability]

[Christopher Baines]

Mathieu Othacehe  writes:

> Now, how to move on?
>
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.
>
> Longer term, we need to figure out a better solution. It's now
> obvious that we do not have the computation power to build all our
> branches for 5 different architectures, relying heavily on emulation for
> armhf and aarch64. Anyone knows how Nix deals with that?

Providing that the more important builds/architectures are prioritised,
I don't think it's an all or nothing situation. For build farms
providing substitutes, it's more about the time taken to catch up with
changes.

When I've tried emulation, I've found there are too many errors that
only occur when emulating.


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

Hello,

On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe  wrote:
> It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
> booted it, without graphics, after a few fixes:
> https://issues.guix.gnu.org/45584.
>
> You may want to try again :).

DONE, it's a bit better, this time initrd, kernel & dtb loaded properly.

But serial output stopped after "Starting kernel ..." which is probably
because of mismatched serial port speed, but I tried to relaunch screen
with 57600, 115200 and still go no output. [complete uboot log attached]

LCD screen stays black which is probably normal.

The image was built like the following:

# ./pre-inst-env guix describe
Git checkout:
  repository: /home/vince/dev/repo/guix
  branch: master
  commit: c03875b0361f114634caeb54935fe37a9b7b05af
# echo "(use-modules (gnu system images pinebook-pro))
pinebook-pro-barebones-os" > /tmp/os.scm
# ./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm
[...]
/gnu/store/5fj3aha8jsyji9mpqzf2krakl08r9zlw-disk-image

Next I'll try the hints from:
https://issues.guix.gnu.org/45584

> >> There is almost no armhf hardware that is suitable
> >> for a build-from-source distro in terms of performance, thermal design
> >> and suitable storage (SD cards will not last for unless you pay a huge
> >> amount for the absolute highest quality). Binary distros like Trisquel
> >> are a much better option for armhf.
> >
> > The cross buildability *should* be kind of a solution for this.
>
> Yes we could always decide to stop supporting native ARMv7 substitutes
> and only focus on the cross-building to provide ready to use image for
> this architecture.

Isn't there a way to reconcile the 2 ? At least theoretically cross- or native-
compilation should give identical output, though I dunno how far that
is from reality (probably not good, or we would be doing just that)

> >> All that is not a reason to not support armhf, but if nobody is using
> >> it, then we should officially deprecate it, and not leave it in this
> >> in-between state.
> >
> > I'm not using it because I can't make it work.
>
> Don't hesitate to report the issues you encountered!

I've done it a few times already, for armhf, arm64, powerpc64, mipsel.

And I'll (re-)try anything if I'm hinted as what to try next.

The main problem from my PoV is the scatteredness of the infos.

Tchuss

-- 
Vincent Legoll
DDR Version 1.20 20190314
In
channel 0
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 400MHz 0,1
channel 0
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 800MHz 1,0
Channel 0: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
256B stride
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 251
SdmmcInit=2 0
BootCapSize=10
UserCapSize=119276MB
FwPartOffset=2000 , 10
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=30528MB
FwPartOffset=2000 , 0
StorageInit ok = 191888
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
LoadTrust Addr:0x4400
LoadTrust Addr:0x4800
LoadTrust Addr:0x4c00
LoadTrust Addr:0x5000
LoadTrust Addr:0x5400
LoadTrust Addr:0x5800
LoadTrust Addr:0x5c00
Addr:0x4000 No find trust.img!
LoadTrustBL error:-3
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!

Multiple values → SRFI-71

[Ludovic Courtès]

Hello Guix!

Starting from commit 4f621a2b003e85d480999e4d0630e9dc3de85bc3, we
require Guile >= 2.2.6.  Since (srfi srfi-71) was added in Guile 2.2.4,
I suggest using it instead of the more clunky (srfi srfi-11)
‘let-values’.  We can gradually migrate code.

Note that (guix build utils), (guix build gnu-build-system), and
probably a few other (guix build …) modules that are used early during
bootstrap, where Guile 2.0 is used, cannot migrate.

Ludo’.

Re: guix build: error: without-test=foo: unrecognized option

[zimoun]

Hi Ludo,

On Thu, 14 Jan 2021 at 23:30, Ludovic Courtès  wrote:

> We should display suggestions based on Levenshtein distance.

Done in patch#45893.  Feedback welcome because it is a quick draft for
my Friday's procrastination. ;-)




Cheers,
simon

Re: guix build: error: without-test=foo: unrecognized option

[zimoun]

Hi Chris,

On Thu, 14 Jan 2021 at 23:18, Christopher Baines  wrote:

> > What do I miss?
>
> An s.

Ahah!  The bug is always between the keyboard and the chair. ;-)

Cheers,
simon

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

Hello Vincent,

> I even attempted building the pinebook pro image without success.

It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
booted it, without graphics, after a few fixes:
https://issues.guix.gnu.org/45584.

You may want to try again :).

>> There is almost no armhf hardware that is suitable
>> for a build-from-source distro in terms of performance, thermal design
>> and suitable storage (SD cards will not last for unless you pay a huge
>> amount for the absolute highest quality). Binary distros like Trisquel
>> are a much better option for armhf.
>
> The cross buildability *should* be kind of a solution for this.

Yes we could always decide to stop supporting native ARMv7 substitutes
and only focus on the cross-building to provide ready to use image for
this architecture.

>> All that is not a reason to not support armhf, but if nobody is using
>> it, then we should officially deprecate it, and not leave it in this
>> in-between state.
>
> I'm not using it because I can't make it work.

Don't hesitate to report the issues you encountered!

Thanks,

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

Hey Ludo,

> You seem to imply that the issue is the number of architectures, rather
> than the small number of ARMv7 build machines (now that we disabled
> 32-bit builds on AArch64).  Do I get it right?

Yes my point is that building three specifications on three
architectures, including an emulated one, is already hard for the build
farm, so adding more specifications/architectures seems complex.

Even if we fix the problem raised by Danny, enabling again ARMv7
transparent emulation, without any additional hardware wouldn't fit.

> That was a problem with Cuirass doing ‘build-derivations’ RPCs for
> derivations spanning multiple architectures (the RPC would complete once
> the slowest architecture is done), but maybe that’s no longer the case
> with the new remote builds feature you’ve been working on?

Yes, that's solved by the remote building feature. The workers are
declaring the architectures they support. When they request work, the
remote server picks randomly an architecture and select the most
priority build available. This way the queuing happens at the database
level and not in the guix-daemon itself.

Thanks,

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

Hello,

On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari  wrote:
> Specifically about armhf, if anybody wants to use it with Guix, I hope
> they will speak up.

I am interested, I have tried, and failed to get anything (apart from guix
on foreign armbian). But I am more interested in guixsd though.

I even attempted building the pinebook pro image without success.

> I think we should monitor the volume of substitute requests per platform
> and see how big the demand for armhf Guix really is.

With the current situation, I'm not sure this would really be representative
of the armhf or arm64 demand.

> Although there is a huge amount of armhf hardware deployed, Guix seems a
> very poor fit for it.

In its current state.

> There is almost no armhf hardware that is suitable
> for a build-from-source distro in terms of performance, thermal design
> and suitable storage (SD cards will not last for unless you pay a huge
> amount for the absolute highest quality). Binary distros like Trisquel
> are a much better option for armhf.

The cross buildability *should* be kind of a solution for this.

> All that is not a reason to not support armhf, but if nobody is using
> it, then we should officially deprecate it, and not leave it in this
> in-between state.

I'm not using it because I can't make it work.

-- 
Vincent Legoll