Looking at the current discussions, I'm wishing some people would calm down a bit. It's always impressive how some things switch sides like pendulums. First of all, Debian already is centered about packing software and not developing them. We already have the rules and policies and methods in place. Our policy states:

If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.

And our source format shows how important marking the difference is to use: We have explicit .diff.gz files to contain them. The differences are not hidden in same Version Control System (like BSD) or in propretary formats (ever tried to unpack a .srpm without rpm or without downloading some magic perl script?), but in a simple universal understandable format. That said, please remember we are a distribution. Our priorities are our users and not the whims of software authors. We have to find the middle ground between harmful and necessary changes. Patching software to abide the FHS, to allow the user choose their editor or browser in an common way or any other thing to form a coherent set of packages is no bug in Debian, it is a bug in upstream to not allow this at least via some configure option. We have neither the manpower nor the job to rewrite and fork stuff to a usable state, though. Thus we have to keep to upstream and hope they will include our modifications or forward-port them to every new release. Thus, we need both: We need to patch (and in general, the worse the software from a distribution's point of view or from a general point, the more of this we need. This does not necessarily hold in the other direction, though.). And we need and want to show what we change. So our users can find out how exactly the software we ship is different. And so other people dealing with the same software can profit from our changes. (After all, free software is about "giving back" a lot.). And of course maintainer change over time and we want the new one understands what the previous one did. That said, there is of course things that can be improved. But as with all improvements there are things that improve and there are things where nothing is worse than good intentions. Adding more thing to keep in sync is almost always a bad thing in the long run. The easiest way to keep things accessible is to use stuff actually used. I think any additional place to track patches will be futile. A good interface to view the .diff.gz files in our archive in some browser, on the other hand, could hardly get unuseful. The format of a single .diff.gz is of course also improveable. Things like a quilt-like standardized patch series look like a very good idea to me. But the format is of course also very downgradeable. Storing VCS formated information for example, tempting as it is, spoils two very important points:

• universal readability is lost. Everyone coping with software can work with patches or patch series, no matter what tools they use.
• visibility of changes is sacrificed for history. Every single VCS I ever saw primarily coped with history. Even patch based ones represent changes in time and not by itself changes by topic.

And of course, a lot can be improved by just using some rules more strictly. Not using a pristine tarball or a proper subset of one where the first is not possible should not be some mere ignorable non-conformist behaviour, but seen as the serious problem it is.

Anyone seen this before? Today, I went to an event about the Sub-National Review Consultation (as a substitute for someone else AIUI). I'd not heard about this before, but if you're in England and you've any interest in our regional planning system (which I think you should, if you have your main home here or run a business here), you have six weeks left to comment on the UK Government's suggested changes. As I understand it, it will move the second-highest tier of planning control from democratically-accountable regional bodies to the business-led Regional Development Agencies, with some oversight by MPs and the very- indirectly-accountable council leaders. I've posted more detail on Co-opNet. When I asked about local involvement and cooperatives, I was directed towards Local Strategic Partnerships, but I'm pessimistic about how easy it will be to influence regional planning through those: a few weeks ago, I was at the launch of the North Somerset Partnership Sustainable Community Strategy for 2008-2026. It's a 72-page A4 glossy book which I've still not found time to read properly. I think the size says something about its sustainability. I've posted a little more detail on WsMForum. I'll try to answer questions about either of them on this blog or those forums...

Mark Shuttleworth has written an interesting post about Ubuntu release dates [1]. He claims that free software distributions are better able to meet release dates than proprietary OSs because they are not doing upstream development. The evidence that free software distributions generally do a reasonable job of meeting release dates (and Ubuntu does an excellent job) is clear. But the really interesting part of his post is where he offers to have Ubuntu collaborate with other distributions on release dates. He states that if two out of Red Hat (presumably Enterprise Linux), Novell (presumably SLES), and Debian will commit to the same release date (within one month) and (possibly more importantly) to having the same versions of major components then he will make Ubuntu do the same. This is a very significant statement. From my experience working in the Debian project and when employed by Red Hat I know that decisions about which versions of major components to include are not taken lightly, and therefore if the plan is to include a new release of a major software project and that project misses a release date then it forces a difficult decision about whether to use an older version or delay the release. For Ubuntu to not merely collaborate with other distributions but to instead follow the consensus of two different distributions would be a massive compromise. But I agree with Mark that the benefits to the users are clear. I believe that the Debian project should align it’s release cycles with Red Hat Enterprise Linux. I believe that RHEL is being released in a very sensible manner and that the differences of opinion between Debian and Red Hat people about how to manage such things are small. Note that it would not be impossible to have some variations of version numbers of components but still stick mostly to the same versions. If Debian, Ubuntu, and RHEL released at about the same time with the same versions of the kernel, GCC, and major applications and libraries then it would make it much easier for users who want to port software between distributions and run multiple distributions on the same network or the same hardware. The Debian Social Contract [2] states that “Our priorities are our users and free software“. I believe that by using common versions across distributions we would help end-users in configuring software and maintaining networks of Linux systems running different distributions, and also help free software developers by reducing the difficulty in debugging problems. It seems to me that the best way of achieving the goal that Mark advocates (in the short term at least) is for Debian to follow Red Hat’s release cycle. I think that after getting one release with common versions out there we could then discuss how to organise cooperation between distributions. I also believe that a longer support cycle would be a good thing for Debian. I’m prepared to do the necessary work for the packages that I maintain and would also be prepared to do some of the work in other areas that is needed (EG back-porting security fixes).

• [1] http://www.markshuttleworth.com/archives/146


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

Share This

Lalala, it’s me again. Don’t shout, it’s not a long post! :) What did we do since I last dared to post with my Ftpmaster head on? (Yes, I should put a summary of all my blog posts into a Bits from mail sometime.)

• Fixed some bugs, like all of the waiting Please create/remove pseudopackage FOO ones. So we now have a BTS entry for wiki.debian.org, release.debian.org and the security-tracker.
• Merged a patch from Thomas so we now correctly reject packages where the maintainer tried to be clever, editing the changes file to get an orig.tar.gz mentioned after forgetting the -sa parameter to dpkg-buildpackage. SIGH. Especially sigh as that ##censored## wasn’t able to understand the format of those lines. Nor did he look, or he would have immediately spotted his mistake. Unfortunately it is not the first time this maintainer broke stuff with uploads he never checked in any way. Including uploads for important packages. Bah.
• Merged another patch from Thomas, which generally makes NEW look nicer. It drops the unneeded Checksums-foo headers completly, no need that we see them there again, they just waste space and are useless for us. The patch also changes the html files we generate for all packages in NEW, something which I added to dak a few months ago - based on a patch from Thomas. :) The stylesheet now applied got sent in from Mart n Ferrari who already created the style for the removals page.
• Done a whole lot of NEW. Yes, I continue to do most of NEW, as I’m still (and possibly for some time) are the one with the most experience and speed in doing it. Thomas is doing NEW too, mostly by picking a few packages and processing them. (Before someone yells - he is doing a very good job with removals and override changes, an area where I haven’t looked much into since he got added to the ftpteam).
• Did, together with Mark Hymers, a lot of cleanup work in the code, using pychecker and pylint. We only started, but there have been various changes already, like
  • change “import daklib.foo” and then using daklib.function to “from daklib import foo” and then using foo.function. Granted, the Ideal way would be to go “from daklib.foo import function1, function2, function3” (or so), explicitly naming every thing you use. Or even better, make the whole dak fully object oriented. Or so. Or whatever. :)
  • replaced all own string exceptions, which are deprecated, with real exception classes.
  The cleanups we did made pylint rate the code 5.21, with the initial rating (before we did anything cleanup related) was 3.59/10. (As if it would count, but still) :)
• Added two more headers to mails generated by dak and the queue daemon, X-Debian: DAK and X-Debian-Package: $something, following a suggestion from Bug #479953. Hopefully other tools follow this schema too, at least I announced it on debian-devel-announce, so hopefully it will be taken as a quasi-standard. :) Ok, yes, I admit, the queue daemon is currently not adding the X-Debian-Package header. It does add the X-Debian: DAK header, but not the package one. I got a headache when looking at it, its old and grown perl code. If someone wants to send a patch, fine, the bzr repository has it in tools/debianqueued-0.9. Update: Now the queue daemin also adds the X-Debian-Package header as I got two patches addressing the issue, in two different ways. Thanks to Stephen Gran and Matt Kraai for their work!

Comments: 2

If you're running Apache2 on a memory-constrained system (like in a virtual machine,) you may want to choose the prefork MPM to save memory at the cost of more process forks. However, if you have more than one CPU on that same machine, you may also want to consider using the threaded worker MPM and tweak its MaxClients and ThreadsPerChild settings from the default configuration. On a typical apache2 installation on a Debian system, the worker MPM configuration looks like this:

<IfModule mpm_worker_module>
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Using these default settings on a resource-constrained system (say a server with 128MB of RAM but with no swap) would be overkill, and the web server processes will definitely eat up all of that memory, leaving little or no room for even simple CGI scripts. In my setup, I experimented with tweaking the values above to get apache2 to serve without eating up too much precious memory. I found that the important values to consider here are MaxClients, which dictate how many clients can connect simultaneously to my server, and ThreadsPerChild, which specifies how many threads of execution can run in a child/worker process. My resulting config becomes:

<IfModule mpm_worker_module>
    MaxClients           15
    MinSpareThreads       3
    MaxSpareThreads       7
    ThreadsPerChild       3
    MaxRequestsPerChild 200
</IfModule>

With this setup, I free up a significant amount of RAM from apache2's hold whle maximizing my thread usage in each worker process; at the same time, I avoid keeping each child process for too long by setting a maximum number of requests each worker can serve, preventing the workers to bloat too much when handling CGI. I also tweaked the KeepAliveTimeout setting to just 2 seconds (instead of the default 15) so that each worker process can go to the next request quickly and preventing them from being tied up to a connection for too long. I also set the Timeout to 30 seconds.

My previous entry features the first ever comment on this blog to arrive over IPv6. Fantastic! I guess this will be the final breakthrough that the protocol needed!!

Some of you might have noticed that in the recent weeks I wasn't active at all online. This was because I was on a vacation in Italy. On the way back I was eager to write about my experiences, but after entering Romania, I found out that may parents had been involved in a motorcycle accident due to a careless driver.

The accident took place on the second day of the Orthodox Easter (on the 28th of April)[1] while my parents were coming back from my sister's, just 20 km away from my home town, Caracal, in a village called Z noaga. There, a Daewoo Cielo was parked on the left side of the road[2], facing the direction towards Caracal. The driver decided that it was a good idea to turn his vehicle and, according to his declaration, instead of looking himself if there was anything comming, he asked a passenger if there were any cars comming.

Since a motorcycle is not a car, I guess the passenger thought it was OK to answer "no".

So the driver simply started his maneuver and managed to occupy the entire right lane, according to the accident schematics (I saw the official police schematics of the accident site with my own eyes). There were only 30 cm from the front most point of the car to the ditch on the right side of road, while the rear wheels were on the mark indicating the axis of the road. That left only 2 meters free on the opposite lane out of the 6.60 meters wide road, so there was no way for my father (driving the motorcycle) to avoid the collision, in spite of the fact he was travelling at about 40-50 km/h[3], within the legal speed limit (50 km/h).

My father barely had enough time to avoid the central pillar and aim for the rear right door of the car, obviously, a safer place to hit. Still, this wasn't enough to keep my mother on the motorcycle, a safer place for her than anywhere on the road.

My mother was projected over my father and over the car, and, luckily, landed on the side of the road, between the asphalt and the ditch, on an area covered with grass. She landed straight onto her head (the helmet protected her really well), and the shock of the landing propagated along the spine, resulting in the fracture of the L1 vertebra. She also got a fissure in the right clavicula, but that should already be OK now.

My father managed to remain on the motorcycle, but the impact was violent enough that he managed to bend the gas tank and has two huge bruises on the inside of his thighs (one for each leg). He also accuses pains in his shoulders and the lower end of the spine (unfortunately he "managed" not to do the medical investigations after the accident), but I hope all of these will pass soon and will have no ill effects. Also, out of sheer luck, at that time, my father was wearing a full-face helmet, contrary to his habit of earing an open-face helmet; due to this, his face was protected and suffered no harm, while the chin of the helmet broke after the impact with the motorcycle windshield. Also some deep scratches starting from the half of the helmet windshield up to the top of the helmet were the signs of a (probably second) violent impact with the motorcycle windshield.



So, the next time you are on the wheel, please look out for motorcycles, too. Motorcycles do exist on the road!

Also, I advice anyone driving a motorcycle to wear good protection equipment like a full-face helmet, jacket, pants, boots, gloves, etc. These helped a lot my parents, and will help you too, if, God forbid, you are involved in an accident.


My mother is in a cast that covers her from hips to shoulders to help with the fracture recovery and also wears a collar (just for safety reasons since she is suffering of spondyloses).
My father is able to walk (with some pain) and seems not to have any injures (I will take him for a close investigation some time soon in spite of his stubbornness).



[1] worrying for us (me and my future spouse), my parents didn't told us and waited for us to return to Romania
[2] in Romania the vehicles travel on the right side of the road, so the driver also drove on opposite lane, a fact which, according to the law, is punished with the suspension of the driving license
[3] he speed was confirmed by the measurements done by the police

One of the biggest questions which has to be answered when one starts a blog is what is the blog engine going to be? (Using a readymade hosted solution like LiveJournal or blogspot is for wimps.) Since the blog is going to be on IMSc's "people" server, there are a lot of choices. The scripting language for the engine is usually a choice between PHP, Perl, Ruby and Python (though with nanoblogger, even a POSIX shell is possible!). The gem looked tempting for a while. Eventually, I realised that the engine is far less important than the entries. Start writing the entries with some engine. It should be "relatively easy" to migrate the entries to a different engine. In some sense, having put essays on the web in the past, a change of engine (from wetware to software) is what I am doing anyway!So the temporary choice is the snake --- think of this is as the snake in the monkey's shadow. Specifically, this blog is currently powered by pyblosxom.

Configuring pyblosxom

StructureSince everything on this blog is meant to be public, all of its data and configuration information is kept in public_html. As far as I can see this causes no security issues --- but if some turn up then it may change!Current directory structure is

blog/ ->
    config.py   Configuration file
    drafts/     -> draft entries
    sources/    -> sources where required
    entries/    -> format of entries is "string"-"date"
    flavours/   -> not tutti-fruity!
    plugins/    -> actual plugins used
    style/      -> stylesheets and images
    index.cgi   -> pyblosxom.cgi renamed
    .htaccess   -> for apache2

Any and all of these files (except drafts) can be examined by extending the URL http://www.imsc.res.in/~kapil/blog by the file or directory name.The development of my web pages is done on my user machine and these are synchronised with the "real" web pages using unison. The local copy of my web pages is managed using git.The plugins were downloaded from the pyblosxom web site.The flavour was downloaded from snarfed.org.Since everything about this blog is visible, there is probably no need to document things further.

Minor cribsI couldn't find anyone who had documented how they had setup their blog using pyblosxom. This meant that it took a while for me to set things up.The apache2 web server behaved rather differently from mathopd. In particular, the latter does not need or use .htaccess files and just declaring that index.cgi was the a CGI script and was the "index file" for the blog/ directory was enough for the blog to start working. However, I had to struggle with apache2 as it needed "Rewrite*" entries in the .htaccess file in order to pick up the style sheets and the blog pages.

I usually don't like me too comments... But this is something that really disappoints me of my otherwise-favorite development framework. I must echo Matt Palmer's comment on Luke Kanies' entry:
Ruby. Has. A. Distribution. Problem.
Nice, good read. Sadly, many Rails pushers see distributability as something very minor, something that should not worry Rails developers right now, as there is too much other serious work to be done - Better UTF8, a clearer language, better performance... And besides, any programmer can live well with gems. (yes, that's all taken from a rant I had with a very convinced person)
My gripe is that... Rails is no longer a small, fringe project. Rails is an enterprise-grade development framework, with thousands of deployed production systems. And if they don't start to act responsably, if the Rails developers keep pushing said problems as low-priority, the Rails developers' (that is, their users) culture will become rigid - and will constitute a serious harm to Rails' future.
Distributability and packageability is not only for OS distributors. Not only we Debian zealots care about software being easily packageable. By using Ruby Gems, you dramatically increase entropy and harm your systems' security.
Read Luke's text for more details. It is quite worth the time.

Those of you who know me might be aware that I have a fondness for cool and neato hardware which is possibly a tiny bit above that of the average geek. I have more nodes on my ThinNet than on my TP network, for example. Back in February, I had the random idea to call SGI Norway and ask them if they had anything they were about to throw out. I knew that they were working hard on moving from MIPS to Itanium, so perhaps some hardware was disappearing along the way. Oslo didn’t have anything, but when I called Bergen I found out that they were about to throw out a large amount of hardware, including some really nice boxes like an Onyx2 deskside workstation, and some Origin systems. For those of you who aren’t into SGI machines, I can sum it up by saying that these are really cool computers: Big, noisy as hell, heavy, and in terms of performance, nearly on par with a normal desktop nowadays. In short, fantastic educational toys. So, this was in February, and we were making arrangements for transport to Oslo, until one day I stopped receiving mail. I didn’t think much of it; email is asynchronous, and I figured he was busy doing something else. I was certainly very eager to get at the machines, but didn’t feel like nagging at him either. Finally, recently I sent him a polite reminder, and I get the rather rude response: Diagnostic code: smtp;550 cuda_nsu 5.7.1 <****@sgi.com>: Recipient address rejected: THIS USER IS NO LONGER WITH SGI. CONTACT help@sgi.com IF YOU NEED INFO. I tried calling the Bergen office, but the number was out of service. So I call the Oslo office - and I am told the Bergen office has been shut down, and all the equipment has been thrown out. This is the bummer of the century, for two main reasons:

1. I’m not getting cool hardware that I was totally looking forward to getting,
2. Great hardware has now been ground up for use in car tires.

For some odd reason, the second reason is infinitely more grating than the first. I feel like a museum curator being forced to watch someone feed a Picasso painting to a paper shredder. This really, really screwed up my day.

When I look at how people are using the net, I see a spectrum... At the low end, there are users who browse, and maybe post stuff to sites like flickr or youtube or wikipedia. When I hang out with these people, I'm struck by them being often quite smart, savvy, capable (and young), and wasting a lot of their time and inginuity fitting what they want to do into these narrow and (mostly) corporate-controlled and censored channels. And being limited by it in ways that they're not fully aware of. If you're in this group, please, please consider finding a way up the spectrum. At the high end are tecchies like me, we have at least one and often multiple servers, sometimes even in different countries/continents. We can write and run our own software with full control. This excellent advogato article calls it the "sovereign" level. We're not exactly kings when you look at who controls things from DNS to the internet backbone, but we're as close as it's practical to be without running your own wires. And we're statistically vanishingly few these days. So the middle is more and more interesting. For one thing, being king is expensive. So some of us move down a level, to virtual servers with xen or the like. Maybe we can't build our own kernel on our server anymore, but we don't have to worry about maintaining spinning disks and fans. And some people move up to this level too. One path is learning about running linux on a personal machine and then using an easy and cheap provider like slicehost. But still, users at this level are rare. The other interesting level (and the one I've not explored much myself) is a step up from the low end, where you have some form of inexpensive shared hosting, but can at least run your own code. This level seems quite a mess, there is no standardisation, everything has to be set up by hand, unless you use prepackaged control panel type things that probably take away most of the empowerment available at this level. A lot of people reach this level, but it's still fractions of a percent. So there seems quite a hump up from the lowest end of the empowerment spectrum to using shared hosting. How to encourage people over that hump is an interesting problem.

---

I've been playing with using some power tools from the top, sovereign level down in these murky shared hosting depths. Decided to see what kind of stuff I could accomplish for $5. Although it ended up costing only 2 cents for hosting so far. Amazon and google's hosting servives look interesting, but need things to be designed explcitly for them. And those companies are too big already. NearlyFreeSpeech.net is more flexible, funky, and has a cheap pay-as-you-go pricing that's ideal for little things that will only use a few dollars of bandwidth. So, I got ikiwiki working there (and documented how), along with a git backend, so my wiki's sources can be cloned to elsewhere for backups and development. Some things I hope to do later include:

• Allowing ikiwiki aggregation to be kicked off via the web. There's no cron jobs on these systems so you have to use something like webcron. (Which I dreamed up last night, but am happy to see someone else already implemented.)
• Implementing Madduck's idea to trigger ikiwiki mirrors via the web. So you can set up a cluster of mirrored wikis on disparate shared hosting.
• Using Amazon s3 to store wiki pages and handle file serving.

Andrew Caudwell's Logstalgia (aka ApachePong) has made it to Debian! It's a fun little Apache access log viewer which replays old logs (or streams live ones) as an OpenGL pong game.

So grab your favourite high-traffic access log and head over to the download page to check it out. There's also a youtube video if you can't find an interesting log file to use it with.

Ooops. When a room full of computer equipment gains a strong smell, there are a couple of possibilities (!) but the characteristic odour of singed electronics and lack of video output on one box is fairly indicative and all I could do was turn off the power on the UPS.

Definite smell associated with one box, smell gets worse when that box opened up, smell seems concentrated around the graphics card. Most weird is that the computer affected seems to restart ok at which point the smell reappears so knock the power off again - fast. Smell stays with the graphics card when card removed - it's surprising how long that smell hangs around. Remove graphics card, retest the machine - hang on - this sounds like a normal boot. Hmm - plugin the network cable, bingo - everything else appears to work - sans smell. Graphics card still has a strong odour even just sitting on the desk.

I've just suffered a graphics card burn out. Damn damn and double damn.

The machine itself is now running fine, just without a graphics card and thereby monitor. Accessing via ssh, dmesg shows the inevitable fsck but no other signs of harm except:
$ ps af
PID TTY STAT TIME COMMAND
3388 pts/0 Ss 0:00 -bash
3410 pts/0 R+ 0:00 \_ ps af
3256 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen
3297 tty7 S+ 0:00 \_ /usr/bin/dialog --yesno Failed to start the X ser

$ sudo invoke-rc.d gdm stop



Why would an archive rebuild cause a graphics card to burn out? (I was running an autobuilder script but I don't run any screensaver on that box.)

Ah well, gives me an excuse to test the whiptail mode of emrecent and see if I can upload the packages that were built before the failure to Emdebian target. Another unexpected expense - 2008 is getting expensive!

Practically ever since Jeff and I released littler to add easy scripting for R, questions popped up about how to support getopt-alike command-line parsing. And as of today, a new package r-cran-getopt is in Debian. It provides Allen Day's recently released package getopt from CRAN which provides a new function getopt. Given a suitable data structure that provides long and short-form command-line option names, whether arguments are mandatory, optional or not required (as for flags), and a data-type, getopt munges the command-line arguments supplied by the user and fills a new variable opt accordingly. If a fifth columns with help text is provided, a usage string can be generated as well. Thanks to Allen for writing getopt, for accepting a quick two-line patch extending support from Rscript to littler, and for fixing one or two minor bugs. Thanks also to the Debian ftpmasters for adding r-cran-getopt within a few days.

Lets go on your nerves again with a ftpmaster post about work I’ve done in the recent past.

• The already mentioned move of britney. And it seems that this did help, so something that should have been done way earlier already… Oh well.
• Enabled a few triggers for the qa user on merkel. While I already mentioned them in my first post, there is a third one now. The qa user now gets notified at the beginning of the dinstall run, so the pages can show why packages might not be visible in the archive and in incoming right now.
• Split up the insanely huge mbox files we had as the ftpmaster mail archive. They got that big because the monthly cronjob rotating them got disabled when the ftp-master archive went away from raff, and noone bothered to reenable that job. Done now, so we are back to a manageable size. (Even if 90% of the content is spam, no matter how much greylisting and blacklists are activated :( ).
• Just committed a largish change thats nothing more than a cleanup. Someone in the past did love to not care about tab versus spaces for the indentation, so dak code ended up with a mess of tab/space mix for indentation. Which is not nice, one style is way better. Fixed that with the help of reindent.py, which one can find in Pythons examples.
• Got the code on security.debian.org to use the latest dak revision from ftpmaster. It was a few commits behind, but worse - it did have one dak tool changed in a way that it only worked on security, no longer on ftpmaster. Also some files that clearly have been copied by scp -r or rsync, but not using the VCS that should be used for it. Args. Brrrr. The “fix” was a simple check if that value the code wants to use from the config file actually exists, instead of blindly assuming it will always be there.
• Generally looked around on security.debian.org, to get more familiar with the setup there, so I can work on a request I got from some members of the security teams: Run a queue daemon that manages the upload of the packages from the security archive to the normal archive (so they end up in proposed-updates). Currently it is done with some lftp calls within the script that does the security install, and that seems to break every now and then. Which means security uploads to proposed-updates randomly go MIA. Using a queue daemon and then only locally copy files into its dir should make that way more reliable.
• Used a tool from Dato and enabled bzr commit mails for the ftpmaster dak tree, they are now going to the dak list.
• Modified the cronjobs that are expected to have output to log that into files in a new logdir. Also modified the cron.daily AKA dinstall cronjob to be more verbose about the actions done. The directory is synced to merkel too (log/cron in the ftp.debian.org tree), so every DD who wants to can look at them now.
• I also merged a small patch from Thomas, fixing/unifying some wording in reject messages.

Comments: 3

So I wrote an entry on my tumblelog about what s going on with my life currently. Since Tumblr s feed doesn t get pushed immediately, I showed the post to my co-worker and friend Chris, before it hit the planets: - So, yeah I have my blog since it s syndicated on Planet Debian and other small feed aggregators -I said. - But do they really care about your bike, your chess games or you attending that conference? -he asked-, I mean, I do care, but people? - Well -I replied after a quick thought-, I think that s how personal blogs work. After a deeper thought I just realized that indeed no one cares and deleted the entry before it was pushed to the feed, updating it on FeedBurner, etc. It was a nice awakening.

---

But on a bit more interesting (for people) things, The Perl Foundation is currently requesting comments on the projects they received for grant requests. My proposal is there, Solidifying and Extending the Blog Normalize project . I do think there are some other more deeper projects, of course, but I think B::N is also an interesting one and the amount requested is not as big for other projects, so it d be nice to give it a try. I believe B::N is a good idea that could be enhanced nicely. I proposed the idea to the TextMotion developers yesterday on IRC (since that s one of the CMS there would be a connector for -as of the grant proposal-). After deeper discussion, CMSs will not make translators for a lot of projects into theirs, but B::N would, so maybe we could make some sort of webservice that CMSs could call on their installation phases. That, or the user at the end could actually do the conversion himself locally. Having the proper information, one could be able to get from TextMotion to Wordpress, to Blogger, to Joomla, to Tumblr, to MovableType and to TextMotion again, making a transparent circular transformation. Some of this is currently possible with the few code I ve written for it, currently in CPAN (and a bit deeper proof of concept); if you are interested, please leave your comments on the Perl Foundation blog entry. And review others too. At the end, I might end up doing the project myself, but if some money is granted to do so, why not apply to it, that d just speed it up.

I’m currently in Xen hell. My Thinkpad (which I won’t replace any time soon) has a Pentium-M CPU without PAE support. I think that Debian might re-introduce Xen support for CPUs without PAE in Lenny, but at the moment I have the choice of running without Xen or running an ancient kernel on my laptop. Due to this I’ve removed Xen from my laptop (I’m doing most of my development which needs Xen on servers anyway). Now I’ve just replaced my main home server. It was a Pentium-D 2.8GHz machine with 1.5G of RAM and a couple of 300G SATA disks in a RAID-1. Now it’s a Pentium E2160 1.8Ghz machine with 3G of RAM with the same disks. Incidentally Intel suck badly, they are producing CPUs with names that have no meaning, and most of their chipsets don’t support more than 4G of physical address space [1]. I wanted 4G of RAM but the machine I was offered only supported addressing 4G and 700M of that was used for PCI devices. For computation tasks it’s about the same speed as the old Pentium-D, but it has faster RAM access, more RAM, uses less power, and makes less noise. If I was going to a shop to buy something I probably would have chosen something different to get support for more than 4G of RAM, but as I got the replacement machine for free as a favor I’m not complaining! I expected that I could just install the new server and have things just work. There were some minor issues such as configuring X for the different video hardware (and installing the 915resolution package (which is only needed in Etch) to get the desired 1650×1400 resolution. But for the core server tasks I expected that I could just move the hard drives across and have it work. After the initial install the system crashed whenever I did any serious hard drive access from Dom0, the Dom0 kernel Oopsed and network access was cut off from the DomU’s (I’m not sure whether the DomU’s died but without any way of accessing them it doesn’t really matter much). As a test I installed the version of the Xen hypervisor from Unstable and it worked. But the Xen hypervisor from Unstable required the Xen tools from Unstable which also required the latest libc6, and therefore the entire Dom0 had to be upgraded. Then in an unfortunate accident unrelated to Xen (cryptsetup in Debian/Unstable warns you if you try to use a non-LUKS option on a device which has been used for LUKS and would have saved me) I lost the root filesystem before I finished the upgrade. So I did a fresh install of Debian/Unstable, this time it didn’t crash on heavy disk IO, instead it would lock up randomly when under no load. I’ve now booted a non-Xen kernel and it’s working well. But this situation is not acceptable long-term, a large part of the purpose of the machine is to run virtualisation so that I can test various programs under multiple distributions. I think that I will have to try some other virtualisation technologies. The idea of running KVM on real servers (ones that serve data to the Internet) doesn’t thrill me, Tavis Ormandy’s paper about potential ways of exploiting virtual machine technologies [2] is a compelling argument for para-virtualisation. Fortunately however my old Pentium-3 machines running Xen seem quite reliable (replacing both software and hardware is a lot of pain that I don’t want). In the near future I will rename the Xen category on my blog to Virtualisation. For older machines Xen is still working reasonably well, but for all new machines I expect that I will have to use something else - and I’ll be blogging about the new machines not the old. I expect that an increasing number of people will be moving away from Xen in the near future. It doesn’t seem to have the potential to give systems that are reliable when running on common hardware. Ulrich Drepper doesn’t have a high opinion of Xen [3], the more I learn about it the more I agree with Ulrich.

• [1] http://en.wikipedia.org/wiki/List_of_Intel_chipsets


• [2] http://taviso.decsystem.org/virtsec.pdf


• [3] http://udrepper.livejournal.com/tag/virtualization

Share This

May 1st is a holiday in many countries around the world - It is, at least, here in Mexico. So, what's a man to do when faced with really-crappy network connectivity at home?
Yesterday I had dinner with Gigio, and among many other things, we talked about the Ciclot n, which I've only done twice. And on my way back home, I crossed (twice) the path of a group of ~100 cyclist going over Colonia Roma.
Anyway, whatever the reason, I woke up very well in the mood for a nice 20km ride:

Now, lets get the day started!
[update] I was told about a worldwide nudist cycling activity, the World Naked Bike Ride. Their page states their main motivator:

We face automobile traffic with our naked bodies as the best way of defending our dignit and exposing the unique dangers faced by cyclists and pedestrians as well as the negative consequences we all face due to dependence on oil, and other forms of non-renewable energy.

Of course, Mexican groups take part in this interesting activity - Ciclomarcha nudista.
Will I be there? I don't know - Quite probably, yes. I first thought of it as a joke, and as a dangerous activity. But, come think of it, I am a move-by-bicycle-in-the-largest-city-in-the-world activist. I have been knocked over or shit-scared (and fortunately not more than that) by careless drivers, but than won't force me back into driving my car when not needed. And this kind of activities, which do get their good share of exposure, need all the participants - I hope to be there, June 7 12:00PM, at the beginning of Mexico City Ciclopista (FFCC de Cuernavaca esq. Ej rcito nacional, Polanco) Chapultepec's Lions' entrance, at the crossing of Lieja and Reforma.

Share the awareness. There are very good promotional pictures. And collective nudist activities are quite fun, experiences to remember for life.

I just added two new developers to the reportbug project on Alioth, Sandro Tosi and Y Giridhar Appaji Nag, who seem to be enthusiastic about working through the big backlog of bug reports and wishlist requests associated with the package. Since my Debian-related interests are largely elsewhere these days, mostly focused on R stuff that has a more tangible relationship with my research (and by extension my future job mobility and/or tenurability) and a few other infrastructural things in Debian (primarily LSB support and printing), I think this is a good development overall. But still, when you’ve been hacking away at something for almost nine years it’s hard not to develop a bit of a sentimental attachment to it. I still plan to be doing some hacking away at reportbug, but hopefully the new blood can take the lead in terms of day-to-day maintenance while I work on some of the desperately-needed code refactoring issues with the software.