Re: 01/01: gnu: itstool: Update to 2.0.4.

[Marius Bakke]

Kei Kebreau  writes:

> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit 13fbd174b5ffe5c2cc59e637f7859d357ab33d97
> Author: Kei Kebreau 
> Date:   Thu Nov 2 15:33:08 2017 -0400
>
> gnu: itstool: Update to 2.0.4.
> 
> * gnu/packages/glib.scm (itstool): Update to 2.0.4.
> [inputs]: Replace python and python-libxml2 with python-2 and 
> python2-libxml2.

This update broke "gtk-doc", so I reverted it.  Can you look into it?

`itstool` is actually segfaulting:

/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
4:  2798 Segmentation fault  itstool -m "${mo}" ${d}/C/index.docbook 
${d}/C/fdl-appendix.xml
make[2]: *** [Makefile:523: de/de.stamp] Error 139
make[2]: *** Waiting for unfinished jobs
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
4:  2808 Segmentation fault  itstool -m "${mo}" ${d}/C/index.docbook 
${d}/C/fdl-appendix.xml
make[2]: *** [Makefile:523: fr/fr.stamp] Error 139


signature.asc
Description: PGP signature

Re: Let's build 'core-updates'!

[Efraim Flashner]

On Thu, Nov 02, 2017 at 09:33:02PM +0100, Marius Bakke wrote:
> Hello!
> 
> 'core-updates' is a month overdue, so now is a good time to start it.
> 
> We are still missing the "binutils" update.  Efraim, do you remember
> what the issue with 2.29 was?

binutils-boot0 built fine, I don't remember what the next -boot0 package
was, but it failed completely so I reverted it. I was also worried about
all the CVEs showing up, and the couple that I checked didn't affect
2.28.1.

> 
> Is there anything else we should consider this round?  Maybe the
> automatic wrapping from ?

We should update cmake. It would also be nice if we could get rid of
some of libjpeg-8 and other similar older versions, but that's something
that can wait for the next round if need be. We've already added the
python update branch in, so we should make sure to update the packages
like pytest to only have the later version. If we have any more packages
without modify-phases that can be taken care of also.

I'm currently building out to gtk+ and gtk+@2 on aarch64 to see how
everything goes.


-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Let's build 'core-updates'!

[Marius Bakke]

Hello!

'core-updates' is a month overdue, so now is a good time to start it.

We are still missing the "binutils" update.  Efraim, do you remember
what the issue with 2.29 was?

Is there anything else we should consider this round?  Maybe the
automatic wrapping from ?


signature.asc
Description: PGP signature

More native-search-paths for gtk and

[Hartmut Goebel]

Hi,

while checking the Nix patches for qtbase, I discovered that they have a
patch to extend XDG_DATA_DIRS and GIO_EXTRA_MODULES.

They basically do this:

  XDG_DATA_DIRS=$XDG_DATA_DIRS:{gtk3}/share/gsettings-schemas/${gtk3.name}

  GIO_EXTRA_MODULES=$GIO_EXTRA_MODULES:${dconf.lib}/lib/gio/modules

What do you think about adding native-search-path entries for these
directories?

[1]
https://github.com/NixOS/nixpkgs/blob/17.09/pkgs/development/libraries/qt-5/5.9/qtbase/qgtk-env.patch

-- 
Regards
Hartmut Goebel

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



0xBF773B65.asc
Description: application/pgp-keys

Creating Docker containers in Scheme

[Roel Janssen]

Dear Guix,

I'd like to create a Docker container from Scheme.  Looking at
guix/scripts/pack.scm, I believe something like this should be possible:

  (docker-image "my-container"
(profile-derivation
  (packages->manifest (list hello coreutils

Is this something we could add to the the public interface of a module?

Kind regards,
Roel Janssen

Re: why is linux-libre-headers behind linux-libre?

[Dave Love]

Efraim Flashner  writes:

> On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
>> Hello,
>> 
>> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love  wrote:
>> > Why is linux-libre-headers a long way behind linux-libre (currently at
>> > version 4.4.47, compared with 4.13.10 for linux-libre)?
>> 
>> I suspect this is due to massive rebuilding that would occur when
>> updating linux-libre-headers
>> 
>
> This is typically updated in the core-updates branch, but it hasn't been
> updated yet. Based on the LTS versions, we should upgrade it to the 4.9
> branch.

Thanks for the explanations.  I checked that 4.9 would support the
Omnipath library, at least.

Fwd: diverse double compilation: using $ORIGIN?

[Ricardo Wurmus]

[resending to guix-devel@gnu.org because of mail problems / delays]

Hi Guix,
hi bootstrappers!

When building packages, Guix embeds the absolute file name of the output
directory in the resulting binary.  That’s usually fine and what we
want.

Now let’s assume that we’d like to build the GCC sources with diverse
double compilation: we’d have a “gcc” package that’s built with
“gcc-core”; we’d also have a “gcc-from-clang” package that uses Clang as
its input.  Since the GCC build procedure is performed at least two
times (once with the bootstrap compiler, and then again with the GCC
variant this produces), the resulting GCC binaries should be identical.

Except that they are not.  One of the reasons is that the binaries that
Guix produces embed the target output directories.  This means that the
two compiler binaries that result from diverse double compilation will
*always* differ in at least the embedded paths, such as paths to itself
(e.g. to binaries in the libexec directory) and paths to.

I wonder if we can use $ORIGIN in the compiler binaries, so that we can
avoid (most) references to the output directories, thereby making the
equality check between the diversely built compiler binaries simpler.

Is this at all possible?  Or do we need to accept that the equality
check for diverse double compilation for binaries built with Guix must
be aware of /gnu/store references and ignore those?

Alternatively, could we move all of these store references into a
wrapper script that would tell the binary about them via environment
variables?  The equality check would only need to exclude the wrapper
script then and compare the two sets of compiler binaries naively.

Does this make any sense?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: [bootstrappable] diverse double compilation: using $ORIGIN?

[Jan Nieuwenhuizen]

Ricardo Wurmus writes:

> When building packages, Guix embeds the absolute file name of the output
> directory in the resulting binary.  That’s usually fine and what we
> want.
>
> Now let’s assume that we’d like to build the GCC sources with diverse
> double compilation: we’d have a “gcc” package that’s built with
> “gcc-core”; we’d also have a “gcc-from-clang” package that uses Clang as
> its input.  Since the GCC build procedure is performed at least two
> times (once with the bootstrap compiler, and then again with the GCC
> variant this produces), the resulting GCC binaries should be identical.
>
> Except that they are not.  One of the reasons is that the binaries that
> Guix produces embed the target output directories.  This means that the
> two compiler binaries that result from diverse double compilation will
> *always* differ in at least the embedded paths, such as paths to itself
> (e.g. to binaries in the libexec directory) and paths to.
>
> I wonder if we can use $ORIGIN in the compiler binaries, so that we can
> avoid (most) references to the output directories, thereby making the
> equality check between the diversely built compiler binaries simpler.
>
> Is this at all possible?  Or do we need to accept that the equality
> check for diverse double compilation for binaries built with Guix must
> be aware of /gnu/store references and ignore those?
>
> Alternatively, could we move all of these store references into a
> wrapper script that would tell the binary about them via environment
> variables?  The equality check would only need to exclude the wrapper
> script then and compare the two sets of compiler binaries naively.
>
> Does this make any sense?

Attached is a patch prototyping this diverse double compilation test.

janneke

>From c91609e847066c384826d726033146e08d8185ed Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Thu, 2 Nov 2017 06:52:46 +0100
Subject: [PATCH] gnu: Add clang-gcc, gcc-ddc.  WIP

Usage: guix build gcc-dcc

Building gcc-dcc tests the diverse double compilation property
of the gcc that Guix is using.

gcc-dcc is a meta-package that depends on gcc-5.4.0 and on
clang-gcc-5.4.0 (the same GCC built with clang).  The builder
checks if both gcc's are bit-for-bit identical and fails if
they differ.

* gnu/packages/bootstrappable.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
---
 gnu/local.mk|  1 +
 gnu/packages/bootstrappable.scm | 98 +
 2 files changed, 99 insertions(+)
 create mode 100644 gnu/packages/bootstrappable.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index 90dc7aec1..379b2c7b9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -78,6 +78,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/boost.scm			\
   %D%/packages/bootloaders.scm			\
   %D%/packages/bootstrap.scm			\
+  %D%/packages/bootstrappable.scm		\
   %D%/packages/build-tools.scm			\
   %D%/packages/busybox.scm			\
   %D%/packages/c.scm\
diff --git a/gnu/packages/bootstrappable.scm b/gnu/packages/bootstrappable.scm
new file mode 100644
index 0..4ccde7a6d
--- /dev/null
+++ b/gnu/packages/bootstrappable.scm
@@ -0,0 +1,98 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 Jan Nieuwenhuizen 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages bootstrappable)
+  #:use-module ((guix licenses)
+#:select (gpl3+))
+  #:use-module (gnu packages)
+  #:use-module (gnu packages base) ; diffutils
+  #:use-module (gnu packages gcc)
+  #:use-module (gnu packages llvm)
+  #:use-module (gnu packages package-management) ; diffosscope
+  #:use-module (guix packages)
+
+  #:use-module (guix build-system trivial)
+
+  ;; for clang-gcc
+  #:use-module (guix build-system gnu)
+  #:use-module (guix utils)
+  #:use-module (gnu packages bootstrap)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages elf)
+  #:use-module (gnu packages multiprecision)
+  #:use-module (gnu packages texinfo)
+
+  #:use-module (srfi srfi-1))
+
+(define gcc-configure-flags-for-triplet (@@ (gnu packages gcc) gcc-configure-flags-for-triplet))
+
+(define-public clang-gcc
+  (package
+(inherit gcc-5)
+;;(name "clang-gcc")
+(name "cgc"); let's see if length matters