Valgrind 3.8.0 for FreeBSD

August 16th, 2012

Valgrind for FreeBSD was updated to version 3.8.0. Grab the tarball here, or clone the Mercurial repo from

hg clone
./configure && make && make install

The new version seems to be stable enough and passes most of the regression suite. There’re still some issues with several tests to look at however.


The Enlightenment E17 FreeBSD port has been updated to the recent snapshot today. Among bugfixes and new APIs, it also brings a lot of new libraries and modules that you will enjoy. Thanks a lot to Grzegorz Blach for preparing the original patch and for his hard work on bringing all the new e17 components to FreeBSD!

In case if you’re an active user of torrent networks like me you may discover one day you have a lot of music stored as APE-compressed AudioCD disk images. Although nothing bad, it is rather hard to manage a big music collection stored like this and navigate between tracks while listening this music. Recently I decided to convert the entire collection to the separate FLAC-compressed tracks, and here’s how you can achive the same.

  • Install audio/cuetools and audio/shntool packages (or whatever it called in your 3rd party software manager)
  • Install audio/flac package (you’ll need metaflac to tag resulted files)
  • Split the big APE file to separate FLAC-compressed tracks:

    cuebreakpoints my_favorite_music.cue  | \
        shnsplit -o flac my_favortite_music.ape
  • Add metadata information to FLAC tracks:

    /usr/local/share/examples/cuetools/ \
        my_favorite_music.cue *.flac
  • Rename resulted files (optional). I use the following script:

    set c=0
    foreach i (`echo *.flac`)
            set name=`metaflac --show-tag=TITLE $i | \
                sed -E -e 's,TITLE=,,' -e 's,[[:space:]]+,_,g'`
            set filename=`printf %.2d__%s ${c} ${name}`
            mv ${i} "${filename}".flac
            set c=`expr ${c} + 1`

After that you’ll receive a number of properly named flac tracks in the working dir. Enjoy!

HostObzor Autumn 2008

November 23rd, 2008

Recently I have been attending Hostobzor 12th, the Russian conference of hosting providers, beeing held at Raivola hotel near St. Petersburg. The event was great as always thanks to organizers. There was a number of intersting talks given, a lot of interesting discussions held, and, what I appreciate better, a lot of new people with great ideas met.

I gave a talk on using the FreeBSD Ports system to mange a large-scale virtual hosting installations based on Hosting Telesystems experience. I tried to describe in detail how we use the ports collection to deploy a large number of servers diverced by architecture and OS versions, how we build packages and distribute them among servers, talked about how we use Mercurial VCS to incrementally merge upstream changes into our modified ports collection and FreeBSD src trees. Hopefully, I’ve not screwed it much… At least, some people was interested a lot and asked interesting questions.

If you’re interested you can grab the talk draft and slides here (in russian): [paper] [slides].

Video should be available later from HostObzor website.

U-boot FFS/UFS support

October 31st, 2008

Yes, it’s there. Well, you might say I was supposed to do something useful instead like improving FreeBSD rather than fighting with this huge and unstructured piece of code… However, for some time u-boot will be here for FreeBSD too before we will be able to roll out a featue-comparable embedded bootloader.

So I spend a couple of days and implemented FFS support for u-boot. This means now you’re able to have a complete FreeBSD system booting directly from FFS-formatted media from u-boot. Both UFS1 and UFS2 should be supported, though I only tested UFS2 support. This listing shows at91’s uboot displaying the listing of FFS-formatted CompactFlash partiton:

ATAMAN-TB> ffsls ide 0:1 /
INODE   SIZE           NAME
2       512            ./
2       512            ../
3       512            .snap/
4       2322058        kernel
5       578            rc.conf

You can grab the patch here: FFS patch. This should apply clearly on u-boot 1.3.4 tree.

To build U-boot on FreeBSD you will also need the ompatibilty patch which could be downloaded here. After that you can use toolchains provided by devel/cross-gcc and devel/cross-binutils ports to build u-boot for the required platform.

Entrance port

September 21st, 2008

For a long time I have been asked whether I'm planning to port entrance to FreeBSD or not. Entrance is a graphic login manager similar to XDM but built around Enlightenment project E17 core libraries and with e17 look&feel. But this application has a lot of drawbacks too - the code isn't stable enough, so it's not a good idea probably to use it as login manager running as root.

After several recent inquries, I decided to create a port for this anyway, thus FreeBSD users will be able to preview and test this beatiful XDM replacement. If you're interested, you can download the port tarball here.

If you want for entrance to start automatically on startup either add an appropriate line to /etc/ttys, or define entranced_enable="YES" in /etc/rc.conf. You can also run entrance by hand by executing ${PREFIX}/sbin/entranced. By default, entranced on FreeBSD binds to first free tty (ttyv8), thus if you've tweaked your ttys configuration so ttyv8 isn't free anymore, change entrance config before trying to run it. You can use entrance_edit utility to tweak its configuration.

If you want to preview entrance in existing X11 session, run entrance -T. This will open a new X11 window with entrance running inside it.


PS: I have no plans currently to add this to the ports collection due to issued described above. Someone need to audit the code before it could be added to the official collection.

For a long time The FreeBSD project used CVS as its version control system almost exclusively. Recently a number of more sophisticated version control systems were developed, and it's becoming quite common that the developer uses something other than CVS for local development work. It was shown over years that using CVS for big long-term work on FreeBSD source code, especially when it should be constantly synced with the main FreeBSD repo, can become a major pain. That's why, in part, the FreeBSD projects provides access to a Perforce repo to work on FreeBSD related projects.

This tiny tutorial shows how one can configure and use Mercurial to do his local development work in FreeBSD repo, while staying in sync with the main development tree.

Checking out the source code

One of the most handy ways to obtain the FreeBSD source code is to use CVSup. This program uses sophisticated algorithms to efficiently transfer a large number of file over network. These also were specifically optimizes to use with CVS, so it tries to transfer deltas, not entire files, whenever possible.

You can find more information about CVSup in the FreeBSD Handbook.

For example, I use the following supfile to keep in sync with the FreeBSD repo.

*default base=/var/db/mercurial-cvsup/
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix

src-all tag=.           prefix=/work/src/mercurial/fbsd-src-HEAD
src-all tag=RELENG_7 prefix=/work/src/mercurial/fbsd-src-RELENG_7
src-all tag=RELENG_6 prefix=/work/src/mercurial/fbsd-src-RELENG_6
src-all tag=RELENG_5 prefix=/work/src/mercurial/fbsd-src-RELENG_5
src-all tag=RELENG_4 prefix=/work/src/mercurial/fbsd-src-RELENG_4

ports-all tag=. prefix=/work/src/mercurial/fbsd-ports

In this configuration all source files will be placed under /work/src/mercurial/. I use separate Mercurial repos for different FreeBSD branches, though you can probably use native Hg branches for this. I discovered that keeping different repositories works better for me as it's much lesser error probability and doesn't impact the speed much (if it does it at all).

Creating Mercurial repository

After obtaining the source you have to initialize Hg repository for the first time. It's very simple, luckily enough. Just enter into the each of repository folders, e.g. /work/src/mercurial/fbsd-src-HEAD from the above, and type the following commands:

% hg init # will create .hg folder and initialize its contents
% hg add  # will schedule all new files for the addition
% hg commit -m 'Initial import of the FreeBSD tree'

After that all downloaded source code will be managed by Mercurial. If you need to ignore some files, use .hgignore(5) file for this.

Keeping repositories in sync

Obviously, you want to be in sync with the main FreeBSD development tree. In fact, it's not harder than creating the repo.

To update your repository you need to perform the following steps:

  • Retrieve the fresh source code with the supfile you used in the previous step
  • Enter to the repository's directory and execute the following commands:

    % hg addremove        # will schedule new files to the
                          # addition and all nonexistent for
                          # removal
    % hg commit -m 'Update from upstream'

You can perform these steps from cron(8) to update your repos e.g. once a day. For example, I use the following script to do this:


set HG=/usr/local/bin/hg
set CSUP='/usr/bin/csup -L0'
set SUPFILE=/home/stas/mercurial-supfile
set BRANCHES=(fbsd-ports fbsd-src-RELENG_7 fbsd-src-RELENG_6 \
        fbsd-src-RELENG_5 fbsd-src-RELENG_4 fbsd-src-HEAD)
set REPOPATH=/work/src/mercurial


# Update sources via CVSUP


if ($status != 0) then
        echo "Error occurred during update"
        exit 1

# Add and commit changes into mercurial repo
foreach branch (${BRANCHES})
        cd ${REPOPATH}/${branch} && ${HG} addremove &&
            ${HG} ci -m 'Update from upstream'

Performing local development work on the repositories

This is what we have done all the previous steps for.

Mercurial is the true distributed VCS and encourages the use of separate repository for the every project you work on. In fact, the repository clone operation is very fast and cheap - Mercurial uses copy-on-write technology to avoid unnecessary copies.

For example if you're going to do some work on the Project1 for the FreeBSD HEAD you start by creating the corresponding repository:

% hg clone /path/to/repo/fbsd-src-HEAD fbsd-HEAD-project1

After that you can safely use fbsd-HEAD-project1 for all project1-related development work, commit changes, rollback them, view the history. Refer to the Hg documentation to learn more about Mercurial and it's abilities.

In case if you need to merge with the recent HEAD after some time, you can easily do that:

% cd /path/to/fbsd-HEAD-project1
% hg pull /path/to/repo/fbsd-src-HEAD
% hg merge

resolve conflicts, etc

% hg commit -m 'Merge upstream'

You can do that whenever you want without any consequences. Mercurial keeps the history of merges, so you won't receive suspicious conflicts. Furthermore, after the merge operation Hg will integrate all the history from the merged tree into your tree, so you'll be able to easily check the difference between your tree and the main tree. Suppose, for example, after some development you've received the following:

changeset:   310:d44952c166fd
tag:         tip
user:        Stanislav Sedov <>
date:        Wed Jan 09 18:57:24 2008 +0300
summary:     - Add new files.

changeset:   309:937d50c4af02
user:        Stanislav Sedov <>
date:        Fri Nov 30 19:02:37 2007 +0300
summary:     - Fix build.

changeset:   308:610151747720
user:        Stanislav Sedov <>
date:        Wed Nov 28 11:45:56 2007 +0300
summary:     - Fix build.

changeset:   307:023d52500562
user:        Stanislav Sedov <>
date:        Tue Nov 27 23:17:43 2007 +0300
summary:     - Add forgotten file.

changeset:   306:af6c5a6c4ff4
parent:      235:28745515f10e
parent:      304:4724d224afe3
user:        Stanislav Sedov <>
date:        Tue Nov 27 21:40:58 2007 +0300
summary:     - Branch merge.

changeset:   305:4724d224afe3
user:        Stanislav Sedov <>
date:        Tue Nov 27 02:53:22 2007 +0300
summary:     Update master tree

changeset:   304:4d9fc65e6661
user:        Stanislav Sedov <>
date:        Mon Nov 26 02:52:57 2007 +0300
summary:     Update master tree

Now you can get the diff between the main tree as on Tue Nov 27 and your last revision by using the following command:

% hg diff -r 305 -r tip


As of time writing the space consumed by my repositories distributed as follows:

  • 629M fbsd-ports
  • 659M fbsd-src-HEAD
  • 481M fbsd-src-RELENG_4
  • 568M fbsd-src-RELENG_5
  • 600M fbsd-src-RELENG_6
  • 657M fbsd-src-RELENG_7

Not so much for such a handy tool.

Additional info

For additional information about Mercurial refer to the included manual pages. The Distributed revision control with Mercurial book also is the great source of information about Hg.

Recently Intel released microcode update for their Core 2 Duo and Core 2 Extreme processors (E6000/E4000 and Q6600/QX6700 series accordingly). This update fix a bug in TLB processing, which can cause incorrect records invalidation. That may result in upredictable system behavour/hangs/reboots/etc.

For FreeBSD you can use devcpu port to update your microcode. It already includes these critical updates, thus will protect you from possible failures linked with the bug. Just install it as usual and add 'devcpu_enable="YES"' in the rc.conf file. Processor microcode will be updated on the next restart (or you can issue /usr/local/etc/rc.d/devcpu start by hand).

First mentee

April 24th, 2007

Today I have received an approve from portmgr@ to allow Marcelo Araujo to join the developers community as a ports committer. He've done a great work of submitting new ports and fixes, so it's the time to reward him.

I'll drive his first steps as ports committer and will be responsible for his possible errors (and receive pointy hats for that:-)).

Please, wish him a luck!

e17 ports were updated

March 17th, 2007

As you may noticed, the enlightenment-devel port as well as other e17 ports were updated to the latest snapshot. Well, there's was enough time from the previous update, many things has changed and stability was generaly improved.

If you have problems building enlightenment from ports, try rebuilding x11/ecore with DBUS support enabled, enlightenment rely on this ecore feature in the builtin file manager. Don't worry, it doesn't depend on dbus library and adds a very few code (via loadable shared library).

Also, the startup command of enlightenment was renamed to enlightenment_start, so don't forget to update your .xinitrc

BTW, oleczek submitted a port for new e17 module elucence, and I have finished it. This module uses xcompmgr to manage windows opacities in a beautiful way. However, it can be slow as an evil on some video adapters, and doesn't behave well with current e17 version (e.g. it has no module icon). If you interested, download it here.

devcpu port was updated

February 2nd, 2007

Today I've updated the devcpu port. One of the major things that was changed is the utility to deal with Award bios update images was added. This program allows to extract microcode updates from vendor bios updates (this especially important for AMD cpus as this company doesn't distribute cpucodes updates for end-users). Furthermore, you can take bios updates for the newer hardware and extract microcode updates from them in case if your system unsuppored by vendor anymore. A have a lot of such hardware.

Another thing, that was added is the rcNG startup script. It allows to enable automatic cpucode updates on startup. Just add ths string devcpu_enable="YES" in your /etc/rc.conf file and cpus will be updated on each boot.

I wish to think pav@ and netchild@ for their suggestions and reports.