Hi Gábor,
>> So, with the following change I was able to build all the way up to the
>> latest openjdk. Should we use it despite the introduction of a memory
>> leak in a bootstrap JVM? Can we make the patch smaller (fewer uses of
>> glibc 2.28 or gcc-5)?
>>
>> What do you think?
>>
>
> I
Raghav Gururajan writes:
> I still suggest that there should be a default/fallback option for
> this. After reviewing guix repository, I found pinentry, emacs-
> pinentry, pinentry-tty, pinentry-qt, pinentry-gtk2, pinentry-gnome3,
> pinentry-emacs and pinentry-efl, as available pinentry
Raghav Gururajan writes:
>> Is there a good
>> reason not to include pinentry-tty or somemthing similarly small?
>
> It appears pinentry-tty is only console-based. If graphical
> applications like MUA, Key Managers etc require pinentry-program, it
> usually uses pop-up (gui) for passphrase
Mark H Weaver writes:
> Unfortunately, I'm unable to get *any* information about what went wrong
> from Cuirass. None of the failed builds have associated log files, and
> the build details page has no useful information either. For example:
>
>
Tobias Geerinckx-Rice writes:
> Ricardo,
>
> Ricardo Wurmus 写道：
>> For the time being you can do
>>
>> git clone https://guix.gnu.org/git/guix
>>
>> which is a read-only copy of my clone of the repository. I’d like
>> to
>> make it automat
Nome Grey writes:
> Just to note it somewhere, the 500 errors are back.
I can’t reproduce this, but I do see that there are quite a lot of
connections that make it difficult for the server to serve all requests.
This segfaults:
sudo /gnu/store/yzxyxnxja4y1riwh3mrqrvb7h4vhxlqb-gparted-1.0.0/bin/gparted
--8<---cut here---start->8---
…
(gpartedbin:5364): Gdk-CRITICAL **: 11:06:10.219:
gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
Arne Babenhauserheide writes:
> Previously I got it working with the following setup:
>
> cd $HOME/Downloads/firefox
> export
>
Raghav Gururajan writes:
> When I launch gajim via terminal, I get the following errors.
>
> *** START ***
>
> No translations found
This is now fixed with commit 343f5efbc3. Thanks for the report!
--
Ricardo
Hi Nome Grey,
> I'm trying to access https://issues.guix.gnu.org/issue/26608 and
> https://issues.guix.gnu.org/issue/32022, which I found from google, and
> both of them are just giving 500.
this is now fixed.
Unfortunately, Mumi (the software behind issues.guix.gnu.org) is still
rather slow
Hi Clément,
> Would it be possible to have an *official* backup Git repository hosted
> somewhere else (like Github, or whatever), where we could redirect users
> when they encounter issues?
For the time being you can do
git clone https://guix.gnu.org/git/guix
which is a read-only copy of
Bengt Richter writes:
> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d
> '-' -f5,6,7,8|less|uniq -c|less
> --8<---cut here---start->8---
> 1 x
> '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
>
Jesse Gibbons writes:
> I need python-scikit-learn for an ai project.
>
> "guix build python-scikit-learn"
> ...
> build of /gnu/store/wymxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-learn-
> 0.20.3.drv failed
> View build log at '/var/log/guix/drvs/wy/mxdfygbzij8hbz4gqkrwnb3jkicx76-
>
Jesse Gibbons writes:
> On Fri, 2019-10-11 at 10:42 -0600, Jesse Gibbons wrote:
>> I need python-scikit-learn for an ai project.
>>
>> "guix build python-scikit-learn"
>> ...
>> build of /gnu/store/wymxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-learn-
>> 0.20.3.drv failed
>> View build log at
Ludovic Courtès writes:
> We’re getting a hash mismatch for Yoshimi and ci.guix.gnu.org doesn’t
> have it in cache: […]
> Ricardo or anyone who might have the previous Yoshimi tarball, could you
> take a look?
I ran guix gc earlier today, so I no longer have the tarball :(
It’s a new
I recently built an installer image from a few commits before
4e09f57af8ee9ac3e7bd5a7a904c4cb6d8d44d9d. It boots fine and the
installer works up to the actual system installation, which then aborts
with an error indicating that the file
python-pep8-stdlib-tokenize-compat.patch could not be found.
When I first tried to install one of the new build servers for
ci.guix.gnu.org I forgot that the firewall rules prevent these servers
from accessing ci.guix.gnu.org via its public IP address. I started the
installation process and waited …
When I realized that I had to first add the internal IP
Konrad Hinsen writes:
>> Maybe I miss a point. It is not: "watch out, this will do something
>> else in the future" but "watch out, this was doing something else in
>> the past and the change happened the in ".
>
> Concrete example: I am writing a tutorial about using Guix for
> reproducible
zimoun writes:
> - I propose the name "guix shell"
This is not a bad idea, especially considering that “guix environment”
was meant to get shebang support, so that you could use it as the
interpreter in a script that handles the environment configuration.
It is also shorter.
--
Ricardo
When the target machine has no signing keys (generated with “guix
archive --generate-key”) the source machine issuing “guix offload test”
will print this confusing error message:
guix offload: error: implementation cannot deal with > 32-bit integers
--
Ricardo
zimoun writes:
> Then you ask one question: "Should Guix be volatile software?" with
> the subtitle "Software developers should avoid traumatic changes".
> Nothing more.
> Well, I answer you by trying to fill the gap. Note that "volatile
> software" is the same argument than the Ludo's concern
On the core-updates branch texlive-luatex-luaotfload fails to build:
--8<---cut here---start->8---
starting phase `build'
make[1]: Entering directory
'/tmp/guix-build-texlive-luatex-luaotfload-2.8-fix-2.drv-0/source/doc'
creating file graph (filegraph.pdf)
Pierre Neidhardt writes:
> swedebu...@riseup.net writes:
>
>> Reason: it is used standalone to convert between formats.
>
> I agree. What do other people think?
I agree.
We should also rename all uses of ghc-pandoc in the same patch.
--
Ricardo
Damien Cassou writes:
> $ ./pre-inst-env guix build emacs
[…]
> no code for module (gcrypt hash)
pre-inst-env modifies the GUILE_LOAD_PATH to put the Guix modules from
the current directory first. It does not, however, arrange for all
dependencies to be placed on GUILE_LOAD_PATH.
You are
This should now be fixed with commit
70b74663b64a65f142b3aac8c79d952d96480008.
--
Ricardo
Since the upgrade to Guile 3.0 I can no longer upgrade my profile. The
module-import-compiled derivation can no longer be built. It fails with
a backtrace involving only Guile modules, no Guix modules.
The error is:
ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
re-exporting
Closing after reverts by Marius.
--
Ricardo
The following packages have duplicate definitions:
python-pathtools
python-iocapture
python-argh
--
Ricardo
This happens even after a reboot, so that’s reassuring.
This is tied to building the derivation for the “sicp” package, which
has this arguments field:
(arguments
`(#:modules ((guix build utils)
(srfi srfi-1)
(srfi srfi-26))
Hi David,
> Tried to install artanis today. It's kida ok to have conflicting package
> but maybe not with guix itself? Not sure whether it's an issue to
> address.
Whenever there are conflicts you should do as the hint says and upgrade
packages together. Not doing so would result in a mixed
Gábor Boskovits writes:
> 5. create a file gexp.scm with this content:
> (use-modules
> (gnu packages package-management)
> (guix gexp))
>
> (program-file
> "a"
> (with-extensions
> (list guix)
> #~(#t)))
> 6. guix build -f gexp.scm
>
> This will fail with as strange error message.
Hi Florian,
> I'm the upstream author of qutebrowser - it looks like Guix currently packages
> qutebrowser 0.11.0: https://guix.gnu.org/packages/qutebrowser-0.11.0/
>
> That version is very outdated (July 2017, there have been 28 new releases
> since
> then).
The qutebrowser package has been
Ludovic Courtès writes:
> Hi Matt,
>
> Matt Wette skribis:
>
>> I'm trying to get guix-1.0.1 running on Fedora-30 with its default
>> SElinux set up.
>> I found (hint from
>> https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00109.html)
>> that the guix-daemon.cil file seems to be
Mikhail Kryshen writes:
> - font files are missing from texlive-latex-lh (shouldn't it be called
> texlive-lh?).
Thank you, that’s a good one. Generally, the texlive-latex-* packages
are of the old type that may very well be incomplete. I’ll replace this
one with texlive-lh which will
Hi Marco,
> I am unable to use LaTeX and friends. I get this error:
Hmm, something broke here. I also cannot compile my older documents any
more. I’ll investigate.
> Can I do something to test the more modular set-up of TeX Live?
I’m only using the modular set up and it appears to suffer
Ricardo Wurmus writes:
> texlive-latex-base provides ltluatex.lua. This file is generated from
> ltluatex.dtx.
>
> ltluatex.dtx contains literal tabs in the embedded Lua sources. Upon
> unpacking the dtx file to generate the file ltluatex.lua these tabs are
> err
texlive-latex-base provides ltluatex.lua. This file is generated from
ltluatex.dtx.
ltluatex.dtx contains literal tabs in the embedded Lua sources. Upon
unpacking the dtx file to generate the file ltluatex.lua these tabs are
erroneously converted to the string “^^I”, which breaks the lualatex
How to reproduce:
$ guix install itk-snap
$ itksnap
Segmentation fault
dmesg|tail shows that the segfault happens in libjsoncpp.so.1.7.3.
--
Ricardo
Pierre Neidhardt writes:
> So what shall we do? Build perl-gtk2 against the previous version of
> gdk-pixbuf?
> And ask upstream if this is a known issue?
The developers of youtube-viewer are aware of this and plan to drop the
dependency on perl-gtk2 (moving to gtk3), but this takes time.
I regularly run this command:
./pre-inst-env guix refresh -t cran,bioconductor -u
This makes a lot of HTTP requests to check for updates. It often aborts
with this error before it can finish checking for updates of all
packages:
guix refresh: error: open-file: Too many open files:
Ludovic Courtès writes:
> Maybe “union”, “surround”, or… “profile”?
“profile” is a tempting choice, but it’s treacherous because we might be
blinded by the glow of the implementation of environments as volatile
profiles. On the other hand: if we could also move some of the features
of the
Although ibus-libpinyin is installed and IBUS_COMPONENT_PATH is set to
include the location of its XML file, libpinyin cannot be selected as an
input method in ibus-setup.
--
Ricardo
This does work after all. The thing to note here is that Gnome
integrates ibus, so the manual use of ibus-daemon and ibus-setup is not
guaranteed to work when using Gnome.
Instead the Region settings should be used. It is important to remove
any residual ibus state, including the ibus registry
Leo Prikler writes:
> the culprit is probably hicolor-icon-theme. Adding it to your user
> profile should fix the icons as a temporary workaround.
I’ve seen the same problem and found that installing hicolor-icon-theme
fixes it. (I installed it in the system profile.)
--
Ricardo
Christopher Baines writes:
>> Could it be that the reference to guile-email in the version field of
>> mumimu created this issue?
>> --8<---cut here---start->8---
>> (version (git-version (package-version guile-email) revision commit))
>>
Icecat retains a reference on clang. This is because the file
./chrome/toolkit/content/global/buildconfig.html (inside of
lib/icecat/omni.ja) records configuration options, which include the
location of clang.
This should be removed.
--
Ricardo
This should do the trick:
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index d5d9839e1a..e9458037a5 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -1023,7 +1023,11 @@ from forcing GEXP-PROMISE."
(format #t "configure flags: ~s~%"
zimoun writes:
>> > Why do you say that "guix shell" does not reflect what the command is
>> > about?
>> > Because the command spawns a new shell with options (expanding it,
>> > isolating it, etc.)
>>
>> The command does not necessarily spawn a new shell; it spawns a command
>> in a
Hi Matthew,
> I have a pair of Bluetooth headphones that I I've paired and connected to
> my guix machine. They show up in the 'configuration' tab of
> pavucontrol. By default the profile is 'Headset Head Unit (HSP/HFP)'.
>
> When I try and change the profile to 'High Fidelity Playback (A2DP
Ludovic Courtès writes:
> Hello,
>
> Just a note for later…
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> With the quick-hack libgit2 bindings attached, I can run this program,
>> which authenticates HEAD:
>
> [...]
>
>> So I think we can go from here. Our repo would contain a Scheme list
Hi Ludo,
> I’ve now committed this file:
>
> b3011dbbd2 doc: Mention "make authenticate".
> 787766ed1e git-authenticate: Keep a local cache of previously-authenticated
> commits.
> 785af04a75 git: 'commit-difference' takes a list of excluded commits.
> 1e43ab2c03 Add
Ludovic Courtès writes:
> The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb
> makes things acceptable: the first “make authenticate” run takes a bit
> more than two minutes to check all the commits starting from ‘v1.0.1’,
> but subsequent runs take a few seconds.
This sounds
Sergiu Marton writes:
> I have mpv installed, which depends on rsound, which, in turn, depends
> on portaudio. Since my last guix pull, portaudio fails to build - it
> fails during the build phase. I attached the build log. I tried
> reading it, but I don't know what to make of it.
I have
Ludovic Courtès writes:
> Maxim Cournoyer skribis:
>
>>> So that means that rpc.mountd “daemonizes”. Thus, shepherd shouldn’t
>>> look at the PID of the process it spawns, but rather at what
>>> rpc.mountd’s PID file contains (I assume it creates a PID file,
>>> right?). IOW, we need to
I added a new script “media type” in Zabbix and specified that the
script to be run should be /srv/my-script.
When testing an action for this media type, Zabbix attempts to find the
script in the /share/zabbix/alertscripts directory of the zabbix-server
package:
Cannot execute command
The location can be overridden with the AlertScriptsPath configuration
option in the server settings.
The default is a sub-directory in the pkgdatadir, which doesn’t make
sense for Guix.
--
Ricardo
Here are more benchmarks on one of the build nodes. It doesn’t nearly
have as many used inodes as ci.guix.gnu.org, but I could fill it up if
necessary.
root@hydra-guix-127 ~# df -i /gnu/
Filesystem Inodes IUsedIFree IUse% Mounted on
/dev/sda3 28950528 2796829 26153699
Ricardo Wurmus writes:
> Ludovic Courtès writes:
>
>> Ricardo, Roel: would you be able to run that links-traversal.c from
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?filename=links-traversal.c;bug=24937;msg=25;att=1>
>> on a machine with a big st
I agree with Ludo and Andreas that we better shouldn’t make the
name field optional.
That said, I just pushed a series of patches that happens to address
this wishlist item in a very roundabout way. It is now possible to
build packages from JSON files like this:
--8<---cut
Marius Bakke writes:
> Is this bug report still relevant?
The EOMA68-A20 board still hasn’t been completed, so I think it’s fine
to close this bug report.
--
Ricardo
Ludovic Courtès writes:
>> root@hydra-guix-127 ~# ls -1 /gnu/store/.links | wc -l
>> 2017395
>
> That’s not a lot, my laptop has 2.8M links.
Let me rerun this after copying a few thousand store items from
ci.guix.gnu.org over. Maybe we’ll see the different times diverge then.
--
Ricardo
Jonathan Brielmaier writes:
> Error in open.connection(con, "rb") :
> server certificate verification failed. CAfile: none CRLfile: none
This is due to a change in r-curl. We patched it to respect the
CURL_CA_BUNDLE environment variable, not just when it’s used on Windows.
The code has
Julien Lepiller writes:
> In fact, the video is slightly outdated, showing a different command
> for importing the gpg key.
This is now fixed.
> There was also a confusion as the gpg fingerprint appears on a
> separate paragraph, as if it were part of the output, leading to a
> failure due
Ricardo Wurmus writes:
> Ludovic Courtès writes:
>
>> Danny Milosavljevic skribis:
>>
>>> I think it's our job as a distribution to integrate the components properly
>>> into
>>> the system so that confusing stuff like that doesn't happen.
>
With the upgrade to R 4.0.0 r-minimal is now reproducible. This is not
because R 4.0.0 fixed anything but because more package meta data files
had become irreproducible.
I noticed that setting LC_ALL to C during the build ensures that package
meta data files are generated reproducibly.
Closing!
This is now fixed after merging #39069.
We could fix this generically for users of the GNOME service, but for
those who simply install install individual applications we would still
need to propagate inputs individually.
--
Ricardo
Ricardo Wurmus writes:
> Ben Sturmfels writes:
>
>> On Sun, 05 May 2019, Jonathan Frederickson wrote:
>>
>>> I'm attempting to use Flatpak on my Guix system, and I'm experiencing
>>> segfaults when attempting to add a remote repo. Provided below a
Bug #22704 is fixed, so while I get the notification box that tells me
that the manual is not installed I can simply click on the link to open
it in a browser.
It also tells me to go to Preferences if I want to always open the
manual in my browser, which works fine.
The only way to include the
Ben Sturmfels writes:
> On Sun, 05 May 2019, Jonathan Frederickson wrote:
>
>> I'm attempting to use Flatpak on my Guix system, and I'm experiencing
>> segfaults when attempting to add a remote repo. Provided below are the
>> output of the command I'm attempting to run, as well as some info
>>
avr-toolchain-5.5.0 fails to build. It seems to be mixing headers from
GCC 5 and GCC 7:
--8<---cut here---start->8---
In file included from
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:36:0,
from
--8<---cut here---start->8---
starting phase `configure'
Backtrace:
19 (primitive-load "/gnu/store/4f9lljysahpgjjlzw02dvnhajnk…")
In ice-9/eval.scm:
191:35 18 (_ _)
In guix/build/gnu-build-system.scm:
838:2 17 (gnu-build #:source _ #:outputs _
gcc-cross-sans-libc-arm-none-eabi-4.9.4-1.227977 (an input to
axoloti-patcher) fails to build.
Just like with issue #41209 the headers for both GCC 5 and 7 are
included.
--8<---cut here---start->8---
…
make[2]: Leaving directory
Arne Babenhauserheide writes:
> Efraim Flashner writes:
>
>> If it worked until about 2 months ago it might be related to the glibc
>> bump. One thing you could do is create a profile from before the
>> core-updates merge and LD_PRELOAD from there.
>
> How can I do that? Can I simply specify
Danny Milosavljevic writes:
> Found a previous bug report at
>
> https://lists.gnu.org/archive/html/bug-guix/2018-10/msg00177.html
Alternative URL:
https://issues.guix.gnu.org/33105
I also ran into this problem and making the directory group-writable
fixed it.
--
Ricardo
Closing.
Ricardo Wurmus writes:
> * can we avoid this by extending modify-services to support “delete”
> much like modify-phases, and suggesting to use that instead of
> “remove”?
The attached patch does this.
What do you think?
--
Ricardo
>From 40c1208cbe9cbfa58ee385ef6ee06b775d30
I believe this was fixed by commit
21fcfe1ee969cc477dc41486ae4074e655d44274.
Closing.
--
Ricardo
zimoun writes:
> Digging in the bug tracker, I found this bug [1] about ESS saying that
> it does not behave like all other Emacs packages; installing in
> '$out/share/emacs/site-lisp/ess' instead of "guix.d".
>
> Well, all other packages do install in '$out/share/emacs/site-lisp/'
> as the
Ricardo Wurmus writes:
> This is not very helpful, because it’s hard to tell how we got there.
> Which of the selected services provide xorg-server?
This is the wrong question. While Shepherd services may have been
introduced to the Shepherd service graph by other general system
se
Hi Hartmut,
have you been able to reproduce this with a simpler test case? Or would
you agree to close this issue as unreproducible?
--
Ricardo
Ricardo Wurmus writes:
> I reported this here:
>
> https://github.com/flatpak/flatpak/issues/3612
>
> I’d say we close this issue here, because the segfault isn’t our fault.
Upstream has acknowledged and addressed the bug.
Closing.
--
Ricardo
java-kafka-clients has a failing test:
[junit] Running org.apache.kafka.common.network.SslTransportLayerTest
[junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
[junit] SLF4J: See
Does it work after removing ~/.config/ibus and ~/.cache/ibus/?
--
Ricardo
I can’t reproduce this easily as I have no accounts with any of the
supported services.
Could this be related to dconf? Have you tried running it with GNOME
debug environment variables set?
--
Ricardo
Jonathan Brielmaier writes:
> Trying `xdg-open mailto:guix-de...@gnu.org` in XFCE or MATE fails. The
> same happens when you click on a mailto link in Icecat. I have
> claws-mail and icedove installed. They both have
> `MimeType=x-scheme-handler/mailto;` in their desktop files.
Pushed the fix
These NIX_* variables are still in use:
NIX_AFFINITY_HACK
NIX_BIN_DIR
NIX_BUILD_CORES
NIX_HELD_LOCKS
NIX_IGNORE_SYMLINK_STORE
NIX_STORE
NIX_STORE_DIR
This is used internally:
_NIX_OPTIONS
--
Ricardo
I’m closing this as eureka-editor has already been added to the Guix
package collection.
--
Ricardo
Hi Julien,
> First it fails because it cannot find the public key and suggests running:
>
> wget … -q0 - | gpg --import
>
> -q0 does not work with debian's wget, but -O works.
The installer script does not display this command. There is no zero in
the wget commands.
> Aftcr importing the
Guile SDL 0.5.2 still fails on i686:
--8<---cut here---start->8---
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler
This seems to affect the openjdk packages as well, so a user of OpenJDK
12 will have to download *all* JDKs.
Gábor, have you been able to identify locations that retain references
to the build JDK?
--
Ricardo
Marius Bakke writes:
> sirgazil via Bug reports for GNU Guix writes:
>
>> I couldn't upgrade the packages in my user profile because "emacs-elpy"
>> check phase fails.
>>
>>
>> ## Steps to reproduce
>>
>> 1. guix pull
>> 2. guix build emacs-elpy
>>
>>
>> ## Unexpected result
>>
>>
>> The
Brendan Tildesley writes:
> 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
zimoun writes:
> 1. when Bioconductor updates their release, some package versions are
> updated too, and so, the upstream return 404.
> 2. for this reason 1., the "guix time-machine" is broken for all the
> Bioconductor packages, at least if Berlin or SWH does not have a
> substitute; which
Thanks. Closing.
--
Ricardo
“guix system” prints a very terse error message when a display manager
is added on top of %desktop-services:
guix system: error: service 'xorg-server' provided more than once
This is not very helpful, because it’s hard to tell how we got there.
Which of the selected services provide
I want to delete a service from %desktop-services, so I write
--8<---cut here---start->8---
…
(services (remove
(lambda (service)
(eq? (service-kind service) that-annoying-service-type))
%desktop-services))
…
When I run “guix pull” (or “guix time-machine”) I see this message
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
followed by disconcerting silence. I can’t tell if it’s doing
something, nor can I see what the progress is.
Would be nice to
Ricardo Wurmus writes:
> Marius Bakke writes:
>
>> The update to http-parser in 62f7f0d636d3b3ff796263ab892ebf53263539fa
>> causes a test failure armhf-linux:
>
> The same test failure happens on i686-linux.
Actually, this might be a different failure:
t
Marius Bakke writes:
> The update to http-parser in 62f7f0d636d3b3ff796263ab892ebf53263539fa
> causes a test failure armhf-linux:
The same test failure happens on i686-linux.
--
Ricardo
Some Haskell packages have a “-bootstrap” variant to cut dependency
cycles. Unfortunately, these bootstrap variants remain in the reference
graph alongside their non-bootstrap counterparts.
An example:
--8<---cut here---start->8---
$ guix gc -R
701 - 800 of 1141 matches
Mail list logo
