I finally bought myself an eBook reader. To be precise, I got the Sony PRS-600 Reader Touch Edition. Two reasons:
Currently, the main product of the Debian project is its stable release[1]. Those release come out approximately every 18-24 months. This article gives a short overview of the process leading to the next stable release.
Creating a new distribution
Immediately after a stable release, a new distribution is created in the Debian archive. Its initial content is a copy of the (just released) stable distribution. Its codename is decided by the release managers and there s a tradition of picking a character s name from the Toy Story movie.
As an example, the wheezy distribution will be created once squeeze (aka Debian 6.0) is out.
For simplicity there s a generic name to refer to the distribution used to prepare the next stable release: it s testing. In the Debian archive, testing is just a symbolic link pointing to the right directory (squeeze currently).
Updating packages, working on release goals
During most of the cycle, developers work on packaging new upstream versions and implementing release goals. They upload their packages in the unstable distribution.
From there packages trickle to the testing distribution once they satisfy some quality checks: they must not have new release-critical bugs, they must have been built on all architectures that were previously supported, they must not break any dependency in testing, and they must have spent at least 10 days in unstable.
This minimal period ensures the package has been tested and gives enough time to users to file bugs if the package is suffering from problems. If the problems are deemed release-critical, they will block the migration of the package to testing.
During this part of the release cycle, the main work of the release team is ensuring that updated packages flow from unstable to testing. It can be a tricky task: package dependencies frequently tie packages together so that they can only migrate to testing together. If only one of the tied packages is not ready (for example if a new revision has been uploaded and has not spent 10 days in unstable yet), then none of them can migrate.
Stabilizing, polishing, fixing release-critical issues
The constant churn of new packages makes it very difficult to build a very polished release. That s why, at some point, release managers freeze the testing distribution: automatic updates are stopped and they vet every single update made to testing. They have strong requirements, the goal is to only allow updates fixing release critical bugs, or those which are low-risk and bring significant value to the user experience (like new translations, updated documentation, etc.).
During freeze, some packages are also removed because the current upstream version can t be supported for the lifetime of the stable release.
The freeze tends to slow down the pace of changes in unstable. Many maintainers opt to push new upstream versions in experimental instead so that if they need to update their packages in testing, they can still do it through unstable. This procedure is recommended by the release managers because it means that updates that they unblock have been tested as usual. It s not the case for updates uploaded directly to testing (through testing-proposed-updates).
This behavior is rather annoying for the bleeding-edge users that use testing or unstable like a rolling release.
Release time
Once release managers are satisfied of the quality of the new distribution, some last minute work is needed, like generating the CD images. In the Debian archive, the release is made official by pointing the stable symbolic link to the new distribution (and the oldstable one to the previous distribution).
Now it s party time, the cycle is over, and a new one can start. 
[1] The Constantly Usable Testing project aims to make testing a first-class product like stable but with a very different update policy.
Follow me on Identi.ca, Twitter and Facebook.
When talking about free culture or free software, many people suggest
that they would love to support free models, but that they don't see
how to make it all work. Until they have an alternate model in front
of them, they cannot bring themselves to argue for a more ethical
alternative. I disagree with this approach. Instead, I say, "this is
the world I want to live in and, even though I don't know exactly how
to get to there from here, I'm going to refuse to settle for anything
short of this ideal." Most people dismiss such thinking as
"impractical" and "unrealistic." I think most people are being
unimaginative.
Robot jockeys are one recent illustrative reason, among many,
that I feel comfortable taking this position. Some background is
necessary for those that are unfamiliar with the example. A decade
ago, several Gulf emirates used thousands of young boys from Sudan and
South Asia as jockeys for camel racing. Human rights groups
campaigned against the practice and suggested that these boys were
at sometimes held as slaves and intentionally underfed to keep their
weight low. Despite criticism, camel racers resisted moving away from
young boys as jockeys. If they moved to heavier adults instead of
young boys, they reasoned, the camels would be much slower. Of course,
they were right. But they were being unimaginative in the alternatives
they were considering.
As the young jockeys became a increasingly unjustifiable public
relations disaster for the states that supported it, law-makers in
several Gulf states gave in to calls from UNICEF and others and
created laws to outlaw the practice. Within three years of UAE
passing strict laws against child jockeys, Swiss engineers, funded
by racers desperate for an alternative, had created the first robotic
camel jockey. Within several years these jockeys were lighter,
cheaper, more responsive to the owner, and well on their way to being
more effective than any young boy. When forced, by law and by an
ethical prerogative, to come up with an alternative to young boys,
racers created a solution that was superior, along nearly every axis,
to the system they had fought to keep.
Although the costs to society of proprietary software cannot be
compared to slavery and abuse, the basic same pattern of
solution-seeking can be seen in the example of free software. Early
free software advocates suggested that most programmers would likely
need to take a paycut. As it turned out, vibrant and successful
economic models to support free software have supported a large and
growing free software industry. But we have free software business
models only because a small group of principled individuals refused to
settle for what they knew, came up with creative ethical business
models that "just might work," and put their own paychecks on the line
to try them out. As open source has shown, some of these creative
solutions offered models superior to what we had before. In the world
of software development, free software redefined "practical" and
"realistic."
One can think of solving human problems as like searching for the
highest point in hilly terrain in thick fog. It's easy to get stuck on
the top of the first little hill you walk up (i.e., a local maximum)
and then conclude you can never do better. If we refuse to
compromise and force ourselves to leave that first little
hill, chances are pretty good we'll find a "higher" peak.
Of course, it is also possible that we will find the global
maximum or the best possible solution to a given problem. In
those cases, any change will mean a sacrifice. But when dealing with
most most social and legal dilemmas, there are enough variables
involved that this seems very unlikely. Indeed, most big problems can
be thought of as having many interacting dimensions -- and only some
of these will be ethical concerns. In other words, most social
problems are more like the problem of child camel jockeys than they
are like trying to transcend the laws of physics.
Business models and laws for the regulation of technology and
knowledge are extremely complicated human creations. Do we really
think we cannot create ethical systems to compensate cultural creators
that are at least as good as what we have now? If we never force
ourselves to be "impractical" and "unrealistic", we will never find
out.
Within the next few days there will be the openSUSE conference held in Nuremberg/Germany. The topic of the conference was set to Collaboration Across Bordersand along that theme they invited other distributions to submit talks. Given my involvement with the Derivatives Frontdesk zack asked me whether I'd like to submit a talk proposal. I usually have a hard time to refuse such questions this will actually happen. My talk will be in the Distributions Track on Thursday afternoon, the topic is
Debian The Project and its Resources. The resources that I will cover are those that can be very useful to other distributions too, and last Thursday I tested the talk at our local Debienna Meeting, gathered further ideas and feedback to cover in the talk. Thanks to you, guys! Unfortunately contrary to what we are used to in Debian (extraordinary thanks to the Video Team!!!) there will be no streaming or recording of the talks from what I was told, so you have either to hurry to be there, or be satisfied with the slides I'll put up after the talk. It's the best I can offer. See you around!
After a somewhat long hiatus,
RPostgreSQL version 0.1-7 has now been released to
CRAN. RPostgreSQL
connects R to
PostgreSQL database systems using the standard
DBI interface.
This version fixes a number of issues that had been compiled in the
issue tracker
on the project
site at Google Code.
Tomoaki Nishiyama, who joined our small development group for his package a few weeks ago, was instrumental in a number
of these fixes, with assistance from Joe Conway.
The relevant NEWS file entry follows below:
Version 0.1-7 -- 2010-10-17
o Several potential buffer overruns were fixed
o dbWriteTable now writes a data.frame to database through a network
connection rather than a temporary file. Note that row_names may be
changed in future releases. Also, passing in filenames instead of
data.frame is not supported at this time.
o When no host is specified, a connection to the PostgreSQL server
is made via UNIX domain socket (just like psql does)
o Table and column names are case sensitive, and identifiers are escaped
or quoted appropriately, so that any form of table/column names can be
created, searched, or removed, including upper-, lower- and mixed-case.
o nullOk in dbColumnInfo has a return value of NA when the column does
not correspond to a column in the table. The utility of nullOk is
doubtful but not removed at this time.
o Correct Windows getpid() declaration (with thanks to Brian D. Ripley)
o A call of as.POSIXct() with a time format string wrongly passed to TZ
has been corrected; this should help with intra-day timestamps (with
thanks to Steve Eick)
o Usage of tmpdir has been improved on similarly to Linux (with thanks
to Robert McGehee)
More information is on the
my RPostgreSQL page, and on
project site at Google Code.
aptitude install tor .The package will install and run by default the tor daemon. Next step is to edit /etc/tor/torrc to add the proxy server. aptitude install connect-proxy. It's a simple tool to tunnel ssh through a socks5 connection. Now you are ready to test. In your ~/.ssh/config you can simply add something like 
I've recently become more serious about my photographic hobby and it dawned onto me that manually editing each JPEG to add my copyright was entirely the wrong approach. Thus, I was wondering if anybody would know of a Free Software tool that can batch edit the EXIF data in JPEG images? What I'd like to accomplish is simple:
Copyright $YEAR Martin- ric Racine where $YEAR is directly extracted from the original EXIF data's day when the picture was taken.
/etc/network/interfaces for it. Moreover to selecting always switch to a wired connection when available will make Wicd to leave alone you routing tables even if there is a wireless connection available that is marked as automatically connect to this network.
Second you need to install guessnet and ifplugd /etc/network/interfaces. With the scheduled R release of version
2.12.0
this morning, we have just uploaded version 0.8.7 of
Rcpp
to CRAN;
Debian will follow shortly once the
autobuilders have processed R 2.12.0
This Rcpp release depends on R 2.12.0 as two things have changed. First, we
play along with change in R concerning the ordering of inheritance for time
classes. But secondly, and more importantly, we support in Rcpp the
corresponding change R itself which brings the new ReferenceClasses. Here is
corresponding bit from R's NEWS file for R 2.12.0:
o A facility for defining reference-based S4 classes (in the OOP
style of Java, C++, etc.) has been added experimentally to
package methods; see ?ReferenceClasses.
[...]
o An experimental new programming model has been added to package
methods for reference (OOP-style) classes and methods. See
?ReferenceClasses.
This was made possible in large part by code committed by
John Chambers
(whom we had welcomed recently as a co-author to
Rcpp) building on
the changes he made to R 2.12.0 itself, as well on the work Romain had done
with 'Rcpp Modules'. The R help page for ReferenceClasses
carries a reference (bad pun) to Rcpp 0.8.7 so these two releases do go
together. This should be a lot of fun over the next little while:
S3, S4, and now ReferenceClasses.
We also made a number of internal changes some of which leads to speed-ups
and internal improvement. The NEWS entry follows below:
0.8.7 2010-10-15
o As of this version, Rcpp depends on R 2.12 or greater as it interfaces
the new reference classes (see below) and also reflects the POSIXt class
reordering both of which appeared with R version 2.12.0
o new Rcpp::Reference class, that allows internal manipulation of R 2.12.0
reference classes. The class exposes a constructor that takes the name
of the target reference class and a field(string) method that implements
the proxy pattern to get/set reference fields using callbacks to the
R operators "$" and "$<-" in order to preserve the R-level encapsulation
o the R side of the preceding item allows methods to be written
in R as per ?ReferenceClasses, accessing fields by name and
assigning them using "<<-". Classes extracted from modules
are R reference classes. They can be subclassed in R, and/or R methods
can be defined using the $methods(...) mechanism.
o internal performance improvements for Rcpp sugar as well as an added
'noNA()' wrapper to omit tests for NA values -- see the included
examples in inst/examples/convolveBenchmarks for the speedups
o more internal performance gains with Functions and Environments
As always, even fuller details are in
Rcpp Changelog page and the
Rcpp page which also
leads to the downloads, the
browseable
doxygen docs and zip files of doxygen output for the standard formats.
A local directory has
source and documentation too.
Questions, comments etc should go to the
rcpp-devel mailing list
off the R-Forge page
libfoo.pc to AC_CONFIG_FILES
and let configure and config.status generate it directly.
This is simpler, but it has two problems:
configure with one prefix setting and then overriding
that setting when running make should build software using the
overridden prefix. This isn't necessary very often, but there are
times when it's very useful, particularly when rebuilding parts of the
tree. Generating the pkg-config configuration file from the Makefile
ensures that this works properly.
./configure --libdir='$ datadir '(admittedly, more common to do that the other way arond) but that would fail with a pkg-config configuration file generated directly from Autoconf unless I'd anticipated that usage and added both
datadir and
datarootdir to the pkg-config template even though I wasn't using
either.
I've updated my build system coding
style page to include this rationale.
When I took over the developement of xen-tools, I looked around for an
appropriate git hosting. I especially had a look at GitHub and
Gitorious.
If you just regard the features, GitHub is definitely more targetted on
single developers and Gitorious more towards projects:
At GitHub, every repository has its URL under the URL of a user page
which makes it nearly impossible to have user independent, official
repositories for projects which have more than one official developer.
At Gitorious, every hosted repository needs to belong to a project,
even if it s only a published configuration. But a project can have
more than one git repository. You only seem to be able to have
personal repositories if you clone some existing Gitorious repository.
So from a feature point of view, the xen-tools git repositories
fit way better to Gitorious hosting while the git repositories with
zshrc, conkerorrc and desktop
configuration files defintely have a more fitting addresses on
GitHub, in my case http://github.com/xtaran/$repository. On Gitorious, they are now
together under a project called Axel s configuration files at http://gitorious.org/abe which contains git repositories of my on
grml s .zshrc based .zshrc, my configuration for Conkeror and all the files
necessary for my ratpoison/xmobar based netbook/laptop desktop.
I though feel a little bad for giving the project the very short
slug name abe instead of abe-config (as I did initially) since
abe is IMHO not a proper project name for my configuration files
and possibly other
projects would have a more reasonable claim for that project name
on Gitorious. But that way it suites more its purpose: Gather some of
my git repositories which don t belong to a proper project.
But there s another important point when comparing Gitorious and
GitHub: Free Software needs free tools as Benjamin Mako Hill posted recently on
Planet Debian. Despite my (probably well known) distrust against
Google and therefore also Google Code, and despite knowing the history
of SourceForge becoming non-free, I was not that much aware that
GitHub s software is only partially open source and therefore also not free software
while Gitorious
is both as it s licensed under the GNU Affero General Public
License (like StatusNet/identi.ca for example) which is basically
GPLv3, but its ideas applied to hosted web applications scenario
(where the GPL itself doesn t grasp), too.
Initially I just had the xen-tools git repositories on Gitorious and
all my small one-repository projects as copies of the repositories
on my own git server on GitHub to
get some more publicity for them and allow social cloning . After
reading Mako s article, I decided to at least have repository
clones on Gitorious of all repositories I mirror at GitHub, too.
That way I force nobody to use the non-free tools on GitHub for
social cloning one of my git repositories. And of course I have
copies of my code somewhere on the net as backup. Or to say it with
Linus Torvalds (slightly updated) words: Only wimps use tape backup: real men just upload their important stuff on git, and let the rest of the world clone it.;-) But isn t that tedious to always push your code to three repositories? No, it isn t. I just push my code to git.noone.org where I have configured the according remotes and the following
post-receive hook:
#!/bin/sh
read oldrev newrev refname
git push gitorious $ refname:t
git push github $ refname:t
The only other thing necessary is to use ssh-agent and SSH agent
forwarding to at least the host you re pushing to.
I was fortunate to get to take a ride on the airship that has in recent times
taken up residence in our back yard.
It was a 90 minute flight around the South Bay Area (south over CA-85, then
north to Stanford over I-280), over the bay itself to Fremont, over the salt
evaporation ponds, and then back to Moffett Field.
Visibility was fairly good, but there was a bit of smog around.
The airship itself was really cool. It only seats 12 people, and it wasn't
quite full. I didn't count the passengers, but there were about 3 or 4 empty
seats. Once the airship stopped its initial climb, we were free to leave our
seats and roam the gondola.
There was an openable window at the front and rear of the gondola, and it
was big enough to stick your head out, which made for some good photos. At
the back, was a bench seat, and an inclined window, so you could lean right
out the back. Even the lavatory had a window.
The cockpit was literally just at the end of the gondola, so you could
inspect all the controls and instruments, and have a chat with the pilot.
Disembarking was a delicate counter-balancing affair. Two people off, two
people on. We were the first load of passengers for the day, so they
jettisoned a heap of water once we were all on board.
Overall, it was a lot of fun, and a very smooth ride. I'm not sure that it's
worth $495, though.
Photos from the flight are here
I just had another conflict with a debatable anti-spam configuration. I think it was debatable rather than obviously wrong, so I m not going to rant about the specific setup, but while discussing it with other postmasters, the following two Domain Name Service Blacklist (DNSBL) facts surprised me:
#599945 at the
time, ta-da! I love it when a plan comes together!
Just as a reminder, the main idea behind those bug reports is to get
as many FTBFSes as possible reported, as
previous mentioned.
How many X packages can be uploaded between two dinstall runs?
14 packages. Now that things are settling down a bit on the
squeeze front, I managed to have a look at X Server 1.9 (more
precisely, 1.9.0.901 aka 1.9.1 rc1), which had already been worked
on by Christopher James Halse Rogers (thanks!). Uploaded source
packages include:
xorg-server: the X
server itself. Selective users want
xserver-xorg-core
and xserver-common
from that one.xorg: a set of
Debian-specific
meta-packages. xserver-xorg
is mostly what s wanted from that one.xserver-xorg-video-fbdev: a FrameBuffer-based video driver.xserver-xorg-video-vesa: the well-known generic video driver.debian-x@ is listed in
Maintainer. That means xserver-xorg-input- acecad, aiptek,
elographics, evdev, joystick, mouse, penmount,
synaptics, vmmouse, void.ati/radeon, intel, and nouveau)
drivers? More on that later; if you want to test 1.9 with those,
pick xserver-xorg-dev from experimental and build your driver
against it. Hopefully only a few days should pass before you get an
update on that topic.
How many times did this blog go haywire?
Possibly none, even though it was recently reworked so that
http://ikibiki.org/ and http://blog.ikibiki.org/ are
distinct. Some d-i or xorg tags may be added to older posts when
time allows, but those shouldn t pop up in planet again.
#599945 at the
time, ta-da! I love it when a plan comes together!
Just as a reminder, the main idea behind those bug reports is to get
as many FTBFSes as possible reported, as
previous mentioned.
How many X packages can be uploaded between two dinstall runs?
14 packages. Now that things are settling down a bit on the
squeeze front, I managed to have a look at X Server 1.9 (more
precisely, 1.9.0.901 aka 1.9.1 rc1), which had already been worked
on by Christopher James Halse Rogers (thanks!). Uploaded source
packages include:
xorg-server: the X
server itself. Selective users want
xserver-xorg-core
and xserver-common
from that one.xorg: a set of
Debian-specific
meta-packages. xserver-xorg
is mostly what s wanted from that one.xserver-xorg-video-fbdev: a FrameBuffer-based video driver.xserver-xorg-video-vesa: the well-known generic video driver.debian-x@ is listed in
Maintainer. That means xserver-xorg-input- acecad, aiptek,
elographics, evdev, joystick, mouse, penmount,
synaptics, vmmouse, void.ati/radeon, intel, and nouveau)
drivers? More on that later; if you want to test 1.9 with those,
pick xserver-xorg-dev from experimental and build your driver
against it. Hopefully only a few days should pass before you get an
update on that topic.
How many times did this blog go haywire?
Possibly none, even though it was recently reworked so that
http://ikibiki.org/ and http://blog.ikibiki.org/ are
distinct. Some d-i or xorg tags may be added to older posts when
time allows, but those shouldn t pop up in planet again.
Blog Action Day approaches on Friday. The call this year is for clean water and some high profile blogs including the UKFCO and the White House will be joining in.
But until then, you can look at the wonderful direct blog action by Lars Wirzenius In defense of Nicole and others after this shocking episode. I hope Lars is wrong in this case and the Davids will join together in their common interest to overthrow the Goliath.
There is a far longer prelude than Lars describes, going back to the April 2005 launch of Liblime (announcement here). An independently-authored history of Koha and LibLime and the recent problems can be found at LWN.net (US$7/month if you woud like to subscribe and support LWN).
Actually, I m not sure if PTFS is even a Goliath. They seem to stomp around a lot, but how big are they? Biggest credible guess I ve seen is 125 people across all products (not only Koha), which is fewer than the 150ish Koha-Community developers (not all supporters). So there you have it: Koha is bigger than PTFS. Literally.
As Christian mentioned, the Debian Keyring Maintainers did a promote this weekend of the new keyring. I figure it s an opportune time to perform a public key transition, since this had the effect of replacing my key on the keyring.
For my new key, 0xF9FDD506, I decided to opt for a 4096-bit RSA, which is stronger than I should have to worry about for the foreseeable future. The key is much better connected than my previous one, 0x0AC70206. I also have a transition document, ripped almost word-for-word from Christian s.
If you signed my previous key, you should sign the new one unless you re feeling extra paranoid today.
Next.