@pmatilai: I'm not an expert on OpenSSL. [We were recently contacted by the
RedHat Crypto Team](https://gitlab.com/sequoia-pgp/sequoia/-/issues/1054) (cc:
@simo5, @sahanaprasad07) about a similar change, and they offered to help with
the porting and review. I suspect they'll be willing to take
Ack, thought so. I don't see the version requirement as a problem (being
non-default etc), just that the docs + build require needs updating, which is
done now :+1:
This looks fine to me but then I haven't got the slightest about the openssl
API, would be nice to have someone more familiar wit
OK, turns out this is code based on OpenSSL 3.0 which is from 2021. So it is a
bit new. Otoh it no longer is the default variant to be built and the next
release shouldn't be backported to some ancient enterprise distribution.
--
Reply to this email directly or view it on GitHub:
https://github
@ffesti pushed 1 commit.
32b12aec2d81690f271cd1cde8b8bf72c358229a Move OpenSSL code to newer API from
version 3.0
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2723/files/009daa3ab584b0e271f08d717c19daaa18de3eed..32b12aec2d81690f271cd1cde8b8bf72c358229a
You are rece
When we talk about configuration, what's meant by that? All macro definitions?
Because there seems to be an issue with `/etc/rpm/macros.image-language-conf`
like things.
As you asked for ideas; I think there's a space for a low-level,
distro-specific, rpm-sub-package that would install the di
That sounds good to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2556#issuecomment-1770538607
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
I too quite severely dislike the notion of librpm users caring about the
backend (name) explicitly. Ideally an API user would be handled -ENOTIMPL which
they could then handle the best they see fit, but we don't have such interfaces
at the moment and again would loathe to do new developments for
I support adding an interface for a backend to identify itself. This is useful
for debugging, as you point out.
I'm not so excited about users of librpm changing their behavior based on the
backend's name. If we want to support that (and I'm not convinced that we do),
I'd rather introduce fea
It wouldn't be hard to add some API of course, but I'm loathe to add anything
at all for a thing that's supposed to be going away :thinking:
OTOH maybe we could just have each backend identify itself with an arbitrary
string which could also cover things like the used lower level crypto, eg
"se
Looking again at case and the PR, I do think the rpm behavior to enforce a
uniform output for %x is intentional and sane. The macro arguments exist for
*modifying macro behavior*, not for passing through to other programs, and we
can't allow external program requirements to set the rules for rpm
As per https://www.sqlite.org/wal.html#read_only_databases:
> Even though it is possible to open a read-only WAL-mode database, it is good
> practice to converted to [PRAGMA
> journal_mode=DELETE](https://www.sqlite.org/pragma.html#pragma_journal_mode)
> prior to burning an SQLite database imag
I think this is mostly a matter of documentation to set the expectations
straight, basically:
Rpm is portable within the limitations stated in INSTALL, currently that means
POSIX.1-2008.
The rpm-team only maintains the Linux port, but patches for other platforms can
be accepted.
--
Reply to t
Right, it's fairly obvious that the behavior is wrong.
I just think an attempt to change the default in the spec needs to be an error
instead of just silently changing it, because otherwise parts of the spec will
be dancing to a different tune from the rest of the spec. Which has to be an
error
I don't see us changing the rpm default behavior here, but it may be feasible
to add an option to log the build scriptlet output to a file. For your case you
could set it to /dev/null, and something like mock could perhaps use it to
separate the script stage output from other parts. I'll discuss
Closed #2095 as completed via 3b070507abf1ce0b399d45268015fb76a829be9b.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2095#event-10706307502
You are receiving this because you are subscribed to this thread.
Message ID:
__
15 matches
Mail list logo
