[Bug 1980942] New: perl-Dist-Zilla-Plugin-Git-2.048 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980942

Bug ID: 1980942
   Summary: perl-Dist-Zilla-Plugin-Git-2.048 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dist-Zilla-Plugin-Git
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.048
Current version/release in rawhide: 2.047-3.fc35
URL: http://search.cpan.org/dist/Dist-Zilla-Plugin-Git/

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/13957/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  43  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef   
openjpeg2-2.3.1-11.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bd790583ee   
seamonkey-2.53.8-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4cfaa8ab63   
djvulibre-3.5.25.3-24.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

R-Rcpp-1.0.7-1.el7

Details about builds:



 R-Rcpp-1.0.7-1.el7 (FEDORA-EPEL-2021-7bcafd112f)
 Seamless R and C++ Integration

Update Information:

Rcpp 1.0.7

ChangeLog:

* Thu Jul  8 2021 Mattias Ellert  - 1.0.7-1
- Update to 1.0.7
* Mon Jun  7 2021 Tom Callaway  - 1.0.6-3
- Rebuilt for R 4.1.0
* Mon Jan 25 2021 Fedora Release Engineering  - 
1.0.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20210709.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
26 of 43 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 107/199 (x86_64), 63/138 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210706.n.0):

ID: 923096  Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/923096
ID: 923098  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/923098
ID: 923099  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/923099
ID: 923126  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/923126
ID: 923127  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/923127
ID: 923150  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/923150
ID: 923151  Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/923151
ID: 923154  Test: x86_64 Workstation-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/923154
ID: 923155  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/923155
ID: 923175  Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/923175
ID: 923176  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/923176
ID: 923196  Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/923196
ID: 923208  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/923208
ID: 923209  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start
URL: https://openqa.fedoraproject.org/tests/923209
ID: 923210  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux
URL: https://openqa.fedoraproject.org/tests/923210
ID: 923211  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging
URL: https://openqa.fedoraproject.org/tests/923211
ID: 923212  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli
URL: https://openqa.fedoraproject.org/tests/923212
ID: 923213  Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/923213
ID: 923214  Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/923214
ID: 923215  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/923215
ID: 923228  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/923228
ID: 923229  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/923229
ID: 923230  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/923230
ID: 923251  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/923251
ID: 923275  Test: aarch64 Server-raw_xz-raw.xz 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/923275
ID: 923297  Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/923297
ID: 923298  Test: aarch64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/923298
ID: 923299  Test: aarch64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/923299
ID: 923300  Test: aarch64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/923300
ID: 923301  Test: aarch64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/923301
ID: 923302  Test: aarch64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/923302
ID: 923303  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/923303
ID: 923304  Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/923304
ID: 923328  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/923328
ID: 923380  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/923380
ID: 923544  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/923544
ID: 923545  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/923545
ID: 923546  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: 

Fedora-IoT-35-20210709.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64)

New failures (same test not failed in Fedora-IoT-35-20210706.0):

ID: 923785  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/923785
ID: 923816  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/923816
ID: 923830  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/923830
ID: 923831  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/923831

Old failures (same test failed in Fedora-IoT-35-20210706.0):

ID: 923801  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/923801

Skipped non-gating openQA tests: 26 of 31
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980931] New: perl-Workflow-1.55 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980931

Bug ID: 1980931
   Summary: perl-Workflow-1.55 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Workflow
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.55
Current version/release in rawhide: 1.54-2.fc35
URL: https://metacpan.org/release/Workflow

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/17896/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Felix Schwarz]

Am 09.07.21 um 17:45 schrieb Ben Cotton:

== Detailed Description ==
The use of SHA-1 is no longer permitted for Digital Signatures or
authentication in RHEL-9. Due to this reason, there is a need to
remove SHA-1 extension from sqlite in RHEL-9 and therefore also
Fedora.


I don't think that this is a valid logical conclusion. Fedora is (should be?) 
upstream to RHEL 9 so you can disable SHA1 in RHEL 9 but keep it enabled in 
Fedora. There is certainly no "need" for this change as demonstrated by the 
various packaging changes done in RHEL.


(FWIW I don't particularly care about SHA1 functionality in sqlite.)

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980918] New: perl-Math-BigInt-1.999822 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980918

Bug ID: 1980918
   Summary: perl-Math-BigInt-1.999822 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-BigInt
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.999822
Current version/release in rawhide: 1.9998.21-1.fc35
URL: http://search.cpan.org/dist/Math-BigInt/

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/7954/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 35 Rawhide 20210709.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 35 Rawhide 20210709.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
lorax - 20210702.n.1: lorax-35.5-1.fc35.src, 20210709.n.1: lorax-35.6-1.fc35.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/35

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210709.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FAS email for authentication

[Kevin Fenzi]

On Fri, Jul 09, 2021 at 01:03:51PM -0400, Christopher wrote:
...snip...
> I used Bugzilla as an example, but I think it goes beyond Bugzilla. It
> also affects OAuth/OpenID authentication to lists.fedoraproject.org,
> pagure.io, src.fedoraproject.org, etc. I don't want to share my
> forwarding address with any of these services, because it is subject
> to change. But, the way it seems to use my forwarding address as my
> account identifier, rather than my FAS username or @fedoraproject.org
> email, seems to force me to share it with them.

I think thats pretty unique to bugzilla. Thats because for bugzilla your
email address == your account name. 
On all those other services you rightly get a account that may have your
email attached, but that email could change and you would still be the
same account. On bugzilla if that email changes it changes the account
entirely too. ;( 

> 
> >
> > In the mean time we can override this for bugzilla.
> > File a infrastructure ticket for it.
> 
> I have previously done that, and my Bugzilla account is my
> @fedoraproject.org alias. All that seems to be working if I log in
> with my Bugzilla username and password. Permissions and auto-watch and
> notifications all seem to work. I also can see the new text box in
> Fedora Accounts settings that shows it correctly. However, that
> doesn't allow me to log in via FAS, because Bugzilla still wants me to
> register a new account using my forwarding email address.

Ah ok, yes, if you are using our auth to login it will (currently) use
your email address. Once we add support for verifying the 'bugzilla
email' in the account system you should be able to put your
@fedoraproject.org in there, ack the email check and it should start
sending that to bugzilla and you can login.
> 
> > >
> > > Every FAS account has a corresponding @fedoraproject.org email alias.
> >
> > nope, they do not.
> >
> 
> I stand corrected. However, I still think that there *should* be a
> unique identifier that isn't as volatile as a forwarding email
> address, for the purposes of authenticating to FAS using OAuth, and it
> seems like it makes the most sense to have it based on the FAS user
> name, and not some field that the user can change in their FAS
> account.

again, I think this is particular to bugzilla. Most apps use account
name. 
> 
> > > Also, why doesn't the FAS OAuth login redirect page show the password
> > > and 2FA fields separately, like on the Fedora Accounts
> > > (accounts.fedoraproject.org) page? It would be much nicer on password
> > > managers, which are easily confused into thinking you've changed your
> > > password every time you manually append the 2FA code to the password.
> >
> > This is also being worked on. It turns out to be a lot harder than we
> > first thought. Hopefully that will land soon.
> 
> Okay. Thanks for your continued dedication and effort to Fedora!

Sorry this stuff is not all better yet. ;( I do hope we can improve it
all now that we have the new account system in place. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Florian Weimer]

* Ben Cotton:

> == Detailed Description ==
> The use of SHA-1 is no longer permitted for Digital Signatures or
> authentication in RHEL-9. Due to this reason, there is a need to
> remove SHA-1 extension from sqlite in RHEL-9 and therefore also
> Fedora. The removal of the extension was discussed with sqlite
> upstream development, who confirmed, that it is safe to remove it and
> should not impact other functionality of sqlite.

Why can we keep SHA-1 in coreutils and Git, but not in SQLite?  That
does not make sense to me.

SQLite is a general-purpose tool.  Not every use of SHA-1 is
cryptographically relevant.  Most uses in the context of SQLite probably
aren't, so the removal just annoys users for no good reason.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[przemek klosowski via devel]

On 7/9/21 11:48 AM, Ben Cotton wrote:

On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton  wrote:

== Upgrade/compatibility impact ==
SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
algorithm can be used.

== User Experience ==
Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
can use SHA-3 algorithm, or any other supported algorithm.


So what's the story for people who are currently using SHA-1? Is there
an upgrade path for their DBs? Will stuff just stop working?

sqlite uses SHA for checksumming the entire databases and tables (with 
the .sha3sum CLI command), and also provides it as a SQL function, 
presumably to store hashes in SQL tables. As far as I know, it hasn't 
provided the SHA1 version for a while: sqlite-3.34.1-2.fc34 seems to 
only provide the sha3 256-bit versions.


I think that people who used SHA1 must have developed workarounds already.

Having said that, I personally didn't use SHA in sqlite so I may be 
missing something.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Robert Marcano via devel]

On 7/9/21 11:45 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1

== Summary ==
Removal of deprecated crypto algorithm SHA-1 from sqlite.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com


== Detailed Description ==
The use of SHA-1 is no longer permitted for Digital Signatures or
authentication in RHEL-9. Due to this reason, there is a need to
remove SHA-1 extension from sqlite in RHEL-9 and therefore also
Fedora. The removal of the extension was discussed with sqlite
upstream development, who confirmed, that it is safe to remove it and
should not impact other functionality of sqlite.


== Benefit to Fedora ==
This change brings update in terms of removing usage of deprecated
crypto algorithms as users should not use them. Also it keeps Fedora
project up-to-date with the newest RHEL release, what is beneficial
for future releases.


Why is this a remove proposal and not a default disabling via crypto 
policies. Will RHEL-9 remove SHA1 code from Java and other developer 
tools too instead of the current default disabled?




== Scope ==
* Proposal owners:
** Prepare patch for removing SHA-1 algorithm from sqlite
** Discuss the possible issues with upstream
** Push the changes to Fedora

* Other developers:  Do not use SHA-1 algorithm in sqlite

* Release engineering: No further coordination is required for this change

* Policies and guidelines: No guidelines need to be updated according
to this change
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
algorithm can be used.

== How To Test ==
No special testing is required for this change.

== User Experience ==
Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
can use SHA-3 algorithm, or any other supported algorithm.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==
Sqlite documentation: https://www.sqlite.org/docs.html

Discussion with upstream about removing SHA-1 algorithm:
https://sqlite.org/forum/forumpost/de1c4a92f3





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Hans de Goede]

Hi,

On 7/9/21 6:56 PM, Ben Beasley wrote:
> Hans,
> 
> Thanks for noticing, and for your very reasonable question.
> 
> In all of these cases, the CC0 component was due to the AppData XML file for 
> a desktop application. (In libinstpatch, the Public Domain component was due 
> to md5-plumb “copylib” source files that are linked into the library.)
> 
> I’ve retained the pre-existing detailed comments in the spec files, so there 
> is still some record of per-file licensing for the curious.
> 
> -
> 
> Your interpretation of preserving separate license terms in the License field 
> when they apply to separate installed files seems to be supported by 
> https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F,
>  at least in the case of separate compiled binaries. However, there was a big 
> discussion about effective licensing on the fedora-devel list a month or two 
> ago (and, a little earlier, a question on fedora-legal) specifically 
> concerning CC0-licensed AppData XML files.
> 
> I recall that all parties who spoke up felt it was correct to form an 
> effective license that did not mention CC0 in this case. As far as I know, 
> everyone understood that the AppData is installed as a separate XML file 
> asset and not linked into the code. Some seemed to feel that leaving CC0 in 
> the License field rather than forming a simpler effective license is actually 
> *wrong* and should not be allowed, an opinion I don’t share but don’t care to 
> debate.> 
> -
> 
> I am hoping not to initiate a broader discussion of when it is and isn’t 
> reasonable to expect packagers to derive effective licenses. Suffice it to 
> say that, in these specific simple cases, I think the changes are clearly 
> consistent with the community consensus, such as it is, and with guidance 
> from fedora-legal.

Not listing the CC0 in case when it is only used for the appdata xml file seems 
reasonable to me. In this case the intent of the author of the file clearly was 
to give as broad a license as possible (1), so I think that not listing it 
separately is fine for appdata xml files (still not a lawyer, etc.).

1) arguably CC0 always indicates the author is trying to not claim any rights 
in so far possible, but that is a separate discussion.

Regards,

Hans



> On 7/9/21 10:07 AM, Hans de Goede wrote:
>> Hi Benjamin,
>>
>> On 7/9/21 3:47 PM, Benjamin Beasley wrote:
>>> I’ve updated several of my packages to use only the “effective license” in 
>>> their License fields, in cases where it was very clear that a single 
>>> effective license was correct. The following packages are affected:
>>>
>>> - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>>> - appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
>>> - gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
>>> - harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>>> - libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
>>> - notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>>> - sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>>
>> In general this is the right thing to do, thank you for simplifying
>> the License field for these packages.
>>
>> One remark about this tough, I wonder what files the CC0 licenses
>> were for ?
>>
>> Sometimes acceptable CC licenses (typically other ones then CC0)
>> are used for assets, like icons / artwork / docs.
>>
>> In that case, since those assets are not linked into a resulting
>> binary the assets stay under the CC license (AFAIK, IANAL, etc.).
>>
>> So if that is the case for any of the above packages then the new
>> License field should still include the "and CC0", with the binaries
>> being under the GPL variant and the assets being under CC0.
>>
>> This is typically documented with a comment in the .spec above the
>> License field explaining things.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>
>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>> Do not reply to spam on the list, report it: 
>>> https://pagure.io/fedora-infrastructure
>>>
>>
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FAS email for authentication

[Stephen John Smoogen]

On Fri, 9 Jul 2021 at 13:04, Christopher  wrote:
>
> On Fri, Jul 9, 2021 at 11:44 AM Kevin Fenzi  wrote:
> >
> > On Fri, Jul 09, 2021 at 11:13:19AM -0400, Christopher wrote:
> > > Why does FAS use the email forwarding address when I use it to
> > > authenticate, rather than the permanent @fedoraproject.org alias for
> > > the address?
> >
> > Because only "contributors" (ie, people in at least one non cla group)
> > have @fedoraproject.org aliases.
>
> Ah, I forgot about this. Maybe this should be reconsidered, but either
> way, this was my misunderstanding. Sorry, and thanks for reminding me.
>

There are several hundred thousand most likely 'spam' accounts which
would get aliases in that case. There are a lot of spam groups which
open accounts with Fedora and then try to pipe their crap through us
thinking they get a free alias and free giant email server. I would
expect that if we did this, we would have to drop email aliases
altogether and/or find all @fedoraproject.org email addresses at the
top of every spamblock list.




-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FAS email for authentication

[Christopher]

On Fri, Jul 9, 2021 at 11:44 AM Kevin Fenzi  wrote:
>
> On Fri, Jul 09, 2021 at 11:13:19AM -0400, Christopher wrote:
> > Why does FAS use the email forwarding address when I use it to
> > authenticate, rather than the permanent @fedoraproject.org alias for
> > the address?
>
> Because only "contributors" (ie, people in at least one non cla group)
> have @fedoraproject.org aliases.

Ah, I forgot about this. Maybe this should be reconsidered, but either
way, this was my misunderstanding. Sorry, and thanks for reminding me.

>
> > I should be able to change my forwarding address without changing how
> > authentication works. However, it looks like if I change my forwarding
> > address, then try to use FAS to log in to Bugzilla, it would tell me
> > that there is no account for  and asks if I want
> > to register. This currently happens when I try to log in with FAS,
> > because I registered my bugzilla account using my
> > ctubb...@fedoraproject.org alias instead. Obviously, I don't want to
> > create a new account if I change my forwarding address. I can't
> > imagine ever wanting to authenticate using my forwarding address,
> > rather than my Fedora alias for accessing Fedora systems, because my
> > forwarding address is subject to change.
>
> We are working on this with the new account system. It has a 'bugzilla
> email address' field. However, we need to put in place verification of
> those addresses before we enable it on our side/in bugzilla.
> Once thats there you should be able to put your fedoraproject.org
> address in there.

I used Bugzilla as an example, but I think it goes beyond Bugzilla. It
also affects OAuth/OpenID authentication to lists.fedoraproject.org,
pagure.io, src.fedoraproject.org, etc. I don't want to share my
forwarding address with any of these services, because it is subject
to change. But, the way it seems to use my forwarding address as my
account identifier, rather than my FAS username or @fedoraproject.org
email, seems to force me to share it with them.

>
> In the mean time we can override this for bugzilla.
> File a infrastructure ticket for it.

I have previously done that, and my Bugzilla account is my
@fedoraproject.org alias. All that seems to be working if I log in
with my Bugzilla username and password. Permissions and auto-watch and
notifications all seem to work. I also can see the new text box in
Fedora Accounts settings that shows it correctly. However, that
doesn't allow me to log in via FAS, because Bugzilla still wants me to
register a new account using my forwarding email address.

> >
> > Every FAS account has a corresponding @fedoraproject.org email alias.
>
> nope, they do not.
>

I stand corrected. However, I still think that there *should* be a
unique identifier that isn't as volatile as a forwarding email
address, for the purposes of authenticating to FAS using OAuth, and it
seems like it makes the most sense to have it based on the FAS user
name, and not some field that the user can change in their FAS
account.

> > Also, why doesn't the FAS OAuth login redirect page show the password
> > and 2FA fields separately, like on the Fedora Accounts
> > (accounts.fedoraproject.org) page? It would be much nicer on password
> > managers, which are easily confused into thinking you've changed your
> > password every time you manually append the 2FA code to the password.
>
> This is also being worked on. It turns out to be a lot harder than we
> first thought. Hopefully that will land soon.

Okay. Thanks for your continued dedication and effort to Fedora!

>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Ben Beasley]

Hans,

Thanks for noticing, and for your very reasonable question.

In all of these cases, the CC0 component was due to the AppData XML file 
for a desktop application. (In libinstpatch, the Public Domain component 
was due to md5-plumb “copylib” source files that are linked into the 
library.)


I’ve retained the pre-existing detailed comments in the spec files, so 
there is still some record of per-file licensing for the curious.


-

Your interpretation of preserving separate license terms in the License 
field when they apply to separate installed files seems to be supported 
by 
https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F, 
at least in the case of separate compiled binaries. However, there was a 
big discussion about effective licensing on the fedora-devel list a 
month or two ago (and, a little earlier, a question on fedora-legal) 
specifically concerning CC0-licensed AppData XML files.


I recall that all parties who spoke up felt it was correct to form an 
effective license that did not mention CC0 in this case. As far as I 
know, everyone understood that the AppData is installed as a separate 
XML file asset and not linked into the code. Some seemed to feel that 
leaving CC0 in the License field rather than forming a simpler effective 
license is actually *wrong* and should not be allowed, an opinion I 
don’t share but don’t care to debate.


-

I am hoping not to initiate a broader discussion of when it is and isn’t 
reasonable to expect packagers to derive effective licenses. Suffice it 
to say that, in these specific simple cases, I think the changes are 
clearly consistent with the community consensus, such as it is, and with 
guidance from fedora-legal.


Regards,

Ben Beasley

On 7/9/21 10:07 AM, Hans de Goede wrote:
> Hi Benjamin,
>
> On 7/9/21 3:47 PM, Benjamin Beasley wrote:
>> I’ve updated several of my packages to use only the “effective 
license” in their License fields, in cases where it was very clear that 
a single effective license was correct. The following packages are affected:

>>
>> - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>> - appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
>> - gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
>> - harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>> - libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
>> - notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>> - sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>
> In general this is the right thing to do, thank you for simplifying
> the License field for these packages.
>
> One remark about this tough, I wonder what files the CC0 licenses
> were for ?
>
> Sometimes acceptable CC licenses (typically other ones then CC0)
> are used for assets, like icons / artwork / docs.
>
> In that case, since those assets are not linked into a resulting
> binary the assets stay under the CC license (AFAIK, IANAL, etc.).
>
> So if that is the case for any of the above packages then the new
> License field should still include the "and CC0", with the binaries
> being under the GPL variant and the assets being under CC0.
>
> This is typically documented with a comment in the .spec above the
> License field explaining things.
>
> Regards,
>
> Hans
>
>
>
>
>
>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Ben Cotton]

On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton  wrote:
>
> == Upgrade/compatibility impact ==
> SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
> algorithm can be used.
>
> == User Experience ==
> Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
> can use SHA-3 algorithm, or any other supported algorithm.
>
So what's the story for people who are currently using SHA-1? Is there
an upgrade path for their DBs? Will stuff just stop working?

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1

== Summary ==
Removal of deprecated crypto algorithm SHA-1 from sqlite.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com


== Detailed Description ==
The use of SHA-1 is no longer permitted for Digital Signatures or
authentication in RHEL-9. Due to this reason, there is a need to
remove SHA-1 extension from sqlite in RHEL-9 and therefore also
Fedora. The removal of the extension was discussed with sqlite
upstream development, who confirmed, that it is safe to remove it and
should not impact other functionality of sqlite.


== Benefit to Fedora ==
This change brings update in terms of removing usage of deprecated
crypto algorithms as users should not use them. Also it keeps Fedora
project up-to-date with the newest RHEL release, what is beneficial
for future releases.

== Scope ==
* Proposal owners:
** Prepare patch for removing SHA-1 algorithm from sqlite
** Discuss the possible issues with upstream
** Push the changes to Fedora

* Other developers:  Do not use SHA-1 algorithm in sqlite

* Release engineering: No further coordination is required for this change

* Policies and guidelines: No guidelines need to be updated according
to this change
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
algorithm can be used.

== How To Test ==
No special testing is required for this change.

== User Experience ==
Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
can use SHA-3 algorithm, or any other supported algorithm.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==
Sqlite documentation: https://www.sqlite.org/docs.html

Discussion with upstream about removing SHA-1 algorithm:
https://sqlite.org/forum/forumpost/de1c4a92f3




-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1

== Summary ==
Removal of deprecated crypto algorithm SHA-1 from sqlite.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com


== Detailed Description ==
The use of SHA-1 is no longer permitted for Digital Signatures or
authentication in RHEL-9. Due to this reason, there is a need to
remove SHA-1 extension from sqlite in RHEL-9 and therefore also
Fedora. The removal of the extension was discussed with sqlite
upstream development, who confirmed, that it is safe to remove it and
should not impact other functionality of sqlite.


== Benefit to Fedora ==
This change brings update in terms of removing usage of deprecated
crypto algorithms as users should not use them. Also it keeps Fedora
project up-to-date with the newest RHEL release, what is beneficial
for future releases.

== Scope ==
* Proposal owners:
** Prepare patch for removing SHA-1 algorithm from sqlite
** Discuss the possible issues with upstream
** Push the changes to Fedora

* Other developers:  Do not use SHA-1 algorithm in sqlite

* Release engineering: No further coordination is required for this change

* Policies and guidelines: No guidelines need to be updated according
to this change
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
SHA-1 algorithm will not be supported in sqlite. Instead SHA-3
algorithm can be used.

== How To Test ==
No special testing is required for this change.

== User Experience ==
Users won't be able to use SHA-1 algorithm with sqlite. Instead, they
can use SHA-3 algorithm, or any other supported algorithm.

== Dependencies ==


== Contingency Plan ==

* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==
Sqlite documentation: https://www.sqlite.org/docs.html

Discussion with upstream about removing SHA-1 algorithm:
https://sqlite.org/forum/forumpost/de1c4a92f3




-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: pyproject-rpm-macros can now install Python BuildRequires from requirements files

[Major Hayden]

On 7/9/21 10:41 AM, Tomas Hrnciar wrote:
%pyproject_buildrequires macro can now optionally take file names as 
positionalargumentsand generate additionalbuilddependencies from them. 
You can supply multiple file names to %pyproject_buildrequires macro. E.g.:

|
|
|  %generate_buildrequires|
|%pyproject_buildrequires requirements/tests.in  
requirements/docs.in |

|
|
This adds the requirements listed in the files as python3dist(...) 
BuildRequires. Other usages of %pyproject_buildrequires remains the same 
as before.


This is *super* exciting and another time saver. Thanks to everyone 
involved in making this happen! 


--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FAS email for authentication

[Kevin Fenzi]

On Fri, Jul 09, 2021 at 11:13:19AM -0400, Christopher wrote:
> Why does FAS use the email forwarding address when I use it to
> authenticate, rather than the permanent @fedoraproject.org alias for
> the address?

Because only "contributors" (ie, people in at least one non cla group)
have @fedoraproject.org aliases. 

> I should be able to change my forwarding address without changing how
> authentication works. However, it looks like if I change my forwarding
> address, then try to use FAS to log in to Bugzilla, it would tell me
> that there is no account for  and asks if I want
> to register. This currently happens when I try to log in with FAS,
> because I registered my bugzilla account using my
> ctubb...@fedoraproject.org alias instead. Obviously, I don't want to
> create a new account if I change my forwarding address. I can't
> imagine ever wanting to authenticate using my forwarding address,
> rather than my Fedora alias for accessing Fedora systems, because my
> forwarding address is subject to change.

We are working on this with the new account system. It has a 'bugzilla
email address' field. However, we need to put in place verification of
those addresses before we enable it on our side/in bugzilla. 
Once thats there you should be able to put your fedoraproject.org
address in there. 

In the mean time we can override this for bugzilla. 
File a infrastructure ticket for it.
> 
> Every FAS account has a corresponding @fedoraproject.org email alias.

nope, they do not.

> So, why doesn't FAS use that? In my opinion, it should, and to make it
> clear, the Fedora Accounts profile page should be changed to have a
> grayed out field for Email that shows your @fedoraproject.org email
> alias, in addition to the Email field that you can edit to update your
> registered/forwarding address.
> 
> Also, why doesn't the FAS OAuth login redirect page show the password
> and 2FA fields separately, like on the Fedora Accounts
> (accounts.fedoraproject.org) page? It would be much nicer on password
> managers, which are easily confused into thinking you've changed your
> password every time you manually append the 2FA code to the password.

This is also being worked on. It turns out to be a lot harder than we
first thought. Hopefully that will land soon. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

pyproject-rpm-macros can now install Python BuildRequires from requirements files

[Tomas Hrnciar]

Hello,
a new version of pyproject-rpm-macros (0-43) landed in Rawhide. I'll try to
briefly summarize what is new.

%pyproject_buildrequires macro can now optionally take file names as
positional arguments and generate additional build dependencies from them.
You can supply multiple file names to %pyproject_buildrequires macro. E.g.:

  %generate_buildrequires
  %pyproject_buildrequires requirements/tests.in requirements/docs.in

This adds the requirements listed in the files as python3dist(...)
BuildRequires. Other usages of %pyproject_buildrequires remains the same as
before.

In case you want to use this feature without using the Python build system
(PEP517/setup.py) you can use a new -N (i.e. "No build system") option to
only install the dependencies from the provided files. With -N, any other
automatic generation of requirements is entirely disabled. -N option cannot
be used in combination with other %pyproject_buildrequires options (-r, -e,
-t, -x). In order to use the -N option, you need to have
pyproject-rpm-macros >= 0-43 installed on your developer machine as well
(or no version of that package at all).

Updates are ready for Fedora 33 and 34:

F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5476e05676
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc2936539e

Backport for CentOS Stream 9 can be found here:

https://gitlab.com/redhat/centos-stream/rpms/pyproject-rpm-macros/-/merge_requests/4

Regards,
Tomáš Hrnčiar
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

pyproject-rpm-macros can now install Python BuildRequires from requirements files

[Tomas Hrnciar]

Hello,
a new version of pyproject-rpm-macros (0-43) landed in Rawhide. I'll try to
briefly summarize what is new.

%pyproject_buildrequires macro can now optionally take file names as
positional arguments and generate additional build dependencies from them.
You can supply multiple file names to %pyproject_buildrequires macro. E.g.:

  %generate_buildrequires
  %pyproject_buildrequires requirements/tests.in requirements/docs.in

This adds the requirements listed in the files as python3dist(...)
BuildRequires. Other usages of %pyproject_buildrequires remains the same as
before.

In case you want to use this feature without using the Python build system
(PEP517/setup.py) you can use a new -N (i.e. "No build system") option to
only install the dependencies from the provided files. With -N, any other
automatic generation of requirements is entirely disabled. -N option cannot
be used in combination with other %pyproject_buildrequires options (-r, -e,
-t, -x). In order to use the -N option, you need to have
pyproject-rpm-macros >= 0-43 installed on your developer machine as well
(or no version of that package at all).

Updates are ready for Fedora 33 and 34:

F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5476e05676
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc2936539e

Backport for CentOS Stream 9 can be found here:

https://gitlab.com/redhat/centos-stream/rpms/pyproject-rpm-macros/-/merge_requests/4

Regards,
Tomáš Hrnčiar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FAS email for authentication

[Pierre-Yves Chibon]

On Fri, Jul 09, 2021 at 11:13:19AM -0400, Christopher wrote:
> Why does FAS use the email forwarding address when I use it to
> authenticate, rather than the permanent @fedoraproject.org alias for
> the address?
> 
> I should be able to change my forwarding address without changing how
> authentication works. However, it looks like if I change my forwarding
> address, then try to use FAS to log in to Bugzilla, it would tell me
> that there is no account for  and asks if I want
> to register. This currently happens when I try to log in with FAS,
> because I registered my bugzilla account using my
> ctubb...@fedoraproject.org alias instead. Obviously, I don't want to
> create a new account if I change my forwarding address. I can't
> imagine ever wanting to authenticate using my forwarding address,
> rather than my Fedora alias for accessing Fedora systems, because my
> forwarding address is subject to change.
> 
> Every FAS account has a corresponding @fedoraproject.org email alias.

There is the invalid assumption :)
You need to be in one group and have signed the FPCA to have the alias.
You can see have a FAS account and do contribution (for examples to projects
hosted on pagure.io) without either of these requirements.



Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

FAS email for authentication

[Christopher]

Why does FAS use the email forwarding address when I use it to
authenticate, rather than the permanent @fedoraproject.org alias for
the address?

I should be able to change my forwarding address without changing how
authentication works. However, it looks like if I change my forwarding
address, then try to use FAS to log in to Bugzilla, it would tell me
that there is no account for  and asks if I want
to register. This currently happens when I try to log in with FAS,
because I registered my bugzilla account using my
ctubb...@fedoraproject.org alias instead. Obviously, I don't want to
create a new account if I change my forwarding address. I can't
imagine ever wanting to authenticate using my forwarding address,
rather than my Fedora alias for accessing Fedora systems, because my
forwarding address is subject to change.

Every FAS account has a corresponding @fedoraproject.org email alias.
So, why doesn't FAS use that? In my opinion, it should, and to make it
clear, the Fedora Accounts profile page should be changed to have a
grayed out field for Email that shows your @fedoraproject.org email
alias, in addition to the Email field that you can edit to update your
registered/forwarding address.

Also, why doesn't the FAS OAuth login redirect page show the password
and 2FA fields separately, like on the Fedora Accounts
(accounts.fedoraproject.org) page? It would be much nicer on password
managers, which are easily confused into thinking you've changed your
password every time you manually append the 2FA code to the password.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Hans de Goede]

Hi Benjamin,

On 7/9/21 3:47 PM, Benjamin Beasley wrote:
> I’ve updated several of my packages to use only the “effective license” in 
> their License fields, in cases where it was very clear that a single 
> effective license was correct. The following packages are affected:
> 
> - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
> - appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
> - gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
> - harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
> - libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
> - notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
> - sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”

In general this is the right thing to do, thank you for simplifying
the License field for these packages.

One remark about this tough, I wonder what files the CC0 licenses
were for ?

Sometimes acceptable CC licenses (typically other ones then CC0)
are used for assets, like icons / artwork / docs.

In that case, since those assets are not linked into a resulting
binary the assets stay under the CC license (AFAIK, IANAL, etc.).

So if that is the case for any of the above packages then the new
License field should still include the "and CC0", with the binaries
being under the GPL variant and the assets being under CC0.

This is typically documented with a comment in the .spec above the
License field explaining things.

Regards,

Hans






> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] 300s delay when query cn=monitor

[Erwin Weitlaner]

We are using 389-Directory/1.3.10.2 B2021.127.856 (we will update next month) 
.. a monitor script queries with basedn cn=monitor and filter (objectClass=*) 
every minute. This query returned in <10ms for years. Since two weeks under 
unknown circumstances this query lasts up to 300s (one or two times per day). 
The other queries work fine (no delay). Any ideas what could block the answer? 

SG erwin

The 'bad' log entry:
[09/Jul/2021:06:54:01.203812923 +0200] conn=962307 SRCH type=srch op=1 
base="cn=monitor" scope=2 filter="(objectClass=*)" attrs="ALL" RESULT op=1 
err=0 errname=success tag=101 nentries=3 optime=250.179697410 wtime=0.62324 
etime=250.179757740 CONNECTION fd=4201 slot=4201 from=127.0.0.1 to=127.0.0.1 
ssl=false binddn="cn=directory manager" method=128 version=3 op=1

The 'normal' log entry:
[09/Jul/2021:06:52:01.797036360 +0200] conn=96 SRCH type=srch op=1 
base="cn=monitor" scope=2 filter="(objectClass=*)" attrs="ALL" RESULT op=1 
err=0 errname=success tag=101 nentries=3 optime=0.002609889 wtime=0.57307 
etime=0.002665406 CONNECTION fd=4199 slot=4199 from=127.0.0.1 to=127.0.0.1 
ssl=false binddn="cn=directory manager" method=128 version=3 op=1
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Benjamin Beasley]

I’ve updated several of my packages to use only the “effective license” in 
their License fields, in cases where it was very clear that a single effective 
license was correct. The following packages are affected:

- agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
- appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
- gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
- harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
- notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review swap: fluent-bit

[Benjamin Kircher]

On Fri, 2021-07-09 at 08:04 -0400, Neal Gompa wrote:
> On Fri, Jul 9, 2021 at 7:54 AM Benjamin Kircher 
> wrote:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1980723
> > 
> > Fluent Bit is a high performance and multi-platform log forwarder:
> > https://github.com/fluent/fluent-bit. It is written in C++ and uses
> > CMake as build system.
> > 
> > Happy to do reviews for other packages of similar complexity
> > (Python,
> > Go, C++, Rust, meson/C).
> > 
> 
> I'll take the review, though I don't have anything of similar
> complexity right now to review swap.

Many thanks!

BK

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review swap: fluent-bit

[Neal Gompa]

On Fri, Jul 9, 2021 at 7:54 AM Benjamin Kircher  wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1980723
>
> Fluent Bit is a high performance and multi-platform log forwarder:
> https://github.com/fluent/fluent-bit. It is written in C++ and uses
> CMake as build system.
>
> Happy to do reviews for other packages of similar complexity (Python,
> Go, C++, Rust, meson/C).
>

I'll take the review, though I don't have anything of similar
complexity right now to review swap.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Review swap: fluent-bit

[Benjamin Kircher]

https://bugzilla.redhat.com/show_bug.cgi?id=1980723

Fluent Bit is a high performance and multi-platform log forwarder:
https://github.com/fluent/fluent-bit. It is written in C++ and uses
CMake as build system.

Happy to do reviews for other packages of similar complexity (Python,
Go, C++, Rust, meson/C).

BK
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Major update of Python packages next week: Flask 2.0, Werkzeug 2.0, Jinja 3.0, ItsDangerous 2.0, and MarkupSafe 2.0

[Miro Hrončok]

Hello Fedorans and especially Pythonistas,

we plan to marge and ship the following upgrades in Rawhide next week:

https://src.fedoraproject.org/rpms/python-flask/pull-request/8
https://src.fedoraproject.org/rpms/python-werkzeug/pull-request/8
https://src.fedoraproject.org/rpms/python-jinja2/pull-request/9
https://src.fedoraproject.org/rpms/python-itsdangerous/pull-request/2
https://src.fedoraproject.org/rpms/python-markupsafe/pull-request/6

The packages come from the Pallets Projects stack and you can read all about 
the upgrade in https://palletsprojects.com/blog/flask-2-0-released/


(Note that Click was alrady upgraded to 8.0 a while ago.)

This breaks some packages, but not a large stack:

https://src.fedoraproject.org/rpms/python-flask/pull-request/8#comment-0
https://src.fedoraproject.org/rpms/python-flask/pull-request/8#comment-80471

Don't hesitate to ask for help if this breaks your package.
There should always be a path forward.
If not, compat packages can be introduced as a last resort
(and I can help with the initial packging of those if needed).

Thanks for your attention,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Major update of Python packages next week: Flask 2.0, Werkzeug 2.0, Jinja 3.0, ItsDangerous 2.0, and MarkupSafe 2.0

[Miro Hrončok]

Hello Fedorans and especially Pythonistas,

we plan to marge and ship the following upgrades in Rawhide next week:

https://src.fedoraproject.org/rpms/python-flask/pull-request/8
https://src.fedoraproject.org/rpms/python-werkzeug/pull-request/8
https://src.fedoraproject.org/rpms/python-jinja2/pull-request/9
https://src.fedoraproject.org/rpms/python-itsdangerous/pull-request/2
https://src.fedoraproject.org/rpms/python-markupsafe/pull-request/6

The packages come from the Pallets Projects stack and you can read all about 
the upgrade in https://palletsprojects.com/blog/flask-2-0-released/


(Note that Click was alrady upgraded to 8.0 a while ago.)

This breaks some packages, but not a large stack:

https://src.fedoraproject.org/rpms/python-flask/pull-request/8#comment-0
https://src.fedoraproject.org/rpms/python-flask/pull-request/8#comment-80471

Don't hesitate to ask for help if this breaks your package.
There should always be a path forward.
If not, compat packages can be introduced as a last resort
(and I can help with the initial packging of those if needed).

Thanks for your attention,
--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] Re: 300s delay when query cn=monitor

[Thierry Bordaz]

Hi,

I would suspect the dump of the opened connections status to be the RC 
of that delay. If the monitor thread can not acquire the connection 
lock, it will delay the request. So I would suspect a connection timeout 
(5min) to hang the monitoring thread, for example if a ldapclient is not 
reading while the server tries to send it some data.


As it is hanging for 5min, when it occurs you may run a pstack showing 
what the threads are doing.


regards
thierry

On 7/9/21 11:51 AM, Erwin Weitlaner wrote:

We are using 389-Directory/1.3.10.2 B2021.127.856 (we will update next month) .. a 
monitor script queries with basedn cn=monitor and filter (objectClass=*) every 
minute. This query returned in <10ms for years. Since two weeks under unknown 
circumstances this query lasts up to 300s (one or two times per day). The other 
queries work fine (no delay). Any ideas what could block the answer?

SG erwin

The 'bad' log entry:
[09/Jul/2021:06:54:01.203812923 +0200] conn=962307 SRCH type=srch op=1 base="cn=monitor" scope=2 
filter="(objectClass=*)" attrs="ALL" RESULT op=1 err=0 errname=success tag=101 nentries=3 
optime=250.179697410 wtime=0.62324 etime=250.179757740 CONNECTION fd=4201 slot=4201 from=127.0.0.1 to=127.0.0.1 
ssl=false binddn="cn=directory manager" method=128 version=3 op=1

The 'normal' log entry:
[09/Jul/2021:06:52:01.797036360 +0200] conn=96 SRCH type=srch op=1 base="cn=monitor" scope=2 
filter="(objectClass=*)" attrs="ALL" RESULT op=1 err=0 errname=success tag=101 nentries=3 
optime=0.002609889 wtime=0.57307 etime=0.002665406 CONNECTION fd=4199 slot=4199 from=127.0.0.1 to=127.0.0.1 
ssl=false binddn="cn=directory manager" method=128 version=3 op=1
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980686] New: Upgrade perl-JSON-Path to 0.5

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980686

Bug ID: 1980686
   Summary: Upgrade perl-JSON-Path to 0.5
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JSON-Path
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.431 version. Upstream released 0.5. When you have free
time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980682] New: Upgrade perl-Data-GUID to 0.050

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980682

Bug ID: 1980682
   Summary: Upgrade perl-Data-GUID to 0.050
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Data-GUID
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.049 version. Upstream released 0.050. When you have
free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980474] perl-Test-Timer-2.12 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980474

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Timer-2.12-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-07-09 09:08:54




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Test-Timer] PR #1: Tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Test-Timer` that you 
are following.

Merged pull-request:

``
Tests
``

https://src.fedoraproject.org/rpms/perl-Test-Timer/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Test-Timer] PR #1: Tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Test-Timer` that 
you are following:
``
Tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Test-Timer/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980474] perl-Test-Timer-2.12 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980474

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Bochecha unavailable for a little while

[Pierre-Yves Chibon]

Good Morning Everyone,

I am in contact with bochecha who has asked me that I announce his
un-availability for personal reason for a little while.
To this end, he has orphaned the package "buildstream" on Wednesday. There may
be more coming.

Bochecha still wants to come back to Fedora once things have settled down but he
didn't want for anything to wait on him while he is not available.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ibus-typing-boster - testcase instruction error

[Mike FABIAN]

Yes, python3-pyhunspell is only another option of python3-enchant is not 
available (for example on FreeBSD that is the case)

> ModuleNotFoundError: No module named 'packaging'

This can be workarounded by

dnf install python3-packaging

But I added it to the requirements in the ibus-typing-booster.spec file now:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3ba1c0d71
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure