On Sat, 2007-10-06 at 16:46 +1000, Anthony Towns wrote:
> On Wed, Oct 03, 2007 at 03:38:54PM +0300, Faidon Liambotis wrote:
> > There's also --rsyncable which is appears mostly (if not only) on Debian
> > and unfortunately can't be figured out from the headers.
>
> > Multipart gzips would also not
On Wed, Oct 03, 2007 at 03:38:54PM +0300, Faidon Liambotis wrote:
> There's also --rsyncable which is appears mostly (if not only) on Debian
> and unfortunately can't be figured out from the headers.
> Multipart gzips would also not work even though I haven't yet find any.
Both these are cases wh
On Wed, Oct 03, 2007 at 03:38:54PM +0300, Faidon Liambotis wrote:
> > Oh wow, that's cool. Any chance of a post/blog on how that was achieved?
[...]
Rock. This is all.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Goswin von Brederlow wrote:
> Does that mean it purposefully fails 132 files, works flawless on the
> rest and has no more "weird" cases? Or is the 132 the sum of the two?
Yes, it detects it cannot handle the 132 and fails at delta creation
time, works correctly on all the rest.
--
see shy jo
Joey Hess <[EMAIL PROTECTED]> writes:
> Faidon Liambotis wrote:
>> On the first run of the tool on the whole archive, pristine-gz succeded
>> in recognizing 21869 of 22566 orig.tar.gz (almost 97% of the archive).
>> It explicitelly failed on 206 of them (0.91%) while something weird,
>> probably a
Faidon Liambotis wrote:
> On the first run of the tool on the whole archive, pristine-gz succeded
> in recognizing 21869 of 22566 orig.tar.gz (almost 97% of the archive).
> It explicitelly failed on 206 of them (0.91%) while something weird,
> probably a bug, happened on the rest 491 (2.18%).
>
>
On Wed, Oct 03, 2007 at 03:09:56PM +0200, Bernhard R. Link wrote:
> situation, only makes it more complex as I think the OS field
> of the header zlib generates changed with the versions).
I can't remember if it included the OS field but there were several
informational things that it started ini
* Faidon Liambotis <[EMAIL PROTECTED]> [071003 15:01]:
> (zlib doesn't write the headers for you, unfortunately).
Minor nitpick: nowadays zlib can create the headers.
(As this was only added later, that of course does not change the
situation, only makes it more complex as I think the OS field
of
Anthony Towns wrote:
> On Tue, Oct 02, 2007 at 04:15:44PM -0400, Joey Hess wrote:
>> BTW, the next release of pristine-tar will support generating pristine
>> gz files too, so will fully support pristine .orig.tar.gz. Regenerating
>> pristine gz files from small deltas is quite a lot trickier, and
On Tue, Oct 02, 2007 at 04:15:44PM -0400, Joey Hess wrote:
> BTW, the next release of pristine-tar will support generating pristine
> gz files too, so will fully support pristine .orig.tar.gz. Regenerating
> pristine gz files from small deltas is quite a lot trickier, and
> currently works for abou
Junichi Uekawa wrote:
> > [EMAIL PROTECTED]:~> pristine-tar stash
> > lib/debian/unstable/uqm-voice_0.3.orig.tar.gz uqm-voice.delta
>
> Hmm.. I don't quite understand why this stashing is required. Why
> would that be. Also another question would be, would it work, for
> example, with upstream w
Hi,
> The 41k uqm-voice.delta file was created earlier as follows; normally
> this would happen when packaging the new upstream version, and it could
> be checked into revision control.
>
> [EMAIL PROTECTED]:~> pristine-tar stash
> lib/debian/unstable/uqm-voice_0.3.orig.tar.gz uqm-voice.delta
H
On Mon, Oct 01, 2007 at 03:45:39AM -0400, Joey Hess wrote:
>
> I'm hoping that some people will find this useful and support for it
> will get into svn-buildpackage, git-buildpackage, etc. I think it could
> be significantly simpler and easier to use than the complex dance
> svn-buildpackage uses
(Reposted here with additions from my blog, for people who don't read that.)
Keeping pristine upstream tarballs around is a pain, especially when working
in a team. Wouldn't it be nice to be able to keep them in revision control?
Except, it would use far too much disk...
Here's a solution. It gen
14 matches
Mail list logo
