You are here

Agreguesi i feed

Bits from Debian: Projects and mentors for Debian's Google Summer of Code 2019 and Outreachy

Planet Debian - Dje, 03/02/2019 - 10:40pd

Debian is applying as a mentoring organization for the Google Summer of Code 2019, an internship program open to university students aged 18 and up, and will apply soon for the next round of Outreachy, an internship program for people from groups traditionally underrepresented in tech.

Please join us and help expanding Debian and mentoring new free software contributors!

If you have a project idea related to Debian and can mentor (or can coordinate the mentorship with some other Debian Developer or contributor, or within a Debian team), please add the details to the Debian GSoC2019 Projects wiki page by Tuesday, February 5 2019.

Participating in these programs has many benefits for Debian and the wider free software community. If you have questions, please come and ask us on IRC #debian-outreach or the debian-outreach mailing list.

Russ Allbery: Another new year haul

Planet Debian - Dje, 03/02/2019 - 3:38pd

The last haul I named that was technically not a new year haul since it was posted in December, so I'll use the same title again. This is a relatively small collection of random stuff, mostly picking up recommendations and award nominees that I plan on reading soon.

Kate Elliott — Cold Fire (sff)
Kate Elliott — Cold Steel (sff)
Mik Everett — Self-Published Kindling (non-fiction)
Michael D. Gordin — The Pseudoscience Wars (non-fiction)
Yoon Ha Lee — Dragon Pearl (sff)
Ruth Ozeki — A Tale for the Time Being (sff)
Marge Piercy — Woman on the Edge of Time (sff)
Kim Stanley Robinson — New York 2140 (sff)

I've already reviewed New York 2140. I have several more pre-orders that will be delivered this month, so still safely acquiring books faster than I'm reading them. It's all to support authors!

Tim Janik: Replace libtool, turn full GNU Make?

Planet GNOME - Dje, 03/02/2019 - 3:02pd
Replace libtool, turn full GNU Make? Every once in a while I start pondering ways to get rid of the slowness and overwhelming complexity of the autotools machinery, in particular autoconf and libtool. GNU Make has been a great companion for 20 years, and automake helps with some of the complexity in…

Steinar H. Gunderson: FOSDEM 2019, Saturday

Planet Debian - Sht, 02/02/2019 - 11:22md

Got lost in the wet slush of Brussels. Got to ULB. Watched seven talks in whole or partially, some good and some not so good. (Six more that I wanted to see, but couldn't due to overfilled rooms, scheduling conflicts or cancellations.) Marvelled at the Wi-Fi as usual (although n-m is slow to connect to v6-only networks, it seems). Had my own talk. Met people in the hallway track. Charged the laptop a bit in the cafeteria; should get a new internal battery for next year so that it lasts all day. Insane amount of people in the hallways as always. Tired. Going back tomorrow.

FOSDEM continues to be among the top free software conferences. But I would love some better way of finding talks than “read through this list of 750+ talks linearly, except ignore the blockchain devroom”.

Steinar H. Gunderson: Futatabi: Multi-camera instant replay with slow motion

Planet Debian - Sht, 02/02/2019 - 11:14md

I've launched Futatabi, my slow motion software! Actually, the source code has been out as part of Nageru for a few weeks, so it's in Debian buster and all, but there's been a dash the last few days to get all the documentation and such in place.

The FOSDEM talk went well—the turnout wasn't huge (about fifty people in person; I don't know the stream numbers), but I guess it's a fairly narrow topic. Feedback was overall good, and the questions were well thought-out. Thanks to everyone who came, and especially those who asked questions! I had planned for 20 minutes (with demo, but without questions) and ended up in 18, so that's fairly good. I forgot only minor details, and reached my goal of zero bullet points. The recording will be out as soon as I can get my hands on it, although I do suspect it's been downconverted from 60 to 50 and then further to 25 fps, which will naturally kill the smoothness of the interpolated video.

Relevant stuff:

Jonathan Dowland: glitched Amiga video

Planet Debian - Sht, 02/02/2019 - 8:30md

This is the fifth part in a series of blog posts. The previous post was Amiga/Gotek boot test.

Glitchy component-video out

As I was planning out my next Gotek-floppy-adaptor experiment, disaster struck: the video out from my Amiga had become terribly distorted, in a delightfully Rob Sheridan fashion, sufficiently so that it was impossible to operate the machine.

Reading around, the most likely explanation seemed to be a blown capacitor. These devices are nearly 30 years old, and blown capacitors are a common problem. If it were in the Amiga, then the advice is to replace all the capacitors on the mainboard. This is something that can be done by an amateur enthusiast with some soldering skills. I'm too much of a beginner with soldering to attempt something like this. I was recommended a company in Aberystwyth called Mutant Caterpillar who do a full recap and repair service for £60 which seems very reasonable.

Philips CRT

Luckily, the blown capacitor (if that's what it was) wasn't in the Amiga, but in the A520 video adaptor. I dug my old Philips CRT monitor out of the loft and connected it directly to the Amiga and the picture was perfect. I had been hoping to avoid fetching it down, as I don't have enough space on my desk to leave it in situ, and instead must lug it over whenever I've found a spare minute to play with the Amiga. But it's probably not worth repairing the A520 (or sourcing a replacement) and the upshot is the picture via the RGB out is much clearer.

As I write this, I'm in a hotel room recovering after my first day at FOSDEM 2019, my first FOSDEM conference. There was a Retrocomputing devroom this year that looked really interesting but I was fully booked into the Java room all day today. (And I don't see mention of Amigas in any of the abstracts)

Shaun McCance: What’s New in Mallard 1.1, Part 2

Planet GNOME - Sht, 02/02/2019 - 3:50md

We’ve just released Mallard 1.1. Let’s take a look at what’s new. All of these features are already supported in tools like Yelp and Pintail.

This is part 2 in a 3-part series. Read part 1.

Table header cells

MEP-0012: Table Header Cells

Mallard mostly follows the HTML table model, with some simplifications of how things are styled. One element that was notably absent from Mallard tables, however, was the th element. The th element allows you to mark a cell as being a header for a row or column, even if it’s not in a thead element (as row headers wouldn’t be).

This was a pretty obvious and easy addition. I was so confident Mallard 1.1 would get a th element that I added a Ducktype shorthand for it well before Mallard 1.1 was released.

Custom roles for links

MEP-0003: The role Attribute on the links Element

This one’s pretty exciting, though a bit advanced. In Mallard, links can have roles which affect things like link text. These work with the multiple informational titles you can provide for a page or section. So, for example, if your language needs to do declensions for different parts of speech, you could write your links like this:

<link role="subject" xref="useful"/> is really useful. For useful info, check out <link role="object" xref="useful"/>.

Then in, you would have something like this:

<info> <title type="link" role="subject">Subject Title</title> <title type="link" role="object">Object Title</title> </info> <title>Normal Title</title>

Mallard will pick up the right title. More often, however, you don’t write your links inline, but instead you do automatic linking with informational links and possibly the links element. What happens then?

In Mallard 1.0, different types of automatic links have implicit roles. So the topic links on a guide page will automatically use the "topic" role to select link text from titles, for example. There are implicit roles for topic, guide, seealso, and series links.

So far, so good. But what if you want to use different titles for link text when coming from different guide pages with different topic link styles? This is where the new Mallard 1.1 feature comes in. In Mallard 1.1, you can add a role attribute to a links element to set the primary role to use for all the links it generates. The implicit role for that links type will still be used as a secondary role.

<links type="topic" role="fancyrole"/> Boring schema changes

In Mallard 1.0, sections were required to have id. There were a couple of reasons I made that decision, but in the end it turned out to annoy more people than it helped. So in Mallard 1.1, section IDs are optional.

We also made a perfectly boring schema change to make it easier for the Cache Files schema to extend the Mallard schema. (There’s also a new Cache Files 1.1 release.) Although RELAX NG is a mostly great schema language for extensible schema design, it does take some effort to design schemas that can be extended. Mallard got a lot of things right, but sometimes we find something to improve.

And more

That’s it for part 2. If you haven’t already, go read part 1, and keep your eye out for part 3. For more information, you can read the Mallard 1.1 changes, the Mallard 1.1 enhancement proposals, and the 1.1 milestone issues.

Want to get involved? Take a look at our 1.2 milestone issues. Or check out the Documentation issue label and help us write tutorials. Keep in touch on the Mallard mailing list.

Bits from Debian: Help test initial support for Secure Boot

Planet Debian - Sht, 02/02/2019 - 11:00pd

The Debian Installer team is happy to report that the Buster Alpha 5 release of the installer includes some initial support for UEFI Secure Boot (SB) in Debian's installation media.

This support is not yet complete, and we would like to request some help! Please read on for more context and instructions to help us get better coverage and support.

On amd64 machines, by default the Debian installer will now boot (and install) a signed version of the shim package as the first stage boot loader. Shim is the core package in a signed Linux boot chain on Intel-compatible PCs. It is responsible for validating signatures on further pieces of the boot process (Grub and the Linux kernel), allowing for verification of those pieces. Each of those pieces will be signed by a Debian production signing key that is baked into the shim binary itself.

However, for safety during the development phase of Debian's SB support, we have only been using a temporary test key to sign our Grub and Linux packages. If we made a mistake with key management or trust path verification during this development, this would save us from having to revoke the production key. We plan on switching to the production key soon.

Due to the use of the test key so far, out of the box Debian will not yet install or run with SB enabled; Shim will not validate signatures with the test key and will stop, reporting the problem. This is correct and useful behaviour!

Thus far, Debian users have needed to disable SB before installation to make things work. From now on, with SB disabled, installation and use should work just the same as previously. Shim simply chain-loads grub and continues through the boot chain without checking signatures.

It is possible to enrol more keys on a SB system so that shim will recognise and allow other signatures, and this is how we have been able to test the rest of the boot chain. We now invite more users to give us valuable test coverage on a wider variety of hardware by enrolling our Debian test key and running with SB enabled.

If you want to help us test our Secure Boot support, please follow the instructions in the Debian wiki and provide feedback.

With help from users, we expect to be able to ship fully-working and tested UEFI Secure Boot in an upcoming Debian Installer release and in the main Buster release itself.

Dirk Eddelbuettel: The Incomplete Book of Running: A Short Review

Planet Debian - Sht, 02/02/2019 - 6:48pd

Peter Sagal’s The Incomplete Book of Running has been my enigma for several weeks now. As a connection, Peter and I have at most one degree of separation: a common fellow runner friend and neighbor who, sadly, long departed to Colorodo (hi Russ!). So we’re quasi-neighbors. But he is famous, I am not, but I follow him on social media.

So as “just another runner”, I had been treated to a constant trickling of content about the book. And I had (in vain) hoped my family would get me the book for Xmas, but no such luck. Hence I ordered a copy. And then Amazon, mankind’s paragon of inventory management and shipment, was seemingly out of it for weeks – so that my copy finally came today all the way from England (!!) even though Sagal and I live a few miles apart, and he and I run similar neighborhoud routes, run (or ran) the same track for Tuesday morning speedwork – and as I noticed while devouring the book, share the same obsession for FIRST I tried to install onto my running pals a decade ago. We also ran the same initial Boston Marathon in 2007, ran many similar marathons (Boston, NY, Philly) even at the same time. But bastard that he his not only owns both my PRs at a half (by about two minutes) and full (by about four minutes) marathon – but he also knows how to write!

This is a great book about running, life, and living around Oak Park. As its focus, the reflections about running are good, sometimes even profound, often funny, and show a writer’s genuine talent in putting words around something that is otherwise hard to describe. Particularly for caustic people such as long-distance runners.

The book was a great pleasure to read—and possibly only the second book in a decade or longer that I “inhaled” cover to cover in one sitting this evening as it was just the right content on a Friday night after a long work week. This was a fun and entertaining yet profound read. I really enjoyed his meditation on the process and journey that got him to his PR – when it was time for mine by now over ten years ago it came after a (now surreal seeming) sequence of running Boston, Chicago, New York in one year and London and Berlin the next. And somehow by the time I got to Berlin I was both well trained, and in a good and relaxed mental shape so that things came together for me that day. (I also got lucky as circumstances were favourable: that was one of the many recent years in which a marathon record was broken in Berlin.) And as Sagal describes really well throughout the book, running is a process and a practical philosophy and an out and occassional meditation. But there is much more in the book so go and read it.

One minor correction: It is Pfeiffer with a P before the f for Michelle’s family name as every viewer of the Baker Boys should know.

Great book. Recommended to runners and non-runners alike.

Petter Reinholdtsen: Websocket from Kraken in Valutakrambod

Planet Debian - Pre, 01/02/2019 - 10:25md

Yesterday, the Kraken virtual currency exchange announced their Websocket service, providing a stream of exchange updates to its clients. Getting updated rates quickly is a good idea, so I used their API documentation and added Websocket support to the Kraken service in Valutakrambod today. The python library can now get updates from Kraken several times per second, instead of every time the information is polled from the REST API.

If this sound interesting to you, the code for valutakrambod is available from github. Here is example output from the example client displaying rates in a curses view:

Name Pair Bid Ask Spr Ftcd Age BitcoinsNorway BTCEUR 2959.2800 3021.0500 2.0% 36 nan nan Bitfinex BTCEUR 3087.9000 3088.0000 0.0% 36 37 nan Bitmynt BTCEUR 3001.8700 3135.4600 4.3% 36 52 nan Bitpay BTCEUR 3003.8659 nan nan% 35 nan nan Bitstamp BTCEUR 3008.0000 3010.2300 0.1% 0 1 1 Bl3p BTCEUR 3000.6700 3010.9300 0.3% 1 nan nan Coinbase BTCEUR 2992.1800 3023.2500 1.0% 34 nan nan Kraken+BTCEUR 3005.7000 3006.6000 0.0% 0 1 0 Paymium BTCEUR 2940.0100 2993.4400 1.8% 0 2688 nan BitcoinsNorway BTCNOK 29000.0000 29360.7400 1.2% 36 nan nan Bitmynt BTCNOK 29115.6400 29720.7500 2.0% 36 52 nan Bitpay BTCNOK 29029.2512 nan nan% 36 nan nan Coinbase BTCNOK 28927.6000 29218.5900 1.0% 35 nan nan MiraiEx BTCNOK 29097.7000 29741.4200 2.2% 36 nan nan BitcoinsNorway BTCUSD 3385.4200 3456.0900 2.0% 36 nan nan Bitfinex BTCUSD 3538.5000 3538.6000 0.0% 36 45 nan Bitpay BTCUSD 3443.4600 nan nan% 34 nan nan Bitstamp BTCUSD 3443.0100 3445.0500 0.1% 0 2 1 Coinbase BTCUSD 3428.1600 3462.6300 1.0% 33 nan nan Gemini BTCUSD 3445.8800 3445.8900 0.0% 36 326 nan Hitbtc BTCUSD 3473.4700 3473.0700 -0.0% 0 0 0 Kraken+BTCUSD 3444.4000 3445.6000 0.0% 0 1 0 Exchangerates EURNOK 9.6685 9.6685 0.0% 36 22226 nan Norgesbank EURNOK 9.6685 9.6685 0.0% 36 22226 nan Bitstamp EURUSD 1.1440 1.1462 0.2% 0 1 2 Exchangerates EURUSD 1.1471 1.1471 0.0% 36 22226 nan BitcoinsNorway LTCEUR 1.0009 22.6538 95.6% 35 nan nan BitcoinsNorway LTCNOK 259.0900 264.9300 2.2% 35 nan nan BitcoinsNorway LTCUSD 0.0000 29.0000 100.0% 35 nan nan Norgesbank USDNOK 8.4286 8.4286 0.0% 36 22226 nan

Yes, I notice the strange negative spread on Hitbtc. I've seen the same on Kraken. Another strange observation is that Kraken some times announce trade orders a fraction of a second in the future. I really wonder what is going on there.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Wouter Verhelst: Visum!

Planet Debian - Pre, 01/02/2019 - 10:22md

A year and a half ago, we made a decision: I was going to move.

About a year ago, I decided that getting this done without professional help was not a very good idea and would take forever, so I got set up with a lawyer and had her guide me through the process.

After lots of juggling with bureaucracies, some unfortunate delays, and some repeats of things I had already done before, I dropped off a 1 cm thick file of paperwork at the consulate a few weeks ago

Today, I went back there to fetch my passport, containing the visum.

Tomorrow, FOSDEM starts. After that, I will be moving to a different continent!

Hans de Goede: i915.fastboot=1 is now enabled in Rawhide / F30 for Skylake and newer

Planet GNOME - Pre, 01/02/2019 - 4:27md
i've just landed a big milestone for the Flicker Free Boot work I'm doing for Fedors 30. Starting with todays rawhide kernel build, version 5.0.0-0.rc4.git3.1, the fastboot option for the i915 Intel display driver is enabled by default on systems with a Skylake CPU/iGPU and newer, as well as on Valleyview and Cherryview (Bay- and Cherry-Trail) systems.

This means that the last modeset / flicker during boot of UEFI systems using the integrated Intel GPU for display output is now gone.

Hubert Figuiere: Music, Flathub and Qt

Planet GNOME - Pre, 01/02/2019 - 6:53pd

I have started reading recently about music theory and such, with the purpose to try to learn music (again). This lead me to look at music software, and what we have on Linux.

I found a tutorial by Ted Felix on Linux and MIDI

I quickly realised that trying these apps on my Dell XPS 13 was really an adventure, mostly because of HiDPI (the high DPI screen that the PS 13 has). Lot of the applications found on Fedora, by default, don't support high DPI and a thus quasi impossible to use out of the box. Some of it is fixable easily, some of it with a bit more effort and some, we need to try harder.

Almost all the apps I have tried used Qt. With Qt5 the fix is easy, albeit not necessarily user friendly. Just set the QT_AUTO_SCREEN_SCALE_FACTOR environment variable to 1 as specified in Qt HiDPI support documentation. There is also an API to set the attribute on the QCoreApplication object. There must be a good reason why this opt-in and not opt-out.

This is the case of Muse3 (aka muse sequence not to be confused with MuseScore which work out of the box, at east from Flathub), and Rosegarden.

LMMS and Hydrogen on the other hand are using Qt4 on Fedora 29. The good news? They both have been ported to Qt5, so it is just a matter of building these newer versions. After doing so, they still need the workaround described above.

This is where Flathub comes into play: make them available on Flathub, where we can set that environment variable for the runtime.

In the end, I have Hydrogen available on Flathub, the three others in queue for Flathub, and all have had patches submitted (with Muse3 and Rosegarden already merged upstream).

Now what other cool Free Software music oriented application exist?

Paul Wise: FLOSS Activities January 2019

Planet Debian - Pre, 01/02/2019 - 6:23pd
Changes Issues Review Administration
  • Debian: merge patch, install dependencies, fix LDAP server, answer keys question, check build hardware differences, remove references to dead systems
  • Debian wiki: re-enable old account unblacklist IP addresses, whitelist email addresses, ping accounts with bouncing email, investigate password reset issue
  • Debian derivatives census: rerun patch generation to fix broken files
  • Initiate discussion about the status of hLinux
  • Respond to queries from the Debian derivatives census Outreachy project intern
  • Respond to queries from Debian users and developers on the mailing lists and IRC

The purple-discord work was sponsored by my employer. All other work was done on a volunteer basis.

Louis-Philippe Véronneau: DebConf Videoteam sprint @ FOSDEM report

Planet Debian - Pre, 01/02/2019 - 6:00pd

For the past week, the DebConf Videoteam has been hard at work, sprinting in Diegem, Belgium. We've had a lot of fun, but were also able to improve a lot of things.

Raspberry Pi Hacking

Jonathan and Andy eventually want to set up Raspberry Pi 3B+ with screens on the top of our cameras to act as tally lights and enable the video directors to send messages to the camera operators that way. No more sleeping on the switch! To make this possible, Jonathan has been working on adding a custom drop-down menu near the camera preview in voctogui.

Since we don't want to have to jump through hoops to image those boards, Jonathan worked on booting a pure Debian image on the Pi 3B+. He's been able to load an Initramfs and a full mainline kernel on it, but ran into trouble getting the network up because of USB driver problems.

The program Jonathan has been writing to display messages on the Raspberry Pi screens is called toetally. It's still in pre-alpha, but check it out nonetheless!


Tzafrir worked on getting his Opsis board up to date with the latest version of HDMI2USB, the firmware we are using on those boards to capture HDMI inputs.

He's been mostly successful in getting it to work, but has been having hardware problems with his Minnowboard Turbot, the SBC we are using to control the Opsis.

Documenting our streaming setup

Nicolas completely rebuilt our streaming setup for DebConf17, migrating from icecast2 to something based on libnginx-mod-rtmp, as icecast2 kept crashing.

It has been working very well since then, but sadly Nicolas hadn't had time to document how it works properly.

This is not the case anymore! You can now check out our streaming documentation.

Nicolas also included our ansible role documentation to the main ansible documentation generated in sphinx.

Hardware Hacking

We recently bought a new audio kit to replace the one we had. It was getting pretty old and was basically crumbling away. At the last mini-DebConf we did in Hamburg, we even had to borrow a kit from the CCC VOC.

Before the sprint, Andy and Kyle worked on listing what hardware we needed to buy and Nicolas had the gear shipped to Paris. Sadly, we only got one of the four wireless receivers we bought, as the other ones were backorder.

During the sprint, Nicolas and Andy worked hard on racking the gear in our new front of stage rack and Andy did a soldering job in our Opsis case to be able to power the Opsis, the turbot and the network switch all at once.

You can find more in depths details about our new audio system and the racking process on Andy's blog.

Thanks to HSBXL for lending us tools to hack sheet metal!


With the phasing out of Alioth, our old git-annex repository was not accessible anymore (Salsa doesn't support git-annex). Judit, Tzafir & Stefano thus worked on migrating it to git LFS.

The plan is to use this new DebConf share repository to host pictures taken by attendees.

As we are trying to migrate away from DebConf hardware, Stefano also wrote a scraper for DebConf Gallery and plans to move the pictures hosted there to DebConf share.

He still plans to modify Wafer to make it easy for speakers to publish their slides on the DebConf website, but if it comes to it, we'll also be able to use that git LFS repository to host slides too.

Playing with the Fomu

Giovanni Mascellani came-by during the week to learn more about the way our setup works. He helped with a bunch of small fixes left and right and we had a very good time!

By pure chance, Stefano came back from LCA with a bunch of Fomu boards (tiny open hardware, open toolchain FPGA boards that fits in your USB port) to give out for FOSDEM and Giovanni managed to flash one of them with a Raspberry Pi. Very neat!

USB installer for our ansible playbooks

Although we mainly install new machines using PXE boot from our network gateway, we sometime need to bootstrap other machines without it. We normally did that by installing Debian manually on a machine and then running ansible on it.

We now have an easy to use USB installer! You can run a simple script that builds a preseeded Debian image and flashes it on a USB key. Once Debian is installed, the machine reboots and runs ansible automatically.

We previously had something similar, but Carl Karsten rebuilt the whole thing and made it easier to use. Louis-Philippe updated the documentation.

Soldering USB ports

When we packed one of our Opsis boards after DebConf18 in Taiwan, one of the USB ports got mangled. Nicolas spent a whole day trying to resolder it back, but finally ended up cutting it from the board and replaced it by a cable attached to a USB header.

systemd in Docker in Gitlab CI

Louis-Philippe worked a large part of the week trying to get systemd to run in Docker in Gitlab CI. We need that to test our ansible modules properly.

Having worked on this previously, this week he tried to build a docker container that ran both systemd as PID 1 and an OpenSSH Server and tried to run this image as a service.

The idea behind this is that since there is no way to run systemd as PID 1 in Gitlab CI, maybe it could be achieved in a service. Ansible roles could then be tested by connecting via ssh.

Sadly, this also proved impossible. Even when using a privileged runner, docker containers need to have volumes like /sys/fs/cgroup explicitly mounted for systemd to run and there is no way to achieve this with a service.

To better test our ansible roles, he added more unit tests that skip the systemd handlers.

DebConf19 preparations

Paulo and Adriana flew in from Brazil to attend the video sprint. With the help of other DebConf people present, they ironed out a few problems and worked some more on planning for DebConf19.

Fixing our example inventory in ansible

Stefano fixed the default ansible inventory that ships with our playbooks. We don't use that inventory very often, as we have a more complete one for our production setup.

It is used by people that want to test our setup though, so that means others will be able to replicate our work more easily.

Thank you!

This sprint would not have been possible without the support of the amazing Jasper Nuyens of Linux Belgium, who very graciously lent us a place to hack and sleep for the week. Jasper also bought us delicious pizza on Thursday night, a gesture everyone highly appreciated.

We also extend our thanks to the Debian Project for giving us a budget for the sprint.

Thank you!

Joaquim Rocha: Going to FOSDEM 2019

Planet GNOME - Enj, 31/01/2019 - 11:37md

It’s that time of the year again! Tomorrow I am flying to Brussels for what will be my 11th FOSDEM!

I will be carrying the Hack Computer (+ cool stickers) with me and I am happy to give a quick demo and talk about this new project or Endless with anyone interested.

Such a mean machine!

Looking forward to meeting everybody!

Jonathan McDowell: IoT Security, DRM and user freedom

Planet Debian - Enj, 31/01/2019 - 7:39md

IoT security is a hot topic these days, and rightly so. Matthew Garrett has spent a lot of time reverse engineering various IoT light bulbs to determine how secure they are, with depressing results. So when I saw Bruce Schneier’s recent post Security Analysis of the LIFX Smart Light Bulb which started with “it’s terrible” I thought this was more of the same. Except it’s not. The original article is Pwn the LIFX Mini white (and the author has at least a couple of other device teardowns in the same vein).

What these articles are concerned with is not the usual protocol level security which Matthew investigates. Instead they’re about physical device security. In particular the points raised are:

  • Wi-Fi details are stored in the clear on the device
  • The device does not have secure boot or flash encryption enabled
  • The private key for the device can be retrieved easily

All of these boil down to the same root cause; without effective DRM there is no way to protect devices from physical attacks. That can be as simple as having only internal flash and being able to blow a set of EFUSEs to prevent readout/debug interfaces functioning, or it can be a full built in boot ROM with cryptographic verification of an image pulled in from external flash (potentially encrypted) and the building up of a chain of trust. I see 2 main problems with this.

Firstly, getting security like this right is hard. Games console manufacturers are constantly trying to protect their devices against unauthorised code running, and while they seem to be getting better it’s taken quite a number of mistakes to get there. They have a much bigger financial imperative to get this right, as console DRM attacks are frequently used for piracy. An IoT vendor could end up adding significant cost to their BoM if they have to buy a more advanced chip to be able to do the appropriate end-to-end flash encryption required. (The LIFX is using the ESP32, which does have some of these features that are not present in the more basic (and cheaper) ESP8266. I’ve no idea if anyone has done a full analysis of the ESP32 security.)

Secondly, locking devices down in this way has a big impact on user freedom. It should come as no surprise that this is my primary concern, as I believe it is detrimental to the end user in multiple ways.

  • There’s a lot of poor security in the IoT protocol arena. If it’s not possible for anyone other than the manufacturer to update a device, or retrieve the firmware image to examine how a device operates, security will suffer.
  • Updates being locked down to the manufacturer leaves the user open to the prospect of forced obsolescence when the manufacturer decides they will no longer support the device, or goes out of business (assuming a device that has some sort of cloud component).
  • Part of the appeal of a lot of the current IoT devices is the fact they can be repurposed for uses beyond what the manufacturer imagined. Just look at the Sonoff-Tasmota project - this excellent 3rd party support is one of the main reasons I purchased several Sonoff devices. If I hadn’t been able to replace the firmware they wouldn’t have been of interest to me or countless other people who’ve purchased them.

There are ways to enable user freedom while still having a locked down setup by default, but they’re hard to do in the embedded IoT space (generally no hardware infrastructure that allows plugging in a USB stick with a new root certificate on it and enrolling it like EFI Secure Boot), and add significant cost and complexity to devices that are meant to be cheap and ubiquitous. I see the validity in raising concerns about discarded devices leaking Wi-Fi credentials, but it’s something any device you connect to your Wi-Fi is potentially going to do. That means your laptop, your phone and all the random other devices you allow to connect to your Wi-Fi. It’s something we need to be aware of generally, rather than singling some cheap IoT light bulbs out.

The lack of physical security for the firmware image or device credentials is not so worrying to me. A surveillance device in a light bulb is not a new concept; in fact the added complexity of an IoT bulb makes it easier to justify the complex circuitry being present. If it requires physical access to be able to subvert the device like this that’s significantly less worrying than being able to do so remotely.

Don’t get me wrong, I love a good device teardown, and I think there’s an interesting discussion that’s already underway about how to improve physical device security without restricting user freedom. I just don’t think this is the major failure that some commenters are suggesting.

Carlos Garnacho: A mutter and gnome-shell update

Planet GNOME - Enj, 31/01/2019 - 6:05md

Some personal highlights:

Emoji OSK

The reworked OSK was featured a couple of cycles ago, but a notable thing that was still missing from the design reference was emoji input.

No more, sitting in a branch as of yet:

This UI feeds from the same emoji list than GtkEmojiChooser, and applies the same categorization/grouping, all the additional variants to an emoji are available as a popover. There’s also a (less catchy) keypad UI in place, ultimately hooked to applications through the GtkInputPurpose.

I do expect this to be in place for 3.32 for the Wayland session.

X11 vs Wayland

Ever since the wayland work started on mutter, there’s been ideas and talks about how mutter “core” should become detached of X11 code. It has been a long and slow process, every design decision has been directed towards this goal, we leaped forward on 2017 GSOC, and eg. Georges sums up some of his own recent work in this area.

For me it started with a “Hey, I think we are not that far off” comment in #gnome-shell earlier this cycle. Famous last words. After rewriting several, many, seemingly unrelated subsystems, and shuffling things here and there, and there we are to a point where gnome-shell might run with --no-x11 set. A little push more and we will be able to launch mutter as a pure wayland compositor that just spawns Xwayland on demand.

What’s after that? It’s certainly an important milestone but by no means we are done here. Also, gnome-settings-daemon consists for the most part X11 clients, which spoils the fun by requiring Xwayland very early in a real session, guess what’s next!

At the moment about 80% of the patches have been merged. I cannot assure at this point will all be in place for 3.32, but 3.34 most surely. But here’s a small yet extreme proof of work:


It’s been nice to see some of the performance improvements I did last cycle being finally merged. Some notable ones, like that one that stopped triggering full surface redraws on every surface invalidation. Also managed to get some blocking operations out of the main loop, which should fix many of the seemingly random stalls some people were seeing.

Those are already in 3.31.x, with many other nice fixes in this area from Georges, Daniel Van Vugt et al.


As a minor note, I will be attending Fosdem and the GTK+ Hackfest happening right after. Feel free to say hi or find Wally, whatever comes first.

Georges Basile Stavracas Neto: GNOME Shell and Mutter: better, faster, cleaner

Planet GNOME - Enj, 31/01/2019 - 2:53md

The very first update in the series is about GNOME Shell and Mutter. I’ve been increasingly involved with the development of those two core components of GNOME, and recently this has been the focus of my development time.

Fortunately, Endless allows me to use part of my work time to improve it. Naturally, I prioritize my upstream work considering what will impact Endless OS the most. So far, that lead to a series of very nice improvements to Mutter and GNOME Shell.


Most of my work time dedicated to GNOME Shell was oriented to performance and cleanup. At Endless, we have a modified GNOME Shell that constantly needs to be rebased. Since I’m taking care of these rebases now, it makes sense for me to also make myself familiar with the vanilla GNOME Shell codebase.


I’ll start with the work that makes me the proudest: removing the Shell.GenericContainer class.

First, a bit of history.

There was a time when GJS, the JavaScript engine that GNOME Shell is based on, did not support subclassing GObjects and overriding virtual functions. We could only instantiate GObject-based classes, and subclass them, all thanks to GObject-Introspection, but not override their virtual functions. This made, for example, implementing ClutterContent in JavaScript impossible.

For that reason, GNOME Shell developers created ShellGenericContainer: an actor that sends signals for various virtual functions. Because GJS supports signals, that worked well.

There are a few problems with that approach though:

  • Signals are slow, and should not be used on hot paths like layouting or rendering;
  • Going in and out of JavaScript territory is expensive;
  • It makes the JavaScript code slightly more complicated;

Thanks to the fantastic work by Jasper St. Pierre, GJS now supports overriding virtual functions. And that made Shell.GenericContainer obsolete. So I spent quite some time untangling it from GNOME Shell, and results were positive:

In general, running GNOME Shell without Shell.GenericContainer (blue line) led to more stable framerates compared to the current state (red line).

This is now merged and will be available with GNOME Shell 3.32, to be released on March 2019.

Improvements to the texture cache

After various investigations, another potential improvement that showed up was on StTextureCache. Textures (icons, image files, etc) are cached in GNOME Shell by StTextureCache, and that happened by keeping a ClutterTexture object alive.

That turned out to be a problem.

ClutterTexture is deprecated. Clutter has a new interface for drawing the contents of an actor: ClutterContent. It does not necessarily make the code faster, but it allows different actors to share a single ClutterContent without having to override ClutterActor.paint(). In other words, it is a nice and sane abstraction layer to control what an actor is drawing.

So I went ahead and wiped out ClutterTexture from StTextureCache. Then wiped it out entirely from GNOME Shell.

Unexpectedly, it made a small but noticeable difference! Icons are now slightly faster to load, but the most visible impact was in the startup animation.


I did not know how fun and exciting compositors could be. It definitely is a new passion of mine, working on Mutter! So much has happened that it’ll be hard to summarize.

Goodbye, Autotools

During last year’s GUADEC, Jonas Ådahl worked on a Meson port of Mutter. After a series of reviews, and a few follow-up fixes, it reached almost complete feature parity with Autotools – the only exception being installed tests.

So I went ahead and added installed tests to the Meson build too.

And also removed Autotools.

Naturally, builds are much faster now. Saving us a few minutes per day.

Wayland vs X11

Another area that was interesting to work on was untangling X11-specific code from Wayland, and vice-versa. There are a handful of developers working on that already, and I had my fair share in better splitting X11 and Wayland code paths in Mutter.

Specifically, I worked on splitting X11-specific code from MetaWindowActor into subclasses. Mutter already handles different surfaces correctly; on X11 sessions, all surfaces are MetaSurfaceActorX11, and under Wayland, MetaSurfaceActorWayland.

MetaWindowActor has now the same split: Wayland windows have a MetaWindowActorWayland associated, while X11 windows have MetaWindowActorX11.

Interestingly, XWayland windows are X11 windows with a Wayland surface. You can check that using GNOME Shell’s Looking Glass:

Example of a Xwayland window; it has a MetaSurfaceActorWayland surface, and a MetaWindowActorX11 actor associated.

There’s a lot more happening in this front, but I’ll spare the words for now. You’ll hear more about it in the future (and not necessarily from me).

CPU-side picking

More recently, I’ve been experimenting with the Cogl journal and ironing out a few bugs that are preventing a completely CPU-side picking implementation.

Picking is the process to figure out which element is beneath the cursor. There are two big approaches: geometry-based, and color-based. On games, the latter is the usual approach: each object in the scene is drawn with a plain color, and the final image is read to find out the color beneath a point. Geometry-based picking is what browsers usually do, and it’s basically math around rectangles.

Clutter uses color-based picking, but has a nice feature around that: a journal that tracks drawing operations and, under some conditions, hits an optimized path and does geometry-based picking. This is interesting for Mutter and GNOME Shell because it avoids sending draw operations to the GPU unecessarily when picking, reducing resource usage.

Unfortunately, due to various bugs and implementation details, we do not hit this optimization, causing GPU commands to be issued when they could be avoided.

Figuring out these bugs is what I’ve been experimenting with lately.



There’s much more that happened, so I will probably do a part 2 of this article soon. But those are big points already, and the post is becoming lengthy.

Many of these experiments and investigations already landed, and will be available with GNOME 3.32. This is all valuable work that is partially sponsored by my employer, Endless, and I’m happy to keep working on it!

Andy Simpkins: Debconf Video Team Sprint – Day 3

Planet Debian - Enj, 31/01/2019 - 2:31md

Today has mostly been spent in conversation.

Jonathan has started to scratch an itch that I share, we need a better tally light solution.  When we were using DV switch we had a simple tally light system using (iirc DTR on a) serial port to turn on or off an LED.  This was fine because there was always a PC available at each camera running DVCapture.

Since the move to Voctomix, each camera no longer has it’s own dedicated PC.  Instead we have long 50R co-ax cables (remember the days of cheaper-net 10 base-2?) going directly to a PC running VoctoCore….  Yes we still use a serial port to drive a tally light (all be it these days from a USB to serial converter) but we could do so much better.

Whilst an LED is good to indicate to a presenter which camera(s) are currently active, but wouldn’t it be good to be able to interact with the camera operator some way as well?

Sure we can dedicate an LED or two for this task, but given how cheep SPI displays are these days why not go for a small display instead?

Now the director can send camera operators canned messages (or free text if they have the time to type one).  The camera operator can easily see what the director would like them to do – and they can acknowledge the instruction.  of cause they can also prod the director as well  – two way comms and all :-)

Our tally light / display can be mounted to our cameras using either a flash shoe (shame we can’t grab power this way) or from a tripod screw, both are available on our cameras.

We could choose to hang all this behind a really cheep SBC (think Arduino) but given the cost and that we only need a few something like a RaspberryPi is perhaps a better option.  We could even add USB headsets and mumble if we later want to have full talk-back…

We spent some time fleshing out the requirements for and the road map of the ToeTally project.

I have ordered myself a little SPI display and a case from ebay (Jonathan already has something similar – there are many such things on Ebay and other sites).  This should be plenty to get the project up and running.

/me has found another rabbit hole to spend my time – I may even make some software commits!



Subscribe to AlbLinux agreguesi