staging-next #44867
Merged
staging-next #44867
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/libyaml/versions. These checks were done: - built on NixOS - 0 of 0 passed binary check by having a zero exit code. - 0 of 0 passed binary check by having the new version present in output. - found 0.2.1 with grep in /nix/store/bn221ypclyhac7pzicwf0kj7b6g03d4v-libyaml-0.2.1 - directory tree listing: https://gist.github.com/a183f8e1406cfb340cfc7e4809746583 - du listing: https://gist.github.com/6731d94c1363109427d6793cc7cd010a
Don't know that there's a reason to keep the patch level fixed at 0, optimistically bumping to latest (6).
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: - xindy: if $HOME is unset, it will try to mkdir /homeless-shelter, which fails due to insufficient permissions. - scheme-infraonly: this scheme had symlinks into other releases that were 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: - More nix code to maintain - Multi-step upgrade process for maintainers: the maintainer first has to download all upstream tarballs by sha512 hash, then run the fix script, then rebuild with sha1 hashes. - Less transparent. If we use the upstream sha512 hashes, any user can immediately verify that the hashes we're providing match upstream, or match the snapshot in time. - Easier to debug. Since upstream is rolling and packages may disappear or fail 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. - Less trust required. Due to the above, users don't have to trust the content-addressed mirrors on IPFS and @veprbl's servers as much. - Easier to cobble together a source distribution from a variety of sources. It 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
2.10 is the appropriate version for latest texlive 2017.
ncurses: patch wrong st-0.7 terminfo
|
This is probably fixed by #44719 |
There are security fixes for a few packages (and other changes).
Hydra: ?compare=1474536
b1548ce dropped the C compiler prefix
38eea80 dropped the C and C++ compiler prefixes. Probably more work is needed to make cross work, but this at least helps preserve/establish the pattern.
sometimes we want the "SDK" version from xcbuild so we do something like: $ xcbuild -version -sdk MacOSX10.10 SDKSettings.plist - MacOSX10.10 (MacOSX10.10) SDKVersion: 10.10 Path: /nix/store/6k7crm1n4drf09ga0dwvbmb59x4zl2i2-SDKs/MacOSX10.10.sdk PlatformPath: /nix/store/vhfwb1znfy65s2xs27j8xribk6mp6lbw-Platforms/MacOSX.platform ProductName: Mac OS X ProductVersion: 10.10 This was previously overriden by the current xcode version so you would get: Xcode 9.4.1 Build version 17E189 This should fix the other usage of -version in nodejs 6.x.
Some packages just can't handle them #44767. It was tempting to try to abstract this in some way, but I didn't do that ATM.
|
Remaining regressions affecting multiple packages:
|
|
Current comparison link for the lazy: https://hydra.nixos.org/eval/1474723?compare=1474536 I think it's already acceptable for merge to master (or close to that), given there are some security fixes included. |
|
I agree. Note the merge conflict. |
|
I was able to build both latest firefox and tor-browser on top of this branch with the following diff applied
```diff
diff --git a/pkgs/applications/networking/browsers/firefox/common.nix b/pkgs/applications/networking/browsers/firefox/common.nix
index 8b93c952a81..ed8446a4aa4 100644
--- a/pkgs/applications/networking/browsers/firefox/common.nix
+++ b/pkgs/applications/networking/browsers/firefox/common.nix
@@ -147,21 +147,21 @@ stdenv.mkDerivation (rec {
rm -f configure
rm -f js/src/configure
rm -f .mozconfig*
'' + (if lib.versionAtLeast version "58"
# this will run autoconf213
then ''
configureScript="$(realpath ./mach) configure"
'' else ''
make -f client.mk configure-files
configureScript="$(realpath ./configure)"
- '') + ''
+ '') + lib.optionalString (!isTorBrowserLike) ''
export MOZCONFIG=$(pwd)/mozconfig
# Set C flags for Rust's bindgen program. Unlike ordinary C
# compilation, bindgen does not invoke $CC directly. Instead it
# uses LLVM's libclang. To make sure all necessary flags are
# included we need to look in a few places.
# TODO: generalize this process for other use-cases.
BINDGEN_CFLAGS="$(< ${stdenv.cc}/nix-support/libc-cflags) \
$(< ${stdenv.cc}/nix-support/cc-cflags) \
@@ -196,22 +196,22 @@ stdenv.mkDerivation (rec {
#"--enable-system-cairo"
"--enable-startup-notification"
#"--enable-content-sandbox" # TODO: probably enable after 54
"--disable-tests"
"--disable-necko-wifi" # maybe we want to enable this at some point
"--disable-updater"
"--enable-jemalloc"
"--disable-maintenance-service"
"--disable-gconf"
"--enable-default-toolkit=${default-toolkit}"
- "--disable-xcode-checks"
]
+ ++ lib.optional stdenv.isDarwin "--disable-xcode-checks"
++ lib.optional (lib.versionOlder version "61") "--enable-system-hunspell"
++ lib.optionals (lib.versionAtLeast version "56" && !stdenv.hostPlatform.isi686) [
# on i686-linux: --with-libclang-path is not available in this configuration
"--with-libclang-path=${llvmPackages.libclang}/lib"
"--with-clang-path=${llvmPackages.clang}/bin/clang"
]
++ lib.optionals (lib.versionAtLeast version "57") [
"--enable-webrender=build"
]
```
but it's a hack as these things should depend on firefox versions, but I'm too lazy to check all the variants and modify the expression (and I can't on Darwin). Beats the failing build, though.
The main problem is that putting `BINDGEN_CFLAGS` into mozconfig makes configure phase barf some crazy errors in firefoxPackages that are or based of older firefoxes.
|
... to fix build; vcunat included the old ESR firefox, too.
|
@oxij: thanks! I made you the author. |
|
I think I'll let someone else stabilize at least one following staging iteration. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tracking the next merge iteration.