I think this part should be cut. _doc should be a seperate package type, and not required for any normal mode of operation.
Funnily enough you can’t build doxygen with documentation on gentoo directly, because it also can’t resolve this. : D
If this is the only one depending on Qt5 maybe an idea to create a seperate _doc recipe for it so it shouldn’t be needed?
Having a Qt dependency to build Haiku should be a nogo.
EDIT: or even have a seperate qt5_doxygen package? (so one could still use the cli version with the qt dependency)
The dependency on doxygen was removed in xz-utils 3 months ago, so the latest released version 5.6.2 doesn’t depend on it anymore:
For previous versions one can pass the --no-doxygen option to autogen.sh (like it’s done here for example: oss-fuzz/projects/xz/build.sh at master · google/oss-fuzz · GitHub).
A separate package won’t help here, the problem is at the recipe level. The bootstrap process needs to download everything needed to build each recipe, even if some of the built packages end up not being used for the build.
So we’ll have to cut these dependencies in some other way. Maybe making special, smaller versions of the packages for bootstrapping. Or maybe some of these dependencies can be removed completely.
I’ll see what happens when I have all the packages downloaded, the bootstrap image built and booted (if that’s even possible currently for PowerPC) and I start trying to run haikuporter inside it.
The more urgent problem is: is it OK if I remove cmd:python (and leave only cmd:python3) in the gstreamer and gstreamer plugins recipes?
Yes, i think that would be best. I think the concerns of haikuports in generall are different to those needed for bootstrapping.
Or Muon written in C that have only C99 as dependencies: GitHub - annacrombie/muon: An implementation of the meson build system in c99.
I manually removed such dependencies for riscv64 to avoid building heavy things such as Qt, LLVM, WebKit. Also it was mysterious random crash on riscv64 for a long time that do not allowed to build big projects. Crash is now fixed in my DM v2 branch by switching to mimalloc.
1 Like
Well, not really. The idea is that you can start from a minimal set of packages (the ones defined in haikuports.cross) that you have to cross-compile, and from there it’s possible to build everything else in haikuports.
If that’s not possible, you have no way to port Haiku to a new CPU architecture, or do a big ABI change, or anything like that. So, haikuports should make sure tha there is a path for that. One solution may be having more things in haikuports.cross to start the build with a more complete base set of packages, but if there are ways to cut down on dependencies, I think that will be easier to maintain.
So this has to be, at least in part, haikuports responsibilities. I’ll see what I can can do (for now it’s still downloading things and preparing source packages…)
I think this minimal set should not be the same as normal haikuports as such, a minimal package of lzma does not have to be the same lzma package used normally for example.
It is okay to have this in haikuports if you want, but that doesn’t mean that the bootstrap packages should be the ones you’d normally use.
1 Like
git show 9d0933434a shows that cmd:python added in 2019 to “fix build for secondary arch”.
While I haven’t tried rebuilding it… seems removing it shouldn’t affect your use case at least?
There is also an option to make special reduced bootstrap version of packages with less dependencies used for building other packages, for example freetype_bootstrap.
1 Like
Ok, next problem 
The netpbm download is broken. The recipe is pointing to a github mirror of the sourcecode, that, as far as I can see, never was officially related to the netpbm project. We did that because FreeBSD used the same mirror sometime ago, but honestly, it is a bit scary that we would get the sources from random mirrors.
Anyway, that mirror on github does not exist anymore, and so the netpbm sources can’t be downloaded. And the bootstrap will stop because of that.
The thing is, the NetPBM official page does not have download archives for the version we are using, only older ones from their “super stable” branch (we were using an older version of the “stable” branch). Would it be OK to switch to the super stable branch and go back a few versions? Or should we get the source from some other unofficial place? Or extract it from their SVN repository somehow?
It is listed here: Some of source URLs are not available anymore · Issue #10333 · haikuports/haikuports · GitHub.
I tried that, but unfortunately there are other paths that lead to Qt 5 being included.
Currently the bootstrap is trying to build:
The following required ports will be built first:
media-libs::netpbm-10.91.01
dev-libs::glib2-2.78.0
media-libs::gstreamer-1.22.0
sys-apps::texinfo-7.1
sys-apps::groff-1.23.0
net-misc::curl-8.8.0
sys-libs::mesa-22.0.5
x11-libs::cairo-1.16.0
dev-util::gtk_doc-1.33.2
media-libs::fontconfig-2.13.96
app-text::ghostscript_gpl-10.03.0
dev-libs::gobject_introspection-1.78.1
dev-build::cmake-3.28.3
media-libs::gst_plugins_base-1.22.0
dev-lang::ruby-3.2.2
media-libs::gd-2.3.3
dev-lang::python3.10-3.10.14
dev-lang::python3.9-3.9.18
dev-vcs::git-2.45.2
net-libs::gnutls-3.7.8
dev-lang::python3.11-3.11.8
dev-lang::python3.12-3.12.2
media-libs::gst_plugins_bad-1.22.0
app-text::texlive_core-2024
dev-qt::qt5-5.15.14
(this is not a complete list, just where it’s failing now because of netpbm that is brought in by one of these things, and then the whole dependencies end up being not resolved).
I guess at least cmake depends on Qt because of cmake-gui, and then that brings in gstreamer and its plugins.
Also I’m not sure why Python 3.9 is still showing up here.
Well, at least it goes past the initial error that was a bit hard to understand. I think I will take a break from this now, and hope someone else can resolve some of these problems so it goes further next time I try it 
2 Likes
Never done anything related to haikuports.cross, as my daily drivers are Haiku installs I already found out that it’s not possible to do this inside Haiku. So I guess some other OS would have to be used then.
I’m more surprised to see:
dev-lang::python3.11-3.11.8
dev-lang::python3.12-3.12.2
in there. Besides providing setuptools/pip for them, we don’t use them for anything over HaikuPorts currently, AFAIK.
Why is texlive_core in that list?
And again, that doesn’t look right to me. By default CMake should be built without the Qt GUI (--no-qt-gui is turned on by default). Why do we explicitly specify --qt-gui in the recipe? It makes sense to remove it and create a separate cmake-gui recipe instead.
I second that. Qt is too huge to be required for building Haiku, and we shouldn’t go down that rabbit hole.
Just checked the new xz_utils without the doxygen requirement, builds and packages fine.
It’s weird that cmd:dot isn’t listed in the recipe, from what I found so far doxygen doesn’t work if it can’t fine cmd:dot, so I even think this isn’t used at all in our current package for the build.
EDIT:
To be sure I checked out current version in the haikuports tree, fails without doxygen.
+ sh update-doxygen
doxygen/update-doxygen: 'doxygen' command not found.
doxygen/update-doxygen: Skipping Doxygen docs generation.
1 Like
Doxygen can be skipped by removing the cmd:doxygen and adding --no-doxygen to ./autogen.sh in the xz_utils recipe, and it should be disabled (it’s not needed for a bootstrap image) so that it doesn’t drag the whole avalanche of Qt5/gstreamer/…etc dependencies.
1 Like
If cmd:doxygen isn’t in the recipe the configure option is obsolete as it won’t be found.