Request to join the DPMT

2019-09-21 Thread Fabian Greffrath
[Re-sending again, this time using my full name, my @debian e-mail
address and a gpg signature.]

Hi -python,

I'd like to join the DPMT!

I am going to package omgifol[1] (python3-omg), a Python library for
reading, manipulating and writing WAD files, i.e. Doom game data files.
My plan is to use this library (instead of deutex) to create individual
desktop icons for each Doom game in game-data-packager[2]. Currently, I
own the corresponding ITP[3] originally opened by jmtd back in 2005.


My salsa login is "fabian".

I have read and accepted the policy in 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst


Thanks!

 - Fabian


[1] https://github.com/devinacker/omgifol
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803930
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354732



signature.asc
Description: This is a digitally signed message part


request to join DPMT

2019-09-18 Thread fabian

Hi -python,

I'd like to join the DPMT!

I am going to package omgifol[1] (python3-omg), a Python library for 
reading, manipulating and writing WAD files, i.e. Doom game data files. 
My plan is to use this library (instead of deutex) to create individual 
desktop icons for each Doom game in game-data-packager[2]. Currently, I 
own the corresponding ITP[3] originally opened by jmtd back in 2005.


My salsa login is "fabian".

I have read and accept the policy in 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team


Thanks!

 - Fabian


[1] https://github.com/devinacker/omgifol
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803930
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354732



Request to join the DPMT

2018-04-25 Thread Fabian Wolff
Hi,

I currently maintain the python-picklable-itertools package. I would
like to maintain this package within the DPMT, which is why I am
hereby requesting to join the Debian Python Modules Team.

My Salsa login is wolff-guest, and my Alioth login (in case it's still
relevant) is fw-guest.

I have read the DPMT Policy [0], and I accept it.

Thank you!

Best regards,
Fabian

[0] https://python-modules.alioth.debian.org/policy.html



Re: Python mkhowto and friends

2004-02-27 Thread Fabian Fagerholm
On Mon, 2003-06-02 at 23:37, Matthias Klose wrote:
 As I am away the next two weeks, is somebody interested to make a
 patch to build such a package from the python source?

(See #207337)

So the tools are now available (since 2.3.3-1) in
/usr/lib/python2.3/doc/tools -- is it safe to assume they will stay
there? Would it be sensible to include something about this in python
policy?

-- 
Fabian Fagerholm [EMAIL PROTECTED]




Re: Question about python policy

2004-02-12 Thread Fabian Fagerholm
On Wed, 2004-02-11 at 11:28, Florent Rougon wrote:
 There used to be a tool called python-central [...]

It probably doesn't solve the case where you need a certain version of
python to run build-time test cases and such. I guess it might have been
a good idea, but since it didn't catch on, perhaps it was too
complicated.

Anyway, I pretty much know what to do now, and if policy will ever
mandate a better way then I'll convert my package to using it.

-- 
Fabian Fagerholm [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: Question about python policy

2004-02-11 Thread Fabian Fagerholm
On Wed, 2004-02-11 at 02:14, Graham Wilson wrote:
  I think I'll do this for python-albatross as well. It'll be a really
  tiny package but at least it'll fix the issue of not being able to
  install both python 2.2 and 2.3 versions.
 
 Does it make sense to have both versions installed? Why might someone
 want to do that?

The only situation that comes to mind is supporting applications written
in an older dialect of python (ie. 2.2 vs. 2.3 and similar transitions
in the future). While 2.2 code should run flawlessly on 2.3, there are
some semantic differences (for example the introduction in 2.3 of the
boolean type) that could cause unexpected behaviour.

Therefore, having the option of keeping your old software running with
python 2.2 while porting it to 2.3 (or writing a 2.3-based replacement)
can be important to someone. And then there's the case of because we
can. :)

-- 
Fabian Fagerholm [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Question about python policy

2004-02-10 Thread Fabian Fagerholm
Hello all,

I maintain python-albatross, a python web toolkit
(http://www.object-craft.com.au/projects/albatross). Following (the
proposed) python policy, I've created a dummy package python-albatross,
and two versioned packages, python2.2-albatross and python2.3-albatross.
The dummy package depends on the 2.2 version.

Now, I have some questions regarding this scheme.

Firstly, it seems a little silly to duplicate all the code in both
packages. I guess there's really no other way of doing it, since there
are build-time test cases that should be run with each version of
python, and the install-time bytecompiling and module optimizing that
much be run with each version of python as well. Are there any ideas for
how to reduce the size without making it all an unmaintainable mess?
(python-albatross is quite small, but this may be useful for bigger
packages.)

Secondly, the above scheme makes it impossible to install both packages
at the same time. This is because both packages provide the same
initscript, defaults file and logrotate file. One solution, which may
be against policy, is to have the versioned packages conflict with each
other. Another solution would be to split all the common parts into a
separate package, which is then depended upon by both versioned
packages. But I don't know if this is permitted by the policy, or if it
will introduce any side-effects that are undesirable. Perhaps it can be
done, but should use versioned dependencies somehow?

Please tell me what you think.

Cheers,
-- 
Fabian Fagerholm [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: Question about python policy

2004-02-10 Thread Fabian Fagerholm
On Tue, 2004-02-10 at 20:44, Graham Wilson wrote:
 This is the solution I use with the PyX package is to create a
 python-pyx-common package that both of the versioned packages depend on.
 This works fine for PyX, since the -common package just cotains
 read-only data files. I am not sure how well it would work for
 Albatross.

I assume python-pyx-common doesn't include any python source code then.
I think I'll do this for python-albatross as well. It'll be a really
tiny package but at least it'll fix the issue of not being able to
install both python 2.2 and 2.3 versions.

Unless of course someone can either propose an even better way, or say
why this solution will lead to horrific results. :)

-- 
Fabian Fagerholm [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re-request for sponsor: python-albatross

2003-08-12 Thread Fabian Fagerholm
Hi,

This is my third or fourth attempt to find a sponsor for the
python-albatross package. So far, I've been contacted by one developer
who was interested in sponsoring the package; he never replied to my
reply, however, so I assume he has other things to do at the moment.
Meanwhile, I'm continuing my search for a sponsor.

Before I resort to bribery, I'm going to try to speak convincingly about
Albatross. At the same time, because I suspect there are people on the
debian-python list that could be interested but don't read
debian-mentors, I'm Cc'ing this mail to debian-python.

Albatross is a very nice piece of software for developing small web
applications. It's written in Python. Upstream activity seems to have
accelerated during the summer and the atmosphere on the Albatross
mailing list is very friendly and helpful, with the developers and users
juggling ideas, advice and code as ideas, advice and code should be
juggled. Recently, for example, a standalone, small HTTP server was
introduced by a user, and Albatross now sports support for standalone
application deployment in addition to regular CGI, FastCGI and
mod_python application deployment with Apache.

If you write anything from simple dynamic web pages to full-blown web
applications, then you should really check out Albatross. If you'd like
to try an approach that is different from PHP but still sensible when
the application grows beyond what regular CGI can do, then Albatross may
well be worth a look. And if, at the same time, you happen to be a
Debian Developer, then please help me introduce this package into
Debian.

Packages can be found at
http://people.paniq.net/~fabbe/debian/albatross/ and an ITP concerning
Albatross is at http://bugs.debian.org/193574
The Albatross site is at
http://www.object-craft.com.au/projects/albatross/

Thanks for your time,
-- 
Fabian Fagerholm [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part