I mourn the loss of thousands of precious lives, but I will not rejoice in the death of one, not even an enemy. Returning hate for hate multiplies hate, adding deeper darkness to a night already devoid of stars. Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. anonymous (often attributed to Martin Luther King, Jr.)Seen many times today.
I look forward to Ubuntu s semiannual release day, because it s the completion of 6ish months of work by Ubuntu (and by extension Debian) developers.I also loathe it, because every single time we get people saying This Ubuntu release is the worst release ever! .Ubuntu releases are always rocky around release time, because the first time Ubuntu gets widespread testing is on or after release day.We ship software to 12 Million Ubuntu Users with only 150 MOTUs who work directly on the platform. That s a little less than 1 developer with upload rights to the archive for every 60,000 users.1 Compared to Debian, which (at last estimate in 2010) had 1.5 million uniques on security.debian.org, yet has around 1000 Debian Developers.Debian has a strong testing culture; someone once estimated that around of Debian users are running unstable or testing. In Ubuntu, we don t have good metrics on how many people are using the development release that I m aware of (pointers welcome), but I d guess that it s a very very small percentage. A common thread in bug reports, if we get a response at all, goes on as follows:Triager:2 Is this a problem in $devel?
User: I ll let you know when it hits final
Triager: It s too late then. Then we ll want you to test in the next release. We have to fix it BEFORE its final
User: Ok, I ll test at beta.
Triager: That s 2 weeks before release, which will be too late. Please test ASAP if you want us to have time to fix it Of course, there are really important bugs with hardware support which keep on cropping up. But if they re just getting reported on or around release day, there are limits to what can be done about them this cycle.We need to make it easier for people to run early development versions, and encourage more people to use them (as long as they re willing to deal with breakage). I m not sure whether unstable/testing is appropriate for Ubuntu, and I m fairly confident that we don t want to move to a rolling release (currently being discussed in Debian, summary). But we badly need more developers, and equally importantly, more testers to try it out earlier in the release process.To users: please, please try out the development versions. Download a LiveCD and run a smoketest, or check if bugs you reported are in fact fixed in the later versions. And do it early and often.
sources.list to the download page. Thanks!
There seem to be lot of momentum in discussions about making Debian testing more attractive to users on debian-devel mailing list (see Lucas's summary for summary of the lengthy discussion).
One of the raised points there is that Debian misses equivalent of Ubuntu's PPA or openSUSE build service. As Debian is usually about do-ocracy, it will be there once it will be implemented, but I still don't think it is always useful to have such thing.
The problem with both (but this is especially the case for openSUSE build service) is that you need to add dozens of home: projects with questionable quality of the software. This usually leads to horrible mess, especially in case of incompatible libraries with different build options (anybody using wxWidgets?).
It can definitely lower barrier for people to create packages for the distro, but is it really good to lower barrier that much? I'd really prefer new things to be uploaded to Debian itself without need to use any external repositories, it would ensure at least some level of quality and compatibility with other packages.
Filed under: Debian English Suse 5 comments Flattr this!
Finally some picture published on time. Going to slightly larger animals this week. Picture taken at parkour race in Prague.
Taken again using PENTAX K7 + PENTAX-DA 70mm F2.4 Limited.
Filed under: English Photography 1 comments Flattr this!
Here is my attempt at a summary of the rolling discussion currently happening on debian-devel@. It might not be complete, it s probably a bit biased, but I hope that it s still better than nothing. It was also posted on debian-devel@.
If you are involved in Debian development, please discuss it on debian-devel@, rather than in the comments of this blog.
If you want to provide feedback about the Debian rolling idea, use this Doodle poll and/or the comments of this blog.Title: Debian endorses usage of testing by end-users, and renames it to rolling The Debian project recognizes that the Debian testing distribution initially created to make it easier to prepare and test the next stable release has become a useful product of its own. It satisfies the needs of users who are looking for the latest stable versions of software and who can cope (or even appreciate) a system that s constantly evolving. The Debian project decides to endorse this usage and will strive to provide a good experience to users of testing . To better communicate this policy change to our users, testing will be renamed rolling .Yes, it s mostly PR bullshit , and I don t expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What would change is more attention from developers to what happens in testing/rolling, which is a good thing since a better testing/rolling makes it easier to create stable releases from it. Open questions Most of the discussion is about the influence of the introduction of rolling on Debian development processes, and in particular, on the painful process resulting in stable releases. Many fear that, with rolling , it will be harder to get stable releases out. The root question is: if we do rolling, what do we do during freezes? Several options have been mentioned in the thread:
The above sign was prominently displayed at a fair that was recently run by the Banyule Council. We have had some discussions in the Linux community about what policies should be used in regard to photography at events, it seems that this is a precedent for being able to opt-out of public photography.
...when waking up, learning, live, the death of Bin Laden, and then
spend one hour wondering if I should be happy or sad that we end up
being happy of this.
Confused, still confused.
Will I succeed maintaining a weekly log of what I'm doing in Debian?
We'll see. At least, let's try.
D-I work: After spending most of the end of week 16 uploading D-I components, I
completed this during this week. I hunted down the remaining arch:all,
arch:i386 and arch:amd64 packages that need an upload because of l10n
changes. The main point was bringing published D-I work inline with
the work of translators. That was mostly meant to publicly have an
image with Uyghur activated (which I blogged about
separately). Finally, I ended up doing some changes to the
fonts-ukij-uyghur package in order to use the right font to display
the language in D-I, as well as improving the readability by
increasing the font size just as we're already doing for Arabic and
Persian.
Samba packaging: I got release managers approval to upload a new
release to stable-proposed-updates. It fixes several important bugs in
samba 3.5.6, often affecting Win7 clients. I'm always happy to see
that we can do that even when issues are ot security or "release
critical" issues. I also integrated the newly-published samba
3.6.0-pre3 in the package maintenance SVN. However, we're still having
problems with symbols disappearing from libwbclient, that prevent me
to upload 3.6.0pre3 in experimental. Steve Langasek's help here will
be welcome.
Pytrainer and "gant" packaging: I setup a mailing list for the
pkg-running maintenance team so that we can move the few packages some
of us maintain (pytrainer and garmin-forerunner-tools as of now, and
soon "garmin-ant-downloader", the helper tool for 405 watches). I also
began looking at pytrainer bugs and forwarding some of them
upstream. I also began packaging "gant" (had to rename it as we
already have a gant package, totally unrelated). I just got a notice
from Klaus Ethgen about improvements he did to the software. We'll try
to figure out what to do as this software doesn't really have a clear
upstream and published versions.
l10n work: a few packages introduced debconf templates and I
launched reviews of English for them (while mumbling about
uncoordinated work, of course..;-)). I also reviewed about one hundred
package description translations in French DDTP (something I recently
began to commit to do even though it means onlinen work for me, which
I'm not used to). No l10n NMUs this week but a few maintainer uploads
after I (gently) kicked their ass..:-)
I really don't know how I ended up spending this entire evening listening to
Bhutanese music. But I did well.
I particularly enjoyed Rang Sem Kar Ga
Mikar and Gayser
Jang Lu Jonpi Gang, which I both found on YouTube.
The former
reminded be the pleasure and (apparent) simplicity of Bhutanese
dances, which I had the privilege to share with guests in Thimphu a
few years ago.
The latter gives a great idea of the peacefulness of that place of the
world (I recommend scenery views some of which probably taken at
Dochula Pass). And that language is so beautiful even when one doesn't
understand a word.
Maybe some readers of this blog will become listeners of Bhutanese
music for some time after reading this. I just can wish this.
And, doh, I really can't wait until I go back there. I will, one day or another.
"Ku Zu Zang Po La" to those who made me discover that place.
Slightly delayed, but here comes photo for last week. I simply failed to download it from camera and process it. Continuing in animal macro, this time it is frog somewhere in Beskydy mountains.
Taken again using same combo PENTAX K7 + PENTAX-DA 35mm F2.8 Macro Limited.
Filed under: English Photography 0 comments Flattr this!
With KDE 3 almost gone in unstable, the KDE team is not longer interested in Qt 3 and we are looking for new maintainer(s).
If you want to have Qt 3 in wheezy, now is the time to step up! Please, read this email and reply in list.
I will never forget.
Last week, I announced the activation of Uyghur language in Debian
Installer. For once, I even went further: I rebuilt all D-I packages
that include localization (at least for i386/amd64 architectures) and uploaded them.
As a consequence, D-I daily builds now allow previewing how an install
done in Uyghur can be like.
For this, please go to the Debian Installer
development page, download the netboot ISO image
(not netinst) and launch D-I with "suite=unstable" passed as
argument when booting the ISO image.
You should end up with something like this, this or this. There are
a few glitches, still: for instance, as the font we chose has no Bold
variant, the screens "titles" do not use an Uyghur font but an Arabic
or Persian one. As a consequence, glyphs ar enot properly joined
together. I'm investigating this issue with Uyghur translators and
we're trying to choose an appropriate font among the gazillion that have been created by UKIJ.
Please notice that Uyghur looks like Arabic but, according to those
who can read Arabic, is really different from Arabic (or Persian).
I hope that this great work by Gheyret Tohti, Abduqadir Abliz and
other people working on this will give ideas to other so-called
"minorities", here or there in the world, who want to be able to
install Debian in their language.
There is still a lot of work to do, such as having end-user software
localization for Uyghur and, then, a uyghur-desktop task, but this is
at least the first language that gets added for wheezy.
In case you would be wondering, the current
count of activated languages in D-I is 71.
svn-all-fast-export --identity-map authors.txt --rules pkg-ace.rules svn-pkg-aceHere's the content of the pkg-ace.rules configuration file that was used:
create repository pkg-ace end repository match /trunk/ repository pkg-ace branch master end match match /(branches tags)/([^/]+)/ repository pkg-ace branch \2 end matchThe author mapping file authors.txt being:
markos = Konstantinos Margaritis <email-hidden> mbrudka-guest = Marek Brudka <email-hidden> pgquiles-guest = Pau Garcia i Quiles <email-hidden> tgg = Thomas Girard <email-hidden> tgg-guest = Thomas Girard <email-hidden>The tool sample configuration file merged-branches-tags.rules recommends to post-process tags, which are just a branch in SVN. That's why the configuration file above treats branches as tags. The conversion was indeed fast: less than 1 minute.
svn tags as branches:
Branches are marked with green rectangles, and tags with yellow arrows.
What we have here (expected given our configuration of the tool) are
branches (e.g. 5.4.7-5) corresponding to tags, and tags matching the SVN
tagging commit (e.g. backups/5.4.7-5@224). We'll review and fix this.
merged code that did not appear as such:
Branches that were not merged using svn merge look like they were not
merged at all.
commits with wrong author:
Before being in SVN, the repository was stored in CVS. When it was imported
into SVN, no special attention was given to the commit author. Hence I
got credited for changes I did not write.
obsolete branches:
The tool leaves all branches, including removed ones (with tag on their end)
so that you can decide what to do with them.
missing merges:
The branch 5.4.7-12 was never merged into the trunk!
#!/usr/bin/env ruby # # retag.rb # # Small script to create an annotated tag, specifying commiter as well as # date, and tag comment. # # Based on Scott Chacon "Custom Importer" example. # # Arguments: # $1 -- tag name # $2 -- sha-1 revision to tag # $3 -- committer in the form First Last <email> # $4 -- date to use in the form YYYY/MM/DD_HH:MM:SS def help puts "Usage: retag <tag> <sha1sum> <committer> <date> <comment>" puts "Creates a annotated tag with name <tag> for commit <sha1sum>, using " puts "given <committer>, <date> and <comment>" puts "The output should be piped to git fast-import" end def to_date(datetime) (date, time) = datetime.split('_') (year, month, day) = date.split('/') (hour, minute, second) = time.split(':') return Time.local(year, month, day, hour, minute, second).to_i end def generate_tag(tag, sha1hash, committer, date, message) puts "tag # tag " puts "from # sha1hash " puts "tagger # committer # date +0000" print "data # message.size \n# message " end if ARGV.length != 5 help exit 1 else (tag, sha1sum, committer, date, message) = ARGV generate_tag(tag, sha1sum, committer, to_date(date), message) end
me@mymachine$ echo 6a6d48814d0746fa4c9f6869bd8d5c3bc3af8242 11cf74d4aa996ffed7c07157fe0780ec2224c73e 898ad49b61d4d8d5dc4072351037e2c8ade1ab68 >> .git/info/grafts
#!/bin/sh br="HEAD" TARG_NAME="Raphael Bossek" TARG_EMAIL="hidden" export TARG_NAME TARG_EMAIL filt=' if test "$GIT_COMMIT" = 546db1966133737930350a098057c4d563b1acdf -o \ "$GIT_COMMIT" = 23419dde50662852cfbd2edde9468beb29a9ddcc; then if test -n "$TARG_EMAIL"; then GIT_AUTHOR_EMAIL="$TARG_EMAIL" export GIT_AUTHOR_EMAIL else unset GIT_AUTHOR_EMAIL fi if test -n "$TARG_NAME"; then GIT_AUTHOR_NAME="$TARG_NAME" export GIT_AUTHOR_NAME else unset GIT_AUTHOR_NAME fi fi ' git filter-branch $force --tag-name-filter cat --env-filter "$filt" -- $br(Script edited here; there were much more commits written by Raphael.)
Important
It's important to realize that the whole selected branch history is rewritten, so all objects id will change. You should not do this if you already published your repository.
Hint
Once git filter-branch completes you get a new history, as well as a new original ref to ease comparison. It is highly recommended to check the result of the rewrite before removing original. To shrink the repo after this, git clone the rewritten repo with file:// syntax -- git-filter-branch says it all.
Add graft points where needed.
Clean tags and branches. Using git tag -d, git branch -d and the Ruby script above it was possible to recreate tags. During this I was also able to add missing tags, and remove some SVN errors I did -- like committing in a branch created under tags/.
Remove obsolete branches.
Merge missing pieces. There were just two missing debian/changelog entries. I did this before git filter-branch because I did not find a way to use the tool correctly with multiple heads.
Fix commit author where needed. Using the shell script above Raphael is now correctly credited for his work.
| [1] | http://lists.alioth.debian.org/pipermail/pkg-ace-devel/2011-March/002421.html |
| [2] | available in Debian as svn-all-fast-export |
This week, I finally switched to use pytrainer to track my running data.
Up to now, I was still using Garmin proprietary software on
Elizabeth's Windows copmuter for this. Mostly because my GPW watch is
a Forerunner 405, that uses a bloody crappy stupid USB stick with
proprietary communication protocol (ANT+).
So, the use of proprietary crappy software was kinda mandatory. There
is however some code floating around to handle this device in Linux,
named "Gant". This is far from being very polished, but I finally
managed to make it work more or less reliably to get the GPS traces
from my watch to my Debian laptop.
So, during the week , I brought all my old running data back from
"Garmin Training Center" (the Windows software provided by Garmin)
back to my laptop and imported it in pytrainer. And I imported new
data from my daily runs with help of that "gant" software.
So, this is now time to really jump into maintenance of pytrainer and
help my friend No l (that will be easy as pytrainer is kinda well
maintained), then package "gant" for Debian, as part of the work in
the "pkg-running" maintenance team (Ralf Treinen, No le K the and /me).
New challenge for me: learn how to create a git public repo and
maintain a package in it (I already participate to maintenance work
with git for several things, but I never initiated any).
Other plans: some bug triage on pytrainer (if some is needed, I indeed
don't know yet) and eventually deal with things that have to be
reported upstream. Looking at Launchpad might also be a good idea as I
suspect that many are using pytrainer with Ubuntu.
Next.
