Re: Virtual Fedora 33 Release Party - You're invited! (Nov 6th & 7th)

[linux guy]

I won't be attending, but I'd like to thank all those that worked on F33.
I'm a long time Fedora user and F33 is excellent.   Linux rocks !   Fedora
rocks !  Good work.

On Thu, Nov 5, 2020 at 1:21 PM Marie Nordin  wrote:

> Hey Fedora!
>
> You're invited to the F33 Release Party! Tomorrow Friday November 6th and
> Saturday November 7th. We will have a couple information sessions with
> plenty of fun sessions mixed in like lightning talks, pictionary, and
> special events! Get ready to celebrate :)
>
> See all relevant links below.
>
> Registration:
> https://hopin.to/events/fedora-33-release-party
> 
>
> Schedule in wiki format:
> https://fedoraproject.org/wiki/Fedora_33_Release_Party_Schedule#
>
> Lightning talk signup:
>
> https://fedoraproject.org/wiki/F33_Virtual_Release_Party_Lightning_Talk_Signup
> 
>
> Special event signup:
> https://fedoraproject.org/wiki/F33_Virtual_Release_Party_Event_Signup
>
> Can't wait to see you there,
> Cheers!
>
> --
>
> Marie Nordin
>
> Fedora Community Action and Impact Coordinator
>
> Red Hat  • Fedora Project
> 
>
> She/Her/Hers
>
> T: +1.973.800.4967
>
> IRC: riecatnor
>
>
> 
> ___
> 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 1894755] perl-IO-Pager-2.10 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

Fedora-Cloud-33-20201106.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

[Bug 1894777] perl-File-Path-2.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-478806368a 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-478806368a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-478806368a

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

[bugzilla]

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



--- Comment #2 from Jakub Jedelsky  ---
https://pagure.io/releng/fedora-scm-requests/issue/30256
https://pagure.io/releng/fedora-scm-requests/issue/30257


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

[bugzilla]

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

Jakub Jedelsky  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|spo...@gmail.com|jakub.jedel...@gmail.com




-- 
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] 389 DS nightly 2020-11-06 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/06/report-389-ds-base-2.0.1-20201106git04ba05e.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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4f4de3554d   
fastd-21-1.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5f50399d2e   
chromium-86.0.4240.111-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a0f02190ad   
libntlm-1.6-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d21505685e   
mujs-1.0.9-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a34a6ea9c4   
pngcheck-2.4.0-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a4ade35d32   
java-latest-openjdk-15.0.1.9-1.rolling.el8


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

html401-dtds-4.01-19991224.12.el8.15
ipmctl-02.00.00.3830-1.el8
modulemd-tools-0.5-1.el8
openbgpd-6.8p1-1.el8

Details about builds:



 html401-dtds-4.01-19991224.12.el8.15 (FEDORA-EPEL-2020-28858dfe5f)
 HTML 4.01 document type definitions

Update Information:

html401-dtds package for EPEL-8

ChangeLog:





 ipmctl-02.00.00.3830-1.el8 (FEDORA-EPEL-2020-6e8279e19d)
 Utility for managing Intel Optane DC persistent memory modules

Update Information:

Update to GitHub release v02.00.00.3830

ChangeLog:

* Wed Nov  4 2020 Steven Pontsler  - 02.00.00.3830-1
- Release 02.00.00.3830




 modulemd-tools-0.5-1.el8 (FEDORA-EPEL-2020-7e9077)
 Collection of tools for parsing and generating modulemd YAML files

Update Information:

- Support EPEL8! - Documentation improvements, many examples of how to use the
tools themselves and in combination with other tools  ## createrepo_mod  - Dump
`modules.yaml` into the correct directory - There is native support for modules
in `createrepo_c` version `0.16.1`. The `createrepo_mod` will utilize it if
possible.

ChangeLog:





 openbgpd-6.8p1-1.el8 (FEDORA-EPEL-2020-c33ab2aead)
 OpenBGPD Routing Daemon

Update Information:

OpenBGPD 6.8p1 ==  This is the second stable release for the 6.8
version. It includes the following change:* Include OpenBSD 6.8 errata 001:
In `bgpd`, the roa-set parser could leak memory.

ChangeLog:

* Thu Nov  5 2020 Robert Scheck  6.8p1-1
- Upgrade to 6.8p1 (#1895063)

References:

  [ 1 ] Bug #1895063 - openbgpd-6.8p1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1895063


___
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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-284f18e5de   
lout-3.40-18.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fd6ec50fa5   
fastd-21-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3157c3d291   
chromium-86.0.4240.111-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e816cf1fbc   
containerd-1.2.14-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a5abe545c6   
wordpress-5.1.8-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-aeaf0b9bc0   
pngcheck-2.4.0-1.el7


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

ipmctl-02.00.00.3830-2.el7
openbgpd-6.8p1-1.el7

Details about builds:



 ipmctl-02.00.00.3830-2.el7 (FEDORA-EPEL-2020-5dbca38df8)
 Utility for managing Intel Optane DC persistent memory modules

Update Information:

Update to GitHub release v02.00.00.3830

ChangeLog:

* Thu Nov  5 2020 Steven Pontsler  - 02.00.00.3830-2
- Try reapplying changes for 02.00.00.3830
* Wed Nov  4 2020 Steven Pontsler  - 02.00.00.3830-1
- Release 02.00.00.3830




 openbgpd-6.8p1-1.el7 (FEDORA-EPEL-2020-316bec5b76)
 OpenBGPD Routing Daemon

Update Information:

OpenBGPD 6.8p1 ==  This is the second stable release for the 6.8
version. It includes the following change:* Include OpenBSD 6.8 errata 001:
In `bgpd`, the roa-set parser could leak memory.

ChangeLog:

* Thu Nov  5 2020 Robert Scheck  6.8p1-1
- Upgrade to 6.8p1 (#1895063)

References:

  [ 1 ] Bug #1895063 - openbgpd-6.8p1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1895063


___
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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca0361c919   
lout-3.40-18.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6bc42544ca   
wordpress-5.1.8-1.el6


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

dmlite-1.14.2-1.el6

Details about builds:



 dmlite-1.14.2-1.el6 (FEDORA-EPEL-2020-219613ff7d)
 Lcgdm grid data management and storage framework

Update Information:

dmlite-1.14.2

ChangeLog:

* Thu Nov  5 2020 Oliver Keeble  - 1.14.2-1
- New upstream release 1.14.2_sl6


___
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

Re: ld segfaults on rawhide

[Christoph Junghans]

On Tue, Nov 3, 2020 at 10:42 AM Justin Forbes  wrote:
>
> On Tue, Nov 3, 2020 at 11:17 AM Miro Hrončok  wrote:
> >
> > On 11/3/20 6:08 PM, Jeff Law wrote:
> > >
> > > On 11/3/20 9:56 AM, Kevin Fenzi wrote:
> > >> On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote:
> > >>> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes  
> > >>> wrote:
> >  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.
> > 
> > >>> Would it be possible/wise to untag the bad binutils build from rawhide
> > >>> until an answer is found here?
> > >> Well, it may already be out in yesterdays rawhide?
> > >>
> > >> I see:
> > >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1637660
> > >> landed today...
> > >>
> > >> Does that one work any better?
> > >
> > > I ping'd Nick on this issue about an hour ago and he indicated it was
> > > now fixed in rawhide.
> > >
> >
> > It appears to be fixed in binutils 2.35.1-12.fc34
> >
> > At least rpm builds again.
> >
>
> kernel as well.

@Kevin Still segfaults, now inside using clang++-11:
Program received signal SIGSEGV, Segmentation fault.
0x7fb81e40aa88 in bfd_elf_link_add_symbols () from
/usr/lib64/libbfd-2.35.1-11.fc34.so
(gdb) bt
#0  0x7fb81e40aa88 in bfd_elf_link_add_symbols () from
/usr/lib64/libbfd-2.35.1-11.fc34.so
#1  0x55745267e16c in load_symbols.part ()
#2  0x55745267304c in open_input_bfds.lto_priv ()
#3  0x557452673116 in open_input_bfds.lto_priv ()
#4  0x55745267b538 in lang_process ()
#5  0x55745266bf97 in main ()
(from building votca-xtp with clang-11 on rawhide)

To reproduce, run:
$ docker run -it fedora:rawhide /bin/bash
in the container
$ dnf install git cmake eigen3-devel libint2-devel hdf5-devel
libxc-devel expat-devel boost-devel
$ git clone --recursive https://github.com/votca/votca
$ cmake -B build -DBUILD_XTP=ON votca
$ cmake --build build
wait and see the segfault.

Christoph

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



-- 
Christoph Junghans
Web: http://www.compphys.de
___
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 870408] CVE-2012-4730 CVE-2012-4732 CVE-2012-4734 CVE-2012-4735 CVE-2012-4884 rt3: Multiple flaws fixed in upstream 3.8.15 version [epel-all]

[bugzilla]

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



--- Comment #3 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to
close all bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version, you are encouraged
to change the 'version' to a later version prior this bug is closed as
described in the policy above.


-- 
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 663069] Wrong charset in graph.

[bugzilla]

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



--- Comment #13 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to
close all bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version, you are encouraged
to change the 'version' to a later version prior this bug is closed as
described in the policy above.


-- 
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 1186698] /etc/profile.d/perl-homedir.csh contains bourne shell "if" code. Makes tcsh prompt "if: Expression Syntax."

[bugzilla]

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



--- Comment #6 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to
close all bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version, you are encouraged
to change the 'version' to a later version prior this bug is closed as
described in the policy above.


-- 
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 844988] Upgrade to new upstream version

[bugzilla]

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



--- Comment #3 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to
close all bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version, you are encouraged
to change the 'version' to a later version prior this bug is closed as
described in the policy above.


-- 
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 870408] CVE-2012-4730 CVE-2012-4732 CVE-2012-4734 CVE-2012-4735 CVE-2012-4884 rt3: Multiple flaws fixed in upstream 3.8.15 version [epel-all]

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 663069] Wrong charset in graph.

[bugzilla]

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



--- Comment #12 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 1186698] /etc/profile.d/perl-homedir.csh contains bourne shell "if" code. Makes tcsh prompt "if: Expression Syntax."

[bugzilla]

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



--- Comment #5 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 844988] Upgrade to new upstream version

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 1021422] Insufficient validation of PID file contents

[bugzilla]

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



--- Comment #1 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 1284924] perl-IPTables-Parse: insecure temporary file use [epel-all]

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 962708] CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input [epel-6]

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 757287] Cannot continue: bucardo_ctl is version 4.4.6, but /usr/share/bucardo/bucardo.schema is version 4.4.7

[bugzilla]

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



--- Comment #1 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 756294] Upgrade to new upstream version

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 1526184] perl-IPTables-Parse returns undef instead of good status on default_log() success

[bugzilla]

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



--- Comment #1 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 879007] SELinux errors with temporary files

[bugzilla]

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



--- Comment #4 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Michael Catanzaro]

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1711519

(And related, but for Qt5: 
https://bugzilla.redhat.com/show_bug.cgi?id=1872819)


___
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 904249] /NoAuth isn't specified in /etc/httpd/conf.d/rt3.conf

[bugzilla]

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



--- Comment #1 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 920685] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [epel-all]

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 1169601] Upgrade to perl-Net-Server version 2 breaks amavisd

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 1267965] CVE-2015-8326 perl-IPTables-Parse: Use of predictable names for temporary files [epel-6]

[bugzilla]

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



--- Comment #2 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


-- 
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 824089] CVE-2011-2082 rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions [epel-all]

[bugzilla]

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



--- Comment #4 from Ben Cotton  ---
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will
stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy
to close all bug reports from releases that are no longer maintained. At that
time this bug will be closed as EOL if it remains open with a 'version' of
'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a
later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to
fix it before EPEL 6 is end of life. If you would still like to see this bug
fixed and are able to reproduce it against a later version of Fedora, you are
encouraged  change the 'version' to a later Fedora version prior this bug is
closed as described in the policy above.


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

pari soname bump

[Jerry James]

Pari 2.13.0 is out, and comes with an soname bump.  I have
successfully rebuilt all consumers except sagemath in mock (the
sagemath build is running now; it takes awhile), so I don't expect any
problems.

Once the sagemath build completes, I will put the various consuming
packages through their paces to see if any problems arise.  If not, I
will do all the necessary builds in Rawhide next week.  If no problems
show up in Rawhide, I will consider updating Fedora 33 as well.

Packages to be rebuilt:
clisp
eclib
giac
L-function
python-cypari2 (requires an update to version 2.1.2b1)
python-cysignals
sagemath (will be updated to version 9.2)

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

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Sandro Mani]

On 06.11.20 00:16, Fabio Valentini wrote:

On Thu, Nov 5, 2020 at 10:26 PM Sandro Mani  wrote:


On 05.11.20 20:27, Sandro Mani wrote:

On 05.11.20 12:36, Tom Hughes wrote:

On 05/11/2020 11:24, Sandro Mani wrote:


I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
shortly. I'll do a round of test builds in this copr [1], and then
build everything (and rebuild dependent packages) in a rawhide
side-tag and then merge it.

That's definitely going to cause some breakage as I believe proj 7 has
finally removed the old legacy API which at least some other things like
mapnik are still using.

I believe there is an upstream patch for mapnik now but I'll have to
see if it can be backported to the release version...


Yes indeed - I'll go through the breakages, see if newer upstream
versions fix the problem, and then will post a list of packages which
need to be updated and contact the respective maintainers.


Soo, this opened a bit a can of worms, as qt-mobility (clearly being of
the qt4 era dead upstream) is not going to support proj7. Only package
requiring qt-mobility is qtwebkit, which in turn has a bit more users:

amarok-0:2.9.0-9.fc33.x86_64
arora-0:0.11.0-23.fc33.x86_64
brewtarget-0:2.1.0-16.fc33.x86_64
gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
kde-runtime-libs-0:17.08.3-15.fc33.i686
kde-runtime-libs-0:17.08.3-15.fc33.x86_64
kdelibs-6:4.14.38-23.fc34.i686
kdelibs-6:4.14.38-23.fc34.x86_64
kdelibs-webkit-6:4.14.38-23.fc34.i686
kdelibs-webkit-6:4.14.38-23.fc34.x86_64
knode-libs-0:4.14.10-44.fc33.i686
knode-libs-0:4.14.10-44.fc33.x86_64
krecipes-0:2.1.0-12.fc33.x86_64
ksysguard-libs-1:4.11.22-28.fc33.i686
ksysguard-libs-1:4.11.22-28.fc33.x86_64
libkfbapi-0:1.0-16.fc32.i686
libkfbapi-0:1.0-16.fc32.x86_64
python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
qlandkartegt-0:1.8.1-28.fc33.x86_64
qmc2-0:0.195-14.fc34.x86_64
qt-assistant-1:4.8.7-57.fc34.x86_64
qt-demos-1:4.8.7-57.fc34.x86_64
qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
qt-examples-1:4.8.7-57.fc34.i686
qt-examples-1:4.8.7-57.fc34.x86_64
qt4pas-0:2.5-21.fc33.i686
qt4pas-0:2.5-21.fc33.x86_64
qtscriptbindings-0:0.2.0-23.fc33.i686
qtscriptbindings-0:0.2.0-23.fc33.x86_64
qtwebkit-devel-0:2.3.4-32.fc34.i686
qtwebkit-devel-0:2.3.4-32.fc34.x86_64
rekonq-0:2.4.2-17.fc33.x86_64
timetablemate-0:0.10-0.24.20111204git.fc32.x86_64

So among this list, I see as end-user applications:

amarok - dead upstream music player
arora, rekonq: dead upstream browers, hardly a good idea to use them
brewtarget: has newer 2.3.0 release which supports Qt5
gambas3-gb-qt4-webkit: qt4 subpackages could just be dropped
krecipes: dead upstream
qlandkartegt: dead upstream
qmc2: latest trunk seems to support qt5
timetablemate -> kde-plasma-publictransport: Plasma 5 applet, with last
update in 2013 apparently


Sooo, how about taking this as a pretext to just kick out all the qt4
stuff? Debian has completed the move in March this year [1].

Opinions?

I, for one, would welcome getting rid of all that old cruft ...
especially if debian already has beaten us to the punch.
Could you pour your research into the Change Proposal wiki template
and propose this for F34? :)


Wait, I'll actually need to expand the analysis to include dependents of 
all these packages though, not just qtwebkit :) qtwebkit for sure it's 
time to remove, it likely has all sorts for security vulnerabilities. 
But I'll also expand the analysis to the entire qt4 stack and see what 
comes out.


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

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Fabio Valentini]

On Thu, Nov 5, 2020 at 10:26 PM Sandro Mani  wrote:
>
>
> On 05.11.20 20:27, Sandro Mani wrote:
> >
> > On 05.11.20 12:36, Tom Hughes wrote:
> >> On 05/11/2020 11:24, Sandro Mani wrote:
> >>
> >>> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
> >>> shortly. I'll do a round of test builds in this copr [1], and then
> >>> build everything (and rebuild dependent packages) in a rawhide
> >>> side-tag and then merge it.
> >>
> >> That's definitely going to cause some breakage as I believe proj 7 has
> >> finally removed the old legacy API which at least some other things like
> >> mapnik are still using.
> >>
> >> I believe there is an upstream patch for mapnik now but I'll have to
> >> see if it can be backported to the release version...
> >>
> > Yes indeed - I'll go through the breakages, see if newer upstream
> > versions fix the problem, and then will post a list of packages which
> > need to be updated and contact the respective maintainers.
> >
> Soo, this opened a bit a can of worms, as qt-mobility (clearly being of
> the qt4 era dead upstream) is not going to support proj7. Only package
> requiring qt-mobility is qtwebkit, which in turn has a bit more users:
>
> amarok-0:2.9.0-9.fc33.x86_64
> arora-0:0.11.0-23.fc33.x86_64
> brewtarget-0:2.1.0-16.fc33.x86_64
> gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
> kde-runtime-libs-0:17.08.3-15.fc33.i686
> kde-runtime-libs-0:17.08.3-15.fc33.x86_64
> kdelibs-6:4.14.38-23.fc34.i686
> kdelibs-6:4.14.38-23.fc34.x86_64
> kdelibs-webkit-6:4.14.38-23.fc34.i686
> kdelibs-webkit-6:4.14.38-23.fc34.x86_64
> knode-libs-0:4.14.10-44.fc33.i686
> knode-libs-0:4.14.10-44.fc33.x86_64
> krecipes-0:2.1.0-12.fc33.x86_64
> ksysguard-libs-1:4.11.22-28.fc33.i686
> ksysguard-libs-1:4.11.22-28.fc33.x86_64
> libkfbapi-0:1.0-16.fc32.i686
> libkfbapi-0:1.0-16.fc32.x86_64
> python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
> qlandkartegt-0:1.8.1-28.fc33.x86_64
> qmc2-0:0.195-14.fc34.x86_64
> qt-assistant-1:4.8.7-57.fc34.x86_64
> qt-demos-1:4.8.7-57.fc34.x86_64
> qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
> qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
> qt-examples-1:4.8.7-57.fc34.i686
> qt-examples-1:4.8.7-57.fc34.x86_64
> qt4pas-0:2.5-21.fc33.i686
> qt4pas-0:2.5-21.fc33.x86_64
> qtscriptbindings-0:0.2.0-23.fc33.i686
> qtscriptbindings-0:0.2.0-23.fc33.x86_64
> qtwebkit-devel-0:2.3.4-32.fc34.i686
> qtwebkit-devel-0:2.3.4-32.fc34.x86_64
> rekonq-0:2.4.2-17.fc33.x86_64
> timetablemate-0:0.10-0.24.20111204git.fc32.x86_64
>
> So among this list, I see as end-user applications:
>
> amarok - dead upstream music player
> arora, rekonq: dead upstream browers, hardly a good idea to use them
> brewtarget: has newer 2.3.0 release which supports Qt5
> gambas3-gb-qt4-webkit: qt4 subpackages could just be dropped
> krecipes: dead upstream
> qlandkartegt: dead upstream
> qmc2: latest trunk seems to support qt5
> timetablemate -> kde-plasma-publictransport: Plasma 5 applet, with last
> update in 2013 apparently
>
>
> Sooo, how about taking this as a pretext to just kick out all the qt4
> stuff? Debian has completed the move in March this year [1].
>
> Opinions?

I, for one, would welcome getting rid of all that old cruft ...
especially if debian already has beaten us to the punch.
Could you pour your research into the Change Proposal wiki template
and propose this for F34? :)

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

Review request for multiple trivial mingw-python-* packages

[Sandro Mani]

Hi

I've put up another bunch of mingw-python-* packages for review which I 
used to maintain in COPR but I'd like to move into Fedora proper:


mingw-python-pytz - https://bugzilla.redhat.com/show_bug.cgi?id=1895157
mingw-python-chardet - https://bugzilla.redhat.com/show_bug.cgi?id=1895161
mingw-python-idna - https://bugzilla.redhat.com/show_bug.cgi?id=1895162
mingw-python-six - https://bugzilla.redhat.com/show_bug.cgi?id=1895164
mingw-python-pygments - https://bugzilla.redhat.com/show_bug.cgi?id=1895165
mingw-python-urllib3 - https://bugzilla.redhat.com/show_bug.cgi?id=1895167
mingw-python-affine - https://bugzilla.redhat.com/show_bug.cgi?id=1895168
mingw-python-OWSLib - https://bugzilla.redhat.com/show_bug.cgi?id=1895172
mingw-python-markupsafe - 
https://bugzilla.redhat.com/show_bug.cgi?id=1895175

mingw-python-shapely - https://bugzilla.redhat.com/show_bug.cgi?id=1895181
mingw-python-pyyaml - https://bugzilla.redhat.com/show_bug.cgi?id=1895179
mingw-python-setuptools_scm - 
https://bugzilla.redhat.com/show_bug.cgi?id=1895185

mingw-python-lxml - https://bugzilla.redhat.com/show_bug.cgi?id=1895186

Note: The spec is basically identical between all the packages

Happy to review in exchange

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

Re: Heads up: poetry 1.1.x and poetry.core coming to rawhide

[Fabio Valentini]

On Thu, Nov 5, 2020 at 1:25 PM Miro Hrončok  wrote:
>
> Hello Pythonistas,
>
> this is a heads up that we plan to upgrade poetry to 1.1.x in rawhide soon:
>https://src.fedoraproject.org/rpms/poetry/pull-request/5
>
> It is blocked on python-lark-parser:
>https://src.fedoraproject.org/rpms/python-lark-parser/pull-request/5
>
> With this update, poetry was split into poetry.core and poetry. After trying 
> to
> keep the project in a single component, I've decided to package them 
> separately.
>
> I've tested all impacted packages in Fedora and there is no breakage.
>
> https://src.fedoraproject.org/rpms/poetry/pull-request/5#comment-60068
> https://src.fedoraproject.org/rpms/poetry/pull-request/5#comment-60070
>
>
> A friendly reminder: You can package poetry-based projects with
> pyproject-rpm-macros:
>
> https://src.fedoraproject.org/rpms/pyproject-rpm-macros (see the README)
>
>
> Thanks Fabio, who started the upgrade.

Thanks for succeeding where I failed with my hamfisted attempt :)

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

Review swap

[Jerry James]

Have you ever thought, "I wish Fedora had a command line utility where
I could type in an ASCII representation of the state of a Rubiks cube
and have it print an equally hard to read ASCII representation of the
moves needed to solve the cube"?  Have I got a package for you!

Sagemath 9.2 is out.  It unbundles the rubiks package (currently
sagemath-rubiks), so we now need a separate package.  Review request
here:

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

This package has no upstream.  Rather, it has 3 upstreams, all dead.
The sagemath developers now manage the code.  They keep some patches
for this code, as do various other Linux distributions.  I've
collected several such patches for Fedora.

I'm happy to review something for you in exchange.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Sandro Mani]

On 05.11.20 20:27, Sandro Mani wrote:


On 05.11.20 12:36, Tom Hughes wrote:

On 05/11/2020 11:24, Sandro Mani wrote:

I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
shortly. I'll do a round of test builds in this copr [1], and then 
build everything (and rebuild dependent packages) in a rawhide 
side-tag and then merge it.


That's definitely going to cause some breakage as I believe proj 7 has
finally removed the old legacy API which at least some other things like
mapnik are still using.

I believe there is an upstream patch for mapnik now but I'll have to
see if it can be backported to the release version...

Yes indeed - I'll go through the breakages, see if newer upstream 
versions fix the problem, and then will post a list of packages which 
need to be updated and contact the respective maintainers.


Soo, this opened a bit a can of worms, as qt-mobility (clearly being of 
the qt4 era dead upstream) is not going to support proj7. Only package 
requiring qt-mobility is qtwebkit, which in turn has a bit more users:


amarok-0:2.9.0-9.fc33.x86_64
arora-0:0.11.0-23.fc33.x86_64
brewtarget-0:2.1.0-16.fc33.x86_64
gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
kde-runtime-libs-0:17.08.3-15.fc33.i686
kde-runtime-libs-0:17.08.3-15.fc33.x86_64
kdelibs-6:4.14.38-23.fc34.i686
kdelibs-6:4.14.38-23.fc34.x86_64
kdelibs-webkit-6:4.14.38-23.fc34.i686
kdelibs-webkit-6:4.14.38-23.fc34.x86_64
knode-libs-0:4.14.10-44.fc33.i686
knode-libs-0:4.14.10-44.fc33.x86_64
krecipes-0:2.1.0-12.fc33.x86_64
ksysguard-libs-1:4.11.22-28.fc33.i686
ksysguard-libs-1:4.11.22-28.fc33.x86_64
libkfbapi-0:1.0-16.fc32.i686
libkfbapi-0:1.0-16.fc32.x86_64
python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
qlandkartegt-0:1.8.1-28.fc33.x86_64
qmc2-0:0.195-14.fc34.x86_64
qt-assistant-1:4.8.7-57.fc34.x86_64
qt-demos-1:4.8.7-57.fc34.x86_64
qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
qt-examples-1:4.8.7-57.fc34.i686
qt-examples-1:4.8.7-57.fc34.x86_64
qt4pas-0:2.5-21.fc33.i686
qt4pas-0:2.5-21.fc33.x86_64
qtscriptbindings-0:0.2.0-23.fc33.i686
qtscriptbindings-0:0.2.0-23.fc33.x86_64
qtwebkit-devel-0:2.3.4-32.fc34.i686
qtwebkit-devel-0:2.3.4-32.fc34.x86_64
rekonq-0:2.4.2-17.fc33.x86_64
timetablemate-0:0.10-0.24.20111204git.fc32.x86_64

So among this list, I see as end-user applications:

amarok - dead upstream music player
arora, rekonq: dead upstream browers, hardly a good idea to use them
brewtarget: has newer 2.3.0 release which supports Qt5
gambas3-gb-qt4-webkit: qt4 subpackages could just be dropped
krecipes: dead upstream
qlandkartegt: dead upstream
qmc2: latest trunk seems to support qt5
timetablemate -> kde-plasma-publictransport: Plasma 5 applet, with last 
update in 2013 apparently



Sooo, how about taking this as a pretext to just kick out all the qt4 
stuff? Debian has completed the move in March this year [1].


Opinions?

Thanks
Sandro

[1] https://wiki.debian.org/Qt4Removal
___
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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2020-11-06 from 21:00:00 to 22:00:00 UTC
   At fedora-meet...@irc.freenode.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9722/

___
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

Virtual Fedora 33 Release Party - You're invited! (Nov 6th & 7th)

[Marie Nordin]

Hey Fedora!

You're invited to the F33 Release Party! Tomorrow Friday November 6th and
Saturday November 7th. We will have a couple information sessions with
plenty of fun sessions mixed in like lightning talks, pictionary, and
special events! Get ready to celebrate :)

See all relevant links below.

Registration:
https://hopin.to/events/fedora-33-release-party


Schedule in wiki format:
https://fedoraproject.org/wiki/Fedora_33_Release_Party_Schedule#

Lightning talk signup:
https://fedoraproject.org/wiki/F33_Virtual_Release_Party_Lightning_Talk_Signup


Special event signup:
https://fedoraproject.org/wiki/F33_Virtual_Release_Party_Event_Signup

Can't wait to see you there,
Cheers!

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

T: +1.973.800.4967

IRC: riecatnor



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

Virtual Fedora 33 Release Party - You're invited! (Nov 6th & 7th)

[Marie Nordin]

Hey Fedora!

You're invited to the F33 Release Party! Tomorrow Friday November 6th and
Saturday November 7th. We will have a couple information sessions with
plenty of fun sessions mixed in like lightning talks, pictionary, and
special events! Get ready to celebrate :)

See all relevant links below.

Registration:
https://hopin.to/events/fedora-33-release-party


Schedule in wiki format:
https://fedoraproject.org/wiki/Fedora_33_Release_Party_Schedule#

Lightning talk signup:
https://fedoraproject.org/wiki/F33_Virtual_Release_Party_Lightning_Talk_Signup


Special event signup:
https://fedoraproject.org/wiki/F33_Virtual_Release_Party_Event_Signup

Can't wait to see you there,
Cheers!

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

T: +1.973.800.4967

IRC: riecatnor



___
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 1891366] Failed to start LSB: web-based administration interface for Unix systems.

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
(In reply to FlyDove from comment #3)
> sudo dnf install perl-Encode-Detect perl-Socket6 perl-Authen-PAM   Fedora32

Reinstalling perl-Socket6 RPM package from Fedora  won't help you. You need to
reinstall a program that prints the "Socket6.c: loadable library and perl
binaries are mismatched" message. It's either webmin, or Socket6 Perl module
from CPAN.


-- 
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: ld segfaults on rawhide

[Miroslav Suchý]

Dne 04. 11. 20 v 16:58 Will Crawford napsal(a):
> Does anyone know when this is likely to be available in COPR build roots?

Copr does not have any special repository. As soon as it hit stable (see Bodhi) 
and the compose is made, then it is
available in Copr.

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

[Bug 1891366] Failed to start LSB: web-based administration interface for Unix systems.

[bugzilla]

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

FlyDove  changed:

   What|Removed |Added

  Flags|needinfo?(flyd...@qq.com)   |



--- Comment #3 from FlyDove  ---
sudo dnf install perl-Encode-Detect perl-Socket6 perl-Authen-PAM   Fedora32


-- 
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 1891366] Failed to start LSB: web-based administration interface for Unix systems.

[bugzilla]

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

FlyDove  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |CANTFIX
Last Closed||2020-11-05 07:44:11




-- 
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 1894714] perl-ExtUtils-MakeMaker-7.52 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-ExtUtils-MakeMaker-7.5
   ||2-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-05 07:20:03




-- 
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 1894714] perl-ExtUtils-MakeMaker-7.52 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




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

[Bug 1894777] perl-File-Path-2.18 is available

[bugzilla]

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



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


-- 
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 1894777] perl-File-Path-2.18 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-File-Path-2.18-1.fc34




-- 
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 1894777] perl-File-Path-2.18 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




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

Re: Heads up: proj 7.2.0 + gdal 3.2.0

[Sandro Mani]

On 05.11.20 12:36, Tom Hughes wrote:

On 05/11/2020 11:24, Sandro Mani wrote:

I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
shortly. I'll do a round of test builds in this copr [1], and then 
build everything (and rebuild dependent packages) in a rawhide 
side-tag and then merge it.


That's definitely going to cause some breakage as I believe proj 7 has
finally removed the old legacy API which at least some other things like
mapnik are still using.

I believe there is an upstream patch for mapnik now but I'll have to
see if it can be backported to the release version...

Yes indeed - I'll go through the breakages, see if newer upstream 
versions fix the problem, and then will post a list of packages which 
need to be updated and contact the respective maintainers.


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

Re: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)

[James Cassell]

On Wed, Nov 4, 2020, at 1:12 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Stratis_2.2.0
> 
> Stratis 2.2.0 now places Stratis filesystem symlinks in /dev/stratis,
> rather than /stratis. Stratis creates and maintains the symlinks by
> means of udev rules, rather than directly via stratisd as previously.
> The /stratis directory is neither created nor used by stratisd 2.2.0.
> 

Thank you! The top level directory had previously made stratis a non-starter 
for me.

V/r,
James Cassell
___
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 1894777] New: perl-File-Path-2.18 is available

[bugzilla]

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

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



Latest upstream release: 2.18
Current version/release in rawhide: 2.17-2.fc33
URL: http://search.cpan.org/dist/File-Path/

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


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

Orpahing notepadqq

[Jan De Luyck]

Hi list,

Due to limited/no movement in the upstream[1] and more and more dependencies 
(nodejs packages) being orphaned within Fedora, I'm planning to orphan 
notepadqq.

If someone wants to step up and try to get it back working, let me/Sagitter 
know.

Kind regards,

Jan

[1] https://github.com/notepadqq/notepadqq/commits/master___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Stellard]

On 11/5/20 10:44 AM, Robbie Harwood wrote:

Ben Cotton  writes:


= Phase 2: Package Updates =
Once we have the list of packages that need to be updated, we will
proceed with adding BuildRequires: make to all spec files that require
it.  This new BuildRequires will be added to the line after the last
BuildRequires in the spec file.  The release number for packages will
'''*not*''' be incremented for this change.

The spec file updates will be automated and changes will be pushed
directly to dist-git once they are ready.


-1.  I think you should use pull requests for this, and continue to
believe that mass-pushing changes to dist-git is an abuse of
provenpackager.



This came up in the discussion about removing from gcc/g++ from the 
buildroot and it seemed to me like committing directly was preferred, 
though I understand not everyone may agree with this.


I'm planning to do an announcement on the mailing list and give 
maintainers about a week to make the changes manually if that is what 
they prefer.  I will update the proposal to make this clear.


-Tom


Thanks,
--Robbie


___
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 1894755] New: perl-IO-Pager-2.10 is available

[bugzilla]

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

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



Latest upstream release: 2.10
Current version/release in rawhide: 2.01-1.fc34
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

Re: HEADSUP: libsepol and libsemanage soname bump

[Brian C. Lane]

On Thu, Nov 05, 2020 at 03:59:18PM +0100, Petr Lautrbach wrote:
> > There are few other components which needs to be rebuild:
> > 
> > parted - for some reason it links to libsepol even though I haven't found a 
> > code
> >   which would use it. I've proposed patch upstream
> >   
> > https://alioth-lists.debian.net/pipermail/parted-devel/2020-November/005500.html

I've applied your patch upstream, and it is currently building for
rawhide.

Thanks!

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
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: [COPR] Build against libuv and Judy librairies

[Kevin Fenzi]

On Thu, Nov 05, 2020 at 09:29:46AM +0100, Didier Fabert wrote:
> Hi,
> 
> I try to make an epel-8 package on COPR, and I get the following errors in
> root.log
> DEBUG util.py:634:  No matching package to install: 'Judy-devel'
> DEBUG util.py:634:  No matching package to install: 'libuv-devel'
> 
> It's working as expected on Koji.
> 
> AM I missing something in my conf ?

epel8 in koji has the centos-devel repo also enabled...

https://wiki.centos.org/FAQ/develrepo

Try enabling that in your copr?

kevin


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

Re: HEADSUP: libsepol and libsemanage soname bump

[Jeff Law]

On 11/5/20 7:59 AM, Petr Lautrbach wrote:
> On Wed, Nov 04, 2020 at 09:47:50AM +0100, Petr Lautrbach wrote:
>> Hi,
>>
>> in order to prevent backward compatibility libsepol and libsemanage used had 
>> few
>> symbols defined twice and used symbol versioning for them. But when LTO was
>> enabled these symbols were completely dropped during compilation, see
>> https://github.com/SELinuxProject/selinux/issues/245
>>
>> In order to fix it, it was decided to drop these duplicate symbols and also 
>> long
>> time deprecated symbols and therefore sonames of libsepol and libsemanage 
>> were
>> bumped.
>>
>> The following SELinux userspace components are built and prepared to be 
>> merged in
>> "f34-build-side-33413" side tag:
>>
>> selinux-policy-3.14.7-7.fc34
>> setools-4.4.0-0.1.20201102git05e90ee.fc34
>> checkpolicy-3.1-4.fc34
>> policycoreutils-3.1-5.fc34
>> libsemanage-3.1-4.fc34
>> libselinux-3.1-4.fc34
>> libsepol-3.1-4.fc34
>>
>> There are few other components which needs to be rebuild:
>>
>> parted - for some reason it links to libsepol even though I haven't found a 
>> code
>>   which would use it. I've proposed patch upstream
>>   
>> https://alioth-lists.debian.net/pipermail/parted-devel/2020-November/005500.html
>>
>> shadow-utils - https://src.fedoraproject.org/rpms/shadow-utils/pull-request/6
>> sssd - https://src.fedoraproject.org/rpms/sssd/pull-request/7
>>
>> As none of packages which require either libsepol or libsemanage use dropped
>> symbols and in order not to break build root during soname bumps I've added 
>> temporary
>> subpackages with original library versions - libsepol-compat with 
>> libsepol.so.1
>> and libsemanage-compat with libsemanage.so.1. These subpackage will be 
>> dropped
>> as soon as everything is rebuilt in Rawhide.
>>
>> I've sucessfuly built all packages also in my COPR repository
>> https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/builds/
>>
>> If there's no objection I'd like to merge the side tag to rawhide as soon as 
>> possible.
>>
> This is merged now 
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-44f878be7e

Thanks!  Good to have those off my LTO list as well :-)


jeff
___
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 1894714] New: perl-ExtUtils-MakeMaker-7.52 is available

[bugzilla]

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

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



Latest upstream release: 7.52
Current version/release in rawhide: 7.50-1.fc34
URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/

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


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

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

[Arjun Shankar]

> Definitely happy to throw nscd out for something better that was just as
> simple and easy to set up.

> I'll leave systemd-resolved for the trail blazers.

Since systemd-resolved is already on by default since Fedora 33 [1],
the user base should be up quite a bit as users continue to upgrade.
It's not just trail blazers any more, and it's not just easy: it's already set
up.

Is there a concern or known issue that will cause systemd-resolved to
not work in your setup?

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Gary Buhrmaster]

On Thu, Nov 5, 2020 at 3:44 PM Robbie Harwood  wrote:
>
> Ben Cotton  writes:
> >
> > The spec file updates will be automated and changes will be pushed
> > directly to dist-git once they are ready.
>
> -1.  I think you should use pull requests for this, and continue to
> believe that mass-pushing changes to dist-git is an abuse of
> provenpackager.
>

While the individuals actively participating in this
discussion are likely willing to deal with any changes
as approved, and some wish to do it themselves in
advance rather than having a bulk change applied
to the packages they shepard, it is my belief that
there are a lot of packagers that will welcome
someone else doing the changes for them,
especially when they have many packages, or are
only an occasional packager that does not fully grok
all the packaging infrastructure/artifacts and may
not always pay close attention to these change
proposals, and could easily be surprised if their
package FTBFS at the next (mass) rebuild due to
one of these types of changes.

I don't know how to measure the "silent" majorities
of packagers opinions/preferences that such
change proposals should default to, but I certainly
believe we should do what is preferred and
easiest for the majority (and not for specific
people), especially when the change impacts
around a third of the packages out there.

My gut tells me that automatically adding in the
BR make to the package source, if not already
there (giving those that wish to make the change
themselves an opportunity to add it now) is going
to be the best for the most, but I have no
actual data to support that conclusion.

And, for what it is worth, recent changes that
impacted lots of packages (for F33, the cmake
macro changes) resulted in updates by the change
owners to packages so that the packagers could,
should they choose, mostly ignore the change
proposal and focus on other things.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Florian Weimer]

* Daniel P. Berrangé:

> Do we need a default build root package set at all ?

I think we need something for running the SRPM build and later for
parsing the spec file to get the actual build dependencies.  Both steps
can run arbitrary code, so they need a build environment.

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Robbie Harwood]

Ben Cotton  writes:

> = Phase 2: Package Updates =
> Once we have the list of packages that need to be updated, we will
> proceed with adding BuildRequires: make to all spec files that require
> it.  This new BuildRequires will be added to the line after the last
> BuildRequires in the spec file.  The release number for packages will
> '''*not*''' be incremented for this change.
>
> The spec file updates will be automated and changes will be pushed
> directly to dist-git once they are ready.

-1.  I think you should use pull requests for this, and continue to
believe that mass-pushing changes to dist-git is an abuse of
provenpackager.

Thanks,
--Robbie


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 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Robbie Harwood]

Stephen John Smoogen  writes:

> On Thu, 5 Nov 2020 at 08:52,  wrote:
>
>> The make package use 539k of space. And for gcc + C++ it's more than
>> 30 Mo.  Does it really worth the effort on changing all the dependent
>> packages ?
>
> Personally I am getting tired of this death of the buildroot by a
> million cuts. Could we just 'engineer' the build root to have what we
> want in it versus these continual sculptor like cuts to a block of
> marble to try and get the inner statue out? Because in around 10-20
> more Fedora releases someone is going to say 'this is a pile of
> rubble' and start on a new block.

Same.  If the goal is to not have a BuildRoot at all, let's just make
that change all at once.  Or if the goal is to have a minimal BuildRoot,
go about it in the other direction: list things that should be in it,
rather than pruning stuff out one change at a time.

Thanks,
--Robbie


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

qemu & LTO

[Richard W.M. Jones]

We discovered a few days ago that LTO broke qemu on aarch64.

The original bug reported was:

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

But actually looking at the build.log[1] we see another assertion
failure in the test suite.  (Unfortunately although we run the test
suite, the spec file was ignoring the result so the broken build
escaped into Rawhide.)

Because qemu is a complicated piece of software we're not clear if the
bugs found are general bugs in LTO, bugs which are specific to LTO on
aarch64, or bugs in qemu which are exposed by optimizations made
possible by LTO.

One thing we do suspect is that this could be the tip of the iceberg
since the qemu test suite only tests a tiny fraction of the code.

LTO has been disabled across all arches for now.  See the list of
latest commits that Dan has added:

https://src.fedoraproject.org/rpms/qemu/commits/master

Rich.

[1] 
https://kojipkgs.fedoraproject.org//packages/qemu/5.1.0/6.fc34/data/logs/aarch64/build.log
 from https://koji.fedoraproject.org/koji/buildinfo?buildID=1634562

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: Packaging rules for build from source vs BPF byte code ?

[Vít Ondruch]

Dne 05. 11. 20 v 13:03 Daniel P. Berrangé napsal(a):

On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote:

On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé  wrote:

In QEMU there's a desire to make use of BPF programs for implementing
some networking features. The current patches are proposing adding
prebuilt BPF byte code to the QEMU repo, with source available, but
not actually building from source during a build.

I was wondering if we had any specific guidance or rules covering the
shipping BPF programs in particular ?

To me it feels like BPF programs should fall under normal Fedora
practice that expects everything to be built from master source.

We do have the exception that allows firmware to be shipped as
pre-built blobs, but I'm thinking that BPF programs could not
be considered as firmware.

Has this been discussed before, if so can someone point to the
results, as I'm not finding anything specific to BPF programs and
Fedora packaging via Google.

If there are no specialized Packaging Guidelines for something, then
the general guidelines apply - so in this case, compiling from source
is required, since Fedora packages MUST NOT ship precompiled binaries.

It seems this case is a little more fuzzy in terms of what is
considered "the preferred source" format, and whether the BPF
program is in fact considered a "binary" at all.



I think that the best would be if the "binary" was stripped from the 
guidelines. Because, you could somewhat argue about JARs or GEM and I 
believe, that this guideline should apply also to documentation as well 
as various grammar parsers generators etc.



Vít





There is the "dpdk" package in Fedora which is doing similar to
what is being proposed for QEMU.

In dpdk-stable-19.11.3/drivers/net/tap/tap_bpf_program.c there is
BPF "source code".

This was, at some point in time, apparently compiled using some
undefined process to create a binary byte code blob.

This binary blob was then processed, again by some undefined process,
to extract just the BPF instructions, which are then turned back
into "source code" as  a static byte array in a C header file. The
latter is what is actually compiled. This derived source is in the

   dpdk-stable-19.11.3/drivers/net/tap/tap_bpf_insns.h


Given that dpdk is not providing any build process for going from
tap_bpf_program.c to tap_bpf_insns.h, it looks to me like the upstream
project effectively considers  "tap_bpf_insns.h" to be their preferred
source form, and  tap_bpf_program.c as just a reference for its
original creation.

IOW, to me it looks like this embedded BPF program shouldn't be
considered a binary from Fedora POV and can be used as is.

Regards,
Daniel

___
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: HEADSUP: libsepol and libsemanage soname bump

[Petr Lautrbach]

On Wed, Nov 04, 2020 at 09:47:50AM +0100, Petr Lautrbach wrote:
> Hi,
> 
> in order to prevent backward compatibility libsepol and libsemanage used had 
> few
> symbols defined twice and used symbol versioning for them. But when LTO was
> enabled these symbols were completely dropped during compilation, see
> https://github.com/SELinuxProject/selinux/issues/245
> 
> In order to fix it, it was decided to drop these duplicate symbols and also 
> long
> time deprecated symbols and therefore sonames of libsepol and libsemanage were
> bumped.
> 
> The following SELinux userspace components are built and prepared to be 
> merged in
> "f34-build-side-33413" side tag:
> 
> selinux-policy-3.14.7-7.fc34
> setools-4.4.0-0.1.20201102git05e90ee.fc34
> checkpolicy-3.1-4.fc34
> policycoreutils-3.1-5.fc34
> libsemanage-3.1-4.fc34
> libselinux-3.1-4.fc34
> libsepol-3.1-4.fc34
> 
> There are few other components which needs to be rebuild:
> 
> parted - for some reason it links to libsepol even though I haven't found a 
> code
>   which would use it. I've proposed patch upstream
>   
> https://alioth-lists.debian.net/pipermail/parted-devel/2020-November/005500.html
> 
> shadow-utils - https://src.fedoraproject.org/rpms/shadow-utils/pull-request/6
> sssd - https://src.fedoraproject.org/rpms/sssd/pull-request/7
> 
> As none of packages which require either libsepol or libsemanage use dropped
> symbols and in order not to break build root during soname bumps I've added 
> temporary
> subpackages with original library versions - libsepol-compat with 
> libsepol.so.1
> and libsemanage-compat with libsemanage.so.1. These subpackage will be dropped
> as soon as everything is rebuilt in Rawhide.
> 
> I've sucessfuly built all packages also in my COPR repository
> https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/builds/
> 
> If there's no objection I'd like to merge the side tag to rawhide as soon as 
> possible.
> 

This is merged now 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-44f878be7e


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 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Stephen John Smoogen]

On Thu, 5 Nov 2020 at 09:42, Daniel P. Berrangé  wrote:

> On Thu, Nov 05, 2020 at 08:57:32AM -0500, Stephen John Smoogen wrote:
> > On Thu, 5 Nov 2020 at 08:52,  wrote:
> >
> > > The make package use 539k of space. And for gcc + C++ it's more than
> 30 Mo.
> > > Does it really worth the effort on changing all the dependent packages
> ?
> > >
> > >
> > Personally I am getting tired of this death of the buildroot by a million
> > cuts. Could we just 'engineer' the build root to have what we want in it
> > versus these continual sculptor like cuts to a block of marble to try and
> > get the inner statue out? Because in around 10-20 more Fedora releases
> > someone is going to say 'this is a pile of rubble' and start on a new
> > block.
>
> Do we need a default build root package set at all ?
>
> Can it be the empty set, and then have RPMs specify their full set
> of build requires without assuming any defaults ?
>
> "fast death by one big cut" instead of "slow death by a million cuts",
> which will put an end to repeated feature proposals to trim out some
> new thing from the build root.
>
>
That is my grumpy morning idea.. each one of these proposals comes with a
"this drops down the need for pulling in packages which are never used..
makes the build root N k smaller... etc." which is a boilerplate text which
eventually takes up more disk space on all the mail and web servers keeping
track of these emails than is saved in anyone's buildroot.

If we are going to have a 'buildroot' it should just be the packages we
know are needed for everything.. and if that is {} then it is {}. If it is
a {} then it needs to be documented what is in it and why each package is
in it. Maybe SuSE has always been right to make sure that nearly everything
is actually documented as required/buildrequired in a package. [Or at least
this has been my opinion from looking through their spec files.]

Anyway I am going back to trying to figure out how to open this child
safety headache medicine bottle.. and will stop being a grump here.



> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


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

[Bug 1893788] EPEL8 request: perl-Mail-IMAPClient

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Tom "spot" Callaway  ---
You have admin permissions on perl-Mail-IMAPClient, go forth. :)


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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Daniel P . Berrangé]

On Thu, Nov 05, 2020 at 08:57:32AM -0500, Stephen John Smoogen wrote:
> On Thu, 5 Nov 2020 at 08:52,  wrote:
> 
> > The make package use 539k of space. And for gcc + C++ it's more than 30 Mo.
> > Does it really worth the effort on changing all the dependent packages ?
> >
> >
> Personally I am getting tired of this death of the buildroot by a million
> cuts. Could we just 'engineer' the build root to have what we want in it
> versus these continual sculptor like cuts to a block of marble to try and
> get the inner statue out? Because in around 10-20 more Fedora releases
> someone is going to say 'this is a pile of rubble' and start on a new
> block.

Do we need a default build root package set at all ?

Can it be the empty set, and then have RPMs specify their full set
of build requires without assuming any defaults ?

"fast death by one big cut" instead of "slow death by a million cuts",
which will put an end to repeated feature proposals to trim out some
new thing from the build root.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 05, 2020 at 08:57:32AM -0500, Stephen John Smoogen wrote:
> On Thu, 5 Nov 2020 at 08:52,  wrote:
> 
> > The make package use 539k of space. And for gcc + C++ it's more than 30 Mo.
> > Does it really worth the effort on changing all the dependent packages ?
> >
> >
> Personally I am getting tired of this death of the buildroot by a million
> cuts. Could we just 'engineer' the build root to have what we want in it
> versus these continual sculptor like cuts to a block of marble to try and
> get the inner statue out?

Only if the tools we use never change. 10 years ago make was widely used.
Nowadays with meson, I go weeks without a single make invocation.
Python/rust/etc. don't normally require make either.

The nice thing about this proposal is that it tries to do the right thing
and preemptively fix all packages. If everything goes well, the change 
will be mostly invisible. Nice and incremental, that's the way to do things
in a distro without making people unhappy.

> Because in around 10-20 more Fedora releases someone is going to say
> 'this is a pile of rubble' and start on a new block.

This change is something that actually helps avoid that: evolve with
the times, instead of trying to cling to an outdated tool, until in 5–10
years we think that so much cruft has accumulated that it's better to
start over.

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 05/11/2020 11:56, Kevin Kofler via devel wrote:


CMake actually just generates the makefiles, you still run make directly (as
with autotools).

The makefiles then do several complex things, possibly including running
make with different arguments (and also calling back into CMake by running
cmake with special arguments multiple times), to handle the progress
reporting, but the initial make invocation comes from the specfile.


Not using the new %cmake_build etc macros it doesn't. Those invoke
cmake which then invokes make.

Tom

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

Re: Packaging rules for build from source vs BPF byte code ?

[Gerd Hoffmann]

  Hi,

> QEMU ships various keymap data files which are auto-generated from data
> provided by X11, but none of these are built "from source", because the
> generated data files are considered the preferred source form. 

Well, the actual reason is the X11 dependency.  qemu needs those files
also on non-X11 platforms like Windows, but generating them on non-X11
platforms doesn't work.

Also note that if we could easily gather the data needed to generate
those keymap files on all platforms we would not need them in the first
place ;)

BTW: Starting with qemu 5.2 those files will be regenerated during the
build if the required dependency (xkbcommon-devel) is available at build
time.

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Stephen John Smoogen]

On Thu, 5 Nov 2020 at 08:52,  wrote:

> The make package use 539k of space. And for gcc + C++ it's more than 30 Mo.
> Does it really worth the effort on changing all the dependent packages ?
>
>
Personally I am getting tired of this death of the buildroot by a million
cuts. Could we just 'engineer' the build root to have what we want in it
versus these continual sculptor like cuts to a block of marble to try and
get the inner statue out? Because in around 10-20 more Fedora releases
someone is going to say 'this is a pile of rubble' and start on a new
block.



> - Mail original -
> De: "Zbigniew Jędrzejewski-Szmek" 
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> Envoyé: Jeudi 5 Novembre 2020 14:42:08
> Objet: Re: Fedora 34 Change proposal: Remove make from BuildRoot
> (System-Wide Change)
>
> On Thu, Nov 05, 2020 at 01:13:47PM +0100, Fabio Valentini wrote:
> > On Wed, Nov 4, 2020 at 9:46 PM Neal Gompa  wrote:
> >
> > (snip)
> >
> > >
> > > Koji/Brew disables weak dependencies. The weak dependency would be for
> > > developer convenience.
> > >
> > > > If the change was automated and you did not have to do anything would
> > > > you still be opposed to having your spec files updated with
> > > > BuildRequires: make
> > > >
> > >
> > > You still need BR: make.
> >
> > Couldn't we add something like this to the cmake package?
> >
> > Requires: (make or ninja)
> > Suggests: make
> >
> > Which would make sure at least *one* of the available backends is
> > installed, and would make it prefer make if ninja is not specified
> > explicitly.
>
> It that works, it'd be great.
>
> 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


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

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #27 from Tom "spot" Callaway  ---
Okay, please test this build and let me know if anything changes:

https://koji.fedoraproject.org/koji/taskinfo?taskID=54919576


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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[ycollette . nospam]

The make package use 539k of space. And for gcc + C++ it's more than 30 Mo.
Does it really worth the effort on changing all the dependent packages ?

- Mail original -
De: "Zbigniew Jędrzejewski-Szmek" 
À: "Development discussions related to Fedora" 
Envoyé: Jeudi 5 Novembre 2020 14:42:08
Objet: Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide 
Change)

On Thu, Nov 05, 2020 at 01:13:47PM +0100, Fabio Valentini wrote:
> On Wed, Nov 4, 2020 at 9:46 PM Neal Gompa  wrote:
> 
> (snip)
> 
> >
> > Koji/Brew disables weak dependencies. The weak dependency would be for
> > developer convenience.
> >
> > > If the change was automated and you did not have to do anything would
> > > you still be opposed to having your spec files updated with
> > > BuildRequires: make
> > >
> >
> > You still need BR: make.
> 
> Couldn't we add something like this to the cmake package?
> 
> Requires: (make or ninja)
> Suggests: make
> 
> Which would make sure at least *one* of the available backends is
> installed, and would make it prefer make if ninja is not specified
> explicitly.

It that works, it'd be great.

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
___
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 1894364] perl-CPANPLUS-Dist-Fedora-0.4.2 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-CPANPLUS-Dist-Fedora-0
   ||.4.2-1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-11-04 14:56:59




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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 05, 2020 at 01:13:47PM +0100, Fabio Valentini wrote:
> On Wed, Nov 4, 2020 at 9:46 PM Neal Gompa  wrote:
> 
> (snip)
> 
> >
> > Koji/Brew disables weak dependencies. The weak dependency would be for
> > developer convenience.
> >
> > > If the change was automated and you did not have to do anything would
> > > you still be opposed to having your spec files updated with
> > > BuildRequires: make
> > >
> >
> > You still need BR: make.
> 
> Couldn't we add something like this to the cmake package?
> 
> Requires: (make or ninja)
> Suggests: make
> 
> Which would make sure at least *one* of the available backends is
> installed, and would make it prefer make if ninja is not specified
> explicitly.

It that works, it'd be great.

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

Re: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

[Fabio Valentini]

On Thu, Nov 5, 2020 at 2:07 PM Michal Schorm  wrote:
>
> On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini  wrote:
> > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton  wrote:
> > > == Contingency Plan ==
> > >
> > > Modules will provide the functional version of MariaDB 10.4, available to 
> > > all users.
> > > * Contingency mechanism: Fedora Modules for 10.4 available
> >
> > This is not a sufficient contingency plan. Leaving broken 10.5
> > non-modular packages in f34 is a non-starter.
> >
> > Is there a realistic path to back out of the 10.5 update in rawhide /
> > F34 if there are problems?
> > It looks like the 10.4 -> 10.5 update requires database upgrades as
> > well, so would MariaDB 10.4 have problems with accessing databases
> > that have been migrated to 10.5?
>
> In the worst case scenario, I would be forced to revert the change,
> bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4
> instead.
>
> Database upgrades in general (this is not just about MariaDB or MySQL)
> are very problematic.
> Every sane DB upgrade *ever* should have a data backup prior and I
> don't want, nor have any means to, solve the cases of corrupted DB
> data which haven't got a backup.
>
> What would be an issue however, if a significant number of users would
> report the upgrade is problematic and they can't use the DB with the
> new version.
> The best thing both they and I can do is to file a BZ ticket (so we
> are informed about it in the first place).
> I will search the upstream JIRA ticket system for workarounds as a
> part of the problem solving.
> If any are found, I'd try to apply them or at least provide them to the users.
>
> If the issues would be in place but no solution in sight, the revert
> to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to
> go.
>
> If you will agree to this contingency mechanism, I will add it to the
> Self-Contained Change wiki page.
> Otherwise I'd ask you for a suggestion of what you picture as
> sufficient contingency mechanism.

Yes, this sounds like a good compromise. Thanks!

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

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

[Petr Menšík]

On 11/5/20 12:49 PM, Florian Weimer wrote:
> * Petr Menšík:
> 
> 
> nscd has more usage downstream, leading to bugs such as:
> 
>   

I have very limited understanding of sssd principles. But I think it is
not comparable to nscd, which you just start or stop. No other
configuration is required.
> 
> Most of them are private, but you should be able to view them.
Yes, I can. Linked bug references netgroup not cached, I cannot comment
it, know no additional information.
> 
>> Instead, I request again, split systemd-resolved into subpackage. I want
>> it removed on my system and so do more people. Also, when I disable it,
>> I have to fix /etc/resolv.conf by hand. I would think NetworkManager
>> restart would refresh classic /etc/resolv.conf, like in F32.
> 
> This proposal is about nscd, not systemd-resolved.
systemd-resolved is mentioned in the title and the body of proposal. So
it seems it is about it.
> 
> If Fedora chooses to adopt another local DNS cache, glibc will use that
> (probably using the built-in nss_dns service module) systemd-resolved is
> just what we have for now, so the proposal references it.  But any other
> DNS cache will work as well.
I do not think there is another cache like nscd, which does not require
/etc/resolv.conf change or special nss hosts module. While I admit there
are more caches, I don't think any provides drop-in replacement.
Especially resolve nss plugin introduces so many (unannounced) changes,
I don't think it is a good alternative. Caching via dns module might be
more predictable even with systemd-resolved.
> 
> The hosts cache in nscd is arguably the weakest part of it, so
> deprecating really shouldn't be controversial at all.
If you offer alternative, which improves caching without additional
regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
can be compared to no configuration of nscd. Unlike other resolvers,
nscd caches only getaddrinfo calls, without ever touching outgoing DNS
client queries or /etc/resolv.conf modification. Is there any other
service able to do it?

Are there bugs I can help fixing, especially in hosts or ahosts databases?

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Description: application/pgp-keys


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

Re: Packaging rules for build from source vs BPF byte code ?

[Daniel P . Berrangé]

On Thu, Nov 05, 2020 at 07:54:16AM -0500, Chuck Anderson wrote:
> On Thu, Nov 05, 2020 at 12:03:43PM +, Daniel P. Berrangé wrote:
> > Given that dpdk is not providing any build process for going from
> > tap_bpf_program.c to tap_bpf_insns.h, it looks to me like the upstream
> > project effectively considers  "tap_bpf_insns.h" to be their preferred
> > source form, and  tap_bpf_program.c as just a reference for its
> > original creation.
> > 
> > IOW, to me it looks like this embedded BPF program shouldn't be
> > considered a binary from Fedora POV and can be used as is.
> 
> One example of a package doing something incorreclty doesn't mean it
> is okay to continue that practice.  I'd argue thet dpdk needs to be
> fixed to provide the original source code and build scripts for the
> BPF program.

The point is that this doesn't feel much different from many other
scenarios that applications often do wrt code generation. Any non
trivial application will have source files whose contents are
auto-generated, and the used as is, instead of building from source
every time.

Every single autotools based application is shipping a pre-generated
configure script, whose content may or may not match what is expressed
in the configure.ac script. Fedora doesn't require "configure" to be
re-generated from source every time, nor validate that the "configure.ac"
actually is the corresponding source.

There are certainly other cases where programs ship sources which were
originally generated from some other data file, but don't even include
the rules to reproduce that.

QEMU ships various keymap data files which are auto-generated from data
provided by X11, but none of these are built "from source", because the
generated data files are considered the preferred source form. 

Libvirt ships various test cases where the source is auto-generated from
data extracted from QEMU. These generated files are used as is, and not
re-created by QEMU during Fedora builds, because Fedora doesn't have all
30+ historical versions of QEMU available in the build root.

The embedded static arrays in source containing BPF instruction are not
conceptually that different from other cases where we build using generated
sources and don't re-generated during Fedora builds.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

[Michal Schorm]

On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini  wrote:
> On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton  wrote:
> > == Contingency Plan ==
> >
> > Modules will provide the functional version of MariaDB 10.4, available to 
> > all users.
> > * Contingency mechanism: Fedora Modules for 10.4 available
>
> This is not a sufficient contingency plan. Leaving broken 10.5
> non-modular packages in f34 is a non-starter.
>
> Is there a realistic path to back out of the 10.5 update in rawhide /
> F34 if there are problems?
> It looks like the 10.4 -> 10.5 update requires database upgrades as
> well, so would MariaDB 10.4 have problems with accessing databases
> that have been migrated to 10.5?

In the worst case scenario, I would be forced to revert the change,
bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4
instead.

Database upgrades in general (this is not just about MariaDB or MySQL)
are very problematic.
Every sane DB upgrade *ever* should have a data backup prior and I
don't want, nor have any means to, solve the cases of corrupted DB
data which haven't got a backup.

What would be an issue however, if a significant number of users would
report the upgrade is problematic and they can't use the DB with the
new version.
The best thing both they and I can do is to file a BZ ticket (so we
are informed about it in the first place).
I will search the upstream JIRA ticket system for workarounds as a
part of the problem solving.
If any are found, I'd try to apply them or at least provide them to the users.

If the issues would be in place but no solution in sight, the revert
to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to
go.

If you will agree to this contingency mechanism, I will add it to the
Self-Contained Change wiki page.
Otherwise I'd ask you for a suggestion of what you picture as
sufficient contingency mechanism.

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: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)

[Dan Čermák]

Ben Cotton  writes:

> == Contingency Plan ==
> * Contingency mechanism:
> * Contingency deadline: N/A
> * Blocks release? No
> * Blocks product? No

Shouldn't there be a contingency plan? We should have a plan B for the
case that the update would introduce serious regressions.


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

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

[Nico Kadel-Garcia]

On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  wrote:
>
> No, no, NO again.
>
> nscd has no important active bugs in Fedora. I am not sure what bugs are
> mentioned, but just a few active bugs are on glibc component in Fedora.
> Therefore it seems just fine no commits are good.
>
> Just unlike systemd-resolved, which actively breaks some use cases. It
> changes resolution order of search directive in resolv.conf, breaks
> DNSSEC, breaks one label names resolution. It is famous among DNS
> community [1].

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

The sophisticated setups available by hand-editing sssd are also
*inevitably* overwritten by any use of the 'authconfig' command, which
is used by various RPM '%post' operations. sssd's configuration
options are so poor that they may as well be malicious. It is most
effective in small and unsophisticated network environments. It
suffers from the "systemd" style, sprawling universal management tool
design principles and makes many straightforward operations very
difficult if not impossible.

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

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

That's a separate issue. Maybe start a separate thread about that?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging rules for build from source vs BPF byte code ?

[Chuck Anderson]

On Thu, Nov 05, 2020 at 12:03:43PM +, Daniel P. Berrangé wrote:
> Given that dpdk is not providing any build process for going from
> tap_bpf_program.c to tap_bpf_insns.h, it looks to me like the upstream
> project effectively considers  "tap_bpf_insns.h" to be their preferred
> source form, and  tap_bpf_program.c as just a reference for its
> original creation.
> 
> IOW, to me it looks like this embedded BPF program shouldn't be
> considered a binary from Fedora POV and can be used as is.

One example of a package doing something incorreclty doesn't mean it
is okay to continue that practice.  I'd argue thet dpdk needs to be
fixed to provide the original source code and build scripts for the
BPF program.
___
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: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

[Miro Hrončok]

On 11/5/20 1:44 PM, Michal Schorm wrote:

On Wed, Nov 4, 2020 at 10:55 AM Miro Hrončok  wrote:

Are there packages that require rebuilding? E.g. I see that some packages
require libmariadbd.so.19. What is the plan regarding them?


Packages that require the server (embedded) library
"libmariadbd.so.19" are the only one that might need rebuild.
Currently this is only a single package 'amarok', so I can cooperate
with its maintainer if rebuild would be needed.

The changes between the server embedded library between MariaDB 10.4
and 10.5 shouldn't be significant, other than added functionality.
I have to check the ABI compatibility to be sure. If the functionality
would be only extended, the dependent package might not need rebuild
at all; though it still would get one during some mass rebuild.

I added my above reply to the Self Contained Change.


Thank You.

My only remaining concern is the contingency mechanism (which is discussed 
elsewhere in this thread).


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

Re: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

[Michal Schorm]

On Wed, Nov 4, 2020 at 10:55 AM Miro Hrončok  wrote:
> Are there packages that require rebuilding? E.g. I see that some packages
> require libmariadbd.so.19. What is the plan regarding them?

Packages that require the server (embedded) library
"libmariadbd.so.19" are the only one that might need rebuild.
Currently this is only a single package 'amarok', so I can cooperate
with its maintainer if rebuild would be needed.

The changes between the server embedded library between MariaDB 10.4
and 10.5 shouldn't be significant, other than added functionality.
I have to check the ABI compatibility to be sure. If the functionality
would be only extended, the dependent package might not need rebuild
at all; though it still would get one during some mass rebuild.

I added my above reply to the Self Contained Change.

--

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: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Arthur G]

"the system administrator will need to install and configure
sssd to replace it after the update. Even when this is not done, the
only visible affect will be slower resolution of named service queries
due to a missing cache."

I use nscd on a few application servers that point to unreliable DNS
servers that we have no control over (thanks to our Microsofties) and find
caching only the positive responses smooths things out very well.

>From the day ncsd was created it has always been easy to set up and always
had funny execution quirks. My nscd implementation occasionally bloats to
600Mb of memory usage just on host caching but fortunately nscd has an auto
restart feature which I've set to run daily to cure this.

Definitely happy to throw nscd out for something better that was just as
simple and easy to set up. Unfortunately sssd is quite sophisticated and
therefore complex, and does caching secondary from its main purpose which
seems overkill if that was the only reason for running it. I'll leave
systemd-resolved for the trail blazers.

I'd still like to see nscd continue to be available but wholeheartedly
agree it's showing its age.



On Thu, 5 Nov 2020 at 22:49, Florian Weimer  wrote:

> * Petr Menšík:
>
> > nscd has no important active bugs in Fedora. I am not sure what bugs are
> > mentioned, but just a few active bugs are on glibc component in Fedora.
> > Therefore it seems just fine no commits are good.
> >
> > Just unlike systemd-resolved, which actively breaks some use cases. It
> > changes resolution order of search directive in resolv.conf, breaks
> > DNSSEC, breaks one label names resolution. It is famous among DNS
> > community [1].
> >
> > There is no controversy with nscd, it just caches names and nothing
> > more. I think this is its advantage. Unless there is any stronger
> > reason, I am against this change in advance.
> >
> > If serious bugs are in NSCD, please fill bugs on the component.
>
> nscd has more usage downstream, leading to bugs such as:
>
>   
>
> Most of them are private, but you should be able to view them.
>
> > Instead, I request again, split systemd-resolved into subpackage. I want
> > it removed on my system and so do more people. Also, when I disable it,
> > I have to fix /etc/resolv.conf by hand. I would think NetworkManager
> > restart would refresh classic /etc/resolv.conf, like in F32.
>
> This proposal is about nscd, not systemd-resolved.
>
> If Fedora chooses to adopt another local DNS cache, glibc will use that
> (probably using the built-in nss_dns service module) systemd-resolved is
> just what we have for now, so the proposal references it.  But any other
> DNS cache will work as well.
>
> The hosts cache in nscd is arguably the weakest part of it, so
> deprecating really shouldn't be controversial at all.
>
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Petr Pisar]

On Thu, Nov 05, 2020 at 12:56:17PM +0100, Kevin Kofler via devel wrote:
> Petr Pisar wrote:
> > That's because cmake executes make (if CMakeList does not override it).
> 
> CMake actually just generates the makefiles, you still run make directly (as 
> with autotools).
> 
That's not true anymore. CMake needs make available when generating the
Makefiles. The inical cmake invocation fails. See
.

-- Petr


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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Panu Matilainen]

On 11/5/20 2:09 PM, Miro Hrončok wrote:

On 11/5/20 12:59 PM, Kevin Kofler via devel wrote:
This change will remove make from the default buildroot in Koji and 
mock.
What is the point of removing a package that is used by almost all 
package

builds from the default buildroot? It is just a pointless backwards
incompatibility.


https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br_make.txt 



This has ~8k lines. Fedora has ~22k source packages.

That is a lot (36%), but definitively not "almost all".

For comparison, ~6.5k packages now BR gcc/gcc-c++. So the scope is quite 
similar.




+1

Make *was* used by almost all package builds, back in the day. The world 
has moved on, so should we...


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

Heads up: poetry 1.1.x and poetry.core coming to rawhide

[Miro Hrončok]

Hello Pythonistas,

this is a heads up that we plan to upgrade poetry to 1.1.x in rawhide soon:
  https://src.fedoraproject.org/rpms/poetry/pull-request/5

It is blocked on python-lark-parser:
  https://src.fedoraproject.org/rpms/python-lark-parser/pull-request/5

With this update, poetry was split into poetry.core and poetry. After trying to 
keep the project in a single component, I've decided to package them separately.


I've tested all impacted packages in Fedora and there is no breakage.

https://src.fedoraproject.org/rpms/poetry/pull-request/5#comment-60068
https://src.fedoraproject.org/rpms/poetry/pull-request/5#comment-60070


A friendly reminder: You can package poetry-based projects with 
pyproject-rpm-macros:


https://src.fedoraproject.org/rpms/pyproject-rpm-macros (see the README)


Thanks Fabio, who started the upgrade.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Florian Weimer]

* Kevin Kofler via devel:

> I would rather wonder whether we really need our default make implementation 
> to be extensible in Scheme (the guile22 package). The size of make itself is 
> negligible.

gdb-headless also needs Guile, and in most cases, once you use make, you
also end up with debuginfo indexing using GDB.

I'm talking to our debugging team, and we'll figure out what to do
there.  Most likely there is going to be a separate Fedora 34 change
proposal for the Guile dependencies.

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Fabio Valentini]

On Wed, Nov 4, 2020 at 9:46 PM Neal Gompa  wrote:

(snip)

>
> Koji/Brew disables weak dependencies. The weak dependency would be for
> developer convenience.
>
> > If the change was automated and you did not have to do anything would
> > you still be opposed to having your spec files updated with
> > BuildRequires: make
> >
>
> You still need BR: make.

Couldn't we add something like this to the cmake package?

Requires: (make or ninja)
Suggests: make

Which would make sure at least *one* of the available backends is
installed, and would make it prefer make if ninja is not specified
explicitly.

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Miro Hrončok]

On 11/5/20 12:59 PM, Kevin Kofler via devel wrote:

This change will remove make from the default buildroot in Koji and mock.

What is the point of removing a package that is used by almost all package
builds from the default buildroot? It is just a pointless backwards
incompatibility.


https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br_make.txt

This has ~8k lines. Fedora has ~22k source packages.

That is a lot (36%), but definitively not "almost all".

For comparison, ~6.5k packages now BR gcc/gcc-c++. So the scope is quite 
similar.

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

Re: Packaging rules for build from source vs BPF byte code ?

[Daniel P . Berrangé]

On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote:
> On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé  
> wrote:
> >
> > In QEMU there's a desire to make use of BPF programs for implementing
> > some networking features. The current patches are proposing adding
> > prebuilt BPF byte code to the QEMU repo, with source available, but
> > not actually building from source during a build.
> >
> > I was wondering if we had any specific guidance or rules covering the
> > shipping BPF programs in particular ?
> >
> > To me it feels like BPF programs should fall under normal Fedora
> > practice that expects everything to be built from master source.
> >
> > We do have the exception that allows firmware to be shipped as
> > pre-built blobs, but I'm thinking that BPF programs could not
> > be considered as firmware.
> >
> > Has this been discussed before, if so can someone point to the
> > results, as I'm not finding anything specific to BPF programs and
> > Fedora packaging via Google.
> 
> If there are no specialized Packaging Guidelines for something, then
> the general guidelines apply - so in this case, compiling from source
> is required, since Fedora packages MUST NOT ship precompiled binaries.

It seems this case is a little more fuzzy in terms of what is 
considered "the preferred source" format, and whether the BPF
program is in fact considered a "binary" at all.

There is the "dpdk" package in Fedora which is doing similar to
what is being proposed for QEMU.

In dpdk-stable-19.11.3/drivers/net/tap/tap_bpf_program.c there is
BPF "source code".

This was, at some point in time, apparently compiled using some
undefined process to create a binary byte code blob.

This binary blob was then processed, again by some undefined process,
to extract just the BPF instructions, which are then turned back
into "source code" as  a static byte array in a C header file. The
latter is what is actually compiled. This derived source is in the

  dpdk-stable-19.11.3/drivers/net/tap/tap_bpf_insns.h


Given that dpdk is not providing any build process for going from
tap_bpf_program.c to tap_bpf_insns.h, it looks to me like the upstream
project effectively considers  "tap_bpf_insns.h" to be their preferred
source form, and  tap_bpf_program.c as just a reference for its
original creation.

IOW, to me it looks like this embedded BPF program shouldn't be
considered a binary from Fedora POV and can be used as is.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Kevin Kofler via devel]

Ben Cotton wrote:
> This change will remove make from the default buildroot in Koji and mock.

What is the point of removing a package that is used by almost all package 
builds from the default buildroot? It is just a pointless backwards 
incompatibility.

> * Reduce the BuildRoot download size by: 7.3 MB [2]:
> ** make: 539k
> ** gc: 104k
> ** guile22: 6.6M
> ** libtool-ltdl: 36k
> * Reduce the BuildRoot install size by; 46 MB [2]:
> ** make: 1.6M
> ** gc: 229k
> ** guile22: 44M
> ** libtool-ltdl: 71k

I would rather wonder whether we really need our default make implementation 
to be extensible in Scheme (the guile22 package). The size of make itself is 
negligible.

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Kevin Kofler via devel]

Petr Pisar wrote:
> That's because cmake executes make (if CMakeList does not override it).

CMake actually just generates the makefiles, you still run make directly (as 
with autotools).

The makefiles then do several complex things, possibly including running 
make with different arguments (and also calling back into CMake by running 
cmake with special arguments multiple times), to handle the progress 
reporting, but the initial make invocation comes from the specfile.

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

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

[Florian Weimer]

* Petr Menšík:

> nscd has no important active bugs in Fedora. I am not sure what bugs are
> mentioned, but just a few active bugs are on glibc component in Fedora.
> Therefore it seems just fine no commits are good.
>
> Just unlike systemd-resolved, which actively breaks some use cases. It
> changes resolution order of search directive in resolv.conf, breaks
> DNSSEC, breaks one label names resolution. It is famous among DNS
> community [1].
>
> There is no controversy with nscd, it just caches names and nothing
> more. I think this is its advantage. Unless there is any stronger
> reason, I am against this change in advance.
>
> If serious bugs are in NSCD, please fill bugs on the component.

nscd has more usage downstream, leading to bugs such as:

  

Most of them are private, but you should be able to view them.

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

This proposal is about nscd, not systemd-resolved.

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

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

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