Today, I have released the first beta for Tails 3.0, that will be the first version of Tails based on Debian 9 (Stretch). Our automated test suite pretends it works pretty well and matches our safety expectations. I'm inclined to trust it. But as we learned after porting Tails to Squeeze, Wheezy and Jessie: quick, exploratory testing of pre-releases will not identify all the remaining regressions. So this time I'm trying to change this narrative a bit. I have committed to provide security updates for the 3.0~ series, just like we do for stable versions of Tails. This was the only missing bit to make me feel comfortable asking my fellow Tails contributors to upgrade to Tails 3.0~beta1 for their daily usage. I hope this helps us release a great Tails 3.0 on June 13 and a better Debian Stretch too: the more early users of Tails based on Stretch, the more chances they identify a few annoying regressions in Stretch before it's called stable :) For details, see the official announcement. Next step: FOSDEM. And then, back to organizing an event that aims at improving both social and technical aspects of Debian (to be announced in about a week, stay tuned); because the way we get organized and how power is distributed matter.

It's that time of the year :-) And FOSDEM is fun. But this year I won't be going; there was a scheduling conflict, and I didn't really have anything new to present (although I probably could have shifted around priorities to get something). But FOSDEM 2017 also means there's a year since FOSDEM 2016, where I presented Nageru, my live video mixer. And that's been a pretty busy year, so I thought I'd do a live cap from high up above. First of all, Nageru has actually been used in production we did Solskogen and Fyrrom, and both gave invaluable input. Then there have been some non-public events, which have also been useful. The Nageru that's in git right now is evolved considerably from the 1.0.0 that was released last year. diffstat shows 19660 insertions and 3543 deletions; that's counting about 2500 lines of vendored headers, though. Even though I like deleting code much more than adding it, the doubling (from ~10k to ~20k lines) represents a significant amount of new features: 1.1.x added support for non-Intel GPUs. 1.2.x added support for DeckLink input cards (through Blackmagic's proprietary drivers), greatly increasing hardware support, and did a bunch of small UI changes. 1.3.x added x264 support that's strong enough that Nageru has really displaced VLC as my go-to tool for just video-signal-to-H.264-conversion (even though it feels overkill), and also added hotplug support. 1.4.x added multichannel audio support including support for MIDI controllers, and also a disk space indicator (because when you run out of disk during production without understanding that's what happens, it really sucks), and brought extensive end-user documentation. And 1.5.x, in development right now, will add HDMI/SDI output, which, like all the previous changes, requires various rearchitecting and fixing. Of course, there are lots of things that haven't changed as well; the basic UI remains the same, including the way the theme (governing the look-and-feel of the finished video stream) works. The basic design has proved sound, and I don't think I would change a lot if I were to design something like 1.0.0 again. As a small free software project, you have to pick your battles, and I'm certainly glad I didn't start out doing something like network support (or a distributed architecture in general, really). So what's for the next year of Nageru? It's hard to say, and it will definitely depend on the concrete needs of events. A hot candidate (since I might happen to need it) is chroma keying, although good keying is hard to get right and this needs some research. There's also been some discussion around other concrete features, but I won't name them until a firm commitment has been made; priorities can shift around, and it's important to stay flexible. So, enjoy FOSDEM! Perhaps I'll return with a talk in 2018. In the meantime, I'll preparing the stream for the 2017 edition of Fyrrom, and I know for sure there will be more events, more features and more experiences to be had. And, inevitably, more bugs. :-)

While the main focus of QSoas is the processing of experimental data, it also features commands to generate (calculate) datasets. The command generate-buffer creates a dataset of equally spaced points (you can change their number using the option /samples) between to limiting values, as below:

QSoas> generate-buffer -2 2

By default, the values are taken equal to . However, generate-buffer also takes an optional formula to directly set the values:

QSoas> generate-buffer -10 10 sin(x)

From version 2.0, it is possible to generate several datasets in a row using the /number option, and to color them using the /style option (but only since version 2.1). Each dataset is generated according to the formula, and number is a special number that starts at 0 and increases by 1 for each dataset. Here's what I used to generate the picture on the right:

QSoas> generate-buffer -2 2 sin(PI*x)**(number+1) /number=30 /style=red-to-blue

About QSoasQSoas is an open source data analysis program that focuses on flexibility and powerful fitting capacities. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052.

I was reading a thread on phoronix where a student was sharing that it is or can be expensive to get even a used laptop and he shared his predicament and was hammered a bit for it to some going to the extent of questioning his life-choices. While I m not a student it still triggered something in me. I am not dirt poor but neither am I insanely rich. The same questions he has, similar questions I have had. While in his case he is probably in his early to late 20 s, I am pushing 40. Most of the money I make goes in for everyday purchases, veggies, house-rent, electricity, landline, broadband and cell phone bills. What little is left is most of the time kept for a rainy day as there is no Government pension. From what I have heard and read on the web, in the west specifically in the States, if I buy a used laptop, I usually get a 6 months 1 year warranty . Here, while you could get a used laptop for around INR 10k there is no warranty/guarantee, so I never get into that. It s buyer s beware all the time. For people who like/want FOSS or specifically something like Free DOS (like me), I had to wait for almost 6 years to get a model I was happy with, with the specs. I was ok with. Was really lucky enough to get a Thinkpad T440 with 8 GB of RAM for around INR 80k/- with Free DOS. The specs T440 Core I 5 (4300) / Dos (NEW MODEL) 20B7A1SD00 Intel Core i5 4300M (2.5 GHz / 3 MB / 5 GT/s) / Intel QM87 Chipset / Integrated 802.11 n WIFI LAN + Bluetooth 4.0 / 8GB DDR III Memory (2 DIMM SLOT) / 500 GB SATA HDD @ 7200 RPM / 14.0 HDy / FPR / Dos / 2 USB , VGA Port , RJ 45 Port /GB LAN /Track Point with 5 button Glass Touch Pad /Stereo Speakers with Dolby Enhanced Audio / 6 Cell Battery /Approx 2.14KG/ While it is/was actually pretty expensive but then wanted something which can take a beating, deal with all the heat, noise and dust (specifically where I live, right in the middle of the city). The reason I used the word lucky is that now there is no model in the T-series range which has FreeDOS on it. Of course, I hopefully will use it for another 4-5 years at the very least depending on how much it cooperates with me, I have heard that Thinkpads function for a long period of time even in dusty environments so banking on that. What probably pissed me is the condensing note in the comment, how does he know what pressures an another individual might be in. It s almost like saying You are refugee because you made a wrong life choice or something to that effect which again is stupid. I actually feel/felt embarrassed to bring this up as I truly am lucky to be safe, secure, have food on the table, am able to sleep on a bed at night, have a workstation AND a laptop, have somewhat of a sound mind and a body which is able to move around without any hassles. Add to that, incredibly as it may sound, was also able to see another country for a few days In relation to people being persecuted and having to run off to save their own lives or even people living on the streets, I am actually living in luxury. While I can t go through life feeling guilty for all the good things that have happened with me, I do feel disgusted when I see some people put blinding statements like that. One of the biggest reasons that GNU/Linux and Debian in particular gelled with me was that it s incredibly flexible and generous. Nobody tells me which packages I should or shouldn t have. I do right things, good, I do something wrong, an opportunity to learn and hopefully learn from my mistakes. In either case, one of the most forgiving kind of system to learn and hack on. While speaking of mistakes, could somebody look at #849684 . It almost feels like a tennis match going between the maintainers concerned. While I don t have the technical skills to ascertain who s right and who is not, it would be nice if some cooler heads can make sense and see if a way could be found out. Can somebody help ?
Filed under: Miscellenous Tagged: #debian, #Life Choices, #Thinkpad440, laptop

Debian LTS November marked the 21st month I contributed to Debian LTS under the Freexian umbrella. I had 8 hours allocated which I used for:

• the first half of a LTS front desk week
• updating icedove 45.6.0 resulting in DLA-782-1 fixing 8 CVEs
• releasing DLA-783-1 for XEN, the actual update was provided by credativ
• testing the bind9 update prepared by Thorsten Alteholz
• fixing 8 CVEs in imagemagick resulting in DLA-807-1.
• work on recent qemu CVEs

Other Debian stuff

• Usual bunch of libvirt and related uploads
• Uploaded git-buildpackage 0.8.10 to 0.8.12.1 to experimental and unstable fixing (among other things) a long standing bug when using multiple tarballs with filters and pristine-tar as well as making generated orig tarballs reproducible so one gets identical tarballs even without pristine-tar.
• Ran a gbp import-dsc of unstable and filed bugs for cases where pristine-tar would not import the package. Started to look into git-apply errors.

Some other Free Software activites

• libplanfahr: switched the example to python3 and made it parse arguments without date as "today":

  $ ./run python examples/trip-query.py --when=21:00 Essen Gelsenkirchen
  Loaded provider de_db
  Start: Essen Hbf
  End: Gelsenkirchen Hbf
  Trip #1
         Start:     Essen Hbf
         Departure: 2017-02-02 21:18
         Delay:     0
         End:       Gelsenkirchen Hbf
         Arrival:   2017-02-02 21:26
         Delay:     0
         Switches:  0
  Trip #2
         Start:     Essen Hbf
         Departure: 2017-02-02 21:22
         Delay:     0
         End:       Gelsenkirchen Hbf
         Arrival:   2017-02-02 21:33
         Delay:     0
         Switches:  0
  Trip #3
         Start:     Essen Hbf
         Departure: 2017-02-02 21:44
         Delay:     0
         End:       Gelsenkirchen Hbf
         Arrival:   2017-02-02 21:52
         Delay:     0
         Switches:  0
  

• Proposed a workaround to rbvmomi to massively speedup cloning under certain conditions when using CachedOVFDeployer
• Proposed a fix to unbreak ansible's zypper module on first installations
• Made ausroller use git-buildpackage from pypi on non Debian based distros
• Made further progess on the Merkur board clones

Working with Date, Calendar, SimpleDateFormat in Android. As I mentioned In my last blog, I would talk about how I used Calendar and Date classes for the user to designate silent mode by setting time constraints and weekdays, in Lumicall. Date class to used to interpret dates as year, month, day, hour, minute, and second values. I had to compare whether the current time falls between Start Time and End Time specified by the user. So that, silent mode can be enabled within that time frame. I used Calendar Class to get the current hour in 24-Hour format and minute.

 Calendar now = Calendar.getInstance();
 int hour = now.get(Calendar.HOUR_OF_DAY);  
 int minute = now.get(Calendar.MINUTE);

Now, Since the user enters the Time in EditText Widgets, the values were retrieved as strings.
String hhStart, mmStart, hhEnd, mmEnd store these values from Edit text widgets.
To interpret these strings as a representation of a date and time, we need to parse it A Date class object s format looks like-

Since, I was only interested in fetching the HH:MM values, i.e the fourth field in the format, To set and compare only the HH:MM values, Android provides lovely, SimpleDateFormat class to access the particular value we want in the Date object.
To access the year, use letter Y
To access the time zone, use letter z
To access the Hour and minute, we use letter H and m.

SimpleDateFormat simpleDateFormat= new SimpleDateFormat( HH:mm , Locale.ENGLISH);
Date currentTime = parseDate(hour + ":" + minute)
Date timeCompareOne = parseDate(hhStart + : +mmStart);  
Date timeCompareTwo = parseDate(hhEnd + : +mmEnd);

Rest everything in the date object are values set by default. Eg, Year 1970. Which we din t set / access , hence did not change. To check if the start time is before the current time. And the endtime is after the current time,

if(timeCompareOne.before(currentTime) && timeCompareTwo.after(currentTime))
 
Switch on the silent mode;
 

Added a try catch block to handle the exception which will arise if the SimpleDateFormat.parse method is unable to parse the given Java String.

public Date parseDate(String date)  
  
try 
   
return inputParser.parse(date);
  
catch (java.text.ParseException e)  
   
return new Date(0);  
   
 

Comparing Time? Done!
Now to check whether the selected weekday in the checkboxes matches the current week day,

Calendar calendar = Calendar.getInstance(); 
int day = calendar.get(Calendar.DAY_OF_WEEK); 

If it s sunday, value returned by calendar.get(Calendar.DAY_OF_WEEK) is 1, if monday, 2 and so on..
Weekdays compared too! Thanks for reading,
U

The past few days I've been doing more arduino-work. In between dying of sleep-exhaustion. One thing that always annoyed me was that I had to hard-code my WiFi credentials in my projects, with code like this:

//
// Connect to the SCOTLAND network
//
WiFi.mode(WIFI_STA);
WiFi.hostname("tram-clock");
WiFi.begin("SCOTLAND", "highlander1");
//
// Attempt to connect - TODO: Timeout on failure
//
while (WiFi.status() != WL_CONNECTED)
    delay(500);
//
// Now we're connected show the local IP address.
//
lcd.print("WiFi connected  ");
lcd.print(WiFi.localIP());

Whilst looking at another project I found a great solution though. There is a library called WiFiManager which behaves perfectly:

• If you've stored connection details it will connect to the local WiFI network using those, automatically.
• If you've not saved previous connection details it will instead configure the device to work as an Access Point
  • You can then connect to that access point and see a list of local WiFi networks.
  • Choose the appropriate one from the list, enter your password, and these details are saved for the future.
  • The device will then reset, join the network via your saved choices and acquire an IP via DHCP as you'd expect.

The code for this is beautifully simple:

//
// Connect to WiFI with saved credentials, if any.
//
// Otherwise work as an access-point, named TRAM-TIMES, and
// let the user fill out their details.
//
WiFiManager wifiManager;
wifiManager.autoConnect("TRAM-TIMES");

This means my current project, which continues to revolve around tram-times, is so very much more user-friendly. It is a product you could package and take to a friends house, not a project you have to recompile to tweak. For that reason, user-niceness, I reworked the on-board HTTP status-page to use bootstrap, be themed, and look nicer. Other than being housed in a horrid case the project actually looks like a product. Not one I'd buy, but neither one I'm ashamed of sharing.

Changes

• gitk: colour of remote refs
• https-everywhere: Update Debian rules
• check-all-the-things: release, security fix, reset terminal modes, allow running removed checkers, regression fix (quote fix), TODO items (for deep-text-corrector, sblint, decopy, Coala Bear & dangerous Python checks)
• devscripts: fix grep-excuses warning
• autorevision: build correctness, tarball reproducibility (due to gzip & AUTHORS.txt)
• whowatch: parameter correctness (for NULL, int), spelling/grammar/typos, https, remove dead links & restore terminal status on exit
• spelling dictionaries:
  • codespell: recod, undefuned, normaly, uner, buid, stength, privide, decstiption(s), revrese, lightweigh, multible, asbtraction, resulution, meatadata, seriuos, transalte, interractive, timestan, partiton, databas, claculate, patern, substiution, freee, operatation(s), ambigous, clasified, coypright, previlege, gental, bacup & detction
  • lintian: recod, undefuned, uner, buid, stength, privide, dimentional, decstiption(s), revrese, lightweigh, asbtraction, resulution, FTBS, meatadata, seriuos, transalte, interractive, timestan, partiton, databas, claculate, patern, substiution, freee, operatation(s), previlege, gental, bacup & detction
• Debian timeline: latest bug milestones
• Debian bits: FOSDEM draft fixes
• Planet Debian derivatives: add Netrunner & update BlankOn logo
• Debian buildd website: plain text logs (1 2 3)
• Debian uscan multi-redirector: add github package.json/cmake checker & remove gitorious
• Debian packages website: update manual pages patch to use https, merge patches (1 2)
• Debian website: fix security Makefiles for DLAs (for 2017, 2016, 2015, 2014), derivatives (wording/formatting fixes 1, 2), build by default), link fixes (for CD brokenness, stability, gitweb to cgit)
• Debian wiki pages: AlejandroRios, ChrootOnAndroid, CopyrightReviewTools, CrossCompiling, CrossGrading, DebianBootstrap, DebianDay, (2017), DebianEvents (Asia, oc) DebianScience, DebianWiki/Browsing, dedup.debian.net, Derivatives/Census (AstraLinux, BlankOn, Netrunner, SalentOS, SerbianLinux, Symbiosis, Template), EmbeddedCodeCopies, ExternalEntities, Fonts, fr/GraphicsCard, fr/Intel HD Graphics, FrontPage, gobby.debian.org, HP/ProLiant, Ideas, InstallingDebianOn, TurrisOmnia (1 2), InterWikiMap, josch/notes, LVM, Merchandise/BoFDebConf10, Mobile (1 2), NewArchiveSections, PaulWise/InterestingSoftware, PortTemplate, ppc64el, PressCoverage2017, PressCoverage, redmine, ReproducibleBuilds/History, Services/Debian Packages, SponsorChecklist, Sprints (2017/DebianMed2017 (1 2)), SystemBuildTools, systemd, Teams/Dpkg/FAQ, ThisWeekInDebian, WhyDebian, Year
• File Formats wiki pages: ACE, File_identification_software, File_command
• Debian package uploads: autorevision 1.20-1, check-all-the-things 2017.01.15 & openchange 1:2.2-6+deb8u1

Issues

• Security migration for check-all-the-things
• GPL violations due to embedded copies of Liberation Fonts in emscripten, freedink, gargoyle-free, gcstar, manaplus, minetest, pcs & zygrib
• Outdated embedded unicode-data copies in boost1.62 & boost1.63
• Crash in liferea
• Regression in coreutils date
• Missing conffile removal in dnssec-trigger & xtightvncviewer
• gitorious redirector usage in fgrun & spectacle
• Annoying issues in hexchat autorejoin, totem & a podcast & gdb messages
• Cosmetic issues in parcimonie menu, gitk colours & aptitude debtags
• Features in duck, apt-file, needrestart, packages.debian.org & aptitude
• An already implemented feature in needrestart

Review

• Spam: report spam in 6 Debian bugs, 132 Debian mails and one LWN comment
• Patches: point out extraneous whitespace changes in a codespell PR
• Debian packages: reviewed and sponsored fsprotect 1.0.7
• Debian wiki: RecentChanges for the month, feedback on InstallDebianWithoutLiveCD article
• Debian screenshots:
  • Approved screenshots of ngraph-gtk lightdm-gtk-greeter-settings kalgebra qtile patat toilet sagemath (2) w3c-markup-validator pentobi pentobi-kde-thumbnailer zygrib (2) sauerbraten kmail aiscm (5) codeblocks lxqt libreoffice-help-es inkscape synaptic thunar gimp midori filezilla libreoffice pluma qupzilla gnome-2048 simplescreenrecorder gerbv keepassx gcstar confclerk onionshare blockout2 subuser dosbox zsnes dosemu lmarbles klickety geda-gattrib katomic kiki-the-nano-bot freedm frogatto (2)
  • Approved removal of screenshots: seaview screenshot contained advertising, mupen64plus/mupen64plus-audio-all were weird screenshots with multiple OS windows overlaid & mkgmap was a screenshot of the OSM wiki instead of the software
  • Rejected screenshots: gccgo looked like a Thai mobile phone screenshot, python-stem was a screenshot for OPENDIME USB, seaview was downloaded from elsewhere and not an authentic screenshot & fbreader contained non-free ebook contents

Administration

• Debian: reboot 1 non-responsive VM, redirect 2 users to support channels, redirect 1 contributor to xkb upstream, redirect 1 potential contributor, redirect 1 bug reporter to mirror team, ping 7 folks about restarting processes with upgraded libs, manually restart the sectracker process due to upgraded libs, restart the package tracker process due to upgraded libs, investigate failures connecting to the XMPP service, investigate /dev/shm issue on abel.d.o, clean up after rename of the fedmsg group.
• Debian mentors: lintian/security updates & reboot
• Debian packages: deploy 2 contributions to the live server
• Debian wiki: unblacklist 1 IP address, whitelist 10 email addresses, disable 18 accounts with bouncing email, update email for 2 accounts with bouncing email, reported 1 Debian member as MIA, redirect 1 user to support channels, add 4 domains to the whitelist.
• Reproducible builds: rescheduled Debian pyxplot:amd64/unstable for themill.
• Openmoko: security updates & reboots.

Debian derivatives

• Send the annual activity ping mail.
• Happy new year messages on IRC, forward to the list.
• Note that SerbianLinux does not provide source packages.
• Expand URL shortener on SerbianLinux page.
• Invite PelicanHPC, Netrunner, DietPi, Hamara Linux (on IRC), BitKey to the census.
• Add research publications link to the census template
• Fix Symbiosis sources.list
• Enquired about SalentOS downtime
• Fixed and removed some 404 BlankOn links (blog, English homepage)
• Fixed changes to AstraLinux sources.list
• Welcome Netrunner to the census

Sponsors I renewed my support of Software Freedom Conservancy. The openchange 1:2.2-6+deb8u1 upload was sponsored by my employer. All other work was done on a volunteer basis.

Almost all traces of the snow are gone. After a very dry December, January was an awesome month. Lots of snow, even in the city, that held for (I think) three weeks very rare for Z rich. This happened because the temperature never went above -5 C, even during the day proper winter for the city! It was awesome to bike in these conditions. At first fresh snow (best! but slow), then packed snow, it never actually became dangerous ice. And then, at the end of last week, temperatures started climbing. First near zero, then 1-2 C above, then it finally started going warm (above freezing even during the night). And the snow started melting a bit, then more, and then it started raining. And it rained for three days. The worst thing, seeing snow being rained upon. Dirty grey snow, slowly melting away I don't like this picture. At least now the snow is gone, and the streets are almost dry, and we can look to either some more snow (I wish ) or spring. I'd rather take -2 C global average temperatures than +2 C. I'm not sure what -5 would mean, but compared to no winter

It is a new month, and time to publish the next chapter in Hacker Noir. This is chapter 2, titled "Development setup phase". I hope you enjoy it. Feedback via email, irc, identi.ca, twitter are welcome. Or come talk to me at FOSDEM if you're there.

I got myself a bunch of Raspberry Pi 3s a short while ago: ...the idea being that I can use those to run a few experiments on. After the experiment, I would need to be able to somehow remove the stuff that I put on them again. The most obvious way to do that is to reimage them after every experiment; but the one downside of the multi-pi cases that I've put them in is that removing the micro-SD cards from the Pis without removing them from the case, while possible, is somewhat fiddly. That, plus the fact that I cared more about price than about speed when I got the micro-SD cards makes "image all the cards of these Raspberry Pis" something I don't want to do every day. So I needed a different way to reset them to a clean state, and I decided to use ansible to get it done. It required a bit of experimentation, but eventually I came up with this:

---
- name: install package-list fact
  hosts: all
  remote_user: root
  tasks:
  - name: install libjson-perl
    apt:
      pkg: libjson-perl
      state: latest
  - name: create ansible directory
    file:
      path: /etc/ansible
      state: directory
  - name: create facts directory
    file:
      path: /etc/ansible/facts.d
      state: directory
  - name: copy fact into ansible facts directory
    copy:
      dest: /etc/ansible/facts.d/allowclean.fact
      src: allowclean.fact
      mode: 0755
- name: remove extra stuff
  hosts: pis
  remote_user: root
  tasks:
  - apt: pkg=  item   state=absent purge=yes
    with_items: "  ansible_local.allowclean.cleanable_packages  "
- name: remove package facts
  hosts: pis
  remote_user: root
  tasks:
  - file:
      path: /etc/ansible/facts.d
      state: absent
  - apt:
      pkg: libjson-perl
      state: absent
      autoremove: yes
      purge: yes

This ansible playbook has three plays. The first play installs a custom ansible fact (written in perl) that emits a json file which defines cleanable_packages as a list of packages to remove. The second uses that fact to actually remove those packages; and the third removes the fact (and the libjson-perl library we used to produce the JSON). Which means, really, that all the hard work is done inside the allowclean.fact file. That looks like this:

#!/usr/bin/perl
use strict;
use warnings;
use JSON;
open PACKAGES, "dpkg -l ";
my @packages;
my %whitelist = (
    ...
);
while(<PACKAGES>)  
    next unless /^ii\s+(\S+)/;
    my $pack = $1;
    next if(exists($whitelist $pack ));
    if($pack =~ /(.*):armhf/)  
        $pack = $1;
     
    push @packages, $1;
 
my %hash;
$hash cleanable_packages  = \@packages;
print to_json(\%hash);

Basically, we create a whitelist, and compare the output of dpkg -l against that whitelist. If a certain package is in the whitelist, then we don't add it to our "packages" list; if it isn't, we do. The whitelist is just a list of package => 1 tuples. We just need the hash keys and don't care about the data, really; I could equally well have made it package => undef, I suppose, but whatever. Creating the whitelist is not that hard. I did it by setting up one raspberry pi to the minimum that I wanted, running

dpkg -l awk '/^ii/ print "\t\""$2"\" => 1," ' > packagelist

and then adding the contents of that packagelist file in place of the ... in the above perl script. Now whenever we apply the ansible playbook above, all packages (except for those in the whitelist) are removed from the system. Doing the same for things like users and files is left as an exercise to the reader. Side note: ... is a valid perl construct. You can write it, and the compiler won't complain. You can't run it, though.

Review: A Closed and Common Orbit, by Becky Chambers

Series:	Wayfarers #2
Publisher:	Harper Voyager
Copyright:	October 2016
ISBN:	0-06-256942-2
Format:	Kindle
Pages:	384

A Closed and Common Orbit has two threads, one that takes place twenty years in the past and one that happens simultaneously with the very end of The Long Way to a Small, Angry Planet. That second part is the motivating plot thread, but it's unfortunately impossible to talk about in any depth without seriously spoiling the previous book. You could otherwise read them out of order, but I think the previous book is too good to spoil, so you want to carefully avoid reading any descriptions of this book until after you've read The Long Way to a Small, Angry Planet. Per my normal review policy, I'm going to try to avoid spoilers, but just about everything about half of this book would give away spoilers if you're paying attention. So you may want to just go read the other book before reading this review. (It's excellent!) The part that I can safely say is that half this book is about Pepper, her partner Blue, Pepper's store and Blue's art, and her attempt to help a friend find a place and a sense of identity that she'd never asked for or expected, while keeping a very dangerous secret. That friend starts somewhat passive, but one of the things I liked the most about this story is that Pepper is neither always right in her advice nor always wrong. Sidra is wrong about some of the limitations that she thinks she has and some of the things she thinks she wants, but she's also right about other things where Pepper is wrong. She has a complicated, careful, and courageous journey. The best part of this book for me, though, was the other half, told in alternating chapters with Sidra's story. This is Pepper's own backstory, which is rather awful (although Chambers does avoid being too graphic about the most horrible parts), but is also an amazing story of someone finding her own power, her own skills, and her own identity. And building a relationship that's something quite special. At first, this seems only vaguely related to Sidra's story and the other half of the book, but they both come together in a way that's both heartbreaking and wonderful. I found this story particularly wonderful because one of my favorite SF tropes is sentient computers or sentient ships, which play a significant role in Pepper's backstory. And one of my favorite characters to read about is the technician who can cobble together fixes to things and who is always finding something to repair. Pepper is a delight, her story explains so much about how she became the person she is (and adds so much emotional heft to it), and she has a relentless, practical determination that I loved reading about. A Closed and Common Orbit doesn't have the sprawling cast of The Long Way to a Small, Angry Planet. The story is tightly focused on five characters. I think I liked that even better than the previous book, even when I was finding Sidra a bit too passive and not as interesting. Chambers's characters have so much depth, thoughtfulness, and basic decency, while still being uniquely themselves, that I feel like I could read about them for months and keep uncovering new, interesting facets. I particularly loved the occasional excerpts from the chat system where Pepper hangs out (and would have loved about three times more of them). Speaking as someone who spends a lot of time in chat, Chambers got the tone just about perfect. Just about the only complaint I have about this book is that I thought the ending was too abrupt. It's so important, the climax of Pepper's story and a hugely significant piece of character development, and I wanted more than the short scene and aftermath we got. I really wanted to spend some time feeling with the characters, savoring the emotional release. Another three or four pages would have been greatly appreciated. The Long Way to a Small, Angry Planet was a happy surprise in 2015. A Closed and Common Orbit is fully as good, if not better. If you liked the previous book, you will definitely want to read this. I pre-ordered it and then read it within months after it was released, something that I almost never do. I can hardly wait to read whatever Chambers writes next. Rating: 9 out of 10

I got a new computer and wondered... How can I test it? One of those innocent questions that brings hours and hours of work and questionning...

A new desktop: Intel NUC devices After reading up on Jeff Atwood's blog and especially his article on the scooter computer, I have discovered a whole range of small computers that could answer my need for a faster machine in my office at a low price tag and without taking up too much of my precious desk space. After what now seems like a too short review I ended up buying a new Intel NUC device from NCIX.com, along with 16GB of RAM and an amazing 500GB M.2 hard drive for around 750$. I am very happy with the machine. It's very quiet and takes up zero space on my desk as I was able to screw it to the back of my screen. You can see my review of the hardware compatibility and installation report in the Debian wiki. I wish I had taken more time to review the possible alternatives - for example I found out about the amazing Airtop PC recently and, although that specific brand is a bit too expensive, the space of small computers is far and wide and deserves a more thorough review than just finding the NUC by accident while shopping for laptops on System76.com...

Reviving the Stressant project But this, and Atwood's Is Your Computer Stable? article, got me thinking about how to test new computers. It's one thing to build a machine and fire it up, but how do you know everything is actually really working? It is common practice to do a basic stress test or burn-in when you get a new machine in the industry - how do you proceed with such tests? Back in the days when I was working at Koumbit, I wrote a tool exactly for that purpose called Stressant. Since I am the main author of the project and I didn't see much activity on it since I left, I felt it would be a good idea to bring it under my personal wing again, and I have therefore moved it to my Gitlab where I hope to bring it back to life. Parts of the project's rationale are explained in an "Intent To Package" the "breakin" tool (Debian bug #707178), which, after closer examination, ended up turning into a complete rewrite. The homepage has a bit more information about how the tool works and its objectives, but generally, the idea is to have a live CD or USB stick that you can just plugin into a machine to run a battery of automated tests (memtest86, bonnie++, stress-ng and disk wiping, for example) or allow for interactive rescue missions on broken machines. At Koumbit, we had Debirf-based live images that we could boot off the network fairly easily that we would use for various purposes, although nothing was automated yet. The tool is based on Debian, but since it starts from boot, it should be runnable on any computer. I was able to bring the project back to life, to a certain extent, by switching to vmdebootstrap instead of debirf for builds, but that removed netboot support. Also, I hope that Gitlab could provide with an autobuilder for the images, but unfortunately there's a bug in Docker that makes it impossible to mount loop images in Docker images (which makes it impossible to build Docker in Docker, apparently).

Should I start yet another project? So there's still a lot of work to do in this project to get it off the ground. I am still a bit hesitant in getting into this, however, for a few reasons:

1. It's yet another volunteer job - which I am trying to reduce for health and obvious economic reasons. That's a purely personal reason and there isn't much you can do about it.
2. I am not sure the project is useful. It's one thing to build a tool that can do basic tests on a machine - I can probably just build an live image for myself that will do everything I need - it's another completely different thing to build something that will scale to multiple machines and be useful for more various use cases and users.

(A variation of #1 is how everything and everyone is moving to the cloud. It's become a common argument that you shouldn't run your own metal these days, and we seem to be fighting an uphill economic battle when we run our own datacenters, rack or even physical servers these days. I still think it's essential to have some connexion to metal to be autonomous in our communications, but I'm worried that focusing on such a project is another of my precious dead entreprises... ) Part #2 is obviously where you people come in. Here's a few questions I'd like to have feedback on:

1. (How) do you perform stress-testing of your machines before putting them in production (or when you find issues you suspect to be hardware-related)?
2. Would a tool like breakin or stressant be useful in your environment?
3. Which tools do you use now for such purposes?
4. Would you contribute to such a project? How?
5. Do you think there is room for such a project in the existing ecology of projects) or should I contribute to an existing project?

Any feedback here would be, of course, greatly appreciated.

manpages.debian.org launched The debmans package I had so lovingly worked on last month is now officially abandoned. It turns out that another developer, Michael Stapelberg wrote his own implementation from scratch, called debiman. Both software share a similar design: they are both static site generators that parse an existing archive and call another tool to convert manpages into HTML. We even both settled on the same converter (mdoc). But while I wrote debmans in Python, debiman is written in Go. debiman also seems much faster, being written with concurrency in mind from the start. Finally, debiman is more feature complete: it properly deals with conflicting packages, localization and all sorts redirections. Heck, it even has a pretty logo, how can I compete? While debmans was written first and was in the process of being deployed, I had to give it up. It was a frustrating experience because I felt I wasted a lot of time working on software that ended up being discarded, especially because I put so much work on it, creating extensive documentation, an almost complete test suite and even filing a detailed core infrastructure best practices report In the end, I think that was the right choice: debiman seemed clearly superior and the best tool should win. Plus, it meant less work for me: Michael and Javier (the previous manpages.debian.org maintainer) did all the work of putting the site online. I also learned a lot about the CII best practices program, flask, click and, ultimately, the Go programming language itself, which I'll refer to as Golang for brievity. debiman definitely brought Golang into the spotlight for me. I had looked at Go before, but it seemed to be yet another language. But seeing Michael beat me to rebuilding the service really made me look at it again more seriously. While I really appreciate Python and I will probably still use it as my language of choice for GUI work and smaller scripts, but for daemons, network programs and servers, I will seriously consider Golang in the future. The site is now online at https://manpages.debian.org/. I even got credited in the about page which makes up for the disappointment.

Wallabako downloads Wallabag articles on my Kobo e-reader This obviously brings me to the latest project I worked on, Wallabako, my first Golang program ever. Wallabako is basically a client for the Wallabag application, which is a free software "read it later" service, an alternative to the likes of Pocket, Pinboard or Evernote. Back in April, I had looked downloading my "unread articles" into my new ebook reader, going through convoluted ways like implementing OPDS support into Wallabag, which turned out to be too difficult. Instead, I used this as an opportunity to learn Golang. After reading the quite readable golang specification over the weekend, I found the language to be quite elegant and simple, yet very powerful. Golang feels like C, but built with concurrency and memory (and to a certain extent, type) safety in mind, along with a novel approach to OO programming. The fact that everything can be compiled in one neat little static binary was also a key feature in selecting golang for this project, as I do not have much control over the platform my E-Reader is running: it is a Linux machine running under the ARM architecture, but beyond that, there isn't much available. I couldn't afford to ship a Python interpreter in there and while there are solutions there like pyinstaller, I felt that it may be so easy to deploy on ARM. The borg team had trouble building a ARM binary, restoring to tricks like building on a Raspberry PI or inside an emulator. In comparison, the native go compiler supports cross-compilation out of the box through a simple environment variable. So far Wallabako works amazingly well: when I "bag" a new article in Wallabag, either from my phone or my web browser, it will show up on my ebook reader then next time I open the wifi. I still need to "tap" the screen to fake the insertion of the USB cable, but we're working on automating that. I also need to make the installation of the software much easier and improve the documentation, because so far it's unlikely that someone unfamiliar with Kobo hardware hacking will be able to install it.

Other work According to Github, I filed a bunch of bugs all over the place (25 issues in 16 repositories), sent patches everywhere (13 pull requests in 6 repositories), and tried to fix everythin (created 38 commits in 7 repositories). Note that excludes most of my work, which happens on Gitlab. January was still a very busy month, especially considering I had an accident which kept me mostly offline for about a week. Here are some details on specific projects.

Stressant and a new computer I revived the stressant project and got a new computer. This is be covered in a separate article.

Linkchecker forked After much discussions, it was decided to fork the linkchecker project, which now lives in its own organization. I still have to write community guidelines and figure out the best way to maintain a stable branch, but I am hopeful that the community will pick up the project as multiple people volunteer to co-maintain the project. There has already been pull requests and issues reported, so that's a good sign.

Feed2tweet refresh I re-rolled my pull requests to the feed2tweet project: last time they were closed before I had time to rebase them. The author was okay with me re-submitting them, but he hasn't commented, reviewed or merged the patches yet so I am worried they will be dropped again. At that point, I would more likely rewrite this from scratch than try to collaborate with someone that is clearly not interested in doing so...

Debian uploads

• calibre 2.75.1 backport - thanks to Nicholas Steeves for finding out about the security issues as well!
• dnsdiag 1.4.0 - sponsored, in NEW, now in unstable!
• monkeysign 2.2.3 - a quick bugfix release to ship a good version in stretch, now finally with GnuPG 2.x support!
• pepper 0.3.3-3 - just regular package maintenance
• tty-clock 2.3 - new upstream release, also got access to the upstream project
• tuptime 3.3.1 - sponsored

Debian Long Term Support (LTS) This is my 10th month working on Debian LTS, started by Raphael Hertzog at Freexian. I took two months off last summer, which means it's actually been a year of work on the LTS project. This month I worked on a few issues, but they were big issues, so they took a lot of time. I have done a lot of work trying to backport the heading sanitization patches for CVE-2016-8743. The full report explain all the gritty details, but I ran out of time and couldn't upload the final version either. The issue mostly affects Apache servers in proxy configurations so it's not so severe as to warrant an immediate upload anyways. A lot of my time was spent battling the tiff package. The report mentions fixes for 15 CVEs and I uploaded the result in the DLA-795-1 advisory. I also worked on a small update to graphics magic for CVE-2016-9830 that is still pending because the issue is minor and we're waiting for more to pile up. See the full report for details. Finally, there was a small discussion surrounding tools to use when building and testing update to LTS packages. The resulting conversation was interesting, but it showed that we have a big documentation problem in the Debian project. There are a lot of tools, and the documentation is old and distributed everywhere. Every time I want to contribute something to the documentation, I never know where to start or go. This is why I wrote a separate debian development guide instead of contributing to existing documentation...

On Progress and Historical Change [archive]

Is progress inevitable? Is it natural? Is it fragile? Is it possible? Is it a problematic concept in the first place? Many people are reexamining these kinds of questions as 2016 draws to a close, so I thought this would be a good moment to share the sort-of zoomed out discussions the subject that historians like myself are always having.

A projection of the ISS live feed as a night light [archive]

I always wanted the ISS live feed as a "night light" / ambiance to fall asleep to on my ceiling how to build a "night light" that is actually a small video projector projecting the ISS live feed

Vatican Climate Forest [archive]

The Vatican Climate Forest, to be located in the B kk National Park, Hungary, was donated to the Vatican City by a carbon offsetting company. The forest is to be sized to offset the carbon emissions generated by the Vatican during 2007. The Vatican's acceptance of the offer, at a ceremony on July 5, 2007, was reported as being "purely symbolic", and a way to encourage Catholics to do more to safeguard the planet. No trees have been planted under the project and the carbon offsets have not materialised. I'm fascinated by how purely symbolic "purely symbolic" can be.

When I was younger, and worked in an "old HP" test and measurement division, I sometimes sat at lunch in the cafeteria with a group of older co-workers who I grew to have immense respect for. They told great stories. I learned a lot of practical electronics from them... and other things too. Each carried on their person a copy of the US Constitution and Bill of Rights, and most also had a "concealed carry" permit, which they would refer to as their "redneck license". I quickly learned that they weren't all gun fanatics... at that time, the vetting process for such a permit was a bit daunting, and having one was their way of "proving" that they were honest, law-abiding citizens. Citizens who knew their rights. Who enjoyed debating boundary conditions in those rights inspired by current events at the lunch table. I miss those guys and those conversations. I mention this because it's one of those things that I realize now had a significant formative impact on my adult values and world view. Freedom matters. That's why, despite my long-standing appreciation for and support of the organization's activities, I'm embarrassed to admit that it wasn't until this week that I personally joined the American Civil Liberties Union and sent them a donation.

Exactly on the schedule, Weblate 2.11 is out today. This release brings extended stats available to users and various other improvements and bug fixes. Full list of changes:

• Include language detailed information on language page.
• Mercurial backend improvements.
• Added option to specify translation component priority.
• More consistent usage of Group ACL even with less used permissions.
• Added WL_BRANCH variable to hook scripts.
• Improved developer documentation.
• Better compatibility with various Git versions in Git exporter addon.
• Included per project and component stats.
• Added language code mapping for better support of Microsoft Translate API.
• Moved fulltext cleanup to background job to make translation removal faster.
• Fixed displaying of plural source for languages with single plural form.
• Improved error handling in import_project.
• Various performance improvements.

If you are upgrading from older version, please follow our upgrading instructions. You can find more information about Weblate on https://weblate.org, 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 https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Aptoide, 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 phpMyAdmin SUSE Weblate 0 comments

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 I was allocated 10 hours to work on security updates for Debian 7 Wheezy. During this time I did the following:

• I reviewed multiple CVE affecting ntp and opted to mark them no-dsa (just like what has been done for jessie).
• I pinged upstream authors of jbig2dec (here) and XML::Twig (by private email) where the upstream report had not gotten any upstream reply yet.
• I asked on oss-security for more details about CVE-2016-9584 because it was not clear whether it had already been reported upstream. Turns out that it was. I then updated the security tracker accordingly.
• Once I got a reply on jbig2dec, I started to backport the patch pointed out by upstream, it was hard work. When I was done, I had also received by private email the fuzzed file at the origin of the report unfortunately that file did not trigger the same problem with the old jbig2dec version in wheezy. That said valgrind still identified read outside of allocated memory. At this point I had a closer look at the git history only to discover that the last 3 years of work consisted mainly of security fixes for similar cases that were never reported to CVE. I thus opened a discussion about how to handle this situation.
• Matthias Geerdsen reported in #852610 a regression in libtiff4. I confirmed the problem and spent multiple hours to come up with a fix. The patch that introduced the regression was Debian-specific as upstream did not fix those issues yet. I released a fixed package in DLA-610-2.

Debian packaging With the deep freeze approaching, I made some last-minute updates:

• schroot 1.6.10-3 fixing some long-standing issues with the way bind mounts are shared (#761435) and other important fixes.
• live-boot 1:20170112 to fix a failure when booting on a FAT filesystem and other small fixes.
• live-config 5.20170112 merging useful patches from the BTS.
• I finished the update of hashcat 3.30 with its new private library and fixed RC bug #851497 at the same time. The work was initiated by fellow members of the pkg-security team.

Misc work Sponsorship. I sponsored a new asciidoc upload demoting a dependency into a recommends (#850301). I sponsored a new upstream version of dolibarr. Discussions. I seconded quite a few changes prepared by Russ Allbery on debian-policy. I helped Scott Kitterman with #849584 about a misunderstanding of how the postfix service files are supposed to work. I discussed in #849913 about a regression in building of cross-compilers, and made a patch to avoid the problem. In the end, Guillem developed a better fix. Bugs. I investigated #850236 where a django test failed during the first week after each leap year. I filed #853224 on desktop-base about multiple small problems in the maintainer scripts. Thanks See you next month for a new summary of my activities.

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