From: John Darrington <john@darrington.wattle.id.au>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Suggestion: disable offloading for texlive builds on hydra?
Date: Sun, 26 Oct 2014 08:49:27 +0100 [thread overview]
Message-ID: <20141026074926.GA3937@intra> (raw)
In-Reply-To: <87ppdf1dwc.fsf@netris.org>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On Sun, Oct 26, 2014 at 03:36:03AM -0400, Mark H Weaver wrote:
When texlive is built on hydra, the build slave that built it is tied up
for 12 hours or more waiting for the build outputs (over 3 gigabytes!)
to be transferred back to hydra.
By design, only one transfer can happen at a time from a given build
slave, so during those 12 hours, the build slave's CPU is left idle, and
typically another 3 built-but-not-yet-transferred packages must wait
until the texlive transfer finishes.
Why is it designed like that? It seems like a poor design to me.
I suggest that we arrange for hydra.gnu.org to build texlive locally for
x86_64 and i686, to avoid this problem.
Would it help if texlive was split into more outputs? For example, the docs
take up a lot of space, and not everyone needs them.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-10-26 7:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-26 7:36 Suggestion: disable offloading for texlive builds on hydra? Mark H Weaver
2014-10-26 7:49 ` John Darrington [this message]
2014-10-26 14:12 ` Ludovic Courtès
2014-10-26 16:07 ` Mark H Weaver
2014-10-27 12:58 ` Ludovic Courtès
2014-10-28 23:55 ` Ludovic Courtès
2014-10-29 21:50 ` Andreas Enge
2014-10-29 12:29 ` Andreas Enge
2014-10-29 16:20 ` Andreas Enge
2014-10-29 22:17 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141026074926.GA3937@intra \
--to=john@darrington.wattle.id.au \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.