[389-devel] 389 DS nightly 2021-05-29 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/05/29/report-389-ds-base-2.0.4-20210529gitba5578f7f.fc34.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-113abf45ca composer-1.10.22-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4ab96a9920 wordpress-5.1.10-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4b7c1b59f8 upx-3.96-9.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6cc996cdc4 opendmarc-1.4.1-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-969456590e rxvt-unicode-9.21-4.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0fec8057df python3-lxml-4.2.5-4.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-17f170d38c caribou0-0.4.21-26.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-7e9a7ecfb4 slurm-20.11.7-3.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0402b44d82 chromium-90.0.4430.212-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-15abda18e1 singularity-3.7.4-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c64b965c33 nginx-1.20.1-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9eaea6f65c audacious-plugins-4.0.5-4.el7 fluidsynth-2.1.8-4.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing remmina-1.4.17-1.el7 Details about builds: remmina-1.4.17-1.el7 (FEDORA-EPEL-2021-31c162c736) Remote Desktop Client Update Information: Update to bugfix release 1.4.17. ChangeLog: * Wed May 26 2021 Simone Caronni - 1.4.17-1 - Update to 1.4.17. - Disable news at every update. References: [ 1 ] Bug #1959277 - remmina-1.4.17 is available https://bugzilla.redhat.com/show_bug.cgi?id=1959277 [ 2 ] Bug #1960201 - [abrt] remmina: rcw_after_configure_scrolled(): remmina killed by SIGSEGV https://bugzilla.redhat.com/show_bug.cgi?id=1960201 [ 3 ] Bug #1964978 - [abrt] remmina: remmina_rdp_event_queue_ui(): remmina killed by SIGSEGV https://bugzilla.redhat.com/show_bug.cgi?id=1964978 [ 4 ] Bug #1965346 - Remmina 1.4.16 is not functional, please upload 1.4.17 from rawhide https://bugzilla.redhat.com/show_bug.cgi?id=1965346 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1962451] perl-perlfaq-5.20210520 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1962451 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-perlfaq-5.20210520-1.f |perl-perlfaq-5.20210520-1.f |c35 |c35 |perl-perlfaq-5.20210520-1.f |perl-perlfaq-5.20210520-1.f |c34 |c34 ||perl-perlfaq-5.20210520-1.f ||c33 --- Comment #7 from Fedora Update System --- FEDORA-2021-756314d756 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1962451] perl-perlfaq-5.20210520 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1962451 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-perlfaq-5.20210520-1.f |perl-perlfaq-5.20210520-1.f |c35 |c35 ||perl-perlfaq-5.20210520-1.f ||c34 Resolution|--- |ERRATA Last Closed||2021-05-29 01:04:37 --- Comment #6 from Fedora Update System --- FEDORA-2021-e1c0b2d767 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20210528.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 4/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20210527.0): ID: 898530 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/898530 ID: 898534 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/898534 ID: 898543 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/898543 ID: 898546 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/898546 ID: 898548 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/898548 ID: 898550 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/898550 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210527.0): ID: 898522 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/898522 ID: 898529 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/898529 ID: 898533 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/898533 ID: 898538 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/898538 Passed openQA tests: 10/15 (aarch64), 11/16 (x86_64) New passes (same test not passed in Fedora-IoT-35-20210527.0): ID: 898541 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/898541 ID: 898542 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/898542 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.67 to 0.55 Previous test data: https://openqa.fedoraproject.org/tests/896769#downloads Current test data: https://openqa.fedoraproject.org/tests/898538#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-05-31 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent on the agenda, so let's take a break. 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. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Fri, May 28, 2021 at 1:45 AM Peter Boy wrote: > > Am 27.05.2021 um 00:59 schrieb Chris Murphy : > > Whereupon Server SIG/WG perform an evaluation of Btrfs for their use > > cases, and decide Btrfs should be the default in a compelling manner, > > FESCo will approve it. And this plausibly could still happen for > > Fedora 35, if folks really want it to happen. > > Theoretically, it could. But practically, I don't see it happen. The need for > discussion is too great. And not everyone is as convinced as you are that > BTRFS is the non-plus-ultra for all possible use cases. All I mean by this is to push back on the idea that the proposal for Cloud translates into delaying the decision for Server by 5 or 10 years. Not that Server folks should escalate their discussion. Also, I don't think Btrfs is the end all for all use cases; I gave an example to the contrary in the previous email. There are always trade offs. The conversation should focus on what those tradeoffs are and how much each SIG values them. > > Server SIG can do anything they > > want. Red Hat is doing the same. > > Nevertheless, coordination and cooperation is at least very desirable (in > fact, indispensable). And is is not just about who is paying the bills. > Beyond this crude economic dimension, Fedora benefits from the reputation of > being upstream for RHEL (and vice versa, for sure). A defiant "we can do as > we like" is not helpful. It isn't defiance, it's conviction consistent with Fedora's mission and the four foundations. My working assumption is substantive public discussion, to reveal the pros and cons of the proposal, in order to come to a decision. The proposal is not the decision. > > My opinion is to not worry about the process in advance of arriving at > > the hurdle. You jump over the hurdle at the proper time. The vast > > majority of the process is about technical features liabilities. > > > > ... > > > And when we address discussion and evidence: > > > > Not often but sometimes folks ask "where has all the space gone?" > > following a Server installation. They're not expecting or maybe not > > discovering, that quite a lot is held in reserve in the VG. > > As said before, I agree with that, at least for the most part. I use BTRFS > myself in LVs to use specific capabilities. Still, I'm against converting > "with a flick of the wrist," so to speak. It needs careful preparation. And > one possible outcome is also, not to switch to BTRFS. I don't think it is a > given that a switch is right in any case. That is perhaps the difference > between us. I agree with all of these things. But from my point of view they are obvious, to the degree that since you're stating them, it makes me wonder whether you think something has happened abruptly, frivolously, or without sufficient care and preparation. In your view should something have occurred before the proposal was submitted that didn't? > And when we address discussion and evidence: What I miss is a prior detailed > discussion of this change in cloud WG and coordination with other possible > affected areas, e.g. server or CoreOS. Cloud Working Group did not happened > for years, then there were a few short, sparsely-attended and content-dry > meetings. A range of existing problems, starting with lack of documentation. > A hesitancy to make any change currently to the cloud artifacts (expressed by > Dusty Mabe at that March meeting, 3). And then out of nowhere the file system > conversion, a very central element. To me, it seems like a playground for > missionaries to gain ground, certainly not like a considerate and methodical > long-term design. I don't agree it happened out of nowhere. It's been floated by various folks over the years, even before Workstation edition switched to Btrfs by default. Fedora has quite a lot of sprawl, it's a diverse community, not all conversations happen on devel@ so it can be easy to draw a conclusion that it's sudden. But that is the whole point of the change proposal process, is to make a broad and grand announcement on the primary development list, expressly because we don't want folks missing big changes. Now is exactly the time to dig into the drawbacks, liabilities, risks of proposals, and weigh them against the proponents' typically strong take in favor of the change or else they probably wouldn't have submitted the proposal in the first place. Take it from me, I really like the adversarial process. I don't mean this in the negative connotation, but rather the legal denotation. We should have a debate. That time is right now, in this thread. And I welcome it. -- 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
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Fri, May 28, 2021 at 4:37 PM Nico Kadel-Garcia wrote: > > On Fri, May 28, 2021 at 9:04 AM Colin Walters wrote: > > > > > > > > On Fri, May 28, 2021, at 5:43 AM, Neal Gompa wrote: > > > > > > Part of the point of the different working groups was to handle the > > > different use-cases *well* at their own pace. The CoreOS Working Group > > > is *explicitly* excluded and frankly unlikely to ever switch because > > > Colin believes > > > > I am not CoreOS, I'm an engineer working on it. > > > > > that Btrfs is only suitable for "pet" workloads[1] > > > > That's not what my blog said. One of the sub-headers is "BTRFS is good for > > "pet" systems". There's no word "only" there - you inserted that. > > > > On this topic though, if Fedora CoreOS didn't exist, this proposal to > > change Cloud would be significantly more consequential. The defaults > > *really matter* here in particular, even more than Workstation. But, I > > think because CoreOS does exist, this change matters less. > > > > One big advantage CoreOS has is Ignition, which allows provisioning > > filesystems in the initramfs, including the root partition. It works today > > to boot up a stock Fedora CoreOS AMI, OpenStack qcow2 etc. and provide an > > Ignition config that changes it: > > No need for "ignition". This has worked since grub and anaconda were > created by using '%pre' scripts in anaconda to pre-partition the > file-system and potentially insert other pre-configuration steps in > it. If ignition has new integration features rather than the manual > scripting I used to do, great. But ignition is not required for this. Fedora Cloud does not use Anaconda for provisioning, so that whole strategy does not work. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Fri, May 28, 2021 at 9:04 AM Colin Walters wrote: > > > > On Fri, May 28, 2021, at 5:43 AM, Neal Gompa wrote: > > > > Part of the point of the different working groups was to handle the > > different use-cases *well* at their own pace. The CoreOS Working Group > > is *explicitly* excluded and frankly unlikely to ever switch because > > Colin believes > > I am not CoreOS, I'm an engineer working on it. > > > that Btrfs is only suitable for "pet" workloads[1] > > That's not what my blog said. One of the sub-headers is "BTRFS is good for > "pet" systems". There's no word "only" there - you inserted that. > > On this topic though, if Fedora CoreOS didn't exist, this proposal to change > Cloud would be significantly more consequential. The defaults *really > matter* here in particular, even more than Workstation. But, I think because > CoreOS does exist, this change matters less. > > One big advantage CoreOS has is Ignition, which allows provisioning > filesystems in the initramfs, including the root partition. It works today > to boot up a stock Fedora CoreOS AMI, OpenStack qcow2 etc. and provide an > Ignition config that changes it: No need for "ignition". This has worked since grub and anaconda were created by using '%pre' scripts in anaconda to pre-partition the file-system and potentially insert other pre-configuration steps in it. If ignition has new integration features rather than the manual scripting I used to do, great. But ignition is not required for this. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
> Am 28.05.2021 um 11:43 schrieb Neal Gompa : > > On Fri, May 28, 2021 at 3:45 AM Peter Boy wrote: >> >> Nevertheless, coordination and cooperation is at least very desirable (in >> fact, indispensable). And is is not just about who is paying the bills. >> Beyond this crude economic dimension, Fedora benefits from the reputation of >> being upstream for RHEL (and vice versa, for sure). A defiant "we can do as >> we like" is not helpful > > Being upstream for RHEL also means pushing forward and demonstrating > that things *can* work better in a different way. If we didn't, > there's no way for RHEL to change. We bring no value as upstream if we > don't actually *do* things. Agreed. And yet it requires coordination and discussion, in a transparent and comprehensible manner. >> Cloud Working Group did not happened for years, then there were a few short, >> sparsely-attended and content-dry meetings. A range of existing problems, >> starting with lack of documentation. A hesitancy to make any change >> currently to the cloud artifacts (expressed by Dusty Mabe at that March >> meeting, 3). And then out of nowhere the file system conversion, a very >> central element. To me, it seems like a playground for missionaries to gain >> ground, certainly not like a considerate and methodical long-term design. >> > > Actually, the Cloud WG members had been talking about this ad-hoc > since all the desktop variants switched last year. The ticket[4] was > filed around the same time the desktop change was proposed. Dusty, > Joe, James, and myself had been talking about it outside of meetings > since. David became interested after the Nest talk about Btrfs[5]. > That conversation started again after my talk on Btrfs at DevConf.cz > (the recording has not been published still, sadly). So this has been > a long time coming. > > [4]: https://pagure.io/cloud-sig/issue/308 > [5]: https://www.youtube.com/watch?v=iHjhouSxIrc I would have expected at least a public announcement on the cloud mailing list including an invitation for discussion at an IRC meeting and - for such a far-reaching matter - a subsequent voting. But I'm not involved in the Cloud SIG. So let's close the discussion. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)
On Mon, May 17, 2021 at 11:37 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/SDL12onSDL2
>
> == Summary ==
> This Change proposes to replace SDL 1.2 with sdl12-compat, which uses SDL 2.0.
>
> == Owner ==
> * Name: [[User:Ngompa| Neal Gompa]]
> * Email: ngomp...@gmail.com
>
>
> == Detailed Description ==
> SDL 1.2 development ended long ago, with SDL 2.0 replacing it.
> However, many older games still use SDL 1.2 and cannot change to SDL
> 2.0. In order to help move SDL 1.2 games into the modern world, let's
> replace SDL 1.2 with sdl12-compat, which uses SDL 2.0.
>
>
> == Benefit to Fedora ==
> Switching SDL 1.2 powered games to use sdl12-compat
> offers significant advantages:
>
> * Automatic support for Wayland with SDL 2.0.16+
> * Native support for PipeWire for audio
> * Massively improved support for inputs (including gamepads)
>
> Ultimately, SDL 2.0 is actively maintained and developed. We want
> applications that use SDL to use an actively maintained codebase.
>
> == Scope ==
> * Proposal owners:
> ** Package [https://github.com/libsdl-org/sdl12-compat
> libsdl12-compat] ([https://bugzilla.redhat.com/show_bug.cgi?id=1960960
> RH#1960960])
> ** Adjust {{package|SDL}} to not ship the main library package and use
> the one from libsdl12-compat
> ** Once [https://github.com/libsdl-org/sdl12-compat/issues/34
> replacement development headers are available], retire {{package|SDL}}
> completely.
>
> * Other developers: N/A
> * Release engineering: [https://pagure.io/releng/issue/10118 #10118]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> The SDL package would be transparently upgraded to
> libsdl12-compat package and games using it should just
> transparently start using SDL 2.0.
>
>
>
> == How To Test ==
> 1. Swap SDL for sdl12-compat: dnf swap
> SDL sdl12-compat
>
> 2. Run something that uses SDL 1.2 like {{package|quake3}} and see
> that it works.
>
>
>
> == User Experience ==
> There shouldn't be a noticeable user impact, other than possibly a
> smoother experience because applications are using SDL 2.0.
>
> == Dependencies ==
>
>
> == Contingency Plan ==
> * Contingency mechanism: Restore the SDL package in
> {{package|SDL}}. If {{package|SDL}} has been fully retired, then
> unretire it.
> * Contingency deadline: Final Freeze
> * Blocks release? N/A (not a System Wide Change)
>
> == Documentation ==
>
> N/A (not a System Wide Change)
>
> == Release Notes ==
> Games that use SDL 1.2 will now transparently use SDL 2.0 through the
> sdl12-compat package. This makes it so applications that
> historically used SDL 1.2 now use SDL 2.0.
>
So a minor update here: sdl12-compat now has replacement headers.
Thus, I updated the proposal to include fully retiring SDL for
sdl12-compat.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora elections voting now open
Hello! Yes, now it works, I changed my password and voted. It's very slow, but that could be my connection. Thank you very much!!! Kind regards, Silvia FAS: Lailah On Fri, 28 May 2021 at 19:32, Kevin Fenzi wrote: > On Fri, May 28, 2021 at 07:21:41PM +0200, Silvia Sánchez wrote: > > Kevin, > > > > Apparently no, but I don't know why. What should I do now? > > Try and reset your password: > https://accounts.fedoraproject.org/forgot-password/ask > > and then see if it starts working. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
On Fri, May 28, 2021 at 12:37 AM Gerd Hoffmann wrote: > > Hi, > > > I don't know why we all missed it. Butt that appears to be the case. > > > > However, the end goal is to create hybrid BIOS+UEFI cloud images via > > kickstart. (Maybe down the road it could be generally useful, if/when the > > existing bootloader UI bits go away.) > > https://git.kraxel.org/cgit/imagefish/tree/kickstart/el8.ks > > (for rhel8/centos8, probably wouldn't work as-is in f34+ because > the unified grub feature changed the grub cfg file arrangements). > That does look like what we're after. Thanks! -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora elections voting now open
On Fri, May 28, 2021 at 07:21:41PM +0200, Silvia Sánchez wrote: > Kevin, > > Apparently no, but I don't know why. What should I do now? Try and reset your password: https://accounts.fedoraproject.org/forgot-password/ask and then see if it starts working. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora elections voting now open
Kevin, Apparently no, but I don't know why. What should I do now? Kind regards, Silvia FAS: Lailah On Fri, 28 May 2021 at 19:20, Kevin Fenzi wrote: > On Fri, May 28, 2021 at 07:06:53PM +0200, Silvia Sánchez wrote: > > Hello! > > > > I tried that too, Mikel, but it fails as well. It doesn't even return an > > error or any sort of feedback. Just back to the previous page without > > logging me. > > In the logs I see: > authentication failed for user lailah: Authentication failure > > You are sure you can login to https://accounts.fedoraproject.org ok? > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora elections voting now open
On Fri, May 28, 2021 at 07:06:53PM +0200, Silvia Sánchez wrote: > Hello! > > I tried that too, Mikel, but it fails as well. It doesn't even return an > error or any sort of feedback. Just back to the previous page without > logging me. In the logs I see: authentication failed for user lailah: Authentication failure You are sure you can login to https://accounts.fedoraproject.org ok? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
one of the more important trusts we place in the parties in question is to protect the privacy of tens of thousands of *other* people's private conversations. Sure. As do we all. Mostly. Kind of. Ok, hopefully. Again, to _my_ read, _I_ see absolutely nothing in either side's recent behavior that builds _my_ trust. And sufficient cause for it to be called into some question. By _me_. If privacy of _credentials_ are in question, again, there's nothing but assumptions here. Unless/until _I_ see provable behavior, contractual accountability, and auditable infrastructure, _I_ remain ... diligent. If privacy of _discussions_ are in question, then #IRC isn't the right platform to start with. At all. And arguing about who's more trustworthy in managing privacy in an infra with the general leak-proofing of a pasta colander, is simply circular-debate about the color of the lipstick on the pig. Paraphrasing the old adage -- takes a lifetime to build a rep, 5 seconds to lose one. BOTH sides have lost trust & rep. In the end, I'm not convinced it was worth the "pantscon 1" (chuckle) hullabaloo, and wait to see if more harm than good comes of it. So thought I'd add/share a doc or 2 to read. /me is really shutting up now. About this, anyway. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On Fri, May 28, 2021 at 4:42 PM PGNet Dev wrote: > I'd bet $0.05 and a half-eaten donut that most folks *Most* folks are not the deciders. The deciders (for their particular projects) have decided, presumably based on what they believe is best for their community. In this case, for Fedora, that is libera (and matrix integration). One will likely never understand the complete motivations for various actions, but it is clear there were a number of unforced errors that resulted in the need to "revise and extend" remarks, and issue multiple clarifications (you really only get one chance to make things right). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora elections voting now open
Hello! I tried that too, Mikel, but it fails as well. It doesn't even return an error or any sort of feedback. Just back to the previous page without logging me. Kind regards, Silvia FAS: Lailah On Thu, 27 May 2021 at 19:21, Mikel Olasagasti wrote: > Hi Silvia, > > Hau idatzi du Silvia Sánchez (bhkoh...@gmail.com) erabiltzaileak (2021 > mai. 27, og. (19:19)): > > > > > > I tried to login to vote but I get a 400 error when I try. > > Had the same problem. I was able to workaround by login in bodhi[1] > and returning to the voting page. > > Mikel > > [1] https://bodhi.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On Fri, 2021-05-28 at 12:26 -0400, PGNet Dev wrote: > On 5/28/21 12:14 PM, Adam Williamson wrote: > > On Fri, 2021-05-28 at 12:01 -0400, PGNet Dev wrote: > > > On 5/27/21 2:04 PM, Nick Bebout wrote: > > > > Since its beginnings, the Fedora Project has used the freenode IRC > > > > network for our project communications. Due to a variety of recent > > > > changes to that network, the Fedora Project is moving our IRC > > > > communications to Libera.Chat. > > > > > > If a still-fuzzy "variety of recent changes to that network" are the > > > reason for this latest fire-drill/tempest, then just fyi, > > > A Lee's provided some documented reply, > > > > > > > > > https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf > > > https://freenode.net/news/post-mortem-may21 > > > > > > To my read it doesn't seem as clear-cut as some are making it all out to > > > be. If 'trust' is the underlying issue here, there seems to be enuf not > > > passing the smell test on 'both sides'. > > > > > > IME, projects want a place to talk that's trustworthy. > > > > Freenode has also shut down every channel that posted a libera.chat > > link in its topic. That's not very 'trustworthy'. This happened to > > multiple Fedora-related projects/channels, including #cockpit , for > > instance. > > Sure. And, what? Not the 1st time projects have acted on "don't talk about > other projects in here" ... > Did anyone try to contact @freenode about that? I certainly dunno about > that. Maybe so, maybe not. There was a huge backlash which resulted in a half-hearted not-really- an-apology a couple of days ago: https://freenode.net/news/post-mortem-may21 but at that point the damage was already pretty comprehensively done. > Just reading through those screenshotted chats, etc, seems 2 me there's > enough "shouldn't have handled it that way" to go around. Personally speaking I don't tend to care a lot about what people (from any group) were saying to each other in private conversations behind the scenes. However, the fact that only one party is releasing private conversations presumably without the consent of the other party seems...significant, especially when one of the more important trusts we place in the parties in question is to protect the privacy of tens of thousands of *other* people's private conversations. > > If it's all thoroughly researched, understood, and rationally decided, then > I'm certainly cool with it. > > All _I_ heard was some buzz in #fedora* @ freenode a week or so back that > "moving fast/immediately is too hard, and would be too disruptive to users", > and then suddenly, this^^ email. Yeah, that was the position initially, when it wasn't entirely clear if there was a Right Side and a Wrong Side, and there was no completely clear reason to question the good faith of either side. We figured we'd hedge for some time at least, as did many other projects. No-one particularly wanted to spend several days at pantscon 1 shifting a ton of stuff from one IRC network to another. But Freenode taking over hundreds of channels that did nothing more than put a link to another channel on another network in their #topic rather focused people's minds on the issue, I think. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
due specifically to Andrew Lee's actions. I'd bet $0.05 and a half-eaten donut that most folks shrieking about this would be hard-pressed to regurgitate much of anything beyond 'headlines', with little actual insight into objective details. But then, I'm often wrong. Now, back to real work for me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On Fri, May 28, 2021 at 12:32 PM PGNet Dev wrote: > > Andrew Lee has a flexible relationship with the truth. This is not a > both sides issue, as every other free software project has also agreed. > > Well, it seems you're good then. So, great. > > Just for me, not my 1st rodeo dealing with the spectrum from > megalomaniacal-sociopathic-CEOs to petulant-lemming-staff-actions > And, like I said, to my read, not so clear cut, despite declarations that > "This is not a both sides issue". > > I just shared some add'l info that I thought was relevant so folks could > read a bit (more) & make their OWN decisions rather than just blindly do > what (arguably) "every other free software project" is doing. > That's fine. It's good to have all the information. This is just my opinion, but while everyone has made mistakes, this mass migration is due specifically to Andrew Lee's actions. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
Andrew Lee has a flexible relationship with the truth. This is not a both sides issue, as every other free software project has also agreed. Well, it seems you're good then. So, great. Just for me, not my 1st rodeo dealing with the spectrum from megalomaniacal-sociopathic-CEOs to petulant-lemming-staff-actions And, like I said, to my read, not so clear cut, despite declarations that "This is not a both sides issue". I just shared some add'l info that I thought was relevant so folks could read a bit (more) & make their OWN decisions rather than just blindly do what (arguably) "every other free software project" is doing. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On 5/28/21 12:14 PM, Adam Williamson wrote: On Fri, 2021-05-28 at 12:01 -0400, PGNet Dev wrote: On 5/27/21 2:04 PM, Nick Bebout wrote: Since its beginnings, the Fedora Project has used the freenode IRC network for our project communications. Due to a variety of recent changes to that network, the Fedora Project is moving our IRC communications to Libera.Chat. If a still-fuzzy "variety of recent changes to that network" are the reason for this latest fire-drill/tempest, then just fyi, A Lee's provided some documented reply, https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf https://freenode.net/news/post-mortem-may21 To my read it doesn't seem as clear-cut as some are making it all out to be. If 'trust' is the underlying issue here, there seems to be enuf not passing the smell test on 'both sides'. IME, projects want a place to talk that's trustworthy. Freenode has also shut down every channel that posted a libera.chat link in its topic. That's not very 'trustworthy'. This happened to multiple Fedora-related projects/channels, including #cockpit , for instance. Sure. And, what? Not the 1st time projects have acted on "don't talk about other projects in here" ... Did anyone try to contact @freenode about that? I certainly dunno about that. Maybe so, maybe not. Just reading through those screenshotted chats, etc, seems 2 me there's enough "shouldn't have handled it that way" to go around. I'm not 'defending' _any_ purile/petty/powermad/etc. BS. I'm jut fyi'ing here, in the hopes that folks will make / have made an informed decision -- and pick-their-poison, and not simply to the lemmings-off-a-cliff biz cuz, "hey, it's the new hotness". If it's all thoroughly researched, understood, and rationally decided, then I'm certainly cool with it. All _I_ heard was some buzz in #fedora* @ freenode a week or so back that "moving fast/immediately is too hard, and would be too disruptive to users", and then suddenly, this^^ email. Beyond that, not a clue as to what discussion was had. Not that it's "my project" to begin with, so few expectations 'bout that in the 1st place. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On Fri, May 28, 2021 at 12:01 PM PGNet Dev wrote: > On 5/27/21 2:04 PM, Nick Bebout wrote: > > Since its beginnings, the Fedora Project has used the freenode IRC > network for our project communications. Due to a variety of recent changes > to that network, the Fedora Project is moving our IRC communications to > Libera.Chat. > > If a still-fuzzy "variety of recent changes to that network" are the > reason for this latest fire-drill/tempest, then just fyi, > A Lee's provided some documented reply, > > > https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf >https://freenode.net/news/post-mortem-may21 > > To my read it doesn't seem as clear-cut as some are making it all out to > be. If 'trust' is the underlying issue here, there seems to be enuf not > passing the smell test on 'both sides'. > > IME, projects want a place to talk that's trustworthy. > > > > caveat emptor. > Andrew Lee has a flexible relationship with the truth. This is not a both sides issue, as every other free software project has also agreed. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On Fri, 2021-05-28 at 12:01 -0400, PGNet Dev wrote: > On 5/27/21 2:04 PM, Nick Bebout wrote: > > Since its beginnings, the Fedora Project has used the freenode IRC network > > for our project communications. Due to a variety of recent changes to that > > network, the Fedora Project is moving our IRC communications to Libera.Chat. > > If a still-fuzzy "variety of recent changes to that network" are the reason > for this latest fire-drill/tempest, then just fyi, > A Lee's provided some documented reply, > > > https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf > https://freenode.net/news/post-mortem-may21 > > To my read it doesn't seem as clear-cut as some are making it all out to be. > If 'trust' is the underlying issue here, there seems to be enuf not passing > the smell test on 'both sides'. > > IME, projects want a place to talk that's trustworthy. Freenode has also shut down every channel that posted a libera.chat link in its topic. That's not very 'trustworthy'. This happened to multiple Fedora-related projects/channels, including #cockpit , for instance. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On 5/27/21 2:04 PM, Nick Bebout wrote: Since its beginnings, the Fedora Project has used the freenode IRC network for our project communications. Due to a variety of recent changes to that network, the Fedora Project is moving our IRC communications to Libera.Chat. If a still-fuzzy "variety of recent changes to that network" are the reason for this latest fire-drill/tempest, then just fyi, A Lee's provided some documented reply, https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf https://freenode.net/news/post-mortem-may21 To my read it doesn't seem as clear-cut as some are making it all out to be. If 'trust' is the underlying issue here, there seems to be enuf not passing the smell test on 'both sides'. IME, projects want a place to talk that's trustworthy. caveat emptor. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210528.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 16/194 (x86_64), 12/133 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210527.n.1): ID: 898080 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/898080 ID: 898124 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/898124 ID: 898188 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/898188 Old failures (same test failed in Fedora-Rawhide-20210527.n.1): ID: 898078 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/898078 ID: 898081 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/898081 ID: 898087 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/898087 ID: 898093 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/898093 ID: 898094 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/898094 ID: 898112 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/898112 ID: 898115 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/898115 ID: 898133 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/898133 ID: 898146 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/898146 ID: 898155 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/898155 ID: 898157 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/898157 ID: 898207 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/898207 ID: 898208 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/898208 ID: 898220 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/898220 ID: 898222 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/898222 ID: 898228 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/898228 ID: 898232 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/898232 ID: 898233 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi URL: https://openqa.fedoraproject.org/tests/898233 ID: 898244 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/898244 ID: 898294 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/898294 ID: 898313 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/898313 ID: 898342 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/898342 ID: 898351 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/898351 ID: 898352 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/898352 ID: 898367 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/898367 Soft failed openQA tests: 4/194 (x86_64), 5/133 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210527.n.1): ID: 898177 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/898177 ID: 898179 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/898179 ID: 898235 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/898235 ID: 898264 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/898264 ID: 898280 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/898280 ID: 898310 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/898310 ID: 898341 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/898341 ID: 898376 Test: aarch64 universal
Re: texlive 2021 landing in Rawhide
I have new builds of texlive (2021-41.fc35) and texlive-base (20210325-34.fc35) going. Fixes: - add texlive-gsftopk as a dependency on texlive-texlive-scripts for mktexpk - add texlive-psnfss as a dependency on texlive-latex - drop Requires: tex(psfonts.map), died with updmap-map - add tfm font provides to texlive-cm - add beamerthemenord component package to resolve broken deps - add latex-firstaid-dev component package to resolve broken deps - fix typo in Requires for texlive-pst-optexp - fix deps for texlive-kvmap Assuming those build (and they should, fingers crossed), I am cautiously optimistic that the reported build failures will go away. If they do not, you know what to do (either reply here, file new bugs, or add new info to the existing ones). Thanks for your help, ~spot On Thu, May 27, 2021 at 8:43 PM Miro Hrončok wrote: > On 27. 05. 21 23:17, Tom Callaway wrote: > > Hi Fedorans, > > > > Just a heads-up, texlive-base (where the compiled code and immediate > > dependencies lives) and texlive (where the thousands of other noarch > components > > live) have been updated to TeXLive 2021 in Rawhide (and the latest > available > > components from CTAN at the time I did the work). > > > > I've done local testing and everything seems to still work, but > inevitably, the > > act of updating TeXLive breaks things, so if your packages have TeX > > dependencies and stop building in rawhide, let me know. > > Hey Spot, thanks for the update. > > I see some problems in Koschei, I've reported them in > https://bugzilla.redhat.com/show_bug.cgi?id=1965547 > > Inlining the problems here as well in case you prefer to discuss them via > email: > > > https://koschei.fedoraproject.org/package/python-mplcairo?collection=f35 > https://koschei.fedoraproject.org/package/python-matplotlib?collection=f35 > > No package found for: tex(cmsy10.tfm) > No package found for: tex(cmmi10.tfm) > No package found for: tex(cmb10.tfm) > No package found for: tex(cmex10.tfm) > No package found for: tex(cmss10.tfm) > > > > > > https://koschei.fedoraproject.org/package/python-nbconvert?collection=f35 > > Problem: package texlive-scheme-full-9:svn54074-40.fc35.noarch > requires > texlive-collection-latexextra, but none of the providers can be installed > - conflicting requests > - nothing provides texlive-beamerthemenord needed by > texlive-collection-latexextra-9:svn59009-40.fc35.noarch > > > > > > https://koschei.fedoraproject.org/package/python-sphinx?collection=f35 > > This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021) (preloaded > format=pdflatex) > restricted \write18 enabled. > entering extended mode > (pdflatex/python.tex > LaTeX2e <2020-10-01> patch level 4 > L3 programming layer <2021-05-07> (./sphinxmanual.cls > Document Class: sphinxmanual 2019/12/01 v2.3.0 Document class (Sphinx > manual) > (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls > Document Class: report 2020/04/10 v1.4m Standard LaTeX document class > (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))) > (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty) > (/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty) > (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty<>) > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty > For additional information on amsmath, use the `?' option. > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty)) > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty) > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty)) > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def > (/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def)) > (/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf)) > (/usr/share/texlive/texmf-dist/tex/latex/psnfss/times.sty) > (/usr/share/texlive/texmf-dist/tex/latex/fncychap/fncychap.sty) > (./sphinx.sty > (/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty) > (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty > (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty) > (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty > (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty) > (/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg) > (/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def))) > (/usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty) > (/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty) > (/usr/share/texlive/texmf-dist/tex/latex/titlesec/titlesec.sty) > (/usr/share/texlive/texmf-dist/tex/latex/tabulary/tabulary.sty > (/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty)) >
Re: Question about Provides and Obsoletes
On 5/28/21 10:39 AM, Richard Shaw wrote: On Fri, May 28, 2021 at 9:32 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote: I understand that we should put "Obsoletes" statements in a spec file when a package changes its name, so the package with the new name can replace the package with the old name. But how long should the Obsoletes statements be left in the spec file? Should they stay there permanently, or should they be removed after some period of time, say after a few years? In particular, the KiCAD documentation used to be in a dozen packages, one per language. Between Fedora 23 and Fedora 24, this was changed, and all languages were placed in a single package, and Obsoletes lines were added so the new combined doc package could replace the individual language packages. Should those Obsoletes be left in the spec file, or is it ok to remove them, given that the name change happened 5 years ago? Fedora requires that upgrading should be possible from N-2 to current, so the TLDR version: Two releases. After that, there is no expectation that the system should upgrade cleanly. So things like Obsoletes, and version conditionals can be removed. If I mis-spoke, I'm sure I'll be corrected shortly :) Thanks! That makes sense. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Question about Provides and Obsoletes
On Fri, May 28, 2021 at 9:32 AM Steven A. Falco wrote: > I understand that we should put "Obsoletes" statements in a spec file when > a package changes its name, so the package with the new name can replace > the package with the old name. > > But how long should the Obsoletes statements be left in the spec file? > Should they stay there permanently, or should they be removed after some > period of time, say after a few years? > > In particular, the KiCAD documentation used to be in a dozen packages, one > per language. Between Fedora 23 and Fedora 24, this was changed, and all > languages were placed in a single package, and Obsoletes lines were added > so the new combined doc package could replace the individual language > packages. Should those Obsoletes be left in the spec file, or is it ok to > remove them, given that the name change happened 5 years ago? > Fedora requires that upgrading should be possible from N-2 to current, so the TLDR version: Two releases. After that, there is no expectation that the system should upgrade cleanly. So things like Obsoletes, and version conditionals can be removed. If I mis-spoke, I'm sure I'll be corrected shortly :) Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Question about Provides and Obsoletes
I understand that we should put "Obsoletes" statements in a spec file when a package changes its name, so the package with the new name can replace the package with the old name. But how long should the Obsoletes statements be left in the spec file? Should they stay there permanently, or should they be removed after some period of time, say after a few years? In particular, the KiCAD documentation used to be in a dozen packages, one per language. Between Fedora 23 and Fedora 24, this was changed, and all languages were placed in a single package, and Obsoletes lines were added so the new combined doc package could replace the individual language packages. Should those Obsoletes be left in the spec file, or is it ok to remove them, given that the name change happened 5 years ago? Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
HEADS UP: pyproject-rpm-macros-0-40 now sets %_pyproject_...dir relative to the source tree, not $PWD
Hello Pythonistas,
I've just updated pyproject-rpm-macros to 0-40 across all Fedora versions.
Update for CentOS Stream 9 is planned for next week(s).
There is a backwards incompatible enhancement. The "semi-internal"
%_pyproject_wheeldir and %_pyproject_builddir locations are now set relative to
the source tree, not $PWD. This allows stuff like:
%build
cd somewhere
%pyproject_wheel
cd -
cd somewhere_else
%pyproject_wheel
cd -
%install
%pyproject_install
The backwards compatibility is only affecting projects that already tried to do
this but needed some workarounds, e.g. python-flit has:
%build
cd flit_core
%pyproject_wheel
# Move %%{_pyproject_wheeldir}/flit_core wheel to the main dir
mv %{_pyproject_wheeldir} ..
...
This will now fail because %{_pyproject_wheeldir} *is* in ..
I will adapt python-flit and any other affected package in Fedora.
Other than that, there are just backwards compatible fixes.
In case you see any other problems with the upgrade, let me know.
Happy packaging!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Fri, May 28, 2021, at 5:43 AM, Neal Gompa wrote: > > Part of the point of the different working groups was to handle the > different use-cases *well* at their own pace. The CoreOS Working Group > is *explicitly* excluded and frankly unlikely to ever switch because > Colin believes I am not CoreOS, I'm an engineer working on it. > that Btrfs is only suitable for "pet" workloads[1] That's not what my blog said. One of the sub-headers is "BTRFS is good for "pet" systems". There's no word "only" there - you inserted that. On this topic though, if Fedora CoreOS didn't exist, this proposal to change Cloud would be significantly more consequential. The defaults *really matter* here in particular, even more than Workstation. But, I think because CoreOS does exist, this change matters less. One big advantage CoreOS has is Ignition, which allows provisioning filesystems in the initramfs, including the root partition. It works today to boot up a stock Fedora CoreOS AMI, OpenStack qcow2 etc. and provide an Ignition config that changes it: https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem And it works to use btrfs too! Just s/ext4/btrfs/ in the first example. (And that *exact same* Ignition config also works for bare metal) That's not true of cloud-init based systems - instead of e.g. you wanted to use xfs/ext4 for a high performance database-like workload, in cloud you'd need to attach a separate instance volume or so for `/var/lib/$whatever` (That said separate volumes can actually be a better approach anyways, it depends). Some traditional Cloud image users won't notice this or care (just like Workstation users) but others definitely will. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Fri, May 28, 2021 at 3:45 AM Peter Boy wrote: > > > > > Am 27.05.2021 um 00:59 schrieb Chris Murphy : > > > > On Wed, May 26, 2021 at 5:30 AM Peter Boy wrote: > > ... > > Whereupon Server SIG/WG perform an evaluation of Btrfs for their use > > cases, and decide Btrfs should be the default in a compelling manner, > > FESCo will approve it. And this plausibly could still happen for > > Fedora 35, if folks really want it to happen. > > Theoretically, it could. But practically, I don't see it happen. The need for > discussion is too great. And not everyone is as convinced as you are that > BTRFS is the non-plus-ultra for all possible use cases. > > > > Server SIG can do anything they > > want. Red Hat is doing the same. > > Nevertheless, coordination and cooperation is at least very desirable (in > fact, indispensable). And is is not just about who is paying the bills. > Beyond this crude economic dimension, Fedora benefits from the reputation of > being upstream for RHEL (and vice versa, for sure). A defiant "we can do as > we like" is not helpful. > Being upstream for RHEL also means pushing forward and demonstrating that things *can* work better in a different way. If we didn't, there's no way for RHEL to change. We bring no value as upstream if we don't actually *do* things. > > > > >> I think we have a misunderstanding here. My argument refers to expected > >> hurdles of a possible changeover process, not to technical features. > > > > My opinion is to not worry about the process in advance of arriving at > > the hurdle. You jump over the hurdle at the proper time. The vast > > majority of the process is about technical features liabilities. > > > > ... > > > And when we address discussion and evidence: > > > > Not often but sometimes folks ask "where has all the space gone?" > > following a Server installation. They're not expecting or maybe not > > discovering, that quite a lot is held in reserve in the VG. > > As said before, I agree with that, at least for the most part. I use BTRFS > myself in LVs to use specific capabilities. Still, I'm against converting > "with a flick of the wrist," so to speak. It needs careful preparation. And > one possible outcome is also, not to switch to BTRFS. I don't think it is a > given that a switch is right in any case. That is perhaps the difference > between us. > As I'll say further down, this was definitely not a "flick of the wrist" or a "snap" decision. > > >> Again, it’s not about technical properties. We have (or probably had?) an > >> agreement to align (or try to align) Server Edition and Cloud. That was 2 > >> or 3 months ago. Regarding to that agreement, it is a step into the wrong > >> direction. > > > > Is there a Server or Cloud meeting with minutes that this discussion > > happened in? Or email thread you can point to? > > Michel gave you the link. And there were several brief comments about that in > previous meetings and also before that reboot event. > > And when we address discussion and evidence: What I miss is a prior detailed > discussion of this change in cloud WG and coordination with other possible > affected areas, e.g. server or CoreOS. Part of the point of the different working groups was to handle the different use-cases *well* at their own pace. The CoreOS Working Group is *explicitly* excluded and frankly unlikely to ever switch because Colin believes that Btrfs is only suitable for "pet" workloads[1] despite the evidence to the contrary[2][3][4]. [1]: https://blog.verbum.org/2020/07/14/on-btrfs/ [2]: https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebook.html [3]: https://www.youtube.com/watch?v=U7gXR2L05IU [4]: https://lwn.net/Articles/824855/ > Cloud Working Group did not happened for years, then there were a few short, > sparsely-attended and content-dry meetings. A range of existing problems, > starting with lack of documentation. A hesitancy to make any change currently > to the cloud artifacts (expressed by Dusty Mabe at that March meeting, 3). > And then out of nowhere the file system conversion, a very central element. > To me, it seems like a playground for missionaries to gain ground, certainly > not like a considerate and methodical long-term design. > Actually, the Cloud WG members had been talking about this ad-hoc since all the desktop variants switched last year. The ticket[4] was filed around the same time the desktop change was proposed. Dusty, Joe, James, and myself had been talking about it outside of meetings since. David became interested after the Nest talk about Btrfs[5]. That conversation started again after my talk on Btrfs at DevConf.cz (the recording has not been published still, sadly). So this has been a long time coming. [4]: https://pagure.io/cloud-sig/issue/308 [5]: https://www.youtube.com/watch?v=iHjhouSxIrc -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org
Fedora-Cloud-34-20210528.0 compose check report
No missing expected images. Failed openQA tests: 8/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210527.0): ID: 897932 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start URL: https://openqa.fedoraproject.org/tests/897932 ID: 897933 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/897933 ID: 897934 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation URL: https://openqa.fedoraproject.org/tests/897934 ID: 897935 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging URL: https://openqa.fedoraproject.org/tests/897935 ID: 897936 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux URL: https://openqa.fedoraproject.org/tests/897936 ID: 897937 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli URL: https://openqa.fedoraproject.org/tests/897937 ID: 897938 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/897938 ID: 897939 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/897939 Soft failed openQA tests: 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210527.0): ID: 897945 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/897945 Passed openQA tests: 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
> Am 27.05.2021 um 00:59 schrieb Chris Murphy : > > On Wed, May 26, 2021 at 5:30 AM Peter Boy wrote: > ... > Whereupon Server SIG/WG perform an evaluation of Btrfs for their use > cases, and decide Btrfs should be the default in a compelling manner, > FESCo will approve it. And this plausibly could still happen for > Fedora 35, if folks really want it to happen. Theoretically, it could. But practically, I don't see it happen. The need for discussion is too great. And not everyone is as convinced as you are that BTRFS is the non-plus-ultra for all possible use cases. > Server SIG can do anything they > want. Red Hat is doing the same. Nevertheless, coordination and cooperation is at least very desirable (in fact, indispensable). And is is not just about who is paying the bills. Beyond this crude economic dimension, Fedora benefits from the reputation of being upstream for RHEL (and vice versa, for sure). A defiant "we can do as we like" is not helpful. > >> I think we have a misunderstanding here. My argument refers to expected >> hurdles of a possible changeover process, not to technical features. > > My opinion is to not worry about the process in advance of arriving at > the hurdle. You jump over the hurdle at the proper time. The vast > majority of the process is about technical features liabilities. > > ... > And when we address discussion and evidence: > > Not often but sometimes folks ask "where has all the space gone?" > following a Server installation. They're not expecting or maybe not > discovering, that quite a lot is held in reserve in the VG. As said before, I agree with that, at least for the most part. I use BTRFS myself in LVs to use specific capabilities. Still, I'm against converting "with a flick of the wrist," so to speak. It needs careful preparation. And one possible outcome is also, not to switch to BTRFS. I don't think it is a given that a switch is right in any case. That is perhaps the difference between us. >> Again, it’s not about technical properties. We have (or probably had?) an >> agreement to align (or try to align) Server Edition and Cloud. That was 2 or >> 3 months ago. Regarding to that agreement, it is a step into the wrong >> direction. > > Is there a Server or Cloud meeting with minutes that this discussion > happened in? Or email thread you can point to? Michel gave you the link. And there were several brief comments about that in previous meetings and also before that reboot event. And when we address discussion and evidence: What I miss is a prior detailed discussion of this change in cloud WG and coordination with other possible affected areas, e.g. server or CoreOS. Cloud Working Group did not happened for years, then there were a few short, sparsely-attended and content-dry meetings. A range of existing problems, starting with lack of documentation. A hesitancy to make any change currently to the cloud artifacts (expressed by Dusty Mabe at that March meeting, 3). And then out of nowhere the file system conversion, a very central element. To me, it seems like a playground for missionaries to gain ground, certainly not like a considerate and methodical long-term design. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210528.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210527.0): ID: 897922 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/897922 ID: 897929 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/897929 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
Hi, > I don't know why we all missed it. Butt that appears to be the case. > > However, the end goal is to create hybrid BIOS+UEFI cloud images via > kickstart. (Maybe down the road it could be generally useful, if/when the > existing bootloader UI bits go away.) https://git.kraxel.org/cgit/imagefish/tree/kickstart/el8.ks (for rhel8/centos8, probably wouldn't work as-is in f34+ because the unified grub feature changed the grub cfg file arrangements). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
