I dual boot Slackware 12.1 with Slackware 13.37 on my "perfect" laptop, but still spend most of my time in 12.1 and still love it.

Today I needed to open a tar.xz archive and suddenly realized that I can't do that under 12.1.

I looked for xz utils for 12.1 on SBo but did not see anything. It looks like tar > 1.22 includes xz so I think that upgrading tar looks like the way to go (12.1 has 1.16) - but I recall that the Slackware package tools rely on some quirk of the older tar and am unsure whether I might break something that way.

Has anyone done this, or have other suggestion?

You can see the SlackBuild for -current here. You should be able to modify that for use with 1.22 or just use 1.26; note the packaging of tar-1.13 alongside the modern tar. Of course you'll need tar 1.13 as well, which is available in the source directory. It might be a good idea to backup /bin/tar-1.13 just in case the upgrade goes horribly wrong. If it does, you can put tar-1.13 back into /bin and pkgtools should still work. It would probably be easier to just install xz and use `unxz` to unzip the file and then tar to extract the newly generated uncompressed tarball.

1 members found this post helpful.

Thanks T3slider.

I had not realized (or forgotten) that tar-1.13 was packaged alongside my own tar-1.16, so good refresher!

I just grabbed everything frrom -current and a non-xz tarball of tar and will try to build it all later tonight.

********** UPDATE ***************

I went ahead and built without any problems.

I will need to defer installation until later when I can test and verify without distractions.

It installed and works fine - but it still requires xz as an external program. What the newer tar seems to include is the option to support xz, but not xz functionality itself.

From what I had read I thought that tar >1.22 itself included the xz support - apparently not.

So, I have a newer tar now, but still no xz. I'll look further...

OK this was easy...

I have a 13.37 mirror on my local network as PXE source, so I grabbed the source/a/xz/ directory including Slackbuild and source for xz.

Built and installed (using my new tar-1.26 package) and opened my tar.xz archive.

So based on this limited test, for Slackware 12.1 users - you CAN safely upgrade tar using a modified -current Slackbuild and a non-xz tar source archive, and you can build a working xz utils package from the 13.37 source and Slackbuild without other dependencies!

Thanks again T3slider.

FWIW, you didn't need to upgrade your tar at all. Only compile and install xz-utils. Even with your older tar you still could have opened xz compressed tarballs using a pipe as follows:

And created new archives like so:
Alternatively if those methods would not be memorable to you, these would also have worked:

Extraction:
Creation:

HAHA! Yes, I see that now.

I did not find an SBo script for xz and along the way read that tar >1.22 includes xz and decided that was the way to go, hence my path through tar. That was not correct, or I mis-understood, and needed xz anyway - which was easy enough.

But in the end I have an updated tar, plus a new xz, and all I have to remember is '-J', or let tar figure it out for me! Simplicity is increasingly important as I pass through the golden years (golden-brown as in "toast"!).

Thanks!

You don't need '-J' except for where tar can't read the file name (e.g. it is receiving the archive through a pipe). For decompression, you can usually leave it out. For compression using '-a' instead (a.k.a. --auto-compress) and it will pick the compressor based on extension of the archive you are creating.

That is what I meant about letting tar figure it out for me.

Oddly enough, I think that tar was the third *nix command that I learned on my first exposure in the early/mid nineties, right after 'cd' and 'ls'. Even then I was a little overwhelmed by the number of options it offered.

Now it has become one of those things that I use all day, every day but rarely think much about. I consult the manual regularly to craft my use du jour, but nothing much sticks beyond -c/x/t/z/j/v/f combinations. I pipe through gzip and even use cpio on occasion, and rarely have any surprizes.

But earlier when I typed tar -xvzf ...xz and it balked, it was such a shock I didn't know where to start! It took me a minute or two just to realize that it was 'xz' and not 'gz'... then the adventure began!

But as of now, the world is spinning normally once more!

As a side note, if some wants just the decompresser I host some self-contained (statically linked against liblzma) xzdec binaries on one of the websites owned by my employer. You can get them from here: http://snapshot.opera.com/unix/xzdec/. I made these to help Opera users of our public development snapshots. Some users need them because we only offer XZ compressed tarballs of Opera Next and older distros don't always have XZ Utils available, as you found.

The binaries were compiled on Ubuntu 6.06 LTS (Dapper Drake) LiveCDs with the following configure options: --disable-shared --disable-nls --disable-encoders --enable-small --disable-threads --disable-lzmainfo --disable-scripts --disable-xz --disable-lzma-links. Then I stripped them before packaging them up to share. So far they have worked for every user who has tried them. I haven't specifically tested Slackware 12.1 but since Dapper pre-dates it by about 2 years, I reckon they should work there are well.

P.S. There is a little more information on the blog post I wrote about XZ compressed Opera development snapshots.

Hi, I recently had this same problem but with Slack12 where you cannot use package from 13.37 because of glibc version.
So, I complied latest source of XZ then...
I probably should have linked rest of libs from /usr/local/lib/ but since system does not complain I just skipped that.
Works pretty good. Hope that helps to someone.

@czezz: You could do that but it is much nicer to have a package, so I would suggest using the SlackBuild to create one, in three easy steps:

Fetch the latest XZ-Utils Slackbuild:

Build and package XZ-Utils:

Install XZ-Utils:

If you just want to be able to decompress and don't care about packaging you could build only xzdec and stick it in /usr/local/bin, e.g.: