Description of problem: It seems the version of the lzma-sdk we have in Fedora is quite prehistoric, i.e. 4.6.5 vs upstream latest 18.01. The version in Fedora is currently missing LZMA2 support which we would like to use in hashcat package (currently under review bug 1540347). Version-Release number of selected component (if applicable): lzma-sdk-4.6.5-20.fc28 How reproducible: Always Steps to Reproduce: 1. Check version 2. 3. Actual results: 4.6.5 Expected results: 18.01 Additional info:
Hello, I'm working with Jarda on hashcat. I would like to propose you a patch for specfile at https://tkorbar.fedorapeople.org/lzma-sdkspec.patch and new sharedlib patch at https://tkorbar.fedorapeople.org/lzma-sdk-18.0.1-sharedlib.patch I think fprintf patch is no longer needed because upstream seems to have repaired it themselves. I'm a beginner at package maintaining so any feedback would be very appreciated.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
(In reply to Tomáš Korbař from comment #1) > Hello, > I'm working with Jarda on hashcat. I would like to propose you a patch for > specfile at https://tkorbar.fedorapeople.org/lzma-sdkspec.patch > and new sharedlib patch at > https://tkorbar.fedorapeople.org/lzma-sdk-18.0.1-sharedlib.patch > I think fprintf patch is no longer needed because upstream seems to have > repaired it themselves. > I'm a beginner at package maintaining so any feedback would be very > appreciated. Thanks for looking into it. Few comments from me related to your patches: - when rebasing please return the release to 1 (i.e. it should be 1, not 22) - I think you should rm -rf the whole bin directory in %prep phase - rather then using "cd DIR; cd ..", use: "pushd DIR; popd", you don't need to remember where to return then - maybe you can keep the sourceforge home page. I am not 100% sure about it, maybe the 7zip homepage is better. I would let it on the maintainer to decide. Few more things for consideration: - what about dos2unix the whole unpacked package? It's quite strange to have CR+LF in the includes - what about putting lzma-sdk-LICENSE.fedora under %license tag? Well it's not license, but it's license related, so according to [1] it should be there. [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification
Thanks for feedback. Updated patch for spec: https://tkorbar.fedorapeople.org/lzma-sdkspec.patch
(In reply to Tomáš Korbař from comment #4) > Thanks for feedback. Updated patch for spec: > https://tkorbar.fedorapeople.org/lzma-sdkspec.patch Thanks two more comments: - I think you can use just 'rm -rf bin', i.e. without the slash - 'dos2unix -ic * | xargs dos2unix' this is a bit overcomplicated and only converts the current directory (i.e. the documentation and not the headers/includes), better to use in the top dir (or CPP top dir): find . -type f -exec dos2unix '{}' \;
Also I think the BuildRequires should contain: - coreutils (for touch, mkdir, ln) - glibc-common (for iconv) - findutils (for xargs, find) - make (for make)
Also better to do the dos2unix conversion before calling the first patch command. I.e. to have the patches without CR+LF.
One more thing for consideration. At the moment we have '/usr/include/lzma1801'. Is the version name in the include really needed? What about renaming it to just '/usr/include/lzma'. It will simplify further version bumps. At the moment it seems there is only 'upx' package build requiring lzma-sdk-devel, which hardcodes: UPX_LZMA_VERSION=0x465 UPX_LZMADIR=%{_includedir}/lzma465 make %{?_smp_mflags} -C src This seems quite strange. We could have then: UPX_LZMADIR=%{_includedir}/lzma And maybe we could also get rid of the UPX_LZMA_VERSION, there is quite strange: const char *upx_lzma_version_string(void) { #if (WITH_LZMA == 0x443) return "4.43"; #else # error "unknown WITH_LZMA version" return NULL; #endif } It could use MY_VERSION_NUMBERS from the 7zVersion.h, i.e. it could be rewritten as: #include <lzma/C/7zVersion.h> ... const char *upx_lzma_version_string(void) { return MY_VERSION_NUMBERS; } And similarly on other places. This seems much better to me. I am ready to open the bugzilla / PR to upx if we accommodate this change.
Created attachment 1398937 [details] Updated sharedlib patch Also for the hashcat to work the sharedlib patch needs updating to make Lzma2Decode part of the public API. This is the updated patch (assuming that dos2unix is run before patching). @tomas next time please attach the patches to the bugzilla
(In reply to Jaroslav Škarvada from comment #8) > One more thing for consideration. At the moment we have > '/usr/include/lzma1801'. Is the version name in the include really needed? > What about renaming it to just '/usr/include/lzma'. It seems we cannot use /usr/include/lzma, because it's already provided by the 'xz-devel' package. But I think we could use '/usr/include/lzma-sdk'.
Created attachment 1399008 [details] Updated sharedlib patch
Created attachment 1399443 [details] patch for specfile This is patch with all changes for lzma-sdk spec.
My latest patch installs the headers into /usr/include/lzma-sdk I think this is the best name for folder with headers.
(In reply to Tomáš Korbař from comment #13) > My latest patch installs the headers into /usr/include/lzma-sdk > I think this is the best name for folder with headers. Thanks, two more things I noticed: - the version isn't 18.0.1, but 18.01, see [1] and C/7zVersion.h. I think the RPM package should be then lzma-sdk-18.1 and the library should be named liblzmasdk.so.18.1.0. It seems even that the current 4.6.5 version isn't correct, it should be 4.65, see [2]. - I think you should remove /usr/include/lzma-sdk/CPP/Windows, it seems to be only Windows OS related includes [1] http://www.7-zip.org/sdk.html [2] https://sourceforge.net/projects/sevenzip/files/LZMA
Ok. You used the patch i uploaded to fedorapeople and created attachment or is it your own? I ask because the version needs to be repaired also at the makefile.
Created attachment 1400178 [details] Updated sharedlib patch I picked our current patch for sharedlib from attachments and changed the version of library at makefile to 18.01
Created attachment 1400179 [details] patch for specfile The version of rpm package is now 18.01-1
(In reply to Tomáš Korbař from comment #17) > Created attachment 1400179 [details] > patch for specfile > > The version of rpm package is now 18.01-1 Both the library and the spec should be without the leading zero, i.e. 18.1-1 for the SPEC, 18.1.0 for the library.
Created attachment 1400835 [details] patch for specfile repaired version to 18.1-1
Created attachment 1400836 [details] Updated sharedlib patch Repaired version of library to 18.1.0
Gwyn is the rebase feasible? Do you need help with co-maintenance?
If it doesn't break upx, I'm all for it. Co-maintainers welcome. I've just been watching this evolve. :)
Created attachment 1403432 [details] patch for specfile New version of patch because last time i failed to do symlinks right. Also contains command for addfuncspatch.
Created attachment 1403433 [details] patch for upx used functions in library This patch will allow us to unbundle lzma-sdk from upx.
Can we consider updating this to 18.05 before it's finalized?
(In reply to Paul K from comment #25) > Can we consider updating this to 18.05 before it's finalized? Sorry for delay, Tomas is working on it.
Upx bugzilla for reference: bug 1550187. I will continue to comment there for things related to upx.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This still an issue. Latest Fedora delivers lzma-sdk-4.6.5-30.fc37, but upstream is at lzma2201.7z <https://sourceforge.net/projects/sevenzip/files/LZMA%20SDK/> There are other potential users like lrzip-next which rely on the modern LZMA SDK <https://github.com/pete4abw/lrzip-next/discussions/94>.
Apologies, this completely fell off my radar. I'm backporting patches and it looks like there are some changes from 18.01 to 22.01. The attached patches were also made before we needed diff -U3. Could someone rebase the sharedlib and addfuncstolibrary patches? upx actually no longer uses lzma-sdk, so if you don't otherwise need it just do sharedlib. I'll attach my current spec.
Created attachment 1931154 [details] 22.01 spec
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Looks like I ended up owning this package but this bug didn't get auto-reassigned to me. I'll look into this as soon as I can.
https://src.fedoraproject.org/rpms/lzma-sdk/pull-request/1 until the rpm bug is fixed. If anyone is still interested, please test (on rawhide, it requires setting %__7zip macro to /usr/bin/7za in /usr/lib/rpm/macros).
FEDORA-2023-a41be8fa00 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a41be8fa00
FEDORA-2023-a41be8fa00 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.