ault for all unixish systems, but I guess
upstream would still want PYENCHANT_LIBRARY_PATH to be preferred in
some way.
(The above snippet would be used somewhere near line 119 "# Not found
yet, search various standard system locations." in enchant/_enchant.py
and would try
e libraries might be loaded
depending on the ldconfig output ordering...
I've opened an upstream bug (see the Launchpad meta-bug) and AFAIK the
python2.x patches will be uploaded to Debian with next uploads.
It would be best if we would patch python programs and modules to stop
using find_
es to address various comments
received via email or IRC. Original announcement:
http://lists.debian.org/debian-python/2009/12/msg9.html
I'm attaching the latest version of all patches and the updated
generated text.
Thanks,
--
Loïc Minier
Debian Pyt
On Fri, Dec 11, 2009, Dmitrijs Ledkovs wrote:
> 2009/12/9 Loïc Minier :
> > On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote:
> >> Where is this git repository hosted? Or where can I get the current
> >> version of the policy as seen on the debian.org website?
> >
is provided.
> + that /usr/bin/python is provided as a symlink to the
> + current pythonX.Y executable.
>
> The python package must also depend on the
> appropriate pythonX.Y to
Thanks, I merged something close; patch attached
--
Loïc Minier
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote:
> Looks fine to me, but 3.1 needs to be updated too since it currently says
> that a
> package that needs `foo' must depend on `python-foo', which may not be correct
> anymore with this patch.
Ack
On Fri, Dec 11, 2009, Jakub Wilk wrote:
> That should read: The GNU General Public License.
Thanks
> Huh? "versioned" might not be recorded by dictionaries, but it is a
> common term in Debian-related documentation:
Hmm right that was pushing it over the top
--
ould make sure we're aware of all the
> consequences of the change...
How about the new attached patch, "Require the python- prefix for
public modules"?
--
Loïc Minier
>From 95d0258fb8513078ccb3eb496a7867c16de4f747 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minie
ersions
of a library, and a complex set of dependencies load them together in
memory; we want to avoid this, but it's not easy to enforce via deps.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Tue, Dec 08, 2009, Jakub Wilk wrote:
> >+ versions explicitely.
> You could fix that typo if you are at it.
Thanks; I've spell checked the whole document and came up with the
attached patch, "Spell check fixes".
--
Loïc Minier
>From ee2c89e0b24b2deff74ad35d
when shipping module foo (unless shipping multiple modules,
or when the module name doens't allow so (underscores for instance).
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
changed in python-support,
> or packages using such tool can ignore it?
python-support can generate XB-Python-Version:, but wont use the data.
This recommendation was kept because it might be useful to have a
machine parseable field containing the list of supported versions for a
package, p
uploads of the python-defaults
package (which I found in the morgue) and committed the proposed
changes on top of that. I can provide a copy of the repo to you, but
it's not in any way an official repo for the python-defaults package or
the policy.
--
Loïc Minier
--
To UNSUBSCRIBE,
On Wed, Dec 24, 2008, Josselin Mouette wrote:
> Precisely. TTBOMK no other VCS is as smooth to operate as subversion
> *for Debian packages*. Only svn-buildpackage can handle correctly the
> versioning of the debian/ directory alone.
bzr bd works fine in this mode; did you try it out?
qualify as accesible. My
> vote, fwiw, is to stay with svn until we have a documented, accessible
> workflow with tool support.
Fair point.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Tue, Dec 23, 2008, Loïc Minier wrote:
> Executive suggestion: we wont be able to use the same VCS for all
> packages; use whatever the top contributors prefer, not what all
> contributors to all packages prefer.
I thought this was clear from the above rationale, but the stats I
ah ]
[ Chris AtLee ]
[ Kumar Appaiah ]
[ Kumar Appaiah ]
[ Ondrej Certik ]
[ Kumar Appaiah ]
[ Sandro Tosi ]
[ Kumar Appaiah ]
[ Kumar Appaiah ]
[ Ondrej Certik ]
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject
utilus-python to
pkg-gnome/packages/experimental, revert the changes in /unstable and
upload the 0.5 tree in experimental for now? Thanks!
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ackages with an assigned maintainer: are
usually better maintained than team maintained ones; this might be
because the team is underpowered, but then having individual
Maintainers: didn't prevent any pkg-gnome-wide changes to happen...
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL
aps you can simply rely
on them being installed on your machine and run the testsuite but
ignore failures:
run_testsuite || true
but generally packages have the bdeps for the testsuite they run.
Also, make sure you honor nocheck in DEB_BUILD_OPTS.
Cheers,
--
Loïc Minier
--
To
kbook.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-rc4-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Loïc Minier
sted to talk to
the Python Packaging Team.
I'd like to join the Python Packaging Team to work on Louie and
probably the other existing modules the team maintains.
My Alioth username is "lool".
Thanks,
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
bute
> 'get_rgba_colormap'
get_rgba_colormap was added in pygtk 2.9.0. You might want to request
the exact requirements of your script to his provider.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
you use a backport or build it yourself.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wful if we had to switch back to RH just
> because if this, i really like debian ;)
It's in python-gnome2-desktop.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
; keyword;
> * making Provides: meaningful in the case of inter-module
> dependencies, as discussed at Debconf;
> * fixes to the erroneous python-support section.
Looks good; this obviously implies that python-central will need to
match the new dependency functionalities.
the default, it will have to
> depend on "python-gtk2 (>= someversion), python2.5, python2.5-gtk2".
> This will fail to bring a python2.5-gobject implementation.
Sure, I do see the problem in this case, but I think it's not very
common. The problem didn't turn up very often with
ed before the default version is switched.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
modules and/or extensions.
PS: you might want to configure a real domain in your message-ids
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d be solved by python-defaults upload to
experimental to list python2.5 as supported as well?
I agree python2.5 is not very useful in itself as is.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
running python rtupdate hook $hb"
errors=yes
fi
done
(There are also pre- and post-rtupdate hooks, but these are mostly
useful when the default runtime changes.)
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the source package
does not build the 2.5 flavor. Either patch pygtk's debian/rules or
patch pyversions and rebuild pygtk.
Cheers,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ill break if not an absolute
pathname.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Aug 24, 2006, Ian Ward wrote:
> http://mentors.debian.net/debian/pool/main/u/urwid/urwid_0.9.6-1.dsc
Uploaded. Would be nice to have an upstream ChangeLog.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
similar containing the name of the python runtime and
build it multiple times, solution b) could be to only build for one
version of python.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t take some time during my holidays
(starting friday) for this.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rt man page.
Perhaps the wiki page http://wiki.debian.org/DebianPython/NewPolicy is
the best place where you can see how the two tools differ?
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
e
replaced by debian/pyversions.
Is your document targetted at inclusion in the dev-ref?
PS: I really don't see the point in cross-posting to debian-devel@,
please either post to one or the other, thanks.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
uot;XS-Python-Version:
current", have a look at "flumotion" which has private modules which
are compiled in place (in /usr/lib/flumotion) for the current version
of python on install, and are recompiled on upgrades.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To U
nome-menu2 (>= 2.14.0), python-central (>= 0.5), python (>=
2.3), python (<< 2.4)
Python-Version: 2.3
So the results are entirely the same with the patch.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-Python-Version: 2.3, and it resulted in the same
binary headers.
Is it possible at all to achieve a python2.3 package??
I think the only solution I have is to build for all versions now.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
same source package,
gnome-menus.
I'll try to strip the shebangs of the private module and see whether it
helps, if not I will resort to building for all available python
versions, even if only one will actually be used. :-/
Thanks,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To U
debian.org/~doko/pythontst/, and its maintainer scripts
didn't seem to have the feature either.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
3 dependency
instead of pure python dependencies? And why does it "conflict" with a
"python" 2.4?
The extension would certainly still work when used from python2.3 after
the switch, and this seems to make upgrades harder.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--
n where one might upgrade
from pythonXX-foo before etch to python-foo etch+1. etc.
Given that we recommend the double depend in cases where a particular
version is needed, it seems quite reasonable to recommend it in all
cases instead.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To
Package: python-defaults
Severity: important
Tags: patch
Hi,
As explained on debian-python@ in the attached message...
Here's a patch.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--- Begin Message ---
Hi,
Python Policy 3.2 states:
3.2 Programs Using a Partic
-omg as a real package
installed -- won't get python-pyorbit-omg.
Shouldn't such packages Depend on "python-pyorbit-omg,
python2.4-pyorbit-omg", even if they don't need a particular version of
python-pyorbit-omg (contrarily to what 3.2 §2 requests)?
Bye,
--
Loïc
On Tue, Jul 11, 2006, Loïc Minier wrote:
> From gst0.10-python's configure.ac:
[...]
> PYGTK_DEFSDIR=`$PKG_CONFIG --variable=defsdir pygtk-2.0`
> => (/usr/share/pygtk/2.0/defs: I can only ship that one time)
> PYGTK_H2DEF=`$PKG_CONFIG --variable=codegendir
On Tue, Jul 11, 2006, Loïc Minier wrote:
> It's also possible to influence the PKG_CONFIG_PATH, eg.
> PKG_CONFIG_PATH=/usr/lib/pkg-config/python2.3:$PKG_CONFIG_PATH in
> debian/rules.
I tried this, and it wasn't too hard except it needed a "rtupdate"
script t
On Tue, Jul 11, 2006, Loïc Minier wrote:
> Or should pyexecdir be dropped from .pc files?
After some IRC discussion, this is not an option, and would violate the
contract between the upstream .pc file authors and the upstream
application developers trying to use these .pc files.
Some ot
age symlinks of pygtk-2.0-pythonVER.pc?
Perhaps we should introduce a /usr/lib/python/site-packages dir which
always points to /usr/lib/pythonCURRENT/site-packages and make .pc
files reference that?
Or should pyexecdir be dropped from .pc files?
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
Package: wnpp
Severity: normal
Hi,
After some checks with the pkg-gnome maintainers, and following the
discussions in debian-gtk-gnome and debian-release concerning the
status of GNOME 1, I'm orphaning a couple of GNOME 1 packages.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
52 matches
Mail list logo
