Overview
Request 1153038 superseded
- dd_rescue-ossl3-evpcipherctx.diff: There's an additional field
in the (private) struct _evp_cipher_ctx_st in openssl-3 since
3.0.6, which makes a difference on 32bit. (On 64bit, the effect
is hidden by the compiler's alignment rules.)
- Specify libopenssl-devel as BuildRequirements. This will select
openssl-3 on new distributions.
- Created by garloff
- In state superseded
-
Package maintainer:
garloff
- Superseded by 1153114
Request History
garloff created request
- dd_rescue-ossl3-evpcipherctx.diff: There's an additional field
in the (private) struct _evp_cipher_ctx_st in openssl-3 since
3.0.6, which makes a difference on 32bit. (On 64bit, the effect
is hidden by the compiler's alignment rules.)
- Specify libopenssl-devel as BuildRequirements. This will select
openssl-3 on new distributions.
- Fix openssl version detection for 3.0.x.
- dd_rescue-ossl3-evpcipherctx.diff: There's an additional field
in the (private) struct _evp_cipher_ctx_st in openssl-3 since
3.0.6, which makes a difference on 32bit. (On 64bit, the effect
is hidden by the compiler's alignment rules.)
- Specify libopenssl-devel as BuildRequirements. This will select
openssl-3 on new distributions.
Sidenote: I never understood why the build macro improvements are not backported to old SLES versions (here: SLESE12SP5), making it simple for new packages to be built on old distros. dd_rescue would happily compile on old distros, but here we see SLES12SP5 fail, which I can only ignore. (I keep some more spec file magic in my own build service project, but I understand that this is unwanted on Factory.)
Another sidenote: It looks to me like I can approve this SR myself, despite being the author. Is it because I happen to be maintainer? I guess it's still best practice to follow the four eyes principle and wait for someone else to approve (except for cases of emergency)?