Description of problem: p7zip 16.02 available in Fedora is quite old - the first RPM is dated to Mon Jul 18 2016. The original p7zip project [1] is no longer updated ("Last Update: 2016-07-14"). The security fixes seem to be backported to the RPM package (thanks!), however, on the official 7-zip project page there is a new fork mentioned which is updated to 17.02 (last p7zip release 2020-06-20). While it is not 19.x, maybe it would be worth to evaluate it as a new upstream for Fedora packages? [1] - https://sourceforge.net/projects/p7zip/ [2] - https://www.7-zip.org/links.html [3] - https://github.com/szcnick/p7zip
no problem , are you a Fedora package maintainer ? have a patch or a pull request ?
Are you a Fedora packager maintainer ? if yes I can add you as co-maintainer
*** Bug 1898710 has been marked as a duplicate of this bug. ***
I'm not a package maintainer. To be honest, I've just some limited knowledge relating builds for fedora/x86_64, non for other platforms. It's understandable, that the issue is not on your priority-list due to other tasks and/or stuff. If tried to look into this and here are my conclusions: * build-system didn't change much, ninja-build now required, building on fedora/x86_64 * patches: CVEs [included], gcc10 [included], hardening [missing] (currently broken anyway), noRAR [missing], DOCS [missing] * my opinion: no need for the DOCS patches anyway The build scripts are wonky and with current hardening patch the executables are not position independent and there's no immediate binding. Something, that seems to work for proper hardening options: sed -i 's|CFLAGS=-c |CFLAGS=%{build_cflags} -c |' makefile.glb sed -i 's|CXXFLAGS=-c |CXXFLAGS=%{build_cxxflags} -c |' makefile.glb OPTFLAGS=$(echo "%{optflags} -fPIE %{build_ldflags}") export OPTFLAGS ... and set OPTFLAGS="$OPTFLAGS" when running %make_build Maybe, it's helpful at some point.
@Sergio yes, I am a Fedora package maintainer, however, I currently have a few packages on my own and most likely - due to time concerts and lack of C/C++ practice in the recent decade - I would not be able to fulfill my duties as a co-maintainer of p7zip duly. Therefore, please, treat the original request as an informational only.
(In reply to samoht0 from comment #5) > I'm not a package maintainer. To be honest, I've just some limited knowledge > relating builds for fedora/x86_64, non for other platforms. It's > understandable, that the issue is not on your priority-list due to other > tasks and/or stuff. > > If tried to look into this and here are my conclusions: > * build-system didn't change much, ninja-build now required, building on > fedora/x86_64 > * patches: CVEs [included], gcc10 [included], hardening [missing] (currently > broken anyway), noRAR [missing], DOCS [missing] > * my opinion: no need for the DOCS patches anyway > > The build scripts are wonky and with current hardening patch the executables > are not position independent and there's no immediate binding. > > Something, that seems to work for proper hardening options: > > sed -i 's|CFLAGS=-c |CFLAGS=%{build_cflags} -c |' makefile.glb > sed -i 's|CXXFLAGS=-c |CXXFLAGS=%{build_cxxflags} -c |' makefile.glb > OPTFLAGS=$(echo "%{optflags} -fPIE %{build_ldflags}") > export OPTFLAGS > ... and set OPTFLAGS="$OPTFLAGS" when running %make_build > > Maybe, it's helpful at some point. yes this is useful , if you send to me an pull request or add here the new p7zip.spec , it is very welcome
Well, I've put things together. But there quiet some things, that didn't work out and I can't fix. * building commandline tools works on x86_64 i386 aarch64 armhfp with norar-patch and added PIE / linker flags * building GUI fails, no missing dependencies according to cmake, commented out with #GUI# as removing %bcond_with gui didn't work for me (DROP?) * manual patches do no apply, commented out (DROP?) * RAR test generally fails (expected), commented out * WIM (Windows Image) test generally fails (untested in 16.02), unclear if missing support is intended by norar-patch, commented out * 7zip ZSTD test (creating 7za433_7zip_zstd.7z) fails on i386 armhfp, added sources probably unsuitable for 32-bit (DROP?) * unclear fail while creating debug source packages (NEEDED?) Spec from ALT Linux doesn't help. They do not build GUI, not patch man, not test the binaries and not create debug packages. Debian packages are still 16.02...
Created attachment 1732016 [details] Edited Spec
Created attachment 1732017 [details] ALT Linux Spec
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
I have just seen that the creator of 7-Zip has released a new version: 21.01 alpha. There seems to be an important change: What's new after 7-Zip 21.00 alpha: The command line version of 7-Zip for Linux was released. URL: https://sourceforge.net/p/sevenzip/discussion/45797/thread/d401ab2966/ Might it be worth to evaluate to switch to the official 7z release?
And some more information given for the Linux build of 7z: https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
(In reply to JayJayJazz from comment #13) > And some more information given for the Linux build of 7z: > https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/ no source code https://github.com/jinfeihan57/p7zip/issues/114#issuecomment-796833759
7-Zip sources with Linux support are released https://sourceforge.net/p/sevenzip/discussion/45797/thread/7fe6c21efa/
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
F36 as well as rawride seems to still provide 16.02.
*** This bug has been marked as a duplicate of bug 1946988 ***