On Jan 26, 2014, at 10:19 AM, Jakub Wilk wrote:
>* Ben Finney , 2014-01-26, 17:06:
>>How can I convince ‘dh_python3’ to set the shebang to the *default* >Python 3
>>interpreter?
>
>dh_python3 --shebang=/usr/bin/python3
>(if I recall correctly)
Should that be the default? There are only a few pr
On Jan 26, 2014, at 03:50 AM, Thomas Goirand wrote:
>[1] https://wiki.debian.org/Python/TransitionToDHPython2 has:
>"The two traditionally popular Python helpers, python-support and
>python-central have both been deprecated in favor of dh_python2."
>
>So if someone do not agree with this, it shoul
I ask because:
% rmadison python-django | grep sid
python-django | 1.6.1-1| sid | source, all
% debcheckout -a --source=never python-django
...
% grep -i svn debian/control
Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/python-django/trunk/
% head debi
On Jan 27, 2014, at 10:50 PM, Kai Storbeck wrote:
>Should I replay my git commits on subversion, or can I create a huge
>commit that will show the work done up to now?
>
>Would someone be interested in the small intermediate commits? They
>sound boring to me :)
IMHO it's up to you, but Subversion
Hi Raphaël,
On Jan 28, 2014, at 02:16 PM, Raphael Hertzog wrote:
>Hi Barry,
>> As the package is supposed to be team maintained, I'm wondering *where* it's
>> maintained. I have some patches to fix build failures against Sphinx 1.2.1.
>
>Good question. Luke, are you using git-svn and you forgot
On Jan 27, 2014, at 10:11 AM, W. Martin Borgert wrote:
>About git: This needs clarification, e.g. will we settle on gbp?
>Shall our branch be "master" (gpbs default) or "debian" (more
>intuitive when one works with upstream)? Will we use the
>pristine-tar branch or pristine tar files? Etc.
That a
On Jan 31, 2014, at 01:00 PM, Piotr Ożarowski wrote:
>PS did I mention that pybuild doesn't replace dh_python2 nor dh_python3?
You did, and I try to make sure that's clear when I talk to people about
it. This also seems to be *implied* in LibraryStyleGuide but I think it could
be made more expli
On Feb 10, 2014, at 10:33 AM, Iain R. Learmonth wrote:
>Cool. Thanks everyone for your help. I'm going to ask upstream if
>they'll consider moving to oauthlib then instead of python-oauth2.
Thanks for that. I've ported a number of libraries and apps to oauthlib, and
had a chance to speak with th
://genshi.edgewall.org/ticket/582
Author: Barry Warsaw
Forwarded: not-needed
--- a/genshi/__init__.py
+++ b/genshi/__init__.py
@@ -22,5 +22,9 @@
__docformat__ = 'restructuredtext en'
__version__ = '0.7'
+import sys
+if not sys.version_info < (3,4):
+raise ImportEr
On Feb 13, 2014, at 05:37 PM, Andreas Tille wrote:
> File "/usr/share/spades/pyyaml3/__init__.py", line 284
>class YAMLObject(metaclass=YAMLObjectMetaclass):
This is Python 3 syntax for specifying a metaclass. Maybe this is somehow
getting executed by Python 2?
There are ways to make metac
On Feb 11, 2014, at 01:49 PM, Michael Hall wrote:
>I am a python developer with a large focus on webapps (Django
>specifically), as well as a long history of working on Ubuntu webapp
>projects. I recently started to contribute to the debian-newmaint
>project, and am working on packaging the Djang
On Feb 17, 2014, at 05:28 PM, Vincent Cheng wrote:
>(My understanding of) the consensus is that modules should provide both
>python2 and python3 packages when possible, and individual applications can
>depend on either python2 or python3. I'm not entirely sure if there's
>consensus on what happens
On Feb 18, 2014, at 09:10 PM, Vincent Cheng wrote:
>I don't really know how autopkgtests work, but if they're run
>automatically during the build process like dh_auto_test, then that
>would cause your package to FTBFS. Can you modify the tests so that
>they work with other fonts, or disable the of
On Feb 21, 2014, at 01:59 PM, Dmitry Shachnev wrote:
>On Wed, Feb 19, 2014 at 7:45 PM, Barry Warsaw wrote:
>> They don't run automatically during package build for either pbuilder or
>> sbuild afaik, although that would be really nice.
>
>No. Autopkgtests are d
On Feb 21, 2014, at 12:22 AM, Matthias Klose wrote:
>In most cases this should be replaced with a python3 shebang, which can be
>done with dh_python3 --shebang=/usr/bin/python3. But why not automate this?
>dh_python3 looks at the b-d's, and if it doesn't find a b-d on
>python3-all-dev or libpytho
On Mar 04, 2014, at 05:26 PM, Piotr Ożarowski wrote:
>PS please add "X-Python-Version: >= 3.3" in debian/control, this module
> doesn't work with 3.2
Oops. Shouldn't that be "X-Python3-Version: >= 3.3" ? :)
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a sub
A quick note that might be of interest to maintainers as they build their
packages for Python 3.4 and 3.3. I just encountered this with Genshi. Thanks
to Piotr and Sebastian Ramacher for the discussion on #debian-python.
Genshi uses 2to3 to produce Python 3 compatible files from its Python 2
sou
On Mar 15, 2014, at 12:06 AM, Piotr Ożarowski wrote:
>In distutils build plugin, pybuild already checks for "test_suite" in
>setup.py (which apparently is not the only case where
>`{interpreter} setup.py test` should be invoked), invokes
>`{interpreter} -m unittest discover -v`... but only for so
TL;DR: Let's re-enable the ensurepip module in Python 3.4, and possibly
address some usability issues. We should descend en masse on Montreal and
stage a revolt at Pycon. :)
Python 3.4 has an `ensurepip` module[1] which implements the specification in
PEP 453 regarding the explicit bootstra
Thanks for following up here, and welcome to the list! I lurk on the Fedora
list via Gmane, but I don't think I have posting privileges there. Responding
a bit out of order.
On Mar 20, 2014, at 04:53 AM, Bohuslav Kabrda wrote:
>I'll be glad to discuss this/answer all questions that might arise
On Mar 21, 2014, at 04:30 AM, Bohuslav Kabrda wrote:
>I'm on python-dev but not pypa-dev. But if you want to take the discussion
>there, I guess I'm ok with following yet another mailing list.
Gmane makes life on a zillion mailing lists so much more manageable. ;)
>Yep, they do that. That's actu
On Mar 21, 2014, at 02:43 PM, Donald Stufft wrote:
>Also yea pip in the system Python currently kind of sucks. I want to make this
>better eventually! I just don't know how yet or have the cycles to spend
>investigating it.
One of the things I'd like to see, in addition to supporting
platform-spe
On Mar 21, 2014, at 02:28 PM, Matthias Klose wrote:
> - whether to use python3-pip or a freshly downloaded pip. When using
>pip to install for the system python3, maybe try to use the shipped
>python3-pip. I have no opinion if another pip is downloaded and
>installed into for enviro
On Mar 25, 2014, at 03:19 PM, Donald Stufft wrote:
>I assume once someone has installed pip with apt-get they’d still be able
>to run pip install —upgrade pip if they wanted too?
I would think they should be able to do that.
-Barry
signature.asc
Description: PGP signature
On Mar 26, 2014, at 02:16 PM, Piotr Ożarowski wrote:
>then --dont-blame-us has to mean removing /usr/local from sys.path
Right.
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https:
On Mar 26, 2014, at 12:15 AM, Scott Kitterman wrote:
>If I've install a package and it's upgraded (this is for the system, not for
>any kind of virtualized/isolated environment), I would find it quite
>surprising and unfortunate that it upgraded itself from an external source.
IMO, if you've apt-
On Mar 26, 2014, at 09:24 AM, Donald Stufft wrote:
>In my half formed idea in my head the way it’d work is there’d be a
>vendor-packages directory where downstream can install things to, and a flag
>to the interpreter to remove the typical site-packages. So then you’d get
>something like:
>
>p
On Mar 26, 2014, at 04:12 AM, Bohuslav Kabrda wrote:
>This really starts to look like we should all join one mailing list and
>discuss this in one thread :) What about the pypa ML? I guess joining one
>more ML is worth this...
Yep, I think pypa is probably the right mailing list to take this to.
On Mar 26, 2014, at 10:42 AM, Donald Stufft wrote:
>> But also, -I should imply this new option for full isolation.
>
>Not sure about this, I don’t think I saw the original discussion but it looks
>like -I is to prevent the user from injecting malicious code (so it removes
>env vars, the user site
On Mar 30, 2014, at 01:03 PM, Dmitry Shachnev wrote:
>On Sun, Mar 30, 2014 at 10:49 AM, Ben Finney
>wrote:
>By default, if debhelper sees a setup.py file, it sets the buildsystem
>to python_distutils, which *only* supports Python 2.
Shouldn't we be advocating for a change to debhelper by now?
On Mar 19, 2014, at 05:40 PM, Barry Warsaw wrote:
>The current situation in the Python 3.4 package is suboptimal because:
>
>% pyvenv-3.4 /tmp/zz
>Error: Command '['/tmp/zz/bin/python3.4', '-Im', 'ensurepip', '--upgrade',
>'-
Hi folks,
I'll be heading up to Montreal for the Python conference on Tuesday April 8th
and will be there until the 18th. If you're also going to the conference, it
would be great to meet up, sign keys, and chat about Python on Debian.
https://us.pycon.org/2014/
Cheers,
-Barry
signature.asc
D
On May 01, 2014, at 07:15 AM, Scott Kitterman wrote:
>>If PEP 404 is ever update to actually release, then it would be
>>reasonable to expect/demand for PEP 3147 to be implemented / included.
Don't worry, it won't (PEP 404 that is).
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lis
I have been doing some experimentation and preparation for trying to solve bug
#732703, i.e. fixing ensurepip in Python 3.4 and thus the pyvenv command.
Why this is tricky: ensurepip in the Python stdlib bundles two wheels, one for
setuptools and another for pip, and these wheels get installed int
On May 06, 2014, at 06:39 PM, Donald Stufft wrote:
>For what it’s worth, I’m the one who pushed hard against ZipImport
>capabilities being codified in PEP427 and I can say that we are *incredibly*
>unlikely to remove that ability without introducing a better way of achieving
>that. So even if the
On May 07, 2014, at 12:22 PM, Matthias Klose wrote:
>Am 07.05.2014 12:17, schrieb Piotr Ożarowski:
>> dh_python2 ignores python3-* packages, dh_python3 ignores python-*
>> packages, but in all other packages both of them will try to handle .py
>> files. To avoid possible unnecessary dependencies o
On May 07, 2014, at 04:45 PM, Matthias Klose wrote:
>Attached is a proposed change to the Debian Python policy to focus on Python3
>within the distribution. The intent is to document and start a large journey
>towards one Python stack in Debian. This is unlikely to happen for jessie+1,
>but we sh
On May 07, 2014, at 12:21 PM, Matthias Klose wrote:
>pip is a specical case here, because we want to mimic the wheel packages which
>come with python upstream. these can't be shipped in the debian python source
>package, but they are needed to make the pyvenv command work. so we have to
>construc
On May 07, 2014, at 05:49 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2014-05-07]
>> So the fix if they do FTBFS would be to add ${python:Depends} or
>> ${python3:Depends}?
>
>yes. Note that missing ${python:Depends} or ${python3:Depends} in
>Depends in most probably a bug
On May 08, 2014, at 06:41 AM, Ben Finney wrote:
>Can we converge on a single way to represent the names of these systems
>in the document? Currently there seems to be “python3”, “Python3”,
>“Python 3” used indiscriminately, without being clear why they would be
>spelled differently like that.
>
>I
On May 07, 2014, at 02:01 PM, Steve Langasek wrote:
>I don't think scripts "outside the archive" are in scope for the python
>policy; and I don't think this is what Barry was referring to. I think he
>meant python commandline programs, which some people may not think of as
>being "applications"?
On May 07, 2014, at 11:43 PM, Matthias Klose wrote:
>thas was "tools outside the archive". Debian has some infrastructure written
>in Python. I don't know if all of this is packaged and available in the
>archive.
I'm personally less concerned about those than packages inside the archive.
-Barr
On May 07, 2014, at 02:29 PM, Thomas Kluyver wrote:
>This fork looks like it's actively maintained, and has a recent release on
>PyPI (as suds-jurko):
>https://bitbucket.org/jurko/suds
There seems to be quite a few forks on PyPI:
https://pypi.python.org/pypi?%3Aaction=search&term=suds&submit=sea
A follow up.
I've done a fair bit of prototyping a solution, and with Donald's gracious
help and feedback, I think I have a plan that will work and should be
compliant with policy. I'm beginning to make changes to various DPMT packages
to build the whole stack, but I'm only uploading the simpler
On May 12, 2014, at 02:57 PM, Nicolas Dandrimont wrote:
>Here, you're setting an empty http_proxy variable, which means "don't use a
>proxy". What you really want is to set the proxy to something that errors out,
>e.g. http://127.0.0.1:9/ (the discard port on localhost).
>
>And then, you'll need t
My thoughts...
On May 16, 2014, at 12:07 AM, Matthias Klose wrote:
> - should we add wheels everywhere? I don't think we should,
> but I'd like to state this somewhere, like in the python policy.
Agreed, we should not add wheels everywhere. I would like to keep it very
limited to exactly the
Hi Piotr,
On May 16, 2014, at 10:48 AM, Piotr Ożarowski wrote:
>If I provide a script that generates .whl file out of Debian binary
>package, would that make more sense than these -wheels packages?
>
>python3.X-venv could simply depend on required packages and run this
>script (with a list of req
On May 15, 2014, at 11:38 PM, Scott Kitterman wrote:
>Shouldn't it be singular? Each package provides a wheel, not several wheels
>(and I'd name the location the same for consistency).
I thought about this. True, in all current cases there's a single wheel file
in the binary package. I wanted
2,7 +32,11 @@
Scott Kitterman
sc...@kitterman.com
- version 0.9.5
+
+ Barry Warsaw
+ba...@debian.org
+
+ version 0.9.6
This document describes the packaging of Python within the
@@ -468,6 +472,36 @@
programs included i
sion 0.9.5
+
+ Barry Warsaw
+ba...@debian.org
+
+ version 0.9.6
This document describes the packaging of Python within the
@@ -468,6 +472,45 @@
programs included in the same package.
+
+Wheels
+
+
On May 19, 2014, at 12:19 PM, Piotr Ożarowski wrote:
>* I don't want to promote .whl, .egg or anything else that is not even
> remotely comparable to .rpm or .deb,
In fact, the second draft of the policy that I posted explicitly prohibits
wheels except in some specific, described cases.
>* I do
On May 19, 2014, at 07:21 AM, Donald Stufft wrote:
>Unpacking the Wheel files will trigger pip to see them as installed and it
>will attempt to uninstall them if it needs to. If they are going to be
>unpacked it’ll need to have the .dist-info directory removed from the
>unpacked locations in order
On May 19, 2014, at 01:33 AM, Matthias Klose wrote:
>I would like to avoid different wheel directories in /usr/share, so if the
>name of the wheel encodes the python version, then they probably can live in
>the same directory.
PEP 427 provides a tagging scheme that allows differentiation in the f
On May 19, 2014, at 02:12 PM, Robert Collins wrote:
>Did you consider using python-wheels-urllib3 ?
I didn't because usually we use a suffix for related packages, as Piotr
pointed out, e.g. python-foo-doc, python-foo-bin, python-foo-common, etc.
-Barry
signature.asc
Description: PGP signature
olicy.sgml 2014-05-20 15:31:20 +
@@ -32,7 +32,11 @@
Scott Kitterman
sc...@kitterman.com
- version 0.9.5
+
+Barry Warsaw
+ba...@debian.org
+
+ version 0.9.6
This document describes the packaging of Python within t
On May 20, 2014, at 11:38 AM, Barry Warsaw wrote:
>+ compliant way. The set of packages providing wheels for this
>+ purpose are (by source package name): chardet, distlib, html5lib,
>+ python-colorama, python-setuptools, python-urllib3, requ
On May 28, 2014, at 03:47 PM, Jakub Wilk wrote:
>* Daniele Tricoli , 2014-05-28, 15:36:
>>>txclib -> urllib3 -> six
>>
>>Jakub, which version of urllib3 are you referring to?
>
>The one that is embedded in transifex-client.
That's the problem with vendorizing. Stuff like that lives in the darkes
On May 28, 2014, at 05:18 PM, Thomas Goirand wrote:
>To avoid that it grows out of proportion, can someone add a lintian
>check for that? I'd be *very* happy to have this check for myself as
>well, so that I don't miss it once more (it's quite easy to miss...).
Unfortunately, it's not just six th
On May 29, 2014, at 04:47 PM, Thomas Goirand wrote:
>On 05/28/2014 10:02 PM, Barry Warsaw wrote:
>> Unfortunately, it's not just six that gets vendorized. I'd be in favor of a
>> lintian check if it could be generalized to warn against all vendorizing. A
>> wa
On May 29, 2014, at 10:58 PM, Paul Wise wrote:
>On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote:
>
>> One of the things I want to add to my mythical PEP are at least declarations
>> of vendored packages.
>
>What tool do people use to do vendorising?
AFAICT it's
On May 28, 2014, at 12:49 AM, Scott Kitterman wrote:
>Is anyone aware of anything that would prevent dropping python3.3 from
>supported versions as soon as this transition is done?
Nope, let's do it. (I'll see what I can do about helping out with #746709.)
-Barry
signature.asc
Description: P
I'm looking again at updating tox to the latest upstream 1.7.1. Along the
way, I'd like to make /usr/bin/tox a Python 3 script.
This requires that virtualenv be importable, e.g. `$python -m virtualenv`. It
is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and we
only build it f
On May 29, 2014, at 08:15 PM, Scott Kitterman wrote:
>I'd rather remove the wheels we have and give up on ensurepip than start down
>this slippery slope.
That means we give up on pyvenv, and given that virtualenv will eventually be
a wrapper around pyvenv, that means we give up on virtual environ
On May 29, 2014, at 08:30 PM, Donald Stufft wrote:
>Does anything other than tox depend on virtualenv? Unless something python
>2.x depends on virtualenv the only real benefit to having virtualenv
>installed in both 2.x and 3.x is what the default interpreter is whenever you
>create a virtual envi
On May 29, 2014, at 08:59 PM, Scott Kitterman wrote:
>I was referring to wheels. It's my understanding that they are primarily for
>platforms without package management.
We use them in the pyvenv solution (and soon in the virtualenv
de-policy-violating solution) because they're the best way (IMHO
Returning to the original question...
On May 29, 2014, at 08:30 PM, Donald Stufft wrote:
>Does anything other than tox depend on virtualenv?
The real question is whether any Python 2 packages in the archive try to
import virtualenv, rather than say shell out to /usr/bin/virtualenv. AFAICT,
only
On Jun 02, 2014, at 02:31 PM, Mário Duarte Cruz wrote:
>Since the upgrade to python 2.7.7rc1 in sid, pip and virtualenv's pip have
>been broken, most likely due to https://bugs.python.org/issue7776 .
>
>Updating pip to 1.5.6 and virtualenv to 1.11.6 should fix the issues
>(current versions in sid
On May 30, 2014, at 11:47 AM, Barry Warsaw wrote:
>So let's say pbundler is the only thing other than tox that does this.
Well, now pbundler has been removed from the archive, so I don't care about
it anymore. ;) I can't see any reason not to make virtualenv a Python 3
applic
On Jun 02, 2014, at 04:43 PM, Donald Stufft wrote:
>Sounds reasonable to me, the only “downside” is that virutalenv will default
>to Python 3, which is probably not what most people want (however they
>can do virtualenv -p python2).
But it's what most people *should* want .
Seriously though, I w
On Jun 03, 2014, at 11:28 AM, Mário Duarte Cruz wrote:
>I forgot to mention that it breaks if you're sitting behind a proxy (might
>not be obvious from a cursory look at the linked bug):
I'm about to upload pip 1.5.6 to unstable. Please double check that this is
fixed there, and if not, please o
On Jun 03, 2014, at 04:31 PM, Donald Stufft wrote:
>The fix in 1.5.6 was updating requests. That's the only change. I think
>Debian needs to update urllib3. That's where the actual fix was.
I think you mean we need to update the requests package. That's on my list.
-Barry
signature.asc
Descri
On Jun 03, 2014, at 07:18 PM, Donald Stufft wrote:
>Do you unbundle urllib3 from requests? The fix that broke proxying was a
>thing in urllib3, which requests bundles, which pip bundles requests.
Yes, we unbundle urllib3.
>Here’s the actual fix for that issue
>https://github.com/shazow/urllib3/p
On Jun 04, 2014, at 10:20 PM, Stefano Rivera wrote:
>Won't python 3 users be using python3 -m venv?
Or `pyvenv-3` once I get that working. ;)
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Jun 04, 2014, at 11:07 PM, Zygmunt Krynicki wrote:
>Barry, would it be sensible to default to python2 (so keep existing outside
>behaviour unchanged) and then only after a grace period and enough
>announcements make python3 the default? To me doing it right now seems like
>breaking lots of scri
On Jun 05, 2014, at 11:52 AM, Donald Stufft wrote:
>Yea it shouldn’t matter on Python 3.x as the SSLContext stuff urllib3 will
>use to give good defaults there already.
Does any of this impact our wheels for virtualenv/pyvenv (Py2 and Py3)?
-Barry
signature.asc
Description: PGP signature
I have virtualenv working now, so I want to readdress the *real* question I
had.
On May 29, 2014, at 07:54 PM, Barry Warsaw wrote:
>This means however that I need to rejigger the binary packages in the
>python-virtualenv source package. Right now, python-virtualenv contains both
>th
On Jun 06, 2014, at 02:39 PM, Barry Warsaw wrote:
>In summary, I propose the following binary packages:
>
>python3-virtualenv:
>NEW package
>contains the Python 3 importable virtualenv module.
>
>python-virtualenv:
>contains the Python 2 importable virtualenv m
On Jun 20, 2014, at 12:06 PM, Brian May wrote:
>My latest thought is maybe I should rename to:
>
>python-django-captcha
>
>and create:
>
>python3-django-captcha
+1
can-never-have-enough-python-3-ly y'rs,
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject
AFAICT, the persistent library is not yet packaged for Debian.
https://pypi.python.org/pypi/persistent/4.0.8
I've search for existing packages and wnpp/ITP and not found anything. I
think this is also required as a build dependency for zope.component. It's
possible I've missed it though, so I'm
On Jun 27, 2014, at 12:06 PM, Arnaud Fontaine wrote:
>I'm not really active lately but I think it would be a good idea to move
>most of packages (the ones listed by Brian in his previous email seems
>fine to me) to DPMT.
Note that there appears to be 48 packages maintained by the Zope team:
http
On Jul 01, 2014, at 01:10 PM, Mathias Behrle wrote:
>The first tests on suds-jurko are looking very promising. I built the package
>succesfully as a drop-in replacement for the current python-suds package. It
>builds correctly for python2 and python3 with all tests. I tested part of the
>functiona
On Jul 02, 2014, at 04:16 PM, Mathias Behrle wrote:
>>* I still have not taken over the original project's documentation
>> and that is something I'd really like to do so I can update it with all
>> the fixes/updates made to the library. If anyone has experience with
>> epydocs and the tool
On Jul 02, 2014, at 05:19 PM, Jurko Gospodnetić wrote:
>Do debian distributions still actually package `distribute` instead of
>`setuptools`?
Not in sid/unstable/jessie (unreleased), but yes in wheezy. I'll update that
page.
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debia
On Jul 09, 2014, at 12:55 PM, Mathias Behrle wrote:
>relatorio has a test suite containing some images, documents and templates,
>which according to FHS should belong under /usr/share.
>
>Short question:
>
>- does this justify a common package, from which linking to the
>python2 and python3 packa
On Jul 09, 2014, at 03:13 PM, Mathias Behrle wrote:
>The latter is the current state and the files are really not big. I just was
>remembered by lintian:
>
>python3-relatorio: image-file-in-usr-lib
>usr/lib/python3/dist-packages/relatorio/tests/egg.jpg
>
>which is the cause of my request.
>
>Would
On Jul 13, 2014, at 07:08 AM, Scott Kitterman wrote:
>What packages are there that need it?
That's my question too.
There isn't much even in jessie that should *require* .whl files, and we've
clearly outlined the acceptable use cases in Python Policy. They are tightly
constrained to those that
On Jul 28, 2014, at 05:33 PM, Sebastian Humenda wrote:
>>> Maintainer: Debian Python Team
Uploaders: Debian Python Modules Team
(Or s/Uploaders/Maintainer/ if you prefer.)
Cheers,
-Barry
signature.asc
Description: PGP signature
On Aug 02, 2014, at 06:23 PM, Scott Kitterman wrote:
>If someone on the team is interested in this package staying in Debian and
>willing to be added to uploaders, please speak up. I don't mind doing the
>work to modernize the packaging, but don't care to be responsible for it long
>term.
I pers
On Aug 04, 2014, at 11:05 PM, Thomas Goirand wrote:
>Well, I'm doing my best to add Python 3 support everywhere I can.
\o/
>I've been doing this for months already. I know it wont be possible to fix
>everything. Currently, I have 2 blockers which I am working on:
>
>- python-memcache
>- beautifu
On Aug 05, 2014, at 04:09 PM, Hans-Christoph Steiner wrote:
>I think it is a good practice to make the source package name the same as the
>binary package name as long is there isn't a good reason to do otherwise. So
>with any source package that produces one binary package, those names should
>m
On Aug 06, 2014, at 08:47 AM, Raphael Hertzog wrote:
>(That said I'm also rather annoyed by the fact that the team hasn't switched
>to git yet.)
We've had these discussions on this mailing list before, but I think we should
discuss it at Debconf. While obviously we won't have full representation
On Aug 10, 2014, at 06:16 PM, Matthias Klose wrote:
>Seen this in pycurl (#757694), but if this is something which occurs more
>often, then I think we should prepare for a policy update and/or a lintian
>warning.
>
>Maybe it is not yet possible to avoid one stack entirely, but we should not
>creat
On Aug 18, 2014, at 09:22 PM, Tianon Gravi wrote:
>On 18 August 2014 18:11, Brian May wrote:
>> Unfortunately, debian/watch (AFAIK) doesn't include any details of any
>> changes that were made to the tar.gz file by the package developer.
>
>It's been my understanding that this is exactly one of t
On Aug 06, 2014, at 02:28 PM, Dimitri John Ledkov wrote:
>I am on the edge. I prefer dgit, as it's the only one the guarantees
>round-trip save with the archive even when someone NMUs things without using
>dgit.
From this description, it sounds like dgit is the closest equivalent to Ubuntu
Distri
On Aug 06, 2014, at 04:08 PM, Piotr Ożarowski wrote:
>and I would love to try them all before we make a decision¹
Me too.
Should we relax the team preference for one vcs to rule them all, at least for
a period of experimentation and experience sharing? I still *really* want to
end up in a plac
On Aug 09, 2014, at 06:02 PM, Brian May wrote:
>At the moment, in subversion, we only store the debian/* directory. Is
>there any requirement/benefit in putting the full upstream source in git
>too?
If it were well integrated with quilt, I think it would be fine to have
source-full branches. I l
On Aug 19, 2014, at 11:14 AM, Barry Warsaw wrote:
>I usually don't care much about preserving local intra-upload vcs history
Ah, except for the case where I want to collaborate with someone on the new
version, e.g. to get a code review of some packaging change *before* it gets
uploaded.
lazr.smtptest wasn't packaged in Debian yet, so I thought it would be a good
candidate for experimenting with one of the git-based workflows, from scratch.
The ITP is bug #758670. I decided to use git-dpm; here are my impressions so
far.
For reference I started with https://wiki.debian.org/Packag
On Aug 20, 2014, at 08:26 AM, Vincent Bernat wrote:
>This makes auto revert automatic but don't lose the previous content
>by keeping the undo history. It also keeps your current position in the
>file.
Thanks! I'll have to think about whether I want to enable this globally, but
it does seem like
On Aug 19, 2014, at 09:44 PM, Barry Warsaw wrote:
>Anyway, I think that's it for now. Feel free to muck about in this package,
>but please do let me know if you want to push any permanent changes. Tomorrow
>I'll probably try to do a new upstream release to fix the typo in th
401 - 500 of 859 matches
Mail list logo
