references
> file. The references file is an S-expression containing a list of
> tuples of the form (FILE-NAME OFFSET). Each of these tuples
> identifies the location of a single reference at the recorded byte
> OFFSET in FILE-NAME.
>
> - when computing grafts, do
Hello Guix,
grafts can be a little slow for a number of reasons:
- they are not substituted, because the assumption is that it is
preferrable to rewrite references locally instead of downloading a big
archive with the modified file. Local computations on x86_64 are
often acceptable, but
zimoun writes:
> Hi Ludo,
>
> On Mon, 10 Oct 2022 at 17:32, Ludovic Courtès wrote:
>
>> This has to be compared with the cost of a rebuild/redownload of the
>> same set of packages. Even in the worst case, grafts are faster than
>> that. Now, the difference i
Hi Ludo,
On Mon, 10 Oct 2022 at 17:32, Ludovic Courtès wrote:
> This has to be compared with the cost of a rebuild/redownload of the
> same set of packages. Even in the worst case, grafts are faster than
> that. Now, the difference is that those grafts need to be recomputed
> regu
Hi,
zimoun skribis:
> On Wed, 05 Oct 2022 at 12:03, Ludovic Courtès wrote:
[...]
>> An is it too expensive for that machine to build grafts locally?
>
> Using my old desktop from work, yes the experience is really poor;
> especially for some packages where the number of g
t;>> enforce substitutability or not.
>>
>> An is it too expensive for that machine to build grafts locally?
>
> Using my old desktop from work, yes the experience is really poor;
> especially for some packages where the number of grafts is sometimes
> something, e.g
t;
> An is it too expensive for that machine to build grafts locally?
Using my old desktop from work, yes the experience is really poor;
especially for some packages where the number of grafts is sometimes
something, e.g., see [1] where grafting were longer than building.
1: <https://yhetil.
sive for that machine to build grafts locally?
It’s a matter of time. Having prepared the environment previously on
another fast machine I’d like to avoid repeating the same work again on
a slow machine.
We needn’t restrict ourselves to substitutions — if “guix copy” could
work without first having
Hi,
Ricardo Wurmus skribis:
> In my scenario I have two machines, one building stuff the other only
> substituting. The serving machine would be the one deciding whether to
> enforce substitutability or not.
An is it too expensive for that machine to build grafts locally?
Ludo’.
Tobias Geerinckx-Rice writes:
> Quick note:
>
> On 1 October 2022 17:29:03 UTC, Ricardo Wurmus wrote:
>>If substitutable was merely a hint that a daemon could be free to ignore
>>it wouldn’t be any worse than downloading a substitute vs building
>>something locally.
>
> Substitutability has le
Quick note:
On 1 October 2022 17:29:03 UTC, Ricardo Wurmus wrote:
>If substitutable was merely a hint that a daemon could be free to ignore
>it wouldn’t be any worse than downloading a substitute vs building
>something locally.
Substitutability has legal implications in Guix, whether or not it s
Ludovic Courtès writes:
> The premise was that computing a graft is usually quicker than
> transferring it, which is why they have #:substitutable? #f.
>
> I don’t think it would be reasonable to have a switch to toggle
> #:substitutable? because that would make .drv depend on external
> factor
Hi!
Ricardo Wurmus skribis:
> While this is also an interesting development for grafts, my question is
> much narrowed. I’d be very happy if we could have a little switch that
> made my daemon(s) ignore the “substitutable?” property and just
> substitute everything.
>
> I
Maxime Devos writes:
> On 15-09-2022 16:46, Csepp wrote:
>> Ricardo Wurmus writes:
>>
>>> [...]
>>> Did I say *all items*? Well, … grafts are not included, because graft
>>> derivations are marked as not substitutable.
>>>
>>> Ca
On 19-09-2022 18:26, Josselin Poiret wrote:
Hi everyone,
Maxime Devos writes:
Fallbacks might be necessary (not every store item is constructed from a
package), but it all sounds doable and efficient. Also the union could
needs to be modified to ignore the .graft-offsets of the union'ed thing
Hi everyone,
Maxime Devos writes:
> Fallbacks might be necessary (not every store item is constructed from a
> package), but it all sounds doable and efficient. Also the union could
> needs to be modified to ignore the .graft-offsets of the union'ed things.
If I understand the whole thing pro
On 15-09-2022 19:43, Csepp wrote:
Could we store the offsets of references somewhere at build time?
I now remember that idea, I forgot about that one.
My answer: I don't see why not, maybe by adding a phase to
%standard-phases (at the very end, to avoid it becoming invalid) that
saves it i
Maxime Devos writes:
> [[PGP Signed Part:Undecided]]
>
>
> On 15-09-2022 16:46, Csepp wrote:
>> Ricardo Wurmus writes:
>>
>>> [...]
>>> Did I say *all items*? Well, … grafts are not included, because
>>> graft
>>> derivations
On 15-09-2022 16:46, Csepp wrote:
Ricardo Wurmus writes:
[...]
Did I say *all items*? Well, … grafts are not included, because graft
derivations are marked as not substitutable.
Can we change that conditionally? I would really like to avoid having
to build grafts on B when they have
achine A, and then on the weak machine B I
> do
>
> guix build --substitute-urls="http://A:8000";
> /gnu/store/…-profile.drv
>
> and all items for that profile are copied to B.
>
> Did I say *all items*? Well, … grafts are not included, because graft
> derivatio
--substitute-urls="http://A:8000"; /gnu/store/…-profile.drv
and all items for that profile are copied to B.
Did I say *all items*? Well, … grafts are not included, because graft
derivations are marked as not substitutable.
Can we change that conditionally? I would really like to avoid
Hello,
What an interesting read. Well done, Ludo!
Nicolò Balzarotti writes:
> Interesting blog post, thanks!
> I found a typo:
> /remove-eval/remote-eval/
Me too: s/more of hint/more of a hint/
-- Tim
Hi Ludo!
Interesting blog post, thanks!
I found a typo:
/remove-eval/remote-eval/
Thanks, Nicolò
Ludovic Courtès writes:
> Hello Guix!
>
> I wrote about the recent changes in support of grafts in this post:
>
> https://guix.gnu.org/blog/2020/grafts-continued/
>
> Feedback welcome!
>
> Ludo’.
Hello Guix!
I wrote about the recent changes in support of grafts in this post:
https://guix.gnu.org/blog/2020/grafts-continued/
Feedback welcome!
Ludo’.
signature.asc
Description: PGP signature
Hello Guix!
Ludovic Courtès skribis:
> To address that, I think we need a better way to handle “dynamic
> dependencies”. The ‘wip-build-accumulator’ branch does that by taking
> advantage of ‘with-build-handler’. On that branch, grafts no longer use
> substitute info. Instea
Hello Guix!
I’ve just pushed a pretty cool hack to ‘wip-build-accumulator’. :-)
Grafts are a function of the references of a package. Suppose Bash has
a ‘replacement’ field. If a package has a build-time dependency on
Bash, it’s a candidate for being grafted the Bash replacement. However,
if
Hello,
Mark H Weaver skribis:
>> Ricardo Wurmus writes:
[...]
>> (define glibc-final
>>;; The final glibc, which embeds the statically-linked Bash built above.
>> - (package (inherit glibc-final-with-bootstrap-bash)
>> + (package/inherit glibc-final-with-bootstrap-bash
>> (name "g
Please review this patch for correctness and style. Thanks in advance :)
Leo Famulari (1):
gnu: mupdf, cups-filters: Incorporated grafted changes.
gnu/packages/cups.scm | 8
gnu/packages/pdf.scm | 17 +++--
2 files changed, 3 insertions(+), 22 deletions(-)
--
2.11.0
o more likely something
>> > else, like figuring out the substitutions.
>>
>> Terrible. Commit d4da602 should improve the situation. You’re welcome
>> to try again and report back!
>>
>
> Much better!
Good, thanks for benchmarking!
There are other things (‘bag-grafts’, namely) that are done repeatedly
when doing an upgrade and that would benefit from a bit of
caching/memoization. Coming next!
Ludo’.
On Sat, Mar 05, 2016 at 12:24:59AM +0100, Ludovic Courtès wrote:
> Efraim Flashner skribis:
>
> > efraim@debian-netbook:~/workspace/guix$ time ./pre-inst-env guix package -u
> > && time ./pre-inst-env guix package -u && time ./pre-inst-env guix package
> > -u
> >
> > real15m0.833s
> > u
Efraim Flashner skribis:
> efraim@debian-netbook:~/workspace/guix$ time ./pre-inst-env guix package -u
> && time ./pre-inst-env guix package -u && time ./pre-inst-env guix package -u
>
> real 15m0.833s
> user 5m53.268s
> sys 1m26.056s
>
> real 14m27.095s
> user 5m50.848s
> sys 1m25.156s
On Wed, 02 Mar 2016 22:36:51 +0100
l...@gnu.org (Ludovic Courtès) wrote:
> Efraim Flashner skribis:
>
> [...]
>
> Ouch! Including substitute info fetching?
>
> There are a couple of optimizations that I’m willing to implement as
> soon as I stop doing email. ;-)
>
> Ludo’.
ran this this
Efraim Flashner skribis:
> One issue that I noticed on my slow netbook is that `guix package -u`,
> with no updates, now takes ~15 minutes, while before it was ~30 seconds.
Ouch! Including substitute info fetching?
There are a couple of optimizations that I’m willing to implement as
soon as I
d version as the package being
> replaced. So OpenSSL 1.0.2g shows up as /gnu/store/…-openssl-1.0.2f.
>
> The store file name of the old OpenSSL is given by:
>
> guix build openssl --no-grafts
>
> … and the new one is given by:
>
> guix build openssl
>
> For exa
That was a very clear and informative read. I appreciate your style of
writing, with links to relevant docs. Thank you!
One thing is still not clear to me about grafts. While you are using a
graft, is it possible the binaries you build will be different from those
built by someone not using the
l...@gnu.org (Ludovic Courtès) writes:
> I’ve posted a longer explanation of grafts at:
>
> https://savannah.gnu.org/forum/forum.php?forum_id=8470
>
> Thanks to Chris, David, and Mark for reviewing an earlier draft!
Thanks for taking the time to explain it.
The persistent
I’ve posted a longer explanation of grafts at:
https://savannah.gnu.org/forum/forum.php?forum_id=8470
Thanks to Chris, David, and Mark for reviewing an earlier draft!
Ludo’.
nSSL 1.0.2g shows up as /gnu/store/…-openssl-1.0.2f.
>
> The store file name of the old OpenSSL is given by:
>
> guix build openssl --no-grafts
>
> … and the new one is given by:
>
> guix build openssl
>
> For example, to verify which OpenSSL(s) your whole profile
A limitation of the current implementation is that the replacement
package must have exactly the same name and version as the package being
replaced. So OpenSSL 1.0.2g shows up as /gnu/store/…-openssl-1.0.2f.
The store file name of the old OpenSSL is given by:
guix build openssl --no-grafts
…
I went ahead and merged the guts of ‘wip-grafts’. This changes the ABI,
so make sure to run:
make clean-go && make
> However, the ‘graft-derivation’ procedure is not recursive: it grafts
> the derivation you give it, but doesn’t graft its dependencies.
This problem is not addr
The current status of ‘wip-grafts’ is that it works, there’s no
performance issue, etc.
However, the ‘graft-derivation’ procedure is not recursive: it grafts
the derivation you give it, but doesn’t graft its dependencies. Thus,
only direct references are grafted, which isn’t so great:
$ guix
Mark H Weaver skribis:
> If you want a real example, upstream bash is at 4.3.30, whereas we only
> have 4.3.27.
Yes, I have it in my working tree, and will push shortly. :-)
Ludo’.
l...@gnu.org (Ludovic Courtès) writes:
> I pushed ‘wip-grafts’, a branch that implements “grafts.”
>
> Normally security updates deep in the DAG, such as an update of Bash or
> libc, cause a rebuild of everything, which can some time, as we’ve seen
> lately.
>
> The idea of g
Hello,
I pushed ‘wip-grafts’, a branch that implements “grafts.”
Normally security updates deep in the DAG, such as an update of Bash or
libc, cause a rebuild of everything, which can some time, as we’ve seen
lately.
The idea of grafts is to graft the fixed package on any packages users
may
44 matches
Mail list logo
