[Bug 2126978] New: perl-Regexp-Grammars-1.058 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2126978 Bug ID: 2126978 Summary: perl-Regexp-Grammars-1.058 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Regexp-Grammars Keywords: FutureFeature, Triaged Assignee: wf...@worldbroken.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, wf...@worldbroken.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.058 Upstream release that is considered latest: 1.058 Current version/release in rawhide: 1.057-9.fc37 URL: http://search.cpan.org/dist/Regexp-Grammars/ 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/3295/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Regexp-Grammars -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126978 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 2022-09-14 07:01, Miro Hrončok wrote: Hello folks! luya dlib dlib @bizdelnick @luya ASSIGNED https://bugzilla.redhat.com/2098694 Bundles old pybind11 which is not Python 3.11 compatible, needs to be unbundled or at least updated. Upstream is waiting for the stable release of Python 3.11 to do the change. As for unbundling, could someone from Python team propose a suggestion for testing please? Thank you. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following builds have been pushed to Fedora EPEL 7 updates-testing
coturn-4.6.0-1.el7
libmd-1.0.4-2.el7
Details about builds:
coturn-4.6.0-1.el7 (FEDORA-EPEL-2022-cb40cdd267)
TURN/STUN & ICE Server
Update Information:
# Coturn 4.6.0* Fix small issues reported by `cppcheck` * Fix long log
line printing * Print `turnserver` version with `--version` * Do not write
outside of a buffer in admin interface * Fix uclient certificate loading bug
* Fix duplicate TCP flag in `run_tests.sh` script* Fix turn session leak *
Document dependency of new-log-timestamp-format on new-log-timestamp * Enable
compilation of coturn on Solaris 11.4 * First step to re-enable compilation
with OpenSSL 1.0.x * Fix cmake build on macOS * Disable SSL renegotiation
* Fix user quota release * Add more info to redis allocation status * Update
`turnserver.conf` comment * Fix performance regression * Add syslog facility
config * Add support for dual-stack prom listener * fix build with LibreSSL
3.4.0+ * Add CI tests workflow * Show error on invalid config * Add new
prom allocations metric * Don't link in libintl * Fix access to freed memory
* Configurable prom username labels * Configurable prometheus listener port
* Fix build MariaDB connector * Fix `README` typo * Correct doc typo * Fix
`sqlite3_shutdown` and `sqlite3_config` race * Prom server better * Define
`OPENSSL_VERSION_1_1_1` on systems where it doesn't (yet) exist * Regression
in 4.5.2 that cause issues in OpenSSL version < 1.1.1 * Typo fix in prometheus
* Add hash algorithm for hmackey value to redis userdb schema docs * Replace
`keep-address-family` with `allocation-default-address-family` (`keep-address-
family` is deprecated and will be removed) * Restore `no_stdout_log` behavior
* Support older MySQL client version in `configure` * Add to support cmake *
Fix typo in `turnserver.conf` * Packaging scripts can miss out on these errors
(exit code) * `Readme.turnserver`: how to run server as a daemon * SSL
reload has hidden bugs which cause crashes * Try to mitigate STUN
amplification attack * Add new option `--no-rfc5780` to force disable
RFC8750 * Add new option `--no-stun-backward-compatibility` Disable
handling old STUN binding requests and disable `MAPPED-ADDRESS` attribute in
binding response (use only the `XOR-MAPPED-ADDRESS`) * Add new option
`--response-origin-only-with-rfc5780` Add `RESPONSE_ORIGIN` attribute only
if RFC8750 is enabled * Don't send `SOFTWARE` attribute if `--no-software-
attribute set on` (breaking change) * Fix for `log_binding` (regression)
ChangeLog:
* Wed Sep 14 2022 Robert Scheck - 4.6.0-1
- Upgrade to 4.6.0 (#2126875)
* Wed Jul 20 2022 Fedora Release Engineering -
4.5.2-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
References:
[ 1 ] Bug #2126875 - coturn-4.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2126875
libmd-1.0.4-2.el7 (FEDORA-EPEL-2022-527b1fd790)
Library that provides message digest functions from BSD systems
Update Information:
The libmd library provides a few message digest ("hash") functions, as found on
various BSD systems, either on their libc or on a library with the same name,
and with a compatible API.
ChangeLog:
* Wed Sep 14 2022 Robert Scheck 1.0.4-2
- Update license identifier to SPDX expression (#2094582 #c11)
* Wed Jun 8 2022 Robert Scheck 1.0.4-1
- Upgrade to 1.0.4 (#2094582)
- Initial spec file for Fedora and Red Hat Enterprise Linux
References:
[ 1 ] Bug #2094582 - Review Request: libmd - Library that provides message
digest functions from BSD systems
https://bugzilla.redhat.com/show_bug.cgi?id=2094582
___
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:
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing:
Age URL
57 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-89ad385971
chromium-103.0.5060.114-1.el8
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cd091ab1b1
libconfuse-3.3-7.el8
1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9d8794e452
ImageMagick-6.9.12.63-1.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
coturn-4.6.0-1.el8
java-latest-openjdk-18.0.2.0.9-1.rolling.el8
kiwi-9.24.48-1.el8
kiwi-boxed-plugin-0.2.23-1.el8
libmd-1.0.4-2.el8
netplan-0.105-2.el8
zbar-0.23.90-5.el8
Details about builds:
coturn-4.6.0-1.el8 (FEDORA-EPEL-2022-e1f1abea12)
TURN/STUN & ICE Server
Update Information:
# Coturn 4.6.0* Fix small issues reported by `cppcheck` * Fix long log
line printing * Print `turnserver` version with `--version` * Do not write
outside of a buffer in admin interface * Fix uclient certificate loading bug
* Fix duplicate TCP flag in `run_tests.sh` script* Fix turn session leak *
Document dependency of new-log-timestamp-format on new-log-timestamp * Enable
compilation of coturn on Solaris 11.4 * First step to re-enable compilation
with OpenSSL 1.0.x * Fix cmake build on macOS * Disable SSL renegotiation
* Fix user quota release * Add more info to redis allocation status * Update
`turnserver.conf` comment * Fix performance regression * Add syslog facility
config * Add support for dual-stack prom listener * fix build with LibreSSL
3.4.0+ * Add CI tests workflow * Show error on invalid config * Add new
prom allocations metric * Don't link in libintl * Fix access to freed memory
* Configurable prom username labels * Configurable prometheus listener port
* Fix build MariaDB connector * Fix `README` typo * Correct doc typo * Fix
`sqlite3_shutdown` and `sqlite3_config` race * Prom server better * Define
`OPENSSL_VERSION_1_1_1` on systems where it doesn't (yet) exist * Regression
in 4.5.2 that cause issues in OpenSSL version < 1.1.1 * Typo fix in prometheus
* Add hash algorithm for hmackey value to redis userdb schema docs * Replace
`keep-address-family` with `allocation-default-address-family` (`keep-address-
family` is deprecated and will be removed) * Restore `no_stdout_log` behavior
* Support older MySQL client version in `configure` * Add to support cmake *
Fix typo in `turnserver.conf` * Packaging scripts can miss out on these errors
(exit code) * `Readme.turnserver`: how to run server as a daemon * SSL
reload has hidden bugs which cause crashes * Try to mitigate STUN
amplification attack * Add new option `--no-rfc5780` to force disable
RFC8750 * Add new option `--no-stun-backward-compatibility` Disable
handling old STUN binding requests and disable `MAPPED-ADDRESS` attribute in
binding response (use only the `XOR-MAPPED-ADDRESS`) * Add new option
`--response-origin-only-with-rfc5780` Add `RESPONSE_ORIGIN` attribute only
if RFC8750 is enabled * Don't send `SOFTWARE` attribute if `--no-software-
attribute set on` (breaking change) * Fix for `log_binding` (regression)
ChangeLog:
* Wed Sep 14 2022 Robert Scheck - 4.6.0-1
- Upgrade to 4.6.0 (#2126875)
* Wed Jul 20 2022 Fedora Release Engineering -
4.5.2-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
References:
[ 1 ] Bug #2126875 - coturn-4.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2126875
java-latest-openjdk-18.0.2.0.9-1.rolling.el8 (FEDORA-EPEL-2022-73672e02b0)
OpenJDK 18 Runtime Environment
Update Information:
July CPU update
ChangeLog:
* Fri Jul 22 2022 Andrew Hughes - 1:18.0.2.0.9-1.rolling
- Update to jdk-18.0.2 release
- Update release notes to 18.0.2
- Drop JDK-8282004 patch which is now upstreamed under JDK-8282231
- Exclude x86 where java_arches is undefined, in order to unbreak build
* Fri Jul 22 2022 Jiri Vanek - 1:18.0.1.1.2-8.rolling
- moved to build only on %{java_arches}
-- https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
- reverted :
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild (always
mess up release)
-- Try to build on x86 again by creating a husk of a JDK which does not depend
on itself
-- Exclude x86 from builds as the bootstrap
[Bug 2126661] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126661 --- Comment #4 from Fedora Update System --- FEDORA-2022-95366a795e has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-95366a795e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-95366a795e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2124507] Please branch and build perl-X11-Protocol in epel9.
https://bugzilla.redhat.com/show_bug.cgi?id=2124507 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-X11-Protocol-0.56-42.e ||l9 Resolution|--- |ERRATA Last Closed||2022-09-15 02:34:50 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-1398a379b4 has been pushed to the Fedora EPEL 9 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. https://bugzilla.redhat.com/show_bug.cgi?id=2124507 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2124508] Please branch and build perl-X11-Protocol-Other in epel9.
https://bugzilla.redhat.com/show_bug.cgi?id=2124508 Bug 2124508 depends on bug 2124507, which changed state. Bug 2124507 Summary: Please branch and build perl-X11-Protocol in epel9. https://bugzilla.redhat.com/show_bug.cgi?id=2124507 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124508 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126677] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126677 --- Comment #2 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7f390fcbe8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126677 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2124508] Please branch and build perl-X11-Protocol-Other in epel9.
https://bugzilla.redhat.com/show_bug.cgi?id=2124508 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-X11-Protocol-Other-31- ||12.el9 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-09-15 02:34:53 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-1398a379b4 has been pushed to the Fedora EPEL 9 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. https://bugzilla.redhat.com/show_bug.cgi?id=2124508 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126661] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126661 --- Comment #3 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7f390fcbe8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126679] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126679 --- Comment #2 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7f390fcbe8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126679 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126682] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126682 --- Comment #2 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7f390fcbe8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126682 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2124460] Pleadse branch and build perl-Crypt-SSLeay in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2124460 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Crypt-SSLeay-0.72-37.e ||l9 Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2022-09-15 02:34:48 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-405547d3d8 has been pushed to the Fedora EPEL 9 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. https://bugzilla.redhat.com/show_bug.cgi?id=2124460 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 14. 09. 22 16:01, Miro Hrončok wrote: Hello folks! ... Will be retired one week before the freeze anyway barbecue it's an old NEW. I don't always spell "because" as "barbecue". But when I do I copy-paste it to the email 8 times 臘 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 14. 09. 22 16:01, Miro Hrončok wrote: Hello folks! ... Will be retired one week before the freeze anyway barbecue it's an old NEW. I don't always spell "because" as "barbecue". But when I do I copy-paste it to the email 8 times 臘 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libFLAC soname bump
Hi Miroslav, On Mon, Sep 12, 2022 at 04:36:47PM +0200, Miroslav Lichvar wrote: > flac-1.4.0 changes the libFLAC and libFLAC++ sonames. There are also > some incompatible changes in the API, but I didn't see any packages > failing to built due to these changes. > > The following packages need to be rebuilt: > > I tried to rebuild them all except chromium which I suspect would take > too much space and time. Only ardour6, audacity, and xmms2 failed, for > unrelated reasons. > All the packages on your list except the 4 you listed in the paragraph above should be built now, please check if anything is missing: https://koji.fedoraproject.org/koji/builds?inherited=0=58420=-build_id=1 Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, 2022-09-14 at 15:49 -0700, Adam Williamson wrote: > The hardcore way is to say "welp, too bad, your account's gone, > create > a new one and start over, including going through the maintainer > process again", but that might be a bit *too* hardcore. > > This is a perennial issue, though, and the weakest point of the whole > FIDO2 concept overall, including in the way it's being promoted to a > mass audience as password-less auth for everything. The official > story > is you should also enrol a backup phone or tablet or something that > you > keep at home, then if you lose your main phone, you can get into the > system with the backup device, enrol a new main device, and unenrol > the > lost/stolen main device. > > But if you *aren't* rich enough to have spare phones/tablets lying > around the place, or you just manage to lose both, the story is > basically "you go into an Apple store or call up Google or Samsung > etc. > and somehow convince them you are you and they will then auth a new > device onto your account". So, awkward squishy human processes again. To follow up on some of these points, IIRC the weakest chain in the link is alternate factors (SMS is strictly inferior to TOTP for example) and social engineering (poorly trained tech support or they just don't care). A sufficiently advanced attacker may not even have to take over an account to create a legitimate looking phishing e-mail or phone call. There's been recent stories of hackers having insider knowledge that would normally be difficult to obtain for less sophisticated attackers. I think the first step would be to create a threat model and then go from there, incorporating all of the points brought up in this thread. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, 2022-09-14 at 18:35 -0400, Simo Sorce wrote: > On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote: > > On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote: > > > > > > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen > > > wrote: > > > > I'm not entirely convinced. See this paper: > > > > https://eprint.iacr.org/2020/1298.pdf > > > > > > I only read the abstract of this paper, but looks like the researchers > > > have found that FIDO is indeed unphishable. Seems their attack relies > > > on websites allowing downgrade to weaker forms of 2FA. > > > > Yup. The thrust of the paper is: in the real world FIDO2 is usually > > deployed alongside older/weaker forms of 2FA, so an attacker can > > pretend to the victim that FIDO auth didn't work and convince them to > > try a weaker method instead, then phish that. > > > > Which is a reasonable point, but not necessarily relevant to us. We > > *could* require only strong auth and not have weaker fallback methods. > > So I have been thinking about this, how do you deal with the inevitable > fact that keys get lost or stop working if there is no alternative > authentication method? > > I guess people can enroll 2 separate keys (if Feodra Infra will allow > that), but not everyone has the means to do that. Same way you deal with people losing their passwords or current 2FA tokens: slowly and awkwardly. Basically, have a human deal with it, and establish as best they can that the person claiming they lost their tokens really is the person who ought to have them. Of course, if you do issue new tokens, send an alert about this to all known contact methods for the account, so if it *was* an Evil Person doing it, and the Evil Person hasn't also compromised all of those contact methods too, the Real Packager will know something funky has happened and - hopefully - reach out and get the account frozen again. The hardcore way is to say "welp, too bad, your account's gone, create a new one and start over, including going through the maintainer process again", but that might be a bit *too* hardcore. This is a perennial issue, though, and the weakest point of the whole FIDO2 concept overall, including in the way it's being promoted to a mass audience as password-less auth for everything. The official story is you should also enrol a backup phone or tablet or something that you keep at home, then if you lose your main phone, you can get into the system with the backup device, enrol a new main device, and unenrol the lost/stolen main device. But if you *aren't* rich enough to have spare phones/tablets lying around the place, or you just manage to lose both, the story is basically "you go into an Apple store or call up Google or Samsung etc. and somehow convince them you are you and they will then auth a new device onto your account". So, awkward squishy human processes again. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote: > On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote: > > > > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen > > wrote: > > > I'm not entirely convinced. See this paper: > > > https://eprint.iacr.org/2020/1298.pdf > > > > I only read the abstract of this paper, but looks like the researchers > > have found that FIDO is indeed unphishable. Seems their attack relies > > on websites allowing downgrade to weaker forms of 2FA. > > Yup. The thrust of the paper is: in the real world FIDO2 is usually > deployed alongside older/weaker forms of 2FA, so an attacker can > pretend to the victim that FIDO auth didn't work and convince them to > try a weaker method instead, then phish that. > > Which is a reasonable point, but not necessarily relevant to us. We > *could* require only strong auth and not have weaker fallback methods. So I have been thinking about this, how do you deal with the inevitable fact that keys get lost or stop working if there is no alternative authentication method? I guess people can enroll 2 separate keys (if Feodra Infra will allow that), but not everyone has the means to do that. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote: > > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen > wrote: > > I'm not entirely convinced. See this paper: > > https://eprint.iacr.org/2020/1298.pdf > > I only read the abstract of this paper, but looks like the researchers > have found that FIDO is indeed unphishable. Seems their attack relies > on websites allowing downgrade to weaker forms of 2FA. Yup. The thrust of the paper is: in the real world FIDO2 is usually deployed alongside older/weaker forms of 2FA, so an attacker can pretend to the victim that FIDO auth didn't work and convince them to try a weaker method instead, then phish that. Which is a reasonable point, but not necessarily relevant to us. We *could* require only strong auth and not have weaker fallback methods. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On Tue, 2022-09-13 at 16:46 +, Timo S via devel wrote: > $ sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 - > -enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null > && echo --enablerepo=updates-testing-modular) --assumeno distro-sync > Last metadata expiration check: 0:08:47 ago on Tue 13 Sep 2022 > 19:34:54. > Error: > Problem 1: problem with installed package nodejs-electron-19.0.16- > 1.3.x86_64 > - package nodejs-electron-19.0.16-1.4.x86_64 requires > libavif.so.13()(64bit), but none of the providers can be installed > - nodejs-electron-19.0.16-1.3.x86_64 does not belong to a > distupgrade repository > - libavif-0.9.3-3.fc36.x86_64 does not belong to a distupgrade > repository > Problem 2: problem with installed package 0ad-0.0.25b-2.fc36.x86_64 > - package 0ad-0.0.25b-2.fc36.x86_64 requires > libboost_filesystem.so.1.76.0()(64bit), but none of the providers can > be installed > - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a > distupgrade repository > Problem 3: problem with installed package signal-desktop-5.58.0- > 1.7.x86_64 > - package signal-desktop-5.58.0-1.7.x86_64 requires (nodejs- > electron(x86-64) >= 19 with nodejs-electron(x86-64) < 20), but none > of the providers can be installed > - package nodejs-electron-19.0.16-1.3.x86_64 requires > libjxl.so.0.6()(64bit), but none of the providers can be installed > - package nodejs-electron-19.0.16-1.3.x86_64 requires > libjxl.so.0.6(JXL_0)(64bit), but none of the providers can be > installed > - package nodejs-electron-19.0.16-1.4.x86_64 requires > libjxl.so.0.6()(64bit), but none of the providers can be installed > - package nodejs-electron-19.0.16-1.4.x86_64 requires > libjxl.so.0.6(JXL_0)(64bit), but none of the providers can be > installed > - libjxl-0.6.1-9.fc36.x86_64 does not belong to a distupgrade > repository > (try to add '--skip-broken' to skip uninstallable packages) Hi, where did you get signal-desktop and nodejs-electron ? is not is any known repo that I'm aware -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Alexander Sosedkin wrote: > That's a reason why my initial thread [1] has been named > "Landing a larger-than-release change (distrusting SHA-1 signatures)": > flipping the switch is the easy part, unfortunately. IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that. Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote: > On ke, 14 syys 2022, Stephen Smoogen wrote: > > On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy > > wrote: > > > > > > > > Sadly, it cannot be just 'any' certificate, it has to be issued by a > > > certificate authority that is trusted by the KDC as well. For example, > > > by FreeIPA CA which is already ran by the Fedora project infrastructure > > > team. An alternative is to set up certificate mapping and validating > > > rules. > > > > > > If someone from Fedora Accounts team wants to experiment with this, I > > > can guide you what to do. > > > > > > > There is no continual running Fedora Accounts 'team'. There are 2-3 system > > administrators split between releng, operations and continual > > firefighting. There are also a team of developers who are split between > > CentOS Stream initiatives and other work. Changes like this need to have > > more than just an 'oh I have finally an afternoon free where all the other > > crap in the build infra is actually working for once.. lets dive into IPA' > > I understand all of that myself. I think what is important here is to > plan to work together so that eventually we can implement this. Right and while I agree with what smooge says there, I'm definitely interested in improving things as we can. I really would prefer a detailed plan however, not 'lets enable everything we can and see what sticks'. :) > This whole thread is about agreeing or disagreeing whether Fedora as a > project would want to have better security methods to identify and > authenticate its contributors when performing tasks that have large > impact. Yep. I'm in agreement that we want to... but there's always tradeoffs. A few random things to mention: * I don't think requiring FIDO2 for all packagers is tenable. It may well be that we could get donations or funding to get hardware for all packagers, especially if we wait for the current inactive process to finish, but even so, we will run into problems of people who can't get one shipped to them or gets lost in the mail, etc. There would also be a delay "hey, you are now a packager, look for a token in the mail in the next few weeks before you can do anything" * I'd really prefer to avoid going back to certs. People have all kinds of problems with certs. I think it would cause a lot of confusion. (Unless I am misunderstanding what use is proposed for them). > If Fedora contributors would have had access to Fedora's FreeIPA web UI We actually do have external access to the web UI. We just don't advertise it much. > or IPA API directly, we wouldn't even need to have a conversation about > PKINIT and certificates. We could have added instructions how to request > and associate a certificate with your account. But since Fedora Accounts > system is the frontend to Fedora Project's FreeIPA deployment, we cannot > simply do that. However, FreeIPA-wise, smartcards are supported now for > Kerberos authentication, so we as Fedora contributors could benefit from > that. What would this use of certificates do here? Authenticate you to get a kerberos ticket? Allow you to login to the account interface? CentOS folks still use certs for their koji: https://wiki.centos.org/Authentication#TLS_certificate (and thats using the same account system/ipa servers as fedora). > I hope we can plan to work together on this improvement again, similar > how we did with the initial rewrite of Fedora Accounts on top of > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, > perhaps CPA team could consider scheduling this effort as part of the > initiatives. Yeah, I would like that. Perhaps we could setup a meeting soon and dicuss plans? I'm open to video meeting, but we could also do IRC to keep things more open... > Let me round up methods that we have supported now or plan to add in > Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to > issuance of a Kerberos ticket that can be used for communicating with > the rest of Fedora services: > - basic password-based authentication > - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an > external RADIUS server for validation of a string passed as >a 'password' or 'token' value > - use of a certificate stored on a supported PKCS11 token (smartcard, >softtoken (SoftHSMv2, NSS) or just in plain keypair files) > - use of OAuth2 device authorization grant against some OAuth2 IdP (new >in FreeIPA 4.9.10+) > - (future) use of a FIDO2/WebAuthn token > > Fedora accounts system implements the management of the first two > methods right now. And possibly the 3rd... What does 'device' mean in the 4th one? :) We do have https pushes using oauth/oidc token right now. Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh keys and thus use FIDO2 for ssh actions if we wish.
[Bug 2124543] perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6
https://bugzilla.redhat.com/show_bug.cgi?id=2124543 --- Comment #4 from Damian Wrobel --- I prepared a request review for 'per(Template::Plugin::CGI)' [1] as well as the BR for it in [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2126943 [2] https://src.fedoraproject.org/rpms/perl-SOAP-WSDL/c/13fd2ffada8eeeda83f81cdfdf110b89728f68cd?branch=rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124543 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS Meeting Minutes 2022-09-14
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:30:52 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.log.html . Meeting summary --- * roll call (dustymabe, 16:30:56) * Action items from last meeting (dustymabe, 16:33:05) * ACTION: travier Reach out to the podman team for the conmon-rs transition (dustymabe, 16:34:54) * tracker: F37 Test Week (dustymabe, 16:35:30) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1225 (dustymabe, 16:35:33) * Fedora CoreOS next stream was rebased to Fedora Linux 37 content! (dustymabe, 16:37:05) * open floor (dustymabe, 16:40:34) * update barriers for key rotation (bgilbert, 16:43:59) * LINK: https://github.com/coreos/fedora-coreos-streams/pull/561#issuecomment-1244815916 (bgilbert, 16:44:02) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629 (bgilbert, 16:49:45) * AGREED: We will replace our existing barrier instructions to add an update barrier for the last build of N-1 when the first build/release of N happens. Basically option 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629 (dustymabe, 17:08:35) * open floor (dustymabe, 17:09:07) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/567 (bgilbert, 17:12:54) * LINK: https://docs.edgeless.systems/constellation/architecture/images (travier, 17:14:15) * LINK: https://mobile.twitter.com/EdgelessSystems/status/1569630921036386308 > if you want to retweet from the FCOS account (travier, 17:16:18) * LINK: https://github.com/edgelesssys/constellation-fedora-coreos-config/commit/4c8eafd344522696cb616f61bc03271888c479e3 :) (travier, 17:17:35) Meeting ended at 17:19:02 UTC. Action Items * travier Reach out to the podman team for the conmon-rs transition Action Items, by person --- * travier * travier Reach out to the podman team for the conmon-rs transition * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (85) * bgilbert (42) * zodbot (18) * travier (13) * lucab (6) * jbrooks (5) * Nemric (1) * spresti[m] (1) * marmijo (1) * aaradhak (1) * ravanelli (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2124543] perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6
https://bugzilla.redhat.com/show_bug.cgi?id=2124543 Damian Wrobel changed: What|Removed |Added Depends On||2126943 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2126943 [Bug 2126943] Review Request: perl-Template-Plugin-CGI - Simple Template Toolkit plugin interfacing to the CGI.pm module -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124543 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
dwrobel pushed to perl-SOAP-WSDL (rawhide). "Fix FTBFS (rhbz#2124543). (..more)"
Notification time stamped 2022-09-14 20:49:30 UTC
From 13fd2ffada8eeeda83f81cdfdf110b89728f68cd Mon Sep 17 00:00:00 2001
From: Damian Wrobel
Date: Sep 14 2022 17:25:25 +
Subject: Fix FTBFS (rhbz#2124543).
Signed-off-by: Damian Wrobel
---
diff --git a/perl-SOAP-WSDL.spec b/perl-SOAP-WSDL.spec
index d6faf34..e4f4273 100644
--- a/perl-SOAP-WSDL.spec
+++ b/perl-SOAP-WSDL.spec
@@ -1,7 +1,7 @@
Summary: Perl module for SOAP with WSDL support
Name: perl-SOAP-WSDL
Version: 3.004
-Release: 11%{?dist}
+Release: 12%{?dist}
License: GPL+ or Artistic
URL: https://metacpan.org/release/SOAP-WSDL
Source:
https://cpan.metacpan.org/modules/by-module/SOAP/SOAP-WSDL-%{version}.tar.gz
@@ -58,6 +58,7 @@ BuildRequires: perl(URI)
BuildRequires: perl(vars)
BuildRequires: perl(warnings)
BuildRequires: perl(XML::Parser::Expat)
+BuildRequires: perl(Template::Plugin::CGI)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
Requires: perl(SOAP::Lite)
@@ -133,6 +134,9 @@ chmod 0755 %{buildroot}%{_bindir}/wsdl2perl.pl
%changelog
+* Wed Sep 14 2022 Damian Wrobel - 3.004-12
+- Add missing BR. Fixes FTBFS (rhbz#2124543).
+
* Fri Jul 22 2022 Fedora Release Engineering -
3.004-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-SOAP-WSDL/c/13fd2ffada8eeeda83f81cdfdf110b89728f68cd?branch=rawhide
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[WIP][gpgme rebase to 1.18.0] Ask for comaintainership of dependant packages
Hello, I am planning to update gpgme to 1.18.0 in rawhide and since there is SONAME bump in libqgpgme, I am asking to be a co-maintainer of these dependant packages: - https://src.fedoraproject.org/rpms/isoimagewriter (main admin: lupinix) - https://src.fedoraproject.org/rpms/kdepim-addons (main admin: rdieter) - https://src.fedoraproject.org/rpms/kf5-libkleo (main admin: rdieter) - https://src.fedoraproject.org/rpms/kf5-mailcommon (main admin: rdieter) - https://src.fedoraproject.org/rpms/kf5-messagelib (main admin: rdieter) - https://src.fedoraproject.org/rpms/kget (main admin: than) - https://src.fedoraproject.org/rpms/kleopatra (main admin: rdieter) - https://src.fedoraproject.org/rpms/kmail-account-wizard (main admin: rdieter) - https://src.fedoraproject.org/rpms/kmail (main admin: rdieter) - https://src.fedoraproject.org/rpms/trojita (main admin: kkofler) Thanks in advance, Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
GAP 4.12 and a package review swap
The gap package has a new version available (4.12), which comes with significant improvements over 4.11. I've been working on updating the entire gap stack [1] for the new version. The spec files have been simplified and made more uniform, which should aid future maintenance. I need one new package as part of this effort. Who would like to swap reviews? gap-pkg-standardff: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2126927 There is a COPR [2] with the relevant builds, including the new package [3]. Footnotes: [1] Every package named gap-pkg-*, plus gap, GAPDoc, and xgap. [2] https://copr.fedorainfracloud.org/coprs/jjames/GAP4.12/ [3] https://copr.fedorainfracloud.org/coprs/jjames/GAP4.12/build/4836940/ -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
I've updated https://fedoraproject.org/wiki/Changes/NodejsRepackaging with the results of this discussion. I'll go the `nodejs-$MAJOR-unversioned-command` route. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: python-passlib for python38 module
Am 24.05.22 um 19:53 schrieb Maxwell G via epel-devel:
On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
I've been coming to the thinking that naming the SRPMS
python3X-%{srcname}-epel is a better choice. This makes modifying
original Fedora specs simpler.
I think that makes sense, especially considering that these packages will not
be built for Fedora.
See https://fedoraproject.org/wiki/EPEL/Python3X
Here is some feedback:
First, aren't we trying to move off the wiki? Wouldn't this be a better
candidate for the EPEL docs on docs.fp.o?
separate Python 3 minor versions in EPEL 8 are packaged as separate python3X
(currently python38) packages to allow for independent versions for each
Python version.
There is also python39.
Just a followup:
In CS8/EPELNEXT ansible is on following version now:
# rpm -qa |grep ansible
ansible-core-2.13.3-1.el8.x86_64
ansible-6.0.0-1.el8.next.noarch
with following dependency
# rpm -q --requires ansible-core |grep abi
python(abi) = 3.9
so the mentioned passlib package needs the corresponding rebuild:
I quick test in COPR shows - while builded against the
corresponding python "dnf" module, it necessary don't need to be
in a stream/module itself. All variants can be installed side by side:
# rpm -qa |grep passlib
python3-passlib-1.7.4-6.el8.noarch
python38-passlib-1.7.4-6.el8.noarch
python39-passlib-1.7.4-8.el8.noarch
It seems that the fedora maintainer had changed:
https://bugzilla.redhat.com/show_bug.cgi?id=2087268
--
Leon
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, 2022-09-07 at 17:47 +, Maxwell G via devel wrote: > I think this is a bad idea. It's quite hostile to packagers. It will > break rawhide for months and make it very difficult to stabilize the > distro before the beta freeze or do any type of rebuild. It very well > may > affect other Changes. It will still cause untold problems even if you > revert it before the beta freeze. Please test this in COPR (as Miro > already said) or somewhere else instead of destabilizing the distro. > You > can analyze the COPR failures and report bugs just like the Python > SIG > does for new Python major versions. I have no stake in this but participated in the test day (I don't think anyone else did?) so I would like to give my 2 cents. First for the results. I only noticed two issues: RPM Fusion signing keys and libimobiledevice no longer pairing with phones. Both are "trivial" issues. The former is a quick fix, the latter the maintainer has been notified and has expressed interest in modifying the codebase to switching from SHA1 to something like SHA256. COPR also had issues but again, that was a quick fix. Secondly, I agree that it is hostile to packagers. I filed an issue and the packager was kind of blindsided by the proposal. I have no issue with the term jump scare because I think such a radical change does need to "scare" people otherwise complacency leads to people being slow to migrate (see Python 2 -> 3 and people forking 2, despite having over a decade to switch to 3 for example). So maybe such a big change should have more communication and emphasis. Now while I only found a few issues doing testing, I have no doubt other people will have more exotic setups like specific hardware, VPNs, third party repos, etc. where things will break. Although I should say that I did testing across a wide variety of software including Tor, git, SSH and so on so assuming a relatively vanilla setup, most people should be fine. Anyway I agree on paper about testing it on COPR to avoid affecting the main distro, but I think that something like this can only encourage people to fix (or drop) software if there is intentional breakage. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi wrote: > > On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > > > How about this: > > > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > > > I'm open for proposals on the wording. =) > > Well, I guess it depends on if you still want to implement it and then > plan to roll it back or not... see below. > > > > > Rework the change so it's basically planning on making this change in > > > f38. > > > > That makes it closer than currently, > > defeating the purpose of letting people prepare. > > True, it possibly makes the timeline shorter. > If thats a concern, perhaps you would consider just targeting f39 and > for f38 just doing test days and reminders asking developers to test > instead of changing it and then changing it back? > > > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > > and decides if it can remain on in f38 and if not, it gets reverted and > > > moved to f39. > > > > Not sure how it's better than reverting in branched f38 but not rawhide, > > unless the goal is to hasten the change. > > It's better because it seems more direct and honest to me. > It means you are landing a change and trying to get it done, not landing > it to break people and then at the last minute after people rush to fix > things, removing it again. I also suspect there will be some feet > dragging due to this: "Oh, it's broken now, but they are going to revert > it anyhow, so I won't do anything". If this helps, from the perspective of tracking rawhide, we flip the switch and don't revert it. So the "they'll revert it" argument doesn't work at least for rawhide. > > > In the run up to f38 beta we could: > > > > > > * run a series of test days. perhaps one before you enable it in > > > rawhide, one a month or two later and one right before f38 beta > > > freeze? > > > > I'm for more test days. > > There was one held already and I'm open for holding more in the future. > > Plus I should attempt some side-tag mass-rebuild or equivalent, > > but I, unfortunately, won't get to it until October at the earliest. > > Sure, understand time is low for everyone. ;( > > > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > > tests on a compose or updates? This might be a good thing to try and do > > > before landing it in rawhide. > > > > Sounds great if that's a possibility, but I don't know how to approach it. > > Perhaps Adam can chime in here... > > > > * setup a tracking bug to track the issues, so we can make a more > > > informed decision before f38 beta. > > > > > > Thoughts? > > > > If the core of your proposal is > > * make it happen in f38 and revert and push back to f39 only if necessary > > as opposed to > > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > > but not f38 branched (the current proposal) > > then I can't say I understand what you are trying to achieve with > > that. > > I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just > kidding, it will not take effect until next cycle. That just seems to be > dishonest to our users. > > > IMO it makes the switch less certain, more frantic and more abrupt, > > while I was trying to smoothen it out in time as far as possible. > > I don't think it's possible to cleanly spread out a change like this > over more than 1 long fedora cycle. That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. > > So +1 on all the accompanying activities possible, > > -1 on expediting the switch. > > ok. I'm not sure where the rest of fesco is on this, but I guess we will > see. :) > > Thanks for listening. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
# dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync Fedora 37 - x86_64 22 MB/s | 81 MB 00:03 Fedora 37 openh264 (From Cisco) - x86_64 3.0 kB/s | 2.5 kB 00:00 Fedora Modular 37 - x86_64 4.5 MB/s | 3.8 MB 00:00 Fedora 37 - x86_64 - Updates 237 B/s | 257 B 00:01 Fedora Modular 37 - x86_64 - Updates 722 B/s | 257 B 00:00 Fedora 37 - x86_64 - Test Updates 4.1 MB/s | 5.0 MB 00:01 Fedora Modular 37 - x86_64 - Test Updates 266 kB/s | 267 kB 00:01 RCM Tools for Fedora 37 (RPMs) 7.5 kB/s | 4.5 kB 00:00 RPM Fusion for Fedora 37 - Free 528 kB/s | 680 kB 00:01 RPM Fusion for Fedora 37 - Free - Updates 192 B/s | 257 B 00:01 Error: Problem: problem with installed package 0ad-0.0.25b-2.fc36.x86_64 - package 0ad-0.0.25b-2.fc36.x86_64 requires libboost_filesystem.so.1.76.0()(64bit), but none of the providers can be installed - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) On Mon, Sep 12, 2022 at 8:00 AM Miroslav Suchý wrote: > > Do you want to make Fedora 37 better? Please spend 1 minute of your time and > try to run: > > # Run this only if you use default Fedora modules > # next time you run any DNF command default modules will be enabled again > sudo dnf module reset '*' > > dnf --releasever=37 --setopt=module_platform_id=platform:f37 \ > --enablerepo=updates-testing \ > $(rpm -q fedora-repos-modular >/dev/null && echo > --enablerepo=updates-testing-modular) \ > --assumeno distro-sync > > > This command does not replace `dnf system-upgrade`, but it will reveal > potential problems. > > You may also run `dnf upgrade` before running this command. > > > The `--assumeno` will just test the transaction, but does not make the actual > upgrade. > > > In case you hit dependency issues, please report it against the appropriate > package. > > Or against fedora-obsolete-packages if that package should be removed in > Fedora 37. Please check existing reports against > > fedora-obsolete-packages first: > > https://red.ht/2kuBDPu > > and also there is already bunch of "Fails to install" (F37FailsToInstall) > reports: > > https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109_id_type=anddependson=tvp_id=12486533 > > Thank you > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
OK, third time is the charm. I finally got the command right. Everything went just fine.: sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync $ sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync Copr repo for PyCharm owned by phracek 54 kB/s | 44 kB 00:00 Fedora 37 - x86_64 14 MB/s | 81 MB 00:05 Fedora 37 openh264 (From Cisco) - x86_64 2.4 kB/s | 2.5 kB 00:01 Fedora Modular 37 - x86_642.1 MB/s | 3.8 MB 00:01 Fedora 37 - x86_64 - Updates 333 B/s | 257 B 00:00 Fedora Modular 37 - x86_64 - Updates 313 B/s | 257 B 00:00 Fedora 37 - x86_64 - Test Updates 1.4 MB/s | 5.0 MB 00:03 Fedora Modular 37 - x86_64 - Test Updates 273 kB/s | 267 kB 00:00 google-chrome 11 kB/s | 3.6 kB 00:00 RPM Fusion for Fedora 37 - Nonfree - NVIDIA Driver 14 kB/s | 14 kB 00:01 RPM Fusion for Fedora 37 - Nonfree - Steam3.0 kB/s | 2.2 kB 00:00 Dependencies resolved. [...] Transaction Summary == Install 55 Packages Upgrade2348 Packages Downgrade95 Packages Total download size: 2.6 G Operation aborted. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 14/09/2022 17:26, Michael Catanzaro wrote: If you want to protect against *both* threats, use a security key, but you've already pushed back against requiring a hardware purchase. I never click on links from emails, instant messengers, etc. I'm using fkinit and my simple custom systemd user timer to keep my Kerberos ticket up to date. I don't want to buy a smartphone just to do TOTP: no way. KeePassXC supports TOTP, HOTP and Steam 2FA. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On 9/14/22 09:40, Scott Beamer wrote: I just copied and pasted from the OP... Ok, but you have to be aware that your email client might reformat the text and mess up the lines. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > How about this: > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > I'm open for proposals on the wording. =) Well, I guess it depends on if you still want to implement it and then plan to roll it back or not... see below. > > > Rework the change so it's basically planning on making this change in > > f38. > > That makes it closer than currently, > defeating the purpose of letting people prepare. True, it possibly makes the timeline shorter. If thats a concern, perhaps you would consider just targeting f39 and for f38 just doing test days and reminders asking developers to test instead of changing it and then changing it back? > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > and decides if it can remain on in f38 and if not, it gets reverted and > > moved to f39. > > Not sure how it's better than reverting in branched f38 but not rawhide, > unless the goal is to hasten the change. It's better because it seems more direct and honest to me. It means you are landing a change and trying to get it done, not landing it to break people and then at the last minute after people rush to fix things, removing it again. I also suspect there will be some feet dragging due to this: "Oh, it's broken now, but they are going to revert it anyhow, so I won't do anything". > > > In the run up to f38 beta we could: > > > > * run a series of test days. perhaps one before you enable it in > > rawhide, one a month or two later and one right before f38 beta > > freeze? > > I'm for more test days. > There was one held already and I'm open for holding more in the future. > Plus I should attempt some side-tag mass-rebuild or equivalent, > but I, unfortunately, won't get to it until October at the earliest. Sure, understand time is low for everyone. ;( > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > tests on a compose or updates? This might be a good thing to try and do > > before landing it in rawhide. > > Sounds great if that's a possibility, but I don't know how to approach it. Perhaps Adam can chime in here... > > * setup a tracking bug to track the issues, so we can make a more > > informed decision before f38 beta. > > > > Thoughts? > > If the core of your proposal is > * make it happen in f38 and revert and push back to f39 only if necessary > as opposed to > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > but not f38 branched (the current proposal) > then I can't say I understand what you are trying to achieve with > that. I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just kidding, it will not take effect until next cycle. That just seems to be dishonest to our users. > IMO it makes the switch less certain, more frantic and more abrupt, > while I was trying to smoothen it out in time as far as possible. I don't think it's possible to cleanly spread out a change like this over more than 1 long fedora cycle. > > So +1 on all the accompanying activities possible, > -1 on expediting the switch. ok. I'm not sure where the rest of fesco is on this, but I guess we will see. :) Thanks for listening. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
I just copied and pasted from the OP... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On Wed, 14 Sep 2022 05:06:29 -
"Richard Myers" wrote:
> This is for F35 -> F37 ...
>
> I sure
> would love it if anybody knows how to fix the below warning(?), which
> shows up every time I run DNF (it has persisted through at least 3 or
> 4 Fedora revisions, maybe more):
>
> Traceback (most recent call last):
> File "/usr/lib/python3.10/site-packages/dnf/plugin.py", line 104,
> in _caller getattr(plugin, method)()
> File
> "/usr/lib/python3.10/site-packages/dnf-plugins/generate_completion_cache.py",
> line 62, in sack cur.execute("delete from available")
> sqlite3.DatabaseError: database disk image is malformed
>
> I've tried (in the past) many things to try to fix it, but nothing
> worked. Can't remember everything I tried, because it has been a
> couple of years, but suffice to say, I've tried the low-hanging,
> obvious stuff, and some obscure things...
The database it is trying to access is
/var/cache/dnf/packages.db
If you delete it, it will rebuild it at the next update, and that
should take care of the error, since it shouldn't build a malformed
database from scratch. If it does, you should open an error agaist
package
python3-dnf-plugins-core
component
generate_completion_cache.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
TLS client certificates is actually not a terrible idea. They're not very popular anymore, but they're supported by all major browsers (I think?) and they work. On Wed, Sep 14 2022 at 02:08:32 PM +0200, Vitaly Zaitsev via devel wrote: On 14/09/2022 10:01, Demi Marie Obenour wrote: Still, even a pure software FIDO2 implementation is much better than TOTP etc. I don't think so. Malware can easily steal the private key. Simple TOTP on a separate device is much better. Well they're different threats with different solutions. Installing malware on users' computers is a lot harder than phishing them, so I'd much rather see software-based FIDO2 than TOTP on a separate device. At least I'm not aware of any malware running on my computer, but I already confessed to entering a password into a phishing website, so we know you can phish me at least. If you want to protect against *both* threats, use a security key, but you've already pushed back against requiring a hardware purchase. It's impossible to enforce use of a separate device regardless of whether you're doing TOTP or FIDO2. I use my Yubikey only for my highest-security work account. Everything else uses a TOTP app running on-device, vulnerable to malware. (I don't want to buy a smartphone just to do TOTP: no way. A $25 security key sounds much more reasonable.) Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen wrote: I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf I only read the abstract of this paper, but looks like the researchers have found that FIDO is indeed unphishable. Seems their attack relies on websites allowing downgrade to weaker forms of 2FA. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Explicit dependency on systemd-rpm-macros now required?
On Wed, Sep 14, 2022 at 10:53 AM Smith, Stewart via devel
wrote:
>
>
> > On Sep 14, 2022, at 4:17 AM, Tom Hughes via devel
> > wrote:
> >
> >> On 14/09/2022 12:11, Florian Weimer wrote:
> >> I see some new build failures in rawhide related to systemd RPM macros:
> >>
> >> Processing files: opencryptoki-3.18.0-4.fc38.s390x
> >> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
> >> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
> >> […]
> >> RPM build errors:
> >> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
> >> File must begin with "/": %{_unitdir}/pkcsslotd.service
> >> Child return code was: 1
> >> EXCEPTION: [Error()]
> >>
> >> Is this a package problem (missing dependency on systemd-rpm-macros), or
> >> is this something that should be fixed at the buildroot level?
> >
> > Guidelines say yes, you do need a BR on that:
> >
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
>
> I think there was some change “recently” where it needed to start being
> explicit rather than being brought in by some other dependency (possibly a
> change to systemd?). I hit the same thing in a package in Amazon Linux the
> other day, read the packaging guide and wondered how the package had ever
> built.
It happened because Zbigniew changed the rich dependency from Requires
to Requires(meta):
https://src.fedoraproject.org/rpms/systemd/c/c971c5b980dff46fb9d7885f9e26b179a5a4749b
I don't think Requires(meta) works when weak dependencies are turned off.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 14. 09. 22 16:36, Casper wrote: Miro Hrončok a écrit : profanity @fantom ASSIGNED https://bugzilla.redhat.com/2049682 Bug status changed ~3 weeks ago without comment, not updated since. Fixed in rawhide recently, f37-candidate build exists. I just made package update 1 hour ago. Cross-fire :) https://bodhi.fedoraproject.org/updates/FEDORA-2022-245be5acd2 RHBZ#2049682 is now closed. Awesome, thanks! PS I've reopened the bugzilla and marked the update as fixing it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 14. 09. 22 16:36, Casper wrote: Miro Hrončok a écrit : profanity @fantom ASSIGNED https://bugzilla.redhat.com/2049682 Bug status changed ~3 weeks ago without comment, not updated since. Fixed in rawhide recently, f37-candidate build exists. I just made package update 1 hour ago. Cross-fire :) https://bodhi.fedoraproject.org/updates/FEDORA-2022-245be5acd2 RHBZ#2049682 is now closed. Awesome, thanks! PS I've reopened the bugzilla and marked the update as fixing it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Explicit dependency on systemd-rpm-macros now required?
> On Sep 14, 2022, at 4:17 AM, Tom Hughes via devel
> wrote:
>
>> On 14/09/2022 12:11, Florian Weimer wrote:
>> I see some new build failures in rawhide related to systemd RPM macros:
>>
>> Processing files: opencryptoki-3.18.0-4.fc38.s390x
>> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
>> […]
>> RPM build errors:
>> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> File must begin with "/": %{_unitdir}/pkcsslotd.service
>> Child return code was: 1
>> EXCEPTION: [Error()]
>>
>> Is this a package problem (missing dependency on systemd-rpm-macros), or
>> is this something that should be fixed at the buildroot level?
>
> Guidelines say yes, you do need a BR on that:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
I think there was some change “recently” where it needed to start being
explicit rather than being brought in by some other dependency (possibly a
change to systemd?). I hit the same thing in a package in Amazon Linux the
other day, read the packaging guide and wondered how the package had ever built.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On ke, 14 syys 2022, Stephen Smoogen wrote: On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy wrote: Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules. If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do. There is no continual running Fedora Accounts 'team'. There are 2-3 system administrators split between releng, operations and continual firefighting. There are also a team of developers who are split between CentOS Stream initiatives and other work. Changes like this need to have more than just an 'oh I have finally an afternoon free where all the other crap in the build infra is actually working for once.. lets dive into IPA' I understand all of that myself. I think what is important here is to plan to work together so that eventually we can implement this. This whole thread is about agreeing or disagreeing whether Fedora as a project would want to have better security methods to identify and authenticate its contributors when performing tasks that have large impact. If Fedora contributors would have had access to Fedora's FreeIPA web UI or IPA API directly, we wouldn't even need to have a conversation about PKINIT and certificates. We could have added instructions how to request and associate a certificate with your account. But since Fedora Accounts system is the frontend to Fedora Project's FreeIPA deployment, we cannot simply do that. However, FreeIPA-wise, smartcards are supported now for Kerberos authentication, so we as Fedora contributors could benefit from that. I hope we can plan to work together on this improvement again, similar how we did with the initial rewrite of Fedora Accounts on top of FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, perhaps CPA team could consider scheduling this effort as part of the initiatives. Let me round up methods that we have supported now or plan to add in Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to issuance of a Kerberos ticket that can be used for communicating with the rest of Fedora services: - basic password-based authentication - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an external RADIUS server for validation of a string passed as a 'password' or 'token' value - use of a certificate stored on a supported PKCS11 token (smartcard, softtoken (SoftHSMv2, NSS) or just in plain keypair files) - use of OAuth2 device authorization grant against some OAuth2 IdP (new in FreeIPA 4.9.10+) - (future) use of a FIDO2/WebAuthn token Fedora accounts system implements the management of the first two methods right now. As much as I enjoy better security, everyone should remember that the ones affected are either packagers who are volunteering to make spec files for software they need for something else.. or developers who only look at spec files as the last hassle they need to do before they can mark on their list 'shipped and done'. Most of them do not package/build things very often, and it takes years for them to get retrained when some change in the workflow occurs. A particular benefit of using Kerberos authentication to Fedora services is that it does not need to change the workflow for all those things. Once you've got your ticket, it works against all the services you are allowed to access. Sure, actual process of obtaining that ticket might change -- like with 2FA token one needs to get a wrap ticket first -- but the rest is the same. They are also the only ones around to do the work. Making workflow changes like adding certificates, tokens, etc may be needed but they are going to need a lot of documentation, continual training, and coaching to actually make function. If there is no staff or people available to do this, then the change will fail hard. Do we have any statistics of how we stand now that Fedora Accounts is deployed for more than a year and people were enabled to use 2FA tokens through it? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
Miro Hrončok a écrit : > profanity > @fantom > ASSIGNED https://bugzilla.redhat.com/2049682 > Bug status changed ~3 weeks ago without comment, > not updated since. > Fixed in rawhide recently, f37-candidate build exists. > I just made package update 1 hour ago. Cross-fire :) https://bodhi.fedoraproject.org/updates/FEDORA-2022-245be5acd2 RHBZ#2049682 is now closed. -- GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der Jabber/XMPP Messaging: cas...@casperlefantom.net signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Remaining packages in need of a Python 3.11 rebuild
Hello folks! We are approaching Fedora 37 Final Freeze, which will start on 2022-10-04. There are still 33 packages in Fedora 37 that will need to be rebuilt with Python 3.11 in order to be installable (most of them). I propose to retire the non-installable packages if they are not rebuilt by 2022-10-03 (1 day before the final freeze) unless they have a freeze exception request and a clear path forward to make it to Fedora 37 GA. Packages that will be fixed after GA can be reintroduced with an update. Packages by maintainer: aekoroglu python-funcy python-sendgrid amoralej python-yappi bizdelnick dlib dcavalca monkeytype fabhome-assistant-cli python-haversion python-requests-credssp fantom profanity gicmo renderdoc ibotty paternoster kevin datanommer luya dlib mcurlejmodule-build merlinmpython-calligrabot mkulik module-build ngompa kiwi-boxed-plugin python-hyperkitty python-postorius oget muse orphan python-calligrabot python-cu2qu python-evic qulogicpython-octave-kernel ralph datagrepper datanommer-commands raphgrojpype py4j python-javabridge python-jep rathannpython-Pympler python-filecheck salimmamailman3 monkeytype python-django-mailman3 python-hyperkitty python-postorius sdgathman cjdns sharkczsigil cjdns @sdgathman ASSIGNED https://bugzilla.redhat.com/2045255 2 possible ways forward but no news for ~3 weeks datagrepper @ralph ASSIGNED https://bugzilla.redhat.com/2098691 Upstream (Fedora Infra) pins dependencies aggressively, needs to be relaxed downstream (also Fedora Infra) as a workaround. Maybe persuade upstream into not doing that long-term. datanommer @kevin NEW https://bugzilla.redhat.com/2098692 Upstream (Fedora Infra) pins dependencies aggressively, needs to be relaxed downstream (also Fedora Infra) as a workaround Maybe persuade upstream into not doing that long-term. Will be retired one week before the freeze anyway barbecue it's an old NEW. datanommer-commands @ralph ASSIGNED https://bugzilla.redhat.com/2098693 Seems to have been updated in dist-git to a version with missing dependencies? dlib @bizdelnick @luya ASSIGNED https://bugzilla.redhat.com/2098694 Bundles old pybind11 which is not Python 3.11 compatible, needs to be unbundled or at least updated. home-assistant-cli @fab ASSIGNED https://bugzilla.redhat.com/2058155 Bug status changed in March without comment, not updated since. jpype @raphgro NEW https://bugzilla.redhat.com/2049705 Upstream PR exists: https://github.com/jpype-project/jpype/pull/1087 kiwi-boxed-plugin @ngompa NEW https://bugzilla.redhat.com/2098732 Already orphaned once due to non-responsivnes, took again by the same maintainer without response. Fixed in Rawhide recently, requested a Fedora 37 fix. Will be retired one week before the freeze anyway barbecue it's an old NEW. mailman3 @salimma ASSIGNED https://bugzilla.redhat.com/2098746 Bug status changed ~4 weeks ago without comment, not updated since. module-build @mcurlej @mkulik ASSIGNED https://bugzilla.redhat.com/2098750 Fixed in rawhide recently, requested a Fedora 37 fix. monkeytype @dcavalca @salimma ASSIGNED https://bugzilla.redhat.com/2098752 Maintainer "will try to fix this" ~3 weeks ago, no news since. muse @oget NEW https://bugzilla.redhat.com/2103647 Accidentally closed before, but still does not build. Only requires libpython3.10.so.1.0()(64bit) so is installable. paternoster @ibotty ASSIGNED https://bugzilla.redhat.com/2098772 Maintainer agreed to retire ~3 weeks ago, no news since. profanity @fantom ASSIGNED https://bugzilla.redhat.com/2049682 Bug status changed ~3 weeks ago without comment, not updated since. Fixed in rawhide recently, f37-candidate build exists. py4j @raphgro NEW https://bugzilla.redhat.com/2098787 Already CLOSED DEFERRED once by the maintainer, no fix. python-calligrabot @merlinm @orphan NEW https://bugzilla.redhat.com/2098856 Already orphaned once due to non-responsivnes, took again by a different maintainer, orphaned again by them. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-cu2qu @orphan NEW https://bugzilla.redhat.com/2098875 Already orphaned due to non-responsivnes. Should be retired as it is not needed any more. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-django-mailman3 @salimma ASSIGNED https://bugzilla.redhat.com/2044961 Bug status changed in March without comment, not updated since. python-evic @orphan NEW https://bugzilla.redhat.com/2098904 Already orphaned due to non-responsivnes. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-filecheck @rathann ASSIGNED https://bugzilla.redhat.com/2098908 Last comment in June, no news since. python-funcy @aekoroglu NEW https://bugzilla.redhat.com/2098917 Orphaned (used to be Igor's?), taken by another maintainer, no update. Will be retired one week before the freeze anyway barbecue it's an old NEW.
Remaining packages in need of a Python 3.11 rebuild
Hello folks! We are approaching Fedora 37 Final Freeze, which will start on 2022-10-04. There are still 33 packages in Fedora 37 that will need to be rebuilt with Python 3.11 in order to be installable (most of them). I propose to retire the non-installable packages if they are not rebuilt by 2022-10-03 (1 day before the final freeze) unless they have a freeze exception request and a clear path forward to make it to Fedora 37 GA. Packages that will be fixed after GA can be reintroduced with an update. Packages by maintainer: aekoroglu python-funcy python-sendgrid amoralej python-yappi bizdelnick dlib dcavalca monkeytype fabhome-assistant-cli python-haversion python-requests-credssp fantom profanity gicmo renderdoc ibotty paternoster kevin datanommer luya dlib mcurlejmodule-build merlinmpython-calligrabot mkulik module-build ngompa kiwi-boxed-plugin python-hyperkitty python-postorius oget muse orphan python-calligrabot python-cu2qu python-evic qulogicpython-octave-kernel ralph datagrepper datanommer-commands raphgrojpype py4j python-javabridge python-jep rathannpython-Pympler python-filecheck salimmamailman3 monkeytype python-django-mailman3 python-hyperkitty python-postorius sdgathman cjdns sharkczsigil cjdns @sdgathman ASSIGNED https://bugzilla.redhat.com/2045255 2 possible ways forward but no news for ~3 weeks datagrepper @ralph ASSIGNED https://bugzilla.redhat.com/2098691 Upstream (Fedora Infra) pins dependencies aggressively, needs to be relaxed downstream (also Fedora Infra) as a workaround. Maybe persuade upstream into not doing that long-term. datanommer @kevin NEW https://bugzilla.redhat.com/2098692 Upstream (Fedora Infra) pins dependencies aggressively, needs to be relaxed downstream (also Fedora Infra) as a workaround Maybe persuade upstream into not doing that long-term. Will be retired one week before the freeze anyway barbecue it's an old NEW. datanommer-commands @ralph ASSIGNED https://bugzilla.redhat.com/2098693 Seems to have been updated in dist-git to a version with missing dependencies? dlib @bizdelnick @luya ASSIGNED https://bugzilla.redhat.com/2098694 Bundles old pybind11 which is not Python 3.11 compatible, needs to be unbundled or at least updated. home-assistant-cli @fab ASSIGNED https://bugzilla.redhat.com/2058155 Bug status changed in March without comment, not updated since. jpype @raphgro NEW https://bugzilla.redhat.com/2049705 Upstream PR exists: https://github.com/jpype-project/jpype/pull/1087 kiwi-boxed-plugin @ngompa NEW https://bugzilla.redhat.com/2098732 Already orphaned once due to non-responsivnes, took again by the same maintainer without response. Fixed in Rawhide recently, requested a Fedora 37 fix. Will be retired one week before the freeze anyway barbecue it's an old NEW. mailman3 @salimma ASSIGNED https://bugzilla.redhat.com/2098746 Bug status changed ~4 weeks ago without comment, not updated since. module-build @mcurlej @mkulik ASSIGNED https://bugzilla.redhat.com/2098750 Fixed in rawhide recently, requested a Fedora 37 fix. monkeytype @dcavalca @salimma ASSIGNED https://bugzilla.redhat.com/2098752 Maintainer "will try to fix this" ~3 weeks ago, no news since. muse @oget NEW https://bugzilla.redhat.com/2103647 Accidentally closed before, but still does not build. Only requires libpython3.10.so.1.0()(64bit) so is installable. paternoster @ibotty ASSIGNED https://bugzilla.redhat.com/2098772 Maintainer agreed to retire ~3 weeks ago, no news since. profanity @fantom ASSIGNED https://bugzilla.redhat.com/2049682 Bug status changed ~3 weeks ago without comment, not updated since. Fixed in rawhide recently, f37-candidate build exists. py4j @raphgro NEW https://bugzilla.redhat.com/2098787 Already CLOSED DEFERRED once by the maintainer, no fix. python-calligrabot @merlinm @orphan NEW https://bugzilla.redhat.com/2098856 Already orphaned once due to non-responsivnes, took again by a different maintainer, orphaned again by them. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-cu2qu @orphan NEW https://bugzilla.redhat.com/2098875 Already orphaned due to non-responsivnes. Should be retired as it is not needed any more. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-django-mailman3 @salimma ASSIGNED https://bugzilla.redhat.com/2044961 Bug status changed in March without comment, not updated since. python-evic @orphan NEW https://bugzilla.redhat.com/2098904 Already orphaned due to non-responsivnes. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-filecheck @rathann ASSIGNED https://bugzilla.redhat.com/2098908 Last comment in June, no news since. python-funcy @aekoroglu NEW https://bugzilla.redhat.com/2098917 Orphaned (used to be Igor's?), taken by another maintainer, no update. Will be retired one week before the freeze anyway barbecue it's an old NEW.
Re: Donate 1 minute of your time to test upgrades from F36 to F37
# dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync Last metadata expiration check: 0:06:44 ago on Wed 14 Sep 2022 02:12:53 PM CEST. Error: Problem: problem with installed package python3-lhafile-0.3.0-6.1.x86_64 - package python3-lhafile-0.3.0-6.1.x86_64 requires python(abi) = 3.10, but none of the providers can be installed - python3-3.10.6-1.fc36.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) # dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync --skip-broken Last metadata expiration check: 0:07:12 ago on Wed 14 Sep 2022 02:12:53 PM CEST. Error: Problem: problem with installed package python3-lhafile-0.3.0-6.1.x86_64 - package python3-lhafile-0.3.0-6.1.x86_64 requires python(abi) = 3.10, but none of the providers can be installed - python3-3.10.6-1.fc36.x86_64 does not belong to a distupgrade repository ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy wrote: > > Sadly, it cannot be just 'any' certificate, it has to be issued by a > certificate authority that is trusted by the KDC as well. For example, > by FreeIPA CA which is already ran by the Fedora project infrastructure > team. An alternative is to set up certificate mapping and validating > rules. > > If someone from Fedora Accounts team wants to experiment with this, I > can guide you what to do. > There is no continual running Fedora Accounts 'team'. There are 2-3 system administrators split between releng, operations and continual firefighting. There are also a team of developers who are split between CentOS Stream initiatives and other work. Changes like this need to have more than just an 'oh I have finally an afternoon free where all the other crap in the build infra is actually working for once.. lets dive into IPA' As much as I enjoy better security, everyone should remember that the ones affected are either packagers who are volunteering to make spec files for software they need for something else.. or developers who only look at spec files as the last hassle they need to do before they can mark on their list 'shipped and done'. Most of them do not package/build things very often, and it takes years for them to get retrained when some change in the workflow occurs. They are also the only ones around to do the work. Making workflow changes like adding certificates, tokens, etc may be needed but they are going to need a lot of documentation, continual training, and coaching to actually make function. If there is no staff or people available to do this, then the change will fail hard. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 14/09/2022 10:01, Demi Marie Obenour wrote: Still, even a pure software FIDO2 implementation is much better than TOTP etc. I don't think so. Malware can easily steal the private key. Simple TOTP on a separate device is much better. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Explicit dependency on systemd-rpm-macros now required?
* Tom Hughes via devel:
> On 14/09/2022 12:11, Florian Weimer wrote:
>> I see some new build failures in rawhide related to systemd RPM macros:
>> Processing files: opencryptoki-3.18.0-4.fc38.s390x
>> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
>> […]
>> RPM build errors:
>> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> File must begin with "/": %{_unitdir}/pkcsslotd.service
>> Child return code was: 1
>> EXCEPTION: [Error()]
>> Is this a package problem (missing dependency on
>> systemd-rpm-macros), or
>> is this something that should be fixed at the buildroot level?
>
> Guidelines say yes, you do need a BR on that:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
Ah, thanks, missed that. I'll try to fix opencryptoki then.
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Explicit dependency on systemd-rpm-macros now required?
On 14/09/2022 12:11, Florian Weimer wrote:
I see some new build failures in rawhide related to systemd RPM macros:
Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]
Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?
Guidelines say yes, you do need a BR on that:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Explicit dependency on systemd-rpm-macros now required?
I see some new build failures in rawhide related to systemd RPM macros:
Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]
Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20220914.n.0 changes
OLD: Fedora-Rawhide-20220913.n.0 NEW: Fedora-Rawhide-20220914.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 2 Dropped packages:2 Upgraded packages: 174 Downgraded packages: 0 Size of added packages: 323.29 KiB Size of dropped packages:100.91 MiB Size of upgraded packages: 3.05 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -86.31 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: python-azure-eventhub-5.10.1-1.fc38 Summary: Microsoft Azure Event Hubs Client Library for Python RPMs:python3-azure-eventhub Size:249.78 KiB Package: python-azure-mgmt-fluidrelay-1.0.0-1.fc38 Summary: Microsoft Azure Fluid Relay Management Client Library for Python RPMs:python3-azure-mgmt-fluidrelay Size:73.50 KiB = DROPPED PACKAGES = Package: rust-starship-1.2.1-5.fc37 Summary: Minimal, blazing-fast, and infinitely customizable prompt for any shell RPMs:rust-starship+battery-devel rust-starship+default-devel rust-starship+notify-rust-devel rust-starship+starship-battery-devel rust-starship-devel starship Size:7.82 MiB Package: valyriatear-1.0.0-26.fc37 Summary: Valyria Tear is a free 2D J-RPG based on the Hero of Allacrost engine RPMs:valyriatear valyriatear-data Size:93.09 MiB = UPGRADED PACKAGES = Package: ImageMagick-1:6.9.12.63-1.fc38 Old package: ImageMagick-1:6.9.12.62-1.fc38 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 33.76 MiB Size change: 6.30 KiB Changelog: * Tue Sep 13 2022 S??rgio Basto - 1:6.9.12.63-1 - Update ImageMagick to 6.9.12.63 (#2125990) Package: amiri-fonts-0.117-1.fc38 Old package: amiri-fonts-0.113-4.fc37 Summary: A classical Arabic font in Naskh style RPMs: amiri-fonts amiri-fonts-all amiri-quran-colored-fonts amiri-quran-fonts Added RPMs: amiri-fonts-all amiri-quran-colored-fonts Dropped RPMs: amiri-fonts-common Size: 723.68 KiB Size change: -13.51 KiB Changelog: * Sat Sep 03 2022 Parag Nemade - 0.117-1 - Convert spec to new fonts packaging guidelines - Update to new upstream release 0.117 Package: ansible-collection-community-general-5.6.0-1.fc38 Old package: ansible-collection-community-general-5.5.0-1.fc38 Summary: Modules and plugins supported by Ansible community RPMs: ansible-collection-community-general Size: 1.49 MiB Size change: 3.75 KiB Changelog: * Tue Sep 13 2022 Maxwell G - 5.6.0-1 - Update to 5.6.0. Package: ant-1.10.12-8.fc38 Old package: ant-1.10.12-8.fc37 Summary: Java build tool RPMs: ant ant-antlr ant-apache-bcel ant-apache-bsf ant-apache-oro ant-apache-regexp ant-apache-resolver ant-apache-xalan2 ant-commons-logging ant-commons-net ant-imageio ant-javadoc ant-javamail ant-jdepend ant-jmf ant-jsch ant-junit ant-junit5 ant-lib ant-manual ant-swing ant-testutil ant-xz Size: 5.28 MiB Size change: 1.42 KiB Package: apache-commons-beanutils-1.9.4-11.fc38 Old package: apache-commons-beanutils-1.9.4-11.fc37 Summary: Java utility methods for accessing and modifying the properties of arbitrary JavaBeans RPMs: apache-commons-beanutils apache-commons-beanutils-javadoc Size: 624.27 KiB Size change: 97 B Package: apache-commons-cli-1.5.0-4.fc38 Old package: apache-commons-cli-1.5.0-4.fc37 Summary: Command Line Interface Library for Java RPMs: apache-commons-cli apache-commons-cli-javadoc Size: 255.16 KiB Size change: 29 B Package: apache-commons-codec-1.15-7.fc38 Old package: apache-commons-codec-1.15-7.fc37 Summary: Implementations of common encoders and decoders RPMs: apache-commons-codec apache-commons-codec-javadoc Size: 627.70 KiB Size change: -1.15 KiB Package: apache-commons-collections-3.2.2-28.fc38 Old package: apache-commons-collections-3.2.2-28.fc37 Summary: Provides new interfaces, implementations and utilities for Java Collections RPMs: apache-commons-collections apache-commons-collections-javadoc apache-commons-collections-testframework Size: 1.46 MiB Size change: -1.15 KiB Package: apache-commons-compress-1.21-4.fc38 Old package: apache-commons-compress-1.21-4.fc37 Summary: Java API for working with compressed files and archivers RPMs: apache-commons-compress apache-commons-compress-javadoc Size: 1.31 MiB Size change: -704 B Package: apache-commons-io-1:2.11.0-2.fc38 Old package: apache-commons-io-1:2.11.0-2.fc37 Summary: Utilities to assist with developing IO functionality RPMs: apache-commons-io apache-commons-io-javadoc Size: 864.33 KiB Size change: -402 B Package
[Bug 2126661] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126661 --- Comment #2 from Fedora Update System --- FEDORA-2022-95366a795e has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-95366a795e -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126677] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126677 --- Comment #1 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126677 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126682] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126682 --- Comment #1 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126682 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126679] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126679 --- Comment #1 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126679 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126661] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126661 --- Comment #1 from Fedora Update System --- FEDORA-2022-7f390fcbe8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f390fcbe8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > How about this: > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. I'm open for proposals on the wording. =) > Rework the change so it's basically planning on making this change in > f38. That makes it closer than currently, defeating the purpose of letting people prepare. > Before f38 beta freeze, change owners/fesco looks at the state of things > and decides if it can remain on in f38 and if not, it gets reverted and > moved to f39. Not sure how it's better than reverting in branched f38 but not rawhide, unless the goal is to hasten the change. > In the run up to f38 beta we could: > > * run a series of test days. perhaps one before you enable it in > rawhide, one a month or two later and one right before f38 beta > freeze? I'm for more test days. There was one held already and I'm open for holding more in the future. Plus I should attempt some side-tag mass-rebuild or equivalent, but I, unfortunately, won't get to it until October at the earliest. > * see if openqa might have some way to set TEST-FEDORA39 and re-run > tests on a compose or updates? This might be a good thing to try and do > before landing it in rawhide. Sounds great if that's a possibility, but I don't know how to approach it. > * setup a tracking bug to track the issues, so we can make a more > informed decision before f38 beta. > > Thoughts? If the core of your proposal is * make it happen in f38 and revert and push back to f39 only if necessary as opposed to * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, but not f38 branched (the current proposal) then I can't say I understand what you are trying to achieve with that. IMO it makes the switch less certain, more frantic and more abrupt, while I was trying to smoothen it out in time as far as possible. So +1 on all the accompanying activities possible, -1 on expediting the switch. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On ke, 14 syys 2022, Demi Marie Obenour wrote: On 9/14/22 03:55, Vitaly Zaitsev via devel wrote: On 14/09/2022 08:46, Demi Marie Obenour wrote: The only other non-phishable authentication method is TLS client certificates and I would be fine with those. Fedora used to have TLS client certificate authorization (in Koji), but this has been replaced by Kerberos. Could Fedora turn on PKINIT or make TLS client certificate authentication an option again? I think PKINIT support is active, otherwise you would not be able to use Anonymous PKINIT for FAST channel wrapping with OTP preauthentication. All we need is a way to associate a trusted certificate with the user and have the trust between KDC cert and the client machine where you'd run kinit: [1660786] 1663147221.189471: PKINIT client verified DH reply [1660786] 1663147221.189472: PKINIT client found id-pkinit-san in KDC cert: krbtgt/fedoraproject@fedoraproject.org [1660786] 1663147221.189473: PKINIT client matched KDC principal krbtgt/fedoraproject@fedoraproject.org against id-pkinit-san; no EKU check required [1660786] 1663147221.189474: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/1D6D [1660786] 1663147221.189475: Preauth module pkinit (17) (real) returned: 0/Success The latter works fine, so we just need to have a certificate in the user account to use PKINIT, not Anonymous PKINIT. And since we have no direct access to FreeIPA server behind Fedora Accounts system, Fedora Accounts should be extended to allow adding a public certificate to the user's account. Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules. If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do. since almost every laptop has a TPM. In some countries (Russia, China and some other countries from the US export banlist) hardware TPMs are prohibited. Still, even a pure software FIDO2 implementation is much better than TOTP etc. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: small aarch64 home server
On Tue, Sep 13, 2022 at 7:51 PM Chris Adams wrote: > > I'd like to piggy-back - is there a Fedora well-supported board that can > use the Pi-targeted hats? I stayed away from the Pi for a long while, > because of the support problems, but it just seems like there's so much > that's just made for Pis. HATs are hard, there's a lot of devices that claim to be compatible with the HAT interface but there's always caveats so it would depend very much on your usecase. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: glibc 2.36 and DT_HASH (preserving it for F37+)
* Vitaly Zaitsev via devel: > On 14/09/2022 05:27, Neal Gompa wrote: >> Well, we just released the Beta and people have noticed that this is >> still broken. Do we have an ETA on a fix? Because this is going to be >> a major black eye for*us* if it stays broken through to GA. > > Epic Games had more than a month to fix the problem but they did nothing. Why do you say that? These multi-ISV coordination issues can be difficult to resolve. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126682] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126682 Petr Pisar changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2022-09-14 08:48:55 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126682 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126682] New: Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126682 Bug ID: 2126682 Summary: Remove from a distribution Product: Fedora Version: 37 Status: NEW Component: perl-Lingua-EN-Syllable Assignee: mhron...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: extras-orp...@fedoraproject.org, perl-devel@lists.fedoraproject.org, rland...@redhat.com Target Milestone: --- Classification: Fedora Removed with: commit d2314bfe49afacb122ed337d3461169254848030 (HEAD -> rawhide, origin/rawhide, origin/main, origin/HEAD) Author: Miro Hrončok Date: Thu Mar 3 12:51:56 2022 +0100 Orphaned for 6+ weeks $ koji list-pkgs --show-blocked --package perl-Lingua-EN-Syllable | tail perl-Lingua-EN-Syllable f34 orphan perl-Lingua-EN-Syllable f33-Beta releng perl-Lingua-EN-Syllable f35 orphan perl-Lingua-EN-Syllable f34-Beta releng perl-Lingua-EN-Syllable f36 orphan perl-Lingua-EN-Syllable f35-Beta rlandmann perl-Lingua-EN-Syllable f37 orphan [BLOCKED] perl-Lingua-EN-Syllable f36-Beta orphan perl-Lingua-EN-Syllable f38 orphan [BLOCKED] perl-Lingua-EN-Syllable f37-Beta orphan [BLOCKED] -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126682 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126679] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126679 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Last Closed||2022-09-14 08:44:21 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126679 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126679] New: Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126679 Bug ID: 2126679 Summary: Remove from a distribution Product: Fedora Version: 37 Status: NEW Component: perl-Lingua-EN-Fathom Assignee: mhron...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: extras-orp...@fedoraproject.org, jfe...@redhat.com, perl-devel@lists.fedoraproject.org, rland...@redhat.com Target Milestone: --- Classification: Fedora Removed with: commit fd83c308527e79b8d1041d0a31eb3798b69efd18 (HEAD -> rawhide, origin/rawhide, origin/main, origin/HEAD) Author: Miro Hrončok Date: Thu Mar 3 12:51:43 2022 +0100 Orphaned for 6+ weeks $ koji list-pkgs --show-blocked --package perl-Lingua-EN-Fathom | tail perl-Lingua-EN-Fathom f34 orphan perl-Lingua-EN-Fathom f33-Beta releng perl-Lingua-EN-Fathom f35 orphan perl-Lingua-EN-Fathom f34-Beta releng perl-Lingua-EN-Fathom f36 orphan perl-Lingua-EN-Fathom f35-Beta rlandmann perl-Lingua-EN-Fathom f37 orphan [BLOCKED] perl-Lingua-EN-Fathom f36-Beta orphan perl-Lingua-EN-Fathom f38 orphan [BLOCKED] perl-Lingua-EN-Fathom f37-Beta orphan [BLOCKED] -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126679 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126677] New: Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126677 Bug ID: 2126677 Summary: Remove from a distribution Product: Fedora Version: 37 Status: NEW Component: perl-File-Inplace Assignee: mhron...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: extras-orp...@fedoraproject.org, perl-devel@lists.fedoraproject.org, rland...@redhat.com Target Milestone: --- Classification: Fedora Removed with: commit d0726866bd999c298ca356abc618403000999a35 (HEAD -> rawhide, origin/rawhide, origin/main, origin/HEAD) Author: Miro Hrončok Date: Thu Mar 3 12:51:29 2022 +0100 Orphaned for 6+ weeks $ koji list-pkgs --show-blocked --package perl-File-Inplace | tail perl-File-Inplace f34 orphan perl-File-Inplace f33-Beta releng perl-File-Inplace f35 orphan perl-File-Inplace f34-Beta releng perl-File-Inplace f36 orphan perl-File-Inplace f35-Beta rlandmann perl-File-Inplace f37 orphan [BLOCKED] perl-File-Inplace f36-Beta orphan perl-File-Inplace f38 orphan [BLOCKED] perl-File-Inplace f37-Beta orphan [BLOCKED] -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126677 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126677] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126677 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Last Closed||2022-09-14 08:34:55 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126677 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126661] Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126661 Petr Pisar changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2022-09-14 08:26:17 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2126661] New: Remove from a distribution
https://bugzilla.redhat.com/show_bug.cgi?id=2126661 Bug ID: 2126661 Summary: Remove from a distribution Product: Fedora Version: 36 Status: NEW Component: perl-Verilog-CodeGen Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Removed with: commit a76eb4803c668c8ae8864a534e650984f2858d60 (HEAD -> rawhide, origin/rawhide, origin/main, origin/H EAD) Author: Jitka Plesnikova Date: Mon Jan 3 09:19:24 2022 +0100 Retired due to inactive upstream and one of dependencies (xemacs) is retired in F36 $ koji list-history --build perl-Verilog-CodeGen-0.9.4-38.fc36 Mon Jan 3 09:12:48 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 tagged into f36-updates-candidate by jplesnik Mon Jan 3 09:12:50 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 tagged into f36-signing-pending by bodhi Mon Jan 3 09:12:55 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 untagged from f36-signing-pending by autopen Mon Jan 3 09:12:55 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 tagged into f36-updates-testing-pending by autopen Mon Jan 3 09:13:48 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 untagged from f36-updates-testing-pending by bodhi Mon Jan 3 09:13:48 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 untagged from f36-updates-candidate by bodhi Mon Jan 3 09:13:50 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 tagged into f36 by bodhi Thu Jan 6 06:18:28 2022 perl-Verilog-CodeGen-0.9.4-38.fc36 untagged from f36 by releng -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 9/13/22 21:37, Tommy Nguyen wrote: > On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote: >> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel < >> devel@lists.fedoraproject.org> wrote: >> >>> On 06/09/2022 19:49, Michael Catanzaro wrote: Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2]. > > I think most people would find it not reasonable for contributors to an > open source project to pay any amount of cash, even $25, to gain > packaging rights. That's tantamount to a membership or entrance fee. There is a huge difference between accepting contributions from someone and trusting them with access to a vast number of people’s machines. Qubes OS accepts contributions from untrusted contributors, but it can only do so because all code is reviewed by hand before merging, so a malicious contribution simply will not be accepted. Fedora, on the other hand, lacks any means to limit the blast radius of a compromised account with packaging rights. Therefore, preventing such a compromise is critical, and hardware authenticators are currently the best means of doing so. In the long term, Fedora should figure out how to avoid having to trust such a large number of people with such power. But for now, requiring **unphishable** 2FA is the best option I am aware of. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 9/14/22 03:55, Vitaly Zaitsev via devel wrote: > On 14/09/2022 08:46, Demi Marie Obenour wrote: >> The only other >> non-phishable authentication method is TLS client certificates and >> I would be fine with those. > > Fedora used to have TLS client certificate authorization (in Koji), but > this has been replaced by Kerberos. Could Fedora turn on PKINIT or make TLS client certificate authentication an option again? >> since almost every laptop has a TPM. > > In some countries (Russia, China and some other countries from the US > export banlist) hardware TPMs are prohibited. Still, even a pure software FIDO2 implementation is much better than TOTP etc. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 14/09/2022 08:46, Demi Marie Obenour wrote: The only other non-phishable authentication method is TLS client certificates and I would be fine with those. Fedora used to have TLS client certificate authorization (in Koji), but this has been replaced by Kerberos. since almost every laptop has a TPM. In some countries (Russia, China and some other countries from the US export banlist) hardware TPMs are prohibited. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 13/09/2022 23:50, Demi Marie Obenour wrote: Another option is a TPM-based authenticator. Would this be acceptable? No. TPM 2.0 chip is a *proprietary* black box. Some of them have known critical security vulnerabilities[1]. [1]: https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: glibc 2.36 and DT_HASH (preserving it for F37+)
On 14/09/2022 05:27, Neal Gompa wrote: Well, we just released the Beta and people have noticed that this is still broken. Do we have an ETA on a fix? Because this is going to be a major black eye for*us* if it stays broken through to GA. Epic Games had more than a month to fix the problem but they did nothing. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, 2022-09-14 at 02:46 -0400, Demi Marie Obenour wrote: > Because FIDO2 is not phishable. TOTP and HOTP are. The only other > non-phishable authentication method is TLS client certificates and > I would be fine with those. I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
Copr repo for Signal-Desktop owned by luminoso 561 B/s | 341 B 00:00 Errors during downloading metadata for repository 'copr:copr.fedorainfracloud.org:luminoso:Signal-Desktop': - Status code: 404 for https://download.copr.fedorainfracloud.org/results/luminoso/Signal-Desktop/fedora-37-x86_64/repodata/repomd.xml (IP: 2600:9000:248c:e400:4:bbc1:1840:93a1) Error: Failed to download metadata for repo 'copr:copr.fedorainfracloud.org:luminoso:Signal-Desktop': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Fedora 37 - x86_64 - Updates 26 kB/s | 19 kB 00:00 Fedora Modular 37 - x86_64 - Updates 30 kB/s | 19 kB 00:00 Fedora 37 - x86_64 - Test Updates 22 kB/s | 16 kB 00:00 Fedora 37 - x86_64 - Test Updates 919 kB/s | 1.4 MB 00:01 Fedora Modular 37 - x86_64 - Test Updates 16 kB/s | 13 kB 00:00 Hashicorp Stable - x86_64 476 B/s | 314 B 00:00 Errors during downloading metadata for repository 'hashicorp': - Status code: 404 for https://rpm.releases.hashicorp.com/fedora/37/x86_64/stable/repodata/repomd.xml (IP: 2600:9000:20dc:7800:18:566b:ecc0:93a1) Error: Failed to download metadata for repo 'hashicorp': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Ignoring repositories: copr:copr.fedorainfracloud.org:luminoso:Signal-Desktop, hashicorp Error: Problem: package elementary-planner-1:3.0.7-1.fc37.x86_64 requires libecal-2.0.so.1()(64bit), but none of the providers can be installed - package elementary-planner-1:3.0.7-1.fc37.x86_64 requires libedataserver-1.2.so.26()(64bit), but none of the providers can be installed - problem with installed package elementary-planner-1:3.0.7-1.fc36.x86_64 - evolution-data-server-3.44.4-1.fc36.x86_64 does not belong to a distupgrade repository - elementary-planner-1:3.0.7-1.fc36.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 9/13/22 21:37, Tommy Nguyen wrote: > On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote: >> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel < >> devel@lists.fedoraproject.org> wrote: >> >>> On 06/09/2022 19:49, Michael Catanzaro wrote: Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2]. > > I think most people would find it not reasonable for contributors to an > open source project to pay any amount of cash, even $25, to gain > packaging rights. That's tantamount to a membership or entrance fee. > > While I think this discussion has gone off the rails, here are my > thoughts: > - Why such a focus on FIDO2? It seems that nobody has discussed any > alternatives. FIDO2 isn't even necessarily universally acclaimed in the > infosec space Because FIDO2 is not phishable. TOTP and HOTP are. The only other non-phishable authentication method is TLS client certificates and I would be fine with those. > - Why such a focus on devices that cost money? I have 2FA enabled on my > phone with a free open source TOTP app Because there is no good software FIDO2 implementation. This can be solved with a TPM-backed one, since almost every laptop has a TPM. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
