Funny how working on a program immediately inspires to do more. Remember that the initial motivation for debtree was to find out why a package was installed? It can now show that in the dependency graphs! I'm not quite ready to do a new release, but the new version is available from the git repository. Let's start with a simple example (all graphs are based on Lenny).

$ debtree -I --rdeps-depth=3 apt

Only installed packages are displayed here; if the -I option is omitted, debmirror will display all, but that does tend to explode the graphs, especially for common libraries. As for forward dependencies, the color of the arrows indicates Pre-Depends, Depends and Recommends. The reverse dependencies are shown three levels deep (one is default). The graph will always include all direct reverse dependencies (both on the package itself and all virtual packages provided by it. For indirect reverse dependencies there's a cut of that is set at five by default. Example is debconf, that apparently has 9 reverse Pre-Depends and 58 reverse Depends installed on my system. The next one is simply beautiful.

$ debtree -I --rdeps-depth=20 --no-conflicts libcairo2

Because of the --rdeps-depth=20 this shows the full recursion! I was surprised that this graph remained a reasonable size. Apparently no packages depend on the virtual package libcairo, at least none that I have installed. The final one is extreme, and I must confess that I have cheated a bit by suppressing the least interesting reverse depends (which explains why it does not match the numbers from the apt graph).

$ debtree -I -R --no-recommends --no-conflicts debconf

The most interesting thing here is how it shows the debconf-2.0 transition. Most packages depend on 'debconf debconf2.0'; tex-common instead has 'debconf cdebconf', while tasksel and exim4 have both combinations (probably one explicitly in debian/control and the other added by debhelper. ucf is missing the alternative; apparently does not use debhelper (no prizes for guessing who the maintainer is :-). Notice anything about iamerican and ibritish? Yes, they really have a double dependency on 'debconf debconf2.0'. The one thing missing is the version info for versioned dependecies. Not sure yet if I want to add that for reverse dependencies. P.S. SVG versions of the images are available in the same directory as the JPGs.

1.1.14 is definitely worth blogging about. While I was updating the gtk-doc stuff to update the documentation that is available in our website I was thinking that this is probably the release with the largest amount of API addition I have seen in my time as a contributor to the project! Before I start talking about the new APIs, though, let me talk of something that went under the hood: Xan has patched WebKitGTK+ to override libsoup s connection limits, so that our limits match those of other modern browsers - we now allow up to 60 connections total, and 6 per host. People have been reporting load performance improvements for some sites! We have an initial set of APIs to deal with the data that was loaded to render the page, represented by the new DataSource object. This allows you to peek at the source of the HTML that was rendered, for instance. In the near future we will have ways of getting the data and other information for each resource that is downloaded to compose the page. Jan Alonzo has spent quite some time studying, implementing and perfecting this API, with some help from me and Xan. One initial piece of the larger API to control resource loading is already there, as well. The WebView will use the new resource-request-starting signal to let you know that a request is about to be sent, and allow you to modify headers, or even the URI that is going to be fetched. For some, the greatest news here is that this allows a basic implementation of AD blocking, which is now supported in Epiphany with the WebKit backend, as of version 2.27.92, released today! This is something I have been looking at in my Collabora time for some time now, and working along with Xan and Jan, we finally seem to have figure out the API interactions correctly. There s more to come regarding resource loading tracking, in the near future. That would already be a lot, from my point of view, but there s a whole lot more. A new contributor, Martin Robinson, has arrived proposing new API pieces for an important HTML5 tool: web databases, which brings with it the concept of SecurityOrigin. Jan has exposed API to put the WebView in view source mode, Xan has given us undo/redo support for editable content, and Zan Dobersek has done some overall improvement of our HTML5 media player. That s a lot of change for a release, which also goes to show we still have quite a gap to fill, but we are being able to move forward and fill them quite quickly. If you want to help out, pick something in your area of interest, and send us patches!

Gammu 1.26.1 is out! This release just fixes few bugs in AT driver. Full list of changes:

• CPIN reply is handled like regular one except in A2D case (bug #994).
• Fix finding first empty position when memory is empty (bug #996).
• Fixed parsing of SMS status reports.
• Fixed parsing of text messages with new lines (bug #995).

You can download from usual place: http://cihar.com/gammu/. Debian users will find packages in unstable soon, SUSE, Fedora and Mandriva users can check repository in OpenSuse Build Service and Ubuntu in my PPA.

A bit more than two years ago, two young Spaniards on vacation in Latvia maybe went a bit too far during one of their night parties and decided to remove some Latvian flags that hanged from a post in the streets of Riga. They spent 1 month in prison, with charges for outraging the Latvian flag. The Spanish media talked about the disproportionate charges, the ridiculous and medieval laws in Latvia and so on. Today, we learn that Jaume d'Urgell will go to prison due to the outraging crime of substituting the current Spanish flag with the Republican flag of 1931 on the facade of a public building. So much for medieval laws and institutions like the Spanish monarchy.

I wanted to renew my key for what seems as eternity, and finally I ve done it, didn t even want to participate in keysigning party on DC9 for the same reason. So here s my RSA 4096 bit replacement for my old 1024 DSA.

pub  4096R/2D516C09 2009-09-07
Key fingerprint = 6878 DFA1 A95C 3D55 713F  42B1 EE0E 2790 2D51 6C09
uid  Adnan Hodzic (AbsintheSyringe) <adnan@foolcontrol.org>
uid  [jpeg image of size 3877]
sub  4096R/E3FBC33A 2009-09-07

We ll see how/when will I get it signed, even though I got some basic idea how we can start doing it remotely

It wasn't too long that Kim Clijsters retired from Tennis, with Justine Henin following her not too long after that. At that point, with the next best player, Kirsten Flipkens, being ranked a hundred-something, I thought it'd be a long time before we'd see Belgian women's tennis reappear. Certainly I didn't think we'd be hopeful this year already. As such, I'm delighted to be able to say that not only is Kim Clijsters making a smashing come-back already beating Venus Williams, ranked 3rd on the WTA lists, at the US open, and only a few months after her returning to tennis at that but Yanina Wickmayer, ranked 50-something on the WTA lists by now, has managed to reach the last 16 players. With Kirsten besting her career record by reaching the 3rd round of the US Open (before being ousted by Kim, no less), I feel the future of Belgian Women's tennis is looking very bright indeed. Perhaps I should think about getting that cable subscription, so I can actually watch the matches.

There is currently a discussion on a private mailing list about whether some money from a community organisation should be used to assist the development of Gnash (the free software Flash player) [1]. The main reason for this is that there are apparently some schools that depend on flash web sites to such a degree that they won t consider using a free OS that lacks Flash support. It has been shown that there are a number of issues related to contributing financially to free projects, the people who advocate financial contributions in this case assure us that such problems have been addressed but it will remain controversial to some extent. One thing that is not controversial is the fact that testing and debugging is universally a good thing. So I advocate doing such testing as a way to contribute to Flash development and therefore free software use in education. The Debian-Edu project has a web page with a link to flash sites that can be used for testing [2]. So I plan to now install Gnash on all Linux desktop systems that I run and get bug reports to help development. I encourage others to do the same. Also there is the Ming library for developing Flash files which could apparently do with some help in the development process [3]. While a non-free format such as Flash is not ideal, it s certainly a lot better than Silverlight! Note that I don t have strong feelings about the issues of financial support for Gnash (which is why I didn t contribute to the private discussion in question). But I am convinced that more people using and testing Gnash is a good thing.

• [1] http://en.wikipedia.org/wiki/Gnash
• [2] http://wiki.debian.org/DebianEdu/FlashInDebianEdu
• [3] http://www.libming.org/

Some people seem to believe that the problem with copyright law is the inability of people on the free culture side of the debate to compete with the large amounts of money that are being spent but the RIAA et al. I think that a significant part of the problem is that many intelligent and well-meaning people are simply unaware of or unconvinced by the arguments. For example the Reid Report post titled Paul Porter speaks truth to Black radio [1] includes the quote Only the United States, North Korea and Iran don t pay royalties for performers on free AM/FM radio . This point actually sounds quite reasonable and will convince many intelligent and well-meaning people who have an interest in politics such as Ms Reid. Cory Doctorow has written an interesting article titled Internet rapshoot: How Internet Gatekeepers Stifle Progress [2]. He describes how the big entertainment companies are failing to properly represent their customers or the artists who produce the content, and in the process creating monopolies out of companies such as Apple and Google. Cory starts by raising the issue of cultural discourse, monopolies in the distribution of popular art will lead to control over the political process. Ironically the article that Ms Reid cited [3] mentions the issue of pay for play which led to a steady diet of misogyny, violence and drug culture on the airwaves. Brendan Scott has written about a similar issue in Australia where the music copyright holders are trying to get massive increases in license fees from restaurants and other small businesses [4]. The expected result of this is greater use of classical music (which is out of copyright) and more interest in purchasing licenses from small musicians who aren t affiliated with the music cartels. One of his main points is that playing music in public places (including public radio frequencies) is the major form of advertising for musicians. Michael Tiemann writes about a Brazilian band that has been quite profitable by skipping the recording industry, providing the fans what they want, and selling CDs direct to fans [5]. This is one of many examples to illustrate the fact that the current music factory system is not required for musicians to make a profit. Amanda Palmer has written an interesting blog post about how the Warner music group wasn t getting as much money from Youtube as they wanted so they demanded that HER music videos be removed [6] (among many others). So we have a music studio that doesn t even pay the artist (below a certain number of sales the artist gets no payment, selling 30,000 albums is not enough to get a cent) demanding that the music videos be made unavailable to fans when the artist wants them published. This is a travesty and if similar licensing schemes are implemented for radio stations then we can expect that some radio stations will be financially discouraged from playing music even when the artist would be happy to have it played for free! In Australia we have an organisation that secretly taxes all viewing of material that they think is under copyright with a suitable license (they give no detailed information on how they determine the copyright and license status they probably violate my license by taxing universities for copying posts from my blog). Educational institutions and other organisations that sign up get to pay them some money based on what they are deemed to have used. The money is then distributed to the creators in proportion to the amount of use their material received. The distribution rules state that any amount less than $50 per year for an Australian resident or $200 per year for a non-resident will be instead redistributed to other people [7]. Usually analysis of The Long Tail [8] comprises the majority of the sales if users are given enough opportunities to search for a product that is a good match for their requirements. This is the entire basis of businesses such as Amazon.com. The Australian Copyright Agency (Copyright Agency Limited CAL) seems to have a business model of taking all the revenue that might be earned by the creative people in the long tail and give it all to the top performers. If a similar system was implemented for the US music industry then it would be great for Michael Jackson s estate, but bad for the vast majority of musicians. It seems likely to me that the current situation with the music industry is fairly optimal for making a few very popular musicians very rich. The proposed changes for the US will make things even better/worse (depending if you are among the rich few or the majority of the population). One thing we need to ask ourselves is whether we want laws that will make a few people rich or laws that will give many people an adequate income for work they enjoy and which also enriches our culture. This correct decision seems obvious to me. Can anyone think of other good points that should be raised when discussing such issues with people who don t consider copyright to be a big issue?

• [1] http://blog.reidreport.com/2009/06/paul-porter-speaks-truth-to-black-radio.html
• [2] http://www.internetevolution.com/document.asp?doc_id=178058
• [3] http://ebonyjet.com/culture/index2.aspx?id=13434
• [4] http://brendanscott.wordpress.com/2009/06/15/artists-should-pay-cafes/
• [5] http://opensource.org/node/444
• [6] http://blog.amandapalmer.net/post/66586355/the-man-strikes-again-youtube-wars
• [7] http://www.copyright.com.au/assets/documents/distribution_rules_0809.pdf
• [8] http://en.wikipedia.org/wiki/The_Long_Tail

Yesterday's upload of RQuantLib 0.3.0 contained one minor oversight: I had failed to update src/Makefile.win to the new and enlarged set of source files. The proper fix (of using wildcards and implicit rules) was simple, and Uwe Ligges kindly rebuilt RQuantLib on the Windows builder for CRAN using an updated Makefile so that binaries for Windows will be available. This fix will also be in the next upload. Should you need it in the meantime, here is a link to the new version directly from SVN.

Hello, The DebConf10 local team would like to announce availability of visa information at http://debconf10.debconf.org/visas.xhtml Full information is contained at that page, provided by our lawyer; however some important points are indicated below. - The United States depends on its tens of millions of visitors annually for its economy to function. Getting approved for a visa is not a rare exception, and it is even easier given our generous free help from an immigration lawyer. - If you are from a Visa Waiver Program country (see visa page), fill out the ESTA web form to apply for your travel authorization now. You don t need any information about the conference itself or your means of travel. - If you will need to apply for a visa, check the visa information page for information on what to do. Carefully check the wait times for your country s embassy. For most countries there is no *immediate* urgency, but plan to get an appointment well in advance of May 2010. - Make sure you will have a passport that will expire in February 2011 or later (6 months after the latest possible DebConf date). If not, apply for a new passport. Special note to Venezuelans: Since the wait time for a visa appointment in Caracas is so long, we have been paying special attention to its visa application process. We have reports that the dates for visa appointments are moving quickly, getting later and later. If you are are applying for a visa in Caracas, you need to make an appointment immediately. You just need to make an appointment now, supporting materials can be assembled later. Also consider applying for a visa in a different US embassy such as the Quito, Ecuador one with a significantly shorter wait time. Consult with our lawyer for advice on the advantages and disadvantages of doing this. The local team hopes that everyone interested can meet us in New York City and have a great DebConf10 experience! Feel free to email us (publicly archived list) or ask in #debconf-team or #debconf-nyc on OFTC with your questions or ideas. - The DebConf10 Local Team

I finalised the initial upload of the ISC DHCP 4.1.0 packages a couple of days ago, and it sat in NEW, because I've renamed the source package (no more dhcp3). Today it was ACCEPTed into experimental. (Kudos to the ftp-team for their quick processing of NEW) It should deal with upgrading from dhcp3-client or dhcp3-server to the newly-named equivalents, at least for the common cases. The rest will come out in the wash (which is why it's in experimental). Thanks also to AJ for letting me NMU ifupdown twice to sort out some problems with the way it invokes /sbin/dhclient (thinking it's the v2 client) as opposed to /sbin/dhclient3. I think the criteria for uploading to unstable will be:

• no egregiously bad issues uncovered by testing in experimental
• the LDAP patch for the DHCP server is sorted out
• bugs are filed, where needed, for consumers of the DHCP client to do the right thing (invoke it correctly as /sbin/dhclient instead of /sbin/dhclient3)

8 RC bugs in 8 days I got back from vacation about 10 days ago. For the first time in recent years, I've spent 2 weeks of vacation mostly without email (excluding 2 "breaks" of 10 minutes each in an internet point, just to verify that my electronic world was not collapsing). The net result is that I feel very recharged and more productive both at work and for other tasks. Including Debian. Hence, during last week, I've tried an experiment. When during the day I feel bored about a given task, instead of reloading compulsively the page of an online newspaper, instead of checking (once more) my email, instead of checking (once more) my feeds, I try to fix an RC bug. For the first week, the result has been encouraging: one RC bug fixed per day (on the average, some day I haven't fixed any, some other 2 or 3):

• 30/08/2009 bug #543067 - mergelog - tell autoreconf to install missing files (i.e., pass "-i")
• 31/08/2009 bug #536971 - mergeant - add missing build-dep, thanks kibi for the triage
• 01/09/2009 bug #521937 - gplanarity - add missing build-dep, thanks peter green for the triage
• 02/09/2009 bug #537010 - gspot - add missing build-dep and CFLAGS/LIBS on libgnomeui
• 03/09/2009 bug #536955 - gnubiff - patch configure.ac to add libgnomeui CFLAGS/LIBS
• 04/09/2009 bug #536934 - xnee - patch configure.in to add libgnomeui CFLAGS/LIBS
• 05/09/2009 bug #537033 - hspell-gui - patch configure.in to add libgnomeui CFLAGS/LIBS
• 06/09/2009 bug #537030 - gnome-photo-printer - add missing build-dep on libglade2-dev

In some sense, this try to be kudos to the amazing initiative of Sesse, a few releases ago (or was it Lenny? my memory still sucks, no matter how recharged I feel). He has been fixing one RC bug a day for several months. I'm quite sure I won't be able to deliver the same result, but maybe this post will motivate other people, so that collectively we can fix a handful of RC bugs per day. Of course in the beginning it's easy, because there are a lot of "simple" bugs to fix and also because (as you can notice in the list above) "clusters" of similar RC bugs, that require similar fixes, can be identified. But the effort is useful nevertheless, since it cleans up RC bug list enabling more capable people to fix more resistent bugs. I'm gonna tag RC reports like this one with "rc" and "debian". If people follow up with similar initiatives we can rinse out of planet a feed of pretty good news for the Debian development community In the interest of sharing best practices, here is my RC bug squashing workflow:

1. go to http://bts.turmzimmer.net/details.php, choose "both" (i.e. squeeze + sid) as distribution and sort by "bugnr" (so that you can avoid most recent reports, which are not yet NMU material)
2. choose an inspiring bug form the list which is at least 1 week old (better at least 2 or 3), study its log; for the moment, I tend to prefer neglected bug logs, where the maintainer has been unresponsive
3. apt-get source package , sudo cowbuilder --build package_1.2-3.dsc , install the result and check for bug reproducibility
4. fix the bug ! (yes, this is the easy step ), taking care of not changing anything else
5. dch --nmu
6. dpkg-source -b package-1.2/ , sudo cowbuilder --build package_1.2-3.1.dsc , check if the bug is fixed and the package otherwise working
7. lintian package_1.2-3.1.changes , check that there are no regressions in lintian errors wrt latest uploaded version
8. interdiff -z package_1.2-3.diff.gz package_1.2-3.1.diff.gz , check that no unexpected changes have slipped in
9. debsign package_1.2-3.1*changes , dput -e 2 package_1.2-3.1*changes (as allowed by devref 5.11.1)
10. nmudiff --delay 2 , in the text: briefly describe in what the patch consists, and mention devref 5.11.1

I welcome suggestions on how to improve the above workflow in order to be both more effective and more polite with maintainers (FWIW, all the maintainer feedback I've received thus far for the above NMUs has been totally positive: you rock guys.).

After a long time of ignoring (or at least not using) micro-blogging services such as Twitter, I recently tried the Free-Software based identi.ca service, and I'm beginning to like it. The choice of service was pretty obvious while Twitter uses proprietary software and has custom Terms of Service, identi.ca is based on software under the GNU Affero General Public License, and the contents are CC-BY 3.0 licensed. The code behind identi.ca is called Laconica (recently renamed to StatusNet) and is hosted at gitorious:

 $ git clone git://gitorious.org/laconica/mainline.git

My account details are available under http://identi.ca/uwehermann, where I'm posting smaller announcements and notes about random technical stuff I'm working on (slightly more regularly than in this blog). Sometimes I use the web interface for posting, but using the Jabber integration available at identi.ca is even more convenient. You can both be notified of new posts ("dents") in real time via Jabber, as well as post your own dents from within your Jabber client, which is nice. identi.ca seems to become more popular every day, which will hopefully make the proprietary Twitter pretty much irrelevant sooner or later.

It's been quite some time (almost two years) since my previous "release" of debtree, but now version 0.7.3 is available. And it still generates very nice graphs :-) The changes are relatively minor: a few nice fixes for corner cases that were not handled correctly, and an update of the default lists of "skip" and "end" packages which help to limit the size of graphs for a fair number of packages I tried (including konqueror and openoffice.org).

---

Reason to revisit debtree was a recent nice mail from a debtree user, but also the current discussions about udev and the FHS. I'm on the side of "let's please keep /usr mountable separately". Mostly because I like a (small) encrypted root with a separate (large) unencrypted /usr'. I'm also increasingly unhappy with the default size of Debian's desktop installs, especially now that it looks as if Squeeze will see installation of Recommends by default by tasksel (and thus Debian Installer). For comparison, the size of a default Gnome desktop install for Etch was 1360MB; for Lenny it is 1830MB; for Squeeze it looks like it will be well over 3000MB! Remember that for Sarge we installed both Gnome and KDE from CD1 with both together taking 1390MB? Sure, some of that is real functionality, but a lot is also (IMO) redundant visual effects that only serve to slow the desktop down and junk needed to do stuff automagically. And a heck of a lot is duplicated functionality. One of the main reasons I switched to Linux was because it gave me back control over my systems, but with KDE4 and pervasive stuff like hal and all the various "kits" Linux is on a fast track that's giving priority to flashiness over real functionality and eroding that control. Here's a fairly default dependency graph for hal (click for full image). Looks reasonable, right? But that's only because most major dependencies, such as dbus, policykit and pm-utils have been pruned. Here's a complete graph, with only libc6 omitted (full image is 1.5MB). Truly a tangled web. Scary. One can also look at it from the other side. Today I upgraded my sid chroot and found I suddenly needed to install libavahi-client3, libavahi-common3, libavahi-common-data and libdbus-1-3. Why? Reason turned out to be libcups2, so I checked if I really needed that. And here's why I do. Most of these dependencies of libgtk2.0-0 I can understand, but isn't gtk supposed to be a graphical toolkit library? Couldn't printing support be implemented in some more specialized Gnome printing toolkit library? But I'm probably missing something. Anyway, now that I have a bit more perl experience through my recent work on debmirror, maybe I should finally port debtree from shell script to perl...

---

See the debtree home page for a full overview of how to read the graphs, but here's a quick intro. Purple arrows are Pre-Depends, blue are Depends and black are Recommends; green connections show Provides. The green packages are currently installed in my sid chroot, while the white ones are not. The diamonds show where the graph has been pruned: dependencies for these packages are not shown.

(... and the BSD license) Two comments about Romain's recent REJECT.

1. The specific case concerns a BSD-licensed source file. With respect to copyright notices BSD is rather peculiar, as can be read in the license text, at its second point

   Redistributions in binary form must reproduce the above
   copyright notice, this list of conditions and the following
   disclaimer in the documentation and/or other materials
   provided with the distribution.
   
   

   So, the requirement of mentioning in debian/copyright authors (or, more precisely, all copyright owners appearing in a given source package) has nothing to do with DFSG, it is a requirement imposed by the license itself.
2. I actually don't think that there is no will to do a move on this issue , quite the contrary. The last time the issue was raised (remember the giantic thread on copyright authors of several months ago?), I got the impression that there is a widespread will of getting rid of the burden of maintaining copyright lists up to date. What is not clear is whether, for licenses other than BSD, it is actually legally acceptable to do that. This issue is one of the pending questions that has been posed (by the DPL) to the SPI lawyer. AFAIK, no answer has been received yet. I "just" lack a bit more of visibility on these issues (e.g. a wiki page with pending queries to SPI lawyer) so that we avoid running in circles, as we are doing here.

I think this was my first contribution to the Debian operating system:

grace  (5.0.3-1) unstable; urgency=low

* added Replaces: xmgr, closes #35010, #42115, the only conflicting
  file is the grconvert binary which is identical in both packages
* changed editor to sensible-editor
* redebianized using dh_make and debhelper
* new upstream, closes: #41146, #27308, #28944, #29705, #38214
* NMU

-- Torsten Werner   Mon, 6 Sep 1999 22:19:04 +0200

That was 10 years ago. By the way the package is still in the distribution but orphaned now. Please note that our bug numbers had 5 digits only!

I don't want to count the packages that I am involved today but I am concentrating on Java related stuff. We got OpenJDK into Lenny and since DebConf9 it is our default JDK. Thanks to the recent work of Ludovic Claude we can use Maven for building official Debian packages. That will hopefully make packaging easier for many packages where upstream is using Maven as the build tool. I recommend joining the debian-java list if you are interested in those topics.

And I am a member of the FTP team today which is a great honour. It is quite
some extra work but we are now closer to the 1 week waiting time for NEW
processing (on average). Processing NEW is another place where I could see that
times are changing: this week I accepted a package (c) Microsoft Corporation
into Debian main what seemed to be impossible ten years ago.

Paul Wise recently reported that the Planet Debian search index hadn't updated since the 7th of June. The search function is something I added to the setup, and although I don't use it very often when I do find it enormously useful. Anyway normal service should now be restored, but the search index will be missing the content of anything posted for the two months the indexer wasn't running. Recently I tried to use this search functionality to find a post that I knew I'd written upon my blog a year or so ago, which I'd spectacularly failed to find via grep and my tag list. Ultimately this lead to my adding a search interface to my own blog entries using the namazu2 package. If I get some free time tomorrow I'll write a brief guide to setting this up for the Debian Administration website - something that has been a little neglected recently. ObFilm: Bill & Ted's Excellent Adventure.

---

po4a creates the meta files needed to generate the manpages but the actual generation process is a little awkward and tends to become heavily customised.

For emdebian-rootfs, I've now received the Portuguese translation and I've been improving the genmanpages script. It's now more general and easier to configure for different source packages. There remain a few hidden assumptions which I hope to fix in future.

#!/bin/sh
set -e

# Copyright (C) 2006-2009 Neil Williams
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see .

# name and location of the config file
# relative to the top level source directory of the translations
# i.e. the directory containing ./po/
CONFIG="doc/po4a.config"
# POTFILE path
POTFILE="po/emdebian-rootfs.pot"
# the binary packages that will contain generated manpages
BINARIES="emdebian-rootfs multistrap"
# the binary packages with manpages in Section 3.
HASMAN3="emdebian-rootfs"
# the binary packages using DocBook XML & xsltproc
XMLPACKAGES="emdebian-rootfs"
# the DocBook XML files (TODO: let this take paths)
XMLFILE="emdebian-rootfs.1.xml"
# the XSL file to use for Docbook XSL
XSLFILE="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
# the POD files (TODO: let this take paths)
PODFILE="em_multistrap"
# the binary packages using POD
PODPACKAGES="multistrap"

# remember to add something to the clean:: rule in debian/rules
# to remove each binary package sub-directory.
# $(RM) -r doc/emdebian-rootfs doc/multistrap

# below this point, no changes should be needed.

wrap_langs ()
if [ -z "$LANGS" ]; then
echo "$1 $2" >> $CONFIG
else
echo "$1 $2 $3" >> $CONFIG
fi


if [ -f po4a.config ]; then
cd ../
fi
if [ -f ../po4a.config ]; then
cd ../../
fi

# calculate the langs, automatically.
LANGS= ls po/*.po 2>/dev/null true
if [ ! -z "$LANGS" ]; then
LANGS= ls po/*.po sed -e 's/.*\/\(.*\)\.po/\1 /' true
fi
if [ ! -z "$LANGS" ]; then
# LANGS should not include the specification, just the root.
LANGS= echo $LANGS sed -e 's/_.*//'
LANGS= echo $LANGS sed -e 's/@.*//'
LANGS= echo $LANGS sed -e 's/\+.*//'
echo "[po4a_langs] $LANGS" > $CONFIG
else
echo > $CONFIG
fi
wrap_langs "[po4a_paths]" "$POTFILE" "\$lang:po/\$lang.po"

for d in $BINARIES; do
for l in $LANGS; do
mkdir -p doc/$d/man/$l/man1/
if [ "$d" = "$HASMAN3" ]; then
mkdir -p doc/$d/man/$l/man3/
fi
done
mkdir -p doc/$d/man/man1/
if [ "$d" = "$HASMAN3" ]; then
mkdir -p doc/$d/man/man3/
fi
mkdir -p doc/pod/$l/
done
mkdir -p doc/html/

for file in ls doc/xml/*.xml ; do
xmllint --format "$file" --output "$file"
LOCAL= basename $file
wrap_langs "[type:docbook]" "$file" "\$lang:doc/xml/\$lang/$LOCAL"
done
# oops, this needs to be configurable
for file in em_multistrap; do
wrap_langs "[type: pod]" "$file" "\$lang:doc/pod/\$lang/$file"
done

# use -k to create all XML even if untranslated or the XSL breaks the build.
po4a -k 0 $CONFIG

for d in $BINARIES; do
for P in $XMLPACKAGES; do
for X in $XMLFILE; do
XML_CATALOG_FILES="/etc/xml/catalog" \
xsltproc -o doc/man/ --nonet $XSLFILE doc/xml/$X
done
if [ "$d" = "$HASMAN3" ]; then
mv doc/man/*.3 doc/$P/man/man3/
fi
mv doc/man/*.1 doc/$P/man/man1/
done
for POD in $PODPACKAGES; do
pod2man $PODFILE > doc/$POD/man/man1/$PODFILE.1
done
for l in $LANGS; do
for P in $XMLPACKAGES; do
for X in $XMLFILE; do
XML_CATALOG_FILES="/etc/xml/catalog" \
xsltproc -o doc/man/ --nonet $XSLFILE doc/xml/$l/$X
done
if [ "$d" = "$HASMAN3" ]; then
mv doc/man/*.3 doc/$P/man/$l/man3/
fi
mv doc/man/*.1 doc/$P/man/$l/man1/
done
for POD in $PODPACKAGES; do
pod2man doc/pod/$l/$PODFILE > doc/$POD/man/$l/man1/$PODFILE.1
done
done
done
for l in $LANGS; do
rm -rf doc/xml/$l
done
rm -rf doc/pod/

# the rest is specific to emdebian-rootfs - ignore.

# HTML versions, not packaged.
xsltproc -o doc/html/ --nonet \
http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl \
doc/xml/emdebian-rootfs.1.xml

for i in ls doc/html/*.html ; do
iconv -t utf-8 -f iso8859-1 $i > doc/html/tmp
sed < doc/html/tmp > $i -e 's:charset=ISO-8859-1:charset=UTF-8:'
done
rm -f doc/html/tmp


OK, more to be done here but it has a basic idea. The generated files are separated out into directories determined by the binary package name into which the manpages will be installed.

This gives a .install line something like:
doc/emdebian-rootfs/man/* ./usr/share/man/

This is important because it reduces the number of changes needed to add a new translation - in effect, only the $lang.po file itself.

It should at least give some ideas of what can be done.

One thing that often seems to cause problems for people who work over many different areas of the Linux kernel is the process of making sure that patches actually get reviewed and applied. Where the relevant subsystem is actively maintained it s not a problem but that s not always the case. Sometimes maintainers are busy or on holiday and miss things, sometimes there are other problems. In these cases the onus is on the patch submitter to spot the problem and make sure that something is done to ensure that the patch doesn t get forgotten. There s a few workflows for dealing with this. My preferred one is to track the appearance of my patches in Stephen Rothwell s linux-next tree, which tracks individual development trees destined for merge into Linus tree. I create a git branch based on the current state of this tree then apply the patches I m submitting on top of that. This lets me spot any potential merge conflicts that they ll create but the main function is to allow me to come back to the branch later and track which of the patches has shown up in one of the trees that Stephen tracks. To do this I rebase the branch onto the current state of linux-next:

git rebase --onto next/master old-master

where old-master is the last linux-next commit in the branch. This will flag up any merge issues that have come up due to changes in other trees and will also handle patches that are already present in one of the trees in -next by dropping my local version. The end result is a branch based on the new linux-next with all the patches that were not yet applied in it. I can see what still needs to be looked at by examining the log

git shortlog next/master..

and take any appropriate action, such as following up with the relevant maintainer or trying to find out what s going on with the subsytem if it looks like the subsystem maintainers are inactive. One possible problem with this approach is that a patch may be applied and then subsequently dropped this is rare but it can happen. I deal with that by also keeping a normal unrebased development branch whch has the changes in Linus tree merged into it periodically and incremental patches for any review updates that occur during the submission process. By looking at the diff between that and other trees I can see any changes that have got lost along the way.