Hey Marius,
> But when you install a system using that Guix, it will install an
> _older_ Guix snapshot, from its embedded
> gnu/packages/package-management.scm, which is the broken
> 1.1.0-3.52b01cb.
Oh you are right, I didn't realize that.
>
> Probably we should make a new Guix snapshot to w
Chris Marusich writes:
> Ludovic Courtès writes:
>
>>> Should Guix do anything about this? We could change guix-daemon to take
>>> correct action in the face of an XDEV error. We could also improve the
>>> logging, since currently it silently swallows the XDEV error.
>>
>> I guess we could del
Hi Chris,
On Fri, 5 Jun 2020 at 11:33, Christopher Marusich wrote:
> Chris Marusich writes:
> > Ludovic Courtès writes:
> Here is a patch. Turns out it's was just a one line change! If nobody
> has any further feedback on it, I'll go ahead and merge it to the master
> branch in the next coup
Caleb Ristvedt skribis:
> Ludovic Courtès writes:
>
>> Hi,
>>
>> Caleb Ristvedt skribis:
>>
>>> From e1071c830ce511eecd57617a3f188740fd49d703 Mon Sep 17 00:00:00 2001
>>> From: Caleb Ristvedt
>>> Date: Tue, 2 Jun 2020 06:28:46 -0500
>>> Subject: [PATCH] xorg: honor xorg-configuration-server in
Hi,
Jan Nieuwenhuizen skribis:
> So, after digesting your message here I took the next step: grep for
> _HURD_STARTUP and change it there, like so
>
> diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
> index 421783eb80..8c73ea8430 100644
> --- a/gnu/packages/hurd.scm
> +++ b/gnu/packag
I ran the command a few times, and got the same error each time. I have
since wiped my VPS so I might not be able to assist in further debugging.
Thanks,
Jackson
On Thu, Jun 4, 2020 at 8:07 AM Ludovic Courtès wrote:
> Hi,
>
> Jackson Seal skribis:
>
> > Computing Guix derivation for 'x86_64-li
Hi,
Jackson Seal skribis:
> I ran the command a few times, and got the same error each time. I have
> since wiped my VPS so I might not be able to assist in further debugging.
Alright, closing.
Thanks,
Ludo’.
Hi,
John Soo skribis:
>> Normally, ‘--allow-downgrades’ does exactly what you need, at least
>> that’s the intent. I’d argue that it’s also reasonable to use it in
>> this case because obviously you know what you’re doing, and you’re
>> pulling from a local Git repository, so that’s fine.
>
> 1
Hi Simon,
zimoun skribis:
> $ guix describe
> Generation 37Jun 05 2020 01:28:52(current)
> guix 8bd0b53
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: 8bd0b533b30d7ee5e03aee99a2eb96d5b0b1c836
>
> $ echo hello >> $SRC/README && git -C $SRC commit -am hello
Hej Ludo,
thanks for the quick reply!
I just tried to pull again and yielded the same result.
Actually, no, there is nothing above these lines. Yet, let me copy/paste
the whole command in/output. It is in german but I guess the steps are
so common by now that it shouldnt be a problem to under
Howdy!
Christopher Marusich skribis:
> Here is a patch. Turns out it's was just a one line change! If nobody
> has any further feedback on it, I'll go ahead and merge it to the master
> branch in the next couple days.
Yay!
> From 505481a6a22819a42320f693988c3f8e13ded080 Mon Sep 17 00:00:00 2
Ludovic Courtès writes:
> Jan Nieuwenhuizen skribis:
>
>> So, after digesting your message here I took the next step: grep for
>> _HURD_STARTUP and change it there, like so
>>
>> diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
>> index 421783eb80..8c73ea8430 100644
>> --- a/gnu/package
Just to follow up: a roll-back does NOT solve the issue.
What I have tried:
1) roll-back via guix system roll-back (to the generation that was
created upon system installation)
2) roll-back via guix package --roll-back (same)
3) (1) + (2) combined
4) boot into the generation created upon system
Hi,
o.ro...@posteo.net skribis:
> Just to follow up: a roll-back does NOT solve the issue.
>
> What I have tried:
> 1) roll-back via guix system roll-back (to the generation that was
> created upon system installation)
> 2) roll-back via guix package --roll-back (same)
> 3) (1) + (2) combined
> 4
Very cool - thanks Chris!
In the meantime, I've updated my build script to externalize the Guix
environment from the Docker container.
So far the daily builds are staying nice and small at ~197MB and one layer.
The images and updated script are
here if anybody is curious:
https://hub.docker.com/r
> All in all, fixing all of this makes the closure size to drop below 1GiB
> which is already a good first step.
>
> I'll try to provide patches soon.
I also discovered that enabling CONFIG_MODULE_COMPRESS, the size of
linux-libre is reduced by 63%.
This makes the image way lighter.
--8<--
Hello Ludovic,
The same with “COLUMNS=200“:
--8<---cut here---start->8---
scheme@(guix-user) [1]> ,bt
In ice-9/boot-9.scm:
2806:4 6 (save-module-excursion _)
4351:12 5 (_)
In unknown file:
4 (find #gnu/build/file-systems.scm:606:4 (device)> (
Hi Ludo,
On Fri, 5 Jun 2020 at 18:17, Ludovic Courtès wrote:
> Generally, rebasing does not necessarily implies ‘git gc’, so I think
It depends on how "git gc" is configured. Well, I am not a Git
specialist but from my understanding of the manual, by default, these
unreachable commits are kept
"bdju" via Bug reports for GNU Guix writes:
> guix (GNU Guix) cef87bfea8a842d7dcf9a44c2305478fa6cca9b2
>
> I will attempt to attach the build log. I tried pasting the contents and
> it crashed my mail client. Also, paste.debian.net is down.
> Feel free to advise me on how to send the log in the f
The generated rdx and rdb files differ when built repeatedly. The code
includes references to Sys.time, but removing them doesn’t seem to be
enough.
--
Ricardo
--8<---cut here---start->8---
building /gnu/store/rb5cigrwvqgm87hxpf553g283lc2j6px-jupyter-1.0.0.drv...
guix package: error: profile contains conflicting entries for python-ipython
guix package: error: first entry: python-ipython@7.9.0
/gnu/store/z0yarar134q6s
Hello,
Jelle Licht writes:
> It seems that it no longer builds since 41a2d6a8 updated emacs-evil;
> Updating `emacs-general' to a more recent commit seems to be a bit of
> work, as the build system now relies on `makem.sh'.
I updated emacs-general. I can build it locally. If this fixes the
orig
Hi Ludo,
guix pull --roll-back did not solve the issue. The only thing I believe
to have changed is the "host version" portion of the error message.
'which guix' actually points to ~/.configu/guix/current/bin/guix. Should
this command yield a different value?
I have actually not done anythi
Hi,
When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
getting this error
"Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"
It works when I let emacs download it from melpa. I tried updating
emacs-lua-mode to 20200508, which is the same version as on melpa.
Stil
Forgot to say which guix version I'm using:
guix (GNU Guix) ba6d3612550f5d978c4b5b1df122444f8fb29377
25 matches
Mail list logo
