Hi,
Maxim Cournoyer skribis:
> Greg Hogan writes:
>
>> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh
>> wrote:
>>>
>>> Suhail Singh writes:
>>>
>>> > The issue, as I see it, is the time commitment required from the
>>> > release-team.
>>>
>>> Correction, the issues (IMO) are (in no particula
Hi,
Maxim Cournoyer skribis:
> Greg Hogan writes:
>
>> On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès wrote:
>>> As has been discussed multiple times at the Guix Days and on this list
>>> (I think?), I believe what we need is a release team with rotating
>>> duties. That is, a bunch of 3–5
Hello,
Olivier Dion skribis:
> For what it is worth, I have been using my own build system purely in
> Guile for a few years now. I use it in my main project libpatch
> (https://git.sr.ht/~old/libpatch/tree). It is compatible with the
> gnu-build-system (configure && make && make check && make
Hi Chris,
Christopher Baines skribis:
> Over the last month there's been work to move data.qa.guix.gnu.org from
> a Hetzner VM that I was renting to hydra-guix-130, a server hosted at
> the MDC. This new server has about 6x the amount of memory and many more
> cores.
>
> All of the moving is now
Hi Ludovic,
Ludovic Courtès writes:
[...]
>>> There is also access to hardware. From doc/release.org:
>>>
>>> "Steps #2 and #3 require you to have offloading set up so you can
>>> build for all the supported architectures. For instance, if you’re
>>> running this on an x86_64 machine, you shou
Hi,
45mg <45mg.wri...@gmail.com> writes:
> Hi Tomas,
>
> I finally understand that it's my use of `guix-for-channels` that's
> making it pull when I reconfigure. So, my issue is solved by removing
> the `(guix)` field from the `(guix-configuration)` form in the
> configuration I posted.
>
> All I
