Hi,
Pierre Neidhardt skribis:
> Ludovic Courtès writes:
>
>> Hi!
>>
>> Pierre Neidhardt skribis:
>>
>>> Shall we start a work group to fix the issue?
>>>
>>> - Write a blog article to explain the issue and a detailed process on
>>> how to fix it. (Embed it to the manual.)
>>
>> The “Submitt
Hello!
Christopher Baines skribis:
> I'm not quite sure how that would work, but the Guix Data Service can
> query for narinfo files, and from those it can store the size of
> specific outputs, as well as there references.
>
> So the closure size (I think?) is the size of an output, plus the
> c
Hi,
Tobias Geerinckx-Rice skribis:
> Ludovic Courtès 写道：
>> Nope (‘inherit’ is purely syntactic, it doesn’t “live on” at run
>> time.)
>> What would it buy you, though?
>
> In addition to what Gábor mentioned, ‘guix refresh -l’ rebuild numbers
> can be dangerously misleading when inheritance is
Ludovic Courtès 写道：
Nope (‘inherit’ is purely syntactic, it doesn’t “live on” at run
time.)
What would it buy you, though?
In addition to what Gábor mentioned, ‘guix refresh -l’ rebuild
numbers can be dangerously misleading when inheritance is
involved.
Would this not be useful information
Le 10 février 2020 03:09:57 GMT-05:00, Pierre Neidhardt a
écrit :
>zimoun writes:
>
>>> Say FOO has BAR in its closure, but not in the explicit inputs, how
>can
>>> I figure out which of the indirect inputs drags BAR in?
>>
>> I do not understand what you are looking for, but there is already:
>
On Mon, 10 Feb 2020 at 09:09, Pierre Neidhardt wrote:
>
> zimoun writes:
> > I do not understand what you are looking for, but there is already:
> >
> >guix graph -t reverse-package
> > guix graph -t reverse-bag
>
> Yes, but this produces way too big a graph, which was my point below.
F
Pierre Neidhardt writes:
> zimoun writes:
>
>> You could propose such feature to the Guix Data Service.
>> For example, on this webpage [1], the history of all the Git package
>> in Guix is shown. The closure size could be reported.
>>
>> [1] http://data.guix.gnu.org/repository/1/branch/master/
zimoun writes:
>> Say FOO has BAR in its closure, but not in the explicit inputs, how can
>> I figure out which of the indirect inputs drags BAR in?
>
> I do not understand what you are looking for, but there is already:
>
>guix graph -t reverse-package
> guix graph -t reverse-bag
Yes, b
Hi Pierre,
On Sat, 8 Feb 2020 at 17:43, Pierre Neidhardt wrote:
> >> - Improve the tooling. In my experience, guix graph is quickly unusable
> >> with a high number of nodes. Maybe d3.js could be leveraged to add a
> >> filtering system, or a way to click on nodes to hide them and all
> >>
Ludovic Courtès writes:
> Hi!
>
> Pierre Neidhardt skribis:
>
>> Shall we start a work group to fix the issue?
>>
>> - Write a blog article to explain the issue and a detailed process on
>> how to fix it. (Embed it to the manual.)
>
> The “Submitting Patches” section mentions closure size spe
Hi,
On Fri, 7 Feb 2020 at 23:31, Gábor Boskovits wrote:
> Ludovic Courtès ezt írta (időpont: 2020. febr. 7., Pén 22:36):
>> zimoun skribis:
>> >> The thing is, I think it’s something that requires constant care, every
>> >> time we add a package or modify an existing one. It’s very easy to lo
Hello Ludo,
Ludovic Courtès ezt írta (időpont: 2020. febr. 7., Pén
22:36):
> Hi,
>
> zimoun skribis:
>
> >> The thing is, I think it’s something that requires constant care, every
> >> time we add a package or modify an existing one. It’s very easy to lose
> >> benefits that had been previousl
Hi,
zimoun skribis:
>> The thing is, I think it’s something that requires constant care, every
>> time we add a package or modify an existing one. It’s very easy to lose
>> benefits that had been previously obtained through hard work!
>
> I have never thought, neither tried but is it possible t
Hi Ludo,
On Wed, 5 Feb 2020 at 16:18, Ludovic Courtès wrote:
> > - Improve the tooling. In my experience, guix graph is quickly unusable
> > with a high number of nodes. Maybe d3.js could be leveraged to add a
> > filtering system, or a way to click on nodes to hide them and all
> > thei
Hi!
Pierre Neidhardt skribis:
> Shall we start a work group to fix the issue?
>
> - Write a blog article to explain the issue and a detailed process on
> how to fix it. (Embed it to the manual.)
The “Submitting Patches” section mentions closure size specifically. Is
there anything you think
Le 4 février 2020 11:22:10 GMT-05:00, zimoun a écrit
:
>Hi Pierre,
>
>On Tue, 4 Feb 2020 at 16:57, Pierre Neidhardt
>wrote:
>
>> Shall we start a work group to fix the issue?
>
>One of the obvious bottleneck is the documentation. Some packages come
>with a full doc and sometimes with Pandoc and/
Hi Pierre,
On Tue, 4 Feb 2020 at 16:57, Pierre Neidhardt wrote:
> Shall we start a work group to fix the issue?
One of the obvious bottleneck is the documentation. Some packages come
with a full doc and sometimes with Pandoc and/or TeX stuff. In
general, it is required but when speaking about m
Hi!
At FOSDEM 2020 Ludovic explained to the world why Guix is better than
other container formats (to put it mildly ;p).
Possibly the only counter-argument to "Guix > Snap / Flatpak" is
the size of the Guix containers.
I also talked to Mathieu who has been working relentlessly on
cross-compilat
18 matches
Mail list logo
