Zbigniew Jędrzejewski-Szmek wrote:
> Heh, that's a cool idea. But that's not how standards work.
> You cannot just insert things at random points in low-level config
> files or protols. How do you think this would work?
> You insert "$tuned_params", I insert "{tuned_params}", and GNU people
> inser
OLD: Fedora-Rawhide-20241116.n.0
NEW: Fedora-Rawhide-20241117.n.0
= SUMMARY =
Added images:8
Dropped images: 0
Added packages: 2
Dropped packages:0
Upgraded packages: 40
Downgraded packages: 0
Size of added packages: 126.46 KiB
Size of dropped packages:0
On Sun, 2024-11-17 at 17:47 -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson said:
> > On Sun, 2024-11-17 at 14:14 -0600, Chris Adams wrote:
> > > Also, there's not a way to test this (e.g. remove the cert.pem symlink
> > > and see what breaks); the change says the speed-up is to use
OLD: Fedora-eln-20241117.n.0
NEW: Fedora-eln-20241118.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 1
Dropped packages:0
Upgraded packages: 4
Downgraded packages: 0
Size of added packages: 484.52 KiB
Size of dropped packages:0 B
Size of
On Sun, 2024-11-17 at 14:14 -0600, Chris Adams wrote:
> Once upon a time, Neal Gompa said:
> > This file has to remain on the system for a completely different
> > reason: other crypto libraries may and do probably use this file. It
> > is unreasonable to delete what essentially is our certificate
Once upon a time, Chris Adams said:
> I thought
> maybe this would be something that can be configured in openssl.cnf, but
> it looks like, when testing with "openssl s_client", it looks for certs
> before reading openssl.cnf (which seems weird to me, but so are lots of
> OpenSSL's ways).
Scratch
Once upon a time, Adam Williamson said:
> On Sun, 2024-11-17 at 14:14 -0600, Chris Adams wrote:
> > Also, there's not a way to test this (e.g. remove the cert.pem symlink
> > and see what breaks); the change says the speed-up is to use the
> > directory-hash format by default... but there's no has
Hey!
I've just reviewed this. Could you please review any of these?
* https://bugzilla.redhat.com/2324138 python-eth-rlp - RLP definitions
for common Ethereum objects in Python
* https://bugzilla.redhat.com/2324137 python-eth-keyfile - Tools for
handling the encrypted keyfile format used to store
Adam Williamson wrote:
> specifically, for releases past the Beta freeze point, *all* updates
> require +2 karma to be pushed stable before the minimum wait. That is,
> if you want your non-critpath update to go stable sooner than 7 days
> after it reached testing, it needs +2 karma. For critpath,
Kevin Kofler via devel wrote:
> When was this decided? I only remember FESCo ever having decided to
> require +2 for critpath updates, not for non-critpath ones.
>
> At some point, those values were written down in the documentation, but
> under what authority? Where was the FESCo decision for tha
Kevin Kofler via devel wrote:
> PS: I suspect the documentation was actually just an attempt to document
> the previous broken Bodhi policy implementation. (See
> https://github.com/fedora-infra/bodhi/issues/772 and
> https://github.com/fedora-infra/bodhi/issues/1033 – both got closed, but
> the is
On Sun, 2024-11-17 at 18:35 +0100, Kevin Kofler via devel wrote:
> Kevin Kofler via devel wrote:
> > PS: I suspect the documentation was actually just an attempt to document
> > the previous broken Bodhi policy implementation. (See
> > https://github.com/fedora-infra/bodhi/issues/772 and
> > https:
Hi
I've posted a review for python-flask-sqlalchemy-light, which I need to
update python-flask-security-too.
The review is here: https://bugzilla.redhat.com/show_bug.cgi?id=2326830
Happy to review in exchange.
Thanks
Sandro
--
___
devel mailing li
Adam Williamson wrote:
> The situation in the old code was actually rather more complicated, and
> weird, than "the non-settable threshold was fixed to the wrong value" -
> there were multiple check functions that applied different logic to
> different operations, which is why you could sometimes p
On Sun, 2024-11-17 at 10:12 -0800, Adam Williamson wrote:
>
> So on the whole, I think you have a good point here, thanks for raising
> it. I will file a FESCo ticket and ask for them to consider the history
> here and decide if they want to make any changes based on this
> evaluation.
Filed http
Björn Persson wrote:
>> == Release Notes ==
>> The /etc/pki/tls/cert.pem file has been deprecated
>
> Removed, not deprecated, according to the rest of the proposal.
> Sysadmins who read "deprecated" in the release notes will think they
> can upgrade Fedora and look into migrating off /etc/pki/tls
On Sun, Nov 17, 2024 at 2:04 PM Kevin Kofler via devel
wrote:
>
> Björn Persson wrote:
> >> == Release Notes ==
> >> The /etc/pki/tls/cert.pem file has been deprecated
> >
> > Removed, not deprecated, according to the rest of the proposal.
> > Sysadmins who read "deprecated" in the release notes w
On Sun, 2024-11-17 at 19:36 +0100, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > The situation in the old code was actually rather more complicated, and
> > weird, than "the non-settable threshold was fixed to the wrong value" -
> > there were multiple check functions that applied diff
Once upon a time, Neal Gompa said:
> This file has to remain on the system for a completely different
> reason: other crypto libraries may and do probably use this file. It
> is unreasonable to delete what essentially is our certificate store
> API without going through and fixing *all* crypto lib
19 matches
Mail list logo
