On 25 May 2012 15:39, Thomas Kluyver tho...@kluyver.me.uk 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 the
On 28 May 2012 12:05, Thomas Kluyver tho...@kluyver.me.uk 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, email to
On 19 May 2012 19:00, Thomas Kluyver tho...@kluyver.me.uk 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 doing it
On 14 May 2012 23:27, Thomas Kluyver tho...@kluyver.me.uk 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 autobuilders,
On 19 May 2012 15:20, Piotr Ożarowski pi...@debian.org 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!
On May 14, 2012, at 11:27 PM, 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 autobuilders, and is there a
On 19 May 2012 18:19, Barry Warsaw ba...@python.org 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
Hi all,
I'd like to request sponsorship of a new package, python-notify2.
This is intended as a replacement for pynotify (aka notify-python,
python-notify), so it broadly copies the API from that package,
although it's not a drop in replacement. Why is a replacement needed?
- notify2 is
8 matches
Mail list logo
