summary refs log tree commit diff
Commit message (Collapse)AuthorAge
* python: tqdm: 4.46.0 -> 4.46.1Frederik Rietdijk2020-06-05
|
* python: pandas: 1.0.3 -> 1.0.4Frederik Rietdijk2020-06-05
|
* python: numpy: 1.18.4 -> 1.18.5Frederik Rietdijk2020-06-05
|
* python: ipython: 7.14.0 -> 7.15.0Frederik Rietdijk2020-06-05
|
* Remove fridh as maintainer of older Python packagesFrederik Rietdijk2020-06-05
| | | | I am not interested in maintaining packages for Python < 3.7.
* python3Minimal: override python38, not python3Frederik Rietdijk2020-06-05
| | | | This avoids an infinite recursion, accidentally introduced in b7ff7465401257e9b0814bb68937a494c58de538.
* Merge pull request #89489 from FRidh/optFrederik Rietdijk2020-06-05
|\ | | | | python3Minimal: disable optimizations
| * python3Minimal: disable optimizationsFrederik Rietdijk2020-06-04
| | | | | | | | No point for the bootstrapping.
| * Revert "cpython: Optimize dynamic symbol tables, for a 6% speedup."Frederik Rietdijk2020-06-04
| | | | | | | | | | | | ofborg does not like fetching patches when the derivation is used during bootstrapping. This reverts commit 480c8d199166b2f8cd20e6e245d8a019329ec466.
* | Merge #82342: rustPlatform: increase build-speed of `checkPhase`Vladimír Čunát2020-06-05
|\ \ | | | | | | | | | ...for rust-packages (into staging)
| * | rust: improve docsMaximilian Bosch2020-05-31
| | | | | | | | | | | | | | | Co-authored-by: cole-h <cole.e.helbling@outlook.com> Co-authored-by: asymmetric <lorenzo@mailbox.org>
| * | rust*: add docs for testing packagesMaximilian Bosch2020-05-24
| | | | | | | | | | | | See also https://discourse.nixos.org/t/rust-build-speed-improvements/7225
| * | ripasso-cursive: fix testsMaximilian Bosch2020-05-13
| | | | | | | | | | | | Needed since we store artifacts in `target/<arch>/<profile>`.
| * | gnvim: fix buildMaximilian Bosch2020-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | When running the default builder for Rust, the artifacts would be stored in `target/<arch>/<profile>`, however the `install`-target expects the default structure (`target/<profile>`) of `cargo`-builds. When using the Makefile for building as well, the expected structure is created instead.
| * | nym: fix testsMaximilian Bosch2020-05-13
| | | | | | | | | | | | | | | A lot of tests are using `debug_assert!` which isn't available in release-mode.
| * | cargo-deb: fix buildMaximilian Bosch2020-05-13
| | |
| * | rustPlatform: add `buildAndTestSubdir`-argumentMaximilian Bosch2020-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several tarballs (such as the `rust-lang/rust`-source) with a `Cargo.toml` at root and several sub-packages (with their own Cargo.toml) without using workspaces[1]. In such a case it's needed to move into a subdir to only build the specified sub-package (e.g. `rustfmt` or `rsl`), however the artifacts are at `/target` in the root-dir of the build environment. This breaks the build since `buildRustPackage` searches for executables in `target` (which is at the build-env's root) at the end of the `buildPhase`. With the optional `buildAndTestSubdir`-argument, the builder moves into the specified subdir using `pushd`/`popd` during `buildPhase` and `checkPhase`. Also moved the logic to find executables and libs to the end of the `buildPhase` from a custom `postBuild`-hook to fix packages with custom `build`/`install`-procedures such as `uutils-coreutils`. [1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
| * | rustPlatform: make it possible to override the profile for `cargo test`Maximilian Bosch2020-05-13
| | |
| * | Merge branch 'staging-next' into PR 82342Vladimír Čunát2020-05-11
| |\ \ | | | | | | | | | | | | Hydra nixpkgs: ?compare=1586582
| * | | rustPlatform: fix logMaximilian Bosch2020-05-08
| | | |
| * | | rustPlatform: don't install test executablesMaximilian Bosch2020-05-08
| | | | | | | | | | | | | | | | | | | | This is done by gathering all binaries to install before running the checkPhase.
| * | | rustPlatform: increase build-speed of `checkPhase` for rust-packagesMaximilian Bosch2020-05-06
| | | | | | | | | | | | | | | | | | | | | | | | When running `cargo test --release`, the artifacts from `buildPhase` will be reused here. Previously, most of the stuff had to be recompiled without optimizations.
* | | | nss: 3.52 -> 3.52.1ajs1242020-06-05
| |_|/ |/| | | | | | | | Needed to compile firefox 77. Taken from PR #89438.
* | | Merge pull request #84072 from gnprice/python-buildFrederik Rietdijk2020-06-04
|\ \ \ | | | | | | | | cpython: Use optimizations, for a 25% speedup.
| * | | cpython: Optimize dynamic symbol tables, for a 6% speedup.Greg Price2020-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I took a close look at how Debian builds the Python interpreter, because I noticed it ran substantially faster than the one in nixpkgs and I was curious why. One thing that I found made a material difference in performance was this pair of linker flags (passed to the compiler): -Wl,-O1 -Wl,-Bsymbolic-functions In other words, effectively the linker gets passed the flags: -O1 -Bsymbolic-functions Doing the same thing in nixpkgs turns out to make the interpreter run about 6% faster, which is quite a big win for such an easy change. So, let's apply it. --- I had not known there was a `-O1` flag for the *linker*! But indeed there is. These flags are unrelated to "link-time optimization" (LTO), despite the latter's name. LTO means doing classic compiler optimizations on the actual code, at the linking step when it becomes possible to do them with cross-object-file information. These two flags, by contrast, cause the linker to make certain optimizations within the scope of its job as the linker. Documentation is here, though sparse: https://sourceware.org/binutils/docs-2.31/ld/Options.html The meaning of -O1 was explained in more detail in this LWN article: https://lwn.net/Articles/192624/ Apparently it makes the resulting symbol table use a bigger hash table, so the load factor is smaller and lookups are faster. Cool. As for -Bsymbolic-functions, the documentation indicates that it's a way of saving lookups through the symbol table entirely. There can apparently be situations where it changes the behavior of a program, specifically if the program relies on linker tricks to provide customization features: https://bugs.launchpad.net/ubuntu/+source/xfe/+bug/644645 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637184#35 But I'm pretty sure CPython doesn't permit that kind of trick: you don't load a shared object that tries to redefine some symbol found in the interpreter core. The stronger reason I'm confident using -Bsymbolic-functions is safe, though, is empirical. Both Debian and Ubuntu have been shipping a Python built this way since forever -- it was introduced for the Python 2.4 and 2.5 in Ubuntu "hardy", and Debian "lenny", released in 2008 and 2009. In those 12 years they haven't seen a need to drop this flag; and I've been unable to locate any reports of trouble related to it, either on the Web in general or on the Debian bug tracker. (There are reports of a handful of other programs breaking with it, but not Python/CPython.) So that seems like about as thorough testing as one could hope for. --- As for the performance impact: I ran CPython upstream's preferred benchmark suite, "pyperformance", in the same way as described in the previous commit. On top of that commit's change, the results across the 60 benchmarks in the suite are: The median is 6% faster. The middle half (aka interquartile range) is from 4% to 8% faster. Out of 60 benchmarks, 3 come out slower, by 1-4%. At the other end, 5 are at least 10% faster, and one is 17% faster. So, that's quite a material speedup! I don't know how big the effect of these flags is for other software; but certainly CPython tends to do plenty of dynamic linking, as that's how it loads extension modules, which are ubiquitous in the stdlib as well as popular third-party libraries. So perhaps that helps explain why optimizing the dynamic linker has such an impact.
| * | | cpython: Use autoreconfHook to rebuild configure script.Greg Price2020-05-13
| | | | | | | | | | | | | | | | In particular this will let us use patches that apply to configure.ac.
| * | | cpython: Use --enable-optimizations, for a 16% speedup.Greg Price2020-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this flag, the configure script prints a warning at the end, like this (reformatted): If you want a release build with all stable optimizations active (PGO, etc), please run ./configure --enable-optimizations We're doing a build to distribute to people for day-to-day use, doing things other than developing the Python interpreter. So that's certainly a release build -- we're the target audience for this recommendation. --- And, trying it out, upstream isn't kidding! I ran the standard benchmark suite that the CPython developers use for performance work, "pyperformance". Following its usage instructions: https://pyperformance.readthedocs.io/usage.html I ran the whole suite, like so: $ nix-shell -p ./result."$variant" --run ' cd $(mktemp -d); python -m venv venv; . venv/bin/activate pip install pyperformance pyperformance run -o ~/tmp/result.'"$variant"'.json ' and then examined the results with commands like: $ python -m pyperf compare_to --table -G \ ~/tmp/result.{$before,$after}.json Across all the benchmarks in the suite, the median speedup was 16%. (Meaning 1.16x faster; 14% less time). The middle half of them ranged from a 13% to a 22% speedup. Each of the 60 benchmarks in the suite got faster, by speedups ranging from 3% to 53%. --- One reason this isn't just the default to begin with is that, until recently, it made the build a lot slower. What it does is turn on profile-guided optimization, which means first build for profiling, then run some task to get a profile, then build again using the profile. And, short of further customization, the task it would use would be nearly the full test suite, which includes a lot of expensive and slow tests, and can easily take half an hour to run. Happily, in 2019 an upstream developer did the work to carefully select a more appropriate set of tests to use for the profile: https://github.com/python/cpython/commit/4e16a4a31 https://bugs.python.org/issue36044 This suite takes just 2 minutes to run. And the resulting final build is actually slightly faster than with the much longer suite, at least as measured by those standard "pyperformance" benchmarks. That work went into the 3.8 release, but the same list works great if used on older releases too. So, start passing that --enable-optimizations flag; and backport that good-for-PGO set of tests, so that we use it on all releases.
| * | | cpython: Drop unrecognized --with-threads configure flag.Greg Price2020-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ./configure script prints a warning when passed this flag, starting with 3.7: configure: WARNING: unrecognized options: --with-threads The reason is that there's no longer such a thing as a build without threads. Eliminate the warning, by only passing the flag on the older releases that accept it. Upstream change and discussion: https://github.com/python/cpython/commit/a6a4dc816 https://bugs.python.org/issue31370
* | | | python: coverage: 4.5.4 -> 5.1Vojtěch Káně2020-06-04
| | | |
* | | | ghostscript: 9.50 -> 9.52Martin Milata2020-06-04
| | | | | | | | | | | | | | | | | | | | https://www.ghostscript.com/doc/9.51/News.htm https://www.ghostscript.com/doc/9.52/News.htm
* | | | jbig2dec: 0.17 -> 0.18Martin Milata2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes https://nvd.nist.gov/vuln/detail/CVE-2020-12268 autoreconfHook was added because the build was failing on missing install-sh.
* | | | libexif: 0.6.21 -> 0.6.22Justin Humm2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | Also: - build from git - enable cross compilation
* | | | linux: CONFIG_MOUSE_ELAN_I2C_SMBUS=yAnders Kaseorg2020-06-04
| | | | | | | | | | | | | | | | Signed-off-by: Anders Kaseorg <andersk@mit.edu>
* | | | pcre2: 10.34 -> 10.35R. RyanTM2020-06-04
| | | |
* | | | gdb: 9.1 -> 9.2Lancelot SIX2020-06-04
| | | | | | | | | | | | | | | | | | | | See https://lists.gnu.org/archive/html/info-gnu/2020-05/msg00008.html for release information
* | | | libgpgerror: 1.36 -> 1.38zowoq2020-06-04
| | | | | | | | | | | | | | | | https://github.com/gpg/libgpg-error/blob/libgpg-error-1.38/NEWS
* | | | libssh2: fix broken patch hashBenjamin Hipple2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | Patches from direct URLs on github are not stable (comment headers change w/ server settings), hence why we usually use `fetchpatch`. In lieu of that, vendor the unstable patch.
* | | | perl: 5.30.2 -> 5.30.3volth2020-06-04
| | | |
* | | | python3Packages.cython: 0.29.14 -> 0.29.19Jonathan Ringer2020-06-04
| | | |
* | | | iproute: 5.6.0 -> 5.7.0Michael Weiss2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "As usual lots of small fixes, across many utilities. Several qdisc now have more parameters available. Devlink get most of the fixes." [0] File changes (additions/removals): +share/bash-completion/completions/devlink +share/man/man8/devlink-dpipe.8.gz +share/man/man8/tc-ct.8.gz [0]: https://marc.info/?l=linux-netdev&m=159115579900638
* | | | python3: now points to python38Frederik Rietdijk2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | Note this also means python3Minimal is now also Python 3.8. This reverts commit eb1369670b5a4e616ff0cf4100616479b1fa3064 and adds more.
* | | | meson: fix hash after incorrect mergeFrederik Rietdijk2020-06-04
| | | |
* | | | Revert "Revert "Merge pull request #78910 from serokell/libarchive-zstd""Frederik Rietdijk2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | The PR was accidentally merged into master instead of staging and thus reverted. Now, in staging, we can re-revert it. This reverts commit 4df2f78ec72f6a8d2fe286cd34eb3acdfcac81f3.
* | | | Merge staging-next into stagingFrederik Rietdijk2020-06-04
|\ \ \ \
| * \ \ \ Merge master into staging-nextFrederik Rietdijk2020-06-04
| |\ \ \ \
| | * \ \ \ Merge pull request #88129 from r-ryantm/auto-update/easyrpg-playerLassulus2020-06-04
| | |\ \ \ \ | | | | | | | | | | | | | | easyrpg-player: 0.6.1 -> 0.6.2
| | | * | | | easyrpg-player: 0.6.1 -> 0.6.2R. RyanTM2020-05-19
| | | | | | |
| | * | | | | Merge pull request #88231 from fuwa0529/update-wowneroLassulus2020-06-04
| | |\ \ \ \ \ | | | | | | | | | | | | | | | | wownero: 0.7.0 -> 0.8.0.0
| | | * | | | | wownero: 0.7.0 -> 0.8.0.0fuwa2020-05-20
| | | | | | | |
| | * | | | | | Merge pull request #88444 from lheckemann/freerdp-bumpLassulus2020-06-04
| | |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | freerdp: 2.1.0 -> 2.1.1
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-02 02:18:07 +0000