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

[pelzflorian (Florian Pelz)]

On Tue, May 07, 2019 at 06:11:58AM +0200, pelzflorian (Florian Pelz) wrote:
> I had the same problem; it works for me now after I added ibus and
> ibus-anthy to the system packages, Anthy appeared in ibus-setup.  I
> believe I had done no other steps other than experimenting with
> libexec/ibus-setup-anthy (which I believe did not change anything).
> 

Since then IBus Preferences has an icon in GNOME Shell.  Maybe it is
the same issue as .  Maybe a
reboot is all that would have been required.

I did add what ibus-setup told me to my bashrc by the way, but I
believe it has no effect on GNOME.

Regards,
Florian

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

[pelzflorian (Florian Pelz)]

I had the same problem; it works for me now after I added ibus and
ibus-anthy to the system packages, Anthy appeared in ibus-setup.  I
believe I had done no other steps other than experimenting with
libexec/ibus-setup-anthy (which I believe did not change anything).

Regards,
Florian

bug#35590: Emacs info can't open info manuals

[sirgazil]

 On Mon, 06 May 2019 10:07:36 -0500 Mark H Weaver  wrote 


 > Hi, 
 >  
 > sirgazil  writes: 
 >  
 > > M-x getenv PATH RET shows "bin"s in other paths, but not "/bin": 
 > > 
 > > /gnu/store/hk4f641r18vpj44m42pny6rp1nwg3d4w-glib-2.56.3-bin/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/setuid-programs:/home/sirgazil/.config/guix/current/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin
 > >  
 >  
 > My first thought was "Why isn't /bin in your PATH?", but actually I see 
 > that /bin isn't in my PATH either, but that doesn't matter because 
 > 'bash' is installed in my system profile, which means that I have 'sh' 
 > in /run/current-system/profile/bin. 
 >  
 > You should too, but apparently you don't. 
 >  
 > 'bash' is included in %base-packages, which should normally be included 
 > in your 'packages' field of your OS config.  It should look something 
 > like this: 
 >  
 >  ;; This is where we specify system-wide packages. 
 >  (packages (append (list 
 >  ;; your added 
 >  ;; packages here 
 >  ) 
 >  %base-packages)) 
 >  
 > If you don't include %base-packages in your system profile, you are 
 > likely to run into problems.  Several of the packages in there could be 
 > safely deleted, but some of them, including 'sh', are widely assumed to 
 > always be in PATH. 


Oh, yes. The system configuration generated by the Guix 1.0 installer did not 
include %base-packages. The bug has been reported 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35541).

My packages form looks like this:

(packages
(list (specification->package "nss-certs")))

The Guix manual has been updated with instructions to work around the problem 
(https://www.gnu.org/software/guix/manual/en/guix.html#Preparing-for-Installation).
 So one should add:

(packages
 (append (list (specification->package "nss-certs"))
  %base-packages))

and then:

guix pull && sudo guix system reconfigure /etc/config.scm


This may fix some of the bugs I've reported (and the ones I haven't).

 
 > If you want to remove a few programs from %base-packages, I recommend 
 > doing something like this: 
 >  
 >  ;; This is where we specify system-wide packages. 
 >  (packages (append (list 
 >  ;; your added 
 >  ;; packages here 
 >  ) 
 >  (fold delete %base-packages (list sudo nano 
 >  
 > Note that 'fold' is in (srfi srfi-1), so you'll need to import it in 
 > your OS config file if you use it. 


Good to know. I'll go with the whole set, though.


Thanks, Mark.

bug#35616: go-github-com-spf13-pflag build fails

[Maxim Cournoyer]

On master:

--8<---cut here---start->8---
starting phase `check'
go: disabling cache (/homeless-shelter/.cache/go-build) due to initialization 
failure: mkdir /homeless-shelter: permission denied
# github.com/spf13/pflag
src/github.com/spf13/pflag/bool_test.go:175: T.Errorf format %s has arg b of 
wrong type *bool
src/github.com/spf13/pflag/bool_test.go:178: T.Errorf format %s has arg c of 
wrong type *bool
FAILgithub.com/spf13/pflag [build failed]
Backtrace:
   5 (primitive-load "/gnu/store/c32i7lg8amk32c7f2ilarwyc3ip…")
In ice-9/eval.scm:
   191:35  4 (_ #f)
In srfi/srfi-1.scm:
   863:16  3 (every1 # …)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/gnu-build-system.scm:
   799:28  2 (_ _)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/go-build-system.scm:
230:4  1 (check #:tests? _ #:import-path _)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
--8<---cut here---end--->8---

bug#35615: go-github-com-getsentry-raven-go build fails

[Maxim Cournoyer]

On current master:

--8<---cut here---start->8---
starting phase `check'
go: disabling cache (/homeless-shelter/.cache/go-build) due to initialization 
failure: mkdir /homeless-shelter: permission denied
# github.com/getsentry/raven-go
src/github.com/getsentry/raven-go/client_test.go:84: T.Errorf format %d has arg 
packet.Level of wrong type raven.Severity
src/github.com/getsentry/raven-go/client_test.go:176: T.Errorf format %s has 
arg actual of wrong type raven.Timestamp
src/github.com/getsentry/raven-go/stacktrace_test.go:140: T.Errorf call has 
arguments but no formatting directives
FAILgithub.com/getsentry/raven-go [build failed]
Backtrace:
   5 (primitive-load "/gnu/store/xzia0im8bznz1aiagfmg769sqrn…")
In ice-9/eval.scm:
   191:35  4 (_ #f)
In srfi/srfi-1.scm:
   863:16  3 (every1 # …)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/gnu-build-system.scm:
   799:28  2 (_ _)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/go-build-system.scm:
230:4  1 (check #:tests? _ #:import-path _)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
--8<---cut here---end--->8---

bug#35603: Go build system mishandles repetitive import paths

[Maxim Cournoyer]

Hello again,

Leo Famulari  writes:

> Looks like it affects packages that use tarballs (instead of Git
> checkouts) and have a repetitive element in the import path. For
> example, 'github.com/restic/restic' is also broken.

I've fixed restic with commit fb09818277; sorry!

Maxim

bug#35603: Go build system mishandles repetitive import paths (was [PATCH] build: go-build-system: Ensure uniform unpacking directory.)

[Maxim Cournoyer]

Hello Leo,

Leo Famulari  writes:

> On Sun, Apr 14, 2019 at 12:03:05AM -0400, Maxim Cournoyer wrote:
>> From 1f7535fbe28f7ac96e824b792e9f1a140b8c54cd Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer 
>> Date: Fri, 5 Apr 2019 00:00:08 -0400
>> Subject: [PATCH 3/3] build: go-build-system: Ensure uniform unpacking
>>  directory.
>>
>> Depending on whether the source is a directory or an archive, we strip the
>> source directory or preserve it, respectively.  This change makes it so that
>> whether the type of the source, it is unpacked at the expected location given
>> by the IMPORT-PATH of the Go build system.
>>
>> * guix/build/go-build-system.scm: Add the (ice-9 ftw) module.
>> (unpack): Add inner procedure to maybe strip the top level directory of an
>> archive, document it and use it.
>
> This commit (or patch series) broke the build of Syncthing and maybe
> others.

Thanks for the heads-up!

> It seems like the the new unpacking code is stripping duplicate
> directory names?
>

It does as documented in the docstring of the unpack phase:

   If the SOURCE archive has a single top level directory,
   it is stripped so that the sources appear directly under UNPACK-PATH.

This behavior was made possible with commit
f42e4ebb56fe4f16991ca6c6e060c8f3535865cb, that made it so that:

[...] whether the type of the source, it is unpacked at the expected
location given by the IMPORT-PATH of the Go build system.

> It fails like this:
>
> --
> starting phase `increase-test-timeout'
> Backtrace:
>6 (primitive-load "/gnu/store/yfvy06fscz726da5wjvh9jxjsah…")
> In ice-9/eval.scm:
>191:35  5 (_ _)
> In srfi/srfi-1.scm:
>863:16  4 (every1 # …)
> In 
> /gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/gnu-build-system.scm:
>799:28  3 (_ _)
> In ice-9/eval.scm:
> 619:8  2 (_ #(#(#) (#:inputs # …)))
> In 
> /gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:
>635:19  1 (with-atomic-file-replacement "src/github.com/syncthin…" …)
> In unknown file:
>0 (mkstemp! "src/github.com/syncthing/syncthing/build.go…" …)
>
> ERROR: In procedure mkstemp!:
> In procedure mkstemp!: No such file or directory
> --
>
> And indeed, if you keep the failed build directory, you will see that
> the path 'src/github.com/syncthing/syncthing' does not exist, even
> though this corresponds to the Go import path specified in the package
> definition.
>
> Instead it is like src/github.com/syncthing' which is incorrect.

The fix was to drop the "unpack-pack" argument of the go-build-system for
syncthing, which means we want the sources unpacked at the location
specified by the "import-path".

Done with commit d879fd80c74371120a2cfa30e18a2e28dc02d31d; closing.

Thank you!

Maxim

bug#35588: [PATCH] ui: Search matches additional package outputs.

[Chris Marusich]

Ludovic Courtès  writes:

> Could we have just this hunk or is there something I’m missing that
> would make it insufficient?

That hunk alone is not enough, but I think the attached patch would do
the trick.  We just need to allow for the new possibility that the
"field" procedure returns a list of strings.

What do you think?

-- 
Chris
From c1150a217a416ef4ceccf87c56e36e8e921f873a Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Mon, 6 May 2019 01:51:30 -0700
Subject: [PATCH] ui: Make package outputs searchable.

* guix/ui.scm (relevance): Allow the "field" procedure of a metric to
return a list, and handle that case appropriately.  Update docstring.
(%package-metrics): Add a metric for package outputs.
* guix/scripts/package.scm (find-packages-by-description): Update
docstring.

Co-authored-by: Tobias Geerinckx-Rice 
---
 guix/scripts/package.scm |  6 +++---
 guix/ui.scm  | 24 +++-
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index aa27984ea2..06e4cf5b9c 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -180,9 +180,9 @@ hooks\" run when building the profile."
 ;;;
 
 (define (find-packages-by-description regexps)
-  "Return two values: the list of packages whose name, synopsis, or
-description matches at least one of REGEXPS sorted by relevance, and the list
-of relevance scores."
+  "Return two values: the list of packages whose name, synopsis, description,
+or output matches at least one of REGEXPS sorted by relevance, and the list of
+relevance scores."
   (let ((matches (fold-packages (lambda (package result)
   (if (package-superseded package)
   result
diff --git a/guix/ui.scm b/guix/ui.scm
index 92c845e944..b7ccd8312a 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -11,6 +11,8 @@
 ;;; Copyright © 2016 Benz Schenk 
 ;;; Copyright © 2018 Kyle Meyer 
 ;;; Copyright © 2018 Ricardo Wurmus 
+;;; Copyright © 2019 Chris Marusich 
+;;; Copyright © 2019 Tobias Geerinckx-Rice 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1370,9 +1372,9 @@ WIDTH columns.  EXTRA-FIELDS is a list of symbol/value pairs to emit."
 (define (relevance obj regexps metrics)
   "Compute a \"relevance score\" for OBJ as a function of its number of
 matches of REGEXPS and accordingly to METRICS.  METRICS is list of
-field/weight pairs, where FIELD is a procedure that returns a string
-describing OBJ, and WEIGHT is a positive integer denoting the weight of this
-field in the final score.
+field/weight pairs, where FIELD is a procedure that returns a string or list
+of strings describing OBJ, and WEIGHT is a positive integer denoting the
+weight of this field in the final score.
 
 A score of zero means that OBJ does not match any of REGEXPS.  The higher the
 score, the more relevant OBJ is to REGEXPS."
@@ -1394,8 +1396,11 @@ score, the more relevant OBJ is to REGEXPS."
 ((field . weight)
  (match (field obj)
(#f  relevance)
-   (str (+ relevance
-   (* (score str) weight)))
+   ((? string? str) (+ relevance
+   (* (score str) weight)))
+   ((? list? lst) (+ relevance
+ (* weight
+(apply + (map score lst)
 0
 metrics))
 
@@ -1404,6 +1409,15 @@ score, the more relevant OBJ is to REGEXPS."
   ;; of regexps.
   `((,package-name . 4)
 
+;; Match against uncommon outputs.
+(,(lambda (package)
+(filter (lambda (output)
+  (not (member output
+   ;; Some common outpus shared by many packages.
+   '("out" "debug" "doc" "static"
+(package-outputs package)))
+ . 1)
+
 ;; Match regexps on the raw Texinfo since formatting it is quite expensive
 ;; and doesn't have much of an effect on search results.
 (,(lambda (package)
-- 
2.20.1



signature.asc
Description: PGP signature

bug#35589: Scribus and GIMP: Clipped, non-resizable windows and pixelated icons

[Chris Marusich]

sirgazil  writes:

> Hi,
>
> A few days ago I mentioned an issue with a Scribus installed on a
> foreign distribution using Guix
> (https://lists.gnu.org/archive/html/help-guix/2019-04/msg00249.html). I'm
> experiencing the same problem with Scribus and the GIMP in a GNU
> system installed in a real machine using the ISO installer
> (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
>
> Scribus (these are from my Guix  on foreign distro experience, but the 
> problem in the GNU system is the same):
>
> 
> https://multimedialib.files.wordpress.com/2019/04/scribus-154-splash-2019-04-22.png
> 
> https://multimedialib.files.wordpress.com/2019/04/scribus-154-dialog-2019-04-22.png
> 
> https://multimedialib.files.wordpress.com/2019/04/scribus-154-main-2019-04-22.png
>
> GIMP (these are taken from the GNU system):
>
> 
> https://multimedialib.files.wordpress.com/2019/05/gimp-21010-2019-05-05.png
>
> The windows are clipped (extend beyond the screen limits), you can't
> resize them, and the icons look like zoomed-in bitmaps. The icon
> problem is minor, but the other problems make it really hard to use
> the applications as intended.
>
> ---
> https://sirgazil.bitbucket.io/

I cannot reproduce these issues using Guix System on commit
aa7cdc57dc28673dedfc6ec210974aaa0099a419.  The gimp and scribus programs
do not appear to render icons incorrectly, their windows are resizable,
and their windows are not clipped.

Can you reproduce the issue in a VM?  You can try with the "guix system
vm" command; you might need to slightly customize your OS config file.
If you aren't sure how to do that, just let me know, and I'll try to
help.

-- 
Chris


signature.asc
Description: PGP signature

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

[Chris Marusich]

ison  writes:

> I currently have ibus with anthy working, but I had this exact same problem at
> first. I'm not 100% sure what I finally did to solve it, but I think it may 
> have
> been a missing environment variable. Here is what I have set:
> export 
> GTK_IM_MODULE_FILE="/run/current-system/profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"
> export GTK_IM_MODULE="xim"
> export XMODIFIERS="@im=ibus"
> export QT_IM_MODULE="xim"
>
> I'm thinking the $GTK_IM_MODULE_FILE variable is the missing ingredient. 
> However, while attempting to fix this I also installed the packages:
> ibus, ibus-anthy, dbus, python-dbus, python2-dbus
>
> If you need these packages too to make it work then perhaps its worth
> investigating if the anthy package is missing some dependencies.

FWIW I have the following in my ~/.bash_profile.  If you search the
email list archives for these environment variables, you'll find some
relevant discussions:

--8<---cut here---start->8---
# Enable GTK+2 and GTK+3 programs to simultaneously use the right
# immodules cache file.  This is a Guix-specific work-around.
# See: https://lists.gnu.org/archive/html/guix-devel/2016-08/msg01634.html
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"
--8<---cut here---end--->8---

ご覧の通り、日本語入力はできています。

If it still doesn't work for you, I'll be happy to help troubleshoot.
I set this up years ago, and the one thing I remember is that it was a
bit of a hassle.

-- 
Chris


signature.asc
Description: PGP signature

bug#35561: Fresh install, guix pull exits with error, hash mismatch

[Calle Kabo]

I tried running guix pull again, but still didn't work
https://paste.debian.net/1081770 

Here's my config.scm
https://paste.debian.net/1081771 

I then connected via VPN so I got an IP in the Netherlands, and le-certs 
downloaded just fine! So this may be a mirroring issue?

/Calle

bug#35561: Fresh install, guix pull exits with error, hash mismatch

[Tobias Geerinckx-Rice]

Ludo',

Ludovic Courtès wrote:

These 3 files are now available from https://ci.guix.gnu.org as
substitutes:


Thanks!  I tried to help Calle with this on IRC yesterday but had 
to make due with my own little build farm (which had already 
collected 2 of the 3 files) and scp…


Did you do a fancier version of this, or is there a better 
(automated?) way we could handle this in future?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#35561: Fresh install, guix pull exits with error, hash mismatch

[Ludovic Courtès]

Hi,

Calle Kabo  skribis:

> manager@guix ~$ guix pull

[...]

> building 
> /gnu/store/vf1ni4bdwlya3f5ii7wq6agiwdvzapmw-letsencryptauthorityx3.pem.drv...
> downloading from https://letsencrypt.org/certs/letsencryptauthorityx3.pem...
> |sha256 hash mismatch for 
> /gnu/store/bcq7sqhg18b7b1q87j8z60d5hybsdafm-letsencryptauthorityx3.pem:
>   expected hash: 0zbamj6c7zqw1j9mbqygc8k1ykgj6xiisp9svmlif5lkbnyjhnkk
>   actual hash:   1kvac1dhm1d02bhrfj6l1cz1dpldz6ishb78zzvy8245zgvh7pdn
> hash mismatch for store item 
> '/gnu/store/bcq7sqhg18b7b1q87j8z60d5hybsdafm-letsencryptauthorityx3.pem'

These 3 files are now available from https://ci.guix.gnu.org as
substitutes:

--8<---cut here---start->8---
$ sha1sum *.pem
af259e2e2ebd686861e3f89be6845298bed6c223  isrgrootx1.pem
36205ada14d1cded7e85294762630b6b57088198  letsencryptauthorityx3.pem
59057c31e97d8e10cc52edb389b1e87089a245aa  letsencryptauthorityx4.pem
$ for i in *.pem; do echo $(guix hash $i) $i ; done
0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y isrgrootx1.pem
0zbamj6c7zqw1j9mbqygc8k1ykgj6xiisp9svmlif5lkbnyjhnkk letsencryptauthorityx3.pem
003dc94c8qwj634h0dq743x7hqv9rdcfaisdksprkmi2jd107xq4 letsencryptauthorityx4.pem
--8<---cut here---end--->8---

and the ‘le-certs’ package itself is now available as a substitute from
ci.guix.gnu.org.

For the record, this failure stems from the combination of two issues:
(1) letsencrypt.org modified these PEM files in place, and (2) the old
copies had disappeared from ci.guix.gnu.org.  Fortunately they were still
on mirror.hydra.gnu.org, which is where I copied them frmo.

We should also update our ‘le-certs’ package definition to refer to the
new file hashes.

Ludo’.

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

[ison]

I currently have ibus with anthy working, but I had this exact same problem at
first. I'm not 100% sure what I finally did to solve it, but I think it may have
been a missing environment variable. Here is what I have set:
export 
GTK_IM_MODULE_FILE="/run/current-system/profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"
export GTK_IM_MODULE="xim"
export XMODIFIERS="@im=ibus"
export QT_IM_MODULE="xim"

I'm thinking the $GTK_IM_MODULE_FILE variable is the missing ingredient. 
However, while attempting to fix this I also installed the packages:
ibus, ibus-anthy, dbus, python-dbus, python2-dbus

If you need these packages too to make it work then perhaps its worth
investigating if the anthy package is missing some dependencies.

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

[sirgazil]

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.


---
https://sirgazil.bitbucket.io/

bug#35550: Installer: wpa_supplicant fails to start

[Danny Milosavljevic]

Hi Ludo,

what happens when the loop reads the pid file when it contains just half of a
numeral?  It won't detect it, right?


pgphutGIhbtZ3.pgp
Description: OpenPGP digital signature

bug#35606: Gajim

[Raghav Gururajan]

T-G-R!

One more interesting information. I had to close the Gajim by killing the 
process. What I noticed in "system monitor" is that the Gajim was running as 
root instead of that user. I retried, it is the same. Gajim runs as root. Weird.

May 6, 2019 7:45 PM, "Raghav Gururajan"  wrote:

> T-G-R!
> 
> Oh my goodness, I didn't notice that. LoL. Of course the OS is GNU/Linux. ;). 
> The bug report was
> automatically generated when I opened the app. I didn't create it.
> 
> Yes, as you said, nothing works. All menu greyed out. Can't even close the 
> app.
> 
> May 6, 2019 7:40 PM, "Tobias Geerinckx-Rice"  wrote:
> 
>> Raghav, Clément, Ricardo, Guix,
>> 
>> Raghav Gururajan wrote:
>> 
>>> ## Versions
>>> - OS: Linux
>> 
>> Never heard of that OS… ;-)
>> 
>>> - GTK+ Version: 3.24.7
>>> - PyGObject Version: 3.28.3
>>> - python-nbxmpp Version: 0.6.10
>>> - Gajim Version: 1.1.3
>> 
>> Thanks for these, but providing the output of ‘guix describe’
>> instead (and making sure both your system and user's packages have
>> been fully updated to that version) would be even more
>> informative.
>> 
>>> ## Traceback
>> 
>> I can't reproduce this, by the way (output below). Gajim opens a
>> window and a welcome wizard (which I close). Then I'm left with
>> the main window where all the menus work… but all options are
>> greyed out (except a few under ‘View’). So the programme isn't
>> frozen, but I can't close it, not even using my window manager's
>> key bindings. Hence the SIGINT at the end.
>> 
>> Very strange. Is anyone successfully using Gajim on Guix System?
>> Clément? Ricardo?
>> 
>> Kind regards,
>> 
>> T G-R
>> 
>> ~ λ gajim
>> (..gajim-real-real:23682): dbind-WARNING **: 21:27:06.317: AT-SPI:
>> Error retrieving accessibility bus address:
>> org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus
>> was not provided by any .service files
>> creating /home/nckx/.config/gajim directory
>> creating /home/nckx/.cache/gajim directory
>> creating /home/nckx/.local/share/gajim directory
>> creating /home/nckx/.local/share/gajim/certs directory
>> creating /home/nckx/.local/share/gajim/debug directory
>> creating /home/nckx/.local/share/gajim/plugins_data directory
>> creating /home/nckx/.config/gajim/pluginsconfig directory
>> creating /home/nckx/.config/gajim/localcerts directory
>> creating /home/nckx/.cache/gajim/plugins_download directory
>> creating /home/nckx/.local/share/gajim/plugins directory
>> creating /home/nckx/.cache/gajim/avatars directory
>> creating /home/nckx/.config/gajim/theme directory
>> Traceback (most recent call last):
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/applicati
>> n.py",
>> line 221, in _activate
>> self.interface.run(self)
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/gui_inter
>> ace.py",
>> line 2550, in run
>> app.plugin_manager = plugins.PluginManager()
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/h
>> lpers.py",
>> line 129, in __call__
>> cls.instance = super(Singleton, cls).__call__(*args, **kwargs)
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/p
>> uginmanager.py",
>> line 115, in __init__
>> pc = self.scan_dir_for_plugins(path)
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/h
>> lpers.py",
>> line 114, in wrapper
>> result = f(*args, **kwargs)
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/p
>> uginmanager.py",
>> line 598, in scan_dir_for_plugins
>> if not os.path.isdir(path):
>> File
>> "/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/genericpath.py",
>> line 42, in isdir
>> st = os.stat(s)
>> TypeError: stat: path should be string, bytes, os.PathLike or
>> integer, not NoneType
>> 06/05/19 21:27:07 (E) gajim.notify Notifications D-Bus connection
>> failed
>> Traceback (most recent call last):
>> File
>> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/notify.py
>> ,
>> line 96, in on_proxy_ready
>> self.daemon_capabilities = proxy.GetCapabilities()
>> File
>> "/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/
>> verrides/Gio.py",
>> line 204, in __call__
>> None)
>> GLib.GError: g-dbus-error-quark:
>> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
>> org.freedesktop.Notifications was not provided by any .service
>> files (2)
>> ^CSIGINT/SIGTERM received
>> ~ λ

bug#35606: Gajim

[Raghav Gururajan]

T-G-R!

Oh my goodness, I didn't notice that. LoL. Of course the OS is GNU/Linux. ;). 
The bug report was automatically generated when I opened the app. I didn't 
create it.

Yes, as you said, nothing works. All menu greyed out. Can't even close the app.

May 6, 2019 7:40 PM, "Tobias Geerinckx-Rice"  wrote:

> Raghav, Clément, Ricardo, Guix,
> 
> Raghav Gururajan wrote:
> 
>> ## Versions
>> - OS: Linux
> 
> Never heard of that OS… ;-)
> 
>> - GTK+ Version: 3.24.7
>> - PyGObject Version: 3.28.3
>> - python-nbxmpp Version: 0.6.10
>> - Gajim Version: 1.1.3
> 
> Thanks for these, but providing the output of ‘guix describe’
> instead (and making sure both your system and user's packages have
> been fully updated to that version) would be even more
> informative.
> 
>> ## Traceback
> 
> I can't reproduce this, by the way (output below). Gajim opens a
> window and a welcome wizard (which I close). Then I'm left with
> the main window where all the menus work… but all options are
> greyed out (except a few under ‘View’). So the programme isn't
> frozen, but I can't close it, not even using my window manager's
> key bindings. Hence the SIGINT at the end.
> 
> Very strange. Is anyone successfully using Gajim on Guix System?
> Clément? Ricardo?
> 
> Kind regards,
> 
> T G-R
> 
> ~ λ gajim
> (..gajim-real-real:23682): dbind-WARNING **: 21:27:06.317: AT-SPI:
> Error retrieving accessibility bus address:
> org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus
> was not provided by any .service files
> creating /home/nckx/.config/gajim directory
> creating /home/nckx/.cache/gajim directory
> creating /home/nckx/.local/share/gajim directory
> creating /home/nckx/.local/share/gajim/certs directory
> creating /home/nckx/.local/share/gajim/debug directory
> creating /home/nckx/.local/share/gajim/plugins_data directory
> creating /home/nckx/.config/gajim/pluginsconfig directory
> creating /home/nckx/.config/gajim/localcerts directory
> creating /home/nckx/.cache/gajim/plugins_download directory
> creating /home/nckx/.local/share/gajim/plugins directory
> creating /home/nckx/.cache/gajim/avatars directory
> creating /home/nckx/.config/gajim/theme directory
> Traceback (most recent call last):
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/applicati
> n.py",
> line 221, in _activate
> self.interface.run(self)
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/gui_inter
> ace.py",
> line 2550, in run
> app.plugin_manager = plugins.PluginManager()
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/h
> lpers.py",
> line 129, in __call__
> cls.instance = super(Singleton, cls).__call__(*args, **kwargs)
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/p
> uginmanager.py",
> line 115, in __init__
> pc = self.scan_dir_for_plugins(path)
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/h
> lpers.py",
> line 114, in wrapper
> result = f(*args, **kwargs)
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/p
> uginmanager.py",
> line 598, in scan_dir_for_plugins
> if not os.path.isdir(path):
> File
> "/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/genericpath.py",
> line 42, in isdir
> st = os.stat(s)
> TypeError: stat: path should be string, bytes, os.PathLike or
> integer, not NoneType
> 06/05/19 21:27:07 (E) gajim.notify Notifications D-Bus connection
> failed
> Traceback (most recent call last):
> File
> "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/notify.py
> ,
> line 96, in on_proxy_ready
> self.daemon_capabilities = proxy.GetCapabilities()
> File
> "/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/
> verrides/Gio.py",
> line 204, in __call__
> None)
> GLib.GError: g-dbus-error-quark:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.freedesktop.Notifications was not provided by any .service
> files (2)
> ^CSIGINT/SIGTERM received
> ~ λ

bug#35606: Gajim

[Tobias Geerinckx-Rice]

Raghav, Clément, Ricardo, Guix,

Raghav Gururajan wrote:

## Versions
- OS: Linux


Never heard of that OS…  ;-)


- GTK+ Version: 3.24.7
- PyGObject Version: 3.28.3
- python-nbxmpp Version: 0.6.10
- Gajim Version: 1.1.3


Thanks for these, but providing the output of ‘guix describe’ 
instead (and making sure both your system and user's packages have 
been fully updated to that version) would be even more 
informative.



## Traceback


I can't reproduce this, by the way (output below).  Gajim opens a 
window and a welcome wizard (which I close).  Then I'm left with 
the main window where all the menus work… but all options are 
greyed out (except a few under ‘View’).  So the programme isn't 
frozen, but I can't close it, not even using my window manager's 
key bindings.  Hence the SIGINT at the end.


Very strange.  Is anyone successfully using Gajim on Guix System? 
Clément?  Ricardo?


Kind regards,

T G-R


~ λ gajim
(..gajim-real-real:23682): dbind-WARNING **: 21:27:06.317: AT-SPI: 
Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus 
was not provided by any .service files

creating /home/nckx/.config/gajim directory
creating /home/nckx/.cache/gajim directory
creating /home/nckx/.local/share/gajim directory
creating /home/nckx/.local/share/gajim/certs directory
creating /home/nckx/.local/share/gajim/debug directory
creating /home/nckx/.local/share/gajim/plugins_data directory
creating /home/nckx/.config/gajim/pluginsconfig directory
creating /home/nckx/.config/gajim/localcerts directory
creating /home/nckx/.cache/gajim/plugins_download directory
creating /home/nckx/.local/share/gajim/plugins directory
creating /home/nckx/.cache/gajim/avatars directory
creating /home/nckx/.config/gajim/theme directory
Traceback (most recent call last):
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/application.py", 
 line 221, in _activate

   self.interface.run(self)
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/gui_interface.py", 
 line 2550, in run

   app.plugin_manager = plugins.PluginManager()
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/helpers.py", 
 line 129, in __call__

   cls.instance = super(Singleton, cls).__call__(*args, **kwargs)
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/pluginmanager.py", 
 line 115, in __init__

   pc = self.scan_dir_for_plugins(path)
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/helpers.py", 
 line 114, in wrapper

   result = f(*args, **kwargs)
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/pluginmanager.py", 
 line 598, in scan_dir_for_plugins

   if not os.path.isdir(path):
 File 
 "/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/genericpath.py", 
 line 42, in isdir

   st = os.stat(s)
TypeError: stat: path should be string, bytes, os.PathLike or 
integer, not NoneType
06/05/19 21:27:07 (E) gajim.notify Notifications D-Bus connection 
failed

Traceback (most recent call last):
 File 
 "/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/notify.py", 
 line 96, in on_proxy_ready

   self.daemon_capabilities = proxy.GetCapabilities()
 File 
 "/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/overrides/Gio.py", 
 line 204, in __call__

   None)
GLib.GError: g-dbus-error-quark: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service 
files (2)

^CSIGINT/SIGTERM received
~ λ 


signature.asc
Description: PGP signature

bug#35540: Installer displays encrypted partition password entry in cleartext

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> On Mon, May 06, 2019 at 08:14:46PM +0200, pelzflorian (Florian Pelz) wrote:
>> When creating a user account, the translation for Home Directory
>> (“Persönliches Verzeichnis”) gets cut off to “Persönliches Verzeic”,
>> but I believe this is not important.
>> 
>
> This cut-off happens even on higher resolution screens.  Hmm well it
> would be nicer if the space for the Home Directory were 4 letters
> wider, but it is not all that important.

I agree.  I’ll commit the patch below, which works fine for German (at
least before the “Hide” checkbox patch).

Thanks,
Ludo’.

diff --git a/gnu/installer/newt/user.scm b/gnu/installer/newt/user.scm
index deab056e0c..ac07d26c8b 100644
--- a/gnu/installer/newt/user.scm
+++ b/gnu/installer/newt/user.scm
@@ -34,7 +34,7 @@
   "Run a form to enter the user name, home directory, and password.  Use NAME,
 REAL-NAME, and HOME-DIRECTORY as the initial values in the form."
   (define (pad-label label)
-(string-pad-right label 20))
+(string-pad-right label 25))
 
   (let* ((label-name
   (make-label -1 -1 (pad-label (G_ "Name"
@@ -44,7 +44,7 @@ REAL-NAME, and HOME-DIRECTORY as the initial values in the form."
   (make-label -1 -1 (pad-label (G_ "Home directory"
  (label-password
   (make-label -1 -1 (pad-label (G_ "Password"
- (entry-width 30)
+ (entry-width 35)
  (entry-name (make-entry -1 -1 entry-width
  #:initial-value name))
  (entry-real-name (make-entry -1 -1 entry-width

bug#35550: Installer: wpa_supplicant fails to start

[pelzflorian (Florian Pelz)]

On Mon, May 06, 2019 at 12:21:26AM +0200, Ludovic Courtès wrote:
> It’d be great if you could do some testing with the patch below.  Then I
> guess we’ll push a Shepherd release with this fix.
> 

The second patch (the one for Guix is the only one I have tested)
works fine on the system which always failed before since sometime
after 1.0.

One time wpa-supplicant worked fine but it had an error establishing
the internet connection, but I am quite certain it was an unrelated
hardware issue.

Regards,
Florian

bug#35540: Installer displays encrypted partition password entry in cleartext

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> On Mon, May 06, 2019 at 12:02:16PM +0200, Ludovic Courtès wrote:
>> I would perhaps add that checkbox only for the passphrase, in part
>
> I disagree, people would expect it (and file bugs) for other passwords
> for the same reasons (other people watching while you install Guix
> vs. wanting to visually confirm you have not mistyped etc.)

Yeah OK, that makes sense to me.

>> because when I test an install I prefer to have fewer keystrokes :-),
>> but also because this might clutter dialog boxes and cause troubles:
>> what if the translation of “Hide” is takes up more space? is it still
>> going to fit?
>>
>
> German “Verbergen” is somewhat longer than “Hide”; I tried translating
> it locally and it still fits perfectly on my low res AMD GPU screen.

Perfect.

So I guess you can go ahead and push, Mathieu!

Thank you,
Ludo’.

bug#35607: Installer: Cannot exit during user creation step

[pelzflorian (Florian Pelz)]

When pressing the Exit button in the graphical installer during the
User Creation step, the installer instead continues with Desktop
Environment selection.

Regards,
Florian

bug#35604: Is the top bootloader entry for previous generations the current one?

[pelzflorian (Florian Pelz)]

On Mon, May 06, 2019 at 08:52:26PM +0200, Tobias Geerinckx-Rice wrote:
> How about changing ‘previous generations’ to ‘all generations’, and have it
> include the current generation at the top (now with # and date, maybe
> ‘(current)’ appended)?
> 
> That way we can keep the default nice and friendly and skimmable in ~5s, and
> the overview is actually a complete overview.
> 

I agree.  Your suggestion is better.

Regards,
Florian

bug#35606: Gajim

[Raghav Gururajan]

## Versions
- OS: Linux
- GTK+ Version: 3.24.7
- PyGObject Version: 3.28.3
- python-nbxmpp Version: 0.6.10
- Gajim Version: 1.1.3

## Traceback
```
Traceback (most recent call last):
 File 
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/application.py",
 line 221, in _activate
 self.interface.run(self)
 File 
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/gui_interface.py",
 line 2550, in run
 app.plugin_manager = plugins.PluginManager()
 File 
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/helpers.py",
 line 129, in __call__
 cls.instance = super(Singleton, cls).__call__(*args, **kwargs)
 File 
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/pluginmanager.py",
 line 115, in __init__
 pc = self.scan_dir_for_plugins(path)
 File 
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/helpers.py",
 line 114, in wrapper
 result = f(*args, **kwargs)
 File 
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/pluginmanager.py",
 line 598, in scan_dir_for_plugins
 if not os.path.isdir(path):
 File 
"/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/genericpath.py",
 line 42, in isdir
 st = os.stat(s)
TypeError: stat: path should be string, bytes, os.PathLike or integer, not 
NoneType

```
## Steps to reproduce the problem

Install and open the app. This bug error shows up.

bug#35586: GNOME

[Raghav Gururajan]

T-G-R!

Thanks for your email. I understand what you mentioned. I came across this link 
(https://blogs.gnome.org/mcatanzaro/2016/09/21/gnome-3-22-core-apps/), where 
the dev(s) recommend to use generic names while packaging GNOME Core Apps. :)

I think it is better to use generic names for package names and include other 
aliases/project-names in the package tagline and/or package description.

May 6, 2019 7:20 PM, "Tobias Geerinckx-Rice"  wrote:

> Raghav,
> 
> Thanks for taking a look at this. I'm sure there's plenty to be 
> improved in how we package a large collection of software like 
> GNOME in an intuitive way.
> 
> Raghav Gururajan wrote:
> 
>> The following gnome core applications have already been included
>> in
>> guix's gnome package but requires correct renaming?
>> 
>> epiphany --> gnome-web
> 
> Using ‘correct’ here is a bit strong.
> 
> ~ λ guix install epiphany
> ~ λ gnome-web
> bash: gnome-web: command not found
> ~ λ epiphany
> # browsin' time
> 
> While we don't blindly name packages after the binaries they
> provide, of course, a look at the project's own publications
> doesn't reduce the confusion. Ironic.
> 
> “Web is the web browser for the GNOME desktop and for elementary
> OS,
> based on the popular WebKit engine. It offers a simple, clean,
> beautiful view of the web featuring first-class GNOME and
> Pantheon
> desktop integration. Its code name is Epiphany.
> 
> You may install Web from the software repositories of most
> Linux
> operating systems, where it is normally packaged as
> "epiphany-browser" or "epiphany". ”[0]
> 
> The README[1] mainly, but not exclusively, talks about ‘Epiphany’.
> Even the two URLs balance each other out. I don't think there's
> enough here to justify gross renaming, and in the name of all
> that's holy let's avoid another mass renaming incident.
> 
> Personally, I think adding ‘GNOME Foo’ to the synopses of all
> these packages is sufficient (epiphany does this by coincidence,
> calling itself the ‘GNOME web browser’). Eventually, this could
> be another use for the separate (G)UI display name field as
> suggested in the games thread. :-)
> 
> Package names aren't opaque identifiers, but they can be a little
> technical IMO.
> 
> Kind regards,
> 
> T G-R
> 
> [0]: https://wiki.gnome.org/Apps/Web
> [1]: https://github.com/GNOME/epiphany

bug#35540: Installer displays encrypted partition password entry in cleartext

[pelzflorian (Florian Pelz)]

On Mon, May 06, 2019 at 08:14:46PM +0200, pelzflorian (Florian Pelz) wrote:
> When creating a user account, the translation for Home Directory
> (“Persönliches Verzeichnis”) gets cut off to “Persönliches Verzeic”,
> but I believe this is not important.
> 

This cut-off happens even on higher resolution screens.  Hmm well it
would be nicer if the space for the Home Directory were 4 letters
wider, but it is not all that important.

Regards,
Florian

bug#35586: GNOME

[Tobias Geerinckx-Rice]

Raghav,

Thanks for taking a look at this.  I'm sure there's plenty to be 
improved in how we package a large collection of software like 
GNOME in an intuitive way.


Raghav Gururajan wrote:
The following gnome core applications have already been included 
in

guix's gnome package but requires correct renaming?

epiphany --> gnome-web


Using ‘correct’ here is a bit strong.

 ~ λ guix install epiphany
 ~ λ gnome-web
 bash: gnome-web: command not found
 ~ λ epiphany
 # browsin' time

While we don't blindly name packages after the binaries they 
provide, of course, a look at the project's own publications 
doesn't reduce the confusion.  Ironic.


 “Web is the web browser for the GNOME desktop and for elementary 
 OS,

  based on the popular WebKit engine. It offers a simple, clean,
  beautiful view of the web featuring first-class GNOME and 
  Pantheon

  desktop integration. Its code name is Epiphany.

  You may install Web from the software repositories of most 
  Linux

  operating systems, where it is normally packaged as
  "epiphany-browser" or "epiphany". ”[0]

The README[1] mainly, but not exclusively, talks about ‘Epiphany’. 
Even the two URLs balance each other out.  I don't think there's 
enough here to justify gross renaming, and in the name of all 
that's holy let's avoid another mass renaming incident.


Personally, I think adding ‘GNOME Foo’ to the synopses of all 
these packages is sufficient (epiphany does this by coincidence, 
calling itself the ‘GNOME web browser’).  Eventually, this could 
be another use for the separate (G)UI display name field as 
suggested in the games thread. :-)


Package names aren't opaque identifiers, but they can be a little 
technical IMO.


Kind regards,

T G-R

[0]: https://wiki.gnome.org/Apps/Web
[1]: https://github.com/GNOME/epiphany


signature.asc
Description: PGP signature

bug#35604: Is the top bootloader entry for previous generations the current one?

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice wrote:
How about changing ‘previous generations’ to ‘all generations’, 
and
have it include the current generation at the top (now with # 
and

date, maybe ‘(current)’ appended)?

That way we can keep the default nice and friendly and skimmable 
in

~5s, and the overview is actually a complete overview.


I'd like to give this patch a try, by the way, if it's considered 
acceptable.  Good excuse to dive into Guix's grub code a tiny bit.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#35604: Is the top bootloader entry for previous generations the current one?

[Tobias Geerinckx-Rice]

Florian,

pelzflorian (Florian Pelz) wrote:

GRUB’s boot menu displays a menuentry for booting the current
generation and a submenu with entries for previous generations.
However, it is not clear if the generation at the top of the 
submenu

is the current generation or if it is one generation before.


The current generation is by definition not a previous one and 
shouldn't appear in the ‘previous’ list, but I see how it could be 
confusing.  Especially once possible language barriers and 
translations are added to the mix.


I would prefer to resolve this by displaying the current 
generation’s
generation number and date outside the submenu as is done for 
the

previous generations in the submenu.


It makes for an uglier boot menu, which sounds silly, but I've 
noticed that the more numbers and symbols are on a screen, the 
more likely ‘non-geeks’ are to ignore the whole thing as something 
not meant for them to understand.  Especially a black one :-)  I 
see it as part of GNU's values to counter that attitude.


How about changing ‘previous generations’ to ‘all generations’, 
and have it include the current generation at the top (now with # 
and date, maybe ‘(current)’ appended)?


That way we can keep the default nice and friendly and skimmable 
in ~5s, and the overview is actually a complete overview.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#35605: GNOME Settings: Region & Language: Input source keyboard button does not work

[sirgazil]

Hi,

I installed the GNU system using Guix 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).

Every time I click the little keyboard button in Input sources, nothing happens.


## Steps to reproduce

1. Go to GNOME Settings → Language & Region → Input Sources.
2. Click on one of the sources.
3. Click the button that has a keyboard icon.


## Unexpected result

Nothing happens.


## Expected result

The Keyboard Layout window is displayed showing you the key mappings for the 
selected input source. Like this:

https://multimedialib.files.wordpress.com/2019/05/gnome-keyboard-layout-window-2019-05-06.png


---
https://sirgazil.bitbucket.io/

bug#35540: Installer displays encrypted partition password entry in cleartext

[pelzflorian (Florian Pelz)]

Sorry for being late to the feedback party.

On Mon, May 06, 2019 at 12:02:16PM +0200, Ludovic Courtès wrote:
> I would perhaps add that checkbox only for the passphrase, in part

I disagree, people would expect it (and file bugs) for other passwords
for the same reasons (other people watching while you install Guix
vs. wanting to visually confirm you have not mistyped etc.)


> because when I test an install I prefer to have fewer keystrokes :-),
> but also because this might clutter dialog boxes and cause troubles:
> what if the translation of “Hide” is takes up more space? is it still
> going to fit?
>

German “Verbergen” is somewhat longer than “Hide”; I tried translating
it locally and it still fits perfectly on my low res AMD GPU screen.

When creating a user account, the translation for Home Directory
(“Persönliches Verzeichnis”) gets cut off to “Persönliches Verzeic”,
but I believe this is not important.

Regards,
Florian

bug#35590: Emacs info can't open info manuals

[sirgazil]

This issue was related to a bug with the installer where "%base-packages" was 
not added to the system configuration file.¹ After working around the installer 
issue as described in the manual,² I can read manuals normally.


1. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35541
2. 
https://www.gnu.org/software/guix/manual/en/html_node/Guided-Graphical-Installation.html#Guided-Graphical-Installation


---
https://sirgazil.bitbucket.io/

bug#35599: No sound most of the time (dummy output)

[sirgazil]

It seems this sound issue was related to a bug with the installer where 
"%base-packages" was not added to the system configuration file.¹ After working 
around the installer issue as described in the manual,² I get sound every time 
I restart the machine. 

I want to test for a few more days before closing this bug.



1. https://issues.guix.info/issue/35541
2. 
https://www.gnu.org/software/guix/manual/en/html_node/Guided-Graphical-Installation.html#Guided-Graphical-Installation


---
https://sirgazil.bitbucket.io/

bug#35529: libdrm fails to build on armhf-linux

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus  writes:

> This has built fine on berlin.  We have a completed build for
> /gnu/store/3c28p8b07709isd9jlcnnnyrpgz4ndz8-libdrm-2.4.97.

 What kind of hardware was it built on?
>>>
>>> I’m not sure.  We’re using a few Overdrive 1000 machines that have quite
>>> a bit more RAM than the other armhf nodes.
>>
>> Are there any other kinds of build slaves that build armhf binaries for
>> Berlin?
>
> Yes.  We have a Beagleboard (x15.sjd.se), which is set up for 2 parallel
> builds and we use the Qemu service on 5 of our x86_64 machines to build
> for armhf.  (We do the same for aarch64, but using 5 different nodes.)

So, many of the armhf builds are done in an emulator.  This is exactly
what I was curious about.  One problem with doing this is that tests
performed during these builds do not necessarily reflect what will
happen on real armhf hardware.

I'll give just one example of where this approach will fail badly: tests
of thread synchronization.  The memory models used in ARM and x86_64 are
quite different, and an ARM emulator running on x86_64 will effectively
have a much stronger memory model than real ARM hardware does.

It's much harder to perform safe thread synchronization on ARM than on
x86_64.  Many programmers use idioms that they believe are safe, and
which work on x86_64, but are buggy on many architectures with weaker
memory models.  Those are the kinds of bugs that will *not* be
discovered by test suites when we perform the builds under QEMU.

I hope that we will soon phase out the practice of performing builds
within emulators.

In the meantime, it would be good to know which machine built 'libdrm'
for armhf.  Was that information recorded?

> “nss” failed its tests when built on x15.sjd.se, but it worked fine when
> building on one of the Overdrives.

Can you find the failed NSS build log from the X15?  It would useful to
see which tests failed, and whether they're the same ones that failed on
hydra-slave3, which is a Novena with 4 GB of RAM.  Here's the relevant
Hydra build page: .

   Thanks!
 Mark

bug#35604: Is the top bootloader entry for previous generations the current one?

[pelzflorian (Florian Pelz)]

GRUB’s boot menu displays a menuentry for booting the current
generation and a submenu with entries for previous generations.
However, it is not clear if the generation at the top of the submenu
is the current generation or if it is one generation before.

I would prefer to resolve this by displaying the current generation’s
generation number and date outside the submenu as is done for the
previous generations in the submenu.

Regards,
Florian

bug#35603: Go build system mishandles repetitive import paths

[Leo Famulari]

Looks like it affects packages that use tarballs (instead of Git
checkouts) and have a repetitive element in the import path. For
example, 'github.com/restic/restic' is also broken.


signature.asc
Description: PGP signature

bug#35603: Go build system mishandles repetitive import paths (was [PATCH] build: go-build-system: Ensure uniform unpacking directory.)

[Leo Famulari]

On Sun, Apr 14, 2019 at 12:03:05AM -0400, Maxim Cournoyer wrote:
> From 1f7535fbe28f7ac96e824b792e9f1a140b8c54cd Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Fri, 5 Apr 2019 00:00:08 -0400
> Subject: [PATCH 3/3] build: go-build-system: Ensure uniform unpacking
>  directory.
> 
> Depending on whether the source is a directory or an archive, we strip the
> source directory or preserve it, respectively.  This change makes it so that
> whether the type of the source, it is unpacked at the expected location given
> by the IMPORT-PATH of the Go build system.
> 
> * guix/build/go-build-system.scm: Add the (ice-9 ftw) module.
> (unpack): Add inner procedure to maybe strip the top level directory of an
> archive, document it and use it.

This commit (or patch series) broke the build of Syncthing and maybe
others.

It seems like the the new unpacking code is stripping duplicate
directory names?

It fails like this:

--
starting phase `increase-test-timeout'
Backtrace:
   6 (primitive-load "/gnu/store/yfvy06fscz726da5wjvh9jxjsah…")
In ice-9/eval.scm:
   191:35  5 (_ _)
In srfi/srfi-1.scm:
   863:16  4 (every1 # …)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/gnu-build-system.scm:
   799:28  3 (_ _)
In ice-9/eval.scm:
619:8  2 (_ #(#(#) (#:inputs # …)))
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:
   635:19  1 (with-atomic-file-replacement "src/github.com/syncthin…" …)
In unknown file:
   0 (mkstemp! "src/github.com/syncthing/syncthing/build.go…" …)

ERROR: In procedure mkstemp!:
In procedure mkstemp!: No such file or directory
--

And indeed, if you keep the failed build directory, you will see that
the path 'src/github.com/syncthing/syncthing' does not exist, even
though this corresponds to the Go import path specified in the package
definition.

Instead it is like src/github.com/syncthing' which is incorrect.


signature.asc
Description: PGP signature

bug#35590: Emacs info can't open info manuals

[Mark H Weaver]

Hi,

sirgazil  writes:

> M-x getenv PATH RET shows "bin"s in other paths, but not "/bin":
>
> /gnu/store/hk4f641r18vpj44m42pny6rp1nwg3d4w-glib-2.56.3-bin/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/setuid-programs:/home/sirgazil/.config/guix/current/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin

My first thought was "Why isn't /bin in your PATH?", but actually I see
that /bin isn't in my PATH either, but that doesn't matter because
'bash' is installed in my system profile, which means that I have 'sh'
in /run/current-system/profile/bin.

You should too, but apparently you don't.

'bash' is included in %base-packages, which should normally be included
in your 'packages' field of your OS config.  It should look something
like this:

  ;; This is where we specify system-wide packages.
  (packages (append (list
 ;; your added
 ;; packages here
 )
%base-packages))

If you don't include %base-packages in your system profile, you are
likely to run into problems.  Several of the packages in there could be
safely deleted, but some of them, including 'sh', are widely assumed to
always be in PATH.

If you want to remove a few programs from %base-packages, I recommend
doing something like this:

  ;; This is where we specify system-wide packages.
  (packages (append (list
 ;; your added
 ;; packages here
 )
(fold delete %base-packages (list sudo nano

Note that 'fold' is in (srfi srfi-1), so you'll need to import it in
your OS config file if you use it.

   Mark

bug#35529: libdrm fails to build on armhf-linux

[Ricardo Wurmus]

Mark H Weaver  writes:

> Ricardo Wurmus  writes:
>
>>> Ricardo Wurmus  writes:
>>>
 Mark H Weaver  writes:

> Hydra failed two consecutive attempts to build libdrm on armhf-linux:
>
>   https://hydra.gnu.org/build/3481547#tabs-summary
>
> Both build attempts were made on hydra-slave2, which is a Wandboard Quad
> based on the Freescale i.MX6 SOC.

 This has built fine on berlin.  We have a completed build for
 /gnu/store/3c28p8b07709isd9jlcnnnyrpgz4ndz8-libdrm-2.4.97.
>>>
>>> What kind of hardware was it built on?
>>
>> I’m not sure.  We’re using a few Overdrive 1000 machines that have quite
>> a bit more RAM than the other armhf nodes.
>
> Are there any other kinds of build slaves that build armhf binaries for
> Berlin?

Yes.  We have a Beagleboard (x15.sjd.se), which is set up for 2 parallel
builds and we use the Qemu service on 5 of our x86_64 machines to build
for armhf.  (We do the same for aarch64, but using 5 different nodes.)

“nss” failed its tests when built on x15.sjd.se, but it worked fine when
building on one of the Overdrives.

--
Ricardo

bug#35586: GNOME

[Raghav Gururajan]

Ah, I see. ☺
On Mon, 2019-05-06 at 11:14 +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, May 06, 2019 at 03:57:48AM -0400, Raghav Gururajan wrote:
> Also, I think it should be okay to include apps mentioned in
> "incubator" section as well. In Guix, users can roll back to older
> versions of newer ones are unstable.
> 
> Well, incubator apps have not enough polish.  Then again, what back
> in2016 was an incubator app maybe works fine now — I see the
> bloglinking to https://wiki.gnome.org/Design/Apps which lists Notes
> ascore now.  Dictionary is listed as inactive/retired on the other
> hand.
> Regards,Florian

bug#35586: GNOME

[Raghav Gururajan]

Yeah! You could be right.

On Mon, 2019-05-06 at 11:05 +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, May 06, 2019 at 03:51:54AM -0400, Raghav Gururajan wrote:
> On 5 May 2019 16:48, "pelzflorian (Florian Pelz)"  orian.de> wrote:
> You can also type both Epiphany and (your language’s translation of)
> Web in the GNOME Activities search bar to find Epiphany.  The same
> goes for Nautilus.  The terminal command is also still epiphany or
> nautilus. 
> I do not know if it is possible to give a package two names; I
> believe it is not. 
> I understand what you are saying. It appears epiphany is the old name
> (https://en.m.wikipedia.org/wiki/GNOME_Web). Dev must have used
> epiphany now a days as a habit.
> Also, the previous blog link you sent me, recommends to use generic
> names.
> 
> Maybe gnome-web could be the real package’s name and there could be
> apackage called epiphany that propagates gnome-web, like the
> gnomemeta-package does?  Same for nautilus etc.
> Regards,Florian
> 

bug#35540: Installer displays encrypted partition password entry in cleartext

[Ludovic Courtès]

Mathieu Othacehe  skribis:

>> I would perhaps add that checkbox only for the passphrase, in part
>> because when I test an install I prefer to have fewer keystrokes :-),
>
> The parameter is disabled by default and enabled only for disk
> encryption and root/user passwords so I'm not sure I get what you mean.

I mean that when I do a test install, I essentially hit RET RET RET RET,
and sometimes TAB ludo foo, and this change adds an additional TAB into
the mix; but nevermind, my muscle memory will get used to it.  :-)

>> but also because this might clutter dialog boxes and cause troubles:
>> what if the translation of “Hide” is takes up more space? is it still
>> going to fit?
>
> Hard to say :p, the checkbox is added to widget grids which should adapt
> to terminal size. So unless the translation is really long and the
> screen really small, I hope it fits!

Isn’t the grid constrained by the side of the outer box?  Perhaps we
should enlarge that outer box a bit?

Anyway, I think you can push, it’s already a great improvement IMO.

Thanks,
Ludo’.

bug#35601: First 'guix pull' does not display 'hash guix' hint

[Diego Nicola Barbato]

Hi Guix,

Congratulations on 1.0.0!

I took the opportunity to revisit bug #33647 [0] and verify that commits
3bbd691 and d1d7283 have the desired effect.  Unfortunately they do
not: The first time a user runs guix pull on a freshly installed Guix
System no hint about running 'hash guix' is displayed even though it is
precisely when the hint was supposed to be displayed.

To reproduce simply run (after installing Guix System using the 1.0.0
installer) 'guix --version', which will yield 'guix (GNU Guix) 1.0.0',
then 'guix pull', which will display no hint about running 'hash guix',
then 'guix --version' again, which will return 'guix (GNU Guix) 1.0.0'
again, and finally 'hash guix' followed by 'guix --version', which now
will yield 'guix (GNU Guix) 1234somecommithash123456789abcdefghijklm'.

Regardless of the hint I still believe it is unfortunate that running
'guix pull && guix system reconfigure /etc/config.scm' for the first
time will rather counterintuitively downgrade the system instead of
upgrading it.

Regards,

Diego

[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33647

bug#35540: Installer displays encrypted partition password entry in cleartext

[Mathieu Othacehe]

Hey Ludo,

> I would perhaps add that checkbox only for the passphrase, in part
> because when I test an install I prefer to have fewer keystrokes :-),

The parameter is disabled by default and enabled only for disk
encryption and root/user passwords so I'm not sure I get what you mean.

> but also because this might clutter dialog boxes and cause troubles:
> what if the translation of “Hide” is takes up more space? is it still
> going to fit?

Hard to say :p, the checkbox is added to widget grids which should adapt
to terminal size. So unless the translation is really long and the
screen really small, I hope it fits!

Mathieu

bug#35590: Emacs info can't open info manuals

[sirgazil]

 On Sun, 05 May 2019 21:26:15 -0500 Mark H Weaver  wrote 


 > Hi, 
 >  
 > sirgazil  writes: 
 >  
 > > I can't open info manuals in an Emacs freshly installed in my GNU 
 > > system installed in a real machine using the ISO installer 
 > > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
 > >  
 > > 
 > > ## Steps to reproduce 
 > > 
 > > 1. guix install emacs 
 > > 2. Start Emacs. 
 > > 3. M-x info Enter. 
 > > 4. m Guix Enter (or any other manual). 
 > > 
 > > 
 > > ## Unexpected result 
 > > 
 > > The manual is not displayed, and the minibuffer says: 
 > > 
 > > Uncompression program 'sh' not found 
 >  
 > This is surprising.  On a Guix system, sh is unconditionally installed 
 > in /bin/sh.  If you type M-x getenv PATH RET in Emacs, does the 
 > displayed string include /bin?  Does M-! sh RET show an error? 


M-x getenv PATH RET shows "bin"s in other paths, but not "/bin":

/gnu/store/hk4f641r18vpj44m42pny6rp1nwg3d4w-glib-2.56.3-bin/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/setuid-programs:/home/sirgazil/.config/guix/current/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin

"/bin/sh" exists in the system, though:

$ ls -l /bin
total 4
lrwxrwxrwx 1 root root 62 may  6 06:19 sh -> 
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/sh

M-! sh RET results in "command not found":

/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash: sh: no se 
encontró la orden

bug#35594: GNOME: Application icons are not displayed immediately after installation

[sirgazil]

 On Sun, 05 May 2019 21:21:59 -0500 Mark H Weaver  wrote 


 > Hi, 
 >  
 > sirgazil  writes: 
 >  
 > > I installed the GNU system in a real machine using Guix 1.0 ISO 
 > > installer 
 > > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
 > >  
 > > 
 > > Whenever I install a desktop application, the application icon does 
 > > not show up immediately in the list of available applications. I have 
 > > to log out and log in again to be able to see it. 
 >  
 > Indeed, this has always been the case on Guix, and I agree it would be 
 > good to fix it.  FWIW, another way to refresh the list of available 
 > applications from GNOME Shell is to type: Alt-F2, and then enter the 
 > single letter "r" as the command.  That should restart GNOME Shell 
 > without affecting your other applications.  (Unfortunately for me, this 
 > only works under Xorg, not Wayland.) 
 >  
 > A related issue is that if you upgrade a program in Guix, and then 
 > launch it using GNOME Shell, it will launch the old one.  That's because 
 > our installed desktop files are specifically rewritten to launch the 
 > program via an absolute path name /gnu/store/x/bin/* instead of 
 > simply looking in PATH, and GNOME Shell continues to use the old desktop 
 > files until it's restarted.  This was implemented back in 2016, here: 
 >  
 >  
 > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d31860b9de07810e114490db5cc160a8b078c58d
 >  
 >  
 > I remember thinking it was a bad idea at the time, but I didn't have 
 > enough energy to speak up about it. 


I see... Thanks for the information, Mark.

bug#35540: Installer displays encrypted partition password entry in cleartext

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

>> #2 would please everybody, but I do not know what widgets Newt
>> provides for this.  Mathieu, would you know if changing the
>> visibility with e.g. a checkbox is doable?
>
> You'll find a patch attached that adds a checkbox to toggle password
> hiding. Every password input now has such a checkbox, WDYT?

It looks great!

I would perhaps add that checkbox only for the passphrase, in part
because when I test an install I prefer to have fewer keystrokes :-),
but also because this might clutter dialog boxes and cause troubles:
what if the translation of “Hide” is takes up more space? is it still
going to fit?

WDYT?

Thank you!

Ludo’.

bug#35599: No sound most of the time (dummy output)

[sirgazil]

Hi,

I installed the GNU system in a real machine using the Guix 1.0 ISO installer 
(https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).

When I play video or audio in the browser or in the desktop, I get no audio. 
The volume controls in the browser and desktop show the sound is not disabled. 
There are no errors about missing codecs or anything like that. The media 
plays, but there is no audio coming out from the speakers (which are on). Audio 
and speakers worked fine in the distro I was using before installing GNU with 
Guix. I posted this issue to help-guix 
(https://lists.gnu.org/archive/html/help-guix/2019-05/msg00107.html). This is 
what I've tried so far:

When I go to GNOME Settings → Sound, I get this:

https://multimedialib.files.wordpress.com/2019/05/dummy-output-gnu-guix-1.0.png

The name of the only device listed there corresponds to "Dummy output" in 
English. So, for some reason, the system is not detecting the real sound device.

Running:

guix environment --ad-hoc alsa-utils
alsamixer

displays this: 

https://multimedialib.files.wordpress.com/2019/05/alsamixer-guix-system-1.0.png

When I press F6 in alsamixer I see "(default)" selected, and there are no other 
options, except for an "enter device name..." option.

I get this behavior almost every time I start the machine. Only once, I started 
the machine and the speakers worked. The real sound device was displayed in 
"GNOME Settings → Sound", and GNOME would display information when I plugged 
some headphones.

However, I don't know why it worked that time. I thought it had worked because 
that day I didn't plugged the headphones before booting, but trying to 
reproduce the behavior, I went back to the beginning: No sound. No matter 
whether I restart with headphones unplugged, I haven't been able to get the 
sound device to be recognized again.


---
https://sirgazil.bitbucket.io/

bug#35583: Setting a GRUB keyboard-layout breaks GRUB… and Linux‽

[Ludovic Courtès]

Hi Tobias,

Tobias Geerinckx-Rice  skribis:

> However, today I tried to (re-)add it to GRUB, too, and ended up
> writing the following comment:
>
> (bootloader
>  (bootloader-configuration
>   (bootloader grub-efi-bootloader)
>   ;; XXX Strange bug: GRUB can read the LUKS passphrase, but
> afterwards (at
>   ;; the menu screen) no longer responds to key presses.  Even
> stranger: it
>   ;; makes my X230T's backspace key send ‘XF86ScreenSaver’s even on
> Linux.
>   ;; (keyboard-layout keyboard-layout)
>   (target "/boot/efi")
>   (timeout 1
>
> This is 100% reproducible.

Even in ‘guix system vm --full-boot’, right?

It could be that the XKB → GRUB conversion fails.  You can see
conversion process in (gnu bootloader grub).  In that case, that would
be a ‘grub-mklayout’ or a ‘ckbcomp’ bug.

I’ve only tested this stuff with standard keyboard layouts with one or
two options at most, so it may be that you’re pushing it to its limits.

I’m surprised what GRUB does has an impact on what Linux does
afterwards, though.

Thanks,
Ludo’.

bug#35588: [PATCH] ui: Search matches additional package outputs.

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

> Tobias Geerinckx-Rice  writes:
>
>> Here's a patch to match package outputs (except ‘out’, since it can't affect 
>> the relative score) in ‘guix search’.
>
> Wow, thank you for the quick patch!  Indeed, it works as advertised.
>
> That said, I see that your patch only omits the "out" output, and it
> also changes the way the regular expression matching works for all
> fields.

Yeah, how does this regexp/newline related to matching outputs, Tobias?

> What do you think of this solution?  I think it's a little more drastic,
> but it feels cleaner to me.  If I'm bike shedding, feel free to call me
> out on that!  ;-)

FWIW I find it a bit too drastic.  :-)  It leads to much verbosity and
I’m not sure this is warranted.

>  (define %package-metrics
>;; Metrics used to compute the "relevance score" of a package against a set
>;; of regexps.
> -  `((,package-name . 4)
> -
> +  `((,(lambda (package)
> +(list (package-name package)))
> + . 4)
> +;; Match against uncommon outputs.
> +(,(lambda (package)
> +(filter (lambda (output)
> +  (not (member output
> +   ;; Some common outpus shared by many packages.
> +   '("out" "debug" "doc" "static"
> +(package-outputs package)))
> + . 1)

Could we have just this hunk or is there something I’m missing that
would make it insufficient?

Thank you,
Ludo’.

bug#35586: GNOME

[pelzflorian (Florian Pelz)]

On Mon, May 06, 2019 at 03:57:48AM -0400, Raghav Gururajan wrote:
> Also, I think it should be okay to include apps mentioned in "incubator" 
> section as well. In Guix, users can roll back to older versions of newer ones 
> are unstable.
> 

Well, incubator apps have not enough polish.  Then again, what back in
2016 was an incubator app maybe works fine now — I see the blog
linking to https://wiki.gnome.org/Design/Apps which lists Notes as
core now.  Dictionary is listed as inactive/retired on the other hand.

Regards,
Florian

bug#35588: [PATCH] ui: Search matches additional package outputs.

[Chris Marusich]

Hi Tobias!

Tobias Geerinckx-Rice  writes:

> Here's a patch to match package outputs (except ‘out’, since it can't affect 
> the relative score) in ‘guix search’.

Wow, thank you for the quick patch!  Indeed, it works as advertised.

That said, I see that your patch only omits the "out" output, and it
also changes the way the regular expression matching works for all
fields.  Previously, a regex like "foo$" would have matched against
"foo" at the end of a package's description string, but now it matches
"foo" right before any newline in the description.  In practice, it
seems we have many newlines in the descriptions, since people wrap the
lines in the source code with non-escaped newlines.  I doubt anyone is
relying on the use of $ or ^ to match at the start of end of the
description, so this probably isn't a big deal, but it made me wonder
how else we might be able to accomplish the same task without changing
the way the regexes already work.

I've attached a patch that attempts to do that.  Basically, this patch
is like yours in spirit, but it excludes a few more "common" outputs,
and it splits the outputs into a list, rather than separating them by
newlines in a single string.  The downside is that I had to update all
the other "metrics" procedures so they would always return a list.  I
kind of feel like returning the same type of object is an upside, not a
downside, but I guess the pattern of returning #f for special cases is
pretty common in Guile, so maybe my change isn't very idiomatic.

What do you think of this solution?  I think it's a little more drastic,
but it feels cleaner to me.  If I'm bike shedding, feel free to call me
out on that!  ;-)

-- 
Chris
From 91d06d8950e700a8a3c3479c3613b579c53411c9 Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Mon, 6 May 2019 01:51:30 -0700
Subject: [PATCH] ui: Make package outputs searchable.

* guix/ui.scm (relevance): Expect the "field" procedure to always return
a (possibly empty) list of strings, thereby eliminating the case in
which (before this commit) "field" might return #f.  Add up the score of
each string in the list, and use that as the overall score when folding
over the metrics.  Update docstring.
(%package-metrics): Return a list in every case.
* guix/scripts/system/search.scm (process-query)
<%service-type-metrics>: Return a list in every case.
* guix/scripts/package.scm (find-packages-by-description): Update
docstring.
---
 guix/scripts/package.scm   |  6 ++---
 guix/scripts/system/search.scm | 17 +++
 guix/ui.scm| 40 --
 3 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index aa27984ea2..06e4cf5b9c 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -180,9 +180,9 @@ hooks\" run when building the profile."
 ;;;
 
 (define (find-packages-by-description regexps)
-  "Return two values: the list of packages whose name, synopsis, or
-description matches at least one of REGEXPS sorted by relevance, and the list
-of relevance scores."
+  "Return two values: the list of packages whose name, synopsis, description,
+or output matches at least one of REGEXPS sorted by relevance, and the list of
+relevance scores."
   (let ((matches (fold-packages (lambda (package result)
   (if (package-superseded package)
   result
diff --git a/guix/scripts/system/search.scm b/guix/scripts/system/search.scm
index 955cdd1e95..733fa22614 100644
--- a/guix/scripts/system/search.scm
+++ b/guix/scripts/system/search.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017, 2018 Ludovic Courtès 
 ;;; Copyright © 2018 Clément Lassieur 
+;;; Copyright © 2019 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -128,14 +129,22 @@ columns."
 
 (define %service-type-metrics
   ;; Metrics used to estimate the relevance of a search result.
-  `((,service-type-name* . 3)
-(,service-type-description-string . 2)
+  `((,(lambda (type)
+(match (service-type-name* type)
+  (#f '())
+  (name (list name
+ . 3)
+(,(lambda (type)
+(match (service-type-description-string type)
+  (#f '())
+  (description (list description
+ . 2)
 (,(lambda (type)
 (match (and=> (service-type-location type) location-file)
   ((? string? file)
-   (basename file ".scm"))
+   (list (basename file ".scm")))
   (#f
-   "")))
+   '(
  . 1)))
 
 (define (find-service-types regexps)
diff --git a/guix/ui.scm b/guix/ui.scm
index 92c845e944..9121e3daee 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -11,6 +11,7 @@
 ;;; Copyright © 2016 Benz Schenk 
 ;;; Copyright © 2018 Kyle Meyer 
 ;;; Copyright © 2018 Ricardo Wurmus 
+;;; Copyright © 2019 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ 

bug#35586: GNOME

[pelzflorian (Florian Pelz)]

On Mon, May 06, 2019 at 03:51:54AM -0400, Raghav Gururajan wrote:
> On 5 May 2019 16:48, "pelzflorian (Florian Pelz)" 
>  wrote:
> > You can also type both Epiphany and (your language’s translation of) 
> > Web in the GNOME Activities search bar to find Epiphany.  The same 
> > goes for Nautilus.  The terminal command is also still epiphany or 
> > nautilus. 
> >
> > I do not know if it is possible to give a package two names; I believe 
> > it is not. 
> 
> I understand what you are saying. It appears epiphany is the old name 
> (https://en.m.wikipedia.org/wiki/GNOME_Web). Dev must have used epiphany now 
> a days as a habit.
> 
> Also, the previous blog link you sent me, recommends to use generic names.
>

Maybe gnome-web could be the real package’s name and there could be a
package called epiphany that propagates gnome-web, like the gnome
meta-package does?  Same for nautilus etc.

Regards,
Florian

bug#35529: libdrm fails to build on armhf-linux

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus  writes:

>> Ricardo Wurmus  writes:
>>
>>> Mark H Weaver  writes:
>>>
 Hydra failed two consecutive attempts to build libdrm on armhf-linux:

   https://hydra.gnu.org/build/3481547#tabs-summary

 Both build attempts were made on hydra-slave2, which is a Wandboard Quad
 based on the Freescale i.MX6 SOC.
>>>
>>> This has built fine on berlin.  We have a completed build for
>>> /gnu/store/3c28p8b07709isd9jlcnnnyrpgz4ndz8-libdrm-2.4.97.
>>
>> What kind of hardware was it built on?
>
> I’m not sure.  We’re using a few Overdrive 1000 machines that have quite
> a bit more RAM than the other armhf nodes.

Are there any other kinds of build slaves that build armhf binaries for
Berlin?

>> Note that the failure on Hydra was due to a timeout in the test suite:
>>
>>   https://hydra.gnu.org/build/3481547/nixlog/6/tail-reload
>>
>> All of the other tests completed within a few seconds, but the timeout
>> tripped after 1200 seconds.  So, I'm not sure if it's simply that the
>> build hardware is too slow.  It might have actually gotten stuck.
>> Perhaps the test uses /dev/random (as opposed to /dev/urandom) and
>> there's not enough entropy available on the build machine.
>
> My guess is that it ran out of RAM and began trashing.  We’ve had at
> least another build (nss) that worked fine on the Overdrive but failed
> on other armhf machines.

All of the armhf build slaves on hydra.gnu.org have 4 gigabytes of RAM.
So does redhill, the armhf slave hosted by Andreas.

My Thinkpad X200 only has 4 gigabytes, and that's enough to build my
entire GNOME system from source code, including webkitgtk, icecat, rust,
nss, etc.

FWIW, I'd be very surprised if these libdrm test failures are due to
running out of memory.

   Mark

bug#35586: GNOME

[Raghav Gururajan]

On 5 May 2019 16:50, "pelzflorian (Florian Pelz)"  
wrote:
>
> On Sun, May 05, 2019 at 03:36:51PM -0400, Raghav Gururajan wrote: 
> > Florian! The link you provided is awesome. 
> > 
> > I strongly request the devs to use that link 
> > (https://blogs.gnome.org/mcatanzaro/2016/09/21/gnome-3-22-core-apps/) to 
> > fix this bug. 
>
> There actually also is: 
> https://blogs.gnome.org/mcatanzaro/2017/08/13/gnome-3-26-core-applications/ 
>
> This is less detailed than the link before, but it is more recent.  I 
> do not remember reading a more recent post on GNOME core applications 
> on Planet GNOME, but I may have forgotten. 

Thanks Florian!

I see. 

Also, I think it should be okay to include apps mentioned in "incubator" 
section as well. In Guix, users can roll back to older versions of newer ones 
are unstable.

>
> Regards, 
> Florian 

bug#35586: GNOME

[Raghav Gururajan]

On 5 May 2019 16:48, "pelzflorian (Florian Pelz)"  
wrote:
>
> On Sun, May 05, 2019 at 03:23:27PM -0400, Raghav Gururajan wrote: 
> > On 5 May 2019 14:52, "pelzflorian (Florian Pelz)" 
> >  wrote: 
> > > Well, they have two names and others frequently refer to them by 
> > > e.g. Epiphany and not GNOME Web, including Epiphany developers. 
> > > 
> > > 
> > 
> > Hmm, but the app shows up as Web in GNOME. 
> > 
>

> One example of GNOME Web being called Epiphany by GNOME developers is 
> the same blog: 
>
> https://blogs.gnome.org/mcatanzaro/2019/03/19/epiphany-technology-preview-upgrade-requires-manual-intervention/
>  
>
> You can also type both Epiphany and (your language’s translation of) 
> Web in the GNOME Activities search bar to find Epiphany.  The same 
> goes for Nautilus.  The terminal command is also still epiphany or 
> nautilus. 
>
> I do not know if it is possible to give a package two names; I believe 
> it is not. 

I understand what you are saying. It appears epiphany is the old name 
(https://en.m.wikipedia.org/wiki/GNOME_Web). Dev must have used epiphany now a 
days as a habit.

Also, the previous blog link you sent me, recommends to use generic names.

>
>
>
> > > Of course, there are more non-packaged applications. 
> > > 
> > > I also remember 
> > > https://blogs.gnome.org/mcatanzaro/2016/09/21/gnome-3-22-core-apps/ 
> > > who says, for example, that gnome-tweaks is *not* core. 
> > > 
> > 
> > What?? How else to enable/disable plugins/extensions in GNOME? 
> > 
>
> Well…  GNOME has repeatedly tried to make simpler alternatives for 
> installing extensions.  I believe the current method is GNOME 
> Software, but I am not sure. 
>
> Regards, 
> Florian 

bug#35529: libdrm fails to build on armhf-linux

[Ricardo Wurmus]

Hi Mark,

> Ricardo Wurmus  writes:
>
>> Mark H Weaver  writes:
>>
>>> Hydra failed two consecutive attempts to build libdrm on armhf-linux:
>>>
>>>   https://hydra.gnu.org/build/3481547#tabs-summary
>>>
>>> Both build attempts were made on hydra-slave2, which is a Wandboard Quad
>>> based on the Freescale i.MX6 SOC.
>>
>> This has built fine on berlin.  We have a completed build for
>> /gnu/store/3c28p8b07709isd9jlcnnnyrpgz4ndz8-libdrm-2.4.97.
>
> What kind of hardware was it built on?

I’m not sure.  We’re using a few Overdrive 1000 machines that have quite
a bit more RAM than the other armhf nodes.

> Note that the failure on Hydra was due to a timeout in the test suite:
>
>   https://hydra.gnu.org/build/3481547/nixlog/6/tail-reload
>
> All of the other tests completed within a few seconds, but the timeout
> tripped after 1200 seconds.  So, I'm not sure if it's simply that the
> build hardware is too slow.  It might have actually gotten stuck.
> Perhaps the test uses /dev/random (as opposed to /dev/urandom) and
> there's not enough entropy available on the build machine.

My guess is that it ran out of RAM and began trashing.  We’ve had at
least another build (nss) that worked fine on the Overdrive but failed
on other armhf machines.

-- 
Ricardo