Re: How to handle Debian patches

[Raphael Geissert]

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 versions of the package
>> > versioned elsewhere, ... Plenty of room for false positives.  Even
>> Why debian/control? debian/changelog provides the source package name and
>> the latest version. Matching data with the latest Sources of unstable
>> should do the trick to know what is up to date in the $VCS, and what
>> isn't.
> 
> Uhm, interesting, you mean testing if the changelog version is greater
> or equal than the latest in unstable, right? This still leaves the room
> to the very same package version, greater than latest unstable, which
> has been moved from one VCS to the other before being uploaded, but I
> guess it is a pretty remote case.

I believe the number of false positives will be very very small, and if one
takes a look at what would be done there's a chance to spot them.

> 
> Cheers.
> 

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Stefano Zacchiroli]

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
> > versioned elsewhere, ... Plenty of room for false positives.  Even
> Why debian/control? debian/changelog provides the source package name and
> the latest version. Matching data with the latest Sources of unstable
> should do the trick to know what is up to date in the $VCS, and what isn't.

Uhm, interesting, you mean testing if the changelog version is greater
or equal than the latest in unstable, right? This still leaves the room
to the very same package version, greater than latest unstable, which
has been moved from one VCS to the other before being uploaded, but I
guess it is a pretty remote case.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Raphael Geissert]

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
> 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
> versioned elsewhere, ... Plenty of room for false positives.  Even

Why debian/control? debian/changelog provides the source package name and
the latest version. Matching data with the latest Sources of unstable
should do the trick to know what is up to date in the $VCS, and what isn't.

> 
> Still, it is a good idea to start diffusing the culture of manually
> filing bugs against version controlled packages lacking the field.
> 
> Cheers.
> 

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Tille]

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 that most probably those packages
are not really the candidates that might need extra care about security
patches.


Which is nice - and thus I would love to see this implemented now for
every format if it can be approached fairly easy.  But the maintainer


What means now? dpkg in lenny is frozen...


"Now" means what you can expect for a wishlist bug - just going to unstable
according to maintainers decision.  And unstable is the place were packages
you might like to change normaly reside - so it would perfectly fit.

But well, I suggest we just end this discussion here.  There are enough
threads running and after having filed the bug I turned my idea into the
shape I wanted it to be.  The dpkg-dev maintainers will decide ...

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Ben Finney]

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 to
> > deprecate in lenny+1.
> 
> Hmmm, do you regard it as realistic that all maintainers will change to
> a new format in Lenny+1?

"$FOO is deprecated in lenny+1" means that, in lenny+1, usage of $FOO
will be deprecated. It doesn't mean "no-one is permitted to use $FOO".

At some point *after* deprecation (i.e. "at some point after lenny+1",
in this example), $FOO becomes unsupported, but preferably only after
a significant proportion has responded to the deprecation by migrating
away from $FOO.

> but I have certain doubts that such kind of transitions are faster
> than for instance /usr/doc -> /usr/share/doc and something like
> that.

A perfect example. '/usr/doc' was deprecated for a long time, yet it
was not until most packages had migrated away from it that it became
mandatory to do so.

-- 
 \"If you continue running Windows, your system may become |
  `\unstable." —Microsoft, Windows 95 bluescreen error message |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Raphael Hertzog]

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 over years?  I would personally welcome your plan,
> but I have certain doubts that such kind of transitions are faster than
> for instance /usr/doc -> /usr/share/doc and something like that.

Because if the new format is the default format built by dpkg-source, this
will happen 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) and at unpack time
you'll be informed that "debian-changes-.diff" is applied.

> Which is nice - and thus I would love to see this implemented now for
> every format if it can be approached fairly easy.  But the maintainer

What means now? dpkg in lenny is frozen... 

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Tille]

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 makes sense for the old format that I hope to deprecate in
lenny+1.


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 over years?  I would personally welcome your plan,
but I have certain doubts that such kind of transitions are faster than
for instance /usr/doc -> /usr/share/doc and something like that.


And I already said that the 3.0 (quilt) format list patches that it
applies during dpkg-source -x.


Which is nice - and thus I would love to see this implemented now for
every format if it can be approached fairly easy.  But the maintainer
has the last word and I have no real problem if you tag the bug wontfix
or just close it.  I personally do this anyway on my systems - I just
thought that the idea would add some tiny bit to help in the problem
we detected.

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Raphael Hertzog]

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 that reside
>   outside of the debian directory.  It would be even better if a
>   config file option would be parsed that enables to switch on this
>   option by default.
>
> Would you regard this as a useful bug report or not?

No. 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 to deprecate in
lenny+1.

And I already said that the 3.0 (quilt) format list patches that it
applies during dpkg-source -x.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Tille]

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 be to include an actual patch to implement it.


... as always.  So I use the excuse (as always) that my time is currently
to limited to fiddle around with this things while trusting that the
implementation is easy enough for a person who knows the code much better
than me.  I had a look into dpkg-source before my proposal and it is
rather a matter of style how to resolve this bug and I would not try
to force my rude beginners style onto a perl professional.

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Lars Wirzenius]

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 PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Josselin Mouette]

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 than the current diff.gz thing?

It is not better, but the point is that it is not *worse*.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

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

[Andreas Tille]

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 that well, if patches of upstream
code are "kind of" hidden in the unpacked Debian source.  So this is rather
a definition what we understand as "going well".


Providing a
--verbose option rather than a --quiet option would be my preference.


If it is accompanied by a config file option for those people who might
forget to specify --verbose it is probably OK for this case.


Having a tool print out a lot of information that is peripheral to what
I'm doing is distracting, and if it happens often, I start mentally
ignoring the output until something breaks.


Important point!


Listing patches when I unpack source is one of those cases to me.


Summarizing the thread I would file a wishlist bug report saying
something like this:

  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 that reside
  outside of the debian directory.  It would be even better if a
  config file option would be parsed that enables to switch on this
  option by default.

Would you regard this as a useful bug report or not?

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Ben Finney]

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 beneficial from a social point of
> view.

In many of the cases discussed in this thread, the Debian package
maintainer is already bearing much of the burden of the divergence and
upstream (whatever their attitude to the developer) is not going to
incorporate the patch any time soon.

Why, in these cases, do you see extra burden on the Debian package
maintainer to be a good thing?

-- 
 \  "I hope some animal never bores a hole in my head and lays its |
  `\   eggs in my brain, because later you might think you're having a |
_o__)  good idea but it's just eggs hatching."  -- Jack Handey |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

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 be a RCS-build-package soon
>> > enough that does that.
>> This can not happen without manual intervention, if the topic
>> branches have overlap. And Redoing the manual conflict resolution
>> over

> I stopped buying this argument (generally, not specifically from you)
> on the basis that in most of the cases packages have several non
> overlapping patches wrt upstream.  So the "trivial" part above is
> indeed true for a lot of packages.

If you want to only cater to package who currently do not have
 overlapping branches, sure. I am not sure I'll feel motivated enough to
 go along with a partial solution, but perhaps you do not need everyone
 buy-in.

> 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 beneficial from a social point of
> view.

While in theory evey divergence is something to be pushed
 upstream, and anything ihn ./debian/patches should disappear, in
 practice, for multitudinous reasons, we still have divergence.  Any
 policy that relies on this not being the case is, umm, being somewhat
 unrealistic. 

manoj
-- 
"In every country and every age, the priest has been hostile to
Liberty." Thomas Jefferson
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

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 conceptualy broken and the
>>> implementation is far from completely thought out.
>> 
>> 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 happen without manual intervention, if the topic
>> branches have overlap. And Redoing the manual conflict resolution
>> over and over and over again is a burden (the manual conflict
>> resolution lives generally in the integration branch history, and can
>> be done once, and mostly ignored 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.

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 (even not quilt) experienced user the combined patch
> will be usable in that he can edit the source and fix bugs. The git
> format does not allow that.

Unpack a 3.0 (git) source package. Hack.
 "git commit -a -m"Why I hacked this."
 dpkg-buildpackage

Seems like does not allow is a bit strong.

As more and more people swithc to git, git awareness will
 spread, making more people who can actually deal with creating a git
 branch to make changes on.  Seems like a long term win.

> Even with some git knowledge I think that most users that write a
> patch won't follow the maintainers workflow. They won't find the right
> feature branch a patch belongs to and how to merge that into an
> integration branch. Instead they will just edit the source, git commit
> and send the resulting patch. And that means you get a patch against
> the integration branch. Same as you would with the quilt format.

The users are not really following the maintainers workflow even
 in the git case (If I have to modify patch 7 of 9, I need some
 quilt-fu).

manoj

-- 
Do unto others before they undo you.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Bernd Eckenfels]

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 seeing the
list of files, it would be the other way around :)

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Gunnar Wolf]

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/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 change some
> files directly and use debian/patches/ for others.

Ok... I have not followed the development of the new package version

> > But with some time put to it, we can end up including a "the
> > maintainer shuold not modify files outside of the debian/ directory
> > without a strong rationale", and provide lintian checks for packages
> > still directly modifying upstream code...
> 
> Do you mean no debian/patches at all?

No, of course not - But I _do_ mean no patches with no rationale at
all. If I understand correctly, were I to repackage something I have
now that directly modifies the upstream code, my whole unorganized
patchwork probably become something like debian/patches/01. Of course,
a tool cannot understand _what_ it does, and how it should be split. I
suppose (and, again, I'm just guessing right now, please forgive me) a
good maintainer would split and name that in
debian/patches/01_fixes_blah, debian/patches/02_foo and so on, and in
each of the files' headers would note what bug or issue is this patch
addressing. And we can make tools understand said headers - and
complain if an unexplained patch was found.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Pierre Habouzit]

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-rerere(1) e.g. This part of the thread is
*really* becoming OT.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpacYazid1E6.pgp
Description: PGP signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

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 happen without manual intervention, if the topic
>  branches have overlap. And  Redoing the manual conflict resolution over

I stopped buying this argument (generally, not specifically from you) on
the basis that in most of the cases packages have several non
overlapping patches wrt upstream.  So the "trivial" part above is indeed
true for a lot of packages.

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 beneficial from a social point of view.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

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 Sources.gz (or better, the latest
> development on that branch).
> 
> For example:
> 
>   Vcs-Git: git://git.debian.org/git/buildd-tools/schroot
> 
> This gives you the master branch, but the Debian packages are actually
> on the schroot-1.2 stable release branch.  For people who want to hack
> on what's actually in use in Debian testing/unstable right now, this
> is the wrong branch.

This is coherent with the initial idea of the field: give a human being
(the Debian maintainer) a pointer to where the packages is being worked
on. Then you will need some additional information to know where to
look, as you would looking on the VCS tab of sourceforge or on the
author homepage.

If, as it seems to me, we are now starting to feel the need of having
more structure Vcs-* information so as to enable _automatic_ processing
of VCS information, well, let's sit down and standardize that. Though
note that this will need to be done on a per-Vcs basis, as concepts from
one VCS not necessarily apply to other (that's for example why we have
$VCS-buildpackage rather than a single vcs-buildpackage).

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

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

[Lars Wirzenius]

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 did you read about
> habits of other fellow developers in this thread.  Just reread and come back
> if you are really sure that an extra hint about patches is really useless.

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. Providing a
--verbose option rather than a --quiet option would be my preference.
Having a tool print out a lot of information that is peripheral to what
I'm doing is distracting, and if it happens often, I start mentally
ignoring the output until something breaks. Listing patches when I
unpack source is one of those cases to me.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Charles Plessy]

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 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).

Hi all,

If we take openssl as an example, we can see that many .pl files are
modified. A quick inspection shows that for most of them the only change
is the path to Perl in the first line. The only way to know if it is the
case for all is to look at all of them one by one. The Debian diff.gz
file is a technical way to apply the Debian modifications to the
original sources, but it seems to me a very suboptimal way to publish
patches of the quality level that one would expect for his own software.
To keep on the openssl example, the patched .pl are dispersed within the
.diff.gz file. That is, different logical units are mixed, and to submit
one of them would necessitate to generate a new patch that is not a
contiguous extract of the original diff.gz. This is how I understand -
and agree with - the claim that patches are "hidden" in the diff.gz.

Have a nice day

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Goswin von Brederlow]

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 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 change some
files directly and use debian/patches/ for others.
 
>> It seems to me that what we need to do is decide that using dpatch or
>> quilt is the way to go (with properly commenting individual patches).
>> It's a social problem, not a technical one.
>
> But with some time put to it, we can end up including a "the
> maintainer shuold not modify files outside of the debian/ directory
> without a strong rationale", and provide lintian checks for packages
> still directly modifying upstream code...

Do you mean no debian/patches at all?

> It can become a long transition, but a good one in the end, /methinks.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Goswin von Brederlow]

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 information get lost? (like, I use
>>rerere to help merging the current upstream version, do we lose
>>information about previous upstream versions?)
>
>   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.

If you have a feature branch that won't be accepted upstream then that
can be years old. And conflicts could have been resolved right at the
start of that time.

How does git-rerere dig out that years old conflict resolution?

How do you tell git-rerere to keep all conflict resolutions needed to
convert feature branches into a patch series but not others?

How sure are you that will actually work right and not misidentify
code at the wrong places? Ok, I guess you can compare the patch series
output against the integration branch and they should be identical.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Goswin von Brederlow]

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. 
>
> 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 happen without manual intervention, if the topic
>  branches have overlap. And  Redoing the manual conflict resolution over
>  and over and over again is a burden (the manual conflict resolution
>  lives generally in the integration branch history, and can be done
>  once, and mostly ignored 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 indeed needs human interaction as already said elsewhere.

To the non git (even not quilt) experienced user the combined patch
will be usable in that he can edit the source and fix bugs. The git
format does not allow that.

Even with some git knowledge I think that most users that write a
patch won't follow the maintainers workflow. They won't find the right
feature branch a patch belongs to and how to merge that into an
integration branch. Instead they will just edit the source, git commit
and send the resulting patch. And that means you get a patch against
the integration branch. Same as you would with the quilt format.

Users that dig deeper into the source to find out the maintainers
workflow I would expect to be able to find the maintainers git
repository too and just use that directly. So the only use for the git
format is for people that can already use the original git
repository. Hence my view that it is a bad format.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Andreas Tille]

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 of the day (yes I've
also read the hint about bazaar "loom" feature comming soon) if an

apt-get source 

which I regard THE method the obtain a Debian package source gives no
better hints about patches in the upstream source.

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Ben Finney]

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 there will be a RCS-build-package
> > > soon enough that does that.
> > 
> > This can not happen without manual intervention, if the
> >  topic branches have overlap. And Redoing the manual conflict
> >  resolution over and over and over again is a burden (the manual
> >  conflict resolution lives generally in the integration branch
> >  history, and can be done once, and mostly ignored from that point
> >  on).
> (...)
> 
> git has git rerere to deal with this.

Bazaar is soon to gain the "loom" feature, currently in development
http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt> which
also will deal with this issue.

-- 
 \ "Yesterday I parked my car in a tow-away zone. When I came back |
  `\   the entire area was missing."  -- Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Pierre Habouzit]

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 help merging the current upstream version, do we lose
>information about previous upstream versions?)

  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.

  git-rerere works by remembering versions of files before a conflict
and after its resolution, so that if this particular conflict is met
again, it just propose the last merge as a merge solution when a
conflict occurs. But it does not hides from you that you had a conflict,
it's just that instead of presenting to you a file with conflicts marks
in it, it replaced the hunks where there is a conflict with the previous
merge solution instead, so that in many cases you just have to {git
commit,git rebase --continue, ...} (depending on which action led you to
this conflict of course) without having to solve the conflict by hand.

  I'm not sure I answer your question wrt "history" but I'm not sure
it's a relevant question either.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpv9T4YynuDk.pgp
Description: PGP signature

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

[Andreas Tille]

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 other fellow developers in this thread.  Just reread and come back
if you are really sure that an extra hint about patches is really useless.


PS: are we going to somehow react to the massive loss of trust into debian,


No I just try to think about implementing what I regularly do and would
call a reasonable habit that might help others.


I just wonder why we currently discuss Mailing List
netiqette instead of the current issue.


I do so as well, but my 'd'-key works perfectly for this kind of subjects ...

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Gunnar Wolf]

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-version.diff.
> 
> It seems to me that what we need to do is decide that using dpatch or
> quilt is the way to go (with properly commenting individual patches).
> It's a social problem, not a technical one.

But with some time put to it, we can end up including a "the
maintainer shuold not modify files outside of the debian/ directory
without a strong rationale", and provide lintian checks for packages
still directly modifying upstream code...

It can become a long transition, but a good one in the end, /methinks.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Bernd Eckenfels]

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 to publish them (at least for some (most?) of the debian
packages following policy).

Gruss
Bernd

PS: are we going to somehow react to the massive loss of trust into debian,
for example by publishing a new policy, a qa task force or anything? From
quite some discussions I know it is expected (however I dont claim to have a
practcable answer). I just wonder why we currently discuss Mailing List
netiqette instead of the current issue.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Tille]

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 or not.

   Am I missing something?


Yes.  You are missing the fact that anybody who inspects a package will
inspect the debian dir anyway.  If there is a patches directory it is
obvious that upstream files are patched and there is no need to explicitely
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.

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

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 is imho conceptualy broken and the
>> > implementation is far from completely thought out.
>> 
>> 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 happen without manual intervention, if the topic
>> branches have overlap. And Redoing the manual conflict resolution
>> over and over and over again is a burden (the manual conflict
>> resolution lives generally in the integration branch history, and can
>> be done once, and mostly ignored from that point on).
> (...)

> git has git rerere to deal with this.

Two comments:

A) This is great for git users. Is there a hg-rerere? svn-rerere?
   tla-rerere? bzr-rerere?  I am just as opposed to everyone must use
   git as I am to everyone must use quilt.

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 help merging the current upstream version, do we lose
   information about previous upstream versions?)

manoj

-- 
Many people feel that they deserve some kind of recognition for all the
bad things they haven't done.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Pierre Habouzit]

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 is imho conceptualy broken and the
> > > implementation is far from completely thought out. 
> > 
> > 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 happen without manual intervention, if the topic
> >  branches have overlap. And  Redoing the manual conflict resolution over
> >  and over and over again is a burden (the manual conflict resolution
> >  lives generally in the integration branch history, and can be done
> >  once, and mostly ignored from that point on).
> (...)
> 
> git has git rerere to deal with this.

  Even better, mkdir .git/rr-cache and it'll do it automatically for
you.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp9racu8kOBK.pgp
Description: PGP signature

Re: How to handle Debian patches

[Mike Hommey]

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 completely thought out. 
> 
> 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 happen without manual intervention, if the topic
>  branches have overlap. And  Redoing the manual conflict resolution over
>  and over and over again is a burden (the manual conflict resolution
>  lives generally in the integration branch history, and can be done
>  once, and mostly ignored from that point on).
(...)

git has git rerere to deal with this.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

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 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 happen without manual intervention, if the topic
 branches have overlap. And  Redoing the manual conflict resolution over
 and over and over again is a burden (the manual conflict resolution
 lives generally in the integration branch history, and can be done
 once, and mostly ignored from that point on).

Now, the quilt series has to be regenerated on every new
 version, or whenever any topic branch gets an input; and doing the
 manual conflict resolution every time might not result in the same
 output (and not just through human error). This brings into question
 the utility of the series: the quilt series is not what the package is
 built from, and might not accurately reflect the integration branch; so
 I am told that from a security review viewpoint the resulting quilt
 series is not that useful.


Allow me to illustrate:
 Suppose there is a file that has 10 lines:
--8<---cut here---start->8---
1
2
3
4
5
6
7
8
9
10
--8<---cut here---end--->8---

I have a topic branch called Odd:
--8<---cut here---start->8---
101
2
103
4
105
6
107
8
9
10
--8<---cut here---end--->8---
And another one called even:
--8<---cut here---start->8---
1
202
3
204
5
206
7
208
9
10
--8<---cut here---end--->8---

Every change in either branch  will result in a conflict when
 trying to apply the second patch, though in this example the conflict
 resolution is trivial.  Can you demonstrate a tool that will correctly
 generate a quilt series from these branches?

manoj
-- 
The meek are contesting the will.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Manoj Srivastava]

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)
>> +++ openssl-0.9.8g/util/pl/netware.pl

> This is *exactly* what I want the 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 this
> case, did not checked).

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 or not.

Am I missing something?

manoj
-- 
Peace cannot be kept by force; it can only be achieved by
understanding. Albert Einstein
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Goswin von Brederlow]

"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'm curious about this. Why is it conceptualy broken and badly
> implemented? Is there any public URL about that?

As for implementation see the bugreport in the other reply for some
tidbits.

Conceptually I think the following:

A Debian source package is a snapshot in time of the source. The
source at the specific time of the upload.

A git repository is the full history of the source with all edits,
pushes, pulls, merged, cherry-picking all documented in the log.


So people said that the git repository should be pruned to only
contain recent stuff. But you can not do that with feature branches
without loosing the history between the branches. You can't merge
changes in a feature branch into the integration branch with that
anymore. Which would make it rather pointless.

So lets not prune it. Then you put every single source version there
ever was into the debian source package. And it will grow and grow and
grow.


And what is the point? Anyone familiar with git can just use the git
repository directly without bothering with the debian source
package. You just duplicate the repository on every debian mirror out
there.

And that is not even mentioning that the workflow in a git repository
can greatly differ between maintainer. You can have many many branches
and how is poor user supposed to know which branch to edit?

And if the user just edits the source as is, figures out how to commit
that to git and create a patch then all you end up is a patch against
the integration branch and not any feature branch. With quilt format
you get exactly the same patch automatically generated without all the
extra hoops the user has to jump through for the git format.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Mike Hommey]

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 git to use it.
> 
> I'm curious about this. Why is it conceptualy broken and badly
> implemented? Is there any public URL about that?

#477954, for one.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Miriam Ruiz]

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 and badly
implemented? Is there any public URL about that?

> The quilt format on the other hand can be used transparently instead
> of v1 format. The user does not need to learn quilt to use it. That
> aspect can be totally ignored unless you want to use it.
>
> The maintainer can use whatever he likes. 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. The maintainer can also
> import the quilt patches a NMU would add to the deb to the RCS
> repository. There is no real drawback in using quilt format even if
> you use git.

I agree with you in this.

Miry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Goswin von Brederlow]

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
>> >> 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 think that .git.tar.gz would be acceptable as replacement
>> >> for native packages (like debhelper for example). 
>> >
>> > Full ACK.
>> 
>> Full NACK.
>
> Please stop using "NACK" on public lists, it's badly connotated. It looks
> like you're forbidding someone else to do something as if you had some
> veto power.
>
>> I would rather have native packages in 3.0 quilt format. Initialy they
>> would have no patches but NMU uploads would automatically generate
>> one.
>
> If the maintainer decides to use a git-based format it's probably also
> because he prefers receving NMU as git branch in a new upload instead of
> a patch.
>
> So I don't see why you would refuse that liberty to the maintainer.
>
> It's not like the "native" package option will disappear...
>
> Cheers,

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.

The quilt format on the other hand can be used transparently instead
of v1 format. The user does not need to learn quilt to use it. That
aspect can be totally ignored unless you want to use it.


The maintainer can use whatever he likes. 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. The maintainer can also
import the quilt patches a NMU would add to the deb to the RCS
repository. There is no real drawback in using quilt format even if
you use git.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Tille]

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 stuff if you really feel spammed.


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)
+++ openssl-0.9.8g/util/pl/netware.pl


This is *exactly* what I want the 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 this case, did not checked).

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Raphael Hertzog]

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 VCS comes _before_ the
> >> source package and the source package is just an export from the VCS.
> >
> >> However I think that .git.tar.gz would be acceptable as replacement
> >> for native packages (like debhelper for example). 
> >
> > Full ACK.
> 
> Full NACK.

Please stop using "NACK" on public lists, it's badly connotated. It looks
like you're forbidding someone else to do something as if you had some
veto power.

> I would rather have native packages in 3.0 quilt format. Initialy they
> would have no patches but NMU uploads would automatically generate
> one.

If the maintainer decides to use a git-based format it's probably also
because he prefers receving NMU as git branch in a new upload instead of
a patch.

So I don't see why you would refuse that liberty to the maintainer.

It's not like the "native" package option will disappear...

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Goswin von Brederlow]

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 package is just an export from the VCS.
>
>> However I think that .git.tar.gz would be acceptable as replacement
>> for native packages (like debhelper for example). 
>
> Full ACK.

Full NACK.

I would rather have native packages in 3.0 quilt format. Initialy they
would have no patches but NMU uploads would automatically generate
one.

I mean what stops us from having foo_1.0-1.dsc contain:

foo_1.0.tar.gz
debian.tar.gz

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Bernd Eckenfels]

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 command. You can even have an alias
if you prefer that.

BTW:
+++ openssl-0.9.8g/Makefile
+++ openssl-0.9.8g/Configure
+++ openssl-0.9.8g/Makefile.shared
+++ openssl-0.9.8g/config
+++ openssl-0.9.8g/Makefile.org
+++ openssl-0.9.8g/openssl.ld
+++ openssl-0.9.8g/debian/libcrypto0.9.8-udeb.dirs
+++ openssl-0.9.8g/VMS/VMSify-conf.pl
+++ openssl-0.9.8g/Netware/do_tests.pl
+++ openssl-0.9.8g/apps/s_time.c
+++ openssl-0.9.8g/apps/CA.sh
+++ openssl-0.9.8g/apps/CA.pl.in
+++ openssl-0.9.8g/apps/speed.c
+++ openssl-0.9.8g/apps/CA.pl
+++ openssl-0.9.8g/os2/backwardify.pl
+++ openssl-0.9.8g/engines/Makefile
+++ openssl-0.9.8g/engines/openssl.ld
+++ openssl-0.9.8g/tools/c_rehash
+++ openssl-0.9.8g/tools/c_rehash.in
+++ openssl-0.9.8g/ssl/t1_lib.c
+++ openssl-0.9.8g/ms/uplink.pl
+++ openssl-0.9.8g/demos/tunala/configure.in
+++ openssl-0.9.8g/doc/Makefile
+++ openssl-0.9.8g/doc/apps/c_rehash.pod
+++ openssl-0.9.8g/crypto/Makefile
+++ openssl-0.9.8g/crypto/x86cpuid.pl
+++ openssl-0.9.8g/crypto/opensslconf.h
+++ openssl-0.9.8g/crypto/x86_64cpuid.pl
+++ openssl-0.9.8g/crypto/md5/asm/md5-x86_64.pl
+++ openssl-0.9.8g/crypto/md5/asm/md5-sparcv9.S
+++ openssl-0.9.8g/crypto/sha/sha.h
+++ openssl-0.9.8g/crypto/sha/asm/sha1-ia64.pl
+++ openssl-0.9.8g/crypto/sha/asm/sha512-sse2.pl
+++ openssl-0.9.8g/crypto/sha/asm/sha512-ia64.pl
+++ openssl-0.9.8g/crypto/rand/md_rand.c
+++ openssl-0.9.8g/crypto/des/asm/desboth.pl
+++ openssl-0.9.8g/crypto/rc4/asm/rc4-x86_64.pl
+++ openssl-0.9.8g/crypto/perlasm/x86unix.pl
+++ openssl-0.9.8g/crypto/perlasm/cbc.pl
+++ openssl-0.9.8g/crypto/perlasm/x86_64-xlate.pl
+++ openssl-0.9.8g/crypto/pkcs7/pk7_mime.c
+++ openssl-0.9.8g/crypto/bn/asm/ppc.pl
+++ openssl-0.9.8g/crypto/aes/asm/aes-586.pl
+++ openssl-0.9.8g/crypto/asn1/charmap.pl
+++ openssl-0.9.8g/util/mkerr.pl
+++ openssl-0.9.8g/util/clean-depend.pl
+++ openssl-0.9.8g/util/extract-names.pl
+++ openssl-0.9.8g/util/pod2man.pl
+++ openssl-0.9.8g/util/mkstack.pl
+++ openssl-0.9.8g/util/selftest.pl
+++ openssl-0.9.8g/util/extract-section.pl
+++ openssl-0.9.8g/util/mkdef.pl
+++ openssl-0.9.8g/util/pl/netware.pl

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Tille]

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 diff.gz").


Well, I don't know anything about quilt 3.0 and I was actually talking about
packages that do *not* using quilt or any other patch system, but just "hide"
some patches in the diff.gz.  I would like to see dpkg-source -x make some
noise about this fact - actually this idea came to me when you said that your
normally overlook those patches.  So we might nead this feature for all the
packages that *do* *not* use quilt.

And I aczually do not really care whether it is implemented using grep or

   lsdiff -z -x '*/debian/*' *.diff.gz 
or whatever - as long as I get a list of patched files brought up to my

intention immediately.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Mike Hommey]

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 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 not going to yeld the best 
> > > > > > > > results, and
> > > > > > > > I think that's my core 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 
> > > > > > > > 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?
> > > > > > 
> > > > > > 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 or .git.tar.gz (depending on whether I'm using v1 or v3 
> > > > > > source)
> > > > > > with them.
> > > > > 
> > > > > 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 quilt or 
> > > > > simple-patch-sys
> > > > > of CDBS and you know it (but you don' like those).
> > > > > 
> > > > > For .git.tar.gz, if you have a tool to generate the patches, it would 
> > > > > be
> > > > > possible to hook it into the automated system that uploads patches 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 packages
> > > > were mandated to use v3(quilt) format: patches.debian.org would be
> > > > ftp.debian.org and would just need nothing new (except for how source
> > > > packages are created)
> > > 
> > > No, you would need to untar the .debian.tar.gz file, so upstream can
> > > browse the patches.
> > 
> > And? You also have to untar the source .tar.gz from upstream web site...
> 
> It sounds better to be able to tell upstream:
>patch available from http://.../the_patch.diff fixes that.
> Rather than:
>patch the_patch.diff  in http://./foo.debian.tar.gz fixes that.

It sounds better to send the patch directly instead of telling upstream
to go to some random place to gather it.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Lucas Nussbaum]

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 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
> > > > > > > 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 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 or .git.tar.gz (depending on whether I'm using v1 or v3 
> > > > > source)
> > > > > with them.
> > > > 
> > > > 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 quilt or 
> > > > simple-patch-sys
> > > > of CDBS and you know it (but you don' like those).
> > > > 
> > > > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > > > possible to hook it into the automated system that uploads patches 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 packages
> > > were mandated to use v3(quilt) format: patches.debian.org would be
> > > ftp.debian.org and would just need nothing new (except for how source
> > > packages are created)
> > 
> > No, you would need to untar the .debian.tar.gz file, so upstream can
> > browse the patches.
> 
> And? You also have to untar the source .tar.gz from upstream web site...

It sounds better to be able to tell upstream:
   patch available from http://.../the_patch.diff fixes that.
Rather than:
   patch the_patch.diff  in http://./foo.debian.tar.gz fixes that.

No?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Mike Hommey]

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 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
> > > > > > 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 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 or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> > > > with them.
> > > 
> > > 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 quilt or simple-patch-sys
> > > of CDBS and you know it (but you don' like those).
> > > 
> > > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > > possible to hook it into the automated system that uploads patches 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 packages
> > were mandated to use v3(quilt) format: patches.debian.org would be
> > ftp.debian.org and would just need nothing new (except for how source
> > packages are created)
> 
> No, you would need to untar the .debian.tar.gz file, so upstream can
> browse the patches.

And? You also have to untar the source .tar.gz from upstream web site...

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Lucas Nussbaum]

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 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
> > > > > 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 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 or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> > > with them.
> > 
> > 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 quilt or simple-patch-sys
> > of CDBS and you know it (but you don' like those).
> > 
> > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > possible to hook it into the automated system that uploads patches 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 packages
> were mandated to use v3(quilt) format: patches.debian.org would be
> ftp.debian.org and would just need nothing new (except for how source
> packages are created)

No, you would need to untar the .debian.tar.gz file, so upstream can
browse the patches.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Josselin Mouette]

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
your VCS that you don’t realize you are making things more complicated
for the others.

> However, I am sure I doh't want to discuss this with you. Bye.

You haven’t been discussing anything from the very beginning of this
discussion.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: How to handle Debian patches

[Josselin Mouette]

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 think that .git.tar.gz would be acceptable as replacement
> for native packages (like debhelper for example). 

Full ACK.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

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

[Russ Allbery]

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Raphael Hertzog]

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 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-version.diff.

Yes but:
1/ you usually don't modify many files for many unrelated change in the
same upload
2/ that process is rather meant for NMU
3/ we can have a lintian warning to discourage this practice if we think
the maintainer should better rename the patch and

> It seems to me that what we need to do is decide that using dpatch or
> quilt is the way to go (with properly commenting individual patches).
> It's a social problem, not a technical one.

Oh sure, but the standardization that v3 quilt can bring will help a lot.
 
> Should we wait for the switch to the new source format to create
> patches.debian.org? It sounds like a better idea to write it in a way
> that makes it work with both format 1.0 and 3.0 (quilt). Maybe work from
> the extract source...

I don't want to stop anyone... feel free to start right now. :-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Raphael Hertzog]

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 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/"
>
> and I wonder whether I should file a bug report against "dpkg-source -x"
> to do this by default.

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 diff.gz").

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Raphael Hertzog]

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 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.

Yes, but not necessarily on ftp-master.debian.org.

> What you're suggesting is equivilant to us deciding by GR which helper
> system can be used in the rules file. 

I can understand how one can would have that feeling. But for me it's more
like the policy process where we make decision of what's reasonable for us
based on what's possible.

As a dpkg maintainer, I can imagine scenario where the new source package
formats are sensible to use and as such I gave my support to include them
in the set of "what's possible". 

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.

> It would stifle any futher innovation in source formats. That's a
> particularly cruel thing to do when such innovation is just getting
> started after an interminable period of stasis.

I can understand that if they are not allowed on ftp-master.d.o it means
that they'll get less exposure. However, I really think that there's quite
some work left to do before I would find it acceptable to use .git.tar.gz
as replacement for .orig+.diff or the v3 quilt format. I already explained
many of the shortcomings that concern me so I won't repeat them here (see
our discussion on debian-dpkg on that topic).

However I think that .git.tar.gz would be acceptable as replacement
for native packages (like debhelper for example). 

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[George Danchev]

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 quilt or
> > simple-patch-sys of CDBS and you know it (but you don' like those).
> >
> > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > possible to hook it into the automated system that uploads patches 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 packages
> were mandated to use v3(quilt) format: patches.debian.org would be
> ftp.debian.org and would just need nothing new (except for how source
> packages are created)

Extremely wise and sound statement. If I ever meet you on private I'd buy you 
a beer, really!

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Mike Hommey]

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 not going to yeld the best results, and
> > > > I think that's my core 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 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?
> > 
> > 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 or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> > with them.
> 
> 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 quilt or simple-patch-sys
> of CDBS and you know it (but you don' like those).
> 
> For .git.tar.gz, if you have a tool to generate the patches, it would be
> possible to hook it into the automated system that uploads patches 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 packages
were mandated to use v3(quilt) format: patches.debian.org would be
ftp.debian.org and would just need nothing new (except for how source
packages are created)

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Raphael Hertzog]

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 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 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?
> 
> 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 or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> with them.

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 quilt or simple-patch-sys
of CDBS and you know it (but you don' like those).

For .git.tar.gz, if you have a tool to generate the patches, it would be
possible to hook it into the automated system that uploads patches 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.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Neil Williams]

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 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/"
> 
> and I wonder whether I should file a bug report against "dpkg-source -x"
> to do this by default.

lintian already has that level of check but it does have problems with
generated files, see #471263:

"Files that are changed as the result of a patch to a file that is
processed during the build should be ignored - e.g. patching
configure.in|ac should mean that changes in ./configure must be ignored."

Otherwise, as soon as autotools updates or an m4 macro gets updated in
some -dev package, the "patch" for ./configure will break for no good
reason and we get a FTBFS RC bug.

Detecting which files are changed as a by-product of a patch isn't
always particularly obvious.

Incidentally, you can collapse the zgrep into lsdiff -z:

$ lsdiff -z *.diff.gz | grep -v debian

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

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

[Andreas Tille]

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

and I wonder whether I should file a bug report against "dpkg-source -x"
to do this by default.

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Lars Wirzenius]

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
> are in this set?

We could add a requirement to add Vcs- field to specify that the package
has none.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Joey Hess]

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 they
do, they already must cope with many source formats used by different
distributions.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Joey Hess]

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 your changes. And unless you do this work, the
> result is exactly the same as shipping our current giant diff.gz.
> 
> 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.

However, I am sure I doh't want to discuss this with you. Bye.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Ben Finney]

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 of the Roman Empire was |
  `\that, lacking zero, they had no way to indicate successful |
_o__)   termination of their C programs."  -- Robert Firth |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Ben Finney]

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 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.

It might allow interesting competition between the different source
formats, but it doesn't improve the upstream's patch interface,
because they still have to deal with a plural set of patch management
styles.

-- 
 \"As soon as I get through with you, you'll have a clear case |
  `\for divorce and so will my wife."  -- Groucho Marx |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Josselin Mouette]

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 this work, the
result is exactly the same as shipping our current giant diff.gz.

Unless you serialize your changes, you cannot expect them to be
understandable for NMUers. Unless you do this work, it is impossible to
make them available to upstream developers. Hacking your git dpkg-source
v3 format sounds like something that was very fun to develop, but it is
completely out of the scope of a source package distribution format.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: How to handle Debian patches

[Joey Hess]

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
> > formats to be used.
> 
> Indeed, but that doesn’t necessarily mean it is a good idea.
> 
> > What you're suggesting is equivilant to us deciding by GR which helper
> > system can be used in the rules file.
> 
> No, it is equivalent to mandating that all helpers implement the
> "build", "install" and "binary" targets in debian/rules.

No, the equivilant of those targets is the Source field in
debian/control, and dpkg-source's plugin interface.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Mike Hommey]

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 coexist.
> 
> 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.
> 
> What you're suggesting is equivilant to us deciding by GR which helper
> system can be used in the rules file. It would stifle any futher
> innovation in source formats. That's a particularly cruel thing to do
> when such innovation is just getting started after an interminable
> period of stasis.

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.

Mike

PS: Also note that the git format shouldn't even be 3.0, seeing how it's
half-baked.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Josselin Mouette]

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, but that doesn’t necessarily mean it is a good idea.

> What you're suggesting is equivilant to us deciding by GR which helper
> system can be used in the rules file.

No, it is equivalent to mandating that all helpers implement the
"build", "install" and "binary" targets in debian/rules.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: How to handle Debian patches

[Joey Hess]

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 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.

What you're suggesting is equivilant to us deciding by GR which helper
system can be used in the rules file. It would stifle any futher
innovation in source formats. That's a particularly cruel thing to do
when such innovation is just getting started after an interminable
period of stasis.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Lucas Nussbaum]

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 of VCSes, workflows, and almost
> > > packages. And no tool is really gonna sort that out. OTOH, if we _do_
> > > mandate people to one way or another serialize their patches in the
> > > source format, with comments and all that stuff, then it _IS_ a good
> > > thing, because that's the kind of things that can be grokked by tools
> > > trivially. And for that, the v3 format goes in the proper direction.
> > 
> > s/the v3 format/the v3 quilt format/
> 
>   Err yes. I indeed think the other v3 formats are somehow insane.

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.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

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 packages are actually
maintained using a $VCS. I did an approximation of that crossing data
coming from svnbuildstat with Vcs-* information, see
http://upsilon.cc/~zack/stuff/vcs-urls/ . But it has serious
limitations: it is Svn specific and only for packages registered under
svnbuildstat.debian.net.

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
versioned elsewhere, ... Plenty of room for false positives.  Even
lintian won't be able to help much here, as VCS-specific info are
usually not even in the source package (unless you want to warn for all
packages lacking a Vcs-* field, no matter what).

Still, it is a good idea to start diffusing the culture of manually
filing bugs against version controlled packages lacking the field.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Russ Allbery]

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 have started to switch my
>> packages over.  However, the one thing discussed on this thread is
>> still the thing I don't know how to do easily in Git.  I have each
>> logical change on its own branch, so I can trivially generate patches
>> to feed to upstream with git diff upstream..bug/foo, but I don't know
>> how to maintain a detailed description and status other than keeping a
>> separate file with that information somewhere independent of the
>> branch, or some special file included in the branch.
>
> How often is a logical change more than just a single commit?
> Espeically in the context of packaging, usually the changes are pretty
> trivial, and don't require multiple patches.

They often are just a single commit (although there are some exceptions),
but I often need to update the patch description to include more
information long after I originally wrote the patch.  I like to note
current upstream reactions and thinking, maybe target version numbers, and
that sort of thing.

I could so that with Manoj's idea of a separate submit branch for each one
of those, since that one I'm rebasing anyway and can use git commit
--amend or something similar to change old log messages without worrying
about breaking things.  That does require creating the separate submit
branches, though; I don't think (unless I'm missing something) that I
could do that with my topic branches without creating some of the same
problems as rebasing, since changing the commit message makes the commit a
different commit.

> Sure, a few bugs may require some new infrastructure, or making changes
> that would be best done with 2-3 patches, but any more than that and you
> probably want to be consulting with upstream before submit any changes
> anyway?

The patches that I carry relative to upstream frequently *are* done with
considerable consultation with upstream and are cherry-picked from
upstream, but I still want to track them and I still want upstream to know
what I've cherry-picked, and in general to be able to use the same
infrastructure I'd use for patches that weren't done in consultation with
upstream.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Roger Leigh]

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, or not under this form.
>> 
>> Don't you think that Vcs-Browse and Vcs-$SCN headers are
>>  normalized ways for telling end users where to get the development
>>  sources from?
>
>   For devel sources yes. Sadly, this won't give you the straight URL to
> what upstream are interested in.

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 Sources.gz (or better, the latest
development on that branch).

For example:

  Vcs-Git: git://git.debian.org/git/buildd-tools/schroot

This gives you the master branch, but the Debian packages are actually
on the schroot-1.2 stable release branch.  For people who want to hack
on what's actually in use in Debian testing/unstable right now, this
is the wrong branch.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpv0rGQMOJbh.pgp
Description: PGP signature

Re: How to handle Debian patches

[Pierre Habouzit]

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 really gonna sort that out. OTOH, if we _do_
> > mandate people to one way or another serialize their patches in the
> > source format, with comments and all that stuff, then it _IS_ a good
> > thing, because that's the kind of things that can be grokked by tools
> > trivially. And for that, the v3 format goes in the proper direction.
> 
> s/the v3 format/the v3 quilt format/

  Err yes. I indeed think the other v3 formats are somehow insane.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpeEDXEZWvA8.pgp
Description: PGP signature

Re: How to handle Debian patches

[Mike Hommey]

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
> > > 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 where to get the development
> >  sources from?
> 
>   For devel sources yes. Sadly, this won't give you the straight URL to
> what upstream are interested in.
>  
> >  We might want to see if we should shipt the VCS-* headers
> >  in the Packages file, but I thought we are trying to standardize
> >  publication of DVCS repositories in Debian now.
> 
>   Well, that's not needed, that could be really easily used in a
> patches.d.o service like Vincent is asking for. Though even with VCS-*
> headers, it's still hard to _automatically_ present things coherently
> enough for automated tools to do some useful reports. OTOH such tools
> could be written for each VCS< there aren't _that_ many of them (I mean,
> compared to the number of bug-trackers out there, bts-link showed such a
> task is doable). but again, even grokking the VCS isn't enough, you'll
> have to know where the maintainer put things in the first place. ANd
> here, grokking git isn't enough. *I* don't even use the same name for
> all my packages, I don't expect it to be more coherent for _different_
> packagers.
> 
>   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 really gonna sort that out. OTOH, if we _do_
> mandate people to one way or another serialize their patches in the
> source format, with comments and all that stuff, then it _IS_ a good
> thing, because that's the kind of things that can be grokked by tools
> trivially. And for that, the v3 format goes in the proper direction.

s/the v3 format/the v3 quilt format/

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Pierre Habouzit]

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 point to be submitted upstream. And if a patch has
> problems, or if I don't understand it, I can immediatly talk to the person
> who developed it.

  that works if upstream uses this kind of decentralized way of working,
where sending a patch to a list or a developper works. Some upstreams
will tell you to send the patch to a bugzilla, where someone will
probably eventually commit it, one day or the other (year).

  Not all upstreams are linux, git, ikiwiki or similar communities. Some
other are glibc, mozilla, .

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpvYsIUgGmeu.pgp
Description: PGP signature

Re: How to handle Debian patches

[Pierre Habouzit]

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 Vcs-Browse and Vcs-$SCN headers are
>  normalized ways for telling end users where to get the development
>  sources from?

  For devel sources yes. Sadly, this won't give you the straight URL to
what upstream are interested in.
 
>  We might want to see if we should shipt the VCS-* headers
>  in the Packages file, but I thought we are trying to standardize
>  publication of DVCS repositories in Debian now.

  Well, that's not needed, that could be really easily used in a
patches.d.o service like Vincent is asking for. Though even with VCS-*
headers, it's still hard to _automatically_ present things coherently
enough for automated tools to do some useful reports. OTOH such tools
could be written for each VCS< there aren't _that_ many of them (I mean,
compared to the number of bug-trackers out there, bts-link showed such a
task is doable). but again, even grokking the VCS isn't enough, you'll
have to know where the maintainer put things in the first place. ANd
here, grokking git isn't enough. *I* don't even use the same name for
all my packages, I don't expect it to be more coherent for _different_
packagers.

  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 really gonna sort that out. OTOH, if we _do_
mandate people to one way or another serialize their patches in the
source format, with comments and all that stuff, then it _IS_ a good
thing, because that's the kind of things that can be grokked by tools
trivially. And for that, the v3 format goes in the proper direction.

  I think people want to solve many problems, that happen to coincide
locally, but are quite different in the end. I see three of them:

  * how to have packages that everyone can modify for NMUs and security
updates, where it's obvious to anyone what the packager did. I know
_you_ don't care about that [citation needed -- but it's not hard to
find ;p] but I think it's a very important goal.

  * how to let upstreams be able to know what we do to their babies,
even when we don't have time (or are too lazy to fight against the
128 steps needed to submit a damn patch in their bugzilla[1]) to
send patches back, be able to see what we didn't sent yet easily,
and automatically (and with a finer grained method than the .diff.gz
please).

  * maintaining history of the patches, and how to they evolve for
long-lived patches. Which is a discussion that generates long
tro^H^H^Hfla^H^H^Hdiscussions on the vcs-pkg list.


  Too many people are in fact only considering the (3rd) issue because
that's clearly the one that is mind challenging and I'd even say
interesting. Though, sorry to try to try (I don't really think _you_'ll
agree ...) to bring you back to earth, but the 1st and 2nd points are
the utterly important ones, by far. How do we have nicer histories in
our VCSes is just clever and twisted bikeshedding (that I'm clearly
happy to participate in, because I'm a pervert and I like that), but
it's not what matters. What matters for real, is how simple it is for
other DD to fix our packages when we're absent, or when we don't want to
maintain a package anymore, and how easy and automatic collaboration
with upstream is. The VCS rebase vs. merge vs. patch queues vs. diff.gz
discussions are just cherry on the top.


  [1] FWIW that's exactly what often makes me "forget" about reporting a
  patch. Bugzilla really really really sucks badly for the reporter,
  the Debian BTS is _way_ better in that regard.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgptiQvAXwrv6.pgp
Description: PGP signature

Re: How to handle Debian patches

[Joey Hess]

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: Digital signature

Re: How to handle Debian patches

[Kurt Roeckx]

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 not 
> > against 
> > the VCS repo (I myself use some for my packaging), I just claim that you 
> > can 
> > expect that random upstream developers and random debian users know about 
> > it, 
> > they need instead extremely simple and stable interfaces to access the 
> > changes to their upstream source currently found in Debian archive, and we 
> > already have that for years. 
> 
> The openssl package is missing a Vcs-Svn field. If it had one it would
> be pretty easy to find its svn repo.

It would be nice that there was some kind of ducomentation on what
people might want to put in the control file that isn't in policy, like
those Vcs- things, Homepage, ...  

Similar, things like a watch file in all packages that can have one
would be great.

As far as I know, they're all documented in the developers reference.
But I don't know of a list or recommended things a package should have.

What I find handy about policy is that we have a version we put in the
control file, and it has a nice "upgrading checklist" so that you know
what changed since the last time.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Josselin Mouette]

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 or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> with them.

Are you deliberately omitting the sane formats to distribute patched
debian sources that are implemented?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: How to handle Debian patches

[Josselin Mouette]

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 different purposes - you need to browse your SCM's history,
> > in which changesets are dependent on each other. Just like quilt
> > patches.
> 
> I think you need to look at man git-blame. Or baz annotate. Or
>  hg annotate.  Or svn annotate. Or even cvs annotate.

Geez, you’re comparing apples and oranges.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: How to handle Debian patches

[Joey Hess]

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
> > 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 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 or .git.tar.gz (depending on whether I'm using v1 or v3 source)
with them.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Joey Hess]

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 normally I just keep those sorts of changes in the commit header,
> where it is easily and safely bundled with each patch.

Ditto, and if I find that I've needed multiple commits for a logical
change, I break it out into a feature branch at that point.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Joey Hess]

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 package.

That's just a matter of personal preference; if I'm coming up to speed
on a package, the first thing I do is check out its version control and
read it.

But expecting upstream do do either of these things is not going to
result in a lot more upstreams seeing patches and prevent the next
openssl disaster. In either case upstream will have to choose to wade
through lots of changes that are not interesting to them, instead of
looking at the next [PATCH] in their inbox.

> Certainly patches.d.o is not meant to replace direct interaction with
> upstream developers but it would be a nice service for upstream developers
> when the debian maintainer sucks (and it happens...) and also for other
> distributions that can benefit from our work. 
> 
> But when we give away patches, we also like to get patches from other back
> so that's why I believe that if we design any patch sharing
> infrastructure, we must open it from the beginning to other distributions
> so that we actually benefit from it too.

Well, my experience with dealing with sorting through patches from other
distributions trying to find useful changes to apply to my packages,
either in Debian, or as upstream, is that it's generally a net time
loss.

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 point to be submitted upstream. And if a patch has
problems, or if I don't understand it, I can immediatly talk to the person
who developed it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[George Danchev]

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 repo (I myself use some for my packaging), I just claim
> > that you can expect that random upstream developers and random debian
> > users know about it, they need instead extremely simple and stable
> > interfaces to access the changes to their upstream source currently found
> > in Debian archive, and we already have that for years.
>
> The openssl package is missing a Vcs-Svn field. If it had one it would
> be pretty easy to find its svn repo.

I agree if we assume that Ben is willing to have that particular VCS installed 
or there is a simple web interface (most do) to the repo. What could be of 
great boredome for poor Ben and other possibly sharp eyes is that they should 
look back in the history to find out what patches has been applied to what 
source tree or export the debian's HEAD and diff it against 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/ is would be much easier for peer 
reviewers to take a look at them without the help of VCSes and their web 
interfaces.

> I think it's about time to file mass bugs on whatever packages are left
> that use version control and lack the fields.

I agree.

P.S. I don't blame openssl packaging, since I know how much valuable work has 
been done for Debian by these people.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Theodore Tso]

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.
> However, the one thing discussed on this thread is still the thing I don't
> know how to do easily in Git.  I have each logical change on its own
> branch, so I can trivially generate patches to feed to upstream with git
> diff upstream..bug/foo, but I don't know how to maintain a detailed
> description and status other than keeping a separate file with that
> information somewhere independent of the branch, or some special file
> included in the branch.

How often is a logical change more than just a single commit?
Espeically in the context of packaging, usually the changes are pretty
trivial, and don't require multiple patches.  

Sure, a few bugs may require some new infrastructure, or making
changes that would be best done with 2-3 patches, but any more than
that and you probably want to be consulting with upstream before
submit any changes anyway?

So normally I just keep those sorts of changes in the commit header,
where it is easily and safely bundled with each patch.

- Ted


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Joey Hess]

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 just claim that you can 
> expect that random upstream developers and random debian users know about it, 
> they need instead extremely simple and stable interfaces to access the 
> changes to their upstream source currently found in Debian archive, and we 
> already have that for years. 

The openssl package is missing a Vcs-Svn field. If it had one it would
be pretty easy to find its svn repo.

I think it's about time to file mass bugs on whatever packages are left that
use version control and lack the fields.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Manoj Srivastava]

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 might not apply cleanly over each other.

> Having to merge 30 topic branches is not a workable solution either.

I personally do not have a package with 30 topic branches. I
 have had ones with about 10 or so, though none at the moment.

But in each topic branch, there are more than one patches -- I
 like having one patchset that makes a change, but still compiles and
 works, and then the next patchset, until I have the functionality
 needed for the topic branch.

This breaking up the topic branch into separate, small,
 individually documented patches helps understanding; and does not
 create an explosion of branches -- all these patches are on the same
 topic.

To do the same in quilt, by maintaining patchsets into small,
 easily understandable, but working chunks, we'll have to keep these
 patches separate -- which is why we can get away with fewer branches
 than we can with quilt patches. Or else make our quilt patches less
 easy to understand and test.

manoj
-- 
Be urgent in good; hold your thoughts off evil. When one is slack in
doing good the mind delights in evil. 116
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Mike Hommey]

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
> >> I find my old and new SCM's preferable to a quilt series -- since any
> >> feature can be compared to any other feature, or upstream,
> >> independently, and easily; this is terribly hard to do with quilt.
> 
> > 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 different purposes - you need to browse your SCM's history,
> > in which changesets are dependent on each other. Just like quilt
> > patches.
> 
> I think you need to look at man git-blame. Or baz annotate. Or
>  hg annotate.  Or svn annotate. Or even cvs annotate.
> 
> Gee, I guess RCS does not have the functionality, but how many
>  people  use RCS for version control?

OT, but while pristine RCS doesn't have that, there is a tool to just do
it for RCS managed files:
http://blame.sourceforge.net/

> So no, modern SCMs do let you find out about who changed what
>  line, though in practice I have rarely, if ever, used it.

What could be useful, and doesn't exist, though, is a functionality to
blame diffs (i.e. something displaying in what commits a line removal or
a line addition happened).

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

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 where to get the development
 sources from? We might want to see if we should shipt the VCS-* headers
 in the Packages file, but I thought we are trying to standardize
 publication of DVCS repositories in Debian now.

manoj
-- 
Alimony is like buying oats for a dead horse. Arthur Baer
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

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
>> feature can be compared to any other feature, or upstream,
>> independently, and easily; this is terribly hard to do with quilt.

> 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 different purposes - you need to browse your SCM's history,
> in which changesets are dependent on each other. Just like quilt
> patches.

I think you need to look at man git-blame. Or baz annotate. Or
 hg annotate.  Or svn annotate. Or even cvs annotate.

Gee, I guess RCS does not have the functionality, but how many
 people  use RCS for version control?

So no, modern SCMs do let you find out about who changed what
 line, though in practice I have rarely, if ever, used it.

Is there a quilt annotate/blame around?

manoj
-- 
"Someone's been mean to you! Tell me who it is, so I can punch him
tastefully." Ralph Bakshi's Mighty Mouse
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[George Danchev]

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.
> >
> > >  + it also seems that some debian developers would prefer the VCS way
> > >instead of patches.debian.org. Well, if all the debian packages are
> > >maintained with the same VCS, and it's easy to browse this from one
> > >place, then yes. Else, if I have to use git for $a, bzr for $b, svn
> > >for $c, hg for $d, etc., this is going to be a nightmare from my
> > >upstream point of view. (although it'd be fine, I guess, to have
> > >$vcs_a for $distro_a and $vcs_b for $distro_b -- the important point
> > >is that consistency to access patches for all packages in a given
> > >distro is key for upstream people)
> >
> >   We will never ever harmonize on one vcs in Debian. Don't dream of it,
> > it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_
> > but I know quite a few Ubuntu developers that use git instead so…).
>
> Sorry, my point wasn't clear: I'm not suggesting that Debian developers
> should harmonize on one vcs. I was merely saying that if multiple vcs
> are used, you shouldn't expect upstream to be happy about having to go
> to multiple places to find the patches for debian packages (unless
> all those places are integrated in some way in one unique place
> afterwards).

I absolutely agree with you. Moreover DDs still can use their favourite VCS to 
maintain their packaging, but that does not mean that upstream developers and 
debian users should be forced to follow DD everywhere. See below.

> I maintain in 5 distros, I find it more convenient to have something
> like http://patches.ubuntu.com/, http://cvs.fedoraproject.org/viewcvs/
> or http://sources.gentoo.org/viewcvs.py/gentoo-x86/ to quickly look at
> everything. (but I'd be the first to agree that this method is
> suboptimal too and that all distros could do a better job)

Ok, here is an extremely simple approach you can follow ;-). You don't need 
any special patches.d.o fancy web cruft, you don't need to know about the 
favourite VCS of any particular DD either or their favourite  
debian-patch-sys ;-). You can have the patches applied to the upstream source 
code version currently found in Debian (you are not so interested about the 
past ones, since they were merged upstream) by simply fetching debian diff.gz 
from packages.d.o/. Now comes the most stressful part: that diff.gz 
contains the debian packaging files and the changes done to the upstream 
source code. The Debian packaging files might not be of any particular 
importance to you, but the changes applied to the upstream source are, so it 
is best having a separate diff file for any logical change to the upstream 
code being done... and you are done! If that is not the case and you find 
yourself bored while fighting with one single monster blob of multiple 
logical changes being applied in a combined fashion to the upstream tree, you 
should fall-back to debian/control at least to have a clue how to visit the 
packager's favourite VCS repo. Meantime, you might learn that there is a new 
VCS invented and you should read some docs, but you shouldn't be unlucky 
since you will finally find the patches applied to a particular upstream tree 
of yours ;-)

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Russ Allbery]

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 resolved on both
>> branches.  Or is there some way to reuse the resolution work done with
>> one of those branches when rebasing/merging the other?

> Check 'man git-rerere'.

Oh, wow.  Yes, that looks like exactly what I'm looking for.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Charles Plessy]

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.4.0-6.diff.gz  82,595.1 kB
> 
> Not to mention all packages where an autoreconf run is stored as a
> patch, I'm not sure it'll help much to install it on each and every
> system.

Salut Cyril,

obviously, if nobody thinks it is a good idea, I will not go further.
Nevertheless, none of the > 100 packages we maintain in debian-med have
80 Mo of patches, nor do autofoo gizmo through patches instead of using
the autotools-dev packages, but maybe I am mislead by our particular
microcosm...

Bon week-end,

-- 
Charles


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Vincent Untz]

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 prefer the VCS way
> >instead of patches.debian.org. Well, if all the debian packages are
> >maintained with the same VCS, and it's easy to browse this from one
> >place, then yes. Else, if I have to use git for $a, bzr for $b, svn
> >for $c, hg for $d, etc., this is going to be a nightmare from my
> >upstream point of view. (although it'd be fine, I guess, to have
> >$vcs_a for $distro_a and $vcs_b for $distro_b -- the important point
> >is that consistency to access patches for all packages in a given
> >distro is key for upstream people)
> 
>   We will never ever harmonize on one vcs in Debian. Don't dream of it,
> it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_
> but I know quite a few Ubuntu developers that use git instead so…).

Sorry, my point wasn't clear: I'm not suggesting that Debian developers
should harmonize on one vcs. I was merely saying that if multiple vcs
are used, you shouldn't expect upstream to be happy about having to go
to multiple places to find the patches for debian packages (unless
all those places are integrated in some way in one unique place
afterwards).

>   FWIW I agree that the .diff.gz is a terrible way of exposing our
> modifications to the world, espcially since all is meld into that
> (debian/ specific changes not meant to be merged upstream like packaging
> stuff, or real patches that upstream should probably take). That's
> exactly why while I'm doing most of my work in git, I try to export
> patches in debian/patches sanely, and I usually also export a git
> branch, trivially browsable through my git.madism.org gitweb, hence
> without _any_ git knowledge, for upstreams to cherry-pick from. Sadly
> not everyone agrees that serializing changes we do is the way to go, and
> the latter (publishing my branch in a gitweb) isn't normalized, and
> won't probably ever be, or not under this form.

It's not about git knowledge (which is also an important point, but the
web interfaces makes it easy to solve it), it's about having to go to
git.madism.org for one debian package, git.blabla.org for another debian
package and then bzr.blablabla.org for a third debian package. Having a
central place helps.

>   The sole thing that can work is that the source package is good enough
> for everyone wanting to grok what is in our packages, because that's the
> _SOLE_ thing everyone still uses in the end. Our source format is our
> common point, it's the best place to make things like that happen.

Kind of agree, yes. Except that when I check the patches for 10 modules
I maintain in 5 distros, I find it more convenient to have something
like http://patches.ubuntu.com/, http://cvs.fedoraproject.org/viewcvs/
or http://sources.gentoo.org/viewcvs.py/gentoo-x86/ to quickly look at
everything. (but I'd be the first to agree that this method is
suboptimal too and that all distros could do a better job)

Just my €0.02 :-)

Vincent

-- 
Les gens heureux ne sont pas pressés.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Pierre Habouzit]

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 packages are
>maintained with the same VCS, and it's easy to browse this from one
>place, then yes. Else, if I have to use git for $a, bzr for $b, svn
>for $c, hg for $d, etc., this is going to be a nightmare from my
>upstream point of view. (although it'd be fine, I guess, to have
>$vcs_a for $distro_a and $vcs_b for $distro_b -- the important point
>is that consistency to access patches for all packages in a given
>distro is key for upstream people)

  We will never ever harmonize on one vcs in Debian. Don't dream of it,
it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_
but I know quite a few Ubuntu developers that use git instead so…).

  FWIW I agree that the .diff.gz is a terrible way of exposing our
modifications to the world, espcially since all is meld into that
(debian/ specific changes not meant to be merged upstream like packaging
stuff, or real patches that upstream should probably take). That's
exactly why while I'm doing most of my work in git, I try to export
patches in debian/patches sanely, and I usually also export a git
branch, trivially browsable through my git.madism.org gitweb, hence
without _any_ git knowledge, for upstreams to cherry-pick from. Sadly
not everyone agrees that serializing changes we do is the way to go, and
the latter (publishing my branch in a gitweb) isn't normalized, and
won't probably ever be, or not under this form.

  The sole thing that can work is that the source package is good enough
for everyone wanting to grok what is in our packages, because that's the
_SOLE_ thing everyone still uses in the end. Our source format is our
common point, it's the best place to make things like that happen.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpikxjuGMyyw.pgp
Description: PGP signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

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
> examining patches, and I just don't buy it.

This is not the point IMO. The point is that we won't be able in the
near future (5 years?) to converge to a single well-known $VCS, there
are just too many, and we can't require all free software eyes to grok
it. On the contrary it is the case that a list of (sequential) .diff
files are understandable by whoever is manipulating free software source
code.

So yes, in this respect I concur that a set of published (though
commented!) patches is better than $VCS.

Cheers.

PS I'm also convinced that 10 years from now the free software world
   will have converged on git, but this is a different story

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

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 would be nice if dpkg-source would automatically create a header
> template if missing and fork an editor whenever it changes a
> patch. Maybe add a comment section with a diffstat of the last changes
> that will be removed when exiting the editor for quick reference while
> describing the change.

I don't think we need such an integration at the dpkg-source level,
lintian checks are more than enough IMO. Take for examples the huge
amount of dpatch-es we have in Debian. Until a few months ago they were
basically *all* not commented, with a boilerplate description in dpatch
header. Then lintian started complaining about missing descriptions and
a lot of people [1] started commenting them. The same approach would
probably work for "3.0 (quilt)" dpkg format, as long as the matching
lintian test exists.

Cheers.

[1] I haven't made any statistics, this is an empirical analysis from my
recent experience: in the past all dpatches I stumbled upon uncommented
patches, including packages of mine, my recent experience show the
contrary.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature