Description of problem: /usr/include/squashfuse.h contains the following #includes: #include "dir.h" #include "file.h" #include "fs.h" #include "traverse.h" #include "util.h" #include "xattr.h" (In fact, that's _all_ it contains.) However, none of those files are packaged, making the header unusable. Version-Release number of selected component (if applicable): squashfuse-devel-0.1.102-3.fc30.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attempt to #include "squashfuse.h" 2. 3. Actual results: In file included from /home/ferd/rpmbuild/REPOS/AppImageKit/lib/libappimage/src/libappimage/libappimage.c:44: /usr/include/squashfuse.h:28:10: fatal error: dir.h: No such file or directory 28 | #include "dir.h" | ^~~~~~~ compilation terminated. make[2]: *** [src/libappimage/CMakeFiles/libappimage.dir/build.make:63: src/libappimage/CMakeFiles/libappimage.dir/libappimage.c.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:305: src/libappimage/CMakeFiles/libappimage.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 Expected results: No compilation errors due to missing includes. Additional info: The referenced include files _are_ present in the squashfuse source distribution, see https://github.com/vasi/squashfuse However, it looks like upstream isn't properly installing its includes, since: $ pkg-config squashfuse --variable=includedir /usr/include ...I would think that would be /usr/include/squashfuse/ (which does not currently exist), a path which would then contain **all** of the necessary header files.
Note that I have submitted a PR upstream to correct the header installation: https://github.com/vasi/squashfuse/pull/36
Thank you for the report, and I appreciate the effort to fix this upstream first. In your opinion, should we wait for that fix to land, or patch it while we wait?
There hasn't been a commit upstream since June 2018, and no reaction to my PR in a full two weeks. It's starting to seem like squashfuse is effectively an abandoned project, I doubt waiting on action there would prove fruitful.
Well, turns out I was wrong. As of 4 hours ago, my PR is merged upstream. So updating from the git HEAD at https://github.com/vasi/squashfuse/ is another option.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
So... any plans on moving this forward? I've just been bitten by this myself.
I was hoping upstream would cut a new release containing the fix, but it's admittedly been a while.
Personally I'm not pushing to adopt the latest git snapshot; cherry-picking only the patch for missing headers would be fine.
Artur's src.fpo PR, which addresses this by cherry-picking the commit from my upstream PR as a patchfile applied in squashfuse.spec, is here: https://src.fedoraproject.org/rpms/squashfuse/pull-request/2 (Please do consider merging the PR and releasing an updated squashfuse RPM. I think waiting on action from upstream is an nice idea whose time has long since passed.)
Kyle, it's been over a year since this issue was originally reported. While the squashfuse package isn't of much importance in Fedora, having squashfuse-devel in this broken state prevents anyone from packaging any new software that would depend on the library. Please review the pull requests and merge one of them, or maybe write your own patch. I am setting the NEEDINFO flag. If you do not respond within a week, I will request help from a Proven Packager via the Simple Patch Policy (https://fedoraproject.org/wiki/Policy_for_simple_patches).
I'm afraid I'm unable to do this at this time. Please do use the simple patch policy.
@suve I took the liberty of performing the required scratch builds: ScratchBuild[rawhide]=https://koji.fedoraproject.org/koji/taskinfo?taskID=57542036 ScratchBuild[f33]=https://koji.fedoraproject.org/koji/taskinfo?taskID=57542045 ScratchBuild[f32]=https://koji.fedoraproject.org/koji/taskinfo?taskID=57542063
Simple Patch Request ==================== Patch[master]=https://svgames.pl/fedora/rhbz1761626/master.patch ScratchBuild[master]=https://koji.fedoraproject.org/koji/taskinfo?taskID=59266220 Patch[f33]=https://svgames.pl/fedora/rhbz1761626/f33.patch ScratchBuild[f33]=https://koji.fedoraproject.org/koji/taskinfo?taskID=59266293 Patch[f32]=https://svgames.pl/fedora/rhbz1761626/f32.patch ScratchBuild[f32]=https://koji.fedoraproject.org/koji/taskinfo?taskID=59266326 Submitter=suve
FEDORA-2021-eb68661994 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-eb68661994
FEDORA-2021-b07c548687 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b07c548687
FEDORA-2021-eb68661994 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-2021-eb68661994` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-eb68661994 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-b07c548687 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b07c548687` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b07c548687 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-eb68661994 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-b07c548687 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.