MidnightBSD Developer Journal

I've updated the rsync port to 3.0.3 and fixed the Firefox port  The linux-thunderbird port was updated for a security issue last night.  

We're still having some problems with graphviz building on some systems and magus.  It works on both of my local systems.  graphviz is a show stopper for the 0.2 release at this point.  We need that port to build on magus before I can do the release.  The point of this release is to get users a security fixed version with recent packages.  0.3 is a feature/technology release.

 I've setup an anonymous cvs mirror (pserver) for MidnightBSD.  This is rsync'd every two hours from stargazer.  It won't help with bandwidth as it's still on the same network, but the system is much faster (sata, pentium d 805, ...) 

For instance, to checkout mports:

cvs -d :pserver:anonymous@ds9.midnightbsd.org:/home/cvs co mports

Foxconn is delibertly forcing users to run windows on their motherboards. Avoid their motherboards.

http://www.pcworld.com/businesscenter/article/148854/attack_code_released_for_new_dns_attack.html 

 The security issue affecting some operating systems with X11 forwarding is not an issue on MidnightBSD.

http://www.openssh.com/txt/release-5.1

I began the day planning to create a snap in preperation for our new release.  I ended up modifying the script used to separate packages for release isos, and looking at what packages are missing that we might want to include.

One problem I had not anticipated was the position we're in selecting a default desktop environment.  I had been planning on using Etoile + GNUstep.  That may still come to pass, but Etoile is not ready for this release.  The next logical choice is Gnome.  It is not used extensively in the BSD community as PC-BSD and DesktopBSD both use KDE.  I'm indifferent as I alternate between KDE, Gnome and other environments on my systems periodically.  I like to try out new verisons, and I'm fond of applications from several environments.  I started this project hoping to offer something unqiue, and I want to suceed at that.  If we role with Gnome, it would be new in the BSD world, but nothing special among the countless Linux distros and Solaris.  Many people do love Ubuntu and that ships with Gnome.  Another problem with Gnome is that it depends on Firefox.  We can't ship a Firefox binary do to usage restrictions for new ports.  The webkit work with the project might save us on this issue down the road. 

Presuming a native Firefox or Seamonkey is built, it's possible to get a fully working Gnome environment on MidnightBSD.  KDE 3.5.8 is also working, but we don't have a QT4 port available to work on KDE 4.1.  As for GNUstep and Etoile, I think we need some people porting and upstreaming patches for those projects to proceed on those fronts.  I also have an interest in improving the underlying operating system.  I have a few radical ideas that I'd like time to explore.

MidnightBSD 0.2 will ship with KDE-lite or KDE3 ports as a necesity.  I also plan to include the GNUstep ports if they're working at the time of release.  Until the browser matter is settled, I can't do much with Gnome. 

I'd appreciate feedback via comments on this blog, email, mailing list communication or chat in iRC about the direction you think the project should go. 

Regardless of the choices, we need to accomplish the following tasks.

1. Finish the new installer and package tools

2. Select a desktop environment, port it completely without any "freebsd hacks" and upstream the patches. 

3. Work on integration of the environment with the OS, and usability.

Then there's the matter of making the kernel changes I'd like to see as well as bringing in new hardware support.

Recently, I added pcc to midnightbsd. While testing mksh, the maintainer noticed that some symbols were missing. Linking libgcc with pcc worked as did libpcc (Mirports version).

Any programs compiled with pcc should link libpcc with them.

Most DNS software packages have a common design problem, they don't use random source ports. There is a great deal of coverage on this issue at isc.org as well as a CVE, etc.

I've committed a patch to MidnightBSD CURRENT tonight. Until I test it seriously, I'm not going to put it on stable branches. I've also updates all three bind ports with the latest patch level.

These patches are known to slow down bind. I don't think most midnightbsd users run DNS servers, so it shouldn't be a big issue. Any ISP or larger DNS deployment should update their servers though.

My patch does not include all the documentation updates.

I saw this article linked on the FreeBSD website today. It might be helpful for beginner kernel hackers.

http://www.freesoftwaremagazine.com/articles/writing_a_kernel_module_for_freebsd

Tonight, I updated the chroot tarball used by 0.2 magus nodes. This will allow us to test and build ports with a very similar environment to a 0.2-RELEASE machine.

I'm hoping to get this release done by the middle of the month, but we'll have to see what happens with mports.

I updated some of the t-shirts on the MidnightBSD store with our newer logo. I also created two other shirts. "I Love BSD" and "Hello World" are geeky shirts without the MidnightBSD branding.

I have not purchased any of these shirts yet, so I don't know how well they come out. I used at least 900pt x 900pt size with each image.

http://www.cafepress.com/midnightbsd

I've been working on hardware support. Several users have been having problems running MidnightBSD on newer hardware.

src/sys/dev/ata

Last night, I merged some things from FreeBSD to support newer ATA and SATA controllers form NVIDIA, Intel, and AMD into CURRENT. I also added a few to 0.2 that I can test here. We've got a few devices that FreeBSD does not support as well.

src/sys/dev/msk

I added an experimental msk(4) to 0.2 and CURRENT. It is built as a module only at this time. I'm also experimenting with a device on my iMac Core 2 Duo and msk(4). To test this, kldload if_msk

src/bin/sh

sh changes are now available on 0.2 and CURRENT which fix some GNU configure scripts like those found in recent versions of graphviz.

src/bin/*

I've brought in several changes from FreeBSD 6.3 to CURRENT. Several commands have updated man pages, new flags, and bug fixes. bin/cp needs the most testing.

We're getting the mports tree ready for 0.2-RELEASE. On the last magus run, we had 28 failures and 30 untested ports.

http://www.midnightbsd.org/magus/runs/83

These results are promising. Due to the nature of this release, we need a larger number of packages built.

The idea goal would be to get KDE, Gnome, and GNUstep related ports in shape for the release. We'd like to have packages for all three environments. Most people tell me they would like us to focus on either GNUstep or Gnome. KDE comes into play because it was easier to get working, and at this point we're depending on Firefox for Gnome which we can't ship in package form. (ported versions of firefox can't use the name or artwork unless approved by Mozilla Corporation) I'm going to try to get some unbranded variant of a mozilla browser available for package building if possible. It takes a long time to get a port working due to build times and complexity. Firefox 3 is out of the question right now. It requires new versions of many ports that would be disruptive this close to a release.

I'd like some feedback from users about their preferred environment. When I started this project, I wanted to focus on GNUstep. I'd like to know that's what people want. If so, we need to overhaul the GNUstep ports and get some patches upstreamed. I personally feel that KDE is well covered by PC-BSD and DesktopBSD folks.

If we get more port maintainers, it might be possible to keep all of them and allow choice during install and/or different ISOs.

After the release, ctriv@ is going to do some disruptive changes to the structure in mports/Mk

I've just migrated about half the nodes to 0.2-PRERELEASE. I've also started a new build run on that release. The remaining nodes will move to CURRENT (0.3) soon.

I've copied some packages from magus (run 80) to stargazer.  We still have some symlink problems with a few files, but there are a great number of packages available.  (2.3GB)  A few were not included for distribution issues.  For instance, the gnome ports will work, but you'll have to manually provide firefox.  Not all the gnome ports built anyway on that run.  We're still fixing a few issues with them. 

it's still the largest distribution of packages we've provided to date.  ( ~  1890)

I pruned these using the ports marked restricted.  It's possible not all the ports were caught.  Please let me know if you see anything that shouldn't be there.  These packges will work on 0.2 branch systems too.

I started working on a linux-firefox3 port, but ran into several problems.  First, it uses TLD which means we can't use it on amd64.  Second, it requires libpangocairo, which I updated/added.  now there is a linux-cairo port too.  Finally, it requires GTK 2.10.  I can't work around this one without upgrading our linuxolator. 

This is a big problem for us.  Not only can we not ship a native firefox at this time, but when mozilla drops firefox 2 support, we'll be without an updated linux browser. 

Some of our developers are taking time off for the summer. At least two of them will be on vacation within the next few weeks. I'm currently taking a summer class which ends at the end of the month. At that time, I plan to pick up on work. (laffer1@)

mports commits might get slower during the next few weeks as I start working on src. We do plan to get gnome ports fixed up.

There has also been a change in plans for 0.2 and 0.3. We plan to release 0.2 sooner than planned. MidnightBSD 0.1.1 comes with many outdated packages. Most of our users are installing from CD and not updating mports. We feel that it is necessary to release something in the next two months with updated package and security updates. So 0.3 will be the feature release that 0.2 was supposed to be.

Prior to the release, we want to stabalize mports and fix one outstanding bug in src. There will also be some installer changes.

Opera software recently released Opera 9.50. Normally, we'd like to include new versions of browsers anyway. However, this version also includes several security fixes. The mports/www/opera port has been updated to 9.50, but it may be tweaked as we move forward. The structure of the port changed quite a bit. We're not doing any config file changes yet. Paths for plugins might be incorrect, etc.

We were not able to update the linux-opera port. That was marked broken as the new versions require qt4 or are debian packages we don't have support for right now. If you don't care about the security risks, just comment out the BROKEN= with a # in the Makefile for the port.

I made some progress on open office 2.4 and kaffe today.  The former installs freedestkop style entries for gnome/kde menus, but does not execute quite right yet.  I suggest you use soffice with this port.  (linux-openoffice24) 

kaffe seems to work fine, although registervm does not properly set the path to the jdk with the javavmwrapper yet.  There's a file /usr/local/etc/javavms (as i recall) that has the invalid path to the ports directory.  Fix that after installation and it should work as expected.  This and linux-blackdown 14 are installable without a lot of fuss. (if you need java in a hurry) 

java/netbeans was updated to 6.1 tonight.  It works aside from a nag message about a missing solaris file.  The old version had fetching problems, so we went with the latest despite this bug. 

Either myself or one of the other port maintainers can tackle these at a later date.

ctriv and I met today to discuss current and future work with midnightbsd.  We've got an idea what our next steps are going to be.  I'll probably post more about my work soon. 

The gnome 2.22 fallout is still at play with mports.  This was compounded by perl bug that should be fixed.  It was not the perl port, but rather some code that sets the default version of perl within mports.  The next magus run should be more productive as we've isolated a few gnome issues and this perl fix should restore the mports collection.

Finally, stevan@ reported a bug in csup awhile back.  I finally got time to test it in a similar environment.  It is recommended that users use cvsup or cvs to checkout mports and src instead of csup at this time.