Raphael Hertzog writes:
> Hello everybody,
>
> I completed the documentation of the python-modules alioth project.
>
> Please check out:
> http://python-modules.alioth.debian.org/python-modules-policy.html
maybe add a layout for the svn structure?
Matthias
--
To UNS
should be reasonably limited, so otoh, it
> isn't totally required.
>
> So, any opinion on the -defaults change, esp. from Matthias of course,
> is very welcomed.
ok, I did run out of time last weekend, however python2.5,
python2.3-doc, python2.4-doc are in NEW. According your logic abou
7;re talking about.
CC'ing Fabio, AFAIK that was a zope2.9 upload. Maybe it would be
better, if FTP masters send the reject mail to the Maintainer address,
not the uploader address?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
am (and
> the turbogears project provide "custom-made eggs" directly on their
> website: http://www.turbogears.org/download/index.html)
that will become interesting ... elementtree is part of 2.5, no egg.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
r on ia64 and hppa,
unreproducible on local machines.
other test failures:
- test_bz2 on alpha (decoding error)
- test_bsddb3 on amd64 (locking error)
Thanks for your input.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lt;< 2.6)
Python-Version: 2.3, 2.4
with the python2.5 package providing python2.5-ctypes. Same thing with
other modules, which are included in the python standard library.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gt; Hmm, seems a bit backward to me. What if I don't have python2.3 installed at
> > all. What's the point in keeping /usr/lib/python2.3/site-packages/foo.so
> > around?
The advantage to have extensions for the python version you switch
from and for the version you sw
think
> > he's the only dpmt admin in mx (gpastore and i weren't). Probably
> > others dmpt members were too. Well, break the silence and give me
> > updates, please. :)
>
> I were, Matthias Klose was, and Josselin was (and many more people like
> Jeroen, Anthony,
Thomas Bushnell BSG writes:
> "Sanghyeon Seo" <[EMAIL PROTECTED]> writes:
>
> >>From what I can tell, nothing have changed since this summary by
> > Raphael Hertzog two weeks ago:
> >
> > http://lists.debian.org/debian-python/2006/05/msg00034.h
thon2.x-foo packages under
> this policy, and any Python package would still need to be rebuilt
> during a transition, I don't see how this policy does anything useful.
see my slides from Debconf.
- we are able to make a transition with one upload (python-defaults)
- no extension mo
Steve Langasek writes:
> On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote:
> > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> > > * the dependencies (hopefully created automatically by dh_python) will
> > > indicate the right interval automatically:
> > > right now for
non-standard
module, which the package doesn't yet provide, you have to upload it
again to i.e. add the Provides: python2.5-foo. Note that we can do
such an upload using a binary NMU.
> - python2.x-* packages -- are they needed? desirable?
>Steve and Matthias gave different answers,
nalysis from February.
> 4) I am still unsure of, because Steve and Matthias gave different
> answers, and your answer is confusing -- if they're desirable, let's
> make them required; if not, let's not pollute the (virtual) package
> namespace unless we need them for a sp
> >
> > we agreed to use this information so that you can decide on package
> > rebuilds based on the Sources and Packages files. See my slides from
> > Debconf.
>
> Where are those slides ?
http://people.debian.org/~doko/pycentral/
> Should we be aware w
t see a
> reason to include them, specially duplicating that files for every python
> version
python-central doesn't touch the header files. I would consider the
header files as version specific. have one header be generated and
including the python version ...
Matthias
--
To UNSU
Raphael Hertzog writes:
> On Tue, 06 Jun 2006, Matthias Klose wrote:
> > assume we want to add a python2.5 package. It's nice to have, but
> > extensions will need an update, or they will FTBFS. At this point I
> > would rather not see python2.5 as supported.
>
>
Raphael Hertzog writes:
> On Tue, 06 Jun 2006, Matthias Klose wrote:
> > > > The 'Provides: python2.3-foo, python2.4-foo' is missing for all
> > > > packages with private modules and scripts (without shared modules).
> > > > For that case we do n
Joe Wreschnig writes:
> On Thu, 2006-06-08 at 09:33 +0200, Raphael Hertzog wrote:
> > [ Please don't keep the BTS cced if you reply unless you want to express a
> > concern about the dh_python implementation suggested by the bug ]
> >
> > Hello everybody,
>
Joe Wreschnig writes:
> Please don't Cc me. I am on the list.
>
> On Thu, 2006-06-08 at 23:05 +0200, Matthias Klose wrote:
> > Joe Wreschnig writes:
> > > On Thu, 2006-06-08 at 09:33 +0200, Raphael Hertzog wrote:
> > > > [ Please don't kee
sts on two recent packages with
> > python-central and python-support. I'd like people to try to recompile
> > some actual python-related packages modules with that dh_python and check
> > if it's really enough backwards compatible.
>
> OK, I did test it myself fina
to package
this kind of package, duplicating all files for all supported python
versions in /usr/lib/python2.X, significantly increasing the package
size. Is there another way to support this or is this the only option?
Matthias
[1] http://lists.debian.org/debian-python/2006/01/msg00065.html
Raphael Hertzog writes:
> Hi all,
>
> first of all Matthias will announce shortly the timeframe of the switch to
> Python2.4 by default. He will upload ASAP the new python-defaults to
> experimental and a few days later to unstable.
I'm attaching here a draft for an a
Graham Wilson writes:
> On Sun, Jun 11, 2006 at 05:50:06PM +0200, Matthias Klose wrote:
> > - Some infrastructure was implemented to remove all hardcoded
> >information about versions in the packaging scripts, so that
> >sourceless package rebuilds (binary NMUs)
;s issue (python's/module's version in dirname)
the python version information should be dropped, the module's version
can be dropped. Checked with Phil Eby.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ving copies of the same .py files in
/usr/lib/pythonX.Y, so that can be done as well (example is
python-newt which comes with one extension and one module).
Extensions and modules in packages (the python sense, a directory with
an __init__.py) must end up in the same directory.
Matthias
--
ot match what has
> been announced in XS-Python-Version, then I might start using it (but I
> have perl code to do the same since it was in my first dh_python).
we should detect that. the resulting package will not be usable?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t $(shell pyversions -d), $(shell pyversions -r))
build: $(EXTRAVERS:%=build-python%)
build-python%:
python$* setup.py build
install: build $(EXTRAVERS:%=install-python%)
install-python%:
python$* setup.py install --no-compile \
--root $(CURDIR)/debian/python-foo
Hacking th
e the XB-Python-Version field
- add section about provides
- extend paragraph about byte compilation
- remove the paragraph about distutils
- enhance the section about support tools
Matthias
pypol.diff
Description: Binary data
%, $(shell pyversions -r
> > debian/control | grep -E "^python[0-9.]+( python[0-9.]+)*$$"))
>
> You shouldn't be removing "python" here because "pyversions" may return
> "python"
> (without any version) if XS-Python-Version is "current".
pyversions -r always prints the resolved, real versions.
Matthias
e python2.5 in the set of supported
versions in an upload to experimental, we can easily check all
packages for python2.5 compatibility (building at least).
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ns from both
python2.3 and 2.4, so that we are able to ship them in one package.
In that case, these must be installed in /usr/lib/python. Just moving
the identical files becomes a bit complex; it is handled by pycentral,
but not by dh_pycentral, so you have to move them yourself.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t; be able to release any other debhelper fixes in that timeframe either.)
could you agree in temporarily/permanently splitting out dh_python
from debhelper?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pport both (the old and the new) installation
directories. We should not do that right now, but try not to reference
the support/central dir in the packaging, so that the packaging
doesn't need to be changed later.
Comments?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
Brown paper bug ... as a workaround, install python2.4, so that both
python2.3 and python2.4 are installed, or install 0.4.17 from
http://people.debian.org/~doko/tmp/python-central_0.4.17_all.deb
or from http://incoming.debian.org/ when it's available there.
Matthias
--
To UNSUBSCRIBE,
Bill Allombert writes:
> Package: python-central
> Version: 0.4.3
> Severity: important
>
> Hello Matthias,
>
> There is a triangular dependency between python-central, python and python2.3:
>
> python-central:Depends: python (>= 2.3.5)
> python
A >= 2.4
in the version fields doesn't hurt and we can get this information
from exactly one place.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pyversions.py script to
remove the dependency on a specific version of python.
- scripts placed in /usr/share/python/runtime.d can be executed
- after the installation of a runtime: *.rtinstall, passed
parameters are: rtinstall
- before the removal of a runtime: *.rtremove, passed parame
u know how I am supposed to get my "system" upto 2.4?
flup was probably built with python as found in experimental.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Adeodato =?utf-8?B?U2ltw7M=?= writes:
> Hi,
>
> I noticed that python-crypto had undergone the new Python Policy
> transition thanks to a NMU from Matthias Klose [1]. However, I could not
> update to this version, since python2.4-paramiko Depends: python2.4-crypto,
> but the
ther usage is getting information about the packages
without looking at the contents of the package itself.
I tried to explain why the dpkg database is the primary place to store
the meta information. We certainly did clutter the database with the
pythonX.Y packages. I really do not consider th
e is not installable anymore under Sid. I've
> > tried to adapt the python package to the new policy, but with no success.
> >
> > So, until I've more time to look into this, I'd like that someone would
> > create
> > a NMU for this package.
simplified th
d if it would fail, then it tries "debian/pyversions"
> > before failing.
>
> Okay yet another update (the last... I promise). Instead of requiring a
> parameter you can now call "pyversions -r" and in that case it will check
> first for the field in debian
> install_scripts run).
+1. The proposal doesn't fix a bug. The same thing can be done by
calling the unversioned interpreter, if it's the default one. or by
explicitely changing the interpreter, like it's currently done in many
packages.
Matthias
PYVERS=$(shell pyversion
Package: debhelper
Version: 5.0.37.3
Severity: important
Looking at python2.4-schoolbell, ${python:Depends} is expanded to
python-central (>= 0.5), python (<< 2.5), python (>= 2.4) | python2.4
which is wrong.
- the package can be installed, even if 2.5 is the default version
- the 'python (
Raphael Hertzog writes:
> tag 378604 + patch
> thanks
>
> On Mon, 17 Jul 2006, Matthias Klose wrote:
> > Package: debhelper
> > Version: 5.0.37.3
> > Severity: important
> >
> > Looking at python2.4-schoolbell, ${python:Depends} is expanded to
> >
ugh.)
> >
> > I agree that having Python-Version in binary packages is dislikeable.
> > Out of curiosity, Matthias, would be a DEBIAN/pyversions file able to
> > provide the same information to pycentral?
the point of having Python-Version in the binary lets you determine
Please could you check dh_python with the patch from #378604?
Loïc Minier writes:
> On Tue, Jul 25, 2006, Joe Wreschnig wrote:
> > The scripts in /usr/lib/python2.3/site-packages/GMenuSimpleEditor call
> > plain "python". That's probably causing the dependency.
>
> After I've "sed 1d" the files,
rformance, but some applications
need it). The packages are prepared for that; if you can test it,
please do.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ks in principle but I wonder if there is some other reasonable
> way.
confused; why a shell script, when trying to get the version of the
*running* interpreter. This should be
import sys
v = sys.version[:3]
It's somewhat communicated that this won't break/change upstream.
Matthia
the default before the
transition freeze.
Matthias
might want to check with the 3.13 bugs
already filed by Stefano for overlaps, but that should not be a
showstopper. It's important that maintainers are aware of these reports,
and that we can raise severities when we are progressing with the 3.13
transitions.
Matthias
is ready to start the python3.13-add transition.
plus we should not do that before the 3.13 upstream release. I'm
targeting 1-2 weeks after the 3.13 release for the addition of 3.13 as a
supported Python version.
Matthias
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a tracker to add python3.13 as a supported python3 version.
This is non-blocking, as packages can migrate on their own once bui
On 18.10.24 18:48, Scott Kitterman wrote:
On October 18, 2024 2:07:35 PM UTC, Simon McVittie wrote:
On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is
levels of this addition are done.
Matthias
[1] https://release.debian.org/transitions/html/python3.13-add.html
for the Python 3.12 transition. Please note
that we don't enable any of the experimental features in Python 3.12 (no
GIL, JIT compilation), so assuming there are currently no other RC
issues in your packages, there should plenty of time to fix any 3.13
related issues.
Matthias
nd of
documentation is not helping very much. So maybe the people already
knowing all the quirks could come up with a way to rewrite the docs?
We even could have that as the first topic for a Python BoF, before
starting any other topic ...
Matthias
On 02.11.24 18:35, Sebastian Ramacher wrote:
Dear toolchain, debian-installer, and image maintainers,
We, as the release team, are aware that we are late with the
announcement of the freeze timeline for trixie. After some internal
discussions on how we want to handle the freeze for trixie based
__init__.py" are not copied in
from the source tree,
and without them Python refuses to recognize the copy.
Ugh.
Do we have any other namespaced packages in the archive? How do *they* handle
this?
--
-- regards
--
-- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
top of my TODO
list …) if anybody wants to take a closer look.
--
-- regards,
--
-- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 09.01.25 10:34, James Allwright wrote:
Hi package maintainers,
I have noticed that pkg-config in not returning the library I need to
link to for python.
pkg-config --libs python3
is returning nothing, when I expect
-lpython3
I think the problem is in file
/usr/lib/x86_64-linux-gnu/pkgconf
On 08.01.25 21:36, Scott Talbert wrote:
On Wed, 8 Jan 2025, Soren Stoutner wrote:
Python3-hid was marked `Multi-Arch: same` by a previous maintainer.
Recently,
tracker.debian.org warned that there is an issue because the WHEEL
file is
different in each package.
https://tracker.debian.org/pk
/llvm-toolchain-15_1%3A15.0.7-15build1_1%3A15.0.7-15ubuntu1.diff.gz
Matthias
readable:
# ...
#FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
# ...
Now it looks better.
My question is: How do I change (or set) the default font that is used
by Python/Tkinter ?
TIA
Matthias
--
Matthias Müller Tel.:+49 30 449 80 68
e-Mail: [EMAIL PROTECTED]
--
501 - 564 of 564 matches
Mail list logo
