Re: How to handle Debian patches

Stefano Zacchiroli wrote: > On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote: >> > You can imagine harvesting alioth.d.o and extracting all debian/control >> > stored in whatever $VCS you find there, but you can't be sure if this >> > is the currently used $VCS, if there are other

Re: How to handle Debian patches

On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote: > > You can imagine harvesting alioth.d.o and extracting all debian/control > > stored in whatever $VCS you find there, but you can't be sure if this is > > the currently used $VCS, if there are other versions of the package > > vers

Re: How to handle Debian patches

Stefano Zacchiroli wrote: > On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote: >> I think it's about time to file mass bugs on whatever packages are left >> that use version control and lack the fields. > ... > > You can imagine harvesting alioth.d.o and extracting all debian/control > s

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Wed, 21 May 2008, Raphael Hertzog wrote: Because if the new format is the default format built by dpkg-source, this will happen automatically when you rebuild your packages... Yes. But there is probably some statistics about packages that are not rebuild inbetween two releases. I admit th

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

Andreas Tille <[EMAIL PROTECTED]> writes: > On Wed, 21 May 2008, Raphael Hertzog wrote: > > I'm currently evaluating a smooth transition from all orig+diff to > > the 3.0 (quilt) format and as such I'm not really interested in a > > new option that only makes sense for the old format that I hope t

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Wed, 21 May 2008, Andreas Tille wrote: > Hmmm, do you regard it as realistic that all maintainers will change to > a new format in Lenny+1? I do not think of maintainers who are in principle > not happy about this format but those who maintain packages that might stay > untouched perfectly fine

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Wed, 21 May 2008, Raphael Hertzog wrote: Would you regard this as a useful bug report or not? No. Ups, it's just to late (#482166) I'm currently evaluating a smooth transition from all orig+diff to the 3.0 (quilt) format and as such I'm not really interested in a new option that only ma

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Wed, 21 May 2008, Andreas Tille wrote: > Subject: Please provide an option to list patches outside debian directory > > Please add a --verbose/-v option to 'dpkg-source -x' that performs > > lsdiff -z -x '*/debian/*' *.diff.gz > > to point potential maintainers / bug fixers to patches

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Wed, 21 May 2008, Lars Wirzenius wrote: ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti: Would you regard this as a useful bug report or not? I think that would be a rather excellently useful bug report. OK, so I will go on filing it this way. The only way to improve it would

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti: > Would you regard this as a useful bug report or not? I think that would be a rather excellently useful bug report. The only way to improve it would be to include an actual patch to implement it. -- To UNSUBSCRIBE, email to [EMAIL PRO

Re: How to handle Debian patches

Le mardi 20 mai 2008 à 23:03 -0500, Manoj Srivastava a écrit : > > A quilt format package with a single combined patch. Get the > > integration branch, get orig.tar.gz, build. dpkg-buildpackage will > > automatically create a debian_version.patch for you. It is easy. > > How is this better

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Tue, 20 May 2008, Lars Wirzenius wrote: I'm a fairly long-time Unix user. I find it much preferably when command line tools are quiet by default when things are going well. I completely agree. I just have the feeling that some points were raised in the discussion that things are not going

Re: How to handle Debian patches

Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > The remaining ones will indeed need manual intervention, but aren't > this kind of changes those which are supposed to be pushed upstream? > So some more burden on the developer on these rare (if you buy my > statement above) cases can even be benef

Re: How to handle Debian patches

On Tue, 20 May 2008 00:44:44 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> said: > On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: >> And then you go saying things like that: >> > It is trivial to generate a quilt format package from >> > git/arch/hg/svn and I'm sure there will

Re: How to handle Debian patches

On Tue, 20 May 2008 08:00:48 +0200, Goswin von Brederlow <[EMAIL PROTECTED]> said: > Manoj Srivastava <[EMAIL PROTECTED]> writes: >> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow >> <[EMAIL PROTECTED]> said: >> >> Hmm. You say things like this: >>> Because the git format is imho conc

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

In article <[EMAIL PROTECTED]> you wrote: > modified. A quick inspection shows that for most of them the only change > is the path to Perl in the first line. Yes, and I really wonder why they are using local perl and removing the -w flag. Both is against best practise. I was actually asuming while

Re: How to handle Debian patches

Goswin von Brederlow dijo [Tue, May 20, 2008 at 08:10:05AM +0200]: > >> If I understand things correctly (but I'm really not sure I do), 3.0 > >> (quilt) won't really help with that: it won't prevent maintainers to > >> directly modify files outside of debian/ , and generate a huge > >> debian/patc

Re: How to handle Debian patches

On Tue, May 20, 2008 at 06:07:14AM +, Goswin von Brederlow wrote: > How do you tell git-rerere to keep all conflict resolutions needed to > convert feature branches into a patch series but not others? I was merely answering a first set of questions, for the rest please read documentation git

Re: How to handle Debian patches

On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: > And then you go saying things like that: > > It is trivial to generate a quilt format package from git/arch/hg/svn > > and I'm sure there will be a RCS-build-package soon enough that does > > that. > This can not h

Re: How to handle Debian patches

On Sat, May 17, 2008 at 10:18:58PM +0100, Roger Leigh wrote: > The syntax for the fields also does not currently let you specify a > branch or tag, it's just the whole repo. Personally, I'd like it to > allow specification of the branch/tag used to produce the specific > release of the package in

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

ti, 2008-05-20 kello 00:01 +0200, Andreas Tille kirjoitti: > > The debian Diff is not hiding patches in the upstream code. It is the > > canonical place to publish them (at least for some (most?) of the debian > > packages following policy). > > Well, I'm DD for 10 years - I know this fact. But d

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

Le Mon, May 19, 2008 at 10:25:35PM +0200, Bernd Eckenfels a écrit : > In article <[EMAIL PROTECTED]> you wrote: > > give a hint about this. If patches are "hidden" anywhere in the upstream > > code some developers fail to realise this and my suggestion might help > > noticing this fact. > > The d

Re: How to handle Debian patches

Gunnar Wolf <[EMAIL PROTECTED]> writes: > Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]: >> If I understand things correctly (but I'm really not sure I do), 3.0 >> (quilt) won't really help with that: it won't prevent maintainers to >> directly modify files outside of debian/ , and g

Re: How to handle Debian patches

Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote: >> B) (This is an honest question). How many things can rerere remember? If >>I use rerere to record how to resolve current conflicts in feature >>branches, does the historical i

Re: How to handle Debian patches

Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow > <[EMAIL PROTECTED]> said: > > Hmm. You say things like this: >> Because the git format is imho conceptualy broken and the >> implementation is far from completely thought out. > >

Re: How to handle Debian patches

On Tue, 20 May 2008, Pierre Habouzit wrote: git-rerere keeps recorded conflicts resolution for 60 days by default, and it's configureable, and it needs to use git-gc (or git rerere gc) to cleanse it, so if you don't, it just won't disappear. I admit I realy don't care what your favourite VCS

Re: How to handle Debian patches

Mike Hommey <[EMAIL PROTECTED]> writes: > On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: > > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow > > <[EMAIL PROTECTED]> said: > > > It is trivial to generate a quilt format package from > > > git/arch/hg/svn and I'm sure th

Re: How to handle Debian patches

On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote: > B) (This is an honest question). How many things can rerere remember? If >I use rerere to record how to resolve current conflicts in feature >branches, does the historical information get lost? (like, I use >rerere to h

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Mon, 19 May 2008, Bernd Eckenfels wrote: The debian Diff is not hiding patches in the upstream code. It is the canonical place to publish them (at least for some (most?) of the debian packages following policy). Well, I'm DD for 10 years - I know this fact. But did you read about habits of

Re: How to handle Debian patches

Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]: > If I understand things correctly (but I'm really not sure I do), 3.0 > (quilt) won't really help with that: it won't prevent maintainers to > directly modify files outside of debian/ , and generate a huge > debian/patches/debian-changes

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

In article <[EMAIL PROTECTED]> you wrote: > give a hint about this. If patches are "hidden" anywhere in the upstream > code some developers fail to realise this and my suggestion might help > noticing this fact. The debian Diff is not hiding patches in the upstream code. It is the canonical place

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Mon, 19 May 2008, Manoj Srivastava wrote: In that case, I fail to see why you are only interested in this information if the maintainer did not use quilt. Seems like you should be concerned about changes made to upstream, period, regardless of whether the changes are recorded in quilt

Re: How to handle Debian patches

On Mon, 19 May 2008 17:29:13 +0200, Mike Hommey <[EMAIL PROTECTED]> said: > On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: >> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow >> <[EMAIL PROTECTED]> said: >> >> Hmm. You say things like this: >> > Because the git format

Re: How to handle Debian patches

On Mon, May 19, 2008 at 03:29:13PM +, Mike Hommey wrote: > On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: > > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow > > <[EMAIL PROTECTED]> said: > > > > Hmm. You say things like this: > > > Because the git format

Re: How to handle Debian patches

On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow > <[EMAIL PROTECTED]> said: > > Hmm. You say things like this: > > Because the git format is imho conceptualy broken and the > > implementation is far from complet

Re: How to handle Debian patches

On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow <[EMAIL PROTECTED]> said: Hmm. You say things like this: > Because the git format is imho conceptualy broken and the > implementation is far from completely thought out. And then you go saying things like that: > It is tr

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Mon, 19 May 2008 09:20:11 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]> said: >> If you care about the changes, just use the command. You can even >> have an alias if you prefer that. >> >> BTW: >> +++ openssl-0.9.8g/Makefile >> +++ openssl-0.9.8g/Configure >> +++ ... (50 lines deleted) >>

Re: How to handle Debian patches

"Miriam Ruiz" <[EMAIL PROTECTED]> writes: > 2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>: > >> Because the git format is imho conceptualy broken and the >> implementation is far from completely thought out. The strongest >> point against it is that the user has to learn git to use it. > > I'

Re: How to handle Debian patches

On Mon, May 19, 2008 at 10:55:00AM +0200, Miriam Ruiz wrote: > 2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>: > > > Because the git format is imho conceptualy broken and the > > implementation is far from completely thought out. The strongest > > point against it is that the user has to learn

Re: How to handle Debian patches

2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>: > Because the git format is imho conceptualy broken and the > implementation is far from completely thought out. The strongest > point against it is that the user has to learn git to use it. I'm curious about this. Why is it conceptualy broken a

Re: How to handle Debian patches

Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Mon, 19 May 2008, Goswin von Brederlow wrote: >> Josselin Mouette <[EMAIL PROTECTED]> writes: >> >> > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : >> >> As a Debian package maintainer however I'm convinced that we'd be better >>

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Mon, 19 May 2008, Bernd Eckenfels wrote: I dont see a reason why the normal unpack action should spam the user. If a user feels spammed there might be means to switch this off. A command line option that reduces the verbosity comes to mind even /dev/null might be a place to foreward this s

Re: How to handle Debian patches

On Mon, 19 May 2008, Goswin von Brederlow wrote: > Josselin Mouette <[EMAIL PROTECTED]> writes: > > > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : > >> As a Debian package maintainer however I'm convinced that we'd be better > >> served by having only native + 3.0 quilt. The VC

Re: How to handle Debian patches

Josselin Mouette <[EMAIL PROTECTED]> writes: > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : >> As a Debian package maintainer however I'm convinced that we'd be better >> served by having only native + 3.0 quilt. The VCS comes _before_ the >> source package and the source packa

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

In article <[EMAIL PROTECTED]> you wrote: >lsdiff -z -x '*/debian/*' *.diff.gz > or whatever - as long as I get a list of patched files brought up to my > intention immediately. I dont see a reason why the normal unpack action should spam the user. If you care about the changes, just use the

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Sun, 18 May 2008, Raphael Hertzog wrote: With the 3.0 quilt format, dpkg-source -x will list each patch that it applies (and since the debian directory is stored in a tarball and not in a .diff, it always means _real_ changes contrary to the v1 format where we always see the line "applying ..

Re: How to handle Debian patches

On Sun, May 18, 2008 at 04:54:28PM +0200, Lucas Nussbaum wrote: > On 18/05/08 at 16:48 +0200, Mike Hommey wrote: > > On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote: > > > On 18/05/08 at 11:27 +0200, Mike Hommey wrote: > > > > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog

Re: How to handle Debian patches

On 18/05/08 at 16:48 +0200, Mike Hommey wrote: > On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote: > > On 18/05/08 at 11:27 +0200, Mike Hommey wrote: > > > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: > > > > On Sat, 17 May 2008, Joey Hess wrote: > > > > > Raphael

Re: How to handle Debian patches

On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote: > On 18/05/08 at 11:27 +0200, Mike Hommey wrote: > > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: > > > On Sat, 17 May 2008, Joey Hess wrote: > > > > Raphael Hertzog wrote: > > > > > On Fri, 16 May 2008, Joey Hess w

Re: How to handle Debian patches

On 18/05/08 at 11:27 +0200, Mike Hommey wrote: > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: > > On Sat, 17 May 2008, Joey Hess wrote: > > > Raphael Hertzog wrote: > > > > On Fri, 16 May 2008, Joey Hess wrote: > > > > > Coming up with a complex set of requirements that everyone

Re: How to handle Debian patches

Le samedi 17 mai 2008 à 22:55 -0400, Joey Hess a écrit : > > Unless you serialize your changes, you cannot expect them to be > > understandable for NMUers. > > I have no idea what you're talking about WRT serialising changes. This is what I’m concerned about. You’re so blinded by the coolness of

Re: How to handle Debian patches

Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : > As a Debian package maintainer however I'm convinced that we'd be better > served by having only native + 3.0 quilt. The VCS comes _before_ the > source package and the source package is just an export from the VCS. > However I thi

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

Neil Williams <[EMAIL PROTECTED]> writes: > Incidentally, you can collapse the zgrep into lsdiff -z: > > $ lsdiff -z *.diff.gz | grep -v debian lsdiff -z -x '*/debian/*' *.diff.gz -- Russ Allbery ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EM

Re: How to handle Debian patches

On Sat, 17 May 2008, Lucas Nussbaum wrote: > On 16/05/08 at 17:54 +0200, Raphael Hertzog wrote: > > In the general case, I do believe that the new source package format "3.0 > > (quilt)" will help as all Debian specific changes will always end up in > > debian/patches/. > > If I understand things

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Sun, 18 May 2008, Andreas Tille wrote: > On Fri, 16 May 2008, Raphael Hertzog wrote: > >> I totally agree that we need to make our changes more visible. In the >> openssl case, the patch in question is inside the .diff.gz and you don't >> notice it in the unpacked source package. I tend to give

Re: How to handle Debian patches

On Sat, 17 May 2008, Joey Hess wrote: > Lucas Nussbaum wrote: > > At some point, we will need to find a way to decide which v3 format we > > are going to choose in adddition to the v3 (native) format (with a GR?). > > We can't afford to allow several different v3 formats to coexist. > > The entire

Re: How to handle Debian patches

On Sunday 18 May 2008, Mike Hommey wrote: --cut-- > > You don't have to check it in revision control, you just have to be able > > to generate them from revision control. > > > > For .diff.gz, we already have tools to handle such files properly > > (without duplicating their content), it's called q

Re: How to handle Debian patches

On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: > On Sat, 17 May 2008, Joey Hess wrote: > > Raphael Hertzog wrote: > > > On Fri, 16 May 2008, Joey Hess wrote: > > > > Coming up with a complex set of requirements that everyone has to follow > > > > up front in their workflow[1] is n

Re: How to handle Debian patches

On Sat, 17 May 2008, Joey Hess wrote: > Raphael Hertzog wrote: > > On Fri, 16 May 2008, Joey Hess wrote: > > > Coming up with a complex set of requirements that everyone has to follow > > > up front in their workflow[1] is not going to yeld the best results, and > > > I think that's my core reason

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Sun, 2008-05-18 at 09:51 +0200, Andreas Tille wrote: > On Fri, 16 May 2008, Raphael Hertzog wrote: > > > I totally agree that we need to make our changes more visible. In the > > openssl case, the patch in question is inside the .diff.gz and you don't > > notice it in the unpacked source packag

Should dpkg-source -x list patches (Re: How to handle Debian patches)

On Fri, 16 May 2008, Raphael Hertzog wrote: I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a

Re: Packages using VCS but with no 'Vcs-*' control field (was: How to handle Debian patches)

su, 2008-05-18 kello 11:42 +1000, Ben Finney kirjoitti: > Joey Hess <[EMAIL PROTECTED]> writes: > > > I think it's about time to file mass bugs on whatever packages are > > left that use version control and lack the fields. > > How would the putative filer of these bugs determine which packages >

Re: How to handle Debian patches

Ben Finney wrote: > Saying that the plural 3.0 source formats allow Debian tools to > consume multiple package source formats is equivalent to saying that > upstream developers have no standard source format to rely on from > Debian. Upstream largely don't touch distribution source packages. Where

Re: How to handle Debian patches

Josselin Mouette wrote: > Le samedi 17 mai 2008 à 19:35 -0400, Joey Hess a écrit : > > No, the equivilant of those targets is the Source field in > > debian/control, and dpkg-source's plugin interface. > > To sum up, you don’t want to standardize on an interface that would > force you to serialize

Packages using VCS but with no 'Vcs-*' control field (was: How to handle Debian patches)

Joey Hess <[EMAIL PROTECTED]> writes: > I think it's about time to file mass bugs on whatever packages are > left that use version control and lack the fields. How would the putative filer of these bugs determine which packages are in this set? -- \ "...one of the main causes of the fall

Re: How to handle Debian patches

Mike Hommey <[EMAIL PROTECTED]> writes: > If we're to say that we need a format such that external entities can > easily parse it, that will need to be a standardized format, and an > unique one. And despite what you'd like, I don't think this is git. +1. Saying that the plural 3.0 source format

Re: How to handle Debian patches

Le samedi 17 mai 2008 à 19:35 -0400, Joey Hess a écrit : > No, the equivilant of those targets is the Source field in > debian/control, and dpkg-source's plugin interface. To sum up, you don’t want to standardize on an interface that would force you to serialize your changes. And unless you do thi

Re: How to handle Debian patches

Josselin Mouette wrote: > Le samedi 17 mai 2008 à 19:14 -0400, Joey Hess a écrit : > > The entire point of having support for multiple source formats in > > dpkg-source, and allowing it to extract any of those formats, and build > > a source package using any of those formats, is to allow multiple

Re: How to handle Debian patches

On Sat, May 17, 2008 at 07:14:31PM -0400, Joey Hess wrote: > Lucas Nussbaum wrote: > > At some point, we will need to find a way to decide which v3 format we > > are going to choose in adddition to the v3 (native) format (with a GR?). > > We can't afford to allow several different v3 formats to coe

Re: How to handle Debian patches

Le samedi 17 mai 2008 à 19:14 -0400, Joey Hess a écrit : > The entire point of having support for multiple source formats in > dpkg-source, and allowing it to extract any of those formats, and build > a source package using any of those formats, is to allow multiple > formats to be used. Indeed, b

Re: How to handle Debian patches

Lucas Nussbaum wrote: > At some point, we will need to find a way to decide which v3 format we > are going to choose in adddition to the v3 (native) format (with a GR?). > We can't afford to allow several different v3 formats to coexist. The entire point of having support for multiple source forma

Re: How to handle Debian patches

On 17/05/08 at 23:00 +0200, Pierre Habouzit wrote: > On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote: > > On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote: > > > All in all, pointing to VCSes is just making things harder, because > > > you fight against direct product o

Re: How to handle Debian patches

On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote: > I think it's about time to file mass bugs on whatever packages are left that > use version control and lack the fields. Unfortunately this is not easy to do, as least not as "mass bug filing". Point is that it is not easy to spot which

Re: How to handle Debian patches

Theodore Tso <[EMAIL PROTECTED]> writes: > On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote: >> In fact, despite being one of the big quilt advocates in the last round >> of this discussion, I am at this point pretty much sold on using Git >> due to its merges and branch support and ha

Re: How to handle Debian patches

Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote: >> On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> >> said: >> >> >> > (publishing my branch in a gitweb) isn't normalized, and won't >> > probably ever be, o

Re: How to handle Debian patches

On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote: > On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote: > > All in all, pointing to VCSes is just making things harder, because > > you fight against direct product of VCSes, workflows, and almost > > packages. And no tool is

Re: How to handle Debian patches

On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote: > On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote: > > On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> > > said: > > > > > > > (publishing my branch in a gitweb) isn't normalized, and won't

Re: How to handle Debian patches

On Sat, May 17, 2008 at 07:05:20PM +, Joey Hess wrote: > And conversely, as upstream I'm git-aming patches emailed to me every > day from people from all over, including other distributions, and that > works quite well. The quality of the patches is often high since they are > worked up to the

Re: How to handle Debian patches

On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote: > On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> said: > > > > (publishing my branch in a gitweb) isn't normalized, and won't > > probably ever be, or not under this form. > > Don't you think that

Re: How to handle Debian patches

Josselin Mouette wrote: > Are you deliberately omitting the sane formats to distribute patched > debian sources that are implemented? I'm talking about the formats that I expect to be using. The implication thst I'm somehow insane is not very useful. -- see shy jo signature.asc Description: Di

Re: How to handle Debian patches

On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote: > George Danchev wrote: > > Then comes even more, even Ben Laurie (as he writes in > > his blog) with all his aggression missed to find the debian's pkg-openssl > > VCS > > repo [1] unless he has been helped by someone at some point. I'm

Re: How to handle Debian patches

Le samedi 17 mai 2008 à 15:12 -0400, Joey Hess a écrit : > > Aren't "patch files in debian/patches/ with some headers" a defined > > interface? > > It's an interface, that if you stop there in defining it, means that I > have to check debian/patches/ into revision control, and bloat my > .diff.gz

Re: How to handle Debian patches

Le samedi 17 mai 2008 à 11:51 -0500, Manoj Srivastava a écrit : > > Diffing the tips of branches in a SCM will not show you which lines > > were changed by which changeset. If you want that information - which > > is one of the most useful ones, because the same file can be changed > > for many dif

Re: How to handle Debian patches

Raphael Hertzog wrote: > On Fri, 16 May 2008, Joey Hess wrote: > > Coming up with a complex set of requirements that everyone has to follow > > up front in their workflow[1] is not going to yeld the best results, and > > I think that's my core reason for disliking Raphael's proposal. Now, if > > yo

Re: How to handle Debian patches

Theodore Tso wrote: > How often is a logical change more than just a single commit? I think the most common case for me is when I need to bring the change forward to new upstream versions (with conflicts). In that case, I'll end up with multiple commits in the VCS hostory for the change. > So nor

Re: How to handle Debian patches

Raphael Hertzog wrote: > A VCS surely allows browsing and examining patches. But when I dig in a > VCS history, it's because I have something precise to look up, I will > rarely check it ouf of curiosity. debian/patches/ on the contrary is > something that gets my attention when I unpack a source p

Re: How to handle Debian patches

On Saturday 17 May 2008, Joey Hess wrote: > George Danchev wrote: > > Then comes even more, even Ben Laurie (as he writes in > > his blog) with all his aggression missed to find the debian's pkg-openssl > > VCS repo [1] unless he has been helped by someone at some point. I'm not > > against the VCS

Re: How to handle Debian patches

On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote: > In fact, despite being one of the big quilt advocates in the last round of > this discussion, I am at this point pretty much sold on using Git due to > its merges and branch support and have started to switch my packages over. > Howeve

Re: How to handle Debian patches

George Danchev wrote: > Then comes even more, even Ben Laurie (as he writes in > his blog) with all his aggression missed to find the debian's pkg-openssl VCS > repo [1] unless he has been helped by someone at some point. I'm not against > the VCS repo (I myself use some for my packaging), I jus

Re: How to handle Debian patches

On Sat, 17 May 2008 09:07:08 +0200, Mike Hommey <[EMAIL PROTECTED]> said: >> I find a quilt series to not fit the bill very well. On the other >> hand, creating ./debian/topics/foo/ with a git-format-patch series >> for each branch in there might be doable -- but then, these >> individual patches

Re: How to handle Debian patches

On Sat, May 17, 2008 at 11:51:22AM -0500, Manoj Srivastava wrote: > On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette <[EMAIL PROTECTED]> > said: > > > Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit : > >> diffing the tips of branches in a SCM has been far more friendly. So

Re: How to handle Debian patches

On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> said: > (publishing my branch in a gitweb) isn't normalized, and won't > probably ever be, or not under this form. Don't you think that Vcs-Browse and Vcs-$SCN headers are normalized ways for telling end users wher

Re: How to handle Debian patches

On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette <[EMAIL PROTECTED]> said: > Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit : >> diffing the tips of branches in a SCM has been far more friendly. So >> I find my old and new SCM's preferable to a quilt series -- since any >> f

Re: How to handle Debian patches

On Saturday 17 May 2008, Vincent Untz wrote: > Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit : > > On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote: > > > [I'm not subscribed to debian-devel, so feel free to cc me if you want > > > to keep me in the loop] > > > > done. >

Re: How to handle Debian patches

Guillem Jover <[EMAIL PROTECTED]> writes: > On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote: >> That would work, although it does... well, not double, but at least >> increase the work for any branch that also has a submission branch, >> since any upstream merge conflicts have to be resol

Re: How to handle Debian patches

Le Sat, May 17, 2008 at 11:36:00AM +0200, Cyril Brulebois a écrit : > On 17/05/2008, Charles Plessy wrote: > > Other idea: when the package is produced through a workflow that uses > > debian/patches, shipping them in /usr/share/doc/package/patches. > > Do you really want that? > openoffice.org_2.

Re: How to handle Debian patches

Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit : > On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote: > > [I'm not subscribed to debian-devel, so feel free to cc me if you want > > to keep me in the loop] > done. > > > + it also seems that some debian developers would pr

Re: How to handle Debian patches

On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote: > [I'm not subscribed to debian-devel, so feel free to cc me if you want > to keep me in the loop] done. > + it also seems that some debian developers would prefer the VCS way >instead of patches.debian.org. Well, if all the debian

Re: How to handle Debian patches

On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote: > > To me this one proof more than even when VCS are used to maintain > > packages, our source packages must clearly identify the Debian patches > > that are applied. > > You're insinuatiog that a VCS does not allow easily browsing and > e

Re: How to handle Debian patches

On Fri, May 16, 2008 at 08:07:38PM +0200, Goswin von Brederlow wrote: > >> Someone recently posted an example of this. IMO we should write a DEP > >> on patch management and standardize those headers. And probably enforce > >> their usage for patches on sensitive packages (lintian checks?). > It wo

  1   2   >