bug#36855: guix system switch-generation doesn't

[Chris Marusich]

Hi Robert,

Robert Vollmert  writes:

> On 8. Aug 2019, at 18:40, Chris Marusich  wrote:
>> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
>> 
>>> 'switch-to-system-generation' doesn't call out to
>>> 'upgrade-shepherd-services'. I'm not sure if this was an intentional
>>> decision or not
>> 
>> It is intentional, but only because there is currently no way to call
>> upgrade-shepherd-services when switching system generations.
>
> How does shepherd work on a non-guix system? Can’t be it be configured
> like other daemons to read its configuration from a file, e.g. from
>
>/run/current-system/etc/shepherd.conf
>
> and be told via signal to reload its configuration from disk?

Maybe!  In the email thread I linked, Ludo talked about storing a
description of the Shepherd services in the system generation for future
reference.  Maybe we could store it in a place like this, and maybe
Shepherd already has mechanisms for reloading configurations like this.
I don't intend to work on this because I need to focus on other things
right now, but I would be happy if someone took up this work!

> (I feel a bit cheated right now. This behaviour makes Guix System entirely
> unsuitable for server use. It shouldn’t be advertised as supporting
> transactional upgrades and rollbacks if those require a reboot.)

I agree that Guix should update as many Shepherd services as it can when
switching generations.  However, I don't think it's inaccurate to say
that Guix supports transactional upgrades and rollbacks.  When you
invoke "guix system switch-generation", the system profile symlink is
flipped atomically, so you get an atomic update from one version of the
system to another.  Software running in the system never sees an
inconsistent view of the system.  Contrast this with nearly any other
mutable GNU/Linux system, in which files are more or less sprayed into
the existing file system with no guarantee of consistency or atomicity.

-- 
Chris


signature.asc
Description: PGP signature

bug#36840: Failing tests (tests/swh.scm tests/pypi.scm tests/gem.scm tests/crate.scm tests/cpan.scm)

[Ludovic Courtès]

Hello,

P  skribis:

> commit: 767a0a18d88479c713f1b9b034bd06eedfe71a80 (or rather the previous 
> commit, there are some small unrelated changes in gnu/packages/idris.scm)
>
> make check TESTS="tests/swh.scm tests/pypi.scm tests/gem.scm tests/crate.scm 
> tests/cpan.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"
>
> =
>GNU Guix 1.0.1.1832-23243: ./test-suite.log
> =
>
> # TOTAL: 21
> # PASS:  12
> # SKIP:  1
> # XFAIL: 0
> # FAIL:  8
> # XPASS: 0
> # ERROR: 0

The likely reason is that you’re using Guile-JSON 1.x instead of 3.x,
which is now required.

If you’re using ‘guix environment’, you may need to run:

  guix environment guix --ad-hoc guile-json@3

HTH!

Ludo’.

bug#34016: Git checkouts managed by (guix git) grow indefinitely?

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> So it’s Guile-Git, called from ‘update-cached-checkout’¹, that would open
> all these pack files, quickly running out of file descriptors.  I wonder
> if we’re doing something wrong here or if we hit a limitation of
> libgit2.  Ideas?

Forwarded here: .

Ludo’.

bug#36991: spacefm segmentation fault

[Bradley Haggerty]

I've just installed spacefm. When I launch it I get a warning about
not having my root editor configured, and then I get a segmentation
fault. Nothing ever appears graphically. I believe these issues are
unrelated, but I can't be sure.

brad@kazuki:~/ > spacefm

(spacefm:18027): SpaceFM-WARNING **: 13:01:17.628: No root settings
found in /gnu/store/6drirn0mil0maz1wjzf5q6hhnsdc3hq0-spacefm-1.0.6/etc/spacefm/
 Setting a root editor in Preferences should remove this warning on
startup.   Otherwise commands run as root may present a security risk.
zsh: segmentation fault  spacefm

guix version:
guix (GNU Guix) 355ba48c463a786149cb6bef8396090c0d6d3498

bug#36992: linux-libre-5.2.7 failed to build on armhf and aarch64; why?

[Mark H Weaver]

linux-libre-5.2.7 failed to build on Berlin due to a dependency failure:

  https://ci.guix.gnu.org/search?query=linux-libre-5
  https://ci.guix.gnu.org/build/1556871/details
  https://ci.guix.gnu.org/build/1556831/details

I guess that the deblobbing derivation probably failed, but I don't see
a way to confirm this, or to find out what specifically went wrong.

Specifically, I'd like to know:

(1) Which derivations failed, that caused these dependency failures?
(2) Were the failed build logs saved, and if so, how can I see them?
(3) Did the failed derivations time out, or was it another kind of failure?

Can someone help me find out what's going on here?

 Thanks,
   Mark

bug#36991: spacefm segmentation fault

[Bradley Haggerty]

Just adding some info, I'm using Sway on Wayland. I noticed another
program, pcmanfm-qt was complaining about missing a plugin for wayland
support, so perhaps spacefm needs to support wayland and doesn't
currently.

bug#36992: linux-libre-5.2.7 failed to build on armhf and aarch64; why?

[Ricardo Wurmus]

Hi Mark,

> linux-libre-5.2.7 failed to build on Berlin due to a dependency failure:
>
>   https://ci.guix.gnu.org/search?query=linux-libre-5
>   https://ci.guix.gnu.org/build/1556871/details
>   https://ci.guix.gnu.org/build/1556831/details
>
> I guess that the deblobbing derivation probably failed, but I don't see
> a way to confirm this, or to find out what specifically went wrong.
>
> Specifically, I'd like to know:
>
> (1) Which derivations failed, that caused these dependency failures?

Some time ago I added a feature to Cuirass that allowed us to see what
dependency was responsible.  This worked through a somewhat awkward
processing of derivation files.  I guess that this no longer works since
the representation of derivation inputs has changed.

I’ll try to verify this later and fix this if possible.

It would be great if we didn’t have to do this and Cuirass were able to
record enough information when the build failed…

> (2) Were the failed build logs saved, and if so, how can I see them?

This also used to work before.  I’ll also look into that.  Previously
there would be a link to the logs on the details page.

> (3) Did the failed derivations time out, or was it another kind of failure?

I guess the logs — once available — will help us answer this question.

--
Ricardo

bug#36991: spacefm segmentation fault

[ison]

On Fri, Aug 09, 2019, Bradley Haggerty wrote:
> Just adding some info, I'm using Sway on Wayland. I noticed another
> program, pcmanfm-qt was complaining about missing a plugin for wayland
> support, so perhaps spacefm needs to support wayland and doesn't
> currently.

I also couldn't get spacefm to launch a while ago when I tried
Wayland. However, I notice that the developer has a separate
"spacefm-wayland" repository with a link to an issue on why normal
spacefm doesn't work in Wayland.
It says it's a temporary branch so I suppose eventually spacefm will
support it, but if you want to get it working now you'd probably
have to build from here instead:
https://github.com/IgnorantGuru/spacefm-wayland

bug#36972: ghc-8.6.5 won't complete its build phase

[Timothy Sample]

Hi Brian,

Brian Leung  writes:

> Hi Tim,
>
> Thanks for your response. I've tried upgrading again and everything
> works fine. For whatever reason, when I tried upgrading last time,
> there was no indication that the tests ever started running, not even
> a couple of hours after the build phase appeared to reach 100%.

That’s certainly odd.  I would have expected it to indicate that it had
started the check phase.  Without a way to reproduce this, I doubt we’ll
be able to fix it.  For that reason, I’m opting to close this bug now.
However, if you notice anything like this again, we can always reopen
it.

> One last question: I notice from haskell.scm that "ghc" presently
> refers to ghc-8, which refers to ghc-8.4. If this is the case (I guess
> I'm probably wrong in my understanding), why did Guix choose to
> upgrade my installation of 8.4 to 8.6 at all?

The default GHC version for building Guix’s Haskell packages is 8.4.3,
but the newest version is 8.6.5.  When you tell Guix that you want “ghc”
it finds the latest version, rather than the version it uses for other
packages.  This is the same as GCC.  Even though Guix uses GCC 5 as it’s
default compiler, if you install “gcc-toolchain”, you’ll get version 9.
This all happens based on the “name” fields of the packages rather than
the Guile variables used to refer to them.  Hence the “ghc” variable
name is only meaningful insofar as it’s what the Haskell build system
uses as its default compiler.


-- Tim