Nebula is X512’s NVIDIA driver which is why it conflicts with Mesa which openscenegraph needs as a dependency. In this case option 1 would uninstall the driver which is not desired. This means this version of Scribus is not installable on systems using the Nebula driver. The package comes from the GitHub link kim1963 linked to in his post above.
Thanks for the pointer, as I don’t have @X512 driver installed I wasn’t aware, so @kim1963 don’t choose option 1 for now ![]()
EDIT: checked haikuports, last updated version for openscenegraph was from 2021, shouldn’t interfere with nebula? @X512 can you have a look here what the confict could be?
Right there, will try a build for scribus without the dependency for openscenegraph (was introduced on the latest update).
EDIT(3)
pushed a change dropping the dependency for openscenegraph, check again once the buildmasters finish on the update.
Packages usually should not depend on Mesa directly, it should depend on lib:GL instead. If dependency are properly defined, openscenegraph should work with Nebula driver set in theory.
Should be investigated which one does then.
EDIT: should have looked “closer” at opensdscenegraph, that one does ![]()
Was looking at the recipe just now too, it explicitly depends on Mesa and not lib:GL. I assume changing it to that will resolve the issue.
Indeed, what I mostly do is to comment it out and run a build, when haikuporter finishes it should print an error/warning on the missing dependency (likely libGL here), provided it isn’t included already with one of the other dependencies. (like probably libEGL here, commenting that one out should reveal what’s needed/required).
I guess the advantage to having users running Nebula on their system is it will weed out the packages/recipes on HaikuPorts that explicitly depend on Mesa. That said, it might be something worth doing is seeing how many packages explicitly depend on Mesa and change the recipes to avoid this. I can search the recipes in the repo tomorrow to see if there are others if that helps.
BTW, thanks for all the work you do on HaikuPorts, much appreciated.
inrecipe mesa | grep -v “OSMesa” reduces the number of hits for this ![]()
On a quick search I found these (some with mesa_devel which should also be replaced)![]()
/Opslag/haikuports/games-emulation/vecx_libretro/vecx_libretro-1.2_20260112.recipe:32: mesa${secondaryArchSuffix}_devel
/Opslag/haikuports/games-engines/openscenegraph/openscenegraph-3.6.5.recipe:59: mesa$secondaryArchSuffix/Opslag/haikuports/games-misc/craft_libretro/craft_libretro-1.0_20241006.recipe:32: mesa${secondaryArchSuffix}_devel
/Opslag/haikuports/x11-libs/iup/iup-3.8.recipe:100: mesa${secondaryArchSuffix}_devel
EDIT: pushed a change for openscenegraph to drop the dependency on mesa and rely on libGL (which was reported by haikuporters build, libEGL isn’t linked to it, so not required in the section REQUIRES).
Once buildmasters are done this should be fixed.
An image translator for QOI images (Quite OK Image) is now available in HaikuDepot. The QOI image format is a lossless image compression similar to PNG, but with much quicker encoding/decoding. The translator supports both reading and writing of QOI images.
Translator even passed the build for riscv64, nice work! ![]()
Nice! This has been on my to-do list for quite a while, but I never got around to do it.
New in the depot: msedit (added from the whishlist)
Updated:
Pencil2D 0.7.2
MKFToolNix 98.0
KDiff3 1.12.4
SourceTrail 2026.4
SuperTux 0.7
Calibre 5.44.0
ecode 0.8.0
And usual updates on libraries and other packages by the haikuports team! ![]()
That’s why i hate packages mánagers. Dependencies come with application. And that was beos doing back in the day. No package manager simply install app and It works
In BeOS days you had to either install seperate packages yourself for dependencies, or the packager would have to include all the required packages in the BeOS package, in itself not much difference beside that now it leads to less duplicates then you would have back then. (or conflicting versions)
Dependencies are not a problem introduced by package managers. You can still build your software and include libs in the package. Though repeat that with thousands of software and it starts to eat a lot of disk space. Also, if you’re going this way, it costs a lot more time updating these thousands builds each time a library has been updated. Knowing that not a lot of system are like Haiku and are allowing several versions of the same library to coexist, you may have to update all of them in one round. I don’t think there are so many people ready for such task.
Well, in the late BeOS days I ran a BSD-ports-styled package manager for BeOS called ReOS that did dependency management. But that only ever provided ported software, mostly command-line stuff, and didn’t integrate with the package system at all.
Honestly, haikuports is more annoying to publish a port through than ReOS ever was but that’s because it does way more and by building server-side it enforces correctness; haikuports is better.
OK, I do think ReOS had a better GUI; it used some library that did heirarchical list views with the ‘click on the triangle to expand” sections that I really miss whenever I use Haiku Depot.
Some day I’ll find the time to dredge up the source to that GUI and look at whether I can make that work in Haiku Depot. ![]()
I did my fair work on packaging for BeOS and ZETA back in the days, also with installer packages, so I know my history there
One of them being the sdl-games libraries, where all required SDL libraries where packaged into one, if one changed the whole package needed to be updated, not to mention required apps that needed them.
IMHO having package manager the way it is now makes live a lot easier (on the note where this came from, the package from @X512 is not included in the depot, hence the conflict was not clear, second, the offending package had a wrong dependency - which is fixed - triggering the conflict).
Maybe this conversation could be moved into a thread for package manager? Getting way off topic in this one. ![]()
Not marked as native in the HDS. Sorry, I don’t have the privileges to fix that.










