Fedora-Cloud-36-20220710.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-20220709.0):

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

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)

[Daan De Meyer via devel]

> I strongly prefer the latter approach.  I believe the unwinder
> executes in NMI context, meaning that it must not block and must finish
> executing in a bounded amount of time.  Furthermore, any oops becomes
> an immediate kernel panic.  The eBPF verifier can trivially guarantee
> that the unwinder satisfies the properties needed here.  For security
> reasons, submitting eBPF programs is a privileged operation, but some
> programs could be compiled into the kernel and thus considered trusted.
> Such programs could be used without any special privileges.
>
> The key advantage of this approach is that privileged user-mode
> profiling tools, such as sysprof, can submit their own eBPF unwinders.
> This means that the kernel does not need to support whatever unwind
> info format userspace uses.  One could use DWARF, ORC, or any other
> format one wishes.

BPF programs do not have access to arbitrary ELF sections AFAIK. Every EBPF
unwinder that I've found is implemented via preprocessing the unwind format
in userspace and storing that in BPF maps so that it can be accessed from the
BPF program.

Effectively, this means that every program that wants to do unwinding
in BPF has to do this preprocessing and store all the required information
in BPF maps. When you don't know which program you're going to be
requesting a stacktrace for, this effectively means userspace has to provide
this information for every program that might run on the system. While this
might work for dedicated long-running system profiling daemons, it is not
an option for software such as perf or bpftrace since it would drastically
increase their startup time, as well as their overall resource usage.

Cheers,

Daan


From: Demi Marie Obenour 
Sent: 09 July 2022 04:02
To: devel@lists.fedoraproject.org
Subject: Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation 
flags (System-Wide Change proposal)

On 7/8/22 20:18, Christian Hergert wrote:
>> That is the problem right here: .eh_frame-based unwinding is too slow, so it 
>> has to be
>> done offline in userspace.  What about instead adding ORC information to 
>> userspace?  That
>> would be much faster to use.
>
> I'm not familiar with ORC, but there are a few things that initially come to
> mind in looking towards such a solution.
>
> First, are there any examples of perf being able to reference ORC data coming
> from user-space or is it currently limited to PERF_CONTEXT_KERNEL? For
> system-wide profiling, we still require that the kernel can do high-velocity
> unwinding across address contexts.

Why does the unwinding need to happen in the kernel?  The kernel can
already asynchronously invoke userspace code in the form of signal
handlers.  Is the problem that it is necessary to collect profiling
information in the middle of a system call, where another syscall
would see inconsistent (and potentially exploitable) kernel state?

> My (limited) understanding of ORC is that the result produced by objtool gets
> you a series of unwind tables, but those tables require further processing by
> the kernel at boot.
>
> Again, I have limited understanding, but wouldn't something need to
> be processed as part of spawning and loading executable pages? There are both
> .orc_unwind and .orc_unwind_ip sections, both of which need to be sorted. I
> don't know what layer would be responsible for that, or how it adapts to
> dlopen(), double-mapping pages like libffi, etc... but I'm sure people will
> have opinions about it.

Ouch.  That is a serious problem for a number of reasons, not least
of which is security.  Having the kernel parse even more complex
untrusted input in C is a horrible idea.

I can think of at least two better options:

1. Wait for Rust support to be merged, and write the unwinder in Rust.
2. Implement the unwinder as an eBPF program.

I strongly prefer the latter approach.  I believe the unwinder
executes in NMI context, meaning that it must not block and must finish
executing in a bounded amount of time.  Furthermore, any oops becomes
an immediate kernel panic.  The eBPF verifier can trivially guarantee
that the unwinder satisfies the properties needed here.  For security
reasons, submitting eBPF programs is a privileged operation, but some
programs could be compiled into the kernel and thus considered trusted.
Such programs could be used without any special privileges.

The key advantage of this approach is that privileged user-mode
profiling tools, such as sysprof, can submit their own eBPF unwinders.
This means that the kernel does not need to support whatever unwind
info format userspace uses.  One could use DWARF, ORC, or any other
format one wishes.

Christian, would this be sufficient for your needs?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code

Fedora-Cloud-35-20220710.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-20220709.0):

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

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: Request: Airspy HF+

[Buford T. Justice]

@Mark E. Fuller
Something isn't right with your airspyhf software.  I installed it, but neither 
Gqrx nor SDR++ sees the Airspy HF+ Discovery.  Also, I cannot do 
"airspyhf_info" to see its status.  All I get is:

[BT@PC ~]$ airspyhf_info
AirSpy HF library version: 1.6.8
No devices attached.

I was messing with OpenMandriva the other day.  "sudo dnf install 
airspyone_host airspyhf" works and installed both devices.  I really wish 
Fedora would do this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[drago01]

One thing which seems to be completely missing in the conversation is how
this affects battery life. Having lower performance, means the CPU has to
do more work / be in a higher power state for a longer time frame.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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]

drago01 wrote:
> One thing which seems to be completely missing in the conversation is how
> this affects battery life. Having lower performance, means the CPU has to
> do more work / be in a higher power state for a longer time frame.

Who in their right mind does CPU profiling on battery?

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

Fedora rawhide compose report: 20220710.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220709.n.0
NEW: Fedora-Rawhide-20220710.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   56
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   5.21 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   632.33 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20220709.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ImageMagick-1:6.9.12.58-1.fc37
Old package:  ImageMagick-1:6.9.12.52-1.fc37
Summary:  An X application for displaying and manipulating images
RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel 
ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs 
ImageMagick-perl
Size: 33.06 MiB
Size change:  -5.03 KiB
Changelog:
  * Sat Jul 09 2022 S??rgio Basto  - 1:6.9.12.56-1
  - Update ImageMagick to 6.9.12.56 (#2105662)

  * Sat Jul 09 2022 S??rgio Basto  - 1:6.9.12.58-1
  - Update ImageMagick to 6.9.12.58 (#2105662)


Package:  arc-kde-20220706-1.fc37
Old package:  arc-kde-20220612-1.fc37
Summary:  Port of the popular GTK theme Arc for the Plasma 5 desktop
RPMs: arc-kde arc-kde-decorations arc-kde-konsole arc-kde-konversation 
arc-kde-kvantum arc-kde-wallpapers arc-kde-yakuake
Size: 31.65 MiB
Size change:  1.95 KiB
Changelog:
  * Sat Jul 09 2022 Robert-Andr?? Mauchin  20220706-1
  - Update to 20220706 - Close: rhbz#2104742


Package:  barman-3.0.1-1.fc37
Old package:  barman-2.17-3.fc37
Summary:  Backup and Recovery Manager for PostgreSQL
RPMs: barman barman-cli python3-barman
Size: 597.07 KiB
Size change:  52.77 KiB
Changelog:
  * Sat Jul 09 2022 Simone Caronni  - 3.0.0-1
  - Update to 3.0.0.

  * Sat Jul 09 2022 Simone Caronni  - 3.0.1-1
  - Update to 3.0.1.


Package:  blender-1:3.2.1-1.fc37
Old package:  blender-1:3.2.0-7.fc37
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 158.90 MiB
Size change:  11.16 KiB
Changelog:
  * Sat Jul 09 2022 Luya Tshimbalanga  1:3.2.1-1
  - local build


Package:  fonttools-4.34.4-1.fc37
Old package:  fonttools-4.33.3-2.fc37
Summary:  Tools to manipulate font files
RPMs: fonttools python3-fonttools python3-fonttools+graphite 
python3-fonttools+interpolatable python3-fonttools+lxml python3-fonttools+plot 
python3-fonttools+symfont python3-fonttools+type1 python3-fonttools+ufo 
python3-fonttools+unicode python3-fonttools+woff
Size: 2.10 MiB
Size change:  23.84 KiB
Changelog:
  * Sat Jul 09 2022 Parag Nemade  - 4.34.4-1
  - Update to 4.34.4 version (#2104988)


Package:  
golang-github-facebookincubator-contest-0-0.4.20210706gitceebc35.fc37
Old package:  
golang-github-facebookincubator-contest-0-0.3.20210706gitceebc35.fc36
Summary:  Run continuous and on-demand system testing for real and virtual 
hardware
RPMs: contest golang-github-facebookincubator-contest-devel
Size: 28.62 MiB
Size change:  226.40 KiB
Changelog:
  * Sat Jul 09 2022 Maxwell G  - 0-0.4
  - Rebuild for CVE-2022-{24675,28327,29526 in golang}


Package:  
golang-github-facebookincubator-dhcplb-0-0.4.20210706git2e66b27.fc37
Old package:  
golang-github-facebookincubator-dhcplb-0-0.3.20210706git2e66b27.fc36
Summary:  Facebook's implementation of a load balancer for DHCP
RPMs: dhcplb golang-github-facebookincubator-dhcplb-devel
Size: 8.35 MiB
Size change:  33.70 KiB
Changelog:
  * Sat Jul 09 2022 Maxwell G  - 0-0.4
  - Rebuild for CVE-2022-{24675,28327,29526 in golang}


Package:  golang-github-facebookincubator-go2chef-1.0-2.fc37
Old package:  golang-github-facebookincubator-go2chef-1.0-1.fc37
Summary:  Tool to bootstrap a system from zero so that it's able to run Chef
RPMs: go2chef golang-github-facebookincubator-go2chef-devel
Size: 16.21 MiB
Size change:  12.37 KiB
Changelog:
  * Sat Jul 09 2022 Maxwell G  1.0-2
  - Rebuild for CVE-2022-{24675,28327,29526 in golang}


Package:  golang-github-facebookincubator-nvdtools-0.1.4-5.fc37
Old package:  golang-github-facebookincubator-nvdtools-0.1.4-4.fc36
Summary:  A collection of tools for working with National Vulnerability 
Database feeds
RPMs: golang-github-facebookincubator-nvdtools-devel nvdtools
Size: 45.08 MiB
Size change:  276.60 KiB
Changelog:
  * Sat Jul 09 2022 Maxwell G  - 0.1.4-5
  - Rebuild for CVE-2022-{24675,28327,29526 in golang}


Package:  golang-github-gojuno-minimock-3.0.10-3.fc37
Old package:  golang-github-gojuno-minimock-3.0.10-2.fc36
Summary:  Powerful mock generation tool for Go programming language
RPMs: golang-github-gojuno-mini

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

[Vitaly Zaitsev via devel]

On 09/07/2022 22:32, Gordon Messmer wrote:
I cannot replicate any of the differences that I would expect to be able 
to.  More than anything else, their results look like evidence of a bug 
in the Xeon Platinum 8380.


Have you rebuilt all system packages with -fno-omit-frame-pointer or 
just tested packages?


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

[drago01]

On Sunday, July 10, 2022, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> drago01 wrote:
> > One thing which seems to be completely missing in the conversation is how
> > this affects battery life. Having lower performance, means the CPU has to
> > do more work / be in a higher power state for a longer time frame.
>
> Who in their right mind does CPU profiling on battery?
>
>
The comment was not about profiling but about the change itself.



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

drago01 wrote:

> On Sunday, July 10, 2022, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
> 
>> drago01 wrote:
>> > One thing which seems to be completely missing in the conversation is
>> > how this affects battery life. Having lower performance, means the CPU
>> > has to do more work / be in a higher power state for a longer time
>> > frame.
>>
>> Who in their right mind does CPU profiling on battery?
>>
>>
> The comment was not about profiling but about the change itself.

So I guess you agree that this is actually an argument against this Change, 
is it not? Considering that, since profiling is usually not done on battery, 
improving the performance of profiling at the expense of overall performance 
is not a win when you consider the battery use.

(The position of your reply in the thread was not optimal, because you 
answered a mail that was talking about the performance of profiling, not the 
overall performance of the system. So that made it easy to misinterpret your 
position.)

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)

[drago01]

On Sunday, July 10, 2022, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> drago01 wrote:
>
> > On Sunday, July 10, 2022, Kevin Kofler via devel <
> > devel@lists.fedoraproject.org> wrote:
> >
> >> drago01 wrote:
> >> > One thing which seems to be completely missing in the conversation is
> >> > how this affects battery life. Having lower performance, means the CPU
> >> > has to do more work / be in a higher power state for a longer time
> >> > frame.
> >>
> >> Who in their right mind does CPU profiling on battery?
> >>
> >>
> > The comment was not about profiling but about the change itself.
>
> So I guess you agree that this is actually an argument against this
> Change,
> is it not?


 Yes it is, unless data shows shows otherwise, which I have not seen.


> Considering that, since profiling is usually not done on battery,
> improving the performance of profiling at the expense of overall
> performance
> is not a win when you consider the battery use.
>
> (The position of your reply in the thread was not optimal, because you
> answered a mail that was talking about the performance of profiling, not
> the
> overall performance of the system. So that made it easy to misinterpret
> your
> position.)


Sorry for that, traveling and responding on mobile.


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

[Miroslav Suchý]

Dne 06. 07. 22 v 20:13 Ben Cotton napsal(a):

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


`systemctl preset-all` is hard to debug. Can we please have implemented this 
first:

https://github.com/systemd/systemd/issues/17898

RFE - dry-run for preset-all

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 14/236 (x86_64), 17/165 (aarch64)

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

ID: 1320430 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1320430
ID: 1320455 Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/1320455
ID: 1320498 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/1320498
ID: 1320513 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1320513
ID: 1320519 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1320519
ID: 1320547 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/1320547
ID: 1320550 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/1320550
ID: 1320551 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1320551
ID: 1320634 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1320634
ID: 1320638 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1320638
ID: 1320688 Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/1320688
ID: 1320729 Test: aarch64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/1320729
ID: 1320755 Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1320755

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

ID: 1320437 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1320437
ID: 1320460 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1320460
ID: 1320466 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1320466
ID: 1320479 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1320479
ID: 1320485 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1320485
ID: 1320487 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1320487
ID: 1320524 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1320524
ID: 1320585 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1320585
ID: 1320597 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1320597
ID: 1320606 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1320606
ID: 1320611 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1320611
ID: 1320624 Test: aarch64 Workstation-upgrade desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/1320624
ID: 1320625 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1320625
ID: 1320636 Test: aarch64 Workstation-upgrade help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1320636
ID: 1320637 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1320637
ID: 1320671 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1320671
ID: 1320716 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1320716
ID: 1320735 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1320735

Soft failed openQA tests: 6/236 (x86_64), 5/165 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 1320448 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1320448
ID: 1320486 Test: x86_64 Silverblue-dvd_ostree-iso clocks
URL: https://openqa.fedoraproject.org/tests/1320486
ID: 1320489 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1320489
ID: 1320500 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1320500
ID: 1320579 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1320579
ID: 1320595 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL:

Re: Request: Airspy HF+

[Mark E. Fuller]

Sorry it's not working.
I simply build the existing approved package that was otherwise abandoned.

Given what you installed with Mandriva, it looks like there's another 
package needed - airspyone_host, which is in the Fedora repositories.

(see e.g. https://pkgs.org/search/?q=airspyone_host)
Have you tried installing that package as well?

Please also keep in mind that Fedora is a volunteer-driven, community 
project.
We all have limited time to contribute and while I and many others are 
willing to assist with software like yours, it would be nicer to see a 
request for assistance with getting the software into the distribution 
over a lament that we do not have it.



Mark E. Fuller, Ph.D.
ful...@fedoraproject.org
ful...@mefuller.dev
@fuller:fedora.im
@fuller:one.ems.host
https://www.stossrohr.net
PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
On 10/07/2022 12:25, Buford T. Justice wrote:

@Mark E. Fuller
Something isn't right with your airspyhf software.  I installed it, but neither Gqrx nor 
SDR++ sees the Airspy HF+ Discovery.  Also, I cannot do "airspyhf_info" to see 
its status.  All I get is:

[BT@PC ~]$ airspyhf_info
AirSpy HF library version: 1.6.8
No devices attached.

I was messing with OpenMandriva the other day.  "sudo dnf install airspyone_host 
airspyhf" works and installed both devices.  I really wish Fedora would do this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Miroslav Suchý]

Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a):

Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS,
which have their own somewhat different release/life cycles? What about
module lifecycles? What is it about*lifecycles*  that's important,
anyway? Don't we maybe want to just have a sort of generic system for
"important events"?

I view it as a mechanism to communicate well in advance of when someone
is going to have to do work.

Fedora is the simple case: every 6-12 months you're going to have to
upgrade the version of the OS.


And when implementing this for Fedora, can you bear RHEL in mind too? Because 
it has several levels of EOL

https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel

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

Re: Fedora SCM requests on the weekend

[Simon de Vlieger]

Would you need any help regarding the automation?

On Sat, Jul 9, 2022, at 8:10 PM, Kevin Fenzi wrote:
> On Fri, Jul 08, 2022 at 01:02:15PM -, Mukundan Ragavan wrote:
>> > On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:
>> > 
>> > That said, until then I can try and run things on weekends. 
>> 
>> Is there a formal process to volunteer to hold the keys to the kingdom?
>
> Yes. Basically one of the existing group members nominates someone, and
> all the existing group members vote on adding them. 
>
> However, at this point we are close to automating it, so not sure it's
> worth adding more folks. We could though if it isn't automated soon...
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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
>
> Attachments:
> * signature.asc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

RPM Guidance Questions

[Brad Smith]

Greetings -

I am sure this question has been asked and answered many times but I
could not find anything that specifically addressed my questions via
google search.

I have modified a spec file for a python based application (weewx
specifically although  that is not too relevant) to target Fedora
specifically. The upstream developers have a spec file that covers el8
and fedora both. The upstream version uses init.d based init scripts
to manage the application daemon.

I modified the spec file to target fedora specifically using systemd
to manage the daemon.  This is working well for me on test VMs.

I would also like to be able to install the rpm on a fedora container
image. I can do that with either the upstream or my current spec file,
of course, but I am thinking that systemd, in this particular
scenario, is overkill. The application daemon would be managed at the
container level not within the container per se.

What would be a good way to structure the spec file to cover both
scenarios? With systemd for install on a fedora VM or fedora bare
metal machine and without systemd for a fedora container install?

Would using subpackages be appropriate? One rpm for the base install
and the second to add systemd integration? Or is there another
alternative? A pointer to relevant discussions or possible solution
would be most helpful and appreciated.

Many thanks

regards

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

[Demi Marie Obenour]

On 7/9/22 12:05, Christian Hergert wrote:
>> Why does the unwinding need to happen in the kernel?  The kernel can
>> already asynchronously invoke userspace code in the form of signal
>> handlers.  Is the problem that it is necessary to collect profiling
>> information in the middle of a system call, where another syscall
>> would see inconsistent (and potentially exploitable) kernel state?
> 
> One of the primary values of system-wide profiling is being able to
> see how a particular library call might have caused undesirable code
> paths due to a syscall, and where/what was reached (given high enough
> sampling rate).
> 
> Does that need to happen in kernel space? I don't know, perse, other
> than perf needs to be able to do that work as it is what gives us
> the array of instruction pointers back. There was some chatter a
> number of years ago in perf about how to handle ORC from user-space,
> and if I'm summing this up correctly, it was basically..
> 
>  - When sampling in PERF_CONTEXT_KERNEL, stop unwinding at the syscall 
> boundary
>  - Append stacktrace samples to perf buffer ring
>  - Upon rescheduling, backtrace a single time into user-space, and expect 
>the consumer to know that N previous samples with matching task-id all
>have the user-space backtrace.
> 
> That's a pretty significant behavior change, and all tools would need
> surgery to support it. I have no idea if that is paletable to either
> side of the debate, but it was the one possible direction I saw.
> 
> It does have a number of pros, in that you can save a lot of unwinding
> time on syscall-heavy workloads by doing user-space unwinding once,
> and from scheduler task queues (so you can take faults), and can
> avoid the NMI context being the cost-center for accounting. But
> the cons are significant in that the behavior change is expansive,
> effects all tooling, and will require ORC data across the platform.

This (or a variant of it) is the only reasonable solution I know of.
The current situation is not acceptable, and a system-wide slowdown
from -fno-omit-frame-pointer is also not acceptable.  A solution like
you suggested here will be much more work, but it will also be a much
better product.

>> Ouch.  That is a serious problem for a number of reasons, not least
>> of which is security.  Having the kernel parse even more complex
>> untrusted input in C is a horrible idea.
> 
> It might seem that way by the description I gave, but we're just
> talking an array of intptr_t or similar. There is no dereferencing or
> state machines like you have with DWARF. Runtime resolution is also
> essentially bsearch() on interval arrays. I really don't think it's
> the sort of thing that requires Rust.

bsearch() itself assumes that the input is trusted, but it should
be possible to have a variant that does not make that assumption.
Similarly, it should be possible to ensure that all user pointer
access are guarded by checks to ensure they will not fault and actually
point to userspace memory.

> As for eBPF, we'd still probably be in NMI context with this route,
> and would fail if we had to page in ORC tables. So that means we'd
> either have to take a per-task memory overhead to maintain the mutated
> form (probably unreasonable) or find a way for that to be done from
> the task's space when returning from the syscall.

The latter is definitely the better option.  The NMI handler needs
to be simpler, not more complex.  One option would be to replace
the normal syscall return with a return to a userspace trampoline.
The trampoline would write the userspace backtrace to a kernel-provided
buffer and then jump to the original return address.

Some programs (such as LVM) would need to be able to opt-out of
such profiling.  LVM has critical sections where it is not safe to
perform any I/O, as the device that backs the root filesystem might
be suspended.  Such a program would only be able to participate in
unwinding if mlockall() was used.

>> Christian, would this be sufficient for your needs?
> 
> I don't think so without significant work. The best case I see here is
> for perf to support user-space unwinding within the task, be it ORC
> or DWARF, and that unwinder not have to necessarily be in-tree with
> the kernel because we know they won't accept a DWARF unwinder again.

Would it be sufficient with that significant work?

> It does pose some questions on what would happen with carefully
> crafted DWARF data.

Processing untrusted DWARF data is probably a bad idea.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

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

[Gordon Messmer]

On 7/10/22 04:38, Vitaly Zaitsev via devel wrote:
Have you rebuilt all system packages with -fno-omit-frame-pointer or 
just tested packages? 



No.  Early in the thread, Tomasz Torcz posted a link to a Phoronix 
article as evidence that Fedora's performance was behind other 
distributions.  At one point, I expressed doubt that intel_pstate in 
performance mode was the reason for some significant differences, so I 
ran some tests to try to either prove or disprove that explanation.  
Having done so, I don't think the results that Phoronix published are 
useful as evidence of anything.

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

Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

Hello.

fmt 9.0.x update will include a soversion bump from .8 to .9. It has 
both API and ABI changes.


Changelog: https://github.com/fmtlib/fmt/releases/tag/9.0.0

The list of affected packages in Rawhide:
0ad
OpenImageIO
cantera
ceph
dolphin-emu
domoticz
folly
libsonata
mkvtoolnix
sdrpp
spdlog
vcpkg
zswap-cli

I can rebuild only spdlog, vcpkg and zswap-cli. For others, I will need 
proven-packagers assistance.


Please use the f37-build-side-54844 side tag. I will merge it into 
Rawhide later.


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

[Vitaly Zaitsev via devel]

On 10/07/2022 19:36, Gordon Messmer wrote:
No.  Early in the thread, Tomasz Torcz posted a link to a Phoronix 
article as evidence that Fedora's performance was behind other 
distributions.


All packages in the dependency tree must be rebuilt with 
-fno-omit-frame-pointer flag, otherwise the tests will show the weather 
on Mars.


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

[Gordon Messmer]

On 7/10/22 10:55, Vitaly Zaitsev via devel wrote:

On 10/07/2022 19:36, Gordon Messmer wrote:
No.  Early in the thread, Tomasz Torcz posted a link to a Phoronix 
article as evidence that Fedora's performance was behind other 
distributions.


All packages in the dependency tree must be rebuilt with 
-fno-omit-frame-pointer flag, otherwise the tests will show the 
weather on Mars.



Right, I understand that.  I was not attempting to determine the effect 
of the -fno-omit-frame-pointer flag, and neither was Tomasz.  I believe 
Tomasz's point was that Fedora should not consider any changes that 
would negatively impact performance, because existing benchmarks 
indicate that Fedora is slower than other distributions.  I think that 
the benchmarks that Tomasz used as evidence do not support that point of 
view.

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

[Buford T. Justice]

Yes I have "airspyone_host" installed on Fedora.  It is working with my two 
Airspy units (R2 and Mini) fine though SDR++ (also from Fedora) doesn't see 
them.  Gqrx does see them.

The Airspy HF+ Discovery is my third unit.  It does not work with 
"airspyone_host".  No HF+ works with that software.  "airspyhf" is specifically 
for Airspy HF+ only.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora SCM requests on the weekend

[Kevin Fenzi]

On Sun, Jul 10, 2022 at 06:34:11PM +0200, Simon de Vlieger wrote:
> Would you need any help regarding the automation?

Well, I'm not doing the implementation there, but we can always use
help. ;) 

I think the code is all there now, we were wanting to get staging
working to test it before rolling it out. 

It's being added as a toddler ( https://pagure.io/fedora-infra/toddlers
) which is basically a framework for things that listen to the message
bus and act on messages or run from time to time to do things. 

CCing Michal here for comment on where we can use help here. 

kevin
--
> On Sat, Jul 9, 2022, at 8:10 PM, Kevin Fenzi wrote:
> > On Fri, Jul 08, 2022 at 01:02:15PM -, Mukundan Ragavan wrote:
> >> > On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:
> >> > 
> >> > That said, until then I can try and run things on weekends. 
> >> 
> >> Is there a formal process to volunteer to hold the keys to the kingdom?
> >
> > Yes. Basically one of the existing group members nominates someone, and
> > all the existing group members vote on adding them. 
> >
> > However, at this point we are close to automating it, so not sure it's
> > worth adding more folks. We could though if it isn't automated soon...
> >
> > kevin
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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
> >
> > Attachments:
> > * signature.asc
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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


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

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

[Jeff Law]

On 7/10/2022 11:36 AM, Gordon Messmer wrote:

On 7/10/22 04:38, Vitaly Zaitsev via devel wrote:
Have you rebuilt all system packages with -fno-omit-frame-pointer or 
just tested packages? 



No.  Early in the thread, Tomasz Torcz posted a link to a Phoronix 
article as evidence that Fedora's performance was behind other 
distributions.  At one point, I expressed doubt that intel_pstate in 
performance mode was the reason for some significant differences, so I 
ran some tests to try to either prove or disprove that explanation.  
Having done so, I don't think the results that Phoronix published are 
useful as evidence of anything.
Phoronix is notorious for poor benchmarking methodology and trying to 
draw any conclusions from their data is pointless as a result.


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)

[Florian Weimer]

* Fabio Valentini:

> On Fri, Jul 8, 2022 at 9:20 PM Christian Hergert  wrote:
>>
>> > So it looks like what you folks are doing is actually very similar to what
>> > Facebook is doing. That is interesting, and explains why some GNOME
>> > developers are jumping on the bandwagon of this Change proposal.
>>
>> To be fair, we've been complaining about it internally in GNOME for probably 
>> around a decade. So it's not a new thing from our standpoint. What is new is 
>> that it appears others came to the similar-in-spirit solutions.
>
> Coming at this problem from a different angle, just a hypothetical:
> Would it be acceptable to add -fno-omit-frame-pointer and
> -mno-omit-leaf-frame-pointer to the default compiler flags on RHEL?

It seems unlikely.  Given typical hardware replacement cycles,
hardware-assisted backtrace without severe limitations will be widely
available soon, and it should have even less overhead than frame-pointer
traversal.

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: ANTLR packages and i686

[Mikolaj Izdebski]

On Thu, Jul 7, 2022 at 4:15 AM Jerry James  wrote:
>
> 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.

I agree. That would be my preference too.

> 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

Not sure why your list does not include these, but the following
packages also build-require antlr-C++:
* gdl - already has java bcond; BR on antlr would need to be wrapped into bcond
* nco - seems to have ability to be built without antlr (with limited features)
* sqlitebrowser - looks like application (and we don't ship i686 kernel)
* vfrnav - likewise

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

* Demi Marie Obenour:

> That is the problem right here: .eh_frame-based unwinding is too slow,
> so it has to be done offline in userspace.  What about instead adding
> ORC information to userspace?  That would be much faster to use.

I'm not sure ORC covers all the registers that could be used to store
the previous frame pointer.  According to the kernel developers, ORC
unwind data is 50% larger than DWARF data:

| The ORC data format does have a few downsides compared to DWARF.  ORC
| unwind tables take up ~50% more RAM (+1.3MB on an x86 defconfig kernel)
| than DWARF-based eh_frame tables.

(Documentation/x86/orc-unwinder.rst)

We would have to have both in parallel, so this is going to drive up
installation sizes somewhat.  (The document also contains some
concerning statistics for enabling frame pointers in the kernel, by the
way.)

It's also not clear that all of the ORC performance tricks can be
applied to untrusted userspace ORC that can be unloaded at any time (or
if it might not be easier after all to do this on DWARF data).

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]

* Matthias Clasen:

> On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer  wrote:
>  
>> If the GNOME's sysprof does not work with Fedora, fix it or use
>> something else.  Do not change how Fedora is built.
>
> The result of that attitude is that performance work in the desktop
> space is happening on GNOME OS images, or in Flatpak runtimes instead
> of on Fedora. Which is a bit sad for Fedora as a supposedly
> developer-friendly environment.

My comment was specifically about sysprof.  I've been told that the
GNOME developers will not even consider anything else.  This means that
we need to fix sysprof.  If we do that, it will be possible to use GNOME
OS for profiling on older CPUs, and hardware-assisted backtraces on
newer CPUs on Fedora (at least Skylake and Zen 3, especially once we've
got userspace SHSTK support).

Even if this proposal is not accepted, I think we can collaborate on a
couple of things:

* Enhance sysprof with LBR and SHSTK support.

* Enable userspace backtrace generation from BPF without frame pointers
  (possibly by using LBR and SHSTK at first).

* Investigate use of the Systemtap and elfutils unwinders in these
  tools.

* Speed up decoding of DWARF data structures using the BMI instruction
  sets (which only operate on scalar registers and should therefore be
  usable even within the kernel).  According to
  
  that's a major source of DWARF processing overhead, and I don't think
  it has to be.

I'll try to get confirmation that it is technically feasible in priciple
to use SHSTK to get arbitrarily deep backtraces from kernel space for
userspace applications.

If we can get SHSTK to work, the value of the DWARF integration and
performance work will diminish fairly quickly because most developers
will soon have CPUs with fairly deep (32 entry) LBR buffers, SHSTK
support, or both.

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