Developers’ Weblog

Sponsored by
HostEurope Logo

Developers’ Weblog

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

The MirPorts Framework can now be used on MidnightBSD out of the box, no special patching needed. MirMake, MirCpio, MirCksum and the package tools have been updated appropriately.

However, MirLibtool support is still missing. This is trivial, I just don’t have the time to do it right now, as I should be doing the release at the moment. Still, feel free to play with it.

Yeah. I did port MirLibtool to mnbsd, and found a bug (in upstream, even) while doing it. Nicey. Both devel/glib1 (autoconf-2.13) and devel/libtool (autoconf-2.61) seem to work (regarding libtool build systems, shared library building/naming, etc.) for now. I’m a little bit unsure about shared library naming conventions, but you can follow FreeBSD’s, even though Todd Vierling and I think they are weird and/or not what one wants. (For insiders like Benny: they do not use current/age/revision, set the third number to 0.)

We have a new “p5” port module, which must now be referenced by any users of ${P5ARCH} which do not include the “perl” module.

pvalchev@obsd replied to my issues with the UMAC64 hash that I might want to report the bug in libgcc’s umoddi3 implementation upstream. This shall be my TODO, someone please remember me to do it (check how to reproduce on $common_os, with $latest_gcc, etc).

miod@openbsd is helping me with the tvtwo(4) card – unluckily, I’m unable to test diffs because my monitor is too small… Doesn’t anyone happen to want to give away a TFT that can do 1152x900 for free? ☺

GPLv3

14.03.2008 by tg@

As written in my earlier entry (still to be ok’d by benz) about GPLv3, editors/nano is okay (for now). This means that rsync 3 is probably ok to go in now too (especially since we have no patches). It’s said to be much faster and less RAM-hungry, which is especially nice.

Besides from my TODO on MirPorts (and the portable subprojects) and MidnightBSD, and the release engineering process, and my other want-to-do hobbies like hercules(4) wsfb(4) support (and an XF86 module, and emulation support for a HGC in qemu), and a couple of other things, Waldemar has made a point:

MirOS definitively needs to shift away from “we want to make OpenBSD better, and we do X, Y and Z” towards “we want to do X, Y and Z, specialise on W, support V, and while doing all that, we are of course as secure as OpenBSD and track their goodies, and by the way, we have GNOME and Frozen-Bubble”. This would give the MirOS Project an actual face, which could attract users and development capability/potential. (And it would imply a re-design of the Flyers’ and website’s content…) We’ll have to think about it, but he is probably right.

The new cksum port sets a variable HAS_CKSUM, which will be used really soon now in the MirPorts infrastructure to replace all the old cruft (_CKSUM_A, _CKSUM_SIZE, _HASHES). From RSN on, you will either have our current cksum(1) from MirOS #10 or MirPorts, or you won’t, in which case it will only use the “cksum” algorithm of the OS’ own cksum programme (which is rather ubiquitous).

We have a new sample file, “portmdoc”, and I’ve converted yet another manpage to be fixed with regards to GNU groff, like I did with mksh(1) after the R33 release. Expect this to continue.

The FSF is now mistaking that lazy moronic finnish student’s excuse for a patch management system for a version control system as well… the config.{guess,sub} files are now in git. Yuck!

Our kernel now should handle signals wrt the extended i386/amd64 ABI fine: thanks to the Debian GNU/kFreeBSD developer Aurelien “aurel32” Jarno, the direction flag (DF) is now cleared on traps.

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

MirOS Logo