A very minor point
# make fetchindex
/usr/ports/INDEX-10.bz2 100% of 1621 kB 208 kBps
# ls -al INDEX-10
-rw-r--r-- 1 root wheel 26284787 Jul 7 20:08 INDEX-10
# xz INDEX-10
# ls -al INDEX-10.xz
-rw-r--r-- 1 root wheel 1350156 Jul 7 20:08 INDEX-10.xz
#
So xz
On Jul 7, 2012 8:19 PM, Anton Shterenlikht me...@bristol.ac.uk wrote:
A very minor point
# make fetchindex
/usr/ports/INDEX-10.bz2 100% of 1621 kB 208 kBps
# ls -al INDEX-10
-rw-r--r-- 1 root wheel 26284787 Jul 7 20:08 INDEX-10
# xz INDEX-10
# ls -al INDEX-10.xz
-10
# xz INDEX-10
# ls -al INDEX-10.xz
-rw-r--r-- 1 root wheel 1350156 Jul 7 20:08 INDEX-10.xz
#
So xz saves ~19% compared to bz2 for this file.
Now that xz is in the base,
perhaps making INDEX available compressed
with xz would help some people who are still
on slow download lines
archivers/xz is mark IGNORE because xz is now in the base system (8.2)
Numerous other ports won't build because they believe they depend on xz (or
on a port that depends on xz)
I'd like to remove the dependencies on xz from the pkgs database.
pkgdb -s /xz-5.0.0// won't work as the slash
On Fri, 2011-09-16 at 02:45 -0500, Lars Eighner wrote:
archivers/xz is mark IGNORE because xz is now in the base system (8.2)
Numerous other ports won't build because they believe they depend on xz (or
on a port that depends on xz)
I'd like to remove the dependencies on xz from the pkgs
Op 28-02-2011 23:31, ajtiM schreef:
Hi!
Today I tried to run portmaster -ad on FreeBSD 8.2 and I got:
portmaster -ad
=== Gathering distinfo list for installed ports
=== Starting check of installed ports for available updates
=== Launching child to update xz-5.0.0 to xz-5.0.1
=== Port
Thank you.
BTW: this problem exist more than one year.
Sent from my HTC Inspire™ 4G on ATT
- Reply message -
From: Rene Ladan r.c.la...@gmail.com
To: ajtiM lum...@gmail.com
Cc: freebsd-ports@freebsd.org
Subject: xz
Date: Mon, Feb 28, 2011 16:46
Op 28-02-2011 23:31, ajtiM schreef:
Hi
On Mon, Feb 28, 2011 at 04:31:27PM -0600, ajtiM wrote:
Than If I run:
portmaster -e xz-5.0.0
=== Warning: Ports with dependencies on xz-5.0.0:
k9copy-2.3.4_4
kde4-4.5.5_1
kdebase-4.5.5
kdenetwork-4.5.5_2
kdesdk-4.5.5_1
kdeutils-4.5.5_2
that is already in place.
We are running out of diskspace on event the FTP master site -
currently we are at ~1TB. The xz compression gives as significant
space saving - so there is already a need.
PS. anyone saying a 1 TB etc. disk is cheap will be ignored.
And all ftp mirror admins
over bzip2 if we
limit compression memory to 512 MB so that decompression would be
possible with, say, 128 MB?
According to xz(1), in its default mode (-6), xz uses ~100MiB for
compression and ~10MiB for decompression.
That seems to be acceptable.
You possibly miss something about
The biggest package that can be produced by a port it's a bit over 10G.
Curious - which one?
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
Eitan Adler writes:
The biggest package that can be produced by a port it's a bit over 10G.
Curious - which one?
OpenOffice(-3)?
Robert Huff
___
freebsd-ports@freebsd.org mailing list
On Sun, 5 Dec 2010 11:41:29 -0500
Eitan Adler li...@eitanadler.com wrote:
Curious - which one?
OpenOffice(-3)?
He told me on IRC - something in games/
$grep -R NO_PACKAGE /usr/ports/games :-)
Hum, looks like either they got smaller or QAT doesn't have all the
games packages
route. Packages that large will benefit from
maximum xz compression most. The question clearly is Would we like to
ditch maximum compression for those huge ones taking care of the
hardware that would never be ready to run them?
Don't listen to me anyway. Our first goal is clearly making FreeBSD
master site - currently we are
at ~1TB. The xz compression gives as significant space saving - so there is
already a need.
PS. anyone saying a 1 TB etc. disk is cheap will be ignored.
--
Simon L. B. Nielsen
___
freebsd-ports@freebsd.org mailing list
be possible with, say, 128 MB?
According to xz(1), in its default mode (-6), xz uses ~100MiB for
compression and ~10MiB for decompression.
That seems to be acceptable.
You possibly miss something about compression/decompression.
The designated memory size is not directly affected only by compression
Ion-Mihai Tetcu ite...@freebsd.org wrote:
It would be nice to support xz(1) compression for large selective
packages like firefox or openoffice as those will never run on
smaller systems.
Trouble is it ain't no way (CPU, space, banhdwidth on our side and
space,bandwidth on our mirrors
Am 28.11.2010 22:12, schrieb Goran Tal:
Now that the base system supports xz compression, it should be used as
the default compression for packages.
Files compressed with xz are smaller and decompress faster than those
compressed with bzip2. This can make an installation much quicker
On 11/29/2010 06:24, Matthias Andree wrote:
Am 28.11.2010 22:12, schrieb Goran Tal:
Now that the base system supports xz compression, it should be used as
the default compression for packages.
Files compressed with xz are smaller and decompress faster than those
compressed with bzip2
On Mon, 29 Nov 2010 13:31:10 -0500
jhell jh...@dataix.net wrote:
On 11/29/2010 06:24, Matthias Andree wrote:
Am 28.11.2010 22:12, schrieb Goran Tal:
Now that the base system supports xz compression, it should be
used as the default compression for packages.
Files compressed with xz
the question is should we do that
so that hosts with N MB of RAM can decompress packages? Do we retain the
compression ratio over bzip2 if we limit compression memory to 512 MB so that
decompression would be possible with, say, 128 MB?
It would be nice to support xz(1) compression for large selective
On Tue, Nov 30, 2010 at 12:40:33AM +0100, Matthias Andree wrote:
Yes, would be nice. I doubt it will happen soon.
It's actually being looked at.
As part of the extensive rework of the pointyhat scripts I did this
summer, I attempted to factor out all the magic constants, including
the
by default just sticking with bzip2(1).
Besides, limiting memory to 512MB to what ? shave an ~ small percentage
off the top of a resulting package.
It would be nice to support xz(1) compression for large selective
packages like firefox or openoffice as those will never run on smaller
systems
be possible with, say, 128 MB?
According to xz(1), in its default mode (-6), xz uses ~100MiB for
compression and ~10MiB for decompression.
That seems to be acceptable.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
Now that the base system supports xz compression, it should be used as
the default compression for packages.
Files compressed with xz are smaller and decompress faster than those
compressed with bzip2. This can make an installation much quicker,
especially when the complete system is installed
Hello,
On 28/11/2010 22:12, Goran Tal wrote:
Now that the base system supports xz compression, it should be used as
the default compression for packages.
Files compressed with xz are smaller and decompress faster than those
compressed with bzip2. This can make an installation much quicker
On Sun, 28 Nov 2010 16:12:48 -0500
Goran Tal goran@gmail.com wrote:
Now that the base system supports xz compression, it should be used as
the default compression for packages.
Files compressed with xz are smaller and decompress faster than those
compressed with bzip2. This can make
Kurt Jaeger li...@opsec.eu wrote:
Hi!
why is archivers/xz marked as IGNORE?
pkg_delete: package 'xz-4.999.9_1' is required by these other packages
and may not be deinstalled:
gtar-1.23_2
kdeutils-3.5.10_6
Because it became part of the base system with 8.1.
Ah, how can I
Hi,
On Fri, 27 Aug 2010 19:16:15 +0200
Heino Tiedemann rotkaps_spam_t...@gmx.de said:
rotkaps Kurt Jaeger li...@opsec.eu wrote:
Hi!
why is archivers/xz marked as IGNORE?
pkg_delete: package 'xz-4.999.9_1' is required by these other packages
and may not be deinstalled:
gtar
On 08/27/2010 07:21 AM, Heino Tiedemann wrote:
Hi,
why is archivers/xz marked as IGNORE?
To fix up your system without rebuilding everything you could use
ports-mgmt/portmaster:
portmaster -d -e xz
portmaster --check-depends
When running the 2nd command when it tells you that xz is listed
Am 12.08.2010, 15:11 Uhr, schrieb Matthias Andree:
Warren Block wrote on 2010-08-01:
xz(1) has a built-in protective notion about limiting memory usage that
prevents port building on relatively low-memory computers. Users have
experienced this in the wild[1].
Matthias Andree pointed out
Warren Block wrote on 2010-08-01:
xz(1) has a built-in protective notion about limiting memory usage that
prevents port building on relatively low-memory computers. Users have
experienced this in the wild[1].
Matthias Andree pointed out[2] that there are existing ways to limit
memory
xz(1) has a built-in protective notion about limiting memory usage that
prevents port building on relatively low-memory computers. Users have
experienced this in the wild[1].
Matthias Andree pointed out[2] that there are existing ways to limit
memory usage: They can use ulimit(1
.tar.xz.
= SHA256 Checksum OK for libpng-1.4.1.tar.xz.
/usr/bin/xz: /usr/ports/distfiles//libpng-1.4.1.tar.xz: Compressed data is
corrupt
=== Patching for png-1.4.1_1
=== Applying FreeBSD patches for png-1.4.1_1
patch: can't cd to /usr/ports/graphics/png/work/libpng-1.4.1: No such
file or directory
for png-1.4.1_1
=== Extracting for png-1.4.1_1
= MD5 Checksum OK for libpng-1.4.1.tar.xz.
= SHA256 Checksum OK for libpng-1.4.1.tar.xz.
/usr/bin/xz: /usr/ports/distfiles//libpng-1.4.1.tar.xz: Compressed data is
corrupt
=== Patching for png-1.4.1_1
=== Applying FreeBSD patches for png
(This goes to all the maintainers of ports with an archivers/xz
dependency.)
The xz utils and lzma library have been imported into base for
9.0-CURRENT and 8.0-STABLE. The patch below makes the dependency
on the archivers/xz port conditional on OSVERSION.
I have not bumped PORTREVISION
On Wed, 19 May 2010 19:42:44 +0200, Christian Weisgerber wrote:
(This goes to all the maintainers of ports with an archivers/xz
dependency.)
The xz utils and lzma library have been imported into base for
9.0-CURRENT and 8.0-STABLE. The patch below makes the dependency
on the archivers/xz
Max Brazhnikov m...@issp.ac.ru wrote:
On Wed, 19 May 2010 19:42:44 +0200, Christian Weisgerber wrote:
(This goes to all the maintainers of ports with an archivers/xz
dependency.)
The xz utils and lzma library have been imported into base for
9.0-CURRENT and 8.0-STABLE. The patch below
Christian Weisgerber wrote:
(This goes to all the maintainers of ports with an archivers/xz
dependency.)
The xz utils and lzma library have been imported into base for
9.0-CURRENT and 8.0-STABLE. The patch below makes the dependency
on the archivers/xz port conditional on OSVERSION.
I
39 matches
Mail list logo
