Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
* Package name: python-flufl.enum
Version : 3.0.1
Upstream Author : Barry Warsaw
* URL : http://launchpad.net/flufl.enum
* License : LGPLv3
Programming Lang: Python
Description : A Python
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
* Package name: python-flufl.i18n
Version : 1.0.2
Upstream Author : Barry Warsaw
* URL : https://launchpad.net/flufl.i18n
* License : LGPLv3
Programming Lang: Python
Description : A high level API
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-persistent
Version : 4.0.8
Upstream Author : Zope Foundation and Contributors
* URL : https://pypi.python.org/pypi/persistent/4.0.8
* License
On Jul 15, 2014, at 12:37 PM, Scott Kitterman wrote:
>On Tuesday, July 15, 2014 18:12:41 Andreas Metzler wrote:
>> Scott Kitterman wrote:
>> [...]
>>
>> > It seems to me 3.0 (Quilt) is still applying patches when the
>> > package is extracted using dpkg-source. Is there a way to avoid
>> > that
On Jul 15, 2014, at 09:07 PM, Raphael Hertzog wrote:
>If quilt is the problem, aren't you more satisfied with tools like gbp-pq
>that lets you avoid quilt and use (rebased) git branches to manage the
>quilt series?
My one experience with this was not very successful, although I'm sure it was
pebk
On Aug 17, 2014, at 11:19 AM, Thomas Goirand wrote:
>By the way, I try to always avoid using "master" as a branch name. This
>doesn't express anything at all.
+1
In the context of Ubuntu (and when it works ) I really like the approach
taken for UDD branches. I can always branch the version of t
On Aug 16, 2014, at 01:15 AM, Thomas Goirand wrote:
>As in, always use pristine-tar? No! The point of using git packaging is
>also to be able to use upstream git repo.
What about cases where upstream doesn't use git but you still want to use git
for your packaging branch?
Also, it makes me somew
On Aug 17, 2014, at 08:47 PM, Henrique de Moraes Holschuh wrote:
>It is not meaningless in the sense that it is a widely used convention in
>git repositories.
>
>And that's actually quite relevant.
It makes more sense when you're a pure upstream, as master might be where you
do all your cutting e
On Aug 16, 2014, at 04:28 PM, Thomas Goirand wrote:
>Why?!? Is there some sort of religion around tarballs? Shouldn't it be
>the same stuff that "git archive" does? If it isn't, why is this the
>case? Shouldn't one be able to use what's in the Git repository anyway?
>Why can't it be fixed? Aren't
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: lazr.smtptest
Version : 2.0.1
Upstream Author : lazr-us...@lists.launchpad.net
* URL : https://launchpad.net/lazr.smtptest
* License : LGPL
On Aug 20, 2014, at 02:17 PM, Ian Jackson wrote:
>I am planning to have dgit do some git-dpm'ish things, probably
>actually using git-dpm.
Excellent. I've been playing around with git-dpm (as described over in
debian-python@) and it does a lot of nice things. There are a few glitches
IMHO, but
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: lazr.config
Version : 2.0
Upstream Author : lazr-develop...@lists.launchpad.net
* URL : http://launchpad.net/lazr.config
* License : LGPLv3
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: lazr.delegates
Version : 2.0
Upstream Author : lazr-develop...@lists.launchpad.net
* URL : http://launchpad.net/lazr.delegates
* License
On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote:
>git-buildpackage's gbp pq system is what I use. I believe git-dpm is more
>complicated and comprehensive, but gbp pq is simple enough in its
>operations that it doesn't take long to wrap your mind around it.
git-dpm seems pretty easy to use as w
Do you like working on Python packages but are using collab-maint (or other)
instead of the Debian Python team's repo because you prefer git over svn? Do
you pine for the day when you can rejoin the DPMT or PAPT and still satisfy
your git cravings? :)
One of the decisions at Debconf14 is that the
On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote:
>I'm looking forward for systemd-mta.
It's inevitable. ;)
http://catb.org/jargon/html/Z/Zawinskis-Law.html
-Barry
signature.asc
Description: PGP signature
On Oct 22, 2014, at 03:02 PM, gregor herrmann wrote:
>debsnap, in devscripts.
>gbp-import-dscs --debsnap, in git-buildpackage
I've also been working on this script (with help from tumbleweed) for
similarly importing history using debsnap into git-dpm:
http://anonscm.debian.org/cgit/users/barry/i
On Oct 29, 2014, at 01:47 PM, Ian Jackson wrote:
>I got the impression that sbuild is winning over pbuilder BICBW.
Especially now that bug #607228 has been fixed!
Cheers,
-Barry
signature.asc
Description: PGP signature
On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote:
>Here's the draft:
Thanks for getting this started. I think it will help considerably to get
some standardization here. I would think that as more teams adopt git, they
will eventually just refer to DEP 14, perhaps with some additional team-b
On Nov 12, 2014, at 10:02 AM, Raphael Hertzog wrote:
>I don't know. My long term hope is that in this process we will get to a
>situation where:
>- either the tools are sufficiently interoperable that we don't have to
> care about this
>- or one of tools emerges as standard supporting all the imp
On Nov 12, 2014, at 09:27 AM, Matthias Urlichs wrote:
>Then we should either remove the paragraph entirely, or at least mention
>the danger of bit rot and that it's unwise to rely on being able to recover
>the tarfile (long term).
Because the vast majority of upstream Python packages are released
On Feb 26, 2012, at 12:26 AM, Evgeni Golov wrote:
>On 02/22/2012 10:40 AM, Elena Grandi wrote:
>
>> * Package name: python-gnupg
>> Version : 0.2.8
>> Upstream Author : Vinay Sajip
>> * URL : http://code.google.com/p/python-gnupg/
>> * License : BSD
>> Progra
On Apr 02, 2012, at 09:58 AM, Tollef Fog Heen wrote:
>This sounds like a bad name, since there used to be a regex module in
>the standard distribution a few years back and there's therefore a fair
>amount of documentation warning against using it.
Some of us were even joking at Pycon 2012 that we
On May 11, 2013, at 11:15 AM, Scott Kitterman wrote:
>Close. Because there is no aging requirement it moves much more quickly and
>as a result, there's much less risk of multiple transitions getting entangled
>and delayed.
>
>Ubuntu explicitly defines the $ RELEASE-proposed pocket as 'not meant fo
On May 23, 2013, at 02:17 PM, Josselin Mouette wrote:
>I’m not criticizing the fact that upstart comes from Ubuntu. I disagree
>with the idea of having Ubuntu as the sole origin of innovation in the
>project. It gives bad habits to both Debian and Ubuntu if the natural
>thing to do to make things
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-enum34
Version : 0.9
Upstream Author : Ethan Furman
* URL : https://pypi.python.org/pypi/enum34
* License : BSD
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-pytest-instafail
Version : 0.1.0
Upstream Author : Janne Vanhala
* URL : https://pypi.python.org/pypi/pytest-instafail
* License : BSD
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: restish
Version : 0.12.1
Upstream Author : Matt Goodall
* URL : https://pypi.python.org/pypi/restish
* License : BSD
Programming Lang
On Aug 31, 2013, at 01:37 AM, Jelmer Vernooij wrote:
>In the end, this meant that using UDD had some minor benefits (a richer
>history, and theoretical improved merge support)
I'd argue that they were more than minor benefits!
>but there were a number of extra things you had to watch out for tha
On Oct 31, 2013, at 07:45 AM, Theodore Ts'o wrote:
>On a different subject, which I don't think has been raised so far ---
>has the Debian maintinares for the upstart package made any comments
>about bug fixes or code contributions from Debian Developers who are
>personally opposed to being forced
On Oct 31, 2013, at 06:10 PM, Lars Wirzenius wrote:
>Quoting from the PDF linked from that page ("Canonical Individual
>Contributor License Agreement" for individual contributors):
>
>Based on the grant of rights in Sections 2.1 and 2.2, if We
>include Your Contribution in a Material, We m
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: flufl.password
Version : 1.1.1
Upstream Author : Barry Warsaw
* URL : http://launchpad.net/flufl.password
* License : LGPL
Programming Lang
On Oct 12, 2012, at 09:13 PM, Hideki Yamane wrote:
> bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed
> Development, as Ubuntu packaging guide says) way, but now it heavily relies
> on Launchpad in my point of view. And, packaging-dev can specify
> vendor-specific Recommen
On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote:
>How does bzr-builddeb depend on Launchpad? bzr is integrated into
>Launchpad, but you can use bzr without Launchpad as every other DVCS.
$ bzr branch debianlp:mypackage
is one way to use Launchpad with bzr for Debian effectively. It's certain
On Oct 16, 2012, at 03:54 PM, Tollef Fog Heen wrote:
>]] Jakub Wilk
>
>> What makes a buildd more secure than a machine of J. Random Developer?
>
>It has a smaller attack surface due to few users, firewalls, few
>packages installed, nobody using it for browsing the web, etc.
I also think allowin
On Nov 23, 2012, at 03:06 PM, YunQiang Su wrote:
>you always need to build for one arch and test, then why not upload it?
I think there are a lot of good reasons to do source-only uploads, even when
you should be building locally for testing purposes.
* Reproducibility - buildds provide a more c
On Nov 25, 2012, at 11:50 PM, Arno Töll wrote:
>It's annoying and it wastes my time to deal with duplicates. If yor MUA
>can't handle mailing lists properly, get a better MUA. +1 on keeping
>things as they are.
Maybe it takes longer than 14 years for MUAs to implement standards[1]. ;)
(Yes, that
On Nov 26, 2012, at 08:03 PM, Thomas Goirand wrote:
>The solution to this is very simple. Have the mailing list manager to add a
>Reply-To: header on each messages.
>
>I've done this on few of the lists I manage, and since then, nobody sends
>double-messages.
>
>But, probably, mailman is too stupi
On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote:
>Plus, you have to sign a contributor's agreement with Canonical which leaves
>a bad taste in my mouth. That shouldn't be the case with true free software,
>should it?
In an ideal world maybe it shouldn't, but in truth it is for both
On Nov 30, 2012, at 09:14 AM, Tollef Fog Heen wrote:
>There's a significant difference whether your contractual counterpart is
>somebody who has the public good or profits in the pockets of its owners
>in mind.
In the abstract, the non-profit or for-profit status of an organization is
little indi
On Dec 01, 2012, at 07:21 AM, Clint Byrum wrote:
>Just any FYI, Canonical no longer requires copyright assignment in their
>CLA. You are still giving Canonical an unlimited perpetual license on the
>code, but you retain your own copyrights.
FTR: http://www.canonical.com/contributors
with embedde
On Dec 02, 2012, at 04:22 PM, Игорь Пашев wrote:
>2012/12/2 Vincent Lefevre :
>> No, that's not sufficient. You may want relations between key-value
>> pair. For instance, if you have a line with a key "foo", then a line
>> with a key "bar" must also exist. Or a line with a key "number" must
>> ha
On Dec 04, 2012, at 02:29 PM, Paul Tagliamonte wrote:
>It's currently tied to Python 2.7 (but not to a very high degree, it's
>totally backportable).
Mmm, Python 2. Would the authors be open to a Python 3 port? :)
-Barry
signature.asc
Description: PGP signature
On Dec 04, 2012, at 06:42 PM, Ian Jackson wrote:
>That allows Canonical to make proprietary forks of the code (eg, to
>engage in the dual licensing business model). This is very
>troublesome for me; it's too asymmetric a relationship.
Not to diminish your own concerns, but it doesn't bother me.
On Dec 04, 2012, at 12:42 PM, Russ Allbery wrote:
>The main issue for some of us is not so much the ethical objections to
>these sorts of agreements but rather the fact that our employers flatly
>are not interested in signing anything of the sort, ever, with anyone.
>Much of my free software work
On Dec 05, 2012, at 01:19 AM, Mike Gabriel wrote:
>Note that finally Python Paramiko has a new upstream[1]. Code gets developed
>on Github[2]. You might want to file an issue about Python3 compatibility
>there.
Good to hear about Paramiko. There's already a Python 3 issue open:
https://github.c
On Jan 31, 2013, at 09:44 AM, Chow Loong Jin wrote:
>Well, really, the manageable case I was talking about was pip/easy_install
>inside a Python virtualenv, which is basically a Python installation that is
>kept completely distinct from the system's installation and doesn't touch
>anything dpkg is
On Feb 06, 2013, at 03:26 PM, Roland Mas wrote:
>I can only speak about Python and Perl, but I don't remember *ever* having
>been told to use their deployment system instead of the packaged versions of
>the interpreter and modules. The closest I've seen is something like "if
>you're running CentO
Okay, fortunately, no bands are practicing tonight and no kids need homework
help, so let's see if I can answer some of these questions. :)
On Feb 07, 2013, at 08:54 AM, Paul Wise wrote:
>On Thu, Feb 7, 2013 at 8:19 AM, Barry Warsaw wrote:
>
>> Speaking with many hats on, I th
On May 03, 2013, at 04:38 PM, Josselin Mouette wrote:
>- source-only uploads
>They are pushed to the buildds, and the produced binaries
>(including arch:all) are put in a staging area (much like
>incoming.d.o). These binaries can be downloaded, but
>the .changes can
On May 05, 2013, at 01:12 AM, Roger Leigh wrote:
>There's definitely an open bug for adding this, and I'll be happy
>for it to be added. It shouldn't be too hard to implement, though
>we would probably want to make it configurable whether the repeat
>build failing should fail the build as a whole
On Nov 16, 2013, at 12:01 PM, John Paul Adrian Glaubitz wrote:
>Your first mail came with the argument that you think that
>xemacs is more visually appealing than emacs. Honestly, emacs
>is primarily a tool and not an optical gimmick. Visual
>appearance does not bother most users, I'd guess. Most
On Nov 16, 2013, at 03:32 PM, Mark Brown wrote:
>There are other users who do use graphical mode, indeed I was reminded
>at the mini-Debconf today that the main reason XEmacs got forked was
>that GNU Emacs was too resistant to implementing a GUI. I guess some
>people use menus or whatever but I e
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: singledispatch
Version : 3.4.0.2
Upstream Author : Łukasz Langa
* URL : https://pypi.python.org/pypi/singledispatch
* License : Expat
On Feb 14, 2014, at 07:40 PM, Daniel Pocock wrote:
>Quite the opposite - some people felt it would be inevitable that
>Debian choosing systemd would effectively be a death sentence for Upstart
Keep in mind that (just as before the ctte decision and Mark's announcement)
Upstart is free software, l
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: nose2-cov
Version : 1.0a4
Upstream Author : Meme Dough
* URL : https://pypi.python.org/pypi/nose2-cov/
* License : MIT/X
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: wheel
Version : 0.23.0
Upstream Author : Daniel Holth
* URL : http://wheel.readthedocs.org/en/latest/
* License : Expat/MIT
Programming
On Apr 28, 2014, at 07:16 PM, Osamu Aoki wrote:
> python3 support or not (Are we moving too?)
I will of course echo Matthias and Thomas on the issue of Python 3 support.
I'd like to see us migrating to Python 3 for any "system" scripts,
i.e. scripts that come with Debian by default or are relied
On Apr 28, 2014, at 01:12 PM, Felipe Sateler wrote:
>Both soappy and fpconst seem dead upstream, which makes option 2 more
>attractive, but it looks like the soap implementations in python3 do
>not get along very well with debbugs, as Jordan notes.
A REST API would be fantastic. The best REST li
On May 12, 2014, at 07:57 AM, Charles Plessy wrote:
>For mailing lists, I read in the thread that it may not be a problem anyway,
>but I just wanted to add one thing: in many cases the lists to be created are
>a maintainer list and a commit list, and this could be replaced completely by
>the “new
On May 12, 2014, at 05:46 PM, Thijs Kinkhorst wrote:
>Mailman 3 is completely different from Mailman 3 and I see no synergy in
>basing anything on the existing package. As of now, to my knowledge no
>migration or upgrade scenarios exist from MM 2 to MM 3, and I'm not sure
>if such code will be the
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: cov-core
Version : 1.12
Upstream Author : Marc Schlaich
* URL : https://github.com/schlamar/cov-core
* License : Expat/MIT
Programming Lang
On Apr 09, 2011, at 01:38 PM, Scott Kitterman wrote:
>We've treated python and python3 as separate runtime environments. We also
>have a default python3 (just in the middle of transitioning to 3.2). The
>only meaningful change that would make python3 the 'default python' is if we
>pointed /usr/b
On Apr 11, 2011, at 07:22 PM, Scott Kitterman wrote:
>Hopefully it will gain additional sanity before approval (the authors did
>improve it based on comments I sent them it could still be better). The
>notion that /usr/bin/python pointing to any python3 version in the near term
>is anything other
On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote:
>I think it makes more sense to have a release or two where users can
>fall back on python2. Well there needs to be at least one
>where /usr/bin/python becomes python3 alerting users to the change and
>giving them the python2 fallback, just so
On Jun 02, 2011, at 10:28 AM, Peter Samuelson wrote:
>Since syncs from Debian are actually supposed to be the majority of
>packages in Ubuntu anyway, why not just do that - a real sync, not a
>fake simultaneous one. I don't live in the Ubuntu dev universe, but
>given how common of an operation th
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
* Package name: python-flufl.lock
Version : 2.1.1
Upstream Author : Barry Warsaw
* URL : https://launchpad.net/flufl.lock
* License : LGPLv3
Programming Lang: Python
Description : An NFS-safe file
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
* Package name: python-flufl.bounce
Version : 1.0
Upstream Author : Barry Warsaw
* URL : https://launchpad.net/flufl.bounce
* License : LGPLv3
Programming Lang: Python
Description : Email bounce
On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote:
>The main thing that is blocking me from implementing it currently is a
>set of perl modules which can handle the hard bit of managing a
>mailing list correctly so I don't have to write them from scratch.
Can you provide a bit more detail on this
On Sep 15, 2011, at 06:47 PM, Don Armstrong wrote:
>On Wed, 14 Sep 2011, Barry Warsaw wrote:
>> Can you provide a bit more detail on this?
>
>I am looking for a set of perl modules which can handle being fed mail
>and managing a subscription list in response to that mail while
On Dec 12, 2014, at 08:36 AM, Ben Finney wrote:
>Even for the source package name, “pathlib” is IMO too general. This is
>specifically a library for Python programmers only; its source package
>name should not grab a generic name like “pathlib”.
Why not first-come-first-served?
Cheers,
-Barry
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-pex
Version : 0.8.6
Upstream Author : Brian Wickman
* URL : https://pypi.python.org/pypi/pex
* License : Apache-2.0
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-future
Version : 0.14.3
Upstream Author : Ed Schofield
* URL : https://python-future.org/
* License : MIT/X
Programming Lang: Python
On Apr 16, 2015, at 09:04 AM, Dimitri John Ledkov wrote:
>I'd rather see gitlab.debian.net :)
+1
I've started moving my personal projects to gitlab and like it a lot.
Cheers,
-Barry
pgpEtXwHRd4zO.pgp
Description: OpenPGP digital signature
On Apr 18, 2015, at 02:56 PM, Stuart Prescott wrote:
>arch 7
>bzr199
>cvs11
>darcs 832
>git12439
>hg 65
>mtn23
>svn3593
I hope at some point soon after Jessie is released that the DPMT will
officially switch from svn to git.
Cheers,
-Barry
pgpZjFyDVmRKn.pgp
Descripti
On Apr 16, 2015, at 07:19 PM, Andrew Shadura wrote:
>> I'd rather see gitlab.debian.net :)
>
>Why Gitlab when there's Kallithea? :)
Kallithea is under consideration as forge for upstream Python:
http://legacy.python.org/dev/peps/pep-0462/
Cheers,
-Barry
pgpxAfgqu1BlU.pgp
Description: OpenPGP
On Apr 16, 2015, at 11:13 PM, Russ Allbery wrote:
>Launchpad, similarly, is probably suffering a lot from the decision to
>only support bzr.
That will probably be solved soon. From watching the commits to Launchpad
trunk, it looks like git support is progressing nicely. I expect after
some reas
On Apr 22, 2015, at 10:40 AM, Paul Wise wrote:
>I don't like it due to the JavaScript requirement, many things just
>give 500 Internal Server Error unless you have JS turned on.
Can you navigate github without JS?
Cheers,
-Barry
pgp2Hk9JVhtjQ.pgp
Description: OpenPGP digital signature
On Apr 22, 2015, at 11:01 AM, Paul Wise wrote:
>Seems to work fairly well, certainly it is robust enough to not have
>500 Internal Server Errors.
File a bug? :)
Cheers,
-Barry
pgp393q5a3UIo.pgp
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-cachecontrol
Version : 0.11.2
Upstream Author : Eric Larson
* URL : https://pypi.python.org/pypi/CacheControl
* License : MIT/Expat
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-pluggy
Version : 0.3.0
Upstream Author : Holger Krekel
* URL : https://pypi.python.org/pypi/pluggy
* License : MIT
Programming Lang
On May 20, 2015, at 04:36 PM, Luca Falavigna wrote:
>Does anybody else have comments / adjustments on the text above?
>I'd like to send out the bugs within the end of this week.
LGTM.
-Barry
pgpUHroOdhwCe.pgp
Description: OpenPGP digital signature
On Jul 21, 2015, at 06:46 PM, Ian Jackson wrote:
>That is, the dgit git tree contains the patches in debian/patches/ but
>also contains the implied changes in the main source code. If you add
>commits yourself to the dgit git tip, new patches will generated from
>your commits.
I think then that
On Aug 04, 2015, at 07:47 AM, Ian Campbell wrote:
>But git log shows that they are, it's just that Quilt is unaware of
>this (no .pc directory in git). Perhaps grub and python-pip differ here
>but I don't think so.
I think you're right. I took a look at a different package (pip *is* a little
wei
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-webencodings
Version : 0.5
Upstream Author : Simon Sapin
* URL : https://github.com/gsnedders/python-webencodings
* License : BSD
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: flufl.testing
Version : 0.1
Upstream Author : Barry Warsaw
* URL : https://gitlab.com/warsaw/flufl.testing
* License : ASLv2
Programming
On Nov 09, 2016, at 06:45 PM, Mattia Rizzolo wrote:
>Also, a personal pledge to everybody who's reading this: please don't attach
>yourself to your packages like mussels on a rock. If you realize (or
>somebody else is making you realize) that you're doing a bad job on a package
>*and* there is a
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-distro
Version : 1.0.1
Upstream Author : Nir Cohen
* URL : https://github.com/nir0s/distro
* License : ASLv2
Programming Lang: Python
On Dec 28, 2016, at 10:25 AM, Steve Langasek wrote:
>Last I looked, the dcut command in dput doesn't support the 'dm' subcommand;
>this led me to switching to dput-ng when I needed it.
Same here, as I recently needed to `dcut dm` allow for a maintainer of a
package I had been sponsoring while he
On Jan 09, 2017, at 02:28 PM, Michael Lustfield wrote:
>Python uses the microversion position for this. More importantly... is this
>really a point that matters?
Not really. In Debian terms you might think about the first digit as an
epoch, the second digit as a major version and the third digi
On Jan 16, 2017, at 10:52 AM, Scott Kitterman wrote:
>This is going to take a lot of work. I see random failures routinely block
>migrations in Ubuntu (postfix is a current example - there's two alleged
>regressions that to the extent they are valid are completely unrelated to
>anything that chan
On Jan 16, 2017, at 06:01 PM, Ian Jackson wrote:
>Right now the plan is to have _passing tests_ (well, regressionless
>ones) _reduce_ the migration delay. Failing tests would be the same
>as no tests.
One other important point for the Ubuntu infrastructure is that the
autopkgtests are a ratchet.
On Jan 16, 2017, at 05:45 PM, Russ Allbery wrote:
>autopkgtest is useful for adding additional tests of the built binaries,
>but I don't believe it's intended as a replacement for build-time testing.
>Maybe I've missed something?
No, I think you're exactly right. If an upstream provides unit tes
Hi Thomas,
I'm very sorry to hear this, and of course I hope that everything eventually
works out for you. I really appreciate the work you've done on
openstack-devel packages that are useful to the wider Python community, even
if sometimes there are version conflicts to work out. To that end...
On Apr 22, 2015, at 01:25 PM, Ben Finney wrote:
>Rather, this is the Debian project considering our own instance of a
>first-class Git hosting platform.
I guess this would mean being able to use the Debian GitLab instance for
package development, rather than say Alioth? For straight-up hosting o
On Nov 16, 2015, at 04:52 PM, Ian Jackson wrote:
>I'm leaning towards
> archive/{debian,ubuntu,...}/
>
>This is on the grounds that the tag's semantics are that the source
>code referenced by the that is what is in the specified distro
>archive, under the specified version number.
LGTM, and I th
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: dirtbike
Version : 0.1
Upstream Author : Asheesh Laroia
* URL : https://github.com/paulproteus/dirtbike
* License : Expat/MIT
Programming
On Jan 26, 2016, at 01:12 AM, Ben Hutchings wrote:
>That's not the problem at all. Read the error message again. Read the
>source line it points to. Now look at where rv comes from:
>
import subprocess
rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE,
>...
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-progress
Version : 1.2
Upstream Author : Giorgos Verigakis
* URL : https://github.com/verigak/progress/
* License : ISC
Programming
On Feb 20, 2016, at 07:52 PM, Bernhard Schmidt wrote:
>- it does not work on stretch/sid because it is not compatible with
> Python 3.5, see https://gitlab.com/mailman/mailman/issues/181
Since both the latest Debian and Ubuntu releases have dropped Python 3.4 and
only have Python 3.5, I'm changi
1 - 100 of 104 matches
Mail list logo
