Latest upstream release: 0.9.3b Current version/release in rawhide: 0.9.2b-5.fc24 URL: http://fritzing.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/858/
Patching or scratch build for fritzing-0.9.2b failed.
Created attachment 1162445 [details] Rebase-helper rebase-helper-debug.log log file. See for details and report the eventual error to rebase-helper https://github.com/phracek/rebase-helper/issues.
Following patches has been deleted: ['feh-1.10.1-dejavu.patch']
Created attachment 1287053 [details] New and updated patches for build against 0.9.3b
Created attachment 1287054 [details] Spec file used to build with new patches
Sorry for the long delay in replying to this. I'm torn, because while the git-based update mechanism might be the right choice for upstream, I'm not convinced it's the right thing for Fedora, where we already have a distribution mechanism we can use for updating the parts library in a controlled and stable manner (by issuing an updated RPM). Introducing a network dependency (and a dependency on Github) just for launching the program the first time seems unreasonable if we don't have to, especially when there's the possibility that the upstream git repository could contain assets that the version we're shipping in Fedora might not be able to render (for example, if we stay behind a version or two in Fedora to ensure output compatibility within a given release). The ideal situation would be splitting fritzing up into two packages at this point: fritzing for the program itself (and which updates infrequently), and fritzing-parts (which fritzing would depend on), which would be updated more frequently from the upstream git repository, and actually patching out the parts update mechanism in the same way we currently patch out the software update mechanism. But, this has been stalled a bit since I haven't had a lot of time to work on it. Suggestions and patches in that direction would definitely be welcome here.
Created attachment 1329105 [details] Proposed fix Hi, I've made it work and created a patch. I think I've disabled all update mechanism, and disabled the use of libgit2 library since it makes connections during the build time which fails the build. Splitting fritzing-parts into its own package sounds like a good idea, especially since Fritzing binary it looks for it into /usr/share/fritzing-parts .
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
FEDORA-2020-babdd23bb7 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-babdd23bb7
FEDORA-2020-babdd23bb7 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-babdd23bb7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-babdd23bb7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-babdd23bb7 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.