Generated.

[homepage.git] / blog / index.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:atom="http://www.w3.org/2005/Atom">
        <channel>
                <title>Petter Reinholdtsen</title>
                <description></description>
                <link>http://people.skolelinux.org/pere/blog/</link>
                <atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
        
        <item>
                <title>syslog-trusted-timestamp - chain of trusted timestamps for your syslog</title>
                <link>http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html</guid>
                <pubDate>Fri, 1 Apr 2016 09:50:00 +0200</pubDate>
                <description>&lt;p&gt;Two years ago, I had
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Public_Trusted_Timestamping_services_for_everyone.html&quot;&gt;a
look at trusted timestamping options available&lt;/a&gt;, and among
other things noted a still open
&lt;a href=&quot;https://bugs.debian.org/742553&quot;&gt;bug in the tsget script&lt;/a&gt;
included in openssl that made it harder than necessary to use openssl
as a trusted timestamping client.  A few days ago I was told
&lt;a href=&quot;https::/www.difi.no/&quot;&gt;the Norwegian government office DIFI&lt;/a&gt; is
close to releasing their own trusted timestamp service, and in the
process I was happy to learn about a replacement for the tsget script
using only curl:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
openssl ts -query -data &quot;/etc/shells&quot; -cert -sha256 -no_nonce \
  | curl -s -H &quot;Content-Type: application/timestamp-query&quot; \
         --data-binary &quot;@-&quot; http://zeitstempel.dfn.de &gt; etc-shells.tsr
openssl ts -reply -text -in etc-shells.tsr
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;This produces a binary timestamp file (etc-shells.tsr) which can be
used to verify that the content of the file /etc/shell with the
calculated sha256 hash existed at the point in time when the request
was made.  The last command extract the content of the etc-shells.tsr
in human readable form.  The idea behind such timestamp is to be able
to prove using cryptography that the content of a file have not
changed since the file was stamped.&lt;/p&gt;

&lt;p&gt;To verify that the file on disk match the public key signature in
the timestamp file, run the following commands.  It make sure you have
the required certificate for the trusted timestamp service available
and use it to compare the file content with the timestamp.  In
production, one should of course use a better method to verify the
service certificate.&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
wget -O ca-cert.txt https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
openssl ts -verify -data /etc/shells -in etc-shells.tsr -CAfile ca-cert.txt -text
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Wikipedia have a lot more information about
&lt;a href=&quot;https://en.wikipedia.org/wiki/Trusted_timestamping&quot;&gt;trusted
Timestamping&lt;/a&gt; and
&lt;a href=&quot;https://en.wikipedia.org/wiki/Linked_timestamping&quot;&gt;linked
timestamping&lt;/a&gt;, and there are several trusted timestamping services
around, both as commercial services and as free and public services.
Among the latter is
&lt;a href=&quot;https://www.pki.dfn.de/zeitstempeldienst/&quot;&gt;the
zeitstempel.dfn.de service&lt;/a&gt; mentioned above and
&lt;a href=&quot;https://freetsa.org/&quot;&gt;freetsa.org service&lt;/a&gt; linked to from the
wikipedia web site.  I believe the DIFI service should show up on
https://tsa.difi.no, but it is not available to the public at the
moment.  I hope this will change when it is into production.  The
&lt;a href=&quot;https://tools.ietf.org/html/rfc3161&quot;&gt;RFC 3161&lt;/a&gt; trusted
timestamping protocol standard is even implemented in LibreOffice,
Microsoft Office and Adobe Acrobat, making it possible to verify when
a document was created.&lt;/p&gt;

&lt;p&gt;I would find it useful to be able to use such trusted timestamp
service to make it possible to verify that my stored syslog files have
not been tampered with.  This is not a new idea.  I found one example
implemented on the Endian network appliances where
&lt;a href=&quot;http://help.endian.com/entries/21518508-Enabling-Timestamping-on-log-files-&quot;&gt;the
configuration of such feature was described in 2012&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;But I could not find any free implementation of such feature when I
searched, so I decided to try to
&lt;a href=&quot;https://github.com/petterreinholdtsen/syslog-trusted-timestamp&quot;&gt;build
a prototype named syslog-trusted-timestamp&lt;/a&gt;.  My idea is to
generate a timestamp of the old log files after they are rotated, and
store the timestamp in the new log file just after rotation.  This
will form a chain that would make it possible to see if any old log
files are tampered with.  But syslog is bad at handling kilobytes of
binary data, so I decided to base64 encode the timestamp and add an ID
and line sequence numbers to the base64 data to make it possible to
reassemble the timestamp file again.  To use it, simply run it like
this:

&lt;p&gt;&lt;pre&gt;
syslog-trusted-timestamp /path/to/list-of-log-files
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;This will send a timestamp from one or more timestamp services (not
yet decided nor implemented) for each listed file to the syslog using
logger(1).  To verify the timestamp, the same program is used with the
--verify option:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
syslog-trusted-timestamp --verify /path/to/log-file /path/to/log-with-timestamp
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;The verification step is not yet well designed.  The current
implementation depend on the file path being unique and unchanging,
and this is not a solid assumption.  It also uses process number as
timestamp ID, and this is bound to create ID collisions.  I hope to
have time to come up with a better way to handle timestamp IDs and
verification later.&lt;/p&gt;

&lt;p&gt;Please check out
&lt;a href=&quot;https://github.com/petterreinholdtsen/syslog-trusted-timestamp&quot;&gt;the
prototype for syslog-trusted-timestamp on github&lt;/a&gt; and send
suggestions and improvement, or let me know if there already exist a
similar system for timestamping logs already to allow me to join
forces with others with the same interest.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Full battery stats collector is now available in Debian</title>
                <link>http://people.skolelinux.org/pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html</guid>
                <pubDate>Wed, 23 Mar 2016 22:10:00 +0100</pubDate>
                <description>&lt;p&gt;Since this morning, the battery-stats package in Debian include an
extended collector that will collect the complete battery history for
later processing and graphing.  The original collector store the
battery level as percentage of last full level, while the new
collector also record battery vendor, model, serial number, design
full level, last full level and current battery level.  This make it
possible to predict the lifetime of the battery as well as visualise
the energy flow when the battery is charging or discharging.&lt;/p&gt;

&lt;p&gt;The new tools are available in &lt;tt&gt;/usr/share/battery-stats/&lt;/tt&gt;
in the version 0.5.1 package in unstable.  Get the new battery level graph
and lifetime prediction by running:

&lt;p&gt;&lt;pre&gt;
/usr/share/battery-stats/battery-stats-graph /var/log/battery-stats.csv
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Or select the &#39;Battery Level Graph&#39; from your application menu.&lt;/p&gt;

&lt;p&gt;The flow in/out of the battery can be seen by running (no menu
entry yet):&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
/usr/share/battery-stats/battery-stats-graph-flow
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;I&#39;m not quite happy with the way the data is visualised, at least
when there are few data points.  The graphs look a bit better with a
few years of data.&lt;/p&gt;

&lt;p&gt;A while back one important feature I use in the battery stats
collector broke in Debian.  The scripts in
&lt;tt&gt;/usr/lib/pm-utils/power.d/&lt;/tt&gt; were no longer executed.  I
suspect it happened when Jessie started using systemd, but I do not
know.  The issue is reported as
&lt;a href=&quot;https://bugs.debian.org/818649&quot;&gt;bug #818649&lt;/a&gt; against
pm-utils.  I managed to work around it by adding an udev rule to call
the collector script every time the power connector is connected and
disconnected.  With this fix in place it was finally time to make a
new release of the package, and get it into Debian.&lt;/p&gt;

&lt;p&gt;If you are interested in how your laptop battery is doing, please
check out the
&lt;a href=&quot;https://tracker.debian.org/pkg/battery-stats&quot;&gt;battery-stats&lt;/a&gt;
in Debian unstable, or rebuild it on Jessie to get it working on
Debian stable. :) The upstream source is available from
&lt;a href=&quot;https://github.com/petterreinholdtsen/battery-stats&quot;&gt;github&lt;/a&gt;.
As always, patches are very welcome.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>UsingQR - &quot;Electronic&quot; paper invoices using JSON and QR codes</title>
                <link>http://people.skolelinux.org/pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html</guid>
                <pubDate>Sat, 19 Mar 2016 09:40:00 +0100</pubDate>
                <description>&lt;p&gt;Back in 2013 I proposed
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/_Electronic__paper_invoices___using_vCard_in_a_QR_code.html&quot;&gt;a
way to make paper and PDF invoices easier to process electronically by
adding a QR code with the key information about the invoice&lt;/a&gt;.  I
suggested using vCard field definition, to get some standard format
for name and address, but any format would work.  I did not do
anything about the proposal, but hoped someone one day would make
something like it.  It would make it possible to efficiently send
machine readable invoices directly between seller and buyer.&lt;/p&gt;

&lt;p&gt;This was the background when I came across a proposal and
specification from the web based accounting and invoicing supplier
&lt;a href=&quot;http://www.visma.com/&quot;&gt;Visma&lt;/a&gt; in Sweden called
&lt;a href=&quot;http://usingqr.com/&quot;&gt;UsingQR&lt;/a&gt;.  Their PDF invoices contain
a QR code with the key information of the invoice in JSON format.
This is the typical content of a QR code following the UsingQR
specification (based on a real world example, some numbers replaced to
get a more bogus entry).  I&#39;ve reformatted the JSON to make it easier
to read.  Normally this is all on one long line:&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2016-03-19-qr-invoice.png&quot; align=&quot;right&quot;&gt;&lt;pre&gt;
{
 &quot;vh&quot;:500.00,
 &quot;vm&quot;:0,
 &quot;vl&quot;:0,
 &quot;uqr&quot;:1,
 &quot;tp&quot;:1,
 &quot;nme&quot;:&quot;Din Leverandør&quot;,
 &quot;cc&quot;:&quot;NO&quot;,
 &quot;cid&quot;:&quot;997912345 MVA&quot;,
 &quot;iref&quot;:&quot;12300001&quot;,
 &quot;idt&quot;:&quot;20151022&quot;,
 &quot;ddt&quot;:&quot;20151105&quot;,
 &quot;due&quot;:2500.0000,
 &quot;cur&quot;:&quot;NOK&quot;,
 &quot;pt&quot;:&quot;BBAN&quot;,
 &quot;acc&quot;:&quot;17202612345&quot;,
 &quot;bc&quot;:&quot;BIENNOK1&quot;,
 &quot;adr&quot;:&quot;0313 OSLO&quot;
}
&lt;/pre&gt;&lt;/p&gt;

&lt;/p&gt;The interpretation of the fields can be found in the
&lt;a href=&quot;http://usingqr.com/wp-content/uploads/2014/06/UsingQR_specification1.pdf&quot;&gt;format
specification&lt;/a&gt; (revision 2 from june 2014).  The format seem to
have most of the information needed to handle accounting and payment
of invoices, at least the fields I have needed so far here in
Norway.&lt;/p&gt;

&lt;p&gt;Unfortunately, the site and document do not mention anything about
the patent, trademark and copyright status of the format and the
specification.  Because of this, I asked the people behind it back in
November to clarify.  Ann-Christine Savlid (ann-christine.savlid (at)
visma.com) replied that Visma had not applied for patent or trademark
protection for this format, and that there were no copyright based
usage limitations for the format.  I urged her to make sure this was
explicitly written on the web pages and in the specification, but
unfortunately this has not happened yet.  So I guess if there is
submarine patents, hidden trademarks or a will to sue for copyright
infringements, those starting to use the UsingQR format might be at
risk, but if this happen there is some legal defense in the fact that
the people behind the format claimed it was safe to do so.  At least
with patents, there is always
&lt;a href=&quot;http://www.paperspecs.com/paper-news/beware-the-qr-code-patent-trap/&quot;&gt;a
chance of getting sued...&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I also asked if they planned to maintain the format in an
independent standard organization to give others more confidence that
they would participate in the standardization process on equal terms
with Visma, but they had no immediate plans for this.  Their plan was
to work with banks to try to get more users of the format, and
evaluate the way forward if the format proved to be popular.  I hope
they conclude that using an open standard organisation like
&lt;a href=&quot;http://www.ietf.org/&quot;&gt;IETF&lt;/a&gt; is the correct place to
maintain such specification.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2016-03-20&lt;/strong&gt;: Via Twitter I became aware of
&lt;a href=&quot;https://news.ycombinator.com/item?id=11319492&quot;&gt;some comments
about this blog post&lt;/a&gt; that had several useful links and references to
similar systems.  In the Czech republic, the Czech Banking Association
standard #26, with short name SPAYD, uses QR codes with payment
information.  More information is available from the Wikipedia page on
&lt;a href=&quot;https://en.wikipedia.org/wiki/Short_Payment_Descriptor&quot;&gt;Short
Payment Descriptor&lt;/a&gt;.  And in Germany, there is a system named
&lt;a href=&quot;http://www.bezahlcode.de/&quot;&gt;BezahlCode&lt;/a&gt;,
(&lt;a href=&quot;http://www.bezahlcode.de/wp-content/uploads/BezahlCode_TechDok.pdf&quot;&gt;specification
v1.8 2013-12-05 available as PDF&lt;/a&gt;), which uses QR codes with
URL-like formatting using &quot;bank:&quot; as the URI schema/protocol to
provide the payment information.  There is also the
&lt;a href=&quot;http://www.ferd-net.de/front_content.php?idcat=231&quot;&gt;ZUGFeRD&lt;/a&gt;
file format that perhaps could be transfered using QR codes, but I am
not sure if it is done already.  Last, in Bolivia there are reports
that tax information since november 2014 need to be printed in QR
format on invoices.  I have not been able to track down a
specification for this format, because of my limited language skill
sets.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Making battery measurements a little easier in Debian</title>
                <link>http://people.skolelinux.org/pere/blog/Making_battery_measurements_a_little_easier_in_Debian.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Making_battery_measurements_a_little_easier_in_Debian.html</guid>
                <pubDate>Tue, 15 Mar 2016 15:00:00 +0100</pubDate>
                <description>&lt;p&gt;Back in September, I blogged about
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/The_life_and_death_of_a_laptop_battery.html&quot;&gt;the
system I wrote to collect statistics about my laptop battery&lt;/a&gt;, and
how it showed the decay and death of this battery (now replaced).  I
created a simple deb package to handle the collection and graphing,
but did not want to upload it to Debian as there were already
&lt;a href=&quot;https://tracker.debian.org/pkg/battery-stats&quot;&gt;a battery-stats
package in Debian&lt;/a&gt; that should do the same thing, and I did not see
a point of uploading a competing package when battery-stats could be
fixed instead.  I reported a few bugs about its non-function, and
hoped someone would step in and fix it.  But no-one did.&lt;/p&gt;

&lt;p&gt;I got tired of waiting a few days ago, and took matters in my own
hands.  The end result is that I am now the new upstream developer of
battery stats (&lt;a href=&quot;https://github.com/petterreinholdtsen/battery-stats&quot;&gt;available from github&lt;/a&gt;) and part of the team maintaining
battery-stats in Debian, and the package in Debian unstable is finally
able to collect battery status using the &lt;tt&gt;/sys/class/power_supply/&lt;/tt&gt;
information provided by the Linux kernel.  If you install the
battery-stats package from unstable now, you will be able to get a
graph of the current battery fill level, to get some idea about the
status of the battery.  The source package build and work just fine in
Debian testing and stable (and probably oldstable too, but I have not
tested).  The default graph you get for that system look like this:&lt;/p&gt;

&lt;p align=&quot;center&quot;&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2016-03-15-battery-stats-graph-example.png&quot; width=&quot;70%&quot; align=&quot;center&quot;&gt;&lt;/p&gt;

&lt;p&gt;My plans for the future is to merge my old scripts into the
battery-stats package, as my old scripts collected a lot more details
about the battery.  The scripts are merged into the upstream
battery-stats git repository already, but I am not convinced they work
yet, as I changed a lot of paths along the way.  Will have to test a
bit more before I make a new release.&lt;/p&gt;

&lt;p&gt;I will also consider changing the file format slightly, as I
suspect the way I combine several values into one field might make it
impossible to know the type of the value when using it for processing
and graphing.&lt;/p&gt;

&lt;p&gt;If you would like I would like to keep an close eye on your laptop
battery, check out the battery-stats package in
&lt;a href=&quot;https://tracker.debian.org/pkg/battery-stats&quot;&gt;Debian&lt;/a&gt; and
on
&lt;a href=&quot;https://github.com/petterreinholdtsen/battery-stats&quot;&gt;github&lt;/a&gt;.
I would love some help to improve the system further.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Creating, updating and checking debian/copyright semi-automatically</title>
                <link>http://people.skolelinux.org/pere/blog/Creating__updating_and_checking_debian_copyright_semi_automatically.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Creating__updating_and_checking_debian_copyright_semi_automatically.html</guid>
                <pubDate>Fri, 19 Feb 2016 15:00:00 +0100</pubDate>
                <description>&lt;p&gt;Making packages for Debian requires quite a lot of attention to
details.  And one of the details is the content of the
debian/copyright file, which should list all relevant licenses used by
the code in the package in question, preferably in
&lt;a href=&quot;https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/&quot;&gt;machine
readable DEP5 format&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;For large packages with lots of contributors it is hard to write
and update this file manually, and if you get some detail wrong, the
package is normally rejected by the ftpmasters.  So getting it right
the first time around get the package into Debian faster, and save
both you and the ftpmasters some work..  Today, while trying to figure
out what was wrong with
&lt;a href=&quot;https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447&quot;&gt;the
zfsonlinux copyright file&lt;/a&gt;, I decided to spend some time on
figuring out the options for doing this job automatically, or at least
semi-automatically.&lt;/p&gt;

&lt;p&gt;Lucikly, there are at least two tools available for generating the
file based on the code in the source package,
&lt;tt&gt;&lt;a href=&quot;https://tracker.debian.org/pkg/debmake&quot;&gt;debmake&lt;/a&gt;&lt;/tt&gt;
and &lt;tt&gt;&lt;a href=&quot;https://tracker.debian.org/pkg/cme&quot;&gt;cme&lt;/a&gt;&lt;/tt&gt;.  I&#39;m
not sure which one of them came first, but both seem to be able to
create a sensible draft file.  As far as I can tell, none of them can
be trusted to get the result just right, so the content need to be
polished a bit before the file is OK to upload.  I found the debmake
option in
&lt;a href=&quot;http://goofying-with-debian.blogspot.com/2014/07/debmake-checking-source-against-dep-5.html&quot;&gt;a
blog posts from 2014&lt;/a&gt;.

&lt;p&gt;To generate using debmake, use the -cc option:

&lt;p&gt;&lt;pre&gt;
debmake -cc &gt; debian/copyright
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Note there are some problems with python and non-ASCII names, so
this might not be the best option.&lt;/p&gt;

&lt;p&gt;The cme option is based on a config parsing library, and I found
this approach in
&lt;a href=&quot;https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/&quot;&gt;a
blog post from 2015&lt;/a&gt;.  To generate using cme, use the &#39;update
dpkg-copyright&#39; option:

&lt;p&gt;&lt;pre&gt;
cme update dpkg-copyright
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;This will create or update debian/copyright.  The cme tool seem to
handle UTF-8 names better than debmake.&lt;/p&gt;

&lt;p&gt;When the copyright file is created, I would also like some help to
check if the file is correct.  For this I found two good options,
&lt;tt&gt;debmake -k&lt;/tt&gt; and &lt;tt&gt;license-reconcile&lt;/tt&gt;.  The former seem
to focus on license types and file matching, and is able to detect
ineffective blocks in the copyright file.  The latter reports missing
copyright holders and years, but was confused by inconsistent license
names (like CDDL vs. CDDL-1.0).  I suspect it is good to use both and
fix all issues reported by them before uploading.  But I do not know
if the tools and the ftpmasters agree on what is important to fix in a
copyright file, so the package might still be rejected.&lt;/p&gt;

&lt;p&gt;The devscripts tool &lt;tt&gt;licensecheck&lt;/tt&gt; deserve mentioning.  It
will read through the source and try to find all copyright statements.
It is not comparing the result to the content of debian/copyright, but
can be useful when verifying the content of the copyright file.&lt;/p&gt;

&lt;p&gt;Are you aware of better tools in Debian to create and update
debian/copyright file.  Please let me know, or blog about it on
planet.debian.org.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2016-02-20&lt;/strong&gt;: I got a tip from Mike Gabriel
on how to use licensecheck and cdbs to create a draft copyright file

&lt;p&gt;&lt;pre&gt;
licensecheck --copyright -r `find * -type f` | \
  /usr/lib/cdbs/licensecheck2dep5 &gt; debian/copyright.auto
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;He mentioned that he normally check the generated file into the
version control system to make it easier to discover license and
copyright changes in the upstream source.  I will try to do the same
with my packages in the future.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2016-02-21&lt;/strong&gt;: The cme author recommended
against using -quiet for new users, so I removed it from the proposed
command line.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Using appstream in Debian to locate packages with firmware and mime type support</title>
                <link>http://people.skolelinux.org/pere/blog/Using_appstream_in_Debian_to_locate_packages_with_firmware_and_mime_type_support.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Using_appstream_in_Debian_to_locate_packages_with_firmware_and_mime_type_support.html</guid>
                <pubDate>Thu, 4 Feb 2016 16:40:00 +0100</pubDate>
                <description>&lt;p&gt;The &lt;a href=&quot;https://wiki.debian.org/DEP-11&quot;&gt;appstream system&lt;/a&gt;
is taking shape in Debian, and one provided feature is a very
convenient way to tell you which package to install to make a given
firmware file available when the kernel is looking for it.  This can
be done using apt-file too, but that is for someone else to blog
about. :)&lt;/p&gt;

&lt;p&gt;Here is a small recipe to find the package with a given firmware
file, in this example I am looking for ctfw-3.2.3.0.bin, randomly
picked from the set of firmware announced using appstream in Debian
unstable.  In general you would be looking for the firmware requested
by the kernel during kernel module loading.  To find the package
providing the example file, do like this:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
% apt install appstream
[...]
% apt update
[...]
% appstreamcli what-provides firmware:runtime ctfw-3.2.3.0.bin | \
  awk &#39;/Package:/ {print $2}&#39;
firmware-qlogic
%
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;See &lt;a href=&quot;https://wiki.debian.org/AppStream/Guidelines&quot;&gt;the
appstream wiki&lt;/a&gt; page to learn how to embed the package metadata in
a way appstream can use.&lt;/p&gt;

&lt;p&gt;This same approach can be used to find any package supporting a
given MIME type.  This is very useful when you get a file you do not
know how to handle.  First find the mime type using &lt;tt&gt;file
--mime-type&lt;/tt&gt;, and next look up the package providing support for
it.  Lets say you got an SVG file.  Its MIME type is image/svg+xml,
and you can find all packages handling this type like this:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
% apt install appstream
[...]
% apt update
[...]
% appstreamcli what-provides mimetype image/svg+xml | \
  awk &#39;/Package:/ {print $2}&#39;
bkchem
phototonic
inkscape
shutter
tetzle
geeqie
xia
pinta
gthumb
karbon
comix
mirage
viewnior
postr
ristretto
kolourpaint4
eog
eom
gimagereader
midori
%
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;I believe the MIME types are fetched from the desktop file for
packages providing appstream metadata.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Creepy, visualise geotagged social media information - nice free software</title>
                <link>http://people.skolelinux.org/pere/blog/Creepy__visualise_geotagged_social_media_information___nice_free_software.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Creepy__visualise_geotagged_social_media_information___nice_free_software.html</guid>
                <pubDate>Sun, 24 Jan 2016 10:50:00 +0100</pubDate>
                <description>&lt;p&gt;Most people seem not to realise that every time they walk around
with the computerised radio beacon known as a mobile phone their
position is tracked by the phone company and often stored for a long
time (like every time a SMS is received or sent).  And if their
computerised radio beacon is capable of running programs (often called
mobile apps) downloaded from the Internet, these programs are often
also capable of tracking their location (if the app requested access
during installation).  And when these programs send out information to
central collection points, the location is often included, unless
extra care is taken to not send the location.  The provided
information is used by several entities, for good and bad (what is
good and bad, depend on your point of view).  What is certain, is that
the private sphere and the right to free movement is challenged and
perhaps even eradicated for those announcing their location this way,
when they share their whereabouts with private and public
entities.&lt;/p&gt;

&lt;p align=&quot;center&quot;&gt;&lt;img width=&quot;70%&quot; src=&quot;http://people.skolelinux.org/pere/blog/images/2016-01-24-nice-creepy-desktop-window.png&quot;&gt;&lt;/p&gt;

&lt;p&gt;The phone company logs provide a register of locations to check out
when one want to figure out what the tracked person was doing.  It is
unavailable for most of us, but provided to selected government
officials, company staff, those illegally buying information from
unfaithful servants and crackers stealing the information.  But the
public information can be collected and analysed, and a free software
tool to do so is called
&lt;a href=&quot;http://www.geocreepy.com/&quot;&gt;Creepy or Cree.py&lt;/a&gt;.  I
discovered it when I read
&lt;a href=&quot;http://www.aftenposten.no/kultur/Slik-kan-du-bli-overvaket-pa-Twitter-og-Instagram-uten-a-ane-det-7787884.html&quot;&gt;an
article about Creepy&lt;/a&gt; in the Norwegian newspaper Aftenposten i
November 2014, and decided to check if it was available in Debian.
The python program was in Debian, but
&lt;a href=&quot;https://tracker.debian.org/pkg/creepy&quot;&gt;the version in
Debian&lt;/a&gt; was completely broken and practically unmaintained.  I
uploaded a new version which did not work quite right, but did not
have time to fix it then.  This Christmas I decided to finally try to
get Creepy operational in Debian.  Now a fixed version is available in
Debian unstable and testing, and almost all Debian specific patches
are now included
&lt;a href=&quot;https://github.com/jkakavas/creepy&quot;&gt;upstream&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;The Creepy program visualises geolocation information fetched from
Twitter, Instagram, Flickr and Google+, and allow one to get a
complete picture of every social media message posted recently in a
given area, or track the movement of a given individual across all
these services.  Earlier it was possible to use the search API of at
least some of these services without identifying oneself, but these
days it is impossible.  This mean that to use Creepy, you need to
configure it to log in as yourself on these services, and provide
information to them about your search interests.  This should be taken
into account when using Creepy, as it will also share information
about yourself with the services.&lt;/p&gt;

&lt;p&gt;The picture above show the twitter messages sent from (or at least
geotagged with a position from) the city centre of Oslo, the capital
of Norway.  One useful way to use Creepy is to first look at
information tagged with an area of interest, and next look at all the
information provided by one or more individuals who was in the area.
I tested it by checking out which celebrity provide their location in
twitter messages by checkout out who sent twitter messages near a
Norwegian TV station, and next could track their position over time,
making it possible to locate their home and work place, among other
things.  A similar technique have been
&lt;a href=&quot;http://www.buzzfeed.com/maxseddon/does-this-soldiers-instagram-account-prove-russia-is-covertl&quot;&gt;used
to locate Russian soldiers in Ukraine&lt;/a&gt;, and it is both a powerful
tool to discover lying governments, and a useful tool to help people
understand the value of the private information they provide to the
public.&lt;/p&gt;

&lt;p&gt;The package is not trivial to backport to Debian Stable/Jessie, as
it depend on several python modules currently missing in Jessie (at
least python-instagram, python-flickrapi and
python-requests-toolbelt).&lt;/p&gt;

&lt;p&gt;(I have uploaded
&lt;a href=&quot;https://screenshots.debian.net/package/creepy&quot;&gt;the image to
screenshots.debian.net&lt;/a&gt; and licensed it under the same terms as the
Creepy program in Debian.)&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Always download Debian packages using Tor - the simple recipe</title>
                <link>http://people.skolelinux.org/pere/blog/Always_download_Debian_packages_using_Tor___the_simple_recipe.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Always_download_Debian_packages_using_Tor___the_simple_recipe.html</guid>
                <pubDate>Fri, 15 Jan 2016 00:30:00 +0100</pubDate>
                <description>&lt;p&gt;During his DebConf15 keynote, Jacob Appelbaum
&lt;a href=&quot;https://summit.debconf.org/debconf15/meeting/331/what-is-to-be-done/&quot;&gt;observed
that those listening on the Internet lines would have good reason to
believe a computer have a given security hole&lt;/a&gt; if it download a
security fix from a Debian mirror.  This is a good reason to always
use encrypted connections to the Debian mirror, to make sure those
listening do not know which IP address to attack.  In August, Richard
Hartmann observed that encryption was not enough, when it was possible
to interfere download size to security patches or the fact that
download took place shortly after a security fix was released, and
&lt;a href=&quot;http://richardhartmann.de/blog/posts/2015/08/24-Tor-enabled_Debian_mirror/&quot;&gt;proposed
to always use Tor to download packages from the Debian mirror&lt;/a&gt;.  He
was not the first to propose this, as the
&lt;tt&gt;&lt;a href=&quot;https://tracker.debian.org/pkg/apt-transport-tor&quot;&gt;apt-transport-tor&lt;/a&gt;&lt;/tt&gt;
package by Tim Retout already existed to make it easy to convince apt
to use &lt;a href=&quot;https://www.torproject.org/&quot;&gt;Tor&lt;/a&gt;, but I was not
aware of that package when I read the blog post from Richard.&lt;/p&gt;

&lt;p&gt;Richard discussed the idea with Peter Palfrader, one of the Debian
sysadmins, and he set up a Tor hidden service on one of the central
Debian mirrors using the address vwakviie2ienjx6t.onion, thus making
it possible to download packages directly between two tor nodes,
making sure the network traffic always were encrypted.&lt;/p&gt;

&lt;p&gt;Here is a short recipe for enabling this on your machine, by
installing &lt;tt&gt;apt-transport-tor&lt;/tt&gt; and replacing http and https
urls with tor+http and tor+https, and using the hidden service instead
of the official Debian mirror site.  I recommend installing
&lt;tt&gt;etckeeper&lt;/tt&gt; before you start to have a history of the changes
done in /etc/.&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
apt install apt-transport-tor
sed -i &#39;s% http://ftp.debian.org/% tor+http://vwakviie2ienjx6t.onion/%&#39; /etc/apt/sources.list
sed -i &#39;s% http% tor+http%&#39; /etc/apt/sources.list
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;If you have more sources listed in /etc/apt/sources.list.d/, run
the sed commands for these too.  The sed command is assuming your are
using the ftp.debian.org Debian mirror.  Adjust the command (or just
edit the file manually) to match your mirror.&lt;/p&gt;

&lt;p&gt;This work in Debian Jessie and later.  Note that tools like
&lt;tt&gt;apt-file&lt;/tt&gt; only recently started using the apt transport
system, and do not work with these tor+http URLs.  For
&lt;tt&gt;apt-file&lt;/tt&gt; you need the version currently in experimental,
which need a recent apt version currently only in unstable.  So if you
need a working &lt;tt&gt;apt-file&lt;/tt&gt;, this is not for you.&lt;/p&gt;

&lt;p&gt;Another advantage from this change is that your machine will start
using Tor regularly and at fairly random intervals (every time you
update the package lists or upgrade or install a new package), thus
masking other Tor traffic done from the same machine.  Using Tor will
become normal for the machine in question.&lt;/p&gt;

&lt;p&gt;On &lt;a href=&quot;https://wiki.debian.org/FreedomBox&quot;&gt;Freedombox&lt;/a&gt;, APT
is set up by default to use &lt;tt&gt;apt-transport-tor&lt;/tt&gt; when Tor is
enabled.  It would be great if it was the default on any Debian
system.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Nedlasting fra NRK, som Matroska med undertekster</title>
                <link>http://people.skolelinux.org/pere/blog/Nedlasting_fra_NRK__som_Matroska_med_undertekster.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Nedlasting_fra_NRK__som_Matroska_med_undertekster.html</guid>
                <pubDate>Sat, 2 Jan 2016 13:50:00 +0100</pubDate>
                <description>&lt;p&gt;Det kommer stadig nye løsninger for å ta lagre unna innslag fra NRK
for å se på det senere.  For en stund tilbake kom jeg over et script
nrkopptak laget av Ingvar Hagelund.  Han fjernet riktignok sitt script
etter forespørsel fra Erik Bolstad i NRK, men noen tok heldigvis og
gjorde det &lt;a href=&quot;https://github.com/liangqi/nrkopptak&quot;&gt;tilgjengelig
via github&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Scriptet kan lagre som MPEG4 eller Matroska, og bake inn
undertekster i fila på et vis som blant annet VLC forstår.  For å
bruke scriptet, kopier ned git-arkivet og kjør&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
nrkopptak/bin/nrk-opptak k &lt;ahref=&quot;https://tv.nrk.no/serie/bmi-turne/MUHH45000115/sesong-1/episode-1&quot;&gt;https://tv.nrk.no/serie/bmi-turne/MUHH45000115/sesong-1/episode-1&lt;/a&gt;
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;URL-eksemplet er dagens toppsak på tv.nrk.no.  Argument &#39;k&#39; ber
scriptet laste ned og lagre som Matroska.  Det finnes en rekke andre
muligheter for valg av kvalitet og format.&lt;/p&gt;

&lt;p&gt;Jeg foretrekker dette scriptet fremfor youtube-dl, som
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Hvordan_enkelt_laste_ned_filmer_fra_NRK_med_den__nye__l_sningen.html&quot;&gt;
nevnt i 2014 støtter NRK&lt;/a&gt; og en rekke andre videokilder, på grunn
av at nrkopptak samler undertekster og video i en enkelt fil, hvilket
gjør håndtering enklere på disk.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>OpenALPR, find car license plates in video streams - nice free software</title>
                <link>http://people.skolelinux.org/pere/blog/OpenALPR__find_car_license_plates_in_video_streams___nice_free_software.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/OpenALPR__find_car_license_plates_in_video_streams___nice_free_software.html</guid>
                <pubDate>Wed, 23 Dec 2015 01:00:00 +0100</pubDate>
                <description>&lt;p&gt;When I was a kid, we used to collect &quot;car numbers&quot;, as we used to
call the car license plate numbers in those days.  I would write the
numbers down in my little book and compare notes with the other kids
to see how many region codes we had seen and if we had seen some
exotic or special region codes and numbers.  It was a fun game to pass
time, as we kids have plenty of it.&lt;/p&gt;

&lt;p&gt;A few days I came across
&lt;a href=&quot;https://github.com/openalpr/openalpr&quot;&gt;the OpenALPR
project&lt;/a&gt;, a free software project to automatically discover and
report license plates in images and video streams, and provide the
&quot;car numbers&quot; in a machine readable format.  I&#39;ve been looking for
such system for a while now, because I believe it is a bad idea that the
&lt;a href=&quot;https://en.wikipedia.org/wiki/Automatic_number_plate_recognition&quot;&gt;automatic
number plate recognition&lt;/a&gt; tool only is available in the hands of
the powerful, and want it to be available also for the powerless to
even the score when it comes to surveillance and sousveillance.  I
discovered the developer
&lt;a href=&quot;https://bugs.debian.org/747509&quot;&gt;wanted to get the tool into
Debian&lt;/a&gt;, and as I too wanted it to be in Debian, I volunteered to
help him get it into shape to get the package uploaded into the Debian
archive.&lt;/p&gt;

&lt;p&gt;Today we finally managed to get the package into shape and uploaded
it into Debian, where it currently
&lt;a href=&quot;https://ftp-master.debian.org//new/openalpr_2.2.1-1.html&quot;&gt;waits
in the NEW queue&lt;/a&gt; for review by the Debian ftpmasters.&lt;/p&gt;

&lt;p&gt;I guess you are wondering why on earth such tool would be useful
for the common folks, ie those not running a large government
surveillance system?  Well, I plan to put it in a computer on my bike
and in my car, tracking the cars nearby and allowing me to be notified
when number plates on my watch list are discovered.  Another use case
was suggested by a friend of mine, who wanted to set it up at his home
to open the car port automatically when it discovered the plate on his
car.  When I mentioned it perhaps was a bit foolhardy to allow anyone
capable of placing his license plate number of a piece of cardboard to
open his car port, men replied that it was always unlocked anyway.  I
guess for such use case it make sense.  I am sure there are other use
cases too, for those with imagination and a vision.&lt;/p&gt;

&lt;p&gt;If you want to build your own version of the Debian package, check
out the upstream git source and symlink ./distros/debian to ./debian/
before running &quot;debuild&quot; to build the source.  Or wait a bit until the
package show up in unstable.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>