Trying to package Everdo for NixOS (core dumped)

I’m on a Linux distro called NixOS, and I’ve gone as far as I can towards packaging Everdo:

>  everdo
Trace/breakpoint trap (core dumped)
Jun 15 09:39:26 whittles-iskandar kernel: traps: ThreadPoolForeg[15369] trap int3 ip:55e4e1e0dc03 sp:7f9944ab3fe0 error:0 in everdo[55e4e1578000+60cd000]
Jun 15 09:39:26 whittles-iskandar systemd[1]: Started Process Core Dump (PID 15387/UID 0).
Jun 15 09:39:26 whittles-iskandar systemd-coredump[15388]: Resource limits disable core dumping for process 15360 (everdo).
Jun 15 09:39:26 whittles-iskandar systemd-coredump[15388]: The core will not be stored: size 18446744073709551615 is greater than 804257792 (the configured maximum)
Jun 15 09:39:26 whittles-iskandar systemd-coredump[15388]: e]8;;man:core(5)[🡕]e]8;; Process 15360 (everdo) of user 1000 dumped core.                                        
Jun 15 09:39:26 whittles-iskandar systemd[1]: systemd-coredump@22-15387-0.service: Succeeded.

Here’s what I’ve done: Everdo: init at 1.5.14 · WhittlesJr/nixpkgs@dc5a4eb · GitHub

NixOS is different from most Linux distros in that it does not use universal paths for its files, like /opt/Everdo/everdo. Instead, it stores packages off under unique locations based on the hash of its contents, like /nix/store/ar3b6abcjsda54j6c16ilzwhvywnp3zx-everdo-1.5.14/lib/everdo. These are linked together on a per-version basis, so when I upgrade, the old stuff remains but new stuff gets added, and pointers essentially switch over to the new version.

All that to say, if your application is trying to call something under /bin/ or some other hard-coded location, that could be the culprit.

That core dump size is frightening…

The application code definitely doesn’t refer to any paths outside of the user directory, specifically /home/user/.config/everdo.

The issue must be with the underlying platform - Electron/Chromium.

Oof… I’m very late to this thread, but I’ve been using Everdo on NixOS for more than a year by now! Unfortunately I’ve never bothered sending my derivation to Nixpkgs :’)

Everdo is mostly a vanilla Electron-based package, with the only exception being the (bundled) native dependency on SQLite (hence .asar unpacking/repacking during postPatch phase below).

Here’s my fully working derivation:

{ stdenv, fetchurl, autoPatchelfHook, makeWrapper, asar, dpkg, electron }:

stdenv.mkDerivation rec {
  name = "everdo-${version}";
  version = "1.5.14";

  src = fetchurl {
    url = "https://d11l8siwmn8w36.cloudfront.net/${version}/everdo_${version}_amd64.deb";
    hash = "sha256-erFYoYhVrxt+iT3B2kG4uAp39+ZLdCfTi1QC8q7uPbU=";
  };

  nativeBuildInputs = [ autoPatchelfHook makeWrapper asar dpkg ];
  buildInputs = [ stdenv.cc.cc ];

  sourceRoot = ".";

  unpackCmd = "dpkg-deb -x $src .";

  postPatch = ''
    asar e opt/Everdo/resources/app.asar app
    autoPatchelf app
    asar p app opt/Everdo/resources/app.asar
  '';

  installPhase = ''
    mkdir -p $out/bin

    cp -r usr/share $out/share
    cp -r opt/Everdo/resources $out/share/everdo

    substituteInPlace $out/share/applications/everdo.desktop \
      --replace /opt/Everdo/everdo $out/bin/everdo

    makeWrapper ${electron}/bin/electron $out/bin/everdo \
      --add-flags $out/share/everdo/app.asar
  '';
}

cc @WhittlesJr

1 Like

My hero! swoons

Thank you so much for sharing this. I encourage you to put up a PR. It could even have a module, or I’d be happy to write one.

1 Like