• 3 Posts
  • 9 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle






  • sashkatoFirefoxBest Firefox Extensions?
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago
    • My O’Reilly Downloader - if you have an account already, but want to persist some material to peruse at a later time
    • TreeStyleTab
    • ContainerProxy - I have mullvad running in gluetun container on my desktop PC, and it exposes HTTP proxy endpoint over Tailscale, so I can have VPN for my webbrowsing, without having to connect. This does not give me full protection, but I use tailscale a lot, and it doesn’t play well with Mullvad.
    • I Still don’t care about cookies

  • I wanted to say thanks for the detailed post.

    I was able to make some progress on packaging the project. A few issues I faced:

    • node2nix was not including devDependencies by default. It’s possible with the -d flag, but that would include all devDependencies into the final build, and I could not find a way to remove that for production build.
    • I tried skipping node2nix, and simply included package-lock.json file, this worked, but there were more difficulties
    • Machines (the plugin) requires source repository of the cockpit-project. I first tried building the plugin from the cockpit-project package, but that did not seem very clean. I then created a separate package like you suggested, and listed 2 project sources, that seemed a bit cleaner, and now that package can be included from cockpit-project package, avoiding circular dependency.
    • This all worked! Great! I had modified the cockpit-project package to include the plugin, and was able to have the package successfully (or so…) and copy it over so it’s found.
    • And yet, there does not seem to be clear compatibility matrix between the cockpit-project, and the plugins. Makefile for the machines plugin simply includes the commit hash of the parent project, and includes its libraries in the build process.
    • Unfortunately, the build did not result in the working plugin, and this is where my expertise in troubleshooting node applications comes to a limit.

    Despite the failure of the outcome (I don’t think I am willing to invest more time into this build right now) I learned a ton about building nix derivations, packaging software, and various troubleshooting tips.

    I was able to hack on a project really successfully, using nix repl. However, to test that on my system, I had to fork nixpkgs, include that in my flakes, and rebuild the system. I would like to find a more isolated, easier way to test my packages, without affecting my main system.