-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 17 Feb 2010 17:38:22 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.7-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman p...@debian.org
Changed-By: Paul Slootman p...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Tue, 05 Jan 2010 12:50:44 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.7-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman p...@debian.org
Changed-By: Paul Slootman p...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 21 Nov 2009 17:56:22 +0100
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.5-1
Distribution: unstable
Urgency: low
Maintainer: Debian Gadmintools Maintainers
gadminto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 20 Aug 2009 09:39:45 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.4-2
Distribution: unstable
Urgency: low
Maintainer: Debian Gadmintools Maintainers
gadminto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 20 Jul 2009 11:07:16 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.3-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann dan...@debian.org
Changed-By: Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 20 Jul 2009 11:10:16 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.4-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann dan...@debian.org
Changed-By: Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 17 Jun 2009 13:43:12 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.6-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman p...@debian.org
Changed-By: Paul Slootman p...@debian.org
: rsync-based GUI data backup utility
luckyBackup is an application that backs-up and/or synchronizes any
directories with the power of rsync.
Its main features are: backup, safety, synchronization, exclude/only include
options, allows custom rsync options, remote connections, restore and dry-run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 18 May 2009 12:24:55 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.2-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann dan...@debian.org
Changed-By: Daniel
, ... but it seems rsync on
people.debian.org creates directories and files with 700 permission.
This is new behavior. If you are synching html pages from your work
station, you need to follow rsync with ssh running chmod.
Osamu
Are you sure you are using the right flags and your local files have
Hi,
When my usual web page updates failed, I was checking my ethernet
connection ... I wondered why ... Here is the reason:
I might have missed some announcment, ... but it seems rsync on
people.debian.org creates directories and files with 700 permission.
This is new behavior. If you
Osamu Aoki os...@debian.org writes:
Hi,
When my usual web page updates failed, I was checking my ethernet
connection ... I wondered why ... Here is the reason:
I might have missed some announcment, ... but it seems rsync on
people.debian.org creates directories and files with 700
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Tue, 27 Jan 2009 11:07:00 +0100
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann dan...@debian.org
Changed-By: Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 22 Jan 2009 15:05:27 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.5-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman p...@debian.org
Changed-By: Paul Slootman p...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 24 Sep 2008 11:35:15 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.4-3
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 14 Sep 2008 12:04:00 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.0-2
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 12 Sep 2008 11:00:20 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.4-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 11 Sep 2008 11:57:46 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.4-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 25 Jul 2008 10:43:00 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.3-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 02 Jul 2008 11:07:22 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.3-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 20 Jun 2008 11:24:00 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.1.0-1
Distribution: unstable
Urgency: medium
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 28 Apr 2008 13:06:35 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.2-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 17 Apr 2008 23:14:00 +0200
Source: gadmin-rsync
Binary: gadmin-rsync gadmin-rsync-dbg
Architecture: source i386
Version: 0.0.9-3
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 17 Apr 2008 23:09:00 +0200
Source: gadmin-rsync
Binary: gadmin-rsync
Architecture: source i386
Version: 0.0.9-2
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel Baumann [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 08 Apr 2008 19:34:22 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.2-1
Distribution: unstable
Urgency: high
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 04 Apr 2008 12:36:56 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.1-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 31 Mar 2008 15:29:51 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.1~pre3-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 04 Mar 2008 12:34:03 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 02 Mar 2008 13:45:09 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 26 Feb 2008 10:31:00 +0100
Source: gadmin-rsync
Binary: gadmin-rsync
Architecture: source i386
Version: 0.0.9-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel Baumann [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 20 Feb 2008 11:20:47 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre10-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 11 Feb 2008 11:35:13 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre9-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 04 Feb 2008 16:25:54 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre8-2
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 13 Jan 2008 13:37:17 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre8-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 20 Dec 2007 12:53:35 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre7-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 11 Dec 2007 11:29:50 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 2.6.9-6
Distribution: unstable
Urgency: high
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 03 Dec 2007 17:00:37 +0100
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.9-5.1
Distribution: unstable
Urgency: high
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Nico Golde [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 12 Nov 2007 12:30:38 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre5-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 07 Nov 2007 13:22:25 -0800
Source: libfile-rsync-perl
Binary: libfile-rsync-perl
Architecture: source all
Version: 0.42-2
Distribution: unstable
Urgency: low
Maintainer: Ivan Kohler [EMAIL PROTECTED]
Changed-By: Ivan Kohler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 05 Oct 2007 11:06:31 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 3.0.0~pre1-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 15 Aug 2007 21:24:47 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 2.6.9-5
Distribution: unstable
Urgency: high
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
: GUI front-end to display rsync status
gtkrsync is a simple GUI that displays a running status display
built from rsync --progress -v. This status display includes a
per-file and overall status bar, overall estimated time to completion,
and an expandable button that shows all rsync status
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 12 Dec 2006 14:39:43 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 2.6.9-3
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 7 Nov 2006 12:32:20 +0100
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 2.6.9-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 27 Oct 2006 12:27:45 +0200
Source: rsync
Binary: rsync
Architecture: source amd64
Version: 2.6.9~pre3-1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
be fantastic for kernel sources
a.
---
A Mennucc [EMAIL PROTECTED] writes:
Brian Eaton wrote:
Hello all -
Regarding the ideas discussed here:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done some log file analysis to figure out how much
bandwidth would
hi
I had the same idea some time ago
if you ever decide to work on that, I may help
Goswin von Brederlow wrote:
I actualy have a little hack how one could implement patch debs now to
test this out:
1. Create an archive mirror with rsync batch files (or xdelta or
whatever) between
On Mon, 01 May 2006 09:30:55 +0200, Florian Weimer [EMAIL PROTECTED]
wrote:
The downside is that anything that doesn't work on entire .debs is
very likely to change them at the byte stream level (you only need to
use slightly different zlib versions or parameters). This means that
the chain of
. Create an archive mirror with rsync batch files (or xdelta or
whatever) between the last and current version of each package. It
might be simplest to replace the data.tar.gz in each deb with the
rsync batch file and leave the rest of the deb as is.
2. Create Packages.gz and friends for those
of the package. Currently my notebook is broken (power
transformer fried with a white flash); when it is alive again, I will
post more details.
a.
Brian Eaton wrote:
Hello all -
Regarding the ideas discussed here:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done
if that
position is also on chunk boundaries.
Rsync has a per chunk Alder-32 and md4 checksum. Those chunk checksums
are compared to a chunk at every byte position in the file. The
Adler-32 checksum is fairly weak but it can be updated from one
position to the next with minimal work. Only when
Peter Samuelson [EMAIL PROTECTED] writes:
* Goswin von Brederlow:
Look at zsync and help develope it far enough so it can look into
debs. Without that the gain is practicaly 0 or less.
The other thing to do would be to lobby for dpkg-deb and dpkg-source to
use 'gzip --rsyncable' when
Pierre Habouzit [EMAIL PROTECTED] writes:
Le Lun 1 Mai 2006 15:31, Brian Eaton a écrit :
On 4/30/06, Goswin von Brederlow wrote:
Look at zsync and help develope it far enough so it can look into
debs. Without that the gain is practicaly 0 or less.
It's entirely possible that the gain
I demand that Pierre Habouzit may or may not have written...
[snip; delta packages?]
The real question is: do people clean their apt cache or not? I do, because
after a full X.org/kde/openoffice upgrade, it takes quite a lot of disk in
/var (that is small on my computers). And with that cache
I demand that Andreas Barth may or may not have written...
* Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
Or you could create the diffdebs before upload or on ftp-master, and
include the diffdebs somehow in the Packages file (so they're
* Darren Salt ([EMAIL PROTECTED]) [060502 19:03]:
I demand that Andreas Barth may or may not have written...
* Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
Or you could create the diffdebs before upload or on ftp-master, and
include the
* Goswin von Brederlow:
Tyler MacDonald [EMAIL PROTECTED] writes:
Brian Eaton [EMAIL PROTECTED] wrote:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done some log file analysis to figure out how much
bandwidth would be saved by transferring package deltas
* Goswin von Brederlow:
Look at zsync and help develope it far enough so it can look into
debs. Without that the gain is practicaly 0 or less.
The other thing to do would be to lobby for dpkg-deb and dpkg-source to
use 'gzip --rsyncable' when building stuff. (That, or sneak
--rsyncable
On 5/1/06, Brian Eaton [EMAIL PROTECTED] wrote:
Hello all -
Regarding the ideas discussed here:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
A few comments:
3.2 rsync is too hard on servers
That document claims it's an avoidable cost. It's not really, because
the client
On 4/30/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Brian Eaton [EMAIL PROTECTED] wrote:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done some log file analysis to figure out how much
bandwidth would be saved by transferring package deltas instead
* Brian Eaton ([EMAIL PROTECTED]) [060501 15:51]:
The only time delta packages will be a win is for upgrades where the
client has the original package cached.
If one does it right, it might be enough if the original package is
*installed*. And that happens quite often, e.g. even for security
Le Lun 1 Mai 2006 15:31, Brian Eaton a écrit :
On 4/30/06, Goswin von Brederlow wrote:
Look at zsync and help develope it far enough so it can look into
debs. Without that the gain is practicaly 0 or less.
It's entirely possible that the gain will be nothing no matter what
algorithm is
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
* Brian Eaton ([EMAIL PROTECTED]) [060501 15:51]:
The only time delta packages will be a win is for upgrades where the
client has the original package cached.
If one does it right, it might be enough if the original package is
*installed*. And
Le Lun 1 Mai 2006 16:35, Brian Eaton a écrit :
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
* Brian Eaton ([EMAIL PROTECTED]) [060501 15:51]:
The only time delta packages will be a win is for upgrades where
the client has the original package cached.
If one does it right, it
* Brian Eaton ([EMAIL PROTECTED]) [060501 16:42]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
* Brian Eaton ([EMAIL PROTECTED]) [060501 15:51]:
The only time delta packages will be a win is for upgrades where the
client has the original package cached.
If one does it right, it might
* Brian Eaton ([EMAIL PROTECTED]) [060501 17:49]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
* Brian Eaton ([EMAIL PROTECTED]) [060501 16:42]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
If one does it right, it might be enough if the original package is
*installed*. And
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
* Brian Eaton ([EMAIL PROTECTED]) [060501 16:42]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
If one does it right, it might be enough if the original package is
*installed*. And that happens quite often, e.g. even for security
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
Or you could create the diffdebs before upload or on ftp-master, and
include the diffdebs somehow in the Packages file (so they're signed as
well by the usual mechanismn).
My initial view is that any delta package system that doesn't
reproduce
* Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]:
On 5/1/06, Andreas Barth [EMAIL PROTECTED] wrote:
Or you could create the diffdebs before upload or on ftp-master, and
include the diffdebs somehow in the Packages file (so they're signed as
well by the usual mechanismn).
My initial view is
Hello all -
Regarding the ideas discussed here:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done some log file analysis to figure out how much
bandwidth would be saved by transferring package deltas instead of
entire new packages?
Assuming someone hasn't done
Brian Eaton [EMAIL PROTECTED] wrote:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done some log file analysis to figure out how much
bandwidth would be saved by transferring package deltas instead of
entire new packages?
Slightly off-topic, but I
Tyler MacDonald [EMAIL PROTECTED] writes:
Brian Eaton [EMAIL PROTECTED] wrote:
http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
Has anyone ever done some log file analysis to figure out how much
bandwidth would be saved by transferring package deltas instead of
entire new
.
Rsync has a per chunk Alder-32 and md4 checksum. Those chunk checksums
are compared to a chunk at every byte position in the file. The
Adler-32 checksum is fairly weak but it can be updated from one
position to the next with minimal work. Only when it matches does
rsync compute the expensive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 29 Apr 2006 13:07:43 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.8-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 24 Apr 2006 12:26:19 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.8-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 13 Apr 2006 10:51:39 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.7-2.6.8pre1
Distribution: experimental
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 17 Mar 2006 11:39:22 +0100
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.7-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
cryptographic assurances.
Just as a side note other developers may be interested in knowing, the
debian keyring can be synced via rsync. I personally like having a
mostly-up-to-date copy of it in my computer.
% cat /etc/cron.weekly/LOCAL-update-keyring
#! /bin/sh -e
cd /var/local
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 22 Sep 2005 05:41:28 -0700
Source: libfile-rsync-perl
Binary: libfile-rsync-perl
Architecture: source all
Version: 0.42-1
Distribution: unstable
Urgency: low
Maintainer: Ivan Kohler [EMAIL PROTECTED]
Changed-By: Ivan Kohler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 29 Jul 2005 10:47:04 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.6-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 3 Jun 2005 19:17:28 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.5-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 10 May 2005 21:44:29 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.4-6
Distribution: unstable
Urgency: high
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 27 Apr 2005 10:54:43 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.4-5
Distribution: unstable
Urgency: high
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 26 Apr 2005 17:05:55 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.4-3
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 26 Apr 2005 17:39:55 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.4-4
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 10 Apr 2005 14:06:28 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.4-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 4 Apr 2005 15:46:38 +0200
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.4-1
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 21 Jan 2005 18:20:27 -0800
Source: libfile-rsync-perl
Binary: libfile-rsync-perl
Architecture: source all
Version: 0.36-1
Distribution: unstable
Urgency: low
Maintainer: Ivan Kohler [EMAIL PROTECTED]
Changed-By: Ivan Kohler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 17 Nov 2004 18:22:36 +0100
Source: rsync
Binary: rsync
Architecture: source i386
Version: 2.6.3-2
Distribution: unstable
Urgency: low
Maintainer: Paul Slootman [EMAIL PROTECTED]
Changed-By: Paul Slootman [EMAIL PROTECTED
load of rsync, and did that exactly once,
so I don't keep saying it. Also, I put in an IIRC, so you have clear
indication that I'm not too sure - somebody asked about the reason, I
answered with that I heard was the reason when the last person asked.
-- vbi
--
Oops
pgp5WZplFp7Wy.pgp
IIRC the problem is that rsync is quite CPU-heavy on the servers, so while
the mirrors have the (network) resources to feed downloads to 100s of
users, they don't have the (CPU) resources for a few dozen rsyncs.
Why do you keep on saying this without providing _any_ figures!
Who
Can anyone explain why rsync is no longer considered an appropriate
method for fetching Packages files?
IIRC the problem is that rsync is quite CPU-heavy on the servers, so while
the mirrors have the (network) resources to feed downloads to 100s of
users, they don't have the (CPU
On Thu, Nov 04, 2004 at 05:46:55PM +0100, Otto Wyss wrote:
Now if you feel advantous, repack as many package on the source mirror
with gzip --rsyncable and notice the difference.
Exactly how is this going to help? I can only see this as being
useful when the files change. Files should never
On Thu, Nov 04, 2004 at 06:35:40PM +0100, Kurt Roeckx wrote:
On Thu, Nov 04, 2004 at 05:46:55PM +0100, Otto Wyss wrote:
Now if you feel advantous, repack as many package on the source mirror
with gzip --rsyncable and notice the difference.
Exactly how is this going to help? I can only
never change. You
get a completly new file. Unless you can somehow tell to use the
old file as base, this is not going to help.
there was a patch by paul russell floating around to build a heuristic
into rsync to allow it to figure out from the name which file might be
similar and use
Package: wnpp
Severity: wishlist
* Package name: zsync
Version : 0.0.4
Upstream Author : Colin Phipps [EMAIL PROTECTED]
* URL : http://zsync.moria.org.uk/
* License : GPLv2
Description : A client-side implementation of the rsync algorithm
This package
On Tuesday 26 October 2004 09.20, Ian Bruce wrote:
Can anyone explain why rsync is no longer considered an appropriate
method for fetching Packages files?
IIRC the problem is that rsync is quite CPU-heavy on the servers, so while
the mirrors have the (network) resources to feed downloads
On Oct 26, Ian Bruce [EMAIL PROTECTED] wrote:
Can anyone explain why rsync is no longer considered an appropriate
method for fetching Packages files? It's the only mechanism I'm aware of
Because it's hard on servers, for a start.
--
ciao, |
Marco | [8782 diFcw3LT7Erlw]
signature.asc
On Thu, Oct 28, 2004 at 01:54:54PM +0200, Adrian 'Dagurashibanipal' von Bidder
wrote:
IIRC the problem is that rsync is quite CPU-heavy on the servers, so
while the mirrors have the (network) resources to feed downloads to
100s of users, they don't have the (CPU) resources for a few dozen
On Tue, Oct 26, 2004 at 12:20:19AM -0700, Ian Bruce said
Now that gzip has the --rsyncable option, wouldn't it be feasible to
rsync against compressed Packages files rather than having to keep the
uncompressed ones around for this purpose?
You have to explicitly enable this option, which
101 - 200 of 341 matches
Mail list logo
