8 minutes ago, Slashee_the_Cow said:Can't you run an AppImage of a current version?
Tried that first of all. A colourful range of error messages at different points. I think there might be a versionitis issue given the changes from Qt5 to Qt6, and so on.
4.13.1 also has an AppImage available, does that work?
I think the change from Qt 5 to Qt 6 only happened a couple of versions ago so you could also try just downloading versions in backwards order until you find one that works 🙂
I think wrong. 5.0 was the first version in Qt 6
Edited by Slashee_the_Cow53 minutes ago, Slashee_the_Cow said:4.13.1 also has an AppImage available, does that work?
I think the change from Qt 5 to Qt 6 only happened a couple of versions ago so you could also try just downloading versions in backwards order until you find one that works 🙂
Had several tries with AppImages, can't swear to that one, but no luck so far. Some less so than others, one got as far as a popup loading screen, otherwise not even that far.
And that was more or less my idea, but it seems to be that the Qt6 switch happened at 5.0. Less clear when other things I've also been tripping over like gcc versions change.
Are all the builds in this sort of range using the "conan" pathway? I briefly looked at a much earlier one still, before the switch to openGL 4, and those looked very odd indeed. Wasn't clear if they were maybe intended to be Windows-only? Or again, just me being very unclear what the build process is intended to be.
Building Cura from source is apparently a pretty hard thing to do - and unfortunately outside the scope of this forum as user support (you'd need to ask in the Cura GitHub repo).
I don't think the problem is because you're running Bullseye though.
As a test I downloaded an 11.0 image (from August 2021) and set it up in VirtualBox, installed with all the default settings (including GNOME desktop), haven't downloaded any updates, and it runs the 5.7.2 AppImage fine:
Of course if I'm right that this isn't a Bullseye thing that leaves you with the much harder question of what thing it is.
1 hour ago, Slashee_the_Cow said:I think the change from Qt 5 to Qt 6 only happened a couple of versions ago
That change was the reason to change the major version of Cura from 4.x to 5.x
Cura 5.0 was the first version to use Qt 6.
1
1
22 hours ago, ahoeben said:Cura 5.0 was the first version to use Qt 6.
Good to know I understood that much about the dependencies, at least! They're... more than a little opaque and bamboozling.
22 hours ago, Slashee_the_Cow said:Building Cura from source is apparently a pretty hard thing to do - and unfortunately outside the scope of this forum as user support (you'd need to ask in the Cura GitHub repo).
Oh. That seems very narrow as a "scope" determination -- but perhaps fair warning about the likelihood of getting responses here on it, at least. Noted. I'd be even less confident about getting useful responses to "me no understand how build" questions at github, but I can but try. I'll certainly take the apparent C++ 'dialect' errors I was getting from one attempt over there...
22 hours ago, Slashee_the_Cow said:I don't think the problem is because you're running Bullseye though.
As a test I downloaded an 11.0 image (from August 2021) and set it up in VirtualBox, installed with all the default settings (including GNOME desktop), haven't downloaded any updates, and it runs the 5.7.2 AppImage fine:
Apparently -- as I belatedly now understand it -- this is because things like the Qt libraries get bundled up in the AppImage, so it potentially survives things like the move from 5 to 6 regardless. So if the worst comes to the worst, I can, much as you suggested, just keep trying different versions until...
22 hours ago, Slashee_the_Cow said:Of course if I'm right that this isn't a Bullseye thing that leaves you with the much harder question of what thing it is.
Quite. Firstly I bit the bullet and upgraded to Debian 12 anyway, then retried. After a couple more bits of installation-attempt doltery that was purely on my own part, I ended up with much the same sort of error as my initial attempt. (By this point this felt like progress!) To wit:
> ./UltiMaker-Cura-5.7.2-linux-X64.AppImage qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor. qt.qml.typeresolution.cycle: Cyclic dependency detected between "file:///tmp/.mount_UltiMap1lKvc/share/cura/resources/qml/Actions.qml" and "file:///tmp/.mount_UltiMap1lKvc/share/cura/resources/qml/Actions.qml" The Wayland connection broke. Did the Wayland compositor die?
(A popup start-screen does appear for a while, then dies right after the "Loading UI..." message.)
Any suggested fixes and/or diagnostics from that point?
Cheers,
Alai.
It looks like it might be something to do with your graphics, given this message:
qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor.
Do you have multiple monitors? Cura can have trouble with multiple monitors (on Windows as well). If you do, try disconnecting all but your main monitor.
It could also be your graphics drivers (especially if you use Nvidia proprietary drivers, which still don't have great support for Wayland). Try running under X instead of Wayland (or vice versa).
45 minutes ago, Slashee_the_Cow said:It looks like it might be something to do with your graphics, given this message:
qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor.Do you have multiple monitors?
Nope.
45 minutes ago, Slashee_the_Cow said:It could also be your graphics drivers (especially if you use Nvidia proprietary drivers, which still don't have great support for Wayland).
"Virtio 1.0 GPU", if that's meaningful?
45 minutes ago, Slashee_the_Cow said:Try running under X instead of Wayland (or vice versa).
I was today years old when I learned I wasn't already, especially as I was launching from an xfce-terminal. Hrm. I'll try to see if other things using Qt6 display a similar issue. Once I work out what something suitable would be -- any and all suggestions welcome!
1 hour ago, AlaiME said:"Virtio 1.0 GPU", if that's meaningful?
Are you running a virtual machine in QEMU? Because... that's one of the graphics drivers it has.
And if you are, why not run Cura on the host instead of the VM? Or create a fresh VM?
And if you're not... did you just break the space/time continuum 😕
I have no idea what that driver is capable is capable of but it's also worth bearing in mind that Cura needs OpenGL support (version 2 as a minimum, 4.1 or higher for layer view, but that standard is years old so not a problem for most things).
1 hour ago, AlaiME said:I'll try to see if other things using Qt6 display a similar issue. Once I work out what something suitable would be -- any and all suggestions welcome!
As best I can tell, native packages using Qt 6 can only be found in the Trixie or Sid repos. Not that it should matter - part of the whole idea of AppImages (or Flatpaks, or *shudder* Snaps) is that they contain all the dependencies they need.
43 minutes ago, Slashee_the_Cow said:Are you running a virtual machine in QEMU? Because... that's one of the graphics drivers it has.
And if you are, why not run Cura on the host instead of the VM? Or create a fresh VM?
And if you're not... did you just break the space/time continuum 😕
Perhaps we're all inside a virtual simulation... </Twilight Zone music>
I'm using a Chromebook, so I'm something of a VM prisoner (CROSVM I think, rather than QEMU?) and likewise for the X/Wayland stack.
43 minutes ago, Slashee_the_Cow said:I have no idea what that driver is capable is capable of but it's also worth bearing in mind that Cura needs OpenGL support (version 2 as a minimum, 4.1 or higher for layer view, but that standard is years old so not a problem for most things).
Yup, that's partly why I was looking at super-old versions at one point -- with scary shizzle like like hardwired "/c/..." paths in their makefiles, apparently -- with no OGL4 dependency at all, as at start with I was limited to 3.2. But having updated to Debian 12 I apparently now have 4.3 support, so in theory no issue there.
43 minutes ago, Slashee_the_Cow said:As best I can tell, native packages using Qt 6 can only be found in the Trixie or Sid repos. Not that it should matter - part of the whole idea of AppImages (or Flatpaks, or *shudder* Snaps) is that they contain all the dependencies they need.
Yeah. But as it appeared to be a Qt call to wayland that was indicated, I was wondering if that was why it was flaking, as opposed to other GUI programs using different stacks.
And funny you should mention Flatpaks, as I found a page suggesting two methods, one of them a binary repo -- I dunno how I didn't think check that as an option in the first place --and the other, that. And the repo works! It's only version 4.13.1, but as that was titularly my objective in the OP, really no cause for complaint there. But flushed with success I also tried the flatpak, and it behaves... exactly like the AppImage. Popup loadscreen, very similar warnings/error messages, fails with a broken Wayland connection at the same point.
But! Version 5.6 is also OK, switching back to AppImages again. Even though it gives both of the same warnings as quoted above:
qt.qpa.wayland: Ignoring unexpected wl_surface.enter received for output with id: 7 screen name: "Screen5" screen model: "unknown" This is most likely a bug in the compositor.
Cyclic dependency detected between "file:///tmp/.mount_UltiMa6I4clr/share/cura/resources/qml/Actions.qml" and "file:///tmp/.mount_UltiMa6I4clr/share/cura/resources/qml/Actions.qml"
... evidently they're not fatal. 5.7,0 and 5.7.1 both fail in the same manner as 5.7.2. I'm naturally curious as to why, but unlikely to matter for my modest -- for now! -- enough needs. In a slightly Spinal Tap moment it also opens .stl files I thought were 22mm as <10, but how bad, easily tweaked.
Made some further progress with the source-build too. Now seems to build Cura, then fails in an esoteric way in CuraEngine (which I hadn't even initially realized I was building), but more RT errors I didn't make much sense of yet. But unless that magically fixes the problems with the 5.7 versions somehow, that might now be pretty much moot.
54 minutes ago, AlaiME said:I'm using a Chromebook
Lucky for you that you didn't mention that at the start or else you'd have just gotten the "Cura is not supported on Chromebooks" company line 😉
(Sorry, but following the official company line is part of the job requirements for being “Assistant Moderator” Slashee)
57 minutes ago, AlaiME said:But! Version 5.6 is also OK, switching back to AppImages again. Even though it gives both of the same warnings as quoted above
The world works in mysterious ways. Computers however fail in mysterious ways.
59 minutes ago, AlaiME said:In a slightly Spinal Tap moment it also opens .stl files I thought were 22mm as <10, but how bad, easily tweaked.
You might want to try playing around with the "Scale large models" and/or "Scale extremely small models" setting in the preferences. Blame whoever came up with the STL format for not including units in the spec.
1 hour ago, AlaiME said:Made some further progress with the source-build too. Now seems to build Cura, then fails in an esoteric way in CuraEngine (which I hadn't even initially realized I was building), but more RT errors I didn't make much sense of yet. But unless that magically fixes the problems with the 5.7 versions somehow, that might now be pretty much moot.
Could be the universe telling you to quit while you're ahead 😄
I would recommend reviewing both of the following articles.
UltiMaker Cura System Requirements: https://support.ultimaker.com/s/article/1667410778209
UltiMaker Cura Supported Operating Systems: https://support.ultimaker.com/s/article/1667337917781
Additionally UltiMaker Cura 4.13.x is over 2yrs old now.. and past versions are not actively maintained or updated so if there was a issue in that version that would have otherwise caused issues in ideal hardware/OS configurations you would have been advised to update to a newer version at that time.
44 minutes ago, Dustin said:UltiMaker Cura System Requirements: https://support.ultimaker.com/s/article/1667410778209
UltiMaker Cura Supported Operating Systems: https://support.ultimaker.com/s/article/1667337917781
No problems here on the former, and no immediate choice on the latter, so caveat noted, but oh well.
44 minutes ago, Dustin said:Additionally UltiMaker Cura 4.13.x is over 2yrs old now.. and past versions are not actively maintained or updated so if there was a issue in that version that would have otherwise caused issues in ideal hardware/OS configurations you would have been advised to update to a newer version at that time.
Sure, but as noted it is the one that's packaged for the (VM) distro in question, so you might be getting various passing querants from that pathway anyway, including from "native" Debian users, not just CROSVM schmucks like myself.
none of the "packaged" versions of UltiMaker Cura that are found anywhere but on our Github are published/maintained by UltiMaker. Those were published by 3rd parties, so you would need to address that with the 3rd party in question.
UltiMaker only publishes UltiMaker Cura on our github nowhere else.
https://github.com/Ultimaker/Cura/releases
.png.790188cb2d32e3558395d7e5fbc992f3.png)
ArunC posted a topic in UltiMaker Cura,
ArunC posted a topic in UltiMaker 3D printers,
Recommended Posts
Slashee_the_Cow 481
Can't you run an AppImage of a current version?
Link to post
Share on other sites