- <div class="title"><a href="http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html">Using appstream with isenkram to install hardware related packages in Debian</a></div>
- <div class="date">20th December 2015</div>
- <div class="body"><p>Around three years ago, I created
-<a href="http://packages.qa.debian.org/isenkram">the isenkram
-system</a> to get a more practical solution in Debian for handing
-hardware related packages. A GUI system in the isenkram package will
-present a pop-up dialog when some hardware dongle supported by
-relevant packages in Debian is inserted into the machine. The same
-lookup mechanism to detect packages is available as command line
-tools in the isenkram-cli package. In addition to mapping hardware,
-it will also map kernel firmware files to packages and make it easy to
-install needed firmware packages automatically. The key for this
-system to work is a good way to map hardware to packages, in other
-words, allow packages to announce what hardware they will work
-with.</p>
-
-<p>I started by providing data files in the isenkram source, and
-adding code to download the latest version of these data files at run
-time, to ensure every user had the most up to date mapping available.
-I also added support for storing the mapping in the Packages file in
-the apt repositories, but did not push this approach because while I
-was trying to figure out how to best store hardware/package mappings,
-<a href="http://www.freedesktop.org/software/appstream/docs/">the
-appstream system</a> was announced. I got in touch and suggested to
-add the hardware mapping into that data set to be able to use
-appstream as a data source, and this was accepted at least for the
-Debian version of appstream.</p>
-
-<p>A few days ago using appstream in Debian for this became possible,
-and today I uploaded a new version 0.20 of isenkram adding support for
-appstream as a data source for mapping hardware to packages. The only
-package so far using appstream to announce its hardware support is my
-pymissile package. I got help from Matthias Klumpp with figuring out
-how do add the required
-<a href="https://appstream.debian.org/html/sid/main/metainfo/pymissile.html">metadata
-in pymissile</a>. I added a file debian/pymissile.metainfo.xml with
-this content:</p>
-
-<blockquote><pre>
-<?xml version="1.0" encoding="UTF-8"?>
-<component>
- <id>pymissile</id>
- <metadata_license>MIT</metadata_license>
- <name>pymissile</name>
- <summary>Control original Striker USB Missile Launcher</summary>
- <description>
- <p>
- Pymissile provides a curses interface to control an original
- Marks and Spencer / Striker USB Missile Launcher, as well as a
- motion control script to allow a webcamera to control the
- launcher.
- </p>
- </description>
- <provides>
- <modalias>usb:v1130p0202d*</modalias>
- </provides>
-</component>
-</pre></blockquote>
-
-<p>The key for isenkram is the component/provides/modalias value,
-which is a glob style match rule for hardware specific strings
-(modalias strings) provided by the Linux kernel. In this case, it
-will map to all USB devices with vendor code 1130 and product code
-0202.</p>
-
-<p>Note, it is important that the license of all the metadata files
-are compatible to have permissions to aggregate them into archive wide
-appstream files. Matthias suggested to use MIT or BSD licenses for
-these files. A challenge is figuring out a good id for the data, as
-it is supposed to be globally unique and shared across distributions
-(in other words, best to coordinate with upstream what to use). But
-it can be changed later or, so we went with the package name as
-upstream for this project is dormant.</p>
-
-<p>To get the metadata file installed in the correct location for the
-mirror update scripts to pick it up and include its content the
-appstream data source, the file must be installed in the binary
-package under /usr/share/appdata/. I did this by adding the following
-line to debian/pymissile.install:</p>
-
-<blockquote><pre>
-debian/pymissile.metainfo.xml usr/share/appdata
-</pre></blockquote>
-
-<p>With that in place, the command line tool isenkram-lookup will list
-all packages useful on the current computer automatically, and the GUI
-pop-up handler will propose to install the package not already
-installed if a hardware dongle is inserted into the machine in
-question.</p>
-
-<p>Details of the modalias field in appstream is available from the
-<a href="https://wiki.debian.org/DEP-11">DEP-11</a> proposal.</p>
-
-<p>To locate the modalias values of all hardware present in a machine,
-try running this command on the command line:</p>
-
-<blockquote><pre>
-cat $(find /sys/devices/|grep modalias)
-</pre></blockquote>
-
-<p>To learn more about the isenkram system, please check out
-<a href="http://people.skolelinux.org/pere/blog/tags/isenkram/">my
-blog posts tagged isenkram</a>.</p>
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Free_software_archive_system_Nikita_now_able_to_store_documents.html">Free software archive system Nikita now able to store documents</a></div>
+ <div class="date">19th March 2017</div>
+ <div class="body"><p>The <a href="https://github.com/hiOA-ABI/nikita-noark5-core">Nikita
+Noark 5 core project</a> is implementing the Norwegian standard for
+keeping an electronic archive of government documents.
+<a href="http://www.arkivverket.no/arkivverket/Offentlig-forvaltning/Noark/Noark-5/English-version">The
+Noark 5 standard</a> document the requirement for data systems used by
+the archives in the Norwegian government, and the Noark 5 web interface
+specification document a REST web service for storing, searching and
+retrieving documents and metadata in such archive. I've been involved
+in the project since a few weeks before Christmas, when the Norwegian
+Unix User Group
+<a href="https://www.nuug.no/news/NOARK5_kjerne_som_fri_programvare_f_r_epostliste_hos_NUUG.shtml">announced
+it supported the project</a>. I believe this is an important project,
+and hope it can make it possible for the government archives in the
+future to use free software to keep the archives we citizens depend
+on. But as I do not hold such archive myself, personally my first use
+case is to store and analyse public mail journal metadata published
+from the government. I find it useful to have a clear use case in
+mind when developing, to make sure the system scratches one of my
+itches.</p>
+
+<p>If you would like to help make sure there is a free software
+alternatives for the archives, please join our IRC channel
+(<a href="irc://irc.freenode.net/%23nikita"">#nikita on
+irc.freenode.net</a>) and
+<a href="https://lists.nuug.no/mailman/listinfo/nikita-noark">the
+project mailing list</a>.</p>
+
+<p>When I got involved, the web service could store metadata about
+documents. But a few weeks ago, a new milestone was reached when it
+became possible to store full text documents too. Yesterday, I
+completed an implementation of a command line tool
+<tt>archive-pdf</tt> to upload a PDF file to the archive using this
+API. The tool is very simple at the moment, and find existing
+<a href="https://en.wikipedia.org/wiki/Fonds">fonds</a>, series and
+files while asking the user to select which one to use if more than
+one exist. Once a file is identified, the PDF is associated with the
+file and uploaded, using the title extracted from the PDF itself. The
+process is fairly similar to visiting the archive, opening a cabinet,
+locating a file and storing a piece of paper in the archive. Here is
+a test run directly after populating the database with test data using
+our API tester:</p>
+
+<p><blockquote><pre>
+~/src//noark5-tester$ ./archive-pdf mangelmelding/mangler.pdf
+using arkiv: Title of the test fonds created 2017-03-18T23:49:32.103446
+using arkivdel: Title of the test series created 2017-03-18T23:49:32.103446
+
+ 0 - Title of the test case file created 2017-03-18T23:49:32.103446
+ 1 - Title of the test file created 2017-03-18T23:49:32.103446
+Select which mappe you want (or search term): 0
+Uploading mangelmelding/mangler.pdf
+ PDF title: Mangler i spesifikasjonsdokumentet for NOARK 5 Tjenestegrensesnitt
+ File 2017/1: Title of the test case file created 2017-03-18T23:49:32.103446
+~/src//noark5-tester$
+</pre></blockquote></p>
+
+<p>You can see here how the fonds (arkiv) and serie (arkivdel) only had
+one option, while the user need to choose which file (mappe) to use
+among the two created by the API tester. The <tt>archive-pdf</tt>
+tool can be found in the git repository for the API tester.</p>
+
+<p>In the project, I have been mostly working on
+<a href="https://github.com/petterreinholdtsen/noark5-tester">the API
+tester</a> so far, while getting to know the code base. The API
+tester currently use
+<a href="https://en.wikipedia.org/wiki/HATEOAS">the HATEOAS links</a>
+to traverse the entire exposed service API and verify that the exposed
+operations and objects match the specification, as well as trying to
+create objects holding metadata and uploading a simple XML file to
+store. The tester has proved very useful for finding flaws in our
+implementation, as well as flaws in the reference site and the
+specification.</p>
+
+<p>The test document I uploaded is a summary of all the specification
+defects we have collected so far while implementing the web service.
+There are several unclear and conflicting parts of the specification,
+and we have
+<a href="https://github.com/petterreinholdtsen/noark5-tester/tree/master/mangelmelding">started
+writing down</a> the questions we get from implementing it. We use a
+format inspired by how <a href="http://www.opengroup.org/austin/">The
+Austin Group</a> collect defect reports for the POSIX standard with
+<a href="http://www.opengroup.org/austin/mantis.html">their
+instructions for the MANTIS defect tracker system</a>, in lack of an official way to structure defect reports for Noark 5 (our first submitted defect report was a <a href="https://github.com/petterreinholdtsen/noark5-tester/blob/master/mangelmelding/sendt/2017-03-15-mangel-prosess.md">request for a procedure for submitting defect reports</a> :).
+
+<p>The Nikita project is implemented using Java and Spring, and is
+fairly easy to get up and running using Docker containers for those
+that want to test the current code base. The API tester is
+implemented in Python.</p>
projects / homepage.git / blobdiff