Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Jun 2014 09:07:56 +0200
From:      Matthias Andree <matthias.andree@gmx.de>
To:        Gea-Suan Lin <gslin@gslin.org>,freebsd-ports@freebsd.org
Subject:   Re: Drop maintainership for all ports maintained by gslin@gslin.org
Message-ID:  <c67a8399-ee8a-4392-9fc7-b0bc20ddd719@email.android.com>
In-Reply-To: <20140630023714.GA32083@gslin.org>
References:  <20140630023714.GA32083@gslin.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 30=2E Juni 2014 04:37:14 MESZ, Gea-Suan Lin <gslin@gslin=2Eorg> wrote:
>Hello sir,
>
>I would like to drop all ports maintainship, please reset to ports@
>and perl@ (or other alias)=2E
>
>Thanks,
>
>--=20
>                                                Resistance is futile=2E
>                           http://blog=2Egslin=2Eorg/ & <gslin@gslin=2Eor=
g>
>_______________________________________________
>freebsd-ports@freebsd=2Eorg mailing list
>http://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to
>"freebsd-ports-unsubscribe@freebsd=2Eorg"

I will grab the databases/db* ports later=2E
From owner-freebsd-ports@FreeBSD.ORG  Mon Jun 30 07:51:20 2014
Return-Path: <owner-freebsd-ports@FreeBSD.ORG>
Delivered-To: ports@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 35E04E5A;
 Mon, 30 Jun 2014 07:51:20 +0000 (UTC)
Received: from critical.ch (critical.ch [IPv6:2a01:4f8:100:936f::1:1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id D71CE28B3;
 Mon, 30 Jun 2014 07:51:19 +0000 (UTC)
Received: from wiggles.local (27-98.1-85.cust.bluewin.ch [85.1.98.27])
 (authenticated bits=0)
 by critical.ch (8.14.7/8.14.7/critical-1.0) with ESMTP id s5U7pGsF032807;
 Mon, 30 Jun 2014 09:51:17 +0200 (CEST)
 (envelope-from ehaupt@FreeBSD.org)
Date: Mon, 30 Jun 2014 09:51:16 +0200
From: Emanuel Haupt <ehaupt@FreeBSD.org>
To: Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au>
Subject: Re: rsync 3.1.1 zlib might not work
Message-Id: <20140630095116.2900595e7c7667cc6c8af370@FreeBSD.org>
In-Reply-To: <53AE17B4.9020109@heuristicsystems.com.au>
References: <CAHT8kSTAmd16YA8AUE4f44y3XJ5QYy-377v5w31XyVx+pQ0dfw@mail.gmail.com>
 <20140627145527.9d22938908a9f4847ba62388@FreeBSD.org>
 <53AE17B4.9020109@heuristicsystems.com.au>
X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: ports@freebsd.org, Ben Tung <benpptung@tacol.biz>,
 Emanuel Haupt <ehaupt@freebsd.org>
X-BeenThere: freebsd-ports@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-ports>,
 <mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports/>;
List-Post: <mailto:freebsd-ports@freebsd.org>
List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
 <mailto:freebsd-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 07:51:20 -0000

Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> wrote:
> Emanuel,
> Thanks for bringing to our attention, I transmit ~900MB of backups
> over the WAN  rather than the uncompressed 9G database. You've saved
> a client excess use charges.
> 
> I tested using highly compressible data (mostly nulls) and it seems to
> work as expected.
> 
> Without -z or -zz: Sent 593 bytes speadup 0.82
> With -z :  Sent 593 bytes speadup 0.82    (Unexpected.  Should be in
> ports/UPDATING)
> With -zz: sent 85 bytes speedup is 4.27   (Expected)
> 
> Detail
> # rm ./b && printf "%512c"a > a && rsync -av ./a ./b
> sending incremental file list
> a
> 
> sent 593 bytes  received 35 bytes  1,256.00 bytes/sec
> total size is 512  speedup is 0.82
> 
> # rm ./b && printf "%512c"a > a && rsync -avz ./a ./b
> This rsync lacks old-style --compress due to its external zlib.  Try
> -zz. Continuing without compression.
> 
> sending incremental file list
> a
> 
> sent 593 bytes  received 35 bytes  1,256.00 bytes/sec
> total size is 512  speedup is 0.82
> 
> # rm ./b && printf "%512c"a > a && rsync -avzz ./a ./b
> sending incremental file list
> a
> 
> sent 85 bytes  received 35 bytes  240.00 bytes/sec
> total size is 512  speedup is 4.27
> 
> # ldd `which rsync`
> /usr/local/bin/rsync:
>         libz.so.6 => /lib/libz.so.6 (0x800873000)
>         libc.so.7 => /lib/libc.so.7 (0x800a87000)
> 
> Perhaps ports/UPDATING should alert users to the new requirement to
> use -zz (not in man page) instead of -z or --compress?

Indeed there seems to be some sort of confusion on how to use -z vs.
-zz. However there -zz mentioned in the manpage of 3.1.1:


       -z, --compress
              With  this  option, rsync compresses the file data as it is sent
              to the destination machine, which reduces  the  amount  of  data
              being  transmitted  -- something that is useful over a slow con-
              nection.

              Note that this  option  typically  achieves  better  compression
              ratios  than can be achieved by using a compressing remote shell
              or a compressing transport because it  takes  advantage  of  the
              implicit  information  in  the matching data blocks that are not
              explicitly sent over the connection.   This  matching-data  com-
              pression  comes at a cost of CPU, though, and can be disabled by
              repeating the -z option, but only if both  sides  are  at  least
              version 3.1.1.

              Note that if your version of rsync was compiled with an external
              zlib (instead of the zlib that comes packaged with  rsync)  then
              it   will  not  support  the  old-style  compression,  only  the
              new-style (repeated-option) compression.   In  the  future  this
              new-style compression will likely become the default.

              The  client  rsync  requests new-style compression on the server
              via the  --new-compress  option,  so  if  you  see  that  option
              rejected  it  means that the server is not new enough to support
              -zz.  Rsync also accepts the --old-compress option for a  future
              time when new-style compression becomes the default.

              See the --skip-compress option for the default list of file suf-
              fixes that will not be compressed.


This is currently being tracked under:
https://bugzilla.samba.org/show_bug.cgi?id=10677

I'm considering an UPDATED entry after some other issues with the port have
been resolved.

Emanuel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c67a8399-ee8a-4392-9fc7-b0bc20ddd719>