Stephan Gwinner schrieb:
Helmut Scholl schrieb:
Hi Leute, ich möchte wichtige Telefonate die über die ISDN kommen mitschneiden, um sie zu einem späteren Zeitpunkt noch einmal in Ruhe abhören zu können. Ich stelle mir so eine Art Voice-Recorder vor der am S0 Bus aufzeichnet. System SuSE 8.2, AVM Fritz!Card V2.0.
Hi mal abgesehen davon, dass das Mitschneiden verboten ist musst du wohl auch wenn überhaupt das Gespräch auf dem PC engegen nehmen damit es überhaupt klappen kann weil der B kanal ja P2P ist.
Mfg Stephan
On Sunday 10 August 2003 12:56, Stephan Gwinner wrote:
Stephan Gwinner schrieb:
Helmut Scholl schrieb: [...]
ich möchte wichtige Telefonate die über die ISDN kommen mitschneiden, um sie zu einem späteren Zeitpunkt noch einmal in Ruhe abhören zu können. Ich stelle mir so eine Art Voice-Recorder vor der am S0 Bus aufzeichnet. System SuSE 8.2, AVM Fritz!Card V2.0.
Hi mal abgesehen davon, dass das Mitschneiden verboten ist Nicht ganz richtig, es ist verboten mit dem Mitschnitt die Persönlichkeitsrechte des aufgezeichneten Sprechers zu verletzen. Dies geschieht idR. durch eine Veröffentlichung. Mitlerweile ist auch das Verwenden von Mitschnitten die ohne das Wissen des Aufgezeichneten vor Gericht verwertbar wenn es einen starfwürdigen Tatbestand beweist. Ist recht Hilfreich bei obskuren Anrufen, hat mir jedenfalls bereits gut geholfen...
musst du wohl auch wenn überhaupt das Gespräch auf dem PC engegen nehmen damit es überhaupt klappen kann weil der B kanal ja P2P ist. [...] Oder eine Entsprechend teure ISDN Karte im Rechner haben (S0 Bus)
Tschüss, Thomas
Thomas Templin wrote:
On Sunday 10 August 2003 12:56, Stephan Gwinner wrote:
Stephan Gwinner schrieb:
Helmut Scholl schrieb: [...]
ich möchte wichtige Telefonate die über die ISDN kommen mitschneiden, um sie zu einem späteren Zeitpunkt noch einmal in Ruhe abhören zu können. Ich stelle mir so eine Art Voice-Recorder vor der am S0 Bus aufzeichnet. System SuSE 8.2, AVM Fritz!Card V2.0.
Hi mal abgesehen davon, dass das Mitschneiden verboten ist Nicht ganz richtig, es ist verboten mit dem Mitschnitt die Persönlichkeitsrechte des aufgezeichneten Sprechers zu verletzen. Dies geschieht idR. durch eine Veröffentlichung.
Nein, nach §201 Abs. 1 Nr. 1 StGB macht sich bereits strafbar, "wer unbefugt das nichtöffentlich gesprochene Wort eines anderen auf einen Tonträger aufnimmt", und zwar auch ohne die Veröffentlichung.
Mitlerweile ist auch das Verwenden von Mitschnitten die ohne das Wissen des Aufgezeichneten vor Gericht verwertbar wenn es einen starfwürdigen Tatbestand beweist. Ist recht Hilfreich bei obskuren Anrufen, hat mir jedenfalls bereits gut geholfen...
Das ist zwar richtig, aber dass es in begründeten Einzelfällen (z.B. belästigende Anrufe) trotz des Verbots gerechtfertigt sein kann, Gespräche aufzuzeichnen, ist kein Freibrief dafür, vorsorglich und ohne konkreten Anlass alle Telefonate ohne Wissen des Gesprächspartners aufnehmen zu dürfen. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
Am Donnerstag, 14. August 2003 08:35 schrieb Eilert Brinkmann:
Thomas Templin wrote:
On Sunday 10 August 2003 12:56, Stephan Gwinner wrote:
Stephan Gwinner schrieb:
Helmut Scholl schrieb:
[...]
Nicht ganz richtig, es ist verboten mit dem Mitschnitt die Persönlichkeitsrechte des aufgezeichneten Sprechers zu verletzen. Dies geschieht idR. durch eine Veröffentlichung.
Nein, nach §201 Abs. 1 Nr. 1 StGB macht sich bereits strafbar, "wer unbefugt das nichtöffentlich gesprochene Wort eines anderen auf einen Tonträger aufnimmt", und zwar auch ohne die Veröffentlichung.
Mitlerweile ist auch das Verwenden von Mitschnitten die ohne das Wissen des Aufgezeichneten vor Gericht verwertbar wenn es einen starfwürdigen Tatbestand beweist. Ist recht Hilfreich bei obskuren Anrufen, hat mir jedenfalls bereits gut geholfen...
Das ist zwar richtig, aber dass es in begründeten Einzelfällen (z.B. belästigende Anrufe) trotz des Verbots gerechtfertigt sein kann, Gespräche aufzuzeichnen, ist kein Freibrief dafür, vorsorglich und ohne konkreten Anlass alle Telefonate ohne Wissen des Gesprächspartners aufnehmen zu dürfen.
Normalerweise wäre mir das Bandmaterial und der Pattenplatz auch viel zu Schade. In diesem Fall handelt es sich jedoch um offizielle Aufträge. Kämen die als Fax oder Email herein hätte ich es gleich schriftlich und es gäbe auch keine Unstimmigkeiten. Von vorsorglich alle Telefonate mit zuschneiden hatte ich auch nicht gesprochen, denn bei den neuen Telefonen erkennt man in den meisten Fällen wer da etwas von einem will. -- MfG Helmut
Hallo,
From: Helmut Scholl [mailto:Helmut.Scholl_Witten@t-online.de] Sent: Thursday, August 14, 2003 9:05 AM
[...] wir arbeiten hier gerade an einer Möglichkeit Digitiale-Funkgespräche mitzuschneiden. Dies ist bei unserem Kunden aus Sicherheitgründen sogar zwingend vorgeschrieben. Alles was da reinkommt wird direkt als mp3 codiert und abgelegt. Unsere Schnittstelle, über die die Daten reinkommen, ist der serielle Bus (/dev/ttyS*), könnte aber natürlich auch jedes andere Gerät sein, dass nur die Gesprächsdaten in RAW PCM Form liefert. Wenn Du also irgendeine Möglichkeit finden solltest (Hardware oder Software), die Daten vom S0 oder B-Kanal auf ein Linux Device zu bekommen, dann hätten wir vielleicht was für Dich. Mit freundlichen Grüßen Maik Bader
M. Bader wrote:
Hallo,
Auch Hallo,
From: Helmut Scholl [mailto:Helmut.Scholl_Witten@t-online.de] Sent: Thursday, August 14, 2003 9:05 AM
[...]
wir arbeiten hier gerade an einer Möglichkeit Digitiale-Funkgespräche mitzuschneiden. Dies ist bei unserem Kunden aus Sicherheitgründen sogar zwingend vorgeschrieben. Alles was da reinkommt wird direkt als mp3 codiert und abgelegt.
Unsere Schnittstelle, über die die Daten reinkommen, ist der serielle Bus (/dev/ttyS*), könnte aber natürlich auch jedes andere Gerät sein, dass nur die Gesprächsdaten in RAW PCM Form liefert. Wenn Du also irgendeine Möglichkeit finden solltest (Hardware oder Software), die Daten vom S0 oder B-Kanal auf ein Linux Device zu bekommen, dann hätten wir vielleicht was für Dich.
Das ist in dem Fall ja auch das Problem, Geräte oder Software die genau sowas machen sind dünn gesäht und teuer und wenn SW dann für M$. Dafür erfolgt die Ausgabe aber dann auch gleich in einem menschenfreundlichen Format. Ich habe in der Anfangszeit des ISDN mal mit einem ISDN-Tester gearbeitet "Pegasus" war glaube ich von einer Firma Festo (ist schon gut 10 Jahre her) der konnte z.B. "mithören". Eigentlich sollte es recht "einfach" mit einer ISDN-Karte möglich sein - man müsste IMO der Karte nur per CAPI mitteilen jetzt z.B. Kanal B1 belegen obwohl schon benutzt und auch nur wenn Dienst "analog" und auch keine Signalisierungen wie "Gesprächsabbau" o.ä. senden. Und das rumpfuschen an der CAPI dürfte wohl das Problem sein, ist hier jemand mächtig? ISDN ist unter Linux ja immer noch ein "Stiefkind". Übrigens gabs mal von Teles ISDN Telefone mit einem Firmwarefehler, da hat das Mithören ohne Probleme geklappt - Hörer abheben und schon war der "richtige" Kanal belegt. Da obiges aber alles teuer ist haben wir bisher in solchen Fällen (Mitschneiden an ISDN- oder Systemtelefonen) immer die Hörerschnittstelle mißbraucht - da hats ein analoges Signal und die (schon erwähnten) Adapter von Retell sind durchaus bezahlbar. Gruß Eric
Eilert Brinkmann wrote:
Thomas Templin wrote:
On Sunday 10 August 2003 12:56, Stephan Gwinner wrote:
Stephan Gwinner schrieb:
Helmut Scholl schrieb: [...] [...] Hi mal abgesehen davon, dass das Mitschneiden verboten ist Nicht ganz richtig, es ist verboten mit dem Mitschnitt die Persönlichkeitsrechte des aufgezeichneten Sprechers zu verletzen. Dies geschieht idR. durch eine Veröffentlichung.
Nein, nach §201 Abs. 1 Nr. 1 StGB macht sich bereits strafbar, "wer unbefugt das nichtöffentlich gesprochene Wort eines anderen auf einen Tonträger aufnimmt", und zwar auch ohne die Veröffentlichung.
Wie immer bei rechtlichen Fragen gibt es hier nur ein eindeutiges JEIN ;-) wie oben schon erwähnt "unbefugt" und hier gehts schon los - schon mal Telefon-Banking gemacht? das Gespräch wurde 100%ig aufgezeichnet. Sofern meine Gesprächspartner (insbesondere Geschäftspartner) in irgendeiner Form darauf hingewiesen wurden das die Gespräche aufgezeichnet werden (z.B. im "Kleingedruckten" der Bank) ist die Aufzeichnung und Verwertung - IMO - rechtens. Einfach mal so die heiße "Gute-Nacht-Geschichte" der Freundin aufnehmen und dann... leider verboten ;-))
[...]
Gruß Eric
Am Donnerstag, 14. August 2003 13:02 schrieb Eric Scheen: Hi
Wie immer bei rechtlichen Fragen gibt es hier nur ein eindeutiges JEIN ;-) wie oben schon erwähnt "unbefugt" und hier gehts schon los - schon mal Telefon-Banking gemacht? das Gespräch wurde 100%ig aufgezeichnet. Sofern meine Gesprächspartner (insbesondere Geschäftspartner) in irgendeiner Form darauf hingewiesen wurden das die Gespräche aufgezeichnet werden (z.B. im "Kleingedruckten" der Bank) ist die Aufzeichnung und Verwertung - IMO - rechtens. Einfach mal so die heiße "Gute-Nacht-Geschichte" der Freundin aufnehmen und dann... leider verboten ;-))
Die nimmt man nicht auf, die erlebt man.;=)) Von AVM gibt es ein Programm mit dem man den PC direkt auch Telefon nutzen kann, aber W$. Viele Firmen können mit W$ einfach mehr Geld machen. Und denken vielleicht nicht daran das auch Open Source bezahlt werden muß und eben nicht alles kostenlos ist. Ich suche auch keine kostenlose, sondern eine bezahlbare, und keine einmalig überteuerten Gelegenheiten. Besser gefällt mir natürlich schon eventuell vorhandene Resourcen zu nutzen. -- MfG Helmut
On Thursday 14 August 2003 18:13, Helmut Scholl wrote:
Am Donnerstag, 14. August 2003 13:02 schrieb Eric Scheen: Hi
Wie immer bei rechtlichen Fragen gibt es hier nur ein eindeutiges JEIN ;-) wie oben schon erwähnt "unbefugt" und hier gehts schon los - schon mal Telefon-Banking gemacht? das Gespräch wurde 100%ig aufgezeichnet. Sofern meine Gesprächspartner (insbesondere Geschäftspartner) in irgendeiner Form darauf hingewiesen wurden das die Gespräche aufgezeichnet werden (z.B. im "Kleingedruckten" der Bank) ist die Aufzeichnung und Verwertung - IMO - rechtens. Einfach mal so die heiße "Gute-Nacht-Geschichte" der Freundin aufnehmen und dann... leider verboten ;-))
Die nimmt man nicht auf, die erlebt man.;=))
Von AVM gibt es ein Programm mit dem man den PC direkt auch Telefon nutzen kann, aber W$. Viele Firmen können mit W$ einfach mehr Geld machen. Und denken vielleicht nicht daran das auch Open Source bezahlt werden muß und eben nicht alles kostenlos ist. Ich suche auch keine kostenlose, sondern eine bezahlbare, und keine einmalig überteuerten Gelegenheiten. Besser gefällt mir natürlich schon eventuell vorhandene Resourcen zu nutzen. [...] ant-phone, natürlich Freie Software unter GNU/Linux macht das selbe. Vorrausgesetzt man hat 'ne duplex fähige Soundkarte.
Tschüss, Thomas
ant-phone, natürlich Freie Software unter GNU/Linux macht das selbe. Vorrausgesetzt man hat 'ne duplex fähige Soundkarte. Danke für den Tip. Compilieren und installieren gingen erstaunlich einfach und
Am Donnerstag, 14. August 2003 18:35 schrieb Thomas Templin: Hi Thomas, hallo Leute problemlos, mußte lediglich ein paar Pakete nachinstallieren und schon lief es. Sollte mal jemand ein RPM für SuSE von machen. -- MfG Helmut
Hi, Am Freitag, 15. August 2003 22:54 schrieb Helmut Scholl:
Am Donnerstag, 14. August 2003 18:35 schrieb Thomas Templin: Hi Thomas, hallo Leute
ant-phone, natürlich Freie Software unter GNU/Linux macht das selbe. Vorrausgesetzt man hat 'ne duplex fähige Soundkarte.
Danke für den Tip. Compilieren und installieren gingen erstaunlich einfach und problemlos, mußte lediglich ein paar Pakete nachinstallieren und schon lief es. Sollte mal jemand ein RPM für SuSE von machen.
Wenn Du schon soweit bist, dann erstell das rpm (checkinstall) und sende es an jemand der es für Dich hostet (z.B. packman: http://packman.links2linux.de/?action=devel-faq#6) Gruß Jean-Marc
Am Sonntag, 17. August 2003 11:34 schrieb Jean-Marc Autexier:
Wenn Du schon soweit bist, dann erstell das rpm (checkinstall) und sende es an jemand der es für Dich hostet (z.B. packman: http://packman.links2linux.de/?action=devel-faq#6)
Packman nimmt keine mit checkinstall erstellten RPMs. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Sonntag, 17. August 2003 12:32 schrieb Manfred Tremmel:
.. Packman nimmt keine mit checkinstall erstellten RPMs.
Hallo Manfred, kannst Du genauer erklären wieso packman keine checkinstall rpms' nimmt? Ich habe mir die RPM-Developer FAQ durchgelesen, außer der Signatur scheint es für mich keine großen Unterschiede zwischem checkinstall und manuel erstellten RPMs zu geben. Wo sind die Unterschiede? Gruß Jean-Marc
Jean-Marc Autexier <jmau2002@web.de> [Sun, 17 Aug 2003 14:39:09 +0200]:
Am Sonntag, 17. August 2003 12:32 schrieb Manfred Tremmel:
.. Packman nimmt keine mit checkinstall erstellten RPMs.
kannst Du genauer erklären wieso packman keine checkinstall rpms' nimmt?
Ich vermute mal, weil checkinstall nur nachträglich aufzeichnet, was wohin installiert wurde. Damit fehlt z.B. ein korrektes .src.rpm inklusive einer korrekten .spec Datei. checkinstall ist nur ein Notbehelf und kann ein richtiges RPM Paket nicht ersetzen, ebensowenig wie ein mit alien umgewandeltes .deb Paket. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de SuSE Linux AG Privat: philipp.thomas@t-link.de
On Sun, 2003-08-17 at 14:49, Philipp Thomas wrote:
Jean-Marc Autexier <jmau2002@web.de> [Sun, 17 Aug 2003 14:39:09 +0200]:
Am Sonntag, 17. August 2003 12:32 schrieb Manfred Tremmel:
.. Packman nimmt keine mit checkinstall erstellten RPMs.
kannst Du genauer erklären wieso packman keine checkinstall rpms' nimmt?
Ich vermute mal, weil checkinstall nur nachträglich aufzeichnet, was wohin installiert wurde. Damit fehlt z.B. ein korrektes .src.rpm inklusive einer korrekten .spec Datei.
checkinstall ist nur ein Notbehelf und kann ein richtiges RPM Paket nicht ersetzen, ebensowenig wie ein mit alien umgewandeltes .deb Paket. Soisses, dies sind die beiden Hauptgründe.
Weitere Gründe: * Bei GPL'd Paketen müssen die Sourcen mit vertrieben werden. Es nicht zu tun, kann man als Verletzung der GPL interpretieren. * checkinstall installiert in ein laufendes System. Deshalb ist "sauberes" Verhalten bei der Installation nicht sichergestellt, in Einzelfällen auch nicht möglich. * Auf längere Sicht sind RPM-specs einfacher zu pflegen als checkinstall'ed Pakete (z.B. Distributions-, Distributionsversions oder Paketversionswechseln) * RPM-specs und src.rpms sind grundsätzlich architektur-unabhängig, checkinstall-RPMs nicht. Ralf
* Ralf Corsepius (corsepiu@faw.uni-ulm.de) [20030817 15:27]:
* Bei GPL'd Paketen müssen die Sourcen mit vertrieben werden. Es nicht zu tun, kann man als Verletzung der GPL interpretieren.
Was aber falsch wäre. Du musst nur auf Verlangen die Sourcen liefern können, du musst sie nicht parallel anbieten. Aber es zugegebenermassen deutlich einfacher, gleich das .src.rpm dazu zu packen.
* Auf längere Sicht sind RPM-specs einfacher zu pflegen als checkinstall'ed Pakete (z.B. Distributions-, Distributionsversions oder Paketversionswechseln)
Nicht nur auf längere Sicht :) Unterschiede in Distributionsversionen kann man nur in den Specs handhaben.
* RPM-specs und src.rpms sind grundsätzlich architektur-unabhängig, checkinstall-RPMs nicht.
Meiner Meinung nach ist checkinstall auch eine mächtige Krücke, die man nicht verwenden sollte. Philipp -- Philipp Thomas <pthomas@suse.de> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nuremberg, Germany
On Mon, 2003-08-18 at 11:12, Philipp Thomas wrote:
* Ralf Corsepius (corsepiu@faw.uni-ulm.de) [20030817 15:27]:
* Bei GPL'd Paketen müssen die Sourcen mit vertrieben werden. Es nicht zu tun, kann man als Verletzung der GPL interpretieren.
Was aber falsch wäre.
Dürfte Auslegungssache sein - Ich kann nur soviel dazu sagen, dass die FSF in Person von RMS schon Leuten mit Klage gedroht hatte, die Binärtarbälle von gepatchten GCCs und die dazugehörigen Diffs auf ihrem ftp-Server liegen hatten, ohne dass sie die dazugehörigen FSF-GCC-Tarbälle auf dem Server liegen hatten. (Siehe auch: http://www.fiddes.net/coldfire/old-index.html). Überträgt man diese von der FSF und RMS vorgenommen Auslegung der GPL auf binär-RPMS statt binär-Tarbällen, würde ein check-install generiertes Binär-RPM eine Verletzung der GPL darstellen.
Du musst nur auf Verlangen die Sourcen liefern können, du musst sie nicht parallel anbieten. Aber es zugegebenermassen deutlich einfacher, gleich das .src.rpm dazu zu packen. Sehe ich auch so.
* RPM-specs und src.rpms sind grundsätzlich architektur-unabhängig, checkinstall-RPMs nicht.
Meiner Meinung nach ist checkinstall auch eine mächtige Krücke, die man nicht verwenden sollte.
ACK. Ralf
Am Montag, 18. August 2003 11:12 schrieb Philipp Thomas:
Was aber falsch wäre. Du musst nur auf Verlangen die Sourcen liefern können, du musst sie nicht parallel anbieten. Aber es zugegebenermassen deutlich einfacher, gleich das .src.rpm dazu zu packen.
Die Sache ist nur die, wenn man sich mit harter Mühe und drei oder vier kleineren Änderungen ein Programm compiliert hat, mit checkinstall ein RPM bastelt, dann das Source-Verzeichnis löscht, wird es reichlich schwierig, genau die verwendeten Sourcen zu rekonstruieren.
* Auf längere Sicht sind RPM-specs einfacher zu pflegen als checkinstall'ed Pakete (z.B. Distributions-, Distributionsversions oder Paketversionswechseln)
Nicht nur auf längere Sicht :) Unterschiede in Distributionsversionen kann man nur in den Specs handhaben.
Die Zeitersparnisse bei immer wiederkehrenden Änderungen sind ohne SPECs auch gar nicht denkbar. Im DVD-Rip RPM bei Packman hab ich z.B. einen Patch drin, der die Voreingestellten Pfade einiger Hilfsprogramme so umstellt, dass sie denen einer SuSE-Installation entsprechen. Der Patch hat schon mindestens 10 Programmversionen überstanden, ohne eine Anpassung. Mit Checkinstall wäre das jedesmal Handarbeit. Von den Grausamkeiten, die ich mit ktail oder kxine veranstalte, will ich erst gar nicht reden ;-) Gerade kxine, das per täglichem cron Job (wie alle xine Pakete) neu compiliert wird, darf kein tägliches Eingreifen erfordern, macht der Source-Forge-CVS-Server schon genug Ärger (drum gibts heute auch keine neuen RPMs).
* RPM-specs und src.rpms sind grundsätzlich architektur-unabhängig, checkinstall-RPMs nicht.
Solange der zugrundeliegende tarball es ist, ein Source-RPM mit nem Assembler-Programm ist nicht Architekturunabhängig, ein "Source-RPM", das nur Binaries installiert, wie z.B. bei Java, ist es auch nicht.
Meiner Meinung nach ist checkinstall auch eine mächtige Krücke, die man nicht verwenden sollte.
Seh ich ähnlich. Checkinstall ist besser als einfach nur mit 'make install' auf die Kiste zu bügeln, aber fürs weitergeben vielleicht nicht so das ware. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Sonntag, 17. August 2003 14:49 schrieb Philipp Thomas:
Jean-Marc Autexier <jmau2002@web.de> [Sun, 17 Aug 2003 14:39:09 +0200]:
Am Sonntag, 17. August 2003 12:32 schrieb Manfred Tremmel:
.. Packman nimmt keine mit checkinstall erstellten RPMs.
kannst Du genauer erklären wieso packman keine checkinstall rpms' nimmt?
Ich vermute mal, weil checkinstall nur nachträglich aufzeichnet, was wohin installiert wurde. Damit fehlt z.B. ein korrektes .src.rpm inklusive einer korrekten .spec Datei.
checkinstall ist nur ein Notbehelf und kann ein richtiges RPM Paket nicht ersetzen, ebensowenig wie ein mit alien umgewandeltes .deb Paket.
Ich glaube Manfred hatte das vor einigen Tagen oder Wochen schon mal erklärt. Im übrigen laufen auch einige Pakete von Packman nicht auf Anhieb und man muß suchen was nun fehlt oder falsch ist, das Elend mit den Versionsnummern einiger libs ist eines, oder es wird auch noch ein Paket benötigt, welches in der Beschreibung nicht erwähnt wurde. Und diese RPMs sind direkt für die einzelnen SuSE Versionen zugeschnitten. Nun möchte ich aber auch die Gelegenheit ergreifen und mich bei allen für die vielen Tips, und hinweise auf Quellen bedanken. -- MfG Helmut
Helmut.Scholl_Witten@t-online.de (Helmut Scholl) [17 Aug 2003 16:00:31]:
Nun möchte ich aber auch die Gelegenheit ergreifen und mich bei allen für die vielen Tips, und hinweise auf Quellen bedanken.
Und unter ftp://ftp.gwdg.de/pub/linux/suse/people/pthomas/8.2 findest du jetzt auch ein direkt für 8.2-i386 gebautes ant-phone :) Philipp
Am Sonntag, 17. August 2003 16:18 schrieb Philipp Thomas:
Helmut.Scholl_Witten@t-online.de (Helmut Scholl) [17 Aug 2003 16:00:31]:
Nun möchte ich aber auch die Gelegenheit ergreifen und mich bei allen für die vielen Tips, und hinweise auf Quellen bedanken.
Und unter ftp://ftp.gwdg.de/pub/linux/suse/people/pthomas/8.2 findest du jetzt auch ein direkt für 8.2-i386 gebautes ant-phone :)
Danke Philipp, Aber jetzt habt ihr mich doch noch so heiß gemacht dass ich, ich hoffe richtig, das Paket mit KRPMbuilder gebastelt habe. Dazu für alle die auch Schwierigkeiten damit haben: http://www.linux-magazin.de/Artikel/ausgabe/1999/11/RPM/rpm2.html. Nun habe ich sowohl die ant-phone-0.1.5-SuSE82.src.rpm wie auch die ant-phone-0.1.5-SuSE82.rpm. Sicher gibt es noch einiges an meinem Vorgehen zu verbessern, aber wenn man den Dreh einmal raus hat kommt der Rest eigentlich auch. Anmerkung zu meiner Person: bin weder Systemadministrator(Ausname: eigenes), noch Programmierer, sondern einfach nur jemand der mit Spaß an diesem Betriebssystem dabei ist, obendrein auch schon einwenig älter, daher manchmal auch dumme Fragen, oder Fragen die schon längst beantwortet waren. -- MfG Helmut
* Philipp Thomas schrieb am Sonntag, 2003-08-17:
Und unter ftp://ftp.gwdg.de/pub/linux/suse/people/pthomas/8.2 findest du jetzt auch ein direkt für 8.2-i386 gebautes ant-phone :)
Danke schön. Das Binary-RPM funktioniert einwandfrei, nach ein paar Nacharbeiten. Erstens: christian:/home/chris # rpm -ivh ant-phone-0.1.5-0.i586.rpm Fehler: fehlgeschlagene Paket-Abhängigkeiten: gtk >= 2.0.0 wird von ant-phone-0.1.5-0 gebraucht christian:/home/chris # rpm -q gtk gtk-1.2.10-552 christian:/home/chris # rpm -q gtk2 gtk2-2.2.1-77 christian:/home/chris # rpm -q --provides gtk2 gtk2+ [...] Zweitens enthält das Binary falsche Pfade für die isdnlog- Protokolldatei (die ist in /var/log/isdn.log). Läßt sich aber mit 'nem Hexeditor problemlos ändern. Die falschen Werte stammen aus dem Vorgabewert für calls_filenames in isdn.c . Drittens kompiliert das SRPM nicht: christian:/usr/src/packages/SPECS # rpm -bc ant-phone.spec [...] + autoreconf -I /opt/gnome/share/aclocal --force --install cvs [checkout aborted]: no such tag gettext-0_12_1 /usr/bin/autopoint: line 260: fatal_error: command not found find: tmpwrk13121/archive: Datei oder Verzeichnis nicht gefunden Hier kann ich nicht ganz ausschließen, daß die manuelle Nachinstallation eines neueren gettext zu Problemen geführt hat. Andererseits sind aber alle m. E. relevanten Pakete unverändert (das sind autoconf, automake, gettext) und besagtes neuere gettext liegt im Homeverzeichnis eines anderen Benutzers und ist bei diesem Build nicht im Weg. Versuche ich das entpackte SRPM von Hand zu kompilieren, passiert nach einem sauberen configure das hier: christian:/usr/src/packages/BUILD/ant-phone-0.1.5 # make cd . && /bin/sh /usr/src/packages/BUILD/ant-phone-0.1.5/missing --run aclocal -I m4 cd . && \ /bin/sh /usr/src/packages/BUILD/ant-phone-0.1.5/missing --run automake --gnu Makefile Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8848. [und noch eine ganze Menge mehr davon] -- Christian Ullrich Registrierter Linux-User #125183 "There's nothing we can't face -- except for Bun-bun..."
* Christian Ullrich (chris@chrullrich.de) [20030817 18:41]:
christian:/home/chris # rpm -ivh ant-phone-0.1.5-0.i586.rpm Fehler: fehlgeschlagene Paket-Abhängigkeiten: gtk >= 2.0.0 wird von ant-phone-0.1.5-0 gebraucht christian:/home/chris # rpm -q gtk gtk-1.2.10-552 christian:/home/chris # rpm -q gtk2 gtk2-2.2.1-77 christian:/home/chris # rpm -q --provides gtk2 gtk2+ [...]
Ja, da hatte ich vergessen, das Requires rauszuschmeissen.
Zweitens enthält das Binary falsche Pfade für die isdnlog- Protokolldatei (die ist in /var/log/isdn.log). Läßt sich aber mit 'nem Hexeditor problemlos ändern. Die falschen Werte stammen aus dem Vorgabewert für calls_filenames in isdn.c .
Ist jetzt auch korrigiert. Jetzt sucht ant-phone auch nach /var/log/isdn.log.
[...] + autoreconf -I /opt/gnome/share/aclocal --force --install cvs [checkout aborted]: no such tag gettext-0_12_1 /usr/bin/autopoint: line 260: fatal_error: command not found find: tmpwrk13121/archive: Datei oder Verzeichnis nicht gefunden
Bei mir baute es aber trotzdem, sonst hätte ich kein .i586.rpm anbieten könnnen :). Aber ich habe jetzt für 8.2 die Aufrufe der Autotools (autoreconf etc.) einfach unterbunden.
Hier kann ich nicht ganz ausschließen, daß die manuelle Nachinstallation eines neueren gettext zu Problemen geführt hat.
Nein, das Problem liegt woanders. Autopoint in der 8.2 kennt einfach die Gettext-Version 0.12.1 nicht, daher kommt es zu den Fehlermeldungen.
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8848. [und noch eine ganze Menge mehr davon]
Da die autotools nicht mehr aufgerufen werden, kommt das auch nicht mehr :) Die korrigierten RPMs liegen jetzt an der genannten Stelle. Vielen Dank für die Rückmeldungen. Philipp -- Philipp Thomas <pthomas@suse.de> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nuremberg, Germany
Am Sonntag, 17. August 2003 16:18 schrieb Philipp Thomas: Hi Philipp, hallo Leute
Und unter ftp://ftp.gwdg.de/pub/linux/suse/people/pthomas/8.2 findest du
Hab gerade das Paket heruntergeladen. Bei der Installation kam dann die Meldung: nicht erfüllte Abhängikeit, benötigt Gtk >=2.0.0. Dabei handelt es sich wohl um das Gtk2 wie es auf den SuSE DVD´s enthalten ist. Installiert habe ich Gtk für das Gimppaket und das Gtk2 paket (+ devel) weil einige andere Anwendungen das wohl brauchen. Der Versuch Gtk-1.2.10-552 zu löschen ergab dann >99 weitere Abhängikeitsprobleme. Das Gtk2 hat die Versionsnummer 2.2.1-77 wird aber von Ant-Phone nicht erkannt. Wenn Du eine schnelle Lösung hast OK, ansonsten ist wieder tüfteln angesagt. Bei der Gelegenheit würde mich interessieren warum die einzelnen Installationen mit derselben Distri und Version so verschieden reagieren. -- MfG Helmut PS: Aus purer Bequemlichkeit und Vertrauen in meine Mitmenschen versuche ich immer erst das fertige Binary zu installieren. Ich weiß ja das ein absichtlich falsch gebautes RPM als Virusersatz für Linux verwendet werden kann. :-)
Helmut.Scholl_Witten@t-online.de (Helmut Scholl) [18 Aug 2003 11:44:46]:
Wenn Du eine schnelle Lösung hast OK, ansonsten ist wieder tüfteln angesagt. Bei der Gelegenheit würde mich interessieren warum die einzelnen Installationen mit derselben Distri und Version so verschieden reagieren.
Einfach noch einmal holen :) Inzwischen sollte das korrigierte Paket auch extern verfügbar sein. Philipp
Am Montag, 18. August 2003 23:03 schrieb Philipp Thomas: Hi Phillip
Helmut.Scholl_Witten@t-online.de (Helmut Scholl) [18 Aug 2003 11:44:46]:
Wenn Du eine schnelle Lösung hast OK, ansonsten ist wieder tüfteln angesagt. Bei der Gelegenheit würde mich interessieren warum die einzelnen Installationen mit derselben Distri und Version so verschieden reagieren.
Einfach noch einmal holen :) Inzwischen sollte das korrigierte Paket auch extern verfügbar sein. Ging einwandfrei durch.
-- MfG Helmut
Am Sonntag, 17. August 2003 14:39 schrieb Jean-Marc Autexier:
kannst Du genauer erklären wieso packman keine checkinstall rpms' nimmt? Ich habe mir die RPM-Developer FAQ durchgelesen, außer der
Wenn Du es exakt wissen willst, musst Du Marc fragen, die Regel stammt nicht von mir. Fakt ist im Moment jedenfalls, dass das Web-Interface die Einstellung eines RPMs ohne Source-RPMs nicht ermöglicht. Sprich, wenn man das ermöglichen wollte, würe auf jeden Fall eine grössere Programmierung und Datenbankumstellung notwendig.
Signatur scheint es für mich keine großen Unterschiede zwischem checkinstall und manuel erstellten RPMs zu geben. Wo sind die Unterschiede?
Die Herrangehensweise und Reproduzierbarkeit. Wärend man mit Checkinstall ja bereits die komplette Konfiguration mit all den Parametern, eventuelle Patches, und das compilieren ist bereits geschehen, Checkinstall zeichnet nur noch den Installationsprozess auf. Damit ist nicht mehr nachvollziehbar, wie das ganze abgelaufen ist. So ein RPM läst sich nicht neu compilieren (für ne andere Prozessor- plattform, ne andere Distri oder nen andere Version). -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Sonntag, 17. August 2003 11:34 schrieb Jean-Marc Autexier: Hi,
Danke für den Tip. Compilieren und installieren gingen erstaunlich einfach und problemlos, mußte lediglich ein paar Pakete nachinstallieren und schon lief es. Sollte mal jemand ein RPM für SuSE von machen.
Wenn Du schon soweit bist, dann erstell das rpm (checkinstall) und sende es an jemand der es für Dich hostet (z.B. packman: http://packman.links2linux.de/?action=devel-faq#6)
Mit RPM als Paketbuilder stehe ich noch auf Kriegsfuß. Da suche ich noch nach einer Anleitung "RPM-Pakete schnüren für Dummies." oder so ähnlich. Allerdings habe ich auch noch nicht sehr gründlich gesucht. Linux bietet so viel, das ich mich da bestimmt noch einige Jahre damit beschäftigen kann und immer noch etwas neues, interessantes entdecke. -- MfG Helmut PS: Ausfürliche Anleitungen in deutsch nehme ich gern auch als PM
Helmut Scholl schrieb:
Mit RPM als Paketbuilder stehe ich noch auf Kriegsfuß. Da suche ich noch nach einer Anleitung "RPM-Pakete schnüren für Dummies." oder so ähnlich. Allerdings habe ich auch noch nicht sehr gründlich gesucht. [...] PS: Ausfürliche Anleitungen in deutsch nehme ich gern auch als PM
http://www.tu-chemnitz.de/linux/Dokumentation/RPM/index.html ==> Teil II: Paketbau CU, Th.
Am Sonntag, 17. August 2003 11:34 schrieb Jean-Marc Autexier:
Am Freitag, 15. August 2003 22:54 schrieb Helmut Scholl:
Am Donnerstag, 14. August 2003 18:35 schrieb Thomas Templin: Hi Thomas, hallo Leute
ant-phone, natürlich Freie Software unter GNU/Linux macht das selbe. Vorrausgesetzt man hat 'ne duplex fähige Soundkarte.
Danke für den Tip. Compilieren und installieren gingen erstaunlich einfach und problemlos, mußte lediglich ein paar Pakete nachinstallieren und schon lief es. Sollte mal jemand ein RPM für SuSE von machen.
Das verfügbare 'Mandrake RPM Package' läuft hervorragend mit SuSE-Linux http://rpmfind.net/linux/RPM/cooker/contrib/i586/ant-phone-0.1.4-2mdk.i586.h...
Wenn Du schon soweit bist, dann erstell das rpm (checkinstall) und sende es an jemand der es für Dich hostet (z.B. packman: http://packman.links2linux.de/?action=devel-faq#6)
Sorry, ich habe die Mail von Helmut nicht mehr, deshalb antworte ich Dir. Robert
On Sunday 17 August 2003 11:34, Jean-Marc Autexier wrote: [...]
Am Freitag, 15. August 2003 22:54 schrieb Helmut Scholl:
Am Donnerstag, 14. August 2003 18:35 schrieb Thomas Templin: [...]
ant-phone, natürlich Freie Software unter GNU/Linux macht das selbe. Vorrausgesetzt man hat 'ne duplex fähige Soundkarte.
Danke für den Tip. Compilieren und installieren gingen erstaunlich einfach und problemlos, mußte lediglich ein paar Pakete nachinstallieren und schon lief es. Sollte mal jemand ein RPM für SuSE von machen.
Wenn Du schon soweit bist, dann erstell das rpm (checkinstall) und sende es an jemand der es für Dich hostet (z.B. packman: http://packman.links2linux.de/?action=devel-faq#6) [...] Besotg dir das ant-phone Debian Paket und wandle das DEB mit Alien in ein RPM um.
Tschüss, Thomas
Am Sonntag, 17. August 2003 14:11 schrieb Thomas Templin:
[...] Besotg dir das ant-phone Debian Paket und wandle das DEB mit Alien in ein RPM um.
Warum sollte man den Aufwand betreiben? Auf der Seite http://www.antcom.de/#downloa einfach dem Link 'Mandrake RPM Package' (http://rpmfind.net/linux/RPM/cooker/contrib/i586/ant-phone-0.1.4-2mdk.i586.h...) folgen und die Installation starten. Mit SuSE 8.2 läuft es bei mir auf Anhieb (mit HiSax und mit Capi2.0 getestet. Ja, ich verwende eine Fritz!PCI-Karte). Robert
participants (14)
-
Christian Ullrich -
Eilert Brinkmann -
Eric Scheen -
Hans-Robert Wagner -
Helmut.Scholl_Witten＠t-online.de -
Jean-Marc Autexier -
M. Bader -
Manfred Tremmel -
Philipp Thomas -
Philipp Thomas -
Ralf Corsepius -
Stephan Gwinner -
Thomas Hertweck -
Thomas Templin