MidnightBSD Developer Journal

I was going to write about my progress with pidgin tonight.  Its now included in ports (2.0 beta 7) with 2.0 release almost working. 

I could write about how ctriv has fixed many of the ports in devel and several other categories lately.

That's not the big news though.  One of our largest hurdles has been getting a native web browser on MidnightBSD.  When I say native, I mean really native.  Opera was working before our mports fake changes, but that's technically a FreeBSD binary and it won't be "native" forever.  Tonight, I managed to get mozilla 1.7 semi working on my box.  Currently only the browser component (Navigator) is compiling with debug flags.  The fake and install targets aren't up to snuff yet so you can't install it just yet, but its possible to run it.  In fact, I'm writing this post from native mozilla!  Even after I get this working much better, we'll have to figure out how to unbrand it since we can't distribute official builds of their browsers. 

Archite did most of the work on mozilla.  He should get most of the credit. 

I don't know if we will make the June date for release or not now.  It might be possible to do it. 

I'm making changes to the CVSup server tonight. If you are using CVSup to fetch mports, note the example supfile was changed. The change was checked into current and stable.

For those of you mirroring MidnightBSD CVSup, we now support prefixes as the other BSD projects do. I'm still testing and playing around with a few things.

If you wish to setup a cvsup mirror site, these directions may now be useful. http://motoyuki.bsdclub.org/BSD/cvsup.html

I've also enabled some connection limiting since our main server can only handle so much.

This is one of those projects I've been putting off way to long .

I don't recall if I announced this, but I added our website to cvs a few weeks ago. The module is "www".

I've just added several translated documents to the midnightbsd.org website. Special thanks to Klu for translating them.

I should introduce myself. I'm ctriv; one of the newer comitters here on the project. I've been working on changes to our mports system.

As mentioned earlier, ports now "fake" install into a temporary directory and a package is made from that temporary directory. This package is then installed with pkg_add. This makes the logic of the ports system much simpler. Everything builds a package. Ports only need to know how to build the package. Much of the work that pkg_add does, such as maintaining the package database and running install scripts, is not duplicated in ports.

Unfortunately, such a large change in the system means that many ports no longer function correctly, but in the last week a great deal of progress has been made. The GNUstep core ports have all been updated. GNUstep-make 2.0 has helped a great deal - almost every GNUstep port now works correctly.

GTK and KDE have been updated, as have all the editors except vim5. Changes to bsd.mport.mk have really improved the state of things. The failure rate of ports continues to drop as the system matures.

I'm continuing to go thru the ports tree, my hope is to have all the ports updated by the start of summer.

This blog will now be updated by two people.  I (laffer1) and ctriv will both post updates.  ctriv knows more about the status of mports as he's actively working on it. 

New ports today:
devel/patch
editors/2bsd-vi
editors/impress
archivers/p5-Archivers-Zip
sysutils/p5-File-Which

ctriv has been commiting fixes for many existing ports all week. 

CURRENT and STABLE both have the patch for ipv6 type 0 routing headers.  The problem is that ipv6 routing headers could be run over the same link multiple times.  We've been debating how to best handle this problem over the last few days.  It was a known issue with the RFC, however, OpenBSD recently brought it to everyones attention.  Their solution was just to add an ifdef 0 in the code which seemed rather poor.  There are research cases where this could be useful.  If your system is not acting as an ipv6 router, it is not needed anyway.  While most MidnightBSD systems are intended for desktop use, home users often use *NIX systems for personal routers, etc. 

We chose to use the FreeBSD approach of adding a new sysctl to enable the old behavior. 

For more information, consult the OpenBSD website or the FreeBSD security advisory FreeBSD-SA-07:03.ipv6. 

I urge everyone to flood the gnu config project with config.sub and config.guess patches for MidnightBSD. One was submitted last year and magically new rules were made to keep us out. bje doesn't like BSDs.

http://savannah.gnu.org/projects/config/

Here's an article on debugging the FreeBSD kernel which also applies to MidnightBSD.

I've decided that I'm going to avoid ports for awhile.  There is a great deal of work to do in other areas of the system.  Apparently, I'm not keeping up with ctriv's changes. :)

I'll still maintain several ports that I've commited and possibly change the maintainer on them to my personal email address. 

I'll need to work something out with Phil and Chris for status reports that we can publish periodically.  I am not sure if RELENG_0_1 has been getting the mports updates as current has.  At this time, I do not know if we will hit our June target for 0.1 Release. 

I expect the project to move slowly over the next week.  Most of us are very busy this week.  I'm in limbo with sysinstall until I can test the installation of new packages.  I've started some minor changes to the loader.

I don't want to get too involved in the bcw driver debate.  I just wish this wouldn't have happened as I was personally looking forward to a BSD implementation for broadcom chipsets. 

http://undeadly.org/cgi?action=article&sid=20070406104008&thres=(u+*+100)+/+c+%3E=+75

Had this happened to us, I would have hoped for a private contact from the GPL code owner.  I also would have wanted to release this information myself through the project website instead of what actually transpired.  The OpenBSD project has a stronger view on GPL that we do.  I suspect this was part of the reason the reaction has been so strong on both sides.  I feel bad for the OpenBSD developer. 

I might as well take the opportunity to clarify our position on licensing.  In short, BSD code is preferred.  We hope to maintain the kernel + userland with BSD licensed code.  Obviously, using GNUstep we have a great deal of LGPL and GPL 2 code in the X11/GUI portions of our system.  We are trying to keep that code as default installed ports to keep it isolated as much as possible.  At one time I greatly disliked the GPL, but now I've realized there are some cases it makes sense. 

Our stance on BSD only code in certain portions of the system must be so in order to share code between our project and the many BSD projects.  We could start using GPL code, but then we would become an island with no other land masses to swim to. 

ctriv committed fixes for the qt33 port, and opera.  He's also working on GNUstep.  gnustep-base and a few other gnustep ports are now working.  If GNUstep is already installed, some GNUstep ports are working.  Many still have make package related errors. 

Ports relying on binary packages seem to die on make fake or make package.  I've personally noticed problems with compat4x, compat5x, and the linux emulation packages. 

At the moment, I wish Just Journal had a poll feature.  We started talking about packages to include in the first release.  There is a balance between packing too much cruft and not enough software that people need.  With our ports system, its possible for end users to install additional software.  At the same time, our target audience is not the typical CLI friendly BSD user.  Out of the box, we need a few basics working.  I'd rather not turn this into the typical bloated linux distro.  I also doubt my mirrors would be happy with me if I started shipping four disc installers.  One or two is the ideal target. 

ctriv has been planning the mport library that will be used by pkg_tool replacements and the GUI mport interface which will be developed by raven (nightlily on IRC). 

I've mostly been testing ports and playing around with sysinstall a bit.  I need to write a new installer, but for the first release we plan on using a modified sysinstall.

We are starting to make progress with the transition of ports.  Its very import that people mention broken ports.  We are testing everything, but hitting ports that people depend on first is always a good thing. 

Today, I fixed the windowmaker port. 

I'm going through X11-wm.  wmii, skippy-xd, ratpoison and pekwm are working.  (bottom up approach) 

The opera port is known to be broken right now.  lynx and links were updated yesterday and should be new versions that also work properly.

Opera has two problems.  First, qt33 is not installing.  If you already have qt, you'll find that the port is dying trying to package up its manpage.  Some ports that we know are broken have been added to bugzilla. 

Once we are done with this transition, all ports will correctly create packages.  This will be helpful to anyone running more than one system on the same architecture.  It will also simply building packages for us.

I recommend that no one use the CBL "anti spam but not for spammers" list.  It falsely accuses legitimate mail servers running on BSD of having windows trojans.  Clearly this is impossible.  They refuse to help or work with people they list. 

Further, if you do not get a reply from me make sure you or your ISP is not using that list. 

I hate spam as much as the next guy, but this is not the answer.  Worst of all, these people will not provide any evidence what so ever of the accusation.  There is no email with headers.  There is nothing they will give you. 

We are in the transition period to bsd.mport.mk.  That means many ports are currently broken.  Many X11 ports do not install properly at this time.  ctriv is working on this transition nearly everyday so progress is made. 

Critical issues at the moment:
GNUstep base doesn't work well.  This is clearly a big issue and we believe transitioning to the new gnustep-make 2.0 will fix this issue as it has destdir support. 

QT 3.3 is not installing just right.  This means KDE and friends aren't going to work. 

If you wish to use mbsd, i recommend you stick to the 0.1-special snap with its packages or grab some packages from the FTP server.  Those packages should run on newer mbsd versions, although this will also switch you over to the new ports system. 

This transition will be worth it.  I do not know how this transition will effect our release schedule.  It was critical we move forward with it, however.  I will work on the base system and installer during this transition.  Our security officer has been working on his new binary patch system.  Our remaining developers are working on different projects related to ports or documentation.

I've built a few amd64 packages.  You can find these on the ftp server under current. 

management/cracking:
kismet
aircrack
aircrack-ng

GNUstep related:
ruby-gnustep
gdl2 (think EOF for GNUstep)

Note: If you have any problems installing the gdl2 port, try installing postgresql81-client first.  There seems to be a subtle problem with detecting pq.4 as postgresql81-client is not fully installed when called from gdl2.. i'm looking at that.  The port itself should work fine.

To see a list of mports with descriptions on the web: http://www.midnightbsd.org/mports/README.html

A security hole was found in Clam Antivirus.  Versions prior to 0.90.2 are vulnerable.  Our port has been updated to address this issue.

I haven't been posting about new ports lately but there have been several. The most recent commit:

mports/security/secpwgen

Mostly, I've been trying to update ports as we've got many that were added last year and have not had any TLC. I do hope that is corrected soon.

This is a great time to join the project. We are nearing a release in June and have some exciting changes coming.