When building a package with python-all-dbg, dh_auto_build does this:
dh_auto_build
python2.5-dbg setup.py build
python-dbg setup.py build
python2.5 setup.py build
python setup.py build
This results in build/scripts-2.6/* having python-dbg in the shebang
line. B
Joey Hess wrote:
> Andrew Straw wrote:
> > To be sure I understand, you're saying this is a bug with setuptools,
> > because it autogenerates the /usr/bin/my_script improperly at install
> > time when called by "python2.4 setup.py install"?
>
> No, the pr
Andrew Straw wrote:
> To be sure I understand, you're saying this is a bug with setuptools,
> because it autogenerates the /usr/bin/my_script improperly at install
> time when called by "python2.4 setup.py install"?
No, the problem is, loosely speaking, that python is on crack.
The order in which
Bernd Zeimetz wrote:
> Normally the scripts are not copied a second time, if they exist at the
> destination (have a look at winpdb, for example - if you want to build it in a
> chroot, don't forget to s/python/python-all/ in the build-deps. So usually -
> and
> in my experience - dh does the righ
Joachim Breitner wrote:
> hi,
>
> Am Mittwoch, den 23.09.2009, 21:27 +0200 schrieb Jakub Wilk:
> > >We discussed possible breakage in #520834 but missed the case that python
> > >script shebang lines would be modified like this. This seems to be done
> > >by python2.4 setup.py, but not by python2.
Joachim Breitner wrote:
> it seems that this is actually a bug in dh: It seems to call setup.py
> twice, once for each version of python, including adjusting the shebang
> line. Then, as the the python version tried last ist 2.4, this modified
> script is shipped with the package.
>
> I’m not sure
Julian Andres Klode wrote:
> pyversions -r lists all supported versions if the field in debian/control
> and debian/pyversions are both missing. If debian/pyversions is empty it
> would fail, but debian/pyversions should never be empty.
>
> At least this is what I saw in my local testing.
You're
Package: python-central
Ben Finney wrote:
> Ideally, I'd only need those rules to say:
>
> =
> .PHONY: install
> install: build
> dh --with python_central install
>
> .PHONY: binary-indep
> binary-indep: build install
> dh --with python_central binary-indep
> =
>
> This
Tristan Seligmann wrote:
> Well, fair enough; I suppose the README.Debian note should not be quite
> as explicit as I made it. I'm just not very happy with the gratuitous
> (in my view) change to the upstream tarball, so I wanted to be as clear
> about it as I could for anyone else wondering why it
Tristan Seligmann wrote:
>* Ship modified upstream tarball, removing insulting source code, and put a
> note in README.Debian to explain why we're doing this (closes: #477454).
For the record, your README.Debian consists of:
The upstream tarball for quodlibet in Debian does not match
Josselin Mouette wrote:
> At least python-support is not the only package to do that. On my
> system, the following directories are generated upon package
> installation and will not change in other situations:
FWIW, you forgot
/var/lib/dpkg/info
(And yes, I've argued before that this d
Ben Finney wrote:
> Does anyone know debhelper better than me, and can suggest ways to
> improve that package's current 'debian/rules' file to make better use
> of debhelper 7 with 'python-central'?
python-central could include a dh sequence file, then you could use
something like:
dh bin
Ben Finney wrote:
> This is referring to the debian/control Depends field:
>
> Depends: ${python:Depends}
>
> Earlier, I had
>
> Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
By removing misc:Depends, you are simply potentially shooting yourself
in the foot. Debhelper c
Raphael Hertzog wrote:
> As I can understand him, we really should respect his wish. If Matthias
> agrees,
> I can extract the "dependency" generation code from dh_python and create
> a little perl library that would be included in the python package
> (or python-dev) and that would be used by dh_
(Thanks for the CC.)
Matthias Klose wrote:
> I haven't yet seen any reasoning why people are seeing that
> information as "cluttering the database" or just as "ugly".
Causing unrelated programs like dpkg-repack to spew warning messages is,
by definition, ugly.
Using X- fields, which are intended
Hugo Vanwoerkom wrote:
> dpkg-repack (from sid dpkg 1.13.22) gives warnings when repacking python
> packages:
>
> ...
> warning, `./dpkg-repack-5343/DEBIAN/control' contains user-defined field
> `Python-Version'
> ...
>
> What effect does this have? Can the .deb be used or not?
It's harmless,
I don't particularly mind that you've chosen to NMU debhelper. However,
I can't guarantee that I will preserve the interfaces that you've added
to dh_python in a backwards compatible way when I get around to looking
at it.
(FWIW, I began ignoring this issue when the politics and constant
advocacy
Raphael Hertzog wrote:
> Because Matthias and Josselin do not (or can't or don't want to) work
> together. I tried my best to fill the gap. :-/
I appreciate your work, but I am not comfortable supporting two
competing implementations in debhelper.
Sorry.
--
see shy jo
signature.asc
Descriptio
Kevin Mark wrote:
> Giving away code (GPL or otherwise) to the world is done for many
> reasons. Aparently some folks are more concerned about how their work
> is used. As with the attribution in .debs, folks want the users to not
> associate possible (as judged by them) 'bad'/'unofficial'/'off
>
Matt Zimmerman wrote:
> On Thu, Jan 19, 2006 at 03:34:58PM -0500, Joey Hess wrote:
> > If we followed the same method for python-base, then we would
> >
> > a) instroduce python-base iff we had some package(s) written in python
> >that we wanted in the base syste
Colin Watson wrote:
> FWIW the relevant design docs from when this was done in Ubuntu are
> here:
>
> https://wiki.ubuntu.com/EssentialPython (requirements)
> https://wiki.ubuntu.com/PythonInEssential (details)
>
> The rationale for the set of included modules is in the latter, and was
> basi
Matthias Klose wrote:
> Josselin Mouette writes:
> > Furthermore, if you want to see this implemented, you'll have to find
> > someone else to write the necessary changes to dh_python. I will not
> > write nor maintain any code that parses the control file in dh_python.
> > This script is already o
Luca - De Whiskey's - De Vitis wrote:
> On Fri, Nov 14, 2003 at 01:28:21PM +0100, Andreas Tille wrote:
> [...]
> > Hmmm, are you sure that this paragraph in the manual makes sense
> > I guess if a zope package depends from zope all relevant debconf information
> > is available and copying the s
Andreas Tille wrote:
> On Thu, 13 Nov 2003, Denis Barbier wrote:
>
> > This was your original point, then Andreas Tille and Federico Di
> > Gregorio replied that this explanation does not apply here because all
> > packages depend on Zope, you agreed and proposed to drop templates,
> > and everyon
Josip Rodin wrote:
> Am I the only one who has a disgusting reminiscence of netscape*.* packages
> every time python* is mentioned? :P
Actually I'm more reminded of the perl* packages and the complete mess
that followed. And I keep expecting to see the same set of problems
affect python.
--
see
The current set of packages installed by the python task:
python
python-doc
ddd
python-htmlgen
idle
python-dev
python-examples
python-extclass
python-gdbm
python-gdk-imlib
python-gendoc
python-glade
python-gnome
python-gtk
python-ldap
python-mpz
python-xml
If someone who knows py
Bernhard Kuemel wrote:
> Thank you very much. I had python 2.1 installed and with 2.2 the
> problem disappeared. Seems python2.2 should be a dependency for
> debconf and mailman.
Why? They only run python2.2 if it can be found in the path. I dont
really understand how you could possibly have seen
Josselin Mouette wrote:
> Your python installation is screwed. The compileall.py module in Debian
> does support -q in all versions. It's not possible to be mistaken about
> that, as the error message included in Debian's compileall.py is not
> exactly this one.
Ok so it is a local install of an o
Bernhard Kuemel wrote:
> apt-get dist-upgrade now won't install even a single package. At first I
> chose severity normal because mailman depends on debconf, but now
> totally unrelated packages don't get installed. Unfortunately it seems
> reportbug won't set the severity of this bug to critical b
Tasksel expects to find a bunch of packages in woody that arn't there.
This is not often a big deal; the missing packages will be silently
skipped. That can sorta suck if it is one of the core packages in the
task though.
Of particular note is the missing KDE metapackage, which means
that new wood
David Coe wrote:
> There are/were a minor bugs against the task-python-* packages in
> unstable, all due to broken dependencies; those are easy to fix, but
> are one of the things that drove us away from the old task-* packages,
> as I understand it.
Yep. It's not the end of the world in the new s
Jérôme Marant wrote:
> According to Joey Hess, it seems that the python-dev needs
> someone to maintain it.
Well, the best maintainer would probably (presumably) be the
maintainer[1] of task-pthon-dev. I'm going to go through and contact the
maintainers of the task packages indi
Moshe Zadka wrote:
> s/posible/certain/
> Python 2.1 already contains many features future programs will be
> able to use. (It's not out now, but alpha is supposed to be released
> in a few days)
> OTOH, all Python programs in Debian *should* work with 2.0. If they
> do not, then they have a bug
Disclaimer: I don't know much about python. I just want to make sure
that you're not making the same mistakes that were made when perl was
modified so multiple versions could be installed at one time.
> . Python 1.5 was installed and we decide to install 2.0
> python 1.5 specific package
Stefan Gybas wrote:
> I would also prefer such a scheme. What about colons in package names?
> I know that they are currently not allowed but is there a technical
> reason not to allow them? According to footnote 14 in the packaging
> manual, colons used to be legal. Was this changed when epochs we
Gregor Hoffleit wrote:
> FYI: Alexander Reelsen filed bug#41113 against debian-policy, which
> is of interest for debian-java, debian-python as well as debian-perl:
>
> Currently, the Python maintainers have an implicit policy to use a
> naming scheme of python-foo-bar for all Python extension mod
36 matches
Mail list logo
