Re: Keeping upstream commits separate from Debian packaging commits
On 13 October 2014 00:19, Barry Warsaw ba...@debian.org 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? 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 change files may not be detected etc.). On the flip side, if there are few or no patches to the upstream source, then it probably doesn't matter much at all. In any case, if upstream vcs is included in the team git repo, then I think it's incumbent on maintainers of those packages to document that in README.source (both how it's done and *why*) and to ensure that notifications of upstream commits are suppressed to team mailing list and IRC. I do think the benefits of team maintenance are diminshed quite a lot when packages need to have such specialized instructions, so aiming for a standardized workflow / configuration (*whatever* that might be!) is valuable. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camckhmtkd09xajtrnxtcxj6qdbpfmaqxjwoqdbycx1twdhb...@mail.gmail.com
Re: Keeping upstream commits separate from Debian packaging commits
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 change files may not be detected etc.). On the flip side, if there are few or no patches to the upstream source, then it probably doesn't matter much at all. Yep. I get that, although it ought not to be *too* hard usually to just clone upstream separately and generate patches from there. But agreed that if there are a lot of those such things, it can be less convenient. I do think the benefits of team maintenance are diminshed quite a lot when packages need to have such specialized instructions, so aiming for a standardized workflow / configuration (*whatever* that might be!) is valuable. Fully agreed. I feel strongly that we want to preserve the current team default where you can essentially just debcheckout any team package and not have to guess about its workflow. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016095937.1f8ea...@anarchist.wooz.org
Re: Keeping upstream commits separate from Debian packaging commits
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 not be accurate (eg. renames of change files may not be detected etc.). On the flip side, if there are few or no patches to the upstream source, then it probably doesn't matter much at all. Yep. I get that, although it ought not to be *too* hard usually to just clone upstream separately and generate patches from there. But agreed that if there are a lot of those such things, it can be less convenient. Having the upstream commits in the packaging repo is also quite useful if you need to make a release that is not an official one, like based on a specific commit rather than a tag. It also makes it easier to manage generating an orig tarball if upstream does not make one. If the upstream git is very active, then it can be annoying to follow the packaging commits. I do think the benefits of team maintenance are diminshed quite a lot when packages need to have such specialized instructions, so aiming for a standardized workflow / configuration (*whatever* that might be!) is valuable. Fully agreed. I feel strongly that we want to preserve the current team default where you can essentially just debcheckout any team package and not have to guess about its workflow. Cheers, -Barry I also agree, a standard, documented workflow is very valuable. .hc -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fdc14.4040...@at.or.at
Re: Keeping upstream commits separate from Debian packaging commits
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 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). Using upstream tags *without* using pristine-tar would seem to be inadvisable For what reason exactly? In what way pristine-tar helps when basing your packaging on upstream Git tags? I haven't seen anyone write importing upstream VCS into the Alioth repo is forbidden anywhere; if this is the intent, then perhaps it should be clearly spelled out somewhere. (Or perhaps it already is, and I just missed it? In which case, whoops) Hum... Then maybe we should talk again. On 10/13/2014 06:19 AM, Barry Warsaw wrote: Does upstream vcs add value? Of course! Lots of value. One of them is that you'd be downloading tiny deltas, instead of constantly downloading a tarball, doing git-import-orig, etc. Another one is doing cherry-picking of changes. Another one is being able to do a Debian package based on any commit from upstream, if you do need that. Finally, it makes it easier for you to send a patch upstream based on your debian-specific patch (just grab it from your debian/patches folder, apply to the master branch, then git review or git push to github/bitbucket/git-cafe/you-name-it...). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543febf4.7010...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
On 16 October 2014 18:01, Thomas Goirand z...@debian.org 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 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). Using upstream tags *without* using pristine-tar would seem to be inadvisable For what reason exactly? In what way pristine-tar helps when basing your packaging on upstream Git tags? 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: it allows you to produce the original byte-for-byte tarball from the git repository, without having to store the tarball itself in the repository in addition to the contents of the tarball. (Although apparently it does not always succeed at doing this...) For most software, the primary distribution mechanism is a tarball released by upstream on their website, their project hosting service, or on a service like PyPI. If such a tarball exists, and is suitable for use in Debian, then having the upstream source in Debian match the tarball distributed by upstream byte-for-byte makes it much easier to verify that the source in Debian is unmodified from the upstream source. This is harder when the tarball is generated from a git tag: the source package does not include the information necessary to match it against the git tag, comparing the individual files is necessary instead of comparing the archive, and producing the upstream source (.orig.tar.gz) will produce a tarball with different bytes every time (even if the file contents will not change). Alternatively, if you will never generate the upstream source from the git repository, then you avoid this problem, but then building a particular package version may require manually fetching the correct tarball from the archive / snapshot.debian.org if they are no longer available from the original source. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camckhmsh34wrxyyb-bg_qprsugrupadhwswqk4zol+ocids...@mail.gmail.com
Re: Keeping upstream commits separate from Debian packaging commits
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 contents of the tarball as its tree, and two parent commits (a pseudo-merge): the upstream VCS tag v1.2.3, and the previous tarball. This seems like the best of both worlds, assuming IRC/email commit bots filter out the upstream-only commits in its ancestry. Alternatively, if you will never generate the upstream source from the git repository, then you avoid this problem, but then building a particular package version may require manually fetching the correct tarball from the archive / snapshot.debian.org if they are no longer available from the original source That's assuming the correct tarball is even in the archive. For un-uploaded packages for which a sponsored upload was requested, you need to obtain a compatible tarball in some out-of-band way. For packages in NEW, it's worse: you need to obtain precisely the same tarball that's already in NEW in some out-of-band way. S -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fff3c.60...@debian.org
Request to join the team
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 - python-riemann-client: Client lib for riemann. I am a contributor - python-click: optparse wrapper, dependency of python-riemann-client - shinkenplugins: Lib to write Shinken/Nagios plugins. I am upsteam You may take a look at my packages here: (https://mentors.debian.net/packages/uploader/alexandre%40alexandreviau.net) Thanks, Alexandre Viau alexan...@alexandreviau.net
Re: Request to join the team
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 alexan...@alexandreviau.net 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 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 - python-riemann-client: Client lib for riemann. I am a contributor - python-click: optparse wrapper, dependency of python-riemann-client - shinkenplugins: Lib to write Shinken/Nagios plugins. I am upsteam You may take a look at my packages here: ( https://mentors.debian.net/packages/uploader/alexandre%40alexandreviau.net ) Thanks, Alexandre Viau alexan...@alexandreviau.net
Re: Keeping upstream commits separate from Debian packaging commits
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-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). Using upstream tags *without* using pristine-tar would seem to be inadvisable For what reason exactly? In what way pristine-tar helps when basing your packaging on upstream Git tags? I think its quite useful since it will show you differences between the upstream git repo, and the upstream orig tarballs. From my experience, they are different most of the time, and I have caught bugs in upstream's tarballs by doing this. .hc I haven't seen anyone write importing upstream VCS into the Alioth repo is forbidden anywhere; if this is the intent, then perhaps it should be clearly spelled out somewhere. (Or perhaps it already is, and I just missed it? In which case, whoops) Hum... Then maybe we should talk again. On 10/13/2014 06:19 AM, Barry Warsaw wrote: Does upstream vcs add value? Of course! Lots of value. One of them is that you'd be downloading tiny deltas, instead of constantly downloading a tarball, doing git-import-orig, etc. Another one is doing cherry-picking of changes. Another one is being able to do a Debian package based on any commit from upstream, if you do need that. Finally, it makes it easier for you to send a patch upstream based on your debian-specific patch (just grab it from your debian/patches folder, apply to the master branch, then git review or git push to github/bitbucket/git-cafe/you-name-it...). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544008a4.9060...@at.or.at
Re: Keeping upstream commits separate from Debian packaging commits
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-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). Using upstream tags *without* using pristine-tar would seem to be inadvisable For what reason exactly? In what way pristine-tar helps when basing your packaging on upstream Git tags? I think its quite useful since it will show you differences between the upstream git repo, and the upstream orig tarballs. From my experience, they are different most of the time, and I have caught bugs in upstream's tarballs by doing this. .hc I haven't seen anyone write importing upstream VCS into the Alioth repo is forbidden anywhere; if this is the intent, then perhaps it should be clearly spelled out somewhere. (Or perhaps it already is, and I just missed it? In which case, whoops) Hum... Then maybe we should talk again. On 10/13/2014 06:19 AM, Barry Warsaw wrote: Does upstream vcs add value? Of course! Lots of value. One of them is that you'd be downloading tiny deltas, instead of constantly downloading a tarball, doing git-import-orig, etc. Another one is doing cherry-picking of changes. Another one is being able to do a Debian package based on any commit from upstream, if you do need that. Finally, it makes it easier for you to send a patch upstream based on your debian-specific patch (just grab it from your debian/patches folder, apply to the master branch, then git review or git push to github/bitbucket/git-cafe/you-name-it...). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54400a96.7090...@at.or.at
Re: Keeping upstream commits separate from Debian packaging commits
Tristan Seligmann wrote: On 16 October 2014 18:01, Thomas Goirand z...@debian.org 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 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). 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. There are tags like v1.0, 1.0, release-1.0, the-real-1.0, etc. etc. .hc -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54400a98.3010...@at.or.at
How to solve #751375, file clash
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. Is there a way to resolve this in Debian? Perhaps add a Conflicts: python-configparser to python-pies2overrides or to move pies2overrides into it's own namespace (and patch frosted accordingly)? -- Per -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABYrXSQ=ddpkj9ry6ya6kdjgs8rjyqpz3i+vqd3e0vrptqp...@mail.gmail.com
Re: How to solve #751375, file clash
On 17 October 2014 08:49, Per Andersson avtob...@gmail.com 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 by python-configparser? If it is the same file, you could delete it from python-pies2overrides and depend on python-configparser. -- Brian May br...@microcomaustralia.com.au
Re: Keeping upstream commits separate from Debian packaging commits
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. There are tags like v1.0, 1.0, release-1.0, the-real-1.0, etc. etc. Note that if the name scheme is consistent within a repository, git-buildpackage can easily be configured in debian/gbp.conf. The default is “upstream-tag = upstream/%(version)s”, but that can be changed to “upstream-tag = v%(version)s”, etc. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016223049.ga8...@falafel.plessy.net
Re: How to solve #751375, file clash
On October 16, 2014 5:49:37 PM EDT, Per Andersson avtob...@gmail.com 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 installed by python-configparser. I have forwarded this bug upstream. Is there a way to resolve this in Debian? Perhaps add a Conflicts: python-configparser to python-pies2overrides or to move pies2overrides into it's own namespace (and patch frosted accordingly)? Conflicts would not be an appropriate solution. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a042ca4c-e50e-4930-a632-474898226...@kitterman.com
