Some time ago, the QR Code Generator WiFi Access made quite some noise on the mighty Internet. Sure, it is cool to be able to share your WiFi-access with someone by just showing him a QR code he can scan on his phone and the phone will auto-connect to the WiFi. But I get a strange feeling telling someone I do not know my WiFi credentials. No, I do not mean my guests, I know them. I mean that shiny web-service that will generate a QR code for me. The geek in you will now say: So? Open up a terminal, install qrencode, pipe it the string WIFI:S:<SSID>;T:<WPA WEP >;P:<password>;; and you got our QR code . Yeah, that works. But was it one or two semicolons at the end? And was it really just WPA even if my WiFi uses WPA2? Oh and how do I encode that umlaut again? I do not want to remember this. Thus, without too much rumble, may I present you: QiFi the pure JS WiFi QR Code Generator. QiFi is a QR code generator for WiFi access in pure JavaScript. It will generate the QR code on your machine, in your browser, not leaking your precious credentials to anyone (but your guests). Don t trust me? Read the code. Fork the code. Host the code yourself. I hope you will find QiFi at least slightly useful ;-)

2 comment(s) this blog is flattr enabled

Also this year the Debian project was present at Chemnitzer Linuxtage, this time right next the debianforum.de booth. The booth folks arriving on friday organized a flashmob at Expitas after booth setup. Unfortunatly our second planned flashmob at the mensa was boycotted by much more students, so we ended up in the Turm-Brauhaus, which is a great location with good drinks but the service was very harshly. On the next two days at the booth we chatted and discussed with visitors and other exhibitors a wide variety of questions, including 'When will be (the next Debian version) released?' and 'Are there installation disks available?'. The answers was as always 'When we are ready and we will have reached the quality-level we defined', 'No we don't have installation medias, as they are always outdated. Do you have an USB-dongle with you?'. Merchandising was requested by visitors as always, but we just had some leftovers of fosdem, brought by Axel. The demonstration was as usual a small box running Babelbox and xpenguins which worked out the last years too. This year there were three lectures held by Debian related people, about Debian GIS, Aptitude - known but even unknown and SSH and unreliable network connections. The organisation team did a really great job. The social event at saturday night was very exciting and we left it early in the morning. The whole event was indeed fun and a pleasure to find new friends and meet old ones of the Free Software community. Many thanks to Florian Baumann, Jan Dittberner, Andreas Tille, Christian Hoffmann, Axel Beckert, Markus Rekkenbeil, Daniel Schier, Jonas Genannt, Jan H rsch and kurio for taking care and running the booth, which worked out this year extreme smoothly from my point of view. Likewise as the last years a special thanks to TMT GmbH & Co. KG, which kindly donated additional boothtickets, the equipment, its transportation and accommodation for almost half of the booth staff.

This night you might have noticed that some services like hosted Weblate or phpMyAdmin wiki being quite flaky. It was caused by DDOS attack which pretty much busted firewall and thus made unable to open new connections. In the morning when I've realized this, I introduced another breakage by too strict filtering on firewall :-). However now everything should be back to normal.

Filed under: English Phpmyadmin Weblate 0 comments Flattr this!

* So, we got new laptop last week. The entire plan was to introduce my wife into tech world or atleast in Debian and/or OpenSouce world. I visited home for one of this and other personal reason(s) [Expect next post on this!]. My wife reported her first bug (installation-report, with help from me) which was closed by mighty bubulle! I handed over couple of freely available Python books and we started with codecademy s Python track. So far, things are good, but being really non-tech person, I m currently working as support system for her. I ve used KDE as desktop. Machine runs on latest kernel from experimental due to issues with hardware mentioned here. I was not able to explain IRC in much depth, so we re using non-free methods like Google Talk for communicating and reporting. Wish us luck! I ll report Part 2 when things will be enough to report the progress.

Sometimes obtaining a substring in a shell script is needed. The bashism of this week comes handy as it allows one to obtain a substring by indicating the offset and even the length of the substring. This is the $ varname:offset:length bashism, also known as substring expansion.

The portable "replacements" are simple if the offset (and the length) are static. For example, the following code would print the substring of "foo" consisting of only the last two characters:

var=foo
# Replace the bashism $ var:1  with:
echo $ var#? 

The length can then be limited with additional pattern-matching removal expansions:

var="portable code"
# Replace the bashism $ var:3:5  with the following code

# Offset is 3, so we use three ? (interrogation) characters:
part=$ var#??? 

# Length is 5, so we use five ? characters:
echo $ part%$ part#????? 

As it can be seen, it is not impossible to replace a substring expansion.

The portable code becomes slightly more complex if the offset and/or the length are dynamic. I leave that as an exercise for the readers.

Feel free to post your code as a comment (use the <pre> tags, please) or in another public way. My own response is already scheduled to be published next week at the same time as usual.

Note: substring expansions can also be replaced with a wide variety of external commands. This is a pure-POSIX shell scripting example.

Given how Debian and Ubuntu nowadays enable IPv6 support by default, the routing table includes some IPv6 entries by standard. However, this has the unpleasant side-effect that lib C tries to connect to public IPv6 addresses, even in a case when the only IPv6 entries are for loopback and local link. Apparently, libc incorrectly assumes that the mere presence of any IPv6 means that there is a usable default IPv6 route. This results in, among other things, APT failing at fetching packages from the Debian repository if the DNS rotation returned the IPv6 address for the server first. I was thus wondering whether libc6 could be made to reject public IPv6 addresses, in cases when the host has no IPv6 gateway in its routing table? Or would there be a smarter way to prevent applications from failing at contacting IPv6 addresses whenever there is no IPv6 connection to the outside world?

The problem with Samsung laptops bricking themselves turned out to be down to the UEFI variable store becoming more than 50% full and Samsung's firmware being dreadful, but the trigger was us writing a crash dump to the nvram. I ended up using this feature to help someone get a backtrace from a kernel oops during suspend today, and realised that it's not been terribly well publicised, so.

First, make sure pstore is mounted. If you're on 3.9 then do:

mount -t pstore /sys/fs/pstore /sys/fs/pstore

For earlier kernels you'll need to find somewhere else to stick it. If there's anything in there, delete it - we want to make sure there's enough space to save future dumps. Now reboot twice[1]. Next time you get a system crash that doesn't make it to system logs, mount pstore again and (with luck) there'll be a bunch of files there. For tedious reasons these need to be assembled in reverse order (part 12 comes before part 11, and so on) but you should have a crash log. Report that, delete the files again and marvel at the benefits that technology has brought to your life.

[1] UEFI implementations generally handle variable deletion by flagging the space as reclaimable rather than immediately making it available again. You need to reboot in order for the firmware to garbage collect it. Some firmware seems to require two reboot cycles to do this properly. Thanks, firmware.

comments

For some time, Weblate was showing avatars for users. Just as I've discovered Libravatar - free and federated alternative to Gravatar, I thought it would be better replacement. Quickly looking at their website, it seems that they transparently provide all avatars from Gravatar as well, so the migration seems to be pretty much painless. Basic replacement to use their server is just matter of changing base URLs, however to support federated behavior, you have to install pyLibravatar. Weblate in Git now supports both these ways. While implementing the client side, I did also setup my own instance of Surrogator to provide avatars for some of my domains. Surprisingly this worked fine without problems, but let's see how much used this will actually become.

Filed under: English Phpmyadmin Weblate 2 comments Flattr this!

It is customary during Debian Project Leader elections to write a rebuttal of the other candidate's platform. However, this is very hard to do this year, as there are a lot of overlaps between platforms, goals and ideas this time around. It is hard to rebute another platform, without also rebuting one's own. So instead of trying to highlight where I disagree (there's very little of that, if at all), I'd like to point out where I found each platform lacking.Mind you, these notes are primarily based off of the platforms, because I'm sadly still behind on my debian-vote@ reading list. Furthermore, due to the high level of similarity between platforms, I will not always single out one or the other, but mention what I found lacking, or troublesome in general instead. So unless stated otherwise, my thoughts below apply to both Moray's and Lucas' platforms.The thing I miss most from both platforms is the curious lack of plans about non-packaging project members (something which I strongly emphasize in my own platform). Similarly, even though Moray does mention encouraging more local events, I find those few paragraphs a little bit lacking; and Lucas does not even mention local teams in his platform, even though they are a very, very important part of the wider Debian community, and a terrific tool in our asset. They can further our reach by long miles! Considering their importance, little's said about either local teams or local events, even when the candidate does explicitly recognise their importance.On the other hand, Lucas writes about innovation within Debian (which I found lacking in Moray's platform) - but while he does bring up the topic, I sadly found that section of his platform vague, a mistake I made last year myself, and which I tried to avoid this time, by explicitly listing a few of my ideas on how I'd imagine inspiring & motivating people (which, in turn, would foster innovation within the project).From what I see - and I may be wrong here, and I am obviously biased - both platforms are reasonably explicit when it comes to easier topics, things that we know to work, and which we'd all continue doing in the very same spirit as our predecessor. But when it comes to experimenting, to new ideas, I found both platforms too vague. There are exceptions, of course, Moray's intern idea for example is sufficiently well explained, as far as it is possible within the limits of a platform. I found no similar thing in Lucas' platform, however, most of the ideas he explained were technical things, and those are the areas where we're fairly good at, where we already have a reasonably chance of improving - and thus, an easier topic. I was suprised by Lucas' platform, because even though he lists the need for experimentation important, the lack of truly experimental ideas was lacking - I found more in Moray's platform.All in all, I found the discussions on debian-vote@ much more useful so far, than the platforms, a lot of things were asked and answered there that the platforms did not touch.

So, since recently bugs.debian.org has started using libravatar avatars. Not yet the federated service, but that s supposedly in the works. But for that, one of course need to run each own service. Which I wanted to do. In a simple way. So I did it.

_avatars._tcp.pusling.com. 43200 IN SRV 10 10 80 static.pusling.com.

and in my root dir for that one I have source/ and avatar/

$ ls
avatar source

In source, I have default.png which I m serving and a series of avatars for various email addresses

$ ls source/
debian@pusling.com default.png

and then I have a simple script to generate the right file names:

#! /bin/sh (cd avatar;
ls while read file ; do [ -L $file ] && rm $file ; done
)
for i in source/*@* ; do ln -s ../$i avatar/$(echo -n $(basename $i) sha256sum sed s/-// ) ; done
for i in source/*@* ; do ln -s ../$i avatar/$(echo -n $(basename $i) md5sum sed s/-// ) ; done

and the last piece of magic to get everything to work:

$ cat avatar/.htaccess
ErrorDocument 404 /source/default.png
ForceType image/png <Files index.html >
ForceType text/html
</Files>

and a set of index.html files created with touch . So there you go. A simple libravatar service, ignoring some pieces of the spec, but it should be good enough for most people. I might save my rants about the libravatar spec for another day. But it involves implementing a complete redirecting service and scaling of images. When will debian.org and kde.org start providing avatar services?

Finally.. My bee box has arrived. Initially I had planned to build it myself, but with current time constraints and in light of the fact that the commercial variant is built in a sheltered workshop, I decided to go for a pre-built one. The bee box is designed to give bees a natural habitat and allow them to get through the winter without the need for artificial sugar. Harvest is limited to about 15 kg in a good year as opposed to up to 50 kg in commercial beehives, but this method of beekeeping is less stressful for the bees. The trick is that there are two sections in every bee box; starting in the second year, you open the second section as soon as the bees have started to run out of space. As that's done relatively late in May, the bees will mainly build honey-only non-larvae honeycombs. During harvest, you remove only those secondary honeycombs; as a result, the bees will not need to defend their larvae and thus be a lot more relaxed. As those bees are under supervision of a human with access to oxalic acid, it's trivial to protect those bees against infestations by varroa destructor and to keep them safe form mice during winter. Bees are incredibly important for nature's cycle, so this is a hobby with a lot of positive impact on your local flora, and subsequently fauna. And hey.. free honey!

Just a small update for those that use my little tmux helper: You may want to fetch the latest version from my git repository. At least if you have to deal with a tmux version prior to 1.4 (like, on squeeze), though I really recommend to use a later one. 1.6 from backports or 1.7 (but thats not backported). Fix is small, just a better handling of the non-existing -V option to get the version information.

Dear users and supporters of the backports service! The Backports Team is pleased to announce the next important step on getting backports more integrated. People who are reading debian-infrastructure-announce will have seen that there was an archive maintenance last weekend: starting with wheezy-backports the packages will be accessible from the regular pool instead of a separate one, and all backports uploads will be processed through the regular upload queue (including those for squeeze-backports and squeeze-backports-sloppy). For Users What exactly does that mean for you? For users of wheezy, the sources.list entry will be different, a simple substitute of squeeze for wheezy won't work. The new format is:

deb http://ftp.debian.org/debian/ wheezy-backports main

So it is debian instead of debian-backports, and offered through the regular mirror network. Feel invited to check your regular mirror if it carries backports and pull from there. For Contributers What does it mean for contributing developers? Uploads for backports are no longer to be pushed to backports-master but to ftp.upload.debian.org, like any other regular package. Also, given that the packages are served from the same archive install there is no need to include the original tarball in the upload any longer because the archive knows it (Squeeze and beyond). Also, given that the upload goes to the same upload queue, there is only one keyring used anymore, so no more pain with expired or replaced keys. We though still keep the rule of adding your UID to an ACL list (this also includes DM additions). This is mostly only to give us the chance to remind you that uploads to backports are directly available for installation onto stable systems and you thus should take special care there. We carefully tried to take over the old ACLs, in case you can't upload anymore, please tell us so we can look into the issue. I've mentioned wheezy-backports (and squeeze-backports-sloppy) a few times here already, and you might wonder when it will be available. Technically, it is available from now on. Practically, while you could already upload to it, the set up of the buildd network is more painful than expected, so please allow the Buildd Team some days for setting them up. The upload rules for wheezy-backports are the same: packages that are in the next suite are accepted. Given that Jessie isn't created yet, we want you to think about whether the package you want to upload will go into Jessie final, and that you are taking a closer look once Jessie is created and the package entered there about the upgradeability. For the time until the suite is available, you can see this as relaxed upload rule. The same goes for squeeze-backports-sloppy: packages from two suites after Squeeze are acceptable, which turns it into the same relaxed rule as wheezy-backports above. Please also keep in mind that uploads to squeeze-backports-sloppy usually should be accompanied by uploads to wheezy-backports so people are able to upgrade from squeeze-backports-sloppy to wheezy with wheezy-backports. Thanks Finally, we want to thank the FTP-Master Team for their fine work on making this happen. The documentation on backports-master has been updated, and in case of any doubt or question, feel free to ask them on either the debian-backports mailinglist, or in case of sensitive topics ask us directly. Enjoy!
Rhonda for the Backports Team

/debian permanent link Comments: 1 Flattr this

Next round of phpMyAdmin 4.0 translation status report is coming. So let's look at which translations are at 100% right now:

• Czech
• Dutch
• English (United Kingdom)
• Greek
• Spanish
• Swedish
• Turkish

Almost complete:

• Chinese (China)
• Danish
• Estonian
• French
• Galician
• German
• Polish
• Portuguese (Brazil)
• Russian
• Slovenian

As you can see, there is still lot of languages missing, this might be your opportunity to contribute to phpMyAdmin. Also you are welcome to translate phpMyAdmin 4.0 using translation server. If your language is already fully translated and you want to help as well, you can translate our documentation as well.

Filed under: English Phpmyadmin 0 comments Flattr this!

I Although I don t mean to brag I have a really great scarf-hood-combination garment. I was wearing said awesome scarf in a rather cold apartment during my remote participation in the Learning Creative Learning class. I would like to think that I said some interesting and insightful things. But if I didn t, I m glad to hear my scarf which now has its very own sub-reddit was able to impress and entertain.

& another week has gone by where I tried to work on RC bugs. here's the overview:

• #656090 ocsinventory-server: "ocsinventory-server: prompting due to modified conffiles which where not modified by the user"
  ping bug, provide a package for piuparts testing, later upload to DELAYED/2
• #702753 src:spandsp: "spandsp: Downloads external files at build time (through xsltproc) -- missing Build-Depends?"
  confirm and prepare patch, later upload to DELAYED/2
• #702769 bup: "FTBFS: bup.git.GitError: no such commit '75cd2b98c52d29ba5d510b37d7c9adb01553bd1f'"
  add some information
• #702790 service-wrapper-java: "FTBFS: local changes detected"
  investigate and send a possible cause of the problem to the bug log, add a patch later
• #703094 owncloud: "owncloud: multiple vulnerabilities (oC-SA-2013-009, oC-SA-2013-010)"
  prepare patch from upstream commits