Arch Linux User Repository

Please do not flag this package out of date unless there is source code available for a newer version than represented here. Unfortunately, upstream is very reluctant in releasing their GPL3 licensed code to the public.

See:

https://github.com/fritzing/fritzing-app/issues/3876

https://github.com/fritzing/fritzing-app/issues/3881

https://forum.fritzing.org/t/can-t-find-source-code/19723

https://github.com/fritzing/fritzing-app/issues/4070

ericfont: No need to downgrade libgit2. You just need to rebuild Fritzing after the libgit2 update. This happens regularly.

Hi ! The issue with libgit2 doesn't seems to be solved :

Project ERROR: libgit2 include path not found in /fritzing/src/fritzing-app-CD-498/../libgit2/include

cliffordwhansen: Thanks for figuring this out! I included the patch here.

Tired to installed this today and ran in to a libgit2 version issue, there is a fix in the Fritzing dev branch[1]:

src/version/partschecker.cpp

118 -: #if LIBGIT2_VER_MINOR > 24
118 +: #if LIBGIT2_VER_MAJOR > 0 || (LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR > 24)

[1] https://github.com/fritzing/fritzing-app/commit/472951243d70eeb40a53b1f7e16e6eab0588d079

cgirard: The reason was that we need to call Fritzing during package() in order to generate the parts database. However, I just pushed a change that works around this problem. Could you please retry?

Why is this package requiring a display to build?

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: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

/startdir/PKGBUILD: line 53:  3924 Aborted                 (core dumped) "${pkgdir}"/usr/bin/Fritzing -db "${pkgdir}"/usr/share/fritzing/fritzing-parts/parts.db -pp "${pkgdir}"/usr/share/fritzing/fritzing-parts -f "${pkgdir}"/usr/share/fritzing

Ha! It turns out having a valid git repository is only required for generating the parts.db sqlite database (and for updating, which does not work with the system installation of the parts library anyway). So we can live with the shared repository during package() and then just drop the .git entirely.

I updated the package accordingly. If there are any issues, please report.

Ok, I see what you mean now. I still don't think even like this it is going to cause issues to Fritzing, the system-wide parts should not be updated either by Fritzing or the user. Still, if you want this to be correct just in case, doing

git -C "${pkgdir}"/usr/share/fritzing/fritzing-parts repack -a
git -C "${pkgdir}"/usr/share/fritzing/fritzing-parts remote set-url origin "https://github.com/fritzing/fritzing-parts"
git -C "${pkgdir}"/usr/share/fritzing/fritzing-parts branch -m master
git -C "${pkgdir}"/usr/share/fritzing/fritzing-parts branch --set-upstream-to=origin/master
rm "${pkgdir}"/usr/share/fritzing/fritzing-parts/.git/objects/info/alternates

should be enough. On the other side I can see how this is still no ideal either, at least it is not clean. My main issue with doing it in package(), is that the PKGBUILD forces re-downloads of the same data for successive re-builds, which can be an issue for metered connections.

Yes, the fragment is a so-called shared clone of the bare repo, created with git clone -s. It's a git repository without the actual git data files. Instead it contains a reference to the location of the bare repository, where all the git objects can be found.

One could transform this shared repository into a complete one using git repack -a but then still the "origin" repository is the bare repository in the build directory and not the upstream fritzing-parts repository. So I think, just sticking to the git clone within package() is the easiest solution, even if it may be a bit unconventional.

Personally I think it's a bit of a mess that Fritzing needs an actual git clone of its parts library as part of its installation. Upstream is currently rethinking how the parts library should be shipped, hopefully making packaging a bit easier in future.

Bevan

• I see what you are saying about the version.

• Yes, pacman clones a bare repo first, which can then be updated for later versions. For the build process it clones a fragment. Do you mean that the fragment is "without the actual objects"? and what do you mean by that?

• The best reason I can think of is the shared SRCDEST directory supported by makepkg. CD-415.tar.gz has very little meaning after some time in a directory with hundreds of other files. fritzing-0.9.4b.tar.gz is more descriptive.

loathingkernel: Thanks for your suggestions. With some of those I fully agree. With some not necessarily:

• If you ask the source code, you will get different opinions on the version string, so I'd rather not worry about that:

  • https://github.com/fritzing/fritzing-app/blob/CD-415/org.fritzing.Fritzing.appdata.xml#L47
  • https://github.com/fritzing/fritzing-app/blob/CD-415/fritzing.rc#L6
  • https://github.com/fritzing/fritzing-app/blob/CD-415/FritzingInfo.plist#L32

• Cloning the git as part of the sources: I'll try that but I remember that makepkg will separate the git repo itself and the working copy, so we would have to manually merge that again within package(). Also we would have to clone all branches and not just master. I'll try and see how it behaves.

Edit: Pacman does two git clones. One is a bare repository, the other one is a shared one without the actual objects. None of these are usable by Fritzing.

Regarding the remaining request: I don't rename the source tarball in the PKGBUILD and I do not see a reason to do so. Is there any?