This is not a new world, this is simply an extension of the old one. I'm not going to write here about sweeping changes that are happening now, but changes that have been taking place in plain sight for many decades. No one has flipped a switch, only tweaked and tuned variables here and there to lead us down this path. I'd like to reflect on where we are now but there is no way I could describe how it is we got here, the journey was far too complex and filled with ommissions, half-truths and outright lies. It's likely we will never know what has brought us here. I live in Scotland, a country that is a part of the United Kingdom and a member of the European Union. We have a Scottish Government, although certain matters are still handled by the UK Government. The European Government also handles some matters and these can take effect across the entire European Union. I do not feel that I can hold trust in any of these bodies anymore. The European Convention on Human Rights was, for me at least, a beacon of hope. A series of fundamental rights guaranteed to be upheld for every person within the European Union. A series of fundamental rights that has been ignored by governments repeatedly:

• 1999: it was held the UK had violated the human rights of several homosexual soldiers who had been dismissed from the armed forces because of their sexuality
• 2002: it was held the UK had violated the human rights of a widower regarding entitlement to receive bereavement benefits who had been discriminated against on account of his gender
• 2005: it was held that the UK violated the human rights of prisoners by denying them the ability to vote
• 2010: the stop and search procedures used by the UK police pursuant to the Terrorism Act 2000 were considered illegal under the ECHR because they did not require the police to have grounds for suspicion before using them

This is not an exhaustive list, just select cross-sections of our recent history. It is important to remember that in each of these cases, it took a citizen to take the case to the European Court of Human Rights. These rights were violated by the UK government until the actions were challenged, the legislation that allowed them was currently enacted into UK law without regard for the ECHR. It should also be noted that the ban on prisoners voting is still in effect in the UK. We've learnt that the ECHR is not an effective safeguard against the abuse of powers by government. The UK government also sees the Human Rights Act as a problem, although at least scrapping it has been delayed for now. Much of these breaches of human rights are justified by the government as in the interest of the runaway train known as "national security". I have recently had direct contact with one aspect of this during my journey home from 32c3. You can read about my experiences with airport security here and here. My experiences at these airports angered me for a number of reasons. The first of which was that I was asked to expose my genitals as part of the routine screening, which I do not believe to be proportionate at all. At Luton, I was at the point where I was intending to leave the airport and take the train instead before I was allowed to excercise my right to opt-out of the nude body scanner. Since these incidents, I have conducted some research into these scanners and started an article on the Open Rights Group wiki. While the security officer at Luton had tried to tell me that the radio waves used could not penetrate clothing, they in fact can and this is the entire purpose of them. While the security officer at Luton told me that the machines did not generate an image, they are in fact doing exactly that, even if that image is processed by computer vision algorithms as opposed to being viewed by a human reviewer. A leaflet by the Department for Transport, made available on the Aberdeen Airport website, also states that no image is created, and yet this is exactly how the scanners work. I have never seen this leaflet printed and available in the airport itself, although I admit I do not fly regularly and may have missed it. That said, it does not provide a true representation of the scan process and I would go as far to say it contains an outright lie. In a document published by the UK Government titled "Response to the consultation on the use of security scanners in an aviation security environment", they state:

"nearly all passengers, if they fully understand the procedures, would be unlikely to opt for [the alternative of a private search]"

Even with this display of confidence that they believe the public are happy with the invasion of privacy brought by the security scanners, they have still chosen to not fully inform the public in the way in which the scanner operates. It is the lies that anger me the most. We claim to live in a democracy and you cannot have a democracy without transparency. It is not too late for the Government to earn back my trust, but for now, they haven't given me good reason to believe anything they produce. If you have read this article and you would like to support efforts for change in the United Kingdom, please consider joining the Open Rights Group and perhaps getting involved in their work.

Debian LTS December was the eighth month I contributed to Debian LTS under the Freexian umbrella. It was a bit of a funny month since most of the time most open CVEs were already taken care of by other team members (which is nice) but it resulted in me not releasing a single DLA which feels weird. Nevertheless in total I spent nine hours working on:

• LTS Frontdesk duties like the triaging of 16 CVEs and patch reviews (which actually found an error reassuring me that spending time on this is useful).
• Finding a fix for CVE-2015-7555 in giflib. I did not release a DLA yet since I hoped upstream would comment if this is the proper fix.
• nss/nspr:
  • Discussion on using the same nss in all suites continued.
  • I did further upgrade test for nss focusing on Java this time (which is a heavy user of nss for its certificate handling).
  • Enabled the internal testsuite of nspr as well since nss and nspr often get updated in lockstep. This resulted in 809723 and upstream bugs 1236333, 1236334, 1236244 (which were already merged thanks to Wan-Teh Chang). The current modifications are available here. Overall the test suite needs more cleanups but it's already useful as is.

On unpaid time I introduced some usertags for tracking our non DLA related activities (although it seems I'm currently the only user). Other Debian stuff

• I uploaded libvirt 1.3.0~rc1 and 1.3.0~rc2 to experimental and 1.3.0 final to unstable.
• I uploaded libvirt-python 1.3.0 with newly added autopkg tests
• Filed bugs reminding that libvirt-bin is a transitional package that will be dropped soon.
• Finally released gbp 0.7.1 with lots of changes most of these where already mentioned in the December installment of this post but there's more:
  • git-pbuilder updates to 1.37 and 1.38
  • fixes for 791759 and 766350,
  • doc updates including the addition of the patch queue handling
  Still looking for time to finish gbp import-orig's rollback support.
• I added a function to link to the Debian BTS to my emacs config to ease writing these kind of posts.

The elections for the new OpenStack board are coming closer
and this time the Open Source community has a great
opportunity of representation: Giuseppe Patern is standing as a candidate for the board.
Although Giuseppe is considered by HP and Forrester Research
among the top talented consultants in the world,
Gippa (as he s largely known in the industry) is still one of us ,
a nerd that grew up with a keyboard on his hands.
As he s one of the candidates of the OpenStack board,
Fabio Marzocca wishing to know more has interviewed him.

[FM] The hard question. You re a techie. Why the hell are you running for the board?

[GP] This is indeed a good question It all started as a challenge from some clients and friends that are working in the OpenStack project. The truth is that the board and most of the management of the foundation are from vendors. I m not questioning here if they do a good job or not, it is very likely that they tend to protect their own interests. In my opinion it lacks some community spirit that have fostered Linux development such as Debian and Ubuntu. That s why I m running for it, to bring the community where it should be.

[FM] Back to Debian and Ubuntu, could you tell us your story with Linux?

[GP] I discovered Linux in 1994, but only in 1996 things were serious. By the time I just finished high school and I applied for a job in a local Internet Service Provider. At 15 years I was well known in the local community as I was installing and maintaining several BBSes, so it wasn t hard to get the job. I can say it was love at first sight. I started with Slackware (was the first distro), but I moved into redhat first and then debian. When I was working for the IBM Linux Technology Center, I was in charge of helping porting Linux to PowerPC and backporting LVM to make it similar to AIX. Sun was also a good playground as they acquired Cobalt, a hardware appliance based on debian. Then I shifted more towards Enterprise Linux adoption with 6 years in RedHat and then I went to Canonical. I was happy to go back to Debian and Ubuntu community, because I still believe that Ubuntu Developer Summits (UDS) were the real spirit of a Linux community.

[FM] Another hard question. We know you re somehow involved in the rebellion of Devuan.org. What is your opinion about systemd?

[GP] Let me tell you that it s not totally black/white and let s see the two sides here. Something like systemd was indeed needed. Each distro has its own way of init ing the system and for a package maintainer or commercial software maker, maintaining different init behaviour is insane. And as an init replacement it totally makes sense. However, IMHO systemd went too far away, incorporating into its code something that should not happen. A DHCP client into an init system, seriously? I doubt it was in the spirit of the Unix and Linux system
However, in the real world of pets vs cattle , where application matters more than systems, having a systemd as it is, doesn t change that much.

[FM] OpenStack was incubated in Ubuntu and the roots are quite clear. Is there something else that you would like to see from Debian and Ubuntu in OpenStack?

[GP] Stability, if I can name just one. Currently OpenStack is released every 6 months, which was probably the best choice to speed up the development. However, this is now becoming a weakness, as enterprise customers can t upgrade their critical infrastructures every 6 months. Traditionally Debian is maniacally focused on given a bullet-proof distribution, this is something that in my opinion is missing from OpenStack.

[FM] Gippa, tell us just 2 or 3 topics you will bring to action in case of election

[GP] I d like to introduce an OpenStack LTS process, following the Ubuntu approach: while releasing every 6 months is fair enough for development and testing environments, having a stable release every 2-3 years can give enterprise customers the peace of mind they need while running production environments.
I d also love to see a consolidation of the core (Nova/Neutron/Cinder/Swift): vendors and developers are introducing new features and projects while I d love to see for example- a more stable and scalable Neutron and a more stable connection to Oslo (in particular rabbitmq).
In general, I would encourage more attention to who is actually deploying, integrating and using OpenStack every day. I would also try to foster the ecosystem of ISVs in order to release and certify their software for OpenStack. And last but not least- to see interoperation between regional datacenters: I dream of a world where companies in a given territory can work together , and this is only possible through standards. I hope that OpenStack can represent this standard.

[FM] When are the elections and how can we vote?

[GP] Individual Member Director elections for the 2016 Board will be held online from Monday January 11, 2016 to Friday January 15, 2016. More informations on the website.

Smartphones, ownership and hope for the fate of humanity
Do you own your phone or does it own you? DanielPocock.com


I have conflicting opinions about this article.

Usually I carry a dumb phone, so I'm not completely disconnected, but I'm mostly self-limited to "useful" communications by the fact that I have to pay for calls and SMSs. It also has a few useful features like showing the time , an alarm clock and a led torch, but that's it.

I also carry a smartphone, but I've never been able to trust it with my personal data, so there is no email on it and no communication software. It's also always offline to preserve battery, unless I'm actually using it for something (usually maps). It does have an offline wikipedia reader, which is the second thing I use it more often for. About half of the time I try to use it, however, it is off because I forgot to charge it, unless I've planned in advance to use it (which usually means I'm also carrying a laptop and will need to tether it).

So I guess that I should be agreeing with the article that offline life is better, and that we shouldn't depend on phones in our daily life, and mostly I do.

On the other hand, I'm not so sure that all of the people who seem to be interacting with a phone are actually disconnected from the local reality.

More than once I've experienced the use of smartphones as part of a local interaction: one typical case involves people having a conversation IRL and checking some fact on the internet and then sharing the results with the rest of the local group.

Actually, most of the time I've seen a smartphone being used at our table while eating with friends or collegues it was being passed around to show something to the people at the table, or at the very least being read aloud from, so it was part of the local experience, not a way to disconnect from it.

I'm sure that there are cases of abuse, but I still have hope that most of the connected humanity is managing to find a good balance between online and offline.

I don't want to go back carrying a wrist watch. I remember them as something unconfortable that ended up hitting stuff as I moved my hands, and I'd rather have my wrists free while I type, thanks. Pocket watches, OTOH...

the main exception involved one young adult in the middle of significantly older relatives, which is a somewhat different issue, and one that I believe predated smartphones (IIRC in my case similar situations involved trying to be somewhere else by reading a book).

Modern versions of Linux and MythTV enable infrared remote controls without the need for lirc. Here's how I migrated my Streamzap remote to evdev.

Installing packages In order to avoid conflicts between evdev and lirc, I started by removing lirc and its config:

apt purge lirc

and then I installed this tool:

apt install ir-keytable

Remapping keys While my Streamzap remote works out of the box with kernel 3.16, the keycodes that it sends to Xorg are not the ones that MythTV expects. I therefore copied the existing mapping:

cp /lib/udev/rc_keymaps/streamzap /home/mythtv/

and changed it to this:

0x28c0 KEY_0
0x28c1 KEY_1
0x28c2 KEY_2
0x28c3 KEY_3
0x28c4 KEY_4
0x28c5 KEY_5
0x28c6 KEY_6
0x28c7 KEY_7
0x28c8 KEY_8
0x28c9 KEY_9
0x28ca KEY_ESC
0x28cb KEY_MUTE #  
0x28cc KEY_UP
0x28cd KEY_RIGHTBRACE
0x28ce KEY_DOWN
0x28cf KEY_LEFTBRACE
0x28d0 KEY_UP
0x28d1 KEY_LEFT
0x28d2 KEY_ENTER
0x28d3 KEY_RIGHT
0x28d4 KEY_DOWN
0x28d5 KEY_M
0x28d6 KEY_ESC
0x28d7 KEY_L
0x28d8 KEY_P
0x28d9 KEY_ESC
0x28da KEY_BACK # <
0x28db KEY_FORWARD # >
0x28dc KEY_R
0x28dd KEY_PAGEUP
0x28de KEY_PAGEDOWN
0x28e0 KEY_D
0x28e1 KEY_I
0x28e2 KEY_END
0x28e3 KEY_A

The complete list of all EV_KEY keycodes can be found in the kernel. The following command will write this mapping to the driver:

/usr/bin/ir-keytable w /home/mythtv/streamzap -d /dev/input/by-id/usb-Streamzap__Inc._Streamzap_Remote_Control-event-if00

and they should take effect once MythTV is restarted.

Applying the mapping at boot While the na ve solution is to apply the mapping at boot (for example, by sticking it in /etc/rc.local), that only works if the right modules are loaded before rc.local runs. A much better solution is to write a udev rule so that the mapping is written after the driver is loaded. I created /etc/udev/rules.d/streamzap.rules with the following:

# Configure remote control for MythTV
# https://www.mythtv.org/wiki/User_Manual:IR_control_via_evdev#Modify_key_codes
ACTION=="add", ATTRS idVendor =="0e9c", ATTRS idProduct =="0000", RUN+="/usr/bin/ir-keytable -c -w /home/mythtv/streamzap -D 1000 -P 250 -d /dev/input/by-id/usb-Streamzap__Inc._Streamzap_Remote_Control-event-if00"

and got the vendor and product IDs using:

grep '^[IN]:' /proc/bus/input/devices

The -D and -P parameters control what happens when a button on the remote is held down and the keypress must be repeated. These delays are in milliseconds.

Okay, this report is not weekly and is a bit late, but anyway here comes report covering last two weeks in 2015. As you might expect there were some days off, but still quite some work has been done. I've focused on encoding conversions and usage of mb_* functions. One of results was cleanup PR and some opened questions. The PR is already merged meanwhile and we will probably make again the mbstring dependency options. Rest was pretty much just bug fixing. Fixed issues:

• #11788 Problems with error message conversion
• #11787 Errors from iconv
• #11786 Kanji encoding errors
• #11785 Internal encoding different than UTF-8
• #11784 Warning: zip_close() expects parameter 1 to be resource
• #11783 ReferenceError: PMA_messages is not defined
• #14 Offer just the latest theme version for a specific phpMyAdmin version

Filed under: English phpMyAdmin 0 comments

With the world passing 10% IPv6 penetration over the weekend, we see the same old debates coming up again; people claiming IPv6 will never happen (despite several years now of exponential growth!), and that if they had only designed it differently, it would have been all over by now. In particular, people like to point to a 2002 3 article by D. J. Bernstein, complete with rants about how Google would never set up useless IPv6 addresses (and then they did that in 2007 I was involved). It's difficult to understand exactly what the article proposes since it's heavy on calling people idiots and light on actual implementation details (as opposed to when DJB's gotten involved in other fields; e.g. thanks to him we now have elliptical curve crypto that doesn't suck, even if the reference implementation was sort of a pain to build), but I will try to go through it nevertheless and show how I cannot find any way it would work well in practice. One thing first, though: Sorry, guys, the ship has sailed. Whatever genius solution DJB may have thought up that I'm missing, and whatever IPv6's shortcomings (they're certainly there), IPv6 is what we have. By now, you can not expect anything else to arise and take over the momentum; we will either live with IPv6 or die with IPv4. So, let's see what DJB says. As far as I can see, his primary call is for a version of IPv6 where the address space is an extension of the IPv4 space. For sake of discussion, let's call that IPv4+ , although it would share a number of properties with IPv6. In particular, his proposal requires changing the OS and other software on every single end host out there, just as IPv6; he readily admits that and outlines how it's done in rough terms (change all structs, change all configuration files, change all databases, change all OS APIs, etc.). From what I can see, he also readily admits that IPv4 and IPv4+ hosts cannot talk to each other, or more clearly, we cannot start using the extended address space before almost everybody has IPv4+ capable software. (E.g., quote: Once these software upgrades have been done on practically every Internet computer, we'll have reached the magic moment: people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. ) So, exactly how does the IPv4 address space fit into the IPv4+ address space? The article doesn't really say anything about this, but I can imagine only two strategies: Build the IPv4+ space around the IPv4 space (ie., the IPv4 space occupies a little corner of the IPv4+ space, similar to how v4-mapped addresses are used within software but not on the wire today, to let applications do unified treatment of IPv4 addresses as a sort of special IPv6 address), or build it as a hierarchical extension. Let's look at the former first; one IPv4 address gives you one IPv4+ addresses. Somehow this seems to give you all the disadvantages of IPv4 and all the disadvantages of IPv6. The ISP is not supposed to give you any more IPv4+ addresses (or at least DJB doesn't want to contact his ISP about more also saying that the fact that automatic address distribution does not change his argument), so if you have one, you're stuck with one. So you still need NAT. (DJB talks about proxies , but I guess that the way things evolved, this either actually means NAT, or it talks about the practice of application-level proxies such as Squid or SOCKS proxies to reach the Internet, which really isn't commonplace anymore, so I'll assume for the sake of discussion it means NAT.) However, we already do NAT. The IPv4 crunch happened despite ubiquitous NAT everywhere; we're actually pretty empty. So we will need to hand out IPv4+ addresses at the very least to new deployments, and also probably reconfigure every site that wants to expand and is out of IPv4 addresses. ( Site here could mean any organizational unit, such as if your neighborhood gets too many new subscribers for your ISP's local addressing scheme to have enough addresses for you.) A much more difficult problem is that we now need to route these addresses on the wire. Ironically, the least clear part of DJB's plan is step 1, saying we will extend the format of IP packets to allow 16-byte addresses ; how exactly will this happen? For this scheme, I can only assume some sort of IPv4 option that says the stuff in the dstaddr field is just the start and doesn't make sense as an IPv4 address on its own; here are the remaining 12 bytes to complete the IPv4+ address . But now your routers need to understand that format, so you cannot do with only upgrading the end hosts; you also need to upgrade every single router out there, not just the end hosts. (Note that many of these do routing in hardware, so you can't just upgrade the software and call it a day.) And until that's done, you're exactly in the same situation as with IPv4/IPv6 today; it's incompatible. I do believe this option is what DJB talks about. However, I fail to see exactly how it is much better than the IPv6 we got ourselves into; you still need to upgrade all software on the planet and all routers on the planet. The benefit is supposedly that a company or user that doesn't care can just keep doing nothing, but they do need to care, since they need to upgrade 100% of their stuff to understand IPv4+ before we can start even deploying it alongside IPv4 (in contrast with IPv6, where we now have lots of experience in running production networks). The single benefit is that they won't have to renumber until they need to grow, at which point they need to anyway. However, let me also discuss the other possible interpretation, namely that of the IPv4+ address space being an extension of IPv4, ie. if you have 1.2.3.4 in IPv4, you have 1.2.3.4.x.x.x.x or similar in IPv4+. (DJB's article mentions 128-bit addresses and not 64-bit, though; we'll get to that in a moment.) People keep bringing this up, too; it's occasionally been called BangIP (probably jokingly, as in this April Fool's joke) due to the similarity with how explicit mail routing would work before SMTP became commonplace. I'll use that name, even though others have been proposed. The main advantage of BangIP is that you can keep your Internet core routing infrastructure. One way or the other, they will keep seeing IPv4 addresses and IPv4 packets; you need no new peering arrangements etc.. The exact details are unclear, though; I've seen people suggest GRE tunneling, ignoring problems they have through NAT, and I've seen suggestions of IPv4 options for source/destination addresses, also ignoring that someting as innocious as setting the ECN bits has been known to break middleboxes left and right. But let's assume you can pull that off, because your middlebox will almost certainly need to be the point that decapsulates BangIP anyway and converts it to IPv4 on the inside, presumably with a 10.0.0.0/8 address space so that your internal routing can keep using IPv4 without an IPv4+ forklift upgrade. (Note that you now lose the supposed security benefit of NAT, by the way, although you could probably encrypt the address.) Of course, your hosts will need to support IPv4+ still, and you will need some way of communicating that you are on the inside of the BangIP boundary. And you will need to know what the inside is, so that when you communicate on this side, you'll send IPv4 and not IPv4+. (For a home network with no routing, you could probably even just do IPv4+ on the inside, although I can imagine complications.) But like I wrote above, experience has shown us that 32 extra bits isn't enough. One layer of NAT isn't doing it, we need two. You could imagine the inter-block routability of BangIP helping a fair bit here (e.g., a company with too many machines for 10.0.0.0/8 could probably easily get more addresses for more external IPv4 addresses, yielding 10.0.0.0/8 blocks), but ultimately, it is a problem that you chop the Internet off in two distinct halves that work very differently. My ISP will probably want to use BangIP for itself, meaning I'm on the outside of the core; how many of those extra bits will they allocate for me? Any at all? Having multiple levels of bang sounds like pain; effectively we're creating a variable-length address. Does anyone ever want that? From experience, when we're creating protocols with variable-length addresses, people just tend to use the maximum level anyway, so why not design it with 128-bit to begin with? (The original IP protocol proposals actually had variable-length addresses, by the way.) So we can create our 32/96 BangIP , where the first 32 bits are for the existing public Internet, and then every IPv4 address gives you a 2^96 addresses to play with. (In a sense, it reminds me of 6to4, which never worked very well and is now thankfully dead.) However, this makes the inside/outside-core problem even worse. I now need two very different wire protocols coexisting on the Internet; IPv4+ (which looks like regular IPv4 to the core) for the core, and a sort of IPv4+-for-the-outside (similar to IPv6) outside it. If I build a company network, I need to make sure all of my routers are IPv4+-for-the-outside and talk that, while if I build the Internet core, I need to make sure all of my connections are IPv4 since I have no guarantee that I will be routable on the Internet otherwise. Furthermore, I have a fixed prefix that I cannot really get out of, defined by my IPv4 address(es). This is called hierarchical routing , and the IPv6 world gave it up relatively early despite it sounding like a great idea at first, because it makes multihoming a complete pain: If I have an address 1.2.3.4 from ISP A and 5.6.7.8 from ISP B, which one do I use as the first 32 bits of my IPv4+ network if I want it routable on the public Internet? You could argue that the solution for me is to get an IPv4 PI netblock (supposedly a /24, since we're not changing the Internet core), but we're already out of those, which is why we started this thing to begin with. Furthermore, if the IPv4/IPv4+ boundary is above my immediate connection to the Internet (say, ISP A doesn't have an IPv4 address, just IPv4+), I'm pretty hosed; I cannot announce an IPv4 netblock in BGP. The fact that the Internet runs on largely the same protocol everywhere is a very nice thing; in contrast, what is described here really would be a mess! So, well. I honestly don't think it's as easy to just do extension instead of alternative when it comes to the address spaces. We'll just need to deal with the pain and realize that upgrading the equipment and software is the larger part of the job anyway, and we'll need to do that no matter what solution we go with. Congrats on reaching 10%! Now get to work with the remaining 90%.

Today I committed a set of changes to the TeX Live subversion repository that should pave the way for better security handling in the future. Work is underway to use strong cryptographic signatures to verify that packages downloaded and installed into a TeX Live installation have not been tinkered with. While there is still a long way to go and to figure out, the current changes already improve the situation considerably. Status up to now Although we did ship size and checksum information within the TeX Live database, these information were only considered by the installer when re-starting an installation to make sure that the downloaded packages are the ones we should use. Neither the installer nor tlmgr did use the checksum to verify that the downloaded packages is correct, relying mostly on the fact that the packages are xz-compressed and would create rubbish when there is a transfer error. Although none of us believes that there is a serious interest in tinkering with the TeX Live distribution maybe to steal just another boring scientific paper? the door was still open. Changes implemented The changes committed to the repository today, which will be in a testing phase to get rid of bugs, consists of the following:

• unification of installation routines: it didn t make sense to have duplication of the actual download and unpack code in the installer and in tlmgr, so the code base was simplified and unified, and both the installer and tlmgr now use the same code paths to obtain, unpack, and install a package.
• verification of size and checksum data: hand-in-hand with the above change, verification of downloaded packages based on both the size as well as the checksum is now carried out.

Together these two changes will allow install-tl/tlmgr to verify that a package (.tar.xz) is according to the information in the accompanying texlive.tlpdb. This still leaves the option of tampering with a package and updating the texlive.tlpdb for the fixes checksums/sizes. Upcoming changes For the future we do plan mostly two things:

• switch to stronger hashing algorithm: till now we use md5, but we will switch to sha512 instead.
• GnuPG signing of the checksum file of the texlive.tlpdb, that is detached signature of texlive.tlpdb.checksum

The last step above will give a very high level of security, as it will be not practically possible to alter the information in the texlive.tlpdb, thus no tampering with the checksum information of the containers, and in turn no tampering with the actual containers will be possible. Restrictions Due to the wide range of supported architectures and operating systems, we will not make verification obligatory, but if a gpg binary is found, it will be used to verify the downloaded texlive.tlpdb.checksum. Details have to be hammered out and the actual programming has to be done, but we are on the way. Enjoy.

I have helped maintain Drupal 7.x in Debian for several years (and am now the leading maintainer). During this last year, I got a small article published in the Drupal Watchdog, where I stated:

What About Drupal 8? Now... With all the hype set in the future, it might seem striking that throughout this article I only talked about Drupal 7. This is because Debian seeks to ship only production ready software: as of this writing, Drupal 8 is still in beta. Not too long ago, we still saw internal reorganizations of its directory structure. Once Drupal 8 is released, of course, we will take care to package it. And although Drupal 8 will not be a part of Debian 8, it will be offered through the Backports archive, following all of Debian's security and stability requirements.

Time passes, and I have to take care of following what I promise. Drupal 8 was released on November 18, so I must get my act together and put it in shape for Debian! So, prompted by a mail by a fellow Debian Developer, I pushed today to Alioth the (very little) work I have so far done to this effect; every DD can now step in and help (and I guess DMs and other non-formally-affiliated contributors, but I frankly haven't really read how you can be a part of collab-maint). So, what has been done? What needs to be done? Although the code bases are massively different, I took the (un?)wise step to base off the Drupal7 packaging, and start solving Lintian problems and installation woes. So far, I have an install that looks sane (but has not yet been tested), but has lots of Lintian warnings and errors. The errors are mostly of missing sources, as Drupal8 inlines many unrelated projects (fortunately documented and frozen to known-good versions) in it; there are two possible courses of action:

1. Prefered way: Find which already made Debian package provides each of them, remove from the binary package, declare dependency.
2. Pragmatic way: As the compatibility must sometimes be to a specific version level, just provide the needed sources in debian/missing-sources

We can, of course, first go pragmatic and later start reviewing what can be safely depended upon. But for this, we need people with better PHP experience than me (which is not much to talk about). This cleanup will correspond with cleaning up the extra license file Lintian warnings, as there is one for each such project Of course, documenting each such license in debian/copyright is also a must. Anyway, there is quite a bit of work to do. And later, we have to check that things work reliably. And also, quite probably, adapt any bits of dh-make-drupal to work with v8 as well as v7 (and I am not sure if I already deprecated v6, quite probably I have). So... If you are interested in working on this, please contact me directly. If we get more than a handful, building a proper packaging team might be in place, otherwise we can just go on working as part of collab-maint. I am very short on time, so any extra hands will be most helpful!

I m organizing an event at the University of Washington in Seattle that involves a reading, the screening of a documentary film, and a Q&A about Aaron Swartz. The event coincides with the third anniversary of Aaron s death and the release of a new book of Swartz s writing that I contributed to. The event is free and open the public and details are below:

WHEN: Wednesday, January 13 at 6:30-9:30 p.m.

WHERE: Communications Building (CMU) 120, University of Washington

We invite you to celebrate the life and activism efforts of Aaron Swartz, hosted by UW Communication professor Benjamin Mako Hill. The event is next week and will consist of a short book reading, a screening of a documentary about Aaron s life, and a Q&A with Mako who knew Aaron well details are below. No RSVP required; we hope you can join us.

Aaron Swartz was a programming prodigy, entrepreneur, and information activist who contributed to the core Internet protocol RSS and co-founded Reddit, among other groundbreaking work. However, it was his efforts in social justice and political organizing combined with his aggressive approach to promoting increased access to information that entangled him in a two-year legal nightmare that ended with the taking of his own life at the age of 26.

January 11, 2016 marks the third anniversary of his death. Join us two days later for a reading from a new posthumous collection of Swartz s writing published by New Press, a showing of The Internet s Own Boy (a documentary about his life), and a Q&A with UW Communication professor Benjamin Mako Hill a former roommate and friend of Swartz and a contributor to and co-editor of the first section of the new book. If you re not in Seattle, there are events with similar programs being organized in Atlanta, Chicago, Dallas, New York, and San Francisco. All of these other events will be on Monday January 11 and registration is required for all of them. I will be speaking at the event in San Francisco.

Would you like to hike a mountain? That question caught me by surprise. It was early in 2000, and I had flown to Tucson for a job interview. Ian Murdock was starting a new company, Progeny, and I was being interviewed for their first hire. Well, I thought, hiking will be fun. So we rode a bus or something to the top of the mountain and then hiked down. Our hike was full of well, everything. Ian talked about Tucson and the mountains, about his time as the Debian project leader, about his college days. I asked about the plants and such we were walking past. We talked about the plans for Progeny, my background, how I might fit in. It was part interview, part hike, part two geeks chatting. Ian had no HR telling him you can t go hiking down a mountain with a job candidate, as I m sure HR would have. And I am glad of it, because even 16 years later, that is still by far the best time I ever had at a job interview, despite the fact that it ruined the only pair of shoes I had brought along I had foolishly brought dress shoes for a, well, job interview. I guess it worked, too, because I was hired. Ian wanted to start up the company in Indianapolis, so over the next little while there was the busy work of moving myself and setting up an office. I remember those early days Ian and I went computer shopping at a local shop more than once to get the first workstations and servers for the company. Somehow he had found a deal on some office space in a high-rent office building. I still remember the puzzlement on the faces of accountants and lawyers dressed up in suits riding in the elevators with us in our shorts and sandals, or tie-die, next to them. Progeny s story was to be a complicated one. We set out to rock the world. We didn t. We didn t set out to make lasting friendships, but we often did. We set out to accomplish great things, and we did some of that, too. We experienced a full range of emotions there elation when we got hardware auto-detection working well or when our downloads looked very popular, despair when our funding didn t come through as we had hoped, being lost when our strategy had to change multiple times. And, as is the case everywhere, none of us were perfect. I still remember the excitement after we published our first release on the Internet. Our little server that could got pegged at 100Mb of outbound bandwidth (that was something for a small company in those days.) The moment must have meant something, because I still have the mrtg chart from that day on my computer, 15 years later. We made a good Linux distribution, an excellent Debian derivative, but commercial success did not flow from it. In the succeeding months, Ian and the company tried hard to find a strategy that would stick and make our big break. But that never happened. We had several rounds of layoffs when hoped-for funding never materialized. Ian eventually lost control of the company, and despite a few years of Itanium contract work after I left, closed for good. Looking back, Progeny was life compressed. During the good times, we had joy, sense of accomplishment, a sense of purpose at doing something well that was worth doing. I had what was my dream job back then: working on Debian as I loved to do, making the world a better place through Free Software, and getting paid to do it. And during the bad times, different people at Progeny experienced anger, cynicism, apathy, sorrow for the loss of our friends or plans, or simply a feeling to soldier on. All of the emotions, good or bad, were warranted in their own way. Bruce Byfield, one of my co-workers at Progeny, recently wrote a wonderful memoriam of Ian. He wrote, More than anything, he wanted to repeat his accomplishment with Debian, and, naturally he wondered if he could live up to his own expectations of himself. That, I think, was Ian s personal tragedy that he had succeeded early in life, and nothing else he did with his life could quite measure up to his expectations and memories. Ian was not the only one to have some guilt over Progeny. I, for years, wondered if I should have done more for the company, could have saved things by doing something more, or different. But I always came back to the conclusion I had at the time: that there was nothing I could do a terribly sad realization. In the years since, I watched Ubuntu take the mantle of easy-to-install Debian derivative. I saw them reprise some of the ideas we had, and even some of our mistakes. But by that time, Progeny was so thoroughly forgotten that I doubt they even realized they were doing it. I had long looked at our work at Progeny as a failure. Our main goal was never accomplished, our big product never sold many copies, our company eventually shuttered, our rock-the-world plan crumpled and forgotten. And by those traditional measurements, you could say it was a failure. But I have come to learn in the years since that success is a lot more that those things. Success is also about finding meaning and purpose through our work. As a programmer, success is nailing that algorithm that lets the application scale 10x more than before, or solving that difficult problem. As a manager, success is helping team members thrive, watching pieces come together on projects that no one person could ever do themselves. And as a person, success comes from learning from our experiences, and especially our mistakes. As J. Michael Straczynski wrote in a Babylon 5 episode, loosely paraphrased: Maybe this experience will be a good lesson. Too bad it was so painful, but there ain t no other kind. The thing about Progeny is this Ian built a group of people that wanted to change the world for the better. We gave it our all. And there s nothing wrong with that. Progeny did change the world. As us Progeny alumni have scattered around the country, we benefit from the lessons we learned there. And many of us were different , sort of out of place before Progeny, and there we found others that loved C compilers, bootloaders, and GPL licenses just as much as we did. We belonged, not just online but in life, and we went on to pull confidence and skill out of our experience at Progeny and use them in all sorts of ways over the years. And so did Ian. Who could have imagined the founder of Debian and Progeny would one day lead the cause of an old-guard Unix turning Open Source? I run ZFS on my Debian system today, and Ian is partly responsible for that and his time at Progeny is too. So I can remember Ian, and Progeny, as a success. And I leave you with a photo of my best memento from the time there: an original unopened boxed copy of Progeny Linux.

This version 0.1 of Twitterwatch is dedicated to Ian Murdock, Debian project Founder. If you use an automated system like Feed2tweet in order to feed your Twitter account from your website of any RSS feed, it is of the utmost important to know when this system is broken, because you are losing traffic because of this malfunction. At the Journal du hacker, a French-speaking FOSS website where people contribute weblinks like Hacker News or Lobste.rs, every new contribution is sent through the RSS feed to the Twitter account of the Journal du hacker. A lot of our readers only follow the news on Twitter. So if the link breaks, our readers are not fed any more :) To be alerted to this issue, I wrote a small self hosted and documented app. I m proud to introduce Twitterwatch !

• Twitterwatch on Github (stars appreciated :) )
• The official documentation about Twitterwatch on Readthedocs

It runs with Python 3.4 and the Tweepy library. You can install it from PyPI or from sources. The documentation is available on Readthedocs. You can read about how to install it, configure it and use it. It s the first release but the main features do the job already. In order to use it, you need a twitterwatch.ini file as following:

[twitter]
consumer_key=ml6jaiBnf3pkU9uIrKNIxAr3o
consumer_secret=4Cmljklzerkhfer4hlj3ljl2hfvc123rezrfsdatpokaelzerp
access_token=213416790-jgJnrJG5gz132nzerl5zerwi1ahmnwkfJFN9nr2j
access_token_secret=WjanlPgqDKlunJ4Knr11k2bnfk3jfnwkFjeriFZERj16Z

[schedule]
; duration between 2 checks in minutes
check_interval=60

[mail]
host=localhost
from=admin@myserver.org
to=foo@mylaptop.org

The most difficult part is now complete. To launch Twitterwatch, just launch the following command:

$ twitterwatch /path/to/twitterwatch.ini

Whenever no more new tweet is sent from your Twitter account during 60 minutes, you ll receive the following mail (here the user is @journalduhacker):

Title: Twitter stream of journalduhacker has stopped
Body: Twitter stream of journalduhacker has stopped since 23/12/2015 - 14:49:23

It is still pretty rough, but it does the job. New features will come whenever I need them (or if you require/open bugs/submit push requests ;) ). Write a comment to tell me what you think of it or why you use it!

& another round of RC bug fixes, still related to the perl 5.22 transition (& yay, 5.22 is in testing since some days!):

• #808209 amanda-common: "amanda-common: Depends on virtual package "perl5" which will is gone with perl/5.22"
  replace perl5 dependencies, NMU with maintainer's approval
• #808321 votca-csg-scripts: "votca-csg-scripts: Depends on virtual package "perl5" which will is gone with perl/5.22"
  fix dependency, upload to DELAYED/3
• #809192 src:libterm-termkey-perl: "libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11"
  set TERM for tests (pkg-perl)
• #809198 maildirsync: "maildirsync broken with perl 5.22"
  add upstream patch, upload to DELAYED/3
• #809583 src:libgenome-model-tools-music-perl: "libgenome-model-tools-music-perl: FTBFS: use Genome::Model::Tools::Music::Survival': Can't use 'defined(@array)"
  fix 'defined(@array)' error (pkg-perl)

As I posted earlier, I have migrated to use tor on my machine. Though I had a couple of unsolved issues back then. One of them being my Mail Transport Agent (MTA) did not support tor. A regular user might not have a lot of use for a MTA on their laptop. However, it is needed for a lot of Debian development scripts (bts, mass-bug, nmudiff), if they are to file/manipulate bugs for you. I have some requirements for my MTA

• tor support (or at least torsocks -able)
• support end-to-end encryption with my provider (STARTTLS)
• verify that it is talking to my provider.
• rewrite my From if it is not correct (otherwise the mail will just be rejected)
• support the auth mechanisms of my provider
• it should be simple to configure

I also have some non-requirements:

• Local mail delivery is not required
• The MTA will not be used as a general mail relay.
  • One target relay
  • No relaying from other hosts
• Mail delivery queue is nice to have but not a strict requirement.

Originally, I used postfix, which supported most of these requirements. Except:

• My attempt to make it use tor failed. The best suggestion I found was to divert its smtp handler and then replace it with a torsocks call to the original handler. Sadly, it just seg. faulted.
• While postfix is almost certainly able to verify it is talking with my provider, I never got it configured to do that. In the end, postfix was to complicated for what I was ready to put up with.

Per suggestion of Jakub Wilk, I tried msmtp, which turned out do what I wanted.

• There is a trivial config file example to start with. I did not need to read any manuals or extended documentation to figure out what they were doing.
• You probably also want to specify tls_priorities (assuming msmtp is linked against gnutls)
  • A code dive suggests it defaults to NORMAL:-VERS-SSL3.0 if not set. It is probably not too bad, but could be better. :)
    
  • From a quick look at the gnutls manual PFS:%PROFILE_<name> seems like decent value (requires gnutls >= 3.2.4 and that your provider has decent/modern SSL setup).
  • You probably want to have a look at the values for the %PROFILE_<name> before deciding on one.
• The msmtp program supports connecting through SOCKS proxies and even has a sample config snippet for using it with tor.
  • Of course, by the time I had discovered that I had already been using torsocks /usr/sbin/sendmail a couple of times. :)

The only feature I will probably miss is having a local queue, which can be rate limited. But all in all, I am quite happy with it so far. :)
Filed under: Debian

Now that I've fixed the major test suite problems with podlators, failure reports are now (mostly) useful. There's still the occasional failure to create a directory for temporary files, which I think is just a problem with the testing system, but Windows test failures revealed an actual test suite bug. This release also merges the changes made for merging podlators into blead Perl, which were relatively minor, and changes the package metadata to point to GitHub as the repository. That seems to be the growing convention in the Perl community and makes it easier for people to submit pull requests. I'm still maintaining my own public repository, but Git makes it easy to replicate things in multiple places. (Bug tracking will remain in the CPAN RT.) You can get the latest release from the podlators distribution page.

I just finished going through my last set of pending-review pictures from 2015, so I'm starting 2016 with a post about the past. In June 2015 I travelled to Seattle/Kirkland area for work purposes, and took advantage of a weekend to plan some more outdoors stuff. After looking around on maps, I settled on the San Juan islands, so I started looking at hiking possibilities, and in the end Orcas island looked the best choice - all the others had much lower elevations. So, early in the morning, I started driving from Kirkland to Anacortes ferry terminal. The drive itself is quite nice: after getting past the more populated areas, passing Everett, the the view are very nice, especially in the early morning hours and with very few traffic. At Anacortes, there was already a small queue, fortunately I had a pre-ordered ticket, and there was not much to do until the ferry arrived except to look forward at the day, and hope that the weather will stay nice. On the ferry then, crossing the straits and enjoying the very nice views: The ferry stops at Orcas (is it a town or just the terminal), and the next stop is Eastsound town. I pre-planned here a stop to get a second mini-breakfast: however, I misjudged what the portion sizes are and got myself a maxi-cinnamon roll at Caffe Olga: At least I knew I wasn't going to be hungry for a while Driving on, briefly stopping at Cascade Lake (I also stopped on the way back, the view is nice), then reaching the parking at the Twin Lakes trail on the shore of Mountain Lake. Good think I arrived somewhat early the parking was quite full already. I also got a bit confused on which way the hike starts, since it's not well marked, but after that I started the hike. It's also possible to drive up to Mount Constitution, but that's just lame; hiking from the base it's quite easy, if you find how to start the hike. Anyway: At one point, one meets this particular sign: Beware the Little Summit is not to be missed! After ~40 minutes of hiking, with some parts a tiny bit strenuous, the view is really breathtaking. It's definitely worth stopping by, as the view is (IMHO) nicer than the view from the top of Mt. Constitution: The reason I say this is better is because you look towards ocean, whereas later the view is back towards the continent. And looking towards the big ocean is just perfect! Plus, the many small island, fully covered with forest are also nice. Onwards then towards the peak of Mount Constitution. You cross the "ridge" of the island, and your view shifts to the other side. Which means you see back to the Mountain Lake where the hike starts: Here the path is more exposed, not through tall forest like at the beginning: Right before reaching the peak, you pass through an interesting forest: And then you're finally reaching the peak. Compared to Switzerland, it's very much not impressive (730m), but nevertheless, being so close to the ocean results in some very nice views: You can go into the small tower, and read through the history of the location, including the personal life of Robert Moran (shipbuilder), who retired in 1905 to Orcas island to live what (his doctors said to be) his last months, and who instead ended living until 1943. Not bad! To be filled under "too much stress is bad, nature is good" heading, I think. After eating a small packed lunch, I started back. At the beginning the forest is similar to the one back at the beginning of the hike, but then, as you reach the level of lakes, it is slightly different. More tall (old?) trees, more moss and ferns: I passed briefly by the Twin Lakes, which were interesting (lots of submerged trunks), and then finally on the Twin Lakes trail back to the start. The views of Mountain Lake from here are also nice, especially in the less harsh afternoon sun: And then the hike was over. I still had some time to spend before the ferry I had a ticket on was scheduled, so I drove down to Olga town, as I was curious what was at the end of "Olga Road". Not much, but again nice views, and this very picturesque pier: And then it was back to the ferry, waiting in line, getting on the ferry, and crossing back: Overall, it was a day well spent, part different, part similar to last year's mostly road trip. Definitely recommended if you're in the area, and there are a couple of other hikes on Orcas Island, plus all the other islands which make up the San Juans. However, traffic on the way back was not that awesome Small price though!

At LibrePlanet 2015 (the FSF s annual conference), I gave a talk called Access Without Empowerment as one of the conference keynote addresses. As I did for my 2013 LibrePlanet talk, I ve edited together a version that includes the slides and I ve posted it online in WebM and on YouTube. Here s the summary written up in the LibrePlanet program:

The free software movement has twin goals: promoting access to software through users freedom to share, and empowering users by giving them control over their technology. For all our movement s success, we have been much more successful at the former. I will use data from free software and from several related movements to explain why promoting empowerment is systematically more difficult than promoting access and I will explore how our movement might address the second challenge in the future.

In related news, registration is open for LibrePlanet 2016 and that it s free for FSF members. If you re not an FSF member, the FSF annual fundraiser is currently going on so now would be a great time to join.