On May 05, 2015, at 07:48 PM, Scott Kitterman wrote:
>This was a sample migration. Still commit to svn (except for testing
>purposes).
So I think the last remaining decision to make is that of the patch regime
we're going to adopt. Once we decide that, I'd like to look at Stefano's
migration t
I haven't heard any feedback on the git migration plan, but I made one small
change for early experimenters.
In https://wiki.debian.org/Python/GitPackaging there used to be a tip
indicating that after running setup-repository on git.d.o to set up the team's
git branches, you had to re-point HEAD t
On May 18, 2015, at 12:51 PM, Daniele Tricoli wrote:
>pip 1.5.6-5 is doing a “from requests.compat import IncompleteRead” but it's
>not a problem: I reintroduced IncompleteRead because it was the easiest way
>to not break pip (see #766419); I will remove this patch when pip will be
>updated.
FWIW
On May 14, 2015, at 12:04 AM, Scott Kitterman wrote:
>On Thursday, May 14, 2015 05:42:56 AM Tristan Seligmann wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Tristan Seligmann
>>
>> * Package name: python-ipaddress
>> Version : 1.0.7
>> Upstream Author : Philipp Hagemeist
On May 21, 2015, at 03:44 PM, Scott Kitterman wrote:
>>ipaddress is apparently also a new dependency of pip.
>
>For python2?
Yes, sorry, just for Python 2.
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
On May 23, 2015, at 07:22 PM, W. Martin Borgert wrote:
>Anybody up to put simpy into git instead of svn? I personally
>would not care to preserve the packaging history.
I've been playing a bit with Stefano's conversion scripts. I really needed
multiple branches for the python-pip work I'm doing.
On Jun 08, 2015, at 08:13 AM, Piotr Ożarowski wrote:
>I use "python-" prefix for source package name only if the name is
>not unique enough.
Same.
-Barry
pgpBpCZep6NyA.pgp
Description: OpenPGP digital signature
On Jun 13, 2015, at 07:50 PM, Christoph Haas wrote:
>I'd like to pass maintenance of the "python-iplib" package to the python
>module team. Would anyone like to put their name onto it? Otherwise I'd
>keep my name there as maintainer or uploader. I'd prefer though if the
>team is the official maint
[Apologies for the cross-posting! -BAW]
For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the default
Python 3 version. It's currently undecided whether we will keep Python 3.4 as
a supported version, but a lot of that depends on how easily an archive port
to Python 3.5 goes. Ideally,
On Jun 24, 2015, at 10:55 AM, Alastair McKinstry wrote:
>I'd recommend we build python3-numpy against Python 3.5 for experimental. Of
>my packages in the list that FTBFS, I think all of them fail on numpy (some
>on cython), while numpy builds fine against Python 3.5. We can test the
>transition i
On Jun 24, 2015, at 11:13 AM, Sandro Tosi wrote:
>but it was the version from sid (1.8), not experimental (1.9)
Ah, gotcha. I'll look at syncing 1.9 to the PPA.
Cheers,
-Barry
pgpMlTmrrRzvg.pgp
Description: OpenPGP digital signature
It looks like we have a Build-Depends loop.
python-sphinx (sphinx) -> python3-gi (pygobject) -> python3-cairo (py3cairo)
-> python-sphinx
All FTBFS in the PPA. I'm guessing this loop was introduced after the
addition of Python 3.4, since it should affect every major Python version
transition.
I
On Jun 25, 2015, at 04:57 PM, Dmitry Shachnev wrote:
>Sphinx needs python3-gi only for tests, so I think it will be easier to
>break the loop here. Search for "jstest" in debian/rules and comment that
>line out.
Thanks, it might indeed be easier this way. py3cairo is a mess. :/
Cheers,
-Barry
On May 03, 2015, at 03:18 PM, Dmitry Shachnev wrote:
>I have finally managed to finalize Sphinx 1.3 upload for experimental.
Thanks! I just added the Python 3.5 compatibility patch from upstream
github to sphinx's svn.
>Also, if someone is interested in helping me to maintain Sphinx is Debian,
On Jun 29, 2015, at 08:06 PM, Dmitry Shachnev wrote:
>Your packages were failing with 1.3.1-1, but are not failing with svn build
>because I fixed the issue :)
Ah, I guess we need an ITP for snowballstemmer .
>FWIW I have went through Yaroslav's logs and filed bugs for most of the
>failing packa
On Jun 29, 2015, at 04:02 PM, Sandro Tosi wrote:
>I dont have a patch for sphinx to fix that, but what I say is that
>patching 59 packages to remove |today| instead of changing sphinx
>/somehow/ is a waste of resources.
Maybe upstream would accept a patch similar to what I've done before. It
cou
On Jun 29, 2015, at 11:43 PM, Tomasz Rybak wrote:
>Sorry for maybe stupid question - but do I need to do anything
>if PyOpenCL is on the list with green checkmark?
Generally, no, but if you can find any dependents of the package that are
FTBFS, then helping chase down the chain of problems would
As part of the 3.5 test rebuild I noticed an incompatibility with
python3-enum, which I reported upstream. The response was: there's actually
no reason to have a Python 3 version of enum in any version >= Python 3.4.
Since that's all we have now, maybe it makes more sense to just remove the
python
>> So I'd argue that ‘python3-mock’ and the like do have a place in Debian:
>> they make it easier to follow the recommended strategy of having a code
>> base run unchanged on Python2 and Python 3.
As it turns out, it looks like upstream enum34 is going to rename the import
to 'enum34' so it won't
On Jul 09, 2015, at 10:25 PM, Robert Collins wrote:
>I don't have a view on other packages.
As it turns out, enum34 is actually renaming its public package name so it
won't conflict with the stdlib name. I may end up keeping the python3 variant
after all.
Cheers,
-Barry
--
To UNSUBSCRIBE, em
On Jul 20, 2015, at 01:12 PM, Julien Cristau wrote:
>Is that a serious question? Why should debian-python, for no good
>reason, break things that work just fine?
Because it doesn't really work well when you are supporting both Python 2 and
Python 3. For example, if you have the 'foo' namespace
On Jul 20, 2015, at 01:12 PM, Dimitri John Ledkov wrote:
>Would it be fair to have a goal to only have PEP420 style namespaces
>in python3 world?
I think so, yes. Since we're integrators, I think it's fine for us to make
this decision, and deal with any fallout that might occur, though I think t
Back in June 2014, I filed bug #751908, which Piotr closed as wontfix. This
is really related to an open question in Python packaging concerning a
standard naming scheme for packages which provide Python applications
(e.g. /usr/bin scripts) whether or not they also provide importable libraries,
al
On Aug 06, 2015, at 04:20 PM, Simon McVittie wrote:
>Policy has this to say on the subject of a different flat global namespace:
>
>"When scripts are installed into a directory in the system PATH, the
>script name should not include an extension such as .sh or .pl that
>denotes the scripting langu
On Aug 06, 2015, at 05:08 PM, Piotr Ożarowski wrote:
>everything that doesn't match python[\d.]*- is fine IMHO.
Here's some language for DPP:
=== modified file 'debian/python-policy.sgml'
--- debian/python-policy.sgml 2015-02-27 23:09:27 +
+++ debian/python-policy.sgml 2015-08-06 19:04:4
On Aug 06, 2015, at 11:42 AM, Sandro Tosi wrote:
>no I mean, really, read http://pkg-perl.alioth.debian.org/git.html
Thanks for the link Sandro.
Reading this, I think it's on par with our
https://wiki.debian.org/Python/GitPackaging by which I mean it's prescriptive
of how to do common tasks in a
On Aug 07, 2015, at 11:30 AM, Sandro Tosi wrote:
>ehm.. Since you havent tried to create a perl package with
>dh-make-perl, I guess you missed much of its functionalities, like:
>
>* it downloads the tarball from CPAN
>* it populates the debian/ files with the information from module
>metadata (no
On Aug 07, 2015, at 02:37 PM, Sandro Tosi wrote:
>are we? when was the last update on it? from an external pov, there's
>not much happening on the matter
Yes, we really are. Stefano and I (mostly him) has spent a *ton* of time
getting the conversion scripts working for the vast majority of packa
On Aug 07, 2015, at 12:25 PM, Simon McVittie wrote:
>To avoid quilt(1), I use "gbp pq" instead. What I commit to git as a
>result interoperates with quilt(1), in the sense that someone like
>Sandro could clone one of my repositories, manipulate the patch queue
>with quilt(1), and not have to know
On Aug 09, 2015, at 10:15 AM, Steve M. Robbins wrote:
>In my defense: I did not say you need to use "sudo". All you need (at least
>for pyvtk) is privilege to write into /usr/local, so it is more like "rm -rf
>/usr/local" ... still damaging but not as dramatic. :-)
pip --user (no sudo) is fin
On Aug 15, 2015, at 08:24 PM, Vincent Bernat wrote:
>So, what's the situation? Should we do something during this Debconf?
JFDI. :)
Cheers,
-Barry
pgpTGp7yyBVyt.pgp
Description: OpenPGP digital signature
On Aug 19, 2015, at 04:11 PM, olivier sallou wrote:
>I'd like to "simple" package python-eta module[0]. Having a look at policy,
>I only see SVN repo [1]. Can't we package module using a git repo ?
We are very close to switching to git. I'm hoping it might actually happen
during Debconf, or soo
On Aug 19, 2015, at 12:43 PM, Barry Warsaw wrote:
>On Aug 19, 2015, at 04:11 PM, olivier sallou wrote:
>
>>I'd like to "simple" package python-eta module[0]. Having a look at policy,
>>I only see SVN repo [1]. Can't we package module using a git repo ?
&g
On Aug 19, 2015, at 07:41 PM, olivier.sal...@codeless.fr wrote:
>As I am not a regular contributor to the python-modules (only made a few),
>would you want to review the package once in git (when ready) before I upload
>? Or should I go when ready ? after reading again Python Policy of course
>;-
Just a quick follow-up I've been meaning to send.
On Jul 02, 2015, at 03:55 PM, Barry Warsaw wrote:
>As part of the 3.5 test rebuild I noticed an incompatibility with
>python3-enum, which I reported upstream. The response was: there's actually
>no reason to have a Python 3
Thanks for the summary Piotr! I was really sorry I couldn't make Debconf this
year.
On Aug 24, 2015, at 11:08 PM, Piotr Ożarowski wrote:
>Python 3.5 as supported
>===
>
>python3-defaults in experimental already has 3.5 as supported. Ubuntu did
>this change as well and report
On Aug 19, 2015, at 06:41 PM, Matthias Klose wrote:
>As a Debian developer you are duplicating code, and no, I don't think that
>providing this code under a different name is different enough to rectify
>distribution of this code in Debian.
In some cases however, the standalone library moves ahea
On Aug 25, 2015, at 10:03 AM, Robert Collins wrote:
>On 25 August 2015 at 09:57, Barry Warsaw wrote:
>...
>> By all means, if there isn't any
>> significant difference between a standalone package and what's available in
>> the current supported Python 3 v
On Aug 25, 2015, at 10:45 AM, Robert Collins wrote:
>Lets take Ironic. While it supports Python 2.7+ and 3.4+ it will
>depend on 'mock' for unit testing.
That's not unreasonable, and different upstreams will have different policies,
but if it was *my* upstream package, I'd probably do a condition
On Aug 25, 2015, at 11:30 AM, Robert Collins wrote:
>Except that that will break: mock in 3.4 vs 3.5 are different.
Then they aren't the same . So it sounds like it doesn't make sense to
remove python3-mock from Debian.
Cheers,
-Barry
pgpV2khUPaCtA.pgp
Description: OpenPGP digital signature
On Sep 02, 2015, at 09:06 PM, Robert Collins wrote:
>So this is perhaps the disconnect: I did not say the metadata should
>move: it should be in the private directory - it has to be adjacent to
>the packages/modules its describing, since if it is present but the
>package/module is not that is at t
On Sep 02, 2015, at 11:19 AM, Karsten Hilbert wrote:
>> That private directory must be on the python search path
>
>Maybe I'm a bit dense but isn't that what OP very much
>DOESN'T want to _happen_ ?
Not on the default sys.path, sure. But it has to get on sys.path at some
point before the applica
On Sep 14, 2015, at 04:26 PM, Scott Kitterman wrote:
>It seems very likely that we'll want to release Stretch with python3.5 as the
>default and only python3 version.
+1
>For packages that build fine with python3.5, there should be nothing required
>from a maintainer point of view. Except pycxx
On Sep 18, 2015, at 06:48 PM, Pierre-Elliott Bécue wrote:
>I'm currently trying to package mailman3 suite, I started with mailman3 core
>functionnalities, you can see the ITP here:
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799281
Thanks for working on this!
>
>But, mailman3-core would
On Sep 19, 2015, at 12:35 AM, Thomas Kluyver wrote:
>By the way, I am also upstream for flit, and I'm prepared to help build
>some tooling to use it for distro packaging. I know it will cause some
>inconvenience in the short term because there's infrastructure around
>setup.py packaging, but ultim
On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote:
>Once again, the python policy about Maintainer/Uploaders has been ignored
>
>either policy changes or this has to stop at some point.
A few observations.
The policy should perhaps be better promoted or more explicitly written. The
links you prov
On Sep 29, 2015, at 02:02 PM, Tristan Seligmann wrote:
>After reading this thread, I feel like I should go through all of my
>packages and remove the team from Maintainer for all of them. I try very
>hard to respond promptly to pings (bugs, email, IRC, ...) about my
>packages, even if it's just to
On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote:
>- I want lintian not to bug me about NMU ;
This one's easy. Just put "Team upload" in the changelog (e.g. `dch --team`).
Cheers,
-Barry
On Sep 29, 2015, at 04:30 PM, Piotr Ożarowski wrote:
>Maintainer vs Uploaders rules needs to be moved to policy. I will
>propose a patch to the policy soon (I'd prefer a native speaker to do
>it, though)
+1, and I'd be happy to review the specific text.
Cheers,
-Barry
On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
>(and remember to remove DPMT from debian/control if it's not in SVN ;P)
Given that the final git migration is imminent (really! otherwise I'm going to
scream ;), can we not force people to go through this churn right now?
Yes, let's discourag
On Sep 29, 2015, at 10:31 PM, Julien Puydt wrote:
>I still have a series of things I plan to package for Debian ; those are
>Python Modules, and I'll use git. If that's a problem for the Debian
>Python Modules Team, can you point me to a more appropriate team?
This illustrates my concern. We'v
On Sep 29, 2015, at 11:05 PM, Piotr Ożarowski wrote:
>but it's OK to force others to search for repo location, used workflow,
>tool, naming convention, etc?
No, definitely not! We have the svn we all know and love , and if it's
not there, then it can only otherwise be in git with the workflow an
On Oct 01, 2015, at 07:47 PM, Vincent Bernat wrote:
>I am a bit worried that the team is handled behind closed walls.
I have no particular interest in either grabbing power nor in taking power
away from anybody, but I think there may be some value in making team
governance more transparent and de
I know there's been a lot of questions about the schedule for the git
migration. Right now, Stefano is at PyconZA, so he hasn't had much time to
follow up here. But he and I discussed a schedule for the migration, and
we're sharing it now both so you know what's going on and so we have to stick
t
On Oct 02, 2015, at 11:28 AM, Piotr Ożarowski wrote:
>well, then you will not gain much from maintaining this package within a
>team
It's not just the maintainer that wins by maintaining the package within the
team. The team also wins because it is now empowered to fix problems when the
need ari
On Oct 02, 2015, at 09:46 PM, Sandro Tosi wrote:
>those are not many days to review the results of the conversions: can
>you (or Stefano) share what were the problems that delayed the
>transition, so that we can check in particular those aspects of the
>packages we know the most?
Stefano has put
On Oct 03, 2015, at 11:47 AM, Sandro Tosi wrote:
>what were the problems that -in the last period- delayed the conversion? were
>they just lack of time (understandable) or were they technical in the
>conversion process?
The very last patch I forwarded to Stefano involved correctly setting the tag
On Oct 03, 2015, at 03:50 PM, Sandro Tosi wrote:
>if the last is a strong requirement, honestly it seems fragile: ~/.gitconfig
>applies to all the git repos I have (and I may want to specify a tag format
>there), while what is set in debian/.git-dpm (is this the file where the tag
>format is set r
On Oct 03, 2015, at 08:52 PM, Stefano Rivera wrote:
>No significant failures, but I wanted to setup an mr config, which I've done
>now:
>https://anonscm.debian.org/cgit/python-modules/svn-migration/python-modules.git/
>The pkg-perl team has fancier tools, but they require more bookkeeping, so I
>m
On Oct 03, 2015, at 08:52 PM, Stefano Rivera wrote:
>So, here is a migration at r34461:
>https://anonscm.debian.org/cgit/python-modules/svn-migration/
>
>The errors:
Some of these may already be in git, and hopefully git-dpm so don't actually
need a conversion. If it's in git but not git-dpm, it
On Oct 04, 2015, at 08:03 PM, Sandro Tosi wrote:
>am I the only one thinking it's quite a huge number to be handled by
>hand? and whose hands will be the ones converting these packages?
>yours or Barry's dont seem enough and others will need training/time.
I'm happy to pitch in if a maintainer ne
On Oct 04, 2015, at 08:03 PM, Sandro Tosi wrote:
>and other 9, for a grand total of 109 packages that cannot be
>converted to git, 13.5% of DPMT (oh, what about PAPT?)
I've wondered about PAPT too. I don't touch those nearly as often, but
eventually yes, they should come under the same vcs regim
On Oct 04, 2015, at 08:31 PM, Sandro Tosi wrote:
>sorry, i forgot to ask another question: how will the packages already
>maintained in git be handled?
It should be easy. Just push it to the team's vcs. If it's not already in
git-dpm it's pretty easy to bootstrap. Essentially just one call to
On Oct 05, 2015, at 10:32 PM, Stefano Rivera wrote:
>Hi Barry (2015.10.05_17:51:41_+0200)
>> >and other 9, for a grand total of 109 packages that cannot be
>> >converted to git, 13.5% of DPMT (oh, what about PAPT?)
>>
>> I've wondered about PAPT too. I don't touch those nearly as often, but
>> e
On Oct 05, 2015, at 02:51 PM, Thomas Goirand wrote:
>In other distributions (Red Hat and Ubuntu), everyone is aware of this
>kind of issue before uploading, and this kinds of things don't happen.
Ubuntu at least does have a technical solution that helps ameliorate
archive-wide breakages, and that
On Oct 06, 2015, at 07:00 AM, Robert Collins wrote:
>The things you listed that I help maintain - mock, testtools, etc -
>are *not* OpenStack specific. They existed before OpenStack, and
>likely will exist after. They have other users, particularly mock
>which is very widely used.
I intensely dis
On Oct 05, 2015, at 10:57 AM, Scott Kitterman wrote:
>I agree that disabling package test suites doesn't improve their quality.
>Were these bad tests? Did you report these issues upstream?
Silently passing broken tests was one of a common pattern of issues I found
when making Python 3.5 suppor
On Oct 05, 2015, at 10:36 PM, Stefano Rivera wrote:
>How about: We move away existing repositories, and put the migrated ones
>in the /packages/ path. If people have existing repositories, that
>they'd prefer to use, they can move the migrated ones out the way, and
>theirs back. But they have to o
On Oct 05, 2015, at 09:16 PM, Mattia Rizzolo wrote:
>Isn't this the whole point of unstable→testing?
I guess, although it seems a lot of people run unstable so breakages affect
more people. I run unstable on most of my Debian machines. I think almost
nobody actually runs -proposed.
Cheers,
-Ba
On Sunday, October 04, 2015 11:54:18 PM Stefano Rivera wrote:
>There's a fundamental question to ask here. Do we want to welcome Python
>packages into the team, or do we want to put up barriers and require a
>level of commitment before packages can be brought into the team?
Thanks Stefano for sta
On Oct 03, 2015, at 08:52 PM, Stefano Rivera wrote:
>So, here is a migration at r34461:
>https://anonscm.debian.org/cgit/python-modules/svn-migration/
I did an update (not uploaded) of webob from this migration and it worked
perfectly. But it's a simple package without patches. I'll try a few m
On Oct 05, 2015, at 07:12 PM, Barry Warsaw wrote:
>I did an update (not uploaded) of webob from this migration and it worked
>perfectly. But it's a simple package without patches. I'll try a few more.
Similarly for ply 3.8. The nice thing here is that there were several quilt
On Oct 06, 2015, at 08:39 AM, Brian May wrote:
>On Tue, 6 Oct 2015 at 18:46 Thomas Goirand wrote:
>
>> This IMO is the same topic as having a Gerrit review system (and not
>> just Git) which could do tests on each change of a package even before
>> having them committed to our git.
>>
>
>Sounds l
On Oct 06, 2015, at 07:05 PM, Thomas Goirand wrote:
>Interesting. It's the first time I hear about it, I thought it was just
>closed source.
The instance at gitlab.com is the non-free Enterprise Edition (EE). EE has
features we probably don't care about ayway. The Community Edition (CE) is
MIT/
On Oct 06, 2015, at 03:12 PM, Fred Drake wrote:
>What CI tools are you using with GitLab CE?
We don't run CE; we use the hosted EE at gitlab.com. But anyway, we have a
custom VM on which we run the GitLab runner software in a docker image. This
runs our test suite in all supported Python 3s aga
On Oct 07, 2015, at 02:33 PM, W. Martin Borgert wrote:
>Quoting Piotr Ożarowski :
>> I assume you all like other ideas, like no team in Maintainer, right?
>
>To me, "team maintenance" would mean, that the team appears in the
>"Maintainer" field. In "Uploaders" it doesn't make sense, so where
>woul
On Oct 07, 2015, at 03:29 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2015-10-07]
>> * Team in Maintainers is a strong statement that fully collaborative
>> maintenance is preferred. Anyone can commit to the vcs and upload as
>> needed. A courtesy email to Uploader
In the upstream Python project, we recently created a new mailing list as a
focal point for cross-distro Linux-specific issues. I invite all interested
folks to join and help make Python better on Linux.
https://mail.python.org/mailman/listinfo/linux-sig
Feel free to spread the announcement of t
On Oct 07, 2015, at 04:08 PM, Piotr Ożarowski wrote:
>I meant to use your exact words, see attachment
+1 !
Cheers,
-Barry
On Oct 08, 2015, at 05:34 AM, Ben Finney wrote:
>Is it already available at GMane?
It's been requested and acknowledged, and I resent a message to kick off
creation of the newsgroup, but I don't see it there yet and the gmane.org
website seems offline for me atm.
Cheers,
-Barry
On Oct 08, 2015, at 07:32 AM, Ben Finney wrote:
>When you receive notification the group is created, please let that mailing
>list[0] know the GMane group name so its readers know where they can
>subscribe.
It will be gmane.comp.python.linux-sig
Cheers,
-Barry
Thanks for the feedback. I did rewrite this a little bit, so hopefully it's
clearer. I left some of the text in there because at least to me it reads
better and provides some rationale for why the rules are there. But hey, it's
a wiki so please feel free to make further improvements!
Cheers,
-B
On Oct 07, 2015, at 05:06 PM, Barry Warsaw wrote:
>It will be gmane.comp.python.linux-sig
The newsgroup is live and they named it gmane.comp.python.linux
Cheers,
-Barry
pgpuNgEFo1i8B.pgp
Description: OpenPGP digital signature
On Oct 08, 2015, at 11:15 AM, Brian May wrote:
>Maybe in this case I should file a bug report however.
I do this when the PyPI tarball is missing some important file or directory.
Fortunately the upstreams I've done this with have generally been very
responsive about fixing the problem and doing
On Oct 08, 2015, at 09:19 PM, Brian May wrote:
>What is the best way of calling unittest2 from debian/rules?
For --buildsystem=pybuild, I've done this:
override_dh_auto_test:
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="{interpreter} -m nose2 -vv" \
dh_auto_
On Oct 08, 2015, at 11:53 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2015-10-08]
>> For --buildsystem=pybuild, I've done this:
>>
>> override_dh_auto_test:
>> PYBUILD_SYSTEM=custom \
>> PYBUILD_TEST_ARGS="{interpreter} -
On Oct 09, 2015, at 10:01 AM, Stefano Rivera wrote:
>And it's done.
\o/
Thank you for all your amazing work on this Stefano!
>Things that need to be looked at:
>http://whiteboard.debian.net/dpmt-git-migration.wb
>
>Please mark them off if you've looked at them.
I've done an updating pass throu
On Oct 09, 2015, at 06:46 PM, Arthur de Jong wrote:
>Perhaps an email to d-d-announce would be in order.
Good idea, thanks.
-Barry
pgpt4EKqpYkKX.pgp
Description: OpenPGP digital signature
On Oct 09, 2015, at 10:30 PM, Brian May wrote:
>Ok, I probably should create another thread to discuss this for Django then.
>
>Also, contrary to the rules we just agreed on, this sounds like one rare
>time when all uploaders should be contacted before moving any repositories
>around.
Probably so
On Oct 10, 2015, at 09:13 AM, Raphael Hertzog wrote:
>Yes, except for the naming of branches where I would prefer to keep the
>DEP-14 naming scheme (we should just rename debian/sid into debian/master).
>
>http://dep.debian.net/deps/dep14/
>
>And I would suggest that we generalize the DEP-14 namin
On Oct 10, 2015, at 12:18 PM, Ben Finney wrote:
>You need to specify which username to connect to over SSH. I have
>updated the Wiki page above to clarify this.
Hmm, I'm not sure about this recommendation. I don't include my user name in
the url, and I'm pretty sure Mattia's suggestion to set th
On Oct 10, 2015, at 04:19 AM, Brian May wrote:
>According to the wiki I do this with the following command:
>
>brian@prune:~/tree/debian/python-modules/django-ajax-selects$ git-dpm tag
>git-dpm: ERROR: tag 'upstream/1.3.6' already exists and differs!
>
>This wasn't the response I was expecting. I
On Oct 12, 2015, at 05:27 AM, Brian May wrote:
>As far as I know this actually did work despite the complaining about no
>parent commit... What does that mean?
No idea, but I've seen it before. I don't think it has any negative effect.
>git-dpm import-new-upstream --ptc --rebase-patched
>../dja
On Oct 12, 2015, at 05:22 AM, Brian May wrote:
>git push --tags
>Total 0 (delta 0), reused 0 (delta 0)
>remote: Sending notification emails to:
>python-modules-comm...@lists.alioth.debian.org,
>python-django_...@packages.qa.debian.org
>remote: Sending notification emails to:
>python-modules-comm..
On Oct 12, 2015, at 11:57 AM, Piotr Ożarowski wrote:
>transition is not over, our policy still mentions SVN only...
Unless I'm missing it, not in python-policy.sgml (Debian Python Policy) though.
Cheers,
-Barry
On Oct 11, 2015, at 12:28 AM, Brian May wrote:
>What branches do I need to put the debian/README.source file in? There are
>six debian/* branches, don't think it is a good idea to try and maintain a
>consistent debian/README.source in all branches.
>
>Maybe debian/experimental would be sufficient?
n-Canonical Vcs fields
I think the codespeak-lib source package is obsolete.
>python-pex: Non-Canonical Vcs fields
I guess this means that the Vcs-* headers are not of the format defined in
https://wiki.debian.org/Python/GitPackaging right? I fixed python-pex (not
yet uploaded
On Oct 14, 2015, at 01:26 PM, Piotr Ożarowski wrote:
>> export PYBUILD_TEST_ARGS={dir}/tests
>
>should I do that by default in pybuild if
>* "test" or "tests" directory is detected
>* PYBUILD_TEST_ARGS is not set
>* nose or pytest test suite is used
>
>?
Maybe just on the first two conditions, on
On Oct 14, 2015, at 04:28 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2015-10-14]
>> On Oct 14, 2015, at 01:26 PM, Piotr Ożarowski wrote:
>>
>> >> export PYBUILD_TEST_ARGS={dir}/tests
>> >
>> >should I do that by default in pybuild if
On Oct 17, 2015, at 08:49 PM, Piotr Ożarowski wrote:
>I moved policy.rst to python-modules.git repo (it was available to edit
>by every team member in SVN as well). It's not OK to edit it and push it
>without having a discussion here (on this mailing list) first, though.
I will make a pass throug
601 - 700 of 859 matches
Mail list logo
