In fact libarchive doesn't require lzma-libs any more in F12 and F13. For F11: repoquery --whatrequires libarchive.so.2 PackageKit-glib-0:0.4.9-1.fc11.i586 libarchive-0:2.6.2-1.fc11.i586 kdeutils-6:4.2.2-4.fc11.i586 PackageKit-glib-0:0.4.6-8.fc11.i586 libarchive-devel-0:2.6.2-1.fc11.i586 Updating libarchive to the F12 only affects a few stuffs(soname unchanged).
在2010-02-13?01:02:56，"Milos?Jakubicek"?xjakub@fi.muni.cz?写道：
Hi?Chen,
On?12.2.2010?12:50,?Chen?Lei?wrote:
?I?realized?from?"http://tukaani.org/xz/%22??the?core?of?the?xz?utils ?compression?code?is?based?on?LZMA?SDK?http://7-zip.org/sdk.html,?but ?it?has?been?modified?quite?a?lot?to?be?suitable?for?XZ?Utils. ?So?I?think?we?should?ship?lzma?sdk?for?fedora?in?parallel?with?xz?utils ?and?p7zip.?Since?xz?utils?are?the?successor?to?lzma?utils,?maybe?lzma ?utils?can?be?safely?retired?in?fedora.
Retiring?lzma?(completely)?is?a?long-term?plan,?yes?(I'm?the?maintainer? of?it).?Not?sure?about?the?right?time?--?F14?
I'll?talk?to?the?libarchive?maintainer?--?any?other?objections?against? the?plan?to?retire?lzma?for?F14?
Milos
Oh, I didn't really notice how your repoquery looks like before. Libarchive is ok, but there are others:
repoquery --whatrequires --alldeps lzma lzma-libs lzma-devel
--enablerepo=rawhide rpm-build-0:4.7.1-6.fc12.x86_64 rpm-build-0:4.8.0-9.fc13.x86_64 man-0:1.6f-25.fc12.x86_64 autoarchive-0:0.1.2-2.fc12.noarch rpm-build-0:4.7.2-1.fc12.x86_64 man-0:1.6f-22.fc12.x86_64 man-0:1.6f-26.fc13.x86_64 man-0:1.6f-24.fc12.x86_64 lzma-libs-0:4.32.7-3.fc12.x86_64 lzma-0:4.32.7-3.fc12.x86_64 lzma-libs-0:4.32.7-3.fc12.i686 lzma-devel-0:4.32.7-3.fc12.x86_64 lzma-devel-0:4.32.7-3.fc12.i686
...which need to be sorted out.
CC'ing autoarchive, man and rpm maintainers:
Ivana, Panu, Fabian: are your packages able to use xz instead? (I guess in case of rpm this is just a relict, right?)
In all cases the lzma dependency is hardcoded, can hopefully be just removed.
If yes, I can retire lzma as soon as we branch F13.
Milos
On 12.2.2010 18:35, Chen Lei wrote:
In fact libarchive doesn't require lzma-libs any more in F12 and F13. For F11: repoquery --whatrequires libarchive.so.2 PackageKit-glib-0:0.4.9-1.fc11.i586 libarchive-0:2.6.2-1.fc11.i586 kdeutils-6:4.2.2-4.fc11.i586 PackageKit-glib-0:0.4.6-8.fc11.i586 libarchive-devel-0:2.6.2-1.fc11.i586 Updating libarchive to the F12 only affects a few stuffs(soname unchanged).
��2010-02-13 01:02:56��"Milos Jakubicek" <xjakub@fi.muni.cz mailto:xjakub@fi.muni.cz> ������
Hi Chen,
On 12.2.2010 12:50, Chen Lei wrote:
I realized from "http://tukaani.org/xz/" the core of the xz utils compression code is based on LZMA SDK http://7-zip.org/sdk.html, but it has been modified quite a lot to be suitable for XZ Utils. So I think we should ship lzma sdk for fedora in parallel with xz utils and p7zip. Since xz utils are the successor to lzma utils, maybe lzma utils can be safely retired in fedora.
Retiring lzma (completely) is a long-term plan, yes (I'm the maintainer of it). Not sure about the right time -- F14?
I'll talk to the libarchive maintainer -- any other objections against the plan to retire lzma for F14?
Milos
lzma itself already replaced by xz-lzma-compat several months ago. xz-lzma-compat provides lzma=5.
在2010-02-13?02:10:23，"Milos?Jakubicek"?xjakub@fi.muni.cz?写道：
Oh,?I?didn't?really?notice?how?your?repoquery?looks?like?before. Libarchive?is?ok,?but?there?are?others:
?>repoquery?--whatrequires?--alldeps?lzma?lzma-libs?lzma-devel? --enablerepo=rawhide rpm-build-0:4.7.1-6.fc12.x86_64 rpm-build-0:4.8.0-9.fc13.x86_64 man-0:1.6f-25.fc12.x86_64 autoarchive-0:0.1.2-2.fc12.noarch rpm-build-0:4.7.2-1.fc12.x86_64 man-0:1.6f-22.fc12.x86_64 man-0:1.6f-26.fc13.x86_64 man-0:1.6f-24.fc12.x86_64 lzma-libs-0:4.32.7-3.fc12.x86_64 lzma-0:4.32.7-3.fc12.x86_64 lzma-libs-0:4.32.7-3.fc12.i686 lzma-devel-0:4.32.7-3.fc12.x86_64 lzma-devel-0:4.32.7-3.fc12.i686
...which?need?to?be?sorted?out.
CC'ing?autoarchive,?man?and?rpm?maintainers:
Ivana,?Panu,?Fabian:?are?your?packages?able?to?use?xz?instead? (I?guess?in?case?of?rpm?this?is?just?a?relict,?right?)
In?all?cases?the?lzma?dependency?is?hardcoded,?can?hopefully?be?just? removed.
If?yes,?I?can?retire?lzma?as?soon?as?we?branch?F13.
Milos
On?12.2.2010?18:35,?Chen?Lei?wrote:
?In?fact?libarchive?doesn't?require?lzma-libs?any?more?in?F12?and?F13. ?For?F11: ?repoquery?--whatrequires?libarchive.so.2 ?PackageKit-glib-0:0.4.9-1.fc11.i586 ?libarchive-0:2.6.2-1.fc11.i586 ?kdeutils-6:4.2.2-4.fc11.i586 ?PackageKit-glib-0:0.4.6-8.fc11.i586 ?libarchive-devel-0:2.6.2-1.fc11.i586 ?Updating?libarchive?to?the?F12?only?affects?a?few?stuffs(soname?unchanged).
?在2010-02-13??01:02:56，"Milos??Jakubicek"??<xjakub@fi.muni.cz??mailto:xjakub@fi.muni.cz>??写道：
Hi??Chen,
On??12.2.2010??12:50,??Chen??Lei??wrote:
??I??realized??from??"http://tukaani.org/xz/%22????the??core??of??the??xz??utils ??compression??code??is??based??on??LZMA??SDK??http://7-zip.org/sdk.html,??but ??it??has??been??modified??quite??a??lot??to??be??suitable??for??XZ??Utils. ??So??I??think??we??should??ship??lzma??sdk??for??fedora??in??parallel??with??xz??utils ??and??p7zip.??Since??xz??utils??are??the??successor??to??lzma??utils,??maybe??lzma ??utils??can??be??safely??retired??in??fedora.
Retiring??lzma??(completely)??is??a??long-term??plan,??yes??(I'm??the??maintainer of??it).??Not??sure??about??the??right??time??--??F14?
I'll??talk??to??the??libarchive??maintainer??--??any??other??objections??against the??plan??to??retire??lzma??for??F14?
Milos
On 12.2.2010 19:17, Chen Lei wrote:
lzma itself already replaced by xz-lzma-compat several months ago. xz-lzma-compat provides lzma=5.
Am I dumb, oh yes of course, this is since the xz review, sorry for confusion!
Well then we are safe to go.
Milos
On Fri, Feb 12, 2010 at 19:25:14 +0100, Milos Jakubicek xjakub@fi.muni.cz wrote:
On 12.2.2010 19:17, Chen Lei wrote:
lzma itself already replaced by xz-lzma-compat several months ago. xz-lzma-compat provides lzma=5.
Am I dumb, oh yes of course, this is since the xz review, sorry for confusion!
Well then we are safe to go.
I'll take a quick look over the weekend. We probably want to wait until the branch next week anyway. I have been meaning to get back to squashfs-tools in any case, as this gives me a way forward. If it looks like I can figure it out, I plan on submitting a package for it.
Another related note is that someone wanted a src package for it because they had something that would only build with access to the source. I am not planning on providing that, but wanted people to be aware we had a request for it.
Another related note is that someone wanted a src package for it because they had something that would only build with access to the source. I am not planning on providing that, but wanted people to be aware we had a request for it.
The package that needs the src is the upx package. The coupling is very strong, therefore a physical copy of the entire specific version of lzma source was put into the source for Fedora's upx. The URL for that lzma source was recorded, but not used as a SourceN:. It is expected that the URL will become stale.
--
On Fri, Feb 12, 2010 at 13:34:48 -0800, John Reiser jreiser@bitwagon.com wrote:
Another related note is that someone wanted a src package for it because they had something that would only build with access to the source. I am not planning on providing that, but wanted people to be aware we had a request for it.
The package that needs the src is the upx package. The coupling is very strong, therefore a physical copy of the entire specific version of lzma source was put into the source for Fedora's upx. The URL for that lzma source was recorded, but not used as a SourceN:. It is expected that the URL will become stale.
Do you think packaging that as a subpackage is worth while? A couple of other packages seem to do that kind of thing?
Where is an appropriate location to put the source?
Is a buildrequires on a package that provides source allowed for packaging?
On 02/12/2010 02:09 PM, Bruno Wolff III wrote:
On Fri, Feb 12, 2010 at 13:34:48 -0800, John Reiserjreiser@bitwagon.com wrote:
The package that needs the src is the upx package. The coupling is very strong, therefore a physical copy of the entire specific version of lzma source was put into the source for Fedora's upx. The URL for that lzma source was recorded, but not used as a SourceN:. It is expected that the URL will become stale.
Do you think packaging that as a subpackage is worth while? A couple of other packages seem to do that kind of thing?
Going forward, there should be a -libs package (and probably a -devel package) and its use should be encouraged (instead of lzma source), particularly for new uses. Probably it is too difficult to force _all_ existing uses of lzma source to convert to using -libs. The reasons have to do with ten years of history: the original author of lzma resisted providing libraries, the internal interfaces changed too rapidly, the original licensing was too restrictive, etc. Today http://7-zip.org/sdk.html says "LZMA SDK is placed in the public domain".
Where is an appropriate location to put the source?
The Fedora upx package put its copy of lzma465.tar.bz2 as another file in the SOURCES for Fedora upx, in same directory as upx-3.04.tar.bz2.
Is a buildrequires on a package that provides source allowed for packaging?
I don't know.
On Fri, Feb 12, 2010 at 15:04:06 -0800, John Reiser jreiser@bitwagon.com wrote:
Going forward, there should be a -libs package (and probably a -devel package) and its use should be encouraged (instead of lzma source), particularly for new uses. Probably it is too difficult to force _all_ existing uses of lzma source to convert to using -libs. The reasons have to do with ten years of history: the original author of lzma resisted providing libraries, the internal interfaces changed too rapidly, the original licensing was too restrictive, etc. Today http://7-zip.org/sdk.html says "LZMA SDK is placed in the public domain".
That is the standard stuff. What I was really asking is if there should be a source package so that upx could be built without having a second copy of the SDK in another srpm?
On Fri, Feb 12, 2010 at 03:04:06PM -0800, John Reiser wrote:
Where is an appropriate location to put the source?
The Fedora upx package put its copy of lzma465.tar.bz2 as another file in the SOURCES for Fedora upx, in same directory as upx-3.04.tar.bz2.
This is a bundled library and needs to stop. How to stop doing it is another question :-)
Looks like some background information is here: https://bugzilla.redhat.com/show_bug.cgi?id=501636
Options: 1) Rebreak LZMA support by simply removing the lzma library 2) Figure out just which files need to be imported from the LZMA source to compile and include those. This would hinge on the definition of a bundled library which FPC is mulling over right now. 3) Port upx to use something other than the old liblzma. From the sounds of it, the old liblzma doesn't provide the needed API for upx to work. However, xz's liblzma is supposed to be closer to the zlib API so it might be possible to change this now. 4) You can request an exception from FESCo but it would need a compelling reason to grant it.
-Toshio
On 02/12/2010 04:08 PM, Toshio Kuratomi wrote:
On Fri, Feb 12, 2010 at 03:04:06PM -0800, John Reiser wrote:
The Fedora upx package put its copy of lzma465.tar.bz2 as another file in the SOURCES for Fedora upx, in same directory as upx-3.04.tar.bz2.
This is a bundled library and needs to stop. How to stop doing it is another question :-)
Upx uses lzma465 not as a library but as a source schema. If compiled outside of upx, then lzma465 is not useful to upx. Upx has C++ definitions and #defines that re-interpret the lzma465 source, including changing interfaces and class layout, in order to be usable by upx. The re- interpretation includes the format of the output compressed data, as well as enforcing constraints during compression which facilitate decompression in the "no-libraries" runtime environment of life immediately after execve().
--
On Fri, Feb 12, 2010 at 07:39:36PM -0800, John Reiser wrote:
On 02/12/2010 04:08 PM, Toshio Kuratomi wrote:
On Fri, Feb 12, 2010 at 03:04:06PM -0800, John Reiser wrote:
The Fedora upx package put its copy of lzma465.tar.bz2 as another file in the SOURCES for Fedora upx, in same directory as upx-3.04.tar.bz2.
This is a bundled library and needs to stop. How to stop doing it is another question :-)
Upx uses lzma465 not as a library but as a source schema. If compiled outside of upx, then lzma465 is not useful to upx. Upx has C++ definitions and #defines that re-interpret the lzma465 source, including changing interfaces and class layout, in order to be usable by upx. The re- interpretation includes the format of the output compressed data, as well as enforcing constraints during compression which facilitate decompression in the "no-libraries" runtime environment of life immediately after execve().
Yes, I realized that from the bug report. My comments still stand.
-Toshio
Bruno Wolff III wrote:
I'll take a quick look over the weekend. We probably want to wait until the branch next week anyway. I have been meaning to get back to squashfs-tools in any case, as this gives me a way forward. If it looks like I can figure it out, I plan on submitting a package for it.
Well, personally I'd be really happy if we could sneak LZMA support for squashfs and livecd-creator into F13, it'd allow us to provide a better KDE spin while keeping CD size. But I realize we're supposed to be in feature freeze and schedules are tight. Still, I don't think we should wait just to wait. ;-)
Kevin Kofler
On Sat, Feb 13, 2010 at 10:57:35 +0100, Kevin Kofler kevin.kofler@chello.at wrote:
Bruno Wolff III wrote:
I'll take a quick look over the weekend. We probably want to wait until the branch next week anyway. I have been meaning to get back to squashfs-tools in any case, as this gives me a way forward. If it looks like I can figure it out, I plan on submitting a package for it.
Well, personally I'd be really happy if we could sneak LZMA support for squashfs and livecd-creator into F13, it'd allow us to provide a better KDE spin while keeping CD size. But I realize we're supposed to be in feature freeze and schedules are tight. Still, I don't think we should wait just to wait. ;-)
I'd be a lot more likely to just do the squashfs part. The default is still to use zlib. Messing with livecd-creator seems a bit more risky at this stage. I was hoping I could get it done for F13, but the squashfs tools build ended up being complicated by the lzma issues.
On Sat, Feb 13, 2010 at 10:57:35 +0100, Kevin Kofler kevin.kofler@chello.at wrote:
Bruno Wolff III wrote:
I'll take a quick look over the weekend. We probably want to wait until the branch next week anyway. I have been meaning to get back to squashfs-tools in any case, as this gives me a way forward. If it looks like I can figure it out, I plan on submitting a package for it.
Well, personally I'd be really happy if we could sneak LZMA support for squashfs and livecd-creator into F13, it'd allow us to provide a better KDE spin while keeping CD size. But I realize we're supposed to be in feature freeze and schedules are tight. Still, I don't think we should wait just to wait. ;-)
Another issue is the kernel patches are in linux-next waiting for 2.6.34. I doubt that we will release with 2.6.34.
On Sat, Feb 13, 2010 at 10:57:35 +0100, Kevin Kofler kevin.kofler@chello.at wrote:
Bruno Wolff III wrote:
I'll take a quick look over the weekend. We probably want to wait until the branch next week anyway. I have been meaning to get back to squashfs-tools in any case, as this gives me a way forward. If it looks like I can figure it out, I plan on submitting a package for it.
Well, personally I'd be really happy if we could sneak LZMA support for squashfs and livecd-creator into F13, it'd allow us to provide a better KDE spin while keeping CD size. But I realize we're supposed to be in feature freeze and schedules are tight. Still, I don't think we should wait just to wait. ;-)
It seems Lougher added a wrapper for xz about a week ago. I haven't tried it out yet, but I think that will likely make it significantly easier for me to get 4.1 into rawhide. I won't do this before the alpha, but it might be there for the release. (Though not usuable for live images without kernel and livecd-tools support.)
On Sat, Feb 13, 2010 at 13:34:13 -0600, Bruno Wolff III bruno@wolff.to wrote:
It seems Lougher added a wrapper for xz about a week ago. I haven't tried it out yet, but I think that will likely make it significantly easier for me to get 4.1 into rawhide. I won't do this before the alpha, but it might be there for the release. (Though not usuable for live images without kernel and livecd-tools support.)
Since I was curious I went and tried out a scratch build with the new feature in the development version and it built cleanly. I haven't tested functionallity yet, but it looks like for squash-tools I am going to be moving in another direction and don't need a lib based off the SDK.
So the odds that prerelease 4.1 version of squashfs-tools will make it into f13 just went up.
I did some testing of the dev squashfs and found it reduced the game spin size by 10%. (This was a nonfunctional spin, since the kernel wouldn't handle the lzma squashfs image.) mksquashfs uses multiple processors for both zlib and lzma compression. I made a spin using the dev squashfs using the default zlib compression and it worked. This suggests that we can get the dev version into F13 without needing to wait until kernel support and an enhanced livecd-creator are ready. I still don't think trying to change livecd-creator to add features this late is a good idea, but it might be OK to land it as an update after a 2.6.34 update has landed in F13.
On Fri, 12 Feb 2010, Milos Jakubicek wrote:
Oh, I didn't really notice how your repoquery looks like before. Libarchive is ok, but there are others:
repoquery --whatrequires --alldeps lzma lzma-libs lzma-devel
--enablerepo=rawhide rpm-build-0:4.7.1-6.fc12.x86_64 rpm-build-0:4.8.0-9.fc13.x86_64 man-0:1.6f-25.fc12.x86_64 autoarchive-0:0.1.2-2.fc12.noarch rpm-build-0:4.7.2-1.fc12.x86_64 man-0:1.6f-22.fc12.x86_64 man-0:1.6f-26.fc13.x86_64 man-0:1.6f-24.fc12.x86_64 lzma-libs-0:4.32.7-3.fc12.x86_64 lzma-0:4.32.7-3.fc12.x86_64 lzma-libs-0:4.32.7-3.fc12.i686 lzma-devel-0:4.32.7-3.fc12.x86_64 lzma-devel-0:4.32.7-3.fc12.i686
...which need to be sorted out.
CC'ing autoarchive, man and rpm maintainers:
Ivana, Panu, Fabian: are your packages able to use xz instead? (I guess in case of rpm this is just a relict, right?)
Yup, the rpm-build dependency on "lzma" is for the command line utility for uncompressing lzma compressed sources and patches. Hmm... and actually in current rawhide the lzma dependency is plain bogus %__lzma just points to xz:
# Deprecated, use %__xz instead. %__lzma %__xz --format=lzma
I'll kill off the unnecessary dependency.
- Panu -
-
Bruno Wolff III -
Chen Lei -
John Reiser -
Kevin Kofler -
Milos Jakubicek -
Panu Matilainen -
Toshio Kuratomi