Planet freenode

June 13, 2015

erry's blog

Form sins: part two

This is a continuation of my previous rant on mistakes web developers make that make forms unusable. Here are other things I’ve noticed, mostly about forms that need your address:

  • Requiring a ‘middle name’. They’re not used in every country in the world.
  • Having a broken country input. This, in my experience, has ranged from having only one country option (????), to doing something that will break the browser’s ability to skip to a particular option by typing the first letter. By the way, why do we even use select boxes for them in 2015? This is one of the things that you would be absolutely justified to use a jquery autocomplete box for (with a select polyfill if JS is disabled)
  • Requiring a “state”. Most forms nowadays are smart enough to change the input depending on the country, but not everyone lives somewhere with states.
  • AJAX submit flows without a loading indicator. Great, thanks for having me guess if your form is stuck, if I clicked the button wrong, or if I just need to wait because you didn’t do anything to indicate I’m waiting for an AJAX request.
  • Purchase flows that don’t have a way to go back to the previous step or cancel on every single step. I saw this on a piece of software: “connecting to paypal” screen, something went wrong and the paypal window never opened, and I had no way to cancel and go back without closing the window and starting over.
US only form option

Gee, thanks for the option..

So, what do you think? Am I, once again, just being grumpy? Should there be a part 3? :-D

by Errietta Kostala at June 13, 2015 02:50 PM

June 12, 2015

RichiH's blog

Happy Friday!!

So, what do you do before you break the Internet?

You tweet this:

by Richard 'RichiH' Hartmann at June 12, 2015 11:31 AM

June 10, 2015

erry's blog

Web forms

Web forms. They are used everywhere.
Yet I have seen so many things done in them, that have made it difficult for even myself (a tech-savvy user, a web developer) to fill in. This should not happen.

Filling in web forms is required for many reasons, yet to many users it’s possibly the most tedious part of the user experience. This is understandable; it requires typing in information, having to find your credit card if you’re making a purchase, remembering your email and phone number, and often making mistakes and having to start over.

In order to not have our users ragequit in the middle of filling out our form, we should at least make it as easy as possible, and not hinder their experience even more.

Here are some things (in no particular order), that I have witnessed happening in web forms, and that I absolutely don’t think you should do. Some are more opinionated, others are common sense.

  • If it takes more than one try to fill out a form (barring typos, etc) you’re doing it wrong.
  • If you’re using custom JavaScript controls that break in certain browsers or make the experience harder rather than easier, you’re doing it wrong. Find another way to present your input field. I would much rather have to type in my birthday than deal with a JavaScript calendar that displays incorrectly and in which I have to manually go back 21 years to find my birth year.
  • If you’re using your own autocompletion script without disabling the browser’s, your punishment should be having to fill out your own form. Seriously, it’s nearly impossible to select something from a JQuery drop-down when your browser’s autocompletion is displayed on top of it. Just disable autocomplete for that input and move on.
  • For most forms, if your form takes more than 2 minutes to fill out (not taking typing speed into account), you’re doing it wrong. If it has to be a long form, please at least consider breaking it in different parts.
  • On the same note, if the form is something that you know takes a long time to fill out (e.g. job application forms with many/long questions) and you expire sessions after 30 minutes (I’ve had this exact thing happen…), your punishment should be having to fill out your own form.
  • If my grandmother can’t figure out your form on the first try, you’re doing it wrong.
  • If your form isn’t usable from a screenreader, your code should be able to take your ability to see away.
  • If your form requires JavaScript, seriously re-think it. JavaScript can be used to make the experience faster and easier to the user, but for the most part your average form should not require it. This is particularly bad if you have the submit button disabled by default with no explanation. Never, ever, do that.
  • If your form loses the filled in data after an error, you should have to fill out your own form 10 times.
  • If your form doesn’t make it clear where the error is, you’re doing it wrong.
  • If your form has required disabled fields that are automatically filled in based on other input… (Yes, I’ve seen forms that do it. It never, ever works well. Ever.)
  • Bear in mind that people on the Internet don’t read. They skim through text. Therefore, if most forms do something one way, you should probably not try to do it the opposite way. What do I mean with this? Today I saw this:

    “Are you under 18? [ ] No [ ] Yes”

    99% of forms I’ve seen usually have “Yes” radio buttons first. I accidentally selected the wrong option in the form I’m talking about, and it actually managed to confuse me. I know this may just be me reading even less than the average user, but i would personally rephrase the question: “Are you over 18? [ ] Yes [ ] No”. This is both closer to what most forms do with age questions (asking that you’re over the required age), and closer to (at least my) expectations of the order of Yes/No buttons.

What do you think? Do you agree with the above, or am I just grumpy and nitpicky?

by Errietta Kostala at June 10, 2015 10:19 AM

May 30, 2015

erry's blog

Calling all women in IT

Hello,

So, being on the Internet a lot, I’ve seen several tweets from tech event organisers that have had difficulty finding women in IT to invite to their talks. While I understand there are (unfortunately) less women in STEM than men, I know that there are still many very talented women. So, I want to write a blog post highlighting women in tech and IT (or even other STEM fields!) and their talents, in order to make it easier for event organisers to find them.

So, this post is targeted at YOU! Are you a woman in technology/IT or another STEM field anywhere in the world?! Write a short paragraph about yourself and what you do in your work and email it to me at [email protected] and you will see yourself here*

*Admittedly not the most popular website in the world…

by Errietta Kostala at May 30, 2015 05:12 PM

May 29, 2015

RichiH's blog

Do what I want

Sesse just gave me the most useful piece of information of this week:

To zoom in/out in Android, you double tap and then drag your finger. All of a sudden, you can use Google Maps in one-handed operation again!

A quick search turned up this gem: Touch mechanics on Android.

Neat.

by Richard 'RichiH' Hartmann at May 29, 2015 10:19 AM

May 28, 2015

RichiH's blog

On SourceForge

You either die a hero or you live long enough to see yourself become the villain.

And yes, we all know that that SF decided to wrap crapware around Windows installers ages ago and then made it opt-in after the backlash. Doing so for stale accounts makes sense from their PoV, which makes it all the worse.

And no, I don't know how stale that account actually was, but that's irrelevant in this context either way.

by Richard 'RichiH' Hartmann at May 28, 2015 12:09 PM

May 18, 2015

erry's blog

A quick review of Scratch

My life as a CodeClub volunteer consists mainly of complaining about wonderful public transport options and working with a program called Scratch. In this post, I will talk about the latter, as it is probably more interesting ;)

Scratch is an interactive, drag-and-drop programming language that allows users to make animations and games. It’s perfect for beginners, as it helps them understand the logic of programming without needing any prior knowledge! The knowledge gained in Scratch can then be applied to real programming languages.

The Scratch Interface

The Scratch Interface

So, how well does it work? I will go through some pros and cons. Note that these are nothing but my own opinion ;)

Pros

Easy to use interface

As mentioned earlier, the interface is very easy to use. You can drag and drop various ‘blocks’, categorised as motion, looks, sound, etc. Definitely easy enough for a 10 year old kid to use.

Online version

Scratch can be used online without downloading. What is more, you can download and upload your work from and to the website, so students need not make an account to save their work. Again, this is good for using in a school environment where installing software may not be possible, and eliminating the need to make an account is useful for students – no need to remember passwords, etc.

Fun!

Scratch can be used to make very fun projects that spark one’s interest, especially when teaching to children. Having fun is the best way to learn. For example, some of the projects I have taught students to build were a space animation, a band, and a game with balloons. Who doesn’t like these things!?

Cons

Scratch has some things I don’t like. Of course, no software is perfect, so this is hardly surprising.

Flash

Scratch requires flash

Scratch requires flash

Need I say more? Dear MIT: 1996 called, it would like its web technologies back.

Now, I understand Flash is a relatively easy way to make applications that will work cross-platform. However, my biggest problem is since Adobe dropped Linux support for Adobe Air, one cannot run the native application on Linux any more. The web version will of course still run as long as flash is installed. However, this is problematic for those wishing to use a raspberry pi for teaching and learning. Raspberry pis are cheap computers, so breaking them is not a problem, and they can be used for building many interesting projects. However, running the web version on a pi may be difficult due to lack of resources – a native version would be SO much better…

The colour scheme.

Blocks are colour coded, which is great – students can immediately know which category a block belongs to just by looking at its colour!
…Except when they can’t.

Coloured blocks

Coloured blocks

As you can see in the above screenshot, few colours look very similar: Motion and Looks (and to some extend, sound), as well as Data, Events, and Control are nearly identical. This problem becomes worse if you’re colour-blind:

How scratch looks with deuteranopia

How scratch looks with deuteranopia


How scratch looks with protanopia

How scratch looks with protanopia

But what’s even worse is that these colours look almost identical when looked at from an interactive board, especially from a distance. This confuses my students because they keep looking in the wrong categories. This may be a problem with the interactive board, but they should have made more of an attempt to make the colours look different, since interactive boards are very common in classrooms.

Closed source.

Last but not least, Scratch is, unfortunately, closed source. This is a huge pity, given that it’s supposed to be about learning and sharing, but its creators seem to have no interest in helping others learn from their work. If it were open source, people could adapt it to their needs, contribute features, and learn from its code!

So, what do you think? Do you use scratch? What’s your opinion? Let me know in the comments, or don’t.

PS: Sorry for not having posted in 100 years.

by Errietta Kostala at May 18, 2015 12:59 AM

April 24, 2015

RichiH's blog

Release Critical Bug report for Week 17

At the current rate, Jessie should release... tomorrow! :)

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1040 (Including 150 bugs affecting key packages)
    • Affecting Jessie: 66 (key packages: 49) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 57 (key packages: 43) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 14 bugs are tagged 'patch'. (key packages: 10) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 3 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 40 bugs are neither tagged patch, nor marked done. (key packages: 33) Help make a first step towards resolution!
      • Affecting Jessie only: 9 (key packages: 6) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 0 bugs are in packages that are unblocked by the release team. (key packages: 0)
        • 9 bugs are in packages that are not unblocked. (key packages: 6)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41) 97 (68+29)
12 release+6 93 (47+46) 87 (71+16)
13 release+7 50 (24+26) 97 (77+20)
14 release+8 51 (32+19) ???
15 release+9 39 (32+7) 82 (49+17)
16 release+10 20 (12+8) 53 (49+4)
17 release+11 24 (19+5) 66 (57+9)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at April 24, 2015 01:08 PM

April 19, 2015

RichiH's blog

Release Critical Bug report for Week 16

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1031 (Including 146 bugs affecting key packages)
    • Affecting Jessie: 53 (key packages: 42) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 49 (key packages: 42) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 12 bugs are tagged 'patch'. (key packages: 9) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 3 bugs are marked as done, but still affect unstable. (key packages: 2) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 34 bugs are neither tagged patch, nor marked done. (key packages: 31) Help make a first step towards resolution!
      • Affecting Jessie only: 4 (key packages: 0) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 1 bugs are in packages that are unblocked by the release team. (key packages: 0)
        • 3 bugs are in packages that are not unblocked. (key packages: 0)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41) 97 (68+29)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at April 19, 2015 09:35 PM

April 10, 2015

RichiH's blog

Release Critical Bug report for Week 15

Still on the road with shittynet; sorry for missing last week.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1041 (Including 159 bugs affecting key packages)
    • Affecting Jessie: 82 (key packages: 54) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 65 (key packages: 49) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 19 bugs are tagged 'patch'. (key packages: 13) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 6 bugs are marked as done, but still affect unstable. (key packages: 1) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 40 bugs are neither tagged patch, nor marked done. (key packages: 35) Help make a first step towards resolution!
      • Affecting Jessie only: 17 (key packages: 5) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 8 bugs are in packages that are unblocked by the release team. (key packages: 5)
        • 9 bugs are in packages that are not unblocked. (key packages: 0)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41) 97 (68+29)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at April 10, 2015 05:45 PM

April 01, 2015

erry's blog

Goin’ to space

I’m happy to announce that I have been selected for one of the most amazing employment opportunities – being the first ever programmer on Mars!

I have been living and training at NASA’s Johnson space centre the past few months, and I am finally ready to be launched into space.

By NASA (Great Images in NASA (image link)) [Public domain], via Wikimedia Commons

By NASA (Great Images in NASA (image link)) [Public domain], via Wikimedia Commons

I will be travelling on the newest, most high-tech space shuttle devised by NASA, which uses classified technology to reach speeds as fast as 0.05 times the speed of light. With that speed, it will only take just over 6 hours to get to Mars!

After arriving, I will be living and working in the underground human settlement that exists on Mars. The work I will be doing is currently classified, but my employer plans to make the software I will develop open source as soon as it’s complete. The outcomes of my work will benefit research – both on Mars and our own planet! I will even be able to work with Mars’s native leader, King Xrhsdpmdf IV, which is a great honour.

I will be leaving this planet forever on Monday, 6th April 2015. I will miss my friends and relatives here, but don’t worry: using a Satellite Internet connection, I will still be able to communicate with you guys!

by Errietta Kostala at April 01, 2015 10:39 AM

March 27, 2015

RichiH's blog

Release Critical Bug report for Week 13

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1039 (Including 155 bugs affecting key packages)
    • Affecting Jessie: 97 (key packages: 65) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 77 (key packages: 51) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 13 bugs are tagged 'patch'. (key packages: 9) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 4 bugs are marked as done, but still affect unstable. (key packages: 1) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 60 bugs are neither tagged patch, nor marked done. (key packages: 41) Help make a first step towards resolution!
      • Affecting Jessie only: 20 (key packages: 14) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 11 bugs are in packages that are unblocked by the release team. (key packages: 7)
        • 9 bugs are in packages that are not unblocked. (key packages: 7)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41) 97 (68+29)
12 release+6 93 (47+46) 87 (71+16)
13 release+7 50 (24+26) 97 (77+20)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at March 27, 2015 08:42 PM

March 25, 2015

RichiH's blog

Visiting Hongkong and Shenzhen

TSDgeos had a good idea:

Lazyweb travel recommodations.

So, dear lazyweb: What are things to do or to avoid in Hongkong and Shenzhen if you have one and a half week of holiday before and after work duties? Any hidden gems to look at? What electronic markets are good? Should I take a boat trip around the waters of Hongkong?

If you have any decent yet affordable sleeping options for 2-3 nights in Hongkong, that would also be interesting as my "proper" hotel stay does not start immediately. Not much in ways of comfort is needed as long as I have a safe place to lock my belongings.

In somewhat related news, this Friday's bug report stats may be early or late as I will be on a plane towards China on Friday.

by Richard 'RichiH' Hartmann at March 25, 2015 09:56 AM

March 23, 2015

Pricey's blog

Chromecasts, Netflix & UI-200

My Chromecast has regularly been refusing to play Netflix streams recently with error ui-200.

Ignoring the onscreen suggestion and initial Netflix support page, a quick search will teach you to factory reset the Chromecast.

It doesn't answer the "Why?" though... It turns out that hitting the "Sign out of all devices" button triggers the issue. I guess the Chromecast stores a token which isn't invalidated or replaced, even if you log in again through the Android app.

Until Netflix/Google fix the bug, it might be time to think about upgrading your Netflix plan or telling "someone" to get their own account!

by Joseph Price ([email protected]) at March 23, 2015 05:59 PM

identifying to the freenode testnet with certfp


freenode will be upgrading their services very soon. One of the major new features that this upgrade will bring is the ability to identify using ssl certificates. Here's a very quick guide on how to get started.

I used atoponce's guide for oftc when writing this up.

You can connect to freenode using ssl without using certfp to identify.

Generating your own certificate

You will need openssl installed. Check your operating systems documentation for this. Once done, the following commands will create a certificate and set sensible permissions:
mkdir -p ~/.irssi/certs
cd .irssi/certs/
openssl req -nodes -newkey rsa:2048 -keyout mynick.key -x509 -days 365 -out mynick.crt
cat mynick.crt mynick.key > mynick.pem
chmod 0400 mynick.key mynick.pem

Needless to say, don't give anyone these files!

Connecting with SSL

The testnet is available at irc://testnet.freenode.net:9003 on ssl so make sure you are connecting to that!

After starting irssi, that means something like:
/network add freenodetest
/server add -auto -ssl -ssl_cert ~/.irssi/certs/mynick.pem -network freenodetest testnet.freenode.net 9003
/save
/connect freenodetest

Or if modifying an existing server config:
use_ssl = "yes";
ssl_verify = "no";
ssl_cert = " ~/.irssi/certs/mynick.pem ";

Once you launch irssi, you should see that you are given usermode +Z:
13:41:49 -!- Mode change [+Z] for user Pricey


If you /whois yourself, you should also see your certificate fingerprint:
14:04:43 -!- Pricey [[email protected]]
14:04:43 -!- ircname : pricechilde
14:04:43 -!- server : barjavel.freenode.net [Paris, FR]
14:04:43 -!- : is using a secure connection
14:04:43 -!- : has client certificate fingerprint aaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbb0000
14:04:43 -!- hostname : 76.10.213.24 76.10.213.24
14:04:43 -!- idle : 0 days 0 hours 0 mins 3 secs [signon: Fri Apr 6 14:04:40 2012]
14:04:43 -!- End of WHOIS

If you don't see the fingerprint line, you need to go back and figure out what you've done wrong.

Giving Services your certificate fingerprint

Finally, we need to tell services about our certificate fingerprint. (If you haven't specified your account password as your server password, sasl'd or had a script take care of it, identify first!)
/msg nickserv cert add aaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbb0000
(using the fingerprint from your whois.)

One final thing of note is that the testnet is using a self signed certificate. You can not simply use the ssl_capath option to point to your distributions existing ssl certificates. Irssi will warn you that this is the case and not connect.

by Joseph Price ([email protected]) at March 23, 2015 05:17 PM

March 20, 2015

RichiH's blog

Release Critical Bug report for Week 12

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1041 (Including 155 bugs affecting key packages)
    • Affecting Jessie: 87 (key packages: 61) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 71 (key packages: 52) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 15 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 1 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 55 bugs are neither tagged patch, nor marked done. (key packages: 40) Help make a first step towards resolution!
      • Affecting Jessie only: 16 (key packages: 9) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 11 bugs are in packages that are unblocked by the release team. (key packages: 5)
        • 5 bugs are in packages that are not unblocked. (key packages: 4)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41) 97 (68+29)
12 release+6 93 (47+46) 87 (71+16)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at March 20, 2015 03:59 PM

March 13, 2015

RichiH's blog

Release Critical Bug report for Week 11

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1053 (Including 152 bugs affecting key packages)
    • Affecting Jessie: 97 (key packages: 63) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 68 (key packages: 50) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 13 bugs are tagged 'patch'. (key packages: 10) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 3 bugs are marked as done, but still affect unstable. (key packages: 1) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 52 bugs are neither tagged patch, nor marked done. (key packages: 39) Help make a first step towards resolution!
      • Affecting Jessie only: 29 (key packages: 13) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 27 bugs are in packages that are unblocked by the release team. (key packages: 13)
        • 2 bugs are in packages that are not unblocked. (key packages: 0)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41) 97 (68+29)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at March 13, 2015 10:02 PM

March 11, 2015

RichiH's blog

100g for deleting

On the assumption that the post titled "Delete file when you have more than 100g for deleting" on the "Linux.com - Content Feed" is not an elaborate joke, it's not unlikely that it will be deleted so I will conserve it here:

Hello Linix community members,

Today I would like to share a simple script for deleting files when you have more than 100g for deleting and when you try to delete using rm -rm /path/fo/files failed.

To do this I use the following procedure;

first I use a "for" ciclo to read file that I going to delete also you can use a mtime for calculate file's date that you're going to delete or you can to calculate previous date of a past day "x=TZ=GMT+24 date +%Y%m%d"

Ex;

#!/bin/bash -x
x=`TZ=GMT+24 date +%Y%m%d`
delcnt=0
for files in `find /path/of/file/to/eraser/ -name \*$x*.bin.gz`
do
echo "Deleting file $files"
/bin/rm -rf $files
delcnt=$(($delcnt + 1))
done

Best regards

Charles E. Rivera

Solaris Server Specialist Engeeneer

But then, Linux.com still aggregates Phoronix, so their focus is not exactly on quality.

by Richard 'RichiH' Hartmann at March 11, 2015 10:17 PM

March 06, 2015

RichiH's blog

Release Critical Bug report for Week 10

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1068 (Including 159 bugs affecting key packages)
    • Affecting Jessie: 112 (key packages: 84) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 82 (key packages: 60) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 14 bugs are tagged 'patch'. (key packages: 10) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 1 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 67 bugs are neither tagged patch, nor marked done. (key packages: 50) Help make a first step towards resolution!
      • Affecting Jessie only: 30 (key packages: 24) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 16 bugs are in packages that are unblocked by the release team. (key packages: 12)
        • 14 bugs are in packages that are not unblocked. (key packages: 12)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48) 112 (82+30)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at March 06, 2015 05:18 PM

erry's blog

Greek article translations: “Greece bullies its children”

Introduction

What is this? This is a new segment that I have no idea how long I’ll keep, if at all. I come from Greece, and you may know that there are certain… not very good things going on there, especially relating to the economy. I believe it’s extremely important for people to understand what’s going on in the country as reported by the simple every day people, instead of the EU, the IMF, etc. There are some intelligent Greek articles available online that talk about and explain these facts, but unfortunately they’re very rarely available in other languages which makes it hard for foreigners to understand our side of the story. This segment will obviously not be of technical nature, so if you want to read something more interesting, you’re welcome to. Theree’s plenty of that.

Today’s article is a worldwide issue, so there are probably many articles about it already in every language of the world. Nevertheless, it’s still an issue that bothers me, and that I want to talk about, and I agree with the greek article, so it’s worth stealing. You can try to read the original article here

World day against bullying: Greece bullies its children

Original by Vasillis Thanopoulos posted on http://www.avmag.gr/av/53563/pagkosmia-imera-kata-tou-bullying-i-ellada-foverizi-ta-pedia-tis/ on March 6th, 2015; Antivirus | HOMOEVOLUTION &Copy 2003-2015

Lately we are becoming spectators of more and more cases of bullying. Young people disappear, mouths remain closed, and educational institutions are transformed into cleustrophobic spaces of punishment and humuliation. How far can we allow this phenomenon to go?

The statistics are shocking. Research done by [a Greek children's charity], “Το Χαμόγελο του Παιδιού”, showed that one in three students of secondary education have become a victim of bullying, while in our country [Greece] is fourth out of six European countries in the amount of cases of bullying, with a percentage of 31.98.

Another study done in 13 Health Centers in Macedonia revealed that one in 20 middle school students are a victim of bullying during their last year of middle school, a percentage that almost doubles in high school.

“Every day that I have to go to school, I’m terrified…”

Bullying is a social phenomenon. Anything that appears to be different from the social norm is alienated. The adults’ stereotypical way of thinking passes on to the children and it’s implemented in a very harsh ways in the societies that they take part in. LGBT individuals have always been victims of this phenomenon.

“I can’t tell anyone…”

Bullying is a timeless phenomenon. We might, in most cases, focus on bullying done in schools, but unfortunately it happens in every age and part of social life. It victimises and creates behaviours that continue and worsen a lot of the time.

The antidote to bullying is education.

Statistics:

42% of educators believe that cases of bullying are kept quiet or underestimated.

Only one in 10 children that are bullied in Greece recieve support.

55% of children in Europe that have been bullied claim that as a result they suffer from depression, with more than a third of the children claiming that they have hurted themselves or thought of commiting suicide.

34% of adults consider bullying a normal part of a child’s development

(End of article)
================

My thoughts

As someone who was bullied in school, I couldn’t agree more with this article. This is a huge problem. We need to learn to accept people who are different because they are the ones who can make a difference to the community and move our species ahead, more than anyone. And unfortunately the fact is that many people don’t take this seriously, or even think that the victims should be able to defend themselves, which is plain wrong. They need support from those around them, but even more importantly, we need to teach our children to be open-minded accepting towards other and not judge or attack them. Which begins from the adults out there: You (and I) need to be open-minded and accepting, and not make judgmental, predujiced and unfair comments around your children or the children of your friends, because this behavior is contagious, like a bad disease.

by Errietta Kostala at March 06, 2015 12:51 PM

February 27, 2015

RichiH's blog

Release Critical Bug report for Week 09

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1072 (Including 181 bugs affecting key packages)
    • Affecting Jessie: 152 (key packages: 117) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 101 (key packages: 80) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 23 bugs are tagged 'patch'. (key packages: 17) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 6 bugs are marked as done, but still affect unstable. (key packages: 4) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 72 bugs are neither tagged patch, nor marked done. (key packages: 59) Help make a first step towards resolution!
      • Affecting Jessie only: 51 (key packages: 37) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 35 bugs are in packages that are unblocked by the release team. (key packages: 27)
        • 16 bugs are in packages that are not unblocked. (key packages: 10)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69) 152 (101+51)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at February 27, 2015 03:40 PM

February 25, 2015

erry's blog

Codeclub: Teaching code in Cumbria

One of the many things I am is a STEM Ambassador. I have talked about this in a previous blog post, but STEM Ambassadors are volunteers that support sessions and run clubs and other activities in schools.

I've been wanting to run a CodeClub for a while. Codeclub a volunteer-led after-school club that aims to teach children to code using Scratch, a visual programming language developed at MIT, and I’m very excited to finally have found an opportunity at a school in a village in Cumbria!

I have only done two sessions so far, but I already find the children very eager to learn, and they learn extremely quickly! There’s definitely much enthusiasm in the air during the sessions, and seeing the children work together and ask each other questions is a great feeling. They also experiment on their own and build things they were not asked to, which may be a bit of a problem when you’re trying to show something, but it’s also a very good thing as experimentation is what makes a great programmer.

I have confidence that by the end of the sessions, the children will have learned many things and hopefully they will keep the interest for years to come and become the next programmers!

I would also like to take the opportunity to thank my employer, Shadowcat Systems, for giving me the ability to do this on company time; this would not be possible otherwise. They are pretty awesome and do a lot of other community work as well, which is very important to me (and I think most of my colleagues as well) at a job :)

by Errietta Kostala at February 25, 2015 05:51 PM

February 23, 2015

RichiH's blog

Accuracy

Even if you disregard how amazing this is, this quote blows my proverbial mind:

The test rig is carefully designed to remove any possible sources of error. Even the lapping of waves in the Gulf of Mexico 25 miles away every three to four seconds would have showed up on the sensors, so the apparatus was floated pneumatically to avoid any influence. The apparatus is completely sealed, with power and signals going through liquid metal contacts to prevent any force being transmitted through cables.

by Richard 'RichiH' Hartmann at February 23, 2015 11:21 PM

February 20, 2015

RichiH's blog

Release Critical Bug report for Week 08

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1069 (Including 188 bugs affecting key packages)
    • Affecting Jessie: 147 (key packages: 114) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 96 (key packages: 81) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 23 bugs are tagged 'patch'. (key packages: 19) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 2 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 71 bugs are neither tagged patch, nor marked done. (key packages: 62) Help make a first step towards resolution!
      • Affecting Jessie only: 51 (key packages: 33) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 34 bugs are in packages that are unblocked by the release team. (key packages: 22)
        • 17 bugs are in packages that are not unblocked. (key packages: 11)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62) 147 (96+51)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at February 20, 2015 07:32 PM

February 18, 2015

RichiH's blog

Listing screen sessions on login

Given Peter Eisentraut's blog post on the same topic, I thought I would also share this Zsh function (from 2011):

startup () {
    # info on any running screens
    if [[ -x $(which screen) ]]
    then
        ZSHRC_SCREENLIST=(${${(M)${(f)"$(screen -ls)"}:#(#s)?:space:##([0-9]##).*}/(#b)?:space:#([0-9]##).*/$match[1]})
        if [[ $#ZSHRC_SCREENLIST -ge 1 ]]
        then
            echo "There are $#ZSHRC_SCREENLIST screens running. $ZSHRC_SCREENLIST"
        fi
    fi
}

by Richard 'RichiH' Hartmann at February 18, 2015 08:32 PM

February 13, 2015

RichiH's blog

DC16.za

Here's to a happy, successful, and overall quite awesome DebConf16 in Cape Town, South Africa.

As a very welcome surprise, the Montreal team is already planning a mini-DC and already have a strong bid for DC17.

Update: Well, that was quick...

by Richard 'RichiH' Hartmann at February 13, 2015 08:59 PM

Release Critical Bug report for Week 07

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1071 (Including 192 bugs affecting key packages)
    • Affecting Jessie: 147 (key packages: 110) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 106 (key packages: 82) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 25 bugs are tagged 'patch'. (key packages: 23) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 4 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 77 bugs are neither tagged patch, nor marked done. (key packages: 59) Help make a first step towards resolution!
      • Affecting Jessie only: 41 (key packages: 28) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 11 bugs are in packages that are unblocked by the release team. (key packages: 6)
        • 30 bugs are in packages that are not unblocked. (key packages: 22)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66) 147 (106+41)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at February 13, 2015 08:16 PM

February 12, 2015

RichiH's blog

A Dance with Dragons

Yesterday, I went to the Federal Office for Information Security (BSI) on an invitation to their "expert round-table on SDN".

While the initial mix of industry attendees was of.. varied technical knowledge.. I was pleasantly surprised by the level of preparation by the BSI. None of them were networkers, but they did have a clear agenda and a pretty good idea of what they wanted to know.

During the first round-table, they went through

  • This is our idea of what we think SDN is
  • Is SDN a fad or here to stay?
  • What does the industry think about SDN?
  • What are the current, future, and potential benefits of SDN?
  • What are the current, future, and potential risks of SDN?
  • How can SDN improve the security of critical infrastructure?
  • How can you ensure that the whole stack from hardware through data plane to control plane can be trusted?
  • How can critical parts of the SDN stack be developed in, or strongly influenced from, players in Germany or at least Europe?

Yes, some of those questions are rather basic and/or generic, but that was on purpose. The mix of clear expectations and open-ended questions was quite effective at getting at what they wanted to know.

During lunch, we touched on the more general topic of how to reach and interact with technical audiences, with regards to both networks and software. The obvious answer for initial contact in regards to networks was DENOG; which they didn't know about.

With software, the answer is not quite as simple. My suggestion was to engage in a positive way and thus build trust over time. Their clear advantage is that, contrary to most other services, their raison d'être is purely defensive and non-military so they can focus on audits, support of key pieces of software, and, most important of all, talk about their results. No idea if they will actually pursue this, but here's to hoping; we could all use more government players on the good side.

by Richard 'RichiH' Hartmann at February 12, 2015 09:51 PM

February 10, 2015

mquin's blog

OpenPGP key transition - 2015-02-10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tue 10 Feb 2015 17:27:10 GMT

For a number of reasons, i've recently set up a new OpenPGP key, and
will be transitioning away from my old one.

The old key will expire shortly and I will prefer all future correspondence to
come to the new one. I would also like this new key to be re-integrated into
the web of trust. This message is signed by both keys to certify the transition.

the old key was:

pub   1024D/45515F0D 2007-03-02
      Key fingerprint = 0959 D8F2 FA5A 72F2 3A38  7061 07E8 A128 4551 5F0D

And the new key is:

pub   4096R/7F2911DC 2015-02-09 [expires: 2017-02-08]
      Key fingerprint = 3E02 CCDA F08C B622 3ED1  C7E6 234B 7D09 7F29 11DC

To fetch my new key from a public key server, you can simply do:

  gpg --keyserver pool.sks-keyservers.net --recv-key 0x234B7D097F2911DC

If you already know my old key, you can now verify that the new key is
signed by the old one:

  gpg --check-sigs 0x7F2911DC

If you don't already know my old key, or you just want to double check, 
you can verify the fingerprint against the one above:

  gpg --fingerprint 0x7F2911DC

If you are satisfied that you've got the right key, the UIDs match what you
expect, and if it's compatible with your key signing policy, I'd appreciate it
if you would sign my key:

  gpg --sign-key 0x7F2911DC

Lastly, if you could upload these signatures, i would appreciate it.
You can either send me an e-mail with the new signatures (if you have
a functional MTA on your system):

  gpg --armor --export 0x7F2911DC | mail -s 'OpenPGP Signatures' [email protected]

Or you can just upload the signatures to a public keyserver directly:

  gpg --keyserver pool.sks-keyservers.net --send-key 0x7F2911DC

Please let me know if there is any trouble, and sorry for the
inconvenience.

Regards,

Mike Quin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJU2j/KAAoJEOVxLEk15iMBF7kIAIzGJiinV8TrtGBB3Y2bpPfY
WfWfTOMCyP5BB5BgK56yixSOIjl5xaIPZKtMKq3ZIzPY3JRoB9mNN+8Jwb2jsLLU
+RRzvL/Y3lmmnAdglUfuwBt5pl2yGDOS8kO8fFwuUa5dka6P7wJzcAol2pwdDf2d
ZX8jT4VenSu3mI7JGzCEV3KNv2k2C/TxcqqIqCLsLOcxSXdZco/FaQoc8WJz6NzV
xIT4IX8cWMYku6vcYH/gBRZIFhnU2m7iqVY99mVThqk49mLhNUG3MVxMfldnHA6X
e6E3SrqUU0/uX6L5EICbPlC/s/UNJg/w4RDUOSAFGWwbUlrARjVT1xPvwCdHWC6J
AhwEAQEKAAYFAlTaP8oACgkQUdpxoEzgI0UXuQ/9Fil2vrAk2mOPWHbe2DJA/cwY
TVbILExG4xFdm1QEdR2GqyobzsIOCZxVSW3mEBHlc5UZBsDWGZX10RVy3QHW8exM
1f6TO+rWvpN7fmka4mQJxm5ijTjBEFM7RHI7xmQ0b3qShkb9zKGJpkisZ3hNEMIT
AzNHuE8bSjs6nUtZy2IoKRd0wYMTb+DWtOfRtdz2uClK6pT0jjgUFoZDyLooWLuC
sHVmDUBFwSrv6PWmuO4WiWtTS92yQtUVhrz8bd7YIxquKJ9yUdAe0mEOjGnjK3f5
9L0fWwraHjwDWVGRXUUVz+jxZ96aBkYBCRbQY8aLTDek88sEz8/VilnxPHHKVx3S
KBlQ3vJGaUaDVcrqE2rBlj7DrK1cXFq5upk2ZCy/JeAi671993LIc/8kF2fUfv75
fzVdVIy8EUKf9CWR5FcS4QSdB6Sc29I6BNgQgsTWNjO3+7pf9l2wIXnfeJ0UM/Yt
vXI/nhAluco5P2d0bjP3DvXLSgv7xJKNQOjbRqPYnmVR7UkonIRtTX8ZqE7fSZZZ
Lpozv3FjjbKCZMPKbs6eERvVQa9lkNWKIuhOL9fssWx0/iH82ZXhckSwakV528Yi
P9SzgwEfODHz2+qIeHKPOL7xWFQwhrG0UOmfUcxWkJXrtaIRQkRyZMAUC7eKykHY
hj03k21i3VI5IybqCFg=
=wsZh
-----END PGP SIGNATURE-----

February 10, 2015 05:31 PM

February 07, 2015

RichiH's blog

Release Critical Bug report for Week 06

Belated post due to meh real life situations.

As you may have heard, if a package is removed from testing now, it will not be able to make it back into Jessie. Also, a lot of packages are about to be reoved for being buggy. If those are gone, they are gone.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1066 (Including 187 bugs affecting key packages)
    • Affecting Jessie: 161 (key packages: 123) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 109 (key packages: 90) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 25 bugs are tagged 'patch'. (key packages: 23) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 6 bugs are marked as done, but still affect unstable. (key packages: 5) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 78 bugs are neither tagged patch, nor marked done. (key packages: 62) Help make a first step towards resolution!
      • Affecting Jessie only: 52 (key packages: 33) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 19 bugs are in packages that are unblocked by the release team. (key packages: 14)
        • 33 bugs are in packages that are not unblocked. (key packages: 19)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83) 161 (109+52)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at February 07, 2015 02:44 AM

January 30, 2015

RichiH's blog

Release Critical Bug report for Week 05

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1083 (Including 186 bugs affecting key packages)
    • Affecting Jessie: 175 (key packages: 122) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 124 (key packages: 89) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 21 bugs are tagged 'patch'. (key packages: 13) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 8 bugs are marked as done, but still affect unstable. (key packages: 6) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 95 bugs are neither tagged patch, nor marked done. (key packages: 70) Help make a first step towards resolution!
      • Affecting Jessie only: 51 (key packages: 33) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 30 bugs are in packages that are unblocked by the release team. (key packages: 18)
        • 21 bugs are in packages that are not unblocked. (key packages: 15)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92) 175 (124+51)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at January 30, 2015 08:57 PM

January 25, 2015

RichiH's blog

KDE battery monitor

Dear lazyweb,

using a ThinkPad X1 Carbon with Debian unstable and KDE 4.14.2, I have not had battery warnings for a few weeks, now.

The battery status can be read out via acpi -V as well as via the KDE widget. Hibernation via systemctl hibernate works as well.

What does not work is the warning when my battery is low, or automagic hibernation when shutting the lid or when the battery level is critical.

From what I gather, something in the communication between upower and KDE broke down, but I can't find what it is. I have also been told that Cinnamon is affected as well, so this seems to be a more general problem

Sadly, me and anyone else who's affected has been unable to fix this.

So, dear lazyweb, please help.

In loosely related news, this old status is still valid. UMTS is stable-ish now but even though I saved the SIM's PIN, KDE always displays a "SIM PIN unlock request" prompt after booting or hibernating. Once I enter that PIN, systemd tells me that a system policy prevents the change and wants my user password. If anyone knows how to get rid of that, I would also appreciate any pointers.

by Richard 'RichiH' Hartmann at January 25, 2015 09:11 PM

January 24, 2015

erry's blog

Fun(d)-raising out in the bay

So I went fundraising today for the first time with people from LGB&T Out In The Bay. They’re a charity group in Lancaster and Morecambe that run coffee afternoons (I’ve been to one or two :P), support groups, advice, etc. for LGBT people. Of course, I find their work and services they offer to people who need them quite important.

We basically offered to pack people’s bags at checkout in Sainsbury’s superstore Morecambe, and hope they give us money. (Most of you did, thank you!)

I was really shy at first, and a bit worried that certain people would lynch us, but I quickly gained confidence, and started not even caring if people attacked me (which nobody did, I was just paranoid :)) which was another awesome first-time feeling!

It was alright, but pretty tiring – I need to get some beauty sleep and then go back to a certain agenda. Overall a fun and good experience though :)

by Errietta Kostala at January 24, 2015 05:14 PM

January 23, 2015

RichiH's blog

Release Critical Bug report for Week 04

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1117 (Including 191 bugs affecting key packages)
    • Affecting Jessie: 187 (key packages: 116) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 132 (key packages: 89) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 24 bugs are tagged 'patch'. (key packages: 15) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 4 bugs are marked as done, but still affect unstable. (key packages: 3) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 104 bugs are neither tagged patch, nor marked done. (key packages: 71) Help make a first step towards resolution!
      • Affecting Jessie only: 55 (key packages: 27) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 25 bugs are in packages that are unblocked by the release team. (key packages: 8)
        • 30 bugs are in packages that are not unblocked. (key packages: 19)

>How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68) 187 (132+55)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at January 23, 2015 05:59 PM

January 18, 2015

erry's blog

Backing up/restoring a LUKS encrypted partition with clonezilla

I recently wanted to back up my LUKS-encrypted disk. However, clonezilla only offered the ability to clone with dd, rather than the faster partclone tool, which is understandable. It is, however, possible to clone the (decrypted) underlying extfs filesystem.
Note: if you make a backup of your decrypted data, it is as bad as if you’ve never encrypted it. Take good care of your backup and, for extra security, destroy it after you have restored it.

The first thing you need to do when you load Clonezilla, is to select “drop to shell” rather than running the normal clonezilla UI. You should now be in a root shell.

Map the device as you normally would (supposing your LUKS partition is /dev/sda5):

cryptsetup luksOpen /dev/sda5 crypt

You should now load some kernel modules:

modprobe dm-mod
vgchange -ay

You should now have /dev/mapper/yourdevice-vg–root or similar.
You can use the partclone tool now.

To back up:

partclone.ext4 -c -s /dev/mapper/yourdevice-vg--root -o /mnt/path-to-backup-disk/backup/image.img

This will clone the decrypted ext4 filesystem and save it to /mnt/path-to-backup-disk.

To restore:

partclone.ext4 -r -s /mnt/path-to-backup-disk/backup/image.img -o /dev/mapper/yourdevice-vg--root

Easier than you’d think! Once again, be extra careful with your backups, for without the encryption, your data will be compromised if they fall to the wrong hands.

by Errietta Kostala at January 18, 2015 05:53 PM

January 16, 2015

RichiH's blog

Release Critical Bug report for Week 03

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1100 (Including 178 bugs affecting key packages)
    • Affecting Jessie: 172 (key packages: 104) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 128 (key packages: 80) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 19 bugs are tagged 'patch'. (key packages: 10) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 8 bugs are marked as done, but still affect unstable. (key packages: 5) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 101 bugs are neither tagged patch, nor marked done. (key packages: 65) Help make a first step towards resolution!
      • Affecting Jessie only: 44 (key packages: 24) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 18 bugs are in packages that are unblocked by the release team. (key packages: 7)
        • 26 bugs are in packages that are not unblocked. (key packages: 17)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84) 172 (128+44)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at January 16, 2015 04:21 PM

January 09, 2015

RichiH's blog

Release Critical Bug report for Week 02

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1090 (Including 177 bugs affecting key packages)
    • Affecting Jessie: 157 (key packages: 92) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 124 (key packages: 74) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 19 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 4 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 101 bugs are neither tagged patch, nor marked done. (key packages: 62) Help make a first step towards resolution!
      • Affecting Jessie only: 33 (key packages: 18) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 16 bugs are in packages that are unblocked by the release team. (key packages: 7)
        • 17 bugs are in packages that are not unblocked. (key packages: 11)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109) 157 (124+33)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at January 09, 2015 05:09 PM

January 02, 2015

RichiH's blog

Release Critical Bug report for Week 01

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1068 (Including 166 bugs affecting key packages)
    • Affecting Jessie: 140 (key packages: 90) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 104 (key packages: 65) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 19 bugs are tagged 'patch'. (key packages: 9) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 3 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 82 bugs are neither tagged patch, nor marked done. (key packages: 56) Help make a first step towards resolution!
      • Affecting Jessie only: 36 (key packages: 25) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 17 bugs are in packages that are unblocked by the release team. (key packages: 11)
        • 19 bugs are in packages that are not unblocked. (key packages: 14)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 (112+35)
1 93 (60+33) 287 (171+116) 140 (104+36)
2 82 (46+36) 271 (162+109)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at January 02, 2015 01:39 PM

December 30, 2014

erry's blog

Hacking on FirefoxOS’s music app.

If you're not aware, Mozilla, the non-profit behind Firefox, has their own smartphone and mobile Operating System, FirefoxOS. I got one of the phones at Mozfest, and ever since, I've been wanting to hack it to make it work exactly the way I want it. It's open source, and all its apps are written in technologies I'm familiar with, like JavaScript and HTML5, which makes that possible!

It's pretty neat, but certain things could use improvement – for example its music app doesn't support user-defined playlists yet. I thought (and I think I was right!) that it would be a big challenge, but a good and achievable one.

Of course, I had never hacked on this app before, so I spent a considerable amount of time reading and following the source code and trying to figure out how everything worked… which was a bit of a headache, but in time I sort of got the hang of it!

Figuring out how an app you've never looked at before works is sort of like a puzzle: you need to put the pieces together at least until you have some idea what the picture looks like. Understanding how the various views pass data to each other, how they talk to the database, and how events are passed to them.

Another thing that was interesting (and very valuable) to play with was IndexedDB. It's the first object-oriented database I've used so it was difficult to adjust to at first. However, I'm learning a bit about it thanks to this project, which is awesome!

So far, I have been able to make the app ask for a playlist name when you long press a song:

playlist-add.png

And then your custom playlists appear on the bottom of the playlists list – not very pretty at the moment, but I'm working on that part!

playlist-list.png

In closing, it just goes to show once more how much you can learn by spending some time on an open source project. Being able to hack my phone's core apps and improve them or change them to my liking is also really amazing! I hope I'll be able to finish the playlist feature and do more awesome things in the future.

by Errietta Kostala at December 30, 2014 10:44 PM

December 27, 2014

RichiH's blog

Release Critical Bug report for Week 52

Sadly, I am a day late.

This post brought to you by download speeds of ~2-9kb/s and upload speeds of 1 kb/s.

Even though I am only a few kilometers away from Munich, I have worse Internet connection here than I had in the middle of nowhere in Finland

Also, the bug count jumped up by about 40 between Thursday and today. Else, we would have been ahead of squeeze.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1088 (Including 171 bugs affecting key packages)
    • Affecting Jessie: 147 (key packages: 95) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 112 (key packages: 72) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 24 bugs are tagged 'patch'. (key packages: 16) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 7 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 81 bugs are neither tagged patch, nor marked done. (key packages: 56) Help make a first step towards resolution!
      • Affecting Jessie only: 35 (key packages: 23) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 21 bugs are in packages that are unblocked by the release team. (key packages: 14)
        • 14 bugs are in packages that are not unblocked. (key packages: 9)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99) 147 ((112+35))
1 93 (60+33) 287 (171+116)
2 82 (46+36) 271 (162+109)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at December 27, 2014 08:29 AM

December 19, 2014

RichiH's blog

Release Critical Bug report for Week 51

Real life has been interesting as of late; as you can see, I didn't post bug stats last week. If you have specific data from last Friday, please let me know and I will update.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1095 (Including 179 bugs affecting key packages)
    • Affecting Jessie: 189 (key packages: 117) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 134 (key packages: 90) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 32 bugs are tagged 'patch'. (key packages: 24) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 13 bugs are marked as done, but still affect unstable. (key packages: 9) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 89 bugs are neither tagged patch, nor marked done. (key packages: 57) Help make a first step towards resolution!
      • Affecting Jessie only: 55 (key packages: 27) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 29 bugs are in packages that are unblocked by the release team. (key packages: 11)
        • 26 bugs are in packages that are not unblocked. (key packages: 16)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144) ???
51 178 (124+54) 323 (190+133) 189 (134+55)
52 115 (78+37) 289 (190+99)
1 93 (60+33) 287 (171+116)
2 82 (46+36) 271 (162+109)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at December 19, 2014 04:25 PM

December 05, 2014

RichiH's blog

Release Critical Bug report for Week 49

Look at that bug count!

At that pace, Jessy will happen before FOSDEM ;)

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1101 (Including 169 bugs affecting key packages)
    • Affecting Jessie: 226 (key packages: 119) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 147 (key packages: 85) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 28 bugs are tagged 'patch'. (key packages: 22) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 10 bugs are marked as done, but still affect unstable. (key packages: 6) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 109 bugs are neither tagged patch, nor marked done. (key packages: 57) Help make a first step towards resolution!
      • Affecting Jessie only: 79 (key packages: 34) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 54 bugs are in packages that are unblocked by the release team. (key packages: 18)
        • 25 bugs are in packages that are not unblocked. (key packages: 16)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155) 226 (147+79)
50 204 (148+56) 339 (195+144)
51 178 (124+54) 323 (190+133)
52 115 (78+37) 289 (190+99)
1 93 (60+33) 287 (171+116)
2 82 (46+36) 271 (162+109)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at December 05, 2014 08:24 PM

December 02, 2014

RichiH's blog

Tabletop games

Wood. I really like wood. Even more, I like working with wood.

Touching it, following its grain, and contemplating that it was made mostly from thin air and water.

Normally, I just turn trees into handy pieces of firewood. While that's already deeply satisfying in the sense that you actually get to see what you worked for, it's a mostly destructive task. You kill a tree, you chop it up, only to turn it back into (mostly) thin air.

As chance would have it, I needed a new table. After dragging myself through way too many furniture stores, I realized that I wouldn't be happy with what's on offer. So I struck a deal with a local carpenter: I would buy from them, but only if I could help building my own table; I would finally create something larger than a carving from wood.

After some scouting, the carpenter found five planks of oak which were 4+ meter long, about 40-60 cm wide, and 8+ cm thick:

Five raw planks of oak

If you think this wood looks old, worn, and broken: You should have seen it up close; it was worse than on the potato-cam picture ;) But that's another great thing about working with wood: by taking off a laughably thin layer of surface material, you can renew the whole thing.

We cut off 10 cm from each side as that's what tends to split and tossed that away. Afterwards, we cut off 80 cm from the wider side for the legs. Again, the base tends to have more imperfections and as you don't need to cut long pieces, you have more freedom in deciding how to cut.

Cutting is an art in itself; tiny imperfections in the wood's surface can hint at large fissures underneath. The fact that the wood looks worn and spotty does not help in figuring this out. After cutting to minimize waste, you end up with a pile like this:

Planks after cutting

And a surprising amount of waste, i.e. firewood:

Leftovers

After a lot of planing, the wood becomes cleaner and smoother:

Planed planks

Then, everything's fitted so that neighbouring planks have their heartwood running into different directions, and so that the upper surface gets (most of) the interesting features. This is another surprisingly involved process and took about two hours.

And no, the potato-cam does not manage to capture the wood's beauty.

Set planks

After sanding the sides down to perfection to ensure the glue can bond really tightly, the table feet are glued and put into a hydraulic press:

Table feet about to be pressed

while the tabletop itself shines in all its 287 cm x 107 cm x 6.3 cm glory:

Tabletop set and glued

Tomorrow, we will sand down the top and bottom of the tabletop and prepare the feet. Grooves will be milled into the wood to glue steel bars into it, as well as another plank that will be glued to the bottom of the tabletop, running along the middle. Along with the alternating heartwood, this helps ensure that this beast of a table will not fold in on itself or otherwise succumb to internal torsion or gravity.

The final steps will be to fit the feet, sand down the surface again and then apply two layers of oil.

And while most people may not fancy taking a week off just to rise way too early and then do unpaid work, I love it.

As I said: I like wood.

by Richard 'RichiH' Hartmann at December 02, 2014 10:36 PM

November 28, 2014

RichiH's blog

Release Critical Bug report for Week 48

Holy bug-count-drop, Batman!

Some bugs which need loving:

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1143 (Including 186 bugs affecting key packages)
    • Affecting Jessie: 274 (key packages: 131) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 189 (key packages: 99) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 46 bugs are tagged 'patch'. (key packages: 27) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 11 bugs are marked as done, but still affect unstable. (key packages: 5) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 132 bugs are neither tagged patch, nor marked done. (key packages: 67) Help make a first step towards resolution!
      • Affecting Jessie only: 85 (key packages: 32) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 59 bugs are in packages that are unblocked by the release team. (key packages: 18)
        • 26 bugs are in packages that are not unblocked. (key packages: 14)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148) 274 (189+85)
49 256 (180+76) 360 (216+155)
50 204 (148+56) 339 (195+144)
51 178 (124+54) 323 (190+133)
52 115 (78+37) 289 (190+99)
1 93 (60+33) 287 (171+116)
2 82 (46+36) 271 (162+109)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at November 28, 2014 08:16 PM

November 21, 2014

RichiH's blog

Release Critical Bug report for Week 47

There's a BSP this weekend. If you're interested in remote participation, please join #debian-muc on irc.oftc.net.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1213 (Including 210 bugs affecting key packages)
    • Affecting Jessie: 342 (key packages: 152) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 260 (key packages: 119) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 37 bugs are tagged 'patch'. (key packages: 20) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 12 bugs are marked as done, but still affect unstable. (key packages: 3) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 211 bugs are neither tagged patch, nor marked done. (key packages: 96) Help make a first step towards resolution!
      • Affecting Jessie only: 82 (key packages: 33) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 65 bugs are in packages that are unblocked by the release team. (key packages: 26)
        • 17 bugs are in packages that are not unblocked. (key packages: 7)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Jessie
43 284 (213+71) 468 (332+136) 319 (240+79)
44 261 (201+60) 408 (265+143) 274 (224+50)
45 261 (205+56) 425 (291+134) 295 (229+66)
46 271 (200+71) 401 (258+143) 427 (313+114)
47 283 (209+74) 366 (221+145) 342 (260+82)
48 256 (177+79) 378 (230+148)
49 256 (180+76) 360 (216+155)
50 204 (148+56) 339 (195+144)
51 178 (124+54) 323 (190+133)
52 115 (78+37) 289 (190+99)
1 93 (60+33) 287 (171+116)
2 82 (46+36) 271 (162+109)
3 25 (15+10) 249 (165+84)
4 14 (8+6) 244 (176+68)
5 2 (0+2) 224 (132+92)
6 release! 212 (129+83)
7 release+1 194 (128+66)
8 release+2 206 (144+62)
9 release+3 174 (105+69)
10 release+4 120 (72+48)
11 release+5 115 (74+41)
12 release+6 93 (47+46)
13 release+7 50 (24+26)
14 release+8 51 (32+19)
15 release+9 39 (32+7)
16 release+10 20 (12+8)
17 release+11 24 (19+5)
18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at November 21, 2014 08:31 PM

November 14, 2014

RichiH's blog

Release Critical Bug report for Week 46

I know I promised better stats, but meh... Next week :(

As you can see, there's been a bit of a mass-filing going on. and that pushed ys above Wheezy's count for week 46.

My own personal favourite bug is, of course, this one.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1263 (Including 218 bugs affecting key packages)
    • Affecting Jessie: 427 (key packages: 175) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 313 (key packages: 131) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 33 bugs are tagged 'patch'. (key packages: 15) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 12 bugs are marked as done, but still affect unstable. (key packages: 6) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 268 bugs are neither tagged patch, nor marked done. (key packages: 110) Help make a first step towards resolution!
      • Affecting Jessie only: 114 (key packages: 44) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 82 bugs are in packages that are unblocked by the release team. (key packages: 32)
        • 32 bugs are in packages that are not unblocked. (key packages: 12)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff
43 284 (213+71) 468 (332+136) +184 (+119/+65)
44 261 (201+60) 408 (265+143) +147 (+64/+83)
45 261 (205+56) 425 (291+134) +164 (+86/+78)
46 271 (200+71) 401 (258+143) +130 (+58/+72)
47 283 (209+74) 366 (221+145) +83 (+12/+71)
48 256 (177+79) 378 (230+148) +122 (+53/+69)
49 256 (180+76) 360 (216+155) +104 (+36/+79)
50 204 (148+56) 339 (195+144) +135 (+47/+90)
51 178 (124+54) 323 (190+133) +145 (+66/+79)
52 115 (78+37) 289 (190+99) +174 (+112/+62)
1 93 (60+33) 287 (171+116) +194 (+111/+83)
2 82 (46+36) 271 (162+109) +189 (+116/+73)
3 25 (15+10) 249 (165+84) +224 (+150/+74)
4 14 (8+6) 244 (176+68) +230 (+168/+62)
5 2 (0+2) 224 (132+92) +222 (+132/+90)
6 release! 212 (129+83) +212 (+129/+83)
7 release+1 194 (128+66) +194 (+128/+66)
8 release+2 206 (144+62) +206 (+144/+62)
9 release+3 174 (105+69) +174 (+105/+69)
10 release+4 120 (72+48) +120 (+72/+48)
11 release+5 115 (74+41) +115 (+74/+41)
12 release+6 93 (47+46) +93 (+47/+46)
13 release+7 50 (24+26) +50 (+24/+26)
14 release+8 51 (32+19) +51 (+32/+19)
15 release+9 39 (32+7) +39 (+32/+7)
16 release+10 20 (12+8) +20 (+12/+8)
17 release+11 24 (19+5) +24 (+19/+5)
18 release+12 2 (2+0) +2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at November 14, 2014 04:34 PM

November 11, 2014

RichiH's blog

One pot noodles

I had prepared a long and somewhat emotional blog post called "On unintended consequences" to write a rather sad bit of news off of my heart. While I believe the points raised were logical, courteous, and overall positive, I decided to do something different and replace sad things with happy things.

So anyway, for 3-4 people you will need:

  • The largest, widest cooking pot you can find (you want surface to let more water evaporate)
  • 500g noodles, preferably Bavette
  • 300g cherry tomatoes
  • ~150g sundried tomatoes
  • ~150g grilled peppers
  • a handful of olives
  • two medium-sized red onions
  • as much garlic as is socially acceptable in your group
  • one or two handful of fresh basil leaves
  • large gulp of olive oil
  • ~100g fresh-ground Parmesan
  • salt, to taste
  • random source of capsaicin, to taste
  • water

Proceed to the cooky part of the evening:

  • Slice and cut all vegetables into sizes of your preference; personally, I like to stay on the chunky side, but do whatever you feel like.
  • Pour the olive oil into the pot; optionally add oil from your sundried tomatoes and/or grilled peppers in case those came in oil.
  • Put the pot onto high heat and toss the chopped vegetables in as soon as it starts heating up.
  • Stir for maybe a minute, then add a bit of water.
  • Toss in the noodles and add just enough water to cover everything.
  • Now is a good time to add salt and capsaicin, to taste.
  • Cook everything down on medium to high heat while stirring and scraping the bottom of the pot so nothing burns. You want to get as much water out of the mix as possible.
  • Towards the end, maybe a minute before the noodles are al dente, wash the basil leaves and rip them into small pieces.
  • Turn off the heat, add all basil and cheese, stir a few times, and serve.

If you don't have any of those ingredients on hand and/or want to add something else: Just do so. This is not an exact science and it will taste wonderful any way you make it.

by Richard 'RichiH' Hartmann at November 11, 2014 08:57 PM

freenode staffblog

Helping GNOME defend its trademark

The GNOME project will be familiar to the vast majority of our users, what you might not be aware of is that the project is currently facing an expensive trademark battle against Groupon with the latter having allegedly chosen to infringe upon GNOME’s trademark by launching a product with the same name (a POS “operating system for merchants to run their entire operation”).

I am not going to go into the details here, as they have been explained by the GNOME project over at http://www.gnome.org/groupon/ and the GNOME folk are in a much better position than me to provide more detailed information on the matter.

What I am going to do is appeal for your help. The GNOME project is looking to raise $80,000 to cover the legal costs involved in defending their trademark. At the time of writing this post the freenode network has 89,998 connected users. Users who are passionate about FOSS.

If each of us donated just ONE DOLLAR to the GNOME project they would cover the anticipated legal costs AND have some spare change leftover for a pint when the proceedings conclude.

Even if you do not use GNOME, please consider helping them out. This is bigger than just GNOME and I think would be fantastic if the FOSS communities could drum together to support our own.

If you head over to http://www.gnome.org/groupon/ you can make a donation directly via PayPal by clicking on the “Help us by donating today” button.

Update: Due to the controversial nature of PayPal, GNOME is now also offering other ways to donate .

Thank you!

Update #2: According to the Groupon blog and this article over at Engadget Groupon has issued the following statement: “Groupon is a strong and consistent supporter of the open source community, and our developers are active contributors to a number of open source projects. We’ve been communicating with the Foundation for months to try to come to a mutually satisfactory resolution, including alternative branding options, and we’re happy to continue those conversations. Our relationship with the open source community is more important to us than a product name. And if we can’t come up with a mutually acceptable solution, we’ll be glad to look for another name.”

I am assuming that this means that the trademarks filed will be retracted and that the GNOME project can go about business as usual. I am certain they will be releasing a statement with further details before long.

by christel at November 11, 2014 06:57 PM

November 09, 2014

freenode staffblog

Atheme 7.2 and freenode

Hello!

We’ve begun some testing on Atheme’s latest release, 7.2, and we’d like to invite interested users to help with that.

Not all changes the Atheme project has included in their new release will be included in our Atheme upgrade, so here’s the bulk of the changes that will actually affect our network:

  • /msg NickServ DROP will require confirmations from the user similar
    to the ChanServ variant. This is to prevent people DROPping when they
    should be GHOSTing or similar.
  •  We’ve loaded two exttargets:
    • $registered to grant flags to all people who are identified to
      NickServ
    • $chanacs to grant flags to people who have flags in another
      channel. Please read /msg ChanServ HELP FLAGS for details on how they work.
  • The SASL mechanism DH-BLOWFISH has been removed. People using it
    can connect via SSL and use PLAIN or upgrade to ECDSA-NIST256P-CHALLENGE.
    Details of how to do so are here and our SASL page will be updated with the relevant documentation soonish.

You should be able to connect to testnet at testnet.freenode.net Port 9002 for cleartext, and 9003 for SSL. Bear in mind, the database is a couple weeks old, so changes you’ve recently made on the production network may not be mirrored on the testnet network. Various amounts of staff should be idling in #freenode on testnet at all times, please feel free to poke us with any questions.

Thanks!

 

by tomaw at November 09, 2014 12:56 AM

November 07, 2014

RichiH's blog

Release Critical Bug report for Week 45

WE ARE FROZEN!

Please note that Lucas hacked a "key packages" count into this list. If you have spare cycles, look at those first.

I hope to have a (somewhat) random bug of the week thingie by next week which picks stalled bugs for increased exposure.

As you can see, we are a bit worse than in the Squeeze cycle, but way ahead of Wheezy. Stats with proper diffs will also start next week.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1154 (Including 190 bugs affecting key packages)
    • Affecting Jessie: 295 (key packages: 150) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 229 (key packages: 116) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 22 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 14 bugs are marked as done, but still affect unstable. (key packages: 8) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 193 bugs are neither tagged patch, nor marked done. (key packages: 96) Help make a first step towards resolution!
      • Affecting Jessie only: 66 (key packages: 34) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 37 bugs are in packages that are unblocked by the release team. (key packages: 24)
        • 29 bugs are in packages that are not unblocked. (key packages: 10)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff
43 284 (213+71) 468 (332+136) +184 (+119/+65)
44 261 (201+60) 408 (265+143) +147 (+64/+83)
45 261 (205+56) 425 (291+134) +164 (+86/+78)
46 271 (200+71) 401 (258+143) +130 (+58/+72)
47 283 (209+74) 366 (221+145) +83 (+12/+71)
48 256 (177+79) 378 (230+148) +122 (+53/+69)
49 256 (180+76) 360 (216+155) +104 (+36/+79)
50 204 (148+56) 339 (195+144) +135 (+47/+90)
51 178 (124+54) 323 (190+133) +145 (+66/+79)
52 115 (78+37) 289 (190+99) +174 (+112/+62)
1 93 (60+33) 287 (171+116) +194 (+111/+83)
2 82 (46+36) 271 (162+109) +189 (+116/+73)
3 25 (15+10) 249 (165+84) +224 (+150/+74)
4 14 (8+6) 244 (176+68) +230 (+168/+62)
5 2 (0+2) 224 (132+92) +222 (+132/+90)
6 release! 212 (129+83) +212 (+129/+83)
7 release+1 194 (128+66) +194 (+128/+66)
8 release+2 206 (144+62) +206 (+144/+62)
9 release+3 174 (105+69) +174 (+105/+69)
10 release+4 120 (72+48) +120 (+72/+48)
11 release+5 115 (74+41) +115 (+74/+41)
12 release+6 93 (47+46) +93 (+47/+46)
13 release+7 50 (24+26) +50 (+24/+26)
14 release+8 51 (32+19) +51 (+32/+19)
15 release+9 39 (32+7) +39 (+32/+7)
16 release+10 20 (12+8) +20 (+12/+8)
17 release+11 24 (19+5) +24 (+19/+5)
18 release+12 2 (2+0) +2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at November 07, 2014 05:28 PM

November 04, 2014

Md's blog

My position on the "init system coupling" General Resolution

I first want to clarify for the people not intimately involved with Debian that the GR-2014-003 vote is not about choosing the default init system or deciding if sysvinit should still be supported: its outcome will not stop systemd from being Debian's default init system and will not prevent any interested developers from supporting sysvinit.

Some non-developers have recently threatened of "forking Debian" if this GR will not pass, apparently without understanding well the concept: Debian welcomes forks and I think that having more users working on free software would be great no matter which init system they favour.

The goal of Ian Jackson's proposal is to force the maintainers who want to use the superior features of systemd in their packages to spend their time on making them work with sysvinit as well. This is antisocial and also hard to reconcile it with the Debian Constitution, which states:

2.1.1 Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. [...]

As it has been patiently explained by many other people, this proposal is unrealistic: if the maintainers of some packages were not interested in working on support for sysvinit and nobody else submitted patches then we would probably still have to release them as is even if formally declared unsuitable for a release. On the other hand, if somebody is interested in working on sysvinit support then there is no need for a GR forcing them to do it.

The most elegant outcome of this GR would be a victory of choice 4 ("please do not waste everybody's time with pointless general resolutions"), but Ian Jackson has been clear enough in explaining how he sees the future of this debate:

If my GR passes we will only have to have this conversation if those who are outvoted do not respect the project's collective decision.

If my GR fails I expect a series of bitter rearguard battles over individual systemd dependencies.

There are no significant practical differences between choices 2 "support alternative init systems as much as possible" and 3 "packages may require specific init systems if maintainers decide", but choice 3 is more explicit in supporting the technical decisions of maintainers and upstream developers.

This is why I think that we need a stronger outcome to prevent discussing this over and over, no matter how each one of us feels about working personally on sysvinit support in the future. I will vote for choices 3, 2, 4, 1.

November 04, 2014 06:36 PM

October 31, 2014

RichiH's blog

Release Critical Bug report for Week 44

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1168
    • Affecting Jessie: 274 That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 224 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 30 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 12 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
        • 182 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
      • Affecting Jessie only: 50 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 2 bugs are in packages that are unblocked by the release team.
        • 48 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

by Richard 'RichiH' Hartmann at October 31, 2014 11:37 PM

October 29, 2014

freenode staffblog

User-enabled sendpass

As a network, we feel it is hugely important to maintain close relationships with our many communities and users. Our interactions with users in #freenode and elsewhere on the network, fielding support requests and assisting users, help build and maintain these relationships.

But we’re constantly looking for things to change and make better, and one of the pieces of feedback we’ve had is that users would like a little automation – and the ability to be able to resolve some of their own support requests.

We recognise that allowing users to generate their own password reset e-mails brings us in line with other registration systems online and may provide a higher quality of service.

So for now, if you are having difficulties accessing your account, you can generate your own password reset e-mail using the following command:

/msg NickServ SENDPASS <account>

This command will only work with an offline account (i.e. it won’t work if a client is logged into your account via NickServ), and should obviously only be used on an account that you believe is yours.

We will be keeping an eye on how this feature is used, and may retain it permanently if it proves to be helpful and non-harmful!

by njan at October 29, 2014 09:39 PM

October 24, 2014

RichiH's blog

Release Critical Bug report for Week 43

Just a friendly reminder: If your package is not in unstable (and reasonably bug free) by Sunday, it's not in Jessie.

I am not doing full stats as I am unsure about the diff format at the moment, but in week 43, we had 284 bugs for Squeeze and 468 for Wheezy.

(282 + 468) / 2 = 376; so we are a bit better off than on average. Still, here's to hoping this freeze will be shorter.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1193
    • Affecting Jessie: 319 That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 240 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 20 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 22 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
        • 198 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
      • Affecting Jessie only: 79 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 0 bugs are in packages that are unblocked by the release team.
        • 79 bugs are in packages that are not unblocked.

by Richard &#x27;RichiH&#x27; Hartmann at October 24, 2014 07:52 PM

October 19, 2014

erry's blog

Supporting an openhatch session

About a week ago, I heard that the socialcoding4good community manager Emma Irwin was running an OpenHatch session at the University of Victoria (in Canada!) OpenHatch sessions are meant to help students get started in contributing to Open Source software. Emma was also going to show them how to contribute to one of my favourite projects, Webmaker, and since I like the project and I have a lot of fun helping new contributors get started to it in general, I did the only reasonable thing and decided to help out… Remotely!

The session

Apart from helping students fix webmaker bugs, the other thing that was particularly interesting to me in the session schedule was a briefing on using IRC. Since I'm running a Mozfest session about the subject soon (!), I thought it would be great practice, so I decided to speak about IRC myself

Working from home

Technology made giving the talk remotely remarkably easy, and there weren't many surprises!
I started by helping out over Skype: Emma had hooked her screen up in a projector and I could talk and share my screen with Skype's screen sharing feature. I said a few short words about IRC and then jumped straight into demonstrating how to use a client and get on freenode's #openhatch and moznet's #introduction and #webmaker.

Later on, students were encouraged to ask any Webmaker questions in the #webmaker channel were me and other contributors could help them out. I answered some of their questions and worked with them and had lots of fun.

Overall, it was an awesome day/night both for me and the students, and I certainly hope to see them in #webmaker again contributing and having more questions!

by Errietta Kostala at October 19, 2014 01:07 PM

October 15, 2014

freenode staffblog

Server Issues: Update

Following up on our previous blog post, we have continued to investigate the compromise of freenode infrastructure, aided by our sponsors in addition to experts in the field.

NCC Group’s Cyber Defence Operations team kindly provided pro bono digital forensic and reverse engineering services to assist our infrastructure team and have recently published a report with some of their findings:

https://www.nccgroup.com/en/blog/2014/10/analysis-of-the-linux-backdoor-used-in-freenode-irc-network-compromise/

NCC’s support has been invaluable in aiding us in further securing our infrastructure, and we have already made significant changes to ensure that it is more resilient against further attacks. Our investigation into the compromise is ongoing and we will provide further updates as appropriate.

In the mean time, if you haven’t updated your password, we would advise you do so as some traffic may have been sniffed. Simply “/msg nickserv set password newpasshere” and don’t forget to update your client’s saved password.

Whilst we endeavour to provide a robust service, it is worth bearing in mind that no computer system is ever perfectly secure and many are inevitably breached. For this reason we do not suggest relying entirely on freenode (or any infrastructure) to protect sensitive data, and encourage our users to take further steps (e.g. unique passwords per service, encryption) as part of a defence in depth strategy to safeguard it.

We are extremely grateful to NCC in addition to our many other sponsors for their assistance and continued support. Without the ongoing support of our generous sponsors and wonderful infrastructure team, freenode would quite literally not have a network!

We will be continuing to work with our sponsors in addition to other relevant authorities regarding this breach and any further incidents.

by Pricey at October 15, 2014 09:27 PM

October 14, 2014

Md's blog

The Italian peering ecosystem

I published the slides of my talk "An introduction to peering in Italy - Interconnections among the Italian networks" that I presented today at the MIX-IT (the Milano internet exchange) technical meeting.

October 14, 2014 04:34 PM

October 05, 2014

erry's blog

Why I love contributing to open source software

I’m a generally quiet person, but if you ask me about open source projects, I’ll go on about them forever (I even had someone interview me about it). So, I thought I should finally get all of my honest thoughts down on my own blog as well!

freenode (or the biggest reason why I got into open source)

freenode is an IRC network dedicated to open source and peer-directed project development. It enables open source project developers to get together and discuss their work, and also provide support to their users.

I started supporting users in #freenode because I was bored in summer 2011 (literally because I was bored), then I realised I quite enjoyed it, so I just kept doing it (to the expense of my high school studies… it will be a cold day down below before I mention high school on this blog again.) Anyway, I was eventually offered to become staff, which I accepted, and I’ve been staff ever since. I’m not sure why anyone would enjoy to spend countless hours just supporting freenode users with any questions they have without expecting anything in return, but I loved it then and I love it now! I think freenode is awesome, because it helps bring many open source projects, companies and non-profits together with their users and assist in collaboration.

My role as a staff member involves helping representatives of on-topic projects manage their community on freenode, and helping other users with finding their way around and using the network.

I’m also involved with working on developing their group management system, which when deployed will help make project affiliation with freenode a lot easier. Groups will just be able to give us some information and perform verification on a website which will track requests, rather than having to manually do this with a staff member. They will also be able to take over channels for their users and perform other currently manual tasks through the portal.

Working on it helped me a lot, because I earned many of the skills I later used for my studies in University and my actual job. That’s another thing about me, I think working on open source projects ultimately helps me as much as it helps the project, at least most of the time!

Mozilla, webmaker, etc.

I also contribute to Mozilla’s projects. I fixed a few bugs for Firefox and Firefox for Mobile at first, but then I discovered webmaker, mostly thanks to social coding for good which pointed me to that project. Webmaker was easier and nicer for me to contribute to, because it used technologies I like and use, so it “stuck”. I also love Webmaker because of its goal – to provide web literacy all over the world! I think it’s extremely important because there are so many Internet users, and many of them would have their lives greatly improve if they could use the web to make ideas from their imagination come true and to express themselves. As with past open source projects, it helped me learn more about angularjs shortly before I started an angular project at work, so it was also helpful to me!

As a code contributor for webmaker, I look for bugs or feature requests filed by Mozilla employees and other contributors and resolve some of them.

I also have the unique opportunity to attend weekly demos, seeing what everyone else in the project has been up to, and even presenting my own work! This is really awesome for me because I get the opportunity to see amazing technologies in use and learn about how they were used.

Eventually I even started reviewing bugs for other contributors and Mozilla employees and mentoring bugs for new contributors, helping people get started on the project, which is also extremely rewarding and I’m really glad I get to do!

In general, I really love open source software. I think they always help people one way or another – after all, just by publishing your code so that everyone can see it you enable them to get ideas and learn (and in return you may get contributors from people who want to see their enhancements in your project!). I like contributing to certain open source projects, because they’re projects I use and/or care about, because it improves my skills, because I want a feature implemented or bug fixed so I fix it myself, because the community is awesome, and because I like being a small part of something big and awesome! I think it’s a good use of my time and knowledge, both for my own development and the community. Because of this, I plan to keep contributing for years to come!

by Errietta Kostala at October 05, 2014 08:26 PM

October 03, 2014

Md's blog

15 years of whois

Exactly 15 years ago I uploaded to Debian the first release of my whois client.

At the end of 1999 the United States Government forced Network Solutions, at the time the only registrar for the .com, .net and .org top level domains, to split their functions in a registry and a registrar and to and allow competing registrars to operate.

Since then, two whois queries are needed to access the data for a domain in a TLD operating with a thin registry model: first one to the registry to find out which registrar was used to register the domain, and then one the registrar to actually get the data.

Being as lazy as I am I tought that this was unacceptable, so I implemented a whois client that would know which whois server to query for all TLDs and then automatically follow the referrals to the registrars.

But the initial reason for writing this program was to replace the simplistic BSD-derived whois client that was shipped with Debian with one that would know which server to query for IP addresses and autonomous system numbers, a useful feature in a time when people still used to manually report all their spam to the originating ISPs.

Over the years I have spent countless hours searching for the right servers for the domains of far away countries (something that has often been incredibly instructive) and now the program database is usually more up to date than the official IANA one.

One of my goals for this program has always been wide portability, so I am happy that over the years it was adopted by other Linux distributions, made available by third parties to all common variants of UNIX and even to systems as alien as Windows and OS/2.

Now that whois is 15 years old I am happy to announce that I have recently achieved complete world domination and that all Linux distributions use it as their default whois client.

October 03, 2014 05:32 AM

September 29, 2014

Md's blog

CVE-2014-6271 fix for Debian woody, sarge, etch and lenny

Very old Debian releases like woody (3.0), sarge (3.1), etch (4.0) and lenny (5.0) are not supported anymore by the Debian Security Team and do not get security updates. Since some of our customers still have servers running these version, I have built bash packages with the fix for CVE-2014-6271 (the "shellshock" bug) and Florian Weimer's patch which restricts the parsing of shell functions to specially named variables:

http://ftp.linux.it/pub/People/md/bash/

This work has been sponsored by my employer Seeweb, an hosting, cloud infrastructure and colocation provider.

September 29, 2014 08:51 AM