bug#25484: Closing #25484?

[Brice Waegeneire]

Hello Guix,

I think this 3 year old bug is fixed, even though Ricardo's patch wasn't
applied. I can't find any “may conflict with “ in the build log of a 
recent

build of qemu[0] and qemu now depends on 'libjpeg-turbo' instead of
'libjpeg' since 513885b54e5a6abd46cb02b04ebab51b879150c0.

Should we close this issue?

[0]: http://ci.guix.gnu.org/build/2599861/details

- Brice

bug#40899: Locales not set up correctly

[Matthew Kraai]

Hi simon,

On Mon, Apr 27, 2020 at 02:53:17PM +0200, zimoun wrote:
> On Mon, 27 Apr 2020 at 14:30, Matthew Kraai  wrote:
> 
> > $ guix package -i nss-certs
> > guile: warning: failed to install locale
> 
> There 3 points:
> 
>  a) "guix install glibc-utf8-locales" as root because of the daemon
> and restart it. (depending on your system init, an extra config should
> be required)

I modified the script to run the following commands as root:

```
guix package -i glibc-utf8-locales
systemctl restart guix-daemon
```

>  b) "guix install glibc-utf8-locales" as regular user

The script was already doing this.

> This should fix the locales issues.
> 
> Note that depending on your locale, glibc-utf8-locles should not
> provide it. (The term utf8 could be misleading). But en_US is provided
> by it.

When I run guix, it still produces the same locale messages:

```
$ guix package -I
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package
and defining `GUIX_LOCPATH', along these lines:

 guix package -i glibc-utf8-locales
  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

glibc-utf8-locales  2.29out 
/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29
```

> > guix package: error: some substitutes for the outputs of derivation 
> > `/gnu/store/mxp55201zl6wm2d82xdjnc8qa7qwgr85-nss-certs-3.50.drv' failed 
> > (usually happens due to networking issues); try `--fallback' to build 
> > derivation from source
> 
>  c) Try:
>   guix install nss-certs --fallback

The --fallback option works.  Thank you for the suggestion.

-- 
Matthew Kraai

bug#40912: [BUG] GUI installer loops when using a NVME drive

[Mathieu Othacehe]

Hello Kozo,

> Did some troubleshooting with Civodul. Submitting the message log that
> helped him determine it was a NVME issue.

I guess you used the 1.1.0 release? This bug should be resolved on
master. Do you have the possibility to build a new ISO image?

You can run this command as explained here[1]:

--8<---cut here---start->8---
guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
--8<---cut here---end--->8---

Thanks,

Mathieu

[1]: 
https://guix.gnu.org/manual/en/html_node/Building-the-Installation-Image.html#Building-the-Installation-Image

bug#40899: Locales not set up correctly

[zimoun]

On Tue, 28 Apr 2020 at 09:56, Matthew Kraai  wrote:

> When I run guix, it still produces the same locale messages:
>
> ```
> $ guix package -I
> guile: warning: failed to install locale
> hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package
> and defining `GUIX_LOCPATH', along these lines:
>
>  guix package -i glibc-utf8-locales
>   export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>
> See the "Application Setup" section in the manual, for more info.
>
> glibc-utf8-locales  2.29out 
> /gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29
> ```

Hum? Did you set GUIX_LOCPATH?

bug#40899: Locales not set up correctly

[Matthew Kraai]

On Tue, Apr 28, 2020 at 10:14:13AM +0200, zimoun wrote:
> On Tue, 28 Apr 2020 at 09:56, Matthew Kraai  wrote:
> 
> > When I run guix, it still produces the same locale messages:
> >
> > ```
> > $ guix package -I
> > guile: warning: failed to install locale
> > hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
> > package
> > and defining `GUIX_LOCPATH', along these lines:
> >
> >  guix package -i glibc-utf8-locales
> >   export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> >
> > See the "Application Setup" section in the manual, for more info.
> >
> > glibc-utf8-locales  2.29out 
> > /gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29
> > ```
> 
> Hum? Did you set GUIX_LOCPATH?

Yes,

```
admin@ip-172-31-11-27:~$ echo $GUIX_LOCPATH
/home/admin/.guix-profile/lib/locale
admin@ip-172-31-11-27:~$ guix package -I
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package
and defining `GUIX_LOCPATH', along these lines:

 guix package -i glibc-utf8-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

glibc-utf8-locales  2.29out 
/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29
```

-- 
Matthew Kraai

bug#35441: r-minimal is not reproducible

[Ricardo Wurmus]

With the upgrade to R 4.0.0 r-minimal is now reproducible.  This is not
because R 4.0.0 fixed anything but because more package meta data files
had become irreproducible.

I noticed that setting LC_ALL to C during the build ensures that package
meta data files are generated reproducibly.

Closing!

--
Ricardo

bug#40899: Locales not set up correctly

[zimoun]

Is 'admin' the regular user or another name for the 'root' account?

On the Debian foreign distro, for GUIX_LOCPATH, I have:

 - root account: /root/.guix-profile/lib/local
 - regular user: /home/kikoo/.guix-profile/lib/locale

Hope that helps,
simon

bug#40926: spice-vdagent not scaling the display

[camlriot]

Hi,
I have installed guix v1.1.0 as a guest OS using virt-manager. In the 
misc. services section of the manual 
http://guix.gnu.org/manual/en/guix.html#Miscellaneous-Services , it is 
suggested to enable the spice-vdagent service. So, with help on irc chat 
I added the two lines in my config.scm

(use-service modules ... spice)
(spice-vdagent-service) in the services list.

On rebooting with the newly configurated build, I'm able to use the 
clipboard feature of spice, but the display does not scale on resizing 
the window (I have checked the option - Autoresize VM with the window in 
virt-manager).


Relevant Log:
localhost shepherd[1]: Service spice-vdagentd has been started.
localhost spice-vdagentd: GetSeats failed: The name 
org.freedesktop.ConsoleKit was not provided by any .service files

localhost spice-vdagentd: (console-kit) seat: (null)
localhost spice-vdagentd: no session info, max 1 session agent allowed

bug#35574: bcm5974 touchpad is not recognized as touchpad

[pelzflorian (Florian Pelz)]

On Mon, Apr 27, 2020 at 08:36:37AM +0200, Mathieu Othacehe wrote:
> Thanks for fixing this! This seems like a reasonable choice. However, I
> noticed that on Ubuntu, CONFIG_USB_MOUSE is set to 'M'. So maybe they
> have some special udev/blacklist rules to handle this case?

Interesting.  Thank you for checking.  So maybe setting
CONFIG_USB_MOUSE=n in the kernel config is the wrong way.  I installed
Ubuntu and they just have a file /etc/modprobe.d/blacklist.conf
containing the lines

# these drivers are very simple, the HID drivers are usually preferred
blacklist usbmouse
blacklist usbkbd

I wonder if a default blacklist file would be more like the Guix way.
Or default blacklist kernel-arguments?  I remember a discussion by
Danny Milosavljevic and Brice Waegeneire about this at
.  All these avoid recompiling the
linux-libre package.

Danny, Brice, I’m putting you in Cc, maybe you have an opinion on
this?  I suppose I should not change %default-extra-linux-options.

Regards,
Florian

bug#40544: Pulseaudio is not looking for user configuration

[Diego Nicola Barbato]

Hi,

Ludovic Courtès  writes:

> Hi Diego,
>
> Diego Nicola Barbato  skribis:
>
>> pkill9  writes:
>>
>>> Pulseaudio doesn't read my user configuration files according to strace.
>>>
>>> Attached is the output of `strace -o /tmp/log.log pulseaudio` - It only
>>> looks for /etc/pulse/daemon.conf.
>>
>> That's a known [0] (but AFAIK undocumented) side effect of the
>> PulseAudio service, which was added to %desktop-services in January [1].
>> If you want PulseAudio to read your user configuration files you'll have
>> to remove that service from your system services or unset PULSE_CONFIG
>> and PULSE_CLIENT_CONFIG in ~/.profile [2].
>
> It would be good to document that, right below
> ‘pulseaudio-service-type’.  Would you like to give it a try, Diego?

I've attached a patch, which adds a warning to the documentation.

> Or alternately, is there a way we can arrange so that the user’s config
> takes precedence over /etc/pulse?

We can't configure PulseAudio with "--sysconfdir=/etc" because it would
break without the service (e.g. on foreign distributions).[0]

We could patch PulseAudio to make the sysconfdir configurable at runtime
using an environment variable.  The service could set this environment
variable to /etc instead of setting ‘PULSE_CONFIG’ and
‘PULSE_CLIENT_CONFIG’.  That way the user's config would take precedence
over /etc/pulse (PulseAudio's normal behaviour).  Without the service
(and with the environment variable unset) it would fall back to the
sysconfdir configured at build time so it wouldn't break on foreign
distributions.  Although I doubt that the slight improvement in user
experience would justify the increased maintenance burden.

Regards,

Diego

[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38172#14

>From a33a10102f555454d9025b0693edf8d539f6a7af Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato 
Date: Sat, 25 Apr 2020 11:32:07 +0200
Subject: [PATCH] doc: Mention that PulseAudio service overrides user
 configuration.

* doc/guix.texi (Sound Services): Add a warning that 'pulseaudio-service-type'
  overrides per-user configuration files in '~/.config/pulse'.
---
 doc/guix.texi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 19094c4b70..683c40b476 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -63,7 +63,7 @@ Copyright @copyright{} 2018, 2019 Florian Pelz@*
 Copyright @copyright{} 2018 Laura Lazzati@*
 Copyright @copyright{} 2018 Alex Vong@*
 Copyright @copyright{} 2019 Josh Holland@*
-Copyright @copyright{} 2019 Diego Nicola Barbato@*
+Copyright @copyright{} 2019, 2020 Diego Nicola Barbato@*
 Copyright @copyright{} 2019 Ivan Petkov@*
 Copyright @copyright{} 2019 Jakob L. Kreuze@*
 Copyright @copyright{} 2019 Kyle Andrews@*
@@ -16288,6 +16288,13 @@ This is the type for the  @uref{https://www.pulseaudio.org/, PulseAudio}
 sound server.  It exists to allow system overrides of the default settings
 via @code{pulseaudio-configuration}, see below.
 
+@quotation Warning
+This service overrides per-user configuration files.  If you want
+PulseAudio to honor configuraton files in @file{~/.config/pulse} you
+have to unset the environment variables @code{PULSE_CONFIG} and
+@code{PULSE_CLIENTCONFIG} in your @file{~/.bash_profile}.
+@end quotation
+
 @quotation Warning
 This service on its own does not ensure, that the @code{pulseaudio} package
 exists on your machine.  It merely adds configuration files for it, as
-- 
2.26.0

bug#40899: Locales not set up correctly

[Matthew Kraai]

On Tue, Apr 28, 2020 at 11:15:58AM +0200, zimoun wrote:
> Is 'admin' the regular user or another name for the 'root' account?
> 
> On the Debian foreign distro, for GUIX_LOCPATH, I have:
> 
>  - root account: /root/.guix-profile/lib/local
>  - regular user: /home/kikoo/.guix-profile/lib/locale

'admin' is the regular user.

I think the problem is that LANG is set to 'C.UTF-8' by default.  If I
change the contents of /etc/default/locale from

LANG=C.UTF-8

to

LANG=en_US.UTF-8

I no longer see the error installing nss-certs.

-- 
Matthew Kraai

bug#40899: Locales not set up correctly

[zimoun]

On Tue, 28 Apr 2020 at 12:59, Matthew Kraai  wrote:


> I think the problem is that LANG is set to 'C.UTF-8' by default.  If I
> change the contents of /etc/default/locale from
>
> LANG=C.UTF-8
>
> to
>
> LANG=en_US.UTF-8

Ah yes. :-)


So closing.

bug#40929: go-sctp build failure: "protocol not supported"

[Josh Holland]

Hi,

I was trying to install docker, which has go-sctp as a dependency.
However, it fails to build, with the following output:

$ guix build go-sctp
The following derivation will be built:
   /gnu/store/bc4sd2819gmy22dda1nhd179cacw7ny6-go-sctp-0.0.0-1.07191f8.drv
building 
/gnu/store/bc4sd2819gmy22dda1nhd179cacw7ny6-go-sctp-0.0.0-1.07191f8.drv...
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/bin:/gnu/store/cnqpra8vr2l5fz00rr4yj4bp3hr00cfw-tar-1.32/bin:/gnu/store/py3k9zla9fj3z7430v4crqj5pyrsd3qj-gzip-1.10/bin:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/bin:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/bin:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/bin:/gnu/store/58sq8iabw3jkv0fvf95hd7sq2g4xcsnz-diffutils-3.7/bin:/gnu/store/v76scv4n63ip08g119rczh2mrw31zwpd-patch-2.7.6/bin:/gnu/store/g9d3wv1d68iflx57yp3mcp3k3sv8spsl-findutils-4.6.0/bin:/gnu/store/2z9hsww76aag37p40671l9niq5pvvasx-gawk-5.0.1/bin:/gnu/store/afmvfw1yhfal48n1kjq6bk6kcw8sc3db-sed-4.7/bin:/gnu/store/7iyvxhp2g3v3655zqwr6biz2h0lqv7pr-grep-3.3/bin:/gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin:/gnu/store/b5vpfzkr59bpgcsg1k9vvad9h5rwvpgk-make-4.2.1/bin:/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin:/gnu/store/nc5vlidpxbvngalng30nif8nb3j7gfy2-ld-wrapper-0/bin:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32/bin:/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/bin:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/sbin'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `CPATH' set to 
`/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/include:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/include:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/include:/gnu/store/2z9hsww76aag37p40671l9niq5pvvasx-gawk-5.0.1/include:/gnu/store/b5vpfzkr59bpgcsg1k9vvad9h5rwvpgk-make-4.2.1/include:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32/include:/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include:/gnu/store/7czrqpi0kwazras6pgyx0bhdn89pg0jl-linux-libre-headers-4.19.56/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/lib:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/lib:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/lib:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/lib:/gnu/store/2z9hsww76aag37p40671l9niq5pvvasx-gawk-5.0.1/lib:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32/lib:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/qky1x5bb2jygy58bn6y95ygfsmpakf52-glibc-2.29-static/lib:/gnu/store/mmqp1xqffn6qw6v88i627c2bpbq36fcy-glibc-utf8-locales-2.29/lib'
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/mmqp1xqffn6qw6v88i627c2bpbq36fcy-glibc-utf8-locales-2.29/lib/locale'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase `setup-go-environment'
phase `setup-go-environment' succeeded after 0.0 seconds
starting phase `unpack'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/.gitignore'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/.gitignore'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/.travis.yml'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/.travis.yml'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/README.md'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/README.md'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/sctp.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/sctp.go'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/sctp_linux.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/sctp_linux.go'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/sctp_streams_test.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/sctp_streams_test.go'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/sctp_test.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/sctp_test.go'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/sctp_unsupported.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/sctp_unsupported.go'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.0719

bug#25484: Closing #25484?

[Marius Bakke]

Brice Waegeneire  writes:

> Hello Guix,
>
> I think this 3 year old bug is fixed, even though Ricardo's patch wasn't
> applied. I can't find any “may conflict with “ in the build log of a 
> recent
> build of qemu[0] and qemu now depends on 'libjpeg-turbo' instead of
> 'libjpeg' since 513885b54e5a6abd46cb02b04ebab51b879150c0.
>
> Should we close this issue?

Indeed.  On the 'core-updates' branch, _all_ packages are now using
exclusively libjpeg-turbo.


signature.asc
Description: PGP signature

bug#40405: System log files are world readable

[Diego Nicola Barbato]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> Diego Nicola Barbato  skribis:
>>
From 43c9ded791ce5b480504ce3528ee34578168f90e Mon Sep 17 00:00:00 2001
>>> From: Diego Nicola Barbato 
>>> Date: Tue, 7 Apr 2020 13:58:28 +0200
>>> Subject: [PATCH 1/2] service: Create log files as non-world-readable.
>>>
>>> * modules/shepherd/service.scm (exec-command): Create log-file with file
>>>   permissions #o640.
>>
>> [...]
>>
From e491436967a912e6e7372f582b3bf5c9784b8209 Mon Sep 17 00:00:00 2001
>>> From: Diego Nicola Barbato 
>>> Date: Tue, 7 Apr 2020 13:38:47 +0200
>>> Subject: [PATCH 2/2] service: Add #:file-creation-mask to
>>>  'make-forkexec-constructor'.
>>>
>>> * modules/shepherd/service.scm (exec-command): Add #:file-creation-mask
>>>   parameter and honor it.
>>>   (fork+exec-command): Add #:file-creation-mask parameter and pass it to
>>>   exec-command.
>>>   (make-forkexec-constructor): Add #:file-creation-mask parameter and pass 
>>> it
>>>   to fork+exec-command.
>>> * doc/shepherd.texi (Service De- and Constructors): Adjust accordingly.
>>
>> I went ahead and pushed these two patches.
>
> These patches are in Shepherd 0.8.0, which was pushed in Guix master
> commit e3358a831e7d5d9e8dc614340e49ea5aeb11a7ff, so we’re done!

Great!  Now we can simplify the 'start' method of
'syslogd-service-type'.

I did eventually write a test script, which I've attached in case we
want to add it to the Shepherd.  I'm sorry it took so long that I missed
the new Shepherd release.

Regards,

Diego

>From 2e7a0795b3a7080376238ab604c50d2c180f8730 Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato 
Date: Mon, 27 Apr 2020 16:57:36 +0200
Subject: [PATCH] tests: Test #:file-creation-mask option of
 'make-forkexec-constructor'.

* tests/file-creation-mask.sh: New file.
---
 tests/file-creation-mask.sh | 79 +
 1 file changed, 79 insertions(+)
 create mode 100644 tests/file-creation-mask.sh

diff --git a/tests/file-creation-mask.sh b/tests/file-creation-mask.sh
new file mode 100644
index 000..9f5f10a
--- /dev/null
+++ b/tests/file-creation-mask.sh
@@ -0,0 +1,79 @@
+# GNU Shepherd --- Test the #:file-creation-mask option of 'make-forkexec-constructor'.
+# Copyright © 2020 Diego N. Barbato 
+#
+# This file is part of the GNU Shepherd.
+#
+# The GNU Shepherd 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.
+#
+# The GNU Shepherd 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 the GNU Shepherd.  If not, see .
+
+shepherd --version
+herd --version
+
+socket="t-socket-$$"
+conf="t-conf-$$"
+log="t-log-$$"
+pid="t-pid-$$"
+service_log="t-service-log-$$"
+service_new_file="t-service-new-file-$$"
+
+herd="herd -s $socket"
+
+trap "cat $log || true;
+  rm -f $socket $conf $log $service_log $service_new_file;
+  test -f $pid && kill \`cat $pid\` || true; rm -f $pid" EXIT
+
+function wait_for_file
+{
+i=0
+while ! test -f "$1" && test $i -lt 20
+do
+	sleep 0.3
+	i=`expr $i + 1`
+done
+test -f "$1"
+}
+
+cat > "$conf"<
+   #:provides '(test)
+   #:start (make-forkexec-constructor %command
+  #:log-file "$PWD/$service_log"
+  ;; Set the umask such that file
+  ;; permissions are #o600.
+  #:file-creation-mask #o177)
+   #:stop (make-kill-destructor)
+   #:respawn? #f))
+EOF
+
+rm -f "$pid"
+shepherd -I -s "$socket" -c "$conf" -l "$log" --pid="$pid" &
+
+# Wait till it's ready.
+wait_for_file "$pid"
+
+# Start the service.
+$herd start test
+
+# Make sure the log file is created with the right permissions independently
+# of the value of #:file-creation-mask.
+wait_for_file "$service_log"
+test `stat -c %a "$service_log"` -eq 640
+
+# Make sure the service creates files with the right permissions as determined
+# by the value of #:file-creation-mask.
+wait_for_file "$service_new_file"
+test `stat -c %a "$service_new_file"` -eq 600
-- 
2.26.0

bug#35574: bcm5974 touchpad is not recognized as touchpad

[Brice Waegeneire]

Hello Florian,

On 2020-04-28 09:45, pelzflorian (Florian Pelz) wrote:

Danny, Brice, I’m putting you in Cc, maybe you have an opinion on
this?  I suppose I should not change %default-extra-linux-options.


Keeping this module enabled in the kernel seems a good idea, it allows
support for mice solely speaking Human Interface Device Boot Protocol
(HIDBP); probably somebody somewhere is unwittingly relying on it being
present by default in Guix.


From the Linux kernel docs
:

5.2. USB Race

The Apple multi-touch trackpads report both mouse and keyboard events
via different interfaces of the same usb device. This creates a race
condition with the HID driver, which, if not told otherwise, will find
the standard HID mouse and keyboard, and claim the whole device. To
remedy, the usb product id must be listed in the mouse_ignore list of
the hid driver.

Indeed for me on good boots, the command `lsusb -t` prints
|__ Port 3: Dev 2, If 2, Class=Human Interface Device, 
Driver=bcm5974, 12M

while on bad boots it says Driver=usbmouse.

But why that happens I do not know, because the mouse_ignore list in
the Linux-libre kernel’s drivers/hid/hid-quirks.c file does list my
touchpad.  Strange.  I will investigate further if a change to the
kernel config could help.


FWI the issue span from the driver 'usbmouse'
(drivers/hid/usbhid/usbmouse.c) which doesn't use 
drivers/hid/hid-quirks.c

contrary to 'usbhid' (drivers/hid/usbhid/hid-core.c) which is using it.
This is probably why you did not report having an issue with 'usbhid'
racing with 'bcm597'; 'usbhid' is effectively prevented to take over 
your

touchpad by the quirks while 'usbmouse' isn't aware of it.

Passing arguments to the kernel to blacklist a module is the correct way 
of

doing this currently FWIU; it's already used in gnu/system/install.scm.

Cheers,
- Brice

bug#40828: core-updates: guix system reconfigure error: guix-1.1.0-1.7dd0539.drv failed

[Marius Bakke]

sirgazil  writes:

>  > Is this error repeatable for you?  Guix built fine on the CI:
>
> No. It worked this time, although I skipped step 2. I don't know if that 
> could make any difference.

It should not have made a difference.

I doubt we'll find out what went wrong, so closing the issue.  Thanks!


signature.asc
Description: PGP signature

bug#40872: First installed package on guix system is not instantly usable

[Marius Bakke]

Stefan  writes:

> Hi!
>
> I have a guix system and my user account has no package installed yet. After 
> installing the first package – git-minimal in my case – this message is 
> printed and I get this error when trying to use the new command:
>
> building profile with 1 package...
> Hinweis: Vielleicht möchten Sie die nötigen Umgebungsvariablen festlegen, 
> indem Sie dies ausführen:
>
>  GUIX_PROFILE="/home/stefan/.guix-profile"
>  . "$GUIX_PROFILE/etc/profile"
>
> Sie können sie auch mit `guix package --search-paths -p 
> "/home/stefan/.guix-profile"' nachlesen.
>
> stefan@guix ~$ git show
> -bash: git: Kommando nicht gefunden.
>
>
> The problem is that without a single package installed there is no user 
> profile-link present:
>
>
> stefan@guix ~$ echo $PATH
> /run/setuid-programs:/home/stefan/.config/guix/current/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin

This is odd, as /etc/profile contains a workaround for this exact
problem (notice the else clause):

# Arrange so that ~/.config/guix/current comes first.
for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
do
  if [ -f "$profile/etc/profile" ]
  then
# Load the user profile's settings.
GUIX_PROFILE="$profile" ; \
. "$profile/etc/profile"
  else
# At least define this one so that basic things just work
# when the user installs their first package.
export PATH="$profile/bin:$PATH"
  fi
done

Can you investigate why this is ineffective on your system?


signature.asc
Description: PGP signature

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

[Jack Hill]

After further discussion on the Bubblewrap issue [0], it was determined 
that the problem should be fixed by having WebKitGTK canonicalize paths 
before passing them to bwrap. There is now a WebKit issue for that fix [1].


[0] https://github.com/containers/bubblewrap/issues/195
[1] https://bugs.webkit.org/show_bug.cgi?id=211131

When the WebKit issue is fixed, that should solve the problem with 
/etc/pulse/client.conf. I believe that we will still have work to do in 
Guix to make sure the store is available inside the sandbox.


Best,
Jack

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

[sirgazil via Bug reports for GNU Guix]

  On Tue, 28 Apr 2020 23:27:57 + Jack Hill  wrote 

 > After further discussion on the Bubblewrap issue [0], it was determined 
 > that the problem should be fixed by having WebKitGTK canonicalize paths 
 > before passing them to bwrap. There is now a WebKit issue for that fix [1].
 > 
 > [0] https://github.com/containers/bubblewrap/issues/195
 > [1] https://bugs.webkit.org/show_bug.cgi?id=211131
 > 
 > When the WebKit issue is fixed, that should solve the problem with 
 > /etc/pulse/client.conf. I believe that we will still have work to do in 
 > Guix to make sure the store is available inside the sandbox.


Thanks for working on this, Jack.

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hello Mathieu!

> I had a look to (gnu system hurd), this is really nice! I think we could
> try an explosive mixture of our two branches :)

Sure, why not? ;-) I played a bit yesterday with wip-disk-image.  Not
that (gnu system hurd) already lives on core-updates; possibly we can
start playing there?  I tried rebasing wip-disk-image on core-updates
and that was (almost?) painless.

> More seriously, we could do something like:
>
> (define hurd-disk-image
>   (image
>(format 'disk-image)
>(partitions
> (list
>  (partition
>   (size 'guess)
>   (label "Guix_image")
>   (file-system "ext2")
>   (flags '(boot))
>   (initializer (gexp initialize-hurd-root-partition)))

Sweet!

> then we could have some mapping in guix/scripts/system.scm to
> associate:
>
> * x86_64-linux -> efi-disk-image
> * i586-pc-gnu -> hurd-disk-image
>
> and one could get a hurd disk-image by typing: 
>
> guix system disk-image --target=i586-pc-gnu my-hurd-os.scm

Oh, that sounds real great.

> One problem that can arise is the installation of grub. Currently
> wip-disk-image does not support legacy Grub (MBR based)
> installation.
>
> This is because running grub-install needs root permissions, to mess with
> /dev/something in order to write the MBR I guess.

Hmm...so we need to do some work, is that bad?

> We could also create a Hurd ISO if grub-mkrescue (that is used to make
> the ISO bootable), supports the Hurd.
>
> Adding Ludo that might have some insight here.

Hopefully -- this is also pretty out of my comfort zone, otoh I am
very motivated to get this going. :-)

I have been wondering about the branch name in combination with its
functionality: can/will/could "wip-disk-image" also be used for
guix system init/reconfigure (we don't have qemu on the Hurd)?

Greetings,
janneke

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

bug#40945: Rottlog service should create filenames with a '.gz' extension

[Leo Famulari]

Currently, the rottlog service in %base-services creates old rotated
logs that are named like "messages.1", "messages.2", etc.

However, these files are compressed with gzip, and gzip refuses to
decompress them until you add '.gz' to the end of the filenames.

I think this should be happening by default but for some reason is
not. rottlog-configuration uses as the default configuration
(file-append rottlog "/etc/rc"), and that file does call for this
extension to be added...

bug#40893: import crate: Recursive importer loops

[Leo Famulari]

On Mon, Apr 27, 2020 at 09:12:44AM +0200, Hartmut Goebel wrote:
> When running "import crate -r", the same packages get downloaded again
> and again. Depending on the package to be imported, this looping can
> take quite some time and the user gets the impression, that the import
> will recurse endlessly.

Is this for the crate importer currently on Guix master, or the new
importer being developed by Martin Becze at
?

bug#40912: [BUG] GUI installer loops when using a NVME drive

[K I]

Hello Mathieu,

I can confirm that it works. Thank you.

On Tue, 28 Apr 2020 09:25:07 +0200, Mathieu Othacehe  
wrote:

> 
> Hello Kozo,
> 
> > Did some troubleshooting with Civodul. Submitting the message log that
> > helped him determine it was a NVME issue.
> 
> I guess you used the 1.1.0 release? This bug should be resolved on
> master. Do you have the possibility to build a new ISO image?
> 
> You can run this command as explained here[1]:
> 
> --8<---cut here---start->8---
> guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
> --8<---cut here---end--->8---
> 
> Thanks,
> 
> Mathieu
> 
> [1]: 
> https://guix.gnu.org/manual/en/html_node/Building-the-Installation-Image.html#Building-the-Installation-Image

bug#39406: emacs-telega on 32bit - "Emacs with wide ints (--with-wide-int) is required"

[Diego Nicola Barbato]

Hi,

This bug has been fixed in a663b7040c3c7ed12d4f673c4ac090ad8d9b8e20.
See https://debbugs.gnu.org/39412 for more details.

Please note that for emacs-telega to work on 32-bit systems (i686,
armhf) it needs to be installed alongside emacs-wide-int instead of
emacs.

Regards,

Diego

bug#40544: Pulseaudio is not looking for user configuration

[Ludovic Courtès]

Hi Diego,

Diego Nicola Barbato  skribis:

>>> That's a known [0] (but AFAIK undocumented) side effect of the
>>> PulseAudio service, which was added to %desktop-services in January [1].
>>> If you want PulseAudio to read your user configuration files you'll have
>>> to remove that service from your system services or unset PULSE_CONFIG
>>> and PULSE_CLIENT_CONFIG in ~/.profile [2].
>>
>> It would be good to document that, right below
>> ‘pulseaudio-service-type’.  Would you like to give it a try, Diego?
>
> I've attached a patch, which adds a warning to the documentation.
>
>> Or alternately, is there a way we can arrange so that the user’s config
>> takes precedence over /etc/pulse?
>
> We can't configure PulseAudio with "--sysconfdir=/etc" because it would
> break without the service (e.g. on foreign distributions).[0]

OK.

> We could patch PulseAudio to make the sysconfdir configurable at runtime
> using an environment variable.  The service could set this environment
> variable to /etc instead of setting ‘PULSE_CONFIG’ and
> ‘PULSE_CLIENT_CONFIG’.  That way the user's config would take precedence
> over /etc/pulse (PulseAudio's normal behaviour).  Without the service
> (and with the environment variable unset) it would fall back to the
> sysconfdir configured at build time so it wouldn't break on foreign
> distributions.  Although I doubt that the slight improvement in user
> experience would justify the increased maintenance burden.

Yeah, plus I’d rather use existing mechanism than patch PulseAudio.

But anyway, we can revisit this later if documenting the issue turns out
to be insufficient.

> From a33a10102f555454d9025b0693edf8d539f6a7af Mon Sep 17 00:00:00 2001
> From: Diego Nicola Barbato 
> Date: Sat, 25 Apr 2020 11:32:07 +0200
> Subject: [PATCH] doc: Mention that PulseAudio service overrides user
>  configuration.
>
> * doc/guix.texi (Sound Services): Add a warning that 'pulseaudio-service-type'
>   overrides per-user configuration files in '~/.config/pulse'.

Applied, thank you!

Ludo’.

bug#25484: Closing #25484?

[Ludovic Courtès]

Hi,

Brice Waegeneire  skribis:

> I think this 3 year old bug is fixed, even though Ricardo's patch wasn't
> applied. I can't find any “may conflict with “ in the build log of a
> recent
> build of qemu[0] and qemu now depends on 'libjpeg-turbo' instead of
> 'libjpeg' since 513885b54e5a6abd46cb02b04ebab51b879150c0.
>
> Should we close this issue?

Yup, done with this message.

Thanks for helping out with bug triage!

Ludo’.

bug#40405: System log files are world readable

[Ludovic Courtès]

Hello,

Diego Nicola Barbato  skribis:

> Great!  Now we can simplify the 'start' method of
> 'syslogd-service-type'.

Oh right, do you want to take care of it?

> I did eventually write a test script, which I've attached in case we
> want to add it to the Shepherd.  I'm sorry it took so long that I missed
> the new Shepherd release.

No problem.  I figured it was okay to add it without a test, but having
a test is always better so I’ve happily pushed your patch.  Thank you!

Ludo’.

bug#40872: First installed package on guix system is not instantly usable

[Stefan]

Hi Marius!

> This is odd, as /etc/profile contains a workaround for this exact
> problem (notice the else clause):
> 
> # Arrange so that ~/.config/guix/current comes first.
> for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
> do
>  if [ -f "$profile/etc/profile" ]
>  then
># Load the user profile's settings.
>GUIX_PROFILE="$profile" ; \
>. "$profile/etc/profile"
>  else
># At least define this one so that basic things just work
># when the user installs their first package.
>export PATH="$profile/bin:$PATH"
>  fi
> done
> 
> Can you investigate why this is ineffective on your system?

Previously I had some packages installed, but I rolled-back to generation 0. I 
found this in my scroll-back buffer:

stefan@guix ~/development/guix$ guix package --roll-back
Folgende Ableitung wird erstellt:
   /gnu/store/l0n6l104ldj7nz6kdyi7l8v5yjnc9p9g-profile.drv
building profile with 0 packages...
Von Generation „1“ zu „0“ gewechselt

By rolling back it created a new generation 0 profile which is now lying around 
with this kind of empty file: 

stefan@guix ~$ cat .guix-profile/etc/profile 
# Source this file to define all the relevant environment variables in Bash
# for this profile.  You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
#  GUIX_PROFILE=/path/to/profile ; \
#  source /path/to/profile/etc/profile
#
# When GUIX_PROFILE is undefined, the various environment variables refer
# to this specific profile generation.

So the test for the existence of this file does not fail, but it doesn't change 
PATH either. This is the profile content, it has no bin/ folder to add to PATH:

stefan@guix ~$ ls -lA /gnu/store/yyxqc1rhz2i062xq8lbfrhhmiyf6pzvp-profile
insgesamt 12
dr-xr-xr-x 2 root root 4096  1. Jan 1970  etc/
-r--r--r-- 4 root root   37  1. Jan 1970  manifest


Bye

Stefan

bug#40832: Audacity does not work with PulseAudio

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> When Audacity starts, it prints this line:
>
> --
> ALSA lib conf.c:3683:(snd_config_hooks_call) Cannot open shared library 
> libasound_module_conf_pulse.so 
> (/gnu/store/nyylgcnzmbw8wrn4sna2crl0g7zxxh33-alsa-lib-1.2.2/lib/alsa-lib/libasound_module_conf_pulse.so:
>  libasound_module_conf_pulse.so: cannot open shared object file: No such file 
> or directory)
> --
>
> But, this file exists in the "pulseaudio" output of alsa-plugins, not
> alsa-lib:
>
> /gnu/store/pwsz9hf66na0s9x3ay9qk02vk8l4v8vi-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_conf_pulse.so

Could it be that the problem is in Audacity and not in alsa-lib?

I can do this with mpg123:

--8<---cut here---start->8---
$ cat ~/.asoundrc
pcm.!default {
type pulse
}
$ mpg123 -o alsa …
--8<---cut here---end--->8---

and the sound goes through PulseAudio.

Ludo’.

bug#40832: Audacity does not work with PulseAudio

[Leo Famulari]

On Tue, Apr 28, 2020 at 11:25:32PM +0200, Ludovic Courtès wrote:
> Could it be that the problem is in Audacity and not in alsa-lib?

I'm not 100% sure but I don't think so.

The function snd_config_hooks_call() is from alsa-lib I can't find any
way in alsa-lib for it work in this case, even though it aims to work by
default on systems with plugins in '/usr/lib/alsa-lib' or similar.

The lookup is performed in alsa-lib's 'src/dlmisc.c', by the function
snd_dlopen(), and it only looks in the hard-coded path provided by the
ALSA_PLUGIN_DIR C object macro, which ends up being alsa-lib's own store
directory.

> I can do this with mpg123:
> 
> --8<---cut here---start->8---
> $ cat ~/.asoundrc
> pcm.!default {
> type pulse
> }
> $ mpg123 -o alsa …
> --8<---cut here---end--->8---
> 
> and the sound goes through PulseAudio.

Is that on Guix System or another distro? On Guix System, this is
handled by the service alsa-service-type.

On Debian, using mpg123 from Guix, and with your ~/.asoundrc, it fails
in the same way as Audacity:

--
% mpg123 -o alsa ...
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.13; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
ALSA lib conf.c:3683:(snd_config_hooks_call) Cannot open shared library 
libasound_module_conf_pulse.so 
(/gnu/store/nyylgcnzmbw8wrn4sna2crl0g7zxxh33-alsa-lib-1.2.2/lib/alsa-lib/libasound_module_conf_pulse.so:
 libasound_module_conf_pulse.so: cannot open shared object file: No such file 
or directory)
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default
[src/libout123/modules/alsa.c:181] error: cannot open device default
[src/libout123/libout123.c:455] error: Found no driver out of [alsa] working 
with device .
main: [src/mpg123.c:314] error: out123 error 3: failure loading driver module
--

bug#40952: gnuradio-osmosdr: no hook into gnuradio block directory?

[Christopher Howard]

Hi, I installed gnuradio and gnuradio-osmosdr, but when I open
gnuradio, none of the osmosdr blocks are available from gnuradio blocks
list. Specifically, I was looking for osmosdr source block, which I am
familiar with from using gnuradio under Debian. I believe the problem
is that the osmosdr blocks are not in the directory where gnuradio-
companion is looking for blocks.

When starting up gnuradio-companion, stdout indicates grc is looking for blocks 
here:

/gnu/store/h2igg2gcbx6ds8wbvlkqz0dkplvwjxbd-gnuradio-3.8.0.0/share/gnuradio/grc/blocks

But osmosdr blocks are in 

/gnu/store/ppb504vizb32f4w2s5f0yd6i4xpy41nz-gnuradio-osmosdr-0.2.0/share/gnuradio/grc/blocks/

Evidentally gnuradio package needs to be enhanced to create a per-
profile merged directory from all gnuradio- block packages that are
installed. Unless there is some way to extend the gnuradio search path
through environment variables.

-- 
Christopher Howard
p: +1 (907) 374-0257
w: https://librehacker.com
social: https://gnusocial.club/librehacker
gpg: ADDEAADE5D607C8D (keys.gnupg.net)