Hi. Altlinux uses rpm files which are packed with lzma. For example download[1] src.rpm and try to rpm2targz it - that fail. I've found inside lzma-4.32.7.tar.bz2 code to check if that's lzma archive: int find_lzma_header(unsigned char *buf) { return (buf[0] < 0xE1 && buf[0] == 0x5d && buf[4] < 0x20 && (memcmp (buf + 10 , "\x00\x00\x00", 3) == 0 || (memcmp (buf + 5, "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF", 8) == 0))); } and patched rpmoffset.c to check for lzma too (patch follows). Now it works, but it makes code not such nice as it was before... Patch follows. [1] http://sisyphus.ru/ru/srpm/Sisyphus/man-pages-ru/get [2] lzma-4.32.7/extra/scanlzma/scanlzma.c
Created attachment 232875 [details, diff] rpmoffset.c.patch The question is should we go this way or what? In any case there is real need to support lzma packed rpms...
that wont work on all lzma archives either as some implementations fill out the filesize field (that 8 byte field). simply extend the existing magic logic and look for the first few lzma bytes. also post a link to an archive that isnt working for you.
This is link on archive that does not work: ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/man-pages-ru-0.98-alt19.src.rpm This link could became invalid also the one in comment #0 should work. And I'm not sure how to extend magic logic... :( As I understand this code if people fill filesize field then they should have memcmp (buf + 10 , "\x00\x00\x00", 3) == 0 so afais this is handled with this check.
With this patch applied, some (maybe all ?) rpm files created with xz fails to unpack. The problem is, they contain lzma signature and it is present towards the beginning of the file. I have made some modifications, so that rpmoffset continues to search when lzma is detected, in case there is xz data later in the file. See [1] for example. There are a few more rpms in that folder to test with too. http://cekirdek.pardus.org.tr/~onur/rpm2targz/system-config-nfs-1.3.49-1.fc12.noarch.rpm
Created attachment 241561 [details] lzma patch with xz fix
Created attachment 244145 [details, diff] rpm2targz-lzma.patch it isnt that there is a lzma signature so much that the lzma check is way too permissive. the current code: + buf[0] < 0xE1 && buf[0] == 0x5d this is dumb because you cant have a value of 0x5d without being less than 0xe1 the gist of it is that if you have a bit stream that matches: 0x5d 0x.. 0x.. 0x.. (0x.. < 0x20) 0x.. 0x.. 0x.. 0x.. 0x.. 0x00 0x00 0x00 that's a bit too fuzzy for my tastes. at any rate, the current patches have style issues up the wazoo, so try this patch instead.
(In reply to comment #6) ... > that's a bit too fuzzy for my tastes. Agreed, but IIRC that is how it is with (old) lzma > at any rate, the current patches have style issues up the wazoo, so try this > patch instead. This patch looks fine to me, I have tested with some samples, no problem so far.
tracked at https://bugs.launchpad.net/gentoo/+bug/634154
why ? i see no point in that.
(In reply to comment #6) > Created attachment 244145 [details, diff] > rpm2targz-lzma.patch > > at any rate, the current patches have style issues up the wazoo, so try this > patch instead. It works for me too. Can we have it in the tree?
*** Bug 377173 has been marked as a duplicate of this bug. ***
I also suffer from this problem as openSUSE is also providing this kind of rpm files :-S Could that patch be applied if possible? Thanks a lot
Hi, Can someone tell me how to apply this patch to my system? I need to unpack a lzma rpm. I'm willing to make portage overlay, jump through hoops, stand on head, etc, I just need to know what to do. Thank you
This shows the basic idea to get a patch: http://en.gentoo-wiki.com/wiki/Writing_Ebuilds#Adding_a_patch 1. Create a portage overlay for rpm2targz 2. Add the patch to the files directory 3. Modify the ebuild as per the above link 4. ebuild xxx digest 5. emerge -vat rpm2targz
http://git.overlays.gentoo.org/gitweb/?p=proj/rpm2targz.git;a=commitdiff;h=de35a1cd59302a1cc6d3766fcc053b130ab4efa0
