bug#24735: netpbm pstopnm tries to invoke /usr/bin/gs - it should depend on ghostscript and invoke that

2019-02-12 Thread Leo Famulari
On Tue, Oct 18, 2016 at 11:44:49PM +0200, Danny Milosavljevic wrote:
> Probably should be substituted out.
> 
> It already depends on ghostscript.

Thanks! Fixed in commit 344e0f56218f6b2680e0ab00446eed372216d420


signature.asc
Description: PGP signature


bug#25533: guixsd hardware issue

2019-02-12 Thread Leo Famulari
Closing due to lack of response.


signature.asc
Description: PGP signature


bug#25258: Bashisms when building 0.11.0

2019-02-12 Thread Leo Famulari
On Sat, Dec 24, 2016 at 08:26:27AM +0100, pelzflorian (Florian Pelz) wrote:
> Guix' testsuite uses the non-POSIX bashism `type -P guile` in
> tests/guix-packages.sh which causes a test failure when using
> Dash to provide /bin/sh instead of Bash. Additionally gnu/local.mk uses
> brace expansion which is not part of POSIX and does not work on Dash.
> 
> When building Guix on Parabola GNU/Linux-libre modified to use Dash as
> /bin/sh,[1] this causes the Guix build to fail. For building, the guix
> 0.11.0 package from AUR[2] was used. The attached “patch” allows for a
> successful build but is not what we want.
> 
> Guix should probably not use bashisms in its Makefile includes and
> either not use bashisms in its test suite or make sure the test suite is
> executed explicitly with Bash and not /bin/sh.

About two years have passed on this bug report without comment. Is it a
"wontfix"?


signature.asc
Description: PGP signature


bug#25036: make check-system hangs.

2019-02-12 Thread Leo Famulari
Closing because we no longer have QEMU 2.7.0 and haven't reproduced the
issue on the build farm.


signature.asc
Description: PGP signature


bug#24220: "failed to unpack source code" on guix pull

2019-02-12 Thread Leo Famulari
`guix pull` has been completely overhauled since the bug was filed so
I'm closing it.


signature.asc
Description: PGP signature


bug#18483: Dmd tries to initialize my network interface before it become available.

2019-02-12 Thread Leo Famulari
Is this bug still relevant? Or can we close it?


signature.asc
Description: PGP signature


bug#18261: Apparently intermittent failures to build gegl

2019-02-12 Thread Leo Famulari
Since gegl has seen many updates since this bug was filed and because,
according to the Hydra web interface, it now builds reliably on i686,
I'm closing this bug.





bug#34402: Inferior channel (I believe 'inferior-for-channels' function specifically) sometimes fails

2019-02-12 Thread Ludovic Courtès
Hi,

 skribis:

> It looks like line 16205 (at the bottom pretty much) shows that a permissions 
> issue is the culprit:
>
> openat(AT_FDCWD, 
> "/home/itsme/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/FETCH_HEAD",
>  O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)
>
> That file, along with  is owned by root and is in the root group, and 
> permissions are set to `-rw-r--r--`.
>
> It looks like this is caused by me running a guix command as root, with `sudo 
> -E` (the -E is probably why it's modifying ownership of files in my user's 
> guix cache directory), that checks out the git commit (I assume since it's 
> only changing the ownership on those two files, the rest in that directory 
> are owned by my user).
>
> Changing the owner of that file back to my user has made the error go away 
> when running `guix package -n -m example-manifest.scm` - and if i then run 
> that command again with 'sudo -E', the ownership of those files is changed 
> back to root.

Great that you found out!

Commits 70a50305c495ca96fdec3d31e7e7972cfc54f8ee and
1d8b10d00f0c242bc5ce9540737af3d3f24a05c0 fix error reporting in this
case: you now get an error message mentioning Git and the invalid
permissions on a file in ~/.cache/guix/checkouts.

Thanks,
Ludo'.





bug#33497: [PATCH] Re: bug#33497: Our CMake package has no documentation

2019-02-12 Thread Marius Bakke
Hello!

Now would be the time to get this in 'core-updates'.

Maxim Cournoyer  writes:

> Maxim Cournoyer  writes:
>
>> Hello,
>>
>> Our CMake package lacks any documentation (manpage or other). Patch to
>> follow.
>>
>> Maxim
>
> Here's the patch to be merged in core-updates (or core-updates-next).
>
> From 07625983cd901c94e4ac25b157035c95e33a115e Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Sun, 25 Nov 2018 01:39:54 -0500
> Subject: [PATCH] gnu: cmake: Generate the documentation.
>
> This fixes https://bugs.gnu.org/33497.
>
> * gnu/packages/cmake.scm (gnu): Use the (gnu package python) and
> (gnu packages texinfo) modules.
> (cmake)[configure]: Add arguments to configure so that manual pages, info and
> HTML documentation is generated.
> [move-html-doc]: New phase.
> [native-inputs]: Add the native inputs required for building the
> documentation.
> [outputs]: Add a "doc" output.

I'm not very comfortable with pulling python-sphinx into the dependency
closure of CMake, because then we can't update it or its dependencies
outside of the 'core-updates' cycle.  It could also cause circular
dependency issues down the road.

Would it make sense to build the documentation as a separate package?
In that case it can go on the master branch.


signature.asc
Description: PGP signature


bug#34441: Wrong build log-file given by Berlin build farm

2019-02-12 Thread Leo Famulari
On Tue, Feb 12, 2019 at 04:12:43PM +0100, Ludovic Courtès wrote:
> Not a bug!  :-)
> 
> Due to fixed-output derivations, there can be several derivations
> mapping to a given output.  Here you just got the build log for one of
> the derivations that produces
> fmwazsg7rgdq7zlxmq3rviwab54gxw8f-qemu-minimal-2.10.2.
> 
> I hope that makes sense!

Okay, thanks for the explanation :)





bug#34461: Debugging build failures on Berlin / qemu-minimal-2.10 not available on Berlin build farm

2019-02-12 Thread Leo Famulari
Substitutes of the hidden package qemu-minimal-2.10 are available from
 but not .

I'd like to fix this but I'm not sure how to start debugging things on
the Berlin build farm.

I know how to use the Hydra web interface to debug build failures but I
need help getting started with Berlin.





bug#34461: Debugging build failures on Berlin

2019-02-12 Thread Leo Famulari
I know this bug report is vague. Any guidance on a build debug workflow
for the Berlin build farm will be helpful.


signature.asc
Description: PGP signature


bug#34459: Docker and containerd bundled dependencies — what to do?

2019-02-12 Thread Leo Famulari
On Tue, Feb 12, 2019 at 01:45:01AM +0100, Danny Milosavljevic wrote:
> Docker still contains some vendored dependencies, among those 
> github.com/opencontainers/runc,
> in directory "vendor", and so does containerd.  It might make sense to also 
> remove them now.

I didn't do anything regarding the vendored / bundled deps in my patches
related to CVE-2019-5736 .

Regarding Docker, the update to 18.09.2 ostensibly fixed CVE-2019-5736,
I suppose by updating the bundled copy of runc.

For containerd I didn't change the package at all.

Both Docker and containerd depend on our runc package. If they don't
actually use it but instead use their bundled copy, we should remove the
dependency and document the bundling, or work on unbundling.

Unfortunately this is complicated for us in recent versions of Go:

https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00223.html


signature.asc
Description: PGP signature


bug#34184: Nitpick on reconfigure message: Installing for i386-pc platform.

2019-02-12 Thread Leo Famulari
On Wed, Jan 23, 2019 at 11:27:26PM +0100, Ricardo Wurmus wrote:
> Maybe we should
> 
> 1) prefix messages from other tools with the name of the tool, and
> 2) hide these tool messages by default behind descriptive messages like
> “installing bootloader”

Yes, absolutely. We just had another person ask about this on IRC.

It may not be the most important thing to fix overall, but it's one of
the first things people see when starting with a Guix system so it is
important.


signature.asc
Description: PGP signature


bug#34333: Docker daemon failing to start on boot

2019-02-12 Thread Danny Milosavljevic
Hi Allan,

On Tue, 12 Feb 2019 09:05:10 +
Allan Adair  wrote:

> On 2019-02-11 17:31, Danny Milosavljevic wrote:
> > Hi Allan,
> > 
> > I've added some more requirements--let's see.
> > 
> > Can you guix pull and guix reconfigure and then try again once more?  
> 
> Still no luck. Do you face the same issue?

I don't know since my machine has not finished updating after the
recent staging to master merge.


pgpiWmSuiTG4M.pgp
Description: OpenPGP digital signature


bug#34431: Qt fails to build

2019-02-12 Thread Ricardo Wurmus


Ludovic Courtès  writes:

> Danny Milosavljevic  skribis:
>
>> Possible fix https://672856.bugs.gentoo.org/attachment.cgi?id=557978
>>
>> diff -Naurp a/src/corelib/global/minimum-linux_p.h 
>> b/src/corelib/global/minimum-linux_p.h
>> --- a/src/corelib/global/minimum-linux_p.h  2018-11-25 
>> 15:51:11.0 +0300
>> +++ b/src/corelib/global/minimum-linux_p.h  2018-12-17 
>> 13:25:38.176823753 +0300
>> @@ -75,14 +75,9 @@ QT_BEGIN_NAMESPACE
>>   * - accept42.6.28
>>   * - renameat2  3.16QT_CONFIG(renameat2)
>>   * - getrandom  3.17
>> QT_CONFIG(getentropy)
>> - * - statx  4.11QT_CONFIG(statx)
>>   */
>>
>> -#if QT_CONFIG(statx)
>> -#  define MINLINUX_MAJOR4
>> -#  define MINLINUX_MINOR11
>> -#  define MINLINUX_PATCH0
>> -#elif QT_CONFIG(getentropy)
>> +#if QT_CONFIG(getentropy)
>>  #  define MINLINUX_MAJOR3
>>  #  define MINLINUX_MINOR17
>>  #  define MINLINUX_PATCH0
>
> Qt should definitely not require a kernel more recent than what libc
> requires.  If this patch solves that, we should probably apply it (in
> ‘staging’ I guess.)

Oh dear, this would certainly cause problems on RHEL 6 and 7.  Thanks
for trying to fix it!

-- 
Ricardo






bug#34427: guile-bootstrap@2.2 segfault?

2019-02-12 Thread Efraim Flashner
On Tue, Feb 12, 2019 at 03:27:37PM +0100, Ludovic Courtès wrote:
> Hello Efraim,
> 
> Efraim Flashner  skribis:
> 
> > I'm testing %bootstrap-guile from bootstrap.scm and I'm getting a
> > segfault when runing guile --version. I've attached an strace of the
> > process.
> 
> To be clear, I believe this is for a *cross-compiled* Guile, right?

That's right, %bootstrap-guile is extracted from $(guix build
--target=powerpc-linux-gnu bootstrap-tarballs)

> 
> The natively-built binary on x86_64-linux works fine:
> 
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped) ./bin/guile 
> --version
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> guile (GNU Guile) 2.2.4
> Copyright (C) 2018 Free Software Foundation, Inc.
> 
> License LGPLv3+: GNU LGPL 3 or later .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ guix describe
> Generacio 61  Feb 12 2019 11:14:38(nuna)
>   guix c86b5f1
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: c86b5f1b9bdfdd478ba15804f9343feb8d9c019b
> $ uname -m
> x86_64
> --8<---cut here---end--->8---
> 
> Since I saw a build failure similar to the one you mention when
> cross-building for GNU/Hurd, I’m tempted to think this has to do with
> cross-compilation.
> 
> Thanks,
> Ludo’.

I saw you mentioned that on IRC.

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


signature.asc
Description: PGP signature


bug#34441: Wrong build log-file given by Berlin build farm

2019-02-12 Thread Ludovic Courtès
Hello!

Leo Famulari  skribis:

> $ ./pre-inst-env guix build --no-grafts -e '(@@ (gnu packages virtualization) 
> qemu-minimal-2.10)' --substitute-urls=https://berlin.guixsd.org
> /gnu/store/fmwazsg7rgdq7zlxmq3rviwab54gxw8f-qemu-minimal-2.10.2
> $ ./pre-inst-env guix build --no-grafts -e '(@@ (gnu packages virtualization) 
> qemu-minimal-2.10)' --substitute-urls=https://berlin.guixsd.org -d
> /gnu/store/6k7gpas81l6bb4ds7pdxr8c9k65292vz-qemu-minimal-2.10.2.drv
> $ ./pre-inst-env guix build --no-grafts -e '(@@ (gnu packages virtualization) 
> qemu-minimal-2.10)' --substitute-urls=https://berlin.guixsd.org --log-file
>   
> https://berlin.guixsd.org/log/fmwazsg7rgdq7zlxmq3rviwab54gxw8f-qemu-minimal-2.10.2
>
> The log file shows that it belongs to a different derivation. Not to
> mention that it describes a failed build:
> --
> TEST: tests/test-io-channel-socket... (pid=14521)
> FAIL: tests/test-io-channel-socket
> make: *** 
> [/tmp/guix-build-qemu-minimal-2.10.2.drv-0/qemu-2.10.2/tests/Makefile.include:849:
>  check-tests/test-io-channel-socket] Error 1
>
> Test suite failed, dumping logs.
> Backtrace:
>4 (primitive-load "/gnu/store/5s9z2df3l8dn85nn29534yrhz1q…")
> In ice-9/eval.scm:
>191:35  3 (_ _)
> In srfi/srfi-1.scm:
>863:16  2 (every1 # …)
> In 
> /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm:
>799:28  1 (_ _)
> 369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)
>
> /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm:369:6:
>  In procedure check:
> Throw to key `srfi-34' with args `(# arguments: ("check") exit-status: 2 term-signal: #f stop-signal: #f] 
> 640040>)'.
> builder for 
> `/gnu/store/mr5zvp4wrlyiwl125qpzc9np8gnmlm26-qemu-minimal-2.10.2.drv' failed 
> with exit code 1
> @ build-failed 
> /gnu/store/mr5zvp4wrlyiwl125qpzc9np8gnmlm26-qemu-minimal-2.10.2.drv - 1 
> builder for 
> `/gnu/store/mr5zvp4wrlyiwl125qpzc9np8gnmlm26-qemu-minimal-2.10.2.drv' failed 
> with exit code 1
> --

Not a bug!  :-)

Due to fixed-output derivations, there can be several derivations
mapping to a given output.  Here you just got the build log for one of
the derivations that produces
fmwazsg7rgdq7zlxmq3rviwab54gxw8f-qemu-minimal-2.10.2.

I hope that makes sense!

Ludo’.





bug#34431: Qt fails to build

2019-02-12 Thread Ludovic Courtès
Danny Milosavljevic  skribis:

> Possible fix https://672856.bugs.gentoo.org/attachment.cgi?id=557978
>
> diff -Naurp a/src/corelib/global/minimum-linux_p.h 
> b/src/corelib/global/minimum-linux_p.h
> --- a/src/corelib/global/minimum-linux_p.h  2018-11-25 15:51:11.0 
> +0300
> +++ b/src/corelib/global/minimum-linux_p.h  2018-12-17 13:25:38.176823753 
> +0300
> @@ -75,14 +75,9 @@ QT_BEGIN_NAMESPACE
>   * - accept42.6.28
>   * - renameat2  3.16QT_CONFIG(renameat2)
>   * - getrandom  3.17QT_CONFIG(getentropy)
> - * - statx  4.11QT_CONFIG(statx)
>   */
>
> -#if QT_CONFIG(statx)
> -#  define MINLINUX_MAJOR4
> -#  define MINLINUX_MINOR11
> -#  define MINLINUX_PATCH0
> -#elif QT_CONFIG(getentropy)
> +#if QT_CONFIG(getentropy)
>  #  define MINLINUX_MAJOR3
>  #  define MINLINUX_MINOR17
>  #  define MINLINUX_PATCH0

Qt should definitely not require a kernel more recent than what libc
requires.  If this patch solves that, we should probably apply it (in
‘staging’ I guess.)

Thanks,
Ludo’.





bug#34427: guile-bootstrap@2.2 segfault?

2019-02-12 Thread Ludovic Courtès
Hello Efraim,

Efraim Flashner  skribis:

> I'm testing %bootstrap-guile from bootstrap.scm and I'm getting a
> segfault when runing guile --version. I've attached an strace of the
> process.

To be clear, I believe this is for a *cross-compiled* Guile, right?

The natively-built binary on x86_64-linux works fine:

--8<---cut here---start->8---
$ unshare -mrf chroot $(guix build guile-static-stripped) ./bin/guile --version
guile: warning: failed to install locale
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
guile (GNU Guile) 2.2.4
Copyright (C) 2018 Free Software Foundation, Inc.

License LGPLv3+: GNU LGPL 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ guix describe
Generacio 61Feb 12 2019 11:14:38(nuna)
  guix c86b5f1
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: c86b5f1b9bdfdd478ba15804f9343feb8d9c019b
$ uname -m
x86_64
--8<---cut here---end--->8---

Since I saw a build failure similar to the one you mention when
cross-building for GNU/Hurd, I’m tempted to think this has to do with
cross-compilation.

Thanks,
Ludo’.





bug#34423: gnome-shell-extensions and glib

2019-02-12 Thread Ludovic Courtès
Hello,

Brett Gilio  skribis:

> Hi all, when I try to install gnome-shell-extensions it is throwing this
> issue
>
> brettg@guixsd ~$ guix package -i gnome-shell-extensions
> The following package will be installed:
>gnome-shell-extensions 3.24.3  
> /gnu/store/bfw4wp2lm68s3gdhhbic0kr2rfzcab07-gnome-shell-extensions-3.24.3
>
> guix package: error: profile contains conflicting entries for glib
> guix package: error:   first entry: glib@2.56.3 
> /gnu/store/lly2sqknlw8h59bfffpgh836r38ffsdc-glib-2.56.3
> guix package: error:... propagated from gnome-shell-extensions@3.24.3
> guix package: error:   second entry: glib@2.56.2 
> /gnu/store/qc5b998gnhb5p8lc9mf0knr1nyc648k9-glib-2.56.2
> guix package: error:... propagated from cairo@1.14.12
> guix package: error:... propagated from guile-cairo@1.10.0
> guix package: error:... propagated from guile-gnome@2.16.5
> hint: Try upgrading both `gnome-shell-extensions' and `guile-gnome', or remove
> one of them from the profile.
>
>
>
>
>
> The strangeness of the issue is not only that glib seems to be
> referencing two different versions, but I don't even have guile-gnome
> installed for there to be a "conflict".

The message above suggests you do have ‘guile-gnome’ in this profile.
What does “guix package -I gnome” report?

Thanks,
Ludo’.





bug#34431: Qt fails to build

2019-02-12 Thread Andreas Enge
On Mon, Feb 11, 2019 at 04:27:38PM +0100, Andreas Enge wrote:
> It happens on my laptop, with kernel 4.9.0. But I thought it also happens
> on bayfront (kernel 4.19.1), which offloads to harbourfront (kernel 4.19.8).
> I will try the latter two again.

Actually I did not remember well, it did compile now on bayfront/harbourfront.
So this seems to be very transient and does not occur on the most recent Guix.
I am closing this bug, and we can open it again if there is a need; the
information on the potential patch will remain online anyway.

Andreas






bug#34454: (no subject)

2019-02-12 Thread Bradley Haggerty
I've now had a similar crash from emacs. I've got errors for both.
emacs erorr:
(emacs-26-1:1049): Gdk-ERROR **: 04:27:15.240: The program 'emacs-26-1'
received an X Window System error. This probably reflects a bug in the
program. The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 605 error_code 8 request_code 2 (core protocol)
minor_code 0) (Note to programmers: normally, X errors are reported
asynchronously; that is, you will receive the error a while after
causing it. To debug your program, run it with the GDK_SYNCHRONIZE
environment variable to change this behavior. You can then get a
meaningful backtrace from your debugger if you break on the
gdk_x_error() function.) Fatal error 5: Trace/breakpoint trap
Backtrace:
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x50b032]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x4f1f34]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x509cee]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x509fd3]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x50a089]
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libpthread.so.0(+0x12750)[0x7f0896f5b750]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(+0x53431)[0x7f0897f8b431]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(g_log_writer_default+0x182)[0x7f0897f8dbc2]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(g_log_structured_array+0x7c)[0x7f0897f8bf6c]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(g_log_structured_standard+0x182)[0x7f0897f8c962]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x634bd)[0x7f08984804bd]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x6f7c9)[0x7f089848c7c9]
/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/lib/libX11.so.6(_XError+0xf5)[0x7f0897e16475]
/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/lib/libX11.so.6(+0x434f7)[0x7f0897e134f7]
/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/lib/libX11.so.6(+0x435a5)[0x7f0897e135a5]
/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/lib/libX11.so.6(_XReply+0x208)[0x7f0897e14428]
/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/lib/libX11.so.6(XGetWindowProperty+0xe6)[0x7f0897dfb356]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x2f2b1)[0x7f089844c2b1]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x64deb)[0x7f0898481deb]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x6a8e2)[0x7f08984878e2]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x6a41c)[0x7f089848741c]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(gdk_display_get_event+0x79)[0x7f0898453769]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgdk-3.so.0(+0x6a002)[0x7f0898487002]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(g_main_context_dispatch+0x287)[0x7f0897f85b57]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(+0x4dd98)[0x7f0897f85d98]
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7f0897f85e3c]
/gnu/store/wjs7m0isjzixaslfbcqz3v2ic3zfbr5a-gtk+-3.24.2/lib/libgtk-3.so.0(gtk_main_iteration+0x15)[0x7f089874e185]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x4c1b02]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x4f90c9]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x4f9625]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x4cda91]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x427798]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x565d16]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x59ba68]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x565c83]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x59ba68]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x565c83]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x56775e]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x565d16]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x59ba68]
/gnu/store/40w5rmp52z2xr8bjdim65rq7d4g89mdd-emacs-26.1/bin/emacs-26.1[0x565c83]
...
zsh: trace trap  emacs

icecat error:
(icecat:1125): Gdk-ERROR **: 10:28:30.375: The program 'icecat'
received an X Window System error. This probably reflects a bug in the
program. The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 11602 error_code 8 request_code 2 (core protocol)
minor_code 0) (Note to programmers: 

bug#34211: error running container: mingetty cannot find ttys

2019-02-12 Thread Giovanni Biscuolo
Hi Ludo'

thank you for looking into this issue!

Ludovic Courtès  writes:

[...]

> I also get this behavior.

OK, so this is deterministic now :-)

> What happens is that the /dev/ttyN nodes do not exist (understandably),
> and thus the ‘console-font-ttyN’ Shepherd services fail to start, and
> get restarted, indefinitely.

actually they do fail but they are not respawned, the services that get
respawned are term-tty[1..6]

> The container is working as expected though.  If you find the PID of the
> container’s ‘shepherd’ process (its PID 1, which obviously has a
> different PID outside the container), then you can do:
>
>   guix container exec NNN /bin/sh

I have to use "sudo" to be able to start and "guix container exec" a
shell in it (I mean: sudo guix container exec...)

I used that command in another terminal so I could see the console
messages from the container

> where NNN is that PID of that ‘shepherd’ process (I use ‘pstree’ to find
> the PID… not very convenient.)

oh yes! I did not realized that my container was there waiting for me
:-)
...I also did not realized thet the container is started as a foreground
process, so we nees to background

I used pstree too, we need a better way to interact with a container (by
name and not by PID); sorry but I still cannot help here, my Guile
proficency is still too low; anyway this is tangent to this bug

> In that shell, you can do:

[...]

> So in that sense everything is working “as expected.”

yes, I see: I stopped term-tty[1..6] and the failure messages disappeared

> Now, it would make more sense to simply remove those ‘console-font-ttyN’
> services in a container and everything that depends on them.

as pointed above the faining services are term-tty[1..6],
console-font-tty[1..6] fails but do not get respawned do they are not
the real issue

> Not sure if we should do that automatically.

I'll try to remove term-tty[1..6] manually from services declaration, if
I manage to "manually" solve this I'll report here

> Thoughts?

since mingetty does not make sense in a container I'd remove
term-tty[1..6] (and console-font-tty[1..6]) automatically and by default
when we create a container via "guix system container..."

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature


bug#34454: After an update, icecat now segfaults very quickly after opening.

2019-02-12 Thread Bradley Haggerty
user profile version: guix (GNU Guix)
d5612439178465cd5bda6c69b71d6afb652b83e5
icecat version: GNU IceCat 60.5.0
system profile version: guix (GNU Guix)
db7c901af1dfaaab2e12218759475a6e121ac3b7

I am able to launch icecat, but loading some sites (e.g. riot.im) or
trying to restore my session seem to make it segfault very quickly. I
even had a crash on the session restore page so now the session it
restores is just an empty tab and it still crashes. Icecat is installed
via my user profile, but I recently updated both system and user
packages. I don't recall the breakage/crashing until very recently, so
I suspect it is the user profile which more recently finished.





bug#34427: [PATCH] build guile-static with guile-2.0

2019-02-12 Thread Efraim Flashner
When experimenting I found that using guile@2.0 as a base for
guile-static, the resulting guile-static didn't segfault on the target
architecture.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 18035c4ec2c698f01e6324bc013a536fc036cc0a Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Mon, 11 Feb 2019 15:10:29 +0200
Subject: [PATCH 1/2] gnu: %guile-static: Build for guile@2.0.

%guile-static@2.2 currently segfaults when run.

* gnu/packages/make-bootstrap.scm (%guile-static): Rewrite package to
use guile@2.0 as a base.
---
 gnu/packages/make-bootstrap.scm | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index c6002eb63a..836f24debf 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018 Ludovic Courtès 

-;;; Copyright © 2017 Efraim Flashner 
+;;; Copyright © 2017, 2019 Efraim Flashner 
 ;;; Copyright © 2018 Tobias Geerinckx-Rice 
 ;;; Copyright © 2018 Mark H Weaver 
 ;;;
@@ -518,29 +518,29 @@ for `sh' in $PATH, and without nscd, and with static NSS 
modules."
   ;; .scm and .go files relative to its installation directory, rather
   ;; than in hard-coded configure-time paths.
   (let* ((patches (cons* (search-patch "guile-relocatable.patch")
- (search-patch "guile-2.2-default-utf8.patch")
+ (search-patch "guile-default-utf8.patch")
  (search-patch "guile-linux-syscalls.patch")
- (origin-patches (package-source guile-2.2
- (source  (origin (inherit (package-source guile-2.2))
+ (origin-patches (package-source guile-2.0
+ (source  (origin (inherit (package-source guile-2.0))
 (patches patches)))
- (guile (package (inherit guile-2.2)
-  (name (string-append (package-name guile-2.2) "-static"))
+ (guile (package (inherit guile-2.0)
+  (name (string-append (package-name guile-2.0) "-static"))
   (source source)
   (synopsis "Statically-linked and relocatable Guile")
 
   ;; Remove the 'debug' output (see above for the reason.)
-  (outputs (delete "debug" (package-outputs guile-2.2)))
+  (outputs (delete "debug" (package-outputs guile-2.0)))
 
   (inputs
`(("libunistring:static" ,libunistring "static")
- ,@(package-inputs guile-2.2)))
+ ,@(package-inputs guile-2.0)))
 
   (propagated-inputs
`(("bdw-gc" ,libgc)
  ,@(alist-delete "bdw-gc"
- (package-propagated-inputs guile-2.2
+ (package-propagated-inputs guile-2.0
   (arguments
-   (substitute-keyword-arguments (package-arguments guile-2.2)
+   (substitute-keyword-arguments (package-arguments guile-2.0)
  ((#:configure-flags flags '())
   ;; When `configure' checks for ltdl availability, it
   ;; doesn't try to link using libtool, and thus fails
@@ -563,7 +563,7 @@ for `sh' in $PATH, and without nscd, and with static NSS 
modules."
(("^guile_LDFLAGS =")
 "guile_LDFLAGS = -all-static")
 
-   ;; Add `-ldl' *after* libguile-2.2.la.
+   ;; Add `-ldl' *after* libguile-2.0.la.
(("^guile_LDADD =(.*)$" _ ldadd)
 (string-append "guile_LDADD = "
(string-trim-right ldadd)
@@ -591,13 +591,13 @@ for `sh' in $PATH, and without nscd, and with static NSS 
modules."
 (out(assoc-ref %outputs "out"))
 (guile1 (string-append in "/bin/guile"))
 (guile2 (string-append out "/bin/guile")))
-   (mkdir-p (string-append out "/share/guile/2.2"))
-   (copy-recursively (string-append in "/share/guile/2.2")
- (string-append out "/share/guile/2.2"))
+   (mkdir-p (string-append out "/share/guile/2.0"))
+   (copy-recursively (string-append in "/share/guile/2.0")
+ (string-append out "/share/guile/2.0"))
 
-   (mkdir-p (string-append out "/lib/guile/2.2/ccache"))
-   (copy-recursively (string-append in "/lib/guile/2.2/ccache")
- (string-append out "/lib/guile/2.2/ccache"))
+   

bug#34333: Docker daemon failing to start on boot

2019-02-12 Thread Allan Adair

On 2019-02-11 17:31, Danny Milosavljevic wrote:

Hi Allan,

I've added some more requirements--let's see.

Can you guix pull and guix reconfigure and then try again once more?


Still no luck. Do you face the same issue?

--
Allan Adair
+47 468 12 135
al...@adair.io
http://allan.adair.io