Planet Debian

Subscribe to Planet Debian feed
Planet Debian - http://planet.debian.org/
Updated: 2 hours 3 min ago

Pau Garcia i Quiles: Almost at FOSDEM. Video volunteers?

3 February, 2017 - 15:23

I am boarding my flight to Brussels to attend FOSDEM.

The Desktops DevRoom will be a blast again this year. While I have been in charge of it for 6? years already, the last two (since my twins) were born I had organized remotely and local duties were carried on by the Desktops DevRoom team (thank you Christophe Fergeau, Philippe Caseiro and others!).

I am anxious at meeting old friends again. I will be at the beer event today.
Video streaming will be available and thanks to the Video Team. If you want to help, please contact us in the desktops-devroom@lists.fosdem.org mailing list, or directly at the devroom.

Also, this year will be the first for me using the job corner to recruit: my company (everis) is recruiting globally for many open positions. Drop us a mail at fosdem@everis.com with your CV, desired position and location (we have direct presence in 13 countries and indirect in 40 countries) and I will make sure it reaches the right inbox.

intrigeri: First Tails beta release based on Stretch

3 February, 2017 - 06:44

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.

Steinar H. Gunderson: Not going to FOSDEM—but a year of Nageru

3 February, 2017 - 06:29

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. :-)

Vincent Fourmond: Extended dataset generation possibilities of QSoas

3 February, 2017 - 04:58
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.

Shirish Agarwal: The $100 used laptop and getting riled up.

3 February, 2017 - 03:03

Lenovo-ThinkPad-T500 – Source – Wikimedia commons

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

Guido Günther: Debian Fun in January 2017

2 February, 2017 - 23:48
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

Urvika Gola: Outreachy- Week 6 & 7 Progress

2 February, 2017 - 23:07

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


Steve Kemp: I've built a product, not a project

2 February, 2017 - 14:15

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.

Paul Wise: FLOSS Activities January 2017

2 February, 2017 - 07:29
Changes Issues Review 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.

Iustin Pop: The snow is gone

2 February, 2017 - 05:25

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…

Lars Wirzenius: Hacker Noir, chapter 2: Development setup phase

1 February, 2017 - 18:29

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.

Wouter Verhelst: Resetting a Raspberry Pi to default using Ansible

1 February, 2017 - 17:19

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 tasks. The first task 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.

Daniel Pocock: Going to FOSDEM, Brussels this weekend

1 February, 2017 - 16:07

This weekend I'm going to FOSDEM, one of the largest gatherings of free software developers in the world. It is an extraordinary event, also preceded by the XSF / XMPP Summit

For those who haven't been to FOSDEM before and haven't yet made travel plans, it is not too late. FOSDEM is a free event and no registration is required. Many Brussels hotels don't get a lot of bookings on weekends during the winter so there are plenty of last minute offers available, often cheaper than what is available on AirBNB. I was speaking to somebody in London on Sunday who commutes through St Pancras (the Eurostar terminal) every day and didn't realize it goes to Brussels and only takes 2 hours to get there. One year I booked a mini-van at the last minute and made the drive from the UK with a stop in Lille for dinner on the way back, for 5 people that was a lot cheaper than the train. In other years I've taken trains from Switzerland through Paris or Luxembourg.

Real-time Communication (RTC) dev-room on Saturday, 4 February

On Saturday, we have a series of 23 talks about RTC topics in the RTC dev-room, including SIP, XMPP, WebRTC, peer-to-peer (with Ring) and presentations from previous GSoC students and developers coming from far and wide.

The possibilities of RTC with free software will also be demonstrated and discussed at the RTC lounge in the K building, near the dev-room, over both Saturday and Sunday. Please come and say hello.

Please come and subscribe to the Free-RTC-Announce mailing list for important announcements on the RTC theme and join the Free-RTC discussion list if you have any questions about the activities at FOSDEM, dinners for RTC developers on Saturday night or RTC in general.

Software Defined Radio (SDR) and the Debian Hams project

At 11:30 on Saturday I'll be over at the SDR dev-room to meet other developers of SDR projects such as GNU Radio and give a brief talk about the Debian Hams project and the relationship between our diverse communities. Debian Hams (also on the Debian Ham wiki) provides a ready-to-run solution for ham radio and SDR is just one of its many capabilities.

If you've ever wondered about trying the RTL-SDR dongle or similar projects Debian Hams provides a great way to get started quickly.

I've previously given talks on this topic at the Vienna and Cambridge mini-DebConfs (video).

Ham Radio (also known as amateur radio) offers the possibility to gain exposure to every aspect of technology from the physical antennas and power systems through to software for a range of analog and digital communications purposes. Ham Radio and the huge community around it is a great fit with the principles and philosophy of free software development. In a world where hardware vendors are constantly exploring ways to limit their users with closed and proprietary architectures, such as DRM, a broad-based awareness of the entire technology stack empowers society to remain in control of the technology we are increasingly coming to depend on in our every day lives.

Russ Allbery: Review: A Closed and Common Orbit

1 February, 2017 - 12:24

Review: A Closed and Common Orbit, by Becky Chambers

Series: Wayfarers #1 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

Hideki Yamane: How to check your package for FTBFS with clang

1 February, 2017 - 10:04
GCC 7 doesn't go into Debian9, but gcc maintainers now file FTBFS bugs for it.

Also you can check packages via building with clang easily. I've already prepared pbuilder (and cowbuilder) build hook script for it. So, if you want to check a package with clang 4.0,

$ mkdir ~/hookdir$ ln -s /usr/share/doc/pbuilder/examples/D65various-compiler-support ~/pbuilder-hookdir(modify your pbuilderrc as adding 1 line like below)
HOOKDIR=/home/henrich/pbuilder-hookdir$ sudo CHOOSE_COMPILER="clang-4.0" cowbuilder --build yourpackage_1.0-1.dsc
That's all - it's handy, isn't it? Please try it to make your package more healthy :)

Antoine Beaupré: Testing new hardware with Stressant

1 February, 2017 - 07:36

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.

Antoine Beaupré: My free software activities, January 2017

1 February, 2017 - 07:09
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 will 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 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...

Enrico Zini: Links for February 2017

1 February, 2017 - 06:00
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.

Bdale Garbee: ACLU

1 February, 2017 - 05:42

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.

Sean Whitton: sorcererscode

31 January, 2017 - 23:37

The Sorcerer’s Code

This is a well-written biographical piece on Stallman.

Pages

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้