Search Results: "Jonathan Wiltshire"

22 November 2021

Jonathan Wiltshire: Mischief managed

I m finally paying up a certain amount of household technical debt, including investigating some exciting mystery cabling and insulating the space it inhabits. This has meant pulling down large chunks of ceiling (eventually, most or all of it for the insulation) on a cable hunt. Turns out the best tool for this part of the job is a decent length of 4 by 2, some borrowed muscle, and a certain amount of bravery. Once a couple of holes have been cut the old-fashioned way to be sure there s nothing crucial above the ceiling (like the other side of the felt roof), the 4 2 really comes into its own: To use the 4 2, aim for a gap between two joists and imagine you re holding a caber. Launch it. The ceiling will come off far worse than the lump of wood you re holding. We found the mystery cable, but didn t really solve the mystery it creates and in the process uncovered another bizarre installation. The local lighting circuit is mostly a spur system in that white junction box by the RSJ. The overhead supplies dive under the RSJ through the junction box to the light switch including a full 3-core feed, not the usual loop-in system used in the rest of the house (I am not sure how prevalent loop-in systems are in other countries, they re sometimes called three-plate systems but they re very common in the UK). It does at least explain why I could never reverse-engineer the setup from the ceiling roses alone, which had only half the cores in the fitting than expected throughout the room (it wasn t even that the first fitting was looped in and being a supply for the others). On the other hand, normalising everything to a loop-in system and removing that awful rats nest of TPE should be straightforward. Neutral isn t required in that switch so that s one less problem. I couldn t resist labelling the switch in its relocated position:
Unfortunately, as valuable as that exercise was, I still have to get to the bottom of the original mystery cable which is at varying points 6mm2, 2.5mm2 and 1.5mm2 with apparently no current limiter or switch separation. Time for a bit more 4 by 2

14 August 2021

Jonathan Wiltshire: #ReleasingDebianBullseye

27 March 2021

Jonathan Wiltshire: Census stupidity, 2021 edition

Dear Office for National Statistics, Next time you sit down to design the UK census question flow, please ensure it does not go like this: 1. What is the date of birth for G [our young daughter]? Answer: late 2020 2. This date of birth makes G four months old. Is this correct? Answer: yes 3. With which of the following nationalities does G identify English, British or [list of others]? Answer: I have no idea, but I m happy to send you the recording of her response when I asked her, and you can see if you can make more sense of it than I did. I am reassured to see that you did skip questions about her employment status (always busy, never paid) and education (intensive), so perhaps there is some hope yet. No love,

7 March 2021

Jonathan Wiltshire: RCBW 21.9

A recent upload of electrum suffers from the serious bug #981374. On the face of it this is just a missing package dependency: can you help with testing and preparing an updated package to fix this? You don t need to be a Debian Developer to get stuck into this one!

2 January 2021

Jonathan Wiltshire: RCBW 21.1

Does software-properties-common really depend on gnupg, as described in #970124, or could it be python3-software-properties? Should it be Depends, or Recommends? And do you accept the challenge of finding out and preparing a patch (and even an upload) to fix the bug?

1 January 2021

Jonathan Wiltshire: WordPress in a subdirectory

For many years now I ve had WordPress installed as a subdirectory to my site but appearing to at the domain level, i.e. /wordpress/index.php is transparently presented as the homepage. This is done by setting the WordPress Address and Site Address settings and then mapping requests which do not match an existing file or directory through as a PHP pathinfo using Apache s mod_rewrite rules in a .htaccess file or server configuration. In this way most of the site is WordPress s dynamic pages and posts, but WordPress itself is neatly contained and random static resources such as /screentest/1024.GIF work as expected. Those .htaccess rules were originally hand-crafted but didn t take account of changing recommendations, e.g. the Authorization header. When I rearranged matters recently I decided to take advantage of WordPress s own generated rules and ditch my old rules. They look like this:
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:% HTTP:Authorization ]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond % REQUEST_FILENAME  !-f
RewriteCond % REQUEST_FILENAME  !-d
RewriteRule . /index.php [L]
# END WordPress
If .htaccess is writable, WordPress adds these rules automatically. Unfortunately, when I switched to them and not my own, the site broke. Crucially the generated rules do not cater for WordPress being in a subdirectory. No matter what combination of settings I tried, local changes to the rules (like RewriteRule . /wordpress/index.php [L]) were rewritten back to the original values at random times and clearly couldn t be relied upon to stay as I need them. This feels like a bug: my intuition is that if the WordPress Address and Site Address settings are different, but within the same domain, the rules should be generated to take care of that. One option is to make the .htaccess file read-only, which WordPress detects and avoids trying to make changes at all. But this rather defeats the object of letting it take care of future changes as the software and specifications change. The second option, which I stuck with, is to add an index.php file with the following contents:
Now the generated rules, though incorrect, result in the right behaviour and won t break on every setting change.

1 April 2020

Jonathan Wiltshire: neuraldak

We are proud to announce that dak, the Debian Archive Kit, has been replaced by a neural network for processing package uploads and other archive maintenance. All FTP masters and assistants have been re-deployed to concentrate on managing neuraldak. neuraldak is an advanced machine learning algorithm which has been taught about appropriate uploads, can write to maintainers about their bugs and can automatically make an evaluation about suitable licenses and code quality. Any uploads which do not meet its standards will be rejected with prejudice. We anticipate that neuraldak will also monitor social media for discontent about package uploads, and train itself to do better with its decisions. In terms of licensing , neuraldak has been seeded only with the GPL license. This we consider the gold standard of licenses, and its clauses will be the basis for neuraldak evaluating other licenses as it is exposed to them. Over the course of the next few weeks, neuraldak will also learn to manage the testing suite. Once it is established, we expect to be able to make a full stable release of Debian approximately every six weeks. We have therefore also re-purposed Janelle Shane s cat name algorithm to invent suitable release names, since the list of Toy Story names is likely to be exhausted before 2021. neuraldak is an independent software project. Rumours of it being derived from Skynet are entirely unfounded. The post neuraldak appeared first on

13 June 2017

Jonathan Wiltshire: What to expect on Debian release day

Nearly two years ago I wrote about what to expect on Jessie release day. Shockingly enough, the process for Stretch to be released should be almost identical.

1 November 2016

Jonathan Wiltshire: Reflecting on a year of regular, public IRC meetings

The release team first started holding a regular, public planning and status meeting a little over a year ago, in September 2015. At that time, FTP masters had experimented along similar lines and I took some inspiration from that, including the keeping of proper minutes that anyone can look at. I wanted to open up our discussion processes and allow other developers and users to see (and perhaps influence) our plans for the release taking shape month by month, and how we reached certain decisions with a lot of mature discussion and not just on a whim. A secondary aim, since we are quite geographically distributed and getting together for same-room meetings is hard, was to bring more accountability to ourselves when we decided something ought to happen; if it s in the minutes, there s no escaping someone asking so what happened to ? . That s worked better for us on some topics than on others. Finally, public minutes mean that anyone who might be interested in joining the team can see easily what we re up to and how we shape the release throughout the cycle. That might help lower the barrier to entry, which can only be good for the team. I had hoped that regular meetings would inspire other teams to do similar; I haven t seen any indication of that to date (though perhaps it s just down to awareness). The Reproducible Builds contributors held fortnightly meetings for a period in 2015, though not inspired by ours, and I heard recent talk of starting those again. I still think that there is plenty of scope to improve the transparency of core teams in general in Debian, but also that regular meetings aren t going to work for every team. A regular slot which is not varied except when absolutely necessary, is essential for avoiding the temptation to just push it back another week when things are busy. In our office we have an allegedly-regular Thursday afternoon slot for technical demonstrations, which has suffered from exactly that problem for a long time now, and I wanted to avoid that issue. We have a calendar to remind us when each meeting is due, along with other important events like freeze milestones. Our slot is the fourth Wednesday of the month, a fairly arbitrary choice which seems to have worked out quite well. Time zones are more of an issue, even within Europe. We have mostly used a European evening time, but that s not very helpful further West where it s in the middle of the working day, or the middle of the night if you re further East (that one fortunately isn t an issue for us so far). Even within Europe it s difficult, as we have to try and balance commuting time in the UK with dinner on the continent, or dinner with late evening, or adjust for saving changes, or you get the idea. If we gained a far-eastern team member one day, this would be a real issue. We use Meetbot for recording the minutes. I have heard criticism that it publicly archives IRC logs to the web essentially forever, but for us that s the whole point. With a little practice and discipline it does generate really nice minutes, with a bullet summary of the important parts, a summary of actions agreed and a log of the conversation for detailed reference. Anybody reading them can see how we reached a conclusion, and I m of the view that goes some way to avoiding a reputation for cabal-ism. It does pay to use the #info, #agree and #action tags liberally, but other things are slightly unnatural like always remembering to use a URL at the beginning of a line and not in the middle of a sentence, or Meetbot doesn t notice it. Practice goes a long way. I ve naturally fallen into chairing most meetings, for better or worse the consistency seems beneficial, but I worry that I m dominating the discussion sometimes. Discipline in making sure everybody has been included is something I ve had to get better at. It s essential to have a public agenda and to stick to it, and it should include some stock items at the start and end (including making sure the URL to the previous minutes has been given, reviewing outstanding actions, and arranging the next meeting before ending the current one). There is some skill in judging the agenda length and deciding which items can be deferred to make sure it doesn t drag on too late we ve found anything more than an hour is far too long, and between 45 and 60 minutes is pushing it. Getting some easy topics out of the way before starting one which is more contentious can be helpful to avoid having to defer them later. I circulate the URL to the minutes and the date of the next meeting publicly on the mailing list immediately after each meeting, or as soon as possible. With little feedback, I have no idea if our meetings are helpful to those outside the team or not. We do still hold in-person meetings from time to time when we re all together, because they re useful for some circumstances (like some genuinely private topics we occasionally need to discuss, or for sprinting). I would hope that public meetings inspire confidence that we re on top of the release process, that they show we have a mature and transparent decision making process (for example, in deciding to move the freeze date to accommodate an external release schedule as a one-off, and subsequently deciding to not move it back when circumstances changed), and mostly that other teams might benefit for the same reasons. But I can also see that they make more sense in a team with a defined project cycle than they might in one which is more administrative or where work is more sporadic (no point holding a meeting for the sake of it, after all).

4 May 2015

Lunar: Reproducible builds: first week in Stretch cycle

Debian Jessie has been released on April 25th, 2015. This has opened the Stretch development cycle. Reactions to the idea of making Debian build reproducibly have been pretty enthusiastic. As the pace is now likely to be even faster, let's see if we can keep everyone up-to-date on the developments. Before the release of Jessie The story goes back a long way but a formal announcement to the project has only been sent in February 2015. Since then, too much work has happened to make a complete report, but to give some highlights: Lunar did a pretty improvised lightning talk during the Mini-DebConf in Lyon. This past week It seems changes were pilling behind the curtains given the amount of activity that happened in just one week. Toolchain fixes We also rebased the experimental version of debhelper twice to merge the latest set of changes. Lunar submitted a patch to add a -creation-date to genisoimage. Reiner Herrmann opened #783938 to request making -notimestamp the default behavior for javadoc. Juan Picca submitted a patch to add a --use-date flag to texi2html. Packages fixed The following packages became reproducible due to changes of their build dependencies: apport, batctl, cil, commons-math3, devscripts, disruptor, ehcache, ftphs, gtk2hs-buildtools, haskell-abstract-deque, haskell-abstract-par, haskell-acid-state, haskell-adjunctions, haskell-aeson, haskell-aeson-pretty, haskell-alut, haskell-ansi-terminal, haskell-async, haskell-attoparsec, haskell-augeas, haskell-auto-update, haskell-binary-conduit, haskell-hscurses, jsch, ledgersmb, libapache2-mod-auth-mellon, libarchive-tar-wrapper-perl, libbusiness-onlinepayment-payflowpro-perl, libcapture-tiny-perl, libchi-perl, libcommons-codec-java, libconfig-model-itself-perl, libconfig-model-tester-perl, libcpan-perl-releases-perl, libcrypt-unixcrypt-perl, libdatetime-timezone-perl, libdbd-firebird-perl, libdbix-class-resultset-recursiveupdate-perl, libdbix-profile-perl, libdevel-cover-perl, libdevel-ptkdb-perl, libfile-tail-perl, libfinance-quote-perl, libformat-human-bytes-perl, libgtk2-perl, libhibernate-validator-java, libimage-exiftool-perl, libjson-perl, liblinux-prctl-perl, liblog-any-perl, libmail-imapclient-perl, libmocked-perl, libmodule-build-xsutil-perl, libmodule-extractuse-perl, libmodule-signature-perl, libmoosex-simpleconfig-perl, libmoox-handlesvia-perl, libnet-frame-layer-ipv6-perl, libnet-openssh-perl, libnumber-format-perl, libobject-id-perl, libpackage-pkg-perl, libpdf-fdf-simple-perl, libpod-webserver-perl, libpoe-component-pubsub-perl, libregexp-grammars-perl, libreply-perl, libscalar-defer-perl, libsereal-encoder-perl, libspreadsheet-read-perl, libspring-java, libsql-abstract-more-perl, libsvn-class-perl, libtemplate-plugin-gravatar-perl, libterm-progressbar-perl, libterm-shellui-perl, libtest-dir-perl, libtest-log4perl-perl, libtext-context-eitherside-perl, libtime-warp-perl, libtree-simple-perl, libwww-shorten-simple-perl, libwx-perl-processstream-perl, libxml-filter-xslt-perl, libxml-writer-string-perl, libyaml-tiny-perl, mupen64plus-core, nmap, openssl, pkg-perl-tools, quodlibet, r-cran-rjags, r-cran-rjson, r-cran-sn, r-cran-statmod, ruby-nokogiri, sezpoz, skksearch, slurm-llnl, stellarium. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which did not make their way to the archive yet: Improvements to Mattia Rizzolo has been working on compressing logs using gzip to save disk space. The web server would uncompress them on-the-fly for clients which does not accept gzip content. Mattia Rizzolo worked on a new page listing various breakage: missing or bad debbindiff output, missing build logs, unavailable build dependencies. Holger Levsen added a new execution environment to run debbindiff using dependencies from testing. This is required for packages built with GHC as the compiler only understands interfaces built by the same version. debbindiff development Version 17 has been uploaded to unstable. It now supports comparing ISO9660 images, dictzip files and should compare identical files much faster. Documentation update Various small updates and fixes to the pages about PDF produced by LaTeX, DVI produced by LaTeX, static libraries, Javadoc, PE binaries, and Epydoc. Package reviews Known issues have been tagged when known to be deterministic as some might unfortunately not show up on every single build. For example, two new issues have been identified by building with one timezone in April and one in May. RD and help2man add current month and year to the documentation they are producing. 1162 packages have been removed and 774 have been added in the past week. Most of them are the work of proper automated investigation done by Chris West. Summer of code Finally, we learned that both akira and Dhole were accepted for this Google Summer of Code. Let's welcome them! They have until May 25th before coding officialy begins. Now is the good time to help them feel more comfortable by sharing all these little bits of knowledge on how Debian works.

24 April 2015

Jonathan Wiltshire: What to expect on Jessie release day

Release day is a nerve-wracking time for several teams. Happily we ve done it a few times now*, so we have a rough idea of how the process should go. There have been some preparations going on in advance:
  1. Last week we imposed a quiet period on migrations. That s about as frozen as we can get; it means that even RC bugs need to be exceptional if they aren t to be deferred to the first point release. Only late-breaking documentation (like the install guide) was accepted.
  2. The security team opened jessie-updates for business, carried out a test upload, and have since released several packages so that those updates are available immediately after release.
  3. The debian-installer team made a final release.
  4. Final debtags data was updated.
  5. Yesterday the testing migration script britney and other automatic maintenance scripts that the release team run were disabled for the duration.
  6. We made final preparations of things that can be done in advance, such as drafting the publicity announcements. These have to be done in advance so translators get chance to do their work overnight (the announcement was signed off at 15:30UTC today, translations are starting to arrive right now!).
The following checklist makes the release actually happen:
  1. Once dinstall is completed at 07:52, archive maintenance is suspended the FTP masters will do manual work for now.
  2. Very large quantities of coffee will be prepared all across Europe.
  3. Release managers carry out consistency checks of the Jessie index files, and confirm to FTP masters that there are no last-minute changes to be made. RMs get a break to make more coffee.
  4. While they re away FTP masters begin the process of relabelling Wheezy as oldstable and Jessie as stable. If an installer needs to be, er, installed as well, that happens at this point. Old builds of the installer are removed.
  5. A new suite for Stretch (Debian 9) is initialised and populated, and labelled testing.
  6. Release managers check that the newly-generated suite index files look correct and consistent with the checks made earlier in the day. Everything is signed off both in logistical and cryptographic terms.
  7. FTP masters trigger a push of all the changes to the CD-building mirror so that production of images can begin. As each image is completed, several volunteers download and test it in as many ways as they can dream up (booting and choosing different paths through the installer to check integrity).
  8. Finally a full mirror push is triggered by FTP masters, and the finished CD images are published.
  9. Announcements are sent by the publicity team to various places, and by the release team to the developers at large.
  10. Archive maintenance scripts are re-enabled.
  11. The release team take a break for a couple of weeks before getting back into the next cycle.
During the day much of the coordination happens in the #debian-release, #debian-ftp and #debian-cd IRC channels. You re welcome to follow along if you re interested in the process, although we ask that you are read-only while people are still concentrating (during the Squeeze release, a steady stream of people turned up to say congratulations! at the most critical junctures; it s not particularly helpful while the process is still going on). The publicity team will be tweeting and denting progress as it happens, so that makes a good overview too. If everything goes to plan, enjoy the parties! (Disclaimer: inaccuracies are possible since so many people are involved and there s a lot to happen in each step; all errors and omissions are entirely mine.) * yes yes, I am being particularly English today.
What to expect on Jessie release day is a post from: Flattr

Jonathan Wiltshire: Jessie Countdown: 1

One further contributor became a non-uploading Debian Developer in 2015, joining 11 others who achieved that status its introduction in 2010. Non-uploading developers are really important to our project. They re a recognition of the invaluable work that contributors do which doesn t involve packaging, for which they may not have the skill nor inclination. Nevertheless we would be much weaker without those tireless contributions in the community, translations, bug handling the list is much longer and covers every aspect of Debian life. If you re reading this and thinking I have a sustained involvement in some aspect of Debian, and make regular contributions , please consider chatting to those you work with and see if you re ready to be recognised too. (source:
Jessie Countdown: 1 is a post from: Flattr

23 April 2015

Jonathan Wiltshire: Jessie Countdown: 2

Two years, give or take a few weeks, is roughly the time required to prepare a new stable release since Sarge in 2005 (source: A Spring release has also been a pretty stable pattern during that time. Debian often has a reputation for being very slow to release (in terms of cadence), or for freezes to hold up development for an excessive length of time, but the current pattern does lend itself well to two attributes: predictability and reliability (in terms of high-quality releases). It s true that this means shipping with slightly older versions of major software, but you can sleep well knowing they re thoroughly tested and that s really important in Debian s core market, which tends to be highly-available services rather than desktop machines. There s always backports.
Jessie Countdown: 2 is a post from: Flattr

22 April 2015

Jonathan Wiltshire: Jessie Countdown: 3

Three is the new number for continuing oldstable security support: thanks to the efforts of those behind the Long-Term Support initiative, the full stable lifecycle of a release has therefore become five years (source: Where do those numbers come from? 2 years as stable, 1 year overlap support as oldstable, plus 2 new years under LTS = 5 years. Having been successful for Squeeze (6), LTS is widely anticipated to follow a similar pattern for Wheezy (7) and Jessie (8) for the same lifetimes. Some reduction in coverage is unavoidable (for example, Squeeze only covers the most popular amd64 and i386 architectures), but for a majority of users this reduces the need to follow a three-year upgrade cycle invaluable when you are managing hundreds or thousands of servers and can t achieve that in a single year.
Jessie Countdown: 3 is a post from: Flattr

21 April 2015

Jonathan Wiltshire: Tube in a Day

For some reason, I ve decided that gallivanting around the London Underground for the day one Saturday is a fine way to raise money for a local children s hospice. You d make my day by supporting us we aren t deducting expenses from pledges, so there s no penalty to the charity for our travel. We re going to run a modified version of the Guinness-recognised Tube Challenge starting about 05:15 (modified to allow for unavoidable maintenance works; we don t have the luxury of being able to pick a day when that s not going to be a problem) and likely finishing about midnight. I m also interested to hear ideas for some kind of micro-blogging platform that we can update on the move, preferably presenting in stream format and with an Android-friendly site/app that can cope with uploading a photo smoothly. Not Twitter or Facebook; it ll probably be a short-lived account. I don t want to part with personal information and I want to be able to throw it away afterwards. Suggestions?
Tube in a Day is a post from: Flattr

Jonathan Wiltshire: Jessie Countdown: 4

Four architectures types of computing device that you can use to run Debian didn t make it through architecture qualification for Jessie and won t be part of the official stable release this weekend. It s always difficult to see architectures go, particularly when there is still a community interested in maintaining support for them. Nevertheless, sometimes a port just doesn t have enough momentum behind it or sufficient upstream interest from the toolchain to be economical. Whether a port is of sufficient quality for stable is a complex decision involving several different teams Debian System Administration, the security team, those who maintain the auto-builder network, the release team, and so on and will continue to affect them for several years. It s not all gloom though: new architectures in Jessie include arm64, ppc64el (a 64-bit version of powerpc) and s390x (replacing Wheezy s s390). Architecture rotation can be healthy. (source: ia64 and s390 were planned retirements following Wheezy, leaving hurd-i386, kfreebsd-i386, kfreebsd-amd64 and sparc which didn t satisfy all qualification criteria by the time decisions had to be taken.)
Jessie Countdown: 4 is a post from: Flattr

20 April 2015

Jonathan Wiltshire: Jessie Countdown: 5

Five contributors became uploading Debian Developers so far in 2015 (source:
Jessie Countdown: 5 is a post from: Flattr

8 February 2015

Jonathan Wiltshire: Contributors

I like how reminds me of things I used to have time for, and motivates me to find some for them.
Contributors is a post from: Flattr

20 January 2015

Jonathan Wiltshire: Never too late for bug-squashing

With over a hundred RC bugs still outstanding for Jessie, there s never been a better time to host a bug-squashing party in your local area. Here s how I do it.
  1. At home is fine, if you don t mind guests. You don t need to seek out a sponsor and borrow or hire office space. If there isn t room for couch-surfers, the project can help towards travel and accommodation expenses. My address isn t secret, but I still don t announce it it s fine to share it only with the attendees once you know who they are.
  2. You need a good work area. There should be room for people to sit and work comfortably a dining room table and chairs is ideal. It should be quiet and free from distractions. A local mirror is handy, but a good internet connection is essential.
  3. Hungry hackers eat lots of snacks. This past weekend saw five of us get through 15 litres of soft drinks, two loaves of bread, half a kilo of cheese, two litres of soup, 22 bags of crisps, 12 jam tarts, two pints of milk, two packs of chocolate cake bars, and a large bag of biscuits (and we went out for breakfast and supper). Make sure there is plenty available before your attendees arrive, along with a good supply of tea and coffee.
  4. Have a work plan. Pick a shortlist of RC bugs to suit attendees strengths, or work on a particular packaging group s bugs, or have a theme, or something. Make sure there s a common purpose and you don t just end up being a bunch of people round a table.
  5. Be an exemplary host. As the host you re allowed to squash fewer bugs and instead make sure your guests are comfortable, know where the bathroom is, aren t going hungry, etc. It s an acceptable trade-off. (The reverse is true: if you re attending, be an exemplary guest and don t spend the party reading news sites.)
Now, go host a BSP of your own, and let s release!
Never too late for bug-squashing is a post from: Flattr

18 January 2015

Jonathan Wiltshire: Alcester BSP, day three

We have had a rather more successful weekend then I feared, as you can see from our log on the wiki page. Steve reproduced and wrote patches for several installer/bootloader bugs, and Neil and I spent significant time in a maze of twist zope packages (we have managed to provide more diagnostics on the bug, even if we couldn t resolve it). Ben and Adam have ploughed through a mixture of bugs and maintenance work. I wrongly assumed we would only be able to touch a handful of bugs, since they are now mostly quite difficult, so it was rather pleasant to recap our progress this evening and see that it s not all bad after all.
Alcester BSP, day three is a post from: Flattr