Hello Katherine and Ludovic,
I've finally had the time to push the patches[0], my house was hit hard by
sickness.
Concerning having Go 1.18 as the default version, I think it's on Ludovic
side to create a
branch to see where things breaks..
Not sure where the outputs will be but I am sure we wil
Pier-Hugues Pellerin writes:
> We should probably also try to mimic how their bootstrap and have the
> following:
>
>- Bootstrap 1.17 with 1.4
>- Bootstrap 1.18 with 1.4
>- Have 1.19 bootstrap with 1.17.
>
> So maybe we should do something like this.
>
> - Add go-1.18 build from 1.4.
Hello,
I've looked a bit more in detail on the Go package definition, Maybe we
should rethink how we are building the Go package in guix?
If I understand correctly, the current bootstrap chain is the following.
1.17 -> 1.16-> 1.4 which is the last gcc version of go.
Looking at the current propos
That sound great and great timing I was working on that as you send the mail
I think also go-next is a good idea, I will split them in the following
commits:
1. Add go-1.17 inherits from 1.18 (actually reversing the patch in the
previous email)
2. Add go-next pointing to 1.18.
3. Make go point to
>>> Pier-Hugues Pellerin writes:
>> Ludovic Courtès writes:
>>> I am trying to update Go to 1.18, I do have a *working* patch that defines
>>> a package that inherits from 1.17 and that adjusts the inputs.
>>
>> Nice!
Yes, thank you! I just found out I need this and came to see if anyone had
sta
Hello,
I think it makes sense, looking at the number of impacted packages and from
my experience working
in go, even if the contract is the same, sometimes it does break on minor.
One more thing, should I do it in two patches like this?
1. Add go 1.18 inheriting from 1.17, allowing people to use
Hi,
Pier-Hugues Pellerin skribis:
> I am trying to update Go to 1.18, I do have a *working* patch that defines
> a package that inherits from 1.17 and that adjusts the inputs.
Nice!
> However, I have a few questions:
>
> 1. Is inheriting the way to do that? The package's build system appears t
Hello,
I am trying to update Go to 1.18, I do have a *working* patch that defines
a package that inherits from 1.17 and that adjusts the inputs. However, I
have a few questions:
1. Is inheriting the way to do that? The package's build system appears to
be the same from 1.17.
2. How can I rebuild
