I maintain most of my Debian packages because I use them myself. Sometimes, I have some needs that go slightly beyond what is currently offered by the software. This is not a problem: Debian ships Free Software and I can program, therefore I can patch the software to also do what I want it to do. Trying to be a good member of the Free Software community, I then submit the patch to the upstream author. If he accepts the patch (which is usually the case), everything is fine. But what if he does not reply to the report or rejects it because he does not want this feature (although the patch is technically fine)? I see two options:
How do other Debian Developers handle such issues? The actual case I’m considering is a feature enhancement for link-monitor-applet (but I only just wrote the patch, so it does not yet fall in the category “upstream does not reply”).
I just packaged and uploaded Jan Vornberger’s window manager bluetile to Debian. This very nice piece of software brings the benefits of a tiling window manager to users who prefer to use the mouse and who don’t want to learn a new programing language to configure their window manager. Bluetile uses the xmonad libraries and extends them with an easy to use and discoverable user interface.
The XML-Editor Serna by Syntext has been published as Free Software a few months ago. This was very good news, because there was a lack of a good free XML editors with a good graphical view on DocBook documents, which I needed to recommend to users of zpub. Therefore, I investigated packaging Serna for Debian. I had to patch a few things to make it compile on and64 and to use components shipped by Debian where possible. Today, I could finally close the RFP bug filed by W. Martin Borgert, as the serna package was accepted by the ftp-masters. The first bug (SEGFAULT on startup on lenny) is already filed. I hope this is a good sign, as it shows that there is interest in the package.
For my packaging workflow, I used git-svn to import the upstream SVN branch into a git repository. I then use git-dpm by Bernhard R. Link to manage my changes as patches in the new 3.0 (quilt) debian source package. I must say that I prefer this approach to git-buildpackage, as there is only one git branch to publish. I hope that Bernhard uploads git-dpm to Debian soon.
Serna is quite a big software project and uses stuff that I know little about (Qt, C++ with python interaction etc.). Also, the package currently bundles the DITA-OT package, which should rather be packaged separately. Therefore, I’d be glad if co-maintainers would join the effort.
In a comment to my previous blog post, I linked to the DebConf photo gallery page with the DebConf8 mugshots. Felix Brandt, a friend of mine, noticed the per-picture view statistics there and plotted them, differentiating between male and female. He finds that the number of views on an image gives a fairly good indication of the sex (or gender?) of the person in question:
The most notable exception is the image of bubulle. He does not even look feminine. Maybe it’s because he’s like a mother to us Debianers, always kind and always helpful? :-)
This observation fits my experience when I created a top-100-statistic of individual picture page views of my personal gallery: I got a collection of pretty much all pictures of girls in bikinis, lying at some beach, across the various pages and years, and hardly any other picture. I won’t post these top-100 here, as I don’t want to additionally increase the effect...
This year’s game of Assassins at DebConf 9 was quick. I did not even had a chance to check who my target would have been, and already I got touched by a sock...
In time for the upcoming DebConf keysigning party I followed the crowd and generated a new 4096-bit RSA GPG key, which you can find on the keyserver near you. But I plan to use my old key for a while, until the new one is properly integrated in the Web of Trust. I still have a batch of cards with the old key on it as well, so I won’t revoke that too soon.
pub 4096R/F0FBF51F 2009-07-10
Key fingerprint = 1A46 087F 955D 93C5 7C60 571B 3D90 8AB3 F0FB F51F
uid Joachim Breitner <mail@joachim-breitner.de>
uid Joachim Breitner <joachim.breitner@itomig.de>
uid Joachim Breitner (Jabber-ID) <nomeata@joachim-breitner.de>
uid Joachim Breitner <nomeata@debian.org>
sub 4096R/6F927969 2009-07-10
I’m also considering to play the keysigning game a bit less intense. I reached a rank of about 20 two months ago with my old key and had my fun.
I just made my first upload to hackage (not counting uploads I did during my work in Dresden). Don Steward repeatedly told me to package and upload darcswatch, so I just did that. Thanks to Gwern Branwen to contribute the first cabal file.
There is little documentation on how to set up darcswatch yourself, so if you actually want to try it out, you most likely will have to get in touch with me. Note that you can just use the installation on http://darcswatch.nomeata.de/.
If you, for some reason, feel like hacking on darcswatch, I’d be interested in memory reduction. I currently process 916 mails containing 1867 patches and 47MB, as well as 13 repositories, some of which are rather large, and the numbers are increasing.
A fellow lodger of my student dormatory just popped in and gave me the December issue of Linux Journal as a gift from his trip to the US (thanks for that!). When I skimmed the front page, I immediatelly noticed the line “Reviewed: OpenMoko’s Neo FreeRunner.” The four page article by Cory Wright contains some general notes on the FreeRunner, a list of things he doesn’t like and – to my surprise – installation instructions for Debian on the FreeRunner! It’s nice to see one’s work used in such public places. I especially liked the line “I must say, the Debian installers sure have improved a lot since the Potato days.” (Of course, the installer for the FreeRunner is mostly a dumb script that can not be compared to the great official debian-installer that you can use on a PC.)
I’ve been at DebConf for almost two week, but haven’t blogged a lot about it. It’s mostly because we’ve been working on getting Debian to run on the OpenMoko FreeRunner. Today we finally sent out the official annoucement for this, because it seems that the installer script and packages seem to work so far.
Great thing about this is the sheer amount of software that’s now available on my phone. I already blogged about running Xmonad on it, and I have also ran my screen-message program, on it, as can be seen here. I only did minimal testing of the phone features, because it would be relatively expensive here in Argentinia with my German SIM card, but it seems to work as well.
Here at DebConf 8 in Argentinia, I’m working on getting Debian to work on the OpenMoko Freerunner Smartphone. We are progressing quite nicely, soon having the same features as the official freesmartphone.org image. See the pkg-fso wiki page for more on that.
And why do we want to do that? Because we can use everything in the Debian archive on our phones!
This is the xmonad window manager, programmed in Haskell and usually running on my Desktop, now on my mobile phone! And it’s almost usable. Only problem is that the screen keyboard, metacity-keyboard, gets the focus by xmonad, so I can’t actually type into other windows. This could be fixed by configuring xmonad, but for that, I need to install ghc and I do not have these 280MB left on my SD card...
Update: I even made it on the front page of the xmonad home page with this image:
A few days ago, I asked how to fork a debian package privately. I got some repsonses by comments, e-Mail and other blog posts, and I want to summarize the tools that were suggested. I have not really tried them, just looked at the webpages, the documentation or the sourcecode. I’m only including Debian-specific solutions, as using Gentoo might be nice, but is out of scope here :-)
I also deleted half the text before saving it, and I hate rewriting stuff, so it might be a bit terse.
Eddy Petrișor tells me about his three year old project debtoo, which wants to bring a Gentoo-like experience to Debian. While it probably provides what I need, it feels “too big” in that it has a more general aim than what I’m looking for. It is not in Debian and not actively developed in the last two years.
Eddy also tells me about srcinst, which is a small haskell program written by jgoerzen in 2005. This is more a proof-of-concept that builds a package and all necessariy build-dependencies without using a binary package, but does not allow for patches to be applied. It is in Debian, actively maintained, but not developed, and barely documented (just an IRC log).
A similar tool and also in Debian is apt-build. This package is created to compile packages for optimization (as it asks half a dozend compiler-flag-questions with DebConf during the installation). It allows the user to apply a patch to the source, but it has to be passed as a command line option, and patches seem not to be tracked. Not much development in the last year, and not much documentation.
Not to be confused with the program in the debdelta package is the debpatch tool by Victor Hsieh which Carsten Hey told me about. Also written in 2005, this comes closest to what I want. For every package you want to modify, you can configure it to apply patches to the source, to add patches to the debian/patches directory or to statically replace files in the generated binary and puts it in a local apt repository. No code yet to track new versions of the packages and no support for pbuilder though. This perl script is not yet in Debian, but is available as a Debian package and seems to have seen some development in the last years. Quick Googleing does not return any user reports; has any already tried this?
Somewhat in this direction goes the script that I wrote two weeks ago for a totally different project, customdeb, but it is aimed at binary debian files exclusively, and debpatch already supports replacing files in the binary package.
Also a related tool Carsten Hey told me about is apt-src. This tool wants to provide apt-like features for source packages. It allows you to “install” sources somewhere, upgrade the source and build binary packages from them. It does not really hide the sources from the user and seems to be created for people who want to work with the source somehow. If you have local changes to the sources, it can try to merge them with the new version, but these changes are not kept as a separate patch but only as implicit changes. If that were different, it would seem be a very nice tool. It’s written by Joey Hess he abondonned it in 2004. Since then, not much development has happened.
Yet another approach is taken by debnest, which Peter Makholm took over. Here, you create a full debian source package with a debian/ directory containing a control and rule file etc., but besides the debian/ directory, it contains just the packed sources (.dsc et al) from another package. In your debian/rules, you can specify your changes. I can see no support for tracking new versions of the inner package, but at least this project is maintained and in Debian.
I found a few projects that go in a similar direction, and one that seems to fit my needs quite well. All of them are not widely used and in a very early state of development, and it seems to be something people start to work on and quickly lose interest. I’m actually surprised that this is not a itch more people had to scratch! I will have a closer look at debpatch when I find the time and maybe, if found useful, see if it can be included in Debian − probably after a name change, since we already have a debpatch binary. Or maybe I should try to add support for what I need to apt-src, which seems to be the most advanced of all these programs, although it’s unmaintained longer than the others exist.
Update: Added apt-src.
Update 2: Added debnest;
I am very fond of Jean-Yves Lefort’s link-monitor-applet, which puts little bars in my panel that display the ping time to certain hosts. Very useful, especially since I’m often using a shaky wireless connection.
With the latest release, though, the author added an icon next to these bars. He argued that the small bars, if there are only few of them, are hard to hit with the mouse, and therefore added this icon as a usability improvement for less advanced users.
But for me, this makes the applet almost unusable, as I just don’t have the space left for a useless icon. Things are here proably worse because the icon is higher than wide, scales to the maximum size that fits the panel and my panel is vertical and slightly wider than the normal horizontal panel is wide.
I asked the author to make this behaviour configurable or to hide the icon when there are more than three hosts to display (with patch included), but he wanted to stick to the icon. So what are my options? I could manually download and extract the source, apply the patch and build the package every time a new version is uploaded to Debian but shouldn’t this be easier?
If Debian were not 20 but 2 years old I assume that all sources would be in one big git/darcs/hg/whatever repository, with something like the SuSE build service, which would automatically build the packages, and I could make my system automatically track a branch of the “real” Debian with my patches added. But at the moment, this would be utopical.
I could imagine creating something smilar that would track the uploads to debian and, if link-monior-applet is uploaded, tries to automatically build a package with my modification, providing this in an apt repository that has a high apt priority for me. Has anyone done that already, or tried it, or thought about that?
I’m currently working at the Linux migration of the city of Böblingen which is currently pushed forward by Itomig. For our modifications to the client there I thought it would be nice to distribute them as easily as the regular Debian packages. We did not want to write a bunch of scripts that modify the files after installation, or try to create packages that modify other packages file.
So I wrote customdeb, which currently allows you to change the contents and permissions of files inside a debian package, generating a new package (with a local version number) that you can easily distribute to your clients. The changes are specified in a simple, debian/control-like file, which therefore also serve as a documentation of your changes. It either modifies a package that you pass it on the command line or tries to fetch it with dget. More ways to change a package (e.g. adjust dependencies) will be added as soon as I need them (or someone else needs them and sends me a patch).
I think this might be useful for others as well, so I am packaging it for Debian. If you want to try it before it went through the NEW queue, you can find the packages here. Contributions are welcome, but be aware that the perl code is currently written in a not very modular, quick-to-work style. I plan to change that if there is more interest in the program. I have the code in a darcs repository (browse it).
This weekend, I’m attending the Haskell Hackathon in Freiburg. Regular readers of my blog will have noticed an increasing interest in Haskell, so having this event so close was a nice chance to get more involved in the Haskell community. My blog also got added to Planet Haskell now.
So far, I have hacked up a simple haskell program called „Haskell Package Version Tracker“. It takes the 00-index.tar.gz file of hackage (which is for Haskell what CPAN is for Perl) and a Debian Source file (which is the list of available packages in Debian) and outputs a comparision in the spirit of the Debian Perl Group’s or utnubu’s version comparison pages. You can see the last output, but I do not yet update that page regulary. The code is available in a Darcs repository. It uses the Index.hs-File from hackports − thaks for that.
On a modern debian system (and other linuxes as well), the cron daemon is PAM-enabled, which is probably a good thing. One downside is that you get your /var/log/auth.log full of messages like:
Sep 11 11:15:01 otto CRON[8755]: pam_unix(cron:session): session opened for user jojo by (uid=0) Sep 11 11:15:01 otto CRON[8755]: pam_unix(cron:session): session closed for user jojo
I think these are pretty useless and make it harder to find real authentication related entries in auth.log, especially if you get them every five minutes. Luckily, the fix is pretty simple: Just edit /etc/pam.d/cron and comment out the line @include common-session, as that only calls pam_unix.so which in turn, for session management, does nothing but logging anyways.
To further separate the cron logs, you can remove these entries to syslog:
Sep 11 07:17:01 quimby /USR/SBIN/CRON[7949]: (root) CMD ( run-parts --report /etc/cron.hourly)
by configuring /etc/syslog.conf to move them to a logfile on its own:
*.*;auth,authpriv,cron.none -/var/log/syslog cron.* -/var/log/cron.log
Bilder
