Re: RFS: python-pyftpdlib
Hi, Thank you for taking a look on this package and for your help. I've committed changes to svn. I hope that this is good now. On Mon, Jun 21, 2010 at 7:51 AM, Umang Varma wrote: > I'm not very experienced, so somethings in this mail may be factually > *wrong*. Please correct anything in this mail that is wrong. > > On 06/21/2010 02:49 AM, Janos Guljas wrote: >> RFS: python-pyftpdlib >> >> Dear mentors, >> >> I am looking for a sponsor my package "python-pyftpdlib". > > debian/watch: Maybe prefix your homepage before the download location? > Currently uscan gives me an error. > >> $ uscan --verbose >> -- Scanning for watchfiles in . >> -- Found watchfile in ./debian >> -- In debian/watch, processing watchfile line: >> http://pyftpdlib.googlecode.com/files/pyftpdlib-(.*).tar.gz >> uscan warning: In watchfile debian/watch, reading webpage >> http://pyftpdlib.googlecode.com/files/ failed: 404 Not Found >> -- Scan finished > > Changing it to this worked: >> version=3 >> http://code.google.com/p/pyftpdlib/ >> http://pyftpdlib.googlecode.com/files/pyftpdlib-(.*).tar.gz > (I think it would be a good idea to do this, so that when a DD reviews > your package, it would be easier to download). > > You don't seem to have an explicit build-dep on python. Python Policy > [1] seems to require that. > > Lintian gives me one informational tag. > > Note: I know nothing about how important it is. If you already knew > about it, ignore my mentioning it. > >> I: python-pyftpdlib: possible-documentation-but-no-doc-base-registration >> N: >> N: The package ships a .html or .pdf file under /usr/share/doc/, which are >> N: usually documentation, but it does not register anything in doc-base. >> N: (Files under an examples directory are excluded.) >> N: >> N: Refer to Debian Policy Manual section 9.10 (Registering Documents using >> N: doc-base) for details. >> N: >> N: Severity: wishlist, Certainty: possible >> N: > > > [1]: > http://www.debian.org/doc/packaging-manuals/python-policy/ap-build_dependencies.html > > > -- > 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/4c1efdf9.60...@gmail.com > > Best, Janoš Guljaš -- 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/aanlktikx__30brih96cfav5sx8tqqsizjrfkkyvvu...@mail.gmail.com
Re: RFS: dnspython (NMU, updated package, new upstream release)
On Sun, Jun 20, 2010 at 1:14 PM, Miguel Landaeta wrote: > I am looking for a sponsor for the new version 1.8.0-0.1 > of package "dnspython". Robert Edmonds already uploaded a new version for this package yesterday, so please ignore this RFS. Thanks. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche -- 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/aanlktikw__pjgvfdw5sfsjru2yhtfnvibuue51xya...@mail.gmail.com
Re: Policy for "Specifying Supported Versions" for Python3
On Jun 20, 2010, at 04:28 PM, Scott Kitterman wrote: >> I'm going to declare rough consensus around this approach and I'll have a >> Python policy patch for review shortly. I haven't had time to read this through yet, but I recently posted some information related to Python on Debian and Ubuntu and requested off-list feedback. One of the more interesting messages I got was from someone who was trying to install a package that has been ported to Python 3, is available on Ubuntu for both Python 2 and 3, and wanted one command to install both binary packages. He was using Synaptic but I don't think that matters. It seems to me that the right way to handle this would be meta-packages that included dependencies on both the Python 2 and Python 3 version of the underlying packages. Maybe we should consider supporting this, and coming up with an agreed-upon naming scheme. E.g. for Python package 'foo', we'd have: * python-foo - the binary package for foo in Python 2 * python3-foo - the binary package for foo in Python 3 * python-2and3-foo - for the meta package that installs both of the above "python-2and3-foo" is probably a crappy naming convention. 1) Is this a good idea? 2) Can you suggest a better name? -Barry signature.asc Description: PGP signature
Re: Policy for "Specifying Supported Versions" for Python3
[Barry Warsaw, 2010-06-21] > I haven't had time to read this through yet, but I recently posted some > information related to Python on Debian and Ubuntu and requested off-list > feedback. One of the more interesting messages I got was from someone who was > trying to install a package that has been ported to Python 3, is available on > Ubuntu for both Python 2 and 3, and wanted one command to install both binary > packages. He was using Synaptic but I don't think that matters. you mean like `debi foo_1.2-3_amd64.changes` or `apt-get install python-foo python3-foo`? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100621221317.gi18...@piotro.eu
Re: Policy for "Specifying Supported Versions" for Python3
On Monday, June 21, 2010 05:40:37 pm Barry Warsaw wrote: > On Jun 20, 2010, at 04:28 PM, Scott Kitterman wrote: > >> I'm going to declare rough consensus around this approach and I'll have > >> a Python policy patch for review shortly. > > I haven't had time to read this through yet, but I recently posted some > information related to Python on Debian and Ubuntu and requested off-list > feedback. One of the more interesting messages I got was from someone who > was trying to install a package that has been ported to Python 3, is > available on Ubuntu for both Python 2 and 3, and wanted one command to > install both binary packages. He was using Synaptic but I don't think > that matters. > > It seems to me that the right way to handle this would be meta-packages > that included dependencies on both the Python 2 and Python 3 version of > the underlying packages. Maybe we should consider supporting this, and > coming up with an agreed-upon naming scheme. > > E.g. for Python package 'foo', we'd have: > > * python-foo - the binary package for foo in Python 2 > * python3-foo - the binary package for foo in Python 3 > * python-2and3-foo - for the meta package that installs both of the above > > "python-2and3-foo" is probably a crappy naming convention. > > 1) Is this a good idea? > 2) Can you suggest a better name? > I think most people install Python modules and extensions as dependencies of applications they care to use. For Python developers that actually care about such things, I think it's better that the just install both manually. If we maintain a standard that if in Python you import foo, then the Python package name is python-foo and the Python3 package is names python3-foo, I would think this is manageable. I think that adding this metapackage would impose a lot of complexity on packagers and/or python helper maintainers, bloat the Packages.gz file signficantly, and probably provide confusing search results. I'm not sure what the best answer is, but I'm not sure there is one that's even good. Scott K -- 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/201006211830.57095.deb...@kitterman.com
Re: Policy for "Specifying Supported Versions" for Python3
On Jun 21, 2010, at 06:30 PM, Scott Kitterman wrote: >I think most people install Python modules and extensions as dependencies of >applications they care to use. For Python developers that actually care >about such things, I think it's better that the just install both manually. I agree about the former. I'm just posing the question, I'm not sure I have a strong opinion about the latter. For developers, I guess 'apt-get build-dep' gets close, but it doesn't seem quite right. >If we maintain a standard that if in Python you import foo, then the Python >package name is python-foo and the Python3 package is names python3-foo, I >would think this is manageable. I think that adding this metapackage would >impose a lot of complexity on packagers and/or python helper maintainers, >bloat the Packages.gz file signficantly, and probably provide confusing >search results. > >I'm not sure what the best answer is, but I'm not sure there is one that's >even good. Maybe the answer isn't in adding more package dependencies, but instead in a tool that you could wrap around apt. E.g. if I wanted Python package foo installed for all installed Python versions, I think it wouldn't be too difficult to write a little helper that could map from Python module name to python-foo and python3-foo binary package names, doing the apt-get install for you. Does that sound more reasonable? -Barry signature.asc Description: PGP signature
Re: Policy for "Specifying Supported Versions" for Python3
On Jun 22, 2010, at 12:13 AM, Piotr Ożarowski wrote: >[Barry Warsaw, 2010-06-21] >> I haven't had time to read this through yet, but I recently posted some >> information related to Python on Debian and Ubuntu and requested off-list >> feedback. One of the more interesting messages I got was from someone who >> was >> trying to install a package that has been ported to Python 3, is available on >> Ubuntu for both Python 2 and 3, and wanted one command to install both binary >> packages. He was using Synaptic but I don't think that matters. > >you mean like `debi foo_1.2-3_amd64.changes` or >`apt-get install python-foo python3-foo`? I think the OP wanted something more like the latter. -Barry signature.asc Description: PGP signature
Re: Policy for "Specifying Supported Versions" for Python3
"Barry Warsaw" wrote: >On Jun 21, 2010, at 06:30 PM, Scott Kitterman wrote: > >>I think most people install Python modules and extensions as dependencies of >>applications they care to use. For Python developers that actually care >>about such things, I think it's better that the just install both manually. > >I agree about the former. I'm just posing the question, I'm not sure I have a >strong opinion about the latter. For developers, I guess 'apt-get build-dep' >gets close, but it doesn't seem quite right. > >>If we maintain a standard that if in Python you import foo, then the Python >>package name is python-foo and the Python3 package is names python3-foo, I >>would think this is manageable. I think that adding this metapackage would >>impose a lot of complexity on packagers and/or python helper maintainers, >>bloat the Packages.gz file signficantly, and probably provide confusing >>search results. >> >>I'm not sure what the best answer is, but I'm not sure there is one that's >>even good. > >Maybe the answer isn't in adding more package dependencies, but instead in a >tool that you could wrap around apt. E.g. if I wanted Python package foo >installed for all installed Python versions, I think it wouldn't be too >difficult to write a little helper that could map from Python module name to >python-foo and python3-foo binary package names, doing the apt-get install for >you. > >Does that sound more reasonable? > Probably almost trivial with python-apt. Yes. Much better. Scott K P. S. No need to CC me, I'm subscribed to the list. -- 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/376e8ddd-00bd-43f9-8481-ca3e4e872...@email.android.com
Re: Policy for "Specifying Supported Versions" for Python3
On Tue, Jun 22, 2010 at 6:30 AM, Scott Kitterman wrote: > If we maintain a standard that if in Python you import foo, then the Python > package name is python-foo and the Python3 package is names python3-foo, I > would think this is manageable. I think that adding this metapackage would > impose a lot of complexity on packagers and/or python helper maintainers, > bloat the Packages.gz file signficantly, and probably provide confusing search > results. What is the point of separate python-foo/python2-foo and python3-foo packages? Will they be separate source packages or just binary packages? Will we rename the python3-foo packages to python-foo once python 2 is gone? After python 2 is gone will we add new packages named python-foo and have old python3-bar packages in the archive at the same time? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimxhu2rsiy9wz4y-n8phj4ktu5cf6zuvhy5k...@mail.gmail.com
