unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* core-updates schedule
@ 2018-08-01 18:41 Ricardo Wurmus
  2018-08-02  9:08 ` Efraim Flashner
  2018-08-05 14:47 ` Ricardo Wurmus
  0 siblings, 2 replies; 8+ messages in thread
From: Ricardo Wurmus @ 2018-08-01 18:41 UTC (permalink / raw)
  To: guix-devel

Hello Guix!

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.

--
Ricardo

PS: I would like to push the patch in #29951 to core-updates so that we
can opt to wrap scripts with “wrap-script” going forward.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-01 18:41 core-updates schedule Ricardo Wurmus
@ 2018-08-02  9:08 ` Efraim Flashner
  2018-08-04  3:22   ` Mark H Weaver
  2018-08-05 14:47 ` Ricardo Wurmus
  1 sibling, 1 reply; 8+ messages in thread
From: Efraim Flashner @ 2018-08-02  9:08 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Wed, Aug 01, 2018 at 08:41:00PM +0200, Ricardo Wurmus wrote:
> Hello Guix!
> 
> 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.
> 
> --
> Ricardo
> 
> PS: I would like to push the patch in #29951 to core-updates so that we
> can opt to wrap scripts with “wrap-script” going forward.
> 

Does core-updates currently address bug 31974, aka 'phases should return
#t or actually fail'?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-02  9:08 ` Efraim Flashner
@ 2018-08-04  3:22   ` Mark H Weaver
  0 siblings, 0 replies; 8+ messages in thread
From: Mark H Weaver @ 2018-08-04  3:22 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:
> Does core-updates currently address bug 31974, aka 'phases should return
> #t or actually fail'?

Thanks for the reminder.  I just pushed a fix for this to core-updates,
commit 82230603ce06de7aa3e4aef2fa093a6dbf0ef8df.

      Mark

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-01 18:41 core-updates schedule Ricardo Wurmus
  2018-08-02  9:08 ` Efraim Flashner
@ 2018-08-05 14:47 ` Ricardo Wurmus
  2018-08-20  9:03   ` Ludovic Courtès
  1 sibling, 1 reply; 8+ messages in thread
From: Ricardo Wurmus @ 2018-08-05 14:47 UTC (permalink / raw)
  To: guix-devel


Ricardo Wurmus <rekado@elephly.net> writes:

> Hello Guix!
>
> 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 hope this won’t delay our plans for core-updates too much.

--
Ricardo

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-05 14:47 ` Ricardo Wurmus
@ 2018-08-20  9:03   ` Ludovic Courtès
  2018-08-20  9:59     ` Ricardo Wurmus
  0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2018-08-20  9:03 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

Hi there!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ricardo Wurmus <rekado@elephly.net> 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’.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-20  9:03   ` Ludovic Courtès
@ 2018-08-20  9:59     ` Ricardo Wurmus
  2018-08-20 12:41       ` Marius Bakke
  0 siblings, 1 reply; 8+ messages in thread
From: Ricardo Wurmus @ 2018-08-20  9:59 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel


Ludovic Courtès <ludo@gnu.org> writes:

> Hi there!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ricardo Wurmus <rekado@elephly.net> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-20  9:59     ` Ricardo Wurmus
@ 2018-08-20 12:41       ` Marius Bakke
  2018-08-20 16:07         ` Ludovic Courtès
  0 siblings, 1 reply; 8+ messages in thread
From: Marius Bakke @ 2018-08-20 12:41 UTC (permalink / raw)
  To: Ricardo Wurmus, Ludovic Courtès; +Cc: guix-devel


[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: glibc-2.28.patch --]
[-- Type: text/x-patch, Size: 15135 bytes --]

From 3f4dcbe7d6331b8bf157464b4d045d2a91ac03cd Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
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 <mbakke@fastmail.com>
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-libio.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 4013803b0..2819d6c95 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -967,6 +967,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/mupen64plus-video-z64-glew-correct-path.patch    \
   %D%/packages/patches/mutt-store-references.patch		\
   %D%/packages/patches/myrepos-CVE-2018-7032.patch		\
+  %D%/packages/patches/m4-gnulib-libio.patch			\
   %D%/packages/patches/net-tools-bitrot.patch			\
   %D%/packages/patches/netcdf-date-time.patch			\
   %D%/packages/patches/netcdf-tst_h_par.patch			\
diff --git a/gnu/packages/m4.scm b/gnu/packages/m4.scm
index b223ce91d..090f5578e 100644
--- a/gnu/packages/m4.scm
+++ b/gnu/packages/m4.scm
@@ -32,6 +32,7 @@
             (method url-fetch)
             (uri (string-append "mirror://gnu/m4/m4-"
                                 version ".tar.xz"))
+            (patches (search-patches "m4-gnulib-libio.patch"))
             (sha256
              (base32
               "01sfjd5a4waqw83bibvmn522g69qfqvwig9i2qlgy154l1nfihgj"))))
diff --git a/gnu/packages/patches/m4-gnulib-libio.patch b/gnu/packages/patches/m4-gnulib-libio.patch
new file mode 100644
index 000000000..a26622ccf
--- /dev/null
+++ b/gnu/packages/patches/m4-gnulib-libio.patch
@@ -0,0 +1,128 @@
+Adjust the bundled gnulib to cope with removal of libio interface in
+glibc 2.28.
+
+Based on this upstream patch, without hunks that do not apply to m4:
+https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a71827c0bc5e0ec67af23edef4f15cee8e
+
+diff --git a/lib/fflush.c b/lib/fflush.c
+index 983ade0..a6edfa1 100644
+--- a/lib/fflush.c
++++ b/lib/fflush.c
+@@ -33,7 +33,7 @@
+ #undef fflush
+ 
+ 
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+ 
+ /* Clear the stream's ungetc buffer, preserving the value of ftello (fp).  */
+ static void
+@@ -72,7 +72,7 @@ clear_ungetc_buffer (FILE *fp)
+ 
+ #endif
+ 
+-#if ! (defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */)
++#if ! (defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */)
+ 
+ # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) && defined __SNPT
+ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
+@@ -148,7 +148,7 @@ rpl_fflush (FILE *stream)
+   if (stream == NULL || ! freading (stream))
+     return fflush (stream);
+ 
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+ 
+   clear_ungetc_buffer_preserving_position (stream);
+ 
+diff --git a/lib/fpending.c b/lib/fpending.c
+index c84e3a5..789f50e 100644
+--- a/lib/fpending.c
++++ b/lib/fpending.c
+@@ -32,7 +32,7 @@ __fpending (FILE *fp)
+   /* Most systems provide FILE as a struct and the necessary bitmask in
+      <stdio.h>, because they need it for implementing getc() and putc() as
+      fast macros.  */
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   return fp->_IO_write_ptr - fp->_IO_write_base;
+ #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
+   /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
+diff --git a/lib/fpurge.c b/lib/fpurge.c
+index b1d417c..3aedcc3 100644
+--- a/lib/fpurge.c
++++ b/lib/fpurge.c
+@@ -62,7 +62,7 @@ fpurge (FILE *fp)
+   /* Most systems provide FILE as a struct and the necessary bitmask in
+      <stdio.h>, because they need it for implementing getc() and putc() as
+      fast macros.  */
+-# if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++# if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   fp->_IO_read_end = fp->_IO_read_ptr;
+   fp->_IO_write_ptr = fp->_IO_write_base;
+   /* Avoid memory leak when there is an active ungetc buffer.  */
+diff --git a/lib/freadahead.c b/lib/freadahead.c
+index c2ecb5b..23ec76e 100644
+--- a/lib/freadahead.c
++++ b/lib/freadahead.c
+@@ -30,7 +30,7 @@ extern size_t __sreadahead (FILE *);
+ size_t
+ freadahead (FILE *fp)
+ {
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   if (fp->_IO_write_ptr > fp->_IO_write_base)
+     return 0;
+   return (fp->_IO_read_end - fp->_IO_read_ptr)
+diff --git a/lib/freading.c b/lib/freading.c
+index 73c28ac..c24d0c8 100644
+--- a/lib/freading.c
++++ b/lib/freading.c
+@@ -31,7 +31,7 @@ freading (FILE *fp)
+   /* Most systems provide FILE as a struct and the necessary bitmask in
+      <stdio.h>, because they need it for implementing getc() and putc() as
+      fast macros.  */
+-# if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++# if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   return ((fp->_flags & _IO_NO_WRITES) != 0
+           || ((fp->_flags & (_IO_NO_READS | _IO_CURRENTLY_PUTTING)) == 0
+               && fp->_IO_read_base != NULL));
+diff --git a/lib/fseeko.c b/lib/fseeko.c
+index 0101ab5..193f4e8 100644
+--- a/lib/fseeko.c
++++ b/lib/fseeko.c
+@@ -47,7 +47,7 @@ fseeko (FILE *fp, off_t offset, int whence)
+ #endif
+ 
+   /* These tests are based on fpurge.c.  */
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   if (fp->_IO_read_end == fp->_IO_read_ptr
+       && fp->_IO_write_ptr == fp->_IO_write_base
+       && fp->_IO_save_base == NULL)
+@@ -123,7 +123,7 @@ fseeko (FILE *fp, off_t offset, int whence)
+           return -1;
+         }
+ 
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+       fp->_flags &= ~_IO_EOF_SEEN;
+       fp->_offset = pos;
+ #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
+diff --git a/lib/stdio-impl.h b/lib/stdio-impl.h
+index 78d896e..05c5752 100644
+--- a/lib/stdio-impl.h
++++ b/lib/stdio-impl.h
+@@ -18,6 +18,12 @@
+    the same implementation of stdio extension API, except that some fields
+    have different naming conventions, or their access requires some casts.  */
+ 
++/* Glibc 2.28 made _IO_IN_BACKUP private.  For now, work around this
++   problem by defining it ourselves.  FIXME: Do not rely on glibc
++   internals.  */
++#if !defined _IO_IN_BACKUP && defined _IO_EOF_SEEN
++# define _IO_IN_BACKUP 0x100
++#endif
+ 
+ /* BSD stdio derived implementations.  */
+ 
-- 
2.18.0


From 80d193c4454261aec57b9f4822ffc45623a17fbf Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Thu, 2 Aug 2018 13:54:44 +0200
Subject: [PATCH 3/4] gnu: gzip: Fix FTBFS with glibc >= 2.28.

* gnu/packages/compression.scm (gzip)[arguments]: Add phase
'patch-for-glibc-2.28'.
---
 gnu/packages/compression.scm | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 8104b9d55..de2a8fb7c 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -216,6 +216,21 @@ adding and extracting files to/from a tar archive.")
     '(#:tests? #f
       #:phases
       (modify-phases %standard-phases
+        (add-after 'unpack 'patch-for-glibc-2.28
+          (lambda _
+            ;; Adjust the bundled gnulib to work with glibc 2.28.  See e.g.
+            ;; "m4-gnulib-libio.patch".  This is a phase rather than patch
+            ;; or snippet to work around <https://bugs.gnu.org/32347>.
+            (substitute* (find-files "lib" "\\.c$")
+              (("#if defined _IO_ftrylockfile")
+               "#if defined _IO_EOF_SEEN"))
+            (substitute* "lib/stdio-impl.h"
+              (("^/\\* BSD stdio derived implementations")
+               (string-append "#if !defined _IO_IN_BACKUP && defined _IO_EOF_SEEN\n"
+                              "# define _IO_IN_BACKUP 0x100\n"
+                              "#endif\n\n"
+                              "/* BSD stdio derived implementations")))
+            #t))
         (add-after 'unpack 'use-absolute-name-of-gzip
           (lambda* (#:key outputs #:allow-other-keys)
             (substitute* "gunzip.in"
-- 
2.18.0


From 445717532dc4ff60c56fb9cef80c5aa28af22d15 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Fri, 10 Aug 2018 16:01:32 +0200
Subject: [PATCH 4/4] gnu: coreutils: Fix build failure with glibc >= 2.28.

* gnu/packages/base.scm (coreutils): Ad phase to work around glibc 2.28 gnulib.
---
 gnu/packages/base.scm | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index ccbbdbf8d..7955b0fd7 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -355,6 +355,22 @@ used to apply commands with arbitrarily long arguments.")
    (arguments
     `(#:parallel-build? #f            ; help2man may be called too early
       #:phases (modify-phases %standard-phases
+                 (add-after 'unpack 'patch-for-glibc-2.28
+                   (lambda _
+                     ;; Adjust the bundled gnulib to work with glibc 2.28.  See e.g.
+                     ;; "m4-gnulib-libio.patch".  This is a phase rather than patch
+                     ;; or snippet to work around <https://bugs.gnu.org/32347>.
+                     (substitute* (find-files "lib" "\\.c$")
+                       (("#if defined _IO_ftrylockfile")
+                        "#if defined _IO_EOF_SEEN"))
+                     (substitute* "lib/stdio-impl.h"
+                       (("^/\\* BSD stdio derived implementations")
+                        (string-append
+                         "#if !defined _IO_IN_BACKUP && defined _IO_EOF_SEEN\n"
+                         "# define _IO_IN_BACKUP 0x100\n"
+                         "#endif\n\n"
+                         "/* BSD stdio derived implementations")))
+                     #t))
                  (add-before 'build 'patch-shell-references
                    (lambda _
                      ;; 'split' uses either $SHELL or /bin/sh.  Set $SHELL so
-- 
2.18.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: core-updates schedule
  2018-08-20 12:41       ` Marius Bakke
@ 2018-08-20 16:07         ` Ludovic Courtès
  0 siblings, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2018-08-20 16:07 UTC (permalink / raw)
  To: Marius Bakke; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Ludovic Courtès <ludo@gnu.org> 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’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: the patch --]
[-- Type: text/x-patch, Size: 2271 bytes --]

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 <sys/procfs.h>
 #endif
 #include <sys/user.h>
-#include <sys/ustat.h>
 #include <linux/cyclades.h>
 #include <linux/if_eql.h>
 #include <linux/if_plip.h>
@@ -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;
 

^ permalink raw reply related	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-08-20 16:13 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-01 18:41 core-updates schedule Ricardo Wurmus
2018-08-02  9:08 ` Efraim Flashner
2018-08-04  3:22   ` Mark H Weaver
2018-08-05 14:47 ` Ricardo Wurmus
2018-08-20  9:03   ` Ludovic Courtès
2018-08-20  9:59     ` Ricardo Wurmus
2018-08-20 12:41       ` Marius Bakke
2018-08-20 16:07         ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).