Bug 506339 - Review Request: XZ Utils - LZMA Utils with newer file format
Summary: Review Request: XZ Utils - LZMA Utils with newer file format
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-16 18:40 UTC by Jindrich Novy
Modified: 2013-07-02 23:36 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-17 18:27:12 UTC
Type: ---
Embargoed:
j: fedora-review+
j: fedora-cvs+


Attachments (Terms of Use)

Description Jindrich Novy 2009-06-16 18:40:51 UTC
Spec URL: http://people.redhat.com/jnovy/files/xz/xz.spec
SRPM URL: http://people.redhat.com/jnovy/files/xz/xz-4.999.8beta-0.1.fc11.src.rpm
Description:

XZ Utils are an attempt to make LZMA compression easy to use
on free (as in freedom) operating systems. This is achieved by
providing tools and libraries which are similar to use than the
equivalents of the most popular existing compression algorithms.

LZMA is a general purporse compression algorithm designed by
Igor Pavlov as part of 7-Zip. It provides high compression ratio
while keeping the decompression speed fast.

koji scratch F12 build is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1418681

Review of XZ Utils is a part of:
http://fedoraproject.org/wiki/Features/XZRpmPayloads

Comment 1 Milos Jakubicek 2009-06-16 20:01:21 UTC
We have to decide how this package will work together with the current lzma.
There was already a brief discussion regarding this issue with Ville Skyttä and Joel Granados (cc'ed, input welcome).

I'm pasting an e-mail summary:

"
On Wednesday 10 June 2009, Joel Granados wrote:
> > On Tue, Jun 09, 2009 at 07:37:10PM +0300, Ville Skyttä wrote:
>> > > On Tuesday 09 June 2009, Joel Granados wrote:
>>> > > > Hello Ville.
>> > >
>> > > Hello Joel,
>> > >
>>> > > > I'm Joel and I maintain parted for fedora.  parted upstream started
>>> > > > using XZ for its build tests and it is needed in fedora, at least for
>>> > > > parted.  I asked in #fedora-devel about XZ in fedora and I was told
>>> > > > that you were looking into packaging it.
>>> > > > Do you have a spec file proposal?  How far along are you in the
>>> > > > packaging process? Is there something I can help you with?  Why have
>>> > > > you not posted the package on the review queue?.... I think, in
>>> > > > general, I want to know the status on the packaging effort.
>> > >
>> > > I did put together an initial package of xz, unfortunately without
>> > > realizing
> >
> > Great!!!, saves me the trouble of doing one myself :)
> >
>> > > that it conflicts quite a bit with the current Fedora lzma package. 
>> > > Below is
> >
> > really? Thats not good....  I spoke to the lzma upstream and he told me
> > that it was possible to have the to coexist in a system.  Reading your
> > mail interchange I see that it _is_ a possibility.  I would think this
> > to be the prefered solution so we don't break whatever is using the
> > original lzma command.
I agree that it seems possible.  It will require some changes to the lzma 
package though.

>> > > a copy of a quick mail exchange with the new Fedora lzma maintainer Milos
>> > > Jakubicek (Cc'd) we had in the beginning of May, I haven't heard back nor
>> > > have done anything myself neither to xz or lzma since.
> >
> > I would be interested in getting this in to fedora (having the two
> > coexist)  I'm guessing that the only thing needed is to change the
> > xz.spec file in such a way that, when installed, it does not conflict
> > with LZMA.  You mind if I use your spec file as a starting point for
> > this?  I would think, with my current workload, that I would make it
> > ready for f12 or f13(the latest).  Do you have any plans regarding this
> > package?
Not really, and by all means, please use my specfile if you find it useful, 
that's why I uploaded it in the first place ;)

Here's a breakdown of the conflicts and other compatibility issues between 
lzma and xz:

 Conflicts:
 * /usr/bin/lzcat
 * /usr/bin/lzma
 * /usr/bin/lzmadec
 * /usr/bin/unlzma
 * /usr/share/man/man1/lzdiff.1.gz
 * /usr/share/man/man1/lzgrep.1.gz
 * /usr/share/man/man1/lzmore.1.gz

 Included in lzma, not in xz:
 * /usr/bin/lzmainfo

 Included in lzma-libs, not in xz-libs:
 * liblzmadec.so.*

 Included in lzma-devel, not in xz-devel:
 * lzmadec.h
 * liblzmadec.so

Personally, I would approach this stuff from the POV that eventually xz will 
obsolete lzma altogether.  I think this could be a good way to go (just 
thinking aloud, not actually tested): Ship the xz package as is from my 
specfile, and modify the current Fedora lzma package so that everything else 
except lzmainfo and its man page is removed from the main lzma package, and 
add "Requires: xz" to the main package (leave lzma-libs and lzma-devel as is).

If you are in contact with upstream xz devs, I think it would be good to ask 
why lzmainfo is not included with xz.  If it was, the transition would be 
simpler; the xz main package could just obsolete the lzma main package, and 
the lzma source package could be modified so that the main package would be 
dropped, and only the -libs and -devel subpackages would be shipped.
"

I'll be able to look at this in more detail at weekend.

Comment 2 Ville Skyttä 2009-06-16 22:01:58 UTC
For the record and FWIW, the "my specfile" referred to in comment 1's mail summary is http://scop.fedorapeople.org/packages/xz.spec

Comment 3 Jindrich Novy 2009-06-17 06:47:09 UTC
Milos, thanks for taking the review and posting here the mailing WRT the XZ utils packaging. I see I was not the first one to package XZ :)

The lzma and xz does conflict so better to IMO obsolete the old lzma by xz. I added the obsoletion and provides to the spec. XZ supports old lzma format as well az XZ so there should be no compatibility issues.

Ville, thanks for your spec. It helped me to add the pkgconfig dependency to xz-devel. Another thing is version which is wierd -> 4.999.8beta. Should we move the beta to release as Ville did? This seems to be the last release before the XZ-5 so is that worth the trouble?

I'll ask upstream about the lzmainfo.

BTW. spec and SRPM is now updated.

Comment 4 Ville Skyttä 2009-06-17 16:25:05 UTC
I think obsoleting lzma-libs and lzma-devel is definitely premature, and providing them is wrong and should never happen (obsoletion _only_ without provides when the time is right to drop lzma).  xz-libs does *not* provide the stuff in lzma-libs (liblzmadec) and xz-devel does not IIRC provide the headers and pkgconfig file that lzma-devel does, and we have packages depending on both in the repo, at least libarchive, never mind people's local builds against lzma-libs/-devel.
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages

Yes, "beta" should be in the release tag.
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages

Comment 5 Jindrich Novy 2009-06-17 18:39:51 UTC
Ok, there is another iteration of packages here:
http://people.redhat.com/jnovy/files/xz/

Comment 6 Panu Matilainen 2009-06-18 20:48:45 UTC
Doesn't really fly:
[root@turre rpm]# rpm -Uvh /home/pmatilai/rpmbuild/RPMS/xz-4.999.8-0.3beta.fc11.x86_64.rpm /home/pmatilai/rpmbuild/RPMS/xz-libs-4.999.8-0.3beta.fc11.x86_64.rpm /home/pmatilai/rpmbuild/RPMS/xz-devel-4.999.8-0.3beta.fc11.x86_64.rpm
error: Failed dependencies:
	lzma is needed by (installed) man-1.6f-20.fc11.x86_64
	lzma is needed by (installed) rpm-build-4.7.0.git9198-1.fc11.lorg.x86_64
	liblzmadec.so.0()(64bit) is needed by (installed) libarchive-2.6.2-1.fc11.x86_64

How about we simply leave out the lzma bits from the xz package? Ie dont obsolete or conflict with anything, and only include the actual xz binaries in the main package:
/usr/bin/unxz
/usr/bin/xz
/usr/bin/xzcat
/usr/bin/xzdec

-libs and -devel are not a problem as they dont conflict and those are the only bits that rpm really needs for payload compression, /usr/bin/xz is only useful for supporting xz compressed sources in build, the old stable lzma can be used to provide the /usr/bin/*lz* bits for now.

Comment 7 Jindrich Novy 2009-06-19 11:45:50 UTC
New files are here:

http://people.redhat.com/jnovy/files/xz/

But the problem is that there still are conflicts with lzma after /usr/bin/*lz* removal. Man pages are conflicting. Only the obsolete man pages are shipped. There are actually no man pages remaining after nuking the lzma related ones...

Comment 8 Ville Skyttä 2009-06-21 09:32:31 UTC
Well, an AFAICT complete working solution was already given in comment 1:

"Ship the xz package as is from my 
specfile, and modify the current Fedora lzma package so that everything else 
except lzmainfo and its man page is removed from the main lzma package, and 
add "Requires: xz" to the main package (leave lzma-libs and lzma-devel as is)."

Comment 9 Panu Matilainen 2009-06-22 04:34:00 UTC
Sure, that'd work too, it just
a) requires changes to existing packages to all supported versions
b) replaces functionality of stable lzma with a beta version

The "only the xz bits" variant from comment #7 allows dropping it with minimal fuss. I dont have any strong feelings about it either way though.

Comment 10 Jindrich Novy 2009-06-22 08:20:32 UTC
The best solution seems to be to add lzma-compat package where all the lzma stuff from xz is shipped. It doesn't need any modifications on lzma side. Adding Obsoletes/Provides to the compat package just obsoletes lzma, not lzma-libs or lzma-devel so all dependencies on liblzmadec are kept.

Check out the new packages:
http://people.redhat.com/jnovy/files/xz/xz.spec
http://people.redhat.com/jnovy/files/xz/xz-4.999.8-0.5beta.fc11.src.rpm

Asked upstream about the lzmainfo:
18:33 < jnovy> Larhzu: Hi Lasse, is it intentional that lzmainfo equivalent is missing from xz?
18:35 < Larhzu> jnovy: For now, yes, but there will be "xz --list" like gzip has, and I guess I can add lzmainfo for backward compatibility.

Comment 11 Orcan Ogetbil 2009-06-24 05:33:22 UTC
How about using "alternatives" for lzma stuff? "alternatives" works very well for packages which use it.

I just found this bug. It would have been nice if the lzma maintainer didn't ignore my emails about this subject in the last one and a half months but I'm glad someone started the work.

Jindrich, according to the guidelines there has to be a . between 5 and beta. Also, please make the description span the 80 columns (as much as possible).

Comment 12 Bill Nottingham 2009-06-24 14:29:49 UTC
I don't think alternatives is correct when one package is a superset/(eventual) replacement of the other.

Comment 13 Milos Jakubicek 2009-06-30 21:11:14 UTC
Orcan, I'm really sorry for my late response, but I'm having busy days now (and yes, I must have missed whatever you sent to f-d-l, sorry too).

I'm generally open to any modification to the current lzma package which will help the symbiosis with xz, however, I really like the latest solution from Jindrich (only -debuginfo are conflicting, which I don't find any bad) and if nobody comes up with something we missed as far, I'm going to approve the package in a day or two.

Other minor comments on packaging:

* rpmlint:
>rpmlint ../SRPMS/xz-4.999.8-0.5beta.fc11.src.rpm
xz.src: W: name-repeated-in-summary XZ
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

>rpmlint ../RPMS/x86_64/xz-*
xz-devel.x86_64: W: no-documentation
xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/lzcat xz
xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/unlzma xz
xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/lzma xz
xz.x86_64: W: name-repeated-in-summary XZ

Those are all OK imho.

xz.x86_64: W: incoherent-version-in-changelog 4.999.8beta-0.5 ['4.999.8-0.5beta.fc11', '4.999.8-0.5beta']

Make rpmlint happy here please, together with adding a dot as Orcan pointed out.

* specfile is sane, owns all directories, proper macros
* builds fine in current F11 and rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1444933
* matches upstream sources, sha256sum: 059da5a9fe51c28b38f67e5b8063a451c516f37fbb268177fd1081b70dd97f53
* handles libraries well
* I have some worries regarding licensing because of the comment on upstream's homepage:

"Oops! Accidentally a wrong COPYING file got included in 4.999.8beta. 4.999.8beta is still under GNU LGPL, but the first stable release will be in the public domain like the incorrectly included draft of new COPYING in 4.999.8beta already hints."

Currently it is definitely *not* LGPLv2.1+ (in this case) but I'm also afraid that authors claims about becoming Public domain are not right too.
Hence GPLv2+ seems to be ok to me (now).

Comment 14 Panu Matilainen 2009-07-01 11:30:16 UTC
One possibility would be using a snapshot from the git repo instead of the "official" beta tarball, that would get the licensing straight from the start:

commit 02ddf09bc3079b3e17297729b9e43f14d407b8fc
Author: Lasse Collin <lasse.collin>
Date:   Mon Apr 13 11:27:40 2009 +0300

    Put the interesting parts of XZ Utils into the public domain.
    Some minor documentation cleanups were made at the same time.

In addition to that, there are a few fairly important looking fixes, such as xz crashing when decompressing two files with a single xz command, and identifying some corrupted files as valid.

Comment 16 Ondrej Vasik 2009-07-09 08:22:32 UTC
Jindra is on PTO (3 weeks - so quite a lot of time) so maybe someone else should fix those issues mentioned  in comment #13. I'd like to see xz utils in Fedora too - as otherwise I still have to use 3 times bigger tar.gz tarball for coreutils (so bigger srpm).

Comment 17 Bill Nottingham 2009-07-09 18:32:33 UTC
OK, new files:

http://notting.fedorapeople.org/review/xz.spec
http://notting.fedorapeople.org/review/xz-4.999.8-0.6.beta.fc11.src.rpm

Changes:

--- xz.spec.old	2009-07-09 14:27:13.000000000 -0400
+++ xz.spec	2009-07-09 14:27:36.000000000 -0400
@@ -1,8 +1,8 @@
 Summary:	XZ Utils, LZMA compression utilities
 Name:		xz
 Version:	4.999.8
-Release:	0.5beta%{?dist}
-License:	GPLv2+
+Release:	0.6.beta%{?dist}
+License:	LGPLv2+
 Group:		Applications/File
 Source0:	http://tukaani.org/%{name}/%{name}-%{version}beta.tar.gz
 URL:		http://tukaani.org/%{name}/
@@ -10,14 +10,14 @@
 Requires:	%{name}-libs = %{version}-%{release}
 
 %description
-XZ Utils are an attempt to make LZMA compression easy to use
-on free (as in freedom) operating systems. This is achieved by
-providing tools and libraries which are similar to use than the
-equivalents of the most popular existing compression algorithms.
-
-LZMA is a general purporse compression algorithm designed by
-Igor Pavlov as part of 7-Zip. It provides high compression ratio
-while keeping the decompression speed fast.
+XZ Utils are an attempt to make LZMA compression easy to use on free (as in
+freedom) operating systems. This is achieved by providing tools and libraries
+which are similar to use than the equivalents of the most popular existing
+compression algorithms.
+
+LZMA is a general purporse compression algorithm designed by Igor Pavlov as
+part of 7-Zip. It provides high compression ratio while keeping the
+decompression speed fast.
 
 %package 	libs
 Summary:	Libraries for decoding LZMA compression
@@ -35,18 +35,20 @@
 Requires:	pkgconfig
 
 %description  devel
-Devel libraries & headers for liblzma.
+Devel libraries and headers for liblzma.
 
 %package 	lzma-compat
-Summary:	Devel libraries & headers for liblzma
+Summary:	Older LZMA format compatibility binaries
 Group:		Development/Libraries
-License:	LGPLv2+
+# lz{grep,diff,more} are GPLv2+. Other binaries are LGPLv2+
+License:	GPLv2+ and LGPLv2+
 Requires:	%{name} = %{version}-%{release}
 Obsoletes:	lzma < 5
 Provides:	lzma = 5
 
 %description  lzma-compat
-Compatibility files for lzma.
+The lzma-compat package contains compatibility links for older
+commands that deal with the older LZMA format.
 
 %prep
 %setup -q  -n %{name}-%{version}beta
@@ -97,6 +99,11 @@
 %{_mandir}/man1/*
 
 %changelog
+* Thu Jul 09 2009 Bill Nottingham <notting> 4.9999.8-0.6.beta
+- fix release versioning to match guidelines
+- fix up lzma-compat summary/description
+- tweak licensing
+
 * Mon Jun 22 2009 Jindrich Novy <jnovy> 4.999.8beta-0.5
 - introduce lzma-compat subpackage


As for the licensing, rather than rebase the tarball, I just updated the spec to reflect the code currently in the tarball. Core xz command is PD + LGPL code linked together, therefore it's LGPL. Similarly for the libraries. The only GPL code is the lz* scripts, which are in the compat package.

Obviously, those license tags can change when the code is rebased.

Comment 18 Ondrej Vasik 2009-07-09 18:42:27 UTC
Just one small comment - in description is a typo "purporse".

Comment 19 Bill Nottingham 2009-07-09 18:44:17 UTC
Fixed. Didn't bump the release just for that. :)

Comment 20 Orcan Ogetbil 2009-07-11 21:41:22 UTC
Any ideas how I should handle the %trigger* lzma part of deco?
   http://cvs.fedora.redhat.com/viewvc/devel/deco-archive/deco-archive.spec?view=markup

Will lzma-compat trigger it or should I change the %trigger* entries to lzma-compat?

Comment 21 Bill Nottingham 2009-07-14 14:08:55 UTC
Orcan: shouldn't be an issue; triggers will fire on the package that provides 'lzma'.

Comment 22 Bill Nottingham 2009-07-14 14:18:59 UTC
I lied. triggers only fire on package names. Sorry.

Comment 23 Jason Tibbitts 2009-07-17 00:25:30 UTC
Perhaps Milos is on vacation, but it's come to my attention that this is critical and needs a review immediately, so I've volunteered to take care of this.  I don't mean to step on anyone's toes, but we have some important stuff waiting on this review.

Builds fine; rpmlint says:
  xz.x86_64: W: name-repeated-in-summary XZ
Generally I'd just suggest dropping "XZ Utils" from the summary, but it's not a big deal.
     
  xz.x86_64: W: incoherent-version-in-changelog 4.9999.8-0.6.beta 
   ['4.999.8-0.6.beta.fc12', '4.999.8-0.6.beta']
There's an extra '9' in the changelog entry.

  xz-devel.x86_64: W: no-documentation                          
OK.

  xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/lzcat xz
  xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/unlzma xz
  xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/lzma xz
These are OK because the links aren't dangling when dependencies are installed.

  xz-libs.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/liblzma.so.0.0.0 /lib64/libpthread.so.0
This isn't a particularly big deal.

So outside of one typo in the changelog, I don't see anything that really needs fixing.

I looked over the licensing and have a question.  The code that I believe you currently indicate is LGPLv2+ is public domain unless the getopt_long code is used.  But there shouldn't be any reason for that to be compiled or linked in, because glibc should already have it.  Indeed, the build log shows no trace of that code being used.  So why isn't the bulk of the package public domain?  (Obviously the various scripts that are GPLv2+ and are correctly marked as such.)

There's a test suite present.  I tried it and it fails utterly, though it passes when I build the package locally.   I suspect this is related to the rpath issues, so I went with the following:
  %check
  LD_LIBRARY_PATH=$PWD/src/liblzma/.libs make check
and it worked fine.   I think it's a good idea the test suite if at all possible, and it seems possible.  Any reason not to add it?

* source files match upstream.  sha256sum:
   059da5a9fe51c28b38f67e5b8063a451c516f37fbb268177fd1081b70dd97f53  
   xz-4.999.8beta.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.                                                              
* description is OK.                                                          
* dist tag is present.
* build root is OK.
? license fields match the actual licenses.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper (none).
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  xz-4.999.8-0.6.beta.fc12.x86_64.rpm
   xz = 4.999.8-0.6.beta.fc12           
   xz(x86-64) = 4.999.8-0.6.beta.fc12   
  =                                  
   liblzma.so.0()(64bit)                
   xz-libs = 4.999.8-0.6.beta.fc12      

  xz-devel-4.999.8-0.6.beta.fc12.x86_64.rpm
   pkgconfig(liblzma) = 4.999.8beta
   xz-devel = 4.999.8-0.6.beta.fc12
   xz-devel(x86-64) = 4.999.8-0.6.beta.fc12
  =
   /usr/bin/pkg-config
   liblzma.so.0()(64bit)
   pkgconfig
   xz-libs = 4.999.8-0.6.beta.fc12

  xz-libs-4.999.8-0.6.beta.fc12.x86_64.rpm
   liblzma.so.0()(64bit)
   xz-libs = 4.999.8-0.6.beta.fc12
   xz-libs(x86-64) = 4.999.8-0.6.beta.fc12
  =
   /sbin/ldconfig
   liblzma.so.0()(64bit)

  xz-lzma-compat-4.999.8-0.6.beta.fc12.x86_64.rpm
   lzma = 5
   xz-lzma-compat = 4.999.8-0.6.beta.fc12
   xz-lzma-compat(x86-64) = 4.999.8-0.6.beta.fc12
  =
    /bin/sh
   liblzma.so.0()(64bit)
   xz = 4.999.8-0.6.beta.fc12

* %check is not present but there's a test suite.
* shared libraries are installed:
   ldconfig called properly.
   unversioned .so link is in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files (excepting license files, which has been deemed OK).
* file permissions are appropriate.
* no generically named files.
* scriptlets are OK (ldconfig).
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel subpackage.
* pkgconfig file is in the -devel package; pkgconfig dependency is there.
* no static libraries.
* no libtool .la files.

Comment 24 Bill Nottingham 2009-07-17 15:38:59 UTC
(In reply to comment #23)
> I looked over the licensing and have a question.  The code that I believe you
> currently indicate is LGPLv2+ is public domain unless the getopt_long code is
> used.  But there shouldn't be any reason for that to be compiled or linked in,
> because glibc should already have it.  Indeed, the build log shows no trace of
> that code being used.  So why isn't the bulk of the package public domain? 
> (Obviously the various scripts that are GPLv2+ and are correctly marked as
> such.)

The COPYING file in the tarball is incorrect/premature (see comment #13); the
code for the xz commands (src/xz/*.c) is marked as LGPLv2.1+ in its comments.

Comment 25 Bill Nottingham 2009-07-17 16:52:21 UTC
OK, new files:

http://notting.fedorapeople.org/review/xz.spec
http://notting.fedorapeople.org/review/xz-4.999.8-0.7.beta.fc11.src.rpm

> Builds fine; rpmlint says:
>   xz.x86_64: W: name-repeated-in-summary XZ
> Generally I'd just suggest dropping "XZ Utils" from the summary, but it's not a
> big deal.

Fixed.

>   xz.x86_64: W: incoherent-version-in-changelog 4.9999.8-0.6.beta 
>    ['4.999.8-0.6.beta.fc12', '4.999.8-0.6.beta']
> There's an extra '9' in the changelog entry.

Fixed.

> There's a test suite present.  I tried it and it fails utterly, though it
> passes when I build the package locally.   I suspect this is related to the
> rpath issues, so I went with the following:
>   %check
>   LD_LIBRARY_PATH=$PWD/src/liblzma/.libs make check
> and it worked fine.   I think it's a good idea the test suite if at all
> possible, and it seems possible.

Added.

Comment 26 Jason Tibbitts 2009-07-17 17:52:12 UTC
Looks good; the issues I had are fixed, rpmlint is down to the acceptable complaints covered earlier and the license issue has been clarified (although I thought I understood a comment on the upstream web site to indicate that the COPYING file had been corrected in this version).  The test suite runs and passes on my builder:
 All 7 tests passed

APPROVED

Comment 27 Bill Nottingham 2009-07-17 18:02:21 UTC
New Package CVS Request
=======================
Package Name: xz
Short Description: LZMA compression utilities
Owners: jnovy notting
Branches: F-11 F-10
InitialCC:

Comment 28 Orcan Ogetbil 2009-07-17 18:08:21 UTC
Thank you all for finishing the review. Me and many people appreciate it.

Comment 29 Jason Tibbitts 2009-07-17 18:11:49 UTC
CVS done.

Comment 30 Bill Nottingham 2009-07-17 18:27:12 UTC
Building for rawhide. I'll leave when to submit updates for earlier releases up to Jindrich. Thanks all for the help!

Comment 31 Orcan Ogetbil 2009-07-18 23:13:38 UTC
Will F-10/F-11 users (for instance: package reviewers) be able to open SRPMs made in rawhide? IMHO, at the least, xz could be held at the testing repos for some time.

Comment 32 Milos Jakubicek 2009-07-19 08:20:43 UTC
Ops, yeah, I just came back from a vacation (forgot to put it in the wiki)...Jason, many thanks you looked into this and sorry for the delay.

(In reply to comment #31)
> Will F-10/F-11 users (for instance: package reviewers) be able to open SRPMs
> made in rawhide? IMHO, at the least, xz could be held at the testing repos for
> some time.  

Maybe I missed the point but why they shouldn't be able to do so? This works just fine.

Comment 33 Bill Nottingham 2009-07-20 14:49:25 UTC
(In reply to comment #31)
> Will F-10/F-11 users (for instance: package reviewers) be able to open SRPMs
> made in rawhide? IMHO, at the least, xz could be held at the testing repos for
> some time.  

If we don't flip the default in rawhide, sure! (Obviously)

If we do change the default, we'd need an updated package. I was going to leave the timing of that up to the RPM maintainers, though.

Comment 34 Toshio Ernie Kuratomi 2009-07-20 20:22:37 UTC
Talked with notting.  We want to branch this so it's available in infrastructure.  Builders will be running with a copy from the builder-rpms repo for now but long term it's better to have it in epel.

Package Change Request
======================
Package Name: xz
New Branches: EL-5
Owners: toshio

Comment 35 Jason Tibbitts 2009-07-21 15:20:35 UTC
CVS done.

Comment 36 Jindrich Novy 2009-07-29 11:33:15 UTC
/me is back.

Thanks to all you guys for importing xz!


Note You need to log in before you can comment on or make changes to this bug.