fritzing: 0.9.3b -> 0.9.4 #98381

avdv · 2020-09-21T08:47:09Z

Motivation for this change

Fritzing does not build currently, because it is not compatible with libgit2 1.x (they are using libgit 0.28.1 -- see https://github.com/fritzing/fritzing-app/blob/a799673d7f79a619d8c94a87d07cf0cebde1b1d9/.travis.yml#L87)

Also, a new version has been released on Dec, 1st 2019. See https://github.com/fritzing/fritzing-app/releases/tag/CD-498 (I could also separate the patches, if we only want to backport the fix of 0.9.3b to the release-20.09 branch).

Since their build scripts are a bit unorthodox, and I did not want to replicate all the different steps in the nixpkgs build again, I chose to patch the tools/linux_release_script/release.sh.

Caveat: I did only fix the build on Linux, since I cannot test on macOS. Should we use broken = lib.isDarwin here?

Things done

ajs124 · 2020-09-21T13:31:05Z

#98277 also attempted this, but is marked as a draft.

risicle · 2020-09-21T20:16:47Z

Builds & runs for me, non-nixos linux x86_64.

avdv

#98277 also attempted this, but is marked as a draft.

@Sohalt I started to look into this on Friday, and didn't look back if there was something for fritzing... :-)

Maybe you can test this PR too. 👍

avdv · 2020-09-21T17:07:03Z

pkgs/applications/science/electronics/fritzing/default.nix

-    repo = "fritzing-parts";
-    rev = version;
-    sha256 = "1d2v8k7p176j0lczx4vx9n9gbg3vw09n2c4b6w0wj5wqmifywhc1";
+  parts = fetchgit {


I switched to fetchgit because fritzing tries to access the git repository and extract the Sha from it. So, I thought it would need the .git folder at runtime, but then I chose to hardcore the Sha into the program as a string literal.

This means it could be switched back to fetchFromGithub again...

Yeah we usually just patch out attempts at that kind of thing.

Sohalt · 2020-09-22T10:18:34Z

#98277 also attempted this, but is marked as a draft.

@Sohalt I started to look into this on Friday, and didn't look back if there was something for fritzing... :-)

Maybe you can test this PR too. +1

Tested and works for me 👍 Thank you!

The AUR package adds a patch to allow using a different fritzing-parts repository than the one that they ship.
I don't know how often the parts library will get updated and how fast that update would land in nixpkgs, but seeing how it has been broken for a while I think it might take its time. The patch would somewhat help with that (but it would also conflict with your current solution of hardcoding the SHA).

avdv · 2020-09-22T11:45:18Z

The AUR package adds a patch to allow using a different fritzing-parts repository than the one that they ship.
I don't know how often the parts library will get updated and how fast that update would land in nixpkgs, but seeing how it has been broken for a while I think it might take its time. The patch would somewhat help with that (but it would also conflict with your current solution of hardcoding the SHA).

That could be an improvement, indeed. But then, the latest fritzing-parts commit is from 19 Sep 2019. Almost seems like a wasted feature, being able to check and update the parts if there are no updates for months...

oxzi

Thanks a lot for this Pull Request. I was just working on the same and thought about checking for existing PRs in the middle of it.

You do not need to use an old libgit2 version. There is already a patch upstream which we can backport. I have successfully tested your suggested PR with the following diff.

--- a/pkgs/applications/science/electronics/fritzing/default.nix
+++ b/pkgs/applications/science/electronics/fritzing/default.nix
@@ -1,5 +1,5 @@
-{ mkDerivation, stdenv, fetchgit, fetchFromGitHub, qmake, pkgconfig
-, qtbase, qtsvg, qttools, qtserialport, boost, libgit2_0_27
+{ mkDerivation, stdenv, fetchgit, fetchpatch, fetchFromGitHub, qmake, pkgconfig
+, qtbase, qtsvg, qttools, qtserialport, boost, libgit2
 }:

 let
@@ -30,7 +30,13 @@ mkDerivation rec {
     sha256 = "0spka33a5qq34aq79j01arw1aly4vh0hzv7mahryhdlcdk22qqvc";
   };

-  buildInputs = [ qtbase qtsvg qtserialport boost libgit2_0_27 ];
+  patches = [(fetchpatch {
+    name = "fix-libgit2-version.patch";
+    url = "https://github.com/fritzing/fritzing-app/commit/472951243d70eeb40a53b1f7e16e6eab0588d079.patch";
+    sha256 = "0v1zi609cjnqac80xgnk23n54z08g1lia37hbzfl8jcq9sn9adak";
+  })];
+
+  buildInputs = [ qtbase qtsvg qtserialport boost libgit2 ];

   nativeBuildInputs = [ qmake pkgconfig qttools ];

pkgs/applications/science/electronics/fritzing/default.nix

oxzi · 2020-09-24T10:39:07Z

pkgs/applications/science/electronics/fritzing/default.nix

 mkDerivation rec {
  pname = "fritzing";
-  version = "0.9.3b";
+  version = "0.9.4";


Perhaps the fritzingTag should also be added to the version, because there multiple 0.9.4 releases, e.g., CD-415 and CD-498.

Suggested change

version = "0.9.4";

version = "0.9.4-${fritzingTag}";

I would not want to add this, as it looks ugly to me and is just a (mostly) random number. If this ever happens again and make multiple releases for a version, we might simply append a rev number at the end.

Otherwise, we could just append the build number, without the CD prefix...?!

I totally feel you and also consider it to be unaesthetic. However, the project does not use semantic versioning and "0.9.4" is ambiguous. Just adding the build number is also fine for me. I just want to be able to distinguish versions.

OK, I changed the version to include the build number. I can squash the commits if wanted, or someone squashes when merging...

Squashing those into one commit sounds good, I think. Otherwise this PR looks good to me, thanks again (:

Added an overlay based on NixOS/nixpkgs#98381

Notes: * fritzing still needs an older version of libgit2 * releases no longer directly correspond to tags in the git repository, they are using build numbers instead * the fritzing-parts repository is no longer versioned at all, the master branch contains the latest stable release * a `parts.db` file needs to be generated from the fritzing-parts files during the build

avdv · 2020-10-05T07:03:47Z

I have squashed the changes together. Should be ready to merge now.

Caveat: I did only fix the build on Linux, since I cannot test on macOS. Should we use broken = lib.isDarwin here?

I have just noticed that this package has platforms = stdenv.lib.platforms.linux, so this should not be an issue right now.

oxzi

Tested successfully, LGTM.

jonringer

this looks to be correctly wrapped, however, I'm unable to open some qt plugins, so it fails to open:

[nix-shell:~/.cache/nixpkgs-review/pr-98381-1]$ ./results/fritzing/bin/Fritzing
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-org.kde.kwin.qpa, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Aborted (core dumped)

avdv · 2020-10-11T18:30:33Z

this looks to be correctly wrapped, however, I'm unable to open some qt plugins, so it fails to open:

@jonringer could you run it while setting QT_DEBUG_PLUGINS=1 to shed some light why this happens on your system?

jonringer

I'm now able to open it fine. Not sure what changed, but the expression seems to follow nixpkgs Qt norms.

diff LGTM
gui launches fine

Notes: * fritzing still needs an older version of libgit2 * releases no longer directly correspond to tags in the git repository, they are using build numbers instead * the fritzing-parts repository is no longer versioned at all, the master branch contains the latest stable release * a `parts.db` file needs to be generated from the fritzing-parts files during the build (cherry picked from commit 0f6b8b7) Otherwise it wouldn't build. Master PR: #98381.

ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 10.rebuild-linux: 1 labels Sep 21, 2020

avdv commented Sep 22, 2020

View reviewed changes

oxzi reviewed Sep 24, 2020

View reviewed changes

pkgs/applications/science/electronics/fritzing/default.nix Outdated Show resolved Hide resolved

oxzi reviewed Sep 24, 2020

View reviewed changes

oxzi added a commit to hackspace-marburg/co2ampel that referenced this pull request Sep 24, 2020

Nix: Fritzing to draw circuits

2120cc8

Added an overlay based on NixOS/nixpkgs#98381

avdv force-pushed the fritzing-0.9.4 branch from 530014c to 9ca3de9 Compare October 5, 2020 07:02

oxzi approved these changes Oct 5, 2020

View reviewed changes

risicle mentioned this pull request Oct 10, 2020

ZERO Hydra Failures 20.09 #97479

Closed

jonringer reviewed Oct 10, 2020

View reviewed changes

jonringer approved these changes Oct 11, 2020

View reviewed changes

jonringer merged commit 0f6b8b7 into NixOS:master Oct 11, 2020

avdv deleted the fritzing-0.9.4 branch October 12, 2020 06:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fritzing: 0.9.3b -> 0.9.4 #98381

fritzing: 0.9.3b -> 0.9.4 #98381

avdv commented Sep 21, 2020 •

edited

Loading

ajs124 commented Sep 21, 2020

risicle commented Sep 21, 2020

avdv left a comment

avdv Sep 21, 2020

risicle Sep 22, 2020

Sohalt commented Sep 22, 2020

avdv commented Sep 22, 2020

oxzi left a comment

oxzi Sep 24, 2020

avdv Sep 28, 2020

oxzi Sep 29, 2020

avdv Sep 29, 2020

oxzi Sep 30, 2020

avdv commented Oct 5, 2020

oxzi left a comment

jonringer left a comment

avdv commented Oct 11, 2020

jonringer left a comment

fritzing: 0.9.3b -> 0.9.4 #98381

fritzing: 0.9.3b -> 0.9.4 #98381

Conversation

avdv commented Sep 21, 2020 • edited Loading

Motivation for this change

Things done

ajs124 commented Sep 21, 2020

risicle commented Sep 21, 2020

avdv left a comment

Choose a reason for hiding this comment

avdv Sep 21, 2020

Choose a reason for hiding this comment

risicle Sep 22, 2020

Choose a reason for hiding this comment

Sohalt commented Sep 22, 2020

avdv commented Sep 22, 2020

oxzi left a comment

Choose a reason for hiding this comment

oxzi Sep 24, 2020

Choose a reason for hiding this comment

avdv Sep 28, 2020

Choose a reason for hiding this comment

oxzi Sep 29, 2020

Choose a reason for hiding this comment

avdv Sep 29, 2020

Choose a reason for hiding this comment

oxzi Sep 30, 2020

Choose a reason for hiding this comment

avdv commented Oct 5, 2020

oxzi left a comment

Choose a reason for hiding this comment

jonringer left a comment

Choose a reason for hiding this comment

avdv commented Oct 11, 2020

jonringer left a comment

Choose a reason for hiding this comment

avdv commented Sep 21, 2020 •

edited

Loading