On Sat, Feb 16, 2008, David Paleino wrote:
We’ve always done this way in pkg-gnome’s SVN, keeping only debian/
directories, while using simple-patchsys, dpatch, dbs (muahaha) and now
standardizing on quilt.
... and? Something's missing: do you use svn-do?
I wrote it for pkg-gnome. :)
On jeu, 2008-02-07 at 23:07 +0100, Sven Mueller wrote:
However, I wonder wether quilt has any way (through a known wrapper
perhaps) to support the thing I like (though I'm not too attached to
that feature) with dpatch:
Being able to keep only debian/* in the repository along with the
Il giorno Sat, 16 Feb 2008 17:07:18 +0100
Josselin Mouette [EMAIL PROTECTED] ha scritto:
On jeu, 2008-02-07 at 23:07 +0100, Sven Mueller wrote:
However, I wonder wether quilt has any way (through a known wrapper
perhaps) to support the thing I like (though I'm not too attached to
that
On sam, 2008-02-16 at 18:25 +0100, David Paleino wrote:
Il giorno Sat, 16 Feb 2008 17:07:18 +0100
Josselin Mouette [EMAIL PROTECTED] ha scritto:
On jeu, 2008-02-07 at 23:07 +0100, Sven Mueller wrote:
However, I wonder wether quilt has any way (through a known wrapper
perhaps) to
[please CC me on replies]
-=| Damyan Ivanov, Fri, Feb 08, 2008 at 01:35:52PM +0200 |=-
-=| Sven Mueller, Thu, Feb 07, 2008 at 11:07:00PM +0100 |=-
gregor herrmann schrieb:
On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
Is there any easy conversion from dpatch to quilt for a
[please CC me on replies]
-=| Sven Mueller, Thu, Feb 07, 2008 at 11:07:00PM +0100 |=-
gregor herrmann schrieb:
On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
Is there any easy conversion from dpatch to quilt for a given package
that is using dpatch?
On Thu, 07 Feb 2008 23:07:00 +0100, Sven Mueller wrote:
* script (but svn-centric):
http://svn.debian.org/wsvn/pkg-perl/scripts/dpatch2quilt?op=filerev=0sc=0
The script should (IMHO) make sure QUILT_PATCHES is set correctly.
(Cc'ing dmn because of this)
Good catch, thanks!
Fixed.
On Thursday 07 February 2008 11:07:00 pm Sven Mueller wrote:
However, I wonder wether quilt has any way (through a known wrapper
perhaps) to support the thing I like (though I'm not too attached to
that feature) with dpatch:
Being able to keep only debian/* in the repository along with the
On Sat, 26 Jan 2008, Pierre Habouzit wrote:
Seconded. I'd add, that in fact we should standardize on quilt as an
exchange format for patches, because it's simple, and that there are
powerful tools to handle them. Basically you have almost the same power
in quilt that in many SCMs when it comes
On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:
Is there any easy conversion from dpatch to quilt for a given package
that is using dpatch?
The following two links might give an idea:
* manual conversion:
http://blog.orebokech.com/2007/08/converting-debian-packages-from-dpatch.html
On Jan 28, 2008 5:09 PM, Andreas Tille [EMAIL PROTECTED] wrote:
Is there any easy conversion from dpatch to quilt for a given package
that is using dpatch?
It is as simple as:
mv debian/patches/00list debian/patches/series
rename s/\.dpatch$/.patch/ debian/patches/*
edit
Il giorno Mon, 28 Jan 2008 09:09:28 +0100 (CET)
Andreas Tille [EMAIL PROTECTED] ha scritto:
Is there any easy conversion from dpatch to quilt for a given package
that is using dpatch?
Isn't dpatch just adding a header (from #!/usr/bin/dpatch -f to @DPATCH@)?
Or am I missing something? I
On 28/01/2008, Paul Wise wrote:
maybe edit debian/patches/*.patch to remove all the dpatch comments
and just leave the patch descriptions and other human-readable info.
QUILT_REFRESH_ARGS=-p0 --no-timestamps --no-index
Agreed on --no-index, not convinced by --no-timestamps and -p0.
FWIW, I
On Mon, Jan 28, 2008 at 10:51:06AM +, Cyril Brulebois wrote:
On 28/01/2008, Paul Wise wrote:
maybe edit debian/patches/*.patch to remove all the dpatch comments
and just leave the patch descriptions and other human-readable info.
QUILT_REFRESH_ARGS=-p0 --no-timestamps --no-index
Pierre Habouzit [EMAIL PROTECTED] writes:
Though the need for --not-timestamps is really important when you
refresh a whole patch series, and don't want spurious timestamps changes
generating useless changes in your $SCM, and I do use it for this very
reason.
Yes. Please use
On Jan 28, 2008 8:36 PM, Pierre Habouzit [EMAIL PROTECTED] wrote:
On Mon, Jan 28, 2008 at 10:51:06AM +, Cyril Brulebois wrote:
On 28/01/2008, Paul Wise wrote:
maybe edit debian/patches/*.patch to remove all the dpatch comments
and just leave the patch descriptions and other
On Wed, 16 May 2007 13:52:28 +0200, Magnus Holmgren
[EMAIL PROTECTED] wrote:
But since svn checkout doesn't give you the whole thing, how do you
prefer to work (especially with respect to creating patches)? Do you unpack
the orig tarball on top and set the svn:ignore property to ., or always
On Wed, 16 May 2007 13:52:28 +0200, Magnus Holmgren
[EMAIL PROTECTED] wrote:
But since svn checkout doesn't give you the whole thing, how do you
prefer to work (especially with respect to creating patches)? Do you
unpack the orig tarball on top and set the svn:ignore property to .,
or always
tjena magnus,
just a quick anecdotal experience to throw into the thread...
for all its strengths and weaknesses, i'm pretty happy with
svn-buildpackage, mergeWithUpstream, and a debian/patches dir. for a
long time my biggest issue with this was having to maintain these
patches across upstream
On Wednesday 16 May 2007 14:52, Marcus Better wrote:
Magnus Holmgren wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly!
I fully agree. Unfortunately Subversion doesn't make it easy for you. You
can keep
Le jeudi 17 mai 2007 à 13:12 +0200, Magnus Holmgren a écrit :
On Wednesday 16 May 2007 14:52, Marcus Better wrote:
Magnus Holmgren wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly!
I fully agree.
On Thursday 17 May 2007 05:12:52 Magnus Holmgren wrote:
On Wednesday 16 May 2007 14:52, Marcus Better wrote:
Magnus Holmgren wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly!
I fully agree.
I try to keep all changes to upstream as a number of patches in
debian/patches. I've heard that restricting the .diff.gz to ./debian is a
Good Thing. The drawback is that the .diff.gz becomes more difficult to read,
with the diff of diffs and all, but once the source package is unpacked it's
Hi
On Wed, 16 May 2007 13:52:28 +0200
Magnus Holmgren [EMAIL PROTECTED] wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly! Maybe it is.
What's for certain is, that to someone who just does 'apt-get
Magnus Holmgren [EMAIL PROTECTED] wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly! Maybe it is.
I don't agree. With patches in debian/patches, you can give names to
those files. Names that explain what
Magnus Holmgren wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly!
I fully agree. Unfortunately Subversion doesn't make it easy for you. You
can keep your patches in different feature branches, but it gets
On Wednesday 16 May 2007 14:52, Marcus Better wrote:
However, he can read debian/copyright and
debian/README.Debian to find out where the maintainer keeps his
repository,
Or check the PTS, if you use XS-Vcs-* control fields.
Yeah, I suppose I didn't know that when I started writing my
Marcus Better [EMAIL PROTECTED] wrote:
Frank Küster wrote:
The VCS can handle the changesets. Putting patches under VCS is silly!
I don't agree. With patches in debian/patches, you can give names to
those files.
With a VCS you can also name branches, or changesets (stgit).
Personally,
Magnus Holmgren wrote:
I have now. IIUC, it lets you group and name diffs vs. a particular state
of the source code, but the end result is a normal .diff.gz, meaning that
everyone else has to use stgit too to get all the benefits, right?
Yes. People working on the same project team should use
Frank Küster wrote:
Personally, I don't like branches very much. Nobody ever explained to
me a good receipe to handle them in the case where development proceeds
in both, and important fixes are copied from one to the other.
I believe git handles that, it should work nicely in most cases.
On (16/05/07 13:52), Magnus Holmgren wrote:
svn-buildpackage has a feature called mergeWithUpstream mode, which means
that only the files that are actually touched are put under version control
(I thought most $TLA-buildpackage would have something similar, but it seems
to be unique to
Frank Küster wrote:
Personally, I don't like branches very much. Nobody ever explained to
me a good receipe to handle them in the case where development proceeds
in both, and important fixes are copied from one to the other.
http://youtube.com/watch?v=4XpnKHJAok8
is good to view if you're
32 matches
Mail list logo
