Fedora-Cloud-33-20201231.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 748899 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/748899 ID: 748906 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/748906 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[Bug 1911305] perl-JavaScript-Minifier-XS-0.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1911305 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-JavaScript-Minifier-XS |perl-JavaScript-Minifier-XS |-0.12 is available |-0.13 is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.13 Current version/release in rawhide: 0.11-20.fc33 URL: http://search.cpan.org/dist/JavaScript-Minifier-XS/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3010/ -- 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
[Bug 1911353] perl-CSS-Minifier-XS-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1911353 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-CSS-Minifier-XS-0.10 |perl-CSS-Minifier-XS-0.11 |is available|is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.11 Current version/release in rawhide: 0.09-22.fc33 URL: http://search.cpan.org/dist/CSS-Minifier-XS/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/11833/ -- 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
[389-devel] 389 DS nightly 2020-12-31 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/31/report-389-ds-base-1.4.4.9-1.fc33.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
License change: R-ggplot2 GPLv2 -> MIT
As in subject. -- Elliott ___ 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
License change: R-rlang GPLv3 -> MIT
As in subject. Due to other dependency changes, this will only be in Rawhide. -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Syngrafias - AsciiDocs Collaboration Tool for Fedora Documentation Maintainers, Available for testing
Hey Matthew! > This is super, super cool! We are so glad to know that you liked the idea. :) > One suggestion I have is to start in the simpler "Unity" mode rather than > the "Cellular" one by default. Also, in the Cellular one, provide a button > or something to add a new cell rather than requiring the menu item -- it > took me an embarrassingly long time to figure out how to start typing. Noted. We would make the "Unity Mode (ADOC)" as the default and give users the choice to move on to a much more sophisticated "Cellular Mode". Also, in order to add cells we are working on "Tabs UI" that we would love for you to take a look. You can find the preview of it here at https://github.com/t0xic0der/syngrafias/pull/87#issuecomment-752829071 and this makes adding cells and working on them a breeze. > As an end-state goal, I'd love to so anyone clicking "edit" on a page on > the > docs site got this editor! Sounds like an awesome plan to me. What do you say @nasirhm? Thank you for taking the time out to review the public preview and suggesting the changes. Wish you a very happy 2021! :D Regards, Akashdeep Dhar t0xic0der ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
On 12/29/20 11:26 PM, Samuel Sieb wrote: More likely what you're really confused about is something that a lot of people are not aware of. Wayland is a protocol, not a program. I believe there's a library, but the final implementation is done in each window manager. The X11 "emulation" is a program called XWayland that provides an interface layer between the X11 calls and whatever Wayland implementation is currently running. Thanks for clarifying; indeed it's the XWayland process that crashes. I actually support leaving X11 behind---I use wayland myself and I agree it's the correct evolutionary path for system graphics. I piped up in this discussion to point out that Wayland has rough spots. There are many legacy X11 apps still around, some possibly buggy. They should not crash XWayland in a way that nukes the entire desktop. Another problem is the reliability of input streams. The mouse behavior is realy weird sometimes, as if it was simultaneously losing events and getting spurious ones. I suspect that these issues are marginal enough to not affect the majority of users, which is why they aren't seen as urgent, but I think they should be addressed for a mainstream Wayland use. I would like to help debugging that, but it's a complex system and I wasn't able to find reliable information on how to look inside those issues. For instance, I understand the separation of layers in X11, and I know how to debug X11 events using xev and such---but I have no idea how to look into why my mouse clicks in Firefox under Wayland are so weird and unpredictable. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1909889] perl-DateTime-TimeZone-2.45 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909889 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-DateTime-TimeZone-2.45 |perl-DateTime-TimeZone-2.45 |-1.fc34 |-1.fc34 |perl-DateTime-TimeZone-2.45 |perl-DateTime-TimeZone-2.45 |-1.fc33 |-1.fc33 ||perl-DateTime-TimeZone-2.45 ||-1.fc32 --- Comment #6 from Fedora Update System --- FEDORA-2020-7ef8caa0e8 has been pushed to the Fedora 32 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
[Bug 1909889] perl-DateTime-TimeZone-2.45 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1909889 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-DateTime-TimeZone-2.45 |perl-DateTime-TimeZone-2.45 |-1.fc34 |-1.fc34 ||perl-DateTime-TimeZone-2.45 ||-1.fc33 Resolution|--- |ERRATA Last Closed||2020-12-31 02:02:31 --- Comment #5 from Fedora Update System --- FEDORA-2020-d1cbc3cc57 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
Re: Thoughts about packaging a standalone python-PyQt5-sip?
On Wed, 30 Dec 2020, Scott Talbert wrote: Neal and I are looking at getting ButterManager packaged, and it depends on sip and PyQt5-sip: https://github.com/egara/buttermanager/blob/master/requirements.txt Now, this is where things get a bit odd: - the current sip (4.19.24) does not have autogenerated Python provides, but sip5 does: $ sudo dnf repoquery --provides sip Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53 PM PST. sip = 4.19.24-1.fc33 sip(x86-64) = 4.19.24-1.fc33 sip-macros = 4.19.24-1.fc33 $ sudo dnf repoquery --provides sip5 Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53 PM PST. python-sip5 = 5.5.0-1.fc33 python3-sip5 = 5.5.0-1.fc33 python3.9-sip5 = 5.5.0-1.fc33 python3.9dist(sip) = 5.5 python3dist(sip) = 5.5 sip5 = 5.5.0-1.fc33 sip5(x86-64) = 5.5.0-1.fc33 - sip ships PyQt5 bindings with matching version, but sip 5 seems to no longer do so $ sudo dnf info python3-pyqt5-sip Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53 PM PST. Installed Packages Name : python3-pyqt5-sip Version : 4.19.24 Release : 1.fc33 Architecture : x86_64 Size : 244 k Source : sip-4.19.24-1.fc33.src.rpm Repository : @System From repo: fedora Summary : SIP - Python 3/C++ Bindings Generator for pyqt5 URL : https://riverbankcomputing.com/software/sip/intro License : GPLv2 or GPLv3 and (GPLv3+ with exceptions) Description : This is the Python 3 build of pyqt5-SIP. - https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in Fedora (available since last month) - there's a lot of packages that depend on python3-pyqt5-sip (though none use the canonical python3dist(pyqt5-sip) unfortunately) $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires 'python3dist(pyqt5-sip)' Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020 04:28:29 PM PST. $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires python3-pyqt5-sip Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020 04:28:29 PM PST. calibre-0:4.23.0-3.fc34.x86_64 krita-0:4.4.1-1.fc34.i686 krita-0:4.4.1-1.fc34.x86_64 libarcus-0:4.8.0-1.fc34.src mingw-python-qt5-0:5.15.0-4.fc34.src pyqtwebengine-0:5.15.0-2.fc33.src python-pyface-0:7.1.0-1.fc34.src python-pynest2d-0:4.8.0-1.fc34.src python-qt5-0:5.15.0-5.fc34.src python3-arcus-0:4.8.0-1.fc34.x86_64 python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64 python3-poppler-qt5-0:0.75.0-6.fc33.x86_64 python3-pyqtchart-0:5.15.2-1.fc34.i686 python3-pyqtchart-0:5.15.2-1.fc34.x86_64 python3-qgis-0:3.16.1-2.fc34.i686 python3-qgis-0:3.16.1-2.fc34.x86_64 python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64 python3-qt5-base-0:5.15.0-5.fc34.i686 python3-qt5-base-0:5.15.0-5.fc34.x86_64 qhexedit2-0:0.8.9-2.fc33.src scidavis-0:2.3.0-2.fc33.src veusz-0:3.3.1-1.fc34.src veusz-0:3.3.1-1.fc34.x86_64 Any idea what's the best way to handle this? and/or why PyQt5-sip's versioning get so far ahead of sip? I think fundamentally the version of PyQt5-sip probably needs to match (or be very close to) the version of sip that PyQt5 itself was compiled with. Also, it seems a bit odd that ButterManager requires PyQt5-sip>=12.7.0, but only requires sip>=4.19.8 (ie, a MUCH older version of sip). You might want to just try patching that out and/or inquire with upstream about whether that version dependency is correct. (Further details: the PyQt5-sip module consists of generated code that's created by the sip code generator.) Furthermore, I'm a bit confused about why ButterManager requires PyQt5-sip and sip to begin with. I can't see either being used in the current code on GitHub: [talbert@deasil buttermanager]$ grep -rsI sip * requirements.txt:PyQt5-sip>=12.7.0 requirements.txt:sip>=4.19.8 setup.py: 'sip>=4.19.8' snapcraft.yaml: - python3-sip Looking at the history...it almost looks like these dependencies were added due to a packaging bug in PyQt5 in Arch Linux?? [1] [1] https://github.com/egara/buttermanager/issues/13 So it seems like the PyQt5-sip and sip dependencies really shouldn't be there as ButterManager doesn't use them itself (that I can tell). Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thoughts about packaging a standalone python-PyQt5-sip?
On Wed, 30 Dec 2020, Michel Alexandre Salim wrote: Hi all, Neal and I are looking at getting ButterManager packaged, and it depends on sip and PyQt5-sip: https://github.com/egara/buttermanager/blob/master/requirements.txt Now, this is where things get a bit odd: - the current sip (4.19.24) does not have autogenerated Python provides, but sip5 does: $ sudo dnf repoquery --provides sip Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53 PM PST. sip = 4.19.24-1.fc33 sip(x86-64) = 4.19.24-1.fc33 sip-macros = 4.19.24-1.fc33 $ sudo dnf repoquery --provides sip5 Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53 PM PST. python-sip5 = 5.5.0-1.fc33 python3-sip5 = 5.5.0-1.fc33 python3.9-sip5 = 5.5.0-1.fc33 python3.9dist(sip) = 5.5 python3dist(sip) = 5.5 sip5 = 5.5.0-1.fc33 sip5(x86-64) = 5.5.0-1.fc33 - sip ships PyQt5 bindings with matching version, but sip 5 seems to no longer do so $ sudo dnf info python3-pyqt5-sip Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53 PM PST. Installed Packages Name : python3-pyqt5-sip Version : 4.19.24 Release : 1.fc33 Architecture : x86_64 Size : 244 k Source : sip-4.19.24-1.fc33.src.rpm Repository : @System From repo: fedora Summary : SIP - Python 3/C++ Bindings Generator for pyqt5 URL : https://riverbankcomputing.com/software/sip/intro License : GPLv2 or GPLv3 and (GPLv3+ with exceptions) Description : This is the Python 3 build of pyqt5-SIP. - https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in Fedora (available since last month) - there's a lot of packages that depend on python3-pyqt5-sip (though none use the canonical python3dist(pyqt5-sip) unfortunately) $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires 'python3dist(pyqt5-sip)' Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020 04:28:29 PM PST. $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires python3-pyqt5-sip Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020 04:28:29 PM PST. calibre-0:4.23.0-3.fc34.x86_64 krita-0:4.4.1-1.fc34.i686 krita-0:4.4.1-1.fc34.x86_64 libarcus-0:4.8.0-1.fc34.src mingw-python-qt5-0:5.15.0-4.fc34.src pyqtwebengine-0:5.15.0-2.fc33.src python-pyface-0:7.1.0-1.fc34.src python-pynest2d-0:4.8.0-1.fc34.src python-qt5-0:5.15.0-5.fc34.src python3-arcus-0:4.8.0-1.fc34.x86_64 python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64 python3-poppler-qt5-0:0.75.0-6.fc33.x86_64 python3-pyqtchart-0:5.15.2-1.fc34.i686 python3-pyqtchart-0:5.15.2-1.fc34.x86_64 python3-qgis-0:3.16.1-2.fc34.i686 python3-qgis-0:3.16.1-2.fc34.x86_64 python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64 python3-qt5-base-0:5.15.0-5.fc34.i686 python3-qt5-base-0:5.15.0-5.fc34.x86_64 qhexedit2-0:0.8.9-2.fc33.src scidavis-0:2.3.0-2.fc33.src veusz-0:3.3.1-1.fc34.src veusz-0:3.3.1-1.fc34.x86_64 Any idea what's the best way to handle this? and/or why PyQt5-sip's versioning get so far ahead of sip? I think fundamentally the version of PyQt5-sip probably needs to match (or be very close to) the version of sip that PyQt5 itself was compiled with. Also, it seems a bit odd that ButterManager requires PyQt5-sip>=12.7.0, but only requires sip>=4.19.8 (ie, a MUCH older version of sip). You might want to just try patching that out and/or inquire with upstream about whether that version dependency is correct. (Further details: the PyQt5-sip module consists of generated code that's created by the sip code generator.) Scott ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dddcb59a9c phpldapadmin-1.2.5-1.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83291355d7 openssl11-1.1.1g-2.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599 openjpeg2-2.3.1-10.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7c91badc19 guacamole-server-1.2.0-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing awstats-7.8-2.el7 partclone-0.3.17-1.el7 zchunk-1.1.9-1.el7 Details about builds: awstats-7.8-2.el7 (FEDORA-EPEL-2020-ab8d229496) Advanced Web Statistics Update Information: Security fix for CVE-2020-35176 ChangeLog: * Wed Dec 30 2020 Tim Jackson - 7.8-2 - Fix CVE-2020-35176 References: [ 1 ] Bug #1911644 - CVE-2020-35176 awstats: path traversal in awstats.pl https://bugzilla.redhat.com/show_bug.cgi?id=1911644 partclone-0.3.17-1.el7 (FEDORA-EPEL-2020-aece229736) Utility to clone and restore a partition Update Information: - Upgrade to 0.3.17 (#1911716) ChangeLog: * Wed Dec 30 2020 Robert Scheck 0.3.17-1 - Upgrade to 0.3.17 (#1911716) * Tue Jul 28 2020 Fedora Release Engineering - 0.3.12-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sun Feb 2 2020 Robert Scheck 0.3.12-4 - Added patch to declare variables as extern in header files * Wed Jan 29 2020 Fedora Release Engineering - 0.3.12-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jul 26 2019 Fedora Release Engineering - 0.3.12-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild References: [ 1 ] Bug #1911716 - partclone-0.3.17 is available https://bugzilla.redhat.com/show_bug.cgi?id=1911716 zchunk-1.1.9-1.el7 (FEDORA-EPEL-2020-f2e0453a3d) Compressed file format that allows easy deltas Update Information: - Fixes for test failures with zstd-1.4.7+ - Add man pages ChangeLog: * Wed Dec 30 2020 Jonathan Dieter - 1.1.9-1 - Fixes for test failures with zstd-1.4.7+ - Add man pages * Wed Jul 29 2020 Fedora Release Engineering - 1.1.5-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Fri Jan 31 2020 Fedora Release Engineering - 1.1.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing awstats-7.8-2.el8 libaesgm-20090429-24.el8 partclone-0.3.17-1.el8 zchunk-1.1.9-1.el8 Details about builds: awstats-7.8-2.el8 (FEDORA-EPEL-2020-d4406c9c75) Advanced Web Statistics Update Information: Security fix for CVE-2020-35176 ChangeLog: * Wed Dec 30 2020 Tim Jackson - 7.8-2 - Fix CVE-2020-35176 References: [ 1 ] Bug #1911644 - CVE-2020-35176 awstats: path traversal in awstats.pl https://bugzilla.redhat.com/show_bug.cgi?id=1911644 libaesgm-20090429-24.el8 (FEDORA-EPEL-2020-a43688fccf) Library implementation of AES (Rijndael) cryptographic methods Update Information: Build for EPEL8 ChangeLog: References: [ 1 ] Bug #1908934 - Please build libaesgm for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1908934 partclone-0.3.17-1.el8 (FEDORA-EPEL-2020-466f8204fb) Utility to clone and restore a partition Update Information: - Upgrade to 0.3.17 (#1911716) ChangeLog: * Wed Dec 30 2020 Robert Scheck 0.3.17-1 - Upgrade to 0.3.17 (#1911716) * Tue Jul 28 2020 Fedora Release Engineering - 0.3.12-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sun Feb 2 2020 Robert Scheck 0.3.12-4 - Added patch to declare variables as extern in header files * Wed Jan 29 2020 Fedora Release Engineering - 0.3.12-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #1911716 - partclone-0.3.17 is available https://bugzilla.redhat.com/show_bug.cgi?id=1911716 zchunk-1.1.9-1.el8 (FEDORA-EPEL-2020-9c3755d5e4) Compressed file format that allows easy deltas Update Information: - Fixes for test failures with zstd-1.4.7+ - Add man pages ChangeLog: * Wed Dec 30 2020 Jonathan Dieter - 1.1.9-1 - Fixes for test failures with zstd-1.4.7+ - Add man pages * Wed Jul 29 2020 Fedora Release Engineering - 1.1.5-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Fri Jan 31 2020 Fedora Release Engineering - 1.1.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ___ 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
Thoughts about packaging a standalone python-PyQt5-sip?
Hi all, Neal and I are looking at getting ButterManager packaged, and it depends on sip and PyQt5-sip: https://github.com/egara/buttermanager/blob/master/requirements.txt Now, this is where things get a bit odd: - the current sip (4.19.24) does not have autogenerated Python provides, but sip5 does: $ sudo dnf repoquery --provides sip Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53 PM PST. sip = 4.19.24-1.fc33 sip(x86-64) = 4.19.24-1.fc33 sip-macros = 4.19.24-1.fc33 $ sudo dnf repoquery --provides sip5 Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53 PM PST. python-sip5 = 5.5.0-1.fc33 python3-sip5 = 5.5.0-1.fc33 python3.9-sip5 = 5.5.0-1.fc33 python3.9dist(sip) = 5.5 python3dist(sip) = 5.5 sip5 = 5.5.0-1.fc33 sip5(x86-64) = 5.5.0-1.fc33 - sip ships PyQt5 bindings with matching version, but sip 5 seems to no longer do so $ sudo dnf info python3-pyqt5-sip Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53 PM PST. Installed Packages Name : python3-pyqt5-sip Version : 4.19.24 Release : 1.fc33 Architecture : x86_64 Size : 244 k Source : sip-4.19.24-1.fc33.src.rpm Repository : @System From repo: fedora Summary : SIP - Python 3/C++ Bindings Generator for pyqt5 URL : https://riverbankcomputing.com/software/sip/intro License : GPLv2 or GPLv3 and (GPLv3+ with exceptions) Description : This is the Python 3 build of pyqt5-SIP. - https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in Fedora (available since last month) - there's a lot of packages that depend on python3-pyqt5-sip (though none use the canonical python3dist(pyqt5-sip) unfortunately) $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires 'python3dist(pyqt5-sip)' Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020 04:28:29 PM PST. $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires python3-pyqt5-sip Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020 04:28:29 PM PST. calibre-0:4.23.0-3.fc34.x86_64 krita-0:4.4.1-1.fc34.i686 krita-0:4.4.1-1.fc34.x86_64 libarcus-0:4.8.0-1.fc34.src mingw-python-qt5-0:5.15.0-4.fc34.src pyqtwebengine-0:5.15.0-2.fc33.src python-pyface-0:7.1.0-1.fc34.src python-pynest2d-0:4.8.0-1.fc34.src python-qt5-0:5.15.0-5.fc34.src python3-arcus-0:4.8.0-1.fc34.x86_64 python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64 python3-poppler-qt5-0:0.75.0-6.fc33.x86_64 python3-pyqtchart-0:5.15.2-1.fc34.i686 python3-pyqtchart-0:5.15.2-1.fc34.x86_64 python3-qgis-0:3.16.1-2.fc34.i686 python3-qgis-0:3.16.1-2.fc34.x86_64 python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64 python3-qt5-base-0:5.15.0-5.fc34.i686 python3-qt5-base-0:5.15.0-5.fc34.x86_64 qhexedit2-0:0.8.9-2.fc33.src scidavis-0:2.3.0-2.fc33.src veusz-0:3.3.1-1.fc34.src veusz-0:3.3.1-1.fc34.x86_64 Any idea what's the best way to handle this? and/or why PyQt5-sip's versioning get so far ahead of sip? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 5:01 PM Chris Murphy wrote: > > On Wed, Dec 30, 2020 at 2:09 PM Javier Martinez Canillas > wrote: > > > On Wed, Dec 30, 2020 at 9:22 PM Adam Williamson > > wrote: > > > > * We wouldn't have a "consistent configuration" across everybody, > > > really, because anyone who upgraded from pre-F34 would still have the > > > old config; every bootloader debugging session ever would start by > > > figuring out which case this was. > > > These are all fair points. My worry is that trying to switch to the > > new configuration on upgrades could lead to issues for people that > > have custom GRUB configs. That was the case when we did the switch to > > using BLS snippets and I don't really want to repeat that experience > > for users. > > That problem was the result of quite old core.img in the MBR gap (or > BIOS Boot partition). As that change simultaneously depended on > shipping a new GRUB module without a way to update the core.img with > up-to-date GRUB modules, there was a known weak spot that we even knew > of in advance. > > Upgrades of customized configurations that deviate significantly from > defaults aren't supported. It's best effort. We can't be blocking on > people's customizations. > > I think we can come pretty close to atomically renaming > > /EFI/fedora/grub.cfg /EFI/fedora/grub.cfg.old > /EFI/fedora/grub.cfg.new to /EFI/fedora/grub.cfg > > And at least ensure the user can boot the old one, but even this I > think is pretty unlikely. It's really a teeny tiny window of failure > opportunity. And based on my reading of rename() if the files are > already all present, and all we're doing is renaming them, there > shouldn't be a case where grub.cfg is either missing entirely or zero > bytes. > > But dm-log-writes can help confirm or deny this. What I don't know is > if this can be done with bash. The convert script probably needs to be > done in C. Or at least the rename and sync parts. Oh I forgot the part about the convert script testing for custom grub.cfg. Maybe it's possible to parse it first, and if it's custom, bail. If it's non-custom then convert it. And a variation where we have an opt-in for this convert script for Fedora 34 cycle. And then ship it and do the conversion in Fedora 35. I think either never fixing this, or never updating systems to the "new way" are both untenable. We saw with the BLS switch many users depend on doing in place upgrades. Many were pushing 4 or more years. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 2:09 PM Javier Martinez Canillas wrote: > On Wed, Dec 30, 2020 at 9:22 PM Adam Williamson > wrote: > > * We wouldn't have a "consistent configuration" across everybody, > > really, because anyone who upgraded from pre-F34 would still have the > > old config; every bootloader debugging session ever would start by > > figuring out which case this was. > These are all fair points. My worry is that trying to switch to the > new configuration on upgrades could lead to issues for people that > have custom GRUB configs. That was the case when we did the switch to > using BLS snippets and I don't really want to repeat that experience > for users. That problem was the result of quite old core.img in the MBR gap (or BIOS Boot partition). As that change simultaneously depended on shipping a new GRUB module without a way to update the core.img with up-to-date GRUB modules, there was a known weak spot that we even knew of in advance. Upgrades of customized configurations that deviate significantly from defaults aren't supported. It's best effort. We can't be blocking on people's customizations. I think we can come pretty close to atomically renaming /EFI/fedora/grub.cfg /EFI/fedora/grub.cfg.old /EFI/fedora/grub.cfg.new to /EFI/fedora/grub.cfg And at least ensure the user can boot the old one, but even this I think is pretty unlikely. It's really a teeny tiny window of failure opportunity. And based on my reading of rename() if the files are already all present, and all we're doing is renaming them, there shouldn't be a case where grub.cfg is either missing entirely or zero bytes. But dm-log-writes can help confirm or deny this. What I don't know is if this can be done with bash. The convert script probably needs to be done in C. Or at least the rename and sync parts. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Any interest? ButterManager and grub-btrfs
Hullo! On Wed, 2020-12-30 at 21:12 +, Justin W. Flory wrote: > Hi all! > > ngompa and I were talking to the upstream maintainer of the > ButterManager backup tool about packaging for Fedora. Upstream is > ready > to collaborate on a RPM spec file if there is an interest in > packaging > for Fedora: > > https://twitter.com/eloygara/status/1344006727583330305 > > https://github.com/egara/buttermanager > > https://github.com/Antynea/grub-btrfs > > The maintainer is willing to work with someone on a package and > possibly > host it upstream: > > https://twitter.com/eloygara/status/1344309377101164546 > > There is interesting functionality for Btrfs snapshots here. The idea > of > being able to jump into any given system snapshot from the GRUB boot > menu is appealing to me. :-) > > Neither Neal or I have time to pick these up as new packages, but I > wanted to share the package on devel@ in case anyone were interested > in > bringing this to Fedora users now that Btrfs is the default > filesystem. > Happy to help here, Neal and I had a previous conversation on the topic and leveraging an existing tool sounds like a great idea. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Mon, 2020-12-21 at 13:02 +0100, Miroslav Suchý wrote: > Dne 19. 12. 20 v 21:24 Luya Tshimbalanga napsal(a): > > Just an idea of a form application that generates the spec file for > > newcomers as an example. > > Something like > https://xsuchy.github.io/rpm-spec-wizard/ > ? > rpmdev-newspec also works fine. The problem is that it's meant to be cross-platform and so the specs might not always align with the latest Fedora Packaging Guidelines. Sometimes it's lagging behind too; perhaps we could make it part of the process for updating packaging guidelines to also verify that the templates are up to date? Also, templates only exist for some usecases; from the help: -t TYPE, --type TYPE Force use of the TYPE spec template. The default is guessed from , falling back to "minimal" if the guesswork does not result in a more specific one or if is not given. Available types: dummy lib minimal ocaml perl php-pear python R ruby Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 5:48 PM Marius Schwarz wrote: > > Am 30.12.20 um 22:14 schrieb Michel Alexandre Salim: > > - a separate partition for storing GRUB config, no matter what > > architecture, is probably the ideal solution > Not always. In VMs you would reduce the amount of partitions to ease up > things. The main problem with Vms is, that you have LTS based linux > distros on the host systems which can't mount the vm guest, if the guest > uses newer filesystems. If you then use BTRFS on the boot partition or > store grub configs in partionheaders, you can't access those from the > guest making it impossible to change the bootconfig, if it fails for > some stupid reasons like older pygrub ( xen ) boot loaders, which can't > handle the kernel images compression/format. Happend last with Xenserver > and Kernel 5.9. > > For this, i.E. me, choose to store the boot config on / so we have just > one partition with ext4, which can easily mounted on the host, as ext4 > can be handled by the older LTS systems on the host. > > As Fedora is a good server os, if the ui parts have been removed ;), it > should be taken into any consideration, that it may not be a bare metal > installation you make plans for. It still needs to run in good old > stable setups ;) > The issues Michel is referring to do not apply to Fedora Server using Btrfs, because outside of Workstation, currently no variant of Fedora has cross-layer integration with the bootloader. That is, Fedora KDE does not currently have integration at the desktop level to trigger different GRUB states like GNOME will in Workstation. Cockpit in Fedora Server Edition also lacks this ability. Most of this is due to missing documentation to actually *implement* the capability in other variants. But the side effect is that the concern we have is pretty much exclusive to Fedora Workstation. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 7:54 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/LTOBuildImprovements > > > == Summary == > Currently all packages that are not opted out of LTO include > -ffat-lto-objects in their build flags. This proposal would remove > -ffat-lto-objects from the default LTO flags and only use it for > packages that actually need it. > > == Owner == > * Name: [[User:law | Jeff Law]] > * Email: l...@redhat.com > > > == Detailed Description == > -ffat-lto-objects was added to the default LTO flags to ensure that > any installed .o/.a files included actual compiled code rather than > just LTO bytecodes (which are stripped after the install phase). > However, that is wasteful from a compile-time standpoint as few > packages actually install any .o/.a files. > > This proposal would remove -ffat-lto-objects from the default LTO > flags and packages that actually need the option would have to opt-in > via an RPM macro in their .spec file. This should significantly > improve build times for most packages in Fedora. > Does this mean that packages that are explicitly shipping a static library to the end user need to enable this macro to allow the installed static library to be usable by an end-user's compiler? If this is the case, then the packaging guidelines should be updated to reflect this. > > To ensure that we can identify packages that need the opt-in now and > in the future, the plan is to pass to brp-strip-lto a flag indicating > whether or not the package has opted into -ffat-lto-objects. If > brp-strip-lto finds .o/.a files, but the package has not opted into > -ffat-lto-objects, then brp-strip-lto would signal an error. > > > == Benefit to Fedora == > The key benefit to Fedora is improved package build times and lower > load on the builders. > > == Scope == > * Proposal owners: The feature owner (Jeff Law) will need to settle on > a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, > implement the necessary tests in brp-strip-lto and opt-in the initial > set of packages. This will be accomplished by doing the prototype > implementation locally, building all the Fedora packages to generate > the opt-in set. Committing the necessary opt-ins, then committing the > necessary changes to the RPM macros. > > * Other developers: There should be minimal work for other > developers. The most likely scenarios where other developers will > need to get involved would include: > # Packages which are excluded from x86_64 builds and which need the > opt-in will need the appropriate package owners to add the opt-in. > # Packages which are FTBFS when the builds are run to find the set of > packages that need to opt-in and which need to opt-in will need > packager attention. > # It is possible that the faster builds may trigger build failures in > packages that have missing dependencies in their Makefiles. We saw a > few of these during the initial LTO work and those packages were > either fixed or -j parallelism removed. This work may expose more of > these problems. > > I expect these all to be relatively rare occurences, but with 9000+ > packages in Fedora I wouldn't be surprised if we see a few of each of > these issues. > > * Release engineering: [https://pagure.io/releng/issues #Releng issue > number] (a check of an impact with Release Engineering is needed) This > should have no release engineering impacts. > * Policies and guidelines: The packaging guidelines will need to be > updated to document the new macro. > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: This proposal does not align with any > current Fedora Objectives. > > == Upgrade/compatibility impact == > This change should have zero impact on upgrade/compatibility. In > fact, the change should have no user visible impacts. > > > == How To Test == > No special testing is needed. Any issues with this proposal will show > up as FTBFS issues. > > > == User Experience == > Users should see no changes to the user experience. > > == Dependencies == > Packages which need to opt-in to -ffat-lto-objects will need their > .spec files updated to include the > new macro. > > > == Contingency Plan == > If this can not be completed by final development freeze, then the RPM > macro changes would not be installed and the change could defer to > Fedora 35. > * Contingency mechanism: Proposal owner will only commit the RPM macro > changes once the opt-in package set has been identified and opt-ins > added to those package's spec files. So no special contingency > mechanism should be needed > * Contingency deadline: It is most beneficial to have this completed > before the mass rebuild; however, the drop dead date should be beta > freeze. > * Blocks release? No > * Blocks product? No > > == Documentation == > No upstream documentation. Packaging guidelines will need a minor update. > > == Release Notes == > I do not expect this change to require any release notes. > > > -- >
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
Am 30.12.20 um 22:14 schrieb Michel Alexandre Salim: - a separate partition for storing GRUB config, no matter what architecture, is probably the ideal solution Not always. In VMs you would reduce the amount of partitions to ease up things. The main problem with Vms is, that you have LTS based linux distros on the host systems which can't mount the vm guest, if the guest uses newer filesystems. If you then use BTRFS on the boot partition or store grub configs in partionheaders, you can't access those from the guest making it impossible to change the bootconfig, if it fails for some stupid reasons like older pygrub ( xen ) boot loaders, which can't handle the kernel images compression/format. Happend last with Xenserver and Kernel 5.9. For this, i.E. me, choose to store the boot config on / so we have just one partition with ext4, which can easily mounted on the host, as ext4 can be handled by the older LTS systems on the host. As Fedora is a good server os, if the ui parts have been removed ;), it should be taken into any consideration, that it may not be a bare metal installation you make plans for. It still needs to run in good old stable setups ;) Best regards and a happy New Year 2021 to all, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
Howdy, On Sat, 2020-12-26 at 20:39 +, Sérgio Basto wrote: > Hi, > For me the most time consuming is monkey updates packages like kde > apps > , which every month or two we have a new release ( kde app 20.04.1 > 20.04.2 20.08.0 , 20.12.00 etc ) > > I did some scripts to automate my builds , we got some software like > https://github.com/fedora-infra/the-new-hotness/ > but the more I do, I always some variables that are different from > project to project , we need to know the version number, we may need > to > download more than one source, we may need drop patches that we know > that are already upstreamed, not all the package are build in same > branches so we need to know what branches we want update , we may > have > to add buildroot-overrides, we need add build to bodhi and fill some > information , we need close bugs create made by hotness or other > users > etc > > Examples of my scripts are usually in packages sources like > > https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/update_vbox.sh > > > or (in attachment) scripts in very quick-and-dirty style > > So, combine tools like rpmdevtools , the-new-hotness , bodhi-client > etc > we improve building automation . > My use case is similar: I comaintain a list of packages that Facebook open-sources that need to be rebuilt in step (since sadly ABI stability is not currently promised). I've cleaned-up my scripts: https://pagure.io/michel-slm/bulk-rebuild and blogged about them: https://michel-slm.name/posts/2020-12-30-fedora-bulk-rebuild/ They mostly wrap around rpmdev-bumpspec, fedpkg, and bodhi right now. Curious to see how much can be factored out and shared among different packagers that perform similar tasks. e.g. I see the GNOME packagers doing bulk updates too. One observation (also in the post): The CLIs for fedpkg and koji is currently meant for human, not machine, consumptions. Invoking them from Bash scripts and trying to use the output (e.g. getting the name of that side tag) involves some brittle parsing. I plan to rewrite this in Python anyway, but it might be useful to add an output formatter to some commands where it makes sense (e.g. request-side-tag or chain-build). Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Am 30.12.20 um 14:07 schrieb Mattia Verga via devel: Il 30/12/20 10:14, Marius Schwarz ha scritto: Don't you need to recompile stuff first to have an effect? :) I've just pushed a rebuild for qt5-qtwebengine, let's see if that's enough. I had a chromium 85 build running instead of the 87er, that had no problems rendering texts. My guerss is, that chromium needs a rebuild too. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: runtime dependencies not in Requires spec section
On Wed, Dec 30, 2020 at 2:49 PM Germano Massullo wrote: > I am one of the keepassxc maintainers. Bugreport > > "Missing dependency: qt5-qtsvg libQt5Svg.so.5" > https://bugzilla.redhat.com/show_bug.cgi?id=1911210 > > made me wonder about the following thing: > > I just installed a basic Fedora server to do a test concerning keepassxc > libs. Keepassxc spec file [1] does not contain any Requires dependency, but > when I install it, it triggers the installation of these libraries [2] that > are needed at runtime. > > My question is: how can keepassxc trigger the installation of such libraries > if the spec file does not contain any Requires dependency that should be the > attribute to identify runtime dependencies that are needed by the package? RPM can query ELF objects (executables and shared libraries) to find DT_NEEDED fields. That gives it a list of libraries that are depended on directly. It generates Requires for those dependencies automatically; see /usr/lib/rpm/find-requires. So the keepassxc package does contain Requires, they just don't appear explicitly in the spec file (and shouldn't). -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
On Wed, Dec 30, 2020 at 2:46 PM Michel Alexandre Salim wrote: > I see this documented here: > https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_consequences_of_a_package_being_deprecated > > but not in the packaging guideline: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > and IIRC fedora-review does not require this check either. I think it's > probably quite safe to assume the risk of someone creating a new > package that depends on xemacs or neXtaw to be quite low, but should > the main guidelines and fedora-review be updated too? (separately from > this Change, that is). > > I must admit this is the first time I noticed `Provides: deprecated()` Actually, fedora-review does check for deprecated dependencies. See CheckIfDepsDeprecated in /usr/share/fedora-review/plugins/generic.py. -- Jerry James http://www.jamezone.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
runtime dependencies not in Requires spec section
I am one of the keepassxc maintainers. Bugreport "Missing dependency: qt5-qtsvg libQt5Svg.so.5" https://bugzilla.redhat.com/show_bug.cgi?id=1911210 made me wonder about the following thing: I just installed a basic Fedora server to do a test concerning keepassxc libs. Keepassxc spec file [1] does not contain any Requires dependency, but when I install it, it triggers the installation of these libraries [2] that are needed at runtime. My question is: how can keepassxc trigger the installation of such libraries if the spec file does not contain any Requires dependency that should be the attribute to identify runtime dependencies that are needed by the package? Thank you [1]: https://src.fedoraproject.org/rpms/keepassxc/blob/master/f/keepassxc.spec [2]: fontconfig freetype glx-utils graphite2 harfbuzz langpacks-core-font-en libICE libSM libX1 libX11-common libX11-xcb libXau libXdamage libXext libXfixes libXi libXtst libXxf86vm libdrm libevdev libglvnd libglvnd-egl libglvnd-glx libinput libjpeg-turbo libpciaccess libsodium libwacom libwacom-data libwayland-client libwayland-server libxcb libxkbcommon-x11 libxshmfence libyubikey llvm-libs mesa-filesystem mesa-libEGL mesa-libGL mesa-libgbm mesa-libglapi mtdev pcre2-utf16 qt-settings qt5-qtbase qt5-qtbase-common qt5-qtbase-gui qt5-qtsvg qt5-qtx11extras quazip-qt5 xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm xml-common ykpers Weak dependencies: mesa-dri-drivers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Wed, 2020-12-30 at 16:28 -0500, Elliott Sales de Andrade wrote: > On Wed, 30 Dec 2020 at 14:53, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression > > > > == How to test == > > > > Existing systems can be converted to use compression manually with > > btrfs filesystem defrag -czstd -r, updating > > `/etc/fstab` > > Update `/etc/fstab` how? Please be more explicit. > Good point, thanks. Adding it now. > -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
On Wed, 2020-12-30 at 14:53 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Deprecate_xemacs > > > == Summary == > Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, > and > neXtaw packages, all of which have dead upstreams. > > == Owner == > * Name: [[User:jjames|Jerry James]] > * Email: loganje...@gmail.com > > > == Detailed Description == > > I have been part of XEmacs upstream for over 20 years, and have > maintained the Fedora package for over 11 years. Upstream > development > had already slowed significantly when I became Fedora maintainer. > The > last release was over 7 years ago. Since that time, development has > essentially come to a halt. Somebody will push a commit every now > and > then, but significant bugs are not being fixed. I see no future for > the project. We should start moving towards dropping it from the > distribution. The upstream sources have been spread across 3 > packages > in Fedora: xemacs, xemacs-packages-base, and xemacs-packages-extra. > In addition, the xemacs package uses an ancient, unmaintained 3D X > library: neXtaw. It's last release was in 2003. Since xemacs is the > only package in Fedora that uses neXtaw, I propose that it also be > deprecated so we can eventually drop it. > > Deprecation is warranted because there are about a dozen XEmacs add- > on > packages in Fedora. This will prevent us from adding any more as we > work to retire the existing add-ons. > > == Feedback == > > On December 7, 2020, I > [ > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VDETPULZDBMXBXJKEFZX7DQ5R6W6FBXT/ > communicated my intent to file this Change] on fedora-devel-list. > There has been no community feedback. > > == Benefit to Fedora == > > This Change will open a path for us to eventually remove unmaintained > software from the distribution. > > == Scope == > * Proposal owners: > The only required work is the addition of `Provides: deprecated()` to > the 4 affected packages. > [snip] I see this documented here: https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_consequences_of_a_package_being_deprecated but not in the packaging guideline: https://docs.fedoraproject.org/en-US/packaging-guidelines/ and IIRC fedora-review does not require this check either. I think it's probably quite safe to assume the risk of someone creating a new package that depends on xemacs or neXtaw to be quite low, but should the main guidelines and fedora-review be updated too? (separately from this Change, that is). I must admit this is the first time I noticed `Provides: deprecated()` Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Wed, 30 Dec 2020 at 14:53, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression > > == Summary == > > On variants using btrfs as the default filesystem, enable transparent > compression using zstd. Compression saves space and can significantly > increase the lifespan of flash-based media by reducing write > amplification. It can also increase read and write performance. > > == Owners == > > * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide > Cavalca]], [[User:josef|Josef Bacik]] > * Email: mic...@michel-slm.name, dcava...@fb.com, jo...@toxicpanda.com > > > == Detailed description == > > Transparent compression is a btrfs feature that allows a btrfs > filesystem to apply compression on a per-file basis. Of the three > supported algorithms, zstd is the one with the best compression speed > and ratio. Enabling compression saves space, but it also reduces write > amplification, which is important for SSDs. Depending on the workload > and the hardware, compression can also result in an increase in read > and write performance. > > See https://pagure.io/fedora-btrfs/project/issue/5 for details. This > was originally scoped as an optimization for > https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora > 33. > > > == Benefit to Fedora == > > Better disk space usage, reduction of write amplification, which in > turn helps increase lifespan and performance on SSDs and other > flash-based media. It can also increase read and write performance. > > == Scope == > > * Proposal owners: > ** Update anaconda to perform the installation using mount -o > compress=zstd:1 > ** Set the proper option in fstab (alternatively: set the XATTR) > ** Update disk image build tools to enable compression: > *** lorax > *** appliance-tools > *** osbuild > *** imagefactory > ** [optional] Add support for > [https://github.com/kdave/btrfs-progs/issues/328 setting compression > level when defragmenting] > ** [optional] Add support for > [https://github.com/kdave/btrfs-progs/issues/329 setting compression > level using `btrfs property`] > * Other developers: > ** anaconda: review PRs as needed > * Release engineering: https://pagure.io/releng/issue/9920 > * Policies and guidelines: N/A > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > This Change only applies to newly installed systems. Existing systems > on upgrade will be unaffected, but can be converted manually with > btrfs filesystem defrag -czstd -r, updating `/etc/fstab` > and remounting. > > == How to test == > > Existing systems can be converted to use compression manually with > btrfs filesystem defrag -czstd -r, updating `/etc/fstab` Update `/etc/fstab` how? Please be more explicit. > and remounting. > > == User experience == > > Compression will result in file sizes (e.g. as reported by du) not > matching the actual space occupied on disk. The > [https://src.fedoraproject.org/rpms/compsize compsize] utility can be > used to examine the compression type, effective compression ration and > actual size. > > == Dependencies == > > Anaconda will need to be updated to perform the installation using > mount -o compress=zstd:1 > > == Contingency plan == > > * Contingency mechanism: will not include PR patches if not merged > upstream and will not enable > * Contingency deadline: Final freeze > * Blocks release? No > * Blocks product? No > > == Documentation == > > https://btrfs.wiki.kernel.org/index.php/Compression > > == Release Notes == > > Transparent compression of the filesystem using zstd is now enabled by > default. Use the compsize utility to find out the actual size on disk > of a given file. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, Dec 30, 2020 at 10:08:31PM +0100, Javier Martinez Canillas wrote: > That's why I went with the conservative approach of only do this for > new installs, to prevent breaking users configuration (or even worse, > their booting). Maybe a middle ground could be to provide a tool for > users to do the switch and make it opt-in? This seems like a good approach to me. Documentation would have to remain doubled for a couple of releases, and then we could move to "if you've upgraded your system and not converted the config, here's how to do that now [link]" after that. However, if there's a chance the tool will break (and that chance is the only reason to not ... just do it), how hard will it be for people to recover? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, 2020-12-30 at 12:21 -0800, Adam Williamson wrote: > On Wed, 2020-12-30 at 14:53 -0500, Ben Cotton wrote: > > == Benefit to Fedora == > > > > This change will not only simplify and make less confusing the GRUB > > configuration but also allow the following improvements: > > > > * To have a consistent configuration across all the architectures > > using GRUB. > > * Allow the same installation to be booted with either EFI or > > legacy BIOS. > > * Use the same documentation and commands for all architectures > > instead of having EFI as a special case. > > * Make GRUB configuration tools more robust by not relying on > > symbolic > > links to be created and not having to handle platform specific > > cases. > > * Align with images generated by COSA and OSBuild on how the GRUB > > configuration files are used. > > * Align with other Linux distributions on how the GRUB > > configuration > > files are used. > There's discussion in emails and IRC this morning that have not made it back to this Change, these are some of them but apologies if I miss some: - right now putting /boot on btrfs (or xfs) works on EFI systems, since the GRUB config is on the EFI partition that Grub can write to. With this change, it's no longer an option unless /boot/grub2 is made a separate partition - for comparison, SUSE stores GRUB environment variables in the Btrfs header, but apart from having to maintain a patch, this would not help the goal of unifying the config, nor help those who want a single / xfs partition - a separate partition for storing GRUB config, no matter what architecture, is probably the ideal solution > But: > > > == Upgrade/compatibility impact == > > > > The changes will only be for new installations, existing systems > > will > > not be impacted and will continue using the grub.cfg and grubenv > > files > > that are located in the ESP. > > To me several of the benefits seem to not really be true, so long as > this is the plan for upgrades. > > * We wouldn't have a "consistent configuration" across everybody, > really, because anyone who upgraded from pre-F34 would still have the > old config; every bootloader debugging session ever would start by > figuring out which case this was. > > * We can't really use the same "documentation and commands" for the > same reason. We either have to document both possibilities forever, > or > accept that our docs will be incorrect for anyone who upgraded from > pre-F34. > > * We can't really make the tools "more robust" in the way cited > because > they'll still have to handle both cases as long as both cases exist. > If > anything this makes them more fragile: the more divergent paths a > tool > has to support, the more likely it is something will break. Igor was asking about migrating existing setups, and I think Javier plans to document that with the caveat that it might be flaky. But yeah, potentially having to support three configurations (BIOS only, EFI old style, EFI pointing to the new location), for me, means ideally we can agree on a mechanism that works everywhere, so that at least there's not another configuration change down the road. To bring the separate email thread back to this, now that the Change proposal is out -- I was initially going to bring up a related Change Proposal to make /boot on btrfs work consistently -- it is also predicated on grubenv being writable, which is currently true on EFI but not on BIOS systems. Depending on the final version of this proposal, I can retarget mine (that Javier kindly offered to help with, to help with any needed GRUB changes) for F35 to be about actually switching /boot to be on btrfs on Fedora solutions that are Btrfs-based -- on the same partition as / if LUKS is not used, and on a separate partition if it is, until we have native Btrfs encryption. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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
Any interest? ButterManager and grub-btrfs
Hi all! ngompa and I were talking to the upstream maintainer of the ButterManager backup tool about packaging for Fedora. Upstream is ready to collaborate on a RPM spec file if there is an interest in packaging for Fedora: https://twitter.com/eloygara/status/1344006727583330305 https://github.com/egara/buttermanager https://github.com/Antynea/grub-btrfs The maintainer is willing to work with someone on a package and possibly host it upstream: https://twitter.com/eloygara/status/1344309377101164546 There is interesting functionality for Btrfs snapshots here. The idea of being able to jump into any given system snapshot from the GRUB boot menu is appealing to me. :-) Neither Neal or I have time to pick these up as new packages, but I wanted to share the package on devel@ in case anyone were interested in bringing this to Fedora users now that Btrfs is the default filesystem. -- Cheers, Justin W. Flory (he/him) https://jwf.io TZ=Amer ica/New_York publickey - foss@jwf.io - 570e854f.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
Hello Adam, Thanks a lot for your feedback. On Wed, Dec 30, 2020 at 9:22 PM Adam Williamson wrote: > [snip] > > == Upgrade/compatibility impact == > > > > The changes will only be for new installations, existing systems will > > not be impacted and will continue using the grub.cfg and grubenv files > > that are located in the ESP. > > To me several of the benefits seem to not really be true, so long as > this is the plan for upgrades. > > * We wouldn't have a "consistent configuration" across everybody, > really, because anyone who upgraded from pre-F34 would still have the > old config; every bootloader debugging session ever would start by > figuring out which case this was. > > * We can't really use the same "documentation and commands" for the > same reason. We either have to document both possibilities forever, or > accept that our docs will be incorrect for anyone who upgraded from > pre-F34. > > * We can't really make the tools "more robust" in the way cited because > they'll still have to handle both cases as long as both cases exist. If > anything this makes them more fragile: the more divergent paths a tool > has to support, the more likely it is something will break. > -- These are all fair points. My worry is that trying to switch to the new configuration on upgrades could lead to issues for people that have custom GRUB configs. That was the case when we did the switch to using BLS snippets and I don't really want to repeat that experience for users. That's why I went with the conservative approach of only do this for new installs, to prevent breaking users configuration (or even worse, their booting). Maybe a middle ground could be to provide a tool for users to do the switch and make it opt-in? Another option is to stick with the status quo but then we will never be able to attempt improving this. Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, 2020-12-30 at 14:53 -0500, Ben Cotton wrote: > == Benefit to Fedora == > > This change will not only simplify and make less confusing the GRUB > configuration but also allow the following improvements: > > * To have a consistent configuration across all the architectures using GRUB. > * Allow the same installation to be booted with either EFI or legacy BIOS. > * Use the same documentation and commands for all architectures > instead of having EFI as a special case. > * Make GRUB configuration tools more robust by not relying on symbolic > links to be created and not having to handle platform specific cases. > * Align with images generated by COSA and OSBuild on how the GRUB > configuration files are used. > * Align with other Linux distributions on how the GRUB configuration > files are used. But: > == Upgrade/compatibility impact == > > The changes will only be for new installations, existing systems will > not be impacted and will continue using the grub.cfg and grubenv files > that are located in the ESP. To me several of the benefits seem to not really be true, so long as this is the plan for upgrades. * We wouldn't have a "consistent configuration" across everybody, really, because anyone who upgraded from pre-F34 would still have the old config; every bootloader debugging session ever would start by figuring out which case this was. * We can't really use the same "documentation and commands" for the same reason. We either have to document both possibilities forever, or accept that our docs will be incorrect for anyone who upgraded from pre-F34. * We can't really make the tools "more robust" in the way cited because they'll still have to handle both cases as long as both cases exist. If anything this makes them more fragile: the more divergent paths a tool has to support, the more likely it is something will break. -- 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
Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Deprecate_xemacs == Summary == Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw packages, all of which have dead upstreams. == Owner == * Name: [[User:jjames|Jerry James]] * Email: loganje...@gmail.com == Detailed Description == I have been part of XEmacs upstream for over 20 years, and have maintained the Fedora package for over 11 years. Upstream development had already slowed significantly when I became Fedora maintainer. The last release was over 7 years ago. Since that time, development has essentially come to a halt. Somebody will push a commit every now and then, but significant bugs are not being fixed. I see no future for the project. We should start moving towards dropping it from the distribution. The upstream sources have been spread across 3 packages in Fedora: xemacs, xemacs-packages-base, and xemacs-packages-extra. In addition, the xemacs package uses an ancient, unmaintained 3D X library: neXtaw. It's last release was in 2003. Since xemacs is the only package in Fedora that uses neXtaw, I propose that it also be deprecated so we can eventually drop it. Deprecation is warranted because there are about a dozen XEmacs add-on packages in Fedora. This will prevent us from adding any more as we work to retire the existing add-ons. == Feedback == On December 7, 2020, I [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VDETPULZDBMXBXJKEFZX7DQ5R6W6FBXT/ communicated my intent to file this Change] on fedora-devel-list. There has been no community feedback. == Benefit to Fedora == This Change will open a path for us to eventually remove unmaintained software from the distribution. == Scope == * Proposal owners: The only required work is the addition of `Provides: deprecated()` to the 4 affected packages. * Other developers: No immediate work is required. Eventually, maintainers of XEmacs add-on packages will need to retire those packages so that XEmacs itself can be retired. * Release engineering: This change does not require coordination with or impact release engineering and does not require a mass rebuild. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: While this proposal does not match any of the [https://docs.fedoraproject.org/en-US/project/objectives current objectives], it is not opposed to any. == Upgrade/compatibility impact == Since the Change only deprecates packages, it has no immediate effect on upgrades or compatibility. Eventually, when the affected packages are retired, fedora-obsolete-packages will be updated to properly manage upgrades. == How To Test == N/A (not a System Wide Change) == User Experience == This change will not lead to any immediate changes in user experience. Eventually, we will retire the affected packages, which will impact users of those packages. We will seek to communicate the upcoming retirement as we work towards it. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? None == Documentation == N/A (not a System Wide Change) == Release Notes == The xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw packages have been deprecated. XEmacs users should prepare for the eventual removal of these packages from the Fedora distribution. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: Xfce-4.16 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/xfce-4.16 == Summary == Xfce 4.16 is a stable release with proven components, provide features to both new and power users alike. This change proposal is submitted to sync fedora packages with the latest upstream release. == Owners == * Name: [[User:nonamedotc| Mukundan Ragavan]] * Email: nonamed...@fedoraproject.org * Name: [[User:kevin| Kevin Fenzi]] * Email: ke...@scrye.com == Detailed Description == This change migrates Xfce desktop environment (DE) to the latest version provided by upstream developers. This release brings, amongst others, the following features * client-side decorations * fractional scaling * new status tray plugins * Streamlined application chooser (i.e. merged "mime type editor" and "default applications") Full feature list can be viewed at [https://xfce.org/about/news Xfce news] == Benefit to Fedora == Updating Xfce to 4.16 will provide Fedora Xfce users stable but latest versions of upstream software. We will also be able to provide timely bug fixes. == Scope == * Proposal owners: ** Update core xfce packages to 4.16 ** Rebuild plugins once core packages are build * Other developers: N/A (not a System Wide Change) * Release engineering:
Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig == Summary == This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or `/boot` directory if no boot partition is used). == Owner == * Name: [[User:Javierm|Javier Martinez Canillas]] * Email: javi...@redhat.com * Name: [[User:Gicmo|Christian Kellner]] * Email: ckell...@redhat.com == Detailed Description == The GRUB configuration files layout on EFI platforms is not consistent with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le with Open Firmware). On platforms using EFI the GRUB configuration file (`grub.cfg`) and environment variables block (`grubenv`) are stored in the EFI System Partition (ESP) while for non-EFI platforms these are stored in the boot partition (or `/boot` directory if not boot partition is used). The reason for this is that the path where the GRUB bootloader searches for its configuration file varies depending on the firmware interface used. In most cases, GRUB searches for it in the path set in the `$prefix` variable. The device is not specified in that case, GRUB just searches for a configuration in this path for every detected device. But on EFI, a special `$fw_path` variable is used instead. This variable specifies both the device and path from where the GRUB bootloader was loaded and these are used to search for the configuration file. This is done for security reasons, to make sure that the correct GRUB configuration file is used and not just the first one found in one of the detected devices. Since the GRUB binary is located in the ESP, it expects to find the configuration file in that location as well. But this creates the mentioned inconsistency, because the GRUB configuration file has to be stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms it has to be stored in `/boot/grub2/grub.cfg`. This leads to a GRUB configuration layout that is confusing for users and error prone, since either the tools that are used to manage these files have to be aware of the differences or symbolic links used to hide the fact that the pats differ depending on the platform. Also, it creates artificial constraints on the OS installation due the differences in the configuration layout used. A system installed when using EFI won't be bootable if the firmware configuration is changed to boot using legacy BIOS instead, for example enabling the EFI Compatibility Support Module or moving the disk to a BIOS machine. The proposal is to always store the `grub.cfg` and `grubenv` files in the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg` to only be a small configuration file that sets a different `$prefix` variable and loads the configuration file stored in `/boot/grub2/grub.cfg`. The `$prefix` variable will be set to the device partition where `/boot/grub2/grub.cfg` is stored, using the partition filesystem's Universally Unique IDentifier (UUID). That way the correct GRUB configuration file will be loaded, making it as secure as the current approach where the configuration file in the ESP is used. A drawback of the new approach is that the GRUB configuration will now depend on the boot partition (or `/boot` directory if no boot partition is used). But since the kernel and initramfs images are stored there too, the bootloader configuration already has this dependency anyways. Note that the proposed configuration files layout is already used by the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this will make the systems installed with Anaconda to be consistent with the images generated by these. == Benefit to Fedora == This change will not only simplify and make less confusing the GRUB configuration but also allow the following improvements: * To have a consistent configuration across all the architectures using GRUB. * Allow the same installation to be booted with either EFI or legacy BIOS. * Use the same documentation and commands for all architectures instead of having EFI as a special case. * Make GRUB configuration tools more robust by not relying on symbolic links to be created and not having to handle platform specific cases. * Align with images generated by COSA and OSBuild on how the GRUB configuration files are used. * Align with other Linux distributions on how the GRUB configuration files are used. == Scope == * Proposal owners: ** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in `/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms. ** Make Anaconda to generate the minimal GRUB config file in the ESP that sets the `$prefix` variable and loads the configuration file located in `/boot/grub2/grub.cfg`. ** Modify the grub2 package scriptlets to not generate the `/boot/grub2/grubenv` and
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Summary == Currently all packages that are not opted out of LTO include -ffat-lto-objects in their build flags. This proposal would remove -ffat-lto-objects from the default LTO flags and only use it for packages that actually need it. == Owner == * Name: [[User:law | Jeff Law]] * Email: l...@redhat.com == Detailed Description == -ffat-lto-objects was added to the default LTO flags to ensure that any installed .o/.a files included actual compiled code rather than just LTO bytecodes (which are stripped after the install phase). However, that is wasteful from a compile-time standpoint as few packages actually install any .o/.a files. This proposal would remove -ffat-lto-objects from the default LTO flags and packages that actually need the option would have to opt-in via an RPM macro in their .spec file. This should significantly improve build times for most packages in Fedora. To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error. == Benefit to Fedora == The key benefit to Fedora is improved package build times and lower load on the builders. == Scope == * Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros. * Other developers: There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include: # Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in. # Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention. # It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems. I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) This should have no release engineering impacts. * Policies and guidelines: The packaging guidelines will need to be updated to document the new macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This proposal does not align with any current Fedora Objectives. == Upgrade/compatibility impact == This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts. == How To Test == No special testing is needed. Any issues with this proposal will show up as FTBFS issues. == User Experience == Users should see no changes to the user experience. == Dependencies == Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro. == Contingency Plan == If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35. * Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed * Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze. * Blocks release? No * Blocks product? No == Documentation == No upstream documentation. Packaging guidelines will need a minor update. == Release Notes == I do not expect this change to require any release notes. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: IBus 1.5.24 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IBus_1.5.24 == Summary == IBus will use the mmap(2) feature to show emoji and Unicode tables in order to reduce the physical memory usage. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == Currently IBus disables the emoji and Unicode features in some system users likes gdm, liveuser, gnome-initial-setup not to exhaust the limited memory usage with LiveDVD. The emoji data requires about 10MB and the Unicode data requires about 15MB and the total 25MB is required roughly to show the tables. The Fedora testers ask to test the emoji feature and Unicode feature in LiveDVD and the next IBus will use mmap to be available the emoji and Unicode data with liveuser. == Feedback == Fedora I18N testers asks to test the emoji and Unicode data without installing Fedora to disc. == Scope == * Proposal owners: * Other developers: N/A * Release engineering: (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == About 25MB free disc space will be needed. == How To Test == # Run Fedora LiveDVD and log into the Fedora desktop # Run `gnome-control-center region` and add both XKB and input method sources. E.g. "English (US)" and "Hangul" # Enable an XKB source with mouse or Super-space shortcut key. E.g. "English (US)" # Type Ctrl-Shift-e, "smile", space, and Enter key. U+1F603 is output. == User Experience == The physical memory usage will be reduced. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the change to IBus. * Contingency deadline: Beta release * Blocks release? No * Blocks product? None == Documentation == TBD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression == Summary == On variants using btrfs as the default filesystem, enable transparent compression using zstd. Compression saves space and can significantly increase the lifespan of flash-based media by reducing write amplification. It can also increase read and write performance. == Owners == * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide Cavalca]], [[User:josef|Josef Bacik]] * Email: mic...@michel-slm.name, dcava...@fb.com, jo...@toxicpanda.com == Detailed description == Transparent compression is a btrfs feature that allows a btrfs filesystem to apply compression on a per-file basis. Of the three supported algorithms, zstd is the one with the best compression speed and ratio. Enabling compression saves space, but it also reduces write amplification, which is important for SSDs. Depending on the workload and the hardware, compression can also result in an increase in read and write performance. See https://pagure.io/fedora-btrfs/project/issue/5 for details. This was originally scoped as an optimization for https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora 33. == Benefit to Fedora == Better disk space usage, reduction of write amplification, which in turn helps increase lifespan and performance on SSDs and other flash-based media. It can also increase read and write performance. == Scope == * Proposal owners: ** Update anaconda to perform the installation using mount -o compress=zstd:1 ** Set the proper option in fstab (alternatively: set the XATTR) ** Update disk image build tools to enable compression: *** lorax *** appliance-tools *** osbuild *** imagefactory ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/328 setting compression level when defragmenting] ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/329 setting compression level using `btrfs property`] * Other developers: ** anaconda: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9920 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == This Change only applies to newly installed systems. Existing systems on upgrade will be unaffected, but can be converted manually with btrfs filesystem defrag -czstd -r, updating `/etc/fstab` and remounting. == How to test == Existing systems can be converted to use compression manually with btrfs filesystem defrag -czstd -r, updating `/etc/fstab` and remounting. == User experience == Compression will result in file sizes (e.g. as reported by du) not matching the actual space occupied on disk. The [https://src.fedoraproject.org/rpms/compsize compsize] utility can be used to examine the compression type, effective compression ration and actual size. == Dependencies == Anaconda will need to be updated to perform the installation using mount -o compress=zstd:1 == Contingency plan == * Contingency mechanism: will not include PR patches if not merged upstream and will not enable * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == https://btrfs.wiki.kernel.org/index.php/Compression == Release Notes == Transparent compression of the filesystem using zstd is now enabled by default. Use the compsize utility to find out the actual size on disk of a given file. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On Mon, 2020-11-30 at 00:31 +0100, Dan Čermák wrote: > "Wim Taymans" writes: > > * propose permanent switch for f35 > > - it gets at least full cycle of testing (f34 + part of f33) > > * re-evaluate situation for f35 beta freeze to make a default > > switch. > > > > Although a bit slower than expected, I guess more testing is good. > > It sounds > > like an acceptable plan to me. > > I'm not sure how it works, if spinoffs can/want to make an earlier > > switch? > > Hm, I don't see a technical reason why a certain edition of Fedora > couldn't ship with PipeWire by default earlier. Albeit I don't think > that jumping ahead of the rest of the distro would reflect very well > on > the project, unless you call it "Fedora PipeWire Edition". > It will be a spin in this case (Jam), not an edition, right? (And editions sometimes do differ in what features they ship, e.g. Workstation defaulted to btrfs in F33 but Server had not. If the benefits for pro audio users outweigh any issues that cause the default to be reverted to Pulseaudio, I can see it being valuable to Jam to stick to Pipewire anyway while the balance goes the other way around for non-pro users who don't use JACK. Cheers, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Wed, Dec 30, 2020 at 01:18:38PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Dec 22, 2020 at 05:09:08PM -0500, Matthew Miller wrote: > > On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote: > > > > delta rpms safe so much time in form of bandwidth on the client side. > > > Well, it's tradeoffs. They save bandwith and download time on one side, > > > but use lots of cpu cycles and disk space on the other. It just depends > > > on what each person wants based on their situation and hardware. > > > > They actually use a lot of cpu cycles on _both_ sides, really. > > I thought that zchunk would obsolete drpm. What's the story here? Nope, they are different things. zchunk = a way to only download changed chunks of repodata. drpms = a way to only download changed chunks of rpms. > Also, in recent times, any dnf upgrade I did reported "savings" from > drpm on the level <1% [*]. Am I doing something wrong or is this expected? > Is there some usage pattern where there drpm provides real gain with > current Fedora? This is most likely because we are only making drpms against the most recent updates. So, we are making very few drpms and only against things that recently updated. For example: https://dl.fedoraproject.org/pub/fedora/linux/updates/33/Everything/x86_64/drpms/ (126 drpms for all of f33 updates). > Maybe the time has come to just disable DRPM entirely for F34. We could. Or try and make them more usefull again. 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 2020-12-29 at 18:54 +, Gary Buhrmaster wrote: > On Tue, Dec 15, 2020 at 11:45 PM Adam Williamson > wrote: > > > I wrote in the update that in my opinion the solution for this bug > > can't involve expecting add-ons to suddenly get re-signed en masse, or > > users to change their local configuration. It needs to keep working as > > it did before. If the policy is ahead of the real world, the policy > > needs to be loosened. > > It was my (possibly failing) recollection that Mozilla > has been signing add-ons with SHA2 (and SHA1 > for compatibility) for a few years now. Is this just > an issue because Mozilla has not re-signed existing > add-ons (which while is obviously not something to > be taken lightly, because they do control the primary > distribution point(*) should be at least theoretically > possible to do a bulk re-signing, and probably a > good thing to do to avoid needing to downgrade > their security stance), or is Mozilla not signing > with SHA2 as I thought? Well, installing uBlock Origin (which is a pretty frequently updated addon) on a fresh VM fails, with the change. So I suspect it's the latter. -- 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
Re: Stale proven packagers
On Sun, Dec 27, 2020 at 7:38 PM Kevin Fenzi wrote: > You can add more than one. Just put them in a file and upload all of > them for 'ssh key' one key per line. There's a limit based on > applications getting the ssh keys, but you can upload multiple keys > fine. Oh, ok! Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Syngrafias - AsciiDocs Collaboration Tool for Fedora Documentation Maintainers, Available for testing
On Tue, Dec 29, 2020 at 04:01:26PM +0500, Nasir Hussain wrote: > We would love to hear your feedback. Please keep in mind that this is a > testing deployment and is currently running on an underpowered cloud > instance. We are proposing it as a candidate GSoC project for it to be > deployed, maintained and integrated in the Fedora Infrastructure this > summer. Also the deployment goes offline on 8th January so be sure to > check it out soon. This is super, super cool! One suggestion I have is to start in the simpler "Unity" mode rather than the "Cellular" one by default. Also, in the Cellular one, provide a button or something to add a new cell rather than requiring the menu item -- it took me an embarrassingly long time to figure out how to start typing. As an end-state goal, I'd love to so anyone clicking "edit" on a page on the docs site got this editor! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Syngrafias - AsciiDocs Collaboration Tool for Fedora Documentation Maintainers, Available for testing
Hey Benson, Thank you so much for taking some time out to check the public preview. > Nice. Consider using a > temporary domain name for this. For example from > Freenom. We are considering a domain name for it and would surely keep you posted, should we obtain one. > Are there any similar tools in other languages (Go, Rust, Crystal)? > Python runtime includes heavy batteries, so not great for underpowered > instances, though useful for rapid development. There are libraries for websockets in Go but with much divisive community support for each. When it comes to Python, we are using the excellent websockets library created by @aaugustin. (But yes, we are keeping our eyes on a Go rewrite down-the-line for speedup and efficiency should the Python implementation feel heavy) > A link to an Asciidoc cheatsheet maybe a good > tip to have. Examples include: > https://powerman.name/doc/asciidoc > https://www.writethedocs.org/guide/writing/asciidoc/ > One could also create one, but the tips and documentation section seems > not to be currently available at > https://github.com/t0xic0der/syngrafias We do have general usability documentation as a part of the help and support topics which was introduced as of https://github.com/t0xic0der/syngrafias/pull/88 but adding an Asciidoc cheatsheet sound like an awesome idea. I have filed a feature request ticket here at https://github.com/t0xic0der/syngrafias/issues/91 which you can track for your reference and this would be prioritized. Thank you for taking your time out to review the public preview and suggesting the changes. Wish you a very happy 2021! :D Regards, Akashdeep Dhar t0xic0der ___ 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
Fedora-Rawhide-20201230.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 11/180 (x86_64), 7/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201229.n.0): ID: 748439 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/748439 ID: 748442 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/748442 ID: 748506 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/748506 ID: 748708 Test: aarch64 universal install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/748708 ID: 748748 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/748748 ID: 748750 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/748750 Old failures (same test failed in Fedora-Rawhide-20201229.n.0): ID: 748489 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/748489 ID: 748490 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/748490 ID: 748497 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/748497 ID: 748507 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/748507 ID: 748516 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/748516 ID: 748518 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/748518 ID: 748530 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/748530 ID: 748670 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/748670 ID: 748697 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/748697 ID: 748724 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/748724 ID: 748729 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/748729 ID: 748733 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/748733 Soft failed openQA tests: 20/180 (x86_64), 15/122 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20201229.n.0): ID: 748495 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/748495 Old soft failures (same test soft failed in Fedora-Rawhide-20201229.n.0): ID: 748436 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/748436 ID: 748437 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/748437 ID: 748444 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/748444 ID: 748448 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/748448 ID: 748452 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/748452 ID: 748453 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/748453 ID: 748466 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/748466 ID: 748475 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/748475 ID: 748538 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/748538 ID: 748547 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/748547 ID: 748548 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/748548 ID: 748556 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/748556 ID: 748567 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/748567 ID: 748573 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/748573 ID: 748587 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/748587 ID: 748591 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/748591 ID: 748614 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL:
Orphaning python-orderedset and auto-destdir
I maintain packages that used to BR the packages in $SUBJECT, but with their latest versions no longer do. I'm orphaning these packages. If you need them, please pick them up. -- Jerry James http://www.jamezone.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
[Bug 1911158] perl-Mojolicious-8.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1911158 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Mojolicious-8.69 is|perl-Mojolicious-8.70 is |available |available --- Comment #2 from Upstream Release Monitoring --- Latest upstream release: 8.70 Current version/release in rawhide: 8.67-1.fc34 URL: https://metacpan.org/release/Mojolicious Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5966/ -- 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
Fedora-IoT-34-20201230.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 1/16 (x86_64), 5/15 (aarch64) ID: 748758 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/748758 ID: 748767 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/748767 ID: 748769 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/748769 ID: 748770 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/748770 ID: 748772 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/748772 ID: 748776 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/748776 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 748751 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/748751 Passed openQA tests: 14/16 (x86_64), 10/15 (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
Fedora rawhide compose report: 20201230.n.0 changes
OLD: Fedora-Rawhide-20201229.n.0 NEW: Fedora-Rawhide-20201230.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 2 Dropped packages:0 Upgraded packages: 102 Downgraded packages: 0 Size of added packages: 1.93 MiB Size of dropped packages:0 B Size of upgraded packages: 2.84 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -20.85 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: ansible-collection-community-general-1.3.1-1.fc34 Summary: Modules and plugins supported by Ansible community RPMs:ansible-collection-community-general Size:1.65 MiB Package: ansible-collection-google-cloud-1.0.1-1.fc34 Summary: Google Cloud Platform collection RPMs:ansible-collection-google-cloud Size:276.98 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: R-git2r-0.27.1-4.fc34 Old package: R-git2r-0.27.1-3.fc33 Summary: Provides Access to Git Repositories RPMs: R-git2r Size: 2.16 MiB Size change: -2.57 KiB Changelog: * Mon Dec 28 2020 Igor Raits - 0.27.1-4 - Rebuild for libgit2 1.1.x Package: aeskeyfind-1.0-9.fc34 Old package: aeskeyfind-1.0-9.fc33 Summary: Locate 128-bit and 256-bit AES keys in a captured memory image RPMs: aeskeyfind Size: 92.41 KiB Size change: -26 B Package: alglib-3.17.0-1.fc34 Old package: alglib-3.16.0-3.fc33 Summary: A numerical analysis and data processing library RPMs: alglib alglib-devel alglib-doc Size: 9.17 MiB Size change: 297.27 KiB Changelog: * Tue Dec 29 2020 Sandro Mani - 3.17.0-1 - Update to 3.17.0 Package: amsynth-1.12.2-1.fc34 Old package: amsynth-1.12.1-1.fc34 Summary: A classic synthesizer with dual oscillators RPMs: amsynth amsynth-data dssi-amsynth-plugin lv2-amsynth-plugin vst-amsynth-plugin Size: 3.71 MiB Size change: -3.32 KiB Changelog: * Tue Dec 29 2020 Guido Aulisi - 1.12.2-1 - Update to 1.12.2 - Fix #1911367 Package: ansible-collection-ansible-netcommon-1.4.1-1.fc34 Old package: ansible-collection-ansible-netcommon-1.1.2-1.fc33 Summary: Ansible Network Collection for Common Code RPMs: ansible-collection-ansible-netcommon Size: 187.46 KiB Size change: 21.71 KiB Changelog: * Tue Dec 29 2020 Igor Raits - 1.4.1-1 - Update to 1.4.1 Package: ansible-collection-ansible-posix-1.1.1-1.fc34 Old package: ansible-collection-ansible-posix-1.1.0-1.fc34 Summary: Ansible Collection targeting POSIX and POSIX-ish platforms RPMs: ansible-collection-ansible-posix Size: 117.59 KiB Size change: 232 B Changelog: * Tue Dec 29 2020 Igor Raits - 1.1.1-1 - Update to 1.1.1 Package: ansible-collection-community-kubernetes-1.1.1-2.fc34 Old package: ansible-collection-community-kubernetes-1.0.0-1.fc34 Summary: Kubernetes Collection for Ansible RPMs: ansible-collection-community-kubernetes Size: 95.41 KiB Size change: 17.89 KiB Changelog: * Tue Dec 29 2020 Igor Raits - 1.1.1-1 - Update to 1.1.1 * Tue Dec 29 2020 Igor Raits - 1.1.1-2 - Drop unneeded dependency Package: ansible-collection-netbox-netbox-1.2.0-1.fc34 Old package: ansible-collection-netbox-netbox-0.3.1-1.fc33 Summary: Netbox modules for Ansible RPMs: ansible-collection-netbox-netbox Size: 214.81 KiB Size change: 76.57 KiB Changelog: * Tue Dec 29 2020 Igor Raits - 1.2.0-1 - Update to 1.2.0 Package: awscli-1.18.204-1.fc34 Old package: awscli-1.18.203-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.95 MiB Size change: 57 B Changelog: * Tue Dec 29 2020 Gwyn Ciesla - 1.18.204-1 - 1.18.204 Package: bitmap-fonts-0.3-36.fc34 Old package: bitmap-fonts-0.3-34.fc33 Summary: Selected set of bitmap fonts RPMs: bitmap-console-fonts bitmap-console-opentype-fonts bitmap-fangsongti-fonts bitmap-fangsongti-opentype-fonts bitmap-fixed-fonts bitmap-fixed-opentype-fonts bitmap-fonts-compat bitmap-lucida-typewriter-fonts bitmap-lucida-typewriter-opentype-fonts bitmap-opentype-fonts-compat Size: 1.51 MiB Size change: 8.76 KiB Changelog: * Fri Sep 04 2020 Peng Wu - 0.3-35 - Use BDF fonts for OpenType conversion * Tue Dec 29 2020 Peng Wu - 0.3-36 - Rebuilt with fonttosfnt 1.2.1 Package: calligra-3.2.1-6.fc34 Old package: calligra-3.2.1-5.fc34 Summary: An integrated office suite RPMs: calligra calligra-core calligra-karbon calligra-karbon-libs calligra-l10n calligra-libs calligra-okular-odpgenerator calligra-okular-odtgenerator calligra-sheets calligra-sheets-libs calligra-stage calligra-stage-libs calligra-words calligra-words-libs Size: 167.42 MiB Size change: -504.89 KiB Changelog: * Mon Dec 28 2020 Igor Raits - 3.2.1-6 - Rebuild for libgit2 1.1
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 05:09:08PM -0500, Matthew Miller wrote: > On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote: > > > delta rpms safe so much time in form of bandwidth on the client side. > > Well, it's tradeoffs. They save bandwith and download time on one side, > > but use lots of cpu cycles and disk space on the other. It just depends > > on what each person wants based on their situation and hardware. > > They actually use a lot of cpu cycles on _both_ sides, really. I thought that zchunk would obsolete drpm. What's the story here? Also, in recent times, any dnf upgrade I did reported "savings" from drpm on the level <1% [*]. Am I doing something wrong or is this expected? Is there some usage pattern where there drpm provides real gain with current Fedora? Maybe the time has come to just disable DRPM entirely for F34. Zbyszek [*] Today on F33: > Delta RPMs reduced 836.8 MB of updates to 836.7 MB (0.1% saved) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Il 30/12/20 10:14, Marius Schwarz ha scritto: > > Don't you need to recompile stuff first to have an effect? :) > > I've just pushed a rebuild for qt5-qtwebengine, let's see if that's enough. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 29/12/2020 01:41, Luya Tshimbalanga wrote: I was trying it with Bose QC35 headphones. It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to. Maybe an extra step is required for that Bose QC35. Try to forget that device and reconnect. That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required? I haven't needed to put "-e bluez5" as Galaxy Buds+ worked without extra configuration on a first try. I had another play with it and I can confirm that I now have bluetooth working - it does work out of the box but has a habit of switching back to the on board sound for new audio streams unless you add that "-e bluez5" argument. What doesn't work at all, and this is likely what was causing my problems before, is fast user switching. That doesn't work with traditional pulseaudio for bluetooth but you can work around that by disabling the bluetooth modules in .config/pulse/default.pa for all bar one user if you are happy only using bluetooth for a single user. With pipewire not only does it not work for bluetooth, it doesn't work for the on board sound either - you have to stop the pipewire service for one user before switching to the other one or it can't use the sound card as the other instance still has it open. I did try and use the (not shipped in Fedora) system service units for pipewire but I couldn't get them to work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd v247-rc2 (app.slice, oomd, udev rule changes, light deps)
On Tue, Nov 24, 2020 at 05:26:15PM +0100, p...@barkhof.uni-bremen.de wrote: > Hi, > > is there hope that this selinux update will make system-container usable in > Fedora again? > > ( see e.g. > https://bugzilla.redhat.com/show_bug.cgi?id=1900869 > https://bugzilla.redhat.com/show_bug.cgi?id=1900888 ) As far as I know, no :( Those two bugs would need a separate patch for selinux policy unrelated to the issues I was seeing. Zbyszek > > Am 12.11.2020 um 15:15 schrieb Zbigniew Jędrzejewski-Szmek > > : > > > > Hi, > > > > we're getting ready to push systemd 247-rc2 to rawhide. This is > > currently blocked by selinux (see below), but I wanted to give a heads-up. > > There's a number of changes which are interesting for Fedora: ___ 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
Fedora-Cloud-32-20201230.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 748428 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/748428 ID: 748435 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/748435 Passed openQA tests: 6/7 (x86_64), 6/7 (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
Re: Chromium built in rawhide does not render most strings
Am 30.12.20 um 04:53 schrieb Jeff Law: To be clear (and I know you know this, but your readers might not know), QtWebEngine (qt5-qtwebengine) and Chromium (chromium) are distinct packages (none of them depends on each other), each containing a slightly different copy of essentially the same source code (plus some higher-layer code that is entirely different: Qt wrapper libraries vs. a browser application). But since the source code is largely the same, things such as miscompilations by the compiler are likely to affect both the same way. And the symptoms in the 2 screenshots definitely look identical. I think this has been fixed with the latest gcc drop into rawhide. jeff Don't you need to recompile stuff first to have an effect? :) Best regards, Marius ___ 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
