Hi,
I've been having a go at repackaging some Python modules where I know the
same codebase can be compiled for Python 3. So far, that's pyzmq and
python-qt4. I've not done any packaging before, so I've no idea if I'm doing
it the best way, but I've worked out something that seems to build the
exp
Scott:
> I've got python3 packaging for python-qt4 in svn already as a work in
progress. I think you'll find it's more complicated than what you've got,
but maybe I was over thinking it.
I had a feeling that might be the case, but I wanted something that I can
use now, and at least my python3-qt4
On 15 November 2011 23:49, Kay Hayen wrote:
> Hm, what about "nuitka-python" as a binary name of what is now Python, is
> that OK? It seems the readable variant.
>
nuitka-python is what I'd call it, from your description. I'm not actually
a Debian packager, though.
Thomas
On 30 November 2011 22:22, Kay Hayen wrote:
> It could turn every "module.py" into a "module.so" with more or less
> dubious benefits.
Note that there are a few differences between compiled and pure Python
modules. E.g.
- Tracebacks to errors won't show code from compiled files.
- Functions ass
On 30 November 2011 23:50, Kay Hayen wrote:
> That is only if the ".py" file doesn't exist, right? Why wouldn't it. To
> me, compilation is not about removing the source code. Not at all, it's
> only about acceleration.
>
> Nuitka's "compiled_function" is way more compatible that "PyCFunction" if
omfortable with the process. Can someone point me to the best way to
submit the packaging change to Debian, bearing in mind that I'm not really
familiar with the procedures and terminology around Debian?
Thanks,
Thomas Kluyver
Thanks, Yaroslav,
On 9 March 2012 14:31, Yaroslav Halchenko wrote:
> the best way would be to join Debian Python Modules Team and help
> maintaining this library in Debian by directly committing to team's SVN
> repository and then seeking review/sponsorship.
>
I'll try to follow this route. I'
On 12 March 2012 14:49, Yaroslav Halchenko wrote:
> well -- it might be beneficial meanwhile to share your changes one way
> or another (patch, git, mentors) so someone could review them
>
OK, I've attached the patch (against the debian/ directory) to this e-mail.
The built packages are in my PP
On 13 March 2012 21:40, Julian Taylor wrote:
> thanks for the patch, I have applied it to the team repository along
> with some more minor fixes to other parts of the package.
>
> http://anonscm.debian.org/viewvc/python-modules/packages/python-tornado/trunk/
>
Great, thanks Julian.
> I think i
Following on from tornado, the attached patch updates the packaging for
qscintilla2 to build Python 3 bindings. It's roughly following the
python-qt4 packaging (which it depends on).
Thanks,
Thomas
qscintilla2-2.6.1-4.patch
Description: Binary data
On 14 March 2012 04:13, Scott Kitterman wrote:
> I did have to make some additional changes, such as using a policy
> compliant
> binary name in python3, as we did for PyQt4 (python3-pyqt4.qsci) and using
> dh_sip3 for the python3 package. You can see the details in the DPMT SVN
> if
> you want.
On 14 March 2012 16:02, Simon McVittie wrote:
> That's too late for it to be relevant for Wheezy, tbh. I don't think a
> first beta should be in a Debian stable release, and the release team
> hopes to freeze in June (at which point advancing from beta to final is
> not a thing that should happen
I was looking at packaging numpy for Python 3 (bug #601593, LP
#795605). As a step towards this, I was trying to convert it from
pysupport to dh_python2, following the 'transition to dh_python2'
guide. But I hit a section that I don't really understand, in
override_dh_pysupport:
# add to public mo
On 15 March 2012 12:45, Yaroslav Halchenko wrote:
> So, my blunt guess would be that with dh_python2 you would not need this
> and just would need to place the .a appropriately.
Thanks, I'll give it a shot.
When the comments talk about adding files *back*, is it pysupport that
removes them? How
After some trial and error, I've got it building python3-numpy
(leaving python-support in place for Python 2) - a patch is attached.
I've checked that I can install and import the built package.
Changes and suggestions are welcome, and I expect there are better
ways to do bits of it. I'm away for
On 16 March 2012 13:35, Sandro Tosi wrote:
> Thanks a lot for your work! I just gave it a quick look (i.e. reading
> the patch) and it seems that would work (at least for the packaging
> part). It would be also nice if you could post your patch at
> 601...@bugs.debian.org, so also the BTS will be
On 17 March 2012 15:00, Sandro Tosi wrote:
> that stuff is done and the package is uploaded: Thanks for your contribution!
Great, thanks for putting in the time to finalise it.
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
The attached patch takes a shot at packaging the IPython notebook for
Python 3 (this was the impetus behind packaging python3-tornado
recently). I'm not quite sure how the symlinks to jquery files in
ipython3-notebook.links should work - at present, it's a
straightforward copy of the ipython-notebo
On 20 March 2012 20:58, Julian Taylor wrote:
> thanks for the effort, but I already did this myself after you patched
> tornado [0].
Excellent, thanks. Are you pursuing getting that change into Debian? I
noticed today that python3-tornado has worked through to Ubuntu
Precise.
> Though I really d
Hi all,
I'd like to request sponsorship of a new package, python3-dateutil,
which is very similar to the existing python-dateutil. Upstream
decided to continue development for Python 3 only, so version numbers
>= 2 are py3, and versions <2 are for py2. This is going to be a
dependency of matplotli
Thanks Jakub and Geoffroy,
(below, Done = changes committed to SVN. I'll reupload to mentors shortly)
On 24 March 2012 10:59, Jakub Wilk wrote:
> Please merge the two changelog entries.
Done. I thought I should bump the number if I'd published the package
anywhere, evidently I was wrong about t
On 24 March 2012 13:16, Geoffroy Youri Berret wrote:
> In the worse case (non dfsg licence) you need to repack upstream to have
> a dfsg suffixed package.
I think it's just a tarball of the same data that's in the tzdata
package - in which case, it's public domain. I'll add it as a section
in the
On 24 March 2012 21:21, Ben Finney wrote:
> That's what makes the most sense to me. Some DDs don't like it, some
> prefer it, and most will (IME) not mind very much either way.
>
> My advice: Do what you've done, and see what the particular sponsor
> prefers.
Thanks, Ben. I've reverted it to 2.0-
On 24 March 2012 22:41, Jakub Wilk wrote:
> I don't accept "it's dh_make's fault!" excuses, sorry. :P
I'm not aiming to make excuses - I'm suggesting that dh_make could be
updated to produce the preferred style of output, if that hasn't
already happened. I see Ben's just phrased this better than
On 26 March 2012 21:28, Jakub Wilk wrote:
>>> Apart from the fact the license and copyright status of the file is not
>>> documented in debian/copyright, there's another problem: the tarball appears
>>> to be a collection of binary blobs, for which we have no source.
>>>
>>> I'm afraid that you'll
On 28 March 2012 21:10, Jakub Wilk wrote:
> I see that you disabled tests for zoneinfo, which I interpret as a "yes"
> answer to my question. Well, I can't see how such behaviour is useful[0],
> but at very least it deserves a big red warning in README.Debian.
As far as I can see, the zoneinfo su
On 1 April 2012 10:53, Jakub Wilk wrote:
> Wouldn't it be better to update zoneinfo.gettz() tests to use tz.gettz(),
> instead of disabling them entirely?
>
> Please add get-orig-source target.
>
> The copyright file mentions dateutil/zoneinfo/zoneinfo-2011d.tar.gz, which
> doesn't exist in .orig.
On 2 April 2012 23:23, Jakub Wilk wrote:
> Your get-orig-source target tries to support being invoked from any
> directory, but this doesn't work:
You're right. I've used `pwd` now instead of . and it appears to work.
I was following the example here:
https://wiki.ubuntu.com/PackagingGuide/Exampl
On 4 April 2012 22:14, Jakub Wilk wrote:
> Hmm, didn't help here:
No bright ideas. What uscan version do you have?
$ uscan --version
This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1
> I took a closer look at your watch file:
I've followed all of your suggestions, and ch
On 5 April 2012 11:38, Jakub Wilk wrote:
> Indeed, adding --check-dirname-level=0 fixes the problem for me.
I've added that, and checked that it still works for me.
Thanks,
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Cont
On 14 April 2012 11:12, Jakub Wilk wrote:
> Could you update the latter item?
Yep, done.
Thomas
--
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/caovn4qi4hvyeg2dqa
On 16 April 2012 21:30, Jakub Wilk wrote:
> The extended description is supposed to make sense even when it's displayed
> alone, without the synposis. So it certainly cannot start with “It
> features:”.
Done. I'd misunderstood the format, I thought that it was simply
continuation of the field on
On 18 April 2012 18:03, Jakub Wilk wrote:
> But anyway, I bumped timestamp in the changelog, built, signed and uploaded
> the package. Thanks.
Thanks Jakub, and thanks for taking the time to go through all these
things with me.
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.de
On 4 May 2012 19:06, Dmitrijs Ledkovs wrote:
> ok. what is the relationship between 'distribute' & 'packaging'?
Let's see if I get all these right:
distutils: basic packaging functionality, part of the Python standard library
setuptools: third party module to add functionality that distutils lac
On 4 May 2012 23:33, Tim Michelsen wrote:
> how to solve pbuilder-satisfydepends-dummy dependencies?
> https://answers.launchpad.net/ubuntu/+source/pbuilder/+question/196073
Looking at which packages it says aren't installable, I would guess
that your pbuilder environment isn't set up to get pack
'd consider fixing things for (2.6/3.1)?
Package name: python-notify2
Version : 0.3-1
Upstream Author : Thomas Kluyver
URL : http://pypi.python.org/pypi/notify2
License : BSD
Section : python
It builds these binary packages:
python-notify2 -
On 14 May 2012 23:27, Thomas Kluyver wrote:
> - The tests: Running the tests during the build requires dbus and a
> notification daemon, which in turn requires an X server running. I've
> come up with a recipe that works in a pbuilder, but is it suitable for
> the autobuilder
On 19 May 2012 15:20, Piotr Ożarowski wrote:
> if you're not sure and package works with all Python{,3} versions
> currently supported by Debian, it's OK to skip these fields
As far as I know, that's the case. The tests pass with all supported versions.
> uploaded
Thanks, Piotr!
Thomas
--
To
On 19 May 2012 18:19, Barry Warsaw wrote:
> Ideally, upstream would mock these for the majority of, if not all the tests.
> It would be fine if there were non-unittests (i.e. integration tests) that
> used the real dbus, but these could be disabled for the builds.
(Upstream is also me, in this ca
On 19 May 2012 19:00, Thomas Kluyver wrote:
> So the
> most important thing for the tests is to check my interpretation of
> the notifications spec against an established implementation. That's
> simple enough for local testing (I just see a series of
> notifications), but do
On 25 May 2012 15:39, Thomas Kluyver wrote:
> Should I try to launch the dbus server for my tests (like I'm already
> launching the notification daemon), or just disable all the tests
> which require a running dbus server (which is all of them, at
> present)?
I've disabled
On 28 May 2012 12:05, Thomas Kluyver wrote:
> Alternatively, if
> there's a good way to get dbus running on the buildd, I'd be happy to
> re-enable the tests.
Thanks to Jakub for a patch which should sort it out. I've applied it in svn.
Thomas
--
To UNSUBSCRIBE, ema
On 6 June 2012 11:51, Toni Mueller wrote:
> Since some time, it's Plone
> 4.[01] that requires Python 2.6. Only the still-in-beta Plone 4.2
> even works with Python 2.7 (but 2.6 is still supported).
For my own interest, what does the current version do that prevents it
from working on 2.7? I
On 7 June 2012 17:09, Michael Fladischer wrote:
> SVG converter based on Cairo
This description seems a bit ambiguous - does it convert from or to
SVG? What's the format on the other end of the conversion? But perhaps
this is obvious to anyone who'd want to install it. Clicking through
to the web
On 22 June 2012 08:47, Dmitry Shachnev wrote:
> There is a small test script in the tarball (I plan to add "real"
> unit-tests in the next releases), but it requires dbus and
> gnome-keyring daemons running, so I don't think it's possible to run
> it at the build time.
I recently did a wrapper fo
On 22 June 2012 12:37, Simon McVittie wrote:
> FYI this shouldn't be necessary on Linux if you're either under X or
> running dbus-daemon manually, but it's still needed on kFreeBSD and
> probably Hurd, even if you run dbus-daemon manually.
The tests failed during an archive rebuild - that line w
The attached diff updates pyxdg with a new upstream version, which
includes Python 3 support (bug #591017).
I'm not sure of the etiquette for doing this sort of thing. Should I
contact the list (like this), directly contact the individual named as
the uploader - in this case, Piotr Lewandowski - o
On 31 July 2012 08:02, Jakub Wilk wrote:
> If the team is in the Maintainer field, you are invited to commit and upload
> stuff yourself. However, in case of big or controversial changes (*cough*
> #654978 *cough*) it's still a good idea to ask the human maintainer(s)
> first.
Do these changes co
Thanks Barry,
On 1 August 2012 19:51, Barry Warsaw wrote:
> - I bumped d/compat to 9 and BD on debhelper >= 9
> - In the d/control python-xdg and python3-xdg stanzas, I added the appropriate
> "Python 2" or "Python 3" text in the first line of Description:
I've applied both of these, along wit
Hello,
I'd like to request a sponsor to upload a new version of pyxdg.
Package name: pyxdg
Version : 0.23-1
Upstream Author : Sergey Kuleshov ; Heinrich
Wendel ; Thomas Kluyver
URL : http://freedesktop.org/wiki/Software/pyxdg
License : LGPL-2
Se
On 10 August 2012 11:33, Jakub Wilk wrote:
> I'm confused. Why do you ask _us_ if you can inject a package into Debian
> Med repo?
I think he's checking that it's OK to get help here with some
packaging that won't live in the DPMT repository. That's presumably
fine, but if he's not sure, it's pol
Hi Nigel,
On 3 September 2012 14:57, Nigel Sedgwick wrote:
> The application makes heavy use of numpy and wx and will soon make heavy
> use of scipy, matplotlib and various other python libraries that are
> widely used.
Python 3 versions of numpy and scipy are already in wheezy. wx and
matplotli
On 18 September 2012 18:00, Dmitry Smirnov wrote:
> At the moment I can't recall a good example but there are some exceptions like
> when package in mainly used as application.
IPython is packaged as 'ipython', 'ipython3', etc., and it also
includes a public module.
Thomas
--
To UNSUBSCRIBE,
With apologies in advance for straying off topic ;-)
On 21 September 2012 14:18, Yaroslav Halchenko wrote:
>Previously I have done a similar talk with an accent on a scientific
>Python stack in Debian [1] which I thought was quite well accepted.
We're having a big discussion on scipy-use
On 21 September 2012 19:32, Paul Boddie wrote:
> From following discussions on python-dev, I imagine that it might be
> interesting for people to be shown how following the basic best practices
> around metadata and configuration information can get you most of the way to
> making a half-decent pa
On 2 October 2012 09:01, Nicolas Chauvat wrote:
> PS: by the way, would anyone know of a way to use chroot or something
> similar to allow any user to have any number of virtual environments
> that use apt-get to install stuff and fall-back to the system if
> something is not installed in the virt
The attached patch is a first stab at packaging SymPy 0.7.2, which
supports Python 3. There's some polishing to be done, such as adding
an isympy3 script, but it at least builds.
I assume that building the binary packages from a single source
package is preferred? The upstream releases on Google C
On 26 October 2012 09:19, Floris Bruynooghe wrote:
> Several people have said they don't think this is a good idea. But
> why not? There is a bad effect if you don't rewrite the shebang to
> "/usr/bin/python[3] -ES" that we know of, but is there any example of
> where such a shebang line would c
On 26 October 2012 11:53, Chow Loong Jin wrote:
>> What is the definition of "system" script?
>
> Any script installed via dpkg, perhaps?
I wouldn't have said so - I install plenty of Python scripts from
packages, like /usr/bin/ipython, that I wouldn't call system scripts.
I don't think there's a
On 26 October 2012 14:20, Paul Tagliamonte wrote:
> django-admin if I'm using a virtualenv? Perhaps I'm missing the point?
> Will this just break all virtualenv support?
To my mind, django-admin is not a system script. A system script would
be something like the unattended-upgrades script, which
On Oct 25, 2012 6:31 PM, "Thomas Kluyver" wrote:
> I assume that building the binary packages from a single source
> package is preferred?
sympy devs reckon we should use the separate release tarballs. Is that
acceptable for Debian?
Thomas
On 28 October 2012 08:47, Jakub Wilk wrote:
> I assume that building the binary packages from a single source package
>>> is preferred?
>>>
>> sympy devs reckon we should use the separate release tarballs. Is that
>> acceptable for Debian?
>>
>
> Yes.
OK. I've committed the minor changes (diff
On 29 October 2012 04:42, Dmitry Shachnev wrote:
> What was the MathJax complain about? I maybe can help you with that.
>
dh_sphinxdoc: debian/python-sympy/usr/share/doc/python-sympy/html/
https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js?config=TeX-AMS_HTML-fullis
missing
Thanks,
T
Hello,
I'd like to request a sponsor to upload a new version of pyxdg. This is
essentially the same as an earlier RFS for 0.23-1, but with a new upstream
version.
Package name: pyxdg
Version : 0.24-1
Upstream Author : Sergey Kuleshov ; Heinrich
Wendel ; Thomas Kluyver
(Resending to the list - sorry)
On 6 November 2012 12:36, Thomas Kluyver wrote:
> On 6 November 2012 12:03, Dmitrijs Ledkovs wrote:
>>
>> Can you add an autopkgtest that runs the upstream testsuite?
>
>
> I've had a go - can you have a glance at the attached
On 6 November 2012 12:54, Dmitrijs Ledkovs wrote:
> Looks good. Commit and I will sponsor your package.
>
Done. Thanks, Dmitrijs.
Thomas
On 6 November 2012 13:18, Dmitrijs Ledkovs wrote:
> I am thinking to upload to experimental instead of unstable. It's a
> few upstream releases jump and a python3 package is introduced.
> This makes this changes unsuitable for unstable considering that we
> are currently frozen and these changes
On 8 November 2012 14:15, Andreas Tille wrote:
> As far as I have followed this thread I have not seen an answer to this
> part of your mail. I admit I have no idea how to support Python 2 *and*
> 3 but wild-guessing from my experience with Debian tools I doubt any
> manual code writing would b
This is an idea I've had knocking around for a while. Packaging is complex
- there are lots of different tools and syntaxes you have to understand to
do a good job of it - quilt, debhelper, watch files, etc. - along with
specialist terminology. I know various CLI tools aim to simplify things,
but n
On 9 November 2012 12:44, Maykel Moya wrote:
> Even in the case of the more restrictive license applying only to
> debian/* work? Could you/someone elaborate a little the implications of
> this (link to fine documentation is welcomed)?
>
I'm not sure if there's a Debian rule about it, but I'd co
Returning to the original topic: I've now svn-injected python3-sympy [1],
and successfully built it in a PPA [2].
[1] http://anonscm.debian.org/viewvc/python-modules/packages/python3-sympy/
[2] https://launchpad.net/~takluyver/+archive/python3
Thanks,
Thomas
On 8 November 2012 13:32, Jakub Wilk
(Resending to the list)
Hi Philippe,
On 13 November 2012 12:36, Philippe Makowski wrote:
> I never packaged any thing for Debian yet, I have to learn everything
> about Debian rules and tools for packaging.
I'm trying to start a GUI application to simplify Debian packaging. It
probably won't
On 14 November 2012 11:43, Jakub Wilk wrote:
> I don't think so, sorry.
Could you expand on this at all? Do you think that packaging should be left
to the experts? Or that the existing systems are easy enough for newcomers
to learn?
Thomas
Hi Clint,
On 15 November 2012 03:53, Clint Byrum wrote:
> https://launchpad.net/pkgme
>
> At one point I was interested in writing a ruby backend for this, but
> got distracted and moved to other focus, but I think it solves what you
> are talking about, without need to develop a large project l
On 15 November 2012 15:18, Andrey Rahmatullin wrote:
> Bottom line: if you want to get a good package, it's not always possible
> to fully automate that, especially in cases of complex (and proprietary)
> software like that you mentioned, and so a GUI wizard can't do everything
> needed.
>
I abs
On 22 December 2012 22:00, Bas Wijnen wrote:
> 6. Make /usr/bin/program a symlink to the actual file in the private
> directory. It will then search in its real place. (I've seen this used
> by angrydd.)
This (symlinking /usr/bin/program) appears to be the recommended way to
deal with it:
http
The python-xlrd package is maintained by Thomas Bläsing and the DPMT, but
the packaged version is quite old. A PAPT thread from last year suggests
that Thomas Bläsing is missing in action [1].
I've prepared a new version of the package, using a patch from the bug
tracker, the latest upstream versi
On 6 February 2013 12:52, Sandro Tosi wrote:
> Yes I do: Thomas is set as the Maintainer (as opposed to the team
> being the Maintainer), so your are more forced to ask Thomas first
> given the huge changes you're planning to do: did you contact him (it
> doesn't seem so from your email)? have yo
On 6 February 2013 19:30, Sandro Tosi wrote:
> please read our "unwritten policy" about Maintainer field at
> http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
"As a general rule of thumb, just set Maintainer to the team; there might
be some exceptions, like in situations where the packa
On 14 February 2013 12:12, Thomas Goirand wrote:
> Is there a valid reason despite history? Is there a chance that this
> rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be
> the only one happy with such decision.
>
I don't know the history, but I'll voice my support for al
On 14 February 2013 16:41, Sandro Tosi wrote:
> so please search into the mailing list archive about the several
> iterations of such discussion and the outcome of them.
The most recent discussion I found with a quick search started nearly 2
years ago. Nobody appeared to be arguing strongly aga
On 14 February 2013 20:29, Barry Warsaw wrote:
> I look at the switch to dh_python2 as an example.
I don't think it's a particularly good example, though. Lots of packages
continue to use the older helpers, and not due to a lack of time - attempts
to move away from the deprecated helpers still
On 14 February 2013 22:54, Matthias Klose wrote:
> > That causes problems when newcomers don't want to learn
> > deprecated packaging methods, and aren't allowed to update packages to
> use
> > the recommended helper.
>
> Agreed, so why not helping with it? Again, why not helping here?
>
I'm not
On 16 February 2013 09:10, Thomas Goirand wrote:
> It would be really stupid to only want to "claim" to be working as part
> of the team, that's not at all what I want to do. I'd like to be able to
> help when I can, and receive help when I need, which is the point of a
> team.
>
I agree there a
On 18 February 2013 20:46, Ludovic Gasc wrote:
> I vote D, and I can handle the migration from SVN to Git, I've done this
> several times for my work and WYMeditor.
>
> Are you interested?
>
I'm interested personally, but the votes so far suggest there's no real
will for any change - the only opt
On 18 February 2013 22:23, Ludovic Gasc wrote:
> I propose to make a poll on the Web (Doodle or other) and ask the question
> in another thread, I'm not sure that each subscriber has read this long
> thread.
>
I don't think I'll do that myself - the responses I have seen don't have
even the bare
On 19 February 2013 17:55, Thomas Goirand wrote:
> Thomas Kluyver
> Seems to be ok with migrating to Git (so, option D)
I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for
summarising the votes.
Including Piotr & Andreas, and putting people whose opin
On 20 February 2013 14:38, Olе Streicher wrote:
> I am trying to create packages for Python3 for the source package
> [1]. Following the guide [2], I get some success. However, the packages
> for Python2 and Python3 differ significantly: in the Python2 package,
> all machine independent data go i
On 20 February 2013 14:53, Thomas Goirand wrote:
> In what way the QA is different because it's a tag instead of a tarball ?
> I don't understand your reasoning. In both cases, you must make sure
> that what you are packaging is buildable, tested, QA, etc.
>
I think the idea is that, if you prep
On 22 February 2013 06:28, Dmitry Shachnev wrote:
> After looking at all packages that build-depend on python3-nose, I've
> identified these packages as needing fix:
>
I happen to recall that python-xdg is also affected, both in debian/rules
[1] and autopkgtests [2].
I'm happy to update that, b
On 14 March 2013 14:01, Scott Kitterman wrote:
> 3. Don't care to invest any thought or time in the question.
That's pretty much my thinking.
If someone wants to go through and automatically change svn. -> anonscm.,
that's fine. I'm mildly against having a Lintian rule for it, because it
just
On 7 May 2013 18:46, Sandro Tosi wrote:
> debian-python doesn't deserve a similar communication (don't you dare
> thinking about coordination, it's out of question) because we're just
> a bunch of puppets waiting for orders by the ultimate master - well
> done.
>
Selectively quoting the tech com
On 17 May 2013 17:52, Daniel Kahn Gillmor wrote:
> > We've been through this a number of times for both PAPT and DPMT. We
> want a
> > common repository for each team (not split between different VCSs).
> There's
> > been discussion about what would be needed to migrate from SVN to
> something
Please can someone upload the new package python3-sympy
Package name : python3-sympy
Version : 0.7.2-2
URL : http://sympy.org/
Binary packages: python3-sympy
It's already in the team svn:
svn://svn.debian.org/python-modules/packages/python3-sympy/trunk/
>From a previous discu
On 11 June 2013 20:58, Vincent Bernat wrote:
> - dh_auto_build has to be overrided to also call each supported Python
>3 version "python setup.py build".
> - dh_auto_install has to be overrided for the same reason.
> - Ditto for dh_auto_clean.
> - python-.install and python3-.inst
On 19 June 2013 05:47, Brian May wrote:
> How do I do this? I don't see any references to objects.inv in the
> upstream source code for django-filter, and I am not really sure what these
> files are used for.
The files are an index of objects described in the Python & Django sphinx
docs, so yo
On 22 May 2013 16:28, Barry Warsaw wrote:
> I think we should consider switching back to setuptools once 0.7 is
> released
> (defined as "available on PyPI), since this will clearly be the future of
> this
> component. We may have some fallout to deal with in other packages
> (e.g. virtualenv) t
On 6 June 2013 11:15, Thomas Kluyver wrote:
> Please can someone upload the new package python3-sympy
>
> Package name : python3-sympy
> Version : 0.7.2-2
> URL : http://sympy.org/
> Binary packages: python3-sympy
>
> It's already in the tea
On 3 July 2013 19:36, Barry Warsaw wrote:
> The reason is that if some code is trying to:
>
> except 'error message'
>
> this will fail if the raise site is changed.
>
In fact it will already fail - recent Python 2 versions throw a TypeError
if you attempt to raise a bare string (from at lea
On 16 July 2013 22:25, Stéphane Blondon wrote:
> > I checked the string exceptions in the code and they are not catched
> > (see shell commands used at this end of this message).
> > So I plan to wrap the string with an exception (Exception ou
> > TypeError). To me, the errors raised are not Type
1 - 100 of 128 matches
Mail list logo
