bug#41702: `guix environment` performance issues

2020-06-04 Thread Lars-Dominik Braun
Hi,

I’ve noticed that `guix environment` can be very very slow for some packages.
Whereas usually a call like

time guix environment --ad-hoc  -- true

takes 600ms to 1.5s, it takes 8.4s for the package r-learnr on my Ryzen 5 3600
with NVMe SSD, 32G of RAM and a warm cache. This seems to accumulate when
trying to install multiple unrelated “slow” packages into the same environment,
i.e. jupyter (2.9s) + r-rlearnr (8.4s) + r-stm (2.9s) = 12.1s. What these
packages seem to have in common is a deep chain of propagated inputs.

And in fact, if I create artificial test packages where test-999 propagates
test-998, test-998→test-997 and so on the command above takes 1m 9s. A single
package propagating 999 packages takes 4.5s.

Instrumenting guix-environment’s with-store call with statprof I see a lot of
time is spent in the garbage collector:

Total time: 24.672604202 seconds (19.431122691 seconds in GC)
./pre-inst-env guix environment --ad-hoc r-learnr -- true  25,18s user 0,24s 
system 308% cpu 8,248 total

More specifically in an anonymous function and reap-pipes, which is a gc hook,
I believe:

% cumulative   self
time   secondsseconds   calls   procedure
 33.41 14.49  8.24anon #xbb8480
 27.95  6.90  6.90
ice-9/popen.scm:145:0:reap-pipes
  4.37  1.08  1.08anon #xbbdcd8
  3.28  0.86  0.81
ice-9/vlist.scm:539:0:vhash-assq
  2.40  2.37  0.59guix/grafts.scm:202:22

Not sure if that helps tracking the issue down though.

Cheers,
Lars

PS: Here’s `guix describe`:
Generation 1Jun 03 2020 10:38:17(current)
  guix 9ab2790
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 9ab2790e2acf872c0f2cf41ec180de80d1eee3f3
  zpid bab33c1
repository URL: https://github.com/leibniz-psychology/guix-zpid.git
branch: master
commit: bab33c19e0f0304d7aa82751653eb85d8cad8c0a



signature.asc
Description: PGP signature


bug#41541: merge wip-hurd-vm

2020-06-04 Thread Ludovic Courtès
Hi!

Jan Nieuwenhuizen  skribis:

> --- a/gnu/packages/hurd.scm
> +++ b/gnu/packages/hurd.scm
> @@ -390,6 +390,8 @@ PATH=@PATH@
>  
>  fsck --yes --force /
>  fsysopts / --writable
> +
> +# Note: this /hurd/ gets substituted
>  settrans -c /servers/socket/1 /hurd/pflocal
>  
>  # parse multiboot arguments
> @@ -421,9 +423,18 @@ exec ${system}/rc \"$@\"
> (substitute* '("utils/uptime.sh")
>   (("/bin/w")
>(string-append out "/bin/w")))
> -   (substitute* "daemons/console-run.c"
> +   (substitute* '("boot/boot.c"
> +  "daemons/console-run.c"
> +  "startup/startup.c")
>   (("/hurd/")
>(string-append out "/hurd/")))
> +   (substitute* "hurd/paths.h"
> + (("_HURD_STARTUP\t")
> +  (string-append "_HURD_STARTUP\t\"" out "\" "))
> + (("_HURD_PROC\t")
> +  (string-append "_HURD_PROC\t\"" out "\" "))
> + (("_HURD_AUTH\t")
> +  (string-append "_HURD_AUTH\t\"" out "\" ")))
> (substitute* '("daemons/runsystem.sh"
>"sutils/MAKEDEV.sh")
>   (("^PATH=.*")
>
> produces a bootable VM.  So...this could be great or maybe...well, what
> do you think?

As discussed on IRC, I wonder if changing  is a good idea
because it’s captured by libc, etc.  So it could have the effect of
forcing all the applications to refer to /gnu/store/…-old-hurd instead
of using the (typically more up-to-date) /hurd.

It could also lead to setting /gnu/store/…-old-hurd as passive
translator settings, which would be very bad because
/gnu/store/…-old-hurd could be GC’d (the GC doesn’t scan passive
translator settings and probably never will).

Thanks,
Ludo’.





bug#41237: guix deploy hangs when a file-system-device is set to a UUID

2020-06-04 Thread Ludovic Courtès
Brice Waegeneire  skribis:

> On 2020-06-03 14:56, Ludovic Courtès wrote:
>> Could you try running this at the REPL:
>> 
>>   (load 
>> "/gnu/store/wzvn8r2z7lnf5mqzagxzcb64wr69kgk4-remote-assertion.scm")
>> 
>> and then hit C-c and type “,bt” to get a backtrace?
>
> Here is the backtrace:
>
> In ice-9/boot-9.scm:
> 2806:4  6 (save-module-excursion _)
>4351:12  5 (_)
> In unknown file:
> 4 (find # …)
> In gnu/system/uuid.scm:
>  302:5  3 (uuid=? . _)
> In unknown file:
> While executing meta-command:
> In procedure frame-local-ref: Argument 2 out of range: 0

And what does “,locals” show?

Ludo’.





bug#22883: Channel introductions

2020-06-04 Thread Ludovic Courtès
Hi,

zimoun  skribis:

> On Wed, 3 Jun 2020 at 11:50, Ludovic Courtès  wrote:
>> zimoun  skribis:
>> > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès  wrote:
>
>> >>  If that information were stored in ‘.guix-channel’, it would be
>> >>  trivial for an attacker to fork the project (or push a new commit)
>> >>  and pretend the authentication process must not take previous
>> >>  commits into account.
>> >
>> > What will happen to recursive '.guix-channel'?  The '.guix-channel' of
>> > channel A contains the reference to the channel B where the
>> > '.guix-channel' contains the reference to the channel C, etc.
>>
>> I’m not sure I understand.  (The sentence above is about *not* storing
>> info in ‘.guix-channel’.)
>
> Sorry, I have misread.
> The question about recursive still applies. ;-)
> Currently, if the local channel file points to a channel A which
> contains the file '.guix-channel' which points to another channel B,
> then when one runs "guix pull" well the channel A will be pulled and
> then the channel B, even if this channel B is not explicit in the
> initial local channel.  (Even, there is bug about recursive implicit
> pulls, see http://issues.guix.gnu.org/issue/41069; well another
> story.)
>
> What happens for such situation?

Nothing special, I guess: each channel would be authenticated (or not,
if it’s an unsigned channel).  I think it’s completely orthogonal.

>> >>   4. When publishing a fork of a channel, one emits a new channel
>> >>  introduction.  Users switching to the fork have to explicitly allow
>> >>  that new channel via its introduction; flipping the URL won’t be
>> >>  enough because ‘guix pull’ would report unauthorized commits.
>> >
>> > I am a bit afraid by this... and I hope that a fork of a channel will
>> > still work without emitting a new channel introduction.
>>
>> No, when publishing a fork of an authenticated channel, you’ll have to
>> publish its introduction alongside its URL.
>
> I do not understand your two answers.  Well, there is 4 situations
> when publishing:
>
>  1- an authenticated fork of an authenticated channel
>  2- an authenticated fork of an unauthenticated channel
>  3- an unauthenticated fork of an authenticated channel
>  4- an unauthenticated fork of an unauthenticated channel
>
> "authenticated channel" means a channel using all the authentication 
> machinery.
> "authenticated fork" means add a "channel introduction" and so become
> a "authenticate channel" then.

I’m sorry, I don’t follow the terminology.

> Today, we are in the situation 4. and we are going to the 1.  if I
> understand correctly.
> And if I understand your answer above about good ol' channel, the 4.
> will still work and emit a warning, isn't it?
> What about the 2. and 3.?
>
> These situations correspond to:
>
> 1- the correct way
> 2- bootstrap the trust
> 3- and 4- quick and dirty "Scientific" workflows where the security is
> not a concern.

Funny how “scientific” has become synonymous with “quick-and-dirty”
these days…

[…]

> Genuine commits and outdated mirrors are separated questions, IMHO.
>
>
>> Since there’s no way to answer the question “is this the latest commit?”
>> in a general way, the best we can do, I think, is to detect whether
>> we’re talking to the “official” Git repo.
>
> What does "official" mean here?  To me, it means commits that I trust,
> i.e., approved by an authority.  My local clone is not less "official"
> than the repo on Savannah.
>
> I do not understand why the question “is this the latest commit?” has
> to be answered.  If an user wants the latest commits, then they
> directly pulls from upstream, i.e, from Savannah.  If an user wants to
> pull from a mirror for whatever reasons, then they knows that the last
> updates are not necessary there, since it is a mirror and not upstream
> -- and it is the responsibility of the mirror maintainer to keep it
> up-to-date.  However, what the user wants to know is whether the
> mirror has not introduced malicious commits.

Guix is a software supply tool.  There are two important security
questions a software supply client must address: “am I getting the
authentic stuff?”, and “am I getting the latest stuff?”.  The first one
is obvious, the second one relates to “downgrade attacks” which can
introduce known security vulnerabilities.

Things like The Update Framework (TUF) address both, but they do that in
a context that’s technically “like Debian” (binary distro) and very
different from Guix.

Yet, these two issues must also be addressed in Guix, like in any other
distro.

What we’ve been discussing here addresses the first question.  For the
second question, the best answer I came up with is that of an “official
URL”, allowing users to know the URL that should give them the latest
stuff.

“Official” means that it genuinely comes from the organization I
entrusted with my computer, be it the Guix project, another organization
maintaining a Guix fork, or an organization maintain

bug#41237: guix deploy hangs when a file-system-device is set to a UUID

2020-06-04 Thread Brice Waegeneire

Hello Ludo',

On 2020-06-04 09:41, Ludovic Courtès wrote:

Brice Waegeneire  skribis:

In ice-9/boot-9.scm:
2806:4  6 (save-module-excursion _)
   4351:12  5 (_)
In unknown file:
4 (find # 
…)

In gnu/system/uuid.scm:
 302:5  3 (uuid=? . _)
In unknown file:
While executing meta-command:
In procedure frame-local-ref: Argument 2 out of range: 0


And what does “,locals” show?


There isn't much:

--8<---cut here---start->8---
scheme@(guix-user) [1]> ,locals
  Local variables:
  $1 = closure = #
--8<---cut here---end--->8---

- Brice





bug#41237: guix deploy hangs when a file-system-device is set to a UUID

2020-06-04 Thread Ludovic Courtès
Hey,

Brice Waegeneire  skribis:

> On 2020-06-04 09:41, Ludovic Courtès wrote:
>> Brice Waegeneire  skribis:
>>> In ice-9/boot-9.scm:
>>> 2806:4  6 (save-module-excursion _)
>>>4351:12  5 (_)
>>> In unknown file:
>>> 4 (find # 
>>> …)
>>> In gnu/system/uuid.scm:
>>>  302:5  3 (uuid=? . _)
>>> In unknown file:
>>> While executing meta-command:
>>> In procedure frame-local-ref: Argument 2 out of range: 0
>> 
>> And what does “,locals” show?
>
> There isn't much:
>
> scheme@(guix-user) [1]> ,locals
>Local variables:
>$1 = closure = #

And in upper frames?  (Type “,up”.)





bug#41541: merge wip-hurd-vm

2020-06-04 Thread Jan Nieuwenhuizen
Ludovic Courtès writes:

Hello!

> Jan Nieuwenhuizen  skribis:
>
>> --- a/gnu/packages/hurd.scm
>> +++ b/gnu/packages/hurd.scm

[...]

>> +   (substitute* "hurd/paths.h"
>> + (("_HURD_STARTUP\t")
>> +  (string-append "_HURD_STARTUP\t\"" out "\" "))
>> + (("_HURD_PROC\t")
>> +  (string-append "_HURD_PROC\t\"" out "\" "))
>> + (("_HURD_AUTH\t")
>> +  (string-append "_HURD_AUTH\t\"" out "\" ")))
>> (substitute* '("daemons/runsystem.sh"
>>"sutils/MAKEDEV.sh")
>>   (("^PATH=.*")
>>
>> produces a bootable VM.  So...this could be great or maybe...well, what
>> do you think?
>
> As discussed on IRC, I wonder if changing  is a good idea
> because it’s captured by libc, etc.

Thank you for explaining it on IRC and stating it so clearly here again;
this really helped me!

> So it could have the effect of
> forcing all the applications to refer to /gnu/store/…-old-hurd instead
> of using the (typically more up-to-date) /hurd.
>
> It could also lead to setting /gnu/store/…-old-hurd as passive
> translator settings, which would be very bad because
> /gnu/store/…-old-hurd could be GC’d (the GC doesn’t scan passive
> translator settings and probably never will).

Ah...right.  As discussed on IRC, I already tried only using a fixed
file-name for _HURD_STARTUP (out + "/hurd/startup"); which worked.

So, after digesting your message here I took the next step: grep for
_HURD_STARTUP and change it there, like so

diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
index 421783eb80..8c73ea8430 100644
--- a/gnu/packages/hurd.scm
+++ b/gnu/packages/hurd.scm
@@ -428,9 +428,10 @@ exec ${system}/rc \"$@\"
   "startup/startup.c")
  (("/hurd/")
   (string-append out "/hurd/")))
-   (substitute* "hurd/paths.h"
- (("_HURD_STARTUP\t")
-  (string-append "_HURD_STARTUP\t\"" out "\" ")))
+   (substitute* '("libdiskfs/boot-start.c"
+  "libdiskfs/opts-std-startup.c")
+ (("_HURD_STARTUP")
+  (string-append "\"" out "/hurd/startup\"")))

This also works, and so I figure we're fine now.  I'm resetting
wip-hurd-vm and, like Mathieu suggested will prepare to send send a
patch series here for the unreviewed subset of patches.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com





bug#41607: Deleted store items are not actually deleted

2020-06-04 Thread Ludovic Courtès
Hi,

Chris Marusich  skribis:

> The reason Guix is failing to GC dead items in the Docker container is
> because those dead items are not on the "top layer", so Docker returns
> an EXDEV error:
>
> https://docs.docker.com/storage/storagedriver/overlayfs-driver/
>
> "Renaming directories: Calling rename(2) for a directory is allowed only
> when both the source and the destination path are on the top
> layer. Otherwise, it returns EXDEV error ('cross-device link not
> permitted'). Your application needs to be designed to handle EXDEV and
> fall back to a 'copy and unlink' strategy."
>
> You can observe this by running guix-daemon with strace in the
> container, and watching what happens when you try to delete one of the
> offending store items (make sure it is a directory).  For example:
>
> 685   rename("/gnu/store/xib50iqk3w1gw9l770mad59m9bi3bcpc-manual-database", 
> "/gnu/store/trash/xib50iqk3w1gw9l770mad59m9bi3bcpc-manual-database") = -1 
> EXDEV (Invalid cross-device link)
>
> In most cases, when guix-daemon GC's a dead directory, it does this
> (see: nix/libstore/gc.cc):
>
> - Create a trash directory (usually /gnu/store/trash)
> - Move dead directories into the trash directory.
> - Delete the trash directory.
>
> The trash directory is on the "top layer" because it gets created in the
> running container.  However, in practice many store items from lower
> layers are made dead when Stephen's script runs "guix pull" and deletes
> the old profiles.  If any of those store items were directories,
> guix-daemon will fail to GC them because of an XDEV error.  If this is
> confusing to you, I suggest you experiment with Docker a little bit, and
> look closely at the steps that Stephen's script is running.  I outlined
> this in the email I accidentally deleted, but I'm a little too tired to
> reproduce it all a second time.  I hope you'll understand.

Interesting, thanks for the analysis!

> Should Guix do anything about this?  We could change guix-daemon to take
> correct action in the face of an XDEV error.  We could also improve the
> logging, since currently it silently swallows the XDEV error.

I guess we could delete recursively right away upon EXDEV.  It should be
just two lines of code, right?

> To work around the issue, Stephen can build the images from the same
> base image, rather than daisy-chaining new images from old ones.  That
> way, they would not accumulate layers without bound.

Maybe that too.

Thanks,
Ludo’.





bug#41625: Sporadic guix-offload crashes due to EOF errors

2020-06-04 Thread Ludovic Courtès
Hi,

Marius Bakke  skribis:

> Marius Bakke  writes:
>
>> 'guix offload test' passes without problems.
>
> Not so fast, running it in a loop reveals the crash.
>
> There is a trace file in /root/offloadtest.trace on Berlin with such an
> occurence.  It looks like a timeout is reached shortly before the EOF
> error:
>
> 10139 poll([{fd=14, events=POLLIN|POLLOUT}], 1, 0) = 1 ([{fd=14, 
> revents=POLLOUT}])
> 10139 poll([{fd=14, events=POLLIN}], 1, 15000) = 0 (Timeout)
> 10139 write(2, "Backtrace:\n", 11)  = 11
>
> This seems to be from a different node than the one reported previously,
> as the preceding connect() was to this machine:
>
> 10139 connect(44, {sa_family=AF_INET, sin_port=htons(22), 
> sin_addr=inet_addr("141.80.167.186")}, 16) = -1 EINPROGRESS (Operation now in 
> progress)

So it looks like ‘connect’ fails and eventually we get an EOF object.
However, I don’t see where that EOF comes from because the return value
of ‘connect!’ (the Guile-SSH procedure) is properly checked.

Ludo’.





bug#41632: Bug report for Guix 1.1.0

2020-06-04 Thread Ludovic Courtès
Hi,

Jackson Seal  skribis:

> Computing Guix derivation for 'x86_64-linux'... \
> |
>
> -
> -guix pull: error: You found a bug: the program
> '/gnu/store/yxymqs3dj744jgqba7nsaly313v2rmdr-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "9f6efa117cd309cb9b467b96dd2d6bb472df7abb"; system: "x86_64-linux";
> host version: "1.1.0"; pull-version: 1).

Could you check if this was a transient error or if the error still
happens?

Thanks,
Ludo’.





bug#40806: xorg-configuration->file doesn't honor xorg-configuration-server

2020-06-04 Thread Ludovic Courtès
Hi,

Caleb Ristvedt  skribis:

> From e1071c830ce511eecd57617a3f188740fd49d703 Mon Sep 17 00:00:00 2001
> From: Caleb Ristvedt 
> Date: Tue, 2 Jun 2020 06:28:46 -0500
> Subject: [PATCH] xorg: honor xorg-configuration-server in
>  xorg-configuration->file

Please add “Fixes .”

> Previously the xorg-server package specified in the configuration was ignored
> entirely in xorg-configuration->file.  This had the effect that while the X
> program of the configured package would be executed, the modules of the
> configured package would be ignored in favor of the default xorg-server
> package's modules.  This fixes that.
>
> * gnu/services/xorg.scm (xorg-configuration->file): honor
>   xorg-configuration-server.

LGTM, thanks!

Ludo’.





bug#41660: texlive-csquotes source hash mismatch

2020-06-04 Thread Ludovic Courtès
Marius Bakke  skribis:

> This is because it was added (on 'master') after the big TeX Live update
> in 85892948bd9fb5fcc3409a60204cc8b14a4eb030 (on 'core-updates'), thus
> the hash was never adjusted for the new TeX revision.
>
> Fixed in 37465b5be0324d9c953408fe88e2509ad0891712, thanks!

Thank you for the quick fix!

Ludo’.





bug#41661: [Cuirass] Doesn't honor 'timeout' nor 'max-silent-time' leading to mising substitutes

2020-06-04 Thread Ludovic Courtès
Hi,

Leo Famulari  skribis:

> We really need to improve our CI so that it's possible to discover these
> build failures. Currently it's quite hard to monitor if they get built
> unless you just do `guix build foo`.

Or ‘guix weather’, which is not worse than a web UI IMO.

> The last time this came up [0] it was said that maybe it's not really
> correct to make these properties of the package, but rather of the CI
> jobs. It makes sense but we need a solution, or stop supporting
> underpowered architectures like armhf, because most of those machines
> can't build this stuff themselves, and it's not good to advertise
> support to people who will just be disappointed later.

Yeah.  I think we need to look at these on a case-by-case basis.  Guile
is one of those packages known to hit the max-silent-time of 1h (?)
that’s configured on berlin.  Hopefully it will no longer be the case
starting from 3.0.3.

What about Linux-libre?  Does it hit the max absolute build time on
armhf?

As I wrote elsewhere, I think it makes more sense in a way to have
those timeouts configured system-wide.  But yeah, we need to be
pragmatic.

Thanks,
Ludo’.





bug#41237: guix deploy hangs when a file-system-device is set to a UUID

2020-06-04 Thread Brice Waegeneire

On 2020-06-04 11:29, Ludovic Courtès wrote:

Hey,

Brice Waegeneire  skribis:


On 2020-06-04 09:41, Ludovic Courtès wrote:

Brice Waegeneire  skribis:

In ice-9/boot-9.scm:
2806:4  6 (save-module-excursion _)
   4351:12  5 (_)
In unknown file:
4 (find #gnu/build/file-syste…>

…)
In gnu/system/uuid.scm:
 302:5  3 (uuid=? . _)
In unknown file:
While executing meta-command:
In procedure frame-local-ref: Argument 2 out of range: 0


And what does “,locals” show?


There isn't much:

scheme@(guix-user) [1]> ,locals
   Local variables:
   $1 = closure = #continuable?)>


And in upper frames?  (Type “,up”.)


I went trough all the upper frames:

--8<---cut here---start->8---
scheme@(guix-user)> (load 
"/gnu/store/wzvn8r2z7lnf5mqzagxzcb64wr69kgk4-remote-assertion.scm")

^Cice-9/boot-9.scm:1669:16: In procedure raise-exception:
User interrupt

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guix-user) [1]> ,bt
In ice-9/boot-9.scm:
   2806:4  6 (save-module-excursion _)
  4351:12  5 (_)
In unknown file:
   4 (find # …)
In gnu/system/uuid.scm:
302:5  3 (uuid=? . _)
In unknown file:
While executing meta-command:
In procedure frame-local-ref: Argument 2 out of range: 0
scheme@(guix-user) [1]> ,locals
  Local variables:
  $1 = closure = #
scheme@(guix-user) [1]> ,up
In ice-9/top-repl.scm:
37:24  1 (_ _)
scheme@(guix-user) [1]> ,locals
  Local variables:
  $2 = arg = signal
  $3 = arg = #f
  $4 = arg = ()
  $5 = pair = (() (2))
  $6 = pair = ("User interrupt" () (2))
  $7 = pair = (#f "User interrupt" () (2))
scheme@(guix-user) [1]> ,up
While executing meta-command:
In procedure frame-local-ref: Argument 2 out of range: 0
scheme@(guix-user) [1]> ,locals
  No local variables.
scheme@(guix-user) [1]> ,up
In gnu/system/uuid.scm:
302:5  3 (uuid=? . _)
scheme@(guix-user) [1]> ,locals
  Local variables:
  $8 = closure = #
  $9 = w = #vu8(185 176 222 181)
While executing meta-command:
In procedure frame-local-ref: Argument 2 out of range: 3
scheme@(guix-user) [1]> ,up
   4 (find # …)
scheme@(guix-user) [1]> ,locals
  No local variables.
scheme@(guix-user) [1]> ,up
In ice-9/boot-9.scm:
  4351:12  5 (_)
scheme@(guix-user) [1]> ,locals
  No local variables.
scheme@(guix-user) [1]> ,up
In ice-9/boot-9.scm:
   2806:4  6 (save-module-excursion _)
scheme@(guix-user) [1]> ,locals
  Local variables:
  thunk = #
  $10 = obj = #
  $11 = outer-module = #f
  $12 = obj = #
  $13 = box = #
  closure = #
scheme@(guix-user) [1]> ,up
Already at outermost frame.
--8<---cut here---end--->8---

- Brice





bug#40806: xorg-configuration->file doesn't honor xorg-configuration-server

2020-06-04 Thread Caleb Ristvedt
Ludovic Courtès  writes:

> Hi,
>
> Caleb Ristvedt  skribis:
>
>> From e1071c830ce511eecd57617a3f188740fd49d703 Mon Sep 17 00:00:00 2001
>> From: Caleb Ristvedt 
>> Date: Tue, 2 Jun 2020 06:28:46 -0500
>> Subject: [PATCH] xorg: honor xorg-configuration-server in
>>  xorg-configuration->file
>
> Please add “Fixes .”

Done.

>> Previously the xorg-server package specified in the configuration was ignored
>> entirely in xorg-configuration->file.  This had the effect that while the X
>> program of the configured package would be executed, the modules of the
>> configured package would be ignored in favor of the default xorg-server
>> package's modules.  This fixes that.
>>
>> * gnu/services/xorg.scm (xorg-configuration->file): honor
>>   xorg-configuration-server.
>
> LGTM, thanks!

Pushed as 8b158e8b2cd0293eeebe73f5a71f0c513a89d606.

- reepca





bug#40806: done

2020-06-04 Thread Caleb Ristvedt
done





bug#41661: [Cuirass] Doesn't honor 'timeout' nor 'max-silent-time' leading to mising substitutes

2020-06-04 Thread Brice Waegeneire

Hello,

On 2020-06-04 12:16, Ludovic Courtès wrote:

Hi,

Leo Famulari  skribis:

We really need to improve our CI so that it's possible to discover 
these

build failures. Currently it's quite hard to monitor if they get built
unless you just do `guix build foo`.


Or ‘guix weather’, which is not worse than a web UI IMO.


+1 for CLI tools!


The last time this came up [0] it was said that maybe it's not really
correct to make these properties of the package, but rather of the CI
jobs. It makes sense but we need a solution, or stop supporting
underpowered architectures like armhf, because most of those machines
can't build this stuff themselves, and it's not good to advertise
support to people who will just be disappointed later.


Yeah.  I think we need to look at these on a case-by-case basis.  Guile
is one of those packages known to hit the max-silent-time of 1h (?)
that’s configured on berlin.  Hopefully it will no longer be the case
starting from 3.0.3.

What about Linux-libre?  Does it hit the max absolute build time on
armhf?


I misdiagnosed the issue, substitutes for it are available now and 
previous

seems to be there too.  IDK why it wasn't available before nor why I
couldn't manage to built it myself.


As I wrote elsewhere, I think it makes more sense in a way to have
those timeouts configured system-wide.  But yeah, we need to be
pragmatic.

Thanks,
Ludo’.


- Brice





bug#41541: [PATCH 0/9] Merge wip-hurd-vm "last review round"

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
From: Jan Nieuwenhuizen 

Hi!

I've just reset wip-hurd-vm (and already locally fixed one commit message
using a report by jonsger).

This patch set includes all patches that I haven't seen any comments on yet.
"wip-hurd-vm" is currently 23 commits and I believe we're good to go after
this review.

This patch set also includes the already reviewed three ,
 and grub patches that I don't expect/need an explicit
LGTM on (of course I still take remarks/suggestions if you feel the need).

I based the previous version of wip-hurd-vm onto Ludo's qemu-image work,
mainly to see if it would fix the old vm-image, and make sure that it would
not break anything.  While I would still suggest to merge that work, I have
removed it from wip-hurd-vm; the only supported way to build a VM image for
the Hurd is by using the new disk-image.

Thanks,
Janneke

Jan (janneke) Nieuwenhuizen (8):
  system: Add 'hurd' field to .
  bootloader: Extend `' for multiboot.
  system: Add 'multiboot-modules' field to .
  bootloader: grub: Add support for multiboot.
  system: Use 'hurd' package in label.
  system: examples: Add bare-hurd.tmpl.
  services: hurd: Add `hurd-etc-service'.
  system: Add `hurd-activation'.

 Makefile.am|   3 +-
 doc/guix.texi  |  26 ++-
 gnu/bootloader.scm |  49 +++--
 gnu/bootloader/grub.scm|  71 +++
 gnu/build/activation.scm   |   9 +--
 gnu/local.mk   |   1 +
 gnu/services.scm   |  86 +++
 gnu/services/hurd.scm  |  61 +
 gnu/system.scm | 106 +++--
 gnu/system/examples/bare-hurd.tmpl |  24 +++
 gnu/system/hurd.scm|  50 +-
 11 files changed, 394 insertions(+), 92 deletions(-)
 create mode 100644 gnu/services/hurd.scm
 create mode 100644 gnu/system/examples/bare-hurd.tmpl

-- 
2.26.2






bug#41541: [PATCH 8/8] system: Add `hurd-activation'.

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/build/activation.scm (boot-time-system): Add #:kernel-command-line
parameter.
* gnu/build/activation.scm (activate-current-system): Likewise, and pass it.
Change optional system parameter to #:system.
* gnu/system.scm (gnu/linux-activation-script): Rename from activation-script.
(activation-script, hurd-activation-script): New procedure.
---
 gnu/build/activation.scm |  9 +++--
 gnu/services.scm | 81 +++-
 2 files changed, 60 insertions(+), 30 deletions(-)

diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index 30f5e87d5a..85ff8d8996 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -318,13 +318,14 @@ improvement."
   ;; a new system configuration and activate it, without rebooting.
   "/run/current-system")
 
-(define (boot-time-system)
+(define* (boot-time-system #:key (kernel-command-line linux-command-line))
   "Return the '--system' argument passed on the kernel command line."
-  (find-long-option "--system" (linux-command-line)))
+  (find-long-option "--system" (kernel-command-line)))
 
 (define* (activate-current-system
-  #:optional (system (or (getenv "GUIX_NEW_SYSTEM")
- (boot-time-system
+  #:key (kernel-command-line linux-command-line)
+  (system (or (getenv "GUIX_NEW_SYSTEM")
+  (boot-time-system #:kernel-command-line 
kernel-command-line
   "Atomically make SYSTEM the current system."
   ;; The 'GUIX_NEW_SYSTEM' environment variable is used as a way for 'guix
   ;; system reconfigure' to pass the file name of the new system.
diff --git a/gnu/services.scm b/gnu/services.scm
index 614956fbab..78f5d15f06 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -519,35 +519,64 @@ ACTIVATION-SCRIPT-TYPE."
 
 (define (activation-script gexps)
   "Return the system's activation script, which evaluates GEXPS."
+  (program-file "activate.scm" (if (hurd-target?)
+   (hurd-activation-script gexps)
+   (gnu/linux-activation-script gexps
+
+(define (gnu/linux-activation-script gexps)
+  "Return a GNU/Linux system activation script, which evaluates GEXPS."
+
   (define actions
 (map (cut program-file "activate-service.scm" <>) gexps))
 
-  (program-file "activate.scm"
-(with-imported-modules (source-module-closure
-'((gnu build activation)
-  (guix build utils)))
-  #~(begin
-  (use-modules (gnu build activation)
-   (guix build utils))
-
-  ;; Make sure the user accounting database exists.  If it
-  ;; does not exist, 'setutxent' does not create it and
-  ;; thus there is no accounting at all.
-  (close-port (open-file "/var/run/utmpx" "a0"))
-
-  ;; Same for 'wtmp', which is populated by mingetty et
-  ;; al.
-  (mkdir-p "/var/log")
-  (close-port (open-file "/var/log/wtmp" "a0"))
-
-  ;; Set up /run/current-system.  Among other things this
-  ;; sets up locales, which the activation snippets
-  ;; executed below may expect.
-  (activate-current-system)
-
-  ;; Run the services' activation snippets.
-  ;; TODO: Use 'load-compiled'.
-  (for-each primitive-load '#$actions)
+  (with-imported-modules (source-module-closure
+  '((gnu build activation)
+(guix build utils)))
+#~(begin
+(use-modules (gnu build activation)
+ (guix build utils))
+
+;; Make sure the user accounting database exists.  If it
+;; does not exist, 'setutxent' does not create it and
+;; thus there is no accounting at all.
+(close-port (open-file "/var/run/utmpx" "a0"))
+
+;; Same for 'wtmp', which is populated by mingetty et
+;; al.
+(close-port (open-file "/var/log/wtmp" "a0"))
+
+;; Set up /run/current-system.  Among other things this
+;; sets up locales, which the activation snippets
+;; executed below may expect.
+(activate-current-system)
+
+;; Run the services' activation snippets.
+;; TODO: Use 'load-compiled'.
+(for-each primitive-load '#$actions
+
+(define (hurd-activation-script gexps)
+  "Return the Hurd activation script, which evaluates GEXPS."
+  (define actions
+(map (cut program-file "activate-service.scm" <>) gexps))
+
+  (with-imported-modules (source-module-closure
+  '((gnu build activation)
+(guix build utils)))
+#~(begin
+(use-modules (gnu build activation)

bug#41541: [PATCH 4/8] bootloader: grub: Add support for multiboot.

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/bootloader/grub.scm (grub-configuration-file): Add support for
multiboot.
---
 gnu/bootloader.scm  |  3 +-
 gnu/bootloader/grub.scm | 71 +
 2 files changed, 46 insertions(+), 28 deletions(-)

diff --git a/gnu/bootloader.scm b/gnu/bootloader.scm
index 2eebb8e9d9..d0bcab1a06 100644
--- a/gnu/bootloader.scm
+++ b/gnu/bootloader.scm
@@ -26,7 +26,8 @@
   #:use-module (guix ui)
   #:use-module (srfi srfi-1)
   #:use-module (ice-9 match)
-  #:export (menu-entry
+  #:export (
+menu-entry
 menu-entry?
 menu-entry-label
 menu-entry-device
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 2d9a39afc3..3e95fece1c 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -25,12 +25,16 @@
   #:use-module (guix records)
   #:use-module ((guix utils) #:select (%current-system))
   #:use-module (guix gexp)
+  #:use-module (guix utils)
   #:use-module (gnu artwork)
   #:use-module (gnu bootloader)
   #:use-module (gnu system uuid)
   #:use-module (gnu system file-systems)
   #:use-module (gnu system keyboard)
+  #:use-module (gnu packages base)
   #:use-module (gnu packages bootloaders)
+  #:use-module (gnu packages cross-base)
+  #:use-module (gnu packages hurd)
   #:autoload   (gnu packages gtk) (guile-cairo guile-rsvg)
   #:autoload   (gnu packages xorg) (xkeyboard-config)
   #:use-module (ice-9 match)
@@ -330,36 +334,49 @@ when booting a root file system on a Btrfs subvolume."
   (define all-entries
 (append entries (bootloader-configuration-menu-entries config)))
   (define (menu-entry->gexp entry)
-(let* ((device (menu-entry-device entry))
-   (device-mount-point (menu-entry-device-mount-point entry))
-   (label (menu-entry-label entry))
-   (arguments (menu-entry-linux-arguments entry))
-   (kernel (normalize-file (menu-entry-linux entry)
-   device-mount-point
-   store-directory-prefix))
-   (initrd (normalize-file (menu-entry-initrd entry)
-   device-mount-point
-   store-directory-prefix)))
-  ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
-  ;; Use the right file names for KERNEL and INITRD in case
-  ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
-  ;; separate partition.
-  #~(format port "menuentry ~s {
+(match entry
+  (($  label device mount-point linux arguments initrd #f ())
+   (let ((linux (normalize-file linux mount-point
+store-directory-prefix))
+ (initrd (normalize-file initrd mount-point
+ store-directory-prefix)))
+ ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
+ ;; Use the right file names for LINUX and INITRD in case
+ ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
+ ;; separate partition.
+
+ ;; When BTRFS-SUBVOLUME-FILE-NAME is defined, prepend it the linux and
+ ;; initrd paths, to allow booting from a Btrfs subvolume.
+ #~(format port "menuentry ~s {
   ~a
   linux ~a ~a
   initrd ~a
 }~%"
-#$label
-#$(grub-root-search device kernel)
-#$kernel (string-join (list #$@arguments))
-#$initrd)))
-  (define sugar
-(eye-candy config
-   (menu-entry-device (first all-entries))
-   (menu-entry-device-mount-point (first all-entries))
-   #:store-directory-prefix store-directory-prefix
-   #:system system
-   #:port #~port))
+   #$label
+   #$(grub-root-search device linux)
+   #$linux (string-join (list #$@arguments))
+   #$initrd)))
+  (($  label device mount-point #f () #f kernel arguments 
modules)
+   (let* ((target (%current-target-system)))
+ #~(format port "
+menuentry ~s {
+  multiboot ~a root=device:hd0s1~a~a
+}~%"
+   #$label
+   #$kernel (string-join (list #$@arguments) " " 'prefix)
+   (string-join (map string-join '#$modules)
+"\n  module " 'prefix))
+
+  (define (sugar)
+(let* ((entry (first all-entries))
+   (device (menu-entry-device entry))
+   (mount-point (menu-entry-device-mount-point entry)))
+  (eye-candy config
+ device
+ mount-point
+ #:store-directory-prefix store-directory-prefix
+ #:system system
+ #:port #~port)))
 
   (define keyboard-layout-config
 (let* ((layout (bootloader-configuration-keyboard-layout config))
@@ -384,7 +401,7 @@ keymap ~a~%" #$keymap
   "# This file was generated from your Guix configuratio

bug#41541: [PATCH 6/8] system: examples: Add bare-hurd.tmpl.

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
With this, we can now build a VM like so

./pre-inst-env guix system vm-image --target=i586-pc-gnu --no-grafts \
gnu/system/examples/bare-hurd.tmpl

it boots, but needs some more setup/services to be really useful.

See also: ; wip-disk-image.

* gnu/system/hurd.scm (%hurd-default-operating-system): New exported variable.
* gnu/system/examples/bare-hurd.tmpl: New file.
* Makefile.am (EXAMPLES): Add it.
---
 Makefile.am|  3 +-
 gnu/services.scm   |  5 ++-
 gnu/system/examples/bare-hurd.tmpl | 24 ++
 gnu/system/hurd.scm| 50 --
 4 files changed, 78 insertions(+), 4 deletions(-)
 create mode 100644 gnu/system/examples/bare-hurd.tmpl

diff --git a/Makefile.am b/Makefile.am
index 5b64386b53..d8c519b4af 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,7 +7,7 @@
 # Copyright © 2017 Mathieu Othacehe 
 # Copyright © 2017 Leo Famulari 
 # Copyright © 2017 Ricardo Wurmus 
-# Copyright © 2017 Jan Nieuwenhuizen 
+# Copyright © 2017, 2020 Jan (janneke) Nieuwenhuizen 
 # Copyright © 2017 Arun Isaac 
 # Copyright © 2018 Nikita 
 # Copyright © 2018 Julien Lepiller 
@@ -346,6 +346,7 @@ AUX_FILES = \
 EXAMPLES = \
   gnu/system/examples/asus-c201.tmpl   \
   gnu/system/examples/bare-bones.tmpl  \
+  gnu/system/examples/bare-hurd.tmpl   \
   gnu/system/examples/beaglebone-black.tmpl\
   gnu/system/examples/desktop.tmpl \
   gnu/system/examples/lightweight-desktop.tmpl \
diff --git a/gnu/services.scm b/gnu/services.scm
index 2e4648bf78..614956fbab 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015, 2016, 2017, 2018, 2019, 2020 Ludovic Courtès 

 ;;; Copyright © 2016 Chris Marusich 
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -29,10 +30,12 @@
   #:use-module (guix describe)
   #:use-module (guix sets)
   #:use-module (guix ui)
-  #:use-module ((guix utils) #:select (source-properties->location))
+  #:use-module ((guix utils) #:select (source-properties->location
+   %current-target-system))
   #:use-module (guix modules)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bash)
+  #:use-module (gnu packages hurd)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-9)
   #:use-module (srfi srfi-9 gnu)
diff --git a/gnu/system/examples/bare-hurd.tmpl 
b/gnu/system/examples/bare-hurd.tmpl
new file mode 100644
index 00..d100bd6dd8
--- /dev/null
+++ b/gnu/system/examples/bare-hurd.tmpl
@@ -0,0 +1,24 @@
+;; -*-scheme-*-
+
+;; This is an operating system configuration template
+;; for a "bare bones" setup, with no X11 display server.
+
+(use-modules (gnu) (gnu system hurd) (guix utils))
+
+(define %hurd-os
+  (operating-system
+(inherit %hurd-default-operating-system)
+(bootloader (bootloader-configuration
+ (bootloader grub-minimal-bootloader)
+ (target "/dev/sdX")))
+(file-systems (cons (file-system
+  (device (file-system-label "my-root"))
+  (mount-point "/")
+  (type "ext2"))
+%base-file-systems))
+(host-name "guixygnu")
+(timezone "GNUrope")
+(packages %base-packages/hurd)
+(services %base-services/hurd)))
+
+%hurd-os
diff --git a/gnu/system/hurd.scm b/gnu/system/hurd.scm
index 3ccf47aa21..472eca82b9 100644
--- a/gnu/system/hurd.scm
+++ b/gnu/system/hurd.scm
@@ -21,6 +21,7 @@
   #:use-module (guix gexp)
   #:use-module (guix profiles)
   #:use-module (guix utils)
+  #:use-module (gnu bootloader)
   #:use-module (gnu bootloader grub)
   #:use-module (gnu packages admin)
   #:use-module (gnu packages base)
@@ -31,8 +32,17 @@
   #:use-module (gnu packages guile-xyz)
   #:use-module (gnu packages hurd)
   #:use-module (gnu packages less)
+  #:use-module (gnu services)
+  #:use-module (gnu services base)
+  #:use-module (gnu services hurd)
+  #:use-module (gnu services shepherd)
+  #:use-module (gnu system)
+  #:use-module (gnu system shadow)
   #:use-module (gnu system vm)
-  #:export (cross-hurd-image))
+  #:export (cross-hurd-image
+%base-packages/hurd
+%base-services/hurd
+%hurd-default-operating-system))
 
 ;;; Commentary:
 ;;;
@@ -44,7 +54,43 @@
 (define %base-packages/hurd
   (list hurd bash coreutils file findutils grep sed
 guile-3.0 guile-colorized guile-readline
-net-base inetutils less which))
+net-base inetutils less shepherd which))
+
+(define %base-services/hurd
+  '())
+
+(define %hurd-default-operating-system
+  (operating-system
+(kernel gnumach)
+;; (kernel-loadable-modules '())
+(kernel-arguments '())
+(hurd hurd)
+(bootloader

bug#41541: [PATCH 5/8] system: Use 'hurd' package in label.

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/system.scm (kernel->boot-label): Add keyword parameter 'hurd'.  If set,
use it for label.
(operating-system-default-label): Call with it with operating-system-hurd.
---
 gnu/system.scm | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index a96a6e6f2c..b814181c69 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -1098,9 +1098,13 @@ listed in OS.  The C library expects to find it under
   (locale-directory definitions
 #:libcs (operating-system-locale-libcs os)))
 
-(define (kernel->boot-label kernel)
+(define* (kernel->boot-label kernel #:key hurd)
   "Return a label for the bootloader menu entry that boots KERNEL."
-  (cond ((package? kernel)
+  (cond ((package? hurd)
+ (string-append "GNU with the "
+(string-titlecase (package-name hurd)) " "
+(package-version hurd)))
+((package? kernel)
  (string-append "GNU with "
 (string-titlecase (package-name kernel)) " "
 (package-version kernel)))
@@ -1113,7 +1117,8 @@ listed in OS.  The C library expects to find it under
 (define (operating-system-default-label os)
   "Return the default label for OS, as it will appear in the bootloader menu
 entry."
-  (kernel->boot-label (operating-system-kernel os)))
+  (kernel->boot-label (operating-system-kernel os)
+  #:hurd (operating-system-hurd os)))
 
 (define (store-file-system file-systems)
   "Return the file system object among FILE-SYSTEMS that contains the store."
-- 
2.26.2






bug#41541: [PATCH 2/8] bootloader: Extend `' for multiboot.

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/bootloader.scm ()[multiboot-kernel,multiboot-arguments,
multiboot-modules]: New fields.
[linux,initrd]: Add default value '#f'.
(menu-entry->sexp, sexp->menu-entry): Support multiboot entry.
---
 gnu/bootloader.scm | 46 +-
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/gnu/bootloader.scm b/gnu/bootloader.scm
index 668caa7fc3..2eebb8e9d9 100644
--- a/gnu/bootloader.scm
+++ b/gnu/bootloader.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2017, 2020 Mathieu Othacehe 
 ;;; Copyright © 2017 Leo Famulari 
 ;;; Copyright © 2019 Ludovic Courtès 
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -33,6 +34,9 @@
 menu-entry-linux-arguments
 menu-entry-initrd
 menu-entry-device-mount-point
+menu-entry-multiboot-kernel
+menu-entry-multiboot-arguments
+menu-entry-multiboot-modules
 
 menu-entry->sexp
 sexp->menu-entry
@@ -77,22 +81,41 @@
(default #f))
   (device-mount-point menu-entry-device-mount-point
(default #f))
-  (linux   menu-entry-linux)
+  (linux   menu-entry-linux
+   (default #f))
   (linux-arguments menu-entry-linux-arguments
(default '()))  ; list of string-valued gexps
-  (initrd  menu-entry-initrd)) ; file name of the initrd as a gexp
+  (initrd  menu-entry-initrd   ; file name of the initrd as a gexp
+   (default #f))
+  (multiboot-kernel menu-entry-multiboot-kernel
+(default #f))
+  (multiboot-arguments menu-entry-multiboot-arguments
+   (default '()))  ; list of string-valued gexps
+  (multiboot-modules menu-entry-multiboot-modules
+ (default '(   ; list of multiboot commands, where
+   ; a command is a list of 
 
 (define (menu-entry->sexp entry)
   "Return ENTRY serialized as an sexp."
   (match entry
-(($  label device mount-point linux linux-arguments initrd)
+(($  label device mount-point linux linux-arguments initrd #f
+ ())
  `(menu-entry (version 0)
   (label ,label)
   (device ,device)
   (device-mount-point ,mount-point)
   (linux ,linux)
   (linux-arguments ,linux-arguments)
-  (initrd ,initrd)
+  (initrd ,initrd)))
+(($  label device mount-point #f () #f
+ multiboot-kernel multiboot-arguments multiboot-modules)
+ `(menu-entry (version 0)
+  (label ,label)
+  (device ,device)
+  (device-mount-point ,mount-point)
+  (multiboot-kernel ,multiboot-kernel)
+  (multiboot-arguments ,multiboot-arguments)
+  (multiboot-modules ,multiboot-modules)
 
 (define (sexp->menu-entry sexp)
   "Turn SEXP, an sexp as returned by 'menu-entry->sexp', into a 
@@ -109,7 +132,20 @@ record."
   (device-mount-point mount-point)
   (linux linux)
   (linux-arguments linux-arguments)
-  (initrd initrd)
+  (initrd initrd)))
+(('menu-entry ('version 0)
+  ('label label) ('device device)
+  ('device-mount-point mount-point)
+  ('multiboot-kernel multiboot-kernel)
+  ('multiboot-arguments multiboot-arguments)
+  ('multiboot-modules multiboot-modules) _ ...)
+ (menu-entry
+  (label label)
+  (device device)
+  (device-mount-point mount-point)
+  (multiboot-kernel multiboot-kernel)
+  (multiboot-arguments multiboot-arguments)
+  (multiboot-modules multiboot-modules)
 
 
 ;;;
-- 
2.26.2






bug#41541: [PATCH 7/8] services: hurd: Add `hurd-etc-service'.

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/services/hurd.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
* doc/guix.texi (Hurd Services): Document it.
---
 doc/guix.texi | 13 +
 gnu/local.mk  |  1 +
 gnu/services/hurd.scm | 61 +++
 3 files changed, 75 insertions(+)
 create mode 100644 gnu/services/hurd.scm

diff --git a/doc/guix.texi b/doc/guix.texi
index 4776eacacd..97bf067074 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -319,7 +319,9 @@ Services
 * Version Control Services::Providing remote access to Git repositories.
 * Game Services::   Game servers.
 * PAM Mount Service::   Service to mount volumes when logging in.
+* Guix Services::   Services relating specifically to Guix.
 * Linux Services::  Services tied to the Linux kernel.
+* Hurd Services::   Services specific to a Hurd System.
 * Miscellaneous Services::  Other services.
 
 Defining Services
@@ -12594,6 +12596,7 @@ declaration.
 * PAM Mount Service::   Service to mount volumes when logging in.
 * Guix Services::   Services relating specifically to Guix.
 * Linux Services::  Services tied to the Linux kernel.
+* Hurd Services::   Services specific for a Hurd System.
 * Miscellaneous Services::  Other services.
 @end menu
 
@@ -26032,6 +26035,16 @@ parameters, can be done as follow:
 @end lisp
 @end deffn
 
+@node Hurd Services
+@subsection Hurd Services
+
+@deffn {Scheme Procedure} hurd-etc-service @var{os}
+This service implements a minimal @code{etc-service}, adding some
+specifics for the Hurd.
+
+It is part of the @code{hurd-default-essential-services}.
+@end deffn
+
 @node Miscellaneous Services
 @subsection Miscellaneous Services
 
diff --git a/gnu/local.mk b/gnu/local.mk
index 8abca8659e..d1d086abe0 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -582,6 +582,7 @@ GNU_SYSTEM_MODULES =\
   %D%/services/games.scm   \
   %D%/services/getmail.scm \
   %D%/services/guix.scm\
+  %D%/services/hurd.scm\
   %D%/services/kerberos.scm\
   %D%/services/linux.scm   \
   %D%/services/lirc.scm\
diff --git a/gnu/services/hurd.scm b/gnu/services/hurd.scm
new file mode 100644
index 00..6e57b22810
--- /dev/null
+++ b/gnu/services/hurd.scm
@@ -0,0 +1,61 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu services hurd)
+  #:use-module (gnu packages admin)
+  #:use-module (gnu services)
+  #:use-module (gnu system)
+  #:use-module (guix gexp)
+  #:use-module (guix records)
+  #:export (hurd-etc-service))
+
+;;; Commentary:
+;;;
+;;; This module implements services for the Hurd.
+;;;
+;;; Code:
+
+
+;;;
+;;; The ETC service for the Hurd.
+;;;
+
+(define (hurd-etc-service os)
+  "Return a  that builds containing the static part of the /etc
+directory."
+  (let ((profile (mixed-text-file "profile"  "\
+# Generated by hurd-etc-services
+export PS1='\\u@\\h\\$ '
+
+GUIX_PROFILE=\"/run/current-system/profile\"
+. \"$GUIX_PROFILE/etc/profile\"
+
+GUIX_PROFILE=\"$HOME/.guix-profile\"
+if [ -f \"$GUIX_PROFILE/etc/profile\" ]; then
+  . \"$GUIX_PROFILE/etc/profile\"
+fi\n"))
+(hurd (operating-system-hurd os)))
+(etc-service
+ `(("services" ,(file-append net-base "/etc/services"))
+   ("protocols" ,(file-append net-base "/etc/protocols"))
+   ("profile" ,profile)
+   ("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
+   ("login" ,(file-append hurd "/etc/login"))
+   ("motd" ,(file-append hurd "/etc/motd"))
+
+;;; hurd.scm ends here
-- 
2.26.2






bug#41541: [PATCH 3/8] system: Add 'multiboot-modules' field to .

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/system.scm ()[multiboot-modules]: New field.
(read-boot-parameters): Initialize it.
(operating-system-multiboot-modules, hurd-multiboot-modules): New procedure.
(operating-system-boot-parameters): Cater for multiboot the Hurd and
initialize it; avoid initrd in that case.
(operating-system-kernel-file): Cater for for Gnumach (the Hurd) besides Linux.
(boot-parameters->menu-entry): Use it to support a multiboot .
---
 gnu/system.scm | 92 +++---
 1 file changed, 73 insertions(+), 19 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 43dd2ec598..a96a6e6f2c 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -39,9 +39,11 @@
   #:use-module (guix utils)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bash)
+  #:use-module (gnu packages cross-base)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages guile-xyz)
   #:use-module (gnu packages admin)
+  #:use-module (gnu packages hurd)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages pciutils)
   #:use-module (gnu packages package-management)
@@ -142,6 +144,7 @@
 boot-parameters-kernel
 boot-parameters-kernel-arguments
 boot-parameters-initrd
+boot-parameters-multiboot-modules
 read-boot-parameters
 read-boot-parameters-file
 boot-parameters->menu-entry
@@ -283,7 +286,8 @@ directly by the user."
   (store-mount-point boot-parameters-store-mount-point)
   (kernel   boot-parameters-kernel)
   (kernel-arguments boot-parameters-kernel-arguments)
-  (initrd   boot-parameters-initrd))
+  (initrd   boot-parameters-initrd)
+  (multiboot-modules boot-parameters-multiboot-modules))
 
 (define (ensure-not-/dev device)
   "If DEVICE starts with a slash, return #f.  This is meant to filter out
@@ -314,7 +318,7 @@ file system labels."
   (match (read port)
 (('boot-parameters ('version 0)
('label label) ('root-device root)
-   ('kernel linux)
+   ('kernel kernel)
rest ...)
  (boot-parameters
   (label label)
@@ -330,12 +334,12 @@ file system labels."
  ((_ entries) (map sexp->menu-entry entries))
  (#f  '(
 
-  ;; In the past, we would store the directory name of the kernel instead
-  ;; of the absolute file name of its image.  Detect that and correct it.
-  (kernel (if (string=? linux (direct-store-path linux))
-  (string-append linux "/"
+  ;; In the past, we would store the directory name of linux instead of
+  ;; the absolute file name of its image.  Detect that and correct it.
+  (kernel (if (string=? kernel (direct-store-path kernel))
+  (string-append kernel "/"
  (system-linux-image-file-name))
-  linux))
+  kernel))
 
   (kernel-arguments
(match (assq 'kernel-arguments rest)
@@ -349,6 +353,8 @@ file system labels."
  (('initrd (? string? file))
   file)))
 
+  (multiboot-modules (or (assq 'multiboot-modules rest) '()))
+
   (store-device
;; Linux device names like "/dev/sda1" are not suitable GRUB device
;; identifiers, so we just filter them out.
@@ -386,14 +392,25 @@ The object has its kernel-arguments extended in order to 
make it bootable."
(boot-parameters-kernel-arguments params))
 
 (define (boot-parameters->menu-entry conf)
-  (menu-entry
-   (label (boot-parameters-label conf))
-   (device (boot-parameters-store-device conf))
-   (device-mount-point (boot-parameters-store-mount-point conf))
-   (linux (boot-parameters-kernel conf))
-   (linux-arguments (boot-parameters-kernel-arguments conf))
-   (initrd (boot-parameters-initrd conf
-
+  (let* ((kernel (boot-parameters-kernel conf))
+ (multiboot-modules (boot-parameters-multiboot-modules conf))
+ (multiboot? (pair? multiboot-modules)))
+(menu-entry
+ (label (boot-parameters-label conf))
+ (device (boot-parameters-store-device conf))
+ (device-mount-point (boot-parameters-store-mount-point conf))
+ (linux (and (not multiboot?) kernel))
+ (linux-arguments (if (not multiboot?) '
+  (boot-parameters-kernel-arguments conf)
+  '()))
+ (initrd (boot-parameters-initrd conf))
+ (multiboot-kernel (and multiboot? kernel))
+ (multiboot-arguments (if multiboot?
+  (boot-parameters-kernel-arguments conf)
+  '()))
+ (multiboot-modules (if multiboot?
+(boot-parameters-multiboot-modules conf)
+'())
 
 
 ;;;
@@ -485,8 +502,17 @@ from the initrd."
 (define (operating-system-kernel-file os)
   "Return an object representing the absolute file name of the kernel ima

bug#41541: [PATCH 1/8] system: Add 'hurd' field to .

2020-06-04 Thread Jan (janneke) Nieuwenhuizen
* gnu/system.scm ()[hurd]: New field.
* doc/guix.texi (operating-system Reference): Document 'hurd'.
---
 doc/guix.texi  | 13 ++---
 gnu/system.scm |  3 +++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 056bf011f6..4776eacacd 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -11484,9 +11484,16 @@ configuration (@pxref{Using the Configuration System}).
 
 @table @asis
 @item @code{kernel} (default: @code{linux-libre})
-The package object of the operating system kernel to use@footnote{Currently
-only the Linux-libre kernel is supported.  In the future, it will be
-possible to use the GNU@tie{}Hurd.}.
+The package object of the operating system kernel to
+use@footnote{Currently only the Linux-libre kernel is fully supported.
+Using GNU@tie{}mach in combination with a @code{hurd} is experimental
+and only available when building a vm-image.}.
+
+@cindex hurd
+@item @code{hurd} (default: @code{#f})
+The hurd to be started by the kernel.  This is required to build an
+experimental vm-image for the Hurd and requires using @code{kernel}
+GNU@tie{}mach as well as other specific operating system overrides.
 
 @item @code{kernel-loadable-modules} (default: '())
 A list of objects (usually packages) to collect loadable kernel modules
diff --git a/gnu/system.scm b/gnu/system.scm
index 213452a6f9..43dd2ec598 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -83,6 +83,7 @@
 operating-system-packages
 operating-system-host-name
 operating-system-hosts-file
+operating-system-hurd
 operating-system-kernel
 operating-system-kernel-file
 operating-system-kernel-arguments
@@ -187,6 +188,8 @@
 (default '())); list of packages
   (kernel-arguments operating-system-user-kernel-arguments
 (default %default-kernel-arguments)) ; list of 
gexps/strings
+  (hurd operating-system-hurd
+(default #f)) ; package
   (bootloader operating-system-bootloader); 
   (label operating-system-label   ; string
  (thunked)
-- 
2.26.2






bug#41651: [PATCH v2] gnu: network-manager-applet: Propagate 'libnma'.

2020-06-04 Thread Efraim Flashner
Thanks! Patch pushed.


-- 
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#41604: guix pull impossible after rebasing a local repository

2020-06-04 Thread John Soo
Hi Ludo,

Ludovic Courtès  writes:

> It supports unrelated Git histories.  It could really be called
> ‘--allow-anything’ but I thought it’d be less descriptive.  :-)
>
> If you hit a problem with that, please report it (perhaps I just
> overlooked it in the other issue.)

Oh nice, then this whole issue I think should be to report that
--allow-downgrades does not allow everything.  When I first reported the
issue I tried --allow-downgrades thanks to some help on IRC.  The first
attempt failed as I mentioned previously in the thread.  However I did
just try --allow-downgrades again after a rebase and it seems to have
succeeded.  With that, I think this issue can be closed.  Thanks for
thinking of this case!

> Interesting, I hadn’t thought about how this mechanism would give an
> incentive to have a channel vs. contributing directly upstream.

I think I will add some notes about a rebase workflow and
--allow-downgrades to the contributing documentation. Looking just now
I'm not sure using a local source tree as a channel is mentioned in the
documentation either. I will open a different patch set to deal with
those issues.

> Normally, ‘--allow-downgrades’ does exactly what you need, at least
> that’s the intent.  I’d argue that it’s also reasonable to use it in
> this case because obviously you know what you’re doing, and you’re
> pulling from a local Git repository, so that’s fine.

100% it does what I need.

Thanks again, feel free to close.

- John





bug#41708: "guix weather" : 504 error

2020-06-04 Thread zimoun
Dear,

By default, "guix weather" returns:

--8<---cut here---start->8---
'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---cut here---end--->8---

which is not fatal but annoying.  Especially, it takes time.

As discussed on IRC [1], it seems that it is a bug server side.

In addition, something appears similar with Bayfront, well the 4
substitutes servers that I know returns:

--8<---cut here---start->8---
'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
'https://bayfront.guix.gnu.org/api/queue?nr=1000' returned 504
("Gateway Time-out")
(continuous integration information unavailable)
'https://guix.tobias.gr/api/queue?nr=1000' returned 410 ("Gone")
--8<---cut here---end--->8---


All the best,
simon

[1] http://logs.guix.gnu.org/guix/2020-06-03.log#201511





bug#41709: installed-os test failing

2020-06-04 Thread Mathieu Othacehe


Hello

The installed-os test is failing because the image closure is (again)
bigger than the allocated 1.4GiB in the test partition.

--8<---cut here---start->8---
guix size $(./pre-inst-env guix system build 
gnu/system/examples/bare-bones.tmpl)
--8<---cut here---end--->8---

reports 1397.3 MiB.

By reverting this commit 0eed77127592323d89f56c215a15374a1aaae110
(introducing an extra glibc to %default-locale-libcs), it drops down to:

1305.5 MiB.

Now multiple options:

* Revert this commit.
* Find other system closure improvements.
* Up the limit to 1.5GiB.

WDYT?

Thanks,

Mathieu





bug#41710: Possibly found a bug while doing a "guix pull"

2020-06-04 Thread Léon Lain Delysid
Hello!
I just tried to "guix pull" on my Debian Buster GNU/Linux system. Twice it
made the system completely freeze for a few seconds and then reboot. And
that third time it didn't crash the system but the guix pull failed and
returned this error:
https://pastebin.com/vhDR8gDC

Can somebody help me please?

(Before doing the third "pull", I did an "apt update" and "upgrade", but I
wasn't that much behind in updates, I had done it less than a week ago
last. My last "guix pull" was made at the same time as the "apt update", a
few days ago.)

Hoping I can resolve this soon or that my feedback was positive for the
development of Guix. =)
I can provide log debug info (if there is any) upon request.

Best regards!


bug#41710: Possibly found a bug while doing a "guix pull"

2020-06-04 Thread Julien Lepiller
Le 4 juin 2020 10:38:09 GMT-04:00, "Léon Lain Delysid" 
 a écrit :
>Hello!
>I just tried to "guix pull" on my Debian Buster GNU/Linux system. Twice
>it
>made the system completely freeze for a few seconds and then reboot.
>And
>that third time it didn't crash the system but the guix pull failed and
>returned this error:
>https://pastebin.com/vhDR8gDC
>
>Can somebody help me please?
>
>(Before doing the third "pull", I did an "apt update" and "upgrade",
>but I
>wasn't that much behind in updates, I had done it less than a week ago
>last. My last "guix pull" was made at the same time as the "apt
>update", a
>few days ago.)
>
>Hoping I can resolve this soon or that my feedback was positive for the
>development of Guix. =)
>I can provide log debug info (if there is any) upon request.
>
>Best regards!

Sorry pastebin is not tor friendly, I couldn't look at it.

For the freezing part, could it be that you have relatively low free ram (<2GB) 
and no swap? Or maybe /tmp is mounted as a tmpfs and for some reason it takes a 
lot of space?

You might need to use substitutes when runnning guix pull. I don't have that 
much ram either on some computers, so I always take a look at 
https://ci.guix.gnu.org/jobset/guix-modular-master and choose the latest commit 
that was built for my architeeture. Then eg. guix pull --commit=c987b72

This will allow guix to download substitutes for guix pull instead of building 
locally, which doesn't require any ram usage.

HTH!





bug#41709: installed-os test failing

2020-06-04 Thread Mathieu Othacehe


> Now multiple options:
>
> * Revert this commit.
> * Find other system closure improvements.
> * Up the limit to 1.5GiB.
>
> WDYT?

Digging a bit more, I discovered multiple culprits in the image closure
size.

* "openssh" is dragging "xauth" which drags some X libraries (but this
does not account for much).

* "sudo" is dragging "python" for about 100MiB.

* "info-reader" is dragging "perl" (and is in fact the same size as
"texinfo" because of a mistake that I introduced with
614a1e3fa2d731d4719f03912b1b87fb4fd309cb) for about 100MiB.

* The switch to non-canonical version of "glibc" and "coreutils" to fix
system cross-compilation in dfc8ccbf5da96a67eb1cade499f0def21e7fdb02 is
also responsible for about 100MiB.

All in all, fixing all of this makes the closure size to drop below 1GiB
which is already a good first step.

I'll try to provide patches soon.

Thanks,

Mathieu






bug#41713: Package referenced with ‘ungexp-native’ gets cross-compiled

2020-06-04 Thread Ludovic Courtès
As reported by Mathieu in :

--8<---cut here---start->8---
$ cat ~/src/guix-debugging/graft-cross-compilation.scm
(use-modules (gnu) (guix)
 (gnu packages gtk))

(with-store store
  (run-with-store store
(mlet* %store-monad ((target (set-current-target "aarch64-linux-gnu"))
 (drv (lower-object
   (computed-file "test"
  #~(begin
  (mkdir #$output)
  #+guile-rsvg)
  (return (derivation->output-path drv)
$ ./pre-inst-env guile ~/src/guix-debugging/graft-cross-compilation.scm
Backtrace:
In guix/gexp.scm:
   243:18 19 (_ _)
   1061:2 18 (_ _)
921:2 17 (_ _)
782:4 16 (_ _)
In guix/store.scm:
  1899:12 15 (_ #)
   1336:2 14 (map/accumulate-builds # _ _)
In srfi/srfi-1.scm:
   586:17 13 (map1 ((# "out")))
In guix/store.scm:
   1295:8 12 (call-with-build-handler # _)
  2017:24 11 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
In guix/gexp.scm:
   785:13 10 (_ _)
In guix/store.scm:
   1851:8  9 (_ _)
In guix/gexp.scm:
   243:18  8 (_ _)
In guix/store.scm:
  1886:38  7 (_ #)
In guix/packages.scm:
  1072:16  6 (package-derivation _ # _ #:graft? _)
  1393:16  5 (thunk)
   1280:6  4 (bag-grafts # #< name: 
"guile-rsvg-2.18.1-0.05c6a2f" system: "x86_64-linux" target: #f build-inputs: 
(("source" #https://gitlab.com…>)
  1260:45  3 (fold-bag-dependencies # _ _ #:native? _)
  1072:16  2 (package->bag _ _ _ #:graft? _)
  1183:21  1 (thunk)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
ERROR:
  1. &package-cross-build-system-error: #
--8<---cut here---end--->8---

This is on 4960a955f8f77cc4c35d0db749cd6f3de8787bff-ish.

Ludo’.





bug#41714: Some Flatpak applications fail to start when attempting to run xdg-dbus-proxy

2020-06-04 Thread Jonathan Frederickson
I have a few applications that I've installed through Flatpak on Guix 
System which used to work, but recently I've been unable to run them. 
Trying to run them results in:


jfred@lambdacrypt ~$ flatpak run im.riot.Riot
bwrap: execvp xdg-dbus-proxy: No such file or directory
jfred@lambdacrypt ~$ flatpak run org.signal.Signal
bwrap: execvp xdg-dbus-proxy: No such file or directory

This is my current Guix revision, and I've just run `guix system 
reconfigure` and updated my user packages:


jfred@lambdacrypt ~$ guix describe
Generation 25   Jun 03 2020 23:43:30(current)
 guix 4c8700f
   repository URL: https://git.savannah.gnu.org/git/guix.git
   branch: master
   commit: 4c8700fd844d24f52c54966467765f14dca6510c

My current system config can be found here: 
https://raw.githubusercontent.com/jfrederickson/dotfiles/6d2724116a420b13adcf8c63afa7e5f197969669/guix/guix/system.scm








bug#41714: Some Flatpak applications fail to start when attempting to run xdg-dbus-proxy

2020-06-04 Thread ArneBab
Hi Jonathan,

Jonathan Frederickson  writes:

> I have a few applications that I've installed through Flatpak on Guix
> System which used to work, but recently I've been unable to run them.
> Trying to run them results in:
>
> jfred@lambdacrypt ~$ flatpak run im.riot.Riot
> bwrap: execvp xdg-dbus-proxy: No such file or directory

I had the same problem. I fixed it with
guix install xdg-dbus-proxy.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken





bug#39584: evolution: involid page id error when composing emails

2020-06-04 Thread Christopher Howard
I have been using evolution heavily for about two days and have not
seen the error appear again. I used to see it about 10 times a day.

-- 
Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com


bug#41710: Possibly found a bug while doing a "guix pull"

2020-06-04 Thread zimoun
Dear,

On Thu, 4 Jun 2020 at 17:42, Julien Lepiller  wrote:
> Le 4 juin 2020 10:38:09 GMT-04:00, "Léon Lain Delysid" 
>  a écrit :

> >I just tried to "guix pull" on my Debian Buster GNU/Linux system. Twice
> >it
> >made the system completely freeze for a few seconds and then reboot.

What do you mean by "then reboot"?
Does it reboot by itself or do you manually force the reboot?

> >And
> >that third time it didn't crash the system but the guix pull failed and
> >returned this error:
> >https://pastebin.com/vhDR8gDC

How do you start guix-daemon?


> >(Before doing the third "pull", I did an "apt update" and "upgrade",
> >but I
> >wasn't that much behind in updates, I had done it less than a week ago
> >last. My last "guix pull" was made at the same time as the "apt
> >update", a
> >few days ago.)

What is your "guix describe"?

>
> >Hoping I can resolve this soon or that my feedback was positive for the
> >development of Guix. =)
> >I can provide log debug info (if there is any) upon request.
> >
> >Best regards!
>
> Sorry pastebin is not tor friendly, I couldn't look at it.

Julien, here the paste:

--8<---cut here---start->8---
./guix/store.scm:1035:9: ERROR:
  1. &store-protocol-error:
  message: "error parsing derivation
`/gnu/store/m5djg8zwgl7nh0rm1av4nnlbwgwi0fwg-guix-daemon-1.1.0-4.bdc801e.drv':
expected string `Derive(['"
  status: 1
guix pull: error: You found a bug: the program
'/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"415b90f24ee83059102f5fb0ce74a2bc0954fe58"; system: "x86_64-linux";
host version: "018cffc9c9e5a5855733f5f45a1c4d396bb6a321"; pull-version: 1).
Please report it by email to .
--8<---cut here---end--->8---

First time, I see that.

All the best,
simon





bug#41607: Deleted store items are not actually deleted

2020-06-04 Thread Chris Marusich
Ludovic Courtès  writes:

>> Should Guix do anything about this?  We could change guix-daemon to take
>> correct action in the face of an XDEV error.  We could also improve the
>> logging, since currently it silently swallows the XDEV error.
>
> I guess we could delete recursively right away upon EXDEV.  It should be
> just two lines of code, right?

I'll try making the change and report back.  Yes, there are other cases
where we immediately delete without moving into the trash directory
(e.g., when the trash directory fails to be created), so it seems OK.

-- 
Chris


signature.asc
Description: PGP signature


bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix

2020-06-04 Thread o . rojon

Hello everyone,

on a freshly installed and reconfigured machine, I receive the following 
error:
# guix pull: error: You found a bug: the program 
'/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
# failed to compute the derivation for Guix (version: 
"790ada9168e0689c1c4607c61cdc1d2dbc327abf"; system: "x86_64-linux";
# host version: "398ec3c1e265a3f89ed07987f33b264db82e4080"; 
pull-version: 1).


I'm not entirely sure if, in this case, it is about RAM, as has been 
mentioned in this thread: https://issues.guix.gnu.org/41710 . I do have 
24gb ram, but currently a small swap file, but that might be totally 
unrelated.


If I can supply you with more information, please do not hesitate to 
specify how I can aid fixing the issue.


Have a good day,
Olivier





bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix

2020-06-04 Thread Ludovic Courtès
Hello,

o.ro...@posteo.net skribis:

> on a freshly installed and reconfigured machine, I receive the
> following error:
> # guix pull: error: You found a bug: the program
> '/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
> # failed to compute the derivation for Guix (version:
> "790ada9168e0689c1c4607c61cdc1d2dbc327abf"; system: "x86_64-linux";
> # host version: "398ec3c1e265a3f89ed07987f33b264db82e4080";
> pull-version: 1).

Is there more info above these lines?

I tried to reproduce it with:

  guix time-machine --commit=398ec3c1e265a3f89ed07987f33b264db82e4080 \
-- time-machine --commit=790ada9168e0689c1c4607c61cdc1d2dbc327abf \
-- describe

but it works for me.

> I'm not entirely sure if, in this case, it is about RAM, as has been
> mentioned in this thread: https://issues.guix.gnu.org/41710 . I do
> have 24gb ram, but currently a small swap file, but that might be
> totally unrelated.

24 GiB is more than enough.

Is the problem reproducible if you try again now?

Thanks for reporting the issue,
Ludo’.





bug#41693: freshly installed system cannot run “guix pull”

2020-06-04 Thread Marius Bakke
Ricardo Wurmus  writes:

> Mathieu Othacehe  writes:
>
>>> I just installed two servers with the installer image built from commit
>>> 2f49007dd076b14feb40d7c3331dee3e737265c8.  Both of these servers boot
>>> just fine, but “guix pull” does not work.
>>>
>>> It fails with the following error:
>>>
>>>   guix pull: error: glibc-bootstrap-system-2.2.5.patch: patch not found
>>
>> The commit you picked should create an installer with a Guix package
>> that contains the appropriate fix:
>> 179e6c524ae4957e6ace83f72a5651767f786ca4.
>>
>> Could you run a "guix describe" just to be sure?
>
> “guix describe” tells me that my Guix was not created with “guix
> pull” but says:
>
> Its version string is 1.1.0-3.52b01cb.

The problem here is that when you create an installer, the Guix inside
the image is the one defined in gnu/packages/package-management.scm
(currently 1.1.0-4.bdc801e).  Which works fine.

But when you install a system using that Guix, it will install an
_older_ Guix snapshot, from its embedded
gnu/packages/package-management.scm, which is the broken
1.1.0-3.52b01cb.

Probably we should make a new Guix snapshot to work around it.  It's a
fairly safe and easy operation, just run 'make update-guix-package' on a
commit that is available on Savannah.  Can you try it?  :-)


signature.asc
Description: PGP signature


bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix

2020-06-04 Thread Jakub Kądziołka
Hi,

I encountered a similar error message today, but it worked fine after
retrying. After digging around in /var/log/guix/drvs, I found these
lines in an appropriately-timestamped log file:

substitute: guix substitute: warning: ci.guix.gnu.org: connection failed: 
Connection timed out
@ build-started 
/gnu/store/klyq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv - 
x86_64-linux 
/var/log/guix/drvs/kl//yq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv.bz2
 3907994
@ build-succeeded 
/gnu/store/klyq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv -

I do recall seeing the Connection timed out message, I'd even say it's
probably the reason why I decided to retry the pull without much
investigation.

Regards,
Jakub Kądziołka


signature.asc
Description: PGP signature


bug#41693: freshly installed system cannot run “guix_ pull”

2020-06-04 Thread Kozo via web
I am getting the same issue with an .iso made with 1.1.0-4.bdc801e.






bug#41693: freshly installed system cannot run “guix_ pull”

2020-06-04 Thread Kozo via web
When I boot to my usb key, gnu grub comes up with gnu guix installation 
1.1.0-4.bdc801e. I'm assuming it's trying to install that version?






bug#41714: Some Flatpak applications fail to start when attempting to run xdg-dbus-proxy

2020-06-04 Thread Jonathan Frederickson




On Thu, Jun 4, 2020 at 7:36 pm, ArneBab  wrote:

Hi Jonathan,

Jonathan Frederickson  writes:

 I have a few applications that I've installed through Flatpak on 
Guix
 System which used to work, but recently I've been unable to run 
them.

 Trying to run them results in:

 jfred@lambdacrypt ~$ flatpak run im.riot.Riot
 bwrap: execvp xdg-dbus-proxy: No such file or directory


I had the same problem. I fixed it with
guix install xdg-dbus-proxy.



Oh interesting, you're right! I would've expected this to be a hard 
dependency of flatpak though, if flatpak apps require it.


Thanks for the tip though!








bug#41604: guix pull impossible after rebasing a local repository

2020-06-04 Thread zimoun
Hi Ludo,

On Wed, 3 Jun 2020 at 17:14, Ludovic Courtès  wrote:

> >> (This can be overridden this by passing ‘--allow-downgrades’.)
> >
> > Does '--allow-downgrades' support unrelated git histories?  I tried that
> > flag and it did not work.
>
> It supports unrelated Git histories.  It could really be called
> ‘--allow-anything’ but I thought it’d be less descriptive.  :-)
>
> If you hit a problem with that, please report it (perhaps I just
> overlooked it in the other issue.)

I think it is not a bug and it is a feature* :-) but the behaviour has
changed for the commits which do not belong to the repo anymore.
That's why John has not seen the issue of his "rebase workflow"
before.

*feature: at least, it seems expected from what I understand of the code. :-)


Let remind the commit history.  Instead of create a channel file, I
directly use the raw repo, but it is the same for any channel (Git
repo).

--8<---cut here---start->8---
$ 
SRC=~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
$ git -C $SRC --no-pager log --oneline c873980d18^..8bd0b533b3
8bd0b533b3 gnu: libexif: Update to 0.6.22 [security fixes].
e451612602 gnu: libgphoto2: Update to 2.5.25.
9744cc7b46 pull: Protect against downgrade attacks.
872898f768 channels: 'latest-channel-instances' guards against
non-forward updates.
8d1d56578a git: 'update-cached-checkout' returns the commit relation.
9b049de84e channels: 'latest-channel-instances' doesn't leak internal state.
c098c11be8 git: Add 'commit-relation'.
86ac14b2f3 (HEAD -> master) gnu: protonvpn-cli: Tweak description.
c873980d18 gnu: Add protonvpn-cli.
--8<---cut here---end--->8---


Here, a first session from a commit before the "downgrade attacks"
commit.  A commit is added, then pulled, then rebased where this
addition is totally deleted of the Git repo, then another pulled.  No
error at all.

--8<---cut here---start->8---
$ guix describe
Generation 34Jun 05 2020 02:16:22(current)
  guix 86ac14b
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 86ac14b2f37efbb6f4a3ed1c3e183fbc9496b7a5

$ echo hello >> $SRC/README && git -C $SRC commit -am hello
[master 20e984e931] hello
 1 file changed, 1 insertion(+)

$ guix pull --commit=$(git -C $SRC rev-parse HEAD)
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git20e984e
Computing Guix derivation for 'x86_64-linux'... /

$ guix describe
Generation 35Jun 05 2020 02:32:43(current)
  guix 20e984e
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 20e984e9311404295c9c82b54eac1c277709b0a0

$ git -C $SRC reset --hard HEAD^
HEAD is now at 86ac14b2f3 gnu: protonvpn-cli: Tweak description.

$ git -C $SRC reflog expire --expire-unreachable=now --all
$ git -C $SRC gc --prune=now --quiet

$ git -C $SRC show 20e984e9311404295c9c82b54eac1c277709b0a0
fatal: bad object 20e984e9311404295c9c82b54eac1c277709b0a0

$ guix pull --commit=c873980d18
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.gitc873980
Computing Guix derivation for 'x86_64-linux'... /
--8<---cut here---end--->8---


Now the same session after the introduction of '--allow-downgrades'.

--8<---cut here---start->8---
$ guix describe
Generation 37Jun 05 2020 01:28:52(current)
  guix 8bd0b53
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 8bd0b533b30d7ee5e03aee99a2eb96d5b0b1c836

$ echo hello >> $SRC/README && git -C $SRC commit -am hello
[master 09f6e9b34c] hello
 1 file changed, 1 insertion(+)

$ guix pull --commit=$(git -C $SRC rev-parse HEAD)
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git09f6e9b
Computing Guix derivation for 'x86_64-linux'... /

$ guix describe
Generation 38Jun 05 2020 02:57:13(current)
  guix 09f6e9b
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 09f6e9b34c6239bcdd8ca9e030d698b5244507a6

$ git -C $SRC reset --hard HEAD^
HEAD is now at 8bd0b533b3 gnu: libexif: Update to 0.6.22 [security fixes].

$ git -C $SRC reflog expire --expire-unreachable=now --all
$ git -C $SRC gc --prune=now --quiet
$ git -C $SRC show 09f6e9b34c6239bcdd8ca9e030d698b5244507a6
fatal: bad object 09f6e9b34c6239bcdd8ca9e030d698b5244507a6

$ guix pull --commit=e451612602 --allow-downgrades
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: object not found - no match for id
(09f6e9b34c6239bcdd8ca9e030d698b5244507a6)
--8<---

bug#41604: guix pull impossible after rebasing a local repository

2020-06-04 Thread zimoun
Hi John,

On Thu, 4 Jun 2020 at 16:12, John Soo  wrote:

> Oh nice, then this whole issue I think should be to report that
> --allow-downgrades does not allow everything.  When I first reported the
> issue I tried --allow-downgrades thanks to some help on IRC.  The first
> attempt failed as I mentioned previously in the thread.  However I did
> just try --allow-downgrades again after a rebase and it seems to have
> succeeded.  With that, I think this issue can be closed.  Thanks for
> thinking of this case!

Well, there is 2 issues, I guess.  One is fixed by allow downgrade.

The other one is not about '--allow-downgrades' but simply about pull
from a removed commit (rebase).  I do not think it could be considered
as a bug but the behaviour has changed and '--allow-downgrades' is not
enough.  Well, if I understand correctly what you described before in
this thread. :-)


> I think I will add some notes about a rebase workflow and
> --allow-downgrades to the contributing documentation. Looking just now
> I'm not sure using a local source tree as a channel is mentioned in the
> documentation either. I will open a different patch set to deal with
> those issues.

IMHO, the trick to be able to pull from a removed commit is to switch
generation first.  The price to pay is that history will be lost and
so news will be screwed up.

Well, for sure describe your workflow could be an entry of the Cookbook. :-)


All the best,
simon