Arch Linux User Repository

patch should be added as a build dependency. Just had a build fail because it was not installed.

Thanks for the package otherwise!

Hi,

to get cura5 to run correctly in KDE + Wayland the last line of the script /user/bin/cura5 should be as follows:

QT_QPA_PLATFORM=xcb LD_PRELOAD=/usr/lib/libstdc++.so.6 QT_QPA_PLATFORMTHEME=xdgdesktopportal QT_QPA_PLATAFORM=xdgdesktopportal ./Ultimaker-Cura $@

After the above is applied Cura5 works as espected. If run from terminal, the below warnings are outputted:

PyInstaller/loader/pyimod02_importers.py:499: DeprecationWarning: the imp module is deprecated in favour of importlib and slated for removal in Python 3.12; see the module's documentation for alternative uses Cyclic dependency detected between "file:///opt/cura5/share/cura/resources/qml/Actions.qml" and "file:///opt/cura5/share/cura/resources/qml/Actions.qml" QQmlEngine::setContextForObject(): Object already has a QQmlContext

Greetings, a clean build will finish creating and installing the package however the following errors are thrown when attempting to launch the app:

(Ultimaker-Cura:1156227): GLib-GIO-ERROR **: 10:11:22.258: Settings schema 'org.gnome.settings-daemon.plugins.xsettings' does not contain a key named 'antialiasing' /usr/bin/cura5: line 5: 1156227 Trace/breakpoint trap (core dumped) LD_PRELOAD=/usr/lib/libstdc++.so.6 QT_QPA_PLATFORMTHEME=xdgdesktopportal QT_QPA_PLATAFORM=xdgdesktopportal ./Ultimaker-Cura $@

The main advantage of hardlinks over symlinks is they can never be broken. They are also real files, so will work where symlinks might not. I tried writing a script to symlink the duplicate files, but cura wouldn't run. Didn't put much effort into trying to figure out why because hardlinks work and the space saving would be the same.

Reflinks are currently supported by Btrfs, XFS, and ZFS. Their uses are similar except that reflink contents can diverge. I use hardlinks to keep copies of notes in multiple locations. I use reflinks to clone WINE prefixes, where some files are expected to diverge. I've used both to clone directories (cp -l) prior to doing temporary work that will be deleted (so I don't have to search for build artifacts) and to make incremental backups (rsync).

Hardlinks and reflinks are both created nearly instantaneously, so for very large packages, creating ref/hardlinks instead of copying files could be worth considering.

Well, thanks for all the suggestions-- this package is definitely better for your contributions :). I use cura all the time so I'll definitely be keeping this package in as good a shape as I'm able to.

It's funny, I've been using linux since the late 90s and never found a use for hard links until now, but this situation is perfect for them. Packaged files typically shouldn't be edited and packaged libraries basically never are, but if someone did need to edit one I'm sure the reason would apply to the other. I suspect you're right about the duplicate issue (and I'll check each release to see if they make a difference to the package size).

I'm not familiar with reflinks at all, but the caveats you listed are pretty big, especially the filesystem and utility ones for a package that's expected to work for everyone. Thanks for highlighting them though! You got me curious about how they work compared to symlinks and hardlinks and I'm going take a look :)

No credit needed. Glad that you're actively maintaining the package. In principle, using reflinks instead of hardlinks would be better in case some of the duplicates need to be modified independently from the others, but hardlinks is the most practical for now because...

• AppImages are based on a read-only file system, so there should never be any need for the duplicates to diverge.

• tar doesn't support reflinks, so the package would be larger and a script would have to be run after install to deduplicate the files.

• Only a few file systems currently support reflinks.

• Utilities to manage reflinks are still non-existent/rare.

• The duplicate files may be an upstream mistake that may be resolved in future releases.

@xiota: That AppRun script was a great find, your solution for replacing the scripts was a great idea, and your hardlink trick to reduce the size of the package by a couple hundred megs is amazing. Thanks so much for sharing all your ideas! I implemented them basically as suggested with a few minor tweaks and credited you in the commit history :)

Version 5.2.1 has ~290MiB of duplicate files that previous versions didn't. Fortunately, tar supports hardlinks. So some space can be saved by adding to prepare():

hardlink --content --maximize "$srcdir"

A dependency on util-linux may be needed for hardlink. On my computer with an NVMe drive, hardlink takes about 4-5s to run. The operation should still be fast on computers with HDDs because the files were recently extracted and should still be in cache.

The AppImage AppRun sets some environment variables to work around bugs. Instead of writing new scripts, if you patch the provided AppRun, upstream changes can be applied automatically.

[patch details removed because they've been added to the package]

@tornado99: Good catch-- looks like not running it from inside an AppImage broke file selection on KDE (and probably other non-gtk-based desktops). I just pushed a tweak to the launcher script that fixed it for me on KDE/Wayland. Let me know if you're still running into issues!