texlive failure

texlive failure

[Federico Beffa]

Hi,

I have trouble downloading the 3.3GB 'texlive-data' package and
therefore I'm trying to build it locally. The 'build' and 'check'
phases succeed. However, after the 'compress-documentation' phase a
guile process stays at 100% for 1 hour, after which the process times
out and is killed.

This is the 'tail' of the output:

[...]
starting phase `compress-documentation'
compressing documentation in
'/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/man'
with "gzip" and flags ("--best" "--no-name")
compressing documentation in
'/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/info'
with "gzip" and flags ("--best" "--no-name")
phase `compress-documentation' succeeded after 0 seconds

After this there is no more output.

The content of the documentation directories is less than 1MB and I
can see that all man and info pages are compressed long before the
process times out. This is reproducible as I tried 3 times.

Any idea?

Regards,
Fede

Re: texlive failure

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> I have trouble downloading the 3.3GB 'texlive-data' package and
> therefore I'm trying to build it locally. The 'build' and 'check'
> phases succeed. However, after the 'compress-documentation' phase a
> guile process stays at 100% for 1 hour, after which the process times
> out and is killed.

I think what happens is what Mark described in
<http://bugs.gnu.org/19811>.

For now the workaround is to use --max-silent-time=10000 or similar.

HTH,
Ludo’.

Re: texlive failure

[Federico Beffa]

On Tue, Feb 10, 2015 at 1:26 PM, Federico Beffa <beffa@ieee.org> wrote:
> This is the 'tail' of the output:
>
> [...]
> starting phase `compress-documentation'
> compressing documentation in
> '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/man'
> with "gzip" and flags ("--best" "--no-name")
> compressing documentation in
> '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/info'
> with "gzip" and flags ("--best" "--no-name")
> phase `compress-documentation' succeeded after 0 seconds
>
> After this there is no more output.

While I was writing the previous email I was trying again to build
texlive and that guile process was already running since ca. 45 mins.
But, this time the process finished and the further output is

grafting '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014' ->
'/gnu/store/lpxmwqsv0rq6qsx7yc7wqjfzjk1v9pck-texlive-2014'...
grafting '/gnu/store/331b3772kzqpgp9mbw73cb9ixfy2fjn7-texlive-2014-data'
-> '/gnu/store/1fvf9jhlc5gb3kcminmv4yds9dkhyx01-texlive-2014-data'...
install-info: warning: no info dir entry in
`/gnu/store/z2z6924n1da54i956hj00awwksy2axkp-automake-1.14.1/share/info/automake-history.info'
[...]

So, I guess grafting takes a very long time. For this package it is
not substantially faster than building the package itself. :-(

Regards,
Fede

Re: texlive failure

[Federico Beffa]

On Tue, Feb 10, 2015 at 1:55 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> I think what happens is what Mark described in
> <http://bugs.gnu.org/19811>.
>
> For now the workaround is to use --max-silent-time=10000 or similar.

Crossed emails...

Yes, that's correct.

Thanks,
Fede

Re: texlive failure

[Andreas Enge]

On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote:
> So, I guess grafting takes a very long time. For this package it is
> not substantially faster than building the package itself. :-(

The speciality of texlive is that it is relatively easy to build - some CPU time
for the binaries. Then the data is essentially only unpacked and some of the
binaries are run on them, but the latter takes only minutes. So I would always
recommend to (re-)build the package locally.

Andreas

Re: texlive failure

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote:
>> So, I guess grafting takes a very long time. For this package it is
>> not substantially faster than building the package itself. :-(
>
> The speciality of texlive is that it is relatively easy to build - some CPU time
> for the binaries. Then the data is essentially only unpacked and some of the
> binaries are run on them, but the latter takes only minutes. So I would always
> recommend to (re-)build the package locally.

I wonder if we should consider setting #:substitutable? #f for texlive.
However, we would have to be careful not to propagate this setting, as
was recently proposed in the "Numpy failures" thread.

      Mark

Re: texlive failure

[Daniel Pimentel]

On 2015-02-10 10:34, Andreas Enge wrote:
> On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote:
>> So, I guess grafting takes a very long time. For this package it is
>> not substantially faster than building the package itself. :-(
> 
> The speciality of texlive is that it is relatively easy to build - some 
> CPU time
> for the binaries. Then the data is essentially only unpacked and some 
> of the
> binaries are run on them, but the latter takes only minutes. So I would 
> always
> recommend to (re-)build the package locally.
> 
> Andreas
I can install texlive after "guix pull", it work.

Thanks,
-- 
Daniel Pimentel (d4n1)

Re: texlive failure

[Andreas Enge]

On Tue, Feb 10, 2015 at 10:50:05AM -0300, Daniel Pimentel wrote:
> I can install texlive after "guix pull", it work.

You mean, you managed to pull all the data from hydra?
Or did you compile locally?

Andreas

Re: texlive failure

[Andreas Enge]

On Tue, Feb 10, 2015 at 08:46:42AM -0500, Mark H Weaver wrote:
> I wonder if we should consider setting #:substitutable? #f for texlive.
> However, we would have to be careful not to propagate this setting, as
> was recently proposed in the "Numpy failures" thread.

I have been working on a split of texlive into two private packages,
the binaries and the data (which unfortunately depends on the binaries),
and a public one that joins the two. We could then also have a
texlive-small with a smaller data portion.

With Ludovic we have been discussing numerous solutions over the last
week, but when implementing them, something always went wrong...
I think we now have a solution that works with wrapping all binaries,
and once some changes are made in core-updates to enable this for
symbolic links, it should be easy to implement. But before it works,
I am not giving guarantees any more...

Then a possible solution would be to substitute the binary package
(which requires CPU time), but not the data package (which requires almost
none).

Andreas

Re: texlive failure

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> So, I guess grafting takes a very long time. For this package it is
> not substantially faster than building the package itself. :-(

Grafting takes time proportional to the input size.  It’s OK for
packages of up to several MiB (the vast majority of packages), but here
we’re talking about 3 GiB.

Grafting is intentionally not substitutable, on the grounds that it’s
quite fast for most packages, and certainly faster than re-downloading
stuff.

TeX Live is obviously an exception.  I’m not sure how to address it.  We
must make grafting faster but even then, it’ll probably never be less
than 10mn for something this big.

Thoughts?

Ludo’.