X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/3dcbf72b993aeaaff8ace4ad02e21378cbfe8874..51d98ae3ba2fce3ed076d15c5ec88521669bccbc:/blog/archive/2014/09/09.rss diff --git a/blog/archive/2014/09/09.rss b/blog/archive/2014/09/09.rss index 02569787b1..b61d8a837a 100644 --- a/blog/archive/2014/09/09.rss +++ b/blog/archive/2014/09/09.rss @@ -6,6 +6,598 @@ http://people.skolelinux.org/pere/blog/ + + How to test Debian Edu Jessie despite some fatal problems with the installer + http://people.skolelinux.org/pere/blog/How_to_test_Debian_Edu_Jessie_despite_some_fatal_problems_with_the_installer.html + http://people.skolelinux.org/pere/blog/How_to_test_Debian_Edu_Jessie_despite_some_fatal_problems_with_the_installer.html + Fri, 26 Sep 2014 12:20:00 +0200 + <p>The <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux +project</a> provide a Linux solution for schools, including a +powerful desktop with education software, a central server providing +web pages, user database, user home directories, central login and PXE +boot of both clients without disk and the installation to install Debian +Edu on machines with disk (and a few other services perhaps to small +to mention here). We in the Debian Edu team are currently working on +the Jessie based version, trying to get everything in shape before the +freeze, to avoid having to maintain our own package repository in the +future. The +<a href="https://wiki.debian.org/DebianEdu/Status/Jessie">current +status</a> can be seen on the Debian wiki, and there is still heaps of +work left. Some fatal problems block testing, breaking the installer, +but it is possible to work around these to get anyway. Here is a +recipe on how to get the installation limping along.</p> + +<p>First, download the test ISO via +<a href="ftp://ftp.skolelinux.no/cd-edu-testing-nolocal-netinst/debian-edu-amd64-i386-NETINST-1.iso">ftp</a>, +<a href="http://ftp.skolelinux.no/cd-edu-testing-nolocal-netinst/debian-edu-amd64-i386-NETINST-1.iso">http</a> +or rsync (use +ftp.skolelinux.org::cd-edu-testing-nolocal-netinst/debian-edu-amd64-i386-NETINST-1.iso). +The ISO build was broken on Tuesday, so we do not get a new ISO every +12 hours or so, but thankfully the ISO we already got we are able to +install with some tweaking.</p> + +<p>When you get to the Debian Edu profile question, go to tty2 +(use Alt-Ctrl-F2), run</p> + +<p><blockquote><pre> +nano /usr/bin/edu-eatmydata-install +</pre></blockquote></p> + +<p>and add 'exit 0' as the second line, disabling the eatmydata +optimization. Return to the installation, select the profile you want +and continue. Without this change, exim4-config will fail to install +due to a known bug in eatmydata.</p> + +<p>When you get the grub question at the end, answer /dev/sda (or if +this do not work, figure out what your correct value would be. All my +test machines need /dev/sda, so I have no advice if it do not fit +your need.</p> + +<p>If you installed a profile including a graphical desktop, log in as +root after the initial boot from hard drive, and install the +education-desktop-XXX metapackage. XXX can be kde, gnome, lxde, xfce +or mate. If you want several desktop options, install more than one +metapackage. Once this is done, reboot and you should have a working +graphical login screen. This workaround should no longer be needed +once the education-tasks package version 1.801 enter testing in two +days.</p> + +<p>I believe the ISO build will start working on two days when the new +tasksel package enter testing and Steve McIntyre get a chance to +update the debian-cd git repository. The eatmydata, grub and desktop +issues are already fixed in unstable and testing, and should show up +on the ISO as soon as the ISO build start working again. Well the +eatmydata optimization is really just disabled. The proper fix +require an upload by the eatmydata maintainer applying the patch +provided in bug <a href="https://bugs.debian.org/702711">#702711</a>. +The rest have proper fixes in unstable.</p> + +<p>I hope this get you going with the installation testing, as we are +quickly running out of time trying to get our Jessie based +installation ready before the distribution freeze in a month.</p> + + + + + Suddenly I am the new upstream of the lsdvd command line tool + http://people.skolelinux.org/pere/blog/Suddenly_I_am_the_new_upstream_of_the_lsdvd_command_line_tool.html + http://people.skolelinux.org/pere/blog/Suddenly_I_am_the_new_upstream_of_the_lsdvd_command_line_tool.html + Thu, 25 Sep 2014 11:20:00 +0200 + <p>I use the <a href="https://sourceforge.net/p/lsdvd/">lsdvd tool</a> +to handle my fairly large DVD collection. It is a nice command line +tool to get details about a DVD, like title, tracks, track length, +etc, in XML, Perl or human readable format. But lsdvd have not seen +any new development since 2006 and had a few irritating bugs affecting +its use with some DVDs. Upstream seemed to be dead, and in January I +sent a small probe asking for a version control repository for the +project, without any reply. But I use it regularly and would like to +get <a href="https://packages.qa.debian.org/lsdvd">an updated version +into Debian</a>. So two weeks ago I tried harder to get in touch with +the project admin, and after getting a reply from him explaining that +he was no longer interested in the project, I asked if I could take +over. And yesterday, I became project admin.</p> + +<p>I've been in touch with a Gentoo developer and the Debian +maintainer interested in joining forces to maintain the upstream +project, and I hope we can get a new release out fairly quickly, +collecting the patches spread around on the internet into on place. +I've added the relevant Debian patches to the freshly created git +repository, and expect the Gentoo patches to make it too. If you got +a DVD collection and care about command line tools, check out +<a href="https://sourceforge.net/p/lsdvd/git/ci/master/tree/">the git source</a> and join +<a href="https://sourceforge.net/p/lsdvd/mailman/">the project mailing +list</a>. :)</p> + + + + + Hva henger under skibrua over E16 på Sollihøgda? + http://people.skolelinux.org/pere/blog/Hva_henger_under_skibrua_over_E16_p__Sollih_gda_.html + http://people.skolelinux.org/pere/blog/Hva_henger_under_skibrua_over_E16_p__Sollih_gda_.html + Sun, 21 Sep 2014 09:50:00 +0200 + <p>Rundt omkring i Oslo og Østlandsområdet henger det bokser over +veiene som jeg har lurt på hva gjør. De har ut fra plassering og +vinkling sett ut som bokser som sniffer ut et eller annet fra +forbipasserende trafikk, men det har vært uklart for meg hva det er de +leser av. Her om dagen tok jeg bilde av en slik boks som henger under +<a href="http://www.openstreetmap.no/?zoom=19&mlat=59.96396&mlon=10.34443&layers=B00000">ei +skibru på Sollihøgda</a>:</p> + +<p align="center"><img width="60%" src="http://people.skolelinux.org/pere/blog/images/2014-09-13-kapsch-sollihogda-crop.jpeg"></p> + +<p>Boksen er tydelig merket «Kapsch >>>», logoen til +<a href="http://www.kapsch.net/">det sveitsiske selskapet Kapsch</a> som +blant annet lager sensorsystemer for veitrafikk. Men de lager mye +forskjellig, og jeg kjente ikke igjen boksen på utseendet etter en +kjapp titt på produktlista til selskapet.</p> + +<p>I og med at boksen henger over veien E16, en riksvei vedlikeholdt +av Statens Vegvesen, så antok jeg at det burde være mulig å bruke +REST-API-et som gir tilgang til vegvesenets database over veier, +skilter og annet veirelatert til å finne ut hva i alle dager dette +kunne være. De har både +<a href="https://www.vegvesen.no/nvdb/api/dokumentasjon/datakatalog">en +datakatalog</a> og +<a href="https://www.vegvesen.no/nvdb/api/dokumentasjon/sok">et +søk</a>, der en kan søke etter ulike typer oppføringer innen for et +gitt geografisk område. Jeg laget et enkelt shell-script for å hente +ut antall av en gitt type innenfor området skibrua dekker, og listet +opp navnet på typene som ble funnet. Orket ikke slå opp hvordan +URL-koding av aktuelle strenger kunne gjøres mer generisk, og brukte +en stygg sed-linje i stedet.</p> + +<blockquote><pre> +#!/bin/sh +urlmap() { + sed \ + -e 's/ / /g' -e 's/{/%7B/g' \ + -e 's/}/%7D/g' -e 's/\[/%5B/g' \ + -e 's/\]/%5D/g' -e 's/ /%20/g' \ + -e 's/,/%2C/g' -e 's/\"/%22/g' \ + -e 's/:/%3A/g' +} + +lookup() { + url="$1" + curl -s -H 'Accept: application/vnd.vegvesen.nvdb-v1+xml' \ + "https://www.vegvesen.no/nvdb/api$url" | xmllint --format - +} + +for id in $(seq 1 874) ; do + search="{ + lokasjon: { + bbox: \"10.34425,59.96386,10.34458,59.96409\", + srid: \"WGS84\" + }, + objektTyper: [{ + id: $id, antall: 10 + }] +}" + + query=/sok?kriterie=$(echo $search | urlmap) + if lookup "$query" | + grep -q '&lt;totaltAntallReturnert>0&lt;' + then + : + else + echo $id + lookup "/datakatalog/objekttyper/$id" |grep '^ &lt;navn>' + fi +done + +exit 0 +</pre></blockquote> + +Aktuelt ID-område 1-874 var riktig i datakatalogen da jeg laget +scriptet. Det vil endre seg over tid. Skriptet listet så opp +aktuelle typer i og rundt skibrua: + +<blockquote><pre> +5 + &lt;navn>Rekkverk&lt;/navn> +14 + &lt;navn>Rekkverksende&lt;/navn> +47 + &lt;navn>Trafikklomme&lt;/navn> +49 + &lt;navn>Trafikkøy&lt;/navn> +60 + &lt;navn>Bru&lt;/navn> +79 + &lt;navn>Stikkrenne/Kulvert&lt;/navn> +80 + &lt;navn>Grøft, åpen&lt;/navn> +86 + &lt;navn>Belysningsstrekning&lt;/navn> +95 + &lt;navn>Skiltpunkt&lt;/navn> +96 + &lt;navn>Skiltplate&lt;/navn> +98 + &lt;navn>Referansestolpe&lt;/navn> +99 + &lt;navn>Vegoppmerking, langsgående&lt;/navn> +105 + &lt;navn>Fartsgrense&lt;/navn> +106 + &lt;navn>Vinterdriftsstrategi&lt;/navn> +172 + &lt;navn>Trafikkdeler&lt;/navn> +241 + &lt;navn>Vegdekke&lt;/navn> +293 + &lt;navn>Breddemåling&lt;/navn> +301 + &lt;navn>Kantklippareal&lt;/navn> +318 + &lt;navn>Snø-/isrydding&lt;/navn> +445 + &lt;navn>Skred&lt;/navn> +446 + &lt;navn>Dokumentasjon&lt;/navn> +452 + &lt;navn>Undergang&lt;/navn> +528 + &lt;navn>Tverrprofil&lt;/navn> +532 + &lt;navn>Vegreferanse&lt;/navn> +534 + &lt;navn>Region&lt;/navn> +535 + &lt;navn>Fylke&lt;/navn> +536 + &lt;navn>Kommune&lt;/navn> +538 + &lt;navn>Gate&lt;/navn> +539 + &lt;navn>Transportlenke&lt;/navn> +540 + &lt;navn>Trafikkmengde&lt;/navn> +570 + &lt;navn>Trafikkulykke&lt;/navn> +571 + &lt;navn>Ulykkesinvolvert enhet&lt;/navn> +572 + &lt;navn>Ulykkesinvolvert person&lt;/navn> +579 + &lt;navn>Politidistrikt&lt;/navn> +583 + &lt;navn>Vegbredde&lt;/navn> +591 + &lt;navn>Høydebegrensning&lt;/navn> +592 + &lt;navn>Nedbøyningsmåling&lt;/navn> +597 + &lt;navn>Støy-luft, Strekningsdata&lt;/navn> +601 + &lt;navn>Oppgravingsdata&lt;/navn> +602 + &lt;navn>Oppgravingslag&lt;/navn> +603 + &lt;navn>PMS-parsell&lt;/navn> +604 + &lt;navn>Vegnormalstrekning&lt;/navn> +605 + &lt;navn>Værrelatert strekning&lt;/navn> +616 + &lt;navn>Feltstrekning&lt;/navn> +617 + &lt;navn>Adressepunkt&lt;/navn> +626 + &lt;navn>Friksjonsmåleserie&lt;/navn> +629 + &lt;navn>Vegdekke, flatelapping&lt;/navn> +639 + &lt;navn>Kurvatur, horisontalelement&lt;/navn> +640 + &lt;navn>Kurvatur, vertikalelement&lt;/navn> +642 + &lt;navn>Kurvatur, vertikalpunkt&lt;/navn> +643 + &lt;navn>Statistikk, trafikkmengde&lt;/navn> +647 + &lt;navn>Statistikk, vegbredde&lt;/navn> +774 + &lt;navn>Nedbøyningsmåleserie&lt;/navn> +775 + &lt;navn>ATK, influensstrekning&lt;/navn> +794 + &lt;navn>Systemobjekt&lt;/navn> +810 + &lt;navn>Vinterdriftsklasse&lt;/navn> +821 + &lt;navn>Funksjonell vegklasse&lt;/navn> +825 + &lt;navn>Kurvatur, stigning&lt;/navn> +838 + &lt;navn>Vegbredde, beregnet&lt;/navn> +862 + &lt;navn>Reisetidsregistreringspunkt&lt;/navn> +871 + &lt;navn>Bruksklasse&lt;/navn> +</pre></blockquote> + +<p>Av disse ser ID 775 og 862 mest relevant ut. ID 775 antar jeg +refererer til fotoboksen som står like ved brua, mens +«Reisetidsregistreringspunkt» kanskje kan være boksen som henger der. +Hvordan finner jeg så ut hva dette kan være for noe. En titt på +<a href="http://labs.vegdata.no/nvdb-datakatalog/862-Reisetidsregistreringspunkt/">datakatalogsiden +for ID 862/Reisetidsregistreringspunkt</a> viser at det er finnes 53 +slike målere i Norge, og hvor de er plassert, men gir ellers få +detaljer. Det er plassert 40 på østlandet og 13 i Trondheimsregionen. +Men siden nevner «AutoPASS», og hvis en slår opp oppføringen på +Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det +være snakk om +<a href="http://www.proff.no/selskap/ciber-norge-as/oslo/internettdesign-og-programmering/Z0I3KMF4/">Ciber +Norge AS</a>, et selskap eid av Ciber Europe Bv?) Et nettsøk på + «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i + 2013 med tittel +«<a href="http://www.nrk.no/trondelag/sjekk-dette-hvis-du-vil-unnga-ko-1.11327947">Sjekk +dette hvis du vil unngå kø</a>». Artikkelen henviser til vegvesenets +nettside +<a href="http://www.reisetider.no/reisetid/forside.html">reisetider.no</a> +som har en +<a href="http://www.reisetider.no/reisetid/omrade.html?omrade=5">kartside +for Østlandet</a> som viser at det måles mellom Sandvika og Sollihøgda. +Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.</p> + +<p>Hvis det stemmer, så er dette bokser som leser av AutoPASS-ID-en +til alle passerende biler med AutoPASS-brikke, og dermed gjør det mulig +for de som kontrollerer boksene å holde rede på hvor en gitt bil er +når den passerte et slikt målepunkt. NRK-artikkelen forteller at +denne informasjonen i dag kun brukes til å koble to +AutoPASS-brikkepasseringer passeringer sammen for å beregne +reisetiden, og at bruken er godkjent av Datatilsynet. Det er desverre +ikke mulig for en sjåfør som passerer under en slik boks å kontrollere +at AutoPASS-ID-en kun brukes til dette i dag og i fremtiden.</p> + +<p>I tillegg til denne type AutoPASS-sniffere vet jeg at det også +finnes mange automatiske stasjoner som tar betalt pr. passering (aka +bomstasjoner), og der lagres informasjon om tid, sted og bilnummer i +10 år. Finnes det andre slike sniffere plassert ut på veiene?</p> + +<p>Personlig har jeg valgt å ikke bruke AutoPASS-brikke, for å gjøre +det vanskeligere og mer kostbart for de som vil invadere privatsfæren +og holde rede på hvor bilen min beveger seg til enhver tid. Jeg håper +flere vil gjøre det samme, selv om det gir litt høyere private +utgifter (dyrere bompassering). Vern om privatsfæren koster i disse +dager.</p> + +<p>Takk til Jan Kristian Jensen i Statens Vegvesen for tips om +dokumentasjon på vegvesenets REST-API.</p> + +<p>Bruksvilkår på bildet er +<a href="https://creativecommons.org/publicdomain/">public domain eller +CC0</a> alt etter hva som fungerer best for mottaker.</p> + +<p>Oppdatering 2014-12-17: Veldig hyggelig å se at mine notater +<a href="http://www.vegdata.no/2014/11/04/hva-henger-under-brua-over-e16-pa-sollihogda/">fikk +omtale på vegdata-bloggen</a>.</p> + + + + + Speeding up the Debian installer using eatmydata and dpkg-divert + http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html + http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html + Tue, 16 Sep 2014 14:00:00 +0200 + <p>The <a href="https://www.debian.org/">Debian</a> installer could be +a lot quicker. When we install more than 2000 packages in +<a href="http://www.skolelinux.org/">Skolelinux / Debian Edu</a> using +tasksel in the installer, unpacking the binary packages take forever. +A part of the slow I/O issue was discussed in +<a href="https://bugs.debian.org/613428">bug #613428</a> about too +much file system sync-ing done by dpkg, which is the package +responsible for unpacking the binary packages. Other parts (like code +executed by postinst scripts) might also sync to disk during +installation. All this sync-ing to disk do not really make sense to +me. If the machine crash half-way through, I start over, I do not try +to salvage the half installed system. So the failure sync-ing is +supposed to protect against, hardware or system crash, is not really +relevant while the installer is running.</p> + +<p>A few days ago, I thought of a way to get rid of all the file +system sync()-ing in a fairly non-intrusive way, without the need to +change the code in several packages. The idea is not new, but I have +not heard anyone propose the approach using dpkg-divert before. It +depend on the small and clever package +<a href="https://packages.qa.debian.org/eatmydata">eatmydata</a>, which +uses LD_PRELOAD to replace the system functions for syncing data to +disk with functions doing nothing, thus allowing programs to live +dangerous while speeding up disk I/O significantly. Instead of +modifying the implementation of dpkg, apt and tasksel (which are the +packages responsible for selecting, fetching and installing packages), +it occurred to me that we could just divert the programs away, replace +them with a simple shell wrapper calling +"eatmydata&nbsp;$program&nbsp;$@", to get the same effect. +Two days ago I decided to test the idea, and wrapped up a simple +implementation for the Debian Edu udeb.</p> + +<p>The effect was stunning. In my first test it reduced the running +time of the pkgsel step (installing tasks) from 64 to less than 44 +minutes (20 minutes shaved off the installation) on an old Dell +Latitude D505 machine. I am not quite sure what the optimised time +would have been, as I messed up the testing a bit, causing the debconf +priority to get low enough for two questions to pop up during +installation. As soon as I saw the questions I moved the installation +along, but do not know how long the question were holding up the +installation. I did some more measurements using Debian Edu Jessie, +and got these results. The time measured is the time stamp in +/var/log/syslog between the "pkgsel: starting tasksel" and the +"pkgsel: finishing up" lines, if you want to do the same measurement +yourself. In Debian Edu, the tasksel dialog do not show up, and the +timing thus do not depend on how quickly the user handle the tasksel +dialog.</p> + +<p><table> + +<tr> +<th>Machine/setup</th> +<th>Original tasksel</th> +<th>Optimised tasksel</th> +<th>Reduction</th> +</tr> + +<tr> +<td>Latitude D505 Main+LTSP LXDE</td> +<td>64 min (07:46-08:50)</td> +<td><44 min (11:27-12:11)</td> +<td>>20 min 18%</td> +</tr> + +<tr> +<td>Latitude D505 Roaming LXDE</td> +<td>57 min (08:48-09:45)</td> +<td>34 min (07:43-08:17)</td> +<td>23 min 40%</td> +</tr> + +<tr> +<td>Latitude D505 Minimal</td> +<td>22 min (10:37-10:59)</td> +<td>11 min (11:16-11:27)</td> +<td>11 min 50%</td> +</tr> + +<tr> +<td>Thinkpad X200 Minimal</td> +<td>6 min (08:19-08:25)</td> +<td>4 min (08:04-08:08)</td> +<td>2 min 33%</td> +</tr> + +<tr> +<td>Thinkpad X200 Roaming KDE</td> +<td>19 min (09:21-09:40)</td> +<td>15 min (10:25-10:40)</td> +<td>4 min 21%</td> +</tr> + +</table></p> + +<p>The test is done using a netinst ISO on a USB stick, so some of the +time is spent downloading packages. The connection to the Internet +was 100Mbit/s during testing, so downloading should not be a +significant factor in the measurement. Download typically took a few +seconds to a few minutes, depending on the amount of packages being +installed.</p> + +<p>The speedup is implemented by using two hooks in +<a href="https://www.debian.org/devel/debian-installer/">Debian +Installer</a>, the pre-pkgsel.d hook to set up the diverts, and the +finish-install.d hook to remove the divert at the end of the +installation. I picked the pre-pkgsel.d hook instead of the +post-base-installer.d hook because I test using an ISO without the +eatmydata package included, and the post-base-installer.d hook in +Debian Edu can only operate on packages included in the ISO. The +negative effect of this is that I am unable to activate this +optimization for the kernel installation step in d-i. If the code is +moved to the post-base-installer.d hook, the speedup would be larger +for the entire installation.</p> + +<p>I've implemented this in the +<a href="https://packages.qa.debian.org/debian-edu-install">debian-edu-install</a> +git repository, and plan to provide the optimization as part of the +Debian Edu installation. If you want to test this yourself, you can +create two files in the installer (or in an udeb). One shell script +need do go into /usr/lib/pre-pkgsel.d/, with content like this:</p> + +<p><blockquote><pre> +#!/bin/sh +set -e +. /usr/share/debconf/confmodule +info() { + logger -t my-pkgsel "info: $*" +} +error() { + logger -t my-pkgsel "error: $*" +} +override_install() { + apt-install eatmydata || true + if [ -x /target/usr/bin/eatmydata ] ; then + for bin in dpkg apt-get aptitude tasksel ; do + file=/usr/bin/$bin + # Test that the file exist and have not been diverted already. + if [ -f /target$file ] ; then + info "diverting $file using eatmydata" + printf "#!/bin/sh\neatmydata $bin.distrib \"\$@\"\n" \ + > /target$file.edu + chmod 755 /target$file.edu + in-target dpkg-divert --package debian-edu-config \ + --rename --quiet --add $file + ln -sf ./$bin.edu /target$file + else + error "unable to divert $file, as it is missing." + fi + done + else + error "unable to find /usr/bin/eatmydata after installing the eatmydata pacage" + fi +} + +override_install +</pre></blockquote></p> + +<p>To clean up, another shell script should go into +/usr/lib/finish-install.d/ with code like this: + +<p><blockquote><pre> +#! /bin/sh -e +. /usr/share/debconf/confmodule +error() { + logger -t my-finish-install "error: $@" +} +remove_install_override() { + for bin in dpkg apt-get aptitude tasksel ; do + file=/usr/bin/$bin + if [ -x /target$file.edu ] ; then + rm /target$file + in-target dpkg-divert --package debian-edu-config \ + --rename --quiet --remove $file + rm /target$file.edu + else + error "Missing divert for $file." + fi + done + sync # Flush file buffers before continuing +} + +remove_install_override +</pre></blockquote></p> + +<p>In Debian Edu, I placed both code fragments in a separate script +edu-eatmydata-install and call it from the pre-pkgsel.d and +finish-install.d scripts.</p> + +<p>By now you might ask if this change should get into the normal +Debian installer too? I suspect it should, but am not sure the +current debian-installer coordinators find it useful enough. It also +depend on the side effects of the change. I'm not aware of any, but I +guess we will see if the change is safe after some more testing. +Perhaps there is some package in Debian depending on sync() and +fsync() having effect? Perhaps it should go into its own udeb, to +allow those of us wanting to enable it to do so without affecting +everyone.</p> + +<p>Update 2014-09-24: Since a few days ago, enabling this optimization +will break installation of all programs using gnutls because of +<a href="https://bugs.debian.org/702711">bug #702711</a>. An updated +eatmydata package in Debian will solve it.</p> + +<p>Update 2014-10-17: The bug mentioned above is fixed in testing and +the optimization work again. And I have discovered that the +dpkg-divert trick is not really needed and implemented a slightly +simpler approach as part of the debian-edu-install package. See +tools/edu-eatmydata-install in the source package.</p> + +<p>Update 2014-11-11: Unfortunately, a new +<a href="http://bugs.debian.org/765738">bug #765738</a> in eatmydata only +triggering on i386 made it into testing, and broke this installation +optimization again. If <a href="http://bugs.debian.org/768893">unblock +request 768893</a> is accepted, it should be working again.</p> + + + Good bye subkeys.pgp.net, welcome pool.sks-keyservers.net http://people.skolelinux.org/pere/blog/Good_bye_subkeys_pgp_net__welcome_pool_sks_keyservers_net.html