bug#40682: frozen installer in WiFi section -guix 1.1.0

[Ludovic Courtès]

Hi,

SergioBG BG  skribis:

> Here the screenshot of Frozen.

Thanks.  Looking at the screenshot, it would seem that the installer is
stuck somewhere in ‘connman-connect-with-auth’, but it’s hard to tell
why/where.

I was able to reproduce it in ‘guix system vm’ with the patch below.

Cc: Mathieu in case they have an idea…

To be continued…

Thanks,
Ludo’.

PS: Nyacc contains libdbus bindings as an example of its FFI tooling,
perhaps we should give it a try and use it here.  It could be more
robust than piping through ‘connmanctl’.

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 0965c4d237..826f6d356d 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -322,6 +322,52 @@ the user's target storage device rather than on the RAM disk."
 "Load the @code{uvesafb} kernel module with the right options.")
(default-value #t)))
 
+(define (simulated-wifi-shepherd-services hostapd)
+  (define config
+(plain-file "hostapd.conf" "\
+interface=wlan1
+ssid=Test Net
+channel=1\n"))
+
+  (list (shepherd-service
+ (provision '(hostapd))
+ (requirement '(mac-sim-module unblocked-wifi))
+ (start #~(make-forkexec-constructor
+   (list #$(file-append hostapd "/sbin/hostapd")
+ #$config)
+   #:log-file "/var/log/hostapd.log"))
+ (stop #~(make-kill-destructor)))
+(shepherd-service
+ (provision '(unblocked-wifi))
+ (requirement '(mac-sim-module))
+ (start #~(lambda _
+(invoke #$(file-append util-linux "/sbin/rfkill")
+"unblock" "0")
+(invoke #$(file-append util-linux "/sbin/rfkill")
+"unblock" "1")))
+ (one-shot? #t))
+(shepherd-service
+ (provision '(mac-sim-module))
+ (requirement '(term-tty3))
+ (modules '((guix build utils)))
+ (start #~(lambda _
+;; XXX: We can't use 'load-linux-module*' here because it
+;; expects a flat module directory.
+(setenv "LINUX_MODULE_DIRECTORY"
+"/run/booted-system/kernel/lib/modules")
+(invoke #$(file-append kmod "/bin/modprobe")
+"mac80211_hwsim")))
+ (one-shot? #t
+
+(define simulated-wifi-service-type
+  (service-type
+   (name 'simulated-wifi)
+   (extensions
+(list (service-extension shepherd-root-service-type
+ simulated-wifi-shepherd-services)))
+   (default-value hostapd)
+   (description "Run hostapd to simulate WiFi connectivity.")))
+
 (define %installation-services
   ;; List of services of the installation system.
   (let ((motd (plain-file "motd" "
@@ -366,6 +412,8 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
   ;; The usual services.
   (syslog-service)
 
+  (service simulated-wifi-service-type)
+
   ;; The build daemon.  Register the default substitute server key(s)
   ;; as trusted to allow the installation process to use substitutes by
   ;; default.

bug#40534: Installer: List of languages should be focused on translated ones

[Björn Höfling]

On Fri, 10 Apr 2020 15:46:44 +0200
"pelzflorian (Florian Pelz)"  wrote:

> On Fri, Apr 10, 2020 at 01:34:40PM +0200, Björn Höfling wrote:
> > When starting the Guix installer, the first question is to choose a
> > language.
> > 
> > You are confronted with a very long list of all sorts of languages.
> > When you then choose one of the untranslated ones, you just get
> > back to English.
> > 
> > Wouldn't it be better to just show those where really (some)
> > translations are available?  
> 
> The chosen language should affect the locale in the generated
> config.scm, does it not?  If the locale in config.scm is correct, then
> even if Guix has no translation at least the installed system will
> have translations e.g. for GNOME and I believe this issue can be
> closed.  Just the installer messages remain untranslated English for
> now.

You are right, that's a good argument at the end of installation.

Closing this one, and waiting for Guix-world-domination with full
translations in all available languages :-)

Björn


pgpLwiYcBev_V.pgp
Description: OpenPGP digital signature

bug#40650: ‘scandir*’ test failure

[Vagrant Cascadian]

On 2020-04-18, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> test-name: scandir*, properties
>> location: /build/guix-YPdZIs/guix-1.1.0/tests/syscalls.scm:257
>> source:
...
> Looking at this test, the only way ‘every’ could return #f is (1) if
> ‘lstat’ returns a different inode number, or (2) if ‘lstat’ returns a
> different file type than the one for ‘scandir*’.

My debian package builds are done using a overlay fs(with tmpfs on top,
and ext4 below), which might explain inode discrepancies... this sort of
thing is not uncommon in Debian package building environments.

If that's indeed triggering the issue, maybe it needs some sort of
workaround or a way to detect if it should skip the test?


> Unfortunately it’s hard to tell more without debugging interactively on
> the machine, adding ‘pk’ calls here and there to see.
>
> Can you reproduce this test failure in a simpler environment when
> interactive debugging is possible?

Yeah, I could build in a one-off chroot or virtual machine using a
"normal" filesystem.


live well,
  vagrant


signature.asc
Description: PGP signature

bug#40650: guix test suite failures building Debian package

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> test-name: store-profile
> location: /build/guix-YPdZIs/guix-1.1.0/tests/size.scm:36
> source:

[...]

> +   (bash (interned-file
> +   (search-bootstrap-binary
> + "bash"
> + (%current-system))
> +   "bash"
> +   #:recursive?

[...]

> actual-value: #f
> actual-error:
> + (match-error "match" "no matching pattern" #f)
> result: FAIL

Same story here: if you provide a ‘bash’ other than Guix’ bash, this
test is bound to fail.

Thanks,
Ludo’.

bug#40650: guix test suite failures building Debian package

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> test-name: gexp->derivation #:references-graphs
> location: /build/guix-YPdZIs/guix-1.1.0/tests/gexp.scm:944

[...]

> actual-value: #f
> result: FAIL

This failure is because of this assumption in the test:

 ;; Note: %BOOTSTRAP-GUILE depends on the bootstrap Bash.
 (lset= string=?
(call-with-input-file g-guile read)
(list (derivation->output-path guile-drv) bash))

This assumption does not hold if you use a ‘bash’ binary different from
the one Guix provides; I had overlooked this.

You can either solve this by pre-downloading Guix’ statically-linked
{bash,mkdir,xz,tar} as discussed earlier, or simply by skipping this
test by adding (test-skip 1) above it (it’s not unreasonable IMO).

Ludo’.

bug#40650: ‘scandir*’ test failure

[Ludovic Courtès]

Hey,

Vagrant Cascadian  skribis:

> test-name: scandir*, properties
> location: /build/guix-YPdZIs/guix-1.1.0/tests/syscalls.scm:257
> source:
> + (test-assert
> +   "scandir*, properties"
> +   (let ((directory
> +   (dirname
> + (search-path %load-path "guix/base32.scm"
> + (every (lambda (entry name)
> +  (match entry
> + ((name2 . properties)
> +  (and (string=? name2 name)
> +   (let* ((full (string-append directory "/" name))
> +  (stat (lstat full))
> +  (inode (assoc-ref properties 'inode))
> +  (type (assoc-ref properties 'type)))
> + (and (= inode (stat:ino stat))
> +  (or (eq? type 'unknown)
> +  (eq? type (stat:type stat)
> +(pk (scandir* directory))
> +(pk (scandir directory (const #t) string
> ;;; ((("." (type . directory) (inode . 656899)) (".." (type . directory) 
> (inode . 655381)) ("base16.go" (type . regular) (inode . 673193)) 
> ("base16.scm" (type . regular) (inode . 656947)) ("base32.go" (type . 
> regular) (inode . 674231)) ("base32.scm" (type . regular) (inode . 656911)) 
> ("base64.go" (type . regular) (inode . 675116)) ("base64.scm" (type . 
> regular) (inode . 657151)) ("build" (type . directory) (inode . 657319)) 
> ("build-system" (type . directory) (inode . 657157)) ("build-system.go" (type 
> . regular) (inode . 673229)) ("build-system.scm" (type . regular) (inode . 
> 656914)) ("bzr-download.go" (type . regular) (inode . 674252)) 
> ("bzr-download.scm" (type . regular) (inode . 656932)) ("cache.go" (type . 
> regular) (inode . 673222)) ("cache.scm" (type . regular) (inode . 657532)) 
> ("channels.go" (type . regular) (inode . 675153)) ("channels.scm" (type . 
> regular) (inode . 657499)) ("ci.go" (type . regular) (inode . 674235)) 
> ("ci.scm" (type . regular) (inode . 657298)) ("colors.go" (type . regular) 
> (inode . 673271)) ("colors.scm" (type . regular) (inode . 656965)) 
> ("combinators.go" (type . regular) (inode . 675122)) ("combinators.scm" (type 
> . regular) (inode . 656926)) ("config.go" (type . regular) (inode . 676566)) 
> ("config.scm" (type . regular) (inode . 675006)) ("config.scm.in" (type . 
> regular) (inode . 657505)) ("cpio.go" (type . regular) (inode . 675880)) 
> ("cpio.scm" (type . regular) (inode . 656935)) ("cve.go" (type . regular) 
> (inode . 675915)) ("cve.scm" (type . regular) (inode . 657295)) 
> ("cvs-download.go" (type . regular) (inode . 674303)) ("cvs-download.scm" 
> (type . regular) (inode . 657265)) ("deprecation.go" (type . regular) (inode 
> . 674238)) ("deprecation.scm" (type . regular) (inode . 656962)) 
> ("derivations.go" (type . regular) (inode . 675143)) ("derivations.scm" (type 
> . regular) (inode . 657544)) ("describe.go" (type . regular) (inode . 
> 675149)) ("describe.scm" (type . regular) (inode . 656908)) ("diagnostics.go" 
> (type . regular) (inode . 675214)) ("diagnostics.scm" (type . regular) (inode 
> . 656902)) ("discovery.go" (type . regular) (inode . 675897)) 
> ("discovery.scm" (type . regular) (inode . 656971)) ("docker.go" (type . 
> regular) (inode . 673196)) ("docker.scm" (type . regular) (inode . 656968)) 
> ("download.go" (type . regular) (inode . 675127)) ("download.scm" (type . 
> regular) (inode . 657310)) ("elf.go" (type . regular) (inode . 673265)) 
> ("elf.scm" (type . regular) (inode . 657301)) ("ftp-client.go" (type . 
> regular) (inode . 674297)) ("ftp-client.scm" (type . regular) (inode . 
> 657538)) ("gexp.go" (type . regular) (inode . 673203)) ("gexp.scm" (type . 
> regular) (inode . 656941)) ("git-download.go" (type . regular) (inode . 
> 674255)) ("git-download.scm" (type . regular) (inode . 657316)) ("git.go" 
> (type . regular) (inode . 673219)) ("git.scm" (type . regular) (inode . 
> 656905)) ("glob.go" (type . regular) (inode . 673216)) ("glob.scm" (type . 
> regular) (inode . 656929)) ("gnu-maintenance.go" (type . regular) (inode . 
> 673210)) ("gnu-maintenance.scm" (type . regular) (inode . 657517)) 
> ("gnupg.go" (type . regular) (inode . 675940)) ("gnupg.scm" (type . regular) 
> (inode . 657292)) ("grafts.go" (type . regular) (inode . 674258)) 
> ("grafts.scm" (type . regular) (inode . 657520)) ("graph.go" (type . regular) 
> (inode . 675175)) ("graph.scm" (type . regular) (inode . 656917)) 
> ("hg-download.go" (type . regular) (inode . 675900)) ("hg-download.scm" (type 
> . regular) (inode . 657508)) ("http-client.go" (type . regular) (inode . 
> 674300)) ("http-client.scm" (type . regular) (inode . 657526)) ("i18n.go" 
> (type . regular) (inode . 675211)) ("i18n.scm" (type . regular) (inode . 
> 657268)) ("import" (type . directory) (inode . 657574)) ("inferior.go" (type 
> . regular) (inode . 675146)) ("inferior.scm" (type . regular) (inode . 
> 657523)) 

bug#40700: herd restart guix-publish crashes system

[Efraim Flashner]

I saw that the guix-publish service on my Guix System desktop wasn't running
correctly so I went to restart it. I ran 'herd restart guix-publish' and
my machine instantly started to shut down.


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


signature.asc
Description: PGP signature

bug#39843: Can't open files through file managers in other DEs and WMs

[sirgazil via Bug reports for GNU Guix]

After removing the workaround from my system configuration file and 
reconfiguring the system with a recent Guix (see below), things work find in 
MATE, Xfce and sway. I can't reproduce the problems anymore.

$ guix describe
Generation 72   Apr 17 2020 08:12:14(current)
  sirgazil-x 66d4b67
repository URL: https://gitlab.com/sirgazil/guix-channel-x.git
branch: master
commit: 66d4b677875c84d0b7a946376cd4885f202094eb
  guix 79ef072
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 79ef0726a9afb7bd4676b9a53401f742c7b83653


Thanks for fixing this.

bug#40590:

[pelzflorian (Florian Pelz)]

On Sat, Apr 18, 2020 at 01:47:11PM -0400, Keyhenge wrote:
> The amd option didn't work, but nomodeset allowed me to get to a shell,
> at which point I could start experimenting with various settings to see
> if I could get a graphical environment. I finally did by switching over
> to the proprietary kernel (which points to a graphical driver issue with
> AMD Navi cards in the libre kernel), but that's obviously less than ideal.
> 

If you have no problems sacrificing all the acceleration by your AMD
GPU, you can try using libre uvesafb for Xorg graphics.  What I wrote
at 
was not necessary there but maybe is in your case.  That said, this
situation is far from ideal, but I don’t think the AMD firmware will
be freed (if there is no other way).

Regards,
Florian

bug#40590:

[Keyhenge]

Sorry for the late reply on this.

Could you try adding the following kernel parameters (via Grub 
by
pressing 'e', then appending the option at the end of the 
cmdline):


* nomodeset

and if it doesn't work:

* amd_iommu=pt ivrs_ioapic[32]=00:14.0 iommu=soft


The amd option didn't work, but nomodeset allowed me to get to a 
shell,
at which point I could start experimenting with various settings 
to see
if I could get a graphical environment. I finally did by switching 
over
to the proprietary kernel (which points to a graphical driver 
issue with
AMD Navi cards in the libre kernel), but that's obviously less 
than ideal.


Still, it means I can finally start using the system in 
earnest. Thanks

for all your help!

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Glad you manage to get more info.
>>
>> Christopher Baines  skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc@7
>>> rather than libgc@8 (which is what's used above), and I can't reproduce
>>> the issue. So, I'm getting more certain that this is a regression which
>>> the libgc upgrade has led to.
>>
>> Bah.  :-/
>>
>> We noticed similar issues with libgc@8 earlier but it seemed to be
>> fixed:
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>>
>>> Would it be feasible to keep guile, or at least the guile Guix uses with
>>> libgc@7 for now?
>>
>> Yes, we can define a Guile variant in (gnu packages guile) and have
>> (guix self) refer to it.
>
> I've sent a patch which I think does this now [1]. Assuming I've done
> the right thing, is this something that can be merged in to core-updates
> Marius?
>
> 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684
>
> I've tested the patch by running:
>
>   ./pre-inst-env guile build-aux/compile-as-derivation.scm "$PWD"
>
> Then taking the Guix I get, and trying the script to reproduce the issue
> through the guix repl, and it seems to work.

I've merged the fix [1] in now, and it looks to have worked [2].

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684
2: 
https://guix-patches-data.cbaines.net/revision/cef392f3936922b7b0b74bd59be67e660c10db67

Thanks for your help in resolving this Ludo!


signature.asc
Description: PGP signature

bug#40612: guix build system --dry-run is broken

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> Yes, of course, I agree that it's not possible to present a build plan
> ahead of time when grafts are enabled.  That was the case before these
> changes, and it's the case today.
>
> The only part I don't understand is why you decided that "--dry-run"
> should no longer imply "--no-grafts".  Does it work better for other
> people?  For me, the "--dry-run" output has become utterly useless
> unless "--no-grafts" is included.

I explained the pros and cons of having ‘--dry-run’ no longer implying
‘--with-grafts’ here:

  https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00337.html

‘guix package --dry-run’ overall works well IME, except when a
dependency of a fixed-output derivation is missing, as explained above.

‘guix system’ doesn’t work so well as you note (though again, that
depends on what you’re building vs. what you have in store).

I think we must find the remaining places that lack “parallelism” and
address them, like I did for example in commit
2ad6eb0568ed69127aea987c009138e03b5b8954.  (It would help if that code
didn’t use the monadic interface this much because ‘lower-gexp’ already
does the right thing.)

> Anyway, it's not that important to me.  I can just fix it in my own
> private branch.  I filed this report because I thought it might benefit
> other users to have this fixed upstream.

It matters to every user so I think it’s worth fixing in our common code base.

Thanks,
Ludo’.

bug#40652: #36924 way solves the problem for me

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant  skribis:

> Ludovic Courtès  skribis:
>
>> ‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
>> exist, so apparently it’s run before the activation snippet of
>> ‘account-service-type’ (the ordering guarantee is not explicit.)
>>
>> Hmm I wonder what I’m missing then.  Would you like to try again?
>
> I tried again and I wasn't able to reproduce the problem.
> Maybe I did something weird with my config last time, but I can't
> remember what it could have been...

OK.

>> Now, I think we should generalize this chown thing and apply it to all
>> the user accounts.  ‘user-homes’ would chown recursively if needed or
>> use the newfangled shiftfs, like systemd-homed does¹.
>>
>> Thoughts?
>> Ludo’.
>>
>> ¹ https://systemd.io/HOME_DIRECTORY/
>
> A recursive chown for system accounts (with their home directory
> somewhere in '/var') sounds like a good idea.
>
> For user accounts (in '/home'), I guess it could be slightly annoying if
> a user wants to set a specific group id to some of their files and if it
> gets set back to the 'users' group at each system reconfiguration.
> However it's probably not a very common use case, and if we only change
> the files' uid, they could end up with an invalid gid anyway.

Right.  The recursive chown would only happen if the home directory
itself has the wrong UID though, so that would still let you fiddle with
ownership of the files within it.  Worth trying!

Thanks,
Ludo’.

bug#40672: shepherd fails to terminate processes after PID file timeout expiration

[Ludovic Courtès]

Ludovic Courtès  skribis:

> As discussed during , in
> Shepherd 0.7.0, if a process created with ‘fork+exec-command’ & co. with
> #:pid-file fails to start before #:pid-file-timeout has expired,
> shepherd marks it as failed but the process potentially just keeps
> running.

Fixed in Shepherd commit 37dd896ce48908e4e3c56101fa07405070a6ce03.

Ludo'.

bug#36862: Root-owned /var/cache/fontconfig sometimes exists, shouldn't.

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> Sometimes fonts break, and after a few frustrating, impotent runs of
> ‘fc-cache -rv’ you notice:
>
>  /var/cache/fontconfig: not cleaning unwritable cache directory
>
> Deleting this stale (root-owned) directory makes fonts fun
> again. Happens about once or twice a month here.

I believe Efraim fixed it with commit
405c0c947cfd59d7bfb81052545cd635970d2d0c.

Closing!

Ludo’.