Summary: | app-crypt/johntheripper-1.7.3.1 3rd-party patch update | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | RB <aoz.syn> |
Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | grobian |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
diff against current ebuild
1.7.3.1-r1 full ebuild stackdefs for all-5 cflags patch from prefix updated stackdef.S patch stackdefs for all-5 (v2) |
Description
RB
2009-07-14 14:31:58 UTC
Created attachment 197922 [details, diff]
diff against current ebuild
Created attachment 197924 [details]
1.7.3.1-r1 full ebuild
Created attachment 197925 [details, diff]
stackdefs for all-5
Created attachment 197927 [details, diff]
cflags patch from prefix
Created attachment 197928 [details, diff]
updated stackdef.S patch
Created attachment 201817 [details, diff]
stackdefs for all-5 (v2)
Updated stackdef-all-5 patch, hadn't tested this on an MMX build yet. This bug should be a quick win, updating and knocking out bugs at the same time.
Could you send this patch to upstream? All the attached patches are Gentoo artifacts, and I've actually removed one from Gentoo's normal distribution since it was unnecessary and broke gentoo-prefix (params.h). In a general sense, none of the patches fix anything that's broken, they only force JtR to fit within the Gentoo worldview. The two stackdef.S patches are split from the original single one so they could be applied appropriately (according to USE=minimal). The cflags patch is from gentoo-prefix and could be dropped, but for what it does seems petty to refuse an update for it. To reiterate, I'm only fixing what is already there. I will contact Solar Designer and see whether he's interested in incorporating the sandbox and CFLAG patches, but the upstream release cycle has sufficiently slowed that incorporation in any reasonable timescale is highly unlikely, if he even accepts them. + 03 Sep 2009; Patrick Lauer <patrick@gentoo.org> + +johntheripper-1.7.3.1-r1.ebuild, + +files/johntheripper-1.7.3.1-all-5-stackdef.S.patch, + +files/johntheripper-1.7.3.1-cflags.patch, + files/johntheripper-1.7.3.1-stackdef.S.patch: + Small set of fixes, thanks to RB. Closes #277811 CPP=${CPP} CC=${CC} AS=${AS} LD=${LD} \ - CFLAGS="-c -Wall ${CFLAGS} -DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_HOME=\"\\\"/etc/john\\\"\"" \ + CFLAGS="-c -Wall ${CFLAGS} -DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_HOME=\"\\\"${ROOT}/etc/john\\\"\" -DJOHN_SYSTEMWIDE_EXEC=\"\\\"${ROOT}/usr/libexec/john\\\"\"" \ LDFLAGS="${LDFLAGS}" \ Hardcoding ROOT inside an application really is no good idea. What made you think it? (In reply to comment #10) It's unrelated to this bug. Please file a separate bug. (In reply to comment #10) Anyway we can't use ${ROOT} in src_compile(). maybe I was talking to the original reporter instead? I removed use of ROOT. Apologies; that was an artifact from a path I'd taken to being more Prefix-friendly and forgotten to take out. ah, I see. |