Arch Linux User Repository

Update on version 2.3.x:

With 2.3.0 being very buggy and no 2.3.1 bugfix release in sight I got main branch building on Arch again and tagged latest commit ( c6b8664c8e276413445ed25d3a8957101143c006 ) as 2.3.1-dev.

Wayland support status:

Please test and report back - a bunch of fixes added, including one for nvidia binary driver performance.

Known issues:

• Camera/Live view/whatever you call it for BambuLab printers doesn't fully work - after a short while framerate drops to about 1fps.

@tflucke I would check that Adwaita font first it segfaults right after trying to access that.

Maybe try uninstalling ttf-harmonyos-sans, if you still have it installed. It led to similar issues in the past.

I installed this update last morning and every time I opened orca-slicer, it would segfault in the middle of the loading screen.

Seems to be an issue related to Freetype2. strace:

brk(0x64773ee9e000)                     = 0x64773ee9e000
futex(0x64773799cf50, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x64773799cf40, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x64773ee7de08, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x64773799cf50, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x64773799cf40, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x64773ee84dd8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x64773799cf50, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x64773799cf40, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x64773ee7b308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
access("/usr/share/fonts/Adwaita/AdwaitaSans-Regular.ttf", R_OK) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
zsh: segmentation fault (core dumped)  strace -- orca-slicer

stack trace:

#0  0x00005555582767a0 in tt_apply_mvar (face=0x55555ca9e9c0) at /usr/src/debug/orca-slicer/OrcaSlicer/deps/build/dep_FREETYPE-prefix/src/dep_FREETYPE/src/truetype/ttgxvar.c:1417
#1  0x00007fffee91b0c5 in FT_Set_Var_Design_Coordinates (face=face@entry=0x55555ca9e9c0, num_coords=2, coords=coords@entry=0x5555613f2380) at ../ft2demos-2.13.3/subprojects/freetype2/src/base/ftmm.c:336
#2  0x00007ffff70739ca in cairo_ft_apply_variations (face=face@entry=0x55555ca9e9c0, scaled_font=scaled_font@entry=0x55556130d060) at ../cairo/src/cairo-ft-font.c:2373
#3  0x00007ffff7077976 in _cairo_ft_scaled_glyph_load_glyph (scaled_font=scaled_font@entry=0x55556130d060, scaled_glyph=scaled_glyph@entry=0x5555613f6ca0, face=face@entry=0x55555ca9e9c0, load_flags=load_flags@entry=512, use_em_size=use_em_size@entry=0, vertical_layout=vertical_layout@entry=0)
    at ../cairo/src/cairo-ft-font.c:2424
#4  0x00007ffff707cde9 in _cairo_ft_scaled_glyph_init_metrics (scaled_font=<optimized out>, scaled_glyph=0x5555613f6ca0, face=0x55555ca9e9c0, vertical_layout=0, load_flags=512, foreground_color=0x7ffff70e8c40 <cairo_color_black.lto_priv>) at ../cairo/src/cairo-ft-font.c:3240
#5  _cairo_ft_scaled_glyph_init (abstract_font=<optimized out>, scaled_glyph=0x5555613f6ca0, info=CAIRO_SCALED_GLYPH_INFO_METRICS, foreground_color=0x7ffff70e8c40 <cairo_color_black.lto_priv>) at ../cairo/src/cairo-ft-font.c:3381
#6  0x00007ffff70304fd in _cairo_scaled_glyph_lookup (scaled_font=scaled_font@entry=0x55556130d060, index=<optimized out>, info=info@entry=CAIRO_SCALED_GLYPH_INFO_METRICS, foreground_color=0x7ffff70e8c40 <cairo_color_black.lto_priv>, foreground_color@entry=0x0, scaled_glyph_ret=scaled_glyph_ret@entry=0x7fffffff0a40)
    at ../cairo/src/cairo-scaled-font.c:2913
#7  0x00007ffff7030767 in cairo_scaled_font_glyph_extents (scaled_font=0x55556130d060, glyphs=0x7fffffff0a90, num_glyphs=1, extents=0x7fffffff0ab0) at ../cairo/src/cairo-scaled-font.c:1643
#8  0x00007ffff7ea7252 in compute_glyph_extents (cf_priv=0x55556130b818, glyph=411, entry=0x5555613f62e8) at ../pango/pango/pangocairo-font.c:830
#9  _pango_cairo_font_private_get_glyph_extents_cache_entry (cf_priv=0x55556130b818, glyph=411) at ../pango/pango/pangocairo-font.c:856
#10 _pango_cairo_font_private_get_glyph_extents (cf_priv=0x55556130b818, glyph=411, ink_rect=0x7fffffff0b60, logical_rect=0x7fffffff0b70) at ../pango/pango/pangocairo-font.c:893
#11 pango_cairo_fc_font_get_glyph_extents (font=0x55556130b7a0, glyph=411, ink_rect=0x7fffffff0b60, logical_rect=0x7fffffff0b70) at ../pango/pango/pangocairo-fcfont.c:130
#12 0x00007ffff79e8dc1 in pango_glyph_string_extents_range (glyphs=0x5555613f5310, start=0, end=8, font=0x55556130b7a0, ink_rect=<optimized out>, logical_rect=0x7fffffff0c20) at ../pango/pango/glyphstring.c:210
#13 pango_glyph_string_extents_range (glyphs=0x5555613f5310, start=0, end=8, font=0x55556130b7a0, ink_rect=<optimized out>, logical_rect=0x7fffffff0c20) at ../pango/pango/glyphstring.c:164
# ...

I tried with and without themes and neither worked.

It's a temporary workaround until this is sorted out https://github.com/SoftFever/OrcaSlicer/issues/8402

well still, If a user runs out of RAM they should change $MAKEFLAGS

So would I, but Orca build process is both fragile and a moving target - I have enough "fun" making sure it keeps up with GCC and cmake version changes in Arch outpacing other distros.

I feel you, I try to maintain the git package, it's something new every other day :D But the script wouldn't save you from any of this changes. I try to get a bit more involved upstream. I didn't even think about adding something like export CMAKE_POLICY_VERSION_MINIMUM=3.5 upstream, because it's not really a fix. It's OK for packaging but upstream should update the env (I know… easier said than done).

I am dockerizing build process to both ensure my local env is not a factor and so it can run on CI for Orca Slicer repo. I'll clean it up as a part of that.

That's why I suggest pkgctl, it creates a clean env, builds the package in it and runs namcap at the end. You would have spotted something like missing ninja right away.

@lod

Isn't this suppose to be a stable release? you could backport patches

2.3.0 stable release is seriously broken. There were some critical bugfixes after it was released so I expected 2.3.1 to follow shortly after. After 2 months of waiting and asking devs on Orca Discord about a new stable release being tagged and nobody biting I was left with a choice do I skip 2.3.x entirely and hope 2.4.0 will be better or do I select a commit in main branch that looks OK and package that. I went with the 2nd option.

Don't put -J in the script, you could use $MAKEFLAGS instead

It's a temporary workaround until this is sorted out https://github.com/SoftFever/OrcaSlicer/issues/8402

I would prefer to have the build script in the PKGBUILD instead of running another script (as long as it reasonable), but that's just my opinion.

So would I, but Orca build process is both fragile and a moving target - I have enough "fun" making sure it keeps up with GCC and cmake version changes in Arch outpacing other distros.

The script misses some important dependencies/makedependencies and does not build without them

I am dockerizing build process to both ensure my local env is not a factor and so it can run on CI for Orca Slicer repo. I'll clean it up as a part of that.

• Add yourself as maintainer in the PKGBUILD with a valid mail address.
• Isn't this suppose to be a stable release? you could backport patches
• The script misses some important dependencies/makedependencies and does not build without them
• It has a couple of unneeded dependencies
• Add optdepends for the Nvidia-Wayland-Zink workaround
• /usr/resources/ is not a valid directory
• You should use pkgctl build -c for testing the PKGBUILD
• Don't put -J in the script, you could use $MAKEFLAGS instead
• I would prefer to have the build script in the PKGBUILD instead of running another script (as long as it reasonable), but that's just my opinion.
• The build is broken again because Mesa 25.1 doesn't ship OSMesa anymore (I already sent a pull request upstream)

@ivlis you can add

sed -i 's|https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.bz2|https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1.tar.bz2|' OrcaSlicer/deps/MPFR/MPFR.cmake

@c2h5oh If you have a link to the Bambu problems, I can add a patch, but I don't have any Bambu printer to test it.

If someone want to test 2.3.0 here is my PKGBUILD based on the git package. It also applies the Nvidia-Wayland-workaround.

Compilation fails with:

CMake Error at dep_MPFR-stamp/download-dep_MPFR.cmake:163 (message):
  Each download failed!
    error: downloading 'https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.bz2' failed
          status_code: 22
          status_string: "HTTP response code said error"
          log:
          --- LOG BEGIN ---
          Host www.mpfr.org:443 was resolved.

It seems mpfs was updated to 4.2.2

Update on version 2.3.x:

With 2.3.0 being very buggy and no 2.3.1 bugfix release in sight I got main branch building on Arch again and tagged latest commit ( c6b8664c8e276413445ed25d3a8957101143c006 ) as 2.3.1-dev.

Wayland support status:

Please test and report back - a bunch of fixes added, including one for nvidia binary driver performance.

Known issues:

• Camera/Live view/whatever you call it for BambuLab printers doesn't fully work - after a short while framerate drops to about 1fps.

This package is broken, please fix it

error: deps/build/dep_OpenCV-prefix/src/dep_OpenCV/cmake/templates/OpenCVConfig.root-WIN32.cmake.in: No such file or directory
Checking patch deps/build/dep_OpenCV-prefix/src/dep_OpenCV/cmake/OpenCVDetectCXXCompiler.cmake...
error: deps/build/dep_OpenCV-prefix/src/dep_OpenCV/cmake/OpenCVDetectCXXCompiler.cmake: No such file or directory
make[2]: *** [CMakeFiles/dep_OpenCV.dir/build.make:117: dep_OpenCV-prefix/src/dep_OpenCV-stamp/dep_OpenCV-patch] Error 1
make[1]: *** [CMakeFiles/Makefile2:836: CMakeFiles/dep_OpenCV.dir/all] Error 2
make: *** [Makefile:91: all] Error 2