Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

firefox: 82.0.3 -> 83.0, firefox-esr: 78.4.1esr -> 78.5.0esr, nss: 3.56 -> 3.58, cacert refactor #104176

Merged
merged 8 commits into from Nov 18, 2020

Conversation

andir
Copy link
Member

@andir andir commented Nov 18, 2020

Motivation for this change

This updates the firefox source packages to the latest upstream version.

This is the continued work of #104051 & #100765.

In #100765 @vcunat pointed out that we could decouple cacert from the NSS package to make it more rebuild friendly. Just rebuilding packages that depend on NSS seems to be about ~100. Rebuilding all the packages that depend on cacert is >9k as of this writing.This makes it much more feasible to upgrade high-profile packages that are (rightfully) pedantic on their NSS version like firefox and thunderbird.

Things done
  • firefox NixOS test executed
  • firefox-esr NixOS test executed
  • thunderbird pinned to older NSS version (FIXME!)
  • verified that pipewire still works

Paging @vcunat and @ajs124 for the NSS & cacert changes, @worldofpeace & @mweinelt for the pipewire functionality and finally @stigtsp and @taku0 for the actual firefox change. :)

] ++

# there are two flavors of pipewire support
# The patches for the ESR release and the patches for the current stable
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this paragraph looks weird. I should reflow/refromat/reword it.

];

MACH_USE_SYSTEM_PYTHON = "1";

postPatch = ''
rm -rf obj-x86_64-pc-linux-gnu
'' + lib.optionalString pipewireSupport ''
'' + lib.optionalString (pipewireSupport && lib.versionOlder ffversion "83") ''
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@worldofpeace & @mweinelt can you also test pipewire on the esr build? If it didn't and does not work we can remove this section (and the entire old patch).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building everything as we speak.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pipewire works on 78.5.0esr, had linker problems on the firefox 83.0 build, retrying that right now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure your /tmp has enough inodes as otherwise the build fails frequently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't work with Firefox 83.0 unfortunately. When trying to share my screen I only see "Use operating system settings". I see no reaction in the pipewire unit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shrug shall we disable it then? I have zero clues how to debug this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Go ahead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am tempted to keep them enabled as they are now.. Things will not work entirely but maybe it is also an environmental thing and works for someone else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine with me.

@ajs124
Copy link
Member

ajs124 commented Nov 18, 2020

Shouldn't we go with NSS 3.53 instead of 3.57 for ESR? 3.53 is an NSS ESR release, whereas I don't think 3.57 is.

@andir
Copy link
Member Author

andir commented Nov 18, 2020

Shouldn't we go with NSS 3.53 instead of 3.57 for ESR? 3.53 is an NSS ESR release, whereas I don't think 3.57 is.

Sounds reasonable. I'll update the PR.

@vcunat
Copy link
Member

vcunat commented Nov 18, 2020

NOTE: Whenever you update this version also update the cacert package
with a PR to staging. cacert is decoupled from this to reduce the
amount of unnecessary rebuilds while both a built from the same
source project.

Maybe we could use a script to compare whether this makes a difference and thus avoid generating meaningless rebuilds even on staging. For example, I compared the current difference (3.57 vs 3.59) and the cert bundles are binary equal.

EDIT: it could be simple... like cacert.overrideAttrs (a_:{ inherit (nss) src version; }). (after switching to pname to avoid confusion)

@andir
Copy link
Member Author

andir commented Nov 18, 2020

NOTE: Whenever you update this version also update the cacert package
with a PR to staging. cacert is decoupled from this to reduce the
amount of unnecessary rebuilds while both a built from the same
source project.

Maybe we could use a script to compare whether this makes a difference and thus avoid generating meaningless rebuilds even on staging. For example, I compared the current difference (3.57 vs 3.59) and the cert bundles are binary equal.

EDIT: it could be simple... like cacert.overrideAttrs (a_:{ inherit (nss) src version; }). (after switching to pname to avoid confusion)

Yeah that might work. I've been looking at the script that we run on the source tree and did wonder if we couldn't have a fetcher that extracts just the data that we care about but that would duplicate a lot of the logic that is in the script :/

@vcunat
Copy link
Member

vcunat commented Nov 18, 2020

We could make it a fixed-output derivation, but that wouldn't really remove the necessity to check if something's changed. (and the switch wouldn't be trivial, due to us wanting two outputs)

@andir
Copy link
Member Author

andir commented Nov 18, 2020

We could make it a fixed-output derivation, but that wouldn't really remove the necessity to check if something's changed. (and it wouldn't be trivial, due to us wanting two outputs)

Lets scratch the fixed output idea for now.

Where would you put that check script?

This would probably be sufficient to check if we have to update the sources of cacerts:

#!/usr/bin/env nix-shell
#!nix-shell -i bash -p nix

# Build both the cacert package and an overriden version where we use the source attribute of NSS.
# Cacert and NSS are both from the same upstream sources. They are decoupled as
# the cacert output only cares about a few infrequently changing files in the
# sources while the NSS source code changes frequently.
#
# By having cacert on a older source revision that produces the same
# certificate output as a newer version we can avoid large amounts of
# unnecessary rebuilds.
#
# As of this writing there are a few magnitudes more packages depending on
# cacert than on nss.


set -ex

BASEDIR="$(dirname "$0")/../../../.."


CURRENT_PATH=$(nix-build --no-out-link -A cacert.out)
PATCHED_PATH=$(nix-build --no-out-link -E 'with import ./. {}; (cacert.overrideAttrs (_: { inherit (nss) src version; })).out')

# Check the hash of the etc subfolder
# We can't check the entire output as that contains the nix-support folder
# which contains the output path itself.
CURRENT_HASH=$(nix-hash "$CURRENT_PATH/etc")
PATCHED_HASH=$(nix-hash "$PATCHED_PATH/etc")

if [[ "$CURRENT_HASH" !=  "$PATCHED_HASH" ]]; then
    echo "mismatch, consider updating"
    exit 1
fi

@vcunat
Copy link
Member

vcunat commented Nov 18, 2020

Maybe into cacert's passthru.updateScript? Though I don't really know any of the auto-updating styles so far.

In [NixOS#100765] @vcunat pointed out that we could decouple cacert from the
NSS package to make it more rebuild friendly. Just rebuilding packages
that depend on NSS seems to be about ~100. Rebuilding all the packages
that depend on cacert is >9k as of this writing. This makes it much more
feasible to upgrade high-profile packages that are (rightfully) pedantic
on their NSS version like firefox and thunderbird.

[NixOS#100765]: NixOS#100765
@andir
Copy link
Member Author

andir commented Nov 18, 2020

Maybe into cacert's passthru.updateScript? Though I don't really know any of the auto-updating styles so far.

Done. I also didn't know much about those before today.. It wasn't that hard to implement. I skipped the pname migration of cacert as that would trigger a mass rebuild.

@andir andir merged commit e5f945b into NixOS:master Nov 18, 2020
andir added a commit that referenced this pull request Nov 19, 2020
This fixes up the changes done in #104176 where I forgot to include this
now required change.
andir added a commit to andir/nixpkgs that referenced this pull request Nov 19, 2020
This fixes up the changes done in NixOS#104176 where I forgot to include this
now required change.

(cherry picked from commit a322b32)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants