Package Details: fritzing 0.9.10-1

Git Clone URL: (read-only, click to copy)
Package Base: fritzing
Description: PCB layout prototyping application
Upstream URL:
Licenses: GPL3
Submitter: phects
Maintainer: Bevan
Last Packager: Bevan
Votes: 235
Popularity: 0.39
First Submitted: 2009-05-31 14:31 (UTC)
Last Updated: 2022-06-08 18:53 (UTC)

Pinned Comments

Bevan commented on 2022-04-02 08:37 (UTC)

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

Latest Comments

Bevan commented on 2022-06-10 19:19 (UTC)

koreymk: I cannot reproduce that. We explicitly patch fritzing to not look for libgit2 at that location. Could you please try removing /home/korey/.cache/yay/fritzing before trying the build or, if that does not help, building the package manually instead of using yay?

koreymk commented on 2022-06-10 18:50 (UTC)

Fritzing fails to build.

Project ERROR: libgit2 include path not found in /home/korey/.cache/yay/fritzing/src/fritzing-app/../libgit2/include

Bevan commented on 2022-04-02 08:37 (UTC)

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

ericfont commented on 2022-04-01 19:58 (UTC)

When run, I got error "error while loading shared libraries:". However I was able to avoid that by downgrading libgit2 from current version 1.4.2 to 1.3.0.

lnoferin commented on 2021-12-12 05:16 (UTC)

@Bevan: thanks, rebuilded with

yay -S fritzing

and now it works!

Bevan commented on 2021-12-08 18:33 (UTC)

Sorry for the late replies:

@SwankyBarbecue4: See the response by slashinfty. You can start fritzing from the command line as Fritzing. The capital F is an upstream decision... Fritzing should also show up in dmenu due to the installed desktop file (/usr/share/applications/org.fritzing.Fritzing.desktop). I'm not sure how well w3m/dmenu is integrated into pacman, so maybe some cache wasn't updated after install and therefore it does not show up immediately.

@lnoferin: You need to rebuild the package to link against the new version of libgit2.

slashinfty commented on 2021-12-08 18:18 (UTC)

@SwankyBarbecue4 try Fritzing with a capital F

lnoferin commented on 2021-12-06 06:47 (UTC)

I can't run fritzing because I get this error

Fritzing: error while loading shared libraries: cannot open shared object file: No such file or directory

The command

 ldd /usr/bin/Fritzing

gives this error => not found

but I have these libraries installed

 pacman -Ss libgit                                                                                                                                                                                                              ✔ 
 extra/libgit2 1:1.3.0-1 [installato]
     A linkable library for Git

I am on manjaro and this happens on arm64 (raspberry pi400) and on amd64 architecture

SwankyBarbecue4 commented on 2021-12-01 23:23 (UTC)

How can I launch this package? I installed using yay -S fritzing, however I am unable to find the package when searching for it in dmenu. I am using i3wm.

Bevan commented on 2021-08-21 18:13 (UTC) (edited on 2021-09-26 19:50 (UTC) by Bevan)

Below comment is obsolete. The github repository by now has been updated and this package tries to reflect the official releases again. Please consider buying the official package to fund ongoing development of Fritzing.

For a while now Fritzing does not provide binary downloads for free but asks for a donation before giving you the possibility to download the software. I think this is fair. However, since the code was available on github under GPL license, it was still possible to build the software from source.

This seems to have changed now. On github there is no tagged release after 0.9.6. There is only a single commit on the develop branch since March and none on master since February. No signs of recent development or releases. To me it looks like open source development has stopped. People who buy the software should be able to request the source code due to the GPL license. I have not.

I'll wait some time for comments here or on github or maybe ask myself in their issue tracker. But it may very well be that this package has no future.

Update: Discussions on the topic are ongoing. See:

Bevan commented on 2021-06-11 19:31 (UTC)

@OJaksch: Done. Thanks for testing!

OJaksch commented on 2021-06-03 15:10 (UTC)

Please enable arch=aarch64. Just build it for myself and it is working with my rpi400.

flolilo commented on 2021-03-27 00:57 (UTC)

For 0.9.6 (currently, there is no CD-xxx version number), you have to change the following things in PKGBUILD (only relevant lines mentioned):

# patch -p1 < "${srcdir}"/472951243d70eeb40a53b1f7e16e6eab0588d079.patch

(in fact, you can delete every mention of 472951[...].patch).

txtsd commented on 2020-11-24 13:48 (UTC) (edited on 2020-11-24 13:49 (UTC) by txtsd)

I've already run fritzing_clone_parts. Here's what happens when I try to regenerate the parts database:

Visually, the loading bar gets stuck about 2/5ths of the way, then the program just crashes.

TheSaint commented on 2020-11-06 04:18 (UTC) (edited on 2020-11-06 04:21 (UTC) by TheSaint)


Fritzing builds fine against the current version of libgit2.

Rebuilding has corrected the flaw. Sorry if I didn't remember that trial, I was trying to reinstall libgit2, without thinking to rebuild the entire package. Thanks

Bevan commented on 2020-11-05 13:26 (UTC) (edited on 2020-11-05 19:31 (UTC) by Bevan)

@TheSaint: Have you tried rebuilding the Fritzing package? Often this is sufficient to fix these kind of issues. I will try myself later today.

Edit: I confirmed that rebuilding the package fixes this issue. Fritzing builds fine against the current version of libgit2.

TheSaint commented on 2020-11-05 11:48 (UTC) (edited on 2020-11-05 11:52 (UTC) by TheSaint)

Fritzing: error while loading shared libraries: cannot open shared object file: No such file or directory

It seems that libgit2 got an upgrade

ls -l /usr/lib/libgit2*
lrwxrwxrwx 1 root root      14 15 ott 22.39 /usr/lib/ ->
lrwxrwxrwx 1 root root      16 15 ott 22.39 /usr/lib/ ->
-rwxr-xr-x 1 root root 1146864 15 ott 22.39 /usr/lib/

Bevan commented on 2020-05-13 12:04 (UTC) (edited on 2020-05-13 12:05 (UTC) by Bevan)

All packages in the base-devel group are expected to be installed when using the AUR. They must not be included in the list of dependencies.


Lasse_Ristig commented on 2020-05-13 12:03 (UTC)

pkg-config was not installed and now fritzing is compiling. Thank you! In my opinion pkg-config must be included in the dependencies. It seems only be needed during compiling, so if not oncluded as dependency it would be useful to check to give a hint to install it temporary.

Bevan commented on 2020-05-13 11:43 (UTC)

Can you please check the output of the following command?

pkg-config --path libgit2

If this command is not installed on your machine this would explain the behavior. In that case please install all packages in base-devel.

Lasse_Ristig commented on 2020-05-13 11:14 (UTC)

The problem with this error notification persists:

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

I tested to compile with: - git clone ... makepkg - trizen -S fritzing

Bevan commented on 2020-05-02 16:05 (UTC)

@guitsi: That is a different issue. I can reproduce it by removing/commenting the following line in the PKGBUILD:

sed -i 's/LIBGIT_STATIC = true/LIBGIT_STATIC = false/'

Did you by accident do that? Apart from that I see that you build in a chroot. Can you briefly describe how you build this package?

guitsi commented on 2020-05-02 10:14 (UTC) (edited on 2020-05-02 10:14 (UTC) by guitsi)

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

Bevan commented on 2020-04-17 22:15 (UTC)

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

cliffordwhansen commented on 2020-04-17 12:07 (UTC) (edited on 2020-04-17 12:07 (UTC) by cliffordwhansen)

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


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


Bevan commented on 2019-11-25 19:09 (UTC)

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?

cgirard commented on 2019-11-25 17:09 (UTC)

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

Bevan commented on 2019-11-15 18:01 (UTC)

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.

loathingkernel commented on 2019-11-14 23:00 (UTC) (edited on 2019-11-14 23:20 (UTC) by loathingkernel)

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 ""
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.

Bevan commented on 2019-11-14 21:32 (UTC)

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.

loathingkernel commented on 2019-11-14 21:05 (UTC) (edited on 2019-11-14 21:22 (UTC) by loathingkernel)


  • 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.

Bevan commented on 2019-11-14 15:44 (UTC) (edited on 2019-11-14 20:31 (UTC) by Bevan)

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

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?

loathingkernel commented on 2019-11-14 13:05 (UTC) (edited on 2019-11-14 13:11 (UTC) by loathingkernel)

There are a few issues with this PKGBUILD.

  • pkgver is 0.9.4, not 0.9.4b

  • the introduced variables should start with an underscore (i.e. _tagver and _partsrev)

  • cloning git objects outside the source array is against the arch packaging etiquette. Something like


and in package()

  cp -dr --no-preserve='ownership' "${srcdir}"/fritzing-parts "${pkgdir}"/usr/share/fritzing/

is enough.

  • renaming the source tarball should be nicer and cleaner, for example

Or use git to pull the specific tag


DrWaluigi commented on 2019-08-06 20:55 (UTC)

Thank you!

Bevan commented on 2019-08-06 18:58 (UTC)

DrWaluigi: I think you are right‌. The dependency was included because there are jar files installed:

./usr/share/fritzing/sketches/core/Fritzing Creator Kit DE+EN/creator-kit-de/Processing/TwitterSaurus/code/twitter4j-core-3.0.3.jar
./usr/share/fritzing/sketches/core/Fritzing Creator Kit DE+EN/creator-kit-de/Processing/TwitterSaurus2/code/twitter4j-core-3.0.3.jar
./usr/share/fritzing/sketches/core/Fritzing Creator Kit DE+EN/creator-kit-de/Processing/twitter4j-core-2.2.5.jar
./usr/share/fritzing/sketches/core/Fritzing Creator Kit DE+EN/creator-kit-en/Processing/TwitterSaurus/code/twitter4j-core-3.0.3.jar
./usr/share/fritzing/sketches/core/Fritzing Creator Kit DE+EN/creator-kit-en/Processing/TwitterSaurus2/code/twitter4j-core-3.0.3.jar
./usr/share/fritzing/sketches/core/Fritzing Creator Kit DE+EN/creator-kit-en/Processing/twitter4j-core-2.2.5.jar

These jar files are part of some Twitter library used by the Twitter Saurus in the Fritzing Creator Kit. So, I guess, the jars are never run on the host system. And most people won't have the Fritzing Creator Kit anyway… So I removed the dependency.

DrWaluigi commented on 2019-08-05 18:28 (UTC)

This package has a dependency on a Java environment, but I don't understand why. On Github, there is no trace of Java code: I've tried to build and install the package without the java-environment dependency, with success.

Could you please remove the java-environment dependency? Or make it optional if it's needed for a feature?

sekret commented on 2018-08-09 19:50 (UTC)

YESSSS! After writing my last comment I realized that harfbuzz was updated again, so I rebuilt fritzing (probably not necessary, I don't know) once more, now it works again :-)

Thanks for taking the time!

Bevan commented on 2018-08-09 19:25 (UTC)

sekret: Looks to me like you are hitting a bug in harfbuzz which was fixed in 1.8.7:

It's already in the Arch repos (but only since a few hours) which would explain why I can't reproduce the issue. Can you check, if you have harfbuzz 1.8.7 installed?

sekret commented on 2018-08-09 19:11 (UTC) (edited on 2018-08-09 19:12 (UTC) by sekret)

Thanks for your answer Bevan. I used fritzing yesterday, then we got a big update (many rebuilds, maybe because of updated icu, harfbuzz? Could those cause this?) with many packages, today I get this message. So the obvious question is: Is your system up-to-date?

I already rebuilt it. Obviously it's the first thing to do. Didn't change anything unfortunately..

No I haven't figured out which commit solves this.

I actually NEED fritzing right now, so this is quite annoying... Rolling back the updates could be an option, switching to my windows laptop another (but it's so sloooooow).

Bevan commented on 2018-08-09 15:44 (UTC)

sekret: Are there any specific steps required to get that crash? At least running Fritzing and opening projects works fine for me here.

So you know a specific git commit which fixes the issue or did you just build the git version and couldn't reproduce? In that case, maybe rebuilding this packages helps.

sekret commented on 2018-08-09 07:41 (UTC) (edited on 2018-08-09 12:14 (UTC) by sekret)

Doesn't work anymore :-(

$ Fritzing

QApplication: invalid style override passed, ignoring it.

Fritzing: hb-machinery-private.hh:642: void hb_lazy_loader_t<wheresface, returned,="" stored="" subclass,="">::set_stored(Stored*) [with unsigned int WheresFace = 1; Subclass = hb_table_lazy_loader_t<1, OT::GDEF>; Returned = OT::GDEF; Stored = hb_blob_t]: Assertion `instance == nullptr' failed.</wheresface,>

Aborted (core dumped)

Seems to be fixed with the current git, but I can't yet manage to create a fully working git version with all included...

Bevan commented on 2018-07-24 17:16 (UTC)

goodmice: The issue appeared when the package had been built in the same version before and the src subdirectory was still lying around. I now changed the PKGBUILD to still work in this case.

goodmice commented on 2018-07-24 03:20 (UTC) (edited on 2018-07-24 03:20 (UTC) by goodmice)

Pleace, fix PKGBUILD. 'mv' can't move not empty folder. I replaced it with:

rsync -a "$srcdir"/fritzing-parts-${partsrev}/* "$srcdir"/fritzing-app-${pkgver}/parts
rm -rf "$srcdir"/fritzing-parts-${partsrev}

lifala commented on 2018-07-13 21:03 (UTC)


fritzing it's ok

Bevan commented on 2018-07-13 20:21 (UTC)

lifala: Please install all packages from the base-devel group:

pacman -S --needed base-devel

This includes the patch utility. Having base-devel installed in assumed for all packages in the AUR.

lifala commented on 2018-07-13 20:18 (UTC)


i problem with prepare and patch, ligne 34, command not found

/tmp/yaourt-tmp-lifala/aur-fritzing/./PKGBUILD: ligne 34: patch : commande introuvable


Bevan commented on 2018-04-09 22:16 (UTC)

salvatoreG: That's weird. For me the checksums are still identical. Could you delete parts-667a5360e53e8951e5ca6c952ae928f7077a9d5e.tar.gz and try again? If it still does not work, please check if it is a text file instead of the expected tar-gz and if so what the content is.

salvatoreG commented on 2018-04-09 09:22 (UTC)

I guess upstream package was updated because it doesn't match the expected checksum

==> Building and installing package ==> Making package: fritzing 0.9.3b-4 (lun. avril 9 11:18:00 CEST 2018) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found 0.9.3b.tar.gz -> Found parts-667a5360e53e8951e5ca6c952ae928f7077a9d5e.tar.gz -> Found 0001-Squashed-commit-of-the-following.patch -> Found fritzing.desktop.patch -> Found fritzing.xml ==> Validating source files with sha256sums... 0.9.3b.tar.gz ... FAILED parts-667a5360e53e8951e5ca6c952ae928f7077a9d5e.tar.gz ... Passed 0001-Squashed-commit-of-the-following.patch ... Passed fritzing.desktop.patch ... Passed fritzing.xml ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build fritzing.

danson commented on 2018-04-07 21:37 (UTC)

Bevan, thanks for the speedy fix, it works fine now.

Bevan commented on 2018-04-07 19:30 (UTC)

danson: Should be fixed now. Could you please retry?

danson commented on 2018-04-07 19:19 (UTC)

==> ERROR: Failure while downloading

/archive doesn't exist. Any idea where to get the parts?

Bevan commented on 2017-09-24 08:07 (UTC) (edited on 2021-09-26 19:49 (UTC) by Bevan)

Below comment is obsolete. Fritzing does not update the parts library anymore so the patches have been removed. See:

/usr/share/fritzing/parts contains the parts db which is provided by the package, which should not be updated by the user. Instead, the user can run the command "fritzing_clone_parts" once which clones the parts db into the user's home (located under ~/.local/share/fritzing). On next start, Fritzing will use this parts db instead of the one under /usr/share. From now on updating the db should work.

This is somehow a workaround to provide both a package that works out-of-the-box and the self-update functionality of Fritzing. See for a discussion on this. This package basically applies the changes of the pull-request to implement this functionality.

bfg commented on 2017-09-24 05:52 (UTC)

I've just installed the package and when I run and try, from menu, to check update a popup window say me that I have to enable write permission on folder: /usr/share/fritzing/parts Can you suggest me there is a way to make this works?

Bevan commented on 2017-09-13 12:56 (UTC)

I have seen this multiple times that release tarballs from github change their checksum. Seems to be the case here, as well. I currently get the following for 0.9.3b.tar.gz: 2475a95aad2c1536eef3fdb72665c5c16590644b45bd110a0cde223c916625b8 I will update the PKGBUILD later today.

Franek commented on 2017-09-13 12:20 (UTC)

The main tarball failed its checksum for me. Is anyone else getting this? Weird, was the 0.9.3b release changed without changing the release number? This is the sha256sum I get for 0.9.3b.tar.gz: 2475a95aad2c1536eef3fdb72665c5c16590644b45bd110a0cde223c916625b8

Bevan commented on 2017-05-16 19:14 (UTC)

This package needs to be rebuilt after the latest libgit2 update.

Bevan commented on 2017-04-16 17:33 (UTC)

@peste88: Well, that is an upstream decision. We would have to explicitly change this in this package, but I tend to stick to upstream as close as possible.

peste88 commented on 2017-04-16 14:22 (UTC)

Hello, I was wondering... Why does it has to be an upper case letter to call that Fritzing thing.

Bevan commented on 2017-04-09 06:55 (UTC)

@ctag: Please see my comment from 2017-02-20 20:49 and follow the steps there.

ctag commented on 2017-04-08 22:59 (UTC)

Received this error while building: Project MESSAGE: Fritzing requires libgit2 Project MESSAGE: Build it from the repo at Project MESSAGE: See for details. Project ERROR: libgit2 include path not found in ../libgit2/include Despite libgit2 being an installed dependency.

ArsenArsen commented on 2017-03-20 12:45 (UTC)

Hello, I was wondering was it just me that gets ==> Extracting sources... -> Extracting 0.9.3b.tar.gz with bsdtar -> Extracting 667a5360e53e8951e5ca6c952ae928f7077a9d5e.tar.gz with bsdtar ==> Starting prepare()... mkdir: cannot create directory ‘/home/arsen/.cache/pacaur/fritzing/src/fritzing-app-0.9.3b/parts’: File exists ==> ERROR: A failure occurred in prepare(). Aborting... :: failed to build fritzing package(s) Could you change `mkdir' to `mkdir -p'? Thanks.

Bevan commented on 2017-02-20 20:49 (UTC)

@MindlessMutagen: What seems to be going on here is that pkg-config does not see your installed libgit2. Please try the following two things: 1. Run "pkg-config --print-variables libgit2". It should output includedir libdir pcfiledir prefix If it claims that libgit2 was not found you need to figure out why. 2. Remove the src directory before building. I noticed the line "WARNING: Using existing $srcdir/ tree" in your output. This can actually cause issues.

Bevan commented on 2017-02-17 20:45 (UTC)

@MindlessMutagen: Thanks for the report. I will have a look into this. Unfortunately I won't have the opportunity to do so before Monday.

MindlessMutagen commented on 2017-02-17 20:30 (UTC)

@Bevan I am having issues with libgit2

MindlessMutagen commented on 2017-02-17 18:44 (UTC)

I am not albe to build the package and the issue is related to libgit2. I have tried building with both libgit2 and libgit2-git installed. This is all of the terminal output when building with pacaur: :: Proceed with installation? [Y/n] :: Retrieving package(s)... :: fritzing build files are up-to-date -- skipping :: Checking fritzing integrity... ==> Making package: fritzing 0.9.3b-3 (Fri Feb 17 12:37:12 CST 2017) ==> Retrieving sources... -> Found 0.9.3b.tar.gz -> Found 667a5360e53e8951e5ca6c952ae928f7077a9d5e.tar.gz -> Found 0001-Squashed-commit-of-the-following.patch -> Found fritzing.xml ==> Validating source files with sha256sums... 0.9.3b.tar.gz ... Passed 667a5360e53e8951e5ca6c952ae928f7077a9d5e.tar.gz ... Passed 0001-Squashed-commit-of-the-following.patch ... Passed fritzing.xml ... Passed :: Building fritzing package(s)... ==> Making package: fritzing 0.9.3b-3 (Fri Feb 17 12:37:14 CST 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Removing existing $pkgdir/ directory... ==> Starting build()... Project MESSAGE: Fritzing requires libgit2 Project MESSAGE: Build it from the repo at Project MESSAGE: See for details. Project ERROR: libgit2 include path not found in ../libgit2/include ==> ERROR: A failure occurred in build(). Aborting... :: failed to build fritzing package(s)

perost commented on 2016-09-24 11:18 (UTC)

@Bevan: Sorry for the late reply, I didn't get a notification about your message for some reason. But the new package release seems to work just fine for me at least.

Bevan commented on 2016-09-16 17:16 (UTC)

@perost: Thanks a lot for tracking this down! Instead of just changing the patch I would like to test a more general solution to what the patch is trying to fix: Could you please test the new package release (-3) if it solves the problem?

perost commented on 2016-09-15 18:27 (UTC) (edited on 2016-09-15 18:29 (UTC) by perost)

This package has a pretty annoying bug where all the bins in /usr/share/fritzing/parts/bins/more are duplicated each time Fritzing is started, leading to the bin manager filling up more and more. The issue is caused by 0003-Provide-a-sane-default-for-parts-path.patch, which introduces the line: FolderUtils::setAppPartsPath("/usr/share/fritzing/parts/"); to fapplication.cpp. This path is then used in binmanager.cpp:81 where it's concatenated with "/more" and used to determine the type of location of a bin. The path then becomes "/usr/share/fritzing/parts/bins//more", and the // causes the string comparison to fail against actual system paths. The fix is to simply remove the last / in the path: FolderUtils::setAppPartsPath("/usr/share/fritzing/parts");

Bevan commented on 2016-07-04 18:51 (UTC)

@kierdavis: I cannot reproduce this issue. Is you system fully up to date? Please double check running pacman -Syu. (The update I just pushed is not related to your issue.)

kierdavis commented on 2016-07-04 13:45 (UTC)

I'm getting a linker error when building this package (version 0.9.3b-1): /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/ undefined reference to `qt_version_tag@Qt_5.7' /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/ undefined reference to `qt_safe_poll(pollfd*, unsigned long, timespec const*)@Qt_5' (full log at At first glance it doesn't look like it's caused by the libgit2/boost-libs problem @Bevan mentioned recently, but I could quite likely be wrong.

Bevan commented on 2016-06-10 18:35 (UTC)

Feel free to build one :)

commented on 2016-06-10 18:29 (UTC)

Maybe a fritzing-bin would be ok in the meantime. I'm using a precompiler version and works reasonably well.

Bevan commented on 2016-06-07 17:02 (UTC)

Unfortunately version 0.9.3b shows to be very difficult to package. Apart from another change in how the parts-db is handled it now requires its own version of libgit2 and boost-libs. I don't want this package to compile and ship a complete system stack… I'll try to figure this out and/or contact the developers. For now I'll leave this flagged out of date.

Bevan commented on 2016-01-30 10:55 (UTC)

@razer: Thanks for the suggestion! I applied it alongside some additions.

razer commented on 2016-01-16 14:06 (UTC)

Please consider adding MIME type association ".fzz" during install cycle by applying this changes : Add fritzing MIME xml descriptor to AUR/GIT repo: Patching the PKGBUILD file : patch -> entire PKGBUILD ->

Bevan commented on 2015-04-09 22:33 (UTC)

@Smitty: icu is a dependency of qt5-base and therefore indirectly also of this package. No idea, how you could have ended up in that situation. Maybe a partial upgrade.

Smitty commented on 2015-04-09 20:51 (UTC)

Hello, I recently installed this package through yaourt, and I received an error during my first attempt almost immediately when the build started. Here is the relevant output: ==> Starting build()... /usr/lib/qt/bin/uic: error while loading shared libraries: cannot open shared object file: No such file or directory /usr/lib/qt/bin/uic: error while loading shared libraries: cannot open shared object file: No such file or directory /usr/lib/qt/bin/uic: error while loading shared libraries: cannot open shared object file: No such file or directory /usr/lib/qt/bin/uic: error while loading shared libraries: cannot open shared object file: No such file or directory make -f Makefile.Release make[1]: Entering directory '/tmp/yaourt-tmp-grant/aur-fritzing/src/fritzing-app-0.9.2b' /usr/lib/qt/bin/uic src/program/consolewindow.ui -o ui_consolewindow.h /usr/lib/qt/bin/uic: error while loading shared libraries: cannot open shared object file: No such file or directory Makefile.Release:2639: recipe for target 'ui_consolewindow.h' failed make[1]: *** [ui_consolewindow.h] Error 127 make[1]: Leaving directory '/tmp/yaourt-tmp-grant/aur-fritzing/src/fritzing-app-0.9.2b' Makefile:38: recipe for target 'release' failed make: *** [release] Error 2 ==> ERROR: A failure occurred in build(). I did some searching the package that owns that shared lib is called "icu". I realized that the package wasn't even installed, so I installed it and fritzing built successfully. Should "icu" be added as a dependency? I at least wanted to let people know in case anyone else runs into this problem.

htho commented on 2015-04-05 16:58 (UTC)

The new sources are available now:

Bevan commented on 2015-04-03 21:42 (UTC)

I will update this package as soon as the source code for 0.9.2b is available. Currently there are only binary downloads and there is no tag in git yet for this release.

avanc commented on 2015-02-21 15:27 (UTC)

Thanks, the problem sits in front of the computer. An update resolved the issue.

Bevan commented on 2015-02-21 13:36 (UTC)

It looks to me like there is an old qt library installed. Is your system fully up to date (pacman -Syu)? If so please post the output of "pacman -Qs qt5".

avanc commented on 2015-02-21 13:32 (UTC)

I get the following error after isntallation: Cannot mix incompatible Qt library (version 0x50400) with this library (version 0x50302) Aborted (core dumped) Any hints?

commented on 2015-01-21 16:04 (UTC)

@Bevan: It definitively helps! I had to install only libxkbcommon-x11 because I already have libsm installed and finally it worked.

Bevan commented on 2015-01-21 11:03 (UTC)

@Misio-it: Could you try installing libxkbcommon-x11 and libsm? If this helps I will add them here as a dependency.

commented on 2015-01-21 10:48 (UTC)

Just installed for the first time, I got this error message lauching from console: This application failed to start because it could not find or load the Qt platform plugin "xcb". Forcing Qt5 on command line leads to the same result. Any suggestions?

Bevan commented on 2014-12-03 09:06 (UTC)

In case anyone is wondering: the binary is now called Fritzing (with a capital F). This is how it is called after building and in the official desktop file so I kept this name.

ryanvade commented on 2014-12-03 00:30 (UTC)

I had to reinstall twice but it works.

Bevan commented on 2014-12-02 20:26 (UTC)

I adopted this package and just pushed an update. I did quite a lot of changes to the package, so please report if anything stopped working.

Transfixer commented on 2014-12-02 15:14 (UTC)

0.9.1b is out.

tghosgor commented on 2014-11-01 23:19 (UTC)

They probably recompiled and changed the link on the web site again without proper version bump. Dependencies seem fine to me.

lem0nhead commented on 2014-11-01 16:16 (UTC)

PCB autorouting seems to only works on Arduino shields boards (similar issue on for Linux Mint) DRC check seems to crash Fritzing (segfault) When I tested with the site version (direct download), autoroute still didn't work, but DRC at least explained why: "Too close to a border" (which is not true, so still a bug). I'm not sure it's a software or dependency bug

tghosgor commented on 2014-08-01 16:43 (UTC)

You are right I though I had all Qt5 packages installed on my system. Updating, thanks.

nishantjr commented on 2014-07-31 15:17 (UTC)

Thats qt5-svg, not qt5-script

nishantjr commented on 2014-07-31 15:16 (UTC)

Fixed compiling against qt4 stuff not listed in dependencies by changing to qmake-qt5 and adding qt5-script as a dependency. Not sure if version specification of qt5-script was necessary but did it anyway.

tghosgor commented on 2014-07-24 20:01 (UTC)

Apparently it still uses Qt4's SVG library and qmake fails to find svg module but qmake-qt4 does not. I am not even sure if I should add qt4 back as dependency.

giniu commented on 2014-07-24 18:39 (UTC)

it probably would use qt5 if you used qmake not qmake-qt4 in package function. Also, I'd recommend wrapping "$srcdir" and "$pkgdir" in quotes, so your package works if someone builds in directory containing spaces.

tghosgor commented on 2014-07-21 14:49 (UTC)

Updated, thanks.

maharifu commented on 2014-07-21 14:24 (UTC)

Hi, the file seems to have gone missing. The source is now at for some reason.

tghosgor commented on 2014-07-21 13:06 (UTC)

The file named "control" in fritzing source still points to qt4 libraries. I cross referenced the qt5 ones I have installed on my system with them and changed the PKGBUILD accordingly. If anybody has problems building please let me know.

tghosgor commented on 2014-07-21 12:50 (UTC)

You are right. I didn't read the changelog and it succeeded since I have got almost every development package installed on my system. Updating the PKGBUILD now.

giniu commented on 2014-07-21 08:26 (UTC)

According to changelog, fritzing was updated to Qt 5.2.1 - - are you sure everything, like all features, will work with qt4?

Manouchehri commented on 2014-07-20 19:57 (UTC)

Disowned as tghosgor offered to maintain it.

Manouchehri commented on 2014-01-27 21:37 (UTC)


Manouchehri commented on 2013-12-17 00:23 (UTC)

I believe the crashing issue should be fixed now, I set boost to require at least version 1.55.

phects commented on 2013-11-05 14:15 (UTC)

I disowned the package, feel free to adopt.

zenolijo commented on 2013-11-05 14:09 (UTC)

Confirming what tikiking1 says, it crashes very easily and is not usable. Works fine hand-built

commented on 2013-10-27 03:28 (UTC) Some issue specific for the AUR. AUR version dies when you try anything useful, hand-built is fine.

commented on 2013-07-27 09:34 (UTC)

Hi, version 0.8.2b is out. I only changed version and sha, compiled and work (for me) perhaps you can update the package? thx :-)

phects commented on 2013-05-14 07:04 (UTC)

I fixed the parts editor issue. Thanks skiltz!

skiltz commented on 2013-05-09 22:01 (UTC)

Please change : cp -r {parts,bins,sketches,translations,Fritzing,} $pkgdir/$_destdir to: cp -r {parts,bins,pdb,sketches,translations,Fritzing,} $pkgdir/$_destdir This allow part edit Thanks :)

jose1711 commented on 2013-03-14 20:41 (UTC)

is parts editor working for anyone? i always get a 'file not found' error

phects commented on 2013-03-02 10:29 (UTC)

Birkov, miffe, nickoe: Thanks for your help! I included your suggestions.

miffe commented on 2013-03-01 18:24 (UTC)

I get this while building: src/utils/graphutils.cpp:41:28: fatal error: boost/config.hpp: No such file or directory Please add boost to makedepends.

Birkov commented on 2013-01-11 19:52 (UTC)

Unable to find the following 21 parts: 'JustPowerModuleID' at ':/resources/parts/core/power.fzp' 'GroundPlaneModuleID' at ':/resources/parts/core/groundplane.fzp' 'RectanglePCBModuleID' at ':/resources/parts/core/rectangle_pcb.fzp' 'Copper1BlockerModuleID' at ':/resources/parts/core/blocker.fzp' 'NetLabelModuleID' at ':/resources/parts/core/netlabel.fzp' 'NoteModuleID' at ':/resources/parts/core/note.fzp' 'LogoImageModuleID' at ':/resources/parts/core/logoimage.fzp' 'LogoTextModuleID' at ':/resources/parts/core/logotext.fzp' 'SchematicLogoImageModuleID' at ':/resources/parts/core/schematiclogoimage.fzp' 'SchematicFrameModuleID' at ':/resources/parts/core/schematicframe.fzp' 'BreadboardLogoImageModuleID' at ':/resources/parts/core/breadboardlogoimage.fzp' 'BreadboardLogoTextModuleID' at ':/resources/parts/core/breadboardlogotext.fzp' 'WireModuleID' at ':/resources/parts/core/wire.fzp' 'PowerModuleID' at ':/resources/parts/core/dcpower.fzp' 'SchematicLogoTextModuleID' at ':/resources/parts/core/schematiclogotext.fzp' 'PadModuleID' at ':/resources/parts/core/pad.fzp' 'JumperModuleID' at ':/resources/parts/core/jumper.fzp' 'HoleModuleID' at ':/resources/parts/core/hole.fzp' 'RulerModuleID' at ':/resources/parts/core/cmRuler.fzp' 'ViaModuleID' at ':/resources/parts/core/via.fzp' 'GroundModuleID' at ':/resources/parts/core/ground.fzp'

commented on 2013-01-11 10:12 (UTC)

Hi, version 0.7.11b is now out. Thank you for your help.

espirit commented on 2012-10-15 19:02 (UTC)

Hello, Version 0.7.9b is out. Thanks and keep up the good work!

brainmue commented on 2012-08-14 11:21 (UTC)

Version 0.7.7b is out. Many Thanks for your great work!

matael commented on 2012-07-04 18:59 (UTC)

Hi ! Version 0.7.5b is now out ! Thanks for your work !

commented on 2012-04-18 14:32 (UTC)

Version 0.7.4b is out. Update, please

igordcard commented on 2012-03-15 16:57 (UTC)

Bump, please update the package.

equinoxefr commented on 2011-12-21 17:11 (UTC)

Thank's for the package ! I update it to 0.6.4b, you can find it here if you want: Pierre

phects commented on 2011-08-24 18:17 (UTC)

Updated to 0.6.3b and added copying of translations.

CarstenF commented on 2011-08-12 14:20 (UTC)

Missing Translation!! please change package() { ... cp -r {bins,sketches,parts,Fritzing,} $pkgdir/opt/fritzing ... } to package() { ... cp -r {bins,sketches,parts,translations,Fritzing,} $pkgdir/opt/fritzing ... } to add the missing Translation

phects commented on 2011-07-12 14:31 (UTC)

Thanks for the notification!

ISF commented on 2011-07-11 21:50 (UTC)

Hi, version 0.6.2b is out

ISF commented on 2011-02-26 15:13 (UTC)

version 0.5.2b is out.

commented on 2011-02-12 16:39 (UTC)

Version 0.5.0b is out.

pyropeter commented on 2010-12-19 14:08 (UTC)

Could you add a link from /usr/bin/fritzing to /usr/bin/Fritzing? I hate uppercase :-P

td123 commented on 2010-10-28 15:45 (UTC)

I decided to let you handle updating it in the aur (at least for now) since it seems you follow upstream which signifies you would have a greater interest then me in this package. Thanks.

phects commented on 2010-10-25 11:59 (UTC)

I often relied on the community to mark it out of date, too. A few weeks ago, i wrote a small script, which monitors the MD5 hash of and notifies me by RSS. You can have that one, but it's really trivial. So i would still appreciate including the fritzing PKGBUILD in community.

td123 commented on 2010-10-24 20:01 (UTC)

I would probably be relying on the community to mark it out of date before I would update it. Do you still think I should move it since I'm assuming you keep track of upstream closely.

phects commented on 2010-10-22 14:28 (UTC)

That implies, the PKGBUILD is moved into the community SVN and further updated by you? I would appreciate this step, but be aware that the project releases a new version once in a month at average. I see no reason which disqualifies the software from community. Maybe you want to have a look on my other PKGBUILDs ;). (Especially ruby-libglade, system-config-lvm and thunar-vcs-plugin.)

td123 commented on 2010-10-22 03:43 (UTC)

I would like to add this package to community, what do you think?

phects commented on 2010-10-13 17:08 (UTC)

Could you send a patch, please? I can't find any KDE package guideline documents.

surfhai commented on 2010-10-13 16:48 (UTC)

Please Add an Icon to the KDE menu

nofxx commented on 2010-08-01 00:34 (UTC)