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.

I see that github have recently announced their pricing plans. Looks like they’ll not be having many kernel developers using their “open source” plan - my current working Linux .git is 261Mb but you start having to pay at 100Mb. git may be very space efficient but the kernel is an enormous project. Mind you, the whole web service based approach of github is fairly alien to kernel development - a large part of what it’s doing is replacing the combination of mailing lists together with git send-email and git am (or their equivalents) that the kernel relies on for code exchange and review. Interestingly it appears not to have done anything that provides the discussion and review side of things - that seems like a surprising omission for a web 2.0ish thing.

Because of some modifications at my Real Life Orkplace, I decided to reduce other duties to get a better chance to deal with my new duties. So i requested help for my four packages in the Distribution

RFH: jove

My first package. A small, but powerful Emacs-relative, with all those uneeded things stripped which makes emacs fat. Maybe these days especially useful for small memory devices, as it gives you emacs-likeness for the price of nvi or ae. I have no idea how well it works in a real utf-8-environment.

RFH: milter-greylist

A greylist-milter which makes running a mailserver somehow possible for me. it keeps away about 2/3 of spam, which leaves me with only 400spams/day. I already have two contacts who want to help with that.

RFH: nn

No news is good news, but nn is better. This is a USENET reader, for those people who grow up with Webforums and Blogs: This could be still the most effective way to celebrate flamefests, gather information or communicate with people sharing same interests. And nn has in my opinion the best UI for it, and makes it easy and fast to find interesting articles and skip others. Well, Upstream Development has ceased to exist around 1994. I think if no one takes over, this package will become finally useless when IPv6 gets widely used (right after the release of 'Duke Nukem Forever') and it also doesn't deal well with non iso-8859-1-charsets. So best for this package would be to rewrite it from scratch (my dream: message/mime-handling/threading from mutt, scoring from slrn, and UI from nn) because the User Interface is much better than those of all still alive Newsreaders i tried.

RFA: synergy

This is my most popular package, which makes it possible to share one mouse and keyboard over many computers and displays. (It is available for UNIX/Linux, Windows and MacOS) This is a very very useful software, and i use it permanently. Sadly the Upstream Development mostly ceased to exist, and so i put this to RFA (instead of RFH) because many Debian-Users use it according to popcon. This software should be taken over by someone who is able to help Upstream. There is a RC-Bug, which caused the package be pulled from testing.

Interesting is that while filing those RFH/RFA all the same day, i only got responses for the packages which scores lowest in popcon, (24 for milter-greylist, 1196 for synergy).

So, since Emacs is apparently switching to bzr, I thought I'd try it out. The first thing I noticed is that cloning the repository is very slow. So slow that I killed it, thinking that it was stuck, but it wasn't. It turns out that the official page recommends downloading a tarball instead, so I did that.

Once I had my local Emacs branch, I tried a simple bzr log to see how recent the repository was. It sat there for a whole minute before even starting to show something. Apparently, all the history commands are slow... This is with a hot cache:

$ time bzr log >/dev/null
bzr log > /dev/null  44.89s user 0.58s system 99% cpu 45.563 total
$ time bzr version-info
revision-id: cvs-1:monnier-20080313012033-9ewl8gg4q3bw01z3
date: 2008-03-13 01:20:33 +0000
build-date: 2008-03-13 20:14:17 +0100
revno: 87445
branch-nick: sandbox
bzr version-info  6.41s user 0.14s system 99% cpu 6.549 total
$

Six seconds just to show me the current revision?!

Compare with my favorite scm, in a repository that contains the same history, also converted with cvsps:

$ time git log >/dev/null
git log > /dev/null  1.81s user 0.05s system 99% cpu 1.862 total
$ time git show >/dev/null
git show > /dev/null  0.02s user 0.00s system 85% cpu 0.023 total
$

Fortunately, other bzr commands such as status, diff, commit are pretty fast so this might be a problem with the conversion process, or something. At least I hope so, because as is it's completely unusable!

I'm getting on a flight to Brisbane, via Auckland, shortly. My mate Nick (yes, that one), is remarrying, and asked me to his Best Man, and I could hardly say no, given he was my Best Man (and we've been friends for years) So I'm flying out of SFO tonight, arriving in Brisbane on Friday morning, going to the wedding on Saturday, and flying home on Sunday morning. Fortunately with the time difference, I'll arrive on Sunday, so I get to walk around like the living dead for a day, and then go back to work. Yep, I'm a sucker for punishment. I've never been Best Man before, so I'm nervous. My speech is pretty short and sweet. Fortunately someone else is being Master of Ceremonies.

Well, after many failed attempts, here I am on my problematic HP laptop with a USB key mounted, a balloon3 board booted under an Emdebian root filesystem and visible over USB-to-serial using /dev/ttyUSB0 via screen.
Thanks to Daniel's tip about screen /dev/ttyUSB0 115200, my USB to Serial converter (Maplins with a Prolific PL2303 chipset) is working on my problematic HP laptop.
The proviso is that I have to reboot to enable all this stuff - allow the laptop to hibernate and all this USB stuff just disappears.
The only remaining problem is the wireless - I haven't decided yet whether to patch the current stock Debian kernel (I've had enough problems without getting into more kernel issues) - I may simply buy a replacement external wireless unit or just not use wireless until the b43 driver is capable of working with the Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02).
The magic runes for enabling USB are to add some more options to the grub boot list (on the 'kernel' line):

 noapic nolapic noirqfixup

minicom still doesn't like serial over USB (on this laptop, it adds an extra line feed and then refuses to pass on any keyboard entry to the device in a similar manner to the powerpc laptop) but screen works nicely. Thanks Daniel.
With noirqfixup added, I can also plug in other USB things like a USB mouse and actually see them work. This is all good news because apart from adding these mysterious runes to Grub, this is a completely standard Debian box running Sid and with no particular configuration changes or tweaks in the system setup.
This means that I can now get on with uploading the emdebian-tools package split to Debian unstable, adapting the Emdebian root filesystem for balloon3 to support USB networking by default and suggesting screen as an alternative to minicom in the control information for the new emdebian-rootfs package. (The package split is now in Emdebian SVN - main trunk - if you are interested.) I'm also downgrading my old G4 iBook to running Lenny instead of sid and it will now stay running Lenny as Debian stable when Lenny is released. It just makes it easier to not have to keep downloading massive updates on the brief occasions that I now use the iBook.
Now if I can just work out why hibernation forgets 'noirqfixup', I'll have a usable HP laptop....
Not bad for a machine that I once considered as a complete non-starter.

If you are interested in using version control for distro packaging, you

• might like http://vcs-pkg.org.
• might want to join #vcs-pkg on irc.oftc.net.
• should be signed up to our mailing list.

If you read the mailing list, you know about the upcoming Extremadura meeting 2-6 April 2008. If this is news to you, well, it isn t anymore. If you think you should be in Extremadura when this party takes place, don t hesitate and reply. The message ID is 20080311193428.GA25745@piper.oerlikon.madduck.net.

It's funny sitting down to finally write something on LJ and not being sure what to write. I can tell stories of Angie's mom coming to support her and giving me time with my wife. I could rant about students putting in some of their first IVs (or not, actually since after the third try I got bitchy and she ran away. Literally. Oops.) I could talk about recovery, the joy that is delaudid, the devil that Valium turned out to be, or wonderful nurses who were so helpful and encouraging (and the ones who bent the rules and let me see Leif on his first year birthday) or the ones who lied, failed to check in on me and left me in distress for several hours.

On the whole, the people and experience were very good. From almost immediately after I woke up, things have been better. I hadn't realized there was pain associated with all this until it was gone post-surgery. The numbness is still there, but better that it was before by a long shot.

I do want to make sure I say thanks for all the energy, thoughts, and prayers. I felt good on Monday going in with the power and energy of literally hundreds behind me. Religiously, I have a complex relationship with this stuff, but I believe that at moments where a yes or a no gets to be decided by luck or external unknown forces, this can really help the answer be a yes. And I think we'd be surprised at how much of life fits into that category.

There are lots of emails and posts I haven't replied to yet. My lifting restrictions are such that I can't pick up my laptop. So if you see emails or LJ posts from me, its been typed on the iPhone or the Blackberry. Same with the instant messenger. I have my status set to "do not disturb" when I'm around so that I don't exceed my ability to type by getting into talking to too many people at once. My lifting restrictions continue for the next 6 weeks.

That said, I do enjoy chatting and writing. It just takes a while and is quite tiring.

I haven't figured out how to upload pictures to flickr such that the pictures are public, but that are not forced onto people who just wanted to see pictures of Leif. :)

Tired now. If there is any particular part of the surgery/recovery you want details on, let me know and i'll write about it.

*hugs and love*
Jeff

PGAPack is rather nice and fairly small library for 'parallel' optimisation via generic algorithms using the MPI message passing protocol. PGAPack 1.0 was written by David Levine while doing graduate work during the mid-1990s at Argonne Labs / University of Chicago. PGAPack has also been in or around Debian for a rather long time, but it suffered from benign neglect in the last few years. Some of this came to the fore in this bugreport which lead to my offer to the then-maintainer Andreas to help on the relicencing request. After all, Argonne Labs is just a few miles from where I live, and I had already spent a little bit of time polishing and upgrading the package for my own exploratory use. So I called Rusty Lust, head of the Mathematics and Computer Science section at Argonne to try to sort this out. He was sympathetic and put me in email contact with David Levine. As we are all somewhat busy, this dragged on for a little longer than we thought --- but as of today, about and a half years later, we have a new and shiny PGAPack 1.1 release, or around twelve years after the initial 1.0 version came out. I have done a fair amount of polishing: there are now two library packages for serial use (i.e. for debugging) as well as parallel use via MPI. We use Open MPI where available and LAM where not. All open Debian bugs have been addressed. One minor issue in the postscript documentation remains as David can no longer locate his LaTeX sources; I may just have to extract the text and re-latex this from scratch to update it. One day. Anyway, for full reference, the changelog entry is below. The package is currently in the NEW queue (as the new sub-package require manual inspection and approval) but should hit mirrors in a couple of days. My thanks to the two previous Debian maintainers; to Rusty Lusk for helping with the from the end MSC department at Argonne Labs and for suggesting the rather liberal and easy MPICH2 license (and he happens to be one of the MPICH2 authors); and of course to David Levine for writing PGAPack in the first place, for agreeing to relicense it and giving valuable feedback on my repackaging of what is now version 1.1 on the MCS ftp server at Argonne --- this library has held up really well over the years; let's hope it will find more good use going forward.

pgapack (1.1-1) unstable; urgency=low
  * Really good news:  The MCS divsion of Argonne National Laboratories has
    agreed to relicense pgapack using the MPICH2 license. So pgapack
    is now Free Software and can move into Debian's main archive!
  
    Our thanks go to David Levine and Rusty Lusk to make this possible.
  
  * New maintainer, following Andreas' offer dated 2006-10-04 in #379388
  * debian/control: Change section to math		(Closes: #379388)
  
  * Added new brinary packages libpgapack-mpi1 and libpgapack-serial1
  * The MPI package is configured using Open MPI where available and LAM
    where not. 
  * debian/control: Changed Build-Depends: to use OpenMPI where available, 
    and LAM otherwise.
 
  * Finally acknowledges old NMUs 		(Closes: #379168,#359549)
  * source/integer.c: Apply patch for one-off error 	(Closes: #333381)
  * source/report.c:  Do not unconditionally print at generation 1
  
  * debian/rules: Remove a bashism 			(Closes: #379168)
  * debian/rules: Install examples directly 		(Closes: #134331)
  * debian/control: libpgapack-lam1 Depends on lam4 	(Closes: #60376)
  * debian/rules: Rewritten using debhelper
  * debian/control: Added Build-Depends: section for debhelper
  * No longer install mpi.h in /usr/include		(Closes: #404027)
    
  * debian/control: Updated Standards-Version: to current version
  * man/man1/PGAGetCharacterAllele.1: fix whatis entry 		(lintian)
  
 -- Dirk Eddelbuettel   Mon, 10 Mar 2008 18:03:34 -0500

A little utility that has been collecting dust on my harddrive over the past two years is an enhanced version of a PyGTK exception handling module that was originally posted to the PyGTK mailing list by Gustavo Carneiro. I've now uploaded it to the sysfs download area; it is essentially unlicensed, considered public domain by Gustavo according to his email message.

Besides fixing a API incompatibility with recent PyGTK releases, there are two main differences with the original functionality.
First, I've modified the traceback formatting to include two lines of context to each line in the traceback, one before and one after the called line. Also included is a printout of the identifiers referenced in the traceback lines variables, usually. On my personal wishlist was also syntax coloring in the debug window, but this was both non-trivial to implement, and it would likely add considerably to the complexity of the error handler, thus increasing the chances that the error handler itself would fail.
The other main functionality change is possibility to email feedback to a predefined address mainly meant for deployment and debugging of company-internal applications. To enable this feature, two identifiers feedback and smtphost must be set on the module. This can be either by modifying the code, or, better, by adding them after module import:

import gtkexcepthook
gtkexcepthook.feedback = 'valid@email.address.here'
gtkexcepthook.smtphost = 'relay.smtp.hostname'

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.

A little utility that has been collecting dust on my harddrive over the past two years is an enhanced version of a PyGTK exception handling module that was originally posted to the PyGTK mailing list by Gustavo Carneiro. I've now uploaded it to the sysfs download area; it is essentially unlicensed, considered public domain by Gustavo according to his email message.

Besides fixing a API incompatibility with recent PyGTK releases, there are two main differences with the original functionality.
First, I've modified the traceback formatting to include two lines of context to each line in the traceback, one before and one after the called line. Also included is a printout of the identifiers referenced in the traceback lines variables, usually. On my personal wishlist was also syntax coloring in the debug window, but this was both non-trivial to implement, and it would likely add considerably to the complexity of the error handler, thus increasing the chances that the error handler itself would fail.
The other main functionality change is possibility to email feedback to a predefined address mainly meant for deployment and debugging of company-internal applications. To enable this feature, two identifiers feedback and smtphost must be set on the module. This can be either by modifying the code, or, better, by adding them after module import:

import gtkexcepthook
gtkexcepthook.feedback = 'valid@email.address.here'
gtkexcepthook.smtphost = 'relay.smtp.hostname'

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.

Pierre Habouzit reported bug #470000 on Saturday March 8th instead of taking care of Habouzit Jr. Shame on him. Double shamre: that was an RC bug. He really should hijack that gromacs package which sounds to me as a special version of EMacs for the Groland country (fr_FR joke). As bug #460000 was reported as of January 11th 2008, we're still keeping the pace of 2 months for 10,000 bugs, so 60,000bugs a year. Bug #500000 should then be reported around Sept 10th 2008. As a consequence, the candidates for winning the 500000th bug contest are still Miguel Gea or Kartik Mistry. I still plan some MBF to keep chances of winning the contest myself. I also expect the lenny release to speed that up. See you around May 10th for bug #480000! PS: has anyone tried to plot compute the number of bugs we *close* in the same amount of time?

In case you didn’t know, I’ve decided to resign as atheme project lead. This is for a few reasons:

• Firstly, I have felt overall ineffective in this role since late 2007. This is probably due to the fact that disagreements between me and several other people have resulted in people leaving the organization to work on other projects, and the fact that atheme has not grown in any significant way since last year’s Summer of Code event.
• Secondly, I am busy with a lot of other things and do not have time to give the proper attention this role needs. This role is basically defining the direction that atheme grows in, and capitalizing our strengths to expand the project and promote it. I see the lack of growth and proper promotion as a personal failure.
• Thirdly, at the moment I am under a lot of stress due to dealing with various issues at the moment, which is leaving me irritable and generally quick to anger. This is not a quality we want in our project leadership. In short: I’m fucking up, and it needs to stop. So right now, I am resigning as project lead. If people want me back when I am under less pressure in general, then that’s great.
• Fourthly, we need to see new leadership in atheme anyway, to keep things interesting. Without a regular change in leadership, people will start to see us as someone’s personal project, and that’s not the case with atheme.

However, just because I’m resigning as project lead doesn’t mean that I will stop working on projects I care about inside atheme, like audacious, mowgli, and mcs. These projects are critical components of the modern FOSS desktop, and I intend to continue working on them. This is purely an administrative change, so that any mistakes or stupidity I do have no effect on atheme.org’s overall health. I hope to see many other Atheme members step up and try to become project lead. Under the right leadership, atheme’s projects could become a much more notable platform in FOSS development within a short amount of time. Update: Due to popular demand, I have changed my mind. I’m no longer resigning as project lead of atheme.

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

1. emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.


2. emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.


3. emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.


4. libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.

I’ve put together a partial timeline of the Debian project using the SIMILE Project’s DHTML timeline component. This is definately work in progress: I would welcome additional events (by email or merge request please, not via blog comments) regarding:

• Dates of the earlier Debian releases
• Release freezes
• Interesting dates of important packages and tools (Linux kernel, XFree86/X.Org, glibc, aptitude, etc.)

The timeline is available to view here. Update: Assistance fixing the (non-Webkit) Konqueror issue would also be appreciated.