Synopsis

Page about Java support on NetBSD

OpenJDK

Available from:

• lang/openjdk7
• lang/openjdk7-bin

Application compatibility

What works (not a complete list):

• NetBeans 6.7
• jedit
• jruby

What doesn't:

• robocode

Known issues

• Nimbus look'n'feel doesn't work
• Missing RPATH, so it can't dlopen shared objects from /usr/pkg/bin/lib
• GTK2 look'n'feel doesn't work without tweaking (because of the above)

Welcome on jym's wiki page, with hopefully up-to-date info on my work within NetBSD. At least, more up-to-date than my personal homepage.

This current page acts as a personnal sandbox, so please be patient. Delightful and interesting information about port-xen or Xen's howto are incoming.

Some links related to my work:

• PAE and Xen balloon benchmarks
• some coccinelle work

Currently working on:

• Xen save/migrate/restore (works, now tracking a few glitches during resume)
• Intel/AMD PowerNow/Speedstep functions inside dom0
• Amazon EC2 support

Wiki consideration: bring ikiwiki templates and content formatting close to what we currently render through Docbook for NetBSD Documentation. See ?tryouts.

Description

Use this template to insert a note into a page. The note will be styled to float to the right of other text on the page. This template has one parameter:

• text - the text to display in the note

Examples

Some text floating to the right, with the NetBSD's logo:

    [[!template  id=note text="""
    <img src="http://www.netbsd.org/images/NetBSD-smaller.png" /><br />
    The official NetBSD Foundation Logo."""]]

Description

Use this template to create a popup window that is displayed when the mouse is over part of the page. This template has two parameters:

• mouseover - This is the text or other content that triggers the popup.
• popup - This should be the content of the popup window. It can be anything, even images or a whole little wiki page, but should not be too large for good usability.

Note that browsers that do not support the CSS will display the popup inline in the page, inside square brackets.

Examples

Trigger a popup when hovering this text [Here comes the content of the popup.] :

    [[!template  id=popup mouseover="hovering this text" popup="Here comes the content of the popup."]]

It should be possible to write an ikiwiki plugin to process XML as an input format. This would make it very easy to move content between htdocs and the wiki.

Links of potential interest:

• XML::XSLT
• Docmake
• xmlto
• xsltproc
• ikiwiki xslt plugin

later

Before announcing the wiki to developers, we need brief explanations of how to:

• edit via CVS
• edit via web browser:
  Just hit the 'Edit' link in the top bar. For markup advice, see the FormattingHelp link at the bottom next to the save etc buttons. Or use the cheat option: look at a page that already does what you want to achieve.
• set up Kerberos
• report the "do" parameter missing bug

done --schmonz

Discovered while trying to debug a template of plunky's:

When web-editing a template, clicking "Save Page" always results in ikiwiki thinking a page-editing conflict occurred. It's not related to HTML::Template tags, because I can put a template's contents into some other page, verbatim, with no errors.

Joey and I can't reproduce with a git-backed wiki. It's probably a bug with the CVS backend. He suggests two possibilities:

1. cvs commit is really failing
2. rcs_commit does not return undef when it does return unless cvs_is_controlling

Something odd happened to me just now, web-editing hook up wiki commits to www-changes@ with SPNEGO. I added a line, clicked Preview, then clicked Save Page and got the spurious conflict. However, after clicking Cancel, the edit was indeed there. This may or may not be the same problem.

And the same thing happened to the above edit. Now trying kdestroy and plain HTTP auth.

There were two reasons cvs update wasn't silent: the blog directory where ikiwiki's aggregator stashes blog entries, and a "note" template marked for Add but not yet added. I've added the former to .cvsignore and committed the latter. Will this web edit be spurious conflict-free?

Yes, it was. That narrows it down a bit for when I've got time to fix this properly. --schmonz

Very likely caused by the CGI not running setgid netbsd until now. --schmonz

RSS Atom Add a new todo item entitled:

To provide unified authentication across web (and conceivably other) applications, we want Kerberos.

• Kerberos server
• web host talking to it
• Apache + mod_auth_kerb (or else mod_auth_pam)
• procedure for a developer to set new Kerberos password
• developers: set password to gain wiki edit access!

?tls and schmonz have satisfactorily Kerberized monitor. done

Having implemented CVS support, we need a test wiki instance in order to evaluate its merits.

spz provided a running system suitable for testing, on which the following was done:

• installed the necessary pkgsrc bits:
• www/apache22
• www/ikiwiki (with the ikiwiki-search option and CVS-related LOCALPATCHES)
• www/cvsweb
• devel/cvsps
• created a wiki user
• created ~/etc/htpasswd
• created ~/etc/apache.conf (restricting web editing to valid users in ~/etc/htpasswd) and included it from the system's httpd.conf
• made a copy of cvsweb into ~/cgi/cvsweb and pointed it at ~/etc/cvsweb.conf
• placed the CVS plugin (not yet included in ikiwiki) in ~/perl/IkiWiki/Plugin/cvs.pm
• created ~/src and ~/html directories
• ran ikiwiki-makerepo cvs ~/src ~/cvsroot to import ~/src into a new repository and configure the ikiwiki post-commit hook
• ran ikiwiki ~/src ~/html --libdir ~/perl --url=http://testwiki.ipv6.de --dumpsetup ~/etc/ikiwiki.conf to create a config file
• tweaked ~/wiki/etc/ikiwiki.conf considerably (for exact changes, diff -u ~/etc/ikiwiki.conf{.default,}):
• added useful plugins, including the CVS plugin
• disabled Discussion subpages
• enabled userdir
• enabled RSS/Atom feed generation
• locked the included ikiwiki documentation against web editing
• ran ikiwiki --setup ~/etc/ikiwiki.conf to generate pages and the CGI and post-commit wrappers
• copied cvsweb.css, the NetBSD.org favicon.ico, and a downloaded stylesheet into ~/src, cvs added them (with -kb for the icon) and cvs commited to test that the post-commit hook regenerates the site
• started Apache
• added a cron job for ikiwiki's feed aggregator

done --schmonz

It should be possible to restrict viewing of pages to logged in users or even further a subset of logged in users. This would enable a private collaboration to be set up where (a group of) persons are building ideas out of sight. --plunky

wikisrc is in its own repository, by design. We need to arrange for it, like the main repository, to be pushed to anoncvs.

spz says:

• anoncvs should pull instead, due to the trust hierarchy of TNF's servers
• we'll need to prevent simultaneous rsyncs from stepping on each other's toes
• we'll need to massage CVSROOT so wikisrc looks like any other anoncvs module

To encrypt logins for the wiki and other web services, we need an SSL certificate. spz has done this.

Both as an experiment and as an additional layer of backup, the blog (posts and comments) should be aggregated and republished on the wiki. --schmonz

See also ikiwiki as blog.

done (posts only) --schmonz

Seriously. It's easy and fine once the "add new page" goo is in a page. But I am surprised there's not an easier way to simply add a page below any given existing page.

P.S. Muahaha! I control your TODO list! Fear the wiki, for with it comes an ever-growing list of tasks assigned to you by me!

P.P.S. Orange

--snj

The usual way assumes you'll want any new page to be linked from somewhere. Add a WikiLink to the page you want to create, and then it should be easy enough. Note that when creating a page you often have several choices of where in the hierarchy you want it to go; for how this works, see LinkingRules. --schmonz

See also http://ikiwiki.info/todo/adding_new_pages_by_using_the_web_interface/

done --schmonz

I've added a postform to the front page for good measure. --schmonz

I've added "New" to the wiki action bar for really good measure. --schmonz

?tron suggests that non-developers should be able to post content to a staging area, to be approved (possibly after editing) by developers. schmonz likes this idea a lot.

what about to make a sub-page called e.g. User contributed documentation an give non-developers rw access there while editing other parts(TNF contributed) of wiki will require developers account or possible some sort of bless from a developer. --haad

From ikiwiki's PoV, this is equivalent to the Discussion-subpage approach (merely a tweak to a PageSpec). From the human PoV, it's a tradeoff. If we make a whole hierarchy world-editable, users will be able to directly edit any page in that hierarchy, but we'll wind up with two pages on every topic of interest and readers will have to check both. A discussion subpage isn't the page itself, but the relation of the two is never ambiguous.

Neither approach is ideal. A possible improvement: in addition to making making Discussion pages world-editable, use the ikiwiki/directive/inline directive on each main topic page to include the relevant Discussion subpage below, with a disclaimer about the provenance of that content. Then both developers and users can effectively edit the page, and the reader can easily discern what's what.

Best if this inlining could be automated somehow, rather than requiring someone to add a directive to each page. --schmonz

I don't understand why we are making user editing so hard, with discussion pages there will be little or no user contribution which is wrong because main point of wiki is to give users power to share information not give this power to developers. Let's make part of wiki editable by users to let them contribute their documentation. If user will want to make his own page about e.g. using NetBSD as xen server how he will done it with discussion pages ?

From other POV I looked at FreeBSD wiki and they have developers only wiki which can be edited by developers and some small number of non developers. --haad

Sorry, I wasn't clear enough. Each page "Foo" will call inline to insert its Discussion subpage into itself. The Discussion subpage will continue to exist separately, but its contents will also be included in the Foo page. The Foo page will then have two sections: one that's only editable by developers, and another that's editable by anyone. Developers will use the "Edit" link as normal. For ease of user editing, we'll want to provide an "Edit" link within the user-editable section of the page which leads directly to editing the corresponding Discussion subpage where that content is stored. Either kind of edit will result in an immediate update of the Foo page.

With this approach, once the relevant ikiwiki bug has been fixed, the opendiscussion plugin should suffice to enable users to edit content in a direct way, while also making clear to readers which content comes from developers and which does not.

Things to think about when the time comes:

• automating the inline, disclaimer, and user-edit link (in wikitemplates?)
• whether anonok is okay or we should require e.g. an OpenID
• treating non-developer edits properly in log_accum messages

--schmonz

For non-developers using anonymous CVS: submit a diff to netbsd-docs@.

For non-developers using a web browser: the ikiwiki discussion subpage and/or comments plugin may point toward the solution.

One of the reasons we chose ikiwiki is the ability to edit via CVS directly, as well as via the web. As long as every wiki editor is a developer, controlling access consistently is simple. In order to open up wiki editing to non-developers, we have to think carefully about both the CVS case and the web case.

In the short term, to start getting non-developers involved, I intend to push wikisrc to anoncvs and hook up wiki commits to www-changes@.

In the long term, ikiwiki has a few ready-made web authentication options (a locally managed user database, OpenID, and HTTP auth), and if they don't suffice for some reason, it's easy enough to write an auth plugin. The hard part is deciding the workflow: where is a sensible place for non-developers to make their edits, and what is a sensible way for developers to review and "bless" the changes? Two ikiwiki-native possibilities are listed above.

Ideas welcome! Edit this page and add your comments. --schmonz

One idea (which needs to be considered by board@):

1. Enable Discussion subpages.
2. Mark very clearly on the Discussion page template that content may have been written by anyone at all and has not been vetted by any member of TNF.
3. Enable the anonok plugin and set the anonok_pagespec to allow anonymous editing of Discussion subpages (and of no other pages).

This doesn't actually work, though. Trying to create or edit a Discussion subpage yields the HTTP auth dialog. And this is equivalent to the opendiscussion plugin. Joey says: "it's a bug, not sure how to fix it right now". --schmonz

The resulting workflow:

1. Non-developer finds a page to which to suggest changes.
2. Non-developer edits its Discussion subpage and writes the suggested changes.
3. Developer who follows RecentChanges (or the commit mails) notices the changes.
4. If the changes aren't acceptable, developer edits the Discussion subpage and explains why not.
5. If the changes are acceptable, developer applies them to the page and removes them from the Discussion subpage.

This can be work flow for a TNF contributed pages but as I said above this is not acceptable for as normal wiki workflow. We had almost similar discussion about comments on a blog software for NetBSD. There were developers who thought that there will be too many comments and we do not have man power to read/approve them all. After setting blog we have found that we have barely 1-2 comments in every third article. I don;t thing that there will be too many real editors on our wiki from non-developers and therefore we need to make it easy not hard to do. --haad

And yet, we already had spam on the blog. I'm not much pro distributing spam, and would strongly suggest some kind of auth that at least brakes spam down a bit. That also speaks against using "any verifying OpenID" (ie users may opt to use OpenID but we still need to put their ID into some sort of list of good IDs). --spz

This sounds reasonable. Getting oneself added to a whitelist isn't too much to ask a prospective contributor. The whitelist can be implemented using plugins/lockedit. --schmonz

spz: How much spam we had there ? Because during our initial talks about blog there were huge expectations about number of spammers and comemnters on our blog for now I don't think that we have more then 30 uniq commenters/spammers that is so low number that we should block user non auth editing because of it. -- haad

Not speaking for spz, but the current holdup is a more general interaction with plugins/httpauth combined with any other type of auth (including plugins/anonok). Once it's fixed, it's about the same amount of work for us to whitelist the OpenIDs of actual human contributors as it is for us to allow fully anonymous editing. So the question becomes, what's best for this wiki that admins feel is reasonably manageable and responsible? Even if the risk of opening ourselves for editing by the whole Internet is small -- and we can't know that -- I'm not comfortable putting TNF at that risk unless there's a very compelling argument for it. --schmonz

There's CAPTCHA work in progress. That might be palatable, when done, as an option in addition to OpenID. --schmonz

After a bunch of work by Joey, we're much closer:

• With httpauth, you can (still) edit any page.
• With an OpenID we've whitelisted, you can edit discussion subpages.
• Otherwise, you can't edit via the web.

What's left:

• Extract the OpenID whitelist to a separate file for ease of maintenance.
• In log_accum, properly parse and display OpenID edits.
• In page.tmpl, inline discussion (if it exists) into its parent page.

--schmonz

---

Whew, this is a long discussion. To recap, every wiki page will have two sections:

1. Content editable by developers only, followed by
2. Content editable by anyone who has told us their OpenID.

This way, every wiki page will be editable (in whole or in part) by everyone, while making the content's provenance clear to the casual reader.

I will implement this by abusing any and all of inline, templates, and/or Discussion subpages.

There were problems combining httpauth (how developers log in) and other authentication methods. The ikiwiki author has fixed these problems.

I have working code to check OpenIDs against a whitelist. We need to streamline the task of "registering" an OpenID as much as possible, so non-developers can get involved with the wiki quickly and easily. We will also want to delegate whitelist management to www@.

The wiki copy of log_accum needs to be taught to parse OpenID edits (and set Reply-To: to the committer, not wiki@NetBSD.org). To avoid skew, we should then carefully merge it back to the main log_accum.

Non-developers will want wikisrc in anoncvs.

In the future, if and when ikiwiki has more fully baked anti-spam measures, it would be nice to be able to allow anonymous editing.

--schmonz

done

Access to the CGI is restricted to authenticated HTTP users. In general, this is as it should be. However, searching is handled by the CGI too. Browsing doesn't require authentication; searching shouldn't either.

(Also, while I'm at it, RecentChanges links to recently edited pages via the CGI, and those links should work for unauthenticated users too. Any other operations to be whitelisted?)

Fixed with a locally applied patch (will be in the next release) from Joey. --schmonz

Search results all start with our web template crud. Would be nice if the previews showed page content instead.

This will also be fixed in the next release. To my taste, this is done. --schmonz

Having chosen ikiwiki, we need to write a plugin to use CVS as the backend revision control system.

While ikiwiki's VCS API is straightforward, CVS is missing some features and behaves badly, besides. Despite these well-known limitations, the CVS plugin manages to implement the complete API, so all of ikiwiki's VCS-related features work.

There may be a bug or two yet to be found, but this is done. --schmonz

Wiki commits should be sent to www-changes@ like any other web commits. This will necessitate copying commit_prep, log_accum, and perhaps other bits from nbcvs. --schmonz

spz has copied those bits over. I'll try to look at this soon.

Works as expected for cvs commits. For web commits, From:, Committed by:, and the commit message need to be massaged (as seen in this commit message). The code for this can be stolen from ikiwiki's. --schmonz

done

The home/about/gallery/etc bar uses relative links (e.g. http:home), not absolute links (e.g. http:/home); this causes said href'ed items to fail anywhere but from the root of the wiki.

done (but the templates are still very much in progress) -- schmonz

The todo list is handy for reporting wiki suboptimality.

A news page (set up as a mini-blog, just like the todo list) that announces new wiki features would be nice to have. Being able to see a trail of improvements could help motivate involvement.

done (it's ?here) --schmonz

a template (or set of templates, whatever is practical) for ports info, see ports/amiga or other ports pages what info should be going in there.

At the very least: hardware supported by the port, news, which mailing lists handle the port, mail-to-port-maintainer

--spz

Requirements for an official NetBSD wiki:

• UI: pleasant web editing with preview and diff
• appearance: customizable with CSS and templates
• access control: publicly readable, editable by developers only, an area readable by developers only
• web authentication: Kerberos
• implementation language: not PHP
• revision control: yes, preferably not something homegrown, even more preferably CVS
• page rendering strategy: compiles static pages that can be mirrored

Before selecting ikiwiki, I evaluated the following:

Software	Language	Versioning	Comments
Sputnik	Lua	git or filesystem	looks cool
Foswiki	Perl	RCS	fork of TWiki, complex install docs, complex software, checkered security history
Kwiki	Perl	don't remember	old version was so-so, the ambitious rewrite never happened
MojoMojo	Perl	SQL	featureful
MoinMoin	Python	filesystem

In my opinion, ikiwiki is the best fit: written in Perl, with a simple web UI and several ways of restricting access, it not only renders arbitrary hierarchies of static pages, but also is designed to be used in concert with a variety of external revision control systems.

This one's done. --schmonz

ikiwiki is translatable with plugins/po (see it in action at l10n.ikiwiki.info). If we can enable the plugin, we can experiment with translating this wiki.

The wiki needs conform with the layout and style of www.n.o and blog.n.o by applying http://www.netbsd.org/global.css.

Help can be sought from www or more specifically either haad or ?sarah.

done --haad

Many wikis out there use icons, or artworks, to wiki layout and/or presentation. For example (my apologies, only french links provided):

• http://fr.wikipedia.org/wiki/Accueil
• http://doc.fedora-fr.org/wiki/
• http://doc.ubuntu-fr.org/

One good start would be to investigate what kind of icons we would like to have in our wiki:

• any work previously done, or WIP, from TNF or marketing?
• define conformance to NetBSD's graphics standards?
• reusability? (licences, public domain vs CCs vs GNU derivative work, etc.)

Inspiration: see icons from wikimedia.

--jym

You've seen this, but others may not have: ikiwiki comes with some built-in icons we could be putting to better use. --schmonz

My own TODO file where I'm trying to keep old things which I would like to see to be done in NetBSD.

Short time goals

1. Fix disk and pseudo-disk ioctl calls used to get informations about disk partitions
2. dm device driver rump port [DONE]
3. update lvm2tools to newer version [DONE]
4. update zfs code to newer version
5. Modular improvements
6. Change way how vnodes are reclaimed to make our vfs much cleaner. [Work in progress]
7. VN_RELE_ASYNC fix for NetBSD [Work in progress]

Mid time goals

1. Port crash(8) to other architectures
2. Write DRBD like device for NetBSD dm
3. LVM remote replication support
4. LVM mirror target (taken from raidframe) ?
5. ZFS Snapshosts support
6. Change ZFS taskq to NetBSD workqueue in a useable way for ZFS.

Long time goals

1. Rewrite ddb to be more modular and to be useable as userspace binary, too.
2. Port Sun Dtrace to NetBSD (Freebsd did that some time ago)
3. Cluster LVM
4. Snapshot LVM support

iMil's wiki.n.o corner

Link to my homepage

The one and famous pkgin !

NetBSD cheat sheet

NetBSD setup

• X11
• Services
• Installation on UEFI systems
• X11 with the wsfb UEFI/BIOS framebuffer display driver
• Enabling or disabling extended attributes and ACLs on FFS

Guide and HOWTOs

• Root on ZFS
• set-up raidframe
• LaTeX in NetBSD
• How to use snapshots

Virtualization

• Xen HOWTO
• Amazon EC2
• how to set up a guest os using xen3

pkgsrc

• pkgsrc

System

• How to enable and run DTrace
• How to create an L2TP IPSEC tunnel between an Android or iPhone or iOS device to NetBSD
• How to increase ulimit with rc.conf
• How to setup VirtIO SCSI with qemu

Developing NetBSD

The tutorials above are aimed at using NetBSD; this section is about improving it.

Userland

• curses in NetBSD
• sysinst translations and testing

Kernel

• Kernel debugging with QEMU

Wifi Renewal

• Wifi renewal on hg
• Testing new wifi
• Converting drivers to the new wifi stack
• Converting USB drivers to usbwifi(9)
• Current state of wifi drivers

Testing

• atf
• reproducable builds
• Continuous building and testing netbsd with buildbot

Procedural

• Developer Key Signing

everything (automatic index)

• DRI, AIGLX, Composite and Compiz
• wsfb UEFI/BIOS framebuffer display driver

Eye Candy for NetBSD 5.0

Since a couple of years, there are some Window Managers providing shiny 3D effects like a cube-mapped-desktop, wobbly windows and various other animations.

NetBSD is capable of dealing with those interfaces, but their installation is not yet straightforward. Here are the couple of steps you'll have to go through in order to impress your friends with a modern 3D NetBSD desktop.

Enable DRM in the kernel

Depending on the graphic card you are using, add one of the following to your kernel configuration:

i915drm*        at vga?         # Intel i915, i945 DRM driver
mach64drm*      at vga?         # mach64 (3D Rage Pro, Rage) DRM driver
mgadrm*         at vga?         # Matrox G[24]00, G[45]50 DRM driver
r128drm*        at vga?         # ATI Rage 128 DRM driver
radeondrm*      at vga?         # ATI Radeon DRM driver
savagedrm*      at vga?         # S3 Savage DRM driver
sisdrm*         at vga?         # SiS DRM driver
tdfxdrm*        at vga?         # 3dfx (voodoo) DRM driver

For example, if your graphic card has an intel 945GM chip and your architecture is amd64-based:

# cd /usr/src/sys/arch/amd64/conf
# cp GENERIC MYKERNEL
# echo "i915drm*        at vga?" >> MYKERNEL

Then recompile and copy your kernel as usual.

Modular Xorg

The next step involves the Xorg server. Xorg 1.4.2 which is the version bundled with NetBSD 5.0 has no real AiGLX support. While Xorg.0.log will pretend AiGLX is enabled, it does not load the X dri driver related to your GPU. In order to have full AiGLX support, you will have to use pkgsrc's modular Xorg. Refer to this article see how to achieve this simple -but long- task.

Once modular Xorg is installed, you'll have to tell gdm not to start the base Xorg server, but the new one installed by pkgsrc. Edit /usr/pkg/etc/gdm/custom.conf and add the following lines:

[server-Standard]
name=Standard server
command=/usr/pkg/bin/X vt05 -audit 0
flexible=true

Those using startx instead should create a ${HOME}/.xserverrc with the following content:

exec /usr/pkg/bin/X vt05 -audit 0

Update your ${PATH} variable so /usr/pkg/bin comes before /usr/X11R{6,7}/bin, i.e.:

PATH=${HOME}/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/pkg/bin
PATH=${PATH}:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin
PATH=${PATH}:/usr/X11R7/bin:/usr/X11R6/bin
export PATH

Xorg configuration

Exit from any X Window environment you might be using and run:

# Xorg -configure

This should produce a valid xorg.conf file in your ${HOME} directory, just copy it to /etc/X11/xorg.conf. Here is a typical xorg.conf file with necessary bits for DRI, AiGLX and Composite extensions to be loaded and operationals:

Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
        ModulePath   "/usr/pkg/lib/xorg/modules"
        FontPath     "/usr/pkg/lib/X11/fonts/misc/"
        FontPath     "/usr/pkg/lib/X11/fonts/TTF/"
        FontPath     "/usr/pkg/lib/X11/fonts/OTF"
        FontPath     "/usr/pkg/lib/X11/fonts/Type1/"
        FontPath     "/usr/pkg/lib/X11/fonts/100dpi/"
        FontPath     "/usr/pkg/lib/X11/fonts/75dpi/"
EndSection

Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "dri2"
        Load  "extmod"
        Load  "glx"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbRules"   "xorg"
        Option      "XkbModel"   "pc105"
        Option      "XkbLayout"  "us"
        Option      "XkbOptions" "compose:ralt"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "wsmouse"
        Option      "Device" "/dev/wsmouse"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
        #DisplaySize      330   210     # mm
        Identifier   "Monitor0"
        VendorName   "LPL"
        ModelName    "2900"
EndSection

Section "Device"
        Option      "DRI" "true"
        Option      "AccelMethod" "XAA" # needed for 945GM GPUs
        Option      "XAANoOffscreenPixmaps" "true"
        Option      "AllowGLXWithComposite" "true"
        Identifier  "Card0"
        Driver      "intel"
        VendorName  "Intel Corporation"
        BoardName   "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
        BusID       "PCI:0:2:0"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        SubSection "Display"
                Viewport   0 0
                Depth     1
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     4
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     8
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     15
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     16
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Section "ServerFlags"
        Option "AIGLX" "true"
EndSection

Section "DRI"
        Mode 0666
EndSection

Section "Extensions"
        Option "Composite" "Enable"
EndSection

Checklist

Now reboot your NetBSD computer with the previously compiled kernel. When Xorg starts, you should see the following kernel messages using dmesg:

error: [drm:pid389:i915_getparam] *ERROR* i915_getparam called with no initialization
i915drm0: interrupting at ioapic0 pin 16
error: [drm:pid389:i915_getparam] *ERROR* Unknown parameter 5

Error messages can safely be ignored, they mean you're not running a GNU/Linux kernel >= 2.6.28. Xorg.0.log now should contain the following messages:

[...]
(**) AIGLX enabled
(II) Loading extension GLX
(II) LoadModule: "intel"
(II) Loading /usr/pkg/lib/xorg/modules/drivers//intel_drv.so
[...]
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
[...]
(II) intel(0): [DRI] installation complete
[...]
(II) AIGLX: enabled GLX_SGI_make_current_read
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: enabled GLX_texture_from_pixmap with driver support
(II) AIGLX: Loaded and initialized /usr/pkg/lib/dri/i915_dri.so
(II) GLX: Initialized DRI GL provider for screen 0

Meaning your X11 environment can now play well with 3D gadgets.

Running compiz

In order to test your new X Window powers, install the following packages using your favourite method (pkgsrc, pkg_add, pkgin...):

wm/compiz
devel/libcompizconfig
wm/compiz-fusion-plugins-extra
wm/compiz-fusion-plugins-main
devel/compizconfig-backend-gconf
wm/ccsm

As of 26/11/2009, pkgsrc-2009Q3 binary version of those packages is 0.6.0. If you'd like to use the latest compiz version (0.8.4), you'll have to install it using current version of pkgsrc.

Once done, if you use the GNOME desktop, start compiz with this little script:

#/bin/sh

# compiz 0.6's --replace does not kill properly metacity
pkill metacity

# for intel cards, add INTEL_BATCH=1 to the following command
LIBGL_ALWAYS_INDIRECT=1 /usr/pkg/bin/compiz --replace --indirect-rendering ccp &

If your windows don't have decorations, launch the ccsm utility and under the "Effect" section, check "Window Decoration".

0.6 version of compiz is old and suffers a known bug, instead of using metacity's themes, it draws white translucent borders. A patch is available for the gtk-window-decorator program that fixes it, but if you don't feel like patching / compiling, revert to compiz's default windows decorator:

$ gconftool-2 --set /apps/gwd/use_metacity_theme false --type bool

It's now up to you to play along with ccsm and try all those shiny effects you'll soon be unable to miss

Mandatory screenshot: Shiny Disco Balls !

Keeping packages up-to-date with pkg_comp and pkg_chk

Pkgsrc is a fantastic package management framework, but when it comes to upgrades, some use cases may lead to an unstable situation. Also, if by any chance you have 2 or more NetBSD machines to keep up-to-date, upgrading each one separately could be risky and a real waste of time. We'll see how to flawlessly keep your packages up-to-date with minimal risks.

pkg_comp

Under pkgsrc/pkgtools you will find a great utility called pkg_comp. This script permits to handle packages manipulation in a chrooted environment, thus keeping your real packages safe from any mistakes.

For pkg_comp 2.x, located under pkgsrc/pkgtools/pkg_comp, follow these tutorials:

• Introducing pkg_comp 2.0 (and sandboxctl 1.0)
• Keeping NetBSD up-to-date with pkg_comp 2.0
• Easy pkgsrc on macOS with pkg_comp 2.0

For pkg_comp 1.x, located under pkgsrc/pkgtools/pkg_comp1, continue reading this page.

Let's install pkg_comp 1.x:

# cd /usr/pkgsrc/pkgtools/pkg_comp1
# make install clean

Once done, we will create the chrooted environment:

# mkdir -p /home/pkg_comp
# cd /home/pkg_comp
# pkg_comp -C test.conf maketemplate

This will create a template file, which will be used to build our fake NetBSD system, but first, we'll have to set up some information. Using your favourite editor, change the following variables to suit your needs:

• DESTDIR, where the chroot will be built
• DISTRIBDIR, where pkg_comp will find your NetBSD binary sets
• SETS_X11 may be set to "no" if you do not intend to use the X Window system

This is my pkg_comp configuration:

...
DESTDIR="/home/pkg_comp/test"
DISTRIBDIR="/home/pkg_comp/dist/NetBSD-5.0.1"
SETS_X11="no"
...

If you don't yet have NetBSD's binary sets, download them from your favourite mirror and put them in /home/pkg_comp/dist/NetBSD-5.0.1/binary/sets. Also note that NetBSD's source directory (/usr/src in most cases) must exist.

We can now build the chroot using the following command:

# pkg_comp -C test.conf makeroot

From now on, we can enter our chroot using the chroot target:

# pkg_comp -C test.conf chroot
PKG_COMP ==> Mounting sandboxed filesystems
PKG_COMP ==> Entering sandbox `/home/pkg_comp/test'
pkg_comp:test.conf# exit
PKG_COMP ==> Unmounting sandboxed filesystems

A very simple method to build a package in the chroot is to use the build target: # pkg_comp -C test.conf build pkgtools/pkgfind

But as we want to keep a good control on our packages freshness and build method, we will use another tool: pkg_chk.

pkg_chk

pkg_chk is another tool available under pkgsrc/pkgtools. This script reads the content of the pkgsrc/pkgchk.conf file and checks if every listed package is up to date. You will have to install pkg_chk on the chroot as well as in the host.

Let's create a /usr/pkgsrc/pkgchk.conf file. Please note this must be done outside of the chroot, pkg_comp uses pkgsrc's directory to read content, but it mounts it as a read only partition. Here's an output of the mount command inside of the chroot:

/usr/src on /var/chroot/pkg_comp/default/usr/src type null (read-only, local)
/usr/pkgsrc on /var/chroot/pkg_comp/default/usr/pkgsrc type null (read-only, local)
/usr/pkgsrc/distfiles on /var/chroot/pkg_comp/default/pkg_comp/distfiles type null (local)
/usr/pkgsrc/packages on /var/chroot/pkg_comp/default/pkg_comp/packages type null (local)

As you can see, generated packages will be written to /usr/pkgsrc/packages and we are allowed to fetch distfiles to /usr/pkgsrc/distfiles, but /usr/pkgsrc and /usr/src are not writables.

# pkg_chk -g

This command will generate an initial pkgchk.conf file based upon the packages installed on the host machine.

Now, enter the chroot as we must configure its etc/mk.conf file:

# no X11
MKX11=no
# clean dependencies when the "clean" target is called
CLEANDEPENDS=yes
# everybody likes vim
ACCEPTABLE_LICENSES+=vim-license
# we want to build packages fo every software
DEPENDS_TARGET=package-install
UPDATE_TARGET=package-install

Everything is now ready. pkg_chk has many options, but we will keep its use very simple.

To see what operations are going to take place without actually doing anything, use the following switches:

pkg_comp:test.conf# pkg_chk -uan

When ready, call pkg_chk this way:

pkg_comp:test.conf# pkg_chk -ua

Depending on how many packages you must generate, this operation could be a rather long one.

Once the packages creation is finished, you may logout from pkg_comp and update your host's packages using binaries created by pkg_comp's pkg_chk:

# pkg_chk -uab

As pkg_chk manpage says:

-b  Use binary packages.  If -s is not set this allows pkg_chk to
    run without PKGSRCDIR.

Here we are! massive upgrade, no harm, no pain.

Upgrading more than one machine with pkgin

A convenient method to upgrade more than one machine is to use pkgtools/pkgin, a remote package installation and upgrade utility being able to handle packages dependencies.

In the machine hosting binary packages, install an HTTP or FTP server being able to access the directory where your binary packages are located. For example, using www/lighttpd:

...
dir-listing.activate = "enable"
...
$HTTP["host"] == "pkgsrc.home.imil.net" {
        server.document-root = "/usr/pkgsrc/packages"
}
...

In this directory, create a pkg_summary.bz2 file, where all packages, dependencies and descriptions will be available:

# cd /usr/pkgsrc/packages/All
# pkg_info -X * | bzip2 > pkg_summary.bz2

Then, on the machine to be upgraded, install pkgin :

# pkg_add -v ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/databases/sqlite3-3.6.17.tgz
# pkg_add -v ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/pkgtools/pkgin-0.2.5.tgz

And put your own repository in /usr/pkg/etc/pkgin/repositories.conf:

http://pkgsrc.home.imil.net/All

Update pkgin's database:

# pkgin up

And upgrade your packages:

# pkgin full-upgrade

There you go !

• Upgrading packages with pkg comp and pkg chk
• Using pbulk to create a pkgsrc binary repository
• Speeding up pkgsrc builds with ccache and distcc
• Distributing pkgsrc builds across different OSes
• Using clang with pkgsrc
• Debugging crashes in the Firefox package