During a conversation with maximed on irc, they suggested I could
possibly use (current-guix) to package latest guix with a VM image I was
creating for sourcehut builder.
I tried building (current-guix) with latest guix (after guix pull) as
well as tried building it with ./pre-install-env guix f
Joshua Branson writes:
> Akib Azmain Turja writes:
>
>> I've downloaded latest QEMU image from build servers (build details:
>> https://ci.guix.gnu.org/build/618573/details). Then I booted it with
>> libvirtd on my Guix System on GNU/Linux. It booted and the login shell
>
> Is this the same as
I've downloaded latest QEMU image from build servers (build details:
https://ci.guix.gnu.org/build/618573/details). Then I booted it with
libvirtd on my Guix System on GNU/Linux. It booted and the login shell
appeared. I logined as root without password and tried to install GNU
Hello (just to ma
I've downloaded latest QEMU image from build servers (build details:
https://ci.guix.gnu.org/build/618573/details). Then I booted it with
libvirtd on my Guix System on GNU/Linux. It booted and the login shell
appeared. I logined as root without password and tried to install GNU
Hello (just to ma
Hi,
I started having issues with R Shiny applications with newer Guix distro
commits. I have a feeling that this is an issue arising from `r-shiny`
dependency clashes and that (some) of those dependencies should be either
downgraded, or upgraded.
The problem is that the server logic of a shiny
Hello there,
I'm not familiar with the OS, this is my first ever test for it. I searched how
to add software and update the system.
During the process following guix pull, I had this error telling me I found a
bug and that I can report it to this email address.
So here is the prompt history and
any ETA on this fix? i think i need it.
i tried to add a `wrap-script-or-program` to `python-build-system`: attempt to
use `wrap-scipt`, and in case of a `no-interpreter-found` error fall back to
`wrap-program`. (motivated by trezor-agent relying on sys.argv[0], which is
ruined by `wrap-program
Hello Guix,
This is intended to be a tracking issue for updating go-build-system to
use Go 1.17 by default. The build system currently uses Go 1.14, which
no longer receives security updates [0].
Here's what needs to be done:
1. Address the aarch64 bug [1], either by verifying that it only happ
On Thu, Sep 09, 2021 at 03:14:57PM -0700, Sarah Morgensen wrote:
> This is intended to be a tracking issue for updating go-build-system to
> use Go 1.17 by default. The build system currently uses Go 1.14, which
> no longer receives security updates [0].
Thanks for putting this together.
> Here'
Sarah Morgensen writes:
> Sarah Morgensen writes:
>
>> Hello Guix,
>>
>> I just noticed go-1.16 is failing on aarch64 [0]. I am not having any
>> success tracking down the cause. It looks like the error is the same as
>> was happening for go-1.14 circa 11 Mar [1], which was fixed by 9 Apr
>> [2]
Hi!
Switching from the graphical installer to a different virtual terminal is
awkward in QEMU because the host system intercepts . So QEMU isn't aware it needs to switch to another TTY.
Usually this is quite easy to work around by using to
switch from one TTY to another, however this doesn't w
Hi.
I had the same issue. From reading online, it may suggest there some network
error. Retrying it after a couple of minutes made the problem go away for me.
Cheers
- Xander
12 matches
Mail list logo