On 01/05/16 23:07, Ludovic Courtès wrote:
l...@gnu.org (Ludovic Courtès) skribis:
Now, I haven’t tested this in reality and would appreciate help here.
I’m in the process of implementing automated tests for the installation
process.
I've been looking at this bug, as I've got a new laptop
The profile generation/union code generates broken symlinks. I've
reproduced this on 2 different machines (both Debian running Guix).
To reproduce, run:
guix environment --pure --container --ad-hoc nss-certs findutils
coreutils
[env]# find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l -exec
On master (8f35c0306192c4b62646f2aa02879c2a8c4f4a07), as ruby 2.3.1 is
replaced by 2.3.3, and all ruby packages inherit from ruby 2.3.1, all
versions of ruby end up being 2.3.3.
For example:
→ guix environment --container --ad-hoc --pure -e "(begin (use-modules
(gnu packages ruby)) ruby-2.1)" --
I'm using a UK keyboard layout with a computer that I recently installed
GuixSD on with a encrypted root parition. Immediately after installation
when I attempted to boot in to the new system for the first time I had
to enter the passphrase twice, and in doing this, first I had to use the
Hey,
I gave setting up offloading another go, I'm testing with 3 machines,
two running GuixSD, and one Debian. I've tried setting up offloading
from both GuixSD machines to the Debian machine, and from one GuixSD
machine to the other.
Running `guix offload test` works, and reports success.
I've had the following issue a few times now, it seems that somehow,
the info-dir builder can be incorrectly generated, without the usual
module import stuff.
The most recent time this occurred, I worked around this by finding the
guix package in the store which I thought was being used at the
When using caff from the signing-tools pacakge, it looks for sendmail
in the wrong places [1]. It would be useful to find a way to make it
work when installed.
I have found a workaround, which is to specify PERL_MAILERS as
sendmail:$(type -p sendmail), e.g.:
PERL_MAILERS=sendmail:$(type -p
On Mon, 09 Oct 2017 23:37:49 +0200
Ricardo Wurmus wrote:
> Hi Christopher,
>
> > When using caff from the signing-tools pacakge, it looks for
> > sendmail in the wrong places [1]. It would be useful to find a way
> > to make it work when installed.
> >
> > I have found a
On Tue, 22 Aug 2017 12:41:26 +0200
l...@gnu.org (Ludovic Courtès) wrote:
> Christopher Baines <m...@cbaines.net> skribis:
>
> > bin/guile",["--no-auto-compile","/gnu/store/9ywpf5jc12svv04gvbx96j5z1kpllwn4-info-dir-builder"]
> >
>
On Tue, 22 Aug 2017 10:41:55 +0200
l...@gnu.org (Ludovic Courtès) wrote:
> Heya,
>
> Christopher Baines <m...@cbaines.net> skribis:
>
> > I've had the following issue a few times now, it seems that somehow,
> > the info-dir builder can be incorrectly generated
On Mon, 28 Aug 2017 21:52:32 +0300
Efraim Flashner wrote:
> efraim@macbook42:~/workspace/guix$ time nice ./pre-inst-env guix
> system build ~/lightweight-desktop.scm Backtrace:
> 11 (primitive-load
> "/home/efraim/workspace/guix/scripts/gu…") In guix/ui.scm:
>
I tried again, and after one small change, things are now working!
Firstly, I was getting messages like:
process 1011 acquired build slot '/var/guix/offload/capella.local/0'
;;; [2017/08/31 18:16:40.455763, 0] private-key-from-file: [GSSH ERROR]
The file does not exist or permission denied:
On Tue, 17 Oct 2017 10:48:03 +0200
Ludovic Courtès wrote:
> Hello,
>
> Here’s a ready-to-merge patch series. Once applied, nars
> (aka. “substitutes”) are downloaded and extracted when a VCS checkout
> fails. This will address cases such as the recent Guile-Git repository
>
I'm glad to say that there is now a build system for Go, guix-patches
bug #28586 contains the details.
signature.asc
Description: PGP signature
There is now support for generating an ISO image of the installer
system, and I've successfully managed to use it to install GuixSD.
I've marked this as pending, and it can probably be closed once there is
a release of Guix/GuixSD which includes an ISO image installer.
signature.asc
Chris Marusich writes:
> I'm using GuixSD v0.10.0 with GNOME. I'd like to be able to lock my
> screen, but I can't seem to do so.
>
> My settings under GNOME settings > Keyboard > Shortcuts > System lists
> the following hotkey:
>
> * Lock screen: Super+L
>
> However,
Duplicity fails to build, this might be because of the GPG version used,
as it looks to me that GPG complains that the message is quite old. I'll
ask on the Duplicity talk mailing list.
test_remove_all_inc_of_but_n (testing.functional.test_cleanup.CleanupTest) ...
ok
Hey,
The Guix package for duplicity is failing to build, and I was wondering
if there is a fix already? I've had a look on Launchpad, but didn't spot
anything.
Here is the error:
==
ERROR: test_sigchain_fileobj
I've just noticed that the erlang package has started failing to
build. It looks like the bootstrap phase is over eager, and attempts to
run the bootstrap directory.
I think I'll fix this by deleting the phase, when I get around to
merging the changes in #31678, but this might be affecting other
Hey,
I think something may have broken recently with the guix publish
service. I run this on a server with very basic configuration, just
setting the host, but I noticed recently that there were problems using
the service. The following example is guix failing to download something
from that
Ludovic Courtès writes:
>> I think something may have broken recently with the guix publish
>> service. I run this on a server with very basic configuration, just
>> setting the host, but I noticed recently that there were problems using
>> the service. The following example is
Gábor Boskovits writes:
> ezt írta (időpont: 2018. nov. 3., Szo 7:13):
>
>> I am watching this bug on Lenovo G50-30 (CPU 2.1 GHz, 2Gb Ram):
>>
>> # guix pull --substitute-urls=https://berlin.guixsd.org
>> Updating channel 'guix' from Git repository at '
>>
On one system running GuixSD, Gnome Shell crashes when opening the
activities overview (super key, or clicking on the activities button in
the top left).
(.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639:
g_file_new_for_path: assertion 'path != NULL' failed
(.gnome-shell-real:2471):
Leo Famulari writes:
> On Wed, Dec 05, 2018 at 10:05:57PM +0000, Christopher Baines wrote:
>>
>> substituting
>> /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
>> downloading from
>> https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdr
substituting /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
downloading from
https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
ruby-sass-spec-3.5.4 1.3MiB
Ludovic Courtès writes:
> Hello,
>
> Christopher Baines skribis:
>
>> Unfortunately, it's not a proper solution, as it obviously breaks when
>> you actually want to strip the mount point off so that grub can find the
>> right files.
>
> Is there a way ‘str
d to track the
issue. I've also written a system test that I believe reproduced the
issue.
From 7eee5685f95d0b6baeb97f5fdd947fe5223a61c9 Mon Sep 17 00:00:00 2001
From: Christopher Baines
Date: Fri, 26 Oct 2018 18:48:32 +0100
Subject: [PATCH] WIP Btrfs store subvolume test
---
gnu/te
swedebugia writes:
> On 2019-01-02 22:50, swedebugia wrote:
>> On 2018-12-31 13:33, Ricardo Wurmus wrote:
>>>
>>> Hi swedebugia,
>>>
We should upgrade.
>>>
>>> Could you please send a patch?
>>>
>>
>> Here it is :)
I haven't looked too closely at the patch, but I think the newer version
Ludovic Courtès writes:
> Hi Chris!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> Christopher Baines skribis:
>>
>>> I'm using a UK keyboard layout with a computer that I recently installed
>>> GuixSD on with a encrypted root parition. Immediate
Ludovic Courtès writes:
> Danny Milosavljevic skribis:
>
>> Hi Christopher,
>>> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
>>> index a633d2ee6d..4db0e72e9b 100644
>>> --- a/guix/scripts/package.scm
>>> +++ b/guix/scripts/package.scm
>>> @@ -159,6 +159,7 @@ hooks\" run
Mark H Weaver writes:
> My OS config includes a reference to 'upower-service', which is now
> deprecated, but the deprecation message is bogus:
>
> mhw@jojen ~$ guix system build /etc/config.scm --verbosity=1
> /etc/config.scm:149:19: warning: 'slim-service' is deprecated, use
>
I ended up pushing a patch [1] for this as part of [2]. This has now
been released by upstream, so the change doesn't exist in the Guix
codebase any longer (the package was updated in [3]).
1: e61f092c877da5a9dc5dcdd82690bd3c191769e1
zna...@disroot.org writes:
> My bug report is this https://github.com/Eloston/ungoogled-chromium/issues/730
>
> During update with `guix pull && guix package -u` ungoogled-chromium build
> process stops on build derivation on 84% three times in a row.
What does your system memory and swap look
Ludovic Courtès writes:
> Hi Chris,
>
> Christopher Baines skribis:
>
>> I believe that the direnv package has encountered an issue with the
>> gnu-build-system [1].
>>
>> 1: https://issues.guix.info/issue/35386
>>
>> Due to the combination o
I believe that the direnv package has encountered an issue with the
gnu-build-system [1].
1: https://issues.guix.info/issue/35386
Due to the combination of the 'setup-go-environment phase from the
go-build-system, and the 'unpack phase of the gnu-build-system, there
are two directories to be
Ricardo Wurmus writes:
> Christopher Baines writes:
>
>> On one system running GuixSD, Gnome Shell crashes when opening the
>> activities overview (super key, or clicking on the activities button in
>> the top left).
>>
>>
>> (.gnome-shell-real
Ben Sturmfels writes:
> On Tue, 2019-04-23 at 21:33 +0100, Christopher Baines wrote:
>> Ricardo Wurmus writes:
>>
>> > Christopher Baines writes:
>> >
>> > > On one system running GuixSD, Gnome Shell crashes when opening
>> > &g
Collin J. Doering writes:
> Not sure where the best place to report this, however today I noticed
> that ci.guix.info, workflow.guix.info and workflows.guix.info do not
> redirect http to https, though its also served over https.
I'm unsure if this is intentional, or something to change.
There
Ludovic Courtès writes:
>> I wonder if some errors could be caught at build time, before attempting
>> to start the service.
>>
>> If in the derivation to build the configuration file, nginx is run
>> against the built config file with -t, that might spot errors at
>> derivation build time.
>
>
Ludovic Courtès writes:
> It’s nice that we have but I noticed that, unlike
> most or all other configuration records that we have, it’s possible to
> create an record that leads to a syntactically
> invalid nginx config file.
>
> For example, if you have a location block like this:
>
>
As version 5.7.0 has been released, I tried updating to that. There
seems to be some issue with the configuration for the socket file, but
even avoiding that, it doesn't seem to resolve the issue with the
cgroups.
For now, I've switched more permanently back to 5.4.0.
signature.asc
Description:
Raghav Gururajan writes:
> libvirt.libvirtError: Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory
So, I've experienced this too. Even though this is a cgroup thing, I'm
pretty sure this isn't an issue with Linux.
I've tried reverting the
Danny Milosavljevic writes:
> Hi,
>
> guix pull takes over 8 GiB of memory to finish if there are no substitutes.
>
> My laptop only takes max 8 GiB of RAM. I've set up swap, but that kind of
> memory usage still seems ridiculous.
Do you know if the derivations got built in parallel? So, does
Ludovic Courtès writes:
> Christopher Baines skribis:
>
>> I've now tried running the tests using Guix immediately prior to the
>> recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf),
>> and immediately after the merge
>> (cf3d1763ed
Christopher Baines writes:
> The guile-fibers package seems to fail to build on some machines.
>
> starting phase `check'
> make check-am
> make[1]: Entering directory
> '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
> make check-TESTS
> make[2]: Entering
→ guix import hackage parallel-io
Syntax error: unexpected token : (buildable (False)) (at line 52, column 8)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package 'parallel-io'
I had a quick look at the importer, but a solution didn't immediately
Hey,
When attempting to guix pull using the aarch64-linux system, I'm seeing
some issues with derivation outputs. I tried with a newer and older
commit, and the result is the same.
→ guix pull --commit=27b09f3ab11a30821a5ce0b071aac1bc6156497d
--system=aarch64-linux --profile=/tmp/testprofile2
Tobias Geerinckx-Rice writes:
> Christopher Baines 写道:
>> However, while this change might avoid the problem with guix pull in
>> the
>> future, I still a bit stuck. I got this from a fresh install of Guix
>> on
>> the Overdrive machine I have (aarch64-linux).
~$ guix pull
building /gnu/store/1r2cj292vvjvhbb92bri568p7dia7cp1-isrgrootx1.pem.drv...
building
/gnu/store/dhlb62lpf1ggcrax62hm7l7rlcf5c4fi-letsencryptauthorityx3.pem.drv...
downloading from https://letsencrypt.org/certs/isrgrootx1.pem...
-sha256 hash mismatch for
Jelle Licht writes:
> Arun Isaac writes:
>
>>> My best guess is that this has something to do with a circular
>>> reference between guile modules, but I am not certain on how to easily
>>> debug (and fix) this.
>>
>> I updated the guile-email package two days ago. I hope that is not what
>>
Ludovic Courtès writes:
> Hi,
>
> Christopher Baines skribis:
>
>> At some point, usually when extracting the information about lint
>> warnings, package derivations or system tests, the inferior guix repl
>> crashes.
>
> Could you come up with a simpler
Efraim Flashner writes:
> On Thu, Apr 09, 2020 at 11:42:18PM +0200, Marius Bakke wrote:
>> Efraim Flashner writes:
>>
>> > On Thu, Apr 09, 2020 at 11:24:25PM +0200, Marius Bakke wrote:
>> >> 'guix lint -c inputs-should-be-native' only checks the 'inputs' field of
>> >> a package, not
Ludovic Courtès writes:
> Glad you manage to get more info.
>
> Christopher Baines skribis:
>
>> Following up on this, I've built Guile on core-updates with libgc@7
>> rather than libgc@8 (which is what's used above), and I can't reproduce
>> the issue
Ludovic Courtès writes:
> Hi Christopher,
>
> Christopher Baines skribis:
>
>> I've attached a script that when run should reproduce the issue. I
>> extracted the code relating to lint warnings from the Guix Data
>> Service. The script attached runs this c
Christopher Baines writes:
> Ludovic Courtès writes:
>
>> Hi Christopher,
>>
>> Christopher Baines skribis:
>>
>>> I've attached a script that when run should reproduce the issue. I
>>> extracted the code relating to lint warnings from the
Christopher Baines writes:
> Ludovic Courtès writes:
>
>> Glad you manage to get more info.
>>
>> Christopher Baines skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc@7
>>> rather than libgc@8 (which is what's
→ guix describe
Generation 181 Apr 07 2020 16:55:29(current)
guix 1e96e6a
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1e96e6ac8bc0285cc2adfac4ac29b538b84d5dfc
→ guix build ledger
Backtrace:
1 (primitive-load
Marius Bakke writes:
> Christopher Baines writes:
>
>> → guix describe
>> Generation 181 Apr 07 2020 16:55:29(current)
>> guix 1e96e6a
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit
Ludovic Courtès writes:
> Hi,
>
> Christopher Baines skribis:
>
>> I got this error when reconfiguring with a recent revision of Guix.
>>
>>
>> /builder for `/gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv' failed
>> with exit code 1
>> buil
I got this error when reconfiguring with a recent revision of Guix.
/builder for `/gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv' failed with
exit code 1
build of /gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv failed
View build log at
Ludovic Courtès writes:
> Christopher Baines skribis:
>
>> When attempting to guix pull using the aarch64-linux system, I'm seeing
>> some issues with derivation outputs. I tried with a newer and older
>> commit, and the result is the same.
>&
Hey,
With recent Guix revisions ([3] for example) I've had some apparently
random segmentation faults with grafts. I've encountered this on two
machines, both times it appears not to happen repeatably, as re-running
the graft can work. I encountered this when running guix package -u, and
running
Noticed this when testing guix system build with core-updates. Here's a
small example which reproduces the issue:
(use-modules (guix channels)
(guix inferior))
(define channels
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
Ludovic Courtès writes:
> Since the use of the ‘static-web-site’ service, which puts web site
> files in the store, nginx returns a ‘Last-Modified’ header that can
> trick clients into caching things forever:
>
> --8<---cut here---start->8---
> $ wget --debug
Ludovic Courtès writes:
> Howdy!
>
> Christopher Baines skribis:
>
>> Ludovic Courtès writes:
>>
>>> Since the use of the ‘static-web-site’ service, which puts web site
>>> files in the store, nginx returns a ‘Last-Modified’ header that can
>
Marius Bakke writes:
> Christopher Baines writes:
>
>> Ludovic Courtès writes:
>>
>>> Ludovic Courtès skribis:
>>>
>>>> The attached patches add a mechanism to patch the Guix source tree, and
>>>> then use that mechanism to add
Ludovic Courtès writes:
> Ludovic Courtès skribis:
>
>> The attached patches add a mechanism to patch the Guix source tree, and
>> then use that mechanism to add the missing (ice-9 threads) import. With
>> this I can do:
>>
>> ./pre-inst-env guix time-machine \
>>
Maxim Cournoyer writes:
> Hello,
>
> Christopher Baines writes:
>
>> I'm loosing track of this issue a bit, as I've been dealing with it for
>> a while. I have a machine that I've setup where /gnu/store is a btrfs
>> subvolume. I do this so that I can
I noticed I could no longer send email recently. This is the behaviour
when I try to run sendmail from and older opensmtpd (this output
suggests it works):
→ /gnu/store/6843f93hfr54ds5zzl7ik3h5njgicy0w-opensmtpd-6.6.4p1/sbin/sendmail -h
sendmail: illegal option -- h
usage: sendmail [-tv] [-f
Leo Famulari writes:
> I've noticed that certain packages never seem to have substitutes
> available from ci.guix.gnu.org.
>
> This is not about packages that consistently fail to build, like Vigra
> (LibreOffice) [0], but packages that never seem to be attempted at all,
> and are not found
Mathieu Othacehe writes:
> Hello,
>
>> As discussed earlier today on IRC with Clément, we could add performance
>> monitoring capabilities to Cuirass. Interesting metrics would be:
>>
>> • time of push to time of evaluation completion;
>>
>> • time of evaluation completion to time of build
Mathieu Othacehe writes:
> Hello,
>
> I've observed a few Cuirass crashes the past days. The log looks like:
>
> --8<---cut here---start->8---
> 2020-09-11T12:55:35 next evaluation in 300 seconds
> GC Warning: Repeated allocation of very large block (appr.
Ludovic Courtès writes:
> Hi,
>
> elaexuotee--- via Bug reports for GNU Guix skribis:
>
>> When using --expose to mirror a path between host and guest, the guest mirror
>> fails to reflect file modifications from the host. However, file creation and
>> deletion are correctly propogated.
>>
>>
Ludovic Courtès writes:
> Hi,
>
> Christopher Baines skribis:
>
>> So I think removing the Last-Modified header from the responses will fix
>> the issue with the Repology fetcher (as it will stop thinking it's
>> already fetch the file, since it was l
* hydra/nginx/berlin.scm (%berlin-servers): Add some config to the
nginx-server-configurations for guix.gnu.org.
---
hydra/nginx/berlin.scm | 14 ++
1 file changed, 14 insertions(+)
diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 303fd35..8c90eb1 100644
---
Ludovic Courtès writes:
> Hi,
>
> Mathieu Othacehe skribis:
>
>>> I have now copied the database to a tmpfs mounted directory to make sure
>>> that those inconsistent duration are only caused by the I/O pressure on
>>> berlin.
>>
>> This helps a lot. The Cuirass web service has been running
pelzflorian (Florian Pelz) writes:
> On Thu, Apr 09, 2020 at 08:58:14PM +0200, Bengt Richter wrote:
>> Wondering, could dnsmasq help?
>
> I am already using dnsmasq to access a virtual machine of the machine
> hosting the Guix website so can replace the
> Guix website while old URLs keep
to figure out.
>>
>> Regards,
>> Florian
>
> An update:
>
> The attached patch for berlin serves more but not all URLs
> properly when testing on a VM.
>
> I found one problem; the nginx locations for redirecting old URLs can
> be given a higher priority
Hartmut Goebel writes:
> Serverity: wishlist
> I often find myself checking the content of a package. For this I
> would like to be able to inspect the list of files in a package, or
> even query for a specific file.
>
> This is much like Debian does in "list of files" for each package
> (e.g.
Ludovic Courtès writes:
> Hi,
>
> Ludovic Courtès skribis:
>
>> There’s this other discussion you mentioned, which I hope will have a
>> positive outcome:
>>
>> https://forge.softwareheritage.org/T2430
>
> This discussion as well as discussions on #swh-devel have made it clear
> that SWH
zimoun writes:
> On Mon, 15 Jun 2020 at 19:43, Christopher Baines wrote:
>
>> I believe it's been deployed now. It was working earlier today at least,
>> however all of Cuirass seems to be stuck now.
>
> Well, it seems working. Feel free to close the bug.
Great, cl
zimoun writes:
> Hi Chris,
>
> On Sat, 13 Jun 2020 at 17:23, Christopher Baines wrote:
>
>> I've now deployed the change to Bayfront, let me know if you see a
>> difference? :)
>
> Yes! :-)
>
> --8<---cut here---start-&
Jack Hill writes:
> On Sat, 20 Jun 2020, Christopher Baines wrote:
>
>> Do you have any examples of packages that are currently broken, and
>> which you'd like to remove?
>
> Perhaps mongo-tools: https://issues.guix.gnu.org/39637
>
> It broke when Go was upgraded
zimoun writes:
> Dear Chris,
>
> On Mon, 15 Jun 2020 at 21:23, Christopher Baines wrote:
>> zimoun writes:
>>> On Mon, 15 Jun 2020 at 19:43, Christopher Baines wrote:
>
>>>> I believe it's been deployed now. It was working earlier today at least,
>&g
Hey,
So I was having problems with soundconverter, and I noticed that if I
avoid grafts, it works. I'm not sure if there's an issue with the
grafting, or what's being grafted.
→ guix build soundconverter
/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2
→
zimoun writes:
> By default, "guix weather" returns:
>
> --8<---cut here---start->8---
> 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
> --8<---cut here---end--->8---
>
> which is not fatal
zimoun writes:
> On Tue, 09 Jun 2020 at 22:12, Christopher Baines wrote:
>
>> So I think I've got a patch [1] to Cuirass to "fix" this.
>>
>> 1: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00117.html
>
> [...]
>
>> I believe
I found this when trying to build guile3.0-gnutls:
guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- build
--no-grafts --check guile3.0-gnutls
FAIL: status-request-revoked
trying NORMAL:-VERS-ALL:+VERS-TLS1.2
received status request
Pierre Neidhardt writes:
> Hey Tobias,
>
> Always good to have someone actually test the stuff :)
>
> Tobias Geerinckx-Rice writes:
>
>> So far this looks like an (SB)CL(-specific) bug, right? Does it
>> happen anywhere else? I tried Guile[0].
>
> Maybe there was a misunderstanding, it's
The recent llvm 11.0.0 -> 11.0.1 change seems to have broken rust on the
master branch.
Luis Felipe writes:
> On Saturday, January 16, 2021 11:18 AM, Christopher Baines
> wrote:
>
>> Hey,
>>
>> I've just pushed the fix I worked on for thumbnails [1].
>>
>> 1:
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=540893a8ccef4143
ed after waiting for about 20 seconds.
> + The fonts have no preview thumbnails (I heard Christopher Baines was
> looking into this particular issue)
Hey,
I've just pushed the fix I worked on for thumbnails [1].
1:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=540893a8ccef41436a1c00a
Mathieu Othacehe writes:
> Hello Leo & Guillaume,
>
>> That's a good observation. I hadn't thought of it.
>>
>> I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable
>> these builds until we can fix the bug for real. Mathieu: this might
>> explain why the build farm is spending
As reported by sss2 on IRC [1]. I can see this has changed recently, I
don't know why [2].
guix package -i pidgin spice-gtk --no-substitutes
The following package will be upgraded:
spice-gtk (dependencies or package changed)
The following package will be installed:
pidgin
Leo Famulari writes:
> Recently, many people on the #guix IRC channel reported frequent
> non-deterministic failures of any operation involving substitution, like
> this:
>
> --
> $ ./pre-inst-env guix build --no-grafts poezio mpdris2 sonata beets-bandcamp
> beets
> substitute:
> guix
There seems to be some issues with guix refresh -l and/or deprecating
packages.
Take the following example, guile3.0-squee is used by the
guix-data-service. guix refresh -l claims it's not though.
→ ./pre-inst-env guix refresh -l guile-squee
No dependents other than itself:
Christopher Baines writes:
> I noticed through the Guix Data Service that some narinfo files from
> ci.guix.gnu.org have an excessive NarSize.
>
> These are the three that I've found, but there could be more.
>
>
> /gnu/store/qln574djfgl8h9glij9id8jips7nnrlw-flightge
I noticed through the Guix Data Service that some narinfo files from
ci.guix.gnu.org have an excessive NarSize.
These are the three that I've found, but there could be more.
/gnu/store/qln574djfgl8h9glij9id8jips7nnrlw-flightgear-2018.3.5
NarSize: 18446744072099351584
Reported on IRC, it looks like the up date of pybind11 from 2.4.3 to
2.6.1 causes openimageio to fail to build, which also prevents users
from installing/upgrading blender.
1:
This is the relevant derivation [1], this change was probably introduced
here [2].
1: /gnu/store/vmpn3xk6mzns9zvq7dvlpj67ld3fv48p-grub-hybrid-2.06.drv
2:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=018f95094153660e3041ec160718f0bda286a3dc
checking whether `gcc' accepts
1 - 100 of 267 matches
Mail list logo