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
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
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
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.
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:
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
Fixed with commit 1eb343f9cf18544319bc4ac016845348816f7265.
Closing.
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.
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!
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
> 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
tag 39394 easy quit
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
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
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
15 matches
Mail list logo
