bug#47204: DrRacket fonts issue

[Jack Hill]

Hi Guix,

DrRacket, both 7.9 and the fixed [0] 8.0 seem to have a fonts issue 
resulting in attatched screenshot with boxes where I expect readable 
characters. I have many fonts installed and recently ran `fc-cache -rvf`.


[0] https://issues.guix.gnu.org/47180

I'm running Guix System. Extra information:

jackhill@alperton ~$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
jackhill@alperton ~$ guix package -I |grep font-
font-awesome4.7.0   out 
/gnu/store/gknn01i1nr80apmcx42w36cqcz3zzri2-font-awesome-4.7.0
font-public-sans1.008   out 
/gnu/store/5agg754wp87z09ski6l0zvs3px81ppfq-font-public-sans-1.008
font-anonymous-pro-minus1.003   out 
/gnu/store/ywm6jrfsz5iw6n9nzgkh5x3igiq3793k-font-anonymous-pro-minus-1.003
font-opendyslexic   0.91.12 out 
/gnu/store/sdv4a8p6cqf2sg5qqf8ksw73h03lmkny-font-opendyslexic-0.91.12
font-sil-andika 5.000   out 
/gnu/store/da0zg8d9ybh6j11n0imx6fknxv9xnab4-font-sil-andika-5.000
font-vazir  22.1.0  out 
/gnu/store/bb8inx1zfncy4jhm0w889bvhpyja5ws0-font-vazir-22.1.0
font-fontna-yasashisa-antique   0   out 
/gnu/store/7fyrxqq1prdgkc6sajw19pp7c0k7ch17-font-fontna-yasashisa-antique-0
font-blackfoundry-inria 1.200   out 
/gnu/store/wam1cyqfx0ria7m75n5vvja00zbkm935-font-blackfoundry-inria-1.200
font-lohit  20140220out 
/gnu/store/v01qkwv5yw0dma3pan2qally7dyg2wwk-font-lohit-20140220
font-dejavu 2.37out 
/gnu/store/7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37
font-cns11643   98.1.20180605   out 
/gnu/store/a9kjz5q78klwnbf90jjlp09wfnxs0gpf-font-cns11643-98.1.20180605
font-sil-charis 5.000   out 
/gnu/store/q65i5vvin72zjpdqil91ih9wpd610mad-font-sil-charis-5.000
font-adobe-source-han-sans  1.004   out 
/gnu/store/vravfg76hqm27lrylhc2y44zs1y9zyn2-font-adobe-source-han-sans-1.004
font-tamzen 1.11.5  out 
/gnu/store/ndh77a0698x7f5l72iphl2328mqa7jms-font-tamzen-1.11.5
font-inconsolata3.000   out 
/gnu/store/8vq65z92r51ghnxbgdss9irk23df9s5f-font-inconsolata-3.000
font-ubuntu 0.83out 
/gnu/store/dkmg1zagg7zjq05zql4y3daahvdwj40x-font-ubuntu-0.83
font-rachana7.0.3   out 
/gnu/store/r4qf4yljwkpp01p4d3djdw1qx2wvnarb-font-rachana-7.0.3
font-cns11643-swjz  1   out 
/gnu/store/58gxg3npp9g3c3pggh3kkcb5s8rd62ga-font-cns11643-swjz-1
font-opendyslexic   0.91.12 out 
/gnu/store/sdv4a8p6cqf2sg5qqf8ksw73h03lmkny-font-opendyslexic-0.91.12
font-lato   2.015   out 
/gnu/store/k6rsaqb1mqq47i4mj8cdj1lwpfi6bxh0-font-lato-2.015
font-bitstream-vera 1.10out 
/gnu/store/1y1v30gm3h073xlybx0442gc6kr1kqh8-font-bitstream-vera-1.10
font-google-noto20171025out 
/gnu/store/g2szydnbvs7qqy2nf7qylba0rapajmd8-font-google-noto-20171025
font-sil-gentium5.000   out 
/gnu/store/5hkxi9ph5zk7lnqm1iq24hdnflcpm5jr-font-sil-gentium-5.000
font-anonymous-pro  1.002   out 
/gnu/store/a2pdlzvk0ywnyfx7666qngas7f8779hx-font-anonymous-pro-1.002
font-un 1.0.2-080608out 
/gnu/store/v6yfj82i40z6ca125qqahbxigprm67bq-font-un-1.0.2-080608
font-go 20170330-1.f03a046  out 
/gnu/store/5422g1r53gjviyhqlagwwsbzggybyr25-font-go-20170330-1.f03a046
font-google-roboto  2.136   out 
/gnu/store/3mv6bxcvdds1npbg2wf10901xh9y3x03-font-google-roboto-2.136
font-ipa-mj-mincho  006.01  out 
/gnu/store/mg4k1g4v1mb57f6vdmgb2nhr8axkz9jg-font-ipa-mj-mincho-006.01
font-wqy-microhei   0.2.0-beta  out 
/gnu/store/k3my3hqrgs9c6mbjkyxvbhlypqb5ll32-font-wqy-microhei-0.2.0-beta
font-fira-mono  3.206   out 
/gnu/store/3bb6j1bi4yam4fj27k3jf2wcci0jns5q-font-fira-mono-3.206
font-dosis  1.7 out 
/gnu/store/jp5bl864rqlw1v5fp8cchhvl96vhalr0-font-dosis-1.7
font-mplus-testflight   063aout 
/gnu/store/scf2li4kzxv5f84p994d7pg3xm8zjx91-font-mplus-testflight-063a
font-fira-sans  4.202   out 
/gnu/store/mmkpalfwk9arl9cm0a92kvspfrfbsmg6-font-fira-sans-4.202
font-hermit 2.0 out 
/gnu/store/lk9yi94cwriwz9y4kflr5rpf59ady7vs-font-hermit-2.0
font-adobe-source-code-pro  2.030R-ro-1.050R-it out 
/gnu/store/l5m74158njcan3p784gqhkir6zyk0bcp-font-adobe-source-code-pro-2.030R-ro-1.050R-it
font-google-material-design-icons   3.0.1   out 
/gnu/store/3yyzsgvagf7rw5lmkx70j5nmwa4qwd0y-font-google-material-design-icons-3.0.1
font-wqy-zenhei 0.9.45  out 
/gnu/store/4666sykl746p9vf4k2vh0nkiw12zjhs5-font-wqy-zenhei-0.9.45
font-hack   3.003   out 
/gnu/store/52r8anazd4rnkq9m3vxk700jga5h0i74-font-hack-3.003
font-tex-gyre   2.005   out 
/gnu/store/pyw1h9gh77b1k8wm26vb9qfbk083qkhf-font-tex-gyre-2.005
font-mathjax2.7.2   out 
/gnu/store/bf582s56ldb3y34pql3fd583wyn49x2a-font-mathjax-2.7.2

bug#47185: grub2 package is vulnerable to CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

[Leo Famulari]

On Tue, Mar 16, 2021 at 07:47:43PM -0400, Mark H Weaver wrote:
> I think we should refrain from updating GRUB until there's an official
> upstream stable release.  Even then, I would advise making an effort to
> test it on Guix systems, using several different system configurations,
> before pushing it to 'master'.
> 
> What do you think?

I agree with Mark that we should tread carefully. Also, I am always
available to test GRUB changes. I have a computer dedicated to testing
changes with Guix System.

bug#47201: sbcl-cl-webkit doesn't protect webkitgtk from garbage collection

[Leo Famulari]

On Tue, Mar 16, 2021 at 11:40:05PM +, pkill9 wrote:
> I have nyxt installed, which has sbcl-cl-webkit as an input, which has
> webkitgtk as an input, and recently it produced an error which was
> fixed by building webkitgtk, so it wasn't in the store.
> 
> sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
> be, so it seems it's not protected from garbage collection by
> sbcl-cl-webkit. Am I wrong in this?

You can check on this with the `guix gc` tool.

Specifically, like this:

$ guix gc --references $(guix build sbcl-cl-webkit)

That will show you the "store references" of the built sbcl-cl-webkit
package. These store references are strings that refer to files in
/gnu/store, found by scanning the result of building sbcl-cl-webkit. 

These references are recorded in the Guix database at
'/var/guix/db/db.sqlite'.

The built package must keep references to its runtime dependencies, or
they will be subject to garbage collection, and that would represent a
bug in the package definition.

Does that make sense?

bug#47185: grub2 package is vulnerable to CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

[Mark H Weaver]

Hi Léo,

Léo Le Bouter via Bug reports for GNU Guix  writes:
> NOTE: SecureBoot on GNU Guix is not something common at all, so the
> urgency to fix this issue is not as great as if we explicitly
> advertised support for SecureBoot.

I would go further and question whether *anyone* is using SecureBoot
with a Guix system, and moreover whether its feasible to do without
non-trivial development work.

> This looks like a sizeable upgrade to a sensitive part of GNU Guix, so
> we have to test carefully.

Indeed.  I would like to underline this point: GRUB is the only part of
a Guix system that cannot be easily rolled back if it breaks.  If we
make changes to GRUB that causes breakage for some minority of users,
those users could end up with an unbootable system, requiring the use of
a rescue disk to repair.

Therefore, we should be *very* careful about updating our GRUB package,
especially for the sake of bugs that almost certainly do not affect Guix
users.

I think we should refrain from updating GRUB until there's an official
upstream stable release.  Even then, I would advise making an effort to
test it on Guix systems, using several different system configurations,
before pushing it to 'master'.

What do you think?

  Regards,
Mark

bug#47201: sbcl-cl-webkit doesn't protect webkitgtk from garbage collection

[pkill9]

I have nyxt installed, which has sbcl-cl-webkit as an input, which has
webkitgtk as an input, and recently it produced an error which was
fixed by building webkitgtk, so it wasn't in the store.

sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
be, so it seems it's not protected from garbage collection by
sbcl-cl-webkit. Am I wrong in this?

bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

[Mark H Weaver]

Arun Isaac  writes:

>> @Arun, does this sound familiar to you?
>
> Thanks for the bug report! It was indeed a regression in guile-email. I
> have fixed it, and added a test. See
> https://git.systemreboot.net/guile-email/commit/?id=ca0520a33c9042a68691d85c6849f88412ca8357

Thanks to both of you for looking into this!

   Regards,
 Mark

bug#47176: QEMU 5.2.0 doesn't build reproducibly [regression]

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> QEMU 5.1.0 builds reproducibly, but 5.2.0 doesn't.
>
> Here's a summary of the differing files:
>
> Here's a summary of the differing files:
>
> $ diff -r /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0{,-check}
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-aarch64 and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-aarch64 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-aarch64_be 
> and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-aarch64_be
>  differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-alpha and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-alpha 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-arm and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-arm 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-armeb and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-armeb 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-cris and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-cris 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-edid and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-edid 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-ga and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-ga 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-hppa and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-hppa 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-i386 and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-i386 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-img and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-img 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-io and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-io 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-keymap and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-keymap 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-m68k and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-m68k 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-microblaze 
> and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-microblaze
>  differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-microblazeel 
> and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-microblazeel
>  differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mips and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mips 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mips64 and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mips64 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mips64el and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mips64el
>  differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mipsel and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mipsel 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mipsn32 and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mipsn32 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-mipsn32el and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-mipsn32el
>  differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-nbd and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-nbd 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-nios2 and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-nios2 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-or1k and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-or1k 
> differ
> Binary files 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0/bin/qemu-ppc and 
> /gnu/store/l286mbanw78qgbn54gs5j23qm0v9abhw-qemu-5.2.0-check/bin/qemu-ppc 
> differ
> Binary 

bug#47195: xboard: alsa-utils dependency

[Christopher Howard]

xboard package needs to be explicitly dependent on alsa-utils, since it
uses the `aplay' utility to play sounds. I think this maybe wasn't
noticed before because alsa-utils used to be a common part of the
desktop environment.

christopher@nightshade ~$ guix describe
Generation 2Feb 25 2021 21:06:30(current)
  guix 6294299
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 62942992831249d6d1c047c0a11c41d2e4fc

-- 
Christopher Howard
phone: (907) 374-0257 (landline)
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

bug#47192: issues.guix.org not showing patch series?

[Tobias Geerinckx-Rice via web]

OK,

I see that  (I don't 
use emacs-debbugs) has your 2/2 patch.

That rules out mail delivery outages and I was simply unrelatedly unlucky.  :-(

bug#47192: issues.guix.org not showing patch series?

[Joshua Branson via Bug reports for GNU Guix]

Hello!

I just submitted a patch series for an endlessh service!

However, issues.guix.gnu.org/39136 does not properly show the patch
series.  :( Maybe I just submitted the patch series incorrectly.  :)

You can see the patch series here:

https://lists.gnu.org/archive/html/guix-patches/2021-03/msg00672.html

And via

 M-x debbugs-gnu-bugs RET 39136 RET

I'm not certain what the issue is...

This is the command that I used to send the patch series.

#+BEGIN_SRC sh
git send-email --to=39...@debbugs.gnu.org HEAD~2
#+END_SRC

Thanks!

Your friend,

Joshua

bug#47190: Building git fails because of a hash mismatch

[Konrad Hinsen]

Léo Le Bouter  writes:

> Yes, this is fixed by 0ee5d4f7a8e25be437297f88ed7013c4f37abafb, simply
> "guix pull", there's nothing we can do to the older commits.

Thanks for the quick fix, this works fine indeed!

Konrad

bug#47190: Building git fails because of a hash mismatch

[Léo Le Bouter via Bug reports for GNU Guix]

On Tue, 2021-03-16 at 13:57 +0100, Konrad Hinsen wrote:
> With Guix commit (ab9629b7c91ff7d6392a03512cfe44282326), building
> git fails because of a hash mismatch when downloading the man pages
> (see
> log below). 
> 

Yes, this is fixed by 0ee5d4f7a8e25be437297f88ed7013c4f37abafb, simply
"guix pull", there's nothing we can do to the older commits.

I upgraded the git package then fixed the hash of git-manpages as well
(which uses git's version variable, so it makes a cascading change),
but then I forgot to amend my previous commit with the fix and pushed
anyway, then I realized that and made another commit.


signature.asc
Description: This is a digitally signed message part

bug#47188: "guix lint -c cve" does not account for language prefixes (rust-, python-, go-, ..)

[zimoun]

Hi,

On Tue, 16 Mar 2021 at 10:30, Léo Le Bouter via Bug reports for GNU
Guix  wrote:

> ./pre-inst-env guix lint -c cve python-urllib3@1.26.2
> Here this should return at least CVE-2021-28363 but it does not because
> the CVE database contains urllib3 and not python-urllib3 (which AFAICT
> the cve linter searches for).

Does the CVE use the upstream name?  Or a normalized name?

I mean, in the R world, packages can have names as 'org.EcK12.eg.db'
which becomes "r-org-eck12-eg-db".  To easy the mapping for updating
and co, the package definition contains:

(properties
 `((upstream-name . "org.EcK12.eg.db")))

Maybe, it could be worth to have similar things.  WDYT?


All the best,
simon

bug#47190: Building git fails because of a hash mismatch

[Konrad Hinsen]

With Guix commit (ab9629b7c91ff7d6392a03512cfe44282326), building
git fails because of a hash mismatch when downloading the man pages (see
log below). I'd be happy to submit a patch that updates the hash, but
it's perhaps worth figuring out first what went wrong here.

Konrad.


building 
/gnu/store/lml7vf4rqr9g08bkfwbs3hrchv90zvpb-git-manpages-2.31.0.tar.xz.drv...
downloading from 
http://linux-kernel.uio.no/pub/software/scm/git/git-manpages-2.31.0.tar.xz ...
-sha256 hash mismatch for 
/gnu/store/cp276zg8yn1v0psi49d8ivib41cv99ya-git-manpages-2.31.0.tar.xz:
  expected hash: 1aiabqbc6mg23r19g2cwd4iajf55cpkxqylwn14hgpg64piaqr2y
  actual hash:   1v40wwj130k76xf2w6vwhvfpkk765q1gcy5bqcrqssxf66ydqp8q
hash mismatch for store item 
'/gnu/store/cp276zg8yn1v0psi49d8ivib41cv99ya-git-manpages-2.31.0.tar.xz'
build of 
/gnu/store/lml7vf4rqr9g08bkfwbs3hrchv90zvpb-git-manpages-2.31.0.tar.xz.drv 
failed

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Here's another error!

For *this* instance notice the very slow download speed; other downloads got up 
to 2MiB/s.  If my understanding is correct the SJTUG server is effectively a 
caching proxy, meaning that the low download speed here probably means that the 
SJTUG server itself is downloading from the Berlin Cuirass.  As noted before, 
often an issue with using ci.guix.gnu.org is that for large multi-megabyte 
substitutes sometimes the Berlin server will just disconnect and EOF early, so 
I suspect something similar is happening to the SJTUG server.

```
downloading from 
https://mirror.sjtu.edu.cn/guix/nar/lzip/6fa3h0n957hr2nbd05ygjnk4idjq122q-ffmpeg-4.3.2
 ...
 ffmpeg-4.3.2  8.8MiB   
 13KiB/s 
05:05 [###   ]  44.2%
Backtrace:
In guix/store/deduplication.scm:
227:2 19 (dump-file/deduplicate "/gnu/store/6fa3h0n957hr2nbd05y…" …)
In ice-9/ports.scm:
   463:17 18 (call-with-output-file _ _ #:binary _ #:encoding _)
In guix/store/deduplication.scm:
   232:10 17 (_ _)
In guix/serialization.scm:
261:6 16 (dump _)
   247:20 15 (dump # # …)
In unknown file:
  14 (get-bytevector-n! # # 0 #)
In guix/store/deduplication.scm:
   203:22 13 (read! #vu8(85 110 107 110 111 119 110 32 112 105 99 …) …)
In unknown file:
  12 (get-bytevector-n! # # 0 #)
In gcrypt/hash.scm:
   223:13 11 (read! #vu8(85 110 107 110 111 119 110 32 112 105 99 …) …)
In unknown file:
  10 (get-bytevector-n! # # 0 #)
In lzlib.scm:
501:4  9 (lzread! # # …)
In unknown file:
   8 (get-bytevector-n # 65537)
In guix/progress.scm:
   358:30  7 (read! _ _ _)
In unknown file:
   6 (get-bytevector-n! # # 0 #)
In web/response.scm:
 95:2  5 (read! _ _ _)
In ice-9/boot-9.scm:
  1669:16  4 (raise-exception _ #:continuable? _)
  1669:16  3 (raise-exception _ #:continuable? _)
  1764:13  2 (_ #< components: (#<> #<…>)
  1669:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `bad-response' with args `("EOF while reading response body: ~a 
bytes of ~a" (4112173 9196598))'.
Backtrace:
In ice-9/boot-9.scm:
  1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   3 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
In guix/ui.scm:
  2164:12  0 (run-guix-command _ . _)

guix/ui.scm:2164:12: In procedure run-guix-command:
Throw to key `bad-response' with args `("EOF while reading response body: ~a 
bytes of ~a" (4112173 9196598))'.
substitution of /gnu/store/6fa3h0n957hr2nbd05ygjnk4idjq122q-ffmpeg-4.3.2 failed
guix upgrade: error: some substitutes for the outputs of derivation 
`/gnu/store/9xx9kbbjals2y7llhak65fnnyfh9rkyq-gnome-tweaks-3.34.1.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source
```

Thanks
raid5atemyhomework

bug#47189: octave needs to be wrapped with coreutils

[Efraim Flashner]

I tracked down a bug where octave has a function called 'copyfile' which
shells out to call 'cp -r' but in an environment without coreutils, or
when in a script with PATH unset, it fails.

try it out with the following:
touch foo
guix environment --pure --ad-hoc octave-cli -- \
octave --eval 'copyfile("foo","bar");'

-- 
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#47106: Bubblewrap hates Guix containers 

[Leo Prikler]

Hi,
Am Dienstag, den 16.03.2021, 11:54 +0100 schrieb Bengt Richter:
> Hi Leo,
> One more favor? ;)
> 
> On +2021-03-14 19:05:24 +0100, Leo Prikler wrote:
> > Hi again³
> > 
> > Am Sonntag, den 14.03.2021, 18:45 +0100 schrieb Bengt Richter:
> > > Hi again^2,
> > > 
> > > Maybe
> > > pstree -at
> > > would show a little more?
> > sh
> >   |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address
> > 7
> > --sess
> >   |-dbus-launch --autolaunch=fa7a4d52637958ddd37547bb5d8bd9d2
> > --binary-
> > synt
> >   `-screen
> >   `-screen
> >   |-sh
> >   |   `-.epiphany-real
> >   |   |-WebKitNetworkPr 3 21
> >   |   |   |-{BMScavenger}
> >   |   |   |-{ReceiveQueue}
> >   |   |   |-{StorageTask}
> >   |   |   |-{Storage}
> >   |   |   |-{WebStorage}
> >   |   |   |-{background}
> >   |   |   |-{dconf worker}
> >   |   |   |-{erialBackground}
> >   |   |   |-{gdbus}
> >   |   |   `-{gmain}
> >   |   |-bwrap --args 37 --
> > /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
> >   |   |   `-bwrap --args 37 --
> > /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
> >   |   |   `-WebKitWebProces 1277 28
> >   |   |-{.epiphany-real}
> >   |   |-{BMScavenger}
> >   |   |-{HashSaltStorage}
> >   |   |-{IconDatabase}
> >   |   |-{PressureMonitor}
> >   |   |-2*[{ReceiveQueue}]
> >   |   |-{dconf worker}
> >   |   |-{e Compile Queue}
> >   |   |-{ebsiteDataStore}
> >   |   |-{gdbus}
> >   |   |-{gmain}
> >   |   |-{re Remove Queue}
> >   |   `-{tore Read Queue}
> >   `-sh
> >   `-pstree -at
> > > Also,
> > > ls -lr /sys/class/drm
> > total 0
> > -r--r--r-- 1 65534 overflow 4096 Mar 14 17:59 version
> > lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 ttm ->
> > ../../devices/virtual/drm/ttm
> > lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 renderD128 ->
> > ../../devices/pci:00/:00:02.0/:01:00.0/drm/renderD128
> > lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-VGA-1 ->
> > ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-
> > VGA-
> > 1
> > lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-HDMI-A-1 ->
> > ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-
> > HDMI-A-1
> > lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0-DVI-D-1 ->
> > ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-
> > DVI-
> > D-1
> > lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0 ->
> > ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0
> > > if that's accessible -- I'm wondering if the version of screen
> > > in the container is built with libdrm and is bypassing X or ??
> > I doubt it is being built differently than screen normally is.
> > 
> > > Do you have a makefile or a guix something.scm defining
> > > what's built/packed into your container? 
> > Nah, it's a rather ad-hoc definition grown from what should be an
> > Eolie
> > container from the cookbook (also refer to #47097).
> > 
> > guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
> >  --preserve=TERM \
> >  --expose=$XAUTHORITY \
> >  --expose=/etc/machine-id \
> >  --expose=/etc/ssl/certs/ \
> >  --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
> >  --expose=/sys/dev --expose=/sys/devices \
> >  --ad-hoc epiphany nss-certs dbus procps coreutils psmisc
> > screen
> > 
> > Given that I expose most of /sys explicitly, you should take the
> > above
> > with a grain of salt.
> > 
> > > Sorry if my curiosity is making work for you, but I'd like to
> > > try containers down the road -- tho right now I'm taking a break
> > > from events IRL, so I may disappear for a while...
> > I'm not personally impacted by this bug or anything, it's much
> > rather a
> > follow-up to my attempted fix of #47097.  I think there might be
> > some
> > flaw in trying to run a sandbox inside a sandbox (like bubblewrap
> > inside `guix container`), that doesn't actually improve security in
> > any
> > meaningful way.
> > 
> > Regards,
> > Leo
> > 
> 
> If you can run this inside your container, I think it will be
> interesting:
> lsof -U|grep -i wayland
> 
> The above ought to show quickly if wayland is running.
> 
> lsof -U shows the open sockets.
> 
> If the above shows nothing, try
> lsof -U|grep -i x11
> or
> lsof -U|grep X
Nothing showed up for either, but this got me thinking.  Exposing
/tmp/.X11-unix/X1 did do away with the warning, now it's unexposed
dbus, missing icons, etc. etc.  Exposing all of /tmp instead yields 

** (epiphany:2): ERROR **: 11:11:28.855: Failed to start embed shell D-
Bus server on unix:dir=(null): Error binding to address: No such file
or directory

I still 

bug#47106: Bubblewrap hates Guix containers 

[Bengt Richter]

Hi Leo,
One more favor? ;)

On +2021-03-14 19:05:24 +0100, Leo Prikler wrote:
> Hi again³
> 
> Am Sonntag, den 14.03.2021, 18:45 +0100 schrieb Bengt Richter:
> > Hi again^2,
> > 
> > Maybe
> > pstree -at
> > would show a little more?
> sh
>   |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7
> --sess
>   |-dbus-launch --autolaunch=fa7a4d52637958ddd37547bb5d8bd9d2--binary-
> synt
>   `-screen
>   `-screen
>   |-sh
>   |   `-.epiphany-real
>   |   |-WebKitNetworkPr 3 21
>   |   |   |-{BMScavenger}
>   |   |   |-{ReceiveQueue}
>   |   |   |-{StorageTask}
>   |   |   |-{Storage}
>   |   |   |-{WebStorage}
>   |   |   |-{background}
>   |   |   |-{dconf worker}
>   |   |   |-{erialBackground}
>   |   |   |-{gdbus}
>   |   |   `-{gmain}
>   |   |-bwrap --args 37 --
> /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
>   |   |   `-bwrap --args 37 --
> /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
>   |   |   `-WebKitWebProces 1277 28
>   |   |-{.epiphany-real}
>   |   |-{BMScavenger}
>   |   |-{HashSaltStorage}
>   |   |-{IconDatabase}
>   |   |-{PressureMonitor}
>   |   |-2*[{ReceiveQueue}]
>   |   |-{dconf worker}
>   |   |-{e Compile Queue}
>   |   |-{ebsiteDataStore}
>   |   |-{gdbus}
>   |   |-{gmain}
>   |   |-{re Remove Queue}
>   |   `-{tore Read Queue}
>   `-sh
>   `-pstree -at
> > Also,
> > ls -lr /sys/class/drm
> total 0
> -r--r--r-- 1 65534 overflow 4096 Mar 14 17:59 version
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 ttm ->
> ../../devices/virtual/drm/ttm
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 renderD128 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/renderD128
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-VGA-1 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-VGA-
> 1
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-HDMI-A-1 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-
> HDMI-A-1
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0-DVI-D-1 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-DVI-
> D-1
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0
> > if that's accessible -- I'm wondering if the version of screen
> > in the container is built with libdrm and is bypassing X or ??
> I doubt it is being built differently than screen normally is.
> 
> > Do you have a makefile or a guix something.scm defining
> > what's built/packed into your container? 
> Nah, it's a rather ad-hoc definition grown from what should be an Eolie
> container from the cookbook (also refer to #47097).
> 
> guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
>  --preserve=TERM \
>  --expose=$XAUTHORITY \
>  --expose=/etc/machine-id \
>  --expose=/etc/ssl/certs/ \
>  --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
>  --expose=/sys/dev --expose=/sys/devices \
>  --ad-hoc epiphany nss-certs dbus procps coreutils psmisc screen
> 
> Given that I expose most of /sys explicitly, you should take the above
> with a grain of salt.
> 
> > Sorry if my curiosity is making work for you, but I'd like to
> > try containers down the road -- tho right now I'm taking a break
> > from events IRL, so I may disappear for a while...
> I'm not personally impacted by this bug or anything, it's much rather a
> follow-up to my attempted fix of #47097.  I think there might be some
> flaw in trying to run a sandbox inside a sandbox (like bubblewrap
> inside `guix container`), that doesn't actually improve security in any
> meaningful way.
> 
> Regards,
> Leo
> 

If you can run this inside your container, I think it will be interesting:
lsof -U|grep -i wayland

The above ought to show quickly if wayland is running.

lsof -U shows the open sockets.

If the above shows nothing, try
lsof -U|grep -i x11
or
lsof -U|grep X

finally, it is interesting to see
lsof -U|less

but on my laptop I just got
lsof -U|wc
4033760   34643

so its a lot to look at.
Hopefully less in a container ;)

-- 
Regards,
Bengt Richter

bug#47188: "guix lint -c cve" does not account for language prefixes (rust-, python-, go-, ..)

[Léo Le Bouter via Bug reports for GNU Guix]

./pre-inst-env guix lint -c cve python-urllib3@1.26.2
Here this should return at least CVE-2021-28363 but it does not because
the CVE database contains urllib3 and not python-urllib3 (which AFAICT
the cve linter searches for).

Annotating each and every python-, go-, and rust- package with cpe-name 
properties is going to be very annoying. I suggest we add some
heuristics that try both the full name and prefix-trimmed name. python-
urllib3's cpe name and vendor is python (vendor) urllib3 (name).

Same story for CVE-2021-28305 and rust-diesel, though it doesnt even
have a CPE entry yet.


signature.asc
Description: This is a digitally signed message part

bug#47115: Redundant library grafts leads to breakage (was: Failure building grub-img.png when reconfiguring)

[Mark H Weaver]

retitle 47115 Redundant library grafts leads to breakage
thanks

Hi,

I looked a bit deeper, and now I think I finally know what's going on.
It turns out that the grafting process is creating two redundant
variants of the replacement guile-cairo.

All of the relevant information is in
/gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv and its
dependents, which fails to build if deduplication is disabled.

If you look through the output of "guix size
/gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv", you'll
find three distinct guile-cairo derivations:

(1) /gnu/store/vz4yw7zkm73diy95mdzywgixal3nf2s2-guile-cairo-1.11.2.drv,
=> /gnu/store/5nmzfnxk8kp85xwma2r585fgyz3jfw56-guile-cairo-1.11.2
(the original, ungrafted, cairo)

(2) /gnu/store/rcl324yiq7a56rwkqwgqx097dwc5mgni-guile-cairo-1.11.2.drv,
=> /gnu/store/vjn7ygzzqshvsfzck8hq5lp5pfrr2xp5-guile-cairo-1.11.2
(the first graft)

(3) /gnu/store/9mha4bzbji8iql50prmq9br4j1c51sjn-guile-cairo-1.11.2.drv,
=> /gnu/store/j69k9n0g3h9ppqi7dmqypwy3lrhxvb97-guile-cairo-1.11.2
(the second graft)

In the 'guile-builder' files referenced from the two graft derivations,
we see that they have the same inputs and perform the same rewrites, but
list them in a different order.  Graft 1 has this guile-builder:

--8<---cut here---start->8---
(begin
  (use-modules (guix build graft) (guix build utils) (ice-9 match))
  (define %output (getenv "out"))
  (define %outputs (map (lambda (o) (cons o (getenv o))) (quote ("out"
  (define %build-inputs
(quote
 (("x" . "/gnu/store/5nmzfnxk8kp85xwma2r585fgyz3jfw56-guile-cairo-1.11.2")
  ("x" . "/gnu/store/fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10")
  ("x" . "/gnu/store/na0x00biq02fm5cyj5a8r67qwsnsskw8-cairo-1.16.0")
  ("x" . "/gnu/store/cw69is9wbbllwx95wky4pmbcsk4vvbpd-libxrender-0.9.10")
  ("x" . "/gnu/store/qrs0p8j3wq6q5a4dm0ndjdavk9gyal5q-libxext-1.3.4")
  ("x" . "/gnu/store/rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12")
  ("x" . "/gnu/store/p51dv37zj24q8001zghc3wxhxz8i3c50-cairo-1.16.0")
  ("x" . "/gnu/store/pzj036f1nmxdrbza6cqy419ddsn9bydp-libxrender-0.9.10")
  ("x" . "/gnu/store/3rmazp46f6g8w9qs8n3w7qcg8hhs1lig-libxext-1.3.4"
  (unsetenv "GUILE_LOAD_COMPILED_PATH")
  (unsetenv "LD_LIBRARY_PATH"))
(exit
 (begin
   (let* ((old-outputs
   (quote
(("out" . 
"/gnu/store/5nmzfnxk8kp85xwma2r585fgyz3jfw56-guile-cairo-1.11.2"
  (mapping
   (append (quote

(("/gnu/store/fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10"
  . 
"/gnu/store/rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12")
 ("/gnu/store/na0x00biq02fm5cyj5a8r67qwsnsskw8-cairo-1.16.0"
  . 
"/gnu/store/p51dv37zj24q8001zghc3wxhxz8i3c50-cairo-1.16.0")
 
("/gnu/store/cw69is9wbbllwx95wky4pmbcsk4vvbpd-libxrender-0.9.10"
  . 
"/gnu/store/pzj036f1nmxdrbza6cqy419ddsn9bydp-libxrender-0.9.10")
 
("/gnu/store/qrs0p8j3wq6q5a4dm0ndjdavk9gyal5q-libxext-1.3.4"
  . 
"/gnu/store/3rmazp46f6g8w9qs8n3w7qcg8hhs1lig-libxext-1.3.4")))
   (map (match-lambda ((name . file)
   (cons (assoc-ref old-outputs name) 
file)))
%outputs
 (graft old-outputs %outputs mapping
--8<---cut here---end--->8---

Graft 2 has this guile-builder:

--8<---cut here---start->8---
(begin
  (use-modules (guix build graft) (guix build utils) (ice-9 match))
  (define %output (getenv "out"))
  (define %outputs (map (lambda (o) (cons o (getenv o))) (quote ("out"
  (define %build-inputs
(quote (("x" . 
"/gnu/store/5nmzfnxk8kp85xwma2r585fgyz3jfw56-guile-cairo-1.11.2")
("x" . "/gnu/store/na0x00biq02fm5cyj5a8r67qwsnsskw8-cairo-1.16.0")
("x" . "/gnu/store/fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10")
("x" . 
"/gnu/store/cw69is9wbbllwx95wky4pmbcsk4vvbpd-libxrender-0.9.10")
("x" . "/gnu/store/qrs0p8j3wq6q5a4dm0ndjdavk9gyal5q-libxext-1.3.4")
("x" . "/gnu/store/p51dv37zj24q8001zghc3wxhxz8i3c50-cairo-1.16.0")
("x" . "/gnu/store/rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12")
("x" . 
"/gnu/store/pzj036f1nmxdrbza6cqy419ddsn9bydp-libxrender-0.9.10")
("x" . 
"/gnu/store/3rmazp46f6g8w9qs8n3w7qcg8hhs1lig-libxext-1.3.4"
  (unsetenv "GUILE_LOAD_COMPILED_PATH")
  (unsetenv "LD_LIBRARY_PATH"))
(exit
 (begin
   (let* ((old-outputs
   (quote
(("out" . 
"/gnu/store/5nmzfnxk8kp85xwma2r585fgyz3jfw56-guile-cairo-1.11.2"
  (mapping
   (append (quote
(("/gnu/store/na0x00biq02fm5cyj5a8r67qwsnsskw8-cairo-1.16.0"
  . 
"/gnu/store/p51dv37zj24q8001zghc3wxhxz8i3c50-cairo-1.16.0")
 

bug#47123: Quagga source code is gone

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sat, 13 Mar 2021 at 15:37, Ludovic Courtès  wrote:
>>
>> The Quagga tarballs and Git repository on Savannah as linked from
>>  are all 404:
>
> [...]
>
>> I can’t find an alternate hosting site.
>
> We could do the same trick as with other disappeared upstreams:
> convert the package to git-fetch with a temporary Git repo (say GitHub
> or Gitlab) and saved it on SWH.  See gdsl for instance.

Sounds good.  But does the Internet Archive have a copy of this one?

It’s kinda weird that the web page still exists but the Savannah project
doesn’t.  I wonder what happened.

Ludo’.

bug#42174: GNU Icecat showing Github Icons?

[Timmy Douglas]

Ricardo Wurmus  writes:

> I see the same on https://ie.wikipedia.org/wiki/Lewis_Carroll (and other
> pages of the ie.wikipedia.org site), but not on other sites.
>
> I have these fonts installed in my profile:
>
> --8<---cut here---start->8---
> font-wqy-zenhei   0.9.45  out 
> /gnu/store/4666sykl746p9vf4k2vh0nkiw12zjhs5-font-wqy-zenhei-0.9.45
> font-tex-gyre 2.005   out 
> /gnu/store/pyw1h9gh77b1k8wm26vb9qfbk083qkhf-font-tex-gyre-2.005
> font-google-noto  20171025out 
> /gnu/store/g2szydnbvs7qqy2nf7qylba0rapajmd8-font-google-noto-20171025
> font-inconsolata  3.000   out 
> /gnu/store/8vq65z92r51ghnxbgdss9irk23df9s5f-font-inconsolata-3.000
> font-adobe-source-han-sans1.004   out 
> /gnu/store/vravfg76hqm27lrylhc2y44zs1y9zyn2-font-adobe-source-han-sans-1.004
> font-awesome  4.7.0   out 
> /gnu/store/gknn01i1nr80apmcx42w36cqcz3zzri2-font-awesome-4.7.0
> font-google-roboto2.136   out 
> /gnu/store/3mv6bxcvdds1npbg2wf10901xh9y3x03-font-google-roboto-2.136
> font-dejavu   2.37out 
> /gnu/store/7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37
> font-adobe75dpi   1.0.3   out 
> /gnu/store/gypnv4gfdbp44f9zcg2gsij6qlijm3kd-font-adobe75dpi-1.0.3
> font-adobe100dpi  1.0.3   out 
> /gnu/store/nhq03m9x7armfdpyj63hq1lqw82vzxzi-font-adobe100dpi-1.0.3
> font-liberation   2.1.2   out 
> /gnu/store/39j1dcvx5996019dqh9jn8xc0pyg7jb0-font-liberation-2.1.2
> font-gnu-unifont  13.0.05 out 
> /gnu/store/ajnwk1yfdlf4cjgya1laww497q98sqj7-font-gnu-unifont-13.0.05
> font-fira-code5.2 out 
> /gnu/store/k0jya8b6adxymjxpcc2yr4590rwpr1dn-font-fira-code-5.2
> --8<---cut here---end--->8---


I have the same issue--all of icecat's font symbols are github icons.
This machine using guix on ubuntu, and running sway from guix.


/home/timmy [timmy@timmy-4570] [21:39]
> guix package -I
guix1.2.0rc2-1.0d4b1af  out 
/gnu/store/mpwik590jp57d4vw09yigxihb3gnq9a0-guix-1.2.0rc2-1.0d4b1af
hello   2.10out /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10
less563 out /gnu/store/y2w719kd0f8624hccmyq3y1prj1pfapc-less-563
guile   3.0.5   out /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5
i3status2.13out 
/gnu/store/q2giwl9nwhxnaj6cyi00gf92g5aafg9p-i3status-2.13
ccls0.20201025  out 
/gnu/store/kbqwz9x4d5vcy9k7v17353ic0ww1w5lp-ccls-0.20201025
glibc-locales   2.31out 
/gnu/store/f3i89i1j5msqpmdhqyvka4dv766i6vjy-glibc-locales-2.31
screen  4.8.0   out /gnu/store/n70kzschlgcfznra06vc9v5zmr2978ri-screen-4.8.0
coredns 1.8.1-0.78de01a out 
/gnu/store/ibnzjkbqfa1p4vllki3abg18z5qlrq3y-coredns-1.8.1-0.78de01a
git 2.30.1  out /gnu/store/12rngfhsh8kgg3x9nvy28p49wpz2406y-git-2.30.1
nss-certs   3.59out 
/gnu/store/4n222mdzwcibajsgjrpvx3zshqcv8w12-nss-certs-3.59
isync   1.4.1   out /gnu/store/4i3m7nb4m9s9xqw4wph8bqdkp49nnq0x-isync-1.4.1
swaks   20201014.0  out 
/gnu/store/nvhjsgc7ms5aa6r5ddr8s52izwqrws3x-swaks-20201014.0
llvm11.0.0  out /gnu/store/876nbkqqkpcy10md23vp6y6mf38c2rgb-llvm-11.0.0
clang   11.0.0  out /gnu/store/gnvkdq38rx2kgdzmp45dz1n4f5a1pxaw-clang-11.0.0
sway1.5.1   out /gnu/store/4qdxp99anhbwfdaxvz085zyl85kzy64s-sway-1.5.1
icecat  78.8.0-guix0-preview1   out 
/gnu/store/ah7asj0z9hxkl1vwy4lfm99vc16m203v-icecat-78.8.0-guix0-preview1
fontconfig  2.13.1  out 
/gnu/store/y9fdy234r6hqiacd7hgwlmbdsngbp8p1-fontconfig-2.13.1
gs-fonts8.11out 
/gnu/store/hbqlzgd8hcf6ndcmx7q7miqrsxb4dmkk-gs-fonts-8.11
font-gnu-freefont   20120503out 
/gnu/store/pkkwax360gs1dvw2wa5w2kf1mfvxkr2q-font-gnu-freefont-20120503
font-dejavu 2.37out 
/gnu/store/7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37

/home/timmy [timmy@timmy-4570] [21:39]
> fc-cache -rv
/gnu/store/7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37/share/fonts: 
caching, new cache contents: 0 fonts, 1 dirs
/gnu/store/7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37/share/fonts/truetype:
 caching, new cache contents: 22 fonts, 0 dirs
/home/timmy/.guix-profile/share/fonts: caching, new cache contents: 0 fonts, 4 
dirs
/home/timmy/.guix-profile/share/fonts/opentype: caching, new cache contents: 12 
fonts, 0 dirs
/home/timmy/.guix-profile/share/fonts/truetype: caching, new cache contents: 34 
fonts, 0 dirs
/home/timmy/.guix-profile/share/fonts/type1: caching, new cache contents: 0 
fonts, 1 dirs
/home/timmy/.guix-profile/share/fonts/type1/ghostscript: caching, new cache 
contents: 35 fonts, 0 dirs
/home/timmy/.guix-profile/share/fonts/webfonts: caching, new cache contents: 1 
fonts, 0 dirs
/run/current-system/profile/share/fonts: skipping, no such directory
/home/timmy/.local/share/fonts: skipping, no such directory
/home/timmy/.fonts: caching, new cache contents: 6 fonts, 0 dirs

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

[jackhill]

On Mon, 15 Mar 2021, Philip McGrath wrote:


Aha! Running:

   guix environment --ad-hoc --no-grafts racket -- drracket

launches DrRacket just fine.

My guess is that Racket CS is compressing string literals in compiled code. 
Currently, Guix patches Racket source files to include the absolute paths to 
foreign libraries in the store as string literals. There are a bunch of 
grafts for GTK and such: if I'm right, Guix somehow mangles the compiled code 
while attempting to apply the grafts.


I already thought this strategy was a bad idea. If it is really the problem, 
I should be able to patch it fairly quickly: I've already been experimenting 
along these lines.


Aha, that does sound promising. This certinially wouldn't be the only 
grafts corner case:


https://issues.guix.gnu.org/33848
https://issues.guix.gnu.org/30265

Thanks for taking a look,
Jack

bug#47185: grub2 package is vulnerable to CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

[Léo Le Bouter via Bug reports for GNU Guix]

NOTE: SecureBoot on GNU Guix is not something common at all, so the
urgency to fix this issue is not as great as if we explicitly
advertised support for SecureBoot.


signature.asc
Description: This is a digitally signed message part

bug#47186: python2 variants made through (package-with-python2 (strip-python2-variant ...)) don't inherit grafts

[Léo Le Bouter via Bug reports for GNU Guix]

As outlined by:
- 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a01bfa7deed1d556fc75ab5588517442054bc5a9
- 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=db87d6ddafd26c5ad657178cf7fdab524d05c522

Two commits needed to be made to fix the issue both in the python2 and
python3 variants, if the package-with-python2 and strip-python2-variant 
function could make so it inherits grafts it would make grafting python
packages with python2 variants less "forget"-prone.


signature.asc
Description: This is a digitally signed message part

bug#47115: Grafts without deduplication can lead to breakage in Guile (was: Failure building grub-img.png when reconfiguring)

[Mark H Weaver]

retitle 47115 Grafts without deduplication can lead to breakage in Guile
thanks

Hi Jack,

Jack Hill  writes:

> I believe that I have identified the problematic difference in my 
> operating system config between my working and non-working hosts.

Thanks very much for your investigation.

> I am forced to conclude that running the guix-daemon with deduplication 
> disabled causes this build failure. Spooky!

Very interesting!

The only difference deduplication makes is that it (usually) causes
identical files in the store to be hard links to the same inode.

I have a new hypothesis:

Suppose that a reference to the original (ungrafted) version of some
library (e.g. libcairo or librsvg) has survived unchanged by the
grafting process.  This could lead to two copies of the same library
being loaded.  For example, I guess that libcairo is loaded by both
librsvg and by guile-cairo.  One of them might load the original
libcairo, and the other might load the replacement libcairo.

If the library is loaded twice, that could lead to each instance of the
library having its own dynamically-allocated type tags, which could lead
to this kind of error.

Here's the code where the error occurred:

  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/svg.scm?id=bc16eacc99e801ac30cbe2aa649a2be3ca5c102a#n40

Guile uses 'cairo-create' (via guile-cairo) to create a cairo-context,
and then passes it to 'rsvg-handle-render-cairo', a 'librsvg' function,
which complains that the context argument has the wrong type.

If 'guile-cairo' was somehow using a different instance of 'libcairo'
than the one that 'librsvg' is linked to, that could explain what we're
seeing, because the two instances of 'libcairo' would have different
ideas of what the cairo-context tag should be.

However, *if* you have deduplication enabled, and *if* the library in
question doesn't contain any references that require rewrites due to
grafts, then these two copies of the library would most likely[*] be
hard links to the same inode.  Perhaps in that case, the run-time loader
recognizes that these are in fact the same library, and suppresses the
redundant load.

I don't know if this is what's happening, but it seems plausible.
Thoughts?

 Regards,
   Mark

bug#47185: grub2 package is vulnerable to CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

[Léo Le Bouter via Bug reports for GNU Guix]

On Tue, 2021-03-16 at 09:08 +0100, Léo Le Bouter via Bug reports for
GNU Guix wrote:
> There is no new upstream release so patching this appears to be some
> kind of sport.

There seems to be a release candidate available: 
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00219.html


signature.asc
Description: This is a digitally signed message part

bug#47185: grub2 package is vulnerable to CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

[Léo Le Bouter via Bug reports for GNU Guix]

As outlined by 
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021
we have a new wave of GRUB security vulnerabilities around SecureBoot.

There is no new upstream release so patching this appears to be some
kind of sport.

Debian has patched it in this commit: 
https://salsa.debian.org/grub-team/grub/-/commit/37c2a594625efba8b7f10d18a444393982d2e31f

I see also there's a new concept of SBAT section to ease administrative
efforts around certificate revocation when signed binaries such as some
GRUB2 things become vulnerable (and we don't want them to verify
successfully anymore).

This looks like a sizeable upgrade to a sensitive part of GNU Guix, so
we have to test carefully.


signature.asc
Description: This is a digitally signed message part