pm2fb

pm2fb* at pci?

This is a kernel driver for Permedia 2 and 2V graphics controllers. It was written specifically for the Sun PGX32 card on ?sparc and ?sparc64, it hasn't been tested on any other hardware as far as I know. It does support basic acceleration ( scrolling and rectangle fills ) but characters are still drawn by software and there is no support for setting video modes, the driver depends on device properties to tell it what video mode the firmware set up. This should work on other OpenFirmware platforms which have code in place to translate OF properties into device properties - namely ?macppc - but this is untested and I don't know if there are any Permedia 2 based graphics cards for Power Macintoshes anyway.

igs

A basic driver for IGS CyberPro 2010 graphics controllers. Currently it only supports the VLB variant found in Rev. 5 ?sharks, adding support for PCI variants is trivial though and will be done if I ever get my hands on a ?netwinder or something similar. The driver supports basic acceleration via ?EXA ( screen-to-screen blits, rectangle fills and off-screen memory ), it relies on igsfb for mode setting and hardware cursor support.

BUGS The driver needs

Option "MigrationHeuristic" "greedy"

otherwise some anti-aliased text won't show up. No idea why, since the hardware has no support for alpha-blending the driver makes no attempt to accelerate any of it.

igsfb

igsfb* at ofbus?
igsfb* at pci?

This is a kernel driver for several IGS graphics chips, namely the 1682 found in the JavaStation 10 and the CyberPro 20x0 family found on ?shark and ?netwinder mainboards. Acceleration is supported for CyberPro chips. The driver supports the usual wscons features like colours, virtual consoles etc. and it accepts mode specifiers via device properties. On ?shark Sun-like mode specifiers can be put into the output-device OpenFirmware variable, machine-dependent code will extract it and pass it to igsfb which will try to switch to this mode. If no mode is specified it will default to 1024x768 in 60Hz. Only modes listed in sys/dev/videomode/modelines can be used.

In order to have a Rev. 5 ?shark switch to 1280x1024 in 60Hz one would:

setenv output-device screen:r1280x1024x60

in OpenFirmware, or something equivalent using the eeprom command.

put FAQs or discussion point collections for mailing lists @NetBSD.org below this point.

tech-repository

Requirements

A list of requirements for a possible replacement for CVS as repo software for NetBSD and pkgsrc so we don't keep starting over listing these (and forgetting half) all of the time:

• the license would be nice to be BSDish, must be open source and free to use
• the software should be includeable in NetBSD base without too much excess baggage
• it should be possible to do development on old or small hardware
• it must support automated updating of source trees
• it must support branches
• there should be a conversion for the present history (that actually works)
• the resulting repository must not break easily
• the software should be reasonably mature and reliable
• checkout of a pkgsrc tree must be feasible on a 32MB system
• checkout of a stable pkgsrc tree and then updating select package subdirs to the latest version of the main branch should be possible
• lasting removal of legally tainted code must be possible

Please add/correct.

---

Experiences in using the software

Experiences with Fossil

Aleksej Saushev (asau)

I started using it before conversion tool were available (basically it isn't available yet, to my knowledge Joerg is working on it), in addition I wanted to start as soon as possible and to try operation with no conversion tool available. Thus I've tried to simulate working with "vendor branches".

For now Fossil lacks some essential features and has other severe problems:

1. Many operations require javascript-capable web browser.
2. No support for vendor branches.
3. Redundant to "There's no support for importing vendor source"?
4. No, it is different. I would import manually, if only some support were there.
5. It is impossible to merge between trees growing from the very root. The initial commit is too special, this prevents using these trees for vendor branches.
6. Fixed in [4e3cd6ce4e].
7. 2010-11-08, not in pkgsrc.
8. There's no support for importing vendor source, even "addremove" command isn't in trunk at the time of writing.
9. It has been merged to trunk and is part of the pkgsrc version.
10. No, it isn't part of pkgsrc version at the moment, TIAS.
11. Sorry, you are right. Merged to trunk in [ceab53718f].
12. Merge state sticks. You can't undo it.
13. Not sure what you mean, but "revert" resets the merge state since [d13054ce84].
14. This is quite recent (late October) fix, I didn't check it.
15. You can't amend your source when you've just merged, you are forced to commit after merge.
16. To clarify, the merge has to be committed first, no separate commits are possible from the checkout before that.
17. In practice this makes critical defect in combination of "fossil diff" inability to generate difference for added files.
18. You can't tune diff command to ignore RCS keywords.
19. Since RCS keywords are not really a native command, it is no surprise. An external diff program can be used for this purpose though.
20. Since there's no external diff program that supports it, it is really not quite easy.
21. You can't diff single file between two given versions.
22. diff --from version1 --to version2 path/to/file
23. That didn't work, and I'm not sure it works now. It used to ignore path-to-file argument. (It used to bail out when both "--from" and "--to" were used.)
24. There's no way to change commit messages.
25. easily done via ui: select a commit and under "Other Links" you can find "Edit" (given the necessary permissions).
26. How? It should be possible via command line nevertheless.
27. There's no documented way to select commit messages of current branch, or branch by given commit id. Or there's a bug preventing it.
28. fossil info
29. This isn't about "info" command, it is about "timeline" --> Please clarify what you mean.
30. BTW, this command doesn't support "-R" flag, perhaps you have to check the source out to use it.
31. Commands are under-documented, usage messages don't list many available options. This applies to trunk at least, there's a branch that states documentation as its goal.
32. There's no convenient way to look at commit contents: files affected, diff.
33. fossil ui and use a web browser
34. We don't have web browser in base system, this information should be accessible with command line.

Some of above problems are reported.

Note, all problems above are usability problems, I didn't explore e.g. scalability, Joerg did and had problems, but this is another story.

Experiences with git

Experience with the imported repositories on morden:

• no problem in principle with the smaller modules like othersrc or htdocs (CVS tags are one off but that is expected)
• the large repos are really fragile, and gits idea of how to fix a broken repo seems to be to retrieve a copy from someone/somewhere that happens to not be broken

Experiences with Subversion

please fill in

Experiences with Bazaar

Jonathan Perkin (sketch)

We use bzr at work (MySQL), and while it has a number of problems, it does make dev work easy.

The Good

• easy to use
• shared repositories keep local disk usage down
• commercial backing (Canonical)
• cross-platform (works on Windows)
• numerous GUI available

The Bad:

• slow
• requires python

The Ugly:

• can be really slow
• changing repository formats is a hassle

A basic example workflow

# create a local shared repository. all objects are held in a .bzr sub-directory, with branches essentially a lightweight checkout
$ bzr init-repo bzr
$ cd bzr

# fetch HEAD, will take a long time, depending on connectivity
$ bzr branch bzr+ssh://bzr.netbsd.org/netbsd-trunk

# fetch netbsd-5, as we already have the majority of the code in netbsd-trunk (and therefore .bzr), this takes a fraction of the time
$ bzr branch bzr+ssh://bzr.netbsd.org//netbsd-5

# ok, let's do some dev work
$ bzr branch netbsd-trunk netbsd-trunk-sketch-fix-msk
$ cd netbsd-trunk-sketch-fix-msk; hack hack hack

# the usual cycle of hack/commit/merge
$ bzr diff # show uncommitted diffs
$ bzr commit # commit to local clone
$ bzr merge ../netbsd-trunk # update clone to latest local trunk, OR
$ bzr merge bzr+ssh://bzr.netbsd.org/netbsd-trunk # merge directly from upstream

# publish our tree for others to review/hack on
$ bzr push bzr+ssh://bzr.netbsd.org/netbsd-trunk-fix-msk

# got reviewed/tested, let's push it
$ bzr merge bzr+ssh://bzr.netbsd.org/netbsd-trunk
$ bzr missing bzr+ssh://bzr.netbsd.org/netbsd-trunk # show changeset differences
$ bzr push bzr+ssh://bzr.netbsd.org/netbsd-trunk

I personally find this approach a lot more natural than git's way of managing branches itself inside a single working directory.

---

Conversion

fossil

We have a successful conversion from cvs to fossil since ~mid 2011, mostly thanks to the work of Jörg Sonnenberger. See github for more details.

git

We have a successful conversion to git via the fossil conversion; also, probably now a successful direct conversion via the tools by Eric S. Raymond. See github for more details.

hg

A conversion to hg has also been done, ask agc@