Obviously both entry boxes are meant to take only numbers, but stupidly, they don't appear to validate their input in any way, such that you can type in "foobar" and they'll happily accept it. The two options are "Rotation Angle" and "Scaling Factor". This toolbar presents you with two options to apply to the block, each accompanied by an entry box.
When you insert an external block, a special toolbar temporarily appears. It took a bit of scrolling up and down in the config to locate the real issue, but I found it. Putting my config file back, the problem returned. When I moved my config file out and started the application "fresh-from-factory" the problem was gone. It has no bearing on our current context.ĭeciding I'd wait for the next test candidate, I downgraded LibreCAD back to package 12.1, but the problem remained. What I describe there *is* a bug for sure, but one for upstream. It turns out that my entire complaint in Comment 9 was a false alarm. I can't tell you how I managed to say what I meant completely in reverse. > libraries when binary compatibility is broken. (In reply to David Walser from comment #10) Since reading and writing the DXF data is *exactly* what libdxfrw is meant for, I'm guessing something that was patched has gotten out of sync between it and the librecad application itself.
This suggests to me that the block's entity data is either written into RAM or file in garbled fashion or perhaps the program is failing to re-read the block back from RAM or file correctly. So far as I can tell, the block's data *does* get written into the save file, but fails to appear on-screen in the drawing at all. I get the impression that not too many of you are actually familiar with the software, so I won't describe the new issue in greater detail unless asked, but will go so far as to say that placed "blocks" (pre-grouped entities) simply vanish when first imported into a drawing rather than being placed into it. It may yet need to be rebuilt against librecad after all (if it ultimately wasn't). > already switched to the 1.0.1 fork, we probably don't need to. > Fedora also rebuilt librecad against the updated library, but since we In Bug 29720 Comment 0, regarding the libdxfrw library, David said: Whoops! I've been doing some drawing with the updated packages and *have* run into a post-patch anomaly. Updated packages in core/updates_testing:
LIBRECAD BLOCK CODE
(CVE-2021-45341)Ī buffer overflow vulnerability in CDataList of the jwwlib component of LibreCAD 2.2.0-rc3 and older allows an attacker to achieve Remote Code Execution using a crafted JWW document. The updated packages fix security vulnerabilities:Ī buffer overflow vulnerability in CDataMoji of the jwwlib component of LibreCAD 2.2.0-rc3 and older allows an attacker to achieve Remote Code Execution using a crafted JWW document. Lib/engine/rs_ellipse.cpp:70:22: error: 'tuple' in namespace 'boost::math' does not name a template typeħ0 | boost::math::tuple operator()(double const& z) const ::EllipseDistanceFunctor) (double)'Ħ81 | inline T halley_iterate(F f, T guess, T min, T max, int digits) noexcept(policies::is_noexcept_error_policy >::value& BOOST_MATH_IS_FLOAT(T) & noexcept(std::declval()(std::declval()))) For Mageia 8, librecad-2.1.3-12.2.mga8 solves the issue.
0 kommentar(er)
