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.
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!
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.
$ cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-x86-64.so.2 ) )
$ readelf --dynamic /lib/libc.so.6 grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
$ cat foo.c #include <stdio.h> #include <syslog.h> int main(void) syslog(LOG_DEBUG, "hello, world!"); return 0; $ cat libbroken.so GROUP ( /lib/ld-linux-x86-64.so.2 ) $ gcc -o -Wall -Wl,-rpath=. -L. -lbroken -g -o foo foo.c $ ./foo Inconsistency detected by ld.so: dl-minimal.c: 138: realloc: Assertion ptr == alloc_last_block' failed!
$ LD_DEBUG_OUTPUT=foo.txt LD_DEBUG=bindings ./foo
Inconsistency detected by ld.so: dl-minimal.c: 138: realloc: Assertion ptr == alloc_last_block' failed!
$ cat foo.txt.11360 grep "\ malloc'"
11360: binding file /lib/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol malloc' [GLIBC_2.2.5]
11360: binding file /lib64/ld-linux-x86-64.so.2 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol malloc' [GLIBC_2.2.5]
11360: binding file /lib/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol malloc' [GLIBC_2.2.5]
$ cat tls.c char __thread *foo; char* moo(void) return foo; $ gcc -fPIC -o libtls.so -shared tls.c $ readelf -d ./libtls.so grep NEED 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [ld-linux.so.2] 0x6ffffffe (VERNEED) 0x314 0x6fffffff (VERNEEDNUM) 2
Relocation section '.rela.plt' at offset 0x1e770 contains 8 entries: Offset Info Type Sym. Value Sym. Name + Addend 00000035b000 084600000007 R_X86_64_JUMP_SLO 00000000000a2100 sysconf + 0 00000035b008 02e000000007 R_X86_64_JUMP_SLO 0000000000075e50 calloc + 0 00000035b010 01dd00000007 R_X86_64_JUMP_SLO 0000000000077910 realloc + 0 00000035b018 029300000007 R_X86_64_JUMP_SLO 00000000000661c0 feof + 0 00000035b020 046f00000007 R_X86_64_JUMP_SLO 00000000000768c0 malloc + 0 00000035b028 000400000007 R_X86_64_JUMP_SLO 0000000000000000 __tls_get_addr + 0 00000035b030 01b400000007 R_X86_64_JUMP_SLO 0000000000076dd0 memalign + 0 00000035b038 086000000007 R_X86_64_JUMP_SLO 00000000000767e0 free + 0
000000000001e870 <feof@plt>: 1e870: ff 25 a2 c7 33 00 jmpq *0x33c7a2(%rip) # 35b018 <_IO_file_jumps+0xb18> 1e876: 68 03 00 00 00 pushq $0x3 1e87b: e9 b0 ff ff ff jmpq 1e830 <h_errno+0x1e7dc>
$ objdump --disassemble-all /lib/libc.so.6 grep 1e870 000000000001e870 <feof@plt>: 1e870: ff 25 a2 c7 33 00 jmpq *0x33c7a2(%rip) # 35b018 <_IO_file_jumps+0xb18> f19f7: e8 74 ce f2 ff callq 1e870 <feof@plt> $ addr2line -e /lib/libc.so.6 f19f7 /home/aurel32/eglibc/eglibc-2.11.2/sunrpc/bindrsvprt.c:70
Romain and I just posted our slides from yesterday's
Rcpp workshop and class
(preceding the now-ongoing R/Finance
conference).
You can access the slides via my presentation page,
or directly from here as
Part 1 (Introduction),
Part 2 (Details),
Part 3 (Advanced) and
Part 4 (Applications).
The page also contains a link to the examples as a
tar.gz and
zip file.
Update: One link corrected.
CC libplurk_la-plurk-item-view.lo plurk-item-view.c: In function construct_image_url : plurk-item-view.c 233 warning: format %lld expects type long long int , but argument 3 has type gint64Tut tut tut .. a compiler warning! How could the commiter had let this happen? Lets look at the code
url = g_strdup_printf ("http://avatars.plurk.com/%s-medium%lld.gif", ...);
Ahaha .. they re probably using a 32-bit system, the nice thing to do here is:
url = g_strdup_printf ("http://avatars.plurk.com/%s-medium%" G_GINT64_FORMAT ".gif", ...);
To handle the case that on a 64-bit system you can represent a gint64 as a long rather than needing to go for a long long. I ve seen this quite a bit with debugging output for size_t for which G_GSIZE_FORMAT is definitely your friend.
Today I resigned from the Debian project. The following packages are up for adoption:
I'll remove myself from Planet Debian tomorrow, assuming the keyring revokation isn't swift and merciless.
ObQuote: This space is intentionally blank.
The discussion about Debian rolling started sooner than expected on debian-devel (see the thread here). I initially wanted to iron out the biggest problems through discussions on my blog and try to submit a somewhat polished proposal instead we ended up discussing the same things both on -devel and on my blog.
That said it s not that bad (except for the time I lost to have similar conversations in both places) because the debian-devel discussions included members of the release team and it looks like they are not fundamentally opposed to the idea.
Despite this, the introduction of a frozen suite branched off from testing/rolling is not really consensual (yet?). But the idea of officially supporting testing on a best-effort basis appears to have almost no opposition.
While some will undoubtedly believe that this is a useless exercise, I believe it would help if the project stated this in a somewhat official manner. My answer to the question in the title is thus:
I am thus considering to submit a general resolution to that effect. My current draft is below.
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 . While we believe that this is a good move, we would like to remind our users that Debian is a volunteer project and that our resources are not infinite. Package maintainers are contributing to Debian on a best-effort basis. This means that they might not be able to properly support their package(s) in all distributions. In that case, the project recommends that maintainers apply the following priorities:Note that this general resolution could have amendments with s/rolling/current/ and that would solve the bikeshedding over the name that started several times already. I deliberately separated Preparation of the next stable release and Support in rolling so that priorities are clear even if we decide to not freeze rolling and to introduce a frozen distribution to finalize the next stable release. I also did not go into too much details on the implications that it might have, it s best to leave that up to each contributor/team/etc. I hesitated to add a paragraph stating that we want to try to gradually improve the usability of testing but in the end I think it would be somewhat redundant. We re always trying to do our best when we decide to take on something. All comments welcome (even if you just agree and would be willing to second such a GR). Update: I will tweak the draft included in this article when I get good suggestions. Thanks to Lucas Nussbaum for the first one.
- Support in stable (security updates, release critical bugs)
- Preparation of the next stable release
- Support in rolling
10 comments Liked this article? Click here. My blog is Flattr-enabled.
A few months ago dropbox was a Debian packge in non-free. Recently I noticed that there are several new versions available and tried to notifiy the maintainer and ask him to update the package. But unfortunately it looks like the package is not available any more (Here s why).
However getting Dropbox is quite easy if you know what to do.
The obvious choice would be to go to dropbox.com and download either the source package and compile it yourself or try to install the precompiled Ubuntu packages. The first option is not really an option for most users and the second one does currently not work on Debian/Sid (aka unstable).
However, there is an easy solution: on the download page search for the CLI script (currently it is named dropbox.py) Download that and run it with python dropbox.py start -i. That will download the propritary binaries into ~/.dropbox-dist. Now go into that folder and start dropboxd. There you go, you have a fully working systray app for dropbox.
Depending on your desktop environment you might want to put dropboxd in your autostart . So you don t have to start the daemon every time you login. And that s it.
It is not really ideal, since a Debian package would be much better for updates, security, yada yada, but it s still better than nothing.
Next.