Let’s merge ‘core-updates’!

Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

The ‘core-updates’ branch is in a good shape now, and I think we should
go ahead and merge in the coming days!

Please try to upgrade your system and your user profile to see if
anything’s wrong for you (I did that a few days ago and I’m happy!).

You can test, for example, with:

  guix pull --branch=core-updates -p /tmp/new
  /tmp/new/bin/guix upgrade

You can also check substitute availability:

  /tmp/new/bin/guix weather -c 10

Feedback welcome!

Ludo’.

Re: Let’s merge ‘core-updates’!

[zimoun]

Hi,

On Tue, 24 Sep 2019 at 10:18, Ludovic Courtès <ludo@gnu.org> wrote:

> You can test, for example, with:
>
>   guix pull --branch=core-updates -p /tmp/new

Maybe I have something twisted but I get this error:

--8<---------------cut here---------------start------------->8---
building package cache...
/builder for `/gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv'
failed to produce output path
`/gnu/store/4ghfs18sd1n7nyzwx21d52myg14q51n9-guix-package-cache'
build of /gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv
failed
View build log at
'/var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2'.
cannot build derivation
`/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv': 1
dependencies couldn't be built
guix pull: error: build of
`/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv' failed
--8<---------------cut here---------------end--------------->8---

I can report more if needed.


All the best,
simon

Re: Let’s merge ‘core-updates’!

[Ricardo Wurmus]

Hi zimoun,

> --8<---------------cut here---------------start------------->8---
> building package cache...
> /builder for `/gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv'
> failed to produce output path
> `/gnu/store/4ghfs18sd1n7nyzwx21d52myg14q51n9-guix-package-cache'
> build of /gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv
> failed
> View build log at
> '/var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2'.
> cannot build derivation
> `/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv': 1
> dependencies couldn't be built
> guix pull: error: build of
> `/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv' failed
> --8<---------------cut here---------------end--------------->8---
>
> I can report more if needed.

Please do.  What does the log at
/var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2
say?

--
Ricardo

Re: Let’s merge ‘core-updates’!

[zimoun]

Hi,

On Fri, 27 Sep 2019 at 22:44, Ricardo Wurmus <rekado@elephly.net> wrote:

> > --8<---------------cut here---------------start------------->8---
> > building package cache...
> > /builder for `/gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv'
> > failed to produce output path
> > `/gnu/store/4ghfs18sd1n7nyzwx21d52myg14q51n9-guix-package-cache'
> > build of /gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv
> > failed
> > View build log at
> > '/var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2'.
> > cannot build derivation
> > `/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv': 1
> > dependencies couldn't be built
> > guix pull: error: build of
> > `/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv' failed
> > --8<---------------cut here---------------end--------------->8---
> >
> > I can report more if needed.
>
> Please do.  What does the log at
> /var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2
> say?

--8<---------------cut here---------------start------------->8---
(repl-version 0 0)
Generating package cache for
'/gnu/store/shvcfdbdh52ygwq2y8in019c91kxm4ic-profile'...
(exception unbound-variable (value "module-lookup") (value "Unbound
variable: ~S") (value (ghc-pandoc)) (value #f))
--8<---------------cut here---------------end--------------->8---

I do not know what does it mean?


All the best,
simon

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Fri, 27 Sep 2019 at 22:44, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> > --8<---------------cut here---------------start------------->8---
>> > building package cache...
>> > /builder for `/gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv'
>> > failed to produce output path
>> > `/gnu/store/4ghfs18sd1n7nyzwx21d52myg14q51n9-guix-package-cache'
>> > build of /gnu/store/87m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv
>> > failed
>> > View build log at
>> > '/var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2'.
>> > cannot build derivation
>> > `/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv': 1
>> > dependencies couldn't be built
>> > guix pull: error: build of
>> > `/gnu/store/zc7z147cx36gka0mc4dbgz4mxv7wqln8-profile.drv' failed
>> > --8<---------------cut here---------------end--------------->8---
>> >
>> > I can report more if needed.
>>
>> Please do.  What does the log at
>> /var/log/guix/drvs/87/m24ly3p44x8qgpm7gzyig7ns2mhpdz-guix-package-cache.drv.bz2
>> say?
>
> (repl-version 0 0)
> Generating package cache for
> '/gnu/store/shvcfdbdh52ygwq2y8in019c91kxm4ic-profile'...
> (exception unbound-variable (value "module-lookup") (value "Unbound
> variable: ~S") (value (ghc-pandoc)) (value #f))

Could you give us the exact command to reproduce it, with a ‘--commit’
flag and without a ~/.config/guix/channels.scm file, as well as the
output of ‘guix describe’ for the ‘guix’ command you’re using?

Thanks,
Ludo’.

Re: Let’s merge ‘core-updates’!

[zimoun]

Hi,

On Wed, 2 Oct 2019 at 15:06, Ludovic Courtès <ludo@gnu.org> wrote:

> Could you give us the exact command to reproduce it, with a ‘--commit’
> flag and without a ~/.config/guix/channels.scm file, as well as the
> output of ‘guix describe’ for the ‘guix’ command you’re using?

Sorry the noise.
The culprit was the ~/.config/guix/channels.scm file and my custom
channel has seemed inconsistent.
Basically I did not report the big move of Haskell packages so
'ghc-pandoc' was not found.
 #:use-module (gnu packages haskell) ->  #:use-module (gnu packages haskell-xyz)


Sorry again.

All the best,
simon

Re: Let’s merge ‘core-updates’!

[Mikhail Kryshen]

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

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

> Hello Guix!
>
> The ‘core-updates’ branch is in a good shape now, and I think we should
> go ahead and merge in the coming days!
>
> Please try to upgrade your system and your user profile to see if
> anything’s wrong for you (I did that a few days ago and I’m happy!).

supercollider (required by emacs-org-contrib via emacs-scel) failed to build:

/tmp/guix-build-supercollider-3.10.2.drv-0/SuperCollider-Source/server/supernova/sc/sc_osc_handler.cpp: In member function ‘void nova::detail::sc_osc_handler::start_tcp_accept()’:
/tmp/guix-build-supercollider-3.10.2.drv-0/SuperCollider-Source/server/supernova/sc/sc_osc_handler.cpp:891:83: error: ‘boost::asio::ip::tcp::acceptor {aka class boost::asio::basic_socket_acceptor<boost::asio::ip::tcp>}’ has no member named ‘get_io_service’
     tcp_connection::pointer new_connection = tcp_connection::create(tcp_acceptor_.get_io_service());
                                                                                   ^~~~~~~~~~~~~~
make[2]: *** [server/supernova/CMakeFiles/libsupernova.dir/build.make:79: server/supernova/CMakeFiles/libsupernova.dir/sc/sc_osc_handler.cpp.o] Error 1
make[2]: Leaving directory '/tmp/guix-build-supercollider-3.10.2.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:2698: server/supernova/CMakeFiles/libsupernova.dir/all] Error 2

> You can test, for example, with:
>
>   guix pull --branch=core-updates -p /tmp/new
>   /tmp/new/bin/guix upgrade
>
> You can also check substitute availability:
>
>   /tmp/new/bin/guix weather -c 10
>
> Feedback welcome!
>
> Ludo’.
>

-- 
Mikhail

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

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hi Mikhail,

Mikhail Kryshen <mikhail@kryshen.net> skribis:

> supercollider (required by emacs-org-contrib via emacs-scel) failed to build:
>
> /tmp/guix-build-supercollider-3.10.2.drv-0/SuperCollider-Source/server/supernova/sc/sc_osc_handler.cpp: In member function ‘void nova::detail::sc_osc_handler::start_tcp_accept()’:
> /tmp/guix-build-supercollider-3.10.2.drv-0/SuperCollider-Source/server/supernova/sc/sc_osc_handler.cpp:891:83: error: ‘boost::asio::ip::tcp::acceptor {aka class boost::asio::basic_socket_acceptor<boost::asio::ip::tcp>}’ has no member named ‘get_io_service’
>      tcp_connection::pointer new_connection = tcp_connection::create(tcp_acceptor_.get_io_service());
>                                                                                    ^~~~~~~~~~~~~~
> make[2]: *** [server/supernova/CMakeFiles/libsupernova.dir/build.make:79: server/supernova/CMakeFiles/libsupernova.dir/sc/sc_osc_handler.cpp.o] Error 1
> make[2]: Leaving directory '/tmp/guix-build-supercollider-3.10.2.drv-0/build'
> make[1]: *** [CMakeFiles/Makefile2:2698: server/supernova/CMakeFiles/libsupernova.dir/all] Error 2

Mathieu fixed it in 772ca8e4f62d5b74286e39652b33afb817e17ca2.

Thanks,
Ludo’.

Re: Let’s merge ‘core-updates’!

[Mikhail Kryshen]

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

Thanks.

Also xfce4-pulseaudio-plugin (this breaks system configurations with
xfce-desktop-service):

  starting phase `augment-cflags'
  Backtrace:
             7 (primitive-load "/gnu/store/b01jl2cm2v4pbang81grgmhp7pi?")
  In ice-9/eval.scm:
     191:35  6 (_ #f)
  In ice-9/boot-9.scm:
      829:9  5 (catch srfi-34 #<procedure 7ffff60a4c20 at /gnu/store/?> ?)
  In srfi/srfi-1.scm:
     863:16  4 (every1 #<procedure 7ffff60a4be0 at /gnu/store/w3jlc8p?> ?)
  In /gnu/store/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import/guix/build/gnu-build-system.scm:
     839:30  3 (_ _)
  In ice-9/eval.scm:
      619:8  2 (_ #(#(#<directory (guile-user) 7ffff6c74140>) (# # ?)))
      159:9  1 (_ #(#(#<directory (guile-user) 7ffff6c74140>) (# # ?)))
  In unknown file:
             0 (string-append "/gnu/store/wz8zw92bs7a2r01n4msicwwk4sc?" ?)

  ERROR: In procedure string-append:
  In procedure string-append: Wrong type (expecting string): #f

Probably caused by use of C_INCLUDE_PATH instead of CPATH.

Would it be feasible to wait for CI to build everything in core-updates
and investigate all failures before merging?

-- 
Mikhail

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

Re: Let’s merge ‘core-updates’!

[Marius Bakke]

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

Mikhail Kryshen <mikhail@kryshen.net> writes:

> Thanks.
>
> Also xfce4-pulseaudio-plugin (this breaks system configurations with
> xfce-desktop-service):
>
>   starting phase `augment-cflags'
>   Backtrace:
>              7 (primitive-load "/gnu/store/b01jl2cm2v4pbang81grgmhp7pi?")
>   In ice-9/eval.scm:
>      191:35  6 (_ #f)
>   In ice-9/boot-9.scm:
>       829:9  5 (catch srfi-34 #<procedure 7ffff60a4c20 at /gnu/store/?> ?)
>   In srfi/srfi-1.scm:
>      863:16  4 (every1 #<procedure 7ffff60a4be0 at /gnu/store/w3jlc8p?> ?)
>   In /gnu/store/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import/guix/build/gnu-build-system.scm:
>      839:30  3 (_ _)
>   In ice-9/eval.scm:
>       619:8  2 (_ #(#(#<directory (guile-user) 7ffff6c74140>) (# # ?)))
>       159:9  1 (_ #(#(#<directory (guile-user) 7ffff6c74140>) (# # ?)))
>   In unknown file:
>              0 (string-append "/gnu/store/wz8zw92bs7a2r01n4msicwwk4sc?" ?)
>
>   ERROR: In procedure string-append:
>   In procedure string-append: Wrong type (expecting string): #f
>
> Probably caused by use of C_INCLUDE_PATH instead of CPATH.

Fixed in e17f1c3dcccca583bc0b2d358c277d6988c51d90, thanks!

> Would it be feasible to wait for CI to build everything in core-updates
> and investigate all failures before merging?

Unfortunately there is a lot of "noise" in the CI -- packages that fail
to build on *all* branches.  It is currently also difficult to compare
branches to see regressions.  Help wanted!  :-)

So for now we have to rely on user feedback, and `guix weather`.

Thanks for testing!

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

Re: Let’s merge ‘core-updates’!

[John Soo]

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

Hi there,

I pulled to commit 3128d6a16a80d40d927c41f530dd48ebbb8a036d and tlsdate
failed to build.  Many other packages and services correctly updated.

- John

[-- Attachment #1.2: Type: text/html, Size: 273 bytes --]

[-- Attachment #2: gdjpdqr9ks422a5vky3wj8hjw8diy1-tlsdate-0.0.13.drv.bz2 --]
[-- Type: application/octet-stream, Size: 8560 bytes --]

Re: Let’s merge ‘core-updates’!

[Marius Bakke]

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

John Soo <jsoo1@asu.edu> writes:

> Hi there,
>
> I pulled to commit 3128d6a16a80d40d927c41f530dd48ebbb8a036d and tlsdate
> failed to build.  Many other packages and services correctly updated.

Fixed in 4ecf790e70dd22c204edad269cb661d820864906, thanks!

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

Re: Let’s merge ‘core-updates’!

[John Soo]

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

Hi Guix,

Two more items on core-updates: I get this message on most things now:
guile: warning: failed to install locale.

Also after a reboot, the early guile repl gets stuck populating /etc.

Thanks!

- John

[-- Attachment #2: Type: text/html, Size: 369 bytes --]

Re: Let’s merge ‘core-updates’!

[Marius Bakke]

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

John Soo <jsoo1@asu.edu> writes:

> Hi Guix,
>
> Two more items on core-updates: I get this message on most things now:
> guile: warning: failed to install locale.

This means that the program you are executing was linked against a
different version of libc than the current system has locales for.

To make the glibc 2.28 locales available and get rid of this warning for
packages you haven't updated yet, add this to your configuration and
reconfigure:

 (locale-libcs (list glibc-2.28 (canonical-package glibc)))

> Also after a reboot, the early guile repl gets stuck populating /etc.

This is <https://issues.guix.gnu.org/issue/37501>.  Can you see if the
mentioned fix works for you?

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

Re: Let’s merge ‘core-updates’!

[pelzflorian (Florian Pelz)]

On Tue, Sep 24, 2019 at 10:18:30AM +0200, Ludovic Courtès wrote:
> Please try to upgrade your system and your user profile to see if
> anything’s wrong for you (I did that a few days ago and I’m happy!).
> 

I switched my local git checkout to core-updates, git pulled and then
did a `guix pull --branch=core-updates` from it.  Afterwards I made
some changes to the local git checkout and tried to pull again, but it
failed with:

~$ bzcat /var/log/guix/drvs/rn/r6phzskqxv88mrmxlvqbf7m6s5l3xq-module-import-compiled.drv.bz2
[ 1/86] Loading './gcrypt/hash.scm'...
[ 2/86] Loading './git.scm'...
[ 3/86] Loading './gnu/packages/bootstrap.scm'...
[ 4/86] Loading './gnu/packages.scm'...
[ 5/86] Loading './guix/base16.scm'...
[ 6/86] Loading './guix/base32.scm'...
[ 7/86] Loading './guix/base64.scm'...
[ 8/86] Loading './guix/build/compile.scm'...
[ 9/86] Loading './guix/build/download.scm'...
[10/86] Loading './guix/build/syscalls.scm'...
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload gnutls-version in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload gnutls-version in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload gnutls-version in (gnutls):
;;; missing interface for module (gnutls)
Backtrace:
          11 (primitive-load "/gnu/store/bd3inz9s8x7lavwjhjzp5dr8bmg?")
In ice-9/eval.scm:
    619:8 10 (_ #f)
In srfi/srfi-1.scm:
   466:18  9 (fold #<procedure 7ffff60bb980 at ice-9/eval.scm:336:1?> ?)
   466:18  8 (fold #<procedure 7ffff6fd7340 at ice-9/eval.scm:336:1?> ?)
   466:18  7 (fold #<procedure 7ffff52ec900 at ice-9/eval.scm:336:1?> ?)
In ice-9/eval.scm:
    619:8  6 (_ #(#(#<directory (guix build utils) 7ffff6ca0500>) # ?))
In ice-9/boot-9.scm:
   2312:4  5 (save-module-excursion _)
In unknown file:
           4 (primitive-load "./guix/build/syscalls.scm")
In ice-9/eval.scm:
    619:8  3 (_ #f)
In ice-9/boot-9.scm:
  2071:24  2 (call-with-deferred-observers #<procedure 7fffee998980 ?>)
   260:13  1 (for-each #<procedure 7fffee998840 at ice-9/boot-9.scm?> ?)
In unknown file:
           0 (scm-error misc-error #f "~A ~S" ("re-exporting loc?" ?) ?)

ERROR: In procedure scm-error:
re-exporting local variable: AT_SYMLINK_NOFOLLOW




This is my channel.scm

(list (channel (name 'guix)
               (url "/home/florian/git/guix")))

Regards,
Florian

Re: Let’s merge ‘core-updates’!

[pelzflorian (Florian Pelz)]

On Fri, Sep 27, 2019 at 08:50:29PM +0200, pelzflorian (Florian Pelz) wrote:
> Afterwards I made
> some changes to the local git checkout and tried to pull again, but it
> failed with:
> 

Oops, this happens only when trying to `guix pull` from master after
`guix pull --branch core-updates`.

Regards,
Florian

Re: Let’s merge ‘core-updates’!

[Ricardo Wurmus]

pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> writes:

> On Fri, Sep 27, 2019 at 08:50:29PM +0200, pelzflorian (Florian Pelz) wrote:
>> Afterwards I made
>> some changes to the local git checkout and tried to pull again, but it
>> failed with:
>> 
>
> Oops, this happens only when trying to `guix pull` from master after
> `guix pull --branch core-updates`.

This looks like https://issues.guix.gnu.org/issue/37506.

-- 
Ricardo

Re: Let’s merge ‘core-updates’!

[Ricardo Wurmus]

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

> The ‘core-updates’ branch is in a good shape now, and I think we should
> go ahead and merge in the coming days!

This is one for the books! :)  I’m so glad it’s finally happening.

> Please try to upgrade your system and your user profile to see if
> anything’s wrong for you (I did that a few days ago and I’m happy!).

My system is already on core-updates and it works fine.

Still to be pushed to core-updates is a fix for ant-bootstrap on
i686-linux (which block all Java packages on that architecture).  We’re
just waiting for independent confirmation that this fix is fine.

-- 
Ricardo

Re: Let’s merge ‘core-updates’!

[Jack Hill]

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

On Tue, 24 Sep 2019, Ludovic Courtès wrote:

> The ‘core-updates’ branch is in a good shape now, and I think we should
> go ahead and merge in the coming days!
>
> Please try to upgrade your system and your user profile to see if
> anything’s wrong for you (I did that a few days ago and I’m happy!).

I've tried this and I turned up a build problem with dconf-editor: 
https://issues.guix.gnu.org/issue/37503

Best,
Jack

Re: Let’s merge ‘core-updates’!

[Jelle Licht]

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

> Hello Guix!
>
> The ‘core-updates’ branch is in a good shape now, and I think we should
> go ahead and merge in the coming days!
>
> Please try to upgrade your system and your user profile to see if
> anything’s wrong for you (I did that a few days ago and I’m happy!).
>
> You can test, for example, with:
>
>   guix pull --branch=core-updates -p /tmp/new
>   /tmp/new/bin/guix upgrade

Building gnucash using core-updates fails:

building /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv...
\ 'configure' phasebuilder for `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed with exit code 1
build of /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv failed
View build log at '/var/log/guix/drvs/zs/x2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv.bz2'.
guix upgrade: error: build of `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed

The specific error message is: Unknown CMake command "check_symbol_exists".
Relevant part of build log:
https://paste.debian.net/1103105/

reconfiguring my system and upgrading the other packages in my profile
seems to work very well.

Re: Let’s merge ‘core-updates’!

[Kei Kebreau]

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

Jelle Licht <jlicht@fsfe.org> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> The ‘core-updates’ branch is in a good shape now, and I think we should
>> go ahead and merge in the coming days!
>>
>> Please try to upgrade your system and your user profile to see if
>> anything’s wrong for you (I did that a few days ago and I’m happy!).
>>
>> You can test, for example, with:
>>
>>   guix pull --branch=core-updates -p /tmp/new
>>   /tmp/new/bin/guix upgrade
>
> Building gnucash using core-updates fails:
>
> building /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv...
> \ 'configure' phasebuilder for
> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
> with exit code 1
> build of /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv failed
> View build log at
> '/var/log/guix/drvs/zs/x2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv.bz2'.
> guix upgrade: error: build of
> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
>
> The specific error message is: Unknown CMake command "check_symbol_exists".
> Relevant part of build log:
> https://paste.debian.net/1103105/
>
> reconfiguring my system and upgrading the other packages in my profile
> seems to work very well.

I ran into this issue as well. Gnucash verison 3.7 fixes this issue
[0]. I have a preliminary patch that may be pushed on master. My
computer is currently attempting to build it on core-updates, but it has
to build WebKitGTK first.

[0]: https://github.com/Gnucash/gnucash/commit/ce6c3c22a15102341ca41ddba2a46ea7daf63f17#diff-e816f3fb553eba8e15e25d30f14cff0d

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

Re: Let’s merge ‘core-updates’!

[Kei Kebreau]

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

Kei Kebreau <kkebreau@posteo.net> writes:

> Jelle Licht <jlicht@fsfe.org> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello Guix!
>>>
>>> The ‘core-updates’ branch is in a good shape now, and I think we should
>>> go ahead and merge in the coming days!
>>>
>>> Please try to upgrade your system and your user profile to see if
>>> anything’s wrong for you (I did that a few days ago and I’m happy!).
>>>
>>> You can test, for example, with:
>>>
>>>   guix pull --branch=core-updates -p /tmp/new
>>>   /tmp/new/bin/guix upgrade
>>
>> Building gnucash using core-updates fails:
>>
>> building /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv...
>> \ 'configure' phasebuilder for
>> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
>> with exit code 1
>> build of /gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv failed
>> View build log at
>> '/var/log/guix/drvs/zs/x2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv.bz2'.
>> guix upgrade: error: build of
>> `/gnu/store/zsx2szs631q5p6dsa03zh8x7hqgv9x9p-gnucash-3.5.drv' failed
>>
>> The specific error message is: Unknown CMake command "check_symbol_exists".
>> Relevant part of build log:
>> https://paste.debian.net/1103105/
>>
>> reconfiguring my system and upgrading the other packages in my profile
>> seems to work very well.
>
> I ran into this issue as well. Gnucash verison 3.7 fixes this issue
> [0]. I have a preliminary patch that may be pushed on master. My
> computer is currently attempting to build it on core-updates, but it has
> to build WebKitGTK first.
>
> [0]:
> https://github.com/Gnucash/gnucash/commit/ce6c3c22a15102341ca41ddba2a46ea7daf63f17#diff-e816f3fb553eba8e15e25d30f14cff0d

The patch seems to work. Please see the following issue to try it out:
<https://issues.guix.gnu.org/issue/37554>

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

Re: Let’s merge ‘core-updates’!

[John Soo]

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

Hi Marius and Guix,

> To make the glibc 2.28 locales available and get rid of this warning for
> packages you haven't updated yet, add this to your configuration and
> reconfigure:
>
> (locale-libcs (list glibc-2.28 (canonical-package glibc)))

That did the trick, thank you.

> This is <https://issues.guix.gnu.org/issue/37501>.  Can you see if the
mentioned fix works for you?

I added urandom-seed to the services for this system, but reconfigure
failed because I use the desktop-services as a base, which includes
urandom-seed as a service from base-services.
The reconfigure and reboot did not hang this time, though.

Everything else I use looks good, thanks!

John

[-- Attachment #2: Type: text/html, Size: 1223 bytes --]

Re: Let’s merge ‘core-updates’!

[Konrad Hinsen]

Hi Ludo,

> Please try to upgrade your system and your user profile to see if
> anything’s wrong for you (I did that a few days ago and I’m happy!).

It mostly works fine for me, except that the build of next-gtk-webkit 
fails (which works fine on master). The cause is:

make[2]: Entering directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
make[2]: *** No rule to make target 'JavaScriptCore-4.0.gir', needed by 
'WebKit2-4.0.gir'.  Stop.

Konrad.

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

>> Please try to upgrade your system and your user profile to see if
>> anything’s wrong for you (I did that a few days ago and I’m happy!).
>
> It mostly works fine for me, except that the build of next-gtk-webkit
> fails (which works fine on master). The cause is:
>
> make[2]: Entering directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
> make[2]: *** No rule to make target 'JavaScriptCore-4.0.gir', needed
> by 'WebKit2-4.0.gir'.  Stop.

AFAICS next builds fine on ‘core-updates’ as of
86f2124b0f015e99416e5e6efc15f0ef790eb366 (on x86_64).

Thanks,
Ludo’.

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

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

> The ‘core-updates’ branch is in a good shape now, and I think we should
> go ahead and merge in the coming days!

Friends have fixed quite a few things lately, so I’ll merge today.

Please shout now if you’re aware of a blocker!

Ludo’.

Re: Let’s merge ‘core-updates’!

[Marius Bakke]

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

Hallo Ludo,

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

> Hello Guix!
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> The ‘core-updates’ branch is in a good shape now, and I think we should
>> go ahead and merge in the coming days!
>
> Friends have fixed quite a few things lately, so I’ll merge today.
>
> Please shout now if you’re aware of a blocker!

I think <https://issues.guix.gnu.org/issue/37501> should block the
merge.  Otherwise many headless systems will occasionally fail to boot.

(attended systems too, but at least then you have a good meat-based
entropy source at hand)

John Soo reported that adding the urandom-seed-service-type did not
work.  Perhaps it starts after OpenSSH?  I haven't had time to look into
it yet.

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

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hello Marius!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> Ludovic Courtès <ludo@gnu.org> skribis:
>>
>>> The ‘core-updates’ branch is in a good shape now, and I think we should
>>> go ahead and merge in the coming days!
>>
>> Friends have fixed quite a few things lately, so I’ll merge today.
>>
>> Please shout now if you’re aware of a blocker!
>
> I think <https://issues.guix.gnu.org/issue/37501> should block the
> merge.  Otherwise many headless systems will occasionally fail to boot.
>
> (attended systems too, but at least then you have a good meat-based
> entropy source at hand)

I think we made good progress there; there are still unknowns, but at
least we have a workaround (Torvalds’ patch.)

Anything else that should be blocking the merge?

Thanks!

Ludo’.

‘core-updates’ merged!

[Ludovic Courtès]

Hello Guix!

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

>> I think <https://issues.guix.gnu.org/issue/37501> should block the
>> merge.  Otherwise many headless systems will occasionally fail to boot.
>>
>> (attended systems too, but at least then you have a good meat-based
>> entropy source at hand)
>
> I think we made good progress there; there are still unknowns, but at
> least we have a workaround (Torvalds’ patch.)
>
> Anything else that should be blocking the merge?

Apparently not, so I went ahead and merged!

Please email bug-guix@gnu.org if you notice anything wrong.

For the record, there are many novelties: glibc 2.29, the default
compiler is now GCC 7 (was 5.5), there’s the new “reduced binary seed
bootstrap”, and tons of other updates and improvements.

Thanks to everyone who’s been working on this!

Ludo’.

Merging ‘core-updates’ real soon

[nathan via Development of GNU Guix and the GNU System distribution.]

Do we have time to merge the vulkan loading fix into core-updates because there isn't a mesa-updates branch for it to go with right now? [bug#71109]

Re: Merging ‘core-updates’ real soon

[John Kehayias]

Hi,

I did see that patch but didn't have a chance to do anything with it. I just started (locally) on updating mesa to the latest version, so I was going to rebase on core-updates (or master if core-updates is merged) and get that ready to go.

So I would say it is up to whoever is leading on core-updates, based on the current substitute coverage. I would guess if it is ready to be merged, a rebuild of ~5k packages due to vulkan would set things back a while. And I can have a mesa-updates branch with that patch building everything soon after.

Apologies for the delay! I was away for a bit but getting back to it now. I better make a formal mesa/graphics team and get some others too.

John

On Thu, Aug 22, 2024 at 07:12 PM, nathan via \"Development of GNU Guix and the GNU System distribution.\" wrote:

> Do we have time to merge the vulkan loading fix into core-updates
> because there isn't a mesa-updates branch for it to go with right now?
> [bug#71109]

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hi,

John Kehayias <john.kehayias@protonmail.com> skribis:

> I did see that patch but didn't have a chance to do anything with it. I just started (locally) on updating mesa to the latest version, so I was going to rebase on core-updates (or master if core-updates is merged) and get that ready to go.
>
> So I would say it is up to whoever is leading on core-updates, based on the current substitute coverage. I would guess if it is ready to be merged, a rebuild of ~5k packages due to vulkan would set things back a while. And I can have a mesa-updates branch with that patch building everything soon after.

A dedicated branch right after ‘core-updates’ is merged sounds like the
way forward to me.

Thanks,
Ludo’.

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hello Guix!

I rebased ‘core-updates’ on ‘master’ hours ago; so far, so good, though
there are a few new build failures:

  https://ci.guix.gnu.org/eval/1586727?status=newly-failed

Nothing too bad, except for icedove:

  https://ci.guix.gnu.org/build/5510567/details

and perf:

  https://ci.guix.gnu.org/build/5509604/details

Prior to that, I applied the ffmpeg i686 fix and libcamera aarch64 fix
that others provided:

  https://ci.guix.gnu.org/eval/1586636?status=succeeded

If there are no objections, I’d like us to go ahead and rebase/merge
‘core-updates’ tomorrow, Friday 30th, after adding an entry in
‘etc/news.scm’ (I can do that but I won’t mind if somebody else does; we
can coordinate on IRC and/or here.)

Thoughts?

Ludo’.

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

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

> If there are no objections, I’d like us to go ahead and rebase/merge
> ‘core-updates’ tomorrow, Friday 30th, after adding an entry in
> ‘etc/news.scm’ (I can do that but I won’t mind if somebody else does; we
> can coordinate on IRC and/or here.)

Here’s a proposed news entry:

 (entry (commit "XXX")
        (title
         (en "Core packages updated"))
        (body
         (en "Core packages have been updated, in particular those that
are used to build every other package in the distribution.  Noteworthy
upgrades include:

@itemize
@item @code{glibc} 2.39 (was 2.35);
@item @code{gcc} 11.4.0 as the default compiler (was 11.3.0);
@item @code{binutils} 2.41 (was 2.38);
@item @code{make} 4.4.1 (was 4.3);
@item TeX@tie{}Live 2024.2 (was 20230313);
@end itemize

Additional improvements were made to the build system and related
packages and tools:

@itemize
@item
the @code{glibc} package now includes the @code{C.UTF-8} locale,
suitable for use when a UTF-8-capable is necessary regardless of any
language or regional convention;
@item
origins that include patches are now repacked with zstd instead of xz,
which uses less CPU power and memory, both when compressing and when
decompressing;
@item
@code{copy-recursively} has a new @code{#:select?} parameter.
@end itemize

If you encounter any problem, please check
@url{https://issues.guix.gnu.org} for existing reports and resolutions;
email @email{bug-guix@@gnu.org} to report new bugs.")))

Did I forget anything important here?

If not, translations welcome!

Ludo’.

Re: Merging ‘core-updates’ real soon

[Nicolas Goaziou via Development of GNU Guix and the GNU System distribution.]

Hello,

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

> @item TeX@tie{}Live 2024.2 (was 20230313);
> @end itemize

You may want to mention that the versioning scheme for TeX Live has
changed and, unless I'm mistaken, users will need to force upgrade for
these packages. Indeed, I doubt "guix pull && guix upgrade" will update
willingly, e.g., `texlive-context' from version "66594" (old scheme) to
"2024.2" (new scheme). I didn't check, tho.

Also, the news entry might mention that compiling documents with modular
TeX Live is no longer slower than expected.

Regards,
-- 
Nicolas Goaziou

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hello!

Here’s the updated news entry based on everyone’s feedback:

 (entry (commit "XXX")
        (title
         (en "Core packages updated"))
        (body
         (en "Core packages have been updated, in particular those that
are used to build every other package in the distribution.  Noteworthy
upgrades include:

@itemize
@item @code{glibc} 2.39 (was 2.35);
@item @code{gcc} 11.4.0 as the default compiler (was 11.3.0);
@item @code{binutils} 2.41 (was 2.38);
@item @code{make} 4.4.1 (was 4.3);
@item TeX@tie{}Live 2024.2 (was 20230313; note that due to the new
versioning scheme, @command{guix upgrade} will consider the new packages
as ``older'' than the previous ones so you may need to use
@command{guix install} to upgrade them).
@end itemize

Additional improvements were made to the build system and related
packages and tools:

@itemize
@item
the @code{glibc} package now includes the @code{C.UTF-8} locale,
suitable for use when a UTF-8 locale is necessary regardless of
any language or regional convention;
@item
origins that include patches are now repacked with zstd instead of xz,
which uses less CPU power and memory, both when compressing and when
decompressing;
@item
performance issues with the modular TeX@tie{}Live package set have
been fixed.
@end itemize

If you encounter any problem, please check
@url{https://issues.guix.gnu.org} for existing reports and resolutions;
email @email{bug-guix@@gnu.org} to report new bugs.")))

I can do the French translation but feel free to send other
translations.

Thanks,
Ludo’.

‘core-updates’ merged! 🎉

[Ludovic Courtès]

Hello Guix!

I rebased and applied ‘core-updates’ on top of ‘master’ minutes ago with
commit b8327cb31199fb9f4ebed6c53a59601d41def5a1! 🎉

Consider contributing translations of the news entry added in that
commit.

Let’s congratulate everyone involved in this branch for more than a year (⁈)
for the long, tedious, and hard work!

As always, please report any issue you encounter, and let’s tackle them
together!

Ludo’.

Re: ‘core-updates’ merged! 🎉

[Tomas Volf]

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

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

Hi!

> Hello Guix!
>
> I rebased and applied ‘core-updates’ on top of ‘master’ minutes ago with
> commit b8327cb31199fb9f4ebed6c53a59601d41def5a1! 🎉
>
> Consider contributing translations of the news entry added in that
> commit.
>
> Let’s congratulate everyone involved in this branch for more than a year (⁈)
> for the long, tedious, and hard work!

I just want to express my thanks to everyone involved.  It is great it
was finally merged and it took lot of work.  So, thanks everyone! :)

>
> As always, please report any issue you encounter, and let’s tackle them
> together!

I am writing this message from a system & home reconfigured after the
merge, so for me (on my fairly boring x86-64 system) everything works
well.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

Since I’m about to leave keyboard for a couple of weeks, here’s a to-do
list for those of you who’ll be around.  :-)

The last things I wanted to push for ‘core-updates’ were a reproducible
Guile (done in b5efd14a9add1bcb4a44fa5b9c1b47706f3df9da), and a subset
or all of the aarch64 patches, depending on their status (should not be
a blocker IMO).

So, here’s a plan:

  • Once Efraim has pushed some of the aarch64 patches, do another
    evaluation of the “core” package set for that branch, and check for
    anything wrong.  From there on, forbid full-rebuild changes.

  • Once the “core” subset builds correctly on all the supported
    platforms (those that Hydra supports), merge ‘master’.  Maybe update
    a couple of things like GnuTLS while we’re at it.  From there on
    forbid non-trivial changes.

  • Build all the packages.  (To do that, someone with access to Hydra
    must change the “subset” argument to “all” in the config of the
    ‘core-updates’ jobset.)

  • Fix things.

  • Once most regressions have been addressed and most binaries are
    available, merge ‘core-updates’ into ‘master’.

How does that sound?

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> So, here’s a plan:
> 
>   • Once Efraim has pushed some of the aarch64 patches, do another
>     evaluation of the “core” package set for that branch, and check for
>     anything wrong.  From there on, forbid full-rebuild changes.
> 
>   • Once the “core” subset builds correctly on all the supported
>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>     a couple of things like GnuTLS while we’re at it.  From there on
>     forbid non-trivial changes.
> 
>   • Build all the packages.  (To do that, someone with access to Hydra
>     must change the “subset” argument to “all” in the config of the
>     ‘core-updates’ jobset.)
> 
>   • Fix things.

We are at this stage... please help :)

Here is a list of packages that are failing on core-updates but not on
the master branch:

https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail

It might take a while to load the web page; please have patience :)

Once you load it, take note of the brown and red icons.

The brown icon means, "we did not try to build this yet, because one of
the dependencies failed to build".

The red icon means, "we tried to build this and it failed." You should
probably focus on these failed builds.

I'm sorry if the color-coding is not sufficient for you; we know it's
not a good system for people who have impaired vision. My vision is
pretty good and I find it hard to pick out the red icons.

Once you have found an interesting build failure, read its log (the
"raw" log is most useful, in my opinion) and try to reproduce and fix it
on your machine. Then send a patch!

Sometimes there is a spurious build failure: The SSH connection used for
offloading fails, or the build machine is out of memory. Reply to this
thread with a link to the failing build and we will restart it.

Thanks in advance :)

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> So, here’s a plan:
>> 
>>   • Once Efraim has pushed some of the aarch64 patches, do another
>>     evaluation of the “core” package set for that branch, and check for
>>     anything wrong.  From there on, forbid full-rebuild changes.
>> 
>>   • Once the “core” subset builds correctly on all the supported
>>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>>     a couple of things like GnuTLS while we’re at it.  From there on
>>     forbid non-trivial changes.
>> 
>>   • Build all the packages.  (To do that, someone with access to Hydra
>>     must change the “subset” argument to “all” in the config of the
>>     ‘core-updates’ jobset.)
>> 
>>   • Fix things.
>
> We are at this stage... please help :)

Checking in for duty! o7

Here are the results of the latest evaluation:

https://hydra.gnu.org/eval/109570?full=1&compare=master#tabs-now-fail

I cannot reproduce these failures, please try restarting the jobs:

https://hydra.gnu.org/job/gnu/core-updates/c-graph-2.0.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/express-beta-diversity-1.0.7.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/gdm-3.22.1.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/gengetopt-2.22.6.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/libutf-0.0.0-1.ff4c606.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/mupdf-1.10a.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/ghc-mockery-0.3.2.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/gst-plugins-good-1.10.4.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/python-lit-0.5.0.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/ruby-concurrent-1.0.2.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/wcslib-5.16.i686-linux

With those out of the way, here are most remaining problems on x86_64:

* aegis
* discrover
* clang-3.5.2 (can this be removed?)
* elixir
* gcc-4.7.4 (likewise)
* glog
* a handful of guile libraries
* hugs (abondoned upstream, no users, remove?)
* khmer
* kodi
* ldc
* powertabeditor
* pspp
* scalapack
* stringtie
* swish-e
* vim-full

Once most of these are fixed, I think we're ready to merge!

Kodi is very interesting, most tests take <1s on 'master', but almost
every test take ~30s on 'core-updates' and invariably segfaults. Any
idea what might be going on?

Likewise, one "vim-full" test is failing on 'core-updates' for no good
reason. I would create an upstream issue if I had any idea what might be
causing it :)

Powertabeditor is likely fixed by an update, but I haven't tried it yet.
Any takers?

For the rest.. please share your findings!

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

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hi!

It looks like we’re doing okay now?  There are still a number of
armhf-linux builds pending, but if everything goes well, I think we
should merge tomorrow (Sunday).  WDYT?

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

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

> Hi!
>
> It looks like we’re doing okay now?  There are still a number of
> armhf-linux builds pending, but if everything goes well, I think we
> should merge tomorrow (Sunday).  WDYT?

One "greenisland" test is segfaulting. This package is needed for the
"sddm" display manager, so I don't think we should merge until that is
sorted. I'm looking into it now, but struggling to produce useful
debugging information.

"vim-full" also has a failing test, but is arguably less important.
There are "relink" warnings during the test phase, like this:

Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'

...but I'm not sure if it's actually related.

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> One "greenisland" test is segfaulting. This package is needed for the
> "sddm" display manager, so I don't think we should merge until that is
> sorted. I'm looking into it now, but struggling to produce useful
> debugging information.

Apparently "ctest" will invoke "gdb" for tests if available in PATH. The
stack trace was not very helpful to my untrained eye however..

Given that this software is abandoned upstream, I don't think it's worth
spending a lot of time on maintaining it (our Wayland is newer than the
latest Greenisland release). We'll eventually have to find another
Wayland compositor for SDDM, in the meantime I think it's okay to
disable this test. What do others think?

I've configured my system on 'core-updates' and can confirm that SDDM
works fine (after disabling greenisland tests).

Geronimo? :-)

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

‘core-updates’ merged!

[Ludovic Courtès]

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

Hello Guix!

With the last blocker out of the way, I’ve merged the branch!

The (not so new) news:

  • Updates: glibc 2.25, coreutils 8.26, grep 3.0, guile 2.0.14,
    sed 4.4, tzdata 2017a, etc.

  • Packages are built with GCC 5 (was 4.9).

  • Aarch64 is supported!

  • Reproducibility fixes: new ‘reset-gzip-timestamps’ build phase, use
    of Guile 2.0.14 which produces .go files deterministically,
    ‘perl-build-system’ no longer produces ‘perllocal.pod’ files (which
    were not reproducible).

  • No more broken store references in grafted stuff!
    <https://bugs.gnu.org/24703>

  • Only one entry in ‘GIT_EXEC_PATH’ & co.!
    <https://bugs.gnu.org/25422>

  • GNU/Hurd and powerpc-linux-gnu cross-compilation fixes.

… and probably lots of other things long forgotten.

Thanks to everyone who took the time to address the issues in this
branch!

Enjoy!

Ludo’.

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

‘core-updates’ freeze approaching!

[Ludovic Courtès]

Hi there!

We’ve been pushing a number a fixes, improvements, and package upgrades
in the ‘core-updates’ branch.

I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
building all of it within a day or two.  Any objections?

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
> building all of it within a day or two.  Any objections?

I’ve just pushed a patch to skip the Coreutils test that was causing
intermittent failures (see <http://bugs.gnu.org/21460>) and Hydra will
soon start rebuilding the ‘core’ package subset.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Since we’ve sidestepped the GnuTLS/libtasn1 issue 宋文武 reported by
reverting the libtasn1 upgrade, Hydra is now building all of
‘core-updates’:

  http://hydra.gnu.org/jobset/gnu/core-updates

Please keep an eye on it so we can fix breakage as quickly as possible.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Since we’ve sidestepped the GnuTLS/libtasn1 issue 宋文武 reported by
> reverting the libtasn1 upgrade, Hydra is now building all of
> ‘core-updates’:
>
>   http://hydra.gnu.org/jobset/gnu/core-updates
>
> Please keep an eye on it so we can fix breakage as quickly as possible.

The main (only?) remaining blocker now is pixman, where a test segfaults
on i686:

  https://bugs.freedesktop.org/show_bug.cgi?id=92027

I would not be comfortable just skipping tests since this seems to be a
genuine bug.

If someone else familiar with C could look into it, that’d be great.  To
reproduce it, run (on x86_64 or i686):

  ./pre-inst-env guix build pixman -s i686-linux

on a ‘core-updates’ checkout.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Andreas Enge]

On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
>   https://bugs.freedesktop.org/show_bug.cgi?id=92027

The segfault and the valgrind issue happen in different files, so they
do not seem to be related.

The code before the line where gdb places the error:
Program received signal SIGSEGV, Segmentation fault.
fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191
2191		t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
(gdb) bt
#0  fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191

is the following:
    while ((w -= 2) >= 0)
    {
        uint32_t sr, sb, sg, t0, t1;
        uint32_t s = *(const uint32_t *)src;
        src += 2;
        sr = (s >> 8) & 0x00F800F8;
        sb = (s << 3) & 0x00F800F8;
        sg = (s >> 3) & 0x00FC00FC;
        sr |= sr >> 5;
        sb |= sb >> 5;
        sg |= sg >> 6;
        t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
             (sb & 0xFF) | 0xFF000000;

This looks perfectly safe; all treated variables are scalars, so the result
may be wrong, but cannot cause a segfault. A problem with optimisation in gcc?
Or gdb giving a wrong line number? Since pointers are dereferenced before and
after that line.

I also tried to cd into /tmp/nix-build-..., source the environment variables
and run "make check"; then all tests pass (but the build is for i686-linux
on an x86_64-machine, so maybe this does not mean much outside the guix build
container?).

Andreas

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
>>   https://bugs.freedesktop.org/show_bug.cgi?id=92027
>
> The segfault and the valgrind issue happen in different files, so they
> do not seem to be related.

[...]

> I also tried to cd into /tmp/nix-build-..., source the environment variables
> and run "make check"; then all tests pass (but the build is for i686-linux
> on an x86_64-machine, so maybe this does not mean much outside the guix build
> container?).

With the patch applied (the patch I attached to the above bug report),
the problem indeed vanishes when outside of the build container, like
you describe.

Without the patch the problem is 100% reproducible both inside and
outside of the build container.

Ludo’.

‘core-updates’ merged!

[Ludovic Courtès]

Hi!

At last ‘core-updates’ is merged!

This brings:

  • Security fixes in icu4c (CVE-2014-6585 and CVE-2015-1270.)

  • libc 2.22–make sure to read
    <https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00717.html>
    before you upgrade!

  • New ‘install-file’ procedure in (guix build utils); consider using
    it where appropriate.

  • Patched tarballs are produced in a deterministic fashion (file
    ordering and time stamps.)

  • The closure size of openssl, curl, libtiff, libx11, libxt has been
    reduced.

  • ‘glib-or-gtk-build-system’ no longer generates icon-theme.cache
    since this is handled during profile generation.  This avoids
    collisions.

  • ‘glibc’ no longer provides bin/bash.

  • Many upgrades.

Ludo’.