1:35 a.m.
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/"??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
12:10 p.m.
New subject: No lzma sdk in fedora
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(a)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
2:17 a.m.
New subject: No lzma sdk in fedora
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/"????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
>
>
>
>
>
12:25 p.m.
New subject: No lzma sdk in fedora
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
2:52 p.m.
New subject: No lzma sdk in fedora
On Fri, Feb 12, 2010 at 19:25:14 +0100,
Milos Jakubicek <xjakub(a)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.
3:34 p.m.
New subject: No lzma sdk in fedora
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.
--
4:09 p.m.
New subject: No lzma sdk in fedora
On Fri, Feb 12, 2010 at 13:34:48 -0800,
John Reiser <jreiser(a)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?
5:04 p.m.
New subject: No lzma sdk in fedora
On 02/12/2010 02:09 PM, Bruno Wolff III wrote:
On Fri, Feb 12, 2010 at 13:34:48 -0800,
John Reiser<jreiser(a)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.
--
5:11 p.m.
New subject: No lzma sdk in fedora
On Fri, Feb 12, 2010 at 15:04:06 -0800,
John Reiser <jreiser(a)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?
6:08 p.m.
New subject: No lzma sdk in fedora
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
9:39 p.m.
New subject: No lzma sdk in fedora
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().
--
10:31 p.m.
New subject: No lzma sdk in fedora
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
3:57 a.m.
New subject: No lzma sdk in fedora
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
4:49 a.m.
New subject: No lzma sdk in fedora
On Sat, Feb 13, 2010 at 10:57:35 +0100,
Kevin Kofler <kevin.kofler(a)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.
4:58 a.m.
New subject: No lzma sdk in fedora
On Sat, Feb 13, 2010 at 10:57:35 +0100,
Kevin Kofler <kevin.kofler(a)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.
1:34 p.m.
New subject: No lzma sdk in fedora
On Sat, Feb 13, 2010 at 10:57:35 +0100,
Kevin Kofler <kevin.kofler(a)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.)
2:24 p.m.
New subject: No lzma sdk in fedora
On Sat, Feb 13, 2010 at 13:34:13 -0600,
Bruno Wolff III <bruno(a)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.
11:58 p.m.
New subject: No lzma sdk in fedora
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.
7:48 a.m.
New subject: No lzma sdk in fedora
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 -
5208
days inactive
5210
days old
18 comments
7 participants
participants (7)
-
Bruno Wolff III -
Chen Lei -
John Reiser -
Kevin Kofler -
Milos Jakubicek -
Panu Matilainen -
Toshio Kuratomi