On Wed, 04 Apr 2012 13:28:49 -0700, Jeremy Huddleston wrote:
On Apr 4, 2012, at 8:30 AM, SciFi <sci-fi@hush.ai> wrote: […]
2. We still have the stuck-'h' key. In fact the bug-report #443 has a few more people who are experiencing this same problem. As for me, a recent Pan build from git.gnome.org can easily change its "hotkey" table, to let us steer-clear of using 'h' for any of its functions.
There's really nothing "special" about h other than that it's used higher up in the stack for cmd-h to hide windows. I'm really perplexed by this issue, and unless you can help me reproduce it, there's really no hope of me fixing it.
For the 'h' key problem, some time ago I've asked in the bug-report #443 for precise directions on what to do for testing this problem, please. Assume I know some things, but not "everything" <g>. So I am still awaiting directions. ;)
5. I still cannot use the pkg-mgrs: the latest Pan code seems to need some projects/versions that are not (yet) available except for having to build 'em by hand the old-fashioned way. Sorry. ;)
What versions are missing in MacPorts. I can probably update them for you...
I think the main thing was with the new SSL support in Pan. We wanted to not need stunnel anymore with its more-complex setups etc. We had been testing OpenSSL, but the Pan community was worried about licensing issues, IIUC. (never mind the problems that I myself had with openssl-cvs <heh>) So, they switched to gnutls-2.12.10 or later. For some strange reason I now don't remember, I had to go with gnutls-3.0.9 or later perhaps for extra functions or similar. Of course I had built gnutls-3.0.9 myself (since I can't find it in your "available ports" search page) which now needs nettle and p11-kit as dependencies (instead of needing gcrypt as earlier gnutls required, IIUC). (I still can't find p11-kit in y'all's "available ports" search.) Perhaps if Macports & Fink et al. had a gnutls3 package with deps it could maybe live in the repros together with the current gnutls (but not with each-other on the user's machine of course). They also added crypto support in Pan with the help from the gmime-2.6.x line. Now y'all only have gmime thru 2.4.x which is ok for Pan to use but we won't have crypto support, see. Added problem is that I've been unable to build _working_ libs with the crypto support enabled via ./configure and have asked help from the main gmime author on this: <https://mail.gnome.org/archives/gmime-devel-list/2012-January/msg00002.html> <http://permalink.gmane.org/gmane.mail.mime.gmime.devel/155> <news://news.gmane.org/pan.2012.01.26.08.38.57@scifi.homeip.net> He finally responded: <https://mail.gnome.org/archives/gmime-devel-list/2012-February/msg00003.html> <http://permalink.gmane.org/gmane.mail.mime.gmime.devel/159> <news://news.gmane.org/4F3FCC48.2070206@gnome.org> He admits not having trying to build an OSX flavor. Anyway, I still need to work-up a report for the GPGME team as he requested me to do. And I need to follow-up with the Pan team asking why are they relying on gmime's obvious experimental code for crypto support, and instead why can't we use an already-established project to do crypto in Pan. Now the Pan team wants to do a release this weekend (yes during Easter for some reason). But I'm afraid us OSX users will have some debilitating functionality in this release. :( … BTW since no-one has wanted to further discuss my main pet peeve with the way things are going with OSX, I am only going to be interested in keeping 10.6.x alive here, not anything newer/higher. I know I must spend $$$ to do any kind of upgrade, so I have decided to eventually build my own "dream machine" design, use 100% open-source systems and apps on it, and spend my remaining time on this planet keeping it interesting to tinker with. Instead of having to give more to a company who is trying to close-down my favorite hobby (not to mention TPTB clamping-down our other Rights To Be Human™, but that's for another list). --