Today I started to package from nearly all packages which I maintain within debian the new upstream versions, as squeeze is finally released Have fun with powertop 2.0beta (1.97) and the new lmms versions, to name only a few!

After everybody though that Midnight Commander is dead and the next release of it will be released together with hurd, it is very cool to announce that a new team of developers are active again. We've taken over officially the development in December and now, after two months of work a new version of mc is available: 4.6.2. This is mostly a bugfix release addressing several very nasty bugs which are also present in the debian package. Here the notes what has changed in this release:

• MC Core
  • Changed HQ url to point to new website www.midnight-commander.org (Closes: #137, #138)
  • Added a micro helper library in order to go slowly avay from glib (Closes: #157)
  • Use static strings as section entries in ~/.mc/history WARNING!: This will break old files (Closes: #50)
  • Fixed a repaint issue when clicking on the "View" Button instead of using F3 (Closes: #35)
  • Removed obsolete autoconf macros (Closes: #133)
  • Fix escaping for command line completion (Closes: #147)
  • prevent mc from segfaulting when getting invalid timestamps on files (Closes: #96)
  • Fixed a keybord issue when running mc via a putty console (Closes: #203)
  • setted pty fd to closeonexec (on subshell) (Closes: #174)
  • Fixed file renames, when copying/moving is performed into deleted directories. (Closes: #181)
  • Add an option to show executables first in the panels (Closes: #173)
  • Fixed concatdirand_file if there is a parameter = NULL (Closes: #180)
  • Allow out-of-tree builds (Closes: #224, #208)
• Editor
  • Syntax highlighting for:
    • debian files (debian/changelog, debian/control, debian/copyright, ..) (Closes: #142)
    • updated sh syntax highlighting (Closes: #143)
    • updated pascal syntax highlighting (Closes: #65)
    • differentiate between c and cpp files for highlighting (Closes: #16)
    • updated python highlighting to support python 2.6 (Closes: #216)
  • Removed some unneeded variables (Closes: #168, #151)
  • Do use a ro test if a file exists (Closes: #206)
  • Fixes some missbehaviour in regex matching (Closes: #207, #211 )
    • start at front of line and not on cursor position
    • . shouldn't match a newline
• VFS
  • Fix some bashisms in some extfs scripts (Closes: #146)
  • Fixed various problems with symlinks and files with chars which needs escaping over fish (Closes: #10, #87, #149, #53)
  • Added 7zip extfs descriptor (Closes: #92)
  • Switched from o3totxt to odf2txt as o3totxt is outdated (Closes: #218)
• Locale
  • Updated german translation (Closes: #167)
  • New Belarussian translation (Closes: #170)
  • Updated russian translation (Closes: #159)

As you see.. quite a long list of fixes Have fun and check the new release out right here!

Arthur Liu is doing a great series of posts following up on the results of Google Summer of Code '08 projects in Debian. (post 1 post 2) Most of them failed to produce code that's actually used in Debian, though there were some very successful projects, too. My experience with ikiwiki in '07 parallels that: latex Patrick Winnertz produced a working teximg (latex -> image) plugin that's in ikiwiki. The initial proposal also included doing latex -> html and wiki page -> latex conversions; that work never happened. file upload and image gallery Ben Coffey had an ambitious proposal to add file upload support to ikiwiki and also write an image gallery plugin using that. Ben did produce a working file upload interface, but that code never got into ikiwiki. This was due to a combination of at least three things:

1. The only outside communication with the ikiwiki community was doing a design proposal at the beginning, and a code dump toward the end of the project.
2. There was an existing complex spec for how to limit who could upload what files, but Ben didn't choose to implement those access controls.
3. The code dump was not even noticed until much later, when I was putting the finishing touches on my own implementation of an attachments plugin.

By the way, since I happened to do that attachments plugin as a paid consultant, I have an interesting data point: It took me 19 hours total to implement it, vs roughly a summer of work for the GSoC project. I don't mean this to reflect poorly on Ben, it just shows that someone who is familar with a code base and has thought a lot about a problem can work on it much more efficiently than a newcomer. AFAICS, Ben never did get to the gallery part. His involvement in SoC was cut short for personal reasons. Wiki WYSIWYG Editor Taylor Killian produced a working interface to Wikiwyg, but it tragically never made it into ikiwiki. This seemed to be going swimmingly -- Taylor set up a subversion repository for his work and produced several revisions of the wikiwyg plugin in response to feedback. At the end of the summer, it was close to ready to be included in ikiwiki. Then we lost contact with Taylor, and his site fell off the net. Subversion repo: Gone. Tarballs: Gone. The final tragic part of this story is that I had a local copy of all of Taylor's work. And when I moved ikiwiki over from subversion to git, I set up a wikiwyg branch, and put his work into it, and happily deleted my other copies of his work. But I made some kind of newbie mistake pushing that branch, and so his work never made it onto my git server, and at this point seems completly lost. (I still hope to hear from Taylor..) gallery Arpit Jain produced a working gallery plugin for ikiwiki. But that code never made it into ikiwiki. The main stumbling block seems to be that it used the lightbox javascript library, which, at least at the time was licensed under a non-free CC license. The code is present in a branch in ikiwiki's git repo, but at this point there is still no image gallery plugin in ikiwiki, though others are now working on other implementations. Conclusions I learned some important things from participating in the '07 SoC:

• There needs to be a well-defined place where students check in their code regularly, and where it is regularly reviewed. Either give them each accounts and branches in the project's main subversion repository, or better use distributed VCS. Ikiwiki switched to git as a direct result of the problems I saw with students publishing their code in the ad-hoc ways that resulted from not having that. And I keep backups of every ikiwiki git repo I am aware of, because any could fall off the net at any time.
• If your goal is to have a student develop something that is included in your project, that needs to be one of up-front success criteria for the SoC project. Otherwise, most of them will fail to get all the way there. Students need an incentive to deal with licensing issues, to respond to maintainers' feedback, and to keep following up until their code is merged. I suspect that requiring students leap over this sometimes very tall bar will scare a lot of them away though. You have to decide whether your goal is indeed to get working code in production, or if it's more to mentor a student for the summer.
• Just because one is very familiar with a code base and very productive in working on it, and has had lots of success getting others to contribute to it in the usual free software manner, does not mean that one will be a good mentor for a student working on that code base. In fact, it probably means you won't be, unless you have some prior experience teaching students. Which is why I've not participated in SoC since. :-/

This morning after getting up I stumbled over exciting news: Google designed it's own browser called Chrome. As a marketing-gag they published a small comic about this new browser where presenting all exciting features. While clicking through this comic I noticed something strange: Google seems to think that Europe is still in the middle of WW2, like many Americans do... (Hint: Have a look at the german borders)

As I wrote in my mail to debian-devel@l.d.o I would like to ask for help for porting mc to link dynamically against libsmclient so that I can enable the native smb support again. I've disabled this support with the last upload to unstable. Please see the informations below for the reasons: Here some background informations: mc still uses a very old samba lib to make the native smb support possible. This lib was included in 1996 and wasn't updated until now. Since the layout of the configuration file has changed and new features was added, this old lib had very much problems parsing this file. Furthermore I fear that there are untracked and unfixed security issues within this lib which were discovered from 1996 until now. My plans are to link mc dynamically against the libsmbclient0, but since there are several other big tasks to work on, I don't know exactly if I've enough time to work on this big issue. If someone is interested in working on a fix for this or for any other issue listed here please contact me, so we can coordinate. Thanks in advance

Cowdancer is activly developed in debian, that's very nice. it's really a cool tool to build packages for unstable but also for backporting efforts. I'm using it on a daily basis to build debian etch packages of lustre. However three days ago cowdancer stopped working with my etch chroot after an upgrade of my unstable system:

dpkg-source: info: building lustre in lustre_1.6.5~rc3-1.dsc
dpkg-genchanges -S >../lustre_1.6.5~rc3-1_source.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: source only upload (original source is included)
chroot: cannot run command  cowdancer-ilistcreate': No such file or directory
W: cowdancer-ilistcreate failed to run within chroot, falling back to old method
 -> Running in no-targz mode
I: using fakeroot in build.
Current time: Sat May 17 12:18:30 CEST 2008
pbuilder-time-stamp: 1211019510
 -> copying local configuration
 -> mounting /proc filesystem
 -> mounting /dev/pts filesystem
 -> policy-rc.d already exists
Obtaining the cached apt archive contents
Installing the build-deps
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
Can't open perl script "/usr/bin/dpkg-architecture": Cannot allocate memory
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
sh: /tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control: Cannot allocate memory
E: pbuilder-satisfydepends failed.
Copying back the cached apt archive contents
 -> unmounting dev/pts filesystem
 -> unmounting proc filesystem
 -> Copying COW directory
 -> Invoking pbuilder
 -> Cleaning COW directory
Command /bin/sh -c pdebuild "--pbuilder" "cowbuilder" "--" "--basepath" "/var/cache/pbuilder/etch.cow" failed

After some research I found that a change of cowdancer (something related to .ilist) is responible for this issue. After that I asked on #debian-devel if someone else had this problem and were told that removing an re-creating the chroot will help. But that results in the same error msg. After that I decided to wrote a bugreport against cowdancer, since this is in my eyes a major defect in this software to do not support the latest stable release. I filled this report as RC Bug and got very fast a answer:

severity 481344 wishlist
retitle 481344  provide cowdancer etch backport
[ ... ]

I think this is the wrong way to fix a problem in unstable with a backport of a software. Providing a fallback for older debian releases would be the better way. Is anybody else having this problems?

Patrick Winnertz writes about the demotivating effect of unreasonable delays on joining the Debian project [1]. While I agree that things need to be improved in terms of getting people in the project in a timely manner (the suggestion of providing assistants seems good), I don’t think that anyone has a good reason for being demotivated because of this. I first applied to join Debian in late 1998 or some time in 1999. At the time part of the process of joining was to receive a phone call. At the time I was living in a hotel and they refused to call me on such a line. I could have easily camped out in the hallway of a hotel (the cheap London hotels often had a pay-phone in the hall and no phones in the rooms) and pretended that it was my own phone with an unlisted number. Unless they refused to allow people with unlisted numbers to join (which seems unlikely) then I could have joined then. So it seems that at the time I could only join Debian if I was prepared to lie about my ownership of a phone line. I wasn’t overly bothered by this - there has never been a shortage of free software projects that need contributions of code. By late 2000 the rules had changed and I joined without needing a phone call. In the mean time I had forked the Bonnie storage benchmark program to form my own project Bonnie++ [2], created Postal - mail server benchmark suite [3] and worked on many other things as well. I have sympathy for the people who apply to become Debian Developers and who have to wait a long time, I’ve been in the same situation myself. But there are plenty of things that you can do in the mean time. Some of the things that you can do are upstream development work, filing bug reports, submiting patches that fix bugs, and writing documentation (all forms including blog posts). Also when projects aren’t yet in Debian it often happens that someone creates unofficial packages, the person who does this doesn’t need to be a DD. Producing back-ported packages for new versions of programs that are in a stable release can also be done by people who are not DDs. Unofficial and back-ported packages provide less benefit for the project as a whole but considerable benefit for the people who want to use them. There is a lot of work that can be done to fulfill clause 4 of the Debian Social Contract [4] (Our priorities are our users and free software) which doesn’t require being a Debian developer. It seems to me that if you have the right approach to this and maintain the perspective that Debian is one part of the free software community (and not necessarily the biggest or most significant) then a delay in your application to become a DD won’t be particularly demotivating.

• [1] http://www.der-winnie.de/posts/Demotivaton_of_new_prospective_Developers/


• [2] http://www.coker.com.au/bonnie++/


• [3] http://www.coker.com.au/postal/


• [4] http://www.debian.org/social_contract

Share This

I'm writing this blog entry as a reaction of Lucas Nussbaums one. More or less one year ago I also was a New Maintainer who completed the process after 3 months (Started in February and ended in May). My Intention was to become as fast as possible a Developer and I was very motivated. (I helped Lucas with filling the build twice in a row bugs in this time). The FD approves me quite fast... (I'll guess I was only waiting for two weeks?) but the next to steps (Approval of DAM and creation of the account) took very long. After waiting for 3 months I was quite demotivated and doing only necessary things in order to update my packages... it was very frustrating. But now I'm finally a DD, since 6 months. For those who doesn't want to calculate: I was waiting for DAM about 4 months. When I saw that I was again highly motivated and started again to work on Debian a bit more, because I thought that the account creation can't took long...this was an error: I was approved by DAM in the middle of October... and got my account in Dezember... again waiting for a simple action. I can really understand New Maintainer who are directly MIA after being a DD. Waiting a half year for account creation is much too long. In my eyes there is only one possible solution for this issue: Since DAM and the Account Manager have also many other tasks which consumes there time, I would suggest to give them assistants...every manager needs at least one assistant ;-). This would speed up the process and people who are doing actually a great job doesn't get frustrated by waiting, but can actively work on Debian. I hope that the new DPL will find a solution for this really big issue during his time.

Some weeks ago I post about a spam contest where I participate. This contest is now running for several weeks. (It will be finished after 5 weeks). The aim is to get as most as possible spam to the emailadress . (My is winnie@qsc218.credativ.com). Atm I'm the second... I've ~140 spam mails and only 1 virus in my mailbox Noel, who is on the first has ~150 spam mails and ~10 viruses in his mailbox :-S The winner of this contest will get a free t-shirt (with a cool text on it). Yeah... it would rock if you can distribute this emailadress a bit more, so that I recieves more spam Thanks!!

Today is the first day where we are really here and could work. After some initial troubles with the network setup here, we've managed that everybody was able to get internet access. There are some goal we would like to archieve during this worksession, these goals are:

• remove blocker bugs of our long standing issue #311188
  • bind9 patch
  • dhcp3 patch
  • slapd patch
  • switch syslog daemon to use rsyslog
• improve our dokumentation
• general hacking on ltsp
• further work on cdd-dev

After the first day the bind9 patch is completed and the dhcp3 is almost ready. Hopefully are the other days here in this nice town also so productive! I'll add some photos of this meeting after it is over to my gallery.

Yesterday I made the switch from kde3 to kde4. But before I dumped all installed packages into a file ( if I have to restore) and backuped my configuration files for kde. After some fiddeling with kde4 and the dependencies I had a full kde4 installed. My problem was that:

apt-get -t experimental install kde4

won't resolve all dependencies... So my apt-get line was quite long. (After I was finished, I thought that maybe pinning would be a better idea). In general kde4 is usable, but there are some quite annoying things:

• konqueror can't show websites via ssl with a ssl name which doesn't match the servername (the https:// protocoll will die)
• It is not possible for me to choose another delimiter than the default one for the shortcuts in konqueror. (I'm used to have as delimter only a blank, but the default is a colon.)
• Sometimes konqueror (very rare!!) can't contact klauner anymore.. a restart of konqueror fixes this issue.
• Sometimes plasma crashes and restarts directly afterwards, but I'm not able to reproduce this atm.

But of course there are quite many improvements, I'll list here only those which I consider very useful

• kopete is now able to show the away messages of people using ICQ6 (I wasn't able to read them before)
• konqueror renders some websites now better than before
• The new menu structure is quite cool
• And of course: the plasmoids...it's quite sad that most plasmoids are in playground atm (calc, weather). It would be cool if it would be possible to package them as extragear-playground or something similiar.

Some things which are definitly missing in kde4 (which have to be ported to qt4) are kpowersave and knetworkmanager. Furthermore kontact and amarok, but there is work in progress.

I've created a small contest together with several other guys. We'll try to get as much as possible spams on a emailadress. The people with the most spam and viruses on his emailaccount will win. I think a good starting point is to publish here, we'll see. Some other things which could end in having success are:

• write the emailadress into the footer of each emailadress as spamtrap.
• subscribe to several websites
• write some guestbook entries with this emailadress

If you have other ideas how to get as much as possible spam to this address please write a Comment to this post to the Discussion page. Thanks in advance The emailadress which should recieves as much as possible spam is: winnie@qsc218.credativ.com.

Today I was very nerved by searching for patches for mc. Every distribution has other patches for the same thing, The best point to show this are the utf8/slang patches. There are many different approaches which have different qualtity. Furthermore are in every distribution fixes which are missing in other ones. And I was really pissed by that :S In order to find a solution I contacted several other maintainers of mc (opensuse, mandriva, mandrake, fedora, ubuntu) and get a reply from several of them. Maybe we'll start to use one repository to start to unify our patches. My goal with this is to get better patches into debian (and into the other distributions), sharing patches between distributions and unifying them to submit them to upstream. Maybe this will help to get patches from distributions faster into the upstreams CVS. We'll see what will happen. I'm looking forward to the result of this initiative

After nearly 2 days I'll put some fotos of the CLT08 online. It's a quite cool event which many nice people and I'm pleased to meet them (again). In some minutes is the start of the social event, I'll hope it will be as good as the last year, which many very cool drinks Have fun to view the fotos! (Sorry for some not so good pictures

Yeah.. finally we're preparing everything in order to leave for the CLT08. Two days on the debian booth in Chemnitz, some very cool talks about various topics, of course party and meeting some people there. See you there!

I've written some days ago a patch for the mutt sidebar patch in order to enable subfolder support there. The big issue was that if there were folders as "Debian/mc/commits" they were displayed as "commits". So everything before the last / is cutted of. In order to fix this I've to replace this piece of code:

 const char *basename (const char *f)
 
  const char *p = strrchr (f, '/');
  if (p)
    return p + 1;
  else
    return f;
 

with this piece of code:

char *sidebar_foldername(const char *folder)  
  char *p = strstr (folder, NONULL(Spoolfile));
  if ( (p) && !strcmp(folder, p) )
    return p + strlen(NONULL(Spoolfile)) + 1;
  else  
    p = strrchr (folder, '/');
    if (p)
      return p + 1;
   
  return folder;
 

and (of course) fix the function call in draw_sidebar ;-). And hey.. subfolders are displayed correctly now in the sidebar. I've send the patch to the debian maintainer and I'll hope that he like it.

I switched today my blog from a svn backend to a git backend, since the svn post-commit hook doesn't work for web commits on svn. (I doesn't get a email for changes via the web interface). We'll see how ikiwiki behaves with a git backend

Yeah... this happens if you are drunken see a nice girl and try to sign a gpg key : Without any other comment. Thanks to madduck: this comic is of course from xkcd

Julien's blog entry and some spare time lead me to try this powertop utility which I never heard about before. As a consequence, I ended up tine tuning a few parameters on my laptop, mostly sound card and wireless card energy saving parameters. I also finally turned "noatime" ON on my mounted partitions when the laptop runs on battery (I use laptop-mode for such automation). I was prevented to do so util now because mutt relies on access times to define whether mailboxes got new mail or not. However, recent mutt version now have "set check_mbox_size" which make mutt rely on the mailboxes sizes I still have fine tuning to do, mostly trying to get my hard disk really spin down in some occasions (mail reading, mostly) as well as automate the screen brightness, but this powertop utility is really worth it in the hunt for wasted energy. And, of course, installing it is just a matter of "aptitude install powertop", thanks to Patrick Winnertz who packages it. And thanks to Julien who blogged about Powertop, even for ranting about it...:-)

As I wrote last week to debian-devel@l.d.o I started the again a mass bug filling against all packages which fails to build twice and three times in a row. Furthermore we checked this time if the package content has changed between the builds. Today I completed these bug reports finally :). I wrote today about ~400 bug reports against several packages. Some packages which are very well known are:

• aptitude
• php5
• debian-policy (my favourite ;-))
• ...

All failures concering doublebuild or three time build issues are filled with Severity: Important and all bugs against packages which have a different content after the builds are filled with Severity: Serious. Please fix all of them as soon as possible (To fix this issues is a release goal for lenny ;-)) To view all bug reports please have a look here and here.