FS#30187 - [xz] please update to 5.1.1alpha1 / SMP

Attached to Project: Arch Linux
Opened by Andreas Radke (AndyRTR) - Friday, 08 June 2012, 06:22 GMT
Last edited by Pierre Schmitz (Pierre) - Monday, 11 June 2012, 08:56 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

Current stable xz release lacks smp support. It's a pain in the ass to wait for LibreOffice (,-i18n) stuff getting compressed.
Some quick reseach shows 5.1.1 being stable enough to be included in the last two Fedora releases
and it's even for a long time in Debian testing (Ubuntu is shipping it in its LTS release).

http://pkgs.fedoraproject.org/gitweb/?p=xz.git;a=summary
https://bugzilla.redhat.com/show_bug.cgi?id=736318 - not sure if we could be hit by this bug

http://packages.debian.org/changelogs/pool/main/x/xz-utils/xz-utils_5.1.1alpha+20110809-3/changelog

My only concerns are the ABI changes and a .so bump Debian introduced in their -3 release. I guess there's no need to follow this right now.

I suggest to push the 5.1.1alpha1 as it is to testing. It shouldn't be less stable than the 5.0.3 release but would give us SMP speed improvements.
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Monday, 11 June 2012, 08:56 GMT
Reason for closing:  Won't implement
Additional comments about closing:  We will only update if upstream considers this version ready for production.
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 08 June 2012, 15:14 GMT
I, for one, would welcome if this proposal were successful.
Comment by Pierre Schmitz (Pierre) - Friday, 08 June 2012, 15:14 GMT
As long as the author does not declare 5.1 stable I wont update one of our basic tools to an alpha version. He just posted that this version will still need some work.

I'd also like to know how much time you spend compiling, compressing and uploading. For me this seems really not worth the danger.

If compression time is really significant higher than compile + upload time, you still could override PKGEXT and use gzip for compression.
Comment by Stéphane Gaudreault (stephane) - Friday, 08 June 2012, 22:03 GMT
Maybe we could add an xz-devel package in [extra] and use this one when the packages is in [extra] and is too big ?
Comment by Andreas Radke (AndyRTR) - Saturday, 09 June 2012, 06:21 GMT
In IRC we came to the conclusion to not yet jump on it because the upstream developer has concerns about some issues in alpha1.
We will wait at least for the next beta1 release and a statement that no corruptions are known.
Comment by Christian Hesse (eworm) - Monday, 11 June 2012, 07:06 GMT
You could use my AUR package xz-git for testing:
https://aur.archlinux.org/packages.php?ID=54518

It is a drop in replacement for xz. I use it for several month now, works
without any flaws so far. So...

+1
Comment by Christian Hesse (eworm) - Monday, 11 June 2012, 08:51 GMT
I have read through the Red Hat bug #736318 (https://bugzilla.redhat.com/show_bug.cgi?id=736318) and think we are not hit by this bug.

Actually it is not a xz issue in first place. draout generates an inird images that is two concatenated cpio images. xz (5.0.3 and 5.1.1 do behave the same here I think) is not able to extract the second part of the inird without manually dealing with the correct offset.

So unless anybody decides mkinitcpio has to build broken initramfs we are fine. (lsinitcpio and xz-git work just fine for me.)

Loading...