Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Svante Signell]

On Wed, 2019-09-04 at 00:01 +0200, Ricardo Wurmus wrote:
> Svante Signell  writes:
> 
> Did you copy this from Debian and moved it into the store?  That’s a
> very bad idea.

Sorry, my fault. I was tired and worked on different boxes and Linux+Hurd VMs.

The status is now that ...:
Starting download of /gnu/store/cq2prw9x259px05hsfvyivjfv9ibd1s7-make-
4.2.1.tar.bz2
>From ftp://ftp.funet.fi/pub/mirrors/ftp.gnu.org/gnu/make/make-4.2.1.tar.bz2...
cessfully built /gnu/store/j3525cllgl53qhkk5k9qkvx49qhba15g-make-
4.2.1.tar.bz2.drv
building /gnu/store/kpwda0jcslkx16hm91ab1kr9kqg6lpg8-guile-bootstrap-2.0.drv...
unpacking bootstrap Guile to '/gnu/store/ncp3yhr6c38kqvgb8c967vnhly59yf1m-guile-
bootstrap-2.0'...
./
./bin/
./bin/guile
...
./share/guile/2.2/web/server.scm./share/guile/2.2/web/uri.scm

Uncaught exception:
Cannot exit gracefully when init is in progress; aborting.
/gnu/store/f2zsfb7ywkjmv7rzbnrzxi68hrcijnsf-build-bootstrap-guile.sh: line 8:
13527 Aborted (core dumped)
GUILE_SYSTEM_PATH=$out/share/guile/2.0
GUILE_SYSTEM_COMPILED_PATH=$out/lib/guile/2.0/ccache $out/bin/guile -c "(begin
(use-modules (ice-9 match)) (match (command-line) ((_ out bash) (let ((bin-dir
(string-append out \"/bin\")) (guile (string-append out \"/bin/guile\")) (guile-
real (string-append out \"/bin/.guile-real\")) (dollar (string (integer->char
36 (chmod bin-dir 493) (rename-file guile guile-real) 
(call-with-output-file 
guile (lambda (p) (format p \"#!~a\\nexport
GUILE_SYSTEM_PATH=~a/share/guile/2.0\\nexport
GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.0/ccache\\nexec -a \\\"~a0\\\" ~a
\\\"~a@\\\"\\n\" bash out out dollar guile-real dollar))) (chmod guile 365)
(chmod bin-dir 365)" $out /gnu/store/l79x4bhi7gw87xq0dwjia55qvdr0d4lz-bash
successfully built /gnu/store/kpwda0jcslkx16hm91ab1kr9kqg6lpg8-guile-bootstrap-
2.0.drv
building /gnu/store/fkqrljhpfw57hvcjg4gy6cisw45vw5r3-static-binaries-0-i586-pc-
gnu.tar.xz.drv...
Starting download of /gnu/store/abq8fgbsnfrjd0l5ywcnb12k4grynpcc-static-
binaries-0-i586-pc-gnu.tar.xz
...
successfully built /gnu/store/kpwda0jcslkx16hm91ab1kr9kqg6lpg8-guile-bootstrap-
2.0.drv
building /gnu/store/fkqrljhpfw57hvcjg4gy6cisw45vw5r3-static-binaries-0-i586-pc-
gnu.tar.xz.drv..
successfully built /gnu/store/1cfnynxfjp5axj9s83hcak8azc84lzfx-module-import-
compiled.drv
building /gnu/store/2pyyqi3hpvwxhdwy0wjnrgnirzbslh1k-binutils-bootstrap-0.drv...
successfully built /gnu/store/2pyyqi3hpvwxhdwy0wjnrgnirzbslh1k-binutils-
bootstrap-0.drv
building /gnu/store/5pddkdbhw27pgaq406js2c5m0wix6z6h-bootstrap-binaries-0.drv...
builder for `/gnu/store/5pddkdbhw27pgaq406js2c5m0wix6z6h-bootstrap-binaries-
0.drv' failed with exit code 1
build of /gnu/store/5pddkdbhw27pgaq406js2c5m0wix6z6h-bootstrap-binaries-0.drv
failedView build log at
'/usr/var/log/guix/drvs/5p/ddkdbhw27pgaq406js2c5m0wix6z6h-bootstrap-binaries-
0.drv.gz'.
cannot build derivation `/gnu/store/9w8x804cgfm0j6h41k5z6lhyzfwcdzhv-make-boot0-
4.2.1.drv': 1 dependencies couldn't be built
killing process 13522: Invalid argument
guix build: error: build of `/gnu/store/9w8x804cgfm0j6h41k5z6lhyzfwcdzhv-make-
boot0-4.2.1.drv' failed

In this session the cross-compiled version of guile-static was used.
The only changes were the native tar in static-binaries and
native versions of bash mkdir tar xz at gnu/packages/bootstrap/i586-gnu

Thanks!

Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Ricardo Wurmus]

Svante Signell  writes:

> On Tue, 2019-09-03 at 23:26 +0200, Ricardo Wurmus wrote:
>> 
>> What are the contents of /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-
>> bootstrap-binaries-0/bin/tar?
>
> Something strange:
>
> # ls -l  /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-
> 0/bin/tar
> -r-xr-xr-x 2 root root 445560 Jan  1  1970
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
>
> # file 
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: ELF
> 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
> interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,

Did you copy this from Debian and moved it into the store?  That’s a
very bad idea.

> BuildID[sha1]=6664753ff93e3b42aa8681d7fe0f7f9e5259c54f, stripped
>
> # ldd /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
> not a dynamic executable
>
> # /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
> -bash: 
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 
> cannot execute binary file: Exec format error

Does /lib64/ld-linux-x86-64.so.2 exist on the system?  On the Guix
system this does not exist.

-- 
Ricardo

Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Ricardo Wurmus]

Svante Signell  writes:

> On Tue, 2019-09-03 at 16:34 +0200, Svante Signell wrote:
>> 
>> > How can I rebuild from scratch to watch the output on the console? 
>
> Seems to be to wipe out /gnu/store and /var/{guix,log}
>
>> This time bash crashed... Took a screen shot of the qemu console. I have to
>> replace all four:  bash  mkdir  tar  xz and put them into the .xz file too. 
>
> I have now replaced bin/guile in 
> guile-static-stripped-2.2.4-i586-pc-gnu.tar.xz, 
> but guile or tar still crashes. However I came a little further this time
> though:
> successfully built 
> /gnu/store/3aqdqcnz63nnlwk61wimkcrdpbilwpvp-glibc-bootstrap-
> 0.drv
> building /gnu/store/sp2zksrcpvph48j9d93i902y098hpai4-make-4.2.1.tar.xz.drv...
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 1:
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 
> Syntax
> error: ";" unexpected
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 1:
> /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 
> Syntax
> error: ";" unexpected

What are the contents of 
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar?

> The main problem seem to be the cross-built binaries. Would it be possible to
> build these static binaries natively, maybe even using guix or in som other
> way??

We should figure out what’s wrong with them and then adjust the way
these binaries are built.  It would not be useful to take binaries from
elsewhere because we want to be able to reproduce the build automatically.

-- 
Ricardo

Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Svante Signell]

On Tue, 2019-09-03 at 23:26 +0200, Ricardo Wurmus wrote:
> 
> What are the contents of /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-
> bootstrap-binaries-0/bin/tar?

Something strange:

# ls -l  /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-
0/bin/tar
-r-xr-xr-x 2 root root 445560 Jan  1  1970
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar

# file /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: ELF
64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=6664753ff93e3b42aa8681d7fe0f7f9e5259c54f, stripped

# ldd /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
not a dynamic executable

# /gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar
-bash: 
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 
cannot execute binary file: Exec format error

> > The main problem seem to be the cross-built binaries. Would it be possible
> > to build these static binaries natively, maybe even using guix or in som
> > other way??
> 
> We should figure out what’s wrong with them and then adjust the way
> these binaries are built.  It would not be useful to take binaries from
> elsewhere because we want to be able to reproduce the build automatically.

Again, can we build them natively on Hurd for testing purposes, either using
native guix or not or cross-compiling from Linux with or without guix?

Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Svante Signell]

On Tue, 2019-09-03 at 16:34 +0200, Svante Signell wrote:
> 
> > How can I rebuild from scratch to watch the output on the console? 

Seems to be to wipe out /gnu/store and /var/{guix,log}

> This time bash crashed... Took a screen shot of the qemu console. I have to
> replace all four:  bash  mkdir  tar  xz and put them into the .xz file too. 

I have now replaced bin/guile in 
guile-static-stripped-2.2.4-i586-pc-gnu.tar.xz, 
but guile or tar still crashes. However I came a little further this time
though:
successfully built /gnu/store/3aqdqcnz63nnlwk61wimkcrdpbilwpvp-glibc-bootstrap-
0.drv
building /gnu/store/sp2zksrcpvph48j9d93i902y098hpai4-make-4.2.1.tar.xz.drv...
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 1:
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: Syntax
error: ";" unexpected
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: 1:
/gnu/store/alzim8hg6zqvs9s33frh7m9z211lryk3-bootstrap-binaries-0/bin/tar: Syntax
error: ";" unexpected
Backtrace:
   2 (primitive-load "/gnu/store/qhyjwkwjriipqrc5av2j2ng6cgh?")
In ice-9/eval.scm:
619:8  1 (_ #f)
In guix/build/utils.scm:
616:6  0 (invoke _ . _)

guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
builder for `/gnu/store/sp2zksrcpvph48j9d93i902y098hpai4-make-4.2.1.tar.xz.drv'
failed with exit code 1
build of /gnu/store/sp2zksrcpvph48j9d93i902y098hpai4-make-4.2.1.tar.xz.drv
failed
View build log at '/usr/var/log/guix/drvs/sp/2zksrcpvph48j9d93i902y098hpai4-
make-4.2.1.tar.xz.drv.gz'.
cannot build derivation `/gnu/store/zjhkkvvlqiidl0albl0hcsd7c5pmfazs-make-boot0-
4.2.1.drv': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/zjhkkvvlqiidl0albl0hcsd7c5pmfazs-make-
boot0-4.2.1.drv' failed

The main problem seem to be the cross-built binaries. Would it be possible to
build these static binaries natively, maybe even using guix or in som other
way??

I have cross-built binutils, gcc, glibc, etc some (long) time ago when porting
gnat to GNU/Hurd. Maybe it is time to find those notes again (if they did not
disappear in the previous hard-disk crashes, no backup was used).

All for now, time to do something else. BBL.

Thanks!

Re: Gender neutral documentation

[Laura Lazzati]

Hi!
I would like to help in translating to Spanish if you need to :)

Latin languages are pretty bad at that.  In Spanish, people sometimes
> replace the “a” and “o” suffixes (which denote feminine and masculine)
> with “@” or with “e”.
>
Here we use "e" or "x" for gender neutrality (ie: les usuaries, or lxs
usuarixs for "the users", the reason of using an "e" is that you can
pronounce it, while @ or x not). However, nothing is approved by Real
Academia Española.

Regards :)
Laura

Re: Seeking Outreachy internship project proposals

[Laura Lazzati]

Hi!

I just wanted to let you know that even I'm in the process of moving I can
help in writing the blog post for Outreachy and so on if you need :)

Regards :)
Laura

Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Svante Signell]

On Tue, 2019-09-03 at 14:58 +0200, Ricardo Wurmus wrote:
> Hi Svante,
> 
> This looks very much like the tar segfault I encountered when I last
> played with the Hurd port.
> 
> My notes say this:
> 
> --8<---cut here---start->8---
> - tar fails to run when building gnu-make-boot0
> ./pre-inst-env  guix build -e '(@@ (gnu packages commencement) gnu-make-
> boot0))'
> here’s the error:
> building /gnu/store/ybi3cyxqwm55gvwn9i1nczg2ns5ha34q-make-
> 4.2.1.tar.xz.drv...   
> /hurd/crash: /gnu/store/dqlhjyvg0n8v1kdvwfpliqy46n7kpjqb-bootstrap-binaries-
> 0/bin/tar cvfa /gnu/store/p278mqb3aa0xrkrrw4rg1fxbb19hbdyh-make-4.2.1.tar.xz 
> --mtime=@0 --owner=root --group=root --sort=name make-4.2.1(2316) crashed,
> signal {no:1 1, code:8176, error:2}, exception {1, code:2, subcode:8176}, PCs:
> {0x8089ce7, 0x 815091c}, writing core file.  
> 
> 
> This works:
> /gnu/store/dqlhjyvg0n8v1kdvwfpliqy46n7kpjqb-bootstrap-binaries-0/bin/tar cvfa
> hello.tar.xz /tmp
> 
> But it segfaults with “--mtime=@0”

I did not look at the console, but found out similar crashes there. How did you
get the output to the client terminal instead of the qemu console (not possible
to cut and paste from that)? I have now tested both the statically built tar,
the native tar downloaded by guix and the native tar: No errors now.

How can I rebuild from scratch to watch the output on the console? 

Re: How to reference external program used in shell-scripts?

[Development of GNU Guix and the GNU System distribution.]

‐‐‐ Original Message ‐‐‐
On Tuesday, September 3, 2019 1:01 PM, Ludovic Courtès  wrote:

> Hello Hartmut,
>
> Hartmut Goebel h.goe...@crazy-compilers.com skribis:
>
> > My concerns are not about building, but about installing. A concrete
> > example:
> >
> > -   Ansible is a Python program running ssh via a path to
> > /gnu/store/…-openssh-8.0p1/bin/ssh
> >
> > -   Mary installs ansible.
> > -   Now openssh shows a serious bug and Mary updates openssh using "guix
> > -u openssh"
> >
> >
> > Obviously this will not update ansible, and ansible will still use the
> > old, vulnerable version of openssh.
> > OTOH, if ansible would run ssh via $PATH, ansible would pick up the new
> > version of openssh.
>
> The whole idea of functional software deployment is that it’s stateless:
> you can tell that /gnu/store/…-ansible-1.2.3 will always behave the
> same, no matter what other programs are available on your machine.
>
> Introducing “dynamic binding” (e.g., looking up programs in $PATH) would
> allow for faster security updates in the example you gave, but that
> would be at the expense of that core property I described above. It
> would be a regression.
>
> I think what we need in this case is (1) fast security updates, which is
> what grafts help us achieve, and (2) documentation that clarifies what
> the deployment model is, such that Mary would know that ‘ansible’ also
> needs to be upgraded in the example above.
>
> Ludo’.

What about the performance side?
Can we tell Guix that an input is runtime only? Or only needed in certain 
stages of the build? Or is that better accomplished by splitting a package?
For example, if a large package (let's say... written in Rust) uses Lua for a 
utility script at run time, but doesn't touch it at build time changing the Lua 
version should not result in a recompilation.

Re: How to reference external program used in shell-scripts?

[Ludovic Courtès]

Hello Hartmut,

Hartmut Goebel  skribis:

> My concerns are not about building, but about installing. A concrete
> example:
>
>   * Ansible is a Python program running ssh via a path to
> /gnu/store/…-openssh-8.0p1/bin/ssh
>   * Mary installs ansible.
>   * Now openssh shows a serious bug and Mary updates openssh using "guix
> -u openssh"
>
> Obviously this will *not* update ansible, and ansible will still use the
> old, vulnerable version of openssh.
>
> OTOH, if ansible would run ssh via $PATH, ansible would pick up the new
> version of openssh.

The whole idea of functional software deployment is that it’s stateless:
you can tell that /gnu/store/…-ansible-1.2.3 will always behave the
same, no matter what other programs are available on your machine.

Introducing “dynamic binding” (e.g., looking up programs in $PATH) would
allow for faster security updates in the example you gave, but that
would be at the expense of that core property I described above.  It
would be a regression.

I think what we need in this case is (1) fast security updates, which is
what grafts help us achieve, and (2) documentation that clarifies what
the deployment model is, such that Mary would know that ‘ansible’ also
needs to be upgraded in the example above.

Ludo’.

Re: Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Ricardo Wurmus]

Hi Svante,

> Then I continued with as Richardo wrote:
> ./pre-inst-env  guix build -e '(@@ (gnu packages commencement) 
> gnu-make-boot0))' 
> 2>&1 | tee ../pre-inst-env_guix-build-e-no-chroot_new-hash.log
> The build went a lot further, but failed here:
>  
> successfully built /gnu/store/6sybpxd8hy07h4fqf4wyblxrsi17r4zn-gcc-bootstrap-
> 0.drv
> building /gnu/store/h0y1izzm1nxr3gqwagg84dnssa723sby-make-4.2.1.tar.xz.drv...
> builder for 
> `/gnu/store/h0y1izzm1nxr3gqwagg84dnssa723sby-make-4.2.1.tar.xz.drv'
> failed with exit code 1
> build of /gnu/store/h0y1izzm1nxr3gqwagg84dnssa723sby-make-4.2.1.tar.xz.drv
> failed
> View build log at '/usr/var/log/guix/drvs/h0/y1izzm1nxr3gqwagg84dnssa723sby-
> make-4.2.1.tar.xz.drv.gz'.
> cannot build derivation 
> `/gnu/store/j18911vbapx9kx0gqcyn6nkd3bwz52lj-make-boot0-
> 4.2.1.drv': 1 dependencies couldn't be built
> guix build: error: build of `/gnu/store/j18911vbapx9kx0gqcyn6nkd3bwz52lj-make-
> boot0-4.2.1.drv' failed

This looks very much like the tar segfault I encountered when I last
played with the Hurd port.

My notes say this:

--8<---cut here---start->8---
- tar fails to run when building gnu-make-boot0
./pre-inst-env  guix build -e '(@@ (gnu packages commencement) gnu-make-boot0))'
here’s the error:
building /gnu/store/ybi3cyxqwm55gvwn9i1nczg2ns5ha34q-make-4.2.1.tar.xz.drv...   

/hurd/crash: 
/gnu/store/dqlhjyvg0n8v1kdvwfpliqy46n7kpjqb-bootstrap-binaries-0/bin/tar cvfa 
/gnu/store/p278mqb3aa0xrkrrw4rg1fxbb19hbdyh-make-4.2.1.tar.xz --mtime=@0 
--owner=root --group=root --sort=name make-4.2.1(2316) crashed, signal {no:1 1, 
code:8176, error:2}, exception {1, code:2, subcode:8176}, PCs: {0x8089ce7, 0x 
815091c}, writing core file.  


This works:
/gnu/store/dqlhjyvg0n8v1kdvwfpliqy46n7kpjqb-bootstrap-binaries-0/bin/tar cvfa 
hello.tar.xz /tmp

But it segfaults with “--mtime=@0”
--8<---cut here---end--->8---

> The cross-built xz is definitely buggy, I don't know about the other files at:
> gnu/packages/bootstrap/i586-gnu: bash mkdir tar xz
>
> Maybe there are other buggy cross-built binaries.

Quite likely!

> A question: The gcc used is very old: 5.5.0, is i possible that guix could
> upgrade to a newer version, preferrably later than gcc-7.

How would that help?  Or is it just a guess that a later GCC would be
better here?

On the “core-updates” branch we are using a later GCC already.

-- 
Ricardo

Re: 01/02: services: cups: Rename ‘retry-this-job’ to ‘retry-current-job’.

[Ludovic Courtès]

Tobias Geerinckx-Rice  skribis:

> Tobias Geerinckx-Rice 写道：
>> ‘retry-this-job’ was never[0] valid, so I think failing loudly is
>> the right thing to do here.  CUPS wouldn't have known what to do
>> with
>> it anyway.
>
> Sorry, sent too soon.  So: this was never more than a broken typo
> (albeit one that slipped in via CUPS itself), I don't think it
> deserves too much attention.  (Which I've now just given it :-)

Heh, makes sense.  :-)

Ludo’.

Re: ‘computed-origin-method’ for IceCat and ungoogled-chromium

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> Ludovic Courtès  writes:
>
>> Hello Mark & Marius!
>>
>> Somehow I hadn’t noticed the clever trick with ‘computed-origin-method’
>> in IceCat and ungoogled-chromium, and it came to me as a shock today.
>> ;-)
>
> Yes, I probably should have brought wider attention to what I did there.
> Sorry about that.  Initially I needed it on short notice for the
> IceCat-60.5.0 security update, which turned out to be impractical to do
> by my earlier method, where I would cherry-pick dozens of patches from
> the upstream repo, because I found to my dismay that Mozilla had
> reindented the entire source tree, including the ESR branch.

Much appreciated!

> Anyway, the purpose of ‘computed-origin-method’ is simply to work around
> some limitations in 'patch-and-repack' and snippets.  Most importantly,
> I needed to produce an output directory and tarball name starting with
> "icecat-" from an original source tarball named "firefox-...".

OK.

>> I stumbled upon it while traversing packages with ‘guix lint’ because
>> they violated the assumption that the ‘sha256’ field of  is
>> always a bytevector.
>>
>> I suspect this could be rewritten by using ‘computed-file’ instead of
>> .  This should be clearer, I think, notably because it would
>> avoid exposing a “non-conforming” .
>>
>> WDYT?
>
> I'd be glad to switch to another mechanism, but I'm not sure
> ‘computed-file’ can be made to do what I need.  The problem there is
> that ‘computed-file’ needs a G-expression.  I found that I needed to
> delay evaluation of the G-expression used to produce 'icecat-source', to
> cope with our widespread cyclic module dependencies.

Bah, true, that’s terrible.  We could fix it by making ‘source’ a
delayed or a thunked field, but that’s not great (notably because it
might have a performance impact.)

Another option (thinking out loud) would be to have a gexp compiler for
promises, such that you can splice a promise in a gexp and have it
transparently forced when needed.

Thoughts?

> Also, I wasn't sure if all of the code that pattern matches on package
> 'source' fields handle non-origins properly.

It’s supposed to (whereas sha256 = #f is not an intended use case.)

> Finally, I should mention that in addition to IceCat and
> ungoogled-chromium, our linux-libre source tarballs are also now
> generated using ‘computed-origin-method’.  That raises an additional
> issue: in the case of our 'linux-libre' packages, we apply patches
> *after* running the code that generates the pristine linux-libre
> tarball.  With ‘computed-origin-method’, I can add 'patches' to that
> origin type, and it will do what I need.  I'm not sure if this can be
> done with ‘computed-file’ or snippets, even if the other limitations are
> addressed.

Good point.

Besides, I really like it that the deblob and firefox-to-icecat scripts
are run directly in derivations; it makes more sense than downloading
pre-processed tarballs!

Thanks,
Ludo’.

Re: Using CLISP instead of CCL to bootstrap SBCL

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> I had a look into this, and it seems that CCL cannot currently be built
> without itself :(

That’s what Mark was hinting at, and that’s something people here and at
 have been trying hard to fix, so let’s not
spoil it!  ;-)

Ludo’.

Re: Gitweb is in some ways superior to cgit

[Ludovic Courtès]

Mark H Weaver  skribis:

> Here are two views of the same commit, my recent merge of 'master' into
> 'core-updates':
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=0481289cbccba2646bf654f0ae49ac9c45602d5d
>   
> https://git.savannah.gnu.org/gitweb/?p=guix.git;a=commitdiff;h=0481289cbccba2646bf654f0ae49ac9c45602d5d
>
> I think it speaks for itself.  Thoughts?

Woow, I somehow had come to believe that Gitweb is “not as good”, and I
was wrong!

Ludo’.

Re: Seeking Outreachy internship project proposals

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2019. szept. 3., K,
14:30):

> Hello!
>
> Gábor Boskovits  skribis:
>
> > GNU Guix is participating in the Outreachy internship program.
> Outreachy's
> > goal is to support people from groups underrepresented in the technology
> > industry. Interns will work remotely with mentors from our community.
> >
> > We are seeking mentors to propose projects that Outreachy interns can
> work
> > on during their internship.
> >
> > Sept. 24, 2019 at 4 pm UTC is the deadline to submit projects:
> > https://www.outreachy.org/communities/cfp/gnu-guix/
>
> Gábor, what about writing a blog post for the web site, with links to
> practical info, to blog posts by previous interns, things like that?
> We could promote it to maximize visibility.
>

Ok, I will look into that later today.


> Thanks for taking care of this, and I hope it’ll be as successful as the
> previous internships!
>
> Thanks,
> Ludo’.
>

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: "Server does not allow request for unadvertised object"

[Ludovic Courtès]

Hi,

Hartmut Goebel  skribis:

> Initialized empty Git repository in
> /gnu/store/…-guix-1.0.1-4.c902458-checkout/.git/
> error: Server does not allow request for unadvertised object
> c902458863d1d341ffd74970b75e69c2bb848183

I’ve seen that coming from different Git servers.  I’m not sure what it
means, but it seems to be harmless.

Ludo’.

Re: Seeking Outreachy internship project proposals

[Ludovic Courtès]

Hello!

Gábor Boskovits  skribis:

> GNU Guix is participating in the Outreachy internship program. Outreachy's
> goal is to support people from groups underrepresented in the technology
> industry. Interns will work remotely with mentors from our community.
>
> We are seeking mentors to propose projects that Outreachy interns can work
> on during their internship.
>
> Sept. 24, 2019 at 4 pm UTC is the deadline to submit projects:
> https://www.outreachy.org/communities/cfp/gnu-guix/

Gábor, what about writing a blog post for the web site, with links to
practical info, to blog posts by previous interns, things like that?
We could promote it to maximize visibility.

Thanks for taking care of this, and I hope it’ll be as successful as the
previous internships!

Thanks,
Ludo’.

Re: core-updates fails to "make dist" missing guix-manual.pot

[Ludovic Courtès]

Hello,

Vagrant Cascadian  skribis:

> I'm trying to generate a tarball from core-updates using "make
> dist". With the following commit it always ends in a failure due to
> missing guix-manual.pot:
>
>   893c2df00daa4e6dd6a7ff3813d7df5329877f9e
>   Merge branch 'master' into core-updates
>
>   $ ./bootstrap && ./configure --localstatedir=/var && make dist
>   
>   make[2]: *** No rule to make target 'po/doc/guix-manual.pot', needed by
>   'distdir-am'.  Stop.
>   make[2]: Leaving directory '/home/vagrant/src/guix-tarball'
>   make[1]: *** [Makefile:4967: distdir] Error 2
>   make[1]: Leaving directory '/home/vagrant/src/guix-tarball'
>   make: *** [Makefile:5072: dist] Error 2

Did that problem eventually vanish?

If not, did you try “make doc-pot-update”?

I think that’s supposed to happen automatically, but maybe something’s
wrong.

HTH,
Ludo’.

Re: IPv6 Guix

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:
>
>> Ludovic Courtès  writes:
>>
>>> dftxbs3e  skribis:
>>>
 It looks like ci.guix.gnu.org does not have  records.
>>>
>>> Ricardo, do you know if berlin is accessible over IPv6?  If it is, I
>>> agree we should add those  records.
>>
>> I’m waiting for a response from the campus network team.  I asked them
>> to confirm if it’s possible to reach the server via IPv6 and to update
>> the firewall rules if it isn’t.
>
> The campus firewall doesn’t route IPv6 yet, so it’s not yet possible to
> access the server via its IPv6 address.  Sorry.

OK, thanks for asking!

Ludo’.

Re: LDAP authentication + Configuring PAM

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

>> Ricardo Wurmus  skribis:

[...]

>>> I worked around this (by lowering the G-expression first), but it’s
>>> ugly.  And even then I still have the problem that I can’t control the
>>> order of PAM entries at all.
>>
>> Perhaps we could add a field in  that would be
>> transformation procedure that takes the complete list of entries?
>
> I don’t know if that makes sense without a guaranteed order.

Precisely: that procedure would allow you to reorder the entries.

>>> I also recommend using “sufficient” as the default keyword for
>>> “pam_unix.so” and ending the stack with “required pam_deny.so”.  This
>>> would make it easier to extend the stack without having to rewrite
>>> existing module entries.
>>
>> Why not.
>
> As far as I can tell this should not have any downsides.

Cool, feel free to push this change.

>> Tricky issues!  NixOS has lots of hard-coded cases instead of a generic
>> way to extend PAM settings:
>>
>>   
>> https://github.com/NixOS/nixpkgs/blob/release-19.03/nixos/modules/security/pam.nix#L304
>
> I prefer the Guix way here.  It is more generic and more flexible.  It
> just misses a few convenience procedures, in my opinion.
>
>> From what you wrote, it may be that PAM configuration is simply not
>> “composable”, in the sense that you cannot assemble bits without viewing
>> the global picture.
>
> I think individual services cannot generically extend the PAM
> configuration, because they cannot know what order is correct with
> respect to all other services that contribute to the configuration.  But
> they *can* provide at least their own entries.

The ideal view is that services contribute bits here and there in the
service graph, such that separation of concern is guaranteed: you can
add a complex service to your ‘services’ field without knowing how it’s
implemented, and the service automatically tweaks other services as
needed and adds any services it depends on.

In the case of PAM, that may simply be impossible: each service can
contribute its own PAM entries, sure, but then, who’s in charge of
ensuring that the final list of entries is correctly ordered?  How does
one know what the “correct order” is?

My understanding is that determining the correct order needs to be done
by the admin, who has to be (1) well versed in PAM, and (2)
knowledgeable about all the services that add PAM entries.

If that really is the case, it’s very different from the ideal view
above.

Thanks,
Ludo’.

Status update+patches:Re: I managed to build guix natively on Debian GNU/Hurd , what's next?

[Svante Signell]

On Sun, 2019-09-01 at 20:01 +0200, Svante Signell wrote:
...

I think it is time to wrap up a little now on the Hurd port.
Attached are patches I made. Save for some indentation misses.
gnu_local.mk.diffguix_scripts_perform-download.scm.diff
gnu_packages_bootstrap.scm.diff  nix_libstore_build.cc.diff
guix_build_syscalls.scm.diff

guix_scripts_perform-download.scm.diff and nix_libstore_build.cc.diff
are temporary fixes enable to downloads as root.

guix_build_syscalls.scm.diff should be made conditional on (set-thread-name
name) for Linux and non-Linux. Don't know too much scheme coding yet.

gnu_local.mk.diff and gnu_package_bootstrap.scm.diff
are essentially the same as Ricardo Wurmus made. I used my cross-built files
though:
binutils-static-stripped-2.31.1-i586-pc-gnu.tar.xz
gcc-stripped-5.5.0-i586-pc-gnu.tar.xz
glibc-stripped-2.28-i586-pc-gnu.tar.xz
guile-static-stripped-2.2.4-i586-pc-gnu.tar.xz
static-binaries-0-i586-pc-gnu.tar.xz

The guix-daemon was started by:
./pre-inst-env ./guix-daemon --debug --disable-chroot --no-substitutes

Found out that the built static xz binary was erroring out:
Error creating a pipe: Function not implemented
so I replaced it with the native dynamically built xz, both at
gnu/packages/bootstrap/i586-gnu and in static-binaries-0-i586-pc-gnu.tar.xz.

That made ./pre-inst-env guix build -S hello work.

Then I continued with as Richardo wrote:
./pre-inst-env  guix build -e '(@@ (gnu packages commencement) 
gnu-make-boot0))' 
2>&1 | tee ../pre-inst-env_guix-build-e-no-chroot_new-hash.log
The build went a lot further, but failed here:
 
successfully built /gnu/store/6sybpxd8hy07h4fqf4wyblxrsi17r4zn-gcc-bootstrap-
0.drv
building /gnu/store/h0y1izzm1nxr3gqwagg84dnssa723sby-make-4.2.1.tar.xz.drv...
builder for `/gnu/store/h0y1izzm1nxr3gqwagg84dnssa723sby-make-4.2.1.tar.xz.drv'
failed with exit code 1
build of /gnu/store/h0y1izzm1nxr3gqwagg84dnssa723sby-make-4.2.1.tar.xz.drv
failed
View build log at '/usr/var/log/guix/drvs/h0/y1izzm1nxr3gqwagg84dnssa723sby-
make-4.2.1.tar.xz.drv.gz'.
cannot build derivation `/gnu/store/j18911vbapx9kx0gqcyn6nkd3bwz52lj-make-boot0-
4.2.1.drv': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/j18911vbapx9kx0gqcyn6nkd3bwz52lj-make-
boot0-4.2.1.drv' failed

Unfortunately the build log is empty.

I also replaced tar at gnu/packages/bootstrap/i586-gnu and in static-binaries-0-
i586-pc-gnu.tar.xz but did not get any further.

The cross-built xz is definitely buggy, I don't know about the other files at:
gnu/packages/bootstrap/i586-gnu: bash mkdir tar xz

Maybe there are other buggy cross-built binaries.

A question: The gcc used is very old: 5.5.0, is i possible that guix could
upgrade to a newer version, preferrably later than gcc-7.

Additionally, it would maybe better to create static binaries built natively on
GNU/Hurd instead of using cross-building? I also tried to build the cross-files
natively but failed:

./pre-inst-env guix build --no-grafts --target=i586-pc-gnu -e '(@@ (gnu packages
make-bootstrap) %static-inputs)' 2>&1 | tee ../rebuild-static-cross-files.log
guix build: error: ("tar" #): not something we can build

Is it possible to modify gnu/packages/make-bootstrap.scm to make this succeed?

Thanks everybody on #guix for your help.

--- a/gnu/local.mk.orig	2019-05-15 15:43:04.0 +0200
+++ b/gnu/local.mk	2019-09-01 21:40:56.0 +0200
@@ -1383,6 +1383,7 @@
 bootstrap_armhf_linuxdir = $(bootstrapdir)/armhf-linux
 bootstrap_aarch64_linuxdir = $(bootstrapdir)/aarch64-linux
 bootstrap_mips64el_linuxdir = $(bootstrapdir)/mips64el-linux
+bootstrap_i586_gnudir = $(bootstrapdir)/i586-gnu
 
 dist_bootstrap_x86_64_linux_DATA =		\
   %D%/packages/bootstrap/x86_64-linux/bash	\
@@ -1414,6 +1415,12 @@
   %D%/packages/bootstrap/mips64el-linux/tar	\
   %D%/packages/bootstrap/mips64el-linux/xz
 
++dist_bootstrap_i586_gnu_DATA =		\
+  %D%/packages/bootstrap/i586-gnu/bash	\
+  %D%/packages/bootstrap/i586-gnu/mkdir	\
+  %D%/packages/bootstrap/i586-gnu/tar	\
+  %D%/packages/bootstrap/i586-gnu/xz
+
 # Those files must remain executable, so they remain executable once
 # imported into the store.
 set-bootstrap-executable-permissions:
--- a/gnu/packages/bootstrap.scm.orig	2019-05-03 14:25:14.0 +0200
+++ b/gnu/packages/bootstrap.scm	2019-09-03 12:07:06.0 +0200
@@ -202,6 +202,8 @@
 "http://alpha.gnu.org/gnu/guix/bootstrap;
 "ftp://alpha.gnu.org/gnu/guix/bootstrap;
 "http://www.fdn.fr/~lcourtes/software/guix/packages;
+"http://berlin.guix.gnu.org/guix/bootstrap;
+"http://178.78.231.178/Guix/bootstrap-tarballs;
 "http://flashner.co.il/guix/bootstrap;))
 
 (define (bootstrap-guile-url-path system)
@@ -212,6 +214,8 @@
 "/20170217/guile-2.0.14.tar.xz")
("armhf-linux"
 "/20150101/guile-2.0.11.tar.xz")
+   ("i586-gnu"
+"/20190901/guile-static-stripped-2.2.4-i586-pc-gnu.tar.xz")
  

Re: Inscrutable error when using “guix deploy”

[Ludovic Courtès]

Hi,

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> I saw this specific error message a few times while I was building 'guix
> deploy'. It means something's been printed that can't be read, which
> (might) be the case if something doesn't have a G-Expression compiler.
> My money is on the target not having a reader for ,
> but as you've observed, the error reporting makes this incredibly
> difficult to diagnose.

We could probably arrange so that ‘gexp->sexp’ reports about objects
without a read syntax that remain in the resulting sexp.

Ludo’.

Re: How to reference external program used in shell-scripts?

[Ricardo Wurmus]

Hi Hartmut,

> Am 09.08.19 um 10:54 schrieb Ricardo Wurmus:
>> Whenever an input is changed the package will be rebuilt, because we
>> can’t know if the presence of a package will affect the build or not.
>>
>> In the case of patching references the presence of the input *will*
>> affect the output (as a reference to the absolute file name will be
>> recorded).  In the case of propagated inputs it’s really the same,
>> expect that the package will also be installed into the target profile.
>
> My concerns are not about building, but about installing. A concrete
> example:
>
>   * Ansible is a Python program running ssh via a path to
> /gnu/store/…-openssh-8.0p1/bin/ssh
>   * Mary installs ansible.
>   * Now openssh shows a serious bug and Mary updates openssh using "guix
> -u openssh"

This is generally not a good idea, because this problem doesn’t only
affect dependent executables but all libraries as well.  Selective
upgrading means that not-upgraded packages will generally not benefit
from fixes.  This can range from libraries for extra features to really
fundamental functionality in glibc.

One could say now that the way around this problem in general would be …
to use a single global namespace for all libraries and all applications
— and this is how we would lose most of the advantages of Guix.

--
Ricardo

Re: GSoC 2019 Recap

[Ludovic Courtès]

Hello!

Alex Sassmannshausen  skribis:

> Christopher Lemmer Webber  writes:
>
>> Hi Jakob,
>>
>> I've already said this off-list, but I feel it's worth repeating
>> on-list: thank you for making "guix deploy" a reality.  So many of us
>> have wanted it for so long, but you did the really important thing: you
>> put in the work, and clearly with great care.  We're glad to have you as
>> part of our community; please do stick around! :)
>>
>>  - Chris
>
> +1 to this!

I’m late to the party but same here, a big +1 from me, Jakob!

The result is impressive in terms of code, and it’s been a pleasure
interacting with you on this.

Thank you!

Ludo’.

Re: How to reference external program used in shell-scripts?

[Hartmut Goebel]

Hi Ricardo,

Am 09.08.19 um 10:54 schrieb Ricardo Wurmus:
> Whenever an input is changed the package will be rebuilt, because we
> can’t know if the presence of a package will affect the build or not.
>
> In the case of patching references the presence of the input *will*
> affect the output (as a reference to the absolute file name will be
> recorded).  In the case of propagated inputs it’s really the same,
> expect that the package will also be installed into the target profile.

My concerns are not about building, but about installing. A concrete
example:

  * Ansible is a Python program running ssh via a path to
/gnu/store/…-openssh-8.0p1/bin/ssh
  * Mary installs ansible.
  * Now openssh shows a serious bug and Mary updates openssh using "guix
-u openssh"

Obviously this will *not* update ansible, and ansible will still use the
old, vulnerable version of openssh.

OTOH, if ansible would run ssh via $PATH, ansible would pick up the new
version of openssh.

FWIW: some way to install openssh automatically along with ansible,
while not specifying a specific version of openssh to be used, thus if
openssh is updated (but ansible is not), ansible will pick up the new
version.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |