Re: F39 proposal: Register EC2 Cloud Images with uefi-preferred AMI flag (Self-Contained Change proposal)
Ben Cotton writes: > https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > A new feature of EC2 is to be able to register AMIs with a boot mode > of `uefi-preferred` rather than picking one of `bios` or `uefi`. In > EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS > only and some instance types have recently begun to support booting in > UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With > `uefi-preferred` it allows an AMI to launch with whatever firmware > stack is available for the instance type, preferring UEFI when UEFI is > an option. > > This proposal is to register the Fedora EC2 images with > `uefi-preferred`, having the effect of switching to booting in UEFI > mode on x86-64 in EC2 where available. > > == Owner == > * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] > * Email: traw...@amazon.com > > > == Detailed Description == > Some features of some EC2 instance types (such as secure boot) are > only available in UEFI mode. There is also the standard set of > advantages of UEFI over BIOS. All aarch64 instance types in EC2 have > always been UEFI, while all x86-64 instance types were historically > all BIOS. Recently, some x86-64 instance types have started to support > UEFI mode. This was originally implemented as an option for instance > launches and AMI registration. An AMI could state that it should be > booted in UEFI mode. An AMI registered for UEFI would *not* boot on > BIOS-only instance types. This meant that if you wanted to make > available an OS that could boot on all instance types, you'd need a > trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI. > > With the `uefi-preferred` boot mode, one AMI registered for x86-64 > will boot on UEFI where possible, but also boot BIOS if the instance > type doesn't support UEFI. > > By registering Fedora AMIs with this boot mode, EC2 features that > require UEFI (such as Secure Boot and NitroTPM) will be able to be > used in Fedora, while still maintaining compatibility with BIOS only > instance types. > > == Feedback == > We have started registering Amazon Linux 2023 AMIs with this boot > mode, albeit quite late in the development cycle of AL2023 due to the > timing of when the `uefi-preferred` boot mode flag was added to EC2. > > == Benefit to Fedora == > UEFI is becoming more ubiquitous amongst hardware, and operating under > UEFI inside EC2 unlocks an increasing number of features such as > Secure Boot and NitroTPM. The benefit for Fedora is a more uniform > experience across cloud and non-cloud environments, simplifying the > boot and runtime software stack. On behalf of the Fedora bootloader maintainers, thank you for this change. Be well, --Robbie signature.asc Description: PGP signature ___ 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: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
Michal Schorm writes: > On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood wrote: >>> Would you see a value in e.g. some kind of a robot reminding >>> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI >>> check) >> >> Please don't. > > Would you mind expanding your answer a bit, please? > I'd like to learn why people would (not) like such a check or reminder. First, there's no benefit to removal. Nothing is harmed by having something that always evaluates like `#if 0` unless it seriously impacts readability. Spec file "hygiene" is not inherently good (or inherently bad) beyond that. A check or reminder is another nag notification. We don't need more of those, especially for low-priority items. And to head something off: it's not better when someone provenpackagers the change in. Then there's an unnecessary revbump, and the maintainers's checkouts desync from the main repo (merge conflicts/rebase). Be well, --Robbie signature.asc Description: PGP signature ___ 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: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
Michal Schorm writes: > While playing around with Sourcegraph, which indexed all Fedora > package repositories, I was able to craft a query listing all '%if' > conditionals referencing Fedora releases that reached EOL. > > Do you agree it would be safe to remove such conditionals and the code > they hold ? Yes, at maintainer discretion. > Do you agree that removing obsolete code such as this brings value to > the package codebase ? No - it's annoying code churn that usually serves no purpose. If maintainers want them gone, generally they'll remove them. > Would you see a value in e.g. some kind of a robot reminding > maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI > check) Please don't. Be well, --Robbie signature.asc Description: PGP signature ___ 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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
"Colin Walters" writes: > On Tue, Nov 15, 2022, at 12:00 PM, Robbie Harwood wrote: > >> If your model doesn't permit the system to cease execution during >> bootloader updates, then I'm not sure why you need bootupd at all - >> traditional RPM updating will work just fine (assuming the A/B change >> we've been talking about). But the "Questions and answers" section >> doesn't read that way to me: it mentions that "forcibly pulling the >> power during OS updates" is a case ostree wants to support and doesn't >> explicitly negate that for the bootloader. > > There's lots of nuance going on here. What both bootupd and your shim > prototype are doing is effectively moving the "payload" into /usr and > not have RPM directly writing to /efi (or /boot/efi, wherever it's > mounted). No, the install script install script in an RPM trigger, so the write is still carried out by RPM. > This also then directly leads into a next issue: > https://github.com/coreos/bootupd/issues/50 Basically, `rpm -q shim` > becomes a lie - or at least, starts to mean something else[1]. I don't agree. Just because a user can mess with files on the system doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all paths on the filesystem just in case they've done so, or create a daemon to provide an interface for doing that. Be well, --Robbie signature.asc Description: PGP signature ___ 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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Timothée Ravier writes: >> Bootloaders are not single files. Consider UEFI: >> >> For grub2, there's both a .efi and some configuration that I'll handwave >> for purposes of this conversation. For shim, it's more like 4 things - >> the main shim*64.efi, fallback.efi, boot.efi, and boot.csv. These all >> serve different purposes, and need to get loaded from specific parts of >> the ESP. (Recall here that fat32 doesn't have symlinks, either.) > > I don't think I understand the problem here. Do shim updates usually > change all of those files at once? What's blocking us from updating > them one by one? Conceptually, we need to be able to update most of them in the event of a security issue. Shim releases are infrequent due to needing signing, which means that as a signed unit they update more at once. In the issue you linked, I described what would be a safe order to apply updates to them in, but that's not *transactional* (a system that takes a reboot during the small window of moving files around could see some from old and some from new). > Note that bootupd is not trying to solve the "safe" part of bootloader > updates: we're aware that the system should not crash while the > bootloader is being updated. See > https://github.com/coreos/bootupd#questions-and-answers If your model doesn't permit the system to cease execution during bootloader updates, then I'm not sure why you need bootupd at all - traditional RPM updating will work just fine (assuming the A/B change we've been talking about). But the "Questions and answers" section doesn't read that way to me: it mentions that "forcibly pulling the power during OS updates" is a case ostree wants to support and doesn't explicitly negate that for the bootloader. I'm happy to send a PR to update that text if that's not what's meant. > Thus that's why we're requiring interactions from an admin to apply > the update as only they can now when the system is the less likely to > crash. Are you referring to https://github.com/fedora-silverblue/issue-tracker/issues/120#issuecomment-1177515110 ? I didn't think that was generally something admins expected to be doing, but would be happy to be wrong about that. Be well, --Robbie signature.asc Description: PGP signature ___ 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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Timothée Ravier writes: >> As we've talked about before, it's not possible to make updates >> transactional. It involves, per spec and depending on processor >> architecture, updating multiple files in different directories, >> potentially on different filesystems entirely, one of which is fat32. > > I should probably have used only 'safe' here. My understanding of the > "fallback work" was that with it, we could do updates automatically and retry > them after failures without risking ending up in a state where we have no > working bootloader. The update process would look like this: > 1. Verify current bootloader hash > 2. Fix it if not good > 3. Copy current version to fallback > 4. Update bootloader to new version > > What I've indeed forgotten to specify is that this only applies to EFI (so > probably only x86 & aarch64) for now as that's what's implemented in bootupd. > > Am I missing something? Bootloaders are not single files. Consider UEFI: For grub2, there's both a .efi and some configuration that I'll handwave for purposes of this conversation. For shim, it's more like 4 things - the main shim*64.efi, fallback.efi, boot.efi, and boot.csv. These all serve different purposes, and need to get loaded from specific parts of the ESP. (Recall here that fat32 doesn't have symlinks, either.) While I think it will surprise no one that I don't agree with doing so, bootupd claims the additional goal of supporting Legacy BIOS. For that, you also need to consider updates to the MBR, which isn't a file at all. Be well, --Robbie signature.asc Description: PGP signature ___ 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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Ben Cotton writes: > By design, ostree does not manage bootloader updates as they can not > (yet) happen in a transactional, atomic and safe fashion. As we've talked about before, it's not possible to make updates transactional. It involves, per spec and depending on processor architecture, updating multiple files in different directories, potentially on different filesystems entirely, one of which is fat32. > * User will be able to easily update the bootloader on their system. > This will let them apply Secure Boot dbx updates that block old > bootloaders with known vulnerabilities from loading. See: > ** https://github.com/fedora-silverblue/issue-tracker/issues/355 > ** https://bugzilla.redhat.com/show_bug.cgi?id=2127995 What's the plan to apply the outstanding security updates (shim, grub2, and dbx push from June) to fedora silverblue 36 + 37 that aren't covered by this change? Be well, --Robbie signature.asc Description: PGP signature ___ 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: Grub menu with 3 kernels by default
Daniel P. Berrangé writes: > We need PCRs to cover at minimum > > 1. Machine firmware > 2. Bootloader(s) > 3. Bootloader configuration > 4. Booted kernel > 5. Booted initrd > 6. Booted cmdline > Item 5 and 6 are a problem, because as mentioned thse are not signed > by the OS vendor with their secureboot key. The PCRs reflect their > contents, but the expected PCR digests will change any time the > initrd/cmdline are updated, meaning the LUKS keys needs to be > re-sealed. One practical approach to this problem is to use > prebuilt unified kernel images, such that the OS vendor's secureboot > signature covers the kernel,initrd and cmdline. Verification now > merely involves checking the PCR for SecureBOot state. The flipside > is that we loose flexibility that exists today with per-host > generated initrd/cmdline. This may matter for some scenarios (bare > metal) but not for others (most VMs). This isn't a grub2 specific problem, but yes - we've discussed how to accomplih signing initrd/cmdline on calls with you before. > Item 3 is a problem. Grub is highly configurable, via grub.conf, and > its contents are tuned for each install. > > This is a really challenging eventlog when trying to validate the PCR > state is matching some expected "known good" state. Given a single > grub.conf, you get both a huge number of entries for every boot, plus > a combinatorial expansion of possible entries that would be considered > valid for a given install over time as kernels and/or grub itself are > updated. A tiny change to the way grub2-mkconfig could result in a > very different PCR eventlog, but which is semantically identical to > what came before. > > Thus any attempt to validate the the grub.conf PCR eventlog, as it > exists in typical distro deployments today, is going to be both > complex and fragile, which is a bad combination. But this is only a problem if you're assuming grub2-mkconfig is nondeterministic, which just isn't the case. I'll grant that the event log isn't terse, but what's valid isn't be hard to precompute. On generally identical systems, what will differ is uuids and partition numbers... which is important information to have logged for booting because it's part of recording *what* was booted. Glibly, if you don't want a config change, don't run grub2-mkconfig :) We don't run mkconfig on the system after install because it doesn't change - it only get run to change something. And if you update configuration, you'd want to know that things changed - that's the whole point of logging it. Be well, --Robbie signature.asc Description: PGP signature ___ 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: Grub menu with 3 kernels by default
Daniel P. Berrangé writes: > The way grub has to write its entire grub.conf into the TPM PCRs is > totally impractical for anyone wishing to maintain attestation > policies to verify the OS boot state from the TPM eventlog. So this has been mentioned in several places, but no one in grub development has actually seen this problem articulated out, which makes me worry that it's spreading FUD. Could you write up a bug report or something concrete? Be well, --Robbie signature.asc Description: PGP signature ___ 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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
Adam Williamson writes: > For background here, see: > https://bugzilla.redhat.com/show_bug.cgi?id=2049849 > > right now, when installing Fedora alongside a Windows install with > BitLocker enabled, trying to boot Windows from the Fedora boot menu > does not work. > > We waived the bug as a blocker for Fedora 36 on the basis upstream did > not consider it fixable within the F36 timeframe. We agreed that if > upstream still couldn't get this fixed for F37, we'd consider revising > the criteria. > > Well, we're approaching F37 Final and the bug is still open, and > there's no appreciable movement upstream, so I'm proposing the criteria > change. I propose we change this: > > "The installer must be able to install into free space alongside an > existing clean Windows installation and install a bootloader which can > boot into both Windows and Fedora." > > to say: > > "The installer must be able to install into free space alongside an > existing clean Windows installation. As long as the Windows > installation does not have BitLocker enabled, the installer must also > install a bootloader which can boot into both Windows and Fedora." (Fedora grub2 maintainer hat on) I'm fine with the proposed change. I'm also fine with the original text. During boot, certain actions are taken that are recorded in the TPM. These include, for instance, any loaders that are run - like grub2. The result is that if you load Windows from grub2 rather than the EFI firmware, the TPM state will be different. Bitlocker cares about this TPM state. So: if you install Windows and set up Bitlocker booting through grub, it will continue to work through grub. If you install Windows outside grub (or it's pre-provisioned), it will continue to work outside grub. If you want to move from not using grub to using grub, then Bitlocker needs to be reestablished with the new TPM values. It is the opinion of the grub2 maintainers that this constitutes being able to boot both Windows and Fedora today. However, we also understand that not everyone agrees with this, as evidenced by the existence of the bug and this thread about changing RC. The only way to get the TPM state to match not using a particular loader is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora userspace) set EFI BootNext and reboot the machine. But generally, if users want to be booting Windows through grub, we recommend they configure Bitlocker against those PCR values instead. Be well, --Robbie signature.asc Description: PGP signature ___ 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: Script to get all deps of a package (for soname bumps etc.)
Maxwell G via devel writes: > I believe Miro uses this for the FTI bugs. It tends to be more accurate, > especially when there hasn't been a compose for a couple days. If this > is something people are interested in, I think it's worthwhile to > include this repo definition in fedora-packager. An authoritative, preferably single, simple command to run to answer the question "across all architectures, what needs my package and in what form?" would be really helpful. Even if there's a "correct" way to do it today, it's not discoverable (as evidenced by these threads) nor is it easy to remember. Something like `dnf whatuses src:mypackage` (or of similar simplicity) would be appreciated. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Lennart Poettering writes: > On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org) > wrote: > >> Also, if users have "special" hardware, shouldn't they also have >> security. > > if you need a special kernel cmdline to get your system to boot, then > that's a bug in the kernel, and should be fixed there. Adding a kernel > cmdline option is a local hack at best, executable only by the most > technically savvy of users, and I think for those it's totally OK if > you have to disable SecureBoot if you hack around. I think this overestimates the complexity required here. You follow the on-screen instructions to press 'e', arrow key to the end of the line, and type the parameters from the support forum or stackoverflow or wherever. > Kernels should work universally, and if the don't do that > out-of-the-box on some very new or very exotic hardware, then the > right fix is not to expect users to be technical enough to set a > kernel cmdline, but to fix the kernel to apply the fix automatically > where needed. The kernel has plenty infrastructure for that. In an ideal world, perhaps. But kernel parameters are also used for things that have nothing to do with hardware, such as needing to drop to a root shell on boot to fix problems in early userspace (e.g., clobbered /etc/shadow). Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Charalampos Stratakis writes: > So I presume then that python2.7 in Debian works flawlessly with > OpenSSL 3.0.0, no regressions, no security issues and no ABI problems > right? I'm hearing hostility from you and I don't know why. From your sarcasm, I take it to mean that no, you haven't looked. So my original question of "can we adapt this to Fedora" still stands. I'm confused that you're asking me to do this legwork for you, given I neither represent Debian in any way nor am I a Python developer, but since it's not hard to check... https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=python2.7 here is the Debian bugtracker for python2.7. The only openssl bug present there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954418 (i.e., upstream https://bugs.python.org/issue40018 ) which, as it affects python3 versions as well, isn't relevant to this discussion. https://salsa.debian.org/cpython-team/python2/-/tree/master/debian/patches here is the patches Debian carries for python2.7. All but one of them are backports from upstream, mostly by Christian Heimes . Commit logs say that the backport was performed by Stefano Rivera , and applied by Matthias Klose . If it were me in your shoes, I would ask them how things have gone and for any pointers in potentially applying the backport yourself. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Charalampos Stratakis writes: > Unfortunately that effort is moot, it's really not possible to make > python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python > versions are not 100% compatible for various reasons. > > In trying to make it compatible there are also ABI changes introduced, > it's not only about having the tests pass. The ssl module is already > complex enough in backporting changes from the master Python branch to > previous 3.x versions, doing that for 2.7 without a full fledged > effort from SSL and the Python C API experts guarantee there's gonna > be regressions. And that's not even taking into account the security > implications of randomly cherry-picking commits just to have the > package compile. I'm having trouble understanding this because Debian seems to have carried out what you're saying is impossible: in testing, they ship a python2.7 that appears to be using openssl 3, and do not ship openssl 1.1 at all. There are also a handful of clearly openssl 3-related patches in their tree https://salsa.debian.org/cpython-team/python2/-/tree/master/debian/patches Have folks looked at how they do this, and whether we could adapt it to Fedora? Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
Vitaly Zaitsev via devel writes: > On 29/06/2022 01:18, Maxwell G via devel wrote: > >> You might also be interested in the Stalled EPEL Requests >> policy[1]. This would've allowed you to get permissions to branch the >> package for EPEL without going through the non-responsive maintainer >> process. > > This policy looks like a package hijack attempt. I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
Maxwell G via devel writes: > On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote: >> I have started the responsive maintainer process due to lack of contact >> through bugzilla mail. Specifically, this is about an epel9 branch, >> which has been repeatedly requested since March (including an offer to >> maintain the branch) in >> https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and >> https://bugzilla.redhat.com/show_bug.cgi?id=2059757 . > > You might also be interested in the Stalled EPEL Requests > policy[1]. This would've allowed you to get permissions to branch the > package for EPEL without going through the non-responsive maintainer > process. Of course, if after a certain amount of time, a maintainer is > deemed completely non-responsive, you should go through the respective > process. The Stalled EPEL Requests policy is just intended to provide > a more expedient way to get a package branched for EPEL. > > [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy/ > #stalled_epel_requests Thanks, I didn't know about that. Hopefully I'll never have to use it, but good to know. In this case, because no one needinfo'd the maintainer, the EPEL policy can be slower (two weeks compared to the minimum ten days for nonresponsive). Also, a literal reading of the EPEL policy says that the same person needs to needinfo as opened the bug, so if that's the case, then it would have been three weeks (because I didn't open either bug), unless I ask one of them to needinfo. I'm not sure if that's intended? Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
Alex Chernyakhovsky writes: > I just replied on bugzilla. No one has attempted to contact me before. Well... as a Fedora maintainer, there's an expectation that you'll read your bugzilla email from time to time :) I know stuff happens, and from your bz comment it sounds like there was some issue posting comments. I'm glad to hear a branch is in the works - thanks! Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Unresponsive maintainer: Alex Chernyakhovsky
Hi Alex + Fedora, I'm trying to contact Alex Chernyakhovsky, the maintainer of mosh. Does anyone know how to contact them? I have started the responsive maintainer process due to lack of contact through bugzilla mail. Specifically, this is about an epel9 branch, which has been repeatedly requested since March (including an offer to maintain the branch) in https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and https://bugzilla.redhat.com/show_bug.cgi?id=2059757 . Alex, while I regret that we're here a second time [1], please know that it's because we want to use this thing yinz built. If it would be helpful to you, I'm happy to either maintain or help co-maintain mosh. Per Fedora policy, check bug is: https://bugzilla.redhat.com/show_bug.cgi?id=2101951 Be well, --Robbie 1: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C3QOBXCDHVN4OWPVRM32IVE37CV36ZOT/ signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
> Demi Marie Obenour wrote: >> On 6/25/22 07:56, Roberto Ragusa wrote: >>> On 6/19/22 22:54, Sharpened Blade via devel wrote: >>> Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. >>> >>> How big is the demand for this kind of lockdown? As a >>> since-last-century Linux user, I'm choosing Fedora exactly to NOT >>> have all this signing/trusted boot complications on my systems and I >>> do not see a reason to turn Fedora into Android (or, worse, iOS). tl;dr: that's not what Secure Boot is; packed kernel+initrd images may be in the cards As one of the people responsible for getting Fedora's shim signed and therefore making Secure Boot work, I feel it's necessary to clarify that we don't agree with any of the misinformation in this thread: Secure Boot is not lockout. Secure Boot is not designed or even intended to keep you out of your own machine. The entire trust model assumes that if you have physical access, it's your machine: you can manipulate keys, and even turn Secure Booting off. If you don't own the machine... well, then you're an attacker, it's designed to keep you out, and as I'm not a blackhat, you'll get no help from me :) How you configure your own hardware, should you choose to do so, is your own business and I won't tell you how to do that. But as it adds a tangible security benefit, and even if you're doing custom module/kernel/etc. builds, it's really not very difficult to add your own key and sign. Secure Boot can be thought of as primarily a way to avoid attacker persistence on the system. Supposing someone otherwise roots the machine, by restricting boot targets to known good (as determined by machine owner or distro vendor), we make it much harder to (for example) deploy a bootkit, or load a malicious kmod. This isn't perfect (see the original post), but it's clearly better than not having it, and problems like "the initrd isn't signed" are eminently solvable. While I will not be responding to all the dangerously incorrect things that have or can be said, here's a sample reply: Neal Gompa writes: > I only care about secure boot enough to bootstrap a Free platform. False dichotomy. Secure Boot isn't nonfree, nor is the Fedora ecosystem somehow decoupled from it. > Secure Boot is generally not designed as a tool to provide security Wildly, dangerously incorrect. (And it's not a tool - many components work together to enable it, including the kernel.) > unless you rip out all the certs and use your own exclusively. At that > point, you can do whatever you want. If you're doing custom builds, you're of course encouraged to use your own certs. How you configure your own machine is, again, your business. > Most PCs are poorly designed to handle doing this procedure, and it's > too easy to accidentally break the computer entirely by doing so. It's > just not worth it. Groundless speculation, and not correct. > I treat Secure Boot purely as a compatibility interface. We need to do > just enough to get through the secure boot environment. Again, this misunderstands the security boundary. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: SPDX identifiers in old branches?
Neal Gompa writes:
> I think people assume we do more with the License tag than we actually
> do.
I think this is correct.
> We have no active automated auditing or validation of package license
> tags at this time.
And this is not.
rpminspect is run on every bodhi update. It contains a check
("license") which checks whether a license is valid against the Fedora
db, whether it's a valid expression, etc..
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 proposal: BIOS boot.iso with GRUB2 (System-Wide Change proposal)
Ben Cotton writes: > https://fedoraproject.org/wiki/Changes/BIOSBootISOWithGrub2 > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Modify > [https://github.com/weldr/lorax/tree/master/share/templates.d/99-generic > lorax-generic-templates] to use GRUB2 when booting the boot.iso on > BIOS systems, instead of syslinux. Upstream syslinux development is > dead, and the Fedora maintainer would like to drop the package from > the distribution. GRUB2 works as a replacement in most situations and > continues to have upstream support. Thanks for the work here, Brian and Thomas! Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)
Ben Cotton writes: > :Don’t prepend a potentially unsafe path to `sys.path`: If this is a safety/security issue, why not just make it the default for python itself? Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
Alexander Sosedkin writes: > crypto-policies' goal is to define system-wide *defaults*. Well, that's certainly part of it, but... "The purpose is to unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system, irrespective of the crypto library in use." (from https://gitlab.com/redhat-crypto/fedora-crypto-policies#purpose ) "Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. The implementation approach will be to initially modify SSL libraries to respect the policy and gradually adding more libraries and applications." (from https://fedoraproject.org/wiki/Changes/CryptoPolicy#Summary ) So to restate: from what Nikos wrote, I read an additional goal of unification and centralization that I don't hear echoed in what you're saying. > Cryptographic libraries already provide all kinds of finer API to > deviate from configuration file defaults that isn't just envvars or > pointing to configuration files; API that applications are already > supposed to be using if they want to ensure that a specific algorithm > is available no matter what the local/vendor/whatever configuration > is. In many cases these APIs exist, but what you're proposing is a world where applications generally need to care about their own crypto settings. In that world, there's little incentive to use the systemwide settings at all, and we're back to each application deciding crypto for themselves - which doesn't strike me as appealing. > The sad thing though is that it's been long limited to just TLS and > routinely needs expansion to cover more. Yes, many things make the assumption that crypto == TLS. crypto-policies already covers more than just TLS settings for applications, so it needs to have solutions for more than just that. > Envvars and custom config files do exist and do function, but I don't > consider them enough. So what solution do you propose that would be enough? Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
JT writes: >> IMO, there's a rather desperate need to be able to override the >> system-wide policy for individual processes, maybe via some sort of >> wrapper around one of the containerization technologies. > > Alternatively I wouldn't be surprised if at some point the industry > doesn't unofficially opt for a legacy openssl option which could be > utilized by legacy code, but still allow all the modern code to use > the new stuff. But of course if that did exist, tons of people would > just refuse to update their code and deps because they have an option > not to. While I agree that per-application policy overrides would be really helpful, these suggested solutions are overkill. Concretely, crypto-policies works by managing various configuration files. All that's needed to override on a per-application or even per-process basis is to look at a different configuration file. Exposing an environment variable (when it's not already) or initialization option from the crypto library suffices for this. In any case, this seems like functionality best provided by crypto-policies itself. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hans de Goede writes: > What I envision for the SIG is: > > 1. I'm not sure if it is possible to setup group ownership > of pkgs in pagure? So to keep things simple the few packages which > are only necessary for BIOS boot can be handed over to me and then > I'll just add other people willing to help out as co-maintainers. As I've mentioned multiple times elsewhere, this isn't about packages, and I don't think it's helpful to think in terms of them. > And I would also like to have a discussion about splitting > the BIOS boot grub bits out into a separate src.rpm > (using the same Source0 as the main grub) so that this can > be build by the SIG without needing help from the bootloader > team (the main grub package can only be built by a few people > because of secureboot signing). The idea is to avoiding > bottlenecking on the bootloader team when some BIOS boot bugs > in grub need to be fixed, quoting from my original email about > this: Trying to avoid re-hashing our lengthy off-list conversation, here are some thoughts (mine and other interested parties's): At minimum, we need a Legacy BIOS SIG to provide: - a "place" to assign bugs (e.g., email address) - a means to fix issues By default, we understand the former to be the SIG's email address, and the latter to be PRs to dist-git of relevant packages. The overall goal of the SIG needs to be to reduce load on existing bootloader contributors. If it is not doing this, it needs to be dissolved. ## SIG package maintenance If the SIG wants to maintain any BIOS-only packages, that's up to them. Assuming Brian's change to use grub2 instead of syslinux on legacy install media ( https://github.com/weldr/lorax/pull/1226 ), the only other packages in question here would be those to support VESA/fbdev: - xorg-x11-drv-vesa - xorg-x11-drv-fbdev - xorg-x11-server-Xorg - syslinux ## Fedora deliverables Given there is consensus that legacy BIOS is on its way out, we think Fedora release criteria in this area should be re-evaluated. Not only does support change from "fully supported" to "best effort", but we should re-evaluate what is/isn't release blocking, and probably clarify who owns what parts. ## grub2 By default, the Legacy SIG is expected to perform contributions in the form of triage and PRs. Normal “upstream first” rules apply here (i.e., send it wherever possible, otherwise send to the downstream rhboot repo). Current grub2 maintainers consider splitting the package (probably grub2 and grub2-pc, to match current naming, or grub2-legacy or something) undesirable for a number of reasons. A nonexhaustive list of what would need to be satisfactorily resolved before a split could considered: - There needs to be a primary (and probably secondary) package owner from the SIG as a prerequisite for a new bugzilla component. - Everything in grub2-common, grub2-tools, and grub2-tools-extra is available on both UEFI and legacy. In most cases, the content is in fact shared: one file works on both. - The new grub2-bios is secondary to the main grub2 package, which means that the Legacy SIG is responsible for not conflicting with any grub2 subpackage, and nothing in grub2 can depend on anything in the legacy package. - More generally, problems with the shared core can and will manifest primarily on one platform. Bugzilla ping-pong needs to not be played. - Feature incompatibilities can and will occur. (Maybe this is okay, or just the Legacy SIG's responsibility to sort out in all cases.) - Current maintainers do not have much capacity for mentoring, and since the point is to be rid of legacy, we can't help much at all with bugfixes. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Hans de Goede writes: > On 4/13/22 21:27, David Cantrell wrote: > >> OK, given this proposal, I'd like the original change proposal >> amended to essentially say "transfer legacy BIOS boot support to >> newly formed Legacy BIOS SIG" or something like that. The logistics >> at that point can be sorted out as the SIG sees fit. I'd like to see >> the original proposal advance forward and this gives a plan for the >> legacy BIOS piece. > > TBH I'm not sure if that is the direction in which the proposal owner > (Robbie) wants to go, Robbie ? More complicated than that. As alluded to elsewhere in the thread, a SIG doesn't actually require a change proposal ( https://fedoraproject.org/wiki/Creating_a_Fedora_SIG ) and I'd feel weird proposing the creation of a SIG that I'm not going to participate in. I don't oppose others stepping forward if they wish. Regarding the change proposal itself, there seems to be consensus that legacy bios booting will be going away "eventually", even if for my purposes "eventually" means "we have this mudslinging again in x releases". Absent a formal date or even consensus around what "deprecation" means, I'm not sure what purpose a revised/new proposal would serve at this juncture. > I've send Robbie an offlist email asking him to weigh in here. My pronouns are they/them. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > Alright, I'll bite. I am within my rights to propose any Change I want > for Fedora Cloud, which I help steward with David Duncan. As, presumably, is anyone else? > As an aside, I examined the state of all release blocking Fedora > deliverables, and something I noticed is that only the Workstation WG > has Red Hatters actively engaged in it. That means that this Change > comes with absolutely no understanding of the state of the world in > Fedora across the various WGs and SIGs that deliver release-blocking > artifacts. That in itself isn't necessarily a problem, but the fact > that none of you are listening to us (David Duncan and myself for > Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy > for Server) when we tell you this is too early is extremely tone-deaf. > > None of us want to keep supporting BIOS forever, but we all have > *real-world experience* saying that we can't do this yet. We're trying > to find a way to meet halfway to simplify legacy BIOS support, but > you're not listening to us. We've also been trying to tell you that > there are *real problems* with Fedora's UEFI support that need fixing > before we can cut off BIOS support, but you're not listening to us. > > This thread has, at the time of my writing this post, has 269 posts > across 62 individuals. It is the most active thread we've had since > the switch to nano by default. However, unlike that change, almost > every single respondent has brought up feedback in this discussion > saying that we're not ready and providing examples of why we're not > ready. However, you're *not listening*. Okay, this is really important: just because I don't agree with you doesn't mean I'm not hearing what you say. You appear to be conflating the two things. I hear your position that this is too soon. But I need you to hear what I'm saying too: community assistance is required to keep up the status quo, if that's how we want to go. If you think the best way to go is to vote this down, and have firmly made up your mind to vote it down, then vote it down! But do so with that knowledge. > I understand you want to drop BIOS support before Fedora Linux 40 is > branched into RHEL 10. No one has said anything at all about RHEL. As a member of the team responsible for RHEL's boot stack, I can say that most of our focus is at the moment on <=9, not >9. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > Windows is a niche in the server space, rather than the default That may be true for many workloads, but I doubt it's true in all cases - Active Directory has a huge footprint, for instance, and Linux is not "the default" for identity services. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Michel Alexandre Salim writes: > - as I stated, there are offers to help with getting syslinux replaced > with GRUB More generally, I'm concerned that folks think this'll help a lot more than it actually will. There's a tendency to think in terms of packages - they're contained units and therefore convenient to reason about. But just being in a container is not an indication of complexity or size. The obligatory example of this that is (I hope) generally understood is the kernel. One source package, wildly different complexity than anything else - to the point where it's more meaningful to talk about the workflows enabled, subsystems, etc. than the rpms themselves. I've mentioned this upthread as well, but this is the nature of the problem: it's not about *packages*, it's about *use case*. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Michel Alexandre Salim writes: > - as I stated, there are offers to help with getting syslinux replaced > with GRUB. what I've not stated originally is Chris Murphy brought up > protective MBR and switching all new installs to inst.gpt, which let > us future proof new installations for when we do kill off legacy BIOS. > > What people who want to help needs, though, is some sense that our > contributions are welcome. (If you're looking for me to comment on proposals to change live media generation and installs, I can't really do that - that's Brian's and Jiri's areas of expertise.) > - Neal pointed out he has been working on addressing this for a while, > and have not put up a Change Proposal because he thought it was > premature While Neal's contributions are as welcome as anyone else's, Neal is not a maintainer of (or regular contributor to) bootloader packages and it would be very strange for Neal to propose such a change without discussing it with us first. That said, if there was suggestion of such a proposal, I have missed it (which is very possible given the size of the thread at this point). Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Michel Alexandre Salim writes: > Would using Grub for legacy boot be more, or less work than continuing > to support syslinux, assuming people step up to do the development and > validation? syslinux is by default only used on the live media. Legacy installs today provision grub2. So moving them to live media would probably be less, but it won't solve the overall problem. > I sympathize with the change owners' position that detractors need > to assume their good intentions, but I feel like the same needs to be > assumed for community contributions, That's not really a "position" so much as a restatement of the Fedora Project's code of conduct. If you feel that our comportment is not up to snuff, please provide specific feedback so we can improve. (Otherwise, a statement like that just comes across as propagating FUD.) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Vitaly Zaitsev via devel writes: > On 07/04/2022 18:10, Robbie Harwood wrote: > >> While we do maintain a large set of patches downstream, due to upstream >> being inactive for a while, today upstream is alive and very much not >> abandoned: > > Why not upstream all those patches then? I resent the implication that I'm not doing that. The idea that one would show up with a decent-sized pile of patches and have an upstream merge them immediately sits somewhere between "naïve" and "a reason to vote no-confidence in upstream". Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
David Duncan writes: > it also appears that issues have prevented direct contribution based > on some sort of misconfiguration in the repository, though it sounds > like this is fixed as of this discussion. It still speaks to more than > a year of complication in contribution. Is Neal really the only one > who was impacted by the inability to submit a PR? So far, that's the only case we're aware of, and we only learned yesterday that they considered using it during that interval. Anyway, it has been fixed for a while - for instance, Zbignew has been waiting on me to merge a pending PR to drop our use of "which" :) (Javier (co-maintainer) has a post I believe touching on this as well, but it's stuck in the moderation queue right now.) I want to emphasize again that PRs are not the only venue of communication with maintainers, nor are they the only way to send us code (attachments on bugzilla, patches upstream, patches to source-git-likes, ...), nor is sending code the only way to contribute (investigating issues, translations, ...). > I think that creating choice is the right response I don't agree that choice is inherently superior, especially when it creates more work to support. For a more eloquent explanation of this, I refer you to ajax's post: https://listman.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Michael Catanzaro writes: > On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez > wrote: >> This seems like a strong assumption to me considering that aside from >> the largest cloud providers (with whom Red Hat is directly working >> with on UEFI boot features and bug reports), cloud providers are >> using off-the-shelf hypervisors that support UEFI boot. > > I'm going to ask the proposal authors to at least mention this as a > risk in the Feedback section of the change proposal. Maybe cloud > providers will all see this as a good opportunity to enable UEFI on > their platforms, and we'll be perfectly fine. I rather suspect it's not > going to happen quite so smoothly, though I have appended added my analysis of this to the Feedback section. For clarity, it's copied here: During mailing list discussion of this change, concern was expressed that some of the smaller hosting providers who do not provision with UEFI today and do not also support Windows would drop Fedora rather than enabling UEFI. Given that the major virtualization solutions (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today, this would likely be exposing an existing capability rather than making a sweeping change. That said, it is always possible that providers may elect to drop Fedora rather than adjust their setups - be it for this change or any other change Fedora makes. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Robert Marcano via devel writes: > Is this change only related to install media support for booting with > BIOS only? Would I be able to install newer Fedora releases using Legacy > PXE on BIOS only machines? The intent is to indicate that new legacy installations are not supported, regardless of how one gets there. Mechanically, there are few ways to actually *prevent* these installations[1] - rather, we send a message that this is on its way out (i.e., deprecated) and that it's time for users to consider migrating their setups. So the direct answer is: yes, probably, if you're willing to work at it hard enough. But it wouldn't be supported. Be well, --Robbie 1: Even if I wanted to, which I don't, it's not that hard to re-enable anything we might turn off just by doing local builds. signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Vitaly Zaitsev via devel writes: > On 07/04/2022 10:43, Lennart Poettering wrote: >> Do you think the user experience with grub was*good*? Turing complete >> language? Scripts that generate scripts that generate scripts? > > +1. Current GRUB2 is a collection of hacks. Even the upstream abandoned > it, and it currently maintained mainly in downstream. This is not reflective of the current state of affairs. While we do maintain a large set of patches downstream, due to upstream being inactive for a while, today upstream is alive and very much not abandoned: https://www.gnu.org/software/grub/ https://lists.gnu.org/archive/html/grub-devel/ Last release was June; plenty of commits since then. I regularly communicate with dkiper (who is the maintainer these days). Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Demi Marie Obenour writes: > On 4/6/22 16:59, Robbie Harwood wrote: >> Demi Marie Obenour writes: >> >>> On 4/5/22 12:29, Michael Catanzaro wrote: >>>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood >>>> wrote: >>>>> Users wishing to use NVIDIA hardware have the following options: >>>>> >>>>> - Use nouveau (free, open source, cool) >>>>> - Sign their own copy of the proprietary driver (involves messing with >>>>> certificates, so not appropriate for all users) >>>>> - Disable Secure Boot (note that this is still UEFI) >>>>> >>>>> The NVIDIA driver is proprietary, so of course it's not going to get >>>>> signed. >>>> >>>> The user experience requirement is: user searches for NVIDIA in GNOME >>>> Software and clicks Install. No further action should be >>>> necessary. We didn't make the NVIDIA driver available from the >>>> graphical installer with the intention that arcane workarounds would >>>> be required to use it. >>> >>> Bingo. None of the three options Robbie suggested are reasonable for >>> non-technical users. >> >> No, I don't think that's right. It's been a bit since I've run nvidia >> hardware, but I'm pretty sure using nouveau is the default. It's less >> powerful than the proprietary driver, but if it works out of the box, >> it's really difficult to argue with that user experience. > > Nouveau does not support any graphics acceleration on Ampere, and its > performance is very poor on Maxwell and later. That may be true, but that has nothing to do with what non-technical users are capable of doing to their systems. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Demi Marie Obenour writes: > On 4/6/22 06:43, Neal Gompa wrote: >> On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster >> wrote: >>> >>> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour >>> wrote: On 4/5/22 19:38, Chris Murphy wrote: > We either want users with NVIDIA hardware to be inside the Secure Boot > fold or we don't. I want them in the fold *despite* the driver that > needs signing is proprietary. That's a better user experience across > the board, including the security messaging is made consistent. The > existing policy serves no good at all and is double talk. If we really > care about security more than ideological worry, we'd sign the driver. I agree with this. Sign the driver. >>> >>> Nvidia has their driver signed for their >>> Windows drivers. That they choose >>> not to do so for Linux is their right, >>> even if some wish they did. >>> >>> It should be noted that while many >>> might wish nvidia chose a different >>> way, that is completely orthogonal >>> to bios vs uefi. >> >> Linux, like Windows, requires the distribution vendor to sign modules >> for automatic trust. There are a number of complicated issues that >> make it difficult for us to sign this particular driver, though. >> Notably, NVIDIA themselves acknowledges that it infringes on the GPL >> to redistribute built kernel module blobs of nvidia.ko[1], so that means >> any method of signing it needs to be done locally, which means we >> *need* the local signing path to be improved. >> >> [1]: https://imgur.com/LUCQ3WW > > Can we get NVIDIA to make the module build reproducible? If so, we > could distribute a detached signature. nvidia's module is proprietary. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Dominik 'Rathann' Mierzejewski writes: > On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote: >> Dominik 'Rathann' Mierzejewski wrote: >> and on its way out. As it ages, maintainability has decreased, and the status quo of maintaining both stacks in perpetuity is not viable for those currently doing that work. >>> >>> Have you tried getting more people involved? >> >> I don't think that's how Open Source works. Realistically the way I >> see this playing out is that the people responsible for maintaining >> the legacy boot stack will retire the packages, > > I thought they would be orphaned, if anything. Retiring seems rather > hostile to the people who still need those packages Assume good intent, please :) I believe Richard's comment is about a hypothetical future, not what's written in the change propsal in front of us. I also don't think Richard's point in any way hinges on the distinction between orphaning and retiring. > (which are those, by the way?). > > It's helpful to show the change proponents attitude. As a way of > "asking more people to get involved", I'd expect a list of packages > the change proponents no longer whish to maintain and a date when they > will orphan them, since they've stated they're going to do that > anyway. Without such list it's difficult to assess the scope of the > work required to maintain the affected software stack. I don't see any > such details in the change proposal. There's no list there because I don't believe that's a helpful way to view the problem. For instance, grub2 supports both legacy and UEFI paths - so one can't cleanly say "this package supports one, this package supports the other" like when trimming a dependency chain. (This is especially true when thinking about bootloaders, which tend toward being small operating systems unto themselves.) It's more realistic to consider use cases: legacy is a separate system bringup path. The work is the entire path, not a package. (Lest I be accused of dodging the question: for me, the relevant packages are parts of grub2 and all of syslinux.) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Demi Marie Obenour writes: > On 4/5/22 12:29, Michael Catanzaro wrote: >> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood >> wrote: >>> Users wishing to use NVIDIA hardware have the following options: >>> >>> - Use nouveau (free, open source, cool) >>> - Sign their own copy of the proprietary driver (involves messing with >>> certificates, so not appropriate for all users) >>> - Disable Secure Boot (note that this is still UEFI) >>> >>> The NVIDIA driver is proprietary, so of course it's not going to get >>> signed. >> >> The user experience requirement is: user searches for NVIDIA in GNOME >> Software and clicks Install. No further action should be >> necessary. We didn't make the NVIDIA driver available from the >> graphical installer with the intention that arcane workarounds would >> be required to use it. > > Bingo. None of the three options Robbie suggested are reasonable for > non-technical users. No, I don't think that's right. It's been a bit since I've run nvidia hardware, but I'm pretty sure using nouveau is the default. It's less powerful than the proprietary driver, but if it works out of the box, it's really difficult to argue with that user experience. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Michael Catanzaro writes: > Woah, what happened here? Why would any Fedora package ever disable > pull requests? I suspect it was an accident. I can't speak to why - if my co-maintainers know, maybe they can - but it seems possible it got toggled while someone was looking for something else in pagure settings. It appears to just be a toggle in Project Options, so right next to web hooks configuration or notification adjustment. A (definitely out of scope) related question is, given this is something we don't want to Fedora packages to do, whether src.fedoraproject.org should just not expose the option at all. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood wrote: >> Neal Gompa writes: >> >>> 3. At various times, people have explicitly said "patches NOT >>> welcome" >> >> I see no evidence of this having happened, and it's definitely not >> something I've said. > > The grub2 package had pull requests disabled until last year. That's a > pretty obvious hammer to indicate patches are not welcome. That's why > I couldn't send PRs to add the protected.d files for grub and had to > wait for someone else to do it by filing a BZ. That change went in in 2020, so we're pushing two years ago. The patch was ultimately written by Javier as 8c2cf1c36843a2eb1e52c29f20ef4167463189ec. While it's not the most complex thing in the world, it's not trivial either. The relevant bug was https://bugzilla.redhat.com/show_bug.cgi?id=1874541 which you filed. You did not mention that sending PRs was broken, nor did you provide a patch there, nor did you indicate willingness to provide one. To turn around after that and say, today, that the grub maintainers have said "patches NOT welcome" seems more like an assumption of bad faith than a reasonable characterization to me. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > On Wed, Apr 6, 2022 at 7:14 AM John Boero wrote: >> >> I can fully understand why this would be done. As per the original >> discussion when Peter Robinson mentioned a Spin to deprecate BIOS, >> would anybody else be interested in helping with a Spin for legacy >> BIOS support? I agree with the e-waste comments and it seems a shame >> to trash some perfectly viable kiosks or old IoT which gave new life >> to old kit. I just got done knocking Windows 11 for deprecating >> support for fairly new hardware but now realize Fedora is doing >> something similar (though not as drastic). Is a spin worth >> exploring? Volunteers welcome. > > The pull request to delete the code for BIOS support in lorax means > that we can't produce media with BIOS support at all once that's > merged. They've tied dropping syslinux to dropping BIOS support > entirely. It is also unclear that they'd take a contribution to rewire > lorax to produce media with BIOS support using GRUB like we do for > UEFI. We're right here - you can just ask. Brian's PR is to implement the change as written. If the project decided to go in the direction of a spin, that would be something other than what the change proposes, and the PR wouldn't be appropriate. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Chris Murphy writes: > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: > >> Legacy BIOS support is not removed, but new non-UEFI installation is >> not supported on those platforms. This is a first step toward >> eventually removing legacy BIOS support entirely. > > What is the distinction between "support is not removed" and "removing > support entirely"? i.e. what are the additional steps for entirely > removing support? A project decision that it's not supported, and to stop building the bootloader packages for it entirely. > And what's the approximate time frame for it? Unclear. Sooner would be better for us, but I know that's not realistic. At least a release, probably multiple. Reasoned suggestions (i.e., other than "never") would influence this. > "Support is not removed" seems incongruent with "new installations are > not supported." What continues to be supported? Existing installations. > Will grub-pc still be built and updated? Yes. > Will grub2-install still work on BIOS systems? Probably - I'm not about to sabotage it. But it wouldn't be supported for making new installations. I'm aware that users comfortable doing installs outside anaconda (or with customized anaconda) can circumvent this, and I'm not interested in trying to stop them - that's an adversarial relationship neither of us want. >> syslinux goes away entirely > > If the installation media used BIOS GRUB, syslinux could still go > away. What consideration has occurred to switch from syslinux to BIOS > GRUB for installation media? Is BIOS GRUB being deprecated? Or is it > being discontinued in Fedora? (I wasn't involved in the decision of what bootloader to use for legacy live media and can't speak to it.) > If security vulnerabilities in BIOS GRUB are discovered, and > grub2-install doesn't apply the most recently available fixes, I > consider this an unsupported configuration. We can't say "support is > not removed" while removing the ability to apply security fixes to the > embedded bootloader. I don't think I understand this paragraph, but taking a guess: I don't intend to break anything about existing installations, including security update delivery. > This is removal of support. No mere deprecation. This is a semantic issue that I don't think it will be useful to argue. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
"Andre Robatino" writes: > Those figures are recommended minimums, not requirements. I have a > single core F35 machine which works fine. It's important to note here that "works fine" isn't the same as "is supported". My reading of that document is that if one goes below what's laid out in "Minimum System Configuration", here be dragons, trouble may happen, and to varying degrees, one is on their own. And that those dangers are why there's a "Recommended System Configuration" in the next section. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > This is not a deprecation change, this is effectively a removal > change. By removing the packages and the tooling support for legacy > BIOS, it makes several scenarios (including recovery) harder. > Moreover, it puts the burden on people to figure out if their hardware > can boot and install Fedora when we clearly haven't reached a critical > mass yet for doing so, like we did when we finally removed the i686 > kernel build. I've stated in the change that the intent is to eventually remove legacy entirely - so there's no sleight of hand here. The rest is a semantic issue which I don't care to argue. > 2. The packages are locked down so there is no way for the community to help I've replied to this when you said it before, but no, this is misinformation, and I'd appreciate if you stop spreading it. Bootloader packages are available for PRs, same as every other package in the distro. Our bugzilla issues are as open as any other package in the distro. Quite simply, being able to make official builds isn't a requirement to help with any package in the distro, bootloader or otherwise. And to peek behind the curtain a bit, running `fedpkg build` is not even close to the hardest or most time-consuming part of working on bootloader packages. > 3. At various times, people have explicitly said "patches NOT welcome" I see no evidence of this having happened, and it's definitely not something I've said. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Vít Ondruch writes: > Maybe I don't correctly understand the "Legacy BIOS support is not > removed, but new non-UEFI installation is not supported on those > platforms." quoted from the the change description, but if you have your > system installed, it should keep working. You just keep updating. IOW as > long as you don't reinstall the system, you are fine and you don't have > to be concerned. Just for clarity, this is indeed a correct reading of the intent of the change. If there's wording that clarified here, I'm happy to adopt suggestions - my intent is not to confuse :) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
majid hussain writes: > hi, > could someone kindly tell me if my toshiba l750 machine has EFI support? > i'm blind and efi/bios screens are in accessible. Easiest is probably to do: ls /sys/firmware/efi This tells you whether the machine booted using UEFI. anaconda will set up a UEFI-capable system if booted that way, unless partitioning is overridden to prevent that. If it didn't boot using UEFI today, that doesn't mean it can't (you could check with a live image as well). UEFI tends to be enabled on machines made these days by default for Windows logo requirements, but this is firmware land, and there are no absolutes. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Chris Murphy writes: > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore >> mandates that machines must have been made after 2006). > > Where do we require this? I see only one location for such minimums: > > https://getfedora.org/en/workstation/download/ https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Hardware_Overview/ Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
PGNet Dev writes: > Curious, has anyone from @redhat or @fedora though to actually > communicate with any of the 'big' hosting providers, to perhaps > coordinate/influence/compromise/plan? > > I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest > hosting providers where 'new installs' would be happening on their > VPSs -- would be quite interested in making sure that THEIR customers > had smooth install/migration options for Redhat/Centos*/Fedora > variants. > > I know my _own_ solution to UEFI-install only if those^ providers > don't support it; I'm guessing not everyone will have the same > goals/approach. Any VPS that supports Windows 11 needs to support UEFI-only already. In particular, the top 3 (AWS, Azure, Google Cloud) are all UEFI-capable. (Akamai is, to my knowledge, not a provider of VPSs.) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Tom Hughes writes: > On 05/04/2022 18:51, Robbie Harwood wrote: > >> Right, you need the EFI partition (EFI System Partition, or ESP). I >> don't remember what we default those to these days - I usually make >> about 600M, but I need it larger for testing stuff. The partition >> scheme also needs to be GPT, not MBR. Once that's all set, the EFI >> grub2 packages need to be installed, but that's the easy part :) > > I actually checked that on wikipedia because I wondered if it > had to be GPT and it seemed to say MBR was supported? > > https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Disk_device_compatibility That may work, but what's important is that it's not close to as well-tested - Windows binds UEFI support to needing GPT. (Also, the 2.2T limitation on MBR makes GPT very attractive.) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Gregory Bartholomew writes: > But I seem to remember /boot being a separate partition for a long > time (it used to be required because some older BOISs couldn't read > beyond a certain sector on the disk). Could not /boot be converted to > the ESP (i.e. reformatted with FAT32) on such systems? Only if there's somewhere else for /boot to reside. If e.g., / is encrypted, we're not prepared out of the box to handle that. A determined user could probably make it work, but it's again niche. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Peter Boy writes: > And I also don't understand why we should give up a hallmark of free > Linux, namely to support old, but still good usable hardware (unlike > commercial system, not only Windows but also e.g. RHEL). Developers are free to support whatever systems they like. If someone wants to support systems, they'll be supported; if not, they won't. There's no law that says Linux MUST keep supporting hardware forever. See also: armv7 removal, i386/i686 removal, ppc removal, m68k removal, ... Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Tom Hughes via devel writes: > On 05/04/2022 15:52, Ben Cotton wrote: > >> * There is no migration story from Legacy BIOS to UEFI - >> repartitioning effectively mandates a reinstall. As a result, we >> don’t drop support for existing Legacy BIOS systems yet, just new >> installations. > > This is where I have a problem with this, the fact that there is > no upgrade path - virtually my entire installed base of Fedora is > running legacy BIOS and not being able to upgrade them will be > something of a headache. Yup. That's why there's a deprecation window here. > Is it actually true though? You need to be able to find some space > for an EFI partition but assuming that can be done is there some > other reason you can't migrate from BIOS to UEFI booting? Right, you need the EFI partition (EFI System Partition, or ESP). I don't remember what we default those to these days - I usually make about 600M, but I need it larger for testing stuff. The partition scheme also needs to be GPT, not MBR. Once that's all set, the EFI grub2 packages need to be installed, but that's the easy part :) Repartitioning in the general case is very involved. If the system is using an encrypted LVM, that's two more layers to worry about. The dm-crypt area would need to shrink, which means the LVM needs to shrink, which means the filesystems on it need to shrink (and importantly, not all of them can). That doesn't even touch dual-boot scenarios, where our filesysem support is less good than for Linux native cases. To restate that: I think very determined, patient users can make it work in some cases. But I don't think we can expect that to work for everyone, especially without friendly tooling to accomplish it. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
David Duncan writes: > For similar reasons, I agree with Neal. There are a number of Amazon > EC2 instance types that would be left out of the next generation. I > think it would be better to identify the usage in some way and create > a general awareness that it is being removed prior to outright > removing it. The deprecation period is important IMO. (Just to be clear here: this change is proposing a deprecation, not a removal.) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > By virtue of how boot stuff is handled in Fedora, the community is > incapable of working on it. Not true. Not at all true. src.fedoraproject.org permits anyone, *anyone* to send PRs to fix issues in the boot stack, or any other package. Even without it, bugzilla doesn't lock down people helping troubleshoot, write patches, work with upstreams, etc.. Just because you can't build an official version of the package doesn't mean you can't help work on it. > Fundamentally, this Change is premature unless there's a fundamental > decision that there's going to be more activity to solve these > problems. You're saying that this will reduce maintenance burden, but > virtually every boot bug I've seen for the last few Fedora releases > have been around UEFI, *not* BIOS. And it's a very real struggle to > get UEFI bugs fixed. So you've heard that we're overloaded, and you know that UEFI is the direction the world is heading. Your solution to this is... what, stick our heads in the sand and ignore that? Just do legacy? We already have UEFI-only platforms (see also: the mention of ARM you're belaboring), so that's obviously not going to fly, even if we were willing to, which we're not. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > And we've still failed to get ARM and RISC-V broadly on board with > UEFI This statement is not correct. ARM in Fedora is UEFI-only, and we were both in the Plumbers conversation around RISC-V's booting. > We also lack solutions for dealing with the NVIDIA driver in > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > Because we still don't have a way to have kernel-only keyrings for > secure boot certificates to avoid importing them into the firmware. Users wishing to use NVIDIA hardware have the following options: - Use nouveau (free, open source, cool) - Sign their own copy of the proprietary driver (involves messing with certificates, so not appropriate for all users) - Disable Secure Boot (note that this is still UEFI) The NVIDIA driver is proprietary, so of course it's not going to get signed. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: dist-git force push
Kamil Dudka writes: > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > >> - check whether the "new object name" is descendant of >> (contains) "old build object name" (rather than "old object name", which >> would forbid any force push) >> This would allow to rewrite a branch as long as the last commit hasn't been >> built yet (but allow only rewrites to commits since the last build). In >> particular, this would allow to avoid the many "commit missing patch", >> "actually commit the change", "duh" commits which happen after a successful >> `fedpkg build --scratch --srpm` followed by a half-(how do you say this >> nicely)ed commit. > > I thought the plan was to use pull requests with some CI checks to > avoid this. I hope not. Unless merging the PRs and kicking off the builds are done automatically, this'll just be as painful as the current centos workflow: - commit - push to fork - open PR - wait for checks - click "merge" button - wait for bots - kick off build compared with: - fedpkg commit -sc && fedpkg push && fedpkg build Context switches for maintainers are expensive! And while I don't personally think the "oops fixup" commits are a problem, a "PR with CI" workflow doesn't get rid of them by any means. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
Miro Hrončok writes: > If that's the case, can we please stop enforcing the signed-off-by > thing in Fedora projects (such as various Fedora projects on Pagure or > Bodhi on GitHub)? My understanding is that's about provenance, not licensing per se (not a lawyer etc.). In any case it's up to the project maintainers. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
David Cantrell writes: > Why? Since the removal of the i686 kernel in Fedora, we want to > reduce the number of i686 packages provided in the repo. As time > marches on, the ability to build a lot of things for i686 becomes > unrealistic or even impossible. Remember it goes beyond providing > builds...providing support, bug fixes, and security fixes for those > packages too. Maybe some things using i686 packages now can move to > x86_64 packages. We do not know yet, but a goal is to figure out what > packages, if anything, can drop their i686 builds. > > NOTE: Nothing is changing now. We are in an information gathering > phase. > > If you use i686 packages for something now, please respond to this thread. Nothing that couldn't be cross-built and provided as an x86_64 package. I use wine, which as I understand it, requires 32-bit libraries to run 32-bit Windows binaries. Given the weakness of x86 ASLR, it makes sense to ensure most of the i686 packages aren't actually getting used (e.g., no browsers). At that point, seems like we'd be better off not building for the arch at all, and doing cross-builds from x86_64 for the packages that need it. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: libusb status?
Benjamin Berg writes: > On Wed, 2022-03-09 at 12:35 -0500, Robbie Harwood wrote: > >> Speaking of which, what *are* we expected to do? Aleksei on IRC >> suggested that the preferred solution is to swap the BuildRequires to >> pkgconfig(libusb) - is that right? Is this going to stick around, or is >> it going away too? > > Ideally you should switch BuildRequires to pkgconfig(libusb-1.0) I > would say. Many packages will support building against the newer libusb > API just fine. The libusb (now libusb-compat-0.1) package is just a > small wrapper library that bridges some API differences. Thanks for the clarification (and assistance investigating)! Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
libusb status?
Hi, today I went to build grub2 in rawhide and got this: DEBUG util.py:444: No matching package to install: 'libusb-devel' grub2 has a `BuildRequires: libusb-devel`, and suddenly that package doesn't exist anymore. libusb was apparently dead.package'd two days ago. So this is sudden, and I want to check what's going on here. I would have expected a change proposal about this[1], or at least some email about what's going on, what we're expected to do, etc.. Speaking of which, what *are* we expected to do? Aleksei on IRC suggested that the preferred solution is to swap the BuildRequires to pkgconfig(libusb) - is that right? Is this going to stick around, or is it going away too? Be well, --Robbie 1: I did find https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated_old_api after going digging, but that's for F35 and was marked as done - so no further change from it was expected, if this is somehow related to it. signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
Alexander Sosedkin writes: > Daniel P. Berrangé wrote: > >> Perhaps a useful first step is to just modify the three main >> crypto libs (gnutls, openssl, and nss) to send a scary warnihg >> message to stderr/syslog any time they get use of SHA1 in a >> signature. Leave that active for a release cycle and see how >> many bug reports we get. > > I left my crystal ball at home today, > but I don't need it to say it'd be ~0 bugs filed if we log to syslog > and ~3 if we log to stderr/stdout, all named > "$CRYPTOLIB has no business messing up my stderr/stdout", It's clear you want SHA-1 gone, but the way you've written this maybe isn't conveying what you wan, as it sounds like you're also unwilling to process the bugs that result requesting its removal. (If you, who want it gone, aren't willing to participate in that, why should maintainers care?) As I understood the proposal, it would be for the crypto lib to log a message like: [timestamp] /usr/bin/firefox used DEPRECATED SHA-1 invocation This is similar to what happened for /var/run: sure, it was annoying to basically everyone involved, but the bugs also went to the relevant packages. > which we'll promptly close by reverting the changes. I don't see why you'd do that instead of reassigning to the appropriate packages or (better) helping them migrate. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Neal Gompa writes: > On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood wrote: >> >> Fabio Valentini writes: >> >> > For example, as far as I know, you need the 32-bit host libraries for >> > running 32-bit Windows applications in Wine. Dropping that would make >> > our Wine packages almost useless, since a large fraction of Windows >> > software still isn't 64-bit. >> >> Would it be possible to have package foo's x86_64 build produce a >> foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an >> important use case, but keeping the whole arch machinery around for it >> seems like overkill - just having the packages that are relevant for it >> build 32-bit variants as a special case seems a lot cleaner. >> > > Koji normally filters out foreign arches from buildroot repos. There > are ways around it, but none are usable in Fedora Koji. Good to know. Guess it'd have to be things like foo-32.x86_64.rpm then. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Fabio Valentini writes: > For example, as far as I know, you need the 32-bit host libraries for > running 32-bit Windows applications in Wine. Dropping that would make > our Wine packages almost useless, since a large fraction of Windows > software still isn't 64-bit. Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Questions about new free-only FFMPEG in Fedora repos
Neal Gompa writes: > And we're not the first to offer reduced functionality > FFmpeg (both Debian and openSUSE do too, so we're in good company > here). I don't think that's an accurate characterization of what Debian does. See https://sources.debian.org/src/ffmpeg/7%3A4.4.1-3/debian/README.Debian/ which states that it's built with "as many features as possible" while still being GPL-compatible. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to orphan gnu-efi
Al Stone writes: > I may be interested in picking this up. I've been doing some UEFI > dev work on Fedora. Let me take a look at the package and let you > know in a day or two or three. Anything I should watch out for if > I do decide to pick this up? Thanks for your interest! However, the plans have been dropped - dnf and I weren't in agreement about how dependency querying should work. While there aren't problems open against gnu-efi right now, PRs and triage of bugs around the boot stack is welcome. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: the meaning of pkgconfig's Libs fields
Zbigniew Jędrzejewski-Szmek writes: > 1. pc(5) talks about "package", as if one would want to link to a >whole "package" instead one of the specific library files provided >by a package. Thankfully most .pc files only list one "-l" in Libs. >(Counterexamples: tbbmalloc_proxy.pc says 'Libs:-ltbbmalloc_proxy > -ltbbmalloc', >and mit-krb5.pc says Libs:-lkrb5 -lk5crypto -lcom_err.) k5crypto and com_err are internal libraries used across the different interfaces krb5 provides - they're not intended for external consumption, and upstream doesn't support their direct use by other applications. > To a large extent pkgconfig files are duplicating dependency logic > that is already provided by distro packaging (rpm in our case). This > would seem like an OK idea: upstreams specify which libraries they > need and downstreams use it. So you're technically right that this information is already duplicated by the dependencies libkrb5.so has already, but that's only true on Linux. The .pc files are provided by upstream, and need to work on all OSs that upstream supports - which includes OSs whose linkers don't follow dependencies, like AIX. > Items 1 + 2 are promoting overlinking, i.e. adding either unneeded > libraries, or libraries that are used indirectly, to linker flags for > some object being linked. If the object is going to get loaded at run-time in all cases anyway (as is the case here), the cost of this is tiny. The linker will only load the one copy, and the size difference from having vs. not having the dependency marked is tiny. Unless this is breaking something, I don't believe it's worth the effort to change (but I don't represent krb5 and don't speak for those folks). Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: CVE-2021-4034: why is pkexec still a thing?
Adam Williamson writes: > ...and yet despite being so easy to review it somehow had a major > security vulnerability ever since it was written. This is not a good metric. easy to review != was sufficiently reviewed, and getting sufficient code review might be the hardest problem in software engineering. Additionally, if a project has never had an issue, it's just as likely that no one has ever really looked at it than that it's "safer". Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to orphan gnu-efi
Miro Hrončok writes:
> On 25. 01. 22 19:53, Robbie Harwood wrote:
>> Miro Hrončok writes:
>>
>>> On 25. 01. 22 19:17, Robbie Harwood wrote:
>>>> Hello, we plan to orphan gnu-efi shortly after I finish fixing the
>>>> FTBFS. There do not appear to be any consumers:
>>>>
>>>> # dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel}
>>>> --source
>>>> Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM
>>>> EST.
>>>> gnu-efi-3.0.11-7.1.fc36.src.rpm
>>>
>>> $ repoquery --repo=rawhide{,-source} --whatrequires gnu-efi-devel
>>> efitools-0:1.9.2-6.fc36.src
>>> fwupd-efi-0:1.2-1.fc36.src
>>> pesign-test-app-0:5-26.fc34.src
>>> sbsigntools-0:0.9.4-7.fc36.src
>>> shim-unsigned-aarch64-0:15-1.fc28.src
>>
>> Noted, thanks. I'll file a dnf bug and not abandon it.
>
> This is not a bug in dnf.
>
> And, when you do --whatrequires gnu-efi{,-devel}, it translates to:
>--whatrequires gnu-efi gnu-efi-devel
>
> But you really need to use:
>--whatrequires gnu-efi --whatrequires gnu-efi-devel
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires gnu-efi gnu-efi-devel
> gnu-efi-devel-1:3.0.11-7.1.fc36.noarch
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires gnu-efi --whatrequires
> gnu-efi-devel
> efitools-0:1.9.2-6.fc36.src
> fwupd-efi-0:1.2-1.fc36.src
> gnu-efi-devel-1:3.0.11-7.1.fc36.noarch
> mokutil-2:0.5.0-1.fc36.src
> pesign-test-app-0:5-26.fc34.src
> sbsigntools-0:0.9.4-7.fc36.src
> shim-unsigned-aarch64-0:15-1.fc28.src
I don't see how you can claim that it's not a bug. If it's invalid, dnf
should *tell me that*, not generate garbage. If it doesn't group with
the --whatrequires, then there's an extra argument, and it needs to say
so.
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Intent to orphan gnu-efi
Miro Hrončok writes:
> On 25. 01. 22 19:17, Robbie Harwood wrote:
>> Hello, we plan to orphan gnu-efi shortly after I finish fixing the
>> FTBFS. There do not appear to be any consumers:
>>
>> # dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel}
>> --source
>> Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM
>> EST.
>> gnu-efi-3.0.11-7.1.fc36.src.rpm
>
> $ repoquery --repo=rawhide{,-source} --whatrequires gnu-efi-devel
> efitools-0:1.9.2-6.fc36.src
> fwupd-efi-0:1.2-1.fc36.src
> pesign-test-app-0:5-26.fc34.src
> sbsigntools-0:0.9.4-7.fc36.src
> shim-unsigned-aarch64-0:15-1.fc28.src
Noted, thanks. I'll file a dnf bug and not abandon it.
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Intent to orphan gnu-efi
Hello, we plan to orphan gnu-efi shortly after I finish fixing the
FTBFS. There do not appear to be any consumers:
# dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel}
--source
Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM EST.
gnu-efi-3.0.11-7.1.fc36.src.rpm
#
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
Miro Hrončok writes: > On 13. 01. 22 1:50, Michel Alexandre Salim wrote: >> On Mon, Jan 10, 2022 at 06:57:34PM +0100, Miro Hrončok wrote: >>> Package (co)maintainers Status >>> Change >>> >>> python-selenium mrunge, orphan0 weeks >>> ago >> >> I wonder if we should make ownership automatically fall to the next >> admin/committer in line, in these situations? > > That would make packages with dozen of not-so-responsive maintainers > basically > immortal. The co-mainatiners are bcc'ed on this report. They can take the > packages if interested or leave them to somebody else. (And if the admin wants a particular co-maintainer to take over, they can use the "Give" functionality in Pagure for that.) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: New tool - license-validate
Neal Gompa writes:
> On Tue, Jan 4, 2022 at 3:10 PM Robbie Harwood wrote:
>>
>> Neal Gompa writes:
>>
>> > On Tue, Jan 4, 2022 at 2:25 PM Robbie Harwood wrote:
>> >>
>> >> Neal Gompa writes:
>> >>
>> >> > SPDX expression logic is identical to Fedora's, so that will not
>> >> > change.
>> >>
>> >> I don't believe that's correct.
>> >>
>> >> For instance, for the LGPL, SPDX uses "LGPL-2.0-only" and
>> >> "LGPL-2.0-or-later", while Fedora currently uses "LGPLv2" and "LGPLv2+".
>> >>
>> >> (From https://spdx.org/licenses/ and
>> >> https://fedoraproject.org/wiki/Licensing:Main )
>> >>
>> >
>> > Those are the identifiers, not the *logic*. SPDX and Fedora both use
>> > the same boolean logic terms ("and"/"or"/"with") and support
>> > parenthetical expressions. Fedora mandates lowercase, SPDX doesn't
>> > care, but examples historically are uppercase. Fedora will retain its
>> > expression logic system, complete with lowercase terms (since that
>> > makes the expressions more readable).
>>
>> Fine, but that's misleading in this context. Right now the tool flags
>> (and therefore bugs have been filed for) the identifiers as well.
>
> Yes, and those should still happen.
I don't see why that would be the case, given that as Matthew Miller
mentioned upthread the plan is to move to SPDX identifiers in the
distro. That seems like useless churn and waste of maintainer time.
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: New tool - license-validate
Neal Gompa writes:
> On Tue, Jan 4, 2022 at 2:25 PM Robbie Harwood wrote:
>>
>> Neal Gompa writes:
>>
>> > SPDX expression logic is identical to Fedora's, so that will not
>> > change.
>>
>> I don't believe that's correct.
>>
>> For instance, for the LGPL, SPDX uses "LGPL-2.0-only" and
>> "LGPL-2.0-or-later", while Fedora currently uses "LGPLv2" and "LGPLv2+".
>>
>> (From https://spdx.org/licenses/ and
>> https://fedoraproject.org/wiki/Licensing:Main )
>>
>
> Those are the identifiers, not the *logic*. SPDX and Fedora both use
> the same boolean logic terms ("and"/"or"/"with") and support
> parenthetical expressions. Fedora mandates lowercase, SPDX doesn't
> care, but examples historically are uppercase. Fedora will retain its
> expression logic system, complete with lowercase terms (since that
> makes the expressions more readable).
Fine, but that's misleading in this context. Right now the tool flags
(and therefore bugs have been filed for) the identifiers as well.
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: New tool - license-validate
Neal Gompa writes: > SPDX expression logic is identical to Fedora's, so that will not > change. I don't believe that's correct. For instance, for the LGPL, SPDX uses "LGPL-2.0-only" and "LGPL-2.0-or-later", while Fedora currently uses "LGPLv2" and "LGPLv2+". (From https://spdx.org/licenses/ and https://fedoraproject.org/wiki/Licensing:Main ) Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Raising the attachment size limit in bugzilla?
Carlos O'Donell writes: > - Life-cycle management (delete attachments). Please don't delete attachments. It severely reduces the usefulness of keeping old bugzillas around - if we're going to do that, we might as well delete the old bugzilla entries as well, and I don't think anyone wants that. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Voluntarily step back as co-maintainer?
Frantisek Zatloukal writes: > On Wed, Nov 24, 2021 at 11:58 AM Dominik 'Rathann' Mierzejewski < > domi...@greysector.net> wrote: > >> Try removing yourself from ACL, i.e.: >> 1. Go to https://src.fedoraproject.org/rpms/glabels and login >> 2. Click on Settings tab >> 3. Click on Users & Groups >> 4. Click on the red "trash" icon next to your FAS name >> >> > I am afraid this won't work for commit rights, which seems it's what Maxim > has. I don't know about any other way than contacting somebody with higher > ACLs on that project or maybe creating an infra ticket ( > https://pagure.io/fedora-infrastructure/issues ). For the times I've had to do this in the past, I've filed a ticket at https://pagure.io/releng/ and someone has handled it. It would be nice if pagure could enable this ability, which I remember being present in the old package interface. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Reduce number of packages that are built for i686
Fabio Valentini writes:
> Since it's not practical to modify almost all Fedora packages to add
> "ExcludeArch: %{ix86}" to them, we'd probably need a different
> machanism for this. I have a vague idea:
Is it really not? This seems the easiest way to go about it, honestly -
just have it be permitted for maintainers to opt their stuff out of
building on x86 and let the problem take care of itself recursively.
Be well,
--Robbie
signature.asc
Description: PGP signature
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
Vitaly Zaitsev via devel writes: > On 08/11/2021 16:47, Andreas Schneider wrote: >> I have electron building offline for Fedora, you can find it here: >> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron > > Electron core packaging is a quite trivial task (Arch Linux and Debian > have already done this), but what about Electron applications (VS Code > for example)? They have? What's it called? Asking because I don't see it: rharwood@eesha:~$ aptitude search electron | grep -v electronics p node-electron-to-chromium - Provides a list of electron-to-chromium version mappings rharwood@eesha:~$ Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: deltarpm usefulness?
Stephen John Smoogen writes: > On Mon, 8 Nov 2021 at 04:32, Michael Schroeder wrote: >> >> On Sat, Nov 06, 2021 at 07:43:02AM -, Daniel Alley wrote: >> > Another issue - which is not per-se a security issue but it's still a >> > problem - is that deltarpm uses md5 checksums pervasively. They're >> > everywhere. And it uses its own implementation of md5 which doesn't >> > respect FIPS, so even when the user has *explicitly* configured their >> > system to not use md5 for anything security-relevant, libdeltarpm won't >> > know or care. >> >> They are used as a consistency check, it might as well use crc32. >> So I don't see why FIPS is a concern for you. >> > > In order to get the overall system to be FIPS (and equivalent EU/RU/CN > ones) certified all the implementations of various functions have to > be audited and reviewed. Some must be able to be turned off no matter > what. It doesn't matter if 99 of the 100 versions of md5um are only > for consistency, they must be able to be turned off/not used and not > affect the system. I don't think that's quite accuroate. If the crypto primitive isn't being used for security, then FIPS isn't interested - FIPS is only certifying the cryptography used, and this isn't it. (It's non-FIPS relevant.) This leads to a very common workaround for legacy cryptosystems of tunneling the "bad" crypto in something else: one example is interacting with RC4 and NTLM, where they're still used but over a tunnel (TLS, VPN, etc.) that doesn't expose them. Be well, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is OpenSSL 3.0 still planned for Fedora 35?
Neal Gompa writes: > Basically, my problem is that I don't think Sahana was prepared on how > to handle doing this work properly and they just need to be aware that > communication is extremely important when doing stuff like this. > Sahara took this over from Tomáš Mráz, who left Red Hat to work for > the OpenSSL Foundation on OpenSSL full-time. In that transfer, I don't > think anyone educated Sahana on how to handle Fedora Changes. Hey, this ^ isn't okay. We don't talk to each other like this. Thanks, --Robbie signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
Charalampos Stratakis writes: > Well it seems so. I mean I would get it to an extend if this wasn't a > *PR*. But anyway yes a two-line diff apparently should be a patch and > not a sed. > > Also according to the PR comments I'm "unwilling" to do that upstream. That is not how that word is used - the full comment reads: - You have not made these changes in a way that is helpful to the ecosystem as a whole - Once you had to figure out what files needed changed, you could simply have submitted a patch - as is done normally. This would have enabled me to apply it upstream if you were unwilling to submit it yourself. Fixed the correct way in d269b84 This is a review of your code. You have submitted code, and I, the reviewer, have indicated how it could have been improved, and shown how I would have preferred it by example. This is normal open source stuff. Are you unwilling to submit upstream? I can't say, hence the conditional. What I can say (since upstream is me) is that you didn't. > I don't see how that behavior helps the ecosystem. So I see it like this: Our goal is to land changes upstream. This helps for two reasons: not only is our maintenance burden lowered by not carrying things downstream in Fedora unnecessarily, but also other users (including other distros!) get to benefit from our work. Broadly speaking, upstreams either want PRs on a github/pagure/gitlab frontend, or patches on a mailing list. In either case, the format requirements are the same: something they can directly feed into git-am or git-pull. The more work a downstream maintainer has to do to upstream something, the less likely they are to do it. So, if you want a change to help the ecosystem as a whole, upstream first. Barring that, lowest barrier to upstreaming. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
Zbigniew Jędrzejewski-Szmek writes: > And now you are pissed that they didn't provide the two line diff in > the the format that you like. This belittling is uncalled for; your escalation here is not needed, nor is it helpful to keeping the conversation on a technical track. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
Miro Hrončok writes: > On 09. 02. 21 1:54, Robbie Harwood wrote: >> Miro Hrončok writes: >>> On 08. 02. 21 20:38, Robbie Harwood wrote: >>>> Robbie Harwood writes: >>>>> Ben Cotton writes: >>> >>> but doing this downstream only was never my intention. I am the >>> change owner. >> >> You have already replied to one of the PRs >> https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1 >> to comment that it couldn't be merged. It follows the >> downstream-only sed approach, you'll note. > > I have commented this PR but I have not even seen the diff yet. If > I've seen it, I'd ask whether it can be proposed upstream as well. > I'd ask that whether or not it is applied as a sed or patch (or any > other way). > > Also note that it is a Pull Request, not a provenpackager mass pushing > changes. Indeed, one step closer to doing this right :) > The PR is actually driven by a RHEL 9 bugzilla because the python3-mock > package > is marked as unwanted in > https://github.com/minimization/content-resolver-input This continues to be Fedora, not RHEL. I don't think python3-mock should stay, but it's not justification *for Fedora*. > As I've already said in my first reply to you in January: > >> Disclaimer: The package is listed as unwanted in ELN (so the RHEL >> maintainers might get some internal spam about dropping the >> dependency). If they will be interested, I might end up sending a >> Fedora PR for such packages. > > Please stop accusing me of ill intention. To my knowledge, I have only stated facts. To be clear, I do not believe you have ill intention - I believe we disagree, and aren't communicating well. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
Miro Hrončok writes: > On 08. 02. 21 20:38, Robbie Harwood wrote: >> Robbie Harwood writes: >> >>> Ben Cotton writes: >>> >>>> A simple `sed` can be applied in `%prep` as a temporary (or even >>>> permanent) downstream solution. >>>> >>>> In most cases, performing the following replacement should be enough: >>>> >>>> s/^(\s*)import mock/\1from unittest import mock/ >>>> s/^(\s*)from mock import /\1from unittest.mock import / >>> >>> a couple lines of sed to all (affected) specfiles. I hope I have >>> misunderstood, because that has no mechanism to get the changes back >>> into upstreams. Could you clarify what you intend to do? >> >> Turns out this is indeed what they meant. I would like to reiterate >> my concern that this has no mechanism to get the changes back into >> upstreams: it's just Fedora deviating further from the rest of the >> world, not leading the charge. > > Not sure who you mean by "them" in this case, Change authors. So, you. > but doing this downstream only was never my intention. I am the change > owner. You have already replied to one of the PRs https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1 to comment that it couldn't be merged. It follows the downstream-only sed approach, you'll note. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
Robbie Harwood writes: > Ben Cotton writes: > >> A simple `sed` can be applied in `%prep` as a temporary (or even >> permanent) downstream solution. >> >> In most cases, performing the following replacement should be enough: >> >> s/^(\s*)import mock/\1from unittest import mock/ >> s/^(\s*)from mock import /\1from unittest.mock import / > > a couple lines of sed to all (affected) specfiles. I hope I have > misunderstood, because that has no mechanism to get the changes back > into upstreams. Could you clarify what you intend to do? Turns out this is indeed what they meant. I would like to reiterate my concern that this has no mechanism to get the changes back into upstreams: it's just Fedora deviating further from the rest of the world, not leading the charge. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): >> Vít Ondruch writes: >> >>> Thx everybody for their responses and sorry for such controversial >>> topic. I am not going to propose this upstream after all. However I >>> have few takeaways: >>> >>> 1) I see responses of Fedora long timers and I understand that you >>> have polished workflows. But I really think that for newcomers, mock >>> should be the preferred way. I'd love to see documentation adjusted >>> to prefer mock everywhere. >>> >>> 2) I would really love you to stop using VMs for your build/testing. >>> With exception of Kernel and Kernel related issues, the argument of >>> "mock being slow" can't stand. Every VM will be more resources >>> hungry then mock, slowing every your task. >>> >>> 3) The argument of mock being slow can't stand, because in one of my >>> examples I posted elsewhere in this thread, I picked up the simplest >>> package I could and the build took 7 seconds. This is certainly not >>> slow, in this time you can't even switch to your email client to >>> check your emails. >> >> So far on this thread, you've asked feedback on a proposal, and then >> when provided with feedback you didn't like, repeatedly argued with >> our comments and told us we're wrong. This is not a good way to >> engage with feedback. > > > I have provided the numbers here: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ > > where I tried to point out that I don't perceive build of trivial > package done in 7s to be slow. For nontrivial package the mock overhead > is negligible. Nobody replied (in constructive way). On various places, > I have suggested to use "--no-clean" option for repeated builds. But in > the whole thread, there was no confirmation that anyone would use it. > > Yet I am repetitively told that mock is slow, you repeat it down bellow > once again without any evidence. Your only argument to this discussion > is that mock is slow, because you believe so and other people have said > so. I would really appreciate if I was given some specific > counterargument supported by numbers. I believe you are missing my point. Your original email reads: I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? This is a *request for input*. You explicitly mention wanting to know "sentiment" [1]. I didn't reply because I wanted to complain or argue; I replied to express what my feelings are. Don't ever tell someone that their feelings are wrong. You want to have a technical argument, fine. But an email initiating that looks very different. Here's an example: `fedpkg local` is a burden to maintain because [insert reasons]. I would like to have everyone using mock instead. What improvements do we need to make in order for your workflow to move off `fedpkg local`? This requests concrete data - actionable points, even. It states intentions clearly, and a request for details and data isn't out of scope. Thanks, --Robbie 1: Here's Merriam-Webster on that: https://www.merriam-webster.com/dictionary/sentiment - note that *every single definition* is subjective and/or involves emotion. signature.asc Description: PGP signature ___ 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
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Thx everybody for their responses and sorry for such controversial > topic. I am not going to propose this upstream after all. However I have > few takeaways: > > 1) I see responses of Fedora long timers and I understand that you > have polished workflows. But I really think that for newcomers, mock > should be the preferred way. I'd love to see documentation adjusted to > prefer mock everywhere. > > 2) I would really love you to stop using VMs for your build/testing. > With exception of Kernel and Kernel related issues, the argument of > "mock being slow" can't stand. Every VM will be more resources hungry > then mock, slowing every your task. > > 3) The argument of mock being slow can't stand, because in one of my > examples I posted elsewhere in this thread, I picked up the simplest > package I could and the build took 7 seconds. This is certainly not > slow, in this time you can't even switch to your email client to check > your emails. So far on this thread, you've asked feedback on a proposal, and then when provided with feedback you didn't like, repeatedly argued with our comments and told us we're wrong. This is not a good way to engage with feedback. In particular, *numerous* people have told you that mock builds are slow for us. Instead of telling us that we're wrong about our own experience because it doesn't match yours, make an effort to understand what the difference is between them. Or accept it for what it is: feedback that *you asked for*. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Dne 27. 01. 21 v 23:21 Gwyn Ciesla via devel napsal(a): >>> On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: >>> Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? >>> >>> Why? I use it all the time. While I understand that it's not as >>> complete a local test as mock, it a lot quicker and less disruptive. >>> And if I want a real test I'll use a scratch build (because that's >>> the only way to test a build across architectures). >>> >> Agreed. Santa didn't bring me the s390x I asked for this year. :( > > Just FTR, mock supports `--arch=ARCH` which will use emulation to > allow you build whatever architecture localy. I have never used it > myself, but I wanted to mention this. I recommend you try. Prepare to be underwhelmed by speed :) Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should > be the preferred way. Would there be anybody really missing this > functionality? I would miss it. It's nontrivially faster to `fedpkg local` than `fedpkg mockbuild` since I don't have to wait for dnf multiple times. The overhead can be quite high. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
Miro Hrončok writes: > On 25. 01. 21 19:32, Robbie Harwood wrote: >> Miro Hrončok writes: >> >>> Before I try to word it more carefully I'd like to hear some feedback >>> on this. What do you think? >> >> It seems to me that this problem would be better solved by making >> rebuilds smarter. Instead of building tip of dist-git (which might >> never have been build), rebuild the last thing that *was* successfully >> built. There are a number of ways to potentially track this >> information[2]. > > Let's say I approach a package I need to bump and rebuild and the > latest successful build is 5 commits old. What do I do? Do I revert > the 5 commits and push a release bump on top? Or do I branch from the > latest working state and push a tagged commit to build it creating a > new git history for what was built (different to what was pushed by > the maintainer)? Exactly. I think *this* is the problem that actually should be solved because people pushing incomplete changes to dist-git is going to happen regardless of what the policy says. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
Miro Hrončok writes: > Before I try to word it more carefully I'd like to hear some feedback > on this. What do you think? I'm struggling to understand what you think this will accomplish. Leaving aside ideological disagreement about the nature of rawhide (I don't think rawhide should be expected to be in perfect working order[1]), this won't prevent the problem of incomplete changes landing in dist-git. All it will do is give people an excuse to yell more at the unfortunate maintainer who ran the wrong push command. The wrath of the heavens already descends on people who break rawhide; we don't need even more. It seems to me that this problem would be better solved by making rebuilds smarter. Instead of building tip of dist-git (which might never have been build), rebuild the last thing that *was* successfully built. There are a number of ways to potentially track this information[2]. Thanks, --Robbie 1: There's also an idea that ProvenPackagers making regularly sweeping changes to the distro is to be encouraged, and I think that's a problem. 2: Off the top of my head: get the SRPM from koji, or update a branch in dist-git to point to last successful build, or track this information explicitly somewhere else, etc., etc. signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
Ben Cotton writes:
> A simple `sed` can be applied in `%prep` as a temporary (or even
> permanent) downstream solution.
>
> In most cases, performing the following replacement should be enough:
>
> s/^(\s*)import mock/\1from unittest import mock/
> s/^(\s*)from mock import /\1from unittest.mock import /
>
> * Other developers: No action needed. Don't add new dependencies on
> {{package|python3-mock}}. If interested, migrate existing packages to
> `unittest.mock` (feel free to ask for help)
Those three snippets together suggest to me that the way this migration
will be performed is that you're going to ProvenPackager in a couple
lines of sed to all (affected) specfiles. I hope I have misunderstood,
because that has no mechanism to get the changes back into upstreams.
Could you clarify what you intend to do?
> == Dependencies ==
> N/A (not a System Wide Change)
You're proposing changing many packages, so I don't think this qualifies
as a self-contained change. The actual removal would be, but not
dependency patching.
Speaking of dependencies, though, I'm not seeing a list of packages that
are affected. Could you provide one?
Thanks,
--Robbie
signature.asc
Description: PGP signature
___
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
Re: libelf now depends on openssl
"Colin Walters" writes: > On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote: >> >> There is of course no problem to have it in Fedora, but if this is >> something that is going to end up in RHEL one day, it would be better >> to do the work now to make it use OpenSSL rather than scramble later. > > Isn't it at least part of the purpose of Fedora ELN to detect > situations like this earlier? A dependency on boringssl in the Fedora > "Everything" repositories is a distinct thing from it in ELN. Part of the problem is that boringssl isn't a separate package - it typically gets bundled. (This causes mysterious failures because boringssl stomps on the openssl names.) So there wouldn't be a dependency to detect. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: turning off ELN build failure notifications
Kevin Fenzi writes: > On Thu, Jan 14, 2021 at 10:12:46PM +0100, Alexander Ploumistos wrote: >> Hello, >> >> Could someone please help me figure out which rule I need to edit over >> at Fedora Notifications, to stop receiving messages like this one? >> >> On Thu, Jan 14, 2021 at 9:53 PM wrote: >> > >> > Notification time stamped 2021-01-14 20:53:32 UTC >> > >> > bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-25.eln108 >> > failed to build >> > http://koji.fedoraproject.org/koji/buildinfo?buildID=1659686 >> > >> > -- >> > You received this message due to your preference settings at >> > https://apps.fedoraproject.org/notifications/alexpl.id.fedoraproject.org/email/31305 >> >> I thought it should be one of the Jenkins or the CI rules, but from >> their description I don't understand how they could apply to this type >> of event. Ideally, I'd like to never see anything about ELN builds >> failing in my inbox. > > Go there and look for a rule called: > > "Koji builds for packages I own" > > click on it > > On the side in 'generic rules' look for 'a particular user' > > click on it. > > Enter: > > bpeck > > click add > > it should now appear on the left in the rule. > > click on 'negate' > > I think that will do it. Won't this remove all koji notifications, not just the ELN ones? Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek writes: > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/golang1.16 >> >> == Summary == >> Rebase of Golang package to upcoming version 1.16 in Fedora 34, > > No complaint about the Change, but... > can we please stop saying "rebase"? > > That verb made sense when packaging was about a stack of patches and > hacks. Nowadays maybe 90% of packages are just the upstream version, > and another 9% have patches backported from git that will be dropped > on the update to the next upstream version. Talking about a "rebase" > is mostly confusing. Not really a defense, but this is what we call it internally for RHEL. So even if we officially change the name, most of us are likely to keep calling it rebase out of habit. (And it does make sense for RHEL where backporting more patches is the norm. I'm uncomfortable with the assertion that ~99% of all packages have no downstream-only packages, but that might just be my bias in the opposite direction, since I maintain a couple that do.) Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: thinking journal retention timelimits
Matthew Miller writes: > Logs can accidentally contain sensitive data, and it's just plain > faster to work with them when there's less. I propose we set this to > something like six months by default. If there are non-negligible speed impacts from large logs, this seems like a problem with systemd-journald - plain text doesn't have this problem. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
Dan Čermák writes: > Robbie Harwood writes: > >> Ben Cotton writes: >> >>> For swap based actions, systemd-oomd will monitor the system-wide swap >>> space and act when available swap falls below the configured >>> threshold, starting with the cgroups with the highest swap usage to >>> the least. Keeping some amount of swap (if enabled) available will >>> prevent the kernel OOM killer from killing processes unpredictably and >>> spending an unbounded amount of time afterwards. >> >> -1 from me. If the kernel behavior is a problem, fix it - don't kludge >> around it in userspace. > > That is unlikely to happen. As far as I know, the kernel devs see the > kernel oom killer as a kernel self protection measure and want it to > fire as the last resort (and they are quite hesitant to touch > userspace). I believe you are assuming the consequent when you suggest that kernel developers should be somehow fixing this in userspace. To back up: the described problem is the manifestation of an interaction between swap and the OOM condition. The OOM killer is a popularly-understood piece of what goes on in the system during OOM, but it's not like the rest of the kernel can be ignored. (I would argue that part of the reason it's well understood is their insistence that it remain simple, but that's getting off into the weeds.) So, several control points here: - OOM killer behavior. I think we're in agreement that this isn't the thing that needs changed. - Enabling swap. Swap is really slow (by virtue of not being RAM...) and we don't seem willing to acknowledge that. If we want the system to be snappy and responsive... we shouldn't be swapping. - Swap aggressiveness. Suggested by above, people want swap anyway. (Sometimes it's for hibernation (not supported, but that stops no one), sometimes it's for... historical reasons? Underprovisioning?) This could be tuned to the use cases we actually want. - Education. Get people to a point where admins don't deploy swap on systems that aren't going to hibernate. I'll readily admit this one might be hardest. And even possibly the (conceptually) simplest solution of all: - Swap usage monitoring as described for oomd... but in the kernel. This saves you on all the overhead of running in userspace, if nothing else. But what really bothers me here is that, to my knowledge, no one has tried to actually make any of these happen in the kernel. There's a vague perception of what "the kernel devs" want, as if they're some other, but... has anyone asked? If so, we should be able to quote what the response was, and a good design proposal should include it as an explanation of why that route wasn't taken. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
Ben Cotton writes: > For swap based actions, systemd-oomd will monitor the system-wide swap > space and act when available swap falls below the configured > threshold, starting with the cgroups with the highest swap usage to > the least. Keeping some amount of swap (if enabled) available will > prevent the kernel OOM killer from killing processes unpredictably and > spending an unbounded amount of time afterwards. -1 from me. If the kernel behavior is a problem, fix it - don't kludge around it in userspace. Thanks, --Robbie signature.asc Description: PGP signature ___ 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
