Comments

358 Comments

I am sending this one to stable now, it is definitely an improvement over the status quo. I will be pushing a fix for #416037 to testing soon. If there are any fixes needed for coordinate precision, please point me to those so that I can apply those, too.

I am sending this one to stable now, it is definitely an improvement over the status quo. I will be pushing a fix for #416037 to testing soon. If there are any fixes needed for coordinate precision, please point me to those so that I can apply those, too.

BZ#1311513 coordinate precision cannot be changed
BZ#1777998 python scripting not present
BZ#1778000 Python scripting assertion failure

That's because the fix is only in the release/19.12 branch and was not merged to master yet.

I am a bit confused... I still do not see the 'ok' button in the coordinate precision dialog when I compile from git sources. Moreover: actually a change in the coordinate precision WORKS! Only it works only on the "Coordinates" of a point when obtained right-clicking on a point -> Add Text Label -> Coordinate. This could actually make sense.

however the new value does not seem to affect the number of decimal digits printed. This is by sure an upstream issue and I will open a report there.

I still don't see an upstream report for that…

karma

Just tested and it seems working fine. Regarding the coordinate precision dialog: now the panel works fine; however the new value does not seem to affect the number of decimal digits printed. This is by sure an upstream issue and I will open a report there.

BZ#1311513 coordinate precision cannot be changed
BZ#1777998 python scripting not present
BZ#1778000 Python scripting assertion failure

Thanks... sorry, I mangled my comment above. The error appearing there comes from a kig compiled from source, I don't know how to help you. To get a backtrace I need help; is the problem present in fedora 32?

I reopened your downstream report https://bugzilla.redhat.com/show_bug.cgi?id=1778000 but I cannot promise anything at this time.

kig: /usr/include/boost/python/object_core.hpp:422: boost::python::api::object_base::~object_base(): Assertion `Py_REFCNT(m_ptr) > 0' failed. Aborted (core dumped)

So I suspect that this is related to the same bug that I reported upstream as https://bugs.kde.org/show_bug.cgi?id=388241

Sorry this seems something that has to be fixed upstream as I get

Do you have a backtrace for the crash? I don't think the warnings you see on the console are related.

Forgot to mention. The error showing up upon kig crash is:

$ kig org.kde.ksyntaxhighlighting: Rule: Unknown format "Normal" in context "Normal" of definition "Python-Kig" org.kde.ksyntaxhighlighting: Rule: Unknown format "Normal" in context "parenthesised" of definition "Python-Kig"

BZ#1777998 python scripting not present

python script can now be created but kig crashes as soon as an object is moved in the kig window.

Details:

I created a Point, then asked for its x-coordinate, then created a python scripting with the numeric value of the x coordinate as an argument and the following script:

def calc( arg1 ): # Calculate whatever you want to show here, and return it. # For example, to return one half of the input number, # you would put this code here: # return DoubleObject( arg1.value()/ 2 ) # Please refer to the manual for more information.

return DoubleObject( arg1.value()/ 2 )

Works for me..

works for me

It turns out that the UEFI issue is not caused by the update. UEFI works in the VM with a fresh disk image and not with a reused one. It is unclear whether it works on real hardware. But the update does not make this any better or worse, so let us just push the security update now and look into UEFI later.

It turns out that the UEFI issue is not caused by the update. UEFI works in the VM with a fresh disk image and not with a reused one. It is unclear whether it works on real hardware. But the update does not make this any better or worse, so let us just push the security update now and look into UEFI later.

Unfortunately, it looks like UEFI installations don't work with Calamares 3.2.11. I need to investigate that issue before pushing this update.

Unfortunately, it looks like UEFI installations don't work with Calamares 3.2.11. I need to investigate that issue before pushing this update.