Language Selection

English French German Italian Portuguese Spanish


Syndicate content
Planet Debian -
Updated: 1 hour 39 min ago

Molly de Blanc: breaking up

7 hours 43 min ago

Just as technology has entwined itself with the act of falling in love, it also has an inescapable role in the act of breaking up. Ending a relationship is hard enough, and made even harder by computing technology.

Clearing an ex-lover from your life is one of the first steps in getting over a breakup. This act is cathartic — it gives you something to focus on in a dark time, a thing to do when you want to do nothing. So, you delete their number from your phone. You archive or delete the text thread you’ve had running for however long. You leave groupchats. You remove their photos from your devices — maybe deleting them, maybe storing them somewhere far away and safe. You hide the emails they’ve sent, the playlists they’ve made for you, and that file of recordings of them reading their favorite book to you.

Then you stop following them on social media.

And immediately social media suggests you follow them.

You’ll continue to see reminders of these people — whether through their activity with your shared contacts or the friendly reminders, the helpful notices, from the algorithms at Facebook and Twitter that think you might possibly know this person with whom you are no longer entangled.

Twitter lets you block people. However:

…please note that you may see Tweets or notifications in your timeline for the following:

  1. Tweets from others you follow that mention accounts you have blocked.
  2. Tweets that mention you, along with an account you have blocked.

These little reminders might be more than you want. You might want a feature to just hide them from you — or to replace every mention of their name with a photo of a kitten. You might want to not see their blog in a shared feed, or to mute them in a social IRC channel.

One of the things we do when it comes to using the internet and web is wind our lives in and out of infrastructure we share with others. We put huge amounts of ourselves into these spaces. The strength and resilience that gives our networks power also gives them the opportunity to tear us down.

FLOSS is about choice (among other things). One of the things we get from developer freedom is the ability to specialize or have specialized technology — the development of features and tools, the fixing of bugs and anti-features.

Would I go as far as to say that seeing someone mentioned in a timeline is a bug, or that the recommendation I add someone I don’t want to think about to my social network is an anti-feature? Yes. It’s a stance I am taking because, due to the proprietary nature of many of these technologies, we’re waiting for a company to decide to give us the freedom to break up and break off contact.

Breakups are traumatic. They can be deeply and devastatingly traumatic. We can be in positions where we need our networks that are now inaccessible to us, because they are too tied into those we loved and still love, even when we wish we didn’t.

A few quick notes:

Generous friends who read through this before I posted it made the following points, which are valuable:

  • There are people who stay away from web sites like Facebook because the people who abused them use that site, and the risk of being triggered it too high.
  • People also stay away from these sites because they are hiding from abusers, who would be given access to them, whether they’d like it or not.
  • This is also applicable to basically any person, regardless of the reason(s) you may want to avoid them.

Louis-Philippe Véronneau: Running Android 9 (Pie) on a Nexus 5 -- Unlegacy Android

Wednesday 24th of April 2019 04:00:00 AM

Like most good stories, this one starts in a bar with friends. I had the chance to go to FOSDEM this year and I managed to get a bunch of people from the DebConf videoteam to meet me at Brew Dog Bruxelles.

Like the respectable geeks we are, the first thing we did after exchanging greeting was to connect to the local Wi-Fi. That's when Stefano Rivera looked at my phone and casually said: “Wow, that's running Android 7, it's ancient!”.

I've had my Nexus 5 for a while now. If I recall correctly, I bought it sometime in Q1 2014. Although already dated at the time, it was a great phone: fast, cheap and easy to repair. The Nexus 5 hasn't been supported by Google for years, but until recently LineageOS did a great job at keeping the OS patched and updated. Sadly, it seems my device won't get ported to LineageOS 16. As announced here, the 14.1 branch won't get security support anymore.

Lucky for me, I found the amazing Unlegacy Android project. Their goal is to build and patch the Android Open Source Project (AOSP) for older devices. The difference with LineageOS is that they do not customize the ROMs, thus making patch porting easier and less troublesome. A few models are supported, but their main focus is the Nexus 5.

Installing Unlegacy Android

If you have a Nexus 5 and want to upgrade to a bleeding edge version of Android, you have two options:

  1. You can install one of the builds provided by the Unlegacy Android project. Since they still consider Android 9 experimental (even though it works pretty much flawlessly), those builds are hosted on a shady cloud storage.
  2. You can build the ROM yourself, following the LineageOS wiki instruction while replacing the code repository with the Unlegacy one.

Although it's a bit more work, I prefer to build the project myself. Something about downloading an update from a random cloud storage doesn't feel right to me. Once a month, when the monthly Android Security Patch is merged in the Unlegacy repository, I boot a VM on my server and build a new OTA update.

Unlegacy Android also provides official Android 7 and Android 8 builds if you are into that.

What about bugs?

I've been using Unlegacy Android with the latest Android 9 builds for 3 months now and the only bugs I've experienced are:

  • On an encrypted device, TWRP isn't able to decrypt the partitions, rendering it somewhat useless. You can still update the device via ADB sideload though.
  • Bluetooth voice calls (HFP) are garbled. Playing music via A2DP works fine though.

I also seen more random app crashes than when I was using LineageOS 14.1, but nothing extreme. The overall experience is great: my device is snappy, runs the latest AOSP build and I neither have bloatware nor Google Apps.

All in all, considering new phones running Android 9 start at 500 USD and that you can buy a new Nexus 5 for less than 100 USD on ebay, it's a pretty compelling choice.

Jonathan McDowell: Making my first PCB

Tuesday 23rd of April 2019 07:52:56 PM

I’ve written a lot about my various home automation bits, but I haven’t generally posted pictures. That’s because my construction skills aren’t great; I’m wiring together modules and that tends to make it harder to case things properly and make them look nice. My first attempt to be better about this was to buy a prototyping box which had a case + board paired with it I could attach modules to. This helped a bit, but still involved a mess set of wiring to attach things together (proper strip board would have been more useful than just copper pads).

I then started to notice I was getting JLCPCB ads while web browsing, offering 10 PCBs for $2. That seemed like a good deal, and I thought if I did things right I could find the right case and then make sure the PCB fitted in it. I found a small vented white case available from CPC. This allows me to put a temperature sensor inside for some devices. KiCad seemed like a good option for trying to design my basic schematic and lay it out, so I installed it and set to work trying to figure out what I wanted to put on the board, and how to actually drive KiCad.

As the core I chose an ESP-07 ESP8266 module. I’ve used a few of them before and they’re cheap and convenient. I added an LDO voltage regulator (LD1117) so I could use a 5V PSU (and I’m hoping with a heatsink I can get away with a 12V supply as well, even if it’s more inefficient). That gave enough to get a basic schematic once I’d added the necessary pull-up/down resistors for the ESP8266 and decoupling capacitors. I included a DC barrel jack for the PSU, and pin headers for the serial port, SPI pins and GPIO0 for boot selection. One of my use cases is to make an LED strip controller, so I threw in a screw terminal block for power + control - the board is laid out to allow a MOSFET for a simple white 12V LED strip, or the same GPIO taken straight to the terminal block for controlling a WS2812 strip. By including a couple of extra pull-up resistors I added the option of I2C for further expansion.

After I had the basic schematic I moved to layout. Luckily Hammond provide 2D CAD files for the case, so I figured I would import them into KiCad’s PCB layout tool to make sure things would fit. That took a little bit of effort to go from DWG to DXF and trim it down (I found a web tool to do the initial conversion and then had to strip out the bits of the case that weren’t related to the PCB size + mounting points). I wasn’t confident enough that the edge cuts layer would include the mounting holes, so I manually placed some from KiCad over the right spots.

At this point I was glad I had a simple design, because it took me a while to decide how to place things and then route the tracks. I ended up altering some header pin assignments from the original design to make things a bit easier to route, and took advantage of the double sided board to put some components underneath, to ease both routing and space constraints. Originally I had planned to make things easy and go for through-hole components (I’ve never SMD soldered before) but in the interests of making use of space I risked the “1206 Handsoldered” footprint option in KiCad, which seems to be like the Duplo of SMD components. I kept my regulator as through-hole to make a larger heatsink easier. I also discovered I had a bit of spare space, so I put down a footprint and pin headers for a PCF8574 I2C GPIO expander to allow for more IO if I needed it. Finally the I2C pin header was laid out to allow a BME280 module to be soldered directly on top, allowing for easy addition of environmental monitoring without having to solder ridiculously small devices myself.

Once I had all of that done I printed out my final design, carefully cut around the edge and made sure it fitted into the case and the components I already had where the right size. Once I was fairly confident I’d checked as much as I could I then did a Gerber export and uploaded to JLCPCB. The process was very smooth - you upload a zip file, can do a sanity check viewing of how they’ve parsed it, select various options for the PCB (I left almost everything as the default) and then submit the order. Over the next couple of days you can see things progress through the various manufacturing stages and then get dispatched. For the first order it turns out you get free DHL Express delivery, so I ordered on Friday morning and had 10 boards by Wednesday afternoon. All for £1.58. A friend tells me subsequent orders have standard China Post shipping as standard, but for that price it’s still hard to beat!

How did they turn out? Pretty well. The quality of the boards is excellent to my untrained eye. Soldering the SMD bits got easier when I switched to a better bit on my soldering iron and made sure it was well screwed in (otherwise it, er, doesn’t heat up particularly reliably) - my soldering is still terrible, but it gets the job done. Most importantly the PCB fit the case footprint perfectly - mounting holes in the right place, edge cuts the right shape/size. A couple of snips to the vents and the barrel jack connector and terminal block are easily accessible, and it still looks fairly neat. The main mistake I made was not thinking about component heights! In particular the barrel jack was a couple of mm too high, which a quick shave with a Dremel sorted. The voltage regulator also stood far too high, which I fixed by bending at a 90° angle over the board. This will limit my options for a heatsink, but for 5V power this isn’t necessary anyway.

So far I’ve assembled 2 boards, both controlling WS2812 LED strips and powered by 5V PSUs. One also has a BME280 added. I’m waiting on more parts arriving and then will try out a 12V / white LED strip combo. I’m really pleased with the overall results; it took a while playing with KiCad to get to the point I was confident to send my files off to be manufactured (the print outs helped a lot), and failing to think about component heights was a silly mistake, but having everything mounted on a single PCB and firmly screwed into a case makes for a much more robust project. The first 2 are both hidden out of the way, but it’s reassuring to know they’re not particularly fragile like some of my earlier constructions. And I’m already trying to work out what PCB I want to make next…

Jonathan Dowland: Use the Twitter web view

Tuesday 23rd of April 2019 02:40:07 PM

Here's a tip for mobile Twitter users who are frustrated with either shortcomings of the Twitter app, or the invasive nature of social media apps in general: delete the app, and just use the mobile web view.

I've been doing this for a while now, and the experience is much better for me. With the app, I regularly had my current view of either a timeline or a specific tweet interrupted or lost when the app decided to refresh. With the web view, I have my browser's history and back/forward buttons, and the ability to bookmark specific tweet URIs if I so wish.

I can open multiple windows with different tweets in them, if I want to keep a few around as reminders for something or other. I can switch between multiple tweets; or tweets, the timeline and something completely different, and not lose my views. I can follow a link from a tweet and not be bounced to a different app (or worse: an app-specific, built-in browser with none of my browser settings or sessions, a fresh round of hell clicking on the Cookie and Privacy Choices pop-ups), and clicking "Back" from such articles brings me back to where I came from.

But most importantly, if I get sick and tired of Twitter at any given moment, I can just close that browser tab. I don't have an omni-present Twitter icon on my phone calling me to click on it. It's just a website, like many others, that I can choose to visit, or not, whenever I want. The Twitter web experience is certainly less polished than the app one, but ultimately I feel like I'm in control of it, rather than the other way around.

Martin Michlmayr: ledger2beancount 1.7 released

Monday 22nd of April 2019 06:38:14 AM

I released version 1.7 of ledger2beancount, a ledger to beancount converter.

This release contains a number of bug fixes and a new feature:

  • Don't misparse account and commodity with mixed tab/space separators
  • Rename account names consisting of a root name without subaccount
  • Warn when non-standard root names are used
  • Avoid duplicate open directives for accounts with name collisions
  • Don't warn for renamed tags that won't show up in the beancount file
  • Add account_regex option to mass rename account names
  • Add man page and improve documentation

You can get ledger2beancount from GitHub.

Thanks to GitHub user Joradi98 for reporting some bugs. Thanks to Jelmer Vernooij for packaging ledger2beancount for Debian.

Keith Packard: snek-car

Monday 22nd of April 2019 05:33:29 AM
Snek Drives a Lego Car

(click on the picture to see the movie)

This is made from:

You can get everything other than the light sensors from various vendors.

More Pictures

Here's a picture from the front showing the light and light sensor mounted next to each other.

And here's the car from the rear showing the motor connections, the other light sensor/light combination and the battery pack:

Source Code

This program is a bit more verbose:

mr = (MOTOR1A, MOTOR1B) ml = (MOTOR2A, MOTOR2B) pf = SIGNAL1 pr = SIGNAL2 f_speed = 0.5 r_speed = 0.5 t_speed_f = 0.6 t_speed_s = 0.2 def forw(): talkto(mr) setpower(f_speed) setright() on() talkto(ml) setpower(f_speed) setleft() on() def back(): talkto(mr) setpower(r_speed) setleft() on() talkto(ml) setpower(r_speed) setright() on() def left(): talkto(mr) setpower(t_speed_f) setright() on() talkto(ml) setpower(t_speed_f) setright() on() def right(): talkto(mr) setpower(t_speed_f) setleft() on() talkto(ml) setpower(t_speed_f) setleft() on() def stop(): talkto(ml) setpower(0) off() talkto(mr) setpower(0) off() def go_forw(): forw() listento(pf) while read() < .25: pass stop() def go_back(): back() listento(pr) while read() < .25: pass stop() def bumper(): while True: go_forw() back() time.sleep(0.5) stop() left() time.sleep(0.25) stop() go_forw() go_back() go_forw() bumper()

Iustin Pop: Yet another man to epub converter :)

Sunday 21st of April 2019 10:48:08 PM

One early result from getting the Kobo Forma reader I wrote before about was “how can I read as much as possible offline?”; and soon enough, I was looking for a man page to ebook (epub) converter.

Initial search seemed successful, but actually, none of the things I found worked correctly, or at least were not working for me. More precisely, I wanted something to generate a “book” with consistent internal links, so that I can jump from one page to another correctly. See the README for what I tried and gave up on.

In Debian, there is of course the online manpages service, and there’s also The Linux man-pages project which do this very well. However, the UI and style for these seem to be designed for interactive browsing, whereas a simple output is better for offline browsing.

So, after a bit of playing around with man -T html, mandoc and man2html, I settled on the later to write my tiny wrapper script. It’s a v0.0.1 release, but nevertheless works, so here it is:

Could be made much better, and switching the backend might be interesting, but it doesn’t need to be more complex. Of course, customising the metadata via the command line would be useful, the auto-generated TOC contains extraneous items, etc. etc. :)

P.S.: In other open-source related topics, I haven’t made a new Corydalis release in ages, but I’m slowly getting there…

Bits from Debian: DPL elections 2019, congratulations Sam Hartman!

Sunday 21st of April 2019 12:00:00 PM

The Debian Project Leader elections just finished and the winner is Sam Hartman!

His term as project leader starts inmediately today April 21st and expires on April 20th 2020.

Of a total of 1003 developers, 378 developers voted using the Condorcet method. More information about the result is available in the Debian Project Leader Elections 2019 page.

Many thanks to Joerg Jaspert, Jonathan Carter and Martin Michlmayr for running.

And special thanks to Chris Lamb for his service as DPL during these last twenty-four months!

Keith Packard: snek-balloon

Sunday 21st of April 2019 04:59:59 AM
Snek and a Balloon

(you can click on the picture to watch the model in action)

This represents the scale of projects we typically do in our Lego class. A motor, a couple of sensors and some simple logic. Here's the Snek program driving the balloon:

# Make the balloon go up and down motor = (D9, D8) top = A0 bottom = A1 def up(): talkto(motor) listento(top) setpower(0.5) setright() on() while read() < .8: pass off() def down(): talkto(motor) listento(bottom) setpower(0.3) setleft() on() while read() < .8: pass off() def play(): while True: up() time.sleep(10) down() time.sleep(10) play() Light Sensors and Lights

I like to use light sensors with robotics and wanted to make some new ones sensitive to visible light. I found these Vishay TEPT5600 photo-transistors which are sensitive to most visible light. Using those with a 470kΩ resistor generated a good range of outputs for indoor lights.

For a light source, I'm using Cree 5mm green LEDs with a 5V power supply and a 100Ω current limiting resistor, these draw about 20mA and generate a lot of light.

For both of these, I take a 1x4 brick and drill a 3/16" hole in one end and a 1/8" in the other. The 5mm device fits snugly in the larger hole and the wires thread out through the other hole. The 1/8W resistor is tucked inside the brick.

You can see both of these in action in the example — the white bricks contain LEDs and the red bricks contain light sensors. The path between the light and sensor is interrupted by the model, allowing the program to determine when the motion has completed.


This model uses the Circuit Cube motors that I discovered last month. There's one visible near the middle of the Ferris wheel and another one just behind the Duemilanove board driving the balloon mechanism.

These motors have a built-in gear reduction and so they offer low speed and high torque. For Lego modelers, that's a pretty useful combination as the older non-geared motors always involved a long gear-train or worm gear to provide a reasonable balance of speed and power. For the balloon, there is a string wrapping around an axle driven directly by one of these motors.

Simple Models with Simple Programs

This class uses Lego to build simple mechanical devices that are controlled with simple computer programs. The Snek environment is the latest in a long history of computer systems which started with Lego Logo on the Apple ][ over twenty years ago.

Jonathan Carter: Debian project leader elections 2019

Saturday 20th of April 2019 12:00:25 PM

A few weeks ago, after a few days of internal turmoil on the matter, I committed to running for DPL.

The original nomination period was the week before, with no one stepping up for the position and with our current leader indicating that he wouldn’t be available to serve another term. This resulted in a bit of a knee-jerk reaction and slight panic, with threads popping up on the debian mailing lists pondering things like what a leaderless Debian would look like and whether we perhaps need more of a team than a single person to be the leader the project. There was also some discussion about burnout and whether it’s even fair to put so much pressure on a single person, and whether it’s possible to delegate more of the DPL’s responsibilities. The press also picked up on this and there were a few big stories on the matter that lead some to be slightly nervous on the matter.

Of course (as the LWN article pointed out), Debian’s constitution is quite thorough and has made provision for cases like these. If no one steps up, the nomination period is extended for another week, and it only took one such extension to produce 5 new candidates (of which one retracted soon afterwards due to time commitments).

I mentioned internal turmoil at the beginning of the post, this was because up until a few days before my self-nomination, I’ve been very confident, and consistently so for a very long time, that I never want to run for DPL. The work that I care about and spend most attention on doesn’t at all require me being a DPL. Also, having more responsibility in areas that I’d rather let others take care of sounded a bit daunting. I’d much rather spend time on technical and more general community issues than very specific interpersonal problems or administrative tasks like reading and approving budget proposals, sending out developer certificates, etc. On top of that, I was aware that running for DPL and opening myself like that means that I open myself to a very wide array of critique, that people might put everything I say under a microscope and try to tear it apart, and that running for DPL means being prepared for that.

Despite that turmoil, a small nagging part kept asking the questions “But what if?”, what if I were DPL, what would I do? What would I change? What would I do as DPL that would make Debian better, and better as a DPL than I just could as a normal debian developer? These questions helped form in my head what my platform would look like, why I wanted to run for DPL, and how the rest of my campaign would shaped up. This year is also unique for me compared to previous years in that I will actually have time over the next year to focus on DPL-like activities. That, combined with the plans that were shaping up that I’m very enthusiastic about, convinced me that it’s time to step up and proceed with my self-nomination.

Directly after the nomination period, the campaign period starts. There are surprisingly few rules (or even guidance) regarding the campaign period, the majority of it is where Debian developers (or anyone really, but mostly DDs) ask questions to the DPL candidates about their stance and policy on certain matters, how they plan to take action and often a few really tough hypothetical situations. Some questions even took advantage of the fact that April fools day falls in the campaign period, which led to some odd and interesting questions. Overall, I really enjoyed the campaign period. I was preparing myself for the worst case scenario before campaigning started, but what actually happened next astonished me. We had all kinds of Debian developers coming forward with high quality, productive discussions on all kinds of aspects which ranged from internal technical policies, how we work with upstreams, community matters, diversity, the DPL role itself, how Debian is changing and how to keep it relevant, community turnover, how we deal with money, how we market ourselves and so one. It was productive discussion and I enjoyed it.

Regardless of the outcome of this election, I’m very happy that I stepped up as a DPL candidate, and I’m very satisfied with how my campaign went and how I answered my questions. I’m also very happy that the elections turned out so vibrant and productive and I dare say even exciting. I hope that this will continue to happen for future elections, because it’s clear to me that a productive election period is good for the health of Debian.

In the future, someone may be reading this and ponder “Should I run for DPL?”. My advice would be to first take some stock and figure out if you’re at a place in your life where you can actually do that (Did you just start a new job? Would your employer support you? Did you recently get married, have kids? How’s your health? Can you afford to spend lots of unpaid time doing DPL work? etc…) and then also consider why you’d want to be DPL and what you’d like to achieve with such a role. If you weigh up all the aspects and it still feels right for you, then by all means go for it. In my opinion, even if you’re not elected you still help make Debian better by participating in the election process.

Voting closes in around 12 hours at the time of writing this. Good luck to all the candidates and thank you to everyone who participated in making this such a fantastic and surreal experience!

2019-04-21: Update: Congratulations to Sam Hartman who is our new DPL! We’ve been talking off-list throughout the election process and Sam knows he has my full support and we even plan to collaborate on certain areas, more news to follow in the near future.

Michal &#268;iha&#345;: Weblate 3.6

Saturday 20th of April 2019 11:00:39 AM

Weblate 3.6 has been released today. It brings rewritten notifications, user data download and several other improvements. It also sets depreciation timeline for Python 2 installations - after April 2020 Weblate will only support Python 3.

Full list of changes:

  • Add support for downloading user data.
  • Addons are now automatically triggered upon installation.
  • Improved instructions for resolving merge conflicts.
  • Cleanup addon is now compatible with app store metadata translations.
  • Configurable language code syntax when adding new translations.
  • Warn about using Python 2 with planned termination of support in April 2020.
  • Extract special chars from the source string for visual keyboard.
  • Extended contributor stats to reflect both source and target counts.
  • Admins and consistency addons can now add translations even if disabled for users.
  • Fixed description of toggle disabling Language-Team header manipulation.
  • Notify users mentioned in comments.
  • Removed file format autodetection from component setup.
  • Fixed generating MO file for monolingual PO files.
  • Added digest notifications.
  • Added support for muting component notifications.
  • Added notifications for new alerts, whiteboard messages or components.
  • Notifications for administered projects can now be configured.
  • Improved handling of three letter language codes.

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

You can find more information about Weblate on, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. Weblate is also being used on as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

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

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

Filed under: Debian English SUSE Weblate

Keith Packard: crickit-snek

Saturday 20th of April 2019 07:45:59 AM
CrickitSnek — snek on the Adafruit Crickit

I got a Crickit FeatherWing from Adafruit today. This board is supposed to act as an I/O expander for all of the Feather boards, but it's a completely operational SAMD21 machine with a pile of useful GPIO bits:

  • 4 “Capacitive Touch” pins (which are just regular GPIOs)
  • 8 Analog input/digital output pins
  • 4 Digital I/O pins
  • 4 High-current 5V digital output pins
  • 2 H-bridge motor controllers
  • 1 Audio amplifier
  • 1 high current output designed for NeoPixels

It's also got a USB port and an on-board NeoPixel, plus headers to plug in a Feather board.

There's no Crystal on the Crickit

To save cost, the Crickit design doesn't include any crystal at all. That required re-configuring the SAMD21 clock configuration to synchronize the 48MHz system clock from USB instead of from the 32.768kHz crystal present on the Metro and Feather boards. Once I had done this, the Crickit board appeared on USB and Snek was running.

Naming the Crickit pins

There are a bunch of separate I/O groupings on the Crickit board, and I wanted to make it easy to remember how to use them. Providing convenient names for each pin seemed like the the best plan.

On the Metro and Duemilanove boards, I just used numbers for all of the pins; 0-13 for the digital pins and 14-19 for the analog pins. This matches the Arduino conventions, although it doesn't provide the convenient 0-5 numbering for analog input. Having names for these pins will also be nice.

So, I hacked up the Snek 'builtins' mechanism to include builtins with numeric values. Now you can have as many builtin values as you want. I first replaced the wacky lexer hacks for values like 'math.pi', 'True' and 'False' and then went and added names for the pins on all devices.

Snek vs TI DRV8833

The TI DRV8833 motor controller chip on the Crickit has two pins per motor -- you set one pin to ground and drive the other with a PWM signal, which pin you PWM selects the direction of the motor. This doesn't directly map to how I expected motor controllers to work in Snek. Snek expects to have one pin control direction and the other control speed.

I had to do a bit of magic to make this work, but the joy of having an interpreter between the application and the hardware is having the ability to hide these kinds of details from the application

Minor Crickit Schematics Error

The Crickit Schematics linked from the Crickit Downloads page have the DRIVE labels flipped -- DRIVEIN1 is actually hooked to PB10, DRIVEIN2 to PB11, DRIVEIN3 to PA12 and DRIVEIN4 to PA13. The Eagle schematics on github are correct; it would be nice to have the images updated as those don't require downloading proprietary software to view.


All of these bits are in the Snek git repository and should be released in the next Snek version (0.97?).

Junichi Uekawa: Wanted to read up on how TLA+ works.

Saturday 20th of April 2019 05:56:05 AM
Wanted to read up on how TLA+ works. Then I noticed that Leslie's page has lots of videos, and now I'm watching him speak. It might be the way people do it but now I can't seem to focus on a video long enough...

Urvika Gola: Attending SREcon’19, Brooklyn

Friday 19th of April 2019 06:51:35 PM

It was my first time attending the SRECON series and also one of the big step into learning about Site Reliability and Engineering. The conference had jam packed sessions on site reliability, Chaos engineering, Code reviewing culture, Incidents, SLOs and much more.

Resilience Engineering Mythbusting at #srecon
Adding a functionality is adding complexity into our systems.
Systems will fail for all sorts of reasons, always practise best practises (misnomer) one of them is NOT to deploy on a friday.

— Urvika Gola (@UrvikaGola) March 27, 2019

My notes would be redundant because there is nothing better than a comprehensive  write up about the conference by Tanya Reilly, you can read it here ->

Thanks to the organizers for putting up such an overwhelming, knowledgeable and fun conference!

Shashank Kumar: Event report for DebUtsav Delhi 2019

Friday 19th of April 2019 06:30:00 PM

The Debian India Community in Delhi along with Mozilla Delhi/NCR community organized DebUtsav Delhi 2019 on 9 and 10 March, 2019.

For those who are unware, DebUtsav is an Indian style version of a typical Mini Debian Conference.

This was the first Debian related conference to be organized in the Northern region of India. We have had Mini Debian conferences previously in Mumbai, Pune, Hyderabad and in different cities of state of Kerala. But this was the very first one in the Northern Region.

DebUtsav was made possible with the help from our sponsors

The event took place at National Institute of Public Finance and Policy (NIPFP), Delhi.

The event schedule was divided into two tracks.
  • Debian Track and FOSS Track. The Debian Track was specific for the talks or workshops related to Debian.
  • The FOSS track included talks/workshops ranging from General Free Software, Gender Diversity a Digital Security and privacy. The full schedule is present on the website

On the first day of DebUtsav

Debian Track

Although you can check the talks happened at the talks in the link to schedule. Some of the notable talks were Pirate Praveen on Debian Packaging in times of Docker and Flatpak. Abhijit Introduced us to the Debian LTS project. While Raju Devidas talked on "How to become a Debian Developer?" There were also workshops by Utkarsh Gupta and Sagar Ippalpalli on Packaging of Ruby Gems and Node Modules.

FOSS Track

Ashutosh Singh, also known as Juggernaut, talked on getting started into Open Source and Debian. The other talks in FOSS track included, a talk on Cryptography & Cryptanalysis by Ishan Malik. While Mohit Phulera talked about Setting up and using Google Vision API's. Thing to note here that both were first time speakers. DebUtsav got them started. We also had a Rust 101 workshop by Swarnim Arun. Karmanya Talked about Building Data Apps with Grames. The last talk for the day in FOSS track was by Himanshu, it had a funky name to it, SELinux: For the Asgardians

Second Day of DebUtsav

Debian Track

The first talk of the day was on an Introduction to the Hamara Linux project by Shivani Bharadwaj and Raju Devidas. They introduced the Hamara Project to the one's present as well as talked about there upcoming release of Hamara codenamed Svastik.

Later in the Debian track, we had the first ever Bug Squashing Party BSP in India. For the BSP we had 2 DD's and 2 DM's and many other active Debian contributors present. They helped people present to go through the Debian bug tracking system BTS and find bugs that they can help solve. Although we did not manage to get any bugsolved during the duration of BSP, we did managed to get some people get familiar with Debian's bug tracking eco-system, introduced them to the various teams within Debian in which they can co-ordinate to get started for solving bugs as well as contributing to Debian in general. The BSP proved to be a good starting point for Utkarsh Gupta. Within two-three weeks after the BSP he has already solved many bugs including 15 RC bugs.

FOSS track

The first talk in the FOSS track was on Digital Security and Privacy by Shashikanth.

In the second talk our DM Sruthi Chandran raised the question on How gender diverse and inclusinve is the Free Software Community?. She co-ordinated the sicussion very well and made sure that the people present during the session got involved.

Later in the Day we had talks by Pirate Praveen on Take back our data and Freedoms. Vipul Gupta talked about digging Opportunities in Open Source. Last talk which was scheduled for the foss track did not take place because of the un-availability of the speaker Ranjith Raj Vasam. Everyone got involved into the Debian BSP instead.

On the sidelines of the schedule of the second day, the podcast team of Decompiled was also present. With the efforts of the team, Raju Devidas interviewed Pirate Praveen. In the interview they talked about work done by Praveen over the years as well as his journey in Debian project.

Some statistics from DebUtsav
  • For both the days combined, around 120 people registered for attending DebUtsav, out of them around 95 attended the conference.
  • Around 10-15, unregistered attendees/on spot registrations were also present.
  • We had a total of 14 Women Attendees.

DebUtsav Delhi was lucky to have the presence of - 2 Debian Developers Pirate Praveen & Abhijith PA. - 2 Debian Maintainers Sruthi Chandran and Sagar Ippalpalli.

It is during the conversations that happened at the conference that we realized that there are a lot of first's happening in the Debian India Community.

  • Sruthi Chandran is the first Women Debian Maintainer from India, also soon to be the first women Debian Developer from India.
  • Presence of DD's proved useful for Utkarsh Gupta as he got his initial requirements for a DM fulfilled with his keys signed by the DD's present at DebUtsav. He is at the time of writing this event report, the youngest DM from India.
  • Currently Sruthi Chandran and Raju Devidas have there DD applications in process. If they get approved, we will be crossing the Double Digits of DD's from India for the first time. They are 9 now and with two more we will get to 11.
  • This was the first Debian related conference in Delhi or anywhere in Northern India.

DebUtsav Delhi proved very productive in introducing many new people to Debian project and to free software in general. Also it provided an opportunity for the Debian contributors from Delhi to meet the Debian Developers.

The conference was made possible by the continuous efforts of people from the communities of Mozilla Delhi NCR and Indian Linux User's Group Delhi. Some of the people involved in the effort could be seen on the Team section of

Thanks a lot to everyone for puting up there efforts for DebUtsav Delhi. We are looking forward to having another Debian event in Delhi and more events around India.

Dirk Eddelbuettel: tint 0.1.2: Some cleanups

Friday 19th of April 2019 03:13:00 PM

A new version 0.1.2 of the tint package is arriving at CRAN as I write this. It follows the recent 0.1.1 release which included two fabulous new vignettes featuring new font choices. The package name expands from tint is not tufte as the package offers a fresher take on the Tufte-style for html and pdf presentations.

However, with the new vignettes in 0.1.1 we now had four full-length vignettes which made the package somewhat bulky. So for this release I reorganized things a little, added two new shorter vignettes with links to the full-length vignettes but keeping the size more constrained.

Two screenshots for the first pages of the Lato and Garamond vignettes follow (and are links to a higher-resolution full-length pdf versions):

The new vignettes can also be browsed from CRAN: html variant and pdf variant. They also show the new theme borrowed with thanks and credits from ggtufte.

The full list of changes is below.

Changes in tint version 0.1.2 (2019-04-19)
  • Two new shorter html and pdf vignettes have been added (with references to the longer vignettes) reducing package size.

  • New helper function 'theme_tint' based on a similar function in package 'ggtufte'.

Courtesy of CRANberries, there is a comparison to the previous release. More information is on the tint page.

For questions or comments use the issue tracker off the GitHub repo.

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

Molly de Blanc: developer

Friday 19th of April 2019 02:43:24 PM

I became a Debian Developer towards the end of 2018. I started the process in August 2017 at DebConf in Montreal. Over the course of 17 months I wrote emails, searched the Debian wiki, and learned a lot about the project.

What’s a non-uploading Debian Developer (DD)?

A non-uploading DD is one who does not upload packages to the Debian code base. A non-uploading DD:

  • is member of the Debian project;
  • is allowed to vote about issues regarding the whole project;
  • can log in on most systems that keep Debian running; and
  • has access to the debian-private mailing list.
Why become a DD?

I had two main reasons for becoming a DD: I was told debian-private was mostly vacation notices and baby pictures. I also wanted to vote in the DPL elections.

It turns out -private contains ZERO baby pictures, and choosing who to vote for in DPL elections is hard work.

There are other reasons to become a non-uploading DD. I found that the most compelling one, from my perspective, was the authority and respect that comes along with it. When representing the project, which I have done on several occasions, it’s easier to get things done when you have a title or formal affiliation attached to your name.

I joined the A-H team with the understanding that I would become a DD — they preferred someone with official status in the project be on that team. In addition to empty promises of baby pictures, I became a DD because I wanted to take on more responsibility in the project.

There’s also a certain amount of the feeling of belonging that goes along with becoming a formal member of a project. There’s a lot to say about the value of the recognition of your peers — that they consider you a part of the team.

What do you do for Debian?

I’m on the Outreach and Anti-harassment teams.


The Outreach team coordinates Debian participation in internship programs, specifically, and currently, Google Summer of Code and Outreachy. We participate in Outreachy twice a year, and GSoC during the Northern Hemisphere summer. This mostly includes a lot of paperwork, emailing people to make sure they’re on task, and talking with the home organizations of Google and Outreachy.

Since I do not mentor any projects, this work is fairly condensed, though very demanding. It’s time sensitive, with externally imposed deadlines not of our own creation.

During a period of several weeks — and application periods overlap in March — we:

  • confirm with the Debian Project Leader funding for Outreachy;
  • put our calls for mentors;
  • assist mentors in finding co-mentors when appropriate;
  • evaluate projects, separating them into “approved” and “unapproved” categories, based on whether they meet the Debian participation criteria;
  • fill out the application forms for GSoC and Outreachy;
  • make announcements, calls for mentors, calls for projects, and calls for applicants;
  • field questions and requests from applicants;
  • keep up with mentors during the application period;
  • make formal decisions about the number of interns and who they are based on requests from mentors, available funding, and an amorphous process of reading mentor reports and trying best to judge who will not only be a successful intern, but who will be a successful mentor for a project;
  • keep up with mentors and interns during the period of the internship;
  • make sure everyone gets invoiced and paid appropriately;
  • make sure everyone has a good time; and
  • general other things as they come up.

As a total process, it’s quite consuming at times, but relaxed at other times. I would say that administering for Outreachy is an “easier” process, as the mentors are (generally, overall, usually) more experienced and self-managing. GSoC is also a much bigger program.


I could, and likely will, write a much longer post about this. I gave a talk at FOSDEM on the activities and operating procedures of the team. The quick summary is that we meet every fortnight, discuss reported incidents, and either: make recommendations to other teams about how to proceed or send personal emails to the individuals involved, pointing out inappropriate behaviors, and asking people to be more professional in their project participation.

What did your process include?

Mostly emails. A lot of emails, and back and forth with my AM (application manager). I’m sure many people say this, but my AM was great.

I went through the initial steps — deciding to apply after many, many people convinced me of the validity of my contributions to the project; getting my keysigned by an appropriate number of DDs; recruiting advocates for my application; etc.

Then came the questions and the tests. A big chunk of questions were around philosophy, policy, and procedures of the project. We covered licensing questions, the DFSG, the philosophy of user freedom, how different things within the Debian project are decided, and a bunch of other sections.

There where a technical section of my application, which covered more policy and procedure around how things are done within the Debian project. I worked on a bug (one on a piece of web site content) and submitted the edit on salsa, Debian’s instance of git. I collaborated in documents on, logged into servers using ssh, and encrypted and decrypted a number of files over the course of the procedure.

Why did it take so long?

I started my application in August of 2017, and got my welcome email December 26, 2018. I joked that I was going for the longest application period.

It took so long largely because my AM and I were both very, very busy. When faced with free time, we both frequently agreed to make the decision to instead work on our respective Debian work, rather than the application process. I think I speak for both of us when I say we agreed a lot of the other projects we were working on were more timely than my application.

At DC18, I did a personal sprint on my application, and my AM kindly did a personal sprint reviewing it. We met over IRC to handle final steps later that fall. I finished in November, days before the November keyring update, and my application was reviewed in December.

Iustin Pop: Debian DPL election 2019

Friday 19th of April 2019 11:43:00 AM

As planned for this long weekend (in Switzerland), I went and re-read the platforms, and cast my vote. Which made me very happy, because I voted in the elections for the first time in a long while…

But it didn’t start like that. The first call for nominations ended up with no (valid) nominations, and the follow-up thread was a bit depressing (high load for the DPL role, unclear expectations, etc.) For a time, it looked like the project is drifting, and some of the trolling on the list definitely didn’t help. I managed to prod a bit the thread and there was a nice reply from Lucas which seems to open the gates—the discussion livened up, and after many more meaningful mails, we ended up with 4 candidates. That’s, in my memory, a very good result.

Which means I went and read the platforms multiple times, and tried to follow the campaign as well (not so successful though), and today I cast my vote. After the initial sad result, very happy to see there are still people who are willing to invest significant time into Debian and its future. Thanks all!

Coupled with the (hopefully soon) upcoming Buster release, and the fact that I managed to update all my small packages before it, I feel much better both about Debian and my involvement with it than a year ago.

Now just looking forward to Python 2 removal :)

Giovanni Mascellani: Paris BSP and this blog

Thursday 18th of April 2019 09:00:00 AM

Hello everybody!

I've never had a blog up to today, and apparently now I do. Why? Well, it happened that there was a Debian Bug Squashing Party in Paris a few weeks ago, and I thought that it might be nice to go, meet some nice people and humbly help releasing Buster. Great news is that the Debian project is willing to reimbourse its members some of the expenses for taking part to a BSP, asking in return to communicate publicly about what you do during a BSP so that others are motivated to participate as well.

So I guessed that might be the occasion for me to start a blog, and start writing something about what I do in Debian. Here it goes!

It was my first BSP ever, and I am very happy of it. We met for a couple of days at very nice Mozilla's office in Paris (I think they are moving and we were at the old one, though). We were probably around 15 people, mostly from France, Belgium, the Netherlands and UK (which is not surprising if you look at the high-speed rail map in Europe; or any map of Europe, as a matter of facts).

The great thing of a BSP is that you have a very short loop to other developers. Since a BSP is all about getting RC bugs closed, it is useful to talk directly to Release Team members, and discuss whether they would unblock your fix or not when you are not sure. This saves a lot in terms of human bandwidth and context-switching. Also, I had the occasion to watch more experienced developers in action and learn how to tackle issues I haven't dealt with ever before, like bumping up a library SONAME.

So here is what I managed to do during the BSP, in roughly chronological order.

  • Bug #920209: that is a bug I already had written a patch for a few months ago, but the whole thing had stagnated and the patch was never uploaded. A simple ping to the maintainer was enough: an easy one!

  • Bug #917711: a FTBFS caused by failing tests, in turn caused by a broken internal interface between two libraries. I was able to cook up a patch, but I was not really sure it was the right thing, so I opened a bug upstream, to which upstream never replied. However, upstream itself wrote a similar patch a few days after, which was then up uploaded to Debian by ivodd.

  • Bug #925957: this is a bug on a package I maintain, so it was imperative to get it done. fstransform is a tool to convert a filesystem to another format (like, XFS to ext4) without having to copy all the data to another filesystem and then back (see the upstream readme for more details). It is no mistery to anyone that such an operation is inherently dangerous, so both the program and its documentation warn prominently that data loss are always an option. The idea is: if fstransform can be useful for you, use it, but never on data you cannot afford to lose (you should always have a backup of such data, anyway). So this bug was about a reproducible failure case for fstransform when it was ran with a too little copying buffer. Of course the best thing is to have a proper fix, but since the upstream bug had stalled for an year an a half without a solution, the road of fixing it myself seemed implausible, especially because I do not know fstransform's internals. So my fix was to add a warning message (that the user has to explicitly acknowledge); this fits my model for fstransform: the user is advised that things might go wrong, but if they are ok, then good for them. This was also unblocked by the Release Team. Of course it is not the ideal solution, but at least the user knows what to expect from the program, which can still be useful if you are properly warned: given that Buster should be released as soon as possible this is, to me, a reasonable compromise. The bug submitter did not agree and reopened the bug. Fortunately a few days later the upstream author managed to find the proper fix, which I then uploaded.

  • Bug #912467: a FTBFS due to an updated reverse dependencies, a relatively common between Java packages. A partial patch had already been begun by andrewsh, but was never completed. Using that as a base and drawing from the corresponding upstream patch, it was not difficult to fix the build, as the API changes were mostly cosmetic. I uploaded my patch to salsa, but not the the archive, because I would like someone else to review it. So far, it has not happened, and maybe I should have another look at it.

  • Bug #917501: a rather nasty Eisenbug, that I could not really understand during the BSP: the bug occurred when I built with sbuild, but not when I build directly in my system, so that I could not debug it. Yesterday it was finally traced back to the usage of eatmydata by sanvila, which is plausible because I also use eatmydata with sbuild (it really boosts package installation!). The bug was downgraded to normal severity, and I guess it should also be reassigned to eatmydata, since it would be eatmydata's duty to be transparent to what is happening above it.

  • Bug #915319: a FTBFS due to a bad library detection procedure by CMake. The detection of libsmbclient.h failed because CMake insisted to compile with -std=c89 (or so), while that header requires C11. Easy to patch.

  • Bug #870267: Very very easy: the bug had already been solved, but was left open.

  • Bug #877773: it was quite easy to understand what had to be done here (i.e., a SONAME bump), but I had never done it. So I asked around and jcristau showed me how to do it, including requesting a mini transition and stuff. Very instructive, and, I think, really one of the points of gathering together instead of working everybody at home.

  • Bug #905697: I ported some of the kdepimlibs libraries to libical3, so that libical2 can be dropped from the archive. The difficult part was to backtrace the corresponding upstream patches, because in the meantime the libraries had reorganized in different repositories. In the end I found this patch, and it was not difficult to make it ready for Debian.

  • One last thing not coming from a bug: Debian Buster should finally support Secure Boot, so that the computer's firmware can cryptographically validate the operating system before launching it. The Debian EFI team recently updated the Secure Boot page on the wiki with a clear description of how it works and how to enable it in Debian. I reviewed it and sent an email with my thoughts to the relevant mailing list.

So here it is, my blog and my report. Now, Debian, give me my money! :-P

Many many thanks to Mozilla for allowing us to use their spaces for the BSP, and to jcristau and olasd who organized it. Now let's try to get Buster released and maybe see you in Brazil (I'm not sure yet I will be able to come, because of [INSERT_REASONS_HERE], but I hope so).

Rapha&#235;l Hertzog: Freexian’s report about Debian Long Term Support, March 2019

Tuesday 16th of April 2019 10:23:49 AM

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In March, 204 work hours have been dispatched among 13 paid contributors. Their reports are available:

  • Abhijith PA did 14 hours (out of 14 hours allocated).
  • Adrian Bunk did 8 hours (out of 8 hours allocated).
  • Ben Hutchings did 22.5 hours (out of 20 hours allocated plus 16.5 extra hours from February, thus carrying over 14 hours to April).
  • Brian May did 10 hours (out of 10 hours allocated).
  • Chris Lamb did 18 hours (out of 18 hours allocated).
  • Emilio Pozuelo Monfort did 26 hours (out of 29.5 hours allocated + 2.5 extra hours from February, thus carrying over 6h to April).
  • Hugo Lefeuvre did 20 hours (out of 20 hours allocated).
  • Markus Koschany did 29.5 hours (out of 29.5 hours allocated).
  • Mike Gabriel did 14 hours (out of 10 hours allocated + 4 extra hours from February).
  • Ola Lundqvist did 8.5 hours (out of 8 hours allocated + 2 extra hours from last month, thus carrying over 1.5h to April).
  • Roberto C. Sanchez did 12 hours (out of 12 hours allocated).
  • Sylvain Beucler did 29.5 hours (out of 29.5 hours allocated).
  • Thorsten Alteholz did 29.5 hours (out of 29.5 hours allocated).
Evolution of the situation

In March we had one new contributor, Sylvain Beucler, though we lost Antoine Beaupré. Thankfully we also gained Jonas Meurer starting in April, yet we are are still very much looking for new contributors. Please contact Holger if you are interested to become a paid LTS contributor.

On a positive note, we are also pleased to welcome a new French university among LTS sponsors: Université Grenoble Alpes.

The security tracker currently lists 36 packages with a known CVE and the dla-needed.txt file has 39 packages needing an update.

Thanks to our sponsors

New sponsors are in bold.

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

More in Tux Machines

OpenBSD 6.5 Released With RETGUARD, OpenRSYNC

OpenBSD 6.5 was released today, about one week ahead of schedule for this security-minded BSD operating system. OpenBSD 6.5 is bringing several prominent new features including RETGUARD as its new stack protector and OpenRSYNC as its ISC-licensed in-progress replacement to rsync. OpenBSD 6.5's new RETGUARD functionality aims to be a better stack protector on x86_64 and AArch64 with instrumenting every function return with better security properties than their traditional stack protector. Read more Also: OpenBSD 6.5

Development kit showcases Cortex-A76 based Snapdragon 855

Intrinsyc has launched a 96Boards CE form-factor “Snapdragon 855 Mobile HDK” that runs Android 9 on a 7nm, octa-core Snapdragon 855 with GNSS, WiFi/BT, and optional touchscreens and cameras. Intrinsyc’s Qualcomm Snapdragon 855 Mobile Hardware Development Kit is now available for $1,149, offering a development window into Qualcomm’s powerful Snapdragon 855 SoC. The new HDK runs the latest Android 9.0 Pie release. Read more

Sad News! Scientific Linux is Being Discontinued

Scientific Linux, a distributions focused on scientists in high energy physics field, will not be developed anymore. It’s creator, Fermilab, is replacing it by CentOS in its labs. Read more

today's leftovers

  • Announcing Akademy 2019 in Milan, Italy (September 7th - 13th)
    Akademy 2019 will be held at the University of Milano-Bicocca in Milan, Italy, from Saturday the 7th to Friday the 13th of September. The conference is expected to draw hundreds of attendees from the global KDE community to discuss and plan the future of the community and its technology. Many participants from the broad Free and Open Source software community, local organizations and software companies will also attend. KDE e.V. is organizing Akademy 2019 with unixMiB — the Linux User Group of the University of Milano-Bicocca. unixMiB aims to spread Open Source philosophy among students.
  • Checking out Crunchbang++
  • Intel Iris Gallium3D Picks Up Conservative Rasterization Support
    On top of Intel's new open-source OpenGL driver seeing some hefty performance optimizations, the Iris Gallium3D driver has picked up another OpenGL extension ahead of the Mesa 19.1 branching.  Iris Gallium3D now supports INTEL_conservative_rasterization alongside the existing support in the i965 driver. INTEL_conservative_rasterization is the several year old Intel extension for seeing if all fragments are at least partially covered by a polygon rather than the default rasterization mode of including fragments with at least one sample covered by a polygon.