> To avoid this unexpected sensitivity on the source origin
> method, I
> suggest that we explicitly exclude 'source' from consideration
> within
> the 'set-paths' phase. What do you think?
I agree. We should do that in the next ‘core-updates’.
I recently ran into this bug myself and was
Hello Danny,
Sorry for the delay.
Danny Milosavljevic writes:
> Hi Maxim,
>
> On Thu, 28 May 2020 09:24:58 -0400
> Maxim Cournoyer wrote:
>
>> FWIW, I started experimenting the same on my Guix System after a recent
>> guix pull & guix system reconfigure.
>
> Really? Back then I've fixed and
Hello,
L p R n d n skribis:
> The accountsservice service hasn't access to dbus' interfaces throwing
> an error when they're needed.The problem, at least, appears with LightDM.
> The error looks like:
>
> WARNING: Error updating user /org/freedesktop/Accounts/User1000:
>
$ guix environment --fallback -s i686-linux --pure mes
[...Building gcc-cross-sans-libc-i686 7.5.0 i686...]
[...]
The directory that should contain system headers does not exist:
/usr/include
make[3]: *** [Makefile:3009: stmp-fixinc] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]:
Hi,
Ricardo Wurmus skribis:
> For the haskell-build-system I want to offer two outputs by default:
> "out" and "static". However, the build system has no way to override
> the default as (@ (guix packages) package->bag) passes the package’s
> “outputs” value to make-bag.
Ah.
> When the
I have no opinion, and nothing new to bring in the conversation. So let's do
what fit the best to you.
Thank you for your advices.
Cheers,
Jérémy
Le 25 mai 2020 19:31:14 GMT+02:00, zimoun a écrit :
>Hi,
>
>On Sat, 23 May 2020 at 17:47, Ludovic Courtès wrote:
>> Jérémy Korwin-Zmijowski
I installed guix on a debian 10 VPS with the following:
cd /tmp wget
https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh chmod
+x guix-install.sh ./guix-install.sh
I ran guix install nginx then ran guix pull
~ $ guix pull
Migrating profile generations to
Hi Vincent,
On Sun, 31 May 2020 at 12:50, Vincent Legoll wrote:
> docker export | docker import - img_name
I do not know if it really works here. Maybe I am doing incorrectly...
--8<---cut here---start->8---
$ docker images --format
Hi,
Mikhail Tsykalov skribis:
> On 29.05.2020 18:38, Ludovic Courtès wrote:
>> Not long ago, I did this:
>>
>>commit 40fd909e3ddee2c46a27a4fe92ed49d3e7ffb413
>>Author: Ludovic Courtès
>>Date: Fri Apr 24 16:17:38 2020 +0200
>>
>>gnu: biber: Downgrade to 2.11.
>>
>>
Hi,
On 29.05.2020 18:38, Ludovic Courtès wrote:
Not long ago, I did this:
commit 40fd909e3ddee2c46a27a4fe92ed49d3e7ffb413
Author: Ludovic Courtès
Date: Fri Apr 24 16:17:38 2020 +0200
gnu: biber: Downgrade to 2.11.
Biber 2.12 is incompatible with biblatex 3.11, which
This problem manifests when installing cl-stumpwm package from
gnu/packages/wm.scm but other cl-* packages are likely to be affected
as well.
guix build cl-stumpwm fails with:
...
phase `unpack' succeeded after 0.0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded
Marius Bakke writes:
> 'guix offload test' passes without problems.
Not so fast, running it in a loop reveals the crash.
There is a trace file in /root/offloadtest.trace on Berlin with such an
occurence. It looks like a timeout is reached shortly before the EOF
error:
10139 poll([{fd=14,
Hello,
maybe you can try:
docker export | docker import - img_name
This should flatten the layers back to a single one.
--
Vincent Legoll
Marius Bakke writes:
> During 'guix build -s aarch64-linux dolphin' on Berlin, I got this crash:
Funny, I just got it _again_ building the same derivation. It seems to
happen while checking load on the selected offload machine, which is
'overdrive1.guixsd.org' in this and the previous case:
Hello,
During 'guix build -s aarch64-linux dolphin' on Berlin, I got this crash:
--8<---cut here---start->8---
building /gnu/store/87655bh9rqcr29qasl1c4yj3skmxkyiz-kfilemetadata-5.70.0.drv...
process 12989 acquired build slot
Am 14.05.20 um 07:24 schrieb Ricardo Wurmus:
> have you been able to reproduce this with a simpler test case? Or would
> you agree to close this issue as unreproducible?
I could not reporduce this either when using a current version fo guix.
Closing.
--
Regards
Hartmut Goebel
| Hartmut
Hi Chris,
Thank you for the detailed explanations.
On Sun, 31 May 2020 at 06:57, Chris Marusich wrote:
> The trash directory is on the "top layer" because it gets created in the
> running container. However, in practice many store items from lower
> layers are made dead when Stephen's script
Dear Stephen,
Follow ups of
https://lists.gnu.org/archive/html/help-guix/2020-05/msg00249.html
and bug#41607 CC http://issues.guix.gnu.org/41607
On Sat, 30 May 2020 at 19:02, Stephen Scheck wrote:
> You can convince yourself of this by doing something like the following:
>
> docker run
>
18 matches
Mail list logo
