In my recent post (I give up on Google), a lot of people suggested using OwnCloud as a replacement for several Google services. I ve been playing around with it for a few days, and it is something of a mix of awesome and disappointing, in my opinion. Files OwnCloud started as a file-sync tool, somewhat akin to Google Drive and Dropbox. It has clients for every platform, and it is also a client for every platform: you can have subfolders of your OwnCloud installation stored on WebDav, *FTP*, Google Drive, Dropbox, you name it. It is a pretty nice integrator of other storage services, and provides the only way to use some of them on Linux (*cough* Google Drive *cough*) One particularly interesting feature is the live editing in the browser of ODT, DOCX, and TXT files. This is somewhat similar to Google Docs and the only such thing I ve seen in Open Source software. It writes changes directly back to the documents and, in my limited testing, seems to work well. A very nice feature! I ve tested the syncing only on Linux so far, but it looks solid. There are two surprising issues, however: there is no deduplication and no delta-uploads. Add 10 bytes to the end of a 1GB file, and you re-upload the 1GB file. Thankfully the OwnCloud GUI client is smart enough to use inotify to notice an mv, but my guess is and I haven t tested this, but apparently OwnCloud doesn t use hashes at all that the CLI client would require a reupload after any mv, because it doesn t run continuously. In some situations, Syncany may be a useful work-around for this, as it does chunk-based dedup and client-side encryption. However, you would lose a lot of the sharing features inside OwnCloud by doing this, and the integration with the OwnCloud apps for photos, videos, and music. The Android/mobile apps support all the usual auto-upload options. Calendar A lot of people report using OwnCloud as a calendar server, and it does indeed use CalDAV. With a program like DAVDroid or Mozilla Lightning, this makes, in theory, a full-functioning calendar syncing tool. There is, of course, also a web interface to the calendar. It, sadly, is limited. Or shall we say, VERY limited. Even something like sending an invite is missing and in fact, the GUI for sharing an event is baffling. You can share it with someone, they get no say in whether or not it shows up, and it shows up on their calendar on the web only (not on synced copies) and they have no way to remove it! Sharing calendars is similar; you can hide the display of any one of your calendars on the web interface, but not of any calendars shared with you. Baffling. Address Book I haven t tested this yet, but there s not much to test, I suspect. It can be shared with others, which I could see as a nice feature. Bookmarks An interesting bookmarks manager, though mysteriously not with Firefox sync support. There is Chrome sync support, and a separate Mozilla Sync support, but it doesn t provide cross-browser syncing, apparently. Music It is designed to present an interface to music that is stored in Files. It provides an Ampache-compatible API, so there are a lot of clients that can stream music. It has very few options, not even for transcoding, so I don t see how it would be useful for my FLAC collection. Pictures Sort of a gallery view of photos synced up with Files. Very basic. Has a sharing button to share a link to an entire folder, but no option to embed photos in blog posts at a lower resolution or shortcut to sharing individual photos. Notes, Tasks, etc. I haven t had the chance to look at this much. Some of them sync to various clients. The Notes are saved as HTML files that get synced down. Clients overall There is a very helpful page that lists all the sync clients for OwnCloud not just for files, but also for calendars, contacts, etc. The list is extensive! Other options The two other Open Source options mentioned on my blog post were Kolab and Sogo, and there is also Zimbra which also has a community edition. The Debian Groupware page lists a number of other groupware options as well. Citadel caught my eye (wow, it s still around!). Sogo has ActiveSync support, which might make phone integration a lot easier. It is not dead-simple to set up like OwnCloud is, though, so I haven t tried it out, but I will probably be looking at it and Citadel next.

When paultag recently announced a project to try to move debian infrastructure to python3, my first thought was how large that undertaking would likely be. It seems like a classic engineering task, full of work and nit-picky details to get right, useful/necessary in the long-term, painful in the short-term, and if you manage to pull it off successfully, the best you can usually hope for is that no one will notice that it was done at all. I always find that kind of task a little off-putting and difficult to tackle, but I was happy to see someone driving the project, since it does need to get done. Debian is potentially also in a position to help the upstream python community, because we have a pretty good view of what things are being used, at least within our own ecosystem. I'm happy to say that i also missed one of the other great benefits of paultag's audacious proposal, which is how it has engaged people who already knew about debian but who aren't yet involved. Evidence of this engagement is already visible on the py3porters-devel mailing list. But if that wasn't enough, I ran into a friend recently who told me, "Hey, I found a way to contribute to debian finally!" and pointed me to the py3-porters project. People want to contribute to the project, and are looking for ways in. So cheers to the people who propose audacious projects and make them inviting to everyone, newcomers included. And cheers to the people who step up to potentially daunting work, stake out a task, roll up their sleeves, and pitch in. Even if the py3porters project doesn't move all of debian's python infrastructure to pyt3 as fast as paultag wants it to, i think it's already a win for the project as a whole. I am looking forward to seeing what comes out of it (and it's reminding me i need to port some of my own python work, too!) The next time you stumble over something big that needs doing in debian, even something that might seem impossible, please make it inviting, and dive in. The rest of the project will grow and improve from the attempt.Tags: py3-porters

I love having guests give my classes :) This time, we had Felipe Esquivel, a good friend who had been once before invited by me to the Faculty, about two years ago. And it was due time to invite him again! Yes, this is the same Felipe I recently blogged about To give my blog some credibility, you can refer to Felipe's entry in IMDb and, of course, to the Indiegogo campaign page for Natura. Felipe knows his way around the different aspects of animation. For this class (2015-04-15), he explained how traditional ray-tracing techniques work, and showed clear evidences on the promises and limits of parallelism Relating back to my subject and to academic rigor, he clearly shows the speed with which we face Amdahl's Law, which limits the efficiency of parallelization at a certain degree perprogram construct, counterpointed against Gustafson's law, where our problem will be able to be solved in better detail given more processing abilities (and will thus not hit Amdahl's hard ceiling). A nice and entertaining talk. But I know you are looking for the videos! Get them, either at my server or at archive.org.

This was my fifth month working on Debian LTS. I was assigned 16 hours by Freexian's Debian LTS initiative. I worked on several packages but haven't uploaded updates yet. linux-2.6 There is a steady stream of security issues in all Linux kernel versions. As we don't want to prompt reboots too often, these won't necessarily result in an update every month; it depends on the severity of the issue(s). However, I triaged the current issues and committed the available fixes to version control. dpkg The PGP signature validation in dpkg-source has a number of bugs, including CVE-2015-0840 which allows the validation to be completely subverted. I backported fixes for these from the 1.16 (wheezy) branch to the 1.15 (squeeze) branch. dpkg has a test suite and the fixes all came with new regression tests, so this was easy to verify. As dpkg is a native package (i.e. there is little separation between the 'upstream' and Debian packaging), I preferred that the dpkg maintainers would turn this into an 'upstream' release that I could upload. Guillem Jover has now reviewed and (semi-)released my changes, so I will complete this update soon. tiff A large number of bugs have been found in the venerable tiff library and tools, mostly by 'fuzzing' them with afl. The bugs have been unhelpfully grouped into a smaller number of CVE IDs, although it's not clear that these groups were introduced at the same time and they certainly weren't fixed at the same time. Most of the upstream bug reports come with samples to reproduce the bug (crash or memory corruption detectable with valgrind), but many of these did not turn out to be reproducible (either upstream or with the version in 'squeeze'). Where they were reproducible, I've verified that the patches fix the issue. Unfortunately tiff does not have a test suite, so I made a call for testing on the debian-lts list. If I don't get any responses soon, I'll run my own basic tests with programs that use libtiff before uploading.

Is the locked books room at McMahon Hall at UW a metaphor for DRM in the academy? Could it be, like so many things in Seattle, sponsored by Amazon? Mika noticed the room several weeks ago but felt that today s International Day Against DRM was a opportune time to raise the questions in front of a wider audience.

For the 2015 International Day Against DRM, I wrote a short essay on DRM for streaming services posted on the Defective by Design website. I m republishing it here. Between 2003 and 2009, most music purchased through Apple s iTunes store was locked using Apple s FairPlay digital restrictions management (DRM) software, which is designed to prevent users from copying music they purchased. Apple did not seem particularly concerned by the fact that FairPlay was never effective at stopping unauthorized distribution and was easily removed with publicly available tools. After all, FairPlay was effective at preventing most users from playing their purchased music on devices that were not made by Apple. No user ever requested FairPlay. Apple did not build the system because music buyers complained that CDs purchased from Sony would play on Panasonic players or that discs could be played on an unlimited number of devices (FairPlay allowed five). Like all DRM systems, FairPlay was forced on users by a recording industry paranoid about file sharing and, perhaps more importantly, by technology companies like Apple, who were eager to control the digital infrastructure of music distribution and consumption. In 2007, Apple began charging users 30 percent extra for music files not processed with FairPlay. In 2009, after lawsuits were filed in Europe and the US, and after several years of protests, Apple capitulated to their customers complaints and removed DRM from the vast majority of the iTunes music catalog. Fundamentally, DRM for downloaded music failed because it is what I ve called an antifeature. Like features, antifeatures are functionality created at enormous cost to technology developers. That said, unlike features which users clamor to pay extra for, users pay to have antifeatures removed. You can think of antifeatures as a technological mob protection racket. Apple charges more for music without DRM and independent music distributors often use DRM-free as a primary selling point for their products. Unfortunately, after being defeated a half-decade ago, DRM for digital music is becoming the norm again through the growth of music streaming services like Pandora and Spotify, which nearly all use DRM. Impressed by the convenience of these services, many people have forgotten the lessons we learned in the fight against FairPlay. Once again, the justification for DRM is both familiar and similarly disingenuous. Although the stated goal is still to prevent unauthorized copying, tools for stripping DRM from services continue to be widely available. Of course, the very need for DRM on these services is reduced because users don t normally store copies of music and because the same music is now available for download without DRM on services like iTunes. We should remember that, like ten years ago, the real effect of DRM is to allow technology companies to capture value by creating dependence in their customers and by blocking innovation and competition. For example, DRM in streaming services blocks third-party apps from playing music from services, just as FairPlay ensured that iTunes music would only play on Apple devices. DRM in streaming services means that listening to music requires one to use special proprietary clients. For example, even with a premium account, a subscriber cannot listen to music from their catalog using an alternative or modified music player. It means that their television, car, or mobile device manufacturer must cut deals with their service to allow each paying customer to play the catalog they have subscribed to. Although streaming services are able to capture and control value more effectively, this comes at the cost of reduced freedom, choice, and flexibility for users and at higher prices paid by subscribers. A decade ago, arguments against DRM for downloaded music focused on the claim that users should have control over the music they purchase. Although these arguments may not seem to apply to subscription services, it is worth remembering that DRM is fundamentally a problem because it means that we do not have control of the technology we use to play our music, and because the firms aiming to control us are using DRM to push antifeatures, raise prices, and block innovation. In all of these senses, DRM in streaming services is exactly as bad as FairPlay, and we should continue to demand better.

This evening I've been mostly playing with removing duplicate content. I've had this idea for the past few days about object-storage, and obviously in that context if you can handle duplicate content cleanly that's a big win. The naive implementation of object-storage involves splitting uploaded files into chunks, storing them separately, and writing database-entries such that you can reassemble the appropriate chunks when the object is retrieved. If you store chunks on-disk, by the hash of their contents, then things are nice and simple. The end result is that you might upload the file /etc/passwd, split that into four-byte chunks, and then hash each chunk using SHA256. This leaves you with some database-entries, and a bunch of files on-disk:

/tmp/hashed/ef267892ee080862c96a8d2d05de62f48e20f0875f27379e7d58c73ea4455bf1
/tmp/hashed/a378977155fb42bb006496321cbe31f74cbda803c3f6ca590f30e76d1afad921
..
/tmp/hashed/3805b0245bc8375be7125ae228eef711552ac082ffb9bf8756e2964a2393a9de

In my toy-code I wrote out the data in 4-byte chunks, which is grossly ineffeciant. But the value of using such small pieces is that there is liable to be a lot of collisions, and that means we save-space. It is a trade-off. So the main thing I was experimenting with was the size of the chunks. If you make them too small you lose I/O due to the overhead of writing out so many small files, but you gain because collisions are common. The rough testing I did involved using chunks of 16, 32, 128, 255, 512, 1024, 2048, and 4096 bytes. As sizes went up the overhead shrank, but also so did the collisions. Unless you could handle the case of users uploading a lot of files like /bin/ls which are going to collide 100% of the time with prior uploads using larger chunks just didn't win as much as I thought they would. I wrote a toy server using Sinatra & Ruby, which handles the splitting/hashing/and stored block-IDs in SQLite. It's not so novel given that it took only an hour or so to write. The downside of my approach is also immediately apparent. All the data must live on a single machine - so that reassmbly works in the simple fashion. That's possible, even with lots of content if you use GlusterFS, or similar, but it's probably not a great approach in general. If you have large capacity storage avilable locally then this might would well enough for storing backups, etc, but .. yeah.

Debsources (http://sources.debian.net) is still under active development. We recently had a Gnome Outreachy intern, Jingjie Jiang, and we're about to work with 2 GSoC students, Cl ment Schreiner and Orestis Ioannou. I will present here the GitHub mirror we've set up, in order to allow external pull requests to be submitted, and to use the continous integration service provided by Travis-CI. GitHub and Travis-CI Debsources' source code is hosted on Debian's git servers, and from there is mirrored to GitHub. Every time a commit is pushed (to master or other branches) or a pull request is open, the test suite will be automatically run on Travis-CI, and the result (tests pass or don't) is displayed on GitHub. This allows us to quickly filter external contributions (when they are submitted on GitHub), and be sure everything works with our setup, before reviewing work. Travis-CI runs the tests on OpenVZ containers. The complete infrastructure was a bit challenging to setup, but as we now have a Docker recipe to quicly begin to hack on Debsources, most of the work could be done using the Dockerfile instructions. In average, a run on Travis-CI (which includes git cloning the code and test data, setup the server, and run the tests suite) takes 7 minutes, which is an ok amount of time to wait for before submitting a pull request, in my opinion. Bugs discovered in the process Setting up this continuous integration infrastructure made me discover a few bugs. Python magic does black magic Debsources runs fine on Debian (not surprisingly), but I got tricked by black magic when I tried to run it on Ubuntu (which is the OS run in Travis-CI's containers). We use the magic library to guess the type of files we're dealing with, for instance when we need to decide between rendering a file (for text files) or downloading it (for binary files). Here comes the tricky part: the Python bindings for libmagic are not the same in Debian and Pypi. Debsources uses Debian package python-magic, which is not in Ubuntu 12.04. Moreover, there's no Python egg for it on Pypi, which has however another package (called magic) which provides a different API. I solved this with a dirty hack, using the fact python-magic lies in a single file: It simply downloads the library, saves it in a temporary folder and includes it in the Python path. Let's see for how long it works before everything breaks! Size of a directory One test in the suite was ensuring the information returned by ls -l on a directory and stored in the DB was the right information. Inode metadata was tested, such as name, permissions, type, or size. Interestingly enough, the size of a directory was tested, and expected to be 4096 bytes. The size of a directory actually depends on the filesystem in use, and on the number of files this directory contains. We often see 4096 because it's the size of a not-too-big directory on ext4. Travis-CI doesn't use ext4: Simfs is a container filesystem for OpenVZ, on which directories have different sizes than on ext4: Directory sizes are not even powers of 2. Hence I changed the test to not check directory sizes. Hopefully this will help to make Debsources work on more filesystems! An empty file is hiding Last but not least, because this bug is still open in the wild. A file, which appears to be empty, is not taken into account by Debsources' updater. This file is sources/non-free/m/make-doc-non-dfsg/4.0-2/.pc/applied-patches. It is present in the filesystem in the container, is not the only empty file over there, but still doesn't appear in the database, and make fail the test which counts files. The test has been commented out (booooooh), so that we still can use Travis-CI's platform for our GSoC students, before it's fixed. Conclusion Making Debsources run automatically on a different platform as the one we usually use permitted us to spot bugs, write dirty hacks, and expand the filesystems it's supposed to run on. Now, let's hope the continuous integration will help our GSoC students, and let's wish them good luck!

I just dist-upgraded the blog server to jessie. A couple of errors from code with checks for which modules are enabled from .htaccess (deprecated and now obsolete behavior). Nothing all that rocky. Go team Debian!

I am really tired of things Google has done lately. The most recent example being retiring Classic Maps. That s a problem, because the current Maps mysteriously doesn t show most of my saved ( starred ) places. Google has known about this since at least 2013. There are posts all over their forums about it going back to when what is now regular Google Maps was beta. Google employees even knew about it and did nothing. For someone that made heavy use of it, this was quite annoying. But there have been plenty of others:

• Removing My Places and My Maps from Maps for Android. Those features were used to, for instance, plan trips, highlight routes, add campground possibilities, etc. (They eventually brought this feature back months/years later, in limited form.)
• Removed the 7-day and month views from Calendar for Android, claiming this was better for users. Finally re-added those views a few months later after many complaints. I even participated in a survey process with them where they were clearly struggling to understand why anybody wanted to see 7 days at once, when that feature had been there for years
• Removing the XMPP capabilities in Google Talk/Hangouts.
• Picasaweb pretty much shut down, with very strong redirects to Google+ Photos. Which still to this day doesn t have a handy feature for embedding in a blog post or anything that s not, well, Google+.
• General creeping crapification of everything they touch. It s almost like Microsoft in the 90s all over again. All of a sudden my starred places stop showing up in Google Maps, but show up in Google Drive shared with the whole world. What? I never wanted them in Google Drive to start with.
• All the products that are all-but-dead Google Groups and the sad state of the Deja News archives. Maybe Google+ itself goes on this list soon?
• Looks like they re trying to kill off Google Voice and merge it into hangouts, but I can t send a text from the web with Hangouts.
• And this massive list of discontinued services and products. Yeowch. Remember when Google Code was hot, and then they didn t touch it at all for years?
• And they still haven t fixed some really basic things, such as letting people change their email address when they get married.
• Dropping SIP from Grand Central, ActiveSync from Apps, etc.

I even used to use Flickr, then moved to Picasa when Yahoo stopped investing in Flickr. Now I m back to Flickr, because Google stopped investing in Picasa. The takeaway is that you can t really rely on Google for anything. Counting on something being there for an upcoming trip and then having it be suddenly yanked away is a level of frustration that just makes the service not so useful. Never knowing when obvious things (7-day calendar view) will be removed means you just can t depend on it. So, are there good alternatives? Things I m thinking of include:

• Alternative calendar applications. Ideally it would support shared calendars for multiple people in a family, an Android app that lets you easily view some or all calendars, etc. I wonder if outlook.com is really the only competitor here? Last I looked a few years ago none of the Open Source options really worked well.
• Alternative mapping applications. Must-haves include directions, navigation in the car, saving points of interest, and offline storage on Android. Nice-to-haves would include restaurant review integration, etc. Looks like Nokia (HERE.com) and Mapquest, plus a few OSM spinoffs, are the leading contenders here.
• Email is easily enough found elsewhere, and I ve never used Gmail much anyhow.

Anybody else moving off Google?

We've spent beautiful weeks on Sri Lanka in January and February. On the way we've seen many different places - ancient cities, mountains, natural parks or beaches. Here comes selection of photos which I like most.

Filed under: English Photography Travelling 0 comments

Debian published Jessie last month. Big congratulations to the release team and all the contributors; quality is again at the rendez-vous! This time, I could not contribute much, being busy with parental activities (hello my son, if you read me), apart from making sure that my packages are ready for the D Day. This work was made easy by the automated removals of buggy packages set up by the release team. Many thanks for that development. I hope to use Jessie for a long time without the need of upgrading to Testing. At the moment, it provides everything I need, including the input of Japanese characters together with the possibility to switch between Japanese (or American) and multilingual Canadian keyboard layouts, which was not easy to do anymore in Wheezy. Many thanks again.

Mail configuration. Sometimes I send mail to root@some-domain-I-don't-own from cron or sudo or whatever system and wonder why that happened.

I approached the SuperTuxKart community fearing some backslash due to last week s discussion about their release 0.9, to find instead a nice, friendly and welcoming community. I have already had some very nice talks with them since then, and they have patiently explained to me the sequence of events that led to the situation that I mentioned and that, for the sake of fairness, I consider that I have to share here too. You can read the log of the first conversation I had with them (the log has been edited and cleared up for clarity and readability). I seriously recommend reading it, it s a honest friendly conversation, and it s first hand. For those who don t already know the game:

All this story seems to start with the complain of a 6 yo girl, close relative of one of the developers and STK user, who explained that she always felt that Mario Kart was better because there was a princess in it. I m not particularly happy with princesses as role models for girls, but one thing I have always said is that we have to listen to kids and take their opinions into accounts, and I know that if I had such a request from one of the kids closer to me, I probably would have fulfilled it too. In any case, Free Software projects based on volunteer work are essentially a do-ocracy and it is assumed that whoever does the work, gets to decide about it.

So that is how Princess Sara was added to the game. While developing it, I was assured that they took extra care that her proportions were somehow realistic, and not as distorted as we re used to see in Barbie or many Disney films. Sara is inspired on an OpenGameArt s wizard and is not supposed to be a weak damsel in distress, but in fact a powerful character in the world s universe.

Sara is not the only female character playable. There are a few others: Suzanne (a monkey, Blender s mascot), Xue (XFCE s mouse) and Amanda (a panda, the mascot of windows maker). Sara happens to be the only human character playable, male or female. While it has been argued that by adding that character, a player might have the impression that the rest of the characters would be male by default, I have been told that the intention is exactly the opposite,and that the fact that the only human playable character in the game is female should make it more attractive to girls. To some, at least. Here are some images of Sara:

So the fact is that they have invested a lot of time in developing Sara s model. I m not an artist myself, so I don t know first hand how much time and effort it takes to make such a model, but in any case it seems that quite a lot. When they designed the beach track Gran Paradiso, they wanted to add people to the beach. That track is, in fact, inspired on a real existing place: Princess Juliana Airport. Time was over and they wanted to publish a version with what they already had, so they used Sara s model in a bikini on the beach, with the intention of adding more people, male and female, later. The overall view of the beach would be:

This is how that track shows when the players are driving in it:

Now, about the poster of version 0.9, it is supposed to be inspired in the previous poster of version 0.8.1, only this time inspired in Carnival (which is, in fact, a celebration in which sexualization of both genders is a core part). I know that there are accusations of cultural apropriation, but I couldn t know, as my white privilege probably shields me from seeing that. Up to now, no one has said anything about that, only Gunnar explaining his point of view as a non-native mexican: While the poster does not strike as the most cautious possible, I do not see it as culturally offensive. It does not attempt to set a scene portraiting what were the cultures really like; the portrait it paints is similar to so many fantasy recreations . In my opinion, even when the model is done in good taste, with no superbig breasts and no unrealistic waist, it s still depicting a girl without much clothes as the main element of the scene, with an attire, a posture and an attitude that clearly resembles carnival and, thus, inevitably conveys a message of sexualization. Even though I can t deny that it s a cute poster, it s one I wouldn t be happy to see for example in a school, if someone wanted to promote the game there. The author of the poster, anyway, tells me that he had a totally different intention when doing it, and he wanted to depict a powerful princess, in the center of SuperTuxKart s universe, celebrating the new engine.

About the panties showing every now and then, I ve been told that it s something so hard to see that in fact you would really have to open the model itself to view them. I m not saying that I like them though, I think it would have been better if Sara would have had short pants under the skirt, if she was going to drive the snowmobile with a dress, but I m not sure if that s something important enough to condemn the game. The original girl mentioned at the beginning of this post seems to have found the animation funny, started laughing, and said that Sara is very silly, and that was all. It s probably something more silly than naughty, I guess. Even though, as I said, it s something I don t like too much. I don t have to agree with STK developers in everything. I guess.

There s one thing I would like to highlight about my conversations with the developers of SuperTuxKart, though. I like them. They seem to be as concerned about the wellbeing of kids as I am, they have their own ethic norms of what s acceptable and what s not, and they want to do something to be proud of. Sometimes, many of these conflicts arise from a lack of trust. When I first saw the screenshots with the girl in bikini and the panties showing, I was honestly concerned about the direction the project was taking. After having talked with the developers, I am more calmed about it, because they seem to have their heart in the right place, they care, they are motivated and they work hard. I don t know if a princess would be my first choice for a main female character, but at least their intention seems to be to give some girls a sensible role model in the game with who they can identify.

Am I missing something? I installed docker and noticed that it created a virtual interface named docker0 with the IP address 172.17.42.1. This behavior is consistent with the Docker networking documentation. However, I was confused by this statement:

It randomly chooses an address and subnet from the private range defined by RFC 1918 that are not in use on the host machine, and assigns it to docker0. Docker made the choice 172.17.42.1/16 when I started it a few minutes ago...

It seems like RFC 1918 defines:

• 10.0.0.0 - 10.255.255.255 (10/8 prefix)
• 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

How is 172.17.42.1/16 from the private ranges listed above? Is 172.17.42.1 a potentially public IP address?

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 26.25 hours on Debian LTS. In that time I did the following:

• CVE triage: I pushed 52 commits to the security tracker. I finished a new helper script (bin/lts-cve-triage.py) that builds on the JSON output that Holger implemented recently. It helps to triage more quickly some issues based on the triaging work already done by the Debian Security team.
• I filed #783005 to clarify the situation of libhtp and suricata in unstable (discovered this problem while triaging issues affecting those packages).
• I reviewed and sponsored DLA-197-1 for Nguyen Cong fixing 5 CVE on libvncserver.
• I released DLA-199-1 fixing one CVE on libx11. I also used codesearch.debian.net to identify all packages that had to be rebuilt with the fixed macro and uploaded them all (there was 11 of them).
• I sponsored DLA-207-1 for James McCoy fixing 7 CVE on subversion.
• I released DLA-210-1 fixing 5 CVE on qt4-x11.
• I released DLA-213-1 fixing 7 CVE on openjdk-6.
• I released DLA-214-1 fixing 1 CVE on libxml-libxml-perl.
• I released DLA-215-1 fixing 1 CVE on libjson-ruby. This backport was non-trivial but luckily included some non-regression tests.
• I filed #783800 about the security-tracker not handling correctly squeeze-lts/non-free.

Now, still related to Debian LTS, but on unpaid hours I did quite a few other things:

• I wrote a talk on Debian LTS that I gave during the Mini-DebConf in Lyon. I took quite some time to collect some statistics about the last 10 months of work within the team.
• I helped to draft a press release announcing our plans for Wheezy LTS and seeking more help at the same time.
• I ensured that the Jessie press release will include a sentence saying that it would be supported for 5 years too.

Other Debian work Feature request in update-alternatives. After a discussion with Josselin Mouette during the Mini-DebConf in Lyon, I filed #782493 to request the possibility to override at a system-wide level the default priority of alternatives recorded in update-alternatives. This would make it easier for derivatives to make different choices than Debian. Sponsored a dnsjava NMU. This NMU introcuded a new upstream version which is needed by jitsi. And I also notified the MIA team that the dnsjava maintainers have disappeared. python-crcmod bug fix and uploads to *-backports. A member of the Google Cloud team wanted this package (with its C extension) to be available to Wheezy users so I NMUed the package in unstable (to fix #782379) and prepared backports for wheezy-backports and jessie-backports (the latter only once the release team rejected a fix in jessie proper, see #782766). Old and new PTS updates for Jessies s release. I took care to update tracker.debian.org and packages.qa.debian.org to take into account Jessie s release (which, most notably, introduced the oldoldstable suite as the new name for Squeeze until its end of life). Received thanks with pleasure. This is not something that I did but I enjoyed reading so many spontaneous thanks in response to Guillem s terse and thankless notification of me stepping down from dpkg maintenance. I love the Debian community. Thank you. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Today at 18:00 UTC (this evening for me) there will be a Debian Publicity Team IRC meeting (open meeting, everybody invited), and I m very happy because it will be the first meeting that I know of, since I joined the team (years!). Being part of the Publicity team There are many tasks handled by Publicity, and when I joined, I supposed that I was going to be part of a team with many members and well structured. And it was true but not as I imagined. Publicity is a great team, in the sense that it accepts contributions from many people, and the few core members do an amazing work: on one side, get things done; on the other side, integrate all those occasional contributions from the wider community. But there are fewer core contributors than what one would expect by the output of the team. I would say we are maximum 10 people (out of 353 voters, 1033 Debian Developers, and 1197 contributors in the Debian Community in 2015). And as far as I know, everybody is member of some other teams too (I m a translator, others in website team, sysadmins, packaging teams and now we have a member sharing Publicity membership with DPL-ship!). Organisation around the tasks Publicity regular tasks (announcements, the newsletter Debian Project News , posting in social networks and in bits.debian.org, and other ) are all well defined and documented, in order to allow anybody jump in and help, and this is great, because it ensures a way for contributions to arrive the wide audience from the very first day: you pick something, you follow the instructions, and you re done. I love this approach, because I tend to prefer to follow instructions than to create something, and my Debian time is made of small chunks at random days/times. But sometimes I feel that we all work alone , in something like a cold, robotic do-ocracy, and I also wonder how many people don t contribute or become regular contributors just because they don t understand the procedures, or they don t like them, or other reasons IRC meeting IRC is something that I use only for contributing to free software, not in other parts of my life. I like IRC, it s productive and fun, but I m not always there, and I don t save logs when I am idle, and I usually prefer email for communication. However, I try to be more present in the Debian IRC channels of the teams where I contribute, because I ve learned that it plays a big role in feeling at home in Debian . Currently you can find me in #debconf-team #debconf15-germany #debian-i18n #debian-l10n-spanish #debian-publicity #debian-women and #debian-www . I ve attended some meetings in IRC (MediaGoblin monthly meetings, and DebConf15 meetings) and I ve learned about MeetBot and more or less how to chair an IRC meeting. Today it will be my first time chairing, it s hard to emulate so great chairs as Marga or Chris Webber, bu I hope I do it decently, and we all have a nice time knowing each other and sharing ideas for the Publicity team. Want to attend? All the details (when, where, agenda ) in the wiki page of the meeting. See you in a few hours!
Filed under: My experiences and opinion Tagged: Communities, Contributing to libre software, Debian, English, Free Software, IRC, libre software, Project Management

Continuing the #newinjessie game: There are a number of development and QA tools that are new in jessie:

• autorevision: store VCS meta-data in your release tarballs and use it during build
• git-remote-bzr: bidirectional interaction with Bzr repositories for git users
• git-remote-hg: bidirectional interaction with Mercurial repositories for git users
• corekeeper: dump core files when ELF programs crash and send you mail
• adequate: check installed Debian packages for various issues
• duck: check that the URLs in your Debian package are still alive
• codespell: search your code for spelling errors and fix them
• iwyu: include only the headers you use to reduce compilation time
• clang-modernize: modernise your C++ code to use C++11
• shellcheck: check shell scripts for potential bugs
• bashate: check shell scripts for stylistic issues
• libb-lint-perl: check Perl code for potential bugs and style issues
• epubcheck: validate your ePub docs against the standard
• i18nspector: check the work of translators for common issues

A few days ago, Erik released a new version of his Annoy library -- a small, fast, and lightweight C++ template header library for approximate nearest neighbours -- which now no longer requires Boost. While I don't mind Boost (actually, quite the opposite), it appears to have been a blocker in getting the Python part of Annoy over to the world of python3. And with a new Annoy out, I updated RcppAnnoy to it. In the process I got another pull request into Annoy (use R's RNG rather than rand() which R CMD check really dislikes). This new package is now on CRAN. 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.

We have set sails for a great endeavour. We are cleaning up the nx-X11 / nxagent code tree [1] and rebase it against latest / recent X.Org. Until now, we have been able to drop ~2,700,000 lines of code [2] from the source tree that originally got released by NoMachine. The plan is...

• to make NXv3 usable with recent desktop environments (work needed on nxagent's randr proto, composite proto, GL, probably more),
• facilitate multimedia content over NX via the Telekinesis framework (originally developped for X2Go),
• make X11 events inside nxagent accessible for third party applications
• and facilitate NX traffic via unix domain sockets.

For more details, see the Readme.md[3] file on our Github project. What we have achieved so far...

• We have only one(!) bundled library left (nx-X11/extras/Mesa--yeah, getting rid of this hunk will be quite an issue, indeed).
• We are continuously dropping bundled X11 libraries (already dropped: libNX_Xdmcp.so, libNX_Xfont.a, libNX_Xdmcp.so, pending: libNX_Xinerama, libNX_Xrandr, libNX_Xdamage).
• We have had three major commits that dropped many many lines of completely unneeded imake build logic.
  

read more