bug#36330: guix-build-branch.sh failed on Fedora 29

[Matt Wette]

On 6/24/19 11:54 AM, Ludovic Courtès wrote:


readlink -f /home/mwette/proj/guix/guix-1.0.1/test-tmp/var


[mwette@localhost ~]$ readlink -f /home/mwette/proj/guix/guix-1.0.1/test-tmp/var

/home/mwette/proj/guix/guix-1.0.1/test-tmp/var

bug#36364: Potential SSH session exhaustion

[Jakob L. Kreuze]

Hi,

Ludovic Courtès  writes:

> Procedures like ‘send-files’ call ‘channel-get-exit-status’ and
> ‘close-port’ on ports that represent SSH channels.
>
> AFAICS, ‘close-port’ triggers a call of ‘ptob_close’ in Guile-SSH,
> which in turn calls ‘ssh_channel_close’.
>
> sshd_config(5) says:
>
>MaxSessions Specifies the maximum number of open shell, login or subsystem
> (e.g. sftp) sessions permitted per network connection. Multiple sessions may 
> be
> established by clients that support connection multiplexing. Setting 
> MaxSessions
> to 1 will effectively disable session multiplexing, whereas setting it to 0 
> will
> prevent all shell, login and subsystem sessions while still permitting
> forwarding. The default is 10.
>
> So you must be hitting this limit.

Ah, thank you for the corrections :)

> I see that ‘remote-eval’ does not close ‘remote’ though, so this
> channel port remains open until it’s GC’d, which happens too late.
> Could you try the attached patch? It allows me to do more than 10
> ‘remote-eval’ calls in a row.

Wow, that was quick. The patch works like a charm, thanks!

Regards,
Jakob


signature.asc
Description: PGP signature

bug#35610: Freshly installed IBus intput method is not listed as an input source

[sirgazil]

 On Mon, 24 Jun 2019 10:57:55 -0500 Chris Marusich  
wrote 

 > sirgazil  writes: 
 >  
 > > Hi, 
 > > 
 > > I installed the GNU system using the Guix System 1.0 ISO installer and 
 > > reconfigured the system to work around the installer "%base-packages" 
 > > bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35541). 
 > > 
 > > When I install the "ibus-anthy" input method, I don't find any way of 
 > > using it because it is not listed in the GNOME input sources, nor in 
 > > the list of input methods in IBus Preferences. 
 > > 
 > > 
 > > ## Steps to reproduce 
 > > 
 > > 1. guix install ibus ibus-anthy font-adobe-source-han-sans 
 > > 2. Go to "GNOME Settings → Language & Region" 
 > > 3. In "Input Sources", click on the Add button (+) 
 > > 4. In the list that appears, select "Japanese" 
 > > 
 > > 
 > > ## Unexpected result 
 > > 
 > > "Japanese (Anthy)" is not listed. 
 > > 
 > > 
 > > ## Expected result 
 > > 
 > > "Japanese (Anthy)" is listed. 
 > > 
 > > Also, adding it to the list of Input Sources enables a new option to 
 > > the right of the GNOME top bar where you can select the different 
 > > Input Sources you have set. When you choose the newly added Japanese 
 > > (Anthy) you can start writing Japanese right away. For example, typing 
 > > "aiueo" would result in "あいうえお". 
 > > 
 > > Also, the keyboard combination Super+Space allows you to alternate between 
 > > input sources 
 > > 
 > > 
 > > ## Additional information 
 > > 
 > > The Japanese (Anthy) input method is not listed in IBus preferences 
 > > either. You can check by doing the following: 
 > > 
 > > 1. Click on Activities 
 > > 2. Click on Show Applications 
 > > 3. Click on IBus Preferences 
 > > 4. Click on the Input Method tab 
 > > 5. Click on the Add button 
 > > 6. Click on Japanese 
 > > 
 > > You should be able to see Anthy there, but it isn't. 
 >  
 > Please try the following: 
 >  
 > 1) Make sure you've installed ibus, ibus-anthy, and a font package that 
 > gives you appropriate fonts for Japanese.  For example: 
 >  
 >  guix package -i ibus ibus-anthy font-adobe-source-han-sans 
 >  
 > 2) Make sure you've set the following environment variables in a place 
 > where they will be made available to your desktop environment (in Guix 
 > System, it is sufficient to put this in your ~/.bash_profile): 
 >  
 >  export 
 > GUIX_GTK2_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-2.0/2.10.0/immodules-gtk2.cache"
 >  
 >  export 
 > GUIX_GTK3_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"
 >  
 >  
 > 2) Remove the ibus cache: 
 >  
 >  rm -rf ~/.cache/ibus 
 >  
 > 3) Log out and back in. 
 >  
 > I was able to reproduce your issue in a Guix VM, and I was able to 
 > resolve it by taking those steps.  Please let me know if this fixes the 
 > issue for you, as well. 


やった！本当にありがとう、Chrisさん！ :)

So, Guix is not setting those variables for the user, right? And maybe 
variables for other GUI toolkits too (Qt)?

bug#36069: Menu-based installer unusable through noVNC

[Björn Höfling]

Reopened.

On Mon, 3 Jun 2019 11:35:17 +0200
Robert Vollmert  wrote:

> There seems to be some conflict between the “graphical” installer’s
> idea of the console size and VNC’s (which appears to be noVNC
> https://novnc.com/info.html). As you can see in the attached
> screenshot, the screen is cropped on all sides, particularly making
> the menu choices unviewable.

Today I installed Guix on a Server which uses Guacamole as a web-based
VNC-client according to the HTML code, see 
https://guacamole.apache.org/

I also had the problem that the screen of the installer was too small,
I'm attaching two screenshots: Of the normal GRUB startup and the
unreadable installer. 

I solved it by hitting CTRL-ALT-F3 through the soft-keyboard and
installing it manually: In this console, everything looked fine.

Björn



pgpaZxI2B1yqy.pgp
Description: OpenPGP digital signature

bug#36364: Potential SSH session exhaustion

[Ludovic Courtès]

Hello Jakob,

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> In developing a test suite for the internals of 'guix deploy', the
> virtual machine I spun up spat out an OpenSSH error that I've never
> encountered before.
>
>   Jun 24 16:59:26 localhost sshd[235]: error: no more sessions
>
> This is, initially, quite curious. Creating the SSH session with
> #:log-verbosity set to 'protocol gives some insight.

[...]

>   ;;; [2019/06/24 12:59:26.546104, 2] channel_open: Creating a channel 76 
> with 64000 window and 32768 max packet
>   ;;; [2019/06/24 12:59:26.546407, 2] ssh_packet_channel_open_conf: Received 
> a CHANNEL_OPEN_CONFIRMATION for channel 76:9
>   ;;; [2019/06/24 12:59:26.546438, 2] ssh_packet_channel_open_conf: Remote 
> window : 0, maxpacket : 32768
>   ;;; [2019/06/24 12:59:26.546839, 2] channel_rcv_change_window: Adding 
> 2097152 bytes to channel (76:9) (from 0 bytes)
>   ;;; [2019/06/24 12:59:26.546865, 2] channel_request: Channel request exec 
> success
>   ;;; [2019/06/24 12:59:26.630055, 2] grow_window: growing window (channel 
> 76:9) to 128 bytes
>   ;;; [2019/06/24 12:59:27.272139, 2] channel_open: Creating a channel 77 
> with 64000 window and 32768 max packet
>   ;;; [2019/06/24 12:59:27.272846, 1] ssh_packet_channel_open_fail: Channel 
> opening failure: channel 77 error (2) open failed
>
> I will admit that my knowledge of the SSH protocol is limited, but the
> rising channel number gives me the impression that channels are going
> out of scope and aren't being cleaned up.

Procedures like ‘send-files’ call ‘channel-get-exit-status’ and
‘close-port’ on ports that represent SSH channels.

AFAICS, ‘close-port’ triggers a call of ‘ptob_close’ in Guile-SSH, which
in turn calls ‘ssh_channel_close’.

sshd_config(5) says:

--8<---cut here---start->8---
   MaxSessions
   Specifies the maximum number of open shell, login or
   subsystem (e.g. sftp) sessions permitted per network
   connection.  Multiple sessions may be established by clients
   that support connection multiplexing.  Setting MaxSessions to
   1 will effectively disable session multiplexing, whereas
   setting it to 0 will prevent all shell, login and subsystem
   sessions while still permitting forwarding.  The default is
   10.
--8<---cut here---end--->8---

So you must be hitting this limit.

I see that ‘remote-eval’ does not close ‘remote’ though, so this channel
port remains open until it’s GC’d, which happens too late.  Could you
try the attached patch?  It allows me to do more than 10 ‘remote-eval’
calls in a row.

Thanks,
Ludo’.

diff --git a/guix/remote.scm b/guix/remote.scm
index cc051dee8a..fa19ece112 100644
--- a/guix/remote.scm
+++ b/guix/remote.scm
@@ -116,6 +116,7 @@ remote store."
   (mbegin %store-monad
 (built-derivations to-build)
 ((store-lift send-files) to-send remote #:recursive? #t)
+(return (close-connection remote))
 (return (%remote-eval lowered session
 (let ((to-send (map (lambda (input)
   (match (gexp-input-thing input)
@@ -127,4 +128,5 @@ remote store."
   (mbegin %store-monad
 ((store-lift send-files) to-send remote #:recursive? #t)
 (return (build-derivations remote to-build))
+(return (close-connection remote))
 (return (%remote-eval lowered session)))

bug#36363: let's encrypt hash mismatch

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

>  expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
>  actual hash:   0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
>  hash mismatch for store item
>  '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem' build

I believe you’d be fine if substitutes were enabled, but they’re not.

In the meantime, you can fetch those files with something like:

  wget -O /tmp/isrgrootx1.pem \

http://berlin.guix.gnu.org/file/isrgrootx1.pem/sha256/0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
  guix download file:///tmp/isrgrootx1.pem

But yeah, like Tobias writes, it’s a bit of a problem.  Should we mirror
them somewhere?  Does Let’s Encrypt have them under a versioned URL
elsewhere?

HTH,
Ludo’.

bug#36335: Is /dev/kvm missing ACLs?

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> I was trying to run some VMs via "guix system vm", and I noticed that
> I didn't have permission to use KVM.  This issue can be worked around by
> running qemu as root, or by adding yourself to the "kvm" group.
> However, I found it curious that the /dev/kvm device didn't have ACLs
> granting me access:
>
> $ getfacl /dev/kvm
> getfacl: Removing leading '/' from absolute path names
> # file: dev/kvm
> # owner: root
> # group: kvm
> user::rw-
> group::rw-
> other::---
>
>
> Is it expected that on Guix System, /dev/kvm does not by default receive
> ACLs granting me access?

Guix System doesn’t use ACLs at all.

However, the udev rule for kvm sets it up like this:

  crw-rw 1 root kvm 10, 232 Jun 24 08:38 /dev/kvm

and the build users are part of the ‘kvm’ group.  I personally arrange
to have my user account in that group too.

Thanks,
Ludo’.

bug#36333: Misleading hint for url-fetch

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice  skribis:

> I just encountered the following:
>
>  foo.scm:4:2: error: url-fetch: unbound variable
>  hint: Did you forget `(use-modules (guix build download))'?
>
> Actually importing that module, instead of (guix download), will cause
> some other very hard-to-debug error that I can't remember but
> coincidentally helped someone fix on #guix the other day.

Oh, bad hint indeed.

Now, the program cannot determine that of the two ‘url-fetch’, only one
makes sense.

Should it search further and propose all the possible options?  In
general there won’t be more than a couple of options.

Thanks,
Ludo’.

bug#36325: In procedure put-string: Wrong type argument in position 1 (expecting open output port): #

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> following redirection to `https://ci.guix.gnu.org'...
> Backtrace:
>3 (apply-smob/1 #)
> In ice-9/boot-9.scm:
> 705:2  2 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  1 (_ #(#(#)))
> In guix/ui.scm:
>   1734:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:1734:12: In procedure run-guix-command:
> In procedure put-string: Wrong type argument in position 1 (expecting open 
> output port): #
> substitution of 
> /gnu/store/hwyhdah35bv4xkqg4rdaw7a1hs5ny3mk-gcc-toolchain-5.5.0 failed

I believe this is the same issue as
, fixed earlier today.

Thanks,
Ludo’.

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Jelle Licht]

Hi S_W, Maxim

Tomáš Čech  writes:

> Hi Ludo,
> [...]
>
> But with Maxim's DBus related patches and my NM patch it seemed to be
> starting daemons at least.

Do you still have the patches for these changes lying around? I am
trying to get network-manager-vpnc packaged+working, but it seems this
issue will also need to be solved first.
>
> Best regards,
>
> S_W

All the best,

Jelle

bug#36276: Not found .so files in bundle made by guix pack

[Ludovic Courtès]

Hello,

Andréas Livet  skribis:

> Found a solution !
>
> https://superuser.com/a/1348051

Good!  So you ran:

  strip --remove-section=.note.ABI-tag \
 ./gnu/store/…/lib/libQt5Core.so.5

right?

Indeed the .so file produced by Guix has this section:

--8<---cut here---start->8---
$ file -L 
/gnu/store/y1nlilwa34wqvmvmraggwv12jfdp0kya-qtbase-5.11.3/lib/libQt5Core.so
/gnu/store/y1nlilwa34wqvmvmraggwv12jfdp0kya-qtbase-5.11.3/lib/libQt5Core.so: 
ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux), dynamically 
linked, interpreter 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 3.16.0, stripped
--8<---cut here---end--->8---

… which reflects in the “for GNU/Linux 3.16.0” that we see above.

What does “uname -r” return on this CentOS machine?  I’m guessing it’s
older than 3.16.0.

The effect of the ‘strip’ command is that libQt5Base.so can be loaded,
but some functionality maybe missing (things that use the ‘renameat2’
system call specifically; see below.)

> Do you think it is related to guix pack in some way ?

I researched it a bit and in qtbase, in
‘src/corelib/global/minimum-linux_p.h’, we can see this:

--8<---cut here---start->8---
#if QT_CONFIG(getentropy)
#  define MINLINUX_MAJOR3
#  define MINLINUX_MINOR17
#  define MINLINUX_PATCH0
#elif QT_CONFIG(renameat2)
#  define MINLINUX_MAJOR3
#  define MINLINUX_MINOR16
#  define MINLINUX_PATCH0
#else
#  define MINLINUX_MAJOR2
#  define MINLINUX_MINOR6
#  define MINLINUX_PATCH28
#endif
--8<---cut here---end--->8---

Since we build Qt with ‘renameat2’ support, Qt effectively requires a
Linux kernel >= 3.16.0.

We could build it without that requirement; 3.16.0 is already rather
old, so I’m not sure we should do it.

Thoughts?

(Note that the Guix package already has a patch to allow it to work with
kernels < 4.11.)

Ludo’.

bug#36330: guix-build-branch.sh failed on Fedora 29

[Ludovic Courtès]

Hello,

Matt Wette  skribis:

> On 6/24/19 1:26 AM, Ludovic Courtès wrote:
>
>> make check TESTS=tests/guix-build-branch.sh
>
> I did not use "-j" and the above fails also.

Does it fail in the same way?

What does this command return:

  readlink -f /home/mwette/proj/guix/guix-1.0.1/test-tmp/var

?

> In addition,
>
> $ guix install glibc-locales
>
> failed as well.  I don't remember the error message.
> I will see if I can find a log.

Please open a separate bug report when you have more info.

Thank you,
Ludo’.

bug#36363: let's encrypt hash mismatch

[Tobias Geerinckx-Rice]

Julien,

Julien Lepiller wrote:
trying to run guix pull on the overdrive at my place to try and 
fix a
bug in openssh which doesn't start at boot, I get this error 
message:


[…]


 letsencryptauthorityx3.pem  2KiB 385KiB/s 00:00
 [##] 100.0% sha256 hash mismatch
 for /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem:
 expected hash: 
 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
 actual hash: 
 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac


This will keep happening until we find(/create) a versioned URL 
for these files.  Let's Encrypt like to change them in place.


The last time this happened they'd added CR/LF line endings for no 
reason at all, but this time I don't have the old version around 
anymore…


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#36364: Potential SSH session exhaustion

[Jakob L. Kreuze]

Hello, Guix

In developing a test suite for the internals of 'guix deploy', the
virtual machine I spun up spat out an OpenSSH error that I've never
encountered before.

  Jun 24 16:59:26 localhost sshd[235]: error: no more sessions

This is, initially, quite curious. Creating the SSH session with
#:log-verbosity set to 'protocol gives some insight.

  ;;; [2019/06/24 13:08:36.711847, 2] channel_open: Creating a channel 43 with 
64000 window and 32768 max packet
  ;;; [2019/06/24 13:08:36.711959, 2] ssh_packet_global_request: Received 
SSH_MSG_GLOBAL_REQUEST packet
  ;;; [2019/06/24 13:08:36.711987, 2] ssh_packet_global_request: UNKNOWN 
SSH_MSG_GLOBAL_REQUEST hostkeys...@openssh.com 0
  ;;; [2019/06/24 13:08:36.712010, 1] ssh_packet_process: Couldn't do anything 
with packet type 80
  ;;; [2019/06/24 13:08:36.712197, 2] ssh_packet_channel_open_conf: Received a 
CHANNEL_OPEN_CONFIRMATION for channel 43:0
  ;;; [2019/06/24 13:08:36.712219, 2] ssh_packet_channel_open_conf: Remote 
window : 0, maxpacket : 32768
  ;;; [2019/06/24 13:08:36.712618, 2] channel_rcv_change_window: Adding 2097152 
bytes to channel (43:0) (from 0 bytes)
  ;;; [2019/06/24 13:08:36.712651, 2] channel_request: Channel request exec 
success
  ...
  ;;; [2019/06/24 12:59:26.296022, 2] channel_open: Creating a channel 74 with 
64000 window and 32768 max packet
  ;;; [2019/06/24 12:59:26.296262, 2] ssh_packet_channel_open_conf: Received a 
CHANNEL_OPEN_CONFIRMATION for channel 74:8
  ;;; [2019/06/24 12:59:26.296308, 2] ssh_packet_channel_open_conf: Remote 
window : 0, maxpacket : 32768
  ;;; [2019/06/24 12:59:26.296667, 2] channel_rcv_change_window: Adding 2097152 
bytes to channel (74:8) (from 0 bytes)
  ;;; [2019/06/24 12:59:26.296721, 2] channel_request: Channel request exec 
success
  ;;; [2019/06/24 12:59:26.487339, 2] grow_window: growing window (channel 
74:8) to 128 bytes
  ;;; [2019/06/24 12:59:26.489031, 2] channel_open: Creating a channel 75 with 
64000 window and 32768 max packet
  ;;; [2019/06/24 12:59:26.489376, 2] ssh_packet_channel_open_conf: Received a 
CHANNEL_OPEN_CONFIRMATION for channel 75:8
  ;;; [2019/06/24 12:59:26.489402, 2] ssh_packet_channel_open_conf: Remote 
window : 0, maxpacket : 32768
  ;;; [2019/06/24 12:59:26.489858, 2] channel_rcv_change_window: Adding 2097152 
bytes to channel (75:8) (from 0 bytes)
  ;;; [2019/06/24 12:59:26.489906, 2] channel_request: Channel request exec 
success
  ;;; [2019/06/24 12:59:26.542586, 2] grow_window: growing window (channel 
75:8) to 128 bytes
  ;;; [2019/06/24 12:59:26.546104, 2] channel_open: Creating a channel 76 with 
64000 window and 32768 max packet
  ;;; [2019/06/24 12:59:26.546407, 2] ssh_packet_channel_open_conf: Received a 
CHANNEL_OPEN_CONFIRMATION for channel 76:9
  ;;; [2019/06/24 12:59:26.546438, 2] ssh_packet_channel_open_conf: Remote 
window : 0, maxpacket : 32768
  ;;; [2019/06/24 12:59:26.546839, 2] channel_rcv_change_window: Adding 2097152 
bytes to channel (76:9) (from 0 bytes)
  ;;; [2019/06/24 12:59:26.546865, 2] channel_request: Channel request exec 
success
  ;;; [2019/06/24 12:59:26.630055, 2] grow_window: growing window (channel 
76:9) to 128 bytes
  ;;; [2019/06/24 12:59:27.272139, 2] channel_open: Creating a channel 77 with 
64000 window and 32768 max packet
  ;;; [2019/06/24 12:59:27.272846, 1] ssh_packet_channel_open_fail: Channel 
opening failure: channel 77 error (2) open failed

I will admit that my knowledge of the SSH protocol is limited, but the
rising channel number gives me the impression that channels are going
out of scope and aren't being cleaned up. For reference, this occurs
when 'remote-eval' is invoked multiple times -- which, in turn, invokes
'send-files'.

  building path(s) `/gnu/store/3rfkwdbayg7m3wdrydmcljnfqhvrady5-remote-exp.scm'
  sending 1 store item (0 MiB) to 'localhost'...
  exporting path `/gnu/store/3rfkwdbayg7m3wdrydmcljnfqhvrady5-remote-exp.scm'
  building path(s) `/gnu/store/ib59b0pnypsw4vf59f2gwpwhn343xnzb-remote-exp.scm'
  sending 1 store item (0 MiB) to 'localhost'...
  exporting path `/gnu/store/ib59b0pnypsw4vf59f2gwpwhn343xnzb-remote-exp.scm'
  [this is where the "no more sessions" error occurs]

Currently, my code performs all of these 'remote-eval' calls with the
same session. I suppose it would be possible to create a new session for
each call, but I feel I should raise this as it may cause issues down
the line: do we need to do something about cleaning up SSH channels?

If a reproducible example is necessary, you can look to the temporary
'tests/machine.scm' in 64ffe453b0c71f417927737fa808dffe858359cd on my
personal branch.[1]

Regards,
Jakob

[1]: https://git.sr.ht/~jakob/guix/


signature.asc
Description: PGP signature

bug#36363: let's encrypt hash mismatch

[Julien Lepiller]

Hi!

trying to run guix pull on the overdrive at my place to try and fix a
bug in openssh which doesn't start at boot, I get this error message:

building /gnu/store/qvrwd6v9jy50j121f963v7rps8fc8qsa-isrgrootx1.pem.drv...
building 
/gnu/store/3s8l6bg8gsfxrqallc5w02drl1m021ky-letsencryptauthorityx3.pem.drv...

Starting download
of /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem From
https://letsencrypt.org/certs/isrgrootx1.pem...

Starting download
of /gnu/store/bcq7sqhg18b7b1q87j8z60d5hybsdafm-letsencryptauthorityx3.pem
From https://letsencrypt.org/certs/letsencryptauthorityx3.pem...
downloading from https://letsencrypt.org/certs/isrgrootx1.pem...
downloading from
https://letsencrypt.org/certs/letsencryptauthorityx3.pem...

 letsencryptauthorityx3.pem  2KiB 385KiB/s 00:00
 [##] 100.0% sha256 hash mismatch
 for /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem:
 expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
 actual hash:   0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
 hash mismatch for store item
 '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem' build
 of /gnu/store/qvrwd6v9jy50j121f963v7rps8fc8qsa-isrgrootx1.pem.drv
 failed View build log at
 '/var/log/guix/drvs/qv/rwd6v9jy50j121f963v7rps8fc8qsa-isrgrootx1.pem.drv.bz2'.
 cannot build derivation
 `/gnu/store/03xigpq7w1ll67ydrwhjydmybdj5gd2i-le-certs-0.drv': 1
 dependencies couldn't be built guix pull: error: build failed: build
 of `/gnu/store/03xigpq7w1ll67ydrwhjydmybdj5gd2i-le-certs-0.drv' failed


Thanks!

bug#36276: Not found .so files in bundle made by guix pack

[Andréas Livet]

Hi !

Found a solution !

https://superuser.com/a/1348051

Don't really understand why I got this problem which seems to be WSL only...

Do you think it is related to guix pack in some way ?

Thank you,

Andréas

bug#35610: Freshly installed IBus intput method is not listed as an input source

[Chris Marusich]

sirgazil  writes:

> Hi,
>
> I installed the GNU system using the Guix System 1.0 ISO installer and
> reconfigured the system to work around the installer "%base-packages"
> bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35541).
>
> When I install the "ibus-anthy" input method, I don't find any way of
> using it because it is not listed in the GNOME input sources, nor in
> the list of input methods in IBus Preferences.
>
>
> ## Steps to reproduce
>
> 1. guix install ibus ibus-anthy font-adobe-source-han-sans
> 2. Go to "GNOME Settings → Language & Region"
> 3. In "Input Sources", click on the Add button (+)
> 4. In the list that appears, select "Japanese"
>
>
> ## Unexpected result
>
> "Japanese (Anthy)" is not listed.
>
>
> ## Expected result
>
> "Japanese (Anthy)" is listed.
>
> Also, adding it to the list of Input Sources enables a new option to
> the right of the GNOME top bar where you can select the different
> Input Sources you have set. When you choose the newly added Japanese
> (Anthy) you can start writing Japanese right away. For example, typing
> "aiueo" would result in "あいうえお".
>
> Also, the keyboard combination Super+Space allows you to alternate between 
> input sources
>
>
> ## Additional information
>
> The Japanese (Anthy) input method is not listed in IBus preferences either. 
> You can check by doing the following:
>
> 1. Click on Activities
> 2. Click on Show Applications
> 3. Click on IBus Preferences
> 4. Click on the Input Method tab
> 5. Click on the Add button
> 6. Click on Japanese
>
> You should be able to see Anthy there, but it isn't.

Please try the following:

1) Make sure you've installed ibus, ibus-anthy, and a font package that
gives you appropriate fonts for Japanese.  For example:

  guix package -i ibus ibus-anthy font-adobe-source-han-sans

2) Make sure you've set the following environment variables in a place
where they will be made available to your desktop environment (in Guix
System, it is sufficient to put this in your ~/.bash_profile):

  export 
GUIX_GTK2_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-2.0/2.10.0/immodules-gtk2.cache"
  export 
GUIX_GTK3_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"

2) Remove the ibus cache:

  rm -rf ~/.cache/ibus

3) Log out and back in.

I was able to reproduce your issue in a Guix VM, and I was able to
resolve it by taking those steps.  Please let me know if this fixes the
issue for you, as well.

-- 
Chris


signature.asc
Description: PGP signature

bug#36330: guix-build-branch.sh failed on Fedora 29

[Matt Wette]

On 6/24/19 1:26 AM, Ludovic Courtès wrote:


make check TESTS=tests/guix-build-branch.sh


I did not use "-j" and the above fails also.

In addition,

$ guix install glibc-locales

failed as well.  I don't remember the error message.
I will see if I can find a log.

Thanks for responding,
Matt

bug#36117: qemu-binfmt with non-native chroot

[Ludovic Courtès]

Hi!

Vagrant Cascadian  skribis:

> That said, it's still a manual step (mounting /gnu or /gnu/store/qemu*)
> required to do something that could otherwise be handled transparently
> with a static build of qemu and adjusting the binfmt_misc flags... so if
> permitted to dream, I still think that would be a nice option to have
> available. :)

Yes, it sounds like we could/should do that too!

We’ll end up having big qemu-* binaries, each one with its own copy of
glibc, for instance.  Is there something smart we could do to avoid
ending up with a huge package?

Thanks,
Ludo’.

bug#36221: Make GDM *not* restart 504 times on failure

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> This is not a Guix bug.  Closing.
>
> Very many GDM restarts is what happens on Debian Stretch and Arch
> (GNOME 3.32) as well after renaming /usr/share/xorg/modules, just like
> it does on Guix.  On Guix’ wip-gnome3.30 GDM fails in a different way;
> maybe I will investigate further and then file a bug at GDM.

Thanks for checking!

Ludo’.

bug#36330: guix-build-branch.sh failed on Fedora 29

[Ludovic Courtès]

Hi Matt,

Matt Wette  skribis:

> FAIL: tests/guix-build-branch
> =
>
> accepted connection from pid 18056, user mwette
> + guix build --version
> guix build (GNU Guix) 1.0.1
> Copyright (C) 2019 the Guix authors
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> + guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)'
> ++ guix build guile-gcrypt -d
> accepted connection from pid 18073, user mwette
> + 
> orig_drv=/home/mwette/proj/guix/guix-1.0.1/test-tmp/store/18ck9672wax2asspiin305l3drpjq8g3-guile-gcrypt-0.1.0.drv
> ++ guix build guile-gcrypt --with-branch=guile-gcrypt=master -d
> accepted connection from pid 18078, user mwette
> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
> guix build: error: cannot fetch branch 'master' from 
> https://notabug.org/cwebber/guile-gcrypt.git: failed to resolve path 
> '/home/mwette/proj/guix/guix-1.0.1/test-tmp/var/18047/cache-18047/guix/checkouts/yxwtks42sv5sew5opm5xd3umk7xmxwfr2vgde5nsbfj6fmb5epmq':
>  No such file or directory

It looks like the directory where Guix was attempting to store the
checkout of guile-gcrypt disappeared under its feet.  I wonder if this
could be due to parallel builds (“make check -j”).

Does it work if you run this test specifically?

  make check TESTS=tests/guix-build-branch.sh

?

Regardless, this is a harmless issue.

Thank you,
Ludo’.

bug#36299: Report: failed to compute the derivation for Guix

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

>> > -following redirection to `https://ci.guix.gnu.org'...
>
> I think that that redirection is wrong (the URL is not specific enough for a
> substitute, right?).

Good catch!  maintenance.git commit
37c2348d72559f9c475cf9250ecef7b33c1c fixes the redirect for nginx on
hydra.gnu.org.

Thanks,
Ludo’.