How to build CPM.cmake packages?

[Bob Hepple]

One of my packages has started to use CPM.cmake
(https://github.com/TheLartians/CPM.cmake) which is a "Setup-free
CMake dependency management" addon script for cmake.

I'm hoping someone out there has some expertise and can coach me
through this - I'm frankly bewildered by it.

My problem is that CPM.cmake requires the use of the network at build
time to download CPM.cmake itself and then to download the source of
various dependency libraries. This is forbidden in fedora by
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_network_access
- fedora builds must be done offline.

Any ideas how to overcome this?

I had thought of building it on my local machine, doing a 'make clean'
equiv and using that as a tarball including all the dependency
libraries. But that seems rather naff.


TIA


Bob
___
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: Remove Python2 RPM Macros (Self-Contained Change proposal)

[Miro Hrončok]

On 15. 01. 21 22:49, Neal Gompa wrote:

I would really rather not have this happen until we're going to retire
Python 2 entirely. The Python 2 macros are already separate from the
Python 3 ones, so we could just leave them alone until we're ready to
just remove Python 2 entirely.


My point here is that I want to keep Python 2 much longer (for developers who 
unfortunately still need to support it, e.g. for RHEL 7) than I'd like to keep 
allowing packages to buiid with it.


Similarly there are no macros for Python 3.5 or 3.7 in Fedora, but the Pythons 
are available.


I'd also like to stop worrying about compatibility of the Python RPM generators 
with Python 2 packages (it gets extremely hard to test, as the real word 
scenarios in Fedora are currently almost non-existent).



Moving the Python 2 macro files (and the python2-rpm-macros package)
from the python-rpm-macros package to the python27 package would also
simplify this eventual retirement.


That might be the way if the proposal is rejected (or reduced to generators 
only), I'll keep that in mind, thanks.


On 15. 01. 21 22:59, Igor Raits wrote:
> Fully agree here, unless we are really going to drop python2 stuff completely
> from distribution.

We are really removing the Python 2 "stuff" (except for the interpreter itself) 
from the distribution, slowly but steadily. This change does not in general 
impact packages that happen to need Python 2 to build only, it only impacts a 
dozen of "Python 2 packages".


--
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: Fedora 34 Mass Rebuild

[Miro Hrončok]

On 15. 01. 21 20:31, Mohan Boddu wrote:

Hi all,

Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild


I've noticed https://pagure.io/releng/issue/9829 is not listed here.
Could you please not start the build until make is removed?

Also, https://pagure.io/releng/issue/9910 was rejected.

--
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: [ELN] How to handle RHEL-specific changes when it fails in ELN?

[Miro Hrončok]

On 15. 01. 21 20:34, Igor Raits wrote:

Hello,

My friendly co-maintainers pushed 
https://src.fedoraproject.org/rpms/stratisd/c/32d87697075a846f9a3feb9ee66058287a91ccde?branch=master 
 
that claims that it makes spec compatible with RHEL (ignore parts that they 
violate packaging guidelines).


However, it might make it RHEL compatible but for sure not ELN compatible. 
Moreover, I am not aware of any announcements that ELN SIG wants to not have any 
rust-* packages for RHEL 9.


Side note: Don't hold a grudge against the co-maintainer, they might have been 
told that this is the way. I suppose that if changes like this have been 
promoted internally, I'd be arguing to have a conversation in Fedora instead, 
without success.


See also: 
https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master


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

[Bug 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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



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

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


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bd945e3b55   
adplug-2.3.3-1.el8 audacious-plugins-4.0.5-3.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e976495093   
coturn-4.5.2-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-47ea069c76   
chromium-87.0.4280.141-1.el8


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

R-Rcpp-1.0.6-1.el8
beakerlib-1.22-2.el8
diff-pdf-0.4.1-5.el8
python-apprise-0.9.0-2.el8
python-junit_xml-1.9-1.20210114gitba89b41.20210114gitba89b41.el8
python-typeguard-2.10.0-2.el8
shairport-sync-3.3.7-0.el8

Details about builds:



 R-Rcpp-1.0.6-1.el8 (FEDORA-EPEL-2021-4cdf8e4183)
 Seamless R and C++ Integration

Update Information:

Rcpp 1.0.6

ChangeLog:

* Fri Jan 15 2021 Mattias Ellert  - 1.0.6-1
- Update to 1.0.6




 beakerlib-1.22-2.el8 (FEDORA-EPEL-2021-4ae668911d)
 A shell-level integration testing library

Update Information:

- ability to parse fmf id references - ability the use simpler library name -
library(foo), {url: '../foo.git', name: '/'}, meaming the library is n the root
folder - ability put library even deeper in the tree -
library(foo/path/to/the/library), {url: '../foo.git', name:
'/path/to/the/library'} - rebased yash to 1.0 - and few more minor fixes

ChangeLog:

* Fri Jan 15 2021 Dalibor Pospisil  - 1.22-2
- ability to parse fmf id references
- ability the use simpler library name - library(foo), {url: '../foo.git', 
name: '/'}, meaming the library is n the root folder
- ability put library even deeper in the tree - 
library(foo/path/to/the/library), {url: '../foo.git', name: 
'/path/to/the/library'}
- rebased yash to 1.0
- and few more minor fixes




 diff-pdf-0.4.1-5.el8 (FEDORA-EPEL-2021-31444ee86b)
 A simple tool for visually comparing two PDF files

Update Information:

Do not require poppler-cairo.

ChangeLog:

* Wed Jan 13 2021 Marek Kasik  - 0.4.1-5
- Do not require poppler-cairo
- It is not needed and drags in explicit dependency on poppler base library
* Mon Jul 27 2020 Fedora Release Engineering  - 
0.4.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 python-apprise-0.9.0-2.el8 (FEDORA-EPEL-2021-7695175970)
 A simple wrapper to many popular notification services used today

Update Information:

Fixed unit tests

ChangeLog:

* Thu Jan 14 2021 Chris Caron  - 0.9.0-2
- Fixed unit tests
* Wed Dec 30 2020 Chris Caron  - 0.9.0-1
- Updated to v0.9.0




 python-junit_xml-1.9-1.20210114gitba89b41.20210114gitba89b41.el8 
(FEDORA-EPEL-2021-4ffc46e7d3)
 Python module for creating JUnit XML test result documents

Update Information:

Port version 1.9 to EPEL8 for Python 3 and Python 2

ChangeLog:


References:

  [ 1 ] Bug #1842886 - Please create python-junit_xml for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1842886




 python-typeguard-2.10.0-2.el8 (FEDORA-EPEL-2021-6c20fc57f7)
 Run-time type checker for Python

Update Information:

Fix egginfo on Fedora < 33 so the auto-generated Provides has the right version
  initial epel8 

[Bug 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-9edeaaba1a has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-9edeaaba1a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-9edeaaba1a

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


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  29  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599   
openjpeg2-2.3.1-10.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-143227c7ed   
sympa-6.2.60-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5843fdc72c   
adplug-2.3.3-1.el7 audacious-plugins-4.0.5-3.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6bfa86551f   
coturn-4.5.2-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d851c69e59   
chromium-87.0.4280.141-1.el7


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

R-Rcpp-1.0.6-1.el7
beakerlib-1.22-1.el7
diff-pdf-0.4.1-5.el7
libmodulemd2-2.12.0-1.el7
python-apprise-0.9.0-2.el7
python-junit_xml-1.7-3.el7

Details about builds:



 R-Rcpp-1.0.6-1.el7 (FEDORA-EPEL-2021-81052d9013)
 Seamless R and C++ Integration

Update Information:

Rcpp 1.0.6

ChangeLog:

* Fri Jan 15 2021 Mattias Ellert  - 1.0.6-1
- Update to 1.0.6




 beakerlib-1.22-1.el7 (FEDORA-EPEL-2021-554a4566e7)
 A shell-level integration testing library

Update Information:

- ability to parse fmf id references - ability the use simpler library name -
library(foo), {url: '../foo.git', name: '/'}, meaming the library is n the root
folder - ability put library even deeper in the tree -
library(foo/path/to/the/library), {url: '../foo.git', name:
'/path/to/the/library'} - rebased yash to 1.0 - and few more minor fixes

ChangeLog:

* Fri Jan 15 2021 Dalibor Pospisil  - 1.22-1
- ability to parse fmf id references
- ability the use simpler library name - library(foo), {url: '../foo.git', 
name: '/'}, meaming the library is n the root folder
- ability put library even deeper in the tree - 
library(foo/path/to/the/library), {url: '../foo.git', name: 
'/path/to/the/library'}
- rebased yash to 1.0
- and few more minor fixes




 diff-pdf-0.4.1-5.el7 (FEDORA-EPEL-2021-495642dd36)
 A simple tool for visually comparing two PDF files

Update Information:

Do not require poppler-cairo.

ChangeLog:

* Wed Jan 13 2021 Marek Kasik  - 0.4.1-5
- Do not require poppler-cairo
- It is not needed and drags in explicit dependency on poppler base library
* Mon Jul 27 2020 Fedora Release Engineering  - 
0.4.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 libmodulemd2-2.12.0-1.el7 (FEDORA-EPEL-2021-b11bb6da53)
 Module metadata manipulation library

Update Information:

Add support for 'buildorder' attribute to Packager formats.    Fix issue
with ModuleIndex when input contains only Obsoletes documents    Update to
libmodulemd 2.11.2  Also fixes a bug when trying to import the python2 bindings.

ChangeLog:

* Thu Jan 14 2021 Stephen Gallagher  - 2.12.0-1
- Add support for 'buildorder' to Packager documents
* Tue Jan 12 2021 Stephen Gallagher  - 2.11.2-2
- Fix issue with ModuleIndex when input contains only Obsoletes documents
* Mon Jan 11 2021 Stephen Gallagher  - 2.11.2-1.1
- Fix issue with loading python2 bindings
* Thu Jan  7 2021 Stephen Gallagher  - 2.11.2-1
- Release 2.11.2
- Extend read_packager_[file|string]() to support overriding the module name
  and stream.




 python-apprise-0.9.0-2.el7 (FEDORA-EPEL-2021-b81daf5402)
 A simple wrapper to many popular notification services used today

Update Information:

Fixed unit tests

ChangeLog:

* Thu Jan 14 2021 Chris Caron  - 0.9.0-2
- Fixed unit tests
* Wed Dec 30 2020 Chris 

[Bug 1913558] perl-Gtk2-GladeXML-1.008 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gtk2-GladeXML-1.008-1. |perl-Gtk2-GladeXML-1.008-1.
   |fc34|fc34
   |perl-Gtk2-GladeXML-1.008-1. |perl-Gtk2-GladeXML-1.008-1.
   |fc32|fc32
   ||perl-Gtk2-GladeXML-1.008-1.
   ||fc33



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


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

[Bug 1913574] perl-Gtk2-Spell-1.05 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gtk2-Spell-1.05-1.fc34 |perl-Gtk2-Spell-1.05-1.fc34
   |perl-Gtk2-Spell-1.05-1.fc32 |perl-Gtk2-Spell-1.05-1.fc32
   ||perl-Gtk2-Spell-1.05-1.fc33



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


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

[Bug 1913574] perl-Gtk2-Spell-1.05 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Gtk2-Spell-1.05-1.fc34 |perl-Gtk2-Spell-1.05-1.fc34
   ||perl-Gtk2-Spell-1.05-1.fc32
 Resolution|--- |ERRATA
Last Closed||2021-01-16 01:23:02



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


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

[Bug 1913558] perl-Gtk2-GladeXML-1.008 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Gtk2-GladeXML-1.008-1. |perl-Gtk2-GladeXML-1.008-1.
   |fc34|fc34
   ||perl-Gtk2-GladeXML-1.008-1.
   ||fc32
 Resolution|--- |ERRATA
Last Closed||2021-01-16 01:23:00



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


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

[Bug 1913160] perl-Gnome2-VFS-1.084 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gnome2-VFS-1.084-1.fc3 |perl-Gnome2-VFS-1.084-1.fc3
   |4   |4
   |perl-Gnome2-VFS-1.084-1.fc3 |perl-Gnome2-VFS-1.084-1.fc3
   |3   |3
   ||perl-Gnome2-VFS-1.084-1.fc3
   ||2



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


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

[Bug 1913143] perl-Gnome2-GConf-1.047 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gnome2-GConf-1.047-1.f |perl-Gnome2-GConf-1.047-1.f
   |c34 |c34
   |perl-Gnome2-GConf-1.047-1.f |perl-Gnome2-GConf-1.047-1.f
   |c33 |c33
   ||perl-Gnome2-GConf-1.047-1.f
   ||c32



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


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

[Bug 1913111] perl-Gnome2-1.048 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gnome2-1.048-1.fc34|perl-Gnome2-1.048-1.fc34
   |perl-Gnome2-1.048-1.fc33|perl-Gnome2-1.048-1.fc33
   ||perl-Gnome2-1.048-1.fc32



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


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

[Test-Announce] 2021-01-18 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2021-01-18
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet for a couple of weeks, and there are interesting goings-
on, so let's meet up on Monday.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 34 status (inc. GNOME 40)
3. Gating proposals/ideas
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: libdnet in Fedora

[Ravindra Kumar]

Thanks Rich and Oliver.

FWIW, open-vm-tools 11.0.0 onwards have removed libdnet dependency - 
https://kojipkgs.fedoraproject.org//packages/open-vm-tools/11.0.0/2.fc32/data/logs/x86_64/build.log.
 My bad I forgot to remove libdnet from open-vm-tools.spec when I updated to 
11.0.0. If no one else gets to it before me, I will remove it when I package 
the new open-vm-tools version 11.2.5.

Thanks,
Ravindra


From: Oliver Falk 
Sent: Thursday, January 14, 2021 5:53 AM
To: Richard W.M. Jones 
Cc: cav...@redhat.com ; Ravindra Kumar 
; libdnet-ow...@fedoraproject.org 
; devel@lists.fedoraproject.org 
; open-vm-tools-ow...@fedoraproject.org 

Subject: Re: libdnet in Fedora

Hey!
OK... Could be that it's still in the devel branch... I'll check later!

Oliver

On Thu, Jan 14, 2021 at 2:51 PM Richard W.M. Jones 
mailto:rjo...@redhat.com>> wrote:

Thanks - it all seemed to go OK.

Interestingly the libdnet SONAME did not change.

Rich.

--
Richard Jones, Virtualization Group, Red Hat 
http://people.redhat.com/~rjones
Read my programming and virtualization blog: 
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

___
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 Mass Rebuild

[Fabio Valentini]

On Fri, Jan 15, 2021 at 8:35 PM Mohan Boddu  wrote:
>
> Hi all,
>
> Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
> on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
> changes listed in:
>
> https://pagure.io/releng/issues?status=Open=mass+rebuild
>
> Mass rebuild will be done in a side tag (f34-rebuild) and moved over
> when completed.
>
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html
>
> Things still needing rebuilt
> https://kojipkgs.fedoraproject.org/mass-rebuild/f34-need-rebuild.html
>
> FTBFS bugs will be filed shortly.
>
> Please be sure to let releng know if you see any bugs in the
> reporting. You can contact releng in #fedora-releng on freenode, by
> dropping an email to our list[2] or filing an issue in pagure[3]
>
> Regards,
> Mohan Boddu.

What system will be used to run the mass rebuild script?
If it's a fedora 33 system, I suggest modifying the script to invoke
rpmdev-bumpspec with the "-D" flag for better compatibiltiy with older
RPM versions (for people who care about that sort of thing, e.g.
maintainers who merge specs back into epel branches).

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: Remove Python2 RPM Macros (Self-Contained Change proposal)

[Igor Raits]

On Fri, Jan 15, 2021 at 10:58 PM Neal Gompa  wrote:

> On Fri, Jan 15, 2021 at 3:57 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Remove_Python2_RPM_Macros
> >
> >
> > == Summary ==
> > The {{package|python2-rpm-macros}} package (containing
> > `/usr/lib/rpm/macros.d/macros.python2`) will be removed from Fedora 34
> > and newer. The python2 RPM macros will ceases to exist. Python 2
> > packages are already not allowed. Around a dozen of packages use the
> > macros in Fedora and will need to be adjusted either by expanding them
> > or by no longer using Python 2. The `python2.7dist()` and
> > `python2dist()` automatic provides/requires will no longer be
> > automatically generated.
> >
> > == Owner ==
> > * Name: [[User:Churchyard|Miro Hrončok]]
> > * Email: mhron...@redhat.com
> >
> >
> > == Detailed Description ==
> > Python 2 is upstream dead, usage in Fedora packages is forbidden,
> > except for several package with an explicit FESCo approved exception.
> > The Python Maintenance team no longer wishes to support the python2
> > RPM macros from the {{package|python2-rpm-macros}} package (located at
> > `/usr/lib/rpm/macros.d/macros.python2`) and hence decided to remove
> > the package. The following macros will be undefined:
> >
> >  %{python2_sitelib}
> >  %{python2_sitearch}
> >  %{python2_version}
> >  %{python2_version_nodots}
> >  %{python2_platform}
> >  %{py2_shbang_opts}
> >  %{py2_shbang_opts_nodash}
> >  %{py2_shebang_flags}
> >  %py2_shebang_fix
> >  %py2_build
> >  %py2_build_egg
> >  %py2_build_wheel
> >  %py2_install
> >  %py2_install_egg
> >  %py2_install_wheel
> >
> > The following macros will remain defined for the time being to not
> > break packages that are using Python 2 as build-time only dependency
> > (which is also not allowed, but happens more often):
> >
> >  %{__python2}
> >  %{python2}
> >
> > The [
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages
> > Python 2 section of Python packaging guidelines] will be removed.
> >
> > {{package|python2.7}} will no longer require
> > {{package|python2-rpm-macros}} and {{package|python3-rpm-generators}}.
> >
> > Provides/requires like this will no longer be automatically generated:
> >
> >  python2dist(...)
> >  python2.7dist(...)
> >
> > The changes will happen after the Fedora 34 mass rebuild and before
> branching.
> >
> > Packages that used to use those macros in Fedora will need to be
> > adapted to expand the macros or switch to Python 3. In January 2021,
> > we have:
> >
> > * several Python 2 trac plugins, but {{package|trac}} uses Python 3 now
> > ** only those require `python2dist(...)`
> > * several Python 2 sugar packages, but they already don't build and/or
> > install as {{package|sugar}} uses Python 3 now
> > * 13 other affected packages in Fedora (some of them co-owned by Python
> Maint):
> > ** avahi
> > ** gimp-layer-via-copy-cut
> > ** gimp-resynthesizer
> > ** chromium
> > ** NFStest
> > ** offlineimap
> > ** pygobject2
> > ** pygtk2
> > ** python-psutil
> > ** python-six
> > ** python2-cairo
> > ** python2-dns
> > ** python2-setuptools
> >
> > Note: Many other packages use the macros in a disabled `%if` section.
> > Some of the listed ones might as well (and hence are not really
> > impacted), the list is an intersection of packages that (Build)Require
> > Python 2 and are greppable for the macros.
> >
> > The removed macros and migration plan:
> >
> > === %{python2_sitelib} ===
> >
> > Affected Fedora packages:
> >
> > * avahi
> > * NFStest
> > * offlineimap
> > * python2-dns
> > * python2-setuptools
> > * python-six
> >
> > Migration plan if not possible to switch to Python 3 / retire: Use
> > `%{_prefix}/lib/python2.7/site-packages`.
> >
> > === %{python2_sitearch} ===
> >
> > Affected Fedora packages:
> >
> > * chromium
> > * offlineimap
> > * pygobject2
> > * pygtk2
> > * python2-cairo
> > * python-psutil
> >
> > Migration plan if not possible to switch to Python 3 / retire: Use
> > `%{_libdir}/python2.7/site-packages`.
> >
> > === %{python2_version} ===
> >
> > Affected Fedora packages:
> >
> > * offlineimap
> > * pygtk2
> > * python2-setuptools
> >
> > Migration plan if not possible to switch to Python 3 / retire: Use `2.7`.
> >
> > === %{python2_version_nodots} ===
> >
> > No affected Fedora packages.
> >
> > Migration plan: Use `27`.
> >
> > === %{python2_platform} ===
> >
> > No affected Fedora packages.
> >
> > Migration plan: Use a glob like `linux-*`.
> >
> > === %{py2_shbang_opts}, %{py2_shbang_opts_nodash},
> > %{py2_shebang_flags}, %py2_shebang_fix ===
> >
> > Affected Fedora packages:
> >
> > * gimp-layer-via-copy-cut
> > * gimp-resynthesizer
> > * offlineimap
> >
> > All use `pathfix.py -pni "%{__python2} %{py2_shbang_opts}" ...`
> >
> > Migration plan: `pathfix.py -pni "%{_bindir}/python2" -kas ...`
> >
> > === %py2_build, %py2_install ===
> >
> > Affected Fedora packages:
> >
> > * NFStest
> > * offlineimap
> > * python2-cairo
> 

Re: Fedora 34 Change: Remove Python2 RPM Macros (Self-Contained Change proposal)

[Neal Gompa]

On Fri, Jan 15, 2021 at 3:57 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Remove_Python2_RPM_Macros
>
>
> == Summary ==
> The {{package|python2-rpm-macros}} package (containing
> `/usr/lib/rpm/macros.d/macros.python2`) will be removed from Fedora 34
> and newer. The python2 RPM macros will ceases to exist. Python 2
> packages are already not allowed. Around a dozen of packages use the
> macros in Fedora and will need to be adjusted either by expanding them
> or by no longer using Python 2. The `python2.7dist()` and
> `python2dist()` automatic provides/requires will no longer be
> automatically generated.
>
> == Owner ==
> * Name: [[User:Churchyard|Miro Hrončok]]
> * Email: mhron...@redhat.com
>
>
> == Detailed Description ==
> Python 2 is upstream dead, usage in Fedora packages is forbidden,
> except for several package with an explicit FESCo approved exception.
> The Python Maintenance team no longer wishes to support the python2
> RPM macros from the {{package|python2-rpm-macros}} package (located at
> `/usr/lib/rpm/macros.d/macros.python2`) and hence decided to remove
> the package. The following macros will be undefined:
>
>  %{python2_sitelib}
>  %{python2_sitearch}
>  %{python2_version}
>  %{python2_version_nodots}
>  %{python2_platform}
>  %{py2_shbang_opts}
>  %{py2_shbang_opts_nodash}
>  %{py2_shebang_flags}
>  %py2_shebang_fix
>  %py2_build
>  %py2_build_egg
>  %py2_build_wheel
>  %py2_install
>  %py2_install_egg
>  %py2_install_wheel
>
> The following macros will remain defined for the time being to not
> break packages that are using Python 2 as build-time only dependency
> (which is also not allowed, but happens more often):
>
>  %{__python2}
>  %{python2}
>
> The 
> [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages
> Python 2 section of Python packaging guidelines] will be removed.
>
> {{package|python2.7}} will no longer require
> {{package|python2-rpm-macros}} and {{package|python3-rpm-generators}}.
>
> Provides/requires like this will no longer be automatically generated:
>
>  python2dist(...)
>  python2.7dist(...)
>
> The changes will happen after the Fedora 34 mass rebuild and before branching.
>
> Packages that used to use those macros in Fedora will need to be
> adapted to expand the macros or switch to Python 3. In January 2021,
> we have:
>
> * several Python 2 trac plugins, but {{package|trac}} uses Python 3 now
> ** only those require `python2dist(...)`
> * several Python 2 sugar packages, but they already don't build and/or
> install as {{package|sugar}} uses Python 3 now
> * 13 other affected packages in Fedora (some of them co-owned by Python 
> Maint):
> ** avahi
> ** gimp-layer-via-copy-cut
> ** gimp-resynthesizer
> ** chromium
> ** NFStest
> ** offlineimap
> ** pygobject2
> ** pygtk2
> ** python-psutil
> ** python-six
> ** python2-cairo
> ** python2-dns
> ** python2-setuptools
>
> Note: Many other packages use the macros in a disabled `%if` section.
> Some of the listed ones might as well (and hence are not really
> impacted), the list is an intersection of packages that (Build)Require
> Python 2 and are greppable for the macros.
>
> The removed macros and migration plan:
>
> === %{python2_sitelib} ===
>
> Affected Fedora packages:
>
> * avahi
> * NFStest
> * offlineimap
> * python2-dns
> * python2-setuptools
> * python-six
>
> Migration plan if not possible to switch to Python 3 / retire: Use
> `%{_prefix}/lib/python2.7/site-packages`.
>
> === %{python2_sitearch} ===
>
> Affected Fedora packages:
>
> * chromium
> * offlineimap
> * pygobject2
> * pygtk2
> * python2-cairo
> * python-psutil
>
> Migration plan if not possible to switch to Python 3 / retire: Use
> `%{_libdir}/python2.7/site-packages`.
>
> === %{python2_version} ===
>
> Affected Fedora packages:
>
> * offlineimap
> * pygtk2
> * python2-setuptools
>
> Migration plan if not possible to switch to Python 3 / retire: Use `2.7`.
>
> === %{python2_version_nodots} ===
>
> No affected Fedora packages.
>
> Migration plan: Use `27`.
>
> === %{python2_platform} ===
>
> No affected Fedora packages.
>
> Migration plan: Use a glob like `linux-*`.
>
> === %{py2_shbang_opts}, %{py2_shbang_opts_nodash},
> %{py2_shebang_flags}, %py2_shebang_fix ===
>
> Affected Fedora packages:
>
> * gimp-layer-via-copy-cut
> * gimp-resynthesizer
> * offlineimap
>
> All use `pathfix.py -pni "%{__python2} %{py2_shbang_opts}" ...`
>
> Migration plan: `pathfix.py -pni "%{_bindir}/python2" -kas ...`
>
> === %py2_build, %py2_install ===
>
> Affected Fedora packages:
>
> * NFStest
> * offlineimap
> * python2-cairo
> * python2-dns
> * python2-setuptools
> * python-psutil
> * python-six
>
> Migration plan:
>
>  %build
>  %set_build_flags
>  python2 setup.py build
>
>  %install
>  python2 setup.py install --skip-build --root %{buildroot}
>
> Note: Add additional `sleep 1` after/before the build if you also
> build for Python 3.
>
> === %py2_build_egg, %py2_build_wheel, %py2_install_egg, 

[389-devel] please review: PR 4549 - dsconf add validation checks for root DN access control settings

[Mark Reynolds]

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

--

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

Fedora 34 Change: Make selinux-policy up-to-date with the latest kernel (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Make_selinux_policy_uptodate_with_current_kernel


== Summary ==
Add new permissions, classes, and capabilities to the selinux policy
so that system recognizes them, can boot without an error message, and
use them in the actual policy for confined services.

== Owner ==
* Name: Zdenek Pytela
* Email: zpyt...@redhat.com
* Name: Ondrej Mosnacek
* Email: omosn...@redhat.com


== Detailed Description ==
Several new permissions, classes, and capabilities have been added to
Linux kernel recently. The current SELinux policy does not reflect all
the changes which means it does not make use of all the potential the
kernel provides.

The new features include:
* New classes: lockdown perf_event
* New permissions: watch watch_mount watch_reads watch_sb watch_with_perm
* New capabilities: bpf checkpoint_restore perfmon

With these new features, selinux-policy will be aligned with the current kernel.


== Benefit to Fedora ==
Adding support for the new features to selinux-policy brings better
granularity for granting permissions and have subsequent security
benefits.

Additionally, systems can be run with the mls selinux policy: this is
currently not possible as using mls policy may prevent a system from
starting when there are permissions unknown to the policy which is
true in the new kernels.

It will also allow for complex selinux testsuites run instead of
skipping parts of the tests, utilising not supported features.

List of the new features and bugzilla links:
* [https://bugzilla.redhat.com/show_bug.cgi?id=1901957 perf_event class ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915034 watch permissions ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915184 lockdown class ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915264 bpf, perfmon,
checkpoint_restore capabilities ]

== Scope ==
* Proposal owners:
** Add all relevant patches to the current development fedora version
** Ensure the system boots with the targeted policy
** Ensure the system boots with the mls policy
** Ensure the permissions are recognized by the system

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
* Boot a system and check for error messages and audit records.
** ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot
** dmesg
** journalctl
* Optionally, install and boot the selinux-policy-mls package.


== User Experience ==
There's no visible change for end users.

Admins and custom policy authors may need to get familiar with the new
features for services which make use of them.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)


== Documentation ==
N/A (not a System Wide Change)



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

Fedora 35 Change: Retire python3.5 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RetirePython3.5


== Summary ==
The {{package|python3.5}} package will be retired without replacement
from [[Releases/35|Fedora 35]]. Python 3.5 has been End of Life since
September 2020 and was kept around only to test software targeting
Ubuntu 16.04 “Xenial Xerus” LTS and Debian 9 “Stretch” LTS. The
removal is more or less aligned with
[https://wiki.debian.org/LTS/Stretch Debian 9 EOL] (2022-06-30) --
Fedora 34 EOLs on 2022-05-17. Ubuntu 16.04 LTS EOLs sooner, in April
2021.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
The {{package|python3.5}} package with the Python interpreter in
version 3.5 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
Ubuntu 16.04 “Xenial Xerus” LTS and Debian 9 “Stretch” LTS.

[https://wiki.ubuntu.com/Releases Ubuntu 16.04 “Xenial Xerus” LTS
standard support ends in April 2021].
[https://wiki.debian.org/LTS/Stretch Debian 9 “Stretch” LTS is End of
Life in 2022-06]. This very roughly corresponds with the
[https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
Fedora 34 EOL]. Hence, we decided to retire (completely remove)
{{package|python3.5}} from Fedora 35, before it gets released. Users
who target Debian 9 can use Fedora 34 until it EOLs.

== Feedback ==
This was announced on the Python list prior to submitting the change
proposal: 
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/ITX7QFF6CLBOOAPE4RA52QTGPMEL5QII/

There was no pushback.

== Benefit to Fedora ==
The maintenance of Python 3.5 was getting harder and harder every
year. The support for Python 3.5 has disappeared from pip and
setuptools, and an older version of pip/setuptools has to be bundled
in {{package|python3.5}}, while pip and setuptools bundle even more
old libraries. Support from tox and virtualenv will eventually
disappear as well.

There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.

Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (33 and 34). If you wish to continue maintaining Python 3.5 in
Fedora, please [[SIGs/Python|speak to us]] first.

== Scope ==
* Proposal owners: Retire {{package|python3.5}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
No more Python 3.5 to test user software on.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? product

== Documentation ==
N/A (not a System Wide Change)




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

Fedora 34 Change: Make selinux-policy up-to-date with the latest kernel (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Make_selinux_policy_uptodate_with_current_kernel


== Summary ==
Add new permissions, classes, and capabilities to the selinux policy
so that system recognizes them, can boot without an error message, and
use them in the actual policy for confined services.

== Owner ==
* Name: Zdenek Pytela
* Email: zpyt...@redhat.com
* Name: Ondrej Mosnacek
* Email: omosn...@redhat.com


== Detailed Description ==
Several new permissions, classes, and capabilities have been added to
Linux kernel recently. The current SELinux policy does not reflect all
the changes which means it does not make use of all the potential the
kernel provides.

The new features include:
* New classes: lockdown perf_event
* New permissions: watch watch_mount watch_reads watch_sb watch_with_perm
* New capabilities: bpf checkpoint_restore perfmon

With these new features, selinux-policy will be aligned with the current kernel.


== Benefit to Fedora ==
Adding support for the new features to selinux-policy brings better
granularity for granting permissions and have subsequent security
benefits.

Additionally, systems can be run with the mls selinux policy: this is
currently not possible as using mls policy may prevent a system from
starting when there are permissions unknown to the policy which is
true in the new kernels.

It will also allow for complex selinux testsuites run instead of
skipping parts of the tests, utilising not supported features.

List of the new features and bugzilla links:
* [https://bugzilla.redhat.com/show_bug.cgi?id=1901957 perf_event class ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915034 watch permissions ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915184 lockdown class ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915264 bpf, perfmon,
checkpoint_restore capabilities ]

== Scope ==
* Proposal owners:
** Add all relevant patches to the current development fedora version
** Ensure the system boots with the targeted policy
** Ensure the system boots with the mls policy
** Ensure the permissions are recognized by the system

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
* Boot a system and check for error messages and audit records.
** ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot
** dmesg
** journalctl
* Optionally, install and boot the selinux-policy-mls package.


== User Experience ==
There's no visible change for end users.

Admins and custom policy authors may need to get familiar with the new
features for services which make use of them.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)


== Documentation ==
N/A (not a System Wide Change)



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

Fedora 35 Change: Retire python3.5 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RetirePython3.5


== Summary ==
The {{package|python3.5}} package will be retired without replacement
from [[Releases/35|Fedora 35]]. Python 3.5 has been End of Life since
September 2020 and was kept around only to test software targeting
Ubuntu 16.04 “Xenial Xerus” LTS and Debian 9 “Stretch” LTS. The
removal is more or less aligned with
[https://wiki.debian.org/LTS/Stretch Debian 9 EOL] (2022-06-30) --
Fedora 34 EOLs on 2022-05-17. Ubuntu 16.04 LTS EOLs sooner, in April
2021.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
The {{package|python3.5}} package with the Python interpreter in
version 3.5 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
Ubuntu 16.04 “Xenial Xerus” LTS and Debian 9 “Stretch” LTS.

[https://wiki.ubuntu.com/Releases Ubuntu 16.04 “Xenial Xerus” LTS
standard support ends in April 2021].
[https://wiki.debian.org/LTS/Stretch Debian 9 “Stretch” LTS is End of
Life in 2022-06]. This very roughly corresponds with the
[https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
Fedora 34 EOL]. Hence, we decided to retire (completely remove)
{{package|python3.5}} from Fedora 35, before it gets released. Users
who target Debian 9 can use Fedora 34 until it EOLs.

== Feedback ==
This was announced on the Python list prior to submitting the change
proposal: 
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/ITX7QFF6CLBOOAPE4RA52QTGPMEL5QII/

There was no pushback.

== Benefit to Fedora ==
The maintenance of Python 3.5 was getting harder and harder every
year. The support for Python 3.5 has disappeared from pip and
setuptools, and an older version of pip/setuptools has to be bundled
in {{package|python3.5}}, while pip and setuptools bundle even more
old libraries. Support from tox and virtualenv will eventually
disappear as well.

There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.

Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (33 and 34). If you wish to continue maintaining Python 3.5 in
Fedora, please [[SIGs/Python|speak to us]] first.

== Scope ==
* Proposal owners: Retire {{package|python3.5}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
No more Python 3.5 to test user software on.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? product

== Documentation ==
N/A (not a System Wide Change)




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

Fedora 34 Change: Remove Python2 RPM Macros (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Remove_Python2_RPM_Macros


== Summary ==
The {{package|python2-rpm-macros}} package (containing
`/usr/lib/rpm/macros.d/macros.python2`) will be removed from Fedora 34
and newer. The python2 RPM macros will ceases to exist. Python 2
packages are already not allowed. Around a dozen of packages use the
macros in Fedora and will need to be adjusted either by expanding them
or by no longer using Python 2. The `python2.7dist()` and
`python2dist()` automatic provides/requires will no longer be
automatically generated.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
Python 2 is upstream dead, usage in Fedora packages is forbidden,
except for several package with an explicit FESCo approved exception.
The Python Maintenance team no longer wishes to support the python2
RPM macros from the {{package|python2-rpm-macros}} package (located at
`/usr/lib/rpm/macros.d/macros.python2`) and hence decided to remove
the package. The following macros will be undefined:

 %{python2_sitelib}
 %{python2_sitearch}
 %{python2_version}
 %{python2_version_nodots}
 %{python2_platform}
 %{py2_shbang_opts}
 %{py2_shbang_opts_nodash}
 %{py2_shebang_flags}
 %py2_shebang_fix
 %py2_build
 %py2_build_egg
 %py2_build_wheel
 %py2_install
 %py2_install_egg
 %py2_install_wheel

The following macros will remain defined for the time being to not
break packages that are using Python 2 as build-time only dependency
(which is also not allowed, but happens more often):

 %{__python2}
 %{python2}

The 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages
Python 2 section of Python packaging guidelines] will be removed.

{{package|python2.7}} will no longer require
{{package|python2-rpm-macros}} and {{package|python3-rpm-generators}}.

Provides/requires like this will no longer be automatically generated:

 python2dist(...)
 python2.7dist(...)

The changes will happen after the Fedora 34 mass rebuild and before branching.

Packages that used to use those macros in Fedora will need to be
adapted to expand the macros or switch to Python 3. In January 2021,
we have:

* several Python 2 trac plugins, but {{package|trac}} uses Python 3 now
** only those require `python2dist(...)`
* several Python 2 sugar packages, but they already don't build and/or
install as {{package|sugar}} uses Python 3 now
* 13 other affected packages in Fedora (some of them co-owned by Python Maint):
** avahi
** gimp-layer-via-copy-cut
** gimp-resynthesizer
** chromium
** NFStest
** offlineimap
** pygobject2
** pygtk2
** python-psutil
** python-six
** python2-cairo
** python2-dns
** python2-setuptools

Note: Many other packages use the macros in a disabled `%if` section.
Some of the listed ones might as well (and hence are not really
impacted), the list is an intersection of packages that (Build)Require
Python 2 and are greppable for the macros.

The removed macros and migration plan:

=== %{python2_sitelib} ===

Affected Fedora packages:

* avahi
* NFStest
* offlineimap
* python2-dns
* python2-setuptools
* python-six

Migration plan if not possible to switch to Python 3 / retire: Use
`%{_prefix}/lib/python2.7/site-packages`.

=== %{python2_sitearch} ===

Affected Fedora packages:

* chromium
* offlineimap
* pygobject2
* pygtk2
* python2-cairo
* python-psutil

Migration plan if not possible to switch to Python 3 / retire: Use
`%{_libdir}/python2.7/site-packages`.

=== %{python2_version} ===

Affected Fedora packages:

* offlineimap
* pygtk2
* python2-setuptools

Migration plan if not possible to switch to Python 3 / retire: Use `2.7`.

=== %{python2_version_nodots} ===

No affected Fedora packages.

Migration plan: Use `27`.

=== %{python2_platform} ===

No affected Fedora packages.

Migration plan: Use a glob like `linux-*`.

=== %{py2_shbang_opts}, %{py2_shbang_opts_nodash},
%{py2_shebang_flags}, %py2_shebang_fix ===

Affected Fedora packages:

* gimp-layer-via-copy-cut
* gimp-resynthesizer
* offlineimap

All use `pathfix.py -pni "%{__python2} %{py2_shbang_opts}" ...`

Migration plan: `pathfix.py -pni "%{_bindir}/python2" -kas ...`

=== %py2_build, %py2_install ===

Affected Fedora packages:

* NFStest
* offlineimap
* python2-cairo
* python2-dns
* python2-setuptools
* python-psutil
* python-six

Migration plan:

 %build
 %set_build_flags
 python2 setup.py build

 %install
 python2 setup.py install --skip-build --root %{buildroot}

Note: Add additional `sleep 1` after/before the build if you also
build for Python 3.

=== %py2_build_egg, %py2_build_wheel, %py2_install_egg, %py2_install_wheel ===

No affected Fedora packages. There are no build dependencies in Fedora
to build a Python 2 wheel or install it.

Migration plan for egg: Please don't use this!

 %build
 %set_build_flags
 python2 setup.py bdist_egg

 %install
 python2 -m easy_install -m --prefix %{buildroot}%{_prefix} -Z 


== Benefit to Fedora ==
We tried to keep the macros as 

Re: libelf now depends on openssl

[Robbie Harwood]

"Colin Walters"  writes:

> On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
>> 
>> There is of course no problem to have it in Fedora, but if this is
>> something that is going to end up in RHEL one day, it would be better
>> to do the work now to make it use OpenSSL rather than scramble later.
>
> Isn't it at least part of the purpose of Fedora ELN to detect
> situations like this earlier?  A dependency on boringssl in the Fedora
> "Everything" repositories is a distinct thing from it in ELN.

Part of the problem is that boringssl isn't a separate package - it
typically gets bundled.  (This causes mysterious failures because
boringssl stomps on the openssl names.)  So there wouldn't be a
dependency to detect.

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

[Bug 1916713] perl-Sys-Virt-7.0.0 is available

[bugzilla]

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

Bug 1916768 Summary: libvirt 7.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916768

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE




-- 
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: Is there interest in Quantum computing in Fedora?

[José Abílio Matos]

On Friday, January 15, 2021 7:08:34 PM WET Matthew Miller wrote:
> As I understand it, IBM's state of the art beats that by one already!

I knew that the number was higher than 64, but then I would ruin the joke. :-)

At the same time if we do not measure it the number could be 64. :-D
This is more a despair laugh in case you wondering. :-)

I have been looking lately at things like Quantum Decision Theory where we use 
the quantum formalism to describe human cognitive processes. So it is more 
than just the quantum computing that is interesting.

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

Re: libelf now depends on openssl

[Simo Sorce]

On Fri, 2021-01-15 at 14:22 -0500, Colin Walters wrote:
> 
> On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
> > There is of course no problem to have it in Fedora, but if this is
> > something that is going to end up in RHEL one day, it would be better
> > to do the work now to make it use OpenSSL rather than scramble later.
> 
> Isn't it at least part of the purpose of Fedora ELN to detect situations like 
> this earlier?  A dependency on boringssl in the Fedora "Everything" 
> repositories is a distinct thing from it in ELN.  If there was a change that 
> brought it into ELN, AFAIK the ELN builds wouldn't fail, presumably we'd want 
> to treat it as an important bug and possibly drive reverting the change in 
> "Everything" or so, right?
> 
> Similarly, we definitely would try really hard to avoid adding another crypto 
> library to Fedora CoreOS.
> 
> So I think the use of the bare term "Fedora" here isn't right.

At the moment the only impediment to add a crypto library in Fedora,
that I know of, is legal issues (like patents). The barrier is higher
in RHEL.

ELN and Fedora Core OS are still Fedora, so I leave it to the
maintainers and FESCO to decide if they want to add any rules or
restrictions to Fedora.

I would rather not see unbounded proliferation of crypto library, given
quality issues in those components are not merely bugs, they are often
serious CVE with potentially dire consequences (loss of key material or
other confidential information), but I am not signing up to be in the
Fedora Crypto police, I have enough on my hands as RHEL Crypto Police
:-D

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Is there interest in Quantum computing in Fedora?

[Leigh Griffin]

Count me in for sure. Answer to Matthew inline!

On Fri, Jan 15, 2021, 16:11 Matthew Miller  wrote:

> On Fri, Jan 15, 2021 at 12:58:28PM +, Stephen Coady wrote:
> > I've recently been experimenting with Quantum computing and learning
> > about its uses and benefits. There are currently libraries available
> > in python to experiment with this technology so I thought it would be
> > interesting to see if others in the community were working in this
> > area.
>
> I'd love to see us in this area. Is this meant to be used with IBM's
> cloud-based quantum computing offerings, or are there other hardware
> options?
>

Qiskit is aimed at multiple Quantum hardware architectures and the Open
QASM format aims to be vendor neutral.

For general community awareness, the IBM Quantum Experience is heavily
customized and linked into Qiskit (which came from IBM so no surprise) to
effectively provide IBMQ as a default hardware to run almost out of the box
on.

I also know that OpenShift has an operator which came from some R work in
this area which is pretty cool to shift workloads into Quantum.
https://github.com/husky-parul/openshift-quantum-operators

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

Fedora 34 Mass Rebuild

[Mohan Boddu]

Hi all,

Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

Mass rebuild will be done in a side tag (f34-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html

Things still needing rebuilt
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-need-rebuild.html

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on freenode, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,
Mohan Boddu.

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 34 Mass Rebuild

[Mohan Boddu]

Hi all,

Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

Mass rebuild will be done in a side tag (f34-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html

Things still needing rebuilt
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-need-rebuild.html

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on freenode, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,
Mohan Boddu.

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
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

[ELN] How to handle RHEL-specific changes when it fails in ELN?

[Igor Raits]

Hello,

My friendly co-maintainers pushed
https://src.fedoraproject.org/rpms/stratisd/c/32d87697075a846f9a3feb9ee66058287a91ccde?branch=master
that claims that it makes spec compatible with RHEL (ignore parts that they
violate packaging guidelines).

However, it might make it RHEL compatible but for sure not ELN compatible.
Moreover, I am not aware of any announcements that ELN SIG wants to not
have any rust-* packages for RHEL 9.

Any suggestions how to deal with this?

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

Re: libelf now depends on openssl

[Colin Walters]

On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
> 
> There is of course no problem to have it in Fedora, but if this is
> something that is going to end up in RHEL one day, it would be better
> to do the work now to make it use OpenSSL rather than scramble later.

Isn't it at least part of the purpose of Fedora ELN to detect situations like 
this earlier?  A dependency on boringssl in the Fedora "Everything" 
repositories is a distinct thing from it in ELN.  If there was a change that 
brought it into ELN, AFAIK the ELN builds wouldn't fail, presumably we'd want 
to treat it as an important bug and possibly drive reverting the change in 
"Everything" or so, right?

Similarly, we definitely would try really hard to avoid adding another crypto 
library to Fedora CoreOS.

So I think the use of the bare term "Fedora" here isn't right.
___
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: libelf now depends on openssl

[Simo Sorce]

On Fri, 2021-01-15 at 09:33 -0600, Michael Catanzaro wrote:
> On Fri, Jan 15, 2021 at 9:47 am, Simo Sorce  wrote:
> > Which is one of the reasons we do not admit boringssl in RHEL.
> > 
> > There is of course no problem to have it in Fedora, but if this is
> > something that is going to end up in RHEL one day, it would be better
> > to do the work now to make it use OpenSSL rather than scramble later.
> 
> It won't even wind up in Fedora since we need WebKit to remain 
> GPL-compatible. So WebRTC stays disabled until upstream finds a way to 
> get rid of boringssl. The plan is to switch from libwebrtc to GStreamer.
> 
> So not such a big deal for me right now, but might be a big deal for 
> anyone hoping to transition to openssl 3.0 anytime other than exactly 
> the same time debuginfod does.

The transition to openssl 3.0 may be a little bumpy for libraries
indeed, but there isn't much we can do about it. We'll definitely try
to minimize impact as much as possible.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Is there interest in Quantum computing in Fedora?

[Matthew Miller]

On Fri, Jan 15, 2021 at 06:41:40PM +, José Abílio Matos wrote:
> On Friday, January 15, 2021 4:10:42 PM WET Matthew Miller wrote:
> > I'd love to see us in this area.
> Matthew, I can understand your point of view. Since the platforms that we 
> support are mostly 64-bit you would like also to see Fedora support (pure) 64 
> qubits systems. ;-)

As I understand it, IBM's state of the art beats that by one already!


-- 
Matthew Miller

Fedora Project Leader
___
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: Is there interest in Quantum computing in Fedora?

[José Abílio Matos]

On Friday, January 15, 2021 12:58:28 PM WET Stephen Coady wrote:
> For the moment, I'm concentrating on getting the QISKIT [1] libraries
> packaged in Fedora. I should hopefully have some updates together for
> this very soon.

That would be nice to have.
Are there any new requirements, other naturally than the Qiskit's sub-
packages, that are not yet on Fedora?

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

Re: Is there interest in Quantum computing in Fedora?

[José Abílio Matos]

On Friday, January 15, 2021 4:10:42 PM WET Matthew Miller wrote:
> I'd love to see us in this area.

Matthew, I can understand your point of view. Since the platforms that we 
support are mostly 64-bit you would like also to see Fedora support (pure) 64 
qubits systems. ;-)

And yes, I am aware that in one case it is the word size and in the other the 
whole size. :-)
-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: turning off ELN build failure notifications

[Kevin Fenzi]

On Fri, Jan 15, 2021 at 01:15:47PM -0500, Robbie Harwood wrote:
> Kevin Fenzi  writes:
> 
> > On Thu, Jan 14, 2021 at 10:12:46PM +0100, Alexander Ploumistos wrote:
> >> Hello,
> >> 
> >> Could someone please help me figure out which rule I need to edit over
> >> at Fedora Notifications, to stop receiving messages like this one?
> >> 
> >> On Thu, Jan 14, 2021 at 9:53 PM  wrote:
> >> >
> >> > Notification time stamped 2021-01-14 20:53:32 UTC
> >> >
> >> > bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-25.eln108 
> >> > failed to build
> >> > http://koji.fedoraproject.org/koji/buildinfo?buildID=1659686
> >> >
> >> > --
> >> > You received this message due to your preference settings at
> >> > https://apps.fedoraproject.org/notifications/alexpl.id.fedoraproject.org/email/31305
> >> 
> >> I thought it should be one of the Jenkins or the CI rules, but from
> >> their description I don't understand how they could apply to this type
> >> of event. Ideally, I'd like to never see anything about ELN builds
> >> failing in my inbox.
> >
> > Go there and look for a rule called:
> >
> > "Koji builds for packages I own"
> >
> > click on it
> >
> > On the side in 'generic rules' look for 'a particular user' 
> >
> > click on it. 
> >
> > Enter: 
> >
> > bpeck
> >
> > click add 
> >
> > it should now appear on the left in the rule. 
> >
> > click on 'negate'
> >
> > I think that will do it. 
> 
> Won't this remove all koji notifications, not just the ELN ones?

Nope. 

The entire rule then should be: 

* Builds changing state (any state)
AND
* A particular users package (your user)
AND
NOT * A particular users messages (bpeck)

So, if you do a build, it matches the first one, and the second one, and
the last one so it matches and you get it. 

If bpeck does a eln build, it matches the first one, the second one, but
not the last one (since it's negated) so you don't get it. 

At least I think it will work. ;) 

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

First round of nodejs libraries retiring

[Troy Dawson]

The following "applications" source rpm's start with nodejs, and have
a binary in /usr/bin/  They have either had their dependencies
bundled, or did not have any nodejs library dependencies.
nodejs-buble nodejs-linefix nodejs-nodemon
nodejs-replace-require-self nodejs-shelljs nodejs-supervisor
nodejs-svgo nodejs-tape

With the above "application" packages bundled, I have moved onto
discovering what nodejs libraries can safely be removed.
I have used the following steps, on a rawhide machine, to find my list.

  dnf repoquery --qf="%{source_name}" -a | grep ^nodejs- | sort -u -o
nodejs.sources
  vi nodejs.sources  # remove the "application" packages from Comment
#1, and nodejs-packaging
  ./find_unblocked_orphans.py --release rawhide --skip-orphans $(cat
nodejs.sources)

From the above steps, there are only 6 packages that are still
depended upon, and 210 that can be removed if we remove them all at
the same time.
I am planning on removing the 210 packages before the F34 mass
rebuild.  Hopefully by end of day Monday, January 18.
During the F34 mass rebuild I will keep watch to see if any packages
are failing builds due to missing nodejs libraries.  I will work with
any of these failed builds to get a proper solution following the
change request guidelines.

Note: There are currently only 216 nodejs library packages.  There
were 740 two months ago, and 1300 a year ago.  These have all gone
away due to being orphaned and/or being uninstallable.

Packages still needed due to dependencies (6):
nodejs-acorn-object-spread
nodejs-backbone nodejs-colors nodejs-generic-pool
nodejs-typescript nodejs-underscore

Packages that can be removed, if done all at once (210):
nodejs-acorn-dynamic-import
nodejs-amdefine nodejs-ansicolors nodejs-any-promise
nodejs-append-transform nodejs-array-buffer-from-string
nodejs-array-index nodejs-asap nodejs-ascli nodejs-base32-encode
nodejs-better-assert nodejs-better-than-before nodejs-bignumber-js
nodejs-boom nodejs-bson nodejs-buf-compare nodejs-buffer-equal
nodejs-builtin-modules nodejs-builtins nodejs-bundle-dependencies
nodejs-bunker nodejs-burrito nodejs-caching-transform
nodejs-caller-callsite nodejs-caller-path nodejs-callsites
nodejs-camelcase-keys nodejs-charm nodejs-ci-info nodejs-cli
nodejs-cli-color nodejs-cli-table nodejs-codemirror
nodejs-code-point-at nodejs-combined-stream nodejs-commander
nodejs-connect-livereload nodejs-consolemd nodejs-cookies
nodejs-cryptiles nodejs-csv nodejs-currently-unhandled
nodejs-cycle nodejs-d nodejs-debug nodejs-decamelize
nodejs-decamelize-keys nodejs-deeper
nodejs-default-require-extensions nodejs-delayed-stream
nodejs-detect-indent nodejs-discord-js nodejs-dot-prop
nodejs-duration nodejs-each nodejs-emojione nodejs-es5-ext
nodejs-es6-iterator nodejs-es6-weak-map nodejs-escape-html
nodejs-escape-regexp-component nodejs-escape-string-regexp
nodejs-espurify nodejs-event-emitter nodejs-fancy-log nodejs-fmix
nodejs-forever-agent nodejs-formatio nodejs-form-data
nodejs-glob-base nodejs-glob-parent nodejs-glogg
nodejs-gonzales-pe nodejs-graceful-readlink nodejs-growl
nodejs-grunt-contrib-nodeunit nodejs-grunt-sed nodejs-gulplog
nodejs-has-ansi nodejs-has-binary2 nodejs-has-flag nodejs-has-glob
nodejs-has-gulplog nodejs-hashish nodejs-hawk
nodejs-hex-to-array-buffer nodejs-hoek nodejs-homedir-polyfill
nodejs-imurmurhash nodejs-indent-string nodejs-indexof
nodejs-ipaddr-dot-js nodejs-irc-colors nodejs-irc-formatting
nodejs-irc-upd nodejs-isarray nodejs-is-builtin-module
nodejs-is-finite nodejs-is-fullwidth-code-point
nodejs-is-observable nodejs-isodate nodejs-is-plain-obj
nodejs-is-promise nodejs-is-text-path nodejs-is-valid-instance
nodejs-js-base64 nodejs-jschardet nodejs-json3 nodejs-jsonify
nodejs-jsonselect nodejs-lcid nodejs-levn nodejs-lolex
nodejs-loud-rejection nodejs-lru-cache nodejs-lru-queue
nodejs-magic-string nodejs-makeerror nodejs-md5-hex
nodejs-memoizee nodejs-minipass nodejs-mkdirp nodejs-mongodb
nodejs-mongodb-core nodejs-murmur-32 nodejs-mustache nodejs-mysql
nodejs-mz nodejs-negative-zero nodejs-npm-run-path
nodejs-nth-check nodejs-observable-to-promise nodejs-once
nodejs-open nodejs-optionator nodejs-option-chain nodejs-options
nodejs-os-homedir nodejs-os-locale nodejs-own-or-env
nodejs-package-license nodejs-parse-glob nodejs-path-is-absolute
nodejs-path-parse nodejs-pkginfo nodejs-platform nodejs-plur
nodejs-pretty-ms nodejs-prism-media nodejs-pruddy-error
nodejs-rainbowsocks nodejs-random-path nodejs-readdir-enhanced
nodejs-require-all nodejs-resolve-cwd nodejs-resolve-from
nodejs-resolve-pkg nodejs-rhea nodejs-runforcover nodejs-samsam
nodejs-shebang-command nodejs-simple-fmt nodejs-simple-is
nodejs-slide nodejs-snapdragon-capture-set nodejs-snapdragon-node
nodejs-snapdragon-util 

Re: turning off ELN build failure notifications

[Robbie Harwood]

Kevin Fenzi  writes:

> On Thu, Jan 14, 2021 at 10:12:46PM +0100, Alexander Ploumistos wrote:
>> Hello,
>> 
>> Could someone please help me figure out which rule I need to edit over
>> at Fedora Notifications, to stop receiving messages like this one?
>> 
>> On Thu, Jan 14, 2021 at 9:53 PM  wrote:
>> >
>> > Notification time stamped 2021-01-14 20:53:32 UTC
>> >
>> > bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-25.eln108 
>> > failed to build
>> > http://koji.fedoraproject.org/koji/buildinfo?buildID=1659686
>> >
>> > --
>> > You received this message due to your preference settings at
>> > https://apps.fedoraproject.org/notifications/alexpl.id.fedoraproject.org/email/31305
>> 
>> I thought it should be one of the Jenkins or the CI rules, but from
>> their description I don't understand how they could apply to this type
>> of event. Ideally, I'd like to never see anything about ELN builds
>> failing in my inbox.
>
> Go there and look for a rule called:
>
> "Koji builds for packages I own"
>
> click on it
>
> On the side in 'generic rules' look for 'a particular user' 
>
> click on it. 
>
> Enter: 
>
> bpeck
>
> click add 
>
> it should now appear on the left in the rule. 
>
> click on 'negate'
>
> I think that will do it. 

Won't this remove all koji notifications, not just the ELN ones?

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: [ELN] "eln-sig" group is missing from dist-git

[Kevin Fenzi]

On Fri, Jan 15, 2021 at 10:13:53AM +0100, Igor Raits wrote:
> I have a package where ELN SIG is supposed to be a co-maintainer because
> there is something specific to their needs but there is no such group on
> dist-git "@eln-sig".
> 
> Can somebody add it there?

It's not that simple. The eln sign needs to request the group in an
infra ticket (because we need to know how they want it setup) and then
it needs a mailing list, etc... 

ELN sig folks? Or is there some other way you want to handle these
cases?

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: turning off ELN build failure notifications

[Kevin Fenzi]

On Thu, Jan 14, 2021 at 10:12:46PM +0100, Alexander Ploumistos wrote:
> Hello,
> 
> Could someone please help me figure out which rule I need to edit over
> at Fedora Notifications, to stop receiving messages like this one?
> 
> On Thu, Jan 14, 2021 at 9:53 PM  wrote:
> >
> > Notification time stamped 2021-01-14 20:53:32 UTC
> >
> > bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-25.eln108 
> > failed to build
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=1659686
> >
> > --
> > You received this message due to your preference settings at
> > https://apps.fedoraproject.org/notifications/alexpl.id.fedoraproject.org/email/31305
> 
> I thought it should be one of the Jenkins or the CI rules, but from
> their description I don't understand how they could apply to this type
> of event. Ideally, I'd like to never see anything about ELN builds
> failing in my inbox.

Go there and look for a rule called:

"Koji builds for packages I own"

click on it

On the side in 'generic rules' look for 'a particular user' 

click on it. 

Enter: 

bpeck

click add 

it should now appear on the left in the rule. 

click on 'negate'

I think that will do it. 

I'm sorry the notifications app is so confusing. ;( 
It's been on our list to re-write for a while... 

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

CPE Weekly: 2021-01-15

[Aoife Moloney]

Hi Everyone,

New Year, same CPE weekly(ish) :)
If you would like to see this report and toggle to the section you are
most interested in, I would suggest visiting this link
https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view and use the header bar
on your left to skip to where you want to go!

## General Project Updates
We are kicking off Q1 this year with some familiar project faces,
namely Noggin, the replacement of the current FAS system and
continuing our development of CentOS Stream.
Most of our initiatives live here
https://pagure.io/cpe/initiatives-proposal and you can use the new
issue button to submit your own proposal.
Our updated initative timetable can be viewed here for 2021
https://docs.fedoraproject.org/en-US/cpe/time_tables/ so you know when
I need it in by to review it.
We also have updated our docs section on the initiative process we
follow as we cannot accept everything so please do check it out if you
want to understand our process more
https://docs.fedoraproject.org/en-US/cpe/initiatives/


### Misc
 GitLab
Being very honest, I've found myself a little bit strapped for time to
give this project its due diligence over the last few months, but
please bear with us/me and expect a more concentrated effort on this
coming into Q2 (April, May, June) of this year. I apologise for the
time a resolution is taking and I really do appreciate all of your
patience.

## Project Updates
*The below updates are pulled directly from our CPE team call we have
every week.*
### Fedora
* OSBS is building for aarm64 & x86_64 in production since December!
* All of the projects under the fedora-infra and releng namespaces on
pagure have had their default branch migrated from “master” to “main”.
* F34 mass rebuild due to start next week

### Noggin/AAA
* New sprint started focusing on testing correct access has been given
per user/account
* Last remaining apps being configured & tested with fasjson API
* Work will be tracked here https://github.com/fedora-infra/aaa-tracker/issues/4
* Our open issues board can be found here
https://github.com/orgs/fedora-infra/projects/6


### Fedora Messaging Schemas
* We are working through supybot and greenwave applications currently
* There is a list of applications that require messaging schemas can
be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit
* There is a readme which contains documentation on messaging schemas,
a cookie-cutter template to create the schema and a definition of Done
for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7


## CentOS Updates

### CentOS
* Community newsletter can be read here
https://blog.centos.org/2021/01/centos-community-newsletter-january-2020-2101/


### CentOS Stream
* Continuing to work on Stream 8 pushes and builds
* Investigating how to automate some module pushes
* Reviewing documentation that is available on Stream currently to
identify gaps and where needs improvement

## Team Info
### Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great weekend!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view

-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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 1916856] New: perl-Log-Report-1.31 is available

[bugzilla]

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

Bug ID: 1916856
   Summary: perl-Log-Report-1.31 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Report
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@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: 1.31
Current version/release in rawhide: 1.30-1.fc34
URL: http://search.cpan.org/dist/Log-Report/

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


-- 
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: Is there interest in Quantum computing in Fedora?

[Matthew Miller]

On Fri, Jan 15, 2021 at 12:58:28PM +, Stephen Coady wrote:
> I've recently been experimenting with Quantum computing and learning
> about its uses and benefits. There are currently libraries available
> in python to experiment with this technology so I thought it would be
> interesting to see if others in the community were working in this
> area.

I'd love to see us in this area. Is this meant to be used with IBM's
cloud-based quantum computing offerings, or are there other hardware
options?

-- 
Matthew Miller

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

Re: Self Introduction: Jan Zerdik

[Matthew Miller]

On Thu, Jan 14, 2021 at 09:29:24PM -0800, Michel Alexandre Salim wrote:
> > Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co-
> > maintainer. My experience with open source projects is mostly just as
> > a user, but I'm looking forward to joining the community.
> Welcome! I'm an occasional user of tuned and would love to see it get
> some desktop integration.

Yes, me too. I believe we already ship gamemode in Workstation, and there
are several other programs in this space. I'd like to see them all as a
unified solution.


-- 
Matthew Miller

Fedora Project Leader
___
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: Migrating the Fedora Developer Portal to Fedora Docs

[Pavel Valena]

- Original Message -
> From: "Ankur Sinha" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "For participants of the Documentation Project" 
> 
> Sent: Friday, January 15, 2021 2:03:46 PM
> Subject: Re: Migrating the Fedora Developer Portal to Fedora Docs
> 
> On Fri, Jan 15, 2021 07:37:23 -0500, Pavel Valena wrote:
> > 
> > Hello,
> 
> Hi Pavel,
> 
> Thanks for chiming in.
> 
> > I'm afraid I'm the only one left who's currently active.
> > 
> > 
> > 
> > Let me repost what I said in the issue:
> > 
> > If it's up to me (as there're no notes from the other/previous
> > maintainers), feel free to migrate the content.
> > 
> > I'd be hower sad to see the current functionality to go away, mainly:
> > 
> >   -  mentions of individual page's authors
> 
> How important is this and what function does this serve? Is the idea
> that the listed authors serve as points of contacts---they're in-charge
> of the information on the page?

Well, the main idea is that author's name is enouraging more people to help 
with updates / editing. Having a POC is nice as well, but I'm not sure whether 
this option was ever used. Nor am I sure lot of people noticed, so this is not 
a hard requirement.

> 
> I don't think this is currently a requirement of the docs, but depending
> on how important this is, we could look into whether the Antora system
> allows this. Of course, one can go to the git history of the page etc.
> to see who edited the page and so on.

You're right, git provides this, that's where we generate it from.

> 
> >   -  edit button on the page, leading to directly editing the page
> 
> The docs have this. If you click the "Edit this page" link in the top
> right corner, it takes you straight to the source of the page in the
> respective Pagure repository.
> 
> >   -  web editor
> ^
> Pagure has a web-editor too. When you click "Edit this page", you'll see
> multiple options "Fork and edit" (or "Edit in your fork" if you already
> have the fork) will take you to the web-editor on Pagure.

Well, that's all great then.

> 
> >   -  no git knowledge needed to submit changes
> 
> Could you clarify on this? One has to fork and open a PR to contribute
> to the devportal too, right?

Yes, you're right, but I think the process for github is intuitive, and the 
contributor does not work with commandline (was my main point).

Pagure needs require FAS though, right? What are the ACLs? Can anyone open a 
PR? The process seems a bit more complicated, and I'm not sure how many people 
already have github account, compared to FAS (does any of them support oauth 
from 3rd party? I'm unsure).

> 
> > Unfortunately, I don't have any spare cycles to do anything like that
> > (I don't have much for the maintenance either).
> 
> I think that's another reason to merge it with docs, which will be
> managed by the community, both infrastructure and content wise.

Agreed. Well, if it migrates well :), anyway.

IMO the UX seems a lot friendlier with Developer Portal, with several 
overviews, and it's also more granular (more sub-pages). Is there such feature 
(or a limit) in quick-docs? Also, there's no search (which limits the usability 
for me at least).

I don't want to end up with few monolithic pages noone reads. (And it's aimed 
at developers, so english is almost natural I expect.)

We could duplicate the content, however (for a while) and see how it compares, 
if you insist. Some automated translation (mirroring) would be a win-win IMO. 
Though I'm unsure it can be done.

Regards,
Pavel

> 
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
___
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: libelf now depends on openssl

[Michael Catanzaro]

On Fri, Jan 15, 2021 at 9:47 am, Simo Sorce  wrote:

Which is one of the reasons we do not admit boringssl in RHEL.

There is of course no problem to have it in Fedora, but if this is
something that is going to end up in RHEL one day, it would be better
to do the work now to make it use OpenSSL rather than scramble later.


It won't even wind up in Fedora since we need WebKit to remain 
GPL-compatible. So WebRTC stays disabled until upstream finds a way to 
get rid of boringssl. The plan is to switch from libwebrtc to GStreamer.


So not such a big deal for me right now, but might be a big deal for 
anyone hoping to transition to openssl 3.0 anytime other than exactly 
the same time debuginfod does.


Michael

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

[Bug 1916713] perl-Sys-Virt-7.0.0 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
Waiting on libvirt upgrade in Fedora (bug #1916768).
This is an enhancement release suitable for Fedora ≥ 34.


-- 
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 1916713] perl-Sys-Virt-7.0.0 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1916768





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1916768
[Bug 1916768] libvirt 7.0.0 is available
-- 
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 1916713] perl-Sys-Virt-7.0.0 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |ppi...@redhat.com
   Assignee|jples...@redhat.com |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 1916713] New: perl-Sys-Virt-7.0.0 is available

[bugzilla]

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

Bug ID: 1916713
   Summary: perl-Sys-Virt-7.0.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sys-Virt
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, crobi...@redhat.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 7.0.0
Current version/release in rawhide: 6.10.0-1.fc34
URL: http://search.cpan.org/dist/Sys-Virt/

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


-- 
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: libelf now depends on openssl

[Simo Sorce]

On Fri, 2021-01-15 at 10:25 +0100, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote:
> > > On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel
> > >  wrote:
> > > > Do the boringssl symbols not have hidden visibility in libwebrtc?
> > > > If they
> > > > do, why are they getting interposed anyway? If they don't, why
> > > > not? I assume
> > > > the library is private to libwebrtc and its symbols should not be
> > > > exported.
> > > 
> > > libwebrtc is a static lib, and so is boringssl. So all symbols,
> > > except unused symbols, will be directly included in libwebkit2gtk.
> > > In release builds, they would then be hidden by a linker script, but
> > > in developer builds everything is exported because API tests depend
> > > on internal symbols.
> > 
> > Would it be possible to get rid of boringssl? Having yet another
> > crypto library is ... bad.
> 
> Especially since it's not expected to be used outside of Google:
> 
> > BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
> > 
> > Although BoringSSL is an open source project, it is not intended for
> > general use, as OpenSSL is. We don't recommend that third parties
> > depend upon it.
> 
> 

Which is one of the reasons we do not admit boringssl in RHEL.

There is of course no problem to have it in Fedora, but if this is
something that is going to end up in RHEL one day, it would be better
to do the work now to make it use OpenSSL rather than scramble later.

HTH,
Simo.

> 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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

[Bug 1916696] perl-Log-Report-1.30 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Log-Report-1.30-1.fc34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
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 1906256] perl-Cache-FastMmap-1.56 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Cache-FastMmap-1.56-1.
   ||fc34
 Resolution|--- |RAWHIDE
Last Closed||2021-01-15 13:51:21



--- Comment #5 from Jan Pazdziora  ---
The new build was pushed to Fedora rawhide.


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

Delay in master->main changes for src.fedoraproject.org

[Kevin Fenzi]

Greetings everyone.


You all may have noticed that we planned to do do Phase 2 of our change
( https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main )
on the 13th. 

However, we have decided to delay changes to src.fedoraproject.org repos
until 2021-01-27, for the following reasons:

* We have changes pending for fedpkg and fedscmadmin to handle the
change and we would like there to be releases of both of them, in
stable updates for at least a little while so maintainers have time to
update. 

* For various reasons we haven't been able to test our scripting in stg
yet, so we would like to do that and confirm all is working, as well
as provide stg with changes for everyone else to test against if they
like.  

* We are tweaking some consmetic changes in pagure (mentioning the old
master branch in PR info, etc) and would like to get that released. 

Thanks for your understanding, 

kevin


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

Orphaned couple of jnr-* packages

[Aleksandar Kurtakov]

I have no need for the following thus orphaned them:
* jnr-enxio
* jnr-unixsocket

-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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 1916696] perl-Log-Report-1.30 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1916613





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1916613
[Bug 1916613] perl-Log-Report-Optional-1.07 is available
-- 
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 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1916696





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1916696
[Bug 1916696] perl-Log-Report-1.30 is available
-- 
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 1916696] perl-Log-Report-1.30 is available

[bugzilla]

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

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

Orphaned tomcat-taglibs-standard

[Aleksandar Kurtakov]

Due to no time nor need for it I've just orphaned tomcat-taglibs-standard
and its build requirement tomcat-taglibs-parent.

-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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 1916696] New: perl-Log-Report-1.30 is available

[bugzilla]

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

Bug ID: 1916696
   Summary: perl-Log-Report-1.30 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Report
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@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: 1.30
Current version/release in rawhide: 1.29-4.fc33
URL: http://search.cpan.org/dist/Log-Report/

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


-- 
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: Migrating the Fedora Developer Portal to Fedora Docs

[Ankur Sinha]

On Fri, Jan 15, 2021 07:37:23 -0500, Pavel Valena wrote:
> 
> Hello,

Hi Pavel,

Thanks for chiming in.

> I'm afraid I'm the only one left who's currently active.
> 
> 
> 
> Let me repost what I said in the issue:
> 
> If it's up to me (as there're no notes from the other/previous
> maintainers), feel free to migrate the content.
> 
> I'd be hower sad to see the current functionality to go away, mainly:
> 
>   -  mentions of individual page's authors

How important is this and what function does this serve? Is the idea
that the listed authors serve as points of contacts---they're in-charge
of the information on the page?

I don't think this is currently a requirement of the docs, but depending
on how important this is, we could look into whether the Antora system
allows this. Of course, one can go to the git history of the page etc.
to see who edited the page and so on.

>   -  edit button on the page, leading to directly editing the page

The docs have this. If you click the "Edit this page" link in the top
right corner, it takes you straight to the source of the page in the
respective Pagure repository.

>   -  web editor
^
Pagure has a web-editor too. When you click "Edit this page", you'll see
multiple options "Fork and edit" (or "Edit in your fork" if you already
have the fork) will take you to the web-editor on Pagure.

>   -  no git knowledge needed to submit changes

Could you clarify on this? One has to fork and open a PR to contribute
to the devportal too, right?

> Unfortunately, I don't have any spare cycles to do anything like that
> (I don't have much for the maintenance either).

I think that's another reason to merge it with docs, which will be
managed by the community, both infrastructure and content wise.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Is there interest in Quantum computing in Fedora?

[Stephen Coady]

Hi,

I've recently been experimenting with Quantum computing and learning
about its uses and benefits. There are currently libraries available
in python to experiment with this technology so I thought it would be
interesting to see if others in the community were working in this
area.

I've checked and there is no #fedora-quantum so I've created it, and
if there's enough interest maybe we can form a SIG and get some
working projects going together. I'd love to throw some ideas around
to see how we can use this technology.

For the moment, I'm concentrating on getting the QISKIT [1] libraries
packaged in Fedora. I should hopefully have some updates together for
this very soon.

Thanks, hope to see you in #fedora-quantum,
Stephen

[1] https://github.com/Qiskit/qiskit
___
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: Migrating the Fedora Developer Portal to Fedora Docs

[Pavel Valena]

- Original Message -
> From: "Kevin Fenzi" 
> To: devel@lists.fedoraproject.org, d...@lists.fedoraproject.org
> Sent: Thursday, January 14, 2021 6:44:56 PM
> Subject: Re: Migrating the Fedora Developer Portal to Fedora Docs
> 
> On Thu, Jan 14, 2021 at 08:41:04AM +, Ankur Sinha wrote:
> > On Wed, Jan 13, 2021 13:45:23 -0800, Kevin Fenzi wrote:
> > > 
> > > 
> > > I'm in favor if you can convince them to do it. ;)
> > 
> > Let's see how it goes :D
> > 
> > Incidentally: who am I convincing?

Hello,

I'm afraid I'm the only one left who's currently active.

> > 
> > The wiki page doesn't list any names[1]. Is there a SIG or a team that
> > maintains this? Would this fall under Websites (or Mindshare or CommOps
> > or Infra?) since it doesn't seem to fall under Docs.
> > 
> > [1] https://fedoraproject.org/wiki/Websites/Developer#About_The_Project
> 
> The following folks had permssions on the developer vm back when we had
> that, otherwise I am not sure:

Yes, the built went fine in the VM, but and then it all crashed...

> 
> asamalik jstribny phracek pvalena
> 
> kevin
> 

Let me repost what I said in the issue:

If it's up to me (as there're no notes from the other/previous maintainers), 
feel free to migrate the content.

I'd be hower sad to see the current functionality to go away, mainly:

  -  mentions of individual page's authors
  -  edit button on the page, leading to directly editing the page
  -  web editor
  -  no git knowledge needed to submit changes

Unfortunately, I don't have any spare cycles to do anything like that (I don't 
have much for the maintenance either).

Regards,
-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
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

help with jekyll build

[Pavel Valena]

Hello,

are there some jekyll experts?

I'm failing to build a website, which did run fine, until update to more recent 
jekyll version (3.5 -> 4.2 I think).

Here's the PR of my attempts to build it:
  https://github.com/developer-portal/website/pull/104#issuecomment-735529591

I'll be glad for any advice.

Thanks!

-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
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: protobuf 3.14 update coming to rawhide

[Florian Weimer]

* Dominik Mierzejewski:

> I've just fixed libgadu. There was a symbol clash with OpenSSL
> SHA1_Init(). libgadu cannot be distributed when linked directly with
> OpenSSL,

I can't read Polish, so I don't know the exact libgadu license terms,
but if it's the usual GPL issue, for Fedora, we have this rule:

| However, we consider that the OpenSSL library is a system library, as
| defined by the GPL, on Fedora and therefore we are allowed to ship GPL
| software that links to the OpenSSL library.



libgadu itself is LGPL, so it would be fine anyway, but Fedora's
interpretation also extends to packages that depend on libgadu, so there
really should not be an issue here that requires use of the emulation
layer (which is always fraught with problems).

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: protobuf 3.14 update coming to rawhide

[Dominik 'Rathann' Mierzejewski]

On Friday, 15 January 2021 at 10:28, Adrian Reber wrote:
> On Fri, Jan 15, 2021 at 10:15:11AM +0100, Dan Čermák wrote:
> > Adrian Reber  writes:
> > 
> > > On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote:
> > >> I prepared a protobuf update for rawhide to 3.14. It requires a rebuild
> > >> of all dependencies and of the 54 dependencies currently only 3 fail to
> > >> rebuild in COPR:
> > >> 
> > >> https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-14/packages/
> > >> 
> > >> paraview: timeout after 10 hours, should work in koji
> > >> 
> > >> community-mysql: test failure, this usually does not happen in koji
> > >> 
> > >> libgadu: actual build failures, but seems unrelated to protobuf:
> > >> 
> > >> /usr/bin/ld: sha1.o (symbol from plugin): undefined reference to symbol 
> > >> 'SHA1_Init@@OPENSSL_1_1_0'
> > >> /usr/bin/ld: /usr/lib64/libcrypto.so.1.1: error adding symbols: DSO 
> > >> missing from command line
> > >> 
> > >> 
> > >> I will start the rebuilds in rawhide in a side-tag in about a week
> > >
> > > All rebuilds are done, but I have not merged the side tag yet.
> > 
> > What's the name of the side tag?
> 
> Right, I should have mentioned that: f34-build-side-35763

I've just fixed libgadu. There was a symbol clash with OpenSSL
SHA1_Init(). libgadu cannot be distributed when linked directly with
OpenSSL, so it's built with GnuTLS. libgadu provides some compatibility
code for that case. However, libcurl is linked with OpenSSL and LTO
caught the identical symbol declarations causing the ld error. At least,
that's what I think happened. So, I renamed the conflicting symbol(s)
and it builds now. I made a new build into your tag:

$ koji latest-build f34-build-side-35763 libgadu
Build Tag   Built by
    
libgadu-1.12.2-15.fc34f34-build-side-35763  rathann

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Re: Deref plugin entries == NULL #4525

[Pierre Rogier]

As I understand things: yes.
 (I do not know if there is an explicit way to tells ldbm that a memory
block is no more needed, in which case we could do something about it ... )

On Fri, Jan 15, 2021 at 12:11 PM thierry bordaz  wrote:

>
>
> On 1/15/21 11:53 AM, Pierre Rogier wrote:
>
> Hi Thierry,
>
> I was rather thinking about the key and value duplication when querying
> the DB:
>
> When using bdb functions that is done implicitly.
>   bdb either copies the values in the DBT buffer or it alloc/realloc it
> When mimicking bdb behavior with LDBM we will have to do that explicitly
> in the LDBM plugin:
> LDMB returns a memory mapped address that may be ummapped
>once the txn is ended. So we must copy the result before closing the
> txn.
> If we have a read txn that protects the full operation lifespan, then we
> could directly use the mapped address without needing to duplicate them.
>
> ah okay ! nice.
> Just a question, if we have a txn covering a search with large candidate
> list (unindexed), does that mean that by default each db key/value will
> remain mapped until txn commit ?
>
> thanks
> thierry
>
>
> Pierre
>
> On Fri, Jan 15, 2021 at 10:53 AM thierry bordaz 
> wrote:
>
>>
>>
>> On 1/14/21 12:32 PM, Pierre Rogier wrote:
>>
>> Hi William,
>>
>> > It's a scenario we will need to fix via your BE work because of the
>> MVCC transaction model that
>> > LMDB will force us to adopt :)
>>
>> As I see things in the early phases the lmdb read txn will probably only
>> be managed at the db plugin level rather than at backend level. That
>> means that we will have the same inconsistency risk than today (i.e as if
>> using bdb and the implicit txn).
>> The txn model redesign you are speaking about should only occur in one of
>> the last phases (once bdb does no more coexists with lmdb).
>> It must be done because it could provide a serious performance boost for
>> read operations (IMHO, In most cases we could avoid to duplicate the db
>> data)
>>
>> Pierre, what duplicate are you thinking of ? str2entry ?
>>
>> But we should not do it while bdb is still around because of the risk of
>> lock issue and excessive retries.
>>
>> Note I put a phasing section in
>>
>> https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing
>> explaining that. But I guess I should move it within Ludwig's document
>> that englobs it.
>>
>>
>> Pierre
>>
>> On Thu, Jan 14, 2021 at 12:01 AM William Brown  wrote:
>>
>>>
>>>
>>> > On 13 Jan 2021, at 21:24, Pierre Rogier  wrote:
>>> >
>>> > Thank you Willian,
>>> > So far your scenario (entry found when reading base entry but no more
>>> existing when computing the candidates) is the only one that matches the
>>> symptoms.
>>>
>>> It's a scenario we will need to fix via your BE work because of the MVCC
>>> transaction model that LMDB will force us to adopt :)
>>>
>>> > And that triggered a thought:
>>> >  We cannot do anything for SUBTREE and ONE_LEVEL searches
>>> >   because the fact that the base entry id is not in the candidate may
>>> be normal
>>> >  but IMHO we should improve the BASE search case.
>>> > In this case the candidate list is directly set to the base entry id
>>> >  ==> if the candidate entry (in ldbm_back_next_search_entry) is not
>>> found and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY
>>> error ..
>>>
>>> I suspect that Mark has seen this email and submitted a PR to resolve
>>> this exact case :)
>>>
>>>
>>> >
>>> >Pierre
>>> >
>>> >
>>> > On Wed, Jan 13, 2021 at 1:45 AM William Brown  wrote:
>>> > Hey there,
>>> >
>>> > https://github.com/389ds/389-ds-base/pull/4525/files
>>> >
>>> > I had a look and I can see a few possible contributing factors, but
>>> without a core and the exact state I can't be sure if this is correct. It's
>>> all just hypothetical from reading the code.
>>> >
>>> >
>>> > The crash is in deref_do_deref_attr() which is called as part of
>>> deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by
>>> "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb,
>>> SLAPI_PLUGIN_PRE_ENTRY_FN);"
>>> >
>>> >
>>> > I think what's important here is that the search is conducted in
>>> ./ldap/servers/slapd/opshared.c:818  rc = (*be->be_search)(pb);  Is *not*
>>> in a transaction. That means that while the single search in be_search() is
>>> consistent due to an implied transaction, the subsequent search in
>>> deref_pre_entry() is likely conducted in a seperate transaction. This
>>> allows for other operations to potentially interleave and cause changes -
>>> modrdn or delete would certainly be candidates to cause a DN to be remove
>>> between these two points. It would be extremely hard to reproduce as a race
>>> condition of course.
>>> >
>>> >
>>> > A question you asked is why don't we get a "no such entry" error or
>>> similar? I think that this is because build_candidate_list in ldbm_search.c
>>> doesn't actually create an error if the base_candidates 

Re: protobuf 3.14 update coming to rawhide

[Petr Menšík]

Hi Adrian,

I would like to rebuild new BIND 9.16, once this tag is merged.
I guess building significant rebase into your tag is not welcome.

Is there any ETA, when it could be merged? Could you please send me a
mail, once it is merged? Is there any bug for the rebase I can watch?

Thanks,
Petr

On 1/15/21 10:28 AM, Adrian Reber wrote:
> On Fri, Jan 15, 2021 at 10:15:11AM +0100, Dan Čermák wrote:
>> Adrian Reber  writes:
>>
>>> On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote:
>>>
>>> All rebuilds are done, but I have not merged the side tag yet.
>>
>> What's the name of the side tag?
> 
> Right, I should have mentioned that: f34-build-side-35763
> 
>   Adrian

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



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

[389-devel] Re: Deref plugin entries == NULL #4525

[thierry bordaz]

On 1/15/21 11:53 AM, Pierre Rogier wrote:

Hi Thierry,

I was rather thinking about the key and value duplication when 
querying the DB:


When using bdb functions that is done implicitly.
  bdb either copies the values in the DBT buffer or it alloc/realloc it
When mimicking bdb behavior with LDBM we will have to do that 
explicitly in the LDBM plugin:

    LDMB returns a memory mapped address that may be ummapped
   once the txn is ended. So we must copy the result before 
closing the txn.
If we have a read txn that protects the full operation lifespan, then 
we could directly use the mapped address without needing to duplicate 
them.

ah okay ! nice.
Just a question, if we have a txn covering a search with large candidate 
list (unindexed), does that mean that by default each db key/value will 
remain mapped until txn commit ?


thanks
thierry


Pierre

On Fri, Jan 15, 2021 at 10:53 AM thierry bordaz > wrote:




On 1/14/21 12:32 PM, Pierre Rogier wrote:

Hi William,

> It's a scenario we will need to fix via your BE work because of
the MVCC transaction model that
> LMDB will force us to adopt :)
As I see things in the early phases the lmdb read txn will
probably only be managed at the db plugin level rather than at
backend level. That means that we will have the same
inconsistency risk than today (i.e as if using bdb and the
implicit txn).
The txn model redesign you are speaking about should only occur
in one of the last phases (once bdb does no more coexists with lmdb).
It must be done because it could provide a serious performance
boost for read operations (IMHO, In most cases we could avoid to
duplicate the db data)

Pierre, what duplicate are you thinking of ? str2entry ?


But we should not do it while bdb is still around because of the
risk of lock issue and excessive retries.

Note I put a phasing section in

https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing
explaining that. But I guess I should move it within Ludwig's
document that englobs it.

Pierre

On Thu, Jan 14, 2021 at 12:01 AM William Brown mailto:wbr...@suse.de>> wrote:



> On 13 Jan 2021, at 21:24, Pierre Rogier mailto:prog...@redhat.com>> wrote:
>
> Thank you Willian,
> So far your scenario (entry found when reading base entry
but no more existing when computing the candidates) is the
only one that matches the symptoms.

It's a scenario we will need to fix via your BE work because
of the MVCC transaction model that LMDB will force us to
adopt :)

> And that triggered a thought:
>  We cannot do anything for SUBTREE and ONE_LEVEL searches
>   because the fact that the base entry id is not in the
candidate may be normal
>  but IMHO we should improve the BASE search case.
> In this case the candidate list is directly set to the base
entry id
>  ==> if the candidate entry (in
ldbm_back_next_search_entry) is not found and the scope is
BASE then we should return a LDAP_NO_SUCH_ENTRY error ..

I suspect that Mark has seen this email and submitted a PR to
resolve this exact case :)


>
>        Pierre
>
>
> On Wed, Jan 13, 2021 at 1:45 AM William Brown
mailto:wbr...@suse.de>> wrote:
> Hey there,
>
> https://github.com/389ds/389-ds-base/pull/4525/files
>
> I had a look and I can see a few possible contributing
factors, but without a core and the exact state I can't be
sure if this is correct. It's all just hypothetical from
reading the code.
>
>
> The crash is in deref_do_deref_attr() which is called as
part of deref_pre_entry(). This is the
SLAPI_PLUGIN_PRE_ENTRY_FN which is called by
"./ldap/servers/slapd/result.c:1488:    rc =
plugin_call_plugins(pb, SLAPI_PLUGIN_PRE_ENTRY_FN);"
>
>
> I think what's important here is that the search is
conducted in ./ldap/servers/slapd/opshared.c:818 rc =
(*be->be_search)(pb);  Is *not* in a transaction. That means
that while the single search in be_search() is consistent due
to an implied transaction, the subsequent search in
deref_pre_entry() is likely conducted in a seperate
transaction. This allows for other operations to potentially
interleave and cause changes - modrdn or delete would
certainly be candidates to cause a DN to be remove between
these two points. It would be extremely hard to reproduce as
a race condition of course.
>
>
> A question you asked is why don't we get a "no such entry"
error or similar? I think that this is because
build_candidate_list in 

[Bug 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-9cf9da915d has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-9cf9da915d


-- 
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 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-9edeaaba1a has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-9edeaaba1a


-- 
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] Re: Deref plugin entries == NULL #4525

[Pierre Rogier]

Hi Thierry,

I was rather thinking about the key and value duplication when querying the
DB:

When using bdb functions that is done implicitly.
  bdb either copies the values in the DBT buffer or it alloc/realloc it
When mimicking bdb behavior with LDBM we will have to do that explicitly in
the LDBM plugin:
LDMB returns a memory mapped address that may be ummapped
   once the txn is ended. So we must copy the result before closing the txn.
If we have a read txn that protects the full operation lifespan, then we
could directly use the mapped address without needing to duplicate them.

Pierre

On Fri, Jan 15, 2021 at 10:53 AM thierry bordaz  wrote:

>
>
> On 1/14/21 12:32 PM, Pierre Rogier wrote:
>
> Hi William,
>
> > It's a scenario we will need to fix via your BE work because of the MVCC
> transaction model that
> > LMDB will force us to adopt :)
>
> As I see things in the early phases the lmdb read txn will probably only
> be managed at the db plugin level rather than at backend level. That
> means that we will have the same inconsistency risk than today (i.e as if
> using bdb and the implicit txn).
> The txn model redesign you are speaking about should only occur in one of
> the last phases (once bdb does no more coexists with lmdb).
> It must be done because it could provide a serious performance boost for
> read operations (IMHO, In most cases we could avoid to duplicate the db
> data)
>
> Pierre, what duplicate are you thinking of ? str2entry ?
>
> But we should not do it while bdb is still around because of the risk of
> lock issue and excessive retries.
>
> Note I put a phasing section in
>
> https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing
> explaining that. But I guess I should move it within Ludwig's document
> that englobs it.
>
>
> Pierre
>
> On Thu, Jan 14, 2021 at 12:01 AM William Brown  wrote:
>
>>
>>
>> > On 13 Jan 2021, at 21:24, Pierre Rogier  wrote:
>> >
>> > Thank you Willian,
>> > So far your scenario (entry found when reading base entry but no more
>> existing when computing the candidates) is the only one that matches the
>> symptoms.
>>
>> It's a scenario we will need to fix via your BE work because of the MVCC
>> transaction model that LMDB will force us to adopt :)
>>
>> > And that triggered a thought:
>> >  We cannot do anything for SUBTREE and ONE_LEVEL searches
>> >   because the fact that the base entry id is not in the candidate may
>> be normal
>> >  but IMHO we should improve the BASE search case.
>> > In this case the candidate list is directly set to the base entry id
>> >  ==> if the candidate entry (in ldbm_back_next_search_entry) is not
>> found and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY
>> error ..
>>
>> I suspect that Mark has seen this email and submitted a PR to resolve
>> this exact case :)
>>
>>
>> >
>> >Pierre
>> >
>> >
>> > On Wed, Jan 13, 2021 at 1:45 AM William Brown  wrote:
>> > Hey there,
>> >
>> > https://github.com/389ds/389-ds-base/pull/4525/files
>> >
>> > I had a look and I can see a few possible contributing factors, but
>> without a core and the exact state I can't be sure if this is correct. It's
>> all just hypothetical from reading the code.
>> >
>> >
>> > The crash is in deref_do_deref_attr() which is called as part of
>> deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by
>> "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb,
>> SLAPI_PLUGIN_PRE_ENTRY_FN);"
>> >
>> >
>> > I think what's important here is that the search is conducted in
>> ./ldap/servers/slapd/opshared.c:818  rc = (*be->be_search)(pb);  Is *not*
>> in a transaction. That means that while the single search in be_search() is
>> consistent due to an implied transaction, the subsequent search in
>> deref_pre_entry() is likely conducted in a seperate transaction. This
>> allows for other operations to potentially interleave and cause changes -
>> modrdn or delete would certainly be candidates to cause a DN to be remove
>> between these two points. It would be extremely hard to reproduce as a race
>> condition of course.
>> >
>> >
>> > A question you asked is why don't we get a "no such entry" error or
>> similar? I think that this is because build_candidate_list in ldbm_search.c
>> doesn't actually create an error if the base_candidates list is empty,
>> because an IDL is allocated with a value of 0 (no matching entries). this
>> allows the search to proceed, and there are no errors, and the result set
>> is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in
>> this process, but without looking further into it, my suspicion is that
>> entries of size 0 WONT return an error condition to internal_search_pb, so
>> it's valid for this to be empty.
>> >
>> > Anyway, again, this is just reading the code for 20 minutes, and is not
>> a complete in depth investigation, but maybe it's some ideas about what
>> happened?
>> >
>> > Hope it helps :)
>> >
>> >

status of 'dhcpcd' pkg builds ?

[PGNet Dev]

dhcpcd client pkgs @Fedora

https://src.fedoraproject.org/rpms/dhcpcd

are years out of date, currently versioned at

Fedora 33   dhcpcd-6.11.3-11.fc33   
Fedora 32   dhcpcd-6.11.3-10.fc32

as per comment,

https://bugzilla.redhat.com/show_bug.cgi?id=1382961#c91

latest upstream version is

9.4.0   2020-12-28 14:05

(cref: https://release-monitoring.org/project/11429/)

afaict, no response -- or recent activity -- from current maintainer.

anyone have any further info/status on this pkg, or its maintainer?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Re: Deref plugin entries == NULL #4525

[thierry bordaz]

On 1/14/21 12:32 PM, Pierre Rogier wrote:

Hi William,

> It's a scenario we will need to fix via your BE work because of the 
MVCC transaction model that

> LMDB will force us to adopt :)
As I see things in the early phases the lmdb read txn will 
probably only be managed at the db plugin level rather than at backend 
level. That means that we will have the same inconsistency risk than 
today (i.e as if using bdb and the implicit txn).
The txn model redesign you are speaking about should only occur in one 
of the last phases (once bdb does no more coexists with lmdb).
It must be done because it could provide a serious performance boost 
for read operations (IMHO, In most cases we could avoid to duplicate 
the db data)

Pierre, what duplicate are you thinking of ? str2entry ?

But we should not do it while bdb is still around because of the 
risk of lock issue and excessive retries.


Note I put a phasing section in
https://directory.fedoraproject.org/docs/389ds/design/backend-redesign-phase3.html#phasing
explaining that. But I guess I should move it within Ludwig's document 
that englobs it.


Pierre

On Thu, Jan 14, 2021 at 12:01 AM William Brown > wrote:




> On 13 Jan 2021, at 21:24, Pierre Rogier mailto:prog...@redhat.com>> wrote:
>
> Thank you Willian,
> So far your scenario (entry found when reading base entry but no
more existing when computing the candidates) is the only one that
matches the symptoms.

It's a scenario we will need to fix via your BE work because of
the MVCC transaction model that LMDB will force us to adopt :)

> And that triggered a thought:
>  We cannot do anything for SUBTREE and ONE_LEVEL searches
>   because the fact that the base entry id is not in the
candidate may be normal
>  but IMHO we should improve the BASE search case.
> In this case the candidate list is directly set to the base entry id
>  ==> if the candidate entry (in ldbm_back_next_search_entry) is
not found and the scope is BASE then we should return a
LDAP_NO_SUCH_ENTRY error ..

I suspect that Mark has seen this email and submitted a PR to
resolve this exact case :)


>
>        Pierre
>
>
> On Wed, Jan 13, 2021 at 1:45 AM William Brown mailto:wbr...@suse.de>> wrote:
> Hey there,
>
> https://github.com/389ds/389-ds-base/pull/4525/files
>
> I had a look and I can see a few possible contributing factors,
but without a core and the exact state I can't be sure if this is
correct. It's all just hypothetical from reading the code.
>
>
> The crash is in deref_do_deref_attr() which is called as part of
deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is
called by "./ldap/servers/slapd/result.c:1488:    rc =
plugin_call_plugins(pb, SLAPI_PLUGIN_PRE_ENTRY_FN);"
>
>
> I think what's important here is that the search is conducted in
./ldap/servers/slapd/opshared.c:818  rc = (*be->be_search)(pb); 
Is *not* in a transaction. That means that while the single search
in be_search() is consistent due to an implied transaction, the
subsequent search in deref_pre_entry() is likely conducted in a
seperate transaction. This allows for other operations to
potentially interleave and cause changes - modrdn or delete would
certainly be candidates to cause a DN to be remove between these
two points. It would be extremely hard to reproduce as a race
condition of course.
>
>
> A question you asked is why don't we get a "no such entry" error
or similar? I think that this is because build_candidate_list in
ldbm_search.c doesn't actually create an error if the
base_candidates list is empty, because an IDL is allocated with a
value of 0 (no matching entries). this allows the search to
proceed, and there are no errors, and the result set is set to
NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in
this process, but without looking further into it, my suspicion is
that entries of size 0 WONT return an error condition to
internal_search_pb, so it's valid for this to be empty.
>
> Anyway, again, this is just reading the code for 20 minutes, and
is not a complete in depth investigation, but maybe it's some
ideas about what happened?
>
> Hope it helps :)
>
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> ___
> 389-devel mailing list -- 389-de...@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:

[Bug 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Log-Report-Optional-1.
   ||07-1.fc34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
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 1916613] perl-Log-Report-Optional-1.07 is available

[bugzilla]

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

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

[Bug 1916613] New: perl-Log-Report-Optional-1.07 is available

[bugzilla]

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

Bug ID: 1916613
   Summary: perl-Log-Report-Optional-1.07 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Report-Optional
  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: 1.07
Current version/release in rawhide: 1.06-10.fc33
URL: http://search.cpan.org/dist/Log-Report-Optional/

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


-- 
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] Re: Deref plugin entries == NULL #4525

[thierry bordaz]

On 1/13/21 1:44 AM, William Brown wrote:

Hey there,

https://github.com/389ds/389-ds-base/pull/4525/files

I had a look and I can see a few possible contributing factors, but without a 
core and the exact state I can't be sure if this is correct. It's all just 
hypothetical from reading the code.


The crash is in deref_do_deref_attr() which is called as part of deref_pre_entry(). This 
is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by 
"./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, 
SLAPI_PLUGIN_PRE_ENTRY_FN);"


I think what's important here is that the search is conducted in 
./ldap/servers/slapd/opshared.c:818  rc = (*be->be_search)(pb);  Is *not* in a 
transaction. That means that while the single search in be_search() is consistent 
due to an implied transaction, the subsequent search in deref_pre_entry() is 
likely conducted in a seperate transaction. This allows for other operations to 
potentially interleave and cause changes - modrdn or delete would certainly be 
candidates to cause a DN to be remove between these two points. It would be 
extremely hard to reproduce as a race condition of course.


Hi William, Pierre,

Thanks for your feedback. I realize how complex it is to think to a 
possible explanation and I really appreciate.

I am still missing some parts to understand how it happened.
In the current crash there was no transaction at all "protecting" the 
initial search or nested searches. So yes we can imagine the entry got 
deleted between the base lookup and candidate list build but it is not 
related to txn.

Note that the logs do not contain direct delete of the entry.
Also during base search, the base entry is lookup. It was successful 
else it would have return a search failure. In such case the candidate 
list is not empty, it contains the base search entry ID (e->ep_id).
Finally, the candidates are evaluated against the filter 
(objectclass=*). It could be that phase that is failing if the entry was 
cleared from the entry cache and ep_id lookup failed.


regards
thierry



A question you asked is why don't we get a "no such entry" error or similar? I 
think that this is because build_candidate_list in ldbm_search.c doesn't actually create 
an error if the base_candidates list is empty, because an IDL is allocated with a value 
of 0 (no matching entries). this allows the search to proceed, and there are no errors, 
and the result set is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is 
set in this process, but without looking further into it, my suspicion is that entries of 
size 0 WONT return an error condition to internal_search_pb, so it's valid for this to be 
empty.

Anyway, again, this is just reading the code for 20 minutes, and is not a 
complete in depth investigation, but maybe it's some ideas about what happened?

Hope it helps :)



—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-de...@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-de...@lists.fedoraproject.org

___
389-devel mailing list -- 389-de...@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-de...@lists.fedoraproject.org

Re: protobuf 3.14 update coming to rawhide

[Adrian Reber]

On Fri, Jan 15, 2021 at 10:15:11AM +0100, Dan Čermák wrote:
> Adrian Reber  writes:
> 
> > On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote:
> >> I prepared a protobuf update for rawhide to 3.14. It requires a rebuild
> >> of all dependencies and of the 54 dependencies currently only 3 fail to
> >> rebuild in COPR:
> >> 
> >> https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-14/packages/
> >> 
> >> paraview: timeout after 10 hours, should work in koji
> >> 
> >> community-mysql: test failure, this usually does not happen in koji
> >> 
> >> libgadu: actual build failures, but seems unrelated to protobuf:
> >> 
> >> /usr/bin/ld: sha1.o (symbol from plugin): undefined reference to symbol 
> >> 'SHA1_Init@@OPENSSL_1_1_0'
> >> /usr/bin/ld: /usr/lib64/libcrypto.so.1.1: error adding symbols: DSO 
> >> missing from command line
> >> 
> >> 
> >> I will start the rebuilds in rawhide in a side-tag in about a week
> >
> > All rebuilds are done, but I have not merged the side tag yet.
> 
> What's the name of the side tag?

Right, I should have mentioned that: f34-build-side-35763

Adrian


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: libelf now depends on openssl

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote:
>> On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel
>>  wrote:
>> >Do the boringssl symbols not have hidden visibility in libwebrtc?
>> >If they
>> >do, why are they getting interposed anyway? If they don't, why
>> >not? I assume
>> >the library is private to libwebrtc and its symbols should not be
>> >exported.
>> 
>> libwebrtc is a static lib, and so is boringssl. So all symbols,
>> except unused symbols, will be directly included in libwebkit2gtk.
>> In release builds, they would then be hidden by a linker script, but
>> in developer builds everything is exported because API tests depend
>> on internal symbols.
>
> Would it be possible to get rid of boringssl? Having yet another
> crypto library is ... bad.

Especially since it's not expected to be used outside of Google:

| BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
| 
| Although BoringSSL is an open source project, it is not intended for
| general use, as OpenSSL is. We don't recommend that third parties
| depend upon it.



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: protobuf 3.14 update coming to rawhide

[Dan Čermák]

Adrian Reber  writes:

> On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote:
>> I prepared a protobuf update for rawhide to 3.14. It requires a rebuild
>> of all dependencies and of the 54 dependencies currently only 3 fail to
>> rebuild in COPR:
>> 
>> https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-14/packages/
>> 
>> paraview: timeout after 10 hours, should work in koji
>> 
>> community-mysql: test failure, this usually does not happen in koji
>> 
>> libgadu: actual build failures, but seems unrelated to protobuf:
>> 
>> /usr/bin/ld: sha1.o (symbol from plugin): undefined reference to symbol 
>> 'SHA1_Init@@OPENSSL_1_1_0'
>> /usr/bin/ld: /usr/lib64/libcrypto.so.1.1: error adding symbols: DSO missing 
>> from command line
>> 
>> 
>> I will start the rebuilds in rawhide in a side-tag in about a week
>
> All rebuilds are done, but I have not merged the side tag yet.

What's the name of the side tag?


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

[ELN] "eln-sig" group is missing from dist-git

[Igor Raits]

I have a package where ELN SIG is supposed to be a co-maintainer because
there is something specific to their needs but there is no such group on
dist-git "@eln-sig".

Can somebody add it there?

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

Re: libelf now depends on openssl

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote:
> On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel
>  wrote:
> >Do the boringssl symbols not have hidden visibility in libwebrtc?
> >If they
> >do, why are they getting interposed anyway? If they don't, why
> >not? I assume
> >the library is private to libwebrtc and its symbols should not be
> >exported.
> 
> libwebrtc is a static lib, and so is boringssl. So all symbols,
> except unused symbols, will be directly included in libwebkit2gtk.
> In release builds, they would then be hidden by a linker script, but
> in developer builds everything is exported because API tests depend
> on internal symbols.

Would it be possible to get rid of boringssl? Having yet another
crypto library is ... bad.

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