bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.
Hi,
swedebu...@riseup.net writes:
> Dec 22 04:21:24 localhost NetworkManager[289]: [1545448884.2537]
> audit: op="connection-activate"
> uuid="c3d6b24a-d67c-48a9-8695-2e9dd83c1b07" name="Riseup VPN" pid=414
> uid=1000 result="fail" reason="The VPN service
> 'org.freedesktop.NetworkManager.openvpn' was not installed."
> Dec 22 04:22:19 localhost NetworkManager[289]: [1545448939.2045]
> device (wlp3s0): set-hw-addr: set MAC address to AE:C7:48:B4:FE:7E
> (scanning)
> Dec 22 04:22:19 localhost vmunix: [ 3281.066433] IPv6:
> ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> Dec 22 04:22:19 localhost NetworkManager[289]: [1545448939.2203]
> device (wlp3s0): supplicant interface state: inactive -> disabled
> Dec 22 04:22:19 localhost NetworkManager[289]: [1545448939.2557]
> device (wlp3s0): supplicant interface state: disabled -> inactive
>
> config attached were it is installed systemwide.
>
> my user manifest is also attached were it is also installed.
>
> sdb@antelope ~/src/guix$ guix --version
> guix (GNU Guix) 0.16.0-3.6ddc63e
>
> running from git.
I can confirm the bug; it makes the network-manager-openvpn useless at
what it's supposed to be helpful with ;-).
Given that it seems to be a DBus error, I tried to modify our
network-manager-service-type so that it would consider the VPN plugins
as well when extending the dbus-system-service:
1 file changed, 10 insertions(+), 7 deletions(-)
gnu/services/networking.scm | 17 ++---
modified gnu/services/networking.scm
@@ -919,25 +919,28 @@ and @command{wicd-curses} user interfaces."
(stop #~(make-kill-destructor
(define network-manager-service-type
- (let
- ((config->package
+ (let*
+ ((config->packages
(match-lambda
- (($ network-manager)
- (list network-manager)
+ (($ network-manager _ vpn-plugins)
+ `(,network-manager ,@vpn-plugins)
(service-type
(name 'network-manager)
(extensions
(list (service-extension shepherd-root-service-type
network-manager-shepherd-service)
-(service-extension dbus-root-service-type config->package)
-(service-extension polkit-service-type config->package)
+(service-extension dbus-root-service-type config->packages)
+(service-extension polkit-service-type
+ (compose
+list
+network-manager-configuration-network-manager))
(service-extension activation-service-type
(const %network-manager-activation))
(service-extension session-environment-service-type
network-manager-environment)
;; Add network-manager to the system profile.
-(service-extension profile-service-type config->package)))
+(service-extension profile-service-type config->packages)))
(default-value (network-manager-configuration))
(description
"Run @uref{https://wiki.gnome.org/Projects/NetworkManager,
Unfortunately that didn't work... I'll have to read on DBus to debug
this further. Any help would be appreciated :-)
Thanks,
Maxim
bug#33861: Problem building sources for guile-bash
Hello Björn, Björn Höfling skribis: > But I tried it with network connection shut down (don't know where we > do not have substitutes and was too lazy to configure firewall): Then > it tries git, fails. It then tries our substitute server and fails. But > that failure is again a stacktrace, and it doesn't try the SWH fallback. Could you paste the backtrace you got? Thanks for testing! Ludo’.
bug#33854: StumpWM build failing.
This seems to be fixed in Ludo's latest commit 804b9b18ac9188ffb6c6891cbb9241c6a80ed7c8 Sent from my Sprint Phone. -- Original message--From: brettg@posteo.netDate: Tue, Jan 8, 2019 2:15 AMTo: Alex Kost;Oleg Pykhalov;Cc: 33...@debbugs.gnu.org;Subject:bug#33854: StumpWM build failing. Just following up here, I returned from vacation and this is still failing. I will dig around after the jet lag settles, but does anybody have any information on this error? It seems to be related to sbcl. Sent from my Sprint Phone. -- Original message--From: Alex KostDate: Tue, Dec 25, 2018 7:50 PMTo: Oleg Pykhalov;Cc: 33...@debbugs.gnu.org;Subject:bug#33854: StumpWM build failing. Alex Kost (2018-12-24 18:01 +0300) wrote: > Oleg Pykhalov (2018-12-24 09:10 +0300) wrote: > >> Hi, >> >> Thank you for notice this. >> >> "bre...@posteo.net" writes: >> >>> Hi all, StumpWM is failing to build on my machine. Can anybody >>> replicate this? […] >> >> The build farm can https://ci.guix.info/build/721131 > > Actually it can't since the build status is "1" which means "failed". Oops, I'm sorry. Initially I thought that you meant "build farm can build it", but now I see you meant "build farm can reproduce the fail" :-) -- Alex
bug#33999: CP437: Invalid Argument on init
Hi, apparently the message is printed by fsck.fat and is harmless (although we should still fix it). Are you sure that the services fail because of it? > (file-systems (cons* > (file-system > (device (file-system-label "ESP")) > (mount-point "/boot/efi") > (type "fat") Try adding (check? #f) here for testing purposes. > ) pgpsiSqItLEpB.pgp Description: OpenPGP digital signature
bug#33608: bug#33882: Blender is not loading menu scripts
On Mon, Jan 07, 2019 at 09:18:50AM +0100, Thorsten Wilms wrote: > On 06/01/2019 19.19, Leo Famulari wrote: > > But, is Guix's Blender 2.79 package working for anyone? > > The GUI is blank here, too. Looking at the last file I edited with a > perfectly fine working, Guix-provided Blender, things where still alright > 9th of December. Though I'm not sure how regular my updates have been. I didn't bisect but I think the problem began after core-updates was merged into master around that time. signature.asc Description: PGP signature
bug#33239: 'guix offload' regularly hangs in 'channel-get-exit-status' call
Ludovic Courtès skribis: > Ludovic Courtès skribis: > >> l...@gnu.org (Ludovic Courtès) skribis: >> >>> The ‘guix offload’ processes on berlin regularly hang while calling >>> ‘channel-get-exit-status’: >>> >>> (gdb) bt >>> #0 0x7f299fb330f1 in __GI___poll (fds=0x1dd58c0, nfds=1, timeout=-1) >>> at ../sysdeps/unix/sysv/linux/poll.c:29 >>> #1 0x7f2994287577 in ssh_poll_ctx_dopoll () from >>> target:/gnu/store/wmpg67bn7i7pqc0p4xjp1npnqixk9znd-libssh-0.7.6/lib/libssh.so.4 >>> #2 0x7f29942884d9 in ssh_handle_packets () from >>> target:/gnu/store/wmpg67bn7i7pqc0p4xjp1npnqixk9znd-libssh-0.7.6/lib/libssh.so.4 >>> #3 0x7f29942885ad in ssh_handle_packets_termination () from >>> target:/gnu/store/wmpg67bn7i7pqc0p4xjp1npnqixk9znd-libssh-0.7.6/lib/libssh.so.4 >>> #4 0x7f2994275080 in ssh_channel_get_exit_status () from >>> target:/gnu/store/wmpg67bn7i7pqc0p4xjp1npnqixk9znd-libssh-0.7.6/lib/libssh.so.4 >>> #5 0x7f29946dd11a in guile_ssh_channel_get_exit_status () from >>> target:/gnu/store/i3nfl17wfx7sryq6w15r9wxl7ilmq4rb-guile-ssh-0.11.3/lib/libguile-ssh.so.11 >>> #6 0x7f29a1765965 in vm_regular_engine (thread=0x1dd58c0, >>> vp=0x1d4df30, registers=0x, resume=-1615646479) at vm-engine.c:786 >> >> I was able to come up with a reduced test case for Guile-SSH: >> >> https://github.com/artyom-poptsov/guile-ssh/issues/11 > > It turned out that the code to start a REPL server in (ssh dist node) > would currently hang, as I wrote in the bug report above. > > After investigation, I decided that inferiors are more appropriate than > Guile-SSH’s node to address this use case, after all. Commit > ed7b44370f71126087eb953f36aad8dc4c44109f changes ‘guix offload’ to > inferiors. It looks like this commit fixed the bug above, so I’m closing it. There are still occasional hangs in ‘ssh_handle_packets_termination’ though while reading from a channel but AFAICS that’s a different issue. Ludo’.
bug#31974: If a phase returns #f, a warning is issued, but the build continues
Mark H Weaver skribis: > I just noticed that I made a mistake in commit > d8a3b1b9e847d4a44d2695f95af77170d4d2788f, which changed 'gnu-build' in > (guix build gnu-build-system) to issue a warning if a phase returns a > value other than #t. > > The result is that if a phase returns a value other than #t, a warning > is issued, but the build nonetheless continues to the next phase, and > the build could ultimately "succeed" even some phases returned #f. This was fixed in commit 82230603ce06de7aa3e4aef2fa093a6dbf0ef8df. Closing! Ludo'.
bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc
Mark H Weaver skribis: > 'meson-build-system' includes 'patchelf' as an implicit input for all > packages that use it, and uses it from its 'fix-runpath' phase, > sometimes directly and sometimes via (guix build rpath). Since commit bf91e6835d21e3bd7b49bb85b40f61389604c6f7 ‘meson-build-system’ no longer relies on PatchELF. Closing! Ludo’.
bug#26705: guix publish daemon on Hydra became dysfunctional; needed restart
l...@gnu.org (Ludovic Courtès) skribis: > Mark H Weaver skribis: > >> While trying to update my GuixSD system in the last hour, I found that >> every attempt by the substituter to download NARs resulted in a 500 >> "Internal Server Error": [...] >> GET /74ch6nvjfkj3i56nygwijnaghlpi01d4.narinfo >> In guix/scripts/publish.scm: >> 393:2 2 (render-narinfo/cached # ...) >> In guix/store.scm: >> 663:9 1 (query-path-from-hash-part # #) >> In unknown file: >>0 (put-bytevector # #vu8(# ...) ...) >> ERROR: In procedure fport_write: Broken pipe >> GET /guix/nar/qz4mg7sid6avdav158lhr6wziqswpjmx-gnome-calendar-3.22.2.tar.xz >> In guix/scripts/publish.scm: >> 491:8 2 (render-nar # #< ...) >> In guix/store.scm: >> 648:0 1 (valid-path? # "/gnu/sto...") >> In unknown file: >>0 (put-bytevector # #vu8(1 ...) ...) >> ERROR: In procedure fport_write: Broken pipe > > Ooh, the connection to the daemon was broken, hence this error. > > Currently ‘guix publish’ assumes the connection opened in the > ‘guix-publish’ procedure remains valid all along. That’s normally the > case unless (1) the daemon is restarted, or (2) there’s a protocol error > somewhere that leads the daemon to close the connection. For now I’m closing this bug as “wontfix” because I’ve never seen any occurrence of #2, and because #1 cannot happen on GuixSD (if ‘guix-daemon’ is restarted, the shepherd will also restart ‘guix-publish’.) Ludo’.
bug#33999: CP437: Invalid Argument on init
I assume that it is related because the error is printed once for each failed service but I have no better reason than that. I can send a video of my boot tonight... It might be a little blurry though, all I have is my phone camera. If there's a way for me to start a screen recorder during init or capture the logs that it prints as a text file I'd be happy to do that, I just don't know of a way to. On Jan 9, 2019 11:08, "Danny Milosavljevic" wrote: Hi, apparently the message is printed by fsck.fat and is harmless (although we should still fix it). Are you sure that the services fail because of it? > (file-systems (cons* > (file-system > (device (file-system-label "ESP")) > (mount-point "/boot/efi") > (type "fat") Try adding (check? #f) here for testing purposes. > )
bug#34015: guix copy error message is quite difficult to understand
Hello Clément,
Clément Lassieur skribis:
> This is what happens when /etc/profile isn't sourced in the remote
> non-interactive shell on guix copy.
Do you know specifically which environment variable was missing and what
caused the backtrace?
Also, what commit are you using? I’m asking because commit
ed7b44370f71126087eb953f36aad8dc4c44109f changed the way we talk to a
remote Guix over SSH.
> I find it difficult to understand. I think the error message should
> lead us to a way to fix the issue.
>
> sending 1 store item (0 MiB) to '192.168.0.51'...
> ;;; [2019/01/08 16:48:31.587577, 0] write_to_channel_port: [GSSH ERROR]
> Remote channel is closed: #
> Backtrace:
> 10 (primitive-load "/home/clement/.config/guix/current/bin…")
> In guix/ui.scm:
> 1644:12 9 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 829:9 8 (catch srfi-34 # …)
> 829:9 7 (catch system-error # …)
> In guix/scripts/copy.scm:
> 80:27 6 (send-to-remote-host _ _)
> In guix/ssh.scm:
> 313:4 5 (send-files # _ _ # _ # _)
> In guix/store.scm:
> 1466:12 4 (export-paths # _ # …)
> 1446:22 3 (export-path # _ # …)
>644:13 2 (process-stderr _ _)
>607:10 1 (dump-port # # …)
> In unknown file:
>0 (put-bytevector # …)
>
> ERROR: In procedure put-bytevector:
> Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote
> channel is closed" # #f)'.
I agree the message could be… ahem… clearer. :-)
Thanks,
Ludo’.
bug#33616: biber build failure
Danny Milosavljevic writes: > [...] > Result: FAIL > Failed 16/43 test programs. 132/1061 subtests failed. I pushed 41a010875ba4108e666f11fc111cf5bb5dcf5464 some days ago, and biber seems to build correctly now. Could you check whether it now works for you? Thanks
bug#33616: biber build failure
Hi! Yes, it works for me now! Closing... pgpKnsJ6fzDDr.pgp Description: OpenPGP digital signature
