Future of dh_python
Hello everybody, as you might have seen on Joey's blog, he expressed some wishes about the future of dh_python: http://kitenet.net/~joey/blog/entry/proposed_transition_plan_for_removal_of_dh_python_from_debhelper.html 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. dh_python would be modified to support only v1 mode (with a big deprecation warning) and would be no-op if debian/pycompat was 2 (including the implicit pycompat=2 set if the XS-Python-Version header is here). 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.) As I volunteer(ed) to maintain this part of the code (dependency generation for dh_py*), I suggest to start using the pkg-python project (and its associated SVN repository, or whatever VCS suits you best, Matthias) so that I can directly maintain this part of the code in the package. If you don't have time for the initial import and all, just let me know, I can add myself to the project and setup things for you. Now replying to the problems Joey expects: > dh_pthon supports params for passing additional module directories. > dh_pysupport does too, but it seems that dh_pycentral does not. Need to > check if this means that noone using dh_pycentral can use it with > non-standard directories, so none of them pass directories to dh_python. dh_pycentral scans all the directories by itself so it shouldn't be a problem for byte-compilation. For the dependency generation, we need to be able to know that a .so is a Python extension module and not something else and so we rely on this parameter to know that any .so in the directory is effectively a python extension module. I heard that python-support implemented something else (with objdump) to assert that a .so is a python package. In any case, it would be no problem to add the same parameter to dh_pycentral or to improve the way we detect the python extension module. > dh_python has -V and -X flags that affect its behavior and the other two > programs would not have access to this information. > * I doubt that -X is used widely. Grep. >* -V is a redundant interface, since it does something approximating >what debian/pyversons does. So things should be able to switch to the >other interface, except in edge cases (although IMHO it's not an >appropriate interface for a debhelper program), and for the edge >cases, -V could be added to the other two programs. Exactly, we should get rid of the "-V" parameter completely. -X support has been added during my NMU as it was a wishlist that I found useful (so -X isn't widely used). > It's possible that someone might set dh_python's -n flag but not also > set it on their call to dh_pycentral or dh_pysupport. Can't imagine why > though. I don't see any reason either. No worry here. > 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. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future of dh_python
Hi, On Tue, 22 Aug 2006, Floris Bruynooghe wrote: > > The changes needed in dh_pysupport are trivial. As of version 0.4, it > > handles dependencies in more cases than dh_python, and does it only if > > debian/pycompat isn't found. The only thing to do is to remove this > > check. > > > > I also heard that python-central has some code for dependency > > generation. Depending on how advanced it is, this library won't be > > needed at all. Matthias, what's your opinion on this topic? > Hrm, I can't help but think that one common code base for dependency > generation is better (if it can be agreed upon). It means more > consistency over time when things get changed and also has the obvious > benefit of being tested better, not all bugs will be duplicated etc. Indeed. That's why I suggested it. And it would be sad to see all my efforts with dh_python go away as the sole purpose of the new dh_python was to assure that consistency. The code would be a little simplified as there's no need to support the "old policy" in that library. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SVN access for Urwid, Templayer
Hi, On Wed, 23 Aug 2006, Ian Ward wrote: > I am hoping to get svn access to python-modules so that I can help to > maintain the Urwid and Templayer packages. My Alioth account is > wardi-guest. You have been added to the project. You'll have access tomorrow. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Hi,
On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
> AIUI debian/pycompat is not needed anymore currently as dh_python has
> enough by having the XS-Python-Version field, while if you are using
> python-support dh_python is not used at all anymore so it doesn't need
> the debian/pycompat anymore either.
>
> Please correct me if I'm wrong. Also the wiki needs updating to
> reflect this, so if no one corrects me I will do that (unless someone
> beats me to it).
You're right. However there's no point in changing that now, until we have
a proper plan to get rid of dh_python completely and replacing it with
another common infrastructure to generate the ${python:*} substitutions.
I tried to propose one but Matthias Klose didn't respond at all and
Josselin Mouette hasn't given his approval for such a common
infrastructure (even if he agreed on the principle the day when he agreed
to keep dh_python as common thing).
See: http://lists.debian.org/debian-python/2006/08/msg00091.html
> Also, fairly unrelated, since pyversions is part of the python package
> should we build-depend on python? I found somewhere that
> build-depending on python-all-dev (>= 2.3.5-11) is sufficient to pull
> in pyversions, is that really the appropriate way though? I would
> prefer to list python directly as dependency instead of indirect.
If you really need python-all-dev, then it's enough, indeed. If you still
want to list explicitely it doesn't hurt.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
On Fri, 25 Aug 2006, Pierre Habouzit wrote: > debian/pycompat is needed if you want dh_python to do the substitution. > You also can (atm) use dh_pysupport do it alone, in that case you must > not use debian/pycompat, neither dh_python. If someone really wants to use dh_pysupport to generate the dependencies, it would be better with an expliciti "-d" option instead of relying on the absence of a file. The interface is clearer for everybody until we have again decided the proper way of handling everything without dh_python. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Mon, 28 Aug 2006, Adeodato Simó wrote: > * Brian May [Mon, 28 Aug 2006 13:22:55 +1000]: > > > Adeodate> Also, do you remember having root > > Adeodato> bzr as root? > > > Huh? > > Sorry, that should have read: "do you remember having *run* bzr as root". > It's the most likely cause for those .pyc files to be there, since > bzrtools did not. What helper tool did you to use to byte-compules modules before python-support? (dh_python v1, python-central, nothing) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385909: pyversions: command not found
On Sun, 03 Sep 2006, Steve Langasek wrote:
> On Sun, Sep 03, 2006 at 11:38:19PM +0200, Julien Danjou wrote:
> > Suggested packages:
> > python-doc python-profiler
> > The following NEW packages will be installed:
> > python-minimal
> > The following packages will be upgraded:
> > python
> > 1 upgraded, 1 newly installed, 0 to remove and 212 not upgraded.
> > 221 not fully installed or removed.
> > Need to get 0B/152kB of archives.
> > After unpacking 119kB of additional disk space will be used.
> > (Reading database ... 142617 files and directories currently installed.)
> > Preparing to replace python 2.3.5-5 (using .../python_2.4.3-11_all.deb)
> > running python pre-rtupdate hooks for python2.4...
> > /usr/share/python/runtime.d/python-gnome2.rtupdate: line 4: pyversions:
> > command not found
>
> Whoops, apparently there's a whole in python policy, packages which use
> pyversions (which is pretty much anything doing bytecompiling, right?) need
> a dependency on python (>= 2.3.5-6)...
Pyversions is mainly used at build-time and not at installation time.
Whatever requires pyversions (and in this case python-gnome2) should be
depending on the first version of python that provides it (and now the
good question: how do you do that while still using ${python:Depends}?).
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385909: pyversions: command not found
On Mon, 04 Sep 2006, Steve Langasek wrote:
> > Pyversions is mainly used at build-time and not at installation time.
> > Whatever requires pyversions (and in this case python-gnome2) should be
> > depending on the first version of python that provides it (and now the
> > good question: how do you do that while still using ${python:Depends}?).
>
> By depending on python (>= 2.3.5-6), ${python:Depends}, which will duplicate
> a dependency but still work?
Yes and generate an annoying lintian warning. :)
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: quest to join pmpt
On Wed, 20 Sep 2006, Kevin Coyner wrote: > Hello > > I'd like to join the python-modules packaging team. > > I've just sent out a RFS for the package 'rls' and also already > maintain 'htmlgen', both python packages. I also have another > python related package in the pipeline. I looked at rpl and it's a simple python application without any public module. This is not a "Python Module" and thus I don't believe that it has its place here. Are the packages above diferrent in that point of view? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381389: dh_pycentral patch
Context for debian-python: we're deprecating dh_python on Joey's request and thus move the logic of substvars generation into dh_pycentral/dh_pysupport. debhelper/python-central/python-support will be jointly uploaded in 2 days (the packages are in DELAYED/2-days right now) to make that happen. We need to make sure that we didn't break anything by doing so. On Tue, 03 Oct 2006, Joey Hess wrote: > Ok, done in a new version of debhelper I've uploaded to the 3-day > delayed queue. Only 3 days left to sort everything out.. I prepared an updated of python-central which integrates the dh_python code into dh_pycentral. It's here: http://people.debian.org/~hertzog/packages/python-central.patch http://people.debian.org/~hertzog/packages/python-central_0.5.6.dsc Doko has more changes for python-central, he will merge my changes and upload the final package into DELAYED/2-day. Now it's time to test the combination. Someone should install the three packages: http://people.debian.org/~hertzog/packages/python-central_0.5.6_all.deb http://people.debian.org/~hertzog/packages/debhelper_5.0.39_all.deb http://people.debian.org/~hertzog/packages/python-support_0.5.3_all.deb (I had to use dpkg --force-conflicts -i *.deb, giving dpkg -iGROEB *.deb didn't work) And then recompile many python packages using python-support/python-central and watch out differences (in the generated dependencies in particular). Some help is welcome. My first tests with dh_pycentral are good but I only checked 2 packages. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing python2.3
On Mon, 23 Oct 2006, Matthias Klose wrote: > With zope2.8 removed, the last package depending on python2.3 is gone, > so we are technically able to drop the support for python2.3. As > currently some packages have reverse dependencies on python2.3, > removing python2.3 without any other action, would open new RC reports > which doesn't seem to be appropriate at this point. The following > issues should be fixed before: Breaking packages is not the right course of action. However filing bugs at RC level is probably required if we want to have a quick reaction from the maintainers. > 1) removing packages only needed for python2.3: > > python-fixedpoint (replaced by decimal) > python-cjkcodecs > python-iconvcodecs (maybe) > decompyle (2.3 only) Contact the maintainer and file removal request on ftp.debian.org ? > 3) removing the rdepends from packages (likely to be packages using >the versioned interpreter name) Someone should go through the list and upgrade any python-policy bug or file a new serious bug asking to update for python2.4. > - rebuild extension packages to drop 2.3 extensions. This is not absolutely required. It clutters some packages a bit but doesn't break anything. Providing python2.5 support would have been nicer than only removing python2.3 support... Anyone tried to build all python extensions with python2.5 ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-numeric: Fails to build 2.3 version
Hi, On Thu, 30 Nov 2006, Daniel Schepler wrote: > > This is the normal behaviour of the package since in sid python2.3 is no > > more marked as supported in /usr/share/python/debian_defaults ... > > It seems to me that it's a bad idea to make this change in sid while the old > python packages are frozen in etch. The result will be: if anybody uploads > updated versions of their python packages, they will get autobuilt against > the sid packages and thus have no 2.3 contact, which is out of sync with what > would happen with people wanting to hand-build their packages locally using > etch. And how is this a problem ? It's not technical problem... it's at most a problem of consistency in the packages built, some will provide support for 2.3 and 2.4 while other will only support 2.4. I'm not the one who decided it, it's Matthias who manages solely the python packages (despite my numerous attemps to push collaborative maintenance on those packages). Given that the new python-defaults has been there for a full month already, it's a bit late to revert this change (although it should be easy since all affected packages should be bin-NMUable). > I think you should decide whether you want python2.3 to be supported in etch > or not. If you do, you should revert the changes in sid until after the etch > release; if you don't, you need to ask the release team to let the new python > packages into etch despite the freeze of "base toolchain" packages, and also > prepare a list of appropriate binNMU's needed to sync up the packages in sid > with this change. Matthias's goal has always been to get rid of python2.3 completely. It's likely doable. And I discussed on #debian-release their move to etch, it will likely happen soon (after my recent NMUs which fixed some issues related to that change). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Outdated Python-related packages in Debian
Hello, On Wed, 06 Dec 2006, Sanghyeon Seo wrote: > My crystal ball, eh, my package tracker told me, that there are many > outdated Python-related packages in Debian. I filtered false > positives. (e.g. version parsing got it wrong, version packaged in > Gentoo/FreeBSD is alpha/beta, etc.) > > http://sparcs.kaist.ac.kr/~tinuviel/package/list.cgi?name=python&version=1 > > aap, asciidoc, python-logilab-astng, python-beautifulsoup, bzr, > python-cairo, cfv, zope-coreblog, zope-coreblog2, python-dnspython, > python-forgethtml, python-formencode, python-gd, gnochm, > python-irclib, python-japanese-codecs, python-kinterbasdb, lphoto, > python-matplotlib, meld, python-moinmoin, python-omniorb, python-osd, > python-paramiko, python-psyco, python-chm, pylint, python-pyparsing, > python-pyvorbis, quodlibet, roundup, python-scgi, python-scientific, > python-simplejson, python-soappy, spe, python-sqlrelay, tmda, viewcvs, > python-visual, python-wxgtk2.6, python-xlib, zwiki. > > People on this list may want to get/help these packages updated. If anyone updates some of theses packages, please invite the maintainers to join the "Debian Python Modules Team". http://python-modules.alioth.debian.org I'd gladly add them to the project. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Outdated Python-related packages in Debian
Hello, On Fri, 08 Dec 2006, Mikhail Gusarov wrote: > RH> If anyone updates some of theses packages, please invite the maintainers > RH> to join the "Debian Python Modules Team". > RH> http://python-modules.alioth.debian.org > > Please add me. My python-openid, python-yadis and python-urljr are > sitting in NEW right now. Alioth login is 'dottedmag-guest'. Done. Welcome to the group! Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining PMPT
Hi, On Fri, 12 Jan 2007, Oleksandr Moskalenko wrote: > I'd like to join the PMPT. My alioth login is "malex". > > Python-related packages that I maintain include beaker, myghty, myghtyutils, > pydb, pylons, quixote, and webhelpers. You have been added. Welcome to the group! We really need some more DD who could help sponsoring, for example Ian Ward seems to have trouble finding sponsors for his urwid package. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining PMPT
Hi, On Sat, 13 Jan 2007, Thomas Viehmann wrote: > Raphael Hertzog wrote: > > We really need some more DD who could help sponsoring, for example Ian > > Ward seems to have trouble finding sponsors for his urwid package. > It seems somebody else picked up urwid. > > I'm not sure I'll be able to this on a regular basis, but sponsoring an > occasional update should be possible. I'm afraid I'll only take new > packages if I have a particular interest. Is there a place where people > look for that? It's either here or on IRC #debian-python. I try to redirect people here when they look for a sponsor. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two small python modules
Hi, On Tue, 27 Feb 2007, Romain Beauxis wrote: > Hi all ! > > I have packaged yesterday two small python modules for interfacing with > memcached. This was required by a colleague on one of our project. > > One is a pur python project and the other one a binding for the C library, > said to be faster. > > I don't know if my packaging was done properly, but I'd like to have your > advice on what I should do with these packages, upload them or not to > debian, and if they should be maintained under the team or with me alone as > the maintainer.. My general advice is to put your name on the Maintainer field and take responsibility for the package but put the team in the Uploaders so that it's clear that anyone from the team can come and help improve/fix those packages if needed. Also you should manage the package within the subversion repository of the team. I can add you to the team if that's your final decision. Just ask. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging for Cheeseshop and Debian
Hi, On Wed, 14 Mar 2007, Ben Finney wrote: > Howdy all, > > I'm writing an application[0] in Python, and am nearly at the point > where I want to package it. I need to do so in a way that's useful to > me, so that means a Debian package; and useful to anyone using Python, > so that means a Python egg available in the Cheeseshop. > > I have some idea about doing each of those, but no real clues about > packaging for both Python's Cheeseshop and a Debian package > simultaneously. Where should I start learning about the issues and > recommendations? http://wiki.debian.org/DebianPythonFAQ Check the part concerning eegs. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PMPT / Alioth
Hi, On Wed, 14 Mar 2007, Tristan Seligmann wrote: > I'd like to be added to the PMPT project on Alioth; my account name is > mithrandi-guest. I'll probably be comaintaning various Divmod packages > with Stefano Zacchiroli. You have been added. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging for Cheeseshop and Debian
Hi, On Thu, 15 Mar 2007, Ben Finney wrote: > > Check the part concerning eegs. > > The page says: > > Adding "egg support" is only required in some specific cases: when > another software uses the python module via an egg and when this > egg support is not yet integrated upstream." > > What is meant by "this egg support is not yet integrated upstream"? You have two ways to install python modules: - the traditional distutils - the eggs-powered setuptools > Does this refer to the "upstream" of the package which depends, or the > packages upon which it depends, or both? The latter. A module that uses "eggs" to load another module is certainly egg-ready itself. However if the dependency isn't egg-ready, then the package expecting an egg of its dependency will be broken unless we add the egg support to its dependency. > What would need to be done upstream for this criterion to change? Switch from distutils to setuptools as shown with the example patch. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging for Cheeseshop and Debian
On Thu, 15 Mar 2007, Josselin Mouette wrote: > Le mercredi 14 mars 2007 à 09:48 +0100, Raphael Hertzog a écrit : > > > I have some idea about doing each of those, but no real clues about > > > packaging for both Python's Cheeseshop and a Debian package > > > simultaneously. Where should I start learning about the issues and > > > recommendations? > > > > http://wiki.debian.org/DebianPythonFAQ > > > > Check the part concerning eegs. > > Wow, just another place with completely outdated (to the point I don't > think it has ever been accurate) documentation about python packaging, > especially python-support. The egg part is still OK, but indeed the rest was rather outdated. Thanks for fixing it (even if it looks like empty now :-)). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
On Mon, 19 Mar 2007, Ben Finney wrote: > Searching for information about this, I've seen references to > 'packagename.substvars' that should be created during package > building. What is it that should be creating these? A missing 'dh_foo' > command? dh_pycentral should do it for you... what's the content of the package ? If it uses private modules, you should indicate the directory where they are stored as parameter to dh_pycentral. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
Hi, On Tue, 20 Mar 2007, Ben Finney wrote: > Raphael Hertzog <[EMAIL PROTECTED]> writes: > > > On Mon, 19 Mar 2007, Ben Finney wrote: > > > [dpkg-gencontrol complains about unknown substitution variables] > > > > dh_pycentral should do it for you... > > I am using dh_pycentral (as noted in my original message). > > Or do you mean that, since I'm using dh_pycentral, I should not use > dh_gencontrol? No I didn't mean that, I just told that dh_pycentral is supposed to create the substvar for you but since it doesn't I need you to answer this question: > > what's the content of the package ? Because the substvar are generated based on what python scripts and python modules are found and where they are located... try running the build with DH_VERBOSE=1 to have more info about what dh_pycentral finds. Otherwise please put up the package online somewhere so that we can check what's wrong... > > If it uses private modules, you should indicate the directory where > > they are stored as parameter to dh_pycentral. > > What are "private modules"? I've never heard that term used in Python. Python modules (or extensions) installed in a non-public/standard directory. Check http://wiki.debian.org/DebianPython/NewPolicy Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
On Tue, 20 Mar 2007, Ben Finney wrote: > > > and 'dpkg-gencontrol' complained about every one of those. > > > > This is a misfeature of dpkg-gencontrol. > > Is 'dh_gencontrol' not useful then? If not, why is it in the > boilerplate created by 'dh_make'? If it is useful, what am I doing > differently that it triggering its misfeatures? Please read man dh_gencontrol... of course that it's still required. A debian package without a control file is not a Debian package. dpkg-gencontrol spits outs useless warnings but the work done is still essential to the creation of a Debian package. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
On Tue, 20 Mar 2007, Ben Finney wrote:
> > > > what's the content of the package ?
>
> Pure Python modules, which should be installed to the system
> site-packages for use by the application.
No the package doesn't contain that, only those files:
drwxr-xr-x root/root 0 2007-03-19 23:31 ./
drwxr-xr-x root/root 0 2007-03-19 23:31 ./usr/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./usr/bin/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./usr/sbin/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./usr/share/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./usr/share/doc/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./usr/share/doc/gracie/
-rw-r--r-- root/root 1152 2007-03-19 23:27 ./usr/share/doc/gracie/copyright
-rw-r--r-- root/root 157 2007-03-19 23:27
./usr/share/doc/gracie/changelog.Debian.gz
drwxr-xr-x root/root 0 2007-03-19 23:31 ./var/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./var/lib/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./var/lib/gracie/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./etc/
drwxr-xr-x root/root 0 2007-03-19 23:31 ./etc/default/
-rw-r--r-- root/root 232 2007-03-19 23:27 ./etc/default/gracie
drwxr-xr-x root/root 0 2007-03-19 23:31 ./etc/init.d/
-rwxr-xr-x root/root 1474 2007-03-19 23:27 ./etc/init.d/gracie
drwxr-xr-x root/root 0 2007-03-19 23:31 ./etc/pam.d/
-rw-r--r-- root/root 181 2007-03-19 23:27 ./etc/pam.d/gracie
That's because you're calling "dh_clean -k" which removes what has been
installed...
Here's a minimal diff of changes:
=== modified file 'debian/control'
--- debian/control 2007-03-19 06:22:59 +
+++ debian/control 2007-03-19 22:29:46 +
@@ -2,7 +2,7 @@
Section: web
Priority: extra
Maintainer: Ben Finney <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 5.0.38),
+Build-Depends: debhelper (>= 5.0.38), docbook-to-man,
python-all-dev (>= 2.3.5-11),
python-central (>= 0.5.6),
python-setuptools (>= 0.6b3-1)
=== modified file 'debian/rules'
--- debian/rules2007-03-19 06:44:04 +
+++ debian/rules2007-03-19 22:37:56 +
@@ -46,7 +46,6 @@
install: build ${PYVERS:%=install-python%}
dh_testdir
dh_testroot
- dh_clean -k
dh_installdirs
dh_installinit
dh_installpam
But there's more to clean in that package. It's arch: all and should not
be built with all python versions like you're doing. Thus there's no need
to build-depend on python-all-dev but only python-dev, etc.
There's a bashishm in debian/rules:
mv
debian/${PACKAGE_NAME}/usr/lib/python$*/site-packages/${MODULE_NAME}{-${DEB_UPSTREAM_VERSION}-py$*,}.egg-info
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
On Tue, 20 Mar 2007, Josselin Mouette wrote:
> Le lundi 19 mars 2007 à 23:44 +0100, Raphael Hertzog a écrit :
> > === modified file 'debian/rules'
> > --- debian/rules2007-03-19 06:44:04 +
> > +++ debian/rules2007-03-19 22:37:56 +
> > @@ -46,7 +46,6 @@
> > install: build ${PYVERS:%=install-python%}
> > dh_testdir
> > dh_testroot
> > - dh_clean -k
> > dh_installdirs
> > dh_installinit
> > dh_installpam
>
> Nope, dh_clean -k is fine. It's just that installation should start
> after calling it, not in the build target.
Installation currently happens in "install-pythonX.Y" which is called before the
"install" target since it's a dependency. Thus dh_clean -k removes what's
installed.
Since the package is "arch: all" the python setup.py call should simply be
placed in the install target and the targets install-pythonX.Y should be
removed.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using python-central for pure-Python package (was: dpkg-gencontrol: warning: unknown substitution variable ${python:Depends})
On Tue, 20 Mar 2007, Ben Finney wrote:
> Part of that target is to rename the generated egg-info directory;
> Setuptools creates it as 'foo-N.M-pyX.Y.egg-info', but the
> python-central documentation seems to indicate this should be renamed
> to 'foo.egg-info':
>
> # install only one Egg dir (without python's version number)
> mv
> debian/${PACKAGE_NAME}/usr/lib/python$*/site-packages/${MODULE_NAME}-${DEB_UPSTREAM_VERSION}-py$*.egg-info
> \
>
> debian/${PACKAGE_NAME}/usr/lib/python$*/site-packages/${MODULE_NAME}.egg-info
>
> How can this be done properly without knowing the exact name
> (including Python version) that Setuptools will create?
Move that to the install target as well and replace "$*" with the version
of the current python (`pyversions -dv`).
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream Makefile, debian/rules, eggs, building and installing
On Wed, 21 Mar 2007, Ben Finney wrote: > How should the Debian packaging files interact with this? Examples > I've seen for using python-central have the egg being built in the > Debian-specific debian/rules targets, but this is clearly duplication > if the upstream Makefile already builds an egg. Please be specific... tell us which examples you are referring to. We can't discuss in general when you might refer to an exception and when you might have misunderstood what you've read. > In normal (non-Debian) usage of Setuptools, a user will generate an > egg that is specific to a Python version, and install that; this isn't > what's needed by python-central, though. But surely the answer isn't > essentially duplication of the build-an-egg step between the upstream > Makefile and debian/rules ? We're using a feature of setuptools to provide eggs as unpacked directory trees instead of a single archive. This doesn't duplicate anything and it doesn't mean that we build eggs manually. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream Makefile, debian/rules, eggs, building and installing
On Wed, 21 Mar 2007, Raphael Hertzog wrote: > On Wed, 21 Mar 2007, Ben Finney wrote: > > How should the Debian packaging files interact with this? Examples > > I've seen for using python-central have the egg being built in the > > Debian-specific debian/rules targets, but this is clearly duplication > > if the upstream Makefile already builds an egg. > > Please be specific... tell us which examples you are referring to. We > can't discuss in general when you might refer to an exception and when you > might have misunderstood what you've read. BTW, applicable examples for your case: $ grep-available -F Depends 'python-central' -a -F Architecture 'all' -s Package Package: python-sqlobject Package: bzr Package: python-pexpect Package: python-serial Package: reportbug Package: python-optcomplete Package: python-setuptools Package: python-formencode (bzr and reportbug are applications mainly and not modules, they're not good examples for you) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: joining the python modules packaging team
Hello, On Thu, 05 Apr 2007, Michel Casabona wrote: > Hello, > > I'd like to join the team to maintain the python-hachoir packages that I > build, > which will be soon uploaded to debian (thanks a lot to Piotr Ożarowski), > and help maintaining other packages if possible. You have been added. Welcome to the group! Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Full checkout with svn:externals
On Sun, 24 Jun 2007, Bernd Zeimetz wrote: > that would mean I'd have to checkout all modules, I wanted to avoid > that. BTW, I discovered that there might be a way to checkout everything out of trunk without extracting tags and branches. The idea would be to have a directory all-packages with the property "svn:externals" listing all the trunk of all packages: http://svnbook.red-bean.com/en/1.0/ch07s03.html Might be worth considering... and documenting so that people add the new packages there as well. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Making all DD members of the team by default
Hello, this mail is crossposted to two mailing lists. Please reply only to the one that concerns you (perl or python team). The collab-maint project gives write access to all DD by default using ACL (see man setfacl and getfacl). $ getfacl /svn/collab-maint/ [...] group:Debian:rwx [...] default:group:Debian:rwx I believe the perl and python team would benefit from using similar ACL so that any DD who wishes to integrate his packages in the team can do so without requesting access that we'll grant him anyway. We expect DD to be educated and to ask before messing up if they're not sure of what they're doing. In most cases, they'll figure it by themselves because the available documentation hopefully directed them correctly. :-) This also let NMUer integrate their NMU in the VCS directly if they so wish. As an Alioth admin, I can add those ACL. However I'd like to have your opinion and agreement first. Cheers, PS: If you know other teams that would be interested, feel free to suggest them and direct them to alioth admins ([EMAIL PROTECTED]) to get the ACL added. -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging django-openid ? and django dev release in experimental ?
Hello Brett, I was looking for some OpenID support in Django and found out http://code.google.com/p/django-openid/ Would you be interested in packaging this ? Also, given the long time between two stable releases of Django it might be worth packaging development release in experimental. What do you think ? Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making all DD members of the team by default
On Thu, 26 Jul 2007, Raphael Hertzog wrote: > Hello, > > this mail is crossposted to two mailing lists. Please reply only to the one > that concerns you (perl or python team). This warning is still valid. :-) > As an Alioth admin, I can add those ACL. However I'd like to have your > opinion and agreement first. Both projects agreed and I just added the ACL. It would be great if some people could update the respective documentation of each project to share this information. It has been noted that when a DD gets highly involved in the team, he should nevertheless be added to the Alioth project. Non-DD who are looking for sponsors can then better identify them and that way we keep a list of "core-members". We'll also publicize this change in debian-devel-announce later (either in a Bits of Alioth or in a more generic mail, we'll see). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python Egg Guidelines across distros
Hi, On Tue, 04 Sep 2007, Toshio Kuratomi wrote: > I'm revising the Fedora Python Guidelines to make better use of eggs and > saw an interesting bug report against python-docutils that left me > wondering how Debian had dealt with some of the decisions that I'm > having to make. If we come out with similar conclusions, that will be > one less difference for end users to have to worry about between > distros. If we come to different conclusions, at least we'll know what > to tell users when they ask why things don't work the way they do in > that other distro :-) Thanks for the initiative, it's much appreciated! We don't have a 100% clear policy, the general rule has been that we don't provide .egg files but we provided the egg meta-informations along with the usual modules when upstream uses setuptools by default. In some cases, when other modules requires an egg for a module which is not using setuptools by default, we apply a patch to use setuptools. See http://wiki.debian.org/DebianPythonFAQ However I noticed lately that egg-info are systematically generated even with distutils based modules and in fact we have /usr/lib/python2.4/distutils/command/install_egg_info.py provided by python2.4. I don't know when the change happened and can't find any note on python's Changelog... Matthias? So in practice we always provide egg-info but this change has not been discussed here. That said I don't see a compelling reason to refuse it. > 2) We're deciding how we want to make packages when we want to have > multiple versions of a module. For instance cherrypy is on release > 3.0.2 but the TurboGears framework requires a 2.2.x version. So we need > to provide both versions to our users. I've been drafting guidelines > for doing this using eggs[1]_ but some recent discussions with Phillip > Eby[2]_, setuptools author are proving there are some difficulties to > doing this. Have you guys considered doing anything like this? Again, no general discussion happened on this topic but the cherrypy maintainer packaged both versions and made them conflict (i.e. they are not co-installable). So we report the problem back to the user who wants to use two version of the product at the same time. :-) http://packages.debian.org/sid/python-cherrypy http://packages.debian.org/sid/python-cherrypy3 $ apt-cache show python-cherrypy3 | grep Conflicts Conflicts: python2.3-cherrypy, python2.4-cherrypy, python-cherrypy > These are my current goals for multiple versions: > 1) import MODULE should import whatever the vendor decided should be the > default. > 2) requires.txt in a project's egginfo should work to select a specific > version from the installed eggs. > 3) In a simple script (without requires.txt), > should work to select a specific version from the installed eggs. I think you're more advanced than us on this topic and we didn't not have any plans to try to use setuptools to achieve this. The python packaging is already complicated enough that we'd like to avoid having to resort to such things. And in general, the Debian packagers don't like Eggs as they replace (badly) the functionnalities of our package manager. So we avoid promoting them and are not keen to use them to solve new problems that shouldn't exist in the first place. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maintainer field
On Thu, 06 Sep 2007, Steve Langasek wrote: > > > So I myself chose to be among Uploaders and set Maintainer to DPMT, > > > because this more enforces team work and I like team work. > > > I had a discussion on #debian-devel about this, and "they" thought it > > was pretty stupid to have DPMT as uploader, as it would make every > > package NMU. > > No, what was said was that it was meaningless to list a mailing list in the > Uploaders field because a mailing list can never do an upload and therefore > it misses the /point/ of the Uploaders field. The only (good) reason of listing the mailing list in the Uploaders field is to have the package in the group's QA page: http://qa.debian.org/[EMAIL PROTECTED] Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python modules not installed correctly with pycentral
On Tue, 08 Jan 2008, Vincent Bernat wrote: > > What should I be doing about this? > > Isuppose thatalintian overrideworks too.Create > debian/source.lintian-overrides with: > yourpackage source: package-lacks-versioned-build-depends-on-debhelper 6 debhelper 6 has been uploaded to unstable a few hours ago. So you can start depending on it. Adding overrides for situations that are known to be transient is not a good idea in general. It's best to keep the lintian warning so that it reminds you to update the build-depends once the updated packages is available. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternative for python
On Thu, 10 Jan 2008, Yaroslav Halchenko wrote: > I know that some packages might not yet ship extensions built for 2.5, > but still, since lenny is targetting python >= 2.5, and unstable is > unstable, why don't we allow users to experiment a bit and change > default python on their systems to python2.5? (yeah yeah -- they could > probably simply ln -sf python2.5 /usr/bin/python, but that is not the > point, since alternatives are there to provide such facility) Because if we allow that, then we must be able to support such changes. And we don't. If you want to experiment, overwrite temporarily the symlink. If we let people change the symlink, and if it breaks, then it's a bug in our packaging and we have to fix it. And it's far easier to package everything while knowing that python is a a single python version (identified by the corresponding python package). > In any case -- I just wanted to raise a concern and may be some > discussion -- may be I should simply a wishlist bug against python? No. The situation is fine as is. No need to introduce more complexity. I pushed for such a change in perl a long time ago, and we're back to a single perl version... let's not reiterate the mistake for python. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
On Mon, 14 Apr 2008, Adeodato Simó wrote:
> Finally, and quite importantly, there is what to do with modules that
> have been added to the standard library in 2.5 (ctypes, celementtree,
> wgsiref). These use either pycentral or pysupport, and since they mark
> themselves as for python << 2.5 only, the dependency generated is on
> python (<< 2.5), rendering them uninstallable.
I think they should simply be updated to not use ${python:Depends}.
I wonder if that should be replaced by some custom dependency however.
Probably not. There's no reason to depend on python-2.4... that's the
job of packages containing python scripts requiring 2.4.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
On Tue, 15 Apr 2008, Adeodato Simó wrote: > * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]: > > The solution is really simple, just add them to python’s Provides: list. > > Plus, uhm, can't really be done for (c)elementtree, since python 2.5 > provides the modules under a different name/namespace. ?! In that case it might be a good idea to build python-celementtree for python 2.5 as well... I haven't heard of technical incompatibility but just that it was bundled with python 2.5 and thus unneeded/in conflict. But if the namespace is different, there's no file conflict and I don't understand why we cared about not generating the module for python 2.5. > python-pysqlite2, on the other hand/for example, still provides the > modules for python 2.5 under the old name. elementtree could do this, > or else the packages should be somehow checked, I guess? Indeed. (I should read mails entirely before replying :)) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Migration of Alioth account
Hi, On Fri, 18 Apr 2008, Vincent Bernat wrote: > Could someone with appropriate rights remove my account bernat-guest and > add bernat instead? Already done by Piotr apparently. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unexpected Depends: both python-central and python-support
On Mon, 16 Jun 2008, Ben Finney wrote: > What's causing this, and how can I fix it so it doesn't have this > unexpected extra dependency? It's because dh (from debhelper 7) will use dh_pysupport by default if it's available. Just use what debhelper uses by default or make sure to skip that script by using appropriate dh --before pysupport and dh --after pysupport invocation to skip dh_pysupport (until Joey decides to implement a --skip option in debhelper at least). Check the output of "dh binary-arch --no-act" to verify it by yourself. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500391: ITP: python-django-debug-toolbar -- Embedded debugging toolbar for Django projects
On Sun, 28 Sep 2008, Chris Lamb wrote: > Raphael Hertzog wrote: > > > Do you plan to maintain the various Django related packages in the > > python-modules team ? > > I'm open to persuasion on this, otherwise no. Well, I'm maintaining like you several Django related packages (python-django itself, python-django-registration, python-django-tagging) and it would be nice if we could co-maintain all those packages in the same repository. Currently this repository is python-modules's SVN repo. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: numpy 1.2.1, switching to git?
On Tue, 23 Dec 2008, Ondrej Certik wrote: > I am surprised I am actually the 6th most active. Pretty cool. :) I am surprised to still be in the top 10 (hertzog)… it means the team is not so active as one would expect. :-) Anyway, I'm fine with git as well but I'm not convinced it's that important. You should also look at the perl team, they are using git on some packages only and have not yet decided to mass-convert from SVN to Git. One of the reasons of the block is that Git makes it difficult to do operations on all the repositories. And for a global update, you're forced to use tools like "mr" (and even that won't add new package automatically). Furthermore, Git alone doesn't mean much, the questions is whether we have to use git-buildpackage, topgit and so on. Hence I would rather suggest a per-package decision for the switch. I won't cry if SVN continues to be used. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517308: python-syck: lacks a python-support dependency
Package: python-syck Version: 0.61.2-1 Severity: serious The package uses python-support but does not depend on it. The dependency should be auto-generated in a substvar, you just have to add the proper substvar. Note: the package is unmaintained, someone from the python team should probably take it over. It is currently a dependency of dak and thus it would be nice to have it properly maintained. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Quick analysis of the Python dist-packages transition
On Fri, 18 Sep 2009, Josselin Mouette wrote: > If there are no objections, I will submit a MBF for those 75 packages in > a few days. Go ahead, we have waited too much for python 2.6 already. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ${python:Breaks}
On Thu, 10 Mar 2011, Piotr Ożarowski wrote: > seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹, > we don't have to worry about 2.X transitions when 2.7 will become the > only supported one. If you don't like Breaks, I will remove it, it > really doesn't matter - that's why at the beginning I wasn't generating > either of these dependencies (in Depends and in Breaks). Well, if upstream changes their plans it will to late to fix the dependencies... > What do you want me to do? Can I drop both of them or do you want me to > drop Breaks only? So I would suggest to continue as usual and generate only the versioned Depends. Better safe than sorry. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310111501.gc31...@rivendell.home.ouaza.com
Maintainer needed for python-trml2pdf
Hello, I just uploaded a new version of python-trml2pdf where I removed myself from Uploaders. I originally packaged this because it's needed for Satchmo but I never went further to package satchmo. So I have no interest in this package. In the mean time it got one reverse dependency, namely kraft. So it can't be removed. Someone should step up to maintain this package, and quite possibly one of the kraft maintainers (since we're using the version released by Kraft's upstream anyway). The package is currently maintained within the python-modules SVN repository and all Debian developers have write access. It's trivial to maintain and should not require much work. On the bad side, it has no real upstream. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120504064142.ga26...@rivendell.home.ouaza.com
Re: Is python-django still maintained in DPMT svn?
Hi Barry, On Tue, 28 Jan 2014, Barry Warsaw wrote: > As the package is supposed to be team maintained, I'm wondering *where* it's > maintained. I have some patches to fix build failures against Sphinx 1.2.1. Good question. Luke, are you using git-svn and you forgot to push or something? > PS. I suppose I should add myself to Uploaders? Not required if you don't intend to work regularly on it. Just put "Team upload" in the changelog and lintian will be happy. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140128131627.gc15...@x230-buxy.home.ouaza.com
Help needed to test packages with Django 1.7
(Please cc me as I'm not subscribed) Hello, I have filed 85 bugs against all reverse-deps of python-django to ask their maintainers to ensure that their packages works well with Django 1.7 (1). A good chunk of those are maintained or co-maintained by the Python Modules team, and as usual in a large sample of packages, some maintainers will be MIA and I won't have any answer. So it would be highly appreciated if some people could help process the following bugs so that when Django 1.7 is out we have a good picture of what needs to be done and/or what will possibly have to be (temporarily) removed from testing: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 It would be nice if all packages had a test suite to ensure whether they still work but a large part doesn't even have a python-django build dependency so it's not really the case... What could be done however is mass-rebuild the packages against django 1.7 and mass-tag as confirmed the set of packages which are failing to build with Django 1.7. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722090523.gb27...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi,
On Wed, 23 Jul 2014, Brian May wrote:
> Attempt to summarize the problem: You want to make sure Django 1.7 is never
> installed if there are any apps with Django south migrations that haven't
> been run, and if Django 1.7 is installed you want to make sure django-south
> is not in INSTALLED_APPS.
>
> Think of the situation where somebody does an "apt-get dist-upgrade", and
> upgrades the packages containing the migrations and Django at the same time.
Multiple points:
- we should package South 1.0, it uses "south_migrations" instead of
"migrations" if it exists, that way applications can provide migrations
for South and for Django 1.7
- the settings needs to include South only in Django < 1.7, you can do
this for example:
import django
if django.VERSION < (1, 7):
INSTALLED_APPS += ('south',)
- still this doesn't solve the problem you mention, how can we ensure that
all deployed Django apps have all their South migrations applied prior
to switch to Django 1.7. This is only a problem if there are actual
schema changes managed by South between the wheezy and squeeze version
of the affected packages. There are only a handful reverse depends of
South:
python-django-voting,python-django-south
0.1 in wheezy, 0.2 in jessie
python-django-threadedcomments,python-django-south
0.5.3 in wheezy, 0.9.0 in jessie
lava-server,python-django-south 0.7.3
=> only in sid, not a problem
python-django-sitetree,python-django-south 0.7.1
=> only in jessie/sid, not a problem
python-django-reversion,python-django-south
=> 1.6 in wheezy, 1.8 in jessie/sid
python-django-picklefield,python-django-south
=> 0.2.1 in wheezy, 0.3.1 in sid
python-django-oauth-plus,python-django-south 0.7.5
=> only in sid, not a problem
bcfg2-web,python-django-south 0.7.5
1.2.2 in wheezy, 1.3.4 in jessie
At the very least, we should document this in debian/NEWS in
python-django.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723064623.ga3...@x230-buxy.home.ouaza.com
Problem migrating from South to Django migrations for Linux distributions
[ Please keep me in CC ] Hello, I'm one of the python-django Debian package maintainers and I have been working on preparing the field for Django 1.7... and we have one problem that we don't know how to handle. Consider that Debian contains Django but also Django applications using South. When our users will upgrade from Debian 7 to Debian 8 they will upgrade at the same time Django itself and the Django applications. The new versions of the Django applications are likely to have unapplied schema migrations managed by South but the system will have Django 1.7 and we have no means to let the users apply those schema changes. I see two ways to go forward: - either we find a way to apply South migrations with Django 1.7 - or we enhance Django migrations to be able to tag some point in the Django migrations as equivalent to some other point in the South migrations, that way we can recreate the supposedly-unapplied South migrations with Django 1.7 and mark those as unneeded if all South migrations were already applied How can we solve this problem? Thank you for your help! -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140724202733.ga8...@x230-buxy.home.ouaza.com
Re: Problem migrating from South to Django migrations for Linux distributions
Hi Brian, On Fri, 25 Jul 2014, Brian May wrote: > I can't help but think this might be unrealistic (?). Changes required for > new versions of Django often break compatibility with old versions, and > 1.4.5 is really old now. Just because many packages don't have versioned > dependencies on Django (or a versioned dependency on a really old version) > doesn't necessarily mean they will work with any 1.4.5. Anyone want to test > every Django package in Debian sid against the Django in wheezy? I agree with you that this is not realistic. A better alternate solution is to document the process of how to execute the South migrations with Django 1.6 in a virtualenv after having done the upgrade to Debian 8. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725074344.ga15...@x230-buxy.home.ouaza.com
Re: Problem migrating from South to Django migrations for Linux distributions
Hi Andrew, thanks for your quick answer. On Thu, 24 Jul 2014, Andrew Godwin wrote: > There is no way around this; it's unfortunate that the packaging situation > means that Django will get auto-upgraded as part of a distribution upgrade; > I'm surprised that Debian hasn't had this with packages before? (Version > upgrades that break installed but non-packaged things) We probably had this kind of things before and the best we can do for non-packaged things is usally to document this in the release notes. But for packaged things, we try usually hard to get things to just work without any human intervention. Hence my question. > Neither of your suggested ways to go forward will work; the two history > models are very different, so the tagging of positions isn't going to work, > and Django 1.7 has changed substantially enough internally that porting > South 1.x up to it would be a very large amount of work. OK. > Also, what are the applications in particular that this will be a problem > for? I'm curious to know what Django + South things Debian is shipping > these days. Applications that depend on South and have different upstream versions in Debian 7 and Debian 8 are: http://tracker.debian.org/pkg/python-django-voting http://tracker.debian.org/pkg/python-django-threadedcomments http://tracker.debian.org/pkg/python-django-reversion http://tracker.debian.org/pkg/python-django-picklefield http://tracker.debian.org/pkg/bcfg2 Given the package names, it probably means only a single end-user application. The others are Django "extensions" for use in non-packaged applications. And looking more closely the case of bcfg2, the package in Debian 7 does not use South, it started using South in the version in Jessie so it should be easy to deal with. For the 4 others, they should provide some NEWS.Debian entry warning users of the potential upgrade problem. (Bccing the 5 relevant bug reports to keep a record of this) Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725080457.gc15...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
On Sun, 03 Aug 2014, Brian May wrote: > > Django 1.7 final isn't even released upstream, and therefore, downstream > > projects didn't even try to run against it. There *will* be issues we > > will have to deal with. 85 packages is quite something. I'm ok, and even > > welcome to *try* to make it before Jessie, though it is my view that > > it's unreasonable to rush without taking care of possible breaking. I already explained you in another thread on debian-release, that it's not reasonable security-wise to release Jessie with Django 1.6. And you're well placed to know what it means to maintain a package that gets security updates very often... We have very few Django end-users apps in Jessie, so let's try to take care of those but it's not a problem if some of the Django "extensions" (i.e. apps available for integration in custom developments that have almost no reverse dependencies) are dropped from jessie. > > FYI, I'm trying to deal with python-memcache support for Python 3.4. > > Until that one is fixed, I wont be able to add support for Python 3 in > > keystoneclient, and therefore *a lot* of other packages will have no > > Python 3 support. I've tried to forward port a patch from > > python3-memcached, though it's still not ready, and unit tests are > > failing. Julien Danjou (eg: acid@d.o) wrote to me he'll try to find time > > to help. I really hope this one issue will be fixed soon, so that I can > > work on adding Python 3 everywhere possible in OpenStack, though right > > now it's a major blocker. I also hope we can upstream Python3 support > > for memcached, as the python3-memcached fork has been a major waste IMO. If you aren't able to deal with Django 1.7 support and Python 3 support before the freeze, please treat python 3 support as lower priority to Django 1.7 support. That said it would be nice to have both. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140803072708.gb19...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi, On Mon, 04 Aug 2014, Thomas Goirand wrote: > and already found out that TEMPLATE_DIRS needed an additional comma in > settings.py, though there's still a lot more failure in the unit tests. > If you want to help, just try to rebuild Horizon (and add a comma as I > wrote in horizon/tests/settings.py to begin with...). > > Horizon is my main concern. I spent some time on horizon and managed to fix quite a few failures in the test suite. I just sent my patches to the bug. There's still some work left though... > Well, I'm doing my best to add Python 3 support everywhere I can. I've > been doing this for months already. I know it wont be possible to fix > everything. Currently, I have 2 blockers which I am working on: > > - python-memcache > - beautifulsoup > > Both needs patches in upstream code, which I already partially wrote, > but it's not fully working (yet?). memcached isn't easy at all, as it > has to deal with lots of unicode stuff. Once these are done, then this > unlocks Python 3 support in maybe 40 other packages. Nice! beautifulsoup has also been annoying me as it's currently used by Distro Tracker (aka tracker.debian.org) and I want to make it work on Python 3. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804220353.gb17...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
Hi, On Tue, 05 Aug 2014, Matthew Vernon wrote: > https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git > https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git [...] > Naturally, I'd like to upload these as maintained by > python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If > so, I'll make some ITPs, and initial uploads. I would feel uncomfortable having the name of the team on it while the package is not on a repository writable by all members. (That said I'm also rather annoyed by the fact that the team hasn't switched to git yet.) Looking on git.debian.org, it looks like that some people started using git for team maintained packages: $ ls -al /git/python-modules/packages/ total 48 drwxrwsr-x+ 6 bzed scm_python-modules 4096 juil. 22 09:26 . drwxrws---+ 5 root scm_python-modules 4096 janv. 30 2014 .. drwxrwsr-x+ 7 obergix scm_python-modules 4096 nov. 29 2013 django-ldapdb.git drwxrwsr-x+ 7 azatoth-guest scm_python-modules 4096 mars 18 2013 plastex.git drwxrwsr-x+ 7 zigo scm_python-modules 4096 mai 16 2013 python3-pyparsing.git lrwxrwxrwx 1 aelmahmoudy-guest scm_python-modules 36 juil. 22 09:26 python-whoosh.git -> ../../collab-maint/python-whoosh.git drwxrwsr-x+ 7 dkg scm_python-modules 4096 mars 18 2013 python-xlrd.git So please move your git repository there. /me notes to switch python-django to git. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806064730.ga13...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
Hi Matthew, On Wed, 06 Aug 2014, Matthew Vernon wrote: > Is 1.7 released yet? At least Grappelli only aims to work with released > versions, so I think it's currently only 1.6-compatible. I'd expect > 1.7-support to be along once that's been out for a bit. 1.7 will be out in a few days/weeks and we aim to include it in Debian Jessie. We have opened bugs against all reverse dependencies asking them to validate their package with Django 1.7rc2 in experimental. See https://lists.debian.org/debian-python/2014/07/msg00085.html So please ensure they work with Django 1.7 before upload, or file a bug yourself and user tag them so that they appear in: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 Thank you! -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806192529.gb13...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
On Thu, 07 Aug 2014, Brian May wrote: > On 23 July 2014 15:58, Brian May wrote: > > > You are expected to do all database migrations with Django 1.6, then > > upgrade to Django 1.7 > > > > Some more thoughts. > > Are there any packages in Debian that attempt to automatically do database > migrations on upgrade? I don't think so. The few packages with south migrations were not concerned in the wheezy->jessie upgrade. > virtualenv --system-site-packages ~/old_django > . ~/old_django/bin/activate > pip install django==1.6.5 > pip install django-south > django-admin --settings=??? migrate --all > touch /etc/xyz/south_migrations_complete > deactivate > rm -rf ~/old_django > > Don't particularly like using --system-site-packages, think it will be > required to find the application however. Hopefully it will still get the > correct version of Django in this case. Can you test something like this? I would like to document something like this in NEWS.Debian of python-django so that admins are not left in the cold for their own django apps. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807214213.ga11...@x230-buxy.home.ouaza.com
Django 1.7 preparations
Hi, I rebuilt all reverse deps of python-django and I tagged confirmed all the associated bugs where the package failed to build with python-django 1.7 and I sent the relevant extract of the build log... It makes a total of 31 bugs that will need some attention: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 And 42 more that need manual evaluation of the situation. There's a good proportion of failures that look trivial (missing django.setup() call) but there might be more problems once this one is fixed... As usual your help is welcome. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140807214803.gb11...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
So let me give my own answer to some of the questions asked here. On Wed, 06 Aug 2014, Dimitri John Ledkov wrote: > However, it does not integrate with git-dpm at the moment and there is > no clear conversion / vcs history import available. Do we care about > preserving vcs history for our packages? Do we want synthetic history > (e.g. per upload granularity)? I believe it's useful to have some history, at least on a per-upload basis (and it's relatively easy to do do with git-import-dscs + debsnap). On Wed, 06 Aug 2014, Piotr Ożarowski wrote: > If one wants us to consider XYZ, please send a link to test repo and a > list of commands that will let us deal f.e. with such problems: Feel free to use "debcheckout python-django" as a test bed (just don't "git push" your tests). > * how can I fetch foo sources? what about updating all packages in one > command? > (XYZ pull? mr update?) "git clone" For the multiple repositories, yes it's "mr" that most teams use. > * how can I build it? > (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?) I do use "git-buildpackage" but it's really not a requirement. debbuild should be usable on a git clone. > * old patch needs an update, what should I do? > (quilt edit? quilt refresh? XYZ rebase on a different branch?) > * new patch is needed, how can I add it? > (quilt new? another branch?) I don't see the need for the team to impose anything here. patches are stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq". > * there's new upstream release, how can I import it? > (uscan in source pkg's root dir?) git-import-orig --pristine-tar --uscan > * how can I share my changes? > (XYZ push?) git push origin : git push origin --tags On Sat, 09 Aug 2014, Brian May wrote: > At the moment, in subversion, we only store the debian/* directory. Is > there any requirement/benefit in putting the full upstream source in git > too? Not putting the upstream sources would be non-sense. We want to be able to use the git tools to maintain the quilt series and for this we need the sources in git. It also makes it possible to use standard tools like debuild instead of needing some pre-build setup logic to extract the upstream sources and inject the debian directory. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813190835.ga18...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
On Wed, 13 Aug 2014, Piotr Ożarowski wrote: > [Raphael Hertzog, 2014-08-13] > > > * old patch needs an update, what should I do? > > > (quilt edit? quilt refresh? XYZ rebase on a different branch?) > > > * new patch is needed, how can I add it? > > > (quilt new? another branch?) > > > > I don't see the need for the team to impose anything here. patches are > > stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq". > > that's the problem. I'm lazy and I rather stop helping / sponsoring than > learn 650 ways to add a patch. You don't have to learn multiple ways to add a patch. You pick your preferred tool and you use it. Others use their preferred tool and everybody is happy since the exchange format (quilt series stored in debian/patches) is well defined. git-dpm and gbp-pq uses local branches that don't get pushed to update the patch series but the result is a simple update of debian/patches in whatever branch we store the Debian packaging. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814154758.ga2...@x230-buxy.home.ouaza.com
Re: guardian and django1.7
Hi, On Tue, 19 Aug 2014, Brian May wrote: > > For example, I renamed migrations to south_migrations and created a > > Django1.7 compliant migrations directory, however still get the same error. Did you fill that new directory with an initial migration generated with ./manage.py makemigrations? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819080439.ga1...@x230-buxy.home.ouaza.com
Re: Playing with git-dpm
Hi Barry, On Tue, 19 Aug 2014, Barry Warsaw wrote: > * The egg-info directory is a PITA. > > The upstream tarball has a lazr.smtptest.egg-info directory. debuild -S blows > this away, and then git thinks I want to delete it. It doesn't get staged, so > it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying > *very* quickly after just a few debuilds. I'm not sure what the best way to > handle this is, if there is one. You can commit the removal, but it will regularly cause merge conflicts. Or you can build the package in another directory, like svn-buildpackage does. I'm not sure if git-dpm has something for this but you can probably use "git-buildpackage --git-export-dir=../build-area/" in combination with git-dpm. > * debian/patches/* get named automatically > > `git-dpm checkout-patched` creates a temporary patch branch. I had to patch > the setup.py, so I just edited it as normal. Note though that you *must* > commit this file while on the patch branch or it doesn't get quilt-ified, but > it will still show up as modified on your packaging branch if you switch to > it. Oh, and the first line of your commit message gets turned into patch > name. I like that it handles quilt-ifying the patch automatically when you > `git-dpm update-patches` but watch out with your commit messages or you may be > left with a patch file that has an odd name. I didn't try to change that and > see if git-dpm could still grok the patch. I believe that git-dpm can handle any quilt series as input but it will always rename it based on the commit after a "checkout-patched". > * Where to push the repo? > > I'm not sure that we have a definitive path on git.debian.org for team > maintained packages under git, but there is a python-modules directory > containing a few packages. So I pushed my branches to > git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git > > It takes a bit of work to create this directory initially, but I found that > gbp has a nice command you can corrupt into doing the right thing for > you, e.g.: Please do something like this to create new git repositories for python-modules: $ ssh git.debian.org $ cd /git/python-modules $ ./setup-repository lazr.smtptest "lazr.smtptest packaging" $ exit It will setup some default hooks to to forward the commit notices where appropriate. (I just did the required configuration for you.) > Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have > no idea why. It's there now. The repository listing is not updated in real time (too much I/O involved). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820192111.gb2...@x230-buxy.home.ouaza.com
Re: Playing with git-dpm
On Wed, 20 Aug 2014, Barry Warsaw wrote: > So, because of the way I've named the branches, the full invocation is: > > $ git-buildpackage -S --git-export-dir=../build-area/ > --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest So --git-export-dir is usally best set in ~/.gbp.conf: $ cat ~/.gbp.conf [DEFAULT] pristine-tar = True cleaner = /bin/true [git-buildpackage] sign-tags = True export-dir = ../build-area/ For the other two options, the recommended practice is to put them in debian/gbp.conf but I generally don't do that and just use standard branch names (master / upstream). > Thanks for both the recommendation and the fix! Once the team decides on a > workflow, will it be feasible to write the equivalent of svn-inject? Since > shell access to g.d.o is required it seems like this won't be completely > self-services, but teammates who are DDs could do it for other folks. git-import-dsc is your svn-inject, it will put upstream sources in the upstream branch and will create the master branch based on that with the packaging changes. But the quilt patches won't be applied after this operation. I managed to start using git-dpm on a pre-existing repository but it required an initial "git-dpm init .../mypkg_1.orig.tar.gz" IIRC. Note that all members of the team automatically have shell access to git.debian.org (it's just alioth itself). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820201709.gc2...@x230-buxy.home.ouaza.com
Re: Playing with git-buildpackage
Hi,
On Thu, 21 Aug 2014, Barry Warsaw wrote:
> Then I `git init`'d a new local repository and used `gbp import-dsc` to
> initialize the git information. That seemed to work just fine.
FWIW, I usually setup the repository on git.debian.org first and then I
clone that empty repository. With this process, the git repository already
has the "origin" remote already setup.
> Now I wanted to update the package to 2.0.1, so I used `git-import-orig
> --uscan` which works great, except that it doesn't add a debian/changelog
> entry. That would be a nice convenience I think.
gbp's developer is relatively active, feel free to file wishlist bug
reports for that kind of things.
> `gbp pq` is the tool to manage the patch branch, but there were a few things
> that seemed messier than with the git-dpm experiment:
>
> * I used `gbp pq switch` to get to the patch-queue/master branch. Unlike with
> git-dpm, this does *not* delete the debian/ directory. It did make things
> smoother with Emacs because upon switching back (later) to master, I didn't
> have to revert the files I was visiting. But I realized that it did leave
> me in a somewhat confusing state. Should I use quilt? The patches were not
> automatically applied by `gbp pq switch`. Maybe I should have imported
> them.
"gbp pq import" is the right command indeed, it will create the branch with
everything required and switch to it.
> It makes me think that git-dpm's handling of debian/ is probably closer to
> right, so that there'll be no temptation to muck about with quilt while in the
> patches branch. Maybe a better approach would be to delete just
> debian/patches - that would remove my confusion but wouldn't force me to
> revert all the debian/ files I was editing.
When you analyzed git-dpm, the lack of debian was a negative point, so it
would be weird to want to remove it here.
What you possibly need is an enhanced shell prompt displaying the name of
the current branch, it's relatively easy to do by embedding $(__git_ps1
2>/dev/null) somewhere in your $PS1. That way you immediately see that you
are on the patch-queue branch...
> I was disappointed with the documentation surrounding the `gbp pq` workflow.
> It's not really described in the git-buildpackage manpage and the best
> documentation for `gbp pq` is off-site and external to debian.org.
man gbp-pq ?
It effectively points to the website of the author, but that doesn't sound
like a problem. It's possibly because the software is quite well
documented on https://honk.sigxcpu.org/piki/projects/git-buildpackage/
that there's no wiki page or anything like that explains everything.
> The other disappointing thing is that once I was back on the master branch,
> the patch-queue/master branch was not deleted. That's a nice little cleanup
> that git-dpm handles for you. After all, who wants that temporary patch
> branch on git.d.o?
Why would you push your temporary branch?
I know this can happen if you do "git push --all" but that command is
not a good idea in general... you can do "git push origin :" to push all
the branches that are pre-existing on the remote side.
Keeping the branch makes it easier to rebase it in the future and then
re-export the patches.
> git-buildpackage has --git-ignore-new but that's actually not enough! Because
> of the vagaries of git, you have an extra "level" of changes, i.e. the index.
> This means that if you want to include uncommitted changes in the package, you
> need to also use --git-export. There are two options here: --git-export=INDEX
> obviously includes the staged changes while --git-export=WC includes the
> working copy. =WC seems much more aligned with my own personal preferences,
> and is closer to what svn-bp does by default.
Note that this is only required because you actually use
--git-export-dir=../build-area/. When you don't do that you build out of
the working copy and --git-ignore-new is then enough.
> Once I uploaded the package, I had trouble with git-bp --git-tag-only
> recognizing my gpg keys. I didn't investigate further, but just used
> --git-no-sign-tags for now.
I never had any problem with signing the tags. Does your git identity
matches your identity on the GPG key?
> After this experiment, my own personal preference is leaning toward git-dpm.
> It just seems like a cleaner, more self-contained, and better documented
> workflow. I think there's room for improvement, but git-dpm is "just" a fancy
> shell script so I hope it's maintainer will be open to patches and
> suggestions.
gbp is Python and the author is also open to patches and suggestions :-)
> In truth though, I bet it won't be hard to convert from one to the other. The
> biggest difference that I can tell is that if you use the default branch
> names, it's mostly just the tag names that differ:
>
> git-dpm: {debian,patched,upstream)-
> git-bp: {debian/upstream}/
In python-django, I just switched to debian/ +
upstream/ following early result
Re: Playing with git-buildpackage
On Fri, 22 Aug 2014, Barry Warsaw wrote: > >Why would you push your temporary branch? > > Only because `git push --all` seems like the obvious choice. But I think > git's cli is akin to quantum mechanics, i.e. don't trust your intuition. :) Ideal is when a "git push" alone is enough, you can do "git config push.default matching" to make it push all the branches that exist on both sides. That used to be the default but it's counter-intuitive... I agree it's a pity that there's no "git push --matching" option instead of the non-explicit "git push origin :". > >It would be nice if the admins could whitelist all mails containing > >an "X-Git-Repo" header. > > In Mailman, that's easy. > > >Or at least whitelist all *@users.alioth.debian.org emails as those are in > >the From of those emails. (I just changed a setting so that it uses this > >domain now) > > In Mailman, that's easy. > > >Alternatively you can subscribe to the list with your > >@users.alioth.debian.org mail and disable mail delivery for that > >address. > > In Mailman, that's easy. > > Anybody know the maintainer of the mailing list? http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-commits => stra...@users.alioth.debian.org aka Gustavo Franco I'm not sure if Gustavo is still active or if someone else has the admin password... Gustavo? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140823071521.ga31...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
Hi Sandro, On Wed, 27 Aug 2014, Sandro Tosi wrote: > It seems to me like very vocal Git fanatics, who refuse to touch any > package which is not maintained in Git (-.-), are pushing and pushing > to that VCS without any clear advantage. You might dismiss those people but you're speaking of true contributors that you're aleniating here. If we really want to stay an all-inclusive team we should use what the majority of (possible) contribtuors prefer to use. python-modules is about the only team I'm part of that is not yet using git. It's an annoyance to have to continue to use svn-buildpackage when I only use git everywhere else. > Upstream releases history? why do we need to care, we are packagers we > should care about packaging commits history. Because your packaging decisions are not influenced by upstream changes? > from the VCS again? seems kinda twisted to me :) And no, not the whole > programming world is using Git for upstream code (sometimes we're not > even able to teach upstream to use proper versions), so the usual > mantra "I can pull from upstream repo and be happy ever after" is > kinda weak. Not everybody is using git but I think that you should face it, most of the upstreams projects do. > is there anything else so "attractive" about git? It's 200% more easy to manage multiple branches and merge them properly. Most of the average python modules will not need multiple branches but for things like python-django, we do need multiple branches... and the fact that svn is such a pain means that the security updates were not managed in svn for example... And handling security updates in svn is a pain because you can't commit localy and push only when the security update is disclosed publicly. etc. All those are real problems for real people doing packaging work. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827084040.gc23...@x230-buxy.home.ouaza.com
Re: DebConf14 svn->git migration BOF notes
On Wed, 27 Aug 2014, Stuart Prescott wrote: > > I've done some personal investigation since the BOF, and am preparing > > some really simple migration scripts, so we can get a feel for what it > > will look like. My scripts so far (very very simple) > > git://git.debian.org/users/stefanor/dpmt-migration.git > > is there any reason to use a loop around git-import-dsc rather than git- > import-dscs --debsnap here? I haven't looked at stefano's script but git-import-dscs will import all source packages in a single linear history (importing the packages by increasing version) and that isn't representative of the true history. For python-django, I imported all the "normal" versions in the debian/sid branch but manually imported the "+deb7uX" in a debian/wheezy branch, the "+squeezeX" in a debian/squeeze branch, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827085224.gd23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
On Wed, 27 Aug 2014, Sandro Tosi wrote: > like true contributors are those using svn right now. and what about > the majority of contributors now? we should change just because maybe, > eventually, if we're lucky we'll attract more contributors? saying "I > won't contribute to your team if you don't move to Git" is IMHO > arrogance and against team work (but we know. I'm different :) ) Please don't try to split contributors in two camps. I do continue to use svn-buildpackage for the few django extensions that I maintain in python-modules. And even if I moved python-django to git, I'm still a team contributor even if I touch only a small subset of packages. > > Because your packaging decisions are not influenced by upstream changes? > > i don't follow? is that an advantage of having the upstream source > code in the Debian packaging repository? Yes, I regularly use "git log" on upstream metadata files to see whether we missed some new (optional) dependencies and stuff like that. > > Not everybody is using git but I think that you should face it, most > > of the upstreams projects do. > > i dont think so. It might be true for the big projects, but look at > the vast majority of the packages in DMPT/PAPT, they are small > modules/apps how many of them are using git? I wont say "most" more > "few" of them. No point in arguing here (I don't have time to do a proper analysis and come up with figures). That said in my experience, most new stuff I tend to package are actually maintained in github or a similar service. The fact that we are grabbing .tar.gz on pypi means that we might also not be directly aware that the tarball is generated out of a git repository. > > It's 200% more easy to manage multiple branches and merge them properly. > > Most of the average python modules will not need multiple branches but for > > things like python-django, we do need multiple branches... and the fact > > that svn is such a pain means that the security updates were not managed > > in svn for example... > > branches exist in svn too (I admin they are harderd than git tho) and > security updates always evolve in 2 separate ways than current > development (in fact, I think you're referring to update in stable, so > you'll have a branch for stable and trunk, which likely are at 2 > different versions, evolving indipendently. I did that for matplotlib, > and it's doable) I said "200% more easy", I know that they are doable, but it's just painful... > > All those are real problems for real people doing packaging work. > > you skipped the part of what are the problems the teams is facing with > svn we want to solve with git, while it seems you're talking about > your experience with Django alone, which is important of course but > not necessarily representative of a huge amount of packages in our > teams. And? If we want a single VCS then we must cater to the most demanding use cases. Obviously svn-buildpackage is just fine for small packages with a single branch and no patches... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827091911.ge23...@x230-buxy.home.ouaza.com
Re: A few git-bp nits
Hi, On Thu, 28 Aug 2014, Barry Warsaw wrote: > * There are anomalies when pushing and pulling branches created with g-i-d. >I get the following errors when I do the initial push: > > remote: fatal: Invalid revision range > ..e14331dcbaf3f097267ca1a7a2ee6a7fd734 > > remote: fatal: Invalid revision range > ..a9bb83a461be57ebcd09fa7b5a57597a866dfb52 > > remote: fatal: Invalid revision range > ..48ba72c1bb849788fbe6ae0c20d9e28093039cd9 > > remote: fatal: Invalid revision range > ..1a90ad5e79b2a5298d42a38308019e281bfc95c5 > > >I have no idea what's causing these or what horrible deformity it's leaving >the state of the repo in. Those are harmless, it's probably /usr/local/bin/git-post-receive-tag-pending that is generating those for the initial push (where there is no old commit). >It does *something* bad because subsequently cloning the repo afresh, >I get this error: > >warning: remote HEAD refers to nonexistent ref, unable to checkout. This is unrelated. I modified /git/python-modules/setup-repository to call “git symbolic-ref HEAD refs/heads/debian/sid” so that the default branch is debian/sid. So unless your repositoriy contains a debian/sid branch, you will get this warning. Still your clone is fine, you can do "git checkout master" and you will have a proper checkout. You can can call the above command with another branch as parameter if you want to reset the default branch to something else. You can also re-modify the script if everybody prefers to experiment with "master" as the default branch. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829193155.gd6...@x230-buxy.home.ouaza.com
Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)
On Thu, 04 Sep 2014, Barry Warsaw wrote: > On Sep 04, 2014, at 04:36 PM, Scott Kitterman wrote: > > >Actually, nevermind. That's not the problem you were trying to solve, > >although you could remove the patch as described and then apply the updated > >patch at the end of the series. > > Yeah, though sometimes for legitimate reasons you can't reorder patches. It > vaguely feels like with git-dpm since the patch branch is never pushed, you > could "uncommit" (`git reset --hard HEAD^`) and stash each commit until you > got to the one you wanted to amend, then unstash and recommit back up the > stack. E.g. just like quilt push/pop. As others have mentionned, you should use "git rebase -i ". This is what you want to use on your patch-queue branch to modifiy individual commits, reorder them, or drop them. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140904222559.ga7...@x230-buxy.home.ouaza.com
Re: Recommendation: adopt git-dpm
On Thu, 04 Sep 2014, Barry Warsaw wrote: > Even with those complaints, git-dpm feels like the better tool for team > package management in git. The problems are minor and probably easily > fixable. >From my point of view, since you're anyway using features of git-buildpackage, it would be better to improve git-buildpackage... I like how git-dpm can keep patches applied on the packaging branch and porting the required shell to "gbp pq" should not be too complicated. It would also be nice if we could fix "gbp pq" to not rename quilt patches. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140904223231.gb7...@x230-buxy.home.ouaza.com
Re: django 1.7 change for backport to wheezy
Hi, On Tue, 09 Sep 2014, Brian May wrote: > Can I please get the following change in python-django git? > > Add the following to debian/control: > > X-Python-Version: >= 2.7 > > This will make backports to stable a lot easier. Otherwise the package > builds fine, but won't install in Python 2.6 is installed. > > I would do it myself, but not 100% confident of the branches - I guess I > should use the debian/experimental branch? Yes, please commit that on the debian/experimental branch. (Sorry that I lost this in the git conversion.) Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909063146.ga31...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi Brian, thanks for those investigations! On Thu, 11 Sep 2014, Brian May wrote: > Note that I have explicitly called python. This ensures Python 3 not used > (not supported by South + the virtualenv is Python 2 only) and that we get > the python from the virtualenv. > > I have tested this and it appears to work, although the above was changed > not to be specific to my app. Please document this in python-django's README.Debian and mention where to find this sample in the current debian/python-django.NEWS entry. TIA. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911062808.gb9...@x230-buxy.home.ouaza.com
Re: django 1.7 bugs
Hi, On Sat, 13 Sep 2014, Thomas Goirand wrote: > I think we should all focus first on the Python Team modules, and see > where that leads us. Also, to me, considering the amount of remaining > bugs without a single reply, it's too early to upload Django 1.7 to Sid. > Raphael, do you still plan to upload next week? Yes. I prefer to do it now, thus raising the bugs to higher severities soon since that's the only thing that will attract the attention of the remaining maintainers and of all people who help squash RC bugs. Also if some packages get removed due to RC bugs, it's better when it happens soon so that reverse-dep get notified earlier and have a chance to reintroduce the package if needed, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140914125838.gc20...@x230-buxy.home.ouaza.com
Re: django 1.7 bugs
Hi, On Fri, 12 Sep 2014, Zygmunt Krynicki wrote: > I wrote large parts of lava-server and both of the django- packages > here but I'm not an active upstream anymore (I cannot commit to those > repositories, only Linaro folks can) . If anyone wants my help though > I'd gladly render assistance. I already provided some patches to fix unit test failures but upstream is concentrated on other stuff in the short term so Neil might appreciate your help to review the patches and do some higher level testing with Django 1.7. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140914130225.gd20...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi, On Tue, 16 Sep 2014, Brian May wrote: > On 11 September 2014 16:39, Brian May > wrote: > > > Ok, will look into this tomorrow. > Just pushed a change. > > Unfortunately, had problems testing this because "debian/rules clean" > removes Django.egg-info/* which is flagged by git-buildpackage as > uncommitted changes. Recent versions of git-buildpackage should no longer call debian/rules clean IIRC. But you can disable this with: [DEFAULT] cleaner = /bin/true in ~/.gbp.conf Alternatively you can build with "--git-ignore-new" too. > Also django-migrate-south won't work without virtualenv installed. Was > wondering if maybe I should add it to recommends (wheezy needs > "python-virtualenv"; sid needs "virtualenv" installed). I'm not sure that adding such a script in /usr/bin/ is a good idea. It doesn't have a manpage, it's a temporary hack, etc. I would put the script in the doc directory and I would document to run it as: sh /usr/share/doc/python-django/migrate-south --settings app.settings Then it's more logical to not change the dependencies and just document (as you did) the need to install virtualenv. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916065130.ga23...@x230-buxy.home.ouaza.com
Re: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
Hi, On Wed, 24 Sep 2014, Julian Taylor wrote: > > Nah. It's a great reason to teach the tool in question to be *way* more > > reasonable. Who needs a single email per commit? Esp. since the number of > > actual commits will go way up with increased git usage – feature branches > > are easy in git, and more granular commits are a great way to help with > > tracking down exactly which change introduced a regression. > > Single mails/irc messages per commmit are very useful, they help a lot > to find mistakes others are making before an upload happens. > > What we don't want is messages for upstream changes. This should be > simple to fix, simply check the changed paths for debian/ before sending > a message. The default script in use on Alioth is based on git-multimail: https://github.com/mhagger/git-multimail It doesn't have such a path-based filtering. But it's Python \o/ So it would be nice it you could contribute such a feature upstream. :-) That said using maxCommitEmail is still a good safeguard. There's also the possibility of only using refchangeList (instead of mailinList) so that we only send out the summary mail of what has been pushed. The caveat being that we don't get diff of the changes wich is what makes those email notifications interesting. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140924073229.gb5...@x230-buxy.home.ouaza.com
Re: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
On Thu, 09 Oct 2014, Sandro Tosi wrote: > so is there any chance you stop this commit storm madness anytime > soon? another bunch of >300 commit messages arrive this night I fixed the default configuration in setup-repository to limit to 20 commits per push as a maximum. And I also limited the size of individual commit emails to 1000 lines. I updated the configuration of the already existing repositories. hertzog@moszumanska:/git/python-modules/packages$ for i in *.git; do cd $i; git config multimailhook.maxCommitEmails 20; git config multimailhook.emailMaxLines 1000; cd -; done Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009080251.gf3...@x230-buxy.home.ouaza.com
Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)
On Thu, 09 Oct 2014, W. Martin Borgert wrote: > On 2014-10-09 10:02, Raphael Hertzog wrote: > > I fixed the default configuration in setup-repository to limit to 20 > > commits per push as a maximum. And I also limited the size of individual > > commit emails to 1000 lines. > > I wonder, whether some kind of digest function would be possible > and useful? There is already a single mail per push that summarizes all the commits and the individual commits are sent as replies to that initial mails (provided that the number of commit doesn't exceed 20, otherwise you only get the summary mail). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009093602.gg3...@x230-buxy.home.ouaza.com
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
On Fri, 10 Oct 2014, W. Martin Borgert wrote: > On 2014-10-10 15:59, Ben Finney wrote: > > Agreed. This is a direct result of rebasing Debian packaging history > > onto upstream VCS history, and keeping them all in the same repo as one > > undifferentiated history, no? > > Not sure, but isn't this more a result of the scripts in use, to > not differentiate paths? > > I assume, that the script uses post-receive, so it has access to > all commits, including all affected paths. If so, generating only > emails or IRC messages when debian/ is involved should be easy. Yes, are you volunteering to implement it? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010081324.gb15...@x230-buxy.home.ouaza.com
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
Hi, On Fri, 10 Oct 2014, Charles Plessy wrote: > Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit : > > > > Where is the repository of the scripts involved? Maybe I have > > some spare time this weekend... I hope, it's all sh or Python. > > I forgot all my Perl. > > Hi Martin, > > good news, it is in Python :) > > https://github.com/mhagger/git-multimail/ But the IRC notifier is "kgb-client" (packaged in Debian) and this is Perl. I just filed a wishlist bug about this: #764713 Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010131715.gh29...@x230-buxy.home.ouaza.com
Bug#781165: RFP: prospector -- Python code analysis tool
Package: wnpp Severity: wishlist * Package name: prospector Version : 0.9.9 Upstream Author : Carl Crowder * URL : https://github.com/landscapeio/prospector * License : GPL-2+ Programming Lang: Python Description : Python code analysis tool Prospector is a tool to analyse Python code and output information about errors, potential problems, convention violations and complexity. It brings together the functionality of other Python analysis tools such as pylint, pep8 and McCabe complexity. More information and a complete list of supported tools is available on the documentation site. The primary aim of Prospector is to be useful 'out of the box'. A common complaint of other Python analysis tools is that it takes a long time to filter through which errors are relevant or interesting to your own coding style. Prospector provides some default profiles, which hopefully will provide a good starting point and will be useful straight away, and adapts the output depending on the libraries your project uses. It would be nice to have this available to help check one's own Python code. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150325142746.ga17...@home.ouaza.com
Re: [DPMT] radical changes: automation, carrot and stick
On Wed, 07 Oct 2015, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? While I understand the desire to have one identified maintainer for each package, I don't agree with the rule. Changing maintainer means changing the flow of information and it is a pain. When I get interested in a package, I subscribe to the package in the tracker. At some point, I end up the "maintainer" because the former maintainer left and here I should put myself in maintainer... that would mean getting duplicate mails and me having to fix my subscriptions or add procmail rules to avoid this. So I don't think that this rule gives us more benefits than annoyances. If you want to identify someone as in charge, let's define that the first person in the Uploaders field is that person. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
Hi, On Fri, 09 Oct 2015, Brian May wrote: > We can move the migrated version out of the way, restore the old version, > and update it to the required standards (e.g. git-dpm). Is everyone happy > with this approach? Yes, except for the naming of branches where I would prefer to keep the DEP-14 naming scheme (we should just rename debian/sid into debian/master). http://dep.debian.net/deps/dep14/ And I would suggest that we generalize the DEP-14 naming scheme as part of our git packaging policy... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Git migration schedule
On Sun, 11 Oct 2015, Brian May wrote: > What branches do I need to put the debian/README.source file in? There are > six debian/* branches, don't think it is a good idea to try and maintain a > consistent debian/README.source in all branches. > > Maybe debian/experimental would be sufficient? Or perhaps > debian/experimental + debian/sid? > > In fact, putting in a branch seems wrong, it isn't specific to any one > branch, not sure where a better place would be though. IMO, you should just indicate that the repository follows DEP-14 and not be specific about the branch names. That way you don't have any problem. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
Hi, On Sat, 10 Oct 2015, Barry Warsaw wrote: > >And I would suggest that we generalize the DEP-14 naming scheme as part of > >our git packaging policy... > > I'm all for standardization, but I do like the shorter names for the common > case where you only need the unstable version. Certainly if there are vendor > or series differences, the namespaces make a lot of sense. But most of my > packages don't need it. This is something that you don't know... a derivative can always want to fork for whatever reason (the most common one being that we lag behind upstream). And another reason for the namespace is to not collide with the upstream namespace. And this one is almost always there (given most upstream use git nowadays). > Would you be open to allowing such simplification in the common case in > DEP-14? Given the above, I believe that having just debian/master is better than encouraging the use of "master". I think the DEP reached a good compromise already. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
On Sun, 11 Oct 2015, Brian May wrote: > Just noticed how it named the upstream branches. > > * [new branch] upstream-debian/experimental -> upstream-debian/experimental > * [new branch] upstream-debian/jessie -> upstream-debian/jessie > * [new branch] upstream-debian/sid -> upstream-debian/sid > > Not sure this is ideal :-( This definetely sucks, I want to continue to use upstream/1.7.x, upstream/1.8.x and so on. We want to be able to maintain multiple upstream branches in parallel, no matter where they are uploaded. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
On Sun, 11 Oct 2015, Brian May wrote: > Just noticed how it named the upstream branches. > > * [new branch] upstream-debian/experimental -> upstream-debian/experimental > * [new branch] upstream-debian/jessie -> upstream-debian/jessie > * [new branch] upstream-debian/sid -> upstream-debian/sid > > Not sure this is ideal :-( I added debian/README.source documenting how to avoid this and keep using the upstream branches based on upstream versions. And I filed #801666 (git-dpm: Need a way to set the upstream branch names from within the repository). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Django 1.8 in unstable in early November
Hello, I just filed 20 bugs on packages that FTBFS with Django 1.8. They have two weeks to be fixed before we upload Django 1.8 to unstable. https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django18 If you maintain a package in the Django ecosystem, please double check that it's ready for Django 1.8. The fact that it doesn't fail to build does not mean that it will necessarily work if you don't have any tests or if you don't run them. If you file more bugs related to Django 1.8, don't hesitate to add the "django18" usertag associated to the "python-dja...@packages.debian.org" user. (I wish we could easily rerun the DEP-8 functional tests with a new version of the package) Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Git migration schedule
On Tue, 20 Oct 2015, Brian May wrote: > Barry Warsaw writes: > > > Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt > > *as long as the final state of the repo is compatible with git-dpm*. > > Meaning, > > in general, you can make whatever local decisions you want as long as they > > don't force other team members to go outside of team recommendations. > > I don't see how you could use quilt and maintain compatability with > git-dpm. git-dpm expects all patches to be in git, and will update > debian/patches automatically from git. quilt writes patches directly in > debian/patches/* and doesn't support git. > > Not something that concerns me personally, quilt was starting to become > very painful for me. I regularly ended up forgetting the "quilt add" > operation before editing files, resulting in invalid patches. And also for import of upstream tarballs you basically have to use git-dpm as git-dpm keeps state data in debian/.git-dpm whereas git-buildpackage does not have similar state data (except the generic git data like availability of a upstream/ tag, and so on). I really regret to not have invested time earlier to try out git-dpm... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Git migration schedule
On Wed, 21 Oct 2015, Sandro Tosi wrote: > On Wed, Oct 21, 2015 at 11:01 PM, Brian May wrote: > > Maybe we should fix #801666 first and then revisit this question? > > git-dpm hasnt seen a single line changed since more than a year > (http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont hold > my breath on it :( Yeah :( That makes another point that was missed in the evaluation of git-dpm vs git-buildpackage and its "gpb pq" command. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: dh-python (pybuild + dh_py*) documentation
Hi Piotr, On Mon, 26 Oct 2015, Piotr Ożarowski wrote: > How can I improve it? Do you need more detailed description of options? > Do you need more examples? Or maybe I should hide most of options, the > "corner case" ones? I focus on making things work out of the box, if > possible, and make it very customizable so that weird corner cases are > possible as well - this means there are a lot of options, is this the > problem? > > Can you be more specific about what's missing? I for one lack a high level presentation of how the various bits work together and a clear description of the "magic" behind each tool. For instance, dh_python2 explains that it tries to translate Python dependencies into Debian dependencies but it's not clear that it needs the corresponding packages installed (so it's not clear that for this to work you have to add something to Build-Depends). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: How to maintain multiple branches (sid/bpo/exp etc)?
Hi Sandro, On Mon, 02 Nov 2015, Sandro Tosi wrote: > hello, > with the new DPMT repo layout and tools, what is the right way to > maintain multiple active branches for our packages? things like: > > 1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2 > 2. unstable at v1, experimental at v2 > > all of them active, so in the 2. case there should be a way to keep > updating v1 and v2 releases (and so unstable and exp) as the come. Have a look at what we did for python-django and check out its README.source to learn how to configure git-dpm to match the various upstream branches and the corresponding Debian packaging branches. I experienced yesterday how to merge a branch into another branch (merging experimental with 1.8 into unstable that had 1.7) and the least I can say is that it was not flawless... I already reported the issue here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667 So I did a plain "git merge" and did the following to clean up: - resolved all conflicts by picking the merged side (including debian/.git-dpm) - ran git-dpm status and reverted changes that did not conflict during the merge but that were not part of the upstream changes (they are probably left-over from debian patches since those are now applied in the packaging branch) - manually cleaned up debian/patches Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Bug#812117: RM: simpletal -- RoQA; unmaintained; low popcon
On Wed, 20 Jan 2016, Mattia Rizzolo wrote: > loggerhead: loggerhead And that rdep is relatively important since AFAIK we use loggerhead at least on alioth to browse bzr repositories. Maybe it's best to invest a bit of time into updating it rather than dropping it just for the sake of its low popcon? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: django-pipeline / slimit
On Wed, 23 Mar 2016, Brian May wrote: > I: pybuild base:184: PYTHONPATH=. python3.5 /usr/bin/django-admin test > --settings=tests.settings ^ > File "/«PKGBUILDDIR»/pipeline/compressors/slimit.py", line 12, in > compress_js > from slimit import minify > ImportError: No module named 'slimit' [...] > Does this mean we need to change the slimit package into python-slimit > and python3-slimit packages? Looks like so, indeed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: django-pipeline / slimit
On Wed, 23 Mar 2016, Brian May wrote: > Looks like slimit doesn't support Python3 and hasn't had an upstream > release since 2013-03-26. > > Any suggestions where to go from here? > > Maybe hack pipeline to disable the failing test? I think pipeline can be > configured to use jsmin instead of slimit and jsmin is packaged in > python2 and python3 versions. Yeah, skip the test on Python 3, tell upstream that slimit is not supported on Python 3 and that the test should be skipped there. Make sure that slimit is not the default. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: using git-dpm or plain git-buildpackage in PAPT and DPMT
On Wed, 10 Aug 2016, Nikolaus Rath wrote: > I don't believe that switching from git-dpm to git-buildpackage is going > to make things easier, it'll just be trading one set of problems for > another. I don't agree on this. I have been a happy git-buildpackage user for all my packages. The problem with git-dpm is that the patch series can't be easily fixed after a merge when it generates conflicts. It's too intricately tied to git-dpm's own fake merge logic with commit it recorded in debian/.git-dpm and it's very painful to bring the repository in a state where git-dpm is happy. With git-buildpackage, the merge and the update of the patch series are distinct operations that can be done at different times. Since patches are unapplied, the merge usually works fine and the patch series can be easily rebased afterwards with your tool of choice. Anyway, +1 from me to switch to git-buildpackage and in fact among the python-django maintainers we are close to decide to switch back to git-buildpackage because it's really horrible to use when you want to merge across branches of different releases. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: DPMT Membership request
Hello Marcos, On Wed, 23 Nov 2016, Marcos Fouces wrote: > I am still waiting for an answer. I don't know how to proceed in this case. You should have subscribed to debian-python@lists.debian.org and you would have seen that you have to reply to https://lists.debian.org/20161117075743.i7exf7vmpbi4a...@sar0.p1otr.com That's the blocker right now. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
