Re: WebKitGTK package naming
Note I'm following the pkg-config version, *not* the soname. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Wed, 2022-09-21 at 02:53 +0200, Kevin Kofler via devel wrote: > Tommy Nguyen wrote: > > DNF5 is ridiculously fast. > > It is faster, but "ridiculously"? In the metric that matters (elapsed > wallclock time), your benchmark shows the update taking 30% less > time. > > That said, there are other features of DNF5 (no more Python, shared > cache > between PackageKit and CLI) that are IMHO even more interesting than > the raw > speed gain. Would you have preferred if I used a different superlative? I still consider 30% less to be significant, especially because DNF5 processes metadata in parallel which makes things seem faster, whether perceived or real. And yes, the other improvements are good as well, but end users focus on speed. See: constant discussions about how to make DNF4 faster (including enabling fastestmirror which can make things slower) or perception that it is slower because it processes metadata at a different stage than apt for example. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: disable comps component in Bugzilla
Ben Cotton wrote: > On Tue, Sep 20, 2022 at 10:03 AM Neal Gompa wrote: >> >> The main reason would be blocker review, but I'm not sure how often it >> comes up in the past few cycles. > > Rarely, which is why I think using distribution as a proxy is fine. > For the curious, a total of 16 comps bugs have ever been a part of the > blocker or freeze exception process. Here's a list of release with > non-zero comps bugs in the blocker/FE processes: > > F18: 4 > F19: 1 > F21: 2 > F22: 1 > F23: 1 > F24: 1 > F28: 2 > F30: 1 > F32: 1 > F34: 2 That was almost every release, and in fact an average of around one such bug per release cycle. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
Brian C. Lane wrote:
> We have reached a point where boot security is important enough
LOL!
> that Windows is now only allowing their bootloader to be used.
It is blatantly obvious that that is actually the goal, not the means.
This is clearly a vendor lock-in "feature", with "security" used as the
excuse (just like other similar vendor lock-in "features", e.g., the iOS App
Store monopoly).
Incidentally, the "feature" not only prevents chainloading (which can be
worked around by using BootNext), but also disabling Restricted Boot
("Secure" Boot) altogether (which is a much worse restriction), because
that, too, changes the TPM PCR measurements.
But the marketing as a "security" "feature" clearly works, because there
does not seem to be any noticeable public outrage about these absolutely
unacceptable monopolistic restrictions.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: WebKitGTK package naming
Michael Catanzaro wrote: > Being different than other distros is most confusing of all! I have to disagree with that blanket assertion. E.g., I believe it would have been much more confusing for our users if we had shipped kdelibs 3.5.x as kdelibs4 (or "kdelibs4c2a" as Debian actually called it, because they also handled a libstdc++ soname bump in a totally weird way) rather than kdelibs3 as we did. I believe version numbers should be human-readable, not reflect the internal soname when they differ, even if that means we use a different package name than distributions like Debian stubbornly sticking to soname-based versioning. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
Tommy Nguyen wrote: > DNF5 is ridiculously fast. It is faster, but "ridiculously"? In the metric that matters (elapsed wallclock time), your benchmark shows the update taking 30% less time. That said, there are other features of DNF5 (no more Python, shared cache between PackageKit and CLI) that are IMHO even more interesting than the raw speed gain. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2022-09-20)
Miro Hrončok wrote: >* https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic > was submitted as an Fedora 37 update after it was deferred to Fedora > 38. We need to decide what to do. (mhroncok, 17:02:38) [snip] >* AGREED: The update may be shipped after Fedora 37 Beta release, > before the Fedora 37 Final Freeze. (+7,0,-0) (mhroncok, 17:12:48) This makes a farce of the whole Change process. I do not see why a Change that was deferred to the next release can now be rushed in post Beta during a feature freeze period where only release-critical bugs should be fixed. (And in the particular case of this Change, I also do not see why it was approved at all, be it for Fedora 37, 38, or some future version, for the reasons that were already stated by me and others when the Change was pre- announced for discussion. The feedback on the mailing list was entirely negative, the only people in favor were the submitters.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
For those who are still not convinced, here is a comparison: $ toolbox create -d fedora -r 37 && toolbox enter $ sudo time dnf upgrade -y 26.79user 3.46system 0:49.09elapsed 61%CPU (0avgtext+0avgdata 489304maxresident)k 47400inputs+1243320outputs (266major+377843minor)pagefaults 0swaps $ toolbox create -d fedora -r 37 && toolbox enter $ sudo dnf copr enable rpmsoftwaremanagement/dnf5-unstable $ sudo dnf install dnf5 -y $ sudo time dnf5 upgrade -y 11.55user 3.40system 0:33.98elapsed 44%CPU (0avgtext+0avgdata 199056maxresident)k 72inputs+1203072outputs (280major+191432minor)pagefaults 0swaps DNF5 is ridiculously fast. The new text output using the C++ fmt library is also a bonus. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Release rpkg-1.65 and fedpkg-1.43
Hi all, a new version rpkg-1.65 together with fedpkg-1.43 are released containing both features and bugfixes. Currently, all supported packages are present in stable repositories. Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.65.html https://docs.pagure.org/fedpkg/releases/1.43.html Both released (rpkg & fedpkg) versions need to be installed together, they contain some changes incompatible with older packages. Centpkg also requires the newest version of rpkg. Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.65-2.el7&builds=rpkg-1.65-2.el8&builds=rpkg-1.65-2.el9&builds=rpkg-1.65-2.fc35&builds=rpkg-1.65-2.fc36&builds=rpkg-1.65-2.fc37&builds=rpkg-1.65-2.fc38&builds=fedpkg-1.43-2.el7&builds=fedpkg-1.43-2.el8&builds=fedpkg-1.43-2.el9&builds=fedpkg-1.43-2.fc35&builds=fedpkg-1.43-2.fc36&builds=fedpkg-1.43-2.fc37&builds=fedpkg-1.43-2.fc38 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 https://bodhi.fedoraproject.org/updates/?packages=fedpkg&page=1 rpkg is also available from PyPI. Thanks to all contributors. Regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: WebKitGTK package naming
OK, thanks for the heads-up. I didn't notice this because I was looking at the GNOME build rules, where evolution-data-server does not yet depend on it. We'll need to coordinate with you to ensure the 2.38 -> 2.40 update goes smoothly, then. I don't expect this to be difficult: it should be simple changes only. Just need to be sure WebKitGTK, Builder, evolution-data-server, and gnome-initial-setup are all bundled into the same bodhi update. On Tue, Sep 20 2022 at 05:05:38 PM +0200, Milan Crha wrote: Thus some upstream changes will be needed there too. The transition will be painful, if the upstream is supposed to support both naming-s. No, there will be zero upstream support for webkit2gtk-5.0: it is actually already gone, replaced by webkitgtk-6.0. webkit2gtk-5.0 is was a WIP/unstable/development API, and 2.38 will be the last release with it available. I wanted to stabilize it in time for 2.38, but failed. I am pretty sure that webkitgtk-6.0 will be stable in time for 2.40, though. I'm actively working on this now. The goal will be to provide API and ABI stability for as long as possible, same as webkit2gtk-4.0 and webkit2gtk-4.1. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Tue, 2022-09-20 at 11:48 -0500, Chris Adams wrote: > Once upon a time, Chris Murphy said: > > An additional topic is having boot entries for Windows (and macOS) that > > don't work in the meantime. While we could just remove the scripts that > > create these entries to chainload another bootloader, they're still needed > > for BIOS systems which don't support bootnext. > > But not all Windows chainload boots will fail. It's not even all that > easy to tell which Windows installs will or won't work... the presence > of Bitlocker is not a 100% sign even (it could be an unlocked Bitlocker > install, which doesn't get the TPM measure and fail from grub). yeah, on the whole I'd prefer to leave it if we can't accurately decide when to include it. Note the rewritten criteria is OK with either. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2022-09-20)
=== #fedora-meeting: FESCO (2022-09-20) === Meeting started by mhroncok at 17:00:17 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2022-09-20/fesco.2022-09-20-17.00.log.html . Meeting summary --- * init process (mhroncok, 17:00:27) * #2859 F37 incomplete Changes: 100% complete deadline (mhroncok, 17:02:20) * https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic was submitted as an Fedora 37 update after it was deferred to Fedora 38. We need to decide what to do. (mhroncok, 17:02:38) * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2022-19a88d07b6 2 weeks ago (mhroncok, 17:11:19) * LINK: https://wiki.documentfoundation.org/Development/Java (zbyszek, 17:12:32) * AGREED: The update may be shipped after Fedora 37 Beta release, before the Fedora 37 Final Freeze. (+7,0,-0) (mhroncok, 17:12:48) * Next week's chair (mhroncok, 17:16:44) * ACTION: zbyszek will chair next meeting (mhroncok, 17:17:53) * Open Floor (mhroncok, 17:18:03) Meeting ended at 17:20:21 UTC. Action Items * zbyszek will chair next meeting Action Items, by person --- * zbyszek * zbyszek will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * mhroncok (40) * jvanek (33) * zodbot (14) * nirik (7) * adamw (7) * zbyszek (6) * sgallagh (4) * salimma (3) * mhayden (2) * Eighth_Doctor (2) * music[m] (2) * kalev (2) * decathorpe (0) * dcantrell (0) * music (0) * Conan_Kudo (0) * Pharaoh_Atem (0) * Son_Goku (0) * King_InuYasha (0) * Sir_Gallantmon (0) -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
... Downgrading: conmon x86_64 2:2.1.3-1.fc37 fedora 57 k grubby x86_64 8.40-66.fc37 fedora 33 k hdparmx86_64 9.62-4.fc37 fedora 96 k openssl-pkcs11x86_64 0.4.12-1.fc37 fedora 73 k qt5-qtquickcontrols2 x86_64 5.15.5-3.fc37 fedora1.7 M qt6-qtwayland x86_64 6.3.1-4.fc37 fedora971 k Transaction Summary === Install52 Packages Upgrade2499 Packages Remove 8 Packages Downgrade 6 Packages Total download size: 4.1 G Operation aborted. -- Fine on my system :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: disable comps component in Bugzilla
On Tue, Sep 20, 2022 at 10:01:36AM -0400, Ben Cotton wrote: > comps, the system of XML files used to put packages into functional > groups is hosted on a Pagure repo[1] but also has a Bugzilla > component. In the interests of simplicity, I propose to disable the > comps component and use the Pagure repo for all comps issues. In the > case where a change in comps is necessary for Bugzilla-based processes > (e.g. blockers), we can use a bug in the distribution component. > > I don't see a benefit to having the Bugzilla component for comps as a > general matter, but if there's a good argument for keeping it, let me > know. Otherwise, I plan to disable the component on Thursday 29 > September. Amusingly I think we in the past discussed closing the pagure project to issues and using bugzilla only. ;) But I'm fine doing either one... having one place for bugs instead of two is a good thing. What will be done with the existing open bugzilla bugs? (There's some overlap between the two it looks like). Close and ask them to refile? Refile for them? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
Once upon a time, Chris Murphy said: > An additional topic is having boot entries for Windows (and macOS) that don't > work in the meantime. While we could just remove the scripts that create > these entries to chainload another bootloader, they're still needed for BIOS > systems which don't support bootnext. But not all Windows chainload boots will fail. It's not even all that easy to tell which Windows installs will or won't work... the presence of Bitlocker is not a 100% sign even (it could be an unlocked Bitlocker install, which doesn't get the TPM measure and fail from grub). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Tue, Sep 20, 2022, at 9:50 AM, Brian C. Lane wrote: > On Mon, Sep 19, 2022 at 12:16:33PM -0700, Adam Williamson wrote: >> "The installer must be able to install into free space alongside an >> existing clean Windows installation and install a bootloader which can >> boot into both Windows and Fedora." >> >> to say: >> >> "The installer must be able to install into free space alongside an >> existing clean Windows installation. As long as the Windows >> installation does not have BitLocker enabled, the installer must also >> install a bootloader which can boot into both Windows and Fedora." > > We have reached a point where boot security is important enough that > Windows is now only allowing their bootloader to be used. With bitlocker > enabled this is working exactly how it was designed so I'd change the > wording to require that grub2 doesn't prevent windows from continuing to > boot via their preferred method and leave it at that. > > And while there may be a possible solution using BootNext, until someone > does the work and tests it there is no point in requiring grub2 to do > something it cannot do. An additional topic is having boot entries for Windows (and macOS) that don't work in the meantime. While we could just remove the scripts that create these entries to chainload another bootloader, they're still needed for BIOS systems which don't support bootnext. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022 at 12:16:33PM -0700, Adam Williamson wrote: > "The installer must be able to install into free space alongside an > existing clean Windows installation and install a bootloader which can > boot into both Windows and Fedora." > > to say: > > "The installer must be able to install into free space alongside an > existing clean Windows installation. As long as the Windows > installation does not have BitLocker enabled, the installer must also > install a bootloader which can boot into both Windows and Fedora." We have reached a point where boot security is important enough that Windows is now only allowing their bootloader to be used. With bitlocker enabled this is working exactly how it was designed so I'd change the wording to require that grub2 doesn't prevent windows from continuing to boot via their preferred method and leave it at that. And while there may be a possible solution using BootNext, until someone does the work and tests it there is no point in requiring grub2 to do something it cannot do. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022, at 1:16 PM, Adam Williamson wrote: > > "The installer must be able to install into free space alongside an > existing clean Windows installation and install a bootloader which can > boot into both Windows and Fedora." > > to say: > > "The installer must be able to install into free space alongside an > existing clean Windows installation. As long as the Windows > installation does not have BitLocker enabled, the installer must also > install a bootloader which can boot into both Windows and Fedora." Workstation working group discussed it at today's meeting, and there were no objections to the language change proposal. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote: > The only way to get the TPM state to match not using a particular loader > is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora > userspace) set EFI BootNext and reboot the machine. I know systemd-boot does implement bootnext, can modify it in NVRAM. But last I checked GRUB can't. I've asked upstream GRUB about supporting bootnext and a reboot, but the discussion didn't go anywhere. Is there any interest or work happening to make this possible? Because if not, then it seems the only way forward is efibootmgr, and see if desktops want to add a GUI wrapper around 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 List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: WebKitGTK package naming
Hi, On Tue, 2022-09-20 at 08:24 -0500, Michael Catanzaro wrote: > For now it's required by Builder and gnome-initial-setup ... and evolution-data-server, according to: dnf repoquery --alldeps --whatrequires "webkit2gtk5.0" and dnf repoquery --alldeps --whatrequires "pkgconfig(webkit2gtk-5.0)" Thus some upstream changes will be needed there too. The transition will be painful, if the upstream is supposed to support both naming-s. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022 at 9:17 PM Adam Williamson wrote: > "The installer must be able to install into free space alongside an > existing clean Windows installation. As long as the Windows > installation does not have BitLocker enabled, the installer must also > install a bootloader which can boot into both Windows and Fedora." > The updated criterion sounds OK to 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: disable comps component in Bugzilla
On Tue, Sep 20, 2022 at 10:03 AM Neal Gompa wrote: > > The main reason would be blocker review, but I'm not sure how often it > comes up in the past few cycles. Rarely, which is why I think using distribution as a proxy is fine. For the curious, a total of 16 comps bugs have ever been a part of the blocker or freeze exception process. Here's a list of release with non-zero comps bugs in the blocker/FE processes: F18: 4 F19: 1 F21: 2 F22: 1 F23: 1 F24: 1 F28: 2 F30: 1 F32: 1 F34: 2 -- Ben Cotton He / Him / His Fedora Program Manager 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: disable comps component in Bugzilla
On Tue, Sep 20, 2022 at 10:02 AM Ben Cotton wrote: > > comps, the system of XML files used to put packages into functional > groups is hosted on a Pagure repo[1] but also has a Bugzilla > component. In the interests of simplicity, I propose to disable the > comps component and use the Pagure repo for all comps issues. In the > case where a change in comps is necessary for Bugzilla-based processes > (e.g. blockers), we can use a bug in the distribution component. > > I don't see a benefit to having the Bugzilla component for comps as a > general matter, but if there's a good argument for keeping it, let me > know. Otherwise, I plan to disable the component on Thursday 29 > September. > > [1] https://pagure.io/fedora-comps > The main reason would be blocker review, but I'm not sure how often it comes up in the past few cycles. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Proposal: disable comps component in Bugzilla
comps, the system of XML files used to put packages into functional groups is hosted on a Pagure repo[1] but also has a Bugzilla component. In the interests of simplicity, I propose to disable the comps component and use the Pagure repo for all comps issues. In the case where a change in comps is necessary for Bugzilla-based processes (e.g. blockers), we can use a bug in the distribution component. I don't see a benefit to having the Bugzilla component for comps as a general matter, but if there's a good argument for keeping it, let me know. Otherwise, I plan to disable the component on Thursday 29 September. [1] https://pagure.io/fedora-comps -- Ben Cotton He / Him / His Fedora Program Manager 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 37 compose report: 20220920.n.0 changes
OLD: Fedora-37-20220919.n.0 NEW: Fedora-37-20220920.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 3 Dropped packages:1 Upgraded packages: 55 Downgraded packages: 0 Size of added packages: 1.20 MiB Size of dropped packages:126.77 KiB Size of upgraded packages: 682.74 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -2.84 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: javadocofflinesearch-2.2-15.fc35 Summary: Tool for offline searching in your docs via browser RPMs:javadocofflinesearch javadocofflinesearch-javadoc Size:407.69 KiB Package: qbe-1.0-4.fc37 Summary: A pure C embeddable compiler backend RPMs:qbe Size:236.92 KiB Package: telepathy-idle-0.2.2-1.fc37 Summary: IRC connection manager for Telepathy RPMs:telepathy-idle Size:589.27 KiB = DROPPED PACKAGES = Package: chrome-gnome-shell-10.1-17.fc37 Summary: Support for managing GNOME Shell Extensions through web browsers RPMs:chrome-gnome-shell Size:126.77 KiB = UPGRADED PACKAGES = Package: COPASI-4.36.260-1.fc37 Old package: COPASI-4.35.258-4.fc37 Summary: Biochemical network simulator RPMs: COPASI COPASI-data COPASI-doc COPASI-gui python3-COPASI Size: 55.48 MiB Size change: 43.21 KiB Changelog: * Tue Sep 13 2022 Antonio Trande - 4.36.260-1 - Release 4.36 build-260 Package: ansible-freeipa-1.8.4-1.fc37 Old package: ansible-freeipa-1.8.3-1.fc37 Summary: Roles and playbooks to deploy FreeIPA servers, replicas and clients RPMs: ansible-freeipa ansible-freeipa-tests Size: 535.15 KiB Size change: 14.27 KiB Changelog: * Mon Sep 12 2022 Thomas Woerner - 1.8.4-1 - Update to version 1.8.4 https://github.com/freeipa/ansible-freeipa/releases/tag/v1.8.4 Package: awscli-1.25.75-1.fc37 Old package: awscli-1.25.58-1.fc37 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.21 MiB Size change: 3.69 KiB Changelog: * Thu Aug 25 2022 Gwyn Ciesla - 1.25.60-1 - 1.25.60 * Thu Aug 25 2022 Gwyn Ciesla - 1.25.61-1 - 1.25.61 * Mon Aug 29 2022 Gwyn Ciesla - 1.25.62-1 - 1.25.62 * Mon Aug 29 2022 Gwyn Ciesla - 1.25.63-1 - 1.25.63 * Mon Sep 12 2022 Gwyn Ciesla - 1.25.72-1 - 1.25.72 * Tue Sep 13 2022 Gwyn Ciesla - 1.25.73-1 - 1.25.73 * Wed Sep 14 2022 Gwyn Ciesla - 1.25.74-1 - 1.25.74 * Thu Sep 15 2022 Gwyn Ciesla - 1.25.75-1 - 1.25.75 Package: cockpit-276.1-1.fc37 Old package: cockpit-274.1-1.fc37 Summary: Web Console for Linux servers RPMs: cockpit cockpit-bridge cockpit-doc cockpit-kdump cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws Size: 11.30 MiB Size change: 18.50 KiB Changelog: * Wed Sep 07 2022 Packit - 276-1 - Stability and performance improvements * Mon Sep 12 2022 Packit - 276.1-1 - login: Use valid selectors when testing for :is() / :where() support. Package: composer-2.4.2-1.fc37 Old package: composer-2.4.1-1.fc37 Summary: Dependency Manager for PHP RPMs: composer Size: 975.41 KiB Size change: 989 B Changelog: * Thu Sep 15 2022 Remi Collet - 2.4.2-1 - update to 2.4.2 Package: console-login-helper-messages-0.21.3-3.fc37 Old package: console-login-helper-messages-0.21.3-2.fc37 Summary: Combines motd, issue, profile features to show system information to the user before/on login RPMs: console-login-helper-messages console-login-helper-messages-issuegen console-login-helper-messages-motdgen console-login-helper-messages-profile Size: 48.58 KiB Size change: -935 B Changelog: * Tue Sep 13 2022 Timoth??e Ravier - 0.21.3-3 - Remove tpmfiles config for /run/motd.d (now provided by the setup package) (fedora#2120544) Package: containerd-1.6.8-4.fc37 Old package: containerd-1.6.8-2.fc37 Summary: Open and reliable container runtime RPMs: containerd containerd-devel Size: 119.31 MiB Size change: 64.86 KiB Changelog: * Wed Aug 10 2022 Maxwell G 1.6.8-3 - Rebuild to fix FTBFS * Sun Sep 11 2022 Robert-Andr?? Mauchin 1.6.8-4 - Fix FTBFS Package: converseen-0.9.9.8-1.fc37 Old package: converseen-0.9.9.7-1.fc37 Summary: A batch image conversion tool written in C++ with Qt5 and Magick++ RPMs: converseen Size: 1.84 MiB Size change: 9.20 KiB Changelog: * Thu Sep 15 2022 Filipe Rosset - 0.9.9.8-1 - Update to 0.9.9.8 fixes rhbz#2126958 Package: curblaster-1.14-1.fc37 Old package: curblaster-1.13-12.fc37 Summary: Sidescrolling shooter, carry the pods through the gate RPMs: curblaster Size: 674.02 KiB Size change: 6.98 KiB Changelog: * Wed Sep 14 2022 Gwyn Ciesla - 1.14-1 - 1.14
Re: WebKitGTK package naming
On Tue, Sep 20 2022 at 08:24:32 AM -0500, Michael Catanzaro wrote: Being different than other distros is most confusing of all! BTW part of the confusion here might be that you're used to the Fedora package name, webkit2gtk3. But all other distros just called it webkit2gtk. I want to avoid Fedora-specific things with the names this time around. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: WebKitGTK package naming
On Thu, Sep 15 2022 at 08:49:39 AM -0500, Michael Catanzaro wrote: I had a pet idea to change the API version to -4.5, so that we could sync up with GTK 5 with -5.0, but this didn't seem popular upstream. So now I'm toying with changing to -5.1 or -6.0 just to avoid confusion caused by webkit2gtk-5.0 looking almost the same as webkitgtk-5.0. We discussed this upstream and settled on webkitgtk-6.0 as the name for the GTK 4 API, to give slightly more distance between the GTK and WebKitGTK API versions. There was some interest in adding the GTK API version to the WebKitGTK API version, like you suggested, but it's a little complicated and there wasn't enough support to make this change. I want the downstream package names to match the upstream API names as closely as possible, so we can minimize the differences between Fedora names and other distros' names. Being different than other distros is most confusing of all! Ideally we would exactly match the upstream name, webkitgtk-6.0. But Kalev has pointed me to: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple as the guideline we followed when deciding to omit the hyphen. Specifically: "If the base package name does not end with a digit, the version MUST be directly appended to the package name with no intervening separator." So that's how we wound up with webkit2gtk4.0, webkit2gtk4.1, webkit2gtk5.0 (current package name), and now webkitgtk6.0 (future package name, to replace webkit2gtk5.0 in March). I'm not sure whether that guideline is actually a good idea, as it results in our names differing from other distros', but it's close enough. One more note: the webkit2gtk5.0 package will disappear within the lifetime of Fedora 37, so please don't actually use it. For now it's required by Builder and gnome-initial-setup, which will require special intervention when we update to WebKitGTK 2.40 in March. The goal is for the API to be stable in WebKitGTK 2.40, so holding off until then will help avoid trouble. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
Hi everyone, I'm getting questions where people could get the ISO image with the Anaconda Web UI. If you also have this question I tried to answer it here: https://discussion.fedoraproject.org/t/isos-with-the-new-installer-are-they-available-yet/42448/2?u=jkonecny TL;DR Don't worry, we are planning to release it about a week after the F37 GA. The exact date could change. Best Regards, Jirka Dne 15. 07. 22 v 23:30 Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The work on Web UI for the Anaconda installer has advanced enough so that it is possible to create and publish self contained preview images. == Owner == * Name: [[User:m4rtink| Martin Kolman]] * Email: mkol...@redhat.com == Detailed Description == Even though still very simple the new Anaconda Web UI is now far enough to support a simple installation workflow from a self-contained image while demonstrating all the main aspects of the new UI, such as: * flexible Wizard layout * responsive PatternFly components * new style built-in help * local and remote access to the Web UI For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. We aim to have the image available for download just after the F37 release (so that the tar-payload can contain final F37 release content) and then updated automatically in regular intervals. That way the rather active Web UI development of the Web UI will be reflected in the up-to-date installation image, as well as any feedback and community PRs. == Benefit to Fedora == The Anaconda Web UI will provide modern responsive user interface based on a well known and widely used toolkit (PatternFly) and backed by proven Cockpit tooling. The screen layout is based on latest UX design guidelines as well as usability testing of the new interface and extensive mockup work. There are improvements in developer experience as well due to the more modern & more mainstream UI technology chosen and powerful Cockpit test tooling (rich unit-test as well as pixel-test framework). The stateless property of the Web UI allows almost live-coding style of UI development. This should make it easier to work on the Anaconda Web UI for not only the Anaconda team, addon developer but also for any interested contributors. Remote Web UI access should also provide a much better experience than the slow and inefficient VNC based remote GUI installation support Anaconda has today. Due to no need for local rendering remotely driven GUI installations on a constrained hardware with minimal installation images should become possible. == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. It will be a '''preview image only''', not an official Fedora deliverable and it will not influence Fedora release criteria in any way. * Other developers: Other developers and Fedora users are welcome to try the image once it is released and to provide feedback. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == (not supplied) == How To Test == Download the Anaconda Web UI preview image and boot it on VM or hardware that contains no important data. Install using the Web UI locally, alternatively try using the Web UI remotely. The installed OS should be functional but its testing or any issues with it are currently out of scope for the Anaconda Web UI preview image. To provide feedback use one of the Anaconda team communication channels: * IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat * mailing list: anaconda-de...@lists.fedoraproject.org - https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org/ * Github Discussion: https://github.com/rhinstaller/anaconda/discussions == User Experience == Should be improved compared to the current GTK interface. == Dependencies == (not supplied) == Contingency Plan == * Contingency mechanism: If we hit some blocking technical issues, the image will be published later. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://
Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On 20-09-2022 07:12, Chris Murphy wrote: On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote: I'm fine with the proposed change. I'm also fine with the original text. During boot, certain actions are taken that are recorded in the TPM. These include, for instance, any loaders that are run - like grub2. The result is that if you load Windows from grub2 rather than the EFI firmware, the TPM state will be different. Bitlocker cares about this TPM state. So: if you install Windows and set up Bitlocker booting through grub, it will continue to work through grub. The Windows installer drops a payload on the drive, and sets a bootnext for an entry that points to the Windows bootloader, not via GRUB. And then, the instant we update either shim or grub, Windows boot will break. Does all this apply as well using sd-boot? If not, since this is the install phase, switching from grub to sd-boot when installing alongside Windows should be viable. Having said that, I am aware that sd-boot is currently not as well supported as grub2. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
