Seraphyn Blog

Es wurde auch endlich mal Zeit, dass ein "böses" Debianpaket aufschlägt und ich hatte es schon früher erwartet. Nicht nur ich, auch andere Debianer warteten auf den Moment bei welchen es richtig los geht. Dieser Moment ist nun gekommen und eine Aussage, welche ich immer in die Welt hinausposaune ist jene:

- Installiere nur Pakete aus Quellen, welche Dir bekannt sind.
- Sind Dir die Quellen nicht bekannt, nimm den Quellcode sichte Ihn und baue selber eines.
- Kannst Du jenes nicht, warte bis das Paket Deine Distributionsserver erreicht, ist dem nicht so, schlage das Paket vor.
- Nimmt sich keiner des Paketes an, lerne Debianpakete zu bauen.

Scheinbar ist dies eine Situation, welchen nicht Allen Linuxnutzern bekannt ist und jene scheinen sich darauf zu verlassen, Linux sei Sicher. Dem ist nicht so, es ist vielleicht sicherer, aber nicht sicher per se. Wird es auch niemals¹. Nur im Gegensatz zu Windows, kann man mit einem unixoiden System einiges mehr anrichten, als mit einem Windows, welches von Haus aus nicht so massive Werkzeuge mit sich bringt, wie ein Unix/Linux.
Zum Glück, das ist es wirklich, hat sich der kleine Scripthippie nicht auf eine sehr böse Sache spezialisiert, sondern er haut einfach ein "paar" Pings auf eine Domain. Ich erinnere nochmals daran, dass man ein Paket mit Rechten des Benutzers root installiert. Stellt sich die Frage, was wäre, wenn er etwas mehr in die Trickkiste gegriffen hätte und sich die Maschinen wirklich unter den Nagel reißen würde. Remote. Eine Firewall dazwischen ist nicht wirklich das Problem, denn Outbound ist immer etwas erlaubt. Man muss es nur versuchen. Eine Anleitung dazu gebe ich nicht.
Also, Pakete nur aus bekannten Quellen installieren.

¹ Software, von Menschen geschrieben, wird immer einigen Fehlern unterliegen. Ich meine wir sind Menschen. Ich denke, dass muss ich nicht weiter ausbreiten.

Ja, so ist das. Da denkt man sich nichts dabei und lädt nur die Debs hoch und vergisst in dem ganzen die GPL. Nun nicht ganz sie liegt im Verzeichnis und ich ging davon aus, dass jene, welche sich die debs herunterladen, auch Wissen wo die Sourcen sind und vor allem da eine GPL jedem DEB beiligt.
Nun Herr Seraphyn, falsch Gedacht. Mir wurde Heute eine virtuelle Watschen von Carsten Hey gegeben, dass ja meine ganze Software dort Illegal wäre. Somit die beanstandeten fehlenden Datein hochgeladen ( Etch-Debs musste ich aus meinem Backup popeln) und ich hoffe somit ist alles rechtens. Also, dass ich mal in dem Punkt stehe die GPL zu brechen ist mir auch was Neues, vor allem als jahrelanger großer Fan, aber nun, er hat schon Recht.
Achja, die Mail noch:

Hi,

I'm going to compile apvlv, I hope it sucks less than the other PDF
readers. :)

It is published under the terms of the GNU GPL 2.1 or any later version.
The problem is that the is no such license, the is only a LGPL 2.1, but
no GPL 2.0, which is also distributed in COPYING, so I guess you meant
this license.  Please consider changing "2.1" to "2.0" in your source
files.  The note in the README is is missing license information, which
is not very helpful, so please consider adding it to this file too.  If
you simply don't care about licenses switching to a 2-clause BSD like
license or the MIT license might cause less headache, though it would
allow commercial software to be based on yours.  One problem that could
be caused by using the GPL is that linking against OpenSSL is considered
to be legally questionable for GPLed software by many people and so your
users would not be allowed to do this when you add SSL support to apvlv
and forget to add a appropriate linking exception.

There is already a Debian package for apvlv available on
http://seraphyn.deveth.org/files/index.php?dir=debian/LENNY/APVLV/ which
is illegal since there no source available, only the compiled Debian
binary package, the other GPLed software in this repository is also
missing the source code.  Christian, it would be helpful for others when
you respect this part of the GPL in the future and also upload the
Debian source packages (.diff.gz, .dsc and .orig.tar.gz) to your
repository.


Regards
Carsten

Wer sich über die Mail nun aufregt, der hat es nicht verstanden.
Nochmals danke Carsten für den Hinweis auf meinen Fauxpas.

Soweit bin ich nun, dass ich die libsoup-2.4 zu den CPPFLAGS und LDFLAGS zugefügt habe, Danke an Morasique aus dem #uzbl-Channel.
Nun bin ich bei den nächsten Errors und hoffe nicht, dass ich eine neue Version von Webkit bauen muss. Leider bietet backports.org keinen Backport für Webkit an. Aber ich lasse mich nicht so einfach unterkriegen. Es wird ein deb geben.
To be continued ...

[UPDATE]
So, Xeno hat auf seinem Blog ein Patch und ein Repository bereitgestellt, welches Updates für die Files:
libproxy-dev_0.2.3-3~bpo50+1
libproxy-tools_0.2.3-3~bpo50+1
libproxy0_0.2.3-3~bpo50+1
libsoup-gnome2.4-1_2.26.2-1~bpo50+1
libsoup-gnome2.4-dev_2.26.2-1~bpo50+1
libsoup2.4-1_2.26.2-1~bpo50+1
libsoup2.4-dev_2.26.2-1~bpo50+1
libwebkit-1.0-2_1.1.7-1~bpo50+1
bietet.
Da er auch einen Patch geschrieben hat, damit kein libgtk2.0 Backport gebraucht wird, war es mir nun ein leichtes für mich ein Debian-Paket zu bauen. Somit, wer gerne uzbl testen möchte, muss das Respository von xeno einbinden und kann sich dann aus dem Quellen selber uzbl bauen. Ich kann nur sagen, der Browser ist es wirklich wert und passt sehr gute zu meinem ion3.
Wenn eine Anleitung erwünscht ist wie man Ihn baut, kann ich das gerne nachliefern, nur ich gehe davon aus, dass jene, welche diesen Browser aus den Gründen nutzen, wissen wie man einen patch anwendet und auch wie man Sourcen kompiliert. Eines muss ich zugeben, durch meine Geilheit, den Browser schnell als deb zu bauen habe ich doch glatt vergessen das examples-Verzeichniss mit in /usr/share/doc zu packen. Aber ich werde nun ein wenig durch das Netz mit uzbl surfen und das Alles auf ein anderes mal vertagen. Ich hoffe, dass sich uzbl in der nächsten stabilen Version von Debian befindet.
Danke nochmal an Xeno für die Arbeit...

nice ist mir wohl bekannt, aber das Debian ein Programm namens cpulimit besitzt, dass wusste ich nicht.

Limit CPU Usage By Process
cpulimit is a simple program that attempts to limit the cpu usage of a process (expressed in percentage,
not in cpu time). This is useful to control batch jobs, when you don't
want them to eat too much cpu. It does not act on the nice value or
other scheduling priority stuff, but on the real cpu usage. Also, it is able to adapt itself to the overall system load, dynamically and quickly.

Gute Idee und was neues gelernt.

Ich bin ein großer Fan von xpdf. Und jener hat nun einen starken Gegner in meinen Augen bekommen: apvlv.
Für jeden großen vim-Anhänger im Grunde ein Muss, da sich die Keyboardshortcuts an die gewohnten von vim halten und somit ein kleines Heimatgefühl geben. Sprich CRTL-F eine Seite vorwärts, CTRL-B eine Seite rückwärts, 'k','j','h','l' Seite hoch, runter, links und rechts. Auch können die Seiten für das Vorwärts-/Rückwärtsspringen vor dem Befehl mit angegeben werden. Sprich 50 und dann CTRL-F springt 50 Seiten nach vorne etc.
Natürlich kann auch apvlv mehrere Fenster auf einmal anzeigen, ich empfehle dazu die Screenshots auf der Homepage, denn die Erklärung von mir dazu klingt irritierend.
Und da ich, wie immer schon, für mich ein Debian Paket für Lenny gebaut habe, wurde jenes nun wieder von mir hochgeladen :
apvlv_0.0.6.4-deveth-1_i386.deb
Unter /usr/share/doc/apvlv/ befindet sich die Datei apvlvrc.example für die eigenen Einstellungen und auch eine README-Datei.

Ich bin mal dreist.
Ich werfe einfach mal diese 4 Werkzeuge für Debian in den Raum mit einer kurzen Erklärung, aber ohne Anleitung.
Wegen debirf braucht man sich keine Sorgen zu machen, ich habe für Debian Lenny eine Version 0.21-1 gebaut (debirf_0.21-deveth-1_i386.deb)

debirf: Baut einen Kernel und einen initrd um Debian direkt im RAM zu fahren. Homepage direkt
dpkg-repack: Eines meiner Lieblingswerkzeuge unter Debian, baut aus einem installierten Debian-paket ein neues inkl der lokal geänderten Konfiguration.
dfsbuild: Debian from Scratch LiveCDs erstellen
Remastersys: Aus einem installierten Debian eine LiveCD erstellen, kann auch benutzt werden um eine eigene LiveCD zu erstellen.

Wenn man nun das ganze ein wenig betrachtet, bringt es einen das doch auf richtig lustige Ideen, oder nicht?
Mich jedenfalls schon und ich denke da an viele Dinge, welche man damit gut lösen kann. Happy Hackin'

Jamendo ist ein Dienst für freie, legale und unlimitierte Musik, die unter Creative Commons Lizenzen veröffentlicht wurde.
Das lassen wir doch mal so stehen und entspannen uns mit freie Musik auf einem freien Betriebssystem. Nur man möchte es sich auch einfach machen und nicht die Seite ansteuern, um die Musik per Flashplayer zu hören, oder ein wirklich gutes Album herunterzuladen.
Hier springt Pyjama in die Bresche. Pyjama lässt sich sehr einfach installieren, indem man das angebotene Debian-Archiv herunterlädt und per dpkg -i installiert.
Nach dem Start von Pyjama wird die Datenbank der Musiker, welche sich bei Jamendo befinden geladen und umgewandelt, dies kann je nach Rechnerleistung ein paar Minuten dauern. Wenn man die Anzahl der Musiker betrachtet, welche Ihre Musik frei bei Jamendo zur Verfügung stellen, ist es mehr als natürlich und nicht negativ für Pyjama zu werten.
Das schöne an Pyjama sind die Features für welche sich Pyjama nicht verstecken muss hinter den Größen wie z.B. amarok. Sei es eigene Playlisten generieren, Playlisten von Jamendo benutzen, die meistgehörten Titel abspielen,  Ratings vergeben, best rated Titel hören, Download der Musik und und und. In dem Falle ist Pyjama noch halbwegs genügsam als Python-Programm und macht bis Dato Spaß. Im Moment höre ich mir den JackJohnson-Verschnitt namens Sean Fournier mit seinem Album "Oh My" an und muss wieder einmal darauf hinweisen, dass sich Musik, welche unter der CreativeCommons-Lizenz veröffentlicht wurde nicht zu verstecken braucht. Eines muss ich aber zugeben, mit ncurses unter der Shell würde es mir noch besser gefallen ;)

Nicht immer muss eine fette aufgeblasene Benutzerschnittstelle sein, welche einen Rattenschwanz an Bibliotheken hinter sich herzieht. Ich bin in dem Punkten schon ein wenig extrem und versuche immer ein Pendant zu finden, welches die Aufgaben für bestimmte Zwecke simpel und einfach erledigt.
Um eine ISO-Datei unter der Shell zu brennen reicht ein einfaches cdrecord -v -dao dev=/dev/hdc speed=24 ISONAME und das war es. Nur wenn es mehrere Dateien geht, ist ein kleines Programm schon ein wenig besser. Ich habe mich in dem Punkt für cdw entschieden. Im Grunde beherrscht cdw auf den Konsole alles, was ein Brennprogramm beherrschen muss, ausser das brennen von DVD-RAM, Blu-ray, HD-DVD und das brennen von MP3 zu AudioCDs. In dem Punkt ist schon k3b besser, aber wenn es um andere Arbeiten geht, brauche ich k3b nicht wirklich, zum Bsp. das Brennen von Files über eine SSH-Verbindung, oder auch mal schnell hier und da ein paar Dateien als Backup auf CD zu brennen. Ersetzen will es die großen Brennprogramme auch nicht, sondern nur eine Lücke schliessen und ich finde dies macht es sehr Gut. Ein Grund warum ich auch auf das Programm hinweise findet sich darin, dass es leider sehr unbekannt ist und in den Tiefen der Debian-Repositories schlummert und darauf wartet installiert zu werden.
Als Features nennt die Webseite:

• creating iso image from selected files
• writing data from hdd to CD/DVD
• writing iso image to CD/DVD
• verification of md5sum of ISO image written to CD (but not DVD)
• erasing CD-RW, DVD-RW (with reformatting: Restricted <--> Sequential) and DVD+RW discs
• ripping audio CDs to raw audio track files (user has to use external tools, e.g sox, to convert them to other formats)
• copying single-session (or first session of multi-session) data CDs to iso image on hdd
• updated man page
• wizard dialogs for writing data to disc and blanking disc
• simplified hardware configuration
• context help tooltips
• CD-AUDIO (ripping audio tracks only)
• CD-R, CD-RW
• DVD-R, DVD+R
• DVD-RW: Sequential Incremental and Restricted Overwrite
• DVD+RW

Ich wurde darauf aufmerksam gemacht, dass ich Newsbeuter für Debian Lenny gegen die in Lenny vorhandene stfl gelinkt hatte, was ein Fehler war. Newsbeuter setzt auf die neue stfl-Version auf, somit habe ich beides als Paket für Debian Lenny paketiert. Ich wunderte mich schon ein wenig über die Anzeige und das nicht alle HTML-Tags richtig geparsed wurden. Somit bedanke ich mich für den Hinweis und sage Entschuldigung für die Unanehmlichkeiten, aber es ist ja nichts zu Schaden gekommen, das hätte ich wohl als Erstes gemerkt ;)
Bitte die vorhandene libstfl-dev deinstallieren.
newsbeuter_2.0-deveth-1_i386.deb für Debian Lenny
stfl_0.19-deveth-1_i386.deb für Debian Lenny

Und nun noch ein paar Worte zu dem Thema warum ich kein Repository habe:
Es geht mir darum, dass der Nutzer dieser Pakete sich definitiv darüber im Klaren ist, dass er Fremdsoftware auf seinem stable-System installiert und sich somit damit auseinandersetzt. Ich könnte ein Repository für Debian stable bauen, ich könnte die Maintainerfiles bearbeiten und Automatismen einbauen bzw. vorhandene nutzen, ich könnte einen Dialog einbauen, welcher auf die Gefahren hinweist. Aber, ich baue normalerweise die Pakete für mich und möchte mir nicht die Mühe machen, sondern möchte die vorhandenen Stärken das Debian Systemes nutzen, anstelle ein Dreisatz zu bilden ( ./configure $OPTIONS && make -j && make install) und die Sourcen permanent auf dem Server, oder auf dem Laptop mitzuführen. Auch bitte ich zu beachten, dass diese Pakete nicht etwas mit den Maintainern der Software und auch nicht mit der Arbeit der Debian Maintainern zu tun hat, also nicht auf jene Einprügeln, wenn etwas nicht funktioniert, denn der Fehler kann auch an mir liegen. Da ich aber in dem Sinne keinen Support für die Pakete gebe und sie meines erachtens bei mir funktioniert haben, gebe ich jene raus wie sie sind. Ich hoffe nicht, dass dieser Text nun missverstanden wird, aber ich wollte dies nochmal erklären und bitte somit um den klugen Umgang mit den Debian GNU/Linux-System, seiner Software und vor allem mit Fremdsoftware. Danke Euch.

Da ist sie, die neue Version des RSS-Feedreaders Newsbeuter, der "mutt" unter den Feedreadern.
Ich nutze auf meinem Server zwar TT-RSS, aber wenn ich mit meinem Thinkpad unterwegs bin, brauche ich etwas, welches eher meinem Gusto von Schlank, Schnell und perfekt zu handeln entspricht. Das ist Newsbeuter. Wie immer habe ich ein Debian deb für mich gebaut, welches auch wie immer für Debian stable ( Lenny) gedacht ist. Installiert wird newsbeuter in /usr/local/bin/ und die Beispielkonfigurationsdatei befindet sich in /usr/local/share/doc/newsbeuter/examples/.
Debian Lenny: newsbeuter_2.0-deveth-1_i386.deb 594.4 KB md5sum f67c276a197cb174e603f355fc311bd0

Nun etwas für die Freunde des Windowmanagers ion:
Man kann sich die Anzahl der ungelesenen Nachrichten in der Statusbar anzeigen lassen.
Um dies zu erreichen lädt man als erstes die statusd_exec.lua herunter und speichert diese in dem Verzeichniss
/home/$USERNAME/.ion3/. Jene wird dann als statusd_rss.lua kopiert und einfach Alleine gelassen. Nun wird die Datei cfg_statusbar.lua bearbeitet. In dem Bereich mod_statusbar.launch_statusd fügen wir:ein.
Das retry_delay bezieht sich auf Sekunden, sprich wir warten 10 Minuten ( weniger würde ich definitiv nicht nehmen, sonst wird man von dem Webseitenbetreiber gesperrt, das kann vorkommen)bis der Stati von newsbeuter nochmals abgefragt wird.
Um das ganze dann in der Statusbar angezeigt zu bekommen muss noch in den Abschnitt Template:hinzugefügt werden.
Somit haben wir immer im Blick, ob es neues in unseren Feedreader gibt. Eine Herausforderung gibt es bei der ganzen Sache, wenn newsbeuter läuft bekommt man in der statusbar angezeigt, dass schon eine Instanz von Newsbeuter läuft mit der PID n :(


disclaimer: Wie immer baue ich die debs eigentlich für mich, sprich, wenn sie funktionieren lade ich sie hier unter Files hoch. Dieses Paket hat nichts mit der Arbeit der Debian-, oder der Newsbeuter-Maintainer zu tun und ist somit inoffiziell. Bitte keine Mails an aufgrund von Fehlern an die Beiden genannten senden.

Erm, ich kann es garnicht leidenden Opera aufzurufen, und per Web Nachrichten an identi.ca zu senden. Nach ein wenig suchen habe ich twidge gefunden, welches sich auch nett nach Unixmanier nutzen lässt, siehe auch die Tips&Tricks auf der twidge-Webseite.
Da ich nur in identi.ca poste und von identi.ca aus die Nachrichten an Twitter parsen lasse, hatte ich im ersten Moment ein kleines Problem mit twidge, denn bei dem Setup mit
wird das ganze nur für Twitter konfiguriert.
Nachdem man seine identi.ca-Daten eingegeben hat macht man etwas ganz einfaches, man fügt der ~/.twidgerc einfach ein urlbase: http://identi.ca/api hinzu, sodass die Konfigurationsdatei so aussieht:
Nun kann es auch schon losgehen.

Es gibt unter Files bei mir das Debian Lenny Paket twidge_0.99.3_i386.deb. Es ist von meiner Seite aus unangetastet und wurde vorbereitet von John Goerze von complete.org (dh_make; rules/control/etc.). Somit kann man ausser jenem wählen, ob man es selber bauen (twidge_0.99.3.tar.gz), oder das fertige Binary (twidge-0.99.3-linux-i386-bin.bz2) in das ~/bin-Verzeichniss einpflegen möchte. Beide sind unter Downloads auf der Twidge-Homepage zu finden. Achja, bevor ich es vergesse, identi.ca macht selbst aus langen URLs kurze...

Eigentlich hatte ich am heutigen tage vor Battle for wesnoth 1.6 für Debian Lenny zu kompilieren und als *.deb in meine Files zum herunterladen zu packen. Nachdem ich die Abhängigkeiten installiert hatte und gerade daran war mich dort hineinzuknien gab mit jemand den Tipp, dass es ja schon als deb vorhanden ist. Somit reiche ich einfach mal den Link weiter und wünsche viel Spaß.
IT-WESNOTH
ps: getestet habe ich das deb noch nicht, aber wer das macht, kann ja ein Kommentar über die Funkionstüchtigkeit hinterlassen.

Wenn an einem echten Multiprozessorsystem sitzend ein .deb gebaut wird bitte bei dpkg-buildpackage mit -j N die Anzahl der gleichzeitigen Aufträge erhöhen, wird dann direkt an die debian/rules für das make weitergegeben. Sonst hat das keinen Sinn mit den Multiprozessoren.
Somit habe ich dann mal wirklich Fix die neue Version meines Lieblingsdateimanagers als deb gebaut.

Date: Fri, 06 Mar 2009 15:27:28 +0100
From: Ralf Hoffmann
To: workerfm-users@lists.sourceforge.net
Subject: [Workerfm-users] new Worker version 2.17.2

Hi,

exactly ten years ago I have released the first public version of
Worker. I think it's a good idea to release another version at this
special date. The new version adds support for tabs in the directory
view. The tabs are not completely independent but share the same
directory cache. The sort settings, filters and so on are also shared.
There is also a new command to change the tabs if you don't like the
default key bindings (which are the same as in web browsers).

The new version is available at

http://www.boomerangsworld.de/cms/worker/downloads/worker-2.17.2.tar.bz2

Here is the complete change log:

new features:
All tabs share the same directory cache so if you select some entries
in a directory and you enter this directory in a different tab the
previous selection is available.
- added "modify tabs" command;
default keys are ctrl+page up/down for previous/next tab and ctrl+t/w
for new/close tab

other changes:
- improved layout configuration
- made checks for bookmarks and labels faster
- updated Czech and Slovak translation (Thanks to Petr Korviny and
Stanislav Pavlica)

Best Regards,

Ralf Hoffmann

--
Ralf Hoffmann
Homepage: http://www.boomerangsworld.de

Zu finden wie immer unter den Files.
worker_2.17.3-deveth-1_i386.deb

Da ich einen Squid als Proxy bei mir rennen habe, warum sollte ich apt-cacher nutzen, bei dem der Aufwand einfach zu viel ist. Wenn man bedenkt, dass die Clients doch apt-cacher als Proxy in apt nutzen sollen und ein Apache dafür auf die Firewall soll.
Somit habe ich meine squid.conf dahingehend geändert, dass nun squid die debs für einen bestimmten Zeitraum vorhält:

2. Bitte die deb-Pakete für einen Monat vorhalten
3. Packages.gz bitte nur für einen Tag vorhalten
4. Packages.bz2 bitte nur für einen Tag vorhalten
5. Die Objektgröße nach oben geschoben, da es Pakete gibt die größer als 1MB sind.
Das ist Alles, nicht mehr nicht weniger. Genauso kann man natürlich mit RPMs etc. verfahren.

dpkg-repack erzeugt eine .deb-Datei aus einem Paket, das bereits installiert wurde. Wenn Sie an dem Paket irgendwelche Änderungen vorgenommen haben, während es installiert war (z.B. wenn Dateien in /etc verändert wurden), dann übernimmt das neue Paket diese Änderungen.

Somit kann, wenn man mehrere Rechner zu deployen hat, das Paket einmal richtig konfigurieren und dann weiternutzen, ohne nochmals die Konfiguration vorzunehmen. Auch sehr schön für Backups...