Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Jarryd Lisher via devel]

Hi, I think the response article has one paragraph which is important to this discussion:"Since Fedora Flatpaks converts RPMs from the Fedora repositories to Flatpak applications, it is much easier to trust and audit from a Fedora Project developer and maintainer perspective. Furthermore, these RPMs already comply with all Fedora Project’s conducts and standards. They’re all built inside the Fedora Project’s infrastructure and based on RPMs that are maintained by Fedora Project maintainers. Flathub, on the other hand, is independent and unaffiliated with the Fedora Project. This also makes auditing harder for the Fedora Project maintainers."Which highlights the importance of prioritising Fedora packages over Flathub packages, regardless of whether they are RPMs or Flatpaks. --Jarryd 18:27, 05 July 2022, "Timothée Ravier" :The two articles mentioned above all full of errors and misconceptions about how Flatpak and Flathub works.See https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-future.html___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.orgDo 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

Review swaps

[Jerry James]

I need 2 OCaml package reviews in order to update existing packages to
the most recent versions.

ocaml-camlp-streams: https://bugzilla.redhat.com/show_bug.cgi?id=2104283
ocaml-ppx-import: https://bugzilla.redhat.com/show_bug.cgi?id=2104693

I am willing to swap reviews.  (But note that I am vanishing in a puff
of smoke on Saturday and will be largely incommunicado for about a
week.)
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

ANTLR packages and i686

[Jerry James]

The various ANTLR packages will be impacted by
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs.  The parser
generators, which are written in Java, will no longer be available on
i686.  If absolutely necessary, we could continue to package the
various language runtimes for i686.  That would be a major pain in the
neck.  WIth ANTLR 4 in particular, the version currently in Rawhide
(4.10.1) is not compatible with previous runtimes.  Most of the
consumers we have in Rawhide ship parsers that were generated with
ANTLR 4.6 through 4.9 generators, so they are not compatible with the
4.10.1 runtimes.  (We regenerate the parsers at build time.)
Continuing to support i686 would therefore mean packaging old versions
of the language runtimes, just for i686.

My preference is to stop building everything ANTLR-related on i686.
This has consequences for packages written in C, C++, Go, and OCaml,
at least.  I'll omit Java packages other than the ANTLR packages from
the lists below, since they will disappear from i686 on their own.

Affected packages with maintainers:
- antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could
conceivably keep the C, C++, and JavaScript runtimes if absolutely
necessary
- antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep
the C++, Go, JavaScript, Python3, and Swift runtimes, but see above
- azure-cli (mhayden, @python-sig): needs the Python3 runtime from the
antlr4-project package
- belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package
- coq (amdunn, jjames): needs the Python3 runtime from the
antlr4-project package
- cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package
- flocq (jjames): depends on coq
- frama-c (jjames): depends on why3
- gappalib-coq (jjames): depends on flocq
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel.  Is consumed by a TON of other Go packages,
so many that I did not attempt to trace them.
- ocaml-menhir (jjames): we can remove the coq subpackage only on
i686; it isn't consumed by anything in Fedora
- why3 (jjames): depends on flocq

Packages by maintainer:
@go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc,
numerous consumers of golang-google-grpc
@python-sig: azure-cli
amdunn: coq
brouhaha: cvc4
dchen: antlr3
eclipseo: golang-github-google-cel, golang-google-grpc
jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c,
gappalib-coq, ocaml-menhir, why3
mhayden: antlr4-project, azure-cli
mizdebsk: antlr3
mjakubicek: antlr3
nucleo: belle-sip
sdgathman: belle-sip
walters: antlr3

I am going to be mostly offline starting Saturday, so I intend to deal
with this when I get back, approximately July 18.  That is just before
the mass rebuild, of course.  If anybody has a problem with dropping
i686 builds for the above packages, please come up with a plan to deal
with the situation by then.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-EPEL-2022-6300856c91 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6300856c91

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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 2101193] Please branch and build perl-Authen-DigestMD5 for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Authen-DigestMD5-0.04-
   ||30.el9
 Status|ON_QA   |CLOSED
Last Closed||2022-07-07 01:42:29



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-1b0c6bc22e has been pushed to the Fedora EPEL 9 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.
https://bugzilla.redhat.com/show_bug.cgi?id=2101193
___
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 2100791] Add perl-Perl4-CoreLibs to EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-07-07 01:42:24



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-300cb2b824 has been pushed to the Fedora EPEL 9 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.
https://bugzilla.redhat.com/show_bug.cgi?id=2100791
___
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 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Glen Turner]

I don't believe the technical details are as significant as the
systemtic change to the boundaries of trusted software maintainers.

Consider this comment, which appears to be the core justification:

Michael Catanzaro wrote:
> 
> Flatpaks already take precedence over RPMs, and there are no plans to
> change this for the reasons I mentioned in my previous mail regarding
> sandboxing, which is more important than other considerations.

A sandboxed trojan application is still capable of damaging the user's
security, even if it can't damage the system's security.

To illustrate the difference, a subverted browser can share all credit
card details seen (user's security compromised), but removing that
software removes the subversion (system security not compromised)

A preference order of

  Fedora Flatpak > GNOME Flatpak > Fedora RPM

makes user's security of graphical applications reliant upon a wider
set of trusted software maintainers than

  Fedora Flatpak > Fedora RPM > GNOME Flatpak

Essentially, for graphical applications the change makes Fedora trust
and security processes approach the minimum of of Fedora trust and
security processes and GNOME trust and security processes. That's 
change to the security stance of the distribution which requires
explicit discussion prior to accepting the change.

-glen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2022-02eb71031a has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-02eb71031a


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-e819bfd06e has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-e819bfd06e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-6300856c91 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6300856c91


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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 2102191] Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-404b3fe119 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-404b3fe119


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
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

Spins keepalive

[Gregory Bartholomew]

FESco previously approved a requirement that Spin/Labs owners send a
keepalive request in order to keep building the spin or lab. I have
opened Pagure issues[1] for all Spins and Labs listed on the wiki[2].

If you are the owner of one of those spins and labs, please reply in
the appropriate ticket by 19 July 2022 to indicate the spin should
continue to be produced. If there is a spin or lab that does not have
an open ticket, please create one[3].

The reasoning for this is to not ship spins that are not actively
maintained. Future improvements to the release process that will allow
for teams to self-publish solutions will eventually remove the need
for these keepalives.

[1] 
https://pagure.io/fedora-pgm/schedule/issues?status=Open=spins+keepalive_status=
[2] https://fedoraproject.org/wiki/Releases/37/Spins
[3] https://pagure.io/fedora-pgm/pgm_team/new_issue
___
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

Spins keepalive

[Gregory Bartholomew]

FESco previously approved a requirement that Spin/Labs owners send a
keepalive request in order to keep building the spin or lab. I have
opened Pagure issues[1] for all Spins and Labs listed on the wiki[2].

If you are the owner of one of those spins and labs, please reply in
the appropriate ticket by 19 July 2022 to indicate the spin should
continue to be produced. If there is a spin or lab that does not have
an open ticket, please create one[3].

The reasoning for this is to not ship spins that are not actively
maintained. Future improvements to the release process that will allow
for teams to self-publish solutions will eventually remove the need
for these keepalives.

[1] 
https://pagure.io/fedora-pgm/schedule/issues?status=Open=spins+keepalive_status=
[2] https://fedoraproject.org/wiki/Releases/37/Spins
[3] https://pagure.io/fedora-pgm/pgm_team/new_issue
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Frank Ch. Eigler]

Michael Catanzaro  writes:

> I can point you to documentation for sysprof:
> https://gitlab.gnome.org/GNOME/sysprof#debugging-symbols
> which says that every library should be built with
> -fno-omit-frame-pointer.

Given that sysprof is a userspace program, it's not in a giant rush, so
it should be capable of doing full dwarf unwinding.  The fedora copy of
sysprof is not linked against libunwind, or more modern libraries like
elfutils, but only against glibc's little emergency backtrace()
function.  If sysprof learned to speak elfutils (like the eu-stack
program demonstrates for unwinding), it could also benefit from
debuginfod dwarf auto-downloading as needed.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Jeff Law]

On 7/6/2022 1:05 PM, Florian Weimer wrote:

* Michael Catanzaro:


On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
 wrote:

If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not need or care about.That seems like a
particularly bad cost/benefit for this proposal.

But all Fedora users benefit from performance improvements implemented
as a result of profiling.

I think we have no evidence that you could not get the same results
using Fedora's current profiling tools.  If the GNOME's sysprof does not
work with Fedora, fix it or use something else.  Do not change how
Fedora is built.  It's not really going to work anyway because typical
workloads spent 5% to 10% in glibc's string functions.  Those functions
won't have frame pointers without some non-trivial development work (and
also an ongoing maintenance cost).  If you change compiler flags only,
you still won't get accurate backtraces in many cases.

Yea, it's not a complete solution.



I had some interactions with Red Hat's performance teams over the years,
and to my knowledge, the lack of frame pointers has never come up.
I had some discussions in this space with Peter Z (IIRC) when he was 
still with Red Hat.  We ran into a brick wall with the kernel insistence 
on no dwarf unwinding and the performance impact of keeping frame 
pointers around.  This was the oprofile era IIRC, but the same 
principles apply.


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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> I can point you to documentation for sysprof:
> 
> https://gitlab.gnome.org/GNOME/sysprof#debugging-symbols
> 
> which says that every library should be built with
> -fno-omit-frame-pointer.

And why is that? Do they not use libunwind, or GDB, or any other sane 
(reliable and portable) way to produce backtraces? Why not?

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> Problem is that in order to get good profiling results today, you need
> to rebuild all dependencies with frame pointers enabled. And that is
> not realistic. Nobody does that.

Actually, the Facebook developers, the ones who are proposing this very 
Change, claim that they do exactly that.

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Kofler via devel]

Marek Polacek wrote:

> On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote:
>> (Un)acceptable for whom?
> 
> GCC maintainers in Fedora, at least.

What I do not understand is why a Change that wants to change the default 
GCC flags is even under discussion at all without the buy-in from the GCC 
maintainers. This is a GCC Change and as such IMHO GCC maintainers should be 
the only ones allowed to propose it (or at least, the GCC maintainers' 
approval ought to be a mandatory precondition for proposing it). Without you 
GCC maintainers' buy-in, it should just be summarily rejected.

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Kofler via devel]

Dan Čermák wrote:
> Please never run ASAN in production workloads:
> https://www.openwall.com/lists/oss-security/2016/02/17/9
> 
> tl;dr; you'll create a local root exploit.

Oh, the joys of automagically added insecure environment variable handlers…
Good to know!

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

Re: proposal idea: EOL notifications

[Gary Buhrmaster]

On Wed, Jul 6, 2022 at 3:45 PM Zbigniew Jędrzejewski-Szmek
 wrote:

> https://github.com/systemd/systemd/pull/23924 proposes adding
> SUPPORT_END=-MM-DD to /usr/lib/os-release.

I like the concept, but

(warning, taxonomy discussion)

The announcement for os-release included
the following statement:

   Please prefix your keys with your distribution's
   name however. Or even better: talk to us and
   we might be able update the documentation and
   make your field standard, if you convince us that
   it makes sense.

And while I would prefer the effort to get
the field standardized (perhaps END_OF_SUPPORT=?)
any name in Fedora should be something of
the form REDHAT_ or FEDORA_ I would
probably also prefer the stanza be differently
named (I prefer the term EOL or EOS) but the
important point (to me) is the prefix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: proposal idea: EOL notifications

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
> notification when a Fedora stops being supported. Various proposals
> for online checks were discussed in the bug, but I think we might make
> do with something much simpler.

That will just be perceived as an annoyance. It will not lead to users 
actually upgrading their Fedora any more quickly.

> The advantage of this proposal that it is very simple and will work
> even on machines that don't have network connectivity,

How does EOL matter at all for machines that do not have network 
connectivity? They will not get any updates either way!

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Daan De Meyer via devel]

I've just updated the proposal with an extended description describing the use 
cases enabled by frame pointers in more details. More specifically, on top of 
describing the profiling use case in much more detail, I've also added a 
section on BPF debugging tooling, such as bcc and bpftrace, which will also 
benefit from much more reliable stacktraces if this proposal is implemented.

I've also clarified that we'll also add -mno-omit-leaf-frame-pointer to the 
compiler options. I think this is already implied by -fno-omit-frame-pointer 
for GCC (maybe a GCC expert can correct me if I'm wrong), but it's better to be 
explicit.

Finally, I've added a description of shadow stacks to the alternatives section, 
which are a new hardware feature that might be an option for unwinding in the 
far future, but at the moment lacks widespread support and isn't available in 
the kernel so it's not an option just yet.

Cheers,

Daan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 CoreOS Meeting Minutes 2022-07-06

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-06/fedora_coreos_meeting.2022-07-06-16.30.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-06/fedora_coreos_meeting.2022-07-06-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-06/fedora_coreos_meeting.2022-07-06-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:30:13 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-06/fedora_coreos_meeting.2022-07-06-16.30.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:30:18)

* Action items from last meeting  (dustymabe, 16:33:42)
  * ACTION: jlebon to open investigation tickets for the IMA/FIDO
changes  (dustymabe, 16:35:19)
  * there was an existing ticket for becoming an edition
(https://github.com/coreos/fedora-coreos-tracker/issues/915) and
cverna opened a ticket related to becoming an edition
(https://github.com/coreos/fedora-coreos-tracker/issues/1239).
(dustymabe, 16:36:42)

* New Package Request: Crash  (dustymabe, 16:37:42)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1238
(dustymabe, 16:37:46)
  * AGREED: We don't think including the crash program in Fedora CoreOS
is extremely useful because it needs the kernel-debuginfo packages
in order to do crash dump analysis and you can grab crash at the
same time those packages are downloaded. Though, we do think it
would be useful to document how to do the crashdump analysis from
say a toolbox container.  (dustymabe, 16:54:00)

* installing non-x86_64 emulators  (dustymabe, 16:55:36)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1237
(dustymabe, 16:55:40)
  * AGREED: We included the x86_64 emulator on non-x86_64 architectures
to get access to the large library of containers that are only built
for x86_64 today. We don't think there is a significant enough user
base wanting aarch64/ppc64le/s390x emulators for containers built
just for those architectures (usually if you are building for
aarch64/ppc64le/s390x you are building for all  (dustymabe,
17:09:10)

* tracker: Fedora 37 changes considerations  (dustymabe, 17:09:21)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1222
(dustymabe, 17:09:26)

* open floor  (dustymabe, 17:23:54)

Meeting ended at 17:31:11 UTC.




Action Items

* jlebon to open investigation tickets for the IMA/FIDO changes




Action Items, by person
---
* jlebon
  * jlebon to open investigation tickets for the IMA/FIDO changes
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (110)
* jlebon (30)
* zodbot (19)
* lucab (15)
* jdoss (14)
* jbrooks (7)
* jmarrero (7)
* walters (4)
* gursewak (2)
* ravanelli (1)
* lorbus (1)
* mnguyen (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: proposal idea: EOL notifications

[Dan Čermák]

Hi,

On July 6, 2022 3:44:49 PM UTC, "Zbigniew Jędrzejewski-Szmek" 
 wrote:
>Hi,
>
>In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
>notification when a Fedora stops being supported. Various proposals
>for online checks were discussed in the bug, but I think we might make
>do with something much simpler.
>
>https://github.com/systemd/systemd/pull/23924 proposes adding
>SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
>e.g. pop up a desktop notification when that date is close, and a
>bigger redder notification once it has been passed. The date could be
>set to some initial value even on the initial release, and then
>adjusted through updates to fedora-release.rpm if our schedule slips.
>I guess we could add a notification during boot in systemd itself, but
>most users wouldn't see that, so a graphical notification would also
>be needed.
>
>The advantage of this proposal that it is very simple and will work
>even on machines that don't have network connectivity, and can be easily
>integrated into various DEs and tools.
>
>WDYT?

I like this idea! As long as we never move an eol earlier, I see very little 
potential issues.


Cheers,

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Florian Weimer]

* Michael Catanzaro:

> On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
>  wrote:
>> If I'm understanding things correctly, the original proposal is trying
>> to make a very special case of profiling work better -- a case that
>> 99.9% of Fedora users do not need or care about.That seems like a
>> particularly bad cost/benefit for this proposal.
>
> But all Fedora users benefit from performance improvements implemented
> as a result of profiling.

I think we have no evidence that you could not get the same results
using Fedora's current profiling tools.  If the GNOME's sysprof does not
work with Fedora, fix it or use something else.  Do not change how
Fedora is built.  It's not really going to work anyway because typical
workloads spent 5% to 10% in glibc's string functions.  Those functions
won't have frame pointers without some non-trivial development work (and
also an ongoing maintenance cost).  If you change compiler flags only,
you still won't get accurate backtraces in many cases.

I had some interactions with Red Hat's performance teams over the years,
and to my knowledge, the lack of frame pointers has never come up.

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Florian Weimer]

* Jeff Law:

> If I'm understanding things correctly, the original proposal is trying
> to make a very special case of profiling work better -- a case that 
> 99.9% of Fedora users do not need or care about.    That seems like a
> particularly bad cost/benefit for this proposal.

It became clear during yesterday's meeting that the actual goal is to
enable userspace backtraces that can be analyzed by BPF (in the kernel),
so it's not really about profiling.  Instead it's about enhancing the
capabilities of BPF.  Nobody mentioned this explicitly, but I expect one
could enhance osquery with this and push out BPF-based behavioral
analysis using osquery.  There is already some BPF support in osquery:

  Process and socket auditing with osquery
  

There really should be a way to reach that goal in a more direction,
without having to rebuild the entire distribution with different
compiler flags.

The core issue here is that kernel people boycott both x86 hardware
shadow stacks *and* DWARF, which means that the most obvious approaches
are not available to us.

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

Re: Suggestion: Use a unified kernel image by default in the future.

[Sharpened Blade via devel]

It should be possible to load sd-boot directly, it picks up any kernel in 
/boot/EFI/linux for me. Try loading sd-boot directly from ovmf, skipping grub.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Preset All Systemd Units on First Boot (Self-Contained Change proposal)

[Neal Gompa]

On Wed, Jul 6, 2022 at 2:14 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Preset_All_Systemd_Units_on_First_Boot
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Systemd will execute the equivalent of '''systemctl preset-all''' when
> an unconfigured system is booted
> ([https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20Boot%20Semantics
> "First Boot"] condition). This means that units will be enabled or
> disabled according to the preset configuration. We currently do the
> equivalent of '''systemctl preset-all --preset-mode=enable-only''',
> and this will be extended to also disable units, i.e. '''systemctl
> preset-all --preset-mode=full'''. Any units which are manually
> symlinked but presets say they shouldn't (which is against the
> packaging guidelines for packaged units) will be disabled.
>
> Note that this applies to "first boot" only, i.e. to boot from an
> image without ''/etc'' fully populated. In does not apply to systems
> that were installed using Anaconda.
>
> == Owner ==
> * Name: [[User:jlebon| Jonathan Lebon]]
> * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Email: zbyszek at in.waw.pl, jlebon at redhat.com
>
>
> == Detailed Description ==
> Our 
> [https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
> guidelines] say that units that are packaged in rpms must be enabled
> through macros (''%systemd_post'') and the preset system. Almost all
> packages conform to this, so effectively their enablement state
> follows the preset config. When the system is installed, or more
> precisely when ''systemd.rpm'' is installed, we do ''preset-all''. But
> for historical reasons, when booting an unconfigured system ("first
> boot") we only 'enable' units in this fashion. In Fedora and RHEL
> CoreOS, some symlinks are created in the golden image, but should be
> disabled in the local image after local preset configuration has been
> inserted. To make this work, the call in systemd will be changed to
> execute the equivalent of ''preset-all --preset-mode=full'', making
> enablement during "first boot" more like enablement during an Anaconda
> installation.
>
>
> == Benefit to Fedora ==
> * CoreOS can insert local preset configuration through Ignition and
> this configuration will be applied on the first boot.
> * Users can do something similar with local preset configuration on
> distributed images.
> * The system is made a bit simpler and easier to understand, because
> we can say that "units are enabled/disabled after installation as
> specified by the preset system".
> * Users can call ''systemctl preset-all'' at any time to apply
> preset-configuration. If no local changes to configuration have been
> made, ''preset-all'' would make no changes to unit state. If units
> have been enabled or disabled, ''preset-all'' would return unit
> enablement to the pristine state after installation.
>
> == Scope ==
> * Proposal owners:
> ** implement patch for systemd to configure preset-all mode on first
> boot (https://github.com/systemd/systemd/pull/15205)
> ** build systemd with this mode changed to ''--preset-mode=full''
> ** provide pull requests for two packages which have been identified
> to not use the preset system for enablement to conform to the
> packaging guidelines
> (https://bugzilla.redhat.com/show_bug.cgi?id=2070862,
> https://bugzilla.redhat.com/show_bug.cgi?id=2070726)
>
> * Other developers: review and merge the pull requests
> * Release engineering: N/A
> * Policies and guidelines: none, this change is about following the
> guidelines more closely
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
> == Upgrade/compatibility impact ==
> None.
>
> == How To Test ==
> * On a newly installed system, with arbitrary set of packages: call
> ''systemctl preset-all''. This should result in no changes.
> * On a system which is booted from an unconfigured image (e.g. the new
> Server VM image should qualify, see
> [[Changes/Supplement-server-by-kvm-vm-image]]): before the first boot,
> enable some units manually that are disabled in presets. After
> booting, those units should be disabled again.
>
> == User Experience ==
> In general this change will be a noop for users, because it only
> applies to "first boot", i.e. to the case when a system is booted from
> a distributable image without local configuration and is configured
> when initially booted. In case where Anaconda is used to install
> images, /etc is populated before the first boot and the "first boot"
> condition never applies, thus this change is irrelevant. On systems
> installed from a "golden image" such as Fedora CoreOS, units will
> follow the preset configuration more closely. Thanks to the 

F37 proposal: Preset All Systemd Units on First Boot (Self-Contained Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Systemd will execute the equivalent of '''systemctl preset-all''' when
an unconfigured system is booted
([https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20Boot%20Semantics
"First Boot"] condition). This means that units will be enabled or
disabled according to the preset configuration. We currently do the
equivalent of '''systemctl preset-all --preset-mode=enable-only''',
and this will be extended to also disable units, i.e. '''systemctl
preset-all --preset-mode=full'''. Any units which are manually
symlinked but presets say they shouldn't (which is against the
packaging guidelines for packaged units) will be disabled.

Note that this applies to "first boot" only, i.e. to boot from an
image without ''/etc'' fully populated. In does not apply to systems
that were installed using Anaconda.

== Owner ==
* Name: [[User:jlebon| Jonathan Lebon]]
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl, jlebon at redhat.com


== Detailed Description ==
Our 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
guidelines] say that units that are packaged in rpms must be enabled
through macros (''%systemd_post'') and the preset system. Almost all
packages conform to this, so effectively their enablement state
follows the preset config. When the system is installed, or more
precisely when ''systemd.rpm'' is installed, we do ''preset-all''. But
for historical reasons, when booting an unconfigured system ("first
boot") we only 'enable' units in this fashion. In Fedora and RHEL
CoreOS, some symlinks are created in the golden image, but should be
disabled in the local image after local preset configuration has been
inserted. To make this work, the call in systemd will be changed to
execute the equivalent of ''preset-all --preset-mode=full'', making
enablement during "first boot" more like enablement during an Anaconda
installation.


== Benefit to Fedora ==
* CoreOS can insert local preset configuration through Ignition and
this configuration will be applied on the first boot.
* Users can do something similar with local preset configuration on
distributed images.
* The system is made a bit simpler and easier to understand, because
we can say that "units are enabled/disabled after installation as
specified by the preset system".
* Users can call ''systemctl preset-all'' at any time to apply
preset-configuration. If no local changes to configuration have been
made, ''preset-all'' would make no changes to unit state. If units
have been enabled or disabled, ''preset-all'' would return unit
enablement to the pristine state after installation.

== Scope ==
* Proposal owners:
** implement patch for systemd to configure preset-all mode on first
boot (https://github.com/systemd/systemd/pull/15205)
** build systemd with this mode changed to ''--preset-mode=full''
** provide pull requests for two packages which have been identified
to not use the preset system for enablement to conform to the
packaging guidelines
(https://bugzilla.redhat.com/show_bug.cgi?id=2070862,
https://bugzilla.redhat.com/show_bug.cgi?id=2070726)

* Other developers: review and merge the pull requests
* Release engineering: N/A
* Policies and guidelines: none, this change is about following the
guidelines more closely
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
None.

== How To Test ==
* On a newly installed system, with arbitrary set of packages: call
''systemctl preset-all''. This should result in no changes.
* On a system which is booted from an unconfigured image (e.g. the new
Server VM image should qualify, see
[[Changes/Supplement-server-by-kvm-vm-image]]): before the first boot,
enable some units manually that are disabled in presets. After
booting, those units should be disabled again.

== User Experience ==
In general this change will be a noop for users, because it only
applies to "first boot", i.e. to the case when a system is booted from
a distributable image without local configuration and is configured
when initially booted. In case where Anaconda is used to install
images, /etc is populated before the first boot and the "first boot"
condition never applies, thus this change is irrelevant. On systems
installed from a "golden image" such as Fedora CoreOS, units will
follow the preset configuration more closely. Thanks to the fixes to
make packages conform to packaging guidelines, users can call
'''preset-all''' to return the system to defaults.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Systemd

F37 proposal: Preset All Systemd Units on First Boot (Self-Contained Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Systemd will execute the equivalent of '''systemctl preset-all''' when
an unconfigured system is booted
([https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20Boot%20Semantics
"First Boot"] condition). This means that units will be enabled or
disabled according to the preset configuration. We currently do the
equivalent of '''systemctl preset-all --preset-mode=enable-only''',
and this will be extended to also disable units, i.e. '''systemctl
preset-all --preset-mode=full'''. Any units which are manually
symlinked but presets say they shouldn't (which is against the
packaging guidelines for packaged units) will be disabled.

Note that this applies to "first boot" only, i.e. to boot from an
image without ''/etc'' fully populated. In does not apply to systems
that were installed using Anaconda.

== Owner ==
* Name: [[User:jlebon| Jonathan Lebon]]
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl, jlebon at redhat.com


== Detailed Description ==
Our 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
guidelines] say that units that are packaged in rpms must be enabled
through macros (''%systemd_post'') and the preset system. Almost all
packages conform to this, so effectively their enablement state
follows the preset config. When the system is installed, or more
precisely when ''systemd.rpm'' is installed, we do ''preset-all''. But
for historical reasons, when booting an unconfigured system ("first
boot") we only 'enable' units in this fashion. In Fedora and RHEL
CoreOS, some symlinks are created in the golden image, but should be
disabled in the local image after local preset configuration has been
inserted. To make this work, the call in systemd will be changed to
execute the equivalent of ''preset-all --preset-mode=full'', making
enablement during "first boot" more like enablement during an Anaconda
installation.


== Benefit to Fedora ==
* CoreOS can insert local preset configuration through Ignition and
this configuration will be applied on the first boot.
* Users can do something similar with local preset configuration on
distributed images.
* The system is made a bit simpler and easier to understand, because
we can say that "units are enabled/disabled after installation as
specified by the preset system".
* Users can call ''systemctl preset-all'' at any time to apply
preset-configuration. If no local changes to configuration have been
made, ''preset-all'' would make no changes to unit state. If units
have been enabled or disabled, ''preset-all'' would return unit
enablement to the pristine state after installation.

== Scope ==
* Proposal owners:
** implement patch for systemd to configure preset-all mode on first
boot (https://github.com/systemd/systemd/pull/15205)
** build systemd with this mode changed to ''--preset-mode=full''
** provide pull requests for two packages which have been identified
to not use the preset system for enablement to conform to the
packaging guidelines
(https://bugzilla.redhat.com/show_bug.cgi?id=2070862,
https://bugzilla.redhat.com/show_bug.cgi?id=2070726)

* Other developers: review and merge the pull requests
* Release engineering: N/A
* Policies and guidelines: none, this change is about following the
guidelines more closely
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
None.

== How To Test ==
* On a newly installed system, with arbitrary set of packages: call
''systemctl preset-all''. This should result in no changes.
* On a system which is booted from an unconfigured image (e.g. the new
Server VM image should qualify, see
[[Changes/Supplement-server-by-kvm-vm-image]]): before the first boot,
enable some units manually that are disabled in presets. After
booting, those units should be disabled again.

== User Experience ==
In general this change will be a noop for users, because it only
applies to "first boot", i.e. to the case when a system is booted from
a distributable image without local configuration and is configured
when initially booted. In case where Anaconda is used to install
images, /etc is populated before the first boot and the "first boot"
condition never applies, thus this change is irrelevant. On systems
installed from a "golden image" such as Fedora CoreOS, units will
follow the preset configuration more closely. Thanks to the fixes to
make packages conform to packaging guidelines, users can call
'''preset-all''' to return the system to defaults.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Systemd

Re: proposal idea: EOL notifications

[Ralf Corsépius]

Am 06.07.22 um 17:44 schrieb Zbigniew Jędrzejewski-Szmek:

Hi,

In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
notification when a Fedora stops being supported. Various proposals
for online checks were discussed in the bug, but I think we might make
do with something much simpler.


I am not excited, because I feel it doesn't add any value to Fedora.

I am also concerned about the impact this may have on post-release 
usages of older fedoras and the fedora repos, i.e. to back-track issues 
popping up in newer releases.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Jul 6 2022 at 10:05:17 AM -0700, Tom Stellard 
 wrote:
With the current profiling methods, are you able to at least narrow 
down which libraries
applications spend the most time in?  Or do you really need detailed 
profile information for

every single library in order to determine where the problem is?


Honestly, I'm bad at profiling, so I'm not the best person to answer 
this. :/


I can point you to documentation for sysprof:

https://gitlab.gnome.org/GNOME/sysprof#debugging-symbols

which says that every library should be built with 
-fno-omit-frame-pointer.


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: proposal idea: EOL notifications

[Ben Cotton]

I'm in favor.

I'm not too concerned about updates to the EOL date post-release. Most
people won't be terribly upset if we actually EOL a week or two later
than advertised (now if we EOL before the advertised date, then we
have a problem). This proposal is a good step that doesn't require
much post-release maintenance on our part (and the downsides to
forgetting the post-release maintenance are minimal).

-- 
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: proposal idea: EOL notifications

[Daniel Gonçalves]

Le 2022-07-06 18:04, Ewoud Kohl van Wijngaarden a écrit :

I like the idea. It's very easy to use and because it's offline it
doesn't have any privacy considerations. The service can't be offline
either.


This idea is very elegant for offline systems with estimated SUPPORT_END 
date initially set.
Furthermore for online system it could be as simple as updating a 
package to have the right end of support date.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Tom Stellard]

On 7/6/22 08:42, Michael Catanzaro wrote:

On Wed, Jul 6 2022 at 04:20:50 PM +0100, Jonathan Wakely  
wrote:

You build locally and profile using your locally built packages.


Problem is that in order to get good profiling results today, you need to 
rebuild all dependencies with frame pointers enabled. And that is not 
realistic. Nobody does that.

Developers normally only build what they are working on, not 100 dependencies 
including mesa, glibc, etc.



With the current profiling methods, are you able to at least narrow down which 
libraries
applications spend the most time in?  Or do you really need detailed profile 
information for
every single library in order to determine where the problem is?

-Tom


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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Tom Stellard]

On 7/6/22 08:20, Jonathan Wakely wrote:

On Wed, 6 Jul 2022 at 15:57, Jeff Law  wrote:




On 7/6/2022 8:20 AM, Michael Catanzaro wrote:

On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
 wrote:

If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not need or care about.That seems like a
particularly bad cost/benefit for this proposal.


But all Fedora users benefit from performance improvements implemented
as a result of profiling.

Yes, but, IMHO, you need to find another way to do the profiling you
need to get those improvements.


Right. Developers already need to rebuild packages locally. The
suggestion that developers of fedora packages can't improve those
packages without making system-wide profiling work on every fedora
users' machines seems like nonsense.

Let's say you profile something and find a performance problem. You
tweak the code to improve performance. How do you verify if it
improves performance? Do you push the change to rawhide, wait for koji
and bodhi to do their thing, then re-profile with the new packages
from the updates-testing repo? And if that didn't work, push another
change to rawhide, wait for koji and bodhi, and re-profile? Of course
not, that would be ridiculous.

You build locally and profile using your locally built packages. So
you're already doing rebuilds, and you're already profiling custom
builds anyway. So you can add frame pointers back in to your local
builds that are used for profiling. It's not essential for frame
pointers to be present in the official koji builds for you to do that.
It might be a minor convenience because it reduces the number of
system libs that you need to rebuild locally, but it's just a
convenience, not a necessity.

Maybe we could make it easier to do local mock builds (or copr builds,
or koji scratch builds) with changes to RPM_OPT_FLAGS to simplify
rebuilding to get frame pointers. But pushing that to every user just
so a handful of people don't have a few extra steps is the wrong
trade-off.


I mentioned this in the FESCO meeting, but this proposal[1] is designed
to make these kind of optflag changes easier to do.

-Tom

[1] https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Re: proposal idea: EOL notifications

[Vitaly Zaitsev via devel]

On 06/07/2022 17:44, Zbigniew Jędrzejewski-Szmek wrote:

Inhttps://pagure.io/fesco/issue/2803  Artem asked for a user-visible
notification when a Fedora stops being supported.


+1. I like this idea.

--
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: proposal idea: EOL notifications

[Josh Boyer]

On Wed, Jul 6, 2022 at 12:21 PM Lennart Poettering  wrote:
>
> On Mi, 06.07.22 18:15, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > I'm aware of the release schedule ;)
> > The date would only need to be set (at most) twice:
> > - once before the release of Fn
> > - after Fn+2 is released and Fn has 1 month left
> >   (only if Fn+2 slipped)

Or you could just move to fixed-time lifecycles and avoid that
entirely.  As you said below, what's a week or two? :)

> > And it's true that you will not get the update of the date if no
> > updates are installed… But if you don't update ever, does it really
> > matter that you have the EOL date off by a week or two? This date is
> > meaningful for systems that are _maintained_, i.e. at least get
> > updates every few weeks.

People update systems in odd ways, not always wholesale.  Think of the
common case of "I want CVE fixes only".  There is almost never a CVE
fix for fedora-release, so using that filter will mean they continue
to have stale info.  Anyway, as I said earlier, I don't think these
corner cases are big deals.

We actually already did the overall idea in a different way long ago.
There used to be a package called "system-autodeath" that would
basically start logging impending EOL a week before it happened, then
daily after it happened:

https://koji.fedoraproject.org/koji/buildinfo?buildID=732174

I can't remember why it was retired to be honest.

> Maybe our os-release docs should mention that this is the latest
> *known* support date, and suggest that people refresh the OS to newest
> set of relevant package to get newer info.

Reasonable.  I'd love it if we had a real telemetry service that could
do a bunch of things including this, but I believe the community would
likely reject that so I'm not even going to propose it.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: proposal idea: EOL notifications

[Lennart Poettering]

On Mi, 06.07.22 18:15, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> I'm aware of the release schedule ;)
> The date would only need to be set (at most) twice:
> - once before the release of Fn
> - after Fn+2 is released and Fn has 1 month left
>   (only if Fn+2 slipped)
>
> And it's true that you will not get the update of the date if no
> updates are installed… But if you don't update ever, does it really
> matter that you have the EOL date off by a week or two? This date is
> meaningful for systems that are _maintained_, i.e. at least get
> updates every few weeks.

Maybe our os-release docs should mention that this is the latest
*known* support date, and suggest that people refresh the OS to newest
set of relevant package to get newer info.

Lennart

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

Re: proposal idea: EOL notifications

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 06, 2022 at 11:59:29AM -0400, Josh Boyer wrote:
> On Wed, Jul 6, 2022 at 11:49 AM Neal Gompa  wrote:
> >
> > On Wed, Jul 6, 2022 at 11:45 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > Hi,
> > >
> > > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
> > > notification when a Fedora stops being supported. Various proposals
> > > for online checks were discussed in the bug, but I think we might make
> > > do with something much simpler.
> > >
> > > https://github.com/systemd/systemd/pull/23924 proposes adding
> > > SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
> > > e.g. pop up a desktop notification when that date is close, and a
> > > bigger redder notification once it has been passed. The date could be
> > > set to some initial value even on the initial release, and then
> > > adjusted through updates to fedora-release.rpm if our schedule slips.
> > > I guess we could add a notification during boot in systemd itself, but
> > > most users wouldn't see that, so a graphical notification would also
> > > be needed.
> > >
> > > The advantage of this proposal that it is very simple and will work
> > > even on machines that don't have network connectivity, and can be easily
> > > integrated into various DEs and tools.
> > >
> > > WDYT?
> > >
> >
> > Wouldn't it make sense to have the start date and the time period
> > supported instead?
> 
> Fedora release lifecycles are not date or timeframe driven.  They are
> driven by the N+2 release, which can and does slip which means you
> will have stale information in /etc/os-release every time that
> happens.  Issuing updates to document these slips seems like a lot of
> work for little gain.  Even if you did, disconnected machines also
> wouldn't get updates to this.

I'm aware of the release schedule ;)
The date would only need to be set (at most) twice:
- once before the release of Fn
- after Fn+2 is released and Fn has 1 month left
  (only if Fn+2 slipped)

And it's true that you will not get the update of the date if no
updates are installed… But if you don't update ever, does it really
matter that you have the EOL date off by a week or two? This date is
meaningful for systems that are _maintained_, i.e. at least get
updates every few weeks.

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: proposal idea: EOL notifications

[Ewoud Kohl van Wijngaarden]

On Wed, Jul 06, 2022 at 11:47:21AM -0400, Neal Gompa wrote:

On Wed, Jul 6, 2022 at 11:45 AM Zbigniew Jędrzejewski-Szmek
 wrote:


Hi,

In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
notification when a Fedora stops being supported. Various proposals
for online checks were discussed in the bug, but I think we might make
do with something much simpler.

https://github.com/systemd/systemd/pull/23924 proposes adding
SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
e.g. pop up a desktop notification when that date is close, and a
bigger redder notification once it has been passed. The date could be
set to some initial value even on the initial release, and then
adjusted through updates to fedora-release.rpm if our schedule slips.
I guess we could add a notification during boot in systemd itself, but
most users wouldn't see that, so a graphical notification would also
be needed.

The advantage of this proposal that it is very simple and will work
even on machines that don't have network connectivity, and can be easily
integrated into various DEs and tools.

WDYT?


I like the idea. It's very easy to use and because it's offline it 
doesn't have any privacy considerations. The service can't be offline 
either.



Wouldn't it make sense to have the start date and the time period
supported instead?


It would be more complicated. With an end date you can easily parse it. 
Start date + time period means you need to perform date calculations, 
which is never easy.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: proposal idea: EOL notifications

[Josh Boyer]

On Wed, Jul 6, 2022 at 11:49 AM Neal Gompa  wrote:
>
> On Wed, Jul 6, 2022 at 11:45 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Hi,
> >
> > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
> > notification when a Fedora stops being supported. Various proposals
> > for online checks were discussed in the bug, but I think we might make
> > do with something much simpler.
> >
> > https://github.com/systemd/systemd/pull/23924 proposes adding
> > SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
> > e.g. pop up a desktop notification when that date is close, and a
> > bigger redder notification once it has been passed. The date could be
> > set to some initial value even on the initial release, and then
> > adjusted through updates to fedora-release.rpm if our schedule slips.
> > I guess we could add a notification during boot in systemd itself, but
> > most users wouldn't see that, so a graphical notification would also
> > be needed.
> >
> > The advantage of this proposal that it is very simple and will work
> > even on machines that don't have network connectivity, and can be easily
> > integrated into various DEs and tools.
> >
> > WDYT?
> >
>
> Wouldn't it make sense to have the start date and the time period
> supported instead?

Fedora release lifecycles are not date or timeframe driven.  They are
driven by the N+2 release, which can and does slip which means you
will have stale information in /etc/os-release every time that
happens.  Issuing updates to document these slips seems like a lot of
work for little gain.  Even if you did, disconnected machines also
wouldn't get updates to this.

I really don't think encoding lifecycle information in the
installation itself is the right approach, but it's perhaps the most
tenable one for Fedora.  However, until Fedora definitively moves to
using independent lifecycles for their releases, this is a game of
whack-a-mole.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: proposal idea: EOL notifications

[Neal Gompa]

On Wed, Jul 6, 2022 at 11:45 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
> notification when a Fedora stops being supported. Various proposals
> for online checks were discussed in the bug, but I think we might make
> do with something much simpler.
>
> https://github.com/systemd/systemd/pull/23924 proposes adding
> SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
> e.g. pop up a desktop notification when that date is close, and a
> bigger redder notification once it has been passed. The date could be
> set to some initial value even on the initial release, and then
> adjusted through updates to fedora-release.rpm if our schedule slips.
> I guess we could add a notification during boot in systemd itself, but
> most users wouldn't see that, so a graphical notification would also
> be needed.
>
> The advantage of this proposal that it is very simple and will work
> even on machines that don't have network connectivity, and can be easily
> integrated into various DEs and tools.
>
> WDYT?
>

Wouldn't it make sense to have the start date and the time period
supported instead?



-- 
真実はいつも一つ！/ 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

proposal idea: EOL notifications

[Zbigniew Jędrzejewski-Szmek]

Hi,

In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
notification when a Fedora stops being supported. Various proposals
for online checks were discussed in the bug, but I think we might make
do with something much simpler.

https://github.com/systemd/systemd/pull/23924 proposes adding
SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
e.g. pop up a desktop notification when that date is close, and a
bigger redder notification once it has been passed. The date could be
set to some initial value even on the initial release, and then
adjusted through updates to fedora-release.rpm if our schedule slips.
I guess we could add a notification during boot in systemd itself, but
most users wouldn't see that, so a graphical notification would also
be needed.

The advantage of this proposal that it is very simple and will work
even on machines that don't have network connectivity, and can be easily
integrated into various DEs and tools.

WDYT?

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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Jul 6 2022 at 04:20:50 PM +0100, Jonathan Wakely 
 wrote:

You build locally and profile using your locally built packages.


Problem is that in order to get good profiling results today, you need 
to rebuild all dependencies with frame pointers enabled. And that is 
not realistic. Nobody does that.


Developers normally only build what they are working on, not 100 
dependencies including mesa, glibc, etc.


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: You can't be serious! you want to remove mesa-libGL.i686 support?

[Jonathan Wakely]

On Tue, 5 Jul 2022 at 23:15, Kevin Kofler via devel
 wrote:
>
> Stephen Smoogen wrote:
> > Hyperbole aside, it isn't a joke. Looking at the chain we see a common
> > problem where subversion relies on java-11-openjdk and without it is going
> > to cause a lot of packages to be removed. Either subversion needs to lose
> > that requirement or a lot of packages are going to get removed as failure
> > to build in i686.
> >
> > libglvnd-glx<-mesa-libGL<-libxcb<-doxygen<-git<-subversion<-java-11-
> openjdk-devel
> >
> > This email isn't a comment about it being a good or bad thing.. it is just
> > what is being presented.
>
> I do not see why bogus "bug" reports are filed against a bazillion packages
> when subversion is the only package that needs to be fixed.

In fact just one subpackage of subversion, subversion-javahl.

All the packages (like git) that depend on the main subversion package
are completely unaffected if the subversion-javahl subpackage goes
away on i686.

And even for git, only the git-svn.noarch subpackage has
Requires:subversion. The git package does have
BuildRequires:subversion for the tests but again, it's not the
subversion-javahl subpackage, and will be completely unaffected by
updates to remove subversion-javahl on i686.

AFAICT nothing depends on subversion-javahl and so nothing will be
affected by removing it on i686, and so no packages need to care about
the change to subversion that is already in rawhide.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Jonathan Wakely]

On Wed, 6 Jul 2022 at 15:57, Jeff Law  wrote:
>
>
>
> On 7/6/2022 8:20 AM, Michael Catanzaro wrote:
> > On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
> >  wrote:
> >> If I'm understanding things correctly, the original proposal is trying
> >> to make a very special case of profiling work better -- a case that
> >> 99.9% of Fedora users do not need or care about.That seems like a
> >> particularly bad cost/benefit for this proposal.
> >
> > But all Fedora users benefit from performance improvements implemented
> > as a result of profiling.
> Yes, but, IMHO, you need to find another way to do the profiling you
> need to get those improvements.

Right. Developers already need to rebuild packages locally. The
suggestion that developers of fedora packages can't improve those
packages without making system-wide profiling work on every fedora
users' machines seems like nonsense.

Let's say you profile something and find a performance problem. You
tweak the code to improve performance. How do you verify if it
improves performance? Do you push the change to rawhide, wait for koji
and bodhi to do their thing, then re-profile with the new packages
from the updates-testing repo? And if that didn't work, push another
change to rawhide, wait for koji and bodhi, and re-profile? Of course
not, that would be ridiculous.

You build locally and profile using your locally built packages. So
you're already doing rebuilds, and you're already profiling custom
builds anyway. So you can add frame pointers back in to your local
builds that are used for profiling. It's not essential for frame
pointers to be present in the official koji builds for you to do that.
It might be a minor convenience because it reduces the number of
system libs that you need to rebuild locally, but it's just a
convenience, not a necessity.

Maybe we could make it easier to do local mock builds (or copr builds,
or koji scratch builds) with changes to RPM_OPT_FLAGS to simplify
rebuilding to get frame pointers. But pushing that to every user just
so a handful of people don't have a few extra steps is the wrong
trade-off.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Suggestion: Use a unified kernel image by default in the future.

[Lennart Poettering]

On Mi, 06.07.22 16:13, Gerd Hoffmann (kra...@redhat.com) wrote:

> grub2 doesn't find it.  Support not implemented?

afics grub2 upstream has no native support for boot loader spec
stuff. (or has that changed?)

The fedora version of grub2 implements a flavour of type #1 boot loader spec
entries (i.e. .conf entries), but not type #2 (i.e. unified kernels), iirc.

> Ok, lets try systemd-boot instead.  Install.
> Chainload from grub for now:
>
> root@fedora ~/mkosi-initrd (main)# cat /boot/grub2/custom.cfg
> if [ "$grub_platform" = "efi" ]; then
>   menuentry 'systemd boot loader' {
>   chainloader (hd0,gpt1)/efi/systemd/systemd-bootx64.efi
>   }
> fi
>
> systemd-boot doesn't find it either.  Double-checking.  ESP mounted at
> /boot/efi.  Directory looks fine to me:
>
> root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux
> total 77832
> -rwx--. 1 root root 79698816 Jul  6 15:36 
> unified-5.18.9-200.fc36.x86_64.efi
>
> Any clues?

I am not a grub guy, haven't used it in a long time. But my educated
guess is this: I think grub might load the chainloaded binary into
memory itself, and then execute it from there, instead of invoking it
directly from the ESP file system. This matters because if sd-boot is
invoked from a synthetic file in memory we cannot derive the directory
tree of the ESP from it, and thus not find boot loader entries.

Lennart

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 06/07/2022 16:20, Michael Catanzaro wrote:
But all Fedora users benefit from performance improvements implemented 
as a result of profiling.


I don't think so. Only the proposal owners will get benefit.

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

Looking for a review swap for an easy review, fuse2fs for epel7

[Dave Dykstra via devel]

I am looking for someone to review adding fuse2fs to only epel7:
https://bugzilla.redhat.com/show_bug.cgi?id=2104533
It is already a standard part of e2fsprogs everywhere else.

Let me know what you would like me to review in return.

Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Jeff Law]

On 7/6/2022 8:20 AM, Michael Catanzaro wrote:
On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law 
 wrote:

If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not need or care about.    That seems like a
particularly bad cost/benefit for this proposal.


But all Fedora users benefit from performance improvements implemented 
as a result of profiling.
Yes, but, IMHO, you need to find another way to do the profiling you 
need to get those improvements.


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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law 
 wrote:

If I'm understanding things correctly, the original proposal is trying
to make a very special case of profiling work better -- a case that
99.9% of Fedora users do not need or care about.That seems like a
particularly bad cost/benefit for this proposal.


But all Fedora users benefit from performance improvements implemented 
as a result of profiling.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Suggestion: Use a unified kernel image by default in the future.

[Gerd Hoffmann]

On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
> 
> Hmm.  Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state.  mkosi going fetch stuff from the
> internet to generate the initrd is clearly a non-starter (maybe not that
> much of a problem when doing it in koji where the next fedora repo is
> only one network hop away).

A few experiments later.  Using 'mkosi --use-host-repositories' greatly
improves the situation.  mkosi picks up the local repo config then and
fetches stuff from my local mirror.

Going build unified kernel image (using 'man systemd-stub'
instructions):

# build unified kernel
echo "Unified Linux Kernel ${KVER}" > os-release
objcopy --add-section .osrel=os-release \
--add-section .cmdline=/proc/cmdline \
--add-section .linux=/boot/vmlinuz-${KVER} \
--add-section .initrd=initrd_${KVER}.cpio.zstd \
\
--change-section-vma .osrel=0x2 \
--change-section-vma .cmdline=0x3 \
--change-section-vma .linux=0x200 \
--change-section-vma .initrd=0x300 \
\
/usr/lib/systemd/boot/efi/linuxx64.efi.stub \
/boot/efi/EFI/Linux/unified-${KVER}.efi

Booting that directly from the ovmf firmware menu works fine.
Progress!

grub2 doesn't find it.  Support not implemented?

Ok, lets try systemd-boot instead.  Install.
Chainload from grub for now:

root@fedora ~/mkosi-initrd (main)# cat /boot/grub2/custom.cfg 
if [ "$grub_platform" = "efi" ]; then
menuentry 'systemd boot loader' {
chainloader (hd0,gpt1)/efi/systemd/systemd-bootx64.efi
}
fi

systemd-boot doesn't find it either.  Double-checking.  ESP mounted at
/boot/efi.  Directory looks fine to me:

root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux
total 77832
-rwx--. 1 root root 79698816 Jul  6 15:36 unified-5.18.9-200.fc36.x86_64.efi

Any clues?

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

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Dusty Mabe]

On 7/6/22 04:37, Lennart Poettering wrote:
> On Di, 05.07.22 22:35, Dusty Mabe (du...@dustymabe.com) wrote:
> 
>> On 6/25/22 15:06, Vipul Siddharth wrote:
>>> This document represents a proposed Change. As part of the Changes
>>> process, proposals are publicly announced in order to receive
>>> community feedback. This proposal will only be implemented if approved
>>> by the Fedora Engineering Steering Committee.
>>>
>>>
>>> == Summary ==
>>>
>>> The `systemd-udev` package installs
>>> `"/usr/lib/systemd/network/99-default.link"`,
>>> which sets `Link.MACAddressPolicy=persistent`. This proposal is to
>>> change it to set `Link.MACAddressPolicy=none` to stop changing the MAC 
>>> address.
>>> This is particularly important for bridge and bond devices.
>>>
>>> This change can either only apply to bridge/bond devices, or to
>>> various software devices. That is to be discussed.
>>
>> Based on the feedback here on the list we have modified the scope of this 
>> proposal
>> to now be limited to changing the MACAddressPolicy=none for bond/bridge/team 
>> devices only.
>>
>> New summary:
>>
>> ```
>> The systemd-udev package installs 
>> "/usr/lib/systemd/network/99-default.link", which sets 
>> Link.MACAddressPolicy=persistent for all software NIC devices. This proposal 
>> is to add to the policy so that we use Link.MACAddressPolicy=none for 
>> bond/bridge/team devices.
>> ```
>>
>> https://fedoraproject.org/wiki/Changes/MAC_Address_Policy_none
> 
> So, with changing this back you'll also break all those setups where
> it is assumed the bridge MAC just works and is stable and independent
> from the devices added to it and the order in which they are added in.

One thing we do need to think about here is the "upgrade" case. We could
consider leaving existing (upgrading) systems alone.

> 
> What makes you so sure, that changing this *again* is so much better
> than just leaving it the way it is now? This change isn't precisely
> new, and changing stuff forth and back comes at quite a price.

Indeed it does come at a price, which is why we're discussing the merits
here and also why we scaled back the proposal to just cover the use case
where it matters the most. For example, this kernel documentation is a good
place where a user is now confused because the kernel behaves one way for
bonds, but systemd delivers configuration to make it behave differently:
https://wiki.linuxfoundation.org/networking/bonding#where_does_a_bonding_device_get_its_mac_address_from

If you look at the longer term landscape (i.e. years from now) the change
is worth it if it's the right change to make. I think the fact that RHEL9
didn't pick up the original change is an indication of it's value in enterprise
environments where bond/bridge/team devices are more common.

> 
> Generally, if we change behaviour like this, then the pros must
> seriously outweight the cons. Now you might argue that when the
> original change was made that wasn't the case, that's a valid opinion,
> though one I disagree with. But that has no effect on today, on the
> question whether changing it again is worth it. I am pretty sure that
> there are *also* numerous scripts that benefit from the predictability
> and stability you get with the status quo, and which you'll break if
> you revert to the old state – again.

There is a lot that happens upstream systemd that we should more carefully
consider in Fedora. For example this probably should have been proposed to
Fedora as a change then (by systemd maintainer in Fedora I suspect) and the
merits examined at that point in time.

> 
> I am not convinced we should flip flop on this all the time. Yes, it's
> unfortunate that people tripped over this, but you are not really
> making it better if you then break it *again*, given the benefit is
> unclear, and the major software creating bridges/bonds/… doesn't care
> anyway (i.e. NM, networkd, …).

This definitely affects NetworkManager and people do care.. See
https://github.com/coreos/fedora-coreos-tracker/issues/919
https://github.com/systemd/systemd/issues/15208

> 
> I for one do not see where you'd get the crystal ball to look into to
> know that by changing this *again* you'll make bazillions of people
> happy, and only very few people sad, because you break their stuff. It
> might very well be that you'll make more people sad because you break
> their stuff again, than were happy before.

The discussion here is one way to gather feedback. There is also the collective
expertise of the members of FESCO, who make decisions like this all the time. 

> 
> Also, let's not forget that allowing users to set the policy is a good
> thing, we should let them. Given that the original change was already
> made a lot of software that cannot work with such changes has already
> been updated to override the default policy. That's a good thing,
> since the overall system becomes more robust and people can more
> safely change the policies locally, with less breakage to 

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Jul 6 2022 at 09:26:44 AM -0400, Marek Polacek 
 wrote:

I think you may be underestimating how much even 1% matters.


For Fedora Workstation, the primary concern should be to make sure 
sysprof works nicely. That's our profiling tool, and it currently 
doesn't work well at all with Fedora binaries due to lack of frame 
pointers. The best way to improve the performance of Fedora 
applications is currently to profile upstream binaries instead, which 
is awkward and disappointing.


I don't understand the technical details here and I will not take a 
position on what flags we use, but I'm concerned the goals here seem 
misplaced. We should surely accept a much bigger performance hit than 
1% if it improves developer experience and facilitates profiling, since 
profiling allows us to make performance improvements that are orders of 
magnitude larger than 1%. Please find some way to make sysprof work 
well. Currently that requires frame pointers.


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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Jeff Law]

On 7/6/2022 7:26 AM, Marek Polacek wrote:

On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote:

On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek  wrote:


Maybe not, but even ~1% is still an unacceptable slowdown.  It would take
about a year for the compiler to catch up.



(Un)acceptable for whom?

GCC maintainers in Fedora, at least.


And why would it be unacceptable?

Because it's too much.


You just said compilers will make up for it quickly, not to mention
hardware continuously getting faster too...

Dozens of developers working a whole release (if not more) is not quick.
  

I haven't seen any convincing arguments as to why such a small
drop would be the end of the world.

And likewise, I haven't seen how this proposal would be helpful to the
majority of users, nevermind that it'd likely break programs using
inline assembly that use %rbp.  But others have already raised similar
points in this thread.
  

And I don't think Fedora is or should be used in high-speed trading or
similar
environments where every microsecond matters.

I think you may be underestimating how much even 1% matters.
Amen.  A 1% hit is very significant -- as Marek indicated, that's 
roughly a year of work for the GCC community to recover.


Sometimes we're willing to take a 1% hit, sometimes not.  It's a 
question of balancing the performance hit against the benefits of 
whatever change is being considered.


If I'm understanding things correctly, the original proposal is trying 
to make a very special case of profiling work better -- a case that 
99.9% of Fedora users do not need or care about.    That seems like a 
particularly bad cost/benefit for this proposal.


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

OT: triggered Re: You can't be serious! you want to remove mesa-libGL.i686 support?

[stan via devel]

On Wed, 6 Jul 2022 07:59:08 -0400
Stephen Smoogen  wrote:

> Thank you for your pointers. I have reflected on my original email and
> agree I made several mistakes in that email:
> I did not know the size of the bug problem.
> I did not investigate why the bugs were filed.
> I approached this as a one off versus a systematic problem.
> I did not help people who were affected by this in a forward moving
> way.

This reminds me too much of those old videos of the cultural revolution
when the bourgeoisie in China wore signs around their neck confessing
their crimes, while being berated by the proletariat (the communist /
Maoist true believers). I think this is a bad thing for a community like
Fedora. Isn't a simple apology or acknowledgement of error enough?

Maybe I'm reading too much into it, or it is satire?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Retired: python-contextlib2

[Ali Erdinc Koroglu]

Dear maintainers,
I have retired python-contextlib2 on rawhide, for details please read 
the link.


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

BR,
Ali
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Marek Polacek]

On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote:
> On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek  wrote:
> 
> >
> > Maybe not, but even ~1% is still an unacceptable slowdown.  It would take
> > about a year for the compiler to catch up.
> >
> >
> (Un)acceptable for whom?

GCC maintainers in Fedora, at least.

> And why would it be unacceptable?

Because it's too much.

> You just said compilers will make up for it quickly, not to mention
> hardware continuously getting faster too...

Dozens of developers working a whole release (if not more) is not quick.
 
> I haven't seen any convincing arguments as to why such a small
> drop would be the end of the world.

And likewise, I haven't seen how this proposal would be helpful to the
majority of users, nevermind that it'd likely break programs using
inline assembly that use %rbp.  But others have already raised similar
points in this thread.
 
> And I don't think Fedora is or should be used in high-speed trading or
> similar
> environments where every microsecond matters.

I think you may be underestimating how much even 1% matters.

Marek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Anyone want to review swap? (rocm-opencl)

[Jeremy Newton]

Thanks Luya! I've landed rocm-opencl in rawhide, with epel8/9 and Fedora 36 
pending :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Request for fence-agents-pve package

[Alex Talaran]

i can give it a shot but not sure i am the best for long term 
maintainer. happy to test and share diffs if i get to them too. i cant 
test more than the pve package for what its worth.


On 2022-06-29 15:02, Carl George wrote:

Correct, a fence-agents-epel package is probably the best choice here.
Are you interested in creating and maintaining that?  It's described
in further detail in the EPEL docs [0], although it's lacking
examples.

[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/

On Tue, Jun 21, 2022 at 9:15 AM Alex Talaran  wrote:


Carl,

it looks like this will not be included in centos stream per RH. so
looks like option 2 or 3 would be next right? to help the greater
community 3 might be better since other agents are missing too.

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

On 2022-06-17 16:28, Carl George wrote:

On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran  wrote:


would anyone be willing to package this in epel or help get it in the
existing package please?

i asked on bugzilla [1] but the current maintainer isnt able to help at
the moment. from what i can tell it might just need uncommented in the
spec file [2]. someone else asked about it [1][3] and the ownership is
being thrown back and forth between epel and rhel.


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

[2]
https://github.com/ClusterLabs/fence-agents/blob/main/fence-agents.spec.in#L33

[3]
https://github.com/ClusterLabs/fence-agents/issues/456
___
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


In Fedora fence-agents-pve is a subpackage of fence-agents.
fence-agents is in RHEL, so the Fedora package cannot be branched
as-is for EPEL.  Some possible alternatives:

- Open a CentOS Stream bugzilla and request that fence-agents-pve be
added to the fence-agents spec file.  If the maintainer agrees, it
will show up in the next RHEL minor release ("next" being contingent
on timing).  This is the ideal solution from a packaging perspective
but has a fair chance of being declined if RHEL doesn't want to
ship/support that subpackage.
- Create a stand-alone fence-agents-pve package, and get it reviewed
as an EPEL-only package.  That would be allowed in EPEL because
neither the srpm or rpm name would conflict with RHEL.
- Create a fence-agents-epel package that contains all the subpackages
that are disabled in the RHEL spec file.  Similar to the previous
option, this would be EPEL-only and would be allowed because the srpm
and rpm names don't conflict with RHEL.
- Rebuild the Fedora spec file with all subpackages somewhere where
replacing base packages is allowed, such as a copr or a CentOS SIG.


___
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





___
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: You can't be serious! you want to remove mesa-libGL.i686 support?

[Stephen Smoogen]

On Tue, 5 Jul 2022 at 18:16, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Stephen Smoogen wrote:
> > Hyperbole aside, it isn't a joke. Looking at the chain we see a common
> > problem where subversion relies on java-11-openjdk and without it is
> going
> > to cause a lot of packages to be removed. Either subversion needs to lose
> > that requirement or a lot of packages are going to get removed as failure
> > to build in i686.
> >
> > libglvnd-glx<-mesa-libGL<-libxcb<-doxygen<-git<-subversion<-java-11-
> openjdk-devel
> >
> > This email isn't a comment about it being a good or bad thing.. it is
> just
> > what is being presented.
>
> I do not see why bogus "bug" reports are filed against a bazillion
> packages
> when subversion is the only package that needs to be fixed.
>
>
Thank you for your pointers. I have reflected on my original email and
agree I made several mistakes in that email:
I did not know the size of the bug problem.
I did not investigate why the bugs were filed.
I approached this as a one off versus a systematic problem.
I did not help people who were affected by this in a forward moving way.



> File a bug against subversion, put it on the release blocker tracker, and
> do
> not waste everyone else's time.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: planning to orphan python-django (and a couple of dependent packages) + potentially more

[Ali Erdinc Koroglu]

Hello, I can take the rest thank you.

FAS: aekoroglu

On 06/07/2022 11:50, Simon de Vlieger wrote:

you may or may not know, I have been maintaining python-django for quite
some time in the past, some time as part of my job. My role changed and
I really can not dedicate Django the time it deserves. I am looking for
someone or persons willing to take

- python-django
- python-django-angular
- python-django-appconf
- python-django-authority
- python-django-compressor
- python-django-contact-form
- python-django-debug-toolbar
- python-django-haystack
- python-django-mptt
- python-django-nose
- python-django-notification
- python-django-pagination
- python-django-pipeline
- python-django-piston
- python-django-pyscss
- python-django-rest-framework
- python-django-reversion
- python-django-robots
- python-django-tables2
- python-django-tagging


I'm going to orphan the packages mid July. Ideally we'd find takers before?
If you are interested and able to maintain (any) of these packages,
please send me your FAS name and package(s) to maintain.

I don't know if I can apply as I am a relatively new maintainer but I'd like to
help out by taking over the following packages:

- python-django-robots
- python-django-pagination
- python-django-contact-form

My FAS username is: `supakeen`.


-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20220706.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 56/236 (x86_64), 15/165 (aarch64)

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

ID: 1316546 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1316546
ID: 1316548 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1316548
ID: 1316640 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1316640
ID: 1316641 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1316641
ID: 1316702 Test: aarch64 Workstation-raw_xz-raw.xz help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1316702
ID: 1316716 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1316716
ID: 1316742 Test: aarch64 Workstation-upgrade clocks@uefi
URL: https://openqa.fedoraproject.org/tests/1316742
ID: 1316744 Test: aarch64 Workstation-upgrade help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1316744
ID: 1316749 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1316749
ID: 1316825 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1316825

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

ID: 1316538 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1316538
ID: 1316566 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1316566
ID: 1316567 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1316567
ID: 1316581 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1316581
ID: 1316585 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1316585
ID: 1316593 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1316593
ID: 1316594 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1316594
ID: 1316601 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1316601
ID: 1316607 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/1316607
ID: 1316608 Test: x86_64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1316608
ID: 1316609 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/1316609
ID: 1316610 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1316610
ID: 1316611 Test: x86_64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/1316611
ID: 1316612 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/1316612
ID: 1316613 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/1316613
ID: 1316615 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1316615
ID: 1316627 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1316627
ID: 1316628 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1316628
ID: 1316671 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1316671
ID: 1316690 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1316690
ID: 1316694 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1316694
ID: 1316729 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1316729
ID: 1316733 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1316733
ID: 1316745 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1316745
ID: 1316753 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1316753
ID: 1316754 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1316754
ID: 1316786 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1316786
ID: 1316814 Test: 

Re: planning to orphan python-django (and a couple of dependent packages) + potentially more

[Matthias Runge]

On 06/07/2022 10:50, Simon de Vlieger wrote:



I don't know if I can apply as I am a relatively new maintainer but I'd like to
help out by taking over the following packages:

- python-django-robots
- python-django-pagination
- python-django-contact-form

My FAS username is: `supakeen`.


Hi Simon,

thank you for stepping up! I just handed these packages over.

Matthias
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Neal Gompa]

On Wed, Jul 6, 2022 at 2:49 AM Peter Boy  wrote:
>
> I very much appreciate the work to support the various SBC devices like 
> Raspberry Pi and workalikes. But I'm a little lost with this proposal.
>
> > Am 05.07.2022 um 23:16 schrieb Ben Cotton :
> > The work around Raspberry Pi 4 has been on going for a number of
> > years, but we've never officially supported it due to lack of
> > accelerated graphics and other key features. A few of us have led the
> > push to get the accelerated graphics work over the line upstream so it
> > now makes sense to enable this in Fedora and make support for the
> > Raspberry Pi 4 more official.
>
> Why Raspberry Pi, and that as the only model from the large number of 
> comparable devices?
>
> Why not other devices, whose makers - as far as I understood the discussion - 
> are far more OSS friendly or e.g. explicitly name Fedora as a recommended 
> operating system?
>
> I know, Raspberry Pi is very popular. But this looks to me a bit like Fedora, 
> the proverbial uninvited guest shouting "me too" from his corner.
>

Because one of the biggest complaints we get about Fedora ARM is that
it *doesn't* work. It was even featured in a recent podcast as a
severe problem with Fedora. The Raspberry Pi is the only mass produced
ARM device everyone can get their hands on *everywhere* (when in
stock). The device has penetrated the public consciousness in a way
nothing else has.

And make no mistake, *all* SBCs are not very good at being OSS
friendly, even *if* they mention Fedora by name. Vendors generally do
not care about mainline support, and it's usually up to *someone else*
to get it done. The Raspberry Pi has the benefit of visibility, so
people try very hard to get it done.



--
真実はいつも一つ！/ 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

[Bug 2104311] Please build perl-Test-CheckDeps for EPEL 9

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

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



--- Comment #1 from Paul Howarth  ---
https://pagure.io/releng/fedora-scm-requests/issue/45523


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2104311
___
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

Fedora-Cloud-35-20220706.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-35-20220705.0):

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

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

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Dan Čermák]

Kevin Kofler via devel  writes:

> Fabio Valentini wrote:
>> And if we say this argument is valid, then should we also build all our
>> packages with ASAN / TSAN / etc. instrumentation, as well?
>
> And ASAN would actually have tangible benefits for end users, namely 
> preventing some memory bug exploits, whereas frame pointers only slow things 
> down and are of no use whatsoever for non-developer users (and even most 
> developers).

Please never run ASAN in production workloads:
https://www.openwall.com/lists/oss-security/2016/02/17/9

tl;dr; you'll create a local root exploit.



Cheers,

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

Re: planning to orphan python-django (and a couple of dependent packages) + potentially more

[Simon de Vlieger]

Hey Matthias,

On Wed, Jul 6, 2022, at 9:29 AM, Matthias Runge wrote:
> On 19/04/2022 15:00, Matthias Runge wrote:
>> Hello there,
>> 
>
> Re-iterating on this email, also including de...@lists.fp.o
>
>> you may or may not know, I have been maintaining python-django for quite 
>> some time in the past, some time as part of my job. My role changed and 
>> I really can not dedicate Django the time it deserves. I am looking for 
>> someone or persons willing to take
>> 
>> - python-django
>> - python-django-angular
>> - python-django-appconf
>> - python-django-authority
>> - python-django-compressor
>> - python-django-contact-form
>> - python-django-debug-toolbar
>> - python-django-haystack
>> - python-django-mptt
>> - python-django-nose
>> - python-django-notification
>> - python-django-pagination
>> - python-django-pipeline
>> - python-django-piston
>> - python-django-pyscss
>> - python-django-rest-framework
>> - python-django-reversion
>> - python-django-robots
>> - python-django-tables2
>> - python-django-tagging
>
>
> I'm going to orphan the packages mid July. Ideally we'd find takers before?
> If you are interested and able to maintain (any) of these packages, 
> please send me your FAS name and package(s) to maintain.

I don't know if I can apply as I am a relatively new maintainer but I'd like to
help out by taking over the following packages:

- python-django-robots
- python-django-pagination
- python-django-contact-form

My FAS username is: `supakeen`.

> Thank you,
> Matthias
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Lennart Poettering]

On Di, 05.07.22 22:35, Dusty Mabe (du...@dustymabe.com) wrote:

> On 6/25/22 15:06, Vipul Siddharth wrote:
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> >
> > == Summary ==
> >
> > The `systemd-udev` package installs
> > `"/usr/lib/systemd/network/99-default.link"`,
> > which sets `Link.MACAddressPolicy=persistent`. This proposal is to
> > change it to set `Link.MACAddressPolicy=none` to stop changing the MAC 
> > address.
> > This is particularly important for bridge and bond devices.
> >
> > This change can either only apply to bridge/bond devices, or to
> > various software devices. That is to be discussed.
>
> Based on the feedback here on the list we have modified the scope of this 
> proposal
> to now be limited to changing the MACAddressPolicy=none for bond/bridge/team 
> devices only.
>
> New summary:
>
> ```
> The systemd-udev package installs "/usr/lib/systemd/network/99-default.link", 
> which sets Link.MACAddressPolicy=persistent for all software NIC devices. 
> This proposal is to add to the policy so that we use 
> Link.MACAddressPolicy=none for bond/bridge/team devices.
> ```
>
> https://fedoraproject.org/wiki/Changes/MAC_Address_Policy_none

So, with changing this back you'll also break all those setups where
it is assumed the bridge MAC just works and is stable and independent
from the devices added to it and the order in which they are added in.

What makes you so sure, that changing this *again* is so much better
than just leaving it the way it is now? This change isn't precisely
new, and changing stuff forth and back comes at quite a price.

Generally, if we change behaviour like this, then the pros must
seriously outweight the cons. Now you might argue that when the
original change was made that wasn't the case, that's a valid opinion,
though one I disagree with. But that has no effect on today, on the
question whether changing it again is worth it. I am pretty sure that
there are *also* numerous scripts that benefit from the predictability
and stability you get with the status quo, and which you'll break if
you revert to the old state – again.

I am not convinced we should flip flop on this all the time. Yes, it's
unfortunate that people tripped over this, but you are not really
making it better if you then break it *again*, given the benefit is
unclear, and the major software creating bridges/bonds/… doesn't care
anyway (i.e. NM, networkd, …).

I for one do not see where you'd get the crystal ball to look into to
know that by changing this *again* you'll make bazillions of people
happy, and only very few people sad, because you break their stuff. It
might very well be that you'll make more people sad because you break
their stuff again, than were happy before.

Also, let's not forget that allowing users to set the policy is a good
thing, we should let them. Given that the original change was already
made a lot of software that cannot work with such changes has already
been updated to override the default policy. That's a good thing,
since the overall system becomes more robust and people can more
safely change the policies locally, with less breakage to expect.

if you now revert to the status quo ante, then you basically also say:
fuck it, we don't care that software is fixed to work with changed
policies, let's keep things brittle that you cannot change policies
anymore effectively because we are sticking our head in the sand and
don't care that they are fixed.

So, I am not convinced.

I can accept that this wasn't handled particularly nicely
originally. My proposal for addressing this is via documentation, i.e
update the udev and iproute docs to explicitly point to the issue and
how to deal with it, with an example drop-in to make it easy to deal
with it.

Lennart

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

Re: Bugzilla Assignee

[Jamie Nguyen]

Miro Hrončok wrot
Done. But maybe the Fedora maintainers were never interested in EPEL? 
Should the assignee be set to orphan instead?


Thanks Miro!

The main assignees for both packages have pushed EPEL builds before, so 
they have at least had interest in the past.


--
Jamie Nguyen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-36-20220706.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-36-20220705.0):

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

Passed openQA tests: 7/8 (aarch64), 7/8 (x86_64)

New passes (same test not passed in Fedora-Cloud-36-20220705.0):

ID: 1316923 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1316923
-- 
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

Re: planning to orphan python-django (and a couple of dependent packages) + potentially more

[Matthias Runge]

On 19/04/2022 15:00, Matthias Runge wrote:

Hello there,



Re-iterating on this email, also including de...@lists.fp.o

you may or may not know, I have been maintaining python-django for quite 
some time in the past, some time as part of my job. My role changed and 
I really can not dedicate Django the time it deserves. I am looking for 
someone or persons willing to take


- python-django
- python-django-angular
- python-django-appconf
- python-django-authority
- python-django-compressor
- python-django-contact-form
- python-django-debug-toolbar
- python-django-haystack
- python-django-mptt
- python-django-nose
- python-django-notification
- python-django-pagination
- python-django-pipeline
- python-django-piston
- python-django-pyscss
- python-django-rest-framework
- python-django-reversion
- python-django-robots
- python-django-tables2
- python-django-tagging



I'm going to orphan the packages mid July. Ideally we'd find takers before?
If you are interested and able to maintain (any) of these packages, 
please send me your FAS name and package(s) to maintain.


Thank you,
Matthias
___
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: planning to orphan python-django (and a couple of dependent packages) + potentially more

[Matthias Runge]

On 19/04/2022 15:00, Matthias Runge wrote:

Hello there,



Re-iterating on this email, also including de...@lists.fp.o

you may or may not know, I have been maintaining python-django for quite 
some time in the past, some time as part of my job. My role changed and 
I really can not dedicate Django the time it deserves. I am looking for 
someone or persons willing to take


- python-django
- python-django-angular
- python-django-appconf
- python-django-authority
- python-django-compressor
- python-django-contact-form
- python-django-debug-toolbar
- python-django-haystack
- python-django-mptt
- python-django-nose
- python-django-notification
- python-django-pagination
- python-django-pipeline
- python-django-piston
- python-django-pyscss
- python-django-rest-framework
- python-django-reversion
- python-django-robots
- python-django-tables2
- python-django-tagging



I'm going to orphan the packages mid July. Ideally we'd find takers before?
If you are interested and able to maintain (any) of these packages, 
please send me your FAS name and package(s) to maintain.


Thank you,
Matthias
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bugzilla Assignee

[Jamie Nguyen]

Ben Cotton wrote:

On Tue, Jul 5, 2022 at 2:34 AM Jamie Nguyen  wrote:


Could someone please set the Bugzilla Assignee for EPEL for both
packages to match the main Bugzilla Assignee?


It looks like you're still the EPEL assignee in dist-git. I could make
the change in Bugzilla, but it will get reset the next time dist-git
syncs. I suggest filing a ticket with Release Engineering to get that
updated: https://pagure.io/releng/issues


Hi Ben,

Thanks for the recommendation :-)

I have opened a ticket.

--
Jamie Nguyen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Peter Boy]

I very much appreciate the work to support the various SBC devices like 
Raspberry Pi and workalikes. But I'm a little lost with this proposal. 

> Am 05.07.2022 um 23:16 schrieb Ben Cotton :
> The work around Raspberry Pi 4 has been on going for a number of
> years, but we've never officially supported it due to lack of
> accelerated graphics and other key features. A few of us have led the
> push to get the accelerated graphics work over the line upstream so it
> now makes sense to enable this in Fedora and make support for the
> Raspberry Pi 4 more official.

Why Raspberry Pi, and that as the only model from the large number of 
comparable devices?

Why not other devices, whose makers - as far as I understood the discussion - 
are far more OSS friendly or e.g. explicitly name Fedora as a recommended 
operating system? 

I know, Raspberry Pi is very popular. But this looks to me a bit like Fedora, 
the proverbial uninvited guest shouting "me too" from his corner.



> This work will polish the support for the Raspberry Pi 4 and include
> some wider general improvements to the Raspberry Pis that we
> officially support which include the RPi3 series and the Zero2W.

Again, why Raspberry Pi, and not e.g. Pine64 Rock64Pro or Radxa Rock Pi, just 
to name 2 capable devices? 

And what is the long tern plan? Do we want to evolve a list of supported 
hardware? Maybe Lenovo next for x86-64 arch?


> There are some minor caveats here:
> 
> * Support for WiFi on the Raspberry Pi 400 is out of scope as it's
> dependent on the engagement (in this case the lack of) the vendor,
> Synaptics, of the WiFi module shipped on this device providing generic
> upstream firmware.
> 
> * The Raspberry Pi CM4 is an a module designed for IoT, Edge and
> Embedded use cases. We will test and support the CM4 on the official
> IO board, it should work on other devices that incorporate the CM4
> assuming the vendor has their support in the upstream Raspberry Pi
> firmware/overlays.
> 
> * Further device support around audio and other such pieces will be
> reviewed as part of the process.

I think these statements are true in the same way for a great many other 
boards. Of course, we can't work on everything, but again, why Raspberry of all 
things? 


> 
> == Benefit to Fedora ==
> 
> The Raspberry Pi 4 is a widely available, reasonably prices device. It

Apart from the fact that it has been almost twice as expensive as comparable 
boards for quite some time.

> has worked well in Fedora for some time in IoT and Server use cases,
> and now with a fully accelerated graphics stack available it's a great
> device from a price-per-performance perspective, and it has a wide
> ecosystem, so fully supporting this in Fedora makes a compelling case.

Instead of focusing on one commercial manufacturer, I would like to see a - 
possibly short - list of boards that we recommend for workstation alike and for 
server alike variants, decided on the basis of edition's requirements. And for 
which we take concrete measures to improve support in Fedora. (And I would 
really like to see the arm group more visible and present in the Fedora 
universe). 


> == Scope ==
> * Proposal owners:
> ** Ensure any patches required are accepted upstream
> ** Work with kernel, mesa and other maintainers to ensure everything
> is as it should be
> ** Test

I don't understand what exactly is supposed to change. Don’t you do that 
already? (and in a very good and effective way)

And when we start to support a device or device category in this prominent way, 
then it also needs a lot more documentation and visibility, e.g., a dedicated 
section on the Fedora docs landing page. 


> == How To Test ==
> 
> * Buy a Raspberry Pi 4 (if you can)
 ^^ really nice





--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Retiring/orphaning my packages

[Artur Frenszek-Iwicki]

I can join bleachbit as a co-maintainer.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 05/07/2022 21:15, Matthias Clasen wrote:
And I doubt that you'd be able to notice a 'smaller than 1% slowdown' on 
your system.


4% slowdown is unacceptable.


At least for Fedora Workstation, being
a useful system for developers with working debugging and profiling tools 
should have some weight too.


Debugging works well on Fedora without this flag.

--
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: F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)

[Adam Williamson]

On Tue, 2022-07-05 at 23:29 -0400, Chris Murphy wrote:
> > 
> > Fedora CoreOS is unique in that by default nodes are automatically updated. 
> > We let the exact content
> > set that we are going to ship to our `stable` stream bake in our `testing` 
> > stream for ~two weeks. This
> > allows people to find issues that we don't find in our CI and report them. 
> > We find CI is good, but
> > there is no substitute for real workloads.
> > 
> > The exact content set delivered as part of Fedora GA isn't available two 
> > weeks before GA date so it's
> > hard for us to ship GA content in our `stable` stream on GA day and follow 
> > our current update model.
> > 
> > We do have the `next` stream which does get updated often in the weeks 
> > before GA, but a significantly
> > smaller set of users are running `next`.
> 
> Given the amount of testing happening to produce GA, is it possible to
> have an exception to the 2 week rule for GA?

I did talk about this with Dusty already, and my opinion is the two
week delay is fine. The situations aren't the same, as Dusty said,
CoreOS is unique here: pushing something out on the 'stable' stream
means that almost all CoreOS users (who haven't changed the default
config) will get it almost immediately. That's not the case with
'regular' Fedora installs, where the user chooses when to upgrade. Many
users don't upgrade to a new release as soon as it comes out, they'd
rather wait and see how things shake out. For me, the two week delay
for the CoreOS 'stable' stream to be kicked over is just the same as
that.

I wouldn't be happy if we didn't have a coherent and definite story to
tell here, but "the CoreOS stable stream will update to the new release
in two weeks, or you can switch to the 'next' stream to get it right
away!" is a perfectly fine story to tell on release day, I think.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Retiring/orphaning my packages

[Ali Erdinc Koroglu]

Hello,
I can take bleachbit, musecore, python-djvulibre and lector, thanks

On 05/07/2022 22:09, Audrey Toskin wrote:

I should have done this a long time ago; I don't have the time or energy to 
maintain my packages anymore 

If anyone is interested in any of these, you're welcome to take them.

https://src.fedoraproject.org/user/terrycloth/projects

Applications:
* BleachBit (bleachbit) -- delete traces of your computer activity and other 
junk files to free disk space and maintain privacy
* Lector (lector) -- ebook reader and collection manager
* MuseScore (mscore) -- WYSIWYG sheet music composition/notation/playback -- I 
was only a comaintainer, but I imagine that jjames would appreciate another 
comaintainer in my place, as builds of this app can be a little tricky...

Libraries:
* python-djvulibre -- Python wrapper for djvulibre, which gives open-source 
implementation of the djvu document file format (mostly used by Lector, I think)


-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 compose report: 20220706.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220704.n.0
NEW: Fedora-Rawhide-20220706.n.0

= SUMMARY =
Added images:5
Dropped images:  9
Added packages:  12
Dropped packages:0
Upgraded packages:   158
Downgraded packages: 0

Size of added packages:  12.64 MiB
Size of dropped packages:0 B
Size of upgraded packages:   7.90 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20220706.n.0.x86_64.vagrant-libvirt.box
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20220706.n.0.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20220706.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20220706.n.0.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20220706.n.0.x86_64.vagrant-virtualbox.box

= DROPPED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20220704.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220704.n.0.s390x.raw.xz
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220704.n.0.iso
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20220704.n.0.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20220704.n.0.s390x.tar.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20220704.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220704.n.0.s390x.qcow2
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20220704.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20220704.n.0.iso

= ADDED PACKAGES =
Package: golang-github-a8m-envsubst-1.3.0-1.fc37
Summary: Environment variables substitution for Go
RPMs:golang-github-a8m-envsubst golang-github-a8m-envsubst-devel
Size:2.19 MiB

Package: golang-github-goccy-yaml-1.9.5-1.fc37
Summary: YAML support for the Go language
RPMs:golang-github-goccy-yaml golang-github-goccy-yaml-devel
Size:2.39 MiB

Package: golang-github-mroach-rom64-0.5.3-1.fc37
Summary: Nintendo 64 ROM utility
RPMs:golang-github-mroach-rom64-devel rom64
Size:5.22 MiB

Package: ocaml-pp-1.1.2-2.fc37
Summary: Pretty printing library for OCaml
RPMs:ocaml-pp ocaml-pp-devel
Size:633.04 KiB

Package: perl-MikroTik-API-2.0.1-3.fc37
Summary: Client for the MikroTik RouterOS API
RPMs:perl-MikroTik-API
Size:21.76 KiB

Package: python-azure-mgmt-subscription-1:3.0.0-1.fc37
Summary: Microsoft Azure Subscription Management Client Library for Python
RPMs:python3-azure-mgmt-subscription
Size:71.54 KiB

Package: python-keepassxc-browser-0.1.8-1.fc37
Summary: Access the KeepassXC Browser API from python
RPMs:python3-keepassxc-browser
Size:37.30 KiB

Package: rocm-opencl-5.2.0-1.fc37
Summary: ROCm OpenCL Runtime
RPMs:rocm-clinfo rocm-opencl rocm-opencl-devel
Size:1.94 MiB

Package: rust-esphome-0.1.0-1.fc37
Summary: ESPHome API client for Rust
RPMs:rust-esphome+default-devel rust-esphome-devel
Size:55.00 KiB

Package: rust-openssl-macros-0.1.0-1.fc37
Summary: Internal macros used by the openssl crate
RPMs:rust-openssl-macros+default-devel rust-openssl-macros-devel
Size:20.51 KiB

Package: rust-print_bytes-0.6.0-1.fc37
Summary: Print bytes as losslessly as possible
RPMs:rust-print_bytes+default-devel rust-print_bytes+specialization-devel 
rust-print_bytes-devel
Size:32.91 KiB

Package: rust-unicode-ident-1.0.1-1.fc37
Summary: Determine whether characters have the XID_Start or XID_Continue 
properties
RPMs:rust-unicode-ident+default-devel rust-unicode-ident-devel
Size:44.71 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  389-ds-base-2.2.2-1.fc37
Old package:  389-ds-base-2.2.1-4.fc37
Summary:  389 Directory Server (base)
RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp 
cockpit-389-ds python3-lib389
Size: 20.08 MiB
Size change:  122.65 KiB
Changelog:
  * Tue Jul 05 2022 Mark Reynolds  - 2.2.2-1
  - Bump version to 2.2.2
  - Issue 5221 - fix covscan (#5359)
  - Issue 5294 - Report Portal 5 is not processing an XML file with (#5358)
  - Issue 5353 - CLI - dsconf backend export breaks with multiple backends
  - Issue 5346 - New connection table fails with ASAN failures (#5350)
  - Issue 5345 - BUG - openldap migration fails when ppolicy is active (#5347)
  - Issue 5323 - BUG - improve skipping