Every now and again I get this problem where Firefox won’t render text correctly (on a Debian/stretch system). Most websites are fine, but the odd site just shows up with blanks where the text should be. Initially I thought it was NoScript, but turning that off didn’t help. Daniel Silverstone gave me a pointer today that the pages in question were using webfonts, and that provided enough information to dig deeper. The sites in question were using Cantarell, via:
src: local('Cantarell Regular'), local('Cantarell-Regular'), url(cantarell.woff2) format('woff2'), url(cantarell.woff) format('woff');
The Firefox web dev inspector didn’t show it trying to fetch the font remotely, so I removed the local() elements from the CSS. That fixed the page, letting me pinpoint the problem as a local font issue. I have
fonts-cantarell installed so at first I tried to remove it, but that breaks
gnome-core. So instead I did an
fc-list | grep -i cant to ask fontconfig what it thought was happening. That gave:
/usr/share/fonts/opentype/cantarell/Cantarell-Regular.otf.dpkg-tmp: Cantarell:style=Regular /usr/share/fonts/opentype/cantarell/Cantarell-Bold.otf.dpkg-tmp: Cantarell:style=Bold /usr/share/fonts/opentype/cantarell/Cantarell-Bold.otf: Cantarell:style=Bold /usr/share/fonts/opentype/cantarell/Cantarell-Oblique.otf: Cantarell:style=Oblique /usr/share/fonts/opentype/cantarell/Cantarell-Regular.otf: Cantarell:style=Regular /usr/share/fonts/opentype/cantarell/Cantarell-Bold-Oblique.otf: Cantarell:style=Bold-Oblique /usr/share/fonts/opentype/cantarell/Cantarell-Oblique.otf.dpkg-tmp: Cantarell:style=Oblique /usr/share/fonts/opentype/cantarell/Cantarell-BoldOblique.otf: Cantarell:style=BoldOblique
.dpkg-tmp files looked odd, and sure enough they didn’t actually exist. So I did a
sudo fc-cache -f -v to force a rebuild of the font cache and restarted Firefox (it didn’t seem to work before doing so) and everything works fine now.
It seems that
fc-cache must have been run at some point when
dpkg had not yet completed installing an update to the
fonts-cantarell package. That seems like a bug - fontconfig should probably ignore .dpkg* files, but equally I wouldn’t expect it to be run before dpkg had finished its unpacking stage fully.
These days the phrase “embedded” usually means no console (except, if you’re lucky, console on a UART for debugging) and probably busybox for as much of userspace as you can get away with. You possibly have package management from OpenEmbedded or similar, though it might just be a horrible kludged together rootfs if someone hates you. Either way it’s rare for it not to involve some sort of hardware and OS much more advanced than the 8 bit machines I started out programming on.
That is, unless you’re playing with Arduinos or other similar hardware. I’m currently waiting on some ESP8266 dev boards to arrive, but even they’re quite advanced, with wifi and a basic OS framework provided. A long time ago I meant to get around to playing with PICs but never managed to do so. What I realised recently was that I have a ready made USB relay board that is powered by an ATtiny45. First step was to figure out if there were suitable programming pins available, which turned out to be all brought out conveniently to the edge of the board. Next I got out my trusty Bus Pirate, installed
avrdude and lo and behold:
$ avrdude -p attiny45 -c buspirate -P /dev/ttyUSB0 Attempting to initiate BusPirate binary mode... avrdude: Paged flash write enabled. avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9206 (probably t45) avrdude: safemode: Fuses OK (E:FF, H:DD, L:E1) avrdude done. Thank you.
Perfect. I then read the existing flash image off the device, disassembled it, worked out it was based on V-USB and then proceeded to work out that the only interesting extra bit was that the relay was hanging off pin 3 on IO port B. Which led to me knocking up what I thought should be a functionally equivalent version of the firmware, available locally or on GitHub. It’s worked with my basic testing so far and has confirmed to me I understand how the board is set up, meaning I can start to think about what else I could do with it…
This post is largely to remind myself of the details next time I hit something similar; I found bits of relevant information all over the place, but not in one single location.
I love Kodi. These days the Debian packages give me a nice out of the box experience that is easy to use. The problem comes in dealing with remote controls and making best use of the available buttons. In particular I want to upgrade the VDR setup my parents have to a more modern machine that’s capable of running Kodi. In this instance an AMD E350 nettop, which isn’t recent but does have sufficient hardware acceleration of video decoding to do the job. Plus it has a built in fintek CIR setup.
First step was finding a decent remote. The fintek is a proper IR receiver supported by the in-kernel decoding options, so I had a lot of flexibility. As it happened I ended up with a surplus to requirements Virgin V Box HD remote (URC174000-04R01). This has the advantage of looking exactly like a STB remote, because it is one.
Pointed it at the box, saw that the
fintek_cir module was already installed and fired up
irrecord. Failed to get it to actually record properly. Googled lots. Found
ir-keytable. Fired up
ir-keytable -t and managed to get sensible output with the RC-5 decoder. Used
irrecord -l to get a list of valid button names and proceed to construct a vboxhd file which I dropped in
/etc/rc_keymaps/. I then added a
fintek-cir * vboxhd
/etc/rc_maps.cfg to force my new keymap to be loaded on boot.
That got my remote working, but then came the issue of dealing with the fact that some keys worked fine in Kodi and others didn’t. This seems to be an issue with scancodes above 0xff. I could have remapped the remote not to use any of these, but instead I went down the
inputlirc approach (which is already in use on the existing VDR box).
For this I needed a stable device file to point it at; the
/dev/input/eventN file wasn’t stable and as a platform device it didn’t end up with a useful entry in
/dev/input/by-id. A ‘quick’
udevadm info -a -p $(udevadm info -q path -n /dev/input/eventN)
provided me with the PNP id (FIT0002) allowing me to create
/etc/defaults/inputlirc ended up containing:
EVENTS="/dev/input/remote" OPTIONS="-g -m 0"
The options tell it to grab the device for its own exclusive use, and to take all scancodes rather than letting the keyboard ones through to the normal keyboard layer. I didn’t want anything other than things specifically configured to use the remote to get the key presses.
At this point Kodi refused to actually do anything with the key presses. Looking at
~kodi/.kodi/temp/kodi.log I could see them getting seen, but not understood. Further searching led me to construct an Lircmap.xml - in particular the piece I needed was the
<remote device="/dev/input/remote"> bit. The existing
/usr/share/kodi/system/Lircmap.xml provided a good starting point for what I wanted and I dropped my generated file in
(Sadly it turns out I got lucky with the remote; it seems to be using the RC-5x variant which was broken in 3.17; works fine with the 3.16 kernel in Debian 8 (jessie) but nothing later. I’ve narrowed down the offending commit and raised #117221.)
Helpful pages included:
Whoop! Looking forward to it already (though will probably spend it feeling I should be finishing my dissertation).
2016-07-01 15:20 DUB -> 16:45 LHR BA0837 2016-07-01 21:35 LHR -> 10:00 CPT BA0059
2016-07-10 19:20 CPT -> 06:15 LHR BA0058 2016-07-11 09:20 LHR -> 10:45 DUB BA0828
(image stolen from Gunnar)
That’s a longer title than I’d like, but I want to try and catch the attention of anyone who might have missed more directed notifications about this. If you’re not an SPI contributing member there’s probably nothing to see here…
Although I decided not to stand for re-election at the Software in the Public Interest (SPI) board elections last July, I haven’t stopped my involvement with the organisation. In particular I’ve spent some time working on an overhaul of the members website and rolling it out. One of the things this has enabled is implementation of 2009-11-04.jmd.1: Contributing membership expiry, by tracking activity in elections and providing an easy way for a member to indicate they consider themselves active even if they haven’t voted.
The plan is that this will run at some point after the completion of every board election. A first pass of cleanups was completed nearly a month ago, contacting all contributing members who’d never been seen to vote and asking them to update their status if they were still active. A second round, of people who didn’t vote in the last board election (in 2014), is currently under way. Affected members will have been emailed directly and there was a mail to spi-announce, but I’m aware people often overlook these things or filter mail off somewhere that doesn’t get read often.
If you are an SPI Contributing member who considers themselves an active member I strongly recommend you login to the SPI Members Website and check the “Last active” date displayed is after 2014-07-14 (i.e. post the start of the last board election). If it’s not, click on the “Update” link beside the date. The updated date will be shown once you’ve done so.
Why does pruning inactive members matter? The 2015 X.Org election results provide at least one indication of why ensuring you have an engaged membership is important - they failed to make a by-laws change that a vast majority of votes were in favour of, due to failing to make quorum. (If you’re an X.org member, go vote!)
subscribe via RSS