monitord RPMs für openSUSE

[cwh]

Hi,

ich hab hier zumindest mal funktionierende RPMs für openSUSE 10.3, 11.0, 11.1 und Factory
http://download.opensuse.org/repositories/home:/cwh/
Für weitere RPM-basierte Distributionen zu bauen dürfte nicht allzu schwierig sein. Bei deb-basierten kann ich erstmal nicht weiterhelfen.

Wenngleich auch noch einiger Verbesserungsbedarf besteht. In meinen Augen wäre das:
- jthread als extrapaket aus den Sourcen rausziehen
- die beiden Plugins in extra Pakete verpacken
- Beispielconfig miteinpacken
- rc-script um monitord automatisch starten zu können

Lamesupport habe ich nicht aktiviert, da es rechtliche Probleme geben wird. Eine Lameunterstützendes Recorderplugin könnte ich evtl. lokal bauen und auf eigenem Webspace zur Verfügung stellen.

Überlegenswert wäre es evtl. Ogg/Vorbis-Support einzubauen, der keine Patentprobleme mit sich bringen würde oder Komprimierungen durch externe Programme machen zu lassen.

Desweiteren noch dieser kleine Hinweis
http://bts.monitord.de/index.php?do=details&task_id=34&project=2

Christopher

[jhr-online]

Wenn es jemand schaffen könnte, die proprietären Abhängigkeiten zu entfernen, würd ich Debian-Pakete bauen, aber so macht es keinen Spaß... :-P

jhr

[cwh]

Welche proprietären Abhängigkeiten? Einzig Lame ist problematisch.
Noch irgendwas?

Christopher

[Buebchen]

Hab mir mal OGG/Vorbis angeschaut. So "mal eben" habe ich den encoding Prozeß nicht verstanden. Muss ich mir nochmal ansehen, wie das genau geht. Ich denke dafür baue ich ein eigenes Plugin für sobald ich es begriffen habe. Im Gegensatz zu lame wird hier mit float werten gearbeitet.

Zumindest mal konnte ich es unter mingw (win32) bauen und configure um nen rudimentären check auf libvorbisenc erweitern :)

[jhr-online]

Hab mir mal OGG/Vorbis angeschaut. So "mal eben" habe ich den encoding Prozeß nicht verstanden. Muss ich mir nochmal ansehen, wie das genau geht. Ich denke dafür baue ich ein eigenes Plugin für sobald ich es begriffen habe. Im Gegensatz zu lame wird hier mit float werten gearbeitet.

Zumindest mal konnte ich es unter mingw (win32) bauen und configure um nen rudimentären check auf libvorbisenc erweitern :)

Zur Info: ich habe so ziemlich mein ganzes Interesse in dieses Projekt verloren, aber wenn wir die Abhängigkeit von proprietären libs loswerden, könnte ich mir vorstellen, als Debian Maintainer noch mal ein bisschen aktiv zu werden. :)

[Buebchen]

Aufgrund der lizenzrechtlichen Problematik mit dem mp3 Codec möchte ich gerne auf ogg/vorbis erweitern. Ob ich später lame komplett entferne muss man dann nochmal überlegen.

Das Projekt hat jetzt recht lange geruht. Kein Wunder, daß viele eine andere Lösung nutzen. Inzwischen habe ich ein wenig mehr Zeit und werde einfach mal die Dinge an/einbauen die mir sinnvoll erscheinen.

[jhr-online]

Aufgrund der lizenzrechtlichen Problematik mit dem mp3 Codec möchte ich gerne auf ogg/vorbis erweitern. Ob ich später lame komplett entferne muss man dann nochmal überlegen.
Ich würd mich drüber freuen...

Das Projekt hat jetzt recht lange geruht. Kein Wunder, daß viele eine andere Lösung nutzen. Inzwischen habe ich ein wenig mehr Zeit und werde einfach mal die Dinge an/einbauen die mir sinnvoll erscheinen.
Ich glaube, dass wohl noch einige dran hängen. Es scheint auch bei Weitem die beste Lösung für Linux zu sein, nicht zuletzt, weil es ja "neuerdings" als daemon läuft. :)
Mein Problem ist, dass ich umgezogen bin und keinen aktiven Kontakt zur Feuerwehr mehr habe.

[cwh]

Hallo allerseits.

Ich bin ja grade dran mich intensiver mit monitord auseinanderzusetzen. Nen funktionstüchtigen Client zur SMS und Emailalarmierung hab ich schon erfolgreich laufen. Ich werd demnächst hier mal mehr dazu schreiben, wenn ich meine Passwörter aus den Sourcen draußen hab. ;)

Jedenfalls hab ich mir natürlich auch schon angeguckt, wie man die lame abhängigkeit rausbekommen könnte. Meines erachtens wäre es am sinnvollsten, dazu eine der einschlägigen Audiolibs zu verwenden anstatt immer einen codec direkt reinzustricken.

Zuerst dachte ich an libsndfile - http://www.mega-nerd.com/libsndfile/ - die nur leider alles kann, außer mp3. Vorteil wäre, sie ist hölleneinfach einzubauen.

Viel mehr Audioformate kann die altbekannte libsox - http://sox.sourceforge.net/. Auch dafür gibts codebeispiele, daher müßte sich das auch machen lassen die reinzubekommen. Damit könnte man eigentlich alle möglichen und unmöglichen Dateiformate schreiben.

Ich hab mal bissl probiert und was Kompression von Funksprüchen betrifft stehen mp3 und ogg/vorbis Welten hinter Verfahren wie amr oder gsm, die ja auf Sprachkompression ausgelegt sind.

Hier ein Beispiel:
2,2M alarm.raw
395K alarm-a-law.wav
395K alarm-u-law.wav
203K alarm-ms-adpcm.wav
149K alarm.mp3
141K alarm.ogg
81K alarm-gsm.wav
23K alarm-wb.amr
19K alarm-nb.amr

Alle Dateien enthalten denselben Mitschnitt. mp3 und ogg sind jeweils in schlechtester Qualität, d.h. bestmöglicher Kompression verpackt. Alle Ergebnisse sind bestens verständlich und haben kaum nennenswerte Qualitätsunterschiede.

All diese Formate kann sox, daher sollte das wohl die beste Wahl sein.

Grüße,
Christopher

[Buebchen]

SoX selbst (bzw. libsox) läßt sich ja relativ leicht integrieren. Der Haken ist da eher, daß ich unter windows mit msys/mingw Probleme habe z.B. dem mp3 lame Support zu kompilieren (bzw. zu linken).

Der typische Ärger - vermutlich weil ich einfach für sowas zu dämlich bin - mit libtool. Der erklärt mit ständige, daß er keine geeignete libmp3lame finden würde. Naja. Könnte auch mal wieder im file magic liegen, daß er das nicht erkennt. Nen eingebauten codec kann ich immerhin schon nutzen. Mal sehen, ob das ganze dann auch demnächst mal unter linux baut. Da ist die libsox im Normalfall sowieso schon drauf. Und wenn nicht erheblich einfacher zu erstellen.

[cwh]

Du bist also grade dabei Dir das anzugucken?

Von bauen unter Windows hab ich leider keine Ahnung. Unter den gängigen Linuxdistributionen gibts sox einfach. Für openSUSE mit gibt sie es bei Packman mit mp3-Support. Damit bekomm ich dann auch ordentliche monitord Pakete für openSUSE hin - und jhr dann debs. ;)

Dann könnt ich auch ziemlich problemlos openSUSE Liveimages/-isos machen.

Grüße.
Christopher

[Buebchen]

Naja. Ich hab das soweit auch schon hardwired am Laufen. Also die libsox unter windows. Das Problem ist halt, daß ich bisher nur die mitgeliefertern Codecs nutzen kann, weil ich die anderen nicht compiliert bekommen (bzw. der linker muckt am Ende wenn er die libsox.dll gegen die libmp3lame.dll binden soll).

Ich werd's wohl erstmal auf linux weitermachen müssen. Und wenn alle Stricke reissen bleibt eben der mp3 Support unter windows auf lame beschränkt. Unter linux entweder über lame oder sox. Zwar doof. Aber ist dann halt so.

Ggf. versuche ich die DLL unter Windows mal nicht mit dem gcc sondern dem Visual C++ Compiler zu erstellen. Ich denke, da habe ich erstmal mehr glück. Nur muss ich den erstmal installieren ...

[cwh]

Moin.

Um mal wieder was zum eigentlichen Thema, nämlich RPMs für openSUSE zu
schreiben ... ;)

Es gibt neue Pakete an der obigen Adresse.

Ich hab die Plugins audiorecorder und mysql in extra subpakete rausgezogen um Abhängigkeiten zu minimieren.

SoX-Support hab ich noch nicht enabled, weil der ja noch nicht so
ganz fertig zu sein scheint.

Desweiteren gibts ein rc-script zum automatischen starten von monitord
beim booten.

Um ein ordentliches RPM zu machen braucht man einen ordentlichen Source
tarball. Den bekommt man am besten mit 'make dist'. In Falle monitord haben
aber leider nach make dist alle headerfiles gefehlt. Deswegen habe ich die mal
ins Makefile.am in EXTRA_DIST ebenso dazugepackt wie die sample-config.

Leider gibts mit der eingecheckten Version configure.ac und der aktuellsten
Autoconfversion probleme - die hab ich gefixt und hätte da einen patch parat.

Nach Durchlaufen der autotools gibts leider früher oder später bei 'svn up'
konflikte in den autogenerierten Files. Daher is es eigentlich ziemlich
unpraktisch, eben diese mit einzuchecken. Daher würde ich empfehlen:
*.m4
*.in
config.*
configure
depcomp
install-sh
ltmain.sh
missing
mkinstalldirs
aus dem SVN zu löschen.

Um dafür den ganzen aclocal, autoconf, automake, libtoolize Schlonz deutlich
abzukürzen würde ich das berühmte autogen.sh (http://buildconf.brlcad.org/)
verwenden und mit einchecken. Damit ist nach einem Aufruf alles da, was man
zum bauen braucht.

Bübchen: Soll ich die das alles mal schicken oder bekomm ich SVN-Zugang um das
selber einzuchecken. ;)

Grüße aus Franken,
Christopher

[Buebchen]

den ganzen configure kram mache ich sowieso nicht gerne. Die Doku ist alles anderen als wirklich hilfreich. Zumindest für mich. Wobei das sicherlich auch daran liegt, daß ich das ganze auch noch unter msys laufen lasse. Da kann man sich nicht mal eben die aktuellen Versionen aus dem Repository laden :(

Nen patch kannst Du mir gerne schicken. Zugriff auf's svn kann ich keinen geben, da ich nicht der admin bin. Autogen.sh schaue ich mir mal an.

Grundsätzlich möchte ich eigentlich schon das ganze so halten, daß es sowohl unter linux, als auch unter windows übersetzt werden kann ohne erst das ganze System von Hand updaten zu müssen. Und bei win32 kann man eigentlich nur die verfügbare msys Version als Maßstab nehmen. Die ist leider z.T. wirklich seeehr alt.

Aber ist spät und ich geh jetzt erstmal ins Bett - Morgen schaue ich mir das erstmal an :)

[jhr-online]

Bübchen: Soll ich die das alles mal schicken oder bekomm ich SVN-Zugang um das
selber einzuchecken. ;)

Wenn niemand "Einwand" schreit, kann ich dir Zugriff auf's Repository geben. Schick mir eine PN mit gewünschtem Benutzernamen und Passwort, dann wird das erledigt.

jhr

[Buebchen]

Ich schrei höchsten "Zustimmung" :)

[cwh]

Ich fühle mich geehrt. ;)

Bei der Gelegenheit merke auch noch mal an, dass die zum guten Ton gehörenden Files: AUTHORS, ChangeLog, COPYING, INSTALL, NEWS und README noch fehlen.

Wer sind denn eigentlich die Autoren? Ihr seid ein bissl zu bescheiden, so wenig Ihr Euch in euerem Code verewigt. ;)

ChangeLog wäre mal wichtig - allerdings sollte man vielleicht auch öfter mal Releases machen.

Lizenz hab ich nur GPL in win32-nsis/license.txt gefunden. Ich gehe davon aus, daß das fürs ganze Projekt gilt?

In INSTALL könnte man teile des Endlosthreads ganz oben im hiesigen Forum packen.

In NEWS und README wüßte ich grade auch nicht, was man schreiben sollte.

Kommentare? Meinungen?

Christopher

[Buebchen]

Da das ganze ja noch keinen Release-Status erreicht hat (bestenfalls Milestones) fehlen natürlich so Dinge wie Changelog, Readme, Install usw.

Ich für meinen Teil, bin ja froh, daß es überhaupt so weit läuft :)

Für den ersten Release müßten wir mal die Features einfrieren. Was wiederum dazu führt, daß man sich ans Finetuning/Bugfixing machen muss. Das ist natürlich etwas, was kein Entwickler so richtig gerne macht - zumindest keiner von denen die ich kenne ^^

Als Autor sollten wir mal alle zusammentragen, die Code zum monitord beigetragen haben. Ebenso sollten irgendwo die erwähnt werden, die in anderer Form mitgewirkt haben. Z.B. die Entwicklung des Kommunikationsprotokolls. Oder auch einfach das hosting von monitord.de.

Zur Lizenz:
unixmon und damit monitor sind gpl'ed. Damit auch der größte Teil des monitords. Alles was nicht automatisch gpl'ed ist habe ich soweit ich dran gedacht habe auch unter die GPL gestellt. Wobei ich gerade nicht die Details kenne, ob man z.B. alte und neue Komponenten unter die GPL v3 stellen kann oder ein Misch-Masch als v2 und v3 genannt werden muss.

News: Würde ich im Moment leer lassen - oder Verweis auf die Homepage
Readme: Naja. Könnte man mal versuchen den monitord als ganzen zu Beschreiben - Nichts, was ich jetzt so richtig gerne machen würde ^^

INSTALL:
Müßte man wohl linux und win32 trennen. Z.T. gibt's da feine Unterschiede.

Aber erstmal was bauen, was hält. Bisher hab ich's noch nicht geschafft die Patches einzuspielen .. Will doch eigentlich sehen, wie MSYS da so drauf reagiert ...

[dekarl]

Hallo,


Zur Lizenz:
unixmon und damit monitor sind gpl'ed. Damit auch der größte Teil des monitords. Alles was nicht automatisch gpl'ed ist habe ich soweit ich dran gedacht habe auch unter die GPL gestellt. Wobei ich gerade nicht die Details kenne, ob man z.B. alte und neue Komponenten unter die GPL v3 stellen kann oder ein Misch-Masch als v2 und v3 genannt werden muss.

Oh je, die GPL v3 ist doch so lang... Mir persönlich wäre eine nicht virale Lizenz lieber, im Stil vom Apache / Eclipse / BSD Lizenz. Mit der GPL v2 hatte ich mich mittlerweile als vorgegeben abgefunden auch wenn diese mir zu restriktiv erscheint.

Wieviel Code vom monitor 1.8 bzw. unixmon ist denn überhaupt noch vorhanden?
Wenn ich es recht verstanden habe ist doch der 2er Monitor bis auf die Decoder fast komplett von Dir neu geschrieben worden?
mdi hat den ZVEI Decoder neu geschrieben und Du hast einen neuen Pocsag decoder geschrieben.
Bleibt noch der FMS Decoder der vom alten monitor bzw. neu vom rtty kommt. Beim rtty konnte ich auf die schnelle keine Lizenz finden.

Ich sehe aktuell folgende Optionen:
a) die historisch gegebene GPL v2 einfach beibehalten
b) Code sichten ob wir noch GPL Code von dritten (also nicht buebchen, mdi, mir, etc) mitschleppen
b1) falls nicht steht uns die Lizenzwahl komplett frei
b2) falls noch wenig GPL v2 Code enthalten ist muß geprüft werden ob der zu ersetzen ist, falls wir von der GPL abweichen wollen

Ein Vorteil von LGPL/APL/EPL/BSDL ist die Möglichkeit den monitord in ein GUI Frontend mit einzubinden (also in eine gemeinsame Programmdatei) obwohl das Frontend selbst nicht Open Source ist.

Bleibt nur die Frage was wir wollen :-)

[Buebchen]

Wie man nun "weg" von der GPL kommt, da kenn ich mich nicht wirklich gut aus. Meine Sachen kann ich ja ab sofort unter einer anderen Lizenz veröffentlichen. Was die Originalteile angeht sie sollte einiges aus dem Bereich der Bitverarbeitung bei POCSAG und FMS noch aus dem Original stammen. Also das, was nach dem eigentlichen Dekoder kommt.

Wenn man den monitord per Socket anspricht dann ist aber doch das verbundene Frontend in der Lizenzwahl frei, oder habe ich da was falsch verstanden ?

Ansonsten kann man für das aktuelle build die GPLv2 erstmal vorsehen. Bis wir dann allen GPL Code durch eigenen ersetzt haben und dann über die neue Lizenzform entscheiden.

Ich habe da keine besondere Präferenz und richte mich nach der Mehrheit (die sicherlich auch mehr Ahnung davon hat als ich).

[dekarl]

Meine Sachen kann ich ja ab sofort unter einer anderen Lizenz veröffentlichen.

Jawoll, bedeutet nur das sich alle die neuen Code geschrieben haben einig und einverstanden sein müssen. Sonst hat man wieder einen Lizenzflickenteppisch.


Wenn man den monitord per Socket anspricht dann ist aber doch das verbundene Frontend in der Lizenzwahl frei, oder habe ich da was falsch verstanden ?

Richtig so, der Knackpunkt ist das man GPL Code mit quasi nichts anderem statisch Linken kann. Gerade das statische Linken fände ich aber für ein Windows Release mit Audiokompression etc. garnicht verkehrt.


Ansonsten kann man für das aktuelle build die GPLv2 erstmal vorsehen. Bis wir dann allen GPL Code durch eigenen ersetzt haben und dann über die neue Lizenzform entscheiden.

Das sehe ich auch als die pragmatische Lösung für das Erste Release. Wir müssen nur darauf achten das wir keine statischen Binaries rausgeben.


Ich habe da keine besondere Präferenz und richte mich nach der Mehrheit (die sicherlich auch mehr Ahnung davon hat als ich).

Ich bin noch ein wenig unentschlossen, tendiere aber in Richtung Minimallizenz...
1) behaupte nicht Du hättest es geschrieben wenn Du den Quellcode weitergibts
2) evtl noch behaupte nicht Du hättest es geschrieben wenn Du ein ausführbares Programm weitergibts

Da bietet sich quasi eine Bierware Lizenz an ;)