bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

[宋文武]

if CMAKE_INSTALL_LIBDIR not set to `lib`, GNUInstallDirs.cmake will install
libraries files to $out/lib64.

if CMAKE_PREFIX_PATH not set to PATH of `inputs`, cmake will unable to
find cmake modules of inputs.

I find this when packaging https://github.com/lxdg/libqtxdg.

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> if CMAKE_INSTALL_LIBDIR not set to `lib`, GNUInstallDirs.cmake will install
>> libraries files to $out/lib64.
>
> I found several CMake-built libraries on x86_64 (graphite2, openjpeg,
> qjson) that all use lib/, not lib64/.
>
> Then I found one counterexample, libftdi; however, setting
> CMAKE_INSTALL_LIBDIR=lib doesn’t make any different: it still installs
> libraries in $out/lib64.  Any idea?
libftdi (not using GNUInstallDirs.cmake) handle this itself by
set LIB_SUFFIX, look like we have to set it specifically.
>
> Here’s the patch I tried:
>
> diff --git a/guix/build/cmake-build-system.scm 
> b/guix/build/cmake-build-system.scm
> index 74b4f01..b1598dd 100644
> --- a/guix/build/cmake-build-system.scm
> +++ b/guix/build/cmake-build-system.scm
> @@ -53,6 +53,8 @@
>   build-type))
>  '())
>,(string-append "-DCMAKE_INSTALL_PREFIX=" out)
> +  ;; Install libraries to $prefix/lib, not $prefix/lib64.
> +  "-DCMAKE_INSTALL_LIBDIR=lib"
>;; add input libraries to rpath
>"-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE"
>;; add (other) libraries of the project itself to rpath
>
> According to <http://www.cmake.org/Wiki/CMake_Useful_Variables>,
> LIBRARY_OUTPUT_PATH might be better for this, no?
no, this is for build phase.
>
>> if CMAKE_PREFIX_PATH not set to PATH of `inputs`, cmake will unable to
>> find cmake modules of inputs.
>
> You’re talking about .cmake files, right?
yes, but now I find out that they can under both lib/cmake and share/cmake.
>
> Could you try the attached patch and report back?
>
> From 536c143997fa146dc77d6e8defc24032452e5a4c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
> Date: Sun, 2 Nov 2014 23:54:28 +0100
> Subject: [PATCH] gnu: cmake: Add search paths for
>  CMAKE_{INCLUDE,LIBRARY,MODULE}_PATH.
>
> * gnu/packages/cmake.scm (cmake)[native-search-paths]: New field.
> * guix/build/cmake-build-system.scm (configure): Remove 'setenv' calls
>   for "CMAKE_LIBRARY_PATH" and "CMAKE_INCLUDE_PATH".
> ---
>  gnu/packages/cmake.scm| 19 +++
>  guix/build/cmake-build-system.scm |  2 --
>  2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/cmake.scm b/gnu/packages/cmake.scm
> index 63805ef..e0349be 100644
> --- a/gnu/packages/cmake.scm
> +++ b/gnu/packages/cmake.scm
> @@ -100,6 +100,25 @@
> ("expat"  ,expat)
> ("bzip2"  ,bzip2)
> ("libarchive" ,libarchive)))
> +
> +(native-search-paths
> + (list
> +  ;; Search path used by the 'FIND_XXX' functions.
> +  (search-path-specification
> +   (variable "CMAKE_PROGRAM_PATH")
> +   (directories '("bin")))
> +  (search-path-specification
> +   (variable "CMAKE_INCLUDE_PATH")
> +   (directories '("include")))
> +  (search-path-specification
> +   (variable "CMAKE_LIBRARY_PATH")
> +   (directories '("lib" "lib64")))
> +
> +  ;; Search path used by 'FIND_PACKAGE' and 'INCLUDE'.
> +  (search-path-specification
> +   (variable "CMAKE_MODULE_PATH")
> +   (directories '("lib/cmake")
> +
>  (home-page "http://www.cmake.org/";)
>  (synopsis "Cross-platform build system")
>  (description
> diff --git a/guix/build/cmake-build-system.scm 
> b/guix/build/cmake-build-system.scm
> index b1598dd..766797e 100644
> --- a/guix/build/cmake-build-system.scm
> +++ b/guix/build/cmake-build-system.scm
> @@ -60,8 +60,6 @@
>;; add (other) libraries of the project itself to rpath
>,(string-append "-DCMAKE_INSTALL_RPATH=" out "/lib")
>,@configure-flags)))
> -  (setenv "CMAKE_LIBRARY_PATH" (getenv "LIBRARY_PATH"))
> -  (setenv "CMAKE_INCLUDE_PATH" (getenv "CPATH"))
>(format #t "running 'cmake' with arguments ~s~%" args)
>(zero? (apply system* "cmake" args)
>  
> -- 
> 2.1.2
thanks for the patch, I have apply it, but it does not work.
because libqtxdg have qtxdg-config.cmake in $out/share/cmake/qt5xdg.

after add CMAKE_PREFIX_PATH with:

  (search-path-specification
(variable "CMAKE_PREFIX_PATH")
(directories '("")))

I could get liblxqt(use libqtxdg) build ok.

and by setting CMAKE_PREFIX_PATH, I think we can get rid of
CMAKE_PROGRAM_PATH, CMAKE_INCLUDE_PATH, and maybe CMAKE_LIBRARY_PATH.
see: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html.
>
>
>> I find this when packaging https://github.com/lxdg/libqtxdg.
>
> It’s 404.
oh, sorry, it's https://github.com/lxde/libqtxdg

and here is the packages I'm working on:


lxqt.scm
Description: Binary data

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> 宋文武  skribis:
>>>
>>>> if CMAKE_INSTALL_LIBDIR not set to `lib`, GNUInstallDirs.cmake will install
>>>> libraries files to $out/lib64.
>>>
>>> I found several CMake-built libraries on x86_64 (graphite2, openjpeg,
>>> qjson) that all use lib/, not lib64/.
>>>
>>> Then I found one counterexample, libftdi; however, setting
>>> CMAKE_INSTALL_LIBDIR=lib doesn’t make any different: it still installs
>>> libraries in $out/lib64.  Any idea?
>> libftdi (not using GNUInstallDirs.cmake) handle this itself by
>> set LIB_SUFFIX, look like we have to set it specifically.
>
> Ah, OK.
>
> Still, graphite2, openjpeg, and qjson all install to $prefix/lib, even
> when not passing CMAKE_INSTALL_LIBDIR=lib.  Is it really needed?
Not sure, it's just for packages using GNUInstallDirs.cmake.
>
>>>> if CMAKE_PREFIX_PATH not set to PATH of `inputs`, cmake will unable to
>>>> find cmake modules of inputs.
>>>
>>> You’re talking about .cmake files, right?
>> yes, but now I find out that they can under both lib/cmake and share/cmake.
>
> In that case...
>
>>> +  ;; Search path used by 'FIND_PACKAGE' and 'INCLUDE'.
>>> +  (search-path-specification
>>> +   (variable "CMAKE_MODULE_PATH")
>>> +   (directories '("lib/cmake")
> ^
> ... just add "share/cmake" here. ---’
>
> Could you try that?
Well, it not work, here is the exact output by liblxqt:

  By not providing "FindQt5Xdg.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5Xdg", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5Xdg" with any
  of the following names:

Qt5XdgConfig.cmake
qt5xdg-config.cmake

  Add the installation prefix of "Qt5Xdg" to CMAKE_PREFIX_PATH or set
  "Qt5Xdg_DIR" to a directory containing one of the above files.  If "Qt5Xdg"
  provides a separate development package or SDK, be sure it has been
  installed.

Since FindQt5Xdg.cmake is not provided by upstream, it looks like we have to set
CMAKE_PREFIX_PATH or Qt5Xdg_DIR.

And if I understand correctly, at liblxqt side, since #:configure-flags can
not refer inputs, I have to add a pre-configure phase, then using setenv.
>
>> after add CMAKE_PREFIX_PATH with:
>>
>>   (search-path-specification
>> (variable "CMAKE_PREFIX_PATH")
>> (directories '("")))
>
> I thought about it, but that "" is inelegant and not as clear.
Yes, it not feeling good, but I have no better idea now.
>
>> and here is the packages I'm working on:
>
> Looks like a good start.  :-)
>
> Thanks,
> Ludo’.

bug#19018: not provided by the ncurses library

[宋文武]

Hi, gtypist check and use ncurses header from that location,
perhaps we should make a symlink in ncurses just as nixpkgs does.

And here is my patch for gtypist:
>From 4cfd5ede203eb3a105a7396ccf784f756150f90c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Tue, 11 Nov 2014 20:34:22 +0800
Subject: [PATCH] gnu: Add GNU Typist.

* gnu/packages/games.scm (gtypist): New variable.
---
 gnu/packages/games.scm | 24 
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index df24c0d..5759c07 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -462,3 +462,27 @@ you control to bounce a ball around the game zone destroying blocks with a
 proton ball.  Each block carries a different point value.  The more blocks you
 destroy, the better your score.  The person with the highest score wins.")
 (license (x11-style "file://COPYING" "Very similar to the X11 licence."
+
+(define-public gtypist
+  (package
+(name "gtypist")
+(version "2.9.5")
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append "mirror://gnu/gtypist/gtypist-"
+  version ".tar.xz"))
+  (sha256
+   (base32
+"0xzrkkmj0b1dw3yr0m9hml2y634cc4h61im6zwcq57s7285z8fn1"
+(build-system gnu-build-system)
+(inputs `(("ncurses" ,ncurses)))
+(home-page "http://www.gnu.org/software/gtypist/";)
+(synopsis "Universal typing tutor")
+(description
+ "Typist is a typing tutor package built using Curses.  The package has
+tutorials, drills, and practice sessions to learn touch typing.  The emphasis
+is on the US computer keyboard layout, but lessons for Dvorak and other
+keyboard types and languages are also included.  The program also has Native
+Language Support and is distributed with messages in many different languages.")
+(license gpl3+)))
-- 
1.9.2

bug#19367: gnome-icon-theme were not built correctly

[宋文武]

Legacy icons is missing (eg: inode/directory used by thunar),
The reason is `icon-naming-utils' does not work.

See: http://hydra.gnu.org/build/172835/log/raw
With:
  Can't locate XML/Simple.pm in @INC ...

bug#19119: closed (Re: bug#19119: X cannot run programs in the current user's profile)

[宋文武]

Ludovic Courtès  writes:

> Thinking more about it, the fix in 1d18d87 wasn’t quite right.
>
> I think the right thing would be to run the window manager as a child of
> a ‘bash --login’ process, so the whole X session would get environment
> variables like a login shell.
>
> WDYT, 宋文武?
Agree!

And currently ratposion and windowmaker are hardcoded,
how about make sessions configurable?
Like:
(define %default-sessions
  `(("windowmaker" . #~(execl #$windowmaker "/bin/wmaker"))
("ratposion" . #~(execl #$ratposion "/bin/ratposion"

(define* (slim-service #:key (sessions %default-sessions)
...
>
> Thanks,
> Ludo’.

bug#19367: Fixed

[宋文武]

Fixed in commit f4e9727.

bug#19491: /etc/mtab give wrong entries for early-mounted items.

[宋文武]

Notably, I have:
  /dev/sda1 /root ext4 rw,relatime,data=ordered 0 0
  none /root//dev devtmpfs rw 0 0

Which should be:
  /dev/sda1 / ...
  none /dev ...

Why not make /etc/mtab a symlink to /proc/self/mounts?

bug#19491: /etc/mtab give wrong entries for early-mounted items.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> Notably, I have:
>>   /dev/sda1 /root ext4 rw,relatime,data=ordered 0 0
>>   none /root//dev devtmpfs rw 0 0
>>
>> Which should be:
>>   /dev/sda1 / ...
>>   none /dev ...
>>
>> Why not make /etc/mtab a symlink to /proc/self/mounts?
>
> This sounds appealing, but it seems that libmount in util-linux will
> insist to update /etc/mtab.
>
> Do you have evidence that it could cope with it?
Not sure, but I think libmount should just work fine.

util-linux support this since 2.19:
  https://www.kernel.org/pub/linux/utils/util-linux/v2.19/v2.19-ReleaseNotes

Debian make this default at 2011:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001
>
> Thanks,
> Ludo’.

bug#19491: Fixed

[宋文武]

Fixed in commit 9331ba5d
by make /etc/mtab a symlink to /proc/self/mounts.

bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session

[宋文武]

Ricardo Wurmus  writes:

> The fix may have resulted in unintended side-effects.  On a fresh
> installation of the System Distribution v0.8.1 WindowMaker is installed
> by default, but it is not completely functional.
>
> For example, the attempt to change the style via the menu results in
> this error to be displayed:
>
> Could not execute command:
> setstyle 
> /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style
>
> Likewise, selecting "Configure Window Maker" from the right-click menu
> results in this error:
>
> Could not execute command: exec WPrefs
>
> The "setstyle" executable is located in
> /gnu/store/...windowmaker.../bin/, but is not in the PATH.
Yes, the $out/bin of windowmaker is not in $PATH, and same for sawfish.

Instead of wrapping every executable of session-type, we can:

#1: Add the package to system profile ('packages').
  It's not clear to me how to do it now, until we have something
  like the NixOS's module system.

#2: Make SLiM use '/run/current-system/profile/share/xsessions' as
session_dir.
  So simply add a package providing xsession file to 'packages' should
  make it available to SLiM.  And all DE and many window-managers provide
  xsession files already (eg: openbox, sawfish, xfce), we can patch
  the rest (eg: WindowMaker) to install one.

I would like to go #2, WDYT?

bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> Ricardo Wurmus  writes:
>>
>>> The fix may have resulted in unintended side-effects.  On a fresh
>>> installation of the System Distribution v0.8.1 WindowMaker is installed
>>> by default, but it is not completely functional.
>>>
>>> For example, the attempt to change the style via the menu results in
>>> this error to be displayed:
>>>
>>> Could not execute command:
>>> setstyle 
>>> /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style
>>>
>>> Likewise, selecting "Configure Window Maker" from the right-click menu
>>> results in this error:
>>>
>>> Could not execute command: exec WPrefs
>>>
>>> The "setstyle" executable is located in
>>> /gnu/store/...windowmaker.../bin/, but is not in the PATH.
>> Yes, the $out/bin of windowmaker is not in $PATH, and same for sawfish.
>>
>> Instead of wrapping every executable of session-type, we can:
>>
>> #1: Add the package to system profile ('packages').
>>   It's not clear to me how to do it now, until we have something
>>   like the NixOS's module system.
>
> What I have in mind is to add a ‘packages’ field in ‘service’.  That
> would allow service implementations to contribute packages to the global
> profile.  Thoughts?
It's fine, but we may also need a 'dbus-service' field (for wicd).
>
>> #2: Make SLiM use '/run/current-system/profile/share/xsessions' as
>> session_dir.
>>   So simply add a package providing xsession file to 'packages' should
>>   make it available to SLiM.  And all DE and many window-managers provide
>>   xsession files already (eg: openbox, sawfish, xfce), we can patch
>>   the rest (eg: WindowMaker) to install one.
>
> IIUC the bug initially reported here would remain: the user’s $PATH
> would be polluted with the window manager’s stuff, no?
I think the 'polluted' means we have a $PATH contains:
  /gnu/store/xxx-windowmaker/bin
install it to profile doesn't have this issue.
>
> Thanks,
> Ludo’.

bug#20037: 'guix system reconfigure' without 'gnu/system/linux.go' fails with duplicates login pam-service

[宋文武]

I can reproduce the issue Tomáš Čech (Sleep_Walker) reported at IRC,
but only when reconfigure under 'pre-inst-env' and without 
'gnu/system/linux.go':

$ cd guix; make clean-go
# .../guix/pre-inst-env guix system reconfigure config.scm

;;; Failed to autoload make-session in (gnutls):
;;; ERROR: missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; ERROR: missing interface for module (gnutls)
;;; Failed to autoload make-session in (gnutls):
;;; ERROR: missing interface for module (gnutls)
The following derivations will be built:
   /gnu/store/8576w1km2a8ij7k66k6n37gyhxzpxda4-system.drv
   /gnu/store/8jg5iqrd04hj1k8nx6fzcm9lz16nmk4r-grub.cfg.drv
   /gnu/store/d53lbndj9yryrzgb3p4vjlb9gyh1rri0-activate.drv
   /gnu/store/y3i8spghyv4dg8d8yl78bvkjb3xcbarb-boot.drv
   /gnu/store/mrlw80nawfbc8mhq3pz6gbxxpgjbabij-pam.d.drv
   /gnu/store/sf3n6ijagmc64ik7mn96p8c69xk30nmv-etc.drv
Backtrace:
In ice-9/boot-9.scm:
 157: 10 [catch #t # ...]
In unknown file:
   ?: 9 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 8 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 7 [eval # #]
In ice-9/boot-9.scm:
2401: 6 [save-module-excursion #]
4050: 5 [#]
1724: 4 [%start-stack load-stack #]
1729: 3 [#]
In unknown file:
   ?: 2 [primitive-load 
"/gnu/store/dmsgr6bsp9k0x7c2dmcvhqrgrqqal7kb-pam.d-builder"]
In ice-9/boot-9.scm:
 775: 1 [for-each # (# # # # 
...)]
In unknown file:
   ?: 0 [symlink "/gnu/store/pn2wmdczwcknksxhdn4jl6sh49h0vidm-login" ...]

ERROR: In procedure symlink:
ERROR: In procedure symlink: File exists
builder for `/gnu/store/mrlw80nawfbc8mhq3pz6gbxxpgjbabij-pam.d.drv' failed with 
exit code 1
cannot build derivation `/gnu/store/sf3n6ijagmc64ik7mn96p8c69xk30nmv-etc.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/8576w1km2a8ij7k66k6n37gyhxzpxda4-system.drv': 1 dependencies 
couldn't be built
killing process 2317
guix system: error: build failed: build of 
`/gnu/store/8576w1km2a8ij7k66k6n37gyhxzpxda4-system.drv' failed


the pam.d-builder contains duplicates login entries
(I have 3 mingetty-service)


dmsgr6bsp9k0x7c2dmcvhqrgrqqal7kb-pam.d-builder
Description: Binary data

After add '(pretty-print services)' to 'pam-services->directory', I get:


x
Description: Binary data

After 'make gnu/system/linux.go', it works with a different pam.d-builder:


1g1ik6jp04x8j204482hkzvfq4dxly0h-pam.d-builder
Description: Binary data

bug#19015: Fixed

[宋文武]

Fixed in commit 2cb4ca6 by remove asla-lib from inputs.

SDL_mixer do a testing for libmikmod using libmikmod-config.
libmikmod-config.in has:
  --libs)
echo -L@libdir@ -lmikmod @LIBRARY_LIB@

When built with alsa driver support, @LIBRARY_LIB@ become "-lm -lasound",
require alsa-lib presented to get the test success.  But in fact the
use of libmikmod
library don't depends on the drivers (alsa),  and the libmikmod.pc
file doesn't have them
in Libs (and Libs.private). So I think it's a bug where @LIBRARY_LIB@
contains '-lasound'.

Instead of  dropping @LIBRARY_LIB@ from libmikmod-config.in, I notice
that the only user
of libmikmod is sdl-mixer, which use it's own audio output drivers.
So I'm temped to remove
alsa-lib from libmikmod (the libx11 is unused IIRC).

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武]

Currently, search-paths built only from packages in user's profile.
As reported by Andy Wingo in #guix, when I have:
  perl installed into system profile
  perl-xml-parser installed into user profile
  
guix package --search-paths won't give a hint about PERL5LIB,
so it's very likely end up with a broken XML::Parser.
Another interesting fact is that we have both guile and guix in
system profile, but the guix modules isn't work out-of-the-box
on GuixSD.

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> Currently, search-paths built only from packages in user's profile.
>> As reported by Andy Wingo in #guix, when I have:
>>   perl installed into system profile
>>   perl-xml-parser installed into user profile
>>   
>> guix package --search-paths won't give a hint about PERL5LIB,
>> so it's very likely end up with a broken XML::Parser.
>
> Rather it ends up with no XML::Parser, no?
>
> That said, I’m not sure how this could be improved.  We could hard-code
> lookup in /run/current-system/profile/.  OTOH that’s not different from
> installing perl in one profile, and perl-xml-parser in another
> (arbitrary) profile, which ‘guix package’ cannot be aware of.
>
> WDYT?
As 'guix package' is for only one profile, that's fine.
Since we can get search-paths from system profile using:
  guix package -p /run/current-system/profile --search-paths

I think the missing is to check whether we are under GuixSD,
and then merge those 2 search-paths object in scheme level
to get a full search-paths.

Or better to generate a 'profile' script for each manifest, and then
merged in shell level, so it can work out-of-the-box. How about:
  - /etc/profile:
# configuration for the whole system goes here.
# shouldn't refer profile paths.
export LANG=en_US.utf8
export SSL_CERT_DIR=/etc/ssl/certs
export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
[...]

source /run/current-system/profile/etc/profile

if [ -f $HOME/.guix-profile/etc/profile ]; then
  source $HOME/.guix-profile/etc/profile
fi

# honor setuid-programs
export PATH=/run/setuid-programs:$PATH

  - /run/current-system/profile/etc/profile:
export 
PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH
export MANPATH=/run/current-system/profile/share/man:$PATH
[...]

  - ~/.guix-profile/etc/profile:
export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH
[...]

The idea to generate profile from search-paths is not new,
I heard it from you IIRC.
I think it's the time to do it.

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武]

> [...]
>>
>> The idea to generate profile from search-paths is not new,
>> I heard it from you IIRC.
>> I think it's the time to do it.
>
> Agreed, the plan makes sense and I think we have all the bits.
>
> A related question is whether to encode search path environment
> variables into the manifest (currently they are “guessed” by looking at
> same-named packages; see (guix build package).)  I think that would
> probably simplify things and make it easier to share this environment
> variable code.
>
> Thoughts?
I see, currently search-paths depends on the packages recipes. If we
update the related scheme code, then search-paths got updated, even we
didn't touch packages in profile at all.  It's a little confusing.
So I think we should encode the search-paths for each package in
manifest.
> Thanks,
> Ludo’.

bug#20358: MariaDB failed to link 'libgcc_s.so' with our ld-wrapper.

[宋文武]

In my patch for mariadb, I have to set LDFLAGS to '-lgcc_s':
  https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00321.html

without this, binaries are built linked with libstdc++.so, but
have a not found entry for libgcc_s.so, eg:
  $ ldd ./build/sql/gen_lex_hash
linux-vdso.so.1 (0x7ffcfbfea000)
libpthread.so.0 => 
/gnu/store/wiqbxcvzj3r35hd55yxzz919b1dv1hnv-glibc-2.21/lib/libpthread.so.0 
(0x7ff62a182000)
libstdc++.so.6 => 
/gnu/store/h132igxl2lkj3sbfcbknn2rd493j7d1l-gcc-4.8.4-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../libstdc++.so.6
 (0x7ff629e8)
libm.so.6 => 
/gnu/store/wiqbxcvzj3r35hd55yxzz919b1dv1hnv-glibc-2.21/lib/libm.so.6 
(0x7ff629b7e000)
libc.so.6 => 
/gnu/store/wiqbxcvzj3r35hd55yxzz919b1dv1hnv-glibc-2.21/lib/libc.so.6 
(0x7ff6297de000)

/gnu/store/wiqbxcvzj3r35hd55yxzz919b1dv1hnv-glibc-2.21/lib/ld-linux-x86-64.so.2 
(0x7ff62a39f000)
libgcc_s.so.1 => not found

The link script (sql/CMakeFiles/gen_lex_hash.dir/link.txt) contains:

  /gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4/bin/c++
-fno-exceptions -fno-rtti -O3 -g -static-libgcc -fno-omit-frame-pointer 
-fno-strict-aliasing -Wno-uninitialized -DDBUG_OFF   
CMakeFiles/gen_lex_hash.dir/gen_lex_hash.cc.o  -o gen_lex_hash  -lpthread



And the build script (sql/CMakefils/gen_lex_hash.dir/flags.make):
-
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.1

# compile CXX with /gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4/bin/c++
CXX_FLAGS =  -fno-exceptions -fno-rtti -O3 -g -static-libgcc 
-fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -DDBUG_OFF 
-I/var/tmp/nix-build-mariadb-10.0.17.drv-0/build/include 
-I/var/tmp/nix-build-mariadb-10.0.17.drv-0/mariadb-10.0.17/include 
-I/var/tmp/nix-build-mariadb-10.0.17.drv-0/mariadb-10.0.17/sql 
-I/var/tmp/nix-build-mariadb-10.0.17.drv-0/mariadb-10.0.17/zlib 
-I/var/tmp/nix-build-mariadb-10.0.17.drv-0/mariadb-10.0.17/extra/yassl/include 
-I/var/tmp/nix-build-mariadb-10.0.17.drv-0/mariadb-10.0.17/extra/yassl/taocrypt/include
 -I/var/tmp/nix-build-mariadb-10.0.17.drv-0/build/sql-DHAVE_YASSL 
-DYASSL_PREFIX -DHAVE_OPENSSL -DMULTI_THREADED

CXX_DEFINES = -DHAVE_CONFIG_H -DHAVE_EVENT_SCHEDULER -DHAVE_POOL_OF_THREADS 
-DMYSQL_SERVER
--

As Ludovic Courtès tell,  '-static-libgcc' may be the issue.

bug#20358: MariaDB failed to link 'libgcc_s.so' with our ld-wrapper.

[宋文武]

> As Ludovic Courtès tell,  '-static-libgcc' may be the issue.
Well, the proper solution is fix our 'libstdc++.so' (which has
a "not found" entry for libgcc_s.so) in the next 'core-updates'.

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> Or better to generate a 'profile' script for each manifest, and then
>> merged in shell level, so it can work out-of-the-box. How about:
>>   - /etc/profile:
>> # configuration for the whole system goes here.
>> # shouldn't refer profile paths.
>> export LANG=en_US.utf8
>> export SSL_CERT_DIR=/etc/ssl/certs
>> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>> [...]
>>
>> source /run/current-system/profile/etc/profile
>>
>> if [ -f $HOME/.guix-profile/etc/profile ]; then
>>   source $HOME/.guix-profile/etc/profile
>> fi
>>
>> # honor setuid-programs
>> export PATH=/run/setuid-programs:$PATH
>>
>>   - /run/current-system/profile/etc/profile:
>> export 
>> PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH
>> export MANPATH=/run/current-system/profile/share/man:$PATH
>> [...]
>> 
>>   - ~/.guix-profile/etc/profile:
>> export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH
>> [...]
>
> There’s a further complication here: ‘profile-derivation’, which builds
> the profile, doesn’t know its user-visible name ~/.guix-profile.  It
> just knows its store file name.  However, we don’t want etc/profile to
> read:
>
>   export PATH=/gnu/store/...-profile/bin:$PATH
>
> because then, the user’s environment variables in a running session
> would keep pointing to a given profile generation.
Indeed.  Run guix to install a package should make it available
immediately.  Currently, we have 'PATH=~/.guix-profile/bin' in
profile and print hint for additional variables.
(Note that when profile changes, even we build all variables with the
location they going to be, a hint or re-source is still needed when the
new profile bring new variables.)
>
> So we have to tell ‘profile-generation’ what the user-visible name of
> the profile is going to be.  Attached is a very rough patch to do that.
> This is not so nice because all user interfaces will now have to pass
> that #:target parameter or etc/profile will be “wrong.”
>
> Another option would be to simply run:
>
>   eval `guix package -p ~/.guix-profile --search-paths`
>
> This has two downsides:
>
>   1. It takes ~200 ms to run on my laptop, which can maybe be
>  noticeable; OTOH it’s only for interactive shells, so maybe that’s
>  OK.
>
>   2. If there’s a manifest format change and /etc/profile calls a ‘guix’
>  command that cannot handle the manifest format (because it’s older
>  than the ‘guix’ used to build the profile), then it doesn’t work at
>  all (that’s a bit contrived, but not completely impossible.)
>
> Thoughts?
>
How about using a shell variable as input for the location:
(replace /gnu/store/xxx with $GUIX_PROFILE)

  # etc/profile
  export PATH=$GUIX_PROFILE/bin:$PATH
  export MANPATH=$GUIX_PROFILE/share/man:$MANPATH
  ...

Then when 'source' it, we pass the location:
(we did know where $GUIX_PROFILE is when do the 'source')

  # ~/.bash_profile
  GUIX_PROFILE=$HOME/.guix-profile
  if [ -f $GUIX_PROFILE/etc/profile ]; then
. $GUIX_PROFILE/etc/profile
  fi

  # /etc/profile
  GUIX_PROFILE=/run/current-system/profile
  source $GUIX_PROFILE/etc/profile

bug#20582: GuixSD ver 0.8.2, DHCLIENT not setting up the network.

[宋文武]

2015-05-15 11:15 GMT+08:00 Scott McDonough :
> I downloaded Guix and tried to install it but DHCLIENT times out and does
> not set up the NIC card.  This command worked fine on my hardware with ver
> 0.8.1. Is anyone else experiencing this issue?
Maybe you need set up the NIC first?
(at least, I need)

bug#21318: Only the first 8 characters of passwords are significant

[宋文武]

Mark H Weaver  writes:

> yenda on #guix reported that when typing user passwords, only the first
> 8 characters need to be typed correctly to successfully log in.
>
> DusXMT on #guix mentioned that [GNU/]Linux From Scratch instructs users
> to change "#ENCRYPT_METHOD_DES" to "ENCRYPT_METHOD_SHA512" in
> etc/login.defs:
>
>   http://www.linuxfromscratch.org/lfs/view/stable/chapter06/shadow.html
>
> I tried modifying both /etc/login.defs and etc/login.defs in our
> 'shadow' package recipe, and then tried updating my password entry with
> 'passwd' but it still only pays attention to the first 8 characters.
>
> 'strace' reveals that 'passwd' doesn't even look for any file named
> "login.defs".
Yeah, when login using PAM (our case), login.defs is not used.
>
> I'm not sure what's going on here, but it would be good to fix it soon.
It turn out that add a 'sha512' to the argument of password pam entry do
the trick,  patch sent :-)

bug#21318: Fixed

[宋文武]

Fixed in commit 9297065a2b2151636194b2c91e957a3ec0b33532.

bug#21318: Fixed

[宋文武]

Fixed in commit 9297065a2b2151636194b2c91e957a3ec0b33532.

bug#21217: Only one icons shown in panel GuixSD installation with Xfce4 desktop

[宋文武]

Danny Milosavljevic  writes:

> Hi,
>
> after instlaling GuixSD and starting the Xfce4 desktop, only the folder
> icon is shown in the panel. The other launchers are there, but the
> buttons are empty (without icon but the size is right). For example,
> "File Manager" (Thunar) has no icon shown.
Yes, by default no icon theme is selected for Xfce, users have to run
'xfce4-appearance-settings' and select 'gnome'.
(I thought this was ok, but it seems bother many people.)

Should be fixed in commit 363ccf9f.  Thanks!

bug#21842: Brasero fails to start on foreign distros

[宋文武]

Federico Beffa  writes:

> On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès  wrote:
>> As Andy notes on IRC, Brasero currently fails to start:
>>
>> --8<---cut here---start->8---
>> $  /gnu/store/dq3817g8w80c9hffbgzspslqjy7szq35-brasero-3.12.1/bin/brasero
>>
>> ** (brasero:21487): WARNING **: Error retrieving accessibility bus
>> address: org.freedesktop.DBus.Error.ServiceUnknown: The name
>> org.a11y.Bus was not provided by any .service files
>>
>> (brasero:21487): GLib-GIO-ERROR **: Settings schema 
>> 'org.gnome.brasero.config' is not installed
>>
>> Trace/breakpoint trap (core dumped)
>> --8<---cut here---end--->8---
>>
>> On GuixSD, it starts just fine *if* it is installed in ~/.guix-profile,
>> because XDG_DATA_DIRS and XDG_CONFIG_DIRS are appropriately set.
>>
>> However, on foreign distros, it doesn’t work out of the box.
>>
>> Andy suggests using ‘glib-or-gtk-build-system’ for Brasero, which
>> appears to solve the problem.
>>
>> WDYT?
>
> I think that using the 'glib-or-gtk-build-system' is the right thing
> to do. It will create a wrapper with the correct value of some
> environment variables, enabling the program to find its schema.
>
Sure, I went ahead and push it.
>>
>> Should we add a profile hook similar to ‘gtk-icon-themes’ in (guix
>> profiles) but for schemas?
>
> I do not think so because if a program gets the wrong schema (say, a
> different incompatible version) then it may crash. With the
> 'glib-or-gtk-build-system' it is guaranteed that it will find the
> schema used at build time.
Yes, using the schemas cache built from profile is problematic for
a program, but as long as it was wraped, the profile cache won't be
used.

But the profile cache is required for dconf-editor to be functional,
I'd like to add it.

>
> Speaking of GTK+ applications: I think that removing the generation of
> 'icon-theme.cache' from the 'glib-or-gtk-build-system' was a mistake
> (I may even have suggested this). It is my understanding (see [1, 2])
> that this file is not strictly necessary, however it speeds up things
> and is therefore useful. Having the cache generated by the
> build-system allows one to use the program optimally without having to
> install it into a profile.
Technical right, but since the cache (hicolor) build for the program
only contain it's own icon (eg: evince). For desktop-wide applications
(panel, file managers) this cache is not useful at all.
I guess there won't be much speeds up, need tests to find more detail
though :-)
>
> The icon profile hook is still useful because it allows one to add
> icon themes a posteriori, that is after having build a program
> derivation and without having to rebuild it. The wrapper created by
> 'glib-or-gtk-build-system' still looks in the directories listed in
> XDG_DATA_DIRS (similarly for some other variables). See also the
> discussion at [3].
>
> The reason for removing the phase from the build system was to
> suppress annoying collision warnings, but in my opinion it would be
> better to suppress them in a different way. As long as the profile
> hook is the last derivation being installed in a profile, such
> collisions are harmless and should just be masked.
Yes, remove the phase is an easy way to suppress the warnings for
icon cache. (there still have some programs install the icon cache,
which could be handled per-package IMO.)

We did need to suppress the warnings for the schemas cache.
If just mask the collisions instead of avoid collisions actually
don't have performance issue, I'm ok with it.
>
> Regards,
> Fede
>
> [1] https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html
> [2] 
> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
> [3] https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00108.html

I'd like to do some tests to see how the icon cache is used actually.

Thanks!

bug#21842: Brasero fails to start on foreign distros

[宋文武]

Federico Beffa  writes:

> On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès  wrote:
>> As Andy notes on IRC, Brasero currently fails to start:
>>
>> --8<---cut here---start->8---
>> $  /gnu/store/dq3817g8w80c9hffbgzspslqjy7szq35-brasero-3.12.1/bin/brasero
>>
>> ** (brasero:21487): WARNING **: Error retrieving accessibility bus address: 
>> org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
>> provided by any .service files
>>
>> (brasero:21487): GLib-GIO-ERROR **: Settings schema 
>> 'org.gnome.brasero.config' is not installed
>>
>> Trace/breakpoint trap (core dumped)
>> --8<---cut here---end--->8---
>>
>> On GuixSD, it starts just fine *if* it is installed in ~/.guix-profile,
>> because XDG_DATA_DIRS and XDG_CONFIG_DIRS are appropriately set.
>>
>> However, on foreign distros, it doesn’t work out of the box.
>>
>> Andy suggests using ‘glib-or-gtk-build-system’ for Brasero, which
>> appears to solve the problem.
>>
>> WDYT?
>
> I think that using the 'glib-or-gtk-build-system' is the right thing
> to do. It will create a wrapper with the correct value of some
> environment variables, enabling the program to find its schema.
Sure, I went ahead and push it.
>
>>
>> Should we add a profile hook similar to ‘gtk-icon-themes’ in (guix
>> profiles) but for schemas?
>
> I do not think so because if a program gets the wrong schema (say, a
> different incompatible version) then it may crash. With the
> 'glib-or-gtk-build-system' it is guaranteed that it will find the
> schema used at build time.
Yes, using the schemas cache built from profile is problematic for
a program, but as long as it was wraped, the profile cache won't be
used.

But the profile cache is required for dconf-editor to be functional,
I'd like to add it.

>
> Speaking of GTK+ applications: I think that removing the generation of
> 'icon-theme.cache' from the 'glib-or-gtk-build-system' was a mistake
> (I may even have suggested this). It is my understanding (see [1, 2])
> that this file is not strictly necessary, however it speeds up things
> and is therefore useful. Having the cache generated by the
> build-system allows one to use the program optimally without having to
> install it into a profile.

Technical right, but since the cache (hicolor) build for the program
only contain it's own icon (eg: evince). For desktop-wide applications
(panel, file managers) this cache is not useful at all.
I guess there won't be much speeds up, need tests to find more detail
though :-)

>
> The icon profile hook is still useful because it allows one to add
> icon themes a posteriori, that is after having build a program
> derivation and without having to rebuild it. The wrapper created by
> 'glib-or-gtk-build-system' still looks in the directories listed in
> XDG_DATA_DIRS (similarly for some other variables). See also the
> discussion at [3].
>
> The reason for removing the phase from the build system was to
> suppress annoying collision warnings, but in my opinion it would be
> better to suppress them in a different way. As long as the profile
> hook is the last derivation being installed in a profile, such
> collisions are harmless and should just be masked.
Yes, remove the phase is an easy way to suppress the warnings for
icon cache. (there still have some programs install the icon cache,
which could be handled per-package IMO.)

We did need to suppress the warnings for the schemas cache.
If just mask the collisions instead of avoid collisions actually
don't have performance issue, I'm ok with it.

>
> Regards,
> Fede
>
> [1] https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html
> [2] 
> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
> [3] https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00108.html

I'd like to do some tests to see how the icon cache is used actually.

Thanks!

bug#21888: guix-publish gets ERROR when serve gtk+.

[宋文武]

can't substitute gtk+ from a guix-publish server, it fails with:

GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2
In web/server/http.scm:
   117:27  1 (http-read #< socket: #)
In unknown file:
   0 (peek-char #)
ERROR: In procedure fport_fill_input: Connection reset by peer

bug#21888: guix-publish gets ERROR when serve gtk+.

[宋文武]

On 2015-11-13 04:28, l...@gnu.org wrote:

宋文武  skribis:


can't substitute gtk+ from a guix-publish server, it fails with:

GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2
In web/server/http.scm:
   117:27  1 (http-read #< socket: #so...>)

In unknown file:
   0 (peek-char #)
ERROR: In procedure fport_fill_input: Connection reset by peer


This means that the *client* closed the connection.  Could you check
what happened on the client side?

It may be more convenient to use wget on the client-side to reproduce
the problem.

OK, I attach logs of:
wget -qd 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2'
wget -qd 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk%2B-3.18.2'



DEBUG output created by Wget 1.16.3 on linux-gnu.

URI encoding = 'ANSI_X3.4-1968'
converted 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk%2B-3.18.2' 
(ANSI_X3.4-1968) -> 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2' (UTF-8)
Caching localhost => ::1 127.0.0.1
Closed fd 3
Created socket 3.
Releasing 0x01448300 (new refcount 1).

---request begin---
GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
User-Agent: Wget/1.16.3 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: localhost:8080
Connection: Keep-Alive

---request end---

---response begin---
HTTP/1.1 404 Not Found
Content-Length: 69
Content-Type: text/plain;charset=utf-8

---response end---
Registered socket 3 for persistent reuse.
URI content encoding = 'utf-8'
Skipping 69 bytes of body: [Resource not found: 
/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.
[IRI fallbacking to non-utf8 for 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk%2B-3.18.2'
Reusing fd 3.

---request begin---
GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk%2B-3.18.2 HTTP/1.1
User-Agent: Wget/1.16.3 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: localhost:8080
Connection: Keep-Alive

---request end---

---response begin---
HTTP/1.1 200 OK
Content-Type: application/x-nix-archive;charset=ISO-8859-1

---response end---
URI content encoding = 'ISO-8859-1'
DEBUG output created by Wget 1.16.3 on linux-gnu.

URI encoding = 'ANSI_X3.4-1968'
converted 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2' 
(ANSI_X3.4-1968) -> 
'http://localhost:8080/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2' (UTF-8)
Caching localhost => ::1 127.0.0.1
Closed fd 3
Created socket 3.
Releasing 0x0218f260 (new refcount 1).

---request begin---
GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
User-Agent: Wget/1.16.3 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: localhost:8080
Connection: Keep-Alive

---request end---

---response begin---
HTTP/1.1 404 Not Found
Content-Length: 69
Content-Type: text/plain;charset=utf-8

---response end---
Registered socket 3 for persistent reuse.
URI content encoding = 'utf-8'
Skipping 69 bytes of body: [Resource not found: 
/nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.

bug#20889: [PATCH] tk: Hardcode path to TK_LIBRARY.

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> 宋文武  skribis:
>
>> From 6c9ea521e88d36bd1ce990a561477ec0e2950017 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
>> Date: Thu, 12 Nov 2015 13:31:19 +0800
>> Subject: [PATCH] tk: Hardcode path to TK_LIBRARY.
>>
>> Fixes <http://bugs.gnu.org/20889>.
>>
>> * gnu/packages/patches/tk-find-library.patch: New patch.
>> * gnu-system.am (dist_patch_DATA): Add it.
>> * gnu/packages/tcl.scm (tk)[source]: Add patch.
>
> [...]
>
>> +++ b/gnu/packages/patches/tk-find-library.patch
>> @@ -0,0 +1,30 @@
>> +This patch hardcode where Tk found its script library during package
>  ^^  
> “This patch hard-codes the Tk library directory during package
> initialization.”
>
> OK with this change.  Thanks for providing a quick fix!  :-)
>
> Could you commit it in a new ‘tk-update’ branch?
Done.
>
> At the same time, I think we should move tkinter*.so to a separate
> output of the Python packages; I think it’s a matter of moving the .so
> to a separate output, literally.  Would you like to give it a try?
I don't know much about python, so I'd like to leave it for others :-)

bug#21888: guix-publish gets ERROR when serve gtk+.

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> 宋文武  skribis:
>
>> ---request begin---
>> GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
>> User-Agent: Wget/1.16.3 (linux-gnu)
>> Accept: */*
>> Accept-Encoding: identity
>> Host: localhost:8080
>> Connection: Keep-Alive
>>
>> ---request end---
>>
>> ---response begin---
>> HTTP/1.1 404 Not Found
>> Content-Length: 69
>> Content-Type: text/plain;charset=utf-8
>>
>> ---response end---
>> Registered socket 3 for persistent reuse.
>> URI content encoding = 'utf-8'
>> Skipping 69 bytes of body: [Resource not found: 
>> /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.
>
> Here ‘guix publish’ returns 404, presumably because
> /gnu/store/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 is not on disk
> or not valid.
>
> Is this correct?
No, the gtk+ item is valid, and replace 'gtk+' with 'gtk%2B' in the url
will make wget download it happily.
>
> Now, does http://localhost/1dlz1am0qmj1579f5p6j5cvfx9l2aw50.narinfo
> return?  It should also return 404, otherwise there’s an
> inconsistency.
for the narinfo, It does return 200.

bug#22755: fixed

[宋文武]

fixed in commit f072e9ad.

bug#22650: guixSD default umask is 0000

[宋文武]

于 2016年3月7日 GMT+08:00下午8:18:44, l...@gnu.org 写到:
>l...@gnu.org (Ludovic Courtès) skribis:
>
>> myglc2  skribis:
>>
>>> glc@g1 ~$ ssh glc4@g1
>>> glc4@g1's password: 
>>> glc4@g1 ~$ umask
>>> 
>>
>> Oh indeed, I can reproduce it.
>>
>> The problem is that lshd resets the umask when it starts (in
>> src/daemon.c:daemon_init) but never changes it again.
>>
>> Perhaps we should be using pam_umask and login.defs (although I’m
>unsure
>> if lshd would honor it), or alternately add explicitly set the umask
>in
>> /etc/profile.
>>
>> Thoughts?
>
>宋文武 & Alex: WDYT?  (Asking you since I know you’re already familiar
>with these things.  :-))
>
>Ludo’.

I never pay attention to umask, but set it in /etc/profile seem the right thing 
to me. IIRC, debian and exherbo set it in there too.

bug#22693: `guix refresh -u` updates other packages with same version

[宋文武]

Leo Famulari  writes:

> I've noticed that `guix refresh -u` will update extraneous packages if
> they happen to have the same version and be in the same module.
>
> For example, from commit d694230ab, you can reproduce the bug:
>
> $ ./pre-inst-env guix environment guix -- ./pre-inst-env guix refresh -u 
> python-pytest
> $ git diff
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 3dd3862..ae14404 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -796,7 +796,7 @@ Python 3 support.")
>  (define-public python-pycrypto
>(package
>  (name "python-pycrypto")
> -(version "2.6.1")
> +(version "2.8.7")
>  (source
>   (origin
>(method url-fetch)
> @@ -1565,7 +1565,7 @@ code introspection, and logging.")
>  (define-public python-pytest
>(package
>  (name "python-pytest")
> -(version "2.6.1")
> +(version "2.8.7")
>  (source
>   (origin
> (method url-fetch)
> @@ -1574,7 +1574,7 @@ code introspection, and logging.")
>   version ".tar.gz"))
> (sha256
>  (base32
> - "0g2w4p0n42wvz8rq4k6gnzpkakgz3g8sfanxk8jrsra9675snkcr"))
> + "1bwb06g64x2gky8x5hcrfpg6r351xwvafimnhm5qxq7wajz8ck7w"))
> (modules '((guix build utils)))
> (snippet
>  ;; One of the tests involves the /usr directory, so it fails.
How to fix this?

The procedure is ‘update-package-source’ in (guix upstream).
it find the file, then use ‘substitute’ to replace the version and
hash.  ‘substitute’ works line-by-line, it can’t match mutiple lines.

I try:
 - use ‘package-location’ and ‘read’ to get the package object,
   but it lost all format and comments.
 - use ‘string-match’, but I have no idea how to match the whole
   package sexp.

bug#22693: close

[宋文武]

fixed in commit 2b8e9d9ed.

bug#23524: Test suite failures building 0.10.0 on CentOS7 - building from git

[宋文武]

"Cook, Malcolm"  writes:

> Ludo!
>
> It has been far too long that I followed up on this.  I have just now return 
> to this project.
>
> Setting HOME, as you last suggested, got me past the `make check` problems 
> from before.  Thank you.
>
> However,  `make check` still apparently halts after:
>
> 
> PASS: tests/guix-package-net.sh
> PASS: tests/guix-package.sh
> PASS: tests/guix-build.sh
> PASS: tests/guix-environment.sh
> PASS: tests/builders.scm
>
> The tests apparently stop running.  Top agrees with me.
>
> At this point, all checks have PASSed  except guix-lint.sh, which is the 
> single file tarred up in checkFAIL.tar.gz
>
> LOG.tar.gz contains logs of stdout/stderr from each step so far:
> bookstrap, configure, make, make check. and also a file detailing the
> version of RPM installed on my CentOS 7 box.
>
> Note - All this is still trying to build based on git, viz:
>
> git clone git://git.savannah.gnu.org/guix.git  --branch v0.10.0  guix
>
>  and still of course performing the ./bootstrap.
>
> I will in a separate message detail what happens when I try and build from 
> the release tarball.
>
> However, I would like to understand what the issues are with building
> using git.  Is there a good explanation on the possible issues that
> are avoided by using the release tarball?
With the release tarball, the ‘configure’ script and documents (man
pages and info) are already built, so autotools, help2man etc. are
not required to build guix.

The failing one in the guix-lint.log:
--8<---cut here---start->8---
<...>
;;; Failed to autoload make-session in (gnutls):
;;; ERROR: missing interface for module (gnutls)
Backtrace:
<...>
In guix/build/download.scm:
 256: 0 [tls-wrap # "static.nvd.nist.gov"]

guix/build/download.scm:256:17: In procedure tls-wrap:
guix/build/download.scm:256:17: In procedure module-lookup: Unbound variable: 
make-session'
<...>
--8<---cut here---end--->8---

It’s due to missing ‘guile-gnutls’ in your host system,
and the ‘cve’ checker of ‘guix lint’ need it to access the URL
through HTTPS.  Seems like we should skip those tests if the gnutls
module is not available.

Once build guix on your host (it uses glibc, guile,
guile-gnutls, etc on your host system), you can install (or without
substitutes, build) guix from guix, which will use glibc,
guile-gnutls, etc in guix (all in /gnu/store).

Thanks your report!

bug#23195: GNOME help does not work

[宋文武]

Chris Marusich  writes:

> Hi,
>
> I'm using GuixSD v0.10.0 with GNOME.  I've noticed that "help" does not
> work.  Specifically, I've observed the following:
>
> * Pressing F1 in any application does not work.  Sometimes (e.g., in the
>   GNOME terminal) you get an error message saying something like "There
>   was an error displaying help / Operation not supported".  Sometimes
>   (e.g., in icecat) nothing at all happens.
>
> * If you run the "Help" application (you can find it in the dashboard
>   under "Show Applications"), you get an error:
>
> Document Not Found
> The URI ‘help:gnome-help/index’ does not point to a valid page.
> Search for packages containing this document.
>
> I know that GNOME documentation is available on the Internet, but it
> would be nice if the built-in GNOME worked, too.  What do we need to do
> to make it work?  How can I investigate further why it is not working?
With the ‘xdg-desktop-database’ hook in commit 842cb820, it should
work now.

bug#23193: Cannot enable logout button in GNOME

[宋文武]

Chris Marusich  writes:

> Hi,
>
> I'm using GuixSD v0.10.0.  The default GNOME installation does not have
> the "log out" button enabled by default.  I've heard that this is the
> new default in GNOME, so it's probably not an issue we need to fix.
> However, I cannot seem to enable it at all.
>
> My understanding is that you should be able to enable the "log out"
> button with a command like the following:
>
> gsettings set org.gnome.shell always-show-log-out true
>
> I've tried this.  Even though running
>
> gsettings get org.gnome.shell always-show-log-out
>
> shows that the setting was stored as 'true' (even after rebooting), the
> "log out" button does not get displayed when I log into GNOME.  Maybe
> I'm looking in the wrong spot: I expected to find it near the "tools"
> and "power" buttons, which are located in the menu that appears when you
> click on the upper right corner of the GUI.
The gsettings trick does work for me, and the “Log Out” action will under
the ‘User’ menu (it’s below the ‘Battery’ menu, only icon and no name).

bug#23260: (wxmaxima) crash: GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' is not installed

[宋文武]

Danny Milosavljevic  writes:

> I finally got to the bottom of it.
>
> It says:
>
>   (wxmaxima:27910): GLib-GIO-ERROR **: Settings schema 
> 'org.gtk.Settings.FileChooser' is not installed
>
> and it's right. I'm not sure how it's supposed to find them.
>
> On this GuixSD installation I only have a minimal number of packages
> in the operating-system definition of the system profile (and gtk is
> not in it). I have installed gtk into my user's profile but I really
> shouldn't have to, right? (and it still doesn't work)
>
> However, lots of programs use gtk. If they do, they'll sooner or later need 
> the filechooser. However, gtk-3 filechooser needs its settings schema.
>
> Environment variables with "GTK" in the name are:
>
> GTK_DATA_PREFIX=/run/current-system/profile
> GTK_PATH=/gnu/store/mjjkx5fq0gn5bg89pz2gsipjs975m2im-gtk+-3.18.2/lib/gtk-3.0
> GUIX_GTK3_PATH=/home/dannym/.guix-profile/lib/gtk-3.0:/home/dannym/.guix-profile/lib/gtk-3.0
>
> But the schema 'org.gtk.Settings.FileChooser' is not found since it's in:
>
>   
> /gnu/store/mjjkx5fq0gn5bg89pz2gsipjs975m2im-gtk+-3.18.2/share/glib-2.0/schemas
>
> which is installed nowhere. I know I can easily workaround this by
> manually installing it in the system profile - but shouldn't it be
> solved in some better manner?

Yes, as you found, the FileChooser schema must be known by wxmaxima
via GSETTINGS_SCHEMA_DIR or XDG_DATA_DIRS.

There is a `glib-or-gtk-build-system', when use it, all executables
will be wraped with XDG_DATA_DIR, combining from inputs's $out/share
directories.  Currently, applications using gsettnigs can be handled
this way or wrap it manually using `wrap-program'.


Thanks for your report, I fixed this specified issue
in commit de477809d773.

bug#23195: fixed

[宋文武]

fixed in commit de477809d773.

bug#23001: emacs in X has icons missing and throws warnings in tty

[宋文武]

Well, now the gtk+ is linked with gdk-pixbuf+svg, with
adwaita-icon-theme and shared-mime-info (used by gdk-pixbuf at runtime)
all my Emacs toolbar icons are missing (empty), but without any warning.

bug#24188: gnucash needs gtk+ in propagated-inputs

[宋文武]

Arun Isaac  writes:

>> The following environment variables are set which may make a difference
>> here:
>>
>>   GUIX_GTK3_PATH=/run/current-system/profile/lib/gtk-3.0
>>   GUIX_GTK2_PATH=/run/current-system/profile/lib/gtk-2.0
>>   GTK_DATA_PREFIX=/run/current-system/profile
>
> After setting XDG_DATA_DIRS with
>
> export 
> XDG_DATA_DIRS="/gnu/store/zlr5l39k9gw7ss26iq6vj3yk215xrzpl-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
>
> gnucash runs successfully. I found out about this using `guix
> environment --search-paths gnucash`.
>
> How do I find out about these environment variables in general?
> Shouldn't they be set in the gnucash wrapper script so that the user
> does not have to set them manually?

--8<---cut here---start->8---
gnc.gui:ERROR:gnc-icons.c:96:gnc_add_stock_icon_pair: assertion failed: 
(pixbuf1 && pixbuf2)
fish: 'gnucash' terminated by signal SIGABRT (Abort)
--8<---cut here---end--->8---

I think this error is caused by gdk-pixbuf, which uses XDG mime-info
database to query file types.  Install the 'shared-mime-info' package
to activate the 'xdg-mime-database' profile hook should make it works.


To actually fix this package (and some others) we can:

- Wrap them with shared-mime-info in XDG_DATA_DIRS or propagated it.

- Make sure 'xdg-mime-database' always run if glib applications are
  there even without shared-mime-info referenced by profile.  
  IIRC, this was suggested by ludo, but I ignored, now patch sent :-)
  

bug#24327: java does not support swing

[宋文武]

Alex Vong  writes:

> Hi,
>
> Our current java does not support swing. To reproduce, first install
> java and clojure. Then start the clojure repl by running:
>   $ ~/.guix-profile/bin/java -cp ~/.guix-profile/share/java/clojure-1.8.0.jar 
> clojure.main
>
> Then try the repl by typing:
>   => (+ 1 2 3)
>   6
>
> Now run:
>   => (javax.swing.JOptionPane/showMessageDialog nil "Hello World")
>   NullPointerException   sun.awt.FontConfiguration.getVersion 
> (FontConfiguration.java:1264)
>
> Note that the above test case is taken from
> .
>
> In contrast, if we replace ~/.guix-profile/bin/java by /usr/bin/java in
> the command, we do not get a nullpointerexception (my base distro is
> debian testing). So there should be a problem in our java build. Any
> ideas? 

Yeah, openjdk-8 loads fontconfig via dlopen.

Fixed in commit cab1760de.

bug#25537: gtksourceview-2 has xorg-server and shared-mime-info as inputs rather than native-inputs (they are just required for tests)

[宋文武]

Danny Milosavljevic  writes:

> (define-public gtksourceview-2
>   (package
> (name "gtksourceview")
> (version "2.10.5") ; This is the last version which builds against gtk+2
> (source (origin
>   (method url-fetch)
>   (uri (string-append "mirror://gnome/sources/" name "/"
>   (version-major+minor version)  "/"
>   name "-" version ".tar.bz2"))
>   (sha256
>(base32
> "07hrabhpl6n8ajz10s0d960jdwndxs87szxyn428mpxi8cvpg1f5"
> (build-system gnu-build-system)
> (inputs
>  `(("gtk" ,gtk+-2)
>;; These two are needed only to allow the tests to run successfully.
>("xorg-server" ,xorg-server) ;  <== ?!
>("shared-mime-info" ,shared-mime-info))) ;  <== ?!
> (native-inputs
>  `(("intltool" ,intltool)
>("glib" ,glib "bin") ; for glib-genmarshal, etc.
>("pkg-config" ,pkg-config)))
>
> Why?
>
> Also, gtksourceview (without -2) doesn't. Weird...

Well i guess it's just being unnoticed, fixed in commit bd05ea41b.

Thank you!

bug#25457: assword: gui: Namespace Gtk not available

[宋文武]

Ivan Vilata i Balaguer  writes:

> Hi, when running ``assword gui`` from Assword 0.10 I get the following error:
>
> ```
> Traceback (most recent call last):
>   File 
> "/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/bin/.assword-real", 
> line 9, in 
> load_entry_point('assword==0.10', 'console_scripts', 'assword')()
>   File 
> "/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/lib/python3.5/site-packages/assword/__main__.py",
>  line 553, in main
> func(args)
>   File 
> "/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/lib/python3.5/site-packages/assword/__main__.py",
>  line 327, in gui
> from assword.gui import Gui
>   File 
> "/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/lib/python3.5/site-packages/assword/gui.py",
>  line 2, in 
> gi.require_version('Gtk', '3.0')
>   File 
> "/gnu/store/hii5dmg5qyawx6a883203dcxhbagmgrd-python-pygobject-3.20.0/lib/python3.5/site-packages/gi/__init__.py",
>  line 102, in require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace Gtk not available
> ```
>
> Other commands not using the GUI work ok.  The error does not show with 
> Assword 0.8.
>
> ```
> $ guix package -I | grep assword
> assword 0.10out 
> /gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10
> ```
>
> Thank you!

Fixed in commit 0050876bcf, thank you!

bug#28088: "The name org.a11y.Bus was not provided by any .service files" with multiple applications

[宋文武]

ng0  writes:

> ng0 transcribed 1.6K bytes:
>> Upon starting for example emacs in spectrwm I get this message:
>> [1]   Doneemacs
>> user@abyayala ~$
>> ** (emacs-25-2:19121): WARNING **: Error retrieving accessibility
>> bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name
>> org.a11y.Bus was not provided by any .service files
>> 
>> It works alright, but I have seen the exact same message while
>> trying to figure out why mate-terminal does not start.
>> -- 
>> ng0
>> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
>> GnuPG: https://n0is.noblogs.org/my-keys
>> https://www.infotropique.org https://krosos.org
>
> It is worth mentioning that this only happens with a
> desktop-services ressembling services list + no xfce-service
> or gnome-service in the system config.
>
> Reconfiguring and adding GNOME, switching tp GNOME makes
> this message not appear. We need to narrow down where
> this error comes from.

GTK+ applications will provide accessibility support over this dbus
service, so the AT-SPI clients (screen reader etc.) could use them.

And this 'org.a11y.Bus' service can be auto activated by the dbus
session daemon if the 'at-spi2-core' package is available.  If not,
we'll get thoese warnning from applications.

Usually they're harmless, and can be suppressed by set the environment
variable 'NO_AT_BRIGE=1'.

bug#28088: "The name org.a11y.Bus was not provided by any .service files" with multiple applications

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> GTK+ applications will provide accessibility support over this dbus
>> service, so the AT-SPI clients (screen reader etc.) could use them.
>>
>> And this 'org.a11y.Bus' service can be auto activated by the dbus
>> session daemon if the 'at-spi2-core' package is available.  If not,
>> we'll get thoese warnning from applications.
>
> It does sound like our GuixSD setup fails to activate org.a11y.Bus
> though.  Should we add a service in %desktop-services that extends
> ‘dbus-root-service-type’ with ‘at-spi2-core’ to ensure that
> auto-activation works?

It's not a dbus system service, we can extend 'profile-service-package'
with 'at-spi2-core' to make it available for the user's dbus session
daemon.

>
> I think we should strive to provide accessible environments when
>possible, as with GNOME.

Yes, but without a client (we only have 'orca') the AT-SPI service alone
is not useful, maybe we should add Orca to both GNOME and Xfce? (I'm not
a user of any, so can't be sure.)

bug#28756: Substitute download progress bar doesn't reach 100%

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Leo Famulari  skribis:
>
>> I just upgraded to the latest Guix and, while downloading substitutes, I
>> noticed the progress bar seems to never reach 100%, as shown below. I'm
>> not sure if this started recently or not.
>>
>> Downloading 
>> https://mirror.hydra.gnu.org/guix/nar/gzip/drm4pj1k5mkb5784i0rkqb0bg2z8lmyw-libabw-0.1.1...
>>  libabw-0.1.1  346KiB
>
> Indeed, I’ve noticed too, and I think it relates to the new progress
> reporters.  宋文武, do you experience this as well?  Thoughts?
>

Yes, thanks for the report, commit abaee53c8 should fix it.

I thought close the 'input' port in the 'progress-substitution' will
close the 'progress' port too, but it's not true.

bug#28756: Substitute download progress bar doesn't reach 100%

[宋文武]

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

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello,
>>
>> Leo Famulari  skribis:
>>
>>> I just upgraded to the latest Guix and, while downloading substitutes, I
>>> noticed the progress bar seems to never reach 100%, as shown below. I'm
>>> not sure if this started recently or not.
>>>
>>> Downloading 
>>> https://mirror.hydra.gnu.org/guix/nar/gzip/drm4pj1k5mkb5784i0rkqb0bg2z8lmyw-libabw-0.1.1...
>>>  libabw-0.1.1  346KiB
>>
>> Indeed, I’ve noticed too, and I think it relates to the new progress
>> reporters.  宋文武, do you experience this as well?  Thoughts?
>>
>
> Yes, thanks for the report, commit abaee53c8 should fix it.
>

Well, it didn't...  I have to learn it's a child process will read and
report the process:

>From 93b42f62ece1ad5181ed1119fc750bcbb74c5d3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 14 Oct 2017 22:45:55 +0800
Subject: [PATCH] guix: substitute: Report the last process in the child
 process.

Fixes <https://bugs.gnu.org/28756>.

* guix/utils.scm (filtered-port): Close the 'input' port in the child process.
* guix/scripts/substitute.scm (progress-substitution): Close the 'progress'
port before 'restore-file'.
---
 guix/scripts/substitute.scm | 10 ++
 guix/utils.scm  |  1 +
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index 921a7c679..d175d3e84 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -959,16 +959,18 @@ DESTINATION as a nar file.  Verify the substitute against ACL."
(decompressed-port (and=> (narinfo-compression narinfo)
  string->symbol)
   progress)))
+  ;; A child process of 'decompressed-port' will read from this 'process'
+  ;; port and thus report the actual progress to the console.  As the
+  ;; parent process, we should close it at the start.
+  (close-port progress)
   ;; Unpack the Nar at INPUT into DESTINATION.
   (restore-file input destination)
   (close-port input)
-  (close-port progress)
+  (every (compose zero? cdr waitpid) pids)
 
   ;; Skip a line after what 'progress-reporter/file' printed, and another
   ;; one to visually separate substitutions.
-  (display "\n\n" (current-error-port))
-
-  (every (compose zero? cdr waitpid) pids
+  (display "\n\n" (current-error-port)
 
 
 ;;;
diff --git a/guix/utils.scm b/guix/utils.scm
index de4aa6531..f8cf11ccb 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -153,6 +153,7 @@ buffered data is lost."
   (close-port in)
   (dump-port input out))
 (lambda ()
+  (close input)
   (false-if-exception (close out))
   (primitive-_exit 0
  (child
-- 
2.13.3


With this patch, update the guix snapshot and do a system reconfigure,
this issue should be fixed!

bug#28756: Substitute download progress bar doesn't reach 100%

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> iyzs...@member.fsf.org (宋文武) writes:
>>
>>> l...@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Hello,
>>>>
>>>> Leo Famulari  skribis:
>>>>
>>>>> I just upgraded to the latest Guix and, while downloading substitutes, I
>>>>> noticed the progress bar seems to never reach 100%, as shown below. I'm
>>>>> not sure if this started recently or not.
>>>>>
>>>>> Downloading 
>>>>> https://mirror.hydra.gnu.org/guix/nar/gzip/drm4pj1k5mkb5784i0rkqb0bg2z8lmyw-libabw-0.1.1...
>>>>>  libabw-0.1.1  346KiB
>>>>
>>>> Indeed, I’ve noticed too, and I think it relates to the new progress
>>>> reporters.  宋文武, do you experience this as well?  Thoughts?
>>>>
>>>
>>> Yes, thanks for the report, commit abaee53c8 should fix it.
>>>
>>
>> Well, it didn't...  I have to learn it's a child process will read and
>> report the process:
>>
>> From 93b42f62ece1ad5181ed1119fc750bcbb74c5d3c Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
>> Date: Sat, 14 Oct 2017 22:45:55 +0800
>> Subject: [PATCH] guix: substitute: Report the last process in the child
>>  process.
>>
>> Fixes <https://bugs.gnu.org/28756>.
>>
>> * guix/utils.scm (filtered-port): Close the 'input' port in the child 
>> process.
>> * guix/scripts/substitute.scm (progress-substitution): Close the 'progress'
>> port before 'restore-file'.
>
> [...]
>
>> +  ;; A child process of 'decompressed-port' will read from this 
>> 'process'
>   
> ^
> … will read from PROGRESS
>
>> +  ;; port and thus report the actual progress to the console.  As the
>> +  ;; parent process, we should close it at the start.
>> +  (close-port progress)
>>;; Unpack the Nar at INPUT into DESTINATION.
>>(restore-file input destination)
>>(close-port input)
>> -  (close-port progress)
>> +  (every (compose zero? cdr waitpid) pids)
>
> Since INPUT is a wrapper around PROGRESS, it seems weird to close
> PROGRESS beforehand.
>
> Shouldn’t ‘filtered-port’ always close INPUT in the parent process (the
> second part of the patch you sent closes it in the child process before
> quitting, but we should additionally close it in the parent):
>

Yes, it makes sense:

>From 6a3fa69f96fc2e3e074a9275066640ddfee57fd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 14 Oct 2017 22:45:55 +0800
Subject: [PATCH] guix: substitute: Report the last progress in the child
 process.

Fixes <https://bugs.gnu.org/28756>.

* guix/utils.scm (filtered-port): Close the 'input' port for the current
process, and close it upon exit in the child process.
* guix/scripts/substitute.scm (progress-substitution): Display "\n\n" after
the reporter has finished.
---
 guix/scripts/substitute.scm | 11 +++
 guix/utils.scm  |  2 ++
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index 921a7c679..60dbdb176 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -956,19 +956,22 @@ DESTINATION as a nar file.  Verify the substitute against ACL."
  #:abbreviation nar-uri-abbreviation)))
  (progress-report-port reporter raw)))
   ((input pids)
+   ;; NOTE: This 'progress' port of current process will be
+   ;; closed here, while the child process doing the
+   ;; reporting will close it upon exit.
(decompressed-port (and=> (narinfo-compression narinfo)
  string->symbol)
   progress)))
   ;; Unpack the Nar at INPUT into DESTINATION.
   (restore-file input destination)
   (close-port input)
-  (close-port progress)
+
+  ;; Wait for the reporter to finish.
+  (every (compose zero? cdr waitpid) pids)
 
   ;; Skip a line after what 'progress-reporter/file' printed, and another
   ;; one to visually separate substitutions.
-  (display "\n\n" (current-error-port))
-
-  (every (compose zero? cdr waitpid) pids
+  (display "\n\n" (current-error-port)
 
 
 ;;;
diff --git a/guix/utils.scm b/guix/utils.scm
index de4aa6531..2cf9be36d 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -153,9 +153,11 @@ buffered data is lost."
   (close-port in)
   (dump-port input out))
 (lambda ()
+  (close-port input)
   (false-if-exception (close out))
   (primitive-_exit 0
  (child
+  (close-port input)
   (close-port out)
   (loop in (cons child pids)
 
-- 
2.13.3



Thanks for the help and review!

bug#28756: Substitute download progress bar doesn't reach 100%

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> iyzs...@member.fsf.org (宋文武) skribis:
>
>> From 6a3fa69f96fc2e3e074a9275066640ddfee57fd2 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
>> Date: Sat, 14 Oct 2017 22:45:55 +0800
>> Subject: [PATCH] guix: substitute: Report the last progress in the child
>>  process.
>>
>> Fixes <https://bugs.gnu.org/28756>.
>>
>> * guix/utils.scm (filtered-port): Close the 'input' port for the current
>> process, and close it upon exit in the child process.
>> * guix/scripts/substitute.scm (progress-substitution): Display "\n\n" after
>> the reporter has finished.
>
> LGTM!
>
> You could commit the utils.scm change separately because it’s a bug-fix
> in its own right.
>

Pushed, thanks!  I think the utils.scm change alone (without the remove
of '(close-port progress') and comment) didn't fix this particular bug
clearly so I didn't seperate it..

bug#29644: gcc-objc is unusable without its 'gcc' executable

[宋文武]

Hello, unlike fortran program files which can be compiled using the
command 'gfortran' (in addition to 'gcc'), there is no other command for
Objective-C program files, and run 'gcc -c x.m' using the 'gcc' package
will just complain "Objective-C compiler not installed on this system"
due to it lacking objc support.

I have to revert commit 82f145ef7a to get a objc enabled 'gcc' in the
'gcc-objc' package.

IIUC, the purpose of that commit is to avoid file collisions between
'gfortran' and the 'gcc' package used in the 'gnu-build-system', which
will broke the compiler in some way.  So I think we really want to only
have one gcc package in an environment...

How about enable all languages (except 'brig' which I never heard of)
for the gcc-final and the 'gcc' (in gcc.scm) packages?  In this way, I
think 'gnu-build-system' and 'gcc-toolchain' will able to compile
Fortran, Objective-C, Go, etc. out of the box.

bug#30623: cdogs-sdl builds but cannot be run

[宋文武]

Nicolas Goaziou  writes:

> Hello,
>
> The package cdogs-sdl (release 0.6.6) seems to build fine, i.e., it is
> successfully added to the store. Yet, whenever I try to run it with
> "cdogs-sdl" command, it stops with a floating point exception.
>

Hello, I just updated the cdogs-sdl package to the latest git version,
which should fix this issue now.

Thanks for the report!

bug#30776: FVWM provides no .desktop file

[宋文武]

ng0  writes:

> When adding FVWM to the system profile and not using startx or something
> like adding fvwm execution to the file in $HOME the login manager would
> source, it does not appear in the selection of window managers to start.
>
> We should install a .desktop file for it.

Hello, as your commit c217df913e00327f5c9b779fd97e222c4c22dab9 had fix
this, so I close this bug now.  Thanks!

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

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> For those who haven’t been following along on
> , I have just
> pushed a new ‘guix pull’.
>
> To summarize, ~/.config/guix/latest no longer exists.  Instead
> ~/.config/guix/current is populated with a complete Guix (without
> ‘guix-daemon’ though), including an up-to-date manual and so on.
> ~/.config/guix/current is a regular profile, meaning that you can
> roll-back to a previously-pulled Guix and so on.

Great!


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.

I think we should make ‘INFOPATH’ a search path of the ‘current’ guix
profile, so that it overrides previous ones.

bug#31769: mpd / pulse control issue

[宋文武]

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:
.

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#31770: New ‘guix pull’ dosen’t update the guix manual in GuixSD

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

>> 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?

Yeah, that's fine.  Maybe add comments about why source ‘current’ after
user profile (prefer current guix) and why ‘export INFOPATH’ at the end
(prefer the current guix manual).  Thank you!

bug#31661: Musescore broke after last Qt update (5.11)

[宋文武]

Nicolas Goaziou  writes:

> Hello,
>
> Since Qt update, building Musescore consistently fails with the
> following error message:
>
> [ 73%] Building CXX object mscore/CMakeFiles/mscore.dir/musescore.cpp.o
> In file included from 
> /tmp/guix-build-musescore-2.2.1.drv-0/MuseScore-2.2.1/mscore/musescore.cpp:109:0:
> 
> /tmp/guix-build-musescore-2.2.1.drv-0/MuseScore-2.2.1/mscore/startcenter.h:20:20:
>  fatal error: QWebView: No such file or directory
> compilation terminated.
> make[3]: *** [mscore/CMakeFiles/mscore.dir/build.make:1365: 
> mscore/CMakeFiles/mscore.dir/musescore.cpp.o] Error 1
>
> I'm not sure about how to fix it at this point.
>

Hello, Since you have actually fixed it in commit 1bfde769, closing now.

Thanks for the report and fix!

bug#22137: Status: python-urwid on x86_64: AsyncEventLoopTest

[宋文武]

Maxim Cournoyer  writes:

> This bug was supposedly fixed upstream [0] but there is no new release
> yet. To be revisited after urwid 1.3.2 is released.
>
> [0]: https://github.com/urwid/urwid/issues/164

Hello, I update our urwid to version 2.0.1.

Closing now, thanks!

bug#31591: [bug#31934] [PATCH] services: sound: Properly handle alsa-plugins.

[宋文武]

Oleg Pykhalov  writes:

> Hello,
>
> iyzs...@member.fsf.org (宋文武) writes:
>
>> Julien Lepiller  writes:
>
> […]
>
>> Hello, after some hours of searching...  I found that we can use the
>> 'lib' option in 'pcm_type' and 'ctl_type' to specify the library path
>> for alsa plugins, e.g:
>
> Thats a nice hack :-)  Thank you for working on this.
>
> […]
>
>> So I think we can make our 'alsa-service' do this, instead of patching
>> alsa-lib for 'ALSA_PLUGIN_DIR'.
>
> Done.  Here is a patch which I tested on my machine by ‘system reconfigure’:
>

Thank you, I modified it to keep the 'pulseaudio? #f' function, and
pushed :-)

bug#32650: Nitpicking perl description

[宋文武]

Alex Kost  writes:

> I have noticed that description of the 'perl' package is:
>
> "Perl 5 is a highly capable, feature-rich programming language with over
> 24 years of development."
>
> Mentioning 24 years seems strange to me.  Well, of course, "over 24
> years" will always be correct (as well as "over 1 year"), but still
> :-)

Yeah, and now it's “over 30 years of developemnt”:  http://www.perl.org/

I went ahead and change it to the description statement from
‘perlintro’.  

Thanks!

bug#44924: guix build u-boot-pinebook --with-git-url failed due to "source" in C_INCLUDE_PATH

[宋文武]

Running:
  guix build u-boot-pinebook \
--with-git-url=u-boot-pinebook=https://github.com/u-boot/u-boot

Would fail with "fatal error: asm/string.h: No such file or directory".

And it's caused by the first entry in C_INCLUDE_PATH, which is
"/gnu/store/xxx-u-boot-xxx/include".

I think we should filter out "source" in `set-paths` of the
`gnu-build-system`.

bug#44924: guix build u-boot-pinebook --with-git-url failed due to "source" in C_INCLUDE_PATH

[宋文武]

Ludovic Courtès  writes:

> Hi,
>
> 宋文武  skribis:
>
>> Running:
>>   guix build u-boot-pinebook \
>> --with-git-url=u-boot-pinebook=https://github.com/u-boot/u-boot
>>
>> Would fail with "fatal error: asm/string.h: No such file or directory".
>>
>> And it's caused by the first entry in C_INCLUDE_PATH, which is
>> "/gnu/store/xxx-u-boot-xxx/include".
>
> Why don’t we have that problem when omitting ‘--with-git-url’?

When not use git, source is a tarball, not a directory, so it's ignored
by "set-paths".

>
>> I think we should filter out "source" in `set-paths` of the
>> `gnu-build-system`.
>
> Yes, sounds like a good idea.  We can do it in ‘core-updates’.

Here is patch:

>From 77283132c6eeeb75900afad5782b989ceee1506a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 5 Dec 2020 11:35:37 +0800
Subject: [PATCH] build-system/gnu: Remove the source directory from search
 paths.

Fixes <https://issues.guix.gnu.org/44924>.

* guix/build/gnu-build-system.scm (set-paths): Delete 'source' from
'input-directories'.
---
 guix/build/gnu-build-system.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index 5f08b9d6ac..f9e6f5013d 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -72,7 +72,9 @@ See https://reproducible-builds.org/specs/source-date-epoch/.";
 (search-paths '()) (native-search-paths '())
 #:allow-other-keys)
   (define input-directories
-(match inputs
+;; The "source" input can be a directory, but we don't want it for search
+;; paths.  See <https://issues.guix.gnu.org/44924>.
+(match (alist-delete "source" inputs)
   (((_ . dir) ...)
dir)))
 
-- 
2.29.1



Thanks!

bug#44924: guix build u-boot-pinebook --with-git-url failed due to "source" in C_INCLUDE_PATH

[宋文武]

> LGTM!
>
> You can push it right away to ‘core-updates’, but since it triggers a
> full rebuild, now’s a good time to push another change that triggers a
> full rebuild.  :-)
>

Pushed bravely, thank you!

bug#45404: kiwix-desktop does not start

[宋文武]

Maxime Devos  writes:

> Hello Guix,

Hello!
>
> kiwix-desktop doesn't start. Depending on the environment, I get
> different error messages:
>
> Variant #A (pure environment, in GDM session)
> $ guix time-machine --commit=20a687bbfbc72ffcd802b4bc59db344ad4291577
> environment --ad-hoc --pure kiwix-desktop -- kiwix-desktop
With ‘–-pure’, the process will run in a container that doesn’t have
access to the X server, this is expected behavior.


> Variant #B (installed in user profile, in GDM session)
>
> $ kiwix-desktop
>
>> Could not find QtWebEngineProcess
This is a bug, look like kiwix-desktop should be wrapped with some
environment variables.  In the meantime, you can install qtwebengine and
qtbase into the profile, or use: guix environment --ad-hoc kiwix-desktop
qtbase qtwebengine -- kiwix-desktop

bug#46398: hedgewars 1.0.0 fails to build again

[宋文武]

"bdju"  writes:

> Apparently there were issues back in August. Version number is still
> 1.0.0. Current build has been failing a couple weeks maybe.
> Build log here: http://ix.io/2OPc
> guix version: guix (GNU Guix) b421b2f66ec5b39bd1331e276bff5f9698cd65dc
> I am using Guix System.

Hello, thanks for the report.

Fixed in commit c7296465cff593bd3c82c7152e09f4337252ce4d.

bug#46269: first guix-pull on foreign distro doesn't create directories

[宋文武]

Leo Famulari  writes:

> On Wed, Feb 03, 2021 at 01:19:22PM +0200, Efraim Flashner wrote:
>> I just installed guix on a foreign distro. In my $HOME I didn't have a
>> .config directory.
>> 
>> (ins)efraimf@tux03:~$ time guix pull 
>> --commit=1b3dcb3dd266fda9732b7a8194bd24e80043fb7a
>> guix pull: error: while creating symlink 
>> '/home/efraimf/.config/guix/current': No such file or directory
>> 
>> Only after creating $HOME/.config/guix did guix pull work.
>
> This happens on Guix System too, at least when starting with `guix
> system vm-image`.

Fixed in commit 5207c5eb5, thanks!

bug#46481: "guix download" with ftp URL doesn't work on IPv6 network

[宋文武]

Danny Milosavljevic  writes:

> I strongly suspect there to be some problem with the ftp client since
> that's the second file that doesn't work using guix download but does work
> using wget, on the same computer.
>
> $ guix download ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2
>
> Starting download of /tmp/guix-file.tORPhj
> From ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2...
> Throw to key `ftp-error' with args `(# "PASV" 425 
> "You cannot use PASV on IPv6 connections. Use EPSV instead.\r")'.
> failed to download "/tmp/guix-file.tORPhj" from 
> "ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2";
> guix download: error: ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2: 
> download failed

Yes, with this patch I can get it work:
>From 568ea9cc0e07eab24c7d24e228d7d391f191feca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 14 Feb 2021 12:02:57 +0800
Subject: [PATCH] ftp-client: Before 'PASV', try 'EPSV' first for IPv6.

This fixes .

* guix/ftp-client.scm (ftp-epsv, ftp-passive): New procedure.
(ftp-list, ftp-retr): Replace call to 'ftp-pasv' with 'ftp-passive'.
---
 guix/ftp-client.scm | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/guix/ftp-client.scm b/guix/ftp-client.scm
index 8d5adcb8ed..a72057d3f5 100644
--- a/guix/ftp-client.scm
+++ b/guix/ftp-client.scm
@@ -216,6 +216,19 @@ TIMEOUT, an ETIMEDOUT error is raised."
   (else
(throw 'ftp-error conn "PASV" 227 message)
 
+(define (ftp-epsv conn)
+  (let* ((message (%ftp-command "EPSV" 229 (ftp-connection-socket conn
+(string->number
+ (match:substring
+  (string-match "\\(...([0-9]+).\\)" message) 1
+
+(define (ftp-passive conn)
+  "Enter passive mode using EPSV or PASV, return a data connection port on
+success."
+  ;; IPv6 only works with EPSV, so try it first.
+  (or (false-if-exception (ftp-epsv conn))
+  (ftp-pasv conn)))
+
 (define (address-with-port sa port)
   "Return a socket-address object based on SA, but with PORT."
   (let ((fam  (sockaddr:fam sa))
@@ -232,7 +245,7 @@ TIMEOUT, an ETIMEDOUT error is raised."
   (if directory
   (ftp-chdir conn directory))
 
-  (let* ((port (ftp-pasv conn))
+  (let* ((port (ftp-passive conn))
  (ai   (ftp-connection-addrinfo conn))
  (s(socket (addrinfo:fam ai) (addrinfo:socktype ai)
(addrinfo:protocol ai
@@ -281,7 +294,7 @@ must be closed before CONN can be used for other purposes."
   ;; Ask for "binary mode".
   (%ftp-command "TYPE I" 200 (ftp-connection-socket conn))
 
-  (let* ((port (ftp-pasv conn))
+  (let* ((port (ftp-passive conn))
  (ai   (ftp-connection-addrinfo conn))
  (s(with-fluids ((%default-port-encoding #f))
  (socket (addrinfo:fam ai) (addrinfo:socktype ai)
-- 
2.30.0


Okay to push?

bug#46481: "guix download" with ftp URL doesn't work on IPv6 network

[宋文武]

Danny Milosavljevic  writes:

> LGTM!

Pushed to master, thank you!

bug#34407: [PATCH] shepherd: Delete the socket file upon exit.

[宋文武]

Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
script too...

According to 'man 2 bind', the socket pathname should be deleted when no
longer required, so a patch to fix this bug:

>From f171f6adb2fc6ee3bf4d25378c2e7bba109b43d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 17 Feb 2019 11:27:28 +0800
Subject: [PATCH] shepherd: Delete the socket file upon exit.

Fixes .

* modules/shepherd.scm (call-with-server-socket): New procedure.
(main): Use it instead of 'open-server-socket'.
---
 modules/shepherd.scm | 65 ++--
 1 file changed, 39 insertions(+), 26 deletions(-)

diff --git a/modules/shepherd.scm b/modules/shepherd.scm
index e241e7a..314b989 100644
--- a/modules/shepherd.scm
+++ b/modules/shepherd.scm
@@ -49,6 +49,17 @@
   (listen sock 10)
   sock)))
 
+(define (call-with-server-socket file-name proc)
+  "Call PROC, passing it a listening socket at FILE-NAME and deleting the
+socket file at FILE-NAME upon exit of PROC.  Return the values of PROC."
+  (let ((sock (open-server-socket file-name)))
+(dynamic-wind
+  noop
+  (lambda () (proc sock))
+  (lambda ()
+(close sock)
+(delete-file file-name)
+
 
 ;; Main program.
 (define (main . args)
@@ -256,32 +267,34 @@
   ;; Get commands from the standard input port.
   (process-textual-commands (current-input-port))
   ;; Process the data arriving at a socket.
-  (let ((sock   (open-server-socket socket-file)))
-
-;; Possibly write out our PID, which means we're ready to accept
-;; connections.  XXX: What if we daemonized already?
-(match pid-file
-  ((? string? file)
-   (with-atomic-file-output pid-file
- (cute display (getpid) <>)))
-  (#t (display (getpid)))
-  (_  #t))
-
-(let next-command ()
-  (define (read-from sock)
-(match (accept sock)
-  ((command-source . client-address)
-   (setvbuf command-source (buffering-mode block) 1024)
-   (process-connection command-source))
-  (_ #f)))
-  (match (select (list sock) (list) (list) (if poll-services? 0.5 #f))
-(((sock) _ _)
- (read-from sock))
-(_
- #f))
-  (when poll-services?
-(check-for-dead-services))
-  (next-command)))
+  (call-with-server-socket
+   socket-file
+   (lambda (sock)
+
+ ;; Possibly write out our PID, which means we're ready to accept
+ ;; connections.  XXX: What if we daemonized already?
+ (match pid-file
+   ((? string? file)
+(with-atomic-file-output pid-file
+  (cute display (getpid) <>)))
+   (#t (display (getpid)))
+   (_  #t))
+
+ (let next-command ()
+   (define (read-from sock)
+ (match (accept sock)
+   ((command-source . client-address)
+(setvbuf command-source (buffering-mode block) 1024)
+(process-connection command-source))
+   (_ #f)))
+   (match (select (list sock) (list) (list) (if poll-services? 0.5 #f))
+ (((sock) _ _)
+  (read-from sock))
+ (_
+  #f))
+   (when poll-services?
+ (check-for-dead-services))
+   (next-command
 
 ;; Start all of SERVICES, which is a list of canonical names (FIXME?),
 ;; but in a order where all dependencies are fulfilled before we
-- 
2.19.2

bug#34407: [PATCH] shepherd: Delete the socket file upon exit.

[宋文武]

Danny Milosavljevic  writes:

> On Sun, 17 Feb 2019 11:38:16 +0800
> iyzs...@member.fsf.org (宋文武) wrote:
>
>> Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
>> script too...
>> 
>> According to 'man 2 bind', the socket pathname should be deleted when no
>> longer required, so a patch to fix this bug:
>
> Hmm, I guess you can do that.
>
> But /run is supposed to be a tmpfs and elogind is supposed to rm -rf 
> /run/user/1000
> after all sessions of that user terminated in any case, so how is it left over
> in the first place?
>

Well, maybe the elogind version I used didn't have this feature, or I
had another user session running...

> If the deletion in the case above doesn't work, please report a bug.

Thanks, good to know, and it indeed works.

>
> If that patch is only in order to enable users to restart user's shepherd
> without exiting all their sessions, then I guess that's ok--although unusual.
>
> Does your patch do the right thing if the user's shepherd is already
> running? (i.e. keep the socket file)

Yes, it deletes the socket file at exit (not at startup).

bug#37209: [PATCH] gnu: libvirt: Don't wrap with PATH

[宋文武]

Hello, this patch will make libvirt use
  "/run/current-system/profile/bin/qemu-system-x86_64"
in machine's definition, and it can use 'ovs-vsctl' in PATH:

>From e463ef6952009a46c96981df0647cee414fb71a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Wed, 28 Aug 2019 20:49:40 +0800
Subject: [PATCH] gnu: libvirt: Don't wrap with PATH.

This reverts commit 903e051a71467bc96a054c9b4ed89348fdae8977 to fix
.  The full path of the 'ip' command is already
embedded, and we want to search 'qemu' in PATH.

* gnu/packages/virtualization.scm (libvirt): Remove 'wrap-libvirtd phase.  Add
configure flags to run qemu as 'nobody:kvm'.
* gnu/services/virtualization.scm (libvirt-service-type): Add 'qemu' to the
system profile.
---
 gnu/packages/virtualization.scm | 17 +
 gnu/services/virtualization.scm |  6 --
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 26477714e4..f46c31df1f 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -401,7 +401,10 @@ manage system or application containers.")
 (build-system gnu-build-system)
 (arguments
  `(#:configure-flags
-   (list "--with-polkit"
+   (list "--with-qemu"
+ "--with-qemu-user=nobody"
+ "--with-qemu-group=kvm"
+ "--with-polkit"
  (string-append "--docdir=" (assoc-ref %outputs "out") "/share/doc/"
 ,name "-" ,version)
  "--sysconfdir=/etc"
@@ -431,23 +434,13 @@ manage system or application containers.")
  (apply invoke "make" "install"
 "sysconfdir=/tmp/etc"
 "localstatedir=/tmp/var"
-make-flags)))
- (add-after 'install 'wrap-libvirtd
-   (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
-   (wrap-program (string-append out "/sbin/libvirtd")
- `("PATH" = (,(string-append (assoc-ref inputs "iproute")
- "/sbin")
- ,(string-append (assoc-ref inputs "qemu")
- "/bin"
-   #t))
+make-flags))
 (inputs
  `(("libxml2" ,libxml2)
("eudev" ,eudev)
("libpciaccess" ,libpciaccess)
("gnutls" ,gnutls)
("dbus" ,dbus)
-   ("qemu" ,qemu)
("libpcap" ,libpcap)
("libnl" ,libnl)
("libuuid" ,util-linux)
diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index 705ed84d06..03aedd326c 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -442,8 +442,10 @@ potential infinite waits blocking libvirt."))
   (service-extension polkit-service-type
  (compose list libvirt-configuration-libvirt))
   (service-extension profile-service-type
- (compose list
-  libvirt-configuration-libvirt))
+ (lambda (config)
+   (list
+(libvirt-configuration-libvirt config)
+qemu)))
   (service-extension activation-service-type
  %libvirt-activation)
   (service-extension shepherd-root-service-type
-- 
2.19.2

bug#37249: console shell upon login is not ~/.guix-profile/bash -- is this always/never ok?

[宋文武]

Bengt Richter  writes:

> Hello,
>
> In the pursuit of causes for problems as yet not clear enough to
> post as bugs, I am looking for ambivalences in name searches
> in /gnu/... and /(the-rest).

Hello, I think most guix packages (some won't or require manual
configurations) will work on a foreign GNU/Linux distribution, and guix
shouldn't cause problems for the distribution.

>
> The first is immediately bash:
> To duplicate, log into a fresh console and look at what's running
> and invoked. I did an Alt-F4 and logged in fresh, and captured the
> terminal screen seen in the following:
>
> -8<-
>
> [ ... snip some output from .bash_profile ... ]
>
> [13:33 ~/bs]$ ps -o pid,tty,args
>   PID TT   COMMAND
> 25500 tty4 -bash
> 25966 tty4 ps -o pid,tty,args
> [13:35 ~/bs]$ which -a ps
> /usr/bin/ps
> [13:35 ~/bs]$ file /proc/25500/exe
> /proc/25500/exe: symbolic link to /usr/bin/bash
>
> So, the shell I am talking to right after login is /usr/bin/bash,
> but if I type bash, the guix version will be found first:
>
> [13:36 ~/bs]$ which -a bash
> /home/bokr/.guix-profile/bin/bash
> /usr/bin/bash
> [13:38 ~/bs]$ which -a bash|xargs readlink -f
> /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
> /usr/bin/bash

After login, user's shell program as specified in /etc/passwd will be
executed.  So you should have '/usr/bin/bash' or '/bin/bash' in
/etc/passwd, and your $PATH have '$HOME/.guix-profile/bin' before
'/usr/bin', so when type 'bash' in a shell, the guix one got executed.

>
> So, nesting into the guix one,
>
> [13:39 ~/bs]$ bash
> [13:39 ~/bs]$ ps -o pid,tty,args
>   PID TT   COMMAND
> 25500 tty4 -bash
> 26226 tty4 bash
> 26253 tty4 ps -o pid,tty,args
> [13:40 ~/bs]$ file /proc/26226/exe
> /proc/26226/exe: symbolic link to 
> /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
>
> Indeed our current pid belongs to guix bash.
> What is the difference? They were built differently...
>
> [13:41 ~/bs]$
> [13:42 ~/bs]$ which -a bash
> /home/bokr/.guix-profile/bin/bash
> /usr/bin/bash
> [13:43 ~/bs]$ which -a bash|xargs readlink -f|while read line;do echo -ne 
> "$line:\n"; file "$line";done
> /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
> /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
> interpreter
> 
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
> for GNU/Linux 2.6.32, not stripped
> /usr/bin/bash:
> /usr/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
> dynamically linked,
> interpreter /lib64/ld-linux-x86-64.so.2, 
> BuildID[sha1]=21a51cb5f7d727370e4d8099d283d7cd20222571,
> for GNU/Linux 3.2.0, stripped
>
> Are the differences possibly dangerous?

It's totally OK, you can use both :-)

>
> The way I got the above, and this tail part itself:
> [13:45 ~/bs]$ tty
> /dev/tty4
> [13:47 ~/bs]$ su -c 'setterm -file login-bashes.txt -dump 4'
> 
>
> Looking for dependencies outside of /gnu from within /gnu, I grepped the whole
> as you see below. I am sure most of this is fine and coming out of 
> documentation
> and stuff meant for other than normally booted runtime. But does it all look 
> ok?
>
> Or is my foreign-host twilight-zone shared ArchLinux/guix namespace really not
> meant to be. I.e., is guix really defined to use /usr/ as a trusted base 
> namespace
> when it is defined by e.g. linux-libre in GuixSD ?
>
> Where would be the best docs to read about the guix name and environment 
> rationales?

There are no 'namespace' involed, guix and your ArchLinux packages share
the same filesystem.  And guix binaries are self-contained, they can
work without any dependenices outsite of /gnu (sometimes they will use
what's available in PATH, etc. which may be provided by your distribution).

>
> Ok, here is the grep:
> (most of the bashes are in the store, as seen at the bottom, but many not)
> ---
> This was generated by:
> grep -Ihr '^ *#!' /gnu|sort|uniq -c|sort -h > gnu-bin-hash-bangs.txt
>
>   2   #!/bin/csh
>   2 #!/bin/tcsh
>   2 #!@GAWK@ -f
>   2 #!/gnu/store/03n7p9g78ixkrmra674pkx2c9cx8fwmz-guile-1.8.8/bin/guile \
>   2 
> #!/gnu/store/0xfmkqpi7xk3ixhrqvjijk4ibsglif62-python-3.7.0/bin/python3.7m
>   2 
> #!/gnu/store/57daq0hkwvmwx4asiy669cmln868brfm-python2-2.7.15/bin/python2
>   2 #!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile
>   2 
> #!/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/bin/python3.7m
>   2 
> #!/gnu/store/cl42c73h609bp2gy92qkh8q56spnnl2n-python-3.7.0/bin/python3.7m
>   2 #! /gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl
>   2 
> #!/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/bin/python3.7m
>   2 #!/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk

bug#37309: ‘ssh-daemon’ service fails to start at boot

[宋文武]

Giovanni Biscuolo  writes:

> Hi,
>
> following a recent discussion on guix-sysadmin I have to confirm the
> ssh-daemon issue since it is still happening on some of the machines I
> administer
>
> Previous possibly related bug reports are
> https://issues.guix.gnu.org/issue/30993 and
> https://issues.guix.gnu.org/issue/32197
>
> Unfortunately this issue is *not* well reproducible, it depends on some
> mysterious (to me) timing factor; AFAIU it does *not* depend on the
> shepherd version, probably it depends on "something" related to IPv6
> (read below the details)

Hello, thank you for this report, it's reproducible with my box that has
an old hard disk, and disable IPv6 for sshd does fix the issue for me...

>
> Andreas Enge  writes:
>
> [...]
>
>> My impression is that the problem is still there. I am quite certain it
>> happened when I rebooted dover, since I had to connect on the serial console
>> to manually restart the ssh service.
>
> I'm sure it happened when milano-guix-1 was rebooted due to data centre
> maintenance and happened yesterday to one of my personal Guix machines at
> office
>
> [...]
>
> My situation is similar to the one observed by Andreas
>
>> Well, it is in /var/log/messages:
>> Aug  3 21:11:38 localhost sshd[360]: Server listening on 0.0.0.0 port 22.
>> Aug  3 21:11:55 localhost shepherd[1]: Service ssh-daemon could not be 
>> started.
>
> [...]
> Sep  4 21:46:02 localhost shepherd[1]: Service syslogd has been started.
> [...]
> Sep  4 21:46:03 localhost shepherd[1]: Service loopback has been started.
> [...]
> Sep  4 21:46:22 localhost vmunix: [0.226337] PCI: Using configuration 
> type 1 for base access
> Sep  4 21:46:09 localhost dhclient: DHCPREQUEST for 10.38.2.16 on eno1 to 
> 255.255.255.255 port 67
> [...]
> Sep  4 21:46:24 localhost shepherd[1]: Service networking has been started.
> [...]
> Sep  4 21:46:12 localhost sshd[577]: Server listening on 0.0.0.0 port 22.
> [...]
> Sep  4 21:46:30 localhost vmunix: [0.250107] ACPI: PCI Interrupt Link 
> [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
> Sep  4 21:46:13 localhost dhclient: DHCPREQUEST for 10.38.2.16 on eno1 to 
> 255.255.255.255 port 67
> [...]
> Sep  4 21:46:16 localhost dhclient: DHCPACK of 10.38.2.16 from 10.38.2.1
> [...]
> Sep  4 21:46:33 localhost shepherd[1]: Service ssh-daemon could not be 
> started.
> [...]
> Sep  4 21:46:47 localhost vmunix: [0.731142] Segment Routing with IPv6
>
>
> Please note the timing of the dhclient and the sshd processes: I
> inserted them as printed in /var/log/messages but they are not
> time-sequential: does it means something or is irrelevant?
>
> So the sshd process started (as far as I cen see there is no trace it
> was stopped) and pretty soon shepherd noticed ssh-daemon was not
> started.
>
> Logging in from the console I see the ssh-daemon is stopped but enabled:
>
> Status of ssh-daemon:
>   It is stopped.
>   It is enabled.
>   Provides (ssh-daemon).
>   Requires (syslogd loopback).
>   Conflicts with ().
>   Will be respawned.
>
>
> [...]

Yes, I think when 'ssh-daemon' failed to start, shepherd should respawn
it until success or disable it, but by look at the code of
'make-forkexec-constructor', when using 'pid-file' (as 'ssh-ademon'
does), and a timeout (default to 5s %pid-file-timeout) is reached, the
processes got a 'SIGTERM' and return '#f' as its running state, which
won't be respawn (it's not a pid number) I guess...

To ludo: Is my analysis correct?  It's not clear to me how to fix it so
'ssh-daemon' can be respawn though...

>
> If I start it via `sudo herd start ssh-daemon` it immediatly starts,
> like in Andreas experience:
>
>> Aug  3 21:13:10 localhost sshd[385]: Server listening on 0.0.0.0 port 22.
>> Aug  3 21:13:10 localhost sshd[385]: Server listening on :: port 22.
>> Aug  3 21:13:11 localhost shepherd[1]: Service ssh-daemon has been started.
>
> Sep  5 13:38:55 localhost sshd[745]: Server listening on 0.0.0.0 port 22.
> Sep  5 13:38:55 localhost sshd[745]: Server listening on :: port 22.
> Sep  5 13:38:55 localhost shepherd[1]: Service ssh-daemon has been started.
>
>
> Please notice the difference from above: this time the sshd server is
> also listening on the IPv6 address :: while in the above log it was only
> listening on the 0.0.0.0 IPv4 address
>
> Does the failure have something to do with IPv6 not available when sshd
> starts for the first time after a reboot?

I agree, as adding '(extra-content "ListenAddress 0.0.0.0")' to my
'openssh-configuration' to skip the ipv6 listen fix this issue for me.

A proper fix should be respawn 'ssh-daemon' and start it after 'ipv6
available' (i don't know what this mean yet..).

bug#37209: [PATCH] gnu: libvirt: Don't wrap with PATH

[宋文武]

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

> Hello, this patch will make libvirt use
>   "/run/current-system/profile/bin/qemu-system-x86_64"
> in machine's definition, and it can use 'ovs-vsctl' in PATH:
>
>>From e463ef6952009a46c96981df0647cee414fb71a6 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
> Date: Wed, 28 Aug 2019 20:49:40 +0800
> Subject: [PATCH] gnu: libvirt: Don't wrap with PATH.
>

Pushed, well I should sent it ..

bug#31365: libvirt/virt-manager: Embeds full path to qemu-system in saved .xml files

[宋文武]

Vagrant Cascadian  writes:

> When i create a new libvirt instance with virt-manager, it embeds the
> full path to the qemu binary used at the time. For the machine named
> "networkboot":
>
>   # grep qemu-system /etc/libvirt/qemu/networkboot.xml
>   
> /gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:
>
> If I later run "guix gc" and it happens to remove this particular qemu
> version, the system no longer runs, of course:
>
>   # virsh start networkboot
>   error: Failed to start domain networkboot
>   error: Cannot check QEMU binary
>   
> /gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:
>   No such file or directory
>
> It also means each virtual machine may be running on an older version of
> qemu, for better or worse.
>
> Manaully replacing the emulator entry in the .xml file with
> /run/current-system/profie/bin/qemu-system-x86_64 works around the
> issue, and might be the easiest fix.
>

Hello, I believe my commit 'ef640db2f509f51ebfe3a6a66ba837ef3103bbb7'
fix this, now it use '/run/current-system/profie/bin/qemu-system-x86_64'
in the xml files.  Close now..  Thank you!

bug#53659: Fontmanager failing to build

[宋文武]

Pāladhammika  writes:

> Fixed by roptat
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9295b911163f386ac63286c1d797718afabf5585

Cool, close this now!

bug#56437: Reduce closure size of gsettings-desktop-schemas

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> On 07-07-2022 16:50, Pierre Neidhardt wrote:
>
>> Hi,
>>
>> Gsettings-desktop-schemas is required by WebKitGTK to load HTTPS pages.
>> But it also depends on gnome-backgrounds which weights some 40 MiB.
>>
>> For sure this does not help the closure size...
>>
>> I suggest we create a separate output, or maybe a
>> gsettings-desktop-schemas-minimal which does not include the reference
>> to the backgrounds.
>>
>> Thoughts?
>
> There are only two schemes that contain a reference, so maybe those
> can be put in a separate output:
> [...]
> As such, I'd prefer gong for a separate output. It would need to be
> checked that this doesn't cause problems from GNOME users though.

I think we can use some gsettings overrides in the gnome package, there
is no need for gsettings-desktop-schemas hardcode the background
setting itself.

bug#57048: tiled-1.8.1 fails to build

[宋文武 via Bug reports for GNU Guix]

Fixed in commit ee216d16ef5ea537eaf5508dcffa5d808ab62bb0, thank you for
the report!

bug#57049: cool-retro-term-1.2.0 build failure

[宋文武 via Bug reports for GNU Guix]

"bdju"  writes:

> build log: http://ix.io/46Yn
> guix version: just shows up as 0 for some reason...

cool-retro-term fixed in master now, thank you for the report!

I have version as 0 too...

bug#57067: Missing Xfce icons

[宋文武 via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> In current ‘master’ (ca. 6db3b34d7203639ef4286c237a6e536259f92352), in a
> VM created with:
>
>   guix system vm gnu/system/examples/vm-image.tmpl
>
> Xfce is lacking a few icons in window decorations and in the bar at the top:
>

Fixed in commit 02b69362cb5922e3e2579b120a12afcc6167a46e now.

GTK+3 (and 4) requires the Adwaita icon theme is always available.
Maybe we can make gtk+ depends and hardcode the path to
adwaita-icon-theme to avoid install it into the profile.

Thank you!

bug#57104: Python-symengine fails to build

[宋文武 via Bug reports for GNU Guix]

Andreas Enge  writes:

> Since it replaces a broken package by a more modern broken package, I still
> took the liberty to push, but it would be nice if someone with knowledge of
> python and/or symengine could have a look. Disabling the tests makes the
> compilation succeed, but it would be nice to find a better solution...
>

Fixed it by using 'nosetests' to run the tests.

Close now, thanks!

bug#57268: rottlog create a /.lastweek file

[宋文武 via Bug reports for GNU Guix]

Our rottlog has an empty STATDIR, it will create a /.lastweek file when
running.  Normally it should use /var/lib/rottlog/.lastweek.

bug#57480: Wrong Type To Apply on Reconfigure

[宋文武 via Bug reports for GNU Guix]

Julien Lepiller  writes:

> I don't know how to fix it, but here is what I think is the issue:
>
> in guix/scripts/system/reconfigure.scm:
>
> #:autoload   (guix describe) (current-channels)
> ...
> (define* (check-forward-update ...
>(current-channels ...))
>   (define new (current-channels)) ; this is supposed to be the
>  ; autoloaded procedure, but it's the keyword argument
>  ; which is a list
>   ... ; uses of current-channels, the keyword argument
>
> Le Mon, 29 Aug 2022 23:01:46 -0400,
> Christopher Rodriguez  a écrit :
>
>> Hello All,
>> 
>> A change made in b084398 is preventing both my system and home
>> configurations from building with a Wrong Type to Apply error. Did the
>> channel spec format change with the changes in that commit?

Hello, I revert the commit b084398 for now.

bug#58697: [bug] guix refresh nftables crashes

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> On 22-10-2022 03:55, kiasoc5 via Bug reports for GNU Guix wrote:
>> % guix refresh nftables
>> [...]
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure getaddrinfo: Servname not supported for ai_socktype
>> ```
>
> I can reproduce this locally and don't know the cause.
>

It happens when the origin have both 'mirror://' and 'http://' urls,
current the html updater check for any url match 'http' or 'https', but
when updating it will just pick the first url, so when the first is
'mirror://' this error will come.

This patch should fix it:

>From e9dfdc3a2031c25043cc8b6f4b08656d05024c16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Mon, 24 Oct 2022 16:35:18 +0800
Subject: [PATCH] gnu-maintenance: Don't try html updater on 'mirror://' urls.

This fixes .

* guix/gnu-maintenance.scm (latest-html-updatable-release): Use the first http
or https url for updating.
---
 guix/gnu-maintenance.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/gnu-maintenance.scm b/guix/gnu-maintenance.scm
index 10a6ec05f1..4cd501e492 100644
--- a/guix/gnu-maintenance.scm
+++ b/guix/gnu-maintenance.scm
@@ -806,10 +806,16 @@ (define http-url?
 (define (latest-html-updatable-release package)
   "Return the latest release of PACKAGE.  Do that by crawling the HTML page of
 the directory containing its source tarball."
+  (define (http-url? url)
+(match (string->uri url)
+  (#f #f)
+  (uri (let ((scheme (uri-scheme uri)))
+ (memq scheme '(http https))
   (let* ((uri   (string->uri
  (match (origin-uri (package-source package))
((? string? url) url)
-   ((url _ ...) url
+   ;; We need filter out possibly 'mirror://' urls.
+   ((? list? urls) (first (filter http-url? urls))
  (custom(assoc-ref (package-properties package)
'release-monitoring-url))
  (base  (or custom
-- 
2.37.3

bug#59876: Bug.

[宋文武 via Bug reports for GNU Guix]

Ping Pong  writes:

> Hello,

Hello!
>
> My shell asked me to send this your way:
> [...]
> ./guix/serialization.scm:80:6: In procedure read-int:
> ERROR:
>   1. &nar-error:
>   file: #f
>   port: #
> guix pull: error: You found a bug: the program 
> '/gnu/store/lzj46vv382in6axngwsjaaa2y96lss04-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f57fbc2fb1b20823f433781d08047df5d7bc31df"; system: "x86_64-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

Sorry for the failure and not helpful error message...  I believe this
usually was due to unstable internet connection, does try "guix pull"
again fixed it?

bug#59846: "Running Guix in a Virtual Machine" documentation unclear/incomplete/wrong

[宋文武 via Bug reports for GNU Guix]

Ian Eure  writes:

> I’m trying to explore Guix System by running it in a VM on my computer
> which runs Debian.  I’m interested in some of the Guix ideas, but not
> ready to do a bare-metal install.

Hello!
>
> I found the download page[1] and got a copy of the QEMU image, then
> clicked "Installation instructions"[2].  These instructions didn’t
> work, because they’re incomplete and/or unclear and/or wrong and/or
> not really installation instructions in the way one might assume.
> Since I don’t really know anything about Guix (which is why I’m
> reading the documentation and test driving it in a VM), I’m not sure
> which one-or-more of these it may be.

Sorry for the not very helpful documentation, I'd say write good
documentation is very hard...
>
> Specifically:
>
>> To enable SSH inside a VM you need to add an SSH server like
>> openssh-service-type to your VM (see openssh-service-type).
>
> The documentation doesn’t say *how* to do that.  The
> openssh-service-type link[3] takes me to a large page of code
> documentation for every possible networking service, instead of the
> openssh-service-type one specifically.  This documentation describes
> *what* the service type and its many configuration options is, but is
> silent on *how* to make use of it.

This openssh-service-type should be added into the system configuration
file, it's /run/current-system/configuration.scm in the pre-built qemu
image or the file passed to 'guix system vm-image' when built your own
image.  The configuration file is a scheme (guile) file, the detail is
in the section "10.1 Using the configuration System".

>
> It continues:
>
>> In addition you need to forward the SSH port, 22 by default, to the
>> host. You can do this with
>> $(guix system vm config.scm) -nic
>> user,model=virtio-net-pci,hostfwd=tcp::10022-:22
>
> I’m really not sure what this is supposed to be doing.  It can’t run
> on my Debian host, since there’s no guix command.  It errors inside
> the VM, since it can’t find a config.scm file; and I don’t see an
> obvious config.scm file anywhere inside the VM that it might be
> looking for.
>
> I *suspect* that this documentation is actually targeted at running a
> Guix System VM on an existing Guix host.  Which is a chicken-and-egg
> problem, if I’ve already installed Guix, I don’t need to follow
> instructions to install it.

Well this 10.16 target both running a pre-built qcow guix system image
and running a 'guix system vm' built one.  But it's not self contained,
as the service things lacking commands for the former as you reported,
and the later case assume you already have guix installed (not the guix
system though).

Hope it helps!

bug#61132: xfce 4.18 issues: gsettings, icons missing, and logout need long time

[宋文武 via Bug reports for GNU Guix]

> [...]
>
> Hello Feng Shu and Michael Rohleder, I have create a wip-xfce branch and
> applied all patches: They're all LGTM, and I will merge it after some
> tests later.  Thank you!
>

Pushed!

During my tests, I find some issues though:

1. in xfce4-appearance-settings, switch the theme to greybird-dark will
kill it, with output:
```
(xfce4-appearance-settings:13788): Gtk-WARNING **: 10:53:21.078: Could not load 
a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.

(xfce4-appearance-settings:13788): GLib-GIO-ERROR **: 10:53:23.264: Settings 
schema 'org.gnome.desktop.interface' does not contain a key named 'color-scheme'
```
I think this is due to our gsettings-desktop-schemas is old.

2. some icons are missing, and by default there is no pixbuf loader for
svg.  With a manually set GDK_PIXBUF_MODULE_FILE, I get better result
with elementary-xfce-icon-theme (the adwaita icon themes still missing
some icons).

3. logout via xfce4-session-logout will wait more about 30s for me,
sometimes it does logout immediately, no idea...

4. mousepad output:
Mousepad-Message: 11:00:34.614: Plugin directory 
'/gnu/store/0m4rqqn3gxwg6mafhccqjwwvqdz1a5sr-mousepad-0.5.10/lib/mousepad/plugins'
 not found
GLib-GIO-Message: 11:00:34.614: Using the 'memory' GSettings backend.  Your 
settings will not be saved or shared with other applications.

The default gsettings backend is dconf, I guess some applications like
mousepad need fix to enable dconf or use the keyfile backend for
gsettings...

I now open a bug for thoes issues.

bug#59579: installing zbar prevents gdm to start on Ubuntu 22.04 foreign distro

[宋文武 via Bug reports for GNU Guix]

Simon Tournier  writes:

> Hi,
>
> On Fri, 25 Nov 2022 at 18:45, Clément Lassieur  wrote:
>
>> It's very difficult to pin the issue down to a guix package being
>> installed.
>>
>> I imagine the bug would not happen if ~/.guix-profile/share was not in
>> XDG_DATA_DIRS.
>
> Yes, it is related to XDG_DATA_DIRS and it can be tedious to find which
> package brings the issue.
>
> I had a similar issue with the package ’python-ipython’ and recently
> with ’fontconfig’ – both cases running on the top of Debian.
>
> The issue can happen whatever the profile; it just depends which ones
> are sourced by your login shell.
>

Hello, I don't think XDG_DATA_DIRS should be the problems, but other
environment variables with "lib", since the xdg data should be
portable...

So:
--8<---cut here---start->8---
$ guix shell -C coreutils zbar --no-grafts  -- env
PS1=\u@\h \w [env]\$ 
TMPDIR=/tmp
TEMPDIR=/tmp
TMP=/tmp
TEMP=/tmp
LOGNAME=iyzsong
USER=iyzsong
HOME=/home/iyzsong
PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/bin:/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/sbin
XDG_DATA_DIRS=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/share
GUIX_GTK3_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/gtk-3.0
QMAKEPATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/qt5
QT_PLUGIN_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/qt5/plugins
XDG_CONFIG_DIRS=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/etc/xdg
XCURSOR_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/share/icons
GDK_PIXBUF_MODULE_FILE=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
GUIX_ENVIRONMENT=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile
--8<---cut here---end--->8---

I think GUIX_GTK3_PATH, QT_PLUGIN_PATH, GDK_PIXBUF_MODULE_FILE should be
the problems.

bug#61195: termite failed to build, need switch to a maintained fork

[宋文武 via Bug reports for GNU Guix]

New fork: https://github.com/aperezdc/termite
Maybe also remove vte-ng.

bug#61343: modules from channels is not available to "guix repl"

[宋文武 via Bug reports for GNU Guix]

I have add the rde channel to my guix, and "guix pull".
--8<---cut here---start->8---
(cons*
 (channel
  (name 'rde)
  (url "https://git.sr.ht/~abcdw/rde";)
  (introduction
   (make-channel-introduction
"257cebd587b66e4d865b3537a9a88cccd7107c95"
(openpgp-fingerprint
 "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0"
 %default-channels)
--8<---cut here---end--->8---

But then, Run:
  echo '(use-modules (rde features))' | guix repl /dev/stdin
Will get error: no code for module (rde features)

Well, Run:
  echo '(use-modules (gnu packages) (rde features))' | guix repl /dev/stdin
Will pass!

bug#57677: GIMP retains reference to GCC

[宋文武 via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> [...]
> So the root cause is that GIMP’s build process captures the output of
> ‘gcc -v’, which leads to this unintended retention.

I sent a patch to fix reference from 'gcc -v', but gcc is still here via
exiv2->gcc:

rg -a /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0 $(guix build exiv2)

--8<---cut here---start->8---
bin/iptcprint:^@^@^@std::auto_ptr<  >::element_type* 
std::auto_ptr<  >::operator->() const [with _T
p = Exiv2::Image; std::auto_ptr< >::element_type =
Exiv2::Image]^@^@^@^@^@^@^@^@/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/backward/auto_ptr.h^@^@%s:%d:
%s: Assertion '%s' failed.
[...]
--8<---cut here---end--->8---

bug#61469: Xfce window snapping broke with latest upgrade

[宋文武 via Bug reports for GNU Guix]

Nathan Dehnel  writes:

> Latest guix pull and reconfigure caused window snapping to stop
> working in XFCE. I have tried toggling it off and on a few times in
> the settings.
> Current generation: ccf742f120452acf587d16e40adea570d15169c4
> Previous generation: 658c09333da095edf6e1b3c5e351a7bfa3c87354
Hello, it does works for me here.

Note that only snapping up upon the default pannel will prevent it
moving future.  For other directions, if you drag too much, the window
will escape the snap and move to another workspace...

bug#61343: [PATCH] scripts: repl: Load (gnu packages) to set up %load-path.

[宋文武 via Bug reports for GNU Guix]

Josselin Poiret  writes:

> * guix/scripts/repl.scm: Add (gnu packages) to the used modules so that 
> channel
> Scheme files are available straight away.
> ---
> Hi both of you,
>
> I don't think there's a reason for that, other than no one realizing before.
> Here's a simple fix, freshly tested.
>
>  guix/scripts/repl.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/guix/scripts/repl.scm b/guix/scripts/repl.scm
> index 787c63d48e..407f5b2b38 100644
> --- a/guix/scripts/repl.scm
> +++ b/guix/scripts/repl.scm
> @@ -22,6 +22,7 @@ (define-module (guix scripts repl)
>#:use-module (guix ui)
>#:use-module (guix scripts)
>#:use-module (guix repl)
> +  #:use-module (gnu packages) ;; To extend %load-path with channels
It's not clear to me why load (gnu packages) will/should extend
%load-path, a suprise side effect!

bug#48214: inetutils-1.9.4 build fails

[宋文武 via Bug reports for GNU Guix]

Bone Baboon  writes:

> I have reopened bug#48214 because while inetutils-1.9.4 can be built on
> x86_64 with IPv6 disabled this command fails on x86_64 with IPv6
> disabled `guix build --no-substitutes --system=i686-linux` inetutils`.
> This command has the same failing test.  Attached is the failing i686
> build log.
>

Does this issue still exist?  Now we have inetutils-2.0 in master, and will
have 2.3 soon after core-updates merged...

bug#61469: Xfce window snapping broke with latest upgrade

[宋文武 via Bug reports for GNU Guix]

Nathan Dehnel  writes:

> Turns out the setting for this is called "tiling" in xfce, not
> "snapping". So I was able to re-enable it. This can probably be
> closed.

Cool!  Close now, thank you!

bug#71458: wireplumber service fails to start in home-pipewire-service-type

[宋文武 via Bug reports for GNU Guix]

Antero Mejr  writes:

> Immediately after logging into an account with
> home-pipewire-service-type in the home environment, about 5 error
> messages appear about the wireplumber service failing and restarting.
> Eventually herd gives up trying to start wireplumber.
>
> Trying to start it manually using `herd start wireplumber` results in
> the message:
> herd: error: failed to start service wireplumber
>
> The other pipewire-related services appear to have started successfully.
>
> home-dbus-service-type is in the home environment also.


Have a look at ~/.local/state/log/shepherd.log, it should have some logs
from wireplumber, which may help debuging.

bug#71458: wireplumber service fails to start in home-pipewire-service-type

[宋文武 via Bug reports for GNU Guix]

Antero Mejr  writes:

> 宋文武  writes:
>
>> Antero Mejr  writes:
>>
>> Have a look at ~/.local/state/log/shepherd.log, it should have some logs
>> from wireplumber, which may help debuging.
>
> It was a problem with older versions of Wireplumber, this
> yet-to-be-merged patch resolves the issue:
>
> https://issues.guix.gnu.org/71463

Merged now, close, thank you!

bug#70456: core-updates failed package: time

[宋文武 via Bug reports for GNU Guix]

time-1.9 fail its test on core-updates:
https://ci.guix.gnu.org/build/4587082/log/raw

time(1) failed to detect 5MB allcoation.
  mem-baseline(kb): 768
  mem-5MB(kb):  5720
  delta(kb):4952
FAIL tests/time-max-rss.sh (exit status: 1)

delta is 4952, but it expect 5000-6000.

No idea what's the reason, maybe skip it?