Mark H Weaver writes:
> I tried to compile a freshly unpacked guix-0.11.0 tarball on my x86_64
> GuixSD system, which is running recent 'master'.
We've had a few releases since this bug report was opened. I'll close
this bug report now. Please open a new bug if you're having trouble
building t
Leo Famulari writes:
> Several packages still depend on webkitgtk@2.4, which is
> unmaintained upstream and surely contains many serious security
> vulnerabilities.
We've removed webkitgtk-2.4 in commit
38039b4fa917c7516535167fb082ea63850ee578, which has been merged into
master (according to 'gi
Maxim Cournoyer writes:
> As a ratpoison user, I also suffered from problems caused by the lack of
> a GSettings backend when not running Gnome; for example, the preferences
> would not be saved across GnuCash restarts.
>
> To fix this, I had to manually install dbus and dconf to my profile.
FYI
On Fri, 8 Jun 2018, Ludovic Courtès wrote:
Hi,
Jack Hill skribis:
Sure, I'll give make a path a go. You're thinking that I should try
applying the changes that the commit introduced as part of our package
definition?
Yes, either that or use a snapshot of upstream haskell-mode.
I have sta
Hi Gábor,
Gábor Boskovits skribis:
> I'm willing to investigate the possibilities we have in this case. Can you
> help me reproduce this, if it is still a problem?
Oops, I’m seeing your message just now and I fixed the issue earlier
today. Thanks for the offer though!
Ludo’.
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> At the moment, the most pressing failure caused by this bug is 'doxygen'
>> on armhf, which causes GCC to crash deterministically in the same place
>> every time, with many important dependency failures.
>
> Fixed very elegantly
Hi,
Jack Hill skribis:
> Sure, I'll give make a path a go. You're thinking that I should try
> applying the changes that the commit introduced as part of our package
> definition?
Yes, either that or use a snapshot of upstream haskell-mode.
Thanks,
Ludo’.
Hey hey!
Turns out ‘guix system disk-image --format=iso9660’ includes not sure
the closure of the given OS, but everything that’s in the build
environment’s store. So typically, we end up with QEMU and all in
addition to the store’s closure.
This stems from the fact that ‘make-iso9660-image’ doe
l...@gnu.org (Ludovic Courtès) skribis:
> Here’s what I get:
>
> $ guix system disk-image --file-system-type=iso9660
> gnu/system/examples/bare-bones.tmpl
> […]
> environment variable `PATH' set to
> `/gnu/store/fc24iwkx64d05rjmay734arc0z4izdl9-qemu-minimal-2.12.0/bin:/gnu/store/zr3lz229a9p2xs2d
Hi Mark,
Mark H Weaver skribis:
> At the moment, the most pressing failure caused by this bug is 'doxygen'
> on armhf, which causes GCC to crash deterministically in the same place
> every time, with many important dependency failures.
Fixed very elegantly in commit 849a1399ca46497ad6acc5b11903
Gábor Boskovits skribis:
> Thanks, Ludo, this seems to be the correct fix. Thanks for the additional
> insight.
> Please push it.
Pushed as 751164bca1030dfd14f9fa7508c03eb4b41173e4, thanks!
Ludo’.
2018-06-05 3:00 GMT+02:00 Mark H Weaver :
> l...@gnu.org (Ludovic Courtès) writes:
>
> > On current ‘core-updates’, we have:
> >
> > $ readlink -f $(type -P gcc)
> > /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
> > ludo@ribbon /home/ludo/src/guix/+core-updates$ cat strmov-ice.c
>
l...@gnu.org (Ludovic Courtès) writes:
> I’ve become convinced that this is due to parallelism: several
> guix-daemon processes run at the same time. In this case, I bet this
> process tries to remove an item from the ValidPaths table while another
> is trying to add it in the Refs table or somet
Here’s what I get:
--8<---cut here---start->8---
$ guix system disk-image --file-system-type=iso9660
gnu/system/examples/bare-bones.tmpl
[…]
environment variable `PATH' set to
`/gnu/store/fc24iwkx64d05rjmay734arc0z4izdl9-qemu-minimal-2.12.0/bin:/gnu/store/zr3l
14 matches
Mail list logo
