Hey!
Mathieu Othacehe skribis:
> I observed the following deadlock on the cuirass-remote-server log file
> on berlin:
>
> 2021-11-17T23:12:00 fetching
> '/gnu/store/g6iqlblaxyvlvycrri110kfli9vhm8s0-julia-mlstyle-0.4.10.drv' from
> http://141.80.167.159:5558
> 2021-12-17T23:12:03 build succeede
Hi Christopher,
Christopher Rodriguez skribis:
> I recently spun up a new Linode host of GNU Guix with the intent to use
> it as a "personal substitute server" of sorts, with GNU Cuirass and guix
> publish being the main services running on it.
>
> It worked fine up to a point, but has been doin
Hello,
Giovanni Biscuolo skribis:
> IMO there is a bug in the CI UI
>
> Tanguy LE CARROUR writes:
>
>> In order to test the latest installer, I went to the "latest download"
>> page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
>> and ended up on an error page [2]:
>>
>> ""
Hi!
Ludovic Courtès skribis:
> News from the everlasting bug!
>
> cannot build missing derivation
> ‘/gnu/store/dfgc46q3l8wlnymv49a1wjnxypin8p0y-plink-1.07.drv’
[...]
> ‘guix publish’ replied, but 40s too late (nginx has
> “proxy_connect_timeout 10s;” for .narinfo URLs¹).
While the exact r
Hi Guix,
Since commit b72b6063cebbcfd64d43f5b05ba8470eb11c3f65 added dwarfes and
bpf support to our kernel an update to the latest kernel causes a
rebuild of all kernels.
The reason is
linux-libre-*->dwarfes->libbpf->linux-libre-headers-6.9
as (dependants of) libbpf need newer kernel header
I reported this problem upstream:
https://gitlab.gnome.org/GNOME/epiphany/-/issues/2392
Suhail Singh writes:
> Liliana Marie Prikler writes:
>
>> Am Sonntag, dem 14.07.2024 um 12:27 -0400 schrieb Suhail Singh:
>>> However, perhaps there is a way to ensure that the proposed
>>> replacement doesn't have a different ABI_VERSION. Could this be
>>> caught by a test or "sanity checker"
Liliana Marie Prikler writes:
> Am Sonntag, dem 14.07.2024 um 12:27 -0400 schrieb Suhail Singh:
>> However, perhaps there is a way to ensure that the proposed
>> replacement doesn't have a different ABI_VERSION. Could this be
>> caught by a test or "sanity checker" of some kind?
> You could just
Am Sonntag, dem 14.07.2024 um 12:27 -0400 schrieb Suhail Singh:
> However, perhaps there is a way to ensure that the proposed
> replacement doesn't have a different ABI_VERSION. Could this be
> caught by a test or "sanity checker" of some kind?
You could just print the value of comp-native-version
Liliana Marie Prikler writes:
>> IIUC, the issue is that replacement packages are grafted post-build.
>> This means that when emacs-dash is built, its AOT native-compilation
>> happens with Emacs 29.3. However, at run-time Emacs 29.4 gets
>> grafted in.
> Nitpick: Emacs 29.4 gets grafted in at p
Am Samstag, dem 13.07.2024 um 19:22 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler writes:
>
> > with the grafting of Emacs 29.3 to 29.4, we see that Emacs itself
> > is still correctly loaded, but Emacs libraries (e.g. dash) aren't.
> >
> > (comp-el-to-eln-filename (expand-file-name "…/das
11 matches
Mail list logo
