Re: Trouble with 'guix download'

[Luther Thompson]

On 12/8/17, Ludovic Courtès  wrote:
> Hi Luther,
> Somebody else reported the same issue and it should be fixed now:
>
>   https://bugs.gnu.org/29570

That fixed it. It downloaded fine today. Thanks!

-- 
Luther Thompson

Guile-Git, bytestructures, libgit2 and Guix 0.14.0

[Paul Boddie]

Hello,

I thought I'd try and see if the latest Guix release might help with the 
problems I described a few days ago, but it looks like there are a few 
additional dependencies, and I am struggling to install them. I'm using Debian 
Jessie, but have also been trying with Debian Stretch.

Guile-Git seems to want scheme-bytestructures, but this seems to be something 
published on GitHub. I can seemingly compile and install it starting out as 
follows:

git clone https://github.com/TaylanUB/scheme-bytestructures.git
cd scheme-bytestructures

At this point, it seems that a modification to SOURCES in Makefile.am is 
required: bytestructures/r6/bytevectors.scm needs to be added. Otherwise, 
later attempts by Guile-Git to use the code will fail. Then...

autoreconf
./configure
make
sudo make install

This puts the library in /usr/local/lib/guile/2.0/site-ccache.

I also found that the packaged version of libgit2 on Debian Jessie doesn't 
export the git_libgit2_init symbol for some reason:

ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: 
git_libgit2_init

So, libgit2 needs to be installed from source as well (having removed the 
packaged version):

git clone https://github.com/libgit2/libgit2.git
cd libgit2
git checkout v0.26.0
mkdir build
cd build
cmake ..
cmake --build .
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local
sudo cmake --build . --target install

This also puts the library in /usr/local/lib/guile/2.0/site-ccache.

Trying to build Guile-Git is more awkward. Here is what I did:

git clone https://gitlab.com/guile-git/guile-git.git
cd guile-git
./bootstrap
./configure GUILE_LOAD_COMPILED_PATH=/usr/local/lib/guile/2.0/site-ccache

It is worth noting that without this extra setting, configure cannot find the 
other libraries. I did wonder whether there might be explicit --with-... 
options for configure, but there doesn't appear to be, at least from the help 
text.

I also found that git/config.scm had some apparently malformed code, possibly 
generated incorrectly, yielding this error when running make:

git/config.scm:23:0: source expression failed to match any pattern in form 
(define %libgit2 "" /usr/local "/lib/libgit2")

So, I edited that file to have the following instead:

(define %libgit2 "/usr/local/lib/libgit2")

Running make also seemed to need the additional setting:

make GUILE_LOAD_COMPILED_PATH=/usr/local/lib/guile/2.0/site-ccache

At this point, Guile-Git, scheme-bytestructures and libgit2 should be 
available and an attempt to compile the Guix tools should be possible. Here is 
what I try and do:

tar zxf guix-0.14.0.tar.gz
cd guix-0.14.0
./bootstrap
./configure GUILE_LOAD_COMPILED_PATH=/usr/local/lib/guile/2.0/site-ccache

Again, without the setting, configure fails to find things. Also, for my 
purposes, I add to gnu/packages/bootstrap.scm a definition for the mipsel 
dynamic linker name:

((string=? system "mipsel-linux") "/lib/ld.so.1")

Then I try and make everything, but the library search path is still a 
problem, so I first have to change the Makefile and remove the following from 
the make-go rule:

unset GUILE_LOAD_COMPILED_PATH ;

Then I actually try and make everything:

make GUILE_LOAD_COMPILED_PATH=/usr/local/lib/guile/2.0/site-ccache

This seems promising until I get an error like this:

  LOAD guix/scripts/pack.scm
Backtrace:
In ice-9/r4rs.scm:
  90: 19 [dynamic-wind # ...]
  90: 18 [dynamic-wind # ...]
In ice-9/eval.scm:
 432: 17 [eval # #]
 432: 16 [eval # #]
 481: 15 [lp (#) (#)]
In ice-9/boot-9.scm:
2864: 14 [resolve-interface (guix scripts pack) #:select ...]
2789: 13 [# # ...]
3065: 12 [try-module-autoload (guix scripts pack) #f]
2401: 11 [save-module-excursion #]
3085: 10 [#]
In unknown file:
   ?: 9 [primitive-load-path "guix/scripts/pack" ...]
In ice-9/eval.scm:
 453: 8 [eval # ()]
 387: 7 [eval # ()]
 387: 6 [eval # ()]
 387: 5 [eval # ()]
 387: 4 [eval # ()]
 387: 3 [eval # ()]
 387: 2 [eval # ()]
 393: 1 [eval # ()]
In unknown file:
   ?: 0 [memoize-variable-access! # #]

ERROR: In procedure memoize-variable-access!:
ERROR: gzip: unbound variable
Makefile:5295: recipe for target 'make-go' failed

I'm clearly doing something wrong or at least inconvenient with the library 
search path, but I don't really know how to troubleshoot this error, either. 
It appears to be the result of running the build-aux/compile-all.scm script on 
the different script files, but I don't see any variable called gzip in the 
guix/scripts/pack.scm script, although it must be said that I don't know 
Scheme that well, so maybe the variable is in another file and I misunderstood 
the backtrace.

Here's hoping that I've done something obviously wrong and that someone might 
be able to tell me what that is!

Paul

Re: Too many heap sections

[Bryan Ferris]

Thanks for the prompt replies,

Ludovic: I have one file, jekyll.scm, which contains jekyll and it's
dependencies, and the only thing I do to it is run `guix package -f
jekyll.scm`. I had assumed that this command would take care of things like
compiling the packages. Is this not the case?

Chris: I probably should've sent the whole file the first time, I was just
worried that a wall of text would be unapproachable. Here's the full file:

(use-modules (guix packages)
 (guix build-system ruby)
 (guix download)
 (guix licenses)
 (gnu packages ruby)
)


(define ruby-sass (package
  (name "ruby-sass")
  (version "3.5.3")
  (source
(origin
  (method url-fetch)
  (uri (rubygems-uri "sass" version))
  (sha256
(base32
  "1167camc4ccqf9lcjlpyf96ji00f0041i7xanj2nm41fkx7kr7kr"
  (build-system ruby-build-system)
  (arguments '(#:phases (modify-phases %standard-phases (delete 'check
  (propagated-inputs
`(("ruby-sass-listen" ,ruby-sass-listen)))
  (synopsis
"  Sass makes CSS fun again. Sass is an extension of CSS, adding
  nested rules, variables, mixins, selector inheritance, and more.
  It's translated to well-formatted, standard CSS using the
  command line tool or a web-framework plugin.
")
  (description
"  Sass makes CSS fun again.  Sass is an extension of CSS, adding
  nested rules, variables, mixins, selector inheritance, and more.
  It's translated to well-formatted, standard CSS using the
  command line tool or a web-framework plugin.
")
  (home-page "http://sass-lang.com/;)
  (license expat)
))


(define ruby-sass-listen (package
  (name "ruby-sass-listen")
  (version "4.0.0")
  (source
(origin
  (method url-fetch)
  (uri (rubygems-uri "sass-listen" version))
  (sha256
(base32
  "0xw3q46cmahkgyldid5hwyiwacp590zj2vmswlll68ryvmvcp7df"
  (build-system ruby-build-system)
  (arguments '(#:phases (modify-phases %standard-phases (delete 'check
  (propagated-inputs
`(("ruby-rb-fsevent" ,ruby-rb-fsevent)
  ("ruby-rb-inotify" ,ruby-rb-inotify)))
  (synopsis
"This fork of guard/listen provides a stable API for users of the ruby
Sass CLI")
  (description
"This fork of guard/listen provides a stable API for users of the ruby
Sass CLI")
  (home-page "https://github.com/sass/listen;)
  (license expat)
))

(define ruby-forwardable-extended (package
  (name "ruby-forwardable-extended")
  (version "2.6.0")
  (source
(origin
  (method url-fetch)
  (uri (rubygems-uri "forwardable-extended" version))
  (sha256
(base32
  "15zcqfxfvsnprwm8agia85x64vjzr2w0xn9vxfnxzgcv8s699v0v"
  (build-system ruby-build-system)
  (arguments '(#:phases (modify-phases %standard-phases (delete 'check
  (synopsis
"Forwardable with hash, and instance variable extensions.")
  (description
"Forwardable with hash, and instance variable extensions.")
  (home-page
"http://github.com/envygeeks/forwardable-extended;)
  (license expat)
))

(define ruby-public-suffix (package
  (name "ruby-public-suffix")
  (version "3.0.1")
  (source
(origin
  (method url-fetch)
  (uri (rubygems-uri "public_suffix" version))
  (sha256
(base32
  "0mvzd9ycjw8ydb9qy3daq3kdzqs2vpqvac4dqss6ckk4rfcjc637"
  (build-system ruby-build-system)
  (arguments '(#:phases (modify-phases %standard-phases (delete 'check
  (synopsis
"PublicSuffix can parse and decompose a domain name into top level
domain, domain and subdomains.")
  (description
"PublicSuffix can parse and decompose a domain name into top level
domain, domain and subdomains.")
  (home-page
"https://simonecarletti.com/code/publicsuffix-ruby;)
  (license expat)
))

(define ruby-addressable (package
  (name "ruby-addressable")
  (version "2.5.2")
  (source
(origin
  (method url-fetch)
  (uri (rubygems-uri "addressable" version))
  (sha256
(base32
  "0viqszpkggqi8hq87pqp0xykhvz60g99nwmkwsb0v45kc2liwxvk"
  (build-system ruby-build-system)
  (arguments '(#:phases (modify-phases %standard-phases (delete 'check
  (propagated-inputs
`(("ruby-public-suffix" ,ruby-public-suffix)))
  (synopsis
"Addressable is a replacement for the URI implementation that is part of
 Ruby's standard library. It more closely conforms to the relevant RFCs
and
 adds support for IRIs and URI templates.
")
  (description
"Addressable is a replacement for the URI implementation that is part of
 Ruby's standard library.  It more closely conforms to the relevant
RFCs and
 adds support for IRIs and URI templates.
  ")
  (home-page
"https://github.com/sporkmonger/addressable;)
  (license #f)
))


(define ruby-colorator (package
  (name "ruby-colorator")
  (version "1.1.0")
  (source
(origin
  (method url-fetch)
  (uri (rubygems-uri "colorator" version))
  (sha256
(base32
  

Re: Bootstrapping on a new platform

[Paul Boddie]

On Friday 8. December 2017 14.40.14 Paul Boddie wrote:
> On Friday 8. December 2017 11.28.38 Ludovic Courtès wrote:
> > 
> > Could you search in the strace output for the ‘clone’ call that failed
> > with EINVAL?  It’s probably the one from nix/libstore/build.cc.

[...]

> I'm tracing the daemon here. Should I also be tracing something else?

Sorry, I found that I should be running strace using the -o, -f and -ff 
options:

strace -o /tmp/guix -f -ff /usr/local/bin/guix-daemon \
   --build-users-group=guixbuild

This gave me the following in the parent process log (/tmp/guix.793):

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x404c5f28) = 797
close(4)= 0
accept(3, 0xbfff7224, [110])= ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=797, si_uid=0, 
si_status=0, si_utime=51, si_stime=524} ---
waitpid(-1, NULL, WNOHANG)  = 797

This resembling what I showed before. Meanwhile in the child process log 
(/tmp/guix.797) the clone call with EINVAL is this one:

clone(child_stack=0xbffedfa4, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|
CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EINVAL (Invalid argument)

Again, this is using the 4.9.67 kernel.

Paul

Re: Bootstrapping on a new platform

[Paul Boddie]

On Friday 8. December 2017 11.28.38 Ludovic Courtès wrote:
> 
> Paul Boddie  skribis:
> > These steps are what I thought might be needed. So, I did the following
> > on my i386-linux-gnu system:
> > 
> > tar zxf guix-0.13.0.tar.gz
> 
> 0.14.0 was released yesterday, I’d suggest starting from that.

I was actually drafting a mail about that yesterday, but that is another story 
with different complications (building Guile-Git, scheme-bytestructures).

> > # Add to gnu/packages/bootstrap.scm:
> > # ((string=? system "mipsel-linux") "/lib/ld.so.1")
> > make
> > sudo make install
> > 
> > This got me the daemon again. Having set up the build users and group, I
> > then started the daemon...
> > 
> > sudo /usr/local/bin/guix-daemon --build-users-group=guixbuild
> 
> > ...and ran the build command for the binaries:
> I’d suggest enabling substitutes if you don’t want to build everything
> locally:
> 
>   https://www.gnu.org/software/guix/manual/html_node/Substitutes.html

I wouldn't mind building things locally, though. Previously, I wanted to avoid 
building cross-compilers, but this time I'm trying to do the whole thing.

> > guix build --target=mipsel-linux-gnu bootstrap-tarballs
> > 
> > I then got a couple of errors that halted the build process. Here's the
> > start of the first error:
> > 
> > output path
> > `/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2' should
> > have sha256 hash
> > `14l06m7nvcvb0igkbip58x59w3nq6315k6jcz3wr9ch1rn9d44bc', instead has
> > `1z91vb2i4d61fbrz7hdrsxiw3ksdzf372bgdzwsn75b72ndbi6lg'
> 
> That would suggest either that gcc-4.9.4.tar.bz2 was modified on
> ftp.gnu.org (unlikely), or that there’s something fishy going on on the
> network (captive portal, DNS hijacking, etc.)  Ideas?

I do wonder about this kind of thing, but I'm using fibre-based broadband. 
Could it be mirroring issues? I tend to get checksum issues when updating 
recent Debian releases that are resolved when retrying and that I've regarded 
as being related to files being updated when apt tries to read them all, but I 
suppose there could be other things happening. (I also used to get this on a 
previous cable-based broadband provider, though.)

Actually, running sha256sum yields this:

sha256sum /gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2 
326efcf243fd917d5e57b930cc8b51c79260176099fd4f5cbc38b1473bd246a3  
/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2

Is this the right way of generating the hash?

> > Running the build command again seems to either resolve this problem or
> > make it go away somehow. However, I then get a persistent error:
> > 
> > guix build: error: build failed: cloning builder process: Invalid
> > argument
> > 
> > Looking at the archives, I see that this happened before (reported by
> > Efraim):
> > 
> > https://lists.gnu.org/archive/html/guix-devel/2016-07/msg00144.html
> > 
> > I didn't see any obvious conclusion. So, I ran the daemon using strace
> > and looked at the clone system call that supposedly causes this problem:
> > 
> > clone(child_stack=0,
> > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> > child_tidptr=0x404c5f28) = 25426
> 
> Could you search in the strace output for the ‘clone’ call that failed
> with EINVAL?  It’s probably the one from nix/libstore/build.cc.

There isn't one that I can find. All I get is this:

write(2, "accepted connection from pid 157"..., 46accepted connection from pid 
1570, user paulb
) = 46
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x404c5f28) = 1572
close(4)= 0
accept(3, 0xbfb09d84, [110])= ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1572, si_uid=0, 
si_status=0, si_utime=61, si_stime=6} ---
waitpid(-1, NULL, WNOHANG)  = 1572
waitpid(-1, NULL, WNOHANG)  = -1 ECHILD (No child processes)
sigreturn() (mask [])   = -1 EINTR (Interrupted system call)

> > For the record, I'm running all this in a User Mode Linux instance,
> > mostly because my main system doesn't support the prerequisites for
> > building Guix.
> 
> What kernel version do you use?  guix-daemon requires namespace support,
> but this is a relatively old feature.

This is an older kernel: 3.2.62. I chose this a while ago when setting up 
various instances, and this was something that I knew worked with the Debian 
versions I wanted to run.

> Otherwise it might be some limitation of User Mode Linux; I’ve never
> tried.

I tried UML with a 4.9.67 kernel (and CONFIG_NAMESPACES=y) but still got the 
error. There's still only one clone system call:

write(2, "accepted connection from pid 721"..., 45accepted connection from pid 
721, user paulb
) = 45
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x404c5f28) = 723
close(4)= 0
accept(3, 

Re: "guix-latest" differs when two users run "guix pull" from same commit

[Ludovic Courtès]

Chris Marusich  skribis:

> Chris Marusich  writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Chris Marusich  skribis:
>>>
 When two users run "guix pull" using the same commit, two different
 versions of "guix-latest" get built.  This surprised me, and in any case
 it seems inefficient to build the same version of Guix two times.  Why
 do two different derivations get built?
>>>
>>> That’s a bug!  :-)
>>
>> I see!  Nice to know my suspicions were correct.
>
> Ludo, did you fix this recently?  Anecdotally, I noticed that the
> problem no longer occurs using a recent version of Guix.

I know that it’s fixed in the new ‘guix pull’ strategy I’ve been working
on¹, but in master nothing has changed.

Ludo’.

¹ https://bugs.gnu.org/27284

Re: guix pack

[Ludovic Courtès]

Hi,

ren...@openmailbox.org skribis:

> I am currently updating my Guix repository in Debian/Hurd, but I do not have 
> guile-git installed that is required.
> Is it possible to use the packages generated by 'guix pack guile-git' to 
> compile a new version of Guix?

You mean building it on GNU/Linux and using it on GNU/Hurd?  The .go
files would be compatible with those from i686-linux, but libgit2.so
from GNU/Linux would obviously not be usable on GNU/Hurd.

So I think you really need to build guile-git on GNU/Hurd (or perhaps to
cross-compile it from GNU/Linux.)

Also, note that if you unpack a tarball created by ‘guix pack’, the
store items that are added are still unknown to the GC and considered
dead.  This is because the store consists not just of /gnu/store, but
also of /var/guix/db/db.sqlite.

Instead, you should use ‘guix archive’ or ‘guix copy’ when transferring
store items from one machine to another.

HTH!

Ludo’.

Re: Too many heap sections

[Ludovic Courtès]

Hi Bryan,

Bryan Ferris  skribis:

> I have recently (re-)installed Guix, and I am trying to package Jekyll so
> that I can build my website on this system. I used `guix import gem` to get
> started, and then repeated the process for a number of it's dependencies.
> Now when I try to build it (with `guix package -f jekyll.scm`) I get the
> following error:
>
> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
>
> To me, this sounds like I'm using too much RAM.

IIRC it’s a warning, not an error, but it has to do with Guile consuming
too much memory, indeed.

It shouldn’t happen when all the package .scm files have been compiled.
Is it the case?

HTH,
Ludo’.

Re: Bootstrapping on a new platform

[Ludovic Courtès]

Hi Paul

Paul Boddie  skribis:

> These steps are what I thought might be needed. So, I did the following on my 
> i386-linux-gnu system:
>
> tar zxf guix-0.13.0.tar.gz

0.14.0 was released yesterday, I’d suggest starting from that.

> # Add to gnu/packages/bootstrap.scm:
> # ((string=? system "mipsel-linux") "/lib/ld.so.1")
> make
> sudo make install
>
> This got me the daemon again. Having set up the build users and group, I then 
> started the daemon...
>
> sudo /usr/local/bin/guix-daemon --build-users-group=guixbuild
>
> ...and ran the build command for the binaries:

I’d suggest enabling substitutes if you don’t want to build everything
locally:

  https://www.gnu.org/software/guix/manual/html_node/Substitutes.html

> guix build --target=mipsel-linux-gnu bootstrap-tarballs
>
> I then got a couple of errors that halted the build process. Here's the start 
> of the first error:
>
> output path `/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2' 
> should have sha256 hash 
> `14l06m7nvcvb0igkbip58x59w3nq6315k6jcz3wr9ch1rn9d44bc', instead has 
> `1z91vb2i4d61fbrz7hdrsxiw3ksdzf372bgdzwsn75b72ndbi6lg'

That would suggest either that gcc-4.9.4.tar.bz2 was modified on
ftp.gnu.org (unlikely), or that there’s something fishy going on on the
network (captive portal, DNS hijacking, etc.)  Ideas?

> Running the build command again seems to either resolve this problem or make 
> it go away somehow. However, I then get a persistent error:
>
> guix build: error: build failed: cloning builder process: Invalid argument
>
> Looking at the archives, I see that this happened before (reported by Efraim):
>
> https://lists.gnu.org/archive/html/guix-devel/2016-07/msg00144.html
>
> I didn't see any obvious conclusion. So, I ran the daemon using strace and 
> looked at the clone system call that supposedly causes this problem:
>
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
> child_tidptr=0x404c5f28) = 25426

Could you search in the strace output for the ‘clone’ call that failed
with EINVAL?  It’s probably the one from nix/libstore/build.cc.

> For the record, I'm running all this in a User Mode Linux instance, mostly 
> because my main system doesn't support the prerequisites for building Guix. 

What kernel version do you use?  guix-daemon requires namespace support,
but this is a relatively old feature.

Otherwise it might be some limitation of User Mode Linux; I’ve never
tried.

Thanks,
Ludo’.