Request to join Python team on Salsa
Hello, I would like to join the team primarily to maintain pygopherd in Debian. My salsa login is jgoerzen. I have read policy.rst and accept it. Further background: I previously maintained a number of Python packages in Debian, all of which were removed during Python 2 deprecation. I am the original author of Pygopherd, and it is now compatible with Python 3. I would like to re-introduce it to Debian, as part of the team. Thanks, John
Re: Release Team meeting minutes - 2005-06-18
On Mon, Jun 20, 2005 at 10:03:05AM +0200, Andreas Barth wrote: * John Goerzen ([EMAIL PROTECTED]) [050620 05:47]: Not everyone can be in an IRC discussion. There are pesky things like sleep, work, and Real Life that mean that it's not possible for everyone to participate in a real-time discussion. I think IRC meetings are fine for teams like the release team (where we choose an appropriate time at least for the team members). Of course, if I'm not saying otherwise. I'm just saying that full and accurate meetings, or at least IRC logs, ought to be posted. Saying oh, our decisions were controversial, therefore we won't tell anyone only makes the legendary communication problems within Debian worse. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305461: O: gnupginterface
Package: wnpp Severity: normal I am orphaning this package. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Seeking a good home for OfflineIMAP
[ also posted on comp.lang.python ] Hi, I'm the author of OfflineIMAP[1], a bidirectional IMAP synchronization tool. Its job is to let you read IMAP mail with any mail reader that can understand a Maildir, and to keep your mail readers in sync on all your different computers. Here's the problem. I consider OfflineIMAP basically finished. It does more than I ever expected out of it, and I haven't lost any mail from in its entire lifespan. I've done a poor job lately of tracking down bugs that people have submitted and generally of maintaining the code. Part of that is because I don't have time. Part is, I admit, that the problems are just not interesting to me, since OfflineIMAP works fine for me already. I know a lot of people find OfflineIMAP useful, and I feel that I'm letting people down sometimes. So I am asking here for somebody (or beter, several people) that would like to take over development and maintenance on OfflineIMAP. If you don't want that, maybe you could at least handle bug reports and send me diffs. I'm content still making releases, or else pretty much ending my involvement. I could put my Subversion repository back up again, and you could hack on that with me, or you could just take it over to *forge and go your own way. Whatever you prefer. I'm happy to continue hosting the mailing list and answer the wtf did you do there questions. OfflineIMAP is pure Python, highly modular, and (I think) easy to work with. With one exception: the IMAP communication code. And that is because it has to use imaplib, which doesn't lend itself very well to, erm, clean code :-) If you're interested, I'd encourage you to sign up[2] for the offlineimap list and post there, so we can get started right away. Thanks, John [1] http://quux.org/devel/offlineimap [2] Send subscribe to offlineimap DASH request aT complete dOt org
ANN: Pycaml for Debian
Hello, I have uploaded Pycaml 0.81 to Incoming. If you would like to see the packages immediately, you may see them at: http://people.debian.org/~jgoerzen Pycaml is a system that binds Python to OCaml and lets you call functions and pass objects back and forth from one environment to the next. Python programmers will find it similar to the Jython system for Java. Enjoy. -- John
Python transition
Hello, I hope I am not alone in this. I find the whole Python transition process to be rather confusing. For instance, I recently received an e-mail asking me not to upload various Python packages. A day later, one of them got NMU'd. I am confused; what exactly is the problem and why would a simple upload in any way inconvenience anyone, ESPECIALLY if it fixes problems? And why are maintainers not supposed to upload their packages but others can? I'm tempted to say to hell with it and just upload packages as normal, make them work with Python 2.3 as proper, fix any bugs, and just go on with life. -- John
Re: python 2.2 - python 2.3 transition
On Tue, Aug 12, 2003 at 01:32:33PM -0400, Samuel Bronson wrote: Well, I haven't had any python-related collisions from the pythonX.Y scheme... python (= 2.2), python ( 2.3) I've seen, of course... it would be so much nicer if someone added debian support to distutils, though ;-) (*hint*) Actually, all that have that are now uninstallable. Some important ones have that, such as libwxgtk2.4-python. Shouldn't they depend on python2.2 instead? -- John
#!/usr/bin/python2.3 vs #!/usr/bin/env python2.3
Hello, Many Python programs use constructs like #!/usr/bin/env python2.3 to load themselves. Many others use #!/usr/bin/python2.3. On most Debian systems, these are the same. The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong because he has his own python2.3 on the path prior to the system's, and it doesn't necessarily have requisite libraries for the programs being run. Any opinions? -- John
ANN: Pyme -- Python OO interface to GPGME
Thought some of you may be interested in this -- it's hit ftp-master now,
and is just waiting for approval. Comments welcome :-) It's taken a good
deal of work, but I like it.
- Forwarded message from John Goerzen [EMAIL PROTECTED] -
From: John Goerzen [EMAIL PROTECTED]
Date: Tue, 19 Nov 2002 16:02:07 -0600
To: [EMAIL PROTECTED]
Subject: ANN: Pyme -- Python OO interface to GPGME
Hello,
Today I am announcing the first release of Pyme, the brand-new Python
bindings for GPGME. Pyme:
* Provides a convenient class-based interface to GPGME functions;
* Exists and is supported;
* Supports most GPGME functions automatically by reflection; thus,
no code changes will be necessary to support most new GPGME features
* Supports callbacks written in Python.
* Features easy installation: python setup.py build; python setup.py install
* Provides pre-built .debs for Debian GNU/Linux users.
You may obtain Pyme at http://quux.org/devel/pyme
The following is from the Pyme documentation:
Welcome to PyME, the GPGME Interface for Python. Pyme, when prounced,
rhymes with Pine.
The latest release of this package may be obtained from
http://quux.org/devel/pyme/
FEATURES
* Feature-rich, full implementation of the GPGME library. Supports
all GPGME features except interactive editing (coming soon).
Callback functions may be written in pure Python.
* Ability to sign, encrypt, decrypt, and verify data.
* Ability to list keys, export and import keys, and manage the keyring.
* Fully object-oriented with convenient classes and modules.
GENERAL OVERVIEW
For those of you familiar with GPGME, you will be right at home here.
Pyme is, for the most part, a direct interface to the C GPGME
library. However, it is re-packaged in a more Pythonic way --
object-oriented with classes and modules. Take a look at the classes
defined here -- they correspond directly to certain object types in GPGME
for C. For instance, the following C code:
GpgmeCtx context;
GpgmeRecipients recp;
gpgme_new(context);
gpgme_recipients_new(recp);
...
gpgme_op_encrypt(context, recp, plain, cipher);
Translates into the following Python code:
context = core.Context()
recp = core.Recipients()
...
context.encrypt(recp, plain, cipher)
The Python module automatically does error-checking and raises Python
exceptions when GPGME signals an error. Those exceptions correspond
directly to GPGME errors. All GPGME exceptions are defined in the
gpgme.errors module, and pyme.errors.GPGMEError is the parent of all
exceptions.
IMPORTANT NOTE
--
This documentation only covers a small subset of available GPGME functions and
methods. Please consult the documentation for the C library
(available in doc/gpgme in this distribution) for comprehensive coverage.
This library uses Python's reflection to automatically detect the methods
that are available for each class, and as such, most of those methods
do not appear explicitly anywhere.
QUICK START SAMPLE PROGRAM
--
This program is not for serious encryption, but for example purposes only!
import sys
from pyme import core, constants
import pyme.constants.validity
# Set up our input and output buffers.
plain = core.Data('This is my message.')
cipher = core.Data()
# Initialize our context.
c = core.Context()
c.set_armor(1)
# Set up the recipients.
sys.stdout.write(Enter name of your recipient: )
name = sys.stdin.readline().strip()
r = core.Recipients()
r.add(name, constants.validity.FULL)
# Do the encryption.
c.op_encrypt(r, plain, cipher)
print cipher.read()
Note that although there is no explicit error checking done here, the
Python GPGME library is automatically doing error-checking, and will
raise an exception if there is any problem.
This program is in the Pyme distribution as examples/simple.py. The examples
directory contains more advanced samples as well.
FOR MORE INFORMATION
PYME homepage: http://quux.org/devel/pyme
GPGME documentation: http://www.fifi.org/cgi-bin/info2www?%28gpgme%29
GPGME homepage: http://www.gnupg.org/gpgme.html
Base classes: pyme.core (START HERE!)
Auxiliary classes: pyme.aux
Utilities: pyme.util
Error classes: pyme.errors
Constants: pyme.constants
Version information: pyme.version
Base classes are documented at pyme.core and auxiliary classes at pyme.aux
- End forwarded message -
Re: Question for the transition
Jim Penny [EMAIL PROTECTED] writes: This is not all that simple. python2.1 conflicts with zope2.3.x and python1.5 conflicts with zope2.4.x. Further, it is often the case that there is a fair amount of internal breakage when upgrading from one release of zope to another. It is not unusual to have to delete and reinstall third party components of zope (Products) to get them to work under new releases. I have never experienced this problem with the Debian packages, and submit that if you have, then it's probably a bug with leaving around .pyc files. I cannot fathom what difference deleting and reinstalling .py files could possibly make. -- John Goerzen [EMAIL PROTECTED]GPG: 0x8A1D9A1Fwww.complete.org
Stackless Python?
Has this been packaged? Are there any plans to do so? -- John
Re: Packaging of more zope products
Yes, there is squishdot, which I maintain. More may happen but it's just that new zope packages are appearing faster than people care to package them, I think. Since it's fairly easy to install most Zope packages, anyway. Christian Leutloff [EMAIL PROTECTED] writes: Hi, for ZOPE exists many many so called products that extends the functionality. Some are already available for Debian: zope-mysqlda, zope-pygresqld, zope-siteacces, zope-tinytable. Are there any plans to pack more of the available products? Are there any reasons why it hasn't happened so far (except nobody wants to do the work)? Bye Christian -- Dipl.-Ing. Christian Leutloff, Aachen, Germany [EMAIL PROTECTED] http://www.oche.de/~leutloff/[EMAIL PROTECTED] Debian GNU/Linux - http://www.de.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
