Forgot to say which guix version I'm using:
guix (GNU Guix) ba6d3612550f5d978c4b5b1df122444f8fb29377
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
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
--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
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
"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
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
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)> (
> 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<--
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
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
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
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
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
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
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
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,
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,
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
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 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
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
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
25 matches
Mail list logo
