Re: svn commit: r264027 - in head: release share/man/man7
On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso: 64% smaller disc1.iso: 44% smaller memstick.img: 47% smaller mini-memstick.img: 65% smaller dvd1.iso: untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). -- Brooks pgp0mmVjzYrzl.pgp Description: PGP signature
Re: svn commit: r264027 - in head: release share/man/man7
On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen pgpmrZ1ZRBE_B.pgp Description: PGP signature
Re: svn commit: r264027 - in head: release share/man/man7
On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r264027 - in head: release share/man/man7
On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso: 64% smaller disc1.iso: 44% smaller memstick.img: 47% smaller mini-memstick.img: 65% smaller dvd1.iso: untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen pgpPSHFHxMMfx.pgp Description: PGP signature
Re: svn commit: r264027 - in head: release share/man/man7
On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso: 64% smaller disc1.iso: 44% smaller memstick.img: 47% smaller mini-memstick.img: 65% smaller dvd1.iso: untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r264027 - in head: release share/man/man7
On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote: On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. Great, thank you for confirming. So, the question I have now is, considering the time it takes to compress the image with xz(1) compared to gzip(1), is that worth saving the 50MB space? I do not object to using xz(1), but the compression time difference was quite significant. (I do not have numbers off-hand, but can run the compression again.) Glen pgpnN8Z30xeqC.pgp Description: PGP signature
Re: svn commit: r264027 - in head: release share/man/man7
On 04/02/14 12:33, Glen Barber wrote: On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote: On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. Great, thank you for confirming. So, the question I have now is, considering the time it takes to compress the image with xz(1) compared to gzip(1), is that worth saving the 50MB space? I do not object to using xz(1), but the compression time difference was quite significant. (I do not have numbers off-hand, but can run the compression again.) Glen Compression is much more expensive. There are different levels too, so xz -9e my16Gfile.img on a 4 core i7 can take up to 8 hours. Other levels are cheaper. De-compression (for the end user) is as cheap or cheaper than gzip. Depending on the chosen compression level, the minimum amount of RAM required for decompression can also grow. The xz(1) explains these properties. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r264027 - in head: release share/man/man7
On Wed, Apr 02, 2014 at 12:33:50PM -0400, Glen Barber wrote: On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote: On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso: 64% smaller disc1.iso: 44% smaller memstick.img: 47% smaller mini-memstick.img: 65% smaller dvd1.iso: untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. Great, thank you for confirming. So, the question I have now is, considering the time it takes to compress the image with xz(1) compared to gzip(1), is that worth saving the 50MB space? I do not object to using xz(1), but the compression time difference was quite significant. (I do not have numbers off-hand, but can run the compression again.) xz is quite slow, but who cares if it's something we do once for the benefit of many. One thing I did do in my build system is use pxz from ports. It speeds things up quite a bit on many-core machines with lots of ram. -- Brooks pgpijffHYnDoG.pgp Description: PGP signature
Re: svn commit: r264027 - in head: release share/man/man7
On Wed, Apr 02, 2014 at 11:41:29AM -0500, Brooks Davis wrote: On Wed, Apr 02, 2014 at 12:33:50PM -0400, Glen Barber wrote: On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote: On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. Great, thank you for confirming. So, the question I have now is, considering the time it takes to compress the image with xz(1) compared to gzip(1), is that worth saving the 50MB space? I do not object to using xz(1), but the compression time difference was quite significant. (I do not have numbers off-hand, but can run the compression again.) xz is quite slow, but who cares if it's something we do once for the benefit of many. One thing I did do in my build system is use pxz from ports. It speeds things up quite a bit on many-core machines with lots of ram. Based on the feedback received on this, I think it's clear that xz(1) is the better choice, so I'll make the relevant changes shortly. I was more worried about Windows users needing to go through pain to decompress the images, which seems like a non-issue now. Thanks Brooks and Nikolai for the input. Glen pgpJ0NTPIPdJm.pgp Description: PGP signature
Re: svn commit: r264027 - in head: release share/man/man7
On 2014-04-02 11:23, Nikolai Lifanov wrote: On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. - Nikolai Lifanov My concern was requiring a *specific* tool to extract the ISO. However I do see that Winzip and Winrar both now support XZ as well. -- Regards, Bryan Drewery ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r264027 - in head: release share/man/man7
On Wed, Apr 02, 2014 at 11:52:44AM -0500, Bryan Drewery wrote: On 2014-04-02 11:23, Nikolai Lifanov wrote: On 04/02/14 12:06, Glen Barber wrote: On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: On 04/02/14 11:51, Glen Barber wrote: On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: Author: gjb Date: Tue Apr 1 22:41:26 2014 New Revision: 264027 URL: http://svnweb.freebsd.org/changeset/base/264027 Log: Add a new release build variable, WITH_COMPRESSED_IMAGES. When set to a non-empty value, the installation medium is compressed with gzip(1) as part of the 'install' target in the release/ directory. With gzip(1) compression, downloadable image are reduced in size quite significantly. Build test against head@263927 shows the following: bootonly.iso:64% smaller disc1.iso: 44% smaller memstick.img:47% smaller mini-memstick.img: 65% smaller dvd1.iso:untested This option is off by default, I would eventually like to turn it on by default, and remove the '-k' flag to gzip(1) so only compressed images are published on FTP. I'd recommend testing xz compression as well. With UFS images of a full world the savings vs gzip are significant (more than 30% IIRC, but it's need more than a year since I checked so I'm a bit unsure of the exact numbers). delphij also brought this up. I have concerns with xz(1), since there was mention in IRC that Windows users may have problems decompressing xz-compressed images. So, gzip(1) is used because it seems to be the more commonly-supported archive mechanisms. The benefit of xz(1) over gzip(1) was only 50M-ish. -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz Glen How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. I don't know, to be honest. I have no Windows machines to test, so I can only go by what I am told. Glen I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. - Nikolai Lifanov My concern was requiring a *specific* tool to extract the ISO. However I do see that Winzip and Winrar both now support XZ as well. Indeed, this was another thing I wanted to avoid too (and meant to include that in the commit message). Glen pgpvdrBj2Zr2M.pgp Description: PGP signature
svn commit: r264027 - in head: release share/man/man7
Author: gjb
Date: Tue Apr 1 22:41:26 2014
New Revision: 264027
URL: http://svnweb.freebsd.org/changeset/base/264027
Log:
Add a new release build variable, WITH_COMPRESSED_IMAGES.
When set to a non-empty value, the installation medium is
compressed with gzip(1) as part of the 'install' target in
the release/ directory.
With gzip(1) compression, downloadable image are reduced in
size quite significantly. Build test against head@263927
shows the following:
bootonly.iso:64% smaller
disc1.iso: 44% smaller
memstick.img:47% smaller
mini-memstick.img: 65% smaller
dvd1.iso:untested
This option is off by default, I would eventually like to
turn it on by default, and remove the '-k' flag to gzip(1)
so only compressed images are published on FTP.
Requested by: wkoszek
MFC After:1 week
Sponsored by: The FreeBSD Foundation
Modified:
head/release/Makefile
head/release/release.conf.sample
head/release/release.sh
head/share/man/man7/release.7
Modified: head/release/Makefile
==
--- head/release/Makefile Tue Apr 1 22:21:56 2014(r264026)
+++ head/release/Makefile Tue Apr 1 22:41:26 2014(r264027)
@@ -21,6 +21,8 @@
# NOSRC:if set, do not distribute source tree
# NODOC:if set, do not generate release documentation
# WITH_DVD: if set, generate dvd1.iso
+# WITH_COMPRESSED_IMAGES: if set, compress installation images with gzip(1)
+# (uncompressed images are not removed)
# TARGET/TARGET_ARCH: architecture of built release
#
@@ -251,6 +253,9 @@ install:
cp -a ftp ${DESTDIR}/
.for I in ${IMAGES}
cp -p ${I} ${DESTDIR}/${OSRELEASE}-${I}
+. if defined(WITH_COMPRESSED_IMAGES) || !empty(WITH_COMPRESSED_IMAGES)
+ gzip -k ${DESTDIR}/${OSRELEASE}-${I}
+. endif
.endfor
cd ${DESTDIR} sha256 ${OSRELEASE}* ${DESTDIR}/CHECKSUM.SHA256
cd ${DESTDIR} md5 ${OSRELEASE}* ${DESTDIR}/CHECKSUM.MD5
Modified: head/release/release.conf.sample
==
--- head/release/release.conf.sampleTue Apr 1 22:21:56 2014
(r264026)
+++ head/release/release.conf.sampleTue Apr 1 22:41:26 2014
(r264027)
@@ -46,6 +46,7 @@ PORTBRANCH=ports/head@rHEAD
#NODOC=
#NOPORTS=
#WITH_DVD=
+#WITH_COMPRESSED_IMAGES=
## Set when building embedded images.
#EMBEDDEDBUILD=
Modified: head/release/release.sh
==
--- head/release/release.sh Tue Apr 1 22:21:56 2014(r264026)
+++ head/release/release.sh Tue Apr 1 22:41:26 2014(r264027)
@@ -83,6 +83,7 @@ NOPORTS=
# Set to non-empty value to build dvd1.iso as part of the release.
WITH_DVD=
+WITH_COMPRESSED_IMAGES=
usage() {
echo Usage: $0 [-c release.conf]
@@ -128,6 +129,7 @@ if [ -n ${EMBEDDEDBUILD} ]; then
exit 1
fi
WITH_DVD=
+ WITH_COMPRESSED_IMAGES=
NODOC=yes
fi
@@ -262,4 +264,4 @@ eval chroot ${CHROOTDIR} make -C /usr/sr
eval chroot ${CHROOTDIR} make -C /usr/src/release ${RELEASE_RMAKEFLAGS} \
release
eval chroot ${CHROOTDIR} make -C /usr/src/release ${RELEASE_RMAKEFLAGS} \
- install DESTDIR=/R
+ install DESTDIR=/R WITH_COMPRESSED_IMAGES=${WITH_COMPRESSED_IMAGES}
Modified: head/share/man/man7/release.7
==
--- head/share/man/man7/release.7 Tue Apr 1 22:21:56 2014
(r264026)
+++ head/share/man/man7/release.7 Tue Apr 1 22:41:26 2014
(r264027)
@@ -250,6 +250,12 @@ Setting this also sets
Set to a non-empty value to include the
.Cm dvdrom
target.
+.It Va WITH_COMPRESSED_IMAGES
+Set to a non-empty value to compress the release images with
+.Xr gzip 1 .
+The original
+.Pq uncompressed
+images are not removed.
.It Va VCSCMD
The command run to obtain the source trees.
Defaults to
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
