This my memo where I store the commands I’m using when building packages with pkgsrc (http://www.netbsd.org/docs/software/packages.html).

Determining the package dependencies:
$ bmake show-depends-pkgpath

Finding build references to a given package, e.g. libdrm:
$ egrep ‘libdrm|xf86driproto’ */*/buildlink3.mk

All the available targets are documented in The pkgsrc make target reference – NetBSD Wiki.

This is used to rebuild a patched package:
bmake distinfo && bmake clean && bmake build

The following builds and install the package:
bmake distinfo && bmake clean && bmake package

QNX specific issues are discussed in the forum http://community.qnx.com/sf/discussion/do/listTopics/projects.pkgsrc/discussion.general.

久しぶりの日記です。

またまた久しぶりに pkgsrc を更新して pkg_roling-replace を実行したところ、x11/modular-xorg-server でエラーが発生してました。
詳細はここをご覧ください。
どうやら新しい x11/printproto が原因らしいです。
もう暫く様子を見ましょう。

# 自分では原因を特定できないので申し訳ないです。
# メンテナンスしていただいている方、よろしくお願いいたします。

よくよく見たら、pkglintから独立していました。

pkgsrc/pkgtools/pkglintとpkgsrc/pkgtools/lintpkgsrcをそれぞれmake updateして今までどおりです。

# obacheさんからコメントをいただいてました。
# ありがとうございました。
# このサイトにコメントをいただけるとは思っていなかったので
# ちょっとビックリでした。

ソースを更新しました。glib2やらperlに依存しているものが沢山あるため、make updateにものすごく時間がかかりました。
ひととおりupdateしたと思ったら日本語変換がonになりません・・・バイナリインストールしたuimが消えていました。
しかも、lintpkgsrc -iで更新状態を確認しようとしたらlintpkgsrcまでもが無くなっていました。
しかもしかも、/usr/pkgsrc/pkgtools/pkglintでmake installしてもlintpkgsrcはインストールされません!?

またまたNetBSDのサイトからとりあえず最も新しいバイナリをダウンロードして、uim-1.3.1nb1.tgzと、バージョンは一つ後戻りしますがpkglint-4.81.tgzをインストールしました。

以上です。

La scheda madre di uno dei miei sistemi ha un bug tedioso, dovuto probabilmente all’aver subito “qualche” danneggiamento, che le impedisce di far funzionare correttamente le unità in modalità Ultra DMA.

Windows sembra non risentire di questo problema: GNU/Linux, specie con le revisioni più recenti del kernel 2.6, ne è sempre più affetto.

Purtroppo, il workaround che consisteva nel passare il parametro ide=nodma sembra non funzionare più. Per questo ho deciso di provare ad utilizzare un altro sistema operativo libero al suo posto. Inoltre, quando ancora il workaround funzionava, il degrado prestazionale che, per contro, si doveva pagare era terrificante.

La scelta è caduta su NetBSD, con il quale ho avuto modo di fare esperienza qualche anno addietro, quando era giunto da poco alla release 2.0. L’impressione che ne avevo ricavato era quella di un sistema molto solido e resistente. La versione 3.1 mi ha confermato appieno quelle impressioni: non soltanto il kernel (che non ho ricompilato, sia chiaro: è quello di default) attiva il workaround per tutte le periferiche IDE in meno di due secondi – mentre Linux aspettava di aver ottenuto l’elenco delle partizioni, ma la fluidità non viene quasi alterata.

Dopo aver sistemato le necessità più immediate (grazie ai pacchetti precompilati che il progetto rende disponibili per ogni release stabile a partire dall’ottimo pkgsrc), mi sono trovato a voler configurare il computer per la stampa.

Nella mia breve esperienza con i sistemi UN*X(-like), ho provato tre sistemi per la stampa: il sistema di stampa BSD, LPRng e CUPS. Pur avendo usato ed apprezzato a lungo il secondo, CUPS ha raggiunto un livello di maturità tale, a mio giudizio, da renderlo la mia scelta preferita. Certamente, come sostiene anche Eric Steven Raymond – con le sue solite maniere forbite – l’uso di CUPS, anche usando i vari front-end per KDE e GNOME che non mi hanno mai convinto troppo, non è proprio a prova di niubbo, ma quantomeno la gestione delle tonnellate di filtri PPD per ciascuna stampante (specie se vi scaricate l’intero pacchetto foomatic) risulta semplificato.

Per installare CUPS ho seguito questi semplici passi:

1. Per prima cosa, bisogna assicurarsi che lpd non sia attivo. Per impostazione predefinita nessun servizio viene avviato su NetBSD, ma qualora abbiate inserito un’override in /etc/rc.conf, siete pregati di sostituirlo con un bel lpd=NO.
2. Bisogna, poi, togliere di mezzo dal PATH i binari lp* che fanno riferimento al sistema di stampa BSD (lpd) distribuito con il sistema operativo. Si potrebbe pensare di cancellarli semplicemente,
   ma potrebbero tornare utili in seguito. Si potrebbe pensare di inserire
   la directory in cui vengono installati i pacchetti di pkgsrc (nello specifico, /usr/pkg/sbin all’inizio del PATH, ma ho come la sensazione che settare bash come shell di root sia una scelta molto più opportuna, a confronto, di questa . Io ho preferito dare un bel for a in /usr/sbin/lp*; do mv $a $a.bak; chmod -x $a.bak; done per renderli “inoffensivi”, togliendo loro il bit di esecuzione e aggiungendo un bel suffisso .bak a futura memoria.
3. L’installazione vera e propria di CUPS l’ho effettuata con un abbastanza standard: export PKG_PATH="ftp://ftp.NetBSD.org/pub/NetBSD/packages/i386/All"
pkg_add -v cups foomatic-filters foomatic-filters-cups foomatic-ppds foomatic-ppds-cups (sì, mi sono installato bash, non mi sono potuto abituare alle shell di default di NetBSD ). Ho scritto abbastanza perchè mi sono imbattuto, in seguito, in un problema.
4. Il problema è stato il fatto che non mi ricordavo che l’unica versione di Ghostscript compatibile con i filtri di CUPS è quella di Easy Software Products (ora Apple), guarda caso l’azienda che stava dietro CUPS . Ebbene, se avete (come avevo fatto io) installato KDE (credo che la stessa cosa accada con GNOME, ma non posso dimostrarlo), noterete che vi siete portati dietro una dipendenza da ghostscript-gpl. L’unica soluzione è forzare l’eliminazione di questo pacchetto, e sostituirlo con ghostscript-esp, così: pkg_delete -f ghostscript-gpl; pkg_add -v ghostscript-esp.

CUPS ha, da quel momento, funzionato a meraviglia. L’unica cosa che non sono riuscito a configurare è stata una stampante ad aghi su porta parallela, per il semplice fatto che non mi viene, a tutt’oggi, consentito di scegliere la porta parallela dal menu a tendina apposito. Investigherò nei prossimi giorni.

One of the new features that Solaris 10 has that I’m interested in is zones. A zone is lightweight virtualisation environment. Unlike VMWare, or Xen, the whole environment is not virtualised. You still have one running OS kernel which arbitrates access to the hardware, for example. A zone is more like a separate instance of the userland, with its own IP address, users, running processes, and so on.

In this respect Solaris Zones are very similar to FreeBSD Jails, and if I was going to sum it up I might call it “chroot on steroids, with a much better management interface.”

I’m quite familiar with FreeBSD’s Jail system, much less so with Zones. I’ve offered up a Zone to some of the pkgsrc developers so they can experiment with pkgsrc on Solaris 10, and I’m planning on using Zones for testing the changes that I’ll be making to Sendmail, so I need to learn how to create and manage them.

BigAdmin has a page dedicated to zones, with links to many other resources. There’s also the OpenSolaris Zones page to consider too. Of the available resources, this article by Brendan Gregg seemed the most comprehensive, and also the most up to date.

Reading through that article the small zone example seems most appropriate. I want to give the pkgsrc developers space to build packages, but I don’t necessarily want them to be able to write to files outside their home directories. Since pkgsrc builds are relocatable (packages don’t have to install under /usr/pkg this should be fine. Of course, I may have to revisit this decision later.

So, on with creating the zone. First, I’ll check that there are no other zones.

# zoneadm list -cv
ID NAME STATUS PATH
0 global running /

That looks promising. zonecfg is used to create and manage zone configuration. I’m going to call the new zone pkgsrc-zone, it’s root directory is going to be /export/pkgsrc-zone, and it’s going to have the IP address 10.0.0.1.

# zonecfg -z pkgsrc-zone
pkgsrc-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:pkgsrc-zone> create
zonecfg:pkgsrc-zone> set autoboot=true
zonecfg:pkgsrc-zone> set zonepath=/export/pkgsrc-zone
zonecfg:pkgsrc-zone> add net
zonecfg:pkgsrc-zone:net> set address=10.0.0.1
zonecfg:pkgsrc-zone:net> set physical=nge0
zonecfg:pkgsrc-zone:net> end
zonecfg:pkgsrc-zone> info
zonepath: /export/pkgsrc-zone
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 10.0.0.1
physical: nge0
zonecfg:pkgsrc-zone> verify
zonecfg:pkgsrc-zone> commit
zonecfg:pkgsrc-zone> exit

A word about zonecfg. I was pleasantly surprised to discover that it supports a command history and sensible editing defaults. Much nicer than many command line tools I’ve had to deal with.

I can re-run zoneadm list -cv to see the new zone.

# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- pkgsrc-zone configured /export/pkgsrc-zone

With the zone configured, I now need to create the zone’s root directory, and install the files that will make up the zone.

# mkdir /export/pkgsrc-zone
# chmod 700 /export/pkgsrc-zone
# zoneadm -z pkgsrc-zone verify
# zoneadm -z pkgsrc-zone install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize packages on the zone.
Initialized packages on zone.
Zone is initialized.
Installation of packages was skipped.
Installation of these packages generated warnings:
The file contains a log of the zone installation.

The wall clock time to complete that last command was 15 minutes. With that done I can see that the zone’s status has changed from “configured” to “installed”, and the zone can be booted.

# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- pkgsrc-zone installed /export/pkgsrc-zone
# zoneadm -z pkgsrc-zone boot
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
1 pkgsrc-zone running /export/pkgsrc-zone

I can then use zlogin to connect to the zone. Since this is the first boot I’m asked the standard Solaris setup questions. The zone then reboots, and puts me at the console login prompt.

# zlogin -C pkgsrc-zone
[Connected to zone 'pkgsrc-zone' console]
Select a Language

pkgsrc-zone console login:

That’s all relatively painless. And much easier than handrolling things. At $work I’m having to build chroot environments for testing, and making sure that the right files get copied, procfs is mounted, and all the other twiddly bits gets tiresome quite quickly. I’m quite pleased at how easy that was.

I wrote earlier about getting pkgsrc builds up and working.

Unfortunately, I wrote too soon.

Although Perl built successfully, attempts to build other applications that I’m going to need failed in interesting ways. No Subversion, no xemacs, no SVK. After fiddling with the build infrastructure for a little while and not getting terribly far I’ve (for the time being) switched to the pre-compiled binary packages provided by Blastwave.

Although they don’t have the same building-from-source warm fuzzies that I get from pkgsrc they do at least have the benefit of actually working.

I brought this up on the #pkgsrc IRC channel earlier to see if anyone could offer any advice. The net result is that I’m going to be offering up a jail^H^H^H^Hzone on this machine to one of the pkgsrc developers to use as a Solaris 10 test bed. So Solaris 10 support in pkgsrc might start to get a little better.

In the years that I’ve been using Solaris it’s support for third party packages has, to my mind, always let it down. The open source community writes and releases software at a phenomenal rate, and systems like FreeBSD and Linux have developed a number of interesting ways to make it as easy as possible to get this software, install it, and (much more importantly) manage it once it’s been installed.

As third party applications grow in complexity (especially in terms of the dependencies that they might have on other applications and libraries) this becomes an increasingly difficult challenge.

It’s a challenge that the open source community is particularly well suited to meeting. The “many hands makes light work” effect, and the fact that it’s possible for an individual to make a contribution without investing a great deal of effort means that thousands upon thousands of open source applications and libraries are now trivial to install on many open source operating systems.

That same has not been true, historically, about Solaris. Sure, there’s been sites like Sun Freeware, but the size of that community is dwarfed by the size of the communities packaging applications for the open source operating systems.

Consequently, installing and managing third party software (especially if it has complex dependencies) has always been a bit of a chore on Solaris.

A few years back I attended a talk given by Alistair Crooks at EuroBSDCon 2002. Alistair spoke about a package management system that NetBSD was using, forked from the FreeBSD ports tree. One of the interesting things about this was that following the NetBSD “runs anywhere” mantra, this system, called pkgsrc, could be used to build and manage packages across multiple operating systems, including Solaris.

Fast forward a few years, and pkgsrc has its own website (www.pkgsrc.org) and is growing in size. So I put it on my “list of technologies to keep an eye on”.

The pkgsrc system is very similar to the FreeBSD Ports system.

Essentially, the acts of downloading a source tarball from the Internet, verifying the file’s checksum, extracting it, applying any patches, configuring, building, and installing the resulting files have been automated using make(1). Package dependencies are also tracked, with pkgsrc recording this metadata in its own packaging format and database, independent of the operating systems own package database.

This might seem like needless duplication of effort, but it does mean that if your environment runs multiple operating systems you can use pkgsrc to build and manage packages for all these operating systems using the same tools, instead of pkgadd(1) on Solaris, rpm(1) on Linux, and so on.

This evening has been spent getting pkgsrc to play nicely on Solaris 10. This is a not-quite-supported configuration, so I’ve had to go round the loop a few times. After playing around with a mixture of packages from Sunfreeware and pre-compiled binaries from elsewhere I eventually figured out the magic incantations. And they are as follows (and assume that Sun Studio 10 is installed).

1. Download the most recent pkgsrc snapshot from here (note: that link will go stale over time
2. Download the Solaris 9 pkgsrc bootstrap
3. Extract both of those in to /
4. # cd /usr/pkgsrc/bootstrap; ../bootstrap
5. Copy the generated mk.conf to /usr/pkg/etc/mk.conf.
6. Add the line “PKGSRC_COMPILER=sunpro” to that mk.conf file.

That, at least, is sufficient to allow the following to work:

# cd /usr/pkgsrc/lang/perl5
# bmake install

Which results in the source for Perl (v5.8.8) being downloaded, patched, configured, built, and installed. Along with any dependencies it might need.

# pkg_info
digest-20060302 Message digest wrapper utility
libiconv-1.10nb3 Character set conversion library
gettext-lib-0.11.5nb6 Internationalized Message Handling Library (libintl)
pkg_install-info-4.5nb3 Standalone GNU info file installation utility
gmake-3.80nb4 GNU version of 'make' utility
perl-5.8.8nb2 Practical Extraction and Report Language
libtool-base-1.5.22nb3 Generic shared library support script (the script itself)

Now to go and try xemacs….