packages
packages copied to clipboard
nmap: bump to 7.94 release + PCRE2
Maintainer: @nunojpg
Bump nmap to 7.94 release and drop upstreamed patch. Also backport patch for PCRE2.
Signed-off-by: Christian Marangi [email protected]
@BKPepe
Depends on https://github.com/openwrt/packages/pull/22722
(test fails due to funny patch repository that have mixed line ending and other kind of stuff... a refresh doesn't seems to fix these warning)
Yea, the patch is huge, I can not even review it on GItHub site, because:
126,500 additions, 0 deletions not shown because the diff is too large. Please use a local Git client to view these changes.
haha. 😆
Yep it's big... the only change i did to the original was comment a file delete (again line ending problem) but that is not used in compiling this package so it's just an additional zombie file in the build_dir.
how was this patch generated. git-format-patch or github.com download?
format-patch but I also verified that github .patch produce the same exact patch
I assume the fix here is to use some combination of
-a
--text
Treat all files as text.
--ignore-cr-at-eol
Ignore carriage-return at the end of line when doing a comparison.
--ignore-space-at-eol
Ignore changes in whitespace at EOL.
-b
--ignore-space-change
Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
-w
--ignore-all-space
Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.
when generating. or maybe git's autocrlf is taking effect here.
@neheb problem is that those are option to apply the patch not to generate one... not really in the mood to tweak how we apply patch and fix this
one way to avoid this is to add a Build/Prepare and download the patch there instead of having it in a patch directory.
one way to avoid this is to add a Build/Prepare and download the patch there instead of having it in a patch directory.
it's really just a big workaround to make the test happy... Is it worth it?
Sure. It'll be gone next version anyway.
So you want to bundle in packages git a 4MB blob? You know it will stay forever in git history?
on that note, arch linux PKGBUILD files typically have routines to download and apply patches. See https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-libimobiledevice/PKGBUILD#L17C1-L17C132 as an example. Maybe such a thing should be implemented here.
Didn't notice it was a 4mb patch :/ well then... we have to wait for a new release... OR @BKPepe we can consider moving to using git source instead of release and target that commit... It's really a taste of choice. But I think the idea is to make everything possible to drop pcre right?
we are not that "in hurry", what about waiting for next release?
I think we should split your PR into two ones.
- bump to 7.94 - no objections in this PR as I see, so it can be merged as it is.
- PCRE2 - okay, adding a large patch is no go. Thus only, what I am thinking is that we can change it to use the latest commit in the master branch. Even though, I don't like using commits in the master branch, because once you forget to update it, then you will be using it also in the stable branches, which means basically no support for upstream developers. However, in the meantime, we can let the OpenWrt community know and ask them for help to test nmap with PCRE2.
@BKPepe should we target latest commit or only till the pcre2 merge?
I would suggest only till pcre2 merge.
@BKPepe well nmap is a very bad beast to tackle...
- bump to 7.94 is not trivial... nmap-full fails to compile as they bumped lua requirement to lua 5.4 (and we have only lua and lua5.3...) (I can try to add support for lua5.4 but the shared library patch is not trivial)
- we can introduce a patch that reverts to lua 5.3 but such patch is almost 1mb of size (with the revert 7.94 nmap-full seems to compile correctly) (patch require some part to be dropped so it's not totally 1:1)
- first test with using commit for pcre2 are not so happy with using commit but it's late and I need to investigate it further
Anyway the lua problem is something we would have encountered anyway on bumping the package to a new nmap release that supported pcre2 by default...
@BKPepe good news!
lau5.4 is a thing... with that in and using the commit that introduce pcre2 nmap compile correctly!
@BKPepe this is ready... the formalities check fails because of lua5.4 not correctly detected as a good tag.
Shouldn't you take Lua 5.4 into a separate PR?
@nunojpg yep i can if required. Just lazy. @BKPepe any hint?
I split the lua part of this pr to a separate pr
Great! :) I will look at it hopefully this week.
Changes:
1st FP:
- removed leftovers from resolving merge conflict in the 1st commit (the 1st commit have <<HEAD, etc., the 2nd commit removed it), now it is as it should be
- added nmap update to version 7.95, released a few days ago 2nd FP:
- rebased on top of the master branch
@BKPepe i think we can just drop the intermediate commit?
We can keep it. Its up to you. :) I dont see why it should not be there.
I will refresh the patch shortly
@BKPepe eh it does keep track of when pcre2 support was introduced... lets keep it.
It seems 7.95 have something wrong... will repro it locally.
@BKPepe fixed :D Patch submitted upstream so it will eventually be dropped...