People often want to know what an application looks like before they install it. This is one of the reason why Christoph Haas started with the screenshots.debian.net service. People can upload screenshots for their favorite applications for others to take a look at.
Finally, as convenience feature, they are now added on packages.debian.org. When you click on the screenshot of a package you can see the list of all of the available ones.
In the case when no screenshot is available yet the page will show a placeholder image which gives you a convenience link to the screenshots page of the package where you can submit one for the benefit of all. Please make sure that you are following the guidelines for submissions, otherwise your upload might get rejected.
On a not totally unrelated topic, the packages.ubuntu.com site finally will also show you packages in maverick. It doesn't show screenshots yet—if you think adding support for screenshots in there would be a good thing too, please let me know!
A while ago I was with my SO at a concert of a band I might cover at a later point. This time I want to cover the support act of that concert: Jerboa. It was a bit weird to see a single person on stage turning some knobs, but he quickly caught both our attention and heart. And he was a charm to talk with afterwards when we bought his CD. He's definitely worth your attention, and if you are able to see him live take the chance for it.
Number 1: The obvious number 1 song in the list. Perfect groovy song, great video too.
Just Another Number: It starts off pretty smooth but then really kicks in. Hard to not headnick along to the song, it is far away from being Just Another Number.
Actually I would have loved to include What if in the songs but unfortunately that one wasn't available so I had to look for a replacement for it.
Happy 17th Birthday, Debian! You kept me busy for the last 10 years and I am really looking forward to what the next 10 years might bring for our relationship.
Thanks also to all the people who also are able to keep calm and to the point when discussions turn to get heated. You are the ones who make work on Debian enjoyable.
Also a lot of thanks to all the people that understand the power of positive encouragement like what is currently flowing in through the thank.debian.net website.
Likewise much thanks to the ever growing number of distributions that are based on Debian, because doing that is a very special kind of appreciation of our work.
This blog post is actually a response to a talk that was given at the debconf last week. It was marga's talk about Making Debian Rule, again. Now that the beta versions of the talks are available for download I'm able to proper quote what I want to respond to: Is there a reason why we haven't yet updated the website?, perhaps someone can answer.
I feel the need to respond to this as I am the main person driving that effort. Unfortunately the question was asked in a talk with no-one involved in that work around instead of addressing those people directly, and the question wasn't brought to my attention before the talk so that I could have provided an answer to offer in the presentation already. Also, as disclaimer, this is my personal story for it and doesn't need to get shared by the other people involved. I hope it can be seen as an answer anyway.
As a little of background, Kalle's proposal went a long path before even I found out about it. I was simply in awe in several ways about it because it wasn't just a great mockup of the page (which it actually is, IMHO) but was accompanied by thoughts about not only the main site but also about several sub sites. Also, it was accompanied by patches, so it was seemingly ready to get deployed right ahead.
I started working on it, got accused of being discouraging while doing that, got told that it would require a proper vote for a decision and can't happen just as, but those are just the Debian way of communication. I nevertheless did set up several test sites for some over the time to play with it. Some did work out better (like the git one, though this one came last and Kalle improved the CSS over time a fair bit), some weren't ready yet (like wiki, missing e.g. the coloring for the version diff, or the packages one where the separation between the different sections isn't that visible yet). Time passed, other things demanded their attention too.
Like the thing where our system administrators did send me a request along about a new www-master server that needs to get set up from scratch. Given that the documentation about the required packages for the website was lacking a fair bit (to say the least) it did require a lot of attention, especially when doing things from scratch the wish to document the dependencies properly is just natural. There are still some issues with that as can e.g. be seen on this page in the empty table at the bottom. The same issue also appears on my testsite for the new design.
The last part though is currently the biggest blocking issue for both efforts. There is no way to move forward with either without having that addressed. Simon Paillard did a great job on helping the move along so far, keeping the thread about the server move requirements that I started on the debian-www mailinglist updated with information about what's still pending. Unfortunately Kalle, Simon and me are also facing some private time constraints (amongst other duties that require attention) which weren't helping to move forward at a bigger pace. Unfortunately not very many people actually has shown interest in helping out neither, after all it's easier to go and ask questions about why it's not done yet to the completely wrong audience.
My plan is to switch many sites at the same time instead of one after the other simply for the effect but also for less distraction for our users, including less people repeatedly pestering about when this or that site gets done, too. At least we need a final discussion on what should go into the header links and what should be at the bottom before a switch can be made anyway. And for some there is still the opinion that such a switch is nothing that we are rightfully allowed to decide without a vote, so that's also part of the reason to not just deploy it.
I hope this answers the question to some extend—and like said, if only I would had been addressed about this before the talk was given an answer to it would had been ready for presentation right ahead instead of having a pretty terse statement getting relayed through IRC (thanks, Yoe!) because I was fortunate enough to be around and watching the talk at that time. Feel free to discuss it further or offer your help on debian-www, especially if you are familiar with working on CSS files.
You might remember that I started to work on closing RC bugs for stable. This effort hasn't died off so I joined the RC Bug Squashing Contest that was going on during the Debian conference (which I was unable to attend). The rules did permit it, even though I was aware that it can't (and shouldn't) be compared to the unstable/testing squashers and thus it was split of into its own Special category.
There still seems to be a lot of confusion on how our BTS works, especially with respect to version tracking. I was even accused of falsely claiming bug closing because the bug has been closed by someone else already. This wasn't the case, otherwise the bugs would had been archived a long time ago already[1]—given that I had expected that person to know how bug archival works and also given the sheer amount of bugs that I simply had closed for stable, I guess it is needed to shine a light upon why some bugs won't get archived as expected.
If you followed my IRC talk on BTS usage last month you might already have an idea of what's going on. There might be several different reasons why bugs aren't marked for archival yet. I'll try to explain them as I understand it (given that I neither have taken a look at the debbugs code nor am involved with its development) through my working on bugs over the last 10 years.
Usually bugs are marked for archival when they are not affecting testing or unstable. That means, for a bug filed against a version that is only in unstable and closed in unstable, an immediate archival process is started (actually, it's not that immediate: It requires the package to be in sync on all architectures it's available for, too); otherwise the fix has to enter testing before bugs are considered for archival.
Sometimes the bug is still considered affecting unstable though, even when the fixing package version already moved over to testing. This is the case when the hurd-i386 package is outdated in unstable and can be checked in the unstable overview of the package on packages.debian.org at the end of the page, it will have red entries next to the green ones (you can ignore red entries for debports architectures, though!). You have to file an arch specific removal request for those bugs to get them archived.
For packages in experimental it's quite the similar situation, because that packages from experimental don't transition anywhere, so those will stay unarchived for the time being if they also affect unstable.
So what can be the reason when the fix is already available in testing and unstable but the bug still doesn't get archived? Those cases mean that the bug is considered as affecting stable and has to get addressed there, too. Bugs that are considered for that are of a release-critical severity, bugs with lower severity aren't considered for stable because they are unlikely to get fixed in stable and thus get archived. So what can we do about them?
Do they actually really affect stable? Working on those is what I did over the last months. There are often enough bugs filed for library transition issues, FTBFS for toolchain changes, or other things that aren't applicable for stable. Those are easy to close in stable:
If the version information got lost (through reassigning or similar), the only thing needed is to re-add the found versions, given that it is a higher one than the one in stable.
If the version information is proper (because it had still the same version in unstable at the time of the reporting) tagging them with + squeeze sid will tell the BTS to consider them only for those releases, so not thinking it affects lenny, too.
Some do affect stable but still aren't severe enough to warrant an update in stable (like for documentation corrections in debian/copyright or similar). If you found one of those please talk to the release-team about getting them tagged lenny-ignore, don't do that yourself because that tag is meant to be set by the release-team themself only!
If they actually affect stable (like security issues that though are considered to be too minor by the security team to warrant a DSA, or other severe usability issues), please try to backport the relevant fix, propose a diff to the release-team on their mailinglist and have it uploaded to lenny-proposed-updates to be fixed in the next point release.
I hope this will get others also interested to fix stuff for stable. Actually when I see something that potential falls into the last group I ping the maintainers of those packages to let them know about having them fixed. Some of you might already have received such a ping and I am thankful for those that received them well and actually already fixed some of those, too. Thanks for making stable a better place!
Coming back to the RCBC, it was an interesting small competition (if only in my brain) between myself and the testing/unstable RC squashers going on. It would had been nice to get at least as many bugs in stable addressed as in testing/unstable because the amount is still a lot higher, but I can still be happy about the things done. And it is good to know that not everything seems to think that it's wasted effort to work on getting the RC count lower for stable, too (like I also was told about my effort). So thanks from that point of view!
[1] There are currently 2688 bugs still unarchived that were closed last year already! This UDD query helps you: select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';
Debian always was known for its communication "style". There were even shirts sold in memory of Espy Klecker with a quote he is known for: Morons. I'm surrounded by morons. Yes, I bought me one of those shirts too in the early days. And there were the talks that promoted Debian as a place to have Goodflamewar training. And people considered that to be the fun part.
After some years it got tiring. It got stressful. It got annoying. Bad feelings popped up, stirred you into the next flamewar, and it went down the gutter from there. It was almost becoming impossible to not be the target of a flamewar when one was doing more than just basic maintenance. Snide and extreme terse responses became the standard.
In the end people are starting to give up and leave. The Ugly thing about this is that human resources are crucial. They aren't endless and can't be replaced as easily as broken hardware, especially when capable people or when people leave who invested an enormous amount of their spare time and effort. And given that a fair amount of people do put their heart into Debian, it feels like a small suicide to them and the public thinking about leaving is meant as a call for help which wasn't and isn't given.
The solution to this death swirl? I'm not sure. When one looks over the edge of the plate and ignores for a moment all the bad feelings they one might have built up against Ubuntu because of their success and possibility to find new contributors on a regular basis one is able to find a much friendlier and productive environment there. This might be attributed to the Code of Conduct about which I wrote about last year already and which is an extremely well intended and useful document (the point I raised in there is already solved for a while, so I became a MOTU). And even if it might be hard to follow it at times, Mark Shuttleworth reminds and encourages its contributors to stick to these principles even in tough times.
The result? When following the planets, one finds on Planet Ubuntu a very good rate of blog posts on things that had been done, compared to the good rate of blog posts of rants on Planet Debian. And even though people regularly complain about the communication style within Debian, the answers of this year's DPL candidates to the question about a code of conduct for Debian were rather rather disappointing. So it is just well too understandable that people go the path that hurts themself, take a cut and leave the project behind in its mess.
For myself? I'm not too far from that point on a regular basis, and I can understand those who did the final step only too well. Regular abuse, especially when doing stuff that others neglect on a regular basis but needs to be done anyway, being belittled on that grounds and not being taken serious and getting disrespectful responses isn't improving the situation. It happens to way too many people, and the only thing that still keeps me on tracks is that I do not want to give in yet, that I don't think that it would improve Debian to leave the grounds to various destructive people.
Alright, get ready for the next round of music links. This time I stumbled upon an old (and still) favorite band of mine while looking for references to Max Headroom: Art of Noise. You most probably have heard the one or the other song from them, they are featured pretty often. Here they are:
Peter Gunn: Also very well known and used often. You have to wait a bit for the music to hook in, there is an intro in the video.
Paranoimia: Third great song you might have heard somewhere already. Absolutely lovely song indeed.
It's really sad to see such great bands to pass away. But it's still the perfect music to have running in the background when hacking along. Highly motivating, great to hum along. Oh, and you might ask, where is the connection to Max Headroom. Here it is, in a special version of Paranoimia featuring Max Headroom!
I got convinced to hold an IRC talk on usage of the Debian BTS in #ubuntu-classroom and thought it might be interested to other children distributions of Debian, too—also for regular Debian users. So feel invited to attend it.
It will be held in #ubuntu-classroom on irc.freenode.net on Thursday, 22nd of July, at 18:00 UTC. For those who have never attended such a session yet, you might want/need to also join #ubuntu-classroom-chat too and raise questions in there, the main channel will be set to moderated.
I will try to cover basic usage like querying the web interface, reporting new bugs and also more deeper handling of bugs, including version tracking issues, and will try to address raised questions as good as possible.
Hope the session will be helpful to some and be able to address some questions like why some bugs aren't getting archived even though they are closed for ages. :) IRC logs will be available for the convenience of those who can't make it.
Working on and for Debian for the whole millennium already it would had been hard to not notice Ubuntu through the times. Given that fixing bugs in the package is in the interest of all involved parties I started to get curious for the packages I maintain in Debian what users of Ubuntu might have filed against them. Given that a fair amount of those actually do also apply to Debian I started to fix them too.
Though, some bug status isn't able to use as an outsider, and given my approach to perfection not wanting to have packages in a bad shape in a release I started to dig a bit further into the procedures and applied to be accepted as a Ubuntu Developer, more specifically as a MOTU, which gives me the possibility to directly ask for syncrequest instead of having to go through a sponsor, or set wontfix status for bugreports in my packages that simply doesn't make sense to get implemented.
Last week I got accepted into that state and I'd like to thank for all the nice and encouraging feedback along the path (including some "What? I thought you were MOTU since ages already??" responses). Let's see how much I really need it, my approach is rather to reduce Ubuntu diffs instead of having to work on them. I though understand that at times close to the releases there can be a need for them, as can be seen in that the package I have to put most effort into (wesnoth-1.8) has a Ubuntu diff in the last lucid release. And because Ubuntu already is in DebianImportFreeze I did a syncrequest for gitolite.
Thanks for accepting me so quickly and rather bureaucratic! And no, Laney, I won't give the talk tomorrow because of this just on my own. ;)
This Monday I was again at concert of Grossstadtgeflüster, and it was again one of the best concerts I've visited. Their new album again has again great songs on it like the former two, and their live performance is truly worth it. Besides they are charming like hell offstage, too. Jen, Raphi and Chriz, I simply love you!
It's hard to choose which songs to put here because there are way too many great ones, so feel free to dig around yourself if you like them:
Weil das morgen noch so ist: Their current single, great video, giving a good impression of their style and the fun they have doing this.
"Today is the greatest day I've ever known,"—this is the line that is spinning around today in my head because of many little things that happened. And it's this time of the month anyway for putting up another band feature into this little blog of mine. So here they are, one of the great bands of the nineties, and like many of them, back after a break again: The Smashing Pumpkins, and these are their featured songs:
Today: The song with the initial mentioned catchphrase. Unfortunately not the official video because in those versions the music is strangely broken. If you want to match it yourself, you can still watch it here: Today (true video, broken music)
Disarm: From the same great album, and one of their songs that gives me goosebumps.
Hope you enjoy this small distraction once a month. I hope I can keep up with it, it's not a question of material, there are too many great bands out there that I'd like to share with others. :)
We ain't dead. A long time has passed since I last wrote on this topic, and much happened—unfortunately (for this effort) in other areas.
This doesn't mean that this effort is being abandoned. So here is the next big step: A gitweb theme using Kalle's proposal. I enabled it on my own gitweb installation so that people can see it live and test it. Feel free to clone it from there, too.
Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package.
The longer answer which also answers Why the name change? goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch.
So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages.
Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!
My SO did had an extremely good idea for my birthday this year: We went to a concert of Ich + Ich. We both were a bit sceptical beforehand—but actually we were both in agreement about that it was one of the finest concerts we have been to. I want thus to share some of the great songs of the band with you:
Universum (Universe): I am thinking of my son when listening to this sweet song.
Stark (Strong): Not only the title but the lyrics.
Dienen (Serve): Probably the best known of their songs.
On 20th of March, at five to midnight, we have released out most straining and time consuming project ever. Its codename is Simon André and we are pleased that it was (more or less) a smooth release process with just a minor delay of three days—but the best don't release on time but when it is ready.
Because everyone loves screenshots, and a few might be viewed on our dedicated Screenshot Page, for completeness this announce contains one:
After one week into the release we have to say the feedback and the interest so far is pretty good, the maintenance is requesting its toll, but nothing really unexpected happened so far. We look into a bright future!
Thank you for your attention, enjoy the nice spring weather!
You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.
You are missing the point - the planned switch of the default format isn't considered a good approach by quite some people. If something new gets introduced, switching to it should be done in wake manner. Other tools do that too, so why can't a central package as dpkg use that approach? I especially want to mention that a point release update for stable was required to get it working in stable like it should.
A while ago Ganneff wondered weather it would be possible to make the matcher extension of rxvt-unicode also pick up something like #12345 and turn it into a link into the BTS.
It isn't—or rather, it wasn't. The idea got stuck in my head and invested some time to make it happen. Here is the quick'n'dirty diff to make it happen:
--- /usr/lib/urxvt/perl/matcher.distrib 2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda 2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
# Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
my $url =
- qr{
+ qr{(?:
(?:https?://|ftp://|news://|mailto:|file://|\bwww\.)
[a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
(
\([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)| # Allow a pair of matched parentheses
[a-zA-Z0-9\-\@;\/?:&=%\$_+*~] # exclude some trailing characters (heuristic)
)+
+ )|\#[0-9]{4,}
}x;
sub on_user_command {
@@ -145,6 +146,7 @@
my @begin = @-;
my @end = @+;
if (!defined($col) || ($-[0] <= $col && $+[0] >= $col)) {
+ $match =~ s/^#/http:\/\/bugs.debian.org\//;
if ($launcher !~ /\$/) {
return ($launcher,$match);
} else {
The diff is intentionally small so it is clear what is happening here. And it should give ideas for other extensions that one would like to make. I don't consider it though flexible enough to submit it upstream. Enjoy anyway!
A while ago I blogged about squashing release-critical bugs in stable. Yesterday we have reached a big milestone on that area: The amount of release-critical bugs in stable dropped below 1000 (blue graph). This might sound like it's still pretty high but given that we were well over 1600 RC bugs in stable a while ago I consider this quite a success.
This is though no time for rest. There is still way too many RC bugs in stable, there are definitely still a lot of bugs that just aren't affecting stable and thus can be marked as such meaning no upload needs to get done for them. I'm taking a close look at those with higher numbers and most of those seem to be validly affecting stable too so they might require a bit more work than just tagging them.
Thanks to all people who helped on that area, I can just remember a few names and don't want to make anyone else also working on stable to feel singled out, though I want to thank Lucas for tagging his FTBFS rounds with squeeze sid right from the start because the packages obviously have built before due to his regular rebuilds. Thanks to all, but like said, not the time to rest. The green squeeze graph is still around 250 bugs away from us!
The t-prot package might need your help: There is a discussion going on with the upstream developer how to proceed with respect to a hopefully helpful change in its behavior. There are several options how to address this, one of them would involve using the Getopt::Long module instead of Getopt::Mixed. Given that the benchmarks of upstream rather speak for sticking with Getopt::Mixed we would like to ask you for help:
Please test this version of t-prot (for your safety: detached gpg signature for the version) and compare it to the packaged version 2.15 that I just upload into unstable (it is installable without anything else also into (old)stable or testing). Your feedback on this is truly appreciated, please send it until the start of next week (Monday evening/Tuesday morning) to "t-prot (AT) tolot.escape.de".
This poem is only in German language, but I hope you can forgive me to run it in my English language feed nevertheless. I send you the best season greetings, have a nice time, use it well, relax and think about it. :)
Weihnachtsgedicht 2009
Vor ungefähr zweitausend Jahren
glaubt man, wurde ein Mann geboren
glaubt man, dass es Gottes Sohn gewesen ist
glaubt man, der uns alle erlösen sollte
Irgendwann später
dachte man, das wäre ein Grund, daran zu denken
dachte man, es wäre ein Grund, in sich zu kehren
dachte man, es wäre eine besinnliche Zeit
Heute jedoch
stresst man, um nur ja Geschenke für alle zu finden
stresst man, weil jeder überall mit einem feiern will
stresst man, um sich besonders gütig zu zeigen
Ich wünsche mir, dass
wir helfen, uns zurück zu erinnern
wir helfen, uns zurück zu besinnen
wir helfen, wieder ruhiger zu werden
Ich wünsche euch ein erlöstes, besinnliches, gütiges und ruhiges Weihnachtsfest!
Others are doing it, so I thought I'd join in, too. Though, from a different perspective. Often enough people claim that package maintainers don't seem to care about their packages anymore once they did hit stable because they say it isn't as easy to update packages in stable. While this is partly true it still doesn't send a too good impression to have a high and increasing release-critical bug count for stable.
UDD makes it easy. It has a field affects_stable in its bugs table, and the view bugs_rt_affects_stable is even yet better. I fiddled together two short statements that help me to find release-critical bugs for stable:
SELECT b.id FROM bugs_rt_affects_stable bas
LEFT JOIN bugs b ON bas.id=b.id
WHERE b.severity IN ('serious', 'critical', 'grave')
AND b.id NOT IN (select bau.id from bugs_rt_affects_unstable bau)
ORDER BY b.id;
The second statement is without the AND clause to see all open release-critical bugs. Going through this list isn't too complicated, and I already found a good rush of bugs to mark as not affecting stable because the reason for the bug only appeared after the lenny release. I could list their bugnumbers, but it's currently up to 39 such bugs since yesterday and I don't want to bore you with it, actually it didn't involve any touching of the package—but it will definitely make it easier to find the real release-critical bugs that do affect stable and should get addressed in an update to it.
Still lots to do, 39 bugs down isn't the world when the barrier is set to about 1500. Though, it's still more than 2% and this is something that makes me a bit happy.
when people upload to Debian with an @ubuntu.com email address
even better, if they do that when they are DDs (so with a @debian.org address)
Yeah! Actually, doing so shows several things: That the collaboration between Debian and Ubuntu actually works out. That people that feel more attached to Ubuntu also do care for Debian. And that those people started to realize that contributing things back to Debian actually does reduce their own workload with respect to not having to maintain seperate patches, with the benefit of all involved parties.
So big kudos to you people being able to look over the corner of your little universe and see the bigger picture for the benefit of all!
It is great to see that the collaboration between Debian and Ubuntu is improving; and I don't say that just because it probably can't be much better within the Debian/Ubuntu Games Team, we have people from both distributions working inside the team and most of the packages don't carry Ubuntu specific patches (anymore) because of that.
Actually, seeing that things do go pretty well in that area made me consider signing up to become a MOTU. To do that one has to sign the Ubuntu Code of Conduct (CoC) which is a fairly good document, actually. I wish there would be something similar within Debian that is considered binding, it would be able to reduce quite some tough and rough times, actually. It is about and explains to be considerate, be respectful, be collaborative, what to do when you disagree, when you are unsure and wants you to step down considerately. If these principles would be carried out amongst all the free software communities (and I really mean carried out and not just be there and grow old) I expect it would be much more welcoming for new people. And it's not too hard to do your part for it (... says the person who just recently had to excuse for her behavior).
Anyway, there is this one part with the CoC that itches me. It's not that one has to sign it with their GnuPG key, but related to it. Making it a requirement to sign it gives the document a much more official character, actually gives it the feeling and impression of a contract and I expect it is meant to carry that feeling. Though, there is this one part in it that I consider off for such a document:
Nobody knows everything, and nobody is expected to be perfect in the Ubuntu community (except of course the SABDFL).
Given that the acronym SABDFL refers to Mark Shuttleworth it means that one has to expect him to be impeccable—which I am sorry but cannot sign. I don't expect that from anyone else but myself, even Mark is only human and can make mistakes. Even though it's obvious that this is a tongue-in-cheek kind of joke which might be meant to make it clear that the Ubuntu community isn't just sterile having this in a document that is expected to get signed by contributors is just an extremely bad idea.
Sorry, Ubuntu, as long as this joke is part of the CoC I can't sign it with clean conscience, no matter how much I would sign the rest of it a thousands' time. It really makes me wonder how many others actually did read the "contract" carefully that they are signing but on the other hand simply didn't care. There is too many site signup stuff out there that noone reads neither.
In my last blog entry I used the term "image-hack". It seems like it has been considered to have a negative feeling attached to it. Even though I consider this very amusing in a community that likes to pride itself with the term "hackers" I guess I can understand why people consider it a negative term. Even though technically a mockup of a website in image form actually feels just a crude hack it wasn't meant to belittle what pixelgirl has produced. Her image-hack looks extremely well.
Unfortunately no further contact after the debconf was established and personally I'm not convinced how the tiny image would work for other pages besides the start page—and removing the DSAs and News from the start page is a no-go, we actually do receive positive feedback for that. So it is what it is, an image-hack. An extremely well done one, but still just that.
Like written in a former blog entry I am working on preparing for getting Kalle's Debian Redesign tested and installed. Even though some unfortunate events happened which made me reconsider my efforts and a lot of things changed for me I am still up with the effort. Mostly because I didn't became part of the webmasters just to chicken away in the face of obstacles, and also not just because yet another image-hack did pop up that neither showed anything usable or overall-thoughts or actual code/concepts or even tried to get in contact with the webteam.
I only remember to have received positive feedback in which I also include minor change suggestions like that the exact hits and other hits sections in the packages site aren't as clearly distinguishable as before. I have of course forwarded these to Kalle and we are looking for a solution that would go with the style. Speaking of the packages site I finally managed to get the packages from the main pool displayed too so it shouldn't behave differently to the old one anymore in that respect (see e.g. wesnoth for some more distributed package).
The next step I finished these last days was setting up a testsite for www as you can find it on www.deb.at. Please notice that you might want to surf that site in English (either change your Accept-Language settings or click on the English links at the bottom of the pages) because some of the changes are only recognizable there; like, the main page in other languages look immensely different.
Where to go from here? Kalle also has proposal for the BugTracking System and the Planet so that targets are the obvious next steps. I can't tell yet when they will be done, depends on how complicated it is to set up an environment for it, but I will keep you updated.
Since I returned from this year's debconf quite a lot things have changed in my life. One thing I knew way before debconf already, I switched jobs. I was working for a pretty long time (and also through great times) for Silver Server, for well over 6 years. Let's see what I can do in and for my new job. I'm still only pretty short there yet and I being to understand what's going on (and what could need improvements in some workflows) but it's too early to see that more precisely.
On a small side-note, the job change also required me to switch my mobile phone number because the old one was a company's number. I now have a private one that I don't fear of losing anymore. If you subtract the number 3933309527644 from my old one you have my new one. On the other hand you can always ask me for it in case you had my old one and wonder. ;)
Besides my mobile phone number other smaller things have changed over time too. Most of you noticed that I'm neither using my @ist.org nor my @debian.org address anymore because they did carry the wrong nick. And given that everyone was switching their gnupg keys I did so too. Like before I again created separate keys for private usage and for Debian usage. I'm not really following the procedure of sending out signing requests to people who have signed my old key(s), personally I don't follow them myself so I don't expect others to do. They are though cross-signed with the old ones just to be on the save side to keep the WoT not losing connections.
Also I finally got around to set up my own ejabberd server and did create my a new jabber ID that I also plan to keep. It is the same as my private mailaddress as you can see linked above in the key for private usage. ;) One of the reasons for the server is by the way also a testbed for the packaging of ejabberd which will get moved into team maintenance with the next upload which will be the next upstream version, 2.1.
But the biggest and most important change in my life is that I will have to rethink my spare time spending quite a lot because there will be something demanding a lot of time starting in about march next year. An extremely fortunate change and almost as happy one even though it means that I won't be able to attend next year's debconf in NY, but I hope the people whom I told that I will be there aren't too disappointed by this announcement. Sorry! :)
I'm extremely uneasy. Not because of some release team announcement that if one would have tried to think along after the interview with Mark Shuttleworth got around was already clear back then. It was talking about that the Debian release will propalby get adjusted to match Ubuntu's LTS releases. It isn't a big secret that the next Ubuntu LTS release will be 10.04. And counting backward from that the freeze in december is just the obvious consequence.
What I actually am uneasy about is Agnieszka's Redesign talk. Just to make things clear I want to congratulate her on what she produced. It definitely looks nice and the reactions during the talk were quite clear on that.
But, there are several issues surrounding this that makes me actually thinking about resigning from the webteam as a whole and reduce my precious time that I invest into Debian. The reason might not be as obvious, but it contains some interesting corner data:
Agnieszka did thank Sledge for his good help. So at least part of the DPL team was aware of it. Some weeks ago Luk, the other part of the DPL team, contacted me and said that he is acting with his DPL team hat on and that there were mails coming in to them about how to create some progress for the website. I told Luk that I am already working on getting Kalle's proposal integrated. It was cool to him and he thanked me and wished me well with the progress, but neither he nor Sledge did tell me anything about Agnieszka's work.
Agnieszka also did thank stockholm about his help. stockholm is part of the "marketing" team (yeah, there was one appointed two years ago; didn't you notice all their great work by now??). Anyway, eventually stockholm have heard about me efforts and did stumble by in #debian-www on IRC. He asked about the new design and who's working on it, I showed him what was there at that time already and all he said was "Cool". Again no mentioning of Agnieszka's work neither.
Like I wrote yesterday almost all of the mockups sent in contained only of images (if there even were multiple) which are hard to really decide upon—especially when they are as tiny and not clearly visible like in this presentation. Questions that were raised in the direction of wether this would actually work out were muted with the magic CSS waving; unfortunately CSS can't do magic. And with the images it's hard to decide wether it actually would work for accessibility reasons and the other things I already mentioned yesterday.
We try very carefully to not have duplication of work in the area of packaging through the terms of ITPs. Great! We try to avoid some few hours invested in an area where we have very well over thousands of contributors. But it seems to be proper to just through away days, weeks, months of invested time, effort and energy in an area that we seriously lack contributors.
Way to go, Debian. Seriously disappointed, seriously annoyed, seriously demotivated.
Not sure if you do follow the debian-www mailinglist, but from time to time there are people mailing about that they would like to give our website a new face. Most of the time people just do some mockup in some painting tool without realizing that there is a lot more behind it, with respect to translation and sublayers and accessibility requirements. After mentioning these kind of things, most people go away.
Then there was Kalle Söderman. He took a deeper look behind it, started working for himself in 2007, did notice that there is not only www.d.o but also packages.d.o (or rather wesnoth as example), wiki.d.o, planet.d.o, bugs.d.o and others too. So he started to think about something that might work cross-service, and actually did work with the code and not a painting tool. And even though he didn't hear much from people when he presented it first he kept thinking about it.
This did manage to catch my interest and I started to think about how to move forward from here. I started to contact him and started to mail back and forth about his proposal, started to set up some small testing sites (again: testing sites. They aren't meant to be finished, likewise the proposal from Kalle isn't finished yet), and this is where we are currently: On packages.deb.at/wesnoth you can see a clone of our pkg.d.o that uses his template, feel free to exchange wesnoth with your favourite package—even though be notified that it doesn't get its data regularly updated, I don't want people to use it instead of the main site and that it somehow currently doesn't show packages from the main archive but only the external sources that are used. It's just there to get you the idea.
And we also have a working testing theme for the wiki which works directly in there (thanks to Paul Wise for installing the part that needs to sit on the server side): Follow the instructions on Kalle's page about the wiki if you like to have it enabled.
I am currently trying to get something for testing set up for bugs.d.o and www.d.o; for the later I have to send kudos to Martin Zobel-Helas for giving me a prod and a system to do it on (even though he didn't originally knew that I would want to abuse it for the theme testing ;)). For the time being you can find some more of Kalle's thoughts on his Site about his proposals together with some few pages as examples, but I will keep you lot updated about major progress on this in here.
The work that I invest here is mostly about finding out how much work it actually would be to get things changed, and also because I like what Kalle did. He invested a lot of time and I guess the outcome deserves to have some further exposure. Unlike than in other areas things aren't carved in stone yet, which even Kalle is full aware of, but things have to get started somewhere. Enjoy, send (constructive) feedback (like The distinction on the new pkg.d.o proposal between Exact hits and Other hits isn't clear enough!) and acknowledge that others are doing stuff that many people in the last years did chicken out from.
On monday there were extremely heavy rainfall. This made it even more surprising that I was able to see the moon so clear and beautiful while driving home by night. It did motivate me to write the following Haikus which I want to share with you:
full moon shining down
it is calming and peaceful
even when cloudy
in all its silence
not much that matters and counts
giving you comfort
just watch its bright light
it does not care for others
think about yourself
I think I can consider this issue the strangest problem that I ever had encountered. I am unable to enter @ or € (or any key that requires the alt-gr switch on German keyboard) in iceweasel, evolution, pidgin, gucharmap but am having no troubles in all other applications I tried (kword, OpenOffice.org, abiword, gvim, urxvt) in an current squeeze system.
If anyone has any idea or hint what might be the cause of this I would be more than grateful!
It's quite interesting. Twitter has this snippet in its registration page: By clicking on 'Create my account' above, you confirm that you are over 13 years of age and accept the Terms of Service. At least currently when you click it leads you to a page that says: Something is technically wrong. I'm very happy to accept that, but I have this strange feeling that it's not what they intended to have there...
It's always enlightning how some people see how Debian works. Or not. It seems to get more and more common that instead of filing a bugreport people seem to consider it appropriate to rather rant in their blogs about it. That will definitely get things fixed and done and motivates everyone involved to work on the issues that they get notified about only through third-party. And of course it's absolutely alright to change an application directly, not use dpkg-divert or similar, and then complain wildly about how unfair an upgrade of the package replaced that file.
And, Andrew, there wasn't a DSA about CVE-2008-2236 because it was considered a too minor issue for that. Thanks for the fish. Did you btw. try the version from the upcoming lenny release? It's not like it's not directly installable in etch because of dependencies...
Only once I would hope that people that are that deeply involved in Debian (like, being Debian Developers or long-time contributors) would do things like random users do: File the things they are annoyed with, even if they are as minor and awkward as some of the bugreports I receive for wesnoth.
I dedicate this oldie but goldie to all the people in Debian that enjoy discussing everything to a dead end and then claim to have won because noone responds anymore because there is no sense to do so: Du vastehst mi ned ("you don't understand me")
Since last weekend backports.org has two more services supporting tracking of what's going on. I will list them in chronological order:
Tracking of Security issues in backports packages: This was one of the many topics that was discussed at the Security Team meeting in Essen at the end of last month and Florian Weimer implemented a first version of tracking security issues within backports.org. It currently compares the backported version against the one fixed for unstable, so at the moment it still has some false-positives (e.g. libspf2 because the fix was taken from lenny-security), but this is still a big step forward and helpful to track outstanding issues here, too.
Diffs between etch-backports and lenny: Something similar was available at some other places before but strangely got discontinued. In here you can see which packages in backports are older (meaning only debian revision difference), outdated (newer upstream version in lenny) newer (backported from unstable?), have a wrong version schema or are not available in lenny (propably even removed from unstable). It will hopefully help people to get their backports in sync. At least it's an indicator of how well the packages are tracked.
Hope you consider them already as useful as myself, even though there is obvious space for improvements. But they are both quite helpful already in their current state so that shouldn't hinder you from using them. :)
For a long time publishing source code under a freedom givinglicense was considered bad. What if people would take your code and reuse it? What if you don't like how they reuse it?
History has shown that this has happened in only rare cases. And even then, having your code reused is an homage towards your creation. People started to understand that and it gladly became very common practise.
But it seems like the story starts over from the very beginning again, the field though is a different one. It's now graphic artists and especially musicians who are facing the same fears this time. But I think, it shouldn't be me writing this because I'm neither (well, only very few people consider ASCII art as proper art. Probably even less than consider good code to be art..). Good thing is, I don't have to. One of the wesnoth graphic artists did it, and way better than I would ever be able to get the idea across. So here you go: Jetryl about GPL Policy in wesnoth. It might be long, but it's definitely worth the read, and I hope it will help to make some people understand better and fear less.
Wow, don't even remotely remember anymore when I was last blogging about going to the cinema. Granted, I wasn't that often in recent times, but I haven't mentioned some movies... Whatever.
Yesteday I have been to cinema again, and we watched "The Dark Knight". To be honest, I regret to have gone. The movie is as dark in its setting as the title says, even darker than what was common in previous Batman movies. They turned Batman into James Bond style, turning Morgan Freeman into Q, and using cheap Eminem quotes. I feel sorry for Heath that this was his last movie to star in. Even his great performance wasn't able to save the movie, and it's sad that this should be the movie people will remember him with... You deserve better, buddy.
Last week I wondered how much space a complete git conversion would actually need—and I was quite surprised:
$ du -hs webwml*
325M webwml
416M webwml.git
819M webwml.svn
The first line is the regular CVS checkout. The third line is the SVN checkout that's available from alioth. You can see that the size is not really something one would want, especially since the real gain is extremely little: besides offline diff you rather have disadvantages with not being able to do much offline because anything history wise requires you to be online. In CVS you at least knew that revision 1.12 of a file is three commits above revision 1.9 of the same file; while in SVN you have no chance offline to know how many commits to a file happened between revision 512 and 1024, if any at all.
The conversion to git took me quite a long time, practically almost three days of (non-constant) running git-cvsimport on my laptop. The time did not completely surprise me, at least when I noticed in the end that it were well over 83 thousand commits in well over 10 years, reaching back to July 1998. My first own commit was in July 2001, which wasn't too hard to find out with git neither, and required no online operation.
git gives you complete offline access to the history. This is actually something that the build process can be based on. There propably will be some speed drawback with not being able to do simple-math for revision difference like in CVS, but that actually will have to be checked. I'm still convinced being able to do all the stuff offline without any strange hacks or needing to be online all the time is something worthwhile.
Things left to do and which I propably won't find the time in the too near future because of ... erm, you know? Lenny? That we want to release? But anyway, to not have the list of things get lost, here is a (not complete) list of things in case you are bored and want to play around a bit:
Adapt the various scripts to not check CVS revisions but use the sha1 sums.
Adjust translation-check translation="" value for all files to use sha1 sums.
Check wether a full website build would work after that changes.
Try out how submodules work and wether they might be reasonable to use for language subdirectories to allow translators partial checkouts.
... other things I've forgotten but that could be added to the WebsiteVCSEvalutaion wiki page.
Playing around a bit? Well, you don't have to do the whole git-cvsimport on yourself: I've pushed my webwml.git repository to alioth: "git clone git://git.debian.org/git/users/alfie/webwml.git" should get you started. Please notice to play around in a seperate branch and not directly in origin to be able to pull further and update from time to time.
For quite a while I'm already looking forward to this year's Two Days A Week festival. To be precise right from when I saw the first poster about it and me finding the name of one of my most favourite bands on it: Live. I haven't seen the guys from the US for a long time now and am absolutely eager to see them on stage again.
But today came the next shock: Some few days ago Slipknot had to cancel their attendance because of the injury of one of their band members, they have found a more than adequate replacement: Apocalyptica!!!! Wiesen, I'm coming!
scons claims to be a better replacement for make, or rather especially autofoo magic. Unfortunately, it isn't. To me a proper build system should definitely be able to clean up behind itself. The reasoning flying around for why scons isn't able to do so are quite hilarious, ranging from that it doesn't know what it generates (how does it generate them in the first place?) to that it's extensible and thus can't be done properly (then the extensions are broken and should add their clean informations in a hook or such, too). I haven't seen any valid reason for why it shouldn't be able to do so—yet we still seem to need to clean up cruft lying aroud like .scons* files and directories, config.log and of course the build/ directory.
People, if you really want to do some proper build system, don't forget to make it clean up after itself. It shouldn't be the requirement of application developers to fix that (which doesn't really work because a scons target trying to clean the files makes scons crash).
![[rss feed]](/pics/logo-xml.png){kind=logo}
![[html by vim]](/pics/logo-vim.png){kind=logo}
![[graphics by gimp]](/pics/logo-gimp.png){kind=logo}
![[generated by wml]](/pics/logo-wml.png){kind=logo}
![[powered by blosxom]](/pics/logo-blosxom.png){kind=logo}