bug#39527: A new information on LXQt DE not "logging in"

[o . rojon]

Hello guys,

I have come to realise something which might be of interest, but which 
might also be something which is well known to you.


When trying to launch LXQt from the GDM login/session manager, the 
screen just went blank and nothing happened. This is why I assumed "it 
simply doesnt work". Now I have switched to another login manager, and 
logging in to LXQt works - only that I am directly prompted to specify 
which WM I wanted to use. I was unable to locate one under /usr/bin 
(only /usr/bin/env seems to live there) and thus had to go to the 
/gnu/store directory.


So I assume that the problem might either be a "personal one" where I 
have forgotten to set some path (even though I have not received a 
particular warning of sorts). Or it is a problem that, either generally 
or specific to LXQt, I would call the "linking" situation -- that not 
completely supported packages just dont (yet) know about the location of 
the binaries.


That said, it is possible that to you guys, this is nothing noteworthy 
because it is clear. It's just that to me, it wasn't because I'm 
learning both guile and the linux ecosystem. Thus, if the problem at 
hand is simply a general problem, it is not a bug. Which means that the 
topic can be closed, if there is nothing to add :)


have a good day folks, guix rules

bug#41120: uvesafb service is unsupported on aarch64

[Efraim Flashner]

the uvesafb-service which was added to the installation image isn't
supported on aarch64 (or probably any non-x86 system) and causes the
creation of an installation image to fail.


-- 
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#41116: A naive proposal for a solution

[Alex Sassmannshausen via Bug reports for GNU Guix]

Upon thinking further about this it seems to me the problem is caused by
guix deploy attempting to restart services as well as it can during
deployment.  When this fails deployment fails.

guix system reconfigure on the other hand does not do this (afaik).  As
a result it can complete.

Once reconfigure is completed a reboot switches to the new system
version and is then thus able to restart the services.

If all this is correct, then the long-discussed guix deploy feature of
service restart policies would resolve this issue elegantly:
When a similar herd upgrade in future looms, a switch away from "restart
running services" to "no restart services" or "reboot after deployment"
would avoid this currently hard-coded failure mode.

Food for thought perhaps, if my understanding is anywhere close to
right, that is.

Alex

bug#41116: Guix deploy fails with new version of Herd

[Marius Bakke]

Hi Alex,

Alex Sassmannshausen via Bug reports for GNU Guix 
writes:

> Hello,
>
> I maintain a number of servers using Guix deploy.  It seems that the
> recent upgrade to Herd in Guix, and specifically commit
> 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec might have introduced a bug.
>
> From my testing, guix deploy currently consistently fails with:
> -8<->8---
> ice-9/boot-9.scm:1667:16: In procedure raise-exception:
> ERROR:
>   1. &inferior-exception:
>   arguments: (srfi-34 # &action-exception-error [service: root action: eval key: 
> keyword-argument-error args: ("# shepherd/service.scm:903:4 (command #:key user group directory 
> environment-variables pid-file pid-file-timeout log-file) | (program . 
> program-args)>" "Unrecognized keyword" () (#:file-creation-mask))] 
> 7eff2bd7be00>>)
>   inferior: #f
>   stack: ()
> -8<->8---
>
> A workaround is to build the system configuration locally on the target
> server, then to reconfigure.  It will still error at the same place, but
> at this point, after restarting the server, the new version of Herd will
> be running and both deploy and reconfigure will work.
>
> I don't know what a good solution to this could be, but it may be
> something we need to consider in future development of Herd.

This issue has been reported by a number of users on IRC.  I think the
problem is that the the #:file-creation-mask keyword requires support
from the running Shepherd, which may not have it yet.  I think we should
revert commit 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec until we find a
smooth upgrade path.  Can you try it and push if that fixes guix deploy?


signature.asc
Description: PGP signature

bug#41116: Guix deploy fails with new version of Herd

[Alex Sassmannshausen via Bug reports for GNU Guix]

Hello,

I maintain a number of servers using Guix deploy.  It seems that the
recent upgrade to Herd in Guix, and specifically commit
4c0cc7bed3de2c0e2d3a6e95b88693941e839eec might have introduced a bug.

>From my testing, guix deploy currently consistently fails with:
-8<->8---
ice-9/boot-9.scm:1667:16: In procedure raise-exception:
ERROR:
  1. &inferior-exception:
  arguments: (srfi-34 #" "Unrecognized keyword" () (#:file-creation-mask))] 
7eff2bd7be00>>)
  inferior: #f
  stack: ()
-8<->8---

A workaround is to build the system configuration locally on the target
server, then to reconfigure.  It will still error at the same place, but
at this point, after restarting the server, the new version of Herd will
be running and both deploy and reconfigure will work.

I don't know what a good solution to this could be, but it may be
something we need to consider in future development of Herd.

Best wishes,

Alex

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

[Ludovic Courtès]

Comrades,

Christopher Baines  skribis:

> (use-modules (guix channels)
>  (guix inferior))
>
> (define channels
>   (list (channel
>  (name 'guix)
>  (url "https://git.savannah.gnu.org/git/guix.git";)
>  (commit
>   "e02c2f85b36ce1c733bd908a210ce1182bdd2560"
>
> (define inferior
>   (inferior-for-channels channels))
>
> (first (lookup-inferior-packages inferior "linux-libre" "5.2.21"))
>
>
> If you save that as a file then attempt to build it:
>
>
> → guix build -f test.scm 
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Backtrace:
>4 (primitive-load "/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r?")
> In ice-9/eval.scm:
> 619:8  3 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>182:19  2 (proc #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>142:16  1 (compile-top-call # ?)
> In unknown file:
>0 (%resolve-variable (7 . call-with-new-thread) #)
>
> ERROR: In procedure %resolve-variable:
> Unbound variable: call-with-new-thread

The attached patches add a mechanism to patch the Guix source tree, and
then use that mechanism to add the missing (ice-9 threads) import.  With
this I can do:

  ./pre-inst-env guix time-machine \
 --commit=e02c2f85b36ce1c733bd908a210ce1182bdd2560 -- build linux-libre

… which is a simple way to do what the manifest above was about.

If we think a bit long-term, I think the %quirks and %patches mechanisms
are a necessary evil.  The goal is for ‘build-self.scm’ to use as little
of the Guix API, as well as Guile APIs that are presumably here to stay.
But as we’re already seeing, there are unavoidably incompatibilities
that arise here and there.  The good news is that we know today how to
modify yesterday’s code to work well, or which Guile version to use to
get it to run.

Thoughts?

Thanks,
Ludo’.

>From 4ec2c3b5527b2189b3f767a980f80dee3c6717ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Wed, 6 May 2020 22:18:52 +0200
Subject: [PATCH 1/3] channels: Add 'latest-channel-instance'.

* guix/channels.scm (latest-channel-instance): New procedure.
(latest-channel-instances): Use it.
---
 guix/channels.scm | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/guix/channels.scm b/guix/channels.scm
index 041fae2a9c..4ffc366d6a 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -199,6 +199,14 @@ description file or its default value."
 channel INSTANCE."
   (channel-metadata-dependencies (channel-instance-metadata instance)))
 
+(define (latest-channel-instance store channel)
+  "Return the latest channel instance for CHANNEL."
+  (let-values (((checkout commit)
+(latest-repository-commit store (channel-url channel)
+  #:ref (channel-reference
+ channel
+(channel-instance channel commit checkout)))
+
 (define* (latest-channel-instances store channels #:optional (previous-channels '()))
   "Return a list of channel instances corresponding to the latest checkouts of
 CHANNELS and the channels on which they depend.  PREVIOUS-CHANNELS is a list
@@ -224,20 +232,16 @@ of previously processed channels."
(G_ "Updating channel '~a' from Git repository at '~a'...~%")
(channel-name channel)
(channel-url channel))
-   (let-values (((checkout commit)
- (latest-repository-commit store (channel-url channel)
-   #:ref (channel-reference
-  channel
- (let ((instance (channel-instance channel commit checkout)))
-   (let-values (((new-instances new-channels)
- (latest-channel-instances
-  store
-  (channel-instance-dependencies instance)
-  previous-channels)))
- (values (append (cons channel new-channels)
- previous-channels)
- (append (cons instance new-instances)
- instances
+   (let ((instance (latest-channel-instance store channel)))
+ (let-values (((new-instances new-channels)
+   (latest-channel-instances
+store
+(channel-instance-dependencies instance)
+previous-channels)))
+   (values (append (cons channel new-channels)
+   previous-channels)
+ 

bug#41115: warsow-qfusion bundles compiled software, third party sources

[Marius Bakke]

Hello,

The 'warsow-qfusion' source code contains lots of compiled libraries,
for various platforms (win32, GNU/Linux, macOS).  It also bundles many
of its dependencies even if they are unused.

Those should be removed with a source 'snippet'.


signature.asc
Description: PGP signature

bug#40837: core-updates: webkitgtk web process sandbox incomplete

[Marius Bakke]

Jack Hill  writes:

> On Wed, 6 May 2020, Marius Bakke wrote:
>
>> Hello Jack,
>>
>> Thanks a lot for this work.
>
> You're welcome. I'm happy that we seem to be making good progress.
>
>> Jack Hill  writes:
>>
>>> Some additional observations:
>>>
>>> With my patched webkitgtk, if I set:
>>>
>>> PULSE_CLIENTCONFIG=/gnu/store/zc4dsmvdabi00nvisrjhi9w00ff4igs7-client.conf
>>>
>>> it does work, which is an improvement compared to without the patch.
>>
>> Great.  I have attached a patch for Guix that stops using /etc for these
>> variables.
>
> Good idea! That way we won't have to wait for WebKitGTK to canonicalize 
> all paths :)
>
>>> [0] 
>>> https://github.com/NixOS/nixpkgs/blob/465566948393cf533e3617704d1c4ccc34cf3753/pkgs/development/libraries/webkitgtk/fix-bubblewrap-paths.patch
>>>
>>> so I wonder if I didn't do the mounts in the right place and or if it is
>>> becasue I missed /run/current-system.
>>>
>>> I'm going to try to adapt the Nix patch to see if that helps.
>>
>> Were you able to verify whether /run/current-system is required inside
>> the sandbox?
>
> I don't think /run/current-system is needed.

Excellent.  I tested Epiphany with these patches on a popular video
streaming site and everything seemed fine.

>> I cleaned up your patch a bit and rebased it on the latest master
>> branch, available as patch 2/2 below.  Currently building it on
>> 'core-updates' to verify that it works.  It takes a while on my dinky
>> quad-core server though.  :-)
>>
>> It does not bind /run/current-system, and I think we should avoid it if
>> possible.  Ideally we would only mount the store paths required by the
>> consumers instead of all of /gnu/store, but not sure how to achieve
>> that.
>
> I've tested the updated patch by applying it to master and merging into 
> core-updates. I'm happy to report that everything seems to be working for 
> me after doing so!
>
> Sharing less than the whole store sounds like a great aspiration, but I 
> think we'd have to teach WebKitGTK how to ask Guix for its closure to do 
> so. On FHS-compliant systems, all of the various /usr/lib and /usr/share 
> directories are bind-mounted into the new namespace, so I don't think 
> we're providing too much more. It's nice that our setuid binaries reside 
> outside of the store :)

Indeed, thanks for testing and confirming.

I added a little more context in the patch description and finally
pushed it as a6919866b07e9ed3986abde7ae48d0c69ff3deed.

Again, thank you very much for taking care of this.  :-)


signature.asc
Description: PGP signature

bug#41082: nomodeset

[Danny Milosavljevic]

Hi,

On Wed, 6 May 2020 10:19:05 +0200
"pelzflorian (Florian Pelz)"  wrote:

> (but the video resolution should be adjusted, probably something higher than
> 1024x768 is supported by the system).

> We could add a uvesafb-service-type to its own gnu/services/….scm.

> Autodetection of the best usable resolution via v86d:testvbe could be
> added (however the best resolution usable with uvesafb may be less
> than the screen’s resolution).

That could maybe cause something not to work too.

I know I keep harping on that, but our generation feature only helps if there
actually is a previous generation to go back too.  So any "improvement" to
what the installer did, which obviously worked if Guix boots up, could also
cause the finished installation not to work--and without recourse.

(Hmm, but then there's nothing preventing us from reconfiguring twice in the
installer)

> One way such a uvesafb-service-type could work is exactly like in the
> installler.  Would it be right to add a uvesafb service that runs
> modprobe itself?

Why not have uvesafb-service-type extend kernel-module-loader-service-type
and give it a module to load unconditionally?
That would make the whole thing more declarative, which we usually want in
Guix.

If that's not possible, sure, the uvesafb service could also modprobe stuff
on its own.

> Another way is to extend etc-service-type for this the way I wrote at
> .
> Extending other services seems cleaner, but in the discussions by
> Brice Waegeneire and Danny Milosavljevic (I put them in Cc) they were
> not really satisfied with etc-service-type.

Well, it's okay--but we could also make a proper service that would allow
other guix services to specify what kernel module configuration they expect
and also guix to find and report conflicts in the global view.

I think it's the right thing to do since the Linux kernel (and the hardware)
keeps global state.
So the programs that run in user space have to kinda negotiate what global state
is okay for everyone.  That negotiation is a lot easier for Guix to do if
it actually knows what is what, as opposed to an opaque etc directory that could
be anything.

Maybe that's premature and we could use etc-service-type in the mean time.
However, if a kernel-module-configuration-service appeared later then users
would have to migrate to it manually.  Not great.

> > kernel-module-configuration-service if/when it exists.  (I did not
> > know how to extend etc-service-type with a file created at runtime not
> > build time, but maybe kernel-module-configuration-service works
> > differently anyway.)  

I think Brice already had a nice mockup for the design, but I don't know whether
Brice plans to do it or not.  Brice?


pgpNXp8Ayd0kP.pgp
Description: OpenPGP digital signature

bug#40837: core-updates: webkitgtk web process sandbox incomplete

[Jack Hill]

On Wed, 6 May 2020, Marius Bakke wrote:


Hello Jack,

Thanks a lot for this work.


You're welcome. I'm happy that we seem to be making good progress.


Jack Hill  writes:


Some additional observations:

With my patched webkitgtk, if I set:

PULSE_CLIENTCONFIG=/gnu/store/zc4dsmvdabi00nvisrjhi9w00ff4igs7-client.conf

it does work, which is an improvement compared to without the patch.


Great.  I have attached a patch for Guix that stops using /etc for these
variables.


Good idea! That way we won't have to wait for WebKitGTK to canonicalize 
all paths :)



[0] 
https://github.com/NixOS/nixpkgs/blob/465566948393cf533e3617704d1c4ccc34cf3753/pkgs/development/libraries/webkitgtk/fix-bubblewrap-paths.patch

so I wonder if I didn't do the mounts in the right place and or if it is
becasue I missed /run/current-system.

I'm going to try to adapt the Nix patch to see if that helps.


Were you able to verify whether /run/current-system is required inside
the sandbox?


I don't think /run/current-system is needed.


I cleaned up your patch a bit and rebased it on the latest master
branch, available as patch 2/2 below.  Currently building it on
'core-updates' to verify that it works.  It takes a while on my dinky
quad-core server though.  :-)

It does not bind /run/current-system, and I think we should avoid it if
possible.  Ideally we would only mount the store paths required by the
consumers instead of all of /gnu/store, but not sure how to achieve
that.


I've tested the updated patch by applying it to master and merging into 
core-updates. I'm happy to report that everything seems to be working for 
me after doing so!


Sharing less than the whole store sounds like a great aspiration, but I 
think we'd have to teach WebKitGTK how to ask Guix for its closure to do 
so. On FHS-compliant systems, all of the various /usr/lib and /usr/share 
directories are bind-mounted into the new namespace, so I don't think 
we're providing too much more. It's nice that our setuid binaries reside 
outside of the store :)


Best,
Jack

bug#41038: [PATCH] doc: Reword "The GCC toolchain".

[zimoun]

Hi Ludo

On Mon, 4 May 2020 at 21:52, Ludovic Courtès  wrote:

> True!  Do you want to send a patch?  :-)

See attached.  Feel free to reword the commit message if it is not
compliant with the standard.


Cheers,
simon
From cefffd56f8363b45f3593814ec296015906854b4 Mon Sep 17 00:00:00 2001
From: zimoun 
Date: Wed, 6 May 2020 19:26:05 +0200
Subject: [PATCH] doc: Reword "The GCC toolchain".

Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478
as discussed in .

* doc/guix.texi (Packages for C Development): Rename to...
(The GCC toolchain): ...this. Add gfortran-toolchain.
(Invoking guix package): Add guix-search anchor.
(Application Setup)[The GCC toolchain]: Remove.
---
 doc/guix.texi | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index bc5ecbbcde..5b56ae757d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -228,6 +228,7 @@ Development
 
 * Invoking guix environment::   Setting up development environments.
 * Invoking guix pack::  Creating software bundles.
+* The GCC toolchain::   Working with languages supported by GCC.
 
 Programming Interface
 
@@ -1767,13 +1768,6 @@ want to avoid auto-loading the Emacs packages installed with Guix, you
 can do so by running Emacs with the @code{--no-site-file} option
 (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
 
-@subsection The GCC toolchain
-
-@c XXX: The contents of this section were moved under
-@c ``Development'', since it makes more sense there and is not specific
-@c foreign distros.  Remove it from here eventually?
-@xref{Packages for C Development}, for information on packages for C/C++
-development.
 
 @node Upgrading Guix
 @section Upgrading Guix
@@ -3039,6 +3033,7 @@ availability of packages:
 
 @item --search=@var{regexp}
 @itemx -s @var{regexp}
+@anchor{guix-search}
 @cindex searching for packages
 List the available packages whose name, synopsis, or description matches
 @var{regexp} (in a case-insensitive fashion), sorted by relevance.
@@ -4669,9 +4664,9 @@ pack} command allows you to create @dfn{application bundles} that can be
 easily distributed to users who do not run Guix.
 
 @menu
-* Invoking guix environment::   Setting up development environments.
-* Invoking guix pack::  Creating software bundles.
-* Packages for C Development::  Working with C code with Guix.
+* Invoking guix environment::  Setting up development environments.
+* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain::  Working with languages supported by GCC.
 @end menu
 
 @node Invoking guix environment
@@ -5335,13 +5330,15 @@ In addition, @command{guix pack} supports all the common build options
 (@pxref{Common Build Options}) and all the package transformation
 options (@pxref{Package Transformation Options}).
 
-@node Packages for C Development
-@section Packages for C Development
+
+@node The GCC toolchain
+@section The GCC toolchain
 
 @cindex GCC
 @cindex ld-wrapper
 @cindex linker wrapper
 @cindex toolchain, for C development
+@cindex toolchain, for Fortran development
 
 If you need a complete toolchain for compiling and linking C or C++
 source code, use the @code{gcc-toolchain} package.  This package
@@ -5355,7 +5352,9 @@ invoke the actual linker with this new set of arguments.  You can instruct the
 wrapper to refuse to link against libraries not in the store by setting the
 @code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
 
-
+The package @code{gfortran-toolchain} provides a complete GCC toolchain
+for Fortran development.  For other languages, please use
+@command{guix search gcc toolchain} (see @pxref{guix-search,, Invoking guix package}).
 
 @c *
 @node Programming Interface
-- 
2.26.1

bug#40837: core-updates: webkitgtk web process sandbox incomplete

[Marius Bakke]

Hello Jack,

Thanks a lot for this work.

Jack Hill  writes:

> Some additional observations:
>
> With my patched webkitgtk, if I set:
>
> PULSE_CLIENTCONFIG=/gnu/store/zc4dsmvdabi00nvisrjhi9w00ff4igs7-client.conf
>
> it does work, which is an improvement compared to without the patch.

Great.  I have attached a patch for Guix that stops using /etc for these
variables.

> I notice that Nix [0] has a similar patch:
>
> """
> diff -ru 
> old/webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
>  webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
> --- 
> old/webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
>  2019-09-09 04:47:07.0 -0400
> +++ 
> webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp 
> 2019-09-20 21:14:10.537921173 -0400
> @@ -585,7 +585,7 @@
>   { SCMP_SYS(keyctl), nullptr },
>   { SCMP_SYS(request_key), nullptr },
>
> -// Scary VM/NUMA ops 
> +// Scary VM/NUMA ops
>   { SCMP_SYS(move_pages), nullptr },
>   { SCMP_SYS(mbind), nullptr },
>   { SCMP_SYS(get_mempolicy), nullptr },
> @@ -724,6 +724,10 @@
>   "--ro-bind-try", "/usr/local/lib64", "/usr/local/lib64",
>
>   "--ro-bind-try", PKGLIBEXECDIR, PKGLIBEXECDIR,
> +
> +// Nix Directories
> +"--ro-bind", "@storeDir@", "@storeDir@",
> +"--ro-bind", "/run/current-system", "/run/current-system",
>   };
>   // We would have to parse ld config files for more info.
>   bindPathVar(sandboxArgs, "LD_LIBRARY_PATH");
> """
>
> [0] 
> https://github.com/NixOS/nixpkgs/blob/465566948393cf533e3617704d1c4ccc34cf3753/pkgs/development/libraries/webkitgtk/fix-bubblewrap-paths.patch
>
> so I wonder if I didn't do the mounts in the right place and or if it is 
> becasue I missed /run/current-system.
>
> I'm going to try to adapt the Nix patch to see if that helps.

Were you able to verify whether /run/current-system is required inside
the sandbox?

I cleaned up your patch a bit and rebased it on the latest master
branch, available as patch 2/2 below.  Currently building it on
'core-updates' to verify that it works.  It takes a while on my dinky
quad-core server though.  :-)

It does not bind /run/current-system, and I think we should avoid it if
possible.  Ideally we would only mount the store paths required by the
consumers instead of all of /gnu/store, but not sure how to achieve
that.

From a2607c8246456460a6bbed62144daf7196a5c9bd Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Wed, 6 May 2020 17:48:42 +0200
Subject: [PATCH 1/2] services: Do not use symbolic links in PulseAudio
 variables.

This addresses  by making these configuration
files more easily accessible within the WebKitGTK+ sandbox.

* gnu/services/sound.scm (pulseaudio-environment): Move below
PULSEAUDIO-CONF-ENTRY.  Create PULSE_CONFIG and PULSE_CLIENTCONFIG entries
directly instead of referring to /etc/pulse.
(pulseaudio-etc): Do not create /etc/pulse/client.conf and /etc/pulse/daemon.conf.
---
 gnu/services/sound.scm | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/gnu/services/sound.scm b/gnu/services/sound.scm
index a1c928222a..bdf819b422 100644
--- a/gnu/services/sound.scm
+++ b/gnu/services/sound.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2018, 2020 Oleg Pykhalov 
 ;;; Copyright © 2020 Leo Prikler 
+;;; Copyright © 2020 Marius Bakke 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -127,11 +128,6 @@ ctl.!default {
   (default
 (file-append pulseaudio "/etc/pulse/system.pa"
 
-(define (pulseaudio-environment config)
-  `(;; Define these variables, so that pulseaudio honors /etc.
-("PULSE_CONFIG" . "/etc/pulse/daemon.conf")
-("PULSE_CLIENTCONFIG" . "/etc/pulse/client.conf")))
-
 (define (pulseaudio-conf-entry arg)
   (match arg
 ((key . value)
@@ -139,21 +135,22 @@ ctl.!default {
 ((? string? _)
  (string-append arg "\n"
 
+(define pulseaudio-environment
+  (match-lambda
+(($  client-conf daemon-conf default-script-file)
+ `(("PULSE_CONFIG" . ,(apply mixed-text-file "daemon.conf"
+ "default-script-file = " default-script-file "\n"
+ (map pulseaudio-conf-entry daemon-conf)))
+   ("PULSE_CLIENTCONFIG" . ,(apply mixed-text-file "client.conf"
+   (map pulseaudio-conf-entry client-conf)))
+
 (define pulseaudio-etc
   (match-lambda
-(($  client-conf daemon-conf
-   default-script-file system-script-file)
+(($  _ _ default-script-file system-script-file)
  `(("pulse"
 ,(file-union
   "pulse"
-  `(("client.conf"
- ,(apply mixed-text-file "client.conf"
- (map pulseaudi

bug#41082: nomodeset

[Danny Milosavljevic]

Hi,

On Wed, 06 May 2020 08:56:48 +0200
Mathieu Othacehe  wrote:

> Should we propose the installation of uvesafb service in the
> installation? Or detect that it is currently used and force its install?

Since we don't have a previous generation to go back to, I'd prefer the first
generation to be one that actually works.  So the latter.

If that's not what is wanted, one can always go into config and reconfigure
the system.  If *that* doesn't boot, one can just reboot and select the
previous generation in the bootloader.

So I'd be in favor of the installer creating a system as close as possible
to the installer's own boot configuration.

Compared to that, if one created a system with a configuration different
to the installer's own boot media, maybe the system won't boot at all.
What do you do then?


pgps4dTpB_nF2.pgp
Description: OpenPGP digital signature

bug#41091: can't build external gcc

[raingloom]

On Tue, 05 May 2020 04:35:31 +0300
Tim Komarov  wrote:

> Many projects (Buildroot, coreboot, Yocto) require building a
> toolchain.
> 
> Every time it tries to build it (I've checked Buildroot and coreboot)
> it fails with the following errors:
> 
> In file included from ./bconfig.h:3:0,
>  from ../../gcc/gengtype-lex.c:4:
> ./auto-host.h:2396:16: error: declaration does not declare anything
> [-fpermissive] #define rlim_t long
> ^
> In file included from /d/gcc-8.4.0/gcc-8.4.0/gcc/gengtype-lex.l:30:0:
> ../../gcc/system.h:488:14: error: conflicting declaration of C
> function ‘void* sbrk(int)’ extern void *sbrk (int);
> 
> In file included from /d/gcc-8.4.0/gcc-8.4.0/gcc/gengtype-lex.l:30:0:
> ../../gcc/system.h:496:14: error: ambiguating new declaration of
> ‘char* strstr(const char*, const char*)’ extern char *strstr (const
> char *, const char *);
> 
> In file included from /d/gcc-8.4.0/gcc-8.4.0/gcc/gengtype-lex.l:30:0:
> ../../gcc/system.h:540:20: error: conflicting declaration of C
> function ‘const char* strsignal(int)’ extern const char *strsignal
> (int);
> 
> In file included from ../../gcc/system.h:691:0,
>  from /d/gcc-8.4.0/gcc-8.4.0/gcc/gengtype-lex.l:30:
> ../../gcc/../include/libiberty.h:112:14: error: ambiguating new
> declaration of ‘char* basename(const char*)’ extern char *basename
> (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1);
> 
> Switching gcc versions doesn't help.
> 
> One can find a simple way to reproduce in buildroot.txt,
> build-gcc.log provides a complete log.
> 
> Looking forward for your help. Thanks!
> 
> -- 
> Best Regards,
> Timofey Komarov

What I'm trying to do (currently with devkitPro and EDK2) is to just
create a Guix package for the patched GCC toolchain and either use that
directly (devkitPro) or convince the build scripts to use the packaged
toolchain (EDK2).

I'm not sure if it will work out, but in the long run, it seems like
the better choice. That is, if it will work at all.

bug#40981: Graphical installer tests sometimes hang.

[Mathieu Othacehe]

Hello,

I found what happened here. Turns out, when a process is forked and
before "setsid" or "setpgid" is called, it shares the parent PGID. In
that case the parent is Shepherd, with the PGID 0.

When doing the following actions:

* stop guix-daemon
* start guix-daemon

* stop guix-daemon
* start guix-daemon

If the second stop occurs after "fork" has been done, but before
"setsid", then "(getpgid)" returns 0. The naive patch attached could fix
the situation.

WDYT?

Mathieu
>From 0e4167251a56d6baa4f51fe72250a6e3bffae8c3 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Wed, 6 May 2020 11:48:26 +0200
Subject: [PATCH] service: Fix 'make-kill-destructor' when PGID is zero.

When a process is forked, and before its GID is changed in "exec-command",
it will share the parent GID, which is 0 for Shepherd. In that case, use
the PID instead of the PGID.

* modules/shepherd/service.scm (make-kill-destructor): Handle the case when
PGID is zero, between the process fork and exec.
---
 modules/shepherd/service.scm | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index 8604d2f..258992c 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -5,6 +5,7 @@
 ;; Copyright (C) 2016 Alex Kost 
 ;; Copyright (C) 2018 Carlo Zancanaro 
 ;; Copyright (C) 2019 Ricardo Wurmus 
+;; Copyright (C) 2020 Mathieu Othacehe 
 ;;
 ;; This file is part of the GNU Shepherd.
 ;;
@@ -957,11 +958,15 @@ start."
   "Return a procedure that sends SIGNAL to the process group of the PID given
 as argument, where SIGNAL defaults to `SIGTERM'."
   (lambda (pid . args)
-;; Kill the whole process group PID belongs to.  Don't assume that PID
-;; is a process group ID: that's not the case when using #:pid-file,
-;; where the process group ID is the PID of the process that
-;; "daemonized".
-(kill (- (getpgid pid)) signal)
+;; Kill the whole process group PID belongs to.  Don't assume that PID is
+;; a process group ID: that's not the case when using #:pid-file, where
+;; the process group ID is the PID of the process that "daemonized".  If
+;; this procedure is called, between the process fork and exec, the PGID
+;; will still be zero (the Shepherd PGID). In that case, use the PID.
+(let ((pgid (getpgid pid)))
+  (if pgid
+  (kill (- pgid) signal)
+  (kill pid signal)))
 #f))
 
 ;; Produce a constructor that executes a command.
-- 
2.26.0

bug#31780: (no subject)

[Brice Waegeneire]

Fixed by 2f93615670da1f9cafa90a904c7b6254ab73586e.

bug#40945: (no subject)

[Brice Waegeneire]

Fixed by ab034adfe86333fccd6afe476806f169e2074d69.

bug#41082: nomodeset

[pelzflorian (Florian Pelz)]

On Wed, May 06, 2020 at 08:56:48AM +0200, Mathieu Othacehe wrote:
> Should we propose the installation of uvesafb service in the
> installation? Or detect that it is currently used and force its install?
> 
> Florian, WDYT?

Yes, IMHO there should be a uvesafb-service-type.  Copying the uvesafb
service from the installer into the config.scm should work (but the
video resolution should be adjusted, probably something higher than
1024x768 is supported by the system).

We could add a uvesafb-service-type to its own gnu/services/….scm.
Autodetection of the best usable resolution via v86d:testvbe could be
added (however the best resolution usable with uvesafb may be less
than the screen’s resolution).

One way such a uvesafb-service-type could work is exactly like in the
installler.  Would it be right to add a uvesafb service that runs
modprobe itself?

Another way is to extend etc-service-type for this the way I wrote at
.
Extending other services seems cleaner, but in the discussions by
Brice Waegeneire and Danny Milosavljevic (I put them in Cc) they were
not really satisfied with etc-service-type.

Back then I wrote 
:
> When the dust has settled on the kernel-module-configuration-service
> discussed by Brice Waegeneire and Danny Milosavljevic
> ,
> a proper uvesafb service can be added.  Then I can make and test one
> and it could also be used in the installer.  That would be the clean
> solution.  In particular, it could detect the resolution to use for
> uvesafb automatically by running the attached code testvbe.scm as
> root.  But how to run that code depends on the
> kernel-module-configuration-service if/when it exists.  (I did not
> know how to extend etc-service-type with a file created at runtime not
> build time, but maybe kernel-module-configuration-service works
> differently anyway.)

Regards,
Florian