From shane at shaneland.co.uk Sat Aug 6 18:35:47 2005 From: shane at shaneland.co.uk (Shane M. Coughlan) Date: Sun Aug 7 00:52:59 2005 Subject: Newbie joins the list Message-ID: <42F4E6E3.6000507@shaneland.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all My first question is: can you tell me where I can download a Windows binary of GPA for my machine? I see the source code on the main site, but don't want to download that. I already have GnuPG installed on my system (along with PGP 6.01i and Enigmail 0.92). I'm interested in helping to further develop GPA, especially from the perspective of promotion of the software, and focusing on improving the end-user experience. Perhaps I could lend a hand with documenation and so on. I'm not a programmer, though I do run a project entitled OpenGEM, which is a 16bit single-tasking GUI for DOS released under the GPL. Regards Shane - -- Shane M. Coughlan BA(hons) MA EMAIL: shane@shaneland.co.uk WEB: www.shaneland.co.uk MSN: shane_coughlan@hotmail.com AOL: ShaneMCoughlan Yahoo: shane_c ICQ: 32280303 - -- "I love deadlines. I like the whooshing sound they make as they fly by." - Douglas Adams - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFC9ObiTa6KuhPvdOoRAsXcAKD0sLplv5yIxlbzt+OMZQ6SofmXOACgyVlf RclaBd4otsyz2kE2wJPgU1U= =lgHr -----END PGP SIGNATURE----- From jan at intevation.de Mon Aug 8 11:45:59 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon Aug 8 12:42:03 2005 Subject: gpa on windows Was: Newbie joins the list In-Reply-To: <42F4E6E3.6000507@shaneland.co.uk> References: <42F4E6E3.6000507@shaneland.co.uk> Message-ID: <20050808094559.GA9399@intevation.de> On Sun, Aug 07, 2005 at 01:35:47AM +0900, Shane M. Coughlan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > My first question is: can you tell me where I can download a Windows > binary of GPA for my machine? I see the source code on the main site, > but don't want to download that. I already have GnuPG installed on my > system (along with PGP 6.01i and Enigmail 0.92). > > I'm interested in helping to further develop GPA, especially from the > perspective of promotion of the software, and focusing on improving > the end-user experience. Perhaps I could lend a hand with > documenation and so on. I'm not a programmer, though I do run a > project entitled OpenGEM, which is a 16bit single-tasking GUI for DOS > released under the GPL. AFAIK, current gpa does not compile on Windows. Am I wrong? Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ Kolab Konsortium http://kolab-konsortium.de/ FreeGIS http://freegis.org/ From lofi at freebsd.org Mon Aug 8 19:54:11 2005 From: lofi at freebsd.org (Michael Nottebrock) Date: Mon Aug 8 20:28:49 2005 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally Message-ID: <200508081954.13221.lofi@freebsd.org> In FreeBSD 6 and later, sys/types.h now also defines the basic pthread types in order to comply with IEEE Std 1003.1-2004. This causes a compile error in gpgme due to conflicting types for pthread_* if pth-support is enabled, since the pth include directory is globally added to CFLAGS and ath-pthread.c picks up the pth-supplied pthread.h header instead of the system include. The attached patch changes gpgme's global configure template and the Makefile template in gpgme/gpgme so that PTH_CFLAGS are only added to the include path where needed. The patch should apply to both the latest gpgme in CVS and gpgme 1.0.x. Cheers, -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /cvs/gnupg/gpgme/configure.ac,v retrieving revision 1.98 diff -u -r1.98 configure.ac --- configure.ac 24 Mar 2005 13:09:54 -0000 1.98 +++ configure.ac 8 Aug 2005 14:37:09 -0000 @@ -120,7 +120,6 @@ AC_CHECK_PTH(1.2.0,,,no,have_pth=yes) if test "$have_pth" = yes; then AC_DEFINE(HAVE_PTH, ,[Define if we have Pth.]) - CFLAGS="$CFLAGS $PTH_CFLAGS" fi AC_CHECK_LIB(pthread,pthread_create,have_pthread=yes) if test "$have_pthread" = yes; then Index: gpgme/Makefile.am =================================================================== RCS file: /cvs/gnupg/gpgme/gpgme/Makefile.am,v retrieving revision 1.56 diff -u -r1.56 Makefile.am --- gpgme/Makefile.am 24 Mar 2005 13:05:12 -0000 1.56 +++ gpgme/Makefile.am 8 Aug 2005 14:37:10 -0000 @@ -99,6 +99,7 @@ AM_CPPFLAGS = $(assuan_cppflags) @GPG_ERROR_CFLAGS@ +libgpgme_la_CFLAGS= ${CFLAGS} @PTH_CFLAGS@ libgpgme_la_LDFLAGS = $(libgpgme_version_script_cmd) -version-info \ @LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@ libgpgme_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \ @@ -113,6 +114,7 @@ libgpgme_pthread_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ -lpthread @GPG_ERROR_LIBS@ +libgpgme_pth_la_CFLAGS = ${CFLAGS} @PTH_CFLAGS@ libgpgme_pth_la_CPPFLAGS = $(AM_CPPFLAGS) @PTH_CPPFLAGS@ libgpgme_pth_la_LDFLAGS = @PTH_LDFLAGS@ \ $(libgpgme_version_script_cmd) -version-info \ From stagger at gmx.net Sat Aug 13 08:47:30 2005 From: stagger at gmx.net (Daniel Link) Date: Sat Aug 13 09:43:24 2005 Subject: Passphrase of GPG-generated key not accepted Message-ID: <42FD9782.7020608@gmx.net> Hi, I have German umlauts (???) and other special characters in my password to increase security. The key itself was created with gpg on a terminal emulator. This is an example key which raises the same problem: ************************************************************************ * ACHTUNG: Diese Datei enth??lt eine Sicherheitskopie Ihres * * geheimen Schl??ssels. * * Bewahren Sie sie an einem sicheren Ort auf. * ************************************************************************ Der in dieser Datei gesicherte Schl??ssel ist: pub 1024D/EECF083D 2005-08-13 [expires: 2005-09-12] Schl.-Fingerabdruck = D225 5118 C06B E863 846D BD0E 0072 5D71 EECF 083D uid Daniel Link (This key is for testing purpose only) sub 2048g/5A4D2532 2005-08-13 [expires: 2005-09-12] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.1 (GNU/Linux) mQGiBEL9j50RBACxrBXPZIcGBk0/Bh2muaRX+cCJ8jHguwUAQGSNGVsL7vSVcpd/ QQpympQ7b0k2dPgiZ9tDfm8SqEu79+YbM7j41GgcbII8MDnaS2xnHJ9dkPTC2Q+G zdiMwoFqAvk4pWwHve5oP+YhXHflBse40jVHpPf3De/ytzkl12RVKHsAMwCguETv U0nVNxI2mmOaOcnbDX+O8YkD/RhXCrd1dfb5Z9hCYQw9hfR0Zybgm7Jfafx9jp+d g67IQyCc5n0MX4JhfTvth9zx+dSquZFIX3uOHsK9kXM56QFZgfi4lFQmYHHmD1l+ cMU+toIHfm1rDFgTMwlJoFh89M2k2BXeZHFvEX/1jFES3/EW4e7iNAbKYhqCJJKN mgbhBACk2Shb0qJFz1Pczz6uxSiBdkEro/9qa3O/QiD4H8sTnV88xpHjVBHQ9OlO pZrjlTwakjfrtB3UbS19N9Ae+pSevHDZ31xsoHKuKYtDZtjU3uw251qUT/Av7EnD +hnvtF/hGZqNeNq6JGZy+45+oD41iEMjGTjt69NCU/0os3XWGLRIRGFuaWVsIExp bmsgKFRoaXMga2V5IGlzIGZvciB0ZXN0aW5nIHB1cnBvc2Ugb25seSkgPGV4YW1w bGVAZXhhbXBsZS5uZXQ+iGQEExECACQFAkL9j50CGwMFCQAnjQAGCwkIBwMCAxUC AwMWAgECHgECF4AACgkQAHJdce7PCD1imwCfZbKVALk3MkvpprQIJ3wjx4505D4A n2BaPEtk/rBJH0u6YJSqlbvYp0C4uQINBEL9j70QCACMErsYMyPp/cQsojYdjQvc 9ZfcR2K/2qXqW9QNGKZnomBUCyyBzCIHcNoUFN9M6VKb8clLIZrQWCa4vacYQeLR lXXwuLcTWy0fabNSTBJqAjGug0mYY18ux/rjYA5xEZL+XLbhzghHP/+BHFJ/nBvd vTaPY9P3wlkoqRywmZMjTMDI4Y3qtrUwE/Y2G10zTR0SVQiONkyr/9Ruackte2eY Vv67Qmc1f6w90tsE+b6CEtzin2mmg1142FNqhsZC0zgav+MQl2sDkWfGOecNveal HZ0ddZXnVl8fKGpP1nBF3clBEAdUCTXG9kWkIMf5NuYFdYd/O1cQ/uTThLWyF1IP AAMFB/sFES/HxNsPumjvaJseUwgd7sn+gsCU1vfyDDn8T9SkDisdn63gdzc1Of9J lmoKuuy0IyxohCZu15dv8iMpis2gMfcDo4G6JXEo1rK6KXjlfpnAjTw0DYyGXdpk A1ilktAxKTgmkMG7iUgSfxliOI3lPCLNzrEDpWxXGct8G4ia6Jqvvl7S+ZozKxej yoK0Qzdd/BlIgz4FwEsQZjXVUfiavBr7sRo7vPRUmse1D8ZLlQoXNX4nQJt7juqi HiYvNg4kbGQ72/AhCm/GQABtHHZhfUPl66t7Qya6ZA5M3/OqP0aPOwWE1cOGUMeU QhIpk4xE6BgsCtWw13RZlKOTB5fWiE8EGBECAA8FAkL9j70CGwwFCQAnjQAACgkQ AHJdce7PCD3C1wCgqk0jkBtZUtSFQdEqzqUmoljIoKsAnArOvcoiHwLCuZPdYyeZ eZAT+N4w =V2E1 -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v1.4.1 (GNU/Linux) lQHhBEL9j50RBACxrBXPZIcGBk0/Bh2muaRX+cCJ8jHguwUAQGSNGVsL7vSVcpd/ QQpympQ7b0k2dPgiZ9tDfm8SqEu79+YbM7j41GgcbII8MDnaS2xnHJ9dkPTC2Q+G zdiMwoFqAvk4pWwHve5oP+YhXHflBse40jVHpPf3De/ytzkl12RVKHsAMwCguETv U0nVNxI2mmOaOcnbDX+O8YkD/RhXCrd1dfb5Z9hCYQw9hfR0Zybgm7Jfafx9jp+d g67IQyCc5n0MX4JhfTvth9zx+dSquZFIX3uOHsK9kXM56QFZgfi4lFQmYHHmD1l+ cMU+toIHfm1rDFgTMwlJoFh89M2k2BXeZHFvEX/1jFES3/EW4e7iNAbKYhqCJJKN mgbhBACk2Shb0qJFz1Pczz6uxSiBdkEro/9qa3O/QiD4H8sTnV88xpHjVBHQ9OlO pZrjlTwakjfrtB3UbS19N9Ae+pSevHDZ31xsoHKuKYtDZtjU3uw251qUT/Av7EnD +hnvtF/hGZqNeNq6JGZy+45+oD41iEMjGTjt69NCU/0os3XWGP4DAwKLqVWljpoh zGCltVnnG/Xbj5meEZ+qHy31kTwLWQsE032EB6S5F9KtHFB9/4VLDFtpxXFX/KKL 6m83wLRIRGFuaWVsIExpbmsgKFRoaXMga2V5IGlzIGZvciB0ZXN0aW5nIHB1cnBv c2Ugb25seSkgPGV4YW1wbGVAZXhhbXBsZS5uZXQ+iGQEExECACQFAkL9j50CGwMF CQAnjQAGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQAHJdce7PCD1imwCeNYUp3w+a eqj95Zcq/XUPGqG0UMsAn3SHyDuZQ8cSKBxDT9FZFZGtoh/VnQJjBEL9j70QCACM ErsYMyPp/cQsojYdjQvc9ZfcR2K/2qXqW9QNGKZnomBUCyyBzCIHcNoUFN9M6VKb 8clLIZrQWCa4vacYQeLRlXXwuLcTWy0fabNSTBJqAjGug0mYY18ux/rjYA5xEZL+ XLbhzghHP/+BHFJ/nBvdvTaPY9P3wlkoqRywmZMjTMDI4Y3qtrUwE/Y2G10zTR0S VQiONkyr/9Ruackte2eYVv67Qmc1f6w90tsE+b6CEtzin2mmg1142FNqhsZC0zga v+MQl2sDkWfGOecNvealHZ0ddZXnVl8fKGpP1nBF3clBEAdUCTXG9kWkIMf5NuYF dYd/O1cQ/uTThLWyF1IPAAMFB/sFES/HxNsPumjvaJseUwgd7sn+gsCU1vfyDDn8 T9SkDisdn63gdzc1Of9JlmoKuuy0IyxohCZu15dv8iMpis2gMfcDo4G6JXEo1rK6 KXjlfpnAjTw0DYyGXdpkA1ilktAxKTgmkMG7iUgSfxliOI3lPCLNzrEDpWxXGct8 G4ia6Jqvvl7S+ZozKxejyoK0Qzdd/BlIgz4FwEsQZjXVUfiavBr7sRo7vPRUmse1 D8ZLlQoXNX4nQJt7juqiHiYvNg4kbGQ72/AhCm/GQABtHHZhfUPl66t7Qya6ZA5M 3/OqP0aPOwWE1cOGUMeUQhIpk4xE6BgsCtWw13RZlKOTB5fW/gMDAoupVaWOmiHM YA1iCtcsuLoM+w0IcLT2mAqmtP0FCVGLFc07Mw560lKKlwOInRwDHso5CWI52slc ZB/xAeOd5CIS9wmE2ndDCioQ+bg7Da1YnRKITwQYEQIADwUCQv2PvQIbDAUJACeN AAAKCRAAcl1x7s8IPcLXAJ9+IseRCdo+E2/Ds2c31ByGgt8P8wCglAlBP5XWv08U 9yhwlqWU/8sJMrU= =yN/i -----END PGP PRIVATE KEY BLOCK-----ins below this line> It will expire in one month. I think this will be enough time to track down the problem. If not, please send an email to my email address _directly_ and I will create a new one as soon as possible. The password is: K3ineK!nderspielengerneFl?te As far as I know I've used the ISO-8859-15 character encoding. This message was also created with that encoding. The version of GPA installed on my computer is 0.7.0-r2. I use GPG 1.4.1 as you can easily see from above. The system is Gentoo Linux. Which encoding does GPA use for backups? The umlaut from "Schl?ssel" which means key isn't displayed correctly (see lines 2, 4 and 9). In addition GPA crashes when I try to backup a key and not enter a filename manually but select file and directory (segfault). I tried but didn't manage to compile from sources with debugging symbols. There's no configure option and I have no idea which file I have to alter / which arguments I have to pass to the compiler to do so. Bye, Daniel Link From albrecht.dress at arcor.de Sat Aug 13 11:50:20 2005 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sat Aug 13 12:41:13 2005 Subject: Passphrase of GPG-generated key not accepted In-Reply-To: <42FD9782.7020608@gmx.net> (from stagger@gmx.net on Sat Aug 13 08:47:30 2005) References: <42FD9782.7020608@gmx.net> Message-ID: <1123926629l.2898l.0l@antares.localdomain> Am 13.08.05 08:47 schrieb(en) Daniel Link: [snip] > As far as I know I've used the ISO-8859-15 character encoding. This > message was also created with that encoding. The version of GPA > installed on my computer is 0.7.0-r2. I use GPG 1.4.1 as you can easily > see from above. The system is Gentoo Linux. > > Which encoding does GPA use for backups? The umlaut from "Schl?ssel" > which means key isn't displayed correctly (see lines 2, 4 and 9). GPA and other applications based upon the Gtk+-2 library (and all kde stuff, btw) use utf8 to encode national characters (basically two chars for german umlauts, as you saw in the outout). As a rule of thumb, if you use your key primarily via a gui application (i.e. you enter the passphrase via gpg-agent and pinentry-{gtk2|qt}), I would suggest to replace the iso8859 encoded passphrase by the same one encoded in utf8. An other option would be to use utf8 encodings in the standard xterm environment as well. I covered that problem in a faq about using encryption with the mua balsa ("I created a key but balsa never accepts my passphrase?"): http://home.arcor.de/dralbrecht.dress/balsa/balsa23-secure-mail.html#FAQ > In addition GPA crashes when I try to backup a key and not enter a > filename manually but select file and directory (segfault). I tried but > didn't manage to compile from sources with debugging symbols. There's no Try to run (assuming you're using bash) CFLAGS="-O0 -g" ./configure rebuild gpa, and then run gpa in gdb. When it crashes, say "bt full" to get a full trace. Hth, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://home.arcor.de/dralbrecht.dress/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050813/8bed4b77/attachment.pgp From stagger at gmx.net Sat Aug 13 13:41:41 2005 From: stagger at gmx.net (Daniel Link) Date: Sat Aug 13 13:37:16 2005 Subject: Passphrase of GPG-generated key not accepted In-Reply-To: <1123926629l.2898l.0l@antares.localdomain> References: <42FD9782.7020608@gmx.net> <1123926629l.2898l.0l@antares.localdomain> Message-ID: <42FDDC75.5080205@gmx.net> > GPA and other applications based upon the Gtk+-2 library (and all kde > stuff, btw) use utf8 to encode national characters (basically two chars > for german umlauts, as you saw in the outout). As a rule of thumb, if > you use your key primarily via a gui application (i.e. you enter the > passphrase via gpg-agent and pinentry-{gtk2|qt}), I would suggest to > replace the iso8859 encoded passphrase by the same one encoded in utf8. > An other option would be to use utf8 encodings in the standard xterm > environment as well. I covered that problem in a faq about using > encryption with the mua balsa ("I created a key but balsa never accepts > my passphrase?"): > http://home.arcor.de/dralbrecht.dress/balsa/balsa23-secure-mail.html#FAQ Wouldn't it be a good idea to include character encoding information in keys? I think so. Many people don't use UTF-8 yet. Demanding such configuration like you mentioned from all these users sounds unreasonable to me. Isn't a workaround possible? Since I use GTK+ applications for quite a while now and never experienced similar problems this would be my solution of choice. Don't ask me about implementation though. Changing the key already sent to key servers and several people from my address book doesn't sound very appealing to me either. Perhaps you'll beg to differ, but in my opinion an application like GPA should work out of the box, no matter which encoding. > CFLAGS="-O0 -g" ./configure > > rebuild gpa, and then run gpa in gdb. When it crashes, say "bt full" to > get a full trace. I've used $ CFLAGS="-O0 -g -O2 -march=pentium4 -fomit-frame-pointer" ./configure \ --prefix=/my/path to configure, compiled GPA and ran it inside the debugger. Here's what it said: (gdb) file /my/path/bin/gpa Reading symbols from /my/path/bin/gpa...done. Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /my/path/bin/gpa Program received signal SIGSEGV, Segmentation fault. 0x0805001a in gpa_window_show_centered (widget=0x827b1d8, parent=0x0) at gtktools.c:47 47 gdk_window_get_origin (parent->window, &parent_x, &parent_y); (gdb) bt full #0 0x0805001a in gpa_window_show_centered (widget=0x827b1d8, parent=0x0) at gtktools.c:47 parent_x = -1209855117 parent_y = 136819160 parent_width = 136819160 parent_height = -1076559632 center_x = 136819160 center_y = 136819512 width = 447 height = 362 child = (GtkWidget *) 0x827b338 #1 0x08050dbf in gpa_get_save_file_name (parent=0xbfd500ac, title=0xbfd500ac "s\023????'\b?\001", directory=0x0) at gtktools.c:432 dialog = {window = 0x827b1d8, filename = 0x0} window = (GtkWidget *) 0x827b1d8 #2 0x08070182 in export_browse (param=0x8108f68) at gpabackupop.c:252 filename = (gchar *) 0x80ef800 "\002" #3 0xb7b25900 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. If you need any more information, feel free to ask. Daniel PS: Please put your own address in CC and the mailing address' in TO. This makes replying easier since one doesn't have to manually change the recipient or choose "Reply to CC" every time. It won't hurt you either, if you don't tend to answer your own messages. From albrecht.dress at arcor.de Sat Aug 13 15:03:19 2005 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sat Aug 13 14:59:25 2005 Subject: Passphrase of GPG-generated key not accepted In-Reply-To: <42FDDC75.5080205@gmx.net> (from stagger@gmx.net on Sat Aug 13 13:41:41 2005) References: <42FD9782.7020608@gmx.net> <1123926629l.2898l.0l@antares.localdomain> <42FDDC75.5080205@gmx.net> Message-ID: <1123938209l.2918l.0l@antares.localdomain> Am 13.08.05 13:41 schrieb(en) Daniel Link: > Wouldn't it be a good idea to include character encoding information in > keys? I think so. RFC 2440, section 3.4 [1] states that "the default character set for text is the UTF-8 encoding". I am not sure if this applies to the messages only and not to the key contents, though. The passphrase, however, is just a "stream of bytes", and no assumption should be made about a "meaning" (read: encoding and possible translation between different ones) of its contents. > Many people don't use UTF-8 yet. I don't think this is true, at least for all gui applications in the UNIX world. KDE (read: the qt library) and Gnome2.x (read: Gtk+-2) are completely and exclusively utf-8. I'm not sure about other popular widget libs (e.g. Motif & friends), but the general trend seems to use utf8 everywhere, maybe except for terminal apps (i.e. xterm). > Demanding such configuration like you mentioned from all these users > sounds unreasonable to me. If you think about the problems regarding the use of gpg (i.e. entering the passphrase) in a terminal, I think the better solution is to install gpg-agent and to use a gui pinentry for this purpose. It (a) removes the encoding problem (b) provides a *secure* passphrase cache and (c) imho makes using the various crypto apps a lot easier. If you don't want to install the whole chain to get the agent running, you might want to look at seahorse [2] which also provides a (simpler) agent solution. I don't know how secure it is, though. > Changing the key already sent to key servers and several people from my > address book doesn't sound very appealing to me either. Afaik, changing the passphrase of your *private* key doesn't alter the contents of the public key in any way. And you don't want to publish your private key ;-)... > Perhaps you'll beg to differ, but in my opinion an application like GPA > should work out of the box, no matter which encoding. Sure it should! However, I think the problem at this point is mixing the use of utf8 applications (gpa, pinentry, seahorse, kmail, balsa, evo, Thunderbird/Enigmail) and iso8859 terminal apps (command line gpg). So, again, if you just use gpg-agent and pinentry-gtk2, you will *never* run into trouble! > $ CFLAGS="-O0 -g -O2 -march=pentium4 -fomit-frame-pointer" ./configure \ ^^^ ^^^^^^^^^^^^^^^^^^^^ Just a remark: you should never activate these optimisations if you want to debug code. On RISC processors (I use a PowerPC), a lot of information may be lost, which is usually prevented by using -O0... > (gdb) bt full > #0 0x0805001a in gpa_window_show_centered (widget=0x827b1d8, > parent=0x0) at gtktools.c:47 [snipped bt] Unfortunately, I'm not a gpa developer. Anyone listening out there? Cheers, Albrecht. [1] http://www.ietf.org/rfc/rfc2440.txt [2] http://seahorse.sourceforge.net/ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://home.arcor.de/dralbrecht.dress/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050813/4d5a2c5b/attachment-0001.pgp From marcus.brinkmann at ruhr-uni-bochum.de Mon Aug 29 14:02:31 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Aug 29 14:58:29 2005 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <200508081954.13221.lofi@freebsd.org> References: <200508081954.13221.lofi@freebsd.org> Message-ID: <87y86l2boo.wl@ulysses.g10code.de> Hi, thanks for your report. At Mon, 8 Aug 2005 19:54:11 +0200, Michael Nottebrock wrote: > This causes a compile error in gpgme due to conflicting types for pthread_* if > pth-support is enabled, since the pth include directory is globally added to > CFLAGS and ath-pthread.c picks up the pth-supplied pthread.h header instead > of the system include. Can you give more details about the compile error, just to know what the actual problem is? (Reports should always include such information). > The attached patch changes gpgme's global configure template and the Makefile > template in gpgme/gpgme so that PTH_CFLAGS are only added to the include path > where needed. The patch should apply to both the latest gpgme in CVS and gpgme > 1.0.x. Does the patch work? From your interpretation of the problem, a compile error should occur in ath-pthread-compat.c, because it will pick up the pth supplied header file rather than the system header file. It seems to me that the pth include directory should only be added to the ath-pth.c and ath-pth-compat.c compilation. Also, $(AM_CFLAGS) should be used instead of ${CFLAGS}, but that is a minor detail. Thanks, Marcus > > Cheers, > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > [2 gpgme-pth-cflags.diff ] > Index: configure.ac > =================================================================== > RCS file: /cvs/gnupg/gpgme/configure.ac,v > retrieving revision 1.98 > diff -u -r1.98 configure.ac > --- configure.ac 24 Mar 2005 13:09:54 -0000 1.98 > +++ configure.ac 8 Aug 2005 14:37:09 -0000 > @@ -120,7 +120,6 @@ > AC_CHECK_PTH(1.2.0,,,no,have_pth=yes) > if test "$have_pth" = yes; then > AC_DEFINE(HAVE_PTH, ,[Define if we have Pth.]) > - CFLAGS="$CFLAGS $PTH_CFLAGS" > fi > AC_CHECK_LIB(pthread,pthread_create,have_pthread=yes) > if test "$have_pthread" = yes; then > Index: gpgme/Makefile.am > =================================================================== > RCS file: /cvs/gnupg/gpgme/gpgme/Makefile.am,v > retrieving revision 1.56 > diff -u -r1.56 Makefile.am > --- gpgme/Makefile.am 24 Mar 2005 13:05:12 -0000 1.56 > +++ gpgme/Makefile.am 8 Aug 2005 14:37:10 -0000 > @@ -99,6 +99,7 @@ > > AM_CPPFLAGS = $(assuan_cppflags) @GPG_ERROR_CFLAGS@ > > +libgpgme_la_CFLAGS= ${CFLAGS} @PTH_CFLAGS@ > libgpgme_la_LDFLAGS = $(libgpgme_version_script_cmd) -version-info \ > @LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@ > libgpgme_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \ > @@ -113,6 +114,7 @@ > libgpgme_pthread_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ > -lpthread @GPG_ERROR_LIBS@ > > +libgpgme_pth_la_CFLAGS = ${CFLAGS} @PTH_CFLAGS@ > libgpgme_pth_la_CPPFLAGS = $(AM_CPPFLAGS) @PTH_CPPFLAGS@ > libgpgme_pth_la_LDFLAGS = @PTH_LDFLAGS@ \ > $(libgpgme_version_script_cmd) -version-info \ > [3 ] > _______________________________________________ > Gpa-dev mailing list > Gpa-dev@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gpa-dev From lofi at freebsd.org Mon Aug 29 20:49:54 2005 From: lofi at freebsd.org (Michael Nottebrock) Date: Mon Aug 29 20:50:15 2005 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <87y86l2boo.wl@ulysses.g10code.de> References: <200508081954.13221.lofi@freebsd.org> <87y86l2boo.wl@ulysses.g10code.de> Message-ID: <200508292050.00477.lofi@freebsd.org> On Monday, 29. August 2005 14:02, Marcus Brinkmann wrote: > Hi, > > thanks for your report. > > At Mon, 8 Aug 2005 19:54:11 +0200, > > Michael Nottebrock wrote: > > This causes a compile error in gpgme due to conflicting types for > > pthread_* if pth-support is enabled, since the pth include directory is > > globally added to CFLAGS and ath-pthread.c picks up the pth-supplied > > pthread.h header instead of the system include. > > Can you give more details about the compile error, just to know what > the actual problem is? (Reports should always include such > information). ?cc -DHAVE_CONFIG_H -I. -I. -I.. -I../assuan -I/usr/local/include -O2 -pipe -march=athlon-xp -I/usr/local/include/pth -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c ?-fPIC -DPIC -o .libs/ath-pthread.o In file included from ath-pthread.c:36: /usr/local/include/pth/pthread.h:285: error: conflicting types for 'pthread_t' /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of 'pthread_t' was here /usr/local/include/pth/pthread.h:286: error: conflicting types for 'pthread_attr_t' /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of 'pthread_attr_t' was here /usr/local/include/pth/pthread.h:288: error: conflicting types for 'pthread_once_t' /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of 'pthread_once_t' was here /usr/local/include/pth/pthread.h:289: error: conflicting types for 'pthread_mutexattr_t' /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of 'pthread_mutexattr_t' was here /usr/local/include/pth/pthread.h:290: error: conflicting types for 'pthread_mutex_t' /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of 'pthread_mutex_t' was here /usr/local/include/pth/pthread.h:291: error: conflicting types for 'pthread_condattr_t' /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of 'pthread_condattr_t' was here /usr/local/include/pth/pthread.h:292: error: conflicting types for 'pthread_cond_t' /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of 'pthread_cond_t' was here /usr/local/include/pth/pthread.h:293: error: conflicting types for 'pthread_rwlockattr_t' /usr/include/sys/_pthreadtypes.h:73: error: previous declaration of 'pthread_rwlockattr_t' was here /usr/local/include/pth/pthread.h:294: error: conflicting types for 'pthread_rwlock_t' /usr/include/sys/_pthreadtypes.h:72: error: previous declaration of 'pthread_rwlock_t' was here ath-pthread.c: In function `_gpgme_ath_connect': ath-pthread.c:161: warning: passing arg 2 of `__pthread_connect' discards qualifiers from pointer target type > > The attached patch changes gpgme's global configure template and the > > Makefile template in gpgme/gpgme so that PTH_CFLAGS are only added to the > > include path where needed. The patch should apply to both the latest > > gpgme in CVS and gpgme 1.0.x. > > Does the patch work? > From your interpretation of the problem, a > compile error should occur in ath-pthread-compat.c, because it will > pick up the pth supplied header file rather than the system header > file. It's been a while - I tend to agree that ath-pthread-compat.c should fail as well, but for some reason it apparently doesn't. Then again, I didn't (and still don't) have access to a FreeBSD 6 system myself, but the the patches to gpgme/Makefile.in of the 1.0.2 distribution tarball which I produced with the patch against CVS I were confirmed to be working by the person who reported the error to me. Fun. > It seems to me that the pth include directory should only be added to > the ath-pth.c and ath-pth-compat.c compilation. Yes, that would probably be best. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20050829/300775b6/attachment.pgp