Question about retired python-oslo-messaging, python-oslo-middleware and python-oslo-service

[Hirotaka Wakabayashi via devel]

Hello Alfredo,
I would like to maintain the following retired packages that you have formerly
maintained[1]. Upstream of each package is alive. I would be happy if you could 
tell me if you know additional issues with them.

python-oslo-messaging https://src.fedoraproject.org/rpms/python-oslo-messaging
    Upstream is alive. https://opendev.org/openstack/oslo.messaging

python-oslo-middleware https://src.fedoraproject.org/rpms/python-oslo-middleware
    Upstream is alive. https://opendev.org/openstack/oslo.middleware

python-oslo-service https://src.fedoraproject.org/rpms/python-oslo-service
    Upstream is alive. https://opendev.org/openstack/oslo.service

This is my first time to claim ownership of retired packages. I wrote this 
email by seeing the following page.
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
I need them because my package requires them. I will submit re-reviews of them 
if no problems.

Thanks in advance,
Hirotaka Wakabayashi

---
[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DDVGRKS2EQMVD2XAZ7GK5ADIJC7AKXVK/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1979815] perl-DateTime-Format-Flexible-0.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTime-Format-Flexib |perl-DateTime-Format-Flexib
   |le-0.34-1.fc35  |le-0.34-1.fc35
   |perl-DateTime-Format-Flexib |perl-DateTime-Format-Flexib
   |le-0.34-1.fc33  |le-0.34-1.fc33
   ||perl-DateTime-Format-Flexib
   ||le-0.34-1.fc34



--- Comment #21 from Fedora Update System  ---
FEDORA-2021-f8463ef2d1 has been pushed to the Fedora 34 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1982677] perl-DateTimeX-Easy: FTBFS in Fedora rawhide

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTimeX-Easy-0.089-2 |perl-DateTimeX-Easy-0.089-2
   |9.fc35  |9.fc35
   |perl-DateTimeX-Easy-0.089-2 |perl-DateTimeX-Easy-0.089-2
   |7.fc33  |7.fc33
   ||perl-DateTimeX-Easy-0.089-2
   ||8.fc34



--- Comment #16 from Fedora Update System  ---
FEDORA-2021-f8463ef2d1 has been pushed to the Fedora 34 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef   
openjpeg2-2.3.1-11.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ddb4fcb22a   
opendmarc-1.4.1.1-3.el7


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

dmlite-1.15.0-6.el7
libmodulemd2-2.13.0-1.el7
lynis-3.0.6-1.el7
seamonkey-2.53.8.1-1.el7

Details about builds:



 dmlite-1.15.0-6.el7 (FEDORA-EPEL-2021-499f64145e)
 Lcgdm grid data management and storage framework

Update Information:

Minor bugfixes for 1.15.0 release.

ChangeLog:

* Fri Jul 23 2021 Petr Vokac  - 1.15.0-6
- Minor bugfixes
- Puppet modules version updated
* Wed Jul 21 2021 Fedora Release Engineering  - 
1.15.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild




 libmodulemd2-2.13.0-1.el7 (FEDORA-EPEL-2021-a624e3264b)
 Module metadata manipulation library

Update Information:

This release adds /data/demodularized/rpms list to modulemd and modulemd-
packager formats and enables modulemd-validator tool to constrain a document
type with a new "--type" option. It also fixes parsing integers, handling failed
g_setenv() call in modulemd-validator, dereferencing a possible NULL pointer
when reporting invalid subdocuments, and "modulemd-validator --version" exit
code.

ChangeLog:

* Fri Jul  9 2021 Petr Pisar  - 2.13.0-1
- 2.13.0 bump




 lynis-3.0.6-1.el7 (FEDORA-EPEL-2021-d9553ac5a6)
 Security and system auditing tool

Update Information:

3.0.6

ChangeLog:

* Fri Jul 23 2021 Gwyn Ciesla  - 3.0.6-1
- 3.0.6
* Thu Jul 22 2021 Fedora Release Engineering  - 
3.0.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Tue Jan 26 2021 Fedora Release Engineering  - 
3.0.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #1910547 - lynis-3.0.6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1910547




 seamonkey-2.53.8.1-1.el7 (FEDORA-EPEL-2021-edab6b43f2)
 Web browser, e-mail, news, IRC client, HTML editor

Update Information:

Update to 2.53.8.1  Includes fixes for mailnews archiving, as well as account
creation after news subscribing.  Show just an icon (instead of a big image
etc.) when moving in drag-and-drop operations to make sure the target is
visible. (You can change it back by toggling boolean preference
"nglayout.enable_drag_images" in about:config).

ChangeLog:

* Thu Jul 22 2021 Dmitry Butskoy  2.53.8.1-1
- update to 2.53.8.1
- no more set nglayout.enable_drag_images by default
- fix mailnews account creation after subscribing by a news URL (mozbz#521861)
- avoid staring drag-and-drop in full mailnews's Wide View (mozbz#1720968)
- fix clearing in download manager (mozbz#1501277)


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1979815] perl-DateTime-Format-Flexible-0.34 is available

[bugzilla]

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

Bug 1982677 Summary: perl-DateTimeX-Easy: FTBFS in Fedora rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1982677

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1982677] perl-DateTimeX-Easy: FTBFS in Fedora rawhide

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTimeX-Easy-0.089-2 |perl-DateTimeX-Easy-0.089-2
   |9.fc35  |9.fc35
   ||perl-DateTimeX-Easy-0.089-2
   ||7.fc33
 Resolution|--- |ERRATA
Last Closed||2021-07-24 01:07:41



--- Comment #15 from Fedora Update System  ---
FEDORA-2021-4e0a1d9423 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1979815] perl-DateTime-Format-Flexible-0.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTime-Format-Flexib |perl-DateTime-Format-Flexib
   |le-0.34-1.fc35  |le-0.34-1.fc35
   ||perl-DateTime-Format-Flexib
   ||le-0.34-1.fc33
 Resolution|--- |ERRATA
Last Closed||2021-07-24 01:07:39



--- Comment #20 from Fedora Update System  ---
FEDORA-2021-4e0a1d9423 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: squashfs-tools being updated in rawhide

[Bruno Wolff III]

On Fri, Jul 23, 2021 at 02:20:50 -0500,
 Bruno Wolff III  wrote:
Phillip released 4.5 which has some new functionallity, some clean up 
and some bug fixes. It looks like he worked pretty hard on it for 


I had a successfull build after tonight's compose started, so the 
earliest it will show up in rawhide is Saturday morning (in the US), 
assuming no one off rawhide composes.


The CI script failed. I'm not sure if this will block it from rawhide 
composes or not. So it might be a bit longer before it shows up.


The issue appears to be all zero fragments being truncated. So it probably 
won't actually break test composes.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Proposal to CANCEL: 2021-07-26 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
have anything in particular for the agenda, F35 things are ticking over
mostly smoothly, and I'm not a fan of meetings for meetings' sake.

If you're aware of anything it would be useful to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)

[Michael Catanzaro]

On Fri, Jul 23 2021 at 05:35:11 PM +0200, Vitaly Zaitsev via devel 
 wrote:

End users are able to switch between profiles with tuned-adm (CLI) or
tuned-switcher (GUI).


So to be clear, power-profiles-daemon has integration into 
gnome-control-center, not an extra app. gnome-settings-daemon 
integration is incoming, to automatically temporarily switch to battery 
saving mode when on low battery. If tuned wants to be an alternative, 
it would need a compatible D-Bus API.


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Consider packaging Jello

[Kelly Brazil]

Hi team,

I am the developer of JC and Jello. JC is currently packaged for Fedora and I 
would like to see if anyone would consider packaging Jello as well? Or would 
you know someone interested in doing so?
I created a src rpm spec similar to what we used for JC, so it should be pretty 
straightforward.
Spec URL: https://jello-packages.s3.us-west-1.amazonaws.com/fedora/jello.spec 

Description: Query JSON at the command line with Python syntax
Fedora Account System Username: kellyjonbra...@gmail.com 
https://github.com/kellyjonbrazil/jello 


Thanks!
Kelly

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

opportunistic dns-over-tls enabled in rawhide

[Zbigniew Jędrzejewski-Szmek]

systemd-249.2-1.fc35 was built today with -Ddefault-dns-over-tls=opportunistic
(https://fedoraproject.org/wiki/Changes/DNS_Over_TLS, #1889901).

Please file bugs if things don't work as expected (or work when unexpected).

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild update

[Scott Talbert]

On Fri, 23 Jul 2021, Scott Talbert wrote:


Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
changes listed in:

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

The mass rebuild will be done in a side tag (f35-rebuild) and moved over
when completed.

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

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-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 Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]


Hi,

Is it possible that the mass rebuild script has a bug where it's
skipping some packages?
I see it's processing packages "t" right now, but, for example,
rust-fedora-update-feedback has no mass rebuild commit / build yet.


Yeah, I was going to point out the same thing - it has skipped a couple of 
the packages I maintain, too, namely python-pyqtgraph and python-wxpython4.


I seem to recall this happening before, too.  :(


If someone from releng wants to share the massbuild.out file (assuming it 
doesn't have anything like security credentials logged in it), I would be 
interested in taking a look at it.


Scott
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review swap request: python-xds-protos

[Major Hayden]

On 7/23/21 2:35 PM, Ben Beasley wrote:
I’d like to get python-xds-protos 
(https://bugzilla.redhat.com/show_bug.cgi?id=1980041) reviewed so I can 
update grpc to version 1.39.0 in Rawhide in time for Fedora 35.


This is a new dependency for grpc—a weirdly circular one that’s 
ultimately generated from sources inside grpc, but is separately 
versioned and separately distributed (generated sources only) on PyPI, 
so I am treating it as a separate package.


I have some of the python-opencensus stuff already, so I'll take a look 
at this one for you. 


--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild update

[Scott Talbert]

On Fri, 23 Jul 2021, Fabio Valentini wrote:


Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
changes listed in:

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

The mass rebuild will be done in a side tag (f35-rebuild) and moved over
when completed.

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

Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-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 Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]


Hi,

Is it possible that the mass rebuild script has a bug where it's
skipping some packages?
I see it's processing packages "t" right now, but, for example,
rust-fedora-update-feedback has no mass rebuild commit / build yet.


Yeah, I was going to point out the same thing - it has skipped a couple of 
the packages I maintain, too, namely python-pyqtgraph and 
python-wxpython4.


I seem to recall this happening before, too.  :(

Scott
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Review swap request: python-xds-protos

[Ben Beasley]

I’d like to get python-xds-protos 
(https://bugzilla.redhat.com/show_bug.cgi?id=1980041) reviewed so I can 
update grpc to version 1.39.0 in Rawhide in time for Fedora 35.


This is a new dependency for grpc—a weirdly circular one that’s 
ultimately generated from sources inside grpc, but is separately 
versioned and separately distributed (generated sources only) on PyPI, 
so I am treating it as a separate package.


I’m happy to review another package, or a handful of simple packages, in 
exchange. I’m particularly accustomed to reviewing Python, C, C++, 
NodeJS, JavaScript, and web asset packages, but I’m happy to jump in and 
review something else as long as reading the relevant domain-specific 
packaging guidelines is enough to get me through the review.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preparing the Fedora Linux 37–42 release schedules

[Ben Cotton]

On Fri, Jul 23, 2021 at 2:44 PM Miro Hrončok  wrote:

> Do you think it makes sense to include expected Python releases there?
>
Definitely! I haven't done it in the last release or two, but I set up
the schedule to include upstream releases. Since Python now has
predictable schedules, I can pre-add them for the upcoming releases.
I've added an issue[1] for that to remind myself.

[1] https://pagure.io/fedora-pgm/schedule/issue/37

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild update

[Fabio Valentini]

On Wed, Jul 21, 2021 at 2:43 PM Tomas Hrcka  wrote:
>
> Hi all,
>
> Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
> on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
> changes listed in:
>
> https://pagure.io/releng/issues?status=Open=mass+rebuild
>
> The mass rebuild will be done in a side tag (f35-rebuild) and moved over
> when completed.
>
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html
>
> Things still needing rebuilding
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-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 Libera.Chat, by
> dropping an email to our list[2] or filing an issue in pagure[3]

Hi,

Is it possible that the mass rebuild script has a bug where it's
skipping some packages?
I see it's processing packages "t" right now, but, for example,
rust-fedora-update-feedback has no mass rebuild commit / build yet.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preparing the Fedora Linux 37–42 release schedules

[Miro Hrončok]

On 23. 07. 21 19:27, Ben Cotton wrote:

Hi everyone,

A few years ago, I created release schedules[1] through Fedora Linux
36. We've almost used up that buffer, so it's time to create the next
few years worth of schedules. Before I start that, I want to take the
opportunity to make sure the schedules match reality.

For teams that already have tasks on the release schedules, I have
opened issues in the schedule repo[2]. Please use those to let me know
what changes make sense. You may also be hearing from members of the
Program Management team about those soon. If your team is not
represented on the release schedule but you think it would be, file a
new issue.


Hey Ben,

Do you think it makes sense to include expected Python releases there?

With the annual release schedule we can predict that the Python mass rebuild 
will happen at the May/June boundary every year in all odd-numbered Fedora 
releases.


--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Preparing the Fedora Linux 37–42 release schedules

[Ben Cotton]

Hi everyone,

A few years ago, I created release schedules[1] through Fedora Linux
36. We've almost used up that buffer, so it's time to create the next
few years worth of schedules. Before I start that, I want to take the
opportunity to make sure the schedules match reality.

For teams that already have tasks on the release schedules, I have
opened issues in the schedule repo[2]. Please use those to let me know
what changes make sense. You may also be hearing from members of the
Program Management team about those soon. If your team is not
represented on the release schedule but you think it would be, file a
new issue.

For more information, check out my Community Blog post[3].

[1] https://fedorapeople.org/groups/schedule/
[2] https://pagure.io/fedora-pgm/schedule/issues
[3] https://communityblog.fedoraproject.org/time-to-make-new-release-schedules/


Thanks,
BC

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Pavel Raiskup]

On Friday, July 23, 2021 5:09:57 PM CEST Daniel P. Berrangé wrote:
> On Fri, Jul 23, 2021 at 03:25:15PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Jul 23, 2021 at 04:03:06PM +0200, Pavel Raiskup wrote:
> > > The ppc64le doesn't seem to build on Power8 hardware we have [2], and
> > > s390x has some troubles with qemu emulation [3].  So those architectures
> > > are at least for now disabled.
> > 
> > 
> > > [3] Fatal glibc error: CPU lacks VXE support (z14 or later required),
> > > 
> > > https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz
> > 
> > I'm trying to find out from the s390x QEMU maintainers about the
> > likely fix requird to make this work.
> 
> It will be fixed in QEMU 6.1.0 which is coming out in a month-ish:
> 
>   https://wiki.qemu.org/Planning/6.1
> 
> and will be addressed by this patch series
> 
>   https://lore.kernel.org/qemu-devel/20210517142739.38597-1-da...@redhat.com/
> 
> This futur QEMU release will go into f35 rawhide, and virt-preview repo
> can be used if you will need it for f34

Nice, thank you for the reference!

I'm curious...  couldn't we run CentOS Stream 9 ppc64le builds through qemu
emulation as well?

Pavel

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



___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed, 1 result missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud

Failed openQA tests: 6/201 (x86_64), 9/138 (aarch64)

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

ID: 933864  Test: x86_64 Server-dvd-iso install_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/933864
ID: 933915  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/933915
ID: 933945  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/933945
ID: 933999  Test: aarch64 Server-dvd-iso base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/933999
ID: 934051  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/934051
ID: 934053  Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/934053
ID: 934054  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/934054
ID: 934079  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/934079
ID: 934158  Test: aarch64 universal upgrade_2_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/934158

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

ID: 933927  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/933927
ID: 933953  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/933953
ID: 933992  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/933992
ID: 934034  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/934034
ID: 934149  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/934149
ID: 934166  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/934166

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

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

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

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

ID: 933978  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/933978
ID: 934035  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/934035
ID: 934084  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/934084
ID: 934131  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/934131

Passed openQA tests: 190/201 (x86_64), 126/138 (aarch64)

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

ID: 933968  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/933968
ID: 933971  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/933971
ID: 933972  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/933972
ID: 933974  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/933974
ID: 933975  Test: x86_64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/933975
ID: 933976  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/933976
ID: 933977  Test: x86_64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/933977
ID: 934044  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/934044
ID: 934045  Test: aarch64 Workstation-raw_xz-raw.xz base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/934045
ID: 934046  Test: aarch64 Workstation-raw_xz-raw.xz base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/934046
ID: 934047  Test: aarch64 Workstation-raw_xz-raw.xz base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/934047
ID: 934048  Test: 

Re: F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)

[Vitaly Zaitsev via devel]

On 23/07/2021 17:16, Michael Catanzaro wrote:

Hi, there is an answer here:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon#tuned-and-tlp



Both are good projects to use for the purpose of experimenting with particular
settings to see if they'd be something that can be implemented by default,
or to put some fine-grained, static, policies in place on server-type workloads
which are not as fluid and changing as desktop workloads can be.


Instead of adding new desktop-oriented profiles for the TuneD daemon, 
they are implementing another daemon from scratch.


Tuned works fine on desktops with custom profiles like this:

[main]
summary=Optimize for Linux gaming
include=desktop

[cpu]
governor=performance
energy_perf_bias=performance

End users are able to switch between profiles with tuned-adm (CLI) or 
tuned-switcher (GUI).


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)

[Michael Catanzaro]

Hi, apologies for this change being submitted a little late. The change 
has actually been fully implemented for a couple months now, and 
already approved by the Workstation WG (it only affects Workstation), 
but we feel a change proposal is important for documentation and 
promotion purposes.


On Fri, Jul 23 2021 at 04:59:25 PM +0200, Vitaly Zaitsev via devel 
 wrote:

On 23/07/2021 16:09, Ben Cotton wrote:
We will install power-profiles-daemon in Fedora Workstation and 
enable
it by default. power-profiles-daemon allows the user to choose 
between

optimizing for system performance or battery life.


Why not TuneD[1] (developed by Red Hat by the way)?


Hi, there is an answer here:

https://gitlab.freedesktop.org/hadess/power-profiles-daemon#tuned-and-tlp

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Daniel P . Berrangé]

On Fri, Jul 23, 2021 at 03:25:15PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 23, 2021 at 04:03:06PM +0200, Pavel Raiskup wrote:
> > The ppc64le doesn't seem to build on Power8 hardware we have [2], and
> > s390x has some troubles with qemu emulation [3].  So those architectures
> > are at least for now disabled.
> 
> 
> > [3] Fatal glibc error: CPU lacks VXE support (z14 or later required),
> > 
> > https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz
> 
> I'm trying to find out from the s390x QEMU maintainers about the
> likely fix requird to make this work.

It will be fixed in QEMU 6.1.0 which is coming out in a month-ish:

  https://wiki.qemu.org/Planning/6.1

and will be addressed by this patch series

  https://lore.kernel.org/qemu-devel/20210517142739.38597-1-da...@redhat.com/

This futur QEMU release will go into f35 rawhide, and virt-preview repo
can be used if you will need it for f34

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

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Richard W.M. Jones]

On Fri, Jul 23, 2021 at 10:17:41AM -0400, Stephen John Smoogen wrote:
> On Fri, 23 Jul 2021 at 10:06, Pavel Raiskup  wrote:
> > [3] Fatal glibc error: CPU lacks VXE support (z14 or later required),

This one is:

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

Seems like it should be fixed with a sufficiently recent copy of qemu.
(Hmm, you're running copr / s390x on top of software emulation ...?)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)

[Vitaly Zaitsev via devel]

On 23/07/2021 16:09, Ben Cotton wrote:

We will install power-profiles-daemon in Fedora Workstation and enable
it by default. power-profiles-daemon allows the user to choose between
optimizing for system performance or battery life.


Why not TuneD[1] (developed by Red Hat by the way)?

TuneD is a system tuning service for Linux. Features:

- monitors connected devices using the udev device manager
- tunes system settings according to a selected profile
- supports various types of configuration like sysctl, sysfs, or kernel 
boot command line parameters, which are integrated in a plug-in architecture
- supports hot plugging of devices and can be controlled from the 
command line or through D-Bus, so it can be easily integrated into 
existing administering solutions: for example, with Cockpit
- stores all its configuration cleanly in one place – in the TuneD 
profile – instead of having configuration on multiple places and in 
custom scripts


[1]: https://tuned-project.org/

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1985448] New: perl-Module-CoreList-5.20210723 is available

[bugzilla]

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

Bug ID: 1985448
   Summary: perl-Module-CoreList-5.20210723 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-CoreList
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.20210723
Current version/release in rawhide: 5.20210620-1.fc35
URL: http://search.cpan.org/dist/Module-CoreList/

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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
We will install power-profiles-daemon in Fedora Workstation and enable
it by default. power-profiles-daemon allows the user to choose between
optimizing for system performance or battery life.

== Owner ==
* Name: [[User:Hadess| Bastien Nocera]]
* Email: bnoc...@redhat.com
* Name: [[User:Catanzaro|Michael Catanzaro]]
* Email: mcatanz...@redhat.com
* Name: [[User:Ngompa|Neal Gompa]]
* Email: ngomp...@gmail.com


== Detailed Description ==

From the upstream README:

power-profiles-daemon offers to modify system behaviour based upon
user-selected power profiles. There are 3 different power profiles, a
"balanced" default mode, a "power-saver" mode, as well as a
"performance" mode. The first 2 of those are available on every
system. The "performance" mode is only available on select systems and
is implemented by different "drivers" based on the system or systems
it targets.

In addition to those 2 or 3 modes (depending on the system), "actions"
can be hooked up to change the behaviour of a particular device. For
example, this can be used to disable the fast-charging for some USB
devices when in power-saver mode.

GNOME's Settings and shell both include interfaces to select the
current mode, but they are also expected to adjust the behaviour of
the desktop depending on the mode, such as turning the screen off
after inaction more aggressively when in power-saver mode.

== Feedback ==


== Benefit to Fedora ==
Shipping power-profiles-daemon enables GNOME to display and offer
users the ability to adjust configuration related to power management
similar to other operating systems, which can improve the quality of
the on-battery experience (with respect to longevity of operating on
battery power).

== Scope ==

* Proposal owners: Add Recommends: power-profiles-daemon to
gnome-control-center package. Add systemd preset to fedora-release.
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope.

== Upgrade/compatibility impact ==

power-profiles-daemon will be installed on upgrade to Fedora 35 if
gnome-control-center is installed. Since the default power profile is
the balanced mode, users should not notice performance changes (sans
bugs), but the option to manually select either performance or power
saving mode will now be present.

== How To Test ==

Visit the Power settings panel in gnome-control-center and switch
between performance, balanced, and power save mode. Look for
unexpected behavior changes over long periods of time. For example,
selecting Performance mode should improve system performance but
reduce battery life. Selecting power save mode should reduce
performance but increase battery life. Selecting balanced mode should
not change anything.

The selected power save mode should persist across system reboots.

== User Experience ==

GNOME Control Center will show a new section in the Power page giving
users the option to select power modes:

* Balanced (the default)
* Performance (to maximize performance)
* Power saver (to maximize battery life)

User selection of these profiles will set various tunables to meet the
needs as described in the profiles.

== Dependencies ==

gnome-control-center depends on power-profiles-daemon to offer power
saving options. If not installed, these options will not be present in
the power panel.

== Contingency Plan ==

* Contingency mechanism: we can easily remove the Recommends: in
gnome-control-center or the preset in fedora-release if necessary.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No

== Documentation ==

The only documentation is the upstream project README:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/main/README.md

== Release Notes ==

Fedora Workstation now ships with power-profiles-daemon installed and enabled.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Dan Horák]

On Fri, 23 Jul 2021 10:17:41 -0400
Stephen John Smoogen  wrote:

> On Fri, 23 Jul 2021 at 10:06, Pavel Raiskup  wrote:
> >
> > Hi all,
> >
> > just for the info, we enabled the `centos-stream-9-x86_64` and
> > `centos-stream-9-aarch64` chroots in Fedora Copr.  Note that we build
> > directly from composes [1] without mirrors (some failures can expected),
> > and that the packages are not GPG-signed.  You have been warned :-)
> >
> > The ppc64le doesn't seem to build on Power8 hardware we have [2], and
> > s390x has some troubles with qemu emulation [3].  So those architectures
> > are at least for now disabled.
> >
> 
> CentOS Stream 9 and RHEL-9 will only support Power 9 and above
> architectures. So COPR will not be able to build CS9 or RHEL-9 at this
> time.
> 
> I am guessing the s390x emulation is also an architectural issue as I
> believe the minimal system for 9 to work on has also moved.

right, RHEL-9 moved the minimums to Power9 for ppc64le and z14 for s390x


Dan
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1985399] New: perl-CPAN-Perl-Releases-5.20210722 is available

[bugzilla]

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

Bug ID: 1985399
   Summary: perl-CPAN-Perl-Releases-5.20210722 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.20210722
Current version/release in rawhide: 5.20210620-1.fc35
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Daniel P . Berrangé]

On Fri, Jul 23, 2021 at 04:03:06PM +0200, Pavel Raiskup wrote:
> The ppc64le doesn't seem to build on Power8 hardware we have [2], and
> s390x has some troubles with qemu emulation [3].  So those architectures
> are at least for now disabled.


> [3] Fatal glibc error: CPU lacks VXE support (z14 or later required),
> 
> https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz

I'm trying to find out from the s390x QEMU maintainers about the
likely fix requird to make this work.

Can you tell me what QEMU version is in use in this environment.


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

Re: coreos-diskimage-rehydrator

[Richard W.M. Jones]

On Fri, Jul 23, 2021 at 10:04:51AM -0400, Colin Walters wrote:
> On Fri, Jul 23, 2021, at 3:24 AM, Richard W.M. Jones wrote:
> > 
> > Hi Colin,
> > 
> > Intrigued by what this is doing:
> > https://github.com/cgwalters/coreos-diskimage-rehydrator/tree/main/src
> > 
> > A few questions:
> > 
> > Don't you have the problem that OSes (eg. OVAs) from VMware won't
> > boot on KubeVirt?
>
> This is unrelated to KubeVirt...or, well it could be tangentially
> related but it really operates on a different layer.
>
> > Not really sure what "streams" refer to in this context.  
>
> Did you see the main `README.md` content in
> https://github.com/cgwalters/coreos-diskimage-rehydrator ?  That
> document assumes a passing familiarity with Fedora CoreOS but
> "stream metadata" specifically links to
> https://docs.fedoraproject.org/en-US/fedora-coreos/stream-metadata/

Yeah I saw it but as with many things I didn't necessarily understand
it :-( So in fact it's nothing to do with streams as I was thinking
about it.  I guess "stream" means something like "software stream", as
in which distro and stable version series.

> > But if
> > that's referring to streaming as in piping disk images across the
> > network, we've got a bunch of tooling here around this.
>
> I am definitely interested in your opinion on this, and perhaps
> there are indeed some techniques you know of that would apply to
> this problem domain.

I gave a talk about this.  I don't know if it's at all relevant to
what you're doing, but here it is:

"Disk image pipelines: Efficiently copying, sparsifying, modifying, streaming 
multi-terabyte disk images between systems"
http://oirase.annexia.org/tmp/disk-image-pipelines.mp4

> However, let's be sure we're on the same page!  I and my team live
> in a duality or quantum superposition between Fedora/RHEL and
> Kubernetes/OpenShift.  One needs an operating system to run
> OpenShift.  But: a huge part of the vision of OpenShift 4 is that
> the operating system is managed by the cluster.
>
> And further OpenShift 4 is not e.g. RPMs installed by something like
> Ansible.  Instead, we build and ship the platform the same way our
> customers write applications - as containers.  These containers all
> run as Kubernetes pods.  Admins can use e.g. `kubectl log` on the
> machine-config-operator to look at the OS upgrade process on a node.
> The thing starting the OS update is a (privileged) container.  We
> ship updates to the OS as a container image
> (https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md
> ).
>
> However, shipping tons of disconnected container images is chaos -
> how do you CI test that?  (In the same way shipping lots of RPMs
> independently is chaos) So a cool OpenShift 4 specific thing is this
> concept of the "release image" which is a *single container image*
> that contains @sha256 references to all the other containers
> (including the OS updates).

(Sounds like git / docker / Fedora atomic...)

> And that's what we ship and CI test.  If you visit e.g. 
> https://amd64.ocp.releases.ci.openshift.org/ and click on e.g.
> https://amd64.ocp.releases.ci.openshift.org/releasestream/4.9.0-0.nightly/release/4.9.0-0.nightly-2021-07-21-081948
> you can see all the CI across many platforms that ran on that release image.
> 
> And crucially, that's how we ship it to customers.  If for example you want 
> to perform a disconnected installation, all you need to do is mirror those 
> containers:
> https://docs.openshift.com/container-platform/4.7/installing/installing-mirroring-installation-images.html
> And you get *exactly the same thing* that ran in CI.  That's a big deal.

Understood.

> OK now we're finally reaching the point: When I said everything was
> part of the release image, that was kind of a lie, because it's
> everything *except* the RHCOS "bootimages" e.g. AMI/OpenStack
> qcow2/etc.

The "bootimage" here is (for example) the Fedora AMI that might be
shipped in Amazon.  So it would contain the bootloader, kernel, and a
base distribution?

> And that's the goal of the rehydrator - if e.g. you want to perform
> a disconnected OpenStack/vSphere/etc. install, all you need to do is
> follow those instructions to mirror the set of container images, and
> then on premise you can *run* the rehydrator container and out pops
> a vSphere/OpenStack/etc. image that you can upload to bootstrap the
> process.

OK, I believe I have a better understanding now, thanks!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Stephen John Smoogen]

On Fri, 23 Jul 2021 at 10:06, Pavel Raiskup  wrote:
>
> Hi all,
>
> just for the info, we enabled the `centos-stream-9-x86_64` and
> `centos-stream-9-aarch64` chroots in Fedora Copr.  Note that we build
> directly from composes [1] without mirrors (some failures can expected),
> and that the packages are not GPG-signed.  You have been warned :-)
>
> The ppc64le doesn't seem to build on Power8 hardware we have [2], and
> s390x has some troubles with qemu emulation [3].  So those architectures
> are at least for now disabled.
>

CentOS Stream 9 and RHEL-9 will only support Power 9 and above
architectures. So COPR will not be able to build CS9 or RHEL-9 at this
time.

I am guessing the s390x emulation is also an architectural issue as I
believe the minimal system for 9 to work on has also moved.


> [1] https://github.com/rpm-software-management/mock/pull/751
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1985364
> [3] Fatal glibc error: CPU lacks VXE support (z14 or later required),
> 
> https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz
>
> Happy building!
> Pavel
>
>
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Use power-profiles-daemon on Workstation (late Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
We will install power-profiles-daemon in Fedora Workstation and enable
it by default. power-profiles-daemon allows the user to choose between
optimizing for system performance or battery life.

== Owner ==
* Name: [[User:Hadess| Bastien Nocera]]
* Email: bnoc...@redhat.com
* Name: [[User:Catanzaro|Michael Catanzaro]]
* Email: mcatanz...@redhat.com
* Name: [[User:Ngompa|Neal Gompa]]
* Email: ngomp...@gmail.com


== Detailed Description ==

From the upstream README:

power-profiles-daemon offers to modify system behaviour based upon
user-selected power profiles. There are 3 different power profiles, a
"balanced" default mode, a "power-saver" mode, as well as a
"performance" mode. The first 2 of those are available on every
system. The "performance" mode is only available on select systems and
is implemented by different "drivers" based on the system or systems
it targets.

In addition to those 2 or 3 modes (depending on the system), "actions"
can be hooked up to change the behaviour of a particular device. For
example, this can be used to disable the fast-charging for some USB
devices when in power-saver mode.

GNOME's Settings and shell both include interfaces to select the
current mode, but they are also expected to adjust the behaviour of
the desktop depending on the mode, such as turning the screen off
after inaction more aggressively when in power-saver mode.

== Feedback ==


== Benefit to Fedora ==
Shipping power-profiles-daemon enables GNOME to display and offer
users the ability to adjust configuration related to power management
similar to other operating systems, which can improve the quality of
the on-battery experience (with respect to longevity of operating on
battery power).

== Scope ==

* Proposal owners: Add Recommends: power-profiles-daemon to
gnome-control-center package. Add systemd preset to fedora-release.
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope.

== Upgrade/compatibility impact ==

power-profiles-daemon will be installed on upgrade to Fedora 35 if
gnome-control-center is installed. Since the default power profile is
the balanced mode, users should not notice performance changes (sans
bugs), but the option to manually select either performance or power
saving mode will now be present.

== How To Test ==

Visit the Power settings panel in gnome-control-center and switch
between performance, balanced, and power save mode. Look for
unexpected behavior changes over long periods of time. For example,
selecting Performance mode should improve system performance but
reduce battery life. Selecting power save mode should reduce
performance but increase battery life. Selecting balanced mode should
not change anything.

The selected power save mode should persist across system reboots.

== User Experience ==

GNOME Control Center will show a new section in the Power page giving
users the option to select power modes:

* Balanced (the default)
* Performance (to maximize performance)
* Power saver (to maximize battery life)

User selection of these profiles will set various tunables to meet the
needs as described in the profiles.

== Dependencies ==

gnome-control-center depends on power-profiles-daemon to offer power
saving options. If not installed, these options will not be present in
the power panel.

== Contingency Plan ==

* Contingency mechanism: we can easily remove the Recommends: in
gnome-control-center or the preset in fedora-release if necessary.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No

== Documentation ==

The only documentation is the upstream project README:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/main/README.md

== Release Notes ==

Fedora Workstation now ships with power-profiles-daemon installed and enabled.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: [CentOS-devel] Updated KDE Plasma Desktop ready for testing on CentOS Stream 8

[Neal Gompa]

On Thu, Jul 22, 2021 at 6:22 PM Troy Dawson  wrote:
>
> An updated qt5 in CentOS Stream 8 allowed us to update KDE Plasma Desktop.
> I believe everything is in place and ready for use and/or testing.
>
> This is for CentOS Stream 8 only, at this time.
>
> ===How to Install [1]
> = Install epel-release
>dnf install 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> = Enable PowerTools
>dnf config-manager --enable powertools
> = Install KDE
>   dnf group install kde-desktop-environment
> or
>   dnf group install kde-desktop
>   (Optional) dnf group install kde-apps
>   (Optional) dnf group install kde-media
>   (Optional) dnf group install kde-education
>   (Optional) dnf install okular
>   (Optional) dnf group install kde-software-development
>   (Optional) dnf group install kf5-software-development
>
> === KNOWN PACKAGE ISSUES
>
> == UNINSTALLABLE PACKAGES
> * kaccounts-providers - no signon-ui
> * kigo - no gnugo
> * lokalize - no translate-toolkit , needs rebuilding on python3
>
> == UNBUILT PACKAGES
> * polkit-qt5 - need branch and build of polkit-qt-1
> * kde-gtk-config - needs sassc
> * digikam - can't find opencv despite it being installed
>
> == UN-UPDATED PACKAGES (but still install and run)
> * kpmcore - would need a newer util-linux than available in RHEL 8
> * kde-partitionmanager - would need a newer kpmcore
>

The KPMCore libblkid bump to 2.33.2[1] comes from an issue with
resizing logical partitions[2] that was fixed in 2.33.2[3].

It may be worth asking if this fix can be backported so that we can
relax the dependency and update kde-partitionmanager.

[1]: 
https://invent.kde.org/system/kpmcore/-/commit/6d272234bbaa98eb580b495392f0c79c01375d66
[2]: https://github.com/karelzak/util-linux/issues/745
[3]: 
https://github.com/karelzak/util-linux/commit/590dc5e919d24e530483af24e877aeb6904d00d2



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

CentOS Sream 9 pre-release chroots added to Fedora Copr

[Pavel Raiskup]

Hi all,

just for the info, we enabled the `centos-stream-9-x86_64` and
`centos-stream-9-aarch64` chroots in Fedora Copr.  Note that we build
directly from composes [1] without mirrors (some failures can expected),
and that the packages are not GPG-signed.  You have been warned :-)

The ppc64le doesn't seem to build on Power8 hardware we have [2], and
s390x has some troubles with qemu emulation [3].  So those architectures
are at least for now disabled.

[1] https://github.com/rpm-software-management/mock/pull/751
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1985364
[3] Fatal glibc error: CPU lacks VXE support (z14 or later required),

https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz

Happy building!
Pavel


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild update

[Richard W.M. Jones]

On Wed, Jul 21, 2021 at 01:27:59PM +0200, Tomas Hrcka wrote:
> Hi all,
> 
> Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35
> on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the
> changes listed in:
> 
> https://pagure.io/releng/issues?status=Open=mass+rebuild
> 
> The mass rebuild will be done in a side tag (f35-rebuild) and moved over
> when completed.
> 
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html
>
> Things still needing rebuilding
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html

I don't see email notifications about successful and failed builds,
even though they seem to be happening in Koji and from the above
lists.  Is it being slow or broken?

Rich.

> 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 Libera.Chat, by
> dropping an email to our list[2] or filing an issue in pagure[3]
> 
> Regards,
> Tomas Hrcka
> fas: humaton
> LiberaChat: jednorozec
> 
> [1] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
> [2] 
> https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org
> /
> [3] https://pagure.io/releng/
> 
> 
> 
> 
> --
> Tomas Hrcka
> role: CPE Team - Senior Software Engineer
> fas: humaton
> freenode: jednorozec

> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm-ostree cliwrap effort

[Colin Walters]

On Fri, Jul 23, 2021, at 7:20 AM, Neal Gompa wrote:
>
> I think I'd prefer that if you intend to do CLI wrappers, that the
> wrapper matches the semantics of the original tools as much as
> possible.
> 
> That is, "dnf|yum install " should overlay RPMs on the system,

I can certainly see ultimately making this configurable (locally and per 
edition).  Some people definitely want "dnf with images and transactional 
updates", i.e. they haven't adapted to a world living in containers.  For 
example, these people might be installing things like `gcc`, `mock` etc. to the 
host system.  They might still have a web browser lifecycle bound with the 
operating system.  Whereas the current behavior is obviously explicitly 
intended to push people into containers, because the benefits are powerful (to 
them, and us).

So yes, we could have an option where `dnf|yum install` just silently runs 
`rpm-ostree install -A` instead of printing the error it does today pretty 
easily.  But then:

> "dnf|yum upgrade" should do the rebase, etc.

Matching semantics exactly gets tricky because then - `dnf upgrade` equivalent 
to `rpm-ostree upgrade && rpm-ostree ex apply-live` or is it just (as the code 
supports today) `rpm-ostree upgrade` i.e. queued for next boot?

The thing is, ultimately I don't believe "online upgrades" should be the 
default.  I know this is a highly polarizing topic =)  But basically it's just 
chock full of race conditions except in a very few targeted cases.  It can 
mostly appear to work most of the time, but you can get spectacular failures 
too.  

What I've concluded is basically offline updates are the default, but it should 
be as easy as possible for the system administrator to "cherry pick" a subset 
of those updates live.  For the nightmare scenario of e.g. an openssh 
unauthenticated RCE, it should be like `rpm-ostree apply-live openssh` that 
pulls the queued updated openssh that would be on the next boot and applies it 
live, while leaving e.g. a queued not-security kernel update (also because 
changing what `rpm -q kernel` says is also just always a confusing lie).

> However, if you *don't* intend to preserve semantics, then don't
> bother doing it *at all* because it'll just lead to confusion. Error
> messages are not helpful.

We'll have to disagree there!  I mean I've been doing this for years now and 
constantly talking to people and e.g. the "engineer/tester trying to replace 
the kernel with yum install" section in 
https://github.com/coreos/rpm-ostree/issues/2883 is just one example of 
something I know this will help with.

> It's just better to not have the command at
> all in the first place in that circumstance. Imagine how much you'd
> break scripts and automation by having something "pretend" to be
> DNF/YUM without actually being able to *do* the things people expect
> it to do.

Yep, a member of my team recently raised this concern and I agree it's a 
problem.  I filed
https://github.com/coreos/rpm-ostree/issues/3009
which I'll probably do pretty soon.

> I'm not sure this is a useful way to position it, since RPM-OSTree
> works completely differently and classes of RPMs don't even work on
> the system. Additionally, the emphasis on using OCI images, Flatpaks,
> and other non-RPM content instead of native RPM content on these
> systems means that "image based dnf" is disingenuous and a potential
> source for confusion, since you've been pushing to *avoid* supporting
> workflows people do on regular Fedora systems.

I think RPM isn't any more native than containers.  It's just a tool, a 
technique; not the axis around which everything revolves or should revolve.

Thanks for the feedback and discussion!  I think people will have a variety of 
opinions here and it's good to have those represented.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

New release: pyproject-rpm-macros 0-46, new features and breaking changes

[Miro Hrončok]

Hello,
we have just released pyproject-rpm-macros 0-46 with new features and breaking 
changes (2 affected Fedora packages, python-platformdirs and python-shellingham).


F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a33e4b0558

F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fcf5e2adc6

F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3d06d86fe9

We aim to release version 1 before Fedora 35 is released: That should remove 
the "provisional" status of the macros: we are extensively probing the design 
decisions and plan to maintain a stable interface and behavior after that.


tl;dr version:

%pyproject_buildrequires now supports x.* versions.

In %pyproject_buildrequires, invalid requirements now *fail* the build.

%pyproject_buildrequires fallbacks to setuptools only if setup.py exists.

The requirements files parser is now more robust.

%pyproject_save_files now escapes weird characters.

%pyproject_save_files marks license files with %license.

The %{_pyproject_ghost_distinfo} and %{_pyproject_record} macros are private.

Details below:

---

%pyproject_buildrequires now supports x.* versions.

When a project requires e.g. "pkg==6.*", %pyproject_buildrequires now correctly 
handles that by requiring "pytohn3dist(pkg) >= 6 with pytohn3dist(pkg) < 7".


---

In %pyproject_buildrequires, invalid requirements now *fail* the build.

Previously, they were skipped with a warning. Only one package in Fedora is 
affected and a PR exists (python-platformdirs#1).


Failing the build for dependencies that cannot be processed via Python tools 
(such as pip) is harmless: The package would eventually fail to build later in 
the process anyway. However, some dependency declarations work with pip while 
we cannot process them via the macros. From the README:



When a dependency is specified via an URL or local path, for example as:

  
https://github.com/ActiveState/appdirs/archive/8eacfa312d77aba28d483fbfb6f6fc54099622be.zip
  /some/path/foo-1.2.3.tar.gz
  git+https://github.com/sphinx-doc/sphinx.git@96dbe5e3

The %pyproject_buildrequires macro is unable to convert it to an appropriate 
RPM requirement and will fail. If the URL contains the packageName @ prefix as 
specified in PEP 508, the requirement will be generated without a version 
constraint:

  
appdirs@https://github.com/ActiveState/appdirs/archive/8eacfa312d77aba28d483fbfb6f6fc54099622be.zip
  foo@file:///some/path/foo-1.2.3.tar.gz

Will be converted to:

  python3dist(appdirs)
  python3dist(foo)

Alternatively, when an URL requirement parsed from a text file given as 
positional argument to %pyproject_buildrequires contains the #egg=packageName 
fragment, as documented in pip's documentation:

  git+https://github.com/sphinx-doc/sphinx.git@96dbe5e3#egg=sphinx

The requirements will be converted to package names without versions, e.g.:

  python3dist(sphinx)

However upstreams usually only use direct URLs for their requirements as 
workarounds, so be prepared for problems.




%pyproject_buildrequires fallbacks to setuptools only if setup.py exists.

In line with the recent development of pip (and build), when the build backend 
is not specified (e.g. pyproject.toml is missing or does not specify it) the 
setuptools.build_meta.__legacy__ build backend is only used if setup.py exists.


Projects without setup.py that intent to use setuptools need to explicitly 
declare it in pyoproject.toml or add a setup.py stub, see e.g. 
python-shellingham#5, the only affected Fedora package.


---

The requirements files parser is now more robust.

The %pyproject_buildrequires macro accepts requirements files as optional 
position arguments. With this release, the parser for the files (also used for 
tox dependencies) is more robust and should process comments, escaped newlines 
and environment variables better than ever.


However, the parser is not (yet) 100% compatible with `pip install -r ` 
behavior (and might as well never be). If you encounter incompatibilities, 
please let us know.


---

%pyproject_save_files now escapes weird characters.

When a path contains spaces (incl. newlines), quotes (") or percentage signs 
(%), it is now correctly escaped by %pyproject_save_files.


Note that due to the limitations of RPM, we are unable to represent a path with 
both spaces and quotes. An error is raised when that happens, instead of 
producing wrong results.


---

%pyproject_save_files marks license files with %license.

PEP 639 (still a draft) introduces a new metadata field for license files (the 
License-File field). Setuptools 57+ generate the field from the license_file(s) 
setup options. %pyproject_save_files newly recognizes this field and marks the 
listed files with the %license tag. Other build backends might follow later.


If your package supports this, you no longer need to list the license file 
manually. I recommend using `rpm -ql --licensefiles` to 

Fedora rawhide compose report: 20210723.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210722.n.0
NEW: Fedora-Rawhide-20210723.n.0

= SUMMARY =
Added images:4
Dropped images:  1
Added packages:  4
Dropped packages:1
Upgraded packages:   124
Downgraded packages: 4

Size of added packages:  501.32 KiB
Size of dropped packages:609.09 KiB
Size of upgraded packages:   1.72 GiB
Size of downgraded packages: 341.33 KiB

Size change of upgraded packages:   2.55 MiB
Size change of downgraded packages: -72.11 KiB

= ADDED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20210723.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20210723.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210723.n.0.iso
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20210723.n.0.ppc64le.tar.xz

= DROPPED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20210722.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: diffuse-0.6.0-1.fc35
Summary: Graphical tool for merging and comparing text files
RPMs:diffuse
Size:355.08 KiB

Package: python-charset-normalizer-2.0.3-1.fc35
Summary: The Real First Universal Charset Detector
RPMs:python3-charset-normalizer
Size:67.49 KiB

Package: rust-serde_bser-0.3.1-1.fc35
Summary: Implements the Watchman BSER encoding for serde
RPMs:rust-serde_bser+debug_bytes-devel rust-serde_bser+default-devel 
rust-serde_bser-devel
Size:40.66 KiB

Package: rust-watchman_client-0.7.1-1.fc35
Summary: Client for the Watchman file watching service
RPMs:rust-watchman_client+default-devel rust-watchman_client-devel
Size:38.09 KiB


= DROPPED PACKAGES =
Package: java-atk-wrapper-0.38.0-6.fc34
Summary: Java ATK Wrapper
RPMs:java-atk-wrapper
Size:609.09 KiB


= UPGRADED PACKAGES =
Package:  Cython-0.29.24-1.fc35
Old package:  Cython-0.29.22-3.fc35
Summary:  Language for writing Python extension modules
RPMs: emacs-cython-mode python3-Cython
Size: 12.48 MiB
Size change:  13.11 KiB
Changelog:
  * Wed Jun 02 2021 Python Maint  - 0.29.22-4
  - Rebuilt for Python 3.10

  * Wed Jul 21 2021 Fedora Release Engineering  - 
0.29.22-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Wed Jul 21 2021 Scott Talbert  - 0.29.24-1
  - Update to 0.29.24 to fix FTBFS with Python 3.10


Package:  ansible-collection-ansible-netcommon-2.2.0-1.fc35
Old package:  ansible-collection-ansible-netcommon-1.5.0-1.fc34
Summary:  Ansible Network Collection for Common Code
RPMs: ansible-collection-ansible-netcommon
Size: 180.47 KiB
Size change:  -9.00 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
1.5.0-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Thu Jul 22 2021 Sagi Shnaidman  - 2.2.0-1
  - Update to 2.2.0


Package:  awscli-1.20.5-1.fc35
Old package:  awscli-1.20.4-1.fc35
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.08 MiB
Size change:  8 B
Changelog:
  * Thu Jul 22 2021 Gwyn Ciesla  - 1.20.5-1
  - 1.20.5


Package:  bemenu-0.6.3-1.fc35
Old package:  bemenu-0.6.2-1.fc35
Summary:  Dynamic menu library and client program inspired by dmenu
RPMs: bemenu bemenu-devel
Size: 623.41 KiB
Size change:  985 B
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
0.6.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Thu Jul 22 2021 Jan Stan??k  - 0.6.3-1
  - Upgrade to version 0.6.3


Package:  classpathless-compiler-1.4-1.fc35
Old package:  classpathless-compiler-1.3-1.fc35
Summary:  Tool for recompiling java sources with customizable class 
providers
RPMs: classpathless-compiler classpathless-compiler-javadoc
Size: 361.99 KiB
Size change:  20.00 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
1.3-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Thu Jul 22 2021 Marian Koncek  - 1.4-1
  - Update to upstream version 1.4


Package:  composer-2.1.4-1.fc35
Old package:  composer-2.1.3-1.fc35
Summary:  Dependency Manager for PHP
RPMs: composer
Size: 427.74 KiB
Size change:  349 B
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
2.1.3-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Thu Jul 22 2021 Remi Collet  - 2.1.4-1
  - update to 2.1.4
  - raise dependency on justinrainbow/json-schema 5.2.11


Package:  darktable-3.6.0-6.fc35
Old package:  darktable-3.6.0-1.fc35
Summary:  Utility to organize and develop raw images
RPMs: darktable darktable-tools-noise
Size: 11.27 MiB
Size change:  4.48 KiB
Changelog:
  * Tue Jul 06 2021 Germano Massullo  - 3.6.0-2
  - Added appdata.patch

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

[Tomas Orsava]

Btw, if you'd like the details of how this is achieved using alternatives:

The "python" alternative is not actually for /usr/bin/python, but rather
for /usr/bin/unversioned-python, which always exists, and points to either:
- /usr/bin/no-python (default)
- /usr/bin/python3
- /usr/bin/python2

The path /usr/bin/python is added to the alternative definition as a
"slave-link", but only for the /usr/bin/python{2,3} alternative
definitions. So when you enable either Python 2 or Python 3, a slave link
is added by alternatives at /usr/bin/python that points to the same Python
version as /usr/bin/unversioned-python.

Tomas

On Fri, Jul 23, 2021 at 1:36 PM Tomas Orsava  wrote:

> If I understand what you're describing correctly, this is not a bug.
> In the default state, /usr/bin/python should *not* exist, that's correct
> behaviour. If you want it to exist, you need to configure it using
> alternatives [0].
>
> We considered making /usr/bin/python exist but be a noop, but that breaks
> a lot of automated (build) tools that search for Python executables (they
> often start with python, if not found search for python3, or python2, etc.).
> And there was no reasonable default for Python in RHEL 8 because it sits
> between the past (Python 2 default in RHEL 7) and the future (Python3
> default in RHEL 9). Either default would cause problems, often hidden and
> hard to debug problems, for some subset of our customers.
>
> [0]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_configuring-the-unversioned-python_configuring-basic-system-settings
>
> Tomas
>
> On Thu, Jul 22, 2021 at 11:58 PM Troy Dawson  wrote:
>
>>
>>
>> On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok  wrote:
>>
>>> On 22. 07. 21 22:33, Troy Dawson wrote:
>>> >
>>> >
>>> > On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok >> > > wrote:
>>> >
>>> > On 22. 07. 21 21:47, Miro Hrončok wrote:
>>> >  > On 22. 07. 21 21:25, Troy Dawson wrote:
>>> >  >> I've been bitten by this yet again.  A package needing
>>> /usr/bin/python and
>>> >  >> not python2 or python3.  And it's way down in the code so it's
>>> hard to
>>> >  >> patch.  But, it works fine on Fedora.
>>> >  >>
>>> >  >> Is anyone in the middle of porting python-unversioned-command
>>> over to
>>> > epel8?
>>> >  >> If not, does anyone object to me porting it over?
>>> >  >
>>> >  > I wonder how would that package work?
>>> >  >
>>> >  > /usr/bin/python is co-owned by several RHEL-proper packages and
>>> managed by
>>> >  > alternatives.
>>> >
>>> > I hit "Send" to early, apologies, here is the rest of my email:
>>> >
>>> > Could you please share the package spec file with us (Python Maint
>>> team at Red
>>> > Hat, specifically Tomas Orsava and me) before you actually push it
>>> to EPEL, so
>>> > we get a chance to review it (and maybe test it)?
>>> >
>>> >
>>> > On RHEL 8, if there is something that provides /usr/bin/python I can't
>>> find it,
>>> > nor can dnf.
>>> > I've been running RHEL 8 since 8.0, I'm currently at 8.4 and this is
>>> what I have.
>>> >
>>> > # dnf provides '/usr/bin/python'
>>> >Error: No Matches found
>>> > # ls /usr/bin/python
>>> >ls: cannot access '/usr/bin/python': No such file or directory
>>> > # which python
>>> >/usr/bin/which: no python in
>>> > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
>>> >
>>> > On Fedora, it's rather simple, just look at the contents of
>>> > python-unversioned-command
>>> > Two files, no scripts or triggers.
>>> >
>>> > # rpm -ql python-unversioned-command
>>> >/usr/bin/python
>>> >/usr/share/man/man1/python.1.gz
>>> > # ls -lh /usr/bin/python
>>> >lrwxrwxrwx. 1 root root 9 May 18 03:48 /usr/bin/python -> ./python3
>>> > # ls -lh /usr/share/man/man1/python.1.gz
>>> >lrwxrwxrwx. 1 root root 14 May 18 03:48
>>> /usr/share/man/man1/python.1.gz ->
>>> > ./python3.1.gz
>>> >
>>> > It looks like it will be very simple spec file.
>>> > I'll probably just cut it out of the Fedora python spec file.
>>>
>>> On Fedora, it is simple.
>>>
>>> On RHEL 8, it is the opposite of simple.
>>>
>>> The /usr/bin/python file is managed by alternatives but it deliberately
>>> not
>>> owned by any Python package, so `yum install /usr/bin/python` does not
>>> work.
>>>
>>> If the /usr/bin/python file is created/changed by the admin (or by a
>>> package
>>> copied from Fedora), upon (re)installation or upgrade of python2 or
>>> pytohn3{6,8,9} it will be restored based on the alternatives database.
>>>
>>> See the %post sctriplets of the mentioned packages.
>>>
>>>
>> Ugg ... no wonder nobody has done this yet.
>> But, is that working right.  It looks like it should be making a
>> /usr/bin/python pointing to unversioned-python but I don't have any of that.
>> I'm not an Alternatives expert.
>>
>> I guess what I'm really asking is if this is a bug or not?
>> I 

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

[Tomas Orsava]

If I understand what you're describing correctly, this is not a bug.
In the default state, /usr/bin/python should *not* exist, that's correct
behaviour. If you want it to exist, you need to configure it using
alternatives [0].

We considered making /usr/bin/python exist but be a noop, but that breaks a
lot of automated (build) tools that search for Python executables (they
often start with python, if not found search for python3, or python2, etc.).
And there was no reasonable default for Python in RHEL 8 because it sits
between the past (Python 2 default in RHEL 7) and the future (Python3
default in RHEL 9). Either default would cause problems, often hidden and
hard to debug problems, for some subset of our customers.

[0]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_configuring-the-unversioned-python_configuring-basic-system-settings

Tomas

On Thu, Jul 22, 2021 at 11:58 PM Troy Dawson  wrote:

>
>
> On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok  wrote:
>
>> On 22. 07. 21 22:33, Troy Dawson wrote:
>> >
>> >
>> > On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok > > > wrote:
>> >
>> > On 22. 07. 21 21:47, Miro Hrončok wrote:
>> >  > On 22. 07. 21 21:25, Troy Dawson wrote:
>> >  >> I've been bitten by this yet again.  A package needing
>> /usr/bin/python and
>> >  >> not python2 or python3.  And it's way down in the code so it's
>> hard to
>> >  >> patch.  But, it works fine on Fedora.
>> >  >>
>> >  >> Is anyone in the middle of porting python-unversioned-command
>> over to
>> > epel8?
>> >  >> If not, does anyone object to me porting it over?
>> >  >
>> >  > I wonder how would that package work?
>> >  >
>> >  > /usr/bin/python is co-owned by several RHEL-proper packages and
>> managed by
>> >  > alternatives.
>> >
>> > I hit "Send" to early, apologies, here is the rest of my email:
>> >
>> > Could you please share the package spec file with us (Python Maint
>> team at Red
>> > Hat, specifically Tomas Orsava and me) before you actually push it
>> to EPEL, so
>> > we get a chance to review it (and maybe test it)?
>> >
>> >
>> > On RHEL 8, if there is something that provides /usr/bin/python I can't
>> find it,
>> > nor can dnf.
>> > I've been running RHEL 8 since 8.0, I'm currently at 8.4 and this is
>> what I have.
>> >
>> > # dnf provides '/usr/bin/python'
>> >Error: No Matches found
>> > # ls /usr/bin/python
>> >ls: cannot access '/usr/bin/python': No such file or directory
>> > # which python
>> >/usr/bin/which: no python in
>> > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
>> >
>> > On Fedora, it's rather simple, just look at the contents of
>> > python-unversioned-command
>> > Two files, no scripts or triggers.
>> >
>> > # rpm -ql python-unversioned-command
>> >/usr/bin/python
>> >/usr/share/man/man1/python.1.gz
>> > # ls -lh /usr/bin/python
>> >lrwxrwxrwx. 1 root root 9 May 18 03:48 /usr/bin/python -> ./python3
>> > # ls -lh /usr/share/man/man1/python.1.gz
>> >lrwxrwxrwx. 1 root root 14 May 18 03:48
>> /usr/share/man/man1/python.1.gz ->
>> > ./python3.1.gz
>> >
>> > It looks like it will be very simple spec file.
>> > I'll probably just cut it out of the Fedora python spec file.
>>
>> On Fedora, it is simple.
>>
>> On RHEL 8, it is the opposite of simple.
>>
>> The /usr/bin/python file is managed by alternatives but it deliberately
>> not
>> owned by any Python package, so `yum install /usr/bin/python` does not
>> work.
>>
>> If the /usr/bin/python file is created/changed by the admin (or by a
>> package
>> copied from Fedora), upon (re)installation or upgrade of python2 or
>> pytohn3{6,8,9} it will be restored based on the alternatives database.
>>
>> See the %post sctriplets of the mentioned packages.
>>
>>
> Ugg ... no wonder nobody has done this yet.
> But, is that working right.  It looks like it should be making a
> /usr/bin/python pointing to unversioned-python but I don't have any of that.
> I'm not an Alternatives expert.
>
> I guess what I'm really asking is if this is a bug or not?
> I don't have a /usr/bin/python
> I do have a /usr/bin/unversioned-python
> But, what good is that, nothing calls "unversioned-python"
>
> Should I open a bug on this?  Or continue with my plan of making a fix via
> a package?
> Troy
>
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: glibc 2.34 vs firefox in rawhide vs mass build rebuild

[Florian Weimer]

This is now resolved in rawhide.  Thanks to all who have helped to get
us to this point.

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm-ostree cliwrap effort

[Neal Gompa]

On Fri, Jul 23, 2021 at 7:03 AM Colin Walters  wrote:
>
> I was originally thinking of this as a Change, but since it won't be enabled 
> by default, and I think it's most useful to gather feedback from this group 
> first:
>
> See https://coreos.github.io/rpm-ostree/cliwrap/
> This is available since 
> https://github.com/coreos/rpm-ostree/releases/tag/v2021.6
>
> But just for convenience of not following the link, run:
>
> $ rpm-ostree deploy --ex-cliwrap=true
> (And `rpm-ostree ex apply-live` if you want)
>
> I'd like for some people interested in this (particularly ones doing 
> interactive CLI use, e.g. more "pet" systems like desktops) to try this out.  
> Is it useful for your muscle memory to have typing `yum|dnf update` just work 
> for example?  If you forget you're in a host shell and not a container, is 
> the new error message from `dnf install` useful?
>
> Obviously the big change would be flipping this on by default - that'd be the 
> Fedora Change.
>

I think I'd prefer that if you intend to do CLI wrappers, that the
wrapper matches the semantics of the original tools as much as
possible.

That is, "dnf|yum install " should overlay RPMs on the system,
"dnf|yum upgrade" should do the rebase, etc.

However, if you *don't* intend to preserve semantics, then don't
bother doing it *at all* because it'll just lead to confusion. Error
messages are not helpful. It's just better to not have the command at
all in the first place in that circumstance. Imagine how much you'd
break scripts and automation by having something "pretend" to be
DNF/YUM without actually being able to *do* the things people expect
it to do.

> Longer term though, part of the idea here is that I hope by thinking about 
> rpm-ostree as "image based dnf" this way, it also helps drive increase 
> alignment between the two.  For example, around things like:
> https://github.com/rpm-software-management/libdnf/pull/1204#issuecomment-884225903
>
> If you have feedback, here is fine, or in 
> https://github.com/coreos/rpm-ostree/issues/2883
>

I'm not sure this is a useful way to position it, since RPM-OSTree
works completely differently and classes of RPMs don't even work on
the system. Additionally, the emphasis on using OCI images, Flatpaks,
and other non-RPM content instead of native RPM content on these
systems means that "image based dnf" is disingenuous and a potential
source for confusion, since you've been pushing to *avoid* supporting
workflows people do on regular Fedora systems.




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

Allow rpath for mingw-qt5 host tools (yes, really, I suppose...)

[Sandro Mani]

Hi

mingw-qt5-* package ship some host tools for the cross-compiled 
toolchain, installing them to


/usr/$mingw_target/bin

which depend on a bunch of libraries (libQt5Bootstrap.so.5, 
libQt5QmlDevTools.so.5, libQt5BootstrapDBus.so.5), which are installed in


/usr/$mingw_target/lib

These host tools have a rpath set to /usr/$mingw_target/lib, indeed the 
mingw-qt5-qtbase packages carries a patch:


# We have to use rpath for host tools as the library which the various tools
# depend on (libQt5Bootstrap.so) resides in the folder 
/usr/$mingw_target/lib.
# Using the regular %%_libdir would cause conflicts with the native qt5 
packages.

Patch5: qt5-qtbase-build-tools-rpath.patch

(While I'm not sure that the latter sentence is correct (these libraries 
do not exist in native qt5 packages AFAICS), I suppose a valid issue is 
that there is a conflict as there is one of each for each cross target, 
so one in /usr/x86_64-w64-mingw32/lib/ and one in 
/usr/i686-w64-mingw32/lib/ respectively.)


Now, these mingw-qt5-* packages with host tools have started failing to 
build, with the usual rpath error. As I see it, rpath here is actually a 
valid use case, so is there any proper way to have rpmbuild accept 
these? The warning states setting the env-var QA_RPATHS, but this needs 
to be done when invoking rpmbuild itself, which I can't control in koji? 
Or is my above analysis incorrect and can I really do without rpath?


(Note: this problem will disappear with mingw-qt6 as it does not ship 
any host tools anymore).


Thanks
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Bring your Python package to Nest and we'll help you convert it to the new Python macros

[Miro Hrončok]

Hello Fedorans and especially Pythonistas,

The Python Maintenance team from Red Hat just submitted a proposal [1] for a 
hackfest on Nest with Fedora [2].


With the new Python packaging guidelines [3], changes of your spec files are 
necessary to benefit from all the new fancy stuff, such as automatically 
generated build (incl. test) requires, packaging packages that use poetry or 
flit, using tox in %check or semi-automatically generating the %files section.


On this hackfest, we plan to be available for you for half a day either on 
Thursday, August 5 or Friday, August 6. You hop on or hop off to Hopin as 
needed, ask us questions in the chat or via audio/video and we'll try our best 
to help you get started with the new tools and macros.


Please, let the Nest organizers know in the ticket [1] if you are interested, 
so they can make a better decision whether to include this hackfest or not.


See you on Nest either way!

[1] https://pagure.io/flock/issue/346
[2] https://flocktofedora.org/
[3] https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Bring your Python package to Nest and we'll help you convert it to the new Python macros

[Miro Hrončok]

Hello Fedorans and especially Pythonistas,

The Python Maintenance team from Red Hat just submitted a proposal [1] for a 
hackfest on Nest with Fedora [2].


With the new Python packaging guidelines [3], changes of your spec files are 
necessary to benefit from all the new fancy stuff, such as automatically 
generated build (incl. test) requires, packaging packages that use poetry or 
flit, using tox in %check or semi-automatically generating the %files section.


On this hackfest, we plan to be available for you for half a day either on 
Thursday, August 5 or Friday, August 6. You hop on or hop off to Hopin as 
needed, ask us questions in the chat or via audio/video and we'll try our best 
to help you get started with the new tools and macros.


Please, let the Nest organizers know in the ticket [1] if you are interested, 
so they can make a better decision whether to include this hackfest or not.


See you on Nest either way!

[1] https://pagure.io/flock/issue/346
[2] https://flocktofedora.org/
[3] https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20210723.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20210722.0):

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

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

[Bug 1985169] perl-Encode-3.11 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Encode-3.11-479.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-07-23 09:43:45




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Announcement: New major version of mariadb-java-client-3.0.0

[Ondrej Dubaj]

Hi,

today a new major version 3.0.0 of mariadb-java-client landed in
Fedora-Rawhide. This version is not 100% compatible with the previous
version 2.7.3, but it should not affect many applications. The reason for
such an update is, that we want this version to be present in RHEL-9-beta
and according to good packaging manners, it should land in Fedora first.
Currently we have Alpha version release but soon (29.7.2021) Beta version
will be released and later (24.9.2021) also GA.

Details about the changes available here [1].

Regards,
Ondrej

[1] https://mariadb.com/kb/en/mariadb-connector-j-300-release-notes/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210723.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

squashfs-tools being updated in rawhide

[Bruno Wolff III]

Phillip released 4.5 which has some new functionallity, some clean up and 
some bug fixes. It looks like he worked pretty hard on it for about 
the last 6 months. I don't think that the new functionallity will break 
any of our normal stuff, but if something breaks that uses it, that would 
be a good possibility to check out.
The man pages are currently still out of date, but you can use the program's 
help to get up to date documentation.
I had a successfull build after tonight's compose started, so the earliest 
it will show up in rawhide is Saturday morning (in the US), assuming no one 
off rawhide composes.


You can currently get a summary of changes at: 
https://github.com/plougher/squashfs-tools/blob/master/CHANGES

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] 389 DS nightly 2021-07-23 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/07/23/report-389-ds-base-2.0.7-20210723git0f443bf33.fc34.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure