Re: Debhelper 7, Python package, multiple binary packages
Ben Finney writes: > Ben Finney writes: > > > Once I learn how to make a ‘foo-dbg’ package, I can do that in the > > next release […] > > I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm > ending up with a source package that installs none of the Python files > into any of the binary packages. Going further today, I now have a ‘python-coverage’ package that: * uses Debhelper 7.x (as before) * uses python-support (as before) * is Debian source package format “3.0 (quilt)” * has multiple binary packages and it successfully builds the original (“normal”) binary package, ‘python-coverage’. However, in doing so, I've had to fall back on explicitly iterating Python versions and explicitly calling ‘setup.py install’, which partly defeats the purpose of using Debhelper 7 and python-support. This is frustrating, and I wonder if I'm missing some simpler way to do multiple binary Python packages with these tools. Also, while the ‘python-coverage’ binary package is now building correctly, the ‘python-coverage-dbg’ binary package contains nothing useful; it's as though there is no content for that package detected by the tools. Isn't that exactly why I'm using Debhelper >= 7.3.5 in the first place: to automatically handle the debug package based on ‘Build-Depends: python-all-dbg’? I would appreciate some feedback again at this point, I'm going cross-eyed trying to find what is wrong and someone else can probably see it much easier. I'm not uploading it to mentors because it's not in a fit state for release. The Debian packaging is in a Bazaar repository: $ bzr branch http://bzr.debian.org/bzr/collab-maint/python-coverage/python-coverage.debian/ You can use ‘uscan’ to get the upstream source (currently version 3.2). Thanks in advance to mentors spending time to help me. -- \ “An idea isn't responsible for the people who believe in it.” | `\ —Donald Robert Perry Marquis | _o__) | Ben Finney pgp1N8WeDkyCK.pgp Description: PGP signature
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 3:56 AM, Paul Wise wrote: > >> Trac 0.11 ships with jQuery 1.2.6 >> However, Debian patches remove this file in favor of libjs-jquery >> package which contains version 1.3.x >> This breaks plugins for Trac 0.11 that rely on 1.2.x jQuery features >> removed in 1.3.x >> >> How to properly add dependency for jQuery<1.3 to trac package? > > jquery 1.2 is only available in lenny, so depending on jQuery<1.3 > would make trac not installable in sid/squeeze (and thus an RC bug). > Talk to Trac upstream about removing the jQuery embedded code copy, > getting the plugins upgraded to jQuery 1.3 and making a new release. Upstream Trac is shipped with jQuery it needs while leaving Genshi and other libraries as dependencies. Debian specific patch removes jQuery from Trac distribution even though it contributes only 2% to package size. This dependency injection creates aforementioned problems. On Sat, Dec 26, 2009 at 7:37 AM, W. Martin Borgert wrote: > Which plugins exactly do not work with jQuery 1.3? There was a complex issue with TracDeveloperPlugin, which solution involved permissions, aliases and mod_wsgi configuration. The jQuery was only a part of a problem and it was not only downgrading that fixed it. There are more than 200 plugins tagged for 0.11 on http://trac-hacks.org/ They were developed and debugged with jQuery 1.2.x which is not forward compatible with 1.3.x I don't feel like I want to check if they are compatible next time I'd like to use one. 15kBytes doesn't worth wasted hours. > How much effort would it take to make them compatible with 1.3? > Note, that Trac 0.12 will ship with jQuery 1.3 anyway... > > In any case, I will document the potential problem in README.Debian > file, so that our users are not surprised (only disappointed maybe). The best solution would be to remove "15_remove_jquery_file.dpatch", "postinst", "prerm" and let Trac developers ship the version that contributes to the official API for Trac extension developers for a given Trac release. P.S. Given the above I'd reconsider "Python Application" concept from just "a big chunk of code" to isolated set of libraries/modules that creates stable virtualenv for an application, which is constructed using Python dependencies recommended by upstream. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 7:23 PM, anatoly techtonik wrote: > Upstream Trac is shipped with jQuery it needs while leaving Genshi and > other libraries as dependencies. Debian specific patch removes jQuery > from Trac distribution even though it contributes only 2% to package > size. This dependency injection creates aforementioned problems. The dependency exists whether or not trac has "Depends: libjs-jquery". Removing the "Depends: libjs-jquery" sounds like the equivalent of shipping a copy of GTK+ with gnome-terminal. Or a copy of ncurses with top. Or a copy of glibc with ls or cp. None of those things are nessecary, so why should shipping a copy of jQuery with one of the packages that use it be any different? In any case I don't think the security team would appreciate reopening one of the issues from their embedded-code-copies list: http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies It is already huge and scary enough as it is. I have a feeling it is probably quite incomplete too. > There was a complex issue with TracDeveloperPlugin, which solution > involved permissions, aliases and mod_wsgi configuration. The jQuery > was only a part of a problem and it was not only downgrading that > fixed it. > > There are more than 200 plugins tagged for 0.11 on > http://trac-hacks.org/ They were developed and debugged with jQuery > 1.2.x which is not forward compatible with 1.3.x I don't feel like I > want to check if they are compatible next time I'd like to use one. > 15kBytes doesn't worth wasted hours. It sounds like you're installing the trac plugins manually rather from Debian packages. I'd suggest manually installing jquery 1.2 for the manually installed plugins that need it and putting the javascript file at a different URL to the Debian jQuery 1.3 version. If there are any trac plugins in Debian sid/squeeze that need jQuery 1.2, I'd suggest filing RC bugs. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
Quoting "anatoly techtonik" : There are more than 200 plugins tagged for 0.11 on http://trac-hacks.org/ They were developed and debugged with jQuery 1.2.x which is not forward compatible with 1.3.x Most Trac plugins do not use JavaScript, even less use jQuery. I don't feel like I want to check if they are compatible next time I'd like to use one. 15kBytes doesn't worth wasted hours. The issue is not 15 kB, but the problems Debian would have if an error must be fixed in jQuery (e.g. a security problem). Currently, around 58 packages depend on jQuery. In theory, each of them must have their own copy. Trac does not even depend on jQuery, but only recommends it, because Trac itself does not need jQuery. The best solution would be to remove "15_remove_jquery_file.dpatch", "postinst", "prerm" and let Trac developers ship the version that contributes to the official API for Trac extension developers for a given Trac release. If it is really important to have jQuery 1.2 around, the best way would be to ask for a libjs-jquery-1.2 package and let Trac recommend this package instead of libjs-jquery. Anatoly, please file an ITP or RFP bug against the WNPP[1] pseudo-package about libjs-jquery-1.2, OK? Set the maintainer of libjs-jquery in Cc, maybe they will package 1.2 as well. I will change the dependencies in Trac etc. as soon as the package is in. [1] http://www.debian.org/devel/wnpp/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unit tests
Quoting "anatoly techtonik" : Even if most users don't need them, tests greatly increase the value of bugreports and doesn't bloat python packages too much. True. What do other people think of the issue? If unit tests were in the package, reportbug could automatically run them on a bug report. Does someone do this already, maybe? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unit tests
On Sat, 2009-26-12 at 17:13 +0100, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : > > Even if most users don't need them, tests greatly increase the value > > of bugreports and doesn't bloat python packages too much. > > True. What do other people think of the issue? They should only be in the source package. > > If unit tests were in the package, reportbug could automatically > run them on a bug report. Does someone do this already, maybe? Can reportbug be modified to download a source package and run tests ? > -- --gh -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python-Soya: About serious problems of soya when compiled with latest pyrex
OoO Lors de la soirée naissante du samedi 26 décembre 2009, vers 18:43, deavid disait : >>> Make me know if I could do anything to help maintaining this package >>> in Debian. >> >> I can offer comaintaine on this package if you wish. You will need to >> register yourself on alioth.debian.org. >> >> Thanks for your help! > I already have one: deavid-guest > https://alioth.debian.org/users/deavid-guest/ Hi! Could someone add David to PMPT? He will help me to maintain soya. Thanks! -- BOFH excuse #410: Electrical conduits in machine room are melting. pgpY42i3Zwt2G.pgp Description: PGP signature
Re: Unit tests
"W. Martin Borgert" writes: > Quoting "anatoly techtonik" : > > Even if most users don't need them, tests greatly increase the value > > of bugreports and doesn't bloat python packages too much. > > True. What do other people think of the issue? I think the judgement of “not bloat the package too much” is to be made with consideration of those users striving for a small system as their primary concern, e.g. those trying to install onto embedded systems with minimal storage. Also, the dependencies of a package that includes unit tests are generally greater; a significant amount of Python package unit test suites require additional packages, e.g. ‘python-nose’, that are not dependencies for the normal operation of the package. -- \ “Any intelligent fool can make things bigger and more complex… | `\It takes a touch of genius – and a lot of courage – to move in | _o__)the opposite direction.” —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
