Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Amirouche Boubekki  writes:

>> I’ve pushed to guix/maintenance.git a list of things that IMO we should
>> do or might want to do for 1.0, with the understanding that 1.0 should
>> happen in 2018 (or early 2019 at the latest!).  :-)
>>
>>   https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>>
>
> I see no mention of containers. What is the status and goal about that
> subject?

What feature regarding containers would you like to know more about?

“guix environment”, for example, supports isolation through container
features.

--
Ricardo

Re: core-updates schedule

[Ludovic Courtès]

Hi there!

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:

[...]

>> This is a reminder about the “core-updates” branch.  Our plan was to
>> freeze the branch on <2018-08-06 Mon> and aim to merge the branch into
>> “master” on <2018-08-20 Mon>, dependent on how long it takes to fix all
>> problems and build most packages.
>>
>> Freezing the branch means that only commits to fix build failures may be
>> pushed.
>>
>> We will need volunteers to watch build failures on the Hydra web
>> interface.
>
> I’m still working on the GNOME updates.  I branched them off
> core-updates some weeks ago and today I finally succeeded in building
> the “gnome” package.  Many of the changes, I assume, will cause a large
> number of packages to be rebuilt, so I’d like to merge the changes into
> core-updates.

I’m late to the party, but what’s the status?  It seems we a bit behind
schedule, but it looks like a good time to resume work on this.

Today I’ll try switching to glibc 2.28, and if it works well, I’d like
to make it the last big change in ‘core-updates’.

How does that sound?

Ludo’.

Re: Graft hooks

[Ludovic Courtès]

Hello Timothy,

Timothy Sample  skribis:

> The basic idea would be to add a field (or use a property) to the
> package record.  Let’s call it “graft-hook”.  It would be Scheme code
> that gets run after grafting takes place, giving us a chance to patch
> special things like checksums.  The hook would be passed the list of
> files that were been modified during grafting.  Then, in the Racket
> package for example, I could write a graft-hook that updates the SHA-1
> hash of each of the modified source files.
>
> Since grafting is done at the derivation level, the hook code would have
> to be propagated down from the package level.  I haven’t looked at all
> the details yet, because maybe this is a bad idea and I shouldn’t waste
> my time!  :)  My first impression is that it is not too tricky.
>
> Are these problems too specialized to deserve a general mechanism like
> this?  Let me know what you think!

I agree that this would be the right thing to do!  (I’d really like to
do it for GDB as discussed in .)

Package properties would be the right way to make it extensible, but
there are complications (notably we’d need to use gexps, but build
systems don’t use gexps yet.)

So as a first step, would like to try and implement the checksum update
for Racket directly in (guix build grafts)?  The implementation would
need to be clearly separate from the generic grafting code (like profile
hooks in (guix profiles)) such that we can easily add similar hooks and
move them to a separate file later.

WDYT?

Thanks,
Ludo’.

Re: The state of guix in (open)SUSE

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice  skribis:

> Jonathan Brielmaier wrote:
>> Hello Guix,
>>
>> during the last weeks we worked hard to bring guix 0.15 to
>> (open)SUSE.
>> Further then the "simple" version bump, we also improved the package
>> of
>> guix :)
>
> Wonderful! Thank you, Tomas, & anyone else involved for all your work.

Very nice indeed, thumbs up!

Ludo’.

Re: core-updates schedule

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi there!
>
> Ricardo Wurmus  skribis:
>
>> Ricardo Wurmus  writes:
>
> [...]
>
>>> This is a reminder about the “core-updates” branch.  Our plan was to
>>> freeze the branch on <2018-08-06 Mon> and aim to merge the branch into
>>> “master” on <2018-08-20 Mon>, dependent on how long it takes to fix all
>>> problems and build most packages.
>>>
>>> Freezing the branch means that only commits to fix build failures may be
>>> pushed.
>>>
>>> We will need volunteers to watch build failures on the Hydra web
>>> interface.
>>
>> I’m still working on the GNOME updates.  I branched them off
>> core-updates some weeks ago and today I finally succeeded in building
>> the “gnome” package.  Many of the changes, I assume, will cause a large
>> number of packages to be rebuilt, so I’d like to merge the changes into
>> core-updates.
>
> I’m late to the party, but what’s the status?  It seems we a bit behind
> schedule, but it looks like a good time to resume work on this.

The GNOME updates are ready (in a separate branch), but I haven’t been
able to actually test them as I could not rebuild all of core-updates on
my laptop to install a GNOME system.  We left out most of the changes
that were needed for GNOME, though some of them were also made on
staging and some have been cherry picked into core-updates.

Some of the delays are due to the work on staging, which had to be
merged into core-updates first.  (This has already been done.)

> Today I’ll try switching to glibc 2.28, and if it works well, I’d like
> to make it the last big change in ‘core-updates’.

Marius was working glibc 2.28 and that was the last big change I wanted
to allow into core-updates.  I don’t know how close Marius was in
getting this done.

--
Ricardo

Re: Closing issues from commits

[Ludovic Courtès]

Hello Marius,

Marius Bakke  skribis:

> Marius Bakke  writes:
>
>> Hello,
>>
>> It would be convenient (for me, at least) to have a server-side git hook
>> that can close debbugs issues.  It would grep the commit message for
>> '^Fixes: ' and automatically send an
>> email to cont...@debbugs.gnu.org with the message 'close $1 $commit_id'.
>>
>> Is this something that we want and can deploy?
>
> Derp.  I realized I can do this with a post-push hook.
>
> I'll make it next time I need it and submit it here :-)

Would be nice!

A server-side hook would also be welcome in any case.  It turns out that
Mailutils in Git has bindings for Guile 2.2, which we can use to send
email, so writing such a hook wouldn’t be too hard.  :-)

We could have a tiny program that regularly pulls from Git, browses the
latest commits, and sends email as appropriate.  Would be a fun hack.
(A script like this would be easier than having a server-side hook on
Savannah, especially if we need to store credentials for the SMTP
server.)

Thanks,
Ludo’.

Re: Help needed: Updating GHC to 8.4.3

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> GHC 8.0 had been patched with
> "ghc-dont-pass-linker-flags-via-response-files.patch" to avoid using
> response files with the linker, because our ld-wrapper doesn’t seem to
> behave right in some edge case that GHC depends on.  I tried porting the
> patch to GHC 8.4.3 by applying this snippet:

I think this patch predates the addition of support for response files
in ld-wrapper.  That support is not entirely faithful (see the FIXME in
ld-wrapper.in), but I think it’s good enough for GHC.

Could you maybe try removing the patch and see if it works better?

HTH,
Ludo’.

Re: System configuration on non-native Guix (SuSE/Debian)

[Ludovic Courtès]

Hello,

Pjotr Prins  skribis:

> One thing I have always wanted to do is use Guix' system configuration
> capabilities on top of Debian. But, so far, I have no idea how to go
> about that.

One thing you could try, though it’s probably not as nice as what you’d
expect ;-), is to run a GuixSD container on your system.

That is, you write a GuixSD configuration with all the services you
need, and then you run ‘sudo guix system container that.scm’.

Not perfect, but it should work without additional hacking.

Ludo’.

Re: Bootstrap Tarballs for alpha-linux Targets

[Ludovic Courtès]

Nils Gillmann  skribis:

> Is this an entire range of CPUs with no differences wrt binary compability?

Alphas were 64-bit processors that were discontinued in the early 2000s:

  https://en.wikipedia.org/wiki/DEC_Alpha

Ludo’.

Re: Help needed: Updating GHC to 8.4.3

[Ricardo Wurmus]

Hi Ludo,

> Hello,
>
> Ricardo Wurmus  skribis:
>
>> GHC 8.0 had been patched with
>> "ghc-dont-pass-linker-flags-via-response-files.patch" to avoid using
>> response files with the linker, because our ld-wrapper doesn’t seem to
>> behave right in some edge case that GHC depends on.  I tried porting the
>> patch to GHC 8.4.3 by applying this snippet:
>
> I think this patch predates the addition of support for response files
> in ld-wrapper.  That support is not entirely faithful (see the FIXME in
> ld-wrapper.in), but I think it’s good enough for GHC.
>
> Could you maybe try removing the patch and see if it works better?

I did try to build GHC 8.4.3 without any patches first, but this failed
(with the same errors and warnings when trying to set up the tests).
Only then did I try to port the patch from 8.0.x to 8.4.3.

-- 
Ricardo

Re: core-updates schedule

[Marius Bakke]

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>
>> Today I’ll try switching to glibc 2.28, and if it works well, I’d like
>> to make it the last big change in ‘core-updates’.
>
> Marius was working glibc 2.28 and that was the last big change I wanted
> to allow into core-updates.  I don’t know how close Marius was in
> getting this done.

One problem with glibc 2.28 is that many (most?) packages that bundle
gnulib needs patching.  I've attached patches below that fixes some of
the packages.  Is the "substitution" style okay, or are origin patches
preferred?

Another thing we should get in is coreutils: version 2.30 has a recent
enough gnulib, but I could not figure out the new test failure.  Any
takers?  :-)

I will push patches that adjusts bootstrap-tarballs to the new static
outputs shortly.

glibc progress attached:

From 3f4dcbe7d6331b8bf157464b4d045d2a91ac03cd Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Wed, 1 Aug 2018 16:13:45 +0200
Subject: [PATCH 1/4] gnu: glibc: Update to 2.28.

* gnu/packages/base.scm (glibc/linux): Update to 2.28.
[source](patches): Remove 'glibc-2.27-git-fixes.patch'.
(glibc-2.28): Remove variable.
(glibc-2.27): New public variable
---
 gnu/packages/base.scm | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 4065af0ab..ccbbdbf8d 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -572,13 +572,13 @@ store.")
(name "glibc")
;; Note: Always use a dot after the minor version since various places rely
;; on "version-major+minor" to determine where locales are found.
-   (version "2.27")
+   (version "2.28")
(source (origin
 (method url-fetch)
 (uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz"))
 (sha256
  (base32
-  "0wpwq7gsm7sd6ysidv0z575ckqdg13cr2njyfgrbgh4f65adwwji"))
+  "10iha5ynvdj5m62vgpgqbq4cwvc2yhyl2w9yyyjgfxmdmx8h145i"))
 (snippet
  ;; Disable 'ldconfig' and /etc/ld.so.cache.  The latter is
  ;; required on LFS distros to avoid loading the distro's libc.so
@@ -590,7 +590,6 @@ store.")
 #t))
 (modules '((guix build utils)))
 (patches (search-patches "glibc-ldd-x86_64.patch"
- "glibc-2.27-git-fixes.patch"
  "glibc-hidden-visibility-ldconfig.patch"
  "glibc-versioned-locpath.patch"
  "glibc-allow-kernel-2.6.32.patch"
@@ -873,25 +872,25 @@ GLIBC/HURD for a Hurd host"
 (define-syntax glibc
   (identifier-syntax (glibc-for-target)))
 
-;; The "next" libc.  Useful for populating locale data before reconfiguring the
-;; entire system on it.  Will be the default in the next rebuild cycle.
-(define-public glibc-2.28
+;; Below are old libc versions, which we use mostly to build locale data in
+;; the old format (which the new libc cannot cope with.)
+
+(define-public glibc-2.27
   (package
 (inherit glibc)
-(version "2.28")
+(version "2.27")
 (source (origin
   (inherit (package-source glibc))
   (uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz"))
   (sha256
(base32
-"10iha5ynvdj5m62vgpgqbq4cwvc2yhyl2w9yyyjgfxmdmx8h145i"))
-  (patches (search-patches "glibc-allow-kernel-2.6.32.patch"
-   "glibc-ldd-x86_64.patch"
+"0wpwq7gsm7sd6ysidv0z575ckqdg13cr2njyfgrbgh4f65adwwji"))
+  (patches (search-patches "glibc-ldd-x86_64.patch"
+   "glibc-2.27-git-fixes.patch"
"glibc-hidden-visibility-ldconfig.patch"
-   "glibc-versioned-locpath.patch"))
-
-;; Below are old libc versions, which we use mostly to build locale data in
-;; the old format (which the new libc cannot cope with.)
+   "glibc-versioned-locpath.patch"
+   "glibc-allow-kernel-2.6.32.patch"
+   "glibc-reinstate-prlimit64-fallback.patch"))
 
 (define-public glibc-2.26
   (package
-- 
2.18.0


From c73ec33c536df65d666de2cd7a20d6564d8f4649 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Thu, 2 Aug 2018 13:32:29 +0200
Subject: [PATCH 2/4] gnu: m4: Fix FTBFS with glibc >= 2.28.

* gnu/packages/patches/m4-gnulib-libio.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/m4.scm (m4)[source](patches): New field.
---
 gnu/local.mk   |   1 +
 gnu/packages/m4.scm|   1 +
 gnu/packages/patches/m4-gnulib-libio.patch | 128 +
 3 files changed, 130 insertions(+)
 create mode 100644 gnu/packages/patches/m4-gnulib-lib

Re: core-updates schedule

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> Ricardo Wurmus  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Today I’ll try switching to glibc 2.28, and if it works well, I’d like
>>> to make it the last big change in ‘core-updates’.
>>
>> Marius was working glibc 2.28 and that was the last big change I wanted
>> to allow into core-updates.  I don’t know how close Marius was in
>> getting this done.

Awesome.

(One of the nice things is that we can then get rid of glibc/hurd.  \o/)

> One problem with glibc 2.28 is that many (most?) packages that bundle
> gnulib needs patching.  I've attached patches below that fixes some of
> the packages.  Is the "substitution" style okay, or are origin patches
> preferred?

Either way i fine IMO.

> Another thing we should get in is coreutils: version 2.30 has a recent
> enough gnulib, but I could not figure out the new test failure.  Any
> takers?  :-)

I can take a look.

FWIW I also came up with the attached patch for GCC 5.5, which otherwise
fails to build with:

--8<---cut here---start->8---
../../../../gcc-5.5.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:141:23:
 fatal error: sys/ustat.h: No such file or directory
compilation terminated.
--8<---cut here---end--->8---

I’d be tempted to do both the upgrade and the fixes in a single commit,
so that each commit yields something that builds.

Thanks!

Ludo’.

The 'ustat' function and corresponding headers has been removed in
version 2.28 of libc.  Adjust libsanitizer accordingly.

diff --git a/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc b/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
index 5e83ce9786c..4e98cbaf89d 100644
--- a/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
+++ b/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
@@ -921,16 +921,6 @@ POST_SYSCALL(newfstat)(long res, long fd, void *statbuf) {
   }
 }
 
-#if !SANITIZER_ANDROID
-PRE_SYSCALL(ustat)(long dev, void *ubuf) {}
-
-POST_SYSCALL(ustat)(long res, long dev, void *ubuf) {
-  if (res >= 0) {
-if (ubuf) POST_WRITE(ubuf, struct_ustat_sz);
-  }
-}
-#endif  // !SANITIZER_ANDROID
-
 PRE_SYSCALL(stat64)(const void *filename, void *statbuf) {
   if (filename)
 PRE_READ(filename,
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
index 6992f2cd8ac..ec975ba9f3a 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
@@ -150,7 +150,6 @@ typedef struct user_fpregs elf_fpregset_t;
 # include 
 #endif
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -243,7 +242,6 @@ namespace __sanitizer {
 #endif // SANITIZER_LINUX || SANITIZER_FREEBSD
 
 #if SANITIZER_LINUX && !SANITIZER_ANDROID
-  unsigned struct_ustat_sz = sizeof(struct ustat);
   unsigned struct_rlimit64_sz = sizeof(struct rlimit64);
   unsigned struct_statvfs64_sz = sizeof(struct statvfs64);
 #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 304d04e3935..3c23dcdb261 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -185,7 +185,6 @@ namespace __sanitizer {
 int v[10];
   };
 
-  extern unsigned struct_ustat_sz;
   extern unsigned struct_rlimit64_sz;
   extern unsigned struct_statvfs64_sz;