date:20201102

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



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


-- 
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 1883530] Add perl-Curses-UI to EPEL8

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Curses-UI-0.9609-15.el
   ||8



--- Comment #6 from Petr Pisar  ---
Thanks for the repo. I've built the package.


-- 
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-20201103.0 compose check report

No missing expected images.

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

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

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

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

Re: Retiring ntp

2020-11-02 Thread Alex Thomas

Question : I know that FreeIPA at one point did not work well with
chrony and required the installation of ntp. This might cause an
issue.

On Mon, Nov 2, 2020 at 3:54 PM Gary Buhrmaster
 wrote:
>
> On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia  wrote:
>
> > So, use "chrony" instead?
>
> For some use cases, there is also the option of
> systemd-timesyncd as a ntp client.
>
> > Is the functionality sufficient
>
> As always, given the different use cases, the answer
> is maybe.
>
> Here is a quick comparison: https://chrony.tuxfamily.org/comparison.html
>
> > and can the ntp.conf files be ported gracefully to a
> > compatible chrony.conf setting?
>
> Again, it would depend on how you are using ntpd.
> For the cases where the system is just a client of
> the protocol trying keep the right time, it should be
> easy to migrate to either chrony (or systemd-timesyncd).
> If you are using hardware to discipline your server
> using one/more of the hardware specific drivers
> things get more complicated.
> ___
> 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

Re: Repository metadata signing?

On Tue, Nov 3, 2020 at 12:16 AM Marek Marczykowski-Górecki
 wrote:
>
> On Mon, Nov 02, 2020 at 07:33:18PM -0500, Neal Gompa wrote:
> > The major remaining issue for us to start enabling repository GPG
> > checks is that DNF doesn't use the RPM GPG keyring for repository
> > metadata GPG signature validation, which can cause issues with our
> > compose pipeline. I believe this is something we'll fix with DNF
> > version 5, as the whole GPG check code is being massively reworked for
> > that.
>
> Ok, makes sense for the default setup. But I think those are in fact two
> related but separate things:
>  - signing repository metadata (infrastructure part)
>  - checking that signature in DNF by default (Fedora configuration)
>
> Is it possible to enable the first one, but leave the second to the
> user, until DNF is adjusted for better UX around the keys? That would
> allow power users to enable metadata verification manually (and accept
> that key import prompt).
>

Yes, this should be possible. File a ticket here:
https://pagure.io/fedora-infrastructure

> Is there any dnf command similar to `rpm --import`, to preemptively
> import the key, or the only option is to accept the prompt? I can't find
> anything about it in dnf's man page...
>

Alas, no. That's part of the problem here.



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

Re: Repository metadata signing?

2020-11-02 Thread Marek Marczykowski-Górecki

On Mon, Nov 02, 2020 at 07:33:18PM -0500, Neal Gompa wrote:
> The major remaining issue for us to start enabling repository GPG
> checks is that DNF doesn't use the RPM GPG keyring for repository
> metadata GPG signature validation, which can cause issues with our
> compose pipeline. I believe this is something we'll fix with DNF
> version 5, as the whole GPG check code is being massively reworked for
> that.

Ok, makes sense for the default setup. But I think those are in fact two
related but separate things:
 - signing repository metadata (infrastructure part)
 - checking that signature in DNF by default (Fedora configuration)

Is it possible to enable the first one, but leave the second to the
user, until DNF is adjusted for better UX around the keys? That would
allow power users to enable metadata verification manually (and accept
that key import prompt).

Is there any dnf command similar to `rpm --import`, to preemptively
import the key, or the only option is to accept the prompt? I can't find
anything about it in dnf's man page...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

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

2020-11-02 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/03/report-389-ds-base-2.0.0.0-20201103gitdb655bb.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 1893586] perl-IO-Pager-2.01 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-IO-Pager-2.00 is   |perl-IO-Pager-2.01 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.01
Current version/release in rawhide: 1.03-3.fc33
URL: http://search.cpan.org/dist/IO-Pager/

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


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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-39d5c8fd1e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-39d5c8fd1e

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


-- 
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 1893497] RFE - build a perl-Module-Install-ExtraTests package for EPEL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-82e06a230d 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-82e06a230d

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 1890598] EPEL8 Request: perl-Prima

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2020-8a996b01dc 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-8a996b01dc

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 1893424] perl-Prima-1.60 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-8a996b01dc 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-8a996b01dc

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 1893923] perl-Dist-Zilla-6.017 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-39d5c8fd1e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-39d5c8fd1e


-- 
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 1893541] perl-ExtUtils-CBuilder-0.280235 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-aaadc67270 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-aaadc67270`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-aaadc67270

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 1893495] perl-Pod-Markdown-3.300 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-0d1353b457 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-0d1353b457`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d1353b457

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 1893923] perl-Dist-Zilla-6.017 is available

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

Petr Šabata  changed:

   What|Removed |Added

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




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

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

2020-11-02 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b21ed088ad   
tcpreplay-4.3.3-3.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca0361c919   
lout-3.40-18.el6


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

wordpress-5.1.8-1.el6

Details about builds:



 wordpress-5.1.8-1.el6 (FEDORA-EPEL-2020-6bc42544ca)
 Blog tool and publishing platform

Update Information:

**WordPress 5.1.8 Maintenance Release**  This maintenance release fixes an issue
introduced in WordPress 5.1.7 which makes it impossible to install WordPress on
a brand new website that does not have a database connection configured.  
**WordPress 5.1.7 Security Release**  **Security Updates**  *Props to Alex
Concha of the WordPress Security Team for their work in hardening
deserialization requests. *Props to David Binovec on a fix to disable spam
embeds from disabled sites on a multisite network. *Thanks to Marc Montas
from Sucuri for reporting an issue that could lead to XSS from global variables.
*Thanks to Justin Tran who reported an issue surrounding privilege
escalation in XML-RPC. He also found and disclosed an issue around privilege
escalation around post commenting via XML-RPC. *Props to Omar Ganiev who
reported a method where a DoS attack could lead to RCE. *Thanks to Karim El
Ouerghemmi from RIPS who disclosed a method to store XSS in post slugs. *
Thanks to Slavco for reporting, and confirmation from Karim El Ouerghemmi, a
method to bypass protected meta that could lead to arbitrary file deletion. *
Thanks to Erwan LR from WPScan who responsibly disclosed a method that could
lead to CSRF. *And a special thanks to @zieladam who was integral in many of
the releases and patches during this release.

ChangeLog:

* Mon Nov  2 2020 Remi Collet  - 5.1.8-1
- WordPress 5.1.8 Maintenance Release
* Fri Oct 30 2020 Remi Collet  - 5.1.7-1
- WordPress 5.1.7 Security Release


___
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

[Bug 1879947] perl-Perl-Tidy-Sweetened-1.16-3.fc34 FTBFS: tests fail

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Perl-Tidy-Sweetened-1. |perl-Perl-Tidy-Sweetened-1.
   |16-4.fc34   |16-4.fc34
   |perl-Perl-Tidy-Sweetened-1. |perl-Perl-Tidy-Sweetened-1.
   |16-4.fc33   |16-4.fc33
   ||perl-Perl-Tidy-Sweetened-1.
   ||15-6.fc32



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-34fd4926d7 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

Self Introduction: John Kacur

2020-11-02 Thread John Kacur

Hello. My name is John Kacur
I'm a real-time developer with Red Hat, who I've been with for over 11 years.
Before that I worked for approximately 8 years with IBM on the compiler team.

I am the upstream co-maintainer of rt-tests that includes cyclictest
for real-time latency testing.
I am also the upstream co-maintainer of rteval that tests the ability
of hardware to run the real-time kernel.
I am also the RH packager of the above packages.

I am also an upstream co-maintainer of tuna, python-schedutils and
python-linux-procutils, and the RH packager of these packages as well.

There are probably a few other things that are relevant, but the most
important ones are listed above.

I have mostly been a lurker when it comes to Fedora development, but
hopefully that will change soon!

John Kacur
___
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 1893923] New: perl-Dist-Zilla-6.017 is available

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

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



Latest upstream release: 6.017
Current version/release in rawhide: 6.015-3.fc33
URL: http://search.cpan.org/dist/Dist-Zilla/

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


-- 
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 1879947] perl-Perl-Tidy-Sweetened-1.16-3.fc34 FTBFS: tests fail

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Perl-Tidy-Sweetened-1. |perl-Perl-Tidy-Sweetened-1.
   |16-4.fc34   |16-4.fc34
   ||perl-Perl-Tidy-Sweetened-1.
   ||16-4.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-03 00:58:00



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-b6adc5b697 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 1890363] perl-Test2-Suite-0.000138 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Test2-Suite-0.000138-1 |perl-Test2-Suite-0.000138-1
   |.fc34   |.fc34
   ||perl-Test2-Suite-0.000138-1
   ||.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-03 00:57:57



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


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

Re: Repository metadata signing?

2020-11-02 Thread Dennis Gilmore

It would require https://bugzilla.redhat.com/show_bug.cgi?id=1768206
to be fixed. Right now the design in dnf for supporting gpg keys is
quite user hostile, especially in automated unattended use cases.

Dennis

On Mon, Nov 2, 2020 at 6:25 PM Marek Marczykowski-Górecki
 wrote:
>
> Hello all,
>
> Are there any plans to have Fedora repository metadata signed? I think
> dnf supports it for a long time already. I know the packages themselves
> are already signed, but metadata do carry some extra information that
> potentially could be manipulated - for example to _selectively_ hide
> some updates, or to exploit metadata-parsing code (like in [1]).
>
> By default Fedora authenticates metadata using metalink downloaded over
> HTTPS from a Fedora-controlled infrastructure. But still an attack is
> possible with some rather extreme preconditions - namely to obtain a
> mis-issued certificate for mirrors.fedoraproject.org and MitM the
> connection. But also, if anyone set a specific mirror (examples to
> uncomment are over plain http, BTW) or use a 3rd-party repository that
> doesn't use metalinks, it is far easier to mount an attack on repository
> metadata.
>
> Additionally, signed metadata could reduce damage in case of
> metalink-hosting server compromise.
>
> I don't know much about Fedora infrastructure, but perhaps there is
> still something I could help with?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1868639
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> ___
> 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

Re: Repository metadata signing?

On Mon, Nov 2, 2020 at 7:24 PM Marek Marczykowski-Górecki
 wrote:
>
> Hello all,
>
> Are there any plans to have Fedora repository metadata signed? I think
> dnf supports it for a long time already. I know the packages themselves
> are already signed, but metadata do carry some extra information that
> potentially could be manipulated - for example to _selectively_ hide
> some updates, or to exploit metadata-parsing code (like in [1]).
>
> By default Fedora authenticates metadata using metalink downloaded over
> HTTPS from a Fedora-controlled infrastructure. But still an attack is
> possible with some rather extreme preconditions - namely to obtain a
> mis-issued certificate for mirrors.fedoraproject.org and MitM the
> connection. But also, if anyone set a specific mirror (examples to
> uncomment are over plain http, BTW) or use a 3rd-party repository that
> doesn't use metalinks, it is far easier to mount an attack on repository
> metadata.
>
> Additionally, signed metadata could reduce damage in case of
> metalink-hosting server compromise.
>
> I don't know much about Fedora infrastructure, but perhaps there is
> still something I could help with?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1868639
>

Repositories that don't use metalinks (and thus don't have
cryptographically strong secure checksums to validate the content
before processing) are encouraged to GPG sign metadata, and prior to
us migrating the openh264 repo to metalinks, we signed the repository
metadata there too. I believe it's still signed, we just don't verify
it by default anymore.

The major remaining issue for us to start enabling repository GPG
checks is that DNF doesn't use the RPM GPG keyring for repository
metadata GPG signature validation, which can cause issues with our
compose pipeline. I believe this is something we'll fix with DNF
version 5, as the whole GPG check code is being massively reworked for
that.



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

Repository metadata signing?

2020-11-02 Thread Marek Marczykowski-Górecki

Hello all,

Are there any plans to have Fedora repository metadata signed? I think
dnf supports it for a long time already. I know the packages themselves
are already signed, but metadata do carry some extra information that
potentially could be manipulated - for example to _selectively_ hide
some updates, or to exploit metadata-parsing code (like in [1]).

By default Fedora authenticates metadata using metalink downloaded over
HTTPS from a Fedora-controlled infrastructure. But still an attack is
possible with some rather extreme preconditions - namely to obtain a
mis-issued certificate for mirrors.fedoraproject.org and MitM the
connection. But also, if anyone set a specific mirror (examples to
uncomment are over plain http, BTW) or use a 3rd-party repository that
doesn't use metalinks, it is far easier to mount an attack on repository
metadata.

Additionally, signed metadata could reduce damage in case of
metalink-hosting server compromise.

I don't know much about Fedora infrastructure, but perhaps there is
still something I could help with?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1868639

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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: Fedora Security Team

On Tue, Nov 3, 2020 at 12:53 am, Marek Marczykowski-Górecki 
 wrote:

How are in practice security issues handled in Fedora? Is there an
active security team to help patching those in timely manner? Or is it
responsibility of individual package maintainers only?


Hi,

Red Hat Product Security is responsible for monitoring CVEs and 
reporting bugs when they determine that a CVE affects Fedora. Fixing 
the CVEs is the responsibility of individual package maintainers. Many 
maintainers respond to bugs expeditiously, but also it's pretty common 
for maintainers to ignore the bug reports filed by Product Security. 
Sometimes this has unfortunate results. It really differs on a 
component-by-component basis.


Michael

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

Fedora Security Team

2020-11-02 Thread Marek Marczykowski-Górecki

Hello all,

How are in practice security issues handled in Fedora? Is there an
active security team to help patching those in timely manner? Or is it
responsibility of individual package maintainers only? I've tried to
find some information on that, but the only thing I've found is this
page:

https://fedoraproject.org/wiki/Category:Security_Team

and few linked from there. And it doesn't look to be very up to date,
for example the last meeting listed there is from 2016, and also mailing
lists are silent.

I don't see also Fedora representative listed on linux-distros[1]
mailing list (but I do see Red Hat, so perhaps there is some information
sharing?).

I ask because in Qubes OS we use Fedora as a default OS in VMs, and
also as a base for the host (dom0) OS. While we do provide security
patches for critical components ourselves, I wonder what is the current
state for the base system.

[1]
https://oss-security.openwall.org/wiki/mailing-lists/distros#linux-distribution-security-contacts-list

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

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: What happened to quality debuginfo?


On Mon, Nov 2, 2020 at 5:23 pm, Keith Seitz  wrote:
It appears that this broke in the last rebase (to 9.2). I will see 
about

fixing it.


Thanks for the quick fix. Much appreciated!

___
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: EOL and Obsoletes in Modularity

2020-11-02 Thread Dan Čermák

Hi all,

Daniel Mach  writes:

> Hi,
>
>
> Dne 27. 10. 20 v 13:52 Martin Curlej napsal(a):
>> Hi,
>> 
>> EOL and Obsoletes were planned as a feature of Modularity. The feature 
>> should enable to set shorter/longer life cycles on Modules than the OS 
>> release. The initial idea was to set this information in the disgit 
>> metadata of a Module. As time went by the requirements have changed.
>
>  From DNF team's perspective, a packaging system is not complete without 
> Obsoletes. That's why we believe module Obsoletes are a must have to 
> ensure smooth system upgrades and regular updates on systems consuming 
> Rawhide (or any other rolling stream). I created a Fedora Change[1] 
> which got accepted already. We'll deliver support for module Obsoletes 
> in DNF as soon as possible and we hope it's going to be used in Fedora 
> 34 (or 35 at latest).
>
> The API is clear: DNF expects additional 'modulemd-obsoletes' YAML 
> documents in modules.yaml. The new document format is getting into 
> libmodulemd and there's going to be documentation on how to write it.
>
> Then there's a question how to get the documents into modules.yaml. From 
> my perspective, it's up to Fedora infra/releng/packaging people. Whether 
> it should be in dist-git, git repo (similar to modulemd-defaults or 
> comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's 
> entirely their call.

I think the package/module maintainer should be able to set the EOL and
obsoletes for their module in a simple fashion, preferably without
requiring to create tickets for releng or anyone else. So that leaves
dist-git as the only option, right?


Cheers,

Dan


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

FedoraRespin-32-updates-20201102.0 compose check report

No missing expected images.

Failed openQA tests: 2/37 (x86_64)

ID: 713808  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/713808
ID: 713841  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/713841

Soft failed openQA tests: 4/37 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 713811  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/713811
ID: 713822  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/713822
ID: 713832  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/713832
ID: 713839  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/713839

Passed openQA tests: 31/37 (x86_64)
-- 
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

Looking for sponsorship to be a package maintainer

2020-11-02 Thread Isaac True

Hello all,

I'm hoping to become the maintainer of an orphaned package (gr-iio, GNU Radio 
blocks for Analog Devices platforms) but I need some sponsorship to become a 
package maintainer. The releng team recommended that I send a message on this 
list to hopefully find someone.

I'm a software engineer and I've built a few .rpm's and .deb's over the years, 
so I'm already pretty capable at putting together a package. I would love for 
the opportunity to give back to the Fedora community, and to improve and 
unorphan a few packages.

Regarding the gr-iio package, I already know what needs to be done in order to 
bring it up to speed and compiling on the new Fedora versions, so it wouldn't 
be too much effort or take too long to get the new version of the package ready.

Regards,
Isaac___
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: Retiring ntp

2020-11-02 Thread Gary Buhrmaster

On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia  wrote:

> So, use "chrony" instead?

For some use cases, there is also the option of
systemd-timesyncd as a ntp client.

> Is the functionality sufficient

As always, given the different use cases, the answer
is maybe.

Here is a quick comparison: https://chrony.tuxfamily.org/comparison.html

> and can the ntp.conf files be ported gracefully to a
> compatible chrony.conf setting?

Again, it would depend on how you are using ntpd.
For the cases where the system is just a client of
the protocol trying keep the right time, it should be
easy to migrate to either chrony (or systemd-timesyncd).
If you are using hardware to discipline your server
using one/more of the hardware specific drivers
things get more complicated.
___
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: Retiring ntp

2020-11-02 Thread Nico Kadel-Garcia

On Mon, Nov 2, 2020 at 9:33 AM Miroslav Lichvar  wrote:
>
> I think we should consider retiring the ntp package. The upstream
> project is not in a good shape and it doesn't seem to be improving.
> Contributors left long time ago. The development is slow and happens
> behind closed doors. They still use bitkeeper.

So, use "chrony" instead?  Is the functionality sufficient, and can
the ntp.conf files be ported gracefully to a compatible chrony.conf
setting?
___
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: making download of filelists.xml(.zck) trigger on demand

2020-11-02 Thread clime

On Mon, 2 Nov 2020 at 21:38, Daniel Mach  wrote:
>
> Lazy file list loading? Yes, that's on DNF's TODO list already, but (to
> be honest) not on top - there's always something more important. It's
> not getting into DNF4, but it may get into DNF5 later on.

Ok, good to know.

Best regards
clime
>
>
> Dne 02. 11. 20 v 20:13 clime napsal(a):
> > On Mon, 2 Nov 2020 at 18:55, Vít Ondruch  wrote:
> >>
> >>
> >> Dne 01. 11. 20 v 11:58 clime napsal(a):
> >>> Hello!
> >>>
> >>> First of all, I don't really know what I am talking about here but I
> >>> noticed the `dnf update` operation downloads among other things
> >>> `filelists.xml` (optionally compressed by zchunk, thanks Jonathan
> >>> Dieter!!!) and I remember there was a thread on devel mailing quite
> >>> some time ago by Zbyszek from which I understood this data is only
> >>> needed when filesystem paths are used as package requirements or when
> >>> a fs path is specified as direct argument to `dnf install`.
> >>
> >>
> >> This was the case for Yum, but have never the case for DNF since its
> >> beginning. I think there were some reasons, such as that the solver in
> >> case it finds it needs them would need to stop, download the data and
> >> start from beginning. Other reason could be that nobody optimized it yet.
> >>
> >> Anyway, I guess you'll find more info in Bugzilla.
> >
> > Hello vit, thank you very much, I will try to look it up. M.
> >
> >>
> >>
> >> V.
> >>
> >>
> >>>Could we
> >>> then, please, trigger download of this file only if and when needed
> >>> and not sooner? It seems to take more than half of the total download
> >>> size e.g. for fedora-32-updates repo so it could improve repodata
> >>> download times quite significantly. Again, I don't really know what I
> >>> am talking about here but this came to my mind recently so I wanted to
> >>> write it down just in case it would be possible :).
> >>>
> >>> Thank you very much
> >>> clime
> >>> ___
> >>> 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 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

Re: Retiring ntp

2020-11-02 Thread Subsentient

I don't have objections to retiring the ntp tool, as long as there's something 
to take its place, and as long as a command argument compatible ntpdate tool 
still exists. I tend to use ntpdate much more often than I enable the ntp 
service. Right now ntpdate runs on boot on my PinePhone's Fedora 33 install.
___
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: Deprecating SCP

2020-11-02 Thread David Howells

Jakub Jelen  wrote:

> Today, I set up a copr repository with the current openssh from Fedora + the
> patch [2] for anyone to test and provide feedback, either here on the mailing
> list, or in the github PR according to ones preferences.

Does it work with connection sharing (ControlPath, ControlMaster,
ControlPersist config options)?

David
___
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-IoT-33-20201102.0 compose check report

No missing expected images.

Failed openQA tests: 3/15 (aarch64)

New failures (same test not failed in Fedora-IoT-33-20201029.2):

ID: 713790  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/713790
ID: 713794  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/713794
ID: 713804  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/713804

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

Old soft failures (same test soft failed in Fedora-IoT-33-20201029.2):

ID: 713774  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/713774

Passed openQA tests: 12/15 (aarch64), 15/16 (x86_64)

New passes (same test not passed in Fedora-IoT-33-20201029.2):

ID: 713791  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/713791
ID: 713792  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/713792
ID: 713793  Test: aarch64 IoT-dvd_ostree-iso base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/713793
ID: 713795  Test: aarch64 IoT-dvd_ostree-iso base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/713795
ID: 713796  Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/713796
ID: 713797  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/713797
ID: 713798  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/713798
ID: 713799  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/713799
ID: 713800  Test: aarch64 IoT-dvd_ostree-iso base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/713800
ID: 713801  Test: aarch64 IoT-dvd_ostree-iso iot_greenboot@uefi
URL: https://openqa.fedoraproject.org/tests/713801
ID: 713802  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/713802
ID: 713803  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/713803
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: making download of filelists.xml(.zck) trigger on demand

2020-11-02 Thread Daniel Mach

Lazy file list loading? Yes, that's on DNF's TODO list already, but (to 
be honest) not on top - there's always something more important. It's 
not getting into DNF4, but it may get into DNF5 later on.



Dne 02. 11. 20 v 20:13 clime napsal(a):

On Mon, 2 Nov 2020 at 18:55, Vít Ondruch  wrote:



Dne 01. 11. 20 v 11:58 clime napsal(a):

Hello!

First of all, I don't really know what I am talking about here but I
noticed the `dnf update` operation downloads among other things
`filelists.xml` (optionally compressed by zchunk, thanks Jonathan
Dieter!!!) and I remember there was a thread on devel mailing quite
some time ago by Zbyszek from which I understood this data is only
needed when filesystem paths are used as package requirements or when
a fs path is specified as direct argument to `dnf install`.



This was the case for Yum, but have never the case for DNF since its
beginning. I think there were some reasons, such as that the solver in
case it finds it needs them would need to stop, download the data and
start from beginning. Other reason could be that nobody optimized it yet.

Anyway, I guess you'll find more info in Bugzilla.


Hello vit, thank you very much, I will try to look it up. M.




V.



   Could we
then, please, trigger download of this file only if and when needed
and not sooner? It seems to take more than half of the total download
size e.g. for fedora-32-updates repo so it could improve repodata
download times quite significantly. Again, I don't really know what I
am talking about here but this came to my mind recently so I wanted to
write it down just in case it would be possible :).

Thank you very much
clime
___
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 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

[Bug 1893873] New: perl-CPANPLUS-Dist-Fedora-0.4.0 is available

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

Bug ID: 1893873
   Summary: perl-CPANPLUS-Dist-Fedora-0.4.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPANPLUS-Dist-Fedora
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.4.0
Current version/release in rawhide: 0.2.3-1.fc34
URL: http://search.cpan.org/dist/CPANPLUS-Dist-Fedora/

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


-- 
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: PR 4417 - CL trimming triggering high CPU

2020-11-02 Thread Mark Reynolds


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

--

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

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

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|lkund...@v3.sk  |emman...@seyman.fr
  Flags|needinfo?(emmanuel@seyman.f |
   |r)  |



--- Comment #2 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/30221
https://pagure.io/releng/fedora-scm-requests/issue/30222


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

[Test-Announce] [Test Day] FCOS 33 2020-11-06 to 2020-11-12

2020-11-02 Thread Sumantro Mukherjee

Greetings Testers!

The Fedora 33 CoreOS Test Day focuses on testing FCOS based on Fedora 33.
The FCOS `next` stream is already rebased on Fedora 33 content, which will
be coming soon to `testing` and `stable`. To prepare for the content being
promoted to other streams the Fedora CoreOS and QA teams have organized a
test day on Friday, November 06, 2020 (results accepted through Thursday,
November 12).

Relevant links:

- FCOS tracker: https://github.com/coreos/fedora-coreos-tracker/issues/659
- QA ticket: https://pagure.io/fedora-qa/issue/656
- Wiki : https://fedoraproject.org/wiki/Test_Day:Fedora_33_CoreOS_2020-11-06
- Test result : https://testdays.fedorainfracloud.org/events/98
- fedocal : https://apps.fedoraproject.org/calendar/QA/2020/11/6/#m9839


See you all on Friday!

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
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: making download of filelists.xml(.zck) trigger on demand

2020-11-02 Thread clime

On Mon, 2 Nov 2020 at 18:55, Vít Ondruch  wrote:
>
>
> Dne 01. 11. 20 v 11:58 clime napsal(a):
> > Hello!
> >
> > First of all, I don't really know what I am talking about here but I
> > noticed the `dnf update` operation downloads among other things
> > `filelists.xml` (optionally compressed by zchunk, thanks Jonathan
> > Dieter!!!) and I remember there was a thread on devel mailing quite
> > some time ago by Zbyszek from which I understood this data is only
> > needed when filesystem paths are used as package requirements or when
> > a fs path is specified as direct argument to `dnf install`.
>
>
> This was the case for Yum, but have never the case for DNF since its
> beginning. I think there were some reasons, such as that the solver in
> case it finds it needs them would need to stop, download the data and
> start from beginning. Other reason could be that nobody optimized it yet.
>
> Anyway, I guess you'll find more info in Bugzilla.

Hello vit, thank you very much, I will try to look it up. M.

>
>
> V.
>
>
> >   Could we
> > then, please, trigger download of this file only if and when needed
> > and not sooner? It seems to take more than half of the total download
> > size e.g. for fedora-32-updates repo so it could improve repodata
> > download times quite significantly. Again, I don't really know what I
> > am talking about here but this came to my mind recently so I wanted to
> > write it down just in case it would be possible :).
> >
> > Thank you very much
> > clime
> > ___
> > 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 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: Self Introduction: Emmett Boudreau

2020-11-02 Thread Dan Čermák

Welcome Emmett,

great to see more scientists coming to Fedora. Hope you'll have a good
time here and achieve great things!


Cheers,

Dan

"Emmett Boudreau"  writes:

> Hello, my name is Emmett Boudreau. I am a statistician and data scientist who 
> has fallen in love with the stability of Fedora over the years. I have been 
> involved with open source software for several years, but only now have 
> desired to be part of a maintenance team for some packages. The main reason I 
> would like to do this is in order to keep the packages on the data science 
> front well-maintained, notably the Julia programming language -- where there 
> could even be installations of different versions. I have found that Fedora 
> is a very popular choice among my colleagues, and I think that keeping these 
> packages in order would make the distribution better overall to work in.
> Thank you for your time!
> ___
> 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


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

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

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 12/181 (x86_64), 14/117 (aarch64)

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

ID: 713495  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/713495
ID: 713666  Test: aarch64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/713666

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

ID: 713439  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/713439
ID: 713443  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/713443
ID: 713483  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/713483
ID: 713496  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/713496
ID: 713530  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/713530
ID: 713535  Test: aarch64 Server-dvd-iso 
server_role_deploy_database_server@uefi
URL: https://openqa.fedoraproject.org/tests/713535
ID: 713546  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/713546
ID: 713552  Test: aarch64 Server-dvd-iso server_database_client@uefi
URL: https://openqa.fedoraproject.org/tests/713552
ID: 713568  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/713568
ID: 713586  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/713586
ID: 713631  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/713631
ID: 713632  Test: x86_64 universal install_resize_lvm
URL: https://openqa.fedoraproject.org/tests/713632
ID: 713686  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/713686
ID: 713690  Test: aarch64 universal install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/713690
ID: 713697  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/713697
ID: 713698  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/713698
ID: 713711  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/713711
ID: 713713  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/713713
ID: 713715  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/713715
ID: 713716  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/713716
ID: 713717  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/713717
ID: 713718  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/713718
ID: 713719  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/713719
ID: 713720  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/713720

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

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

ID: 713478  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/713478
ID: 713514  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/713514
ID: 713583  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/713583
ID: 713600  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/713600

Passed openQA tests: 166/181 (x86_64), 102/117 (aarch64)

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

ID: 713467  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/713467
ID: 713474  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/713474
ID: 713498  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/713498
ID: 713499  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/713499
ID: 713500  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/713500
ID: 713501  Test: x86_64

Re: What happened to quality debuginfo?


On Mon, Nov 2, 2020 at 5:23 pm, Keith Seitz  wrote:

In the meantime, does using debuginfod work?

export DEBUGINFOD_URLS=https://debuginfod.elfutils.org

Setting this in your env /should/ cause any missing debuginfo to be 
automatically
downloaded (by just about any tool requiring debuginfo, e.g, gdb, 
binutils)


Hm, it sort of works. For a test, I launch gnome-calculator, hit Ctrl+C 
once it loads, and generate a backtrace. I see it used existing 
debuginfo for glibc, but didn't download anything for glib:


$ export DEBUGINFOD_URLS=https://debuginfod.elfutils.org
$ gdb gnome-calculator
GNU gdb (GDB) Fedora 9.2-7.fc33
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
   .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gnome-calculator...
Reading symbols from .gnu_debugdata for /usr/bin/gnome-calculator...
(No debugging symbols found in .gnu_debugdata for 
/usr/bin/gnome-calculator)

(gdb) bt full
No stack.
(gdb) r
Starting program: /usr/bin/gnome-calculator
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe7f14640 (LWP 36182)]
[New Thread 0x7fffe7713640 (LWP 36183)]
[New Thread 0x7fffe6d79640 (LWP 36202)]
[New Thread 0x7fffe5883640 (LWP 36205)]
[New Thread 0x7fffe5082640 (LWP 36206)]
[Thread 0x7fffe5082640 (LWP 36206) exited]
^C
Thread 1 "gnome-calculato" received signal SIGINT, Interrupt.
0x76d32a0f in __GI___poll (fds=0x55617b20, nfds=3, 
timeout=13135)

   at ../sysdeps/unix/sysv/linux/poll.c:29
29 return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) bt full
#0 0x76d32a0f in __GI___poll
   (fds=0x55617b20, nfds=3, timeout=13135)
   at ../sysdeps/unix/sysv/linux/poll.c:29
   sc_ret = -516
   sc_cancel_oldtype = 0
#1 0x77f1dd1e in g_main_context_iterate.constprop ()
   at /lib64/libglib-2.0.so.0
#2 0x77eca41f in g_main_context_iteration ()
   at /lib64/libglib-2.0.so.0
#3 0x7746d3e5 in g_application_run () at /lib64/libgio-2.0.so.0
#4 0x55562162 in main ()

So that is a fail.

Next test: launch gnome-calculator without gdb, run 'killall -SEGV 
gnome-calculator', and then run 'coredumpctl gdb' and 'bt full'. Result 
is the same: no debuginfo for glib.


Third test: run gnome-calculator, and while running, 'gdb -p `pidof 
gnome-calculator`. Result is the same: no debuginfo for glib.


I do see that it is capable of downloading some debuginfo. E.g. when I 
attached to goa-daemon, I saw:


Downloading separate debug info for /lib64/libc.so.6...
Downloading separate debug info for /lib64/libpthread.so.0...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
--Type  for more, q to quit, c to continue without paging--c
Downloading separate debug info for /lib64/libresolv.so.2...
Downloading separate debug info for /lib64/ld-linux-x86-64.so.2...
Downloading separate debug info for /lib64/librt.so.1...
Downloading separate debug info for /lib64/libsystemd.so.0...
Downloading separate debug info for 
/home/mcatanzaro/.cache/debuginfod_client/78dab7efffc09e12cb1d33fec9e0e4fd0a0b974a/debuginfo...

Downloading separate debug info for /lib64/libdl.so.2...
Downloading separate debug info for /lib64/libstdc++.so.6...
Downloading separate debug info for 
/home/mcatanzaro/.cache/debuginfod_client/8a631bbf2acdfdaf554335bb9e8a04dd4e3e9c17/debuginfo...

Downloading separate debug info for /lib64/libm.so.6...
Downloading separate debug info for /lib64/libgcc_s.so.1...
Downloading separate debug info for /lib64/libdw.so.1...
Downloading separate debug info for 
/home/mcatanzaro/.cache/debuginfod_client/e32142f3e8a9c7834dba57d6f2d7e082744876e9/debuginfo...

Downloading separate debug info for /lib64/libelf.so.1...
Downloading separate debug info for /lib64/libdebuginfod-0.181.so...
Downloading separate debug info for /lib64/libnss_files.so.2...
Downloading separate debug info for /lib64/libnss_resolve.so.2...
Downloading separate debug info for /home/mcatanzaro/system-supplied 
DSO at 0x7fff9d56b000...


That's cool. But again, no debuginfo for glib, sadly:

#0 0x7f0211851a0f in __GI___poll (fds=0x55f9b84074f0, nfds=2, 
timeout=-1)

   at ../sysdeps/unix/sysv/linux/poll.c:29
   sc_ret = -516
   sc_cancel_oldtype = 0
#1 0x7f02119c9d1e in g_main_context_iterate.constprop ()
   at /lib64/libglib-2.0.so.0
#2

Re: making download of filelists.xml(.zck) trigger on demand

2020-11-02 Thread Vít Ondruch



Dne 01. 11. 20 v 11:58 clime napsal(a):

Hello!

First of all, I don't really know what I am talking about here but I
noticed the `dnf update` operation downloads among other things
`filelists.xml` (optionally compressed by zchunk, thanks Jonathan
Dieter!!!) and I remember there was a thread on devel mailing quite
some time ago by Zbyszek from which I understood this data is only
needed when filesystem paths are used as package requirements or when
a fs path is specified as direct argument to `dnf install`.



This was the case for Yum, but have never the case for DNF since its 
beginning. I think there were some reasons, such as that the solver in 
case it finds it needs them would need to stop, download the data and 
start from beginning. Other reason could be that nobody optimized it yet.


Anyway, I guess you'll find more info in Bugzilla.


V.



  Could we
then, please, trigger download of this file only if and when needed
and not sooner? It seems to take more than half of the total download
size e.g. for fedora-32-updates repo so it could improve repodata
download times quite significantly. Again, I don't really know what I
am talking about here but this came to my mind recently so I wanted to
write it down just in case it would be possible :).

Thank you very much
clime
___
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

[389-devel] please review: PR 4416 - lib389 - unable to query schema if there are extra parenthesis

2020-11-02 Thread Mark Reynolds


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

--

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: Deprecating SCP

On Monday, November 2, 2020 6:31:33 PM CET Florian Weimer wrote:
> * Kamil Dudka:
> > On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote:
> >> * Kamil Dudka:
> >> > As far as I know, (lib)curl has never silently transformed a protocol
> >> > scheme explicitly specified with URL.  This can be discussed upstream
> >> > but I do not feel like starting the discussion myself.
> >> 
> >> Curl does it for https://, so it should be fine for scp://.
> > 
> > Could you please be more specific?  What exactly does curl do for https://
> > ?
> It automatically replaces the underlying HTTP transport with HTTP/2 if
> the server replaces it.  These protocols are about as similar as SCP and
> SFTP, I would say.

Thank you for clarifying it!

The key difference is that the HTTP protocol upgrade to HTTP/2 (or HTTP/3
via Alt-Svc header) are covered by IETF specifications.  There is also no 
protocol scheme to specify HTTP/2 explicitly in URL, unlike SCP vs. SFTP.

Kamil

> Thanks,
> Florian

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

Re: Retiring ntp

On Mon, Nov 02, 2020 at 06:09:18PM +0100, BjÃ¶rn Persson wrote:
> Miroslav Lichvar wrote:
> > The main problem is that they don't fix all known security issues. In
> > the CVE list I see about 10 issues that were not fixed at all or only
> > partially, some exploitable in default configuration.
> 
> That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.

There is no official list. You would need to inspect the code to see
what have been actually fixed. For some CVEs they only provided
mitigations and in some cases the fixes were wrong or incomplete.
You can look for my comments in the upstream bugzilla.

The list of 10 issues that I think are not (fully) fixed yet follows.
Probably not complete or completely accurate, but if you need details
about a specific issue, I can check the code.

CVE-2013-5211
CVE-2015-7705
CVE-2015-7974
CVE-2015-7979
CVE-2015-8139
CVE-2016-1548
CVE-2016-4955
CVE-2016-7426
CVE-2018-7170
CVE-2020-13817

-- 
Miroslav Lichvar
___
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: Retiring ntp

On Mon, Nov 2, 2020 at 12:37 PM PGNet Dev  wrote:
>
> On 11/2/20 9:22 AM, Neal Gompa wrote:
> > Work migrated to Chrony a year or so ago. The only thing I use from
> > ntp is the "ntpdate" tool. Everything else is chrony now. :)
>
> out of curiosity, what's lacking for your use case?
>
> ntpdate, here, was primarily for "set it now" interventions.
>
> that, at least, is easily done with
>
>chronyd -q 'server  iburst'

Mostly third-party scripts and programs that have it hardcoded.
Otherwise I wouldn't use it at all.


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

Re: Retiring ntp

2020-11-02 Thread PGNet Dev


On 11/2/20 9:22 AM, Neal Gompa wrote:

Work migrated to Chrony a year or so ago. The only thing I use from
ntp is the "ntpdate" tool. Everything else is chrony now. :)


out of curiosity, what's lacking for your use case?

ntpdate, here, was primarily for "set it now" interventions.

that, at least, is easily done with

  chronyd -q 'server  iburst'
___
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: Deprecating SCP

2020-11-02 Thread Florian Weimer

* Kamil Dudka:

> On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote:
>> * Kamil Dudka:
>> 
>> 
>> > As far as I know, (lib)curl has never silently transformed a protocol
>> > scheme explicitly specified with URL.  This can be discussed upstream
>> > but I do not feel like starting the discussion myself.
>> 
>> 
>> Curl does it for https://, so it should be fine for scp://.
>
> Could you please be more specific?  What exactly does curl do for https:// ?

It automatically replaces the underlying HTTP transport with HTTP/2 if
the server replaces it.  These protocols are about as similar as SCP and
SFTP, I would say.

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: Deprecating SCP

On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote:
> * Kamil Dudka:
> 
> 
> > As far as I know, (lib)curl has never silently transformed a protocol
> > scheme explicitly specified with URL.  This can be discussed upstream
> > but I do not feel like starting the discussion myself.
> 
> 
> Curl does it for https://, so it should be fine for scp://.

Could you please be more specific?  What exactly does curl do for https:// ?

Kamil

> 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: Retiring ntp

On Mon, Nov 2, 2020 at 12:10 PM Björn Persson  wrote:
>
> Miroslav Lichvar wrote:
> > The main problem is that they don't fix all known security issues. In
> > the CVE list I see about 10 issues that were not fixed at all or only
> > partially, some exploitable in default configuration.
>
> That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.
>
> > I'm not sure how many users of ntp are there. As a replacement, we
> > could package ntpsec.
>
> Judging only from their own website, it seems that switching to NTPsec
> would be a great improvement.
>
> I'll have to investigate whether I can migrate all my usecases to
> Chrony.
>

Work migrated to Chrony a year or so ago. The only thing I use from
ntp is the "ntpdate" tool. Everything else is chrony now. :)



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

Re: What happened to quality debuginfo?

2020-11-02 Thread Keith Seitz

It appears that this broke in the last rebase (to 9.2). I will see about
fixing it.

In the meantime, does using debuginfod work?

export DEBUGINFOD_URLS=https://debuginfod.elfutils.org

Setting this in your env /should/ cause any missing debuginfo to be 
automatically
downloaded (by just about any tool requiring debuginfo, e.g, gdb, binutils)
___
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 happened to quality debuginfo?

On Mon, Nov 2, 2020 at 11:39 am, Zbigniew Jędrzejewski-Szmek 
 wrote:

Yep, I can confirm this, the hint about debuginfo is gone.
After I install appropriate debuginfo packages, the backtrace shows 
all the details.

So it seems that it's just the hint that is missing.


OK, that's sort of good to know.

I found: https://bugzilla.redhat.com/show_bug.cgi?id=1887025 so we can 
continue discussion there.


___
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: Retiring ntp

2020-11-02 Thread Björn Persson

Miroslav Lichvar wrote:
> The main problem is that they don't fix all known security issues. In
> the CVE list I see about 10 issues that were not fixed at all or only
> partially, some exploitable in default configuration.

That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.

> I'm not sure how many users of ntp are there. As a replacement, we
> could package ntpsec.

Judging only from their own website, it seems that switching to NTPsec
would be a great improvement.

I'll have to investigate whether I can migrate all my usecases to
Chrony.

Björn Persson


pgpwYLWhtsbwn.pgp
Description: OpenPGP digital signatur
___
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: Deprecating SCP

2020-11-02 Thread Florian Weimer

* Kamil Dudka:

> As far as I know, (lib)curl has never silently transformed a protocol scheme 
> explicitly specified with URL.  This can be discussed upstream but I do not 
> feel like starting the discussion myself.

Curl does it for https://, so it should be fine for scp://.

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: Deprecating SCP

On Monday, November 2, 2020 4:47:47 PM CET Simo Sorce wrote:
> On Mon, 2020-11-02 at 16:36 +0100, Kamil Dudka wrote:
> > How is the "compatibility scpd to support old clients" going to differ
> > from the current implementation?
> > 
> > libcurl implements its own SCP client over libssh.  Will this
> > implementation 
> > continue to work after OpenSSH gets updated on servers?
> > 
> > Applications often allow users to pass arbitrary URLs to libcurl.  So one
> > can, 
> > for example, use scp:// URLs to specify a kickstart for Anaconda. 
> > The fact that scp utility will be reimplemented over SFTP does not help
> > much in this case.  Each build of libcurl that supports scp:// supports
> > sftp:// as well. But libcurl will not transmit scp:// requests over
> > sftp:// in case SCP is not supported by the remote server any more.
> 
> 
> Sounds like a RFE for libcurl to slowly move scp:// to be using the
> sftp protocol instead ?

As far as I know, (lib)curl has never silently transformed a protocol scheme 
explicitly specified with URL.  This can be discussed upstream but I do not 
feel like starting the discussion myself.

> Or they could simply deprecate it, and then users will have to change
> their config to say sftp://
> 
> For something like libcurl the latter is probably more appropriate
> anyway.

Yes, I believe this is the curl way to handle it.  Nothing is being changed 
for curl now as I understand it.  So there is no need to take an immediate 
action.  Anyway, I will notify curl upstream about the plan so they are not 
surprised later on.

Kamil

> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc

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

Re: ld segfaults on rawhide

2020-11-02 Thread Justin Forbes

On Sat, Oct 31, 2020 at 10:32 AM Jeff Law  wrote:
>
>
> On 10/31/20 9:13 AM, Christoph Junghans wrote:
> > Hi,
> >
> > I am getting the following error on all archs on rawhide:
> > collect2: fatal error: ld terminated with signal 11 [Segmentation
> > fault], core dumped
> > in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411
> >
> > any ideas?
>
> Given it's happening on multiple architectures, I'd guess its a linker
> bug of some kind.
>

Definitely seems to be. Killed every arch for the kernel builds today as well.

Justin
___
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: Retiring ntp

2020-11-02 Thread Steven A. Falco


On 11/2/20 10:37 AM, Miroslav Lichvar wrote:

On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:

I use ntp heavily for multiple stratum 1 timeservers here.  If you drop ntp, I 
will have to build my own from source.  Not a big problem, but I'd personally 
like to see ntp stay available in Fedora.


I have few stratum-1 servers too, but I'm not running ntp.

What reference clock do you have? Unless it's something very rare, you
shouldn't need ntp for that. GPS receivers are well supported by gpsd
and ntpsec kept most of the ntpd drivers for hardware that is still
widely used.


I played around for a while with gpsd and never could get it to behave 
properly.  My ref clocks are NMEA, and I thought gpsd would be easy, but 
sometimes it wouldn't recognize the PPS, other times it was off by 1 second or 
showed milliseconds of error.  So in the end I went back to plain ntp.

I'll try ntpsec.

Steve
___
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: 20201102.n.0 changes

2020-11-02 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20201101.n.0
NEW: Fedora-Rawhide-20201102.n.0

= SUMMARY =
Added images:1
Dropped images:  3
Added packages:  2
Dropped packages:0
Upgraded packages:   35
Downgraded packages: 0

Size of added packages:  61.56 KiB
Size of dropped packages:0 B
Size of upgraded packages:   455.25 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20201102.n.0.iso

= DROPPED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201101.n.0-sda.raw.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201101.n.0.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201101.n.0.s390x.qcow2

= ADDED PACKAGES =
Package: freeipa-fas-0.0.4-1.fc34
Summary: Fedora Account System extension for FreeIPA
RPMs:freeipa-fas
Size:44.87 KiB

Package: python-pytest-mpi-0.4-2.fc34
Summary: Pytest plugin for running tests under MPI
RPMs:python3-pytest-mpi
Size:16.70 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Thunar-1.8.16-1.fc34
Old package:  Thunar-1.8.15-3.fc33
Summary:  Thunar File Manager
RPMs: Thunar Thunar-devel Thunar-docs
Size: 10.12 MiB
Size change:  -1.93 KiB
Changelog:
  * Sun Nov 01 2020 Mukundan Ragavan  - 1.8.16-1
  - Update to 1.8.16


Package:  arpwatch-14:2.1a15-52.fc34
Old package:  arpwatch-14:2.1a15-50.fc34
Summary:  Network monitoring tools for tracking IP addresses on a network
RPMs: arpwatch
Size: 966.74 KiB
Size change:  1.48 KiB
Changelog:
  * Sat Oct 31 2020 Benjamin A. Beasley  - 14:2.1a15-51
  - add rpmlintrc file to suppress expected rpmlint errors

  * Sat Oct 31 2020 Benjamin A. Beasley  - 14:2.1a15-52
  - add rpmlintrc file to suppress expected rpmlint errors
  - touch ghost file arp.dat.new (ghost files should exist in the buildroot)


Package:  bouncycastle-1.67-1.fc34
Old package:  bouncycastle-1.65-4.fc33
Summary:  Bouncy Castle Cryptography APIs for Java
RPMs: bouncycastle bouncycastle-javadoc bouncycastle-mail 
bouncycastle-pg bouncycastle-pkix bouncycastle-tls
Size: 10.65 MiB
Size change:  195.61 KiB
Changelog:
  * Sun Nov 01 2020 Mat Booth  - 1.67-1
  - Update to latest upstream release


Package:  ccls-0.20201025-1.fc34
Old package:  ccls-0.20190823.6-4.fc33
Summary:  C/C++/ObjC language server
RPMs: ccls
Size: 2.38 MiB
Size change:  -3.85 KiB
Changelog:
  * Mon Nov 02 2020 Dan ??erm??k  - 0.20201025-1
  - New upstream release 0.20201025 (rhbz#1891388)


Package:  cmst-2020.11.01-1.fc34
Old package:  cmst-2020.05.09-2.fc33
Summary:  A Qt based GUI front end for the connman connection manager with 
systemtray icon
RPMs: cmst
Size: 11.25 MiB
Size change:  344.84 KiB
Changelog:
  * Sun Nov 01 2020 Martin Gansser  - 2020.11.01-1
  - Update to 2020.11.01-1


Package:  dialect-1.1.0-2.fc34
Old package:  dialect-1.0.0-1.fc34
Summary:  A translation app for GNOME based on Google Translate
RPMs: dialect
Size: 47.25 KiB
Size change:  10.28 KiB
Changelog:
  * Sun Nov 01 2020 Lyes Saadi  - 1.1.0-1
  - Updating to 1.1.0 (Fix #1893399)

  * Sun Nov 01 2020 Lyes Saadi  - 1.1.0-2
  - Adding some unpackaged files


Package:  drawing-0.6.3-1.fc34
Old package:  drawing-0.6.2-1.fc34
Summary:  Drawing application for the GNOME desktop
RPMs: drawing
Size: 2.40 MiB
Size change:  11.47 KiB
Changelog:
  * Sun Nov 01 2020 Artem Polishchuk  - 0.6.3-1
  - build(update): 0.6.3


Package:  dummy-test-package-crested-0-2084
Old package:  dummy-test-package-crested-0-2071
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 134.41 KiB
Size change:  802 B
Changelog:
  * Sun Nov 01 2020 packagerbot  - 0-2072
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2073
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2074
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2075
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2076
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2077
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2078
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2079
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2080
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2081
  - rebuilt

  * Sun Nov 01 2020 packagerbot  - 0-2082
  - rebuilt

  * Mon Nov 02 2020 packagerbot  - 0-2083
  - rebuilt

  * Mon Nov 02 2020 packagerbot  - 0-2084
  - rebuilt


Package:  dummy-test-package-gloster-0-1970.fc34
Old package:  dummy-test-package-gloster-0-1956.fc34
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 126.31 KiB
Size change

Re: Deprecating SCP

2020-11-02 Thread Jakub Jelinek

On Mon, Nov 02, 2020 at 03:44:39PM +0100, Jakub Jelen wrote:
> Over the last years, there were several issues in the SCP protocol, which
> lead us into discussions if we can get rid of it in upstream [1]. Most of
> the voices there said that they use SCP mostly for simple ad-hoc copy and
> because sftp utility does not provide simple interface to copy one or couple
> of files back and forth and because of people are just used to write scp
> rather than sftp.
> 
> Some months ago, I wrote a patch [2] for scp to use SFTP internally (with
> possibility to change it back using -M scp) and ran it through some
> successful testing. The general feedback from upstream was also quite
> positive so I would like to hear also opinions from our users.

Has that testing included performance measurements, both on high bandwidth
low-latency transfers and low bandwidth high-latency transfers?
At least in the past SFTP used to be worse than SCP on high-latency
connections.

Jakub
___
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: Deprecating SCP

2020-11-02 Thread Nicolas Mailhot via devel

Le lundi 02 novembre 2020 à 16:16 +0100, Marius Schwarz a écrit :
> Am 02.11.20 um 16:13 schrieb Solomon Peachy:
> > On Mon, Nov 02, 2020 at 03:44:39PM +0100, Jakub Jelen wrote:
> > > I am looking for any kind of feedback from the idea through the
> > > usability,
> > > implementation. Is this something you would like to see in Fedora
> > > soon? Do
> > > you have something against this? Is your use case missing?
> > I like it!  scp-the-tool (including command/filename completion!)
> > is
> > just so much nicer to work with than sftp-the-tool.
> Well, thats a nice feature requirement, almost forgot about it.

Well lftp-the-tool is even better. And they all do the same thing from
a functional POW, only the underlying protocol changes. This is sad,
the user wouldn’t care less about protocol differences (as he would not
care less about TLS negociation, as long as the resulting recipe is
steong)

User attachment to different tools is a legacy of other OSes where one
protocol is built in and the others not.

Regards,

-- 
Nicolas Mailhot
___
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 1893788] New: EPEL8 request: perl-Mail-IMAPClient

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

Bug ID: 1893788
   Summary: EPEL8 request: perl-Mail-IMAPClient
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Mail-IMAPClient
  Assignee: spo...@gmail.com
  Reporter: jakub.jedel...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Hello, I would appreciate if you could build perl-Mail-IMAPClient for EPEL8.
Feel free to add me as co-maintainer (kubo), I'll be happy to help you.


-- 
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: Deprecating SCP

2020-11-02 Thread Jakub Jelen


On 11/2/20 4:36 PM, Kamil Dudka wrote:

On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote:

Hi Fedora users!

Over the last years, there were several issues in the SCP protocol,
which lead us into discussions if we can get rid of it in upstream [1].
Most of the voices there said that they use SCP mostly for simple ad-hoc
copy and because sftp utility does not provide simple interface to copy
one or couple of files back and forth and because of people are just
used to write scp rather than sftp.

Some months ago, I wrote a patch [2] for scp to use SFTP internally
(with possibility to change it back using -M scp) and ran it through
some successful testing. The general feedback from upstream was also
quite positive so I would like to hear also opinions from our users.

It still has some limitations (missing -3 support, it will not work if
the server does not run sftp subsystem, ...), but it should be good
enough for most common use cases.

Today, I set up a copr repository with the current openssh from Fedora +
the patch [2] for anyone to test and provide feedback, either here on
the mailing list, or in the github PR according to ones preferences.

I am looking for any kind of feedback from the idea through the
usability, implementation. Is this something you would like to see in
Fedora soon? Do you have something against this? Is your use case missing?

[1]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html
[2] https://github.com/openssh/openssh-portable/pull/194/
[3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/


How is the "compatibility scpd to support old clients" going to differ
from the current implementation?


I can think of a solution that in the end, there will be just the server 
parts of the current scp and the client code branches will be gone or 
support sftp only. But this can change as we are not there yet.



libcurl implements its own SCP client over libssh.  Will this implementation
continue to work after OpenSSH gets updated on servers?


With the above update, everything will work as before -- it affects only 
the client scp binary.



Applications often allow users to pass arbitrary URLs to libcurl.  So one can,
for example, use scp:// URLs to specify a kickstart for Anaconda.  The fact
that scp utility will be reimplemented over SFTP does not help much in this
case.  Each build of libcurl that supports scp:// supports sftp:// as well.
But libcurl will not transmit scp:// requests over sftp:// in case SCP is not
supported by the remote server any more.


As Simo wrote, I think it is something that will have to happen sooner 
or later inside of libcurl or libssh or in users configurations. But 
again, the above change should not have any effect on this.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Deprecating SCP

2020-11-02 Thread Simo Sorce

On Mon, 2020-11-02 at 16:36 +0100, Kamil Dudka wrote:
> On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote:
> > Hi Fedora users!
> > 
> > Over the last years, there were several issues in the SCP protocol, 
> > which lead us into discussions if we can get rid of it in upstream [1]. 
> > Most of the voices there said that they use SCP mostly for simple ad-hoc 
> > copy and because sftp utility does not provide simple interface to copy 
> > one or couple of files back and forth and because of people are just 
> > used to write scp rather than sftp.
> > 
> > Some months ago, I wrote a patch [2] for scp to use SFTP internally 
> > (with possibility to change it back using -M scp) and ran it through 
> > some successful testing. The general feedback from upstream was also 
> > quite positive so I would like to hear also opinions from our users.
> > 
> > It still has some limitations (missing -3 support, it will not work if 
> > the server does not run sftp subsystem, ...), but it should be good 
> > enough for most common use cases.
> > 
> > Today, I set up a copr repository with the current openssh from Fedora + 
> > the patch [2] for anyone to test and provide feedback, either here on 
> > the mailing list, or in the github PR according to ones preferences.
> > 
> > I am looking for any kind of feedback from the idea through the 
> > usability, implementation. Is this something you would like to see in 
> > Fedora soon? Do you have something against this? Is your use case missing?
> > 
> > [1] 
> > https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html
> > [2] https://github.com/openssh/openssh-portable/pull/194/
> > [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/
> 
> How is the "compatibility scpd to support old clients" going to differ
> from the current implementation?
> 
> libcurl implements its own SCP client over libssh.  Will this implementation 
> continue to work after OpenSSH gets updated on servers?
> 
> Applications often allow users to pass arbitrary URLs to libcurl.  So one 
> can, 
> for example, use scp:// URLs to specify a kickstart for Anaconda.  The fact 
> that scp utility will be reimplemented over SFTP does not help much in this 
> case.  Each build of libcurl that supports scp:// supports sftp:// as well.  
> But libcurl will not transmit scp:// requests over sftp:// in case SCP is not 
> supported by the remote server any more.

Sounds like a RFE for libcurl to slowly move scp:// to be using the
sftp protocol instead ?

Or they could simply deprecate it, and then users will have to change
their config to say sftp://

For something like libcurl the latter is probably more appropriate
anyway.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Retiring ntp

On Mon, Nov 02, 2020 at 04:09:33PM +0100, Reindl Harald (privat) wrote:
> Am 02.11.20 um 15:33 schrieb Miroslav Lichvar:
> > In Fedora, there seems to be only one package that has a dependency on
> > ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
> > problematic mode-6 protocol. It should work with ntpsec.
> > 
> > Thoughts?
> 
> only as long there is a fully compatible drop-in replacement with proper
> provides/obsoletes
> 
> in other words the config below needs to work because ESXi hosts and cetral
> servers on other locations are using two of this ntpd instances to provide
> time for the other machines in the network over vpn and/or for virtualized
> guests by vmware-tools timesync

Your config doesn't use any special features. Just a plain client and
server. You can switch easily to chrony or ntpsec.

-- 
Miroslav Lichvar
___
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] Deprecating SCP

2020-11-02 Thread Jakub Jelen


On 11/2/20 3:57 PM, Walter Cazzola wrote:

Hi,
I don't know if and how the internet protocol scp: is related to the scp
command. But I suppose it is.


Hi,
SCP is not an internet protocol -- it is simple protocol that is used 
inside of encrypted SSH session, similarly to SFTP protocol. The name 
comes from RCP which actually was unencrypted internet protocol and 
which is hopefully gone.



I'm using scp: a lot to edit remote files with vim and I'm pretty sure that
many remote admins are doing the same.

So I'm wondering how this change will affect my use case scenario and if 
you

have considered it when moving to sftp.


That is a good question!

When I try to use scp://host/file I am getting errors that vim is trying 
to use `rcp` command (yuck!). But using the same with sftp://host/file 
works like a charm.


I believe vim is using just scp to fetch the file so if the connection 
to the server will work also with sftp, it should continue to work (but 
I recommend using sftp protocol anyway).


The simplest way to try is to try with sftp:// or try the previously 
mentioned package, but my best bet is that it will keep on working as 
before (even though I never used this inside of vim up until today).


Regards,
Jakub


Thank you
Walter

On Mon, 2 Nov 2020, Jakub Jelen wrote:


Hi Fedora users!

Over the last years, there were several issues in the SCP protocol, 
which lead us into discussions if we can get rid of it in upstream 
[1]. Most of the voices there said that they use SCP mostly for simple 
ad-hoc copy and because sftp utility does not provide simple interface 
to copy one or couple of files back and forth and because of people 
are just used to write scp rather than sftp.


Some months ago, I wrote a patch [2] for scp to use SFTP internally 
(with possibility to change it back using -M scp) and ran it through 
some successful testing. The general feedback from upstream was also 
quite positive so I would like to hear also opinions from our users.


It still has some limitations (missing -3 support, it will not work if 
the server does not run sftp subsystem, ...), but it should be good 
enough for most common use cases.


Today, I set up a copr repository with the current openssh from Fedora 
+ the patch [2] for anyone to test and provide feedback, either here 
on the mailing list, or in the github PR according to ones preferences.


I am looking for any kind of feedback from the idea through the 
usability, implementation. Is this something you would like to see in 
Fedora soon? Do you have something against this? Is your use case 
missing?


[1] 
https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html 


[2] https://github.com/openssh/openssh-portable/pull/194/
[3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/

Thanks,






--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring ntp

On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
> I use ntp heavily for multiple stratum 1 timeservers here.  If you drop ntp, 
> I will have to build my own from source.  Not a big problem, but I'd 
> personally like to see ntp stay available in Fedora.

I have few stratum-1 servers too, but I'm not running ntp.

What reference clock do you have? Unless it's something very rare, you
shouldn't need ntp for that. GPS receivers are well supported by gpsd
and ntpsec kept most of the ntpd drivers for hardware that is still
widely used.

There is also the ntp-refclock package which contains all ntpd drivers
with a thin wrapper that allows them to be used with chrony, ntpsec,
or basically any NTP server.

-- 
Miroslav Lichvar
___
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: Deprecating SCP

On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote:
> Hi Fedora users!
> 
> Over the last years, there were several issues in the SCP protocol, 
> which lead us into discussions if we can get rid of it in upstream [1]. 
> Most of the voices there said that they use SCP mostly for simple ad-hoc 
> copy and because sftp utility does not provide simple interface to copy 
> one or couple of files back and forth and because of people are just 
> used to write scp rather than sftp.
> 
> Some months ago, I wrote a patch [2] for scp to use SFTP internally 
> (with possibility to change it back using -M scp) and ran it through 
> some successful testing. The general feedback from upstream was also 
> quite positive so I would like to hear also opinions from our users.
> 
> It still has some limitations (missing -3 support, it will not work if 
> the server does not run sftp subsystem, ...), but it should be good 
> enough for most common use cases.
> 
> Today, I set up a copr repository with the current openssh from Fedora + 
> the patch [2] for anyone to test and provide feedback, either here on 
> the mailing list, or in the github PR according to ones preferences.
> 
> I am looking for any kind of feedback from the idea through the 
> usability, implementation. Is this something you would like to see in 
> Fedora soon? Do you have something against this? Is your use case missing?
> 
> [1] 
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html
> [2] https://github.com/openssh/openssh-portable/pull/194/
> [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/

How is the "compatibility scpd to support old clients" going to differ
from the current implementation?

libcurl implements its own SCP client over libssh.  Will this implementation 
continue to work after OpenSSH gets updated on servers?

Applications often allow users to pass arbitrary URLs to libcurl.  So one can, 
for example, use scp:// URLs to specify a kickstart for Anaconda.  The fact 
that scp utility will be reimplemented over SFTP does not help much in this 
case.  Each build of libcurl that supports scp:// supports sftp:// as well.  
But libcurl will not transmit scp:// requests over sftp:// in case SCP is not 
supported by the remote server any more.

Kamil

___
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 1893497] RFE - build a perl-Module-Install-ExtraTests package for EPEL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
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: Retiring ntp

2020-11-02 Thread Steven A. Falco


On 11/2/20 10:23 AM, Tomasz Torcz wrote:

On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:

On 11/2/20 9:33 AM, Miroslav Lichvar wrote:

I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.



I use ntp heavily for multiple stratum 1 timeservers here.  If you
drop ntp, I will have to build my own from source.  Not a big problem,
but I'd personally like to see ntp stay available in Fedora.


   Would NTPSec (https://www.ntpsec.org/accomplishments.html) work for you?


Probably.  They appear to have kept the nmea and pps drivers.  I'll have to 
build a copy and give it a try to be sure.

Steve
___
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: Retiring ntp

2020-11-02 Thread Tomasz Torcz

On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
> On 11/2/20 9:33 AM, Miroslav Lichvar wrote:
> > I'm not sure how many users of ntp are there. As a replacement, we
> > could package ntpsec. It is an actively maintained fork of ntp which
> > has removed a lot of code and fixed or avoided most of the issues in
> > ntp. What I don't like much about it is that they kept the mode-6
> > protocol of NTP, which allows traffic amplification and is still
> > causing problems on Internet, but I think the code and the project are
> > definitely in a better shape than ntp. I can help with the packaging
> > or review, and as a comaintainer if there is a volunteer for the
> > role of the primary maintainer.
> > 
> 
> I use ntp heavily for multiple stratum 1 timeservers here.  If you
> drop ntp, I will have to build my own from source.  Not a big problem,
> but I'd personally like to see ntp stay available in Fedora.

  Would NTPSec (https://www.ntpsec.org/accomplishments.html) work for you?


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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: nss vs. nspr - shipping overlapping set of built binary packages?

2020-11-02 Thread Daiki Ueno

Hello Fabio,

Fabio Valentini  writes:

> I just noticed (because of a failed build due to NVR mismatch in an
> exact dependency) that *two* packages provide the "nspr" and
> "nspr-devel" binary packages - nss and nspr.
>
> Is there a reason for both those packages to exist, if nspr and
> nspr-devel are built from the "nss" source package, as well as from
> the "nspr" source package? The .spec files do not seem to contain an
> explanation.

The idea is to merge nspr into nss in F34+.  Although there were some
hiccups, the latest compose shouldn't have the problem.  I've just
retired nspr package in rawhide.

See the original rationale in the PR:
https://src.fedoraproject.org/rpms/nss/pull-request/14
and some follow-up discussions on:
https://bugzilla.redhat.com/show_bug.cgi?id=1892874

Regards,
-- 
Daiki Ueno
___
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: Deprecating SCP

2020-11-02 Thread Marius Schwarz


Am 02.11.20 um 16:13 schrieb Solomon Peachy:

On Mon, Nov 02, 2020 at 03:44:39PM +0100, Jakub Jelen wrote:

I am looking for any kind of feedback from the idea through the usability,
implementation. Is this something you would like to see in Fedora soon? Do
you have something against this? Is your use case missing?

I like it!  scp-the-tool (including command/filename completion!) is
just so much nicer to work with than sftp-the-tool.

Well, thats a nice feature requirement, almost forgot about it.



But sftp is also slightly slower than scp, at least on large sustained
transfers.


Hope not, slow data transfer is already an issue with Gb/s :).

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

Re: Retiring ntp

2020-11-02 Thread Steven A. Falco


On 11/2/20 9:33 AM, Miroslav Lichvar wrote:

I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.

The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.

I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.

In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.

Thoughts?



I use ntp heavily for multiple stratum 1 timeservers here.  If you drop ntp, I 
will have to build my own from source.  Not a big problem, but I'd personally 
like to see ntp stay available in Fedora.

Steve
___
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: EOL and Obsoletes in Modularity

2020-11-02 Thread Michal Schorm

I haven't got a need to use obsolete modules yet, so I'll write my
opinion about the module EOL only.

Q: Should the EOL be configurable to mid-release date?
The others in this discussion showed it makes sense to EOL a module mid-release.

Since the modules are built on and on (new build targets are added,
unless you blacklist them), it easily happens that it starts building
for targets you didn't want to. (e.g. next fedora release; or 'el8')
I would have used the mid-release EOL ability to kill the module on
targets I haven't intended it would be built for.

Real case with mysql 5.7 module. I don't want to maintain it any
longer, after I maintained it for a release or two the MySQL 8.0 came
out. But I haven't got any other choice than going to relengs and ask
to EOL it; but since it was already built for rawhide, I had to wait
for the Rawhide to EOL. I should maintain it, since I am it's
maintainer and it wasn't EOL yet, but I didn't. I closed every CVE
with WONTFIX ... as it was on the very bottom of my priority list but
still not EOL ... and it is not EOL until this day. (synced with F31
EOL, so I'm already preparing a small celebration)

So the answer is:
* YES - I would be grateful to use mid-release EOL in some cases

Q: How to set the EOL ?
Pretty please, let me (the maintainer) do it! Any other way is IMHO
the wrong way.
Having to wait on someone, who does not know anything about the module
content (e.g. upstream release cycles and decisions) is just awful.
Both for maintainers and the poor people who must to process that.
An ideal place is IMHO the same, single modulemd file used for
defining the module. I don't understand why it had to be a separate
file, but I can live with that.

So the answer is:
* YES - I, the maintainer, MUST to be able to set EOL on my own.
Ideally in the same modulemd file

A related question is - who knows how to find out the EOL dates now?
Well I don't. PDC is a mess for me.
And you know what? Based on a link provided by Petr Pisar:
https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/?branch_type=module_component=mysql=5.7
MySQL 5.7 has EOL date set to 2020-09-15.
Wtf is that date?
Anytime I wanted to assure about the EOL date, I looked back at the
releng ticket:
https://pagure.io/releng/issue/8699
and checked it should be F31 EOL for mysql 5.7
But yeah, I get it. Since the Fedora release dates are not ultimately
set, even releng couldn't know the exact date of F31 EOL back then, so
it seems the module EOLed mid-release already, huh?

So the side note is:
* let me check the EOL date in some SANE way. (checking an EOL line
e.g. in modulemd file is a sane way for me - the maintainer)

Michal

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
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: Deprecating SCP

2020-11-02 Thread Solomon Peachy

On Mon, Nov 02, 2020 at 03:44:39PM +0100, Jakub Jelen wrote:
> I am looking for any kind of feedback from the idea through the usability,
> implementation. Is this something you would like to see in Fedora soon? Do
> you have something against this? Is your use case missing?

I like it!  scp-the-tool (including command/filename completion!) is 
just so much nicer to work with than sftp-the-tool.

But sftp is also slightly slower than scp, at least on large sustained 
transfers.

My non-scientific test transfered a 13GB file at 111.1MB/s vs 112.0MB/s 
between two (very fast) endpoints connected via GigE.

(I need to see how well it handles smaller transfers, this is where SCP 
gets pretty crappy..)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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 1893759] perl-DBD-Mock-1.58 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An unexpected error occurred while creating the scratch build and has been
automatically reported. Sorry!


-- 
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: Deprecating SCP

2020-11-02 Thread Marius Schwarz


Am 02.11.20 um 15:44 schrieb Jakub Jelen:

Hi Fedora users!

Over the last years, there were several issues in the SCP protocol, 
which lead us into discussions if we can get rid of it in upstream 
[1]. Most of the voices there said that they use SCP mostly for simple 
ad-hoc copy and because sftp utility does not provide simple interface 
to copy one or couple of files back and forth and because of people 
are just used to write scp rather than sftp.


Some months ago, I wrote a patch [2] for scp to use SFTP internally 
(with possibility to change it back using -M scp) and ran it through 
some successful testing. The general feedback from upstream was also 
quite positive so I would like to hear also opinions from our users.


if it is compatible with what powerusers i.e. sysadmins do with it, it 
should be fine. I have such things as Compression, Cipher, Ports and 2 
sets of login credentials in mind, to directly copy from a to b without 
parking it first on the pc running the scp.


On the server side it has to honor things like CHROOT directives.

best regards,
Marius

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

[Bug 1753543] perl-Font-AFM for EL8

https://bugzilla.redhat.com/show_bug.cgi?id=1753543
Bug 1753543 depends on bug 1757474, which changed state.

Bug 1757474 Summary: a2ps for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1757474

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG




-- 
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: Orphaned packages looking for new maintainers (see note about xinetd)

2020-11-02 Thread Todd Zullinger

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.
> 
> Thanks for the clear info about the dependency, btw. It would have been easy 
> to miss otherwise.

Indeed, thanks Miro and Michael!

_If_ it comes to it, the git package has a conditional for
building without CVS.  It's trivial to change the default
for f34+ and avoid the cvs dep.

It seems likely that cvs can drop the inetd subpackage
without much trouble though, so it shouldn't come to that.

-- 
Todd


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: Deprecating SCP

2020-11-02 Thread José Abílio Matos

On Monday, November 2, 2020 2:44:39 PM WET Jakub Jelen wrote:
> I am looking for any kind of feedback from the idea through the
> usability, implementation. Is this something you would like to see in
> Fedora soon? Do you have something against this? Is your use case missing?

Hi Jakub,
  if I am not sure if I understood what you said, you intend to deprecate the 
scp protocol/inner working but not the scp binary. Is that correct?

I like the ease of the use of the scp, even if sometimes I would prefer it to 
have the same options as the usual cp. :-)

Best regards,
-- 
José Abílio___
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 1807857] please build perl-Sys-SigAction on EPEL8

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

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|trem...@tremble.org.uk  |andr...@bawue.net



--- Comment #5 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.


-- 
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: Deprecating SCP

2020-11-02 Thread Paul Wouters


On Mon, 2 Nov 2020, Jakub Jelen wrote:

Some months ago, I wrote a patch [2] for scp to use SFTP internally (with 
possibility to change it back using -M scp) and ran it through some 
successful testing. The general feedback from upstream was also quite 
positive so I would like to hear also opinions from our users.


I am looking for any kind of feedback from the idea through the usability, 
implementation. Is this something you would like to see in Fedora soon? Do 
you have something against this? Is your use case missing?


This is excellent!

Indeed, most users don't care about the underlying SSH protocol flavour
other than expecting it to be secure. They just want "scp" to work.

Your solution does both. It is a very good example of listening to what
users want and supported users without requiring them to learn a new
command like sftp. I wish more developers had this focus!

I will try it out over the next few days. My personal usecases would be
that it still keeps working with rsync's method of invoking scp and that
we would have sftp enable by default for sshd by default.

Thanks!

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

Deprecating SCP

2020-11-02 Thread Jakub Jelen


Hi Fedora users!

Over the last years, there were several issues in the SCP protocol, 
which lead us into discussions if we can get rid of it in upstream [1]. 
Most of the voices there said that they use SCP mostly for simple ad-hoc 
copy and because sftp utility does not provide simple interface to copy 
one or couple of files back and forth and because of people are just 
used to write scp rather than sftp.


Some months ago, I wrote a patch [2] for scp to use SFTP internally 
(with possibility to change it back using -M scp) and ran it through 
some successful testing. The general feedback from upstream was also 
quite positive so I would like to hear also opinions from our users.


It still has some limitations (missing -3 support, it will not work if 
the server does not run sftp subsystem, ...), but it should be good 
enough for most common use cases.


Today, I set up a copr repository with the current openssh from Fedora + 
the patch [2] for anyone to test and provide feedback, either here on 
the mailing list, or in the github PR according to ones preferences.


I am looking for any kind of feedback from the idea through the 
usability, implementation. Is this something you would like to see in 
Fedora soon? Do you have something against this? Is your use case missing?


[1] 
https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html

[2] https://github.com/openssh/openssh-portable/pull/194/
[3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/

Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

nss vs. nspr - shipping overlapping set of built binary packages?

2020-11-02 Thread Fabio Valentini

Hi everybody,

I just noticed (because of a failed build due to NVR mismatch in an
exact dependency) that *two* packages provide the "nspr" and
"nspr-devel" binary packages - nss and nspr.

Is there a reason for both those packages to exist, if nspr and
nspr-devel are built from the "nss" source package, as well as from
the "nspr" source package? The .spec files do not seem to contain an
explanation.

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: Retiring ntp

On Mon, Nov 2, 2020 at 9:33 AM Miroslav Lichvar  wrote:
>
> I think we should consider retiring the ntp package. The upstream
> project is not in a good shape and it doesn't seem to be improving.
> Contributors left long time ago. The development is slow and happens
> behind closed doors. They still use bitkeeper.
>
> The main problem is that they don't fix all known security issues. In
> the CVE list I see about 10 issues that were not fixed at all or only
> partially, some exploitable in default configuration. This was one of
> the reasons why we dropped it from RHEL.
>
> I'm not sure how many users of ntp are there. As a replacement, we
> could package ntpsec. It is an actively maintained fork of ntp which
> has removed a lot of code and fixed or avoided most of the issues in
> ntp. What I don't like much about it is that they kept the mode-6
> protocol of NTP, which allows traffic amplification and is still
> causing problems on Internet, but I think the code and the project are
> definitely in a better shape than ntp. I can help with the packaging
> or review, and as a comaintainer if there is a volunteer for the
> role of the primary maintainer.
>
> In Fedora, there seems to be only one package that has a dependency on
> ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
> problematic mode-6 protocol. It should work with ntpsec.
>
> Thoughts?
>

That sounds fine to me. The only thing I really get concerned about is
whether we have the "ntpdate" tool, which comes from the ntp package.
As far as I know, ntpsec also includes it, so we should be fine.




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

Retiring ntp

I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.

The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.

I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.

In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.

Thoughts?

-- 
Miroslav Lichvar
___
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: EOL and Obsoletes in Modularity

2020-11-02 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Nov 02, 2020 at 08:37:30AM -0500, Stephen John Smoogen wrote:
> On Mon, 2 Nov 2020 at 06:55, Miro Hrončok  wrote:
> 
> > On 11/2/20 12:33 PM, Daniel Mach wrote:
> > > Then there's a question how to get the documents into modules.yaml. From
> > my
> > > perspective, it's up to Fedora infra/releng/packaging people. Whether it
> > should
> > > be in dist-git, git repo (similar to modulemd-defaults or comps), PDC,
> > Bodhi
> > > (similar to updateinfo) or somewhere else - that's entirely their call.
> >
> > I understand this perspective, but unless we have Fedora
> > infra/releng/packaging
> > people who would own this and drive this, it won't happen. I consider
> > myself
> > "packaging people" and I certainly won't. Do we have at least an idea if
> > we have
> > such people?
> >
> >
> I do not think Fedora/CentOS Infra/Releng could do any of this without a
> scoped out project to Community Platform Engineering.
> 
> Most of the items (outside of bodhi) listed above are 'run' by CPE but not
> 'owned' by CPE in a way that CPE architects what is there and how it is
> done. dist-git is dictated by what koji wants and needs. modularity git
> repo is dictated by what MBS needs. PDC is abandoned-ware from some
> internal group and works only when it wants to, etc. Most of the CPE
> infra/releng work is just trying to keep the Rube Goldberg machine of the
> Fedora/CentOS build systems running 24x7x365 while meeting the 'oh by the
> way we promised that XYZ would be built this release.. disk and cpu are
> free right?' project demands of some component which works fine by itself
> and now needs to work in the existing systems already. We have a long list
> of these items to complete in the next 6 months..

Yes ;[ So any process that centralizes this to be managed (and verified!) by
infra or releng folks is a bad idea. dist-git seems to be the only possible 
place.

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

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

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

Bug ID: 1893759
   Summary: perl-DBD-Mock-1.58 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBD-Mock
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jakub.jedel...@gmail.com, jan.pra...@gmail.com,
lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com, tjczep...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.58
Current version/release in rawhide: 1.57-1.fc34
URL: http://search.cpan.org/dist/DBD-Mock/

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


-- 
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: DevConf.CZ CfP open

2020-11-02 Thread Ben Cotton

The DevConf.CZ proposal deadline has been extended to 6 November.
There's still time for you to submit a talk about all of the great
things you're doing in Fedora. See the Community Blog post[1] for more
information.

[1] https://communityblog.fedoraproject.org/devconf-cz-cfp-now-open/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

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

Jitka Plesnikova  changed:

   What|Removed |Added

  Flags||needinfo?(emmanuel@seyman.f
   ||r)



--- Comment #1 from Jitka Plesnikova  ---
Emmanuel, could you please give me (jplesnik) permissions in dist-git, then I
can do it myself.


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

Logs for the Open NeuroFedora Meeting: 1300 UTC on Monday, 2nd November

2020-11-02 Thread Aniket Pradhan

Hello everyone!

Thanks for attending today's meeting. We will be meeting again in two
weeks' time. bt0 would be chairing the next meeting :D

Links to the logs from today's meeting:
* 
https://meetbot.fedoraproject.org/fedora-neuro/2020-11-02/neurofedora.2020-11-02-13.01.log.html
* 
https://meetbot.fedoraproject.org/fedora-neuro/2020-11-02/neurofedora.2020-11-02-13.01.html

Minutes in text format for your convenience:

===
#fedora-neuro: NeuroFedora - 2020-11-02
===


Meeting started by MeWjOr at 13:01:29 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-neuro/2020-11-02/neurofedora.2020-11-02-13.01.log.html
.



Meeting summary
---
* LINK: https://webchat.freenode.net/?channels=#fedora-neuro
  (FranciscoD, 13:03:11)
* Today's Agenda  (MeWjOr, 13:03:31)
  * Announcement e-mail:

https://lists.fedoraproject.org/archives/list/neurofed...@lists.fedoraproject.org/thread/VKFCKQUXL3C6OPIJ2F7HFDBVCQB5CSAX/
(MeWjOr, 13:05:16)
  * introductions and roll call  (MeWjOr, 13:05:28)
  * Tasks from last week's meeting:  (MeWjOr, 13:05:34)
  * Open Pagure tickets  (MeWjOr, 13:05:40)
  * Open NeuroFedora bugs  (MeWjOr, 13:05:49)
  * Koschei packages check  (MeWjOr, 13:06:00)
  * CompNeuro lab compose status check  (MeWjOr, 13:06:07)
  * Neuroscience query of the week  (MeWjOr, 13:06:12)
  * Next meeting day, and chair  (MeWjOr, 13:06:18)
  * open floor  (MeWjOr, 13:06:24)

* introductions and roll call  (MeWjOr, 13:06:53)
  * Ankur Sinha, FAS: ankursinha, IRC: FranciscoD; NeuroFedora,
packaging, fedora-join, Ask Fedora, etc. ; UTC + 0  (FranciscoD,
13:09:32)

* Task from the last meeting  (MeWjOr, 13:11:01)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1838564   (MeWjOr,
13:13:14)
  * LINK:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures
(FranciscoD, 13:14:18)
  * FTBFS marked for lfpy:
https://bugzilla.redhat.com/show_bug.cgi?id=1893723  (MeWjOr,
13:14:34)
  * ACTION: MeWjOr fix libneurosim:
https://bugzilla.redhat.com/show_bug.cgi?id=1864029: WIP, upstream
had to make a fix  (MeWjOr, 13:16:21)
  * FranciscoD purusharths: add koji compose link to the agenda for
future meetings --- done  (MeWjOr, 13:17:00)
  * LINK:

https://docs.fedoraproject.org/en-US/neurofedora/communicating/#_open_meetings
(FranciscoD, 13:17:55)
  * FranciscoD file FTBFS bug for python-mne using Koschei:
https://koschei.fedoraproject.org/package/python-mne --- done
(MeWjOr, 13:18:05)
  * ACTION: MeWjOr Work over the update for python-mne  (MeWjOr,
13:19:22)
  * MeWjOr check if release-monitoring.org has been set up for
python-odml --- done  (MeWjOr, 13:19:38)
  * ACTION: MeWjOr Fix the deps for python-odml  (MeWjOr, 13:20:19)

* Open Pagure tickets  (MeWjOr, 13:20:55)
  *

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
(MeWjOr, 13:21:04)
  * https://fosdem.org/2021/news/2020-10-26-devroom-cfp/  (MeWjOr,
13:22:48)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/392  (MeWjOr,
13:28:56)
  * ACTION: everyone Think over some ideas as to what we can present at
FOSDEM 21  (MeWjOr, 13:31:48)
  * FOSSDEM mailing lists: https://lists.fosdem.org/mailman/listinfo
(FranciscoD, 13:37:13)

* NeuroFedora Bugs: https://tinyurl.com/neurofedora-bugs  (MeWjOr,
  13:39:38)
  * https://tinyurl.com/neurofedora-bugs  (MeWjOr, 13:39:45)

* Koschei packages check  (MeWjOr, 13:41:46)
  * neuro-sig packages here:
https://koschei.fedoraproject.org/groups/neuro-sig  (MeWjOr,
13:42:10)
  * pydicom: https://bugzilla.redhat.com/show_bug.cgi?id=1838435
(FranciscoD, 13:43:14)
  * ACTION: FranciscoD Checkout nest at the next meeting if its building
fine or not  (MeWjOr, 13:47:37)
  * ACTION: alciregi check on python-pydicom package  (FranciscoD,
13:47:45)

* CompNeuro lab compose check  (MeWjOr, 13:48:40)
  * https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
(MeWjOr, 13:48:48)
  * LINK: https://pagure.io/fedora-kickstarts/pull-request/724
(FranciscoD, 13:49:48)

* Neuroscience query of the week  (MeWjOr, 13:53:39)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/318  (MeWjOr,
13:53:58)
  * LINK: https://neuroblog.fedoraproject.org/planet-neuroscientists/
(FranciscoD, 13:55:14)

* Next meeting day, and chair  (MeWjOr, 13:58:29)
  * ACTION: bt0 Next meeting, same time in two weeks. bt0 will chair the
meet :D  (MeWjOr, 14:00:48)

* open floor  (MeWjOr, 14:01:12)
  * ACTION: MeWjOr send out the meeting logs and everything else
(MeWjOr, 14:01:56)

Meeting ended at 14:02:47 UTC.




Action Items

* MeWjOr fix libneurosim:
  https://bugzilla.redhat.com/show_bug.cgi?id=1864029: WIP, upstream had
  to make a fix
* MeWjOr Work over the update for python-mne
* MeWjOr Fix the deps for python-odml
* everyone Think over some ideas as to what we

[Bug 1889622] Upgrade perl-File-Remove to 1.60