Content

Porting

Apr
12

Posted on April 12th, 2010 at 12:14 pm TeXLive 2009 on FreeBSD

I recently updated the freebsd-texlive project to make TeXLive 2009 (the latest verison) available as ports for FreeBSD.

I used a script for update TeXLive 2008 on a regular basis, but since these new ports feature pkg-plist files, I had to setup an update jail. So updates for FreeBSD TeXLive ports will be generated daily at 5:30 CET.

I am also thinking about pushing the portshaker(8) utility in the FreeBSD ports tree in order to make it easier to track this project along with others (e.g. BSD#).

Feedback is welcomed!

Feb
16

Posted on February 16th, 2010 at 5:57 pm The state of Mono 2.6 on FreeBSD

Long time no post... Well, I an writing a serie of articles about NFC and it takes me a lot of time, not mentioning I still do many other things in parallel. If you are interested in this area, stay tuned ;-)

So apart NFC, what's new with Mono on FreeBSD? First, you wight have seen that mono 2.6 has been released for a while and is still not available in FreeBSD ports. The main reasons are:

Dec
23

Posted on December 23rd, 2009 at 4:29 am Unbreaking Mono on FreeBSD 6.4

A few days ago ports/140916: lang/mono (2.4.2.3) installation fails was opened. The reported problem had already been reported a few time but with insufficient feedback so far and I was not able to diagnose the problem, not mentioning providing a fix. But this time, the reporter could spot that the problem was happening for him only with FreeBSD-6.4. I did the test on a fresh FreeBSD-6.4 install and could trigger the error:

arthur# portsnap fetch
[...]
arthur# portsnap extract
[...]
arthur# cd /usr/ports/lang/mono
arthur# make -V PKGNAME
mono-2.4.2.3_1
arthur# make
[...]
if test -w ../mcs; then :; else chmod -R +w ../mcs; fi
cd ../mcs && gmake NO_DIR_CHECK=1 PROFILES='net_1_1 net_2_0 net_3_5 net_2_1' CC='cc' all-profiles
gmake[3]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake profile-do--net_1_1--all profile-do--net_2_0--all profile-do--net_3_5--all profile-do--net_2_1--all
gmake[4]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake PROFILE=basic all
gmake[5]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[6]: *** [build/deps/basic-profile-check.exe] Error 1
gmake[6]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
*** The compiler 'false' doesn't appear to be usable.
*** Trying the 'monolite' directory.
gmake[7]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[8]: *** [build/deps/basic-profile-check.exe] Error 138
gmake[8]: Entering directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
*** The contents of your 'monolite' directory may be out-of-date
*** You may want to try 'make get-monolite-latest'
gmake[8]: *** [do-profile-check-monolite] Error 1
gmake[8]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[7]: *** [do-profile-check] Error 2
gmake[7]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[6]: *** [do-profile-check-monolite] Error 2
gmake[6]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[5]: *** [do-profile-check] Error 2
gmake[5]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[4]: *** [profile-do--basic--all] Error 2
gmake[4]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[3]: *** [profiles-do--all] Error 2
gmake[3]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/mcs'
gmake[2]: *** [all-local] Error 2
gmake[2]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3/runtime'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/lang/mono/work/mono-2.4.2.3'
gmake: *** [all] Error 2
*** Error code 1

Stop in /usr/ports/lang/mono.
*** Error code 1

Stop in /usr/ports/lang/mono.
Nov
14

Posted on November 14th, 2009 at 1:09 am Introducing ZFS support in portshaker(8)

portshaker(8) is a tool designed for merging partial ports trees into the FreeBSD ports tree. In other words, it implements some kind of overlay for the FreeBSD ports.

When merging port trees, portshaker(8) first clones the upstream FreeBSD ports tree to the target location. For this purpose, portshaker(8) used to rely on rsync(1) because the target ports tree was supposed to be quite near to the source ports tree. With an UFS file-system, it took my computer circa 10 minutes to merge the 390 Mib of files.

I recently switched to full ZFS, and this gave the clone process a boost: less than four minutes where required to perform the clone action for the first time, and thanks to caching, a single minute was enought to clone a second time.

But ZFS provides cloning capabilities, thus, I added support for the ZFS file-system into portshaker(8). Enabling this feature is as simple as adding the following to /usr/local/etc/portshaker.conf:

use_zfs="yes"

There is however a prerequisite for this to work: the target ports tree's parent directory and the source directory have to be ZFS filesystems. For example, on my computer, the FreeBSD upstream ports are stored in /var/cache/portshaker/freebsd and I merge my ports to the usual /usr/ports directory. All these directories are ZFS filesystems:

romain@marvin ~ % zfs list /usr/ports /var/cache/portshaker /var/cache/portshaker/freebsd
NAME                                USED  AVAIL  REFER  MOUNTPOINT
data/usr/ports                     57,1M  80,9G   402M  /usr/ports
data/var/cache/portshaker           514M  80,9G  48,6M  /var/cache/portshaker
data/var/cache/portshaker/freebsd   427M  80,9G   390M  /var/cache/portshaker/freebsd

When merging, portshaker(8) snapshots the FreeBSD ports and clone them to the target ports tree. This requires only a few seconds to achieve.

May
6

Posted on May 6th, 2009 at 4:08 pm TeXLive for FreeBSD updated

TeXLive tarballs are updated every once a while and uploaded in place of the old ones wihout any versionning information. A direct consequence is that the FreeBSD ports for TeXLive are not fetchable anymore.

Since I announced I was not willing to track TeXLive updates, I almost forgot about this problem until a bug was oppened in the Google code repository of the project.

I promptly fixed the issue and created a shell script that should do this automatically each night thank's to cron(5):

#!/bin/sh

svn_root="https://freebsd-texlive.googlecode.com/svn"
date=`date +%Y%m%d`

cd /usr/ports/distfiles/TeXLive/2008 && \
   /usr/local/bin/wget \
     --quiet --mirror --no-directories \
     ftp://ftp.inria.fr/pub/TeX/CTAN/systems/texlive/tlnet/2008/archive/
if [ $? -ne 0 ]; then
   echo "Fetch error" >&2
   exit 1
fi
cd /usr/home/romain/Projects/freebsd-texlive-releng && \
   Tools/resum print/*
if [ $? -ne 0 ]; then
   echo "Sync error" >&2
   exit 1
fi

if [ -n "`/usr/local/bin/svn diff`" ]; then
   /usr/local/bin/svn commit -m "Sync distinfos" &&
   /usr/local/bin/svn copy "${svn_root}/branches/releng" \
                          "${svn_root}/tags/freebsd-texlive-${date}" \
                          -m "TAG freebsd-texlive-${date}"
fi

This problem should not occur anymore now :-).

Apr
18

Posted on April 18th, 2009 at 12:53 pm Enlève tes doigts d'ici gamin!

Gamin has been recently patched on FreeBSD. This may change dramaticaly the way you use USB sticks, so here is a quick tutorial (for those who don't speak french, the title says put your fingers away kid).

What you used to do

  1. plug your USB device in. The device automagically appears on the desktop and by default a file manager window shows its contents;
  2. copy your files;
  3. left-click the device and select Unmount Volume;
  4. click Ok when a message dialog tells you that the volume cannot be unmounted :-s;
  5. Choose one:
    • If you are a violent person,
      1. open a terminal;
      2. run killall -9 gam_server && umount /media/KINGSTON
      3. unplug your USB device.
    • If you are not a violent person,
      1. save your work;
      2. close your session;
      3. log-in into a console;
      4. run gnome-unmount --pseudonym KINGSTON
      5. unplug your USB device;
      6. log-out from the console and log-in to X.

The new way of doing it

  1. plug your USB device in. The device automagically appears on the desktop and by default a file manager window shows its contents;
  2. copy your files;
  3. left-click the device and select Unmount Volume;
  4. unplug your USB device :-D.

I'm not sure that FreeBSD is the platform of choice for beginners, but this problem was really irritating. Having it fixed may help people discovering FreeBSD not running away screaming I guess.

Dec
23

Posted on December 23rd, 2008 at 1:24 pm TeXLive architecture dependent files

I am having fun with TeXLive under FreeBSD, and while trying to understand what is utterly needed in the 5229 packages provided by the distribution, I discovered a funny thing:

$ ls texlive.infra.*.tar.lzma
texlive.infra.alpha-linux.tar.lzma       texlive.infra.mips-irix.tar.lzma
texlive.infra.amd64-freebsd.tar.lzma     texlive.infra.powerpc-aix.tar.lzma
texlive.infra.doc.tar.lzma               texlive.infra.powerpc-linux.tar.lzma
texlive.infra.hppa-hpux.tar.lzma         texlive.infra.sparc-linux.tar.lzma
texlive.infra.i386-freebsd.tar.lzma      texlive.infra.sparc-solaris.tar.lzma
texlive.infra.i386-linux.tar.lzma        texlive.infra.universal-darwin.tar.lzma
texlive.infra.i386-openbsd.tar.lzma      texlive.infra.win32.tar.lzma
texlive.infra.i386-solaris.tar.lzma      texlive.infra.x86_64-linux.tar.lzma

All these distfiles (excepted the one emphasized) contains the same program compiled for different architectures. As the name suggest, it is related to the infrastructure of TeXLive, that is the piece of code handling the brunch of .tar.lzma distfiles.
Let's see what is packaged in one of these files:

$ lzma -dkc texlive.infra.i386-freebsd.tar.lzma | tar tf -
tlpkg/installer/lzma/lzma.i386-freebsd
tlpkg/installer/lzma/lzmadec.i386-freebsd
tlpkg/tlpobj/texlive.infra.i386-freebsd.tlpobj

Cool! This package includes FreeBSD binaries for decompressing .lzma archives, (e.g. this package)! Hopefully we already have archivers/lzmautils for doing that.

Oct
11

Posted on October 11th, 2008 at 9:56 am Writting consistent tests

I recently encountered a somewhat funny problem when porting Labyrinth to FreeBSD, python complaining about some locale.bindtextdomain that does not exist.

Having a look at the source code, I could read:

if hasattr(gettext, 'bind_textdomain_codeset'):
       gettext.bind_textdomain_codeset('labyrinth','UTF-8')
gettext.textdomain('labyrinth')
if not os.name == 'nt':
       locale.bindtextdomain('labyrinth', localedir)
       if hasattr(locale, 'bind_textdomain_codeset'):
               locale.bind_textdomain_codeset('labyrinth','UTF-8')
       locale.textdomain('labyrinth')

gtk.glade.bindtextdomain('labyrinth')
gtk.glade.textdomain('labyrinth')
Aug
2

Posted on August 2nd, 2008 at 11:15 am BSD#: Mono on FreeBSD

A few weeks ago, I joined the BSD# project which aim to maintain Mono (an open source implementation of the Microsoft .NET framework) on FreeBSD. It was the occasion for giving svk a try.