This is only resolved if one does not plan on actually using haiku. QupZilla is brioken on 32 bit haiku and qt4 is broken everywhere.
“If you encounter any packages that are still uninstallable or whose apps are still crashing, please pipe up”
A bit of a hard judgement. Haiku and most of the available apps do work fine now. Qt4 is sadly broken AFAIK, so if those ports are vital to someone, people should hold off using a newer hrev.
I tried building Qt4, but it failed.
Calling this resolved is a bit optimistic and intentionally ignoring the apps that were broken. Qupzilla is the most stable and reliable web browser on 32bit haiku. With qt4 broken, so is the only really usable browser, and many ports that are indeed useful. Until qt4 is fixed, Haiku is still broken.
“Haiku” certainly isn’t broken, just a third-party non-essential library is currently missing. I understand you personally find Qt important, but claiming that Haiku is broken, or that it becomes unusable due to this, is hyperbole.
This happens every time we start talking about a beta release, Some haiku dev breaks 3rd party software by changing things, then ignores all the trouble he caused. This one isn’t as bad as the last time. Last time we lost Haikuware, a good source of 3rd party apps. This time I think the haiku devs need to do a complete job of fixing what they broke and maybe then we can actually see a beta before 2030.
Hello bbjimmy. Did you tried with the HPKG from the new (experimental) repo?
http://eu.hpkg.haiku-os.org/haikuports/master/repository/x86_gcc2/current/packages/
There are a newer Qupzilla package, build against Qt5.
I guess all the efforts are put in this automated repo.
Yes, I found Qupxilla for gcc2, it launches but crashes even more than Web+
I think you’re mixing things up here.
The Haiku devs changed the ABI, by changing the (formerly?) private BControlLook class. This had to be done before a beta release. This resulted in the developers using that private class - knowing full well it might break and require a re-compile of their app - to re-compile and publish their software.
The Haiku devs are really only responsible for maintaining the applications bundled with Haiku, i.e. WebPositive, Vision, BePDF. Updating those took longer than it should have, therefore the warning on breakage.
You can’t have the Haiku devs responsible for every application in the HaikuPorts repo. (Currently, they still are the bottleneck to upload updated packages, but that’ll be gone when the switch to the buildbot-repo is complete.)
Of course, one could lay it all at the feet of the volunteers working on the HaikuPorts recipes, but to me that hardly seems fair.
These are the consequences of too few people trying to maintain a huge number of packages. The alternative is that these few people only care about a few packages, with the result that fewer packages in the repo. Which is practically the current situation: Qt and apps depending on it are not in a working order.
Yeah, I know, I don’t like it too much either… but since I wasn’t able to fix the Qt4 recipe, I have to wait until someone has.