I tried to start to write this blog entry like I usually do: Type along what goes through my mind and see where I'm heading. This won't work out right now for various reasons, mostly because there is so much going on that I don't have the time to finish that in a reasonable time and I want to publish this today still. So please excuse me for being way more brief than I usually am, and hopefully I'll find the time to expand some things when asked or come back to that later. Part of the reason of me being short on time is different stuff going on in my private life which requires additional attention. A small part of this is also something that I hinted in a former blog entry: I switched my job in June. I really was looking forward to this. I made them aware of what the name Rhonda means to me and it's definitely extremely nice to be addressed with female pronouns at work. And also I'm back in a system administration job which means there is an interest overlap with my work on Debian, so a win-win situation on sooo many levels! I'm at DebConf15 since almost two weeks now. On my way here I was complimented on my outfit by a security guard at the Vienna airport which surprised me but definitely made my day. I was wearing one of these baggy hippie pants (which was sent to me by a fine lady I met at MiniDebConf Bucharest) but pulled up the leg parts to the knees so it could be perceived as a skirt instead. Since I came here I was pretty busy with taking care of DCschedule bot adjustments (like, changing topic and twittering from @DebConf at the start of the talks), helping out with the video team when I noticed there was a lack of people (which is a hint for that you might want to help with the video team in the future too, it's important for remote people but also for yourself because you can't attend multiple sessions at the same time). And I have to repeat myself, this is the place I feel home amongst my extended family, even though I it still is sometimes for me to get to speak up in certain groups. I though believe it's more an issue of certain individuals taking up a lot of space in discussions without giving (more shy) people in the round the space to also join in. I guess it might be the time that we need a session on dominant talking patterns for next year and how to work against them. I absolutely enjoyed such a session during last year's FemCamp in Vienna which set the tone for the rest of the conference, and it was simply great. And then there was the DebConf Poetry Night. I'm kinda disappointed with the outcome this year. It wasn't able to attract as much people anticipated, which I to some degree account to me not making people aware of it well enough, overlapping with a really great band playing at the same time in competition, and even though the place where we did it sounded like a good idea at first, it didn't had enough light for someone to read something from a book (but that was solved through smartphone lights). I know that most people did enjoy it, so it was good to do it, but I'm still a fair bit disappointed with the outcome and will try to work on improving on that grounds for next year. :) With all this going on there unfortunately wasn't as much time as I would have liked to spend with people I haven't seen for a long time, or new people I haven't met yet. Given that this year's DebConf had an height in attendees (526 being here at certain times during the two weeks, and just today someone new arrived too, so that doesn't even have to be the final number) it makes it a bit painful to have picked up so many tasks and thus lost some chances to socialize as much as I would have liked to. So, if you are still here and have the feeling we should have talked more, please look for me. As Bdale pointed out correctly in the New to DebConf BoF (paraphrased): When you see us DebConf old timers speaking to someone else and you feel like you don't want to disturb, please do disturb and speak to us. I always enjoyed to get to know new people. This for me always is one of the important aspects of DebConf. Also, I am very very happy to have received feedback from different people about both my tweets and my blog, thank you a lot of that. It is really motivating to keep going. So, lets enjoy the last few hours of DebConf! Another last side notice: While my old name in the Debian LDAP did manage to find some wrongly displayed names in the DebConf website, like for speakers, or volunteers, it was clear to me that having it exposed through SSO.debian.org isn't really something I appreciate. So I took the chance and spoke to Luca from the DSA team right here today, and ... got it fixed. I love it! Next step is getting my gpg key exchanged, RT ticket is coming up. :)

/debian permanent link Comments: 1 Flattr this

Well, here are the stats for the final week of the DUCK challenge as well as DebConf15:

• Yao Wei uploaded big-cursor
• Denis Briand abook
• Salvatore Bonaccorso uploaded libtext-simpletable-perl, libstring-bufferstack-perl and libcarp-clan-perl
• Sandro Tois uploaded dot2txt
• Florian Schlichting uploaded libxml-dom-perl, libtie-array-sorted-perl, libvalidate-net-perl and libtext-typography-perl
• Enrico Tassi uploaded lua-sec
• Bas Couwenberg uploaded modestmaps-py
• Riku Voipo uploaded device-tree-compiler
• Lucas Kanashiro uploaded libclass-gomor-perl and libclass-c3-adopt-perl
• Bernd Zeimez uploaded lua-json
• Olivier Sallou uploaded biojava4-live
• Kari Pahula uploaded gearhead
• Gregor Hermann uploaded libnet-tclink-perl
• Jakub Wilk uploaded pebl

So we had 21 packages fixed and uploaded by 14 different uploaders. People were really working hard on this during DebConf. A big "Thank You" to you!! Since the start of this challenge, a total of 89 packages, were fixed. Here is a quick overview:

	Week 1	Week 2	Week 3	Week 4	Week 5	Week 6	Week 7
# Packages	10	15	10	14	10	9	21
Total	10	25	35	49	59	68	89

Thank you all for participating - either on purpose or "accidentially": Some people were really surprised as i sneaked up on them at DebConf15, confronting them with a green lighter! I just tried to put even more fun into Debian, i hope this worked out Pevious articles are here: Week 1, Week 2, Week 3, Week 4, Week 5,Week 6.

The URW Base35 fonts are a great set of fonts, available for free as in free software. They have been part of various distributions and systems since long time. Big thanks to URW for their work. But these fonts don t have Cyrillic or Greek glyphs. Be it as it is, world would be easy. People would need to use different fonts for these languages. Comes around someone who did the unthinkable namely adding the Cyrillic and Greek glyphs to the fonts (by now nothing bad), but then NOT renaming the fonts. Here we see one point of the stupidity of GPL and absolute freedom. Because what we now have is that documents produced several TeX engines (in particular XeTeX and LuaTeX) which use fontconfig to search the fonts, suddenly pick up these changed fonts that fake their identity, and what comes out is this, a complete rubbish: And now we are suffering huge pain from that. Look at the bug reports of that are coming in:

• 796120 xdvipdfmx broken
• 789391 developers reference fonts broken
• 787759 fonts broken in dblatex

Just to name a few. And there is a simple way to circumvent this: Don t install gsfonts which guarantees that fontconfig finds the real original URW fonts within the TeX Live tree first. I have now spent many hours to track down these problems, find the reason, and at the end of the day there is always gsfonts with its broken fonts with added Cyrillic glyphs. I honestly don t care about the history, there are now many fonts with Cyrillic and Greek glyphs, there is no need to fake fonts, and incorrectly take over font names. This should be a lesson to all the GPL zealots that require absolute freedom of each and everything. Unfortunately things don t work like that. Using AND RENAMING is ok, the Knuth license as I would say, but anything else is just a source of much pain. End for today, I have to go to work now. Real work instead of fighting sins of the past. Nothing to enjoy here. Additional information Just to let you know, before starting a flame war, I have already contacted the upstream developers, that is TeX Live, and explained them the situation. I don t see much chance for fixing, since the problem is with fonts without upstream and support, which are probably only used in Debian (I haven t seen them anywhere else but some mentioning in RH), and which are not officially supported or distributed. It really needs a nice developer to look into why this breakage appeared. Let us hope. And instead of flaming, anyone here is invited to dig into the code him/herself and search for changes. Additional information 2015-08-22 Just to back up my complaints and counteract several of the comments: I am quoting from an email of a colleague on the list where we are discussing the problem:

However, the fonts extended by Valek Filippov are quite problematic. The Type1 spec clearly requires that there may not exist two different fonts with the same /FontName. The modified fonts shipped with Ghostscript have the same /FontName as the original fonts donated by URW and not even the /UniqueID was changed. IMO they are broken because they don t comply with the Type1 specification.

I hope that convinced also the last in doubt.

Thursday was our big day: After more than 2.5 years of working in the hidden, ups and downs, Frank Hofmann and myself were able to announce the availability of our book project Debian Package Management under a free license (Creative Commons Attribution ShareAlike 4.0 International License, short CC BY-SA 4.0 ) during a Lightning Talk at DebConf15 in Heidelberg. This became possible because we found Onyx Neon, a publishing company which is specialised on books with contents under free licenses. Its founder does not only have a faible for Perl but also for Debian. (Since the question already came up: We also thought about self-publishing, e.g. via Lulu or Epubli and it would have been our fallback solution , but we prefer the professionalism and services of a real publisher. I m though happy to share what I found out about self-publishing in the past few months.) The source code of the book is written in the AsciiDoc format and available on GitHub. The book is still work in progress. But if you want, you can already build an e-book out of the publically available source code:

sudo apt-get install asciidoc dblatex git
git clone git://github.com/dpmb/dpmb.git
cd dpmb
make

(Works fine on Debian 7 Wheezy, Debian 8 Jessie and Ubuntu 14.04 LTS Trusty. Does not work on Ubuntu 12.04 LTS Precise.) If you find an error in the book, please file an issue on GitHub. If you also know how to fix the error, please for the Git repository on GitHub, fix the error in your Git repository and file a pull request. (The first pull request already happenend and has been applied.) Initially there will be only a German written issue as e-book (at least in HTML, PDF and EPUB formats, maybe also KF8/MOBI and EPUB3) and at some point in the future also as printed book at Onyx Neon. But we re also planning a translation to English as well as a Debian package. If your want to get informed when we publish a printed book, a translation or an official e-book release, please subscribe to one of our mailing lists: There s one in German and one in English.

Based on a discussion around breakfast, and encouraged by the people at the table, I hereby call for a new release goal (or challenge, whatever you prefer to call it):


Every package maintainer should remove one of their packages from the archive.


It's dead simple. It is acceptable to adopt a package to replace the one that has been removed, or to add a new one to the archive.
For tracking purposes please include "for RG" (release goal) in the removal request to ftp.debian.org.


And how about a debconf challenge? how about filing over 100 removal requests before the end of Debconf 15 on Saturday night? blog about it, dent/twit about it, spam IRC about it!


The idea came up after discussing about how us as package maintainers refuse to remove our obsolete or unused packages. So yes, that may also include the very first package that you got into the archive.


Sad news, good news.

Following the tradition of Love Locks, apparently there is someone really in love with vim in Heidelberg! Found at the Old Bridge in Heidelberg during DebConf15.

There is more people with blue hair at Debconf than at an average Akademy. KDE we need to do better :)

Thanks to Takahiro Seino we are now having a gentle introduction to CafeOBJ for beginners, in both English and Japanese, available. Please head over to the CafeOBJ web site for details, or jump directly to the English or Japanese version. We are also preparing for a new release with largely improved CITP support and better term inspection. Stay tuned.

Today, finally, my first printed draft edition of the Norwegian translation of Free Culture I have been working on for the last few years arrived in the mail. I had to fake a cover to get the interior printed, and the exterior of the book look awful, but that is irrelevant at this point. I asked for a printed pocket book version to get an idea about the font sizes and paper format as well as how good the figures and images look in print, but also to test what the pocket book version would look like. After receiving the 500 page pocket book, it became obvious to me that that pocket book size is too small for this book. I believe the book is too thick, and several tables and figures do not look good in the size they get with that small page sizes. I believe I will go with the 5.5x8.5 inch size instead. A surprise discovery from the paper version was how bad the URLs look in print. They are very hard to read in the colophon page. The URLs are red in the PDF, but light gray on paper. I need to change the color of links somehow to look better. But there is a printed book in my hand, and it feels great. :) Now I only need to fix the cover, wrap up the postscript with the store behind the book, and collect the last corrections from the proof readers before the book is ready for proper printing. Cover artists willing to work for free and create a Creative Commons licensed vector file looking similar to the original is most welcome, as my skills as a graphics designer are mostly missing.

Poetry for Debconf15 poetry night

Debian's reached the age of 22
I wish I could be there with you
In Heidelberg, fair German city
To share, in person, this my ditty

Rhonda's worked hard - the work is done
With poems now begins the fun
While others play cards or hack new code
Or dream of running down the road

Free software, arguments, warmth, good cheer
Too soon all over 'til next year
All of the best are there / on 'Net
Here's hope that it's the best Debconf yet

A bi-lingual poem created on inspiration from Debconf15 and in honor of Debconf Poetry Night by Rhonda

Du ... Du hast ... Du hast apt ... Du hast apt gebrochen! Reconsider your disk usage, And APT might work again.

(as usual - licenced as CC-BY V3+ or GPLv2+)

I ve just uploaded an update version of my puppet ssh module to the forge. The module aims at being a generic module to manage of ssh server and clients, including key generation and known_hosts management. It provides a mechanism to generate and deploy ssh keys without the need of storeconfig or PuppetDB but a server-side cache instead. This is neat, if you want to remain ssh keys during a reprovisioning of a host. Updates The update is mostly to push out some patches I ve received from contributors via pull requests in the last few months. It adds:

• Support for the AllowUsers, AllowGroups and DenyUsers aswell as DenyGroups parameters in the default sshd_config template. Thanks to cachaldora for the patches.
• Support for multiple ports in the default sshd template. Thanks to Arnd Hannemann for that patch.
• Fixes in the template for it to work with newer puppet versions. Untested by me, but this probably fixes compatibility with puppet 4. For that contribution my thanks go to Daine Danielson.Apart from this changes I ve added a couple of beaker tests.If the module is of any use for you, I d be happy for ratings at puppetforge. The same is true for critical feedback, bug reports or (even better pull requests.

On a private mailing list there have been some recent discussions about a Code of Conduct which demonstrate some great misunderstandings. The misunderstandings don t seem particular to that list so it s worthy of a blog post. Also people tend to think more about what they do when their actions will be exposed to a wider audience so hopefully people who read this post will think before they respond. Jokes The first discussion concerned the issue of making jokes . When dealing with the treatment of other people (particularly minority groups) the issue of jokes is a common one. It s fairly common for people in positions of power to make jokes about people with less power and then complain if someone disapproves. The more extreme examples of this concern hate words which are strongly associated with violence, one of the most common is a word used to describe gay men which has often been associated with significant violence and murder. Men who are straight and who conform to the stereotypes of straight men don t have much to fear from that word while men who aren t straight will associate it with a death threat and tend not to find any amusement in it. Most minority groups have words that are known to be associated with hate crimes. When such words are used they usually send a signal that the minority groups in question aren t welcome. The exception is when the words are used by other members of the group in question. For example if I was walking past a biker bar and heard someone call out geek or nerd I would be a little nervous (even though geeks/nerds have faced much less violence than most minority groups). But at a Linux conference my reaction would be very different. As a general rule you shouldn t use any word that has a history of being used to attack any minority group other than one that you are a member of, so black rappers get to use a word that was historically used by white slave-owners but because I m white I don t get to sing along to their music. As an aside we had a discussion about such rap lyrics on the Linux Users of Victoria mailing list some time ago, hopefully most people think I m stating the obvious here but some people need a clear explanation. One thing that people should consider jokes is the issue of punching-down vs punching-up [1] (there are many posts about this topic, I linked to the first Google hit which seems quite good). The basic concept is that making jokes about more powerful people or organisations is brave while making jokes about less powerful people is cowardly and serves to continue the exclusion of marginalised people. When I raised this issue in the mailing list discussion a group of men immediately complained that they might be bullied by lots of less powerful people making jokes about them. One problem here is that powerful people tend to be very thin skinned due to the fact that people are usually nice to them. While the imaginary scenario of less powerful people making jokes about rich white men might be unpleasant if it happened in person, it wouldn t compare to the experience of less powerful people who are the target of repeated jokes in addition to all manner of other bad treatment. Another problem is that the impact of a joke depends on the power of the person who makes it, EG if your boss makes a joke about you then you have to work on your CV, if a colleague or subordinate makes a joke then you can often ignore it. Who does a Code of Conduct Protect One member of the mailing list wrote a long and very earnest message about his belief that the CoC was designed to protect him from off-topic discussions. He analysed the results of a CoC on that basis and determined that it had failed due to the number of off-topic messages on the mailing lists he subscribes to. Being so self-centered is strongly correlated with being in a position of power, he seems to sincerely believe that everything should be about him, that he is entitled to all manner of protection and that any rule which doesn t protect him is worthless. I believe that the purpose of all laws and regulations should be to protect those who are less powerful, the more powerful people can usually protect themselves. The benefit that powerful people receive from being part of a system that is based on rules is that organisations (clubs, societies, companies, governments, etc) can become larger and achieve greater things if people can trust in the system. When minority groups are discouraged from contributing and when people need to be concerned about protecting themselves from attack the scope of an organisation is reduced. When there is a certain minimum standard of treatment that people can expect then they will be more willing to contribute and more able to concentrate on their contributions when they don t expect to be attacked. The Public Interest When an organisation declares itself to be acting in the public interest (EG by including Public Interest in the name of the organisation) I think that we should expect even better treatment of minority groups. One might argue that a corporation should protect members of minority groups for the sole purpose of making more money (it has been proven that more diverse groups produce better quality work). But an organisation that s in the Public Interest should be expected to go way beyond that and protect members of minority groups as a matter of principle. When an organisation is declared to be operating in the Public Interest I believe that anyone who s so unable to control their bigotry that they can t refrain from being bigoted on the mailing lists should not be a member.

• [1] http://reasonableconversation.wordpress.com/2012/07/19/punching-up/

Another relatively minor release, this of a software package that I've technically orphaned. But, well, it needed a fix, and it only took a few hours. krb5-sync is a system for synchronizing passwords from a Kerberos KDC to an Active Directory realm (which I no longer personally use). The primary change in this release is some tweaks to the silent mode of krb5-sync-backend to keep it from spamming output about transient errors if accounts are slow to materialize on the Active Directory side. It also incorporates changes from the Debian packaging to relax the timing on some tests. You can get the latest version from the krb5-sync distribution page.

Another collection of random bug fixes in my general C utility library. Fixes a missing va_end, a segfault in buffer_find_string with new buffers, and how relative paths are computed in Test::RRA::Automake. Also adds a portability layer for the MIT Kerberos kadm5_init_krb5_context function. You can get the latest release from the rra-c-util distribution page.

Nothing particularly exciting in this release of my C testing framework, but aherbert on Github found a segfault in the runtests driver with test lists that had only blank lines and comments. Since I'm releasing some other software anyway, that seemed to be worth a release. While preparing the release, I found that the test for spelling errors in the POD documentation had some bad assumptions about how to canonicalize paths, so you may want to grab a new copy of that if you're using it in your projects. You can get the latest release from the C TAP Harness distribution page.

In the last few years I wasn t really maintaining my GPG keys. I ve created a new one (B4E14499) in 2011 during DebConf11, after the older primary one (99E81DA0) became too weak (1024D). I thought that I didn t have enough signatures on the new key and almost lost my place on the debian keyring due to removal on the old one (without adding the new key). Due to my confusion with the key signature, I didn t really take the time to sign other people keys. But that doesn t mean I ignored them completely, as I kept all the information from Debconf11 (yes, 4 years ago) and also the slips I was handed since. Today, I finally took the time to finish the backlog and sign all the keys which are strong enough and still valid (haven t expired / revoked). One less item on the todo list. For those who got my signatures I m sorry for the delay, but better later than never, right ?
Filed under: Debian GNU/Linux Tagged: gpg

I bumped into Mark Shuttleworth today at Linuxcon and we had a brief conversation about Canonical's IP policy. The short summary:

• Canonical assert that the act of compilation creates copyright over the binaries, and you may not redistribute those binaries unless (a) the license prevents Canonical from restricting redistribution (eg, the GPL), or (b) you follow the terms of their IP policy. This means that, no matter what Dustin's blogpost says, Canonical's position is that you must ask for permission before distributing any custom container images that contain Ubuntu binaries, even if you use no Ubuntu trademarks in the process. Doing so without their permission is an infringement of their copyright.
  
• Canonical have no intention of clarifying their policy, because Canonical benefit from companies being legally uncertain as to whether they have permission to do something or not.
  
• Mark justifies maintaining this uncertainty by drawing an analogy between it and the perceived uncertainties that exist around certain aspects of the GPL. I disagree with this analogy pretty strongly. One of the main reasons for the creation of GPLv3 was to deal with some more ambiguous aspects of GPLv2 (such as what actually happened after license termination and how patents interacted with the GPL). The FSF publish a large FAQ intended to provide further clarity. The major ambiguity is in what a derivative work actually is, which is something the FSF can't answer absolutely (that's going to be up to courts) but will give its opinion on when asked. The uncertainties in Canonical's IP policy aren't a result of a lack of legal clarity - they're a result of Canonical's refusal to answer questions.

The even shorter summary: Canonical won't clarify their IP policy because they believe they can make more money if they don't.

Why do I keep talking about this? Because Canonical are deliberately making it difficult to create derivative works, and that's one of the core tenets of the definition of free software. Their IP policy is fundamentally incompatible with our community norms, and that's something we should care about rather than ignoring.

comments

Good news. Many things happened since my last report (8 months ago), some of them very interesting :-)

debian maintainer

Back in April 2015 I applied to become Debian Maintainer (DM). I was supported by several Debian Developers (DD), including Ana Guerrero, Anibal Monsalve, Michael Prokop and Vicent Cheng. They are people I have been somehow involved with in the last times (developing, in-person meetings, other talks...).

After a month or two, my PGP key was added to the debian keyring.

And what means this? If a DD gives me the corresponding authorization, I can now upload packages directly to the archive without the need for a sponsor.

I have been maintaining packages as a standard contributor since early 2014. From 2014 to 2015 I've learned many many things about Debian. That knowledge was key to become DM.

Google Summer of Code 2015

This is my 3 year in GSoC. In 2013 and 2014 I was involved with the Netfilter Project, but this time I'm contributing to the Debian project.
In concrete, my project is "Improve the Debian port mipsel".

Most of the software is developed to run in common CPU architectures like amd64 and i386. However, Debian can run in a large variety of arches (not so many operating systems have this power). Developers tend to consider these arches 'exotic' and don't pay much attention to them.
The mips/mipsel architecture is somewhat similar to arm: its mainly intended for small devices.

My tasks consist mainly into fixing bugs and FTBFS errors in the mipsel architecture.

Roughly speaking, this can be done in two ways: emulating the mipsel arch using qemu, or using a physical mipsel machine. The qemu way is very very slow. Fortunately, as part of my GSoC involvement, I was given a ci20 mipsel board by Imagination Technologies. I have been using this board for all my GSoC work.

Detailing my work during this GSoC deserves his own blog post. However, the Debian workflow for GSoC'15 requires a weekly report, and here are mine:

1. week 1
2. week 2
3. week 3
4. week 4
5. week 5
6. week 6
7. week 7
8. week 8
9. week 9
10. week 10
11. week 11
12. week 12

other debian sutff

Regarding packaging, it worth mention my latest new package: liquidprompt. For people who get their hands dirty with the CLI, I recommend it :-)
I made lot of updates to the other packages as well.

The nftables package is now in jessie-backports. Debian includes now Linux v4 in jessie-backports as well, which mean you can start playing with a full-featured nftables right now :-)
I'm looking forward to package the following version of upstream nftables, which is to include new exciting changes.

best regards!

Dear Lazyweb, I m currently trying to find a way to port python-debianbts to Python3. Debian s standard bugreport tool reportbug depends on python-debianbts and can thus not convert to Python3 if python-debianbts does not as well. Unfortunately python-debianbts depends on SoapPy for parsing the Debian bugtracker s responses, and that library is not ported to Python3 yet, and probably never will. I m planning to replace SoapPy with pysimplesoap which is available for Python2 and Python3. Unfortunately debbugs does not support WSDL which makes parsing of the replies extremely painful and error-prone. I wonder if there is a SOAP/Python expert out there who d be willing to give some assistance in porting python-reportbug to pysimplesoap? python-reportbug s repository is on GitHub and patches are very welcome. Since SOAP is quite a beast and debbugs uses it for read-only purposes only, another attractive solution would be to replace/augment debbugs API with something much more simple, like JSON. That would make parsing extremely easy as many programming languages including Python support JSON without any external libraries. In theory this could be quite easy but requires some serious Perl skills.