Hi,
I added in the Wiki [0], the link to the python3-defaults
docs and policy [1].
Please review it.
[0] https://wiki.debian.org/Teams/PythonTeam#preview
[1] https://www.debian.org/doc/packaging-manuals/python-policy/
Cheers
Emmanuel
Hi!
On Fri, Oct 1, 2021 at 7:43 AM wrote:
> Hello,
>
> this is about the wiki page of that team.
> https://wiki.debian.org/Teams/PythonTeam
>
> I accidentally found the "Debian Python Policy documentation".
> https://www.debian.org/doc/packaging-manuals/python-pol
Hello,
this is about the wiki page of that team.
https://wiki.debian.org/Teams/PythonTeam
I accidentally found the "Debian Python Policy documentation".
https://www.debian.org/doc/packaging-manuals/python-policy/
Looks nice and very important for new team members.
Maybe it would hel
On Wed, Nov 4, 2009 at 2:29 AM, Ben Finney wrote:
> (I am reading this to mean “the reference version of the Debian Python
> policy is in the python-defaults package”.)
>
> Okay. Clearly one way for this to improve would be for some of those bug
> reports to be responded to by
Josselin Mouette writes:
> Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit :
> > Is there a silent Debian Python policy drafter out there who would
> > like to step forward? Or is this work now moribund?
>
> Bug reports concerning the Python policy have been si
On Tue, 03 Nov 2009 19:02:21 +0100 Josselin Mouette wrote:
>Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit :
>> Is there a silent Debian Python policy drafter out there who would like
>> to step forward? Or is this work now moribund?
>
>Bug reports concerning t
Josselin Mouette writes:
> Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit :
> > Is there a silent Debian Python policy drafter out there who would
> > like to step forward? Or is this work now moribund?
>
> Bug reports concerning the Python policy have been si
Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit :
> Is there a silent Debian Python policy drafter out there who would like
> to step forward? Or is this work now moribund?
Bug reports concerning the Python policy have been silently ignored. I’m
afraid this will last as long
On Mon, 2 Nov 2009 16:50:00 +0300 anatoly techtonik wrote:
>On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman wrote:
>>
>> I'm not aware of any ongoing work. I would be willing to help work on such
>> a thing, but we currently lack a good mechanism for developing/approving
>> such a policy.
>
>Wit
On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman wrote:
>
> I'm not aware of any ongoing work. I would be willing to help work on such
> a thing, but we currently lack a good mechanism for developing/approving
> such a policy.
With clear policy and precise goal you won't need approving mechanism
[ &] we could wait for the new policy to be drafted, I'm not sure when
>> this will happen, though.
>
>I don't know if anyone has even taken the reins for this recently.
>
>The last time I knew someone was actually developing a Debian Python
>policy was when Manoj Sriv
pen, though.
I don't know if anyone has even taken the reins for this recently.
The last time I knew someone was actually developing a Debian Python
policy was when Manoj Srivastava was drafting a document to help record
some of the ad hoc practices he observed, and that work appears to hav
Le mardi 25 octobre 2005 à 12:24 +0100, Donovan Baarda a écrit :
> > If you want to automate the process on the packaging side, using
> > dh_python will do all the work for you; you will only need a rebuild
> > when the major python version changes. Support for rebuilding these
> > modules automati
On Tue, 2005-10-25 at 08:40, Josselin Mouette wrote:
> Le lundi 24 octobre 2005 à 11:30 -0400, James A. Treacy a écrit :
> > Thanks for the replies to my questions.
> >
> > I hope that a way to ensure automatic recompiling of python modules is
> > implemented sometime in the future.
>
> If you wa
Le lundi 24 octobre 2005 à 11:30 -0400, James A. Treacy a écrit :
> Thanks for the replies to my questions.
>
> I hope that a way to ensure automatic recompiling of python modules is
> implemented sometime in the future.
If you want to automate the process on the packaging side, using
dh_python w
Thanks for the replies to my questions.
I hope that a way to ensure automatic recompiling of python modules is
implemented sometime in the future.
--
James Treacy
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED
On Sat, 2005-10-22 at 22:27, James A. Treacy wrote:
> I have some questions relating to python packages and the python
> policy.
>
> I maintain a pure python program (gramps) that relies heavily on other
> python packages: python-gnome2, python-glade2, python-reportlab and
> python-gnome2-extras.
James A. Treacy wrote:
Let's use gramps(*) as an example and that the default python switches
to 2.4. A user upgrades python (leaving 2.3 on the system), gramps and
python-glade2 to python 2.4 versions but does not ugrade python-gnome2
(this works since python 2.3 is still installed). All the dep
I have some questions relating to python packages and the python
policy.
I maintain a pure python program (gramps) that relies heavily on other
python packages: python-gnome2, python-glade2, python-reportlab and
python-gnome2-extras.
Section 3.1 of the python policy states that programs which can
On Sun, Feb 10, 2002 at 10:26:26AM +0100, Matthias Klose wrote:
> Donovan Baarda writes:
> > G'day,
> >
> > just thought I'd have another look at the current policy and I couldn't find
> > it. Where is it again?
>
> /usr/share/doc/python, anybody actually reading the docs?
Ahh, it's included in
Donovan Baarda writes:
> G'day,
>
> just thought I'd have another look at the current policy and I couldn't find
> it. Where is it again?
/usr/share/doc/python, anybody actually reading the docs?
> Can we get a link to it put on the Debian devel page?
>
> http://www.debian.org/devel/
IMO that
G'day,
just thought I'd have another look at the current policy and I couldn't find
it. Where is it again?
Can we get a link to it put on the Debian devel page?
http://www.debian.org/devel/
--
--
ABO: finger [EMAIL PROTECTED]
On Tue, Oct 23, 2001 at 09:14:24AM +0200, Matthias Klose wrote:
> Neil Schemenauer writes:
> > Matthias Klose wrote:
> > > - Recommend /usr/bin/env python over /usr/bin/python
> >
> > Again I must express my opposition to this idea. Using /usr/bin/env
> > totally breaks dependencies. There's no
On Tue, Oct 23, 2001 at 01:33:29AM +0200, Matthias Klose wrote:
> 3.1. Version Independant Programs
> -
> Programs that can run with any version of Python must start with
> `#!/usr/bin/env python'. They must also specify a dependency on
> `python-base
Neil Schemenauer writes:
> Matthias Klose wrote:
> > - Recommend /usr/bin/env python over /usr/bin/python
>
> Again I must express my opposition to this idea. Using /usr/bin/env
> totally breaks dependencies. There's no way that I'm going to let
> Debian policy dictate what I can have in my path
Matthias Klose wrote:
> - Recommend /usr/bin/env python over /usr/bin/python
Again I must express my opposition to this idea. Using /usr/bin/env
totally breaks dependencies. There's no way that I'm going to let
Debian policy dictate what I can have in my path.
Neil
ttp://ftp-master.debian.org/~doko/python/).
Debian Python Policy
Neil Schemenauer <[EMAIL PROTECTED]>
Matthias Klose <[EMAIL PROTECTE
Ricardo Javier Cardenes <[EMAIL PROTECTED]> writes:
> I have fixed that, but not uploaded the package while the policy is
> on debate. I suppose this is the case of other maintainers too...
Yep.
Joel
--
Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
Quoting Matthias Klose <[EMAIL PROTECTED]>:
> Carey Evans writes:
> > Matthias Klose <[EMAIL PROTECTED]> writes:
[...]
> Thanks. Updated in 0.3.2:
>
> http://ftp-master.debian.org/~doko/python/
Nice work updating Neil's policy. I'd be interested to hear Niels comments now
that he is back.
Quoting Matthias Klose <[EMAIL PROTECTED]>:
> Donovan Baarda writes:
> > Good point... I'd forgotten about that. This means we might as well go
> > strait to python2.1 as the default, but make sure that the
> python2.1-xxx
> > packages have versioned conflicts with all the packages that depend on
On Sun, Oct 21, 2001 at 10:58:01PM +1300, Carey Evans wrote:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
>
> (Actually 60, but gimp-python also depends on python-base (<< 1.6.0)).
>
> Packages that depend on python:
>grep-dctrl -FDepends -e 'python([ ,]|$)' Packages
I maintain one of those
Matthias Klose <[EMAIL PROTECTED]> writes:
> Carey Evans writes:
>
> > Another possibility is for python-base to go away, and for a new
> > package that conflicts with it, and has a different name, to take its
> > place.
>
> basically that is Neil's proposal of a python-api package.
I thought p
Donovan Baarda writes:
> Good point... I'd forgotten about that. This means we might as well go
> strait to python2.1 as the default, but make sure that the python2.1-xxx
> packages have versioned conflicts with all the packages that depend on just
> python or python-base and install into /usr/lib/
Carey Evans writes:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
>
> > Good point... I'd forgotten about that. This means we might as well go
> > strait to python2.1 as the default, but make sure that the python2.1-xxx
> > packages have versioned conflicts with all the packages that depend on just
Donovan Baarda writes:
> On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote:
> > Matthias Klose <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > exactly. But you see that these packages will break when you try to
> > > upgrade. We can't make 2.1 the default right now, because we will
Carey Evans writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > 2.4. Dependencies
> > -
> >
> > Packaged modules must depend on `python-base (> .)' and
> > `python-base (<< .)'.
>
> (>= .), right?
>
> Shouldn't this explain just what . is? I assume i
Donovan Baarda <[EMAIL PROTECTED]> writes:
> Good point... I'd forgotten about that. This means we might as well go
> strait to python2.1 as the default, but make sure that the python2.1-xxx
> packages have versioned conflicts with all the packages that depend on just
> python or python-base and i
On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > exactly. But you see that these packages will break when you try to
> > upgrade. We can't make 2.1 the default right now, because we will
> > _silently_ break packages. Before
Matthias Klose <[EMAIL PROTECTED]> writes:
[...]
> exactly. But you see that these packages will break when you try to
> upgrade. We can't make 2.1 the default right now, because we will
> _silently_ break packages. Before python can point to python2.1, we
> will have to fix all packages which de
Jérôme Marant writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I have some questions about the upgrade procedure:
>
>
> >A. Upgrade Procedure
> >
> >
> > This section describe the procedure for the upgrade from the current
> > `python- (1.5)' packag
Matthias Klose <[EMAIL PROTECTED]> writes:
Hi,
I have some questions about the upgrade procedure:
>A. Upgrade Procedure
>
>
> This section describe the procedure for the upgrade from the current
> `python- (1.5)' packages to the `python1.5-' packages, the
> rem
Matthias Klose <[EMAIL PROTECTED]> writes:
[...]
> 2.4. Dependencies
> -
>
> Packaged modules must depend on `python-base (> .)' and
> `python-base (<< .)'.
(>= .), right?
Shouldn't this explain just what . is? I assume it's actually
., i.e. >=1.5 and <<1.6, >=2.1 an
s.
I couldn't find these source diffs on people.debian.org.
Probably we should allow NMUs which only fix the dependencies?
> I'm about ready to give up trying to improve the Debian/Python
> situation. I assumed the Python maintainers were busy and that's why
> they didn
Matthias Klose wrote:
> At any given time, the package `python-base' should represent the
> current stable upstream version of Python. XXX: Should we have an
> exception for the case, when a new upstream version is released during
> a Debian freeze?
It should probably be rewor
[Please CC me on replies]
I made a new version of the Debian Python Policy, based on Neil's
Python Policy (0.1), the new Python packages in unstable and Donovan's
comments on the upgrade procedure.
It's appended and available from http://ftp-master.debian.org/~doko/
(including
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> I'm on vacation until Oct. 17 but I should have experimental packages
> ready soon after that, they are almost done already. I don't know
> what's happening with Woody. Can anyone explain it to me? Gregor seems
> to be busy with other things righ
Anthony Towns wrote:
> Which scheme was that?
Quickly:
python-2.1_2.1.1
python_2.1.1 (depends on python-2.1) (does "ln /usr/bin/python{2.1,}")
python-2.1-_ (depends on python-2.1)
python-_ (depends on python and python-2.1-)
_ (depends on python and python-,
#!/u
On Wed, Oct 10, 2001 at 10:28:58AM -0700, Neil Schemenauer wrote:
> Anthony Towns wrote:
> > Hrm. That doesn't seem to make sense. For example, Python 2.1 supports
> > the Python 2.0 API completely, and Python 2.2 supports the Python 2.1
> > API completely too, doesn't it?
> API in this context mea
> The point is probably moot anyhow since I've almost finished creating
> packages using the scheme proposed by Donavon and others. I need to
> update the policy and doing some more testing yet though.
That's good news. I'm itching to try out some of the new features. Would I
be able to assist in
Anthony Towns wrote:
> Hrm. That doesn't seem to make sense. For example, Python 2.1 supports
> the Python 2.0 API completely, and Python 2.2 supports the Python 2.1
> API completely too, doesn't it?
API in this context means binary API. Only Python 2.1.X supports the
2.1 API.
The point is proba
On Sun, Sep 30, 2001 at 01:52:00PM -0700, Neil Schemenauer wrote:
> Donovan Baarda wrote:
> > Hmmm, but if only "python" can provide python-api-*, then any packages that
> > depend on python-api-X.Y will be broken when a new version of python
> > providing python-api-X.Z comes out, and no python-X.
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > In my above diagrams the (>=2.1,<2.2) dependancy could be replaced
> with a
> > python-api-2.1 provided by python (as suggested by Neil), but I think
> this
> > actually introduces confusion rather than convenience. The pr
Donovan Baarda <[EMAIL PROTECTED]> writes:
[...]
> IMHO, the best solution given what you have described above is to make each
> new release of python as a "python-X.Y" package that installs
> "/usr/bin/pythonX.Y", and have another small "python" package which depends
> on the latest "python-X.Y"
Donovan Baarda wrote:
> In my above diagrams the (>=2.1,<2.2) dependancy could be replaced with a
> python-api-2.1 provided by python (as suggested by Neil), but I think this
> actually introduces confusion rather than convenience. The problem is that it
> doesn't really represent a particular v
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Jim Penny wrote:
[...]
> The python is a small package to create a link from /usr/bin/python2.2
> to /usr/bin/python. python-eggs is a dummy package for dependencies
> (similar to what is done for GCC). When we upgrade Python to 2.2 we
> have:
>
>
Jim Penny wrote:
> Why? Could you better explain your reasoning here?
> On the face of it, it certainly seems that python-1.5 ought to be
> able to provide python-api-1.5.
It breaks dependencies. We've been through this before but I'll explain
it again. Here's a dependency graph:
On Tue, Oct 02, 2001 at 06:53:39AM -0700, Neil Schemenauer wrote:
> Carey Evans wrote:
> > In my original example, spam embeds libpython2.1.so. It would make
> > sense for this to mean it depends on python-api-2.1, though this isn't
> > what the current shlibs file says.
>
> Only "python" can pro
Carey Evans wrote:
> In my original example, spam embeds libpython2.1.so. It would make
> sense for this to mean it depends on python-api-2.1, though this isn't
> what the current shlibs file says.
Only "python" can provide "python-api-*".
Neil
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> spam should depend on python not python-2.1.
In my original example, spam embeds libpython2.1.so. It would make
sense for this to mean it depends on python-api-2.1, though this isn't
what the current shlibs file says.
--
Carey Evans ht
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > Packages like extension modules _are_ tied to a particular version and
> hence
> > should be in a python-X.Y-foo package that installs into
> /usr/lib/pythonX.Y.
> > There would also be an empty package python-foo that si
Donovan Baarda wrote:
> Packages like extension modules _are_ tied to a particular version and hence
> should be in a python-X.Y-foo package that installs into /usr/lib/pythonX.Y.
> There would also be an empty package python-foo that simply depends on the
> latest python-X.Y-foo and python pack
Carey Evans wrote:
>/> python-2.1 -\
>spam -- > python
>\---> python-eggs ---> python-api-2.1 ---/
spam should depend on python not python-2.1.
Neil
Neil Schemenauer <[EMAIL PROTECTED]> writes:
[...]
> Excellent point. I've updated the policy document to prevent this. The
> python package should provide python-api-X.Y. Module packages should
> depend on python-api-X.Y. If someone packages an older version of
> Python they should call it p
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
[...]
I've done some digging in the archives and found things that look surprisingly
like "my proposal" proposed by others. I don't think the finer points of how it
would work were pinned down though, so I'm going to persist untill someone
tells me
[Please don't CC me, I'm on the list. I wish MUAs would respect the
mail-followup-to header.]
Donovan Baarda wrote:
> From archive updating point of view, my scheme has a large
> python-X.Y-foo added and a small python-foo updated when python
> upgrades. Your scheme has a large python-foo updated
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> > > Donovan Baarda wrote:
> > > If you change the major or minor version of Python installed then
> > > packages that depend on it must be upgraded. There
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > Hmmm, but if only "python" can provide python-api-*, then any packages
> that
> > depend on python-api-X.Y will be broken when a new version of python
> > providing python-api-X.Z comes out, and no python-X.Y package can be
Donovan Baarda wrote:
> Hmmm, but if only "python" can provide python-api-*, then any packages that
> depend on python-api-X.Y will be broken when a new version of python
> providing python-api-X.Z comes out, and no python-X.Y package can be
> compatible with it.
That's right. Packaged modules mu
Donovan Baarda wrote:
> On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> > Donovan Baarda wrote:
> > If you change the major or minor version of Python installed then
> > packages that depend on it must be upgraded. There is no way around
> > that.
>
> Yes, but the old packages
On Sat, Sep 29, 2001 at 11:10:43PM -0700, Neil Schemenauer wrote:
> Carey Evans wrote:
> > By way of example, suppose I have a package "spam" that embeds Python
> > 2.1, and therefore depends on python-2.1. spam also uses the "eggs"
> > module, and therefore depends on python-eggs, which depends o
On Sat, Sep 29, 2001 at 11:31:44PM -0700, Neil Schemenauer wrote:
> Packages (mostly) conforming to this policy are at:
[...]
> - Packaged modules should depend on python-api-X.Y
>
> - Remove section on legacy versions of Python (they are
> independent). I should probably add a sect
On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> Donovan Baarda wrote:
> > First off, you need to clarify what you are attempting to achieve. There
> > are
> > three possibile aims as I see it;
> >
> > 1) single "official" version of Python in archive/distro.
> > 2) multiple a
Packages (mostly) conforming to this policy are at:
deb http://people.debian.org/~nas woody/
I've updated a lot of packages. If there is something missing that you
use please let me know. After updating about 30 packages I'm getting
good at it. :-)
Changes from last version (off the top o
Donovan Baarda wrote:
> First off, you need to clarify what you are attempting to achieve. There are
> three possibile aims as I see it;
>
> 1) single "official" version of Python in archive/distro.
> 2) multiple alternative versions of Python in archive/distro, only one
> installed at a time.
>
Carey Evans wrote:
> By way of example, suppose I have a package "spam" that embeds Python
> 2.1, and therefore depends on python-2.1. spam also uses the "eggs"
> module, and therefore depends on python-eggs, which depends on
> python-2.1 itself.
>
> Now Python 2.2 is released, and eggs is recomp
G'day debian-python,
Just read the DWN, saw mention of the Python policy, read it, and subscribed to
this list to throw in some comments. I note that the policy was posted some
time ago, so these comments might be too late.
First off, you need to clarify what you are attempting to achieve. Ther
On 18-Sep-2001 Neil Schemenauer wrote:
> Please comment.
>
> Neil
it is /usr/share/common-licenses, not licences. Annoying thing there being two
spellings of some common words.
>
> We could perhaps differenciate python modules and bindings.
>
> For example, libxml bindings for Python would be libxml-python.
> Also, python-gtk would become libgtk-python, python-gnome would become
> libgnome-python
> and so on.
>
> However, xml tools for python would stay pytho
On Wed, 2001-09-26 at 11:37, Jérôme Marant wrote:
> David Coe <[EMAIL PROTECTED]> writes:
>
> > Neil Schemenauer <[EMAIL PROTECTED]> writes:
> >
> > > 2.3. Module Package Names
> > > -
> > >
> > > Python module packages should be named for the primary module
> > >
David Coe <[EMAIL PROTECTED]> writes:
> Neil Schemenauer <[EMAIL PROTECTED]> writes:
>
> > 2.3. Module Package Names
> > -
> >
> > Python module packages should be named for the primary module
> > provided. The naming convention for module `foo' is `python-foo'
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> 2.3. Module Package Names
> -
>
> Python module packages should be named for the primary module
> provided. The naming convention for module `foo' is `python-foo'.
> Packages which include multiple modules may
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> Please comment.
This all looks good. I do have a question concerning dependencies on
Python modules.
By way of example, suppose I have a package "spam" that embeds Python
2.1, and therefore depends on python-2.1. spam also uses the "eggs"
module,
Jim Penny wrote:
> I just want to ask a couple of questions to make sure that I understand
> this in detail. Suppose python2.1 is installed as python and you
> also have python1.5 installed. You have
> script poo which is invoked via #!/usr/bin/python and
> script bah which is invoked via #!/us
On Mon, Sep 17, 2001 at 07:33:26PM -0700, Neil Schemenauer wrote:
>
I just want to ask a couple of questions to make sure that I understand
this in detail. Suppose python2.1 is installed as python and you
also have python1.5 installed. You have
script poo which is invoked via #!/usr/bin/python
Ricardo Javier Cardenes wrote:
> I think this:
>
> /usr/local/lib/python./site-packages
> /usr/local/lib/site-python
> /usr/lib/python./site-packages
>
> should be the order.
I see not problem with that. It shouldn't make any difference except in
the case you describe.
> And what happene
Mikael Hedin wrote:
> Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's
> cosmetics, not really important.
It has been pythonX.Y for many years. We should not change it.
Neil
On Mon, Sep 17, 2001 at 07:33:26PM -0700, Neil Schemenauer wrote:
> 1.2. Module Path
>
>
> Python searches a number of directories for modules. The module
> search path for Debian has been ordered to include these locations at
> the beginning of the path in the fol
Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's
cosmetics, not really important.
--
Mikael Hedin, MSc +46 (0)980 79176
Swedish Institute of Space Physics +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint =
Please comment.
Neil
Debian Python Policy
Neil Schemenauer <[EMAIL PROTECTED]>
versi
89 matches
Mail list logo
