Re: Renaming stumpwm contributor packages

[Pierre Neidhardt]

I don't use StupmWM, but this makes sense to me, so +1!

:)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: 02/04: doc: Update README to refer to the manual.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi Ludo!

> Jan Nieuwenhuizen  skribis:
>
>>> commit c75a80189fc19f6ff8b4c82d1d1801be6763b6d2
>>> Author: Ludovic Courtès 
>>> AuthorDate: Tue Jun 2 14:50:54 2020 +0200
>>>
>>> doc: Update README to refer to the manual.
>>>
>>> * README (Requirements): Refer to the manual.
>>> (Installation): Update URL of the manual.
>>
>> Hmm, I don't like it!  Also, no rationale.
>
> Someone reported that the list of dependencies (the Guile version in
> particular) in ‘README’ was outdated.  I set out to update it and then
> realized that that info was already available and up-to-date in the
> manual.  Hence this patch.

Okay...

>> ...but as a new potential user of a software I have often cursed the
>> makers for providing "empty" READMEs that refer to documentation that is
>> neither built (yet) or shipped, or needs a viewer/web browser; making it
>> most convenient for them, the writers, and not for me, the reader;
>> leaving me puzzled ... "So, you'd rather not have me use your software?"
>>
>> I'm wondering if you haven't had that experience, and how you look at
>> this...
>
> Sure.  Two things:
>
>   1. People installing a release from a tarball have doc/guix.info
>  already built.

Ah, that's right.

>   2. The ‘README’ also gives the URL of the on-line copy of the manual.
>
> So I think the information is readily available.
>
> My goal here was just to avoid having an outdated copy of parts of the
> manual.
>
> I hope that makes sense!

Yes...it looks like this struck a nerve; I'll think about it.

Thanks; Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Danny Milosavljevic]

Thanks!

Changes sourceforge URL in presage to use mirrors.

This set of packages causes rebuild of 2400 other packages.

(Leaving gdk-pixbuf and gdk-pixbuf+svg off for testing purposes would drop it 
to 388 packages)

Pushed to wip-desktop.


pgpdnNaNHHaEo.pgp
Description: OpenPGP digital signature

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Vincent Legoll]

Hello Raghav,

On 04/06/2020 20:31, Raghav Gururajan wrote:

Please find attached patches.


Could you add a simple / small description of the patch set each time
you send one ?

The bare email with only attached files is not directly useful to us
mere bystanders, without opening each file which is tedious.

So with maybe the `git log --oneline' or something like that we can 
quickly see if there is something of direct interest and then dig in.


Or you can do the usual full dance with an introductory message to
guix-patc...@gnu.org, then followed by each patch in a single email
(easy to do with `git send-email'). Dunno if that is useful in that
case.

I hope not to have stepped on mentor's toes with this inquiry ;-)

Happy contributing !

--
Vincent Legoll

Re: Heads-up: “pre-push” Git hook updated

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> So, I think make authenticate dislikes the naming I use for Git remotes,
>> in particular I don't have an origin remote.
>>
>> → make authenticate
>> Compiling Scheme modules...
>> Authenticating Git checkout...
>> Authenticating d68de95 to 776409c (0 commits)...
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   1736:10 10 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>9 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>> 718:2  8 (call-with-prompt _ _ #)
>> In ice-9/eval.scm:
>> 619:8  7 (_ #(#(#)))
>>293:34  6 (_ #(#(#(#(#(#(#(#(#(#(#<…> …) …) …) …) …) …) …) …) …) …))
>> In guix/progress.scm:
>> 71:36  5 (call-with-progress-reporter _ _)
>> In ice-9/eval.scm:
>> 619:8  4 (_ #(#(#(#) # …) #))
>>626:19  3 (_ #(#(#(#) # …) #))
>>293:34  2 (_ #(#(#) # …))
>> In git/branch.scm:
>> 101:8  1 (_ _ _ _)
>> In git/bindings.scm:
>>  77:2  0 (raise-git-error _)
>>
>> git/bindings.scm:77:2: In procedure raise-git-error:
>> Git error: cannot locate remote-tracking branch 'origin/keyring'
>>
>> make: *** [Makefile:5965: authenticate] Error 1
>>
>>
>> I tried renaming my savannah remote to origin, and then it seemed to
>> work. Any ideas?
>
> Yeah, that’s a problem Tobias reported as well.
>
> In  I change it to just use the local
> ‘keyring’ branch.  That also requires you to set things up
> appropriately, but I think that’s hard to avoid no?

Great, that sounds good :)


signature.asc
Description: PGP signature

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Raghav Gururajan]

@Danny

Please find attached patches.

Regards,
RG.
From efe996a0c53ac90522498a980bd6a40beb1d9a56 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan 
Date: Tue, 2 Jun 2020 19:41:00 -0400
Subject: [PATCH 11/16] gnu: Add presage.

* gnu/packages/fcitx.scm (presage): New variable.
---
 gnu/packages/fcitx.scm | 60 ++
 1 file changed, 60 insertions(+)

diff --git a/gnu/packages/fcitx.scm b/gnu/packages/fcitx.scm
index e699d7d59d..61bf36cd83 100644
--- a/gnu/packages/fcitx.scm
+++ b/gnu/packages/fcitx.scm
@@ -22,18 +22,78 @@
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system cmake)
+  #:use-module (guix build-system glib-or-gtk)
+  #:use-module (gnu packages check)
   #:use-module (gnu packages documentation)
   #:use-module (gnu packages enchant)
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages glib)
+  #:use-module (gnu packages graphviz)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages icu4c)
   #:use-module (gnu packages iso-codes)
+  #:use-module (gnu packages man)
+  #:use-module (gnu packages ncurses)
   #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages sqlite)
   #:use-module (gnu packages web)
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg))
 
+(define-public presage
+  (package
+(name "presage")
+(version "0.9.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri
+(string-append "https://sourceforge.net/projects/presage/files/presage/;
+   version "/presage-" version ".tar.gz"))
+   (sha256
+(base32 "0rm3b3zaf6bd7hia0lr1wyvi1rrvxkn7hg05r5r1saj0a3ingmay"
+(build-system glib-or-gtk-build-system)
+(outputs '("out" "doc"))
+(arguments
+ `(#:configure-flags
+   (list
+"CFLAGS=-Wno-narrowing"
+"CXXFLAGS=-Wno-narrowing")
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'install 'move-doc
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(doc (assoc-ref outputs "doc")))
+   (mkdir-p (string-append doc "/share/presage"))
+   (rename-file
+(string-append out "/share/presage/html")
+(string-append doc "/share/presage/html"))
+   #t))
+(native-inputs
+ `(("dot" ,graphviz)
+   ("doxygen" ,doxygen)
+   ("gettext" ,gettext-minimal)
+   ("glib:bin" ,glib "bin")
+   ("gtk+:bin" ,gtk+ "bin")
+   ("help2man" ,help2man)
+   ("pkg-config" ,pkg-config)
+   ("python-wrapper" ,python-wrapper)))
+(inputs
+ `(("glib" ,glib)
+   ("gtk+" ,gtk+)
+   ("libx11" ,libx11)
+   ("sqlite" ,sqlite)
+   ("tinyxml" ,tinyxml)))
+(synopsis "Intelligent Predictive Text Entry System")
+(description "Presage generates predictions by modelling natural language as
+a combination of redundant information sources.  It computes probabilities for
+words which are most likely to be entered next by merging predictions generated
+by the different predictive algorithms.")
+(home-page "https://presage.sourceforge.io/;)
+(license gpl2+)))
+
 (define-public fcitx
   (package
 (name "fcitx")
-- 
2.26.2

From e9121dabc1de6cdd748a8ce2258d3cd2bb1233f9 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan 
Date: Tue, 2 Jun 2020 20:42:46 -0400
Subject: [PATCH 12/16] gnu: fcitx: Update package definition.

* gnu/packages/fcitx.scm (fcitx): Update packages definition.
[arguments]<#:configure-flags>[-DENABLE_QT_GUI]: New flag.
[-DGOBJECT_INTROSPECTION_GIRDIR]: New flag.
[-DGOBJECT_INTROSPECTION_TYPELIBDIR]: New flag.
[-DENABLE_GIR]: Remove flag.
[native-inputs]: Add dot, gettext, gobject-introspection, intltool,
libxml2 and python-wrapper.
[inputs]: Add cairo, ecm, fontconfig, libx11, libxkbcommon, opencc,
pango and presage. Remove glib and libxml2.
[propagated-inputs]: Add glib.
---
 gnu/packages/fcitx.scm | 106 +
 1 file changed, 65 insertions(+), 41 deletions(-)

diff --git a/gnu/packages/fcitx.scm b/gnu/packages/fcitx.scm
index 61bf36cd83..da9eabeced 100644
--- a/gnu/packages/fcitx.scm
+++ b/gnu/packages/fcitx.scm
@@ -24,8 +24,10 @@
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system glib-or-gtk)
   #:use-module (gnu packages check)
+  #:use-module (gnu packages compression)
   #:use-module (gnu packages documentation)
   #:use-module (gnu packages enchant)
+  #:use-module (gnu packages fontutils)
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages graphviz)
@@ -37,9 +39,11 @@
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages python)
   #:use-module (gnu packages sqlite)
+  #:use-module (gnu packages textutils)
   #:use-module (gnu packages web)
   #:use-module (gnu packages 

Channel introductions

[zimoun]

Hi Ludo,

I move the discussion to guix-devel to avoid to pollute the bug thread
[1] already long enough. :-)

Well thank you for the explanations.  There is still something I do
not understand.  I am sorry to be slow but as I am pushing the
adoption of Guix in my lab, it is hard to explain ("sell") when I have
not well understood myself. :-)


You said:

> Nothing special, I guess: each channel would be authenticated (or not,
> if it’s an unsigned channel).  I think it’s completely orthogonal.

and

> >  ;; Tell 'guix pull' to use my own repo.
> >  (list (channel
> >  (name 'guix)
> >  (url "https://example.org/my-guix.git;)
> >  (branch "super-hacks")))
>
> Yeah, we have to keep it working.  So I guess in that case it would just
> emit a warning saying this channel is not authenticated, and that’s it.

and

> >> No, when publishing a fork of an authenticated channel, you’ll have to
> >> publish its introduction alongside its URL.

and so, I do not understand what happens if:

 a- the channel is unsigned
 b- the channel is signed and I want to add something to it


> >  1- an authenticated fork of an authenticated channel
> >  2- an authenticated fork of an unauthenticated channel
> >  3- an unauthenticated fork of an authenticated channel
> >  4- an unauthenticated fork of an unauthenticated channel
> >
> > "authenticated channel" means a channel using all the authentication 
> > machinery.
> > "authenticated fork" means add a "channel introduction" and so become
> > a "authenticate channel" then.
>
> I’m sorry, I don’t follow the terminology.

Well, I am sorry if I have not understood.  From my understanding,
today there is unsigned channels (called above unauthenticated
channels) and tomorrow some channel will be signed (called above
authenticated channel).  Then adding materials to these 2 kind of
channels can be done in 2 ways: signed or unsigned (called above,
authenticated fork and unauthenticated fork, respectively).
Therefore, this leads to 4 situations:

 1- add signed material to a signed channel
 2- introduce authentication to an unsigned channel
 3- add unsigned material to a signed channel
 4- add unsigned material to unsigned channel

Therefore, my question is what happens?  Today, I can fork any channel
and publish this fork without enter in the security dance.  Well, I
want to continue to be able to fork any channel and publish the fork
without enter in the security dance and based on your answers, I do
not understand if it will still be possible.

I understand that there is incompatible requirements but I miss what
will be the framework of channels with this trusted "guix pull".

Could '--allow-downgrades' bypass the authentication mechanism?  Since
it is the name (more descriptive than) for '--allow-anything'. ;-)
(at least with Git histories)


> > 1- the correct way
> > 2- bootstrap the trust
> > 3- and 4- quick and dirty "Scientific" workflows where the security is
> > not a concern.
>
> Funny how “scientific” has become synonymous with “quick-and-dirty”
> these days…

Even if 'quick-and-dirty' is often a point of view. ;-)

However, the point is that security is not a main concern for
"scientific" workflow.  The main argument of Applied Maths or
Biologists people I know is first: easy-to-use and robust.  And
security is in general not-easy and error-prone.  Anyway.


> Yet, these two issues must also be addressed in Guix, like in any other
> distro.

[...]

> I hope that makes sense.

Yes it makes sense.
I disagree on "get the latest" but who cares. :-)


Sorry again to be slow.

All the best,
simon


[1] http://issues.guix.gnu.org/issue/22883

Re: Renaming stumpwm contributor packages

[Katherine Cox-Buday]

Tobias Geerinckx-Rice  writes:

> Katherine Cox-Buday 写道：
>> Can I get a +1 from someone appropriate to rename these packages to
>> be
>> prepended with `sbcl-stumpwm-`?
>
> In the case of sbcl-pass, at least, you're just fixing a typo/bug: the
> variable is already named sbcl-stumpwm-pass, its NAME should match.
> No +1 needed for that.

It looks like all the contrib modules are this way. My guess is that it
might be because this is what the Common Lisp system names are. 

> But +1 nonetheless.

Thank you!

They also all independently declare the same source repository they come
from, so I think I'll establish an inheritance pattern there.

-- 
Katherine

Re: Renaming stumpwm contributor packages

[Tobias Geerinckx-Rice]

Katherine Cox-Buday 写道：
Can I get a +1 from someone appropriate to rename these packages 
to be

prepended with `sbcl-stumpwm-`?


In the case of sbcl-pass, at least, you're just fixing a typo/bug: 
the variable is already named sbcl-stumpwm-pass, its NAME should 
match.  No +1 needed for that.


But +1 nonetheless.

Kind regards,

T G-R


signature.asc
Description: PGP signature

Renaming stumpwm contributor packages

[Katherine Cox-Buday]

StumpWM is a window manager which has optional, community contributed,
modules you can use. I went to go add these to Guix and discovered
they're already present albeit with confusing names.

For example, `sbcl-stumpwm-pass` is simply `sbcl-pass`. This limits
discoverability, and suggests that these packages are more broadly
useful than they are (as far as I know they are only useful within the
context of StumpWM).

Can I get a +1 from someone appropriate to rename these packages to be
prepended with `sbcl-stumpwm-`?

-
Katherine

Re: Build reproducibility metrics

[Vagrant Cascadian]

On 2020-06-03, Christopher Baines wrote:
> Combining that with the substitute server operated by Tobias, which has
> a pretty awesome substitute availability of over 90% for recent
> revisions, not only is there data from 4 different substitute servers to
> use in the comparison, but the proportion of packages where there isn't
> sufficient data is pretty low, below 10%.
>
> I'm currently using the data.guix-patches.cbaines.net instance of the
> Guix Data Service, you can see the package substitute availability for
> the latest revision using this URL [1], and the package reproducibility
> at this URL [2].
>
> 1: 
> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-substitute-availability
> 2: 
> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-reproducibility
>
> Some caution is needed when interpreting this data. It's most probably
> less up to date than what you'd get through running the guix weather or
> guix challenge commands, as it takes the Guix Data Service time to query
> the data, that querying process isn't very reliable at the moment
> either. Additionally, the "matching" percentage could easily go down if
> that output is built with a different hash in the future.
>
> While the number itself maybe isn't the most useful thing, I like that
> clicking through to the "Not matching" outputs will show a list of
> outputs which didn't build reproducibly, which is something that could
> help identify reproducibility issues to investigate and fix.
>
> I think things are coming together on the substitute server side. The
> goal I have in mind for this is for users of Guix to be able to have
> greater trust in the substitutes they use, through trusting substitutes
> only if it's been built reproducibly on multiple substitute servers. It
> would be great to see work start soon on how guix as a client to
> substitute servers might be enhanced to check for reproducibility when
> fetching substitutes.

Really glad to see great progress on this!

I've CC'ed the reproducible builds list, as others might be interested
to see too! original post:

  https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00034.html

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Compilation time with Guile 3.0.3-to-be

[Ludovic Courtès]

Hello!

Andy Wingo  skribis:

> On Thu 04 Jun 2020 09:50, Ludovic Courtès  writes:

[...]

>> For the record, the optimizations currently used in (guix build compile)
>> are between the new -O0 and -O1:
>>
>>   (cond ((or (string-contains file "gnu/packages/")
>>  (string-contains file "gnu/tests/"))
>>  ;; Level 0 is good enough but partial evaluation helps preserve the
>>  ;; "macro writer's bill of rights".
>>  (override-option #:partial-eval? #t
>>   (optimizations-for-level 0)))
>
> Here fwiw I would use -O1.  It is basically the same as -O0 except that
> it adds partial evaluation and it inlines primcalls.  If you are willing
> to do partial evaluation, you are probably willing to inline primcalls
> too; I think it typically leads to less code and the compilation time is
> similar to -O0.

Alright, let’s do that.

>> ((string-contains file "gnu/services/")
>>  ;; '-O2 -Ono-letrectify' compiles about ~20% faster than '-O2' for
>>  ;; large files like gnu/services/mail.scm.
>>  (override-option #:letrectify? #f
>>   (optimizations-for-level 2)))
>
> Interesting.  I think this is probably a bug of some sort that we'll
> have to keep working on.

Yeah I think memory consumption increases noticeably with
letrectification, which in turns means more GC activity.

> Note that in 3.0.3 there is also a new phase called "lowering".  Before
> a compiler from Tree-IL to language X is called, the tree-IL program is
> "lowered" -- meaning canonicalized and optionally optimized.
>
> (define (lower-exp exp env optimization-level opts)
>   (let ((make-lowerer (language-lowerer (lookup-language 'tree-il
> ((make-lowerer optimization-level opts) exp env)))
>
> Similarly there is an analysis pass for warnings, which runs before
> lowering:
>
> (define (analyze-exp exp env warning-level warnings)
>   (let ((make-analyzer (language-analyzer (lookup-language 'tree-il
> ((make-analyzer warning-level warnings) exp env)))
>
> These can be interesting to test different phases of the tree-il ->
> bytecode path.

OK, I’ll take a look.

>> The profile looks like this:
>>
>> scheme@(guile-user)> ,pr (define t (call-with-input-file  
>> "gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 
>> 'tree-il
>> % cumulative   self 
>> time   seconds seconds  procedure
>>  13.16  0.45  0.40  anon #x1136458

[...]

>> It’d be great to waive the anonymity of that first lambda.  :-)
>
> I think I just fixed it :)

Yay, thank you, it’s much nicer now!

--8<---cut here---start->8---
scheme@(guile-user)> ,use(system base compile)
scheme@(guile-user)> ,pr (define t (call-with-input-file  
"gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 
'tree-il
% cumulative   self 
time   seconds seconds  procedure
 16.24  0.52  0.49  set-source-properties!
 12.82  0.47  0.39  ice-9/boot-9.scm:3128:0:module-gensym
  4.27  0.13  0.13  ice-9/popen.scm:168:0:reap-pipes
  4.27  0.13  0.13  ice-9/psyntax.scm:749:8:search
  3.42  0.13  0.10  ice-9/boot-9.scm:2201:0:%load-announce
  3.42  0.10  0.10  ice-9/boot-9.scm:3434:11:b
  3.42  0.10  0.10  read
  3.42  0.10  0.10  source-properties
  2.56 50.34  0.08  ice-9/threads.scm:388:4
  2.56 12.56  0.08  ice-9/psyntax.scm:1611:10:parse
  2.56  0.08  0.08  module-variable
  2.56  0.08  0.08  memoize-expression
  2.56  0.08  0.08  ice-9/psyntax.scm:668:4:make-binding-wrap
  1.71  0.08  0.05  ice-9/boot-9.scm:2790:0:module-ref-submodule
  1.71  0.05  0.05  number->string
  1.71  0.05  0.05  ice-9/boot-9.scm:1396:0:symbol-append
  1.71  0.05  0.05  append
  1.71  0.05  0.05  string-append
  0.85270.25  0.03  ice-9/boot-9.scm:220:5:map1
--8<---cut here---end--->8---

Nowadays I freak out every time I see those weak hash tables show up.  ;-)
Well, given the size of the file, it’s no surprise that
‘set-source-properties!’ is called a lot, but it’s still worrying that
it’s #1.  (Perhaps an issue similar to ?)

> I think the reap-pipes call is a pretty bad sign, incidentally!

Yeah, it was discussed recently and I can’t explain it:

  https://lists.gnu.org/archive/html/guile-devel/2020-05/msg00019.html

Thanks for your feedback!

Ludo’.

Re: [bug#41694] [PATCH] doc: cookbook: Add entry about getting substitutes through Tor.

[Brice Waegeneire]

Hello,

On 2020-06-04 12:29, Ludovic Courtès wrote:

Hi,

Brice Waegeneire  skribis:


* doc/guix-cookbook.texi (Getting substitutes from Tor): New section.


Yay!


+@node Getting substitutes from Tor
+@section Getting substitutes from Tor
+
+@quotation Warning
+@emph{Not all} Guix daemon's traffic will go through Tor!  Only
+HTTP/HTTPS will get proxied; FTP, Git protocol, SSH, etc connections
+will still go through the clearnet.  Again, this configuration isn't
+foolproof some of your traffic won't get routed by Tor at all.  Use 
it

+at your own risk.
+@end quotation


I would suggest adding a line of intro before the warning, otherwise we
see the warning before even knowing what the section is about.  :-)

+Guix's substitute server is available as a hidden service, if you 
want


I think official terminology these days is “Onion service”.


+to use it to get your substitutes from Tor configure your system as
+follow:
+
+@lisp
+(use-modules (gnu))
+(use-service-module base networking)
+
+(operating-system
+  …
+  (services
+(cons
+  (service tor-service-type
+  (tor-configuration
+(config-file (plain-file "tor-config"
+ "HTTPTunnelPort 
127.0.0.1:9250"

+  (modify-services %base-services
+   (guix-service-type

 ^
Too many spaces here.


+@example
+# herd set-http-proxy guix-daemon http://localhost:9250
+$ guix build --substitute-urls=https://bp7o7ckwlewr4slm.onion hello
+@end example


To make it copy/pastable, you can remove the prompt and write it as:

  sudo herd set-http-proxy …
  guix build …

Something along these lines LGTM.

Thank you!

Ludo’.


Thank you for the review Ludovic.

Pushed as c987b72382e739bf887849b02c533eda317ea52b with the 3 
modifications you

were requesting.

- Brice

Re: Compilation time with Guile 3.0.3-to-be

[Ludovic Courtès]

Ludovic Courtès  skribis:

> With the attached patch I’ve run ‘make as-derivation’ (equivalent to
> ‘guix pull’) and timed the builds of guix-packages-base.drv (279 files)
> and guix-packages.drv (217 files) on my 4-core i7 laptop:

Oh, here comes the attached patch.

Ludo’.

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index c2dc7f6d5f..2c9a9825e4 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -322,6 +322,41 @@ without requiring the source code to be rewritten.")
   `(("bdw-gc" ,libgc-7)
 ,@(srfi-1:alist-delete "bdw-gc" (package-propagated-inputs guile-3.0)))
 
+(define-public guile-devel
+  (let ((commit "e2066d2e639ecc81078e83fcd7acd8b75faf27a3")
+(revision "0"))
+   (package
+ (inherit guile-3.0)
+ (version (git-version (package-version guile-3.0)
+   revision commit))
+ (source (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://git.savannah.gnu.org/git/guile.git;)
+ (commit commit)))
+   (file-name (git-file-name "guile" version))
+   (sha256
+(base32
+ "1qipc4j2wbc2h22qsqp7n81ykclmnw8zxay06gqyaijk3nyf0bbn"
+ (arguments
+  (substitute-keyword-arguments (package-arguments guile-3.0)
+((#:phases phases '%standard-phases)
+ `(modify-phases ,phases
+(add-before 'check 'skip-failing-tests
+  (lambda _
+(setenv "XFAIL_TESTS" "test-out-of-memory")
+(delete-file "test-suite/tests/version.test")
+#t))
+ (native-inputs
+  `(("autoconf" ,autoconf)
+("automake" ,automake)
+("libtool" ,libtool)
+("flex" ,flex)
+("gettext" ,gnu-gettext)
+("texinfo" ,texinfo)
+("util-linux" ,util-linux)  ;for 'rev', used in popen.test
+,@(package-native-inputs guile-3.0))
+
 (define-public guile-3.0/fixed
   ;; A package of Guile that's rarely changed.  It is the one used in the
   ;; `base' module, and thus changing it entails a full rebuild.
@@ -776,3 +811,4 @@ manipulate repositories of the Git version control system.")
 
 ;;; guile.scm ends here
 
+
diff --git a/guix/self.scm b/guix/self.scm
index 60fe6e6b01..7449406dc5 100644
--- a/guix/self.scm
+++ b/guix/self.scm
@@ -48,7 +48,7 @@
   (let ((ref (lambda (module variable)
(module-ref (resolve-interface module) variable
 (match-lambda
-  ("guile"  (ref '(gnu packages guile) 'guile-3.0/libgc-7))
+  ("guile"  (ref '(gnu packages guile) 'guile-devel))
   ("guile-json" (ref '(gnu packages guile) 'guile-json-3))
   ("guile-ssh"  (ref '(gnu packages ssh)   'guile-ssh))
   ("guile-git"  (ref '(gnu packages guile) 'guile-git))

Re: Build reproducibility metrics

[Ludovic Courtès]

Hello!

Christopher Baines  skribis:

> I've also been writing and trying to use the Guix Build Coordinator [1]
> to build Guix packages and provide substitutes. That has got to the
> point where it's not getting stuck every day at least, and there's more
> than 80% of packages are available.
>
> 1: https://git.cbaines.net/guix/build-coordinator/about/

Well done!

> Combining that with the substitute server operated by Tobias, which has
> a pretty awesome substitute availability of over 90% for recent
> revisions, not only is there data from 4 different substitute servers to
> use in the comparison, but the proportion of packages where there isn't
> sufficient data is pretty low, below 10%.
>
> I'm currently using the data.guix-patches.cbaines.net instance of the
> Guix Data Service, you can see the package substitute availability for
> the latest revision using this URL [1], and the package reproducibility
> at this URL [2].
>
> 1: 
> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-substitute-availability
> 2: 
> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-reproducibility

That’s really good!  It’s the first time we have this good an overview
of the package reproducibility status.

> Some caution is needed when interpreting this data. It's most probably
> less up to date than what you'd get through running the guix weather or
> guix challenge commands, as it takes the Guix Data Service time to query
> the data, that querying process isn't very reliable at the moment
> either. Additionally, the "matching" percentage could easily go down if
> that output is built with a different hash in the future.
>
> While the number itself maybe isn't the most useful thing, I like that
> clicking through to the "Not matching" outputs will show a list of
> outputs which didn't build reproducibly, which is something that could
> help identify reproducibility issues to investigate and fix.

Yes, definitely.  There’s also always the option of running ‘guix
challenge’ locally.

> I think things are coming together on the substitute server side. The
> goal I have in mind for this is for users of Guix to be able to have
> greater trust in the substitutes they use, through trusting substitutes
> only if it's been built reproducibly on multiple substitute servers. It
> would be great to see work start soon on how guix as a client to
> substitute servers might be enhanced to check for reproducibility when
> fetching substitutes.

Agreed!

I think between that, the reduced bootstrap seeds, and authenticated
checkouts, we’re starting to have a good security story.

Thank you!

Ludo’.

Re: Compilation time with Guile 3.0.3-to-be

[Katherine Cox-Buday]

Ludovic Courtès  writes:

> So this part is ~2.5 times faster than before, yay!  Thank you, Andy!

I find a sense of peace working on and with Guix. It seems to me that
Guix has the fundamentals correct, and so change feels like progress and
not churn. We seem to have the right people, working on the right
things, with empathy.

Also, Andy, I appreciated the addendum in your blog post. Thanks for
your efforts towards Guile too!

-- 
Katherine

Re: [bug#41694] [PATCH] doc: cookbook: Add entry about getting substitutes through Tor.

[Ludovic Courtès]

Hi,

Brice Waegeneire  skribis:

> * doc/guix-cookbook.texi (Getting substitutes from Tor): New section.

Yay!

> +@node Getting substitutes from Tor
> +@section Getting substitutes from Tor
> +
> +@quotation Warning
> +@emph{Not all} Guix daemon's traffic will go through Tor!  Only
> +HTTP/HTTPS will get proxied; FTP, Git protocol, SSH, etc connections
> +will still go through the clearnet.  Again, this configuration isn't
> +foolproof some of your traffic won't get routed by Tor at all.  Use it
> +at your own risk.
> +@end quotation

I would suggest adding a line of intro before the warning, otherwise we
see the warning before even knowing what the section is about.  :-)

> +Guix's substitute server is available as a hidden service, if you want

I think official terminology these days is “Onion service”.

> +to use it to get your substitutes from Tor configure your system as
> +follow:
> +
> +@lisp
> +(use-modules (gnu))
> +(use-service-module base networking)
> +
> +(operating-system
> +  …
> +  (services
> +(cons
> +  (service tor-service-type
> +  (tor-configuration
> +(config-file (plain-file "tor-config"
> + "HTTPTunnelPort 127.0.0.1:9250"
> +  (modify-services %base-services
> +   (guix-service-type
 ^
Too many spaces here.

> +@example
> +# herd set-http-proxy guix-daemon http://localhost:9250
> +$ guix build --substitute-urls=https://bp7o7ckwlewr4slm.onion hello
> +@end example

To make it copy/pastable, you can remove the prompt and write it as:

  sudo herd set-http-proxy …
  guix build …

Something along these lines LGTM.

Thank you!

Ludo’.

Re: 02/04: doc: Update README to refer to the manual.

[Ludovic Courtès]

Hello!  :-)

Jan Nieuwenhuizen  skribis:

>> commit c75a80189fc19f6ff8b4c82d1d1801be6763b6d2
>> Author: Ludovic Courtès 
>> AuthorDate: Tue Jun 2 14:50:54 2020 +0200
>>
>> doc: Update README to refer to the manual.
>>
>> * README (Requirements): Refer to the manual.
>> (Installation): Update URL of the manual.
>
> Hmm, I don't like it!  Also, no rationale.

Someone reported that the list of dependencies (the Guile version in
particular) in ‘README’ was outdated.  I set out to update it and then
realized that that info was already available and up-to-date in the
manual.  Hence this patch.

>> +or by checking the 
>> [[https://guix.gnu.org/manual/en/html_node/Installation.html][web copy of 
>> the manual]].
>>  
>>  For information on installation from a Git checkout, please see the section
>>  "Building from Git" in the manual.
>
> ...but as a new potential user of a software I have often cursed the
> makers for providing "empty" READMEs that refer to documentation that is
> neither built (yet) or shipped, or needs a viewer/web browser; making it
> most convenient for them, the writers, and not for me, the reader;
> leaving me puzzled ... "So, you'd rather not have me use your software?"
>
> I'm wondering if you haven't had that experience, and how you look at
> this...

Sure.  Two things:

  1. People installing a release from a tarball have doc/guix.info
 already built.

  2. The ‘README’ also gives the URL of the on-line copy of the manual.

So I think the information is readily available.

My goal here was just to avoid having an outdated copy of parts of the
manual.

I hope that makes sense!

Ludo’.

Re: Heads-up: hard reset of the 'staging' branch

[Ludovic Courtès]

Hey,

Marius Bakke  skribis:

> Ludovic Courtès  writes:

[...]

>> To be clear, it wouldn’t just “leave a gap”: all future commits would
>> also be rejected.  The authentication code ensures that each commit is
>> signed by one of the keys authorized in its parent commit(s).  (See the
>> latest discussions at .)
>
> Indeed, sorry for being unclear.  The gap I was referring to was based
> on a hypothetical situation where we worked around this issue in
> git-authenticate.scm, similar to %commits-with-known-bad-signature.

As it turns out, ‘%commits-with-known-bad-signature’ is unused.  :-)
I’m actually reluctant to supporting it now because I don’t see how it
could be implemented without also offering a trivial way to escape
verification.

>> This is a good opportunity to remind all fellow committers of the latest
>> changes in that area, which are summarized here:
>>
>>   https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html
>>
>> Please take a look.
>>
>> SCARY WARNING:
>>
>>   When ‘guix pull’ runs that authentication code, which I hope will be
>>   the case in a few weeks, any such mistakes means that users will not
>>   be able to pull at all, so we all have to be very cautious.  If we do
>>   make a mistake, we’ll have to reset the branch to a known-good state,
>>   like you did.
>
> I am really looking forward to strong authentication in 'guix pull'.
> Sounds like a good excuse to make a new release!  :-)

Yup!

Ludo’.

Re: Heads-up: “pre-push” Git hook updated

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> So, I think make authenticate dislikes the naming I use for Git remotes,
> in particular I don't have an origin remote.
>
> → make authenticate
> Compiling Scheme modules...
> Authenticating Git checkout...
> Authenticating d68de95 to 776409c (0 commits)...
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>9 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 718:2  8 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  7 (_ #(#(#)))
>293:34  6 (_ #(#(#(#(#(#(#(#(#(#(#<…> …) …) …) …) …) …) …) …) …) …))
> In guix/progress.scm:
> 71:36  5 (call-with-progress-reporter _ _)
> In ice-9/eval.scm:
> 619:8  4 (_ #(#(#(#) # …) #))
>626:19  3 (_ #(#(#(#) # …) #))
>293:34  2 (_ #(#(#) # …))
> In git/branch.scm:
> 101:8  1 (_ _ _ _)
> In git/bindings.scm:
>  77:2  0 (raise-git-error _)
>
> git/bindings.scm:77:2: In procedure raise-git-error:
> Git error: cannot locate remote-tracking branch 'origin/keyring'
>
> make: *** [Makefile:5965: authenticate] Error 1
>
>
> I tried renaming my savannah remote to origin, and then it seemed to
> work. Any ideas?

Yeah, that’s a problem Tobias reported as well.

In  I change it to just use the local
‘keyring’ branch.  That also requires you to set things up
appropriately, but I think that’s hard to avoid no?

Ludo’.

Re: installer no longer signals success or offer reboot

[Mathieu Othacehe]

Hey,

> I can reproduce this issue on a VM, I'm currently investigating it.

Ok, found it, it's the cow-store umount bitting again. As a reminder,
once the installation is over, we need to umount the cow-store overlay
in order to be able to umount to underlying media which Guix is
installed upon.

The problem is that, some processes that run during the installation can
open store files (from the overlay) and keep them open. That's why I'm
trying to kill them before umounting the overlay.

Here the issue is that, after the cow-store is mounted, kmscon opens a
font file from the store. So I'm basically killing kmscon and hence
restarting the installation, not great.

I feel a bit stuck here, I cannot find an alternative to overlayfs and
on the other hand umounting the overlay is problematic.

Do people have some ideas here?

Thanks,

Mathieu

Re: GNU Shepherd 0.8.1 released

[Bengt Richter]

Hi Ludo, et al,

Would there be a benefit from NOT using .sig's from mirrors
while getting corresponding .tgz's from mirrors to help with traffic?

On +2020-06-03 14:48:23 +0200, Ludovic Courtès wrote:
> We are pleased to announce the GNU Shepherd version 0.8.1.  This release
> represents 16 commits by 4 people, bringing an important bug fix and
> improvements to the code.
[...]
> • Download
> 
>   Here are the compressed sources and a GPG detached signature[*]:
> https://ftp.gnu.org/gnu/shepherd/shepherd-0.8.1.tar.gz
> https://ftp.gnu.org/gnu/shepherd/shepherd-0.8.1.tar.gz.sig
> 
>   Use a mirror for higher download bandwidth:
> https://ftpmirror.gnu.org/shepherd/shepherd-0.8.1.tar.gz
> https://ftpmirror.gnu.org/shepherd/shepherd-0.8.1.tar.gz.sig
> 
>   Here are the SHA1 and SHA256 checksums:
> 
>   2964502388aa74207e6761c2ff77df69369738b0  shepherd-0.8.1.tar.gz
>   d32fe58694bb5350b5fc7285cf0ca0d9c7d24221aa5969d6c464ee3e3ac83f75  
> shepherd-0.8.1.tar.gz
> 
>   [*] Use a .sig file to verify that the corresponding file (without the
>   .sig suffix) is intact.  First, be sure to download both the .sig file
>   and the corresponding tarball.  Then, run a command like this:
> 
> gpg --verify shepherd-0.8.1.tar.gz.sig
[...]

I am wondering if downloading the .sig file from
> https://ftp.gnu.org/gnu/shepherd/shepherd-0.8.1.tar.gz.sig
(to make sure it is the latest official sig, even if mirrors haven't caught up)

and the big file from a mirror:
(to avoid overloading the official non-mirror server)
> https://ftpmirror.gnu.org/shepherd/shepherd-0.8.1.tar.gz
would be a good thing to do for server traffic, while ensuring that
I would detect a stale tar.gz if it didn't correspond to the official .sig.

Of course one would discover it if one used the sha256sums in the announcement,
but could one be fooled by gpg's accepting a valid-as-pair tgz/sig pair where
both were actually out of date?

If so, could a class of errors and potential vulns be eliminated by not 
servings .sig's
at all from mirrors? (it would be inconvenient when official server was down, 
but
not a showstopper inconvenience, since the tgz would be be mirrored and could be
validated with published sha256sum's).

-- 
Regards,
Bengt Richter

Re: Compilation time with Guile 3.0.3-to-be

[Andy Wingo]

Hi :)

On Thu 04 Jun 2020 09:50, Ludovic Courtès  writes:

> With the attached patch I’ve run ‘make as-derivation’ (equivalent to
> ‘guix pull’) and timed the builds of guix-packages-base.drv (279 files)
> and guix-packages.drv (217 files) on my 4-core i7 laptop:
>
>   • guix-packages-base.drv: 1m30s (was 4m)
>
>   • guix-packages.drv: 30s (was 1m8s)

Nice!!  Thanks for testing :-)

> For the record, the optimizations currently used in (guix build compile)
> are between the new -O0 and -O1:
>
>   (cond ((or (string-contains file "gnu/packages/")
>  (string-contains file "gnu/tests/"))
>  ;; Level 0 is good enough but partial evaluation helps preserve the
>  ;; "macro writer's bill of rights".
>  (override-option #:partial-eval? #t
>   (optimizations-for-level 0)))

Here fwiw I would use -O1.  It is basically the same as -O0 except that
it adds partial evaluation and it inlines primcalls.  If you are willing
to do partial evaluation, you are probably willing to inline primcalls
too; I think it typically leads to less code and the compilation time is
similar to -O0.

> ((string-contains file "gnu/services/")
>  ;; '-O2 -Ono-letrectify' compiles about ~20% faster than '-O2' for
>  ;; large files like gnu/services/mail.scm.
>  (override-option #:letrectify? #f
>   (optimizations-for-level 2)))

Interesting.  I think this is probably a bug of some sort that we'll
have to keep working on.

> With the new -O1, the scheme->tree-il conversion (mostly macro
> expansion) accounts for half of the build time on large files:
>
> scheme@(guile-user)> ,use(system base optimize)
> scheme@(guile-user)> ,time (compile-file "gnu/packages/python-xyz.scm" #:opts 
> (optimizations-for-level 1))
> $1 = 
> "/data/src/guile-3.0/cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix/gnu/packages/python-xyz.scm.go"
> ;; 4.154311s real time, 5.604945s run time.  2.538106s spent in GC.

Interesting data :)

Note that in 3.0.3 there is also a new phase called "lowering".  Before
a compiler from Tree-IL to language X is called, the tree-IL program is
"lowered" -- meaning canonicalized and optionally optimized.

(define (lower-exp exp env optimization-level opts)
  (let ((make-lowerer (language-lowerer (lookup-language 'tree-il
((make-lowerer optimization-level opts) exp env)))

Similarly there is an analysis pass for warnings, which runs before
lowering:

(define (analyze-exp exp env warning-level warnings)
  (let ((make-analyzer (language-analyzer (lookup-language 'tree-il
((make-analyzer warning-level warnings) exp env)))

These can be interesting to test different phases of the tree-il ->
bytecode path.

> The profile looks like this:
>
> scheme@(guile-user)> ,pr (define t (call-with-input-file  
> "gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 
> 'tree-il
> % cumulative   self 
> time   seconds seconds  procedure
>  13.16  0.45  0.40  anon #x1136458
>  10.53  0.35  0.32  ice-9/popen.scm:168:0:reap-pipes
>   7.89  0.24  0.24  anon #x1132af8
>   6.14  0.35  0.19  ice-9/boot-9.scm:3128:0:module-gensym
>   5.26  0.21  0.16  ice-9/boot-9.scm:2201:0:%load-announce
>   4.39  0.19  0.13  ice-9/psyntax.scm:749:8:search
>   3.51  0.69  0.11  ice-9/psyntax.scm:2964:6:match*
>   3.51  0.11  0.11  anon #x11334e8
>   3.51  0.11  0.11  anon #x1136428
>   2.63  0.08  0.08  anon #x113a258
>   1.75  0.05  0.05  ice-9/psyntax.scm:3017:12:$sc-dispatch
>   1.75  0.05  0.05  anon #x1139e68
>   0.88277.30  0.03  ice-9/boot-9.scm:220:5:map1
>
> It’d be great to waive the anonymity of that first lambda.  :-)

I think I just fixed it :)

> I was wondering what fraction of that time was spent running Guix macros
> (‘package’, ‘base32’, and so on), but it’s difficult to answer that
> question here.  Probably something to investigate so we can make further
> progress!

I think the reap-pipes call is a pretty bad sign, incidentally!

Cheers,

Andy

Re: installer no longer signals success or offer reboot

[Mathieu Othacehe]

Hey Ricardo,

> It worked but at the end of the installation when it prompted me to hit
> Return it did not tell me that the installation was successful and that
> I could reboot.  Instead it brought me right back to the language
> selection of the installer.

I can reproduce this issue on a VM, I'm currently investigating it.

Thanks for reporting,

Mathieu

Re: Compilation time with Guile 3.0.3-to-be

[Christopher Baines]

Ludovic Courtès  writes:

> Hello!
>
> Here’s a followup to Andy’s great blog post about the new “baseline
> compiler” that’ll be in Guile 3.0.3:
>
>   https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile
>
> With the attached patch I’ve run ‘make as-derivation’ (equivalent to
> ‘guix pull’) and timed the builds of guix-packages-base.drv (279 files)
> and guix-packages.drv (217 files) on my 4-core i7 laptop:
>
>   • guix-packages-base.drv: 1m30s (was 4m)
>
>   • guix-packages.drv: 30s (was 1m8s)
>
> So this part is ~2.5 times faster than before, yay!  Thank you, Andy!

Indeed, thanks Andy! That's an amazing speedup :D


signature.asc
Description: PGP signature

Compilation time with Guile 3.0.3-to-be

[Ludovic Courtès]

Hello!

Here’s a followup to Andy’s great blog post about the new “baseline
compiler” that’ll be in Guile 3.0.3:

  https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile

With the attached patch I’ve run ‘make as-derivation’ (equivalent to
‘guix pull’) and timed the builds of guix-packages-base.drv (279 files)
and guix-packages.drv (217 files) on my 4-core i7 laptop:

  • guix-packages-base.drv: 1m30s (was 4m)

  • guix-packages.drv: 30s (was 1m8s)

So this part is ~2.5 times faster than before, yay!  Thank you, Andy!
This is quite an achievement, especially given that, before compiling,
there’s an initial phase during which we load all the files, and that
phase is sequential and takes the same amount of time in both cases.

For the record, the optimizations currently used in (guix build compile)
are between the new -O0 and -O1:

  (cond ((or (string-contains file "gnu/packages/")
 (string-contains file "gnu/tests/"))
 ;; Level 0 is good enough but partial evaluation helps preserve the
 ;; "macro writer's bill of rights".
 (override-option #:partial-eval? #t
  (optimizations-for-level 0)))
((string-contains file "gnu/services/")
 ;; '-O2 -Ono-letrectify' compiles about ~20% faster than '-O2' for
 ;; large files like gnu/services/mail.scm.
 (override-option #:letrectify? #f
  (optimizations-for-level 2)))
(else
 (optimizations-for-level 3)))

With the new -O1, the scheme->tree-il conversion (mostly macro
expansion) accounts for half of the build time on large files:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(system base optimize)
scheme@(guile-user)> ,time (compile-file "gnu/packages/python-xyz.scm" #:opts 
(optimizations-for-level 1))
$1 = 
"/data/src/guile-3.0/cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix/gnu/packages/python-xyz.scm.go"
;; 4.154311s real time, 5.604945s run time.  2.538106s spent in GC.
--8<---cut here---end--->8---

vs.:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(system base compile)
scheme@(guile-user)> ,time (define t (call-with-input-file  
"gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 
'tree-il
;; 2.206563s real time, 3.057369s run time.  1.339261s spent in GC.
--8<---cut here---end--->8---

The profile looks like this:

--8<---cut here---start->8---
scheme@(guile-user)> ,pr (define t (call-with-input-file  
"gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 
'tree-il
% cumulative   self 
time   seconds seconds  procedure
 13.16  0.45  0.40  anon #x1136458
 10.53  0.35  0.32  ice-9/popen.scm:168:0:reap-pipes
  7.89  0.24  0.24  anon #x1132af8
  6.14  0.35  0.19  ice-9/boot-9.scm:3128:0:module-gensym
  5.26  0.21  0.16  ice-9/boot-9.scm:2201:0:%load-announce
  4.39  0.19  0.13  ice-9/psyntax.scm:749:8:search
  3.51  0.69  0.11  ice-9/psyntax.scm:2964:6:match*
  3.51  0.11  0.11  anon #x11334e8
  3.51  0.11  0.11  anon #x1136428
  2.63  0.08  0.08  anon #x113a258
  1.75  0.05  0.05  ice-9/psyntax.scm:3017:12:$sc-dispatch
  1.75  0.05  0.05  anon #x1139e68
  0.88277.30  0.03  ice-9/boot-9.scm:220:5:map1
--8<---cut here---end--->8---

It’d be great to waive the anonymity of that first lambda.  :-)
I was wondering what fraction of that time was spent running Guix macros
(‘package’, ‘base32’, and so on), but it’s difficult to answer that
question here.  Probably something to investigate so we can make further
progress!

Ludo’.

Re: Icedove package needs update, following IceCat 68.9.0 update.

[Jonathan Brielmaier]

On 03.06.20 10:44, Jonathan Brielmaier wrote:
> There is a Thunderbird 68.8.1 with only 3 patches. None of them seems to
> be security relevant. I'm working on the update. My laptop just needs
> some time to built that stuff...

I made a patch see http://issues.guix.gnu.org/issue/41701

Re: Request to verify powerpc64-linux bootstrap binaries

[Efraim Flashner]

On Mon, Jun 01, 2020 at 07:56:43PM -0700, Chris Marusich wrote:
> Hi everyone!
> 
> Thanks to Léo's help, as of commit
> 8159ce1970d91567468cf1bacac313099a009d2a, the master branch now contains
> all the changes necessary to cross-compile powerpc64-linux bootstrap
> binaries.  I've done this without substitutes by running the following
> commands on an x86_64-liinux machine.
> 
> First, to ensure you're using commit
> 8159ce1970d91567468cf1bacac313099a009d2a, put something like this in
> your ~/.config/guix/channels.scm file:
> 
> (list (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (commit
>   "8159ce1970d91567468cf1bacac313099a009d2a")))
> 
> Then, run these commands:
> 
> # Confirm you're using the right guix.
> guix describe
> # Clear as many GC roots as possible, and do a GC run.
> guix gc --delete-generations
> # Build the bootstrap tarballs without substitutes.
> guix build --no-substitutes --target=powerpc64-linux-gnu bootstrap-tarballs
> 
> After a few hours, you should see the following message:
> 
> successfully built 
> /gnu/store/icnj0m294b94pc3rhpmkz6zc41w8vyqj-bootstrap-tarballs-0.drv
> /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0
> 
> On my end, the SHA-512 hashes of the binaries are:
> 
> --8<---cut here---start->8---
> 426e5f1d0d7023a90e73286ccda1fa55a359301e998a19dfe00f5b4f5d387e69d7a247f47056f41e609393893b0238a908698fbd28d73b183b32a5dadcfe9fbb
>   binutils-static-stripped-2.34-powerpc64-linux-gnu.tar.xz
> 8aca7f332a1ba8e3c2225c161a7545b0a04ddd690d164dc97afee9c9ea067b0c49bc155e9f06d285c22e24cdd16d91e59730af5f1dd9efcda13a26bede5948a2
>   gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz
> a717a420e765accf12cfc1e18ebed76e9359ee58e8781601ca9066ced59196f88a528ddc554c0f57c77e2c01908cafe596f3c8d1df135beb4cae4073b9a999d2
>   glibc-stripped-2.31-powerpc64-linux-gnu.tar.xz
> e2e70c7fcc477fced12eb76704212f9bda0e1ec2cf40137ff6a32a85ca75fec10ec20076b73698438e48c3ce45d24542aa309bb99274f4c3d4f9d49ec9d1dd7b
>   guile-static-stripped-2.0.14-powerpc64-linux-gnu.tar.xz
> 04d9203467ecb48e9f1fca5130199c292212d4d119153778d398899aeef517fc8bce5d25f3505063f38e433fa09e3c723a6da5dee4943dbc9d3728279356879b
>   static-binaries-0-powerpc64-linux-gnu.tar.xz
> --8<---cut here---end--->8---
> 
> Hopefully, you'll get identical results!  You don't have to run "guix
> gc" if you don't want to, but doing so will increase the likelihood of
> catching nondeterminism issues propagated from dependencies (which seem
> unlikely, but you never know).  It took 3 or 4 for me hours on a modern
> 16-core machine.
> 
> Once we verify the binaries, we can actually start using them to build
> stuff!  Léo has already gotten an optimistic start on that work, and
> many things are building successfully.  Exciting!!

After 3(?) days and several reboots I built the bootstrap binaries from
an aarch64-linux machine using the commit.

(ins)efraim@pine64:~/workspace/guix$ git log -1
commit 8159ce1970d91567468cf1bacac313099a009d2a (HEAD -> master)
Author: Léo Le Bouter 
Date:   Tue May 21 05:00:30 2019 +

gnu: bootstrap: Add powerpc64-linux dynamic linker.

This makes it possible to build bootstrap binaries for powerpc64-linux:

  guix build --target=powerpc64-linux-gnu bootstrap-tarballs

* gnu/packages/bootstrap.scm (glibc-dynamic-linker): Add an entry for
powerpc64-linux.

Signed-off-by: Chris Marusich 
(ins)efraim@pine64:~/workspace/guix$ sha512sum 
/gnu/store/38zyf3y0fvi1l0bbkacwaapw5m1jmmi6-bootstrap-tarballs-0/*
426e5f1d0d7023a90e73286ccda1fa55a359301e998a19dfe00f5b4f5d387e69d7a247f47056f41e609393893b0238a908698fbd28d73b183b32a5dadcfe9fbb
  
/gnu/store/38zyf3y0fvi1l0bbkacwaapw5m1jmmi6-bootstrap-tarballs-0/binutils-static-stripped-2.34-powerpc64-linux-gnu.tar.xz
74ac175b22f9964cefbcc94c8589e14fac1ae2c98879f84d40faa352aa9dd108e7ba631e6b35cceae263507d0cc956f31c49af686c1e60850b97c51878bf533d
  
/gnu/store/38zyf3y0fvi1l0bbkacwaapw5m1jmmi6-bootstrap-tarballs-0/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz
0693dc1a0c85ab23ec2f8bbb89a8819c384d50a8830297d0900d6caa94f75c67bbb6f300d182f855e8e6c88810caf1f183e9b24cda574c470dc129641dac1258
  
/gnu/store/38zyf3y0fvi1l0bbkacwaapw5m1jmmi6-bootstrap-tarballs-0/glibc-stripped-2.31-powerpc64-linux-gnu.tar.xz
e2e70c7fcc477fced12eb76704212f9bda0e1ec2cf40137ff6a32a85ca75fec10ec20076b73698438e48c3ce45d24542aa309bb99274f4c3d4f9d49ec9d1dd7b
  
/gnu/store/38zyf3y0fvi1l0bbkacwaapw5m1jmmi6-bootstrap-tarballs-0/guile-static-stripped-2.0.14-powerpc64-linux-gnu.tar.xz
04d9203467ecb48e9f1fca5130199c292212d4d119153778d398899aeef517fc8bce5d25f3505063f38e433fa09e3c723a6da5dee4943dbc9d3728279356879b
  
/gnu/store/38zyf3y0fvi1l0bbkacwaapw5m1jmmi6-bootstrap-tarballs-0/static-binaries-0-powerpc64-linux-gnu.tar.xz

my gcc-stripped tarball should be available at
https://flashner.co.il/~efraim/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz


-- 
Efraim