From nix@go-nix.ca Sun Jul 1 17:10:16 2007 From: nix@go-nix.ca (Gabriel Schulhof) Date: Sun, 1 Jul 2007 19:10:16 +0300 (EEST) Subject: [OTR-dev] Hang during key generation Message-ID: <60587.88.113.2.57.1183306216.squirrel@go-nix.ca> Hi! I've started to hack on a Maemo port for pidgin-otr, and I've run into my first hurdle: When I push the "Generate" button int the config dialog, it causes Pidgin to hang. I have stepped through both pidgin-otr and libotr and the crucial call seems to be privkey.c:414: gcry_pk_genkey(&key, parms); This hangs in such a way that there's no CPU activity and, when I interrupt the process, it tells me it's inside select() - so, waiting for events, I assume. Now, I realize that's inside libgcrypt and not libotr, but I'm just wondering if someone on this list has encountered this behaviour before, and if so, what the resolution towards successful key creation was. TIA for your help, Gabriel From nix@go-nix.ca Sun Jul 1 19:59:41 2007 From: nix@go-nix.ca (Gabriel Schulhof) Date: Sun, 1 Jul 2007 21:59:41 +0300 (EEST) Subject: [OTR-dev] Patch: cleaner account option menu Message-ID: <61350.88.113.2.57.1183316381.squirrel@go-nix.ca> ------=_20070701215941_81803 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi! The attached patch makes use of the functions pidgin_account_option_menu_get_selected() and g_signal_emit_by_name() to greatly reduce the code required for dealing with pidgin-otr's accounts combo. HTH, Gabriel ------=_20070701215941_81803 Content-Type: text/x-patch; name="omgp.account-menu-fix.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="omgp.account-menu-fix.diff" # # # patch "gtk-ui.c" # from [831f68d60dc135d10615c46388e95a820424057f] # to [600941da16248aa38facf4b4a73399a296a76e5c] # ============================================================ --- gtk-ui.c 831f68d60dc135d10615c46388e95a820424057f +++ gtk-ui.c 600941da16248aa38facf4b4a73399a296a76e5c @@ -101,16 +101,6 @@ static void account_menu_changed_cb(GtkW } } -static GtkWidget *accountmenu_get_selected_item(void) -{ - GtkWidget *menu; - - if (ui_layout.accountmenu == NULL) return NULL; - - menu = gtk_option_menu_get_menu(GTK_OPTION_MENU(ui_layout.accountmenu)); - return gtk_menu_get_active(GTK_MENU(menu)); -} - static PurpleAccount *item_get_account(GtkWidget *item) { if (!item) return NULL; @@ -121,22 +111,10 @@ static void otrg_gtk_ui_update_fingerpri * UI, if visible. */ static void otrg_gtk_ui_update_fingerprint(void) { - GtkWidget *item; - PurpleAccount *account; - gpointer user_data; - - item = accountmenu_get_selected_item(); - - if (!item) return; - - account = item_get_account(item); - user_data = g_object_get_data(G_OBJECT(ui_layout.accountmenu), - "user_data"); - - account_menu_changed_cb(item, account, user_data); + g_signal_emit_by_name(G_OBJECT(ui_layout.accountmenu), "changed"); } -static void account_menu_added_removed_cb(PurpleAccount *account, void *data) +static void account_menu_added_removed_cb(PurpleAccount *account, GtkWidget *accountmenu) { otrg_gtk_ui_update_fingerprint(); } @@ -214,10 +192,10 @@ static void otrg_gtk_ui_update_keylist(v } -static void generate(GtkWidget *widget, gpointer data) +static void generate(GtkWidget *widget, GtkWidget *account_menu) { PurpleAccount *account; - account = item_get_account(accountmenu_get_selected_item()); + account = pidgin_account_option_menu_get_selected(account_menu); if (account == NULL) return; @@ -545,10 +523,10 @@ static void make_privkeys_ui(GtkWidget * * been added or removed */ purple_signal_connect(purple_accounts_get_handle(), "account-added", ui_layout.accountmenu, - PURPLE_CALLBACK(account_menu_added_removed_cb), NULL); + PURPLE_CALLBACK(account_menu_added_removed_cb), ui_layout.accountmenu); purple_signal_connect(purple_accounts_get_handle(), "account-removed", ui_layout.accountmenu, - PURPLE_CALLBACK(account_menu_added_removed_cb), NULL); + PURPLE_CALLBACK(account_menu_added_removed_cb), ui_layout.accountmenu); ui_layout.fprint_label = gtk_label_new(""); gtk_label_set_selectable(GTK_LABEL(ui_layout.fprint_label), 1); @@ -557,7 +535,7 @@ static void make_privkeys_ui(GtkWidget * ui_layout.generate_button = gtk_button_new(); gtk_signal_connect(GTK_OBJECT(ui_layout.generate_button), "clicked", - GTK_SIGNAL_FUNC(generate), NULL); + GTK_SIGNAL_FUNC(generate), ui_layout.accountmenu); label = gtk_label_new("Generate"); gtk_container_add(GTK_CONTAINER(ui_layout.generate_button), label); ------=_20070701215941_81803-- From nix@go-nix.ca Sun Jul 1 20:24:03 2007 From: nix@go-nix.ca (Gabriel Schulhof) Date: Sun, 1 Jul 2007 22:24:03 +0300 (EEST) Subject: [OTR-dev] (Better) patch: cleaner account option menu In-Reply-To: <61350.88.113.2.57.1183316381.squirrel@go-nix.ca> References: <61350.88.113.2.57.1183316381.squirrel@go-nix.ca> Message-ID: <61449.88.113.2.57.1183317843.squirrel@go-nix.ca> ------=_20070701222403_88974 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi! Always happens ... please find a lower-impact patch attached. HTH, Gabriel ------=_20070701222403_88974 Content-Type: text/x-patch; name="omgp.account-menu-fix.minimal.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="omgp.account-menu-fix.minimal.diff" # # # patch "gtk-ui.c" # from [831f68d60dc135d10615c46388e95a820424057f] # to [298618f95127ca4f6df201b326c6c9b11be894cd] # ============================================================ --- gtk-ui.c 831f68d60dc135d10615c46388e95a820424057f +++ gtk-ui.c 298618f95127ca4f6df201b326c6c9b11be894cd @@ -101,16 +101,6 @@ static void account_menu_changed_cb(GtkW } } -static GtkWidget *accountmenu_get_selected_item(void) -{ - GtkWidget *menu; - - if (ui_layout.accountmenu == NULL) return NULL; - - menu = gtk_option_menu_get_menu(GTK_OPTION_MENU(ui_layout.accountmenu)); - return gtk_menu_get_active(GTK_MENU(menu)); -} - static PurpleAccount *item_get_account(GtkWidget *item) { if (!item) return NULL; @@ -121,19 +111,7 @@ static void otrg_gtk_ui_update_fingerpri * UI, if visible. */ static void otrg_gtk_ui_update_fingerprint(void) { - GtkWidget *item; - PurpleAccount *account; - gpointer user_data; - - item = accountmenu_get_selected_item(); - - if (!item) return; - - account = item_get_account(item); - user_data = g_object_get_data(G_OBJECT(ui_layout.accountmenu), - "user_data"); - - account_menu_changed_cb(item, account, user_data); + g_signal_emit_by_name(G_OBJECT(ui_layout.accountmenu), "changed"); } static void account_menu_added_removed_cb(PurpleAccount *account, void *data) @@ -217,7 +195,7 @@ static void generate(GtkWidget *widget, static void generate(GtkWidget *widget, gpointer data) { PurpleAccount *account; - account = item_get_account(accountmenu_get_selected_item()); + account = pidgin_account_option_menu_get_selected(ui_layout.accountmenu); if (account == NULL) return; ------=_20070701222403_88974-- From nix@go-nix.ca Sun Jul 1 20:35:46 2007 From: nix@go-nix.ca (Gabriel Schulhof) Date: Sun, 1 Jul 2007 22:35:46 +0300 (EEST) Subject: [OTR-dev] (Better) patch: cleaner account option menu In-Reply-To: <61449.88.113.2.57.1183317843.squirrel@go-nix.ca> References: <61350.88.113.2.57.1183316381.squirrel@go-nix.ca> <61449.88.113.2.57.1183317843.squirrel@go-nix.ca> Message-ID: <61506.88.113.2.57.1183318546.squirrel@go-nix.ca> ------=_20070701223546_12887 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi! Forgot to remove item_get_account(). Sorry. Gabriel ------=_20070701223546_12887 Content-Type: text/x-patch; name="omgp.account-menu-fix.minimal.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="omgp.account-menu-fix.minimal.diff" # # # patch "gtk-ui.c" # from [831f68d60dc135d10615c46388e95a820424057f] # to [34a58c51c5ae928fd03102455c87fae6bc2c83a6] # ============================================================ --- gtk-ui.c 831f68d60dc135d10615c46388e95a820424057f +++ gtk-ui.c 34a58c51c5ae928fd03102455c87fae6bc2c83a6 @@ -101,39 +101,11 @@ static void account_menu_changed_cb(GtkW } } -static GtkWidget *accountmenu_get_selected_item(void) -{ - GtkWidget *menu; - - if (ui_layout.accountmenu == NULL) return NULL; - - menu = gtk_option_menu_get_menu(GTK_OPTION_MENU(ui_layout.accountmenu)); - return gtk_menu_get_active(GTK_MENU(menu)); -} - -static PurpleAccount *item_get_account(GtkWidget *item) -{ - if (!item) return NULL; - return g_object_get_data(G_OBJECT(item), "account"); -} - /* Call this function when the DSA key is updated; it will redraw the * UI, if visible. */ static void otrg_gtk_ui_update_fingerprint(void) { - GtkWidget *item; - PurpleAccount *account; - gpointer user_data; - - item = accountmenu_get_selected_item(); - - if (!item) return; - - account = item_get_account(item); - user_data = g_object_get_data(G_OBJECT(ui_layout.accountmenu), - "user_data"); - - account_menu_changed_cb(item, account, user_data); + g_signal_emit_by_name(G_OBJECT(ui_layout.accountmenu), "changed"); } static void account_menu_added_removed_cb(PurpleAccount *account, void *data) @@ -217,7 +189,7 @@ static void generate(GtkWidget *widget, static void generate(GtkWidget *widget, gpointer data) { PurpleAccount *account; - account = item_get_account(accountmenu_get_selected_item()); + account = pidgin_account_option_menu_get_selected(ui_layout.accountmenu); if (account == NULL) return; ------=_20070701223546_12887-- From ian@cypherpunks.ca Sun Jul 1 22:22:26 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 1 Jul 2007 17:22:26 -0400 Subject: [OTR-dev] Hang during key generation In-Reply-To: <60587.88.113.2.57.1183306216.squirrel@go-nix.ca> References: <60587.88.113.2.57.1183306216.squirrel@go-nix.ca> Message-ID: <20070701212226.GA5757@yoink.cs.uwaterloo.ca> On Sun, Jul 01, 2007 at 07:10:16PM +0300, Gabriel Schulhof wrote: > Hi! > > I've started to hack on a Maemo port for pidgin-otr, and I've run into my > first hurdle: > > When I push the "Generate" button int the config dialog, it causes Pidgin > to hang. I have stepped through both pidgin-otr and libotr and the crucial > call seems to be > > privkey.c:414: gcry_pk_genkey(&key, parms); > > This hangs in such a way that there's no CPU activity and, when I > interrupt the process, it tells me it's inside select() - so, waiting for > events, I assume. Now, I realize that's inside libgcrypt and not libotr, > but I'm just wondering if someone on this list has encountered this > behaviour before, and if so, what the resolution towards successful key > creation was. > > TIA for your help, It's gathering randomness from /dev/random. Normally, the kernel will block reads until some randomish events happen (mouse moves, disk reads, etc.). I don't know what the Maemo does for randomness. If all else fails, change libgcrypt to read from /dev/urandom instead; you'll get cryptographic randomness instead of entropic randomness, but in all honesty, that's usually good enough. - Ian From ian@cypherpunks.ca Sun Jul 1 22:25:20 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 1 Jul 2007 17:25:20 -0400 Subject: [OTR-dev] (Better) patch: cleaner account option menu In-Reply-To: <61506.88.113.2.57.1183318546.squirrel@go-nix.ca> References: <61350.88.113.2.57.1183316381.squirrel@go-nix.ca> <61449.88.113.2.57.1183317843.squirrel@go-nix.ca> <61506.88.113.2.57.1183318546.squirrel@go-nix.ca> Message-ID: <20070701212520.GB5757@yoink.cs.uwaterloo.ca> On Sun, Jul 01, 2007 at 10:35:46PM +0300, Gabriel Schulhof wrote: > Hi! > > Forgot to remove item_get_account(). Sorry. Thanks. I'll check it out. - Ian From nix@go-nix.ca Mon Jul 2 05:10:15 2007 From: nix@go-nix.ca (Gabriel Schulhof) Date: Mon, 2 Jul 2007 07:10:15 +0300 (EEST) Subject: [OTR-dev] Hang during key generation In-Reply-To: <20070701212226.GA5757@yoink.cs.uwaterloo.ca> References: <60587.88.113.2.57.1183306216.squirrel@go-nix.ca> <20070701212226.GA5757@yoink.cs.uwaterloo.ca> Message-ID: <60537.88.113.2.57.1183349415.squirrel@go-nix.ca> Hi! On Mon, July 2, 2007 00:22, Ian Goldberg wrote: > It's gathering randomness from /dev/random. Normally, the kernel will > block reads until some randomish events happen (mouse moves, disk reads, > etc.). That's what I figured out later on. I also found that libgcrypt can be passed a progress function pointer that is then called with parameters indicating what libgcrypt needs and what it's doing and how complete it is: void gcry_set_progress_handler (gcry_handler_progress_t CB, void *CB_DATA); where void (*gcry_handler_progress_t) (void *, const char *, int, int, int); I'm thinking about putting a wrapper for this mechanism into libotr, so I can in turn pass a function pointer to libotr and not only make the "Please wait" dialog responsive (by executing while(g_main_context_iteration(NULL, FALSE)); inside the progress handler), but also maybe add a "Cancel" option. However, before I proceed I need to study the code for both pidgin-otr and libotr a little further, because I need to see all the uses pidgin-otr makes of libotr and which of those uses involve long operations. I also need to see just how often libgcrypt calls the progress handler, since libgcrypt itself doesn't do the select() inside a main loop :o( I will try to experiment with these things. If the progress indicator works as advertised, it might even tell what kinds of things are considered sources of randomness on Maemo. Cheers, Gabriel From ian@cypherpunks.ca Sat Jul 7 21:13:25 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 7 Jul 2007 16:13:25 -0400 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <45CF4F8D.60308@gmx.net> References: <45CF4F8D.60308@gmx.net> Message-ID: <20070707201325.GU5757@yoink.cs.uwaterloo.ca> On Sun, Feb 11, 2007 at 06:17:01PM +0100, Thomas B. wrote: > A few days ago, there was a discussion on otr-users about the > translation of OTR, and I've commited to implement > internationalisation support. Here's the first result: I've attached a > tarball containing a patch with the changes I made to gaim-otr and > also some new files that should go into the new po/ subdirectory. I > was able to compile and run the patched gaim-otr on my Ubuntu 6.10 > system with a Gaim 2.0.0beta6 (compiled from source) as well as on > Windows (see below). Please test it for yourselves and send me results > and comments. So that people are aware: I just i18n'd pidgin-otr (based on this patch). There are still constant strings in libotr, and the plan is still to turn those into enums that the application will be responsible for displaying. That should happen for 4.0.0, but there is likely to be a 3.1.0 pretty soon, with pidgin-otr, but not libotr, i18n'd. - Ian From donny.viszneki@gmail.com Tue Jul 17 04:15:49 2007 From: donny.viszneki@gmail.com (Donny Viszneki) Date: Mon, 16 Jul 2007 23:15:49 -0400 Subject: [OTR-dev] gmail spam Message-ID: <44acbb800707162015g7613ec6fia794ba67eef50afc@mail.gmail.com> Just thought I'd point out that Gmail has begun marking some OTR-dev mailing list messages as spam. The list is at the URL below so you can make sure your spam filter isn't hitting OTR-dev too: http://metascape.afraid.org:13666/~donny/gmail-otr-spam.png From ian@cypherpunks.ca Tue Jul 17 23:15:19 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jul 2007 18:15:19 -0400 Subject: [OTR-dev] gmail spam In-Reply-To: <44acbb800707162015g7613ec6fia794ba67eef50afc@mail.gmail.com> References: <44acbb800707162015g7613ec6fia794ba67eef50afc@mail.gmail.com> Message-ID: <20070717221519.GV3751@yoink.cs.uwaterloo.ca> On Mon, Jul 16, 2007 at 11:15:49PM -0400, Donny Viszneki wrote: > Just thought I'd point out that Gmail has begun marking some OTR-dev > mailing list messages as spam. The list is at the URL below so you can > make sure your spam filter isn't hitting OTR-dev too: > > http://metascape.afraid.org:13666/~donny/gmail-otr-spam.png I don't use gmail; is there a way to tell why gmail thinks otr-dev is spam? - Ian From nikita@uiuc.edu Tue Jul 17 23:28:44 2007 From: nikita@uiuc.edu (Nikita Borisov) Date: Tue, 17 Jul 2007 17:28:44 -0500 Subject: [OTR-dev] gmail spam In-Reply-To: <20070717221519.GV3751@yoink.cs.uwaterloo.ca> References: <44acbb800707162015g7613ec6fia794ba67eef50afc@mail.gmail.com> <20070717221519.GV3751@yoink.cs.uwaterloo.ca> Message-ID: <16f0378d0707171528l384ff092gc472c65ab5da1557@mail.gmail.com> On 7/17/07, Ian Goldberg wrote: > I don't use gmail; is there a way to tell why gmail thinks otr-dev is > spam? Not really, it's "magic". I think it's personalized based on your incoming mail, though -- otr-dev wasn't marked as spam for me. - Nikita -- Nikita Borisov - http://www.crhc.uiuc.edu/~nikita/ Assistant Professor, Electrical and Computer Engineering Tel: (217) 244-5385, Office: 460 CSL From cactusthesaint@yahoo.com Tue Jul 17 23:34:10 2007 From: cactusthesaint@yahoo.com (Cactus The Saint) Date: Tue, 17 Jul 2007 15:34:10 -0700 (PDT) Subject: [OTR-dev] gmail spam Message-ID: <993168.32745.qm@web55205.mail.re4.yahoo.com> FWIW, Yahoo mail often marks [OTR-dev] as spam as well. ----- Original Message ---- From: Ian Goldberg To: otr-dev@lists.cypherpunks.ca Sent: Tuesday, July 17, 2007 3:15:19 PM Subject: Re: [OTR-dev] gmail spam On Mon, Jul 16, 2007 at 11:15:49PM -0400, Donny Viszneki wrote: > Just thought I'd point out that Gmail has begun marking some OTR-dev > mailing list messages as spam. The list is at the URL below so you can > make sure your spam filter isn't hitting OTR-dev too: > > http://metascape.afraid.org:13666/~donny/gmail-otr-spam.png I don't use gmail; is there a way to tell why gmail thinks otr-dev is spam? - Ian _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From stpeter@jabber.org Tue Jul 17 23:40:12 2007 From: stpeter@jabber.org (Peter Saint-Andre) Date: Tue, 17 Jul 2007 16:40:12 -0600 Subject: [OTR-dev] gmail spam In-Reply-To: <993168.32745.qm@web55205.mail.re4.yahoo.com> References: <993168.32745.qm@web55205.mail.re4.yahoo.com> Message-ID: <469D454C.1090100@jabber.org> This is a cryptographically signed message in MIME format. --------------ms050106000503000507080908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cactus The Saint wrote: > On Mon, Jul 16, 2007 at 11:15:49PM -0400, Donny Viszneki wrote: >> Just thought I'd point out that Gmail has begun marking some OTR-dev >> mailing list messages as spam. > > FWIW, Yahoo mail often marks [OTR-dev] as spam as well. > The paranoid among us might conclude that perhaps Yahoo and Google don't want people sending encrypted messages through their services. ;-) /psa --------------ms050106000503000507080908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzE3MjI0MDEyWjAjBgkqhkiG9w0BCQQxFgQUHxHLmwwiiYrkf9x4uBmzZQJnkeYwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAL1Am+637N3/h0eFEqGCDUfbzFsmp1msjWEFD+8v3qFtRdx7/ 4HQYe16NBhl8t0vJYKuPFZvpa+GjtkluHoashaBi0Wpu89GJIMTgQ8fHoS7arXLgl6jn2hPb pbPcbtumlvQPzPyV1+ewacFISYY71/KrYcvIEGz9FIH68JGFt9I/cuEBDvbAFyESp4zu7wHC W0hbkkvBIsoCkrB1+lkSf09vOGinH7fmLRDkW7L+oy6dSzTxG3j4/opgo+ndNBWpyTUZz5pZ kn74lEMfge5cWt6HeJ0oaXG6AmoS/LaJZgv08+3qskfEDRh/DT7HJ9iK3WVaq58cmjyFNA4s 54ZIWQAAAAAAAA== --------------ms050106000503000507080908-- From aoeuid@gmail.com Tue Jul 17 23:50:03 2007 From: aoeuid@gmail.com (Andri) Date: Wed, 18 Jul 2007 01:50:03 +0300 Subject: [OTR-dev] gmail spam In-Reply-To: <16f0378d0707171528l384ff092gc472c65ab5da1557@mail.gmail.com> References: <44acbb800707162015g7613ec6fia794ba67eef50afc@mail.gmail.com> <20070717221519.GV3751@yoink.cs.uwaterloo.ca> <16f0378d0707171528l384ff092gc472c65ab5da1557@mail.gmail.com> Message-ID: <469D479B.2000902@gmail.com> Nikita Borisov wrote: > On 7/17/07, Ian Goldberg wrote: >> I don't use gmail; is there a way to tell why gmail thinks otr-dev is >> spam? > > Not really, it's "magic". I think it's personalized based on your > incoming mail, though -- otr-dev wasn't marked as spam for me. > > - Nikita I've occasionally found both messages to this list and to the NFS list in my GMails SPAMbox. I'm certain this is because any encryption to personal messages makes it harder for Google to collect private information and design The Matrix in the future ;) And NFS is just in the way of bringing GoogleFS to the masses! Perhaps someone has been actively marking some list-messages as SPAM, and GMail, in its trusting state, applied similar conclusions to the messages of others. Even though the possibility of false-positives is big, it seems like a smart way to design SPAM-filters used by many. Spamrank, if you will. From aoeuid@gmail.com Wed Jul 18 07:58:45 2007 From: aoeuid@gmail.com (Andri) Date: Wed, 18 Jul 2007 09:58:45 +0300 Subject: [OTR-dev] gmail spam In-Reply-To: <44acbb800707172031t3a13c316h3362ead78fe6f763@mail.gmail.com> References: <44acbb800707162015g7613ec6fia794ba67eef50afc@mail.gmail.com> <20070717221519.GV3751@yoink.cs.uwaterloo.ca> <16f0378d0707171528l384ff092gc472c65ab5da1557@mail.gmail.com> <469D479B.2000902@gmail.com> <44acbb800707172031t3a13c316h3362ead78fe6f763@mail.gmail.com> Message-ID: <469DBA25.7090708@gmail.com> I've seen the mentioned lists marked as SPAM long before I heard the news about Hotmail's CAPTCHAs. But SPAM *has* changed its tactics -- I've even seen subjects similar to Bugzilla bugreports now. Like geeks are the perfect target for body-part enlargement ads. Or maybe they were about dating services... didn't check. Would make more sense though :) I've also pressed the "Not spam" button for each misplaced message, hoping that GMail would learn. But who knows -- it's a closed source system :P Donny Viszneki wrote: > Matrix and Skynet aside, I think most email servers are marking spam > more often because Microsoft and Yahoo captchas have recently been > compromised, increasing the amount of total spam out there. It costs > money to filter it all, the most cost effective way has been to > identify abusive email sources, but you can't just blacklist Hotmail > and Yahoo. > > Maybe Gmail and/or Yahoo have a "whitelist" feature? > > On 7/17/07, Andri wrote: >> Nikita Borisov wrote: >> > On 7/17/07, Ian Goldberg wrote: >> >> I don't use gmail; is there a way to tell why gmail thinks otr-dev is >> >> spam? >> > >> > Not really, it's "magic". I think it's personalized based on your >> > incoming mail, though -- otr-dev wasn't marked as spam for me. >> > >> > - Nikita >> >> I've occasionally found both messages to this list and to the NFS list >> in my >> GMails SPAMbox. >> I'm certain this is because any encryption to personal messages makes >> it harder >> for Google to collect private information and design The Matrix in the >> future ;) >> And NFS is just in the way of bringing GoogleFS to the masses! >> >> Perhaps someone has been actively marking some list-messages as SPAM, >> and GMail, >> in its trusting state, applied similar conclusions to the messages of >> others. >> Even though the possibility of false-positives is big, it seems like a >> smart way >> to design SPAM-filters used by many. Spamrank, if you will. >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev@lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> > From bdesham@gmail.com Wed Jul 18 14:46:18 2007 From: bdesham@gmail.com (Benjamin Esham) Date: Wed, 18 Jul 2007 13:46:18 +0000 (UTC) Subject: [OTR-dev] Re: [meta] Can we add this mailing list to Gmane? References: <77D4ED68-E317-4DD5-B135-E1C081E488E8@gmail.com> <20070702032346.GE5757@yoink.cs.uwaterloo.ca> Message-ID: Benjamin Esham wrote: > I've gone ahead and added all three lists. OTR-users and -dev are > "non-public", which means that only list subscribers can post through > Gmane. OTR-announce is "read-only", so that no one can post to it through > Gmane. I'm pleased to announce that otr-users, otr-dev, and otr-announce are now available on Gmane as gmane.comp.security.otr.user, .devel, and .announce, respectively. (This is different from the previous announcement in that the list archives are now available through Gmane as well.) Information on using Gmane can be found at http://www.gmane.org and http://www.gmane.org/faq.php. Please note that, as before, you must be a registered user of the mailing lists in order to post. Enjoy! -- Benjamin D. Esham E-mail/Jabber: bdesham@gmail.com | AIM bdesham128 | PGP D676BB9A "Men never do evil so completely and cheerfully as when they do it from religious conviction." — Blaise Pascal From gdt@ir.bbn.com Tue Jul 24 19:19:22 2007 From: gdt@ir.bbn.com (Greg Troxel) Date: Tue, 24 Jul 2007 14:19:22 -0400 Subject: [OTR-dev] finished converstations a bad UI choice! Message-ID: I'm writing, perhaps again, about what I consider to be a serious UI bug with finished conversations. Actual scenario: I have a private conversation with Alice. Both of us use gaim and gaim-otr with jabber. Alice's client is probably set to 'require OTR' for me. At least I've had the same behavior on my end when talking to someone else, when I have 'require OTR' set. I shut down my client. This sends a 'finished' message, putting Alice's client in state finished for me. Alice (who doesn't follow otr-dev and understand the nuances of why it's bad to send cleartext when she might expect encrypted) tries to send something, typing a sentence and hitting return. She gets something like 'message not sent; please cancel or restart' and concludes (correctly!) that the IM system is broken. Now, I realize that sending the message in the clear would be a security problem, as she could expect confidentiality and then not get it. So let me be very clear that I'm not asking for that. There are then two cases: OTR is enabled, with automatic initiation, but not required) Here, we know that OTR recently worked with this peer. So choices are 0) send in clear - dangerous, violates user expectations 1) fail (current behavior) 2) try to initiate, and send message if negotatiation is successful OTR is enabled, with automatic initiation, and further is required) Here, there are two choices 0) send in clear - against stated policy, dangerous 1) fail 2) try to initiate, and send message if negotatiation is successful In the required case, note that these are the same options as in a "not private" state. But in "not private", otr-gaim does option 2, which is useful and what the user expects. In the 'not required' case, option 2 seems preferred - a savvy user can always 'end private' if that's what they want. I have no objection to "Conversation is in state finished; trying to initiate private conversation" message. I realize this is work to change. But does anyone really think that the current behavior is useful and reasonable? To me it's gratuitously difficult when there's a better behavior without security problems. From ian@cypherpunks.ca Tue Jul 24 21:11:04 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 24 Jul 2007 16:11:04 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available Message-ID: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Boy, has this been a long time coming. See what happens when Real Life gets in the way? Luckily, I was recently able to get part of said life to be working on OTR (along with an additional developer). For the impatient: http://otr.cypherpunks.ca/libotr-3.1.0-preview1.tar.gz http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview1.tar.gz [Also on sourceforge's cvs.] The major changes: - Added fragmentation support for large messages - Added an option to turn off logging of OTR conversations - Internationalization of the pidgin-otr part (but not yet the libotr part) - Makefile.static builds pidgin-otr.so with libgcrypt.so linked statically to avoid the libgcrypt multiple-clients bug. (At least on Linux; I can't vouch for how well that Makefile will work on other OSes.) And the coolest one: - Added the ability to authenticate your buddies without ever having to see the word "fingerprint", or an obnoxious string of hex chars. The old "verify fingerprint" dialog is still available behind an "Advanced..." button, if needed (for communicating with old clients, say). Anyone want to help with the i18n translations? Here's the pot file: http://otr.cypherpunks.ca/pidgin-otr.pot Please post as to what language you want to take, so we don't duplicate effort. I've got French lined up, and I think Paul offered Dutch? I seem to remember someone offered German? The point of this preview version is mainly for package maintainers to tell me what I've messed up as far as packaging / portability go. The sooner I get feedback in that area, the sooner the "real" 3.1.0 release will be there. Note that the online help files aren't quite ready yet, but will be in place sometime this week. Have fun! - Ian From paul@cypherpunks.ca Wed Jul 25 18:14:29 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Wed, 25 Jul 2007 13:14:29 -0400 (EDT) Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available In-Reply-To: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-517794320-1185383669=:19193 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 24 Jul 2007, Ian Goldberg wrote: > Anyone want to help with the i18n translations? Here's the pot file: > > http://otr.cypherpunks.ca/pidgin-otr.pot > > Please post as to what language you want to take, so we don't duplicate > effort. I've got French lined up, and I think Paul offered Dutch? > I seem to remember someone offered German? I am covering Dutch, German, Polish and Spanish so far. How should non-ascii text be inputted? Should it use HTML encoding or utf8? (eg should it be ó or ó ? Paul --8323328-517794320-1185383669=:19193-- From ian@cypherpunks.ca Wed Jul 25 19:32:33 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 25 Jul 2007 14:32:33 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available In-Reply-To: References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: <20070725183233.GJ5484@thunk.cs.uwaterloo.ca> On Wed, Jul 25, 2007 at 01:14:29PM -0400, Paul Wouters wrote: > On Tue, 24 Jul 2007, Ian Goldberg wrote: > > > Anyone want to help with the i18n translations? Here's the pot file: > > > > http://otr.cypherpunks.ca/pidgin-otr.pot > > > > Please post as to what language you want to take, so we don't duplicate > > effort. I've got French lined up, and I think Paul offered Dutch? > > I seem to remember someone offered German? > > I am covering Dutch, German, Polish and Spanish so far. How should > non-ascii text be inputted? Should it use HTML encoding or utf8? (eg > should it be ó or ó ? UTF-8. Thanks! - Ian From paul@cypherpunks.ca Wed Jul 25 21:00:37 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Wed, 25 Jul 2007 16:00:37 -0400 (EDT) Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available In-Reply-To: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-276934314-1185393637=:21809 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 24 Jul 2007, Ian Goldberg wrote: > http://otr.cypherpunks.ca/libotr-3.1.0-preview1.tar.gz Spec file needs some minor tweaks. diff attached. rpmlint then still gives the following error: E: libotr binary-or-shlib-defines-rpath /usr/bin/otr_mackey ['/usr/lib64'] E: libotr binary-or-shlib-defines-rpath /usr/bin/otr_sesskeys ['/usr/lib64'] E: libotr binary-or-shlib-defines-rpath /usr/bin/otr_modify ['/usr/lib64'] E: libotr binary-or-shlib-defines-rpath /usr/bin/otr_remac ['/usr/lib64'] E: libotr binary-or-shlib-defines-rpath /usr/bin/otr_parse ['/usr/lib64'] E: libotr binary-or-shlib-defines-rpath /usr/bin/otr_readforge ['/usr/lib64'] I am not sure how to resolve these.... A build in mock succeeded though, so the above is the only error that needs fixing for this package. > http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview1.tar.gz This one failed to configure: checking for libgcrypt-config... /usr/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.2.0... yes checking LIBGCRYPT API version... okay checking for libotr CFLAGS... checking for libotr LIBS... -lotr checking for libotr headers version 3.x >= 3.1.0... found. checking for otrl_message_receiving in -lotr... yes checking for x86_64-redhat-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for EXTRA... configure: error: glib ./configure: line 19127: exit: gtk: numeric argument required ./configure: line 19127: exit: gtk: numeric argument required error: Bad exit status from /var/tmp/rpm-tmp.27228 (%build) I think this is a missing build dependancy which we didn't catch? The configure line used by rpm was: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info Paul --8323328-276934314-1185393637=:21809 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=libotr-3.1.0.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=libotr-3.1.0.diff M2MzDQo8IFZlcnNpb246IDMuMC4wDQotLS0NCj4gVmVyc2lvbjogMy4xLjAN CjVjNQ0KPCBMaWNlbnNlOiBHUEwsIExHUEwNCi0tLQ0KPiBMaWNlbnNlOiBH UEwgYW5kIExHUEwNCjEyYzEyDQo8IFJlcXVpcmVzOiBsaWJnY3J5cHQgPj0g MS4yLjAsIGxpYmdwZy1lcnJvcg0KLS0tDQo+IFJlcXVpcmVzOiBsaWJnY3J5 cHQgPj0gMS4yLjAsIA0KMzVjMzUNCjwgJWNvbmZpZ3VyZSAtLXdpdGgtcGlj DQotLS0NCj4gJWNvbmZpZ3VyZSAtLXdpdGgtcGljIC0tZGlzYWJsZS1ycGF0 aA0KNzFjNzEsNzQNCjwgKiBNb24gT2N0IDE3IDIwMDUgUGF1bCBXb3V0ZXJz IDxwYXVsQGN5cGhlcnB1bmtzLmNhPiAzLjAuMA0KLS0tDQo+ICogV2VkIEp1 bCAyNSAyMDA3IFBhdWwgV291dGVycyA8cGF1bEBjeXBoZXJwdW5rcy5jYT4g My4xLjAtMQ0KPiAtIFVwZ3JhZGVkIHRvIGN1cnJlbnQgdmVyc2lvbg0KPiAN Cj4gKiBNb24gT2N0IDE3IDIwMDUgUGF1bCBXb3V0ZXJzIDxwYXVsQGN5cGhl cnB1bmtzLmNhPiAzLjAuMC0xDQo4MWE4NQ0KPiANCjgzYTg4DQo+IA0KODVh OTENCj4gDQo4OGE5NQ0KPiANCjkwYTk4DQo+IA0KOTJhMTAxDQo+IA0KOTRh MTA0DQo+IA0KOTZhMTA3DQo+IA0KOThhMTEwDQo+IA0KMTAwYTExMw0KPiAN CjEwMmExMTYNCj4gDQoxMDRhMTE5DQo+IA0KMTA4YTEyNA0KPiANCg== --8323328-276934314-1185393637=:21809-- From paul@cypherpunks.ca Wed Jul 25 21:01:19 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Wed, 25 Jul 2007 16:01:19 -0400 (EDT) Subject: [OTR-dev] pidgin-otr.nl.po In-Reply-To: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: On Tue, 24 Jul 2007, Ian Goldberg wrote: Attached is the Dutch translation for gaim-otr. Paul From paul@xelerance.com Wed Jul 25 21:55:11 2007 From: paul@xelerance.com (Paul Wouters) Date: Wed, 25 Jul 2007 16:55:11 -0400 (EDT) Subject: [OTR-dev] pidgin-otr.nl.po In-Reply-To: References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1373854264-1185396911=:22096 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Jul 2007, Paul Wouters wrote: > Subject: [OTR-dev] pidgin-otr.nl.po > > Attached is the Dutch translation for gaim-otr. Hmm, no attachment found? Trying again... Paul --8323328-1373854264-1185396911=:22096 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pidgin-otr.nl.po Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=pidgin-otr.nl.po IyBTT01FIERFU0NSSVBUSVZFIFRJVExFLg0KIyBDb3B5cmlnaHQgKEMpIFlF QVIgVEhFIFBBQ0tBR0UnUyBDT1BZUklHSFQgSE9MREVSDQojIFRoaXMgZmls ZSBpcyBkaXN0cmlidXRlZCB1bmRlciB0aGUgc2FtZSBsaWNlbnNlIGFzIHRo ZSBQQUNLQUdFIHBhY2thZ2UuDQojIEZJUlNUIEFVVEhPUiA8RU1BSUxAQURE UkVTUz4sIFlFQVIuDQojDQojLCBmdXp6eQ0KbXNnaWQgIiINCm1zZ3N0ciAi Ig0KIlByb2plY3QtSWQtVmVyc2lvbjogUEFDS0FHRSBWRVJTSU9OXG4iDQoi UmVwb3J0LU1zZ2lkLUJ1Z3MtVG86IFxuIg0KIlBPVC1DcmVhdGlvbi1EYXRl OiAyMDA3LTA3LTI0IDE1OjQ3LTA0MDBcbiINCiJQTy1SZXZpc2lvbi1EYXRl OiAyMDA3LTA3LTI1IDEyOjQxK0VEVFxuIg0KIkxhc3QtVHJhbnNsYXRvcjog UGF1bCBXb3V0ZXJzIDxwYXVsQGN5cGhlcnB1bmtzLmNhPlxuIg0KIkxhbmd1 YWdlLVRlYW06IExBTkdVQUdFIDxMTEBsaS5vcmc+XG4iDQoiTUlNRS1WZXJz aW9uOiAxLjBcbiINCiJDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJz ZXQ9Q0hBUlNFVFxuIg0KIkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDhi aXRcbiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjkxMyAuLi9ndGstZGlhbG9n LmM6MjA5NQ0KbXNnaWQgIl9XaGF0J3MgdGhpcz8iDQptc2dzdHIgIldhdCBi ZXRla2VudCBkaXQ/Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6OTI0DQptc2dp ZCAiX01vcmUuLi4iDQptc2dzdHIgIk1lZXIuLi4iDQoNCiMuIENyZWF0ZSB0 aGUgQWR2YW5jZWQuLi4gYnV0dG9uLCBhbmQgbGVmdC1qdXN0aWZ5IGl0LiAg VGhpcw0KIy4gKiBpbnZvbHZlcyBhZGRpbmcgdGhlIGJ1dHRvbiwgYW5kIGEg YmxhbmsgbGFiZWwgYXMgYSBzcGFjZXIsIGFuZA0KIy4gKiByZW9yZGVyaW5n IHRoZW0gc28gdGhhdCB0aGV5J3JlIGF0IHRoZSBiZWdpbm5pbmcuDQojOiAu Li9ndGstZGlhbG9nLmM6OTgwDQptc2dpZCAiQWR2YW5jZWQuLi4iDQptc2dz dHIgImdlYXZhbmNlZXJkIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTAyNQ0K bXNnaWQgIkVudGVyIHNlY3JldCBoZXJlIg0KbXNnc3RyICJWb2VyIGRlIGdl aGVpbWUgY29kZSBoaWVyIGluIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTAz MA0KbXNnaWQgIlRoaXMgYnVkZHkgaXMgYWxyZWFkeSBhdXRoZW50aWNhdGVk LiINCm1zZ3N0ciAiRGV6ZSBmcmllbmQgaXMgYWwgZ2UtYXV0aGVudGlmaWNl ZXJkIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTA0OQ0KbXNnaWQgIiINCiJU byBhdXRoZW50aWNhdGUsIHBpY2sgYSBzZWNyZXQga25vd24gb25seSB0byB5 b3UgYW5kIHlvdXIgYnVkZHkuICBFbnRlciB0aGlzICINCiJzZWNyZXQsIHRo ZW4gd2FpdCBmb3IgeW91ciBidWRkeSB0byBlbnRlciBpdCB0b28uICBJZiB0 aGUgc2VjcmV0cyBkb24ndCAiDQoibWF0Y2gsIHRoZW4geW91IG1heSBiZSB0 YWxraW5nIHRvIGFuIGltcG9zdGVyLiINCm1zZ3N0ciAiT20gdGUgYXV0aG9y aXNlcmVuIGRpZW4gamUgZWVuIGdlaGVpbWUgY29kZSB0ZSBiZWRlbmtlbiBk aWUgYWxsZWVuICINCiJqaWogZW4gamUgdnJpZW5kIGtlbm5lbi4gVm9lciBk aXQgZ2VoZWltIGluLCBlbiB3YWNodCBvcCBqZSB2cmllbmQgb20gIg0KImhl dHplbGZkZSB0ZSBkb2VuLiBBbHMgZGUgZ2VoZWltZW4gbmlldCBvdmVyZWVu a29tZW4sIGRhbiBrdW4gamUgdGUgbWFrZW4gIg0KImhlYmJlbiBtZXQgZWVu IGJlZHJpZWdlci4iDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxMDUzDQptc2dp ZCAiIg0KIklmIHlvdXIgYnVkZHkgdXNlcyBtdWx0aXBsZSBJTSBhY2NvdW50 cyBvciBtdWx0aXBsZSBjb21wdXRlcnMsIHlvdSBtYXkgaGF2ZSAiDQoidG8g YXV0aGVudGljYXRlIG11bHRpcGxlIHRpbWVzLiAgSG93ZXZlciwgYXMgbG9u ZyBhcyB0aGV5IHVzZSBhbiBhY2NvdW50IGFuZCAiDQoiY29tcHV0ZXIgdGhh dCB5b3UndmUgc2VlbiBiZWZvcmUsIHlvdSBkb24ndCBuZWVkIHRvIGF1dGhl bnRpY2F0ZSBlYWNoICINCiJpbmRpdmlkdWFsIGNvbnZlcnNhdGlvbi4iDQpt c2dzdHIgIkFscyBqZSB2cmllbmQgbWVlcmRlcmUgSU0gYWNjb3VudHMgb2Yg bWVlcmRlcmUgY29tcHV0ZXJzIGdlYnJ1aWt0LCBrYW4gIg0KImhldCB6aWpu IGRhdCBqZSBtZWVyZGVyZSBrZXJlbiBtb2V0IGF1dGhlbnRpY2VyZW4uIFpv bGFuZyBqZSB2cmllbmQgZWVuIGFjY291bnQgIg0KIiBvZiBlZW4gY29tcHV0 ZXIgZ2VicnVpa3QgZGllIGplIGFsIGVlcmRlciBnZXppZW4gaGVidCwgaG9l ZiBqZSBuaWV0IGVsa2UgIg0KIiBpbmRpdmlkdWVlbCBnZXNwcmVrIGFwYXJ0 IHRlIGF1dGhlbnRpY2VyZW4uIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTA1 OCAuLi9ndGstZGlhbG9nLmM6MTMyMiAuLi9ndGstZGlhbG9nLmM6MTMyNg0K IzogLi4vZ3RrLWRpYWxvZy5jOjE0MjMgLi4vZ3RrLWRpYWxvZy5jOjE1OTAg Li4vZ3RrLWRpYWxvZy5jOjE3NTANCiM6IC4uL2d0ay1kaWFsb2cuYzoxODUw IC4uL2d0ay1kaWFsb2cuYzoxOTM1DQptc2dpZCAiP2xhbmc9ZW4iDQptc2dz dHIgIj9sYW5nPW5sIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTA1OQ0KbXNn aWQgIkNsaWNrIGhlcmUgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgYXV0 aGVudGljYXRpb24gaW4gT1RSLiINCm1zZ3N0ciAiS2xpayBoaWVyIHZvb3Ig bWVlciBpbmZvcm1hdGllIG92ZXIgT1RSIGF1dGhlbnRpY2F0aWUiDQoNCiM6 IC4uL2d0ay1kaWFsb2cuYzoxMDYzDQptc2dpZCAiIg0KIkF1dGhlbnRpY2F0 aW5nIGEgYnVkZHkgaGVscHMgZW5zdXJlIHRoYXQgdGhlIHBlcnNvbiB5b3Ug YXJlIHRhbGtpbmcgdG8gaXMgIg0KIndobyB0aGV5IGNsYWltIHRvIGJlLiIN Cm1zZ3N0ciAiRG9vciBtaWRkZWwgdmFuIGhldCBhdXRoZW50aWNlcmVuIHZh biBlZW4gdnJpZW5kIGt1biBqZSBnZWdhcmFuZGVlcmQgIg0KIndldGVuIGRh dCBkZSBwZXJzb29uIHdhYXJtZWUgamUgcHJhYXQsIGRhYWR3ZXJrZWxpamsg amUgdnJpZW5kIGlzLiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjExMTMNCm1z Z2lkICJBdXRoZW50aWNhdGluZyBCdWRkeSINCm1zZ3N0ciAiVnJpZW5kIGF1 dGhlbnRpY2F0aWUiDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxMTQwDQptc2dp ZCAiQXV0aGVudGljYXRpbmciDQptc2dzdHIgIkF1dGhlbnRpY2VyZW4iDQoN CiM6IC4uL2d0ay1kaWFsb2cuYzoxMjAxDQptc2dpZCAiR2VuZXJhdGluZyBw cml2YXRlIGtleSINCm1zZ3N0ciAiR2VoZWltZSBzbGV1dGVsIGFhbiBoZXQg Z2VuZXJlcmVuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTIwMg0KbXNnaWQg IlBsZWFzZSB3YWl0Ig0KbXNnc3RyICJFZW4gbW9tZW50IGEudS5iLiINCg0K IzogLi4vZ3RrLWRpYWxvZy5jOjEyMTAgLi4vZ3RrLWRpYWxvZy5jOjE2Mjcg Li4vZ3RrLWRpYWxvZy5jOjE2NjQNCiM6IC4uL2d0ay11aS5jOjE3NSAuLi9v dHItcGx1Z2luLmM6MTE1IC4uL290ci1wbHVnaW4uYzoyMTIgLi4vdWkuYzox MTANCm1zZ2lkICJVbmtub3duIg0KbXNnc3RyICIiDQoNCiMuIENyZWF0ZSB0 aGUgUGxlYXNlIFdhaXQuLi4gZGlhbG9nDQojOiAuLi9ndGstZGlhbG9nLmM6 MTIxMw0KIywgYy1mb3JtYXQNCm1zZ2lkICJHZW5lcmF0aW5nIHByaXZhdGUg a2V5IGZvciAlcyAoJXMpLi4uIg0KbXNnc3RyICJHZWhlaW1lIHNsZXV0ZWwg dm9vciAlcyAoJXMpIGFhbiBoZXQgZ2VuZXJlcmVuLi4uIg0KDQojOiAuLi9n dGstZGlhbG9nLmM6MTI1OA0KIywgYy1mb3JtYXQNCm1zZ2lkICIlcyBEb25l LiINCm1zZ3N0ciAiJXMgS2xhYXIiDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzox MzIwDQojLCBjLWZvcm1hdA0KbXNnaWQgIiINCiIlcyBpcyBjb250YWN0aW5n IHlvdSBmcm9tIGFuIHVucmVjb2duaXplZCBjb21wdXRlci4gIFlvdSBzaG91 bGQgPGEgaHJlZj1cIiVzJSINCiJzXCI+YXV0aGVudGljYXRlPC9hPiB0aGlz IGJ1ZGR5LiINCm1zZ3N0ciAiJXMgem9la3QgY29udGFjdCBtZXQgamUgdmFu YWYgZWVuIG9uaGVya2VuYmFyZSBjb21wdXRlci4gSmUga3VudCBoZXQgYmVz dGUgIg0KImRlemUgdnJpZW5kIDxhIGhyZWY9XCIlcyVzXCI+YXV0aGVudGlj ZXJlbjwvYT4uIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTMyNA0KIywgYy1m b3JtYXQNCm1zZ2lkICIiDQoiJXMgaGFzIG5vdCBiZWVuIGF1dGhlbnRpY2F0 ZWQgeWV0LiAgWW91IHNob3VsZCA8YSBocmVmPVwiJXMlcyINCiJcIj5hdXRo ZW50aWNhdGU8L2E+IHRoaXMgYnVkZHkuIg0KbXNnc3RyICIlcyBpcyBub2cg bmlldCBnZS1hdXRoZW50aWNlZXJkLiBKZSBrdW50IGhldCBiZXN0ZSAiDQoi ZGV6ZSB2cmllbmQgPGEgaHJlZj1cIiVzJXNcIj5hdXRoZW50aWNlcmVuPC9h Pi4iDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxMzY1IC4uL2d0ay11aS5jOjc2 DQptc2dpZCAiRmluaXNoZWQiDQptc2dzdHIgIktsYWFyIg0KDQojOiAuLi9n dGstZGlhbG9nLmM6MTM2NiAuLi9ndGstdWkuYzo3NQ0KbXNnaWQgIlByaXZh dGUiDQptc2dzdHIgIkJlc2xvdGVuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6 MTM2NyAuLi9ndGstdWkuYzo3NA0KbXNnaWQgIlVudmVyaWZpZWQiDQptc2dz dHIgIk9uZ2V2ZXJpZmljZWVyZGUiDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzox MzY4IC4uL2d0ay11aS5jOjczDQptc2dpZCAiTm90IHByaXZhdGUiDQptc2dz dHIgIk5pZXQgYmVzbG90ZW4iDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxMzcw DQptc2dpZCAiU3RhcnQgYSBwcml2YXRlIGNvbnZlcnNhdGlvbiINCm1zZ3N0 ciAiU3RhcnQgZWVuIGJlc2xvdGVuIGNvbnZlcnNhdGllIg0KDQojOiAuLi9n dGstZGlhbG9nLmM6MTM3MQ0KbXNnaWQgIlJlZnJlc2ggdGhlIHByaXZhdGUg Y29udmVyc2F0aW9uIg0KbXNnc3RyICJIZXJuaWV1dyBlZW4gYmVzbG90ZW4g Y29udmVyc2F0aWUiDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxMzc1DQptc2dp ZCAiU3RhcnQgX3ByaXZhdGUgY29udmVyc2F0aW9uIg0KbXNnc3RyICJTdGFy dCBfYmVzbG90ZW4gY29udmVyc2F0aWUiDQoNCiM6IC4uL2d0ay1kaWFsb2cu YzoxMzc2DQptc2dpZCAiUmVmcmVzaCBfcHJpdmF0ZSBjb252ZXJzYXRpb24i DQptc2dzdHIgIkhlcm5pZXV3IGJlc2xvdGVuIGNvbnZlcnNhdGllIg0KDQoj OiAuLi9ndGstZGlhbG9nLmM6MTU1NQ0KbXNnaWQgIkkgaGF2ZSBub3QiDQpt c2dzdHIgImlrIGhlYiBuaWV0Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTU1 Ng0KbXNnaWQgIkkgaGF2ZSINCm1zZ3N0ciAiaWsgaGViIg0KDQojOiAuLi9n dGstZGlhbG9nLmM6MTU1OA0KbXNnaWQgIiB2ZXJpZmllZCB0aGF0IHRoaXMg aXMgaW4gZmFjdCB0aGUgY29ycmVjdCINCm1zZ3N0ciAiYmV2ZXN0aWdkIG9m IGRpdCBkYWFkd2Vya2VsaWprIGRlIGNvcnJlY3RlIg0KDQojOiAuLi9ndGst ZGlhbG9nLmM6MTU2Nw0KIywgYy1mb3JtYXQNCm1zZ2lkICJmaW5nZXJwcmlu dCBmb3IgJXMuIg0KbXNnc3RyICJ2aW5nZXJhZmRydWsgaXMgdm9vciAlcy4i DQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxNTc5DQptc2dpZCAiIg0KIlRvIHZl cmlmeSB0aGUgZmluZ2VycHJpbnQsIGNvbnRhY3QgeW91ciBidWRkeSB2aWEg c29tZSA8aT5vdGhlcjwvaT4gIg0KImF1dGhlbnRpY2F0ZWQgY2hhbm5lbCwg c3VjaCBhcyB0aGUgdGVsZXBob25lIG9yIEdQRy1zaWduZWQgZW1haWwuICBF YWNoIG9mICINCiJ5b3Ugc2hvdWxkIHRlbGwgeW91ciBmaW5nZXJwcmludCB0 byB0aGUgb3RoZXIuIg0KbXNnc3RyICIiDQoNCiM6IC4uL2d0ay1kaWFsb2cu YzoxNTgzDQptc2dpZCAiIg0KIklmIGV2ZXJ5dGhpbmcgbWF0Y2hlcyB1cCwg eW91IHNob3VsZCBpbmRpY2F0ZSBpbiB0aGUgYWJvdmUgZGlhbG9nIHRoYXQg eW91ICINCiI8Yj5oYXZlPC9iPiB2ZXJpZmllZCB0aGUgZmluZ2VycHJpbnQu Ig0KbXNnc3RyICJBbHMgYWxsZXMgcHJlY2llcyBrbG9wdCwga3VuIGplIGlu IGhldCBib3ZlbnN0YWFuZGUgZGlhbG9vZ3ZlbnN0ZXIgIg0KImFhbmdldmVu IGRhdCBqZSBkZSB2aW5nZXJhZmRydWsgaGVidCA8Yj5iZXZlc3RpZ2Q8L2I+ LiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE1ODUNCm1zZ2lkICIiDQoiSWYg eW91ciBidWRkeSBoYXMgbW9yZSB0aGFuIG9uZSBJTSBhY2NvdW50LCBvciB1 c2VzIG1vcmUgdGhhbiBvbmUgY29tcHV0ZXIsICINCiJoZSBtYXkgaGF2ZSBt dWx0aXBsZSBmaW5nZXJwcmludHMuIg0KbXNnc3RyICJBbHMgamUgdnJpZW5k IG1lZXJkZXJlIElNIGFjY291bnRzIGhlZWZ0LCBvZiBtZWVyIGRhbiBlZW4g Y29tcHV0ZXIiDQoiZ2VicnVpa3QsIGRhbiBrYW4gaGV0IHppam4gZGF0IGRl IHZyaWVuZCBtZWVyZGVyZSB2aW5nZXJhZmRydWtrZW4gaGVlZnQuIg0KDQoj OiAuLi9ndGstZGlhbG9nLmM6MTU4Nw0KbXNnaWQgIiINCiJIb3dldmVyLCB0 aGUgb25seSB3YXkgYW4gaW1wb3N0ZXIgY291bGQgZHVwbGljYXRlIG9uZSBv ZiB5b3VyIGJ1ZGR5J3MgIg0KImZpbmdlcnByaW50cyBpcyBieSBzdGVhbGlu ZyBpbmZvcm1hdGlvbiBmcm9tIGhlci9oaXMgY29tcHV0ZXIuIg0KbXNnc3Ry ICJFY2h0ZXIsIGRlIGVuaWdlIG1ldGhvZGUgd2Fhcm9wIGVlbiBiZWRyaWVn ZXIgamUgdnJpZW5kJ3MgIg0KInZpbmdlcmFmZHJ1a2tlbiBrYW4gbmFtYWtl biwgaXMgZG9vciBnZWhlaW1lIGluZm9ybWF0aWUgdGUgc3RlbGVuICINCiJ2 YW4gamUgdnJpZW5kJ3MgY29tcHV0ZXIuIg0KDQojOiAuLi9ndGstZGlhbG9n LmM6MTU5MQ0KbXNnaWQgIkNsaWNrIGhlcmUgZm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgZmluZ2VycHJpbnRzLiINCm1zZ3N0ciAiS2xpayBoaWVyIHZv b3IgbWVlciBpbmZvcm1hdGllIG92ZXIgdmluZ2VyYWZkcnVra2VuIg0KDQoj OiAuLi9ndGstZGlhbG9nLmM6MTU5NA0KbXNnaWQgIiINCiJBIDxiPmZpbmdl cnByaW50PC9iPiBpcyBhIHVuaXF1ZSBpZGVudGlmaWVyIHRoYXQgeW91IHNo b3VsZCB1c2UgdG8gIg0KImF1dGhlbnRpY2F0ZSB5b3VyIGJ1ZGR5LiINCm1z Z3N0ciAiRWVuIDxiPnZpbmdlcmFmZHJ1azwvYj4gaXMgZWVuIHVuaWVrZSBo ZXJrZW5iYXJlIGVpZ2Vuc2NoYXAgd2Fhcm1lZSINCiJqZSBqZSB2cmllbmQg a3VudCBhdXRoZW50aWNlcmVuLiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE2 MTYNCiMsIGMtZm9ybWF0DQptc2dpZCAiVmVyaWZ5IGZpbmdlcnByaW50IGZv ciAlcyINCm1zZ3N0ciAiQmV2ZXN0aWcgZGUgdmluZ2VyYWZkcnVrIHZhbiAl cyINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE2MjANCm1zZ2lkICJbbm9uZV0i DQptc2dzdHIgIltnZWVuXSINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE2MjgN CiMsIGMtZm9ybWF0DQptc2dpZCAiIg0KIkZpbmdlcnByaW50IGZvciB5b3Us ICVzICglcyk6XG4iDQoiJXNcbiINCiJcbiINCiJQdXJwb3J0ZWQgZmluZ2Vy cHJpbnQgZm9yICVzOlxuIg0KIiVzXG4iDQptc2dzdHIgIkpvdXcgdmluZ2Vy YWZkcnVrLCAlcyAoNXMpOlxuIg0KIiVzXG4iDQoiXG4iDQoiVmVybWVlbmRl IHZpbmdlcmFmZHJ1ayB2YW4gJXM6XG4iDQoiJXNcbiINCg0KIzogLi4vZ3Rr LWRpYWxvZy5jOjE2MzMgLi4vZ3RrLXVpLmM6NjgxDQptc2dpZCAiVmVyaWZ5 IGZpbmdlcnByaW50Ig0KbXNnc3RyICJCZXZlc3RpZyB2aW5nZXJhZmRydWsi DQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxNjYwDQojLCBjLWZvcm1hdA0KbXNn aWQgIkF1dGhlbnRpY2F0ZSAlcyINCm1zZ3N0ciAiQXV0aGVudGljZWVyICVz Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTY2NQ0KIywgYy1mb3JtYXQNCm1z Z2lkICJFbnRlciBhIHNlY3JldCBrbm93biBvbmx5IHRvICVzIGFuZCB5b3Vy c2VsZi5cbiINCm1zZ3N0ciAiVm9lciBoZXQgZ2VoZWltIGluIGRhdCBhbGxl ZW4gamlqIGVuIGplIHZyaWVuZCAlcyBrZW5uZW4uXG4iDQoNCiM6IC4uL2d0 ay1kaWFsb2cuYzoxNjY4DQptc2dpZCAiQXV0aGVudGljYXRlIGJ1ZGR5Ig0K bXNnc3RyICJBdXRoZW50aWNlZXIgdnJpZW5kIg0KDQojOiAuLi9ndGstZGlh bG9nLmM6MTcwMA0KbXNnaWQgIkFuIGVycm9yIG9jY3VycmVkIGR1cmluZyBh dXRoZW50aWNhdGlvbi4iDQptc2dzdHIgIkVyIGlzIGVlbiBmb3V0IG9wZ2V0 cmVkZW4gdGlqZGVucyBkZSBhdXRoZW50aWNhdGllIg0KDQojOiAuLi9ndGst ZGlhbG9nLmM6MTcxNg0KbXNnaWQgIkF1dGhlbnRpY2F0aW9uIHN1Y2Nlc3Nm dWwuIg0KbXNnc3RyICJBdXRoZW50aWNhdGllIHN1Y2Nlc3N2b2wuIg0KDQoj OiAuLi9ndGstZGlhbG9nLmM6MTcxOQ0KbXNnaWQgIkF1dGhlbnRpY2F0aW9u IGZhaWxlZC4iDQptc2dzdHIgIkF1dGhlbnRpY2F0aWUgbWlzbHVrdC4iDQoN CiM6IC4uL2d0ay1kaWFsb2cuYzoxNzQ0DQojLCBjLWZvcm1hdA0KbXNnaWQg IlByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMgc3RhcnRlZC4lcyINCm1z Z3N0ciAiQmVzbG90ZW4gY29udmVyc2F0aWUgZ2VzdGFydCBtZXQgJXMuJXMi DQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxNzQ4DQojLCBjLWZvcm1hdA0KbXNn aWQgIjxhIGhyZWY9XCIlcyVzXCI+VW52ZXJpZmllZDwvYT4gY29udmVyc2F0 aW9uIHdpdGggJSVzIHN0YXJ0ZWQuJSVzIg0KbXNnc3RyICI8YSBocmVmPVwi JXMlc1wiPk9uYmVzY2hlcm1kZTwvYT4gY29udmVyc2F0aWUgZ2VzdGFydCBt ZXQgJSVzLiUlcyINCg0KIy4gVGhpcyBsYXN0IGNhc2Ugc2hvdWxkIG5ldmVy IGhhcHBlbiwgc2luY2Ugd2Uga25vdw0KIy4gKiB3ZSdyZSBpbiBFTkNSWVBU RUQuDQojOiAuLi9ndGstZGlhbG9nLmM6MTc1Ng0KIywgYy1mb3JtYXQNCm1z Z2lkICJOb3QgcHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCAlcyBzdGFydGVk LiVzIg0KbXNnc3RyICJHZWVuIGJlc2xvdGVuIGNvbnZlcnNhdGllIGdlc3Rh cnQgbWV0ICVzLiVzIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTc2MiAuLi9n dGstZGlhbG9nLmM6MTg2Mw0KbXNnaWQgIiAgV2FybmluZzogdXNpbmcgb2xk IHByb3RvY29sIHZlcnNpb24gMS4iDQptc2dzdHIgIiAgV2FhcnNjaHV3aW5n OiBoZXQgb3VkZSBwcm90b2NvbCB2ZXJzaWUgMSBpcyBnZWJydWlrdC4iDQoN CiM6IC4uL2d0ay1kaWFsb2cuYzoxNzgyDQojLCBjLWZvcm1hdA0KbXNnaWQg IlByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMgbG9zdC4iDQptc2dzdHIg IkJlc2xvdGVuIGNvbnZlcnNhdGllIG1ldCAlcyB2ZXJsb3Jlbi4iDQoNCiM6 IC4uL2d0ay1kaWFsb2cuYzoxODE3DQojLCBjLWZvcm1hdA0KbXNnaWQgIiIN CiIlcyBoYXMgZW5kZWQgaGlzL2hlciBwcml2YXRlIGNvbnZlcnNhdGlvbiB3 aXRoIHlvdTsgeW91IHNob3VsZCBkbyB0aGUgc2FtZS4iDQptc2dzdHIgIiVz IGhlZWZ0IGRlIGJlc2xvdGVuIGNvbnZlcnNhdGllIG1ldCBqb3UgYWZnZXNs b3Rlbi4gSmlqIGt1bnQgZGl0ICINCiJoZXQgYmVzdGUgbnUgb29rIHplbGYg YWZzbHVpdGVuLiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE4NDINCiMsIGMt Zm9ybWF0DQptc2dpZCAiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgcHJp dmF0ZSBjb252ZXJzYXRpb24gd2l0aCAlcy4lcyINCm1zZ3N0ciAiRGUgYmVz bG90ZW4gY29udmVyc2F0aWUgbWV0ICVzIGlzIHN1Y2Nlc3N2b2wgaGVybmll dXdkIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTg0Nw0KIywgYy1mb3JtYXQN Cm1zZ2lkICIiDQoiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgPGEgaHJl Zj1cIiVzJXNcIj51bnZlcmlmaWVkPC9hPiBjb252ZXJzYXRpb24gd2l0aCAi DQoiJSVzLiUlcyINCm1zZ3N0ciAiRGUgPGEgaHJlZj1cIiVzJXNcIj5vbmJl c2NoZXJtZGU8L2E+IGNvbnZlcnNhdGllIG1ldCAlJXMuJSVzIGlzIG1ldCAi DQoic3VjY2VzcyBoZXJuaWV1d2QiDQoNCiMuIFRoaXMgbGFzdCBjYXNlIHNo b3VsZCBuZXZlciBoYXBwZW4sIHNpbmNlIHdlIGtub3cNCiMuICogd2UncmUg aW4gRU5DUllQVEVELg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE4NTYNCiMsIGMt Zm9ybWF0DQptc2dpZCAiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgbm90 IHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMuJXMiDQptc2dzdHIgIkRl IG9uYmVzY2hlcm1kZSBjb252ZXJzYXRpZSBtZXQgJXMuJXMgaXMgbWV0IHN1 Y2Nlc3MgaGVybmlldXdkLiBIdWg/Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6 MTg4Mw0KIywgYy1mb3JtYXQNCm1zZ2lkICJBdHRlbXB0aW5nIHRvIHJlZnJl c2ggdGhlIHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMuLi4iDQptc2dz dHIgIkJlemlnIG1ldCBoZXQgdmVybmlldXdlbiB2YW4gZGUgYmVzY2hlcm1k ZSBjb252ZXJzYXRpZSBtZXQgJXMuLi4iDQoNCiM6IC4uL2d0ay1kaWFsb2cu YzoxODg1DQojLCBjLWZvcm1hdA0KbXNnaWQgIkF0dGVtcHRpbmcgdG8gc3Rh cnQgYSBwcml2YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVzLi4uIg0KbXNnc3Ry ICJFZW4gcG9naW5nIGlzIGdlc3RhcnQgb20gZWVuIGJlc2NoZXJtZGUgY29u dmVyc2F0aWUgdGUgYmVnaW5uZW4gbWV0ICVzLi4uIg0KDQojIFBhdWwgdG8g SWFuOiBTaG91bGQvY2FuIHdlIHJlYWxseSB0cmFuc2xhdGUgdGhlc2UgZW50 cmllcyBoZXJlPw0KIzogLi4vZ3RrLWRpYWxvZy5jOjIwNDUNCm1zZ2lkICJP VFI6Ig0KbXNnc3RyICJPVFI6Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6MjA1 NA0KbXNnaWQgIk9UUiBNZXNzYWdpbmciDQptc2dzdHIgIk9UUiBCZXJpY2h0 Z2V2aW5nIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MjA2MA0KbXNnaWQgIl9F bmQgcHJpdmF0ZSBjb252ZXJzYXRpb24iDQptc2dzdHIgIl9FaW5kZSBiZXNj aGVybWRlIGNvbnZlcnNhdGllIg0KDQojLg0KIy4gKiBEb24ndCBzaG93IHRo ZSBWZXJpZnkgZmluZ2VycHJpbnQgbWVudSBvcHRpb24gYW55IG1vcmUuICBZ b3UgY2FuDQojLiAqIHN0aWxsIGdldCB0byB0aGUgZGlhbG9nIHRocm91Z2gg QXV0aGVudGljYXRlIGNvbm5lY3Rpb24gLT4NCiMuICogQWR2YW5jZWQuLi4N CiMuICoNCiMuIG1lbnV2ZXJmID0gZ3RrX21lbnVfaXRlbV9uZXdfd2l0aF9t bmVtb25pYyhfKCJfVmVyaWZ5IGZpbmdlcnByaW50IikpOw0KIy4gZ3RrX21l bnVfc2hlbGxfYXBwZW5kKEdUS19NRU5VX1NIRUxMKG1lbnUpLCBtZW51dmVy Zik7DQojLiBndGtfd2lkZ2V0X3Nob3cobWVudXZlcmYpOw0KIy4NCiM6IC4u L2d0ay1kaWFsb2cuYzoyMDc4DQptc2dpZCAiX0F1dGhlbnRpY2F0ZSBidWRk eSINCm1zZ3N0ciAiQXV0aGVudGljZWVyIHZyaWVuZCINCg0KIzogLi4vZ3Rr LXVpLmM6OTYNCiMsIGMtZm9ybWF0DQptc2dpZCAiRmluZ2VycHJpbnQ6ICUu ODBzIg0KbXNnc3RyICJ2aW5nZXJhZmRydWsgJS44MHMiDQoNCiM6IC4uL2d0 ay11aS5jOjEwMA0KIywgYy1mb3JtYXQNCm1zZ2lkICJObyBrZXkgcHJlc2Vu dCINCm1zZ3N0ciAiR2VlbiBzbGV1dGVsIGFhbndlemlnIg0KDQojOiAuLi9n dGstdWkuYzoxMDUNCiMsIGMtZm9ybWF0DQptc2dpZCAiTm8gYWNjb3VudCBh dmFpbGFibGUiDQptc2dzdHIgIkdlZW4gYWNjb3VudCBiZXNjaGlrYmFhciIN Cg0KIzogLi4vZ3RrLXVpLmM6MTY1DQptc2dpZCAiVW51c2VkIg0KbXNnc3Ry ICJPbmdlYnJ1aWt0Ig0KDQojOiAuLi9ndGstdWkuYzoxNzENCm1zZ2lkICJZ ZXMiDQptc2dzdHIgIkphIg0KDQojOiAuLi9ndGstdWkuYzoxNzENCm1zZ2lk ICJObyINCm1zZ3N0ciAiTmVlIg0KDQojOiAuLi9ndGstdWkuYzozOTYNCm1z Z2lkICJFbmFibGUgcHJpdmF0ZSBtZXNzYWdpbmciDQptc2dzdHIgIlN0YXJ0 IGJlc2NoZXJtZGUgY29udmVyc2F0aWUiDQoNCiM6IC4uL2d0ay11aS5jOjM5 OA0KbXNnaWQgIkF1dG9tYXRpY2FsbHkgaW5pdGlhdGUgcHJpdmF0ZSBtZXNz YWdpbmciDQptc2dzdHIgIkF1dG9tYXRpc2NoIGluaXRpZXJlbiB2YW4gYmVz Y2hlcm1kZSBiZXJpY2h0ZW4iDQoNCiM6IC4uL2d0ay11aS5jOjQwMA0KbXNn aWQgIlJlcXVpcmUgcHJpdmF0ZSBtZXNzYWdpbmciDQptc2dzdHIgIkFsbGVl biBiZXNjaGVybWRlIGJlcmljaHRlbiB0b2VzdGFhbiINCg0KIzogLi4vZ3Rr LXVpLmM6NDAzDQptc2dpZCAiRG9uJ3QgbG9nIE9UUiBjb252ZXJzYXRpb25z Ig0KbXNnc3RyICJPVFIgY29udmVyc2F0aWVzIG5pZXQgb3BzbGFhbiINCg0K IzogLi4vZ3RrLXVpLmM6NTMxDQptc2dpZCAiTXkgcHJpdmF0ZSBrZXlzIg0K bXNnc3RyICJNaWpuIGdlaGVpbWUgc2xldXRlbHMiDQoNCiM6IC4uL2d0ay11 aS5jOjU0MA0KbXNnaWQgIktleSBmb3IgYWNjb3VudDoiDQptc2dzdHIgIlNs ZXV0ZWwgdm9vciBhY2NvdW50OiINCg0KIzogLi4vZ3RrLXVpLmM6NTY1DQpt c2dpZCAiR2VuZXJhdGUiDQptc2dzdHIgIkdlbmVyZWVyIg0KDQojOiAuLi9n dGstdWkuYzo1OTYNCm1zZ2lkICJEZWZhdWx0IE9UUiBTZXR0aW5ncyINCm1z Z3N0ciAiU3RhbmRhYXJkIE9UUiBpbnN0ZWxsaW5nZW4iDQoNCiM6IC4uL2d0 ay11aS5jOjYyNQ0KbXNnaWQgIlNjcmVlbm5hbWUiDQptc2dzdHIgIk5hYW0i DQoNCiM6IC4uL2d0ay11aS5jOjYyNg0KbXNnaWQgIlN0YXR1cyINCm1zZ3N0 ciAiU3RhdHVzIg0KDQojOiAuLi9ndGstdWkuYzo2MjcNCm1zZ2lkICJWZXJp ZmllZCINCm1zZ3N0ciAiR2V2ZXJpZmljZWVyZCINCg0KIzogLi4vZ3RrLXVp LmM6NjI4DQptc2dpZCAiRmluZ2VycHJpbnQiDQptc2dzdHIgInZpbmdlcmFm ZHJ1ayINCg0KIzogLi4vZ3RrLXVpLmM6NjI5DQptc2dpZCAiQWNjb3VudCIN Cm1zZ3N0ciAiQWNjb3VudCINCg0KIzogLi4vZ3RrLXVpLmM6NjY1DQptc2dp ZCAiU3RhcnQgcHJpdmF0ZSBjb25uZWN0aW9uIg0KbXNnc3RyICJTdGFydCBi ZXNsb3RlbiB2ZXJiaW5kaW5nIg0KDQojOiAuLi9ndGstdWkuYzo2NzMNCm1z Z2lkICJFbmQgcHJpdmF0ZSBjb25uZWN0aW9uIg0KbXNnc3RyICJTdG9wIGJl c2xvdGVuIHZlcmJpbmRpbmciDQoNCiM6IC4uL2d0ay11aS5jOjY4OQ0KbXNn aWQgIkZvcmdldCBmaW5nZXJwcmludCINCm1zZ3N0ciAiVmVyZ2VldCB2aW5n ZXJhZmRydWsiDQoNCiM6IC4uL2d0ay11aS5jOjczOA0KbXNnaWQgIkNvbmZp ZyINCm1zZ3N0ciAiQ29uZmlndXJhdGllIg0KDQojOiAuLi9ndGstdWkuYzo3 NDANCm1zZ2lkICJLbm93biBmaW5nZXJwcmludHMiDQptc2dzdHIgIkJla2Vu ZGUgdmluZ2VyYWZkcnVra2VuIg0KDQojOiAuLi9ndGstdWkuYzo4MzggLi4v b3RyLXBsdWdpbi5jOjU3Nw0KbXNnaWQgIk9UUiBTZXR0aW5ncyINCm1zZ3N0 ciAiT1RSIEluc3RlbGxpbmdlbiINCg0KIy4gU2V0IHRoZSB0aXRsZQ0KIzog Li4vZ3RrLXVpLmM6ODU2DQojLCBjLWZvcm1hdA0KbXNnaWQgIk9UUiBTZXR0 aW5ncyBmb3IgJXMiDQptc2dzdHIgIk9UUiBJbnN0ZWxsaW5nZW4gdm9vciAl cyINCg0KIy4gTWFrZSB0aGUgY2FzY2FkZWQgY2hlY2tib3hlcw0KIzogLi4v Z3RrLXVpLmM6ODczDQptc2dpZCAiVXNlIGRlZmF1bHQgT1RSIHNldHRpbmdz IGZvciB0aGlzIGJ1ZGR5Ig0KbXNnc3RyICJHZWJydWlrIGRlIHN0YW5kYWFy ZCBPVFIgaW5zdGVsbGluZ2VuIHZvb3IgZGV6ZSB2cmllbmQiDQoNCiM6IC4u L290ci1wbHVnaW4uYzoxMTMNCiMsIGMtZm9ybWF0DQptc2dpZCAiWW91IGFy ZSBub3QgY3VycmVudGx5IGNvbm5lY3RlZCB0byBhY2NvdW50ICVzICglcyku Ig0KbXNnc3RyICJKZSBiZW50IG9wIGRpdCBtb21lbnQgbmlldCB2ZXJib25k ZW4gYWFuIGhldCBhY2NvdW50ICVzICglcykuIg0KDQojOiAuLi9vdHItcGx1 Z2luLmM6MTE3DQptc2dpZCAiTm90IGNvbm5lY3RlZCINCm1zZ3N0ciAiTmll dCB2ZXJib25kZW4iDQoNCiM6IC4uL290ci1wbHVnaW4uYzoxNjENCiMsIGMt Zm9ybWF0DQptc2dpZCAiT3V0IG9mIG1lbW9yeSBidWlsZGluZyBmaWxlbmFt ZXMhXG4iDQptc2dzdHIgIlRlIHdlaW5pZyBnZWhldWdlbiB2b29yIGhldCBv cGJvdXdlbiB2YW4gYmVzdGFuZHNuYW1lbiEiDQoNCiM6IC4uL290ci1wbHVn aW4uYzoxNjcNCiMsIGMtZm9ybWF0DQptc2dpZCAiQ291bGQgbm90IHdyaXRl IHByaXZhdGUga2V5IGZpbGVcbiINCm1zZ3N0ciAiS29uIGhldCBnZWhlaW1l IHNsZXV0ZWwgYmVzdGFuZCBuaWV0IHNjaHJpanZlblxuIg0KDQojOiAuLi9v dHItcGx1Z2luLmM6MjEwDQojLCBjLWZvcm1hdA0KbXNnaWQgIlVua25vd24g YWNjb3VudCAlcyAoJXMpLiINCm1zZ3N0ciAiT25iZWtlbmQgYWNjb3VudCAl cyAoJXMpLiINCg0KIzogLi4vb3RyLXBsdWdpbi5jOjIxNA0KbXNnaWQgIlVu a25vd24gYWNjb3VudCINCm1zZ3N0ciAiT25iZWtlbmQgYWNjb3VudCINCg0K IzogLi4vb3RyLXBsdWdpbi5jOjk1Mw0KbXNnaWQgIk9mZi10aGUtUmVjb3Jk IE1lc3NhZ2luZyINCm1zZ3N0ciAiT2ZmLXRoZS1SZWNvcmQgQmVyaWNodGdl dmluZyINCg0KIzogLi4vb3RyLXBsdWdpbi5jOjk1NA0KbXNnaWQgIlByb3Zp ZGVzIHByaXZhdGUgYW5kIHNlY3VyZSBjb252ZXJzYXRpb25zIg0KbXNnc3Ry ICJCZXNjaGVybWQgZW4gdmVyc2xldXRlbGQgZ2VzcHJla2tlbiINCg0KIzog Li4vb3RyLXBsdWdpbi5jOjk1NQ0KbXNnaWQgIiINCiJQcmVzZXJ2ZXMgdGhl IHByaXZhY3kgb2YgSU0gY29tbXVuaWNhdGlvbnMgYnkgcHJvdmlkaW5nIGVu Y3J5cHRpb24sICINCiJhdXRoZW50aWNhdGlvbiwgZGVuaWFiaWxpdHksIGFu ZCBwZXJmZWN0IGZvcndhcmQgc2VjcmVjeS4iDQptc2dzdHIgIkJlc2NoZXJt ZCBkZSBwcml2YWN5IHZhbiBJTSBjb21tdW5pY2F0aWUgZG9vciBtaWRkZWwg dmFuICINCiJoZXQgZ2VicnVpayB2YW4gdmVyc2xldXRlbGluZywgYXV0aGVu dGljYXRpZSwgb25rZW4tbW9nZWxpamtoZWlkIGVuICINCiIncGVyZmVjdCBm b3J3YXJkIHNlY3JlY3knLg0KDQojOiAuLi91aS5jOjEwOA0KIywgYy1mb3Jt YXQNCm1zZ2lkICJBY2NvdW50ICVzICglcykgY291bGQgbm90IGJlIGZvdW5k Ig0KbXNnc3RyICJBY2NvdW50ICVzICglcykga29uIG5pZXQgd29yZGVuIGdl dm9uZGVuIg0KDQojOiAuLi91aS5jOjExMg0KbXNnaWQgIkFjY291bnQgbm90 IGZvdW5kIg0KbXNnc3RyICJBY2NvdW50IG5pZXQgZ2V2b25kZW4iDQo= --8323328-1373854264-1185396911=:22096-- From ian@cypherpunks.ca Thu Jul 26 16:03:03 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 26 Jul 2007 11:03:03 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available In-Reply-To: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: <20070726150303.GK24420@thunk.cs.uwaterloo.ca> On Tue, Jul 24, 2007 at 04:11:04PM -0400, Ian Goldberg wrote: > The point of this preview version is mainly for package maintainers to > tell me what I've messed up as far as packaging / portability go. The > sooner I get feedback in that area, the sooner the "real" 3.1.0 release > will be there. To be clear, this preview release should *not* be packaged and distributed by the package maintainers. There's at least one more crash bug to track down, and translations to add, before official packages should be made. But you should try to make the packages yourself, and let me know if anything's not building properly, or something like that. Thanks, - Ian From ian@cypherpunks.ca Thu Jul 26 17:57:42 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 26 Jul 2007 12:57:42 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> Message-ID: <20070726165742.GO24420@thunk.cs.uwaterloo.ca> Fixed (hopefully) a problem with 64-bit systems. [Had an "unsigned int" where we needed a "size_t", d'oh. libotr now compiles cleanly on both 32 and 64 bit arches with "-Wall -pedantic -Werror". ;-) ] http://otr.cypherpunks.ca/libotr-3.1.0-preview2.tar.gz http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview2.tar.gz - Ian From paul@cypherpunks.ca Thu Jul 26 18:26:25 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Thu, 26 Jul 2007 13:26:25 -0400 (EDT) Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: <20070726165742.GO24420@thunk.cs.uwaterloo.ca> References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> <20070726165742.GO24420@thunk.cs.uwaterloo.ca> Message-ID: On Thu, 26 Jul 2007, Ian Goldberg wrote: > Fixed (hopefully) a problem with 64-bit systems. [Had an "unsigned int" > where we needed a "size_t", d'oh. libotr now compiles cleanly on both > 32 and 64 bit arches with "-Wall -pedantic -Werror". ;-) ] > > http://otr.cypherpunks.ca/libotr-3.1.0-preview2.tar.gz > http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview2.tar.gz Fedora7 test packages are available at: ftp://ftp.xelerance.com/libotr/binaries ftp://ftp.xelerance.com/pidgin-otr/binaries Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From ian@cypherpunks.ca Thu Jul 26 23:55:07 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 26 Jul 2007 18:55:07 -0400 Subject: [OTR-dev] Help with Windows dll? In-Reply-To: <45CF4F8D.60308@gmx.net> References: <45CF4F8D.60308@gmx.net> Message-ID: <20070726225507.GF3751@yoink.cs.uwaterloo.ca> On Sun, Feb 11, 2007 at 06:17:01PM +0100, Thomas B. wrote: > I also wanted to test it under Windows, which was a bit trickier. I > don't know if this can be done in a better way (it's long ago that I > compiled something for Windows), but it worked for me. First, I > followed Ian's instructions to set up a cross-compiling environment > with MinGW under Linux: > http://lists.cypherpunks.ca/pipermail/otr-users/2006-November/000792.html > That worked quite well and enabled me to cross-compile the current CVS > version of gaim-otr. Then, after applying my patch, I needed two extra > steps: > > 1.) The MinGW environment was lacking a libintl.h. The libintl.h from > my system was not suitable, as it belongs to glibc (and the code of > libintl is built into glibc). So I downloaded the gettext package, > cross-compiled it and installed it into /usr/i586-mingw32msvc/, so > that I had a libintl.h and a libintl.a in my MinGW environment. > > 2.) Inside gaim-otr, LOCALEDIR needs to be correctly defined so that > the language files can be found. The tricky thing is that in Win32 > Gaim, the directory containing the locale files is generally only > known at runtime (it depends on where the user has installed Gaim). So > in Gaim's win32dep.h, LOCALEDIR is defined as a function call to > wgaim_locale_dir(). Therefore I included that file in otr-plugin.c, > and placed win32dep.h and the other headers in libgaim/win32 (from the > Gaim source tarball) into /usr/i586-mingw32msvc/include/gaim. > > Then, after making some adjustments to Makefile.mingw, I was able to > cross-compile the patched gaim-otr for Windows with a "make -f > Makefile.mingw". I did all that, and I successfully built a pidgin-otr.dll file, but pidgin (on Windows) won't load it. pidgin -d complains: plugins: C:\Program Files\Pidgin\plugins\pidgin-otr.dll is not loadable: The specified module could not be found. This error message is the output of g_module_error() when g_module_open() fails, but I have no idea why that might be happening. Here's my build line: i586-mingw32msvc-gcc -g -shared -Wl,--enable-auto-image-base otr-plugin.o ui.o dialogs.o gtk-ui.o gtk-dialog.o -o pidgin-otr.dll /usr/i586-mingw32msvc/lib/libotr.a -lgtk-win32-2.0 -lglib-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lpidgin -llibpurple -lgcrypt -lgpg-error -L/usr/i586-mingw32msvc/lib -lintl If you'd like to see the dll itself, you can find it at http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-3.1-preview2.zip The source is what's currently checked into CVS, which is negligibly different from the 3.1.0-preview2 I posted this morning. Any hints would be appreciated. I know approximately nothing about Windows. ;-) Thanks, - Ian From mgentry@ieee.org Fri Jul 27 00:33:48 2007 From: mgentry@ieee.org (Martin Gentry) Date: Thu, 26 Jul 2007 19:33:48 -0400 Subject: [OTR-dev] Help with Windows dll? References: <45CF4F8D.60308@gmx.net> <20070726225507.GF3751@yoink.cs.uwaterloo.ca> Message-ID: <001101c7cfdd$7136fe60$9800a8c0@IndustryNext.local> ----- Original Message ----- From: "Ian Goldberg" To: "Thomas B." Cc: Sent: Thursday, July 26, 2007 6:55 PM Subject: [OTR-dev] Help with Windows dll? > On Sun, Feb 11, 2007 at 06:17:01PM +0100, Thomas B. wrote: >> I also wanted to test it under Windows, which was a bit trickier. I >> don't know if this can be done in a better way (it's long ago that I >> compiled something for Windows), but it worked for me. First, I >> followed Ian's instructions to set up a cross-compiling environment >> with MinGW under Linux: >> http://lists.cypherpunks.ca/pipermail/otr-users/2006-November/000792.html >> That worked quite well and enabled me to cross-compile the current CVS >> version of gaim-otr. Then, after applying my patch, I needed two extra >> steps: >> >> 1.) The MinGW environment was lacking a libintl.h. The libintl.h from >> my system was not suitable, as it belongs to glibc (and the code of >> libintl is built into glibc). So I downloaded the gettext package, >> cross-compiled it and installed it into /usr/i586-mingw32msvc/, so >> that I had a libintl.h and a libintl.a in my MinGW environment. >> >> 2.) Inside gaim-otr, LOCALEDIR needs to be correctly defined so that >> the language files can be found. The tricky thing is that in Win32 >> Gaim, the directory containing the locale files is generally only >> known at runtime (it depends on where the user has installed Gaim). So >> in Gaim's win32dep.h, LOCALEDIR is defined as a function call to >> wgaim_locale_dir(). Therefore I included that file in otr-plugin.c, >> and placed win32dep.h and the other headers in libgaim/win32 (from the >> Gaim source tarball) into /usr/i586-mingw32msvc/include/gaim. >> >> Then, after making some adjustments to Makefile.mingw, I was able to >> cross-compile the patched gaim-otr for Windows with a "make -f >> Makefile.mingw". > > I did all that, and I successfully built a pidgin-otr.dll file, but > pidgin (on Windows) won't load it. pidgin -d complains: > > plugins: C:\Program Files\Pidgin\plugins\pidgin-otr.dll is not > loadable: The specified module could not be found. > > This error message is the output of g_module_error() when > g_module_open() fails, but I have no idea why that might be happening. > > Here's my build line: > > i586-mingw32msvc-gcc -g -shared -Wl,--enable-auto-image-base > otr-plugin.o ui.o dialogs.o gtk-ui.o gtk-dialog.o -o pidgin-otr.dll > /usr/i586-mingw32msvc/lib/libotr.a -lgtk-win32-2.0 -lglib-2.0 > -lgdk_pixbuf-2.0 -lgobject-2.0 -lpidgin -llibpurple -lgcrypt -lgpg-error > -L/usr/i586-mingw32msvc/lib -lintl > > If you'd like to see the dll itself, you can find it at > > http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-3.1-preview2.zip > > The source is what's currently checked into CVS, which is negligibly > different from the 3.1.0-preview2 I posted this morning. > > Any hints would be appreciated. I know approximately nothing about > Windows. ;-) I know this might not really help much since I don't offhand know how to remedy the problem, but the dll you built wants a libintl-8.dll to be available whereas the GTK+ runtime that got installed when I just installed pidgin on a Windows box includes intl.dll, not libintl-8.dll. -martin From ian@cypherpunks.ca Fri Jul 27 02:09:15 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 26 Jul 2007 21:09:15 -0400 Subject: [OTR-dev] Help with Windows dll? In-Reply-To: <001101c7cfdd$7136fe60$9800a8c0@IndustryNext.local> References: <45CF4F8D.60308@gmx.net> <20070726225507.GF3751@yoink.cs.uwaterloo.ca> <001101c7cfdd$7136fe60$9800a8c0@IndustryNext.local> Message-ID: <20070727010915.GG3751@yoink.cs.uwaterloo.ca> On Thu, Jul 26, 2007 at 07:33:48PM -0400, Martin Gentry wrote: > I know this might not really help much since I don't offhand know how to > remedy the problem, but the dll you built wants a libintl-8.dll to be > available whereas the GTK+ runtime that got installed when I just installed > pidgin on a Windows box includes intl.dll, not libintl-8.dll. Thanks, that helped a lot. I statically linked libintl and libiconv, and now I have a working pidgin-otr.dll again (and it works in Dutch, too!). Out of curiosity, what do you use to figure out what .dlls a given .dll requires? Thanks so much, - Ian From mgentry@ieee.org Fri Jul 27 03:38:44 2007 From: mgentry@ieee.org (Martin Gentry) Date: Thu, 26 Jul 2007 22:38:44 -0400 Subject: [OTR-dev] Help with Windows dll? In-Reply-To: <20070727010915.GG3751@yoink.cs.uwaterloo.ca> References: <45CF4F8D.60308@gmx.net> <20070726225507.GF3751@yoink.cs.uwaterloo.ca> <001101c7cfdd$7136fe60$9800a8c0@IndustryNext.local> <20070727010915.GG3751@yoink.cs.uwaterloo.ca> Message-ID: <51f9d0440707261938t1372eb9cwab7bc3306d8c4c37@mail.gmail.com> ------=_Part_273_13210247.1185503924715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/26/07, Ian Goldberg wrote: > > Thanks, that helped a lot. I statically linked libintl and libiconv, > and now I have a working pidgin-otr.dll again (and it works in Dutch, > too!). > > Out of curiosity, what do you use to figure out what .dlls a given .dll > requires? Dependency walker - http://www.dependencywalker.com/. Not sure if there are any non-Windows tools that will do the same thing. -martin ------=_Part_273_13210247.1185503924715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/26/07, Ian Goldberg <ian@cypherpunks.ca> wrote:
Thanks, that helped a lot.  I statically linked libintl and libiconv,
and now I have a working pidgin-otr.dll again (and it works in Dutch,
too!).

Out of curiosity, what do you use to figure out what .dlls a given .dll
requires?

Dependency walker - http://www.dependencywalker.com/.  Not sure if there are any non-Windows tools that will do the same thing.

-martin


------=_Part_273_13210247.1185503924715-- From gdt@ir.bbn.com Sat Jul 28 00:51:25 2007 From: gdt@ir.bbn.com (Greg Troxel) Date: Fri, 27 Jul 2007 19:51:25 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: <20070726165742.GO24420@thunk.cs.uwaterloo.ca> (Ian Goldberg's message of "Thu, 26 Jul 2007 12:57:42 -0400") References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> <20070726165742.GO24420@thunk.cs.uwaterloo.ca> Message-ID: I don't mean to rant, but I'm trying to package pidgin-otr and having a harder time than seems necessary. I'm experienced enough at packaging that I suspect others are too. 1) at http://www.cypherpunks.ca/otr/ it says that there is OTR plugin for Pidgin (formerly known as gaim) and the file is http://www.cypherpunks.ca/otr/gaim-otr-3.0.0.tar.gz But this file is a plugin for gaim (1.5), not for pidgin (which to me implies 2.0). The headline should indicate clearly that this is for gaim 1.5.X. 2) There is no obvious way to find out the list of files available for download. Simply putting them all in http://www.cypherpunks.ca/otr/download/ and enabling indexing would help a lot. 3) It seems that pidgin has been out for a while, so it never occured to me that there is no released otr plugin based on the beta one that's been around for ever. If this is really the case the top-level web page should explain it - I expected to find pidgin-otr-3.0.0 and haven't been able to. 4) I found Ian's message about preview2, and downloaded it. It would be good to use 3.1.0a2 to follow normal conventions for prerelease software, and to have the directory name match the version name, so that packaging software that assumes it will match won't need adjusting. Right now 3.1.0-preview2 unpacks into 3.1.0. 5) pidgin-otr-3.1.0 seems to need libotr-3.1.0. While this might really be necessary, it would be really nice to decouple gui issues from core protocol issues, and to only depend on released libraries - even for unreleased plugins. It's awkward to test pidgin-otr-3.1.0 while not breaking gaim-otr-3.0.0 on the same system. (I'd hope that 3.1.0 is API and ABI compatible, but you'll forgive me for not being confident in this given all of the above.) I really appreciate all the work that's gone into OTR, and I use it daily. Sorry if I'm sounding cranky, but a bit more care in making things packaging friendly and being careful to avoid confusion would make it more likely that more people can get OTR more easily. The good news is that after updating libotr (which only needed a version change and a single new .h), and adjusting the former gaim-otr package for pidgin-otr (naming changes only), the plugin works. This is on NetBSD-current on i386 with pretty recent gnome/gtk/glib/etc and pidgin 2.0.1. Just to be clear, this is a full test of the plugin as built by the packaging system, and my only real issues were 4 and 5 above, both quite minor. Greg From gdt@ir.bbn.com Sat Jul 28 00:56:39 2007 From: gdt@ir.bbn.com (Greg Troxel) Date: Fri, 27 Jul 2007 19:56:39 -0400 Subject: [OTR-dev] libotr major version bump? Message-ID: Was this really necessary? Upgrading to 3.1.0 from 3.0.0 went from 2.0 to 3.0 in ELF shlib numbering, and I see nothing in NEWS that indicates why - just things that look like they might have new calls, vs changing the signature of existing calls. So the gaim-otr for gaim 1.5 was broken by this. NEWS really should say clearly which procedures had an interface change, so that users of the library can update their code. Rebuilding gaim-otr seems to fix the problem, though, so there seems not to have been an API change. From ian@cypherpunks.ca Sat Jul 28 19:14:40 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 28 Jul 2007 14:14:40 -0400 Subject: [OTR-dev] libotr major version bump? In-Reply-To: References: Message-ID: <20070728181440.GO3751@yoink.cs.uwaterloo.ca> On Fri, Jul 27, 2007 at 07:56:39PM -0400, Greg Troxel wrote: > Was this really necessary? Upgrading to 3.1.0 from 3.0.0 went from 2.0 > to 3.0 in ELF shlib numbering, and I see nothing in NEWS that indicates > why - just things that look like they might have new calls, vs changing > the signature of existing calls. So the gaim-otr for gaim 1.5 was > broken by this. NEWS really should say clearly which procedures had an > interface change, so that users of the library can update their code. > > Rebuilding gaim-otr seems to fix the problem, though, so there seems not > to have been an API change. That's weird. When I build libotr-3.1.0, I get a "libotr.so.2.1.0", as expected, since the API and ABI are indeed back-compatible. libotr's configure.ac indicates: LIBOTR_LIBTOOL_VERSION="3:0:1" which specifies current=3, revision=0, age=1, so you get 2.1.0 out of that. What version number is libtool using for you? libotr's UPDATING file contains the information about how users of libotr can update their code for the new version. - Ian From ian@cypherpunks.ca Sat Jul 28 19:23:59 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 28 Jul 2007 14:23:59 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> <20070726165742.GO24420@thunk.cs.uwaterloo.ca> Message-ID: <20070728182359.GP3751@yoink.cs.uwaterloo.ca> On Fri, Jul 27, 2007 at 07:51:25PM -0400, Greg Troxel wrote: > I don't mean to rant, but I'm trying to package pidgin-otr and having a > harder time than seems necessary. I'm experienced enough at packaging > that I suspect others are too. > > 1) at http://www.cypherpunks.ca/otr/ it says that there is > > OTR plugin for Pidgin (formerly known as gaim) > > and the file is http://www.cypherpunks.ca/otr/gaim-otr-3.0.0.tar.gz But > this file is a plugin for gaim (1.5), not for pidgin (which to me > implies 2.0). The headline should indicate clearly that this is for > gaim 1.5.X. We're just waiting for the final release version of 3.1.0 to be ready, which looks like Aug 1 plus or minus a day or two. All that's left is some tidying of some of the documentation. At that point, the old versions will come off the website. > 2) There is no obvious way to find out the list of files available for > download. Simply putting them all in > http://www.cypherpunks.ca/otr/download/ and enabling indexing would help > a lot. As a rule, the webserver's indexing is off, but you make a good point, and I'll ponder this. > 3) It seems that pidgin has been out for a while, so it never occured to > me that there is no released otr plugin based on the beta one that's > been around for ever. If this is really the case the top-level web page > should explain it - I expected to find pidgin-otr-3.0.0 and haven't been > able to. As above, pidgin-otr-3.1.0 will appear next week. > 4) I found Ian's message about preview2, and downloaded it. It would be > good to use 3.1.0a2 to follow normal conventions for prerelease > software, and to have the directory name match the version name, so that > packaging software that assumes it will match won't need adjusting. > Right now 3.1.0-preview2 unpacks into 3.1.0. I did that sort of on purpose; -preview2 isn't meant to be an alpha release. It's meant to be something which structurally will be identical to the upcoming release. That way, packagers can see if there's something broken that I'd need to fix before the 3.1.0 actual release. > 5) pidgin-otr-3.1.0 seems to need libotr-3.1.0. While this might really > be necessary, it would be really nice to decouple gui issues from core > protocol issues, and to only depend on released libraries - even for > unreleased plugins. It's awkward to test pidgin-otr-3.1.0 while not > breaking gaim-otr-3.0.0 on the same system. (I'd hope that 3.1.0 is API > and ABI compatible, but you'll forgive me for not being confident in > this given all of the above.) Indeed, installing libotr-3.1.0 will not break an existing gaim-otr-3.0.0. pidgin-otr-3.1.0 naturally requires libotr-3.1.0, since it uses the library's new features. > name and pointing pkgsrc at the unpacked location> > > > I really appreciate all the work that's gone into OTR, and I use it > daily. Sorry if I'm sounding cranky, but a bit more care in making > things packaging friendly and being careful to avoid confusion would > make it more likely that more people can get OTR more easily. > > > The good news is that after updating libotr (which only needed a version > change and a single new .h), and adjusting the former gaim-otr package > for pidgin-otr (naming changes only), the plugin works. This is on > NetBSD-current on i386 with pretty recent gnome/gtk/glib/etc and pidgin > 2.0.1. Just to be clear, this is a full test of the plugin as built by > the packaging system, and my only real issues were 4 and 5 above, both > quite minor. So when pidgin-otr-3.1.0 and libotr-3.1.0 get released for real next week, they'll build cleanly on NetBSD? That's good to know. Thanks! - Ian From gdt@ir.bbn.com Sun Jul 29 12:10:44 2007 From: gdt@ir.bbn.com (Greg Troxel) Date: Sun, 29 Jul 2007 07:10:44 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: <20070728182359.GP3751@yoink.cs.uwaterloo.ca> (Ian Goldberg's message of "Sat, 28 Jul 2007 14:23:59 -0400") References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> <20070726165742.GO24420@thunk.cs.uwaterloo.ca> <20070728182359.GP3751@yoink.cs.uwaterloo.ca> Message-ID: Ian Goldberg writes: > On Fri, Jul 27, 2007 at 07:51:25PM -0400, Greg Troxel wrote: >> I don't mean to rant, but I'm trying to package pidgin-otr and having a >> harder time than seems necessary. I'm experienced enough at packaging >> that I suspect others are too. >> >> 1) at http://www.cypherpunks.ca/otr/ it says that there is >> >> OTR plugin for Pidgin (formerly known as gaim) >> >> and the file is http://www.cypherpunks.ca/otr/gaim-otr-3.0.0.tar.gz But >> this file is a plugin for gaim (1.5), not for pidgin (which to me >> implies 2.0). The headline should indicate clearly that this is for >> gaim 1.5.X. > > We're just waiting for the final release version of 3.1.0 to be ready, > which looks like Aug 1 plus or minus a day or two. All that's left is > some tidying of some of the documentation. At that point, the old > versions will come off the website. It's fine that 3.1.0 isn't out, but my point that the current gaim 1.5 plugin is mislabeled as pidgin remains. Plus, I think that the gaim 1.5 plugins should remain available until it's reasonable to tell people that they're being completely ridiculous to be running 1.5. Given that 2.0 has been out only a short time, I don't think that's happened yet. >> 3) It seems that pidgin has been out for a while, so it never occured to >> me that there is no released otr plugin based on the beta one that's >> been around for ever. If this is really the case the top-level web page >> should explain it - I expected to find pidgin-otr-3.0.0 and haven't been >> able to. > > As above, pidgin-otr-3.1.0 will appear next week. OK, but please keep in mind that visitors to the web site are not aware of your announced-on-the-list plans, and that the web site should clearly and correctly explain the status of the world at all times. A simple "These files are for gaim 1.5. Support for pidgin 2.0 has not been released and is expected soon." would do wonders. >> 4) I found Ian's message about preview2, and downloaded it. It would be >> good to use 3.1.0a2 to follow normal conventions for prerelease >> software, and to have the directory name match the version name, so that >> packaging software that assumes it will match won't need adjusting. >> Right now 3.1.0-preview2 unpacks into 3.1.0. > > I did that sort of on purpose; -preview2 isn't meant to be an alpha > release. It's meant to be something which structurally will be > identical to the upcoming release. That way, packagers can see if > there's something broken that I'd need to fix before the 3.1.0 actual > release. My point is that it isn't structurally identical, because releases unpack into directories that match the file name, and this doesn't. But I suspect that you did 'make dist', and then just renamed it. I realize that not renaming it is no good either... >> 5) pidgin-otr-3.1.0 seems to need libotr-3.1.0. While this might really >> be necessary, it would be really nice to decouple gui issues from core >> protocol issues, and to only depend on released libraries - even for >> unreleased plugins. It's awkward to test pidgin-otr-3.1.0 while not >> breaking gaim-otr-3.0.0 on the same system. (I'd hope that 3.1.0 is API >> and ABI compatible, but you'll forgive me for not being confident in >> this given all of the above.) > > Indeed, installing libotr-3.1.0 will not break an existing > gaim-otr-3.0.0. pidgin-otr-3.1.0 naturally requires libotr-3.1.0, since > it uses the library's new features. So I guess my point is that it would have been nice to have pidgin-otr-3.0.0 that worked with the old libotr. Because of this it was harder to test. > So when pidgin-otr-3.1.0 and libotr-3.1.0 get released for real next > week, they'll build cleanly on NetBSD? That's good to know. Yes, except for the shlib version issue, which I'll follow up separately on. I have packages ready to commit to pkgsrc once I remove previewN, update checksums, and remove the line to make it build in a directory other than the one implied by the distfile. From gdt@ir.bbn.com Sun Jul 29 12:34:33 2007 From: gdt@ir.bbn.com (Greg Troxel) Date: Sun, 29 Jul 2007 07:34:33 -0400 Subject: [OTR-dev] libotr major version bump? In-Reply-To: <20070728181440.GO3751@yoink.cs.uwaterloo.ca> (Ian Goldberg's message of "Sat, 28 Jul 2007 14:14:40 -0400") References: <20070728181440.GO3751@yoink.cs.uwaterloo.ca> Message-ID: Ian Goldberg writes: > That's weird. When I build libotr-3.1.0, I get a "libotr.so.2.1.0", as > expected, since the API and ABI are indeed back-compatible. > > libotr's configure.ac indicates: > > LIBOTR_LIBTOOL_VERSION="3:0:1" > > which specifies current=3, revision=0, age=1, so you get 2.1.0 out of > that. > > What version number is libtool using for you? In config.status: s,@LIBOTR_LIBTOOL_VERSION@,3:0:1,;t t and this is passed to libtool, but it makes so.3.0 poblano gdt 22 /usr/pkgsrc/chat/libotr/work/libotr-3.1.0/src > gmake /bin/sh ../libtool --tag=CC --mode=link cc -O2 -I/usr/pkg/include -I/usr/include -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -o libotr.la -rpath /usr/pkg/lib -version-info 3:0:1 -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lgcrypt -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgpg-error privkey.lo context.lo proto.lo b64.lo dh.lo mem.lo message.lo userstate.lo tlv.lo auth.lo sm.lo cc -shared .libs/privkey.o .libs/context.o .libs/proto.o .libs/b64.o .libs/dh.o .libs/mem.o .libs/message.o .libs/userstate.o .libs/tlv.o .libs/auth.o .libs/sm.o -Wl,--rpath -Wl,/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib -L/usr/pkg/lib -L/usr/lib /usr/pkg/lib/libgcrypt.so /usr/pkg/lib/libgpg-error.so -Wl,-R/usr/pkg/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-soname -Wl,libotr.so.3 -o .libs/libotr.so.3.0 (cd .libs && rm -f libotr.so.3 && ln -s libotr.so.3.0 libotr.so.3) (cd .libs && rm -f libotr.so && ln -s libotr.so.3.0 libotr.so) ar cru .libs/libotr.a privkey.o context.o proto.o b64.o dh.o mem.o message.o userstate.o tlv.o auth.o sm.o ranlib .libs/libotr.a creating libotr.la (cd .libs && rm -f libotr.la && ln -s ../libotr.la libotr.la) I have libtool 1.5.22, but I'm 99% sure that the above runs the libtool that was generated by you at 'make dist' time. So I read the pkgsrc documentation and added USE_LIBTOOL=yes, so that the included libtool script would get overwritten with one that's been fixed for all the platforms pkgsrc runs on. Then I get the right shlib number. -rwxr-xr-x 1 root wheel 74300 Jul 29 07:32 /usr/pkg/lib/libotr.so.2.1.0 I don't understand this - I think it means that just building libotr not with pkgsrc will get the wrong version. I can remove the libtool override, add -x to libtool, and send that if you want to look, but I don't understand libtool innards. > libotr's UPDATING file contains the information about how users of > libotr can update their code for the new version. Thanks - I see you've been quite careful about upgrading issues. From gdt@ir.bbn.com Sun Jul 29 13:02:30 2007 From: gdt@ir.bbn.com (Greg Troxel) Date: Sun, 29 Jul 2007 08:02:30 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: <20070726165742.GO24420@thunk.cs.uwaterloo.ca> (Ian Goldberg's message of "Thu, 26 Jul 2007 12:57:42 -0400") References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> <20070726165742.GO24420@thunk.cs.uwaterloo.ca> Message-ID: http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview2.tar.gz During the install, I get errors about nl.gmo. See build log appended. I don't understand how this is supposed to work. BUILD LOG => Required installed package digest>=20010302: digest-20070703 found => Required installed package checkperms>=1.1: checkperms-1.7 found => Checksum SHA1 OK for pidgin-otr-3.1.0-preview2.tar.gz => Checksum RMD160 OK for pidgin-otr-3.1.0-preview2.tar.gz ===> Installing dependencies for pidgin-otr-3.1.0a2 => Required installed package intltool>=0.35: intltool-0.35.5 found => Required installed package perl>=5.0: perl-5.8.8nb4 found => Required installed package pkg-config>=0.19: pkg-config-0.21nb1 found => Required installed package x11-links>=0.25: x11-links-0.31 found => Required installed package randrproto>=1.2.0: randrproto-1.2.1 found => Required installed package renderproto>=0.9.1: renderproto-0.9.2 found => Required installed package fixesproto>=3.0.0: fixesproto-4.0 found => Required installed package inputproto>=1.4: inputproto-1.4.2 found => Required installed package pidgin>=2.0.1nb1: pidgin-2.0.1nb1 found => Required installed package libotr>=3.0.0: libotr-3.1.0 found => Required installed package libgcrypt>=1.2.0: libgcrypt-1.2.4 found => Required installed package gtk2+>=2.4.0: gtk2+-2.10.14 found => Required installed package glib2>=2.4.0: glib2-2.12.13 found ===> Overriding tools for pidgin-otr-3.1.0a2 ===> Extracting for pidgin-otr-3.1.0a2 ===> Patching for pidgin-otr-3.1.0a2 ===> Creating toolchain wrappers for pidgin-otr-3.1.0a2 src=/usr/pkg/lib/pkgconfig/fixesproto.pc dst=/usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.buildlink/lib/pkgconfig/fixesext.pc; /bin/mkdir -p /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.buildlink/lib/pkgconfig; if test -f ${src}; then /bin/ln -sf ${src} ${dst}; fi ===> Configuring for pidgin-otr-3.1.0a2 => Checking for portability problems in extracted files => Modifying GNU configure scripts to avoid --recheck => Replacing config-guess with pkgsrc versions => Replacing config-sub with pkgsrc versions => Replacing install-sh with pkgsrc version configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... /usr/bin/awk checking whether make sets $(MAKE)... yes checking for i386--netbsdelf-strip... no checking for strip... strip checking for i386--netbsdelf-gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking build system type... i386-unknown-netbsdelf4.99.24 checking host system type... i386--netbsdelf checking for a sed that does not truncate output... /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.tools/bin/sed checking for egrep... grep -E checking for ld used by cc... /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld checking if the linker (/usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld) is GNU ld... yes checking for /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld option to reload object files... -r checking for BSD-compatible nm... nm checking whether ln -s works... yes checking how to recognise dependent libraries... match_pattern /lib[^/]+(\.so|_pic\.a)$ checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for i386--netbsdelf-g++... c++ checking whether we are using the GNU C++ compiler... no checking whether c++ accepts -g... no checking dependency style of c++... none checking how to run the C++ preprocessor... cpp checking for i386--netbsdelf-g77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse nm output from cc object... ok checking for objdir... .libs checking for i386--netbsdelf-ar... no checking for ar... ar checking for i386--netbsdelf-ranlib... no checking for ranlib... ranlib checking for i386--netbsdelf-strip... strip checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... NetBSD ld.elf_so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking whether the c++ linker (/usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld) supports shared libraries... ERROR: To use this compiler, you have to add c++ to ERROR: USE_LANGUAGES in the package Makefile. yes libtool.m4: error: problem compiling CXX test program checking for c++ option to produce PIC... checking if c++ static flag works... no checking if c++ supports -c -o file.o... no checking whether the c++ linker (/usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... ERROR: To use this compiler, you have to add c++ to ERROR: USE_LANGUAGES in the package Makefile. NetBSD ld.elf_so checking how to hardcode library paths into programs... unsupported appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... no checking whether the f77 linker (/usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/.wrapper/bin/ld) supports shared libraries... ERROR: To use this compiler, you have to add fortran to ERROR: USE_LANGUAGES in the package Makefile. yes checking dynamic linker characteristics... ERROR: To use this compiler, you have to add fortran to ERROR: USE_LANGUAGES in the package Makefile. ERROR: To use this compiler, you have to add fortran to ERROR: USE_LANGUAGES in the package Makefile. NetBSD ld.elf_so checking how to hardcode library paths into programs... immediate checking for libgcrypt-config... /usr/pkg/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.2.0... yes checking LIBGCRYPT API version... okay checking for libotr CFLAGS... checking for libotr LIBS... -lotr checking for libotr headers version 3.x >= 3.1.0... found. checking for otrl_message_receiving in -lotr... yes checking pkg-config is at least version 0.9.0... yes checking for EXTRA... yes checking for perl... /usr/pkg/bin/perl checking for XML::Parser... ok checking for iconv... /usr/bin/iconv checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for xgettext... /usr/bin/xgettext checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... no checking for bindtextdomain in -lintl... yes checking for ngettext in -lintl... yes checking for dgettext in -lintl... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for catalogs to be installed... nl configure: creating ./config.status config.status: creating Makefile config.status: creating po/Makefile.in config.status: creating config.h config.status: executing depfiles commands config.status: executing intltool commands config.status: executing default-1 commands config.status: executing po/stamp-it commands => Overriding intltool. WARNING: *** Please consider adding c++ to USE_LANGUAGES in the package Makefile. WARNING: *** Please consider adding fortran to USE_LANGUAGES in the package Makefile. ===> Building for pidgin-otr-3.1.0a2 --- all --- /usr/bin/make all-recursive --- all-recursive --- Making all in po --- otr-plugin.lo --- --- ui.lo --- --- dialogs.lo --- --- gtk-ui.lo --- --- otr-plugin.lo --- if /bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT otr-plugin.lo -MD -MP -MF ".deps/otr-plugin.Tpo" -c -o otr-plugin.lo otr-plugin.c; then mv -f ".deps/otr-plugin.Tpo" ".deps/otr-plugin.Plo"; else rm -f ".deps/otr-plugin.Tpo"; exit 1; fi --- ui.lo --- if /bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT ui.lo -MD -MP -MF ".deps/ui.Tpo" -c -o ui.lo ui.c; then mv -f ".deps/ui.Tpo" ".deps/ui.Plo"; else rm -f ".deps/ui.Tpo"; exit 1; fi --- dialogs.lo --- if /bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT dialogs.lo -MD -MP -MF ".deps/dialogs.Tpo" -c -o dialogs.lo dialogs.c; then mv -f ".deps/dialogs.Tpo" ".deps/dialogs.Plo"; else rm -f ".deps/dialogs.Tpo"; exit 1; fi --- gtk-ui.lo --- if /bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT gtk-ui.lo -MD -MP -MF ".deps/gtk-ui.Tpo" -c -o gtk-ui.lo gtk-ui.c; then mv -f ".deps/gtk-ui.Tpo" ".deps/gtk-ui.Plo"; else rm -f ".deps/gtk-ui.Tpo"; exit 1; fi mkdir .libs cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT gtk-ui.lo -MD -MP -MF .deps/gtk-ui.Tpo -c gtk-ui.c -fPIC -DPIC -o .libs/gtk-ui.o --- dialogs.lo --- cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT dialogs.lo -MD -MP -MF .deps/dialogs.Tpo -c dialogs.c -fPIC -DPIC -o .libs/dialogs.o --- otr-plugin.lo --- cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT otr-plugin.lo -MD -MP -MF .deps/otr-plugin.Tpo -c otr-plugin.c -fPIC -DPIC -o .libs/otr-plugin.o --- ui.lo --- cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT ui.lo -MD -MP -MF .deps/ui.Tpo -c ui.c -fPIC -DPIC -o .libs/ui.o --- gtk-dialog.lo --- if /bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT gtk-dialog.lo -MD -MP -MF ".deps/gtk-dialog.Tpo" -c -o gtk-dialog.lo gtk-dialog.c; then mv -f ".deps/gtk-dialog.Tpo" ".deps/gtk-dialog.Plo"; else rm -f ".deps/gtk-dialog.Tpo"; exit 1; fi cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -MT gtk-dialog.lo -MD -MP -MF .deps/gtk-dialog.Tpo -c gtk-dialog.c -fPIC -DPIC -o .libs/gtk-dialog.o --- pidgin-otr.la --- /bin/sh ./libtool --tag=CC --mode=link cc -I/usr/pkg/include -I/usr/pkg/include -O2 -DXTHREADS -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/cairo -I/usr/pkg/include/pango-1.0 -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/libpng12 -I/usr/pkg/include/pidgin -I/usr/pkg/include/libpurple -DUSING_GTK -DPURPLE_PLUGINS -DPIDGIN_OTR_VERSION=\"3.1.0\" -DLOCALEDIR=\"/usr/pkg/share/locale\" -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/X11R6/include -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -L/usr/X11R6/lib -Wl,-R/usr/X11R6/lib -o pidgin-otr.la -rpath /usr/pkg/lib/pidgin -module -avoid-version -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lgcrypt -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgpg-error -lotr otr-plugin.lo ui.lo dialogs.lo gtk-ui.lo gtk-dialog.lo cc -shared .libs/otr-plugin.o .libs/ui.o .libs/dialogs.o .libs/gtk-ui.o .libs/gtk-dialog.o -Wl,--rpath -Wl,/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib -L/usr/pkg/lib -L/usr/lib -L/usr/X11R6/lib /usr/pkg/lib/libgcrypt.so /usr/pkg/lib/libgpg-error.so /usr/pkg/lib/libotr.so -Wl,-R/usr/pkg/lib -Wl,-R/usr/lib -Wl,-R/usr/X11R6/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-soname -Wl,pidgin-otr.so -o .libs/pidgin-otr.so creating pidgin-otr.la (cd .libs && rm -f pidgin-otr.la && ln -s ../pidgin-otr.la pidgin-otr.la) *** Please use pkgtools/verifypc to sanity check dependencies. => Unwrapping files-to-be-installed. INSTALL LOG => Required installed package digest>=20010302: digest-20070703 found => Required installed package checkperms>=1.1: checkperms-1.7 found ===> Replacing for pidgin-otr-3.1.0a2 WARNING: experimental target - DATA LOSS MAY OCCUR. Creating binary package: pidgin-otr-3.1.0a2 Creating package /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/pidgin-otr-3.1.0a2.tgz Registering depends: pidgin>=2.0.1nb1 libotr>=3.0.0 libgcrypt>=1.2.0 gtk2+>=2.4.0 glib2>=2.4.0. Registering conflicts:. => Preserving existing +REQUIRED_BY file. ===> Deinstalling for pidgin-otr-3.1.0a2 Running /usr/sbin/pkg_delete -K /var/db/pkg pidgin-otr-3.1.0a2 ===> Installing for pidgin-otr-3.1.0a2 => Generating pre-install file lists Making install in po /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/pidgin-otr-3.1.0/install-sh -d /usr/pkg/share/locale if test -n ""; then linguas=""; else linguas="nl"; fi; for lang in $linguas; do dir=/usr/pkg/share/locale/$lang/LC_MESSAGES; /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/pidgin-otr-3.1.0/install-sh -d $dir; if test -r $lang.gmo; then /usr/bin/install -c -o root -g wheel -m 444 $lang.gmo $dir/pidgin-otr.mo; echo "installing $lang.gmo as $dir/pidgin-otr.mo"; else /usr/bin/install -c -o root -g wheel -m 444 ./$lang.gmo $dir/pidgin-otr.mo; echo "installing ./$lang.gmo as" "$dir/pidgin-otr.mo"; fi; if test -r $lang.gmo.m; then /usr/bin/install -c -o root -g wheel -m 444 $lang.gmo.m $dir/pidgin-otr.mo.m; echo "installing $lang.gmo.m as $dir/pidgin-otr.mo.m"; else if test -r ./$lang.gmo.m ; then /usr/bin/install -c -o root -g wheel -m 444 ./$lang.gmo.m $dir/pidgin-otr.mo.m; echo "installing ./$lang.gmo.m as" "$dir/pidgin-otr.mo.m"; else true; fi; fi; done install: ./nl.gmo: stat: No such file or directory installing ./nl.gmo as /usr/pkg/share/locale/nl/LC_MESSAGES/pidgin-otr.mo test -z "/usr/pkg/lib/pidgin" || /usr/home/gdt/NetBSD-current/pkgsrc/chat/pidgin-otr/work/pidgin-otr-3.1.0/install-sh -d "/usr/pkg/lib/pidgin" /bin/sh ./libtool --mode=install /usr/bin/install -c -o root -g wheel 'pidgin-otr.la' '/usr/pkg/lib/pidgin/pidgin-otr.la' /usr/bin/install -c -o root -g wheel .libs/pidgin-otr.so /usr/pkg/lib/pidgin/pidgin-otr.so /usr/bin/install -c -o root -g wheel .libs/pidgin-otr.lai /usr/pkg/lib/pidgin/pidgin-otr.la ---------------------------------------------------------------------- Libraries have been installed in: /usr/pkg/lib/pidgin If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- => Automatic manual page handling => Generating post-install file lists => Registering installation for pidgin-otr-3.1.0a2 pidgin-otr-3.1.0a2 requires installed package glib2-2.12.13 pidgin-otr-3.1.0a2 requires installed package gtk2+-2.10.14 pidgin-otr-3.1.0a2 requires installed package libgcrypt-1.2.4 pidgin-otr-3.1.0a2 requires installed package libotr-3.1.0 pidgin-otr-3.1.0a2 requires installed package pidgin-2.0.1nb1 => Checking file-check results for pidgin-otr-3.1.0a2 => Checking file permissions in pidgin-otr-3.1.0a2 => Checking for missing run-time search paths in pidgin-otr-3.1.0a2 => Checking for work-directory references in pidgin-otr-3.1.0a2 => Fixing @pkgdep entries in dependent packages. From ian@cypherpunks.ca Sun Jul 29 16:14:20 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 29 Jul 2007 11:14:20 -0400 Subject: [OTR-dev] libotr major version bump? In-Reply-To: References: <20070728181440.GO3751@yoink.cs.uwaterloo.ca> Message-ID: <20070729151420.GT3751@yoink.cs.uwaterloo.ca> On Sun, Jul 29, 2007 at 07:34:33AM -0400, Greg Troxel wrote: > Ian Goldberg writes: > > > That's weird. When I build libotr-3.1.0, I get a "libotr.so.2.1.0", as > > expected, since the API and ABI are indeed back-compatible. > > > > libotr's configure.ac indicates: > > > > LIBOTR_LIBTOOL_VERSION="3:0:1" > > > > which specifies current=3, revision=0, age=1, so you get 2.1.0 out of > > that. > > > > What version number is libtool using for you? > > In config.status: > > s,@LIBOTR_LIBTOOL_VERSION@,3:0:1,;t t > > > and this is passed to libtool, but it makes so.3.0 > > > poblano gdt 22 /usr/pkgsrc/chat/libotr/work/libotr-3.1.0/src > gmake > /bin/sh ../libtool --tag=CC --mode=link cc -O2 -I/usr/pkg/include -I/usr/include -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -o libotr.la -rpath /usr/pkg/lib -version-info 3:0:1 -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lgcrypt -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgpg-error privkey.lo context.lo proto.lo b64.lo dh.lo mem.lo message.lo userstate.lo tlv.lo auth.lo sm.lo > cc -shared .libs/privkey.o .libs/context.o .libs/proto.o .libs/b64.o .libs/dh.o .libs/mem.o .libs/message.o .libs/userstate.o .libs/tlv.o .libs/auth.o .libs/sm.o -Wl,--rpath -Wl,/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib -L/usr/pkg/lib -L/usr/lib /usr/pkg/lib/libgcrypt.so /usr/pkg/lib/libgpg-error.so -Wl,-R/usr/pkg/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-soname -Wl,libotr.so.3 -o .libs/libotr.so.3.0 > (cd .libs && rm -f libotr.so.3 && ln -s libotr.so.3.0 libotr.so.3) > (cd .libs && rm -f libotr.so && ln -s libotr.so.3.0 libotr.so) > ar cru .libs/libotr.a privkey.o context.o proto.o b64.o dh.o mem.o message.o userstate.o tlv.o auth.o sm.o > ranlib .libs/libotr.a > creating libotr.la > (cd .libs && rm -f libotr.la && ln -s ../libotr.la libotr.la) > > I have libtool 1.5.22, but I'm 99% sure that the above runs the libtool > that was generated by you at 'make dist' time. I also have 1.5.22: $ libtool --version ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365 2005/12/18 22:14:06) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > So I read the pkgsrc documentation and added USE_LIBTOOL=yes, so that > the included libtool script would get overwritten with one that's been > fixed for all the platforms pkgsrc runs on. Then I get the right shlib > number. > > -rwxr-xr-x 1 root wheel 74300 Jul 29 07:32 /usr/pkg/lib/libotr.so.2.1.0 > > I don't understand this - I think it means that just building libotr not > with pkgsrc will get the wrong version. I can remove the libtool > override, add -x to libtool, and send that if you want to look, but I > don't understand libtool innards. I don't either, unfortunately. But it probably wouldn't hurt. > > libotr's UPDATING file contains the information about how users of > > libotr can update their code for the new version. > > Thanks - I see you've been quite careful about upgrading issues. Yeah. Our plans for the next version will almost certainly require an API change, but we wanted to make this version back-compatible. - Ian From ian@cypherpunks.ca Sun Jul 29 16:22:33 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 29 Jul 2007 11:22:33 -0400 Subject: [OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available In-Reply-To: References: <20070724201104.GN23980@thunk.cs.uwaterloo.ca> <20070726165742.GO24420@thunk.cs.uwaterloo.ca> Message-ID: <20070729152233.GU3751@yoink.cs.uwaterloo.ca> On Sun, Jul 29, 2007 at 08:02:30AM -0400, Greg Troxel wrote: > http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview2.tar.gz > > During the install, I get errors about nl.gmo. See build log appended. > I don't understand how this is supposed to work. > > BUILD LOG > > ===> Building for pidgin-otr-3.1.0a2 > --- all --- > /usr/bin/make all-recursive > --- all-recursive --- > Making all in po > --- otr-plugin.lo --- This isn't working right; the Makefile in po should have built nl.gmo here, using msgfmt. My output: Making all in po make[2]: Entering directory `/home/iang/uw/research/otr/sf/gaim-otr/po' file=`echo nl | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/msgfmt -o $file nl.po make[2]: Leaving directory `/home/iang/uw/research/otr/sf/gaim-otr/po' Can you see what's going on in po/Makefile? > INSTALL LOG > > install: ./nl.gmo: stat: No such file or directory > installing ./nl.gmo as /usr/pkg/share/locale/nl/LC_MESSAGES/pidgin-otr.mo Then of course it fails to install it, since it didn't build. Thanks, - Ian From nix@go-nix.ca Sun Jul 29 17:37:02 2007 From: nix@go-nix.ca (Gabriel Schulhof) Date: Sun, 29 Jul 2007 19:37:02 +0300 Subject: [OTR-dev] A few UI patches Message-ID: <1185727022.30144.43.camel@idefix.go-nix.ca> Hi! I maintain a port of pidgin and pidgin-otr for Internet tablets. From a UI point of view, this means a mouse that cannot move but only click and drag, no right-click (but there's tap-and-hold), and no keyboard (except on-screen via GTK input methods). I have created a few UI patches for pidgin-otr. My main motivation is, of course, to make pidgin-otr usable on Internet tablets, however, I believe that some of my modifications are useful/good-looking enough to be considered for pidgin-otr on the desktop. I have lightly tested these patches both on the desktop and on the Internet tablet. The patches are available in the directory at ftp://go-nix.ca/incoming/pidgin-otr-patches/ Brief per-patch explanations: otr-button.diff: - Replace the button that goes into the conversation window with a GtkFrame containing two buttons: The original button on top, and a button labelled "Actions..." below it. The original button's behaviour is unchanged. The "Actions..." button causes the right-click menu to be popped up. In this sense, it behaves a little bit like a GtkOptionMenu. otr-clist-to-treeview.diff: - Remove the deprecated GtkCList widget and replace it with a GtkTreeView. This change allows for several UI "spruce-ups": - You can use pixbufs (same as those used on the button) to illustrate the current status for each fingerprint in the list (instead of mere text like "Private", "Not private", etc.) - You can use checkboxes to indicate whether the fingerprint is verified (again, instead of mere text like "Yes" and "No") To make it possible to use the same pixbufs in both the button and the tree view, I had to move the xpm static data from gtk-dialogs.c to gtk-ui.c and create a function that converts the static data to a GdkPixbuf. The otr_icon function then uses this new function (whose prototype is in gtk-ui.h, now included from gtk-dialog.h) to create the GtkImage as before. A side effect of this is that these pixbufs can now be used to make the four "Verify fingerprint", "Start private connection", etc. buttons look better by putting an image on them. I used the following images: "Start private connection" TRUST_PRIVATE "End private connection" TRUST_FINISHED "Verify fingerprint" GTK_STOCK_YES "Forget fingerprint" GTK_STOCK_DELETE otr-explanation-via-imhtml.diff: - Replace the GtkExpander-within-GtkExpander arrangement with only the outer GtkExpander, and render the inner GtkExpander as a link inside GtkIMHTML markup. IOW, there is now only one expander containing a scrolled window with a GtkIMHTML inside. The IMHTML widget contains the initial explanation, plus a link labelled "+ Explain further". When clicked, the url-clicked handler deletes all text starting with the "+" and up to the end of the GtkIMHTML and replaces it with a link labelled "- Hide explanation" and the longer explanation. URLs in the longer explanation are opened in the Web browser via purple_notify_uri as before. When the user clicks "- Hide explanation" it toggles back to "+ Explain further". Caveat: The long explanation causes the imhtml to scroll to the end. There is code in place to put "- Hide explanation" and the beginning of the long explanation to the top of the imhtml when the user clicks "+ Explain further". This code works in 2.0.2, but there has been a regression since then whereby pidgin seems to ignore the GTK_IMHTML_NO_SCROLL flag in the gtk_imhtml_append_text call. I posted a bug about it: http://developer.pidgin.im/ticket/2315 otr-generate-key-via-thread.diff: - Do not freeze Pidgin while generating a key. GLib provides several preprocessor directives which can bracket code that uses threads so that, if compiled, it's very, very likely to also work at runtime. pidgin-otr already has a mechanism for blocking the generate() function so that it only returns after the key is done. Unfortunately, the key is generated on the main thread, blocking the GMain event handling code. I have pushed the function onto a new GThread. I use the main loop to tell the main thread that generation is complete in the following way: The new GThread adds an idle handler to the main context and quits. The idle handler, which runs in the main thread, toggles a boolean variable and removes itself from the list of sources. The boolean variable then unblocks the code as before. The upshot is that Pidgin remains responsive while a key is being generated. Caveat: - The user can quit Pidgin while a key is being generated. This causes a segfault. Not a typical use case though, I would think. - Cannot start a private conversation while a key is being generated because gcrypt fails with some assertion otr-pidgin-frames-and-spacings: - Make the plugin configure dialog look more like Pidgin's own preferences dialog. I have replaced the GtkFrame widgets used to enclose the various groups of settings with pidgin_make_frame. I have also replaced numerous hard-coded border widths and spacings with Pidgin's #defined spacing and border width values PIDGIN_HIG_BORDER, PIDGIN_HIG_CAT_SPACE, and PIDGIN_HIG_BOX_SPACE. In addition to the above changes, I have, in some places changed the arrangement of widgets a little bit (cleaning things up, perhaps). For example, instead of a GtkHBox with two empty labels with the aim of centering a widget between them, I used a GtkAlignment. I have created a demo of my changes: http://www.youtube.com/watch?v=zPtnlqEZPeY Please let me know what you think! Gabriel From mail@scottellis.com.au Tue Jul 31 01:24:50 2007 From: mail@scottellis.com.au (Scott Ellis) Date: Tue, 31 Jul 2007 10:24:50 +1000 Subject: [OTR-dev] add_appdata not called (3.1)? Message-ID: <96e269140707301724k61097756n80cfadf37e6ea941@mail.gmail.com> ------=_Part_50018_33389769.1185841490868 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, FYI - Just upgraded to libotr 3.1, and it seems that the 'add_appdata' callback isn't functioning any longer. Scott ------=_Part_50018_33389769.1185841490868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

FYI - Just upgraded to libotr 3.1, and it seems that the 'add_appdata' callback isn't functioning any longer.

Scott
------=_Part_50018_33389769.1185841490868-- From ian@cypherpunks.ca Tue Jul 31 02:12:14 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 30 Jul 2007 21:12:14 -0400 Subject: [OTR-dev] add_appdata not called (3.1)? In-Reply-To: <96e269140707301724k61097756n80cfadf37e6ea941@mail.gmail.com> References: <96e269140707301724k61097756n80cfadf37e6ea941@mail.gmail.com> Message-ID: <20070731011214.GD3751@yoink.cs.uwaterloo.ca> On Tue, Jul 31, 2007 at 10:24:50AM +1000, Scott Ellis wrote: > Hi All, > > FYI - Just upgraded to libotr 3.1, and it seems that the 'add_appdata' > callback isn't functioning any longer. Huh. It looks like it's still being called. Can you be more specific? otrl_message_sending and otrl_message_receiving each call otrl_context_find with the add_appdata parameter, and that routine hasn't changed in over two years. Thanks, - Ian From mail@scottellis.com.au Tue Jul 31 03:03:34 2007 From: mail@scottellis.com.au (Scott Ellis) Date: Tue, 31 Jul 2007 12:03:34 +1000 Subject: [OTR-dev] add_appdata not called (3.1)? In-Reply-To: <20070731011214.GD3751@yoink.cs.uwaterloo.ca> References: <96e269140707301724k61097756n80cfadf37e6ea941@mail.gmail.com> <20070731011214.GD3751@yoink.cs.uwaterloo.ca> Message-ID: <96e269140707301903i330cddectc4a9edbde4bb2ba3@mail.gmail.com> ------=_Part_50754_25385891.1185847414207 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline you're completely correct - i didn't reallise it was also being called by the 'read fingerprints' function. sorry. On 7/31/07, Ian Goldberg wrote: > > On Tue, Jul 31, 2007 at 10:24:50AM +1000, Scott Ellis wrote: > > Hi All, > > > > FYI - Just upgraded to libotr 3.1, and it seems that the 'add_appdata' > > callback isn't functioning any longer. > > Huh. It looks like it's still being called. Can you be more specific? > > otrl_message_sending and otrl_message_receiving each call > otrl_context_find with the add_appdata parameter, and that routine > hasn't changed in over two years. > > Thanks, > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > ------=_Part_50754_25385891.1185847414207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline you're completely correct - i didn't reallise it was also being called by the 'read fingerprints' function. sorry.

On 7/31/07, Ian Goldberg <ian@cypherpunks.ca> wrote:
On Tue, Jul 31, 2007 at 10:24:50AM +1000, Scott Ellis wrote:
> Hi All,
>
> FYI - Just upgraded to libotr 3.1, and it seems that the 'add_appdata'
> callback isn't functioning any longer.

Huh.  It looks like it's still being called.  Can you be more specific?

otrl_message_sending and otrl_message_receiving each call
otrl_context_find with the add_appdata parameter, and that routine
hasn't changed in over two years.

Thanks,

   - Ian
_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev

------=_Part_50754_25385891.1185847414207-- From paul@cypherpunks.ca Tue Jul 31 18:58:21 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Tue, 31 Jul 2007 13:58:21 -0400 (EDT) Subject: [OTR-dev] Slovak translation by Milan Plzik Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1141903542-1185904701=:32017 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached is the Slovak translation for pidgin-otr Paul --8323328-1141903542-1185904701=:32017 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; name=pidgin-otr.sk.po Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=pidgin-otr.sk.po IyBTT01FIERFU0NSSVBUSVZFIFRJVExFLg0KIyBDb3B5cmlnaHQgKEMpIFlF QVIgVEhFIFBBQ0tBR0UnUyBDT1BZUklHSFQgSE9MREVSDQojIFRoaXMgZmls ZSBpcyBkaXN0cmlidXRlZCB1bmRlciB0aGUgc2FtZSBsaWNlbnNlIGFzIHRo ZSBQQUNLQUdFIHBhY2thZ2UuDQojIEZJUlNUIEFVVEhPUiA8RU1BSUxAQURE UkVTUz4sIFlFQVIuDQojDQojLCBmdXp6eQ0KbXNnaWQgIiINCm1zZ3N0ciAi Ig0KIlByb2plY3QtSWQtVmVyc2lvbjogUEFDS0FHRSBWRVJTSU9OXG4iDQoi UmVwb3J0LU1zZ2lkLUJ1Z3MtVG86IFxuIg0KIlBPVC1DcmVhdGlvbi1EYXRl OiAyMDA3LTA3LTI0IDE1OjQ3LTA0MDBcbiINCiJQTy1SZXZpc2lvbi1EYXRl OiAyMDA3LTA3LTMxIDE5OjQ4KzAyMDBcbiINCiJMYXN0LVRyYW5zbGF0b3I6 IE1pbGFuIFBsemlrIDxlbWVtcGlAZ21haWwuY29tPlxuIg0KIkxhbmd1YWdl LVRlYW06IFNsb3ZhayA8c2staTE4bkBsaXN0cy5saW51eC5zaz5cbiINCiJN SU1FLVZlcnNpb246IDEuMFxuIg0KIkNvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD11dGY4XG4iDQoiQ29udGVudC1UcmFuc2Zlci1FbmNvZGlu ZzogOGJpdFxuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6OTEzIC4uL2d0ay1k aWFsb2cuYzoyMDk1DQptc2dpZCAiX1doYXQncyB0aGlzPyINCm1zZ3N0ciAi xIxvIGplIF90b3RvPyINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjkyNA0KbXNn aWQgIl9Nb3JlLi4uIg0KbXNnc3RyICJfVmlhYy4uLiINCg0KIy4gQ3JlYXRl IHRoZSBBZHZhbmNlZC4uLiBidXR0b24sIGFuZCBsZWZ0LWp1c3RpZnkgaXQu ICBUaGlzDQojLiAqIGludm9sdmVzIGFkZGluZyB0aGUgYnV0dG9uLCBhbmQg YSBibGFuayBsYWJlbCBhcyBhIHNwYWNlciwgYW5kDQojLiAqIHJlb3JkZXJp bmcgdGhlbSBzbyB0aGF0IHRoZXkncmUgYXQgdGhlIGJlZ2lubmluZy4NCiM6 IC4uL2d0ay1kaWFsb2cuYzo5ODANCm1zZ2lkICJBZHZhbmNlZC4uLiINCm1z Z3N0ciAiUm96xaHDrXJlbsOpLi4uIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6 MTAyNQ0KbXNnaWQgIkVudGVyIHNlY3JldCBoZXJlIg0KbXNnc3RyICIiDQoN CiM6IC4uL2d0ay1kaWFsb2cuYzoxMDMwDQptc2dpZCAiVGhpcyBidWRkeSBp cyBhbHJlYWR5IGF1dGhlbnRpY2F0ZWQuIg0KbXNnc3RyICJUZW50byBwcmlh dGXEviB1xb4gamUgYXV0ZW50aWZpa292YW7DvS4iDQoNCiM6IC4uL2d0ay1k aWFsb2cuYzoxMDQ5DQptc2dpZCAiIg0KIlRvIGF1dGhlbnRpY2F0ZSwgcGlj ayBhIHNlY3JldCBrbm93biBvbmx5IHRvIHlvdSBhbmQgeW91ciBidWRkeS4g IEVudGVyIHRoaXMgIg0KInNlY3JldCwgdGhlbiB3YWl0IGZvciB5b3VyIGJ1 ZGR5IHRvIGVudGVyIGl0IHRvby4gIElmIHRoZSBzZWNyZXRzIGRvbid0ICIN CiJtYXRjaCwgdGhlbiB5b3UgbWF5IGJlIHRhbGtpbmcgdG8gYW4gaW1wb3N0 ZXIuIg0KbXNnc3RyICIiDQoiTmEgYXV0ZW50aWZpa8OhY2l1IHBvdcW+aXRl IGhlc2xvLCBrdG9yw6kgcG96bsOhdGUgaWJhIFZ5IGEgcHJpYXRlxL4uIFph ZGFqdGUgdG90byAiDQoiaGVzbG8gYSBwb8SNa2FqdGUsIGvDvW0gaG8gemFk w6EgYWogcHJpYXRlxL4uIEFrIHNhIGhlc2zDoSBuZXpob2R1asO6LCBqZSBy aXppa28sICINCiLFvmUgc2Egcm96cHLDoXZhdGUgcyBwb2R2b2Ruw61rb20u Ig0KIzogLi4vZ3RrLWRpYWxvZy5jOjEwNTMNCg0KbXNnaWQgIiINCiJJZiB5 b3VyIGJ1ZGR5IHVzZXMgbXVsdGlwbGUgSU0gYWNjb3VudHMgb3IgbXVsdGlw bGUgY29tcHV0ZXJzLCB5b3UgbWF5IGhhdmUgIg0KInRvIGF1dGhlbnRpY2F0 ZSBtdWx0aXBsZSB0aW1lcy4gIEhvd2V2ZXIsIGFzIGxvbmcgYXMgdGhleSB1 c2UgYW4gYWNjb3VudCBhbmQgIg0KImNvbXB1dGVyIHRoYXQgeW91J3ZlIHNl ZW4gYmVmb3JlLCB5b3UgZG9uJ3QgbmVlZCB0byBhdXRoZW50aWNhdGUgZWFj aCAiDQoiaW5kaXZpZHVhbCBjb252ZXJzYXRpb24uIg0KbXNnc3RyICIiDQoi QWsgVsOhxaEgcHJpYXRlxL4gcG91xb7DrXZhIHZpYWNlcm8gSU0ga29udCBh bGVibyB2aWFjZXJvIHBvxI3DrXRhxI1vdiwgbW/Fvm5vIGhvICINCiJidWRl dGUgbXVzaWV0IGF1dGVudGlmaWtvdmHFpSB2aWFja3LDoXQuIEF2xaFhaywg cG9raWHEviBwb3XFvsOtdmEga29udG8gYSBwb8SNw610YcWlLCAiDQoia3Rv csO9IHN0ZSB1xb4gdmlkZWxpLCBuZXRyZWJhIGF1dGVudGlmaWtvdmHFpSBr YcW+ZMO9IHJvemhvdm9yLiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjEwNTgg Li4vZ3RrLWRpYWxvZy5jOjEzMjIgLi4vZ3RrLWRpYWxvZy5jOjEzMjYNCiM6 IC4uL2d0ay1kaWFsb2cuYzoxNDIzIC4uL2d0ay1kaWFsb2cuYzoxNTkwIC4u L2d0ay1kaWFsb2cuYzoxNzUwDQojOiAuLi9ndGstZGlhbG9nLmM6MTg1MCAu Li9ndGstZGlhbG9nLmM6MTkzNQ0KbXNnaWQgIj9sYW5nPWVuIg0KbXNnc3Ry ICI/bGFuZz1zayINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjEwNTkNCm1zZ2lk ICJDbGljayBoZXJlIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGF1dGhl bnRpY2F0aW9uIGluIE9UUi4iDQptc2dzdHIgIktsaWtuaXRlIHNlbSBwcmUg dmlhYyBpbmZvcm3DoWNpw60gbyBhdXRlbnRpZmlrw6FjaWkgdiBPVFIuIg0K DQojOiAuLi9ndGstZGlhbG9nLmM6MTA2Mw0KbXNnaWQgIiINCiJBdXRoZW50 aWNhdGluZyBhIGJ1ZGR5IGhlbHBzIGVuc3VyZSB0aGF0IHRoZSBwZXJzb24g eW91IGFyZSB0YWxraW5nIHRvIGlzICINCiJ3aG8gdGhleSBjbGFpbSB0byBi ZS4iDQptc2dzdHIgIiINCiJBdXRlbnRpZmlrw6FjaWEgcHJpYXRlxL5hIHBv bcOhaGEgemFiZXpwZcSNacWlLCDFvmUgb3NvYmEsIHMga3Rvcm91IHNhIHJv enByw6F2YXRlLCAiDQoiamUgc2t1dG/EjW5lIHTDoSwgemEga3RvcsO6IHNh IHZ5ZMOhdmEuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTExMw0KbXNnaWQg IkF1dGhlbnRpY2F0aW5nIEJ1ZGR5Ig0KbXNnc3RyICJBdXRlbnRpZmlrdWpl bSBwcmlhdGXEvmEuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTE0MA0KbXNn aWQgIkF1dGhlbnRpY2F0aW5nIg0KbXNnc3RyICJBdXRlbnRpZmlrdWplbSIN Cg0KIzogLi4vZ3RrLWRpYWxvZy5jOjEyMDENCm1zZ2lkICJHZW5lcmF0aW5n IHByaXZhdGUga2V5Ig0KbXNnc3RyICJHZW5lcnVqZW0gc8O6a3JvbW7DvSBr xL7DusSNIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTIwMg0KbXNnaWQgIlBs ZWFzZSB3YWl0Ig0KbXNnc3RyICJQcm9zw61tIMSNYWthanRlIg0KDQojOiAu Li9ndGstZGlhbG9nLmM6MTIxMCAuLi9ndGstZGlhbG9nLmM6MTYyNyAuLi9n dGstZGlhbG9nLmM6MTY2NA0KIzogLi4vZ3RrLXVpLmM6MTc1IC4uL290ci1w bHVnaW4uYzoxMTUgLi4vb3RyLXBsdWdpbi5jOjIxMiAuLi91aS5jOjExMA0K bXNnaWQgIlVua25vd24iDQptc2dzdHIgIk5lem7DoW15Ig0KDQojLiBDcmVh dGUgdGhlIFBsZWFzZSBXYWl0Li4uIGRpYWxvZw0KIzogLi4vZ3RrLWRpYWxv Zy5jOjEyMTMNCiMsIGMtZm9ybWF0DQptc2dpZCAiR2VuZXJhdGluZyBwcml2 YXRlIGtleSBmb3IgJXMgKCVzKS4uLiINCm1zZ3N0ciAiR2VuZXJ1amVtIHPD umtyb21uw70ga8S+w7rEjSBwcmUgJXMgKCVzKS4uLiINCg0KIzogLi4vZ3Rr LWRpYWxvZy5jOjEyNTgNCiMsIGMtZm9ybWF0DQptc2dpZCAiJXMgRG9uZS4i DQptc2dzdHIgIiVzIERva29uxI1lbsOpLiINCg0KIzogLi4vZ3RrLWRpYWxv Zy5jOjEzMjANCiMsIGMtZm9ybWF0DQptc2dpZCAiIg0KIiVzIGlzIGNvbnRh Y3RpbmcgeW91IGZyb20gYW4gdW5yZWNvZ25pemVkIGNvbXB1dGVyLiAgWW91 IHNob3VsZCA8YSBocmVmPVwiJXMlIg0KInNcIj5hdXRoZW50aWNhdGU8L2E+ IHRoaXMgYnVkZHkuIg0KbXNnc3RyICIiDQoiJXMgdsOhcyBrb250YWt0dWpl IHogbmV6bsOhbWVobyBwb8SNw610YcSNYS4gVG9odG8gcHJpYXRlxL5hIGJ5 IHN0ZSBtYWxpIDxhICINCiJocmVmPVwiJXMlc1wiPmF1dGVudGlmaWtvdmHF pTwvYT4uIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTMyNA0KIywgYy1mb3Jt YXQNCm1zZ2lkICIiDQoiJXMgaGFzIG5vdCBiZWVuIGF1dGhlbnRpY2F0ZWQg eWV0LiAgWW91IHNob3VsZCA8YSBocmVmPVwiJXMlcyINCiJcIj5hdXRoZW50 aWNhdGU8L2E+IHRoaXMgYnVkZHkuIg0KbXNnc3RyICIiDQoiJXMgZcWhdGUg bmVib2wgYXV0ZW50aWZpa292YW7DvS4gVG9odG8gcHJpYXRlxL5hIGJ5IHN0 ZSBtYWxpIDxhIGhyZWY9XCIlcyVzXCI+Ig0KImF1dGVudGlmaWtvdmHFpTwv YT4uIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTM2NSAuLi9ndGstdWkuYzo3 Ng0KbXNnaWQgIkZpbmlzaGVkIg0KbXNnc3RyICJEb2tvbsSNZW7DqSINCg0K IzogLi4vZ3RrLWRpYWxvZy5jOjEzNjYgLi4vZ3RrLXVpLmM6NzUNCm1zZ2lk ICJQcml2YXRlIg0KbXNnc3RyICJTw7prcm9tbsOpIg0KDQojOiAuLi9ndGst ZGlhbG9nLmM6MTM2NyAuLi9ndGstdWkuYzo3NA0KbXNnaWQgIlVudmVyaWZp ZWQiDQptc2dzdHIgIk5lb3ZlcmVuw6kiDQoNCiM6IC4uL2d0ay1kaWFsb2cu YzoxMzY4IC4uL2d0ay11aS5jOjczDQptc2dpZCAiTm90IHByaXZhdGUiDQpt c2dzdHIgIk5lc8O6a3JvbW7DqSINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjEz NzANCm1zZ2lkICJTdGFydCBhIHByaXZhdGUgY29udmVyc2F0aW9uIg0KbXNn c3RyICJaYcSNYcWlIHPDumtyb21uw70gcm96aG92b3IiDQoNCiM6IC4uL2d0 ay1kaWFsb2cuYzoxMzcxDQptc2dpZCAiUmVmcmVzaCB0aGUgcHJpdmF0ZSBj b252ZXJzYXRpb24iDQptc2dzdHIgIk9ibm92acWlIHPDumtyb21uw70gcm96 aG92b3IiDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxMzc1DQptc2dpZCAiU3Rh cnQgX3ByaXZhdGUgY29udmVyc2F0aW9uIg0KbXNnc3RyICJaYcSNYcWlIF9z w7prcm9tbsO9IHJvemhvdm9yIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTM3 Ng0KbXNnaWQgIlJlZnJlc2ggX3ByaXZhdGUgY29udmVyc2F0aW9uIg0KbXNn c3RyICJPYm5vdmnFpSBfc8O6a3JvbW7DvSByb3pob3ZvciINCg0KIzogLi4v Z3RrLWRpYWxvZy5jOjE1NTUNCm1zZ2lkICJJIGhhdmUgbm90Ig0KbXNnc3Ry ICJOZW92ZXJpbCBzb20sIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTU1Ng0K bXNnaWQgIkkgaGF2ZSINCm1zZ3N0ciAiT3ZlcmlsIHNvbSwiDQoNCiM6IC4u L2d0ay1kaWFsb2cuYzoxNTU4DQptc2dpZCAiIHZlcmlmaWVkIHRoYXQgdGhp cyBpcyBpbiBmYWN0IHRoZSBjb3JyZWN0Ig0KbXNnc3RyICIgxb5lIHRvdG8g amUgdGVuIHNwcsOhdm55Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTU2Nw0K IywgYy1mb3JtYXQNCm1zZ2lkICJmaW5nZXJwcmludCBmb3IgJXMuIg0KbXNn c3RyICJvZHRsYcSNb2sgcHJzdGEgcHJlICVzLiINCg0KIzogLi4vZ3RrLWRp YWxvZy5jOjE1NzkNCm1zZ2lkICIiDQoiVG8gdmVyaWZ5IHRoZSBmaW5nZXJw cmludCwgY29udGFjdCB5b3VyIGJ1ZGR5IHZpYSBzb21lIDxpPm90aGVyPC9p PiAiDQoiYXV0aGVudGljYXRlZCBjaGFubmVsLCBzdWNoIGFzIHRoZSB0ZWxl cGhvbmUgb3IgR1BHLXNpZ25lZCBlbWFpbC4gIEVhY2ggb2YgIg0KInlvdSBz aG91bGQgdGVsbCB5b3VyIGZpbmdlcnByaW50IHRvIHRoZSBvdGhlci4iDQpt c2dzdHIgIiINCiJOYSBvdmVyZW5pZSBvZHRsYcSNa3UgcHJzdGEga29udGFr dHVqdGUgVsOhxaFobyBwcmlhdGXEvmEgcG9tb2NvdSA8aT5pbsOpaG88L2k+ ICINCiJhdXRlbnRpZmlrb3ZhbsOpaG8ga2Fuw6FsdSwgYWtvIG5hcHLDrWts YWQgdGVsZWbDs24gYWxlYm8gZS1tYWlsIHBvZHDDrXNhbsO9ICINCiJwb21v Y291IEdQRy4gT2JhamEgYnkgc3RlIHNpIG1hbGkgbmF2esOham9tIHBvdmVk YcWlIG9kdGxhxI1reSBwcnN0b3YuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6 MTU4Mw0KbXNnaWQgIiINCiJJZiBldmVyeXRoaW5nIG1hdGNoZXMgdXAsIHlv dSBzaG91bGQgaW5kaWNhdGUgaW4gdGhlIGFib3ZlIGRpYWxvZyB0aGF0IHlv dSAiDQoiPGI+aGF2ZTwvYj4gdmVyaWZpZWQgdGhlIGZpbmdlcnByaW50LiIN Cm1zZ3N0ciAiIg0KIkFrIHNhIHbFoWV0a28gemhvZHVqZSwgbWFsaSBieSBz dGUgdiBkaWFsw7NndSB2ecWhxaFpZSBvem5hxI1pxaUsIMW+ZSA8Yj5zdGUg Ig0KInNrb250cm9sb3ZhbGk8L2I+IG9kdGxhxI1vayBwcnN0YS4iDQoNCiM6 IC4uL2d0ay1kaWFsb2cuYzoxNTg1DQptc2dpZCAiIg0KIklmIHlvdXIgYnVk ZHkgaGFzIG1vcmUgdGhhbiBvbmUgSU0gYWNjb3VudCwgb3IgdXNlcyBtb3Jl IHRoYW4gb25lIGNvbXB1dGVyLCAiDQoiaGUgbWF5IGhhdmUgbXVsdGlwbGUg ZmluZ2VycHJpbnRzLiINCm1zZ3N0ciAiIg0KIkFrIFbDocWhIHByaWF0ZcS+ IG3DoSB2aWFjIGFrbyBqZWRubyBJTSBrb250bywgYWxlYm8gcG91xb7DrXZh IHZpYWMgYWtvIGplZGVuICINCiJwb8SNw610YcSNLCBtw7TFvmUgbWHFpSB2 aWFjZXJvIG9kdGxhxI1rb3YgcHJzdG92LiINCg0KIzogLi4vZ3RrLWRpYWxv Zy5jOjE1ODcNCm1zZ2lkICIiDQoiSG93ZXZlciwgdGhlIG9ubHkgd2F5IGFu IGltcG9zdGVyIGNvdWxkIGR1cGxpY2F0ZSBvbmUgb2YgeW91ciBidWRkeSdz ICINCiJmaW5nZXJwcmludHMgaXMgYnkgc3RlYWxpbmcgaW5mb3JtYXRpb24g ZnJvbSBoZXIvaGlzIGNvbXB1dGVyLiINCm1zZ3N0ciAiIg0KIkplZGluw70g c3DDtHNvYiwgYWtvIG1vaG9sIHBvZHZvZG7DrWsgZHVwbGlrb3ZhxaUgamVk ZW4geiBvZHRsYcSNa292IHByc3RvdiBWw6HFoWhvICINCiJwcmlhdGXEvmEs IGplIHVrcmFkbsO6xaUgaW5mb3Jtw6FjaWUgeiBqZWovamVobyBwb8SNw610 YcSNYS4iDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxNTkxDQptc2dpZCAiQ2xp Y2sgaGVyZSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBmaW5nZXJwcmlu dHMuIg0KbXNnc3RyICJLbGlrbml0ZSBzZW0gcHJlIHZpYWMgaW5mb3Jtw6Fj acOtIG8gb2R0bGHEjWtvY2ggcHJzdG92LiINCg0KIzogLi4vZ3RrLWRpYWxv Zy5jOjE1OTQNCm1zZ2lkICIiDQoiQSA8Yj5maW5nZXJwcmludDwvYj4gaXMg YSB1bmlxdWUgaWRlbnRpZmllciB0aGF0IHlvdSBzaG91bGQgdXNlIHRvICIN CiJhdXRoZW50aWNhdGUgeW91ciBidWRkeS4iDQptc2dzdHIgIiINCiI8Yj5P ZHRsYcSNb2sgcHJzdGE8L2I+IGplIGplZG5vem5hxI1uw70gaWRlbnRpZmlr w6F0b3IsIGt0b3LDvSBieSBzdGUgbWFsaSBwb3XFvmnFpSAiDQoibmEgYXV0 ZW50aWZpa292YW5pZSBWw6HFoWhvIHByaWF0ZcS+YS4iDQoNCiM6IC4uL2d0 ay1kaWFsb2cuYzoxNjE2DQojLCBjLWZvcm1hdA0KbXNnaWQgIlZlcmlmeSBm aW5nZXJwcmludCBmb3IgJXMiDQptc2dzdHIgIlNrb250cm9sdWp0ZSBvZHRs YcSNb2sgcHJzdGEgcHJlICVzIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTYy MA0KbXNnaWQgIltub25lXSINCm1zZ3N0ciAiW8W+aWFkZW5dIg0KDQojOiAu Li9ndGstZGlhbG9nLmM6MTYyOA0KIywgYy1mb3JtYXQNCm1zZ2lkICIiDQoi RmluZ2VycHJpbnQgZm9yIHlvdSwgJXMgKCVzKTpcbiINCiIlc1xuIg0KIlxu Ig0KIlB1cnBvcnRlZCBmaW5nZXJwcmludCBmb3IgJXM6XG4iDQoiJXNcbiIN Cm1zZ3N0ciAiIg0KIk9kdGxhxI1vayBwcmUgVsOhcywgJXMgKCVzKTpcbiIN CiIlc1xuIg0KIlxuIg0KIsOaZGFqbsO9IG9kdGxhxI1vayBwcmUgJXM6XG4i DQoiJXNcbiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE2MzMgLi4vZ3RrLXVp LmM6NjgxDQptc2dpZCAiVmVyaWZ5IGZpbmdlcnByaW50Ig0KbXNnc3RyICJT a29udHJvbHVqdGUgb2R0bGHEjW9rIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6 MTY2MA0KIywgYy1mb3JtYXQNCm1zZ2lkICJBdXRoZW50aWNhdGUgJXMiDQpt c2dzdHIgIkF1dGVudGlmaWt1anRlICVzIg0KDQojOiAuLi9ndGstZGlhbG9n LmM6MTY2NQ0KIywgYy1mb3JtYXQNCm1zZ2lkICJFbnRlciBhIHNlY3JldCBr bm93biBvbmx5IHRvICVzIGFuZCB5b3Vyc2VsZi5cbiINCm1zZ3N0ciAiWmFk YWp0ZSBoZXNsbyB6bsOhbWUgaWJhICVzIGEgVsOhbS5cbiINCg0KIzogLi4v Z3RrLWRpYWxvZy5jOjE2NjgNCm1zZ2lkICJBdXRoZW50aWNhdGUgYnVkZHki DQptc2dzdHIgIkF1dGVudGlmaWt1anRlIHByaWF0ZcS+YSINCg0KIzogLi4v Z3RrLWRpYWxvZy5jOjE3MDANCm1zZ2lkICJBbiBlcnJvciBvY2N1cnJlZCBk dXJpbmcgYXV0aGVudGljYXRpb24uIg0KbXNnc3RyICJOYXN0YWxhIGNoeWJh IHByaSBhdXRlbnRpZmlrw6FjaWkuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6 MTcxNg0KbXNnaWQgIkF1dGhlbnRpY2F0aW9uIHN1Y2Nlc3NmdWwuIg0KbXNn c3RyICJBdXRlbnRpZmlrw6FjaWEgYm9sYSDDunNwZcWhbsOhIg0KDQojOiAu Li9ndGstZGlhbG9nLmM6MTcxOQ0KbXNnaWQgIkF1dGhlbnRpY2F0aW9uIGZh aWxlZC4iDQptc2dzdHIgIkF1dGVudGlmaWvDoWNpYSB6bHloYWxhIg0KDQoj OiAuLi9ndGstZGlhbG9nLmM6MTc0NA0KIywgYy1mb3JtYXQNCm1zZ2lkICJQ cml2YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVzIHN0YXJ0ZWQuJXMiDQptc2dz dHIgIlPDumtyb21uw70gcm96aG92b3IgcyAlcyB6YcSNYWwuJXMiDQoNCiM6 IC4uL2d0ay1kaWFsb2cuYzoxNzQ4DQojLCBjLWZvcm1hdA0KbXNnaWQgIjxh IGhyZWY9XCIlcyVzXCI+VW52ZXJpZmllZDwvYT4gY29udmVyc2F0aW9uIHdp dGggJSVzIHN0YXJ0ZWQuJSVzIg0KbXNnc3RyICI8YSBocmVmPVwiJXMlc1wi Pk5lb3ZlcmVuw708L2E+IHJvemhvdm9yIHMgJSVzIHphxI1hbC4lJXMiDQoN CiMuIFRoaXMgbGFzdCBjYXNlIHNob3VsZCBuZXZlciBoYXBwZW4sIHNpbmNl IHdlIGtub3cNCiMuICogd2UncmUgaW4gRU5DUllQVEVELg0KIzogLi4vZ3Rr LWRpYWxvZy5jOjE3NTYNCiMsIGMtZm9ybWF0DQptc2dpZCAiTm90IHByaXZh dGUgY29udmVyc2F0aW9uIHdpdGggJXMgc3RhcnRlZC4lcyINCm1zZ3N0ciAi TmVzw7prcm9tbsO9IHJvemhvdm9yIHMgJXMgemHEjWFsLiVzIg0KDQojOiAu Li9ndGstZGlhbG9nLmM6MTc2MiAuLi9ndGstZGlhbG9nLmM6MTg2Mw0KbXNn aWQgIiAgV2FybmluZzogdXNpbmcgb2xkIHByb3RvY29sIHZlcnNpb24gMS4i DQptc2dzdHIgIiAgVmFyb3ZhbmllOiBwb3XFvnZhbSBzdGFyw70gcHJvdG9r b2wgdmVyemllIDEuIg0KDQojOiAuLi9ndGstZGlhbG9nLmM6MTc4Mg0KIywg Yy1mb3JtYXQNCm1zZ2lkICJQcml2YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVz IGxvc3QuIg0KbXNnc3RyICJTw7prcm9tbsO9IHJvemhvdm9yIHMgJXMgc3Ry YXRlbsO9LiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE4MTcNCiMsIGMtZm9y bWF0DQptc2dpZCAiIg0KIiVzIGhhcyBlbmRlZCBoaXMvaGVyIHByaXZhdGUg Y29udmVyc2F0aW9uIHdpdGggeW91OyB5b3Ugc2hvdWxkIGRvIHRoZSBzYW1l LiINCm1zZ3N0ciAiIg0KIiVzIHVrb27EjWlsKC1hKSBzdm9qIHPDumtyb21u w70gcm96aG92b3IgcyBWYW1pOyBtYWxpIGJ5IHN0ZSBzcHJhdmnFpSB0byBp c3TDqS4iDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzoxODQyDQojLCBjLWZvcm1h dA0KbXNnaWQgIlN1Y2Nlc3NmdWxseSByZWZyZXNoZWQgdGhlIHByaXZhdGUg Y29udmVyc2F0aW9uIHdpdGggJXMuJXMiDQptc2dzdHIgIlPDumtyb21uw70g cm96aG92b3IgcyAlcyDDunNwZcWhbmUgb2Jub3ZlbsO9LiVzIg0KDQojOiAu Li9ndGstZGlhbG9nLmM6MTg0Nw0KIywgYy1mb3JtYXQNCm1zZ2lkICIiDQoi U3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgPGEgaHJlZj1cIiVzJXNcIj51 bnZlcmlmaWVkPC9hPiBjb252ZXJzYXRpb24gd2l0aCAiDQoiJSVzLiUlcyIN Cm1zZ3N0ciAiIg0KIjxhIGhyZWY9XCIlcyVzXCI+TmVvdmVyZW7DvTwvYT4g cm96aG92b3IgcyAlJXMgw7pzcGXFoW5lIG9ibm92ZW7DvS4lJXMiDQoNCiMu IFRoaXMgbGFzdCBjYXNlIHNob3VsZCBuZXZlciBoYXBwZW4sIHNpbmNlIHdl IGtub3cNCiMuICogd2UncmUgaW4gRU5DUllQVEVELg0KIzogLi4vZ3RrLWRp YWxvZy5jOjE4NTYNCiMsIGMtZm9ybWF0DQptc2dpZCAiU3VjY2Vzc2Z1bGx5 IHJlZnJlc2hlZCB0aGUgbm90IHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGgg JXMuJXMiDQptc2dzdHIgIk5lc8O6a3JvbW7DvSByb3pob3ZvciBzICVzIMO6 c3BlxaFuZSBvYm5vdmVuw70uJXMiDQoNCiM6IC4uL2d0ay1kaWFsb2cuYzox ODgzDQojLCBjLWZvcm1hdA0KbXNnaWQgIkF0dGVtcHRpbmcgdG8gcmVmcmVz aCB0aGUgcHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCAlcy4uLiINCm1zZ3N0 ciAiUG9rw7rFoWFtIHNhIG9ibm92acWlIHPDumtyb21uw70gcm96aG92b3Ig cyAlcy4uLiINCg0KIzogLi4vZ3RrLWRpYWxvZy5jOjE4ODUNCiMsIGMtZm9y bWF0DQptc2dpZCAiQXR0ZW1wdGluZyB0byBzdGFydCBhIHByaXZhdGUgY29u dmVyc2F0aW9uIHdpdGggJXMuLi4iDQptc2dzdHIgIlBva8O6xaFhbSBzYSB6 YcSNYcWlIHPDumtyb21uw70gcm96aG92b3IgcyAlcy4uLiINCg0KIzogLi4v Z3RrLWRpYWxvZy5jOjIwNDUNCm1zZ2lkICJPVFI6Ig0KbXNnc3RyICJPVFI6 Ig0KDQojOiAuLi9ndGstZGlhbG9nLmM6MjA1NA0KbXNnaWQgIk9UUiBNZXNz YWdpbmciDQptc2dzdHIgIk9UUiBvZG9zaWVsYW5pZSBzcHLDoXYiDQoNCiM6 IC4uL2d0ay1kaWFsb2cuYzoyMDYwDQptc2dpZCAiX0VuZCBwcml2YXRlIGNv bnZlcnNhdGlvbiINCm1zZ3N0ciAiX1Vrb27EjWnFpSBzw7prcm9tbsO9IHJv emhvdm9yIg0KDQojLg0KIy4gKiBEb24ndCBzaG93IHRoZSBWZXJpZnkgZmlu Z2VycHJpbnQgbWVudSBvcHRpb24gYW55IG1vcmUuICBZb3UgY2FuDQojLiAq IHN0aWxsIGdldCB0byB0aGUgZGlhbG9nIHRocm91Z2ggQXV0aGVudGljYXRl IGNvbm5lY3Rpb24gLT4NCiMuICogQWR2YW5jZWQuLi4NCiMuICoNCiMuIG1l bnV2ZXJmID0gZ3RrX21lbnVfaXRlbV9uZXdfd2l0aF9tbmVtb25pYyhfKCJf VmVyaWZ5IGZpbmdlcnByaW50IikpOw0KIy4gZ3RrX21lbnVfc2hlbGxfYXBw ZW5kKEdUS19NRU5VX1NIRUxMKG1lbnUpLCBtZW51dmVyZik7DQojLiBndGtf d2lkZ2V0X3Nob3cobWVudXZlcmYpOw0KIy4NCiM6IC4uL2d0ay1kaWFsb2cu YzoyMDc4DQptc2dpZCAiX0F1dGhlbnRpY2F0ZSBidWRkeSINCm1zZ3N0ciAi X0F1dGVudGlmaWtvdmHFpSBwcmlhdGXEvmEiDQoNCiM6IC4uL2d0ay11aS5j Ojk2DQojLCBjLWZvcm1hdA0KbXNnaWQgIkZpbmdlcnByaW50OiAlLjgwcyIN Cm1zZ3N0ciAiT2R0bGHEjW9rIHByc3RhOiAlLjgwcyINCg0KIzogLi4vZ3Rr LXVpLmM6MTAwDQojLCBjLWZvcm1hdA0KbXNnaWQgIk5vIGtleSBwcmVzZW50 Ig0KbXNnc3RyICJOaWUgamUgZG9zdHVwbsO9IMW+aWFkZW4ga8S+w7rEjSIN Cg0KIzogLi4vZ3RrLXVpLmM6MTA1DQojLCBjLWZvcm1hdA0KbXNnaWQgIk5v IGFjY291bnQgYXZhaWxhYmxlIg0KbXNnc3RyICJOaWUgamUgZG9zdHVwbsOp IMW+aWFkbmUga29udG8iDQoNCiM6IC4uL2d0ay11aS5jOjE2NQ0KbXNnaWQg IlVudXNlZCINCm1zZ3N0ciAiTmVwb3XFvml0w6kiDQoNCiM6IC4uL2d0ay11 aS5jOjE3MQ0KbXNnaWQgIlllcyINCm1zZ3N0ciAiw4FubyINCg0KIzogLi4v Z3RrLXVpLmM6MTcxDQptc2dpZCAiTm8iDQptc2dzdHIgIk5pZSINCg0KIzog Li4vZ3RrLXVpLmM6Mzk2DQptc2dpZCAiRW5hYmxlIHByaXZhdGUgbWVzc2Fn aW5nIg0KbXNnc3RyICJaYXBuw7rFpSBzw7prcm9tbsOpIG9kb3NpZWxhbmll IHNwcsOhdiINCg0KIzogLi4vZ3RrLXVpLmM6Mzk4DQptc2dpZCAiQXV0b21h dGljYWxseSBpbml0aWF0ZSBwcml2YXRlIG1lc3NhZ2luZyINCm1zZ3N0ciAi QXV0b21hdGlja3kgaW5pY2lvdmHFpSBzw7prcm9tbsOpIG9kb3NpZWxhbmll IHNwcsOhdiINCg0KIzogLi4vZ3RrLXVpLmM6NDAwDQptc2dpZCAiUmVxdWly ZSBwcml2YXRlIG1lc3NhZ2luZyINCm1zZ3N0ciAiVnnFvmFkb3ZhxaUgc8O6 a3JvbW7DqSBvZG9zaWVsYW5pZSBzcHLDoXYiDQoNCiM6IC4uL2d0ay11aS5j OjQwMw0KbXNnaWQgIkRvbid0IGxvZyBPVFIgY29udmVyc2F0aW9ucyINCm1z Z3N0ciAiTmV6YXpuYW1lbsOhdmHFpSBPVFIgcm96aG92b3J5Ig0KDQojOiAu Li9ndGstdWkuYzo1MzENCm1zZ2lkICJNeSBwcml2YXRlIGtleXMiDQptc2dz dHIgIk1vamUgc8O6a3JvbW7DqSBrxL7DusSNZSINCg0KIzogLi4vZ3RrLXVp LmM6NTQwDQptc2dpZCAiS2V5IGZvciBhY2NvdW50OiINCm1zZ3N0ciAiS8S+ w7rEjSBwcmUga29udG86Ig0KDQojOiAuLi9ndGstdWkuYzo1NjUNCm1zZ2lk ICJHZW5lcmF0ZSINCm1zZ3N0ciAiR2VuZXJ1aiINCg0KIzogLi4vZ3RrLXVp LmM6NTk2DQptc2dpZCAiRGVmYXVsdCBPVFIgU2V0dGluZ3MiDQptc2dzdHIg IsWgdGFuZGFyZG7DqSBuYXN0YXZlbmlhIE9UUiINCg0KIzogLi4vZ3RrLXVp LmM6NjI1DQptc2dpZCAiU2NyZWVubmFtZSINCm1zZ3N0ciAiUG91xb7DrXZh dGXEvnNrw6kgbWVubyINCg0KIzogLi4vZ3RrLXVpLmM6NjI2DQptc2dpZCAi U3RhdHVzIg0KbXNnc3RyICJTdGF2Ig0KDQojOiAuLi9ndGstdWkuYzo2MjcN Cm1zZ2lkICJWZXJpZmllZCINCm1zZ3N0ciAiT3ZlcmVuw70iDQoNCiM6IC4u L2d0ay11aS5jOjYyOA0KbXNnaWQgIkZpbmdlcnByaW50Ig0KbXNnc3RyICJP ZHRsYcSNb2sgcHJzdGEiDQoNCiM6IC4uL2d0ay11aS5jOjYyOQ0KbXNnaWQg IkFjY291bnQiDQptc2dzdHIgIktvbnRvIg0KDQojOiAuLi9ndGstdWkuYzo2 NjUNCm1zZ2lkICJTdGFydCBwcml2YXRlIGNvbm5lY3Rpb24iDQptc2dzdHIg IlphxI1hxaUgc8O6a3JvbW7DvSByb3pob3ZvciINCg0KIzogLi4vZ3RrLXVp LmM6NjczDQptc2dpZCAiRW5kIHByaXZhdGUgY29ubmVjdGlvbiINCm1zZ3N0 ciAiVWtvbsSNacWlIHPDumtyb21uw70gcm96aG92b3IiDQoNCiM6IC4uL2d0 ay11aS5jOjY4OQ0KbXNnaWQgIkZvcmdldCBmaW5nZXJwcmludCINCm1zZ3N0 ciAiWmFidWRuw7rFpSBvZHRsYcSNb2sgcHJzdGEiDQoNCiM6IC4uL2d0ay11 aS5jOjczOA0KbXNnaWQgIkNvbmZpZyINCm1zZ3N0ciAiTmFzdGF2acWlIg0K DQojOiAuLi9ndGstdWkuYzo3NDANCm1zZ2lkICJLbm93biBmaW5nZXJwcmlu dHMiDQptc2dzdHIgIlpuw6FtZSBvZHRsYcSNa3kgcHJzdG92Ig0KDQojOiAu Li9ndGstdWkuYzo4MzggLi4vb3RyLXBsdWdpbi5jOjU3Nw0KbXNnaWQgIk9U UiBTZXR0aW5ncyINCm1zZ3N0ciAiTmFzdGF2ZW5pYSBPVFIiDQoNCiMuIFNl dCB0aGUgdGl0bGUNCiM6IC4uL2d0ay11aS5jOjg1Ng0KIywgYy1mb3JtYXQN Cm1zZ2lkICJPVFIgU2V0dGluZ3MgZm9yICVzIg0KbXNnc3RyICJPVFIgbmFz dGF2ZW5pYSBwcmUgJXMiDQoNCiMuIE1ha2UgdGhlIGNhc2NhZGVkIGNoZWNr Ym94ZXMNCiM6IC4uL2d0ay11aS5jOjg3Mw0KbXNnaWQgIlVzZSBkZWZhdWx0 IE9UUiBzZXR0aW5ncyBmb3IgdGhpcyBidWRkeSINCm1zZ3N0ciAiUHJlIHRv aHRvIHByaWF0ZcS+YSBwb3XFvmnFpSDFoXRhbmRhcmRuw6kgbmFzdGF2ZW5p YSINCg0KIzogLi4vb3RyLXBsdWdpbi5jOjExMw0KIywgYy1mb3JtYXQNCm1z Z2lkICJZb3UgYXJlIG5vdCBjdXJyZW50bHkgY29ubmVjdGVkIHRvIGFjY291 bnQgJXMgKCVzKS4iDQptc2dzdHIgIk1vbWVudMOhbG5lIG5pZSBzdGUgcHJp cG9qZW7DvSgtw6EpIGt1IGtvbnR1ICVzICglcykuIg0KDQojOiAuLi9vdHIt cGx1Z2luLmM6MTE3DQptc2dpZCAiTm90IGNvbm5lY3RlZCINCm1zZ3N0ciAi TmVwcmlwb2plbsO9Ig0KDQojOiAuLi9vdHItcGx1Z2luLmM6MTYxDQojLCBj LWZvcm1hdA0KbXNnaWQgIk91dCBvZiBtZW1vcnkgYnVpbGRpbmcgZmlsZW5h bWVzIVxuIg0KbXNnc3RyICJOZWRvc3RhdG9rIHBhbcOkdGUgcHJpIHZ5dHbD oXJhbsOtIG1pZW4gc8O6Ym9yb3YiDQoNCiM6IC4uL290ci1wbHVnaW4uYzox NjcNCiMsIGMtZm9ybWF0DQptc2dpZCAiQ291bGQgbm90IHdyaXRlIHByaXZh dGUga2V5IGZpbGVcbiINCm1zZ3N0ciAiTmVtb2hvbCBzb20gemFww61zYcWl IHPDumJvciBzbyBzw7prcm9tbsO9bSBrxL7DusSNb21cbiINCg0KIzogLi4v b3RyLXBsdWdpbi5jOjIxMA0KIywgYy1mb3JtYXQNCm1zZ2lkICJVbmtub3du IGFjY291bnQgJXMgKCVzKS4iDQptc2dzdHIgIk5lem7DoW1lIGtvbnRvICVz ICglcykuIg0KDQojOiAuLi9vdHItcGx1Z2luLmM6MjE0DQptc2dpZCAiVW5r bm93biBhY2NvdW50Ig0KbXNnc3RyICJOZXpuw6FtZSBrb250byINCg0KIzog Li4vb3RyLXBsdWdpbi5jOjk1Mw0KbXNnaWQgIk9mZi10aGUtUmVjb3JkIE1l c3NhZ2luZyINCm1zZ3N0ciAiVXRhamVuw6kgcG9zaWVsYW5pZSBzcHLDoXYi DQoNCiM6IC4uL290ci1wbHVnaW4uYzo5NTQNCm1zZ2lkICJQcm92aWRlcyBw cml2YXRlIGFuZCBzZWN1cmUgY29udmVyc2F0aW9ucyINCm1zZ3N0ciAiVW1v xb7FiHVqZSBzw7prcm9tbsOpIGEgYmV6cGXEjW7DqSByb3pob3ZvcnkiDQoN CiM6IC4uL290ci1wbHVnaW4uYzo5NTUNCm1zZ2lkICIiDQoiUHJlc2VydmVz IHRoZSBwcml2YWN5IG9mIElNIGNvbW11bmljYXRpb25zIGJ5IHByb3ZpZGlu ZyBlbmNyeXB0aW9uLCAiDQoiYXV0aGVudGljYXRpb24sIGRlbmlhYmlsaXR5 LCBhbmQgcGVyZmVjdCBmb3J3YXJkIHNlY3JlY3kuIg0KbXNnc3RyICIiDQoi WmFjaG92w6F2YSBzw7prcm9taWUgSU0gcm96aG92b3JvdiBwb3XFvml0w61t IMWhaWZyb3ZhbmlhLCBhdXRlbnRpZmlrw6FjaWUsICINCiJwb3ByZXRlxL5u b3N0aSBhIGRva29uYWzDqWhvIGRvcHJlZG7DqWhvIHphYmV6cGXEjWVuaWEu Ig0KDQojOiAuLi91aS5jOjEwOA0KIywgYy1mb3JtYXQNCm1zZ2lkICJBY2Nv dW50ICVzICglcykgY291bGQgbm90IGJlIGZvdW5kIg0KbXNnc3RyICJLb250 byAlcyAoJXMpIG5lbW9obG8gYnnFpSBuw6FqZGVuw6kiDQoNCiM6IC4uL3Vp LmM6MTEyDQptc2dpZCAiQWNjb3VudCBub3QgZm91bmQiDQptc2dzdHIgIktv bnRvIG5lbsOhamRlbsOpIg0K --8323328-1141903542-1185904701=:32017-- From ian@cypherpunks.ca Tue Jul 31 22:54:48 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 31 Jul 2007 17:54:48 -0400 Subject: [OTR-dev] Slovak translation by Milan Plzik In-Reply-To: References: Message-ID: <20070731215448.GE3751@yoink.cs.uwaterloo.ca> On Tue, Jul 31, 2007 at 01:58:21PM -0400, Paul Wouters wrote: > > Attached is the Slovak translation for pidgin-otr Thanks; checked in. > #: ../gtk-dialog.c:1025 > msgid "Enter secret here" > msgstr "" Should there not be a translation for this one? - Ian