Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1911705 [details] Vertical line is leaning Created attachment 1911705 [details] Vertical line is leaning Description of problem: The vertical dimension line is leaning, and the measured value is wrong. The plugins are missing in the installed path /usr/share/librecad/plugins. Version-Release number of selected component (if applicable): librecad-2.2.0-0.13.rc3.fc36 How reproducible: It's always visible with vertical dimension measurement. Steps to Reproduce: 1.Create a new dxf file. 2.Add one vertical dimension line. 3. Actual results: The vertical dimension line is leaning. The plugins are missing in the menu. Expected results: The vertical dimension line shows correctly. The plugins are available in menu. Additional info: With the latest source code on Github, the built result is correct. The similar bug has been reported and corrected in Github. https://github.com/LibreCAD/LibreCAD/issues/1545 The plugins should be installed under /usr/share/librecad/plugins/.
I'm not the primary maintainer so I don't have a lot of experience with the package. Based on the link it's still unclear to me what the exact problem was or what the fix was. I can try updating to RC4 if that would help.
Pretty sure this package (and libdxfrw) just needs to be updated to the latest versions. It's on my to-do list, but if you can get to it first, more power to you. :)
libdxfrw seems to be the bigger issue. Neither have releases for the release candidates but it only has an rc1 tagged. I can update to latest master or LibreCAD_2 branches, whichever is more appropriate.
More coffee needed. It's 1.1.0 RC1 whereas 1.0.1 RC4 is in Fedora.
For both libdxfrw and LibreCAD, I'm assuming that any patch that doesn't apply is no longer necessary. Let me know if that's not a safe assumption for these projects.
For libdxfrw only Patch 2 survived with offsets. Looking at the link in the spec file it's an upstream commit from Nov '21. Is it safe to drop all patches?
Not sure that it is safe to drop all patches. Obviously if things we were patching are merged upstream, that's fine for us to drop.
(for libdxfrw) Ok, they are all upstream commits but I checked a few on github and it says something to the effect of "these are not part of a known branch". Is it possible they became part of a rebase? Seeing as they are (were?) upstream commits at one point it may be that the code base has moved on since they were committed. I did not get any "previously applied" output from the patch command indicating they were an exact match already. I don't know I have the time or expertise to evaluate each of the 12 patches individually.
Thanks for your discussion so quick. I'm a newbie on the patch history. As I've only downloaded the latest source code from Github and compiled it, it works well. So, I think the current patches can be dropped. And rc4 is a better choice. Additionally, with the current package, the plugins are installed under /usr/lib64/librecad/. But it's a wrong path. The plugins are not visible in the Librecad menu. The plugins should be put under /usr/share/librecad/plugins/. Thanks :)
We need to fix that the other way. The plugins are libraries and therefore arch specific. Only noarch data can go in /usr/share.
Looking for Spot's input here... I can brute patch it to /usr/lib64 since we don't have 32-bit binary packages anymore but that would prevent backporting to all current releases and EPEL. Some sed magic in the spec file may be the best solution.
TIL that if you go to the commit in github it will tell you what tags the commit is a part of. I have confirmed that all but the PR in Patch2 has been included in 1.1.0 RC1. I'll go ahead and build in a side tag and prep for a build with LibreCAD.
libdxfrw has been built. For posterity, or after I go to sleep :) $ cat f38-side-tag Side tag 'f38-build-side-58496' (id 58496) created. Use 'fedpkg build --target=f38-build-side-58496' to use it. Use 'koji wait-repo f38-build-side-58496' to wait for the build repo to be generated.
Can you manually download and install and check that the plugin issue is solved? https://koji.fedoraproject.org/koji/taskinfo?taskID=92041190
Plugins were in the dropdown for me, but two of the initial configuration options, one being language were blank. Still got more to fix.
FEDORA-2022-c074f42273 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c074f42273
FEDORA-2022-c074f42273 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
I'll work through the other Fedora releases as I have time.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days