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.
GCI winners trip 2014 report
Hi there!
I’m reporting from San Francisco today. This week I was visiting Google, meeting with the two winner students from Google Code-In as well as the students and mentors from the 11 other organizations participating in GCI.
In case you missed it: GCI is a program run by Google for 13-17 year old children. The goal of the program is to introduce them to open source software and get them contributing there, and to get them interested in computer science in general.
As of hrev49248, TeX Live 2014 and LyX 2.1.3 have been added to the Haiku Ports repository!
A word of warning: TeX Live is a mammoth 823MB package, and LyX, whilst not massive, is another 20MB or so. These will undoubtedly take some time to download for installation. Also, upon first launch of LyX, it will appear to not open any windows. This is normal, as LyX is generating a whole bunch of data it needs, which will be stored at ~/config/settings/lyx. Subsequent launches of LyX should be fairly quick.
Hello world!
This week was rather slow: I've logged only 18 hours of contract time this week. I expected this, partly because I didn't expect to do any work on Monday (as mentioned in my first blog post) and partly because I still had some coursework to finish up the semester with. But despite that, I got a ton of stuff done, and the foundations for the following weeks' work are well laid.
Anyone following the "haiku-inc" ML will have noticed that I've been approved to spend 240 hours (around 6 weeks of full-time work) on Haiku's packaging infrastructure. This mostly means I'll be working on the package building system, which will manage the "HaikuPorts" package repository, ensuring it's up-to-date across architectures (and later, across both nightly & release builds).
