Hi Maxim,
Maxim Cournoyer skribis:
> In the second case, the build is started on the local machine instead of
> being dispatched to the offload machine. Presumably, this is done so
> that the files are available locally; but I'd prefer if it'd offload and
> keep the files on the remote. An alt
Steps to reproduce:
1. Make file ~/.config/vis/visrc.lua with following text:
```
require('vis')
vis.events.subscribe(vis.events.INIT, function()
vis:command('qall')
end)
```
2. Open vis
vis should immediately close on startup, but it doesn't.
It happens because package defines $VIS_PATH sea
Thanks for the report.
tsmish ezt írta (időpont: 2020. febr. 2., Vas 18:57):
> Steps to reproduce:
> 1. Make file ~/.config/vis/visrc.lua with following text:
> ```
> require('vis')
>
> vis.events.subscribe(vis.events.INIT, function()
> vis:command('qall')
> end)
> ```
> 2. Open vis
>
> vis
tag 39394 easy quit
> I would go for renaming it like visrc.lua.example, or similar.
I don't really like this solution because while this particular
problem will be fixed, underlying issue of system paths having higher
priority than user ones will stay.
>From what I can figure out from the
code(https://github.com/mar
Hello!
strypst...@posteo.net skribis:
> Whenever running "sudo guix system reconfigure /path/to/config.scm I
> get the following warnings:
>
> building
> /gnu/store/vpazjd711byj3jszh7jrk5d8lq51077g-switch-to-system.scm.drv...
> ;;; WARNING: loading compiled file
> /gnu/store/5bd6ywmfcxxa4gvpzg0pd
On Thu, Jan 30, 2020 at 11:28:16AM +, Pkill -9 wrote:
> * gnu/packages/disk.scm (lf): New variable.
Thanks! I removed the superfluous #:unpack-path and pushed as
d441a6455051d70d7ff0d951c7e68318499b1739
> ---
> gnu/packages/disk.scm | 31 +++
> 1 file changed, 31
Hello!
Jesse Gibbons skribis:
> I've noticed most guix ops (including guix pull) hang on armhf as well,
> but I don't have a log to provide.
> Right now I'm fine with keeping guix at a stable (but potentially less
> secure) commit until the JIT compiler in Guile 3 is fixed and enabled
> on ARM.
Fixed with commit 1eb343f9cf18544319bc4ac016845348816f7265.
Closing.
Hello!
It seems that Go unduly retains a reference to GCC:
--8<---cut here---start->8---
$ guix size go
store item totalself
/gnu/store/g4rrz9rnr8ssbnj3gx3dmsxv4glll8nf-go-1.12.15 646.3
35
Hi Matt,
Matt Wette skribis:
> I'm using guix-1.0.1 on Fedora 30, x86_64.
>
> I wanted to get module spec for bytestructures, but failed:
> location points to (guix packages), but it's actually in (gnu packages
> guile).
>
> $ guix search bytestructures
> name: guile3.0-bytestructures
> version:
tsmish ezt írta (időpont: 2020. febr. 2., Vas 22:08):
> > I would go for renaming it like visrc.lua.example, or similar.
>
> I don't really like this solution because while this particular
> problem will be fixed, underlying issue of system paths having higher
> priority than user ones will stay.
Ludovic Courtès ezt írta (időpont: 2020. febr. 2., Vas
22:15):
> Hello!
>
> strypst...@posteo.net skribis:
>
> > Whenever running "sudo guix system reconfigure /path/to/config.scm I
> > get the following warnings:
> >
> > building
> > /gnu/store/vpazjd711byj3jszh7jrk5d8lq51077g-switch-to-system.s
In my case on aarch64, it appears to be deterministic. I've tried over a dozen
times and it always fails in the exact same place.
So perhaps aarch64 is a good target for debugging the underlying problem, if
this and #39266 are related, as they appear to be.
‐‐‐ Original Message ‐‐‐
On
Howdy :),
I've found that the `set-xorg-configuration` service ends up pulling in
`xf86-video-intel` as a dependency. But `xf86-video-intel` fails to build, with:
```
checking whether to include UXA support... no
checking whether to include SNA support... auto
checking for xvmc dri2proto x11 x11
15 matches
Mail list logo
