Hi Stefano,
thanks for the advice, I'll definitely take a look into patching and
orphaned packages. As far as mentoring how would I go about doing that?
finding one that is.
On Thu, Jan 21, 2021 at 12:15 PM Stefano Rivera wrote:
> Hi PerRy (2021.01.21_07:39:50_+)
> > I wanted
My name is Perry,
I wanted to request to join the debian python team. In a previous email, I
shared that I have been using debian for a while now and at this point in
time I want to contribute back to the project. One of my skills is writing
scripts in python, and I want to utilize and build upon
Greetings everyone!,
I have been using debian for a while now and I am a point where I want
to help and start contributing to debian itself. I read the web page
about contributing and I took away that I should just jump right in, and
I specifically jumped here because I do know how write pytho
Magnus Therning wrote:
Interestingly enough distutils doesn't keep executable bits on
libraries, and this causes lintian to complain:
W: python-pyggy: script-not-executable
./usr/lib/python2.3/site-packages/pyggy/dfa.py
N:
N: This file starts with the #! sequence that marks interpreted scripts,
On Wednesday 11 September 2002 15:00, Matthias Klose wrote:
> Neil Schemenauer writes:
> > Matthias Klose wrote:
> > > Moshe Zadka writes:
> > > > I was wondering if you mind passing Python 1.5 maintainership to me.
> > >
> > > I do not mind passing the maintainership, but I do mind keeping it in
>
On Tuesday 10 September 2002 15:09, Chris Lawrence wrote:
> On Sep 10, Matthias Klose wrote:
> > Moshe Zadka writes:
> > > I was wondering if you mind passing Python 1.5 maintainership to me.
> >
> > I do not mind passing the maintainership, but I do mind keeping it in
> > unstable. Debian is not a
>
>> Converting a hack to another hack with no strong reason nor fun is not
>> exactly what I dream of every night.
>>
>> So, I am not sure that such a conversion would be worth the time spent.
>> If despite all of this you still want to tackle on this task and have
>> some ELisp questions (I thi
> BTW, if you're looking for a really nice and practical solution, you
> should convince/help Python documentation team to switch to another
> source format. LaTeX is really bad choice for such a documentation.
>
this sounds like a great idea, LaTeX is really not meants as a one to many
format.
On 26-Jun-2002 Florent Rougon wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote:
>
>> The problem is we now have a piece of a fairly common package using
>> script(s) in a language few understand. So if you get hit by a bus
>> someone WILL
>
> Converting a hack to another hack with no strong reason nor fun is not
> exactly what I dream of every night.
>
> So, I am not sure that such a conversion would be worth the time spent.
> If despite all of this you still want to tackle on this task and have
> some ELisp questions (I think it
>
> Not OK, since the locally-installed Python may not/will not have
> access to jack's site-python files. Using /usr/bin/env python is IMHO
> only acceptable if the package is self-contained or munges sys.path to
> include any non-standard modules in the search path.
>
indeed. If you have pyt
>>
>> why is this so messy? You only compile for one python version and you match
>> the upstream in either case. The existing software works perfectly without
>> change in both cases. Seems like everyone wins here.
>>
>
> Ok, not messy, but the most "complicated", since programs that depend
>
> ===
> 3.
> ===
> Quite messy, but...
> Since python-gtk2 require python2.2 or later, we let python2.1-gtk
> install as upstream does (in /usr/lib/python2.2/site-packages/) and
> install python2.2-gtk in /usr/lib/python2.2/site-packages/gtk1.2/. And
> python2.2-gtk2 can install as upstream doe
>
> Q2: python-jabber uses socket.ssl (libssl), should I
> put it in a section != main? python is in main.
>
ssl is fine in main now.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
> making python-jabber2.{1,2} would let it, but is it the correct way?
>
if you want to support multiple python versions, yes. You could also make a
python-jabber package which depended on the newest python version you support.
That way a user can just use python-jabber and let the upgrades
On 07-Apr-2002 Jérôme Marant wrote:
>
> Hi,
>
> It seems that 4suite people ship a tarball
> of prerendered 4suite docs.
> I think I can release it sepearately. Since the conflicts
> happen only when the docs are built, I can both avoid
> to make the package conflict on the previous ve
>>
>> apt-cache showpkg doesn't show any reverse dependencies for 4suite, so
>> an upload might be safe ...
>
> Well, some api changed. It might not be reasonnable ...
>
consider people using it as a depends for software not in Debian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
>
> I have one more question: AJ wants to release Woody in May, so there are
> not a lot
> of weeks left. What can I do with 4suite since it is quite broken in Woody
> ?
> Should I release this pre0.12 or should I stick with 0.11.1 ?
>
damned if you do, damned if you don't. 0.12 uses a
>>
>> 4suite is obviously updating the python search path to add its modules, the
>> modules should be added at the front of the list and not the end where they
>> seem to be added.
>
> This really sucks. I don't have in mind any package that requires the
> removal
> of the old version in orde
>
> PS: I'm not sure about this, but it seems that the old version of
> the package must not be installed on the system in order to build
> the new package. Could someone try to build it and confirm?
>
confirmed. It finds the old module in the path which does not have the same
hierarchy a
On 06-Apr-2002 Jérôme Marant wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
>>> http://people.debian.org/~jerome/python-4suite
>>
>> the source is 600 so we can not download it.
>
> My apologies. It is strange that
On 05-Apr-2002 Jérôme Marant wrote:
>
> Hi,
>
> I've just built a preversion of the 4suite 0.12a2 snapshot.
> Building the package takes a huge amount of time (the whole
> documentation is processed with 4xslt, which is known as one of the
> slowest XSLT processors) and packaging becomes
>
> I put it at:
>
> http://people.debian.org/~jerome/python-4suite
>
> The package is now compatible with python-xml. Please test it. If
> you think that is is reliable enough, I'll upload it and will be
> able to close #128604, at last.
>
> Thanks in advance.
>
> Cheers,
>
>
I am considering packaging my first python lib. Anyone have a pointer to a
good package to use as a template? It contains a setup.py script so I do not
think it will be too difficult.
Comments on any gotchas welcome.
The package is pyro -- http://pyro.sf.net. I am once again looking at Narval
>
> They should be known by dpkg because they're part of the package. It's
> impossible to support more than just the currently installed versions anyway.
> Once a new version of python is added, the package will still need to be
> updated or at least reinstalled to compile the modules for the ne
On 20-Feb-2002 dman wrote:
> On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote:
>| >>
>| >> What do you have against giving the user optimizations?
>| >
>| > Absolutely nothing, but I don't see why this needs to be done outside
>>
>> What do you have against giving the user optimizations?
>
> Absolutely nothing, but I don't see why this needs to be done outside of
> the package management system.
>
I fail to see why these files need to be known by dpkg? Many python modules
are forwards compatible, I also fail to see
>
> Any policy that forces me to compile .py{c,o} object files in my postinst is
> braindead. Then I also have to delete them in purge/postrm, and the
> packaging system knows nothing about them.
>
A program run by a user will never be able to write out the .py[co] files so
the files MUST be ge
On 08-Feb-2002 Federico Di Gregorio wrote:
> hi,
>
> hi have python-psycopg be a fake package that depends on the right
> python-psycopg package (i provide psycopg packages for python 1.5, 2.1
> and 2.2.) lintian give me an error saying that the package should
> contain at least the copyright fil
On 10-Jan-2002 Bastian Kleineidam wrote:
> Hi Python folks,
>
> I have put together a dh_purepython debhelper script to help
> the installation of pure Python packages.
>
> Still missing:
>
> 1) All Python X.Y versions need to be preinstalled. What happens
>when you install an new Python ve
On 15-Dec-2001 Carel Fellinger wrote:
> Hi,
>
> Today I tried the new Python2.2c1 to find that it doesn't build on potato.
> It works out of the box on my woody system, but fails on my potato setup:(
> The latest 2.2 that does build under potato is 2.2.a4
>
> It seems to have to do with changes
On 07-Nov-2001 Danie Roux wrote:
> Policy states that you should Build-Depends on python2.1-dev.
>
> Can this also be Build-Depends-Indep? I have a "Architecture: all"
> package. It's just 3 python files. No need for "Architecture: any"
>
of course it can. We usually say "Build-Depends" when w
On 29-Oct-2001 Tom Cato Amundsen wrote:
> Has anyone started modifying lintian? If I remember correctly,
> packages that generate lintian errors will be rejected...
>
anyone is me, the maint. (-: Although any pythoners among you willing to get
dirty with perl are welcome to send patches.
> At
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
> I have filed an ITP for pyAda which is an Ada wrapper to allow Python to be
> embedded and extended with Ada. Since pyada contains no python code I was
> going to name the package pyada instead of python-pyada, or am I wrong
> about the usage of 'python-' in a package name.
>
pyAda is the well
On 18-Apr-2001 Gregor Hoffleit wrote:
> On Tue, Apr 17, 2001 at 03:33:45PM +0200, Vasko Miroslav wrote:
>> as Python 2.1 is out, there is no need to keep Python2 and Python152
>> in Debian, I think.
>>
>> it looks like 2.1 has GPL-compatible license (it has, in fact, three
>> licenses)
>
> Thank
On 03-Apr-2001 Jérôme Marant wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
>
>> why does this need alternatives? It should go in
>> /usr/ib/python1.5/site-packages and python2.x/site-packages.
>
> Alternatives are used f
On 02-Apr-2001 Jérôme Marant wrote:
>
> Hi,
>
> I made 4Suite available for unstable, it is waiting in Incoming.
> Sorry for those who were waiting it to come out earlier but it
> took more time than I was expecting.
>
> There are 2 packages: python-4suite and python2-4suite, and both
>
On 28-Feb-2001 Jérôme Marant wrote:
>
> Hi,
>
> Would you think great to have 4Suite (http://www.4suite.org) in Debian ?
> As 4DOM was included in Python-xml, we could simply remove it from 4Suite
> add a dependency instead.
>
I looked into packaging it for narval. However, the version
On 07-Feb-2001 Moshe Zadka wrote:
> On Wed, 07 Feb 2001 02:39:11 -0500, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>> The binaries should be called python1.5 and python2.0, and python
>> should be a symlink to whatever is the default one.
>
> No they shouldn't. Joey Hess wrote to debian-python
>
> none; both packages should depend on python|python2
> I am just waiting till python2 packages stabilise to upload
> versions with correct dependencies.
> But, of course, the correct way would be to have
> virtual package python, provided by python1-base and python2-base
>
it is my understand
42 matches
Mail list logo
