Linux

Recently there was yet another storm in a teacup that distracted us from creating and sharing Ubuntu and our flavors with others. I am not going to dive into the details of this particular incident…it has been exhaustively documented elsewhere…but at the heart of this case was a concern around the conduct in which some folks engaged around something they disagreed with. This is not the first time we have seen disappointing conduct in a debate, and I wanted to share some thoughts on this too. In every community I have worked in I have tried to build an environment in which all view points that challenge decisions or decision makers are welcome with the requirement that they are built on a platform of respectful discourse; this is the essence of our Code Of Conduct. Within the context of an Open Source community we also encourage this engagement around differences to be expressed as solutions with a focus on solving problems; this helps us to be productive and move the project forward. This is why we have such a strong emphasis on blueprints, specs, bugs, and other ways of expressing issues and exploring solutions. Within the context of this most recent issue I saw three problems (problems I have seen present in other similar arguments too): Irrespective of the voracity or content of an opinion we must never forget to be respectful and polite in the way we express and engage with others. Respect must always be present in our discourse, irrespective of the content of our opinions; without it we become a barbaric people and lose the magic that brought this wonderful set of minds together in the first place. There is simply no excuse for rudeness, and inflammatory FUD that has no evidence to back it up other than presumed ill-intent serves nothing but to demotive folks and ratchet up the flames, as opposed to resolve the issue and make things better. Trust needs to be earned, but trust should always be built within the wider context of a set of contributions and conduct. Unfortunately some folks consider decisions they disagree with to be a basis for (a) entering into a paranoid debate about the “real reason” the individual or company made that decision (and typically not believing the rationale provided by said decision-maker) and (b) seemingly forgetting about all the other positive contributions that the person or company has contributed. I can assure you there is no nefarious scheme at place at Canonical; our goals are well known in the community. If I felt Canonical was fundamentally trying to demote and shut the community out, I wouldn’t work here; I have no interest in working for a company that doesn’t understand the value of community, and I am not worried about finding suitable employment elsewhere. I work at Canonical because I believe our goals with Ubuntu are just and the company’s commitment to our community is sincere. Ubuntu is not a consensus-based community. Consensus communities rarely work, and I am not aware of any Open Source project that bases their work on wider consensus in the community. It would be impossible and impractical to notify our community of every decision we make, let alone try to base a decision on a majority view, but we do try to ensure that major changes are communicated to our leaders first (this is something we have been driving improvements in recently). We always need to find the right balance between transparency and JFDI, and sometimes the balance isnt’t quite there, but that does not mean there is some kind of illuminati-ish scheme going on behind the scenes. Ubuntu is a community filled with passionate people, and I love that we have folks who are critical of our direction and decisions. If everyone agreed with what we are doing, we would not always make the right decisions, and our diversity is what makes Ubuntu and our flavors such a great place to participate. As I said at the beginning of this post, it is important that all

You may not know this, but I am a huge PowerDNS fan. This may be because it is so simple to use, supports different databases as backends or maybe just because I do not like BIND, pick one. I also happen to live in Germany where ISPs usually do not give static IP-addresses to private customers. Unless you pay extra or limit yourself to a bunch of providers that do good service but rely on old (DSL) technology, limiting you to some 16MBit/s down and 1MBit/s up. Luckily my ISP does not force the IP-address change, but it does happen from time to time (once in a couple of month usually). To access the machine(s) at home while on a non-IPv6-capable connection, I have been using my old (old, old, old) DynDNS.com account and pointing a CNAME from under die-welt.net to it. Some time ago, DynDNS.com started supporting AAAA records in their zones and I was happy: no need to type hostname.ipv6.kerker.die-welt.net to connect via v6 — just let the application decide. Well, yes, almost. It’s just DynDNS.com resets the AAAA record when you update the A record with ddclient and there is currently no IPv6 support in any of the DynDNS.com clients for Linux. So I end up with no AAAA record and am not as happy as I should be. Last Friday I got a mail from DynDNS: Starting now, if you would like to maintain your free Dyn account, you must now log into your account once a month. Failure to do so will result in expiration and loss of your hostname. Note that using an update client will no longer suffice for this monthly login. You will still continue to get email alerts every 30 days if your email address is current. Yes, thank you very much… Given that I have enough nameservers under my control and love hacking, I started writing an own dynamic DNS service. Actually you cannot call it a service. Or dynamic. But it’s my own, and it does DNS: powerdyn. It is actually just a script, that can update DNS records in SQL (from which PowerDNS serves the zones). When you design such a “service”, you first think about user authentication and proper information transport. The machine that runs my PowerDNS database is reachable via SSH, so let’s use SSH for that. You do not only get user authentication, server authentication and properly crypted data transport, you also do not have to try hard to find out the IP-address you want to update the hostname to, just use $SSH_CLIENT from your environment. If you expected further explanation what has to be done next: sorry, we’re done. We have the user (or hostname) by looking at the SSH credentials, and we have the IP-address to update it to if the data in the database is outdated. The only thing missing is some execution daemon or … cron(8). :) The machine at home has the following cron entry now: */5 * * * * ssh -4 -T -i /home/evgeni/.ssh/powerdyn_rsa powerdyn@ssh.die-welt.net This connects to the machine with the database via v4 (my IPv6 address does not change) and that’s all. The machine with the database has the following authorized_keys entry for the powerdyn user: command="/home/powerdyn/powerdyn/powerdyn dorei.kerker.die-welt.net" ssh-rsa AAAA... evgeni@dorei By forcing the command, the user has no way to get the database-credentials the script uses to write to the database and neither cannot update a different host. That seems secure enough for me. It won’t scale for a setup as DynDNS.com and the user-management sucks (you even have to create the entries in the database first, the script can only update them), but it works fine for me and I bet it would for others too :) 0 comment(s) | this blog is flattr enabled

Or rather, hello Planet! Here’s a somewhat traditional introductory post. I’m Nicolas Dandrimont, I’m French, I’m sysadmin in a grande école, where I’m mostly in charge of the GNU/Linux workstations and servers. In Debian, I’m a DM, currently in the NM queue, so I might become a DD soon-ish. I am (rather inactively) co-maintaining a few packages. In my Debian “career”, I have been involved in OCaml packaging and Python packaging, although lately most of my time has been spent on Google Summer of Code (mentor for two mentors.debian.net projects in 2012, org admin for Debian in 2013), and on mentors.debian.net. In other free-software related projects, I own a RepRap 3D printer, and I grew some interest in the related software, e.g. Slic3r and printrun. There have been a lot of action in Fedora about packaging 3D-printing-related software, and it’d be great to get a team together to work on that in Debian during the jessie release cycle. Consider this a call for interested parties Unrelatedly, paultag has tricked me into working on hy, which is way too much fun. Blame him if you feel that I have been inactive lately, this has been eating way too much of my free time Hopefully I’ll be able to make regular updates on the work I do in Debian and free software, so stay tuned!

besides working on the preparation of the Perl 5.18 transition, I also looked into some RC bugs: #542564 – xmlroff: "xmlroff: uses libgnomeprint which is scheduled for removal"drop build dependency and disable in ./configure, upload to DELAYED/2 #665506 – src:ario: "ario: Including individual glib headers no longer supported"apply patch from Michael Biebl, upload to DELAYED/2, overriden by a faster upload of another bug squashing DD #665530 – src:getstream: "getstream: Including individual glib headers no longer supported"add patch from Michael Biebl, upload to DELAYED/2 #665555 – src:gxine: "gxine: Including individual glib headers no longer supported"add info about next build failure to bug report #665573 – src:librcc: "librcc: Including individual glib headers no longer supported"include patch from Colin Watson, upload to DELAYED/2 #665579 – src:meanwhile: "meanwhile: Including individual glib headers no longer supported"apply patch from Michael Biebl, upload to DELAYED/2 #665609 – src:sagasu: "sagasu: Including individual glib headers no longer supported"apply patch from Michael Biebl, upload to DELAYED/2 #665628 – src:xmlroff: "xmlroff: Including individual glib headers no longer supported"apply patch from Michael Biebl, upload to DELAYED/2 #707686 – dhelp: "dhelp: FTBFS and uninstallable in sid: needs ruby-gettext"upload last week's patch to DELAYED/2 #708598 – src:libgeo-ip-perl: "libgeo-ip-perl: FTBFS: CAPI must be at least 1.4.8 - Please update"upload new upstream release (pkg-perl) #708730 – libanyevent-perl: "libanyevent-perl: architecture specific constants in an arch:all package (again)"switch back to arch:any (pkg-perl) #708766 – libimager-qrcode-perl: "libimager-qrcode-perl: Update for newer libimager-perl needed"file a bug with patch (update for newer libimager-perl)

Today, I played at TC Cantincrode in Mortsel, Belgium, in the first round. This is the first year I'm playing tennis competitively, so I wasn't expecting to win by a pretty wide margin. Now while I didn't win, the margin wasn't as wide as I'd expected; 6/4 - 6/3 isn't too bad for the non-ranked beginner that I am. For comparison: I lost my previous match with 6/2 - 6/0, and I was not unhappy about that. Part of this was due to my opponent (by his own admission) not playing his best; but still, I'm quite happy about my result here. My next match probably won't be as good. Oh well.

I use RSS feeds to keep up with academic journals. Because of an undocumented and unexpected feature (bug?) in my (otherwise wonderful) free software newsreader NewBlur, many articles published over the last year were marked as having been read before I saw them. Over the last week, I caught up. I spent hours going through abstracts and downloading papers that looked interesting or relevant to my research. Because I did this for hundreds of articles, it gave me an unusual opportunity to reflect on my journal reading practices in a systematic way. On a number of occasions, there were potentially interesting articles in non-open access journals that neither MIT nor Harvard subscribes to and that were otherwise not accessible to me. In several cases where the research was obviously important to my work, I made an interlibrary request, emailed the papers’ authors for copies, or tracked down a colleague at an institution with access. Of course, articles that look potentially interesting from the title and abstract often end up being less relevant or well executed on closer inspection. I tend to cast a wide net, skim many articles, and put them aside when it’s clear that the study is not for me. This week, I downloaded many of these possibly relevant papers to, at least, give a skim. But only if I could download them easily. On three or four occasions, I found inaccessible articles at this margin of relevance. In these cases, I did not bother trying to track down the articles. Of course, what appear to be marginally relevant articles sometimes end up being a great match for my research and I will end up citing and building on the work. I found several suprisingly interesting papers last week. The articles that were locked up have no chance at this. When people suggest that open access hinders the spread of scholarship, a common retort is that the people who need the work have or can finagle access. For the papers we know we need, this might be true. As someone with access to two of the most well endowed libraries in academia who routinely requests otherwise inaccessible articles through several channels, I would have told you, a week ago, that locked-down journals were unlikely to keep me from citing anybody. So it was interesting watching myself do a personal cost calculation in a way that sidelined published scholarship — and that open access publishing would have prevented. At the margin of relevance to ones research, open access may make a big difference.

All recent articles on packaging using a version control system should really appear over at Planet vcs-pkg. Feel free to just ping me with a feed URL that is vcs-pkg-specific.

I have a Raspberry Pi running Raspbian (wheezy) with a UVC camera available as /dev/video0. I've been trying for three weeks to live-stream the picture from the camera onto the local network. I have tried crtmpserver and vlc, read several dozens of how-tos, but so far I have not been able to get a streaming setup working, no matter what I tried. Hence my plea to the lazy web: does anyone have such a setup running on top of Debian? Would you please let me know how you did it? Thanks a lot! NP: Eels: End Times

I've written an article as monthly one, "Debian Hot Topics", and  this time, teaching steps and ways that how to put packages to Debian official repository. Japanese readers, have fun :)

PyBit is a distributed build system able to build packages in response to VCS commits or other triggers, across multiple architectures, multiple clients and multiple build environments with automated uploads to a nominated repository. Support is included in 1.0.0 for building Debian packages using sbuild in response to subversion commits or changes in debian-devel-changes@lists.debian.org (by using apt as a version control handler) for any architecture and build environment which sbuild can support. There is also an example git commit template. Pybit has been designed to be fully extensible, so support for RPM or other package formats can be added as well as other version control handlers, other build environments and other architectures. Pybit is also scalable, when one type of client is struggling with the workload, another machine of the same architecture can be added to the pool to share the load. Pybit can also build a package for any number of architectures and build environments at the same time. The Pybit web interface provides an at-a-glance summary of all current builds as well as options to blacklist certain combinations, cancel and retry specific jobs and add monitor each pybit client. Current use cases include: Rapidly changing VCS - one or more subversion repositories with lots of Debian packages, built automatically for any number of build environments and architectures every time the debian/changelog is modified. Clean chroot builds provide continuous integration testing of the every package. Rebuilding the archive with different compilers or flags - a dedicated email account subscribed to debian-devel-changes@lists.debian.org feeding messages through procmail to the changes-debian hook, passing build requests to the apt handler to rebuild each package in your own sbuild chroots, using whatever environments, suites and build options can be configured within those chroots. something else we haven't thought of yet ... there is scope for a lot more hooks, package formats, chroot tools and handler plugins. Pybit 1.0.0 has arrived in Debian unstable as a direct result of the efforts put in by the pybit team during a sprint on 18th May 2013. Thanks to everyone involved in Pybit. https://freecode.com/projects/pybit http://nicholasdavidson.github.io/pybit/ https://github.com/nicholasdavidson/pybit