Re: Keeping upstream commits separate from Debian packaging commits
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; if you build a package from svn, you need to fetch the upstream tarball from the archive or via uscan anyway (probably by letting svn-buildpackage do it for you). So it seems to me this is more a case of "adding pristine-tar", not "dropping pristine-tar", unless you're referring to the handful of packages already in git instead of svn. (Not disagreeing with your point here, just clarifying the issue) -- 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/CAMcKhMQ7Y===WwvcrK96p3mvrMvVeSWA5rEqv=u03wzvasl...@mail.gmail.com
Re: Keeping upstream commits separate from Debian packaging commits
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, so that everyone has enough time to get used to it. Thomas -- 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/5445e1ac.50...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
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...). Please keep in mind that this really is because >I want the best and most efficient workflow, and the purpose is *not* to >be annoying! :) Absolutely! I enjoy learning about other workflows, especially ones that others have good success with. 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. 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/20141020135534.28405...@anarchist.wooz.org
Re: Keeping upstream commits separate from Debian packaging commits
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 > decision. 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...). Please keep in mind that this really is because I want the best and most efficient workflow, and the purpose is *not* to be annoying! :) 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/54453ce2.3020...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
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 IRC). 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. Anyone who doesn't respect what we are collectively agree on >> should IMO take the blame for what happened on IRC and on the commit >> list, and pointing fingers at whoever configured it is IMO wrong. > > It's my fault someone else configured their git repos so IRC and the > ML get flooded? That's not what I wrote. Of course, it's not your fault. Thomas -- 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/54453af3.60...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
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 upstream > source. I never understood why this is important, even though so many people told me they want to check for that. If the point is security, then I don't think we achieve anything by doing so. > 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). This is anyway completely broken (see why Joey Hess decided to stop maintaining pristine-tar ...). > 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. When using xz compression, then anyway, the resulting orig.tar.xz will often not be the same when doing the same operation twice. So it's a broken concept. And I really hope you're not arguing that because of this, we should continue to use a 2 decade old compression thing... On 10/17/2014 02:12 AM, Hans-Christoph Steiner wrote: > 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. The most common standard I've seen almost everywhere, is to use, for a version number, well ... just a version number. Eg, release version 1.0, then just tag 1.0. That's what you'll see almost everywhere. Yes, there's silly upstream who loves to prefix these with a single character (and surprisingly, they've decided it would be a "v"). But that's fine, just re-tag on top with: "git tag 1.0 v1.0" and then everything is fine. There's absolutely no need to re-tag "upstream/v1.0", that's a pristine-tar convention only, IMO. On 10/17/2014 11:19 PM, 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 name, email, timestamp > > tag-message > > All signed with gpg. Thus any change to that metadata of a signed tag > will invalidate signature, or be treated as conflicting tag and thus > require --force push. > > Unsigned tags should not be publically used for e.g. release > identification. Though, if upstream publishes a gpg signed tag "v1.0", and then you don't like it and retag "1.0" on top, then it just points to the same pgp signature object, and you can still validate the signature. That's a very nice feature which I use often! :) On 10/17/2014 11:57 PM, Tristan Seligmann wrote: > The value of this is questionable if the upstream tags are unsigned, > especially if the released source tarballs *are* signed I haven't yet found any instance of the above. Most of the time, I see signed git tags, but no signed tarballs. On 10/17/2014 11:57 PM, Tristan Seligmann wrote: > I felt it > was worth the extra contortions to handle the upstream tags / > orig.tar.gz this way (the upstream tag in the packaging repository can > still be verified, as shown above). I did end up writing a 36 line > README.source discussing this process however... so I'm not sure how > suitable it is for the average DPMT/PAPT-maintained package. > > [1] The git repository is at > https://anonscm.debian.org/git/pkg-bitcoin/armory.git -- browse link > is https://anonscm.debian.org/cgit/pkg-bitcoin/armory.git My feeling is that it's not necessary. Just use upstream tags as-is, and do not attempt to prefix them with "upstream/", which adds very little to no benefits. 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/5445392a.4090...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits
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 >> type type-of-above >> tag tag-name >> tagger normal user name, email, timestamp >> >> tag-message >> >> All signed with gpg. Thus any change to that metadata of a signed tag >> will invalidate signature, or be treated as conflicting tag and thus >> require --force push. > > I stand corrected, tag objects do indeed include a name. However, this > name does not have to be the same as the name of the ref to that tag! > For example, in a package I recently helped sponsor[1]: > LOLz!!! was my initial reaction. But honestly, this does sounds a bit broken =) I was not aware of this property. It does make sense that a signed tag object has unique sha1 and thus one can create multiple tags named "foo" with different sha1 IDs and thus store them in a single git object store without ref names and/or different ref names. However the implications of this are rather severe - what if I copy/rename v1.0.3 tag as a v1.0.5 tag in my mirror and thus trick people into an older version... I'm concerned by this, I'll checkout git mailing list and/or raise this issue there. For some time now I have switched to providing people with sha1id of a GPG signed commit, instead pushing signed tags and providing a signed tag name only. That was only for the sake of minimising amount of refs i publish/pollute. I guess this is for the best. Regards, Dimitri. > mithrandi@lorien ~/d/p/armory> git tag -l | grep 0.92.3 > debian/0.92.3-1 > upstream/v0.92.3 > mithrandi@lorien ~/d/p/armory> git tag -v upstream/v0.92.3 > object 268db0f3fa20c989057bd43343a43b2edbe89aeb > type commit > tag v0.92.3 > tagger Armory Technologies, Inc 1412648447 -0400 > > Tor privacy fixes and msg signing RNG fix > gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223 > gpg: Good signature from "Alan C. Reiner (Offline Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 > > You'll notice that I've prefixed the upstream refs with upstream/ in > order to organise them; it is possible to do this automatically with a > configuration like: > > git config remote.upstream.tagopt --no-tags > git config --add remote.upstream.fetch '+refs/tags/*:refs/tags/upstream/*' > > However, the name does not match the standard git-buildpackage naming > scheme exactly (prefixed with 'v'), so setting --git-upstream-tag is > necessary. You could avoid this at the cost of having to fetch each > tag manually, with something like: > > mithrandi@lorien ~/d/p/armory> git fetch upstream > +refs/tags/v0.92.3:refs/tags/upstream/this-is-nonsense > From github.com:etotheipi/BitcoinArmory > * [new tag] v0.92.3-> upstream/this-is-nonsense > mithrandi@lorien ~/d/p/armory> git tag -v upstream/this-is-nonsense > object 268db0f3fa20c989057bd43343a43b2edbe89aeb > type commit > tag v0.92.3 > tagger Armory Technologies, Inc 1412648447 -0400 > > Tor privacy fixes and msg signing RNG fix > gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223 > gpg: Good signature from "Alan C. Reiner (Offline Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 > > And thus name the ref whatever you like locally, regardless of what > upstream's name is. Since all of the commands that operate on a > revision take the ref name as an argument, not the actual name given > in the tag object, this is all that matters for things like > pristine-tar (which just records the commit id regardless of how you > identify the commit to use) and git-buildpackage. > > The value of this is questionable if the upstream tags are unsigned, > especially if the released source tarballs *are* signed (in which case > they can be verified by uscan...but only as long as they continue to > be published, since the upstream signature is not kept anywhere in > Debian). In the case of Armory, upstream does not publish source > tarballs at all, only binary releases; the primary source release > mechanism is through signed tags in their git repository, so I felt it > was worth the extra contortions to handle the upstream tags / > orig.tar.gz this way (
Re: Keeping upstream commits separate from Debian packaging commits
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 name, email, timestamp > > tag-message > > All signed with gpg. Thus any change to that metadata of a signed tag > will invalidate signature, or be treated as conflicting tag and thus > require --force push. I stand corrected, tag objects do indeed include a name. However, this name does not have to be the same as the name of the ref to that tag! For example, in a package I recently helped sponsor[1]: mithrandi@lorien ~/d/p/armory> git tag -l | grep 0.92.3 debian/0.92.3-1 upstream/v0.92.3 mithrandi@lorien ~/d/p/armory> git tag -v upstream/v0.92.3 object 268db0f3fa20c989057bd43343a43b2edbe89aeb type commit tag v0.92.3 tagger Armory Technologies, Inc 1412648447 -0400 Tor privacy fixes and msg signing RNG fix gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223 gpg: Good signature from "Alan C. Reiner (Offline Signing Key) " gpg: aka "Alan C. Reiner (Armory Signing Key) " gpg: aka "Alan C. Reiner (Armory Signing Key) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 You'll notice that I've prefixed the upstream refs with upstream/ in order to organise them; it is possible to do this automatically with a configuration like: git config remote.upstream.tagopt --no-tags git config --add remote.upstream.fetch '+refs/tags/*:refs/tags/upstream/*' However, the name does not match the standard git-buildpackage naming scheme exactly (prefixed with 'v'), so setting --git-upstream-tag is necessary. You could avoid this at the cost of having to fetch each tag manually, with something like: mithrandi@lorien ~/d/p/armory> git fetch upstream +refs/tags/v0.92.3:refs/tags/upstream/this-is-nonsense >From github.com:etotheipi/BitcoinArmory * [new tag] v0.92.3-> upstream/this-is-nonsense mithrandi@lorien ~/d/p/armory> git tag -v upstream/this-is-nonsense object 268db0f3fa20c989057bd43343a43b2edbe89aeb type commit tag v0.92.3 tagger Armory Technologies, Inc 1412648447 -0400 Tor privacy fixes and msg signing RNG fix gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223 gpg: Good signature from "Alan C. Reiner (Offline Signing Key) " gpg: aka "Alan C. Reiner (Armory Signing Key) " gpg: aka "Alan C. Reiner (Armory Signing Key) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 And thus name the ref whatever you like locally, regardless of what upstream's name is. Since all of the commands that operate on a revision take the ref name as an argument, not the actual name given in the tag object, this is all that matters for things like pristine-tar (which just records the commit id regardless of how you identify the commit to use) and git-buildpackage. The value of this is questionable if the upstream tags are unsigned, especially if the released source tarballs *are* signed (in which case they can be verified by uscan...but only as long as they continue to be published, since the upstream signature is not kept anywhere in Debian). In the case of Armory, upstream does not publish source tarballs at all, only binary releases; the primary source release mechanism is through signed tags in their git repository, so I felt it was worth the extra contortions to handle the upstream tags / orig.tar.gz this way (the upstream tag in the packaging repository can still be verified, as shown above). I did end up writing a 36 line README.source discussing this process however... so I'm not sure how suitable it is for the average DPMT/PAPT-maintained package. [1] The git repository is at https://anonscm.debian.org/git/pkg-bitcoin/armory.git -- browse link is https://anonscm.debian.org/cgit/pkg-bitcoin/armory.git -- 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/camckhmsn0trwfex97kylkqq5w-uyeeomcwtb0cwf_o9c7ez...@mail.gmail.com
Re: Keeping upstream commits separate from Debian packaging commits
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-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. > > Renaming the tag does not require retagging, git tag objects (perhaps > unfortunately) do not include their name. 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 name, email, timestamp tag-message All signed with gpg. Thus any change to that metadata of a signed tag will invalidate signature, or be treated as conflicting tag and thus require --force push. Unsigned tags should not be publically used for e.g. release identification. -- Regards, Dimitri. -- 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/CANBHLUgEnJ0P=s47lxsxu1hoefxo-_eishw+msvznpn9oh1...@mail.gmail.com
Re: Keeping upstream commits separate from Debian packaging commits
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). > > 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. Renaming the tag does not require retagging, git tag objects (perhaps unfortunately) do not include their name. -- 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/CAMcKhMTEMf8MgvaQB476mvG_=kz7mhalfbxv1bd9_zuouaj...@mail.gmail.com
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: Keeping upstream commits separate from Debian packaging commits
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 >> 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
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
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
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
Re: Keeping upstream commits separate from Debian packaging commits
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 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 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
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 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
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? 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: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013190602.28d2c...@limelight.wooz.org
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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 message from Henrique de Moraes Holschuh. https://lists.debian.org/debian-devel/2014/08/msg00694.html Cheers, -- Charles -- 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/20141013225728.ga27...@falafel.plessy.net
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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 propose, but you can have a look >at the following thread and do not hesitate to ask for more information on >our list if you would like. > >http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-May/026728.html >http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-June/027063.html I probably missed it, but from skimming these threads, it seemed like the problem was more with git-buildpackage than with pristine-tar. If so, I wonder if the same problems would affect git-dpm. 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. 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/20141013104000.2e1fc...@limelight.wooz.org
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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 is in the archive. (Perhaps that's a > >reasonable assumption?) And since we are not planning to use dgit in > >DPMT (as I understand it), I'm not sure what the obvious way for us to > >replace pristine-tar is. > > In practice, I haven't seen any problems with pristine-tar. And given that > archive uploads still currently require a tarball, and PyPI releases are > overwhelmingly tarball-based, I think it still makes sense for DPMT to > continue to use pristine-tar workflows by default. Hi Barry, 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 propose, but you can have a look at the following thread and do not hesitate to ask for more information on our list if you would like. http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-May/026728.html http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-June/027063.html 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/20141012234118.ga3...@falafel.plessy.net
Re: Keeping upstream commits separate from Debian packaging commits
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 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 can perhaps see it might help when importing patches, but it's almost always (IME) to find other ways to generate the patch. For example, you can always clone upstream into a different directory, or pull the patch from the code hosting site. 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. 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/20141012181934.1b6bb...@anarchist.wooz.org
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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 are not planning to use dgit in >DPMT (as I understand it), I'm not sure what the obvious way for us to >replace pristine-tar is. In practice, I haven't seen any problems with pristine-tar. And given that archive uploads still currently require a tarball, and PyPI releases are overwhelmingly tarball-based, I think it still makes sense for DPMT to continue to use pristine-tar workflows by default. 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/20141012181419.6f734...@anarchist.wooz.org
Re: Keeping upstream commits separate from Debian packaging commits
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 packages do), then DPMT git vcses would also use a pristine-tar workflow. When upstream does not release tarballs, I think we decided to encourage pristine-tar, but to leave it to individual package maintainers to do what makes the most sense. However, in these cases, a README.source is required to explain the untypical packaging workflow. It also makes sense in those cases to ensure that the communication channels aren't overloaded with upstream commits, which I think are almost always going to be uninteresting to team members. >A "git-import-orig" normally goes into a single commit, which I don't think >would bother anyone (not on the list, or on IRC). Agreed. >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 decision. One other comment about commit notifications; we'll probably want to suppress notifications for initial commits of converted packages. I learned that the hard way for the last package I converted. 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/20141012181137.34075...@anarchist.wooz.org
Re: Keeping upstream commits separate from Debian packaging commits
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 uninteresting for a packaging team. >> >> 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? > >The IRC bot and the commit-by-email function, while being nice, aren't >going to be the decision making features. What's going to be is what is >the most convenient for doing the packaging work. > >> 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 used only for the build. >> >> See ‘git-buildpackage(1)’ for the ‘--git-overlay’ option, which AFAIK >> does this. >> >> That way, the history of the Debian packaging VCS is entirely about >> what happened to Debian packaging; upstream VCS history is elsewhere. >> That seems to address the trouble entirely. > >There are perfectly valid points for using what you describe above. But >also, there's some other reasons why it's preferable to have upstream >source within the VCS packaging branches. > >During Debconf 14, we had this discussion. Only Paultag wanted this, >everyone else didn't. 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. > >Please, let's move on and not discuss it again... > >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 IRC). 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. Anyone who doesn't respect what we are collectively agree on >should IMO take the blame for what happened on IRC and on the commit >list, and pointing fingers at whoever configured it is IMO wrong. It's my fault someone else configured their git repos so IRC and the ML get flooded? Nonsense. I don't know who caused it to happen, but that's definitely where I'm (correctly) pointing fingers. 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/a7633e1a-c4d2-4ae0-a3ab-4d6b9b2c5...@kitterman.com
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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 want to store is in the archive. (Perhaps that's a reasonable assumption?) And since we are not planning to use dgit in DPMT (as I understand it), I'm not sure what the obvious way for us to replace pristine-tar is. > http://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/ This doesn't load for me at the moment (database error). Okay, found it in Google's cache; unfortunately the post doesn't say much beyond "I'm going to stop using pristine-tar". -- 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/camckhmsope0fbowpxjesp5nyg8rjhp9jbxmltmmqsafmomm...@mail.gmail.com
Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
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 sources. > Also, during the Debconf discussion, we decided we would use the > pristine-tar workflow, *not* using upstream VCS merge. Isn't pristine-tar deprecated by its author? I read https://bugs.debian.org/737871 and http://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/ and was therefore reluctant to use it. Anyway, I don't remember to encounter any problems with pristine-tar myself. > Anyone who doesn't respect what we are collectively agree on > should IMO take the blame for what happened on IRC and on the commit > list, and pointing fingers at whoever configured it is IMO wrong. Blaming and pointing fingers is almost always wrong :~) -- 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/20141012103613.GA2011@fama
Re: Keeping upstream commits separate from Debian packaging commits
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 IRC). 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; did I misread what you wrote? pristine-tar just needs a commit to base the tar delta off of; this can be a tag created via git-import-orig, but it can just as easily be a tag pulled from upstream. (Using upstream tags *without* using pristine-tar would seem to be inadvisable, with the possible exception of upstreams who don't release tarballs, and/or sign all their release tags) > the DPMT. Anyone who doesn't respect what we are collectively agree on > should IMO take the blame for what happened on IRC and on the commit > list, and pointing fingers at whoever configured it is IMO wrong. 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) -- 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/CAMcKhMQTGotYsddxC+ynb5oFn0QrP1ng+hkui9Lv6U=4yfs...@mail.gmail.com
Re: Keeping upstream commits separate from Debian packaging commits
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 of rebasing Debian packaging history > onto upstream VCS history, and keeping them all in the same repo as one > undifferentiated history, no? The IRC bot and the commit-by-email function, while being nice, aren't going to be the decision making features. What's going to be is what is the most convenient for doing the packaging work. > 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 used only for the build. > > See ‘git-buildpackage(1)’ for the ‘--git-overlay’ option, which AFAIK > does this. > > That way, the history of the Debian packaging VCS is entirely about > what happened to Debian packaging; upstream VCS history is elsewhere. > That seems to address the trouble entirely. There are perfectly valid points for using what you describe above. But also, there's some other reasons why it's preferable to have upstream source within the VCS packaging branches. During Debconf 14, we had this discussion. Only Paultag wanted this, everyone else didn't. 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. Please, let's move on and not discuss it again... 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 IRC). 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. Anyone who doesn't respect what we are collectively agree on should IMO take the blame for what happened on IRC and on the commit list, and pointing fingers at whoever configured it is IMO wrong. 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/543a248b.30...@debian.org
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011163551.GA20499@fama
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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, > > good news, it is in Python :) > > https://github.com/mhagger/git-multimail/ But the IRC notifier is "kgb-client" (packaged in Debian) and this is Perl. I just filed a wishlist bug about this: #764713 Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20141010131715.gh29...@x230-buxy.home.ouaza.com
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 in the packaging, and only > >deal with upstream tarballs/source at build time, which keeps things > >simple. > > > >Looking at the history of our repo is a direct look at the history of > >debian/, which makes sense because it's a repo for the packaging, and > >anything other than that really is a distraction. > > > >During the BoF, we were kind of alone in recommending this workflow, > >but it's certainly nice (for me anyhow) to see other people advocating > >it as well! :) > > I don't quite understand how you would get more than a single commit outside > of debian/ when you would do something like git-dpm import-new-upstream. > You're pulling in the tar.gz which of course has no vcs history. Yes. That's how I use git-dpm as well and matches my experience. 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/1850433.POYLGLxXaS@scott-latitude-e6320
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 at build time, which keeps things >simple. > >Looking at the history of our repo is a direct look at the history of >debian/, which makes sense because it's a repo for the packaging, and >anything other than that really is a distraction. > >During the BoF, we were kind of alone in recommending this workflow, >but it's certainly nice (for me anyhow) to see other people advocating >it as well! :) I don't quite understand how you would get more than a single commit outside of debian/ when you would do something like git-dpm import-new-upstream. You're pulling in the tar.gz which of course has no vcs history. 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/20141010090432.4896a...@anarchist.wooz.org
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010111332.ga3...@smurf.noris.de
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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/mhagger/git-multimail/ Cheers, -- 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/20141010095153.gd29...@falafel.plessy.net
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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. > > Yes, are you volunteering to implement it? I would, if the "commit storm" would annoy me. It does not :~) (I'm not subscribed to the commit mailing list and used IRC around 1991 last time.) OK, this is getting selfish! 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. -- 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/20141010091146.GA30038@fama
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 more a result of the scripts in use, to > not differentiate paths? > > 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. Yes, are you volunteering to implement it? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20141010081324.gb15...@x230-buxy.home.ouaza.com
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 paths? 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. -- 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/20141010062107.GA23092@fama
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 used only for the build. 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 at build time, which keeps things simple. Looking at the history of our repo is a direct look at the history of debian/, which makes sense because it's a repo for the packaging, and anything other than that really is a distraction. During the BoF, we were kind of alone in recommending this workflow, but it's certainly nice (for me anyhow) to see other people advocating it as well! :) TL;DR +1 for ditching upstream artifacts :> ♥, - Tianon -- 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/cahnknk0gbmk6jeeidfqrtqupgpmw-_iyzajhab-yj+njamh...@mail.gmail.com
Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
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 VCS history, and keeping them all in the same repo as one undifferentiated history, no? 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 used only for the build. See ‘git-buildpackage(1)’ for the ‘--git-overlay’ option, which AFAIK does this. That way, the history of the Debian packaging VCS is entirely about what happened to Debian packaging; upstream VCS history is elsewhere. That seems to address the trouble entirely. -- \ “Liberty, n. One of imagination's most precious possessions.” | `\ —Ambrose Bierce, _The Devil's Dictionary_, 1906 | _o__) | Ben Finney -- 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/8538awtt8v.fsf...@benfinney.id.au
