[Test-Announce] 2026-06-08 @ 15:00 UTC - Fedora Quality Meeting

# Fedora Quality Assurance Meeting # Date: 2026-06-08 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting&iso=20260525T15&p1=1440&ah=1 If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 45 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 45 Rawhide 20260606.n.2 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260606.n.2. 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: anaconda - 20260603.n.0: anaconda-45.6-1.fc45.src, 20260606.n.2: anaconda-45.6-2.fc45.src kiwi - 20260603.n.0: kiwi-10.3.0-1.fc45.src, 20260606.n.2: kiwi-10.3.0-2.fc45.src lorax - 20260603.n.0: lorax-45.2-1.fc45.src, 20260606.n.2: lorax-45.2-2.fc45.src pungi - 20260603.n.0: pungi-4.13.0-1.fc45.src, 20260606.n.2: pungi-4.13.0-2.fc45.src python-blivet - 20260603.n.0: python-blivet-3.13.2-2.fc45.src, 20260606.n.2: python-blivet-3.13.2-3.fc45.src pyparted - 20260603.n.0: pyparted-3.13.0-14.fc44.src, 20260606.n.2: pyparted-3.13.0-15.fc45.src pykickstart - 20260603.n.0: pykickstart-3.73-1.fc45.src, 20260606.n.2: pykickstart-3.73-2.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 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_45_Rawhide_20260606.n.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: replica RUV communicanting by 389 port

Please excuse the mistake in my previous message; the communication on port 389 is actually from the supplier nodes to the consumer nodes, not the other way around. What could be triggering traffic on port 389 if the replication agreements are strictly configured on port 636? Note that we are running an old version of 389-ds: 389-ds-base-1.3.10.2-10. Thank you in advance for your help. Best regards -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 45 Rawhide 20260603.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260603.n.0. 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: anaconda - 20260527.n.1: anaconda-45.5-1.fc45.src, 20260603.n.0: anaconda-45.6-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 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_45_Rawhide_20260603.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes

On 5/29/26 4:45 PM, Bob Green via 389-users wrote: > On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: >> Hi Bob, >> >> The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. >> i.e calling send_all_attrs instead of send_specific_attrs >> >> in the first case it walks the attribute list of the given entry >> while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) >> >> In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) >> >> 75682 objects with 870191 attributes means around 12 attributes per entries >> ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. >> so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M >> strcasecmp are performed on 25 seconds >> Or 2.5 M strcasecmp per seconds >> IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck >> paging maybe, or other processes spending the bandwidth ? > Thank you for your analysis. I went back to take a closer look at > these ~76K objects and indeed there are approximately 77 attributes > being retrieved for each object, which makes the total attributes > retrieved when specifying all 77 explicitly a bit over 5.8 million. > When requesting all attributes the total per object is closer to 87 > attributes each. The 870191 number of total attributes I shared > initially is clearly wrong, I must have come up with this number by > parsing the output through sort | uniq which was incorrect. I'm > guessing now that I've clarified the actual number of attributes > returned from a query your strcasecmp analysis would indicate a CPU > bottleneck. Also note that the server returns values not only attributes. So if some attributes have a large set of values or large values (like jpeg, certs..) then the networks can be a bottleneck. You may redirect your search into a file to compute the amount of transfer data. > > Thank you for sharing these details. > Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes

On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: > > Hi Bob, > > The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. > i.e calling send_all_attrs instead of send_specific_attrs > > in the first case it walks the attribute list of the given entry > while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) > > In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) > > 75682 objects with 870191 attributes means around 12 attributes per entries > ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. > so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M > strcasecmp are performed on 25 seconds > Or 2.5 M strcasecmp per seconds > IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck > paging maybe, or other processes spending the bandwidth ? Thank you for your analysis. I went back to take a closer look at these ~76K objects and indeed there are approximately 77 attributes being retrieved for each object, which makes the total attributes retrieved when specifying all 77 explicitly a bit over 5.8 million. When requesting all attributes the total per object is closer to 87 attributes each. The 870191 number of total attributes I shared initially is clearly wrong, I must have come up with this number by parsing the output through sort | uniq which was incorrect. I'm guessing now that I've clarified the actual number of attributes returned from a query your strcasecmp analysis would indicate a CPU bottleneck. Thank you for sharing these details. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: retrieving 75K objects each with 77 attributes vs. all attributes

On Thu, May 28, 2026 at 3:48 PM Bob Green <wood.green.robert@gmail.com> wrote: > > On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote: > > > > Otherwise, in this case the only other option is to make sure your entry > > cache is large enough to hold all the entries. Note - running > > concurrent searches like this is not going to be performant because it > > has to process so many results. So I am not surprised the more > > concurrent searches you run the slower they all get. > > Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm > database,cn=plugins,cn=config will "automatically size" the entry > cache? I ask because dsconf INSTANCE backend monitor --suffix > dc=example,dc=com reports: > > currententrycachesize: 2818570021 > maxentrycachesize: 2818572288 > > which is just about at the maximum, though perhaps this will grow in > size as needed? Or should I replace -1 with a larger value? To answer my question, if you want to manually set your nsslapd-cachememsize attribute you must make the following ldapmodify changes: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cache-autosize nsslapd-cache-autosize: 0 dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: <new_value> Thanks again, and I apologize for my previous email which was forwarded rather than replied, due to me not noticing I had only replied to Mark and not the list previously. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new