I've finally got my kernel tree up on kernel.org. It took a couple of weeks to get an account, then a couple of weeks to find the time to worry about it.
http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=shortlog;h=drm-intel-next
git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
This should be the place where all of our future "ready for upstream" work goes. So, for example, if you're looking to test GEM, grab these branches:
kernel: drm-intel-next
libdrm: master
xf86-video-intel: master
mesa: master
If you're looking to test dri2, it's a little more work. Grab these:
kernel: drm-intel-next
libdrm: master
dri2proto: master
xserver: master (then edit hw/xfree86/Makefile.am to uncomment dri2)
xf86-video-intel: dri2
mesa: master
Monthly Archive for September, 2008
I’m leaving Padova for the next three months in less than 10 hours. Goodbye all!
It took a while, but registration for EuroBSDCon 2008 is now open!
As usual, there are many interesting talks and tutorials. Life was again "interesting" for the program committee!
For FreeBSD developers, there will be the usual by-invitation developer summit two days before the conference.
I would like to note that this will be the first non-FOSDEM conference I'm attending this year with only marginal impact on my carbon footprint.
I'm taking the train!
My dear friend flevour pointed out a mistake on my side in my GPG key, so I had to update it again. You find it on my GPG key page.
Sorry for the noise.
Here's an update in status to the FreeBSD/mips tree. David O'Brien has been working through issues one at a time to get things building, primarily getting gcc support merged in. After learning from David that more patches were needed than were in my blog, I spent some time collapsing changes from p4 into the main tree. I've updated my patches, and confirmed they work.
First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:
I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.
Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.
First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:
% svn update
% fetch http://people.freebsd.org/~imp/MipsSvn.diff
% patch -p0 < MipsSvn.diff
% setenv TARGET mips
% setenv MAKEOBJDIRPREFIX /tmp/$LOGNAME/obj
% make buildworld
% make buildkernel KERNCONF={ADM5120,IDT,MALTA,QEMU}
I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.
Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.
Every once in a while I get email asking for an option to pmcstat(8) that would allow hardware events to be measured for a specified time interval.
The good news is: pmcstat(8) already supports timed measurements — using /bin/sleep.
Here is how you would do it:
Timed system sampling would be done in the following manner:
% pmcstat -S instructions -O logfile /bin/sleep 42
This invocation allocates a system-scope sampling PMC (-S) and profiles the whole system while /bin/sleep executes, i.e., for 42 seconds.
Timed measurements on groups of processes are performed in a similar fashion:
% pmcstat -d -p dc-misses -t '1234' /bin/sleep 24
This invocation would allocate a process-scope counting PMC (-p) that counts data cache misses, attach it (-t) to the process with pid 1234 and its descendants (-d), and count for 24 seconds.
Note that the '-t' option also takes regular expressions, so you don't need to know process ids beforehand. To count instructions executed by processes named 'httpd' for an hour you would use:% pmcstat -p instructions -t 'httpd' /bin/sleep 3600
The "Unix way" uses small tools, each of which does a defined task reasonably well and which are combined to perform more complex tasks. In the examples above, /bin/sleep manages time intervals and pmcstat(8) manages PMC based measurements.
When you combine them, voilà, you get timed PMC based measurements.
For various reasons, I had to renumber the machine this blog (and a number of other things) run on. A pain, of course, but FreeBSD makes it fairly easy.
First, I shut down all the jails using /etc/rc.d/jail stop. I probably could have renumbered the jails too, but it was easier just to restart them.
I removed all IP addresses except for the one I was talking to, and added the new addresses:
# ifconfig hme0 89.106.240.243 -alias # ifconfig hme0 89.106.240.244 -alias # ... # ifconfig hme0 alias 89.106.240.146/28 # ifconfig hme0 alias 89.106.240.147/32 # ifconfig hme0 alias 89.106.240.148/32 # ...
I also put the new configuration in /etc/rc.conf so things will keep working after the next reboot.
After verifying that I could ping the new addresses from the outside (ie: that the router behaved as expected), I used a trivial little script to fix the routing table:
#!/bin/sh route delete default ifconfig hme0 89.106.240.242 -alias route add default 89.106.240.145 shutdown -r +10
The shutdown -r +10 is just for insurance. :-)
Of course, it just worked!
Then it was just a matter of updating DNS and restarting some services which were bound to the old address only instead of INADDR_ANY.
Unix rules!
Finally, I have been able to resolve all current known issues with cvsmode support in csup. I just sent out a new announcement with the patch, and I hope to get some more testing and perhaps some reviews soon, but it is a big patch and few people are familiar with the code base.
Remaining issues with the patch is support for using the status file when reading (but this is not critical at all), as well as rsync support (which is only significant for a few files in the freebsd repository).
I hope as many as possible are able to test it:
http://people.freebsd.org/~lulf/patches/csup/csup_09_16_2008.diff
I’m continuing to do some maintenance on the weekly PR emails, and the new prototype PR pages. The former are having their formatting fixed up and the boilerplate removed. The latter has been rewritten to group the reports by commnity of interest, and has also added PRs that have been modified in the last day/week/month; PR count by assignee; and latest commit by assignee.
In addition, the main pointyhat erorrlog page is now much more readable. A bugfix there has also helped portsmon get back up to date.
Finally, I’ve completely rewritten my home page on freefall, so that you can find the various projects that I am working on (including the above), the presentations that I have done at various BSDCan and EuroBSDCon conferences.
Fabien Thomas sent in a screenshot showing the result of his experiments at integrating KCachegrind and PmcTools.
Thank you Fabien, for sharing!
As part of the work we're doing for Moblin, I got our head trees in shape for GL compositing on GEM. We had a nice demo of the technology at XDS from krh, and today I got the same setup working: glxgears and totem on a cube all playing nicely together. It feels like things are finally coming together, and we'll be ready to support this stuff in releases soon, even if it won't be at the end of this release cycle.
All the code's in master, and available to test. The usual warnings about master apply, and just to show how serious we are about our in-development code, among the known issues are:
Can't do UXA (and therefore DRI2) with tiling.
It's kind of hard to teach X about tiled buffers. NVIDIA went with wrapping all pixel access from libfb to produce libwfb. Our plan is to return to GTT-managed access of buffers in the X Server so we don't have to teach it about this -- we keep the nice write-combined performance we're used to with framebuffer access, though we also suffer from painful read performance we're used to if we have fallbacks that read (See also: Render gradients and convolutions).
2D performance has tanked when you use UXA.
If you fallback on front buffer rendering with the X Server, GEM goes wild with cache flushing because the X Server isn't telling it just what memory it touched, yet we're telling GEM that the results need to land in the front buffer "soon". This means that compositing is fast, but non-composited isn't if you run emacs or gitk anything else that causes fallbacks. There are a couple of potential fixes for this, but the current plan is to avoid it using GTT mapping, which resolves the coherency issue.
Long term, we're going to be adding support for telling GEM what pages we touched after the fact (or maybe use fault-based clflushing) for OpenGL, and at that point we may reconsider how X maps its buffers.
3D performance has tanked in some cases
Haven't debugged this one, and it's next on the list. Can't reproduce on the test systems here.
Applications hang on to a lot of buffer objects
In TTM we would allocate giant buffer objects and then suballocate out of them, because allocation performance was so slow. This meant that userland had to pay attention to a lot of fencing issues (and you had to expose the idea of a fence) so that you could know which pieces were still used.
We went with a simpler model for GEM, where the userland caches buffer objects of similar size, and reuses them when the kernel tells us they're no longer used by the GPU. By returning "freed" buffers to the cache, we get wonderful performance when an app is running flat out and allocating and freeing buffers like mad. However, as we think about cairo moving to a GL backend, and all your apps sitting waiting for input hanging onto these cached buffers, the memory usage is likely to become an issue. They're pageable, but that's slow and we're looking at systems with limited memory+swap anyway. Instead, we need to free buffers when they're not serving any use in the cache. One way we're thinking about is on allocate, when a cached buffer is "really old" (seconds), actually free it.
That still leaves some excess memory laying around when an app does some rendering and then stops for input. The long-term solution would be for userland to tell the kernel when it wasn't going to actively use a buffer and the contents could be thrown out. Then, in the memory pressure callback from the kernel, we can throw out cached buffers and nuke mappings, and userland has to allocate new ones when it needs.
All the code's in master, and available to test. The usual warnings about master apply, and just to show how serious we are about our in-development code, among the known issues are:
Can't do UXA (and therefore DRI2) with tiling.
It's kind of hard to teach X about tiled buffers. NVIDIA went with wrapping all pixel access from libfb to produce libwfb. Our plan is to return to GTT-managed access of buffers in the X Server so we don't have to teach it about this -- we keep the nice write-combined performance we're used to with framebuffer access, though we also suffer from painful read performance we're used to if we have fallbacks that read (See also: Render gradients and convolutions).
2D performance has tanked when you use UXA.
If you fallback on front buffer rendering with the X Server, GEM goes wild with cache flushing because the X Server isn't telling it just what memory it touched, yet we're telling GEM that the results need to land in the front buffer "soon". This means that compositing is fast, but non-composited isn't if you run emacs or gitk anything else that causes fallbacks. There are a couple of potential fixes for this, but the current plan is to avoid it using GTT mapping, which resolves the coherency issue.
Long term, we're going to be adding support for telling GEM what pages we touched after the fact (or maybe use fault-based clflushing) for OpenGL, and at that point we may reconsider how X maps its buffers.
3D performance has tanked in some cases
Haven't debugged this one, and it's next on the list. Can't reproduce on the test systems here.
Applications hang on to a lot of buffer objects
In TTM we would allocate giant buffer objects and then suballocate out of them, because allocation performance was so slow. This meant that userland had to pay attention to a lot of fencing issues (and you had to expose the idea of a fence) so that you could know which pieces were still used.
We went with a simpler model for GEM, where the userland caches buffer objects of similar size, and reuses them when the kernel tells us they're no longer used by the GPU. By returning "freed" buffers to the cache, we get wonderful performance when an app is running flat out and allocating and freeing buffers like mad. However, as we think about cairo moving to a GL backend, and all your apps sitting waiting for input hanging onto these cached buffers, the memory usage is likely to become an issue. They're pageable, but that's slow and we're looking at systems with limited memory+swap anyway. Instead, we need to free buffers when they're not serving any use in the cache. One way we're thinking about is on allocate, when a cached buffer is "really old" (seconds), actually free it.
That still leaves some excess memory laying around when an app does some rendering and then stops for input. The long-term solution would be for userland to tell the kernel when it wasn't going to actively use a buffer and the contents could be thrown out. Then, in the memory pressure callback from the kernel, we can throw out cached buffers and nuke mappings, and userland has to allocate new ones when it needs.
This morning I had to go to the US Consulate in Milan to get the visa. I’m in Milan since Wednesday, hosted by Max Stucchi.
On Wednesday night, GUFIPizza took place: it’s the monthly meeting of the GUFI (FreeBSD Italian Users Group) members who live near Milan. Since I was there, other members who don’t usually show up showed up ( 
), Cris, _Oity_ and satu among the others. It was fun because I didn’t see some of them since 2 or even 4 years. We proved that geeks cannot speak about anything but computers when they meet, even when they don’t want to. That night, the main topic was Facebook. Anyway.
Yesterday I went to NewOldCamera and bought two Voigtlander-Cosina rings to mount my Leica screwmount lenses on my Leica M (actually CL) body and I even bought a Billingham L2 bag. It’s soooo well made. =)
Today is a raining day in Milan and I have neither an umbrella nor a jacket… 
I finally got around to updating these after having let them gather dust for a while. These include bar charts showing the time periods that various releases were being worked on (QA = Quality Assurance) and were supported by the FreeBSD security team. The dates for 6.4, 7.1, and beyond are all “best-guess”.
I find the graphs much easier to understand than the text-format descriptions in various emails.
The data are up at schedule.html.
FYI, I updated my GPG key.
I wrote a bit about one of my current projects for the FreeBSD Status report, unfortunatly due to some mixup it didn’t get included, so I’m posting the text here instead:
Recently NetApp donated one of their Filer storage systems and Sentex donated hosting of it with the FreeBSD Foundation helping with various administrative tasks. See the FreeBSD Foundation July 2008 Newsletter for details of the donation.As of this writing around 1 TB of data has been transfered to the off-site storage system and critical systems are being set up for periodic backup as time permits. The 1 TB includes the FreeBSD ftp-archive containing old FreeBSD releases which is being extra backed up to avoid loosing the history data for the FreeBSD project.
The actual backups are being done with rsync over ssh glued together by some custom scripts. As I’m not that creative with naming, the “system” is called qsbp or “Q Simple Backup Push”. File system snapshots are being used to preserve old data while still allowing a relativly simple system to be used.
On behalf of the the FreeBSD Admins Team, I would like to thank NetApp, Sentex, and the FreeBSD Foundation for making this possible.
The last week or so has show a spike up in FreeBSD embedded platform work. Fixes for mips and powerpc have gone into the tree. Support for a new ARM platform is getting ready to be committed. FreeBSD/mips is almost self-hosting in the svn tree (it has been in the p4 tree for some time). FreeBSD/powerpc and FreeBSD/arm continue to mature.
Thanks to a flurry of activity over the weekend by David O'Brien, the number of patches needed for FreeBSD/mips has been reduced to a set for libpam and for binutils. David cleaned up the diffs for gcc and pushed them into the tree in a manner that allows for easier upstream committing.
In addition, David has cleaned up a number of dangling nits in the build. This is the result of a slight mismatch between p4 and the code in FreeBSD's svn tree. Oleksandr Tymoshenko has looped back most of these changes into p4, and is working on resolving the conflicts that were generated. Once this is sorted out, Oleksandr or myself will generate a new set of diffs and go for the final push into the tree.
I'm looking forward to having a good base for FreeBSD/mips in the tree. I've been busy with a number of other projects and haven't given it the time that I really want to give.
On the PowerPC side of the ledger, Marcell Moolenaar and Rafal Jaworowski have been polishing uboot boot loader support in the FreeBSD/powerpc subversion tree. In addition, some bug fixes to and code polishing of the low level Book E PowerPC support have been committed. Many of these improvements were obtained from Semihalf consulting.
On deck to be committed soon is support for Marvell's Orion NAS chips. This code has been in perforce for a while now and is nearly ready for the FreeBSD tree. I'll keep everybody posted when that happens. I hope to have my DLINK DIR-615 Rev A1 working by then with this code, but time has been tight and there's already too many different projects afoot in my life.
Thanks to a flurry of activity over the weekend by David O'Brien, the number of patches needed for FreeBSD/mips has been reduced to a set for libpam and for binutils. David cleaned up the diffs for gcc and pushed them into the tree in a manner that allows for easier upstream committing.
In addition, David has cleaned up a number of dangling nits in the build. This is the result of a slight mismatch between p4 and the code in FreeBSD's svn tree. Oleksandr Tymoshenko has looped back most of these changes into p4, and is working on resolving the conflicts that were generated. Once this is sorted out, Oleksandr or myself will generate a new set of diffs and go for the final push into the tree.
I'm looking forward to having a good base for FreeBSD/mips in the tree. I've been busy with a number of other projects and haven't given it the time that I really want to give.
On the PowerPC side of the ledger, Marcell Moolenaar and Rafal Jaworowski have been polishing uboot boot loader support in the FreeBSD/powerpc subversion tree. In addition, some bug fixes to and code polishing of the low level Book E PowerPC support have been committed. Many of these improvements were obtained from Semihalf consulting.
On deck to be committed soon is support for Marvell's Orion NAS chips. This code has been in perforce for a while now and is nearly ready for the FreeBSD tree. I'll keep everybody posted when that happens. I hope to have my DLINK DIR-615 Rev A1 working by then with this code, but time has been tight and there's already too many different projects afoot in my life.
Translations of technical documentation from English to Greek are a relatively difficult task. It takes a certain level of attention to detail and a fairly good command of both languages. Then there is the minor issue of keeping the translations up to date with their English counterparts.
Updating translations (the old style)
We have a growing body of translated work at the FreeBSD Greek documentation project team, and it was getting rather unwieldy going through each file manually and checking if there are updates in the English version that we would like to pull out of CVS, translate from scratch or re-translate, and commit to our main translation tree. Back when I started writing the original Greek translation build glue, I copied a tagging scheme used by existing translations that was helpful for this sort of manual check. Each translated file had a comment of the form:
<!-- Original revision: 1.17 -->
When looking for updates, one had to manually perform the following steps for each file in the doc/el_GR.ISO8859-7/ directory:
- Check if the file includes an “Original revision” comment.
- Extract the revision number from that comment, and note it down somewhere.
- Make an educated guess about the pathname of the original English text. Some times the path is easy to guess by substituting el_GR.ISO8859-7 with en_US.ISO8859-1 in the file’s path name. Some other times, it isn’t so easy (especially for files in the el_GR.ISO8859-7/share directory).
- Locate the
$FreeBSD: ... $line in the original English text. - Compare with the saved revision from the comment of the Greek text, and see if there are updates to translate.
There are just five steps for each file in this checking process. When translated files are just a bunch of articles, and a few makefiles, it’s boring to repeat these steps for each file, but it isn’t so difficult that nobody can do it. Now that we have Greek translations for a large part of the FreeBSD Handbook, and I am a bit more pressed for time, manually performing these steps for each file of the Greek translation tree started becoming very difficult to do in a timely manner.
New tools (checkupdate)
This was the main reason for writing the checkupdate script. With a lot of help from Gabor Pali, one of the committers who work for the Hungarian FreeBSD translations, I wrote a Python script called checkupdate and designed a tagging scheme that would make this part of the translator’s work much easier. We started by defining how a translator can “tag” a translated source file with the revision of the last fully translated English version. The idea we came up was:
Each translated file will contain a pair of tags called “
%SOURCE%” and “%SRCID%“. The%SOURCEtag will point to the relative path of the English text under the doc/ tree. The%SRCID%tag will refer to the last fully translated revision of the%SOURCE%file.
An example for one of the translated Greek articles is:
$ pwd /ws/bsd/doc $ head -10 el_GR.ISO8859-7/articles/new-users/article.sgml <!-- $FreeBSD: doc/el_GR.ISO8859-7/articles/new-users/article.sgml,v 1.4 2008/01/14 14:19:42 keramida Exp $ ??? ??????? ????? ???? ??? FreeBSD ??? ??? ??? Unix The FreeBSD Greek Documentation Project %SOURCE% en_US.ISO8859-1/articles/new-users/article.sgml %SRCID% 1.24 $
Then we wrote a Python script that can “parse” the %SOURCE% and %SRCID% tags, look up the CVS (or Subversion) revision number of the original English text, and report any differences. The “interface” of the script was quite simple: a list of filenames is fed to the script through standard input, and it assumes they are relative pathnames under the top of a doc/ checkout. This way, to check all the files of the Greek translation one would run:
$ pwd /ws/bsd/doc $ find el_GR.ISO8859-7 | checkupdate
To check multiple translations trees at once it would be possible either to loop through the translations:
$ pwd
/ws/bsd/doc
$ for dname in el_GR.ISO8859-7 mn_MN.UTF-8 hu_HU.ISO8859-2 ; do \
find "${dname}" | checkupdate ; \
done
or just pass their names directly to find:
$ pwd /ws/bsd/doc $ find el_GR.ISO8859-7 mn_MN.UTF-8 hu_HU.ISO8859-2 | checkupdate
The first version of the script tried to include as much information about each translated file as possible, so it used a relatively verbose output format. This is the default output format even today. For the current version of the el_GR.ISO8859-7 translation tree the checkupdate script output includes the following:
$ find el_GR.ISO8859-7 | checkupdate
el_GR.ISO8859-7/articles/Makefile rev. 1.16
1.39 -> 1.60 en_US.ISO8859-1/articles/Makefile
el_GR.ISO8859-7/articles/laptop/article.sgml rev. 1.4
1.9 -> 1.25 en_US.ISO8859-1/articles/laptop/article.sgml
[...]
Gabor (pgj) later added an option for compact output, because he likes seeing one line of output for each file. The compact mode is enabled with the -c option of the checkupdate script:
$ find el_GR.ISO8859-7 | checkupdate -c 1.39 -> 1.60 el_GR.ISO8859-7/articles/Makefile 1.9 -> 1.25 el_GR.ISO8859-7/articles/laptop/article.sgml [...]
The checkupdate script has now been committed to the FreeBSD doc/ tree in CVS, and it includes a short manpage too. The script and manpage sources are browsable online at:
http://cvsweb.freebsd.org/doc/el_GR.ISO8859-7/share/tools/checkupdate/
Updating translations (new style)
Using the checkupdate script and a CVS checkout of the doc/ tree is much easier now. I usually open two side-by-side terminals, and keep running CVS diff commands in one of them and checkupdate in the other. A typical MFen session for one of the Greek articles includes:
- Picking one of the translated files to update, from the output of
checkupdate. For this example, let’s assume I want to update the laptop/article.sgml file. -
Running “cvs log” and “cvs diff” in the second terminal window, to look at each change committed in CVS:
$ cvs log -r1.9:1.25 en_US.ISO8859-1/articles/laptop/article.sgml | more $ cvs diff -r1.9 -r1.25 en_US.ISO8859-1/articles/laptop/article.sgml | cdiff
- If the diffs seem to large to translate in one go, I may opt to translate each CVS change as a separate piece. The FreeBSD doc committers try to keep content and indentation changes separate, so it is often the case that translating revision 1.9 (a content change) as a standalone change is a lot easier than trying to decipher what changed between 1.8 and 1.10 (because revision 1.10 rewrapped and reformatted lots of text and it makes looking for the content changes of 1.9 unnecessarily hard).
-
Looking at only one revision of a file is slightly boring in CVS, but not really tough:
$ cvs diff -r1.8 -r1.9 en_US.ISO8859-1/articles/laptop/article.sgml | cdiff
- When the translation of revision 1.9 is done, I commit it to the Mercurial tree I am using for local work, taking care to update the
%SRCID%comment in the file to show that it is now synchronized with English revision 1.9. - Some time later, a bunch of changes are pushed to the main Mercurial tree at http://hg.hellug.gr/freebsd/doc-el/.
Recent updates
aUsing the checkupdate script and the CVS diff commands described so far, I merged from the English text a fair number of updates since last night. The commit email started tricking in late at night, when I extracted the patches from my personal Mercurial tree and committed them into CVS:
2008-08-31 [ 29: Giorgos Keramidas ] cvs commit: doc/en_US.ISO8859-1/books/developers-handbook/policies chapter.s$ 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/share/sgml mailing-lists.ent 2008-09-01 [ 15: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/share/sgml freebsd.ent 2008-09-01 [ 14: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/books Makefile.inc 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/releng extra.css 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/books/handbook/jails chapter.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/books/handbook/jails chapter.sgml 2008-09-01 [ 15: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 13: Giorgos Keramidas ] cvs commit: doc/en_US.ISO8859-1/articles/dialup-firewall article.sgml 2008-09-01 [ 14: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 15: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 14: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 14: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-01 [ 14: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/dialup-firewall article.sgml 2008-09-02 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/books/handbook colophon.sgml 2008-09-02 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/freebsd-questions article.sgml 2008-09-02 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/freebsd-questions article.sgml 2008-09-02 [ 13: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/freebsd-questions article.sgml 2008-09-02 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/freebsd-questions article.sgml 2008-09-02 [ 12: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/freebsd-questions article.sgml 2008-09-02 [ 14: Giorgos Keramidas ] cvs commit: doc/el_GR.ISO8859-7/articles/freebsd-questions article.sgml
The number of commits looks scary, but in reality this was only because I was experimenting with separate MFen commits of each English revision.
In retrospect, this may not be a very good idea. We don’t really need *all* the English versions translated in CVS (some may be broken, others may be intermediate commits, or may be missing some bits). It doesn’t make sense to include all the false starts of the English docs in the el_GR.ISO8859-7 tree too. So the last two commits to CVS included a bunch of English revision merges in “collapsed” form:
keramida 2008-09-02 13:56:43 UTC
FreeBSD doc repository
Modified files:
el_GR.ISO8859-7/books/handbook/virtualization chapter.sgml
Log:
MFen: 1.11 -> 1.13 en_US.ISO8859-1/books/handbook/virtualization/chapter.sgml
Revision Changes Path
1.5 +9 -4 doc/el_GR.ISO8859-7/books/handbook/virtualization/chapter.sgml
keramida 2008-09-02 13:57:41 UTC
FreeBSD doc repository
Modified files:
el_GR.ISO8859-7/books/handbook/virtualization chapter.sgml
Log:
MFen: 1.13 -> 1.17 en_US.ISO8859-1/books/handbook/virtualization/chapter.sgml
Revision Changes Path
1.6 +198 -3 doc/el_GR.ISO8859-7/books/handbook/virtualization/chapter.sgml
I think I like this commit style a bit better, and after a short discussion in the mailing list of the translators, Manolis seems to like this style too.
