AUR (en) - fritzing

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: fritzing 1.0.2-2

Package Actions

Git Clone URL:	https://aur.archlinux.org/fritzing.git (read-only, click to copy)
Package Base:	fritzing
Description:	PCB layout prototyping application
Upstream URL:	http://fritzing.org
Licenses:	GPL3
Submitter:	phects
Maintainer:	Bevan
Last Packager:	Bevan
Votes:	243
Popularity:	0.40
First Submitted:	2009-05-31 14:31 (UTC)
Last Updated:	2024-02-16 19:46 (UTC)

Dependencies (9)

libgit2 (libgit2-git^AUR)
ngspice (ngspice-git^AUR)
polyclipping^AUR
qt6-serialport
qt6-svg
quazip-qt6
boost (boost-git^AUR) (make)
git (git-git^AUR) (make)
qt6-tools (make)

Required by (0)

Sources (6)

Pinned Comments

Bevan commented on 2023-09-25 08:41 (UTC) (edited on 2023-11-02 19:48 (UTC) by Bevan)

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

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 .. 18 Next › Last »

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]:

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

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

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)

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.

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:

If you ask the source code, you will get different opinions on the version string, so I'd rather not worry about that:
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?

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

source=(git+https://github.com/fritzing/fritzing-parts.git#commit=${_partsrev})

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

source=($pkgname-$pkgver.tar.gz::https://github.com/fritzing/fritzing-app/archive/${_tagver}.tar.gz)

Or use git to pull the specific tag

source=(git+https://github.com/fritzing/fritzing-app.git#tag=${_tagver})