Package Details: fritzing 0.9.4b-2

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: 213
Popularity: 1.19
First Submitted: 2009-05-31 14:31
Last Updated: 2019-11-25 19:07

Pinned Comments

Bevan commented on 2017-09-24 08:07

/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 https://github.com/fritzing/fritzing-app/pull/3238 for a discussion on this. This package basically applies the changes of the pull-request to implement this functionality.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Bevan commented on 2019-11-25 19:09

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

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

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

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

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

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

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

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})

DrWaluigi commented on 2019-08-06 20:55

Thank you!

Bevan commented on 2019-08-06 18:58

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.