bug#37384: Daemon does not honor “useSubstitutes” on armhf

[Timothy Sample]

Timothy Sample  writes:

> The problem goes away if I move “useSubstitutes” above “reservedSize”,
> which has type “off_t”.  I’m guessing this is because of something fishy
> with “_FILE_OFFSET_BITS”, but I’m not sure what just yet.

Here’s my best guess as to what is going on.  In “nix-daemon.cc” the
order of includes causes “off_t” to be defined before
“_FILE_OFFSET_BITS”, which results in it being something like a 32-bit
signed integer.  In “local-store.cc”, “_FILE_OFFSET_BITS” gets set
first, yielding a 64-bit “off_t”.  This causes all of the addresses in
the “Settings” struct to be mismatched after “reservedSize”.  I plugged
in “sizeof(off_t)” into the “printMsg” calls from before, and (lo and
behold) I saw 4 from “nix-daemon.cc” and 8 from “local-store.cc”.

The following patch fixes the problem:

>From 3c3eafac82e0a6e8a37363d6eb46f128e585705a Mon Sep 17 00:00:00 2001
From: Timothy Sample 
Date: Thu, 12 Sep 2019 00:50:54 -0400
Subject: [PATCH] daemon: Include 'config.h' in 'nix-daemon.cc'.

* nix/nix-daemon/nix-daemon.cc: Include 'config.h'.
---
 nix/nix-daemon/nix-daemon.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/nix/nix-daemon/nix-daemon.cc b/nix/nix-daemon/nix-daemon.cc
index ffac6cde34..1163a249d1 100644
--- a/nix/nix-daemon/nix-daemon.cc
+++ b/nix/nix-daemon/nix-daemon.cc
@@ -1,3 +1,4 @@
+#include "config.h"
 #include "shared.hh"
 #include "local-store.hh"
 #include "util.hh"
-- 
2.23.0


Is this okay to push?  It seems kind of conspicuous that it’s missing in
the first place.  Is it missing for a good reason?


-- Tim

bug#37369: Getting network-manager-openconnect to work

[pelzflorian (Florian Pelz)]

On Wed, Sep 11, 2019 at 10:46:56PM +0200, Ludovic Courtès wrote:
> Something I don’t get: why does NM itself know about openconnect?
> 
> There’s a network-manager-openconnect plugin, so I would expect
> everything openconnect to happen there.  Do you know why it’s not that
> way?
> 
> Thanks,
> Ludo’.

I don’t know.  The patch addresses (if it works) a function called
nm_vpn_openconnect_authenticate_helper within the code for
NetworkManager clients like nmtui, probably also nm-connection-editor,
that calls openconnect --authenticate.

Perhaps the network manager service could symlink the openconnect
binary to the plugins directory when used and NetworkManager could be
made to look there, but it would be nice to know if the current patch
works.

Regards,
Florian

bug#37387: reconfigure does not recreate ~/.guix-profile

[Joshua Branson via Bug reports for GNU Guix]

Hey guix,

;tldr guix system reconfigure does not create a ~/.guix-profile, if
 the file was deleted, nor does it change the symlink if the username
 changed.

This seems like 2 tiny bugs.  I recently installed guix on my Thinkpad
T400.  (Thanks by the way!  Sway works wonderfully!)  When I first
created my user my user line looked like

#+BEGIN_SRC scheme
 (user-account
  (name "Joshua Branson")
  (comment "Joshua Branson")
  (group "users")
  (home-directory "/home/joshua")
  (supplementary-groups
   '("wheel" "netdev" "audio" "video")))
#+END_SRC scheme

Later I changed the user name to '(name "joshua")' and reconfigured.
Guix was smart enough to create a new profile for me, but
.guix-profile still pointed to user account "Joshua Branson" not
"joshua".


$ cd ~/; ls -lha .guix-profile
.guix-profile -> /var/guix/profiles/per-user/Joshua Branson/guix-profile

So I removed .guix-profile and reconfigured.

$ rm ~/.guix-profile

# sudo guix system reconfigure sway.scm

I thought that guix is declarative, so it will recreate .guix-profile,
but it did not.

Thanks,

Joshua

bug#37089: texlive-union includes log files with timestamps

[Ricardo Wurmus]

Hi Maxim,

I think this might be related to or a duplicate of these bugs:

   https://issues.guix.gnu.org/issue/28173
   https://issues.guix.gnu.org/issue/27515

--
Ricardo

bug#37373: python-ipython-documentation build is not reproducible

[Ricardo Wurmus]

Hi Maxim,

> --8<---cut here---start->8---
> diff -r 
> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0/share/doc/python-ipython-documentation-7.5.0/html/sphinxext.html
>  
> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check/share/doc/python-ipython-documentation-7.5.0/html/sphinxext.html
> 624c624
> < Out[2]: datetime.datetime(2019, 9, 11, 0, 16, 37, 
> 683664)
> ---
>> Out[2]: datetime.datetime(2019, 9, 11, 1, 19, 45, 
>> 915814)
> 632c632
> < 50.1 ms +- 2.31 us per loop (mean +- std. dev. of 7 runs, 
> 10 loops each)
> ---
>> 50.1 ms +- 11 us per loop (mean +- std. dev. of 7 runs, 10 
>> loops each)
> --8<---cut here---end--->8---

This is now fixed in commit 0f272518eca06f849cef86d26c294f17edc82c3e.

Thanks for the report!

-- 
Ricardo

bug#37374: "Guix is too old and cannot be upgraded" (guix package -u)

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

>> Wow, now I want to keep guix up-to-date all the time. How long has it
>> been since you pulled/upgraded guix?
>
> There’s no need to worry about that.  The mechanism to upgrade Guix has
> changed significantly over the past years and has since stabilized.
> This error will usually only hit you if you’re using a *much* older
> Guix that predates the changes how “guix pull” works.

Specifically, the message “Guix is too old and cannot be upgraded”
appears when you’re running ‘guix pull’ from Guix before 0.15.0,
released in July 2018.  (That seemed like prehistory to me but I realize
it’s only a bit more than one year old.)

But like Ricardo wrote, such problems are unlikely to show up again
because ‘guix pull’ since 0.15.0 is designed to handle all sorts of
bumps into future Guix revisions.

Anyway, the simplest option for now, melon, may be to remove your
current Guix installation and install 1.0 instead.

Ludo’.

bug#37386: ungoogled-chromium broken because of openssl update

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Jelle,

Jelle Licht 写道：
Commit cf065aba1ec14bdacab7a5a6bddbdfd7661cd409 seems to have 
broken
node, which subsequently broke ungoogled-chromium. It should 
still be
possible to upgrade node to the latest LTS version 10.16.3, but 
this

requires an upgrade to the following rebuild-the-world packages:
- libuv
- nghttp2


Yeah, I was just trying to update node but it is indeed not 
simple.




What do we do?


I'd like to avoid rolling back the openssl update if at all 
possible.  I'll try grafting openssl-next, I guess…


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Jan]

> Do not run ./configure alone, always specify --localstatedir=/var
> unless you plan to run the daemon from the repo too (then it's fine
> without the option, but you won't be able to pull or you'll get into
> trouble iiuc).

Thank you all for advice, after running 
./configure --localstatedir=/var the file has been generated. Then to
be able to run Guix, I had to do "make check". Now I have Guix available
and I would like to update a package, like showed in the manual or the
tutorial, but running for example "./pre-inst-env guix refresh opendht"
throws the following error:

Backtrace:
  18 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 17 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 16 (_ #(#(#)))
In guix/ui.scm:
  1692:12 15 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9 14 (catch _ _ # ?)
829:9 13 (catch _ _ # ?)
In guix/store.scm:
   623:10 12 (call-with-store _)
  1803:24 11 (run-with-store # _ # _ ?)
In guix/scripts/refresh.scm:
   541:14 10 (_ _)
In srfi/srfi-1.scm:
640:9  9 (for-each # ?)
In guix/scripts/refresh.scm:
344:2  8 (check-for-package-update # ?)
In guix/import/github.scm:
   231:25  7 (latest-release #)
   200:22  6 (latest-released-version "https://github.com/savoirfai?; ?)
163:2  5 (fetch-releases-or-tags _)
In ice-9/boot-9.scm:
829:9  4 (catch srfi-34 # ?)
In guix/import/json.scm:
41:19  3 (_)
In guix/http-client.scm:
88:25  2 (http-fetch _ #:port _ #:text? _ #:buffered? _ # _ # _ # ?)
In guix/build/download.scm:
426:4  1 (open-connection-for-uri _ #:timeout _ # _)
313:6  0 (tls-wrap # _ # _)

guix/build/download.scm:313:6: In procedure tls-wrap:
X.509 certificate of 'api.github.com' could not be verified:
  signer-not-found
  invalid

Am I missing a dependency in my environment? Running "guix refresh"
without ./pre-inst-env and "guix environment guix --pure" works.


Jan Wielkiewicz

bug#37386: ungoogled-chromium broken because of openssl update

[Jelle Licht]

Commit cf065aba1ec14bdacab7a5a6bddbdfd7661cd409 seems to have broken
node, which subsequently broke ungoogled-chromium. It should still be
possible to upgrade node to the latest LTS version 10.16.3, but this
requires an upgrade to the following rebuild-the-world packages:
- libuv
- nghttp2

What do we do?

bug#37369: Getting network-manager-openconnect to work

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> From 8de7675a2dc2c1385d312e35136f8fa9eb4f9825 Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Tue, 10 Sep 2019 12:59:19 +0200
> Subject: [PATCH] gnu: network-manager: Enable openconnect helper.
>
> * gnu/packages/gnome.scm (network-manager): Add openconnect input.
> Patch source to use it instead of searching /usr/bin.
> ---
>  gnu/packages/gnome.scm | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index efe5206e53..a6ea09d8f6 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -5372,6 +5372,13 @@ users.")
> (("src/devices/tests/test-lldp") " ")
> (("src/tests/test-route-manager-linux") " "))
>   #t))
> + (add-after 'unpack 'patch-source
> +   (lambda* (#:key inputs #:allow-other-keys)
> + (begin
> +   (substitute* "clients/common/nm-vpn-helpers.c"
> + (("\\\"/usr/sbin/openconnect\\\"")
> +  (string-append openconnect "\"/bin/openconnect\"")))
> +   #t)))
>   (add-after 'unpack 'delete-failing-tests
> (lambda _
>   ;; FIXME: These four tests fail for unknown reasons.
> @@ -5434,6 +5441,7 @@ users.")
> ("libsoup" ,libsoup)
> ("modem-manager" ,modem-manager)
> ("newt" ,newt)   ;for the 'nmtui' console 
> interface
> +   ("openconnect" ,openconnect)

Something I don’t get: why does NM itself know about openconnect?

There’s a network-manager-openconnect plugin, so I would expect
everything openconnect to happen there.  Do you know why it’s not that
way?

Thanks,
Ludo’.

bug#37384: Daemon does not honor “useSubstitutes” on armhf

[Timothy Sample]

Timothy Sample  writes:

> it gives me different addresses depending on whether I’m printing from
> the main daemon loop or from the “querySubstitutablePathInfos” method.
> The addresses suspiciously differ by eight.

The problem goes away if I move “useSubstitutes” above “reservedSize”,
which has type “off_t”.  I’m guessing this is because of something fishy
with “_FILE_OFFSET_BITS”, but I’m not sure what just yet.


-- Tim

bug#37380: gdm doesn't load pam-limits

[Ricardo Wurmus]

Hi Jesse,

> I have been trying to set up ardour, but jackd doesn't start in real-
> time mode. I made an os definition that replicates this issue when I
> use a VM[0].
> [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.html
> I asked the gnome and gdm IRC and found out gdm loads the gdm-password
> pam config, which seems untouched by pam-limits-service. My
> /etc/pam.d/gdm-password (which should be the default) is attached.

I can reproduce this.

(I’m sorry for accidentally misleading you earlier.  Turns out I used
JACK a little longer ago than I initially realized.)

I think it should be pretty easy to fix this:

1) we should generate a single file that is used for generic session
settings.

2) all login programs (including gdm) should include that file in their
PAM settings.

3) the pam-limits-service should extend that single file instead of
attempting to update a bunch of PAM files for a selected list of
programs.

--
Ricardo

bug#37384: Daemon does not honor “useSubstitutes” on armhf

[Timothy Sample]

Currently, the “guix” package cannot build on armhf due to test
failures: .  (I can
confirm this on my local machine, too.)

It looks like there is some confusion about the layout of the “Settings”
struct.  At least, if I add some print statements in the code to print
the address of the “useSubstitutes” flag:

printMsg(lvlError, format("XXX: %1%") % );

it gives me different addresses depending on whether I’m printing from
the main daemon loop or from the “querySubstitutablePathInfos” method.
The addresses suspiciously differ by eight.

I can confirm that the addresses are the same on x86_64.

My guess is that this bug was revealed by the changes made in commit
f6919ebdc6b0ce0286814cc6ab0564b1a4c67f5f (making the daemon assume a
single substituter).  Before this commit, it looks like the daemon would
give up because there were no substituters.  Now it relies on checking
“useSubstitutes”, which is not in fact reliable.  I’ve tested everything
from before this commit, and the addresses are still different.

Weirdly, in GDB, I can be right before the following line:

if (!settings.useSubstitutes) return;

run “p settings.useSubstitutes” and see “false”, and then continue
running through the method without hitting that “return”.  It seems GDB
is not confused about the flag, just the actual code.

Looking at the disassembly was no use to me, since I don’t know much
about ARM, and it was not simple enough for me to guess what it was
doing.


-- Tim

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

On Wed, 2019-09-11 at 09:12 -0600, Jesse Gibbons wrote:
> I have been trying to set up ardour, but jackd doesn't start in real-
> time mode. I made an os definition that replicates this issue when I
> use a VM[0].
> [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.htm
> l
> I asked the gnome and gdm IRC and found out gdm loads the gdm-
> password
> pam config, which seems untouched by pam-limits-service. My
> /etc/pam.d/gdm-password (which should be the default) is attached.
> 
> Thanks!
I'm not sure how to resolve this issue. I tried appending "gdm-
password" to the list of pam configs modified by pam-limits-service[1]
but it doesn't fix anything when I use ./pre-inst-env to build the
vm. gdm-password still does not have a line to load pam_limits.

Whatever the solution, we will probably also want to implement it with
other graphical login services like slim and sddm (and eventually
lightdm and kdm).

[1] http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.sc
m#n1480
-- 
-Jesse

bug#37363: emacs and other programs do not display special characters

[quiliro]

El Mar, 10 de Septiembre de 2019, 11:40 am, Ricardo Wurmus escribió:
>
> quil...@riseup.net writes:
>
>> Also with (locale "es_ES.utf8"), the system is all in English and Gnome
>> Terminal will not start:
>> quiliro@GSD3 ~$ gnome-terminal
>> # Locale not supported by C library.
>> #Using the fallback 'C' locale.
>
> Do you have “glibc-locales” installed?
> Is GUIX_LOCPATH set?

Not on my user. Probably on my system. I did not know I had to add those
on Guix System. Should I?

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

I have been trying to set up ardour, but jackd doesn't start in real-
time mode. I made an os definition that replicates this issue when I
use a VM[0].
[0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.html
I asked the gnome and gdm IRC and found out gdm loads the gdm-password
pam config, which seems untouched by pam-limits-service. My
/etc/pam.d/gdm-password (which should be the default) is attached.

Thanks!
-- 
-Jesseaccount required pam_unix.so 
auth required pam_unix.so nullok
password required pam_unix.so sha512 shadow
session required 
/gnu/store/90b3ypy5w6si4vd4b17i2nyzy0pfr5j2-elogind-241.3/lib/security/pam_elogind.so
 
session required pam_loginuid.so 
session required pam_env.so 
session required pam_unix.so 

bug#37373: python-ipython-documentation build is not reproducible

[Maxim Cournoyer]

Hello Gábor,

Gábor Boskovits  writes:

> Hello,
>
>
> Maxim Cournoyer  ezt írta (időpont: 2019. szept.
> 11., Sze, 2:30):
>
>> Here's the diff produced by diffoscope:
>>
>> ---
>> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0
>> +++
>> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check
>> ├── share
>> │ ├── doc
>> │ │ ├── python-ipython-documentation-7.5.0
>> │ │ │ ├── html
>> │ │ │ │ ├── sphinxext.html
>> │ │ │ │ │┄ xxd not available in path. Falling back to Python hexlify.
>> │ │ │ │ │ @@ -1182,29 +1182,29 @@
>> │ │ │ │ │  3d226e223e6461746574696d653c2f7370616e3e3c7370616e20636c6173733d
>> │ │ │ │ │  226f223e2e3c2f7370616e3e3c7370616e20636c6173733d226e223e64617465
>> │ │ │ │ │  74696d653c2f7370616e3e3c7370616e20636c6173733d226f223e2e3c2f7370
>> │ │ │ │ │  616e3e3c7370616e20636c6173733d226e223e6e6f773c2f7370616e3e3c7370
>> │ │ │ │ │  616e20636c6173733d2270223e28293c2f7370616e3e0a3c7370616e20636c61
>> │ │ │ │ │  73733d226770223e2020202e2e2e3a203c2f7370616e3e0a3c7370616e20636c
>> │ │ │ │ │  6173733d22676f223e4f75745b325d3a206461746574
>> │ │ │ │ │ -696d652e6461746574696d6528323031392c20392c2031312c20302c2031362c
>> │ │ │ │ │ -2033372c20363833363634293c2f7370616e3e0a3c2f7072653e3c2f6469763e
>> │ │ │ │ │ +696d652e6461746574696d6528323031392c20392c2031312c20302c2032312c
>> │ │ │ │ │ +2031322c20353230363534293c2f7370616e3e0a3c2f7072653e3c2f6469763e
>> │ │ │ │ │  0a3c2f6469763e0a3c703e497420737570706f7274732049507974686f6e2063
>> │ │ │ │ │  6f6e737472756374207468617420706c61696e0a507974686f6e20646f657320
>> │ │ │ │ │  6e6f7420756e6465727374616e6420286c696b65206d6167696373293a3c2f70
>> │ │ │ │ │  3e0a3c64697620636c6173733d22686967686c696768742d69707974686f6e20
>> │ │ │ │ │  6e6f7472616e736c617465223e3c64697620636c6173733d22686967686c6967
>> │ │ │ │ │  6874223e3c7072653e3c7370616e3e3c2f7370616e3e3c7370616e20636c6173
>> │ │ │ │ │  733d226770223e496e205b335d3a203c2f7370616e3e3c7370616e20636c6173
>> │ │ │ │ │  733d226b6e223e696d706f72743c2f7370616e3e203c7370616e20636c617373
>> │ │ │ │ │  3d226e6e223e74696d653c2f7370616e3e0a0a3c7370616e20636c6173733d22
>> │ │ │ │ │  6770223e496e205b345d3a203c2f7370616e3e3c7370616e20636c6173733d22
>> │ │ │ │ │  6f223e253c2f7370616e3e3c7370616e20636c6173733d226b223e74696d6569
>> │ │ │ │ │  743c2f7370616e3e2074696d652e736c65657028302e3035290a3c7370616e20
>> │ │ │ │ │ -636c6173733d22676f223e35302e31206d73202b2d20322e3331207573207065
>> │ │ │ │ │ +636c6173733d22676f223e35302e31206d73202b2d20322e3135207573207065
>> │ │ │ │ │  72206c6f6f7020286d65616e202b2d207374642e206465762e206f6620372072
>> │ │ │ │ │  756e732c203130206c6f6f70732065616368293c2f7370616e3e0a3c2f707265
>> │ │ │ │ │  3e3c2f6469763e0a3c2f6469763e0a3c703e546869732077696c6c20616c736f
>> │ │ │ │ │  20737570706f727420746f702d6c6576656c206173796e63207768656e207573
>> │ │ │ │ │  696e672049507974686f6e20372e302b3c2f703e0a3c64697620636c6173733d
>> │ │ │ │ │  22686967686c696768742d69707974686f6e206e6f7472616e736c617465223e
>> │ │ │ │ │  3c64697620636c6173733d22686967686c69676874223e3c7072653e3c737061
>>
>>
> As far as I can see from the header this is a html file, correct me if I am
> wrong. Did you try to look at the file as text?
> It might give a more useful diff.

Indeed! I'm surprised that diffoscope chose to reprosent an html file as
a binary file... Here's a more useful diff:

--8<---cut here---start->8---
diff -r 
/gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0/share/doc/python-ipython-documentation-7.5.0/html/sphinxext.html
 
/gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check/share/doc/python-ipython-documentation-7.5.0/html/sphinxext.html
624c624
< Out[2]: datetime.datetime(2019, 9, 11, 0, 16, 37, 
683664)
---
> Out[2]: datetime.datetime(2019, 9, 11, 1, 19, 45, 
> 915814)
632c632
< 50.1 ms +- 2.31 us per loop (mean +- std. dev. of 7 runs, 10 
loops each)
---
> 50.1 ms +- 11 us per loop (mean +- std. dev. of 7 runs, 10 
> loops each)
--8<---cut here---end--->8---

bug#37369: Getting network-manager-openconnect to work

[pelzflorian (Florian Pelz)]

On Wed, Sep 11, 2019 at 10:38:22AM +0300, Efraim Flashner wrote:
> Instead of adding openconnect to network-manager, would it be enough to
> 
> (substitute* "the-file"
>   (("/usr/sbin/openconnect") "openconnect"))
> 
> 

No, at least the comment documenting nm_utils_file_search_in_paths says:

/**
 * nm_utils_file_search_in_paths:
 * […]
 * @try_first: (allow-none): a custom path to try first before searching.
 *   It is silently ignored if it is empty or not an absolute path.
 * […]

I do not know if my patch works though.

Regards,
Florian

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#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#37373: python-ipython-documentation build is not reproducible

[Gábor Boskovits]

Hello,


Maxim Cournoyer  ezt írta (időpont: 2019. szept.
11., Sze, 2:30):

> Here's the diff produced by diffoscope:
>
> ---
> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0
> +++
> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check
> ├── share
> │ ├── doc
> │ │ ├── python-ipython-documentation-7.5.0
> │ │ │ ├── html
> │ │ │ │ ├── sphinxext.html
> │ │ │ │ │┄ xxd not available in path. Falling back to Python hexlify.
> │ │ │ │ │ @@ -1182,29 +1182,29 @@
> │ │ │ │ │  3d226e223e6461746574696d653c2f7370616e3e3c7370616e20636c6173733d
> │ │ │ │ │  226f223e2e3c2f7370616e3e3c7370616e20636c6173733d226e223e64617465
> │ │ │ │ │  74696d653c2f7370616e3e3c7370616e20636c6173733d226f223e2e3c2f7370
> │ │ │ │ │  616e3e3c7370616e20636c6173733d226e223e6e6f773c2f7370616e3e3c7370
> │ │ │ │ │  616e20636c6173733d2270223e28293c2f7370616e3e0a3c7370616e20636c61
> │ │ │ │ │  73733d226770223e2020202e2e2e3a203c2f7370616e3e0a3c7370616e20636c
> │ │ │ │ │  6173733d22676f223e4f75745b325d3a206461746574
> │ │ │ │ │ -696d652e6461746574696d6528323031392c20392c2031312c20302c2031362c
> │ │ │ │ │ -2033372c20363833363634293c2f7370616e3e0a3c2f7072653e3c2f6469763e
> │ │ │ │ │ +696d652e6461746574696d6528323031392c20392c2031312c20302c2032312c
> │ │ │ │ │ +2031322c20353230363534293c2f7370616e3e0a3c2f7072653e3c2f6469763e
> │ │ │ │ │  0a3c2f6469763e0a3c703e497420737570706f7274732049507974686f6e2063
> │ │ │ │ │  6f6e737472756374207468617420706c61696e0a507974686f6e20646f657320
> │ │ │ │ │  6e6f7420756e6465727374616e6420286c696b65206d6167696373293a3c2f70
> │ │ │ │ │  3e0a3c64697620636c6173733d22686967686c696768742d69707974686f6e20
> │ │ │ │ │  6e6f7472616e736c617465223e3c64697620636c6173733d22686967686c6967
> │ │ │ │ │  6874223e3c7072653e3c7370616e3e3c2f7370616e3e3c7370616e20636c6173
> │ │ │ │ │  733d226770223e496e205b335d3a203c2f7370616e3e3c7370616e20636c6173
> │ │ │ │ │  733d226b6e223e696d706f72743c2f7370616e3e203c7370616e20636c617373
> │ │ │ │ │  3d226e6e223e74696d653c2f7370616e3e0a0a3c7370616e20636c6173733d22
> │ │ │ │ │  6770223e496e205b345d3a203c2f7370616e3e3c7370616e20636c6173733d22
> │ │ │ │ │  6f223e253c2f7370616e3e3c7370616e20636c6173733d226b223e74696d6569
> │ │ │ │ │  743c2f7370616e3e2074696d652e736c65657028302e3035290a3c7370616e20
> │ │ │ │ │ -636c6173733d22676f223e35302e31206d73202b2d20322e3331207573207065
> │ │ │ │ │ +636c6173733d22676f223e35302e31206d73202b2d20322e3135207573207065
> │ │ │ │ │  72206c6f6f7020286d65616e202b2d207374642e206465762e206f6620372072
> │ │ │ │ │  756e732c203130206c6f6f70732065616368293c2f7370616e3e0a3c2f707265
> │ │ │ │ │  3e3c2f6469763e0a3c2f6469763e0a3c703e546869732077696c6c20616c736f
> │ │ │ │ │  20737570706f727420746f702d6c6576656c206173796e63207768656e207573
> │ │ │ │ │  696e672049507974686f6e20372e302b3c2f703e0a3c64697620636c6173733d
> │ │ │ │ │  22686967686c696768742d69707974686f6e206e6f7472616e736c617465223e
> │ │ │ │ │  3c64697620636c6173733d22686967686c69676874223e3c7072653e3c737061
>
>
As far as I can see from the header this is a html file, correct me if I am
wrong. Did you try to look at the file as text?
It might give a more useful diff.


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37369: Getting network-manager-openconnect to work

[Efraim Flashner]

Instead of adding openconnect to network-manager, would it be enough to

(substitute* "the-file"
  (("/usr/sbin/openconnect") "openconnect"))


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#37374: "Guix is too old and cannot be upgraded" (guix package -u)

[Ricardo Wurmus]

Hi Jesse,

> Wow, now I want to keep guix up-to-date all the time. How long has it
> been since you pulled/upgraded guix?

There’s no need to worry about that.  The mechanism to upgrade Guix has
changed significantly over the past years and has since stabilized.
This error will usually only hit you if you’re using a *much* older
Guix that predates the changes how “guix pull” works.

(It’s still a good idea to keep Guix up-to-date, of course.)

--
Ricardo