A lot has happened since my last report. I decided to spend some time working on stabilizing both Haiku and the packaging system, and so I am closer to having full builds & HPKR generation, but I’m not quite there yet.
In a previous blog post, I had described the newly added ability to edit raw memory. While this makes a number of things possible that otherwise wouldn’t be, it generally isn’t the most convenient approach for the more general case one runs into over the course of debugging. As of hrev49449, some new enhancements have been introduced that should make life much simpler in many cases.
I’m back from the Libre Software Meeting (RMLL), took me some time to recover from the highly packed week. Indeed, in addition to the mandatory Haiku booth, I had 4 talks to give (and so slides to finish), and I ended up being chairman for the Embedded track.
Luckily Olivier was here as well to look after the booth, even though he was also involved with the organization.
Hello again!
It’s been two weeks since my last report, as I wasn’t working full-time these past two due to some outside appointments and other conflicts. I’ll be back to working full-time next week. Despite this, I managed to make a lot of progress on a number of fronts.
Since some time, I am working on a replacement of our current shell script based boot process to something more flexible, a similar solution to Apple’s launchd, and Linux’s systemd.
While there is still a lot to do, it’s now feature complete in terms of being able to completely reproduce the current boot process.
Since the switch to our package manager, there was no longer a way to influence the boot process at all. The only file you could change was the UserBootscript which is started only after Tracker and Deskbar; the whole system is already up at this point.
The launch_daemon gives the power back to you, but also allow software you install to automatically be started on system boot as well. You can also even prevent system components from being started at all if you so wish.
As an operating system that implements the POSIX specification, Haiku includes support for signals, and the requisite API calls for an application to decide how it will handle them. While these aren’t really used by the Be API in any meaningful way, they do frequently come into play for ported applications and libraries. Up until now, however, our debugger has lacked support for them, which could make debugging situations involving signals a less than convenient affair if one didn’t already know what to look for. As of hrev49356, this has been rectified.
After I took last week off for vacation, this week went very well. HaikuPorts has been migrated to GitHub, many corner cases related to HaikuPorter have been resolved, and most of the infrastructure issues that were directly related to setting up the package build server are gone.
Hi there, it’s time for the monthly report!
Statistics
Commit range scanned this month: hrev49209-hrev49344.
There are currently 38 tickets open in the beta 1 release. For the first time, we are below 40.
Hello again!
As mentioned in last week's report, I planned to work on integration with IRC to allow the developers to get real-time updates on what the builder was doing, finishing the documentation, and then working on the logic that actually builds packages. The first two of the three are pretty much done, and the last one I did get started on. So this week went pretty well.
Hello, Haikuvians!
This week was just as productive as last week. I did start on the builds logic, which now can run "builds" (lists of commands) in sequential order. I also improved the builder management system, and created documentation for pretty much everything.
