🌠 Nightly Build 🌠 (5.10 Alpha)

[wawanbreton]

A Nightly build with upgraded Python 🐍 and Conan 🐸

During the last months, we have been pretty busy upgrading 2 core components of Cura:

• Python has been bumped from 3.10 to 3.12. Athough this is not major, Python is the engine that runs the Cura front-end and even the slightest change in its behavior can have an impact.
• We are now using Conan 2 instead of Conan 1. This tool is the basis of our build system, as it orchestrates the way each component of Cura is built and packaged. Cura uses multiple Python and C++ packages altogether, so assembling them all to a standalone application on 3 platforms is a sensitive task.

Why are these changes required ?

• Python keeps evolving, and we want to take advantages of its upgrades and last features. This also allows new developers to use the most recent version.
• Python 3.12 also comes with native speed improvements, so it is always good to take 🙂
• Conan 1 is on a deprecation path, so we really needed to switch to version 2, which is considered the more mature and robust version. Recent packages are now using Conan 2, so if we want to keep up-to-date, we need to use it.

Why do we need you ?

• We have tested many builds of Cura, on many systems, but we know everyone has a different execution environment. The idea of this Alpha release is to make sure that it still works on all the platforms where it used to work before.
• We don't exactly know how everyone uses Cura. There may be some actions that you do, which will reveal a bug we didn't see in our tests.
• There are tons of plugins, all based on Python code. So we want to make sure that they keep working with the new version.

What do you need to do ?

Well, not much, just download this version, use it as you would usually do, and send a brief feedback on the discussion: describe your environment, and tell us if everything went fine, or if you encountered some crashes or strange behaviors !

⚠️ Remember that this is an Alpha version, which means that only the basic functionalities have been tested. Some features are missing, incomplete or still in development, and may not be usable for production.

---

This discussion was created from the release 🌠 Nightly Build 🌠 (5.10 Alpha).

[jszymon]

Everything fine on Linux.

[kalkishnu]

os: Archlinux
kernel: 6.13.0-2
WM: Hyprland
gpu driver: nvidia-open 570

./Descargas/UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage UM/Settings/SettingFunction.py:244: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead def visit_Str(self, node: ast.Str) -> None: fish: Job 1, './Descargas/UltiMaker-Cura-5.10…' terminated by signal SIGSEGV (Address boundary error)
Additional info: version 5.9b1/b2/r crash the same way, last version i can run on this environment is 5.8.1.
Worth to mention that i tried all this version also on a nested lxqt_kwin_wayland session on the same user and all of them launched.

[wawanbreton]

Hi, thanks for the feedback !
This seems to be related to wayland indeed. In 5.9 we added an environment variable at start to force QT to use the xcb platform:
QT_QPA_PLATFORM=xcb
So you could also try the other platform plugins. Giving the plugin with the environment variable doesn't seem to work though, because it is embedded in the AppImage, but you can do the following:

./UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage -platform ...

In order to get the list of available plugins, just set a wrong one:

$ ./UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage -platform something
...
qt.qpa.plugin: Could not find the Qt platform plugin "something" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-egl, wayland, xcb.

Anyway, if the issue is present since 5.9, it is not a regression related to the Python/Conan changes, which is at least some good news for me.

[glx-seven]

Win11 24H2
Cura 5.10.0-alpha.0

The gradual infill setting seems just to respect the uppermost surface, the lower ones are treated with the reduced density (somehow offsetted tho). Doesn't seem to be affected which material or printcore is selected, the screenshots are from extruder 2 but I included a project with extruder 1 that behaves the same.

One below the uppermost:

Uppermost:

Project file:
Project-files_UMS5_vallejo_multi_rack.zip

[wawanbreton]

Hi, thanks for the feedback !
I'm not very familiar with the gradual infill feature, but I will discuss this with the team to see if this is somehow intended behavior.

This part aside, it seems that the application works pretty well overall 🙂

[GrimQuagle]

Hey fellas, I'm the main maintainer of the LulzBot fork of Cura, just popping in to see if I can lend a quick hand.

Very recently, the version numbers of many dependencies was bumped up to match the version number of Cura itself. While that's all well and good, you'll notice that the latest Windows installer from this run now crash during boot. What happened?

I ran into this while working on the LulzBot fork a few weeks ago. I couldn't for the life of me figure out why I wasn't able to get the Windows installer to work properly. After digging and digging, I figured it out.

What appears to have happened is that for quite a while now, Cura has been being built with an Arcus package for Windows that was created many months ago. Between then and now, MSVC updated from 19.3X to 19.4X and it just so happens that a change that was made to the constructor of std::mutex managed to break the implementation used by Arcus and results in Arcus attempting to reference a memory location that was instantiated as 0s. Windows doesn't like that and kills the entire application. This crash occurs when sendQueueMutex.lock(); is called on line 238 of libArcus/src/Socket_p.h.

Now, I'll be the first to tell you that my understanding of C++ is a bit shaky at best, so for my purposes (and what I feel is an adequate temporary solution), I simply added a few lines to the LulzBot fork of the conan-config repo that ensures when building Arcus, Conan uses MSVC version 193.

I'm sure you guys can probably get a much better long term solution figured out faster than I can, but I figured I'd swing by and give you my findings along with creating a quick pull request if you'd like to use it. Hopefully someone finds this helpful!

Best regards

[rburema]

@GrimQuagle

Very recently, the version numbers of many dependencies was bumped up to match the version number of Cura itself. While that's all well and good, you'll notice that the latest Windows installer from this run now crash during boot. What happened?

Hi! Thanks so much for digging up all of this -- Jaime forwarded me the mail and I meant to get back to you (will do so soon).

As far as I can see, what (I think) happened was that: Due to unrelated reasons, quite recently, we had to redo our windows-build server (private github runner), on which we installed a newer version of Visual Studio -- This initially seemed to work, since Arcus was pre-build and thus cached. However, we then bumped the version-number, which caused it to be finally be actually build on the server, which runs into the problem you've described.

Since we're closing in on release-related stuff (feature freezes and all that), I think I'll just try your fix for now -- We should fix this more properly (as in 'not a workaround') once (soon after, hopefully) 5.10 is released.

[rburema]

@GrimQuagle That's on me, I totally should've caught that. I did briefly think about it being in the 'wrong' spot, but thought, 'we'll remove it soon anyway' 😓

[wawanbreton]

Hi, I'm very sorry but I have to revert Ultimaker/conan-config@8ca7b5d, MSVC 19.3 is not available on the GitHub runners so the arcus package fails to build.
@GrimQuagle I suggest that you put the config in your local conan config for the moment, if possible for you, and we will work on making a proper fix ASAP.

[GrimQuagle]

Yep, that's totally fine by me. I suppose I should've asked first if your runners had the proper compilers!

I will add that I do have a pull request as well that would move that change to the installer profile, which for you guys is run on a windows runner that UltiMaker controls, but that still isn't a proper "permanent" fix so it's probably not worth the while anyhow, not to mention having multiple versions of a library compiled with different versions is bound to run into more problems down the road at some point anyways.

Best of luck with the fix! I'm sure you guys will get it ironed out pretty quickly.

[rburema]

We've found out today that Cura runs fine with v19.4x, as long as we provide the correct redistributables next to Arcus.dll (so in the root). Previously, we where apparently using the ones PyQt ships with Qt -- which is not under our control and thus only worked by accident.

We've put a crude stopgap in the cura-workflows repository to copy over the ones we currently have. -- I plan to write a bit more elaborate script to figure out the actual correct one if multiple versions of MSVC are installed, just so we don't get into trouble in the future. Otherwise, there doesn't really seem to be an elegant solution (putting the redistributable self-extractor in the installer will always install it system-wide as far as we can tell, for example).

In any case: Thanks so much for your help, we would have spent ages looking until we'd have figured out Arcus would have been the problem.

[GrimQuagle]

No problem at all! I'd spent a very long while bashing my head into this until I figured out where it was all going wrong so I figured at trying to point out the fairly elusive breaking point once you guys hit it as well was about the least I could do.

[Alfonsopl]

It works fine for macOS monterrey 12.3.1
How can you make the app images now? I used to do it with pyinstaller venv/conan/Ultimaker-Cura.spec but i can not find now Ultimaker-Cura.spec with the new structure.

[wawanbreton]

Hi, you can have a look at this file for the full install steps (for the linux AppImage) : cura-installer-linux.yml
Some of them may not be required of different, depending on your install paths, but if you follow the same steps, you should be able to build an appimage.

[a4jp-com]

Can you fix the measuring tool?

[rburema]

The measuring tool is a plugin that's not made by UltiMaker; I'm not sure it's under active development any more, but you can see the repo here: https://github.com/fieldOfView/Cura-MeasureTool/

[a4jp-com]

Looks like that hasn't been updated in 2 years. How do you measure objects in Cura now?

[a4jp-com]

Is there a 5.11 chat area? I can only see 5.10 alpha in the discussion area but 5.10 has already been released.

Also roughly when will 5.11 be released? I can see some nice changes have been made but there aren't any compiled versions of nightly builds here. Can that be automated? I'm happy to help test builds.

[wawanbreton]

Our build process is already mostly automated, but we do not release an Alpha build for every version. For 5.10 it was necessary because we had some major technical changes, and wanted to make sure it worked in the wild.

5.11 is not really planned yet, but we try to keep a 3-4 month release schedule, so should be around June-July. What features would you like to try ? I can have a discussion with the team to see if an Alpha version for 5.11 would make sense, maybe this is the case.

[fieldOfView]

Looks like that hasn't been updated in 2 years.

That by itself does not mean the plugin is broken. Please see my questions here: fieldOfView/Cura-MeasureTool#43 (comment)