I’ve tried building the ppc bootstrap and got severall faults about sources not beeing available because the gnu mirror url was wrong. I fixed it locally.
Now there seems to be a fallback, a haiku-mirror server that it tried to use, but that one also does not work, what happened to that? It seems like an important part to keep working, just in case the gnu mirror is actually down at some point.
On another thing, how can i submit the haikuports.cross patch? any objections to moving the repo to codeberg? it should fit into the storage limit even if the webkit issue is not yet resolved.
One second issue, I am having trouble with texinfo, it has some problems in the code… i may try to update the package, but at the same time this seems to only be for documentation? why is this in the bootstrap build?
Gcc needs it. Unless you can figure out how to build gcc without it. But then some other package may need it as well.
You do not need anyone’s approval to create a fork at codeberg. Then it is easy to get your changes from there and push them back to github. Do you want to solve the ppc port bootstrap, or the haikuports move to codeberg? These are two independant and unrelated issues.
Offline because it was complicated to set up with the current builders, and because it was using a lot of space as it kept every version of every recipe. It was also difficult to sort out what the content was because many recipes don’t correctly set SRC_FILENAME when needed, and as a result the archive files had random git sha1 or just ‘v1.2.x.tar.gz’ without a project name.
It may return now that the builders are moved to S3 storage, but the old mirror is gone.
This is 100% on the todo list. I felt bad tossing it originally, but we were having some serious growing pains a few years ago and the source repo of “every haikuport package” was getting intense. I opted to toss it to prioritize getting haiku / haikuports stable.
PowerPC is going to need a lot of work. We shut it down originally because zero people seemed interested in working on it. Mix in the aging, (and generally expensive to maintain) Apple hardware… and the lift seemed too great.
With that said, if there’s serious interest, we can always add it back to the build systems, etc. Just keep in mind that someone has to manage the architecture for the long-haul (testing / patching / building when we upgrade gcc toolchains, icu, etc)
I’d be happy with “just” the bootstrap packages having backups. Those seem important to the core of Haiku, but other packages not so much (don’t see a particular threat to haikus build if some random kde app can’t be build…)
Did we? As far as I know nothing was removed from the sourcetree.
It never booted to the desktop, like several other ports. And there is not a lot of activity due to lack of interest. But all it takes to fix that is someone willing to spend enough time on it
There was another problem with imagemagick, wrong checksum and wrong contents of tarball (did they update it?)
Fixing that and now would be on the step to boot the image in a vm, but no dice. I tried qemu powerpc but the finished 20GB haiku-bootstrap.img seems to not be bootable, atleast I can’t figure out how to get the openfirmware in qemu to try and boot it… supposedly it is attached as cdrom.
I’ve had no problems with removing texinfo from the build to get the bootstrap image build. presumeably a gcc image inside the vm would have a problem? but that makes no sense to me, surely there has to be a gcc already available in the vm…
You need to boot using the boot_loader_openfirmware file (should be somewhere under objects, haikuloader does not work for me). For real hardware, I’m using a tftp server and the disk server to boot from haiku-bootstrap.img . Before that, I manually created hfs disk files, on which I moved the bootloader, which could then be boot in qemu
It should do if you use the right build profile or target. The problem is, build profiles have been misused to hrovide different image types (raw, anyboot, iso) in addition to what they are for (minimum, bootstrap, nightly, release, defining the content of the image).
I think this was done initially to workaround a bug in jam where you couldn’t specify both a profile and a target, but this has since been fixed.
I think you can do something like this, but no guarantee it will work:
jam -q @bootstrap-raw haiku-boot-cd
(For reference the haiku-boot-cd target is defined in build/jam/images/CDBootImage, you can see there that it has a special case for powerpc with a completely different setup than other systems)
ways to make this simpler:
document this state of affairs for the powerpc build,
try to add a bootstrap-cd profile in build/jam/DefaulBuildProfiles and see if that does the right thing (this should be an easy copypaste job by looking at the other -cd profiles defined there),
clean up build profiles to define only the build type (nightly, bootstrap, …) and not the image type, and update all documentation on how to build different image types
make the anyboot tool able to generate bootable image for powerpc/openfirmware, so the bootstrap-anyboot profile could be used (right now, the anypoot tool is efi, bios, and oios-cd booting only)
use network booting (in this case you need a raw image and the bootloader as a separate file, and tou need to set up a tftp server, but it is very convenient to build from a modern x86 machine and test from a powerpc one - not as useful as long as you’re using qemu to test things)
For completeness, the ARM port suffers similar problems, as the “mmc” image is tailored for one of a few specific boards, and won’t work on anything else. Kallisti5 wrote a host-processing tool in Rust (called Rune) to “fix” the image for various boards. Ideally this would be done inside the buildsystem, but it’s hard to find people willing to rewrite rust code into c++/jam/python, and it seems addind rust to Haiku’s build dependencies may not be acceptable. So for now this remains as a separate step, that can be done by the nightly build servers.
