Re: Please install /usr/bin/python2
On Mon, Sep 16, 2013 at 4:05 AM, Steve Langasek wrote: > On Sun, Sep 15, 2013 at 09:53:41PM +1000, Ben Finney wrote: >> Lachlan writes: > >> > i'm not an expert by any means but i fail to see how this is an issue? > >> In short: Debian is not the only Unix-like system where Python is >> installed, and consistency across operating systems is valuable. > > Yes, it is, which is what makes the Arch devs' change to make things > *inconsistent* by pointing /usr/bin/python to python3 an unforgivable > screwup. > > /usr/bin/python is an interface for python2. Having this change over time > to point to something incompatible, such as python3, is Evil Bad Wrong. We > are now in the situation that we have to ship /usr/bin/python2 for > compatibility with scripts originating from Arch, but that in no way implies > that /usr/bin/python should be changed to python3. Repurposing > /usr/bin/python should only happen following an intervening release in which > python2 is not shipped *at all*. > >> > -Everyone wrote scripts for python 2.x using /usr/bin/python > >> And eventually Python 2 will be long obsolete. > > And *once that happens*, we can discuss resurrecting /usr/bin/python and > pointing it to python3. It should not change until then. That's a wrong strategy. The scripts should be patched to use right version of Python, and they could not be patched until Debian doesn't provide right version for them, i.e. python2. >> > -With python3, scripts were written specifically for python3 using >> > /usr/bin/python3 > >> Not all of them, and the expectation is that more and more systems will >> assume “/usr/bin/python” is the current version of Python. > > Who expects that? Arch is negligible. Debian and Ubuntu are not going to > make this change. What other OSes are making the ill-conceived change to > /usr/bin/python? Windows never did the conversion. It just came natural for this 'poorly designed OS' to rewrite Python binaries with the latest installed. You could never expect to find Python of required version on this platform. Probably it was one of the reasons why virtualenv was born. >> See PEP 394 http://www.python.org/dev/peps/pep-0394/>. > > It's not the first or last time that an upstream has made a poor > recommendation that Debian rightly ignores. > > Enabling /usr/bin/python2 compatibility benefits our users, yes. Promoting > its use, or making /usr/bin/python incompatible with the many existing > scripts running on older Debian releases, does not. As a Python developer I couldn't care less for the "default Python" stuff as long as my scripts use proper shebang. python for 2/3 compatible stuff, python2 for 2.x only and python3 where needed. The Debian python policy should require that. This is an upstream recommendation that Debian wrongly didn't pay attention to, choosing to complain about inevitable natural processes instead. Take it easy. -- anatoly t. -- 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/CAPkN8x+s=t5BZZzZogGhEFux=5ixmzuckl9ay1uo6nntaab...@mail.gmail.com
Re: Please install /usr/bin/python2
On Sun, Sep 15, 2013 at 1:47 PM, Lachlan wrote: > i'm not an expert by any means but i fail to see how this is an issue? > > -Everyone wrote scripts for python 2.x using /usr/bin/python > -With python3, scripts were written specifically for python3 using > /usr/bin/python3 > > When Debian eventually changes to python3 by default all the scripts will be > written using /usr/bin/python3 anyway so it shouldn't matter what the python > symlink is as we are following the major release number for python3+. There > isn't a reason to change the /usr/bin/python link let alone create one for > python2. > > Debian source packages that require a python2 symlink would be patched out > and it would be fine. I am a Python coder. Python is a cross-platform language that runs on Windows, Unix, Mac X, Raspberry PI etc., and I like if my script runs everywhere. Now I have tons of legacy libraries that are written in Python 2 and porting them to Python 3 is not trivial. So I have to stick with Python 2 for the next 5+ years or so. Now I discovered that if you install Python 3 on Windows, the default 'python' command will invoke Python 3, so I add "!/usr/bin/env python2" shebang to my sources to explicitly call Python 2. There is even a special Python launcher for Windows that parses that shebang. I commit my scripts to Bitbucket, test everything works and the next day I discover that everything broken on Debian, because there is no python2 there now. -- anatoly t. -- 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/CAPkN8xLP6nDy+fAtVL3_+13OiOe6XYz0hL3ZB4gy+=zqxhe...@mail.gmail.com
Re: Please install /usr/bin/python2
On Sun, Sep 15, 2013 at 1:24 PM, anatoly techtonik wrote: > On Sun, Sep 15, 2013 at 12:55 PM, anatoly techtonik > wrote: >> On Sat, Sep 14, 2013 at 7:25 PM, Scott Kitterman >> wrote: >>> The only suggestion I can make is that it's generally not that hard for new >>> code to make it work for both python2.7 and python3.3. >> >> I do not agree. > > I mean that generally it is hard to say what problems people face when > trying to make the code running on both Python 3 and Python 2. My own > experience shows that testing both is very burdensome no matter if you > port app or start from scratch. Generally you should keep in mind all > differences between both languages and that alone already hard. And as anti-offtopic, writing only for Python 2 has its advantages, and leaving out this option for Debian users now seriously affect future of Debian as a backward compatible Python platform in future. So, I am +1 fpor adding python2 command ASAP. -- anatoly t. -- 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/CAPkN8x++8mTZNznJSNQbp7Q+fawWAhW_X-U9317=4Ya5=04...@mail.gmail.com
Re: Please install /usr/bin/python2
On Sun, Sep 15, 2013 at 12:55 PM, anatoly techtonik wrote: > On Sat, Sep 14, 2013 at 7:25 PM, Scott Kitterman wrote: >> The only suggestion I can make is that it's generally not that hard for new >> code to make it work for both python2.7 and python3.3. > > I do not agree. I mean that generally it is hard to say what problems people face when trying to make the code running on both Python 3 and Python 2. My own experience shows that testing both is very burdensome no matter if you port app or start from scratch. Generally you should keep in mind all differences between both languages and that alone already hard. -- anatoly t. -- 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/capkn8x+qk6qc_7zfdentymjyaxzebuatcwsu94vwq2cswva...@mail.gmail.com
Re: Please install /usr/bin/python2
On Sat, Sep 14, 2013 at 7:25 PM, Scott Kitterman wrote: > The only suggestion I can make is that it's generally not that hard for new > code to make it work for both python2.7 and python3.3. I do not agree. -- anatoly t. -- 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/CAPkN8x+yVDnRnTU2Nq_-+KQbKasGSUSRBqDWbFOQ=qayxiz...@mail.gmail.com
Re: Status of python-central and dh_python
On Mon, Jul 22, 2013 at 1:34 PM, Luca Falavigna wrote: > 2013/7/22 anatoly techtonik : >> Does that mean that helper to build Python packages is finally rewritten in >> Python? > > Unrelated, but yes: To me the fact that replacement for dh_python is written in Python is very much related to dh_python status. Thank for the link. > http://anonscm.debian.org/gitweb/?p=dh-python/dh-python.git;a=tree That's cool. I always wondered what do all these magic commands like dh_python2 actually do. Any chance to include that summary in dh_python* modules docstrings for Debian non-hackers out there? -- anatoly t. -- 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/CAPkN8xJAF+bbN83taNPyqVtsLZJnNM5tLKUQ=F+Ci0DW=gu...@mail.gmail.com
Re: Status of python-central and dh_python
On Sun, Jul 21, 2013 at 10:47 AM, Luca Falavigna wrote: > Hi! > > Just to let you know about some good news regarding the deprecated > python helpers. > > python-central has just been removed from unstable, as you can see in > [0]. The only package still using python-central is gozerbot-plugins > [1], which should be removed from the archive very soon. I'll make > sure python-central will be dropped from Jessie as well, as soon as > all reverse dependencies migrate. > > Also, dh_python is no longer used by any package in debian [2]. A bug > against debhelper has been filed asking to remove dh_python helper for > good [3]. A bug against lintian will be filed as soon as debhelper > will no longer provide dh_python. > Does that mean that helper to build Python packages is finally rewritten in Python? -- anatoly t.
Re: Anybody to package new Bitten version?
On Fri, Oct 14, 2011 at 2:10 PM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : > >> What does this testing implies? If there is a reference document on >> testing - somebody else may do this. This doc should exists even just >> to tell which parts can possibly go wrong as well as history of >> previous problems and mistakes. I'm running unreleased 0.6b3 for about >> 6 months now, and can't remember any problems. >> > > There is no testing method defined or documented. > I just install it and do some builds, that's it. > > > I'd like to see 0.6b3 released first, and then 0.6, because if there >> is problem with 0.6 - you can at least revert to a version that is not >> so old. >> > > Given that the upstream changes between 0.6b3 and 0.6 are > small (if I'm not mistaken), I would leave out this step. > > > I traced the imports and so far haven't found any that require Bitten >> slave to import Trac components. >> > > Same for me. > > > Let's hope for your time to grant you an inspiration to complete this >> quest. >> Thanks. =) >> > > :~) > > Any chances to release Bitten 0.6 before the end of the year? -- anatoly t.
Re: Two binary from one source - how?
On Fri, Oct 14, 2011 at 3:39 PM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> On Fri, Oct 14, 2011 at 2:07 PM, W. Martin Borgert >> wrote: > > ... >> >> The Python thing is to how to generate (and regenerate) these install >> files? I certainly don't want to create them by hand. > > I don't know any automated way to generate install files, > but it is not really difficult to do it manually. These > days I surely will find some time to create them. > >> > You have commit rights, yes? Please feel free to correct this! >> >> Not anymore. They were revoked, because I appeared too dumb to >> understand Build-Depends-Indep meaning for Python packages. > > Hm? Well, I will do the change. While you're at it - current version specification (0.6.final-1) breaks uscan. $ svn-buildpackage --svn-download-orig ... Orig tarball not found (expected /home/user07/bitten-builds/tarballs/trac-bitten_0.6.final.orig.tar.gz) Trying to download tarball using apt Trying to download tarball using uscan uscan warning: In debian/watch no matching hrefs for version 0.6.final in watch line http://ftp.edgewall.com/pub/bitten/Bitten-([\d\.b]+).tar.gz Couldn't find a tarball mergeWithUpstream mode detected, looking for /home/user07/bitten-builds/tarballs/trac-bitten_0.6.final.orig.tar.gz I: mergeWithUpstream property set, looking for upstream source tarball... E: Could not find the upstream source file! (should be /home/user07/bitten-builds/tarballs/trac-bitten_0.6.final.orig.tar.gz) -- anatoly t. -- 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/CAPkN8xKwh-vGAakaFJcjCQGfoBJ9JPA9As2gn=fsnzmzmef...@mail.gmail.com
Re: Two binary from one source - how?
On Fri, Oct 14, 2011 at 2:07 PM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> Nice. But how do you create these install files? Can stdeb tool help with >> that? > > I don't know stdeb, but install files are easyly understood. > See the documenation: > > http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install > > (We're leaving Python related things here, so if you have > more questions, we should move this to debian-mentors or > whatever.) The Python thing is to how to generate (and regenerate) these install files? I certainly don't want to create them by hand. >> The master package description can be improved ,) >> - This package contains the master, which integrates into Trac. >> + This package contains the master implemented as Trac plugin. > > You have commit rights, yes? Please feel free to correct this! Not anymore. They were revoked, because I appeared too dumb to understand Build-Depends-Indep meaning for Python packages. >> I'd keep full package in master package and strip slave to required >> files only. I wonder that will happen with shared files if you install >> trac-bitten + trac-bitten-slave and then remove slave? Is Debian smart >> enough to detect that these files are still belong to another package? > > Files always belong to one package only. That's why I suggested > to put commonly used files into the slave package and let the > trac-bitten package depend on trac-bitten-slave. Alternatively, > common files could be in a "trac-bitten-common" package and both > master and slave depend on it. But in this specific case there > is no advantage in a third package. The variant with trac-bitten being dependent on trac-bitten-slave seems better to me too. -- anatoly t. -- 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/capkn8xkwgtkgrcfyavof+t7d+hzy+y16e3k4i6b9g+nz-7s...@mail.gmail.com
Re: Two binary from one source - how?
On Thu, Oct 13, 2011 at 10:55 PM, W. Martin Borgert wrote: > On 2011-10-13 21:31, anatoly techtonik wrote: >> There is a long standing bug in trac-bitten [1] to make a spin off a >> bitten-slave package from the same source that will include just slave >> client for running builds, which is independent of Trac [2]. Usually, >> you can build bitten-slave with: >> >> python setup.py --without-master install >> >> But how to specify that in debian/rules - >> http://anonscm.debian.org/viewvc/python-apps/packages/trac-bitten/trunk/debian/rules?revision=4711&view=markup >> ? > > You don't have to specify anything in debian/rules! :~) > > Just change debian/control (I just checked in my working copy, > see r7647). However, one has to have one or two install files > in the debian directory. These determine, which files will go > into which package. Nice. But how do you create these install files? Can stdeb tool help with that? > Note: Because master and slave use some Python files in common, > you need these files either in a third package > (trac-bitten-common) or we just keep these files in the slave > package. This only means, that on the master machine also a > slave must be installed, which doesn't hurt size-wise. The master package description can be improved ,) - This package contains the master, which integrates into Trac. + This package contains the master implemented as Trac plugin. I'd keep full package in master package and strip slave to required files only. I wonder that will happen with shared files if you install trac-bitten + trac-bitten-slave and then remove slave? Is Debian smart enough to detect that these files are still belong to another package? -- anatoly t. -- 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/capkn8xk206esd5njvwoz9o66whkwxmpjgkfzhm5thvkhk__...@mail.gmail.com
Re: Anybody to package new Bitten version?
On Thu, Oct 13, 2011 at 9:20 PM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> It's 9 months since the patch to upgrade trac-bitten was committed to >> Debian repository and it's not packaged yet. Can anybody release it? > > Problem is: I can't (currently) test new versions properly - no time. What does this testing implies? If there is a reference document on testing - somebody else may do this. This doc should exists even just to tell which parts can possibly go wrong as well as history of previous problems and mistakes. I'm running unreleased 0.6b3 for about 6 months now, and can't remember any problems. I'd like to see 0.6b3 released first, and then 0.6, because if there is problem with 0.6 - you can at least revert to a version that is not so old. > Second issue: I really want to have two packages: Master (trac-bitten) > and slave (trac-bitten-slave), with the bitten slave not depending on > trac. It's not too difficult, I believe, but without proper testing > (see 1) it will fail. Maybe I can do something in the next days... I traced the imports and so far haven't found any that require Bitten slave to import Trac components. Let's hope for your time to grant you an inspiration to complete this quest. Thanks. =) -- anatoly t. -- 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/capkn8xjgcsgojkx-nn6fgkkr2ctemvb3_4ze4ackwnk1dfb...@mail.gmail.com
Two binary from one source - how?
There is a long standing bug in trac-bitten [1] to make a spin off a bitten-slave package from the same source that will include just slave client for running builds, which is independent of Trac [2]. Usually, you can build bitten-slave with: python setup.py --without-master install But how to specify that in debian/rules - http://anonscm.debian.org/viewvc/python-apps/packages/trac-bitten/trunk/debian/rules?revision=4711&view=markup ? 1. http://packages.debian.org/sid/trac-bitten 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575127 -- anatoly t. -- 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/capkn8xl6axhe3vjv3okwgc0lnvp3pshf-eu-_k+dhpsyw2d...@mail.gmail.com
Anybody to package new Bitten version?
It's 9 months since the patch to upgrade trac-bitten was committed to Debian repository and it's not packaged yet. Can anybody release it? http://anonscm.debian.org/viewvc/python-apps/packages/trac-bitten/trunk/debian/changelog?r1=6417&r2=6416&pathrev=6417 -- anatoly t. On Sat, Jan 1, 2011 at 5:06 PM, anatoly techtonik wrote: > Hi, > > I've sent a patch to trac-bitten package. It was committed into Python > application team repository. What should I do now to make the package > released? > > Please, CC. > -- > anatoly t. > -- 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/capkn8xkfsoycjskrdjoxtmasmg5gupiyts1_u-gj942v3w7...@mail.gmail.com
Anybody to apply Bitten patch (Fwd: Build-Depends-Indep dependencies)
Hi, Can anybody apply this patch to trac-bitten? Seems like everybody who could do this are busy. Thanks. -- anatoly t. -- Forwarded message -- From: anatoly techtonik Date: Tue, Dec 7, 2010 at 5:22 PM Subject: Re: Build-Depends-Indep dependencies To: Bernd Zeimetz Hi Bernd, How is it going? -- anatoly t. On Tue, Nov 30, 2010 at 5:13 PM, anatoly techtonik wrote: > On Tue, Nov 30, 2010 at 4:30 PM, Bernd Zeimetz wrote: >> On 11/30/2010 03:26 PM, anatoly techtonik wrote: >>> On Tue, Nov 30, 2010 at 10:46 AM, Bernd Zeimetz wrote: >>>> On 11/30/2010 09:45 AM, anatoly techtonik wrote: >>>>> On Mon, Nov 29, 2010 at 12:59 PM, Bernd Zeimetz wrote: >>>>>> On 11/29/2010 11:52 AM, anatoly techtonik wrote: >>>>>>>> Of course you are still welcome to update packages, please send the >>>>>>>> according >>>>>>>> patches to me and I'll apply them. >>>>>>> >>>>>>> Please apply this. >>>>>> >>>>>> In most cases you need a minimal version of setuptools, please check >>>>>> that and >>>>>> update the dependency accordingly, otherwise it might happen that >>>>>> setuptools >>>>>> tries to update itself from the internet on buildds - and that will fail. >>>>> >>>>> setuptools dependency is there. It was just moved from >>>>> Build-Depends-Indep to Build-Depends. >>>> >>>> Read again what I wrote please. >>> >>> Sorry. You need to explain to me why setuptools is trying to update >>> itself and fails. I've tested build in clean chroot with pbuilder and >>> everything went fine. It unlikely to be related to >>> http://wiki.debian.org/Build-Depends-Indep, isn't it? >> >> See if there is something mentioned in the setup.py and other files if there >> is >> a minimal version of it necessary. If so, update the version accordingly. >> (it is of course not your fault that a versioned dependency is missing, but >> its >> a good time to think about it now). > > Bitten requires Trac, and Trac includes all necessary dependencies. > The minimum setuptools version required to install bitten-slave alone > (which is not supported by debian packaging) is 0.6a2 - far more > outdated than 0.6c8 available in lenny. I hope there is no need to > specify version dependency in this case. > -- > anatoly t. > bitten.patch Description: Binary data
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 3:10 PM, Bernd Zeimetz wrote: >> Even though the policy doesn't explain what Build-Depends-Indep is, it >> says that Build-Depends-Indep should be present for these Makefile >> targets: >> build, build-indep, binary, and binary-indep >> >> But there are no such targets in trac-bitten debian/rules file, so I >> assume that some kind of autotools is used to execute/supply these >> targets when debian/rules is executed. As a Windows Python user, who >> just want to see new Bitten package in Debian to upload the package to >> production server, I can't really go into the gory details of Debian >> toolchains. It already takes more time than I could allow. > > I don't mind that beginners in packaging have write access to our > repositories, > assuming that they're willing to learn the necessary details during their work > within the team. But as you're neither willing to learn how packaging software > for Debian works, nor you seem to know the necessary basics like makefiles, > I've > removed your write access to the Python teams' repositories. You assumption is wrong, and I'd like to think that the right signal for this outcome here is "Windows" keyword. =) Because: 1. It not that I am unwilling to learn how packaging work, it's that nobody is able to explain the details. If you feel I am wrong - then explain, please, what Build-Depends-Indep was designed for, how it works, what is the real usage, and how its usage conflicts with the policy? 2. I know basics about makefiles, but maybe not the details of your patching systems and autotools. Details of Build-Depends-Indep conflict are buried in the pile of packaging stuff somewhere near the layer of auto build systems. 3. I you feel that I don't know how packaging works - then please improve http://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowToPBuilder so that it will sound like written by someone with knowledge. > Of course you are still welcome to update packages, please send the according > patches to me and I'll apply them. Please apply the patch in attach. -- anatoly t. -- 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/aanlktikhobth7ejeeore9jp4mr1zfolzrwcsn96uk...@mail.gmail.com
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 3:10 PM, Bernd Zeimetz wrote: >> Even though the policy doesn't explain what Build-Depends-Indep is, it >> says that Build-Depends-Indep should be present for these Makefile >> targets: >> build, build-indep, binary, and binary-indep >> >> But there are no such targets in trac-bitten debian/rules file, so I >> assume that some kind of autotools is used to execute/supply these >> targets when debian/rules is executed. As a Windows Python user, who >> just want to see new Bitten package in Debian to upload the package to >> production server, I can't really go into the gory details of Debian >> toolchains. It already takes more time than I could allow. > > I don't mind that beginners in packaging have write access to our > repositories, > assuming that they're willing to learn the necessary details during their work > within the team. But as you're neither willing to learn how packaging software > for Debian works, nor you seem to know the necessary basics like makefiles, > I've > removed your write access to the Python teams' repositories. You assumption is wrong, and I'd like to think that the right signal for this outcome here is "Windows" keyword. =) Because: 1. I am willing to learn how packaging work, but nobody is able to explain the details. If you feel you're better than everybody else in packaging - then explain what is Build-Depends-Indep, how it works, what it was designed for and what is the real usage, and in which parts its usage conflicts with the policy? 2. I know basics about makefiles, but maybe not the details of your patching systems and autotools. There is a big difference in a level of incompetence. 3. I don't think that http://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowToPBuilder could be written by someone who doesn't know anything about packaging. > Of course you are still welcome to update packages, please send the according > patches to me and I'll apply them. Please apply this. -- anatoly t. bitten.diff Description: Binary data
Re: Bitten patch to release new version
On Thu, Nov 18, 2010 at 8:28 PM, Sandro Tosi wrote: > >> What is the further process to get this in Lenny backports? > > first you got to upload to experimental (since a beta it's not the > best version to have in unstable at this stage of the release), I've uploaded it to http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=trac-bitten What's next? -- anatoly t. -- 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/aanlkti=a6daj3w+iyoaky6m2rddyzyzyb8rhssyuy...@mail.gmail.com
Errors with piuparts
Hi, I use pbuilder environment on lenny to test new trac-bitten with piuparts, but the process fails with the broken symlinks error in python-support: $ sudo piuparts -p trac-bitten_0.6b3-1_all.deb -d lenny ... Setting up libjs-jquery (1.2.6-2) ... Setting up trac (0.11.1-2.1) ... Setting up trac-bitten (0.6b3-1) ... Processing triggers for python-support ... 0m34.8s DEBUG: Command ok: ['chroot', '/tmp/tmpg5YLyT', 'apt-get', '-yf', '--no-remove', 'install'] 0m34.8s DEBUG: Starting command: ['chroot', '/tmp/tmpg5YLyT', 'apt-get', 'clean'] 0m34.8s DEBUG: Command ok: ['chroot', '/tmp/tmpg5YLyT', 'apt-get', 'clean'] 0m34.8s DEBUG: Removing /tmp/tmpg5YLyT/tmp/trac-bitten_0.6b3-1_all.deb 0m34.8s DEBUG: Starting command: ['lsof', '-w', '+D', '/tmp/tmpg5YLyT'] 0m35.2s DEBUG: Command failed (status=1), but ignoring error: ['lsof', '-w', '+D', '/tmp/tmpg5YLyT'] 0m35.5s ERROR: Broken symlinks: /usr/lib/python2.4/site-packages/python-support.pth -> /var/lib/python-support/python2.4/.path 0m35.5s DEBUG: Starting command: ['chroot', '/tmp/tmpg5YLyT', 'umount', '/proc'] 0m35.5s DEBUG: Command ok: ['chroot', '/tmp/tmpg5YLyT', 'umount', '/proc'] 0m35.8s DEBUG: Removed directory tree at /tmp/tmpg5YLyT How do you test PAPT packages? -- anatoly t. -- 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/aanlkti=9kjrqquynt7y=6g_h9y_wub+4gehm1lm=r...@mail.gmail.com
Re: Bitten patch to release new version
On Thu, Nov 18, 2010 at 8:28 PM, Sandro Tosi wrote: > On Thu, Nov 18, 2010 at 19:10, anatoly techtonik wrote: >> Here is the patch to release new beta version of Bitten. > > "here" where? :) Oops. Fixed. =) >> What is the further process to get this in Lenny backports? > > first you got to upload to experimental (since a beta it's not the > best version to have in unstable at this stage of the release), and > the policy for backports is to take packages from testing (and this > version won't be there until squeeze is out) but maybe this rules are > a bit relaxed in the -sloppy suite. Ok. Seems like I need to look for a sponsor. -- anatoly t. new.bitten.diff Description: Binary data
Bitten patch to release new version
Hi, Here is the patch to release new beta version of Bitten. What is the further process to get this in Lenny backports? P.S. Check out instructions on using pbuilder with svn-buildpackage. http://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowToPBuilder -- anatoly t. -- 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/aanlktin=-cmebjnmmgdeghhaacrp0ffkbe7yq7ona...@mail.gmail.com
Re: Consistent DPMT and PAPT names
On Mon, Nov 15, 2010 at 9:32 PM, Jonathan Wiltshire wrote: > On Mon, Nov 15, 2010 at 08:29:30PM +0200, anatoly techtonik wrote: >> Why not to choose consistent naming scheme for Python groups? >> Like PMPT and PAPT or DPMT and DPAT? > > Presently they're not easily confused or mis-typed, which is actually quite > useful when you work in both teams. > >> BTW, what are differences in packaging between Application and Module >> - any FAQ links? > > Debian Python Policy? Sections 2 and 3 are modules and applications > respectively. > > http://www.debian.org/doc/packaging-manuals/python-policy/ But these are "programs", not "applications". It's not searchable. Should it be renamed properly? Or should the PAPT be renamed? I still can't find the definition of Python Application. From policy it looks like executable script with a shebang line. There is inconsistency in policy regarding private modules. Section 2 says that private modules should be installed into /usr/share/package-name, Section 3 says they should be installed into /usr/share/module -- anatoly t. -- 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/aanlkti=mpxdvy_wvkr3pwmf9m9t5u=hbadkwrf8jq...@mail.gmail.com
Consistent DPMT and PAPT names
Hi, Why not to choose consistent naming scheme for Python groups? Like PMPT and PAPT or DPMT and DPAT? Maybe also PCPT Python Core Packaging Team or DPCT? BTW, what are differences in packaging between Application and Module - any FAQ links? -- anatoly t. -- 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/aanlktincvql7quzu=ex1nzuacd4gppioilhnmkh8k...@mail.gmail.com
Using svn-buildpackage in isolated environment
Hi, How to build package in chroot environment (I guess that's pbuilder)? I don't want to install build garbage on production server with Debian instance, so I am trying to use pbuilder as described at http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#id538126 $ svn-buildpackage --svn-builder='pdebuild --pbuilder cowbuilder' Complete layout information: buildArea=/home/anatoly/build-area trunkDir=/home/anatoly/bitten-debian-upgrade trunkUrl=svn://svn.debian.org/svn/python-apps/packages/trac-bitten/trunk E: Found unresolved issues: M debian/changelog E: Resolve them manually before continuing Ok. I've added --svn-ignore-new key and it still doesn't work. $ svn-buildpackage --svn-builder='pdebuild --pbuilder cowbuilder' --svn-ignore-new Complete layout information: buildArea=/home/anatoly/build-area trunkDir=/home/anatoly/bitten-debian-upgrade trunkUrl=svn://svn.debian.org/svn/python-apps/packages/trac-bitten/trunk NOT RELEASED YET tag found - you don't want to release it with it, do you? mergeWithUpstream mode detected, looking for (location unknown, guessed: ../tarballs/trac-bitten_0.6b3.orig.tar.gz) Use of uninitialized value in subroutine entry at /usr/share/svn-buildpackage/SDCommon.pm line 35. I: mergeWithUpstream property set, looking for upstream source tarball... Use of uninitialized value in -e at /usr/bin/svn-buildpackage line 457. E: Could not find the origDir directory, please check the settings! What's this mergeWithUpstream mode/property? Why can't it find the tarball downloaded with uscan into parent directory? Why it asks about some NOT RELEASED YET tag when I just want to test the package? How can I do the build inside pbuilder? Can anybody provide manual instructions of what is happening behind the scenes? At least I will have a chance to do build manually, because instructions at http://wiki.debian.org/Teams/PythonAppsPackagingTeam/howto is not enough. Thanks. -- anatoly t. -- 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/aanlkti=g9x6mr6yrrmkmgujtstejwweybxa8fv26v...@mail.gmail.com
Re: I want to help
On Sun, Oct 31, 2010 at 5:19 PM, Andrey Rahmatullin wrote: > On Fri, Oct 29, 2010 at 08:19:36PM +0200, Tshepang Lekhonkhobe wrote: >> > I have a lot of packaging experience for ALT Linux and some experience >> > with Python programming, but no experience with Debian Python packaging (I >> > have some understanding of general Debian packaging). I want to help with >> > Python in Debian, what can I do? >> Looka here: http://wiki.debian.org/Teams/PythonModulesTeam > I've already seen that page butt didn't find any specific tasks. The most useful task would be to write a sane tutorial about packaging for Python folks, who've never seen Debian packaging stuff before. -- anatoly t. -- 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/aanlkti=m6q6oepjnph3c3q-k+cepourp4xxqr55lq...@mail.gmail.com
Re: python sample packages?
On Mon, Nov 8, 2010 at 11:32 PM, Christian Kastner wrote: > Having recently looked at packaging a Java library for the first time, I > found the sample packages[1] provided by the Java team immensely helpful > in getting started: > > [1] http://pkg-java.alioth.debian.org/examples/ > > It would be nice if we could provide a similar service for Python, too. > I added it to my own TODO list, but I fear that I won't get around to it > anytime soon... There was a page called DebianPython/Tutorial to allow people share their starter experience with packaging, but it was removed by Piotr, probably because there weren't many contributions. http://wiki.debian.org/DebianPython?action=diff&rev1=23&rev2=24 -- anatoly t. -- 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/aanlkti=fd7g7btcbhma28kto9quq=qxsuuh=fmukg...@mail.gmail.com
Re: What is anonymous access URL for PAPT SVN repository?
On Mon, Nov 8, 2010 at 9:32 PM, Sandro Tosi wrote: > Hi, > > On Mon, Nov 8, 2010 at 20:27, anatoly techtonik wrote: >> Hi, >> >> I need access to PAPT SVN repository to make a patch. Does anybody know the >> URL? > > $ svn ls > svn://svn.debian.org/svn/python-modules/packages/matplotlib/branches/experimental > debian/ Thanks. I used to http:// URLs for public repositories, but this one is misconfigured, so it just allows to download the repository files itself. Updated http://wiki.debian.org/Teams/PythonAppsPackagingTeam -- anatoly t. -- 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/aanlktimx1ek0ukn8arxgptqew61a=lpdysje7r9ec...@mail.gmail.com
What is anonymous access URL for PAPT SVN repository?
Hi, I need access to PAPT SVN repository to make a patch. Does anybody know the URL? Thanks. -- anatoly t. -- 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/aanlktikln9ye+z9vmewxd_-3+nqfpc7iwpikybrs_...@mail.gmail.com
Researching Build-Depends-Indep (Was: Build-Depends-Indep dependencies)
On Tue, Oct 26, 2010 at 7:18 PM, Bernd Zeimetz wrote:
>>> Of course you are still welcome to update packages, please send the
>>> according
>>> patches to me and I'll apply them.
Ok. I can send you patch right away, but I failed to understand what
Build-Depends-Indep need. Mind correcting my findings below, so that I
can put them in Wiki for future reference?
debian/control
...
Build-Depends - lists all packages required to build the package
('build' target in debian/rules). These packages are also removed when
'clean' target from debian/rules is executed.
Build-Depends-Indep - lists all packages required to build
architecture independent package out of given source ('build-indep'
target in debian/rules).
In practice Build-Depends-Indep is useless, because:
1. If 'build-indep' is present, then 'build' target in debian/rules
should depend on it (and builder that detects this dependency should
fetch all Build-Depends packages anyway) [1]
2. If 'build' target doesn't depend on 'build-indep' target then
'clean' target will leave Build-Depends-Indep garbage, because it
cleans only files produced during 'build' stage [1]
3. The Build-Depends-Indep list could be useful to avoid installing
some dependencies when building architecture dependent packages (that
are built using 'build-arch' target of debian/rules).
But package builders are unable to detect 'build-arch' target, and
therefore it is never invoked [2]
[1] 4.9 Main building script: debian/rules
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[2] http://www.debian.org/doc/debian-policy/footnotes.html#f22
--
anatoly t.
--
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/aanlktikkat0r=h=j=bt=vbtvd6nsud4g6mw_=-xey...@mail.gmail.com
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 7:12 PM, Didier 'OdyX' Raboud wrote: > anatoly techtonik wrote: > >> I know basics about Makefiles - I know that target is and what 4-space >> indents from PEP-8 are unwelcome there. But Debian Policy tells that >> debian/rules should contain build-indep target for > ^^ > >> Build-Depends-Indep, and there is no such rule in trac-bitten. > > Yes. "Should" is not "must". Ok, but then Build-Depends-Indep doesn't make sense without build-indep target. Why it is present in debian/rules in trac-bitten? Another side is that Build-Depends should not be processed, because there is no build target also. But there is trac-bitten binary package, so the build process somehow works. This kind of magic is not explained in debian policy, and I am unable to see how this magic works to tell if Build-Depends-Indep should be dropped. -- anatoly t. -- 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/aanlktimuw-5dadwtaebwwx_o5ygexansyn0hjxaju...@mail.gmail.com
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 7:09 PM, Tristan Seligmann wrote: > On Tue, Oct 26, 2010 at 5:35 PM, anatoly techtonik > wrote: >> many places outdated (email-based bug-trackers, ML without search, > > FWIW: http://lists.debian.org/search.html Cool. Why Python Application Team list is not there? http://lists.alioth.debian.org/mailman/listinfo/python-apps-team -- anatoly t. -- 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/aanlktimsmx1ofy_ngpfpredfhyj81bz8q==znwqr9...@mail.gmail.com
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 3:10 PM, Bernd Zeimetz wrote: > > I don't mind that beginners in packaging have write access to our > repositories, > assuming that they're willing to learn the necessary details during their work > within the team. But as you're neither willing to learn how packaging software > for Debian works, nor you seem to know the necessary basics like makefiles, > I've > removed your write access to the Python teams' repositories. You seem to read it the way you wanted. If I wasn't willing to learn how packaging software works, I've didn't read much about it already and asked some really dumb stuff. Even though I've apologized for the lame question, the thing I asked was quite complicated concept nobody was able to explain so far, and I still expect some on-topic ideas from this discussion. If you are fighting for justice then make an exam to test the knowledge of Build-Depends-Indep and revoke access for everybody who don't understand this. I am willing to elaborate on questionnaire form. =) I know basics about Makefiles - I know that target is and what 4-space indents from PEP-8 are unwelcome there. But Debian Policy tells that debian/rules should contain build-indep target for Build-Depends-Indep, and there is no such rule in trac-bitten. > Of course you are still welcome to update packages, please send the according > patches to me and I'll apply them. Ok. Can you upload edited trac-bitten package for previous version right now, before I send you patch for newer version? -- anatoly t. -- 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/aanlktikpqzo2dff2lkbztu6ebdrxwwt+4h8dvu1px...@mail.gmail.com
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 1:56 PM, Filippo Rusconi wrote: > > in fact, I understand that you are mainly asking for general packaging > practice details. Have you looked at > > http://www.debian.org/doc/maint-guide/ > > which does a fairly good job at explaining the basics of Debian > package preparation, and which is certainly the most appropriate gate > to making correct Debian packages. The size of this doc is about 100kB. The average reading speed is about 200 word per minute or about 1.5kB that will about 1 hour for non-technical text. Maint-guide is full of technical details, there are many references to Debian Policy and other docs, you also want to test examples, lookup unknown terms in Wikipedia, so the reading speed drops from 1 to 3-16 hours per manual (depending on your familiarity with unix). Another problem is that I've read it already several months ago, but I didn't need to understand Build-Depends-Indep and rereading this stuff from scratch is kind of ineffective in the end. So, the idea of the previous paragraph is that there should be another entrypoint that explains meaning to people, who primarily use Python rather than for people who primarily use unix. > Section > > http://www.debian.org/doc/maint-guide/ch-dreq.en.html#control > > will enlighten you about Build-Depends-Indep use. Thanks. I've missed this, it helps a little, but not much. Its first attempt to explain Build-Depends-Indep references to Policy 7.7 (which doesn't explain). The second explanation is "Build-Depends-indep is rarely used" and it obviously doesn't explain anything too. Third attempt tells that Build-Depends-Indep may or may not be used to specify packages with "Architecture: all" if they are not "listed in Build-Depends field to satisfy the Debian Policy requirement for the clean target". This sends to Google for Debian Policy requirement for the clean target, but doesn't explain this requirement. Just one more confusing indirection. > Roughly, one way to figure out if you need to specify something in > that field is to ask yourself these questions in order : > > 1. Is my software dependent on the computer architecture (compiled > source code), or is the source code interpreted so that it will run > unmodified on all architectures ? Well, I don't know if Python bytecode could be run unmodified on all architectures. Can it? But I guess Python packages don't ship compiled bytecode, and pure Python packages can run on "all architectures" as well as on "any architecture". What's the difference? From main-guide Build-Depends-Indep is only used with "Architecture: all", but why? > 2. In case the source code is interpreted (like by the Python > interpreter), is that code (in the form of modules or packages) > requiring any particular software to be built ? If yes, you need to > specify the name (and version, if necessary) of the Debian package > that ships that software. If no, you do not need to fill that > field. One example would be that one particular Python library would > be required for your building of the software. That would be > platform-independent software, but still you would require, when > building you software that specific package. You describe Build-Depends record - this one is pretty clear, but what about Build-Depends-Indep? > However, please, note that these are general packaging questions which > should be posted on other mailing lists. In order for your questions > to be well received by the Debian community (which is full of people > willing to help), you should really make sure you have read the basic > documents about packaging (not only Python stuff *all stuff* because > packaging software for Debian requires an extensive understanding of > how software works, not just Python scripts : any software). I understand that I need to read all the stuff and there are specialized lists. The problem that I feel depressed going through this book pile just to be able to bump a version number in small Python package I support in my free time. This is what I'd like to see changed if you want more useful packages in Debian like I do. > A list of useful developer lists is located at > http://lists.debian.org/devel.html, along with an easy subscription > system. ..no search and a lot of spam. =) > Finally, just a suggestion : do not state that you do not want to do > this and this and that learning this and this is not useful... That > kind of behaviour will call for sarcasm from Debianists, precisely > because they became Debianists by not thinking the way you did in a > previous mail. There wasn't so much text back in time, Python folks don't have to use Ubuntu, and Ubuntu didn't encourage people to contribute to Debian first. Back in time there wasn't so many things going on, so you can spend weeks studying exciting Debian infrastructure. I am not skipping rules that everybody is forced to obey - I just don't understand some things that are not clearly explained, and if it causes sarcasm i
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 11:28 AM, Sandro Tosi wrote: > On Tue, Oct 26, 2010 at 10:16, anatoly techtonik wrote: >> On Tue, Oct 26, 2010 at 10:40 AM, Sandro Tosi wrote: >>>> Sorry for the lame question, but I couldn't find an explanation of >>>> difference between Build-Depends and Build-Depends-Indep in Debian >>>> manuals. Can anybody explain when Build-Depends-Indep is required? >>> >>> look it up on Debian Policy - and questions like this should be sent >>> to debian-mentors: there's nothing python specify here. >> >> I expected smb. to tell me that Python applications doesn't need >> Build-Depends-Indep, because ... > > and I expected you to use google, find what b-d and b-d-i are, try to > understand what's their use-case and in case of doubt ask here (if > it's a strictly python question) or on debian-mentors (if it's a > general questions) - unmatched expectation it seems. I used Google to find http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps It doesn't explain the terminology. > Ah, you can also look at what other packages does - it's a very good > way to learn "how to package". I'm already trying to understand the packaging of trac-bitten - that's why these questions. >> Now I ought to educate myself about autotools, makefiles and all that >> low level stuff that I don't really care about when writing in Python. >> There are good chances that I won't do this, and as a result won't be >> able to help you in maintaining. > > ahah nice try - f.e. why would you need to "educate" yourself about > autotools? it's a non sequitur from b-d vs b-d-i question: care to > explain? Because from Debian Policy I understand that Build-Depends-Indep affects some rules in debian/rules. This file is a Makefile. I remember that Makefiles in *nix systems were usually produced with some kind of autotools. Even though the policy doesn't explain what Build-Depends-Indep is, it says that Build-Depends-Indep should be present for these Makefile targets: build, build-indep, binary, and binary-indep But there are no such targets in trac-bitten debian/rules file, so I assume that some kind of autotools is used to execute/supply these targets when debian/rules is executed. As a Windows Python user, who just want to see new Bitten package in Debian to upload the package to production server, I can't really go into the gory details of Debian toolchains. It already takes more time than I could allow. -- anatoly t. -- 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/aanlktikrlrtqym37miqbnlce3irxettgfn9jj3fom...@mail.gmail.com
Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 10:40 AM, Sandro Tosi wrote: >> Sorry for the lame question, but I couldn't find an explanation of >> difference between Build-Depends and Build-Depends-Indep in Debian >> manuals. Can anybody explain when Build-Depends-Indep is required? > > look it up on Debian Policy - and questions like this should be sent > to debian-mentors: there's nothing python specify here. I expected smb. to tell me that Python applications doesn't need Build-Depends-Indep, because ... Now I ought to educate myself about autotools, makefiles and all that low level stuff that I don't really care about when writing in Python. There are good chances that I won't do this, and as a result won't be able to help you in maintaining. -- anatoly t. -- 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/aanlktikchmejfsoes0be112_baaaempxeki8vos0k...@mail.gmail.com
Build-Depends-Indep dependencies
Sorry for the lame question, but I couldn't find an explanation of difference between Build-Depends and Build-Depends-Indep in Debian manuals. Can anybody explain when Build-Depends-Indep is required? -- anatoly t. -- 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/aanlktiktmx1v5ufl6lk-6gjcatpzaorudmjo06ngw...@mail.gmail.com
PAPT ML is flooded with spam
What is the point in the PAPT ML that is full of spam? http://lists.alioth.debian.org/pipermail/python-apps-team/2010-October/thread.html Should it be moved from Alioth to lists.debian.org or just redirected here? http://lists.debian.org/debian-python/2010/10/threads.html -- anatoly t. -- 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/aanlktin2lzy7fjjuzb02_mjlsytgq9_ncyuma-jc7...@mail.gmail.com
Re: dfsg suffix
Got it. Thanks. One last question: Can I upload the new version of a package what doesn't contain any upstream changes? I want to see how added debian/watch is picked up by various package management tools. -- anatoly t. -- 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/aanlktimrquo1fhdwpls9dakwdkhpwn4pofa2zwoxo...@mail.gmail.com
Re: dfsg suffix
On Mon, Oct 25, 2010 at 8:47 PM, Chow Loong Jin wrote: > On Tuesday 26,October,2010 01:45 AM, anatoly techtonik wrote: >> What dfsg suffix in package version is for? >> In trac-bitten to be exact. > > It means that the tarball was repacked to meet DFSG[1] requirements. > > [1] http://www.debian.org/social_contract#guidelines Does that mean that I need to figure out why tarball was repacked and manually repack it again with the same changes to do new release? -- anatoly t. -- 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/aanlktinonyxdd1evxkt3oa8wzsenv5nzwmjfvf13r...@mail.gmail.com
dfsg suffix
What dfsg suffix in package version is for? In trac-bitten to be exact. -- anatoly t. -- 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/aanlkti=hbnxh64obf+2nrhd+kwxgnobagh4zuzfjt...@mail.gmail.com
Broken post-commit hook
Hi, When you commit changes to SVN, the post-commit hook fails with error. Sendingdebian\changelog Sendingdebian\control Adding debian\watch Transmitting file data ... Committed revision 6210. Warning: post-commit hook failed (exit code 13) with output: Error opening cache: Permission denied I know it is not critical, but still affects Debain image. -- anatoly t. -- 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/aanlktiks6wdznwt--lp_peg-cr+vebvpcoofr8xsm...@mail.gmail.com
Wrong SVN URLs at Alioth page
Hello, The Alioth page lists wrong paths for SVN repositories: https://alioth.debian.org/scm/?group_id=30714 -- anatoly t. -- 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/aanlkti=vfcz4gvjw=8m7yzxy=5jrm9+qxea2y1gfd...@mail.gmail.com
Re: Python talks at DebConf
2010/5/11 Piotr Ożarowski : > > Why am I mentioning Ubuntu at all? Because all decisions about Python in > Debian are made there. > > Do you still want me to answer your questions or is it clear already why > I am acting as an asshole? I can't see an asshole action so fat. The thing that troubles me is that there is some conflict between Ubuntu and Debian and it affects developers like me that not only have to care about intricateness of Python packaging, but also about Debian/Ubuntu stuff. -- anatoly t. -- 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/aanlktilxvkf23jrheiwyrxdxs_nfyqo-yxtfamfi_...@mail.gmail.com
Re: Python talks at DebConf
On Tue, May 11, 2010 at 9:57 PM, Sandro Tosi wrote: > > Indeed, that's what we expect from the python maintainer: > > - understand what changes between to major release > - prepare a draft for the transition, checking packages that brake > (reporting bugs and hopefully patches) > - get consensus from the project (release team for formal ACK on > starting the transition and from python community to support the > transition with uploads and so) > > none of that has happened in the past. > >> Why is upgrading to a new default Python so difficult, more than 19 >> months after 2.6 was released? > > because we have a quite "original" python maintainer, that doesn't > care at all about Debian. > > On the other hand, he does care (to a certain point) about Ubuntu > using the latest python version possible, of course not handling all > the problems that that version can cause. > > Ah, just for the sake clarity: the Debian and Ubuntu python > maintainers are the same person. It is easy to blame one person. Let's say Debian doesn't have any Python maintainers at all and the person from Ubuntu has to do the job. Anyway, it is a fail of Debian to provide a workflow that a person (or a group of people) is capable to follow to make us (Python folks) happy about maintaining Debian servers that host our Python applications. >> Is the problem using an old version of a package while the more recent >> upstream versions have already fixed the compatibility problems? > > yep, sometimes, but there are also new upstream release that drop > support to a version to add support to a newer one, and we have to > support them both. You need a Debian compat Python layer then. Look at SCons for an example. >> I apologize if all this has already been discussed, but I hope that > > no problem. Me should apologize too. >> the future transition to 2.7 and eventually to 3.x could be less >> labour-intensive than the one to 2.6. > > Well, we hope several things will change on the python side of Debian; > let's see if our dreams will come true. Do you have a roadmap to see if this hope should be shared or abandoned? -- anatoly t. -- 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/aanlktimoxg_cywioydwen01x-kyxpwlkdpfkcfm5z...@mail.gmail.com
Re: Python talks at DebConf
2010/5/10 Piotr Ożarowski : > > I had to explain many times (mostly to Pylons users) why packages not > touched by Ubuntu developers are not working on Ubuntu, I know the pain. Why...? -- anatoly t. -- 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/aanlktilqtm1bzhq_1jrqhdmctam8g2wt0wdwzvdtu...@mail.gmail.com
Re: Python talks at DebConf
On Mon, May 10, 2010 at 2:23 PM, Piotr Ożarowski wrote: > > Why I think derivatives should not add new versions? > * because it's mostly chasing numbers - I'm pretty sure there are not > more than 10 packages that require Python >= 2.6 and are not easy to > port to 2.5 in Ubuntu 10.04, Backporting is a waste of time, Python 2.6 adds new tasty useful functions that I use for my packages and do not want to support Python 2.5. I won't add them to Debian, because: 1. No Python 2.6 2. I still do not know how 3. Non-Python toolchain is obscure 4. I do not feel like to wasting time learning Debian Policy Tomes 5. I already know virtualenv > * because when you have to convert hundreds of packages, without > checking them carefully (most packages in Ubuntu don't have maintainer > assigned to them) you end up with "fixes" like: > - disabling tests, Which tests can fail on newer Python versions? I though newer Pythons are backward compatible, except Py3k. > - breaking perfectly valid XS-Python-Version or debian/pyversions, Sorry, I am not DD. What is this perfection for? > - hardcoding "-I /usr/include/python2.6" in debian/rules (yes, 2.5 was > still in supported when I saw it) > or no fixes at all (>100 packages that FTBFS, ignoring broken > XS-Python-Version or debian/pyversions, packages that build > correctly, pass all tests... and do not work[1]), Looks like a major failure of Debian to be a common base for derivative distributions for Python apps. > * because new version often means changes in helper tools (cdbs, > debhelper, python-central, python-support) and you're risking the > situation where we will not like your implementation and will rewrite > them in incompatible way (and that will mean you will have to rewrite > them again), That's why helper tools should be Python based and crossplatform, like the Python itself. -- anatoly t. -- 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/aanlktik50jnr1irx5go15m0znilqmxrce_nr9-mrj...@mail.gmail.com
Re: Python talks at DebConf
On Sat, May 8, 2010 at 11:51 AM, Emilio Pozuelo Monfort wrote: \>> 80kb of duplicated >> code (even 8Mb) doesn't worth wasted time for troubleshooting in 2010. >> It may be a reason for security, but why not just let packages >> register their used version in Debian registry and track it there? > > Because if there's a security hole in that code, you would need to make a lot > of > DSAs (see the recent problem with expat that was embedded in a lot of places). What's wrong with contacting upstream about security holes in their applications due to wrong libraries shipped? Shouldn't Debian collaborate with upstream sources that make this system so popular? Or the aim is to make DD jobs easier - "let's Debian be secure and do not care about upstream". The typical scenario (a source of all my rants) - jQuery bundled with Trac. Do you really think Trac developers should not receive notification from Debian if there will be a security bug in it? Do you think they should monitor the status of jQuery library themselves along with a couple of other python modules? > That's even worse than statically linking, since those embedded copies are > forks > of their original upstream many times. Something tells me and "static linking" is offtopic in this ML. -- anatoly t. -- 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/aanlktimig61jzstj_igla3oqwffu5bavqfywkypsv...@mail.gmail.com
Re: Python talks at DebConf
On Sat, May 8, 2010 at 1:58 PM, Jakub Wilk wrote: > * anatoly techtonik , 2010-05-08, 07:16: >> >> Cover stdeb (anything else?), the reasons (if any) political and >> technical, why it (or anything else) can not be used instead >> unpythonic and unfamiliar make/debhelper stuff. It is not really >> helper if no one understands how it works, and it is confusing for >> non-C folks. > > The premise of your implication is false. Please translate to simple English. -- anatoly t. -- 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/aanlktimoziizu3kbpqw0qdxkwbx478feehbgm86zh...@mail.gmail.com
Re: Python talks at DebConf
One more thing for "Python Policy 2010." Status quo with examples. Trac comes with jQuery suitable for this version of application. But Debian policy dictates to remove duplicated code, so jQuery is replaced with some other version rather than required. This creates problems with plugins and Debian email based tracker really suxx at reporting problems with plugins from trac-hacks that were not ported as packages (email based trackers suxx as a class). 80kb of duplicated code (even 8Mb) doesn't worth wasted time for troubleshooting in 2010. It may be a reason for security, but why not just let packages register their used version in Debian registry and track it there? BTW, on Windows I have tree 2.x Python versions installed and all three are used even though only one is default. But there is no Python2.6 even in backports on Lenny and I need it for python-expect, to automate my stuff. This also requires explanation to refer people when they ask. -- anatoly t. -- 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/aanlktin3vt2vxilh0wvyxqnbd7dqelr1su94epmtm...@mail.gmail.com
Re: Python talks at DebConf
On Tue, May 4, 2010 at 11:20 PM, Richard Darst wrote: > > I was looking through the talks submitted to DebConf, and noticed > there weren't very many Python related talks. Given the amount there > is to discuss related to Python in Debian, it would be great to see > some more submissions. > > Perhaps the list can suggest some talks and we can nominate some > people to lead them? At least we should have a talk on Python > packaging and one on packaging helpers. Perhaps there could be talks > on the DPMT or PAPT. Any more ideas? Only ideas. "Using Python toolchain for Python modules/apps in Debian?" Cover stdeb (anything else?), the reasons (if any) political and technical, why it (or anything else) can not be used instead unpythonic and unfamiliar make/debhelper stuff. It is not really helper if no one understands how it works, and it is confusing for non-C folks. "Ubuntu, Debian and Python packaging." Why the difference? The consequences. "Python policy 2010." Why not use virtualenv for Packaging applications? Why stable Python packages should still be fetched from backports (Trac)? How to use stable Python product compiled manually and still have an automatic option for upgrade when official backport for the same version is released? How to customize/patch local installations of Python packages and sync them with upstream? (MoinMoin patches, Trac Hacks, Roundup tweaks etc). "Python 3000" Any speakers? -- anatoly t. -- 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/aanlktinmdz74hzzhyhl05ougyucx-r0poxsb8zoqr...@mail.gmail.com
Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
On Tue, Apr 20, 2010 at 3:19 AM, Lino Mastrodomenico wrote: > Given how much work is required to change the default Python, does it > make sense to just skip Python 2.6 and use 2.7 as the default Python > version in Squeeze? Does that mean that Debian could then be called a "modern operating system"? No wy. =) Although between 2.6, 2.7 and Python 3k, 2.7 seems a reasonable choice for development in 2010/2011. -- anatoly t. -- 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/y2md34314101004290932ud822076fq7a1becbde9806...@mail.gmail.com
Re: Trac wrong plugin names.
There is a bug report to track the issue at http://bugs.debian.org/562963 I've created patch for Trac 0.11, but because I work on Windows and Debian toolchain doesn't work on this system, it is impossible to make a package with updated patches to test right now. However, I'll be more than happy if somebody can point me to the latest tutorial on updating patches for python packages in Debian, so I can try something over SSH (seems like Trac package uses dpatch). -- anatoly t. On Mon, Dec 28, 2009 at 11:33 PM, Christoph Egger wrote: >> > >> >> Now I still have >> >> AccountManager named "urwid" in Trac Admin panel, but I do not even >> >> want to repeat this awful SSH experience. >> > >> > I have the same problem (wrong Python package names as names of >> > Trac plugins in the admin panel) sometimes, but I don't know what >> > the cause is. Any idea? (But I don't think, it's in any way >> > related to JavaScript nor jQuery...) >> >> Finally decided to change topic as this time it has nothing to do with >> jQuery. >> It's probably a conflict between setuptools and Debian packaging (i.e. >> setuptools vs python-central), because manually installed plugins from >> my environment are ok. >> >> What about switching to python-support and see if it solves the problem? >> >> -- >> anatoly t. > > I'm seeing it with trac-graphviz, which is python-support as well. > > Regards > > Christoph > > -- > /"\ ASCII Ribbon : GPG-Key ID: 0xD49AE731 > \ / Campaign : CaCert Assurer > X against HTML : Debian Maintainer > / \ in eMails : http://www.debian.org/ > > http://www.christoph-egger.org/ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCgAGBQJLOSREAAoJEKv/7bJACMb5hAMP/3Mip/D/6FTxseNSuBd/Ta6T > Q5gqa9WjW2iJCnYldo/vcLzfl8qaOINLOymX2PYH2Hlg/MnaejM24EhR7n4jmBr0 > LxNIznkhgjY+fP1171zLNP8qj1PjwTuMHJPl24Vm2CZmGimkemvT26Y49L/+Ls8P > a9F6Csfxni6M6WymbvjYn+EriBHe59N4UapKkD4uSF9LREqobu87N65akQsMTiXV > cdDSsm4GMtCYR3GOX6S3d6SLiS/owFNkgjkztDLpdSLHehcVhN6yB8y9SH4kBGt4 > jvpdWZV5WyECgarD/2jGSnRoAXGA5dSR1R/k10N3iHKfpMkmIltN03PYQS3LrPXo > ByDvYYE4d0wtcLreKpObLxjTy1yjidRksmDcoaS1R1mhg51c0Uxn/mV5G60+BTEa > 2Rs3OvYxS79lpzxWPZZv0qti9l/2yUDczqSLB6/cJNZRF/0hbA5MfWr49V825f7I > eLBp8FWBaV7uWvp1gYHfjZrTWq616YZjTCOi9mhbZB3VfTz/lIGWjRvro4ED4gx3 > 9NsYF1fVBmP6tWJ/40uH+xfazCX0SunVz1OdYR3557BgSuwDTHFlTA23teFW4L/S > XSZOoNZwTTnsvLM3x+3RHHZd7nusYBlUHMQ3DSR6/mW7oFba7czLew0vi7IaMkRj > K2laPYNK9iia7MEE1JDq > =eqyQ > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How do I know if my package is 'arch-all' or 'arch-any'?
>> On Tue, Dec 29, 2009 at 11:48 PM, Iustin Pop wrote: >> > >> > People who are creating/maintaining packages should start by reading >> > the general packaging documentation, which explains these. >> >> Python package maintainers do not need to learn all that irrelevant C >> stuff they have no idea about. They need minimum required information >> explaining how their software should be packaged and why. > > Iustin is correct: a Debian package maintainer needs to be familiar with > the general packaging documentation. I do not argue. I just want to say that for people with Python background this information should be structured in different manner omitting various irrelevant and confusing details. > You are free to learn what you want to learn, and ignore what you want > to ignore, of course. But that doesn't mean you get to skip the > essential packaging documentation if you want to be a Debian package > maintainer. That *is* part of the minimum required information. Ok. I may be wrong. Do you have a list of literature for people who want to become a maintainer of Python package? Preferably in an order for zero Debian student who have read chapter "Distributing Python Modules" from Python Manual. I will be happy to put it on wiki and refresh my knowledge. On Wed, Dec 30, 2009 at 2:39 PM, Josselin Mouette wrote: >> >> Thanks! How about updating python-support README with these comments? >> Something makes me think that most Python people who are the primary >> readers of this text don't really know what is "arch-all" or >> "arch-any". > > You have to be kidding. > > Especially, a more Python-oriented description (talking about th > difference between pure-Python modules and C extensions) is already > included in this file. But it doesn't describe what is 'arch-all' or 'arch-any'. Perhaps I want too much - simple instructions with all gory Debian details explained. Maybe putting README to wiki will help hyperlink unclear sections to relevant parts of Debian general packaging documentation? -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How do I know if my package is 'arch-all' or 'arch-any'?
On Tue, Dec 29, 2009 at 11:48 PM, Iustin Pop wrote: > > People who are creating/maintaining packages should start by reading the > general packaging documentation, which explains these. Python package maintainers do not need to learn all that irrelevant C stuff they have no idea about. They need minimum required information explaining how their software should be packaged and why. >> > HTH! >> > >> > PS: debian-mentors is probably the best list for questions, that >> > are not directly related to Python. >> >> You can't say it is not related to Python! And subscribing to yet >> another mailing list is painful unless it is a Google Group. > > With all due respect, these are basic packaging terms that are not > Python specific at all. Let's call it "Debian Packaging for Python Developers" and update definition a bit. I rely on your elaboration from Python side of things. arch-all: Debian flag for packages that work on all machines out of the box and don't require compilation to produce binary packages. All pure Python modules fall into this category. Purpose: unknown. arch-any: Crossplatform Debian Package that requires compilation to produce binary package. In Python world that usually means the package contains extension modules, i.e. written in other language, e.g. C. Why this flag exists and obligatory (isn't it?) is also unknown. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Trac upgrade documentation (was: jQuery dependency for Trac 0.11)
On Tue, Dec 29, 2009 at 6:10 PM, W. Martin Borgert wrote: > > There is an open bug report anyway, that suggests and > "trac-admin upgrade" to be done automatically on every > upgrade of Trac. This is technically too difficult to solve, > because one never knows which environments exist (they > might not even be available at package upgrade time). Again, > this is sth. that should be documented clearly. If environments are created with trac-admin init, it is possible to patch it to record their locations and check if these locations exist at upgrade time. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How do I know if my package is 'arch-all' or 'arch-any'?
On Tue, Dec 29, 2009 at 11:01 PM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> python-support README [1] contains different instructions for >> 'arch-all' and 'arch-any' packaged. How do I know which one is mine? > > all: Package works on all architectures without (re-) compilation, > e.g. a program written in Python > > any: Package needs e.g. compilation, but will work on any > architecture, e.g. a library for Python, but written in C Thanks! How about updating python-support README with these comments? Something makes me think that most Python people who are the primary readers of this text don't really know what is "arch-all" or "arch-any". > HTH! > > PS: debian-mentors is probably the best list for questions, that > are not directly related to Python. You can't say it is not related to Python! And subscribing to yet another mailing list is painful unless it is a Google Group. -- anatoly y. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
How do I know if my package is 'arch-all' or 'arch-any'?
python-support README [1] contains different instructions for 'arch-all' and 'arch-any' packaged. How do I know which one is mine? [1] http://svn.debian.org/viewsvn/collab-maint/deb-maint/python-support/trunk/README Thanks. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Mon, Dec 28, 2009 at 4:27 PM, W. Martin Borgert wrote: >> >> Then we should also patch "trac-admin deploy" command so that it >> create symlinks to static resources instead of copies to update user >> environments to latest jQuery automaically. > > I don't remember, I ever used "trac-admin deploy", and I wonder how > useful it is. It saves you from creating one symlink and creating > one WSGI file of typically about ten lines, right? Not only that - these ten lines are not fixed - it records path to the correct python interpreter and path to environment. That makes sure that it will be run with the Python you've run "deploy" with and for which you've probably installed all your plugins. This also important in case of virtualenv. > Maybe it's sufficient to change the documentation of the deploy > command in README.Debian? Like: > > If you prefer copies (which are not updated automatically, even > in case of security issues), use "trac-admin deploy", if you > prefer links, use the following commands: > > $ cp /usr/share/doc/trac/examples/foo.wsgi /my/trac/env/cgi-bin/ > $ vi /my/trac/env/cgi-bin/foo.wsgi # adjust trac env directory > $ ln -s /usr/share/pyshared/trac/htdocs /my/trac/env/ That's not sufficient. To update Trac environment you will need to run "trac-admin upgrade" and optionally "trac-admin wiki upgrade". The second point is that web-servers (including Apache) treat symlinks differently and I am unsure how to setup web permissions correctly if symlinks lead outside of your environment. "deploy" is useful command - it exports web resources that can be configured to be served statically, which should greatly reduce server load by avoiding loading interpreter for serving .png buttons. This is especially true for CGI. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Trac wrong plugin names.
On Mon, Dec 28, 2009 at 3:34 AM, W. Martin Borgert wrote: > >> Now I still have >> AccountManager named "urwid" in Trac Admin panel, but I do not even >> want to repeat this awful SSH experience. > > I have the same problem (wrong Python package names as names of > Trac plugins in the admin panel) sometimes, but I don't know what > the cause is. Any idea? (But I don't think, it's in any way > related to JavaScript nor jQuery...) Finally decided to change topic as this time it has nothing to do with jQuery. It's probably a conflict between setuptools and Debian packaging (i.e. setuptools vs python-central), because manually installed plugins from my environment are ok. What about switching to python-support and see if it solves the problem? -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Mon, Dec 28, 2009 at 3:29 AM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> Then why can't you wait until upstream developers, whose product >> bundles that library, confirm, validate, test and release fix for that >> error in their source package together with release announcement? Also >> in the case of Trac/jQuery. > > Again, many applications have many libraries and tools as embedded > code copies. jQuery alone is used by 58 Debian packages. As I'm > already repeating myself I'll stop now arguing about the issue. > Btw. inside of Debian nor Ubuntu I'm not aware of other opinions > in this matter. But we are not maintaining those 58 packages! When I be designing my own cloud OS I'll make sure to give a special attention to this case. So that when new security fix for enclosed/used library is released, package maintainers receive a warning first. >> Is it possible to create symlink on a symlink? >> (I am on windows right now - can't test) > > Yes. Then we should also patch "trac-admin deploy" command so that it create symlinks to static resources instead of copies to update user environments to latest jQuery automaically. >> That's true. Trac was designed to work even without JavaScript, but >> Trac plugins are written by community and people often assume that >> jQuery is available. > > That's why the Debian Trac package recommends jQuery. In the > default case, it is installed automatically, but you can > explicitly say "no", if you want to. So, if a package is listed in "Recommends:" section it is installed automatically by command line "aptitude install trac"? Didn't know that. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sun, Dec 27, 2009 at 6:56 PM, W. Martin Borgert wrote: > >> 2. Thing to consider. When you create Environment and "deploy" it with >> trac-admin (to generate fastcgi/mod_wsgi scripts) - copies of static >> resources for web-server, including JavaScript won't be updated when >> you fix your security package. Right now nobody handles this, but only >> trac-admin "upgrade" could potentially heal it given it will be able >> to detect old and new jQuery version in user Environment. > > Trac works fine without having such copies. I really would > not recommend this style of installation. Exactly for the > reasons you mentioned. I use symlinks and shared directories. Is it possible to create symlink on a symlink? (I am on windows right now - can't test) >> Martin, you are wrong. >> http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11#NewDependencies >> http://trac.edgewall.org/wiki/TracDev/JavaScript#jQuery > > But trac works perfectly well with any kind of JavaScript. > (I have JavaScript disabled for anything, but some sites.) That's true. Trac was designed to work even without JavaScript, but Trac plugins are written by community and people often assume that jQuery is available. >> Does that mean people won't be able to install Trac 0.12 on Lenny? > > No. It would mean that two libjs-jquery packages would exist in > parallel, one with the latest 1.2, the other with the latest > 1.3 version and that Trac 0.11 could use one, 0.12 the other. That makes sense, but they could not at the moment if I understand correctly? It will require splitting libjs-jquery into libjs-jquery12 and libjs-jquery13 - is that right? > Yes. I fear, we don't have the human power to maintain both > 0.11 and 0.12 in parallel in Debian. OTOH, it would be cool > to have 0.12 in the next Debian release, but of course we > can't drop 0.11 at the moment, as too many people use it. Is that only human power problem? Where the most time will be spent if we play this scenario? > Which plugin(s) exactly did not work with libjs-jquery >= 1.3? > Do you have any further information what the problem is/was? At first it was AccountManager, then I ended up with the necessity of installing TracDeveloper, wasted some time patching Trac code to find the source of the problem. Found that TracDeveloper uses wrong version of jQuery, fixed Apache configuration, restored jQuery, reenabled AccountManager, made modifications to my own plugs. Now I still have AccountManager named "urwid" in Trac Admin panel, but I do not even want to repeat this awful SSH experience. > > Today we will have 30°C, so I will postpone this a little bit :~) > You are lucky. It is a few degrees above the zero, the snow is melting, snowboard is slowly covering with rust, Santa was trapped in mud and stole my sock to change one of his own. Everything is just plain wrong. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sun, Dec 27, 2009 at 6:24 PM, W. Martin Borgert wrote: > > It would be helpful, if you could state the exact problems you > had because of the newer jQuery. Not 100% sure it was only jQuery (can't test this right now) but, for example, I could not drill down beneath the first level in template debugger of TracDeveloper plugin. >> It is not necessary to do the extra job of removing jQuery liver from >> the Trac body at all. The only advantage I see are security patches. >> Anything else? > > Security is only an example. Any kind of error is relevant. Then why can't you wait until upstream developers, whose product bundles that library, confirm, validate, test and release fix for that error in their source package together with release announcement? Also in the case of Trac/jQuery. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unit tests
On Sat, Dec 26, 2009 at 10:17 PM, Ben Finney wrote: > >> Quoting "anatoly techtonik" : >> > Even if most users don't need them, tests greatly increase the value >> > of bugreports and doesn't bloat python packages too much. >> >> True. What do other people think of the issue? > > I think the judgement of “not bloat the package too much” is to be made > with consideration of those users striving for a small system as their > primary concern, e.g. those trying to install onto embedded systems with > minimal storage. Are there any such people here? Do they prefer different package repository with stripped down binary packages like http://wiki.debian.org/Embedded_Debian ? > Also, the dependencies of a package that includes unit tests are > generally greater; a significant amount of Python package unit test > suites require additional packages, e.g. ‘python-nose’, that are not > dependencies for the normal operation of the package. Need more precise statistics. In my opinion 80% use standard unittest and doctest, especially small packages or modules. If there are dependencies like 'python-nose' - they would be optional anyway. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 2:08 PM, Paul Wise wrote: > >> Upstream Trac is shipped with jQuery it needs while leaving Genshi and >> other libraries as dependencies. Debian specific patch removes jQuery >> from Trac distribution even though it contributes only 2% to package >> size. This dependency injection creates aforementioned problems. > > The dependency exists whether or not trac has "Depends: libjs-jquery". This dependency is hidden, encapsulated inside of Trac application. If you see jquery.js file inside of its source package - why not to leave it alone - where is the Policy that requires to replace it with some external copy? Does Policy take priority over common sense if the change may affect application stability? The maintenance work in this case creates more problems than benefits and may be not as appreciated. Coming back to Earth - what security holes are expected from jQuery? What make people think that Trac developers won't release a new version when such important security problem arise? Basically everything you need is to track that Trac includes some version of jQuery to respond to security issues. Possible response could be in creating a patch to include different jQuery version until upstream does the same, but this should be decided on case-by-case basis. You insist on using Debian Package System to pull parts of application automatically, and that requires manually dissecting application into pieces and analyzing dependencies. That's because there is probably no Security Scanner able to detect affected libraries in shipped applications and create security issues automatically. What's the value of Debian then if it takes security over stability with no option to weigh one over other on a discretion of maintainer of dependent package? > Removing the "Depends: libjs-jquery" sounds like the equivalent of > shipping a copy of GTK+ with gnome-terminal. Or a copy of ncurses with > top. Or a copy of glibc with ls or cp. It may sound like if you forget about size ratios of jQuery/Trac=2% and GTK+/gnome-terminal=757% > None of those things are > nessecary, so why should shipping a copy of jQuery with one of the > packages that use it be any different? It is not necessary to do the extra job of removing jQuery liver from the Trac body at all. The only advantage I see are security patches. Anything else? So far the potential security threat from jQuery shipped inside Trac package doesn't worth the time for implementing measures to maintain external dependencies, potential compatibility issues and restriction for having a 1.3.x jQuery on a system with 0.11 Trac. Seems like I finally made my point clear this time. :P >> There are more than 200 plugins tagged for 0.11 on >> http://trac-hacks.org/ They were developed and debugged with jQuery >> 1.2.x which is not forward compatible with 1.3.x I don't feel like I >> want to check if they are compatible next time I'd like to use one. >> 15kBytes doesn't worth wasted hours. > > It sounds like you're installing the trac plugins manually rather from > Debian packages. I'd suggest manually installing jquery 1.2 for the > manually installed plugins that need it and putting the javascript > file at a different URL to the Debian jQuery 1.3 version. If there are > any trac plugins in Debian sid/squeeze that need jQuery 1.2, I'd > suggest filing RC bugs. The problem that Trac is a web application and during web page rendering plugins load and share all available JS code. When JS behaves wrong - it is also not easy to spot. You don't get coredumps or stacktraces or compilation errors. Your DHTML window may not popup as expected, syntax hints may not be displayed, subscription link won't be inserted where it should or hidden form field won't be updated. In most cases you notice a change unless you're a developer of a plugin and won't catch the error unless your users always browse internet with opened JavaScript console. Google Web Toolkit was invented not as some fancy tool for Java guys who want to switch to ajax - it makes even experienced web front end designers skillful in DHTML/JavaScript learn Java. Things in JavaScript are already fragile enough, let's not make them worse. Bugs from broken JS (and there is a lot of JS in 0.12) will be submitted by users to Trac in 95% of cases - not to Debian. Trac developers will be very happy to track bugs down to a wrong jQuery version that by their assumption should correspond to a Trac release. Well, it may sound a little exaggerated, but writing this is nothing compared to the time it took to fix all problems in my Debian Trac installation over sluggish SSH. There is nothing else to add. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 6:01 PM, W. Martin Borgert wrote: > >> I don't feel like I >> want to check if they are compatible next time I'd like to use one. >> 15kBytes doesn't worth wasted hours. > > The issue is not 15 kB, but the problems Debian would have if an > error must be fixed in jQuery (e.g. a security problem). Currently, > around 58 packages depend on jQuery. In theory, each of them must > have their own copy. 1. Trac is not a package - it's an application. If there will be a problem in one of the files that shipped with Trac sources - it is a Trac bug. If in case of globally installed packages dependency analysis is a good (must) thing, then for standalone application autopsies contribute nothing to the quality of Debian releases. I would say quite contrary. In Python world there is a very nice thing called Virtualenv that was invented for Python Applications because global packages create stability mess. 2. Thing to consider. When you create Environment and "deploy" it with trac-admin (to generate fastcgi/mod_wsgi scripts) - copies of static resources for web-server, including JavaScript won't be updated when you fix your security package. Right now nobody handles this, but only trac-admin "upgrade" could potentially heal it given it will be able to detect old and new jQuery version in user Environment. > Trac does not even depend on jQuery, but only > recommends it, because Trac itself does not need jQuery. Martin, you are wrong. http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11#NewDependencies http://trac.edgewall.org/wiki/TracDev/JavaScript#jQuery >> The best solution would be to remove "15_remove_jquery_file.dpatch", > > If it is really important to have jQuery 1.2 around, the best way > would be to ask for a libjs-jquery-1.2 package and let Trac > recommend this package instead of libjs-jquery. Does that mean people won't be able to install Trac 0.12 on Lenny? Consider that when people jump from Trac 0.10 to 0.11 they usually create two instances of Trac before switch and new one usually should be run on the same server. That was true for trac-hacks.org (there virtualenv was used) and that is true with me too, except that I am constrained to use Debian packages and therefore used two Debian servers. Admins would really appreciate an ability to have two Trac major versions on the same server. > Anatoly, please file an ITP or RFP bug against the WNPP[1] > pseudo-package about libjs-jquery-1.2, OK? Set the maintainer of > libjs-jquery in Cc, maybe they will package 1.2 as well. I will > change the dependencies in Trac etc. as soon as the package is in. I fixed it with "aptitude install libjs-jquery=1.2.6" and it works for me. It may be useful for jQuery itself, but for Trac I still do not think it is appropriate to mess with Trac innards if Trac team don't list something as installation prerequisites. In any case the final decision is from maintainers. P.S. There is another reason why I won't fill ITP against libjs-jquery. Sorry for the ignorance, but I still didn't read Debian Bible and ITP, RFP, WNPP and the whole bug-entering process is too way complicated to squeeze into my head at once. It is that it is not as intuitive as web form or something - just have to do some things with Trac and a lot of new stuff to read. Anyways. Thanks for support. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 3:56 AM, Paul Wise wrote: > >> Trac 0.11 ships with jQuery 1.2.6 >> However, Debian patches remove this file in favor of libjs-jquery >> package which contains version 1.3.x >> This breaks plugins for Trac 0.11 that rely on 1.2.x jQuery features >> removed in 1.3.x >> >> How to properly add dependency for jQuery<1.3 to trac package? > > jquery 1.2 is only available in lenny, so depending on jQuery<1.3 > would make trac not installable in sid/squeeze (and thus an RC bug). > Talk to Trac upstream about removing the jQuery embedded code copy, > getting the plugins upgraded to jQuery 1.3 and making a new release. Upstream Trac is shipped with jQuery it needs while leaving Genshi and other libraries as dependencies. Debian specific patch removes jQuery from Trac distribution even though it contributes only 2% to package size. This dependency injection creates aforementioned problems. On Sat, Dec 26, 2009 at 7:37 AM, W. Martin Borgert wrote: > Which plugins exactly do not work with jQuery 1.3? There was a complex issue with TracDeveloperPlugin, which solution involved permissions, aliases and mod_wsgi configuration. The jQuery was only a part of a problem and it was not only downgrading that fixed it. There are more than 200 plugins tagged for 0.11 on http://trac-hacks.org/ They were developed and debugged with jQuery 1.2.x which is not forward compatible with 1.3.x I don't feel like I want to check if they are compatible next time I'd like to use one. 15kBytes doesn't worth wasted hours. > How much effort would it take to make them compatible with 1.3? > Note, that Trac 0.12 will ship with jQuery 1.3 anyway... > > In any case, I will document the potential problem in README.Debian > file, so that our users are not surprised (only disappointed maybe). The best solution would be to remove "15_remove_jquery_file.dpatch", "postinst", "prerm" and let Trac developers ship the version that contributes to the official API for Trac extension developers for a given Trac release. P.S. Given the above I'd reconsider "Python Application" concept from just "a big chunk of code" to isolated set of libraries/modules that creates stable virtualenv for an application, which is constructed using Python dependencies recommended by upstream. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
jQuery dependency for Trac 0.11 should be < 1.3
Hello, Trac 0.11 ships with jQuery 1.2.6 However, Debian patches remove this file in favor of libjs-jquery package which contains version 1.3.x This breaks plugins for Trac 0.11 that rely on 1.2.x jQuery features removed in 1.3.x How to properly add dependency for jQuery<1.3 to trac package? Thanks. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unit tests
On Fri, Dec 25, 2009 at 6:01 PM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> Python policy is silent about unit tests. Should they be stripped? Or >> should they be Debianized or left as-is? > > Just my opinion: Unit tests should be in the source package, but not > in the binary package. Most users don't need them, and if somebody > wants to try them, they can easily fetch the source package. Even if most users don't need them, tests greatly increase the value of bugreports and doesn't bloat python packages too much. > Btw. What's wrong with trac-accountmanager? It does work for me. Nevermind. I've forgot to enable it in config when switched from local .egg to global version installed with aptitude. Now I'm struggling with TracDeveloper plugin that doesn't want to drill down data in template debugger. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Unit tests
Hello, I'm having some troubles with trac-accountmanager package and want to execute its unit tests to see if they could catch anything unusual, but it appeared that they were stripped from the package. Python policy is silent about unit tests. Should they be stripped? Or should they be Debianized or left as-is? Merry Christmas, -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final updates for this Python Policy revision
Given that people are tired of discussing things they've already decided for themselves I CC this to debian-legal. On Sun, Dec 13, 2009 at 11:11 AM, Ben Finney wrote: > The Debian policy is software with source code: the DocBook source document. It is not clear why GPL notice doesn't stay in the source then and instead appear in "binary form", but it seems ok. BTW, where is the link to Debian Python Policy source in http://www.debian.org/doc/packaging-manuals/python-policy/ ? Shouldn't it be mentioned in documentation? >> 1. What am I free to do with with GPL'ed policy text? > > View it, examine its source code, modify it, and/or redistribute it > under the same license terms. >From your words it sounds like I can do just anything about it - remove authors, sign under my name and sell for a big money without distributing source code. Is that right? >> 2. Are you sure about that? > > Yes. The GPL grants those freedoms. >> > What specific problems do you see from choosing the GPL for a work, >> > and why should those problems concern us in this case? >> >> One specific problem is that nobody understands what do you mean when >> releasing something that is not software under GPL. > > The Debian policy is digital information, therefore it is software (as > opposed to hardware). > > Perhaps you mean “something that is not a program”. I mean that "documentation for software" is not software itself.Software can render documentation or process it. Documentation can be printed and still remain documentation. Software is not. >> It can simply be deemed invalid in court and usual copyright rules >> apply. In this case it can be sought like the freedom authors choose >> to express their opinions about what did they meant later. You do not >> license for that. > > I don't know what would lead you to think the GPL would be deemed > invalid for the Debian policy more than any other software work. Considering your argument that policy source is DocBook and .html is "compiled binary software" I am beaten. However, most people won't get that without lengthy discussion. >> I still have no idea why Policy authors have chosen GPL > > Perhaps, then, you should not assert they have chosen the GPL blindly. I still can't see the reasons why they couldn't choose GPL blindly. At the time when original author was forced to choose license there could not be other choice. All others are just followed. Now there are many more clear suitable licenses, that's why I ask. Maybe authors would like to choose non-copyleft license at all? > Now, in the absence of a specific problem with applying the GPL to the > software work that is the Debian policy, I don't think there's any more > need to call for changing it. While nobody understands what does it all mean, let's leave it alone. =) -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final updates for this Python Policy revision
On Sun, Dec 13, 2009 at 12:41 AM, Christoph Egger wrote: > anatoly techtonik schrieb: >> >> Questions like "Debian Python Policy is all about GPL. Do I have to >> release my Python package under GPL?". Most people (as you clearly >> expressed) don't care, so upstream maintainers would just avoid Debian >> packaging and let it do by someone else. > > CC-By-Sa as you have suggested is a copyleft license as well so why > would one not ask "Do I need to publish my python stuff now under > CC-By-Sa" if one isn't sure about GPL? Because CC-By-Sa doesn't mention word "software" and doesn't try to argue with common sense trying to tell that "software documentation is software itself". I chose CC-By-Sa as a closest alternative to GPL, but Debian Policies may permit non-copyleft licenses as well. > And having read both licenses I > fail to see where the CC license is easier to read (in the relevant > legalcode) as the GPL CC has authoritative human-readable summary that is just 1k long and easy to spot. It is just what 95% of people need to answer their questions. GPL doesn't have such summary, so you either need to study 17k lawyers spell by yourself or seek the truth from biased comments on the web. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final updates for this Python Policy revision
On Sat, Dec 12, 2009 at 4:56 PM, Adam wrote: > This is a topic for debian-legal not debian-pyhton. Discuss it with them > (after looking at the archive), as they are the experts. If there are > problems (= results) that can be brought here again. The point is to make Python Policy clear without additional consulting from Debian lawyers. I understand that most of us do not want to deal with these issues, but it will only do good if people won't have any questions after reading the policy. Questions like "Debian Python Policy is all about GPL. Do I have to release my Python package under GPL?". Most people (as you clearly expressed) don't care, so upstream maintainers would just avoid Debian packaging and let it do by someone else. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final updates for this Python Policy revision
On Sat, Dec 12, 2009 at 12:22 PM, Ben Finney wrote: > >> The policy is under GPL license which is kind of ridiculous to prevent >> citing Debian Policy in private talks. > > Why is it ridiculous? Is it any more ridiculous to put a policy document > under GPL than any other document? It is in the same ridiculous for other document. It is ridiculous in the way people want to hide, skip or complicate things. GPL clearly doesn't suit "works" that are not binary, nor source code, that are organized for storage in classic real world libraries. GPL text itself is rather big for comprehension and when you try to apply it to documentation it creates too many confusing (philosophical) questions to be useful. FSF created GFDL to address this issue, but it was not compatible with DFSG. http://en.wikipedia.org/wiki/GPL#Use_for_text_and_other_media > I think that any free-software license that the copyright holders choose > is fine for this work. Copyright holders are free to choose anything they want. It may not even make any sense. The criteria is simple. Can you answer the two questions below? 1. What am I free to do with with GPL'ed policy text? 2. Are you sure about that? I can't answer positive about the second one, and I suspect that nobody can. > Why do you want specific justification for choosing the GPL? Just because I believe it is chosen blindly. Why do you need policy license at all? If it is decided to limit the usage of this text - it can be said more clearly - "attribution required", "commercial usage is not permitted", "derived works are allowed". > What specific problems do you see from choosing the GPL for a work, and > why should those problems concern us in this case? One specific problem is that nobody understands what do you mean when releasing something that is not software under GPL. It can simply be deemed invalid in court and usual copyright rules apply. In this case it can be sought like the freedom authors choose to express their opinions about what did they meant later. You do not license for that. >> What about http://creativecommons.org/licenses/by-sa/3.0/ ? > > Are you saying that license preferable to the GPL for this work? How so? I still have no idea why Policy authors have chosen GPL, but if everything they meant was that this work requires attribution and should be distributed under the same license, then CC license says it way much more clearly. >> It is compatible with DFSG > > As is the GPL. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final updates for this Python Policy revision
Hello, The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. I imagine people discussing "those folks at Debian. Have you heard - they've changed you-know-what to make packaging easier". =) Is there any license that more clearly states reason behind choosing the license? Seems like GPL in this case was chosen just because "everything is GPL". What about http://creativecommons.org/licenses/by-sa/3.0/ ? It is compatible with DFSG http://wiki.debian.org/DFSGLicenses#CreativeCommonsAttributionShare-Alike.28CC-BY-SA.29v3.0 Ciao -- anatoly t. On Sat, Dec 12, 2009 at 6:03 AM, Scott Kitterman wrote: > I think we are at the point where the proposed update to the Python Policy is > clearly more relevant and better than what is currently published. Once this > is done, we can work on refinements. Loïc Minier (lool) did attempt to send > the proposed final patch set to the list and it has gotten stuck somewhere and > didn't make it to the list. > > Rather than wait to get that resolved, I'll point you at the git repository > Loïc mentioned earlier: > >> Pushed as git.debian.org:~lool/public_git/python-defaults.git if you >> want to use ssh with an alioth account, or >> git://git.debian.org/~lool/python-defaults.git otherwise > > The only other change I've made is to revert the first hunk of 0026-Clarify- > which-files-are-provided.patch. Once we hit a time where we are both awake, > I'll get git updated. > > I'm preparing an upload of python-defaults to publish this and unless I hear > screams will do it as soon as I can get the package assembled and the > maintainer's blessing (I have worked on this already and don't anticipate a > problem). > > Scott K > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Hello, Now I wish I could find time to write "de-facto" packaging tutorial in wiki to see how the patched policy and original policy is going to solve this real-world problem. Thanks for collaboration. -- anatoly t. On Tue, Dec 8, 2009 at 10:24 PM, Loïc Minier wrote: > [ MFT: debian-pyt...@ldo ] > > Hi all, > > To resurrect the Python Policy as a document reflecting required and > recommended Python packaging practices, we prepared a set of patches. > We started in private to provide a complete set of changes and avoid > flames as much as possible, but now we'd like the whole Debian Python > community to send comments, feedback, or additional patches. > > The goal of this set of patches is only to reflect what's de facto > being done in the archive, and update various bit-rotted sections of > the Python Policy. It's only a first step, but also a prerequisite for > other changes. > > > We hope that once consensus is reached on how to fix the Python Policy > in the python-defaults package, we can propose new series of patches > proposing changes to the Python Policy such as ideas from the "new > dh_python proposal" [1], or Python 3.x support etc. > > Thanks, > > [1] http://lists.debian.org/debian-python/2009/08/msg3.html > > -- > Piotr Ożarowski, Scott Kitterman, Loïc Minier > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkseteUACgkQ4VUX8isJIMD7YQCeIyGvxjxjg0nfsC+xcvJaBpiE > ohAAnR4BarvnITsGUeJYyAAvnTcQCG/d > =hlfn > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MBF: embedded copies of Python modules
2009/11/8 Jakub Wilk : > I am going to file a few dozens of bugs against packages that are embedding > copies of Python modules; more specifically: Do you mean that all these packages need to stick to the stable standard version of some Module available in Debian? I personally think that fit is a bad idea, because by upgrading such Module it is possible to break Python Application that require older version of the Module for its equivalent stable version. How does Debian Policy 4.13 (Convenience copies of code) deal in this case? Is it possible for Python Applications to maintain their own set of "stable" modules independently? For example by building virtualenv upon installation and filling missing dependencies online through custom mirror of PyPi packages with added Debian specifics? -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Work on a current Debian Python policy
On Wed, Nov 4, 2009 at 2:29 AM, Ben Finney wrote: > (I am reading this to mean “the reference version of the Debian Python > policy is in the python-defaults package”.) > > Okay. Clearly one way for this to improve would be for some of those bug > reports to be responded to by the maintainer. > > In the absence of that, though, what other way forward is there? Here. > What > would need to change for the reference version of the Python policy to > be somewhere else? Remove it from http://www.debian.org/doc/packaging-manuals/python-policy/ Remove this page http://python-modules.alioth.debian.org/ (wiki is more up to date) Replace this one with wiki too and remove links. http://python-apps.alioth.debian.org/policy.html > Just start referring to a different document, or > something more? Point everything to wiki. Update MoinMoin to remove bugs and enable latest features that can become useful for collaboration. In particular: * Add "subscription by default" feature to policy pages so that everybody who edited page automatically receives updates. This will increase collaboration rate. You may forward these edits here as well. * Upgrade also fixes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546905 so that inserting table of content will not be a compromise between layout and technical limitations -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)
On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman wrote: > > I'm not aware of any ongoing work. I would be willing to help work on such > a thing, but we currently lack a good mechanism for developing/approving > such a policy. With clear policy and precise goal you won't need approving mechanism to see if they work for defined set of cases or not. While everybody want policy just to know how to do thing properly, there are in fact very few people who really understand how complicated is the task of maintaining python code, modules and applications. When there is precise goal, next action is to collect scenarios for the whole install/update/remove lifecycle of Python code in Debian. Only after this step is complete it is possible to start drafting self-explanatory architecture that will be capable to support all these scenarios. There is no need in mechanism for developing a policy - in wiki everybody can start contributing immediately with a full history of changes. There can be a sprint though to force the progress and keep work focused. To make it easier to contribute scenarios a template can come handy. I've edited http://wiki.debian.org/DebianPython to be concise introduction into the problems with Python code packaging, summarized issues with the current policy, but still can't provide vision for a new policy. That's why I'd like to see http://wiki.debian.org/DebianPython/Tutorial with step-by-step instructions and explanations of the reasons why things should be done in some particular way, what problems arise if they won't done as requested, and how it makes maintenance easier. There can be a series of tutorials starting with most basic packaging scenario (one module) and gradually move to most complicated (application with several C-modules installed in virtualenv). There is a difference in Scenario and Tutorial in that Tutorial is based on some policy draft while Scenario concentrates on a very-very source of the problem. I.e. scenario is "As a user, I want some stable version of that Python module to be present for my scripts in my Debian installation" or "As an admin, I want to install Trac in isolated environment and upgrade it separately as security fixes are coming out". -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Backports: Django, web.py, Trac - anyone wants them?
Trac for sure. Is there any _short_ howto about Debian backports for Python folks? --anatoly t. On Mon, Sep 21, 2009 at 2:54 AM, W. Martin Borgert wrote: > Hi, > > for some reasons I need lenny backports of python-django, > python-webpy and trac. Some of the packages I don't need for > "production use", but for automatic testing (using bitten) only. > I could work with squeeze chroots, but probably I will go for > the backports. Now my question: Are more people interested in > having the backports, so I will upload them to b.d.o (but don't > hold your breath), or am I the only one interested? Or better: > Is someone interested in doing the backports? :~) > > Cheers > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: trac maintenance activity?
On Fri, Sep 11, 2009 at 12:52 AM, W. Martin Borgert wrote: > http://packages.qa.debian.org/t/trac.html states > git://git.debian.org/git/pkg-trac/trac.git > > If you like, feel free to try your luck! I would just leave the > git history in git and start with the latest packaged trac > version, but of course I'm not opposed if somebody else does the > work :~) I've decided not to convert git history - it contains a whole Trac checkout from upstream repository and the garbage it provides doesn't worth the value. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: trac maintenance activity?
On Thu, Sep 10, 2009 at 6:45 PM, W. Martin Borgert wrote: > Quoting "Andres Salomon" : > > Yes, trac will be maintained in the Python Application Packaging Team. > I already tried to copy the git history to the PAPT svn, but - lacking > any experience with git - failed. I will now just start with the last > version and for the history people have to look into the git. If you have any experience with Mercurial - you may use convert extension to convert GIT repository to HG first and then merge HG changes back to SVN. There is always Tailor that is capable of converting various repositories into each other. HG to SVN for sure. I may try to do the conversion, just let me know where to get GIT sources (althout HG repository would be better to start with). BTW, when doing test commit an error occurred, and although commit seems to be recorded in repo, the output from server doesn't seem normal. -- cut -- Adding trac\branches Adding trac\tags Committed revision 3715. Warning: post-commit hook failed (exit code 13) with output: svnlook: Write error: Broken pipe Error opening cache: Permission denied -- cut -- -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
On Tue, Sep 8, 2009 at 1:00 PM, Steve Langasek wrote: >> Twas brillig at 02:42:09 08.09.2009 UTC-07 when vor...@debian.org did gyre >> and gimble: > >> SL> Spare me your ignorant preaching and go read the mailing list >> SL> archives. > >> Mailing list archives are not documentation. > > They're documentation that you're wrong. Stop wasting my time. Mailing lists are not documentation. Wiki is some kind of docs, but it still bears a high degree of uncertainty. > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer http://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org -- anatoly t. Random Debian User -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
On Mon, Sep 7, 2009 at 9:49 PM, Mikhail Gusarov wrote:
>
> Twas brillig at 11:37:50 07.09.2009 UTC-07 when vor...@debian.org did gyre
> and gimble:
>
> SL> They were part of the design that came out of the python packaging
> SL> BoF in DebConf 6 that you then proceeded to ignore entirely.
>
> Is this design and rationale written down somewhere? It's hard to follow
> policy which contains completely opaque requirements.
+1 It is impossible to reverse reasons based on initial statements
like "This is used to track packages during Python transitions, and is
also used by some packaging scripts to automatically generate
appropriate Depends and Provides lines."
What is the process of "tracking packages"? Any examples? Even if
Depends and Provides are automatically generated developer still
supply X-...-Python headers manually, so this add nothing more than
another level of indirection with some bit of uncertainty to
maintainer's mind.
Quiting further from
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
-- cut here ---
Your control file should also have a line:
XB-Python-Version: ${python:Versions}
The python:Versions is substituted by the supported Python versions of
the binary package, based on XS-Python-Version. (If you are not using
dh_python you will need to handle this substitution yourself.) The
format of the field XB-Python-Version is the same as the
XS-Python-Version field for packages not containing extensions.
Packages with extensions must list the versions explicitely.
--- cut here ---
It does tell what spell to weave, but does not explain what problem it
is aimed to solve. Is it solely for copying Depends field from source
package to binary?
I do not get some aspects of Python packaging in Debian mostly because
there are many thing that people take for granted (and also because
the lack of time to read out all the stuff). I would be grateful if
you spot any such thing in my point of view and could explain them or
point to the exact place in docs.
Thanks.
--
anatoly t.
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
On Tue, Sep 1, 2009 at 4:16 PM, Dmitrijs Ledkovs wrote: > Recently I have discovered some very nice features of hg that make it > attractive: Mercurial Queues are awesome, but there is one major drawback in Mercurial comparing to SVN - it is impossible to clone a subtree of repository. In SVN you may checkout any path and isolate your work inside. I personally found this feature along with --set-depth option very convenient when working with parts of such big projects as Debian or Python. There is forest extension and experimental subrepository support in HG, but it works like svn:externals replacement. Ciao, -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python-support source repository
Thank you. Next time I'll try to contact directly. I presumed that tools like python-support should have a well-known location somewhere under Python teams repository trees. I've checked all Debian Python projects with no traces of it. SVN/ViewVC links from the PTS page at http://packages.qa.debian.org/p/python-support.html are all broken. Added link to python-support README to http://wiki.debian.org/DebianPythonFAQ Ciao, --anatoly t. 2009/9/1 Josselin Mouette : > Le mardi 01 septembre 2009 à 13:53 +0300, anatoly techtonik a écrit : >> Can anybody point me to the repository location of python-support package? > > It’s in collab-maint : > http://svn.debian.org/viewsvn/collab-maint/deb-maint/python-support/trunk/ > > Cheers, > -- > .''`. Josselin Mouette > : :' : > `. `' “I recommend you to learn English in hope that you in > `- future understand things” -- Jörg Schilling > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
python-support source repository
Hello, Can anybody point me to the repository location of python-support package? Thanks. --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
VCS for Python code Was: Trac team almost dead?
On Fri, Aug 28, 2009 at 2:21 PM, Christoph Egger wrote: > > As my packages have (following trac itself) a git history and the one > I've ITA-ed has some HG history I'm interested in what the team thinks > so I can decide if / what to move in. If we are all Python developers to some degree and know about PEP 374 - what do you think about switching from SVN to HG for maintaining Debian packages? There is also "convert" extension that may allow to convert history from other sources to HG and PEP 385 that may help admins to decide how to move from SVN. --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
On Fri, Aug 28, 2009 at 12:01 PM, Jan Dittberner wrote: > > I'm using trac and commithooks and would like to help with better > Debian support for both. > There are many outstanding bugs without patches that are rather critical to skip forever. Before moving Trac from one VCS to another the first thing that should be done is fixing them. For example, I find that for migrating servers to Lenny the following bug is absolutely necessary to be fixed and it doesn't matter where the fix will reside. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501338 Another thing that should be done is clear Debian Python Policy with Tutorial. Current dichotomy and uncertainty is not acceptable for maintaining "Modules" and "Applications". Trac is perhaps the most attractive and useful piece of Python software inside Debian. And there are many people who would like to bring it to the latest and greatest version. Let's make an exemplary package for others out of it - with proper DB/environment migrations. --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
On Fri, Aug 28, 2009 at 11:48 AM, W. Martin Borgert wrote: > > I wonder, how people feel about moving Trac from its own team > to a larger, more active team, i.e. Debian Python Modules Team, > which already has some of tracs dependencies, i.e. > libapache2-mod-python, mod-wsgi, python-docutils, genshi, > python-mysqldb Please, note that MySQL support in Trac is still experimental. Why Trac should belong to application is that Python Application is something that should be run inside virtualenv. Trac is not a module, but rather important piece of server software that should better be updated alone with it's dependent libraries and probably independent of main Python installation. --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
Hello, Piotr. In short - your post is long. Brain is limited. Better place an overview in wiki and discuss in parts. Before discussing your proposal I would really appreciate if somebody from insiders could describe situation in Debian Python in all possible detail including the history of development. I believe that this piece of work is absolutely necessary, because the problem of repackaging Python packages for Debian and maintaining integrity between installed packets, packages and Python versions is too complex to keep every detail in mind unless you can devote your full time to the problem. One way to make the status more obvious is to answer to emails in this group, and merge answers into wiki, so that the next time you can point a person to the exact place of documentation. You say that attempt to merge -cental and -support failed, but didn't mention why. You say that current tools have problems that occur at install/upgrade time, but do not mention these problems explicitly. So it is impossible to say whatever your ideas solve current problems and won't add new. Referencing rtinstall/rtupdate/rtremove scripts is cool for a seasoned Debian developer, but for a Python developer it means nothing. In other words - not only Python things are obscure for Debian developers, but Debian stuff is also a mystery for Python masters, so these things should be explained symmetrically for both communities. The chances for Debian Python Packaging experts to pop up are magnitude less if we won't explain the situation in detail. Now about the proposal (from newcomer's point of view): dh_python is a shell script -- I have a strong belief that Python package automation scripts should be written in Python, there is no need to learn bashes when you program Python - do not expect that package maintainers will be able to debug their scripts in shell language. The description that dh_python will do at a build time looks like a solution, but again - it doesn't specify what problem is being solved. Perhaps I expected to see more high-level definition. May I ask a question - is there a difference between installation of Python Modules and Python Applications? Does the problem set you are trying to resolve with this proposal include the difference? Have you considered distributing Python Applications via virtualenv? How this proposal handles virtualenv installations? In conclusion my opinion is that problem set is not defined well enough to propose a solution or estimate if it will be effective both for current flow and for future ideas. I would start from wiki. --anatoly t. On Sun, Aug 2, 2009 at 6:53 AM, Piotr Ożarowski wrote: > My attempt to merge python-central and python-support failed few months ago, > so > here's another proposal to improve the Python situation in Debian. It's > nothing new > actually, just a compilation of previous Matthias' and Joss' ideas and few of > my > own. > > The main idea is to ship symlinks (not .pyc files!) in binary packages as > Matthias proposed back in February and thus get rid of both helper tools (most > problems with current tools occur at install / upgrade time). I want to keep > it > as simple as possible and let maintainers customize it in maintainer or > rtinstall/rtupdate/rtremove scripts (if really needed). > > Advantages: > * a lot less opportunities to break a system while installing / upgrading > Python packages, > * no more problems with packages that provide the same namespace and use > different helper tool, > * Python modules available out of the box (think about daemons), > * no more "which tool should I use?" or "how do they differ?" questions ;-) > > The main disadvantage of this approach is that architecture independent > packages > will have to be rebuilt once new Python version will be added to the > supported ones > (I think we can avoid a rebuild if a version is removed from the supported > ones). > Luk (our release manager) told me that binNMUs for arch:all packages will be > possible in Debian at some point, but it's a matter or months or even years, > so > for now - manual NMUs will be needed. I think it will be easy to detect which > packages need one basing on Contents file and Depends field. > > Another disadvantage is the fact that pysupport's namespace feature will not > be > supported. If we want to keep it simple and let dpkg know about all the files > - > new *-common package with all common __init__.py (and other if needed) files > will have to be provided, just like we did before pysupport 0.7. Otherwise > removing .pyc files will not be a trivial thing to do. Note that there are > lots > of problems with this feature anyway (upstreams tend to use site-packages for > things that don't belong there), so removing it will improve the situation at > the end, IMHO. > > I'll try to make dh_python a drop in replacement for dh_pycentral and > dh_pysupport (i.e. tools used at build time) for most packages, but I don't > consider
Re: Existing modules for new Python
On Thu, Jul 30, 2009 at 7:10 PM, Max Bowsher wrote: > anatoly techtonik wrote: >> Hello, >> >> Can anybody tell what happens with existing Python modules when a new >> Python version is deployed on the system? >> Are they recompiled or reinstalled or left inaccessible in this version? > > Debian python packages trigger hook scripts in > /usr/share/python/runtime.d/ on installation to cause compilation of > bytecode for newly installed versions. > Shouldn't this be described in Debian Python Policy? http://www.debian.org/doc/packaging-manuals/python-policy/ Because I have more questions that are not answered there: What scripts should installed by python modules packages, which parameters do these scripts accept? In particular - how do they know for what version of Python they are being called and where to place interpreter specific bytecompiled files? > If the package providing the modules in question uses python-support or > python-central everything should be automatically taken care of by the > above process. > "Uses" means "adds it as dependency" or there must be specific API calls to get the desired result? Thank you. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Existing modules for new Python
Hello, Can anybody tell what happens with existing Python modules when a new Python version is deployed on the system? Are they recompiled or reinstalled or left inaccessible in this version? WBR, --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
