On 20 October 2014 19:55, Barry Warsaw wrote:
> It occurs to me too that the switch from svn to git (e.g. git-dpm) is already
> a large change to current team workflow, and dropping pristine-tar might just
> be too big a move to also do right now.
We're not using pristine-tar with svn, right now;
On 10/21/2014 01:55 AM, Barry Warsaw wrote:
> It occurs to me too that the switch from svn to git (e.g. git-dpm) is already
> a large change to current team workflow, and dropping pristine-tar might just
> be too big a move to also do right now.
And things should move/improve incrementally as well
On Oct 21, 2014, at 12:48 AM, Thomas Goirand wrote:
>While I think it's important to do team work, and agree on some workflow
>conventions, I still want to explain my point of view, in the hope to
>make things better. I just hope I don't bother everyone too much with
>it... (I know I do...). Pleas
On 10/13/2014 06:11 AM, Barry Warsaw wrote:
>> While I don't agree with this decision, I prefer to just import upstream VCS
>> and do packaging based on tags, but I will still respect it when packaging in
>> the DPMT.
>
> Thank you. I personally appreciate the accommodations to the majority team
On 10/12/2014 09:30 PM, Scott Kitterman wrote:
>> Also, during the Debconf discussion, we decided we would use the
>> pristine-tar workflow, *not* using upstream VCS merge. A
>> "git-import-orig" normally goes into a single commit, which I don't
>> think would bother anyone (not on the list, or on
On 10/17/2014 01:01 AM, Tristan Seligmann wrote:
> 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 ups
On 17 October 2014 16:57, Tristan Seligmann wrote:
> On 17 October 2014 17:19, Dimitri John Ledkov wrote:
>> There are different tag types in git. "Soft" are just named commit
>> references and indeed can be renamed at will / point to new commits,
>> however signed tags encode:
>> object SHA1id
>
On 17 October 2014 17:19, Dimitri John Ledkov wrote:
> There are different tag types in git. "Soft" are just named commit
> references and indeed can be renamed at will / point to new commits,
> however signed tags encode:
> object SHA1id
> type type-of-above
> tag tag-name
> tagger normal user na
On 17 October 2014 07:39, Tristan Seligmann wrote:
> 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-ta
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).
>
>
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
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
>>
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
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
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
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
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
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
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
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?
On Oct 14, 2014, at 07:57 AM, Charles Plessy wrote:
>Ah sorry, it was a message from Henrique de Moraes Holschuh.
>
>https://lists.debian.org/debian-devel/2014/08/msg00694.html
Thanks, Henrique's posting does make sense. :/
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.de
Le Mon, Oct 13, 2014 at 10:40:00AM -0400, Barry Warsaw a écrit :
>
> I search d-d on gmane and wasn't able to find Joey's specific message about
> pristine-tar bitrot. pristine-tar does have a few bugs that could be
> relevant. I'm not sure where that leaves us though.
Ah sorry, it was a messag
Hi Charles, thanks for the information.
On Oct 13, 2014, at 08:41 AM, Charles Plessy wrote:
>in the Debian Med team, we had concrete evidence last May that the
>pristine-tar data bitrots with time in the way explained by Joey on
>debian-devel.
>
>Sorry to not have a high-quality summary to propos
Le Sun, Oct 12, 2014 at 06:14:19PM -0400, Barry Warsaw a écrit :
> On Oct 12, 2014, at 01:27 PM, Tristan Seligmann wrote:
>
> >That's interesting, I didn't know about that. I'm not really sure I
> >understand how dgit replaces pristine-tar, unless you assume that
> >every tarball you want to store
On Oct 12, 2014, at 11:15 AM, 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
Maybe not mutually exclusive, but what's the
On Oct 12, 2014, at 01:27 PM, Tristan Seligmann wrote:
>That's interesting, I didn't know about that. I'm not really sure I
>understand how dgit replaces pristine-tar, unless you assume that
>every tarball you want to store is in the archive. (Perhaps that's a
>reasonable assumption?) And since we
On Oct 12, 2014, at 02:49 PM, Thomas Goirand wrote:
>Also, during the Debconf discussion, we decided we would use the
>pristine-tar workflow, *not* using upstream VCS merge.
More specifically, as I remember the discussion, it was decided that if
upstream uses tarball based releases (as most PyPI
On October 12, 2014 2:49:47 AM EDT, Thomas Goirand wrote:
>On 10/10/2014 12:59 PM, Ben Finney wrote:
>> Scott Kitterman writes:
>>
>>> Changing the number of commits is solving the wrong problem. The
>>> problem that needs to be solved is including upstream commits.
>That's
>>> thoroughly uninte
On 12 October 2014 12:36, W. Martin Borgert wrote:
> Isn't pristine-tar deprecated by its author? I read
> https://bugs.debian.org/737871 and
That's interesting, I didn't know about that. I'm not really sure I
understand how dgit replaces pristine-tar, unless you assume that
every tarball you wan
On 2014-10-12 14:49, Thomas Goirand wrote:
> Let's say there's a few more other people which
> were not accounted for and that were not at Debconf, those who prefers
> having upstream source code in the VCS are still the majority.
And some weren't at Debconf and prefer to work with upstream
source
On 12 October 2014 08:49, Thomas Goirand wrote:
> Also, during the Debconf discussion, we decided we would use the
> pristine-tar workflow, *not* using upstream VCS merge. A
> "git-import-orig" normally goes into a single commit, which I don't
> think would bother anyone (not on the list, or on IR
On 10/10/2014 12:59 PM, Ben Finney wrote:
> Scott Kitterman writes:
>
>> Changing the number of commits is solving the wrong problem. The
>> problem that needs to be solved is including upstream commits. That's
>> thoroughly uninteresting for a packaging team.
>
> Agreed. This is a direct result
On 2014-10-10 13:13, Matthias Urlichs wrote:
> Looking at that code, IMHO it should be sufficient to add the arguments
> '--' and 'debian' to all calls of "git revlist".
Who can add this?
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble
Hi,
On Fri, 10 Oct 2014, Charles Plessy wrote:
> Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit :
> >
> > Where is the repository of the scripts involved? Maybe I have
> > some spare time this weekend... I hope, it's all sh or Python.
> > I forgot all my Perl.
>
> Hi Martin,
On Friday, October 10, 2014 09:04:32 Barry Warsaw wrote:
> On Oct 10, 2014, at 12:16 AM, Tianon Gravi wrote:
> >At the BoF during DebConf, me and paultag discussed how we use exactly
> >this workflow for Docker stuff in Git, and we love it. We don't ever
> >worry about any kind of upstream commits
On Oct 10, 2014, at 12:16 AM, Tianon Gravi wrote:
>At the BoF during DebConf, me and paultag discussed how we use exactly
>this workflow for Docker stuff in Git, and we love it. We don't ever
>worry about any kind of upstream commits in the packaging, and only
>deal with upstream tarballs/source
Hi,
Charles Plessy:
> https://github.com/mhagger/git-multimail/
>
Looking at that code, IMHO it should be sufficient to add the arguments
'--' and 'debian' to all calls of "git revlist".
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subj
Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit :
>
> Where is the repository of the scripts involved? Maybe I have
> some spare time this weekend... I hope, it's all sh or Python.
> I forgot all my Perl.
Hi Martin,
good news, it is in Python :)
https://github.com/mhagge
On 2014-10-10 10:13, Raphael Hertzog wrote:
> On Fri, 10 Oct 2014, W. Martin Borgert wrote:
> > I assume, that the script uses post-receive, so it has access to
> > all commits, including all affected paths. If so, generating only
> > emails or IRC messages when debian/ is involved should be easy.
On Fri, 10 Oct 2014, W. Martin Borgert wrote:
> On 2014-10-10 15:59, Ben Finney wrote:
> > Agreed. This is a direct result of rebasing Debian packaging history
> > onto upstream VCS history, and keeping them all in the same repo as one
> > undifferentiated history, no?
>
> Not sure, but isn't this
On 2014-10-10 15:59, Ben Finney wrote:
> Agreed. This is a direct result of rebasing Debian packaging history
> onto upstream VCS history, and keeping them all in the same repo as one
> undifferentiated history, no?
Not sure, but isn't this more a result of the scripts in use, to
not differentiate
On 9 October 2014 22:59, Ben Finney wrote:
> It's a good illustration of why I much prefer the workflow of a separate
> VCS for the ‘debian/’ directory, merged with upstream source only at
> build time. The results of the merge are in a separate location and are
> never checked into VCS, they're u
Scott Kitterman writes:
> Changing the number of commits is solving the wrong problem. The
> problem that needs to be solved is including upstream commits. That's
> thoroughly uninteresting for a packaging team.
Agreed. This is a direct result of rebasing Debian packaging history
onto upstream V
43 matches
Mail list logo
