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 d
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
>.pc/dpkg-source-auto-app
On Thursday, June 02, 2011 02:17:14 PM Goswin von Brederlow wrote:
> Scott Kitterman 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
Scott Kitterman 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 what's in the arc
Stefano Rivera 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 different
> prefe
Charles Plessy 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
>> edit
Guido Günther writes:
> On Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow wrote:
>> Scott Kitterman 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 mainta
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
--
Stefan
On Thursday, June 02, 2011 05:11:30 AM Goswin von Brederlow wrote:
> Scott Kitterman 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 allw
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
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-versi
On Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow wrote:
> Scott Kitterman 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 ca
Scott Kitterman 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 patches if you s
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 some
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 c
"Bernhard R. Link" writes:
> * Scott Kitterman [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
* Scott Kitterman [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 user of some pac
"Andrew O. Shadoura" writes:
> Hello,
>
> On Tue, 31 May 2011 12:21:26 +0200
> Joachim Breitner 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 UI is always pointed o
Stefano Rivera 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 find v3 works w
On Tue, May 31, 2011 at 12:58, Scott Kitterman 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 would be time n
Hello,
On Tue, 31 May 2011 12:21:26 +0200
Joachim Breitner 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 (especially co
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, ju
"Bernhard R. Link" wrote:
>* Raphael Hertzog [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
>> > ab
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 c
Hi,
Am Dienstag, den 31.05.2011, 09:18 +0200 schrieb Goswin von Brederlow:
> Joachim Breitner 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 darcs UI (b
Joachim Breitner 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 for
Russ Allbery 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 directory.
I am
Hello,
On Mon, 30 May 2011 23:30:03 +0200
Joachim Breitner 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 worry):
> http://
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
>
* Raphael Hertzog [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." (Actuall
Raphael Hertzog writes:
> On Sun, 29 May 2011, Benjamin Drung wrote:
>> The file should end with .patch
>> (debian/patches/debian-changes-.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
> extension. 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 a
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, 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/. Rig
Raphael Hertzog 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 you can do
Cyril Brulebois writes:
> Hi,
>
> Raphael Hertzog (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.
* Raphael Hertzog [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 if the more cons
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
Hi,
Raphael Hertzog (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 improve the s
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
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
- d
41 matches
Mail list logo
