Paretje's blog

technical

In het verleden deed ik steeds het volgende met technische termen, meer bepaald commando's, packages en paden:
[font=Courier][/font]

Nu, dat vereist wel dat Courier geïnstalleerd is, of dat er een alias voor bestaat. Verder is het nogal lang om steeds te typen, en schreef ik soms Courrier. Ik had dan ook al een tijdje de wens om dit te vereenvoudigen, en dat heb ik het typen van het vorige bericht beslist om te gaan doen. Ik heb de t-tag toegevoegd:
[t][/t]


chronic

Aan het begin van de examens vond ik op een avond op mijn netbook, ik weet niet meer wat ik exact aan het zoeken was, maar ik vond het pakket moreutils. Dit bevat een aantal extra commando's, waaronder chronic, die enkel de output van een commando toont wanneer de exit code niet 0 was, of dus als er iets fout gelopen was.

Nu is dat exact wat ik een tijdje geleden geregeld heb om minder emails te krijgen, bijvoorbeeld van alle backups:
rsync ... > /home/kevin/.cronjobs/log/rsync-games-previous 2>&1 ; if [ $? -ne 0 ] ; then cat /home/kevin/.cronjobs/log/rsync-games-previous ; fi

Dit gebruikte ik sinds enkele maanden om hetzelfde te bereiken als chronic. Nu waren er hier en daar toch problemen met mijn aanpak, en het is op zijn zachts nogal lang. Daarom had ik graag beginnen overschakelen op chronic. Nu draait mijn server, voorlopig, nog Ubuntu 10.04, het is de bedoeling dat dit Debian Wheezy wordt. Maar, zover zijn we nog niet, en ik was bezig met het aanpassen van mijn crontab file voor de opnames, en wou dit meteen eens uittesten. Echter, toen ik moreutils installeerde bleek dit niet voldoende. Toen ik op de Ubuntu package pagina keek, wist ik ook waarom, de versie die gebruikt werd bevatte nog geen chronic. De enige versieafhankelijke dependency is libc6, en bij 0.45 van Ubuntu 12.04, en die heb ik dan ook toegevoegd aan mijn repo. Ondertussen is het trouwens al geïnstalleerd, en nu kunnen we verder.


Fonts

Eergisteren ben ik begonnen met het aanpassen van mijn stylesheets, en Verdana, die meestal geen alternatief had, te vervangen door sans-serif. Nu, toen ik vandaag dit ook wou doen op het forum en de site (blog en uploads waren reeds gebeurd) vroeg ik me af hoe men aan het Sans font komt onder Debian. Dit is een soort voorstelling van het standaard sans-serif font. Dit wordt geconfigureerd in /etc/fonts/conf.avail/60-latin.conf, waar in principe Bitstream Vera Sans als eerste staat, maar tegenwoordig wordt dit niet meer geïnstalleerd, en wordt dus de 2de in de rij gebruikt, DejaVu Sans, welke eigenlijk een doorontwikkeling is van de Bitstream font. Nu, dit is volledig conform mijn vermoedens.

Nu, de reden dat ik Verdana overal wou veranderen is gedeeltelijk uit principe, om de gebruiker de vrije keus te laten wat voor font te gebruiken, maar ook ingegeven door het feit dat ik al een tijdje, op Citrix voor Athena na (en het BIOS), alle non-free software verwijderd heb van mijn Eee PC, al was het niet veel, enkel unrar, flash en de MS fonts. Nu, de fontconfig op mijn Eee PC blijkt niet geüpdatet te zijn bij de upgrade naar Wheezy, want op mijn desktop wordt er automatisch een andere sans-serif gebruikt.

Nu, er zijn ook een aantal aliassen gemaakt in 30-metric-aliases.conf, maar niet voor Verdana. Nochtans, DejaVu Sans kan zeker als vervanger voor Verdana dienen, al gebeurt dit dus op zich automatisch, aangezien dat het standaard sans-serif font is. Echter, MyBB definieert bijvoorbeeld als alternatief voor Verdana Arial, die heeft wel een alias. Hierdoor bestaat Arial dus plots, en wordt "Arial" gebruikt. Nu, ik zou liever hebben dat dit netjes Verdana is, en dus moet ik de code, of toch zeker die van het MS font naar het vrije alternatief (het omgekeerde staat er ook in, maar is dus hier zeker niet nodig), kopiëren naar .fonts.conf in mijn home directory. Als ik die code dan aanpas voor het gewenste effect bekom ik het volgende:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
	<alias binding="same">
	  <family>Verdana</family>
	  <accept>
	  <family>DejaVu Sans</family>
	  </accept>
	</alias>
</fontconfig>

Citrix Cerftificaat

Al een tijdje kon ik niet meer inloggen op Athenax, de Athena-site waarvoor geen VPN-verbinding vereist is. Ik kreeg met name een SSL error 61 met verdere info over welk certificaat tekort was. Uiteindelijk vond ik dat de Citrix certificaten worden opgeslagen in /opt/Citrix/ICAClient/keystore/cacerts, en daar blijken dan slechts 5 certificaten in te staan. Her en der op het internet vind je tips om van die map een symlink te maken naar /usr/lib/ssl/certs, maar dat lijkt me niet verstandig. Wanneer je dan een nieuwe versie van Citrix installeert zal je er dan eerst aan moeten denken om die link ongedaan te maken, want anders kan Citrix onbedoeld een aantal certificaten toevoegen, verwijderen of wijzigen, en dat met effect op het gehele systeem. Dus, heb ik gewoon het betreffende certificaat gekopieerd naar de de Citrix-map, waardoor het probleem is opgelost.

cp /usr/share/ca-certificates/mozilla/UTN_USERFirst_Hardware_Root_CA.crt /opt/Citrix/ICAClient/keystore/cacerts


Dropbox alternatief

Het is al een hele tijd dat ik de intentie heb om Dropbox te vervangen, en wel door een open-source alternatief, en liefst gebruik makend van ssh, zodat het onder eigen beheer kan functioneren, zonder speciale services, en dan valt, volgens mij, zo ongeveer alles af. Dat wil dus zeggen dat we zelf voor een oplossing zullen moeten zorgen. Het liefst natuurlijk zonder zelf algoritmen voor synchronisatie gaan schrijven, want die zijn er al in overvloed. We moeten dus op zoek naar een goede commandline synchronizer, die goed (en automatisch!) bestanden tussen een lokale en bvb een ssh-source synchroniseert.

Het is de bedoeling een vergelijkbare ervaring als Dropbox te bieden. Bijvoorbeeld, wanneer voor de (voltooiing van) een synchronisatie een bestand lokaal gewijzigd wordt, dan moet het oudere bestand genomen worden. Dat is zeker! Want, ik gebruik dit vooral voor het synchroon houden van programma-files. Ik wil mijn werk aan een project tijdens de week niet verliezen door Eclipse te vroeg op te starten in het weekend ... Ik vraag me af of er wel een situatie is waar je het nieuwste bestand zou willen. Volgens mij enkel als je tegelijkertijd aan een bestand werkt, dan eventueel, maar dat is zoiezo geen goed idee, want dat is de taak voor een systeem als SVN. Liefst wordt er van het bestand wel een backup gemaakt.

Als eerste was er dan de kwestie van welke synchronizer te gebruiken. Hierbij is de keuze gevallen op Unison, omdat het duidelijk en gemakkelijk via argumenten op de commandolijn aan te sturen valt, en ongeveer exact doet wat ik verlang, en wel met het volgende commando:
unison server local -batch -prefer server

Dit voldoet voldoet volledig aan mijn beschrijving van daarnet, behalve de backup. Dat kan wel, maar dan backupt hij alles. Dat wil ik nog kunnen beperken. Waarschijnlijk zal dit gebeuren door een extra script te schrijven dat alle backups verwijderd, behalve de conflicten. Omdat, zeker in het begin, de keuze voor Unison redelijk absoluut was, werd mijn nieuwe synchronizer de naam Unisister mee.

Nu heb ik inmiddels eens verder gekeken naar csync, wat gebruikt wordt bij ownCloud (de client daarvan is niet geschikt, want ownCloud gebruikt WebDAV, en daar heb ik geen zin in), en die heeft in ieder geval veel minder opties via de commandline. Als de basis van Unisister af is zal ik waarschijnlijk eens kijken naar hoe csync geïmplementeerd is in de ownCloud client. Gebruikt men config-files, of opties die geen weerslag hebben in de man-files? Dat zullen we dan zien. De mogelijkheid dat er zo wel gemakkelijk met backups van conflicten gewerkt zou kunnen worden is wel aanlokkelijk. Daarnaast is er geen actieve development van Unison meer, en worden er enkel nog bugfixes meer uitgebracht, aldus Wikipedia. Daarnaast ondersteunt Unison ENKEL ssh, waardoor het moeilijk wordt voor Windows gebruikers, maar dit is in de eerste plaats een programma die IK nodig heb, en van Windows heb ik geen last :P Maar blijkbaar is het niet zo vanzelfsprekend om ssh aan de praat te krijgen onder Windows, maar uiteindelijk: dit is geen programma die, zonder dat iemand zich er mee bezighoudt, gemakkelijk geinstalleerd kan worden onder Windows. Onder Linux is iets helemaal anders, vermits de dependenties gewoon geïnstalleerd kunnen worden door de package manager.

Nu, naast de (primaire) synchronizer-backend, is er natuurlijk nog een belangrijke keuze: de taal en de GUI. De keuze van de taal was redelijk snel gemaakt. C was hier niet echt van toepassing, vermits het uiteindelijk om een GUI om een bestaand commando gaat. Java is absoluut geen optie, is een belachelijke taal als je kijkt naar het geheugengebruik. Daarnaast had ik hier toch enkel ervaring met Swing, en dat is al helemaal geen optie. Het werd eigenlijk bijna onmiddellijk Python, en de voorgaande motivatie kwam achteraf. Een moeilijker keuze is die van de GUI. Omdat ik het enigszins cross-platform wou, en vooral naar andere toekomstige programma's toe, koos ik voor wxPython. Maar, ik was in eerste instantie wel vergeten dat dit een C++ library is, en ik heb toch eerder de neiging te kiezen voor C, wanneer ik moet kiezen tussen die twee. Maar, een ander argument om voor wxPython te kiezen was dat PyGTK niet meer verder ontwikkeld wordt naar GTK 3 toe, en vermits dit toch ooit waarschijnlijk de norm wordt, leek het voor mezelf redelijk zinloos om nu PyGTK te leren gebruiken.

Ondertussen heb ik gezien dat het helemaal niet zo absurd is om GTK+ 3 te gebruiken in Python dmv PyGOobject. Daar bestaat een goede turorial voor, maar zo'n boel, ik heb geen zin om dat allemaal te gaan lezen op de PC. Veel handiger vind ik het om dit op papier te hebben, maar 140 pagina's daar begin ik niet zo graag aan. Toen dacht ik aan die persoonlijke drukdiensten waar ik ooit over las in de PCActive (dacht ik ...), en al snel vond ik inderdaad lulu, wat me bekend in de oren klonk. Enfin, ik had goesting om dat te bestellen, zeker toen ik keek naar de prijs op economy-paper. Maar, ik was de verzendkosten vergeten, maar ook: de economy optie laat enkel Digest en US Letter toe al papierformaat. Nu is het simpel, de ene is te klein, de andere te groot. Ik heb niet graag een boek vast (is toch groteorde 150) dat zo groot is, en Digest is te klein voor 80 karakters aan code. Nu is dit toch het minimum, er onder wordt het al snel absurd.

Nu, de bestaande turorial was zoiezo niet aangepast aan een limiet van 80 karakters. Dus, heb ik de broncode gedownload:
git clone https://github.com/sebp/PyGObject-Tutorial.git

Vervolgens heb ik deze aanpassingen aangebracht, en gecompileerd naar LaTeX met volgende commando:
make latexpdf PAPER=letter

Nu, spijtig genoeg lukte het niet om hier al de papiersoort aan te passen, ook niet door dit gewoon toe te voegen in de Makefile. Dus had ik ook enkele aanpassingen nodig aan de gegenereerde LaTeX-code. En, zo heb ik het boek aangemaakt. Nu nog geld overschrijven op PayPal. Het boek is well (nog) niet publiekelijk toegankelijk, maar je kan het zo ook gewoon zelf bestellen. Je moet enkel een front-cover verzorgen en je kan zo ook bijvoorbeeld kiezen om bijvoorbeeld toch Economy op US Letter te drukken, en toch gemakkelijk 2,50 euro besparen. Mocht er vraag naar zijn, of ik heb er goesting in, wil ik het wel openbaar maken. Ik zal wel proberen om er eens tijd voor te maken om de wijzigingen door te geven aan de oorspronkelijke auteur/project.

Maar enfin, ik zou het misschien lezen tijdens de examens, en dan kan ik het programma aanpassen naar native GTK. De reden is vooral omdat ik toch gemerkt heb dat het niet altijd optimaal is met wxWidgetrs om bijvoorbeeld theme-support te hebben. Ik zal daar toch echt serieus voor moeten zoeken voor specifieke iconen die wel in de icon-set zitten (de programma-iconen), maar niet in de standaard acties zitten. Ik vermoed dat dat veel gemakkelijk zal zijn met GTK. We zullen dan wel zien.


Raspberry Pi

Toen ik het bericht over de voorbereiding van de Raspberry Pi toevoegde zag ik dat nog steeds geen post over mijn Raspberry Pi had toegevoegd. Ik heb toen zo ongeveer de eerste regel beginnen typen, en terug er mee gestopt. Nu komt het er toch eens van.

Oorspronkelijk had ik de Raspberry Pi besteld bij RS. Immers, Farnell bood geen verkoop van behuizingen aan aan consumenten, en er kon dacht ik zelfs enkel betaald worden via creditcard. Na meer dan 2 maanden had ik daar echter nog steeds niets van vernomen, en je las overal verhalen van mensen die al veel langer wachtten. Op hun website was er zelfs geen levering meer aangegeven sinds enkele maanden. Ik ben dus beginnen zoeken naar alternatieven, en bleek dat een aantal webshops ontstaan waren die Raspberry Pi's opkochten (bij Farnell?) en dan terug doorverkochten. Een ervan was NewIT, en die bleek in zijn korte bestaan een goede reputaties te hebben opgebouwd, en had geen al te hoge verzendingskosten naar België. Verder kon je er ook alles voor de Pi meteen bij bestellen. Ik moest wel nog even wachten, want men was nog bezig om een Europese voedingsadapter te zoeken om te verkopen, wat geen probleem was, vermits ik toch nog even moest wachten op de terugbetaling van Farnell, en tot er wat extra geld overgeschreven was op Paypal (want het was wel iets duurder dan RS, zo waren de verzendkosten in 9.95 pond, terwijl RS 6-7 euro rekende. Verder had ik ook een paar extra dingen besteld.

En zo had ik al snel, eindelijk, mijn langverwachte Raspberry Pi in handen. Ik had al vanaf de lancering wel zin in het apparaatje, maar werd wat uitgesteld, onder andere door de wachtlijsten aan het begin van de lancering. En ook toen ik bestelde leek RS al moeite te hebben om aan de vraag te voldoen. Ondertussen heb ik echter al een tweede Pi besteld die gecollecteerd wordt in het datacenter waar PCextreme zit, in Nederland. Het is de bedoeling daar een mailserver op te gaan draaien, want dat is toch een klein puntje van kritiek op PCextreme: ze hechten weinig waarde aan de verdere beveiliging door gebruik te maken van geëncrypteerde connecties van het e-mail verkeer. Daarom zal ik het dan maar zelf gaan doen. Volgende week wordt het opgeleverd, dus zou wel eens iets kunnen zijn om tijdens de examens 's avonds de gedachten even mee te verzetten. Ik heb ook wel zin om er een boek over ŧe kopen, maar daar heb ik nog geen beslissing over genomen.


Nieuwe URL's

Omdat de nummers te veel verspringen, en dus weinig of niet op elkaar volgen (wanneer dat wel zou zijn, zou ik het waarschijnlijk zo gelaten hebben) en dus eigenlijk helemaal geen betekenis hebben, heb ik besloten voortaan de volgende structuur voor de URLS van de blogposts te gebruiken:
/%category%/%postname%/

21/04/2013, 02:16:
Zonet zag ik dat de oude URL's niet meer werken door deze wijziging, en dus wordt deze wijziging ongedaan gemaakt. Ik zal later eens kijken om beide URL's te gebruiken. Uiteindelijk, zolang er geen archive-categorie is, zou dat geen probleem mogen zijn.


NFS met Raspbmc

Nu, met de Raspdebian, en nu ook met Raspbmc wil de sfs nfs-server niet meteen werken wanneer je die installeert. Na wat zoekwerk vond ik de volgende oplossing. Ik had die toen niet meteen hier gepost, en je ziet het, ik moest opnieuw zoeken:

apt-get remove rpcbind nfs-common
apt-get install rpcbind nfs-common nfs-kernel-server

Nog zo'n gevalletje was trouwens hoe de Pi kan ingesteld worden op PAL voor de analoge uitgang. Het antwoord is simpel: voeg de volgende regel toe in de /boot/config.txt (in Raspbmc kan dit via de instellingen, en waarschijnlijk is dat een betere optie voor wanneer de config opnieuw gegenereerd moet worden, zodat het dan niet opnieuw moet worden toegevoegd:
sdtv_mode=2


DVB-T driver

Het compileren van de module werkte goed, en het werkte effectief. Alleen, de tvheadend op de Pi draaien bleek toch niet de beste keuze, in die zin dat de pi vooral geen radd leek te hebben met de HDD en de DVB-T stick tegelijkertijd, en dat zou wel eens vervelend kunnen zijn als je wil opnemen ... Dus, de oplossing zou dan zijn dat de Pi enkel nog de frontend heeft, en de backend op mijn pc draait. Om dat te doen moest ik dus ofwel de experimentele (voor Debian) Linux 3.8 kernel draaien, of moest ik de module gewoon compileren voor mijn computer. Ik heb dat laatste gedaan, en wel volgens de volgende stappen:
Eerst en vooral moest ik natuurlijk de source downloaden:

git clone https://github.com/ambrosa/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0
cd DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/RTL2832-2.2.2_kernel-3.0.0

Volgens de website die me op weg hielp bij het compileren en opsporen van alle zaken werd vermeld dat ik INCLUDE_EXTRA_DVB moest aanpassen naar 320. Toch bleek ik achteraf tegen problemen aan te lopen. Al snel vond ik allerlei mogelijke fixes, maar toen ik in de Makefile keek zag ik dat het eigenlijk geen probleem zou mogen zijn. Toen ik zelf een absolute locatie ingaf bleek het wel te lukken. Blijkbaar gaf PWD een verkeerde waarde terug ...

INCLUDE_EXTRA_DVB := include-320
SOURCEDIR := /home/kevin/Documents/SVN/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/RTL2832-2.2.2_kernel-3.0.0

En vervolgens compileren, in de juiste map zetten en aan als module aan de kernel toevoegen:

make clean
make
sudo cp dvb-usb-rtl2832u.ko /lib/modules/3.2.0-4-686-pae/kernel/drivers/media/dvb/dvb-usb
sudo depmod -a

Nu had ik een vloeiend werkende TVHeadend backend, maar op de Pi kon ik NIET afspelen. Daar kreeg ik enkel een zwart scherm, terwijl het op mijn computer altijd al lukte. Dit bleek een probleem te zijn van Omxplayer. Wanneer je echter een recentere versie van TVHeadend (ik gebruikte eerst de stable repo voor wheezy, nu de unstable (in de beta had ik het niet gevonden, maar waarschijnlijk keek ik op de verkeerde plaats, want ook bij de unstable vond ik het niet direct. Ik zal dit zeker nog eens controlleren) en timeshift activeert, werkt het wel. Enig probleem: wanneer je rechtstreeks TV kijkt is de verhouding van het beeld totaal verkeerd. Naar verluid wordt er momenteel hard aan gewerkt, dus hopelijk dat er binnen afzienbare tijd een update komt voor Raspbmc waarin het werkt. Eventueel zou ik zelf een andere versie kunnen installeren, want naar verluid zijn er builds waarmee het al werkt.


Raspbmc

Vorige week is hij eindelijk toegekomen: mijn TSOP4838 ontvanger die ik op 20 februari (!!!!) heb besteld. Deze stond al sinds 27 februari gemarkeerd als klaar voor verzending en via de website zelfs als verzonden (Conrad stuurt GEEN bevestiging van verzending), maar ik heb die nooit ontvangen. Ik heb daarvoor tweemaal contact opgenomen met Conrad, via de website, en nooit geen antwoord op gehad. Toen ik vorige week maandag belde (was wat weigerig, want het kost 1 euro per minuut vanaf een GSM) bleek het net afgehandeld te zijn. Leuk detail: in mijn doos zat een mooie factuur! Nochtans had ik met voorafbetaling gewerkt (dat koste me 7 euro verzendkosten, maar uit privacyoverwegingen wou ik niet betalen via een systeem dat vanaf de server inlogt op mijn PC banking account! Daarnaast bleek bankcontact via hun website niet te werken met Fortis) en hiervan reeds bevestiging gekregen op 25 februari! Nu moet ik zeggen dat het me een beetje tot hier (wijzend 2 meter boven het plafond) zit, en ik dan ook zal trachten om Conrad te mijden. Probleem is echter dat zeker voor zaken als die IR-receiver er niet echt heel veel goede alternatieven lijken te bestaan. Creditcards, hoge verzendkosten en bulkbestelling, daar ben ik niet echt in geïnteresseerd.

Nu was het idee dus om die TSOP receiver aan te sluiten op mijn Raspberry Pi, en dan een multifunctioneel "baksje" (voor de niet-West-Vlamingen: afstandsbediening) uit de Action, die ik had gekocht voor mijn TV op mijn kot gebruiken om de Pi aan te sturen. Nu stond er Raspbian op, en dit moest Raspbmc worden. Dit genoot mijn voorkeur wegens het gebruik van de Debian basis, zoals Raspbian (is het niet op Raspbian gebaseerd?), wat een groot pluspunt is, en zelfs noodzakelijk, aangezien de Pi enkele tunnels naar het netwerk in Eggewaarts moet openhouden, en de externe HDD moet beschikbaar gesteld worden via NFS. Oorspronkelijk was het de bedoeling om dit alles op een Kingston kaartje te doen die ik al klaar had gelegd. Door het lange wachten is het echter waarschijnlijk van mijn bureau gevallen, en zo bij het vuilnis terecht gekomen ...

Ik heb dan maar mijn kleinere Samsung gebruikt die ik reeds gebruikte voor Raspbian. Nu is alles ingesteld. Het was even zoeken om mijn baksje goed in te stellen voor XBMC. Als basis gebruikt ik deze handleiding. Of toch gedeeltelijk. Ik had XBMC reeds ingesteld op een eigen config. Om zo'n config aan te maken gebruikte ik het volgende commando:
irrecord -d /dev/lirc0 ~/lircd.conf

Dit heb ik een aantal keer herhaald voor een paar verschillende mogelijke configuraties van het baksje zelf. Het was wel een probleem om het contextmenu te openen met een toets. Eerst had ik getracht met KEY_CONTEXT_MENU, maar dat lukte niet. De toetsenboordcombinatie is m, en dus probeerde ik KEY_M. Ook dit lukte niet. Vervolgens heb ik verschillende configs bekeken en uiteindelijk lukte het met KEY_TITLE.

Nu had ik ook een DVB-T usb-stick besteld, en ontvangen. Nu is het probleem dat deze pas sinds kernel 3.8 standaard wordt ondersteund. Standaard gebruikt Debian Wheezy, die al enige tijd voorbij de feature freeze is, 3.2, Raspbian gebruikt 3.6. Dit wordt dus compileren, en dat ben ik momenteel aan het doen volgens deze instructies.