Trying to package Everdo for NixOS (core dumped)

Support
1

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.

2

That core dump size is frightening…

3

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.

4

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

2 Likes
5

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
6

Has this been submitted to Nixos github? I’d like to see a more standard approach to getting Everdo to work as it’s become one of my core programs. Setup Nixos recently in a VM and very tempted to use it as my main driver and switch out of Arch. Thanks for any help.

P.S. I know I’m replying to an old thread but there aren’t many options.