Hi Leute,
mal ne blöde Frage. An wenn muss man sich wenden, wenn man endlich mal ein offzielles Paket für gpgsm (s/mime) und gpg-agent haben will? Überall wird gpg angepriesen, aber diese beiden Programme haben es immer noch nicht nach sarge oder unstable gebracht. Okay, imNetz findet man Anleitungen zum selber bauen. Es gibt auch inoffizielle Pakete (siehe http://lists.debian.org/ debian-user/2005/01/msg00635.html) Bloss für die "normalen" Nutzer von kmail, thunderbird, evolution kann das doch keine Lösung sein. Debian sollte auch ohne selber kompilieren oder Fremdpaketen benutzbar sein. Die anderen Distributionen bekommen das doch auch auf die Reihe. Lieber 100 Spiele weglassen und endlich mal gpg _richtig_ machen.
Ciao
Je -gerade mal wieder richtig gefrustet- ns
Hallo Jens,
Bloss für die "normalen" Nutzer .. evolution .. kann das doch keine Lösung sein.
Hier unter Gnome und Evolution wird ein ssh-agent gestartet, dann kann noch per Checkbox eingestellt werden, ob das Passwort für die Sitzung gecached werden soll. Fertig. Als normaler Nutzer ist das easy. Ich kann Deine Aufregung nicht nachvollziehen.
Debian sollte auch ohne selber kompilieren oder Fremdpaketen benutzbar sein.
Ach naja, selbst so ein Paket zu basteln ist doch nicht so schwer.
Grüße
Marek
Am Mittwoch, 9. März 2005 10:20 schrieb Marek Werstak:
Hallo Jens,
Bloss für die "normalen" Nutzer .. evolution .. kann das doch keine Lösung sein.
Hier unter Gnome und Evolution wird ein ssh-agent gestartet, ...
ssh-agent?
Sorry. Evolution hat tatsächlich einen eigene Paßphraseabfrage.
.... dann kann noch per Checkbox eingestellt werden, ob das Passwort für die Sitzung gecached werden soll. Fertig. Als normaler Nutzer ist das easy.
Ich weis. Wenns es einmal funktioniert, dann ist das einfach spizenmässig. Und was passiert, wenn man nicht Evolution sondern KMail verwenden will? Da müsste ein gpg-agent auf deine Platte kommen.
Ich kann Deine Aufregung nicht nachvollziehen.
Man hat mal wieder jemand zu Debian bekehrt. Die Installation geht fix und das allermeiste ist sinnvoll vorkonfiguriert. Wunderbare Sache. Und $jemand ist total von apt-get begeistert. Und nun? $jemand fragt nach Verschlüsselung von e-mails. Alles kein Problem. Ups ... s/mime fehlt ganz. Naja nicht weiter schlimm. Dann nimmt er halt nur "OpenGPG (gpg)". Also mal ne Testmail verschickt. Er kann sie mit KMail nicht entschlüsseln "Grund: Das Krypto-Modul "opengpg" konnte die Datei nicht entschlüsseln. Fehler: Falsche Passphrase" Es wurde aber nie nach der Passphrase gefragt. :-(
Und weil das alles so easy geht, greift man mal fix zum Kompiler apt-get install gcc $viele_Developerpakete wget .... configure make su make install Alles ganz einfach :-(
Debian sollte auch ohne selber kompilieren oder Fremdpaketen benutzbar sein.
Ach naja, selbst so ein Paket zu basteln ist doch nicht so schwer.
Richtig. Aber warum benutzt dann nicht jeder LFS?
Jens
Marek Werstak marexmail@web.de (Mi 09 Mär 2005 10:20:34 GMT):
Ach naja, selbst so ein Paket zu basteln ist doch nicht so schwer.
Das ist keine Lösung. Fangen wir bei Debian jetzt mal an, alle unsere Packages selbst zu bauen?
(Bin gerade gefrustet, weil auf meine Mails, wieder 'develeoper'-Status zu bekommen, *garnichts* passiert, nicht mal 'ne Mail, dass es gerade viel zu tun gibt...)
Heiko
Heiko Schlittermann hs@schlittermann.de:
Marek Werstak marexmail@web.de (Mi 09 Mär 2005 10:20:34 GMT):
Ach naja, selbst so ein Paket zu basteln ist doch nicht so schwer.
Das ist keine Lösung. Fangen wir bei Debian jetzt mal an, alle unsere Packages selbst zu bauen?
Auf das im Betreff genannte Problem bin ich gestern mit Jens auch gestoßen. Ein bisschen Suchen im BTS zeigt, dass das noch eine offenen Frage für sarge ist. ITP #187548 für newpg wurde im Sommer letzten Jahres einfach geschlossen und Bug #280175 ist seit 4 Monaten offen.
Ich habe eine Anfrage an den o. g. Bug geschrieben und hoffe, das die Debian-KDE-Liste antwortet.
Auf die schnelle sollte ein DD newpg paketieren und ins Archiv laden. Die Zeit drängt und so kann's nicht bleiben.
Freundlich grüßend,
Erik
Am Mittwoch, den 09.03.2005, 08:29 +0100 schrieb Jens Weisse:
mal ne blöde Frage. An wenn muss man sich wenden, wenn man endlich mal ein offzielles Paket für gpgsm (s/mime) und gpg-agent haben will?
Hallo Jens,
du solltest einen RFP-Bug-Report schreiben (request for package) bzw. mal fanden, ob es einen solchen schon gibt und dann alle Info dran hängen, die du hast.
Viele Grüße, Torsten
Kiro Zimmer lug-dd@kironet.de:
seit gestern ist es offiziell in unstable ;)
Halleluja!!!!1
Hoffen wir, dass es schnell nach testing rutscht.
Freundlich grüßend, Erik
Am Donnerstag, 17. März 2005 09:13 schrieb Erik Schanze:
Hoffen wir, dass es schnell nach testing rutscht.
Mal zur Übersicht für diejenigen, die schon immer mal wissen wollten, wo und wann so ein Paket denn wohin rutscht:
Zuerst verspürt irgendein Wesen auf dieser Welt den Wunsch, ein Paket zu erstellen. Er sendet eine Nachricht darüber (RFP) und kommt dann auf http://www.debian.org/devel/wnpp/being_packaged, wo er solange bleibt, bis das Paket fertig ist. So sieht man z.B., dass das Paket 'balance' seit 1100 Tagen in Arbeit ist. Will ja nicht pessimistisch sein, aber das wird wohl nichts mehr... zumal es mit 'morebalance' eine Alternative gibt. </werbung>
Wenn ein komplett neues Paket gebaut ist, muss es erst einer Prüfung unterzogen werden. Es taucht dann auf der Seite http://ftp-master.debian.org/new.html auf, so wie z.B. PHP5 oder GCC 4.0 zur Zeit. Auch UnionFS (welches von vielen Live-CDs verwendet werden wird) ist dort zu finden. Kommt also alles in den nächsten Tagen bis Wochen nach 'unstable'.
Sitzt es dann dort erstmal fest, so braucht es gewöhnlich 10 Tage, bis es nach 'testing' kommt. Manchmal aber auch länger. Die Seite http://bjorn.haxx.se/debian/testing.pl?package=gnupg-agent gibt Auskunft darüber.
Josef
On 17.03.05 Josef Spillner (josef@coolprojects.org) wrote:
Moin,
Sitzt es dann dort erstmal fest, so braucht es gewöhnlich 10 Tage, bis es nach 'testing' kommt. Manchmal aber auch länger. Die Seite http://bjorn.haxx.se/debian/testing.pl?package=gnupg-agent gibt Auskunft darüber.
Ich dachte das hängt davon ab, mit welcher urgency das Paket hochgeladen wird....
H.
Hallo Josef!
Josef Spillner josef@coolprojects.org:
Am Donnerstag, 17. März 2005 09:13 schrieb Erik Schanze:
Hoffen wir, dass es schnell nach testing rutscht.
Mal zur Übersicht für diejenigen, die schon immer mal wissen wollten, wo und wann so ein Paket denn wohin rutscht:
Zuerst verspürt irgendein Wesen auf dieser Welt den Wunsch, ein Paket zu erstellen. Er sendet eine Nachricht darüber (RFP) und kommt dann auf http://www.debian.org/devel/wnpp/being_packaged, wo er solange bleibt, bis das Paket fertig ist.
Nicht ganz. Wenn jemand ein Paket haben, aber nicht selbst erstellen will, schreibt er eine RFP-Bug (Request for package). Wenn jemand das Paket baut, erstellt er gleich einen ITP (Intend to package) oder benennt den dazugehörenden RFP um.
So sieht man z.B., dass das Paket 'balance' seit 1100 Tagen in Arbeit ist. Will ja nicht pessimistisch sein, aber das wird wohl nichts mehr... zumal es mit 'morebalance' eine Alternative gibt. </werbung>
Schreibe einen RFP (ITP) für morebalance und bitte den Owner des RFP von balance ihn zu schließen.
In Zukunkft will das QA-Team inaktive RFPs und ITPs schneller schließen.
Sitzt es dann dort erstmal fest, so braucht es gewöhnlich 10 Tage, bis es nach 'testing' kommt.
Wenn keine schwerwiegenden Fehler gemeldet werden.
Freundlich grüßend, Erik
Am Donnerstag, 17. März 2005 13:50 schrieb Erik Schanze:
Schreibe einen RFP (ITP) für morebalance und bitte den Owner des RFP von balance ihn zu schließen.
Wenn, dann wäre es ein RFS: http://tudix.linux-info-tag.de/debbrowser.php
Josef
Hallo Josef!
Am Donnerstag, 17. März 2005 13:50 schrieb Erik Schanze:
Schreibe einen RFP (ITP) für morebalance und bitte den Owner des RFP von balance ihn zu schließen.
Wenn, dann wäre es ein RFS:
Nicht ganz. ;-) RFS heißt "Request for sponsor" und damit kennzeichnist du eine Nachricht, die du in die Mailinliste debian-mentors postest, wenn du kein DD bist und einen Sponsor für deinen Upload suchst.
Wenn es ein neues Paket ist, d. h. noch nicht im Archiv, dann musst du vorher einen ITP stellen, sonst gibt's mekka.
Siehe auch: http://www.debian.org/devel/wnpp/
Was meinst du mit der Seite? Sind da Pakete dabei, die auf Integration in Debian warten?
Freundlich grüßend, Erik
Salut,
Am Donnerstag, 17. März 2005 14:38 schrieb Erik Schanze:
Nicht ganz. ;-) RFS heißt "Request for sponsor" und damit kennzeichnist du eine Nachricht, die du in die Mailinliste debian-mentors postest, wenn du kein DD bist und einen Sponsor für deinen Upload suchst.
Genau das wäre aber für Morebalance der Fall. Einer, der etwas gesponsort haben will, muss kein NM sein. Er kann sich auch sein ganzes Leben lang sponsorn lassen. Ist zwar unüblich, aber möglich.
Wenn es ein neues Paket ist, d. h. noch nicht im Archiv, dann musst du vorher einen ITP stellen, sonst gibt's mekka.
ITP kommt ja vor der Existenz eines Paketes. Du meinst wahrscheinlich einen "sponsored NMU", dann muss das Paket natürlich schon in Debian sein. Aber man kann durchaus eines in Timbuktu finden und jemanden bitten, es hochzuladen, dann ist das genau ein RFS.
Was meinst du mit der Seite? Sind da Pakete dabei, die auf Integration in Debian warten?
Es sind 3 Typen von Debian-Paketen dort: - solche, die irgendwo rumlagen und nur gespiegelt werden, damit man sie zur Hand hat (morebalance, ccslc, japper), erkennbar an einer revisionierten Versionsnummer - die nativen Pakete, erkennbar an der fehlenden Revision - und dann diejenigen, für die gar kein Packaging existierte
Wenn nun jemand diese Pakete in Debian haben möchte, kann er sie von dort holen. Das macht nicht bei allen Paketen Sinn, aber bei einigen schon.
Josef
Hallo Josef!
Josef Spillner:
Salut,
Ich salutiere vor niemandem. ;-)
Am Donnerstag, 17. März 2005 14:38 schrieb Erik Schanze:
Nicht ganz. ;-) RFS heißt "Request for sponsor" und damit kennzeichnist du eine Nachricht, die du in die Mailingliste debian-mentors postest, wenn du kein DD bist und einen Sponsor für deinen Upload suchst.
Genau das wäre aber für Morebalance der Fall. Einer, der etwas gesponsort haben will, muss kein NM sein. Er kann sich auch sein ganzes Leben lang sponsorn lassen. Ist zwar unüblich, aber
möglich.
Ja. Und wenn er schon einen Sponsor kennt, der noch freie Kapazitäten hat /der Glückliche!),muss er nichtmal einen RFS stellen.
Wenn es ein neues Paket ist, d. h. noch nicht im Archiv, dann musst du vorher einen ITP stellen, sonst gibt's mekka.
ITP kommt ja vor der Existenz eines Paketes.
Ein ITP kennzeichnet, dass jemand an dem Paket arbeitet, um doppelte Arbeit zu verhindern. Auch wenn das Paket schon vorhanden ist, wollen die Sponsoren (meist) einen ITP sehen, sonst sponsorn sie dich nicht. Iss halt so.
Du meinst wahrscheinlich einen "sponsored NMU", dann muss das Paket natürlich schon in Debian sein.
Nein, das habe ich nicht gemeint. Das kann ich schon noch auseinanderhalten. ;-) Abgesehen davon sind sponsored NMUs "discouraged".
Aber man kann durchaus eines in Timbuktu finden und jemanden bitten, es hochzuladen, dann ist das genau ein RFS.
Häh?
Was meinst du mit der Seite? Sind da Pakete dabei, die auf Integration in Debian warten?
Es sind 3 Typen von Debian-Paketen dort:
- solche, die irgendwo rumlagen und nur gespiegelt werden, damit man sie
zur Hand hat (morebalance, ccslc, japper), erkennbar an einer revisionierten Versionsnummer
- die nativen Pakete, erkennbar an der fehlenden Revision
- und dann diejenigen, für die gar kein Packaging existierte
Wenn nun jemand diese Pakete in Debian haben möchte, kann er sie von dort holen. Das macht nicht bei allen Paketen Sinn, aber bei einigen schon.
Die nicht nativen Quellen-Pakete müssen aber z.T. neu gepackt werden. Siehe andere E-Mail (*.orig.tar.gz, *.diff.gz, *.dsc).
Freundlich grüßend, Erik
Am Donnerstag, 17. März 2005 15:19 schrieb Erik Schanze:
Aber man kann durchaus eines in Timbuktu finden und jemanden bitten, es hochzuladen, dann ist das genau ein RFS.
Häh?
Man kann alles hochladen lassen, sofern man selbst als Maintainer drinsteht und einen findet, der dafür den Kopf hinhält.
Die nicht nativen Quellen-Pakete müssen aber z.T. neu gepackt werden. Siehe andere E-Mail (*.orig.tar.gz, *.diff.gz, *.dsc).
Das Diff ist aber genau 0 Bytes groß. Somit sind es schon "native Pakete" im technischen Sinne. Nur halt keine aus Projektsicht. Ein 0-Byte-Diff wird gepackt zu 24 Bytes, wenn man es gzip einsetzt. Wozu also Traffic verschwenden :-)
Etwas anderes wäre es, wenn in dem Debian-Paket ein Fehler auftritt und das Paket neu erstellt werden müsste. Dann wäre im aktuellen Fall eine neue Upstream-Version nötig. Aber das ist bisher noch nie vorgekommen, und von daher braucht man sich das Leben nicht schwerer machen, als es eh schon ist.
Josef
Hallo Josef!
Josef Spillner josef@coolprojects.org:
Am Donnerstag, 17. März 2005 15:19 schrieb Erik Schanze:
Die nicht nativen Quellen-Pakete müssen aber z.T. neu gepackt werden. Siehe andere E-Mail (*.orig.tar.gz, *.diff.gz, *.dsc).
Das Diff ist aber genau 0 Bytes groß. Somit sind es schon "native Pakete" im technischen Sinne. Nur halt keine aus Projektsicht. Ein 0-Byte-Diff wird gepackt zu 24 Bytes, wenn man es gzip einsetzt. Wozu also Traffic verschwenden :-)
Dein diff is 0 bte groß, weill du das Verzeichnis debian/ mit in den originalen Tarball intergriert hast. Ich würde das nicht machen. (siehe andere E-Mail) Was soll ein RPM-Bauer mit dem Zeug?
Außerdem verschwendest du Traffic bei Leuten, die nur an dem Tarball ohne das Verzeichnis debian/ interessiert sind. ;-)
Freundlich grüßend, Erik
Am Donnerstag, 17. März 2005 16:16 schrieb Erik Schanze:
Außerdem verschwendest du Traffic bei Leuten, die nur an dem Tarball ohne das Verzeichnis debian/ interessiert sind. ;-)
Das ist ein Argument. Naja, die nächste Upstreamversion kommt bald, muss nur noch die zlib-Unterstützung fertigmachen...
Josef
Hallo Josef!
Josef Spillner josef@coolprojects.org:
Am Donnerstag, 17. März 2005 13:50 schrieb Erik Schanze:
Schreibe einen RFP (ITP) für morebalance und bitte den Owner des RFP von balance ihn zu schließen.
Wenn, dann wäre es ein RFS: http://tudix.linux-info-tag.de/debbrowser.php
Achso, ich vergas:
Debian-Paket-Quellen bestehen bei non-native Paketen aus: *.dsc - Paketbeschreibung *.diff.gz - Debianpezifische Erweiterung des Originalpakets und *.orig.tar.gz - Originalpaket
Siehe: http://www.debian.de/doc/maint-guide/ (man achte die Übersetzer. *g*)
Programm- und Paketanteile sollte man strikt trennen, das macht es anderen Distributionen leichter und ist von Vorteil, wenn Paketbetreuer != Upstream-Author.
Freundlich grüßend, Erik
Hi @all!
Kiro Zimmer lug-dd@kironet.de:
seit gestern ist es offiziell in unstable ;)
Funktioniert das schon bei jemandem zusammen mit KMail?
Bei mir wird zwar eine Datei $HOME/.gpg-agent-info angelegt, aber die ENV-Variable $GPG_AGENT_INFO nicht belegt und KMail registriert dadurch den Agenten nicht. :-(
Ein: GPG_AGENT_INFO=`cat $HOME/.gpg-agent-info` export GPG_AGENT_INFO
würde es lösen, aber wie führt man das beim KDE-Start aus? Die .xsession wird bei mir nicht beachtet.
Freundlich grüßend,
Erik
Hi Erik!
Erik Schanze schanzi_@gmx.de:
Kiro Zimmer lug-dd@kironet.de:
seit gestern ist es offiziell in unstable ;)
Funktioniert das schon bei jemandem zusammen mit KMail?
Bei mir wird zwar eine Datei $HOME/.gpg-agent-info angelegt, aber die ENV-Variable $GPG_AGENT_INFO nicht belegt und KMail registriert dadurch den Agenten nicht.
:-(
Ein: GPG_AGENT_INFO=`cat $HOME/.gpg-agent-info` export GPG_AGENT_INFO
würde es lösen, aber wie führt man das beim KDE-Start aus? Die .xsession wird bei mir nicht beachtet.
KLar geht das, siehe: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300128%3E Freundlich grüßend,
Freundlich grüßend,
Erik
KLar geht das, siehe: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300128%3E Freundlich grüßend,
So geht es natürlich auch. :P
Allerdings ist es schon komisch, das die XDEs irgendwie keine Startup-Dateien ausführen. Wenn man keinen Draht zum Admin hat (in meinem Fall betrifft es die Hochschule), kann das extrem nerven ;(
Kiro
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am Donnerstag, 17. März 2005 22:53 schrieb Erik Schanze:
Hi Erik!
Erik Schanze schanzi_@gmx.de:
Kiro Zimmer lug-dd@kironet.de:
seit gestern ist es offiziell in unstable ;)
Funktioniert das schon bei jemandem zusammen mit KMail?
Bei mir wird zwar eine Datei $HOME/.gpg-agent-info angelegt, aber die ENV-Variable $GPG_AGENT_INFO nicht belegt und KMail registriert dadurch den Agenten nicht.
:-(
Ein: GPG_AGENT_INFO=`cat $HOME/.gpg-agent-info` export GPG_AGENT_INFO
würde es lösen, aber wie führt man das beim KDE-Start aus? Die .xsession wird bei mir nicht beachtet.
KLar geht das, siehe: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300128%3E Freundlich grüßend,
Perfekte Arbeit :-) Mit deinem Skript geht das sofort.
Jens
Hi Erik,
das Problem hatte ich mit gdm als Loginmanager auch. Leider hat bisher niemand auf meinen Bugreport [1] reagiert. Folgendermaßen funktioniert es bei mir mit kmail unter gnome wunderbar:
#!/bin/sh # ~/.xclients export BROWSER=/usr/bin/firefox eval "$(gpg-agent --daemon)"
--- /etc/gdm/Xsession.original 2005-01-08 20:59:01.000000000 +0100 +++ /etc/gdm/Xsession 2005-01-08 21:00:46.000000000 +0100 @@ -97,11 +97,20 @@ SYSSESSIONDIR=/etc/X11/Xsession.d USERXSESSION=$HOME/.xsession ALTUSERXSESSION=$HOME/.Xsession +USERXCLIENTS=$HOME/.xclients +ALTUSERXCLIENTS=$HOME/.Xclients
# this will go into the .xsession-errors along with all other echo's # good for debugging where things went wrong echo "$0: Beginning session setup..."
+if [ -f $USERXCLIENTS ] ; then + . $USERXCLIENTS +fi +if [ -f $ALTUSERXCLIENTS ] ; then + . $ALTUSERXCLIENTS +fi + # Translation stuff if [ -x "/usr/lib/gdm/gdmtranslate" ] ; then gdmtranslate="/usr/lib/gdm/gdmtranslate"
Hoffe das hilft ;) Kiro
Hallo,
nur fürs Protokoll: Ein ähnliches Problem gibt es auch bei SuSE (nach einem Update auf KDE 3.4). Mails können verschlüsselt und signiert, aber verschlüsselte Mails nicht angezeigt werden (das openpgp Modul konnte den Text nicht entschlüsseln).
Einfache Lösung (leider nur für jeden Benutzer einzeln):
Ins Verzeichnis ~/.kde/env eine Datei 'gpg-agent.sh" mit
eval "$(gpg-agent --daemon)"
und in ~/.gnupg/gpg.conf ergänzen
pinentry-program /usr/bin/pinentry-qt no-grab default-cache-ttl 1800
Dann funktioniert auch das Entschlüsseln.
Keine Ahnung ob das mit der Standardinstallation von SuSE 9.2 und KDE 3.3 funktioniert hat -- habe vor dem Update auf KDE-3.4 keine verschlüsselte Mail bekommen ...
Gruß Uwe
lug-dd@mailman.schlittermann.de
-
Erik Schanze -
Heiko Schlittermann -
Hilmar Preusse -
Jens Weisse -
Jens Weiße
-
Josef Spillner -
Kiro Zimmer -
Marek Werstak -
Torsten Werner -
Uwe Koloska