Re: ISO-9660 image working and ready

[Adam Van Ymeren]

Danny Milosavljevic  writes:

> Hi Ludo,
>
> On Mon, 17 Jul 2017 15:41:26 +0200
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> Would you like to update the ‘release’ Makefile.am target as well as
>> “System Installation” in guix.texi to reflect that?
>
> Sure, but if possible, let's make sure that the image is tested in all
> cases first.  I hope someone tests the image on a real EFI computer
> again.  (It works in qemu - but with the complexity of the EFI
> specification and all I'd rather someone burned it to DVD and tried to
> boot from it)

No luck booting the prodced guixsd.iso burned to a DVD on my UEFI
system.  It does boot fine if I disable UEFI boot.

That being said, it's possible that my system just doesn't supporting
booting from DVDs in UEFI mode.  I'm going to try to rule that out by
finding some other iso reported to work on UEFI systems.

Re: npm (mitigation)

[Mike Gerwitz]

On Mon, Jul 17, 2017 at 11:45:29 +0200, Catonano wrote:
>  in my idea I would have build a database withh conditions for being non
> free forr every npm package.
>
> So we could have queried the database for questions like: is there any non
> free or non buildable package in the dependency tree of, say, the current
> Jquery ?

Being able to query the graph for non-free dependencies is good,
yes.  My concern is developing a (reasonably) fool-proof system for
detecting those packages that doesn't require manual verification, which
would be extremely costly, outside of a reasonable randomly-chosen set.

I'm not saying it's impossible; it's just difficult with such wildly
varying standards and carelessness with regards to licensing that is
prominent in the JS community.

But we have to start somewhere, so anything you can come up with would
be good. :)

> You might remember my post of a few months back about an attempt of mine to
> crawl thhe npm registry and storing data found there.

I do---I'm sorry if there are details that I missed or should know; I
haven't been able to follow this too closely.  I can be a bit of a
parrot sometimes with certain issues. :x

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com


signature.asc
Description: PGP signature

Re: 02/04: gnu: Add Poly/ML.

[Andy Patterson]

Hi Mark,

On Mon, 17 Jul 2017 12:01:33 -0400
Mark H Weaver  wrote:

> l...@gnu.org (Ludovic Courtès) writes:
> 
> > civodul pushed a commit to branch master
> > in repository guix.
> >
> > commit 9b7ee28d5700b47ae34bd47c32d250f042fbdbbd
> > Author: Andy Patterson 
> > Date:   Sat Jul 15 18:17:25 2017 -0400
> >
> > gnu: Add Poly/ML.
> > 
> > * gnu/packages/sml.scm: New file.
> > * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.  
> 
> Thank you for this!  I've become interested in some projects that
> require Poly/ML, notably CakeML and Milawa/Jitawa which are based on
> HOL4 and apparently require Poly/ML.  Now I can play with those
> things :)
> 
> > +   (modify-phases %standard-phases
> > + (add-after 'build 'build-compiler
> > +   (lambda* (#:key make-flags parallel-build?
> > #:allow-other-keys)
> > + (define flags
> > +   (if parallel-build?
> > +   (cons (format #f "-j~d" (parallel-job-count))
> > + make-flags)
> > +   make-flags))
> > + (apply system* "make" (append flags (list
> > "compiler"  
> 
> This is not quite right.  Phase procedures return a boolean value to
> indicate success or failure.  'system*' returns a numeric status code.
> All numbers are treated as true by Scheme, so this will fail to detect
> errors.  By our usual conventions, we would replace the final
> expression above with:
> 
>   (zero? (apply system* "make" (append flags (list "compiler"
> 

Oh yeah; whoops. Appending a patch to fix that.
 
> > +(home-page "http://www.polyml.org/;)
> > +(synopsis "Standard ML implementation")
> > +(description "Poly/ML is a Standard ML implementation.  It is
> > fully +compatible with the ML97 standard.  It includes a thread
> > library, a foreign +function interface, and a symbolic debugger.")  
> 
> It might be worth mentioning that Poly/ML cannot be bootstrapped from
> source code, and includes a precompiled version of itself, or at least
> that's my understanding.

Hmm, I worked on this because I wanted to have a non-bootstrapped sml.
I looked all over the place for binaries and I didn't find any. I guess
we could just ask?

> 
> Anyway, thanks again for this contribution.
> 
>Mark

As for your building issues - I didn't experience any issues so I'm
not sure what to suggest. I'm not familiar with the project. Maybe we
need to turn off parallel builds or tests?

Thanks,

--
Andy

From 2505b5806e6a1cb88947dc253bd0f22ce5ce9fe1 Mon Sep 17 00:00:00 2001
From: Andy Patterson 
Date: Mon, 17 Jul 2017 20:51:52 -0400
Subject: [PATCH] gnu: polyml: Ensure that the compiler is built.

* gnu/packages/sml.scm (polyml)[arguments]<#:phases>: Check the return code of
"make compiler" in the 'build-compiler phase.
---
 gnu/packages/sml.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/sml.scm b/gnu/packages/sml.scm
index 6e57c4a4a..088109465 100644
--- a/gnu/packages/sml.scm
+++ b/gnu/packages/sml.scm
@@ -60,7 +60,8 @@
(cons (format #f "-j~d" (parallel-job-count))
  make-flags)
make-flags))
- (apply system* "make" (append flags (list "compiler"
+ (zero?
+  (apply system* "make" (append flags (list "compiler")
 (home-page "http://www.polyml.org/;)
 (synopsis "Standard ML implementation")
 (description "Poly/ML is a Standard ML implementation.  It is fully
-- 
2.13.2

Re: Fun question: has anyone tried secure boot with GuixSD?

[Adonay Felipe Nogueira]

Thanks for asking others to leave the "Microsoft-phobia" aside. This is
important because we must replace our (organization/brand)-based view
with a per (product/project/model/work)-based view, because exclusively
for-profit organizations aren't always in favor of the free/libre
software movement (according to
[[https://k7r.eu/there-is-no-free-software-company-but/]] and
[[https://media.libreplanet.org/u/libreplanet/m/libreplanet-2016-the-last-lighthouse-3d51/]]).

Before anyone else jumps at us, it's important to note the difference
between "Secure Boot" and "Restricted Boot". Basically, the first one
allows the user himself to manage (add/remove/modify) any keys or trust
levels he wants to, while the second doesn't
([[https://media.libreplanet.org/u/libby/m/embracing-secure-boot-and-rejecting-restricted-boot-matthew-garrett/]]).

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

collaboration from students of a technical school

[Quiliro Ordonez Baca]

I spoke with the director of a technical school (small universtity) that
offers degrees in computer science. He said he could establish collaboration in
free software projects as part of the syllabus for the students. I could ask
them to contribute to Guix.
What tasks should I ask them to do? They
must collaborate between 80, 120 and 800 hours before graduating,
depending on their area of study. There are students of languages
too. Perhaps they can add the descriptions to the packages. Maybe
editorial contributions to the manual or contributing to the
translations.  Descriptions could indeed be translated:
LANG=fr_FR.utf-8 guix package --show=hello

We could also ask them to have a hydra mirror or another server for
Guix.

It would be nice to have a list of TODO tasks...with knowledge
dependencies specified in order to have them done by contributors. I
think that easy tasks are a great way to help motivate people to learn
more in order to contribute with the harder tasks later. Is there a
place where tasks are described?

Fun question: has anyone tried secure boot with GuixSD?

[ng0]

Following some interesting points I got during a discussion we had
(offline), I have some questions for multiple projects. One of the
topics is "Secure Boot".

Apparently I missed the point with my hardware and systems where Secure
Boot practically became mandatory and default. Which was a long time
ago as I learned today.

As you know or don't know I'm working towards a system based on GuixSD
where one of its scenarios and configurations is to be used from an USB
disk (think 'TAILS' big sister).
I'm about to ask the secure-os mailinglist about how they handle the
Secure Boot (ie: Microsoft) case with their systems.
For us (as in us->Guix) I pose the questions:
- has someone tried this?
- would it technically be possible given the (un/likely) case we get
  Microsoft to cooperate (leaving aside the techno-ethical points for
  this question)?

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org


signature.asc
Description: PGP signature

Re: core-updates summer 2017

[Leo Famulari]

On Mon, Jul 17, 2017 at 03:26:06PM +0200, Ludovic Courtès wrote:
> It looks like the initrd is still running Guile 2.0 but getting 2.2
> modules.
> 
> This should be fixed with this patch, which I haven’t been able to test
> yet:

> diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
> index 844b110eb..ecd019a94 100644
> --- a/gnu/packages/make-bootstrap.scm
> +++ b/gnu/packages/make-bootstrap.scm
> @@ -504,21 +504,21 @@ for `sh' in $PATH, and without nscd, and with static 
> NSS modules."
>(let* ((patches (cons* (search-patch "guile-relocatable.patch")
>   (search-patch "guile-default-utf8.patch")

'guile-default-utf8.patch' needs to be adjusted (or dropped? not sure)
for Guile 2.2.

My naive attempt (attached) doesn't work. At the end of building a
package, or perhaps after it's built, Guix prints 'uncaught exception'
and seems to hang forever.
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 844b110eb..ecd019a94 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -504,21 +504,21 @@ for `sh' in $PATH, and without nscd, and with static NSS 
modules."
   (let* ((patches (cons* (search-patch "guile-relocatable.patch")
  (search-patch "guile-default-utf8.patch")
  (search-patch "guile-linux-syscalls.patch")
- (origin-patches (package-source guile-2.0
- (source  (origin (inherit (package-source guile-2.0))
+ (origin-patches (package-source guile-2.2
+ (source  (origin (inherit (package-source guile-2.2))
 (patches patches)))
- (guile (package (inherit guile-2.0)
-  (name (string-append (package-name guile-2.0) "-static"))
+ (guile (package (inherit guile-2.2)
+  (name (string-append (package-name guile-2.2) "-static"))
   (source source)
   (synopsis "Statically-linked and relocatable Guile")
 
   ;; Remove the 'debug' output (see above for the reason.)
-  (outputs (delete "debug" (package-outputs guile-2.0)))
+  (outputs (delete "debug" (package-outputs guile-2.2)))
 
   (propagated-inputs
`(("bdw-gc" ,libgc)
  ,@(alist-delete "bdw-gc"
- (package-propagated-inputs guile-2.0
+ (package-propagated-inputs guile-2.2
   (arguments
`(;; When `configure' checks for ltdl availability, it
  ;; doesn't try to link using libtool, and thus fails
@@ -534,7 +534,7 @@ for `sh' in $PATH, and without nscd, and with static NSS 
modules."
(("^guile_LDFLAGS =")
 "guile_LDFLAGS = -all-static")
 
-   ;; Add `-ldl' *after* libguile-2.0.la.
+   ;; Add `-ldl' *after* libguile-2.2.la.
(("^guile_LDADD =(.*)$" _ ldadd)
 (string-append "guile_LDADD = "
(string-trim-right ldadd)
diff --git a/gnu/packages/patches/guile-default-utf8.patch 
b/gnu/packages/patches/guile-default-utf8.patch
index 22771324f..f03aaaffe 100644
--- a/gnu/packages/patches/guile-default-utf8.patch
+++ b/gnu/packages/patches/guile-default-utf8.patch
@@ -16,28 +16,6 @@ index cf41f2f..facfb91 100644
   iconveh_question_mark, NULL,   \
   _utf, _utf_len);   \
if (SCM_UNLIKELY (err))   \
-diff --git a/libguile/ports.c b/libguile/ports.c
-index 301bc44..b0ea2e6 100644
 a/libguile/ports.c
-+++ b/libguile/ports.c
-@@ -1750,7 +1750,7 @@ scm_ungetc (scm_t_wchar c, SCM port)
-   if (pt->encoding != NULL)
- encoding = pt->encoding;
-   else
--encoding = "ISO-8859-1";
-+encoding = "UTF-8";
- 
-   len = sizeof (result_buf);
-   result = u32_conv_to_encoding (encoding,
-@@ -2212,7 +2212,7 @@ scm_i_set_port_encoding_x (SCM port, const char 
*encoding)
-   pt = SCM_PTAB_ENTRY (port);
- 
-   if (encoding == NULL)
--encoding = "ISO-8859-1";
-+encoding = "UTF-8";
- 
-   if (pt->encoding != encoding)
- pt->encoding = scm_gc_strdup (encoding, "port");
 diff --git a/libguile/posix.c b/libguile/posix.c
 index 4f8b8ac..fea7f74 100644
 --- a/libguile/posix.c
@@ -68,33 +46,6 @@ diff --git a/libguile/strings.c b/libguile/strings.c
 index 5d0db23..8266247 100644
 --- a/libguile/strings.c
 +++ b/libguile/strings.c
-@@ -1576,7 +1576,7 @@ scm_from_locale_string (const char *str)
- SCM
- scm_from_locale_stringn (const char *str, size_t len)
- {
--  return scm_from_stringn (str, len, locale_charset (),
-+  

Re: Automatically detect other OSs and generate grub entries

[Arun Isaac]

Ludovic Courtès writes:

> Arun Isaac  skribis:
>
>> Instead of having to manually specify custom grub entries in config.scm,
>> can Guix use os-prober to automatically detect other operating system
>> and generate grub entries?
>>
>> https://joeyh.name/code/os-prober/
>
> I think there is value in having everything in the GuixSD config, which
> can then be put under version control.
>
> Now, I have a single OS on my machines so I’m probably not part of the
> target audience.  :-)
>
> Thoughts?

I too now only have a single OS. So, I don't really need this feature
either. But, I do think we should offer an user experience as close as
possible to other distros. Hence, I think automatic os detection and
grub generation is worthwile. It's nice to have the grub work
automagically out of the box.

Also, I noticed that custom grub entries are a problem for the proposed
"guix system delete-generations"

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00194.html

Would automatic grub generation solve, or at least alleviate, this
problem?

Re: ISO-9660 image working and ready

[Adam Van Ymeren]

On July 17, 2017 1:54:49 PM EDT, Danny Milosavljevic  
wrote:
>
>Sure, but if possible, let's make sure that the image is tested in all
>cases first.  I hope someone tests the image on a real EFI computer
>again.  (It works in qemu - but with the complexity of the EFI
>specification and all I'd rather someone burned it to DVD and tried to
>boot from it)

I will try to test it on a real EFI system tonight.

Re: ISO-9660 image working and ready

[Danny Milosavljevic]

Hi Ludo,

On Mon, 17 Jul 2017 15:41:26 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Would you like to update the ‘release’ Makefile.am target as well as
> “System Installation” in guix.texi to reflect that?

Sure, but if possible, let's make sure that the image is tested in all cases 
first.  I hope someone tests the image on a real EFI computer again.  (It works 
in qemu - but with the complexity of the EFI specification and all I'd rather 
someone burned it to DVD and tried to boot from it)

Then something like the following?

diff --git a/Makefile.am b/Makefile.am
index 4d1512f8c..1d4364bce 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -632,14 +632,15 @@ release: dist
  image=`$(top_builddir)/pre-inst-env   
\
guix system disk-image  
\
 --system=$$system  
\
+--file-system-type=iso9660 
 \
gnu/system/install.scm` ;   
\
  if [ ! -f "$$image" ] ; then  
\
echo "failed to produced GuixSD installation image for $$system" 
>&2 ;  \
exit 1 ;
\
  fi ;  
\
- xz < "$$image" > "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz.tmp" 
;   \
+ xz < "$$image"/guixsd.iso > 
"$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz.tmp" ;\
  mv "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz.tmp"   
\
-"$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz" ; 
\
+"$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.iso.xz" ; 
\
done
for system in $(GUIXSD_VM_SYSTEMS) ; do 
\
  image=`$(top_builddir)/pre-inst-env   
\

Re: Automatically detect other OSs and generate grub entries

[Amirouche Boubekki]

On Mon, Jul 17, 2017 at 3:39 PM Ludovic Courtès  wrote:

> Arun Isaac  skribis:
>
> > Instead of having to manually specify custom grub entries in config.scm,
> > can Guix use os-prober to automatically detect other operating system
> > and generate grub entries?
> >
> > https://joeyh.name/code/os-prober/
>
> I think there is value in having everything in the GuixSD config, which
> can then be put under version control.
>
> Now, I have a single OS on my machines so I’m probably not part of the
> target audience.  :-)
>
> Thoughts?
>

My understanding is that os-probe could generate part of GuixSD config.


>
> Ludo’.
>
>

Re: 02/04: gnu: Add Poly/ML.

[Mark H Weaver]

Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> civodul pushed a commit to branch master
>> in repository guix.
>>
>> commit 9b7ee28d5700b47ae34bd47c32d250f042fbdbbd
>> Author: Andy Patterson 
>> Date:   Sat Jul 15 18:17:25 2017 -0400
>>
>> gnu: Add Poly/ML.
>> 
>> * gnu/packages/sml.scm: New file.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
>
> Thank you for this!  I've become interested in some projects that
> require Poly/ML, notably CakeML and Milawa/Jitawa which are based on
> HOL4 and apparently require Poly/ML.  Now I can play with those things :)

I attempted to build it a second time, mainly to add '--keep-failed' to
the guix build options.  It failed again but in a different place:

--8<---cut here---start->8---
Making InitialiseCore
Created structure InitialiseCore
Making MOTIF_SIG
Making XM_TYPES
Making MOTIF_TYPES
Created signature MOTIF_TYPES
Created signature XM_TYPES
Created signature MOTIF_SIG
Created structure Motif
/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash ./libtool  
--tag=CC   --mode=link gcc   -Wall -fno-strict-aliasing -O3-o poly  
polyexport.o  libpolymain/libpolymain.la libpolyml/libpolyml.la  -lpthread 
-lffi -lgmp -lXm -lXt -lX11 -lm -ldl -lstdc++ -lgcc_s -lgcc
libtool: link: gcc -Wall -fno-strict-aliasing -O3 -o poly polyexport.o  
libpolymain/.libs/libpolymain.a 
-L/gnu/store/wfy8pwxjbyc9033sqb1snyfla3h8d02p-libice-1.0.9/lib 
-L/gnu/store/6z06w9zfnq3zcr50vcv2wvzr5wpzvy7l-util-linux-2.29.2/lib 
-L/gnu/store/gdx6vk579px16dgv60hgrr1c2k1pwsni-libx11-1.6.5/lib 
-L/gnu/store/w5b3db8y2rq3d73b30m4c5z0ql270r9a-libsm-1.2.2/lib 
-L/gnu/store/fpbm0nvl2zi4jksm22kr1mq3hfw79xdn-libxcb-1.12/lib 
-L/gnu/store/dr4qfgqmcv8vjfyi5bh6iqxmcnr5psxh-libxau-1.0.8/lib 
-L/gnu/store/ja06pq19g0cf2122kimk15z5yn0az73j-libxdmcp-1.1.2/lib 
libpolyml/.libs/libpolyml.a -lpthread 
/gnu/store/85ss68qvpfb62chf2wapp3b8gfqv5xc6-libffi-3.2.1/lib/libffi.so 
/gnu/store/wak3m4kdkgw010qn1ksnqlggvklp4b24-gmp-6.1.2/lib/libgmp.so 
/gnu/store/j7c87ss5vp909z2yzz7d8z6vigx93zkj-lesstif-0.95.2/lib/libXm.so 
/gnu/store/0fzh44zpdw1h2dwpzgfw2lic05y4k6md-libxt-1.1.5/lib/libXt.so 
/gnu/store/w5b3db8y2rq3d73b30m4c5z0ql270r9a-libsm-1.2.2/lib/libSM.so 
/gnu/store/6z06w9zfnq3zcr50vcv2wvzr5wpzvy7l-util-linux-2.29.2/lib/libuuid.so 
/gnu/store/wfy8pwxjbyc9033sqb1snyfla3h8d02p-libice-1.0.9/lib/libICE.so 
/gnu/store/gdx6vk579px16dgv60hgrr1c2k1pwsni-libx11-1.6.5/lib/libX11.so 
/gnu/store/fpbm0nvl2zi4jksm22kr1mq3hfw79xdn-libxcb-1.12/lib/libxcb.so 
/gnu/store/dr4qfgqmcv8vjfyi5bh6iqxmcnr5psxh-libxau-1.0.8/lib/libXau.so 
/gnu/store/ja06pq19g0cf2122kimk15z5yn0az73j-libxdmcp-1.1.2/lib/libXdmcp.so 
/gnu/store/a3qkf2l3jqnpqibcg2iwbkak4d6scx28-libbsd-0.8.3/lib/libbsd.so -lrt 
-ldl /gnu/store/dhc2iy059hi91fk55dcv79z09kp6500y-gcc-5.4.0-lib/lib/libstdc++.so 
-lm -lgcc_s -lgcc -Wl,-rpath 
-Wl,/gnu/store/dhc2iy059hi91fk55dcv79z09kp6500y-gcc-5.4.0-lib/lib -Wl,-rpath 
-Wl,/gnu/store/85ss68qvpfb62chf2wapp3b8gfqv5xc6-libffi-3.2.1/lib -Wl,-rpath 
-Wl,/gnu/store/wak3m4kdkgw010qn1ksnqlggvklp4b24-gmp-6.1.2/lib -Wl,-rpath 
-Wl,/gnu/store/j7c87ss5vp909z2yzz7d8z6vigx93zkj-lesstif-0.95.2/lib -Wl,-rpath 
-Wl,/gnu/store/0fzh44zpdw1h2dwpzgfw
2lic05y4k6md-libxt-1.1.5/lib -Wl,-rpath 
-Wl,/gnu/store/w5b3db8y2rq3d73b30m4c5z0ql270r9a-libsm-1.2.2/lib -Wl,-rpath 
-Wl,/gnu/store/6z06w9zfnq3zcr50vcv2wvzr5wpzvy7l-util-linux-2.29.2/lib 
-Wl,-rpath -Wl,/gnu/store/wfy8pwxjbyc9033sqb1snyfla3h8d02p-libice-1.0.9/lib 
-Wl,-rpath -Wl,/gnu/store/gdx6vk579px16dgv60hgrr1c2k1pwsni-libx11-1.6.5/lib 
-Wl,-rpath -Wl,/gnu/store/fpbm0nvl2zi4jksm22kr1mq3hfw79xdn-libxcb-1.12/lib 
-Wl,-rpath -Wl,/gnu/store/dr4qfgqmcv8vjfyi5bh6iqxmcnr5psxh-libxau-1.0.8/lib 
-Wl,-rpath -Wl,/gnu/store/ja06pq19g0cf2122kimk15z5yn0az73j-libxdmcp-1.1.2/lib 
-Wl,-rpath -Wl,/gnu/store/a3qkf2l3jqnpqibcg2iwbkak4d6scx28-libbsd-0.8.3/lib 
-Wl,-rpath -Wl,/gnu/store/dhc2iy059hi91fk55dcv79z09kp6500y-gcc-5.4.0-lib/lib 
-Wl,-rpath -Wl,/gnu/store/85ss68qvpfb62chf2wapp3b8gfqv5xc6-libffi-3.2.1/lib 
-Wl,-rpath -Wl,/gnu/store/wak3m4kdkgw010qn1ksnqlggvklp4b24-gmp-6.1.2/lib 
-Wl,-rpath -Wl,/gnu/store/j7c87ss5vp909z2yzz7d8z6vigx93zkj-lesstif-0.95.2/lib 
-Wl,-rpath -Wl,/gnu/store/0fzh44zpdw1h2dwpzgfw2lic05y4k6md-libxt-1.1.5/lib 
-Wl,-rpath -Wl,/gnu/store/w5b3db8y2rq3d73b30m4c5z0ql270r9a-libsm-1.2.2/lib 
-Wl,-rpath 
-Wl,/gnu/store/6z06w9zfnq3zcr50vcv2wvzr5wpzvy7l-util-linux-2.29.2/lib 
-Wl,-rpath -Wl,/gnu/store/wfy8pwxjbyc9033sqb1snyfla3h8d02p-libice-1.0.9/lib 
-Wl,-rpath -Wl,/gnu/store/gdx6vk579px16dgv60hgrr1c2k1pwsni-libx11-1.6.5/lib 
-Wl,-rpath -Wl,/gnu/store/fpbm0nvl2zi4jksm22kr1mq3hfw79xdn-libxcb-1.12/lib 
-Wl,-rpath -Wl,/gnu/store/dr4qfgqmcv8vjfyi5bh6iqxmcnr5psxh-libxau-1.0.8/lib 
-Wl,-rpath -Wl,/gnu/store/ja06pq19g0cf2122kimk15z5yn0az73j-libxdmcp-1.1.2/lib 
-Wl,-rpath -Wl,/gnu/store/a3qkf2l3jqnpqibcg2iwbkak4d6scx28-libbsd-0.8.3/lib
make  check-local
make[2]: Entering directory 

Re: 02/04: gnu: Add Poly/ML.

[Mark H Weaver]

Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> civodul pushed a commit to branch master
>> in repository guix.
>>
>> commit 9b7ee28d5700b47ae34bd47c32d250f042fbdbbd
>> Author: Andy Patterson 
>> Date:   Sat Jul 15 18:17:25 2017 -0400
>>
>> gnu: Add Poly/ML.
>> 
>> * gnu/packages/sml.scm: New file.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
>
> Thank you for this!  I've become interested in some projects that
> require Poly/ML, notably CakeML and Milawa/Jitawa which are based on
> HOL4 and apparently require Poly/ML.  Now I can play with those things :)

This failed to build on my x86_64 system running GuixSD.  Here's the
tail of the build log:

--8<---cut here---start->8---
Making XWINDOWS_SIG
Making XEVENT_SIG
Making XTYPES_SIG
Created signature XTYPES_SIG
Created signature XEVENT_SIG
Created signature XWINDOWS_SIG
Created structure XWindows
Making Motif
Making MotifTypes
Created structure MotifTypes
Making XmTypes
Created structure XmTypes
Making MotifCore
Created structure MotifCore
Making InitialiseCore
Created structure InitialiseCore
Making MOTIF_SIG
Making XM_TYPES
Making MOTIF_TYPES
Created signature MOTIF_TYPES
Created signature XM_TYPES
Created signature MOTIF_SIG
Created structure Motif
make[1]: *** [Makefile:1143: polyexport.o] Error 1
make[1]: Leaving directory '/tmp/guix-build-polyml-5.7.drv-0/polyml-5.7'
make: *** [Makefile:706: check-recursive] Error 1
phase `check' failed after 26.5 seconds
builder for `/gnu/store/g8fkhnji7cizvlgcxh1nyr5jplpmh6fd-polyml-5.7.drv' failed 
with exit code 1
guix package: error: build failed: build of 
`/gnu/store/g8fkhnji7cizvlgcxh1nyr5jplpmh6fd-polyml-5.7.drv' failed
--8<---cut here---end--->8---

   Mark

Re: 02/04: gnu: Add Poly/ML.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit 9b7ee28d5700b47ae34bd47c32d250f042fbdbbd
> Author: Andy Patterson 
> Date:   Sat Jul 15 18:17:25 2017 -0400
>
> gnu: Add Poly/ML.
> 
> * gnu/packages/sml.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

Thank you for this!  I've become interested in some projects that
require Poly/ML, notably CakeML and Milawa/Jitawa which are based on
HOL4 and apparently require Poly/ML.  Now I can play with those things :)

> +   (modify-phases %standard-phases
> + (add-after 'build 'build-compiler
> +   (lambda* (#:key make-flags parallel-build? #:allow-other-keys)
> + (define flags
> +   (if parallel-build?
> +   (cons (format #f "-j~d" (parallel-job-count))
> + make-flags)
> +   make-flags))
> + (apply system* "make" (append flags (list "compiler"

This is not quite right.  Phase procedures return a boolean value to
indicate success or failure.  'system*' returns a numeric status code.
All numbers are treated as true by Scheme, so this will fail to detect
errors.  By our usual conventions, we would replace the final expression
above with:

  (zero? (apply system* "make" (append flags (list "compiler"

> +(home-page "http://www.polyml.org/;)
> +(synopsis "Standard ML implementation")
> +(description "Poly/ML is a Standard ML implementation.  It is fully
> +compatible with the ML97 standard.  It includes a thread library, a foreign
> +function interface, and a symbolic debugger.")

It might be worth mentioning that Poly/ML cannot be bootstrapped from
source code, and includes a precompiled version of itself, or at least
that's my understanding.

Anyway, thanks again for this contribution.

   Mark

Re: Is font-google-noto toooooo big as a font package?

[tumashu]

the first thing is improve font-build-system to support split package easy


在2017年07月17日 22:04，(无发件人) 写道：
"Feng Shu"  skribis:

> font-google-note's size is 506.4 MB, see to big as a font package,
> maybe we should split it.

It’s too big, indeed (and this is the compressed size; ‘guix size’
reports 591.4 MiB.)

Would be nice to split, but I have no idea whether/how this can be done.

Thoughts?

Ludo’.

Re: [directory-discuss] guix tags that could be automatically extracted

[Ludovic Courtès]

Hello,

Adonay Felipe Nogueira  skribis:

> As I explained in directory-discuss, in the same thread that started
> this one: I'm in favor of:
>
> Guix → FSF MW.
>
> But I don't think the other way around is good, as it might also imply
> losing the auto-sufficiency described in the first sections of the GNU
> FSDG.
>
> As far as I know, Quiliro's intention was to do the first (Guix → FSF
> MW).

That’s something that should be easily done, maybe without even a single
change on the Guix side: the output is in the GNU recutils format, so
perhaps it can be directly entered in the MediaWiki database somehow?

Anyway thanks for looking into this.  I think it’s good to share efforts
among peers!

Ludo’.

Re: Bootstrapping Guix on HPC without Root

[Ludovic Courtès]

Hello!

Wm Salt Hale  skribis:

> I have been attempting to install Guix on the University of
> Washington's HPC using a modified bootstrapping script based on
> https://github.com/pjotrp/nix-no-root
>
> The script can currently be found here (to be forked and pushed to GH
> when verified as working):
>
> https://communitydata.cc/~salt/guix-bootstrap.sh
>
>
> This produces a semi-working installation, it can spit out a version
> and spend a good deal of time trying to complete `guix pull`
>
> The first run was logged via `|& tee -a`
>
> https://communitydata.cc/~salt/guix_first_run.log

For the sake of those not following links ;-), the build error is:

--8<---cut here---start->8---
build/genhooks.o build/errors.o 
../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
g++   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H 
-DGENERATOR_FILE 
-Wl,-rpath=/com/guix/guix/store/qrxkb00z8qmj0aql4gd8zcmf3ldvz583-glibc-2.25/lib 
-Wl,-dynamic-linker 
-Wl,/com/guix/guix/store/qrxkb00z8qmj0aql4gd8zcmf3ldvz583-glibc-2.25/lib/ld-linux-x86-64.so.2
 -L/com/guix/guix/store/89f8avya4dzh8jrvzxw1q9pf27af702h-libstdc++-5.4.0/lib 
-L/com/guix/guix/store/yr6nya39hzwx960y8nbiqq91w5yk842x-zlib-1.2.11/lib 
-Wl,-rpath=/com/guix/guix/store/yr6nya39hzwx960y8nbiqq91w5yk842x-zlib-1.2.11/lib
 -o build/genchecksum \
build/genchecksum.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
x86_64-guix-linux-gnu-ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:2613: build/genhooks] Error 1
make[3]: *** Waiting for unfinished jobs
x86_64-guix-linux-gnu-ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:2613: build/genchecksum] Error 1
--8<---cut here---end--->8---

The ‘guix-bootstrap.sh’ script above runs guix-daemon with
‘--disable-chroot’, which means build processes are not being isolated.
I’m fairly confident that this is the root cause of the problem; for
instance because GCC’s build processes end up picking a few things from
/usr/bin instead of /gnu/store.  (ISTR Roel Janssen experienced a
similar issue back then, maybe Roel can comment.)

Pjotr mentioned PRoot.  An intermediate solution would be to build and
“pack” the software you want to run on your laptop (any machine where
Guix is already installed), to send it to the HPC machine, and to run it
there with PRoot.  I gave instructions at:

  https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00182.html

I know Pjotr has been experimenting with another nice option, I’ll let
him explain.  :-)

HTH!

Ludo’.

Re: Is font-google-noto toooooo big as a font package?

[Ludovic Courtès]

"Feng Shu"  skribis:

> font-google-note's size is 506.4 MB, see to big as a font package,
> maybe we should split it.

It’s too big, indeed (and this is the compressed size; ‘guix size’
reports 591.4 MiB.)

Would be nice to split, but I have no idea whether/how this can be done.

Thoughts?

Ludo’.

Re: ISO-9660 image working and ready

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Wed, 12 Jul 2017 23:20:26 +0200
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> > It will work from CD and USB flash drive - that should cover all the 
>> > options.  
>> 
>> Are you saying that the same image could be either dd’d to a USB key or
>> burnt on an actual CD?
>
> Yes.

Awesome!

Would you like to update the ‘release’ Makefile.am target as well as
“System Installation” in guix.texi to reflect that?

>> Are there any downsides to using ISO9660 as the file system for the
>> media, like limitations on file names or file name lengths, restrictions
>> on the type of files, etc.?  (That doesn’t seem to be the case, but I
>> vaguely remember ISO9660 as having annoying limitations.)
>
> It uses the Rock Ridge extension.  That means basenames are limited to 255 
> characters at most, allowed are all characters except NUL and "/".

Cool.

>>   ./pre-inst-env guix system disk-image -t iso9660 gnu/system/install.scm
>> 
>> on v0.13.0-1321-gc96ed0091 (current master), booted it with QEMU,
>> worked fine with ‘lsblk’ showing only /dev/{fd0,sr0}.   Woohoo!  \o/
>
> Now try qemu ...  -hda thesamefile.iso :)

Incredible.  :-)

>> The image has this 2KiB /boot.catalog file; is that expected?
>
> Yeah, that's the El Torito specification for the first-stage bootloader.  It 
> contains what system architectures are supported and what kind of weird boot 
> emulation the BIOS is supposed to use (look like a floppy drive, look like a 
> hard drive, just be yourself etc).

OK.

>> Otherwise the file names look alright as if Joliet extensions were used,
>> but maybe they are?
>
> Rock Ridge :)

Oh right, Rock Ridge.  Thanks for explaining!

Ludo’.

Re: Automatically detect other OSs and generate grub entries

[Ludovic Courtès]

Arun Isaac  skribis:

> Instead of having to manually specify custom grub entries in config.scm,
> can Guix use os-prober to automatically detect other operating system
> and generate grub entries?
>
> https://joeyh.name/code/os-prober/

I think there is value in having everything in the GuixSD config, which
can then be put under version control.

Now, I have a single OS on my machines so I’m probably not part of the
target audience.  :-)

Thoughts?

Ludo’.

Re: Substitute caching restored

[Ludovic Courtès]

Leo Famulari  skribis:

> On Wed, Jul 12, 2017 at 10:47:29PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> Tired of updating the list of substitutes?  I have some good news for
>> you!
>> 
>> Since the switch to Guile 2.2.2, because of a bug (an otherwise known
>> bug) in SRFI-19, ‘guix substitute’ would be storing the wrong date in
>> cached narinfos in /var/guix/substitute/cache.  Consequently, we’d be
>> updating most narinfos as soon as we had cached them!
>> 
>> Commit b547349d505c57fd679b6e48c472d8ab65469c96 fixes that and
>> c96ed00910d9238a43469e5f00a8261253294257 updates the ‘guix’ package.
>
> Ah, thank you for finding and fixing this!

I owe it in part to jsierles on IRC who reported weird caching
behavior—which I had actually been experiencing for some time but was
blaming on anything except Guix.  ;-)

Ludo’.

Re: Graphical Installer - Call for Testing.

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> Hi Ludo,
>
>> Yes.  At the REPL, you can do:
>> 
>>   ,use(guix)
>>   ,run-in-store (system-disk-image installation-os)
>
> I tried:
>
> ,use (gnu system vm)
> ,use (gnu system install)
> ,use (guix)
> ,run-in-store (system-disk-image installation-os)
> (derivation->output-path $3)
>
> and get
>
> $3 = # => /gnu/store/pjrkpnz4bgpiqgdix8ldz0psp53zr4kr-disk-image b0bbe60>
> $5 = "/gnu/store/pjrkpnz4bgpiqgdix8ldz0psp53zr4kr-disk-image"
>
> But /gnu/store/pjrkpnz4bgpiqgdix8ldz0psp53zr4kr-disk-image doesn't exist yet.
>
> What should I do to make guix build the image?

You should build the derivation, either from the REPL:

  ,run-in-store (built-derivations (list $3))

or from the shell:

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

HTH!

Ludo’.

Re: cuirass evaluate

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> A cuirass question :
>
> In src/cuirass/base.scm, you wrote the following comment :
>
>   ;; Register the results in the database.
>   ;; XXX: The 'build-derivations' call is blocking so we end updating the
>   ;; database potentially long after things have been built.
>
> How would it be possible to be notified when a build succeeds, to update
> the database asap ?

Unfortunately, the current daemon protocol makes it hard to get such
notifications, unless you parse its output (the “@ build-succeeded”
lines) like I did in ‘wip-ui’.

Perhaps we’ll have to do this parsing anyway, or just change the
protocol altogether and have a “channel” mechanism like SSH to multiplex
the number of communication channels on one connection.  reepca, if you
read this, that’s something to keep in mind.  :-)

Alternately, Cuirass could also periodically call ‘valid-path?’ for all
the outputs of the pending builds (in a separate thread; note that the
daemon connection cannot be shared among threads.)

HTH,
Ludo’.

Re: core-updates summer 2017

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Jul 10, 2017 at 04:47:06PM -0400, Leo Famulari wrote:
>> Let's use this thread to discuss the state of the branch.
>
> I've reconfigured and rebooted my x86_64-linux GuixSD system based on
> the latest core-updates (2f0d1b9dd2d75c5501767a15cf9b87fc057711c0).
>
> There are some new warnings / errors during early boot, that read like
> this:
>
> --
> ;;; WARNING: loading compiled file 
> /gnu/store/...-module-import-compiled/gnu/build/linux-boot.go failed:
> ;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
> "\x7fELF\x02\x01\x01ÿ\x00\x00\x00\x00\x00\x00\x00\x00"
> --
>
> This seems reminiscent of the object format change between Guile 2.0 and
> Guile 2.2, but I'm not sure what's going on. I've attached photos of my
> screen, which provide some more context.

It looks like the initrd is still running Guile 2.0 but getting 2.2
modules.

This should be fixed with this patch, which I haven’t been able to test
yet:

diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 844b110eb..ecd019a94 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -504,21 +504,21 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
   (let* ((patches (cons* (search-patch "guile-relocatable.patch")
  (search-patch "guile-default-utf8.patch")
  (search-patch "guile-linux-syscalls.patch")
- (origin-patches (package-source guile-2.0
- (source  (origin (inherit (package-source guile-2.0))
+ (origin-patches (package-source guile-2.2
+ (source  (origin (inherit (package-source guile-2.2))
 (patches patches)))
- (guile (package (inherit guile-2.0)
-  (name (string-append (package-name guile-2.0) "-static"))
+ (guile (package (inherit guile-2.2)
+  (name (string-append (package-name guile-2.2) "-static"))
   (source source)
   (synopsis "Statically-linked and relocatable Guile")
 
   ;; Remove the 'debug' output (see above for the reason.)
-  (outputs (delete "debug" (package-outputs guile-2.0)))
+  (outputs (delete "debug" (package-outputs guile-2.2)))
 
   (propagated-inputs
`(("bdw-gc" ,libgc)
  ,@(alist-delete "bdw-gc"
- (package-propagated-inputs guile-2.0
+ (package-propagated-inputs guile-2.2
   (arguments
`(;; When `configure' checks for ltdl availability, it
  ;; doesn't try to link using libtool, and thus fails
@@ -534,7 +534,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
(("^guile_LDFLAGS =")
 "guile_LDFLAGS = -all-static")
 
-   ;; Add `-ldl' *after* libguile-2.0.la.
+   ;; Add `-ldl' *after* libguile-2.2.la.
(("^guile_LDADD =(.*)$" _ ldadd)
 (string-append "guile_LDADD = "
(string-trim-right ldadd)

> Also, while starting my user's shepherd, there is a new error message,
> but my services do start:
>
> --
> $ shepherd
> Service root has been started.
> Service mpd has been started.
> Service syncthing has been started.
> error in finalization thread: Bad file descriptor
> error in finalization thread: Bad file descriptor
> [... services start ...]
> --

Ooh, hmm, could you “strace -f shepherd”?

For the record, I can build my laptop config as of
v0.13.0-1469-g588bd05fc (X11, SLiM, OpenSSH, etc.)  I haven’t tested in
a VM yet because there are no QEMU substitutes.  It looks like we’re
getting there!

Thanks,
Ludo’.

Re: `guix pack --target=arm-linux-gnueabihf guile` fails at phase unpack

[Ludovic Courtès]

Hi Louis,

Louis Pearson  skribis:

> I am experimenting with different methods of building applications and
> deploying them to embedded devices. I am currently experimenting with
> `guix` and the `guix pack` command. When running `guix pack
> --target=arm-linux-gnueabihf guile` with guile however, I encounter
> this error:

[...]

> warning: failed to install 'en_US.utf8' locale: Invalid argument
> phase `install-locale' succeeded after 0.0 seconds
> starting phase `unpack'
> In execvp of tar: No such file or directory
> phase `unpack' failed after 0.0 seconds
> builder for `/gnu/store/2igq71k5767mh00wwii6lw7b04yq753s-make-boot0-4.2.1.drv'
> failed with exit code 1
> cannot build derivation
> `/gnu/store/xbwfrk8q029di2y7wbkb70x5j67b5zka-gcc-cross-boot0-5.4.0.drv':
> 1 dependencies couldn't be built
> guix pack: error: build failed: build of
> `/gnu/store/xbwfrk8q029di2y7wbkb70x5j67b5zka-gcc-cross-boot0-5.4.0.drv'
> failed

I think you found a bug in the “grafting” code, or in the specific
grafts that are currently applicable on master.  Could you report it to
bug-g...@gnu.org so we keep track of it?

For now, you can work around it by running “guix pack guile
--no-grafts”.  However, note that the resulting binaries will lack
important security updates, such as the stack-clash-related fix in
glibc.  Use with care!

Thanks,
Ludo’.

Re: npm (mitigation)

[Catonano]

Mike,

2017-07-15 5:34 GMT+02:00 Mike Gerwitz :

> On Fri, Jul 14, 2017 at 13:57:30 +0200, Jelle Licht wrote:
> > Regardless, the biggest issue that remains is still that npm-land is
> mired
> > in cyclical dependencies and a fun-but-not-actually unique dependency
> > resolving scheme.
>
> I still think the largest issue is trying to determine if a given
> package and its entire [cyclic cluster] subgraph is Free.  That's a lot
> of manual verification to be had (to verify any automated
> checks).  npm's package.json does include a `license' field, but that is
> metadata with no legal significance, and afaik _defaults_ to "MIT"
> (implying Expat), even if there's actually no license information in the
> repository.


 in my idea I would have build a database withh conditions for being non
free forr every npm package.

So we could have queried the database for questions like: is there any non
free or non buildable package in the dependency tree of, say, the current
Jquery ?

So we could have focused on such problems before embarking in a demanding
packaging process and then get struck by said problem along the way (withh
the risk of loosing the work already done)

You might remember my post of a few months back about an attempt of mine to
crawl thhe npm registry and storing data found there.

I used amz3's wrap around Wiredtiger and that was probably not the best
choice as I run into some maturity problems (maturity both of the framewrok
and my own maturity).

And then I slacked a bit

I also posted more recently about a research team that published a SPARQL
endpoint containing data about the npm packages

I thought it would be important but the feedback I collected was not
exactly warm

So I thought there must be some fundamental flaw in my way of thinking
about a more data centric way of dealing with this

Now I'm not sure what Jelle is talking about but any approach that cold be
shared among at least 2 persons would be a progress, in my opinion.

Jelle, please, say something more about whaht you're doing !

Re: npm (mitigation)

[Catonano]

2017-07-14 19:11 GMT+02:00 Jan Nieuwenhuizen :

> Catonano writes:
>
> > I read that Jelle and Jan used their own branch in order to have npm
> > based software to be installed in their GuixSD environments, as binary
> > blobs
>
> Jelle wrote a nice and clean npm importer, no binary anything.
>
> Npm packages have the can be source or binary.  Depending on how you
> want to look at it you can make change this source/binary disctinction
> less white/black and turn it into a gray-scale.
>
> As we are talking about javascript, in some cases source and binary
> packages are identical.  In other cases, the binary packages come with
> preprocessed documentation and lack the sources.  Other binary packages
> include minimized javascript and even further into the darkness some
> binary packages do not include the non-minimized javascript.  Then some
> binary packages come with pre-compiled binaries and the worst are binary
> package that do not come with the C/C++ sources that were used to
> compile these binaries.
>
> In all these cases the binary packages can be built from their source
> package.  Here is where it starts to get nasty.  Building a package from
> source can only be done if you have all its dependencies already
> installed.  In theory that should not be a problem.
>
> It appears that the npm ecosystem has manouvered itself into a place
> where bootstrapping seems impossible: it turns out that any serious
> package (notably all npm build system packages) have over 1000
> dependencies, often with cyclic dependencies or even missing packages.
>
> To break this boostrap loop on Guix I have added a couple of patches
> onto Jelle's npm importer branch that implement a --binary flag.  This
> allows binary npm packages to be installed in Guix and serve as a basis
> to build other npm packages from source.
>
> Apparently have no problem*) adding binary blobs for gcc, haskell (...?)
> to Guix.  Similarly we could consider adding a/some binary blobs for npm
> buildsystem packages to Guix and use those for a basis to build
> source-only packages.
>
> > Can I ask you for instructions about how to do that exactly ?
>
>git clone https://gitlab.com/janneke/guix.git
>
> The branch `npm' is rebased on version-0.13.0, have a look at
>
>guix import npm --help
>
> and look in gnu/packages/npm.scm for instructions.
>
> Greetings,
> janneke
>
> *) Actually I do not like this very much and that's why some of us seek
>to remove the need for our bootstrap binaries with our stage0 and Mes
>projects.
>

Thanks.
Both for the wrap up and for the instructions.

Re: npm (mitigation)

[Catonano]

2017-07-14 13:57 GMT+02:00 Jelle Licht :

> Hi Catonano,
>
> I would be be happy to help you with this, but tbh, I am not comfortable
> discussing this in-depth on guix-devel, as this seems antithetical to Guix'
> goals.
>

Ok, at least we made this clear.
I'll keep the list off the hook, should I need to discuss tis further, in
the future.

Just for the record, I don't mean to conter thhe Guix aim. I consider this
as a temporary mitigation. Were "temporary" is the key word

Regardless, the biggest issue that remains is still that npm-land is mired
> in cyclical dependencies and a fun-but-not-actually unique dependency
> resolving scheme.
> I am currently working on a guile version of what Sander did for Nix for
> importing entire npm dependency trees, but this will likely lead to lots of
> programmatically
> defined packages instead of the guix approach of mostly-manually defining
> each package.
>

What ? Who is Sander ans what did the do for Nix ?

How is importing "entire npm dependencies trees" different than importing
one package at a time and building the dependency tree gradually ?

I have no problem with programmatically defined pacages, anyway ;-)

Re: RPC pipelining

[Ludovic Courtès]

Ricardo Wurmus  skribis:

>> Why does Guix need Shepherd?  And if it needs the (charting)
>> module, why isn't guile-charting already an input?
>
> Guile Charting is optional.  The error is misleadingly alarming.

Yes, same for Shepherd (both are mere warnings, but I agree they can be
misleading.)

Does “make dist” eventually fail?

Thanks,
Ludo’.