bug#31769: mpd / pulse control issue

[Leo Famulari]

On Sat, Jun 09, 2018 at 06:58:03AM -0500, Bradley Haggerty wrote:
> When I start my computer, mpd can play my music fine, but pavucontrol can't
> connect to pulse and show my volume controls. If I kill pulse and open
> pavucontrol, all my volume controls are visible, but then mpd can't play
> music.

As 宋文武 and Julien said, this should be fixed in our service but it might be
tricky to do without being able to listen to music ;)

In the meantime, If it suits your needs, you can run MPD with your
unprivileged user instead of at the system level.

Below is a file I use to start MPD as my own user on GuixSD, and it
seems to do the right thing regarding PulseAudio, although I use
pulsemixer instead of pavucontrol.

I originally copied the file from Dave Thompson... any mistakes are my
own :)

By the way, the file should be named '~/.config/shepherd/init.scm'.

--
;; To use this automatically, add something like the following line to
;; whatever gets sourced for a login shell:
;;
;; [[ -z $(pgrep -U $(id --user) shepherd) ]] && shepherd & > /dev/null
;;
;; Or, just invoke `shepherd`.

(use-modules (ice-9 match)
 (srfi srfi-1)
 (system repl server))

(define (touch-file file)
  (close-port (open-file file "a0b")))

(register-services

  (make 
#:provides '(mpd)
#:requires '() 
#:start (lambda args
  (define (mpd-dir file)
(string-append (getenv "HOME") "/.mpd/" file))
  (unless (file-exists? (mpd-dir "playlists"))
(mkdir (mpd-dir "playlists")))
  (touch-file (mpd-dir "database"))
  (fork+exec-command
   (list "mpd" "--no-daemon")))
#:stop (make-kill-destructor)))

(action 'shepherd 'daemonize)

(for-each start '(mpd))
--


signature.asc
Description: PGP signature

bug#31780: manual mentions “git-http-service”, but it does not exist

[Ricardo Wurmus]

In section “Version Control Services” the manual mentions the
“git-http-service” to describe “git-http-configuration”, but that
service does not exist.

-- 
Ricardo

bug#31779: gitweb PERL5LIB needs to include Perl version subdirectory

[Ricardo Wurmus]

The “git” package provides “gitweb”, which is wrapped in PERL5LIB.
Gitweb has broken some time ago and now fails with an error about CGI.pm
not being found.

The reason seems to be that the Perl version sub-directory is not
searched for CGI.pm.  The directory that gitweb.cgi is wrapped with
stops at “site_perl”, but it really should be “site_perl/5.26.1”.

--
Ricardo

bug#31770: New ‘guix pull’ dosen’t update the guix manual in GuixSD

[Ludovic Courtès]

Hello 宋文武!

iyzs...@member.fsf.org (宋文武) skribis:

> After run ‘guix pull’ twice, I have got ‘~/.config/guix/current’, then
> use it to do a system reconfigure for ‘/etc/profile’.
>
> But the guix manual doesn’t got updated, my ‘INFOPATH’ contains:
>
> - /home/iyzsong/.guix-profile/share/info
> - /run/current-system/profile/share/info
> - /home/iyzsong/.config/guix/current/share/info
> - /home/iyzsong/.guix-profile/share/info
> - /run/current-system/profile/share/info
>
> The last there are from the ‘export’ statement of ‘/etc/profile’, the
> first two are added by ‘source’ the profiles.  Since there is a guix in
> the system profile contains the old info manual, the current one won’t
> be picked.

Ooh!  I think the change below should be enough to ensure
~/.config/guix/current comes first:

--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -602,7 +602,7 @@ directory."
 # because they would require combining both profiles.
 # FIXME: See .
 export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
-export INFOPATH=$HOME/.config/guix/current/share/info:$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
+export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
 export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
 export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
 
@@ -630,7 +630,7 @@ then
   export `cat /etc/environment | cut -d= -f1`
 fi
 
-for profile in \"$HOME/.config/guix/current\" \"$HOME/.guix-profile\"
+for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
 do
   if [ -f \"$profile/etc/profile\" ]
   then
@@ -644,6 +644,8 @@ do
   fi
 done
 
+export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
+
 # Set the umask, notably for users logging in via 'lsh'.
 # See .
 umask 022

How does that sound?

(Note that in the meantime you can always work around the bug by using
‘info -f ~/.config/guix/current/share/info/guix.info’ or ‘C-u C-h i …’
in Emacs.)

Thanks for the heads-up!

Ludo’.

bug#31775: mumble fails to build, related to AudioOutput.cpp

[Danny Milosavljevic]

Thanks for the report!

Fixed in master, commit 185b95a8b7a4720243dd5914ce535338cf70a08e.


pgp50AOGUW_N3.pgp
Description: OpenPGP digital signature

bug#31170: Package: nix build failed

[宋文武]

 writes:

> Package: nix build failed

Hello, thanks for the report.

I had updated nix to 2.0.4, which should fix the build.

bug#31775: mumble fails to build, related to AudioOutput.cpp

[Bradley Haggerty]

The mumble package fails to build currently. Here is the relevant error.

AudioOutput.cpp:434:82: error: no matching function for call to ‘abs(float)’

bug#31773: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

[Christopher Baines]

Hey,

The Guix package for duplicity is failing to build, and I was wondering
if there is a fix already? I've had a look on Launchpad, but didn't spot
anything.

Here is the error:

==
ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)
Test getting signature chain fileobjs from archive_dir
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 188, in test_sigchain_fileobj
self.sigchain_fileobj_check_list(self.sigchain_fileobj_get(None))
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 180, in sigchain_fileobj_check_list
test_fileobj(0, "Hello, world!")
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 177, in test_fileobj
fileobjlist[i].close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/dup_temp.py",
 line 227, in close
assert not self.fileobj.close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 304, in close
self.gpg_failed()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 271, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
likely that this message is legitimate.  This is because back
then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!
gpg: WARNING: unsafe permissions on homedir 
'/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/gnupg'
= End GnuPG log =


--
Ran 418 tests in 548.274s

FAILED (errors=1, skipped=3)


Thanks,

Chris


signature.asc
Description: PGP signature

bug#31773: Duplicit fails to build: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

[Christopher Baines]

Duplicity fails to build, this might be because of the GPG version used,
as it looks to me that GPG complains that the message is quite old. I'll
ask on the Duplicity talk mailing list.


test_remove_all_inc_of_but_n (testing.functional.test_cleanup.CleanupTest) ... 
ok

==
ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)
Test getting signature chain fileobjs from archive_dir
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 188, in test_sigchain_fileobj
self.sigchain_fileobj_check_list(self.sigchain_fileobj_get(None))
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 180, in sigchain_fileobj_check_list
test_fileobj(0, "Hello, world!")
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 177, in test_fileobj
fileobjlist[i].close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/dup_temp.py",
 line 227, in close
assert not self.fileobj.close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 304, in close
self.gpg_failed()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 271, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
likely that this message is legitimate.  This is because back
then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!
gpg: WARNING: unsafe permissions on homedir 
'/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/gnupg'
= End GnuPG log =


--
Ran 418 tests in 548.274s

FAILED (errors=1, skipped=3)
Backtrace:
   5 (primitive-load "/gnu/store/h8y2ahqbx83ih4kcf9x5x11wg4q…")
In ice-9/eval.scm:
   191:35  4 (_ _)
In srfi/srfi-1.scm:
640:9  3 (for-each # …)
In 
/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/gnu-build-system.scm:
   799:31  2 (_ _)
In 
/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/python-build-system.scm:
142:8  1 (check #:tests? _ #:test-target _ #:use-setuptools? _)
In 
/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
builder for `/gnu/store/ghxnpxvxvgpgcrf0b7a5ia4s7lm5aha6-duplicity-0.7.17.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/1439zhmkrg58n15mj5m9nmx6sxd01km5-deja-dup-34.3.drv': 1 dependencies 
couldn't be built
guix package: error: build failed: build of 
`/gnu/store/1439zhmkrg58n15mj5m9nmx6sxd01km5-deja-dup-34.3.drv' failed


signature.asc
Description: PGP signature

bug#31769: mpd / pulse control issue

[Julien Lepiller]

I think the best solution is to implement this in our herd service. It doesn't 
look too difficult to do the part in the mpd configuration, but pulseaudio 
might be trickier to configure...

Le 10 juin 2018 04:18:47 GMT+02:00, iyzs...@member.fsf.org a écrit :
>Bradley Haggerty  writes:
>
>> I have mpd enabled as a herd service. When I start my computer, mpd
>can play my music fine, but pavucontrol can't connect to pulse and show
>my volume controls. If I
>> kill pulse and open pavucontrol, all my volume controls are visible,
>but then mpd can't play music. If I kill pulse again and this time play
>a song in mpd, mpd works again,
>> but pavucontrol can't connect. Basically, if mpd starts pulse, mpd
>works, but other things can't connect, and if pavucontrol starts pulse,
>mpd can't connect to pulse. Since
>> I have mpd enabled as a service, it's the one to start pulse on a
>fresh boot. I also tried starting pulse as my user by killing it and
>opening pavucontrol, then restarting the
>> mpd service in case it could find my pulse service this way. No
>success there. While mpd has control of pulse, other applications also
>lack sounds, such as mpv (video
>> players) and icecat.
>
>According to the wiki of ArchLinux, users of PulseAudio with a
>system-wide MPD configuration have to implement a workaground:
>
>
>
>It suggests letting mpd use pulseaudio's tcp module to send sound to
>localhost, where user's pulseaudio server listening.
>
>This seems too tricky for me, I'll suggest you forget the system herd
>service, and launch mpd as a normal user:
>.