bug#40179: gpgme's json test fails

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

Hi!

ndre 写道：

Since the upgrade to gnupg 2.2.20, gpgme fails a json
test.


Then your Guix is hours out of date!  ;-)


Apparently, the same issue is not guix specific and has
already been reported on gnupg's bug track:

https://dev.gnupg.org/T4820


Thanks for this link!  I'd asked on #gnupg whether this was a 
known issue but didn't hear back.


I'll keep an eye on the issue and will apply whatever fix upstream 
decides on.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#40039: 'wrap-script' introduces spurious argument

[Brendan Tildesley]

It appears the repeated (car cl) results in the executable path getting 
sent to it's self as the first argument. I'm not sure how things managed 
to work up until now? I tested the following change and it fixed the one 
case I was using, but am not sure it is correct. why was the cons (car 
cl) there in the first place?



diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index b8be73ead4..9610f39d71 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -946,7 +946,7 @@ FILE are kept unchanged."
   "patch-shebang: ~a: 
changing `~a' to `~a'~%"
   file (string-append 
interp " " arg1) bin)

   (patch p bin rest))
-  (begin
+  (begin
 (format (current-error-port)
 "patch-shebang: ~a: 
changing `~a' to `~a'~%"

 file interp bin)
@@ -1292,11 +1292,10 @@ not supported."
    (_ vars
    `(let ((cl (command-line)))
   (apply execl ,interpreter
- (car cl)
- (cons (car cl)
-   (append
- ',(string-split args #\space)
-    cl))
+ (car cl) ;; The program.
+ (append
+  ',(string-tokenize args 
#\space)

+  cl)
    (template (string-append prog ".XX"))
    (out  (mkstemp! template))
    (st   (stat prog))

bug#40116: GDM: Memory leak in .gnome-shell-real process

[sirgazil via Bug reports for GNU Guix]

 > I'm planning to create another virtual machine with "guix system vm-image" 
 > instead to install all the packages I have in my user profile and leave it 
 > running overnight to see if there is any difference.

I wasn't able to create the VM image with this method. After an hour, the image 
was still building. I interrupted the process and gave up.

bug#40179: gpgme's json test fails

[ndre]

Hello Guix,

Since the upgrade to gnupg 2.2.20, gpgme fails a json
test.

Apparently, the same issue is not guix specific and has
already been reported on gnupg's bug track:

https://dev.gnupg.org/T4820

Bellow is the output I've got when I tried building it:

Making check in json
make[2]: Entering directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests/json'
make  check-am
make[3]: Entering directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests/json'
make  check-TESTS
make[4]: Entering directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests/json'
../../tests/start-stop-agent: line 18: which: command not found
starting gpg-agent..
../../tests/start-stop-agent: line 57: : command not found
OK
PASS: initial.test
Running t-config...
 success
Running t-version...
 success
Running t-keylist...
 success
Running t-keylist-secret...
 failed
FAIL: t-json
../../tests/start-stop-agent: line 18: which: command not found
stopping gpg-agent
PASS: final.test
===
1 of 3 tests failed
Please report to https://bugs.gnupg.org
===
make[4]: *** [Makefile:609: check-TESTS] Error 1
make[4]: Leaving directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests/json'
make[3]: *** [Makefile:732: check-am] Error 2
make[3]: Leaving directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests/json'
make[2]: *** [Makefile:734: check] Error 2
make[2]: Leaving directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests/json'
make[1]: *** [Makefile:720: check-recursive] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-gpgme-1.13.1.drv-0/gpgme-1.13.1/tests'
make: *** [Makefile:534: check-recursive] Error 1

Test suite failed, dumping logs.
command "make" "check" "-j" "4" failed with status 2
note: keeping build directory `/tmp/guix-build-gpgme-1.13.1.drv-0'
builder for `/gnu/store/s6rqh1nahanif481rxnpav0imdkas9gg-gpgme-1.13.1.drv' 
failed with exit code 1
a compilação de /gnu/store/s6rqh1nahanif481rxnpav0imdkas9gg-gpgme-1.13.1.drv 
falhou
Veja o log de compilação em 
"/var/log/guix/drvs/s6/rqh1nahanif481rxnpav0imdkas9gg-gpgme-1.13.1.drv.bz2".
guix build: error: build of 
`/gnu/store/s6rqh1nahanif481rxnpav0imdkas9gg-gpgme-1.13.1.drv' failed


signature.asc
Description: PGP signature

bug#39984: INFOPATH set in /etc/profile.d/guix.sh should end in ":" for Emacs's sake

[Ludovic Courtès]

Hi Adam,

Adam Porter  skribis:

> I installed Guix into my system, and I've been enjoying using it.
> However, I found that, after installing it, when I logged out and back
> in, and then started Emacs, Emacs could no longer see my system's info
> pages (including Emacs's own info pages).  I found that the Emacs
> variable Info-directory-list only contained
> "/home/me/.config/guix/current/share/info", so it couldn't see the
> info pages in "/usr/local/share/info/" and "/usr/share/info/".
> According to the Info-directory-list docstring:
>
> If nil, meaning not yet initialized, Info uses the environment
> variable INFOPATH to initialize it, or ‘Info-default-directory-list’
> if there is no INFOPATH variable in the environment, or the
> concatenation of the two if INFOPATH ends with a ‘path-separator’.
>
> I found that INFOPATH is being set in /etc/profile.d/guix.sh, which does this:
>
>   # Export INFOPATH so that the updated info pages can be found
>   # and read by both /usr/bin/info and/or $GUIX_PROFILE/bin/info
>   export INFOPATH="$_GUIX_PROFILE/share/info${INFOPATH:+:}$INFOPATH"
>
> Since it does not append a colon at the end, Emacs doesn't add the
> directories from Info-default-directory-list.  I added a colon to the
> end and restarted Emacs, and it fixed the problem.
>
> So I'd suggest adding ":" to the end of INFOPATH in /etc/profile.d/guix.sh.

Done in 3c69701f9735dd62a2f765b8bd23a7eaeb391412.

Thanks for the clear explanation!

Ludo’.

bug#39993: Guix report hash mismatch when underlying cause is ENOSPC

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Maxim Cournoyer  skribis:
>
>> Guix should correctly report that it ran out of space instead of falsely
>> mentioning hash mismatches and attempting alternative download sources,
>> as demonstrated by the Guix output below:
>>
>> Session:
>>
>> building 
>> /gnu/store/dqzq8hbk8gqx5lhmnxsl5vl0c6s3i0a2-tcpdump-4.9.3.tar.gz.drv...
>> downloading from https://www.tcpdump.org/release/tcpdump-4.9.3.tar.gz...
>
> Could you post the log returned by ‘guix build --log-file
> /gnu/store/dqzq8hbk8gqx5lhmnxsl5vl0c6s3i0a2-tcpdump-4.9.3.tar.gz.drv’?

I was able to reproduce it with a hack and that gives:

--8<---cut here---start->8---
$ ./pre-inst-env guix build -S tcpdump --check 
accepted connection from pid 32022, user ludo
The following derivation will be built:
   /gnu/store/3y4zkzpkx799cvph0qi8kvkh26l8kfww-tcpdump-4.9.3.tar.gz.drv
building /gnu/store/3y4zkzpkx799cvph0qi8kvkh26l8kfww-tcpdump-4.9.3.tar.gz.drv...

Starting download of 
/gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz
>From https://www.tcpdump.org/release/tcpdump-4.9.3.tar.gz...
In procedure fport_write: Ne haviĝas plu da spaco sur aparato

Starting download of 
/gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz
>From 
>https://ci.guix.gnu.org/file/tcpdump-4.9.3.tar.gz/sha256/0434vdcnbqaia672rggjzdn4bb8p8dchz559yiszzdk0sjrprm1c...
In procedure fport_write: Ne haviĝas plu da spaco sur aparato

Starting download of 
/gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz
>From 
>https://tarballs.nixos.org/sha256/0434vdcnbqaia672rggjzdn4bb8p8dchz559yiszzdk0sjrprm1c...
following redirection to 
`https://tarballs.nixos.org/sha512/3aec673f78b996a4df884b1240e5d0a26a2ca81ee7aca8a2e6d50255bb53476e008a5ced4409e278a956710d8a4d31d85bbb800c9f1aab92b0b1046b59292a22'...
In procedure fport_write: Ne haviĝas plu da spaco sur aparato

Starting download of 
/gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz
>From 
>https://archive.softwareheritage.org/api/1/content/sha256:2cd47cb3d460b6ff75f4a9940f594317ad456cfbf2bd2c8e5151e16559db6410/raw/...
In procedure fport_write: Ne haviĝas plu da spaco sur aparato
failed to download 
"/gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz" from 
"https://www.tcpdump.org/release/tcpdump-4.9.3.tar.gz";
warning: rewriting hashes in 
`/gnu/store/mv33j0si1n75q9kdimhvyrjn05pbxz5b-tcpdump-4.9.3.tar.gz'; cross 
fingers
sha256 hash mismatch for 
/gnu/store/mv33j0si1n75q9kdimhvyrjn05pbxz5b-tcpdump-4.9.3.tar.gz:
  expected hash: 0434vdcnbqaia672rggjzdn4bb8p8dchz559yiszzdk0sjrprm1c
  actual hash:   0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
hash mismatch for store item 
'/gnu/store/mv33j0si1n75q9kdimhvyrjn05pbxz5b-tcpdump-4.9.3.tar.gz'
--8<---cut here---end--->8---

> The root cause is that ‘false-if-exception*’ as used in (guix build
> download) is too coarse-grain.

I came up with a fix in 4a6ec23a9780bd75a7e527bd0dfb1943347869bb.

Thanks,
Ludo’.

bug#40170: Audio-Output of some IceCat videos far too low pitch

[Arne Babenhauserheide]

Tobias Geerinckx-Rice via Bug reports for GNU Guix  writes:

> Merged with #37244, #38047.
>
> Arne Babenhauserheide 写道：
>> I don’t know why.
>
> I don't think anybody does for sure :-(
>
> Try the work-arounds in
> .

I’ll do — thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

bug#40125: Problem with guix offload: Remote channel closed

[Ludovic Courtès]

Hi Mikael,

Mikael Djurfeldt  skribis:

> I will look at the other buh reports. Meanwhile, do you have any hint on
> where to look/insert logging code in order to see what is going on?

On ‘wand’, can you run something like:

  sudo strace -s 500 -p $(pidof sshd) -f -o sshd.log

After that, run ‘guix offload test’ from the other host, and check what
‘sshd.log’ contains.  If would in particular look for all the ‘execve’
syscalls as well as what happens right before ‘exit_group’ syscalls.
There are probably error messages lurking there.  :-)

You can share excerpts of the log but note that it will contain
sensitive crypto material, so beware.

Thanks in advance,
Ludo’.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

Hi

Brice Waegeneire  writes:

> Hello,
>
> Arun Isaac  writes:
>> FWIW, I fixed our ansible package in
>> https://issues.guix.info/issue/33777 . This is not a general solution,
>> but at least our ansible package works at the moment.
>
> If this bug is about ansible malfunctioning then it should be closed,
> Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
> it myself successfully with the command from the IRC report[0] (linked
> in the merged issue[2]).
> On the other hand If it's about fixing it with the new wrap-script from
> Ricardo I can send a patch, but the derivation will need guile as a new
> input.

I would be okay with closing it, as ansible works fine right now. If the
current solution is deemed too brittle, or if the intent behind the new
wrap-script is that we use it everywhere we can, then not of course.

- Jelle

bug#40176: `guix pull` fails due to unbound variable qemu-minimal-2.10

[Marius Bakke]

Hi Evan,

Evan Straw  writes:

> Hello,
> When attempting to run `guix pull` today, I encountered an error while
> building the package cache.

My bad, sorry about that!  This was fixed in
18401bdf69b2540b13db86aed199d1ebc585a844, thanks for reporting it!


signature.asc
Description: PGP signature

bug#40176: `guix pull` fails due to unbound variable qemu-minimal-2.10

[Evan Straw]

Hello,
When attempting to run `guix pull` today, I encountered an error while
building the package cache.

Here is the output of `guix pull`:
--8<---cut here---start->8---
evan@xenon:~$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   dde3f55
Computing Guix derivation for 'x86_64-linux'... -
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/146ww7y6p3dxs63qry46zd5ni3ksi1v7-profile.drv
   /gnu/store/biwwzic55r9gdz8fkmxm61dwfhx6irjl-inferior-script.scm.drv
   /gnu/store/jl7j7xwlrgz0188mh4sq7mbv2waspiv1-profile.drv
0.0 MB will be downloaded:
   /gnu/store/llvcnyrnsasq1kbll9k19awrkj3qkjq6-manual-database
The following profile hooks will be built:
   /gnu/store/4136wng3vj76id8d5lrghasjbfq62ly8-guix-package-cache.drv
   /gnu/store/kbacrq2k9iv07hk8q5j95b88ycrm38x2-ca-certificate-bundle.drv
   /gnu/store/v24zmacl82qpmmi6fmxdmdgjs2mwxg9h-info-dir.drv
   /gnu/store/y93pwf2clvhyj93vzj3cmwv9z7jbp99l-fonts-dir.drv
downloading from 
https://ci.guix.gnu.org/nar/lzip/llvcnyrnsasq1kbll9k19awrkj3qkjq6-manual-database...
 manual-database  231B 226KiB/s 00:00 
[##] 100.0%

building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building /gnu/store/jl7j7xwlrgz0188mh4sq7mbv2waspiv1-profile.drv...
building /gnu/store/biwwzic55r9gdz8fkmxm61dwfhx6irjl-inferior-script.scm.drv...
building package cache...
/builder for 
`/gnu/store/4136wng3vj76id8d5lrghasjbfq62ly8-guix-package-cache.drv' failed to 
produce output path 
`/gnu/store/8j8vml0w92s5rpkfi2b5yzpfd2xzsrr3-guix-package-cache'
build of /gnu/store/4136wng3vj76id8d5lrghasjbfq62ly8-guix-package-cache.drv 
failed
View build log at 
'/var/log/guix/drvs/41/36wng3vj76id8d5lrghasjbfq62ly8-guix-package-cache.drv.bz2'.
cannot build derivation 
`/gnu/store/146ww7y6p3dxs63qry46zd5ni3ksi1v7-profile.drv': 1 dependencies 
couldn't be built
guix pull: error: build of 
`/gnu/store/146ww7y6p3dxs63qry46zd5ni3ksi1v7-profile.drv' failed
--8<---cut here---end--->8---

Here are the contents of the build log provided:
--8<---cut here---start->8---
(repl-version 0 1 1)
Generating package cache for 
'/gnu/store/m8f66b82z47ywnsxx0qsh402lfg3l5lp-profile'...
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
(qemu-minimal-2.10)) (value #f))
--8<---cut here---end--->8---

I normally have some channels added for my own personal packages as well
as some from a friend's personal packages, but this error happens even
with those channels removed from my channels.scm file. Below is the
output of `guix describe` (containing the channels I normally have
added, I've removed some names and URLs for privacy, please let me know
if they are necessary):
--8<---cut here---start->8---
evan@xenon:~$ guix describe
Generation 52   Mar 19 2020 05:21:49(current)
  guix 58d9027
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 58d902741240d52d783e77ef3a0540642bd91e4c
   73aad23
repository URL: 
branch: master
commit: 73aad23c652df42c63b4029e97db5c4149930f71
  personal-channel 159b508
repository URL: 
branch: master
commit: 159b50819c8fe9061e1b8fccbbe88fc13a91d971
--8<---cut here---end--->8---

Another Guix user I've spoken to has
confirmed the same error is happening on his machine as well.

I hope this report helps. Please let me know if I can provide any
additional information.

-- Evan Straw 


signature.asc
Description: PGP signature

bug#28966: Hunting: git fails test suite

[Marius Bakke]

zimoun  writes:

> This bug is about failing tests of Git. Possible because the stack size.
> It was opened against the commit 62d48234e2 (Git version 2.14.3).

Since we haven't heard back from Ricardo regarding this I'll assume the
issue is fixed.  Closing!


signature.asc
Description: PGP signature

bug#36675: [PATCH] gnu: kodi: Disable intermittently failing test.

[Marius Bakke]

Hi Josh,

Josh Holland  writes:

> As reported in , occasionally the
> TestMassEvent.General test in kodi crashes with a mutex error.

This patch feel through the cracks, sorry about that.  Can you rebase it
on the current master branch?

TIA, and apologies for the inconvenience.


signature.asc
Description: PGP signature

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Brice Waegeneire]

Hello,

Arun Isaac  writes:

FWIW, I fixed our ansible package in
https://issues.guix.info/issue/33777 . This is not a general solution,
but at least our ansible package works at the moment.


If this bug is about ansible malfunctioning then it should be closed,
Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
it myself successfully with the command from the IRC report[0] (linked
in the merged issue[2]).
On the other hand If it's about fixing it with the new wrap-script from
Ricardo I can send a patch, but the derivation will need guile as a new
input.

[0]: http://logs.guix.gnu.org/guix/2018-04-28.log#013741
[1]: https://issues.guix.info/issue/31299

Brice.

bug#34063: dscrypt-proxy dependencies could not be built

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

Guix,

Marius Bakke 写道：

 writes:


Bug on `guix pull && guix package -u`:
using ci.guix.info dnscrypt-proxy-1.9.5 derivation could not be 
built because of dependencies.


This issue seems to have fixed itself, closing the bug report. 
Thanks

anyway!


The 1.x upstream tarballs have vanished, so we're only one big 
oops away from having no source at all.


I found one super-random mirror (check out dat port) through a Web 
search:


 
http://vpnb.leipzig.freifunk.net:8004/srv2/lede/lede-20171019/dl/dnscrypt-proxy-1.9.5.tar.bz2

We should rather move on to 2.x, as[0] upstream has done.  Anybody 
using this package want to try?


Kind regards,

T G-R

[0]: https://github.com/DNSCrypt/dnscrypt-proxy/releases


signature.asc
Description: PGP signature

bug#40125: Problem with guix offload: Remote channel closed

[Mikael Djurfeldt]

On Sat, Mar 21, 2020 at 5:05 PM Mikael Djurfeldt 
wrote:

> Hi Ludovic! :-)
>
> I did generate the signing key on wand. (But is this sensitive to what
> user I used? O might have done it as root rather than as the ssh user used
> to login on wand.)
>

Sorry, I read your email on a cell phone and missed the "sudo" in front of
the command. Yes, I did that.

bug#35324: SDDM shows black screen instead of login prompt

[Marius Bakke]

Diego Nicola Barbato  writes:

> Hello Guix,
>
> As already mentioned on IRC SDDM does not work for me.
>
> This is what I tried:
>
> $ qemu-system-x86_64 -enable-kvm -snapshot -m 6G $(guix system vm-image 
> --image-size=24G config.scm)
>
> After booting I get a black screen instead of a greeter.  I have
> attached the config.scm, Xorg.log, and sddm.log.

I believe this issue has been fixed, please reopen if you still
experience problems.  Thanks!


signature.asc
Description: PGP signature

bug#34063: dscrypt-proxy dependencies could not be built

[Marius Bakke]

 writes:

> Bug on `guix pull && guix package -u`:
> using ci.guix.info dnscrypt-proxy-1.9.5 derivation could not be built because 
> of dependencies.

This issue seems to have fixed itself, closing the bug report.  Thanks
anyway!


signature.asc
Description: PGP signature

bug#40170: Audio-Output of some IceCat videos far too low pitch

[Ekaitz Zarraga]

‐‐‐ Original Message ‐‐‐
On Saturday, March 21, 2020 6:59 PM, Tobias Geerinckx-Rice via Bug reports for 
GNU Guix  wrote:

> Merged with #37244, #38047.
>
> Arne Babenhauserheide 写道：
>
> > I don’t know why.
>
> I don't think anybody does for sure :-(
>
> Try the work-arounds in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37244.
>
> Kind regards,
>
> T G-R

I don't know why neither but I solved the case for some video formats 
installing Gstreamer plugins.
In the past, when I was in Ubuntu (a week ago or so) I found the same issues 
when I started using
a UserAgent randomizer: the low-pitch appeared for some specific UserAgent 
strings.

Could that be related somehow?

Best,
Ekaitz

bug#40170: Audio-Output of some IceCat videos far too low pitch

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

Merged with #37244, #38047.

Arne Babenhauserheide 写道：

I don’t know why.


I don't think anybody does for sure :-(

Try the work-arounds in 
.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#40170: Audio-Output of some IceCat videos far too low pitch

[Arne Babenhauserheide]

Hi,

On several video-sites icecat plays the sound in lower pitch.

One example:
https://www1.wdr.de/daserste/monitor/videos/video-monitor-vom--268.html
Another example are videos on twitter.

On other sites it works, for example on youtube.

I don’t know why.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

bug#40142: CVE checker return false positives

[Brice Waegeneire]

Hello,

On 2020-03-21 16:25, Ludovic Courtès wrote:

Probably the fix would be to preserve the vendor part in the API and to
somehow use it meaningfully.

Ideas & patches welcome!


I'll see what I can write a patch to fix it then.


Also note the missing / on the first line and it output on `stderr'
instead of `stdout'.


What do you mean?


I misunderstood the meaning of “gnu/packages/version-control.scm:149:2:”
and thought there was a missing / before “gnu/”; this is irrelevant. 
About
the output stream of “guix lint” I think it should output to `stdout', 
not

`stderr' as it's currently the case.

Brice.

bug#39282: Rhythmbox does not start

[sirgazil via Bug reports for GNU Guix]

This problem is solved. I can't reproduce it with

$ guix describe
Generation 64   Mar 20 2020 13:54:14(current)
  guix 830dab8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 830dab870ab1d4a4ec1127a877a43d19f86c4f7f

$ rhythmbox --version
rhythmbox 3.4.3

I couldn't find any commit in the log of Guix's git repository addressing this 
issue.

bug#34276: ‘guix system disk-im age’ successfully builds a bad image

[Brice Waegeneire]

Hello Ludo,

On 2020-03-21 15:58, Ludovic Courtès wrote:

Any idea how to implement it?  Is QMP a request/reply kind of interface
like the monitor?


Not really or I would have sent a patch instead.

QMP is similar to the the monitor in the sense that you can send a 
command and

receive a reply but it give us access to more features; in our case
asynchronous events. To get notified by the pvpanic device that a panic 
occured

on the guest it is needed to do the following:
1. Connect to the socket
2. Receive the server greetings
3. Respond with the capabilites request
4. Receive the capabilites respond
5. Listen on GUEST_PANICKED events

The QMP specifications are available here[0].

[0]: 
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/interop/qmp-spec.txt;hb=HEAD


Brice.

bug#27003: [PATCH 0/3] Generalized wrap phase for perl, python.

[Ludovic Courtès]

Hi,

Brice Waegeneire  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> BTW, there’s also this patch series on this topic:
>>
>>   https://issues.guix.info/issue/27003
>>
>> What to do?
>
> A `wrap-script' procedure has been merged as of
> 0fb9a8df429a7b9f40610ff15baaff0d8e31e8cf
> thanks to Ricardo's patch from https://issues.guix.info/issue/27003,
> it seems to
> provide similar functionality as the `program-wrapper' suggested
> here. Should we close
> this issue?

Yes, it seems that the patch that Alex initially submitted shares the
same goals as Ricardo’s ‘wrap-script’, so I guess we can close it.

Thanks for your work on bug triage!

Ludo’.

bug#40142: CVE checker return false positives

[Ludovic Courtès]

Hi,

Brice Waegeneire  skribis:

> The CVE checker of “guix lint” returns false positives:
> ┌
> │ LANGUAGE=C guix lint git 2>&1
> ├───
> │ gnu/packages/version-control.scm:149:2: git@2.25.1: probably
> vulnerable to CVE-2020-2136, CVE-2019-1003010, CVE-2018-1000110,
> CVE-2018-1000182

[...]

> • [CVE-2020-2136]: “Jenkins Git Plugin 4.2.0 and earlier […]”
> • [CVE-2019-1003010]: “[…] Jenkins Git Plugin 3.9.1 and earlier […]”
> • [CVE-2018-1000110]: “[…] Jenkins Git Plugin version 3.7.0 and earlier
>   […]”
> • [CVE-2018-1000182]: “[…] Jenkins Git Plugin 3.9.0 and older […]”

(guix cve) reports it as applying to “git”:

--8<---cut here---start->8---
scheme@(guix cve)> (define items
 (call-with-decompressed-port 'gzip (http-fetch 
(yearly-feed-uri 2020))
   json->cve-items))
scheme@(guix cve)> (find (lambda (item)
   (string=? (cve-id (cve-item-cve item)) 
"CVE-2020-2136"))
 items)
$130 = #< cve: #< id: "CVE-2020-2136" data-type: CVE 
data-format: MITRE references: (#< url: 
"http://www.openwall.com/lists/oss-security/2020/03/09/1"; tags: ("Third Party 
Advisory")> #< url: 
"https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1723"; tags: ("Vendor 
Advisory")>)> configurations: (("git" (<= "4.2.0"))) published-date: # last-modified-date: #>
--8<---cut here---end--->8---

I think the problem stems from the fact that the CVE configuration
specify “jenkins:git” (where “jenkins” is the “vendor” and “git” is the
“product”), but we just strip the vendor part:

--8<---cut here---start->8---
$ wget -O - -q https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2020.json.gz| 
gunzip | jq

[…]

  "configurations": {
"CVE_data_version": "4.0",
"nodes": [
  {
"operator": "OR",
"cpe_match": [
  {
"vulnerable": true,
"cpe23Uri": "cpe:2.3:a:jenkins:git:*:*:*:*:*:jenkins:*:*",
"versionEndIncluding": "4.2.0"
  }
]
  }
]
--8<---cut here---end--->8---

It’s usually the case that the vendor part has little relevance for free
software packages, but in this case it does make a difference.

Probably the fix would be to preserve the vendor part in the API and to
somehow use it meaningfully.

Ideas & patches welcome!

> Also note the missing / on the first line and it output on `stderr'
> instead of `stdout'.

What do you mean?

Thanks,
Ludo’.

bug#39335: GNOME Help: Getting Started: Videos don't start

[sirgazil via Bug reports for GNU Guix]

This problem is solved. I can't reproduce it anymore using 

$ guix describe
Generation 64   Mar 20 2020 13:54:14(current)
  guix 830dab8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 830dab870ab1d4a4ec1127a877a43d19f86c4f7f

$ yelp --version
yelp 3.32.2

bug#40125: Problem with guix offload: Remote channel closed

[Mikael Djurfeldt]

Hi Ludovic! :-)

I did generate the signing key on wand. (But is this sensitive to what user
I used? O might have done it as root rather than as the ssh user used to
login on wand.)

I will look at the other buh reports. Meanwhile, do you have any hint on
where to look/insert logging code in order to see what is going on?

Best regards,
Mikael

Den lör 21 mars 2020 16:50Ludovic Courtès  skrev:

> Hi Mikael!
>
> Good to see you here.  :-)
>
> Mikael Djurfeldt  skribis:
>
> > mdj@hat:~$ guix offload test
> > guix offload: testing 1 build machines defined in
> > '/etc/guix/machines.scm'...
> > guix offload: Guix is usable on 'wand.pdc.kth.se' (test returned
> > "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
> > guix offload: 'wand.pdc.kth.se' is running GNU Guile 3.0.1
> > sending 1 store item (0 MiB) to 'wand.pdc.kth.se'...
> > exporting path `/gnu/store/gl7dps3yx0vrxz16sj7q3w7gs3vdbxj4-export-test'
> > ;;; [2020/03/18 20:53:04.930901, 0] write_to_channel_port: [GSSH ERROR]
> > Remote channel is closed: #
> > Backtrace:
> >1 (primitive-load "/home/mdj/.config/guix/current/bin/guix")
> > In guix/ui.scm:
> >   1833:12  0 (run-guix-command _ . _)
> >
> > guix/ui.scm:1833:12: In procedure run-guix-command:
> > Throw to key `guile-ssh-error' with args `("write_to_channel_port"
> "Remote
> > channel is closed" # #f)'.
>
> Did you generate a signing key on wand.pdc.kth.se?  Specifically with:
>
>   sudo guix archive --generate-key
>
> (See
>  >.)
>
> Error reporting in guix offload is currently suboptimal as you have
> seen.  There’s a couple of bug reports open on that topic, so hopefully
> we’ll get there soon!
>
> Ludo’.
>

bug#34276: ‘guix system disk-im age’ successfully builds a bad image

[Ludovic Courtès]

Hi Brice,

Brice Waegeneire  skribis:

>> I investigated a bit.  I managed to get our code to cause a kernel 
>> panic
>> upon failure (patch below).  However I fail to turn that guest kernel
>> panic into a different QEMU exit code.
>> 
>> I tried to use the “pvpanic” paravirtualized device (the ‘pvpanic.ko’
>> module in the guest, and “-device pvpanic” on the QEMU command line),
>> but unfortunately that thing is almost undocumented and I can’t get it
>> to turn the panic into a non-zero exit code, nor do I know if it’s
>> possible.
>> 
>> Thoughts anyone?
>
> I looked a little into it and I have found how to use pvpanic.
> Unfortunately it's not as straight forward as getting a non-zero exit
> code form qemu. When pvpanic is loaded in a VṂ, as you did with 
> “-device
> pvpanic”, generate events[0] on the QMP interface when a crash happen
> and qemu either shutdown or pause when using --no-shutdown[1].
>
> (gnu build marionette) which use the “-monitor” interface could be
> recycled to use “-qmp” a machine interface using JSON.
>
> Following is log of a QMP session where the guest panicked[2]:

Oooh, I see, thanks for digging into this!

Any idea how to implement it?  Is QMP a request/reply kind of interface
like the monitor?

Ludo’.

bug#40125: Problem with guix offload: Remote channel closed

[Ludovic Courtès]

Hi Mikael!

Good to see you here.  :-)

Mikael Djurfeldt  skribis:

> mdj@hat:~$ guix offload test
> guix offload: testing 1 build machines defined in
> '/etc/guix/machines.scm'...
> guix offload: Guix is usable on 'wand.pdc.kth.se' (test returned
> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
> guix offload: 'wand.pdc.kth.se' is running GNU Guile 3.0.1
> sending 1 store item (0 MiB) to 'wand.pdc.kth.se'...
> exporting path `/gnu/store/gl7dps3yx0vrxz16sj7q3w7gs3vdbxj4-export-test'
> ;;; [2020/03/18 20:53:04.930901, 0] write_to_channel_port: [GSSH ERROR]
> Remote channel is closed: #
> Backtrace:
>1 (primitive-load "/home/mdj/.config/guix/current/bin/guix")
> In guix/ui.scm:
>   1833:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:1833:12: In procedure run-guix-command:
> Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote
> channel is closed" # #f)'.

Did you generate a signing key on wand.pdc.kth.se?  Specifically with:

  sudo guix archive --generate-key

(See
.)

Error reporting in guix offload is currently suboptimal as you have
seen.  There’s a couple of bug reports open on that topic, so hopefully
we’ll get there soon!

Ludo’.

bug#27003: [PATCH 0/3] Generalized wrap phase for perl, python.

[Brice Waegeneire]

Hello,

l...@gnu.org (Ludovic Courtès) writes:

BTW, there’s also this patch series on this topic:

  https://issues.guix.info/issue/27003

What to do?


A `wrap-script' procedure has been merged as of 
0fb9a8df429a7b9f40610ff15baaff0d8e31e8cf
thanks to Ricardo's patch from https://issues.guix.info/issue/27003, it 
seems to
provide similar functionality as the `program-wrapper' suggested here. 
Should we close

this issue?

Brice.

bug#39926: Regression introduced by Shepherd 0.7.0 ('make check-system TESTS=btrfs-root-os' fails)

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer  skribis:
>>
>>> Maxim Cournoyer  writes:
>>>
>>> [...]
>>>
 Comparing with the above uname output, we can see that it validates the
 hostname matches against "liberigilo", yet it is "gnu"!  Perhaps
 Shepherd 0.7.0 introduced some problem with the hostname service?
>>>
>>> Another data point: the same happen when running './pre-inst-env make
>>> check-system TESTS=installed-os', so this is not Btrfs specific.
>>
>> Fixed by be0a672c30ad1401019abb5cb83d59be171813d0.
>>
>> I wonder how this could have worked before: ‘reboot’ never gets a reply,
>> so it’s supposed to hang until it’s killed when the ‘user-processes’
>> service is stopped.
>>
>> Thanks,
>> Ludo’.
>
> Hey, weird!  Anyway, thanks for fixing it!  How did you debug this?  I'm 
> curious.

I first noticed that the installation script ran to completion and that
the VM seems to stop properly.  Then I saw our code that did:

  (zero? (marionette-eval '(system #$script) marionette))

So I just tried adding:

  (pk (marionette-eval '(system "/run/current-system/profile/sbin/reboot")
   marionette))

to the ‘basic’ test.  I noticed it would return 15, and then I got it.

Nothing fancy, mostly stubbornness and perseverance.  :-)

Ludo’.

bug#40159: python-language-server-0.31.7 fails to build

[Marius Bakke]

ryan  writes:

> View build log at 
> '/var/log/guix/drvs/3m/x0662f42mrhvsvyahlj8ajyykq9hax-python-language-server-0.31.7.drv.bz2'.
>
> The build log listed above ended with:
>
> ...
> running "python setup.py" with command "test" and parameters ()
> running test
> Searching for jedi<0.16,>=0.14.1
> Reading https://pypi.org/simple/jedi/
> Download error on https://pypi.org/simple/jedi/: [Errno -2] Name or 
> service not known -- Some packages may not be found!
> Couldn't retrieve index page for 'jedi'
> Scanning index of all packages (this may take a while)
> Reading https://pypi.org/simple/
> Download error on https://pypi.org/simple/: [Errno -2] Name or service 
> not known -- Some packages may not be found!
> No local packages or working download links found for jedi<0.16,>=0.14.1
> error: Could not find suitable distribution for 
> Requirement.parse('jedi<0.16,>=0.14.1')

Whoops, thanks for reporting this issue.  Fixed in
dcff9bda97d088a717d6f7c01bdf7c0e68d62b9b.


signature.asc
Description: PGP signature

bug#39950: flatpack packages can't open external applications

[Damien Cassou]

Hi,

Marius Bakke  writes:
> To my knowledge, Flatpak applications run in isolated containers and
> thus have no visibility to the host system by default.  Maybe there are
> some command-line arguments you can add to give it access to what it
> needs to open a browser?


When in Fedora, the exact same Flatpak command works fine: a browser
opens.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill