Hi,
Simon Tournier writes:
> Hi,
>
> On Sun, 08 Oct 2023 at 11:12, Maxim Cournoyer
> wrote:
>
>
>> such as fixes to
>> git-minimal (bug#65924)
>
> Why not also update git-minimal/pinned?
>
> Well, the idea with git-minimal/pinned (as well as with al
Hi,
On Sun, 08 Oct 2023 at 11:12, Maxim Cournoyer wrote:
> such as fixes to
> git-minimal (bug#65924)
Why not also update git-minimal/pinned?
Well, the idea with git-minimal/pinned (as well as with all /pinned
packages) is to have a variant that is
s fixes to
>> git-minimal (bug#65924) as well as docbook improvements (bug#65479) and
>> fixes to the build systems so that deep input rewriting works as
>> intended (bug#65665).
>>
>> I think we could also batch ungrafting of all grafted packages, to make
>>
ents (bug#65479) and
> fixes to the build systems so that deep input rewriting works as
> intended (bug#65665).
>
> I think we could also batch ungrafting of all grafted packages, to make
> the most out of this complete rebuild.
>
That sounds good, we have suddenly got a bunch of g
#65665).
I think we could also batch ungrafting of all grafted packages, to make
the most out of this complete rebuild.
To recall, the policy surrounding what goes to core-updates is still
unchanged (per the Contributing section of our manual), except for areas
covered by teams (which is still patchy
Hey Leo,
> Okay. Can you let me know when you do? I'll delay the ungrafting builds
> until then.
I deployed the upgrade yesterday. I've been monitoring it for 12 hours
without any sign of substitutes timeout. I think you can proceed whenever
you want.
Thanks,
Mathieu
On Wed, Jun 02, 2021 at 07:53:35PM +0200, Mathieu Othacehe wrote:
> I monitored a previous evaluation of the ungrafting Cuirass
> specification that was more successful, with more than 17000 builds
> performed in less than 24 hours, a new record! The recent evaluation is
> sadly les
Hello Leo,
I monitored a previous evaluation of the ungrafting Cuirass
specification that was more successful, with more than 17000 builds
performed in less than 24 hours, a new record! The recent evaluation is
sadly less victorious.
> The latest iteration failed en masse due to netw
the wip-ungrafting branch
"by hand" on the build farm.
What can we do to clear all these "spurious" build failures and re-try
building the branch? I already tried using the "restart all builds"
button, but there were still a lot of spurious failures.
We started building the wip-ungrafting branch a week ago:
https://ci.guix.gnu.org/jobset/ungrafting
Some progress has been made, but not enough. This is partially due to
<https://bugs.gnu.org/48574>, and also due to inefficient building of
expensive bootstrap paths (namely, every Rust p
On Fri, Apr 30, 2021 at 06:32:54PM +0200, Ludovic Courtès wrote:
> I’ve just merged ‘wip-ungrafting’ in master! It was at 76% according to
> <https://ci.guix.gnu.org>, with mostly ARM builds missing compared to
> ‘master’. Now we have fresh binaries to download (or build)!
Hooray
Hey there!
I’ve just merged ‘wip-ungrafting’ in master! It was at 76% according to
<https://ci.guix.gnu.org>, with mostly ARM builds missing compared to
‘master’. Now we have fresh binaries to download (or build)!
For the record, ‘wip-ungrafting’ was merged in ‘version-1.3.0’ a few
da
On Thu, Apr 22, 2021 at 12:27:52PM -0400, Mark H Weaver wrote:
> I don't understand why it's relevant how many patches are involved. It
> sounds like if I had concatenated all of the CVE-2021-27219 patches into
> a single file, you would have judged that as "simple", and therefore
> ungrafted it,
Hi Leo,
Leo Famulari writes:
> On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote:
>> I just noticed that 'glib' is still grafted on the 'wip-ungrafting'
>> branch. Was that intentional?
>>
>> https://git.sv.gnu.org/cgit/guix.git
On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote:
> I just noticed that 'glib' is still grafted on the 'wip-ungrafting'
> branch. Was that intentional?
>
> https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting&id=e122
I just noticed that 'glib' is still grafted on the 'wip-ungrafting'
branch. Was that intentional?
https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting&id=e12210dc92098d8581cea3007d57dbb6be16bb41#n171
Mark
Hi,
Mark H Weaver writes:
> Mathieu Othacehe writes:
>
>>> Any idea what could be wrong, Mathieu? What would you suggest to do
>>> when investigating such issues?
>>
>> Yes I noticed it. The main problem here is that almost all workers are
>> stuck building Rust.
>>
>> I see two actions here:
Mathieu Othacehe writes:
>> Any idea what could be wrong, Mathieu? What would you suggest to do
>> when investigating such issues?
>
> Yes I noticed it. The main problem here is that almost all workers are
> stuck building Rust.
>
> I see two actions here:
>
> 1. Understand why Rust is taking so
Hello,
> Any idea what could be wrong, Mathieu? What would you suggest to do
> when investigating such issues?
Yes I noticed it. The main problem here is that almost all workers are
stuck building Rust.
I see two actions here:
1. Understand why Rust is taking so long to build.
2. Implement
Hello,
> Any idea what could be wrong, Mathieu? What would you suggest to do
> when investigating such issues?
Yes I noticed it. The main problem here is that almost all workers are
stuck building Rust.
I see two possible actions here.
1. Understand why Rust is taking so long to build.
2. I
Hi!
The ‘wip-ungrafting’ branch that Leo set up has been building for ~36h.
It was at 26% 24h hours ago and it’s now stuck at 33%, even though all
but two workers are idle.
<https://ci.guix.gnu.org/eval/22683/dashboard> shows that many x86_64
builds are missing.
Any idea what could be
On Thu, Mar 11, 2021 at 02:16:16PM +0100, zimoun wrote:
> Updating the package r-chemminer, it leads to this huge stack of
> grafts. To be concrete, it is 84 grafts for a “simple” R packages. On
> my machine, the grafting steps are longer than building (compiling and R
> dance).
The performance
zimoun writes:
> Hi,
>
> Updating the package r-chemminer, it leads to this huge stack of
> grafts. To be concrete, it is 84 grafts for a “simple” R packages. On
> my machine, the grafting steps are longer than building (compiling and R
> dance).
>
> We definitively need a way to tackle this.
Hi,
Updating the package r-chemminer, it leads to this huge stack of
grafts. To be concrete, it is 84 grafts for a “simple” R packages. On
my machine, the grafting steps are longer than building (compiling and R
dance).
We definitively need a way to tackle this. Maybe when is in frozen
state,
On Thu, Jan 21, 2021 at 12:15:28PM +0100, Ludovic Courtès wrote:
> Apologies for not contributing so far, this month is busy for me. I
> think the slow feedback loop with ci.guix is one of the main reasons
> people don’t contribute much. Perhaps the whole process is also unclear
> to people who’r
Hi,
Leo Famulari skribis:
> On Fri, Jan 15, 2021 at 12:57:50AM -0500, Mark H Weaver wrote:
>> Ludovic Courtès writes:
>>
>> > Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
>> > that does nothing but ungraft things.
>> >
>>
On Fri, Jan 15, 2021 at 12:57:50AM -0500, Mark H Weaver wrote:
> Ludovic Courtès writes:
>
> > Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> > that does nothing but ungraft things.
> >
> > The rationale is that grafts incur additional overh
Hi Ludovic,
Ludovic Courtès writes:
> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> that does nothing but ungraft things.
>
> The rationale is that grafts incur additional overhead when installing
> things (the time to create those grafts), so it’s good t
Hello,
Am Mon, Dec 14, 2020 at 04:00:36PM -0500 schrieb Leo Famulari:
> I agree, it's not a violation of the functional packaging model in a
> strict sense.
if I understand correctly, it remains confusing in a non-strict sense:
grafting is functional, but it is not the same function. Precisely, t
Hi Mark and Leo,
Thanks for the explanations. All is clear.
All the best,
simon
On Mon, Dec 14, 2020 at 03:03:16PM -0500, Mark H Weaver wrote:
> So, it's still a mathematical function (assuming all packages build
> deterministically), but not necessarily the same function as if normal
> upgrades had been done instead of grafts. That's the main issue with
> grafts that I'm awa
Hi Leo,
Leo Famulari writes:
> When we added the recursive grafting feature, we intended to use it to
> deploy urgent security updates quickly, but we also intended to
> "ungraft" quickly, maybe in a week or two. We never planned to keep
> packages grafted for several months as we do now — graft
On Mon, Dec 14, 2020 at 11:32:05AM +0100, zimoun wrote:
> But if grafts is here, it is because of something. Therefore, I do not
> understand what it does mean “ungraft”. Avoid the grafting mechanism
> when it is possible?
Grafts are used to "hack" the package dependency graph. We try to make
so
Hi!
Marius Bakke skribis:
> Marius Bakke skriver:
>
>> Now the question is: should we restore this patch, and in practice
>> restart the branch almost from scratch? Or drop it, considering
>> upstream has rejected it[0]?
>
> Following a discussion on IRC, we decided to reinstate the patch and
Hi Leo,
On Tue, 08 Dec 2020 at 13:20, Leo Famulari wrote:
> On Tue, Dec 08, 2020 at 03:13:40PM +0100, zimoun wrote:
>> I have missed the discussion on IRC and I do not understand the
>> rationale. What's the point of "ungrafting"?
>
> Grafts cause profil
Hi,
Christopher Baines skribis:
> Ludovic Courtès writes:
>
>> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
>> that does nothing but ungraft things.
>>
>> The rationale is that grafts incur additional overhead when installing
>> thi
Marius Bakke skriver:
> Now the question is: should we restore this patch, and in practice
> restart the branch almost from scratch? Or drop it, considering
> upstream has rejected it[0]?
Following a discussion on IRC, we decided to reinstate the patch and get
rid of the newly added graft at th
Hello,
As you may have noticed, there is a new "ungrafting" branch that intends
to remove most of the "grafts" people have to deal with on a regular
basis.
The CI (and undersigned) have gotten pretty far on building this branch,
but there is a problem: cURL lost its "cur
Hello Ludo,
Ludovic Courtès writes:
> Hi Guix!
>
> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> that does nothing but ungraft things.
>
> The rationale is that grafts incur additional overhead when installing
> things (the time to create those gra
Ludovic Courtès writes:
> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> that does nothing but ungraft things.
>
> The rationale is that grafts incur additional overhead when installing
> things (the time to create those grafts), so it’s good to clean them
On Tue, Dec 08, 2020 at 03:13:40PM +0100, zimoun wrote:
> I have missed the discussion on IRC and I do not understand the
> rationale. What's the point of "ungrafting"?
Grafts cause profile operations like `guix install` and `guix
environment` to be slower than without grafts.
Hello,
On Tue, Dec 08, 2020 at 03:13:40PM +0100, zimoun wrote:
> I have missed the discussion on IRC and I do not understand the
> rationale. What's the point of "ungrafting"?
I suppose it is just a branch with all the patches that are grafted applied,
so that it is not ne
Hi Ludo,
On Tue, 8 Dec 2020 at 12:29, Ludovic Courtès wrote:
> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> that does nothing but ungraft things.
>
> The rationale is that grafts incur additional overhead when installing
> things (the time to create th
Hi Guix!
Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
that does nothing but ungraft things.
The rationale is that grafts incur additional overhead when installing
things (the time to create those grafts), so it’s good to clean them up
once in a while. Ungrafting in a
On Mon, May 02, 2016 at 09:34:34AM -0400, Mark H Weaver wrote:
> Leo Famulari writes:
> > Core-updates was suggested on IRC. This would mean that after each graft
> > commit, master would need to be merged into core-updates, and then the
> > "ungrafting" patch c
IRC. This would mean that after each graft
>> commit, master would need to be merged into core-updates, and then the
>> "ungrafting" patch could be applied.
>
> Merging those two will be awkward. In my experience, the result of git
> automatically merging these two com
master would need to be merged into core-updates, and then the
> "ungrafting" patch could be applied.
Merging those two will be awkward. In my experience, the result of git
automatically merging these two commits is to update the main package
*and* to graft it. For this reason,
-updates, and then the
"ungrafting" patch could be applied.
Thoughts?
48 matches
Mail list logo
