Re: Bug#589759: debhelper: dh_auto_install + python-all-dbg changes shebang of scripts
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. Because the default distutils behavior for a script is to not overwrite it if it's already been created in build/. [0] dh_auto_install runs setup.py install --force, so the last python to run wins, which ensures that the script installed has an unversioned python in the shebang. (Bugs #548392 and #547510 explain the whole nasty story behind needing to do that.) It *seems* that bug #589759 can be dealt with by also making dh_auto_build pass --force to setup.py. It certianly fixes it in the case in this bug[1]. It may cause unnecessary work, or who knows, may break something else. So I'm CCing debian-python for advice before doing that. [0| It's also possible for a setup.py to build a script by hand, and always overwrite it. So while running python first and python-dbg second would probably fix this bug in most cases, I am uncomfortable doing that. [1] Tested in the case of pyrit by adding the following to its debian/rules: override_dh_auto_build: dh_auto_build -- --force -- see shy jo signature.asc Description: Digital signature
Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
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 packages are installed in > ...python/1.5/site-packages > other packages are installed in ...python/site-packages > > * we make /usr/bin/python point to python 2 thanks to alternatives This is where I begin getting flashbacks to the whole perl SNAFU. Is it possible for a python program to use python 2.0 features and not work with 1.5? Is it possible for a program to use deprecated 1.5 things and not work with 2.0? Is it possible some later version of python after 2.0 will introduce new features programs could use? All of these things were true with perl, and all of them tripped us up horribly. The problem is, if you have two versions of perl (or python) installed and /usr/bin/perl(python) is managed with alternatives, dependancies are useless. A package that uses perl 5.6 (ptyhon 2.0) features should depend on that package. But a user can install an older version still, and can modifiy the alternatives to make it the default, and then the program breaks, even though its alternatives are satisfied. The only way to make a program that uses perl 5.6 (I'll stop putting the equivilant ptyhon stuff in parens now :-) reliably work is to make it use #!/usr/bin/perl-5.6. But this is just shooting yourself in the foot when perl 5.7 comes out and your package works with it fine except it refuses to use it because the filename is different. It's a horrific can of worms, which is why perl in debian is no longer going to do this at all -- it's just not worth it. I encourage you python folks to think this through before adopting a similar scheme. Good luck! -- see shy jo
Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
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 -- and it should be fixed. > So, as a Perl basher , I think Python will not cause the same > problems that Perl did. You mean all python programs will work with 2.0 until 2.1 is out and programs start using its features. At that point every problem I predicted is going to bite you. -- see shy jo
Re: Bug#41113: Proposal: Naming Conventions for modules
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 modules. > > If Alex proposal gains support, we may have to change this convention > to something like libfoo-bar-python (as I don't think the Perl people > would be glad to change their package names ;-). I wish they would. Perhaps I'm in the minority, but when I want a perl module package, I know it's a perl module. I don't necessarily know the module part of the package name. So I'd like to type: # dpkg --print-avail libperl- And get a list of perl modules [1]. But I can't do that. I can with python modules though, which is very nice. -- see shy jo [1] I have zsh set up to do such command line completion of dpkg commands. Quite a time saver.
Re: Bug#41113: Proposal: Naming Conventions for modules
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 were > introduced? Probably. It would rock if we could use the exact module name as the package, I agree. :-) -- see shy jo
Re: Status of the python-dev task
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 indiviually and work this stuff out. > This is a very long list and I'm not sure all of them should > be put in a single task, for few reasons: > > - there are both python and python2 package. > - some of them are not used a lot. I seriously doubt that they all belong in any task. If we had a perl task, it would be *insane* to make it include lib*-perl. Knowing little of python, I can only draw an analogy. Our guidelines include the following: Care should be taken when adding new tasks to ensure that the new task is suitably generic -- it should be something of value to a large number (at least 10%) of our users. It must not perform the same general purpose as some other existing task. It must contain packages that are the ones in most common use, and software that is of the best perceived quality. > As long as there is a speration between python and python2, > I would propose to create a second task called python2-dev > that would contain all python2 specific packages. > (I still don't know what was stated about the separation, so > does my proposal make sense?) > > Now, some questions: > - what packages are not worth having? > - should we split the task in smaller ones? You have to run new tasks by myself, Anthony Towns and Randolph Chung right now. The guidelines and working consensus we have is emphatically against splitting up tasks (see above), and the set of tasks we've settled on was chosen after a lot of consideration to be at the right level of granularity (though we're certianly open to interesting new tasks if they meet the guildlines). If the python/python2 split is a problem, the maintainer of this task basically has to decide if it will offer python, python2, or both. Another thing to bear in mind is that the new system makes it reasonably easy to select a task thus selecting all the packages in it, and then drop down to per-package selection and remove or change some of the selections, before anything is installed. -- ±see shy jo [1] Hi David. The only task-pthon package I can find is in potato.
Re: Status of the python-dev task
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 system if a task lists a package that no longer exists. It may slightly break the task, but it is handled gracefully. Tasks can also refer to packages that are only in non-us and they will continue to work even if the system doesn't have a source for non-us. > I had also planned to create a parallel set of task-python2-* > packages, as a result of brief discussion on debian-python, and > can still do that if task-python[2]-* packages are still desired. > > task-python-dev, in particular, is probably not very useful; we had > discussed the pros and cons of having that, on the debian-python list > when task-* packages were first created, and decided to (iirc) go > ahead and create it to see if anyone uses it. My guess is we > could drop that one and no one would complain. > > Joey, what *should* happen with these task-[python-]* packages? > Should I bring them up to date for sid? for woody? What should > I read (e.g. where are the following guidelines)? See tasks/README in tasksel's source. We do have a few other -dev tasks, and I think it can be sorta useful to get a task that lets you get started quickly on using a particular langage. (In particular, the c-dev task should also let you build most any program you run accross.) At the same time, I do think they're amoung the shakier of the tasks we have now (expecially fortran-dev!). I'm not sure what these pthon2-* tasks are intended to do or why you think more than one task is needed in this area. -- see shy jo
packages tasksel expects to find in woody, that arn't there
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 woody installs do not get KDE at all, although tasksel claims to let you pick it as part of the desktop task. Someone needs to begin maintaining that package, fix its dependancy problems, and get it into woody posthaste. No cxterm-gb! No cxterm-big5! update-excuses hates it. If anyone cares about cxterm, someone needs to figure out why it has all these unsatisfiable Depends. No kde! Again, very, very bad. No asiya24-vfont! Has some RC bugs. Seems to be in the process of being removed, according to update-excuses, although they are all fixed. Hmm. No junior-programming! I wonder there this went. Ben? No python-base! No dpkg-python! No python-distutils! No python-mxdatetime! No python-mxstack! No python-mxtexttools! No python-mxtools! No python-pam! No pythondoc! No sulfur! Someone who cares about python needs to look at its task and send us a corrected version. Preferably a much smaller corrected version, the current one is ridiculously bloated. No mueller7-dict! Has rc bugs, and updates-excuses implies it is in the process of being removed. No dialdcost! Was only in stable, is there a replacement in unstable? -- see shy jo
Re: Bug#178373: debconf: severity critical
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 but I was asked > if this bug is already listed and enter it's number. Should I have filed > a new bug report? It should not be severity critical anyway, packages break in unstable from time to time and there are workarounds to upgrade everything else. Anyway. > s:~# apt-get dist-upgrade > Reading Package Lists... Done > Building Dependency Tree... Done > Calculating Upgrade... Done > The following NEW packages will be installed: > libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl > libmailtools-perl libmime-base64-perl liburi-perl libwww-perl > 87 packages upgraded, 7 newly installed, 0 to remove and 0 not > upgraded. > 2 packages not fully installed or removed. > Need to get 0B/60.6MB of archives. After unpacking 8738kB will be used. > Do you want to continue? [Y/n] > Preconfiguring packages ... > Setting up debconf (1.2.21) ... > option -q not recognized > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp] What version of python2.2 do you have installed? What does it say when you run -- sh -ex /var/lib/dpkg/info/debconf.postinst configure 1.2.21 I was told by some python people that I could use -q after compileall to shut it up, if that no longer works it is porbably a bug in python or possibly debhelper, not debconf. -- see shy jo
Re: Bug#178373: debconf: severity critical
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 old or broken version of python in /usr/local/bin, or something of the sort. I suppose I could make debhelper use an explicit path to a python that we know is in debian, but I generally dislike that approach without very good reasons. I suppose sysadmins should be free to install their own python, even if they do break their machine in the process. So all I can do is close this bug report. -- see shy jo
Re: Bug#178373: debconf: severity critical
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 the problem with debians python 2.1, which provides a python2.1 binary, or fixed it by upgrading to 2.2. I suspect you are not accuratly reporting whatever happened or are confused. -- see shy jo
python task package needs TLC
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 python would like to maintain this list, mail me. Right now it's being maintained by me, and I don't use, or know python! I've just removed a number of packages that no longer exist, including python-distutils, pythondoc, and dpkg-python, from the list. Also the task is intended now to install enough python packages to make developing python programs pleasant, but not every python module in all of debian. I have no clue if it meets this goal. -- see shy jo pgpYlkAUOgIZ5.pgp Description: PGP signature
Re: [Pkg-zope-developers] Re: Duplicate debconf templates in zope-* packages
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 everyone was happy... but this never happened ;) I'm not familiar with zope's packaging, but I hope you all realize that dependencies are not guaranteed to be satisfied at debconf preconfigure time. That is the reason you sometimes need shared templates. -- see shy jo signature.asc Description: Digital signature
Re: Duplicate debconf templates in zope-* packages
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 same stuff over and over makes no sense at all > > except from enhancing the probability of errors. > > Sorry, i now realize that i did not in consider policy explanation on what > Depends field mean. > > Perheps some sort of note in that paragraph of debconf-devel would have been > useful. I mean something like "Including the shared question, is not required > if all packages depends on the one which provides the template (see section > 7.2. of Debian policy)" That's not at all accurate. Every package that has a config script that expects to use a template must include a copy of the template in the package. Dependencies will not be honored at preconfigure time. -- see shy jo signature.asc Description: Digital signature
Re: python 2.2 -> python 2.3 transition
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 shy jo pgpXISG37Hhdy.pgp Description: PGP signature
Re: python packaging infrastructure
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 one of the most complex ones in debhelper, and > > Joey, would you accept a reimplementation in python? at least the use > of dh_python already requires a dependency on python. No, debhelper has to all be implemented in the same language. -- see shy jo signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
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 > basically done by taking each module in perl-base and mapping it to its > Python equivalent. FWIW, that's a fairly strange way to do it, since modules are added/removed from perl-base as needed by the perl-using programs in the base system. For example, perl-base includes Data::Dumper because debconf (used to) use it, not because there's any other particular reason to include that module in base, and I've just asked that Data::Dumper be removed, so including its equivilant (pickle) in python-base on that rationalle is decidely strange. 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 system (apt-listchanges comes to mind) b) include only the modules needed by the package(s). -- see shy jo signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
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 system (apt-listchanges comes to mind) > > b) include only the modules needed by the package(s). > > Please don't do this; it implies that python-minimal would be part of base, > but not full python, and this is something that python upstream explicitly > objects to. It implies no such thing. -- see shy jo signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
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 > project'/'different' work with their projects. But the perl folks don't > seem to have that objection! x-) (at least none have spoken yet!) perl is priority standard and so it is part of default Debian installs unless the user explcitly asks aptitude not to install it. -- see shy jo signature.asc Description: Digital signature
Re: Bug#370833: New dh_python proposal
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 Description: Digital signature
Re: Bug#370833: New dh_python proposal
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 and pressure became too annoying to bother with, and I expect to ignore it for at least another couple of weeks. Unfortunatly that means that to avoid either trampeling over or blessing your NMU, I won't be able to release any other debhelper fixes in that timeframe either.) -- see shy jo signature.asc Description: Digital signature
Re: dpkg-repack warnings: what effect?
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, though perhaps a pity that the python maintainers decided on this ugly solution. > Would it be true to say that only those .debs cannot be used where there > are warnings that the package may be broken? Like: > > ... > cp: cannot create regular file `./dpkg-repack-15399//etc/pam.d/cupsys': > No such file or directory > dpkg-repack: Error running: cp -pd /etc/pam.d/cupsys > ./dpkg-repack-15399//etc/pam.d/cupsys Don't you have a /etc/pam.d/cupsys? It's in the cupsys package unless you delete it.. > tar: -: file name read contains nul character > dpkg-repack: Problems were encountered in processing. > dpkg-repack: The package may be broken. > dpkg-deb: building package `cupsys' in `./cupsys_1.2.1-3_i386.deb'. > ... > And *all* uses of dpkg-repack have that "file name read contains nul > character" now. That's bug #375749, which is harmless. -- see shy jo signature.asc Description: Digital signature
Re: dpkg-repack warnings: what effect?
(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 for nonstandard extensions, in the core of Debian is also ugly. > Same thing > with a missing attribute "Homepage", which often is hidden in the > description anyway. Modify dpkg to properly add new fields if they're going to have common usage in Debian. Using X- fields is fine for prototyping but not for final implementations. -- see shy jo, hyprocritically signature.asc Description: Digital signature
Re: Future of dh_python
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_pysupport and dh_pycentral. > I can also prepare patches for dh_pysupport/dh_pycentral. If I were you, I would probably make that a little python program that they can call. Up to you of course. > python-support/central will have to depend on the new debhelper to avoid > generating dependencies twice if dh_python is invoked (as is currently > the case for most packages). > > The new debhelper will have to be uploaded together with the new > python-support/central to avoid any problem (If it is uploaded before, > some packages may not have dependencies at all. If it is uploaded after, > python-support/central won't be installable.) Shouldn't be a problem as long as both python-support and python-central can be modified.. > > Not all packages use the new python policy yet. For example, debconf > > doesn't. I'm not sure if that's a bug or not. One alternative would be > > reverting dh_python to the pre-NMU version (plus a small shim to make it > > a no-op if it detects the new policy), to avoid breaking such packages > > until they transition. > > Indeed, for me it appears unavoidable (cf my suggestion above). > And we must also coordinate the upload of the new version of the > packages. BTW, the main reason debconf doesn't use either method is because AFAIK neither is written to be used by an effectively essential package, which still needs to install if python is broken, not available, or too old. I may have to end up writing my own postinst code in debconf to deal with that, since the old method is also not very robust (#225384). -- see shy jo signature.asc Description: Digital signature
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
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 could need to add a dependency via misc:Depends
at some point in the future, and the only way you'll find out about it
is if you notice it in the changelog. If you keep misc:Depends in the
control file, debhelper will automatically do the right thing in the
future.
> and 'dpkg-gencontrol' complained about every one of those.
This is a misfeature of dpkg-gencontrol.
--
see shy jo
signature.asc
Description: Digital signature
Re: debhelper 7 and python-central
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 binary-indep --with python-central I might need to add a Debian::Debhelper::Dh_Lib::remove_command to the sequence file interface, if it needs a way to actually remove the dh_pysupport call, rather than just adding a dh_pycentral call. -- see shy jo signature.asc Description: Digital signature
Re: FHS location for Python libraries as locally-compiled bytecode (was: debhelper 7 and python-central)
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 does not belong in /var given a strict reading of the FHS..) -- see shy jo signature.asc Description: Digital signature
Re: RFS: quodlibet (1.0.ds1-1)
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 the one distributed by upstream, as a minor change has been made to it. The only difference between the two should be this diff: diff -rN -u old-quodlibet.upstream/player.py new-quodlibet.upstream/player.py --- old-quodlibet.upstream/player.py2008-06-03 19:45:12.247191545 +0200 +++ new-quodlibet.upstream/player.py2008-06-03 19:45:12.311191392 +0200 @@ -289,7 +289,7 @@ gst.debug_set_default_threshold(gst.LEVEL_ERROR) if gst.element_make_from_uri( gst.URI_SRC, -"file:///Sebastian/Droge/please/choke/on/a/bucket/of/cocks", ""): +"file:///fake/path/for/gst", ""): global playlist playlist = PlaylistPlayer(pipeline or "gconfaudiosink", librarian) return playlist If the presense of this buried in an internal source file is so vile/illegal/unlike other profanity in software in Debian that you have to *repackage* the upstream tarball to hide it from the tender eyes of our users (with all the problems that entails), why do you then turn around and add it back in to the most important file that we expect our users to read? My mind boggles. PS: What does quodlibet sponsorship have to do with the debian-python mailing list? -- see shy jo, wondering if perhaps the point is to shield the under-aged python interpeter from the profanity, or what signature.asc Description: Digital signature
Re: RFS: quodlibet (1.0.ds1-1)
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 didn't match the > released tarball. If it were up to me, I wouldn't be making this change > at all, but it seems the alternative is to release lenny without > quodlibet, which is not very satisfactory either. There has never been a clear explaination in #477454 as to why the bug should be considered RC at all, or why, if it is RC, it would require modification of the upstream tarball to fix. There have been vague mutterings about the content being illegal in germany; I've already pointed out in the bug log several other instances of personal insults included in Debian packages. If the people who think this is illegal in germany, and that Debian should censor such speech think this bug is RC, they need to begin a comprensive audit and mass RC bug filing on all the other packages too. (They might also find certian such insults on the Debian mailing lists..) -- see shy jo signature.asc Description: Digital signature
Re: dh_pycentral and dh_pysupport clash
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 does, in fact, cause the 'pdebuild' to succeed.
>
> However, if 'python-support' *is* installed, then this causes *both*
> of 'dh_pysupport' and 'dh_pycentral' to run, and the resulting package
> fails 'lintian':
python-central's debhelper sequence file is missing a line to disable
the default python-support.
remove_command("dh_pysupport");
debhelper 7.0.14 is the first version that will work with.
--
see shy jo
signature.asc
Description: Digital signature
Re: Bug#520834: dh_auto_{build,install,clean} should support different python versions
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 right. > If they use the standard functionality provided by python distutils, > python-distutils-extra or python-setuptools it should work. > > As far as I know cdbs also builds for all requested python versions, > so it should be safe to adapt this way of building. > > I CCed debian-python@lists.debian.org, so we can get some feedback > from there. I'm mostly worried about breaking any existing packages that use dh or dh_auto_*, and somehow contain something that breaks if it's changed to start building multiple times for multiple python versions. (There are probably few if any such packages, but I do have to worry about backward compatability when I change dh_auto_*.) -- see shy jo signature.asc Description: Digital signature
Re: [pkg-fso-maint] Bug#547510: zhone refuse to start
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 what to do differently, thus I’m CC’ing Joey: Is there > something wrong with the way we package zhone (a python script, not a > library)? dh_auto_* looks at pyversions -r to determine which versions of python the package is targeting, and builds it for each version to support C python modules. j...@gnu:~/tmp/zhone-0-git20090610>pyversions -r pyversions: missing XS-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions python2.4 python2.5 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.5 setup.py. In the latter case you get #!/usr/bin/python. (Is this a bug in python2.4?) So I suppose you could work around it by adding the control field listing one python version, probably 2.5. -- see shy jo signature.asc Description: Digital signature
Re: [pkg-fso-maint] Bug#547510: zhone refuse to start
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.5 setup.py. In the latter case > > >you get #!/usr/bin/python. (Is this a bug in python2.4?) > > > > Weird, dh should already take care of this: > > > > $ grep shebang -C1 > > /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm > ># We need to to run setup.py with the default python first > ># as distutils/setuptools modifies the shebang lines of scripts. > ># This ensures that #!/usr/bin/python is used and not pythonX.Y > > > > And, when I rebuild zhone from source, /usr/bin/zhone indeed ends up > > with the proper #!/usr/bin/python shebang. > > I hope you didn’t try the version -5 I just uploaded :-) > > Well, you need to ensure that the default python is run last, since the > last copy of the script is the one that gets installed. (At least that’s > my oberservation.) Bernd, did you get it backwards when writing the above code? Build order does not actually matter, but installation order does. At least in this case, the last python version to run the install overwrites the script from the other version, so default should be last. -- see shy jo signature.asc Description: Digital signature
Re: [pkg-fso-maint] Bug#547510: zhone refuse to start
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 right thing as it is now. > The last time we had such an issue it was due to the setup.py doing weird > things > (like creating the to-be-installed script on the fly). I didn't have the time > to > investigate in zhone, but I'm kinda sure its an issue with its setup.py. I can reproduce the same problem with winpdb if I comment out the rules file's inclusion of dpatch. The patching changes the mtime of winpdb.py, and that *somehow* causes setup.py to behave differently and in a way that dh_auto_install must accidentially depend on. -- see shy jo signature.asc Description: Digital signature
Re: Bug#548392: debhelper: python_distutils buildsystem and, setuptools entry_points don't use default python
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 versions of python are run is only loosely correlated to which version of the script is installed, and file timestamps are somehow involved. j...@gnu:~/tmp/winpdb-1.4.6>dh_auto_build >/dev/null 2>&1 j...@gnu:~/tmp/winpdb-1.4.6>touch build/scripts-2.4/* j...@gnu:~/tmp/winpdb-1.4.6>dh_auto_install >/dev/null 2>&1 j...@gnu:~/tmp/winpdb-1.4.6>head -1 debian/winpdb/usr/bin/winpdb #!/usr/bin/python2.4 j...@gnu:~/tmp/winpdb-1.4.6>touch build/scripts-2.5/* j...@gnu:~/tmp/winpdb-1.4.6>dh_auto_install >/dev/null 2>&1 j...@gnu:~/tmp/winpdb-1.4.6>head -1 debian/winpdb/usr/bin/winpdb #!/usr/bin/python j...@gnu:~/tmp/winpdb-1.4.6>touch build/scripts-2.4/* j...@gnu:~/tmp/winpdb-1.4.6>dh_auto_install >/dev/null 2>&1 hej...@gnu:~/tmp/winpdb-1.4.6>head -1 debian/winpdb/usr/bin/winpdb #!/usr/bin/python2.4 -- see shy jo signature.asc Description: Digital signature
Re: Bug#548392: debhelper: python_distutils buildsystem and, setuptools entry_points don't use default python
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 problem is, loosely speaking, that python is on crack. > > The order in which versions of python are run is only loosely correlated > to which version of the script is installed, and file timestamps are > somehow involved. More to the point: 1. With your test script, the last version of python to run wins. 2. Building zhone, the last version of python to run wins. 3. Building winpdb, the *first* version of python to run wins. 4. Unless winpdb is modified not to use dpatch. Then the last version of python to run wins. 5. *Or* unless the build machine is slow[1], or we just get unlucky[2]. Then, when building winpdb, the last version of python to run wins. In 4 and 5, as well as my examples with touch, we see that the install run order matters less than timestamps from the build run. I hypothesisze that setuptools is doing something like this to decide which script to install: - Is one of the build/scripts newer than the others? Install it. - Do all the build/scripts have the same timestamp? Install the first one, artitrarily. - Something to do with the timestamp of the original source file, too? -- see shy jo [1] Simulated by making debhelper sleep for 5 seconds after each call to setup.py. [2] Ie, I assume there is a race condition here; if the clock ticks at the right point during the build, the result will change. (Also probably filesystem dependent.) signature.asc Description: Digital signature
