On Wednesday 05 August 2009 14:21:54 Cyril Brulebois wrote:
> Michael Banck (05/08/2009):
> > On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote:
> > > And for the format of the patch, I do not know what to tell them
> > > apart that unified diff is the preferred format of some Debian
Charles Plessy writes:
> Le Wed, Aug 05, 2009 at 03:45:00PM +1000, Ben Finney a écrit :
> >
> > The point, rather, seems to be that unified-diff format is the de
> > facto standard format for exchanging patch information.
>
> Le Wed, Aug 05, 2009 at 10:53:21AM +0200, Michael Banck a écrit :
> >
Michael Banck (05/08/2009):
> On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote:
> > And for the format of the patch, I do not know what to tell them
> > apart that unified diff is the preferred format of some Debian
> > developers,
>
> It's the preferred format for 99% of all Free
On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote:
> And for the format of the patch, I do not know what to tell them apart that
> unified diff is the preferred format of some Debian developers,
It's the preferred format for 99% of all Free Software work/projects
AFAICT.
> and that
Charles Plessy writes:
> Le Tue, Aug 04, 2009 at 09:51:26AM +0200, Paul Wise a écrit :
> > Perhaps you could talk to upstream about switching to either using
> > unified diffs for updates, tarballs for every release or a git/etc
> > repository?
>
> For sure, Debian can suggest them git, Ubuntu c
Le Tue, Aug 04, 2009 at 09:51:26AM +0200, Paul Wise a écrit :
> Perhaps you could talk to upstream about switching to either using
> unified diffs for updates, tarballs for every release or a git/etc
> repository?
For sure, Debian can suggest them git, Ubuntu can suggest them bzr, Fedora can
sugge
Perhaps you could talk to upstream about switching to either using
unified diffs for updates, tarballs for every release or a git/etc
repository?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
Le Mon, Aug 03, 2009 at 06:18:57PM +0200, Raphael Hertzog a écrit :
>
> > The patch is not in unified format, which causes the failure of
> > dpkg-buildpackage. It is trivial to refresh it with quilt to the unified
> > format, but this introduces a divergence with upstream that I would prefer
> >
On Sun, 02 Aug 2009, Charles Plessy wrote:
> I see that .bzip2 and .lzma are also supported compression methods for the 3.0
> (native) format as well as for the binary packages. But I do not think it
> would
> be useful to add zip to this list. It seems to me that the only thing needed
> is
> the
Vincent Danjean wrote:
Emilio Pozuelo Monfort wrote:
Charles Plessy wrote:
I see that .bzip2 and .lzma are also supported compression methods for the 3.0
(native) format as well as for the binary packages. But I do not think it would
be useful to add zip to this list. It seems to me that the on
Charles Plessy writes:
> Another question that I would like to ask is on the auto-patching
> functionality. One of the programs we package, EMBOSS, is released once a
> year
> every 15th of July, and other updates are made via patches. Currently it is
> possible to just give the patch to quilt
On Sun, Aug 02, 2009 at 08:11:57PM +, Philipp Kern wrote:
> On 2009-08-02, Vincent Danjean wrote:
> > Unpacking a source package is not needed during an upgrade. However, it
> > occurs before
> > a build.
> >
> > So, I understand the question of Charles as "do we want that stable dpkg be
> >
On 2009-08-02, Vincent Danjean wrote:
> Unpacking a source package is not needed during an upgrade. However, it
> occurs before
> a build.
>
> So, I understand the question of Charles as "do we want that stable dpkg be
> able to
> unpack all packages from testing ?". I have no strong opinion for
Emilio Pozuelo Monfort wrote:
> Charles Plessy wrote:
>> I see that .bzip2 and .lzma are also supported compression methods for the
>> 3.0
>> (native) format as well as for the binary packages. But I do not think it
>> would
>> be useful to add zip to this list. It seems to me that the only thing
Raphael Hertzog writes:
> On Sun, 02 Aug 2009, Charles Plessy wrote:
>> But actually, among the programs that are not distributed upstream in a
>> tar.gz format, we in the Debian Med team have as many zip cases as
>> bzip2. Do you think that it would be possible to support zip format
>> (i.e. .zi
Charles Plessy wrote:
> I see that .bzip2 and .lzma are also supported compression methods for the 3.0
> (native) format as well as for the binary packages. But I do not think it
> would
> be useful to add zip to this list. It seems to me that the only thing needed
> is
> the capacity to unpack t
Le Sun, Aug 02, 2009 at 11:03:11AM +0200, Raphael Hertzog a écrit :
> On Sun, 02 Aug 2009, Charles Plessy wrote:
About zip support:
> > But actually, among the programs that are not distributed upstream in a
> > tar.gz
> > format, we in the Debian Med team have as many zip cases as bzip2. Do you
On Sun, 02 Aug 2009, Charles Plessy wrote:
> But actually, among the programs that are not distributed upstream in a tar.gz
> format, we in the Debian Med team have as many zip cases as bzip2. Do you
> think
> that it would be possible to support zip format (i.e. .zip, .jar and .xpi
> extensions)
Le Thu, Jul 30, 2009 at 04:55:16PM +0200, Raphael Hertzog a écrit :
>
> I updated the wiki page listing the status of this project:
> http://wiki.debian.org/Projects/DebSrc3.0
Bonjour Raphaël,
first of all, thank you for making things progress for the support of a
next-generation source format
19 matches
Mail list logo
