Re: PSA: tuned breaks boot loader entries for systemd-boot
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
> insert "@TUNED_PARAMS@", all because the spec didn't say that's
> forbidden?
Unfortunately, that is exactly how standards work in the real world. Pretty
much any standardized language has dialects with incompatible extensions.
Sometimes even explicitly ignoring a rule in the standard that forbids an
extension at this place (and if you are lucky, the implementation providing
an off-by-default flag to actually enforce that rule, flag which may or may
not work reliably). Expecting any particular implementation to actually
strictly conform to a standard and to always flag all non-strictly-
conforming input is not a realistic expectation.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20241117.n.0 changes
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 B Size of upgraded packages: 3.70 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 150.44 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite ociarchive ppc64le Path: Kinoite/ppc64le/images/Fedora-Kinoite-ppc64le-Rawhide.20241117.n.0.ociarchive Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20241117.n.0.iso Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20241117.n.0.x86_64.vagrant-virtualbox.box Image: Silverblue ociarchive ppc64le Path: Silverblue/ppc64le/images/Fedora-Silverblue-ppc64le-Rawhide.20241117.n.0.ociarchive Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20241117.n.0.x86_64.vagrant-libvirt.box Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20241117.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20241117.n.0.iso Image: Sericea ociarchive aarch64 Path: Sericea/aarch64/images/Fedora-Sericea-aarch64-Rawhide.20241117.n.0.ociarchive = DROPPED IMAGES = = ADDED PACKAGES = Package: conflict-20240429-1.fc42 Summary: Check for conflicting binary names on path RPMs:conflict Size:95.72 KiB Package: rust-derive_utils-0.14.2-1.fc42 Summary: Procedural macro helper for easily writing derive macros for enums RPMs:rust-derive_utils+default-devel rust-derive_utils-devel Size:30.75 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alexandria-0.7.9-9.fc42 Old package: alexandria-0.7.9-8.fc41 Summary: Book collection manager RPMs: alexandria Size: 2.38 MiB Size change: -154 B Changelog: * Sat Nov 16 2024 Mamoru TASAKA - 0.7.9-9 - Add missing syck file import (bug 2326632) Package: aquamarine-0.5.0-3.fc42 Old package: aquamarine-0.4.4-1.fc42 Summary: A very light linux rendering backend library RPMs: aquamarine aquamarine-devel Size: 1.51 MiB Size change: 19.54 KiB Changelog: * Sat Nov 16 2024 Jannik M??ller - 0.5.0-1 - Update to 0.5.0 * Sat Nov 16 2024 Jannik M??ller - 0.5.0-2 - Update to 0.5.0 * Sat Nov 16 2024 Jannik M??ller - 0.5.0-3 - Update to 0.5.0 - Address changed SOVERSION Package: contractor-0.3.5-21.fc42 Old package: contractor-0.3.5-19.fc42 Summary: Desktop-wide extension service RPMs: contractor Size: 185.18 KiB Size change: -25 B Changelog: * Sat Nov 16 2024 Benjamin A. Beasley - 0.3.5-21 - Install into libexec dir. instead of bin dir. Package: corectrl-1.4.3-1.fc42 Old package: corectrl-1.4.1-3.fc41 Summary: Friendly hardware control RPMs: corectrl Size: 3.48 MiB Size change: 15.76 KiB Changelog: * Wed Aug 28 2024 Miroslav Such?? - 1.4.1-4 - convert license to SPDX * Sat Nov 16 2024 Packit - 1.4.3-1 - Update to 1.4.3 upstream release - Resolves: rhbz#2312839 Package: dotnet9.0-9.0.100-1.fc42 Old package: dotnet9.0-9.0.100~rc.2.24474.1-0.13.fc42 Summary: .NET Runtime and SDK RPMs: aspnetcore-runtime-9.0 aspnetcore-runtime-dbg-9.0 aspnetcore-targeting-pack-9.0 dotnet-apphost-pack-9.0 dotnet-host dotnet-hostfxr-9.0 dotnet-runtime-9.0 dotnet-runtime-dbg-9.0 dotnet-sdk-9.0 dotnet-sdk-9.0-source-built-artifacts dotnet-sdk-aot-9.0 dotnet-sdk-dbg-9.0 dotnet-targeting-pack-9.0 dotnet-templates-9.0 netstandard-targeting-pack-2.1 Size: 2.63 GiB Size change: 20.76 MiB Changelog: * Tue Nov 12 2024 Omair Majid - 9.0.100-1 - Update to .NET SDK 9.0.100 and Runtime 9.0.0 Package: firefox-132.0.2-1.fc42 Old package: firefox-132.0.1-2.fc42 Summary: Mozilla Firefox Web browser RPMs: firefox firefox-langpacks Size: 482.59 MiB Size change: 120.99 MiB Changelog: * Fri Nov 15 2024 Martin Stransky - 132.0.2-1 - Updated to 132.0.2 - Try to reduce build mem usage on ppc64le Package: fzf-0.56.3-1.fc42 Old package: fzf-0.56.0-1.fc42 Summary: A command-line fuzzy finder written in Go RPMs: fzf Size: 5.78 MiB Size change: 10.31 KiB Changelog: * Sun Nov 17 2024 Elliott Sales de Andrade - 0.56.3-1 - Update to latest version (#2325249) Package: gimp-fourier-plugin-0.4.5^20241109git29697b2-3.fc42 Old package: gimp-fourier-plugin-0.4.5^20241010git29d3400-3.fc42 Summary: Do direct and reverse Fourier Transforms on your image RPMs: gimp-fourier-plugin Size: 83.04 KiB Size change: 1.19 KiB Changelog: * Sat Nov 16 2024 Benjamin A
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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 the > > > directory-hash format by default... but there's no hashes in > > > /etc/pki/tls/certs. Something needs to be managing those hashes > > > (creating, updating, deleting stale) BEFORE the bundle can be > > > > There are hashes there on my system. They're symlinks to /etc/pki/ca- > > trust/extracted/pem/directory-hash. Both ends of the symlink are owned > > by ca-certificates; I believe the symlinks are set up by its > > scriptlets. > > Hmm, I checked both a system that had Fedora 41 freshly installed and > some systems that were upgraded from Fedora 39 to Fedora 41, and all I > have in /etc/pki/tls/certs is ca-bundle.crt and ca-bundle.trust.crt > symlinks. > > Would it be practical to just configure OpenSSL to use a different > (empty) location for cert.pem, rather than deleting the file? 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). No, it's not runtime configurable AFAIK, and you cannot configure the paths to the cert file and hash dir separately. You specify a single directory at compile time, and it looks there for both. > It also seems backwards to read the full file and THEN look for a hash; > seems like if the hash is intended to be faster, reversing that would be > better anyway. The problem is we have to do this in the code, and it's hard to get anyone to want to touch this as it's sensitive and it's been the way it's been forever. Carrying a downstream patch forever doesn't seem great either. But I would be in favor of this option on the whole, personally. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora eln compose report: 20241118.n.0 changes
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 upgraded packages: 29.63 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -47.94 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: openjph-0.18.0-1.eln143 Summary: Open-source implementation of JPEG2000 Part-15 (or JPH or HTJ2K) RPMs:libopenjph Size:484.52 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: kwin-6.2.3-2.eln143 Old package: kwin-6.2.3-1.eln143 Summary: KDE Window manager RPMs: kwin kwin-common kwin-libs kwin-wayland Size: 26.52 MiB Size change: -26.41 KiB Changelog: * Sun Nov 17 2024 Alessandro Astone - 6.2.3-2 - Backport fix for keyboard focus after using the task switcher https://bugs.kde.org/show_bug.cgi?id=495844 https://bugs.kde.org/show_bug.cgi?id=491398 Package: libheif-1.19.3-3.eln143 Old package: libheif-1.19.3-1.eln143 Summary: HEIF and AVIF file format decoder and encoder RPMs: libheif Size: 1.81 MiB Size change: -25.34 KiB Changelog: * Sat Nov 16 2024 S??rgio Basto - 1.19.3-2 - Add support to multilib in devel sub-package - Resolves: rhbz#2279891 * Sun Nov 17 2024 Dominik Mierzejewski - 1.19.3-3 - disable OpenJPH encoder support to work-around crashes Package: python-websockets-14.1-1.eln143 Old package: python-websockets-14.0-1.eln143 Summary: Implementation of the WebSocket Protocol for Python RPMs: python3-websockets Size: 1.14 MiB Size change: 3.79 KiB Changelog: * Sun Nov 17 2024 Fabian Affolter - 14.1-1 - Update to latest upstream release (closes rhbz#2314017) Package: rubygem-rspec-core-3.13.2-4.eln143 Old package: rubygem-rspec-core-3.13.2-3.eln143 Summary: RSpec runner and formatters RPMs: rubygem-rspec-core Size: 163.27 KiB Size change: 15 B Changelog: * Sun Nov 17 2024 Mamoru TASAKA - 3.13.2-4 - Workaround syntax_suggest 2.0.2 change = DOWNGRADED PACKAGES = -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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 store > > API without going through and fixing *all* crypto libraries and > > applications that directly load the CA store themselves to work with > > it upstream. > > Yeah, there's nothing that says "this file is for OpenSSL's internal use > only". I know I've written code that references it. It's /etc/pki/tls, > not /etc/openssl-private-nobody-else-use; it gives all appearances of > being a shared file. On the whole, no, no other major crypto library relies on it that I'm aware of. nss uses its own stuff. gnutls *can* use the file at that location, but it's just one in a big list of candidates and it doesn't actually use it on Fedora. I started poking through references to the file on github a while ago and didn't yet find any significant ones that would not be OK somehow (it's usually referenced as part of a big list of candidates, and some other item on the list would still be present on Fedora if this location were removed). > > 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 hashes in > /etc/pki/tls/certs. Something needs to be managing those hashes > (creating, updating, deleting stale) BEFORE the bundle can be There are hashes there on my system. They're symlinks to /etc/pki/ca- trust/extracted/pem/directory-hash. Both ends of the symlink are owned by ca-certificates; I believe the symlinks are set up by its scriptlets. > > If the hashes directory (once populated) is also going to be considered > OpenSSL-only, it should be moved out from under /etc/pki/tls into a > directory that is obviously OpenSSL-only. The hashes actually live elsewhere (as per above), but changing our OPENSSLDIR on Fedora after like 20 years would be a huge change and probably not a great idea for all the reasons people are worried about doing *this*. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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 that... I accidentally had sort in my output. Dumb me. So still: is the cert.pem location configurable in openssl.cnf? Then it could just be pointed at something that doesn't exist by default. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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 hashes in > > /etc/pki/tls/certs. Something needs to be managing those hashes > > (creating, updating, deleting stale) BEFORE the bundle can be > > There are hashes there on my system. They're symlinks to /etc/pki/ca- > trust/extracted/pem/directory-hash. Both ends of the symlink are owned > by ca-certificates; I believe the symlinks are set up by its > scriptlets. Hmm, I checked both a system that had Fedora 41 freshly installed and some systems that were upgraded from Fedora 39 to Fedora 41, and all I have in /etc/pki/tls/certs is ca-bundle.crt and ca-bundle.trust.crt symlinks. Would it be practical to just configure OpenSSL to use a different (empty) location for cert.pem, rather than deleting the file? 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). It also seems backwards to read the full file and THEN look for a hash; seems like if the hash is intended to be faster, reversing that would be better anyway. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review request: python-flask-sqlalchemy-light
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 private keys * https://bugzilla.redhat.com/2324136 python-trie - Library which implements the Ethereum Trie structure On Sun, Nov 17, 2024 at 4:22 PM Sandro Mani wrote: > > 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 list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- With best regards, Peter Lemenkov. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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, if you want > it to go stable sooner than 14 days after it reached testing, it needs > +2 karma. 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 that? This is yet another worsening of already painful red tape preventing urgent updates (security updates, regression fixes, fixes for completely broken packages, etc.) from going out in a timely manner. (All those are cases where the best thing to do would actually be to send them directly to stable, which Bodhi has not allowed for years now.) It is hard enough to get even 1 karma for Fedora n-1 releases, let alone 2. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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 that? 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 issue was never properly fixed.) So now instead of resolving the inconsistency to the more liberal policy (requiring only +1 for both manual and automatic pushes), AFAIK matching what FESCo actually decided, and either way having the lowest practical impact (because it would not have allowed anything that was not previously allowed), it was instead decided to resolve it the strict way (requiring +2 in both cases), making policy with no FESCo decision. All that because of documentation that was faulty because it was matching a Bodhi bug. Please fix both Bodhi and the documentation to match what was actually decided by FESCo, or point us to the FESCo decision that proves that the current code and documentation does that (because I believe it does not). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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 issue was never properly fixed.) PPS: Sorry, one more thing, I have to correct myself: Actually, the issue was eventually fixed in that Bodhi has at some point started allowing to set the stable threshold even when unchecking the autopush checkbox, so it was possible before 8.2 to manually push updates to stable at +1. Though I still do not understand how a threshold makes any sense at all for manual pushes. Manual pushes should just always require only the minimum required by policy, as the person setting the threshold (to any allowed value) is the same as the one doing the push. Settable thresholds have only ever made sense for automatic pushes. (So the bug was not that the threshold was not settable for manual pushes, but that the non-settable threshold was fixed to the wrong value, the default for automatic pushes (+3) instead of the minimum allowed (+1). Which is why I still do not consider this properly fixed.) Still, somehow a +2 threshold made its way into the documentation, and I am still wondering on what base that was encoded there. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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://github.com/fedora-infra/bodhi/issues/1033 – both got closed, but > > the issue was never properly fixed.) > > PPS: Sorry, one more thing, I have to correct myself: > > Actually, the issue was eventually fixed in that Bodhi has at some point > started allowing to set the stable threshold even when unchecking the > autopush checkbox, so it was possible before 8.2 to manually push updates to > stable at +1. > Though I still do not understand how a threshold makes any sense at all for > manual pushes. Manual pushes should just always require only the minimum > required by policy, as the person setting the threshold (to any allowed > value) is the same as the one doing the push. > > Settable thresholds have only ever made sense for automatic pushes. (So the > bug was not that the threshold was not settable for manual pushes, but that > the non-settable threshold was fixed to the wrong value, the default for > automatic pushes (+3) instead of the minimum allowed (+1). Which is why I > still do not consider this properly fixed.) Yes, to be clear, in rewriting this code, I had the same opinion as you. The configurable thresholds only make sense as applying to autopush. There is no reason I can see to consider them as applying to manual push. To me, as to you, the only constraint on manual push that makes sense is a policy minimum karma for manual pushes, which naturally cannot be edited. As rewritten, the minimum requirements for manual push are different concepts from the autopush thresholds and are now more clearly defined as such in Bodhi's code. The per-update editable thresholds now clearly (in the code) have absolutely no input into the decision as to whether an update can be manually pushed stable. Whatever those thresholds are set to, if the update meets the currently-configured policy minimum requirements for stable push (and any gating requirements), it can be pushed; if not, it can't. You can verify that in the code, if you like. So I think your 'issue' as you describe it above is addressed in 8.2. 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 push something via the CLI that you could not push via the web UI, for e.g. > Still, somehow a +2 threshold made its way into the documentation, and I am > still wondering on what base that was encoded there. That is in fact an interesting question, now I dig into it. Zbigniew seems to have done substantial rewrites on the karma requirements in 2021. These were: https://pagure.io/fesco/fesco-docs/c/e57f002ee55810d1636e4460fe0d2c3515897c0b?branch=main https://pagure.io/fesco/fesco-docs/c/19bf26cef5d5e2a8d744ea28d8d54ec5374112e9?branch=main https://pagure.io/fesco/fesco-docs/c/33c510e462f0b4118a716a89315f6afef6f5354c?branch=main The "some more" in the first commit description refers to 997bd212d760f223ecaa98cbc5e020ad35754b01 by Kevin, which made substantial updates to the policy but did not change the karma stuff AFAICS. As of that commit, these were the requirements: u-t activation to Beta release: critpath: "*MUST* either get one +1 karma *OR* spend at least 14 days in updates-testing and have no negative karma" non-critpath: "*MUST* either reach the prescribed karma level for that update *OR* spend at least 3 days in updates-testing" Beta to Final: critpath: "*MUST* either have a sum of +2 karma *OR* spend at least 14 days in updates-testing and have no negative karma" non-critpath: "*MUST* either reach the prescribed karma level for that update *OR* spend at least 7 days in updates-testing" After Final: critpath: "needs to have either a Bodhi karma sum of 2 *OR* It must spend at least 14 days in updates-testing *AND* have no negative Bodhi karma points" non-critpath: "*MUST* either [reach the critpath requirements] *OR* reach the positive Bodhi karma threshold specified by the updates submitter *OR* spend some minimum amount of time in updates-testing, currently one week" The "after Final" and "Beta to Final" requirements are effectively the same, just written differently. At this point, we don't actually have any explicit minimum karma requirement for non-critpath updates; it's phrased as "reach the prescribed karma level for that update", which you and I have both noted doesn't really make any sense, and is dependent on the behavior of the tool. *Effectively*, given Bodhi's behavior at this point, this more or less meant the minimum was 1. After Zbigniew's first commit, they looked like this: "* The update becomes eli
Review request: python-flask-sqlalchemy-light
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 list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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 push something > via the CLI that you could not push via the web UI, for e.g. Indeed, and I believe this is actually the explanation for the following: > *This* is the point at which a minimum of +2 was introduced for non- > critpath updates (after Beta freeze). The commit message does not > reference any FESCo decision. It says "This matches what bodhi seems to > implement and the text before my changes said", but I don't believe > either of those things is accurate: it does not really match what the > text before his changes said (it did not clearly prescribe +2 for non- > critpath), and it does not really match old Bodhi behaviour (which was > weird and inconsistent, but *could* be made to push a non-critpath > update with only +1 karma). In fact, I vaguely recall that some version(s) of Bodhi had a hardcoded check that would mark any update as approved for manual push when the hardcoded minimum requirements for critpath were met. As a result, if, for an update, the default stable threshold of +3 was not changed (or if a higher threshold was set), Bodhi would actually have marked the update as approved at +2 because of the hardcoded check. So that is where the +2 probably came from. So it is a combination of multiple Bodhi glitches that ended up accidentally encoded in the documentation and now made it back into Bodhi in a strict reinterpretation. I think it kinda makes critpath pointless if we now require the same +2 threshold for all updates. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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 https://pagure.io/fesco/issue/3289 . -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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/cert.pem > later. They will feel deceived when their in-house software breaks > right away. I agree, but I think the terminology is the least of the problems here. I think this file must remain on the file system and OpenSSL needs to be patched to ignore it if it has a more efficient alternative, as was in fact already suggested in the discussion of the change (but refused by the change owners). Backwards compatibility is something that needs to be retained wherever possible. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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 will think they > > can upgrade Fedora and look into migrating off /etc/pki/tls/cert.pem > > later. They will feel deceived when their in-house software breaks > > right away. > > I agree, but I think the terminology is the least of the problems here. > > I think this file must remain on the file system and OpenSSL needs to be > patched to ignore it if it has a more efficient alternative, as was in fact > already suggested in the discussion of the change (but refused by the change > owners). Backwards compatibility is something that needs to be retained > wherever possible. > 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 libraries and applications that directly load the CA store themselves to work with it upstream. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi 8.2 in production: changes to karma requirements
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 different logic to > > different operations, which is why you could sometimes push something > > via the CLI that you could not push via the web UI, for e.g. > > Indeed, and I believe this is actually the explanation for the following: > > > *This* is the point at which a minimum of +2 was introduced for non- > > critpath updates (after Beta freeze). The commit message does not > > reference any FESCo decision. It says "This matches what bodhi seems to > > implement and the text before my changes said", but I don't believe > > either of those things is accurate: it does not really match what the > > text before his changes said (it did not clearly prescribe +2 for non- > > critpath), and it does not really match old Bodhi behaviour (which was > > weird and inconsistent, but *could* be made to push a non-critpath > > update with only +1 karma). > > In fact, I vaguely recall that some version(s) of Bodhi had a hardcoded > check that would mark any update as approved for manual push when the > hardcoded minimum requirements for critpath were met. As a result, if, for > an update, the default stable threshold of +3 was not changed (or if a > higher threshold was set), Bodhi would actually have marked the update as > approved at +2 because of the hardcoded check. So that is where the +2 > probably came from. > > So it is a combination of multiple Bodhi glitches that ended up accidentally > encoded in the documentation and now made it back into Bodhi in a strict > reinterpretation. It was even weirder than that, but yeah, that was one part of it (part of *one* of the check flows in old Bodhi went "first apply the critpath requirements, then if the update isn't critpath, apply some alternative requirements"). In general, though, I'd say there were various ways old-Bodhi could make it *look* like you couldn't push a non-critpath update with only +1 karma, but in fact you always *could*, one way or another (the CLI was the most reliable way). > I think it kinda makes critpath pointless if we now require the same +2 > threshold for all updates. Indeed, the only practical difference between critpath and non-critpath in the current policy is the minimum wait times after Beta freeze (7 days for non-critpath, 14 days for critpath). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: dropping Of cert.pem file (System-Wide)
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 libraries and > applications that directly load the CA store themselves to work with > it upstream. Yeah, there's nothing that says "this file is for OpenSSL's internal use only". I know I've written code that references it. It's /etc/pki/tls, not /etc/openssl-private-nobody-else-use; it gives all appearances of being a shared file. 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 hashes in /etc/pki/tls/certs. Something needs to be managing those hashes (creating, updating, deleting stale) BEFORE the bundle can be deprecated. If the hashes directory (once populated) is also going to be considered OpenSSL-only, it should be moved out from under /etc/pki/tls into a directory that is obviously OpenSSL-only. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
