On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote:
> This has driven
> some contributors away in the past, thinking we don't have team spirit.
> IMO, that's truth, and this kind of thread is hurting again.
Just to back this up: watching threads like this go past makes working
on/with Debian
On Thu, Sep 24, 2015, at 03:30 AM, Paul Wise wrote:
> Source tarballs containing generated/bundled files is a bug that
> should be fixed.
That's my point ;-). From our upstream point of view, it's not a bug
that the distributions we put on PyPI contain generated/bundled files -
we do it that way d
On Sat, Sep 19, 2015, at 09:36 AM, Barry Warsaw wrote:
> There have been countless attempts at moving the Python packaging
> infrastructure to a declarative syntax over the years. I remember
> talking to
> Tarek at a Pycon *many* years ago about this. Maybe this time it'll
> catch
> on. :)
I thi
On Sat, Sep 19, 2015, at 01:05 AM, Julien Puydt wrote:
> Yes, you're also upstream for ptyprocess and terminado :-P
Guilty as charged ;-) I work for Jupyter/IPython, so there are several
dependencies from that that I'm responsible for.
> I have nothing against declarative -- it's just that I sus
On Fri, Sep 18, 2015, at 11:56 PM, Julien Puydt wrote:
> here is a new way to package modules for Python:
> https://github.com/takluyver/flit
>
> It means that something packaged using it doesn't use a setup.py or some
> such, but a flit.ini ; see for example:
> https://github.com/jupyter/testpat
On Fri, Sep 18, 2015, at 08:49 AM, Julien Puydt wrote:
> What is annoying is that some of the packages have a dependency chain
> going in some way, and an extra dependency chain going the other way.
> For a concrete example, ipykernel depends on ipython... but ipython has
> an extra-dep on ipyke
On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote:
> c) write convoluted tricky code to workaround the bugs and differing
> behaviour on 3.4 vs 3.5.
I use unittest.mock from Python 3.4 on several packages, and it has not
required convoluted code. I would be very surprised if that code breaks
On Mon, Jun 22, 2015, at 12:20 PM, Andreas Tille wrote:
>
> "/home/andreas/debian-maintain/alioth/debian-med_git/build-area/python-dendropy-4.0.2/dendropy/utility/textprocessing.py",
> line 44, in bytes_to_text
> s = codecs.decode(s, ENCODING)
> TypeError: must be string, not None
Looks l
On 21 April 2015 at 08:15, Barry Warsaw wrote:
> >For third parties who want to distribute scripts that run out-of-the-box
> >everywhere (installers, cross-platform system management or monitoring
> >scripts, build scripts, etc.), Python 3 isn't an option. If we remove
> Python
> >2 from the defa
I think the basic shape of this idea is good - it's a neat way to keep the
ubiquitous 'python' command available as Python 2 starts to go away,
without breaking compatibility with all the scripts that expect that
command to mean Python 2. You're essentially saying that 'python' can be
Python 3, but
It's worth mentioning that in virtualenvs and conda envs, where there can
only be one version of Python installed, 'python' refers to that whether it
is Python 3 or 2. So it's already not a safe assumption that 'python'
always means Python 2, even if you discount Arch.
On 15 April 2015 at 21:04, S
On 14 April 2015 at 08:57, Scott Kitterman wrote:
> I have scripts I use locally that are untouched in almost a decade that use
> /usr/bin/python.
I'm thinking about scripts that are written and distributed to people
running on different, unknown, Linux distros. Obviously if you're only
targeti
On 14 April 2015 at 08:10, Barry Warsaw wrote:
> But it fails unhelpfully when you use it in a shebang.
>
> $ /tmp/foo.py
> bash: /tmp/foo.py: /usr/bin/python: bad interpreter: No such file or
> directory
>
> Let's make the latter more helpful.
>
>From a script authors point of view, it's curren
On 25 February 2015 at 14:40, Scott Kitterman wrote:
> Having re-read the bug, I don't see how this is anything other
> than user error in Debian.
>
I hope you don't mean that installing any of the packages pip relies on
under my home directory is 'user error'. The user shouldn't even need to
kn
On 11 February 2015 at 14:22, Scott Kitterman wrote:
> Given the filename, shouldn't it be import khmermodule?
foomodule.so was a valid filename for a module 'foo' - though I only heard
about this when that spelling was removed in Python 3.3:
https://docs.python.org/3/whatsnew/3.3.html#building
On 14 December 2014 at 15:34, Brian May
wrote:
>
> Not sure calling it multiple distinct Python packages is correct,
> currently there is only one setup.py, and hence only one egg file produced.
>
> e.g. package contains
>
>
> setup.py
> module1/__init__.py
> module1/something.py
> module2/__init_
On 4 August 2014 10:29, Thomas Goirand wrote:
> Also, fixing version 3 of beautifulsoup doesn't look very easy. It needs
> sgmllib, which is removed from Python 3, and it doesn't feel right to
> maintain sgmllib as a Python module for Python 3 (I tried, and with a
> few hacks, it works though...)
On 7 May 2014 14:11, Paul Tagliamonte wrote:
> If I had more time to blow, I'd likely try a run at something SUDS API
> compatible in Python 3. Won't happen any time soon for me, but it's
> something I will eternally praise someone over.
>
> So many people have tried to forward-port the SUDS code
On 26 Jan 2014 16:33, "Paul Tagliamonte" wrote:
>
> On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote:
>
> [ awesome points here ]
>
> > Cheers,
> > Nicolas Dandrimont
>
> Hear, Hear!
Ditto - I agree with just about everything Nicolas said. I'd love to see
this become a cooperati
On 25 Jan 2014 07:37, "Thomas Goirand" wrote:
>
> On 01/25/2014 06:01 PM, Sandro Tosi wrote:
> > Sorry, what? and you didn't think to contact me first to almost
> > rewrite the package? If there's problems, open bugs. Revert your
> > changes or I'll do at the first occasion. and mainly, why don't
On 11 November 2013 08:45, Barry Warsaw wrote:
> * Expose /usr/bin/foo with a shebang line of #!/usr/bin/python
>
> * Expose /usr/bin/foo-3 with a shebang line of #!/usr/bin/python3
>
In upstream IPython, we now install an ipython2 script on Python 2,
paralleling the ipython3 script. The packa
Hi Jean-Christophe,
On 29 September 2013 13:31, Jean-Christophe Jaskula <
jean.christophe.jask...@gmail.com> wrote:
> The Ipython team has released a couple of major releases during the last
> months but I haven't seen any discussions about packaging them in debian.
> Just for curiosity, I decide
On 20 September 2013 16:00, Andrey Rahmatullin wrote:
> Packaging often takes much longer than a couple of days, especially if the
> packager is not experienced. And when the work is published somewhere, but
> not yet uploaded, there is no general way to know if it's published and
> where.
>
And
On 20 September 2013 12:08, Paul Tagliamonte wrote:
> Don't take this as me trashing on Python or Pythonistas. If you want to
> talk
> about this in person, I'm usually at PyCon. I'm also usually in the
> packaging
> BOF. Perhaps we can bring some of this up there this year?
>
Unfortunately, I d
On 20 September 2013 10:52, Paul Tagliamonte wrote:
> If a library breaks API because the maintainer wanted another toy
> rewrite, we're not going to upload it and break half the archive. That's
> silly.
>
This condescending attitude towards developers ('another toy rewrite')
doesn't help. Work
On 20 September 2013 01:11, Thomas Goirand wrote:
> > From a developer point of view: this leaves you dependent on other
> > people to get the latest release of your software to users, which can be
> > very frustrating. For instance, I'm a developer for IPython: we made a
> > 1.0 release over a m
On 18 September 2013 08:41, Piotr Ożarowski wrote:
> so instead of reinventing the wheel and trying to make something that
> works everywhere they should make it easier for others to convert
> whatever they provide (tarballs?) into .rpm, .deb or .exe.
>
>From a developer point of view: this leav
I've updated the python3-sympy package in SVN to the new upstream release,
0.7.3. Is anyone interested in reviewing or uploading this?
Thank-you,
Thomas
On 29 June 2013 23:17, Thomas Kluyver wrote:
> On 6 June 2013 11:15, Thomas Kluyver wrote:
>
>> Please can someone uploa
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
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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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 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
(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
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
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
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 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
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 6 November 2012 12:54, Dmitrijs Ledkovs wrote:
> Looks good. Commit and I will sponsor your package.
>
Done. Thanks, Dmitrijs.
Thomas
(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
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
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
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 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 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 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 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
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 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
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
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 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,
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 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
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
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
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
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 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
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 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 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 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 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 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 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 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 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
'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 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
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 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 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 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 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 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
1 - 100 of 128 matches
Mail list logo
