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

zoom-us: 5.0.399860.0429 -> 5.0.403652.0509 #87686

Merged
merged 1 commit into from May 13, 2020

Conversation

lovesegfault
Copy link
Member

Motivation for this change

Zoom complained it was out of date

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

Copy link
Member

@kini kini left a comment

Choose a reason for hiding this comment

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

lgtm

Copy link
Contributor

@doronbehar doronbehar left a comment

Choose a reason for hiding this comment

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

Builds and works fine when rebased on latest nixos-unstable channel 👍.

@garbas garbas merged commit 2b51171 into NixOS:master May 13, 2020
@obadz
Copy link
Contributor

obadz commented May 14, 2020

Btw does anyone know why the zoom "build" takes so long? nix-top only shows bash running and yet it takes minutes to do something, just not sure what?

@doronbehar
Copy link
Contributor

Yea I also noticed that and it seemed peculiar, it happens here for me:

automatically fixing dependencies for ELF files
warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/nix/store/dcj8q73hv242xxzcgiq3hrk8z40m0f17-zoom-us-5.0.403652.0509/share/zoom-us/.ZoomLauncher-wrapped’
searching for dependencies of /nix/store/dcj8q73hv242xxzcgiq3hrk8z40m0f17-zoom-us-5.0.403652.0509/share/zoom-us/.ZoomLauncher-wrapped

I think it's autopatchelfHook that's running there at that "almost stale" phase and it's here where stuff happen:

echo "searching for dependencies of $toPatch" >&2
# We're going to find all dependencies based on ldd output, so we need to
# clear the RPATH first.
patchelf --remove-rpath "$toPatch"
local missing="$(
ldd "$toPatch" 2> /dev/null | \
sed -n -e 's/^[\t ]*\([^ ]\+\) => not found.*/\1/p'
)"
# This ensures that we get the output of all missing dependencies instead
# of failing at the first one, because it's more useful when working on a
# new package where you don't yet know its dependencies.
local -i depNotFound=0
for dep in $missing; do
echo -n " $dep -> " >&2
if findDependency "$dep" "$(getSoArch "$toPatch")"; then
rpath="$rpath${rpath:+:}${foundDependency%/*}"
echo "found: $foundDependency" >&2
else
echo "not found!" >&2
depNotFound=1
fi
done
# This makes sure the builder fails if we didn't find a dependency, because
# the stdenv setup script is run with set -e. The actual error is emitted
# earlier in the previous loop.
[ $depNotFound -eq 0 ]
if [ -n "$rpath" ]; then
echo "setting RPATH to: $rpath" >&2
patchelf --set-rpath "$rpath" "$toPatch"
fi

Though I have no idea what makes that function slow.

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

5 participants