Re: did tar(1) loose xz compression support in 11?

2014-08-27 Thread Warren Block

On Tue, 26 Aug 2014, Daniel Eischen wrote:


On Tue, 26 Aug 2014, Tim Kientzle wrote:


On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote:


Greetings,
I'm currently testing 11. My build / install is from about 2 days ago.
I generally use xz compression, when creating archives. But when I
attempt the following:

tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

it returns the following:

tar: Undefined option: `xz:9'

This has always worked in previous versions. Has the syntax changed,
and the man(1) pages just haven't caught up?


I can?t see any evidence in libarchive?s source that this ever worked.


The man page is a little confusing.  Here it says:

 --options options
 Select optional behaviors for particular modules.  The
 argument is a text string containing comma-separated
 keywords and values. These are passed to the modules that
 handle particular formats to control how those formats will
 behave.  Each option has one of the following forms:

 key=value
 The key will be set to the specified value in every
 module that supports it.  Modules that do not
 support this key will ignore it.


Then below, after the last option, it says:

 ...
 zip:compression=type
 Use type as compression method.  Supported values are
 store (uncompressed) and deflate (gzip algorithm).

 If a provided option is not supported by any module, that is a
 fatal error.

The first states that it is ignored, the latter states that it
is a fatal error.  The meaning of any module is subtle, at
least for my feeble brain ;-)


It suggests that options are passed to all modules, and each module is 
free to ignore options it does not understand.  But at least one module 
must understand the option, or a fatal error is reported.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-27 Thread Chris H

 On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote:

 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:

 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

 it returns the following:

 tar: Undefined option: `xz:9'

 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

 I can’t see any evidence in libarchive’s source that this ever worked.

 However, there was some work done recently to improve error reporting from 
 the options
 processor.  It’s quite possible that —options xz:9 used to just be ignored 
 and now it’s
 reporting an error.

 Tim
On a hunch. I performed a similar test.
I added STAGE to the following port. So I'll test here.

# tar -cvJ --options xz:9 -f posadis-xz9.tar.xz ./posadis/
a ./posadis
a ./posadis/files
a ./posadis/pkg-plist
a ./posadis/Makefile
a ./posadis/distinfo
a ./posadis/pkg-descr
a ./posadis/files/patch-Makefile.in
a ./posadis/files/patch-configure.in

# tar -cvJ --options xz:1 -f posadis-xz1.tar.xz ./posadis/
a ./posadis
a ./posadis/files
a ./posadis/pkg-plist
a ./posadis/Makefile
a ./posadis/distinfo
a ./posadis/pkg-descr
a ./posadis/files/patch-Makefile.in
a ./posadis/files/patch-configure.in

unlike the previous examples, and arguments. I used the v switch.
Presuming that would provide feedback on any anomalous usage.
However. The following proves otherwise:

# ls -la

-rw-r--r--  1 root  wheel  2380 Aug 27 06:47 posadis-xz1.tar.xz
-rw-r--r--  1 root  wheel  2380 Aug 27 06:47 posadis-xz9.tar.xz

(performed on a RELENG_9 box)

As one can see, nothing (compression level(s)) were UNchanged.

So the verdict is in; the _recent_ changes provide the needed
feedback where anomalous usage is concerned.
Short version; tar now works correctly -- it's fixed. :)

Humble opinion; the man(1) pages could be somewhat more concise.

Humble request; would it be possible to make [bsd]tar(1) honor
the short-hand version of options?

Thank you, Tim, and everyone else, for all your thoughtful replies.

--Chris


 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: did tar(1) loose xz compression support in 11?

2014-08-27 Thread Daniel Eischen

On Wed, 27 Aug 2014, Warren Block wrote:


On Tue, 26 Aug 2014, Daniel Eischen wrote:


The man page is a little confusing.  Here it says:

 --options options
 Select optional behaviors for particular modules.  The
 argument is a text string containing comma-separated
 keywords and values. These are passed to the modules that
 handle particular formats to control how those formats will
 behave.  Each option has one of the following forms:

 key=value
 The key will be set to the specified value in every
 module that supports it.  Modules that do not
 support this key will ignore it.


Then below, after the last option, it says:

 ...
 zip:compression=type
 Use type as compression method.  Supported values are
 store (uncompressed) and deflate (gzip algorithm).

 If a provided option is not supported by any module, that is a
 fatal error.

The first states that it is ignored, the latter states that it
is a fatal error.  The meaning of any module is subtle, at
least for my feeble brain ;-)


It suggests that options are passed to all modules, and each module is free 
to ignore options it does not understand.  But at least one module must 
understand the option, or a fatal error is reported.


Yes, I got that, but it is confusing when you are intentionally
passing to only one module, as in the original post, xz:9,
and considering that the fatal error and ignore it parts
are listed in separate sections.  Regardless, tar(1) has many
options, so a little confusion is not unsurprising :-)

--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Peter Wemm
On 8/26/14 11:05 AM, Chris H wrote:
 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:
 
 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
 
 it returns the following:
 
 tar: Undefined option: `xz:9'
 
 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

I use:
tar -cJ --options xz:compression-level=1
.. on head. Are you using the right syntax?

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV



signature.asc
Description: OpenPGP digital signature


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Chris H
 On 8/26/14 11:05 AM, Chris H wrote:
 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:

 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

 it returns the following:

 tar: Undefined option: `xz:9'

 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

 I use:
 tar -cJ --options xz:compression-level=1
 .. on head. Are you using the right syntax?
Apparently not. Using your example works as expected.
RELENG_8, and RELENG_9 use short-hand;
tar -cvJ --options xz:9

Why/when the change to long-hand? Seems a shame. Now I
get to modify all my scripts, and such. :P Altho I
don't suppose it'd be a big deal to back out (revert) the
changes made to tar(1). :)

Thank you, very much, Peter. For taking the time to respond.

--Chris


 --
 Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Lowell Gilbert
Chris H bsd-li...@bsdforge.com writes:

 On 8/26/14 11:05 AM, Chris H wrote:
 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:

 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

 it returns the following:

 tar: Undefined option: `xz:9'

 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

 I use:
 tar -cJ --options xz:compression-level=1
 .. on head. Are you using the right syntax?
 Apparently not. Using your example works as expected.
 RELENG_8, and RELENG_9 use short-hand;
 tar -cvJ --options xz:9

 Why/when the change to long-hand? Seems a shame. Now I
 get to modify all my scripts, and such. :P Altho I
 don't suppose it'd be a big deal to back out (revert) the
 changes made to tar(1). :)

I can't find any changes that would make the syntax change.  At least,
not in quite a long while.  Therefore, this change may not be
intentional. However, I looked at the the manual page from 9.3, and its
description of the features looks the same as on the latest HEAD, and
*doesn't* look like leaving out a key (in this case,
compression-level) is ever compliant.

You might try the latest (or older) libarchive from the ports, and
compare its behaviour. Also, there are a number (amusingly many, in
fact) of other ways of specifying these parameters that may be more
convenient for you, so another look throught the tar(1) manual might
save you a few minutes.

Good luck.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Garrett Cooper
On Tue, Aug 26, 2014 at 1:23 PM, Lowell Gilbert
freebsd-current-lo...@be-well.ilk.org wrote:
 Chris H bsd-li...@bsdforge.com writes:

 On 8/26/14 11:05 AM, Chris H wrote:
 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:

 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

 it returns the following:

 tar: Undefined option: `xz:9'

 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

 I use:
 tar -cJ --options xz:compression-level=1
 .. on head. Are you using the right syntax?
 Apparently not. Using your example works as expected.
 RELENG_8, and RELENG_9 use short-hand;
 tar -cvJ --options xz:9

 Why/when the change to long-hand? Seems a shame. Now I
 get to modify all my scripts, and such. :P Altho I
 don't suppose it'd be a big deal to back out (revert) the
 changes made to tar(1). :)

 I can't find any changes that would make the syntax change.  At least,
 not in quite a long while.  Therefore, this change may not be
 intentional. However, I looked at the the manual page from 9.3, and its
 description of the features looks the same as on the latest HEAD, and
 *doesn't* look like leaving out a key (in this case,
 compression-level) is ever compliant.

 You might try the latest (or older) libarchive from the ports, and
 compare its behaviour. Also, there are a number (amusingly many, in
 fact) of other ways of specifying these parameters that may be more
 convenient for you, so another look throught the tar(1) manual might
 save you a few minutes.

 Good luck.

I've CCed kientzle@ for input.
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Chris H
 Chris H bsd-li...@bsdforge.com writes:

 On 8/26/14 11:05 AM, Chris H wrote:
 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:

 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

 it returns the following:

 tar: Undefined option: `xz:9'

 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

 I use:
 tar -cJ --options xz:compression-level=1
 .. on head. Are you using the right syntax?
 Apparently not. Using your example works as expected.
 RELENG_8, and RELENG_9 use short-hand;
 tar -cvJ --options xz:9

 Why/when the change to long-hand? Seems a shame. Now I
 get to modify all my scripts, and such. :P Altho I
 don't suppose it'd be a big deal to back out (revert) the
 changes made to tar(1). :)

 I can't find any changes that would make the syntax change.  At least,
 not in quite a long while.  Therefore, this change may not be
 intentional. However, I looked at the the manual page from 9.3, and its
 description of the features looks the same as on the latest HEAD, and
 *doesn't* look like leaving out a key (in this case,
 compression-level) is ever compliant.

 You might try the latest (or older) libarchive from the ports, and
 compare its behaviour. Also, there are a number (amusingly many, in
 fact) of other ways of specifying these parameters that may be more
 convenient for you, so another look throught the tar(1) manual might
 save you a few minutes.
Thank you, Lowell. For your extremely informative reply.
Curious. The man page I read from my freshly built 11-CURRENT indicates
the following:

xz:compression-level
 A decimal integer from 0 to 9 specifying the xz compres-
 sion level.

As I have always read that (interpreted it). It meant:
xz:decimal-number (0-9)
Which is what I've always used. I haven't grepped ports||src
yet. But if it makes any difference, it came from src -- build/install
world.
I'll do some poking around. But all my other boxes (RELENG_8  RELENG_9)
use xz:decimal-number.

Thanks again, Lowell. For taking the time to respond. Greatly appreciated.

--Chris


 Good luck.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread John-Mark Gurney
Chris H wrote this message on Tue, Aug 26, 2014 at 16:32 -0700:
  Chris H bsd-li...@bsdforge.com writes:
 
  On 8/26/14 11:05 AM, Chris H wrote:
  Greetings,
  I'm currently testing 11. My build / install is from about 2 days ago.
  I generally use xz compression, when creating archives. But when I
  attempt the following:
 
  tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
 
  it returns the following:
 
  tar: Undefined option: `xz:9'
 
  This has always worked in previous versions. Has the syntax changed,
  and the man(1) pages just haven't caught up?
 
  I use:
  tar -cJ --options xz:compression-level=1
  .. on head. Are you using the right syntax?
  Apparently not. Using your example works as expected.
  RELENG_8, and RELENG_9 use short-hand;
  tar -cvJ --options xz:9
 
  Why/when the change to long-hand? Seems a shame. Now I
  get to modify all my scripts, and such. :P Altho I
  don't suppose it'd be a big deal to back out (revert) the
  changes made to tar(1). :)
 
  I can't find any changes that would make the syntax change.  At least,
  not in quite a long while.  Therefore, this change may not be
  intentional. However, I looked at the the manual page from 9.3, and its
  description of the features looks the same as on the latest HEAD, and
  *doesn't* look like leaving out a key (in this case,
  compression-level) is ever compliant.
 
  You might try the latest (or older) libarchive from the ports, and
  compare its behaviour. Also, there are a number (amusingly many, in
  fact) of other ways of specifying these parameters that may be more
  convenient for you, so another look throught the tar(1) manual might
  save you a few minutes.
 Thank you, Lowell. For your extremely informative reply.
 Curious. The man page I read from my freshly built 11-CURRENT indicates
 the following:
 
 xz:compression-level
  A decimal integer from 0 to 9 specifying the xz compres-
  sion level.
 
 As I have always read that (interpreted it). It meant:
 xz:decimal-number (0-9)
 Which is what I've always used. I haven't grepped ports||src
 yet. But if it makes any difference, it came from src -- build/install
 world.
 I'll do some poking around. But all my other boxes (RELENG_8  RELENG_9)
 use xz:decimal-number.
 
 Thanks again, Lowell. For taking the time to respond. Greatly appreciated.

Could it be that previous versions were ignoring the option and not
giving you an error?

It looks like that was the case on my 9.1-PR box:
$tar -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:33 test.txz
$tar --options xz:9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:33 test.txz
$tar --options xz:1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:33 test.txz
$tar --options xz:compression-level=1 -cJf test.txz *.patch *.c testcrypt *.h; 
ls -l test.txz
-rw---  1 jmg  wheel  41772 Aug 26 17:34 test.txz
$tar --options xz:compression-level=9 -cJf test.txz *.patch *.c testcrypt *.h; 
ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:34 test.txz

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Tim Kientzle

On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote:

 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:
 
 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
 
 it returns the following:
 
 tar: Undefined option: `xz:9'
 
 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

I can’t see any evidence in libarchive’s source that this ever worked.

However, there was some work done recently to improve error reporting from the 
options processor.  It’s quite possible that —options xz:9 used to just be 
ignored and now it’s reporting an error.

Tim

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Daniel Eischen

On Tue, 26 Aug 2014, Tim Kientzle wrote:


On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote:


Greetings,
I'm currently testing 11. My build / install is from about 2 days ago.
I generally use xz compression, when creating archives. But when I
attempt the following:

tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

it returns the following:

tar: Undefined option: `xz:9'

This has always worked in previous versions. Has the syntax changed,
and the man(1) pages just haven't caught up?


I can’t see any evidence in libarchive’s source that this ever worked.


The man page is a little confusing.  Here it says:

  --options options
  Select optional behaviors for particular modules.  The
  argument is a text string containing comma-separated
  keywords and values. These are passed to the modules that
  handle particular formats to control how those formats will
  behave.  Each option has one of the following forms:

  key=value
  The key will be set to the specified value in every
  module that supports it.  Modules that do not
  support this key will ignore it.


Then below, after the last option, it says:

  ...
  zip:compression=type
  Use type as compression method.  Supported values are
  store (uncompressed) and deflate (gzip algorithm).

  If a provided option is not supported by any module, that is a
  fatal error.

The first states that it is ignored, the latter states that it
is a fatal error.  The meaning of any module is subtle, at
least for my feeble brain ;-)

Also, the syntax for [lr]zip:compression=type is very clear,
whereas the syntax for compression-level keys omit the =value.

--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org