On Fri, 15 Jul 2011, Steve Langasek wrote:
On Sun, May 29, 2011 at 10:53:03AM +0200, Raphael Hertzog wrote:
b/ modify dpkg-source --before-build to keep a trace of the fact that
it applied the patches (for example by creating
.pc/dpkg-source-auto-applied) and in that case have
Hi Raphaël,
Thanks for looking at ways to improve the dpkg-source experience.
On Sun, May 29, 2011 at 10:53:03AM +0200, Raphael Hertzog wrote:
b/ modify dpkg-source --before-build to keep a trace of the fact that
it applied the patches (for example by creating
Scott Kitterman deb...@kitterman.com writes:
On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
And note that as maintainer or for the VCS copy you can allways
configure debian/soruce/local-options to unapply
On Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow wrote:
Scott Kitterman deb...@kitterman.com writes:
On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
And note that as maintainer or for the VCS
Le Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow a écrit :
apt-get source foo
work on package
debuild
test
# Optionally: Just to be nice and fill out the header
# This would be improved by the --record-changes discussed earlier
edit debian/patches/debian-changes-version
Bernhard R. Link writes (Re: Behaviour of dpkg-source with 3.0 (quilt) and
VCS and automatic patches):
The more Debian packages you have seen, the more different ways you
have encountered and the less likely you are to be confused or to
forget to apply the patches before looking at the source,
On Thursday, June 02, 2011 05:11:30 AM Goswin von Brederlow wrote:
Scott Kitterman deb...@kitterman.com writes:
On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
And note that as maintainer or for the VCS copy
Hi Scott (2011.06.02_16:30:13_+0200)
Keeping local_options in a VCS is a bit of a workaround for this
...
I'd really like to have a way to just control this globally on my system.
+1 to that. Esp for team-maintained packages where people have different
preferences, and QA work.
SR
--
Stefano
Guido Günther a...@sigxcpu.org writes:
On Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow wrote:
Scott Kitterman deb...@kitterman.com writes:
On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
And
Charles Plessy ple...@debian.org writes:
Le Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow a écrit :
apt-get source foo
work on package
debuild
test
# Optionally: Just to be nice and fill out the header
# This would be improved by the --record-changes discussed earlier
Stefano Rivera stefa...@debian.org writes:
Hi Scott (2011.06.02_16:30:13_+0200)
Keeping local_options in a VCS is a bit of a workaround for this
...
I'd really like to have a way to just control this globally on my system.
+1 to that. Esp for team-maintained packages where people have
Scott Kitterman deb...@kitterman.com writes:
If 3.0 (quilt) didn't apply patches by default I'd have no reason not to just
use it. Keeping local_options in a VCS is a bit of a workaround for this,
but
it seems wrong to have a persistent diff between what's in the VCS for a
package and
On Thursday, June 02, 2011 02:17:14 PM Goswin von Brederlow wrote:
Scott Kitterman deb...@kitterman.com writes:
If 3.0 (quilt) didn't apply patches by default I'd have no reason not to
just use it. Keeping local_options in a VCS is a bit of a workaround
for this, but it seems wrong to have
* Scott Kitterman deb...@kitterman.com [110531 14:36]:
For some of us (me anyway), applying patches when unpacking a
source package is just the wrong kind of automagic. I'd like to
have patches applied when I say they should be applied.
Please think of the children^H^H^H^H^H^H^H^Husers. ;-
As
Bernhard R. Link brl...@debian.org writes:
* Scott Kitterman deb...@kitterman.com [110531 14:36]:
For some of us (me anyway), applying patches when unpacking a
source package is just the wrong kind of automagic. I'd like to
have patches applied when I say they should be applied.
Please
On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
And note that as maintainer or for the VCS copy you can allways
configure debian/soruce/local-options to unapply patches if you so
desire.
This is something i've been doing quite happily and I think it is
a pretty decent
On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
And note that as maintainer or for the VCS copy you can allways
configure debian/soruce/local-options to unapply patches if you so
desire.
This is something
Joachim Breitner nome...@debian.org writes:
Hi,
Am Sonntag, den 29.05.2011, 11:26 +0200 schrieb Josselin Mouette:
But it still happens that those patches are generated[1] when the
maintainer
did not expect any change at all. That's why we added the option
--abort-on-upstream-changes
Hi,
Am Dienstag, den 31.05.2011, 09:18 +0200 schrieb Goswin von Brederlow:
Joachim Breitner nome...@debian.org writes:
BTW, for all who create patches this way and want to later split the
patch into two logically independent patches, I am creating an
interactive patch splitter based on the
Hi,
Am Dienstag, den 31.05.2011, 01:25 +0300 schrieb Andrew O. Shadoura:
Especially Darcs is rightly famous for its user-friendly interface
Are you kidding? :)
Your quoting lets me wonder: Do you really doubt that Darcs’s general
user interface is more intuitive than others (especially
Bernhard R. Link brl...@debia.org wrote:
* Raphael Hertzog hert...@debian.org [110530 16:42]:
That sounds a bit better, but it adds even more magic to
dpkg-source.
I really miss some way to express: In this account, do not use
magic.
If things are not correct and need fixing, tell me what
Hi Scott (2011.05.31_12:58:05_+0200)
This fits my mental model of being a distribution developer. It
cleanly separates upstream code from packaging except when I choose to
entangle them by applying the patches.
I know others view it differently. I'm not trying to say they are
wrong, just
Hello,
On Tue, 31 May 2011 12:21:26 +0200
Joachim Breitner nome...@debian.org wrote:
Especially Darcs is rightly famous for its user-friendly interface
Are you kidding? :)
Your quoting lets me wonder: Do you really doubt that Darcs’s general
user interface is more intuitive than others
On Tue, May 31, 2011 at 12:58, Scott Kitterman deb...@kitterman.com wrote:
I know others view it differently. I'm not trying to say they are wrong,
just that source format v3 is not a good fit with my mental model. This is
why I generally avoid it in packages I maintain.
Scott K
Perhaps it
Stefano Rivera stefa...@debian.org writes:
Hi Scott (2011.05.31_12:58:05_+0200)
This fits my mental model of being a distribution developer. It
cleanly separates upstream code from packaging except when I choose
to entangle them by applying the patches.
[…]
That's my model too, and I
Andrew O. Shadoura bugzi...@tut.by writes:
Hello,
On Tue, 31 May 2011 12:21:26 +0200
Joachim Breitner nome...@debian.org wrote:
Do you really doubt that Darcs’s general user interface is more
intuitive than others (especially compared to git)? Darcs might have
its shortcomings, but its
On Sun, 29 May 2011, Benjamin Drung wrote:
Am Sonntag, den 29.05.2011, 10:53 +0200 schrieb Raphael Hertzog:
Again to cope with the scenario explained at the start of this mail,
once a user has made modifications we must ensure that they end up in a
proper patch in debian/patches/. Right now
Hi,
On Sun, 29 May 2011, Bernhard R. Link wrote:
That sounds a bit better, but it adds even more magic to dpkg-source.
I really miss some way to express: In this account, do not use magic.
If things are not correct and need fixing, tell me what is wrong and
abort so I'll never miss it.
On Sun, 29 May 2011 10:53:03 +0200, Raphael Hertzog wrote:
Auto-application of patches
---
I would like to improve this situation and not force the majority of
people to add the unapply-patches option (if it turns out the majority
of people use this option or are
Raphael Hertzog hert...@debian.org writes:
On Sun, 29 May 2011, Benjamin Drung wrote:
The file should end with .patch
(debian/patches/debian-changes-ver.patch) so that your favorite text
editor uses the correct highlighting.
At the time I wrote it, it was on purpose that I did not use any
* Raphael Hertzog hert...@debian.org [110530 16:42]:
That sounds a bit better, but it adds even more magic to dpkg-source.
I really miss some way to express: In this account, do not use magic.
If things are not correct and need fixing, tell me what is wrong and
abort so I'll never miss it.
Hi,
Am Sonntag, den 29.05.2011, 11:26 +0200 schrieb Josselin Mouette:
But it still happens that those patches are generated[1] when the maintainer
did not expect any change at all. That's why we added the option
--abort-on-upstream-changes for maintainers who never wants dpkg-source
to
Hello,
On Mon, 30 May 2011 23:30:03 +0200
Joachim Breitner nome...@debian.org wrote:
BTW, for all who create patches this way and want to later split the
patch into two logically independent patches, I am creating an
interactive patch splitter based on the darcs UI (but only the UI,
don’t
Russ Allbery r...@debian.org writes:
I have a very minor objection: I think it's aethetic clutter to add
unnecessary file extensions (we're not DOS or Windows), and any decent
editor should figure out that it's a patch from either the file format
or the fact that it's in a debian/patches
Hello,
from time to time I hear some rumblings about how 3.0 (quilt) mixes
badly with VCS. Indeed, one of the primary goals of the format
was to not require prior knowledge of the patch system to be able to
modify a package. And it's the case since you can do:
- dpkg-source -x
- modify files
-
Le dimanche 29 mai 2011 à 10:53 +0200, Raphael Hertzog a écrit :
b/ modify dpkg-source --before-build to keep a trace of the fact that
it applied the patches (for example by creating
.pc/dpkg-source-auto-applied) and in that case have dpkg-source
--after-build unapply the patches so
Hi,
Raphael Hertzog hert...@debian.org (29/05/2011):
from time to time I hear some rumblings about how 3.0 (quilt)
mixes badly with VCS. Indeed, one of the primary goals of the format
was to not require prior knowledge of the patch system to be able to
modify a package.
thanks for trying to
Am Sonntag, den 29.05.2011, 10:53 +0200 schrieb Raphael Hertzog:
Again to cope with the scenario explained at the start of this mail,
once a user has made modifications we must ensure that they end up in a
proper patch in debian/patches/. Right now this is entirely automatic,
the generated
* Raphael Hertzog hert...@debian.org [110529 10:53]:
I see 2 ways to solve this:
a/ detect the common VCS and make --unapply-patches the default in that
case (but it would require a --no-unapply-patches for the people who
keep the patches applied in their VCS)
I'd be very disappointed
Cyril Brulebois k...@debian.org writes:
Hi,
Raphael Hertzog hert...@debian.org (29/05/2011):
from time to time I hear some rumblings about how 3.0 (quilt)
mixes badly with VCS. Indeed, one of the primary goals of the format
was to not require prior knowledge of the patch system to be able
Raphael Hertzog hert...@debian.org writes:
Hello,
from time to time I hear some rumblings about how 3.0 (quilt) mixes
badly with VCS. Indeed, one of the primary goals of the format
was to not require prior knowledge of the patch system to be able to
modify a package. And it's the case since
41 matches
Mail list logo
