1:13 p.m.
Per prior discussion -- this was, indeed, trivial.
I'm a little disappointed to be breaking the ordering characteristics of
the enum (as it had been ordered by increasing time requirements and
decreasing output size), but breaking any save files with the old
constants in the headers would of course be worse.
5:04 a.m.
Charles Duffy wrote:
Per prior discussion -- this was, indeed, trivial.
I'm a little disappointed to be breaking the ordering characteristics of
the enum (as it had been ordered by increasing time requirements and
decreasing output size), but breaking any save files with the old
Heh, that was completely an accident; I just added them as I implemented them.
So no loss there.
ACK to the patch.
--
Chris Lalancette
6:48 a.m.
Chris Lalancette wrote:
Charles Duffy wrote:
> Per prior discussion -- this was, indeed, trivial.
>
> I'm a little disappointed to be breaking the ordering characteristics of
> the enum (as it had been ordered by increasing time requirements and
> decreasing output size), but breaking any save files with the old
Heh, that was completely an accident; I just added them as I implemented them.
So no loss there.
ACK to the patch.
Hi Chris,
FYI, in the context of that patch, I noticed compression support (nice!),
and LZMA support in particular, but none for xz, which is the successor
to lzma. <http://tukaani.org/xz/>
Now that XZ's format is stable, and xz is in F11, you may
want to support it, too.
Actually, since lzma is deprecated, and support for it in libvirt
went in only 3 weeks ago, you may want to remove it completely,
in favor of xz.
Jim
7:06 a.m.
Jim Meyering wrote:
Chris Lalancette wrote:
> Charles Duffy wrote:
>> Per prior discussion -- this was, indeed, trivial.
>>
>> I'm a little disappointed to be breaking the ordering characteristics of
>> the enum (as it had been ordered by increasing time requirements and
>> decreasing output size), but breaking any save files with the old
> Heh, that was completely an accident; I just added them as I implemented them.
> So no loss there.
>
> ACK to the patch.
Hi Chris,
FYI, in the context of that patch, I noticed compression support (nice!),
and LZMA support in particular, but none for xz, which is the successor
to lzma. <http://tukaani.org/xz/>
Now that XZ's format is stable, and xz is in F11, you may
want to support it, too.
Actually, since lzma is deprecated, and support for it in libvirt
went in only 3 weeks ago, you may want to remove it completely,
in favor of xz.
Hey Jim,
Right, I noticed that as I was developing this (and another patch). The
situation between xz and lzma wasn't completely clear to me, so thanks for
clarifying a little. The thing is, isn't the command-line tool for xz still
called "lzma"? Or is the tool called "xz"?
--
Chris Lalancette
7:17 a.m.
Chris Lalancette wrote:
Jim Meyering wrote:
> Chris Lalancette wrote:
>> Charles Duffy wrote:
>>> Per prior discussion -- this was, indeed, trivial.
>>>
>>> I'm a little disappointed to be breaking the ordering characteristics of
>>> the enum (as it had been ordered by increasing time requirements and
>>> decreasing output size), but breaking any save files with the old
>> Heh, that was completely an accident; I just added them as I implemented them.
>> So no loss there.
>>
>> ACK to the patch.
>
> Hi Chris,
>
> FYI, in the context of that patch, I noticed compression support (nice!),
> and LZMA support in particular, but none for xz, which is the successor
> to lzma. <http://tukaani.org/xz/>
>
> Now that XZ's format is stable, and xz is in F11, you may
> want to support it, too.
>
> Actually, since lzma is deprecated, and support for it in libvirt
> went in only 3 weeks ago, you may want to remove it completely,
> in favor of xz.
Hey Jim,
Right, I noticed that as I was developing this (and another patch). The
situation between xz and lzma wasn't completely clear to me, so thanks for
clarifying a little. The thing is, isn't the command-line tool for xz still
called "lzma"? Or is the tool called "xz"?
xz is the new format name as well as the new program name.
The LZMA -> XZ format change was big enough that it seemed best to
have a new tool name (though it was a close call, and there was a lot
of debate ;-), in spite of the trouble it causes to users.
However, note that xz can uncompress .lzma files.
2:12 p.m.
Charles Duffy wrote:
Per prior discussion -- this was, indeed, trivial.
I'm a little disappointed to be breaking the ordering characteristics of
the enum (as it had been ordered by increasing time requirements and
decreasing output size), but breaking any save files with the old
constants in the headers would of course be worse.
Committed, thanks. Note that I slightly modified the patch to add a bit of
documentation into the src/qemu.conf file, so please check it out.
We'll deal with the lzma/xz problems in another patch.
--
Chris Lalancette
5603
days inactive
5606
days old
5 comments
3 participants
participants (3)
-
Charles Duffy -
Chris Lalancette -
Jim Meyering