[Bug 1895493] perl-Crypt-OpenSSL-X509-1.902 is available

[bugzilla]

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



--- Comment #4 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Crypt-OpenSSL-X509-1.902-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=55436422


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

[Bug 1895493] perl-Crypt-OpenSSL-X509-1.902 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Crypt-OpenSSL-X509-1.9 |perl-Crypt-OpenSSL-X509-1.9
   |01 is available |02 is available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.902
Current version/release in rawhide: 1.901-1.fc34
URL: http://search.cpan.org/dist/Crypt-OpenSSL-X509/

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


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

[Bug 1895493] perl-Crypt-OpenSSL-X509-1.902 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Created attachment 1728635
  --> https://bugzilla.redhat.com/attachment.cgi?id=1728635=edit
[patch] Update to 1.902 (#1895493)


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

Fedora-Cloud-33-20201112.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-2020.0):

ID: 721130  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/721130
ID: 721137  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/721137

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-11-12 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/12/report-389-ds-base-2.0.1-20201112gitca8ac8e.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1893136] RFE - build a perl-Future package for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-ba89c0dcc2 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ba89c0dcc2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

[Bug 1890896] Add perl-File-Map to EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-8a24651ea4 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8a24651ea4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

[Bug 1890589] EPEL8 Request: perl-Config-GitLike

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-262a44f93d has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-262a44f93d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e816cf1fbc   
containerd-1.2.14-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a5abe545c6   
wordpress-5.1.8-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-aeaf0b9bc0   
pngcheck-2.4.0-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f16789146a   
chromium-86.0.4240.183-1.el7


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

IP2Location-8.3.1+1-1.el7
annobin-9.41-1.el7
boinc-client-7.16.11-3.el7
mock-core-configs-33.2-1.el7

Details about builds:



 IP2Location-8.3.1+1-1.el7 (FEDORA-EPEL-2020-f587448f31)
 Tools for mapping IP address to geolocation information

Update Information:

update to 8.3.1-1 to fix library version in headers    update to 8.3.1

ChangeLog:

* Tue Nov 10 2020 Remi Collet  - 8.3.1+1-1
- update to 8.3.1-1 to fix library version in headers
- fix missing perl dependencies
* Mon Nov  9 2020 Remi Collet  - 8.3.1-4
- move library in libs subpackage
* Mon Nov  9 2020 Peter Bieringer  - 8.3.1-3
- update to 8.3.1
* Sat Nov  7 2020 Peter Bieringer  - 8.3.0-2
- update to commit 7b074becd59cf8c574190e49ce097640a2cfefd7
- add new 'ip2location' binary
* Fri Oct 30 2020 Remi Collet  - 8.3.0-1
- update to 8.3.0




 annobin-9.41-1.el7 (FEDORA-EPEL-2020-e47e07aad0)
 Annotate and examine compiled binary files

Update Information:

An updated version of annobin, including a version of annocheck that does not
generate internal errors when examining ppc64le binaries.

ChangeLog:

* Tue Nov 10 2020 Nick Clifton  - 9.41-1
- Annocheck: Handle gimple compiled binaries.
* Mon Nov  9 2020 Nick Clifton  - 9.38-1
- Rebase to 9.39
- Annocheck: Add fixes for building on RHEL-7.
- Annocheck: Fix bug parsing DW_AT_producer.
- Add test of .note.gnu.property section for PowerPC.
- Add test of objcopy's ability to merge notes.
- Record the -flto setting and produce a soft warning if it is absent.
- Suppress warnings about _D_GLIBCXX_ASSERTIONS if the source code is known to 
be something other than C++.
- Correct the directory chosen for 32-bit LLVM and Clang plugins.  (#1884951)
- Allow the use of the SHF_LINK_ORDER section flag to discard unused notes.  
(Experimental).
- Enable the build and installation of the LLVM and Clang plugins.  
(Experimental).
- gcc-plugin: Fix test for empty PowerPC sections.  (#1880634)
- annocheck: Add tests for the AArch64 BTI and PAC security features.  
(#1862478)
- gcc plugin: Use a 4 byte offset for PowerPC start symbols, so that they do 
not break disassemblies.
- gcc plugin: Correct the detection of 32-bit x86 builds.  (#1876197)
- gcc plugin: Detect any attempt to access the global_options array.
- gcc plugin: Do not complain about missing pre-processor options when 
examining a preprocessed input file.  (#1862718)
- Use more robust checks for AArch64 options.
- Detect CLANG compiled assembler that is missing IBT support.
- Improved target pointer size discovery.
- Rebuild with plugin enabled to check that suppression works.
- Add support for installing clang and llvm plugins.
- Temporary suppression of aarch64 pointer size check.  (#1860549)
- Annocheck: Do not skip tests of the short-enums notes.  (#1743635)
- Add (optional) llvm plugin.
- Annobin: Fall back on using the flags if the option cannot be found in 
cl_options.  (#1817659)




 boinc-client-7.16.11-3.el7 (FEDORA-EPEL-2020-354a8a37dd)
 The BOINC client

Update Information:

updated 4071 patch file    7.16.11 release.  Added /etc/boinc-
client/config.properties    7.16.11 release

ChangeLog:

* Wed Nov 11 2020 Germano Massullo  - 7.16.11-3
- updated 4071 patch file
* Fri Oct 30 2020 Germano Massullo  - 7.16.11-2
- Added SOURCE4: config.properties
* Fri Oct 30 2020 Germano Massullo  - 7.16.11-1
- 7.16.11 release
- Added 4071.patch Read https://github.com/BOINC/boinc/pull/4071
-

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6bc42544ca   
wordpress-5.1.8-1.el6


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

IP2Location-8.3.1+1-1.el6

Details about builds:



 IP2Location-8.3.1+1-1.el6 (FEDORA-EPEL-2020-065ba5e977)
 Tools for mapping IP address to geolocation information

Update Information:

update to 8.3.1-1 to fix library version in headers    update to 8.3.1

ChangeLog:

* Tue Nov 10 2020 Remi Collet  - 8.3.1+1-1
- update to 8.3.1-1 to fix library version in headers
- fix missing perl dependencies
* Mon Nov  9 2020 Remi Collet  - 8.3.1-4
- move library in libs subpackage
* Mon Nov  9 2020 Peter Bieringer  - 8.3.1-3
- update to 8.3.1
* Sat Nov  7 2020 Peter Bieringer  - 8.3.0-2
- update to commit 7b074becd59cf8c574190e49ce097640a2cfefd7
- add new 'ip2location' binary
* Fri Oct 30 2020 Remi Collet  - 8.3.0-1
- update to 8.3.0


___
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

[389-devel] Re: Question on cloning and replication . . .

[William Brown]

> On 11 Nov 2020, at 12:17, Matthew Harmsen  wrote:
> 
> Everyone,
> 
> I received the following from a community member who is using Dogtag and 389:
> 
> I have 2 questions and 1 note.
> 
> Note:
> Here is an interesting thing that I noticed during CA cloning:
> When CA to be cloned has secure connection DS enabled, cloning process fails.
> None of docs:
>   • https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_Clone
>   • 
> https://github.com/dogtagpki/pki/blob/DOGTAG_10_6_BRANCH/docs/installation/Installing_CA_Clone.md
>   • 
> https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing_CA_Clone.md
> is covering this issue.
> Solution here is to use 
> pki_clone_replication_master_port=389
> pki_clone_replication_clone_port=389
> pki_clone_replication_security=None
> https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg#L255
> 
> 
> Question 1 (sorry, bit long):
> When CA is cloned both DS servers have nsslapd-referral attribute set in dn: 
> cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config entries
> so DS on vm-users4.hostname.com
> would have 
> dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
> nsslapd-referral: ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA
> and DS on vm-users3.hostname.com
> dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
> nsslapd-referral: ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
> I wonder what is the meaning of nsslapd-referral attribute?

It's so that while the server is "offline" and receiving data, it can redirect 
clients to other nodes in the topology. 

> 
> The reason I'm asking is that I was thinking that for replication over SSL 
> maybe nsslapd-referral should be modified
> from  ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
> to  ldaps://vm-users4.hostname.com:636/o%3Dpki-tomcat-CA
> but when I did this nsslapd-referral attribute was reverted to original value 
> by DS automatically,
> so I'm trying to make sure if nsslapd-referral attribute should be left 
> unchanged during enabling of SSL to DS replication?
> 
> Just in case here is a sample of all changes on both DS (hopefully, I didn't 
> miss anything to have properly configured replication over SSL):
> vm-users4.hostname.com:
> 
> dn: cn=config
> nsslapd-security: on
> 
> dn: cn=RSA,cn=encryption,cn=config
> nsSSLPersonalitySSL: slapd-vm-users4
> nsSSLToken: internal (software)
> nsSSLActivation: on
> 
> dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
> nsslapd-referral: ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA
> 
> dn: 
> cn=cloneAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping
>  tree,cn=config
> nsDS5ReplicaPort: 636
> nsDS5ReplicaTransportInfo: SSL
> 
> 
> vm-users3.hostname.com:
> 
> dn: cn=config
> nsslapd-security: on
> 
> dn: cn=RSA,cn=encryption,cn=config
> nsSSLPersonalitySSL: slapd-vm-users3
> nsSSLToken: internal (software)
> nsSSLActivation: on
> 
> dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
> nsslapd-referral: ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
> 
> dn: 
> cn=masterAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping
>  tree,cn=config
> nsDS5ReplicaPort: 636
> nsDS5ReplicaTransportInfo: SSL

I'm not sure here, it could be a bug as we should redirect to TLS ports if 
possible, but I guess it also depends on how the client connects too . 
Generally a lot of clients don't follow referrals *anyway* so the whole this is 
a bit moot. 

> 
> 
> Question 2:
> DS has so called "SSF Restrictions" 
> (https://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictions.html}
> which may be configured by setting nsslapd-minssf attribute in cn=config 
> entry.
> Default value of nsslapd-minssf attribute is 0. W
> Minimum SSF configuration setting can be used to define the minimum level of 
> encryption that is required.
> 
> Do you know what this means?
> Should I be concerned?

SSF restrictions are a bit of a joke. You probably should leave them alone. 
They are intended to force connections to require encryption, but they don't 
actually provide meaningful security improvements since the info disclosures 
happen *before* the ssf check can kick in due to bind being the first op in any 
connection.

https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html?highlight=minssf

A better option if you are security conscious is to set the nsslapd-port to 0 
and only use the LDAPS/TLS port (startTLS has similar issues to minssf, and 
also adds extra latency and should be avoided.).

> 
> By the way, when is set nsslapd-minssf attribute to 128, DS becomes 
> inaccessible and CA is not working.
> 
> Thanks in advance for any answers,
> -- Matt




—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 

Schedule for Thursday's FPC Meeting (2020-11-12 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-11-12 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-11-12 09:00 PST  US/Pacific
2020-11-12 12:00 EST  --> US/Eastern <--
2020-11-12 17:00 GMT  Europe/London 
2020-11-12 17:00 UTC  UTC   
2020-11-12 18:00 CET  Europe/Berlin 
2020-11-12 18:00 CET  Europe/Paris  
2020-11-12 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-11-13 01:00 HKT  Asia/Hong_Kong
2020-11-13 01:00 +08  Asia/Singapore
2020-11-13 02:00 JST  Asia/Tokyo
2020-11-13 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Actions =

#topic #pr-954
 * King_InuYasha
   talk to copr to get config. turned on
 * tibbs
   talk to releng to get config. turned on

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

#topic Open Floor
 * decathorpe
   look through non-meeting tickets, see if any are stuck/need to be discussed

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1893759] perl-DBD-Mock-1.58 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBD-Mock-1.58-1.fc34   |perl-DBD-Mock-1.58-1.fc34
   |perl-DBD-Mock-1.58-1.fc33   |perl-DBD-Mock-1.58-1.fc33
   ||perl-DBD-Mock-1.58-1.fc32



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-cc0a863a2d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1893923] perl-Dist-Zilla-6.017 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Dist-Zilla-6.017-1.fc3 |perl-Dist-Zilla-6.017-1.fc3
   |3   |3
   ||perl-Dist-Zilla-6.017-1.fc3
   ||2



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-f92e88788d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1893923] perl-Dist-Zilla-6.017 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Dist-Zilla-6.017-1.fc3
   ||3
 Resolution|--- |ERRATA
Last Closed||2020-11-12 03:05:53



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-39d5c8fd1e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1893759] perl-DBD-Mock-1.58 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DBD-Mock-1.58-1.fc34   |perl-DBD-Mock-1.58-1.fc34
   ||perl-DBD-Mock-1.58-1.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-12 03:06:05



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-bd4e52879a has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[389-devel] Please review 4428 sigsegv in chaining.

[William Brown]

https://github.com/389ds/389-ds-base/pull/4434

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
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

[Bug 1896968] New: perl-Mozilla-PublicSuffix-1.0.1 is available

[bugzilla]

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

Bug ID: 1896968
   Summary: perl-Mozilla-PublicSuffix-1.0.1 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mozilla-PublicSuffix
  Keywords: FutureFeature, Triaged
  Assignee: yan...@declera.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.0.1
Current version/release in rawhide: 1.0.0-14.fc33
URL: http://search.cpan.org/dist/Mozilla-PublicSuffix/

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


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

[Bug 1896967] New: perl-Mojolicious-8.65 is available

[bugzilla]

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

Bug ID: 1896967
   Summary: perl-Mojolicious-8.65 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mojolicious
  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,
robinlee.s...@gmail.com, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 8.65
Current version/release in rawhide: 8.64-1.fc34
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/5966/


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Nico Kadel-Garcia]

On Wed, Nov 11, 2020 at 7:41 AM Pavel Březina  wrote:
>
> On 11/5/20 1:58 PM, Nico Kadel-Garcia wrote:
> > On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  wrote:
> >>
> >> No, no, NO again.
> >>
> >> nscd has no important active bugs in Fedora. I am not sure what bugs are
> >> mentioned, but just a few active bugs are on glibc component in Fedora.
> >> Therefore it seems just fine no commits are good.
> >>
> >> Just unlike systemd-resolved, which actively breaks some use cases. It
> >> changes resolution order of search directive in resolv.conf, breaks
> >> DNSSEC, breaks one label names resolution. It is famous among DNS
> >> community [1].
> >
> > sssd also breaks other LDAP setups, It's extremely broken with larger
> > LDAP setups because it insists on caching *ALL* of the LDAP, barring
> > being able to filter to only a smaller set of the LDAP. But because so
> > many LDAP setups scatter group and user information in so many
> > distinct parts of the LDAP layout, this never works and it *ALWAYS*
> > times out in large, remot4e LDAP setups. It works for a few seconds at
> > start time, then crashes and takes out *all* sssd based services.
>
> SSSD only stores required data, i.e. requested users, groups or whatever
> unless you set enumerate=true which is explicitly stated as "not
> recommended" in SSSD manual pages.

Unless it's been heavily modified, it pre-caches *EVERYTHING* from
LDAP by default. It's possible to limit the sssd.conf to restricted
groups or users in specific LDAP ou's, but the larger the company, the
more likely the necessary ou's for relevant users and groups are
likely to be in very large, scattered ou's throughout the LDAP layout,
and the result is excessive caching and unavoidable timeouts. Been
there, done that, about 24 months ago.

> > The sophisticated setups available by hand-editing sssd are also
> > *inevitably* overwritten by any use of the 'authconfig' command, which
> > is used by various RPM '%post' operations. sssd's configuration
>
> Authconfig used to only override domain named "default" which was
> created by authconfig and it only touched a specific set of options that
> were requested by authconfig arguments. Also users usually don't name
> their domain as "default" so I don't deem this a valid point.
> Furthermore, real authconfig is not around since Fedora 28 and the
> wrapper around authselect touches only a configuration snippet.

authconfig doesn't clean up. It has no *options* to clean up. And at
last look, it blew away the hand-tuning of sssd.conf. to restrict the
LDAP caching to more finely tuned ou's. It was not my friend. Last
time, I threw it the !@#$ out in plain old LDAP and Kerberos setups
for a much more robust and industry capable setup.

> > options are so poor that they may as well be malicious. It is most
> > effective in small and unsophisticated network environments. It
> > suffers from the "systemd" style, sprawling universal management tool
> > design principles and makes many straightforward operations very
> > difficult if not impossible.
>
> What kind of operations?
>
> I don't know when it was the last time you tried SSSD or authconfig and
> I know nothing about your environment but these are just hateful
> paragraphs without any kind of evidence. If you have any issue with
> SSSD, feel free to open bug report and we can see what needs to be done
> to make it work for you.
>
> > nscd is a lightweight and *far* more stable tool, and should be used
> > in preference to sssd wherever possible. An indepent LDAP and Kerberos
> > toolkit is *far* more stable than sssd.
> >
> >> Instead, I request again, split systemd-resolved into subpackage. I want
> >> it removed on my system and so do more people. Also, when I disable it,
> >> I have to fix /etc/resolv.conf by hand. I would think NetworkManager
> >> restart would refresh classic /etc/resolv.conf, like in F32.
> >
> > That's a separate issue. Maybe start a separate thread about that?
> > ___
> > 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
> >
> ___
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

[389-devel] please review: PR 4433 - After a failed online import the next imports are very slow

[Mark Reynolds]

https://github.com/389ds/389-ds-base/pull/4433

--

389 Directory Server Development Team
___
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

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

[Florian Weimer]

* Jonathan Wakely:

> On 10/11/20 23:24 +, Will Crawford wrote:
>>On Tue, 10 Nov 2020 at 11:56, Sandro Mani  wrote:
>>
>>/usr/bin/ld:
>>> CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
>>> from plugin): undefined reference to symbol
>>> '_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
>>> /usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO missing
>>> from command line
>>>
>>...
>>
>>> I'm not sure why ld thinks LLVM is involved, vtk does not pull in LLVM
>>> in any way.
>>>
>>> I'm pretty much clueless, any ideas?
>>>
>>
>>That looks like the object file requires a symbol from libLLVM, and gcc
>>isn't linking against it (hence the "DSO missing from command line" part).
>
> That's not a symbol from libLLVM though, it's a static variable inside
> a function template defined in the C++ standard library.

And it got assigned the LLVM_11 symbol version by accident, due to the
way the LLVM linker script works?

> See  in the libstdc++ sources:
>
>   template
> void
> __to_chars_10_impl(char* __first, unsigned __len, _Tp __val) noexcept
> {
>   static_assert(is_integral<_Tp>::value, "implementation bug");
>   static_assert(is_unsigned<_Tp>::value, "implementation bug");
>
>   static constexpr char __digits[201] =
>   "0001020304050607080910111213141516171819"
>   "2021222324252627282930313233343536373839"
>   "4041424344454647484950515253545556575859"
>   "6061626364656667686970717273747576777879"
>   "8081828384858687888990919293949596979899";

This looks similar to this bug:

  

Except that in the case here on this thread, we probably want the
interposition to get a single definition (although the symbol version
may still prevent that in the end).

My theory is that with the linker plugin, ld sees more shared objects
and considers them missing from the link.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

[Jonathan Wakely]

On 10/11/20 23:24 +, Will Crawford wrote:

On Tue, 10 Nov 2020 at 11:56, Sandro Mani  wrote:

/usr/bin/ld:

CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
from plugin): undefined reference to symbol
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
/usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO missing
from command line


...


I'm not sure why ld thinks LLVM is involved, vtk does not pull in LLVM
in any way.

I'm pretty much clueless, any ideas?



That looks like the object file requires a symbol from libLLVM, and gcc
isn't linking against it (hence the "DSO missing from command line" part).


That's not a symbol from libLLVM though, it's a static variable inside
a function template defined in the C++ standard library.

See  in the libstdc++ sources:

  template
void
__to_chars_10_impl(char* __first, unsigned __len, _Tp __val) noexcept
{
  static_assert(is_integral<_Tp>::value, "implementation bug");
  static_assert(is_unsigned<_Tp>::value, "implementation bug");

  static constexpr char __digits[201] =
"0001020304050607080910111213141516171819"
"2021222324252627282930313233343536373839"
"4041424344454647484950515253545556575859"
"6061626364656667686970717273747576777879"
"8081828384858687888990919293949596979899";
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20201111.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 6/177 (x86_64), 14/115 (aarch64)

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

ID: 720508  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/720508
ID: 720681  Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/720681
ID: 720693  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/720693
ID: 720701  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/720701
ID: 720721  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/720721
ID: 720725  Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/720725
ID: 721088  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/721088
ID: 721091  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/721091

Old failures (same test failed in Fedora-Rawhide-20201110.n.0):

ID: 720509  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/720509
ID: 720511  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/720511
ID: 720550  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/720550
ID: 720553  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/720553
ID: 720585  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/720585
ID: 720631  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/720631
ID: 720686  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/720686
ID: 720698  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/720698
ID: 720711  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/720711
ID: 720715  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/720715
ID: 721113  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/721113
ID: 721114  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/721114

Soft failed openQA tests: 7/177 (x86_64), 1/115 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 720623  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/720623

Old soft failures (same test soft failed in Fedora-Rawhide-20201110.n.0):

ID: 720437  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/720437
ID: 720469  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/720469
ID: 720482  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/720482
ID: 720483  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/720483
ID: 720533  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/720533
ID: 720601  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/720601
ID: 720610  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/720610

Passed openQA tests: 164/177 (x86_64), 99/115 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20201110.n.0):

ID: 720489  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/720489
ID: 720501  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/720501
ID: 720539  Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/720539
ID: 720709  Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/720709

Skipped non-gating openQA tests: 1 of 292

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.01 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/719552#downloads
Current test data: https://openqa.fedoraproject.org/tests/720442#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 163 MiB to 146 MiB
System load changed from 0.35 to 

Fedora-Cloud-31-20201111.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 7/7 (x86_64), 7/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20201111.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-32-20201110.0):

ID: 720360  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/720360
ID: 720367  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/720367

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-33-20201111.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20201110.0):

ID: 720293  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/720293
ID: 720300  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/720300

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Re: stable/dev branches

[Mark Reynolds]

On 11/3/20 8:50 AM, Stanislav Levin wrote:


03.11.2020 15:58, Mark Reynolds пишет:

On 11/3/20 4:41 AM, Stanislav Levin wrote:

Hello.

Currently, I package 1.4.1 branch as the former-stable for ALTLinux.
But it is not updated since July, too stable?


1.4.x branches in upstream:

   upstream/389-ds-base-1.4.1

This is no longer being maintained

   upstream/389-ds-base-1.4.2

This branch is about to stop being maintained

   upstream/389-ds-base-1.4.3

This would be the "most" stable branch at this time.

   upstream/389-ds-base-1.4.4
   upstream/master

1.4.4 and master (2.0.0) are not "stable" and include more cutting edge
changes and features.

HTH,

Mark

It would be much appreciated such future changes will be announced at
time. I think the other distro-packagers need this information too.


We follow the Fedora release schedule:

https://fedoraproject.org/wiki/Releases?rd=Releases/

So...

F34(rawhide) --> 389-ds-base-2.0.0

F33 --> 389-ds-base-1.4.4

F32 --> 389-ds-base-1.4.3

F31 --> 389-ds-base-1.4.2

Now F31 is probably going to be EOLed sooner than later, so we will stop 
maintaining 1.4.2 at that time.



I will add something to the landing page of our wiki about this topic.

Regards,
Mark




Thank you very much!


--

389 Directory Server Development Team
___
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

[389-devel] please review: PR 4431 - Do not normalize escaped spaces in a DN

[Mark Reynolds]

https://github.com/389ds/389-ds-base/pull/4431

--

389 Directory Server Development Team
___
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

Re: Proposed updates to the FESCo updates policy document

[Mattia Verga via devel]

Il 11/11/20 16:56, Kevin Fenzi ha scritto:
> Greetings.
>
> FESCo is looking to update the updates policy document that is here:
>
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
>
> For the most part the updates are not changing any policy, but simply
> removing old/no longer accurate information (taskotron no longer exists,
> bodhi is always enabled, etc) and trying to clarify things.
>
> The one actual proposed change is to allow releng to untag builds that
> have already gone out in rawhide composes. This was forbidden by the
> existing policy.
>
> You can see the PR with the changes:
>
> https://pagure.io/fesco/fesco-docs/pull-request/40
>
> and if you want to view the changed document:
>
> https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/modules/ROOT/pages/Updates_Policy.adoc
> (you may want to install a adoc viewing extension in your browser to
> view it)
>
> Feedback welcome here or in the PR.
>
> FESCo is likely to look at this next week for approval.
>
> Thanks!
>
> kevin

Hi kevin,

I've tried to summarize some of the aspects of the (updated) policy in 
an image [1], is that right? I don't fully understand the difference 
between the Beta during final freeze and Pre release...

As a side note, it would be nice to have a link in 
docs.fedoraproject.org main page to the fesco section, I currently can't 
found and didn't know he existence of it before you posted the link ;-)

Mattia

[1] https://pasteboard.co/JzTXVfv.png

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (see note about xinetd)​

[Ian McInerney]

On Wed, Nov 11, 2020 at 5:40 PM Wolfgang Ulbrich  wrote:

> I know where my package are listed at
> https://src.fedoraproject.org/dashboard/projects  :)
> But...
> [root@mother rave]# dnf repoquery --whatrequires sgpio
> Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020
> 17:04:25 CET.
> [root@mother rave]# dnf repoquery --whatrequires sgpio
> Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020
> 17:04:25 CET.
> dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64
> dmraid-events-0:1.0.0.rc16-44.fc32.x86_64-devel-0:1.0.0.rc16-44.fc32.x86_64
> dmraid-events-0:1.0.0.rc16-44.fc32.x86_64
>
> Hmm, i do not maintain dmraid or any package which depends on dmraid
>
> [root@mother rave]# dnf repoquery --whatrequires dmraid
> Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:20 am Mi 11 Nov 2020
> 17:04:25 CET.
> dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64
> dmraid-events-0:1.0.0.rc16-44.fc32.x86_64
> libblockdev-dm-0:2.23-2.fc32.i686
> libblockdev-dm-0:2.23-2.fc32.x86_64
> libblockdev-dm-0:2.24-2.fc32.i686
> libblockdev-dm-0:2.24-2.fc32.x86_64
> [root@mother rave]# dnf repoquery --whatrequires libblockdev-dm
> Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:52 am Mi 11 Nov 2020
> 17:04:25 CET.
> libblockdev-dm-devel-0:2.23-2.fc32.i686
> libblockdev-dm-devel-0:2.23-2.fc32.x86_64
> libblockdev-dm-devel-0:2.24-2.fc32.i686
> libblockdev-dm-devel-0:2.24-2.fc32.x86_64
> libblockdev-plugins-all-0:2.23-2.fc32.x86_64
> libblockdev-plugins-all-0:2.24-2.fc32.x86_64
> [root@mother rave]# dnf repoquery --whatrequires libblockdev-plugins-all
> Letzte Prüfung auf abgelaufene Metadaten: vor 1:31:26 am Mi 11 Nov 2020
> 17:04:25 CET.
> anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64
> anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64
>
> And caja doesn't depend on any of them.
>

The packager dashboard has this in a nice graph that shows the dependency
tree:

caja -> gvfs -> udisks2 -> libblockdev -> dmraid -> sgpio

-Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (see note about xinetd)​

[Wolfgang Ulbrich]

I know where my package are listed at 
https://src.fedoraproject.org/dashboard/projects  :)
But...
[root@mother rave]# dnf repoquery --whatrequires sgpio
Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020 
17:04:25 CET.
[root@mother rave]# dnf repoquery --whatrequires sgpio
Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020 
17:04:25 CET.
dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64
dmraid-events-0:1.0.0.rc16-44.fc32.x86_64-devel-0:1.0.0.rc16-44.fc32.x86_64
dmraid-events-0:1.0.0.rc16-44.fc32.x86_64

Hmm, i do not maintain dmraid or any package which depends on dmraid

[root@mother rave]# dnf repoquery --whatrequires dmraid
Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:20 am Mi 11 Nov 2020 
17:04:25 CET.
dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64
dmraid-events-0:1.0.0.rc16-44.fc32.x86_64
libblockdev-dm-0:2.23-2.fc32.i686
libblockdev-dm-0:2.23-2.fc32.x86_64
libblockdev-dm-0:2.24-2.fc32.i686
libblockdev-dm-0:2.24-2.fc32.x86_64
[root@mother rave]# dnf repoquery --whatrequires libblockdev-dm
Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:52 am Mi 11 Nov 2020 
17:04:25 CET.
libblockdev-dm-devel-0:2.23-2.fc32.i686
libblockdev-dm-devel-0:2.23-2.fc32.x86_64
libblockdev-dm-devel-0:2.24-2.fc32.i686
libblockdev-dm-devel-0:2.24-2.fc32.x86_64
libblockdev-plugins-all-0:2.23-2.fc32.x86_64
libblockdev-plugins-all-0:2.24-2.fc32.x86_64
[root@mother rave]# dnf repoquery --whatrequires libblockdev-plugins-all
Letzte Prüfung auf abgelaufene Metadaten: vor 1:31:26 am Mi 11 Nov 2020 
17:04:25 CET.
anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64
anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64

And caja doesn't depend on any of them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do with - in release tag?

[Vitaly Zaitsev via devel]

On 11.11.2020 17:00, Bruno Wolff III wrote:
There already was a 4.4 release and the package is currently a post 
release snapshot and has a release of 2.20200513gitc570c61%{dist}. So in 
this case I think I want 3.git1%{?dist} to follow your suggestion?


Yes. Also you can continue to use the classic Git snapshots scheme 
regardless of Git tags.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lightly-maintained packages (was: Summary/Minutes from today's FESCo Meeting (2020-11-11))

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 11, 2020 at 06:05:20PM +0100, Miroslav Suchý wrote:
> Dne 11. 11. 20 v 16:47 David Cantrell napsal(a):
> > * #2475 proposal: let's develop the idea of a new repo for
> >   lightly-maintained packages  (dcantrell, 15:16:41)
> 
> For the record - the initial ticket can be found here:
>   https://pagure.io/fesco/issue/2475
> 
> We already have "lightly-maintained packages" - it is called Copr projects. 
> Do we need something in between?

Yeah, because we want those packages to be available as build dependencies.
So coprs are out (unless we allow pulling in coprs into the koji buildroot, 
which
I don't think we should.)

Instead of a separate maintained repo, I'd go for a "Requires" or "Provides"
tag on packages instead. This would be easier to implement (packagers could
just add this as any other Requires), and we could easily tweak dnf to emit
a warning or require a special option before those packages were installed on
the end user system.

Zbyszek
___
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

Arpwatch updated to 3.1 – testing and auditing appreciated!

[Benjamin Beasley]

I recently took maintainership of arpwatch after it was orphaned by the 
previous maintainer. This package has a particularly long history in Fedora, 
carries quite a few patches, and had seen no upstream releases in many years 
until late 2019.

I just updated Rawhide to ship the latest upstream version, 3.1; the entire 
spec file has been modernized and de-crufted, and I have reviewed and dropped, 
rebased, or rewritten every patch or extra source file carried by the Fedora 
package. (I will send all remaining patches and extra sources upstream for 
consideration prior to the release of Fedora 34; I am waiting for further 
testing before doing so.)

I’ve made all these changes very carefully; still, given the scope of the 
necessary changes, I would especially appreciate testing and feedback from any 
arpwatch users, as well as from anyone who feels like auditing the current spec 
file and/or patches (https://src.fedoraproject.org/rpms/arpwatch/tree/master).

– Ben Beasley
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do with - in release tag?

[Vít Ondruch]

Maybe follow this guideline?

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde

Although it it not clear to me if this is pre-release or post release or 
what it actually is.



Vít


Dne 11. 11. 20 v 16:09 Bruno Wolff III napsal(a):
I looked at 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ 
and didn't see dashes specifically covered.


In my case, squashfs-tools has a new upstream release tagged 4.4-git.1 .
I'm guessing that using 4.4-git.1 as the version would be at least 
confusing and might be prohibitted. Should I do that?


If not, should I replace the - with a . in the version or should I 
move git.1 into the release. This is the first tag using this naming 
pattern, so I don't know the next tag will sort properly if I keep it 
in the version.

___
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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lightly-maintained packages (was: Summary/Minutes from today's FESCo Meeting (2020-11-11))

[Miroslav Suchý]

Dne 11. 11. 20 v 16:47 David Cantrell napsal(a):
> * #2475 proposal: let's develop the idea of a new repo for
>   lightly-maintained packages  (dcantrell, 15:16:41)

For the record - the initial ticket can be found here:
  https://pagure.io/fesco/issue/2475

We already have "lightly-maintained packages" - it is called Copr projects. Do 
we need something in between?

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20201110.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 5/177 (x86_64), 11/115 (aarch64)

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

ID: 719599  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/719599
ID: 719649  Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/719649
ID: 719819  Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/719819

Old failures (same test failed in Fedora-Rawhide-20201109.n.0):

ID: 719619  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/719619
ID: 719741  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/719741
ID: 719796  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/719796
ID: 719808  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/719808
ID: 719821  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/719821
ID: 719825  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/719825
ID: 719837  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/719837
ID: 719838  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/719838
ID: 719839  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/719839
ID: 719840  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/719840
ID: 719842  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/719842
ID: 719899  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/719899
ID: 719912  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/719912

Soft failed openQA tests: 6/177 (x86_64), 1/115 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 719547  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/719547
ID: 719579  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/719579
ID: 719592  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/719592

Old soft failures (same test soft failed in Fedora-Rawhide-20201109.n.0):

ID: 719593  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/719593
ID: 719643  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/719643
ID: 719711  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/719711
ID: 719720  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/719720

Passed openQA tests: 166/177 (x86_64), 103/115 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20201109.n.0):

ID: 719548  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/719548
ID: 719556  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/719556
ID: 719562  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/719562
ID: 719618  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/719618
ID: 719686  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/719686
ID: 719795  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/719795
ID: 719803  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/719803
ID: 719811  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/719811
ID: 719824  Test: aarch64 universal install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/719824

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
Used mem changed from 201 MiB to 180 MiB
Previous test data: https://openqa.fedoraproject.org/tests/718423#downloads
Current test data: https://openqa.fedoraproject.org/tests/719551#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
Used mem changed from 200 MiB to 179 MiB
Previous test data: 

[389-devel] please review: PR 4430 - Fix NULL dereference in cache_revert()

[Mark Reynolds]

https://github.com/389ds/389-ds-base/pull/4430

--

389 Directory Server Development Team
___
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

Re: What to do with - in release tag?

[Bruno Wolff III]

On Wed, Nov 11, 2020 at 16:53:26 +0100,
 Vitaly Zaitsev via devel  wrote:

On 11.11.2020 16:09, Bruno Wolff III wrote:
If not, should I replace the - with a . in the version or should I 
move git.1 into the release. This is the first tag using this naming 
pattern, so I don't know the next tag will sort properly if I keep 
it in the version.


Version: 4.4
Release 1.git1%{?dist}


There already was a 4.4 release and the package is currently a post 
release snapshot and has a release of 2.20200513gitc570c61%{dist}. 
So in this case I think I want 3.git1%{?dist} to follow your suggestion?


Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Petr Menšík:

>> Fedora made the decision to promote systemd-resolved as a local DNS
>> cache.  To me, that means that we can gradually remove other DNS caches
>> from the distribution.

> I maintain also dnsmasq and I doubt there is reason to remove it from
> the distribution. I would oppose if anyone intented to do it.

dnsmasq has other uses in the distribution, see e.g. libvirt.  We don't
quite see that for nscd anymore.

>> There seem to be a lot of misconceptions about what nscd does and which
>> benefits it brings (see the claim about increased privacy).  So I think
>> it's important to be precise here.

> I expect it would only cache simple name:ip pairs, nothing more. No, I
> doubt nscd can bring any additional privacy.

Ahem.  Name/sets of addresses, which covers negative caching as well.

>> 
>> From my point of view, nscd is not a very satisfactory solution for DNS
>> caching because it can't do DNSSEC, it can't do recursion, it can't do
>> prefetching, it doesn't have a good way to detect dead servers, it can't
>> inject local stub zones, and so on.

> We can argue whether people need DNSSEC. Systemd-resolved cannot work
> with it correctly and it actively BREAKS its usage. Just like dnsmasq,
> nscd just caches and no more. It usually does not break anything. I
> think it preserves most features of libnss_dns.so behaviour. No
> recursion, dead servers detection or injecting local zones is required.
> It is not done without the cache anyway. Dead servers detection could be
> improved I think.

Dead server detection is what people expect that have migrated from
other systems.  dnsmasq has a rudimentary form of it:

  /* In strict_order mode, always try servers in the order 
 specified in resolv.conf, if a domain is given 
 always try all the available servers,
 otherwise, use the one last known to work. */

I think that probably covers 80% of the use cases.

(This really needs a separate daemon that centralizes the state, so that
processes that just do one DNS query and exit can pick the right
upstream server for the query.)

>> I also think that not changing /etc/resolv.conf isn't a feasible goal
>> because that's the file applications use to locate the system DNS
>> resolver if they can't use the glibc interfaces for some reason.

> Sure. If they can't use glibc interface, they would not use nscd. That
> clearly its advantage!

Typically, they still want a reliable DNS service, and in some
deployment scenarios, that basically needs a local caching stub that
does some rudimentary form of dead-server detection.

> It does not have to implement dnssec or edns0, because getaddrinfo api
> does not include such flags. If clients needs advanced usage, unlike
> systemd-resolved, it does not stand in the way. I think this is the
> greatest advantage. Advanced uses can work around only a simple
> service without problem. They don't collide.

They still suffer from the lack of local cache.  I think the local cache
is highly beneficially and important to Fedora, so I'm excited that we
finally got one by default in Fedora 33.

>> The big one is the general cache instability:
>> 
>>   nscd: Concurrency issues with cache.
>>   
>> 
>> (Internal bug #1172792.)
> This bug reminds me bug #1740511 [1], which was very hard for me. Later,
> mlichvar discovered real reason for it. Atomic operations required
> different flags to atomic operations. ppc64le platform has different
> memory ordering than x86_64, where it worked flawlessly. It crashed
> often just on ppc64le. Our fix was to switch to memory_order_acquire,
> where integrity was enforced properly. I have seen relaxed in bug
> attached patches, would recommend checking it out.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1740511
> https://en.cppreference.com/w/c/atomic/memory_order

We had someone look at this who literally has a PhD in this area
(software transactional memory).  And yet here were are. 8-(

>> Related to DNS data, there are bunch of issues that need investigating
>> or fixing:
>> 
>>   getaddrinfo drops ipv6 V4MAPPED addresses from ncsd results
>>   
>> 
>>   Problems with nscd and systemd-resolved interactions on IPv6 network.
>>   
>> 
>>   nscd doesn't cache record containing more than one IP address.
>>   
>> 
>>   Reload nscd cache entry even if its timeout is equal to the current time
>>   
>> 
>>   hosts caching does not respect TTL, and caches old IP's
>>   

> Is there any design document about nscd?

Not really, it's necessary to reconstruct this from the implementation.

> How are interfaces to cache implemented from glibc? Is connection to
> nscd hardocoded 

[Bug 1890589] EPEL8 Request: perl-Config-GitLike

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-262a44f93d has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-262a44f93d


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Lennart Poettering]

On Sa, 07.11.20 15:33, Marius Schwarz (fedora...@cloud-foo.de) wrote:

> Am 05.11.20 um 12:39 schrieb Petr Menšík:
> > There is no controversy with nscd, it just caches names and nothing
> > more. I think this is its advantage. Unless there is any stronger
> > reason, I am against this change in advance.
> >
> It not only caches names, it also RANDOMIZES the requests to the dns servers
> configured, increasing the privacy of ones internet journey.

What do you mean by that? That it distributes DNS lookups between multiple,
randomly selected servers?

So if you configure 4 DNS servers then each will still get roughly
1/4th of your requests? That's still quite a lot of info.

I mean, if it would distribute it to >1000 different DNS servers this might be
interesting, but it doesn't really sound like it gives you much of
privacy benefit IRL...

Lennart

--
Lennart Poettering, Berlin
___
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

Proposed updates to the FESCo updates policy document

[Kevin Fenzi]

Greetings.

FESCo is looking to update the updates policy document that is here:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/

For the most part the updates are not changing any policy, but simply
removing old/no longer accurate information (taskotron no longer exists,
bodhi is always enabled, etc) and trying to clarify things.

The one actual proposed change is to allow releng to untag builds that
have already gone out in rawhide composes. This was forbidden by the
existing policy.

You can see the PR with the changes:

https://pagure.io/fesco/fesco-docs/pull-request/40

and if you want to view the changed document:

https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/modules/ROOT/pages/Updates_Policy.adoc
(you may want to install a adoc viewing extension in your browser to
view it)

Feedback welcome here or in the PR.

FESCo is likely to look at this next week for approval.

Thanks!

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (see note about xinetd)

[Gary Buhrmaster]

On Wed, Nov 11, 2020 at 3:01 PM Chris Adams  wrote:

> Are there replacements for the old services built in to xinetd?

Not that I know of as being integrated, although
writing such servers (often in perl) can often be
seen in training materials about network socket
programming in a few dozen lines of code.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do with - in release tag?

[Vitaly Zaitsev via devel]

On 11.11.2020 16:09, Bruno Wolff III wrote:
If not, should I replace the - with a . in the version or should I move 
git.1 into the release. This is the first tag using this naming pattern, 
so I don't know the next tag will sort properly if I keep it in the 
version.


Version: 4.4
Release 1.git1%{?dist}

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (see note about xinetd)

[Stephen John Smoogen]

On Wed, 11 Nov 2020 at 10:01, Chris Adams  wrote:

> Once upon a time, Petr Pisar  said:
> > I believe it's unlikely that somobody will adopt xinetd. It was orphaned
> > because its maintainer orphaned all his packages.
>
> Are there replacements for the old services built in to xinetd?  It's a
> surprise, but there are still network devices for service provider
> networks that want to use time and/or daytime to set their clocks at
> boot (so $DAYJOB still has to provision servers with those services
> enabled on private networks occasionally).
>
> Yes, I know it is 2020, and all about NTP and such... but I don't write
> the firmware in those devices.  If you haven't worked on service
> provider stuff before... it is VERY slow to change.
>
>
I expect that the only way to make it work will be having an EL7 system til
2024 and then an eventual giant hardware firesale in 2030 or so.
Daytime/time have only worked by the 'grace' of Fortuna since probably the
late 1990's, and not tested except for those people who actually have to
deal with said hardware since then. Eventually the technology hits a wall
like it does every 5 to 10 years and a mass amount of stuff has to be
'retired'.. This usually happens after a crisis like a recession, a CFO/CIO
retiring, or some set of sysadmins who kept it working are fully retired
(aka it is now too expensive to pay for them being after-job consultants so
their contracts are ended.)




> --
> Chris Adams 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
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

Summary/Minutes from today's FESCo Meeting (2020-11-11)

[David Cantrell]

=
#fedora-meeting-2: FESCO (2020-11-11)
=


Meeting started by dcantrell at 15:00:45 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-11-11/fesco.2020-11-11-15.00.log.html
.



Meeting summary
---
* init process  (dcantrell, 15:00:48)
  * Igor is alive, but busy  (mhroncok, 15:07:00)

* #2495 Election Interview Questions — FESCo (Fedora 33)  (dcantrell,
  15:08:05)
  * ACTION: dcantrell followup with bcotton regarding election question
gathering process  (dcantrell, 15:14:31)

* #2475 proposal: let's develop the idea of a new repo for
  lightly-maintained packages  (dcantrell, 15:16:41)

* #2473 updates policy is out of date  (dcantrell, 15:20:08)
  * ACTION: nirik to followup with qa and devel list re: 2473
(dcantrell, 15:28:03)

* Next week's chair  (dcantrell, 15:29:02)
  * ACTION: zbyszek will chair next meeting  (dcantrell, 15:29:47)

* Open Floor  (dcantrell, 15:29:57)

Meeting ended at 15:31:45 UTC.




Action Items

* dcantrell followup with bcotton regarding election question gathering
  process
* nirik to followup with qa and devel list re: 2473
* zbyszek will chair next meeting




Action Items, by person
---
* dcantrell
  * dcantrell followup with bcotton regarding election question
gathering process
* nirik
  * nirik to followup with qa and devel list re: 2473
* zbyszek
  * zbyszek will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dcantrell (63)
* mhroncok (28)
* King_InuYasha (22)
* nirik (21)
* zbyszek (14)
* zodbot (13)
* decathorpe (5)
* sgallagh (1)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* cverna (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Chris Adams:

> Once upon a time, Florian Weimer  said:
>> Fedora made the decision to promote systemd-resolved as a local DNS
>> cache.  To me, that means that we can gradually remove other DNS caches
>> from the distribution.
>
> Since when does Fedora choosing a default mean other options must be
> removed from the distribution?

What I meant: If Fedora chooses a default, it is reasonable to expect
that less effort is spent on alternatives, especially if the maintainers
for those alternatives desire to do so.

In theory, users could have been presented with a choice of different
caching options during installation, including Unbound, dnsmasq and
nscd, but that is not what was implemented, despite some concerns
regarding the readiness of systemd-resolved.  To me, this suggests that
the Fedora project does not think that having those alternatives an
option brings substantial value.  I think it's only fair if package
maintainers prioritize accordingly.

Unbound and dnsmasq clearly have alternative usage scenarios beyond a
caching DNS stub resolver, but we just don't see such alternative usage
scenarios for nscd.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do with - in release tag?

[Fabio Valentini]

On Wed, Nov 11, 2020 at 4:30 PM Bruno Wolff III  wrote:
>
> I looked at
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
> and didn't see dashes specifically covered.
>
> In my case, squashfs-tools has a new upstream release tagged 4.4-git.1 .
> I'm guessing that using 4.4-git.1 as the version would be at least
> confusing and might be prohibitted. Should I do that?
>
> If not, should I replace the - with a . in the version or should I move
> git.1 into the release. This is the first tag using this naming pattern, so
> I don't know the next tag will sort properly if I keep it in the version.

Dashes are invalid in both Version and Release tags. RPM will not even
parse your .spec file if either of them contains one.

I would say the way to deal with this depends on what upstream wants
to convey with this confusing versioning scheme:
- the -git.1 is information that is irrelevant to end-users (and there
won't be -git.2, -git.3 releases): drop it from Version and Release
entirely
- this is a 4.4 pre-release (expecting that a there will be 4.4 at
some point): then use something like Version: 4.4, Release:
0.git.1%{?dist}, which will make "proper" 4.4 releases sort higher
than this one
- this is a 4.4 stable release with a weird name: then use something
like Version 4.4.git.1, Release: 1%{?dist}, which will also preserve
ordering for eventual git.2, git.3, etc. updates

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Ben Cotton:

> https://fedoraproject.org/wiki/Changes/RemoveNSCD
>
> == Summary ==
> This proposal intends to replace the ''nscd'' cache for named services
> with ''systemd-resolved'' for the `hosts` database and the ''sssd''
> daemon for everything else.
>
> == Owner ==
> * Name: [[User:submachine| Arjun Shankar]]
> * Email: ar...@redhat.com
>
> == Detailed Description ==

Arjun brought this up on the musl list as well:

  

I'm not sure if there's a clear consensus there.  Obviously the core
interest lies elsewhere.  I do not know how much software deployed using
musl actually depends on nscd for enterprise name lookup integration.
(The nscd protocol is the only way musl consume these glibc services;
it does not have a similar plug-in framework.)

I do not view the musl dependency as a significant obstacle to nscd
removal.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1890896] Add perl-File-Map to EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-8a24651ea4 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8a24651ea4


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

Re: patch applied without package maintainers' approve

[Miro Hrončok]

On 11/11/20 4:17 PM, Peter Robinson wrote:

Also note there is no packaging requirements to get approval from
package maintainers.


https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

"Provenpackagers should try to communicate with owners of a package in bugzilla, 
irc or email prior to making changes"


Yes, technically this is not a hard requirement, but a recommendation.

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

What to do with - in release tag?

[Bruno Wolff III]

I looked at 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ 
and didn't see dashes specifically covered.


In my case, squashfs-tools has a new upstream release tagged 4.4-git.1 .
I'm guessing that using 4.4-git.1 as the version would be at least 
confusing and might be prohibitted. Should I do that?


If not, should I replace the - with a . in the version or should I move 
git.1 into the release. This is the first tag using this naming pattern, so 
I don't know the next tag will sort properly if I keep it in the version.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Chris Adams]

Once upon a time, Florian Weimer  said:
> Fedora made the decision to promote systemd-resolved as a local DNS
> cache.  To me, that means that we can gradually remove other DNS caches
> from the distribution.

Since when does Fedora choosing a default mean other options must be
removed from the distribution?

> Even if systemd-resolved has issues, they still need to be fixed because
> it's the Fedora default.

And yet, it was made default and objections about issues hand-waved away
as not important use cases... I'm not holding my breath for them to be
fixed.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1890589] EPEL8 Request: perl-Config-GitLike

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/30684
https://pagure.io/releng/fedora-scm-requests/issue/30685


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

Re: patch applied without package maintainers' approve

[Peter Robinson]

> I'm one of package maintainers of rdma-core. There is a patch
> applied without any maintainers' review/approve. I had sent two emails
> to patch committer to ask him/her to push the change to upstream.
> But never get response.

So someone pinged me on IRC about this, I never saw the emails because
you replied to the git commit and I auto archive/mute all those emails
because I get a LOT of them. You never tried other communication
mechanisms that I'm aware of such are IRC.

Also note there is no packaging requirements to get approval from
package maintainers.

> The patch maybe useful or fix something. But the divergence between
> upstream and Fedora rawhide is what I don't want to see, because
> such divergence is source of regression issues.

The addition of libpcap linking against libibverbs pulled in a whole
of extra dependencies that aren't used by Workstation/Cloud or
anything that doesn't have infinband. So this just splits it out to a
smaller package, for a IB user they will see nothing different.

I don't see how a spec file change is a "regression", there's nothing
that will regress here, the rdma-core depends on the package and if
anyone installs that they also get the new sub package, but if the
general user doesn't have IB hardware, which is the vast majority of
users even in the enterprise, they don't have to unnecessarily have
extra stuff clogging up their system.

In terms of "upstream" I'm not sure what you mean there, because
upstream of Fedora is generally tar files but do feel free to push the
change upstream if you prefer that for managing stuff.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (see note about xinetd)

[Chris Adams]

Once upon a time, Petr Pisar  said:
> I believe it's unlikely that somobody will adopt xinetd. It was orphaned
> because its maintainer orphaned all his packages.

Are there replacements for the old services built in to xinetd?  It's a
surprise, but there are still network devices for service provider
networks that want to use time and/or daytime to set their clocks at
boot (so $DAYJOB still has to provision servers with those services
enabled on private networks occasionally).

Yes, I know it is 2020, and all about NTP and such... but I don't write
the firmware in those devices.  If you haven't worked on service
provider stuff before... it is VERY slow to change.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Petr Menšík]

Hi Florian,

more below...

On 11/11/20 11:39 AM, Florian Weimer wrote:
> * Petr Menšík:
>>> This proposal is about nscd, not systemd-resolved.
> 
>> systemd-resolved is mentioned in the title and the body of proposal. So
>> it seems it is about it.
> 
> Fedora made the decision to promote systemd-resolved as a local DNS
> cache.  To me, that means that we can gradually remove other DNS caches
> from the distribution.
I maintain also dnsmasq and I doubt there is reason to remove it from
the distribution. I would oppose if anyone intented to do it.
> 
> Even if systemd-resolved has issues, they still need to be fixed because
> it's the Fedora default.
systemd-resolved brings more changes than were announced. Not all of
them have fixes and some were refused. I think systemd people close too
many bugs with WORKSFORME reason personally. But sure, bugs should be fixed.

On the other hand, there are a lot of use cases, where it works better
without systemd-resolved. I think we want alternatives supported
regardless what is the default. Need to say I am not happy it became
default and I would prefer it would first fix (already) known issues.
> 
>>> If Fedora chooses to adopt another local DNS cache, glibc will use that
>>> (probably using the built-in nss_dns service module) systemd-resolved is
>>> just what we have for now, so the proposal references it.  But any other
>>> DNS cache will work as well.
> 
>> I do not think there is another cache like nscd, which does not require
>> /etc/resolv.conf change or special nss hosts module. While I admit there
>> are more caches, I don't think any provides drop-in replacement.
>> Especially resolve nss plugin introduces so many (unannounced) changes,
>> I don't think it is a good alternative. Caching via dns module might be
>> more predictable even with systemd-resolved.
> 
> What do you mean by “Caching via dns module”?  nss_dns does not have any
> cache whatsoever.
What I mean is omitting resolve module. So hosts db either reads
/etc/hosts, or uses /etc/resolv.conf via /lib64/libnss_dns.so.2.
> 
> There seem to be a lot of misconceptions about what nscd does and which
> benefits it brings (see the claim about increased privacy).  So I think
> it's important to be precise here.
I expect it would only cache simple name:ip pairs, nothing more. No, I
doubt nscd can bring any additional privacy.
> 
> From my point of view, nscd is not a very satisfactory solution for DNS
> caching because it can't do DNSSEC, it can't do recursion, it can't do
> prefetching, it doesn't have a good way to detect dead servers, it can't
> inject local stub zones, and so on.
We can argue whether people need DNSSEC. Systemd-resolved cannot work
with it correctly and it actively BREAKS its usage. Just like dnsmasq,
nscd just caches and no more. It usually does not break anything. I
think it preserves most features of libnss_dns.so behaviour. No
recursion, dead servers detection or injecting local zones is required.
It is not done without the cache anyway. Dead servers detection could be
improved I think.
> 
> I also think that not changing /etc/resolv.conf isn't a feasible goal
> because that's the file applications use to locate the system DNS
> resolver if they can't use the glibc interfaces for some reason.
Sure. If they can't use glibc interface, they would not use nscd. That
clearly its advantage! It does not have to implement dnssec or edns0,
because getaddrinfo api does not include such flags. If clients needs
advanced usage, unlike systemd-resolved, it does not stand in the way. I
think this is the greatest advantage. Advanced uses can work around only
a simple service without problem. They don't collide.
> 
>>> The hosts cache in nscd is arguably the weakest part of it, so
>>> deprecating really shouldn't be controversial at all.
> 
>> If you offer alternative, which improves caching without additional
>> regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
>> can be compared to no configuration of nscd. Unlike other resolvers,
>> nscd caches only getaddrinfo calls, without ever touching outgoing DNS
>> client queries or /etc/resolv.conf modification. Is there any other
>> service able to do it?
>>
>> Are there bugs I can help fixing, especially in hosts or ahosts
>> databases?
> 
> Thanks for the offer.
> 
> The big one is the general cache instability:
> 
>   nscd: Concurrency issues with cache.
>   
> 
> (Internal bug #1172792.)
This bug reminds me bug #1740511 [1], which was very hard for me. Later,
mlichvar discovered real reason for it. Atomic operations required
different flags to atomic operations. ppc64le platform has different
memory ordering than x86_64, where it worked flawlessly. It crashed
often just on ppc64le. Our fix was to switch to memory_order_acquire,
where integrity was enforced properly. I have seen relaxed in bug
attached patches, would recommend checking it out.

[Bug 1893136] RFE - build a perl-Future package for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-ba89c0dcc2 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ba89c0dcc2


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Pavel Březina]

On 11/5/20 1:58 PM, Nico Kadel-Garcia wrote:

On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  wrote:


No, no, NO again.

nscd has no important active bugs in Fedora. I am not sure what bugs are
mentioned, but just a few active bugs are on glibc component in Fedora.
Therefore it seems just fine no commits are good.

Just unlike systemd-resolved, which actively breaks some use cases. It
changes resolution order of search directive in resolv.conf, breaks
DNSSEC, breaks one label names resolution. It is famous among DNS
community [1].


sssd also breaks other LDAP setups, It's extremely broken with larger
LDAP setups because it insists on caching *ALL* of the LDAP, barring
being able to filter to only a smaller set of the LDAP. But because so
many LDAP setups scatter group and user information in so many
distinct parts of the LDAP layout, this never works and it *ALWAYS*
times out in large, remot4e LDAP setups. It works for a few seconds at
start time, then crashes and takes out *all* sssd based services.


SSSD only stores required data, i.e. requested users, groups or whatever 
unless you set enumerate=true which is explicitly stated as "not 
recommended" in SSSD manual pages.



The sophisticated setups available by hand-editing sssd are also
*inevitably* overwritten by any use of the 'authconfig' command, which
is used by various RPM '%post' operations. sssd's configuration


Authconfig used to only override domain named "default" which was 
created by authconfig and it only touched a specific set of options that 
were requested by authconfig arguments. Also users usually don't name 
their domain as "default" so I don't deem this a valid point. 
Furthermore, real authconfig is not around since Fedora 28 and the 
wrapper around authselect touches only a configuration snippet.



options are so poor that they may as well be malicious. It is most
effective in small and unsophisticated network environments. It
suffers from the "systemd" style, sprawling universal management tool
design principles and makes many straightforward operations very
difficult if not impossible.


What kind of operations?

I don't know when it was the last time you tried SSSD or authconfig and 
I know nothing about your environment but these are just hateful 
paragraphs without any kind of evidence. If you have any issue with 
SSSD, feel free to open bug report and we can see what needs to be done 
to make it work for you.



nscd is a lightweight and *far* more stable tool, and should be used
in preference to sssd wherever possible. An indepent LDAP and Kerberos
toolkit is *far* more stable than sssd.


Instead, I request again, split systemd-resolved into subpackage. I want
it removed on my system and so do more people. Also, when I disable it,
I have to fix /etc/resolv.conf by hand. I would think NetworkManager
restart would refresh classic /etc/resolv.conf, like in F32.


That's a separate issue. Maybe start a separate thread about that?
___
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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20201111.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201110.n.0
NEW: Fedora-Rawhide-2020.n.0

= SUMMARY =
Added images:0
Dropped images:  6
Added packages:  16
Dropped packages:5
Upgraded packages:   84
Downgraded packages: 0

Size of added packages:  343.10 MiB
Size of dropped packages:32.37 MiB
Size of upgraded packages:   2.49 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   67.81 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20201110.n.0-sda.raw.xz
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20201110.n.0.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201110.n.0.x86_64.vagrant-virtualbox.box
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20201110.n.0.ppc64le.tar.xz
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20201110.n.0.iso
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201110.n.0.x86_64.vagrant-libvirt.box

= ADDED PACKAGES =
Package: bcd-1.1-2.20180610gitd94c9fa.fc34
Summary: Bayesian Collaborative Denoiser for Monte-Carlo Rendering
RPMs:bcd bcd-cli bcd-devel
Size:1.04 MiB

Package: cri-o-2:1.17.5-4.module_f34+10558+f570851f
Summary: Kubernetes Container Runtime Interface for OCI-based containers
RPMs:cri-o
Size:212.62 MiB

Package: cri-tools-1.19.0-1.module_f34+10164+3651ed44
Summary: CLI and validation tools for Container Runtime Interface
RPMs:cri-tools
Size:55.03 MiB

Package: ghc-HaXml-1.25.5-2.fc34
Summary: Utilities for manipulating XML documents
RPMs:HaXml ghc-HaXml ghc-HaXml-devel ghc-HaXml-doc ghc-HaXml-prof
Size:63.38 MiB

Package: ghc-fixed-0.3-1.fc34
Summary: Signed 15.16 precision fixed point arithmetic
RPMs:ghc-fixed ghc-fixed-devel ghc-fixed-doc ghc-fixed-prof
Size:550.49 KiB

Package: ghc-http-client-openssl-0.3.1.0-1.fc34
Summary: Http-client backend using the OpenSSL library
RPMs:ghc-http-client-openssl ghc-http-client-openssl-devel 
ghc-http-client-openssl-doc ghc-http-client-openssl-prof
Size:350.49 KiB

Package: golang-github-mdlayher-ethernet-0-0.1.20201109git0394541.fc34
Summary: Implements marshaling and unmarshaling of IEEE 802.3 Ethernet II 
frames and IEEE 802.1Q VLAN tags
RPMs:etherecho golang-github-mdlayher-ethernet-devel
Size:3.35 MiB

Package: iotop-c-1.15-1.fc34
Summary: Simple top-like I/O monitor (implemented in C)
RPMs:iotop-c
Size:196.10 KiB

Package: libnxz-0.61-1.fc34
Summary: Zlib implementation for POWER processors
RPMs:libnxz libnxz-devel libnxz-static
Size:198.50 KiB

Package: openxr-1.0.12-3.fc34
Summary: An API for writing VR and AR software
RPMs:openxr openxr-devel openxr-libs
Size:3.46 MiB

Package: ptex-2.3.2-3.fc34
Summary: Per-Face Texture Mapping for Production Rendering
RPMs:ptex ptex-devel ptex-doc ptex-libs
Size:1.70 MiB

Package: puddletag-2.0.1-1.fc34
Summary: Feature rich, easy to use tag editor
RPMs:puddletag
Size:1.07 MiB

Package: python-dingz-0.2.0-1.fc34
Summary: Python API client for interacting with dingz devices
RPMs:python3-dingz
Size:22.30 KiB

Package: python-dnslib-0.9.14-1.fc34
Summary: Simple library to encode/decode DNS packets
RPMs:python3-dnslib
Size:88.88 KiB

Package: python-jsonpath-ng-1.5.1-2.fc34
Summary: Implementation of JSONPath for Python
RPMs:python3-jsonpath-ng
Size:46.57 KiB

Package: python-secure_cookie-0.1.0-1.fc34
Summary: Provides interfaces for secure cookies and sessions in WSGI 
applications
RPMs:python3-secure_cookie
Size:27.21 KiB


= DROPPED PACKAGES =
Package: dynafed-1.5.1-1.fc32
Summary: Ultra-scalable dynamic system for federating HTTP-based storage 
resources
RPMs:dynafed dynafed-dmlite-frontend dynafed-dmlite-plugin 
dynafed-http-plugin dynafed-private-devel dynafed-tpc-gfal2
Size:19.64 MiB

Package: hub-2.14.2-1.fc33
Summary: Command-line tool that makes git easier to use with GitHub
RPMs:hub
Size:12.66 MiB

Package: python-azure-devtools-1.0.0-10.fc33
Summary: Devtools for Azure SDK and CLI for Python
RPMs:python3-azure-devtools
Size:35.14 KiB

Package: python-j1m.sphinxautointerface-0.3.0-14.fc33
Summary: Sphinx extension for documenting zope.interface interfaces
RPMs:python3-j1m.sphinxautointerface
Size:19.22 KiB

Package: python-pytest-faulthandler-1.6.0-6.fc33
Summary: py.test plugin that activates the fault handler module for tests
RPMs:python3-pytest-faulthandler
Size:14.51 KiB


= UPGRADED PACKAGES =
Package:  CubicSDR-0.2.5-10.20200824git4f1db55.fc34
Old package:  CubicSDR-0.2.5

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

[Richard Shaw]

On Wed, Nov 11, 2020 at 4:05 AM Sandro Mani  wrote:

>
> > Can you try disabling LTO by adding:
> > %global _lto_cflags %{nil}
> > to your spec file and see if that helps.
>
> Indeed, with LTO disabled it builds, thanks for the tip!
>

He probably saw this, but copying in Jeff to add to his LTO list :)

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Nico Kadel-Garcia:

> On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  wrote:
>>
>> No, no, NO again.
>>
>> nscd has no important active bugs in Fedora. I am not sure what bugs are
>> mentioned, but just a few active bugs are on glibc component in Fedora.
>> Therefore it seems just fine no commits are good.
>>
>> Just unlike systemd-resolved, which actively breaks some use cases. It
>> changes resolution order of search directive in resolv.conf, breaks
>> DNSSEC, breaks one label names resolution. It is famous among DNS
>> community [1].
>
> sssd also breaks other LDAP setups, It's extremely broken with larger
> LDAP setups because it insists on caching *ALL* of the LDAP, barring
> being able to filter to only a smaller set of the LDAP.

Have you filed a bug report?  I have seen similar reports, but I think
they were unexpected interactions with certain LDAP servers and
schemata.

(I personally do not work on sssd, though.)

> nscd is a lightweight and *far* more stable tool, and should be used
> in preference to sssd wherever possible. An indepent LDAP and Kerberos
> toolkit is *far* more stable than sssd.

Just because it works for you doesn't mean that it's bug-free.  We know
from reviewing the source code that nscd has several problem areas that
are difficult to fix.  It may work fine under low-load situations.

I think it is more useful to focus on improving SSSD (which is already
more or less required for Windows domain integration) than maintain two
different caching solutions.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Petr Menšík:

> On 11/5/20 12:49 PM, Florian Weimer wrote:
>> * Petr Menšík:
>> 
>> 
>> nscd has more usage downstream, leading to bugs such as:
>> 
>>   
>
> I have very limited understanding of sssd principles. But I think it is
> not comparable to nscd, which you just start or stop. No other
> configuration is required.

sssd without LDAP integration should work out of the box, too, and
automatically cache /etc/passwd and other databases.  It's even smarter
about that than nscd, I think, reading the files on startup and
monitoring them for changes.

>>> Instead, I request again, split systemd-resolved into subpackage. I want
>>> it removed on my system and so do more people. Also, when I disable it,
>>> I have to fix /etc/resolv.conf by hand. I would think NetworkManager
>>> restart would refresh classic /etc/resolv.conf, like in F32.
>> 
>> This proposal is about nscd, not systemd-resolved.

> systemd-resolved is mentioned in the title and the body of proposal. So
> it seems it is about it.

Fedora made the decision to promote systemd-resolved as a local DNS
cache.  To me, that means that we can gradually remove other DNS caches
from the distribution.

Even if systemd-resolved has issues, they still need to be fixed because
it's the Fedora default.

>> If Fedora chooses to adopt another local DNS cache, glibc will use that
>> (probably using the built-in nss_dns service module) systemd-resolved is
>> just what we have for now, so the proposal references it.  But any other
>> DNS cache will work as well.

> I do not think there is another cache like nscd, which does not require
> /etc/resolv.conf change or special nss hosts module. While I admit there
> are more caches, I don't think any provides drop-in replacement.
> Especially resolve nss plugin introduces so many (unannounced) changes,
> I don't think it is a good alternative. Caching via dns module might be
> more predictable even with systemd-resolved.

What do you mean by “Caching via dns module”?  nss_dns does not have any
cache whatsoever.

There seem to be a lot of misconceptions about what nscd does and which
benefits it brings (see the claim about increased privacy).  So I think
it's important to be precise here.

From my point of view, nscd is not a very satisfactory solution for DNS
caching because it can't do DNSSEC, it can't do recursion, it can't do
prefetching, it doesn't have a good way to detect dead servers, it can't
inject local stub zones, and so on.

I also think that not changing /etc/resolv.conf isn't a feasible goal
because that's the file applications use to locate the system DNS
resolver if they can't use the glibc interfaces for some reason.

>> The hosts cache in nscd is arguably the weakest part of it, so
>> deprecating really shouldn't be controversial at all.

> If you offer alternative, which improves caching without additional
> regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
> can be compared to no configuration of nscd. Unlike other resolvers,
> nscd caches only getaddrinfo calls, without ever touching outgoing DNS
> client queries or /etc/resolv.conf modification. Is there any other
> service able to do it?
>
> Are there bugs I can help fixing, especially in hosts or ahosts
> databases?

Thanks for the offer.

The big one is the general cache instability:

  nscd: Concurrency issues with cache.
  

(Internal bug #1172792.)

Related to DNS data, there are bunch of issues that need investigating
or fixing:

  getaddrinfo drops ipv6 V4MAPPED addresses from ncsd results
  

  Problems with nscd and systemd-resolved interactions on IPv6 network.
  

  nscd doesn't cache record containing more than one IP address.
  

  Reload nscd cache entry even if its timeout is equal to the current time
  

  hosts caching does not respect TTL, and caches old IP's
  

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1893136] RFE - build a perl-Future package for EPEL8

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/30681
https://pagure.io/releng/fedora-scm-requests/issue/30682


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

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

[Sandro Mani]

Can you try disabling LTO by adding:
%global _lto_cflags %{nil}
to your spec file and see if that helps.


Indeed, with LTO disabled it builds, thanks for the tip!

Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (see note about xinetd)

[Petr Pisar]

On Mon, Nov 02, 2020 at 11:25:39AM -, Michael J Gruber wrote:
> > = NOTE about xinetd =
> > 
> > Many packagers are listed as affected by xinetd. The dependency chain is:
> > 
> > cvs (kasal, ppisar)
> > cvs-inetd.noarch requires xinetd
> > 
> > git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
> > git.src requires cvs
> > git-cvs.noarch requires cvs
> > 
> >  ( )
> >  requires git
> > 
> > Note that if xinetd indeed goes away, your package will most likely not be 
> > affected, unless you actually need git-cvs.
> > 
> > = end NOTE =
> 
> Also, git requires only the client functionality, not cvs-inetd itself. So
> it would be good to get input from the former xinetd maintainer whether
> - xinetd should be retired fro some reason (and cvs should retire the
> cvs-inetd subpackage)
> - or xinetd should simply be picked up.
> 
I removed the cvs-inted subpackage from Fedora 34. Those who need to run a CVS
server can use systemd cvs@.service activated by cvs.socket instead.

I believe it's unlikely that somobody will adopt xinetd. It was orphaned
because its maintainer orphaned all his packages.

-- Petr


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

[Bug 1889396] Upgrade perl-Term-Shell to 0.12

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Term-Shell-0.12-1.fc34
 Resolution|--- |RAWHIDE
   Assignee|steve.tray...@cern.ch   |jples...@redhat.com
Last Closed||2020-11-11 08:47:23




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