bug#48007: computing derivations through inferior takes twice as long

Ludovic Courtès writes: > The trick is to ensure the inferior maintains its object cache across > calls. The patch needs to be cleaned up because it peeks into > internals, but we should be able to do something along these lines and > optimize a couple of other things. Yeah, this makes sense.

bug#48007: computing derivations through inferior takes twice as long

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> I tried it in the GWL with the big RNAseq workflow I adopted from PiGx >> and the step to generate job scripts (which reference inferior packages) >> became considerably faster. There is still potential for

bug#53657: inconsistent parsing of the channel sexp's

Thanks for the bug report. I feel like I’m missing something here. > this leads to an actual issue that channel dependencies don't match up, > unless the name is without quotes in the dependencies list > specification. I don’t understand what it means for “channel dependencies” to “match up”. H

bug#53463: ci.guix.gnu.org not building the 'guix' job

Ludovic Courtès writes: > Hi, > > Mathieu Othacehe skribis: > >>> Oh! That indicates that it’s failing to offload to one of the >>> ‘localhost’ build machines specified in /etc/guix/machines.scm. >>> Normally there’s an SSH tunnel set up for those, but I guess it broke. >>> >>> Perhaps we can

bug#53903: aarch64: failed to compute the derivation for Guix

I’m trying but failing to update Guix on the honeycomb machines. I just got this error: --8<---cut here---start->8--- root@grunewald ~# time guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating

bug#53903: aarch64: failed to compute the derivation for Guix

Ricardo Wurmus writes: > I’m trying but failing to update Guix on the honeycomb machines. I just > got this error: […] > > ./guix/store.scm:1421:15: ERROR: > 1. &store-protocol-error: > message: "build of > `/gnu/store/8b6ry6k346yidsvwvhfwyw5ghfn1y8gy-

bug#53903: aarch64: failed to compute the derivation for Guix

Christopher Baines writes: > [[PGP Signed Part:Undecided]] > > Ricardo Wurmus writes: > >> \ 'check' phaseBacktrace: >> 13 (primitive-load >> "/gnu/store/l7rhvfaziri0znvs3jc6khrkxaq9shna-compute-guix-derivation") >> \ 'ch

bug#53903: aarch64: failed to compute the derivation for Guix

Christopher Baines writes: >>> Looks like this derivation can be built at least: >>> >>> >>> https://data.guix.gnu.org/gnu/store/2j5348zpz32qmb7x4v5ipg26d269hgxf-coreutils-8.32.drv >> >> Interesting. I wonder what machine built it; maybe it succeeds in qemu. >> The honeycombs here all canno

bug#53903: aarch64: failed to compute the derivation for Guix

Christopher Baines writes: > Ricardo Wurmus writes: > >>>>>> View build log at >>>>>> '/var/log/guix/drvs/2j/5348zpz32qmb7x4v5ipg26d269hgxf-coreutils-8.32.drv.bz2'. >>>>> >>>>> Would you be able to

bug#53903: aarch64: failed to compute the derivation for Guix

pukkamustard writes: > Ricardo Wurmus writes: > >> [..] >> >>> >>> I tried building it again on the Overdrive machine, and it succeeded. I >>> also tried building it with --cores=1 on the HoneyComb machine and that >>> succeeded too. &g

bug#40558: Modular TexLive "Insufficient extension fonts" and duplicate fonts

I can reproduce this with a simpler document: --8<---cut here---start->8--- \documentclass{article} \usepackage{amsfonts} \begin{document} \begin{equation} x \end{equation} \end{document} --8<---cut here---end--->8--- and

bug#53948: [aarch64] gettext has a failing test

On the Honeycomb machines gettext fails to build because of one failing test. There is no more information other than this: --8<---cut here---start->8--- FAIL: test-select-in.sh === FAIL test-select-in.sh (exit status: 1) --8<--

bug#51224: Cannot login (login screen loop) after some packages are installed

Hi Nikos, my apologies for the long delay. You may have better luck on help-g...@gnu.org; bug-guix@gnu.org is usually for bugs which can be reproduced by others. > I have succesfully installed guix in trisquel 9 (mate). > > I have installed some packages and everything is working as expected. [

bug#40558: Modular TexLive "Insufficient extension fonts" and duplicate fonts

This is now fixed with commit 64fcf9508af318cc2d71811815cfbe99063867b1. The cause: we generated the tfm files from afm and pl files in a misguided attempt to build as many things from “source” as possible. Turns out that this results in bad tfm files. These files mere meant to be installed just a

bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.

Ricardo Wurmus writes: > My guess: the argument is the absolute file name of pdftex.map. It > doesn’t belong to any real package in the tlpdb, and I’m pretty sure we > generate it. However, in this case it must be missing, so that there is > no argument to \strip@prefix. This wa

bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.

Ricardo Wurmus writes: > % This line is new. Set the language! > \usepackage[british]{babel} It is in fact sufficient to add only this line \def\languagename{english} The only problem is that languagename is undefined. -- Ricardo

bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.

Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> % This line is new. Set the language! >> \usepackage[british]{babel} > > It is in fact sufficient to add only this line > >\def\languagename{english} > > The only problem is that languagename is u

bug#54041: cannot load (gnu services virtualization)

When I add (service qemu-guest-agent-service-type) to the list of my services and add (gnu services virtualization) to the imports and then try to build my system configuration I get this error: guix system: error: #< file: "gnu/services/virtualization.scm" line: 893 column: 18>: invali

bug#51317: wishlist: option to not display new packages when list-generations

Looks like newer versions of Guix no longer show the list of new packages. Can this be closed now? -- Ricardo

bug#54041: cannot load (gnu services virtualization)

Ludovic Courtès writes: > Fixed in 01821914e272ed682dc83b5163c17a0345dcaf17. Thank you! -- Ricardo

bug#54181: [aarch64] gnutls-dane fails tests

I tried to build this derivation /gnu/store/6r4y0ni5k1b658mlzr2j5pbzy1d37rq9-gnutls-dane-3.7.2.drv on the honeycomb aarch64 nodes repeatedly, also with --cores=1. Every time this build fails with at least one test failure. There seem to be different tests that fail each time. Here are some:

bug#54181: [aarch64] gnutls-dane fails tests

Ricardo Wurmus writes: > I tried to build this derivation > > /gnu/store/6r4y0ni5k1b658mlzr2j5pbzy1d37rq9-gnutls-dane-3.7.2.drv > > on the honeycomb aarch64 nodes repeatedly, also with --cores=1. Every > time this build fails with at least one test failure. It built fin

bug#54206: [aarch64] kodi fails because of just one test

The build of kodi 18.8 fails to complete on aarch64 because one of 520 tests fails: --8<---cut here---start->8--- [ RUN ] TestCPUInfo.CoreInfo /tmp/guix-build-kodi-18.8.drv-0/source/xbmc/utils/test/TestCPUInfo.cpp:80: Failure Value of: c.m_strModel.empty()

bug#54258: recursive pypi importer prints backtrace when package does not exist

The recursive pypi importer prints a backtrace when a package does not exist: --8<---cut here---start->8--- ./pre-inst-env guix import pypi -r doesnotexist following redirection to `https://pypi.org/pypi/doesnotexist/json/'... Backtrace: In ice-9/boot-9.scm: 1

bug#54259: pypi importer prints backtrace when no source package exists

The only download for the kaleido package on Pypi is a binary. There is no source code on Pypi. The importer recognizes this but then prints a confusing backtrace when attempting to print a hint: --8<---cut here---start->8--- ./pre-inst-env guix import pypi ka

bug#42920: conda 4.8.3 on guix cannot activate environments

zimoun writes: > On Wed, 18 Aug 2021 at 12:07, Ricardo Wurmus wrote: >> We have since upgraded to 4.10.3, but the problems still persist. Conda still >> asks users to run “conda init”, which attempts to run “sudo” to modify >> root-owned files. It’s a big mess. > >

bug#42920: conda 4.8.3 on guix cannot activate environments

Dominic Martinez writes: > [[PGP Signed Part:Undecided]] > >>> On Wed, 18 Aug 2021 at 12:07, Ricardo Wurmus >>> wrote: >>>> We have since upgraded to 4.10.3, but the problems still >>>> persist. Conda still >>>> asks users to ru

bug#54787: importer Bioconductor: no tarball, only Git

zimoun writes: > $ guix import cran -a bioconductor CHETAH > guix import: warning: failed to retrieve package information from > https://cran.r-project.org/web/packages/CHETAH/DESCRIPTION: 404 (Not Found) > guix import: error: failed to download description for package 'CHETAH' > > The reason

bug#54787: importer Bioconductor: no tarball, only Git

zimoun writes: > First, note that annotations do not have Git repo; at least not always, > e.g., > > That’s fine. We just ignore annotation and experiment packages, and use git only for regular packages. >

bug#54787: importer Bioconductor: no tarball, only Git

zimoun writes: > On Thu, 14 Apr 2022 at 13:43, Ricardo Wurmus wrote: > >> We probably should *not* use RELEASE_3_14 (or whatever) as the commit, >> though, because that is a moving target. We need to resolve to the >> actual commit and use its hash. >> >>

bug#55120: “guix import cran” fails for some git repositories

Importing an R package from Git fails: --8<---cut here---start->8--- $ guix import cran -a git -r https://github.com/RubD/Giotto/ Backtrace: In guix/ui.scm: 1347:6 19 (guix-import-cran . _) In ice-9/boot-9.scm: 1752:10 18 (with-exception-handler _ _ #:unwin

bug#55499: excessively large manifests due to propagation

Packages of some languages rely heavily on propagation. R is one example. Since the generated “manifest” file of a Guix profile records entries for all propagated packages, this can get really big really quickly. A profile consisting only of four R packages (r-seurat, r-cistopic, r-monocle3, and

bug#55499: excessively large manifests due to propagation

Ludovic Courtès writes: > Hi! > > Ricardo Wurmus skribis: > >> A profile consisting only of four R packages (r-seurat, r-cistopic, >> r-monocle3, and r-cicero-monocle3) results in a “manifest” file that >> weighs 7.1MB. At the MDC I repeatedly encountered manife

bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.

Lars-Dominik Braun writes: > Hi Ricardo, > > this problem is biting me too now. > >> > % This line is new. Set the language! >> > \usepackage[british]{babel} >> >> It is in fact sufficient to add only this line >> >>\def\languagename{english} >> > This workaround only works fine for scr

bug#55848: [cuirass] workers stalled

Ludovic Courtès writes: > Hi, > > (+Cc: guix-sysadmin) > > Tom Fitzhenry skribis: > >>>From following the builds on http://ci.guix.gnu.org/workers , many >> (all?) builds are failing on the following workers: >> >> * grunewald >> * kreuzberg >> * pankow >> >> The builds are failing with the sa

bug#42148: guix-1.1.0-13.26611f5 fails to build

Closing, because this is no longer relevant. -- Ricardo

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

zimoun writes: > Hi, > > On Wed, 23 Mar 2022 at 23:14, zimoun wrote: > >> Hum, do we keep a report open based on « maybe » or « we don’t know » or >> « I suppose »? It is an honest question and not a rhetoric one. :-) >> >> Well, how is this bug report actionable? Other said, what is missing

bug#56441: guix time-machine broken by profiles speed-up

zimoun writes: > Bug#55499 [1] is fixed by 4ff12d1de7cd617b791996ee7ca1240660b4c20e. > However, because the manifest version is going from 3 to 4 with new > fields, the new Guix cannot builds the old Guix. > > Commit 4ff12d1de7cd617b791996ee7ca1240660b4c20e is not able to go to its > parent 9b8

bug#56441: guix time-machine broken by profiles speed-up

Ricardo Wurmus writes: > zimoun writes: > >> Bug#55499 [1] is fixed by 4ff12d1de7cd617b791996ee7ca1240660b4c20e. >> However, because the manifest version is going from 3 to 4 with new >> fields, the new Guix cannot builds the old Guix. >> >> Commit 4ff12d1

bug#56441: Time travel doesn't resist profile format changes

ood to me. It’s a pragmatic, minimally invasive fix, so thumbs up emoji from me! Thank you! -- Ricardo >From da3eaeea0d0082138284720dce60f6bdfc796f2b Mon Sep 17 00:00:00 2001 From: Ricardo Wurmus Date: Fri, 8 Jul 2022 08:40:27 +0200 Subject: [PATCH] channel stuff --- guix/channels.sc

bug#50841: rstan needs gfortran 9+

Hi, thank you for your bug report! > You find a related error if you try install.packages("isoband"), which could > work as a test case: > > /gnu/store/741057r2x06zwg6zcmqmdyv51spm6n9i-gfortran-7.5.0-lib/lib/libstdc++.so.6: > version > `GLIBCXX_3.4.26' not found (required by > /home/kept/Dotfil

bug#50477: herd can't connect to socket on GNU/Hurd: Connection refused

Hi, ping not working inside qemu is a frequently encountered problem. See also the Hurd wiki: […] note that ping doesn't work with QEMU's user-networking stack. https://www.gnu.org/software/hurd/hurd/running/qemu.html > root@guixygnu ~# herd status loopback > error: connect: /var/run/shepher

bug#39885: Bioconductor URI, fallback and time-machine

zimoun writes: > At the cost of more bandwidth, we could switch from url-fetch to > git-fetch. Let’s do it! I’m tired of Bioconductor archive shenanigans messing with package availability. -- Ricardo

bug#56667: test failures tests/channels.scm and tests/texlive.scm

Ludovic Courtès writes: > Hi, > > Chris Keschnat skribis: > >> FAIL: tests/texlive >> === >> >> (package (inherit (simple-texlive-package "texlive-texsis" (list >> "bibtex/bst/texsis/" "doc/man/man1/" "doc/otherformats/texsis/base/" >> "tex/texsis/base/" "tex/texsis/config/") (

bug#57089: r-rmarkdown contains minified JavaScript

r-rmarkdown contains a lot of minified JavaScript. It is not immediately obvious, where the corresponding source code could be found: --8<---cut here---start->8--- rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/prettify/prettify.js: ASCII text, with very long

bug#55848: AArch64 honeycomb machines aren’t building stuff

Hi, Ludovic Courtès writes: > Ludovic Courtès skribis: > >> guix-daemon is configured to use the default substitute URLs, >> https://ci.guix.gnu.org and https://bordeaux.guix.gnu.org, which we know >> are unreachable. >> >> I’ve theoretically addressed this here: >> >> >> https://git.savanna

bug#39885: Bioconductor URI, fallback and time-machine

Ricardo Wurmus writes: > zimoun writes: > >> At the cost of more bandwidth, we could switch from url-fetch to >> git-fetch. > > Let’s do it! I’m tired of Bioconductor archive shenanigans messing with > package availability. I have finally taken the time to review

bug#57210: reproducibility: r-bgx tests CPU at configure time

The r-bgx package tests the CPU of the build node to determine whether to use -march options. On my laptop it does not, but on berlin it adds -march=k8 to the compiler options. This is due to AX_GCC_ARCHFLAG. -- Ricardo

bug#57210: reproducibility: r-bgx tests CPU at configure time

Fixed with commit 593327ef5b506f031d75349fdcda1ad04e6684ed. -- Ricardo

bug#57501: call-with-file-lock does not remove lock file

“call-with-file-lock” and “call-with-file-lock/no-wait” create a lock file but don’t remove the lock file when they exit. (guix build syscalls) defines these procedures with “dynamic-wind” so that the lock is always lifted with “unlock-file”. While “unlock-file” uses the fcntl syscall to remove t

bug#57775: guix shell --root fails

This fails on the first try: --8<---cut here---start->8--- $ guix shell -D -f guix.scm --root=env-test Backtrace: 10 (primitive-load "/home/rekado/.config/guix/current/bin/guix") In guix/ui.scm: 2238:7 9 (run-guix . _) 2201:10 8 (run-guix-comman

bug#57077: guix-jupyter fails a test

Unfortunately, guix-jupyter still fails to build for me as of commit 29d52a56f2d254781b65dbec0f1009db0b9d06e6. --8<---cut here---start->8--- == Guix-Jupyter 0.2.2: ./test-suite.log ==

bug#57853: “inappropriate ioctl for device” when running in RStudio Server

When running “guix” in RStudio Server the “terminal-window-size” procedure triggers an error. (You can ignore the cause of the error, because I’m running this in a container where /var/guix/profiles/per-user/rekado doesn’t exist.) --8<---cut here---start->8---

bug#42141: blast+ is not reproducible

reopen 42141 thanks Maxim Cournoyer writes: > Hi, > > Ricardo Wurmus writes: > >> This should be rather easy to fix: >> >> diff -r >> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include >> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blas

bug#42141: blast+ is not reproducible

Ricardo Wurmus writes: > reopen 42141 > thanks > > Maxim Cournoyer writes: > >> Hi, >> >> Ricardo Wurmus writes: >> >>> This should be rather easy to fix: >>> >>> diff -r >>> /gnu/store/3y97kfanv9ynxnahyykixchlbpb

bug#42141: blast+ is not reproducible

Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337. -- Ricardo

bug#42141: blast+ is not reproducible

Maxim Cournoyer writes: > Ricardo Wurmus writes: > >> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337. > > Yay! Thank you! And for my curiosity, how did I get the two build > farms to agree on an identical build, as reported in 'guix challenge'? >

bug#42141: blast+ is not reproducible

zimoun writes: > Hi, > > On Thu, 29 Sep 2022 at 23:09, Maxim Cournoyer > wrote: >> Ricardo Wurmus writes: >> >>> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337. >> >> Yay! Thank you! And for my curiosity, how did I get the two buil

bug#58149: Unable to pull when using a pre-lzip version of guix-daemon

I’d just like to note what I do when I’m finding myself in a situation where I’m tempted to run “guix pull” from a very old version of Guix: 1. visit https://ci.guix.gnu.org and select the “guix” jobset. 2. select a recent successful evaluation, e.g. https://ci.guix.gnu.org/eval/686692 3. select

bug#58308: guix import -r swallows errors

Consider this: $ ./pre-inst-env guix import elpa -r syslog $ echo $? 0 And now this: $ ./pre-inst-env guix import elpa syslog guix import: error: failed to download package 'syslog' $ echo $? 1 The recursive importer swallows the error. -- Ricardo

bug#58333: Manual PDFs other than en and es fail to build

The error in guix.de.texi is an infinite loop. The location it points out is wrong syntax: @uref{@uref{https://webssh.huashengdun.org/, WebSSH}} There shouldn’t be a double-wrapping in @uref. -- Ricardo

bug#58333: Manual PDFs other than en and es fail to build

The first error in guix.fr.texi is encountered here: --8<---cut here---start->8--- Overfull \hbox (31.11255pt too wide) in paragraph at lines 26508--26508 []@deftt getmail-retriever-configuration[] | Runaway argument? 1 @advance @rightskip by 0pt plus 1fil@

bug#58333: Manual PDFs other than en and es fail to build

Ricardo Wurmus writes: > The error in guix.de.texi is an infinite loop. The location it points > out is wrong syntax: > > @uref{@uref{https://webssh.huashengdun.org/, WebSSH}} > > There shouldn’t be a double-wrapping in @uref. I can confirm that fixing the bad translat

bug#58333: Manual PDFs other than en and es fail to build

With these two changes I can build both German and French PDF manuals: diff --git a/po/doc/guix-manual.de.po b/po/doc/guix-manual.de.po index edbe853248..cd7eff86f5 100644 --- a/po/doc/guix-manual.de.po +++ b/po/doc/guix-manual.de.po @@ -38181,7 +38181,7 @@ msgstr "{Scheme-Variable} webssh-service

bug#58333: Manual PDFs other than en and es fail to build

Julien Lepiller writes: > You can push this fix directly to the repo, but please also fix it on > weblate or it'll break again next time I update translations. I pushed the fix and made a change in the German translation on weblate; the change for the French translation had already been made o

bug#28240: bad backtrace on “guix archive -x”

zimoun writes: >> guix archive: error: corrupt input while restoring '/tmp/ci' from #> file 0> > > The situation is still the same. Well, is the “guix archive” error the > point of this bug report? The point is the terrible backtrace. While this error is a little better it’s also not great.

bug#58878: build log filter broken by odd characters in build output

Here I am, minding my own business, building GHC 6.10.4 with GHC 6.6 and I see this in the build output: --8<---cut here---start->8--- /gnu/store/km47738v7q4qgym9zkggngqxr05q165h-ghc-6.6/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.4 -hide-all-pa

bug#59185: Trouble mounting recursive file systems in containers

00:00:00 2001 From: Ricardo Wurmus Date: Sat, 19 Nov 2022 23:16:52 +0100 Subject: [PATCH] WIP --- gnu/build/file-systems.scm | 2 +- guix/build/syscalls.scm| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm in

bug#59185: Trouble mounting recursive file systems in containers

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> yes, mounting with MS_REC seems sensible. Not mounting with MS_REC is >> also responsible for a couple of errors e.g. when trying to map / inside >> the container (when / has other bind mounts). > > Having

bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux

I tried building with ld-gold-wrapper, but it didn’t fix it: --8<---cut here---start->8--- ld: /tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o: warning: relocation against `_ZThn20_N4cp

bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux

I applied this patch: https://bug-attachments.documentfoundation.org/attachment.cgi?id=172646 And the error changed: --8<---cut here---start->8--- ld: /tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/xmloff/source/core/xmlim

bug#58690: [PATCH] gnu: emacs-ess: Update to 18.10.2-1.01e7f5b.

* gnu/packages/statistics.scm (emacs-ess): Update to 18.10.2-1.01e7f5b. [source]: Update snippet; remove patch. [arguments]: Use gexp; add phase "patch-test-suite"; run tests conditionally. [inputs]: Drop package labels. * gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch: Remove fil

bug#47739: Mumi: sorting the list of issues by date

This is now fixed in mumi commit 4361d69de393a55ad27574d10d7c6ad62477a13e. -- Ricardo

bug#48160: Mumi renders huge messages

This is now fixed with mumi commit ca4d83865943f2851b07deaf34b026705c46dd41. The problem here was that the attachment did not come with a content-disposition header reporting the size of the attachment. As a fall back mumi now also looks at the actual size of the message when determining whether

bug#41906: [mumi] Raw mailbox download not usable with mutt

Commit 0a90eeda9b5e12a2f83e3917c46fa539f308d0c8 fixes this. Debbugs apparently stores the raw email with the first two lines swapped. I just swap the two lines back. The output from mumi’s /raw endpoint now only differs in trailing white space. -- Ricardo

bug#47520: mumi: wrong message is downloaded

I cannot reproduce this with the current version of mumi. https://issues.guix.gnu.org/47513#3 points to the restinio email, and the download links fetch the corresponding email / message parts. -- Ricardo

bug#49115: Mumi inserts spurious underscore in bug title

> See http://issues.guix.gnu.org/49114, which Mumi currently > titles > > ‘guix_ lint’ should catch certificate validation exceptions > > There's no underscore in the original subject. The debbugs “.log” file for issue 49114 contains this line: Subject: bug#49114: =?UTF-8?Q?=E2=80=98guix_?=

bug#55120: “guix import cran” fails for some git repositories

This has been fixed in the meantime. If you still have this problem you may need to remove your git checkout cache in ~/.cache/guix/checkouts. -- Ricardo

bug#57775: guix shell --root fails

I can no longer reproduce this. -- Ricardo

bug#54206: [aarch64] kodi fails because of just one test

This is still a problem as of Guix commit e84f17ea939013f25a0dd1276659e27bc4c2198f. I’ll try upgrading Kodi to 19.5. There have been a few changes with regard to the CPUInfo code. -- Ricardo

bug#49115: Mumi inserts spurious underscore in bug title

Hi Arun, > Thanks for the bug report! > > It's very strange, but I'm not able to reproduce this. Thank you for your analysis! > Even at https://issues.guix.gnu.org/49114 , only the "bug title" has the > spurious underscore. The subject of the first message does not. Is the > bug title somethin

bug#49115: [PATCH 1/1] debbugs: Do not check for MIME encoded words in subject.

Arun Isaac writes: > guile-email transparently handles MIME encoded words. We do not have > to check for them. > > * mumi/debbugs.scm (bug-status): Do not check for MIME encoded words > in subject. Thank you, I applied it. -- Ricardo

bug#60608: keras is broken –> package bazel?

We have an old version of keras. This is now broken. It is not compatible with python-h5py > 2.10. Our version of Tensorflow also won’t work with h5py 3. We can’t upgrade keras to anything above 2.2.5 because any later version is built with Bazel. We cannot build Bazel, because it needs a big

bug#60719: [aarch64] grub-efi cannot be built because of qemu changes

Ricardo Wurmus writes: > commit 71b8707100e2fbc00f123566717ba3958c6afabb seems to have broken > reconfiguration of my aarch64 machine. See also https://issues.guix.gnu.org/60719 -- Ricardo

bug#60946: java-logback-classic fails to build

Hi, I applied the patch and pushed commit 0d169401cbc9e1a418290d4d6cb03dac8babcde3. -- Ricardo

bug#47985: CentOS : SELinux is preventing /usr/lib/systemd/systemd from read access on the lnk_file current-guix

Hi, the cil file has been updated to work with a more recent base policy as provided by current Fedora releases. We also updated the documentation to make the relabeling step a little clearer. Does this solve your problem? -- Ricardo

bug#61795: “guix deploy” doesn’t build all derivations remotely

I’m running “guix deploy deploy.scm” on a x86_64 host. The deploy.scm file looks like this: deploy.scm Description: Binary data The target machine architecture is aarch64-linux, and the x86_64 host cannot offload to any aarch64-linux machines. The machine declaration has the “build-locally?”

bug#61902: r-maaslin2 is not reproducible

The r-maaslin2 package builds example plots in PNG and PDF format. The scatter plots and box plots are not reproducible as the points are not plotted in deterministic order. -- Ricardo

bug#62280: r-learnr contains minified JavaScript

The r-learnr package contains minified JavaScript files that need to be minified from source: learnr/inst/lib/tutorial/tutorial.js learnr/inst/lib/i18n/i18next.min.js learnr/inst/lib/i18n/tutorial-i18n-init.js learnr/inst/lib/i18next/i18next.min.js learnr/inst/lib/ace/ace.js

bug#55013: Guix-emacs doesn't work

Hi, this no longer seems to be a problem. Can you please confirm that this issue can be closed now? -- Ricardo

bug#55013: Guix-emacs doesn't work

Hi Giovanni, thank you for testing. Can you please confirm that this is reproducible even in “guix shell -C”? -- Ricardo

bug#55013: Guix-emacs doesn't work

Ryan Prior writes: >> this no longer seems to be a problem. Can you please confirm that this >> issue can be closed now? > > I can confirm that the emacs-guix package is still broken. > > ## Steps to reproduce > 1. launch Emacs in a container: > $ guix shell -C --no-cwd --expose=/gnu --expose

bug#62493: xelatex won't render fonts correctly without full texlive

FWIW, it does work with lualatex: guix shell --container texlive-base texlive-fontspec -- lualatex test.tex -- Ricardo

bug#62493: xelatex won't render fonts correctly without full texlive

We seem to be missing the xetex package that provides files for font mapping: --8<---cut here---start->8--- $ info tex-text.tec tlmgr.pl: cannot find package tex-text.tec, searching for other matches: Packages containing `tex-text.tec' in their title/descript

bug#62493: xelatex won't render fonts correctly without full texlive

John Kehayias writes: > Exported revision 59745. > svn: E160013: File not found: revision 66702, path > '/tags/texlive-2021.3/Master/texmf-dist/tcode' > command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" > "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-

bug#62493: xelatex won't render fonts correctly without full texlive

John Kehayias writes: > "Ricardo Wurmus" writes: > >> John Kehayias writes: >> >>> Exported revision 59745. >>> svn: E160013: File not found: revision 66702, path >>> '/tags/texlive-2021.3/Master/texmf-dist/tcode' >>>

bug#62972: rseqc installs __pycache__ directory to $out/bin

The rseqc package installs a __pycache__ directory to the bin directory. -- Ricardo

bug#63471: python-pytorch has bogus version string

The wheel generated for python-pytorch embeds a bad version string: … Building wheel torch-1.13.0a0+gitUnknown … This lets the version check in downstream packages fail. -- Ricardo

bug#63507: [mumi] /recent causes crash

Visiting issues.guix.gnu.org/recent leads to this crash: --8<---cut here---start->8--- 2023-05-14 23:11:35 GET /recent 2023-05-14 23:11:35 In mumi/web/server.scm: 2023-05-14 23:11:35 35:9 95 (handler _ _) 2023-05-14 23:11:35 In mumi/web/controller.scm: 2023

bug#63529: awscli doesn’t use global certificate store on foreign distro

On a foreign distro, awscli does not use the global certificate store. It seems to only use certifi.pem from the python-certifi package. There seems to be no way to override the certificate store. This makes awscli unusable on foreign distros. -- Ricardo

  1   2   3   4   5   6   7   8   9   10   >