Re: Cross-compilation, Guix "system", and GNU "triplet"

2017-11-27 Thread Chris Marusich 
l...@gnu.org (Ludovic Courtès) writes:

> The ABI and file format are entirely (or almost entirely) the
> responsibility of user-land software (how you configure the toolchain
> determines what ABI you use, for instance.)  Thus they’re necessarily
> captured by the dependency graph; no need to store that information
> elsewhere.
>
> ...
> 
> It’s the toolchain that shows up in the graph that determines what ABI
> is targeted.

The Guix manual makes it sound like the Guix system string can identify
more than just the CPU architecture and kernel.  Specifically, in the
section titled "GNU Distribution", it says the following:

‘armhf-linux’
 ARMv7-A architecture with hard float, Thumb-2 and NEON, using the
 EABI hard-float application binary interface (ABI), and Linux-Libre
 kernel.

‘aarch64-linux’
 little-endian 64-bit ARMv8-A processors, Linux-Libre kernel.  This
 is currently in an experimental stage, with limited support.  *Note
 Contributing::, for how to help!

‘mips64el-linux’
 little-endian 64-bit MIPS processors, specifically the Loongson
 series, n32 ABI, and Linux-Libre kernel.


Is this langugae too specific?

-- 
Chris


signature.asc
Description: PGP signature

Re: bug#24841: Cross-building bootstrap binaries fail in current master

2017-11-27 Thread Chris Marusich 
l...@gnu.org (Ludovic Courtès) writes:

>> For efraim and for myself,
>>
>> guix build --target=mips64el-linux-gnu bootrap-tarballs
>>
>> got broken with commit
>>
>> b9bc6e842066b066ebdf9eaf75d41753598d75b5
>>

This still fails.  The error I see today, using commit
5aa6e0d04a3f9dea06b9d35f04fa709b31e4b343, is the following:

--8<---cut here---start->8---
$ ./pre-inst-env guix build --substitute-urls='https://mirror.hydra.gnu.org 
https://hydra.gnu.org' --target=mips64el-linux-gnu bootstrap-tarballs
@ build-started 
/gnu/store/ybqid1nca0wjf0mvph82hl8f1dav4ann-make-boot0-4.2.1.drv - x86_64-linux 
/var/log/guix/drvs/yb//qid1nca0wjf0mvph82hl8f1dav4ann-make-boot0-4.2.1.drv.bz2
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/bdbi6mlyci8d98szqhyzwxbb2pd6kw9w-gcc-cross-x86_64-linux-5.4.0/bin:/gnu/store/pdl320cy7axlq8ry87jqid7m0sgnm56n-binutils-cross-x86_64-linux-2.28/bin'
environment variable `CROSS_LIBRARY_PATH' set to 
`/gnu/store/jb6xbkm6jchhbp9l9nm05qnn3jzlnczl-glibc-bootstrap-0/lib:/gnu/store/inwi6s9x140rv8qhn7z3cpl2sj8in4vq-gcc-bootstrap-0/lib:/gnu/store/n47km143d64pbl8r55w741gpplg62jji-glibc-cross-x86_64-linux-2.25/lib'
environment variable `CROSS_C_INCLUDE_PATH' set to 
`/gnu/store/jb6xbkm6jchhbp9l9nm05qnn3jzlnczl-glibc-bootstrap-0/include:/gnu/store/inwi6s9
x140rv8qhn7z3cpl2sj8in4vq-gcc-bootstrap-0/include:/gnu/store/n47km143d64pbl8r55w741gpplg62jji-glibc-cross-x86_64-linux-2.25/include:/gnu/store/zm415fv9i70ablx8lpz2dmh4iyj7l5hy-linux-libre-headers-cross-x86_64-linux-4.4.47/include'
environment variable `CROSS_CPLUS_INCLUDE_PATH' set to 
`/gnu/store/jb6xbkm6jchhbp9l9nm05qnn3jzlnczl-glibc-bootstrap-0/include:/gnu/store/inwi6s9x140rv8qhn7z3cpl2sj8in4vq-gcc-bootstrap-0/include:/gnu/store/n47km143d64pbl8r55w741gpplg62jji-glibc-cross-x86_64-linux-2.25/include:/gnu/store/zm415fv9i70ablx8lpz2dmh4iyj7l5hy-linux-libre-headers-cross-x86_64-linux-4.4.47/include'
environment variable `CROSS_OBJC_INCLUDE_PATH' set to 
`/gnu/store/jb6xbkm6jchhbp9l9nm05qnn3jzlnczl-glibc-bootstrap-0/include:/gnu/store/inwi6s9x140rv8qhn7z3cpl2sj8in4vq-gcc-bootstrap-0/include:/gnu/store/n47km143d64pbl8r55w741gpplg62jji-glibc-cross-x86_64-linux-2.25/include:/gnu/store/zm415fv9i70ablx8lpz2dmh4iyj7l5hy-linux-libre-headers-cross-x86_64-linux-4.4.47/include'
environment variable `CROSS_OBJCPLUS_INCLUDE_PATH' set to 
`/gnu/store/jb6xbkm6jchhbp9l9nm05qnn3jzlnczl-glibc-bootstrap-0/include:/gnu/store/inwi6s9x140rv8qhn7z3cpl2sj8in4vq-gcc-bootstrap-0/include:/gnu/store/n47km143d64pbl8r55w741gpplg62jji-glibc-cross-x86_64-linux-2.25/include:/gnu/store/zm415fv9i70ablx8lpz2dmh4iyj7l5hy-linux-libre-headers-cross-x86_64-linux-4.4.47/include'
environment variable `GUIX_LOCPATH' unset
environment variable `CPATH' set to 
`/gnu/store/bdbi6mlyci8d98szqhyzwxbb2pd6kw9w-gcc-cross-x86_64-linux-5.4.0/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/bdbi6mlyci8d98szqhyzwxbb2pd6kw9w-gcc-cross-x86_64-linux-5.4.0/lib'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
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/ybqid1nca0wjf0mvph82hl8f1dav4ann-make-boot0-4.2.1.drv' 
failed with exit code 1
@ build-failed /gnu/store/ybqid1nca0wjf0mvph82hl8f1dav4ann-make-boot0-4.2.1.drv 
- 1 builder for 
`/gnu/store/ybqid1nca0wjf0mvph82hl8f1dav4ann-make-boot0-4.2.1.drv' failed with 
exit code 1
cannot build derivation 
`/gnu/store/bb8hq0px9ij03nmls8a0j2ak248f9lyx-file-boot0-5.30.drv': 1 
dependencies couldn't be built
guix build: error: build failed: build of 
`/gnu/store/bb8hq0px9ij03nmls8a0j2ak248f9lyx-file-boot0-5.30.drv' failed
--8<---cut here---end--->8---

>> Probably building with --no-grafts is a suitable work-around, or
>> cross-building expat beforehand (thus I won't need grafting) but I am
>> leaving my store untoched for a while to be able to produce a proper
>> fix.
>
> Yeah, I’d suggest using --no-grafts until this is fixed.

Are you sure this work-around works?  When I add --no-grafts, I get the
following error:

--8<---cut here---start->8---
$ ./pre-inst-env guix build --substitute-urls='https://mirror.hydra.gnu.org 
https://hydra.gnu.org' --no-grafts --target=mips64el-linux-gnu 
bootstrap-tarballs
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://hydra.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/x9wixafhlhrwaimp5dyf4g3m4b900h9y-bootstrap-tarballs-0.drv
   /gnu/store/hi7magp0zhkrd7fy25vwv2skl2x3j2lv-guile-static-2.2.2.drv

Re: boot the Hurd with Guix

2017-11-27 Thread rennes 
Hello,

I update the download link:

https://ombx.io/ipoWt9uK

Re: Building Docker images of GuixSD

2017-11-27 Thread Christopher Baines 

Chris Marusich writes:

> Hi Ludo and others following along,

...

> Thanks for reading this far.  I look forward to hearing your thoughts!

Awesome stuff Chris, I've tried this myself, on a Debian machine with
Docker installed.

I struggled getting root, as su and sudo didn't seem to work, until I
realised I could just replace alice with root in the "docker exec"
command...

Anyway, when I got root, I could tell that the system hadn't come up
correctly. The problem seemed to be related to cgroups.

  root@komputilo /# mount -t cgroup /sys/fs/cgroup/cpu
  mount: /sys/fs/cgroup/cpu: cgroup already mounted on
  /sys/fs/cgroup/systemd.

  root@komputilo /# herd status
  Started:
   + file-system-/sys/fs/cgroup/perf_event
   + file-system-/dev/shm
   + host-name
   + root
   + file-system-/sys/fs/cgroup
   + file-system-/sys/fs/cgroup/cpuset
   + file-system-/dev/pts
   + user-file-systems
   + root-file-system
   + file-system-/gnu/store
   + file-system-/sys/fs/cgroup/freezer
   + file-system-/sys/fs/cgroup/memory
   + file-system-/sys/fs/cgroup/devices
   + file-system-/sys/fs/cgroup/blkio
  Stopped:
   - file-system-/sys/fs/cgroup/hugetlb
   - file-system-/sys/fs/cgroup/cpuacct
   - file-system-/sys/fs/cgroup/cpu
   - guix-daemon
   - file-systems
   - syslogd
   - urandom-seed
   - nscd
   - user-homes
   - user-processes

  root@komputilo /# herd start guix-daemon
  herd: exception caught while executing 'start' on service 
'file-system-/sys/fs/cgroup/cpu':
  ERROR: In procedure mount: mount "cgroup" on "///sys/fs/cgroup/cpu": Device 
or resource busy


I changed the %base-file-systems in the very-bare-bones system with
%container-file-systems, and then things started working.

I tried without privileged mode, and got a error related to the firmware
service. This isn't included when you build call
operating-system-derivation with the #:container? #t argument, and sure
enough I was able to get the system up without the Docker --privileged
flag. I think Ludo mentioned this in his reply.

Unfortunately, while I could get a shell using "docker exec ...", I had
to start the guix-daemon manually as the shepherd service didn't seem to
work, at least initially. Also, when I had started it, I tried
installing a package, and there was some promising output to start off
with, but then it failed with:

  guix package: error: build failed: cloning builder process: Operation
  not permitted

Anyway, this is all pretty great! Awesome work getting this far. I'm
very excited to see what services will run this way, as Docker could
provide, albeit with some overhead, a layer of interoperability between
software that can handle Docker containers, and Guix.

Thanks again,

Chris


signature.asc
Description: PGP signature

Re: Idea: Install script to better support improving contributor-friendliness of projects

2017-11-27 Thread Adonay Felipe Nogueira 
+1

2017-11-28T05:06:28+0800 Alex Vong wrote:
> Hello,
>
> Here is a further explaination of why 'curl | sh' is a bad idea:
>
> https://stackoverflow.com/questions/29382739/why-using-curl-sudo-sh-is-not-advised
>
> Cheers,
> Alex

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Idea: Install script to better support improving contributor-friendliness of projects

2017-11-27 Thread Alex Vong 
Hello,

Here is a further explaination of why 'curl | sh' is a bad idea:

https://stackoverflow.com/questions/29382739/why-using-curl-sudo-sh-is-not-advised

Cheers,
Alex

Никита Чураев  writes:

> Here's how I want to use Guix and it is to increase
> contributor-friendliness of a project, so that the user can simply run
> a distribution-independent command to install all dependencies without
> having to hunt for them with `apt` and `dnf` manually.
>
> Unfortunately, Guix itself is not very easy to install, and the
> instructions are full of rather technical stuff like 'systemd' and
> 'upstart'.
>
> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
>
> There should be a script like the one Haskell Stack uses:
>
> |curl -sSL https://get.haskellstack.org/ | sh|
>
> IMO supporting this as a use case could really bring popularity to GNU Guix.
>
> 
>
> ||


signature.asc
Description: PGP signature

Re: boot the Hurd with Guix

2017-11-27 Thread Manolis Ragkousis 
Hello Rene :D

On 11/27/17 21:05, ren...@openmailbox.org wrote:
> Hello,
> 
> This is the demo generated with Guix:
> 
> https://github.com/methalo/boot-hurd
> 
> The binary files were generated in Debian/Hurd and placed in an 'img' file.
> 
> The command used to generate the binaries is:
> 
> './pre-inst-env guix system init ~/light.scm /guix'
> 
> To test Hurd, execute:
> 
> 'sudo qemu-system-i386 -enable-kvm -m 1G -hda guixsdhurd.img -curses'
> 
> I hope to upload the patches soon to github, for now I need to understand 
> Guix/Guile to create the patches properly.
> 
> Comments and help is welcome.
> 

The repo has only a Readme file. I think you forgot to add the rest of
the files :P

Keep up the awesome work!!

Manolis

Re: boot the Hurd with Guix

2017-11-27 Thread rennes 
Hello,

This is the demo generated with Guix:

https://github.com/methalo/boot-hurd

The binary files were generated in Debian/Hurd and placed in an 'img' file.

The command used to generate the binaries is:

'./pre-inst-env guix system init ~/light.scm /guix'

To test Hurd, execute:

'sudo qemu-system-i386 -enable-kvm -m 1G -hda guixsdhurd.img -curses'

I hope to upload the patches soon to github, for now I need to understand 
Guix/Guile to create the patches properly.

Comments and help is welcome.

Re: 01/02: gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].

2017-11-27 Thread Leo Famulari 
On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote:
> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421
> Author: Marius Bakke 
> Date:   Thu Nov 2 22:11:25 2017 +0100
> 
> gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, 
> CVE-2017-2736].
> 
> * gnu/packages/tls.scm (openssl)[replacement]: New field.
> (openssl-1.0.2m): New public variable.

[...]

> +;; Fixes CVE-2017-3735 and CVE-2017-3736.
> +;; See .
> +(define-public openssl-1.0.2m

In the early days of recursive grafts, Mark replaced libgcrypt with a
public variable, and it was resolved non-deterministically. We ended up
having to make the replacement private:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=69aa6e0995b55a38d5ce174602a107645be726d5

I remember doing something like this and getting different results
randomly:

$ while true; do guix build --source openssl@1.0.2 ;done
guix build: warning: ambiguous package specification `openssl@1.0.2'
guix build: warning: choosing openssl@1.0.2m from gnu/packages/tls.scm:402:2
/gnu/store/3hsffv38zzn3pafzr3g4x6mwqmxcmnr5-openssl-1.0.2m.tar.xz
[...]

But now it seems to consistently pick the correct package.

Did the implementation change to ensure that it does the right thing?


signature.asc
Description: PGP signature

RE: [bootstrappable] Re: prototyping the full source bootstrap path

2017-11-27 Thread Orians, Jeremiah (DTMB) 
> Jan is correct that Guile is still heavily tied to its C code.  It's true 
> that Guile's compiler is written in Scheme and that
>  the C evaluator is used only during bootstrapping, but the C bootstrap 
> evaluator is only a small piece of libguile. 
> The majority of libguile is still needed. Notably, the entire runtime, the 
> VM, and implementations of many data
> structures and other libraries are written in C.

Thank you for correcting my mistaken assumption.