Re: Invalid check in debian/patches

Guillem Jover writes: > Hi! > > On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote: >> On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote: >> > But also, in this particular case, it's not the issue of the spec but of a >> > particular tool trying to enforce the rule. >> > >> > I

Re: Invalid check in debian/patches

Hi! On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote: > On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote: > > But also, in this particular case, it's not the issue of the spec but of a > > particular tool trying to enforce the rule. > > > > I'll file a bug to fix it. > I fin

Re: Invalid check in debian/patches

Hi, On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote: > But also, in this particular case, it's not the issue of the spec but of a > particular tool trying to enforce the rule. > > I'll file a bug to fix it. I finally found many reports already dealing with this issue in the bug tracker.

Re: Invalid check in debian/patches

Hi Jonas, On Sat, 2025-02-01 at 17:05 +0100, Jonas Smedegaard wrote: > Quoting Abou Al Montacir (2025-02-01 16:13:44) > > > > > > > On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote: > > > Quoting Simon McVittie (2025-02-01 14:21:38) > > > > On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al

Re: Invalid check in debian/patches

Quoting Abou Al Montacir (2025-02-01 16:13:44) > > > > On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote: > > Quoting Simon McVittie (2025-02-01 14:21:38) > > > On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote: > > > > Bug- > > > > Upstream:  > > > > https://gitlab.com/freepa

Re: Invalid check in debian/patches

On Sat, Feb 1, 2025 at 10:14 AM Abou Al Montacir wrote: > With regards to other possible values (No, NotNeeded), I find it a bit hacky > to use this field to provide an upstream bug URL. > I would completely remove this practice and keep this field human readable > and understandable to be a sim

Re: Invalid check in debian/patches

> On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote: > Quoting Simon McVittie (2025-02-01 14:21:38) > > On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote: > > > Bug- > > > Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 > > > > I believe the intende

Re: Invalid check in debian/patches

On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote: > Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 I believe the intended DEP-3 syntax for this is: Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 so using that instead of Bug-Upst

Re: Invalid check in debian/patches

Quoting Simon McVittie (2025-02-01 14:21:38) > On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote: > > Bug-Upstream: > > https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378 > > I believe the intended DEP-3 syntax for this is: > > Bug: https://gitlab.com/freepascal.org/laz

Re: Invalid check in debian/patches

Hi Abou, Quoting Abou Al Montacir (2025-02-01 13:13:32) > According > to https://udd.debian.org/patches.cgi?src=lazarus&version=3.8%2Bdfsg1-4 my > package have a patch with invalid metadata. There seem to be that the tool > considers the following as an error: > Forwarded: Yes > Bug-Upstream: http

Invalid check in debian/patches

Hi All, According to https://udd.debian.org/patches.cgi?src=lazarus&version=3.8%2Bdfsg1-4 my package have a patch with invalid metadata. There seem to be that the tool considers the following as an error: Forwarded: Yes Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378

Re: Have you merged debian/patches/* ?

Hi Ian, On Tue, Feb 20, 2018 at 09:23:00PM +, Ian Jackson wrote: > I would like some test cases for experimenting with various algorithms I think python-pandas 0.20.3 -> 0.22.0 would qualify as complex test case. Hope this helps Andreas. -- http://fam-tille.de

Have you merged debian/patches/* ?

If you have done a nontrivial merge of debian/patches/*, I'd like to hear from you. This is because I have a theory about how this can be done in a way that does not involve editing, or worse, resolving conficts in, diffs. I would like some test cases for experimenting with various algorith

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)

en automatically when you rebuild your packages... of course, it means that all the .diff.gz (except the debian dir) will end up in a single debian/patches/debian-changes-.diff if you don't take care to put the changes in separate patches. But the new source package will still be 3.0 (quilt)

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

pushed upstream? > So some more burden on the developer on these rare (if you buy my > statement above) cases can even be beneficial from a social point of > view. While in theory evey divergence is something to be pushed upstream, and anything ihn ./debian/patches should disappea

Re: How to handle Debian patches

> automatically create a debian_version.patch for you. It is easy. How is this better than the current diff.gz thing? > I'm not saying you get a nice and shiny debian/patches/* out of > it. That indeed needs human interaction as already said elsewhere. > To the non git (e

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

debian/ , and generate a huge > >> debian/patches/debian-changes-version.diff. > > Yes it will. Any modified file will end up in debian/patches/ instead > of modifying the file directly. It will not prevent patches but it > ensures they are used exclusively. So no packages that

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

ctly modify files outside of debian/ , and generate a huge >> debian/patches/debian-changes-version.diff. Yes it will. Any modified file will end up in debian/patches/ instead of modifying the file directly. It will not prevent patches but it ensures they are used exclusively. So no package

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

ored from that point on). 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. I'm not saying you get a nice and shiny debian/patches/* out of it. That i

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

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)

are that there > might be reasons to inspect the diff carefully and that it is not > enough to look into debian/patches (which might not exist in this > case, did not checked). In that case, I fail to see why you are only interested in this information if the maintainer did

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)

user to see. The information that the source has *a lot* (53) files that are patched by the Debian maintainer is no spam at all but might make the user aware that there might be reasons to inspect the diff carefully and that it is not enough to look into debian/patches (which might not exist in

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

ore reason for disliking Raphael's proposal. > > > > > > > > Now, if > > > > > > > > you can come up with protocols/interfaces that can be used to > > > > > > > > publish/communicate patches, that are managed/generated in

Re: How to handle Debian patches

> > you can come up with protocols/interfaces that can be used to > > > > > > > publish/communicate patches, that are managed/generated in > > > > > > > whatever way > > > > > > > is most useful for the maintainer, that seems more lik

Re: How to handle Debian patches

cate patches, that are managed/generated in whatever > > > > > > way > > > > > > is most useful for the maintainer, that seems more likely to work. > > > > > > > > > > Aren't "patch files in debian/patches/ with some

Re: How to handle Debian patches

Raphael's proposal. Now, > > > > > if > > > > > you can come up with protocols/interfaces that can be used to > > > > > publish/communicate patches, that are managed/generated in whatever > > > > > way > > > > > is most useful for th

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/patche

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

ource package. I tend to give a look to what's >> in debian/patches/ when I rebuild a package but not to what's in .diff.gz >> only. > > If I inspect an unknown package I always do > > zgrep "^+++ " *.diff.gz | grep -v "/debian/" > >

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

hes to > > patches.debian.org. If that process is not the same across all > > .git.tar.gz, we can mandate a new debian/rules target that must generate > > a debian/patches directory with all the patches. > > Note how infrastructure needs would decrease considerably if packa

Re: How to handle Debian patches

icate patches, that are managed/generated in whatever way > > > > is most useful for the maintainer, that seems more likely to work. > > > > > > Aren't "patch files in debian/patches/ with some headers" a defined > > > interface? > &g

Re: How to handle Debian patches

r, that seems more likely to work. > > > > 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

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

ice it in the unpacked source package. I tend to give a look to what's > > in debian/patches/ when I rebuild a package but not to what's in .diff.gz > > only. > > If I inspect an unknown package I always do > > zgrep "^+++ " *.diff.gz | grep -v &quo

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

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/pat

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

aphael's proposal. Now, if > > you can come up with protocols/interfaces that can be used to > > publish/communicate patches, that are managed/generated in whatever way > > is most useful for the maintainer, that seems more likely to work. > > Aren't "patch files in

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

Re: How to handle Debian patches

nst the latest upstream source they have (please I don't need examples how various VCS'es rock comparing btw repos;-). Then again, we end up having all these logically separate changes (if any/many of them) in a combined fashion. If there were clearly separeted diffs in debian/patches/ i

  1   2   >