bug#47641: Ongoing difficulities after linphoneqt -> linphone-desktop transition

2021-04-21 Thread Raghav Gururajan via Bug reports for GNU Guix

Hi Christopher and Maxim,


Hi, I've been having difficulties since the the recent linphone
updates. I know some work has been done on the package in recent
commits, so just a few minutes ago I ran

guix time-machine -- environment --ad-hoc linphone-desktop

christopher@theoden ~ [env]$ guix describe
Generation 14   Apr 01 2021 13:21:37(current)
   guix 079a7f2
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: 079a7f2c65c51da7b53b0e5ef44c516dc8eaab6e

The two problems I get running the program are:

(1) I get non-descript error icons when I send messages to contacts
(though the messages seem to get through)

(2) old messages do not appear when I start the application

(3) messages from others appear in notifications window but not in the
app screen

(4) sometimes get a segfault upon replying to a message


Thanks for the report.

Would you be able to help me with the testing, by test-messaging me over 
linphone, so that I can try some fixes? My address is raghavgururajan at 
sip.linphone.org



Hmm, it seems the problem strictly has to do with messaging?  That would
explain how my testing of the application failed to reveal it as I don't
currently used that feature (I use it for SIP calls only).


Same here.


Is someone else equipped and able to reproduce it?  Perhaps Raghav
(CC'd)?


I'll try to fix it.

Regards,
RG.



OpenPGP_signature
Description: OpenPGP digital signature


bug#47935: coreutils: tests/tail-2/inotify-dir-recreate.sh fails on overlayfs

2021-04-21 Thread Carl Dong
Upstream bug filed: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47940





bug#45280: qutebrowser has no audio

2021-04-21 Thread bdju
Here's some output when I launch qutebrowser from a terminal. It seems
like it may be using ALSA instead of pulse for some reason.
```
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
[14812:14812:0421/184051.727290:ERROR:alsa_util.cc(204)] PcmOpen:
default,No such file or directory
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
[14812:14812:0421/184051.728902:ERROR:alsa_util.cc(204)] PcmOpen:
plug:default,No such file or directory
[14656:13:0421/184058.289956:ERROR:batching_media_log.cc(38)]
MediaEvent: {"error":"FFmpegDemuxer: no supported streams"}
[14656:1:0421/184058.290464:ERROR:batching_media_log.cc(35)] MediaEvent:
{"pipeline_error":14}
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
[14812:14812:0421/184144.908489:ERROR:alsa_util.cc(204)] PcmOpen:
default,No such file or directory
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
[14812:14812:0421/184144.911093:ERROR:alsa_util.cc(204)] PcmOpen:
plug:default,No such file or directory
```





bug#42861: emacspeak won't shut up about TTS sync states

2021-04-21 Thread Nicolas Goaziou
Hello,

Kei Kebreau  writes:

> I've pushed the patch as-is to master.

Thank you.

> I was If you are able to provide a method to replicate the issues you
> speak of here, please message me and we can open a bug report.

OK noted.

Regards,
-- 
Nicolas Goaziou





bug#44675: guix lint: support for spellchecker or basic grammar

2021-04-21 Thread Vagrant Cascadian
Control: tags 44675 +patch

On 2020-11-15, Vagrant Cascadian wrote:
> Please consider a guix lint description/synopsis check for basic
> spelling, typo and rudimentary grammar issues.
...
> Many of these are likely to be caught by most spell checking routines;
> I'm not sure if there is anything that would be implementable in pure
> guile, or it if would make sense to call out to an external
> spellchecker.
>
> Some of them might be harder, and obviously we do not want too many
> false positives, but no need to get perfectionist on solving this; even
> just checking for "This packages" would haved detected many of these
> issues!

In the attached patch, I've implemented a simple lint check for "This
packages", which has been fixed in ... 42 packages so far in the git
repository, so maybe this could help catch future ones!

I haven't implemented a more complicated spellchecker or grammar checker
or anything, but at least this is a start.

I think it is also within my skills to address "allows to" and "permits
to", if I'm not heading down the wrong path here...


live well,
  vagrant

From d4b851f5722cd6f8d514a4254884d1f7a016b74f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 21 Apr 2021 09:26:45 -0700
Subject: [PATCH] lint: Add description check for check-pluralized-package

Fixes: https://issues.guix.gnu.org/44675

* guix/lint.scm: Check for occurances of "This packages" in package
  descriptions.
* tests/lint.scm: Add test.
---
 guix/lint.scm  | 9 +
 tests/lint.scm | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/guix/lint.scm b/guix/lint.scm
index 1bebfe03d3..ffeac18077 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -221,6 +221,14 @@ markup is valid return a plain-text version of DESCRIPTION, otherwise #f."
   (G_ "Texinfo markup in description is invalid")
   #:field 'description
 
+  (define (check-pluralized-this-package description)
+"Check that DESCRIPTION does not contain This packages"
+(if (string-match "This packages" description)
+	(list
+	 (make-warning package
+		   (G_ "description contains This Packages but should just be This package")))
+	'()))
+
   (define (check-trademarks description)
 "Check that DESCRIPTION does not contain '™' or '®' characters.  See
 http://www.gnu.org/prep/standards/html_node/Trademarks.html.;
@@ -283,6 +291,7 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
  (check-not-empty description)
  (check-quotes description)
  (check-trademarks description)
+ (check-pluralized-this-package description)
  ;; Use raw description for this because Texinfo rendering
  ;; automatically fixes end of sentence space.
  (check-end-of-sentence-space description)
diff --git a/tests/lint.scm b/tests/lint.scm
index a2c8665142..6cb7a98686 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -160,6 +160,13 @@
  (description "This is a 'quoted' thing."
  (check-description-style pkg
 
+(test-equal "description: pluralized this package"
+  "description contains This Packages but should just be This package"
+  (single-lint-warning-message
+   (let ((pkg (dummy-package "x"
+ (description "This packages is a typo."
+ (check-description-style pkg
+
 (test-equal "synopsis: not a string"
   "invalid synopsis: #f"
   (single-lint-warning-message
-- 
2.30.2



signature.asc
Description: PGP signature


bug#47941: guix lint -c cve stacktrace

2021-04-21 Thread Ludovic Courtès
Hi,

Jack Hill  skribis:

> Using guix ae5128e21eb7afa66bd7cfd7fd1bc5764d00663e, the cve lint
> check fails when fetching the CVE database as follows:
>
> $ guix lint -c cve hello
> fetching CVE database for 2021...
> Backtrace:
>   15 (primitive-load "/home/jackhill/.config/guix/current/bi…")
> In guix/ui.scm:
>   2164:12 14 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>   1731:15 12 (with-exception-handler # …)
> In srfi/srfi-1.scm:
> 634:9 11 (for-each # …)
> In guix/scripts/lint.scm:
>  65:4 10 (run-checkers _ _ #:store _)
> In srfi/srfi-1.scm:
> 634:9  9 (for-each # …)
> In guix/scripts/lint.scm:
> 74:21  8 (_ _)
> In guix/lint.scm:
>1178:4  7 (check-vulnerabilities _ _)
>1170:9  6 (_ _)
> In unknown file:
>5 (force #)
> In guix/lint.scm:
>1153:2  4 (_)
>1112:2  3 (call-with-networking-fail-safe _ _ _)
> In ice-9/boot-9.scm:
>   1736:10  2 (with-exception-handler _ _ #:unwind? _ # _)
>   1669:16  1 (raise-exception _ #:continuable? _)
>   1667:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1667:16: In procedure raise-exception:
> Wrong type (expecting array): #f

Fixed:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7dbc2fcb45fac4a0b64fef8efa8c858a047d0498

It looks like a couple of bogus CVE entries crept in.  It’s surprising
because we never encountered such issues before, so I wonder if MITRE
changed something on their side.

Thanks,
Ludo’.





bug#42861: emacspeak won't shut up about TTS sync states

2021-04-21 Thread Kei Kebreau

On 4/2/21 10:44 AM, Nicolas Goaziou wrote:

Hello,

Kei  writes:


How are you able to tell (aside from looking at the command line arguments)?
I'm unable to distinguish the startup processes using Emacs on Debian and Guix
even if I install "etc/emacspeak.sh" as the startup script instead of
"run".

On Debian, the voice kicks in after all the initial minibuffer
information is displayed, i.e., it starts when it is actually ready. On
Guix, see below.


Here, the package spells out all configuration messages displayed on
in the minibuffer.


Unless I'm misunderstanding you, Emacspeak seems to do the same for me on
Debian.  For example, it reads "Active processes exist?..." and so on when
exiting.  Is this not proper behavior?

It is, but I am speaking at the initial messages, when you start a fresh
Emacs session.

Regards,


I've pushed the patch as-is to master. If you are able to provide a 
method to replicate the issues you speak of here, please message me and 
we can open a bug report.



Thanks,

Kei Kebreau






bug#47941: guix lint -c cve stacktrace

2021-04-21 Thread Jack Hill

Hi Guix,

Using guix ae5128e21eb7afa66bd7cfd7fd1bc5764d00663e, the cve lint check 
fails when fetching the CVE database as follows:


$ guix lint -c cve hello
fetching CVE database for 2021...
Backtrace:
  15 (primitive-load "/home/jackhill/.config/guix/current/bi…")
In guix/ui.scm:
  2164:12 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 12 (with-exception-handler # …)
In srfi/srfi-1.scm:
634:9 11 (for-each # …)
In guix/scripts/lint.scm:
 65:4 10 (run-checkers _ _ #:store _)
In srfi/srfi-1.scm:
634:9  9 (for-each # …)
In guix/scripts/lint.scm:
74:21  8 (_ _)
In guix/lint.scm:
   1178:4  7 (check-vulnerabilities _ _)
   1170:9  6 (_ _)
In unknown file:
   5 (force #)
In guix/lint.scm:
   1153:2  4 (_)
   1112:2  3 (call-with-networking-fail-safe _ _ _)
In ice-9/boot-9.scm:
  1736:10  2 (with-exception-handler _ _ #:unwind? _ # _)
  1669:16  1 (raise-exception _ #:continuable? _)
  1667:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1667:16: In procedure raise-exception:
Wrong type (expecting array): #f

Best,
Jack

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

2021-04-21 Thread pelzflorian (Florian Pelz)
Sorry for the slow response.

On Wed, Apr 21, 2021 at 12:38:58AM +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> >> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> > It seems this is the bad commit.  Downloading the enlightenment
> > substitute got stuck and after a few minutes displayed the usual TLS
> > error.
> Note that on master there have been changes in this area since this
> commit, in particular 20c08a8a45d0f137ead7c05e720456b2aea44402.

I have tested 20c08a in my reverts, it is neither the bad commit nor
does it fix it.
> I assume the error we’re after is still this one:
> 
> >>|substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
> >> 0.0%guix substitute: error: TSL error in procedure 
> >> 'write_to_session_port': Resource temporarily unavailable, try again.

Yes.

> I believe the attached patch “addresses” this problem.

It still gets stuck (sometimes with enlightenment, one time with
udisks, restarting the install fixed it once).  After getting stuck,
this different error message is shown now; no TLS error (copied by
manual typing, there may be typos):

gtk-doc-1.28  653KiB2.4MiB/s 00:00 [] 100.0%
udisks-2.8.4  842KiB1.6MiB/s 00:00 [] 100.0%

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1736:10 17 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   16 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 718:2 15 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 14 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:   2164:12 13 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1736:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1731:15 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:745:18  9 (_)
substitute:346:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:358:27  7 (lookup-narinfos/diverse _ _ #
substitute:315:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
substitute:238:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1669:16  4 (raise-exception _ #:continuable? _)
substitute:   1669:16  3 (raise-exception _ #:continuable? _)
substitute:   1764:13  2 (_ #< _ components: 
assertion-fail…>)
substitute:   1669:16  1 (raise-exception _ #:continuable? _)
substitute:   1669:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: In ice-9/boot-9.scm:1669:16 In procedure raise-exception:
substitute: In procedure %read-line: Wrong type argument in position 1 
(expecting open input port): #
guix system: error: 
`/gnu/store/k3n98i1fk9awd5ydv4ry4k4rlpp7i13m7-guix-1.2.0-22.c467718/bin/guix 
substitute' died unexpectedly

Command failed with exit code 1.
Press Enter to continue.

> Can you reproduce the substitute issue in a simpler environment?
> For instance, by running:
> 
>   rm -rf ~/.cache/guix/substitute/
>   ./pre-inst-env guix weather $(guix package -A |head -2000 |cut -f1) 

Nope, this always works without issue.  Ricardo had written about TLS
errors with 0ad some two or three days ago, but I do not get errors
with 0ad.  The issue is present when installing Enlightenment DE from
the installer on both my Macbook and my Beebox every time, but not
when installing to a VM (but maybe it was just luck)

Regards,
Florian





bug#47734: Guix install script on foreign distro fails to add berlin public key

2021-04-21 Thread Ludovic Courtès
Here’s the paste, for posterity:

--8<---cut here---start->8---
This script installs GNU Guix on your system

https://www.gnu.org/software/guix/
Press return to continue...
[1618245319.405]: Starting installation (Mon 12 Apr 2021 12:35:19 PM EDT)
[1618245319.409]: [ PASS ] verification of required commands completed
[1618245319.445]: [ INFO ] init system is: systemd
[1618245319.465]: [ WARN ] We recommend installing and/or starting your 
distribution 'nscd' service
[1618245319.467]: [ WARN ] Please read 'info guix "Application Setup"' about 
"Name Service Switch"
[1618245319.468]: [ INFO ] system is x86_64-linux
[1618245319.593]: [ PASS ] Release for your system: 
guix-binary-1.2.0.x86_64-linux
[1618245319.595]: [ INFO ] Downloading Guix release archive
guix-binary-1.2.0.x86_64-linux.tar.xz   
100%[=>]
  76.00M  68.5MB/sin 1.1s
guix-binary-1.2.0.x86_64-linux.tar.xz.sig   
100%[=>]
 833  --.-KB/sin 0s  
[1618245320.829]: [ PASS ] download completed.
[1618245321.262]: [ PASS ] Signature is valid.
[1618245328.424]: [ PASS ] unpacked archive
[1618245328.426]: [ INFO ] Installing /var/guix and /gnu...
[1618245329.506]: [ INFO ] Linking the root user's profile
[1618245329.516]: [ PASS ] activated root profile at /root/.config/guix/current
[1618245330.001]: [ PASS ] group  created
[1618245330.698]: [ PASS ] user added 
[1618245331.389]: [ PASS ] user added 
[1618245332.274]: [ PASS ] user added 
[1618245332.907]: [ PASS ] user added 
[1618245333.583]: [ PASS ] user added 
[1618245334.203]: [ PASS ] user added 
[1618245334.874]: [ PASS ] user added 
[1618245335.520]: [ PASS ] user added 
[1618245336.215]: [ PASS ] user added 
[1618245336.853]: [ PASS ] user added 
Created symlink /etc/systemd/system/guix-daemon.service.wants/gnu-store.mount → 
/etc/systemd/system/gnu-store.mount.
Created symlink /etc/systemd/system/multi-user.target.wants/guix-daemon.service 
→ /etc/systemd/system/guix-daemon.service.
[1618245337.848]: [ PASS ] enabled Guix daemon via systemd
[1618245337.849]: [ INFO ] making the guix command available to other users
Permit downloading pre-built package binaries from the project's build farm? 
(yes/no) yes
/home/roptat/guix-install.sh: line 445: 
/root/.config/guix/current/share/guix/ci.guix.gnu.org.pub: No such file or 
directory
[1618245340.514]: [ PASS ] installed shell completion
[1618245340.516]: [ INFO ] cleaning up /tmp/guix.ySI
[1618245340.528]: [ PASS ] Guix has successfully been installed!
[1618245340.529]: [ INFO ] Run 'info guix' to read the manual.
[1618245340.530]: [ INFO ] Please log out and back in to complete the 
installation.
--8<---cut here---end--->8---

We see these lines:

  [ INFO ] Installing /var/guix and /gnu...
  [ INFO ] Linking the root user's profile
  [ PASS ] activated root profile at /root/.config/guix/current

which is evidence that ~root/.config/guix/current was created and is not
a dangling symlink.  Further more, the binary tarball does contain that
.pub file:

--8<---cut here---start->8---
$ wget -qO - https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.x86_64-linux.tar.xz 
| xz -d | tar tv | grep '\.pub$'
-r--r--r-- root/root   118 1970-01-01 01:00 
./gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/guix/berlin.guix.gnu.org.pub
-r--r--r-- root/root   118 1970-01-01 01:00 
./gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/guix/ci.guix.gnu.org.pub
-r--r--r-- root/root   118 1970-01-01 01:00 
./gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/guix/ci.guix.info.pub
--8<---cut here---end--->8---

So I don’t see what happened.

Julien, could it be that “something else” removed /root/.config or
/var/guix/profiles while it was running?  Or… any other idea?

Thanks,
Ludo’.





bug#47463: Fixed by 47467

2021-04-21 Thread Ekaitz Zarraga
Empty Message





bug#47463: Blender: Voxel remesher failed to create mesh

2021-04-21 Thread Leo Famulari
On Wed, Apr 21, 2021 at 04:24:18PM +, Ekaitz Zarraga wrote:
> This issue can be closed since: 47467 is merged

Feel free to close it. 

Bugs are closed by sending mail to 





bug#47463: Blender: Voxel remesher failed to create mesh

2021-04-21 Thread Ekaitz Zarraga
This issue can be closed since: 47467 is merged





bug#47428: Problems building the up-to-date "devel" manual for the website

2021-04-21 Thread Leo Famulari
On Fri, Apr 02, 2021 at 11:33:57AM +0200, Mathieu Othacehe wrote:
> 
> > ). Please consider running po4a-updatepo to refresh it.
> > Your input po file ./guix-manual.de.po seems outdated (The amount of 
> > entries differ between files: 10012 is not 325
> > ). Please consider running po4a-updatepo to refresh it.
> > mmap(PROT_NONE) failed
> > builder for 
> > `/gnu/store/86gnwxxw7lfkifaal6fhflmkn3fczyhf-guix-translated-texinfo.drv' 
> > failed due to signal 11 (Segmentation fault)
> 
> I worked around it by building this derivation on one core. Looks like
> the cookbook, website, manual and devel manual are now building fine.

The problem happened again.

How can we make sure this derivation is always single-threaded?





bug#47734: Guix install script on foreign distro fails to add berlin public key

2021-04-21 Thread Julien Lepiller
I can't copy-paste easily to my email client right now, so here's a paste. I'll 
send the content later.

https://paste.debian.net/1194563/

Le 21 avril 2021 08:45:01 GMT-04:00, "Ludovic Courtès"  a écrit :
>Hi Julien,
>
>Julien Lepiller  skribis:
>
>> When installing Guix on a new machine (foreign distro), substitute
>were not properly set up:
>>
>> …
>> Permit downloading pre-built package binaries from the project's
>build farm? (yes/no) yes
>> /home/roptat/guix-install.sh: line 445:
>/root/.config/guix/current/share/guix/ci.guix.gnu.org.pub: No such file
>or directory
>>
>> That was the latest version of the script downloaded from savannah.
>It downloaded and installed the 1.2.0 tarball.
>>
>> I was able to fix that later manually, but let's make sure the script
>doesn't fail like that with the release :)
>
>I don’t see how this can happen: ‘sys_create_store’ creates
>~root/.config/guix/current, before ‘sys_authorize_build_farms’ runs.
>
>Can you reproduce it, Julien?
>
>Alternatively, could you paste the complete output of the
>guix-install.sh script when it failed?
>
>Thanks,
>Ludo’.


bug#46297: nix-service-configuration is missing the default /bin/sh

2021-04-21 Thread pukkamustard


I ran into the same issue and agree with your conclusion that we 
may not need build-sandbox-paths.


Attached a patch that removes the `build-sandbox-paths` option. 
This causes nix to use the default value which seems to work fine.


>From 886410216c7b1fb6572e7cfdd83dcbd6836e78e4 Mon Sep 17 00:00:00 2001
From: pukkamustard 
Date: Wed, 21 Apr 2021 17:19:36 +0200
Subject: [PATCH] services: nix: Remove build-sandbox-items configuration.

* gnu/services/nix.scm ()[build-sandbox-items]: Remove field.
* doc/guix.texi (Miscellaneous Services)[Nix service]: Remove build-sandbox-items.
---
 doc/guix.texi|  4 
 gnu/services/nix.scm | 30 ++
 2 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index b9019d5550..44e545952f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -31993,10 +31993,6 @@ The Nix package to use.
 @item @code{sandbox} (default: @code{#t})
 Specifies whether builds are sandboxed by default.
 
-@item @code{build-sandbox-items} (default: @code{'()})
-This is a list of strings or objects appended to the
-@code{build-sandbox-items} field of the configuration file.
-
 @item @code{extra-config} (default: @code{'()})
 This is a list of strings or objects appended to the configuration file.
 It is used to pass extra text to be added verbatim to the configuration
diff --git a/gnu/services/nix.scm b/gnu/services/nix.scm
index 1aef47db0a..53796c 100644
--- a/gnu/services/nix.scm
+++ b/gnu/services/nix.scm
@@ -53,8 +53,6 @@
(default nix))
   (sandbox nix-configuration-sandbox ;boolean
(default #t))
-  (build-sandbox-items nix-configuration-build-sandbox-items ;list of strings
-   (default '()))
   (extra-confignix-configuration-extra-config ;list of strings
(default '()))
   (extra-options   nix-configuration-extra-options ;list of strings
@@ -106,24 +104,16 @@ GID."
 (define nix-service-etc
   (match-lambda
 (($  package sandbox build-sandbox-items extra-config)
- (let ((ref-file (references-file package)))
-   `(("nix/nix.conf"
-  ,(computed-file
-"nix.conf"
-#~(begin
-(use-modules (srfi srfi-26)
- (ice-9 format))
-(with-output-to-file #$output
-  (lambda _
-(define internal-sandbox-paths
-  (call-with-input-file #$ref-file read))
-
-(format #t "sandbox = ~a~%" (if #$sandbox "true" "false"))
-;; config.nix captures store file names.
-(format #t "build-sandbox-paths = ~{~a ~}~%"
-(append internal-sandbox-paths
-'#$build-sandbox-items))
-(for-each (cut display <>) '#$extra-config)))
+ `(("nix/nix.conf"
+,(computed-file
+  "nix.conf"
+  #~(begin
+  (use-modules (srfi srfi-26)
+   (ice-9 format))
+  (with-output-to-file #$output
+(lambda _
+  (format #t "sandbox = ~a~%" (if #$sandbox "true" "false"))
+  (for-each (cut display <>) '#$extra-config))
 
 (define nix-shepherd-service
   ;; Return a  for Nix.
-- 
2.31.1



CC: Oleg Pykhalov who seems to have worked on this.

Thanks,
pukkamustard



bug#47935: coreutils: tests/tail-2/inotify-dir-recreate.sh fails on overlayfs

2021-04-21 Thread Carl Dong
Hi all,

I’m continuing my testing of the 1.3.0 branch, and I’ve found that coreutil's 
tests/tail-2/inotify-dir-recreate.sh fails on filesystems where tail detects 
that it cannot use inotify safely (probably arising out of this check: 
https://github.com/coreutils/coreutils/blob/34a48bf0f0552aaed21a7dba4a5488946a978317/src/tail.c#L2486-L2491).
 Example for this: overlayfs used by docker/podman/etc.

The author of tail’s inotify support explains it here: 
https://github.com/containers/podman/issues/5493#issuecomment-598851397

A quick and easy fix for v1.3.0 may be to just disable 
tests/tail-2/inotify-dir-recreate.sh :-)

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"






bug#46829: Fresh install of 1.2.0 can't guix pull

2021-04-21 Thread Ludovic Courtès
Leo Famulari  skribis:

> On Tue, Apr 13, 2021 at 10:12:13AM +0200, Ludovic Courtès wrote:
>> Could you type ‘bt’ (backtrace) at the GDB prompt?
>
> It goes like this:
>
> --
> Using host libthread_db library 
> "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
> Core was generated by 
> `/gnu/store/66xwl53f9ws7gin8iaqkhg111gimw1li-profile/bin/guile 
> ./build-aux/updat'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x in ?? ()
> [Current thread is 1 (Thread 0x7eff7d8cdb80 (LWP 70404))]
> (gdb) bt
> #0  0x in ?? ()
> #1  0x7eff61d9d4c4 in git_buf_try_grow () from 
> /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #2  0x7eff61d9d7a5 in git_buf_set () from 
> /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #3  0x7eff61deffe7 in git_path_prettify () from 
> /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #4  0x7eff61e043ad in find_repo () from 
> /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #5  0x7eff61e0528b in git_repository_discover () from 
> /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #6  0x7eff7de6166d in ffi_call_unix64 () from 
> /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
> #7  0x7eff7de5fac0 in ffi_call_int () from 
> /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
> #8  0x7eff7df4efbe in scm_i_foreign_call () from 
> /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1

BTW, this must be fixed by 5b35c9adc899749a0bd96a0e6d2c3bbf88e38963.

Ludo'.





bug#47734: Guix install script on foreign distro fails to add berlin public key

2021-04-21 Thread Ludovic Courtès
Hi Julien,

Julien Lepiller  skribis:

> When installing Guix on a new machine (foreign distro), substitute were not 
> properly set up:
>
> …
> Permit downloading pre-built package binaries from the project's build farm? 
> (yes/no) yes
> /home/roptat/guix-install.sh: line 445: 
> /root/.config/guix/current/share/guix/ci.guix.gnu.org.pub: No such file or 
> directory
>
> That was the latest version of the script downloaded from savannah. It 
> downloaded and installed the 1.2.0 tarball.
>
> I was able to fix that later manually, but let's make sure the script doesn't 
> fail like that with the release :)

I don’t see how this can happen: ‘sys_create_store’ creates
~root/.config/guix/current, before ‘sys_authorize_build_farms’ runs.

Can you reproduce it, Julien?

Alternatively, could you paste the complete output of the
guix-install.sh script when it failed?

Thanks,
Ludo’.





bug#31719: icedtea-3 binaries contain references to icedtea-2

2021-04-21 Thread Ludovic Courtès
Hi,

Carlo Zancanaro  skribis:

> On 21 April 2021 2:38:56 am AEST, "Ludovic Courtès"  wrote:
>>Sounds good?
>
> Sounds good, except I don't have commit privileges.  Can someone else push 
> it for me?

Oops!  I adjusted the patch so it would apply to ‘master’, and followed
up with two commits:

  f8acd1aeef gnu: openjdk: Disallow references to the JDK used for build.
  e511a1d327 gnu: openjdk: Avoid non-top-level 'use-modules'.
  698c4365ba gnu: openjdk: Fix library substitution when libraries aren't found.

I rebuilt everything up to openjdk@11.

Thanks!

Ludo’.





bug#47808: guile-git-0.5.0.drv build failed on i686-linux

2021-04-21 Thread Ludovic Courtès
Hi,

Bone Baboon  skribis:

> Thank you
> Now when I do a `guix pull --no-substitutes` guile-git build

Awesome, thanks for checking!

Ludo’.





bug#47610: gnome-keyring service doesn't appear

2021-04-21 Thread Leo Prikler
Am Mittwoch, den 21.04.2021, 02:35 -0500 schrieb bdju:
> On Wed Apr 21, 2021 at 2:30 AM CDT, Leo Prikler wrote:
> > That's quite an interesting observation. Could you tell me what DM
> > (gdm, sddm, sway) you're using?
 idiot thinking sway is a DM and not a WM.
> > 
> > The gnome-keyring PAM service works by adding an auto_start login
> > entry, that refers to gnome-keyring's
> > /lib/security/pam_gnome_keyring.so. I don't think you need GNOME
> > keyring installed for that to run, but the default configuration
> > assumes you're running GDM. You will need to adjust it if you use
> > something else.
> > 
> > Regards,
> > Leo
> I'm using sway, I launch it with `exec sway` from a tty.
Since you manually exec sway, you can either configure gnome-keyring-
service, so that it always runs on login (be aware, that I haven't
checked that configuration and it might lock you out forever, so use
rollbacks if that happens), or try to start the keyring manually or
from sway.






bug#47610: gnome-keyring service doesn't appear

2021-04-21 Thread bdju
On Wed Apr 21, 2021 at 2:30 AM CDT, Leo Prikler wrote:
> That's quite an interesting observation. Could you tell me what DM
> (gdm, sddm, sway) you're using?
>
> The gnome-keyring PAM service works by adding an auto_start login
> entry, that refers to gnome-keyring's
> /lib/security/pam_gnome_keyring.so. I don't think you need GNOME
> keyring installed for that to run, but the default configuration
> assumes you're running GDM. You will need to adjust it if you use
> something else.
>
> Regards,
> Leo
I'm using sway, I launch it with `exec sway` from a tty.





bug#47610: gnome-keyring service doesn't appear

2021-04-21 Thread Leo Prikler
Am Mittwoch, den 21.04.2021, 01:49 -0500 schrieb bdju:
> On Tue Apr 6, 2021 at 1:55 AM CDT, Leo Prikler wrote:
> > gnome-keyring-service is not a shepherd service. It is a pam
> > service,
> > that ensures your login keyring (if it exists) is unlocked when you
> > log
> > in. That's all it does.
> > 
> > `ps x | grep gnome-keyring` should have a non-empty output. Mine
> > includes this:
> > /gnu/store/47nl5kpkc3sgwasrbk06sgaig22w07ha-gnome-keyring-
> > 3.34.0/bin/gnome-keyring-daemon --daemonize --login
> > 
> > Regards,
> > Leo
> The only output I get back from that is the very grep I'm running. I
> didn't have gnome-keyring in my manifest, so I added it. Then I
> rebooted. Still nothing. I also installed python-keyring.
> Someone had me run `keyring --list-backends` which seems to show I
> have
> no working keyring backends. I haven't messed with keyrings before,
> so
> maybe I'm just doing something wrong here.
> 
> (output of above command)
> ```
> keyring.backends.fail.Keyring (priority: 0)
> keyring.backends.chainer.ChainerBackend (priority: -1)
> ```
That's quite an interesting observation.  Could you tell me what DM
(gdm, sddm, sway) you're using?

The gnome-keyring PAM service works by adding an auto_start login
entry, that refers to gnome-keyring's
/lib/security/pam_gnome_keyring.so.  I don't think you need GNOME
keyring installed for that to run, but the default configuration
assumes you're running GDM.  You will need to adjust it if you use
something else.

Regards,
Leo






bug#47610: gnome-keyring service doesn't appear

2021-04-21 Thread bdju
On Tue Apr 6, 2021 at 1:55 AM CDT, Leo Prikler wrote:
> gnome-keyring-service is not a shepherd service. It is a pam service,
> that ensures your login keyring (if it exists) is unlocked when you log
> in. That's all it does.
>
> `ps x | grep gnome-keyring` should have a non-empty output. Mine
> includes this:
> /gnu/store/47nl5kpkc3sgwasrbk06sgaig22w07ha-gnome-keyring-
> 3.34.0/bin/gnome-keyring-daemon --daemonize --login
>
> Regards,
> Leo
The only output I get back from that is the very grep I'm running. I
didn't have gnome-keyring in my manifest, so I added it. Then I
rebooted. Still nothing. I also installed python-keyring.
Someone had me run `keyring --list-backends` which seems to show I have
no working keyring backends. I haven't messed with keyrings before, so
maybe I'm just doing something wrong here.

(output of above command)
```
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.chainer.ChainerBackend (priority: -1)
```






bug#41138: IceDove

2021-04-21 Thread Brendan Tildesley via Bug reports for GNU Guix
Problem is gone for me now. (78.6.0)