Re: 01/01: gnu: mit-scheme: Update to 10.1.3.

[Mark H Weaver]

Hi Kei,

guix-comm...@gnu.org writes:

> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit d870cc5e8acfed6fee318a66c3ffc7244aa376a1
> Author: Kei Kebreau 
> Date:   Thu Dec 13 08:32:50 2018 -0500
>
> gnu: mit-scheme: Update to 10.1.3.
> 
> * gnu/packages/scheme.scm (mit-scheme): Update to 10.1.3.
> [arguments]: Update 'unpack', 'configure-doc', and 'install-doc' phases
> accordingly.
> [supported-systems]: Limit to i686-linux and x86_64-linux.

[...]

> @@ -177,24 +171,21 @@
>  ("x86_64-linux"
>   (string-append version "-x86-64"))
>  ("i686-linux"
> - (string-append version "-i386"))
> -(_
> - (string-append "c-" version)))
> + (string-append version "-i386")))
>".tar.gz"))
>(sha256
> (match (%current-system)
>   ("x86_64-linux"
>(base32
> -   "1skzxxhr0iq96bf0j5m7mvf3i4sppfyfa6gpqn34mwgkw1fx8274"))
> +   "03m7cc035w3avs91j2pcz9f15ssgvgp3rm045d1vbydqrkzfyw8k"))
>   ("i686-linux"
>(base32
> -   "1fmlpnhf5a75db93phajh4ysbdgrgl72v45lk3kznriprl0a7jc6"))
> - (_
> -  (base32
> -   "0w5ib5vsidihb4hb6fma3sp596ykr8izagm57axvgd6lqzwicsjg"
> +   "05sjyz90xxfnmi87qv8x0yx0fcallnzl1dciygdafp317pn489is"

Without the fallback cases in these 'match' forms, this package
definition raises an exception when asked to generate the derivation on
non-Intel systems.  Ludovic partly reverted your changes here:

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

This commit also broke the 'guix' package on armhf-linux, and probably
on other non-Intel systems as well,

  https://hydra.gnu.org/build/3281991

although admittedly I found this surprising.

>  ;; Fails to build on MIPS, see .
> -(supported-systems '("x86_64-linux" "i686-linux" "armhf-linux"))
> +;; Also, the portable C version of MIT/GNU Scheme did not work in time 
> for
> +;; release in version 10.1.
> +(supported-systems '("x86_64-linux" "i686-linux"))

In general, please do not remove a system from 'supported-systems'
unless there is good reason to believe that it would be prohibitively
difficult to support the package on that system.  If there is merely a
bug or some minor unfinished work that prevents a package from building
on a given system, that is not sufficient grounds to remove it from
'supported-systems'.

   Thanks,
 Mark

Re: CDN performance

[Mark H Weaver]

Hi Giovanni,

Giovanni Biscuolo  writes:
> with a solid infrastructure of "scientifically" trustable build farms,
> there are no reasons not to trust substitutes servers (this implies
> working towards 100% reproducibility of GuixSD)

What does "scientifically trustable" mean?

  Mark

Re: Coq native-inputs: Useless hevea / texlive?

[Mark H Weaver]

Julien Lepiller  writes:

> They must have been useful in older versions, but I didn't pay
> attention. If they are not needed for anything, please go ahead and
> remove them!

Although I sometimes use Coq, I don't know much about the Guix packaging
for it, so I'm glad to trust your judgment on this.  Do as you think
best.

  Thanks!
Mark


> Le 13 décembre 2018 22:20:15 GMT+01:00, Pierre Neidhardt  
> a écrit :
>>Hevea and texlive are native-inputs for Coq, however they don't seem to
>>be used ever.
>>
>>https://github.com/coq/coq/blob/V8.8.2/INSTALL does not mention them as
>>build dependencies either.
>>
>>Shall we remove them?

Re: French translation of manual

[zimoun]

Bonsoir Julien,

Voilà un premier tiers avec quelques coquilles que j'ai trouvé.
Comme je n'ai pas encore recu pour traduc.org, voilà un patch (contre
bd208a13e).

Je remarque que parfois c'est pré-requis et parfois prérequis.
Y-a-t-il une préférence ?

D'ailleurs, est-ce que c'est sur guix-devel que l'on discute de choix
de traduction ou sur traduc.org ?

Comme par exemple, ces mots que mon dictionnaire avec aspell n'a pas reconnnu:
incrémental
formater
formatage
indente
indenter
accesseurs
instantiera
triplet ou triplé?
gérable
enveloppage
conceptuellement
ciblé
internalisés

le féminin de standard: standarde ?

monad ou monade ?


Bien  toi,
simon
diff --git a/po/doc/guix-manual.fr.po b/po/doc/guix-manual.fr.po
index 3faeed8ee..10d48488e 100644
--- a/po/doc/guix-manual.fr.po
+++ b/po/doc/guix-manual.fr.po
@@ -8,7 +8,7 @@ msgstr ""
 "Project-Id-Version: guix-manual 0.16.0.1\n"
 "Report-Msgid-Bugs-To: l...@gnu.org\n"
 "POT-Creation-Date: 2018-11-28 22:35+0100\n"
-"PO-Revision-Date: 2018-12-02 12:30+0100\n"
+"PO-Revision-Date: 2018-12-14 23:40+0100\n"
 "Last-Translator: Julien Lepiller \n"
 "Language-Team: French \n"
 "Language: fr\n"
@@ -240,7 +240,7 @@ msgstr "Ensuite, lancez @command{./configure} comme d'habitude.  Assurez-vous de
 #. type: Plain text
 #: doc/contributing.texi:100
 msgid "Finally, you have to invoke @code{make check} to run tests (@pxref{Running the Test Suite}).  If anything fails, take a look at installation instructions (@pxref{Installation})  or send a message to the @email{guix-devel@@gnu.org, mailing list}."
-msgstr "Finalement, vous devez invoquer @code{make check} pour lancer les tests (@pxref{Lancer la suite de tests}).  Si quelque chose échoue, jetez un œil aux instructions d'installation (@pxref{Installation}) ou envoyez un message à la list @email{guix-devel@@gnu.org}."
+msgstr "Finalement, vous devez invoquer @code{make check} pour lancer les tests (@pxref{Lancer la suite de tests}).  Si quelque chose échoue, jetez un œil aux instructions d'installation (@pxref{Installation}) ou envoyez un message à la liste @email{guix-devel@@gnu.org}."
 
 #. type: Plain text
 #: doc/contributing.texi:109
@@ -684,7 +684,7 @@ msgstr "entre 300 et 1 200 paquets dépendants"
 #. type: table
 #: doc/contributing.texi:407
 msgid "@code{staging} branch (non-disruptive changes).  This branch is intended to be merged in @code{master} every 3 weeks or so.  Topical changes (e.g., an update of the GNOME stack) can instead go to a specific branch (say, @code{gnome-updates})."
-msgstr "branche @code{staging} (changemets non-disruptifs).  Cette branche devrait être fusionnées dans @code{master} tous les 3 semaines.  Les changements par thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une branche spécifique (disons, @code{gnome-updates})."
+msgstr "branche @code{staging} (changements non-disruptifs).  Cette branche devrait être fusionnées dans @code{master} tous les 3 semaines.  Les changements par thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une branche spécifique (disons, @code{gnome-updates})."
 
 #. type: item
 #: doc/contributing.texi:408
@@ -863,7 +863,7 @@ msgstr "guix package : (guix.fr)Invoquer guix package"
 #. type: menuentry
 #: doc/guix.texi:73
 msgid "Installing, removing, and upgrading packages."
-msgstr "Intaller, supprimer et mettre à jour des paquets."
+msgstr "Installer, supprimer et mettre à jour des paquets."
 
 #. type: menuentry
 #: doc/guix.texi:73
@@ -1343,7 +1343,7 @@ msgstr "Authentification des substituts"
 #. type: menuentry
 #: doc/guix.texi:168 doc/guix.texi:2323
 msgid "How Guix verifies substitutes."
-msgstr "Coment Guix vérifie les substituts."
+msgstr "Comment Guix vérifie les substituts."
 
 #. type: subsection
 #: doc/guix.texi:168 doc/guix.texi:2323 doc/guix.texi:2463 doc/guix.texi:2464
@@ -2111,7 +2111,7 @@ msgstr "Services réseau"
 #. type: menuentry
 #: doc/guix.texi:278 doc/guix.texi:10706
 msgid "Network setup, SSH daemon, etc."
-msgstr "Paramétres réseau, démon SSH, etc."
+msgstr "Paramètres réseau, démon SSH, etc."
 
 #. type: subsubsection
 #: doc/guix.texi:278 doc/guix.texi:10706 doc/guix.texi:12645
@@ -2679,7 +2679,7 @@ msgstr "script d'installation"
 #. type: Plain text
 #: doc/guix.texi:436
 msgid "This section describes how to install Guix on an arbitrary system from a self-contained tarball providing binaries for Guix and for all its dependencies.  This is often quicker than installing from source, which is described in the next sections.  The only requirement is to have GNU@tie{}tar and Xz."
-msgstr "Cette section décrit comment intaller Guix sur un système quelconque depuis un archive autonome qui fournit les binaires pour Guix et toutes ses dépendances.  C'est souvent plus rapide que d'installer depuis les sources, ce qui est décrit dans les sections suivantes.  Le seul pré-requis est d'avoir GNU@tie{}tar et Xz."
+msgstr "Cette section décrit comment installer Guix sur un système quelconque depuis 

Re: 16/16: doc: Discourage the use of texlive as input

[Pierre Neidhardt]

> The text looks fine but I find it a bit long and m

Yeah, it  can probably be worked out a bit :p

> more importantly it
> partly duplicates an item that’s just above :-), which mentions ‘guix
> size’ but not ‘texlive’.

Just above?  Do you mean this one:

--8<---cut here---start->8---
Take a look at the profile reported by @command{guix size}
(@pxref{Invoking guix size}).  This will allow you to notice references
to other packages unwillingly retained.  It may also help determine
whether to split the package (@pxref{Packages with Multiple Outputs}),
and which optional dependencies should be used.
--8<---cut here---end--->8---

True, they should be merged, but in my opinion the existing paragraph is not
explicit enough about the size, despite mentioning the "guix size" command.

> Perhaps a ‘lint’ checker warning about ‘texlive’ as an input would be
> more appropriate?  WDYT?

Maybe, but we should keep in mind that we still don't have a proper texlive
build system, and it can be really hard to build a minimal texlive-union.  So if
someone cannot figure out the minimal union, then the linter will inevitably
flag the package.

> In general I think it’s a good idea to discuss changes to the guidelines
> beforehand, as per ‘HACKING’.

Yup, I went a bit out of my way here, sorry, long and painful day fighting
TeXlive...

Conclusion: I'll just add a mention of TeXlive in the existing paragraph then.

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


signature.asc
Description: PGP signature

Re: 16/16: doc: Discourage the use of texlive as input

[Ludovic Courtès]

Hi Pierre!

guix-comm...@gnu.org skribis:

> commit dc56dc025df0b7ea6915ad1061f8d189d641fe35
> Author: Pierre Neidhardt 
> Date:   Fri Dec 14 23:06:06 2018 +0100
>
> doc: Discourage the use of texlive as input
> 
> * doc/contributing.texi (Submitting Patches): Discourage the use of 
> texlive as
>   input.
> ---
>  doc/contributing.texi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index c55eb63..9f705d2 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -477,6 +477,16 @@ often better to clone the repository.  Don't use the 
> @command{name} field in
>  the URL: it is not very useful and if the name changes, the URL will probably
>  be wrong.
>  
> +@item
> +Try to minimize the weight of the inputs to make the transitive closure as
> +small as possible (@pxref{Invoking guix size}).  Use @command{native-inputs}
> +and @command{inputs} appropriately.  It's sometimes sufficient to use the
> +@command{-minimal} version of a package as input, e.g. @command{bash-minimal}
> +instead of @command{bash}.  In particular, avoid adding @command{texlive} as 
> a
> +dependency: because of its extreme size, it's both heavy on the build farms
> +and on the users who would like to build or hack the package from source.  
> Use
> +@command{texlive-tiny} or @command{texlive-union} instead.

The text looks fine but I find it a bit long and more importantly it
partly duplicates an item that’s just above :-), which mentions ‘guix
size’ but not ‘texlive’.

So I’d rather not add this item because it shows that this section is
already too long to be read.

Perhaps a ‘lint’ checker warning about ‘texlive’ as an input would be
more appropriate?  WDYT?

In general I think it’s a good idea to discuss changes to the guidelines
beforehand, as per ‘HACKING’.

Anyway thanks for all the latest TeX Live improvements.  It’s great you
managed to replace all these ‘texlive’ dependencies with
‘texlive-union’!

Ludo’.

Re: Preparing the reduced bootstrap tarballs, take 3

[Mark H Weaver]

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Jan Nieuwenhuizen  skribis:
>>>
 Ludovic Courtès writes:

 Hi!

> I’ve just uploaded these to
> :
>
>   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz.sig
>   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz
>   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz.sig
>   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz
>   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz.sig

 Great!

> Could you adjust bootstrap.scm to refer to this URL?  Currently I see
> bootstrap.scm refers to a different version of
> linux-libre-headers-stripped so it should be the only one whose hash
> needs to be changed.

 I don't see that...and the hash matches.
>>>
>>> We’ve discussed it in person, and now I think we’re all set!  :-)
>>
>> Does our documentation include instructions on how to reproducibly build
>> these new bootstrap binaries, to independently verify them?
>
> The build procedure remains unchanged (info "(guix) Bootstrapping"):
>
>   guix build bootstrap-tarballs
>
> To verify them, you can do what I described in this thread, which is to
> use the same commit as Janneke and myself used, run “guix build
> bootstrap-tarballs”, and compare the three tarballs listed above.

What commit did you use?  It would be good to document this, so that
others can independently verify our bootstrap binaries, now or in the
future.

 Thanks,
   Mark

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Andreas,

can you check whether dirindex (hashtables for directory) is enabled?

# tune2fs -l /dev/... | grep -o dir_index

See also 
https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html


pgp6PbcZAEg70.pgp
Description: OpenPGP digital signature

[GWL] (random) next steps?

[zimoun]

Dear Guixers,
... or at least some of them :-)

Here, I would like to collect some discussions or ideas about the Guix
Workflow Language (GWL) and the next steps of this awesome tool!

For those who do not know.
About workflow language, Wikipedia says:
https://en.wikipedia.org/wiki/Scientific_workflow_system

About GWL, basically the idea is to apply Guix functional principles
to data processing. More details here:
https://www.guixwl.org/
Roel Janssen is the original author of the GWL and now the project is
part of GNU.


Well, I narrow the Ludo's notes from the Paris' meeting and add
commentaries as it was suggested. :-)

** HPC, “workflows”, and all that

  - overview & status
  - supporting “the cloud”
+ service that produces Docker/Singularity images
+ todo: produce layered Docker images like Nix folks
  - workflows
+ snakemake doesn’t handle software deployment
  + or does so through Docker
+ GWL = workflow + deployment
  + add support for Docker
  + add “recency” checks
  + data storage: IRODS?
  - Docker arguments
+ security: handling patient data with untrusted “:latest” images
+ Guix allows for “bisect”


1.
Even if I am not a big fan of WISP because I remember difficulties to
catch "parenthesis closing" issue last time I tried, now I am fan of
what Ricardo showed!
Let push out the wisp-way of GWL... or not. :-)

What are the opinions ?

(pa (ren (the (sis

vs

pa:
  ren:
the:
  sis

With wisp, the workflow description seems close to CWL, which is an argument ;-)
Last time, I check, CWL files seems flat yaml-like files and they lack
programmable extension; as Snakemake provides with Python for example.
And GWL-wisp will have both: easy syntax and programmable stuff,
because it is still lisp under the hood.

https://www.draketo.de/proj/wisp/
https://www.commonwl.org/
https://snakemake.readthedocs.io/en/stable/getting_started/examples.html


2.
One of the lacking feature of GWL is kind-of content addressable store
(CAS) for data. Another workflow language named FunFlow (baked as
Haskell-DSL) implements such kind of ideas. To quote explanations by
Ricardo: "we could copy for the GWL (thus avoiding the need for
recency checks).  The GWL lacks a data provenance story and a CAS
could fit the bill."

https://github.com/tweag/funflow


3.
The project OpenMole about parametric explorations seems implementing
an IPFS way to deal with the data. Not sure what does it mean. :-)

https://openmole.org/

Talking about data, Zenodo is always around. ;-)
https://zenodo.org/


4.
Some GWL scripts are already there.
Could we centralize them to one repo?
Even if they are not clean. I mean something in this flavor:
https://github.com/common-workflow-language/workflows


5.
I recently have discovered the ELisp package `s.el` via the blog post:
http://kitchingroup.cheme.cmu.edu/blog/2018/05/14/f-strings-in-emacs-lisp/
or other said:
https://github.com/alphapapa/elexandria/blob/master/elexandria.el#L224

Does it appear to you a right path to write a "formater" in this
flavour instead of the `string-append` ?
I mean, e.g.,
  `(system ,(string-command "gzip  ${data-inputs}  -c >  ${outputs}"))
instead of e.g.,
  `(system ,(string-append "gzip " data-inputs " -c > " outputs))

It seems more on the flavour of  Snakemake.


6.
The graph of dependencies between the processes/units/rules is written
by hand. What should be the best strategy to capture it ? By files "à
la" Snakemake ? Other ?


7.
Does it appear to you a good idea to provide a command `guix workflow pack` ?
to produce an archive with the binaries or the commit hashes of the
channels, etc.



Last, the webpage [1] points to gwl-devel mailing list which seems broken.
Does the gwl-devel need to be activated and the GWL discussion will
append there or everything stay here to not scattered too much.

[1] https://www.guixwl.org/community



What do you think?
What is do-able? Science-fiction dream?


Thank you.

Have a nice week-end,
simon

--

Then, just pointers/threads (that I am aware of) to remind what the
list already discussed.

https://lists.gnu.org/archive/html/help-guix/2016-02/msg00019.html
https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00380.html
https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00947.html
https://lists.gnu.org/archive/html/guix-devel/2016-10/msg01248.html
https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00371.html
https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00177.html
https://lists.gnu.org/archive/html/help-guix/2018-05/msg00241.html

Re: 01/01: python: Honor '--cores=...' in tests.

[Eric Bavier]

On Fri, 14 Dec 2018 15:50:37 +
Christopher Baines  wrote:

> Christopher Baines  writes:
> 
> > Eric Bavier  writes:
> >  
> >> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> >> index 2b6a064..46ce0dd 100644
> >> --- a/gnu/packages/python.scm
> >> +++ b/gnu/packages/python.scm
> >> @@ -190,6 +190,9 @@
> >>   "--enable-unicode=ucs4"
> >>   (string-append "LDFLAGS=-Wl,-rpath="
> >>  (assoc-ref %outputs "out") "/lib"))
> >> +   ;; With no -j argument tests use all available cpus, so provide 
> >> one.
> >> +   #:make-flags
> >> +   (list (format #f "EXTRATESTOPTS=-j~d" (parallel-job-count)))
> >>  
> >>  #:modules ((ice-9 ftw) (ice-9 match)
> >> (guix build utils) (guix build gnu-build-system))  
> >
> > Hi Eric,
> >
> > I'm having trouble building the python2 package on core-updates (which
> > was renamed from core-updates-next), and I think it relates to this
> > change.
> >
> > This is roughly the issue I'm seeing:
> >
> >   LD_LIBRARY_PATH=/tmp/guix-build-python2-2.7.15.drv-0/Python-2.7.15 
> > ./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -l -j12
> >
> >   -l and -j don't go together!
> >
> >
> > Since all the python packages look to inherit from python-2.7 that's
> > being changed here, perhaps this worked for some of them (I know you
> > mentioned python-minimal in one message), but not all of them, or at
> > least python2?  
> 
> Just got around to testing this, moving this change to python-3.7, from
> python-2.7 fixes the python-2.7 build for me, but I haven't checked
> how that affects how many cores are actually used when running the tests.

Strange.  I recall testing this patch on both python2 and python.  Not
sure what has changed since then.

`~Eric


pgp0ehqxO5Pcs.pgp
Description: OpenPGP digital signature

Re: 01/01: python: Honor '--cores=...' in tests.

[Christopher Baines]

Christopher Baines  writes:

> Eric Bavier  writes:
>
>> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
>> index 2b6a064..46ce0dd 100644
>> --- a/gnu/packages/python.scm
>> +++ b/gnu/packages/python.scm
>> @@ -190,6 +190,9 @@
>>   "--enable-unicode=ucs4"
>>   (string-append "LDFLAGS=-Wl,-rpath="
>>  (assoc-ref %outputs "out") "/lib"))
>> +   ;; With no -j argument tests use all available cpus, so provide one.
>> +   #:make-flags
>> +   (list (format #f "EXTRATESTOPTS=-j~d" (parallel-job-count)))
>>  
>>  #:modules ((ice-9 ftw) (ice-9 match)
>> (guix build utils) (guix build gnu-build-system))
>
> Hi Eric,
>
> I'm having trouble building the python2 package on core-updates (which
> was renamed from core-updates-next), and I think it relates to this
> change.
>
> This is roughly the issue I'm seeing:
>
>   LD_LIBRARY_PATH=/tmp/guix-build-python2-2.7.15.drv-0/Python-2.7.15 ./python 
> -Wd -3 -E -tt  ./Lib/test/regrtest.py -l -j12
>
>   -l and -j don't go together!
>
>
> Since all the python packages look to inherit from python-2.7 that's
> being changed here, perhaps this worked for some of them (I know you
> mentioned python-minimal in one message), but not all of them, or at
> least python2?

Just got around to testing this, moving this change to python-3.7, from
python-2.7 fixes the python-2.7 build for me, but I haven't checked
how that affects how many cores are actually used when running the tests.


signature.asc
Description: PGP signature

Fwd: Re: quicklisp importer?

[swedebugia]

Hi people

All details needed to create an importer should be available below.

Pierre asked off-list:
> Swedebugia, would you like to give it a shot?  I can help of course.

Yes :) I will look into it, this seems easier now that I already learned 
to handle git and branches and also studied the pypi- and npm-importers.

:D

Cheers
swedebugia

 Forwarded Message 
Subject:Re: quicklisp importer?
Date:   Tue, 11 Dec 2018 06:05:56 -0800
From:   Zach Beane 
To: swedebu...@riseup.net
CC: m...@ambrevar.xyz





On Mon, Dec 10, 2018 at 11:04 PM > wrote:


Hi Zach

Thank you! What a nice simple API (compared to what we deal with in
other importers).

On 2018-12-11 04:24, Zach Beane wrote:
 > One option is to start from here:
 >
 > https://beta.quicklisp.org/dist/quicklisp.txt
 >
 > From there, go to the release-index-url value, e.g.
 > https://beta.quicklisp.org/dist/quicklisp/2018-12-10/releases.txt

This looks very good.

Are the tarballs static or regenerated sometimes?
Is the old tarballs for earlier releases available?


Tarballs are static and are never changed or deleted.

quicklisp.txt is updated periodically to point to new dist indexes. 
https://beta.quicklisp.org/dist/quicklisp-versions.txt has a list of 
active dist versions.



file-md5 content-sha1 is the two file hashes.

We strictly need sha256 because of the way the /gnu/store is 
implemented

in Nix/Guix.
Could you add that as an additional hash in the next release?


Look at digests.txt alongside releases.txt.

Are all build time and run time dependencies?


Build time. Foreign libraries are not listed, sorry - and there are many 
that are required. I collect the data but do not currently publish it.


Zach

 > On Mon, Dec 10, 2018 at 4:41 PM mailto:swedebu...@riseup.net>> wrote:
 >
 >> Hi
 >>
 >> I work on the guix project.
 >>
 >> We have importers for semi-automatic importing of packages from
 >> pypi,
 >> CRAN, etc.
 >>
 >> We currently lack a quicklisp importer.
 >>
 >> Would it be possible for you to help me understand the API or
 >> structure
 >> of Quicklisp Beta and the paths to files?
 >>
 >> Is there a list of packages somewhere?
 >>
 >> How can I map a package name to the newest version to the path for
 >> the
 >> tarball?
 >>
 >> Cheers
 >> swedebugia
 >>
 >>  Original Message 
 >> Subject: Re: quicklisp importer?
 >> Date: 2018-12-11 00:10
 >> From: Pierre Neidhardt mailto:m...@ambrevar.xyz>>
 >> To: swedebu...@riseup.net 
 >> Cc: guix-devel mailto:guix-devel@gnu.org>>
 >>
 >> Nope, Andy Patterson had some plans about it, but as far as I know,
 >> nothing has
 >> been done yet.
 >>
 >> I'd be very interested by a recursive importer as well! :)
 >>
 >> --
 >> Cheers
 >> Swedebugia

-- Cheers
Swedebugia

Re: 01/01: python: Honor '--cores=...' in tests.

[Christopher Baines]

Eric Bavier  writes:

> bavier pushed a commit to branch core-updates-next
> in repository guix.
>
> commit 5b01b6034aeab32a5011c5757f18bd9772d3497d
> Author: Eric Bavier 
> Date:   Thu Nov 1 21:18:41 2018 -0500
>
> python: Honor '--cores=...' in tests.
> 
> * gnu/packages/python.scm (python-2.7)[arguments]: Add #:make-flags.
> ---
>  gnu/packages/python.scm | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 2b6a064..46ce0dd 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -190,6 +190,9 @@
>   "--enable-unicode=ucs4"
>   (string-append "LDFLAGS=-Wl,-rpath="
>  (assoc-ref %outputs "out") "/lib"))
> +   ;; With no -j argument tests use all available cpus, so provide one.
> +   #:make-flags
> +   (list (format #f "EXTRATESTOPTS=-j~d" (parallel-job-count)))
>  
>  #:modules ((ice-9 ftw) (ice-9 match)
> (guix build utils) (guix build gnu-build-system))

Hi Eric,

I'm having trouble building the python2 package on core-updates (which
was renamed from core-updates-next), and I think it relates to this
change.

This is roughly the issue I'm seeing:

  LD_LIBRARY_PATH=/tmp/guix-build-python2-2.7.15.drv-0/Python-2.7.15 ./python 
-Wd -3 -E -tt  ./Lib/test/regrtest.py -l -j12

  -l and -j don't go together!


Since all the python packages look to inherit from python-2.7 that's
being changed here, perhaps this worked for some of them (I know you
mentioned python-minimal in one message), but not all of them, or at
least python2?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Compressing nars with lzip or similar

[Pierre Neidhardt]

Absolutely, but once the bindings are up and running, it should be
straightforward to update (guix scripts substitute), no?

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


signature.asc
Description: PGP signature

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> go-ipfs is fine indeed, but that's because you've just looked at the lucky
> package!  go-ipfs vendors all the Go dependencies, which is why there is no
> extra input there and go-ipfs closure size is optimal.

Oh, we should really work towards unbundling things from ‘go-ipfs’.  Any
idea how difficult that would be?

> Now try with gx, demlo or syncthing: all of them had zero Go inputs in their
> closure with go-1.9.  Now they have hundreds with go-1.11 :(

“guix size syncthing”, for instance, returns mostly tiny Go packages,
which looks good to me, no?

Anyway, if you think there’s a problem, could you email details to
bug-g...@gnu.org so we keep track of it there?

Thanks!

Ludo’.

Compressing nars with lzip or similar

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Talking about this, I recently discussed with Ludovic the idea of compressing
> nars in Lzip instead of gzip.
>
> http://lzip.nongnu.org/lzip.html (benchmark included)
>
> I can work on some Lzip guile-bindings, it should be quite easy, then we could
> save some 10-50% (!!!) disk usage.

That would be sweet!

Though we have to keep in mind that today’s ‘guix substitute’ doesn’t
know about lzip at all (see (guix scripts substitute) and
‘call-with-decompressed-port’.)  So while lzip would be my preference,
we may not be able to use it until we can be sure our users can actually
unpack it.

Ludo’.

Re: Using a CDN or some other mirror?

[Ludovic Courtès]

Hello,

Hartmut Goebel  skribis:

> Am 09.12.2018 um 14:58 schrieb Ludovic Courtès:
>>> I could try and ask a few organizations in my area, but I would need
>>> figures for this.
>> What would you need to know?  ‘guix weather’ can provide info about
>> storage size.
>
> I don't know yet, which info the admins need for a decision. FMPOV I'd
> says: Disk-space and traffic to be expected.
>
> `guix weather` only provides the disk-space, but even this is not
> obvious for me:
>
>   13912.1 MiB of nars (compressed)
>   41176.6 MiB on disk (uncompressed)
>
> From reading the manual, I assume 13.9 GB are required on the server
> (which is quite a lot IMHO). Is this correct?

If you’re running a caching proxy, you’ll need 13G.  However note that
it’s only for one architecture and one revision of Guix.  The total
space needed is obviously a function of time (number of Guix revisions
served) and number of architectures.

You could choose an expiration time in your caching proxy that satisfies
your disk space constraints, though.

Our machines that run Cuirass + ‘guix publish --cache’ need roughly
41+13G since they contain both /gnu/store and /var/cache/guix/publish.

HTH!

Ludo’.

Re: GNU Guix & GuixSD 0.16.0 released

[Giovanni Biscuolo]

Hi!

Ludovic Courtès  writes:

> Pjotr Prins  skribis:
>
>> Yesterday I gave a passionate 'I love Guix' lightning talk about Guix
>> packages at the biohackathon in Japan. Many people after approached me
>> and said that the website is confusing them because it looks like it
>> is promoting a Linux distribution... I know this is an old topic, but
>> it would be nice if we found a way to promote Guix packaging as it
>> works so well outside GuixSD.
>
> Yes, that should be a nice side-effect of calling everything “Guix”.

does this mean that "guix system" is capable of
instantiating/reconfiguring an operating-system declaration (services
included) even outside GuixSD?

AFAIK for this we need Sheperd as PID 1 and I do not know how I can get
it on a systemd based (or any other different PID 1) distro

do we need a FAQ on https://www.gnu.org/software/guix/, the first may be
"What is the difference between GuixSD and Guix"?

thanks!
Gio

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

failed to compute the derivation for Guix, host version: "0.16.0-3.6ddc63e"

[Giovanni Biscuolo]

Hi,

today I made a guix pull on a test machine (probably I messed up
something?), from root account using this command:

--8<---cut here---start->8---
root@guixsdtest ~# time guix pull --dry-run > guix-pull.log 2>&1

real16m6.518s
user3m6.573s
sys 0m6.606s
--8<---cut here---end--->8---

it took quite a lot, I expected this to be much more quick due to
--dry-run

anyway the (very long) guix-pull.log ends with:

--8<---cut here---start->8---
srfi/srfi-1.scm:592:17: In procedure map1:
Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/bmbjmh64xk6hr632balpfllfs0v7768i-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"adb158b7396cbdcda347fa298978408e531a03fd"; system: "x86_64-linux";
host version: "0.16.0-3.6ddc63e"; pull-version: 1).
Please report it by email to .
--8<---cut here---end--->8---

I have two questions:

1. am I wrong or "guix pull --dry-run" is not supposed tu build
anything?

2. is it really useful I report this to bug-guix or it's just a spuriuos
bug due to something I could have messed up?

thanks!
Gio

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Using a CDN or some other mirror?

[Chris Marusich]

Hi Giovanni,

Thank you for sharing some data with us!

Giovanni Biscuolo  writes:

> measures from my office network: Italy, 20Km north Milan, FTTC
> (90Mbit/sec measured bandwidth)
>
> measure from Berlin:
>
> url_effective: 
> https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
>   http_code: 200
>   num_connects: 1
>   num_redirects: 0
>   remote_ip: 141.80.181.40
>   remote_port: 443
>   size_download: 69899433 B
>   speed_download: 9051388,000 B/s

That's about 72 megabits per second.

>   time_appconnect: 0,229271 s
>   time_connect: 0,110443 s
>   time_namelookup: 0,061754 s

Latency was about 49 milliseconds (after the name lookup).

>   [...]
> latency measured with mtr:
>
> HOST: roquette  Loss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 10.38.2.1  0.0%100.3   0.4   0.3   0.4   0.0
>
> [...]
>
>  18.|-- 141.80.181.40  0.0%10  112.5  77.1  55.6 201.7  47.1
>
>
>
> from your mirror (third download):
>
> url_effective: 
> https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
>   http_code: 200
>   num_connects: 1
>   num_redirects: 0
>   remote_ip: 54.230.102.61
>   remote_port: 443
>   size_download: 69899433 B
>   speed_download: 9702091,000 B/s

That's about 78 megabits per second, which is 8% more than 72.

>   time_appconnect: 0,172660 s
>   time_connect: 0,037833 s
>   time_namelookup: 0,003772 s

Latency was 34 milliseconds, which is 31% less than 49.

>   [...]
>
> latency measured with mtr:
>
> HOST: roquette   Loss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 10.38.2.1   0.0%100.4   0.4   0.4   0.4   0.0
>
> [...]
>
>  11.|-- ???100.0100.0   0.0   0.0   0.0   0.0
>  12.|-- ???100.0100.0   0.0   0.0   0.0   0.0
>  13.|-- ???100.0100.0   0.0   0.0   0.0   0.0
>  14.|-- ???100.0100.0   0.0   0.0   0.0   0.0
>  15.|-- 52.93.58.1900.0%10   36.1  34.6  32.9  37.1   1.2
>  16.|-- ???100.0100.0   0.0   0.0   0.0   0.0
>
> 100% loss?

Yes, mtr's output here is a bit surprising.

On my end, also, mtr reported similar "loss" for intermediate hops, but
in my case the final hop did not report any loss.  Deprioritization of
ICMP traffic is common in many networks, so tools like mtr and
traceroute will sometimes report surprisingly high latency or packet
loss even when the network is just fine.

The mechanism used by tools like mtr and traceroute is to repeatedly
send "probes" with monotonically increasing TTL values.  The measurement
(even when using TCP probes) relies on (1) intermediate hops correctly
returning an ICMP "time exceeded" message when the packet lands on that
hop and the TTL expires, and (2) the ICMP "time exceeded" message
getting successfully delivered back to the mtr process.

In any case, the "100% loss" metric is clearly inaccurate, since you
successfully downloaded the file at an impressive speed.  If a hop were
truly dropping 100% of the traffic, the download would have failed.  In
addition, the latency that mtr does report seems comparable to the
latency calculated from the measure_get output (which is not influenced
by the vagaries of ICMP deprioritization).

> from here it seems Berlin is as performant as CloudFront

Yes, it seems you are already well connected to the build farm!  But
still, when you used CloudFront, your throughput went up by 7%, and your
latency went down by 31%.  Even more importantly, when you downloaded
the file from CloudFront, it placed zero additional load on the build
farm because it was served from CloudFront's cache.

Again, thank you for sharing!  This is useful information.

-- 
Chris


signature.asc
Description: PGP signature

Re: Gash and Geesh together at last

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> Timothy Sample  skribis:
>
>> I am very happy to announce that Gash and Geesh are merging into a
>> single project.  Jan and I discussed this earlier today, and decided
>> that the time has come.  We worked out a list of goodies from each
>> project that we should be able to zip together into an even greater
>> whole.
>
> I’m really happy you found a rough path towards a merged project!  The
> three of you have been doing awesome work and I’m sure the merged
> project will be even more impressive.

Thanks, yes I'm very happy too!  We'll first have to create a rough
merger, then make it really work and hopefully also chat about a path
forward.  I think Gash and Geesh had slightly different priorities in
their goals but I am sure that will work out perfectly.

> This is an important milestone in our quest to reduce bootstrap
> binaries!

Indeed, I have been experimenting somewhat with Gash on the
wip-bootstrap branch in an attempt to remove coreutils and am now
blocked for missing functionality.

Once we have this merger in place I suspect we may see a lot of progress
on the Scheme-only bootstrap front :-)

janneke

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

Re: Preparing the reduced bootstrap tarballs, take 3

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> Does our documentation include instructions on how to reproducibly build
>> these new bootstrap binaries, to independently verify them?
>
> The build procedure remains unchanged (info "(guix) Bootstrapping"):
>
>   guix build bootstrap-tarballs
>
> To verify them, you can do what I described in this thread, which is to
> use the same commit as Janneke and myself used, run “guix build
> bootstrap-tarballs”, and compare the three tarballs listed above.

Note however that while you're very welcome to do so now, Ricardo and
are working on at least a new mes-minimal-stripped-tarball that I
expect any day now.

janneke

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

Re: GC Warning: Out of Memory

[Manolis Ragkousis]

Hello Ludo,

On 12/14/18 1:02 PM, Ludovic Courtès wrote:
> You must be using a personal branch, no?  It seems that ‘master’ cannot
> be used natively on GNU/Hurd because we lack binaries under
> gnu/packages/bootstrap/i586-gnu:
> 
> --8<---cut here---start->8---
> $ guix build hello -s i586-gnu -n
> guix build: error: could not find bootstrap binary 'tar' for system 'i586-gnu'
> --8<---cut here---end--->8---
> 
> Manolis, I suppose we could cross-compile ‘bootstrap-tarballs’ to

Rene is using a personal branch based with modification based on the
guix-hurd work.

Rene are you still using the binaries I had provided?

Theoretically we could do that. But unfortunately 1) the Guix to Hurd
cross-compilation support breaks faster that I can keep up trying to fix
2) even when we get the binaries we will definitely have issues with the
initial tool-chain.

Can the current master build `guix build --target=i586-pc-gnu
bootstrap-tarballs` ?

Manolis

ENOSPC upon offloading

[Ludovic Courtès]

Hello,

Danny Milosavljevic  skribis:

> I've tried it now and I get:
>
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image 
> --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory 
> '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for 
> '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device
> cannot build derivation 
> `/gnu/store/mdc6h56cg0a8i09rh0zbw5kgipwlnvln-binutils-cr
> oss-boot0-2.31.1.drv': 1 dependencies couldn't be built

I looked again at the code and found the issue, now fixed in
adb158b7396cbdcda347fa298978408e531a03fd.

We’ll have to update the ‘guix’ package and deploy it to actually get
the fix.

Thanks,
Ludo’.

Re: Gash and Geesh together at last

[Ludovic Courtès]

Hi Timothy!

Timothy Sample  skribis:

> I am very happy to announce that Gash and Geesh are merging into a
> single project.  Jan and I discussed this earlier today, and decided
> that the time has come.  We worked out a list of goodies from each
> project that we should be able to zip together into an even greater
> whole.

I’m really happy you found a rough path towards a merged project!  The
three of you have been doing awesome work and I’m sure the merged
project will be even more impressive.

This is an important milestone in our quest to reduce bootstrap
binaries!

Thank you,
Ludo’.

Re: GC Warning: Out of Memory

[Ludovic Courtès]

Hi Rene,

Rene  skribis:

> $ ./pre-inst-env guix build hello -n --verbosity=100
> ...
> madvise failed: Function not implemented
> madvise failed: Function not implemented
> GC Warning: Failed to expand heap by 8388608 bytes
> GC Warning: Failed to expand heap by 2097152 bytes
> GC Warning: Out of Memory! Heap size: 113 MiB. Returning NULL!
> Warning: Unwind-only `out-of-memory' exception; skipping pre-unwind handler.
> madvise failed: Function not implemented
>
> And it does not create any file in `/tmp`.
>
> The error is similar to the one reported[1], but in 2017; Any idea about if 
> it is the same situation?
>
> Thank you
>
>
> Environment:
> * guix (GNU Guix) 0.16.0.112-46e61 (master branch)
> * Debian/Hurd
> * guile (GNU Guile) 2.2.4

You must be using a personal branch, no?  It seems that ‘master’ cannot
be used natively on GNU/Hurd because we lack binaries under
gnu/packages/bootstrap/i586-gnu:

--8<---cut here---start->8---
$ guix build hello -s i586-gnu -n
guix build: error: could not find bootstrap binary 'tar' for system 'i586-gnu'
--8<---cut here---end--->8---

Manolis, I suppose we could cross-compile ‘bootstrap-tarballs’ to
i586-pc-gnu and get the mkdir, tar, etc. files from there?

Thanks,
Ludo’.

Re: French translation of manual

[Ludovic Courtès]

Salut Simon !

The top of the manual at

contains instructions on how to join Julien on this cool endeavor.

Bonne traduction !  :-)

Ludo’.

Re: Preparing the reduced bootstrap tarballs, take 3

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> Ludovic Courtès  writes:
>
>> Jan Nieuwenhuizen  skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>> Hi!
>>>
 I’ve just uploaded these to
 :

   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz.sig
   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz
   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz.sig
   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz
   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz.sig
>>>
>>> Great!
>>>
 Could you adjust bootstrap.scm to refer to this URL?  Currently I see
 bootstrap.scm refers to a different version of
 linux-libre-headers-stripped so it should be the only one whose hash
 needs to be changed.
>>>
>>> I don't see that...and the hash matches.
>>
>> We’ve discussed it in person, and now I think we’re all set!  :-)
>
> Does our documentation include instructions on how to reproducibly build
> these new bootstrap binaries, to independently verify them?

The build procedure remains unchanged (info "(guix) Bootstrapping"):

  guix build bootstrap-tarballs

To verify them, you can do what I described in this thread, which is to
use the same commit as Janneke and myself used, run “guix build
bootstrap-tarballs”, and compare the three tarballs listed above.

Ludo’.

Re: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hello!

Danny Milosavljevic  skribis:

> Ye!
>
> flash-image just successfully built on Hydra.
>
> Can I have the resulting file please?
>
> See https://hydra.gnu.org/build/3255541/log/raw

I believe you can download it by running:

  guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

If you don’t have this .drv, you should be able to build it from commit
cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

See all the details at .

Ludo’.

Re: Video of Talk: "Everyday Use of GNU Guix"

[Ludovic Courtès]

Chris Marusich  skribis:

> Chris Marusich  writes:
>
>> Hi Ludo,
>>
>> Ludovic Courtès  writes:
>>
>>> Chris, if you want you can push a .md file to guix-artwork.git with a
>>> link to the video (for example similar to
>>> )
>>> and I can do the CVS dance to upload it if you want.  :-)
>>
>> Sounds good!  I'll let you know once I've done that.
>
> I've added a small retrospective post in guix-artwork, commit
> 4ba6b7c042ff04c89ffdd6d5b7ba91f620f40d44.  I've verified it looks good,
> and the links are correct, on my local machine.  (The link to the PDF
> didn't work locally, but I think it will work when published.)  Could
> you check it, and then do the CVS dance if it looks good to you?

I pushed it on-line yesterday I think.  Thank you!

Ludo’.

Re: CDN performance

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> Ludovic Courtès  writes:


[...]

> Judging by that email thread, one of the reasons why Debian considered
> using a CDN was because they felt that the cost, in terms of people
> power, of maintaining their own "proto-CDN" infrastructure had grown too
> great.  I believe it!  I think it would be ill-advised for the Guix
> project to expend effort and capital on building and maintaining its own
> CDN.  I think it would be wiser to focus on developing a decentralized
> substitute solution (GNUnet, IPFS, etc.).
>
> That said, I still think that today Guix should provide a third-party
> CDN option.  For many Guix users, a CDN would improve performance and
> availability of substitutes.  Contracting with a third party to provide
> the CDN service would require much less effort and capital than building
> and maintaining a CDN from scratch.  This would also enable the project
> to focus more on building a decentralized substitute solution.  And once
> that decentralized solution is ready, it will be easy to just "turn off"
> the CDN.
>
> I also understand Hartmut's concerns.  The risks he points out are
> valid.  Because of those risks, even if we make a third-party CDN option
> available, some people will choose not to use it.  For that reason, we
> should not require Guix users to use a third-party CDN, just as we do
> not require them to use substitutes from our build farm.
>
> However, not everyone shares the same threat model.  For example,
> although some people choose not to trust substitutes from our build
> farm, still others do.  The choice is based on one's own individual
> situation.  Similarly, if we make a third-party CDN option available and
> explain the risks of using it, Guix users will be able to make an
> educated decision for themselves about whether or not to use it.

That summarizes the situation very well.

In Paris, there was consensus on two things: that a CDN would be helpful
for performance and availability (though availability could suddenly be
worse if we run… out of money), and that it raises privacy concerns.

Based on this, some suggested having a way to opt out of the CDN
distribution: for example, we might make ci.guix.info point to the CDN
and also advertise berlin.guixsd.org as a way to bypass it.

Of course in parallel we want to do our best to develop decentralized
solutions.

> However, I believe you when you say that it's slow the first time you
> download the substitute from berlin.  What path does the data take from
> its origin through berlin?  If berlin needs to download the initial file
> from another server, perhaps the connection between berlin and that
> server is the bottleneck?  Maybe we should discuss that in a different
> email thread, though.

On the first hit, nginx fetches the file from ‘guix publish’, which is
also on berlin.  ‘guix publish’ gets the file from local storage and
passes it with sendfile(2), so it’s as fast as can be.

Thanks for the info!

Ludo’.

guix.gnu.org sub-domain

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Ludovic Courtès  writes:
>
>> Regarding the GNU sub-domain, as I replied to Meiyo, I’m in favor of it,
>> all we need is someone to champion setting it up.
>
> I could help with this.  Whom should I contact?

We discussed this over the last few days in Paris and Julien (roptat on
IRC) volunteered to come up with a Knot service setup for bayfront.scm.
When that’s ready, we can contact the FSF sysadmins so they delegate to
bayfront.

I’m sure Julien wouldn’t mind getting some help or insight, so please do
get in touch!

Ludo’.

Re: GNU Guix & GuixSD 0.16.0 released

[Ludovic Courtès]

Hi!

Pjotr Prins  skribis:

> Yesterday I gave a passionate 'I love Guix' lightning talk about Guix
> packages at the biohackathon in Japan. Many people after approached me
> and said that the website is confusing them because it looks like it
> is promoting a Linux distribution... I know this is an old topic, but
> it would be nice if we found a way to promote Guix packaging as it
> works so well outside GuixSD.

Yes, that should be a nice side-effect of calling everything “Guix”.

Ludo’.

Re: Guix & IPFS

[Pierre Neidhardt]

Ludo and Me have played with it at the Reproducible Build summit, and it works
quite well indeed!

Ludo is working Guile bindings.

I'll implement the service later, but I'd really like to get the first contract
money first.  Alicia told me there were some issues with the University because
they issue the payment on a monthly basis or something.  Alicia is working out a
solution, but that's a pity I've got to wait this long :(

Anyways, have fun with IPFS! :)

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


signature.asc
Description: PGP signature

Re: Guix & IPFS

[Pjotr Prins]

IPFS is working like a charm. Thanks Pierre a.o!

Pj.

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

[Ludovic Courtès]

Hello!

Pierre Neidhardt  skribis:

> I've investigated the possible solutions to avoid including the paths into the
> binaries.
>
> I've found this:
>
> https://github.com/golang/go/issues/16860
>
> It's still unresolved and only planned for Go 1.13.
>
> In the meantime, I've played with the -trimpath option to see if I could get
> something out of it.
>
> I've added this to Go's (build) function:
>
>   "-asmflags=all=-trimpath=/gnu/store"
>   "-gcflags=all=-trimpath=/gnu/store"
>
> The resulting binary is indeed trimmed, but that's not enough: it seems that
> Guix detects the remaining part of the path as a store item and includes it in
> the list of requisites.  Is this really how Guix works?  It does not need the
> full path?

No, the scanner just looks for the hash part of the store file name (see
‘scanForReferences’ in nix/libstore/references.cc).

How much of a problem is this though?  Currently the set of references
looks reasonable:

--8<---cut here---start->8---
$ guix size go-ipfs
store item   totalself
/gnu/store/rm3cfgzd8iywjmsdcxf6gnwswm5za50x-go-ipfs-0.4.18 203.4   
102.2  50.2%
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28  37.8
36.3  17.8%
/gnu/store/ypiv8dj4lkvsnm82s639h18l87frrh5g-gcc-6.5.0-lib   69.0
31.2  15.3%
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib   68.0
30.2  14.8%
/gnu/store/8g2wi0i5fgp0ylz99mckhprh25p1zgiv-tzdata-2018e 2.0 
2.0   1.0%
/gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23   1.5 
1.5   0.8%
/gnu/store/sj8m05bfj2902h67c4qkmvnzg2pjdgsv-net-base-5.3 0.0 
0.0   0.0%
total: 203.4 MiB
--8<---cut here---end--->8---

Well OK we could do with a single gcc:lib :-), but other than that it
looks good.

Thoughts?

Ludo’.

Re: 01/01: hydra: Increase image sizes for USB image and Flash image.

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> On Wed, Dec 12, 2018 at 09:17:23AM +0100, Giovanni Biscuolo wrote:
>> > I’m in favour of moving them elsewhere, such as %desktop-services.
>>
>> yes please: sound related services are not-so-base, we do not need them
>> on installation/web/mail/DNS et. al servers (and containers) and it does
>> not makes much sense to remove them an all that class of
>> hosts/containers
>> 
>> it makes sense - semantically speaking - to move sound to
>> %desktop-services since we only need sound on desktops
>  
> I would prefer if sound services were removed from the installation
> system rather than from the %base-services. I am using systems based on
> %base-services for music playback and other audio work. They are not
> desktop systems — there is no graphical interface to these machines.

Yeah I do that as well.

On closer inspection my initial diagnostic was not accurate: the ALSA
udev rules are not in the installation system itself:

--8<---cut here---start->8---
scheme@(gnu system install)> (define s (operating-system-services 
installation-os))
scheme@(gnu system install)> (fold-services s #:target-type udev-service-type)
$3 = #< type: # value: 
#< udev: # rules: (# 
#)>>
--8<---cut here---end--->8---

Instead, the ALSA rules come from the bare-bones OS, which we
purposefully add as a GC root of the installation OS (see commit
4e854b1814a9216ae7cc90aef4d82fd989a519c3).

So I suppose there’s not much we can do in this area.

The good news is that there are other optimization opportunities.  :-)

--8<---cut here---start->8---
$ guix size $(guix system build gnu/system/install.scm) | head -10
store item   totalself
/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6 236.5   
236.5  21.2%
/gnu/store/mdw00a2sq0qqyzqygmp9035g8r2rlslj-guix-0.15.0-8.71a78ba   345.7   
182.3  16.3%
/gnu/store/1lcniyxkxkh8g73zvh2gpbccvl6ggna7-locale-2.28 91.8
91.8   8.2%
/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0146.3
58.2   5.2%
/gnu/store/ybglr7nfs8v9kpnm8vf4drg3gafnvd15-guile-static-stripped-2.2.445.9 
   45.9   4.1%
/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4121.9
44.4   4.0%
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4121.9
44.4   4.0%
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28  37.8
36.3   3.2%
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib   68.0
30.2   2.7%
--8<---cut here---end--->8---

Ludo’.

Re: Using a CDN or some other mirror?

[Pierre Neidhardt]

Talking about this, I recently discussed with Ludovic the idea of compressing
nars in Lzip instead of gzip.

http://lzip.nongnu.org/lzip.html (benchmark included)

I can work on some Lzip guile-bindings, it should be quite easy, then we could
save some 10-50% (!!!) disk usage.

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


signature.asc
Description: PGP signature

Re: Using a CDN or some other mirror?

[Hartmut Goebel]

Am 09.12.2018 um 14:58 schrieb Ludovic Courtès:
>> I could try and ask a few organizations in my area, but I would need
>> figures for this.
> What would you need to know?  ‘guix weather’ can provide info about
> storage size.

I don't know yet, which info the admins need for a decision. FMPOV I'd
says: Disk-space and traffic to be expected.

`guix weather` only provides the disk-space, but even this is not
obvious for me:

  13912.1 MiB of nars (compressed)
  41176.6 MiB on disk (uncompressed)

From reading the manual, I assume 13.9 GB are required on the server
(which is quite a lot IMHO). Is this correct?

-- 
+++hartmut

| Hartmut Goebel|   |
| hart...@goebel-consult.de | www.goebel-consult.de |