texlive: 2017 -> 2017-final #40826
texlive: 2017 -> 2017-final #40826
Conversation
|
CC @vcunat @veprbl I've tested this and built it on NixOS and on a single-user enterprise linux installation with a non-standard nix-store path; both appear to be working. I was initially trying to just go straight to I can understand not wanting to upgrade it and instead just going straight to |
| @@ -309,6 +309,10 @@ xindy = stdenv.mkDerivation { | |||
| name = "texlive-xindy.bin-${version}"; | |||
|
|
|||
| inherit (common) src; | |||
|
|
|||
| # If unset, xindy will try to mkdir /homeless-shelter | |||
| HOME = "/tmp/homeless-shelter"; | |||
There was a problem hiding this comment.
I'm not sure if this is sandbox-friendly. Perhaps it would be better to patch the build scripts to not do the funny business.
There was a problem hiding this comment.
Alternatively (although avoiding it might be better) can probably do something like setting HOME=$(mktemp -d) in preConfigure or something.
There was a problem hiding this comment.
I always do HOME = "."; in such cases.
|
Did you check that this evaluates on nix 1.11? We had problems with that last time. |
|
I think this should first go into staging. |
GrahamcOfBorg
added
10.rebuild-darwin: 501+
and removed
10.rebuild-darwin: 11-100
labels
|
Ping! It'd be great to get this (if not 2018!) in before 18.09! |
|
@yegortimoshenko Is there anything left to do, before this can be merged? |
|
I've been using this locally for the past few months without issue; I can rebase this on staging and set the We'd also want to mirror those tarballs to the content-addressed cache and/or IPFS and/or @veprbl's server, since I doubt math.utah.edu has a ton of bandwidth. |
|
@GrahamcOfBorg build texlive.scheme-basic |
|
Success on aarch64-linux Attempted: texlive.scheme-basic No partial log is available. |
|
Success on x86_64-linux Attempted: texlive.scheme-basic No partial log is available. |
bhipple
force-pushed
the
u/texlive-2017-final
branch
from
224777b
to
8f739f6
Compare
|
@GrahamcOfBorg build texlive.bin |
|
Success on x86_64-linux (full log) Attempted: texlive.bin Partial log (click to expand)
|
|
Failure on aarch64-linux (full log) Attempted: texlive.bin Partial log (click to expand)
|
|
Runs fine on my x86_64-linux box. aarch64 error looks unrelated. |
|
will merge in a day unless someone objects |
|
I'm getting That's strange because ./result/bin/biber --version
biber version: 2.7"biber" = {
sha512.run = "dec41092568e614d3366ca63dd4edbaf8ac602844bd8c1cfe1f7a294e701947a9da0dffa461b8b4adafd2f31ab7ac7afd8f6519afef2ed2c8d51ce60422e58fc";
sha512.doc = "d0d069a387b31f773ec2616a6f934138fef3029a3dad1f7fd3a49ca30d7c3177db3cd9aa5eff4b67e76092fabf1e1ce98afc3a0f4ce7800665fda818329621c6";
sha512.source = "a80f6a79d32f90aaf62c06535766209ff4942e950315b2c9bb3890abd2f3e06b28d3042b9e7bbc744ebc57e87c2d401f78628cabedb131d3b6169126b4fdddcd";
version = "2.10";
}; |
|
Maybe |
|
If I do diff --git a/pkgs/tools/typesetting/tex/texlive/bin.nix b/pkgs/tools/typesetting/tex/texlive/bin.nix
index 8e7551b4e41..a302729aca8 100644
--- a/pkgs/tools/typesetting/tex/texlive/bin.nix
+++ b/pkgs/tools/typesetting/tex/texlive/bin.nix
@@ -4,7 +4,7 @@
, freetype, gd, libXaw, icu, ghostscript, libXpm, libXmu, libXext
, perl, pkgconfig
, poppler, libpaper, graphite2, zziplib, harfbuzz, potrace, gmp, mpfr
-, cairo, pixman, xorg, clisp, biber
+, cairo, pixman, xorg, clisp
, makeWrapper
}:
@@ -261,7 +261,6 @@ dvipng = stdenv.mkDerivation {
};
-inherit biber;
bibtexu = bibtex8;
bibtex8 = stdenv.mkDerivation {
name = "texlive-bibtex-x.bin-${version}";I no longer have |
|
Yes, texlive seems to use the separately packaged biber. Will push an update here shortly. |
That won't be that easy. Seems like we need to package |
|
we do have |
|
Seems to build and run at least. |
|
Rebased on current staging. |
|
BTW: I could reproduce the issue with texlive 2017 and biber 2.7 on my 18.03 system. So it seems older and unrelated to this PR. Good we'll fix it soon 😄 |
|
Timed out, unknown build status on x86_64-linux (full log) Attempted: biber Partial log (click to expand)
|
|
Timed out, unknown build status on aarch64-linux (full log) Attempted: biber Partial log (click to expand)
|
|
@dotlambda after last rebase on newer |
|
Works perfectly. Thank you! |
|
This breaks the cddlib build: Is that expected? Could that be a more general issue? |
|
It's a more general issue – I've seen a few other TeX homeless-shelter errors in this staging-next iteration. Some not-too-long regression list of that iteration: https://hydra.nixos.org/eval/1474723?compare=1474536 |
|
I'm not sure this can be fixed in |
|
Yes, I think I've seen some |
|
Yes that may fix it, but it would be something everybody using texlive now or in the future in builds has to keep in mind. What is the |
|
Main reason is that But there may be a bug here: some format data should already be generated in However, |
|
Thank you for looking into it! A bug also seems likely because the issue didn't exist in the previous version. |
|
The weird thing is that the code generating the combined packages wasn't changed. But it uses a lot of perl scripts, and the update to perl 5.28 in the same staging iteration may be a factor too. |
|
If you can't find the issue, maybe you can file an issue on upstream's bug tracker (assuming such a thing exists). |
|
Sure, but I don't think it's an upstream issue. |
|
According to |
|
For others reading: @dtzWill apparently found the problem. |
|
I should state there's been a misunderstanding about the main purpose of I can't blame anyone, as I didn't review this PR, knowingly focusing my energy to other nix* parts. I almost don't use TeX anymore these years, so I "can't" really maintain it well, given my priorities around here... so it's more up to "you". The point was the fixed keyword – they were making the non-binary TeX packages fixed-output, so they stayed on the same nix store paths regardless of any mass rebuilds. Yes, it's a little harder to update for the maintainer, etc. but at that moment I wanted to save space, and this was a rather important part of that. When upstream switched hashes (from md5), I chose to stay with sha1 at that moment, as it seemed sufficient (and this choice actually had a line of explanation in the comments; we had quite some discussions about git repo size blowup around that time as well), but I personally consider the hash choice a nitpick, really. Well, you can consider getting this property back, e.g. with the 2018 update... |
|
@vcunat I understand your concerns. Making the packages fixed-output does save space (and, less importantly, a little time on rebuilds ). But the method implemented here also has its advantages as described above in terms of maintainability and transparency, so I don't think we should just go back to the previous solution either. Maybe we can find a "best of" solution for 2018. Let's take that discussion to #45432 . |
This reverts a part of the changes made in NixOS#40826. Fixed-output derivations save time and space on rebuilds.
This commit rebuilds texlive 2017 with the final release of 2017. As described
in these issues [1][2][3], the upstream CTAN mirrors are a continuously moving
rolling release without historical archives.
This particular FTP server is also a rolling release folling CTAN for the latest
version, but it has snapshots of the final texlive releases; it appears that the
2017 distribution has been unmodified since texlive-2018 was released earlier
this year.
Along the way, we needed to fix several issues:
due to insufficient permissions.
read-only, so it couldn't patch and modify the scripts. This commit removes it
for now, but that's not a particularly satisfying solution. Ideas?
This also adds some documentation on the upgrade process to prepare for
texlive-2018 [4].
This commit also replaces the sha1 hashes with upstream's standard sha512 hashes.
It appears the motivation for the shorter hashes was to save disk space in the
derivations; in master, the size of this directory is 1012K; in this commit it
is 1600K. The difference is not particularly large, and the downsides to using
our own sha1 hashes are:
download all upstream tarballs by sha512 hash, then run the fix script, then
rebuild with sha1 hashes.
immediately verify that the hashes we're providing match upstream, or match
the snapshot in time.
to build, it's useful to be able to determine if the sha mismatch is because
of an update or not; if we have a sha1 mismatch and no tarball to pull, we
can't figure out which sha512sum would have produced that sha1.
content-addressed mirrors on IPFS and @veprbl's servers as much.
seems some FTP servers have more/less than others, or older/newer packages. If
we know what we're looking for beforehand and we're just missing a few
packages whose hashes match the advertised hashes upstream, it's easier to find.
[1] #24683
[2] #10026
[3] #34490
[4] #40232
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)