staging.inyokaproject.org

Hi!

Hab es - mit ZeBobs Hilfe - noch geschafft, die Tracks gleich hierachisiert abzulegen. ☺

Hat Vor- und Nachteile; aber das kann ja jeder selbst ausprobieren. 🤓

Kann das ganze jetzt aus der Baustelle raus? Oder gibt's noch grundlegende Bedenken?

Allen schöne Ostereier

so long
hank

Hi!

So, jetzt ist der neue Patch eingearbeitet, auch die Hinweise zur 64-bit-Systemen, und die Möglichkeiten zum Selber-Patchen auch wieder komplett 8).

Ich denke, jetzt kann er tatsächlich, wirklich und überhaupt aus der Baustelle raus, wenn niemand noch gravierende Mängel feststellt... 😉

mtron war so fleißig, den neuen Patch gleich mit in die auf seiner Seite angebotenen Pakete und den vorbereiteten Quellcode zu integrieren, sodass dessen Änderungen und Verbesserungen auch ohne viel Bastelei genutzt werden könnten...

Viel Spaß beim rippen!
(aber immer schön für den privaten Gebrauch, sonst könnte es Ärger geben ❗ )

so long
hank

Danke 😀
Schaue mir den Artikel gleich in Ruhe an und gebe dir im Laufe des Tages Feedback ☺ Bei solch einer Auswahl von Programmen für Last.fm weiß ich schon gar nicht mehr was ich nutzen soll 😀

hallo hank!

um unsere mail kommunikation ein wenig fortzuführen: (ich poste es hier damit die Informationen nicht verloren gehen)

Bitte nimm die manuelle bearbeitung des Sourcecode aus dem wiki artikel raus. Das ist sehr unschön und macht einen unprofessionellen eindruck. Besser wäre es wenn auf der wiki seite fertige Patches für die aktuelle Vagalume Version angeboten werden, welche die gewünschte funktion hinzufügen. Ich finde es am besten den user selbst eintscheiden zu lassen, ob er die Dateinamenstruktur ändern will bzw. hirarchische Ordnerausgabe möchte.

Also: Bringe deine gewünschten Änderungen in jeweils ein unified diff (patch file). Ich kann dir gerne dabei helfen.

Der einfachste weg die Sache dann mit den custom patches zu builden: (als terminal log)

mkdir ~/vagaume
cd vagalume
wget http://mtrons.googlepages.com/vagalume_0.5.1-src.tar.gz
tar -xzvf vagalume_0.5.1-src.tar.gz
dpkg-source -x vagalume_*.dsc
cd vagalume-0.5.1/debian/patches

soweit ist jetzt alles ganz normal. Falls du die von dir gewünschten funktionen in einem (oder mehreren) patch hast, kannst du diesen patch mir zuschicken und ich nehme ihn auf.

Angenommen dein patch heisst 02_folderstructure.patch, diesen kopierst du jetzt nach ~/vagalume/vagalume-0.5.1/debian/patches

ein ls in diesem folder bringt dann:

mtron@mtron-desktop:~/vagalume/vagalume-0.5.1/debian/patches$ ls
01_save-song_v2.patch
02_folderstructure.patch

so kannst du natürlich mit allen patches verfahren die du haben willst. Wenn ein patch nicht verwendet werden soll, entweder einfach aus dem folder löschen, oder die .patch Endung zu z.B. diff ändern. Dann wird der patch nicht angewandt.

Zum build selber dann:

cd ~/vagalume/vagalume-0.5.1/

entweder nur die binary bauen:

fakeroot debian/rules binary

oder voller build:

dpkg-buildpackage -rfakeroot -us -uc -sa

in beiden fällen sollte dann mindestens die datei vagalume_0.5.1-1gutsy4_i386.deb (binary package) erstellt werden, mit den gewünschten patches. Ich hoffe Robert hat das 64-bit problem jetzt gelöst. Schon sehr gespannt ob's jetzt kompiliert und funktioniert. Falls jemand ein funktionstüchtiges vagalume 64bit + save-song.patch gebaut hat, bitte hier posten (das gilt auch für andere releases 😉 e.g. ein Hardy package wäre auch sehr nett. )

Hi!

mtron hat geschrieben:

Bitte nimm die manuelle bearbeitung des Sourcecode aus dem wiki artikel raus. Das ist sehr unschön und macht einen unprofessionellen eindruck. Besser wäre es wenn auf der wiki seite fertige Patches für die aktuelle Vagalume Version angeboten werden, die jeder beim build selbst hinzufügen kann.

Naja, liegt wohl daran, dass ich kein Profi bin... 😉
mtron hat geschrieben:

Also: Bringe deine gewünschten Änderungen in ein unified diff (patch file). Ich kann dir gerne dabei helfen.

Sehr gerne; nur dazu müsstest du mir wirklich helfen ☺ . Für die Version mit den Separatoren ist wohl kein eigener patch nötig; dazu kann ja auch der jetzige patch ohne großen Aufwand verändert werden.
Die Veränderung für die Ordnerstruktur allein ist auch nicht so gravierend; es sind ja gerade mal die paar Zeilen, die geändert werden müssten.
Allerdings wär es mühsam, das ganze per Hand zu schreiben. Wenn du mir sagst, wie ich die beiden Datein vergleiche und daraus automatisch einen patch baue - kein Problem 😉
(sonst schon...)
Die Konfusion um den Verzeichnisnamen (vagalume-0.5.1 vs vagalume -0.5.1-1) wäre nach deiner Anleitung auch aufgelöst?

Ich hoffe Robert hat das 64-bit problem jetzt gelöst. Schon sehr gespannt ob's jetzt kompiliert und funktioniert. Falls jemand ein funktionstüchtiges vagalume 64bit + save-song.patch gebaut hat, bitte hier posten (das gilt auch für andere releases 😉 e.g. ein Hardy package wäre auch sehr nett. )

Es scheint so; jedenfalls haben webster und johnnyff hier schon Erfolge gemeldet; es scheint zu klappen ☺

Für Last-Exit wär' das vorgehen mit der neuen Version (patche, erstellen etc) ähnlich? Wär nett, wenn du da auch nochmal draufschauen könntest! ☺

so long
hank

Soweit sieht es sehr gut aus - warte noch eure Änderungen ab ☺

hallo hank!

Das mit dem unprofessionell von davor war auf alle fälle nicht böse gemeint. Herzlichen Dank für deine ganze Arbeit und Hingabe zum Thema!

Wie du siehst habe ich deine änderungen in patches gegossen und in das source paket vagalume_0.5.1-src.tar.gz eingefügt.

neben den bereits bekannten debian/patches Verzeichnis (in dem der save-song patch ist) gibt es jetzt auch noch ein debian/contrib verzeichniss mit den anderen beiden patches. Falls man diese verwenden will muss man sie nur ins andere verzeichnis zum save-song patch legen und das wars. Sie werden automatisch beim build mit fakeroot angewendet.

siehe auch das vagalume_patchhowto.txt

mkdir ~/vagaume
cd ~/vagalume
wget http://mtrons.googlepages.com/vagalume_0.5.1-src.tar.gz
tar -xzvf vagalume_0.5.1-src.tar.gz
dpkg-source -x vagalume_*.dsc

cd vagalume-0.5.1
fakeroot debian/rules binary
cd ..
sudo dpkg -i vagalume_*.deb

ein binary paket für gutsy mit allen 3 patches: http://mtrons.googlepages.com/vagalume_0.5.1-1gutsy5~allpatch_i386.deb

zum thema wie erstellt man patches ist hier ein sehr gutes howto (für's nächste mal 😉 ). in dem howto geht's genaugesagt um perl patches, ist aber vom prinzip her total dasselbe ob der patck für perl, C oder C++ sourcecode ist.

Erstellen tut man patches sehr einfach

du brauchst 2 kopien des Sourcecode
- Orginaler_Sourcecode
- bearbeiteter_Sourcecode

den unterschied zwischen den beiden ermittelt man dann mit

diff -up path/to/Originaler_Sourcecode path/to/bearbeiteter_Sourcecode

gibt es mittlerweile schon jemand der probiert hat die neue Version auf 64bit zu bauen?

lg mtron

Hi mtron!

Nein, nein keine Angst, ich nehm' dir da nichts übel. ☺

Und es schien ja auch nicht so schwierig zu gewesen sein, die patches zusammenzubauen, deine Erklärung hab' ich sofort verstanden; werd's für Last-Exit auch mal versuchen...
Für mich ist's aber auch so ein bisschen "selbst was erreichen", und sei's "nur", ne Datei per Hand zu verändern, dabei rauszufinden, wie's funktioniert, und einzubauen, was ich haben will - "Learning by doing"; und nicht einfach ein fertiges Ding aufzuspielen, und gut is...

Wie du siehst habe ich deine änderungen in patches gegossen und in das source paket vagalume_0.5.1-src.tar.gz eingefügt.

Bei deinem tar.gz sehe ich z.B. erst mal nicht, was darin steckt; und ob ich da selbst noch was verändern könnte; daher meine Nachfrage an dich, was ich denn damit machen soll...
"Hilfe zur Selbsthilfe", bin halt Pädagoge... 😉

Aber das mit deinen fertigen Patchen werd' ich auf alle Fälle mit aufnehmen; (...alle drei zusammen gibt dann im Zweifelsfall das Ergebnis /Pfad/zum/Zielverzeichnis/Joe Claussell/Rare Elements - Ustad Sultan Khan - Remixes/Joe Claussell ;;; Rare Elements - Ustad Sultan Khan - Remixes ;;; Aja Mahi (Sacred Rhythm Version).mp3 😉... ; das Howto kann ich ja auf alle Fälle mit verlinken, und bei Problemen darauf verweisen.

Das mit dem contrib-Verzeichnis find' ich gut; das finde ich aber auch erst, wenn ich dein Paket weiterverarbeitet hab (und wie mache ich das? siehe oben...), und dann das README lesen kann. Schön wär's ja, wenn jeder, der sowas entwickelt, es für andere begreifbar machen könnte. Insofern find ich meine Patchanleitungen auch nicht so daneben; der interessierte Laie (wie ich) kann daran vielleicht etwas darüber ableiten, wie denn z.B. der Dateiname zustande kommt, wo die temp-datei abgelegt wird etc,pp., - und dann den Schritt weiter gehen, selbst was zu entwickeln oder den patch dazu zu bauen - vielleicht ja auch so weit, und das id3-tagging-problem angehen 😉

Ich werd' mich weiter damit beschäftigen.

Danke für Deine Unterstützung! (btw: hatte zebob dir den Patch eigentlich auch geschickt? ☺ )

gibt es mittlerweile schon jemand der probiert hat die neue Version auf 64bit zu bauen?

Naja, wie gesagt, guckst du hier und fragst mal webster und johnyff....

so long
hank

hank hat geschrieben:

Bei deinem tar.gz sehe ich z.B. erst mal nicht, was darin steckt; und ob ich da selbst noch was verändern könnte;

die drei dateien aus vagalume_0.5.1-src.tar.gz sind folgendes:

vagalume_0.5.1.orig.tar.gz → bertos originale vagalume version
vagalume_0.5.1-1gutsy5.diff.gz → alle änderungen als komprimiertes diff (oder patch)
vagalume_0.5.1-1gutsy5.dsc → ein control file

mit dem command

dpkg-source -x vagalume_*.dsc

wird das original vagalume entpackt und der patch angewendet. Es wird das neue Verzeichnis vagalume-0.5.1 erstellt in dem du jetzt alles nach herzenslust ändern kannst (patches zwischen dem debian/contrib und debian/patches verzeichnis hin und hersschieben, ect)

Dann gibst du noch zum build das bekannte

fakeroot debian/rules binary

ein und das paket ist erstellt.

hank hat geschrieben:

...alle drei zusammen gibt dann im Zweifelsfall das Ergebnis...

jup, drum halte ich die patches auch optional 😉

hank hat geschrieben:

Insofern find ich meine Patchanleitungen auch nicht so daneben; der interessierte Laie (wie ich) kann daran vielleicht etwas darüber ableiten, wie denn z.B. der Dateiname zustande kommt, wo die temp-datei abgelegt wird etc,pp

wenn du dich ausführlich mit der debian Paketerstellung beschäftigen möchtest empfehle ich das studium der Ubuntu packaging guide
. Dort wird die Materie sehr breit erklärt und anhand von beispielen gut erläutert. Viel besser als ich es je könnte 😉

Danke bez. dem 64-bit hinweis. ich hoffe einer der beiden schickt mir die 64-bit binary ☺

Hi mtron!

Danke dir noch mal für die Hinweise; so verstehe ich zumindest, was die Komandos bedeuten; muss ich wahrscheinlich wirklich noch mehr zu lesen, um genauer dahinterzusteigen.

Mit dem "allpatch"-Paket war's aber wohl nichts 😉 ; Wenn ich die selben Zeilen in der selben Datei durch drei Patche verändere, bleibt zum Schluss nur die letzte Veränderung an den Zeilen über; mit Glück funktionieren sie dann mit den anderen Änderungen noch... Um das Monstrum von Pfad/Dateinamen von oben hinzukriegen, müssten wohl zu unterschiedliche Strukturen erstellt und kombiniert werden, und das ginge so nur "per hand", oder einzeln angewandten Patches...

Naja, für heute lass' ich es mal;

so long
hank

Hi!

So, (zum wievielten Male eigentlich 😉 ), im meld mich mal wieder als "fertig"

Hinweise auf 64-bit-Pakete sind eingebaut; die "unschönen" Patchanweisungen dank mtrons Hilfe auch rausgeräumt; jetzt dürfte dem Rippen nichts mehr im Wege stehen!
Theoretisch könnte auch "gestest für hardy" mit rein; aber das weiß ich nur von anderen, probiert hab' ich es selber nicht.

so long
hank

Hi!

Ja ja, ich mach' mich langsam lächerlich 😉

Habe aber gerade noch etwas gebastelt und vagalume jetzt beigebracht, vor Abspeichern der Dateien zu überprüfen, ob im Zielverzeichnis schon eine Datei mit dem vorgesehenen Namen existiert und eine solche nicht zu überschreiben, sondern die Datei dann schlicht zu verwerfen. Das ist ganz sinnvoll, wenn die Dateien schon "vertaggt" worden sind, außerdem gab's zumindest bei mir hin und wieder den Fall, dass überschriebene Dateien einfach leer waren (entweder zwar normal groß und lang, aber ohne Ton, oder auch nur noch aus dem Namen bestanden).

Wenn ich jetzt noch "meine" per-Hand-Patchanleitung" im Wiki stehen hätte, wärs ganz einfach, das da mit anzugeben; jetzt müssten wir erstmal wieder neue patches bauen 😉

Das Prinzip ist relativ einfach: In controller.c müssen folgende Zeilen eingbaut werden (die erste Zeile ist nur zur Orientierung, wo das ganze hingehört):

savedfile = g_strconcat (savedir, filename, NULL);
		if (g_file_test (savedfile, G_FILE_TEST_EXISTS) == FALSE) {
			char command = g_strdup_printf ("cp \"%s\" \"%s\"", tmp_fname, savedfile);
		        system (command);
			g_free (command);
		} else g_print (" File already exists: %s", savedfile);	

die Bezüge zu command, die bisher kurz vorher und nacher in den aufgelisteten Teilen (char und g_free) vorkommen. müssen entfern werden.
Damit wird bei schon existierender Datei bei Betrieb im Terminal eine Meldung ausgegeben: File already exits: "name.mp3" bzw "/Pfad/zum/Namen/Name.mp3" (je nach dem, welcher patch benutzt wird 😉) und die alte Datei bleibt erhalten

Ich hänge mal meine Version von controller.c an; meine Version legt die Temporärdatei im Zielverzeichnis ab und erstellt die hierarchisierten Ordner; wenn mtron Zeit und Lust hat, kann er das vielleicht mit in das patches-Archiv aufnehmen... 😠 . Wer meine Version so benutzen will, kann einfach die momentane controller.c-Datei durch meine ersetzen, und dann nach Anweisung im Wiki neu kompilieren - kein großer Aufwand...
Ich hab's jetzt noch nicht einen Patch gegossen; weiß noch nicht, wann ich dazu komme (wäre halt das erste mal...) Es funktioniert auch für die anderen Versionen; ich habe Robert-André Mauchin gebeten, es in seinen Ursprungs-Patch auch mit aufzunehmen, weil ich es für eine echte Verbesserung halte, die auch grundsätzlich mit in den patch könnte. Ich hoffe, er meldet sich demnächst zurück, und dann können wir das auch noch abklären...
Das ganze funktioniert übrigens genauso für Last-Exit (in player.c), da die Patches in dem Teil gleich aufgebaut sind.

also, mtron, wie halten wirs?

so long
hank

wie gesagt: du schickst mir patches im diff format (wie man die erstellt haben wir oben besprochen), und ich schau dann was ich daraus machen kann ☺

diff
While individual tastes vary (and are not the point here) patches should be created using either -u or -c arguments to diff. These produce, respectively, unified diffs (where the changed line appears immediately next to the original) and context diffs (where several lines surrounding the changes are included). See the manpage for diff for more details.

The preferred method for creating a unified diff suitable for feeding to the patch program is:

diff -up old-file new-file > patch-file

Aber grundsätzlich eine sehr gute idee 8) weiter so! Ich schau es mir morgen an.

noch eine kleinigkeit zum wiki artikel:

Patchen

Die Ausagebeformate für das Zielvezeichnis lassen sich zur einfacheren Weiterverarbeitung mit Hilfe von Patches verändern. Dazu muss das Paket aus diesem dazu angpassten Quellcode erstellt werden, in dem verschiedenen Patches bereits integriert sind. Im Downloadverzeichnis mit

Bitte aus muss kann machen. Alle patches können natürlich auch ohne weiteres manuell auf bertos originale sourcen applied werden. Der sourcecode selbst ist in vagalume_0.5.1-src.tar.gz nicht angepasst, sondern das was ich hier bereits gepostet habe.

Das ist Packaging Standard. Alle Änderungen vom Original werden extern (in patches) gespeichert. Darum gibt's auch das vagalume_0.5.1-1gutsy5.diff.gz im download archiv. Änderungen am Sourcecode selber solltest du mit dem Entwickler kären 😉

Heinrich Schwietering hat geschrieben:

Ja ja, ich mach' mich langsam lächerlich 😉

Nönö ☺ Ich warte nur ein paar Tage ab ob nun wirklich nichts mehr kommt - man weiß ja nie 😉

Hi!
mtron hat geschrieben:

Aber grundsätzlich eine sehr gute idee 8) weiter so! Ich schau es mir morgen an.

Danke ☺! (bin auch ein bisschen stolz auf mich 😳 ...)

Eine Sache ist mir noch unklar: Ich möchte den filecheck.patch als erstes bauen, und so, dass die anderen auf ihn aufbauen. Das heißt doch, dass ich zunächst einen mit dem save-song_v2.patch bearbeiteten Sourcecode brauche. Aus dem baue ich dann den Patch für die filecheck-Geschichte.
Wenn der fertig ist, nehme ich diesen Sourcecode, um daraus die anderen beiden patches abzuleiten - sie sollen sich ja auf die mit filecheck gepatchte Version beziehen.
Stimmt meine Logik?
Und eigentlich müsste es doch auch reichen, dann jeweils nur "diff-ups" aus der betroffenen Datei zu machen, oder wird das dann mit dem Anwenden nix?

Na, ich probiers einfach mal aus... 😉

so long
hank