updating aur packages with yaourt

Wednesday, December 6. 2017

This is a work in progress for right now I dont seem to know how to do it right.

sudo yaourt -Syu --aur 

searches through my system and upgrades the db and then presents me a list of aur packages that need upgrade and then it works it's way through the list and I need to stay there and check every dialog and when there is a package I do not wish to upgrade I cannot skip it. Sure, there is a dialog asking me if I want to update this package, but if I give it a "no" the entire routine is aborted.

So, in case the package I really want to update happens to be the last in yaourt's list I have to update all of them, including the huge font collection which takes ages to download and build, and including the printer driver which I'd rather not touch at all.

That got me shouting and cursing yesterday cause following the update of the driver for the Brother QL-710w label printer the darn thing wouldnt print any more. CUPS was happy though, preparing the print data, posting them to /var/spool/cups and instantly flag it for completed, no errors.

The package that gave me trouble is  aur.archlinux.org/packages/brother-ql710w/  with the version 1.1.4r0. The prior version, pkgver=1.0.2r0 had installed and worked like a charm.

I spent hours trying to find a reason ar even a hint t what was failing to work but nothing helped until I decided to downgrade to the original version.
Now, with 'official' arch packages this is rather esy, there is a storage of older versions at /var/cache/pacman/pkg and you can take the package from there and downgrade with a pacman -U packageName

 But packages from aur are built when you install them, in /tmp and so they are usually lost when you try to step back. I have learned now that there is an option to change this in the /etc/yaourtrc config file. Next time it will be easier.. But as things were I chose a different path yesterday, I manually downgraded the package when it offers me to edit the build script. Changing the pkgver and the sha256sums was all it took.

One of the things I discovered was a nice feature of the aur git, in my case the url is https://aur.archlinux.org/cgit/aur.git/?h=brother-ql710w

I clicked around and soon had the site show me diffs of the prior and new version. Clearly the package was not at fault for my problems. Or Brother has changed some requirement for the install which the former version did not need and which should be reflected in the new package version - I didn't investigate this.

What I did is, searching on the Brother support site for links to older versions of the driver (none!) and then play around with the new url until I succeeded to get the old versions. Naming conventions are a good thing. Then, after successfully downloading them I took their sha256sums

sha256sum ql710wcupswrapper-1.0.2-0.i386.rpm

and those I pasted into the build script. After hours of fruitless trying I was perplexed to see it work on the first go.

That step wasn't actually necessary, I could have taken the sums from the diff at aur.archlinux.org/cgit/aur.git/diff/PKGBUILD 

 

Von Squeeze zu Wheezy

Sunday, May 12. 2013

Ein wenig nervös macht mich ein Dist-Upgrade schon, man hofft auf di Linderung einer lang ertragenen Druckstelle durch das viel aktuellere Paket so.und.so und ahnt doch, dass das durch manchen neuen Kummer erkauft wird. Auf den ersten Blick schien auf dem meist headless laufenden Rechner auch alles zu laufen, die Überraschungen kamen mit den grafischen Oberflächen.

Die Kiste lief vorher schon mit LXDE, aber nach dem Upgrade war plötzlich wieder Gnome der Standard. Gnome3 und was mich nun wirklich störte, war die Fluppe, die mir Gnome nun ständig zog, weil es in der thightvnc-Umgebung nicht alle Features ausspielen konnte sondern im Fallback-Modus lief. 

Gnome3 in der tightvnc-Umgebung eine Zumutung gefunden, versucht, es durch LXDE zu ersetzen.LXDE soweit unbenutzbar gefunden, ein Grossteil der Probleme mögen nicht wiedergefundene config-Dateien sein aber auch nach vielen Stunden Mühen blieb es dabei, dass der pcmanFM nur für root startete und sichtbar wurde (incl Desktop-Bild, Icons, Config-Dialog), für user aber zwar startete, aber nicht angezeigt wurde.Endlich aufgegeben und stattdessen XFCE installiert, dass nun tut was es soll. Bei der Gelegenheit habe ich mich des überwiegenden Teils der Gnome3-Pakete entledigt.

Noch etwas hefiger war die Entdeckung, dass mit dem neuen Kernel 3.2.0-4-amd64 nicht mehr die ganze Bildschirmfläche benutzt wurde, sondern nur noch die oberen 1280x768. Den Kernel hatte ich anfangs nicht in Verdacht sondern Grub, denn der zeigte anfangs das Grub-Menue noch auf der vollen Fläche, wechselte dann aber nach den ersten Bootmeldungen in den beschnittenen Modus. 
Wie schon beim LXDE-Fiasko fand mir Google nur ganz wenige vergleichbare Faelle und kein Beispiel mit einer besseren Lösung als der, einen neuen Kernel zu installieren. Ich probierte es mit dem alten und weg war das Problem.
Auf dem Desktop von Arch Linux und dessen problemlosen Aktualisierungen verwöhnt begann ich schon, nach Alternativen zu schielen, aber das hätte nun gewiss nicht mehr in dies Wochenende gepasst. Und als Router und Gateway zum Wan ist der Rechner doch ziemlich unverzichtbar.
Also bleibe ich vorerst bei dem uralt-Kernel 2.6.32-5-amd64.

owncloud 5.0

Saturday, March 16. 2013

(owncloud ist in reger Entwicklung und manches Problem, dass ich mit 5.0 sah, hat sich im Laufe der versionen schon erledigt. 
updates am Ende des Artikel.)

Heise berichtet von der eben erschienenen Version 5.0 von ownCloud und deutet auf laestig klingende upgrade-Methoden. Aber ich hab' es doch im repository... hier reicht ein apt-get update && ap-get upgrade und dann erscheint, nach Aufruf der Wolke, ein kurzer Hinweis auf das Upgrade, pling, pling,plong, pling, erfolgreich, weitergeleitet - fertig.
Erstmal login als Administrator, es sind eine Reihe neue Applications dazugekommen und ich aktiviere tasks - Antivir: hat zwar die Anmerkung "recommended", schmeisst mir aber gleich eine Fehlermeldung.
Auf den ersten Blick kommt mir die neue Oberfläche etwas dunkler vor, platzsparender und bedienbarer.
Raus und zweites Login als user, ich bekomme erst einmal minutenlang einen Verlaufsbalken mit dem Titel: "Dateisystem-Cache wird aktualisiert ..." Und dann: "Alles leer - lade etwas hoch!" :-( - da ist schon mal was verlorengegangen. Hoffentlich nur der Link...

Kurz mal durch die anderen Optionen:
Kontakte kennt auf einmal Gruppen! Schon mal ein Schritt in die richtige Richtung.
Aufgaben kennt keine hierarchischen Beziehungen zwischen tasks, also kein "Kapitel 1" .. "Kapitel n" als subTasks zu "Buch". Eine Task hat Title, Kategorie, Ort, Fälligkeit, Fertigstellung scheint Boolean zu sein. Nach Priorität kann man sortieren, aber wo man die setzt, sehe ich erst mal nicht.

Ein Blick in's forum.owncloud.org/ bestätigt, dass andere die Probleme (Dateien, Task/Priority) auch haben.
Es findet sich auch ein Hinweis auf ein Google import app.

Nach etwas stöbern und probieren sieht es für mich, was die fehlenden Inhalte in meinem ownCloud storage angeht, so aus: 
- unbegreiflicherweise sind alle Ordner, die zum Zeitpunkt des upgrade existierten, unsichtbar. Und zwar permanent und aktiv unsichtbar. Ich kann sie aus dem jwlg Verzeichnis verschieben, in der ownCloud-Oberfläche einen neuen, gleichnamigen anlegen, alles wunderbar. Ein Click auf Dateien und die Ordner sind unsichtbar. Dass sie existieren und zugänglich sind, kann man mit etwas Url-Gymnastik leicht feststellen. Aber sie werden eben nicht angezeigt.

Ok, neue Ordnernamen, gefällt nicht wirklich aber ein gangbarer workaround. Aber die Logik dahinter entgeht mir.

Es tut mir leid, das so sagen zu müssen, aber owncloud 5.0 funktioniert derzeit nur im Prinzip. Konkret erlebe ich dagegen einen Sack von Unzuverlässigkeiten, Funktionsausfällen, Überraschungen dass ich es derzeit allenfalls als Ergänzung zu den Google-Diensten nutzen kann, aber nicht als deren replacement.

Update:
Mit einiger Mühe hatte ich 5.0 dann letztlich doch in grundsätzlich funktionierendem status, 5.03 brachte dagegen einen markanten Sprung nach vorn, die erste Version, wo "Bilder" für mich nicht völlig kaputt aussieht....

Update
5.04 ist eben installiert und macht einen weiter verbesserten Eindruck. Allerdings ist auch nur ein rudimentäres subset der Features hier wirklich in Gebrauch, letztlich nur webdav / files. Kontakte sind bei google eben doch noch weit flexibler mit dem tagging zu Gruppen und der sync zu Thunderbirds Adressbuch. Und bislang habe ich noch keinen praktikablen weg gefunden, Kontaktbilder von Google nach owncloud zu ziehen. Nur schade, dass viele der drittseitigen Apps mit 5.x gar nicht laufen.   

Update
5.05 nennt sich selbst in der config.php 5.0.6, aber das war wohl auch bei der Vorversion schon so. Die "Geister" in Musik und Dateien gab es immer noch, daraufhin habe ich mit apt-get purge owncloud und brutaler Gewalt gegenüber der config.php und den Tabellen der mysql-db eine komplette De- und anschliessende Neuinstallation erzwungen. Seither funktionieren Bilder und Musik deutlich besser.

Update 15.5.2013
owncloud hat ganz offenbar eine interne Versionierung, die der veröffentlichten vorauseilt. Außen drauf steht 5.0.6 und so heisst auch das debian package (5.0.6-0) - aber die config.php nennt sich schon 5.0.8'  Das Upgrade selbst geht mit apt-get locker, anschliessend akualisiert sich OC mit dem ersten Aufruf der Seite im Bowser. Kein Problem dabei.
Ich benutze von den Modulen ja faktisch nur Dateien. weil mir für Kalender, Kontakte und Tasks die Synchronisierung mit den entsprechenden Google-Diensten fehlt, Musik geht nicht im Hintergrund weiter. Bilder funktioniert seit 5.0.5 besser als zuvor, ist aber immer noch etwas verwirrend. Der beklagt langsame Upload ist wohl wirklich schneller geworden, wie das release note aufführt, ich habe wie im Testszenario mp3's hochgeladen, über https://, allerdings im intranet. 446 MB in 90 sec. Upload über externe Verbindung steht noch zu testen aus.

Update 17.8. 2013
Owncloud ist bei mir nun schon mehr als einen Monat auch für Kontakte und Kalender an die Stelle von Google getreten und abgesehn von der mühsamen Migration der Kontakte und nur eingeschränkter Unterstützung der Gruppierung von Kontakten im neuen Thunderbird-Addon ist alles wunderbar. Immer mal kommt eine neue Version, derzeit 5.0.10 aber die anfangs teils holprige Update-Prozedur geht inzwischen locker durch.

 

KDE 4.8.3

Wednesday, June 20. 2012

Am Morgen begruesste mich KNotify mit dem Hinweis auf 129 ausstehende upgrades und siehe da, KDE 4.8 haelt Einzug.
20 min und einen reboot später sehe ich

  • Lancelot Launcher beklagt einen Fehler
  • die ganzen Einrichtungen der virt. Desktops (Hintergrund-Bilder, Folderview- Fenster etc) sind wieder mal verschwunden
  • Dolphin und Konsole wollen über beide Monitore aufspannen, das width 1280=1281 - Spielchen geht also weiter
  • About KDE sagt 4.8.3, KInfo führt aber immer noch KDE SC 4.7.4 auf
  • Klipper ist aus dem systray verschwunden (lässt sich mit KRuner aber wieder starten)

Einen Versuch, die Desktop-Möblierung zu Fuss mit Edit der ~/.kde/share/config/plasma-desktop-appletsrc zu restaurieren gebe ich genervt auf, das Format dieser Datei ist ein übles Gestrüpp, gibt es dafür keinen grafischen Editor? Wäre fast wert, ihn zu schreiben.

Ansonsten entdecke ich erstmal eigentlich wenig Unterschiede.

Am Folgetag kam noch ein Schwung, dpkg -l|grep kde zeigt mir, dass es ein Mix von 4.7.4, 4.8.3 und 4.8.4, ist, was sich da tummelt, und KDEPIM steht im Wesentlichen noch auf 4.4
KOrganizer und Google (Kalender, tasks) spielen nun gar nicht mehr miteinander, jeder Versuch einer Authentifizierung gibt mir "parsing token page failed" und dann poppt noch KDE wallet service mit "There have been repeated failed attempts to gain access to a wallet. An application may be misbehaving." In der Tat. kdepim kriegt die Axt.

Ach, und die eben restaurierte Möblierung meiner virtuellen desktops war mit dem folgenden Update auch wieder durcheinandergewuerfelt. Das ist schon mehr als irritierend.

 Nun, zwei Wochen später ist alles auf 4.8.4, bis auf kdePim, und die Desktops sind auch noch so wie eingerichtet.

 

Squeeze mit aktuellerem Kernel

Monday, October 24. 2011

Anstoss der Unrast sind die heftigen Performance-Einbrüche meines Rechners während der regelmässigen incrementiellen Backups auf eine externe USB-Festplatte. Die ist wirklich nicht besonders schnell, hdparm -t ermittelt 30 MB in  3.09 seconds =   9.72 MB/sec. Mein HTC Desire ist da mit bis zu 14 MB/sec merklich schneller.

Das das Backup relativ langsam geschrieben wird ist aber an sich gar kein Problem. Wirklich nervend ist, dass die CPU sich dabei mit 80, 90% wait states eindeckt und kaum noch etwas anderes erledigen mag als, auf die lahme Platte zu warten. Auf der Suche nach möglichen Auswegen stiess ich auf Hinweise, dass Linux ab 2.6.37 mit solchen Situationen besser umgehen könne. Squeeze hat 2.6.32. Einen Versuch wär's wert.

Woher einen aktuelleren Kernel nehmen? Backports (hilfreich bei der Auswahl von Paketen), und eine schon brauchbare Anleitung für die konkreten Schritte fand sich auch bald, brauchte aber dann doch noch ein paar Änderungen und Ergänzungen.

- es schadet nicht, ein aktuelles Backup von /boot und /etc zu haben...
- nano /etc/apt/sources.list
- dort unten diesen Eintrag anfügen: 
  deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free
- apt-get update
- und jetzt installieren:
   apt-get install -t squeeze-backports linux-image-2.6-amd64

Der install macht auch ein update der Grub-Konfiguration und fügt für den neuen Kernel oben auf der Liste zwei Einträge ein. Wenn nicht alles so geht, wie man gehofft hat, kann man im Grub-Menü nach unten wandern und den bisherigen Kernel booten, das ist die dritte Zeile im Menü.
Klappte soweit ganz gut, ein paar Sachen waren aber zu erledigen. So kam beim Install ein Hinweis auf fehlende (non-free) Firmware, die für diesen Rechner mit
apt-get install -t squeeze-backports firmware-realtek
kam. Weiter monierte der install schon:

dkms: running auto installation service for kernel 2.6.39-bpo.2-amd64:
      vboxhost (4.1.4)...failed.
      nvidia (195.36.31)...failed.

dkms: WARNING: linux headers are missing, which may explain the above failures.
      please install the linux-headers-2.6.39-bpo.2-amd64 package to fix this.

Wirklich landete ich nach dem ersten boot des neuen Kernels auf der Konsole, mangels Grafiktreiber. Google fand mir diese Anleitung, NVidia-Treiber auf dem backported Kernel zu nutzen. In der bash_history hat dieser Schritt solche Spur hinterlassen (das shell script nvidia_heilen.sh entspricht dem auf obiger seite gelistetem)

apt-get install -t squeeze-backports dkms nvidia-kernel-dkms
dpkg-reconfigure nvidia-kernel-dkms
grep -ie error /var/lib/dkms/nvidia/195.36.31/build/make.log
cd /usr/local/src
mkdir backportkernel
cd backportkernel/
nano nvidia_heilen.sh
chmod 755 nvidia_heilen.sh
./nvidia_heilen.sh
apt-get install -y nvidia-glx
apt-get install -y nvidia-glx-ia32
apt-get install -y nvidia-xconfig nvidia-settings
reboot

Nun lande ich wieder auf dem grafischen Desktop und nicht nur der nvidia-Treiber sondern auch der ebenfalls monierte vboxhost sind geheilt. Bleibt vmware. Hier die hilfreiche Webseite (leider ist sie jetzt, beim schreiben dieser Zeilen, nicht verfügbar). Infos und Beschreibung treffen, aber bei mir klappte es auch mit dem Patch nicht. Letztlich half der Link zu den gepatchten Sourcen. Der Vmware-Player (3) baute sich seine Module, die liefen aber erst nach einem reboot.

Fein, damit war das Update gelungen - hat es auch was gebracht? Sieht recht gut aus, top zeigt die wa während der rsync-Läufe zwischen 25 und 30%. Und gefühlt ist das Problem damit bereinigt.

Update:
Für die Aktion etwas zu spät stieß ich auf  smxi/sgfxi/svmi, eine Familie von Scripten, die sich ganz dem Kernel-Update und der Kompilierung von Grafik Modulen und Modulen für vmbox und vmware widmen und die Sache um einiges leichter machen...

(Page 1 of 2, totaling 6 entries) » next page