Subscribe: Planet Debian
Added By: Feedage Forager Feedage Grade B rated
Language: English
code  debconf  debian  lib site  library  local lib  months  package  packages  people  site library  time  usr local  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Planet Debian

Planet Debian

Planet Debian -


Dirk Eddelbuettel: RcppArmadillo 0.7.960.1.1

Sun, 20 Aug 2017 19:20:00 +0000

On the heels of the very recent bi-monthly RcppArmadillo release comes a quick bug-fix release 0.7.960.1.1 which just got onto CRAN (and I will ship a build to Debian in a moment). There were three distinct issues I addressed in three quick pull requests: The excellent Google Summer of Code work by Binxiang Ni had only encountered direct use of sparse matrices as produced by the Matrix. However, while we waited for 0.7.960.1.0 to make it onto CRAN, the quanteda package switched to derived classes---which we now account for via the is() method of our S4 class. Thanks to Kevin Ushey for reminding me we had is(). We somehow missed to account for the R 3.4.* and Rcpp 0.12.{11,12} changes for package registration (with .registration=TRUE), so ensured we only have one fastLm symbol. The build did not take not too well to systems without OpenMP, so we now explicitly unset supported via an Armadillo configuration variable. In general, client packages probably want to enable C++11 support when using OpenMP (explicitly) but we prefer to not upset too many (old) users. However, our configure check now also wants g++ 4.7.2 or later just like Armadillo. Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language--and is widely used by (currently) 382 other packages on CRAN---an increase of 52 since the CRAN release in June! Changes in this release relative to the previous CRAN release are as follows: Changes in RcppArmadillo version 0.7.960.1.1 (2017-08-20) Added improved check for inherited S4 matrix classes (#162 fixing #161) Changed fastLm C++ function to fastLm_impl to not clash with R method (#164 fixing #163) Added OpenMP check for configure (#166 fixing #165) Courtesy of CRANberries, there is a diffstat report. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge 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. [...]

Steinar H. Gunderson: Random codec notes

Sun, 20 Aug 2017 19:15:31 +0000


Post-Solskogen, there hasn't been all that many commits in the main Nageru repository, but that doesn't mean the project is standing still. In particular, I've been working with NVIDIA to shake out a crash bug in their drivers (which in itself uncovered some interesting debugging techniques, although in the end, the bug turned out just to be uncovered by the boring standard technique of analyzing crash dumps and writing a minimal program to reproduce). But I've also been looking at intraframe codecs; my sort-of plan was to go to VideoLAN Dev Days to present my findings, but unfortunately, there seems to be a schedule conflict, so instead, you can have some scattered random notes:

  • JPEG is really impressive technology. It's made in 1992, and it's still frighteningly close to state of the art! Beating it without getting a lot slower isn't trivial at all; witness that even with WebP etc., we still don't have a JPEG-killer because it's just so incredibly good. (Granted, in 1992, decompressing a JPEG would easily take half a minute or more.)
  • rANS is pretty neat; it gives you almost all the advantages of arithmetic coding, but does without divisions in the decoder (and if you have static probabilities and fast high multiplies, also in the encoder). I still don't feel like I understand it fully, though. And it has the odd property of having to encode and decode in different directions, which may or may not be a problem to you. But ryg's interleaving tricks to get SIMD are pretty nice; I won't claim to fully understand those either. Maybe I will need to eventually.
  • GPU performance models continue to bend my head. GPUs may have managed to make a parallel programming model that people actually manage to use, but getting really high performance out of compute shaders is still hard to get use to.
  • It really annoys me that Quick Sync doesn't support luma-only encoding (ie. 4:0:0); the best you can do is seemingly 4:2:0 and then have empty chroma planes, which wastes resources. It would have been a nice way to hack around the limitation that you can't have 4:2:2 or alpha.
  • Time-frequency switching is the solution to a problem that sounds trivial if you're a DSP beginner and nearly impossible if you've actually done some DSP. I'm not intuitively convinced it's worth it if you have fast float muladds, but it's pretty neat. Allowing multiple block sizes to an intraframe codec has a cost in that you'll need a size decision heuristic, though, which pretty much instantly complicates the encoder.

Work in progress :-) Maybe something more coherent will come out eventually.

Edit: Forgot about TF switching!

Joachim Breitner: Titel

Sun, 20 Aug 2017 18:50:10 +0000

Joachim Breitner: Compose Conference talk video online

Sun, 20 Aug 2017 18:50:10 +0000


Three months ago, I gave a talk at the Compose::Conference in New York about how Chris Smith and I added the ability to create networked multi-user programs to the educational Haskell programming environment CodeWorld, and finally the recording of the talk is available on YouTube (and is being discussed on reddit):

It was the talk where I got the most positive feedback afterwards, and I think this is partly due to how I created the presentation: Instead of showing static slides, I programmed the complete visual display from scratch as an “interaction” within the CodeWorld environment, including all transitions, an working embedded game of Pong and a simulated multi-player environments with adjustable message delays. I have put the code for the presentation online.

Chris and I have written about this for ICFP'17, and thanks to open access I can actually share the paper freely with you and under a CC license. If you come to Oxford you can see me perform a shorter version of this talk again.

Vincent Bernat: IPv6 route lookup on Linux

Sun, 20 Aug 2017 16:53:19 +0000

TL;DR: With its implementation of IPv6 routing tables using radix trees, Linux offers subpar performance (450 ns for a full view — 40,000 routes) compared to IPv4 (50 ns for a full view — 500,000 routes) but fair memory usage (20 MiB for a full view). In a previous article, we had a look at IPv4 route lookup on Linux. Let’s see how different IPv6 is. Lookup trie implementation Caching Performance Route lookup performance History Insertion performance Memory usage Conclusion Lookup trie implementation Looking up a prefix in a routing table comes down to find the most specific entry matching the requested destination. A common structure for this task is the trie, a tree structure where each node has its parent as prefix. With IPv4, Linux uses a level-compressed trie (or LPC-trie), providing good performances with low memory usage. For IPv6, Linux uses a more classic radix tree (or Patricia trie). There are three reasons for not sharing: The IPv6 implementation (introduced in Linux 2.1.8, 1996) predates the IPv4 implementation based on LPC-tries (in Linux 2.6.13, commit 19baf839ff4a). The feature set is different. Notably, IPv6 supports source-specific routing1 (since Linux 2.1.120, 1998). The IPv4 address space is denser than the IPv6 address space. Level-compression is therefore quite efficient with IPv4. This may not be the case with IPv6. The trie in the below illustration encodes 6 prefixes: For more in-depth explanation on the different ways to encode a routing table into a trie and a better understanding of radix trees, see the explanations for IPv4. The following figure shows the in-memory representation of the previous radix tree. Each node corresponds to a struct fib6_node. When a node has the RTN_RTINFO flag set, it embeds a pointer to a struct rt6_info containing information about the next-hop. The fib6_lookup_1() function walks the radix tree in two steps: walking down the tree to locate the potential candidate, and checking the candidate and, if needed, backtracking until a match. Here is a slightly simplified version without source-specific routing: static struct fib6_node *fib6_lookup_1(struct fib6_node *root, struct in6_addr *addr) { struct fib6_node *fn; __be32 dir; /* Step 1: locate potential candidate */ fn = root; for (;;) { struct fib6_node *next; dir = addr_bit_set(addr, fn->fn_bit); next = dir ? fn->right : fn->left; if (next) { fn = next; continue; } break; } /* Step 2: check prefix and backtrack if needed */ while (fn) { if (fn->fn_flags & RTN_RTINFO) { struct rt6key *key; key = fn->leaf->rt6i_dst; if (ipv6_prefix_equal(&key->addr, addr, key->plen)) { if (fn->fn_flags & RTN_RTINFO) return fn; } } if (fn->fn_flags & RTN_ROOT) break; fn = fn->parent; } return NULL; } Caching While IPv4 lost its route cache in Linux 3.6 (commit 5e9965c15ba8), IPv6 still has a caching mechanism. However cache entries are directly put in the radix tree instead of a distinct structure. Since Linux 2.1.30 (1997) and until Linux 4.2 (commit 45e4fd26683c), almost any successful route lookup inserts a cache entry in the radix tree. For example, a router forwarding a ping between 2001:db8:1::1 and 2001:db8:3::1 would get those two cache entries: $ ip -6 route show cache 2001:db8:1::1 dev r2-r1 metric 0 cache 2001:db8:3::1 via 2001:db8:2::2 dev r2-r3 metric 0 cache These entries are cleaned up by the ip6_dst_gc() function controlled by the following parameters: $ sysctl -a | grep -F net.ipv6.route net.ipv6.route.gc_elasticity = 9 net.ipv6.route.gc_interval = 30 net.ipv6.route.gc_min_interval = 0 net.ipv6.route.gc_min_interval_[...]

Dirk Eddelbuettel: #10: Compacting your Shared Libraries, After The Build

Sun, 20 Aug 2017 13:40:00 +0000

Welcome to the tenth post in the rarely ranting R recommendations series, or R4 for short. A few days ago we showed how to tell the linker to strip shared libraries. As discussed in the post, there are two options. One can either set up ~/.R/Makevars by passing the strip-debug option to the linker. Alternatively, one can adjust src/Makevars in the package itself with a bit a Makefile magic. Of course, there is a third way: just run strip --strip-debug over all the shared libraries after the build. As the path is standardized, and the shell does proper globbing, we can just do $ strip --strip-debug /usr/local/lib/R/site-library/*/libs/*.so using a double-wildcard to get all packages (in that R package directory) and all their shared libraries. Users on macOS probably want .dylib on the end, users on Windows want another computer as usual (just kidding: use .dll). Either may have to adjust the path which is left as an exercise to the reader. The impact can be Yuge as illustrated in the following dotplot: This illustration is in response to a mailing list post. Last week, someone claimed on r-help that tidyverse would not install on Ubuntu 17.04. And this is of course patently false as many of us build and test on Ubuntu and related Linux systems, Travis runs on it, CRAN tests them etc pp. That poor user had somehow messed up their default gcc version. Anyway: I fired up a Docker container, installed r-base-core plus three required -dev packages (for xml2, openssl, and curl) and ran a single install.packages("tidyverse"). In a nutshell, following the launch of Docker for an Ubuntu 17.04 container, it was just $ apt-get update $ apt-get install r-base libcurl4-openssl-dev libssl-dev libxml2-dev $ apt-get install mg # a tiny editor $ mg /etc/R/ # to add a default CRAN repo $ R -e 'install.packages("tidyverse")' which not only worked (as expected) but also installed a whopping fifty-one packages (!!) of which twenty-six contain a shared library. A useful little trick is to run du with proper options to total, summarize, and use human units which reveals that these libraries occupy seventy-eight megabytes: root@de443801b3fc:/# du -csh /usr/local/lib/R/site-library/*/libs/*so 4.3M /usr/local/lib/R/site-library/Rcpp/libs/ 2.3M /usr/local/lib/R/site-library/bindrcpp/libs/ 144K /usr/local/lib/R/site-library/colorspace/libs/ 204K /usr/local/lib/R/site-library/curl/libs/ 328K /usr/local/lib/R/site-library/digest/libs/ 33M /usr/local/lib/R/site-library/dplyr/libs/ 36K /usr/local/lib/R/site-library/glue/libs/ 3.2M /usr/local/lib/R/site-library/haven/libs/ 272K /usr/local/lib/R/site-library/jsonlite/libs/ 52K /usr/local/lib/R/site-library/lazyeval/libs/ 64K /usr/local/lib/R/site-library/lubridate/libs/ 16K /usr/local/lib/R/site-library/mime/libs/ 124K /usr/local/lib/R/site-library/mnormt/libs/ 372K /usr/local/lib/R/site-library/openssl/libs/ 772K /usr/local/lib/R/site-library/plyr/libs/ 92K /usr/local/lib/R/site-library/purrr/libs/ 13M /usr/local/lib/R/site-library/readr/libs/ 4.7M /usr/local/lib/R/site-library/readxl/libs/ 1.2M /usr/local/lib/R/site-library/reshape2/libs/ 160K /usr/local/lib/R/site-library/rlang/libs/ 928K /usr/local/lib/R/site-library/scales/libs/ 4.9M /usr/local/lib/R/site-library/stringi/libs/ 1.3M /usr/local/lib/R/site-library/tibble/libs/ 2.0M /usr/local/lib/R/site-library/tidyr/libs/ 1.2M /usr/local/lib/R/site-library/tidyselect/libs/ 4.7M /usr/local/lib/R/site-library/xml2/libs/ 78M total root@de443801b3fc:/# Looks like dplyr wins this one at thirty-three megabytes just for its shared library. But with a single stroke of [...]

Sean Whitton: Debian Policy call for participation -- August 2017

Sat, 19 Aug 2017 21:44:11 +0000

At the Debian Policy BoF at DebConf17, Solveig suggested that we could post summaries of recent activity in policy bugs to Planet Debian, as a kind of call for participation. Russ Allbery had written a script to generate such a summary some time ago, but it couldn’t handle the usertags the policy team uses to progress bugs through the policy changes process. Today I enhanced the script to handle usertags and I’m pleased to be able to post a summary of our bugs. Consensus has been reached and help is needed to write a patch #172436 BROWSER and sensible-browser standardization #273093 document interactions of multiple clashing package diversions #299007 Transitioning perms of /usr/local #314808 Web applications should use /usr/share/package, not /usr/share/doc/… #425523 Describe error unwind when unpacking a package fails #452393 Clarify difference between required and important priorities #476810 Please clarify 12.5, “Copyright information” #484673 file permissions for files potentially including credential informa… #491318 init scripts “should” support start/stop/restart/force-reload - why… #556015 Clarify requirements for linked doc directories #568313 Suggestion: forbid the use of dpkg-statoverride when uid and gid ar… #578597 Recommend usage of dpkg-buildflags to initialize CFLAGS and al. #582109 document triggers where appropriate #587279 Clarify restrictions on main to non-free dependencies #587991 perl-policy: /etc/perl missing from Module Path #592610 Clarify when Conflicts + Replaces et al are appropriate #613046 please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS) #614807 Please document autobuilder-imposed build-dependency alternative re… #616462 clarify wording of parenthetical in section 2.2.1 #628515 recommending verbose build logs #661928 recipe for determining shlib package name #664257 document Architecture name definitions #682347 mark ‘editor’ virtual package name as obsolete #683222 say explicitly that debian/changelog is required in source packages #685506 copyright-format: new Files-Excluded field #685746 debian-policy Consider clarifying the use of recommends #688251 Built-Using description too aggressive #757760 please document build profiles #759316 Document the use of /etc/default for cron jobs #761219 document versioned Provides #767839 Linking documentation of arch:any package to arch:all #770440 policy should mention systemd timers #773557 Avoid unsafe RPATH/RUNPATH #780725 PATH used for building is not specified #793499 The Installed-Size algorithm is out-of-date #810381 Update wording of 5.6.26 VCS-* fields to recommend encryption #823256 Update maintscript arguments with dpkg >= 1.18.5 #833401 virtual packages: dbus-session-bus, dbus-default-session-bus #835451 Building as root should be discouraged #838777 Policy 11.8.4 for x-window-manager needs update for freedesktop menus #845715 Please document that packages are not allowed to write outside thei… #853779 Clarify requirements about update-rc.d and invoke-rc.d usage in mai… Wording proposed, awaiting review from anyone and/or seconds by DDs #542288 Versions for native packages, NMU’s, and binary only uploads #582109 document triggers where appropriate #630174 forbid installation into /lib64 #645696 [copyright-format] clearer definitions and more consistent License:… #648271 11.8.3 “Packages providing a terminal emulator” says xterm passes -… #649530 [copyright-format] clearer definitions and more consistent License:… #662998 stripping static libraries #732445 debian-policy should encourage verification of upstream cryptograph… #737796 copyright-format: support Files: paragraph with both abbreviated na… #756835 Extension of the syntax of the Packages-List field. #786470 [copyright-format] Add an optional “License-Grant” field #835451 Building as root[...]

Holger Levsen: 20170819-lasercutter-sprint

Sat, 19 Aug 2017 16:14:53 +0000


laser-cutter sprint

So I'm overcoming my jetlag after DebConf17 by helping to make the Alioth sprint happen, and while it's good to witness work on the upcoming replacement, I'm rather minding my own business instead of getting involved…

And so I got interested in this laser cutter, which since two months has been set up in the CCCHH hackerspace and which is nicely documentend (and set up), so I managed to learn how to do my first baby steps with the laser cutter in one evening:


Basically there is a hosted web application named 'LaserWeb4' for which a pre-configuration exists, so that one only needs to load an image, scale and position it and tune the laser settings a bit. The laser itself is inside a cage, which has a physical safety switch which will turn off the laser if the cage is opened. Obviously the setup is a lot more complex and there are many parameters to tune, and I basically just learned one thing, which is "printing images on wood", but "printing images on a laptop cover" should be pretty similar and something to learn in the future (image)

And now I'm even teaching weasel how to use this thing (and he already made interesting new mistakes) and it looks like Ganneff & formorer are next. Fun fun fun!

Oh, and the Alioth sprint also seems to be quite productive, but I'll leave reporting about this to others.

Vasudev Kamath: Writing a UDP Broadcast Receiver as Python Iterator

Sat, 19 Aug 2017 13:28:00 +0000

I had to write a small Python application to listen for some broadcast message and process the message. This broadcast messages are actually sort of discovery messages to find some peers in a network. Writing a simple UDP Server to listen on a particular port was easy; but while designing an application I was wondering how can I plugin this server into my main code. There are 2 possibility Use threading module of python to send the server code in back ground and give it a callback to communicate the data to main thread. Periodically read some messages from server code and then dispose of server. I didn't like first approach because I need to pass a callback function and I some how will end up complicating code. Second approach sounded sane but I did want to make server more like iterator. I searched around to see if some one has attempted to write something similar, but did not find anything useful (may be my Googling skills aren't good enough). Anyway so I thought what is wrong in trying?. If it works then I'll be happy that I did something different :-). The first thing for making iterator in Python is having function __iter__ and __next__ defined in your class. For Python 2 iterator protocol wanted next to be defined instead of __next__. So for portable code you can define a next function which in return calls __next__. So here is my first shot at writing BroadCastReceiver class. from socket import socket, AF_INET, SOCK_DGRAM class BroadCastReceiver: def __init__(self, port, msg_len=8192): self.sock = socket(AF_INET, SOCK_DGRAM) self.sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) self.sock.bind(('', port)) self.msg_len = msg_len def __iter__(self): return self def __next__(self): try: addr, data = self.sock.recvfrom(self.msg_len) return addr, data except Exception as e: print("Got exception trying to recv %s" % e) raise StopIteration This version of code can be used in a for loop to read from socket UDP broadcasts. One problem will be that if no packet is received which might be due to disconnected network the loop will just block forever. So I had to modify the code slightly to add timeout parameter. So changed portion of code is below. ... def __init__(self, port, msg_len=8192, timeout=15): self.sock = socket(AF_INET, SOCK_DGRAM) self.sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) self.sock.settimeout(timeout) self.sock.msg_len = msg_len self.sock.bind(('', port)) ... So now if network is disconnected or no packet was received for timeout period we get a socket.timeout exception due to which StopIteration will be raised causing the for loop using server as iterator to exit. This avoids us just blocking our periodic code run forever when network is disconnected or no messages are received for long time. (may be due to connected to wrong network). Now every thing looks fine but only part is if we create the server object each time our periodic code is called we will have binding issue as we did not properly close the socket once iterator has stopped. So I added socket closing code in __del__ function for the class. __del__ will be called when garbage collector try to recollect object when it goes out of scope. ... def __del__(self): self.sock.close() So the server can be used in for loop or by passing the object of server to next built-in function. Here are 2 examples. r = BroadCastReceiver(5000, timeout=10) count = 0 for (address, data) in r: print('Got packet from %s: %s' % address, data) count += 1 # do whatever you want with data if count > 10: break Here we use an counter variable to track iteration and after some iteration we exit for loop. Another way is[...]

Arturo Borrero González: Running Suricata 4.0 with Debian Stretch

Sat, 19 Aug 2017 10:56:00 +0000

Do you know what’s happening in the wires of your network? There is a major FLOSS player in the field of real time intrusion detection (IDS), inline intrusion prevention (IPS) and network security monitoring (NSM). I’m talking about Suricata, a mature, fast and robust network threat detection engine. Suricata is a community driven project, supported by the Open InfoSec Foundation (OISF). For those who doesn’t know how Suricata works, it usually runs by loading a set of pre-defined rules for matching different network protocols and flow behaviours. In this regards, Suricata has been always ruleset-compatible with the other famous IDS: snort. The last major release of Suricata is 4.0.0, and I’m uploading the package for Debian stretch-backports as I write this line. This means the updated package should be available for general usage after the usual buildds processing ends inside the Debian archive. You might be wondering, How to start using Suricata 4.0 with Debian Stretch? First, I would recommend reading the docs. Please checkout: the Debian wiki page for Suricata the official Suricata upstream docs My recommendation is to run Suricata from stretch-backports or from testing, and just installing the package should be enough to get the environment up and running: % sudo aptitude install suricata You can check that the installation was good: % sudo systemctl status suricata ● suricata.service - Suricata IDS/IDP daemon Loaded: loaded (/lib/systemd/system/suricata.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2017-08-19 12:50:49 CEST; 44min ago Docs: man:suricata(8) man:suricatasc(8) Main PID: 1101 (Suricata-Main) Tasks: 8 (limit: 4915) CGroup: /system.slice/suricata.service └─1101 /usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/ ago 19 12:50:44 nostromo systemd[1]: Starting Suricata IDS/IDP daemon... ago 19 12:50:47 nostromo suricata[1032]: 19/8/2017 -- 12:50:47 - - This is Suricata version 4.0.0 RELEASE ago 19 12:50:49 nostromo systemd[1]: Started Suricata IDS/IDP daemon. You can interact with Suricata using the suricatasc tool: % sudo suricatasc -c uptime {"message": 3892, "return": "OK"} And start inspecting the generated logs at /var/log/suricata/ The default configuration, in file /etc/suricata/suricata.yaml, comes with some preconfigured values. For a proper integration into your enviroment, you should tune the configuration file, define your networks, network interfaces, running modes, and so on (refer to the upstream documentation for this). In my case, I tested suricata by inspecting the traffic of my laptop. After installation, I only had to switch the network interface: [...] # Linux high speed capture support af-packet: - interface: wlan0 [...] After a restart, I started seeing some alerts: % sudo systemctl restart suricata % sudo tail -f /var/log/suricata/fast.log 08/19/2017-14:03:04.025898 [**] [1:2012648:3] ET POLICY Dropbox Client Broadcasting [**] \ [Classification: Potential Corporate Privacy Violation] [Priority: 1] {UDP} -> One of the main things when running Suricata is to keep your ruleset up-to-dated. In Debian, we have the suricata-oinkmaster package which comes with some handy options to automate your ruleset updates using the Oinkmaster software. Please note that this is a Debian-specific glue to integrate and automate Suricata with Oinkmaster. To get this funcionality, simply install the package: % sudo aptitude install suricata-oinkmaster A daily cron-job will be enabled. Check suricata-oinkmaster-updater(8) for more info. By the way, Did you [...]

Sean Whitton: The knowledge that one has an unread message is equivalent to a 10 point drop in one's IQ

Fri, 18 Aug 2017 17:37:53 +0000


According to Daniel Pocock’s talk at DebConf17’s Open Day, hearing a ping from your messaging or e-mail app or seeing a visual notification of a new unread message has an equivalent effect on your ability to concentrate as

  • a 10 point drop in your IQ; or

  • drinking a glass of wine.

This effect is probably at least somewhat mitigated by reading the message, but that is a context switch, and we all know what those do to your concentration. So if you want to get anything done, be sure to turn off notifications.

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, July 2017

Fri, 18 Aug 2017 14:16:31 +0000

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In July, about 181 work hours have been dispatched among 11 paid contributors. Their reports are available: Antoine Beaupré did 20h (out of 16h allocated + 4 extra hours). Ben Hutchings did 14 hours (out of 15h allocated, thus keeping 1 extra hour for August). Chris Lamb did 18 hours. Emilio Pozuelo Monfort did 18.5 hours (out of 23.5 hours allocated + 8 hours remaining, thus keeping 13 hours for August). Guido Günther did 10 hours. Hugo Lefeuvre did nothing due to personal problems (out of 2h allocated + 10 extra hours, thus keeping 12 extra hours for August). Markus Koschany did 23.5 hours. Ola Lundqvist did not publish his report yet (out of 14h allocated + 2 extra hours). Raphaël Hertzog did 7 hours (out of 12 hours allocated but he gave back his remaining hours). Roberto C. Sanchez did 19.5 hours (out of 23.5 hours allocated + 12 hours remaining, thus keeping 16 extra hours for August). Thorsten Alteholz did 23.5 hours. Evolution of the situation The number of sponsored hours increased slightly with two new sponsors: Leibniz Rechenzentrum (silver sponsor) and Catalyst IT Ltd (bronze sponsor). The security tracker currently lists 74 packages with a known CVE and the dla-needed.txt file 64. The number of packages with open issues increased of almost 50% compared to last month. Hopefully this backlog will get cleared up when the unused hours will actually be done. In any case, this evolution is worth watching. Thanks to our sponsors New sponsors are in bold. Platinum sponsors: TOSHIBA (for 22 months) GitHub (for 13 months) Gold sponsors: The Positive Internet (for 38 months) Blablacar (for 37 months) Linode (for 27 months) Babiel GmbH (for 16 months) Plat’Home (for 16 months) Silver sponsors: Domeneshop AS (for 37 months) Université Lille 3 (for 37 months) Trollweb Solutions (for 35 months) Nantes Métropole (for 32 months) Dalenys (for 28 months) Univention GmbH (for 23 months) Université Jean Monnet de St Etienne (for 23 months) Sonus Networks (for 17 months) UR Communications BV (for 12 months) maxcluster GmbH (for 11 months) Exonet B.V. (for 7 months) Leibniz Rechenzentrum Bronze sponsors: David Ayers – IntarS Austria (for 38 months) Evolix (for 38 months) Offensive Security (for 38 months), a.s. (for 38 months) Freeside Internet Service (for 37 months) MyTux (for 37 months) Intevation GmbH (for 35 months) Linuxhotel GmbH (for 35 months) Daevel SARL (for 33 months) Bitfolk LTD (for 32 months) Megaspace Internet Services GmbH (for 32 months) NUMLOG (for 32 months) Greenbone Networks GmbH (for 31 months) WinGo AG (for 31 months) Ecole Centrale de Nantes – LHEEA (for 27 months) Sig-I/O (for 24 months) Entr’ouvert (for 22 months) Adfinis SyGroup AG (for 19 months) GNI MEDIA (for 14 months) Quarantainenet BV (for 14 months) RHX Srl (for 11 months) Bearstech (for 5 months) LiHAS (for 5 months) People Doc Catalyst IT Ltd No comment | Liked this article? Click here. | My blog is Flattr-enabled. [...]

Albiona Hoti: CoderGals Prizren Hackathon

Fri, 18 Aug 2017 10:00:01 +0000

CoderGals Hackathon started tonight!

Mike Gabriel: @DebConf17: Ad-hoc BoF: Bits from the Debian+Ubuntu MATE Packaging Team

Fri, 18 Aug 2017 09:33:16 +0000

On Tuesday, late afternoon, at DebConf17, I offered an ad-hoc BoF about the current status of the MATE Desktop packaging efforts in Debian and Ubuntu. I need to get this written down, before DebConf17 feels too far away...

Unfortunately, I scheduled that BoF with Joey Hess's talk about his post-Debian life, which attracted many people. So, only a small group of people came together to share and discuss about the current status of MATE in Debian and Ubuntu.

Ongoing efforts around MATE in Debian and Ubuntu

A quick summary of ongoing efforts was provided and also a collection of URLs for reporting bugs, looking up packaging status, etc. was listed:

Cross-Distro Packaging Workflow

The workflow of Debian and Ubuntu packaging in the MATE Packaging Team was described in detail (basically, all packages go through Debian, only exception being freeze states of this or that distro) and the benefit of the close cooperation between the two projects underlined. We reduce the packaging effort tremendously by working very closely together. In the past, we (Martin Wimpress and myself) also invited the people from Linux Mint to join our cross-distro packaging efforts, but so far to no avail. Also the packaging for the Parrot Security OS has recently been integrated in our packaging Git repository.

Requested / Upcoming Improvements

From people attending the BoF, I got these main inputs, which I hope to accomplish with the help of all, for Debian buster:

  • Improve the MATE User Guide, I am quite optimistic that we get help from the person that asked for a better help tool on the MATE Desktop (like it was back in the times of old GNOMEv2)
  • Provide several desktop layouts in Debian, like available in Ubuntu MATE, that can be chosen / configured by the MATE Tweak Tool
  • Port the Ubuntu MATE Welcome application to Debian and autostart it on first login, like people know it from Ubuntu MATE

Another project that I will also work on for Debian buster is proper Ayatana Indicator support for Debian's MATE Desktop.


Thanks to all the people attending the BoF for your sharings and input. Feel invited to contribute to our team's effort in improving the user experience of the MATE Destkop Environment in Debian (and Ubuntu, and ...). Also a big thanks to the people already on the team for bringing MATE in Debian to where it is now. Good work, folks!

Dirk Eddelbuettel: RcppArmadillo 0.7.960.1.0

Fri, 18 Aug 2017 00:41:00 +0000

The bi-monthly RcppArmadillo release is out with a new version 0.7.960.1.0 which is now on CRAN, and will get to Debian in due course. And it is a big one. Lots of nice upstream changes from Armadillo, and lots of work on our end as the Google Summer of Code project by Binxiang Ni, plus a few smaller enhancements -- see below for details. Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language--and is widely used by (currently) 379 other packages on CRAN---an increase of 49 since the last CRAN release in June! Changes in this release relative to the previous CRAN release are as follows: Changes in RcppArmadillo version 0.7.960.1.0 (2017-08-11) Upgraded to Armadillo release 7.960.1 (Northern Banana Republic Deluxe) faster randn() when using OpenMP (NB: usually omitted when used fromR) faster gmm_diag class, for Gaussian mixture models with diagonal covariance matrices added .sum_log_p() to the gmm_diag class added gmm_full class, for Gaussian mixture models with full covariance matrices expanded .each_slice() to optionally use OpenMP for multi-threaded execution Upgraded to Armadillo release 7.950.0 (Northern Banana Republic) expanded accu() and sum() to use OpenMP for processing expressions with computationally expensive element-wise functions expanded trimatu() and trimatl() to allow specification of the diagonal which delineates the boundary of the triangular part Enhanced support for sparse matrices (Binxiang Ni as part of Google Summer of Code 2017) Add support for dtCMatrix and dsCMatrix (#135) Add conversion and unit tests for dgT, dtT and dsTMatrix (#136) Add conversion and unit tests for dgR, dtR and dsRMatrix (#139) Add conversion and unit tests for pMatrix and ddiMatrix (#140) Rewrite conversion for dgT, dtT and dsTMatrix, and add file-based tests (#142) Add conversion and unit tests for indMatrix (#144) Rewrite conversion for ddiMatrix (#145) Add a warning message for matrices that cannot be converted (#147) Add new vignette for sparse matrix support (#152; Dirk in #153) Add support for sparse matrix conversion from Python SciPy (#158 addressing #141) Optional return of row or column vectors in collapsed form if appropriate #define is set (Serguei Sokol in #151 and #154) Correct speye() for non-symmetric cases (Qiang Kou in #150 closing #149). Ensure tests using Scientific Python and reticulate are properly conditioned on the packages being present. Added .aspell/ directory with small local directory now supported by R-devel. Courtesy of CRANberries, there is a diffstat report. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge 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. [...]

Sean Whitton: DebCamp/DebConf17: reports on sprints and BoFs

Thu, 17 Aug 2017 22:21:33 +0000


In addition to my personal reflections on DebCamp/DebConf17, here is a brief summary of the activities that I had a hand in co-ordinating.

I won’t discuss here many other small items of work and valuable conversations that I had during the two weeks; hopefully the fruits of these will show themselves in my uploads to the archive over the next year.

Debian Policy sprint & BoF

  • released version of the Policy Manual

  • figured out documenting reproducibility in policy. Formulating the wording turned out to be easier than I had expected

  • approx. ten years after they were first published, incorporated marga’s maintscript flowcharts into policy proper

  • converted policy from docbook to rST built with the Sphinx toolchain. Many, many thanks to Hideki Yamane and David Bremner for helping Russ and I get this merged to our master branch

  • triage of every single bug against policy, and mass closure of inactive bugs, bringing the total down from more than 200 to around 125

  • conversations with Technical Committee members about how the two teams can help each other’s work (mainly us helping them to help us!)

  • conversations about how we handle disagreement and plans to streamline our overly complex BTS usertags (watch this space)

  • very useful input from policy consumers about how the upgrading checklist is formatted, and how we can recruit more people to get patches written

Debian Emacs Team meeting/sprint

  • plans to finally drop our emacsXY binary packages, and just have a single version of Emacs in the archive, so that we no longer have to deal with bugs due to someone still having emacs21 installed (David’s idea; Rob’s implementation; Sean’s mostly-helpful comments)

  • other plans to simplify and otherwise improve the Debian Emacsen policy

  • finally finished off the work needed to RM emacs24—nine months later—including a lot of NMUs

  • mentoring a junior team member

Unfortunately we didn’t make any significant progress towards converting all addons to use dh_elpa, as the work is not that much fun. Might be worth a more focused sprint next year.

Report on team website

Git for Debian packaging BoF & follow-up conversations

The BoF was far more about dgit than I had wanted; however, I think that this was mostly because people had questions about dgit, rather than any unintended lecturing by me.

I believe that several people came away from DebConf thinking that starting to use dgit would improve Debian for themselves and for users of their packages.

Sean Whitton: I went all the way to Montréal for DebConf17, and all I got was a new MUA

Thu, 17 Aug 2017 21:50:51 +0000

This year’s group photo (by Aigars Mahinovs). I really like the tagline On Sunday night I got back from Montréal, where I attended both DebCamp17 and DebConf17. It was a wonderful two weeks. All I really did was work on Debian for roughly eight hours per day, interspersed with getting to know both people I’ve been working with since I first began contributing to Debian in late 2015, and people I didn’t yet know. But this was all I really needed to be doing. There was no need to engage in distracting myself. I enjoyed the first week more. There were sufficiently few people present that you could know at least all of their faces, and interesting-sounding talks didn’t interrupt making progress on one’s own work or unblocking other people’s work. In the second week it was great to meet people who were only present for the second week, but it felt more like regular Debian, in that I was often waiting on other people or they were waiting on me. While I spent one morning actually writing fresh code, and I did a fair amount of pure packaging work, the majority of my time was poured into (i) Debian Policy; (ii) discussions within the Emacs team; and (iii) discussions about dgit. This was as I expected. During DebConf, it’s not that useful to seclude oneself and sufficiently reacquaint oneself with a codebase that one can start producing patches, because that can be done anywhere in the world, without everyone else around. It’s far more useful to bring different people together to get projects unblocked. I did some of that for my own work, and also tried to help other people’s, including those who weren’t able to attend the conference. In my ordinary life, taking a step back from the methods by which I protect my PGP keys and other personal data, I can appear to myself as a paranoid extremist, or some kind of data hoarder. It was comforting to find at DebConf plenty of people who go way further than me: multiple user accounts on their laptop, with separate X servers, for tasks of different security levels; PGP keys on smartcards; refusal to sign my PGP key based on government-issued ID alone; use of Qubes OS. One thing that did surprise me was to find myself in a minority for using the GNOME desktop; I had previously assumed that most people deep in Debian development didn’t bother with tiling window managers. Turns out they are enthusiastic to talk about the trade-offs between window managers while riding the subway train back to our accommodation at midnight—who knew such people existed? I was pleased to find them. One evening, I received a tag-teamed live tutorial in using i3’s core keybindings, and the next morning GNOME seemed deeply inelegant. The insinuation began, but I was immediately embroiled in inner struggle over the fact that i3 is a very popular tiling window manager, so it wouldn’t be very cool if I were to start using it. This difficulty was compounded when I learned that the Haskell team lead still uses xmonad. The struggle continues. I hope that I’ve been influenced by the highly non-judgemental and tolerant attitudes of the attendees of the conference. While most people at the conference were pretty ordinary—aside from wanting to talk about the details of Debian packaging and processes!—there were several people who rather visibly rejected social norms about how to present themselves. Around these people there was nothing of the usual tension. Further, in contrast with my environment as a graduate student, everyone was extremely relaxed about how everyone was spending their time. People drinking beer in the evenings we[...]

Reproducible builds folks: Reproducible Builds: Weekly report #120

Thu, 17 Aug 2017 21:48:55 +0000

Here's what happened in the Reproducible Builds effort between Sunday 6th and Saturday 12th August 2017: There were two talks mainly about Reproducible Builds at DebConf17: Reproducible builds: Status update by Chris Lamb, Holger Levsen, Maria Glukhova, Steven Chamberlain, Vagrant Cascadian, Valerie Young and Ximin Luo. Fun with .buildinfo by Steven Chamberlain. Reproducible builds were also mentioned in many other talks including: Using Qubes OS from the POV of a Debian developer by Holger Levsen. Debian for Medical Software by André Roth. Let's maintain as a team by Holger Levsen. Signing package contents: why and how by Matthew Garrett. Bits from the DPL by Chris Lamb. Installing Debian by Vagrant Cascadian. in-toto -- Securing supply chains as a whole by Lukas Puehringer. Debian Cloud BoF by Steve McIntyre. Will there be Debian in your next BMW car? by Aigars Mahinovs. There has also been substantial activity regarding updating the Debian Policy regarding Reproducible Builds (#844431). This work is still ongoing and will be covered in future issues of this weekly blog. Notes about reviews of unreproducible packages 13 package reviews have been added, 7 have been updated and 34 have been removed in this week, adding to our knowledge about identified issues. Packages reviewed and fixed, and reproducibility related bugs filed Adrian Bunk: #871818 filed against debian-zh-faq. #871907 filed against praat. Katsuhiko Nishimra: #871591 filed against llvm-toolchain-snapshot. Lucas Nussbaum: #871059 filed against fltk1.3. #871155 filed against brltty. #871159 filed against texlive-extra. #871345 filed against texlive-base. #871349 filed against ispell-uk. #871357 filed against po4a. jathan: #870890 filed against apg. Upstream packages: Bernhard M. Wiedemann: enblend (merged), SOURCE_DATE_EPOCH support systemtap splint (dead project) skelcd-openSUSE Other bugs filed During our reproducibility testing, Adrian Bunk filed 48 FTBFS bugs this week. diffoscope development Mattia Rizzolo: debian/copyright: coalesce some file paragraphs and update information. Bump Standards-Version to 4.0.1, no changes needed. trydiffoscope development Chris Lamb: Test --help output in autopkgtests Mattia: Notify the#debian-reproducible-changes` IRC channel for unreproducible -> FTBFS transitions. Update squid.conf for all nodes to 5.2.23 (and fixup some). Enable the Munin Squid plugin on the Codethink arm64 nodes as well. Force reconfiguration of Apache and Munin when is updated. Holger worked on slides for his DebConf17 BoF about migrating to, which affects tests.r-b.o as well. Misc. This week's edition was written by Chris Lamb & Holger Levsen & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists. [...]

Julian Andres Klode: Why TUF does not shine (for APT repositories)

Thu, 17 Aug 2017 19:49:06 +0000

In DebConf17 there was a talk about The Update Framework, short TUF. TUF claims to be a plug-in solution to software updates, but while it has the same practical level of security as apt, it also has the same shortcomings, including no way to effectively revoke keys. TUF divides signing responsibilities into roles: A root role, a targets rule (signing stuff to download), a snapshots rule (signing meta data), and a time stamp rule (signing a time stamp file). There also is a mirror role for signing a list of mirrors, but we can ignore that for now. It strongly recommends that all keys except for timestamp and mirrors are kept offline, which is not applicable for APT repositories – Ubuntu updates the repository every 30 minutes, imagine doing that with offline keys. An insane proposal. In APT repositories, we effectively only have a snapshots rule – the only thing we sign are Release files, and trust is then chained down by hashes (Release files hashes Packages index files, and they have hashes of individual packages). The keys used to sign repositories are online keys, after all, all the metadata files change every 30 minutes (Ubuntu) or 6 hours (Debian) – it’s impossible to sign them by hand. The timestamp role is replaced by a field in the Release file specifying until when the Release file is considered valid. Let’s check the attacks TUF protects again: Arbitrary installation attacks. – We protect against that with the outer signature and hashes Endless data attacks. – Yes, we impose a limit on Release files (the sizes of other files are specified in there and this file is signed) Extraneous dependencies attacks – That’s verified by the signed hashes of Packages files Fast-forward attacks – same Indefinite freeze attacks – APT has a Valid-Until field that can be used to specify a maximum life time of a release file Malicious mirrors preventing updates. – Well, the user configures the mirror, so usually not applicable. if the user has multiple mirrors, APT deals with that fine Mix-and-match attacks – Again, signed Release file and hashes of other files Rollback attacks – We do not allow Date fields in Release files to go backwards Slow retrieval attacks – TUF cannot protect against that either. APT has very high timeouts, and there is no reasonable answer to that. Vulnerability to key compromises – For our purposes where we need all repository signing keys to be online, as we need to sign new releases and metadata fairly often, it does not make it less vulnerable to require a threshold of keys (APT allows repositories to specify concrete key ids they may be signed with though, that has the same effect) Wrong software installation. – Does not happen, the .deb files are hashed in the Packages files which are signed by the release file As we can see, APT addresses all attacks TUF addresses. But both do not handle key revocation. So, if a key & mirror gets compromised (or just key and the mirror is MITMed), we cannot inform the user that the key has been compromised and block updates from the compromised repository. I just wrote up a proposal to allow APT to query for revoked keys from a different host with a key revocation list (KRL) file that is signed by different keys than the repository. This would solve the problem of key revocation easily – even if the repository host is MITMed or compromised, we can still revoke the keys signing the repository from a different location.Filed under: Debian, Ubuntu [...]

Shirish Agarwal: Composers are not given due recognition

Thu, 17 Aug 2017 18:17:21 +0000

Update – Some youtube links are not viewable or even seen on Seems p.d.o. tries its best to remove external links, sorry for the breakage. Beware – some youtube-links would be shared in this entry, sorry couldn’t find a better/easier media platform to work with. If anyone knows any other platform or wants to suggest, feel free to either mail me or let me know in comments. I want to start today’s sharing with a picture of Ganesha I saw today. It is and was public art hence sharing it without an issue. This is starting of festivities time in India and Ganesha or Ganpati is looked up as a good omen in India. The festival of Ganesh Chaturthi would be starting on the 25th of August and is a sight to behold. Just like Rio has its carnival, Ganesh Chaturthi is also a carnival. We also have parades where people come with Pandals (or temporary structures) The mythology says he has a sweet tooth (hence lot of distribution of sweets, especially modak) and anything which might be troubling people, he creates solutions for them. Here is one video of how people celebrate his immersion in India. This is from my home-town few years ago, every year the madness and the celebrations are becoming more and more. People from far off come to see how we celebrate and see how different people make their Pandals. While some are with music, others are with social messages. Usually people start going to see these structures after dusk and return home way after midnight or early morning. I hope to do this endeavour after many years. One is drunk from hearing all sorts of different kids of music, decoration, messages, a feast and a strain to all the senses. Ganesha immersion celebrations – If one is interested one can find more info. at After quite a bit of time, I wrote an article about various foss internships which I knew besides GSOC over the years. I finally penned them down at Interestingly, I was amazed to see that all FOSS U.S. projects (outside of GSOC) are for students who are either living or studying in U.S. and have a student work visa (which from private discussions I came to know is lot harder to get nowadays than before). Except for the National Science Foundation (NSF) which probably has U.S. defence relations and hence they might be sensitive, I fail to understand other institutes preferences for only getting people from the U.S. and hence having a lesser talent pool of people. This also affects the growth of the projects themselves. Just think how limited Debian would have been if it had decided to only have people from only any one community develop it. Dunno if this is due to the present President Trump or these policies had been there before. It would be nice and interesting if people in the know can share. What has also been interesting to watch is Mr. Trump blaming low-cost manufacturing centres like India and China when as far as I recall, lot of manufacturing, specifically auto-mobiles manufacturing was shifted out of the U.S. to Ireland and other places years before which are relatively high-cost places (at least compared to India). I *believe* the change was as early as in 1980’s itself where India was insulated and had a limited market for everything (similar to Russian communism as shown in popular media but not so bad.) Interestingly, it took almost a month for the perl 2.56 to make the transition smoothly. It took quite a bi[...]

Bits from Debian: Work on Debian for mobile devices continues

Thu, 17 Aug 2017 13:40:00 +0000

Work on Debian for mobile devices, i.e. telephones, tablets, and handheld computers, continues. During the recent DebConf17 in Montréal, Canada, more than 50 people had a meeting to reconsider opportunities and challenges for Debian on mobile devices.

A number of devices were shown at DebConf:

  • PocketCHIP: A very small handheld computer with keyboard, Wi-Fi, USB, and Bluetooth, running Debian 8 (Jessie) or 9 (Stretch).
  • Pyra: A modular handheld computer with a touchscreen, gaming controls, Wi-Fi, keyboard, multiple USB ports and SD card slots, and an optional modem for either Europe or the USA. It will come preinstalled with Debian.
  • Samsung Galaxy S Relay 4G: An Android smartphone featuring a physical keyboard, which can already run portions of Debian userspace on the Android kernel. Kernel upstreaming is on the way.
  • ZeroPhone: An open-source smartphone based on Raspberry Pi Zero, with a small screen, classic telephone keypad and hardware switches for telephony, Wi-Fi, and the microphone. It is running Debian-based Raspbian OS.


The photo (click to enlarge) shows all four devices, together with a Nokia N900, which was the first Linux-based smartphone by Nokia, running Debian-based Maemo and a completely unrelated Gnuk cryptographic token, which just sneaked into the setting.

If you like to participate, please

Holger Levsen: 20170816-irssi-timezones

Wed, 16 Aug 2017 21:02:01 +0000


How to change irssi's timezone without restart

Happy birthday to all you lovely Debian people!

For my future self:

 | h01ger: /script exec $ENV{TZ} = 'Europe/Vienna';

Simon McVittie: DebConf 17: Flatpak and Debian

Wed, 16 Aug 2017 20:50:00 +0000

The indoor garden at Collège de Maisonneuve, the DebConf 17 venue

I'm currently at DebConf 17 in Montréal, back at DebConf for the first time in 10 years (last time was DebConf 7 in Edinburgh). It's great to put names to faces and meet more of my co-developers in person!

On Monday I gave a talk entitled “A Debian maintainer's guide to Flatpak”, aiming to introduce Debian developers to Flatpak, and show how Flatpak and Debian (and Debian derivatives like SteamOS) can help each other. It seems to have been quite well received, with people generally positive about the idea of using Flatpak to deliver backports and faster-moving leaf packages (games!) onto the stable base platform that Debian is so good at providing.

A video of the talk is available from the Debian Meetings Archive. I've also put up my slides in the DebConf git-annex repository, with some small edits to link to more source code: A Debian maintainer's guide to Flatpak. Source code for the slides is also available from Collabora's git server.

The next step is to take my proof-of-concept for building Flatpak runtimes and apps from Debian and SteamOS packages, flatdeb, get it a bit more production-ready, and perhaps start publishing some sample runtimes from a cron job on a Debian or Collabora server. (By the way, if you downloaded that source right after my talk, please update - I've now pushed some late changes that were necessary to fix the 3D drivers for my OpenArena demo.)

I don't think Debian will be going quite as far as Endless any time soon: as Cosimo outlined in the talk right before mine, they deploy their Debian derivative as an immutable base OS with libOSTree, with all the user-installable modules above that coming from Flatpak. That model is certainly an interesting thing to think about for Debian derivatives, though: at Collabora we work on a lot of appliance-like embedded Debian derivatives, with a lot of flexibility during development but very limited state on deployed systems, and Endless' approach seems a perfect fit for those situations.

[Edited 2017-08-16 to fix the link for the slides, and add links for the video]

Ross Gammon: My Debian & Ubuntu work from April to mid-August 2017

Wed, 16 Aug 2017 17:16:58 +0000

Okay, so I have been slack with my blogging again. I have been travelling around Europe with work quite a bit, had a short holiday over Easter in Denmark, and also had 3 weeks of Summer Holiday in Germany. Debian Tidied up the packaging and tried building the latest version of libdrumstick, but tests had been added to the package by upstream which were failing. I still need to get back and investigate that. Updated node-seq (targeted at experimental due to the Debian Stretch release freeze) and asked for sponsorship (as I did not have DM rights for it yet). Uploaded the latest version of abcmidi (also to experimental), and again. Updated node-tmp to the latest version and uploaded to experimental. Worked some more on bluebird RFP, but getting errors when running tests. I still haven’t gone back to investigate that. Updated node-coffeeify to the latest version and uploaded to experimental. Uploaded the latest version of node-os-tmpdir (also to experimental). Uploaded the latest version of node-concat-stream (also to experimental). After encouragement from several Debian Developers, I applied to become a full Debian Developer. Over the summer months I worked with Santiago as my Application Manager and answered questions about working in the Debian Project. A web vulnerability was identified in node-concat-stream, so I prepared a fix to the version in unstable, uploaded it to unstable, and submitted a unblock request bug so that it would be fixed in the coming Debian Stretch release. Debian 10 (Stretch) was released! Yay! Moved abcmidi from experimental to unstable, adding an autopkgtest at the same time. Moved node-concat-stream from experimental to unstable. During the process I had to take care of the intermediate upload to stretch (on a separate branch) because of the freeze. Moved node-tmp to unstable from experimental. Moved node-os-tmpdir from experimental to unstable. Filed a removal bug for creepy, which seems to be unmaintained upstream these days. Sent my unfinished Qt4 to Qt5 porting patches upstream just in case! Uploaded node-object-inspect to experimental to check the reverse dependencies, then moved it to unstable. Then a new upstream version came out which is now in experimental waiting for a retest of reverse dependencies. Uploaded the latest version of gramps (4.2.6). Uploaded a new version of node-cross-spawn to experimental. Discovered that I had successfully completed the DD application process and I was now a Debian Developer. I celebrated by uploading the Debian Multimedia Blends package to the NEW queue, which I was not able to do before! Tweaked and uploaded the node-seq package (with an RC fix) which had been sitting there because I did not have DM rights to the package. It is not an important package anyhow, as it is just one of the many dependencies that need to be packaged for Browserify. Packaged and uploaded the latest node-isarray directly to unstable, as the changes seemed harmless. Prepared and uploaded the latest node-js-yaml to experimental. Did an update to the Node packaging Manual now that we are allowed to use “node” as the executable in Debian instead of “nodejs” which caused us to do a lot of patching in the past to get node packages working in Debian. Ubuntu Did a freeze exception bug for ubuntustudio-controls, but we did not manage to get it sponsored before the Ubuntu Studio Zesty 17.04 release. Investigated why Ardour was not migrating from z[...]

Bits from Debian: Debian turns 24!

Wed, 16 Aug 2017 15:50:00 +0000

Today is Debian's 24th anniversary. If you are close to any of the cities celebrating Debian Day 2017, you're very welcome to join the party!

If not, there's still time for you to organize a little celebration or contribution to Debian. For example, spread the word about Debian Day with this nice piece of artwork created by Debian Developer Daniel Lenharo de Souza and Valessio Brito, taking inspiration from the desktop themes Lines and softWaves by Juliette Belin:


If you also like graphics design, or design in general, have a look at and join the team! Or you can visit the general list of Debian Teams for many other opportunities to participate in Debian development.

Thanks to everybody who has contributed to develop our beloved operating system in these 24 years, and happy birthday Debian!

Lisandro Damián Nicanor Pérez Meyer: Qt 4 removal in Debian testing (Buster)/unstable

Tue, 15 Aug 2017 16:50:00 +0000

(image) We have been announcing it: we are going to remove Qt 4 during the Buster cycle.

Or at least that's the best outcome we can expect. Removing a very highly used library is hard, as Qt4's Webkit has proved. Qt 4 is long dead upstream and we have already started to need to patch it with untested patches as in the OpenSSL 1.1 case (will be in experimental in a few hours after this post).

We will try to put as less effort as possible in keeping it alive meaning that from now on if we need to patch it to make it support a newer lib or alike we will simply remove its support if possible. Using the OpenSSL case as an example, if we need to support any version > 1.1 we will simply remove the SSL support. That means things will break.

So, if you depend on FLOSS which is still based on Qt 4 be sure to try to port it. If you depend on a proprietary vendor software which uses Qt 4 then you better start telling them it's really time to update it. Really.

We will soon start filing bugs against packages using Qt 4. I'll update this blog post later to add that info.

For the Qt/KDE team, Lisandro.

Dirk Eddelbuettel: #9: Compacting your Shared Libraries

Tue, 15 Aug 2017 01:49:00 +0000

Welcome to the nineth post in the recognisably rancid R randomness series, or R4 for short. Following on the heels of last week's post, we aim to look into the shared libraries created by R. We love the R build process. It is robust, cross-platform, reliable and rather predicatable. It. Just. Works. One minor issue, though, which has come up once or twice in the past is the (in)ability to fully control all compilation options. R will always recall CFLAGS, CXXFLAGS, ... etc as used when it was compiled. Which often entails the -g flag for debugging which can seriously inflate the size of the generated object code. And once stored in ${RHOME}/etc/Makeconf we cannot on the fly override these values. But there is always a way. Sometimes even two. The first is local and can be used via the (personal) ~/.R/Makevars file (about which I will have to say more in another post). But something I have been using quite a bite lately uses the flags for the shared library linker. Given that we can have different code flavours and compilation choices---between C, Fortran and the different C++ standards---one can end up with a few lines. I currently use this which uses -Wl, to pass an the -S (or --strip-debug) option to the linker (and also reiterates the desire for a shared library, presumably superfluous): SHLIB_CXXLDFLAGS = -Wl,-S -shared SHLIB_CXX11LDFLAGS = -Wl,-S -shared SHLIB_CXX14LDFLAGS = -Wl,-S -shared SHLIB_FCLDFLAGS = -Wl,-S -shared SHLIB_LDFLAGS = -Wl,-S -shared Let's consider an example: my most recently uploaded package RProtoBuf. Built under a standard 64-bit Linux setup (Ubuntu 17.04, g++ 6.3) and not using the above, we end up with library containing 12 megabytes (!!) of object code: edd@brad:~/git/rprotobuf(feature/fewer_warnings)$ ls -lh src/ -rwxr-xr-x 1 edd edd 12M Aug 14 20:22 src/ edd@brad:~/git/rprotobuf(feature/fewer_warnings)$ However, if we use the flags shown above in .R/Makevars, we end up with much less: edd@brad:~/git/rprotobuf(feature/fewer_warnings)$ ls -lh src/ -rwxr-xr-x 1 edd edd 626K Aug 14 20:29 src/ edd@brad:~/git/rprotobuf(feature/fewer_warnings)$ So we reduced the size from 12mb to 0.6mb, an 18-fold decrease. And the file tool still shows the file as 'not stripped' as it still contains the symbols. Only debugging information was removed. What reduction in size can one expect, generally speaking? I have seen substantial reductions for C++ code, particularly when using tenmplated code. More old-fashioned C code will be less affected. It seems a little difficult to tell---but this method is my new build default as I continually find rather substantial reductions in size (as I tend to work mostly with C++-based packages). The second option only occured to me this evening, and complements the first which is after all only applicable locally via the ~/.R/Makevars file. What if we wanted it affect each installation of a package? The following addition to its src/Makevars should do: strippedLib: $(SHLIB) if test -e "/usr/bin/strip"; then /usr/bin/strip --strip-debug $(SHLIB); fi .phony: strippedLib We declare a new Makefile target strippedLib. But making it dependent on $(SHLIB), we ensure the standard target of this Makefile is built. And by making the target .phony we ensure it will always be executed. And it simply tests for the strip tool, an[...]

Reproducible builds folks: Reproducible Builds: Weekly report #119

Mon, 14 Aug 2017 23:30:01 +0000

Here's what happened in the Reproducible Builds effort between Sunday July 30 and Saturday August 5 2017: Media coverage We were mentioned on Late Night Linux Episode 17, around 29:30. Packages reviewed and fixed, and bugs filed Upstream packages: Bernhard M. Wiedemann: efl (merged), unique ids based on memory address 389-ds (merged), SOURCE_DATE_EPOCH support. plowshare, SOURCE_DATE_EPOCH support sphinx, file ordering sphinx, SOURCE_DATE_EPOCH support Debian packages: Adrian Bunk: #870212 filed against glib2.0. #870213 filed against pajeng. #870733 filed against openhpi. #870738 filed against gtk2-engines-xfce. #870741 filed against libgda5. #870742 filed against libgnome. #870749 filed against glade. #870821 filed against esys-particle. Chris Lamb: #870131 filed against autopep8. #870221 filed against dpkg. #870573 filed against grap. Johannes Schauer: #870585 filed against hevea. Logan Rosen: #870586 filed against behave. Lucas Nussbaum: #871059 filed against fltk1.3. #871155 filed against brltty. #871159 filed against texlive-extra. jathan: #870890 filed against apg. Reviews of unreproducible packages 29 package reviews have been added, 72 have been updated and 151 have been removed in this week, adding to our knowledge about identified issues. 4 issue types have been updated: Added timestamps_generated_by_hevea. Added timestamps_in_source_generated_by_rcc. Updated build_id_differences_only: remove an obsolete example. Updated golang_compiler_captures_build_path_in_binary: mark as not deterministic, because the patch fixing it is not yet upstreamed. Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by: Adrian Bunk (36) Andreas Beckmann (2) Daniel Schepler (2) Logan Rosen (1) Lucas Nussbaum (93) diffoscope development Version 85 was uploaded to unstable by Mattia Rizzolo. It included contributions from: Mattia Rizzolo: Add an explicit Recommends: on the defusedxml python package. Various other code quality tweaks. Juliana Oliveira Rodrigues: Fix test_ico_image for ImageMagick identify >= 6.9.8. Use the defusedxml XML library by default in the XML comparator, if it's available. This protects against various XML parser DoS attacks and other security holes, which other Python XML libraries are vulnerable to. Ximin Luo: Force a flush when writing output to diff. (Closes: #870049). as well as previous weeks' contributions, summarised in the changelog. There were also further commits in git, which will be released in a later version: Guangyuan Yang: tests/iso9660: support isoinfo's output coming from cdrtools' version instead of genisoimage's Mattia Rizzolo: Code quality and test fixes. Chris Lamb: Code quality and test fixes. Misc. This week's edition was written by Ximin Luo, Bernhard M. Wiedemann and Chris Lamb & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists. [...]

Jamie McClelland: Diversity doesn't help the bottom line

Mon, 14 Aug 2017 18:39:43 +0000

A Google software engineer's sexist screed against diversity has been making the rounds lately.

Most notable are the offensive and mis-guided statements about gender essentialism, which honestly make the thing hard to read at all.

What seems lost in the hype, however, is that his primary point seems quite accurate. In short: If Google successfully diversified it's workforce, racial and gender tensions would increase not decrease, divisiveness would spread and, with all liklihood, Google could be damaged.

Imagine what would happen if the thousands of existing, mostly male, white and Asian engineers, the majority of whom are convinced that they play no part in racism and sexism, were confronted with thousands of smart and ambitious women, African Americans and Latinos who were becoming their bosses, telling them to work in different ways, and taking "their" promotions.

It would be a revolution! I'd love to see it. Google's bosses definitely do not.

That's why none of the diversity programs at Google or any other major tech company are having any impact - because they are not designed to have an impact. They are designed to boost morale and make their existing engineers feel good about what they do.

Google has one goal: to make money. And one strategy: to design software that that people want to use. One of their tactics that is highly effective is building tight knit groups of programmers who work well together. If the creation of hostile, racist and sexist environments is a by-product - well, it's not one that affects their bottom line.

Would Google make better software with a more diverse group of engineers? Definitely! For one, if African American engineers were working on their facial recognition software, it's doubtful it would have mistaken people with black faces for gorillas.

However, if the perceived improvement in software outweighed the risks of diversification, then Google would not waste any time on feel-good programs and trainings - they would simply build a jobs pipeline and change their job outreach programs to recruit substantially more female, African Americans and Latino candidates.

In the end, this risk avoidance and failure to perceive the limitations of homogeneity is the achiles heel of corporate software design.

Our challenge is to see what we can build outside the confines of corporate culture that prioritizes profits, production efficiency, and stability. What can we do with teams that are willing to embrace racial and gender tension, risk diviseveness and be willing to see benefits beyond releasing version 1.0?

Antonio Terceiro: Debconf17

Mon, 14 Aug 2017 17:27:06 +0000

I’m back from Debconf17.

I gave a talk entitled “Patterns for Testing Debian Packages”, in which I presented a collection of 7 patterns I documented while pushing the Debian Continuous Integration project, and were published in a 2016 paper. Video recording and a copy of the slides are available.

I also hosted the ci/autopkgtest BoF session, in which we discussed issues around the usage of autopkgtest within Debian, the CI system, etc. Video recording is available.

Kudos for the Debconf video team for making the recordings available so quickly!

Holger Levsen: 20170812-reproducible-policy

Mon, 14 Aug 2017 16:53:57 +0000

"packages should build reproducibly" - after 4 years this work of many is in debian-policy now This post was written roughly 44h ago and now that the fix for #844431 has been merged into the git master branch, I'm publishing it - hoping you'll enjoy this as much as I do! So today is the last (official) day of DebConf17 and it looks like #844431: "packages should build reproducibly" will be merged into debian-policy today! So I'm super excited, super happy, quite tired and a bit sad (DebConf is ending…) right now! Four years ago Lunar held a BoF at DebConf13 which started the initiative in Debian. I only got involved in September 2014 with setting up continuous tests, rebuilding each package twice with some variations and then comparing the results using diffoscope, which back then was still called debbindiff and which we renamed as part of our efforts to make Reproducible Builds the norm in Free Software. Many people have worked on this, and I'm also very happy how visible this has been in our talk here yesterday. You people rock and I'm very thankful and proud to be part of this team. Thank you everyone! And please understand: we are not 94% done yet (which our reproducibility stats might have made you think), rather more like half done or so. We still need tools and processes to enable anyone to indepently verify that a given binary comes from the sources it is said to be coming, this will involve distributing .buildinfo files and providing user interfaces in APT and elsewhere. And probably also systematic rebuilds by us and other parties. And 6 or 7% of the archive are a lot of packages still, eg in Buster we currently still have 273 unreproducible key packages and for a large part we don't have patches yet. So there is still a lot of work ahead. This is what was added to debian-policy now: Reproducibility --------------- Packages should build reproducibly, which for the purposes of this document [#]_ means that given - a version of a source package unpacked at a given path; - a set of versions of installed build dependencies; - a set of environment variable values; - a build architecture; and - a host architecture, repeatedly building the source package for the build architecture on any machine of the host architecture with those versions of the build dependencies installed and exactly those environment variable values set will produce bit-for-bit identical binary packages. It is recommended that packages produce bit-for-bit identical binaries even if most environment variables and build paths are varied. It is intended for this stricter standard to replace the above when it is easier for packages to meet it. .. [#] This is Debian's precisification of the ` definition `_. For now violating this part of policy may result in a severity: normal bug, though I think we should still only file them if we have patches, else it's probably better to just take a note in our notes.git, like we did before the policy change. Finally one last comment: we could do reproducible security updates for Stretch now too, for those 94% of the packages which are reproducible. It just needs to be done by someones and the first step would be publishing those .buildinfo files from thos[...]

Tim Retout: Jenkins milestone steps do not work yet

Mon, 14 Aug 2017 14:57:36 +0000

Public Service Announcement for anyone relying on Jenkins for continuous deployment - the milestone step plugin as of version 1.3.1 will not function correctly if you could have more than two builds running at once - older builds could get deployed after newer builds.

See JENKINS-46097.

A possible workaround is to add an initial milestone at the start of the pipeline, which will then allow builds to be killed early. (Builds are only killed early once they have passed their first milestone.)

Going by the source history, I reckon this bug has been present since the milestone-step plugin was created.

Michal Čihař: New projects on Hosted Weblate

Mon, 14 Aug 2017 10:00:22 +0000


Hosted Weblate provides also free hosting for free software projects. The hosting requests queue was over one month long, so it's time to process it and include new project.

This time, the newly hosted projects include:

If you want to support this effort, please donate to Weblate, especially recurring donations are welcome to make this service alive. You can do them on Liberapay or Bountysource.

Filed under: Debian English SUSE Weblate

Dirk Eddelbuettel: RProtoBuf 0.4.10

Sun, 13 Aug 2017 22:08:00 +0000


RProtoBuf provides R bindings for the Google Protocol Buffers ("ProtoBuf") data encoding and serialization library used and released by Google, and deployed fairly widely in numerous projects as a language and operating-system agnostic protocol.

A new releases RProtoBuf 0.4.10 just appeared on CRAN. It is a maintenance releases replacing one leftover errorenous use of package= in .Call with the correct PACKAGE= (as requsted by CRAN). It also integrates a small robustification in the deserializer when encountering invalide objects; this was both reported and fixed by Jeffrey Shen.

Changes in RProtoBuf version 0.4.10 (2017-08-13)

  • More careful operation in deserializer checking for a valid class attribute (Jeffrey Shen in #29 fixing #28)

  • At the request of CRAN, correct one .Call() argument to PACKAGE=; update routine registration accordingly

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub issue tracker off 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.

Lars Wirzenius: Retiring Obnam

Sun, 13 Aug 2017 18:49:21 +0000

This is a difficult announcement to write. The summary is if you use Obnam you should switch to another backup program in the coming months. The first commit to Obnam's current code base is this: commit 7eaf5a44534ffa7f9c0b9a4e9ee98d312f2fcb14 Author: Lars Wirzenius Date: Wed Sep 6 18:35:52 2006 +0300 Initial commit. It's followed by over 5200 more commits until the latest one, which is from yesterday. The NEWS file contains 58 releases. There are 20761 lines of Python, 15384 words in the English language manual, with translations in German and French. The yarn test suite, which is a kind of a manual, is another 13382 words in English and pseudo-English. That's a fair bit of code and prose. Not all of it mine, I've had help from some wonderful people. But most of it mine. I wrote all of that because backups were fun. It was pleasing to use my own program to guarantee the safety of my own data. The technical challenges of implmenting the kind of backup program I wanted were interesting, and solving interesting problems is a big part of why I am a programmer. Obnam has a kind user base. It's not a large user base: the Debian "popularity contest" service estimates it at around 500. But it's a user base that is kind and has treated me well. I have tried to reciprocate. Unfortunately, I have not had fun while developing Obnam for some time now. This has changed. A few years ago, I lived in Manchester, UK, and commuted by train to work. It was a short train ride, about 15 minutes. At times I would sit on the floor with my laptop on my knees, writing code or the manual. Back then Obnam was a lot of fun. I was excited, and enthusiastic. In the past two years or so, I've not been able to feel that excitement again. My native language, Finnish, has an expression describing unpleasant tasks: something is as much fun as drinking tar. That describes Obnam in recent years for me. Obnam has not turned out well, from a maintainability point of view. It seems that every time I try to fix something, I break something else. Usuaully what breaks is speed or memory use: Obnam gets slower or starts using even more memory. For several years now I've been working on a new repository format for Obnam, code names GREEN ALBATROSS. It was meant to solve Obnam's problems as far as extensibility, performance, and resource use were concerned. It seems to have failed. I'm afraid I've had enough. I'm going to retire Obnam as a project and as a program, and move on to doing something else, so I can feel excitement and pleasure again. After some careful thought, I fear that the maintainability problems of Obnam can realistically only be solved by a complete rewrite from scratch, and I'm not up to doing that. If you use Obnam, you should migrate to some other backup solution. Don't worry, you have until the end of the year. I will be around and I intend to fix any serious bugs in Obnam; in particular, security flaws. But you should start looking for a replacement sooner rather than later. I will be asking Obnam to be removed from the Debian unstable and testing branches. The next Debian release (buster[...]

Mike Gabriel: @DebConf17: Ad-hoc BoF: Debian for the Remote Desktop

Sun, 13 Aug 2017 15:57:56 +0000

On Thursday at DebConf17, all people interested in using this or that Remote Desktop solution on Debian (as a server, as a client, as both) came together for a BoF. Sharing about Usage Scenarios Quite some time we informally shared with one another what technologies and software we use for remote access to Debian machines and what the experiences are. The situation in Debian and on GNU/Linux in general is that many technical approaches exist, all of them have certain features and certain limitations. The composition of features and limitations finally lead the users to choosing one or another technology as his or her favourite solution. The Debian Remote Maintainers Team On the developers' side, Dominik George and I set up a packaging team for Remote Desktop related software in Debian. A packaging team that we invite everyone who is maintaining such software in the widest sense to join: 'DebianRemote' namespace on the Debian Wiki For users of Debian, the group agreed, we need an overview page (on that provides an entry point for Debian on the Remote Desktop. An entry point that provides user information as well as developer information. A skeleton of this wiki page, I have just set up (thanks to Vagrant for taking some notes in Gobby during the BoF): However, the page still contains loads of FIXMEs, so the actual work only now really starts. Fill the template with content (and also adapt the template, if needed). Everyone with experience and know-how about Remote Desktop on Debian systems is invited to share knowledge and improve this wiki namespace. (I will, at the earliest, start working on Arctica, X2Go and NX passages end of August, but I'll be also happy to find passages having been written down that I can review by then). Tracking Debian Remote Issues in Debian BTS At the BoF, also the following suggestions came up: The Remote Desktop experience on a GNU/Linux desktop or terminal server can be affected by all graphical applications available. Often it happens, that a change in this or that graphical application results in problems in remote sessions, but not so in local sessions. We agreed on filing and tagging such bugs accordingly. For new bugs, please file such bugs with the following BTS header at the top of your mail and always explain what remote desktop solution is being used when the bug appears: Package: file Version: 1:5.19-2 Severity: important User: Usertags: debian-edu Conclusion Overall, I was quite happy that the BoF has been attended by so many people and to see that there is quite "a lobby" in Debian. Let's dive into the work and make Debian 10 the first Debian, that mentions the Remote Desktop in its release notes. Let's, in fact, release Debian 10 as the first Debian with the official announcement as an operating system for the Remote Desktop (like the Fedora people did already for Fedora 20). [...]

Enrico Zini: Consensually doing things together?

Sun, 13 Aug 2017 14:26:40 +0000

On 2017-08-06 I have a talk at DebConf17 in Montreal titled "Consensually doing things together?" (video). Here are the talk notes. Abstract At DebConf Heidelberg I talked about how Free Software has a lot to do about consensually doing things together. Is that always true, at least in Debian? I’d like to explore what motivates one to start a project and what motivates one to keep maintaining it. What are the energy levels required to manage bits of Debian as the project keeps growing. How easy it is to say no. Whether we have roles in Debian that require irreplaceable heroes to keep them going. What could be done to make life easier for heroes, easy enough that mere mortals can help, or take their place. Unhappy is the community that needs heroes, and unhappy is the community that needs martyrs. I’d like to try and make sure that now, or in the very near future, Debian is not such an unhappy community. Consensually doing things together I gave a talk in Heidelberg. Valhalla made stickers Debian France distributed many of them. There's one on my laptop. Which reminds me of what we ought to be doing. Of what we have a chance to do, if we play our cards right. I'm going to talk about relationships. Consensual relationships. Relationships in short. Nonconsensual relationships are usually called abuse. I like to see Debian as a relationship between multiple people. And I'd like it to be a consensual one. I'd like it not to be abuse. Consent From wikpedia: In Canada "consent means…the voluntary agreement of the complainant to engage in sexual activity" without abuse or exploitation of "trust, power or authority", coercion or threats.[7] Consent can also be revoked at any moment.[8]» There are 3 pillars often included in the description of sexual consent, or "the way we let others know what we're up for, be it a good-night kiss or the moments leading up to sex." They are: Knowing exactly what and how much I'm agreeing to Expressing my intent to participate Deciding freely and voluntarily to participate[20] Saying "I've decided I won't do laundry anymore" when the other partner is tired, or busy doing things. Is different than saying "I've decided I won't do laundry anymore" when the other partner has a chance to say "why? tell me more" and take part in negotiation. Resources: Relationships Debian is the Universal Operating System. Debian is made and maintained by people. The long term health of debian is a consequence of the long term health of the relationship between Debian contributors. Debian doesn't need to be technically perfect, it needs to be socially healthy. Technical problems can be fixed by a healty community. The Thomas-Kilmann Conflict Mode Instrument: source png. Motivations Quick poll: how many of you do things in Debian because you want to? how many of you do things in Debian because you have to? how many of you do both? What are your motivations to be in a relationship? Which of those motivations are healthy/unhealthy? healthy sustain the[...]

Mike Gabriel: @DebConf17: Work for Debian and FLOSS I got done during DebCamp and DebConf... and Beyond...

Sun, 13 Aug 2017 00:44:53 +0000

People I Met and will Remember Angela, my wife, I met daily on Jabber. Thanks for letting me go to this great DebConf17 conference and keeping our family up and running Andreas asking people to either impersonate his wife or adoptive daughter for a photo shooting. You gave such a touching talk on Friday, together with Minh from Vietnam. Holger for nagging us about stone age bugs in the Debian Blends package and the outdated software list in Debian Edu (Kernel 2.6.32 package are finally not mentioned anymore) Vagrant, Foetini and Alkis for there efforts on LTSP and their success in Greece with bringing Debian into Greek schools Tiago, Jerome and all the others from the local team, providing us with such great food and support. THANKS folks!!! Enrico who showed my his 20 liner version of nodm aka lightdm-autologin-greeter (and also made me curious on staticsite) Jonas Smedegaard for teaching me the solarized theme and loads of other things Siri for being around and really having a stand for making Debian look more like a product Dimitri John Ledkov for chiming in on Ayatana Indicators as next Indicators upstream for Ubuntu 18.04 LTS Chrys for chiming on .desktop file proxying, meet you back in #arctica on Freenode Sean for asking me daily, if my luggage had arrived (see below), as he shared the same fate during DebCamp the owner of that nice shop where I bought loads of clothes while waiting for my luggage still stuck in Hamburg Steven for looking into gcc compiler macros with me for nx-libs autotools conversion, also probably - luggage wise - the lightest traveller among us Fabian for sharing is sadness and pain about the FLOSS non-situation in schools all over Quebec Mario from New Zealand and Jos from the Netherlands chiming in on FLOSS and education on IRC after having watch my talk about Debian Edu / Skolelinux. Mario, we will soon ask you for opensourcing your teacher screen over WiFi solution... Lior who thinks about bringing Debian Edu / Skolelinux to Israel. (That would be awesome!) Rhonda for having time for my Debian Backports woes and probably having been quite forgiving ;-) Bobby who is a font engineer during the week and (used to be) a cave explorer and mapper in his spare time Ximin for providing deep insight in the key signing workflow and the caff approach to it Daniel for sharing work experiences and nudging me to go with Remote Desktop stuff (out of pure personal interest *g*, of course, but still) Tzfarir and Gunnar for a nice chat on the last night of DebConf Topics I have worked on Finding my luggage After I had arrived at Montreal Airport, I found out that my luggage stayed in Hamburg So the first 4.5 days, I was continuously busy with calling Lufthansa for package item tracking... Go shopping twice, to update my plastic bag of fresh clothes... MATE 1.18 in Debian Finalize package builds of MATE 1.18 in Debian unstable (because of some GLib2.0 regression, thanks to Iain Lane for the prompt fix and upload) Debian Edu clear up src:package debian-edu regarding the task files related to Debian[...]

Bits from Debian: DebConf17 closes in Montreal and DebConf18 dates announced

Sat, 12 Aug 2017 21:59:00 +0000

Today, Saturday 12 August 2017, the annual Debian Developers and Contributors Conference came to a close. With over 405 people attending from all over the world, and 169 events including 89 talks, 61 discussion sessions or BoFs, 6 workshops and 13 other activities, DebConf17 has been hailed as a success. Highlights included DebCamp with 117 participants, the Open Day, where events of interest to a broader audience were offered, talks from invited speakers (Deb Nicholson, Matthew Garrett and Katheryn Sutter), the traditional Bits from the DPL, lightning talks and live demos and the announcement of next year's DebConf (DebConf18 in Hsinchu, Taiwan). The schedule has been updated every day, including 32 ad-hoc new activities, planned by attendees during the whole conference. For those not able to attend, talks and sessions were recorded and live streamed, and videos are being made available at the Debian meetings archive website. Many sessions also facilitated remote participation via IRC or a collaborative pad. The DebConf17 website will remain active for archive purposes, and will continue to offer links to the presentations and videos of talks and events. Next year, DebConf18 will be held in Hsinchu, Taiwan, from 29 July 2018 until 5 August 2018. It will be the first DebConf held in Asia. For the days before DebConf the local organisers will again set up DebCamp (21 July - 27 July), a session for some intense work on improving the distribution, and organise the Open Day on 28 July 2018, aimed at the general public. DebConf is committed to a safe and welcome environment for all participants. See the DebConf Code of Conduct and the Debian Code of Conduct for more details on this. Debian thanks the commitment of numerous sponsors to support DebConf17, particularly our Platinum Sponsors Savoir-Faire Linux, Hewlett Packard Enterprise, and Google. About Savoir-faire Linux Savoir-faire Linux is a Montreal-based Free/Open-Source Software company with offices in Quebec City, Toronto, Paris and Lyon. It offers Linux and Free Software integration solutions in order to provide performance, flexibility and independence for its clients. The company actively contributes to many free software projects, and provides mirrors of Debian, Ubuntu, Linux and others. About Hewlett Packard Enterprise Hewlett Packard Enterprise (HPE) is one of the largest computer companies in the world, providing a wide range of products and services, such as servers, storage, networking, consulting and support, software, and financial services. HPE is also a development partner of Debian, and provides hardware for port development, Debian mirrors, and other Debian services. About Google Google is one of the largest technology companies in the world, providing a wide range of Internet-related services and products as online advertising technologies, search, cloud computing, software, and hardware. Google has been supporting Debian by sponsoring DebConf since more than ten years, at gold level since DebConf12, and at p[...]

Steve Kemp: A day in the life of Steve

Sat, 12 Aug 2017 21:00:00 +0000

I used to think I was a programmer who did "sysadmin-stuff". Nowadays I interact with too many real programmers to believe that. Or rather I can code/program/develop, but I'm not often as good as I could be. These days I'm getting more consistent with writing tests, and I like it when things are thoroughly planned and developed. But too often if I'm busy, or distracted, I think to myself "Hrm .. compiles? Probably done. Oops. Bug, you say?" I was going to write about working with golang today. The go language is minimal and quite neat. I like the toolset: go fmt Making everything consistent. go test Making testing an obvious and natural part of libraries and code. My personal puppet dashboard went from 0% code-coverage to ~60% coverage in the space of a few hours. Instead I think today I'm going to write about something else. Since having a child a lot of my life is different. Routine becomes something that is essential, as is planning and scheduling. So an average week-day goes something like this: 6:00AM Wake up (naturally). 7:00AM Wake up Oiva and play with him for 45 minutes. 7:45AM Prepare breakfast for my wife, and wake her up, then play with Oiva for another 15 minutes while she eats. 8:00AM Take tram to office. 8:30AM Make coffee, make a rough plan for the day. 9:00AM Work, until lunchtime which might be 1pm, 2pm, or even 3pm. 5:00PM Leave work, and take bus home. Yes I go to work via tram, but come back via bus. There are reasons. 5:40PM Arrive home, and relax in peace for 20 minutes. 6:00PM-7:00PM Take Oiva for a walk, stop en route to relax in a hammock for 30 minutes reading a book. 7:00-7:20PM Feed Oiva his evening meal. 7:30PM Give Oiva his bath, then pass him over to my wife to put him to bed. 7:30PM - 8:00pm Relax 8:00PM - 10:00PM Deal with Oiva waking up, making noises, or being unsettled. Try to spend quality time with my wife, watch TV, read a book, do some coding, etc. 10:00PM ~ 11:30PM Go to bed. In short I'm responsible for Oiva from 6ish-8ish in the morning, then from 6PM-10PM (with a little break while he's put to bed.) There are some exceptions to this routine - for example I work from home on Monday/Friday afternoons, and Monday evenings he goes to his swimming classes. But most working-days are the same. Weekends are a bit different. There I tend to take him 6AM-8AM, then 1PM-10PM with a few breaks for tea, and bed. At the moment we're starting to reach the peak-party time of year, which means weekends often involve negotiation(s) about which parent is having a party, and which parent is either leaving early, or not going out at all. Today I have him all day, and it's awesome. He's just learned to say "Daddy" which makes any stress, angst or unpleasantness utterly worthwhile. [...]

Bastian Blank: Network caps in cloud environments

Sat, 12 Aug 2017 21:00:00 +0000

Providing working network is not easy. All the cloud providers seem to know how to do that most of the time. Providing enough troughput is not easy either. Here it get's interresting as the cloud providers tackle that problem with completely different results.

There are essentially three large cloud providers. The oldest and mostly known cloud provider is Amazon Web Services (AWS). Behind that follow Microsoft with Azure and the Google Cloud Platform (GCP). Some public instances of OpenStack exist, but they simply don't count anyway. So we remain with three and they tackle this problem with widely different results.

Now, what network troughput is necessary for real world systems anyway? An old friend gives the advice: 1Gbps per Core of uncongested troughput within the complete infrastructure is the minimum. A generalization of this rule estimates around 1bps per clock cycle and core, so a 2GHz core would need 2Gbps. Do you even get a high enough network cap at your selected cloud provider to fill any of these estimates?

Our first provider, AWS, publishes a nice list of network caps for some of there instance types. The common theme in this list is: for two cores (all the *.large types) you get 500Mbps, for four cores (*.xlarge) you get 750Mbps and for eight cores (*.2xlarge) you get 1000Mbps. This is way below our estimate shown above and does not even raise linear with the number of cores. But all of this does not really matter anyway, as the performance of AWS is the worst of the three providers.

Our second provider, Azure, seems to not publish any real information about network caps at all. From my own knowledge it is 50MBps (500Mbps) per core for at least the smaller instances. At least is scales linear with instance size, but is still way below our estimates.

Our third provider, GCP, documents a simple rule for network caps: 2Gbps per core. This matches what we estimated.

Now the most important question: does this estimate really work and can we actually fill it. The answer is not easy. A slightly synthetic test of a HTTP server with cached static content showed that it can easily reach 7Gbps on a 2GHz Intel Skylake core. So yes, it gives a good estimate on what network troughput is needed for real world applications. However we still could easily file pipe that is larger by a factor of three.

Sam Hartman: Debian: a Commons of Innovation

Sat, 12 Aug 2017 20:10:54 +0000

I recently returned from Debconf. This year at Debconf, Matthew Garrett gave a talk about the next twenty years in free software. In his talk he raised concerns that Debian might not be relevant in that ecosystem and talked about some of the trends that contribute to his concerns.I was talking to Marga after the talk and she said that Debian used to be a lot more innovative than it is today.My initial reaction was doubt; what she said didn't feel right to me. At the time I didn't have a good answer. Since then I've been pondering the issue, and I think I have a partial answer to both Marga and Matthew and so I'll share it here.In the beginning Debian focused on a lot of technical innovations related to bringing an operating system together. We didn't understand how to approach builds and build dependencies in a uniform manner. Producing packages in a clean environment was hard. We didn't understand what we wanted out of packages in terms of a uniform approach to configuration handling and upgrades. To a large extent we've solved those problems.However, as the community has grown, our interests are more diverse. Our users and free software (and the operating system we build together) are what bring us together: we still have a central focus. However, no one technical project captures us all. There's still significant technical innovation in the Debian ecosystem. That innovation happens in Debian teams, companies and organizations that interact with the Debian community. We saw several talks about such innovation this year. I found the talk about ostree and flatpak interesting, especially because it focused on people in the broader Debian ecosystem valuing Debian along with some of the same technologies that Matthew is worried will undermine our relevance.Matthew talked about how Debian ends up being a man-in-the-middle. We're between users and developers. we're between distributions and upstreams. Users are frustrated because we hold back the latest version of software they want from getting to them. Developers are frustrated because we present our users with old versions of their software configured not as they would like, combined with different dependencies than they expect.All these weaknesses are real.However, I think Debian-in-the-middle is our greatest strength both on the technical and social front.I value Debian because I get a relatively uniform interface to the software I use. I can take one approach to reporting bugs whether they are upstream or Debian specific. I expect the software to behave in uniform ways with regard to things covered by policy. I know that I'm not going to have to configure multiple different versions of core dependencies; for the most part system services are shared. When Debian has value it's because our users want those things we provide. Debian has also reviewed every source file in the software we ship to understand the license and license compatibility. A[...]

Thorsten Glaser: [PSA] Fixing CVE-2017-12836 (Debian #871810) in GNU cvs

Fri, 11 Aug 2017 23:49:00 +0000

Considering I’ve become the de-facto upstream of cvs(GNU) even if not yet formally the de-iure upstream maintainer, fixing this bug obviously falls to me — not quite the way I had planned passing this evening after coming home from work and a decent and, worse, very filling meal at the local Croatian restaurant. But, so’s life. The problem here is basically that CVS invokes ssh(1) (well, rsh originally…) but doesn’t add the argument separator “--” before the (user-provided) hostname, which when starting with a hyphen-minus will be interpreted by ssh as an argument. (Apparently the other VCSes also had additional vulnerabilities such as not properly escaping semicoloi or pipes from the shell or unescaping percent-escaped fun characters, but that doesn’t affect us.) The obvious fix and the one I implemented first is to simply add the dashes. This will also be backported to Debian {,{,old}old}stable-security. Then I looked at other VCSes out of which only one did this, but they all added extra paranoia hostname checks (some of them passing invalid hostnames, such as those with underscores in them). OK, I thought, then also let’s add extra checks to CVS’ repository reference handling. This will end up in Debian sid and MirBSD, pending passing the regression tests of course… hah, while writing this article I had to fixup because a test failed. Anyway, it’s not strictly necessary AFAICT to fix the issue. Update, about 2⅕ hours past midnight (the testsuite runs for several hours): of course, the “sanity” testsuite (which itself is rather insane…) also needs adjustments, plus a bonus fix (for something that got broken when the recent allow-root-regex patch was merged and got fixed in the same go to…night). tl;dr: a fix will end up in Debian *stable-security and can be taken out of my mail to the bugreport; another few changes for robustness are being tested and then added to both MirBSD and Debian sid. The impact is likely small, as it’s hard to get a user (if you find one, in the first place) to use a crafted CVSROOT string, which is easy to spot as well. Update, Monday: apparently someone took care of the DSA and DLA yesterday after ACCEPTing the uploads — thanks, I was outside during the day. [...]

Michal Čihař: Weblate 2.16

Fri, 11 Aug 2017 17:15:36 +0000


Weblate 2.16 has been released today while I'm at DebConf17. There are quite some performance improvements (and more of that is scheduled for 2.17), new file formats support and various other improvements.

Full list of changes:

  • Various performance improvements.
  • Added support for nested JSON format.
  • Added support for WebExtension JSON format.
  • Fixed git exporter authentication.
  • Improved CSV import in certain situations.
  • Improved look of Other translations widget.
  • The max-length checks is now enforcing length of text in form.
  • Make the commit_pending age configurable per component.
  • Various user interface cleanups.
  • Fixed component/project/sitewide search for translations.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is also being used on as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

Mike Gabriel: @DebConf 2017: Ayatana Indicators

Fri, 11 Aug 2017 15:30:34 +0000

On last Tuesday, I gave a 20 min talk about Ayatana Indicators at DebConf 17 in Montreal. Ayatana Indicators Talk The talk had video coverage, so big thanks to the DebConf video team for making it possible to send the below video link around to people in the world: The document of notes shown in the video is available on Debian's Infinote (Gobby) server: $ sudo apt-get install gobby $ sudo gobby infinote:// The major outcome of this talk was getting to know Dimitri John Ledkov from the Foundation Team at Canonical Ltd. We agreed on investigating the following actions, targetting the Ubuntu 18.04 LTS release and later on Debian 10 (aka buster): Upstream Todos We need to find out what indicator applets are still needed (already there: application, session, power; w-i-p: messages, not yet touch: sound, datetime, transfer). If you maintain a desktop environment and need indicator support, please contact us. Rip-out liburl-dispatcher and Mir related code from all ayatana-indicator-* code projects (upstream) Build-time disable phone and tablet related code (upstream). If you are from the UBPorts project and have concerns about this, please contact us. Fully deprecate all Ubuntu Indicators upstream projects on Launchpad and point to Ayatana Indicators as upstream source for indicators in the Ubuntu ecosystem Debian/Ubuntu Todos Update, most important change for packagers: The team will use Git from now on, not Bazaar. Get in touch with people maintaining indicator related packages (packages that have libappindicator-dev as build-dependency) to prepare for the transition from Ubuntu Indicators (unmaintained upstream, unmaintained in Debian) to Ayatana Indicators (package list, see DDPO Ayatana Developers Overview) File bug reports against all packages still dependending on Ubuntu Indicators in Debian and ideally provide patches to make those packages build against Ayatana Indicators Do the Ayatana Indicator transition in Debian Please get in Touch... As this is going to be quite an effort, esp. if we want to get this done until 18.04 LTS, let me say, that this blog post is a call for help. If you are attached to Ubuntu and have used desktops with indicator support until now, please get in touch with the Ayatana Indicators team upstream as well as downstream (Debian/Ubuntu). Contact: Ayatana Indicators upstream: #arctica on Freenode IRC Ayatana Indicators in Debian: #debian-ayatana on Debian/OFTC IRC Mailing list: Ubuntu Desktop Developers: #ubuntu-desktop on Freenode IRC Looking forward to meeting you online or on person and possibly working together with you on this transition project. [...]

Mike Gabriel: @DebConf17: Story Telling about Debian Edu in Northern Germany

Fri, 11 Aug 2017 14:40:21 +0000

Last Monday, I gave a 20min talk about our little FLOSS school project "IT-Zukunft Schule" at the Debian Conference 17 in Montreal. The talk had video coverage, so may want to peek in, if you couldn't manage to watch the life stream: I'd like to share some major outcomes (so far) of this talk. I realized how attached I am to "IT-Zukunft Schule" and how much it means to me that our kids grow up in a world of freedom and choice. Also and esp. when it comes to choosing your daily communication tools and computer working environment I met Foteini Tsiami and Alkis Georgopoulos from Greece. They work on LTSP and have deployed 1000+ schools in Greece with LTSP + Debian GNU/Linux + MATE Desktop Environment I met Vagrant Cascadian who is the maintainer of LTSP in Debian and also a major LTSP upstream contributor I received a lot of fine feedback that was very encouraging to go on with our local work in Schleswig-Holstein If you have some more time for watching DebConf talks on video, I dearly recommend the talk given by Alkis and Foteini on their Greek FLOSS success story. If you don't have that much time, please skip through the video until you are at 26:15 and enjoy the map that shows how much Debian + LTSP has spread over all of Greece. Unfortunately, the schools in Greece are so much smaller than schools in Germany. Most schools there have between 50 and 300 students. So at the Greek schools, it is possible to have a teacher machine being the server for one computer lab. This teacher / server machine provides the infrastructure for a room full of LTSP fat clients (no hard drive inside) and that's it. For German schools, unfortunately, we need a larger scale setup. German schools often have 800+ students and network services need to be spread over more than one server machine. So, the current approach with one server running LDAP, Kerberos etc. is quite appropriate, but also extendible, possibly on municipality level or on county level. We (from IT-Zukunft Schule) are quite positive that there will be opportunities for introducing FLOSS approaches more on the county level in Schleswig-Holstein in the near future. So stay tuned... [...]

Lucas Nussbaum: systemd services, and queue management?

Fri, 11 Aug 2017 12:40:36 +0000


I’ve been increasingly using systemd timers as a replacement for cron jobs. The fact that you get free logging is great, and also the fact that you don’t have to care about multiple instances running simultaneously.

However, sometimes I would be interested in more complex scenarios, such as:

  • I’d like to trigger a full run of the service unit: if the service is not running, it should be started immediately. If it’s currently running, it should be started again when it terminates.
  • Same as the above, but with queue coalescing: If I do the above multiple times in a row, I only want the guarantee that there’s one full run of the service after the last time I triggered it (typical scenario: each run processes all pending events, so there’s no point in running multiple times).

Is this doable with systemd? If not, how do people do that outside of systemd?

Kartik Mistry: DebConf17

Thu, 10 Aug 2017 19:15:03 +0000


So, I’m here. It will take sometime to write about this, but this is to just reminder to myself that I exists on this blog too! (image)


Don Armstrong: Debbugs: 22 Years of Bugs (Debconf 2017)

Thu, 10 Aug 2017 18:41:52 +0000


This is a talk which I presented on August 10th, 2017 at Debconf 17 in Montreal, Canada.

François Marier: pristine-tar and git-buildpackage Work-arounds

Thu, 10 Aug 2017 05:25:45 +0000

I recently ran into problems trying to package the latest version of my planetfilter tool. This is how I was able to temporarily work-around bugs in my tools and still produce a package that can be built reproducibly from source and that contains a verifiable upstream signature. pristine-tar being is unable to reproduce a tarball After importing the latest upstream tarball using gbp import-orig, I tried to build the package but ran into this pristine-tar error: $ gbp buildpackage gbp:error: Pristine-tar couldn't checkout "planetfilter_0.7.4.orig.tar.gz": xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3 decode failed! at /usr/share/perl5/Pristine/Tar/ line 56. pristine-tar: command failed: pristine-gz --no-verbose --no-debug --no-keep gengz /tmp/user/1000/pristine-tar.mgnaMjnwlk/wrapper /tmp/user/1000/pristine-tar.EV5aXIPWfn/planetfilter_0.7.4.orig.tar.gz.tmp pristine-tar: failed to generate tarball So I decided to throw away what I had, re-import the tarball and try again. This time, I got a different pristine-tar error: $ gbp buildpackage gbp:error: Pristine-tar couldn't checkout "planetfilter_0.7.4.orig.tar.gz": xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3 decode failed! at /usr/share/perl5/Pristine/Tar/ line 56. pristine-tar: command failed: pristine-gz --no-verbose --no-debug --no-keep gengz /tmp/user/1000/pristine-tar.mgnaMjnwlk/wrapper /tmp/user/1000/pristine-tar.EV5aXIPWfn/planetfilter_0.7.4.orig.tar.gz.tmp pristine-tar: failed to generate tarball I filed bug 871938 for this. As a work-around, I simply symlinked the upstream tarball I already had and then built the package using the tarball directly instead of the upstream git branch: ln -s ~/deve/remote/planetfilter/dist/planetfilter-0.7.4.tar.gz ../planetfilter_0.7.4.orig.tar.gz gbp buildpackage --git-tarball-dir=.. Given that only the upstream and master branches are signed, the .delta file on the pristine-tar branch could be fixed at any time in the future by committing a new .delta file once pristine-tar gets fixed. This therefore seems like a reasonable work-around. git-buildpackage doesn't import the upstream tarball signature The second problem I ran into was a missing upstream signature after building the package with git-buildpackage: $ lintian -i planetfilter_0.7.4-1_amd64.changes E: planetfilter changes: orig-tarball-missing-upstream-signature planetfilter_0.7.4.orig.tar.gz N: N: The packag[...]

John Goerzen: A new baby and deep smiles

Thu, 10 Aug 2017 00:25:52 +0000


A month ago, we were waiting for our new baby; time seemed to stand still. Now she is here! Martha Goerzen was born recently, and she is doing well and growing! Laura and I have enjoyed moments of cuddling her, watching her stare at our faces, hearing her (hopefully) soft sounds as she falls asleep in our arms. It is also heart-warming to see Martha’s older brothers take such an interest in her. Here is the first time Jacob got to hold her:


Oliver, who is a boy very much into sports, play involving police and firefighters, and such, has started adding “aww” and “she’s so cute!” to his common vocabulary. He can be very insistent about interrupting me to hold her, too.

Thorsten Glaser: New mksh and jupp releases, mksh FAQ, jupprc for JOE 4.4; MuseScore

Thu, 10 Aug 2017 00:00:00 +0000

mksh R56 was released with experimental fixes for the “history no longer persisted when HISTFILE near-full” and interactive shell cannot wait on coprocess by PID issues (I hope they do not introduce any regressioins) and otherwise as a bugfix release. You might wish to know the $EDITOR selection mechanism in dot.mkshrc changed. Some more alias characters are allowed again, and POSIX character classes (for ASCII, and EBCDIC, only) appeared by popular vote. mksh now has a FAQ; enjoy. Do feel free to contribute (answers, too, of course). The jupp text editor has also received a new release; asides from being much smaller, and updated (mksh too, btw) to Unicode 10, and some segfault fixes, it features falling back to using /dev/tty if stdin or stdout is not a terminal (for use on GNU with find | xargs jupp, since they don’t have our xargs(1) -o option yet), a new command to exit nonzero (sometimes, utilities invoking the generic visual editor need this), and “presentation mode”. Presentation mode, crediting Natureshadow, is basically putting your slides as (UTF-8, with fancy stuff inside) plaintext files into one directory, with sorting names (so e.g. zero-padded slide numbers as filenames), presenting them with jupp * in a fullscreen xterm. You’d hit F6 to switch to one-file view first, then present by using F8 to go forward (F7 to go backward), and, for demonstrations, F9 to pipe the entire slide through an external command (could be just “sh”) offering the previous one as default. Simple yet powerful; I imagine Sven Guckes would love it, were he not such a vim user. The new release is offered as source tarball (as usual) and in distribution packages, but also, again, a Win32 version as PKZIP archive (right-click on setup.inf and hit I̲nstall to install it). Note that this comes with its own (thankfully local) version of the Cygwin32 library (compatible down to Windows 95, apparently), so if you have Cygwin installed yourself you’re better off compiling it there and using your own version instead. I’ve also released a new DOS version of 2.8 with no code patches but an updated jupprc; the binary (self-extracting LHarc archive) this time comes with all resource files, not just jupp’s. Today, the jupprc drop-in file for JOE 3.7 got a matching update (and some fixes for bugs discovered during that) and I added a new one for JOE 4.4 (the former being in Debian wheezy, the latter in jessie, stretch and buster/sid). It’s a bit rudimentary (the new shell window functionality is absent) but, mostly, gives the desired jupp feeling, more so than just using stock jstar would. source tarballs Win32 binari[...]

Petter Reinholdtsen: Simpler recipe on how to make a simple $7 IMSI Catcher using Debian

Wed, 09 Aug 2017 21:59:00 +0000

On friday, I came across an interesting article in the Norwegian web based ICT news magazine on how to collect the IMSI numbers of nearby cell phones using the cheap DVB-T software defined radios. The article refered to instructions and a recipe by Keld Norman on Youtube on how to make a simple $7 IMSI Catcher, and I decided to test them out. The instructions said to use Ubuntu, install pip using apt (to bypass apt), use pip to install pybombs (to bypass both apt and pip), and the ask pybombs to fetch and build everything you need from scratch. I wanted to see if I could do the same on the most recent Debian packages, but this did not work because pybombs tried to build stuff that no longer build with the most recent openssl library or some other version skew problem. While trying to get this recipe working, I learned that the apt->pip->pybombs route was a long detour, and the only piece of software dependency missing in Debian was the gr-gsm package. I also found out that the lead upstream developer of gr-gsm (the name stand for GNU Radio GSM) project already had a set of Debian packages provided in an Ubuntu PPA repository. All I needed to do was to dget the Debian source package and built it. The IMSI collector is a python script listening for packages on the loopback network device and printing to the terminal some specific GSM packages with IMSI numbers in them. The code is fairly short and easy to understand. The reason this work is because gr-gsm include a tool to read GSM data from a software defined radio like a DVB-T USB stick and other software defined radios, decode them and inject them into a network device on your Linux machine (using the loopback device by default). This proved to work just fine, and I've been testing the collector for a few days now. The updated and simpler recipe is thus to start with a Debian machine running Stretch or newer, build and install the gr-gsm package available from, clone the git repostory from, run grgsm_livemon and adjust the frequency until the terminal where it was started is filled with a stream of text (meaning you found a GSM station). go into the IMSI-catcher directory and run 'sudo python' to extract the IMSI numbers. To make it even easier in the future to get this sniffer up and running, I decided to package the gr-gsm project for Debian (WNPP #871055), and the package was uploaded into the NEW queue today. Luckily the gnuradio maintainer has promised to help me, as I do not know much about gnuradio stuff y[...]

Joey Hess: unifying OS installation and configuration management

Wed, 09 Aug 2017 15:57:13 +0000

Three years ago, I realized that propellor (my configuration management system that is configured using haskell) could be used as an installer for Debian (or other versions of Linux). In propellor is d-i 2.0, I guessed it would take "a month and adding a few thousand lines of code". I've now taken that month, and written that code, and I presented the result at DebConf yesterday. I demoed propellor building a live Debian installation image, and then handed it off to a volenteer from the audience to play with its visual user interface and perform the installation. The whole demo took around 20 minutes, and ended with a standard Debian desktop installation. (Video) The core idea is to reuse the same configuration management system for several different purposes. Building a bootable disk image that can be used as both a live system and as an OS installer. Running on that live system, to install the target system. Which can just involve copying the live system to the target disk and then letting the configuration management system make the necessary changes to get from the live system configuration to the target system configuration. To support such things as headless arm boards, building customized images tuned for the target board and use case, that can then simply be copied to the board to install. Optionally, running on the installed system later, to futher customize it. Starting from the same configuration that produced the installed system in the first place. There can be enourmous code reuse here, and improvements made for one of those will often benefit all the rest as well. Once everything is handled by configuration management, all user interface requirements become just a matter of editing the configuration. Including: A user interface that runs on the live system and gets whatever input is needed to install to the target system. This is really just a config editor underneath. I built a prototype gamified interface that's as minimal as such an interface could get. With a regular text editor, of course. This is the equivilant of preseeding in d-i, giving advanced users full control over the system that gets built. Unlike with preseeding, users have the full power of a configuration management system, so can specify precisely the system they want installed. A separate user interface for customizing disk images, for arm boards and similar use cases. This would run on a server, or on the user's own laptop. That's the gist of it. Configuration management reused for installation and image building, and multiple editor interfaces to make it widely usable. I was glad, sitting in to [...]

Junichi Uekawa: reading up on rapidjson.

Wed, 09 Aug 2017 00:14:14 +0000

(image) reading up on rapidjson. I was reading the docs for rapidjson performance and I like that source buffer is destroyed for performance. I was wrinting JSON parser myself and performance bottleneck seems to be copying and constructing objects.

Jonathan Dowland: libraries

Tue, 08 Aug 2017 20:50:01 +0000


Cover for The Rise Of The Meritocracy

At some point during my Undergraduate years I lost the habit of using Libraries. On reflection this is probably Amazon's fault. In recent years I've tried to get back into the habit of using them.

Using libraries is a great idea if you are trying to lead a more minimalist life. I am registered to use Libraries in two counties: North Tyneside, where I live, and Newcastle, where I work. The union of the two counties' catalogues is pretty extensive. Perhaps surprisingly I have found North Tyneside to offer both better customer service and a more interesting selection of books.

Sometimes there are still things that are hard to get ahold of. After listening to BBC Radio 4's documentary The Rise and Fall of Meritocracy, presented by Toby Young, I became interested in reading The Rise of the Meritocracy: an alarmist, speculative essay that coined the term meritocracy, written by Toby's father, Michael Young.

The book was not on either catalogue. It is out of print, with the price of second hand copies fluctuating but generally higher than I am prepared to pay. I finally managed to find a copy in Newcastle University's Library. As an associate of the School of Computing I have access to the Library services.

It's an interesting read, and I think if it were framed more as a novel than as an essay it might be remembered in the same bracket as Brave New World or 1984.

Wouter Verhelst: DebConf17 first videos published

Tue, 08 Aug 2017 12:11:12 +0000


Due to some technical issues, it took a slight bit longer than I'd originally expected; but the first four videos of the currently running DebConf 17 conference are available. Filenames are based on the talk title, so that should be reasonably easy to understand. I will probably add an RSS feed (like we've done for DebConf 16) to that place some time soon as well, but code for that still needs to be written.

Meanwhile, we're a bit behind on the reviewing front, with (currently) 34 talks still needing review. If you're interested in helping out, please join the #debconf-video channel on OFTC and ask what you can do. This is something which you can do from home if you're interested, so don't be shy! We'd be happy for your help.

Ben Hutchings: Debian LTS work, July 2017

Mon, 07 Aug 2017 22:35:08 +0000


I was assigned 15 hours of work by Freexian's Debian LTS initiative and worked 14 hours. I will carry over 1 hour to the next month.

I prepared and released an update on the Linux 3.2 longterm stable branch (3.2.91), and started work on the next update. However, I didn't make any uploads to Debian this month.

Raphaël Hertzog: My Free Software Activities in July 2017

Mon, 07 Aug 2017 14:49:58 +0000

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (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 was allocated 12 hours but I only managed to work for 7 hours (due to vacation and unanticipated customer work). I gave back the remaining hours to the pool as I didn’t want to carry them over for August which will be also short due to vacation (BTW I’m not attending Debconf). I spent my 7 hours doing CVE triaging during the week where I was in charge of the LTS frontdesk (I committed 22 updates to the security tracker). I did publish DLA-1010-1 on vorbis-tools but the package update had been prepared by Petter Reinholdtsen. Misc Debian work zim. I published an updated package in experimental (0.67~rc2-2) with the upstream bug fixes on the current release candidate. The final version has been released during my vacation and I will soon upload it to unstable. Debian Handbook. I worked with Petter Reinholdtsen to finalize the paperback version of the Norwegian translation of the Debian Administrator’s Handbook (still covering Debian 8 Jessie). It’s now available. Bug reports. I filed a few bugs related to my Kali work. #868678: autopkgtest’s setup-testbed script is not friendly to derivatives. #868749: aideinit fails with syntax errors when /etc/debian_version contains spaces. debian-installer. I submitted a few d-i patches that I prepared for a customer who had some specific needs (using the hd-media image to boot the installer from an ISO stored in an LVM logical volume). I made changes to debian-installer-utils (#868848), debian-installer (#868852), and iso-scan (#868859, #868900). Thanks See you next month for a new summary of my activities. No comment | Liked this article? Click here. | My blog is Flattr-enabled. [...]

Gunnar Wolf: #DebConf17, Montreal • An evening out

Mon, 07 Aug 2017 11:49:07 +0000


I have been in Montreal only for a day. Yesterday night, I left DebConf just after I finished presenting the Continuous Key-Signing Party introduction to go out with a long-time friend from Mexico and his family. We went to the Mont Royal park, from where you can have a beautiful city view:



What I was most amazed of as a Mexico City dweller is of the sky, of the air... Not just in this picture, but as we arrived, or later when a full moon rose. This city has beautiful air, and a very beautiful view. We later went for dinner to a place I heartfully recommend to other non-vegetarian attendees:


Portuguese-style grill. Delicious. Of course, were I to go past it, I'd just drive on (as it had a very long queue waiting to enter). The secret: Do your request on the phone. Make a short queue to pick it up. Have somebody in the group wait for a table, or eat at the nearby Parc Lafontaine. And... Thoroughly enjoy :-)

Anyway, I'm leaving for the venue, about to use the Bixi service for the first time. See you guys soon! (if you are at DebConf17, of course. And you should all be here!)

Montreal1.jpeg112.83 KB
Montreal2.jpeg118.2 KB
Poule.jpeg118.85 KB