Follow the White Rabbit

I went to the doctor today and after they took a scan of my body, the lab assistant just gave me a card with "Follow the Nurse"* written on it.

Was it a slightly modified version of following the White Rabbit? Nobody asked me to eat any pills, have I failed somewhere?

* (taking into account the context, 'Go to the Nurse' would be a better translation, but that wouldn't fit as nicely to the Matrix theory)

Advanced Patch Management

Nowadays not only have the patches be fully functional, fixing the breakage; the users require them to be a piece of art and fun.
Here's one of my recent creations:

Kooky returns

The guy behind Samorost, Samorost 2 and Machinarium is making a movie and it looks really great. Check it out!

I found a service that allows to add subtitles to YouTube videos and added English subs for the Teaser and Trailer. Enjoy!

pkgbuild and publishing via the file protocol

pkgbuild is the tool the kde-solaris project uses for building its packages. After a package is built and properly generated, it needs to be published to an IPS repository.
Here's an example of the publishing script generated by pkgbuild:

#/usr/bin/bash
export PKG_REPO=${PKGBUILD_IPS_SERVER:-http://localhost:10000/}
eval `pkgsend open soprano@2.3.70,5.11-3` || exit 1
pkgsend include /export/home/test/packages/PKGMAPS/manifests/FOSSsoprano.manifest || exit 2
pkgsend close || exit 3

Due to an old bug, publishing packages with files bigger than ~100MB fails. This is the case of the Qt src package and also some Qt libraries when compiled with debug information. In such cases one has to resort to publishing the packages via the file protocol.
 But ... while publishing via http does not require any extra privileges, for the file protocol one has to have write permissions to the ips repository. Not really keen on using pfexec all the time, I first made sure the pkg server on the build machine is running under the same user who runs the build.

Then I patched pkgbuild so that if the environment variable PKG_REPO is set, it's value will be used for publishing.

As a result I can just do

export PKG_REPO=file:///export/home/test/repo
make KDEgdm-integration

Not only are we able to painlessly publish packages with big files now, there's also a noticeable speedup. The full KDE4 build (72 packages, ~10 hours on a 16 core machine) is 30-50 minutes faster since when the change was implemented.

Running pkg server as regular user

I wanted to run the pkg server a regular user, to be able to publish into the repository via the file protocol without giving the user any extra privileges. It turned to be quite easy to achieve:

Export the current configuration to a file:

svccfg export pkg/server > pkg.xml 

Modify the file so that it looks like the below example. I added the <method_context> and modified the inst_root property. Also the port has to be > 1024 to be usable by ordinary user.

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle type='manifest' name='export'>
  <service name='application/pkg/server' type='service' version='0'>
    <create_default_instance enabled='true'/>
    <dependency name='fs' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/local'/>
    </dependency>
    <dependency name='autofs' grouping='optional_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/autofs'/>
    </dependency>
    <dependency name='ntp' grouping='optional_all' restart_on='none' type='service'>
      <service_fmri value='svc:/network/ntp'/>
    </dependency>
    <dependency name='network' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/milestone/network'/>
    </dependency>
    <exec_method name='start' type='method' exec='%{pkg/pkg_root}/lib/svc/method/svc-pkg-depot %m' timeout_seconds='0'>
    <method_context>
        <method_credential
        user='test'
        group='staff' />
    </method_context>
    </exec_method>
    <exec_method name='stop' type='method' exec='%{pkg/pkg_root}/lib/svc/method/svc-pkg-depot %m %{restarter/contract}' timeout_seconds='30'/>
    <property_group name='pkg' type='application'>
      <propval name='cfg_file' type='astring' value=''/>
      <propval name='content_root' type='astring' value='usr/share/lib/pkg'/>
      <propval name='debug' type='astring' value=''/>
      <propval name='log_access' type='astring' value='none'/>
      <propval name='log_errors' type='astring' value='stderr'/>
      <propval name='mirror' type='boolean' value='false'/>
      <propval name='pkg_root' type='astring' value='/'/>
      <propval name='proxy_base' type='astring' value=''/>
      <propval name='readonly' type='boolean' value='false'/>
      <propval name='socket_timeout' type='count' value='60'/>
      <propval name='sort_file_max_size' type='astring' value=''/>
      <propval name='ssl_cert_file' type='astring' value='none'/>
      <propval name='ssl_dialog' type='astring' value='smf'/>
      <propval name='ssl_key_file' type='astring' value='none'/>
      <propval name='threads' type='count' value='10'/>
      <propval name='writable_root' type='astring' value=''/>
      <propval name='port' type='count' value='10000'/>
      <propval name='inst_root' type='astring' value='/export/home/test/repo'/>
    </property_group>
    <property_group name='pkg_secure' type='application'>
      <property name='read_authorization' type='astring'/>
      <property name='ssl_key_passphrase' type='astring'/>
    </property_group>
    <property_group name='startd' type='framework'>
      <propval name='duration' type='astring' value='child'/>
    </property_group>
    <stability value='Unstable'/>
    <template>
      <common_name>
        <loctext xml:lang='C'>image packaging repository</loctext>
      </common_name>
    </template>
  </service>
</service_bundle>

And import the settings back:

svccfg import pkg.xml

Do not forget to make the service log file writable for the user, otherwise the pkg server will not start:

pfexec chown test /var/svc/log/application-pkg-server:default.log

Refreshing the file list in kde-solaris

Often when we upgrade a package or change something in the build process (e.g. recently we started putting the debug information into separate files), the build fails because either some files are missing or new files appear or both.
In the log something like this is found:


pkgbuild: ## Validating control scripts.
pkgbuild: ## Packaging complete.
pkgbuild: error: Installed (but unpackaged) file(s) found:
pkgbuild:         /opt/foss/bin/amd64/imginfo.debug
pkgbuild:         /opt/foss/bin/amd64/tmrdemo.debug
pkgbuild:         /opt/foss/bin/amd64/imgcmp.debug
pkgbuild:         /opt/foss/bin/amd64/jasper.debug
pkgbuild:         /opt/foss/bin/jasper.debug
pkgbuild:         /opt/foss/bin/tmrdemo.debug
pkgbuild:         /opt/foss/bin/imgcmp.debug
pkgbuild:         /opt/foss/bin/imginfo.debug
pkgbuild:         /opt/foss/lib/libjasper.so.1.0.0.debug
pkgbuild:         /opt/foss/lib/amd64/libjasper.so.1.0.0.debug
pkgbuild: pkgbuild: FOSSjasper.spec(118): Installed (but unpackaged) file(s) found
--- command output ends --- finished at Wed Mar 17 03:44:06 CET 2010


Fixing the file list manually can lead to errors and is time-consuming, so it's easier to use the scripts available in the repository:
First, the file names are extracted from the log:

perl tools/extract-plist.pl < ~/logs/FOSSxz.log |sort -u> a

And then a new plist is constructed:

perl tools/extract-plist-2.pl <  a 

Of course you can join them into a oneliner:

perl tools/extract-plist.pl < ~/logs/FOSSxz.log |sort -u|perl tools/extract-plist-2.pl

Copying a zone

I wanted to play a bit with the KDE4 build flags and I needed a playground. The idea I had was to use a copy of the existing KDE build zone, so as to save time configuring it and downloading all the dependencies.

Well, I have to admit I sort of failed in this one ...

zoneadm clone wasn't really an option as I need to have freedom creating and destroying snapshots on both zones. zoneadm clone -m copy probably never worked.
I spent a lot of time with zfs send|zfs receive, esp. with the idea of

# /usr/sbin/zfs snapshot -r tank/zones/build@1move
# /usr/sbin/zfs send tank/zones/build/ROOT/zbe@1move > build.backup
# zfs create tank/zones/debugbuild
# zonecfg -z debugbuild
zonecfg:debugbuild> export
create -b                                                               
set zonepath=/tank/zones/debugbuild                                
set brand=ipkg                                                          
set autoboot=true                                                       
set ip-type=shared                                                      
add fs                                                                  
set dir=/home                                                           
set special=/export/home                                                
set type=lofs                                                           
end                                                                     
add net                                                                 
set address=10.10.2.44                                                  
set physical=e1000g0                                                    
end

# cat build.backup|zoneadm -z debugbuild attach  -r zfs

but it never worked. I spent hours trying, looking into the scripts in /usr/lib/brand/ipkg/, but it was probabaly not meant to be working anyway.

So in the end I hacked it like this:

# /usr/sbin/zfs snapshot -r tank/zones/build@1move
# /usr/sbin/zfs send tank/zones/build/ROOT/zbe@1move > build.backup
# zfs create tank/zones/debugbuild
# chmod 700  tank/zones/debugbuild
# zonecfg -z debugbuild 
# zoneadm -z debugbuild install
# cat build.backup| pfexec /usr/sbin/zfs receive -F tank/zones/debugbuild/ROOT/zbe@1test
# zoneadm -z debugbuild boot

Not really a clean way, since I had to waste some extra bandwidth and time, but a working one.

KDE 4.4.1 on OpenSolaris

A screenshot of KDE 4.4.1 running on OpenSolaris b132. Some things still crash, but we're definitely improving. 

Welcome to the ghetto

One week after the renewed (and reinforced) train station shelters were put in place and we're in a ghetto again.
The yellow rectangle in the middle is the timetable - wisely put to the place of least interest of the grafitti heroes. It stayed there about two more days ...

Breaching a patent

I came across a post on cnet linking to my ooooold blog post on silecing the mouse clicks. The interesting stuff is that the post also linked a patent that is covering the same issue albeit with a slightly different approach.

So was I breaching the patent? Would I be if I started producing silenced rodents? I don't know, there's just too many things to consider
1) Is the patent same as my hack? To me it looks like there are big-enough differences
2) I published it before the patent was published, but after it was filed. How does it work in such cases?
3) Fortunately, I'm not US citizen (the patent was filed in the USA). However there are international treaties regarding IP, so who knows ...

Was the hack worth commecializing?
Quick googling revealed that Gregory Maroun (the guy behind the patent) registered the quietmouse.com domain about the same day he filed the patent application. He was selling the silenced mice for 40-50$ and right now his site states that he's preparing a second generation of the mice that should be out in Spring this year.
So it seems one can do a business around this :-)

Good luck Greg and don't sue me :-)

KDE 4.4.1 on Solaris 10 (Amarok2 included)

Mark Wright and Ben Taylor did enormous amounts of work on porting KDE4 to Solaris 10. About half of the known universe had to be rebuilt, but the result was definitely worth it. Yesterday Mark sent a screenshot of his KDE 4.4.1 session to the mailing list.
As you can see, Amarok2 is there as well - we weren't building it for some time due to the unresolved dependency on MySQL embedded, but fortunately Mark found a workaround.
As of now there are no binary packages available, Ben will probably publish them at some point, although he might need more +1s to motivate him.