Petter Reinholdtsen

The LinuxCNC project is still going strong. And I believe this great software system for numerical control of machines such as milling machines, lathes, plasma cutters, routers, cutting machines, robots and hexapods, would do even better with more in-person developer gatherings, so we plan to organise such gathering this summer too.

The Norwegian LinuxCNC developer gathering take place the weekend Friday July 5th to 7th this year, and is open for everyone interested in contributing to LinuxCNC and free software manufacturing. Up to date information about the gathering can be found in the developer mailing list thread where the gathering was announced. Thanks to the good people at Debian as well as leftover money from last years gathering from Redpill-Linpro and NUUG Foundation, we have enough sponsor funds to pay for food, and probably also shelter for the people traveling from afar to join us. If you would like to join the gathering, get in touch and add your details on the pad.

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

Nine days ago, I started migrating orphaned Debian packages with no version control system listed in debian/control of the source to git. At the time there were 438 such packages. Now there are 391, according to the UDD. In reality it is slightly less, as there is a delay between uploads and UDD updates. In the nine days since, I have thus been able to work my way through ten percent of the packages. I am starting to run out of steam, and hope someone else will also help brushing some dust of these packages. Here is a recipe how to do it. I start by picking a random package by querying the UDD for a list of 10 random packages from the set of remaining packages:

PGPASSWORD="udd-mirror" psql --port=5432 --host=udd-mirror.debian.net \
  --username=udd-mirror udd -c "select source from sources \
   where release = 'sid' and (vcs_url ilike '%anonscm.debian.org%' \
   OR vcs_browser ilike '%anonscm.debian.org%' or vcs_url IS NULL \
   OR vcs_browser IS NULL) AND maintainer ilike '%packages@qa.debian.org%' \
   order by random() limit 10;"

Next, I visit http://salsa.debian.org/debian and search for the package name, to ensure no git repository already exist. If it does, I clone it and try to get it to an uploadable state, and add the Vcs-* entries in d/control to make the repository more widely known. These packages are a minority, so I will not cover that use case here.

For packages without an existing git repository, I run the following script debian-snap-to-salsa to prepare a git repository with the existing packaging.

#!/bin/sh
#
# See also https://bugs.debian.org/804722#31

set -e

# Move to this Standards-Version.
SV_LATEST=4.7.0

PKG="$1"

if [ -z "$PKG" ]; then
    echo "usage: $0 "
    exit 1
fi

if [ -e "${PKG}-salsa" ]; then
    echo "error: ${PKG}-salsa already exist, aborting."
    exit 1
fi

if [ -z "ALLOWFAILURE" ] ; then
    ALLOWFAILURE=false
fi

# Fetch every snapshotted source package.  Manually loop until all
# transfers succeed, as 'gbp import-dscs --debsnap' do not fail on
# download failures.
until debsnap --force -v $PKG || $ALLOWFAILURE ; do sleep 1; done
mkdir ${PKG}-salsa; cd ${PKG}-salsa
git init

# Specify branches to override any debian/gbp.conf file present in the
# source package.
gbp import-dscs  --debian-branch=master --upstream-branch=upstream \
    --pristine-tar ../source-$PKG/*.dsc

# Add Vcs pointing to Salsa Debian project (must be manually created
# and pushed to).
if ! grep -q ^Vcs- debian/control ; then
    awk "BEGIN { s=1 } /^\$/ { if (s==1) { print \"Vcs-Browser: https://salsa.debian.org/debian/$PKG\"; print \"Vcs-Git: https://salsa.debian.org/debian/$PKG.git\" }; s=0 } { print }" < debian/control > debian/control.new && mv debian/control.new debian/control
    git commit -m "Updated vcs in d/control to Salsa." debian/control
fi

# Tell gbp to enforce the use of pristine-tar.
inifile +inifile debian/gbp.conf +create +section DEFAULT +key pristine-tar +value True
git add debian/gbp.conf
git commit -m "Added d/gbp.conf to enforce the use of pristine-tar." debian/gbp.conf

# Update to latest Standards-Version.
SV="$(grep ^Standards-Version: debian/control|awk '{print $2}')"
if [ $SV_LATEST != $SV ]; then
    sed -i "s/\(Standards-Version: \)\(.*\)/\1$SV_LATEST/" debian/control
    git commit -m "Updated Standards-Version from $SV to $SV_LATEST." debian/control
fi

if grep -q pkg-config debian/control; then
    sed -i s/pkg-config/pkgconf/ debian/control
    git commit -m "Replaced obsolete pkg-config build dependency with pkgconf." debian/control
fi

if grep -q libncurses5-dev debian/control; then
    sed -i s/libncurses5-dev/libncurses-dev/ debian/control
    git commit -m "Replaced obsolete libncurses5-dev build dependency with libncurses-dev." debian/control
fi

Some times the debsnap script fail to download some of the versions. In those cases I investigate, and if I decide the failing versions will not be missed, I call it using ALLOWFAILURE=true to ignore the problem and create the git repository anyway.

With the git repository in place, I do a test build (gbp buildpackage) to ensure the build is actually working. If it does not I pick a different package, or if the build failure is trivial to fix, I fix it before continuing. At this stage I revisit http://salsa.debian.org/debian and create the project under this group for the package. I then follow the instructions to publish the local git repository. Here is from a recent example:

git remote add origin git@salsa.debian.org:debian/perl-byacc.git
git push --set-upstream origin master upstream pristine-tar
git push --tags

With a working build, I have a look at the build rules if I want to remove some more dust. I normally try to move to debhelper compat level 13, which involves removing debian/compat and modifying debian/control to build depend on debhelper-compat (=13). I also test with 'Rules-Requires-Root: no' in debian/control and verify in debian/rules that hardening is enabled, and include all of these if the package still build. If it fail to build with level 13, I try with 12, 11, 10 and so on until I find a level where it build, as I do not want to spend a lot of time fixing build issues.

Some times, when I feel inspired, I make sure debian/copyright is converted to the machine readable format, often by starting with 'debhelper -cc' and then cleaning up the autogenerated content until it matches realities. If I feel like it, I might also clean up non-dh-based debian/rules files to use the short style dh build rules.

Once I have removed all the dust I care to process for the package, I run 'gbp dch' to generate a debian/changelog entry based on the commits done so far, run 'dch -r' to switch from 'UNRELEASED' to 'unstable' and get an editor to make sure the 'QA upload' marker is in place and that all long commit descriptions are wrapped into sensible lengths, run 'debcommit --release -a' to commit and tag the new debian/changelog entry, run 'debuild -S' to build a source only package, and 'dput ../perl-byacc_2.0-10_source.changes' to do the upload. During the entire process, and many times per step, I run 'debuild' to verify the changes done still work. I also some times verify the set of built files using 'find debian' to see if I can spot any problems (like no file in usr/bin any more or empty package). I also try to fix all lintian issues reported at the end of each 'debuild' run.

If I find Debian specific patches, I try to ensure their metadata is fairly up to date and some times I even try to reach out to upstream, to make the upstream project aware of the patches. Most of my emails bounce, so the success rate is low. For projects with no Homepage entry in debian/control I try to track down one, and for packages with no debian/watch file I try to create one. But at least for some of the packages I have been unable to find a functioning upstream, and must skip both of these.

If I could handle ten percent in nine days, twenty people could complete the rest in less then five days. I use approximately twenty minutes per package, when I have twenty minutes spare time to spend. Perhaps you got twenty minutes to spare too?

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

Update 2024-05-04: There is an updated edition of my migration script, last updated 2024-05-04.

I am happy to report that the megactl package, useful to fetch RAID status when using the LSI Megaraid controller, now is available in Debian. It passed NEW a few days ago, and is now available in unstable, and probably showing up in testing in a weeks time. The new version should provide Appstream hardware mapping and should integrate nicely with isenkram.

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

There are several packages in Debian without a associated git repository with the packaging history. This is unfortunate and it would be nice if more of these would do so. Quote a lot of these are without a maintainer, ie listed as maintained by the 'Debian QA Group' place holder. In fact, 438 packages have this property according to UDD (SELECT source FROM sources WHERE release = 'sid' AND (vcs_url ilike '%anonscm.debian.org%' OR vcs_browser ilike '%anonscm.debian.org%' or vcs_url IS NULL OR vcs_browser IS NULL) AND maintainer ilike '%packages@qa.debian.org%';). Such packages can be updated without much coordination by any Debian developer, as they are considered orphaned.

To try to improve the situation and reduce the number of packages without associated git repository, I started a few days ago to search out candiates and provide them with a git repository under the 'debian' collaborative Salsa project. I started with the packages pointing to obsolete Alioth git repositories, and am now working my way across the ones completely without git references. In addition to updating the Vcs-* debian/control fields, I try to update Standards-Version, debhelper compat level, simplify d/rules, switch to Rules-Requires-Root: no and fix lintian issues reported. I only implement those that are trivial to fix, to avoid spending too much time on each orphaned package. So far my experience is that it take aproximately 20 minutes to convert a package without any git references, and a lot more for packages with existing git repositories incompatible with git-buildpackages.

So far I have converted 10 packages, and I will keep going until I run out of steam. As should be clear from the numbers, there is enough packages remaining for more people to do the same without stepping on each others toes. I find it useful to start by searching for a git repo already on salsa, as I find that some times a git repo has already been created, but no new version is uploaded to Debian yet. In those cases I start with the existing git repository. I convert to the git-buildpackage+pristine-tar workflow, and ensure a debian/gbp.conf file with "pristine-tar=True" is added early, to avoid uploading a orig.tar.gz with the wrong checksum by mistake. Did that three times in the begin before I remembered my mistake.

So, if you are a Debian Developer and got some spare time, perhaps considering migrating some orphaned packages to git?

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

A while back I wrote a small script to extract the Bitcoin transactions in a wallet in the ledger plain text accounting format. The last few days I spent some time to get it working better with more special cases. In case it can be useful for others, here is a copy:

#!/usr/bin/python3
#  -*- coding: utf-8 -*-
#  Copyright (c) 2023-2024 Petter Reinholdtsen

from decimal import Decimal
import json
import subprocess
import time

import numpy

def format_float(num):
    return numpy.format_float_positional(num, trim='-')

accounts = {
    u'amount' : 'Assets:BTC:main',
}

addresses = {
    '' : 'Assets:bankkonto',
    '' : 'Assets:bankkonto',
}

def exec_json(cmd):
    proc = subprocess.Popen(cmd,stdout=subprocess.PIPE)
    j = json.loads(proc.communicate()[0], parse_float=Decimal)
    return j

def list_txs():
    # get all transactions for all accounts / addresses
    c = 0
    txs = []
    txidfee = {}
    limit=100000
    cmd = ['bitcoin-cli', 'listtransactions', '*', str(limit)]
    if True:
        txs.extend(exec_json(cmd))
    else:
        # Useful for debugging
        with open('transactions.json') as f:
            txs.extend(json.load(f, parse_float=Decimal))
    #print txs
    for tx in sorted(txs, key=lambda a: a['time']):
#        print tx['category']
        if 'abandoned' in tx and tx['abandoned']:
            continue
        if 'confirmations' in tx and 0 >= tx['confirmations']:
            continue
        when = time.strftime('%Y-%m-%d %H:%M', time.localtime(tx['time']))
        if 'message' in tx:
            desc = tx['message']
        elif 'comment' in tx:
            desc = tx['comment']
        elif 'label' in tx:
            desc = tx['label']
        else:
            desc = 'n/a'
        print("%s %s" % (when, desc))
        if 'address' in tx:
            print("  ; to bitcoin address %s" % tx['address'])
        else:
            print("  ; missing address in transaction, txid=%s" % tx['txid'])
        print(f"  ; amount={tx['amount']}")
        if 'fee'in tx:
            print(f"  ; fee={tx['fee']}")
        for f in accounts.keys():
            if f in tx and Decimal(0) != tx[f]:
                amount = tx[f]
                print("  %-20s   %s BTC" % (accounts[f], format_float(amount)))
        if 'fee' in tx and Decimal(0) != tx['fee']:
            # Make sure to list fee used in several transactions only once.
            if 'fee' in tx and tx['txid'] in txidfee \
               and tx['fee'] == txidfee[tx['txid']]:
                True
            else:
                fee = tx['fee']
                print("  %-20s   %s BTC" % (accounts['amount'], format_float(fee)))
                print("  %-20s   %s BTC" % ('Expences:BTC-fee', format_float(-fee)))
                txidfee[tx['txid']] = tx['fee']

        if 'address' in tx and tx['address'] in addresses:
            print("  %s" % addresses[tx['address']])
        else:
            if 'generate' == tx['category']:
                print("  Income:BTC-mining")
            else:
                if amount < Decimal(0):
                    print(f"  Assets:unknown:sent:update-script-addr-{tx['address']}")
                else:
                    print(f"  Assets:unknown:received:update-script-addr-{tx['address']}")

        print()
        c = c + 1
    print("# Found %d transactions" % c)
    if limit == c:
        print(f"# Warning: Limit {limit} reached, consider increasing limit.")

def main():
    list_txs()

main()

It is more of a proof of concept, and I do not expect it to handle all edge cases, but it worked for me, and perhaps you can find it useful too.

To get a more interesting result, it is useful to map accounts sent to or received from to accounting accounts, using the addresses hash. As these will be very context dependent, I leave out my list to allow each user to fill out their own list of accounts. Out of the box, 'ledger reg BTC:main' should be able to show the amount of BTCs present in the wallet at any given time in the past. For other and more valuable analysis, a account plan need to be set up in the addresses hash. Here is an example transaction:

2024-03-07 17:00 Donated to good cause
    Assets:BTC:main                           -0.1 BTC
    Assets:BTC:main                       -0.00001 BTC
    Expences:BTC-fee                       0.00001 BTC
    Expences:donations                         0.1 BTC

It need a running Bitcoin Core daemon running, as it connect to it using bitcoin-cli listtransactions * 100000 to extract the transactions listed in the Wallet.

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

The last few days I have revisited RAID setup using the LSI Megaraid controller. These are a family of controllers called PERC by Dell, and is present in several old PowerEdge servers, and I recently got my hands on one of these. I had forgotten how to handle this RAID controller in Debian, so I had to take a peek in the Debian wiki page "Linux and Hardware RAID: an administrator's summary" to remember what kind of software is available to configure and monitor the disks and controller. I prefer Free Software alternatives to proprietary tools, as the later tend to fall into disarray once the manufacturer loose interest, and often do not work with newer Linux Distributions. Sadly there is no free software tool to configure the RAID setup, only to monitor it. RAID can provide improved reliability and resilience in a storage solution, but only if it is being regularly checked and any broken disks are being replaced in time. I thus want to ensure some automatic monitoring is available.

In the discovery process, I came across a old free software tool to monitor PERC2, PERC3, PERC4 and PERC5 controllers, which to my surprise is not present in debian. To help change that I created a request for packaging of the megactl package, and tried to track down a usable version. The original project site is on Sourceforge, but as far as I can tell that project has been dead for more than 15 years. I managed to find a more recent fork on github from user hmage, but it is unclear to me if this is still being maintained. It has not seen much improvements since 2016. A more up to date edition is a git fork from the original github fork by user namiltd, and this newer fork seem a lot more promising. The owner of this github repository has replied to change proposals within hours, and had already added some improvements and support for more hardware. Sadly he is reluctant to commit to maintaining the tool and stated in my first pull request that he think a new release should be made based on the git repository owned by hmage. I perfectly understand this reluctance, as I feel the same about maintaining yet another package in Debian when I barely have time to take care of the ones I already maintain, but do not really have high hopes that hmage will have time to spend on it and hope namiltd will change his mind.

In any case, I created a draft package based on the namiltd edition and put it under the debian group on salsa.debian.org. If you own a Dell PowerEdge server with one of the PERC controllers, or any other RAID controller using the megaraid or megaraid_sas Linux kernel modules, you might want to check it out. If enough people are interested, perhaps the package will make it into the Debian archive.

There are two tools provided, megactl for the megaraid Linux kernel module, and megasasctl for the megaraid_sas Linux kernel module. The simple output from the command on one of my machines look like this (yes, I know some of the disks have problems. :).

# megasasctl 
a0       PERC H730 Mini           encl:1 ldrv:2  batt:good
a0d0       558GiB RAID 1   1x2  optimal
a0d1      3067GiB RAID 0   1x11 optimal
a0e32s0     558GiB  a0d0  online   errs: media:0  other:19
a0e32s1     279GiB  a0d1  online  
a0e32s2     279GiB  a0d1  online  
a0e32s3     279GiB  a0d1  online  
a0e32s4     279GiB  a0d1  online  
a0e32s5     279GiB  a0d1  online  
a0e32s6     279GiB  a0d1  online  
a0e32s8     558GiB  a0d0  online   errs: media:0  other:17
a0e32s9     279GiB  a0d1  online  
a0e32s10    279GiB  a0d1  online  
a0e32s11    279GiB  a0d1  online  
a0e32s12    279GiB  a0d1  online  
a0e32s13    279GiB  a0d1  online  

#

In addition to displaying a simple status report, it can also test individual drives and print the various event logs. Perhaps you too find it useful?

In the packaging process I provided some patches upstream to improve installation and ensure a Appstream metainfo file is provided to list all supported HW, to allow isenkram to propose the package on all servers with a relevant PCI card.

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

Nikita-prosjektet, der jeg er involvert, inviterer i samarbeid med Oslo Byarkiv, forskningsgruppen METAINFO og foreningen NUUG, til et frokostseminar om Noark 5 og Noark 5 Tjenestegrensesnitt tirsdag 2024-03-12. Seminaret finner sted ved Oslo byarkiv. Vi håper å få til videostrømming via Internett av presentasjoner og paneldiskusjon. Oppdatert program og lenker til påmeldingsskjema er tilgjengelig fra Nikita-prosjektet. Arrangementet er gratis.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

Today, the animation figure Mickey Mouse finally was released from the corporate copyright prison, as the 1928 movie Steamboat Willie entered the public domain in USA. This movie was the first public appearance of Mickey Mouse. Sadly the figure is still on probation, thanks to trademark laws and a the Disney corporations powerful pack of lawyers, as described in the 2017 article in "How Mickey Mouse Evades the Public Domain" from Priceonomics. On the positive side, the primary driver for repeated extentions of the duration of copyright has been Disney thanks to Mickey Mouse and the 2028 movie, and as it now in the public domain I hope it will cause less urge to extend the already unreasonable long copyright duration.

The first book I published, the 2004 book "Free Culture" by Lawrence Lessig, published 2015 in English, French and Norwegian Bokmål, touch on the story of Disney pushed for extending the copyright duration in USA. It is a great book explaining problems with the current copyright regime and why we need Creative Commons movement, and I strongly recommend everyone to read it.

This movie (with IMDB ID tt0019422) is now available from the Internet Archive. Two copies have been uploaded so far, one uploaded 2015-11-04 (torrent) and the other 2023-01-01 (torrent) - see VLC bittorrent plugin for streaming the video using the torrent link. I am very happy to see the number of public domain movies increasing. I look forward to when those are the majority. Perhaps it will reduce the urge of the copyright industry to control its customers.

A more comprehensive list of works entering the public domain in 2024 is available from the Public Domain Review.

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

The other day I uploaded a new version of the VLC bittorrent plugin to Debian, version 2.14-4, to fix a few packaging issues. This plugin extend VLC allowing it to stream videos directly from a bittorrent source using both torrent files and magnet links, as easy as using a HTTP or local file source. I believe such protocol support is a vital feature in VLC, allowing efficient streaming from sources such at the 11 million movies in the Internet Archive. Bittorrent is one of the most efficient content distribution protocols on the Internet, without centralised control, and should be used more.

The new version is now both in Debian Unstable and Testing, as well as Ubuntu. While looking after the package, I decided to ask the VLC upstream community if there was any hope to get Bittorrent support into the official VLC program, and was very happy to learn that someone is already working on it. I hope we can see some fruits of that labour next year, but do not hold my breath. In the mean time we can use the plugin, which is already installed by 0.23 percent of the Debian population according to popularity-contest. It could use a new upstream release, and I hope the upstream developer soon find time to polish it even more.

It is worth noting that the plugin store the downloaded files in ~/Downloads/vlc-bittorrent/, which can quickly fill up the user home directory during use. Users of the plugin should keep an eye with disk usage when streaming a bittorrent source.

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

For noen uker siden skrev en kamerat og meg en artikkel om tegnsett i arkivtidsskriftet Aksess både på web og i papirutgave nr. 3 2023. Her er det som nettopp ble publisert.

Når «på» blir «pÃ¥»: Et reservoar av tegn sett fra depotet

av Thomas Sødring og Petter Reinholdtsen

De færreste av oss tenker over hva som skjer dypere i datamaskinen mens vi sitter der og skriver noe på tastaturet. Når du trykker på tasten «Å», så vises bokstaven Å. Men noen ganger blir det feil. Hvorfor det – og hva er viktig å være klar over i arkivsammenheng?

Dersom bokstaver tolkes forskjellig mellom systemer, blir det fort rot, dette kalles mojibake blant kjennere, etter det japanske uttrykket for tegnomforming. Det er en lang historie her som tidvis har vært preget av rot. Noen husker kanskje tilbake til en tid der bokstavene æ, ø og å ofte var ødelagt i e-poster – et klassisk eksempel på tegnsettproblemstilling.

«Nå» og «før»

Tid er et skjult problem for depot fordi vi danner dokumentasjon i en kontekst som er preget av å være «nå». Vår forståelse av verden og bruken av teknologi er utgangspunktet for denne konteksten. Tenk selv hvordan verden har utviklet seg de siste 20 årene, hva samfunnet er opptatt av, og hvordan vi bruker teknologi i hverdagen. Tid er et skjult problem fordi når vi trekker dokumentasjon ut av systemer og deponerer for langtidsbevaring, er konteksten til materialet «nå», men verden går videre. Ettersom teknologien og måten vi bruker den på, utvikler seg, blir «nå» til «før», og dokumentasjonen befinner seg snart i en «før»-kontekst.

Dette med «før» og «nå» i forhold til dokumentasjonens kontekst er noe vi er veldig lite bevisste på, men det er en problemstilling depotarkivene eier og forvalter. En av disse utfordringene er hvorfor «Ø» ikke nødvendigvis er det samme som «Ø», og hvorfor det i det hele tatt gir mening å si noe sånt. Vi snakker her om noe som heter tegnsett, som er en avtalt måte å representere bokstaver, tall og andre symboler på slik at vi på en feilfri måte kan utveksle tekst mellom datasystemer.

Tegnsettproblemstillingen er satt sammen av fire fasetter; repertoar, representasjon, koding og uttegning.

Repertoarer

Repertoar er en samling med tegn og symboler som kan representeres. Tenk norsk alfabet eller japanske piktogrammer, men også matematiske og elektroniske symboler. Bokstaven «stor a» kan være en oppføring i et slikt repertoar. For å kunne brukes i en datamaskin trenger hver oppføring i et slikt repertoar en representasjon, hvilket i datamaskinsammenheng betyr at det tilordnes et tall. Tallet kan lagres på ulike vis i en eller flere kodingsformater. For eksempel kan en skrive tallet ti som både 10, X og A, i henholdsvis titallssystemet, romertallssystemet og sekstentallssystemet.

Hvis en skal kunne lese inn filer og vite hvilket tall og hvilken representasjon og instans i et repertoar det er snakk om, så må en vite hvordan tallet er kodet. Sist, men ikke minst, for å kunne bruke symbolet til noe må det kunne være kjent hvordan det skal se ut eller tegnes på ark. Det finnes utallige skrifttyper med norske bokstaver, alle litt forskjellige, og skal en kunne tegne en stor A på skjermen, så må datamaskinen vite hva den skal tegne. Skrifttyper inneholder informasjon om hvordan ulike tall skal tegnes. De inneholder ikke alltid alle symbolene som er brukt i en tekst, hvilket gjør at ikke alle forståtte tegn vil kunne vises på skjerm eller ark.

Hver av disse fasettene må være avklart for å kunne ta vare på og vise frem tekst med en datamaskin. Kombinasjon av repertoar, representasjon og koding er det en kaller et tegnsett. Kombinasjonen av representasjon og uttegning kalles en skrifttype. De fleste skrifttyper har også informasjon om repertoar, men det finnes skrifttyper som kun kobler mellom tallkode og uttegning, uten å fortelle noe om hvordan tallkodene egentlig skal tolkes.

Fra ASCII til ISO-8859

Vi begynner historien med ASCII (American Standard Code for Information Interchange) som har en historie som spores tilbake til 1963. Utgangspunktet til ASCII var at det kunne kode opp til 128 forskjellige symboler i vanlig bruk i USA. De visuelle symbolene i ASCII er de små og store bokstavene (a til z og A til Z), tall (0 til 9) og tegnsettingssymboler (for eksempel semikolon, komma og punktum). ASCII har også noen usynlige symboler som ble brukt for bl.a. kommunikasjon. Før ASCII var det for eksempel teleks-tegnsett med plass til bare 32 tegn og EBCDIC med plass til 256 tegn, alle med en helt annen rekkefølge på symbolene enn ASCII, men de har vært lite brukt de siste femti årene. Et eksempel på noen utvalgte symboler i repertoaret til ASCII vises i tabell 1.

Tabell 1. Eksempel på utvalgte symboler hentet fra ASCII-tegnsettet. Kolonnen «Binær» viser symbolets verdi i totallssystemet (1 og 0 tall), mens kolonnen «Desimal» viser symbolets verdi i titallssystemet.

Grafisk	Binær	Desimal
A	1000001	65
M	1001101	77
Z	1011010	90
a	1100001	97
m	1101101	109
z	1111010	122
0	0110000	48
9	0111001	58
;	0111011	59

Det opprinnelige ASCII-tegnsettet ble også omtalt som ASCII-7 og brukte 7 bits (0 og 1) for å representere symboler. Datamaskiner er ofte konfigurert til å jobbe med enheter der bits er gruppert som 4 eller 8 bits . Det lå en mulighet i å ta i bruk bit åtte. En slik endring ville gjøre det mulig for datamaskiner å øke antall symboler de kunne representere, noe som ga en økning fra 128 forskjellige symboler til 256 forskjellige symboler. Det ble åpnet for å innlemme de nordiske bokstavene sammen med ASCII, og dette ble etter hvert standardisert som ISO-8859-1. Tabell 2 viser deler av ISO-8859-1 som støtter de norske bokstavene.

Det sier seg selv at muligheten til å representere inntil 256 symboler ikke holder når vi snakker om en global verden, og det ble gjort et standardiseringsløp som tok utgangspunkt i ASCII-7 med en utvidelse til å bruke den åttende biten for ulike språkgrupper. Denne standarden heter ISO-8859 og er inndelt i opptil 16 varianter, altså fra ISO-8859-1 til ISO-8859-16.

Tabell 2. Koding av de norske symbolene slik de er definert i ISO-8859-1 tegnsettet.

Grafisk	Binær	Desimal
Æ	11000110	198
Ø	11011000	216
Å	11000101	197
æ	11100110	230
ø	11111000	248
å	11100101	229

Norske tegn er definert i ISO-8859-1, som også omtales som Latin 1, de fleste samiske tegn er definert i ISO-8859-4 (Latin 4) mens tilgang til €-symbolet kom med ISO-8859-15 (Latin 9). ISO-8859-15 er en revisjon av ISO-8859-1 som fjerner noen lite brukte symboler og erstatter bokstaver som er mer brukt, og introduserer €-symbolet. Det er viktig å merke at alle ISO-8859-variantene har overlapp med ASCII-7, noe som ga samvirke med de engelskspråklige landene som ikke trengte å gjøre noe. Det innebærer også at de første 128 verdiene i ISO-8859-variantene representerer de samme symbolene. Det er først når du kommer til tolkningen av de resterende 128 verdiene med nummer 128 til 255, at det oppsto tolkningsutfordringer mellom ISO-8859-variantene.

ISO-8859-verdenen fungerte godt så lenge tegnsettet som ble brukt når innhold ble skapt, også ble brukt når innhold ble gjengitt og du ikke trengte å kombinere innhold fra forskjellige tegnsett i samme dokument. Utfordringen med bruken av ISO-8859-variantene ble raskt tydelig i en mer globalisert verden med utveksling av tekst på tvers av landegrenser der tekstlig innhold i dokumenter, e-poster og websider kunne bli skrevet med ett tegnsett og gjengitt med et annet tegnsett.

Tabell 3. Viser tolkning av verdiene som er tilegnet de norske symbolene i ISO-8859-1 i de andre ISO 8859-variatene. Merk ISO-8859-12 ikke finnes da arbeidet ble avsluttet.^[1]

Binærverdi	1	2	3	4	5	6	7	8	9	10	11	13	14	15	16
11000110	Æ	Ć	Ĉ	Æ	Ц	ئ	Ζ		Æ	Æ	ฦ	Ę	Æ	Æ	Æ
11011000	Ø	Ř	Ĝ	Ø	и	ظ	Ψ		Ø	Ø	ุ	Ų	Ø	Ø	Ű
11000101	Å	Ĺ	Ċ	Å	Х	إ	Ε		Å	Å	ล	Å	Å	Å	Ć
11100110	æ	ć	ĉ	æ	ц	ن	ζ	ז	æ	æ	ๆ	ę	æ	æ	v
11111000	ø	ř	ĝ	ø	ј		ψ	ר	ø	ø	๘	ų	ø	ø	ű
11100101	å	ĺ	ċ	å	х	م	ε	ו	å	å	ๅ	å	å	å	ć

Denne problemstillingen er illustrert i tabell 3, der vi ser verdiene tilegnet de norske symbolene i ISO-8859-1 i kolonne «1». I de øvrige kolonnene ser vi hvilket symbol verdien får i de andre ISO-8859-variantene. Tar vi utgangspunkt i tabell 3, kan vi se at ordet lærlingspørsmål gjengitt med ISO-8859-2 (kolonne 2) blir lćrlingspřrsmĺl, mens det blir lζrlingspψrsmεl med ISO- 8859-7 (kolonne 7). Med ISO-8859-2 blir «æ» til «ć», «ø» til «ř» og «å» til «ĺ». I ISO-8859-7 blir «æ» til «ζ», «ø» til «ψ», mens «å» blir «ε».

Det er egentlig ingen utfordring med dette så lenge du vet hvilket tegnsett innholdet ditt er representert med, og det ikke har skjedd omforminger som du ikke er klar over. Det er det siste som er problematisk, spesielt de datasystemene som har vært i bruk de siste 20 årene, som ikke har noe innebygd funksjonalitet for å forvalte tegnsettproblematikken. Et godt eksempel på dette er Microsoft-tegnsettet Windows-1252, som ble forvekslet som 100 % kompatibel med ISO-8859-1, men hadde byttet ut plassene fra 127 til 159. Historisk vil det finnes en del variasjon i hvilket tegnsett som har vært i bruk, og hvor vellykket konvertering mellom tegnsett har vært.

Unicode som løsning

Tegnsettforvirring ble etter hvert et irritasjonsmoment og samvirkeproblem. Ofte fikk man en e-post der æøå var erstattet av rare symboler fordi e-posten hadde vært innom et eller annet datasystem som ikke brukte samme tegnsett.

For å løse dette samvirkeproblemet for tegnsett ble det startet et arbeid og en ny standard så dagens lys etter hvert. Denne standarden fikk navnet Unicode (ISO/ IEC 10646) og skulle resultere i et tegnsett som alle skulle være enige om. Unicode er et repertoar og en representasjon, dvs. navngivning og tilordning av tallverdi til alle symboler i bruk i verden i dag. Oppføringer i Unicode skrives gjerne U+XXXX der XXXX er tallkoden i sekstentallssystemet som oppføringen har i Unicode-katalogen. Her finner vi tegn brukt av både levende og døde språk, konstruerte språk, tekniske symboler, morsomme tegninger (såkalte emojier) og tegn ingen vet hva betyr eller skal brukes til. Et morsomt eksempel er i nettartikkelen: U+237C ⍼ RIGHT ANGLE WITH DOWNWARDS ZIGZAG ARROW, av Jonathan Chan.^[2]

Sammen med Unicode kom det tre måter å kode disse tallene på; UTF-8, UTF-16 og UTF-32. Av datatekniske årsaker er UTF-8 mye brukt, spesielt når det gjelder utveksling av tekst over Internett, mens UTF-16 er brukt en del til tekstfiler lagret på Windows. En utfordring med Unicode og UTF-variantene er at disse gir flere måter å kode samme symbol på med en kombinasjonsmekanisme. Dette kan gi utfordringer ved søk, hvis en skal søke etter et ord som har ett eller flere symboler som kan skrives på ulikt vis, så er det ikke sikkert at søkesystemet vil finne alle forekomster. For eksempel kan bokstaven U+00F8 «Latin Small Letter O with Stroke» kodes som den tradisjonelle norske tegnet ø, men også som o kombinert med skråstrek U+0338. Begge deler er gyldig bruk av Unicode, selv om det er tradisjon for å foretrekke å «normalisere» kombinasjoner som enkelttegn der det er mulig, nettopp for å forenkle søk.

Bare Unicode fremover

Forvaltningens bruk av tegnsett er regulert i Forskrift om IT-standarder i offentlig forvaltning^[3]. Her står det: «Ved all utveksling av informasjon mellom forvaltningsorganer og fra forvaltningsorgan til innbyggere og næringsliv skal tegnsettstandarden ISO/IEC 10646 representert ved UTF8 benyttes.» Det er forskjellige bruksområder til UTF-8, UTF-16 og UTF-32, men UTF-8 er kodingen vi kjenner mest til. Det er flere grunner at UTF-8 «vant» konkurransen til å bli den utvalgte. Den kanskje viktigste er at UTF-8 er fullt samvirkende med ASCII-7, slik at den engelskspråklige delen av verden kunne rulle ut UTF-8 uten å merke noe forskjell. En tekstfil med kun ASCII-tekst vil være identisk på disken hvis den lagres som UTF-8 og ASCII. UTF-16 og UTF-32 byr på noen optimaliseringer som gjør dem relevant for spesifikke problemområder, men for det meste vil vi aldri oppleve disse standardene på nært hold i hverdagen. Det er uansett kun bruken av UTF-8 som er lovregulert i Norge.

Det er ikke slik at hele verden bruker ISO/IEC 10646 og UTF-8. Kina har egne standarder for tegnsett, mye brukt er GB 18030, som er Unicode med en annen koding enn UTF-8, mens Taiwan og andre asiatiske land gjerne bruker Big5 eller andre tegnsett.

UTF-8 er dominerende i Norge, men det er tidsperioder der forskjellige datasystemer utvekslet data i henhold til ISO-8859-1, ISO-8859-15, Windows-1252, Codepage 865 og ISO-646-60 / Codepage 1016 mens overgangen til UTF-8 pågikk. Det er ikke slik at et datasystem enkelt kan tvinges til å bruke et tegnsett, da det er flere lag i et datasystem som må settes opp til å bruke riktig tegnsett, og tegnsettproblemet fort oppstår når det er et eller annet i datasystemet som bruker feil tegnsett.

Et klassisk eksempel på problemet er en utveksling av tekst mellom to systemer der teksten i utgangspunktet er kodet i UTF-8, men går gjennom noe som er ISO-8859-1 underveis. Dette kan vises med at ordet «på» i et slik scenario ender opp som «pÃ¥». Det er mulig å spore dette tilbake til verdiene symbolene er tilordnet i tegnsettene. «på» blir til «pÃ¥» fordi «å» i UTF-8 er representert med U+C3AF, og dersom vi ser på hva disse verdiene representerer, ser vi at sekstentallssystemverdien C3 er 1100 0011 i totallssystemet og symbolet med dette tallet i ISO-8859-1 er Ã.

Vi ser det samme med sekstentallssystemverdien A5, som er 1010 0101 i totallssystemet, og tilsvarende symbol i ISO-8859-1 er ¥. Slik mojibake kan lett skje hvis «på» i utgangspunktet var representert med UTF-8, men ble behandlet med et system som bruker ISO-8859-1. Det er ingen automatikk i å fange opp slike ødeleggelser mens tekstlig innhold utveksles mellom datasystemer.

En utfordring for depotarkivene er at bruken av tegnsett ikke alltid har vært regulert, og at det kan finnes flere dokumentasjonssamlinger som er opprettet med varierende tegnsett før gjeldende forskrift inntraff – uten at det er mulig å avlede fra filene hvilket tegnsett som ble brukt. Et eksempel på dette er €-symbolet, som kom først etter at ISO-8859-1 var tatt i bruk. Det kan bli en utfordring for et depotarkiv, men så lenge det er kjent hvilket tegnsett var i bruk, så bør det gå bra. Riksarkivarens forskrift^[4] formaliserer dette ved å kreve følgende:

§ 5-11. Tegnsett i arkivuttrekk

1. Arkivuttrekk og medfølgende struktur- og innholdsbeskrivelser skal overføres som ren tekst i ukryptert form, og benytte godkjent tegnsett.
2. Godkjente tegnsett er:
   1. Unicode UTF-8
      (ISO/IEC 10646-1:2000 Annex D)
   2. ISO 8859-1:1998, Latin 1
   3. ISO 8859-4:1998, Latin 4 for samiske tegn.
3. Andre tegnsett aksepteres bare etter avtale med Arkivverket.

Ditt ansvar

På mange måter burde ikke tegnsett være et problem i 2023, men sånn er det nok ikke. Land som har oppgradert til UTF-8 som primærtegnsett for utveksling av tekstlig innhold, begrenser problematikken betraktelig, men globalt sett så er tegnsettutfordringen ikke løst fordi ikke alle er enige om å bruke samme tegnsett. Det kan være geopolitiske eller kulturelle hensyn som ligger til grunn for dette.

Det er uansett verdt å merke at selv om bruken av UTF-8 skulle bli 100% utbredt, så er det et historisk perspektiv (ASCII-7, ISO-8859-variantene, UTF-8) her som gjør tegnsett til et problemområde arkivarene må forstå og håndtere. Som danningsarkivar har du et ansvar for å vite hvilket tegnsett systemene og databasene dere forvalter, er i samsvar med. Det er noe IT-avdelingen din eller programvareleverandørene enkelt skal kunne svare på, og svaret skal være UTF-8 for alle nye systemer.

---

1. Tegnsettkilde https://en.wikipedia.org/wiki/ISO/IEC_8859

2. https://ionathan.ch/2022/04/09/angzarr.html

3. https://lovdata.no/dokument/SF/forskrift/2013-04-05-959/%C2%A78#%C2%A78

4. https://lovdata.no/forskrift/2017-12-19-2286/§5-11

For øvrig burde varsleren Edward Snowden få politisk asyl i Norge.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)