After the events of April, I've realized that I have a lot less time, and to
be frankly honest, motivation for contributing to Debian right now. So I'm
scaling back, but not retiring.
I've tried to reflect my current level of participation by updating the
packages for which I was sole or primary
On Aug 7, 2017, at 20:52, Ben Finney wrote:
> So IMO the conservative assumption is that they expect Debian to provide
> the stability it is famous for, and not to break the behaviour of
> commands unnecessarily.
There’s another dimension to that too: it’s people who
On Aug 7, 2017, at 18:28, Ben Finney wrote:
> The issue is: Invoking ‘python’ today gets an interpereter, Python 2,
> that will work with some code and not others. It should not tomorrow
> invoke an incompatible interpreter without *knowing* that the vast
> majority of
On Aug 7, 2017, at 14:52, Diane Trout wrote:
> Perhaps when launching via the command "python" the interpreter could
> hint python2 was available? Something like:
> $ python
> Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34)
> [GCC 6.4.0 20170704] on linux
> Type "python2" for
On Aug 6, 2017, at 11:11, Ondrej Novy wrote:
> It's not always possible/simple/nice to use sdist, because it contains
> prebuild docs. And I don't like to do +dfsg rebuild just for removing docs.
> Sometimes sdists doesn't contain tests.
I will also generally prefer the PyPI
Scott Kitterman wrote:
> If the primary concern is what happens when a user types "python", then can
> address that in command-not-found and leave /usr/bin/python out of it?
I'm definitely willing to for now. It's clearly not time to remove the
link or point it elsewhere anyway. I think
Ole Streicher wrote:
> It is very usual to use "#!/usr/bin/env python" as shebang, exactly for
> the case that python is not installed in /usr/bin.
Sure, but then all bets are off. The script so shebanged can't assume
anything about $PATH so it gets whatever it gets. Using /usr/bin/env in
On Jun 17, 2017, at 04:20 AM, Scott Kitterman wrote:
>Last time I compared my understanding of the Buster schedule with the
>python3.7 schedule, I recall concluding that we'd likely be on python3.6 for
>the Buster release (not sure that's still true). If so, we only have to do
>this once this
On Jun 06, 2017, at 10:57 AM, Sandro Tosi wrote:
>if we plan (and it looks like we do) to support and distribute 2.7
>with buster, why not support it *properly*? what's the point of
>deprecating python2.7? either we ship it or not, but if we do then
>let's not cripple it by removing python2
On Jun 02, 2017, at 05:48 AM, Debian FTP Masters wrote:
> partd (0.3.8-1) unstable; urgency=medium
> * Switch from git-dpm to gbp
I may be misremembering our previous discussions on the topic, but we all know
that in the long term we want to convert off of git-dpm.
On May 31, 2017, at 08:58 PM, Stefano Rivera wrote:
>It's been a while, but I found some time and energy at PyCon, to work
>our SVN->Git migration.
Thanks for all your great work on this Stefano!
>Here's what the migration currently looks like .
On May 16, 2017, at 08:10 PM, Brian May wrote:
>python-enum - robust enumerated type support in Python
>python3-enum34 - backport of Python 3.4's enum package
Oh yeah, that too. :)
On May 16, 2017, at 11:51 AM, Piotr Ożarowski wrote:
>packaged as python-enum34 (correct name is python-enum, that's why you
>didn't find it most probably)
Why is that wrong? Agreed it's perhaps less discoverable in this case, but if
you were looking for the PyPI enum34 package in
On May 11, 2017, at 10:14 AM, Colin Watson wrote:
>I'd like to join the Debian Python Modules Team. I maintain a couple of
>module packages already that probably ought to be moved under the DPMT
>umbrella (six, python-tblib), and I'm upstream for some others (e.g.
On Apr 09, 2017, at 01:13 PM, sab wrote:
>with DPMT as uploader. What's my next step? Have I to create a Git repository?
Welcome to the team Sabino.
You'll want to take a look at these two wiki pages. First is the style guide
As Ubuntu 17.04 development winds down, I've been spending a fair bit of time
looking at FTBFS. For packages that have been copied from Debian, especially
Python ones, we try really hard not to introduce too many deltas. Doko
usually does archive-wide test rebuilds at various times during the
On Apr 01, 2017, at 05:12 PM, Ghislain Vaillant wrote:
>Pasting the relevant quotes below:
>"The 2.x series of Python is due for deprecation and will not be maintained
>past 2020 so it is recommended that Python 2 modules are not packaged unless
It's true that upstream will almost
On Mar 14, 2017, at 08:16 AM, Brian May wrote:
>I just found another one: python-ledger. Unfortunately in this case,
>Python packages are also bundled with the C code (libraries and client).
Not entirely relevant, but pyparted also contained C code, but its mainline
does support Python 3.
On Mar 13, 2017, at 05:55 PM, Thomas Goirand wrote:
>IMO, upstream are right that the PyPi releases should be minimal. They
>are, from my view point, a binary release, not a source release.
Wheels should be considered a binary release, but tarballs should still be
considered the canonical source
On Mar 12, 2017, at 01:19 PM, Brian May wrote:
>Should we be using PyPI as our source of packages? Or github?
PyPI for two reasons: not every developer uses git, and even those that do may
not use GitHub.
I've so far only encountered one package that releases on GitHub and not PyPI:
On Mar 12, 2017, at 11:46 AM, Ben Finney wrote:
>What prospect is there in the Python community to get signed upstream
>releases become the obvious norm?
I don't know. Digital security seems to be mostly an afterthought
unfortunately. I always use `twine upload --sign` so all my projects have
On Mar 06, 2017, at 10:32 AM, Scott Kitterman wrote:
>I think it's reasonable to try this out on a branch for some number of
>packages and write documentation (the documentation for using git with
>git-dpm in DPMT is excellent and I don't think we should regress in that
>area). Once that's done,
On Mar 05, 2017, at 01:47 AM, Thomas Goirand wrote:
>Why waiting? The freeze is typically a time of very low activity and low
>disturbance. That's a perfect moment for doing the switch.
I think it's generally been the consensus, even outside of this team, that
doing vcs or other disruptive
On Mar 03, 2017, at 02:03 PM, Thomas Goirand wrote:
>Please consider that python-lockfile is considered deprecated upstream,
>and only maintained for bugs and security. There's alternative
>available, like python-oslo.concurrency.
ObPlug: Or flufl.lock, albeit with a different API and other
We've talked on various lists about adopting the OpenStack packages into DPMT,
and also adopting the team's standard workflows and helpers.
The way the packages have been maintained in the past isn't aligned with our
team practices, but Allison and I spent a little time today importing alembic
On Feb 23, 2017, at 10:00 AM, Jordan Justen wrote:
>Looking at http://python-apps.alioth.debian.org/policy.html, it
>appears that PAPT still uses svn.
>I wanted to start working on the 'alot' PAPT package using git. On
>irc, olasd let me know that the current stance is that no PAPT
On Feb 16, 2017, at 07:53 AM, Scott Kitterman wrote:
>Which is completely separate from the question of if we want to use it as a
>team. Whoever it was that suggested focusing on what (if anything) to
>replace git-dpm with (post-stretch) and leave the dgit discussion for later,
On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote:
>The patch-queue branch is based on the Debian branch, not upstream. Try
>merging the new upstream version to your Debian branch, and then running
>gbp pq rebase.
This confuses me, or I'm doing something wrong. With git-dpm the way to drop
On Feb 14, 2017, at 05:54 PM, Brian May wrote:
>Not sure how to unapply all patches. "quilt pop -a" won't work, quilt
>doesn't realize the patches are applied.
Yep, that does seem to be the problem.
>Maybe something like the following?
>git read-tree --reset -u upstream
>git reset -- debian
On Feb 13, 2017, at 04:56 PM, Brian May wrote:
>There might be errors, as I was going from memory for some of this
Thanks Brian. I did a quick review (without testing) and it looks pretty
One section I think we should add at some point is instructions on how to
On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>I know the discussion is leaning towards replacing usage of git-dpm
>with gbp-pq. I have nothing against it but, since we are talking about
>solutions for a git-centric workflow, has anyone considered the dgit-
>maint-merge workflow ?
On Feb 05, 2017, at 02:07 AM, Scott Kitterman wrote:
>Experimentation with a few packages to prepare for a migration and make sure
>the documentation is good, is fine. We really ought to switch for real all
>at once like we did for svn -> git. It's not much of a team repository
On Feb 05, 2017, at 04:01 PM, Brian May wrote:
>What should we call the clone page?
On Jan 31, 2017, at 02:51 PM, Scott Kitterman wrote:
>We should probably be thinking in terms of post-release for this change.
Oh, definitely +1
On Jan 29, 2017, at 09:39 AM, Brian May wrote:
>I would think "gbp pq" is the most popular.
I've used it on some of my non-team packages and while it takes a little
getting used to for the standard git-dpm workflow, it's been mostly fine.
What I'd really like to see is a page like
On Jan 23, 2017, at 02:41 AM, Scott Kitterman wrote:
>Which would be horrible. single-debian-patch means that to understand the
>upstream modifications, access to the packaging VCS is required. I think
>that would be a huge step backwards.
On Jan 22, 2017, at 03:00 PM, Dmitry Shachnev wrote:
>On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote:
>> "Drop DPMT from Uploaders (due to problems with multiple tarballs in
>> Then, the package is no longer team-maintained?
>Personally I think we could
On Nov 28, 2016, at 01:56 PM, Barry Warsaw wrote:
>I'm starting to work on pip 9.0.1 but noticed two new dependencies. appdirs
>1.4.0 we have, but distro 1.0.1 we don't. It doesn't look like there's an ITP
>for that, so I'll file that bug.
Okay, as soon as python-distro clears new, I'
On Nov 21, 2016, at 06:37 PM, Donald Stufft wrote:
>As one might expect, I would prefer it if folks got 9.0.1 as quickly as
>possible. In particular the feature that makes it easier for upstreams to
>drop Python 2 support is one that is really only effective when people can
>consider pip 9 a
On Nov 28, 2016, at 11:11 AM, Scott Kitterman wrote:
>@@ -534,6 +534,13 @@
> This requirement also applies to extension modules; binaries for all
> the supported Python versions should be included in a single package.
>+ As a special exception to the `python3-' and `python-'
Now that Stretch development is winding down, and I've been doing some recent
maintenance on pip, I wanted to throw this out there and see if anybody has
strong opinions one way or the other.
I'm considering sticking with pip 8.1.2 for Stretch, even though upstream is
On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote:
>So, I don't agree with you, and believe that gradually using
>#!/usr/bin/python2 is a good approach to the transition. IMO, that's
>what we should start doing as much as possible.
>If the dependencies for Python itself aren't calculated well
On Nov 07, 2016, at 01:21 PM, Brian May wrote:
>Should I ask on debian-devel?
I think you should, and I'll be very interested in that discussion.
Several packages in our team already apply deltas to upstream to disable
certain amounts of information gathering and reporting. The most common
On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote:
>I'm used to gbp. I don't know git-dpm (or I forgot after seeing I would not
git-dpm is usually pretty easy, but it's really only used in a few cases, such
as importing a new upstream, managing the patch stack, and tagging. We
On Nov 02, 2016, at 10:46 AM, Arnaud Fontaine wrote:
>> I write to debian-python, because some of the involved packages are
>> not specific to Zope. Actually, I even think that ZODB itself is not
>> specific to Zope, but well, changing section of existing packages can
>> be another topic.
Don't panic. :)
On Nov 03, 2016, at 09:28 AM, Ben Finney wrote:
>But the above post implies that pointless confusion will be directly
>courted, merely because of some aesthetic objection to a two-digit
>component in the version string.
Those are Nick's opinions. Everyone's got one!
On Nov 02, 2016, at 01:57 PM, Ben Finney wrote:
>Donald Stufft writes:
>> /usr/bin/python3 being Python 4.x is a bit weird though
>Seriously? Who is proposing that?
>> and it’s likely that Python 4.x is not going to be another break the
>> world release.
On Nov 01, 2016, at 11:34 AM, Scott Kitterman wrote:
>I don't think /usr/bin/python should ever point to a python3 version. It
>should be dropped when python2.7 is removed. I think the existence of
>/usr/bin/python2 is a limited to a work around for a specific distros
>insanity. There's no
Over in #834193, a user is asking for a /usr/bin/pip2 to mirror /usr/bin/pip
because some uses cases apparently prefer pip2 over pip. That seems like a
reasonable request on the face of it, and easy to support.
However, I thought, well why not shebang pip2 to /usr/bin/python2 because 1)
On Sep 29, 2016, at 11:30 PM, Thomas Goirand wrote:
>I just had a quick look to that page, not only it advises to override
>the wrong dh sequence, but also it gives stupid advices for intersphinx:
ObDIY: "It's a wiki". :)
On Sep 11, 2016, at 09:41 AM, Sandro Tosi wrote:
>now can we PLEASE stop talking about how the perfect smtp system
>should work and GET BACK to discuss if we are able and want to disable
>the suspend membership upon bounces (that's what the mail you receive
>says, so do not nitpick on this term
On Sep 10, 2016, at 04:32 PM, Santiago Vila wrote:
>AFAIK, Gmail does not bounce spam. It rejects messages with broken
There are a number of DKIM mitigation features in newer versions of Mailman 2
that should be investigated. I can't tell what version of Mailman this list
On Sep 10, 2016, at 02:46 PM, Sandro Tosi wrote:
>I'm sure i'm not the only member using gmail, which bounces spam
>emails and that what causes this problem.
Are you sure about that? Bouncing spam has been bad practice for a very long
On Aug 31, 2016, at 11:31 PM, IOhannes m zmölnig (Debian/GNU) wrote:
>isn't this what `gbp pull` is supposed to do?
Indeed. Either this is new-ish or I missed it, but it does exactly what I
Description: OpenPGP digital signature
On Aug 21, 2016, at 12:30 AM, Piotr Ożarowski wrote:
>* all Python applications that support it, should use 3.X only *now*
> (and do not bother with things like alternatives or "-3" suffixes /
> "python3-" prefixes - at least for new packages; I'd even slowly start
On Aug 17, 2016, at 01:58 PM, Andreas Tille wrote:
>This exactly was my question: Is there any advise how to inject
>sensible debugging code or any other strategies to find out what might
>be the problem.
>> So you can use the full power of your development environment to hunt
>> the problem:
On Aug 15, 2016, at 11:44 PM, Thomas Goirand wrote:
>If we decide to use gbp-pq, in fact, we're deciding to not decide, and anyone
>can use PoQ (my choice, for example). Indeed, the way to store the patches is
>PoQ, and you then "gbp-pq import", modify, then "gbp-pq export" and store the
On Aug 14, 2016, at 01:01 PM, Scott Kitterman wrote:
>On August 14, 2016 12:51:18 PM MDT, "Piotr Ożarowski" wrote:
>>[Ben Finney, 2016-08-14]
>>> Would it be a good idea to first have it running in an analogous
>>> channel, ‘#debian-python-changes’?
>>+1 (I'd move VCS
On Aug 13, 2016, at 10:48 PM, Ondrej Novy wrote:
>I would like to add BTS bot to IRC channel #debian-python with same
>notifications (uploads, bug reports) as in #debian-devel-changes filtered
I don't *think* I'd mind getting these notifications in irc, but I guess I
On Aug 12, 2016, at 05:50 PM, Sergio Durigan Junior wrote:
>I understand this is a matter of personal taste, but I beg to differ. I
>have been using git-buildpackage for most of my non-Python packages and,
>despite really small nits here and there, I think it is an awesome tool.
I think there
Thanks for the follow up Simon. One question...
On Aug 11, 2016, at 12:12 AM, Simon McVittie wrote:
>gbp pq works best if all repository users stick to the dialect of DEP-3
>where all Debian-specific pseudo-headers appear at the end of the diff
>(next to the Signed-off-by if any),
Did you mean
On Aug 10, 2016, at 11:53 AM, Nikolaus Rath wrote:
>I think the only way to make this less painful is to get rid of the idea
>of managing patches in a VCS and use something like gitpkg. This has the
>drawback source package is now *generated* from the Git repository
>(i.e., you can't do git clone
On Aug 10, 2016, at 08:49 PM, Brian May wrote:
>Most of the time it works pretty well... It looked good compared with
>the alternatives available at the time we made the decision.
>However this is irrelevant IMHO if it isn't being mantained.
Yep. git-dpm was the best of breed at the time we
On Aug 09, 2016, at 11:28 PM, Daniel Stender wrote:
>On this occasion ... let it be me to start the discussion: let's get into Git
>also for Python Apps soon.
You're channeling Stefano on #debian-python:
barry: I've started poking at PAPT SVN migration [15:08]
On Aug 08, 2016, at 11:46 AM, Ondrej Novy wrote:
>what do you think about this:
>With this change we can make slow transition pep8 -> pycodestyle without
On Aug 08, 2016, at 12:52 AM, Ondrej Novy wrote:
>created (https://bugs.debian.org/833683) and uploaded :)
Description: OpenPGP digital signature
On Aug 02, 2016, at 11:35 PM, Thomas Goirand wrote:
>I need voluptuous for OpenStack. So unless someone needs the version in
>Unstable, I prefer to not risk to break anything, and upload updates to
>Experimental, just in case the new version breaks something in the older
>release of OpenStack. My
On Aug 02, 2016, at 01:54 PM, Barry Warsaw wrote:
>You won't mind if I upload 0.9.2? I'll try to merge your changes in, but
>I've yet to see how easy that will be.
Not too bad actually. I think I have it all prepped and ready to go in DPMT
Thomas, what's going on with the voluptuous package?
I'm looking at starting to use it for a project and I noticed that it was
pretty out of date (the current upstream is 0.9.2). So I gbp cloned the DPMT
git-dpm repo and started to hack on it. The last upload appeared to be
0.8.2-1 by Robert S.
On Jul 12, 2016, at 04:07 PM, Thomas Goirand wrote:
>I find this not the top-noch way. Here's what I do:
>ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
> PYTHONPATH=. sphinx-build -b html doc/source \
On Jul 04, 2016, at 04:52 PM, Olivier Berger wrote:
>Unfortunately, I'm no longer able to dedicate time to help maintaining
>the html5lib package.
Thanks so much for your past work on it!
>Thus I'm requesting that anyone uploading the next version as part of
>the team, please remove me from the
On Jun 23, 2016, at 11:17 AM, Ben Finney wrote:
>There isn't, AFAIK, anything portable that I can write in the shebang to
>turn a command invocation of ‘./foo/bar.py’ into ‘python3 -m foo.bar’.
Why not just have a file that contains only?
exec python3 -m foo.bar
On Jun 24, 2016, at 03:30 PM, Ben Finney wrote:
>Neil Muller writes:
>> I'm working on packaging the latest version of sqlobject, which adds
>> supprt for python 3, and I'm unsure of how best to handle the helper
>> applications that ship as part of the package.
On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:
>This seems to be more common now that command-line invocation is
>becoming even more discouraged. When the upstream documentation
>recommends ‘python3 -m foo.bar’ as the primary means of invoking the
>command line functionality, that really blurs
On Jun 21, 2016, at 10:18 AM, Piotr Ożarowski wrote:
>I'd simply create new source package with new binary packages and remove
>src:pep8 even from Stretch (once all rev. dependencies use new package).
Yep, I'm leaning toward this, or at least creating a new source package for
You might be aware that the upstream pep8 package has been renamed to
pycodestyle. Both the command line and imports have changed, although not in
a backward compatible way unfortunately.
There's a new upstream flake8 which I'm preparing in git-dpm, but it will be
blocked until we decide what
On May 31, 2016, at 03:44 PM, Thomas Goirand wrote:
>Changed-By: Barry Warsaw <ba...@debian.org>
I am at Pycon US this week (anybody else?). Please feel free to do what you
Description: OpenPGP digital signature
On May 25, 2016, at 08:57 PM, Matthias Klose wrote:
>Python 3.6.0 alpha 1 is now available in experimental. The upstream release
>date is scheduled for December 2016, about two months before the stretch
>freeze. The question is, if 3.6 should be targeted for stretch, as a
Pycon 2016 starts in one week in Portland OR, USA. I'll be there for the
duration (flying in late Friday evening). Who else is coming?
We should definitely have a Debian Python BOF, and perhaps a keysigning if
there isn't one organized for the larger Python community. I'm sure we can
On May 10, 2016, at 09:56 PM, Tristan Seligmann wrote:
>I think it would be great if we could get performance-sensitive applications
>running on PyPy instead of CPython, but of course this requires the whole
>dependency graph to have pypy-* packages built.
That might be a good approach to
On May 10, 2016, at 07:23 PM, Michael Fladischer wrote:
>is there a specific reason why there are so few pypy-* packages in the
>archive? Is it just a lack of interest or are any practical reasons not
>to have them?
I don't think there are too many practical reasons other than every package
On May 05, 2016, at 11:54 AM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2016-05-02]
>> PS: why do we have two mailing lists?! :( :(
>are you suggesting to redirect ~100 emails a month from -team to this
I'm not suggesting anything (yet :). I just wan
On Apr 30, 2016, at 07:21 PM, Ondrej Novy wrote:
Thanks! I must have missed it, but you did the right thing.
PS: why do we have two mailing lists?! :( :(
On Apr 21, 2016, at 04:52 PM, Thomas Goirand wrote:
>It's best that the test suite goes within the project. So if project is
>called foo, then best is to get the test folder in foo/tests. This way,
>you don't even need to fix the MANIFEST.in.
+1 - as an upstream I always do this because I like
On Apr 21, 2016, at 02:54 PM, Tristan Seligmann wrote:
>With my upstream developer hat on: source packages on PyPI are meant for
>end users to install via pip. They often include generated artifacts, and
>don't include things that aren't intended for installation via pip (tests
>being just one of
On Apr 17, 2016, at 06:36 PM, Brian May wrote:
>(or even better, use the quick-update script instead)
Oh, and +1 for the recommendation! I'd just add to also be sure that you
commit and push your changes. ;) I've had one or two cases where the repo
doesn't match the
On Apr 09, 2016, at 08:11 PM, Julien Cristau wrote:
>FWIW I think that's a bad idea. A number of packages run their test
>suite at build time, and running the tests with hash randomization
>enabled seems to me like something we shouldn't give up.
Completely agreed. Although we're in the long
On Apr 06, 2016, at 11:48 PM, Scott Kitterman wrote:
>In my opinion either can be correct depending on the primary purpose of the
I think that's true; take it on a case-by-case basis.
In general, I like having a separate binary package for the /usr/bin script
because it can be more
On Apr 04, 2016, at 05:33 PM, Brian May wrote:
>Ok, so as I expected, integrating a new upstream release resolved this
>issue for me. git-dpm import-new-upstream left me in the patched
>directory, and I was able to drop the last patch and then run git-dpm
When it works, it's
On Mar 26, 2016, at 01:49 PM, Brian May wrote:
>Barry Warsaw <ba...@debian.org> writes:
>> In some cases, I've just taken to adding DEP-8 tests for those.
>Do you have an example I can look at?
Hi Brian. Take a look at tox for example.
On Mar 25, 2016, at 06:17 PM, Brian May wrote:
>However I have a package where the tests require the entry points from
>setup.py to be configured, the tests fail without this.
>So what is the appropriate way to modify debian/rules to get the tests
>to run from the installed version with the
On Mar 25, 2016, at 01:02 PM, Paul Wise wrote:
>Does HyperKitty depend on mailman3 or just enhance it by providing an
>archive web interface?
Although greatly enhanced by it, Mailman 3 (core) doesn't require HyperKitty.
HK isn't currently useful on its own though.
Probably no surprise, but I agree with everything Matthias said.
On Mar 15, 2016, at 11:20 AM, Matthias Klose wrote:
>I would like to come up with a recommendation that if a python module ships
>scripts, Python3 is used for these scripts, and the Python2 version of these
>scripts should be
On Mar 09, 2016, at 11:21 AM, Nikolaus Rath wrote:
>Whenever I use pristine-tar, I'm getting the following warning:
>| warning: pristine-gz cannot reproduce build of [whatever].orig.tar.gz;
>storing 85% size diff in delta
>| (Please consider filing a bug report so the delta size can be
On Mar 07, 2016, at 10:24 AM, Brian May wrote:
>I really like the work flow of git-dpm. Think it is much better then
>gbp-pq, which IIRC stores and distributes the patch files in git.
>Shame it isn't better maintained. As a result, seems it is very easy to
>get it in a confused state (e.g. by
On Mar 06, 2016, at 01:12 PM, Christopher Baines wrote:
>However, git-dpm keeps complaining in different ways when I try to do
>this (and I have tried a few different ways). I think the source of the
>issues I am having could be that the debian/.git-dpm file is out of sync
>with the rest of the
On Mar 02, 2016, at 11:40 AM, Florent Rougon wrote:
>Sorry for linking to my own bug report, but am I the only one affected
>by bug #815864?
Since the fix for this is in python3.5, I've already provided a patch to
Matthias. I wanted to get his feedback about one particular point of the
On Mar 01, 2016, at 11:02 PM, Mattia Rizzolo wrote:
>FYI, I don't know of a nice way to build a dependency graph, like sometimes I
>see somewhere, with graphiz
That's a tool I'd sometimes love to have too.
Description: OpenPGP digital signature
On Mar 01, 2016, at 06:10 PM, Martin Pitt wrote:
>You could use it for that purpose indeed, but that's not really what
>it is intended for. The idea is that the generic tests apply to all
>packages of a particular type, so you can change them centrally
>instead of having to modify and upload
On Mar 01, 2016, at 09:05 AM, Martin Pitt wrote:
>Very nice! There's precedent for Perl, Ruby and DKMS packages which
>have a fairly standard way to run the upstream test suite. For Python
>there are some conventions, like "./setup.py test" or running
>nosetests, maybe it's worth experimenting
1 - 100 of 772 matches
Mail list logo