On Sunday night I started the process of upgrading the LUV server to Debian/Jessie from Debian/Wheezy. My initial plan was to just upgrade Apache first but dependencies required upgrading systemd too. One problem I ve encountered in the past is that the Wheezy version of systemd will often hang on an upgrade to a newer version. Generally the solution to this is to run systemctl daemon-reexec from another terminal. The problem in this case was that not all the libraries needed for systemd had been installed, so systemd could re-exec itself but immediately aborted. The kernel really doesn t like it when process 1 aborts repeatedly and apparently immediately hanging is the result. At the time I didn t know this, all I knew was that my session died and the server stopped responding to pings immediately after I requested a reexec. The LUV server is hosted at VPAC for free. As their staff have actual work to do they couldn t spend a lot of time working on the LUV server. They told me that the screen was flickering and suspected a VGA cable. I got to the VPAC server room with the spare LUV server (LUV had been given 3 almost identical Sun servers from Barwon Water) at 16:30. By 17:30 I had fixed the core problem (boot with init=/bin/bash , mount the root filesystem rw, finish the upgrade of systemd and it s dependencies, and then reboot normally). That got it into a stage where the Xen server for Wikimedia Au was working but most LUV functionality wasn t working. By 23:00 on Monday I had the full list server functionality working for users, this is the main feature that users want when it s not near a meeting time. I can t remember whether it was Monday night or Tuesday morning when I got the Drupal site going (the main LUV web site). Last night at midnight I got the last of the Mailman administrative interface going, I admit I could have got it going a bit earlier by putting SE Linux in permissive mode, but I don t think that the members would have benefited from that (I ll upload a SE Linux policy package that gets Mailman working on Jessie soon). Now it s Wednesday and I m still fixing some cron jobs. Along the way I noticed some problems with excessive disk space use that I m fixing now and I ve also removed some Wikimedia related configuration files that were obsolete and would have prevented anyone from using a wikimedia.org.au address to subscribe to the LUV mailing lists. Now I believe that everything is working correctly and generally working better than before. Lessons Learned While Sunday night wasn t a bad time to start the upgrade it wasn t the best. If I had started the upgrade on Monday morning there would have been less down-time. Another possibility might be to do the upgrade while near the VPAC office during business hours, I could have started the upgrade while at a nearby cafe and then visited the server room immediately if something went wrong. Doing an upgrade on a day when there s no meeting within a week was a good choice. It wasn t really a conscious choice as I m usually doing other LUV work near the meeting day which precludes doing other LUV work that doesn t need to be done soon. But in future it would be best to consciously plan upgrades for a date when users aren t going to need the service much. While the Wheezy systemd bug is unlikely to ever be fixed there are work-arounds that shouldn t result in a broken server. At the moment it seems that the best option would be to kill -9 the systemctl processes that hang until the packages that systemd depends on are installed. The problem is that the upgrade hangs while the new systemctl tries to tell the old systemd to restart daemons. If we can get past that to the stage where the shared objects are installed then it should be ok. The Apache upgrade from 2.2.x to 2.4.x changed the operation of some access control directives and it took me some time to work out how to fix that. Doing a Google search on the differences between those would have led me to the Apache document about upgrading from 2.2 to 2.4 [1]. That wouldn t have prevented some down-time of the web sites but would have allowed me to prepare for it and to more quickly fix the problems when they became apparent. Also the rather confusing configuration of the LUV server (supporting many web sites that are no longer used) didn t help things. I think that removing cruft from an installation before an upgrade would be better than waiting until after things break. Next time I do an upgrade of such a server I ll write notes about it while I go. That will give a better blog post about it if it becomes newsworthy enough to be blogged about and also more opportunities to learn better ways of doing it. Sorry for the inconvenience.

• [1] https://httpd.apache.org/docs/trunk/upgrading.html

Review: The Oathbound, by Mercedes Lackey

Series:	Vows and Honor #1
Publisher:	DAW
Copyright:	July 1988
ISBN:	0-88677-414-4
Format:	Mass market
Pages:	302

This book warrants a bit of explanation. Before Arrows of the Queen, before Valdemar (at least in terms of publication dates), came Tarma and Kethry short stories. I don't know if they were always intended to be set in the same world as Valdemar; if not, they were quickly included. But they came from another part of the world and a slightly different sub-genre. While the first two Valdemar trilogies were largely coming-of-age fantasy, Tarma and Kethry are itinerant sword-and-sorcery adventures featuring two women with a soul bond: the conventionally attractive, aristocratic mage Kethry, and the celibate, goddess-sworn swordswoman Tarma. Their first story was published, appropriately, in Marion Zimmer Bradley's Swords and Sorceress III. This is the first book about Tarma and Kethry. It's a fix-up novel: shorter stories, bridged and re-edited, and glued together with some additional material. And it does not contain the first Tarma and Kethry story. As mentioned in my earlier Valdemar reviews, this is a re-read, but it's been something like twenty years since I previously read the whole Valdemar corpus (as it was at the time; I'll probably re-read everything I have on hand, but it's grown considerably, and I may not chase down the rest of it). One of the things I'd forgotten is how oddly, from a novel reader's perspective, the Tarma and Kethry stories were collected. Knowing what I know now about publishing, I assume Swords and Sorceress III was still in print at the time The Oathbound was published, or the rights weren't available for some other reason, so their first story had to be omitted. Whatever the reason, The Oathbound starts with a jarring gap that's no less irritating in this re-read than it was originally. Also as is becoming typical for this series, I remembered a lot more world-building and character development than is actually present in at least this first book. In this case, I strongly suspect most of that characterization is in Oathbreakers, which I remember as being more of a coherent single story and less of a fix-up of puzzle and adventure stories with scant time for character growth. I'll be able to test my memory shortly. What we do get is Kethry's reconciliation of her past, a brief look at the Shin'a'in and the depth of Tarma and Kethry's mutual oath (unfortunately told more than shown), the introduction of Warrl (again, a relationship that will grow a great deal more depth later), and then some typical sword and sorcery episodes: a locked room mystery, a caravan guard adventure about which I'll have more to say later, and two rather unpleasant encounters with a demon. The material is bridged enough that it has a vague novel-like shape, but the bones of the underlying short stories are pretty obvious. One can tell this isn't really a novel even without the tell of a narrative recap in later chapters of events that you'd just read earlier in the same book. What we also get is rather a lot of rape, and one episode of seriously unpleasant "justice." A drawback of early Lackey is that her villains are pure evil. My not entirely trustworthy memory tells me that this moderates over time, but early stories tend to feature villains completely devoid of redeeming qualities. In this book alone one gets to choose between the rapist pedophile, the rapist lord, the rapist bandit, and the rapist demon who had been doing extensive research in Jack Chalker novels. You'll notice a theme. Most of the rape happens off camera, but I was still thoroughly sick of it by the end of the book. This was already a cliched motivation tactic when these stories were written. Worse, as with the end of Arrow's Flight, the protagonists don't seem to be above a bit of "turnabout is fair play." When you're dealing with rape as a primary plot motivation, that goes about as badly as you might expect. The final episode here involves a confrontation that Tarma and Kethry brought entirely on themselves through some rather despicable actions, and from which they should have taken a lesson about why civilized societies have criminal justice systems. Unfortunately, despite an ethical priest who is mostly played for mild amusement, no one in the book seems to have drawn that rather obvious conclusion. This, too, I recall as getting better as the series goes along and Lackey matures as a writer, but that only helps marginally with the early books. Some time after the publication of The Oathbound and Oathbreakers, something (presumably the rights situation) changed. Oathblood was published in 1998 and includes not only the first Tarma and Kethry story but also several of the short stories that make up this book, in (I assume) something closer to their original form. That makes The Oathbound somewhat pointless and entirely skippable. I re-read it first because that's how I first approached the series many years ago, and (to be honest) because I'd forgotten how much was reprinted in Oathblood. I'd advise a new reader to skip it entirely, start with the short stories in Oathblood, and then read Oathbreakers before reading the final novella. You'd miss the demon stories, but that's probably for the best. I'm complaining a lot about this book, but that's partly from familiarity. If you can stomach the rape and one stunningly unethical protagonist decision, the stories that make it up are solid and enjoyable, and the dynamic between Tarma and Kethry is always a lot of fun (and gets even better when Warrl is added to the mix). I think my favorite was the locked room mystery. It's significantly spoiled by knowing the ending, and it has little deeper significance, but it's a classic sort unembellished, unapologetic sword-and-sorcery tale that's hard to come by in books. But since it too is reprinted (in a better form) in Oathblood, there's no point in reading it here. Followed by Oathbreakers. Rating: 6 out of 10

Categories:

• Debian-Blog
• Tools

Keywords:

• systemd
• cgroups
• desktop
• digikam

Like:

What happened in the reproducible builds effort this week: Toolchain fixes

• Scott Kitterman uploaded python3-defaults/3.4.3-7 which changes py3versions to list versions in a consistent order. Issue reported by Santiago Vila with a tentative patch by Chris Lamb. Sadly, it appears the problem is not entirely solved.
• Martin Pitt uploaded init-system-helpers/1.24 which makes the order of unit files in maintainer scripts stable. Original patch by Reiner Herrmann.
• Niko Tyni uploaded libextutils-xsbuilder-perl/0.28-3 which makes the generated XS code reproducible.

Niko Tyni wrote a new patch adding support for SOURCE_DATE_EPOCH in Pod::Man. This would complement or replace the previously implemented POD_MAN_DATE environment variable in a more generic way. Niko Tyni proposed a fix to prevent mtime variation in directories due to debhelper usage of cp --parents -p. Packages fixed The following 119 packages became reproducible due to changes in their build dependencies: aac-tactics, aafigure, apgdiff, bin-prot, boxbackup, calendar, camlmix, cconv, cdist, cl-asdf, cli-common, cluster-glue, cppo, cvs, esdl, ess, faucc, fauhdlc, fbcat, flex-old, freetennis, ftgl, gap, ghc, git-cola, globus-authz-callout-error, globus-authz, globus-callout, globus-common, globus-ftp-client, globus-ftp-control, globus-gass-cache, globus-gass-copy, globus-gass-transfer, globus-gram-client, globus-gram-job-manager-callout-error, globus-gram-protocol, globus-gridmap-callout-error, globus-gsi-callback, globus-gsi-cert-utils, globus-gsi-credential, globus-gsi-openssl-error, globus-gsi-proxy-core, globus-gsi-proxy-ssl, globus-gsi-sysconfig, globus-gss-assist, globus-gssapi-error, globus-gssapi-gsi, globus-net-manager, globus-openssl-module, globus-rsl, globus-scheduler-event-generator, globus-xio-gridftp-driver, globus-xio-gsi-driver, globus-xio, gnome-control-center, grml2usb, grub, guilt, hgview, htmlcxx, hwloc, imms, kde-l10n, keystone, kimwitu++, kimwitu-doc, kmod, krb5, laby, ledger, libcrypto++, libopendbx, libsyncml, libwps, lprng-doc, madwimax, maria, mediawiki-math, menhir, misery, monotone-viz, morse, mpfr4, obus, ocaml-csv, ocaml-reins, ocamldsort, ocp-indent, openscenegraph, opensp, optcomp, opus, otags, pa-bench, pa-ounit, pa-test, parmap, pcaputils, perl-cross-debian, prooftree, pyfits, pywavelets, pywbem, rpy, signify, siscone, swtchart, tipa, typerep, tyxml, unison2.32.52, unison2.40.102, unison, uuidm, variantslib, zipios++, zlibc, zope-maildrophost. The following packages became reproducible after getting fixed:

• autoconf2.13/2.13-67 uploaded by Ben Pfaff, original patch by Santiago Vila.
• ding/1.8-3 by Roland Rosenfeld.
• dropbear/2015.68-1 by Guilhem Moulin. First set of patches (#777324, #793006) by Chris Lamb and akira.
• nvram-wakeup/1.1-3 by Tobias Grimm.
• original-awk/2012-12-20-5 by Santiago Vila.
• resiprocate/1:1.10.0-1 uploaded by Daniel Pocock, patch by Reiner Herrmann merged upstream.
• sbuild/0.66.0-5 by Johannes Schauer, reported by Jakub Wilk.
• scribus/1.4.5+dfsg1-4 by Mattia Rizzolo.
• sgmltools-lite/3.0.3.0.cvs.20010909-19 by Santiago Vila.
• unicode-data/8.0-2 uploaded by Alastair McKinstry, original patch by Esa Peuha.
• xmoto/0.5.11+dfsg-3 by Stephen Kitt.

Packages which could not be tested:

• mp4h/1.3.1-11 by Axel Beckert (shared memory issue on reproducible.debian.net).
• nvidia-graphics-drivers-legacy-304xx/304.128-5 by Andreas Beckmann (non-free).

Some uploads fixed some reproducibility issues but not all of them:

• libvirt/1.2.20-1 by Guido G nther.
• libgpars-groovy-java/1.2.1-4 by Emmanuel Bourg.

Patches submitted which have not made their way to the archive yet:

• #801520 on libapache2-mod-perl2 by Niko Tyni: sort the list of files used to build the documentation.
• #801523 on perl by Niko Tyni: sort the list of input files in PPPort_xs.PL. Forwarded upstream.
• #801864 on ncurses by Esa Peuha: use C locale when sorting the list of keys.
• #802042 on libchado-perl by Niko Tyni: sort keys in installed configuration file.

Lunar reported that test strings depend on default character encoding of the build system in ongl. reproducible.debian.net The 189 packages composing the Arch Linux core repository are now being tested. No packages are currently reproducible, but most of the time the difference is limited to metadata. This has already gained some interest in the Arch Linux community. An explicit log message is now visible when a build has been killed due to the 12 hours timeout. (h01ger) Remote build setup has been made more robust and self maintenance has been further improved. (h01ger) The minimum age for rescheduling of already tested amd64 packages has been lowered from 14 to 7 days, thanks to the increase of hardware resources sponsored by ProfitBricks last week. (h01ger) diffoscope development diffoscope version 37 has been released on October 15th. It adds support for two new file formats (CBFS images and Debian .dsc files). After proposing the required changes to TLSH, fuzzy hashes are now computed incrementally. This will avoid reading entire files in memory which caused problems for large packages. New tests have been added for the command-line interface. More character encoding issues have been fixed. Malformed md5sums will now be compared as binary files instead of making diffoscope crash amongst several other minor fixes. Version 38 was released two days later to fix the versioned dependency on python3-tlsh. strip-nondeterminism development strip-nondeterminism version 0.013-1 has been uploaded to the archive. It fixes an issue with nonconformant PNG files with trailing garbage reported by Roland Rosenfeld. disorderfs development disorderfs version 0.4.1-1 is a stop-gap release that will disable lock propagation, unless --share-locks=yes is specified, as it still is affected by unidentified issues. Documentation update Lunar has been busy creating a proper website for reproducible-builds.org that would be a common location for news, documentation, and tools for all free software projects working on reproducible builds. It's not yet ready to be published, but it's surely getting there. Package reviews 103 reviews have been removed, 394 added and 29 updated this week. 72 FTBFS issues were reported by Chris West and Niko Tyni. New issues: random_order_in_static_libraries, random_order_in_md5sums.

Undecided whether the title should be "exercises in Yak shaving" or "paying back technical debt" or "too much complexity for personal systems". Anyway I started hosting my personal website and some other small stuff on a dedicated box (rented from a provider) in early 2008. Even for a relatively cheap box, it worked without issues for a good number of years. A surprising number of years, actually; the only issue was a power supply failure that was solved by the provider automatically and then nothing for many years. Even the harddrive (mechanical) had no issues at all for 7 years (Power_On_Hours: 64380; I probably got it after it had a few months of uptime). I believe it was the longest running harddrive I've ever used (for the record: Seagate Barracuda 7200.10, ST3250310AS). The reason I delayed upgrade for a long time was twofold: first, at the same provider I couldn't get a similar SLA for the same amount of money. I could get better hardware, but with worse SLA and options. This is easily solvable, of course, by just finding a different provider. The other issue was that I never bothered to setup proper configuration management for the host; after all, it was only supposed to run Apache with ikiwiki and some other trivial small other things. The truth was that over time it started pilling up more and more "small things" so actually changing the host is expensive. As the age of the server neared 7 years, I thought to combine upgrade from Wheezy to Jessie with a HW upgrade. Managed to find a different provider that had my desired SLA and HW configuration, got the server and the only thing left was to do the migration. Previous OS upgrades were simple as they were on the same host; i.e. rely on Debian's reliable upgrade and nothing else to, eventually adjust slightly some configs. With a cross-host upgrade (I couldn't just copy the old OS since it was also a 32-to-64 bit change) it's much worse: since there's no previous installation, I had to manually check and port the old configuration for each individual service. This got very tedious, and I realised I have to make it somehow better. "Proper" configuration management aside, I thought that I need proper monitoring first. I already had (for a long while actually) graphing via Munin, but no actual monitoring. Since the host only had few services, this was again supposed to be easy - same mistake again. The problem is that once you have any monitoring system setup, it's very easy to actually add "just one more" host or service to it. First it was only the external box, then it was my firewall, then it was the rest of my home network. Then it was the cloud services that I use for example, checking whether my domain registrar's nameservers still are authoritative for my domain or whether the expiration date it still far in the future. And so on In the end, what was in previous iterations (e.g. Squeeze to Wheezy upgrade) a half-weekend job only, spread out over many weekends (interleaved with other activities, not fully working on it). I had to keep the old machine running for a month more in order to make sure everything was up and running, and I ended up with 80 services monitored across multiple systems; the migrated machine itself has almost half of these. Some of these are light items (e.g. a checking that a single vhost responds) other are aggregates. I still need to add some more checks though, especially more complex (end-to-end) ones. The lesson I learned in all this is that, with or without configuration management in place, having monitoring makes it much easier do to host or service moves, as you know much better when everything is done whether it's "done-done" or just "almost done". The question that remains though: with 80 services for a home network plus external systems (personal use); I'm not sure if I'm doing things right (monitor the stuff I need) or wrong (do I really need these many things)?

Today I ran a hands-on training session on configuring a MTA with Postfix and Dovecot for LUV. I gave each student a virtual machine running Debian/Jessie with full Internet access and instructions on how to configure it as a basic mail server. Here is a slightly modified set of instructions that anyone can do on their own system. Today I learned that documentation that includes passwords on a command-line should have quotes around the password, one student used a semi-colon character in his password which caused some confusion (it s the command separator character in BASH). I also discovered that trying to just tell users which virtual server to login to is prone to errors, in future I ll print out a list of user-names and passwords for virtual servers and tear off one for each student so there s no possibility of 2 users logging in to the same system. I gave each student a sub-domain of unixapropos.com (a zone that I use for various random sysadmin type things). I have changed the instructions to use example.com which is the official address for testing things (or you could use any zone that you use). The test VMs that I setup had a user named auser , the documentation assumes this account name. You could change auser to something else if you wish. Below are all the instructions for anyone who wants to try it at home or setup virtual machines and run their own training session. Basic MTA Configuration

1. Run apt-get install postfix to install Postfix, select Internet Site for the type of mail configuration and enter the domain name you selected for the mail name.
2. The main Postfix configuration file is /etc/postfix/main.cf. Change the myhostname setting to the fully qualified name of the system, something like mta.example.com.
   You can edit /etc/postfix/main.cf with vi (or any other editor) or use the postconf command to change it, eg postconf -e myhostname=mta.example.com .
3. Add home_mailbox=Maildir/ to the Postfix configuration to make it deliver to a Maildir spool in the user s home directory.
4. Restart Postfix to apply the changes.
5. Run apt-get install swaks libnet-ssleay-perl to install swaks (a SMTP test tool).
6. Test delivery by running the command swaks -f auser@example.com -t auser@example.com -s localhost . Note that swaks displays the SMTP data so you can see exactly what happens and if something goes wrong you will see everything about the error.
7. Inspect /var/log/mail.log to see the messages about the delivery. View the message which is in ~auser/Maildir/new.
8. When other students get to this stage run the same swaks command but with the -t changed to the address in their domain, check the mail.log to see that the messages were transferred and view the mail with less to see the received lines. If you do this on your own specify a recipient address that s a regular email address of yours (EG a Gmail account).

Basic Pop/IMAP Configuration

1. Run apt-get install dovecot-pop3d dovecot-imapd to install Dovecot POP and IMAP servers.
   Run netstat -tln to see the ports that have daemons listening on them, observe that ports 110 and 143 are in use.
2. Edit /etc/dovecot/conf.d/10-mail.conf and change mail_location to maildir:~/Maildir . Then restart Dovecot.
3. Run the command nc localhost 110 to connect to POP, then run the following commands to get capabilities, login, and retrieve mail:
   user auser
   pass WHATEVERYOUMADEIT
   capa
   list
   retr 1
   quit
4. Run the command nc localhost 143 to connect to IMAP, then run the following commands to list capabilities, login, and logout:
   a capability
   b login auser WHATEVERYOUMADEIT
   c logout
5. For the above commands make note of the capabilities, we will refer to that later.

Now you have a basically functional mail server on the Internet! POP/IMAP Over SSL To avoid password sniffing we need to use SSL. To do it properly requires obtaining a signed key for a DNS address but we can do the technical work with the snakeoil certificate that is generated by Debian.

1. Edit /etc/dovecot/conf.d/10-ssl.conf and change ssl = no to ssl = required . Then add the following 2 lines:
   ssl_cert = </etc/ssl/certs/ssl-cert-snakeoil.pem
   ssl_key = </etc/ssl/private/ssl-cert-snakeoil.key
2. 1. Run netstat -tln and note that ports 993 and 995 are not in use.
   2. Edit /etc/dovecot/conf.d/10-master.conf and uncomment the following lines:
      port = 993
      ssl = yes
      port = 995
      ssl = yes
   3. Restart Dovecot, run netstat -tln and note that ports 993 and 995 are in use.
3. Run nc localhost 110 and nc localhost 143 as before, note that the capabilities have changed to include STLS/STARTTLS respectively.
4. Run gnutls-cli --tofu 127.0.0.1 -p 993 to connect to the server via IMAPS and gnutls-cli --tofu 127.0.0.1 -p 995 to connect via POP3S. The --tofu option means to Trust On First Use , it stores the public key in ~/.gnutls and checks it the next time you connect. This allows you to safely use a snakeoil certificate if all apps can securely get a copy of the key.

Postfix SSL

1. Edit /etc/postfix/main.cf and add the following 4 lines:
   smtpd_tls_received_header = yes
   smtpd_tls_loglevel = 1
   smtp_tls_loglevel = 1
   smtp_tls_security_level = may
   Then restart Postfix. This makes Postfix log TLS summary messages to syslog and in the Received header. It also permits Postfix to send with TLS.
2. Run nc localhost 25 to connect to your SMTP port and then enter the following commands:
   ehlo test
   quit
   Note that the response to the EHLO command includes 250-STARTTLS, this is because Postfix was configured with the Snakeoil certificate by default.
3. Run gnutls-cli --tofu 127.0.0.1 -p 25 -s and enter the following commands:
   ehlo test
   starttls
   ^D
   After the CTRL-D gnutls-cli will establish a SSL connection.
4. Run swaks -tls -f auser@example.com -t auser@example.com -s localhost to send a message with SSL encryption. Note that swaks doesn t verify the key.
5. Try using swaks to send messages to other servers with SSL encryption. Gmail is one example of a mail server that supports SSL which can be used, run swaks -tls -f auser@example.com -t YOURADDRESS@gmail.com to send TLS (encapsulated SSL) mail to Gmail via swaks. Also run swaks -tls -f auser@example.com -t YOURADDRESS@gmail.com -s localhost to send via your new mail server (which should log that it was a TLS connection from swaks and a TLS connection to Gmail).

SASL SASL is the system of SMTP authentication for mail relaying. It is needed to permit devices without fixed IP addresses to send mail through a server. The easiest way of configuring Postfix SASL is to have Dovecot provide it s authentication data to Postfix. Among other things if you change Dovecot to authenticate in another way you won t need to make any matching changes to Postfix.

1. Run mkdir -p /var/spool/postfix/var/spool and ln -s ../.. /var/spool/postfix/var/spool/postfix , this allows parts of Postfix to work with the same configuration regardless of whether they are running in a chroot.
2. Add the following to /etc/postfix/main.cf and restart Postfix:
   smtpd_sasl_auth_enable = yes
   smtpd_sasl_type = dovecot
   smtpd_sasl_path = /var/spool/postfix/private/auth
   broken_sasl_auth_clients = yes
   smtpd_sasl_authenticated_header = yes
3. Edit /etc/dovecot/conf.d/10-master.conf, uncomment the following lines, and then restart Dovecot:
   unix_listener /var/spool/postfix/private/auth
   mode = 0666
   
4. Edit /etc/postfix/master.cf, uncomment the line for the submission service, and restart Postfix. This makes Postfix listen on port 587 which is allowed through most firewalls.
5. From another system (IE not the virtual machine you are working on) run swaks -tls -f auser@example.com -t YOURADDRESS@gmail.com -s YOURSERVER and note that the message is rejected with Relay access denied .
6. Now run swaks -tls --auth-user auser --auth-password WHATEVER -f auser@example.com -t YOURREALADDRESS -s YOURSERVER and observe that the mail is delivered (subject to anti-spam measures at the recipient).
Configuring a MUA If every part of the previous 3 sections is complete then you should be able to setup your favourite MUA. Use auser as the user-name for SMTP and IMAP, mail.example.com for the SMTP/IMAP server and it should just work! Of course you need to use the same DNS server for your MUA to have this just work. But another possibility for testing is to have the MUA talk to the server by IP address not by name.
Related posts:
1. Mail Server Security I predict that over the course of the next 10...
2. I need an LMTP server I am working on a system where a front-end mail...
3. Moving a Mail Server Nowadays it seems that most serious mail servers (IE mail...

One of the packages that got lost in the transition from Debian wheezy to jessie was the update-notifier-common package which could be used to receive notifications when a reboot is needed (for example, after installing a kernel update). I decided to wrap this piece of functionality along with a simple cron job and create a new package: reboot-notifier. Because it uses the same file (/var/run/reboot-required) to indicate that a reboot is needed, it should work fine with any custom scripts that admins might have written prior to jessie. If you're running sid or strech, all you need to do is:

apt install reboot-notifier

On jessie, you'll need to add the backports repository to /etc/apt/sources.list:

deb http://httpredir.debian.org/debian jessie-backports main

For a while I've been wanting to tidy up some of my existing ikiwiki hacks, as well as test some changes I'd like to make to this site, but I hadn't had much success with setting up environments to play with it. That was until earlier in the year, when as a bit of an experiment I tried to put ikiwiki in docker. I've put up a preliminary image for anyone who is curious. It's in a very early state. When you start up the image, you get a HTTP daemon listening on port 8080 and serving a basic ikiwiki from /. A single administrative user is defined, user admin and password password. The CGI is set up (path /cgi) and websetup is enabled. The ikiwiki instance is configured with git as the vcs backend and the git HTTP backend is also enabled at path /git. It is set up for anonymous pull and HTTP basic authentication for push, with admin/password.

• Image: https://hub.docker.com/r/jmtd/ikiwiki
• Source: https://github.com/jmtd/debian-docker/tree/ikiwiki/ikiwiki

There's still a lot to do before this is useful for what I want to do with it, and I would strongly advise against using it for anything except testing yourself, unless you are going to layer on some changes (HTTPS and change the credentials at the very least!) but I thought I'd put it out there. If you have any suggestions for it, please either file an issue or leave a comment here. It's built on top of the stuff I mentioned last time but it should rebase on top of the "semi-official" Debian images without problems.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In September, 71.50 work hours have been dispatched among 7 paid contributors. Their reports are available:

• Ben Hutchings did 9 hours (out of the 14.5 hours that he had allocated, he will catch up in October).
• Guido G nther did 8 hours.
• Mike Gabriel did 16 hours (8 assigned + 8 remaining from month before).
• Rapha l Hertzog did 8 hours.
• Santiago Ruano Rinc n did 14.5 hours.
• Scott Kitterman did nothing out of the 4 hours allocated. He will catch up in October.
• Thorsten Alteholz did 14.50 hours.

Evolution of the situation October is back to the highest level of funding with 85.5 hours funded. The late sponsors have all caught up now. And next month will again rise to a new record with multiple sponsors having joined up. So far we already have two new silver sponsors (Universit Jean Monnet de Saint- tienne and Univention GmbH) and a new bronze sponsor (Entr ouvert). Many thanks to them! With those sponsors we crossed the 50% mark that was our first objective. \o/ But we still need more support to reach our second goal of funding the equivalent of a full time position. That said the increased level of support already allows us to do a better job in some areas that have been neglected : I asked the paid contributors to work towards providing mysql-5.5 in squeeze since version 5.1 is no longer supported by Oracle. We need beta testers to test the upgrade, see this message on the mailling list. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 15 packages awaiting an update (3 less than last month), the list of open vulnerabilities in Squeeze shows about 23 affected packages in total (7 less than last month). Thanks to our sponsors The new sponsors are in bold.

• Gold sponsors:
• The Positive Internet (for 16 months already)
• Blablacar (for 15 months already)
• Linode LLC (for 5 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 16 months already)
• Domeneshop AS (for 15 months already)
• Universit Lille 3 (for 15 months already)
• Trollweb Solutions (for 13 months already)
• Gandi SAS (for 10 months already)
• University of Luxembourg (for 7 months already)
• Rentabiliweb Group (for 5 months already)
• Univention GmbH
• Universit Jean Monnet de St Etienne
• Bronze sponsors:
• Offensive Security (for 16 months already)
• Seznam.cz, a.s. (for 16 months already)
• Evolix (for 15 months already)
• Freeside Internet Service (for 15 months already)
• MyTux (for 15 months already)
• Linuxhotel GmbH (for 13 months already)
• Intevation GmbH (for 12 months already)
• Daevel SARL (for 11 months already)
• FOSSter (for 11 months already)
• Bitfolk LTD (for 10 months already)
• Megaspace Internet Services GmbH (for 10 months already)
• Gree, Inc. (for 9 months already)
• Greenbone Networks GmbH (for 9 months already)
• NUMLOG (for 9 months already)
• WinGo AG (for 8 months already)
• Ecole Centrale de Nantes LHEEA (for 5 months already)
• Sig-I/O
• Entr ouvert

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

Earlier today, Josh sent the text below in this message to the R-SIG-Finance list as the very first heads-up concerning the 2016 edition of our successful R/Finance series. We are once again very excited about our conference, thrilled about upcoming keynotes (some of which are confirmed and some of which are in the works), and hope that many R / Finance users will not only join us in Chicago in May 2016 -- but also submit an exciting proposal. So read on below, and see you in Chicago in May!

Note: 2015/10/16: I need to add some links but I won t delay this more, posting now, will edit later. Summer ended long time ago, but believe me, I m still catching up with all the things that I began in June/July, all the things I left in August when I went holidays, and more things that appeared in August and September. This is a long overdue post, I hope you bear with me for waiting so long, and writing (now) so long too! June In June, I was 100% sure that I would not attend DebConf15 (well, I was 98% sure until then), and when the new Outreach Sponsorship grants were announced, I decided to write some mails to several Debian contributors, so they consider applying for the grant and attend DebConf (and maybe trigger some i18n/l10n meeting ). They kindly declined, and I understood their reasons, but also wondered what would have happened if the proposal would have come from somebody more official instead of a random contributor that they don t know. I also hoped that lots of other Debianites also write to newbies or not-yet-DD-contributors or non-packaging contributors to invite them to DebConf, and I hoped that they had better luck than me in convincing them :) July In July I usually work hard preparing the computer labs for next academic year at my workplace in the University, but I also have more free time in the long afternoons and evenings, since I don t sleep much, and there is not much to do outside with the summer hot. So I used that month to go on contributing to DebConf publicity and think a bit more about Debian and the other free software communities. I didn t put much time in advancing my selfhosting (no SSL yet in *.larjona.net! booooo!) but I decided to deep my toe in Sandstorm.io, and try to selfhost an instance ( http://lacaja.larjona.net ) and try Etherpad inside Sandstorm (since I failed in deploying Etherpad by myself in my jessie+nginx+postgres box). Sandstorm worked, and Etherpad was packaged in Sandstorm so it worked too; and I have my free-software-base pads now for writing and share. So I joined #sandstorm IRC channel since then, and there I learnt that Asheesh Laroia (who works in Sandstorm.io and is also a Debian Developer and was going to give a talk about Sandstorm.io in DebConf15) was offering mentorship for people wanting to learn Sandstorm packaging, and his proposal was to begin packaging Framadate. I also failed in selfhosting Dudle (prepared for Apache + FastCGI, couldn t make it work in my Nginx), so Asheesh s proposal looked suitable for me. We talked and decided to invest the rest of July and first days of August in learning to package Framadate. I learned a lot, but couldn t finish the task. I encountered many issues (setting my dev environment, and later trying to package), and we solved some of them but my time ran out. I posted my work in the list, and I hope that my feedback on the documentation and the issues I encountered helped Asheesh and the Sandstorm community. Framadate is packaged in Sandstorm.io now, Drew Fisher packaged it, not sure if my stuff was useful or not (it s been useful for me, for learning, at least). I ll talk more about Sandstorm.io in a future blog post updating on my selfhosting adventures. What I liked most was the kind of proposal of mentoring that Asheesh made. It was very detailed in every aspect: the task, the things you need to accomplish it, details about his availability for mentorship I try to be welcoming in the teams in which I participate, but the fact is that I fail in actually mentor, maybe because of not making specific proposals to people (until now, I was like Hi, newcomer! Go read this, this and this, and try for yourself any task you feel you like it, and come back if you have issues , la Debian ). This, plus the thoughts about my mails in June for diversity outreach in DebConf, made me feel the need of having a team where people willing to welcome newcomers share tricks and procedures, write together more specific proposals, and follow up the newcomers experiences in a regular way. I talked with Enrico Zini and we wrote down some notes for a Welcome Team in Debian; he said he would spread the word during DebCamp/DebConf and we would see what people thinks about it. August August came, and the day before going on holidays I was really tired: too much luggage to prepare, too many hours in front of the computer, and the usual stress of traveling; and I took the bad decision of signing some GPG keys of several Debianites that I met in July. I say bad decision because the lack of sleep showed its black magic and I accidentally deleted my secring.gpg file. I knew I had a backup but I didn t have too much time to invest and I didn t want to mess it with the backup too, and my laptop was going to stay at home, powered off, during the whole month, so I just went on holidays and left the GPG issue for later. The day after, meanwhile I was waiting in the airport for my boarding time, I received a mail accepting me as Debian Developer. Wow!! Really, I was not expecting that the process was already finished, I had interchanged several mails with my Application Manager (who happens to be the current DPL!) and I thought that his summer could be quite packed of Debian/DebConf work and my process could wait a bit. So it was a very happy news and very motivating after one month (July) full of free software work. On the other side, I was a bit scared: what type of Debian Developer are you, larjona, not capable to sign some GPG keys without breaking your setup?! but I answered myself well, I m the type of Debian Developer that has backups :) and then, with that mixed feelings of excitement and impostor syndrome, I took my plane and went on holidays, not expecting to touch any computer until the end of the month. August is probably the month in the year when I have more free time (holidays), but less time to dedicate to free software. I devote most of the month to visit family and stay with them, with no internet connection available or no free time to look at the mailbox or social networks or IRC But DebCamp and DebConf15 were happening during my holidays. And this DebConf15 was the first one in which I participated in the organization, and the first one in which I felt more than being a consumer of Debian videos . I could not follow the streamings, my only internet-capable device was my Android 2.x phone, but when I had wifi I fetched the mail, and during the nights, while everybody else was sleeping and I was laying on the terrace, below the sky full of stars, I could read batches of hundred of mails from debconf-discuss mailing list. And I could get some feeling from DebConf life, because I learned about the ad-hoc BoFs and discussions, the morning bike rides and swimming proposals, and the dancing classes, the i18m/l10n meeting, and many other things. I could answer some mail from time to time, and I also knew that a fellow Debianite from Madrid was going to bring me some stickers, maybe a t-shirt, and shake hands in my name to some persons. September and October September was about finishing reading all the mails and try to answer the pending ones, and preparing my computer to use my new Debian identity (and stop using larjona-guest). I still have some things to do, pending technical work, and some mails that I should have answered and I ve forgotten, for sure (if you sent me a mail that needs answer or would be fine that I answer (even if it was months ago!), please resend or ping me). I recovered my secring.gpg but and just now I added larjona@debian.org to the ID in my GPG key, but didn t signed the pending keys again (sorry dkg and holger! will catch up there soon). My subkeys expired and I m trying to find out how to proceed (they are in my FSFE SmartCard) :/ About the Debian teams, I ve resumed my work in publicity team (this year I ll try to be more involved, in Debian Project News in particular), partially in the website team, and recently I ve finished catching up with the Spanish translation of the website. I ve also joined the DebConf team again (for DebConf16, no matter I probably won t attend) and documented the Publicity task for DebConf, and I try to engage the mailing list and the IRC meetings. I finally could have time to watch some DebConf15 videos and Andreas Tille s talk ( Creating a more inviting environment for newcomers New experiences from MoM, SoB, Teammetrics ) helped me to step ahead in welcoming people with more useful stuff than Hi, newcomer! Go read this (general URLs), try for yourself whatever you like . I have made specific proposals for two people. In mid September I accepted an interview about Debian for a podcast with quite a lot audience (in Spanish), in which I explained the idea of the Welcome Team and offered myself as first-contact. Since then, two more people have contacted me and I have offered specific tasks I think are suitable for them. I also try to be more available in the IRC and offer some time spans for new contributors to DebConf to explain the git setup, the wiki, and all this stuff that looks more complicated than what it is. And I think that s all. My Debianite friend kindly brought me some stickers and a DebConf t-shirt, plus the organization t-shirt that the team gave me as present for my contributions in DebConf15. Neil McGovern kindly sent me a certificate of my new Debian Developer status (thanks!!), and it s posted in my wall at work. Here you are a photo! (Note: my wall is full of stickers and pieces of papers with things I need, things I like and things I use to explain my work (sometimes sarcastically/ironically ). Maybe some day I ll make a blog post about that!) I feel very proud and happy. Still, a lot of things to learn and work to do, but my intentions are: to keep on progressing (sometimes fast, sometimes slowly), never give up, and enjoy the multiple flowers I find in my way :) Thanks everybody! October and future Some other ideas/plans for the future (the ones I didn t say yet):

• Try to catch up with Debian Contributors development/news, adopt some data source (www.debian.org?), try to create some new data source (about translators, for example).
• Clean spam in the archive lists (now that I am DD I may help in not only Mark as spam , but actually remove the spam from the archive)
• Help in the review/updates of the Debian website (ongoing: /users; future: children-distros/derivatives, /partners).
• Try to get more involved in the Debian i18n team, at least in the part of internationalizing the Debian infrastructure (make translatable via PO files/templates many texts that used repetitively in the Debian website, for example) and in welcoming new members in translation teams or helping the weak ones (although I don t know many languages, the workflow and tools are common, so I think I could help new translators at least to get hands on the matter).
• Maybe some short screencasts/videos about the Debian infrastructure, for newcomers? (mailing lists, IRC, wiki, Alioth )

Comments? If you want to comment you can use this pump.io thread.
Filed under: My experiences and opinion, News Tagged: Communities, Contributing to libre software, Debian, Developer motivations, encryption, English, Free Software, gpg, libre software

I am not going to talk about Norbert Preining's continuous ranting against Debian's Code of Conduct. Suffice to say that it annoys me, and that I think he is wrong. I am, however going to mention that contrary to his statements (penultimate paragraph), yes, the Code of Conduct is supposed to apply to Planet Debian as well. Its introductory paragraph states:

The Debian Project, the producers of the Debian system, have adopted a code of conduct for participants to its mailinglists, IRC channels and other modes of communication within the project.

Note the "other modes of communication within the project" bit. Planet Debian is planet.debian.org. If your blog is aggregated there, you are communicating within the project. At least that's my interpretation of it.

Step by step, one slips towards the bottom:

1. One should be blunt with those who are wrong.
2. One is blunt when one is right.
3. When one thinks to be right, one is blunt.
4. One is wrong and blunt.

Let's note anyway that one can slip to the bottom without being vulgar or insulting. In any large project like Debian, one can find people who know how to be very oppressive, while keeping a very correct communication style. Debian is a broad project, and it is easy to avoid them, unless one tries make contributions that can be related to keywords like committee , code , policy , delegation , etc. In that case, it is better to retrieve the good old thick skin from the cupboard where we stored it after our code of conduct was adopted...

There are some things that I didn't mention in my sort-of quickly written entry about DebConf15. So first things first. When I received the mail about the room allocation I was at first confused. I was put into a room with other ladies, which I didn't expect. Granted, two of the other three names were people that knew me since a while, but it still felt like a mistake might have happened. But after a while I realized what has happened: It wasn't a mistake, it was intentional, I was finally recognized as woman for the room allocation too, which made me extremely happy. I was just just concerned about the third person who would be in our room who doesn't know me yet and whether it would make them feel uncomfortable. In the end, that was no trouble at all. I felt so empowered and more accepted than ever in this community. And when finally being on-site there another thing happened with me. I started to use the women's restroom. Up to now I usually had the feeling of "it's fine for me to use the male one, and I don't want other women to feel uncomfortable", but somehow, with a skirt on, it in the end made me feeling uncomfortable. Additionally, there were only three times in total when I used the male toilet (and one was on the boat for the daytrip), and every single time of it I felt extremely uncomfortable with it, like others might think I'm just faking it. It at least in my mind doesn't help with accepting me as female when I go to the male restroom. And it's not a Good choice! as a woman did put it during the conference dinner when there was a longer queue infront of the male restroom. It's not so much of a choice over here. But I give her the doubt of not knowing how important these little steps became to me over time. Totally unrelated to the restroom question but interestingly featuring it a fair bit I was made aware of the Assigned Male cartoon. I instantly fell in love with it, and in case you want to enlighten yourself a bit more about how some things you might say or do get received by trans people, be very much invited to read it. Sophie is currently on European tour with her book, unfortunately Vienna/Austria doesn't seem to be part of europe in that respect so I hope someone will be able to visit one of her stations to pick up a book for me ... And then there was also a small inofficial Nail Polish BoF going on at DebConf. I left it on my fingers for the next two weeks, totally in love with it. Unfortunately the nail polish I got for myself after DebConf had a rather big brush so I wasn't able to work on it, I failed miserably. ... which brings me to the empowerment that DebConf meant for me this year, and the time since. Given that I left the nail polish on I even took the comfort in being myself to go to work in my skirt on a more regular basis. Also, a very nice friend did visit me and we went lipstick shopping. I loved the color she chose, even though in the meantime it isn't visible enough for me and I guess I'll get another one rather sooner than later. Also, about what I mentioned in my last blog post was that my name change within the Debian project was granted. A quick update on that is that also now my GPG key got replaced. I guess it's finally time for me to write a gpg transition statement, even though I don't follow those myself. I still prefer meeting up with people face-to-face for signing their new keys. But given that it's called a transition statement makes it more appealing to me on that grounds. :) And I got invited to a local podcast show. Actually I know the person who does the podcast since several years already, he's also part of the local free software community who attends various events, and he does a podcast since several years now called Biertaucher (named after cooling the beer in a fountain). It is held in German language, so if you don't understand German you might want to skip these links.
In the first episode that I joined in I talked about DebConf. Afterwards we were sitting together and talking about that they would like to have more social topics too, not just technical things. So we took that chance and talked in Biertaucher #221 about Polyamory, which was a quite interesting experience. The host intentionally asked questions coming from a quite ignorant point of view, but it went nice. We were three poly people sharing our views and insight how it works for us.
Then there was Biertaucher #223 where it was just me and one of the hosts. We didn't had much to talk about from the past week, so we agreed to talk about Transgender in the end. Granted, it's mostly my personal story, but I guess I got some important topics addressed in a useful way. And, after getting my name changed in Debian, I thought about what it might take to get my name changed officially, too (as if it could get more official than using it throughout my work environment, both payed and voluntary, but ...). I covered that in the podcast, but mostly it is either quite expensive or requires me to change my gender in the register of births, which require a lot of other hassles that include psychiatry. Or, settle for a so-called "gender neutral" name as first name, which both doesn't sound very convincing somehow ... Only time can tell I guess. Guess that's enough for now, if I forgot something I might come back to it. :) One last note: I consider the Debian project a very welcoming one, and that can only work for a fair amount of people if the tone is right. So yes, I wholeheartly agree with the Code of Conduct. And I'm very disappointed to see that there are still people in the project that are advocating for a freedom of expression, so to say. Respectful communication with each other is a must in a bigger community to make it work, not something that might be a nice to have, and calling someone names and ridiculing them for stating that is absolutely not acceptable. I encourage those people to watch How to Throughly Offend and Insult People in Open Source presentation (or at least read the slides) that Gina Likins gave earlier this year. It might give them an idea why it's important to communicate respectful with each other, and that includes banning degrading terms like "SJW" from your vocabulary because it actually speaks a lot more about your own attitude than about the one of the person you use it for.

/personal permanent link Comments: 8 Flattr this

Now that the tsunami that followed my recent blog post has passed, I can read through all the nice comments and blogs of other people. I didn t expect that just writing up some links to posts on LKML, plus adding my personal opinion on what has happened and about my interpretation concerning Debian could gather so much attention. Anyway, let us look at the blog posts written in the aftermath. In particular do I want to answer to two blogs: Lars Wirzenius blog and Mart n Ferrari s blog, both of which are excellent examples of insults. I also want to mention that although the previous two are bad examples, there are fortunately also those who are able to resist primitive insults, in particular Gunnar Wolf (direct link to the blog does not work), and Miriam Ruiz blog, which contradict my blog and propose a different view, without pulling the knife. Lars Wirzenius Let us start with Lars (ah sorry, I have to call him Wirzenius here, strange custom has suddenly popped up in Debian!):

I think Preining mis-characterises what happens on the Linux kernel mailing list, and in Debian, in free software development in general, and what Sarah Sharp has said and done. I continue to think he is wrong about everything on this topic.

I am very surprised that Lars^WWirzenius is in possession of a crystal ball that allows him to see and evaluate my attitude towards all these items, considering that I have presented links to posts on the LKML, and yes, my interpretation of the matter. Mind that the whole text amounts to about 130 lines on my screen, while my personal opinion was stated in two paragraphs of total 9 lines plus some interspersed comments. And in these maybe 20 lines I didn t make general statements about open source, kernel development etc etc. Lars, I know you have closed your blog for comments so I couldn t ask you but please, can you send me one of your crystal balls if you have more of them? At least he has managed to keep a bit of proper writing and disagreed with my statement on Debian (whether there is fun or not in Debian). He is of course free to do that, but please, don t rob me the right to state that I think Debian has changed. All this dispute centers around people not being capable to distinguish two things: One, being against the Code of Conduct due to the inclusion of administrative actions without clear definitions, and Two, being pro offensive behavior and and insults. Now, dear Lars^WWirzenius, please listen: I never advocated abusive behavior or insults, nor do I defend it. (Did you hear that!) I simply opposed the Code of Conduct as ruling instrument. And what kind of emails I got due to my opposition was far outside the Code of Conduct you are so strongly defending. So please, stay at the facts, and stop insulting me. Thanks. Mart n Ferrari Concerning Mart n I don t have much to say but please, stop spreading lies. You stated:

Once again, he s complaining about how the fun from Debian has been lost because making sexist jokes, or treating other people like shit is not allowed any more.

Could you please come up with a reference to this? Or are you just interpreting? I am very disappointed about this level of discussion between Debian Developers. You not even cared to answer my comment on your blog. Should I say something clear here you should be happy that this has not been written on a Debian mailing list, otherwise I hope the Code of Conduct hammer would hit you.

---

So yes, it seems that at least these two blogs underline exactly what my opinion is: Communication culture in Debian has changed to be more company-like. Probably due to the ever increasing amount of developers that are paid for their work on Debian (Ubuntu), the pressure to follow US company codes has taken a firm grip, so firm that even stating my diverging opinion is already enough to get branded. Good Future!

What happened in the reproducible builds effort this week: Toolchain fixes

• Niels Thykier uploaded debhelper/9.20151004 which exports SOURCE_DATE_EPOCH when running dh_auto_* (patch by Dhole). dh now also calls dh_strip_nondeterminism during build (patch by Andrew Ayer). The only remaining change regarding reproducibility in the custom debhelper is related to mtimes in data.tar which might be fixed directly in dpkg instead.
• Niels Thykier made another upload of debhelper/9.20151005 the next day to sort Build IDs added by dh_strip in control files.

Scott Kitterman fixed an issue with non-deterministic Depends generated by dh-python identified by Santiago Vila and Chris Lamb. Lunar updated the patch against dpkg which makes the order of files in control.tar.gz deterministic using the new --sort=name option available in GNU Tar 1.28. josch released sbuild version 0.66.0-1 with several fixes and improvements. The most notable one for reproducible builds is the new --build-path option and $build_path configuration variable added by akira which allows to explicitly chose a given build path. Reiner Herrmann wrote a new patch for dh-systemd to sort the list of unit files in the generated maintainer scripts. Packages fixed The following packages became reproducible due to changes in their build dependencies: aoeui, apron, camlmix, cudf, findlib, glpk-java, hawtjni, haxe, java-atk-wrapper, llvm-py, misery, mtasc, ocamldsort, optcomp, spamoracle. The following packages became reproducible after getting fixed:

• classified-ads/0.08-1 uploaded by Antti J rvinen, fix merged upstream, original patch by Reiner Herrmann.
• criu/1.7-3 uploaded by Salvatore Bonaccorso, original patch by Chris Lamb.
• doomsday/1.15.4-1 by Michael Gilbert.
• ejabberd/15.07-1~exp1 by Philipp Huebner.
• libxbean-java/4.4-1 by Emmanuel Bourg.
• markdown/1.0.1-8 uploaded by Matt Kraai, original patches by Chris Lamb (#776925) and akira (#793701).
• nedit/1:5.6a-3 by Paul Gevers.
• nvidia-settings/340.93-1 uploaded by Andreas Beckmann, original patch by Lunar.
• ocaml/4.02.3-2 by St phane Glondu.
• polygen/1.0.6.ds2-14 uploaded by Mehdi Dogguy, original patch by Chris Lamb.
• stsci.distutils/0.3.7-4 by Aurelien Jarno.
• vdr/2.2.0-4 by Tobias Grimm.
• vdr-plugin-xineliboutput/1.1.0+cvs20150907-3 by Tobias Grimm.
• w3c-markup-validator/1.3+dfsg-3 by Santiago Vila.
• xcolorsel/1.1a-19 by Santiago Vila.
• xmoto/0.5.11+dfsg-3 by Stephen Kitt.

Some uploads fixed some reproducibility issues but not all of them:

• ognl/2.7.3-6 by Emmanuel Bourg.
• enblend-enfuse/4.1.4+dfsg-2 by Andreas Metzler.

Untested

• nvidia-xconfig/340.93-1 by Andreas Beckmann.
• nvidia-settings-legacy-304xx/304.128-1 by Andreas Beckmann.

Patches submitted which have not made their way to the archive yet:

• #801212 on unicode-data by Esa Peuha: set TZ=UTC when calling unzip.

reproducible.debian.net ProfitBricks once again increased their support for reproducible builds in Debian and in other free software projects by adding 58 new cores and 138 GiB of RAM to the already existing setup. Two new amd64 build nodes and 16 new amd64 build jobs have been added which doubles the build capacity per day and allows us to spot many kind of problems earlier. The size of the tmpfs where builds are performed has also been increased from 70 to 200 GiB on all amd64 build nodes. Huge thanks! When examining a package, a link now points to a table listing all previous recorded tests for the same package. (Mattia) The menu on the package pages has also been improved. (h01ger) Packages in the depwait state are now rescheduled automatically after five days. (h01ger) Links to documentation and other projects being tested have been made more visible on the landing page. (h01ger) To reduce noise on the team IRC channel five different types of notifications have been turned into mail notifications. The remaining ones have been shortened and the status changes have been limited to unstable and experimental. (h01ger) Maintainer notifications about status changes in a package will only be sent out once per day, and not on each status change. (h01ger) diffoscope development Some more experiments of concurrent processing have been made. None were good and reliable enough to be shared, though. Package reviews 48 reviews have been removed, 189 added and 23 updated this week. 9 FTBFS bugs were reported by Chris Lamb. Misc. h01ger met with Levente Polyak to discuss testing Arch Linux on Debian continuous test system with an easily extensible framework. The idea is to also allow testing of other distributions, and provide a nice package based view like the one for Debian.

We got pretty good feedback on Gnocchi so far, even if we only had little. Recently, in order to have a better feeling of where we were at, we wanted to know how fast (or slow) Gnocchi was. The early benchmarks that some of the Mirantis engineers ran last year showed pretty good signs. But a year later, it was time to get real numbers and have a good understanding of Gnocchi capacity. Benchmark tools The first thing I realized when starting that process, is that we were lacking of tools to run benchmarks. Therefore I started to write some benchmark tools in python-gnocchiclient, which provides a command line tool to interrogate Gnocchi. I added a few basic commands to measure metric performance, such as:
The command line tool supports the --verbose switch to have detailed progress report on the benchmark progression. So far it supports metric operations only, but that's the most interesting part of Gnocchi. Spinning up some hardware I got a couple of bare metal servers to test Gnocchi on. I dedicated the first one to Gnocchi, and used the second one as the benchmark client, plugged on the same network. Each server is made of 2 Intel Xeon E5-2609 v3 (12 cores in total) and 32 GB of RAM. That provides a lot of CPU to handle requests in parallel. Then I simply performed a basic RHEL 7 installation and ran devstack to spin up an installation of Gnocchi based on the master branch, disabling all of the others OpenStack components. I then tweaked the Apache httpd configuration to use the worker MPM and increased the maximum number of clients that can sent request simultaneously. I configured Gnocchi to use the PostsgreSQL indexer, as it's the recommended one, and the file storage driver, based on Carbonara (Gnocchi own storage engine). That means files were stored locally rather than in Ceph or Swift. Using the file driver is less scalable (you have to run on only one node or uses a technology like NFS to share the files), but it was good enough for this benchmark and to have some numbers and profiling the beast. The OpenStack Keystone authentication middleware was not enabled in this setup, as it would add some delay validating the authentication token. Metric CRUD operations Metric creation is pretty fast. I managed to attain 1500 metric/s created pretty easily. Deletion is now asynchronous, which means it's faster than in Gnocchi 1.2, but it's still slower than creation: 300 metric/s can be deleted. That does not sound like a huge issue since metric deletion is actually barely used in production. Retrieving metric information is also pretty fast and goes up to 800 metric/s. It'd be easy to achieve very higher throughput for this one, as it'd be easy to cache, but we didn't feel the need to implement it so far. Another important thing is that all of these numbers are constant and barely depends on the number of the metric already managed by Gnocchi.

Operation	Details	Rate
Create metric	Created 100k metrics in 77 seconds	1300 metric/s
Delete metric	Deleted 100k metrics in 190 seconds	524 metric/s
Show metric	Show a metric 100k times in 149 seconds	670 metric/s

Sending and getting measures Pushing measures into metrics is one of the hottest topic. Starting with Gnocchi 1.1, the measures pushed are treated asynchronously, which makes it much faster to push new measures. Getting new numbers on that feature was pretty interesting. The number of metric per second you can push depends on the batch size, meaning the number of actual measurements you send per call. The naive approach is to push 1 measure per call, and in that case, Gnocchi is able to handle around 600 measures/s. With a batch containing 100 measures, the number of calls per second goes down to 450, but since you push 100 measures each time, that means 45k measures per second pushed into Gnocchi! I've pushed the test further, inspired by the recent blog post of InfluxDB claiming to achieve 300k points per second with their new engine. I ran the same benchmark on the hardware I had, which is roughly two times smaller than the one they used. I achieved to push Gnocchi to a little more than 120k measurement per second. If I had same hardware as they used, I could interpolate the results to achieve almost 250k measures/s pushed. Obviously, you can't strictly compare Gnocchi and InfluxDB since they are not doing exactly the same thing, but it still looks way better than what I expected. Using smaller batch sizes of 1k or 2k improve the throughput further to around 125k measures/s.

Operation	Details	Rate
Push metric 5k	Push 5M measures with batch of 5k measures in 40 seconds	122k measures/s
Push metric 4k	Push 5M measures with batch of 4k measures in 40 seconds	125k measures/s
Push metric 3k	Push 5M measures with batch of 3k measures in 40 seconds	123k measures/s
Push metric 2k	Push 5M measures with batch of 2k measures in 41 seconds	121k measures/s
Push metric 1k	Push 5M measures with batch of 1k measures in 44 seconds	113k measures/s
Push metric 500	Push 5M measures with batch of 500 measures in 51 seconds	98k measures/s
Push metric 100	Push 5M measures with batch of 100 measures in 112 seconds	45k measures/s
Push metric 10	Push 5M measures with batch of 10 measures in 852 seconds	6k measures/s
Push metric 1	Push 500k measures with batch of 1 measure in 800 seconds	624 measures/s
Get measures	Push 43k measures of 1 metric	260k measures/s

What about getting measures? Well, it's actually pretty fast too. Retrieving a metric with 1 month of data with 1 minute interval (that's 43k points) takes less than 2 second. Though it's actually slower than what I expected. The reason seems to be that the JSON is 2 MB big and encoding it takes a lot of time for Python. I'll investigate that. Another point I discovered, is that by default Gnocchi returns all the datapoints for each granularities available for the asked period, which might double the size of the returned data for nothing if you don't need it. It'll be easy to add an option to the API to only retrieve what you need though! Once benchmarked, that meant I was able to retrieve 6 metric/s per second, which translates to around 260k measures/s. Metricd speed New measures that are pushed into Gnocchi are processed asynchronously by the gnocchi-metricd daemon. When doing the benchmarks above, I ran into a very interesting issue: sending 10k measures on a metric would make gnocchi-metricd uses up to 2 GB RAM and 120 % CPU for more than 10 minutes. After further investigation, I found that the naive approach we used to resample datapoints in Carbonara using Pandas was causing that. I reported a bug on Pandas and the upstream author was kind enough to provide a nice workaround, that I sent as a pull request to Pandas documentation. I wrote a fix for Gnocchi based on that, and started using it. Computing the standard aggregation methods set (std, count, 95pct, min, max, sum, median, mean) for 10k batches of 1 measure (worst case scenario) for one metric with 10k measures now takes only 20 seconds and uses 100 MB of RAM 45 faster. That means that in normal operations, where only a few new measures are processed, the operation of updating a metric only takes a few milliseconds. Awesome! Comparison with Ceilometer For comparison sake, I've quickly run some read operations benchmark in Ceilometer. I've fed it with one month of samples for 100 instances polled every minute. That represents roughly 4.3M samples injected, and that took a while almost 1 hour whereas it would have taken less than a minute in Gnocchi. Then I tried to retrieve some statistics in the same way that we provide them in Gnocchi, which mean aggregating them over a period of 60 seconds over a month.

Operation	Details	Rate
Read metric SQL	Read measures for 1 metric	2min 58s
Read metric MongoDB	Read measures for 1 metric	28s
Read metric Gnocchi	Read measures for 1 metric	2s

Obviously, Ceilometer is very slow. It has to look into 4M of samples to compute and return the result, which takes a lot of time. Whereas Gnocchi just has to fetch a file and pass it over. That also means that the more samples you have (so the more time you collect data and the more resources you have), slower Ceilometer will become. This is not a problem with Gnocchi, as I emphasized when I started designing it. Most Gnocchi operations are O(log R) where R is the number of metrics or resources, whereas most Ceilometer operations are O(log S) where S is the number of samples (measures). Since is R millions of time smaller than S, Gnocchi gets to be much faster. And what's even more interesting, is that Gnocchi is entirely scalable horizontally. Adding more Gnocchi servers (for the API and its background processing worker metricd) will multiply Gnocchi performances by the number of servers added. Improvements There are several things to improve in Gnocchi, such as splitting Carbonara archives to make them more efficient, especially from drivers such as Ceph and Swift. It's already on my plate, and I'm looking forwarding to working on that! And if you have any questions, feel free to shoot them in the comment section.

On the recently reviewed album International Sad Hits Vol 1 I wrote that Kim Doo Soo was the great surprise of the CD for me. So I went ahead and bought (not that easy, import from US!) one of his most recommended album, the Free Spirit. Sad songs, full of melancholy, speaking of desperation, isolation, destroyed love. The music and singing is simple, mainly based on guitar and voice only, at times harmonica, strings and others are added. In contrast to the Crying Philosopher Tomokawa Kazuki, the songs are all very melodic and easy to listen, but still carrying a strong impact. After listening to these songs, the melodies wander around my brain resonating again and again, like (mis)guiding lights in a dark forest. All the songs are in Korean, but fortunately the accompanying booklet carries a Japanese translation for the Korean incapables like me. In the future I will provide some translations into English, since I believe that this artist should be more known outside this small area. While a friend of mine said I don t like (bimbokusai) music, I have to say I enjoy reading through the sad stories while listening to this special music.

This is the 2002 fourth album by Korea s true cult folk/singer-songwriter hero, Kim Doo Soo. Kim Doo Soo is perhaps the deepest and most introspective of Korea s acid folk singers. Legends surround his songs political oppression, alcoholism, suicide, a 10-year period of mountain seclusion. [ ] On Free Spirit he mines productive veins of profound melancholy, animistic nature, and unfathomable, hermetic affection. These songs are couched in a veil of gorgeous, still melodicism, Kim s quavering vocals and guitar shaded with subtle accordion, cello, organ and harmonica. A reflective and unearthly masterpiece.
Forced Exposure

To this I cannot add anything more eloquent! The songs on this CD are as follows, the English translation is taken from Kim Doo Soo s official web page.

1. (Wild flower)
2. (Boat for the shore)
3. (Butterfly)
4. (Sweetbrier)
5. (Bohemian)
6. (Dawn rain)
7. 19 Blues (Blues of 19th street)
8. (Mountain)
9. (As time goes by)
10. Romantic Horizon
11. ( ) (Reminiscence)
12. (Evening river)
13. ( ) (Bohemian poetry)
14. , (Dandelion, dandelion)

My favorites under these songs are Boat for the shore ( You aren t coming any more onto a wild sea I am leaving ), Bohemian ( I m going to the shores of emptiness, my free spirit flows down the river probably his most famous song, assumed to be responsible for his retreat to the mountains), Dawn rain (A lovely song, and the only one without Japanese translation! Very strange.), Mountain ( Mountains Mountains my dream, mountains ). But I can recommend each and every song on this CD. To close this short review, if you are interested in something else but the usual happy-pappy KPop or JPop or USPop, and are searching for inspiring and songs with Tiefgang (deep meaning, as we say it in German), give this special artist a try! Some links concerning Kim Doo Soo that might be useful:

• Official Web site
• Kim Doo Soo Live Information for Japan
• A review of Kim Doo Soo s Bohemian at KPopStarz
• Kim Doo Soo at Psychedelic Folk with short reviews of his albums
• (in Russian) Biography of Kim Doo Soo on svyazalamuzyka

One of the greatest pleasures of walking and hiking is to appreciate all of the many living things encountered along the way. A big part of that appreciation for me is to be able to identify individual species and learn the relationships among them. To that end, I would like to introduce a flashcard deck I created, based on the glossary of the excellent, and also free, Nova Scotia Plants, by Marian C. Munro, Ruth E. Newell, and Nicholas M. Hill, so that I could more effectively use the book as an amateur student of our local flora.

• Download the book.
• Download my Nova Scotia Plants glossary flashcard deck for Anki.
• Install Anki for your platform and register at ankiweb.net.
• Import the apkg deck file in Anki.
• Enjoy studying the plants of Nova Scotia with these resources.
• Comments are welcome here, and a review on ankiweb.net would be appreciated.

Creating the Nova Scotia Plants glossary for Anki I authored the deck on Debian, using the free software utility pdftotext (from poppler-utils), the small shell script below to produce a rough draft, and a text editor to clean up any errors, inconsistencies, and artefacts caused by the conversion process, such as descriptions which wrapped to a second line.

#!/bin/sh
pdftotext -f 40 -l 55 \
  'Print Nova Scotia Plants complete manuscript.pdf' \
  glossary_raw.txt
egrep -v '^[ixvl]+$' glossary_raw.txt   \
  grep -P '^\f?[ a-z]+'   \
  sed -re 's/^\f?([^ ]+)( [- ]+ ? [- ]+ )( ?(.+))/\1\t\4/' \
  > glossary_import.txt

Nova Scotia Plants The Anki flashcard deck is intended as a companion for studying Nova Scotia Plants, linked above, and available either as a single PDF file, or multiple, smaller PDFs per section or family. This ebook has been a constant companion to me on my tablet during my walks and to study in quiet moments of the day. It has enriched my enjoyment of nature in Nova Scotia immeasurably. I am indebted to the authors for the years of work they put into it, and for making it available to the public for free. I hope you get as much out of it as I have. Anki for devices One of the criteria I used in selecting Anki as my flashcard software is that it is available for Debian, but also should work on my devices. I use the free software, AnkiDroid, on my Android phone and tablet, available both in F-Droid and the Google Play store. I understand there is also AnkiMobile for iOS, but that is not free. Feedback Please take the time to give me feedback. I spent an afternoon and a morning putting these materials together to share, and am eager to hear if my work has benefited you. Let me know if you have any suggestions for improvements, and don t forget to leave a review at ankiweb.net.