dh-python piuparts problem?

I like to run `sbuild --run-piuparts blah.dsc` before I upload a new package version. I've seen this failure on a number of packages now, but I haven't had time to dig into it in detail. I'm not sure if it's a problem in the individual packages, or a bug in dh-python. I should file a bug. Has

New pip/virtualenv stack

I just uploaded virtualenv 14.0.5+ds-1 I'm hoping that this repairs the whole pip/virtualenv stack. It does for me in all my local testing, and all the DEP-8 tests pass (again, locally). Some headers for pip apparently got lost when I merged branches, so it's entirely possible there are still

Re: How to put experimental upload into git

On Feb 01, 2016, at 08:10 AM, Nikolaus Rath wrote: >Commit to a new branch that then becomes dangling, because the next upload to >unstable descends from the most-recent unstable upload rather than from >experimental. I haven't done this specifically, but I have used branches w/git-dpm. I can't

Re: New, updated pip coming

On Feb 01, 2016, at 03:01 PM, Piotr Ożarowski wrote: >Did you consider creating whl files at install time¹ rather than pip's >build time? This way whl can be regenerated whenever one of needed >packages is updated and there's no need to rebuild pip package. > >[¹] using dpkg (file) triggers

Re: New, updated pip coming

On Jan 30, 2016, at 11:33 AM, Robert Collins wrote: > If a new requests package is built, uploaded to the archive and >apt-get installed on my machine, and I then do: >virtualenv test >. test/bin/activate >pip install foobar > ^--- what version of requests will be used by this in-virtualenv

New, updated pip coming

TL;DR By the end of today, I expect to upload pip 8.0.2 to unstable, finally bringing us up to the latest version. It's been a long slog, with many people helping out. I hope that all the hard work done to get us here means it will be much, much easier to track new pip, virtualenv, and pyvenv

Re: mkdocs locale error building djangorestframework

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, >... 

Re: Python Policy: Things to consider for Stretch

Thanks for taking this on Ben, On Jan 24, 2016, at 04:33 PM, Ben Finney wrote: >I think you're right that this needs a general clean-up through the >policy document, to consistently use: > >* “python2” to refer to that command only; > >* “python3” to refer to that command only; > >* “python” to

Re: Python Policy: Things to consider for Stretch

On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote: >Personally I seriously dislike the trend to call Python Python 2 (and I still >thing approving a pep to invent /usr/bin/python2 because Arch went insane was >a horrible idea). There's an earlier spot in the document where it says that

Re: Amend Debian Python Proposal to Include More Python Metadata?

Hey Donald, thanks for starting this conversation. I for one am super appreciative of all the consideration you give for Debian's little slice of the world. There's a lot to unpack in this thread, and I'm a little under the weather[1], so hopefully this makes sense. Big +1 for recording the

Re: Python Policy: Things to consider for Stretch

On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote: >I've taken a run through the current Python Policy to see where I think it >needs to be updated for Stretch. Thanks Scott for the badly needed update. Some comments, apologies for the lack of good quoting, or if I've read the diff

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Jan 22, 2016, at 05:50 PM, Donald Stufft wrote: >Forget that pip can fetch files from PyPI and install them for a moment and >consider the command ``pip install .``. Fundamentally this is similar to the >command ``make install`` right? Please remind me what the long term plan for this is.

Re: Updating python-jsmin

On Jan 14, 2016, at 02:45 PM, gustavo panizzo (gfa) wrote: >Usually I generate the orig.tar.gz from git tags myself (gbp will do it for >you) and upload that. if the pkg needs a -2 release I base on that, I never >used pristine-tar Team policy is to use PyPI tarballs and pristine-tar workflow

Re: Bug#810136: transition: python3-defaults (python3.5 as default python3)

On Jan 06, 2016, at 01:34 PM, Nikolaus Rath wrote: >If necessary, s3ql can also be build with cython instead of cython3. I strongly suspect this is a regression due to http://bugs.python.org/issue22995 which I've now reopened. We're probably just starting to see the unintended consequences of

Re: RFS: twistar (Was: Request to join)

On Jan 04, 2016, at 04:41 AM, Giovanni Pellerano wrote: >i was reading https://lists.debian.org/debian-python/2015/10/msg00267.html >while working on GlobaLeaks (https://github.com/globaleaks/GlobaLeaks) >and evaluate it's adoption as replacement for python-storm that >appears not to be an

Re: Switching Default Python3 To Python3.5

On Dec 31, 2015, at 04:44 AM, Scott Kitterman wrote: >Does anyone object if I go ahead and ask the release team for a transition >slot? +1 and thanks! -Barry

Re: Help with pytest 2.8.5

Thanks for the suggestions Tristan & Piotr, On Dec 17, 2015, at 01:15 PM, Piotr Ożarowski wrote: >> diff --git a/debian/rules b/debian/rules >> index f473395..3c2f918 100755 >> --- a/debian/rules >> +++ b/debian/rules >> @@ -59,8 +59,9 @@ override_dh_clean: >> override_dh_auto_test: >> ifeq

Help with pytest 2.8.5

I've been working on an update to pytest 2.8.5, but I'm stuck and I'm hoping someone here can help. The DPMT git repo is up-to-date with my latest work if you'd like to check the branches out and try to debug the builds. I've made some significant changes to the packaging by switching it to

Re: Rebuild for packages with entry points?

On Dec 08, 2015, at 08:48 AM, Nikolaus Rath wrote: >Aeh, you know about a bug and you want to delay fixing it until someone >has reporeds it for every affected package? This seems like a pretty >inconsiderate waste of time for both users and maintainers. There are always lots of bugs that affect

Re: Rebuild for packages with entry points?

On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote: >Would it make sense to do a no-change rebuild for all Python packages >that use setuptool's entry point functionality? > >It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/ >fixed in stretch. I believe most packages will see

vim & Python 3 (was Re: vim-khuno: live Python checking within vim via flakes (in testing))

On Dec 03, 2015, at 08:45 AM, Edward Betts wrote: >I've packaged a vim plugin that provides live code checking for Python 2 and 3 >using pyflakes. Speaking of vim, some work needs to be done along the port-to-Python-3 path. I think vim still only builds against Python 2. As part of this issue:

git-dpm tag possible gotcha

I've occasionally seen this when I try to `git-dpm tag`: git-dpm: ERROR: 'upstream' differs from recorded one! In the past I've just done `git-dpm tag --refresh-upstream` but I think that's not the right thing to do. I think this means that you've `git pull`d while in master and the upstream

Re: How to maintain multiple branches (sid/bpo/exp etc)?

On Nov 02, 2015, at 09:51 PM, Sandro Tosi wrote: >with the new DPMT repo layout and tools, what is the right way to >maintain multiple active branches for our packages? things like: > >1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2 >2. unstable at v1, experimental at v2 > >all of them

Re: How to maintain multiple branches (sid/bpo/exp etc)?

On Nov 02, 2015, at 11:07 PM, Sandro Tosi wrote: >I dont think I follow your description: looking at the debian repo, stable >has 1.5.6-5 while testing and unstable has 1.5.6-7; looking at the git repo >(as of http://anonscm.debian.org/cgit/python-modules/packages/python-pip.git) >all the

DPMT policy update

Since comments have stopped, I've updated DPMT policy: http://python-modules.alioth.debian.org/policy.html so now (g)it's official. Cheers, -Barry pgpJPM1vPmxy6.pgp Description: OpenPGP digital signature

Re: How to maintain multiple branches (sid/bpo/exp etc)?

On Nov 03, 2015, at 12:03 AM, Sandro Tosi wrote: >1. I have a simple package, which I keep maintaining with the usual >'master' and 'upstream' branches, but then the testing freeze will >come and I want to start uploading to experimental, at that point I >need to change the layout of the repo

Re: dh-python (pybuild + dh_py*) documentation

On Oct 28, 2015, at 05:59 PM, Piotr Ożarowski wrote: >Each day I choose a victim and enable Piotr's evil mode. Beware the Eye of Piotr. :) -Barry

Re: dh-python (pybuild + dh_py*) documentation

On Oct 26, 2015, at 06:28 PM, Raphael Hertzog wrote: >I for one lack a high level presentation of how the various bits work together >and a clear description of the "magic" behind each tool. I agree with this. When you know where to look, the documentation is actually quite good. Maybe there

Re: RFS: numpydoc 0.5-1

On Oct 26, 2015, at 12:33 PM, Christoph Groth wrote: >Denis Laxalde wrote: > >> I'd like to request sponsorship for numpydoc, which had a new > upstream >> release, the first supporting Python 3. It's available > in python-modules >> SVN repository (I can upload it on mentors if > that helps).

Re: pristine-tar (was: Git migration schedule)

On Oct 22, 2015, at 01:04 PM, W. Martin Borgert wrote: >So far, it just seems to work for (most of?) us. Yep, pretty much. Cheers, -Barry

Re: Git migration schedule

On Oct 22, 2015, at 09:09 AM, Raphael Hertzog wrote: >Yeah :( That makes another point that was missed in the evaluation of >git-dpm vs git-buildpackage and its "gpb pq" command. When we started down this road, `gbp pq` was pretty unusable and git-dpm was much better (IMHO, others who did

Re: Python Policy

On Oct 22, 2015, at 11:14 AM, IOhannes m zmölnig (Debian/GNU) wrote: >thanks for gender neutral wording. however, you missed one "his" in the >first sentence (probably more in other paragraphs). Got it, thanks. -Barry pgpm4DkniheG1.pgp Description: OpenPGP digital signature

Re: Python Policy

On Oct 22, 2015, at 11:11 AM, IOhannes m zmölnig (Debian/GNU) wrote: >something else i wonder whether we shouldn't drop it, as i don't quite >understand why it has to be in the policy. > >i *think* it's supposed to urge DDs into becoming team members, even though >they can ("are able to") already

PyPI wheels (was Re: Python Policy)

On Oct 21, 2015, at 08:47 PM, Brian May wrote: >in one case this is because upstream have only supplied a *.whl >file on Pypi. I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads. There is talk about source wheels, and if that happens we'll probably have to adjust our tools

Re: DPMT Policy

On Oct 21, 2015, at 02:06 PM, Piotr Ożarowski wrote: >Only version to version upstream changes should be kept in the repository - >complete upstream git history should be avoided. In order to make it >easier to cherry-pick upstream commits as patches, add remote repository >(example below). > >

Re: Git migration schedule

On Oct 21, 2015, at 08:36 AM, Sandro Tosi wrote: >I need to backport quite some packages, and use often experimental to >stage big packages new releases (think of numpy and matplotlib) so it >is not a rare situation at all and it should be considered now that we >are at the beginning of a new era

Re: DPMT Policy

On Oct 22, 2015, at 08:32 AM, Ben Finney wrote: >+1 > GOML -Barry :)

Re: Python Policy

<hert...@debian.org> +:Author: Gustavo Franco <stra...@debian.org>, Raphaël Hertzog <hert...@debian.org>, Barry Warsaw <ba...@debian.org> :License: GNU GPL v2 or later :Introduction: - Python Modules Packaging Team aims to improve the python modules situation

Re: Python Policy

On Oct 20, 2015, at 12:37 AM, Piotr Ożarowski wrote: >should we also document that we're not OpenStack Packaging Team? Or zope-packaging? . Agreed that there are different teams here, but I am hoping that we can do some consolidation. E.g. I posted on the zope list that I'd like to pull those

Re: Python Policy

gt; +:Author: Gustavo Franco <stra...@debian.org>, Raphaël Hertzog <hert...@debian.org>, Barry Warsaw <ba...@debian.org> :License: GNU GPL v2 or later :Introduction: - Python Modules Packaging Team aims to improve the python modules situation - in Debian, by packaging availa

Re: Python Policy

On Oct 20, 2015, at 05:16 PM, Piotr Ożarowski wrote: >I will leave this team the moment I have to read README.sources each day when >I sponsor a package. Nobody wants that! (either you leaving or having to read README.source for every package). Cheers, -Barry

Re: Python Policy

On Oct 21, 2015, at 11:17 AM, Ben Finney wrote: >On the contrary, I think the Policy document should document the >rationale for contingent decisions like this. When it is inevitably >discussed again in the future, it is always better to know the intent of >the authors. +1 Cheers, -Barry

Re: Python Policy

On Oct 20, 2015, at 11:30 PM, Piotr Ożarowski wrote: >I have few comments, but even if I didn't, please wait at least until after >the weekend (or better: 7 days) so that others have time to review it and >comment / propose changes. Fair enough. Of course, it's in a vcs so it's easy to change!

Re: git instead of svn in DPMT policy

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

Python Policy

So we currently have several places where we have team policy described. * The Debian wiki https://wiki.debian.org/Python and subpages * Another wiki page: https://wiki.debian.org/Teams/PythonModulesTeam * https://www.debian.org/doc/packaging-manuals/python-policy/ which comes from the

Re: Git migration schedule

On Oct 18, 2015, at 07:19 PM, Jean-Michel Vourgère wrote: >Git multiple remotes is a nice feature. We can plug right into upstream >tree. Currently, our git workflow is tarball-based, since we primarily package PyPI releases, which are tarball-centric, and because orig.tar is required for

Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

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

Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

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,

Re: git repo lint tool

l 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). >Bar

Re: Request to join

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

Re: warnings importing new upstream source

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

Re: errors pushing tags to git

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:

Re: Git migration schedule

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

Re: python-django

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

Re: tagging releases in git

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

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: Python < 3.5 tests

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

Re: Python < 3.5 tests

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} -m nos

Re: Python < 3.5 tests

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" \

Re: Python/LibraryStyleGuide: Executables and library packages dokonana przez BarryWarsaw

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,

linux-sig

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

Re: team vs individual as maintainer (was: radical changes)

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

Re: team vs individual as maintainer

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

Re: linux-sig

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

Re: managing transitions (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

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

Re: managing transitions

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

Re: managing transitions

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

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

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

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

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

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

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,

Re: [DPMT] radical changes: automation, carrot and stick

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

Re: Git migration schedule

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

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

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

Re: Git migration schedule

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 >>

Re: Git migration schedule

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 patches th

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: Git migration schedule

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,

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: Git migration schedule

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

Re: I've been removed from the Python team

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

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

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

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

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

Re: Maintainer vs. Uploaders

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

Re: lintian and team uploads

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

Re: Dealing with flit -- a simplified packaging of python modules

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

Re: About OpenStack, Mailman3 and python-falcon update

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

Re: Python 3.5 as a supported python3 version

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

Re: Application libraries private, Distutils metadata available for console scripts and introspection

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

Re: Application libraries private, Distutils metadata available for console scripts and introspection

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

Re: Python BoF at DebConf15 - summary

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 reported

Re: Removing some python3-* packages

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 version of enum in any

Re: Removing some python3-* packages

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 ahead

Re: Removing some python3-* packages

On Aug 25, 2015, at 10:03 AM, Robert Collins wrote: On 25 August 2015 at 09:57, Barry Warsaw ba...@debian.org 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 version, let's not ship

Re: Removing some python3-* packages

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

<    1   2   3   4   5   6   7   8   >