Sometimes it’s good to double-check. Benny has found a bug in my fix to gnu.port.mk, leading to incorrect dependencies. I couldn’t get the sparc floppy to boot – several NetBSD® users had the same problem, leading to a posting about how to clean a sparc floppy drive, luckily. Note that I am lazy, that’s why I just tested the floppy in my SS10 instead. This gave me quite a hard shock, though.
I prepared the Mini-ISO, and – new – a Midi-ISO containing the floppy images as well (if extra netboot kernels were required, they would be also on it, but boot.net is enough), which will take the place of cdrom10.iso on the download area, while the Mini-ISO will sit on the release ISO.
This means we’re now all set to release today. *crosses fingers*
Yay! I got a SPARCstation 20, a SPARCstation 10, and a SPARCstation 5, several CPUs and sbus cards, an external HDD, an external CD, and some more toys, from wbx@ – he has no sparc parts left now. Sad, as he is the initiator of MirOS/sparc. Good, because I can cluster them now. I could test the framebuffer, XFree86®, even build binary packages with distcc if Benny ports it (I still have to get on friendly terms with distcc first though, and I won’t use it for official releases).
Being the better OpenBSD sometimes sucks. For instance, if our make(1) implicit rules generate grammar.h from grammar.y, and not y.tab.h, as a certain lex.l wanted to include. Well, that could be fixed – re-rolled ports10.ngz with new games/bsdgames.
I’m building a number of selected binary packages on the sparc and very few basic ones for i386, to add to the release ISO. (More binary packages can be downloaded from our mirrors later.) This is holding us a little, but I’ve got plenty of time over the weekend to carefully finish the release engineering process. Better than having bugs, eh?
I actually found a bug in gnu.port.mk during porting to mnbsd; gecko2@ had found it too but I couldn’t reproduce it back then.
Sorry for all the delay in the release announcement and publication, but first we have to get the ISOs ready – since they contain i386, sparc, source and CVS it’s a tad difficult and quite time-consuming.
Ha! Giving support in #cvs in IRC and being called life saviour, master, etc. is really giving me the chills, in a good way.
I’m exhausted, will continue hacking on the release tomorrow.
I’m trying to hand-bake a floppy for the sparc though. It won’t contain an installer, but enough to download an installer onto a HDD. Ports have aborted (gnupg can’t import keys, but decrypt them just fine – weird), but I’ve got enough for tomorrow.
It’s really annoying. This is actually a pre-release issue. There is a port, editors/nano, which snuck in before the release, containing GPLv3 licenced stuff. This means that I either have to remove nano from the mirports tree for #10 or read the GPLv3 and allow it into the tree.
Looking for OpenBSD’s opinion on GPLv3 in ports, I found that my “dear friend”, the oksh developer, has struck again: his oksh-0.3 is GPLv3’d now. (At least he did not remove the UCB copyright from some files.) And to add insult to injury, the description of oksh at Softpedia, which is almost certainly provided by my “dear friend” Henry Jensen <email@example.com>, pretends that mksh(1) is not Bourne compatible (which it is, at least no less than oksh) and buggy, which it definitively is not. He said that, at the time of his forking, mksh was buggy, but could not tell me one single actual point. His only complaint against mksh was that it does not support the GNU bash-like $PS1 hackery. *sigh* (Did I mention that oksh-0.1 violated the MirOS licence on mksh?)
Phew, I read through it. And I think we have a sort of official stance on the GPLv3 (even though bsiegert@ of course has to agree to make it truly official). I still don’t like it, but it could be worse, and for ports we do not need to care that much.
Today, I helped wbx@ to clean up his basement: DECstations, SPARCstations, VAXstations, Alphas, mac68k, hppa, SGI O2 and Indy, and some other boxen either went to the recycling company today or will tomorrow. gecko2@ retains some mac68k and maybe one hppa, I try to get some 32-bit sparc parts, and bogus got an E450 (heavy!) and an Ultra1 for toying around with, as he now exclusively runs Solaris.
It’s annoying that not every CPU works in every SPARCstation – for example, the two SPARCstation 10 we found have 33 MHz CPUs and 400 MiB HDDs, one has OpenBSD on it, one Solaris 5. Nice. Tomorrow we’ll look at the two SPARCstation 5 which are still there. The monitor sadly doesn’t work. Maybe one VGA conversion cable from the SGIs will help, but I don’t have a monitor capable of doing the sunfb 1152x900 (maybe with a zx(4) card…)
The SPARCstation 20 of mine (“demo”) has finished building the release kernels and tarballs, so I can proceed with the release engineering process ASAP. Like I said, we’ll do a unified medium. As with i386, the preliminary dist sets may show up on the download mirrors already for a while…
Building the release took about 6h22′ at 1 GHz on i386, and 81h22′ on 75 MHz on sparc, for what it’s worth.
Für lange Zugfahrten o.ä, wo man keine Lust hat zu hacken, ist ganz gut dies hier geeignet: z.Zt. 128 je ca. 200 Lynx-Seiten umfassende Harry Potter Fanfics, die ein recht logisches, aber manchmal nerviges Universum, das jedoch sich streng nach dem Original richtet, aufspannen. Einfach runterladen und dann offline lesen.
Ich bin ja ehrlich gesagt immer noch am sicken, daß Freenode mir einfach den Nick „lynx“ geklaut hat… jetzt kann ich gar nicht mehr so deutlich anzeigen, daß ich am Schmökern bin. Merke: wer „linked nicks“ hat, sollte diese trotzdem alle 29 Tage mal touchieren, da man im Staff nicht nachfragt, selbst wenn der Hauptkontakt gerade online ist.
I’m still pissed about Freenode taking the nick “lynx” away from right under my arse, having been online with the main nick of “linked nicks” (the NickServ feature), just because I had not used that nickname for a while. Note: touch all alternative nicks every 29 days. RichiH says it’s policy to at least ask the owner, but seemingly they don’t.
Oh, another wlog entry ☺
I found out that, actually, you can commit into both a branch and HEAD within the same directory on the same commit command. It’s just our log scripts which suck. This will be fixed RSN. It works if you use another, different directory as the last one (like I thought). This also means you can ignore commitid 10047D8245653D8184A and 10047D8248447FC1F5F, as these never went live.
Someone wants to do an appliance with FreeWRT, maybe I can let him hire (and pay) me for that. I could definitively need the money at the moment (hint hint).
If not, I can always port MirPorts to MidnightBSD…
… and I actually did, this will lead to some changes, even a few real improvements not only for mnbsd but for mbsd too.
This is probably the last entry in this wlog. If you are using the RSS feeds, you might either want to subscribe to https://www.mirbsd.org/wlog-10.rss, or change your subscription to the new (as of yesterday) feed at https://www.mirbsd.org/wlog.rss, which is a symbolic link to the current developers’ weblog.
A fix for the ppp(8) security vulnerability has been committed to MirOS #10-stable already. This is still in time for the release, and will be included in the source10.ngz dist set as well as in both i386 and sparc base10.ngz dist sets. Thanks to TNF’s replaced, who mentioned the issue to me in the #!/bin/mksh channel in IRC.
The i386 part of the #10semel release is already built, but, oh WTF we don’t have a codename for this release yet. Well, the sparc part is still compiling, which leaves us another few days to think of one. I’m already uploading part of the sets, so that the distribution process will be quicker later. (Some of the files will change later on, though.)
Benny already has written a release announcement draft. Like I said, he is my best man. He didn’t even attempt to list the changes, which might even be the better approach… In the meantime, I’m updating some of the web pages already – you can, in theory, netinstall #10 now, but some links will have to be fixed later.
I still urgently need a SCSI host adapter for my new server tear, U160 or U320, SCA LVD, 32-bit PCI, no RAID, supported by MirBSD (i.e. OpenBSD 3.5), as the current one, donated by wbx@, has issues. Or a fix. Plans to migrate to tear have been postponed due to this problem, which makes the progress in the project seriously suffer.
The code is almost frozen, we’re only waiting for a few updates that should still go in. Benny allowed me to add the ‘u’ to the flavour variables of MirPorts, after a year or so of thinking about it ☺
I fought the Leopard today, but I won: we can now use our own getopt(3) suite on Mac OSX 10.5 again, and some other bugs and minor issues have been fixed too. Plus, all the hashes, including ADLER32, SFV, SUMA, TIGER and WHIRLPOOL, now work on Darwin too (tested on both i386 and macppc).
Now it’s release engineering. I have started tagging, after a few final updates and fixes, and asked Benny to write a release announcement. Let’s see when the builds are done, calculate a good four days for the sparc side. Afterwards, we’ll switch to wlog-10, and back up the repo to get it all on one CD (i386, sparc, source, CVS).
Thanks Benny, I’m glad to have a developer like you too.
Whew. mksh is done. I hacked a little on mcabber, and if your libc is recent enough, it even can display the new uppercase eszett the DIN proposed onto us (ẞ ← it’s in fixed-misc in MirBSD, and in a few other fonts such as the Linux Libertine). Mine wasn’t, of course. My work system is, actually, too old… (currently I’m building i386 stuff either in a chroot or in a dual-boot).
Now that tg@ is back, MirOS has certainly regained its momentum. Great work, it is good to have a developer like him.
For the last six months, we always distributed the same snapshot on exhibitions. I am almost ashamed to admit that the CDs we had at FOSDEM 2008 were burned from the FrOSCon 2007 ISO image that I had lying around on the showcase box, schaaf.mirbsd.org. So my radical proposal was: the code we have has had a lot of testing already and has shown no show-stopper bugs (except on the new Intel Macs, but that is another story). So: let's release what we have and call it MirOS #10.
However, we urgently needed to apply some security fixes first. My task was X. I managed to update the included freetype to 2.3.5, which contains many security-relevant bugfixes and is recommended for all users. Alas, many places under xc/ have to be touched for it to integrate well. I also applied the X.org patch from OpenBSD 4.2-stable. I had to do the applying by hand as there seemed to be some coding style changes from XFree86 to X.org but the code itself seems to have been mostly unchanged since 1987 or so. Some of it does not even have ANSI prototypes (in XFree86 at least).
Some ports have also been updated, mostly security fixes. My build machine is now MirOS in Parallels on a MacBook Pro. I have aqua/qt4-mac in my tree but it does not install quite right yet. A new, unified Ghostscript port is also in the pipeline. However, convincing the build system to only use the system zlib proves difficult.
After pushing out the mksh distfiles, ports, etc. (and, of course, spotting a couple of bugs too much for my taste), I finally found time to work some more on my TODO. rm(1) now can do random overwrites including file (and directory) renaming to random values before unlink(2)ing (and rmdir(2)ing). Thanks to TNF, again, for some of their code and bugs.
Another thing is putting the installer onto the Baselive CD. This would not easily be possible as of now, I see, because it uses, for example, some hard-coded paths like /mnt and commands like umount -a -t nonfs, which could cause normal operation on the rest of the running Live CD environment to cease. So this will not be in the tree in time for #10semel. Sorry, Benny, it was a good idea we had.
I also upgraded OpenSSH, but un-did the unifdef(1) -DBSD_AUTH change, as we need a non-BSD-auth version of sshd(8) for bsd.rd. During the process, of course, bugs were spotted… e.g. in the docs. Of course, the new internal sftp subsystem isn’t on the ramdisc, either.
And, I upgraded Sendmail, without the support of OpenBSD…
Note: new kernels and old /sbin/sysctl and /usr/bin/uname, and vice versa, will not have the kern.ospatchlevel entry, which is required to build XFree86® and/or imake(1) with MirOS.