Re: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller wrote: > > More data is always better. I like qualifying the situations in that way. I > think we should make our decision based on the "center" rather than the > edges, though. > > For I hope obvious reasons, I'd love to see this tested on a Lenovo X1 > Carbon Gen 8 with the default SSD options. > > And, for benchmarks, I'm thinking more application benchmarks than a > benchmark of the compression itself. How much does compressed /usr affect > boot times for GNOME and KDE? What about startup time for LibreOffice, > Firefox, etc? Any impact on run-time usage? https://paste.centos.org/view/f4165396 Two workloads: install and update. It might seem like an update is both read and write dependent, but the rpms are already compressed and don't get compressed again. The differences, I expect, are mostly write performance. And this suggests it's a wash. I'd say this setup is fairly middle of the pack. The space savings, however, isn't a wash. -- Chris Murphy ___ 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: incorrect docs for forge macro extension, when using 'unknown' scm source (e.g., git.kernel.org) ?
Le jeudi 09 juillet 2020 à 09:40 -0700, PGNet Dev a écrit : > I'm working on a spec, pulling source with forgemeta/scm > > With known/supported scm sources (e.g., github), it works as > expected, with no issues. Because every forge hosting service out there is inventing its own archive export API, it is not possible for the macro to process an unknown source without being taught how this particular service works. That, basically involves writing the lua equivalent of regexpes that contruct the variables forgesetup will use from forgeurl and tag/commit/whatever (you can check in redhat-rpmc-config history how pagure and gitea support was added, they’re the two last supported sources) So, either your need is a one-off, and you can workaround things by setting all the variables forgemeta would have computed if it knew your source, or it’s something generally useful for the long term, and someone needs to add the regexpes In other circumstances, the someone might be me, but I’m getting fed up with everyone else in the project not doing their part and blaming me for doing things alone. So, right now, very unlikely that I will invest more in Fedora without others doing their parts. Regards, -- Nicolas Mailhot ___ 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: Btrfs by default, the compression option
Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit : > > Yes, it's completely reasonable to not do it. It might seem like a > > big > > change on its own, but Btrfs has had native compression for 10+ > > years, > > and at least three years for most all of the workloads at Facebook. > > So > > it's quite safe. > > But it has been eating data as recently as 2018 [1] and the Debian > wiki warns strongly against using compression that is dated for 2020 > [2]. The project will already see a large number of new bugs thanks > to the wider breadth of hardware, why throw in an additional variable > when you can flip it on in six months anyway? Compression will increase the risk of data loss, because compression removes data duplication that could be used to reconstruct data in case of corruption. If you add duplication over compression to make it recovery-safe, the wins are not so good. However, that is consistent with btrf’s recovery story, and reliance on restoring from backups in case of problems. What is the workstation backup story? I would be a lot more confident in this change, if the things Facebook relies on to make btrfs corruption non events, were available workstation side. Regards, -- Nicolas Mailhot ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Fri, Jun 26, 2020 at 6:30 PM Josef Bacik wrote: > > On 6/26/20 11:15 AM, Matthew Miller wrote: > > On Fri, Jun 26, 2020 at 11:13:39AM -0400, Josef Bacik wrote: > >> Not Fedora land, but Facebook installs it on all of our root > >> devices, so millions of machines. We've done this for 5 years. > >> It's worked out very well. Thanks, > > > > Josef, I'd love to hear your comments on any differences between that > > situation and the typical laptop-user case for Fedora desktop systems. > > Anything we should consider? > > > > We buy worse hardware than a typical laptop user uses, at least for our hard > drives. Also we hit our disks harder than most typical Fedora users. > Consider > the web tier for example, we push the entire website to every box in the web > tier (measured in hundreds of thousands of machines) probably 6-10 times a > day. > This is roughly 40 gib of data, getting written to these truly terrible > consumer > grade flash drives (along with some spinning rust), 6-10 times a day. In > addition to the normal sort of logging, package updates, etc that happen. > > Also keep in mind we pay really close attention to burn rates for our drives, > because obviously at our scale it translates to millions of dollars. Btrfs > has > improved our burn rates with the compression, as the write amplification goes > drastically down, thus extending the life of the drives. Hi Josef, Out of curiosity, do you also monitor SMART data for all your hard drives? If yes, have you seen any correlations between specific errors reported by btrfs and those picked up by SMART (not necessarily the fatal ones)? Any useful conclusions? Best regards, A. ___ 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: The future of legacy BIOS support in Fedora.
Le jeudi 09 juillet 2020 à 23:58 -0400, Przemek Klosowski via devel a écrit : > > While it's true that a completely secure software chain doesn't > really exist yet, we are slowly going in that direction, because it > is just inconceivable otherwise in the world with billions of > autonomous IOT devices That’s a joke isn’t it? The problem IOT side is not the security of the software update chain. The problem is that manufacturers skimp on software updates in the first place, and refuse to provide the length of support software-side, that users have come to expect hardware-side. Leading to vast deployments of abandoware. A lot of things, starting with the DRM target that funded secure boot, would not exist if manufacturers were serious about updates, because those systems are increadibly brittle and incompatible with a long term support view. -- Nicolas Mailhot ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
Matthew Miller wrote: > I also don't see any reason to be required to keep unsolicited negative > "private" emails secret. There's no agreement that they should be. > However, I would request that you ignore them rather than bringing them > back to the list. We can unsubscribe and moderate, but we can't do > anything about reading and off-list replies, and I'd prefer for them to > not get dragged back here. (My suggestion is to just ignore.) Well, as I understand it, the main reason he is sending those private replies is that he was banned from the mailing list, or put on moderation or something. If this mailing list were actually a place where people are allowed to voice their technical criticisms without censorship, we would not have this situation to begin with. Judging from the forwarded mail, I disagree with Harald on this particular issue, but that does not mean I think we should not listen to his points. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Btrfs in Silverblue
I haven't seen any mention of Silverblue in the Btrfs discussions. Will Silverblue also switch to Btrfs if the change is approved? I've tested installing Silverblue 32 and Rawhide with the default Btrfs partitioning suggested by Anaconda, and in both cases the system failed to boot after installation. It couldn't mount the Btrfs subvolumes. Is that a known issue or should I report it as a bug? -- Marek Suchánek He / Him / His Technical Writer 2, Customer Content Services Red Hat Czech IM: msuchane ___ 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: Btrfs in Silverblue
On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek wrote: > > I haven't seen any mention of Silverblue in the Btrfs discussions. Will > Silverblue also switch to Btrfs if the change is approved? > > I've tested installing Silverblue 32 and Rawhide with the default Btrfs > partitioning suggested by Anaconda, and in both cases the system failed to > boot after installation. It couldn't mount the Btrfs subvolumes. > > Is that a known issue or should I report it as a bug? > The expectation is that Silverblue will follow along with Workstation, yes. We do know about the bug and have a fix proposed to Anaconda: https://github.com/rhinstaller/anaconda/pull/2720 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs in Silverblue
That's perfect, thanks. So for reference, the fix is to add an option to the kernel command line: rootflags=subvol=$(root_device.name) -- Marek Suchánek He / Him / His Technical Writer 2, Customer Content Services Red Hat Czech IM: msuchane On Fri, Jul 10, 2020 at 12:51 PM Neal Gompa wrote: > On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek > wrote: > > > > I haven't seen any mention of Silverblue in the Btrfs discussions. Will > Silverblue also switch to Btrfs if the change is approved? > > > > I've tested installing Silverblue 32 and Rawhide with the default Btrfs > partitioning suggested by Anaconda, and in both cases the system failed to > boot after installation. It couldn't mount the Btrfs subvolumes. > > > > Is that a known issue or should I report it as a bug? > > > > The expectation is that Silverblue will follow along with Workstation, > yes. We do know about the bug and have a fix proposed to Anaconda: > https://github.com/rhinstaller/anaconda/pull/2720 > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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: Btrfs in Silverblue
On Fri, Jul 10, 2020 at 6:57 AM Marek Suchánek wrote: > > That's perfect, thanks. > > So for reference, the fix is to add an option to the kernel command line: > > rootflags=subvol=$(root_device.name) > Yes, essentially it's the label of the root subvolume. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 7/10/20 5:06 AM, Nicolas Mailhot wrote: The problem IOT side is not the security of the software update chain. The problem is that manufacturers skimp on software updates in the first place Yes, that's the situation right now: everyone has a custom firmware tied to a short product cycle---so new versions and fixes have to be developed separately by everyone. This does not scale, and so it doesn't happen most of the time. I think the only long-term solution is a wide use of platforms, such as Android or Fedora. My point is that however the updates are being produced, they need a secure remote update method. It's not realistic to expect end users to be in the loop---it doesn't scale to the size the IOT is going to be. Moreover, without the secure method, any vulnerability can be easily converted to persistent breakage. Android, actually, is trying to get it right by a) being a platform so that common security updates are available from the platform owner, and can be applied to everyone's system and b) having a secure remote update method. ___ 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: The future of legacy BIOS support in Fedora.
On Thu, Jul 9, 2020 at 5:20 PM Chris Adams wrote: > > Once upon a time, nick...@gmail.com said: > > To be honest, I don't know. Do all UEFI secure boot implementations > > allow you to add your own keys to the list of trusted keys? > > I believe that the Microsoft OEM Windows x86_64 distribution > requirements require UEFI, with Scure Boot enabled, and with the ability > for the system admin to add their own signing keys. So, most every > AMD/Intel system you run across should support that. I don't know this for sure, but from what I've heard, that last point (user management of keys) is no longer a requirement, as is being able to disable Secure Boot. Some of my friends have reported getting laptops from some big vendors without the ability to do either in the last couple of years. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel wrote: > Le 2020-07-08 17:19, Pavel Raiskup a écrit : > > > Small experiment (few-liner) for copr with "%bid, build system tag": > > https://pagure.io/copr/copr/pull-request/1436 > > Well, that ties the system to corp, not koji The %bid macro is definitely meant to be usable with any build system, but I'm proposing that as Copr patch both because it is very trivial for me now and it is simple to test it there without the risk it will hurt anyone's work-flow with Koji. We just can afford to do such experiments there. The worst case scenario in using such macro everywhere is that particular build-system doesn't care about it (keeps it undefined). Pavel ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Thu, Jul 09, 2020 at 02:15:03PM -0400, Matthew Miller wrote: > On Thu, Jul 09, 2020 at 11:09:57AM -0700, Adam Williamson wrote: > > What we're dealing with now is awkward consequences of this change for > > existing installs, where we'd probably want to *keep* modular repos, > > especially if any modules are actually enabled. > > Is it a terrible idea to suggest that MBS insert a "Requires: > fedora-repos-modular" into all of the packages built in that system? > Does rpmbuild have such capability? -- Petr 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
[Bug 1855332] perl-Sereal-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855332 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Sereal-4.017-1.fc33 --- Comment #2 from Petr Pisar --- No changes except the encoder and decoder versions. Suitable for all Fedoras and EPEL ≥ 8. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 09. 07. 20 20:00, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/ModularPolicy == Summary == Establish a set of rules for Modular content in Fedora to ensure an optimal user and packager experience. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email:sgall...@redhat.com == Detailed Description == Over the last several months, members of the Modularity WG and FESCo have been working to establish a policy for module inclusion in Fedora. We now have a proposal that FESCo requested be taken to the Fedora community via the Change Proposal. There is a preview of the new policy available at https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ As said in the modularity docs PR (but I cannot find it now, because pagure.io is down), I am not sure what is the outcome wrt default streams. Default streams are not allowed now. If this change proposal and the policy is approved, does it mean that: 1) default streams are still not allowed (and hence the default streams section of the policy is moot) 2) default streams are allowed (and hence it should be spelled out explicitly and this should be a system wide change proposal) 3) default streams are allowed in ELN, but not in non-ELN Fedora (and hence it should at least be said somewhere - in the policy or in the proposal) 4) something different? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/9/20 2:24 PM, Eric Sandeen wrote: <50 runs later on btrfs> 16 readonly mounts failed (32% failure rate) Within the successful mounts, 1 or more files were unreachable in 30 attempts. Across all 50 attempts, 7720 files were lost. Is that better than ext4, and will ext4 need fsck just to be able to mount? <50 runs later on ext4, same strategy> zero mount failures for ext4. Within the successful mounts, 1 or more files were unreachable in 2 attempts. Across all 50 attempts, 48 files were lost. But for that test to be meaningful, you need to check that the files that ext4 recovers are actually what you expect---after all, if the metadata is damaged and repaired incorrectly, it could point to some random blocks and we'd never know. This is not just theoretical concern---I have seen this type of damage in fsck'ed systems, although I admit it has been long ago. The type of damage might be tricky---for instance part of the file would be correct, but other parts would be wrong, or the file would be truncated. Btrfs will just give up if it screws up. You could see it as good or bad---after all, if a disk holding your pictures went bad, maybe it is useful to see partially damaged pictures, rather than having the filesystem throw up its hands. On the other hand, btrfs being harsh like that basically sends the message to 'backup or else', which may be the right thing in the end. ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On 09. 07. 20 20:19, Adam Williamson wrote: On Thu, 2020-07-09 at 11:09 -0700, Adam Williamson wrote: On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote: On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.) Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right? No, it should be installed by default. Are you talking about upgrades here, or fresh installs? It is not being installed on fresh installs presently, and as I read the ticket, that was intended, per your comment: https://pagure.io/fesco/issue/2114#comment-653352 "Probably best way would be going back to "Boltron" (IIRC how that thing was called) and have modular repos in their own fedora-repos subpackage which are enabled by default, but the package **is not installed by default.**" (emphasis added) Oh, looking at it again, now I see this: https://pagure.io/fesco/issue/2406#comment-658315 which seems to suggest that FESCo expects fedora-repos-modular to be installed out of the box. Well, in yesterday's and today's Rawhide (default Server DVD install) it wasn't, openQA caught this. On my first reading of #2114 I figured this was intentional and adjusted openQA to install fedora-repos-modular , but it sounds like it's actually a bug and comps and/or kickstarts and/or package dependencies will need to be changed. Yes, I was waiting for https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62 to be mergeable before proceeding further. Suddenly it was merged as part of https://src.fedoraproject.org/rpms/fedora-repos/pull-request/65 -- so I quickly created https://pagure.io/fedora-comps/pull-request/510 to avoid this situation. Unfortunately, I wasn't sure if this is the best approach and it wasn't merged right away. I was not expecting the fedora-repos change to be merged before we figure this out :( FTR the details are handled via https://fedoraproject.org/wiki/Changes/ModularReposSubpackage and the tracking bug is https://bugzilla.redhat.com/show_bug.cgi?id=1852028 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel a écrit : > > My point is that however the updates are being produced, they need a > secure remote update method. It's not realistic to expect end users > to be in the loop If you remove end users from the loop there is zero zip nada need for secure boot in the first place. The sole function of secure boot and DRPM is to prevent end users, present in the update loop, from doing things the manufacturer disagreees with. A system, that auto consults a remote update point, over https, checking the certificate of this remote point, has zero need for secure boot. -- Nicolas Mailhot ___ 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
orphaning gabedit
Cc'ing SciTech SIG as this is a science-related package. Hello! I'm orphaning gabedit. It has two bugs open: https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&component=gabedit&product=Fedora Last release was in February this year, so upstream is not dead, but I don't have time to maintain it anymore and I don't use it. Regards, -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On 09. 07. 20 14:24, Petr Pisar wrote: On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote: One just noticed that `dnf autoremove` is trying to remove `fedora- repos-modular` and `fedora-repos-rawhide-modular`. [...] I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`. DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.) Can we amend dnf system-upgrade to do this? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: The future of legacy BIOS support in Fedora.
Hello, Faye. On Saturday, 04 July 2020 at 00:42, Faye C. wrote: [...] > Because of the way Windows 10 is, UEFI is the only thing that is > accepted (no Legacy Boot). If I try any other OS on UEFI my laptop > can't find the disc image. It somehow seems to be designed only for > Windows 10. Legacy Boot is the only way that I can run a different OS. > Despite factory reseting it and doing a clean install of Windows 7, I > still can't use UEFI at all. My laptop isn't that old either, (about a > year and a half) in fact it was really hard to get my intel drivers > working since Intel doesn't support downgrading with newer hardware > that's designed for Windows 10 from what I can see. I'm new to Linux > and have only recently gotten used to Fedora, but if it goes to where > only UEFI is supported I will have to unfortunately go elsewhere. That sadly happens when vendors modify the reference UEFI firmware to support booting Windows only. For example, one of my machines has "Windows Boot Manager" hard-coded as the only boot entry it can boot, so I was able to boot Fedora with UEFI and SecureBoot enabled only by renaming the Fedora boot entry to "Windows Boot Manager". :) Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
> Matthew Miller wrote: > > Well, as I understand it, the main reason he is sending those private > replies is that he was banned from the mailing list, or put on moderation or > something. > > If this mailing list were actually a place where people are allowed to voice > their technical criticisms without censorship, we would not have this > situation to begin with. I think one of the major problems was, which is also evident in the above "private" mail, that it never was only technical and most of the time also included personal insults. I think since he was banned/moderated the overall climate on this mailing list improved considerably. Johannes > > Judging from the forwarded mail, I disagree with Harald on this particular > issue, but that does not mean I think we should not listen to his points. > > Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: dnf autoremove cleans fedora-repos-modular
On 09. 07. 20 12:55, Igor Raits wrote: I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`. How much crazy would it be to call `dnf group upgrade core` equivalent on system-upgrade? See also, https://bugzilla.redhat.com/show_bug.cgi?id=1845562 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: The future of legacy BIOS support in Fedora.
On Fri, Jul 10, 2020 at 07:18:06AM -0400, Neal Gompa wrote: > I don't know this for sure, but from what I've heard, that last point > (user management of keys) is no longer a requirement, as is being able > to disable Secure Boot. Some of my friends have reported getting > laptops from some big vendors without the ability to do either in the > last couple of years. The System.Fundamentals.Firmware.UEFISecureBoot section of the current WHCP v2004 documentation [1] states that: "For devices that are designed to always boot with a specific secure boot configuration, the two requirements ... to support Custom Mode and the ability to disable Secure Boot are optional." (Custom mode: "It shall be possible for a physically present user... to modify the contents of the secure boot signature databases and the PK...") (Enable/Disable: "A physically presnet user must be allowed to disable secure boot via firmware setup... programmatic disabling of secure boot during boot services or after exiting boot services MUST NOT be possible") Note that "specific secure boot configuration" and "locked down platforms" are not defined in this document, but appears to only apply to ARM-based platforms] Additionally, in System.Fundamentals.Firmware.UEFICompatibility "All Windows systems must boot in UEFI mode by default. Other requirements may add additional sections of compatibility to this list, but this is the baseline." "All systems, except servers, must be certified in UEFI mode without activating CSM. If a system is available with 32bit and/or 64bit UEFI, both configurations must be tested for certification." And in System.Fundamentals.Firmware.UEFILegacyFallback: "If the system ships with a UEFI-compatible OS, system firmware must be implemented as UEFI and it must be able to achieve UEFI boot mode by default. Such a system may also support fallback to legacy BIOS boot on systems with OS which do not support UEFI, but only if the user selects that option in a pre-boot firmware user interface. Legacy option ROMs also may not be loaded by default." "An OEM may not ship a 64-bit system which defaults to legacy BIOS ... if that systems ships with a UEFI-compatible OS" The language about servers is a bit muddled but it seems to say that if you're going to ship a 64-bit Windows install it needs to default to, and be certified with, CSM-less UEFI booting. Secure boot is not a requirement for servers. [1] https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/whcp-specifications-policies - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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: The future of legacy BIOS support in Fedora.
On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel wrote: > If you remove end users from the loop there is zero zip nada need for > secure boot in the first place. The sole function of secure boot and > DRPM is to prevent end users, present in the update loop, from doing > things the manufacturer disagreees with. s/manufacturer/device owner/ - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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: The future of legacy BIOS support in Fedora.
On 7/10/20 7:37 AM, Nicolas Mailhot wrote: Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel a écrit : My point is that however the updates are being produced, they need a secure remote update method. It's not realistic to expect end users to be in the loop If you remove end users from the loop there is zero zip nada need for secure boot in the first place. The sole function of secure boot and DRPM is to prevent end users, present in the update loop, from doing things the manufacturer disagreees with. A system, that auto consults a remote update point, over https, checking the certificate of this remote point, has zero need for secure boot. Not quite---as I said in next sentence that you didn't include in your quote, secure boot also tries to prevent unauthorized modifications, for instance resulting from exploited vulnerabilities. It turns out that legitimate owners aren't the only users of IOT :) Look---I agree this is a complex situation. Secure boot has many consequences, and I share your concerns about many of them (walled gardens and loss of control over hardware we own). This does not change the fact that the current technology is inadequate and needs to evolve. ___ 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: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit : > On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel > wrote: > > If you remove end users from the loop there is zero zip nada need > > for > > secure boot in the first place. The sole function of secure boot > > and > > DRPM is to prevent end users, present in the update loop, from > > doing > > things the manufacturer disagreees with. > > s/manufacturer/device owner/ Nope, manufacturer. There are hundreds of other simpler ways to protect device owner side (physical locks on racks, 2FA auth via a physical button on the device or an sms code, etc). The average device is not sold with locks in the supermarket. The home or office or building or rack door is considered sufficient protection. Evil maid does exist, but applying evil maid generally would require putting locks on everything you buy, from the drawers where you may store sensitive documents someday, to the fridge where the evil maid may serve herself on your precious lagger. The threat scenario has been massively ovehyped to justify giving keys to the manufacturers. -- Nicolas Mailhot ___ 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: Btrfs in Silverblue
On Fr, 10.07.20 06:50, Neal Gompa (ngomp...@gmail.com) wrote: > On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek wrote: > > > > I haven't seen any mention of Silverblue in the Btrfs discussions. Will > > Silverblue also switch to Btrfs if the change is approved? > > > > I've tested installing Silverblue 32 and Rawhide with the default Btrfs > > partitioning suggested by Anaconda, and in both cases the system failed to > > boot after installation. It couldn't mount the Btrfs subvolumes. > > > > Is that a known issue or should I report it as a bug? > > > > The expectation is that Silverblue will follow along with Workstation, > yes. We do know about the bug and have a fix proposed to Anaconda: > https://github.com/rhinstaller/anaconda/pull/2720 Instead of passing this in each time on the kernel cmdline, maybe just use "btrfs subvol set-default" to se the default subvolume to mount, after mkfs. That makes things a lot more robust, as btrfs will then just work like any other fs even if you insert the root subvol in between like anaconda apparently does. I think there's big value in allowing short kernel cmdlines that are as similar as possible everywhere, instead of blowing it up with different switches for every single case. Lennart -- Lennart Poettering, Berlin ___ 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: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit : > > > Not quite---as I said in next sentence that you didn't include in > your quote, secure boot also tries to prevent unauthorized > modifications, That does not work either, because if your system is remotely exploitable, it will just be remotely exploited at every boot, and there will be nothing stored persistently for secure boot to block (that is actually how some windows malware started to behave once Microsoft added boot protections). The other usual argument is that digital keys are cheap and physical buttons or locks expensive. Well digital keys are definitely not cheap once you count all the work to keep digital protections up to date and bug free, and physical buttons are definitely not expensive. I have one on every bargain-bin iot plug in my house, to authorise initial pairing. And those buttons will keep working far after the IOT manufacturer will have screwed up the software update part. Regards, -- Nicolas Mailhot ___ 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: The future of legacy BIOS support in Fedora.
On 7/10/20 8:25 AM, Nicolas Mailhot wrote: Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit : Not quite---as I said in next sentence that you didn't include in your quote, secure boot also tries to prevent unauthorized modifications, That does not work either, because if your system is remotely exploitable, it will just be remotely exploited at every boot, and there will be nothing stored persistently for secure boot to block (that is actually how some windows malware started to behave once Microsoft added boot protections). Except that you can fix the vulnerability, push the update and prevent the exploit, even if the vulnerability would somehow be in the boot firmware. For the exploit to win it would have to hit the window just after the boot, which can be prevented. The other usual argument is that digital keys are cheap and physical buttons or locks expensive. Well digital keys are definitely not cheap once you count all the work to keep digital protections up to date and bug free, and physical buttons are definitely not expensive. I have one on every bargain-bin iot plug in my house, to authorise initial pairing. And those buttons will keep working far after the IOT manufacturer will have screwed up the software update part. The marginal cost of a digital key has got to be smaller than the marginal cost of the button. At billions of device, that's the only cost that matters. Again, I am a hardware hacker and I hate the locked devices. But I think the secure updates have to happen, and it turns out that there is almost always a local bypass--JTAG, serial port, whatever. Maybe that is a regulatory issue---like a legal requirement that manufacturers need to publish a local unlock key/code after (or maybe even before) their support schedule ends. ___ 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: Can we do away with release and changelog bumping?
Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit : > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel > wrote: > > Le 2020-07-08 17:19, Pavel Raiskup a écrit : > > > > > Small experiment (few-liner) for copr with "%bid, build system > > > tag": > > > https://pagure.io/copr/copr/pull-request/1436 > > > > Well, that ties the system to corp, not koji > > The %bid macro is definitely meant to be usable with any build > system, That won’t work unless you persist the %bid state so the next build systems knows where to pick up from. And persisting is the part you do not like in my proposal (unless I completely misunderstood what you wrote before). Making things work across build systems without persisting means using an external reference like the clock, and that only works if your build history is completely linear, without scratched branches (intended scratch branches or branches that do not work out, despite the packager initial hopes) Regards, -- Nicolas Mailhot ___ 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: Can we do away with release and changelog bumping?
Le vendredi 10 juillet 2020 à 14:59 +0200, Nicolas Mailhot a écrit :
> Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit :
> > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via
> > devel
> > wrote:
> > > Le 2020-07-08 17:19, Pavel Raiskup a écrit :
> > >
> > > > Small experiment (few-liner) for copr with "%bid, build system
> > > > tag":
> > > > https://pagure.io/copr/copr/pull-request/1436
> > >
> > > Well, that ties the system to corp, not koji
> >
> > The %bid macro is definitely meant to be usable with any build
> > system,
>
> That won’t work unless you persist the %bid state so the next build
> systems knows where to pick up from. And persisting is the part you
> do
> not like in my proposal (unless I completely misunderstood what you
> wrote before).
>
> Making things work across build systems without persisting means
> using
> an external reference like the clock, and that only works if your
> build
> history is completely linear, without scratched branches (intended
> scratch branches or branches that do not work out, despite the
> packager initial hopes)
Also, if you do not persist, your build won’t be reproducible in a
third party buildd system, because reproducing requires knowing the
%{bid} value you used in your own build.
--
Nicolas Mailhot
___
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
Golang 1.15 - Late Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/golang1.15
== Summary ==
Rebase of Golang package to upcoming version 1.15 in Fedora 33,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jca...@redhat.com, alexsa...@redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.15 in Fedora 33. Golang
1.15 is schedule to be released in August 2020.
Due to current nature and state of Go packages, rebuild of dependent
package will be required to pick up the changes.
== Benefit to Fedora ==
Staying closely behind upstream by providing latest release of golang,
which includes performance improvements and improvements in support
for currently supported platforms among other bug fixes and new
features. For complete list of changes see upstream change notes at
https://tip.golang.org/doc/go1.15 . In result Fedora will be providing
solid development platform for Go language.
== Scope ==
* Proposal owners: Rebase golang package in Fedora 33, help with
resolving possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking ticket
https://pagure.io/releng/issue/9548
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How To Test ==
;0.
:a)Install golang 1.15 from rawhide and use it to build your
application(s)/package(s).
:b)Scratch build against rawhide.
;1.
:Your application/package built using golang 1.15 should work as expected.
== User Experience ==
None
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed ~1300.
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.14.X if
significatnt issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.15
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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: Golang 1.15 - Late Fedora 33 System-Wide Change proposal
Note that this proposal was prepared prior to the deadline, but due to
an error in wiki formatting, it did not appear in the queue.
On Fri, Jul 10, 2020 at 9:40 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/golang1.15
>
> == Summary ==
> Rebase of Golang package to upcoming version 1.15 in Fedora 33,
> including rebuild of all dependent packages(pre-release version of Go
> will be used for rebuild, if released version will not be available at
> the time of the mass rebuild).
>
> == Owner ==
> * Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
> Morollón]]
> * Email: jca...@redhat.com, alexsa...@redhat.com
>
> == Detailed Description ==
>
> Rebase of Golang package to upcoming version 1.15 in Fedora 33. Golang
> 1.15 is schedule to be released in August 2020.
> Due to current nature and state of Go packages, rebuild of dependent
> package will be required to pick up the changes.
>
> == Benefit to Fedora ==
>
> Staying closely behind upstream by providing latest release of golang,
> which includes performance improvements and improvements in support
> for currently supported platforms among other bug fixes and new
> features. For complete list of changes see upstream change notes at
> https://tip.golang.org/doc/go1.15 . In result Fedora will be providing
> solid development platform for Go language.
>
>
> == Scope ==
> * Proposal owners: Rebase golang package in Fedora 33, help with
> resolving possible issues found during package rebuilds.
> * Other developers: Fix possible issues, with help from golang maintainers.
>
> * Release engineering: Rebuild of dependent packages as part of
> planned mass-rebuild. Tracking ticket
> https://pagure.io/releng/issue/9548
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
>
> == Upgrade/compatibility impact ==
> None
>
> == How To Test ==
> ;0.
> :a)Install golang 1.15 from rawhide and use it to build your
> application(s)/package(s).
> :b)Scratch build against rawhide.
> ;1.
> :Your application/package built using golang 1.15 should work as expected.
>
> == User Experience ==
> None
> == Dependencies ==
>
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'golang'
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'compiler(go-compiler)'
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'compiler(golang)'
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'go-rpm-macros'
>
>
> Omitted due to the number of packages listed ~1300.
>
>
> Not all of listed require re-build as they might not ship binaries
> and/or do not use golang compiler during build, but only use Go rpm
> macros that pull it in to every build root.
>
> == Contingency Plan ==
> * Contingency mechanism:Reverting to golang version 1.14.X if
> significatnt issues are discovered.
> * Contingency deadline: Beta Freeze(?)
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
> https://tip.golang.org/doc/go1.15
>
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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: Btrfs by default, the compression option
On Fri, Jul 10, 2020 at 12:59:37AM -0600, Chris Murphy wrote: > https://paste.centos.org/view/f4165396 > > Two workloads: install and update. It might seem like an update is > both read and write dependent, but the rpms are already compressed and > don't get compressed again. The differences, I expect, are mostly > write performance. And this suggests it's a wash. I'd say this setup > is fairly middle of the pack. > > The space savings, however, isn't a wash. And if I'm reading it right, a significant win for either btrfs setup over ext4. -- Matthew Miller Fedora Project Leader ___ 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: [Rawhide] Blender failed to build
Right, upstream provided a patch which landed on Rawhide: https://developer.blender.org/rB56d0df51a36fdce7ec2d1fbb7b47b1d95b591b5f Could someone having python expertise check it please? Thanks. On 2020-07-09 1:34 a.m., Miro Hrončok wrote: On 09. 07. 20 10:22, Dan Horák wrote: On Thu, 9 Jul 2020 01:08:57 -0700 Luya Tshimbalanga wrote: Hello team, Could someone investigate the failure on Blender 2.83.2 as tested on the scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=46849313 I don't know what exactly causes the issue. Here is the source files: /builddir/build/BUILD/blender-2.83.2/source/blender/python/mathutils/mathutils_Matrix.c:45:40: error: unknown type name 'PyNoArgsFunction'; did you mean 'PyCFunction'? 45 | static PyObject *matrix__apply_to_copy(PyNoArgsFunction matrix_func, MatrixObject *self); | ^~~~ | PyCFunction might be a Python 3.9 compatibility issue It is. https://bugzilla.redhat.com/show_bug.cgi?id=1843100 https://bugs.python.org/issue39372 -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ 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: Btrfs by default, the compression option
On Fri, Jul 10, 2020, 8:37 AM Matthew Miller wrote: > On Fri, Jul 10, 2020 at 12:59:37AM -0600, Chris Murphy wrote: > > https://paste.centos.org/view/f4165396 > > > > Two workloads: install and update. It might seem like an update is > > both read and write dependent, but the rpms are already compressed and > > don't get compressed again. The differences, I expect, are mostly > > write performance. And this suggests it's a wash. I'd say this setup > > is fairly middle of the pack. > > > > The space savings, however, isn't a wash. > > And if I'm reading it right, a significant win for either btrfs setup over > ext4. Space wise or the update time? I think the install times are moderated by the installer image being tightly bound by xz decompression. The same happens to zstd compressed RPM for updates, to a lesser degree, and it might be better threaded, so we see a bigger difference. There is also noise contributed by the fact it's done in a VM, and using sparse files. That could have disproportionately penalized ext4. But as a sanity test that there isn't anything particular screwy going on performance wise, it's probably fine. For example, the kernel load times. Why is the compressed btrfs one so much faster? Twice. Weird. All three setups, the kernel is on ext4. All six should be the same. So there is error. -- Chris Murphy ___ 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: Btrfs in Silverblue
On Fri, Jul 10, 2020, 6:07 AM Lennart Poettering wrote: > On Fr, 10.07.20 06:50, Neal Gompa (ngomp...@gmail.com) wrote: > > > On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek > wrote: > > > > > > I haven't seen any mention of Silverblue in the Btrfs discussions. > Will Silverblue also switch to Btrfs if the change is approved? > > > > > > I've tested installing Silverblue 32 and Rawhide with the default > Btrfs partitioning suggested by Anaconda, and in both cases the system > failed to boot after installation. It couldn't mount the Btrfs subvolumes. > > > > > > Is that a known issue or should I report it as a bug? > > > > > > > The expectation is that Silverblue will follow along with Workstation, > > yes. We do know about the bug and have a fix proposed to Anaconda: > > https://github.com/rhinstaller/anaconda/pull/2720 > > Instead of passing this in each time on the kernel cmdline, maybe just > use "btrfs subvol set-default" to se the default subvolume to mount, > after mkfs. > > That makes things a lot more robust, as btrfs will then just work like > any other fs even if you insert the root subvol in between like > anaconda apparently does. > > I think there's big value in allowing short kernel cmdlines that are > as similar as possible everywhere, instead of blowing it up with > different switches for every single case. I agree with all of the above, but there is a contra argument. There is something to be said about having an understandable system, one that self describes how it's assembled, and boots. Changing the default subvolume obscures this, and now one of the "connect the dots" steps of boot becomes a dot on a completely different page in another book. Therefore I'm not certain. -- Chris Murphy ___ 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: [Rawhide] Blender failed to build
On 10. 07. 20 17:22, Luya Tshimbalanga wrote: Right, upstream provided a patch which landed on Rawhide: https://developer.blender.org/rB56d0df51a36fdce7ec2d1fbb7b47b1d95b591b5f Could someone having python expertise check it please? If it builds, ship it :) (The changes look reasonable.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Btrfs in Silverblue
On Fri, Jul 10, 2020 at 09:34:36AM -0600, Chris Murphy wrote: > On Fri, Jul 10, 2020, 6:07 AM Lennart Poettering > wrote: > > > On Fr, 10.07.20 06:50, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek > > wrote: > > > > > > > > I haven't seen any mention of Silverblue in the Btrfs discussions. > > Will Silverblue also switch to Btrfs if the change is approved? > > > > > > > > I've tested installing Silverblue 32 and Rawhide with the default > > Btrfs partitioning suggested by Anaconda, and in both cases the system > > failed to boot after installation. It couldn't mount the Btrfs subvolumes. > > > > > > > > Is that a known issue or should I report it as a bug? > > > > > > > > > > The expectation is that Silverblue will follow along with Workstation, > > > yes. We do know about the bug and have a fix proposed to Anaconda: > > > https://github.com/rhinstaller/anaconda/pull/2720 > > > > Instead of passing this in each time on the kernel cmdline, maybe just > > use "btrfs subvol set-default" to se the default subvolume to mount, > > after mkfs. > > > > That makes things a lot more robust, as btrfs will then just work like > > any other fs even if you insert the root subvol in between like > > anaconda apparently does. > > > > I think there's big value in allowing short kernel cmdlines that are > > as similar as possible everywhere, instead of blowing it up with > > different switches for every single case. > > > I agree with all of the above, but there is a contra argument. There is > something to be said about having an understandable system, one that self > describes how it's assembled, and boots. Changing the default subvolume > obscures this, and now one of the "connect the dots" steps of boot becomes > a dot on a completely different page in another book. > > Therefore I'm not certain. I agree with both of you, but I think the concept of default subvolume is fairly natural and does not make things more confusing. When I pause to think about this, I know that the root subvolume is "just a subvolume", but by default I think of the the root subvolume as the partition itself and the other subvolumes as less important. So elevating the root subvolume to be the default subvolume feels right. Zbyszek ___ 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: incorrect docs for forge macro extension, when using 'unknown' scm source (e.g., git.kernel.org) ?
On 7/10/20 1:26 AM, Nicolas Mailhot wrote: Le jeudi 09 juillet 2020 à 09:40 -0700, PGNet Dev a écrit : I'm working on a spec, pulling source with forgemeta/scm With known/supported scm sources (e.g., github), it works as expected, with no issues. involves writing the lua equivalent of regexpes that contruct the variables forgesetup will use from forgeurl and tag/commit/whatever (you can check in redhat-rpmc-config history how pagure and gitea support was added, they’re the two last supported sources) That something needs to be added/written/worked-around is clear. To do that effectively, I've simply asked > (1) Are there up-to-date/correct docs for 'Extending the macro' ? > > (2) Is there an explcit example for use with 'git.kernel.org' sources? In other circumstances, the someone might be me, but I’m getting fed up with everyone else in the project not doing their part and blaming me for doing things alone. So, right now, very unlikely that I will invest more in Fedora without others doing their parts. I don't know you to 'blame you', and certainly haven't here. If your issue is with others, then perhaps you might take it up with _them_? ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 26.06.2020 16:42, Ben Cotton wrote: > ** transparent compression: significantly reduces write amplification, > improves lifespan of storage hardware What can you say about this? https://arxiv.org/pdf/1707.08514.pdf -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Friday, July 10, 2020, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 26.06.2020 16:42, Ben Cotton wrote: > > ** transparent compression: significantly reduces write amplification, > > improves lifespan of storage hardware > > What can you say about this? https://arxiv.org/pdf/1707.08514.pdf It doesn't use compression so not relevant to the cited statement? > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > 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 > ___ 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: out of Koji disk space
On Thu, Jul 09, 2020 at 06:15:54PM +0200, Jan Kratochvil wrote: > On Tue, 07 Jul 2020 21:11:31 +0200, Kevin Fenzi wrote: > > I am not sure what to tell you here. Perhaps you could describe the > > reason you are working on the chromium debuginfo? Is it broken? Missing? > > Less useful that normal? > > Missing. Completely. > > And it is not just about enabling it (=remove its disable) because with > default Fedora building options (no -fdebug-types-section and using DWZ) the > build will fail. That is because debuginfo will exceed 4GB which is the limit > of DWARF32 format and GNU tools do not much support DWARF64. > Enable debuginfo for x86_64 and aarch64. > https://src.fedoraproject.org/rpms/chromium/pull-request/27 > > > > All I see in this thread is that you were working on it and it increased > > disk space usage, I must have missed the background/goal here? > > The goal is to have debuginfo for Chromium. Or why other Fedora packages have > debuginfo but Chromium does not? Well, if you can't convince the maintainer, you're welcome to escalate it to FESCo I suppose. I don't think there's a guideline that requires them to exist, but they are definitely handy sometimes. Perhaps a compromise could be to generate them for rawhide builds, but not stable releases and if someone needs to debug things ask them to use the rawhide one/debuginfo? kevin PS: I'm subscribed to the list, there's no need to specifically cc me on posts. 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
> It doesn't use compression so not relevant to the cited statement? Well the paper compares ext2, ext4, xfs, f2fs, and btrfs in terms of IO amplification and states: "In fact, in all our experiments, btrfs was an outlier, producing the highest read, write, and space amplification." The results listed in Tables 1 and 2 show that btrfs does incur higher amounts of IO, so even with compression it's not at all obvious that this would bring btrfs down to levels comparable to (or lower than) the other file systems. Hence I believe Vitaly is linking this paper to suggest that evidence is needed before we can confidently assert that btrfs + compression is better at preserving nand than using ext4 or xfs. ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/10/20 10:14 AM, Vitaly Zaitsev via devel wrote: On 26.06.2020 16:42, Ben Cotton wrote: ** transparent compression: significantly reduces write amplification, improves lifespan of storage hardware What can you say about this? https://arxiv.org/pdf/1707.08514.pdf I would say that it illustrates the reason that compression is being proposed. What did you take away from it? ___ 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: Btrfs in Silverblue
On Fr, 10.07.20 09:34, Chris Murphy (li...@colorremedies.com) wrote: > > That makes things a lot more robust, as btrfs will then just work like > > any other fs even if you insert the root subvol in between like > > anaconda apparently does. > > > > I think there's big value in allowing short kernel cmdlines that are > > as similar as possible everywhere, instead of blowing it up with > > different switches for every single case. > > I agree with all of the above, but there is a contra argument. There is > something to be said about having an understandable system, one that self > describes how it's assembled, and boots. Changing the default subvolume > obscures this, and now one of the "connect the dots" steps of boot becomes > a dot on a completely different page in another book. I am pretty sure a self-describing system is the best system. And if one subvolume is marked "as default" and then booted into "as default" then that's fantastically self-descriptive. The concept of default subvolumes exists, for cases like this, and it simplifies things and makes them more robust. There's really no need to complicate things by pushing btrfsisms into user-visible concepts needlessly. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Fri, Jul 10, 2020 at 07:14:09PM +0200, Vitaly Zaitsev via devel wrote: > On 26.06.2020 16:42, Ben Cotton wrote: > > ** transparent compression: significantly reduces write amplification, > > improves lifespan of storage hardware > > What can you say about this? https://arxiv.org/pdf/1707.08514.pdf Also funny note: when compression was introduced in ZFS, circa 2007, it was mainly promoted as _performance_ win, not a space saving measure. This was still 5 years before NVMe, so all we had was SATA, SAS and FC drives, yet the CPUs were already multi-core and multi-gigahertz. Transfering uncompressed data was _slower_ than compressing/decompressing and having to transfer less data. For a bit higher CPU usage we got noticeable bandwidth wins. The tradeoff is no longer there, as single drives reach 7GiB/s transfer speed. -- Tomasz TorczOnly gods can safely risk perfection, to...@pipebreaker.pl it's a dangerous thing for a man. — Alia ___ 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
X.org Utility Deaggregation - Fedora 33 Self-Contained Change proposal
https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
== Summary ==
The collection packages
`xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}` will be
retired, and the individual utilities within them will be packaged
separately.
== Owner ==
* Name: [[User:ajax|Adam Jackson]]
* Email: a...@redhat.com
== Detailed Description ==
The `xorg-x11-*` collection packages are somewhat arbitrary
collections of the stock utilities and sample applications from the
X.org distribution, mostly for the convenience of comps and other
package-set-definition tooling. Typically not all of the utilities in
a given package will be needed simultaneously, and the version numbers
of the package do not logically reflect the upstream version of any
particular component. Most of the packages that require a particular
component Require that specific component name, as opposed to the
collection package. In addition, some of the components (notably
`luit` and `edid-decode`) are not in fact X.org packages anymore but
have other upstreams.
Deaggregating the individual components will allow for smaller
installed image sizes, less frequent rebuilds for unrelated changes,
and greater flexibility in choice of upstream.
== Feedback ==
It is not strictly necessary to retire the collection packages, they
could instead be converted to metapackages like `xorg-x11-drivers`
that simply Require all the things they used to Provide. However, as
the majority of consumers of these utilities depend on the specific
utility and not the collection, retiring them should require touching
quite few consumers. On the other hand, the upgrade migration path is
more difficult if the collections are retired. I'm open to either
approach.
== Benefit to Fedora ==
1. Smaller installed footprint due to eliminating unused leaf utilities.
2. Utilities will be rebuilt only as they actually change.
3. Utilities that have a new home besides X.org will not be deceptively named.
== Scope ==
* Proposal owners:
Prepare new independent packaging of each utility, and update or
retire the corresponding collection packages. This is a few dozen new
packages, but they are all nearly trivial.
* Other developers: N/A (not a System Wide Change)
* Release engineering:
We may want to update comps to include the new packages, or we may
simply allow them to be brought in by the packages that actually
Require them.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
If the collection packages are retired, the new packaging will need to
Obsolete the old collection packages.
== How To Test ==
Spins and package sets that currently include the collection packages
should be tested to verify that they still contain everything they
need after this conversion.
== User Experience ==
Marginally smaller installed image, fewer unrelated updates.
== Dependencies ==
Full list of affected consumer packages TBD.
== Contingency Plan ==
Leave the packaging as it is.
== Documentation ==
None.
== Release Notes ==
Release notes should reflect the fact that the collection packages
have been retired or made meta, and the list of affected utilities
should be noted.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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
Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS == Summary == This proposal adds cgroup based resource protections for the active graphical session. This is done by passing a memory protection of 250MiB to active users (capped at 10% of system memory) and by enabling other cgroup controllers (CPU, IO) to ensure important session processes get the resources they need. See: https://pagure.io/fedora-workstation/issue/154 == Owner == * Name: [[User:benzea|Benjamin Berg]] * Email: bb...@redhat.com * Product: Workstation * Responsible WG: Workstation == Detailed Description == Graphical sessions should always be responsive, even when the machine is doing a lot work or in the extreme case has started to thrash. We have started to ship EarlyOOM with F32, however, while it is a good solution to this date, it is shipped with the understanding of being superseded by other approaches in the future. With `uresourced` a small daemon was written that enables protection of the graphical user session. It serves the following main purposes: * Safely modify existing GNOME systemd units to closer adhere to https://systemd.io/DESKTOP_ENVIRONMENTS/ (until this is merged upstream). * Enables the CPU and IO cgroup controllers for users to prevent e.g. fork bombs from taking over the system. * Allocates a memory guarantee for any *active* user which is distributed to core session processes. Precautions are in place to not negatively affect systems: * Active users will receive a protected memory allocation of 250MiB allocation, but capped at 10% of system memory. So low memory systems should not be negatively impacted. Said differently, the memory subsystem treats the core session processes in comparison to everything else as if they were using 250MiB less than they actually are. * `uresourced` detects whether the user session is using systemd to prevent passing memory guarantees to processes that are not important (e.g. not a GNOME session). * Enabling the IO controller has no effect on Fedora currently. NOTES: * `uresourced` is designed to be obsoleted. Everything it does should be absorbed by other upstreams. However, it is a good and safe solution that eases development and permits shipping the benefits to users now. * Enabling the cgroup controllers may slightly increase the scheduling overhead that the kernel imposes. I don't have numbers right now, but expect this to be <=1% of overall system CPU time. == Benefit to Fedora == This change proposal will improve interactivity of graphical sessions in certain situations. It also is an important step on the path to reap the benefits of systemd and cgroups in workstation scenarios. == Scope == * Proposal owners: * Install `uresourced` on workstations by default * Add a preset to enable `uresourced` by default * Other developers: no further changes are needed * Release engineering: [https://pagure.io/releng/issue/9592] * Policies and guidelines: N/A (not needed) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact. The worst case scenario is that the feature will not be enabled. == How To Test == Testing this has multiple aspects. From the technical side, a test is as simple as: * Install and enable `uresourced` * Reboot (to make absolutely sure the user session has picked up all changes, logout may *not* be sufficient) * Check values in `/sys/fs/cgroup/user.slice/memory.low`, `/sys/fs/cgroup/user.slice/user-1000.slice/memory.low`, `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/memory.low` and `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/memory.low` (should usually be 250MiB with the default configuration). * Verify that the allocation is zero if the user is not active on any seat (e.g. switch to GDM and log in via SSH or by doing a `sleep 10; cat ...` and coming back). * Check enabled controllers in `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.controllers` (should be `cpu io memory pids`). Beyond that, a test can be done to show that the cgroup kernel controllers are actually beneficial in various scenarios. Possible examples are: * Running mprime (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); choose local stress test, repeat by selecting 15 NOTE: mcatanzaro has reported a huge impact, with both the session remaining mostly responsive and EarlyOOM not kicking in (this makes sense, as overall memory pressure is much lower, i.e. the session is waiting on memory related IO less). The proposal owners have not been able to reproduce this corner case so far. * Log in two user A and B (same seat), run `stress-ng -c NCPUS` in both. Switch between them and look at `top` to verify that the active user gets a 5 times higher CPU share overall. == User Experience == See other sections. == Dependencies == There are no further dependencies. == Contingency Plan == * Contingency mechanism: Remove uresourced f
Re: Btrfs by default, the compression option
Maybe Workstation could provide Déjà Dup in the default system to make it discoverable and encourage users to create backups. It has to be an installed application (can’t be a website), and most users would benefit from having backups. ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Friday, July 10, 2020 2:27:02 AM MST Kevin Kofler wrote: > Matthew Miller wrote: > > > I also don't see any reason to be required to keep unsolicited negative > > "private" emails secret. There's no agreement that they should be. > > However, I would request that you ignore them rather than bringing them > > back to the list. We can unsubscribe and moderate, but we can't do > > anything about reading and off-list replies, and I'd prefer for them to > > not get dragged back here. (My suggestion is to just ignore.) > > > Well, as I understand it, the main reason he is sending those private > replies is that he was banned from the mailing list, or put on moderation or > something. > > If this mailing list were actually a place where people are allowed to voice > their technical criticisms without censorship, we would not have this > situation to begin with. > > Judging from the forwarded mail, I disagree with Harald on this particular > issue, but that does not mean I think we should not listen to his points. Agreed, it's unfortunate that he was banned from this list. My only criticism was being contacted in private for what I felt was more for the list. At the time, I wasn't aware that the individual was banned from the list. -- John M. Harris, Jr. ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Thursday, July 9, 2020 2:19:27 PM MST Przemek Klosowski via devel wrote: > On 7/9/20 8:44 AM, Kevin Kofler wrote: > > > Przemek Klosowski via devel wrote: > > > >>* disk access is literally O(1) slower than RAM access > > > > This notation is meaningless. By the definition of the O notation, > > O(1)=O(1)=O(k) for any constant k. > > > Yes, you are right of course, but I just hope that everyone understood > that was just a shortcut for saying that the speed ratio is somewhere > between 1e3 and 1e5 That's not accurate, as demonstrated earlier. At least, it's not accurate for my hardware. I haven't tested on anything more recent. -- John M. Harris, Jr. ___ 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: The future of legacy BIOS support in Fedora.
On Friday, July 10, 2020 4:12:42 AM MST Przemek Klosowski via devel wrote: > On 7/10/20 5:06 AM, Nicolas Mailhot wrote: > > > The problem IOT side is not the security of the > > software update chain. The problem is that manufacturers skimp on > > software updates in the first place > > > Yes, that's the situation right now: everyone has a custom firmware tied > to a short product cycle---so new versions and fixes have to be > developed separately by everyone. This does not scale, and so it doesn't > happen most of the time. I think the only long-term solution is a wide > use of platforms, such as Android or Fedora. > > My point is that however the updates are being produced, they need a > secure remote update method. It's not realistic to expect end users to > be in the loop---it doesn't scale to the size the IOT is going to be. > Moreover, without the secure method, any vulnerability can be easily > converted to persistent breakage. > > Android, actually, is trying to get it right by a) being a platform so > that common security updates are available from the platform owner, and > can be applied to everyone's system and b) having a secure remote update > method. The problem with implementing systems such as this is obvious.. If the end user cannot upload their own firmware, because the host has a hardware mechanism for checking the signature of the firmware, that's not good for the end user, it's harmful. It would mean they don't actually own the system, the vendor does. -- John M. Harris, Jr. ___ 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: The future of legacy BIOS support in Fedora.
On Friday, July 10, 2020 5:05:51 AM MST Nicolas Mailhot via devel wrote: > Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit : > > > On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel > > wrote: > > > > > If you remove end users from the loop there is zero zip nada need > > > for > > > secure boot in the first place. The sole function of secure boot > > > and > > > DRPM is to prevent end users, present in the update loop, from > > > doing > > > things the manufacturer disagreees with. > > > > > > s/manufacturer/device owner/ > > > Nope, manufacturer. There are hundreds of other simpler ways to protect > device owner side (physical locks on racks, 2FA auth via a physical > button on the device or an sms code, etc). > > The average device is not sold with locks in the supermarket. The home > or office or building or rack door is considered sufficient > protection. > > Evil maid does exist, but applying evil maid generally would require > putting locks on everything you buy, from the drawers where you may > store sensitive documents someday, to the fridge where the evil maid > may serve herself on your precious lagger. > > The threat scenario has been massively ovehyped to justify giving keys > to the manufacturers. Please note that SMS two factor has been known to be insecure since 2005, and NIST has recommended against it for just as long. (Before a bit of nonsense in 2016-2017, which I think has been corrected?) -- John M. Harris, Jr. ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Friday, July 10, 2020 4:39:21 AM MST Miro Hrončok wrote: > On 09. 07. 20 14:24, Petr Pisar wrote: > > > On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote: > > > >> One just noticed that `dnf autoremove` is trying to remove `fedora- > >> repos-modular` and `fedora-repos-rawhide-modular`. > >> > >> > >> > > [...] > > > >> I don't know where / which the fix should be: DNF, comps or both. > >> Simply putting the fedora-repos-modular in comps won't help since DNF > >> is only using them when running `group install/update/remove`. > >> > >> > >> > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action > > on a system upgrade, because we want that package to be prensented on > > the system. However I worry that DNF does not possess a capability for > > doing it. (Except of injecting that command into some externally executed > > script.) > > > Can we amend dnf system-upgrade to do this? Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that? -- John M. Harris, Jr. ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On 10. 07. 20 23:35, John M. Harris Jr wrote: DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.) Can we amend dnf system-upgrade to do this? Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that? My idea was: if fedora-repos-modular is installed: dnf mark install fedora-repos-modular else: pass -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
poppler soname bump in rawhide
Hi, I've prepared rebase of poppler to 0.90.0 in the side tag "f33-build-side-25167". I ask you to build your dependent packages in it and I will ask to merge it to main branch next Friday (17th of July). There are several API changes and soname bump of the base library libpoppler.so.*. Btw, if your package uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt5, C++)? It would mean less work for you. Also, if your package still uses qt4 frontend, try to use another one since this was removed in upstream and we have it just as a backup solution which I plan to remove in next rebase (the one for Fedora 34). I'll notice corresponding maintainers separately. Regards Marek ___ 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: PSA: dnf autoremove cleans fedora-repos-modular
On Friday, July 10, 2020 2:53:30 PM MST Miro Hrončok wrote: > On 10. 07. 20 23:35, John M. Harris Jr wrote: > > >>> DNF should perform "dnf mark install fedora-repos-rawhide-modular" > >>> action > >>> on a system upgrade, because we want that package to be prensented on > >>> the system. However I worry that DNF does not possess a capability for > >>> doing it. (Except of injecting that command into some externally > >>> executed > >>> script.) > >> > >> > >> > >> Can we amend dnf system-upgrade to do this? > > > > Wouldn't that install modular repos on systems that end users have removed > > it from? Is there a way around that? > > > My idea was: > > if fedora-repos-modular is installed: > dnf mark install fedora-repos-modular > else: > pass Ah, gotcha. Sounds like a plan. -- John M. Harris, Jr. ___ 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: Btrfs in Silverblue
On Fri, Jul 10, 2020 at 12:16 PM Lennart Poettering wrote: > > On Fr, 10.07.20 09:34, Chris Murphy (li...@colorremedies.com) wrote: > > > > That makes things a lot more robust, as btrfs will then just work like > > > any other fs even if you insert the root subvol in between like > > > anaconda apparently does. > > > > > > I think there's big value in allowing short kernel cmdlines that are > > > as similar as possible everywhere, instead of blowing it up with > > > different switches for every single case. > > > > I agree with all of the above, but there is a contra argument. There is > > something to be said about having an understandable system, one that self > > describes how it's assembled, and boots. Changing the default subvolume > > obscures this, and now one of the "connect the dots" steps of boot becomes > > a dot on a completely different page in another book. > > I am pretty sure a self-describing system is the best system. And if > one subvolume is marked "as default" and then booted into "as default" > then that's fantastically self-descriptive. > > The concept of default subvolumes exists, for cases like this, and it > simplifies things and makes them more robust. > > There's really no need to complicate things by pushing btrfsisms into > user-visible concepts needlessly. It's been this way in Fedora for a decade. The behavior is baked into the installer, and bootloader scripts. The 'rootflags' boot parameter is added by the grub-mkconfig scripts. It's upstreamed. When I say understandable, I mean a user can follow a trail of breadcrumbs for boot, startup, and assembly: not just rootflags, but also that systemd at sysroot mount time, also uses the 'subvol=' mount option. Whereas if this is a leap, they can't follow it. If the user mounts this file system elsewhere, including from a livecd, they actually won't see their home, it's hidden. How are they supposed to know where it is or how to find it, without learning btrfsisms? I've seen a lot more confusion from the (open)SUSE use of set-default than on Fedora where it isn't used. *shrug* I agree Fedora way is more verbose. But that also makes it easier to understand and troubleshoot and *not* have to know about decoder rings like "btrfs subvolume get-default" in order to find out why some subvolume is always mounted, the others are all invisible. This all relates to a possible snapshotting and rollback feature too. And that's going to take design and planning, including Anaconda, bootloader, and desktop teams being onboard. I'm disinclined to add churn almost everywhere else, just to eliminate one boot parameter. -- Chris Murphy ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/drop_mod_php > > == Summary == > mod_php (apache2handler) is an optional httpd module to execute PHP > scripts, not used. > > == Owner == > * Name: [[User:Remi| Remi Collet]] > * Email: remi at fedoraproject dot org > > > == Detailed Description == > By default php-fpm is used for a few versions. mod_php is not > supported for threaded modules. mod_php usage also increases security > risk, sharing the same process than httpd. > > Drop mod_php from php build. This will only affect user of httpd in > "prefork" mode, which will also use php-fpm. > > php-fpm is already used but most users of httpd and nginx without any > issue. > The "php" package will be kept as a metapackage, installing (weak > dependencies) most commonly used extension, thus reducing the > difference between "yum install php" (flat repository) and "yum module > install php" (modular repository). > > == Benefit to Fedora == > > Only provide the modern way to execute PHP in a web server. > > == Scope == > > PHP rebuild (mod_php build is already conditional) > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > * install and play with your web applications > > == User Experience == > > No change. > > > == Dependencies == > > None (dependency on "php" is already forbidden by Guidelines) > > == Contingency Plan == > * revert > > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change), Yes/No > * Blocks product? product > > == Documentation == Now that this has been accepted, I take it that the current maintainer of mod_php no longer wants to maintain it? I'd like to offer to take over the package if that's the case, so that Fedora will continue to work for those using mod_php. -- John M. Harris, Jr. ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr wrote: > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > == Summary == > > mod_php (apache2handler) is an optional httpd module to execute PHP > > scripts, not used. > > > > == Owner == > > * Name: [[User:Remi| Remi Collet]] > > * Email: remi at fedoraproject dot org > > > > > > == Detailed Description == > > By default php-fpm is used for a few versions. mod_php is not > > supported for threaded modules. mod_php usage also increases security > > risk, sharing the same process than httpd. > > > > Drop mod_php from php build. This will only affect user of httpd in > > "prefork" mode, which will also use php-fpm. > > > > php-fpm is already used but most users of httpd and nginx without any > > issue. > > > The "php" package will be kept as a metapackage, installing (weak > > dependencies) most commonly used extension, thus reducing the > > difference between "yum install php" (flat repository) and "yum module > > install php" (modular repository). > > > > == Benefit to Fedora == > > > > Only provide the modern way to execute PHP in a web server. > > > > == Scope == > > > > PHP rebuild (mod_php build is already conditional) > > > > * Other developers: N/A (not a System Wide Change) > > * Release engineering: N/A > > * Policies and guidelines: N/A (not a System Wide Change) > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > N/A (not a System Wide Change) > > > > == How To Test == > > > > * install and play with your web applications > > > > == User Experience == > > > > No change. > > > > > > == Dependencies == > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > == Contingency Plan == > > * revert > > > > * Contingency deadline: N/A (not a System Wide Change) > > * Blocks release? N/A (not a System Wide Change), Yes/No > > * Blocks product? product > > > > == Documentation == > > Now that this has been accepted, I take it that the current maintainer of > mod_php no longer wants to maintain it? I'd like to offer to take over the > package if that's the case, so that Fedora will continue to work for those > using mod_php. mod_php is built from the php source tree, so no, you can't really do that. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > wrote: > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > == Summary == > > > mod_php (apache2handler) is an optional httpd module to execute PHP > > > scripts, not used. > > > > > > > > > > > > == Owner == > > > * Name: [[User:Remi| Remi Collet]] > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > == Detailed Description == > > > By default php-fpm is used for a few versions. mod_php is not > > > supported for threaded modules. mod_php usage also increases security > > > risk, sharing the same process than httpd. > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd in > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx without any > > > issue. > > > > > > > > > The "php" package will be kept as a metapackage, installing (weak > > > dependencies) most commonly used extension, thus reducing the > > > difference between "yum install php" (flat repository) and "yum module > > > install php" (modular repository). > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > == Scope == > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > * Release engineering: N/A > > > * Policies and guidelines: N/A (not a System Wide Change) > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > N/A (not a System Wide Change) > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > > > > > > > == Contingency Plan == > > > * revert > > > > > > > > > > > > * Contingency deadline: N/A (not a System Wide Change) > > > * Blocks release? N/A (not a System Wide Change), Yes/No > > > * Blocks product? product > > > > > > > > > > > > == Documentation == > > > > > > > > Now that this has been accepted, I take it that the current maintainer of > > mod_php no longer wants to maintain it? I'd like to offer to take over > > the > > package if that's the case, so that Fedora will continue to work for > > those > > using mod_php. > > > mod_php is built from the php source tree, so no, you can't really do that. In that case, is it possible that it can just be kept in the build, so that we can continue to support it? There's really not a whole lot of reason to kill off something as useful and widely used as mod_php while it's still working well for thousands, if not hundreds of thousands, of servers, and is still the preferred backend for Apache, which even defaults to prefork upstream. -- John M. Harris, Jr. ___ 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: Btrfs by default, the compression option
> https://paste.centos.org/view/f4165396 > > Two workloads: install and update. It might seem like an update is > both read and write dependent, but the rpms are already compressed and > don't get compressed again. The differences, I expect, are mostly > write performance. And this suggests it's a wash. I'd say this setup > is fairly middle of the pack. > > The space savings, however, isn't a wash. New longer lasting paste. Same info. https://pastebin.com/nvpvAy0k Mostly this was just a sanity test, I'll get around to some baremetal tests eventually. ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr wrote: > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > wrote: > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > == Summary == > > > > mod_php (apache2handler) is an optional httpd module to execute PHP > > > > scripts, not used. > > > > > > > > > > > > > > > > == Owner == > > > > * Name: [[User:Remi| Remi Collet]] > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > By default php-fpm is used for a few versions. mod_php is not > > > > supported for threaded modules. mod_php usage also increases security > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd in > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx without any > > > > issue. > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing (weak > > > > dependencies) most commonly used extension, thus reducing the > > > > difference between "yum install php" (flat repository) and "yum module > > > > install php" (modular repository). > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > * Release engineering: N/A > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > N/A (not a System Wide Change) > > > > > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > > > > > > > > > > > == Contingency Plan == > > > > * revert > > > > > > > > > > > > > > > > * Contingency deadline: N/A (not a System Wide Change) > > > > * Blocks release? N/A (not a System Wide Change), Yes/No > > > > * Blocks product? product > > > > > > > > > > > > > > > > == Documentation == > > > > > > > > > > > > Now that this has been accepted, I take it that the current maintainer of > > > mod_php no longer wants to maintain it? I'd like to offer to take over > > > the > > > package if that's the case, so that Fedora will continue to work for > > > those > > > using mod_php. > > > > > > mod_php is built from the php source tree, so no, you can't really do that. > > In that case, is it possible that it can just be kept in the build, so that we > can continue to support it? There's really not a whole lot of reason to kill > off something as useful and widely used as mod_php while it's still working > well for thousands, if not hundreds of thousands, of servers, and is still the > preferred backend for Apache, which even defaults to prefork upstream. > Fedora has not defaulted to prefork for Apache httpd since Fedora 27, upstream Apache httpd has not defaulted to it for even *longer*. Apache httpd switched to event mpm by default more than a decade ago (at least 12 years ago, from what I can tell, most likely longer!). Fedora finally followed upstream on this in Fedora 27, and mod_php has been broken in the default configuration since then. But even with that, we've had PHP-FPM as the default with Apache httpd for five years now. Out of the box, that's what is set up. Nobody noticed that mod_php was broken for the past two years, and nobody has had any real issues with the default PHP SAPI being switched five years ago. At this point, the only reason to keep it is if there's something that somehow absolutely cannot run with PHP-FPM but can with mod_php. If something like that is the case, we *could* restore it as a subpackage. But it'd have to be a pretty compelling case... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > wrote: > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > mod_php (apache2handler) is an optional httpd module to execute PHP > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > By default php-fpm is used for a few versions. mod_php is not > > > > > supported for threaded modules. mod_php usage also increases > > > > > security > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd in > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx without > > > > > any > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing (weak > > > > > dependencies) most commonly used extension, thus reducing the > > > > > difference between "yum install php" (flat repository) and "yum > > > > > module > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > * Release engineering: N/A > > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > > N/A (not a System Wide Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Contingency Plan == > > > > > * revert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Contingency deadline: N/A (not a System Wide Change) > > > > > * Blocks release? N/A (not a System Wide Change), Yes/No > > > > > * Blocks product? product > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Documentation == > > > > > > > > > > > > > > > > > > > > > > > > Now that this has been accepted, I take it that the current maintainer > > > > of > > > > mod_php no longer wants to maintain it? I'd like to offer to take > > > > over > > > > the > > > > package if that's the case, so that Fedora will continue to work for > > > > those > > > > using mod_php. > > > > > > > > > > > > > > > mod_php is built from the php source tree, so no, you can't really do > > > that. > > > > > > > In that case, is it possible that it can just be kept in the build, so > > that we can continue to support it? There's really not a whole lot of > > reason to kill off something as useful and widely used as mod_php while > > it's still working well for thousands, if not hundreds of thousands, of > > servers, and is still the preferred backend for Apache, which even > > defaults to prefork upstream.> > > > > > Fedora has not defaulted to prefork for Apache httpd since Fedora 27, > upstream Apache httpd has not defaulted to it for even *longer*. > > Apache httpd switched to event mpm by default more than a decade ago > (at least 12 years ago, from what I can tell, most likely longer!). > Fedora finally followed upstream on this in Fedora 27, and mod_php has > been broken in the default configuration since then. > > But even with that, we've had PHP-FPM as the default with Apache httpd > for five years now. Out of the box, that's what is set up. Nobody > noticed that mod_p
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr wrote: > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > > wrote: > > > > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > > mod_php (apache2handler) is an optional httpd module to execute PHP > > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > By default php-fpm is used for a few versions. mod_php is not > > > > > > supported for threaded modules. mod_php usage also increases > > > > > > security > > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd in > > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx without > > > > > > any > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing (weak > > > > > > dependencies) most commonly used extension, thus reducing the > > > > > > difference between "yum install php" (flat repository) and "yum > > > > > > module > > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > > * Release engineering: N/A > > > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > > > N/A (not a System Wide Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Contingency Plan == > > > > > > * revert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Contingency deadline: N/A (not a System Wide Change) > > > > > > * Blocks release? N/A (not a System Wide Change), Yes/No > > > > > > * Blocks product? product > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Documentation == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now that this has been accepted, I take it that the current maintainer > > > > > of > > > > > mod_php no longer wants to maintain it? I'd like to offer to take > > > > > over > > > > > the > > > > > package if that's the case, so that Fedora will continue to work for > > > > > those > > > > > using mod_php. > > > > > > > > > > > > > > > > > > > > mod_php is built from the php source tree, so no, you can't really do > > > > that. > > > > > > > > > > > In that case, is it possible that it can just be kept in the build, so > > > that we can continue to support it? There's really not a whole lot of > > > reason to kill off something as useful and widely used as mod_php while > > > it's still working well for thousands, if not hundreds of thousands, of > > > servers, and is still the preferred backend for Apache, which even > > > defaults to prefork upstream.> > > > > > > > > > Fedora has not defaulted to prefork for Apache httpd since Fedora 27, > > upstream Apache httpd has not defaulted
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote: > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr > wrote: > > > > > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > > > > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > > > mod_php (apache2handler) is an optional httpd module to execute > > > > > > > PHP > > > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > > By default php-fpm is used for a few versions. mod_php is not > > > > > > > supported for threaded modules. mod_php usage also increases > > > > > > > security > > > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd > > > > > > > in > > > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx > > > > > > > without > > > > > > > any > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing > > > > > > > (weak > > > > > > > dependencies) most commonly used extension, thus reducing the > > > > > > > difference between "yum install php" (flat repository) and "yum > > > > > > > module > > > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > > > * Release engineering: N/A > > > > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > > > > N/A (not a System Wide Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Contingency Plan == > > > > > > > * revert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Contingency deadline: N/A (not a System Wide Change) > > > > > > > * Blocks release? N/A (not a System Wide Change), Yes/No > > > > > > > * Blocks product? product > > > > > > > > > > > > > > > > > > > > > > >
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr wrote: > > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote: > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr > > wrote: > > > > > > > > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > > > > > > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > > > > mod_php (apache2handler) is an optional httpd module to execute > > > > > > > > PHP > > > > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > > > By default php-fpm is used for a few versions. mod_php is not > > > > > > > > supported for threaded modules. mod_php usage also increases > > > > > > > > security > > > > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd > > > > > > > > in > > > > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx > > > > > > > > without > > > > > > > > any > > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing > > > > > > > > (weak > > > > > > > > dependencies) most commonly used extension, thus reducing the > > > > > > > > difference between "yum install php" (flat repository) and "yum > > > > > > > > module > > > > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > > > > * Release engineering: N/A > > > > > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > > > > > N/A (not a System Wide Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > >
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote: > On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr > wrote: > > > > > > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote: > > > > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > > > > > mod_php (apache2handler) is an optional httpd module to > > > > > > > > > execute > > > > > > > > > PHP > > > > > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > > > > By default php-fpm is used for a few versions. mod_php is > > > > > > > > > not > > > > > > > > > supported for threaded modules. mod_php usage also > > > > > > > > > increases > > > > > > > > > security > > > > > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of > > > > > > > > > httpd > > > > > > > > > in > > > > > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx > > > > > > > > > without > > > > > > > > > any > > > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing > > > > > > > > > (weak > > > > > > > > > dependencies) most commonly used extension, thus reducing > > > > > > > > > the > > > > > > > > > difference between "yum install php" (flat repository) and > > > > > > > > > "yum > > > > > > > > > module > > > > > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > > > > > * Release engineering: N/A > > > > > > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[Test-Announce] Proposal to CANCEL: 2020-07-13 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't have anything urgent new this week. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Note on blocker meetings: we still have a very short list of proposed blockers for now, probably doesn't need a meeting yet. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr wrote: > > Why should I have to switch the system that's being used, and potentially > break these servers, just because a package isn't being compiled anymore? It > still works, and it works very well. It has less overhead than php-fpm, even! > AFAICT you do not. You are absolutely free to build your own rpms and use them on your own systems. I do that for a couple of very specific applications that have no value outside of my personal use case, and did that for years at a previous $DAYJOB for the site. ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 6:56:36 PM MST Gary Buhrmaster wrote: > On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr > wrote: > > > > > > > Why should I have to switch the system that's being used, and potentially > > break these servers, just because a package isn't being compiled anymore? > > It still works, and it works very well. It has less overhead than > > php-fpm, even!> > > > > > AFAICT you do not. You are absolutely free to build > your own rpms and use them on your own systems. > I do that for a couple of very specific applications > that have no value outside of my personal use case, > and did that for years at a previous $DAYJOB for > the site. What would be the best way to do that, such that all Fedora users can make use of it? Otherwise, this is going to break peoples' systems on upgrade to Fedora 33, so we need to solve this problem fairly quickly. I originally considered cloning the current php package over to copr when the change was accepted, but that'd only be useful for those that are aware their systems are about to be needlessly broken. -- John M. Harris, Jr. ___ 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
[Bug 1855334] perl-Sereal-Encoder-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1855334 --- Comment #11 from Fedora Update System --- FEDORA-2020-1f18f358d0 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1f18f358d0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Fri, Jul 10, 2020 at 10:05 PM John M. Harris Jr wrote: > > On Friday, July 10, 2020 6:56:36 PM MST Gary Buhrmaster wrote: > > On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr > > wrote: > > > > > > > > > > > > Why should I have to switch the system that's being used, and potentially > > > break these servers, just because a package isn't being compiled anymore? > > > It still works, and it works very well. It has less overhead than > > > php-fpm, even!> > > > > > > > > > AFAICT you do not. You are absolutely free to build > > your own rpms and use them on your own systems. > > I do that for a couple of very specific applications > > that have no value outside of my personal use case, > > and did that for years at a previous $DAYJOB for > > the site. > > What would be the best way to do that, such that all Fedora users can make use > of it? Otherwise, this is going to break peoples' systems on upgrade to Fedora > 33, so we need to solve this problem fairly quickly. I originally considered > cloning the current php package over to copr when the change was accepted, but > that'd only be useful for those that are aware their systems are about to be > needlessly broken. > Copr is the way to go if you really want to provide it. You can probably start from here: https://src.fedoraproject.org/rpms/php/pull-request/4 But as described in the PR by Remi, mod_php + httpd is essentially a broken configuration. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Saturday, July 11, 2020, John M. Harris Jr wrote: > On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote: > > On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr > > wrote: > > > > > > > > > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote: > > > > > > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > > > > > > mod_php (apache2handler) is an optional httpd module to > > > > > > > > > > execute > > > > > > > > > > PHP > > > > > > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > > > > > By default php-fpm is used for a few versions. mod_php is > > > > > > > > > > not > > > > > > > > > > supported for threaded modules. mod_php usage also > > > > > > > > > > increases > > > > > > > > > > security > > > > > > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user > of > > > > > > > > > > httpd > > > > > > > > > > in > > > > > > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx > > > > > > > > > > without > > > > > > > > > > any > > > > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, > installing > > > > > > > > > > (weak > > > > > > > > > > dependencies) most commonly used extension, thus reducing > > > > > > > > > > the > > > > > > > > > > difference between "yum install php" (flat repository) > and > > > > > > > > > > "yum > > > > > > > > > > module > > > > > > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 7:12:50 PM MST Neal Gompa wrote: > On Fri, Jul 10, 2020 at 10:05 PM John M. Harris Jr > wrote: > > > > > > On Friday, July 10, 2020 6:56:36 PM MST Gary Buhrmaster wrote: > > > > > On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why should I have to switch the system that's being used, and > > > > potentially > > > > break these servers, just because a package isn't being compiled > > > > anymore? > > > > It still works, and it works very well. It has less overhead than > > > > php-fpm, even!> > > > > > > > > > > > > > > > > > > > > > > > AFAICT you do not. You are absolutely free to build > > > your own rpms and use them on your own systems. > > > I do that for a couple of very specific applications > > > that have no value outside of my personal use case, > > > and did that for years at a previous $DAYJOB for > > > the site. > > > > > > > > What would be the best way to do that, such that all Fedora users can make > > use of it? Otherwise, this is going to break peoples' systems on upgrade > > to Fedora 33, so we need to solve this problem fairly quickly. I > > originally considered cloning the current php package over to copr when > > the change was accepted, but that'd only be useful for those that are > > aware their systems are about to be needlessly broken. > > > > > > > Copr is the way to go if you really want to provide it. You can > probably start from here: > https://src.fedoraproject.org/rpms/php/pull-request/4 > > But as described in the PR by Remi, mod_php + httpd is essentially a broken > configuration. Nowhere in there does it describe how mod_php + httpd would be a broken configuration, and it's not. I see where remi mentions that, but that's simply not the case. mod_php works just fine, as it has for over a decade, and will for many years to come. It's a damn shame that your PR was closed, that looks like the best way to handle the situation to me, drop it into a sub-package. -- John M. Harris, Jr. ___ 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 33 Self-Contained Change proposal: Drop mod_php
On Friday, July 10, 2020 9:41:48 PM MST drago01 wrote: > On Saturday, July 11, 2020, John M. Harris Jr wrote: > > On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote: > > > On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr > > > > > > wrote: > > > > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote: > > > > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr > > > > > > > > > > > > > > > wrote: > > > > > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > > > > > > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > > > > > > > mod_php (apache2handler) is an optional httpd module to > > > > > > > > > > > execute > > > > > > > > > > > PHP > > > > > > > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > > > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > > > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > > > > > > > By default php-fpm is used for a few versions. mod_php > > > > > > > > > > > is > > > > > > > > > > > not > > > > > > > > > > > supported for threaded modules. mod_php usage also > > > > > > > > > > > increases > > > > > > > > > > > security > > > > > > > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user > > > > of > > > > > > > > > > > > > httpd > > > > > > > > > > > in > > > > > > > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and > > > > > > > > > > > nginx > > > > > > > > > > > without > > > > > > > > > > > any > > > > > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, > > > > installing > > > > > > > > > > > > > (weak > > > > > > > > > > > dependencies) most commonly used extension, thus > > > > > > > > > > > reducing > > > > > > > > > > > the > > > > > > > > > > > difference between "yum install php" (flat repository) > > > > and > > > > > > > > > > > > > "yum > > > > > > > > > > > module > > > > > > > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web > > > > server. > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > > > > > > >
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > == Summary == > This proposal adds cgroup based resource protections for the active > graphical session. This is done by passing a memory protection of > 250MiB to active users (capped at 10% of system memory) and by > enabling other cgroup controllers (CPU, IO) to ensure important > session processes get the resources they need. Just curious, why 250MiB and not some other number? > See: https://pagure.io/fedora-workstation/issue/154 > > == Owner == > * Name: [[User:benzea|Benjamin Berg]] > * Email: bb...@redhat.com > * Product: Workstation > * Responsible WG: Workstation > > > == Detailed Description == > Graphical sessions should always be responsive, even when the machine > is doing a lot work or in the extreme case has started to thrash. We > have started to ship EarlyOOM with F32, however, while it is a good > solution to this date, it is shipped with the understanding of being > superseded by other approaches in the future. Does it mean we do not ship earlyoom anymore or what is this sentence supposed to indicate? > With `uresourced` a small daemon was written that enables protection > of the graphical user session. It serves the following main purposes: > > * Safely modify existing GNOME systemd units to closer adhere to > https://systemd.io/DESKTOP_ENVIRONMENTS/ (until this is merged > upstream). > * Enables the CPU and IO cgroup controllers for users to prevent e.g. > fork bombs from taking over the system. > * Allocates a memory guarantee for any *active* user which is > distributed to core session processes. > > Precautions are in place to not negatively affect systems: > > * Active users will receive a protected memory allocation of 250MiB > allocation, but capped at 10% of system memory. So low memory systems > should not be negatively impacted. Said differently, the memory > subsystem treats the core session processes in comparison to > everything else as if they were using 250MiB less than they actually > are. > * `uresourced` detects whether the user session is using systemd to > prevent passing memory guarantees to processes that are not important > (e.g. not a GNOME session). > * Enabling the IO controller has no effect on Fedora currently. > > NOTES: > > * `uresourced` is designed to be obsoleted. Everything it does should > be absorbed by other upstreams. However, it is a good and safe > solution that eases development and permits shipping the benefits to > users now. > * Enabling the cgroup controllers may slightly increase the > scheduling > overhead that the kernel imposes. I don't have numbers right now, but > expect this to be <=1% of overall system CPU time. > > > == Benefit to Fedora == > This change proposal will improve interactivity of graphical sessions > in certain situations. It also is an important step on the path to > reap the benefits of systemd and cgroups in workstation scenarios. > > == Scope == > * Proposal owners: > * Install `uresourced` on workstations by default > * Add a preset to enable `uresourced` by default > > * Other developers: no further changes are needed > > * Release engineering: [https://pagure.io/releng/issue/9592] > * Policies and guidelines: N/A (not needed) > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > No impact. The worst case scenario is that the feature will not be > enabled. > > == How To Test == > Testing this has multiple aspects. From the technical side, a test is > as simple as: > > * Install and enable `uresourced` > * Reboot (to make absolutely sure the user session has picked up all > changes, logout may *not* be sufficient) > * Check values in `/sys/fs/cgroup/user.slice/memory.low`, > `/sys/fs/cgroup/user.slice/user-1000.slice/memory.low`, > `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/memory.l > ow` > and > `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session. > slice/memory.low` > (should usually be 250MiB with the default configuration). > * Verify that the allocation is zero if the user is not active on any > seat (e.g. switch to GDM and log in via SSH or by doing a `sleep 10; > cat ...` and coming back). > * Check enabled controllers in > `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.c > ontrollers` > (should be `cpu io memory pids`). > > Beyond that, a test can be done to show that the cgroup kernel > controllers are actually beneficial in various scenarios. Possible > examples are: > > * Running mprime > (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); > choose local stress test, repeat by selecting 15 NOTE: mcatanzaro > has reported a huge impact, with both the session remaining mostly > responsive and EarlyOOM not kicking in (this makes sense, as overall > memory pressure is much lower, i.e. t
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On 7/10/20 10:55 PM, John M. Harris Jr wrote: I demonstrated how it adds ~1ms to requests. That's one of the major downsides to using FastCGI, and it's unavoidable. You didn't demonstrate anything, you made an unsubstantiated claim. Did you even look at the link that was given? Regardless of whether or not fastcgi adds 1ms to requests, it saves hundreds more elsewhere. Have you even tried it? ___ 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
