Unless you ve been living under a firewalled rock, you know that IPv6 is coming. There s also a good chance that you ve heard that IPv6 doesn t have NAT. Or, if you pay close attention to the minutiae of IPv6 development, you ve heard that IPv6 does have NAT, but you don t have to (and shouldn t) use it. So let s say we ll skip NAT for IPv6. Fair enough. However, let s say you have this use case:

1. A bunch of containers that need Internet access
2. That are running in a VM
3. On your laptop
4. Behind your home router!

For IPv4, you d just layer on the NAT, right? While SIP and IPsec might have kittens trying to work through three layers of NAT, for most things it ll Just Work. In the Grand Future of IPv6, without NAT, how the hell do you make that happen? The answer is Prefix Delegation , which allows routers to delegate management of a chunk of address space to downstream routers, and allow those downstream routers to, in turn, delegate pieces of that chunk to downstream routers. In the case of our not-so-hypothetical containers-in-VM-on-laptop-at-home scenario, it would look like this:

1. My border router (a DNS-323 running Debian) asks my ISP for a delegated prefix, using DHCPv6. The ISP delegates a /56¹. One /64 out of that is allocated to the network directly attached to the internal interface, and the rest goes into the pool , as /60 blocks (so I ve got 15 of them to delegate, if required).
2. My laptop gets an address on the LAN between itself and the DNS-323 via stateless auto-addressing ( SLAAC ). It also uses DHCPv6 to request one of the /60 blocks from the DNS-323. The laptop puts one /64 from that block as the address space for the virtual LAN (actually a Linux bridge) that connects the laptop to all my VMs, and puts the other 15 /64 blocks into a pool for delegation.
3. The VM that will be running the set of containers under test gets an address on the all VMs virtual LAN via SLAAC, and then requests a delegated /64 to use for the all containers virtual LAN (another bridge, this one running on the VM itself) that the containers will each connect to themselves.

Now, almost all of this Just Works. The current releases of ISC DHCP support prefix delegation just fine, and a bit of shell script plumbing between the client and server seals the deal the client needs to rewrite the server s config file to tell it the netblock from which it can delegate. Except for one teensy, tiny problem routing. When the DHCP server delegates a netblock to a particular machine, the routing table needs to get updated so that packets going to that netblock actually get sent to the machine the netblock was delegated to. Without that, traffic destined for the containers (or the VM) won t actually make it to its destination, and a one-way Internet connection isn t a whole lot of use. I cannot understand why this problem hasn t been tripped over before. It s absolutely fundamental to the correct operation of the delegation system. Some people advocate running a dynamic routing protocol, but that s a sledgehammer to crack a nut if ever I saw one. Actually, I know this problem has been tripped over before, by OpenWrt. Their solution, however, was to use a PHP script to scan logfiles and add routes. Suffice it to say, that wasn t an option I was keen on exploring. Instead, I decided to patch ISC DHCP so that the server can run an external script to add the necessary routes, and perhaps modify firewall rules and also to reverse the process when the delegation is released (or expired). If anyone else wants to play around with it, I ve put it up on Github. I don t make any promises that it s the right way to do it, necessarily, but it works, and the script I ve added in contrib/prefix-delegation-routing.rb shows how it can be used to good effect. By the way, if anyone knows how pull requests work over at ISC, drop me a line. From the look of their website, they don t appear to accept (or at least encourage) external contributions. So, that s one small patch for DHCP, one giant leap for my home network.

I originally posted this in a thread on debian-private, but on further reflection it seems appropriate for a broader audience. So I'm posting it here, as well as on debian-project. There is quite a lot of discussion in various places about what the recent GR result means. Some are concluding that systemd won in some way that implies Debian is not going to support other init systems, or at least that support for other init systems is in immediate danger. A lot of that analysis concludes that the pro-systemd "side" in Debian won some sort of conclusive victory. I have a different perspective. I think we just had a GR in which the Debian developer community said that we, as a community, would like to work through all of the issues around init systems together, as a community, rather than having any one side of the argument win unambiguously and impose its views on those who disagree. There were options on the ballot that clearly required loose coupling and that clearly required tight coupling. The top two options did neither of those things. The second-highest option said, effectively, that we should feel free to exercise our technical judgement for our own packages, but should do so with an eye to enabling people to make different choices, and should merge their changes and contributions where possible. The highest option said that we don't even want to say that, and would instead prefer to work this whole thing out through discussion, respect, consensus, and mutual support, without giving *anyone* a clear mandate or project-wide blessing for their approach. In other words, the way I choose to look at this GR is that the project as a whole just voted to take away the sticks that we were using to beat each other with. In a way, we just chose the *hardest* option. We didn't make a simplifying technical decision that provides clear guidance to everyone. Instead, we made a complicating social decision that says that, sorry, there's no short cut to avoid having to talk to each other, respect each other's views, and try to reach workable collaborative compromises. Even though it's really hard, even though everyone is raw and upset, that's what the project as a whole is asking us to do. Are we up to the challenge?

There s many ways to interpret the last GR. The way I see it is how Joey hoped Debian was: the outcome of the poll shows that we don t want to do technical decisions by voting. At the beginning of this GR, I was supportive of it, and though it was a good thing to enforce the rule that we care for non-systemd setups. Though I have slowly changed my mind. I still think it was a good idea to see what the community thought after a so long debate. I now think that this final outcome is awesome and couldn t have been better. Science (and computer science) has never been about voting, otherwise the earth would be flat, without drifting continents. So my hope is that the Debian project as a whole, will allow itself to do mistakes, iterative trials, errors, and go back on any technical decision if they don t make sense anymore. When being asked something, it s ok to reply: I don t know , and it should be ok for the Debian project to have this alternative as one of the possible answers. I m convince that refusing to take a drastic choice in this point in time was exactly what we needed to do. And my hope is that Joey comes back after he realizes that we ve all understood and embarrassed his position that science cannot be governed by polls. For Stretch, I m sure there s going to be a lot of new alternatives. Maybe uselessd, eudev and others. Maybe I ll have a bit of time to work on OpenRC Debian integration myself (hum I m dreaming here ). Maybe something else. Let s just wait. We have more than 300 bugs to fix before Jessie can be released. Let s happilly work on that together, and forget about the init systems for a while P.S: Just to be on the safe side: the rotten tomatoes image was not about criticizing the persons who started the poll, who I respect a lot, especially Ian, who I am convinced is trying to do his best for Debian (hug).

I'm changing jobs! From February 2015, I will be joining Red Hat as a Senior Software Engineer. I'll be based in Newcastle and working with the Middleware team. I'm going to be working with virtualisation, containers and Docker in particular. I know a few of the folks in the Newcastle office already, thanks to their relationship with the School of Computing Science, and I'm very excited to work with them, as well as the wider company. It's also going to be great to be contributing to the free software community as part of my day job. This October marked my tenth year working for Newcastle University. I've had a great time, learned a huge amount, and made some great friends. It's going to be sad to leave, especially the School of Computing Science where I've spent the last four years, but it's the right time to move on, It's an area that I've been personally interested in for a long time and I'm very excited to be trying something new.

A teacher in New York was teaching her class about bullying and gave them the following exercise to perform. She had the children take a piece of paper and told them to crumple it up, stamp on it and really mess it up but do not rip it. Then she had them unfold the paper, smooth it out and look at how scarred and dirty is was. She then told them to tell it they re sorry. Now even though they said they were sorry and tried to fix the paper, she pointed out all the scars they left behind. And that those scars will never go away no matter how hard they tried to fix it. That is what happens when a child bullies another child, they may say they re sorry but the scars are there forever. The looks on the faces of the children in the classroom told her the message hit home. ( Source: http://www.buzzfeed.com/mjs538/awesome-bullying-lesson-from-a-new-york-teacher )

Another PSA: something surprising about XML. As you might all know, XML must be valid UTF-8 (or UTF-16 (or another encoding supported by the parser, but one which yields valid Unicode codepoints when read and converted)). Some characters, such as the ampersand & , must be escaped ( &#38; or &#x26; , although &amp; may also work, depending on the domain) or put into a CDATA section ( <![CDATA[&]]> ). A bit surprisingly, a literal backspace character (ASCII 08h, Unicode U+0008) is not allowed in the text. I filed a bugreport against libxml2, asking it to please encode these characters. A bit more research followed. Surprisingly, there are characters that are not valid in XML documents in any way, not even as entities or in CDATA sections. (xmlstarlet, by the way, errors out somewhat nicely for an unescaped literal or entity-escaped backspace, but behaves absolutely hilarious for a literal backspace in a CDATA section.) Basically, XML contains a whitelist for the following Unicode codepoints:

• U+0009
• U+000A
• U+000D
• U+0020 U+D7FF
• U+E000 U+FFFD
• U-00010000 U-0010FFFF

Additionally, a certain number of codepoints is discouraged: U+007F U+0084 (IMHO wise), U+0086 U+009F (also wise, but why allow U+0085?), U+FDD0 U+FDEF (a bit surprisingly, but consistent with disallowing the backspace character), and the last two codepoints of every plane (U+FFFE and U+FFFF were already disallowed, but U-0001FFFE, U-0001FFFF, , U-0010FFFF weren t; this is extremely wise). The suggestion seems to be to just strip these characters silently from the XML document . I m a bit miffed about this, as I don t even use XML directly (I m extending a PHP webapplication that is a SOAP client and talks to a Java SOAP-WS) and would expect this to preserve my strings, but, oh my. I ve forwarded the suggestion to just strip them silently to the libxml2 maintainers in the aforementioned bug report, for now, and may even hack that myself (on customer-paid time). More robust than hacking the PHP thingy to strip them first, anyway I ve got no control over the XML after all. Sharing this so that more people know that not all UTF-8 is valid in XML. Maybe it saves someone else some time. (Now wondering whether to address this in my xhtml_escape shell function. Probably should. Meh.)

Apparently (the actual results have not yet been published by the Secretary), the GR is over, and the worst possible option has won. This is an absolutely ambiguous result, while at the same time sending a clear signal that Debian is not to be trusted wrt. investing anything into it, right now. Why is this? Simply: GR not required means that whatever people do is probably right . Besides this, we have one statement from the CTTE ( systemd is default init system for jessie. Period. ) and nothing else. This means that runit, or upstart, or file-rc, or uselessd, can be the default init system for zurg^H^H^H^Hstretch, or even the only one. It also means that the vast majority of Debian Developers are sheeple, neither clearly voting to preserve freedom of choice between init systems for its users, nor clearly voting to unambiguously support systemd and progress over compatibility and choice, nor clearly stating that systemd is important but supporting other init systems is still recommended. (I ll not go into detail on how the proposer of the apparently winning choice recommends others to ignore ftpmaster constraints and licences, and even suggests to run a GR to soften up the DFSG interpretation.) I d have voted this as no, absolutely not if it was possible to do so more strongly. Judging from the statistics, the only thing I voted above NOTA/FD is the one least accepted by DDs, although the only other proposal I considered is the first-rated of them: support for other init systems is recommended but not required. What made me vote it below NOTA/FD was: The Debian Project makes no statement at this time on sysvinit support beyond the jessie release. This sentence made even this proposal unbearable, unacceptable, for people wanting to invest (time, money, etc.) into Debian. Update: Formal result announced. So 358 out of 483 voting DDs decided to be sheeple (if I understand the eMail correctly). We had 1006 DDs with voting rights, which is a bit ashaming as well. That s 48.01% only. I wonder what s worse. This opens up a very hard problem: I m absolutely stunned by this and wondering what to do now. While there is no real alternative to Debian at $dayjob I can always create customised packages in my own APT repository, and while it was great when those were eventually (3.1.17-1) accepted into Debian, even replacing the previous packages completely it is simpler and quicker to not do so. While $dayjob benefits from having packages I work on inside Debian itself, even though I cannot always test all scenarios Debian users would need, some work reduction due to reactions already led to Debian losing out on Mediawiki for jessie and some additional suffering. With my own package repository, I can modulo installing/debootstrap serve my needs for $dayjob much quicker, easily, etc. and only miss out on absolutely delightful user feedback. But then, others could always package software I m upstream of for Debian. Or, if I do not leave the project, continue doing so via QA uploads. I m also disappointed because I have invested quite some effort into trying to make Debian better (my idea to join as DD was if I ve got to use it, it better be damn good! ), into packaging software and convincing people at work that developing software as Debian packages instead of (or not) thinking of packaging later was good. I ve converted our versions of FusionForge and d-push to Debian packages, and it works pretty damn well. Sometimes it needs backports of my own, but that s the corportate world, and no problem to an experienced DD. (I just feel bad we ($orkplace) lost some people, an FTP master along them, before this really gained traction.) I d convert to OpenBSD because, despite MirBSD s history with them, they re the only technically sound alternative, but apparently tedu (whom I respect technically, and who used to offer good advice to even me when asked, and who I think wouldn t choose systemd himself) still (allying with the systemd side (I m not against people being able to choose systemd, for the record, I just don t want to be forced into it myself!)) has some sort of grudge against me. Plus, it d be hard to get customers to follow. So, no alternative right now. But I m used to managing my own forks of software; I m doomed to basically hack and fix anything I use (I recently got someone who owns a licence to an old-enough Visual Studio version to transfer that to me, so I can hack on the Windows Mobile 6 version of Cachebox, to fix bugs in one of the geocaching applications I use. Now I just need to learn C# and the .NET Compact Framework. So I m also used to some amount of pain.) I m still unresolved wrt. the attitude I should show the Debian project now. I had decided to just continue to live on, and work on the things I need done, but that was before this GR non-result. I absolutely cannot recommend anyone to invest into Debian (without sounding hypocriet), but I cannot recommend anything else either. I cannot justify leaving but don t know if I want to stay. I think I should sleep over it. One thing I promised, and thus will do, is to organise a meeting of the Debian/m68k people soonish. But then, major and important and powerful forces inside Debian still insist that Debian-Ports are not part of it [Update: yes, DSA is moving it closer, thanks for that by the way, but that doesn t mean anything to certain maintainers or the Release Team, although, the latter is actually understandable and probably sensible.] yet, all forks of Debian now suffer from the systemd adoption in it instead of having a freedom-of-choice upstream. I ve said, and I still feel that systemd adoption should have done in a Debian downstream / (pure?) blend, and maybe (parts of) GNOME removed from Debian itself for it. (Adding cgroups support to the m68k kernel to support systemd was done. I adviced against it, on the grounds of memory and code size. But no downstream can remove it now.)

Actually I was working already on a different music blog entry, but I want to get this one out. I was invited to join the Organic Dancefloor last thursday. And it was a really great experience. A lot of nice people enjoying a dance evening of sort of improvisational traditional folk dancing with influences from different parts of europe. Three bands playing throughout the evening. I definitely plan to go there again. :) Which brings me to the band I want to present you now. They also play sort-of traditional songs, or at least with traditional instruments, and are also quite danceable to. This is about The Pogues. And these are the songs that I do enjoy listening to every now and then:

• Medley: Don't meddle with the Medley. Rather dance to it.
• Fairytale of New York: Well, we're almost in the season for it. :)
• Streams of Whiskey: Also quite the style of song that they are known for and party with at concerts.

Like always, enjoy!

/music permanent link Comments: 2 Flattr this

Make sure bug metadata is accurate We use the metadata on the bugs you claim to have closed, as well as reading the bug report itself. You can help us out with severities, tags (e.g. blocks), and version information. Don t fall into the trap of believing that an unblock is a green light into Jessie. Britney still follows her validity rules, so if an RC bug appears to affect the unblocked version, it won t migrate. Versions matter, not only the bug state (closed or open).

---

Getting things into Jessie (#4) is a post from: jwiltshire.org.uk Flattr

The result for the General Resolution about the init system coupling is out and the result is, not quite surprisingly, General Resolution is not required . When skimming over -devel or -private from time to time, one easily gets the impression that we are all a bunch of zealots, all too eager for fighting. People argue in the worst possible ways. People make bold statements about the future of Debian if solution X is preferred over Y. People call each other names. People leave the project. At some point you realize, we re not all a bunch of zealots, it is usually only the same small subset of people always involved in those discussions. It s reassuring that we still seem to have a silent majority in Debian that, without much fuss, just do what they can to make Debian better. In this sense: A General Resolution is not required.

Earlier today, Josh send the text below to the R-SIG-Finance list, and I updated the R/Finance website, including its Call for Papers page, accordingly. We are once again very excited about our conference, thrilled about the four confirmed keynotes, and hope that many R / Finance users will not only join us in Chicago in May 2015 -- but also submit an exciting proposal. So read on below, and see you in Chicago in May! Call for Papers: R/Finance 2015: Applied Finance with R
May 29 and 30, 2015
University of Illinois at Chicago, IL, USA
The seventh annual R/Finance conference for applied finance using R will be held on May 29 and 30, 2015 in Chicago, IL, USA at the University of Illinois at Chicago. The conference will cover topics including portfolio management, time series analysis, advanced risk tools, high-performance computing, market microstructure, and econometrics. All will be discussed within the context of using R as a primary tool for financial risk management, portfolio construction, and trading. Over the past six years, R/Finance has included attendees from around the world. It has featured presentations from prominent academics and practitioners, and we anticipate another exciting line-up for 2015. This year will include invited keynote presentations by Emanuel Derman, Louis Marascio, Alexander McNeil, and Rishi Narang. We invite you to submit complete papers in pdf format for consideration. We will also consider one-page abstracts (in txt or pdf format) although more complete papers are preferred. We welcome submissions for both full talks and abbreviated "lightning talks." Both academic and practitioner proposals related to R are encouraged. All slides will be made publicly available at conference time. Presenters are strongly encouraged to provide working R code to accompany the slides. Data sets should also be made public for the purposes of reproducibility (though we realize this may be limited due to contracts with data vendors). Preference may be given to presenters who have released R packages. The conference will award two (or more) $1000 prizes for best papers. A submission must be a full paper to be eligible for a best paper award. Extended abstracts, even if a full paper is provided by conference time, are not eligible for a best paper award. Financial assistance for travel and accommodation may be available to presenters, however requests must be made at the time of submission. Assistance will be granted at the discretion of the conference committee. Please make your submission online at this link. The submission deadline is January 31, 2015. Submitters will be notified via email by February 28, 2015 of acceptance, presentation length, and financial assistance (if requested). Additional details will be announced via the R/Finance conference website as they become available. Information on previous years' presenters and their presentations are also at the conference website. For the program committee:

Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson, Dale Rosenthal,
Jeffrey Ryan, Joshua Ulrich

Debian's latest round of angry mailing list threads have been about some combination of init systems, future direction and project governance. The details aren't particularly important here, and pretty much everything worthwhile in favour of or against each position has already been said several times, but I think this bit is important enough that it bears repeating: the reason I voted "we didn't need this General Resolution" ahead of the other options is that I hope we can continue to use our normal technical and decision-making processes to make Debian 8 the best possible OS distribution for everyone. That includes people who like systemd, people who dislike systemd, people who don't care either way and just want the OS to work, and everyone in between those extremes. I think that works best when we do things, and least well when a lot of time and energy get diverted into talking about doing things. I've been trying to do my small part of the former by fixing some release-critical bugs so we can release Debian 8. Please join in, and remember to write good unblock requests so our hard-working release team can get through them in a finite time. I realise not everyone will agree with my idea of which bugs, which features and which combinations of packages are highest-priority; that's fine, there are plenty of bugs to go round! Regarding init systems specifically, Debian 'jessie' currently works with at least systemd-sysv or sysvinit-core as pid 1 (probably also Upstart, but I haven't tried that) and I'm confident that Debian developers won't let either of those regress before it's released as Debian 8. I expect the freeze for Debian 'stretch' (presumably Debian 9) to be a couple of years away, so it seems premature to say anything about what will or won't be supported there; that depends on what upstream developers do, and what Debian developers do, between now and then. What I can predict is that the components that get useful bug reports, active maintenance, thorough testing, careful review, and similar help from contributors will work better than the things that don't; so if you like a component and want it to be supported in Debian, you can help by, well, supporting it.

---

PS. If you want the Debian 8 installer to leave you running sysvinit as pid 1 after the first reboot, here's a suitable incantation to add to the kernel command-line in the installer's bootloader. This one certainly worked when KiBi asked for testing a few days ago:

preseed/late_command="in-target apt-get install -y sysvinit-core"

I think that corresponds to this line in a preseeding file, if you use those:

d-i preseed/late_command string in-target apt-get install -y sysvinit-core

A similar apt-get command, without the in-target prefix, should work on an installed system that already has systemd-sysv. Depending on other installed software, you might need to add systemd-shim to the command line too, but when I tried it, apt-get was able to work that out for itself. If you use aptitude instead of apt-get, double-check what it will do before saying "yes" to this particular switchover: its heuristic for resolving conflicts seems to be rather more trigger-happy about removing packages than the one in apt-get.

Some days I feel super lazy but I still would like to go on contributing translations to Debian.
Then, I leave the web translations a bit, and change to translate or review Debian package descriptions. It s something that anybody can do without any knowledge of translation tools, since it is a very simple web interface, as you will see. First you need to create a login account, then, login into the system. And then, go to the page of your mother language (in my case, Spanish, es ). You will see some introductory text, and the list of pending translations:

At the end of the page, there is the list of translations pending to review:
We should begin with this, so the work that other people already made arrives quickly its destination. And it s the easiest part, as you will see. Let s pick one of them (libvformat1-dev):
You see the short description in the original English, and the current translation (if there were changes from a former version, they are coloured too). I didn t know what the package libvformat1-dev does, but here s a nice opportunity to learn aobut it a bit :) The short description looks ok for me. Let s go on to the long description: It also looks correct for me. So I leave the text box as is, and go on until the bottom of the page:

and click Accept as is . That s all!! The system brings you back to the page with pending translations and reviews. Let s pick another one: totem

I found a typo and corrected some other words, so I updated the text in the translation box, left a message to the other translators in the comment box, and clicked Accept with changes . And iterate. When 3 translators agree in a translation, it becomes official, and its propagated to apt-cache, aptitude, synaptic, etc., and the website (packages.debian.org). This is the most difficult part (to get 3 reviews for each package description): many language teams are small, and their workforce is spread in many fronts: translations for the website, news and announcements, debconf templates (the messages that are shown to the user when a package is installed), the Debian installer, the documentation, the package descriptions So your help (even when you only review some translations from time to time) will be appreciated, for sure.
Filed under: Tools Tagged: Contributing to libre software, Debian, English, translations

Martin Pitt reported Debian bug #770000 on Tuesday November 18th, against the release.debian.org pseudo-package. Bug #760000 was reported as of August 30th: so there have been 10,000 bugs reported in 3 months minus 12 days. The bug rate increased quite significantly during the last weeks. We can suspect this is related to the release and the freeze (that triggers many unblock requests) I find it interesting that this bug is directly related to the release, directly related to systemd and originated from one of the systemd packages maintainers, if I'm right. So, I'll take this opportunity to publicly thank all people who have brought the systemd packages to what they are now, whether or not they're still maintaining the package. We've all witnessed that Debian if facing a strong social issue nowadays and I'm very deeply sad about this. I hope we'll be able to go through this without losing too many brilliant contributors, as it happened recently. Please prove me right and do The Right Thing for me to be able to continue this silly "round bug number" contest and still believe that, some day, bug #1000000 will really happen and I'm still there to witness it. Ah, and by the way, systemd bloody works on my system. I can't even remember when I switched to it. It Just Worked.

Weblate has started as a translation system tightly bound to Git version control system. This was in no means design decision, but rather it was the version control I've used. But this has shown not to be sufficient and other systems were requested as well. And Mercurial is first of them to be supported. Weblate 2.0 already had separated VCS layer and adding another system to that is quite easy if you know the VCS you're adding. Unfortunately this wasn't the case for me with Mercurial as I've never used it for anything more serious than cloning a repository, committing fixes and pushing it back. Weblate needs a bit more than that, especially in regard to remote branches. But nevertheless I've figured out all operations and the implementation is ready in our Git. In case somebody is interested in adding support for another version control, patches are always welcome!

Filed under: English phpMyAdmin SUSE Weblate 0 comments Flattr this!

Hours after the initial blog post announcing the first release of the new package RcppAnnoy, Qiang Kou sent us a very nice pull request adding mmap support in Windows. So a new release with Windows support is on now CRAN, and Windows binaries should be available by this evening as usual. To recap, RcppAnnoy wraps the small, fast, and lightweight C++ template header library Annoy written by Erik Bernhardsson for use at Spotify. RcppAnnoy uses Rcpp Modules to offer the exact same functionality as the Python module wrapped around Annoy. Courtesy of CRANberries, there is also a diffstat report for this release. More detailed information is on the RcppAnnoy page page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Make sure everything you ve changed is in the changelog We do read the diffs in detail, and if there s no explanation for something that s changed we ll ask. We also expect it to be in the changelog. Do save some round-trips by making sure your changelog is in order. One round-trip about your package is an inconvenience; when it s scaled up to the number of requests we receive, it s a serious time-sink for us.

---

Getting things into Jessie (#3) is a post from: jwiltshire.org.uk Flattr

Disclaimer: I m not used to writing personal stuff on Debian channels. However, there is nothing new here for those who know me from other public channels.


Yesterday, I received the weirdest email from well-known troll MikeeUSA. He thought I shared his views of a horrible world full of bloodthirsty feminists using systemd in their quest for domination over poor white male heterosexuals. The most nauseating paragraph was probably the one where he showed signs of the mentality of a pedocriminal.

At first, I shrugged it off and sent him an email explaining I didn t want anything with his stinky white male supremacist theories, assorted with a bit of taunting. But after discovering all that stuff was actually sent to public mailing lists, I took the time for a second look and started a bit of introspection.

MikeeUSA thought I was a white male supremacist because of the so-called SmellyWerewolf incident, 6 years ago.
Oh boy, people change in six years. Upon re-reading that, I had trouble admitting I was the one to write it. Memory is selective, and with time, you tend not to remember some gruesome details, especially the ones that conflict most with your moral values.

I can assure every reader that the only people I intended to mock then were those who mistook Debian mailing lists for advertising channels; but I understand now that my message must have caused pain to a lot more people than that. So, it may come late, but let me take this opportunity to offer my sincerest apologies to anyone I may have hurt at that time.


It may seem strange for someone with deeply-rooted values of equality to have written that. To have considered that it was okay to stereotype people. And I think I found this okay because to me, those people were given equal rights, and were therefore equal. But the fight for equality is not over when everyone is given the same rights. Not until they are given the same opportunities to exert those rights. Which does not happen when they live in a society that likes to fit them in little archetypal peg holes, never giving you the chance to question where those stereotypes come from.

For me, that chance came from an unusual direction: the fight against prostitution. This goes way back for me. Since when I was a teenager, I have always been ticked off at the idea of nonconsensual sex that somehow evades criminal responsibility because of money compensation. I never understood why it wasn t considered as rape. Yet it sounded weird that a male heterosexual would hold such opinions; after all, male heterosexuals should go to prostitutes as a kind of social ritual, right?

It was only three years ago that an organization of men against prostitution was founded in France. Not only did I find out that I was not alone with my progressive ideas, I was given the opportunity to exchange with many men and women who had studied prostitution: its effects on victims, its relationship to rape culture and more generally to the place men and women hold in society. Because eventually, it all boils down to little peg holes in which we expect people to fit: the virile man or the faggot, the whore or the mother. For me, it was liberating. I could finally get rid of the discomfort of being a white male heterosexual that didn t enter the little peg holes that were made for me.

And now, after Sweden 15 years ago, a new group of countries are finally adopting laws to criminalize the act of paying for sex. Including France. That s too bad for MikeeUSA, but this country is no longer the eldorado for white male supremacists. And I m proud that our lobbying made a contribution, however small, to that change.