Ria has the sprue. She keeps her c liac disease a secret, though, because she works in food service, and customers knowing about her little gluten-sensitive enterology problem would, she feels, damage her credibility. The fried chicken is delicious, she coos. There is nothing gluten-free on the menu, so she does not have first-hand knowledge of this. Instead she is proxying the amalgamated judgments of others.

My house entered full power saving mode with fall. Lantern light and all devices shutdown at bedtime. But, it felt early to need to do this. Comparing with my logbook for last year, the batteries were indeed doing much worse. I had added a couple of new batteries to the bank last winter, and they seemed to have helped at the time, although it's difficult to tell when you have a couple of good batteries amoung a dozen failing ones. The bank was set up like this:

+---- house ----
                
+( 6v )-+( 6v )-
                
+( 6v )-+( 6v )-
                
+( 6v )-+( 6v )-
                
+( 6v )-+( 6v )-
                
+( 6v )-+( 6v )-
                
+(   new 12v  )-
                
+(   new 12v  )-

Tried as an experiement disconnecting all the bridges between the old 6v battery pairs. I expected this would mean only the new 12v ones would be in the circuit, and so I could see how well they powered the house. Instead, making this change left the house without any power at all! On a hunch, I then reconnected one bridge, like this -- and power was restored.

+---- house ----
                
+( 6v )-+( 6v )-
                
+( 6v )  ( 6v )-
                
+( 6v )  ( 6v )-
                
+( 6v )  ( 6v )-
                
+( 6v )  ( 6v )-
                
+(   new 12v  )-
                
+(   new 12v  )-

My best guess of what's going on is that the wires forming the positive and negative rails are not making good connections (due to corrosion, rust, broken wires etc), and so batteries further down are providing less and less power. The new 12v ones may not have been able to push power up to the house at all. (Or, perhaps having partially dead batteries hanging half-connected off the circuit has some effect that my meager electronics knowledge can't account for.) So got longer cables to connect the new batteries directly to the house, bypassing all the old stuff. That's working great -- house power never dropped below 11.9v last night, vs 11.1v the night before. The old battery bank might still be able to provide another day or so of power in a pinch, so I am going to keep them in there for now, but if I don't use them at all this winter I'll be recycling them. Astounding that those batteries were in use for 20 years.

I had a great time last week and the web engines hackfest! It was the 7th web hackfest hosted by Igalia and the 7th hackfest I attended. I m almost a local Galician already. Brazilian Portuguese being so close to Galician certainly helps! Collabora co-sponsored the event and it was great that two colleagues of mine managed to join me in attendance. It had great talks that will eventually end up in videos uploaded to the web site. We were amazed at the progress being made to Servo, including some performance results that blew our minds. We also discussed the next steps for WebKitGTK+, WebKit for Wayland (or WPE), our own Clutter wrapper to WebKitGTK+ which is used for the Apertis project, and much more.

Zan giving his talk on WPE (former WebKitForWayland)

One thing that drew my attention was how many Dell laptops there were. Many collaborans (myself included) and igalians are now using Dells, it seems. Sure, there were thinkpads and macbooks, but there was plenty of inspirons and xpses as well. It s interesting how the brand make up shifted over the years since 2009, when the hackfest could easily be mistaken with a thinkpad shop. Back to the actual hackfest: with the recent release of Gnome 3.22 (and Fedora 25 nearing release), my main focus was on dealing with some regressions suffered by users experienced after a change that made putting the final rendering composited by the nested Wayland compositor we have inside WebKitGTK+ to the GTK+ widget so it is shown on the screen. One of the main problems people reported was applications that use WebKitGTK+ not showing anything where the content was supposed to appear. It turns out the problem was caused by GTK+ not being able to create a GL context. If the system was simply not able to use GL there would be no problem: WebKit would then just disable accelerated compositing and things would work, albeit slower. The problem was WebKit being able to use an older GL version than the minimum required by GTK+. We fixed it by testing that GTK+ is able to create GL contexts before using the fast path, falling back to the slow glReadPixels codepath if not. This way we keep accelerated compositing working inside WebKit, which gives us nice 3D transforms and less repainting, but take the performance hit in the final blit .

Introducing WebKitClutterGTK+

Another issue we hit was GTK+ not properly updating its knowledge of the window s opaque region when painting a frame with GL, which led to some really interesting issues like a shadow appearing when you tried to shrink the window. There was also an issue where the window would not use all of the screen when fullscreen which was likely related. Both were fixed. Andr Magalh es also worked on a couple of patches we wrote for customer projects and are now pushing upstream. One enables the use of more than one frontend to connect to a remote web inspector server at once. This can be used to, for instance, show the regular web inspector on a browser window and also use IDE integration for setting breakpoints and so on. The other patch was cooked by Philip Withnall and helped us deal with some performance bottlenecks we were hitting. It improves the performance of painting scroll bars. WebKitGTK+ does its own painting of scrollbars (we do not use the GTK+ widgets for various reasons). It turns out painting scrollbars can be quite a hit when the page is being scrolled fast, if not done efficiently. Emanuele Aina had a great time learning more about meson to figure out a build issue we had when a more recent GStreamer was added to our jhbuild environment. He came out of the experience rather sane, which makes me think meson might indeed be much better than autotools.

Igalia 15 years cake

It was a great hackfest, great seeing everyone face to face. We were happy to celebrate Igalia s 15 years with them. Hope to see everyone again next year =)

Review: Uprooted, by Naomi Novik

Publisher:	Del Rey
Copyright:	2015
Printing:	2016
ISBN:	0-8041-7904-2
Format:	Kindle
Pages:	465

Agnieszka lives in a small peasant village on the border of the Wood. The malevolent forest is the source of dark corruption, illnesses that turn people into ravaging monsters, and lures and traps for the unwary who disappear into the Wood. Or, worse, return and appear the same, and then do horrific things, smiling all the time. This neighboring storehouse of horrors is not what occupies Agnieszka's thoughts at the start of the book, however. Instead, it's the village's protector against the Wood: the Dragon. The Dragon is not a flying lizard; he's a man, a wizard who has lived in his tower for living memory and fights back against the Wood with magic. And, once every ten years, he takes a girl from a village. They go to his tower and serve him for ten years, and then leave, generally to move to some far-away city and never return to their village. Each says afterwards that the Dragon never did anything untoward to them. No one entirely believes them. Agnieszka was born in the year that makes her one of the candidates for being taken by the Dragon. But that's not what she's worried about. She's known for certain since she was a small child that her best friend, Kasia, would be the one taken by the Dragon. Kasia was always the exceptional one: the most beautiful, the most talented, the one who stood out among all the girls in the neighboring villages. And she's about to be taken out of Agnieszka's life, to a mysterious and unknown fate. It will hopefully surprise no fantasy reader (and hence not be much of a spoiler) that awkward Agnieszka, who can't keep her dress unstained for more than five minutes and has none of the skills that Kasia has, is the one the Dragon chooses. I think a warning is important here, since I'm about to recommend this book highly. However, it is very fond of its stereotypes. Most of the other wizards are men, and they focus on books and formal understanding of magic. The one female wizard whose magic we see in some detail is a smith described as wearing male clothing. Uprooted then introduces a different type of magic that's much more intuitive, described largely through natural metaphors, and doesn't play well with formal rules... and is practiced by a woman. This is, unfortunately, persistently gendered, although the book never comes right out and calls it female magic. There are also quite a few traditional gender roles scattered through the rest of the book (although it does get a bit of a pass due to its obvious deep roots in traditional fairy tales). Uprooted is still an excellent book despite this, but it's best read when you're in the mood to tolerate this sort of story. If you go in feeling irritated about gender stereotypes, you'll probably get frustrated by the book, overwhelming its merits. Best saved for a forgiving mood (or skipped entirely if this style of story just doesn't sound fun). The beginning of Uprooted is about Agnieszka finding her feet in her bizarre arrangement with the Dragon, who turns out to be nothing like what either her or the reader expected. I think her panic and confusion drags on a little long, but Novik makes up for that by the delightful descriptions of Agnieszka's eventual understanding and the Dragon's frustrated consternation. Fantasy is full of prickly, arrogant wizards, but few have felt quite so human to me as the Dragon. Agnieszka is clearly nothing like he expected or like he's dealt with before, and his path from arrogant contempt to outrage to prickly confusion to uncomfortable respect is a delight. This is, of course, a coming-of-age story for Agnieszka, and by the end the book deals with both the origins of the Wood and some sort of resolution. But the path there wanders through an exploration of a rather interesting magic system, quite a lot of court intrigue, and Agnieszka persistently defying everyone's expectations. As with the introductory panic and confusion, I could have done with less of her awkward bumbling at court (in general, I think the book could have been a bit tighter), but once I reached the second half of the book I couldn't put it down. I've previously read a fair chunk of Novik's Temeraire series, which were fun (at least in spots), but Uprooted is definitely better. There is a fair bit of horror-tinged stuff in this book, as well as the stereotypes mentioned above, so it won't be for everyone. But I usually hate horror of any kind, and I still loved this. Agnieszka is sufficiently positive and solution-focused that the story never falls into the constant fear and panic and disgust that I particularly dislike in horror. If you're in the mood for a good fantasy coming-of-age story coupled with delightful disruption of the life of a prickly, cynical, but surprisingly ethical wizard, give this one a try. Rating: 8 out of 10

A new version of RcppGSL in now on CRAN and in Debian. The RcppGSL package provides an interface from R to the GNU GSL using our Rcpp package. This release is one that entirely focused on maintenance. CRAN asked us to change on aspect relative to vignettes, and we added a few more small updates related entirely to packaging. In other words, no user-facing changes. The NEWS file entries follows below:

Changes in version 0.3.1 (2016-10-02)

• The unit test driver was updated and simplified, (by request of CRAN) no longer leaves files in '/tmp', and removes two unexported (and unused) test helper functions (PR #10)
• Switched to run.sh for Travis (PR #11)
• Use canonical CRAN URLs in README.md
• Restored 'boxed' display of code in vignette (PR #12)

Courtesy of CRANberries, a summary of changes to the most recent release is available. More information is on the RcppGSL page. Questions, comments etc should go to the issue tickets at the GitHub repo.

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

Previously: v4.7. Here are a bunch of security things I m excited about in Linux v4.8: SLUB freelist ASLR Thomas Garnier continued his freelist randomization work by adding SLUB support. x86_64 KASLR text base offset physical/virtual decoupling On x86_64, to implement the KASLR text base offset, the physical memory location of the kernel was randomized, which resulted in the virtual address being offset as well. Due to how the kernel s -2GB addressing works (gcc s -mcmodel=kernel ), it wasn t possible to randomize the physical location beyond the 2GB limit, leaving any additional physical memory unused as a randomization target. In order to decouple the physical and virtual location of the kernel (to make physical address exposures less valuable to attackers), the physical location of the kernel needed to be randomized separately from the virtual location. This required a lot of work for handling very large addresses spanning terabytes of address space. Yinghai Lu, Baoquan He, and I landed a series of patches that ultimately did this (and in the process fixed some other bugs too). This expands the physical offset entropy to roughly $physical_memory_size_of_system / 2MB bits. x86_64 KASLR memory base offset Thomas Garnier rolled out KASLR to the kernel s various statically located memory ranges, randomizing their locations with CONFIG_RANDOMIZE_MEMORY. One of the more notable things randomized is the physical memory mapping, which is a known target for attacks. Also randomized is the vmalloc area, which makes attacks against targets vmalloced during boot (which tend to always end up in the same location on a given system) are now harder to locate. (The vmemmap region randomization accidentally missed the v4.8 window and will appear in v4.9.) x86_64 KASLR with hibernation Rafael Wysocki (with Thomas Garnier, Borislav Petkov, Yinghai Lu, Logan Gunthorpe, and myself) worked on a number of fixes to hibernation code that, even without KASLR, were coincidentally exposed by the earlier W^X fix. With that original problem fixed, then memory KASLR exposed more problems. I m very grateful everyone was able to help out fixing these, especially Rafael and Thomas. It s a hard place to debug. The bottom line, now, is that hibernation and KASLR are no longer mutually exclusive. gcc plugin infrastructure Emese Revfy ported the PaX/Grsecurity gcc plugin infrastructure to upstream. If you want to perform compiler-based magic on kernel builds, now it s much easier with CONFIG_GCC_PLUGINS! The plugins live in scripts/gcc-plugins/. Current plugins are a short example called Cyclic Complexity which just emits the complexity of functions as they re compiled, and Sanitizer Coverage which provides the same functionality as gcc s recent -fsanitize-coverage=trace-pc but back through gcc 4.5. Another notable detail about this work is that it was the first Linux kernel security work funded by Linux Foundation s Core Infrastructure Initiative. I m looking forward to more plugins! If you re on Debian or Ubuntu, the required gcc plugin headers are available via the gcc-$N-plugin-dev package (and similarly for all cross-compiler packages). hardened usercopy Along with work from Rik van Riel, Laura Abbott, Casey Schaufler, and many other folks doing testing on the KSPP mailing list, I ported part of PAX_USERCOPY (the basic runtime bounds checking) to upstream as CONFIG_HARDENED_USERCOPY. One of the interface boundaries between the kernel and user-space are the copy_to_user()/copy_from_user() family of functions. Frequently, the size of a copy is known at compile-time ( built-in constant ), so there s not much benefit in checking those sizes (hardened usercopy avoids these cases). In the case of dynamic sizes, hardened usercopy checks for 3 areas of memory: slab allocations, stack allocations, and kernel text. Direct kernel text copying is simply disallowed. Stack copying is allowed as long as it is entirely contained by the current stack memory range (and on x86, only if it does not include the saved stack frame and instruction pointers). For slab allocations (e.g. those allocated through kmem_cache_alloc() and the kmalloc()-family of functions), the copy size is compared against the size of the object being copied. For example, if copy_from_user() is writing to a structure that was allocated as size 64, but the copy gets tricked into trying to write 65 bytes, hardened usercopy will catch it and kill the process. For testing hardened usercopy, lkdtm gained several new tests: USERCOPY_HEAP_SIZE_TO, USERCOPY_HEAP_SIZE_FROM, USERCOPY_STACK_FRAME_TO,
USERCOPY_STACK_FRAME_FROM, USERCOPY_STACK_BEYOND, and USERCOPY_KERNEL. Additionally, USERCOPY_HEAP_FLAG_TO and USERCOPY_HEAP_FLAG_FROM were added to test what will be coming next for hardened usercopy: flagging slab memory as safe for copy to/from user-space , effectively whitelisting certainly slab caches, as done by PAX_USERCOPY. This further reduces the scope of what s allowed to be copied to/from, since most kernel memory is not intended to ever be exposed to user-space. Adding this logic will require some reorganization of usercopy code to add some new APIs, as PAX_USERCOPY s approach to handling special-cases is to add bounce-copies (copy from slab to stack, then copy to userspace) as needed, which is unlikely to be acceptable upstream. seccomp reordered after ptrace By its original design, seccomp filtering happened before ptrace so that seccomp-based ptracers (i.e. SECCOMP_RET_TRACE) could explicitly bypass seccomp filtering and force a desired syscall. Nothing actually used this feature, and as it turns out, it s not compatible with process launchers that install seccomp filters (e.g. systemd, lxc) since as long as the ptrace and fork syscalls are allowed (and fork is needed for any sensible container environment), a process could spawn a tracer to help bypass a filter by injecting syscalls. After Andy Lutomirski convinced me that ordering ptrace first does not change the attack surface of a running process (unless all syscalls are blacklisted, the entire ptrace attack surface will always be exposed), I rearranged things. Now there is no (expected) way to bypass seccomp filters, and containers with seccomp filters can allow ptrace again. That s it for v4.8! The merge window is open for v4.9

2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

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 With the increasing number of paid contributors, easy fixes (CVE with patches available) tend to be processed rather quickly. All the package I worked on had issues that were open for a long time because they were hard to handle. I prepared DLA-613-1 fixing 3 CVE on roundcube. The fix required to manually backport the CRSF handling code which was not available in the wheezy version. I spent almost 8 hours on roundcube. Then I started to work on tiff3. I reviewed many CVE: CVE-2016-3658, CVE-2015-7313, CVE-2015-7554, CVE-2015-8668, CVE-2016-5318, CVE-2016-3625, CVE-2016-5319. I updated their status for tiff3 in wheezy, requested reproducer files to people who reported the CVE when the files were not publicly available and made sure that everything was recorded in the upstream bug tracker. The 4.25 hours I spent on the package were not enough to work on patches, so I put the package back in the work queue. GNOME 3.22 transition I uploaded a new gnome-shell-timer that would work with GNOME 3.21 that had been uploaded to sid. Unfortunately, that new GNOME (and GTK+) version caused many regressions that affected Debian Testing (and thus Kali) users in particular in gnome-control-center. I uploaded a new version fixing some of those issues and I reported a bunch of them to upstream too (#771515, #771517, #771696). Kali I worked on #836211 creating a dpkg patch to work-around the overlayfs limitation (we use it in Kali because persistence of live system relies on overlayfs) and I contacted the upstream overlayfs maintainer to hopefully get a proper fix on the overlayfs side instead. I uploaded radcli 1.2.6-2.1 to fix RC bug #825121 as the package was removed from testing and openvas depends on it in Kali. As part of the pkg-security team, I sponsored/uploaded acccheck and arp-scan for Marcos Fouces, and p0f 3.09b as well. Misc Debian work Distro Tracker. I tested, fixed and merged Paul Wise s patch integrating multiarch hints into tracker.debian.org (#833623). Debian Handbook. I enabled the new Vietnamese translation on debian-handbook.info and updated all translations with Weblate updates. systemd units for apache2. I prepared systemd units for apache2 which I submitted in #798430. With approval of Stefan Fritsch, I committed my work to the git repository and then uploaded the result in version 2.4.23-5. Hindsight packaging. I first packaged lua-sandbox (#838969) which is a dependency of Hindsight and then Hindsight itself (#838968). In this process, I opened a couple of upstream tickets. PIE by default. I uploaded a new version of cpputest compiled with -fPIC so shat executable linking to its static library can be compiled with -fPIE (#837363, forwarded upstream here). Bugs filed. Bad homepage link in haskell-dice-entropy-conduit. Inconsistent options --onlyscripts and --noscripts in debhelper. pidgin entry in security-support-limited is out of date in debian-security-support. New upstream version (2.0.2) in puppet-lint. Thanks See you next month for a new summary of my activities.

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

Once a month I am involved in running an informal session, loosely affiliated with Open Rights Group and FSFE, called Cryptonoise. Cryptonoise explores methods for protecting your digital rights, with a leaning towards focusing on privacy, and provides a venue for like minded people to meet up and discuss the state of the digital landscape and those that may try to infringe on the rights of digital citizens. We ve all made it easy for large enterprises and governments to collect masses of data about our online activities because we perform most of those activities in the same place. Facebook, Google and Twitter spring to mind as examples of companies that have grown to dangerous sizes with little competition. This is not paranoia. This is real. We make it a lot more difficult when we spread out. Our meetups are held at 57North Hacklab and at the last meetup on the 29th September I set up a GNU Social instance for the members of 57North. GNU Social provides the same functionality as Twitter but as a decentralised federated network. Federation is a feature that is found in protocols like E-Mail, XMPP and SIP. It doesn t matter which server you re using, you can still talk to all the other users on all the other servers. While I m using social.57north.org.uk I can still follow FSF on status.fsf.org, for example, with no prior coordination with system administrators or anything complicated. It all just works. People have pointed out that I ve just introduced another point of centralisation but I don t see it necessarily as a bad thing. I think too many users in a single service starts to look dangerous but as long as user counts don t go too high I believe that the benefits of sharing the administrative workload (performing updates, monitoring, keeping the TLS cert current, etc.) far outweigh the effects of having a few extra users. I think 100 is probably about the maximum number I would be comfortable with, although I ll admit I ve not based this on anything and it s chosen arbitrarily. The jabber.ccc.de server is an example of a service that grew too large. It was set up by members of CCC and made available to all, but ended up becoming the de facto service for hackers. The jabber.ccc.de team have made appeals for others to set up their own servers, and you should. For a great overview and guide for setting up your own real-time commmunication servers, check out the RTC Quick Start Guide. This work was enabled by Shell who had previously set up a Central Authentication Service, which GNU Social already had a plugin to use as the authentication backend. No one likes to have a whole load of different passwords for different services and integration with this allows for identities to be consistent across the 57North services. She has also setup a Matrix homeserver, another step towards decentralisation and an end of reliance on centralised giants. If you have an account on a GNU Social instance, you can follow me here.

I have been working quite hard, along with my friend and colleague Richard Maw, on getting Gitano ready for a release suitable for inclusion into Debian Stretch. You can see how we're doing on the various Trello boards for:

• Gitano
• Clod
• Gall
• Lace
• Tongue
• Supple

As Richard and I work toward a version of Gitano we're prepared to support long-term in Debian we are making many changes to make our lives easier. For those of you who have been using Gitano over the past few years, you'll need to pay attention to some postings which will be coming soon about how to make the changes you need so as to not explode horribly when you upgrade to the version we're releasing soon. For those of you who are not yet using Gitano but feel like you might want to; I'll also be producing some postings about getting started with the packages. And for those happily running current HEAD of Gitano already, I'll be posting about some of the new features over the next little while in case you're not aware of them.

IMPORTANT: If you're using Gitano already and have any issues or feature requests then please please please let me know ASAP otherwise they're unlikely to be resolved/implemented before 1.0. irl already asked for the facility to verify GPG signed commits and tags, but if you want anything else considering then I need to know v. soon. (Ideally email me, but you may comment on this posting too if you must)

Shipping Position Independent Executables and using read-only Global Offset Table was already possible for packages but needed package maintainers to opt-in for each package (see Hardening wiki) using the pie and bindnow Dpkg hardening flags. Many critical packages enabled the extra flags but there are still way more left out according to Lintian hardening-no-bindnow and hardening-no-pie warnings. Now we can change that. We can make those hardening flags the default for every package.
We already have the needed patches for GCC (#835148) and dpkg (#835146, #835149). We already have all packages rebuilt once to test which breaks (Thanks to Lucas Nussbaum!). The Release Team already asked porters if they feel their ports ready for enabling PIE and most ports tentatively opted-in (Thanks to Niels Thykier for pushing this!). What is left is fixing the ~75 open bugs found during the test rebuilds and this is where You can help, too! Please check if your packages are affected or give a helping hand to other maintainers who need it. (See PIEByDefaultTransition wiki for hints on fixing the bugs.) Many thanks to those who already fixed their packages! If we can get past those last bugs we can enable those badly needed security features and make Stretch the most secure release ever!

So this morning, along with a few other members of staff, I was filmed for a Diversity and Inclusion video for Ada Lovelace Day at work. Very positive experience, and I was wearing my rainbow chain mail necklace made by the wonderful Rosemary Warner, and a safety pin, which I had to explain the meaning of to the two peeps doing the filming. We all of us read the same script, and they are going to paste it together with each of us saying one sentence at a time. The script was not just about gender, it also mentioned age, skills, sexual orientation and physical ability among other things (I cannot remember the entire list). I was very happy and proud to take part.

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you. Debian Android

• I sponsored a new upstream release of android-platform-tools-base prepared by Kai-Chung Yan and Chirayu Desai.

Debian Games

• I packaged a new upstream release of hyperrogue, a rogue-like game settled in a non-euclidian world, fixing one RC bug (#811991). I uploaded two more revisions later that addressed build failures on arm64 and hppa.
• I fixed more RC bugs (build failures with GCC-6) in torus-trooper (#835712) and fife (#811858).
• I packaged new upstream releases of pygame-sdl2, renpy, freeorion, netrek-client-cow, redeclipse, redeclipse-data, hitori, atomix, adonthell and adonthell-data.
• I updated gtkballs and fixed a documentation bug (#820588) but also a /usr/share/locale issue that prevented the actual use of the translations.
• I raised the severity of #797998 to grave in unknown-horizons because the game cannot be started currently. In order to fix this issue I packaged a new build-dependency, fifechan, which is currently awaiting approval by the FTP team. As soon as fifechan got accepted I will upload new upstream releases of fife and unknown-horizons.
• I released debian-games 1.5, a Debian blend and collection of games metapackages.
• Hardening-wrapper has been deprecated for some time and this issue became release critical now. I updated cookietool, alex4 and netrek-client-cow to use dpkg-buildflags instead.
• Together with Russel Coker I packaged a new upstream release of warzone2100. This package would benefit from a new regular uploader. If you are interested in it, please get involved. (Same story for hyperrogue, redeclipse, renpy and unknown-horizons and many other games.)
• I started a new Bullet transition (#839243). The package is currently waiting in the NEW queue and I hope to complete this work in October.
• I triaged #838199 and reassigned the issue to fonts-roboto. Initially I prepared an NMU but eventually the maintainer uploaded a new revision himself. It is now possible to install the hinted and unhinted versions of fonts-roboto together which also resolved former installation problems with kodi and freeorion.

Debian Java

• I packaged new upstream releases of undertow, activemq and jackrabbit.
• I fixed RC bugs in libphonenumber (#836768), wagon2 (#837022) and activemq (#839244).
• I updated syncany in experimental and simplified the packaging a little. Unfortunately upstream has been on hiatus for the past year and we haven t seen new releases in the meantime. Nevertheless give it a try, even though it is still alpha software, it s an useful cloud-storage and synchronization tool.
• I sponsored a new upstream release of freeplane for Felix Natter.
• I prepared and uploaded security updates for jackrabbit and zookeeper in Jessie.

Debian LTS This was my eight month as a paid contributor and I have been paid to work 12,25 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:

• From 12. September until 19. September I was in charge of our LTS frontdesk. I triaged bugs in tiff3, mysql-5.5, curl, dropbear, mantis, icu, dwarfutils, jackrabbit, zendframework, zookeeper and graphicsmagick. For the latter I skimmed through all commits since the last version to identify the patches that fix the recent issues in graphicsmagick. I also answered questions on the mailing list and contacted Diego Biurrun again about his progress with libav. It is now anticipated that Hugo Lefeuvre and Diego will issue a new libav security release this month.
• I reviewed and tested a patch by Rapha l Hertzog for roundcube.
• DLA-629-1. Issued a security update for jackrabbit fixing 1 CVE.
• DLA-630-1. Issued a security update for zookeeper fixing 1 CVE.
• DLA-633-1. Issued a security update for wordpress fixing 7 CVE. This one also required backports of certain functions from newer releases and a database upgrade that required careful testing.
• I also issued DLA-622-1 and DLA-623-1, two security issues that I already mentioned last month. It was discovered that Debian s versions of Tomcat were vulnerable to a root privilege escalation issue. However it was also necessary that another exploit, for instance in a web application, could be used to gain write access as the tomcat user. Former security issues were already fixed and new ones are not known. Nevertheless since a zero-day exploit could not be ruled out, the issue was embargoed for a month to give other distributions time to fix this issue as well. You can read more about this topic at legalhackers.com.

Non-maintainer uploads

• I fixed various RC bugs in several games that are not maintained by the Games Team. The following games will be available in Stretch again soon: solarwolf, enigma, open-invaders, crrcsim, noiz2sa, csmash, csmash-demosong and glob2.

Misc

• I packaged a new upstream release of MediathekView.
• I uploaded a new revision of xarchiver and applied a patch from Helmut Grohne that made it possible to cross-build the package.

Trust is important in any kind of interpersonal relationship. It's inevitable that there will be cases where something you do will irritate or upset others, even if only to a small degree. Handling small cases well helps build trust that you will do the right thing in more significant cases, whereas ignoring things that seem fairly insignificant (or saying that you'll do something about them and then failing to do so) suggests that you'll also fail when there's a major problem. Getting the small details right is a major part of creating the impression that you'll deal with significant challenges in a responsible and considerate way.

This isn't limited to individual relationships. Something that distinguishes good customer service from bad customer service is getting the details right. There are many industries where significant failures happen infrequently, but minor ones happen a lot. Would you prefer to give your business to a company that handles those small details well (even if they're not overly annoying) or one that just tells you to deal with them?

And the same is true of software communities. A strong and considerate response to minor bug reports makes it more likely that users will be patient with you when dealing with significant ones. Handling small patch contributions quickly makes it more likely that a submitter will be willing to do the work of making more significant contributions. These things are well understood, and most successful projects have actively worked to reduce barriers to entry and to be responsive to user requests in order to encourage participation and foster a feeling that they care.

But what's often ignored is that this applies to other aspects of communities as well. Failing to use inclusive language may not seem like a big thing in itself, but it leaves people with the feeling that you're less likely to do anything about more egregious exclusionary behaviour. Allowing a baseline level of sexist humour gives the impression that you won't act if there are blatant displays of misogyny. The more examples of these "insignificant" issues people see, the more likely they are to choose to spend their time somewhere else, somewhere they can have faith that major issues will be handled appropriately.

There's a more insidious aspect to this. Sometimes we can believe that we are handling minor issues appropriately, that we're acting in a way that handles people's concerns, while actually failing to do so. If someone raises a concern about an aspect of the community, it's important to discuss solutions with them. Putting effort into "solving" a problem without ensuring that the solution has the desired outcome is not only a waste of time, it alienates those affected even more - they're now not only left with the feeling that they can't trust you to respond appropriately, but that you will actively ignore their feelings in the process.

It's not always possible to satisfy everybody's concerns. Sometimes you'll be left in situations where you have conflicting requests. In that case the best thing you can do is to explain the conflict and why you've made the choice you have, and demonstrate that you took this issue seriously rather than ignoring it. Depending on the issue, you may still alienate some number of participants, but it'll be fewer than if you just pretend that it's not actually a problem.

One warning, though: while building trust in this way enhances people's willingness to join your community, it also builds expectations. If a significant issue does arise, and if you fail to handle it well, you'll burn a lot of that trust in the process. The fact that you've built that trust in the first place may be what saves your community from disintegrating completely, but people will feel even more betrayed if you don't actively work to rebuild it. And if there's a pattern of mishandling major problems, no amount of getting the details right will matter.

Communities that ignore these issues are, long term, likely to end up weaker than communities that pay attention to them. Making sure you get this right in the first place, and setting expectations that you will pay attention to your contributors, is a vital part of building a meaningful relationship between your community and its members.

comments

This would be a longish post. I had bought a Samsung Galaxy J-5/500 just a few days before Debconf16 which I had written about a bit earlier as well. As can be seen in the specs there isn t much to explore other than A-GPS. There were a couple of temperature apps. which I wanted to explore before buying the smartphone but as there were budget constraints and there weren t any good budget smartphones with environmental sensors built-in had to let go of those features. I was looking for a free app. which would have OSM support and came across osmand . I was looking for an app. which would have support for OSM and support for the gpx format. I was planning to use osmand in South Africa but due to the over-whelming nature of meeting people, seeing places and just being didn t actually get the time and place to try it. Came back home and a month and a half passed. In-between I had done some simple small tracks but nothing major. This week-end I got the opportunity as I got some free data balance from my service provider (a princely 50 MB) as well an opportunity to go about 40 odd kms. from the city. I had read about osmand and was looking if the off-line method worked or not from the webpage Works online (fast) or offline (no roaming charges when you are abroad) So armed with a full battery I started the journey which took about an hour and half even though technically it was a holiday. On the way back, got a different route and recorded that as well. The app. worked flawlessly. I was able to get the speed of the vehicle and everything. The only thing I haven t understood till date is how to select waypoints but other than that I got the whole route on my mobile. What was cool to see that on most roads, at least through the app. there were speed limits. Now I don t know from where the data was getting there. Most city roads had 65 and some roads had 55 at the maximum. I am assuming that it was at km/hr as also shared later. Just for fun I also looked at the gpx file after copying it from mobile to hdd (an extract) https://paste.debian.net/853231/ While it s not a complete extract, What was interesting for me to note here is the time was in UTC . What was also interesting is that in the gpx tracks I also saw some entries about speed as can be seen in the paste above. Although it doesn t say whether it was in km/hr or mph, I believe it probably is km/hr. as that is the unit I defined in the app. Anyways, the next step was trying to see which tool was good enough to show me the tracks with tiles underneath and labels of places, paths etc. I tried three tools 1. jmapviewer this didn t work at all.
2. gnome-maps this worked remarkably well but has numerous gtk3.0 warnings [shirish@debian] - [~/osmand] - [10149]
[$] gnome-maps 2016-10-01_08-11_Sat.gpx (gnome-maps:21017): Gtk-WARNING **: Theme parsing error: gtk.css:63:28: The :prelight pseudo-class is deprecated. Use :hover instead. (gnome-maps:21017): Gtk-WARNING **: Theme parsing error: gtk.css:73:35: The :prelight pseudo-class is deprecated. Use :hover instead. (gnome-maps:21017): Gtk-WARNING **: Theme parsing error: application.css:14:30: The style property GtkButton:image-spacing is deprecated and shouldn't be used anymore. It will be removed in a future version (gnome-maps:21017): Gtk-WARNING **: Theme parsing error: application.css:15:31: The style property GtkWidget:interior-focus is deprecated and shouldn't be used anymore. It will be removed in a future version (gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window (gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window (gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window (gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window (gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window (gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window (gnome-maps:21017): Gtk-WARNING **: GtkClutterOffscreen 0x4c4f3f0 is drawn without a current allocation. This should not happen. (gnome-maps:21017): Gtk-WARNING **: GtkImage 0x4ed4140 is drawn without a current allocation. This should not happen. Now I m not sure whether all of those are gtk3+ issues or me running them under Debian MATE. I know that there are issues with mate and gtk3+ as had been told/shared a few times in p.d.o. Anyways, one of the issues I encountered is that gnome-maps doesn t work in offline-mode, saw https://bugzilla.gnome.org/show_bug.cgi?id=708799 . Also saw ~/.cache/champlain/osm-mapquest and the listing underneath is gibberish in the sense you don t know what it meant to do
[shirish@debian] - [~/.cache/champlain/osm-mapquest] - [10163]
[$] ll -h drwx------ 6 shirish shirish 4.0K Jun 11 2015 10
drwx------ 26 shirish shirish 4.0K Oct 24 2014 11
drwx------ 10 shirish shirish 4.0K Jun 11 2015 12
drwx------ 11 shirish shirish 4.0K Jun 11 2015 13
drwx------ 12 shirish shirish 4.0K Jun 11 2015 14
drwx------ 12 shirish shirish 4.0K Jun 11 2015 15
drwx------ 27 shirish shirish 4.0K Oct 24 2014 16
drwx------ 25 shirish shirish 4.0K Oct 24 2014 17
drwx------ 4 shirish shirish 4.0K Mar 4 2014 3
drwx------ 5 shirish shirish 4.0K Mar 4 2014 8
drwx------ 9 shirish shirish 4.0K Mar 29 2014 9
What was/is interesting to see things like this As I was in a moving vehicle, it isn t easy to know if the imagery is at fault or was it app. , sensor of my mobile ? Did see http://learnosm.org/en/josm/correcting-imagery-offset/ but as can be seen that requires more effort from my side. The last tool proved to be the most problematic 3. JOSM Getting the tracks into josm which was easily done. While firing up josm came across https://josm.openstreetmap.de/ticket/13735 which I subsequently filed. One of the other first things which has been a major irritant for a long time is JOSM is, for a lack of better term, ugly. See the interface, especially the one having preferences, all cluttered look and specifically see the plugins corner/tab The part about it being ugly, I dunno but have seen most java apps are a bit ugly. It is a bit generalist I know but that has been my experience with whatever little java apps. I have used. I don t know what the reasons for that are, maybe because java is known/rumoured to use lot of memory which seems true in my case as well OR it doesn t have toolkits like gtk3+ or qt quick, although have to say that the looks have improved from before when I used it last some years ago
[shirish@debian] - [~] - [10340]
[$] ps -eo size,pid,user,command awk ' hr=$1/1024 ; printf("%13.6f Mb ",hr) for ( x=4 ; x<=NF ; x++ ) printf("%s ",$x) print "" ' grep josm 0.324219 Mb /bin/sh /usr/bin/josm
419.468750 Mb /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Djosm.restart=true -Djava.net.useSystemProxies=true -jar /usr/share/josm/josm.jar
This is when I m just opening josm and have not added any tracks or done any work. Now I wanted to explore the routing in good amount of detail on josm. This was easily said than done. When trying to get imagery I got the Download area too large issue/defect . Multiple tries didn t get me anywhere. Then hunting on the web came across the continous-download plugin which is part of the plugin infrastructure . This I found to be a very good tool. It downloads the tiles and puts them in ~/.josm/cache/tiles
[shirish@debian] - [~/.josm/cache/tiles] - [10147]
[$] ll -h total 28M
-rw-r--r-- 1 shirish shirish 28M Oct 2 02:13 TMS_BLOCK_v2.data
-rw-r--r-- 1 shirish shirish 290K Oct 3 12:59 TMS_BLOCK_v2.key
-rw-r--r-- 1 shirish shirish 4 Oct 3 12:59 WMS_BLOCK_v2.key
-rw-r--r-- 1 shirish shirish 4 Oct 3 12:59 WMTS_BLOCK_v2.key
While unfortunately I cannot see this/make sense of it I m guessing it is some sort of database with key and data files. What did become apparent is that the OSM needs lots more love if it is to become something which can be used everyday. At the end I had to change the open-source gpx track file to a Google map kml file to be able to make sense as there are whole areas which need to be named, numbered etc. One of the newbie mistakes that I did was trying to use the slippy map in josm (using Openstreetmap/Mapnik at the back-end) to move/pan using the left-hand mouse button. It took me quite sometime to figure out that it is with right-hand mouse button that you can make the slippy map pan. This is different from almost all maps, gnome-maps uses the traditional left-hand button, Google maps also uses the same. I have filed it in upstream as https://josm.openstreetmap.de/ticket/13751 . So at least, in these rounds it is gnome-maps which has kind of won even though it doesn t do any of the things that josm claims to do. I am sure there might be some interesting tricks and tips that people might have to share about mapping
Filed under: Miscellenous Tagged: #Debconf16, #GNOME-MAPS, #JOSM, OSM

10 years ago I first blogged about getting glasses [1]. I ve just ordered my 4th pair of glasses. When you buy new glasses the first step is to scan your old glasses to use that as a base point for assessing your eyes, instead of going in cold and trying lots of different lenses they can just try small variations on your current glasses. Any good optometrist will give you a print-out of the specs of your old glasses and your new prescription after you buy glasses, they may be hesitant to do so if you don t buy because some people get a prescription at an optometrist and then buy cheap glasses online. Here are the specs of my new glasses, the ones I m wearing now that are about 4 years old, and the ones before that which are probably about 8 years old:

	New	4 Years Old	Really Old
R-SPH	0.00	0.00	-0.25
R-CYL	-1.50	-1.50	-1.50
R-AXS	180	179	180
L-SPH	0.00	-0.25	-0.25
L-CYL	-1.00	-1.00	-1.00
L-AXS	5	10	179

The Specsavers website has a good description of what this means [2]. In summary SPH is whether you are log-sighted (positive) or short-sighted (negative). CYL is for astigmatism which is where the focal lengths for horizontal and vertical aren t equal. AXS is the angle for astigmatism. There are other fields which you can read about on the Specsavers page, but they aren t relevant for me. The first thing I learned when I looked at these numbers is that until recently I was apparently slightly short-sighted. In a way this isn t a great surprise given that I spend so much time doing computer work and very little time focusing on things further away. What is a surprise is that I don t recall optometrists mentioning it to me. Apparently it s common to become more long-sighted as you get older so being slightly short-sighted when you are young is probably a good thing. Astigmatism is the reason why I wear glasses (the Wikipedia page has a very good explanation of this [3]). For the configuration of my web browser and GUI (which I believe to be default in terms of fonts for Debian/Unstable running KDE and Google-Chrome on a Thinkpad T420 with 1600 900 screen) I can read my blog posts very clearly while wearing glasses. Without glasses I can read it with my left eye but it is fuzzy and with my right eye reading it is like reading the last line of an eye test, something I can do if I concentrate a lot for test purposes but would never do by choice. If I turn my glasses 90 degrees (so that they make my vision worse not better) then my ability to read the text with my left eye is worse than my right eye without glasses, this is as expected as the 1.00 level of astigmatism in my left eye is doubled when I use the lens in my glasses as 90 degrees to it s intended angle. The AXS numbers are for the angle of astigmatism. I don t know why some of them are listed as 180 degrees or why that would be different from 0 degrees (if I turn my glasses so that one lens is rotated 180 degrees it works in exactly the same way). The numbers from 179 degrees to 5 degrees may be just a measurement error.

• [1] https://etbe.coker.com.au/2006/09/20/vision/
• [2] https://www.specsavers.com.au/glasses/your-prescription
• [3] https://en.wikipedia.org/wiki/Astigmatism_(eye)

Previously: v4.6. Onward to security things I found interesting in Linux v4.7: KASLR text base offset for MIPS Matt Redfearn added text base address KASLR to MIPS, similar to what s available on x86 and arm64. As done with x86, MIPS attempts to gather entropy from various build-time, run-time, and CPU locations in an effort to find reasonable sources during early-boot. MIPS doesn t yet have anything as strong as x86 s RDRAND (though most have an instruction counter like x86 s RDTSC), but it does have the benefit of being able to use Device Tree (i.e. the /chosen/kaslr-seed property) like arm64 does. By my understanding, even without Device Tree, MIPS KASLR entropy should be as strong as pre-RDRAND x86 entropy, which is more than sufficient for what is, similar to x86, not a huge KASLR range anyway: default 8 bits (a span of 16MB with 64KB alignment), though CONFIG_RANDOMIZE_BASE_MAX_OFFSET can be tuned to the device s memory, giving a maximum of 11 bits on 32-bit, and 15 bits on EVA or 64-bit. SLAB freelist ASLR Thomas Garnier added CONFIG_SLAB_FREELIST_RANDOM to make slab allocation layouts less deterministic with a per-boot randomized freelist order. This raises the bar for successful kernel slab attacks. Attackers will need to either find additional bugs to help leak slab layout information or will need to perform more complex grooming during an attack. Thomas wrote a post describing the feature in more detail here: Randomizing the Linux kernel heap freelists. (SLAB is done in v4.7, and SLUB in v4.8.) eBPF JIT constant blinding Daniel Borkmann implemented constant blinding in the eBPF JIT subsystem. With strong kernel memory protections (CONFIG_DEBUG_RODATA) in place, and with the segregation of user-space memory execution from kernel (i.e SMEP, PXN, CONFIG_CPU_SW_DOMAIN_PAN), having a place where user-space can inject content into an executable area of kernel memory becomes very high-value to an attacker. The eBPF JIT was exactly such a thing: the use of BPF constants could result in the JIT producing instruction flows that could include attacker-controlled instructions (e.g. by directing execution into the middle of an instruction with a constant that would be interpreted as a native instruction). The eBPF JIT already uses a number of other defensive tricks (e.g. random starting position), but this added randomized blinding to any BPF constants, which makes building a malicious execution path in the eBPF JIT memory much more difficult (and helps block attempts at JIT spraying to bypass other protections). Elena Reshetova updated a 2012 proof-of-concept attack to succeed against modern kernels to help provide a working example of what needed fixing in the JIT. This serves as a thorough regression test for the protection. The cBPF JITs that exist in ARM, MIPS, PowerPC, and Sparc still need to be updated to eBPF, but when they do, they ll gain all these protections immediatley. Bottom line is that if you enable the (disabled-by-default) bpf_jit_enable sysctl, be sure to set the bpf_jit_harden sysctl to 2 (to perform blinding even for root). fix brk ASLR weakness on arm64 compat There have been a few ASLR fixes recently (e.g. ET_DYN, x86 32-bit unlimited stack), and while reviewing some suggested fixes to arm64 brk ASLR code from Jon Medhurst, I noticed that arm64 s brk ASLR entropy was slightly too low (less than 1 bit) for 64-bit and noticeably lower (by 2 bits) for 32-bit compat processes when compared to native 32-bit arm. I simplified the code by using literals for the entropy. Maybe we can add a sysctl some day to control brk ASLR entropy like was done for mmap ASLR entropy. LoadPin LSM LSM stacking is well-defined since v4.2, so I finally upstreamed a small LSM that implements a protection I wrote for Chrome OS several years back. On systems with a static root of trust that extends to the filesystem level (e.g. Chrome OS s coreboot+depthcharge boot firmware chaining to dm-verity, or a system booting from read-only media), it s redundant to sign kernel modules (you ve already got the modules on read-only media: they can t change). The kernel just needs to know they re all coming from the correct location. (And this solves loading known-good firmware too, since there is no convention for signed firmware in the kernel yet.) LoadPin requires that all modules, firmware, etc come from the same mount (and assumes that the first loaded file defines which mount is correct , hence load pinning ). That s it for v4.7. Prepare yourself for v4.8 next!

2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Review: Winds of Fury, by Mercedes Lackey

Series:	Mage Winds #3
Publisher:	DAW
Copyright:	August 1994
ISBN:	0-88677-612-0
Format:	Mass market
Pages:	427

This is the concluding book of the Mage Winds trilogy and a direct sequel to Winds of Change. This series doesn't make sense to read out of order. In traditional fantasy trilogies of this type, the third book is often the best. The author can stop developing characters, building the world, and setting the scene and can get to the meat of the story. All the guns on the mantles go off, all the twists the author has been saving can be used, and there's usually a lot more action than in the second book of a trilogy. That is indeed the case here. I'm not sure Winds of Fury rises to the level of a good book, but if you're invested in the Valdemar story, it works better than the previous books of this series. As one might expect, the protagonists do return to Valdemar, finally. The method of that return makes sense of some things that happened in Winds of Change and is an entertaining surprise, although I wish more had been done with it through the rest of the book and we'd gotten more world-building details. I also like how Lackey handles the Valdemar reactions to the returning protagonists, and their own reactions to Valdemar. Lackey's characters might fit some heavy-handed stereotypes a bit too neatly, but they do grow and change over the course of a series, and the return home is a good technique for showing that. Lackey also throws in her final twist for the villains of this series at the start of this book, and it's a good one (if typical Lackey; she does love her abused youth characters). The villains are still far too one-dimensional and far too stereotyped evil, but the twist (which I'll avoid spoiling) does make that dynamic a bit more interesting. And she manages to get the reader to root for one evil over another, since one of them is at least competent. You'd think from the direction the series was taking that Winds of Fury would culminate in another epic war of magic, but not this book. Lackey takes a more personal and targeted approach, heavier on characterization and individual challenge. This gives Firesong a chance to grow into an almost-likable character and earn some of that empathy and insight that he'd gotten for free. Unfortunately, it sidelines Nyara a lot, and pushes her back into a stereotyped role, which made me sad. The series otherwise emphasizes the importance of magic users who know their own limitations and can thoughtfully use the power they have, but rarely extends that to Nyara herself. I would have much rather seen her play a role like that in the final climax instead of the one she played. This is partly made up for by centering Need in the story and having her play the key connecting role between two different threads of effort. Those are probably the best parts of this book. I wish the entire series had been told from Need's perspective, with a heavy helping of exasperated grumbling, although I don't think Lackey could have written that series. But what we get of her is a delight. The gryphons, sadly, are relegated to fairly minor roles, but we get a few more tantalizing hints about the Companions to make up for it. (Although not enough to figure out their great mystery, which isn't revealed until future books.) This series is nowhere near as good as I remembered, sadly, but I did enjoy bits of it. If you like Valdemar in general, the world building is fairly important and reveals quite a lot about the underpinnings and power dynamics of Lackey's universe. I'm not sure that makes up for some tedious characters, poor communication, and some uncomfortable and dragging sections, but if you're trying to get the whole Valdemar story, the events here are rather important. And this ending was at least entertaining, if not great fiction. Rating: 6 out of 10

FTP assistant This month I was rather busy with other stuff and only marked 191 packages for accept and rejected 21 packages. I also sent 6 emails to maintainers asking questions. Debian LTS This was my twenty-seventh month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 12.25h. During that time I did an upload of php5 fixing 17 CVEs and two additional bugs, I uploaded mactelnet and fixed one CVE. I also prepared a package for testing of zendframework, which will fix one CVE. Unfortunately my bind9 upload needed to be postponed as Florian Weimer found an incomplete patch of a previous CVE. I am trying to fix that as well. I also had some progress with the asterisk CVEs and of course the next round of php5 patches is waiting This month I also had a few days of frontdesk work at the beginning of the month and a few days at the end. Other stuff For the Alljoyn framework I uploaded alljoyn-services-1604 and as I forgot a Conflict:, I had to take care of RC-bugs: #836717, #836718 and #836719. Thanks a lot to Ralf Treinen for his automatic installation tests. As mentioned earlier, openzwave is on its way to the Debian archive. While it is still in non-free, the author of a used library gave his permission to relicense this code, so the way to main is paved now.

the last two weeks have seen the migration of perl 5.24 into testing, most of the bugs I worked on were related to it. additionally a few more build dependencies on tzdata werde needed. here's the list:

• #784845 libdevel-gdb-perl: "libdevel-gdb-perl: FTBFS: t/expect.t #8 sometimes fails"
  skip brittle test (pkg-perl)
• #825629 src:libgd-perl: "libgd-perl: FTBFS: Could not find gdlib-config in the search path. "
  add patch to use pkg-config instead of the removed gdlib-config (pkg-perl)
• #832840 src:license-reconcile: "license-reconcile: FTBFS: dh_auto_test: perl Build test --verbose 1 returned exit code 255"
  sponsor upload prepared by gfa (pkg-perl)
• #838310 keyboard-configuration: "keyboard-configuration: user configuration lost + error message from setupcon"
  propose a patch
• #838851 libcoro-perl: "libcoro-perl: FTBFS with Perl 5.24: panic: corrupt saved stack index -144185424"
  resurrect parts of the removed patch (pkg-perl)
• #838933 libio-compress-lzma-perl: "libio-compress-lzma-perl: uninstallable and unbuildable with Perl 5.24"
  fix dependencies (pkg-perl)
• #838934 libperl-apireference-perl: "libperl-apireference-perl: FTBFS with Perl 5.24.1"
  add support for 5.24.1 (pkg-perl)
• #839187 sa-compile: "sa-compile: failed make after perl upgraded to 5.24.1~rc3-3 on testing"
  close on suggestion of submitter after investigation
• #839442 src:libtime-parsedate-perl: "libtime-parsedate-perl: FTBFS: Tests failures"
  add build dependency on tzdata (pkg-perl)
• #839477 src:libposix-strftime-compiler-perl: "libposix-strftime-compiler-perl: FTBFS: dh_auto_test: perl Build test --verbose 1 returned exit code 5"
  add build dependency on tzdata (pkg-perl)
• #839513 src:libapache-logformat-compiler-perl: "libapache-logformat-compiler-perl: FTBFS: dh_auto_test: perl Build test --verbose 1 returned exit code 8"
  add build dependency on tzdata (pkg-perl)
• #839516 src:libclass-date-perl: "libclass-date-perl: FTBFS: Tests failures"
  add build dependency on tzdata (pkg-perl)

If you just install the snmp package out of the box, you won't get the MIBs, so it's pretty much useless for anything vendor without some setup. I'm sure this is documented somewhere, but I have to figure it out afresh every single time, so this time I'm writing it down; I can't possibly be the only one getting confused. First, install snmp-mibs-downloader from non-free. You'll need to work around bug #839574 to get the Cisco MIBs right:

# cp /usr/share/doc/snmp-mibs-downloader/examples/cisco.conf /etc/snmp-mibs-downloader/
# gzip -cd /usr/share/doc/snmp-mibs-downloader/examples/ciscolist.gz > /etc/snmp-mibs-downloader/ciscolist

Now you can download the Cisco MIBs:

# download-mibs cisco

However, this only downloads them; you will need to modify snmp.conf to actually use them. Comment out the line that says mibs : , and then add:

mibdirs +/var/lib/snmp/mibs/cisco/

Voila! Now you can use snmpwalk with e.g. -m AIRESPACE-WIRELESS-MIB to get the full range of Cisco WLC objects (and the first time you do so as root or the Debian-snmp user, the MIBs will be indexed in /var/lib/snmp/mib_indexes/.)