Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Tristan Seligmann
On 16 October 2014 20:12, Hans-Christoph Steiner wrote: > > > Tristan Seligmann wrote: >> If you are fetching the upstream revisions / tags into your packaging >> repository, you can use the upstream tag exactly as-is, no need to >> re-tag (and indeed re-tagging would generally be a bad idea). > >

Re: How to solve #751375, file clash

2014-10-16 Thread Tristan Seligmann
On 16 October 2014 23:55, Brian May wrote: > Is the configparser.py supplied by python-pies2overrides different from the > file supplied by python-configparser? > > If it is the same file, you could delete it from python-pies2overrides and > depend on python-configparser. The pies2overrides conf

Re: How to solve #751375, file clash

2014-10-16 Thread Scott Kitterman
On October 16, 2014 5:49:37 PM EDT, Per Andersson wrote: >Hi! > >A while ago I uploaded python-pies to the archive, a dependency >for frosted which is also in the archive. > >One of the binary packages python-pies2overrides, has an >important bug; it overwrites configparser.py, which is also insta

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Charles Plessy
Le Thu, Oct 16, 2014 at 02:12:40PM -0400, Hans-Christoph Steiner a écrit : > > I think there is a lot of value to always including the Debian upstream/v1.0 > tag. It provides a standard way to access the upstream version across all > repos. There is no such standard out there "in the wild". The

Re: How to solve #751375, file clash

2014-10-16 Thread Brian May
On 17 October 2014 08:49, Per Andersson wrote: > One of the binary packages python-pies2overrides, has an > important bug; it overwrites configparser.py, which is also installed > by python-configparser. > Is the configparser.py supplied by python-pies2overrides different from the file supplied

How to solve #751375, file clash

2014-10-16 Thread Per Andersson
Hi! A while ago I uploaded python-pies to the archive, a dependency for frosted which is also in the archive. One of the binary packages python-pies2overrides, has an important bug; it overwrites configparser.py, which is also installed by python-configparser. I have forwarded this bug upstream.

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Hans-Christoph Steiner
Tristan Seligmann wrote: > On 16 October 2014 18:01, Thomas Goirand wrote: >> Using pristine-tar and pulling from upstream VCS is silly. If you do >> like this, then why not just doing tag-based packaging? That's a lot >> safer than just re-tagging on top of what upstream does (ie: no risk to >>

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Hans-Christoph Steiner
Thomas Goirand wrote: > On 10/12/2014 05:15 PM, Tristan Seligmann wrote: >> I wasn't at Debconf, maybe this is why I'm a bit confused by what you >> wrote here. pristine-tar and upstream VCS merge are in no way mutually >> exclusive, but you seem to be implying that they are > > Using pristine-t

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Hans-Christoph Steiner
Thomas Goirand wrote: > On 10/12/2014 05:15 PM, Tristan Seligmann wrote: >> I wasn't at Debconf, maybe this is why I'm a bit confused by what you >> wrote here. pristine-tar and upstream VCS merge are in no way mutually >> exclusive, but you seem to be implying that they are > > Using pristine-t

Re: Request to join the team

2014-10-16 Thread Alexandre Viau
I should have mentioned, my alioth account is reazem-guest. Alexandre Viau alexan...@alexandreviau.net On Thu, Oct 16, 2014 at 1:11 PM, Alexandre Viau wrote: > Hello Pythonistas, > > I have always wanted to become a Debian Developer and now > is the time to start working on it. I have decided t

Request to join the team

2014-10-16 Thread Alexandre Viau
Hello Pythonistas, I have always wanted to become a Debian Developer and now is the time to start working on it. I have decided to package a few projects that I like and I would like to join the Python Team to collaborate on them. - influxdb-python: Client lib for influxdb. I am a contributor - p

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Simon McVittie
On 16/10/14 18:01, Tristan Seligmann wrote: > The purpose of pristine-tar is the same whether you base it on a > revision fetched from upstream, or a revision created by > git-import-orig or a similar tool ... or a revision created by "git-import-orig --upstream-vcs-tag=v1.2.3", which has the cont

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Tristan Seligmann
On 16 October 2014 18:01, Thomas Goirand wrote: > Using pristine-tar and pulling from upstream VCS is silly. If you do > like this, then why not just doing tag-based packaging? That's a lot > safer than just re-tagging on top of what upstream does (ie: no risk to > introduce any difference). If y

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Thomas Goirand
On 10/12/2014 05:15 PM, Tristan Seligmann wrote: > I wasn't at Debconf, maybe this is why I'm a bit confused by what you > wrote here. pristine-tar and upstream VCS merge are in no way mutually > exclusive, but you seem to be implying that they are Using pristine-tar and pulling from upstream VCS

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Hans-Christoph Steiner
Barry Warsaw wrote: > On Oct 16, 2014, at 09:26 AM, Tristan Seligmann wrote: > >> I would expect it to make merging / rebasing Debian patches on top of >> a new upstream version easier, since you have the granular history of >> changes to the source tree, not one massive single commit which may

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Barry Warsaw
On Oct 16, 2014, at 09:26 AM, Tristan Seligmann wrote: >I would expect it to make merging / rebasing Debian patches on top of >a new upstream version easier, since you have the granular history of >changes to the source tree, not one massive single commit which may >not be accurate (eg. renames of

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Tristan Seligmann
On 13 October 2014 00:19, Barry Warsaw wrote: > Maybe not mutually exclusive, but what's the point? I certainly would not > base the Debian packaging on anything but the upstream tarball, and most git > workflows provide those as an unpacked upstream source branch. Does upstream > vcs add value?