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!
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.
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!
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".
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.
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 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.
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. :)
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.
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).
Sometimes things like these happen. Noone really did expect it, but it did: blosxomVersion 2.1 got released by the new Upstream Team. It does incorporate all previous Debian patches which I'm quite happy about, and contains other long standing and needed fixes and changes.
Though, there is also a tiny drawback in that, especially for the Debian package: some of the changes might not be totally approved by all the users of the Debian package. This is unfortunate, but it had to be done to get the package finally yet in a cleaner state (maybe you remember the cleanup run when I originally took over the package). Please be sure to read the NEWS.Debian entry (apt-listchanges might help here) about the most important changes, one of them might even mean that upgrades to this package will flood planets. This is extremely unfortunate but for getting things clean unavoidable:
blosxom (2.1.0-1) unstable; urgency=low
* This update is a major switch, all local patches have been incorporated
into upstream version again. Furthermore, html and rss flavours are now
included in the blosxom script directly and the old 1993 and index
flavours are not included anymore, to get rid of some further historical
annoyances with the packaging.
* MOST IMPORTANTLY: This update adds a new tag into rss feeds:
<guid isPermanentLink="true"> which helps to notice duplicates and not let
them appear again on planets. Though, for the time of switching it might
mean that your last entries might appear as new when planet doesn't check
<link> (which already should be cached) when finding <guid>. This is
unfortunate but not really avoidable. To limit impact a new plugin was
added: 00RssLimit which turns the syndicated feed in only pick up the last
5 entries.
* The plugin timezone got disabled and gets only installed into a new
/etc/blosxom/plugins-available directory which is the first step to the
planned blosxom-plugins package. If you found it useful and made use of it
just symlink it from the plugins directory.
-- Gerfried Fuchs <rhonda@debian.at> Fri, 25 Jul 2008 16:19:49 +0200
Technically it means you might want to tweak the included 00RssLimit plugin to even just 1 until you blogged some more and raise it with time if your blog runs through some planet. If you do the upgrade, did set 00RssLimit to 1 and do not reappear with your last entry on your planet sites feel free to switch it back.
Again, this is an unfortunate situation, and it's not really related to the Debian package only–the addition of the <guid> tag happened upstream and will affect all users of blosxom. It's just that I added the selfwritten 00RssLimit plugin to reduce the impact for the Debian users. Hope you don't mind. ;)
Ah yes, and if you might ask where the package is: I did put it into my website for now so people have some time to stumble upon this blog entry before they install the package from unstable without prior notice and maybe not even using apt-listchanges. I will upload the package within the next day.
One of the things why I was on the tracks for getting src:wxwidgets2.8 into the pool was to be able to get a recent pgadmin3, too. The one we currently have in testing/unstable isn't even anymore able to cope with our default postgresql-8.3 version.
Now that wxwidgets2.8 is in experimental for a while I tried to suggest a pgadmin3 upload to experimental. Unfortunately the package maintainer seems to be quite busy these days, thus I prepared an NMU for it, planing to upload it into the pool at the start of next week. All involved parties received mails about it—that also includes the bug reporters of the bugs it would fix. For your convenience, if you are interested, you can find the package in the meantime on my private server: http://rhonda.deb.at/debian/pgadmin3/—feel free to give it a test and send feedback along.
One of the freedoms I value is the freedom to choose what you spend your time on and who you spend it with. And while I believe that people in key roles in Debian still have those freedoms (hey, 2.1(1), don't you know), reality these days even confirms that. So long, and thanks for the fish.
Quite a lot people are unhappy with how the package descriptions are translated. Different teams handle it differently, but the approach the German "team" chose is quite unfriendly from a quality point of view: The webinterface for it doesn't require any authentication at all, leading technically to anonymous translations all over the place. The so-called "review" process consists of the same not-existing authentication, leading to a situation where unknown people can put in whatever they like and have other (or potentially the same) unknown people acknowledge that.
The language team has actively chosen that way because it was said that bad translations simply won't happen and that the review (three people opening the page and clicking onto a button) will not let that happen. Well, it happened. And is happening all over the place. Things like "Gedultsspiel" and "Murmelirrsinn" are pretty tough and almost hiding translations from "counting pipe" to "Zählrohr" and "villages" to "Orte" (and no, those aren't the only examples that accumulated over the last months). As this all happens anonymously one can't even get a message to the people submitting (extremely) low quality translations, helping them to improve their skills so they won't do the same mistake in future translations; meaning things are hard to improve.
I am usual an advocate of translating stuff, did put a lot of effort into that area—but the total lack of quality in not only a small and tiny bit here but a much broader area is why I suggest to everyone (at least from a German language point of view): Put APT::Acquire::Translation "none"; into your /etc/apt/apt.conf file and don't get annoyed by them. When quantity is the only thing that counts people wanting to have quality are simply ignored with their mails on the lists.
... are still there, even if I don't blog about every single bit all the time. Most of the packages I care about are in good state, I even did jump on board of irssi co-maintaining and got its bugcount down a fair bit (though I won't rest at this stage, there are still some to go) and did jump onboard of the pkg-games Team.
... which brings me to wesnoth. For quite a while I am tracking the stable releases (1.2.x) of wesnoth in unstable while the development releases (1.3.x) are followed in experimental. With the upcoming stable release 1.4 this though will change. The development branch is feature frozen and thus will be (propably) compatible with the next stable release, and furthermore the current stable release isn't expected to receive any further update. My plan is thus to upload the next development release directly to unstable. If you want to give it some additional testing before that happens pull the package from experimental now and give your feedback, thanks.
Furthermore I am also tracking some packages for backports.org. I usually do the packaging of it almost synchronous to its upload into unstable although it is only allowed onto backports.org when it entered testing. For the timegap in between you can usually find it on my website repository. Directories that aren't empty there have some upload to backports pending and you can feel free to test the packages and send me feedback on them. Currently this includes bacula, slony1 and postgresql-8.3.
One last note, finally it happened: apache1 isn't anymore. There were two packages left in testing until recently which got their removal requests adjusted. Thanks to everyone involved in keeping track of this and helping cleaning up the archive.
Since quite a while gettext has support for a feature which I was waiting for since ages: --previous. It means that when a string gets marked fuzzy it adds the previous original string as a comment so one is able to see the difference which led to the fuzzy marking. This makes translation of po files much much more comfortable because one can easily find out now what has changed. Let me give you a reallife example:
With out the previous string (in the "#|" line) you would propably be puzzled about what has changed because the string gets stripped off the everything before the ^ for displaying it in this case.
Though, not all translation tools behave correctly. One of them is unfortunately poedit. It moves the previous string to a wrong place and thus breaks the parsing of the file. A bugreport has been filed about it—but unfortunately it also means that upstream projects that already support (like Wesnoth) it are considering disabling it again because of this. So I wrote quickly a perl script that is able to fix that for you: pofix.pl. It's quite simple, reads from stdin and writes to stdout.
Go and support --previous before your competitors do it and hijack all your translators! ;)
ccr has uploaded a new beta version of his fabulous xmms-sid extension for the X MultiMedia System which now also supports localization. I have prepared a package so you can test it, start localizing it for your language, or just enjoy it. I have noticed some possible wrong implementation of the i18n infrastructure, I had to do the msgfmt for the de.po myself — if you know what goes wrong here any input is absolutely welcome.
Recently Dunc-Tank was created. An effort, instantiated by the current DPL, it is said to improve Debian. Personally I am quite sure it's rather the opposite, especially when the people coming up with the idea are the people in charge currently and are giving the thing a quite official feeling. And money next to never is a good motivation for quality, especially when working on parts people usually don't work on. The quality Debian has is because people work on the parts they have interest in themself to get improved — that's the way Free Software really works.
But, there's one really good thing about it: Now that people are going to get paid to work on Debian, it motivates me to take a step back and spend some more time on other things. More free time for everyone, because there are the people getting paid now! Thank you very much, Dunc, for giving us back our free time!
I've uploaded a CVS snapshot of abook yesterday to experimental. Cédric Duval did commit really useful stuff there, like the possibility for user defined fields and views, renaming the custom fields, and lists which can contain a quite big amount of entries.
It would be nice if you could give it some testing and send in feedback about it so that I have more than just my own impression about it for deciding if it's ready to upload to unstable for it making it into the release of etch.
Some things I've noticed so far: You can't use a comma in lists because it is used as field separator. Yes, this needs to get changed, but it is no real regression, because the only list used before was the email addresses and you wasn't able to use it there neither. The date field type isn't yet completely supported — it is planed to have content checking in it, I could think of having flexible display ways for date fields, too. So far it has its reason why it isn't released yet upstream, it has its problem, but I think it is still a great advancement over the current stable release and would make sense to get included in etch. Give it a try and report back, either to me or to the upstream list.
After two weeks and a bit it finally happened: I hit austria again. But, first things first. I guess everyone noticed by now that at the start the network wasn't our best strengths. I helped as much as possible, collected network cable back from one path to lay it out at a different one just to find that the about 200 m were a bit too short (or rather, me was lying the cable with too much safety). Though, it was too long anyway to be relyable, to it was cut in the middle and a small access point was put in. Later it had to be replaced because we were running a bit short of specific power supplies.
But it wasn't too bad, waiting for some more rj45 plugs and other things even allowed Ganneff to spend some time in the pool and relax a bit. And given that there seem to have been a few (vegetarian) people less than registered for sponsored meals allowed stockholm and Vagrant to get extra dishes to get fed. People during the debcamp mostly enjoyed themself, mao was played, fights for the gay vegetarian sign, tetrinetx on homer when only local network was available, and I managed to translate the new wesnoth tutorial into german. It wasn't clear by then that the new release will be delayed due to other problems until after the debconf, but in my opinion the tutorial is one of the most important parts of any games because it explains the basics, so I wanted to be sure that there won't be another release without a fully translated one.
About enjoying oneself: I tried out the skirts I brought with me and considered them absolutely comfortable. You'll find me more with one, especially when it gets warmer. It helped me to be more "myself". Also I enjoyed the weird looks and repeated questions about my shoes — although it was often that I was walking barefooted; but that got a bit of a pain, especially after noon when you were able to boil eggs on the stones. And given that I forgot myself when I switched from blue/red shoes to red/blue ones you don't have to send in your guesses when it was done because I can't tell who would be the winner anyway. ;)
The end of the week came, the Debian Day was here. Closer to its happening more and more people arrived and it was becoming more crowded in the hacklab. The network became more and more stable, the video streaming setup got finalized, and everything looked alright. Some of the mexico city people stayed for the night and enjoyed the friendly atmosphere (and a beer or two ;)).
The debconf started for real, the talks started, people were busy all around, zack added me to the alioth pkg-vim project to continue helping with the hijacked debian specific syntax files. Haven't done much yet beside a checkout, still pondering where I can bug around most ;)
I was looking forward to bubulle's BoF about the i18n infrastructure. It was really inspiring, and I collected some ideas for what the tool-to-be-created should support. The second BoF later the week just showed that others were mostly thinking along the same lines, so I hadn't much to add. Still I am looking forward to join the effort to make it happen — I was playing with the idea about such a tool for ages now, and I guess this is what it will make it happen, finally. Christian is so much more able to get people interested and together for making it happen than me... :/
Some of the evening featured interesting things too, like a cheese BoF, the everywhere featured formal dinner with its mariachis, the waterfall and the blackout; special effects you wouldn't be able to plan as well as they happened — though Martin Ferrarri had a small accident with it when water rushed down onto his plate and spilled the sauce over his white shirt and the table. And then there was the hard liquour BoF where I quit after the eggnogg.
The week passed, I got my hair dyed and rid of my beard right in time for the group photo. Thank you nattie, a thousands time, it went better than I expected! Really like it. I didn't attend the fun photo in the pool the next day, was a bit late after the talk, didn't had my bathing slip with me, was worried about my newly dyed hairs and was nervous... because a person I was looking forward to meet again was late. But gladly only late, so I got rid of my nervousness and enjoyed the last official talk (formerly mentioned i18n talk) of the week, and explained to some attendee that even in languages like French, German and English (yes, no mistake) there are still areas we have to struggle with all of this, like when keeping things up to date and the likes.
It was the last evening in Oaxtepec for me because I refused to leave by bus at 4 in the morning, rather wanted to spend the night in Mexico City to at least be able to have seen a tiny bit of it and eat something my tummy enjoys completely. :) I guess I don't need to point at sandino's gallery about that evening anymore, thanks to Gunnar. And yes, I'm mentally disturbed, but that shouldn't be anything new to people who know me for a while, or is it? ;)
This night was too long (less than 4 hours of sleep is even for debconf not much), so I rather went to bed early after a small walk (just 2 blocks or such) in the city and a nice dinner with friends who are missing the nice time too and was wearing too big sort-of shoes. Went to the airport in the morning by taxi whose driver gladly was able to speak english. Met zack and Martin Ferrari again there, and some other people with whom I was taking the same plane with. They were hacking along on the airport, found the open wifi, using power supplies from differentspots. Bubulle already wrote about the two loud guys, gladly I wasn't too close to them, and plugged myself into the music and movie channels from the plane. The showed Last Holiday (which I really liked, although in the ending I started to cry — mostly because I started to realize what I was leaving...) and two spanish movies of which I don't remember the titles. People started to hack away in the temporarily set up hacklab and we started to wonder how much power they might have, though they cheated: They used two battery packs...
In Madrid some more people parted and we were down to 5 people. I bought totally overpriced playingcards so we could play Mao, had a short nice session and spread the word. We did hack the baby room power supply and hacked along a bit more, and then Peter and me were off heading to vienna, finally.
All in all I really enjoyed it. Although there were its down times, sunburned, my butt hurting a bit because in the end I did jump from the 10m platform into the pool, it still was a really nice event and even though I guess many people tried to enjoy themselfes quite some things were acomplished. If not really codewise, then at least social-wise, which will benefit quite well in the future, I'm sure. Hope to see you all next year, wherever that might be.
thanks, Ted, for spoiling what was expected to be the nicest evening of the debconf. And thanks to the organizers for the really great special effects with the light plays and the waterfall; really!
... and already liking it. Though, first things first, some notes about the trip so far: The plane from vienna took off 50 minutes late due to weather reasons. It was quite nice, though, and I hope that some of the night pictures of town lightnings are usable. At least the delay reduced my waiting time at the madrid airport quite a bit.
Which brings me to that airport. It's... HUGE! I mean... erm, it has signs telling people that it will take 25 minutes to the gate that the plane to mexico will be leaving. And that is including the trip on some underground train they have that it doesn't take you much longer than that... But appart from that, I arrived on the gate area before midnight so I was able to order some drink at the starbucks. At least some shop that knows how to let people enjoy the waiting time. :)
The plane to mexico left on schedule at 1:50, so it was completely dark outside when we started. And almost the whole trip, up until about the last 20 minutes or so of the 13 hour flight, it was completely dark outside, because we were travelling ahead of the sun. So it wasn't too bad, being able to get some good sleep, at least as good as possible on a plane.
Having arrived in mexio airport with a short delay and waiting a bit for my suitcase I finally met up with Frans Pop, because I was too scared of getting lost without any sense for the spanish language yet. We took one of the prepaid official taxis to the bus that will take us the rest of the trip. The taxi drive was really... well, interesting. It was the fastest trip I've ever seen in any car in city area, but the bad thing: I can't even tell you how fast we were at times because the speedometer was b0rked and displayed only zero all of the time. I guess taxi drivers are most the same all around the world, but this one definitely mastered the art.
The bustrip wasn't anything notable, besides a bit tiresome due to the air in the bus, the partly monotonous vegetation outside and that I was sure to not be able to watch the movie to the end, besides that the sound was too silent. :)
Finally arrived at Oaxtepec, which turned out that our hotel seems to be in some sort of recreation area, maybe even a bit of themepark... At least it has some rollercoasters, at least they showed them on the video. We'll see. I at least tried out the pool already, it's not even feeling cold for me. Not have met all the people yet that are rumoured to be around already, but I guess it might happen at lunch, which is expected soonish. Due to network not working though this blog post will have to wait until afterwards.
/me wonders why people seem to prefer a webbased, flash game when we have the very same thing in our sgt-puzzles package called untangle. Wasn't Debian and sort of Planet Debian about mainly free software, back then, somehow?
I know for myself that picking up unparsed userdata is teh evil. But we also all know that the usual webpage and mailer script coder isn't thinking. And to my knowledge the php mail() function is the only one that perverted to parse the headers additional to an explicit given recipient list for additional recipients. Yes, you read right. Often enough people use things like mail("myown@addre.ss", "subject", $body, "From: $_POST['name'] <$_POST['email']>") without thinking about it, because, there is this extra to field anyway. Right? Wrong! SPAMers will come and send things like email="some@jo.ke\nBcc: my@sp.am, list@is.bigg.er, than@you.rs". People that put up such webmail scripts usually don't notice it anyway, they just delete the spam right ahead, not noticing that it was an abuse of their form. And the ISP has to deal with having to get the system out of the blacklists again....
At least none of the hosts on which customers are able to put up such scripts directly affect our own mail system, it's just the shared hosts they use... Still, deadly annoying. And then people are claiming that such misfeatures aren't a problem in PHP but in the coders? If it would at least be documented in the description of the function, but if one can claim it that it is it's at most just very vague hinted...
I know, I know. A bit early, you might say. But let's face it: The shopping industry is already fully into christmas. You already get advent calendars, christmas cookies and thing in the various stores. And I got my first christmas presents the last week....
First of all I finally tried again to switch to Linux 2.6. Going through the great amount of options in my make oldconfig from 2.4 I finally tried to boot with it. The most deep changes I did was:
Switching from APM to ACPI: This was one of the things I was worried about. But there was nothing to worry, I now can even see the temperature of the processor!
Software Suspend: I now can shutdown my system to disk! That rocks, and seems to be more stable than the former APM sleep mode, which occasionally had problems with waking up again...
The powerbutton now performs a shutdown. Unfortunately it is the only button that seems to get recognized, the key bindings with the function key don't do much. But I am confident that this can be settled out, they are sending keycodes. Calling acpitool manually isn't that much of an annoyance yet.
Switching from OSS to ALSA: Another thing I was worried about. But I found out about the OSS emulation, so that reduced my worries. In the end I'm now even running without it, programs like mp3blaster I'm running with the wrapper from alsa-oss. Switched the few packages that were OSS specific on my system (like the SDL sound package) afterwards and am happy with it.
Framebuffer module neofb works now built in! Finally I also can play around with some nice boot logo, and in connection with software suspend this isn't even wasted time. :)
This was my own christmas present. But I got some more, from a dear friend whom I'm working with and helping from time to time. More in a funny way I sent him a christmas wishlist, but he took it serious, and so there I am. Like, with a Gameboy Advance SP Kingdom Hearts Edition, including the game. I really loved the first part on my Playstation 2, am desperately waiting for the second part which shall be released in europe in spring next year... *sighs*
The second major part was a Typhoon My Mini DJ music player. Most important thing for me with it is that it plays oggvorbis files natively. Finally I'm not the only one without a portable music player!
Last but not least I'm going to attend LWE in Frankfurt/Main, and finishing my LPI Level 1 certification there. I'm not too worried about the test, though it for sure will be a good feeling to finally have something written and not only you lot telling me that I have some knowledge about it.
Yesterday night grml 0.5 - Codename Tokolytika was released. I can just repeat my last remarks: grml is a charm when it comes to restoring systems, or in other tricky situations where you need your sysadmin tools handy. Saved my day quite often so far, and I'm sure it won't stop. Get it now! I simply don't know any better live CD.
For those who wonder what I was doing in the last time: I had been to the last Friday Night Skating of this year. The last hundred meters of the almost 2 hour lasting course I got pushed because my legs had finished early... Thank you very much, Conny!
All in all it was a great event and I'm sure to visit it more regularly next year. :)
Workload both at work and private didn't really stop for quite some weeks, it was a horror. I wasn't even able to reasonably follow any mailing lists, left aside to do any real work. Though if you noticed my 1.2.2-16 upload of beep you might know that I also have invested quite much there.
Furthermore I managed to get some people of our Debienna group interested in the g++ 4.0 transition. Greek0 wrote some scripts to bring the data of mfurr's page into one (for us) better suited to use and work from. In our wiki we write down our progress to keep us updated on who's working on getting what in.
I don't have real numbers, but from tracking mfurr's list of packages needing a recompile it went down quite a bit since we started, and we don't plan to stop soonish.
And finally: I've written an article about jigdo-lite for my company's magazine. It's the 5th issue of the magazine, and my third article for it (first has been about gnupg and second about MUDs). I like writing, and from some of the feedback I received people like reading me, too. :)
![[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}
