I finally took the time to search for a solution. I post it here for two reasons: a) I might need this information at some point in the future and am more likely to find it that way and b) I might not be the only one here which faced this situation.

I finally took the time to search for a solution. I post it here for two reasons: a) I might need this information at some point in the future and am more likely to find it that way and b) I might not be the only one here which faced this situation.

The first step was to modify my Xorg configuration to be a bit more verbose about the process of choosing a screen resolution when X starts to see if something was different with both drivers. This can be achieved by editing the Monitor section:

Section "Monitor"
    ...
    Option "ModeDebug" "TRUE"
EndSection

More recently (October 1st, 2012), I made major changes in the freebsd-texlive project to fix the long-standing problem of TeXLive shipping distfiles with no version in the filename and replacing them in place. After setting up a new mirror with renamed distfiles (sponsored by NFrance, a French hosting company using the FreeBSD operating system. Many thanks to them for providing hosting and bandwidth!), updating the program that creates and updates ports, updating the updating tools, switching to the new mirror and updating all ~2250 ports; all the caveats around this choice from the maintainers of the TeXLive distribution should be gone!

This change will however not be without consequences for users. Distfiles version numbers where created by using the date at which a file appeared or where updated on the upstream mirrors, but because of the mirroring delays, the file mtime could be earlier by more than one day. As a consequence, a file updated on 17th May, 2012 could have version number 20120518 (getting the real package version number in the distfile is a PITA). Because having the version in the distfile filename require consistent dates, the new ports use the date from the upstream distfile mtime, and many ports had their version going backwards… PORTEPOCH have so been bumped, and port management tools will want to update all these ports which are in fact unchanged.

It's the first time such a bad situation happen in the freebsd-texlive repository. I hope this will be the last and apologies to users who will be worried with this massive update.

Happy TeXing!

1. it was on some topics I had interests in but had not as much time as I would have liked to to dig in;
2. it was focussed on my main operating system.

I bought the book and although it was rather small (~140 pages) enjoyed learning quite a large amount of things about the FreeBSD kernel.

So, when I was contacted by No Stash Press to know if I would be interested in a review copy of their upcoming book FreeBSD Device Drivers by the same author in exchange of writing what I though about it, I had no hesitation and accepted the deal.

On the next day, I eventually realised that an hard disk was logically missing on the system and the ZFS mirror it was belonging to was working in a degraded mode. This disk holding a swap partition, the panic quite makes sense: some data was stored there and could not be paged-out anymore.

# zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
data   294G  68,2G   226G    23%  1.25x  DEGRADED  -
tank  1,81T   300G  1,52T    16%  1.06x  ONLINE  -

# zpool status data
  pool: data
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
  scan: none requested
config:

NAME                                            STATE     READ WRITE CKSUM
data                                            DEGRADED     0     0     0
  mirror-0                                      DEGRADED     0     0     0
    gptid/36711e52-a69e-11de-8adf-0018f38af467  ONLINE       0     0     0
    15152536002702365387                        UNAVAIL      0     0     0  was /dev/gptid/602da1ae-c474-11de-960d-0008a14dbca1

errors: No known data errors

Location of Feature Keys on the ST2030.

I finally decided to configure these keys with proper numbers instead of browsing my directory each time I want to make a call. But the phone only ships with a single paper sheet to hand-write the names corresponding to the configured numbers and my hand-writing is somewhat like what would produce a drunk cow with Creutzfeldt–Jakob disease. I browsed the Internet for a sheet template to fill-in, print and cut, but was unable to find some.

The show is called Les aventures du comte de Malamanteau (French for Earl Malamanteau's Adventures), and is mostly music centered: during one hour, a selection of music from a given country (a different one for each issue) is aired. So far, we have visited South Africa, Kenya, Tunisia, Lebanon, Ukraine and Finland.

A website has been setup for listeners to have access to broadcasted shows and gathering more information about the music we chose and location we visited: malamanteau.fr.

In order to help users who don't want to install the whole TeXLive collection (~2000 ports), a basic script has been developed to ease-up finding which port provides some file required by a given package.

As usual, feedback is welcomed!

The first line of the script was:

#!/bin/bash -x

Those who know me might imagine how my eyes were bleeding (the other may want to read my previous entry about writing portable shebang for shell scripts), but this shows another problem one may encounter when porting a shell script with an invalid shebang.

I did some basic testing locally, but I don't read Korean, thus I could not test beyond the (minimalistic) examples. I am therefore looking for FreeBSD TeXLive users who are able to write Korean to help testing this package. If you are one of them, please give it a try and report any success or failures on the issue page.

One month ago, I pushed TeXLive 2010 to the freebsd-texlive repository. Moreover, because portshaker is now in the FreeBSD ports tree, installing bleeding-edge TeXLive on FreeBSD has never been so easy!