Re: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Naheem Zaffar]

On Sat, 9 Jul 2022, 03:37 Allan via devel, 
wrote:

> On Tue, 5 Jul 2022 23:21:36 +0200
> Miro Hrončok  wrote:
>
> > On 05. 07. 22 23:16, Ben Cotton wrote:
> > > 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.
> >
> > I don't understand what is actually proposed by this change proposal.
>
> I can't see any change here in any polices of Fedora too.
>
> Please explain what really IS the CHANGE


Fedora will be able to support being installed on and having accelerated
graphics on  raspberry pi 4.

It's a milestone, an announcement. Almost like a change notice announcing
that next Fedora will come with next gnome/kde/kernel/samba.

There may be (some times a lot of) work to integrate it and there may be
fedora contributors making it happen and doing upstream development, but it
doesnt require changes in policy or focus.

>
>
___
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 2105631] New: perl-Imager-1.019 is available

[bugzilla]

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

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



Releases retrieved: 1.019
Upstream release that is considered latest: 1.019
Current version/release in rawhide: 1.018-1.fc37
URL: http://search.cpan.org/dist/Imager/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/6659/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Imager


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

Help needed with truth

[Orion Poplawski]

The truth package has been failing to build for quite a while, and I 
can't figure out how to fix it.  I believe it's related to versions of 
the auto package.  I dealt with those quite a while ago, but really 
don't have the time to delve back into it again.


Any help would greatly appreciated.

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Demi Marie Obenour]

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 of Conduct: 
https://docs.fedoraproject.org/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)

[Allan via devel]

On Tue, 5 Jul 2022 23:21:36 +0200
Miro Hrončok  wrote:

> On 05. 07. 22 23:16, Ben Cotton wrote:
> > 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.
> 
> I don't understand what is actually proposed by this change proposal.

I can't see any change here in any polices of Fedora too.

Please explain what really IS the CHANGE ??

  Allan.


___
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 2102686] Add perl-Package-Variant to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-ce1756b539 has been pushed to the Fedora EPEL 9 testing
repository.

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

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=2102686
___
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 2102645] Add perl-Context-Preserve to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-104264989e has been pushed to the Fedora EPEL 9 testing
repository.

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

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=2102645
___
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 2102629] Add perl-Class-Accessor-Grouped to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-377a90dbd1 has been pushed to the Fedora EPEL 9 testing
repository.

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

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=2102629
___
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 2102650] Add perl-Math-Base36 to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-14600e13e3 has been pushed to the Fedora EPEL 9 testing
repository.

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

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=2102650
___
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 2102643] Add perl-Class-Unload to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-4d707c6152 has been pushed to the Fedora EPEL 9 testing
repository.

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

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=2102643
___
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 2102648] Add perl-DateTime-Format-Pg to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-28a4c3e355 has been pushed to the Fedora EPEL 9 testing
repository.

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

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

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

[updates]

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

e00compr-1.0.1-35.el7
geany-1.37-1.el7
seamonkey-2.53.13-1.el7

Details about builds:



 e00compr-1.0.1-35.el7 (FEDORA-EPEL-2022-b5823e7621)
 Library to compress and uncompress E00 files

Update Information:

Fix duplicate, rather than symlinked, shared library

ChangeLog:

* Fri Jul  8 2022 Benjamin A. Beasley  1.0.1-35
- Fix duplicate, rather than symlinked, shared library
* Fri Jul  8 2022 Benjamin A. Beasley  1.0.1-34
- Fix extra newline in description
* Fri Jul  8 2022 Benjamin A. Beasley  1.0.1-33
- Output LICENSE contents when creating it
* Fri Jul  8 2022 Benjamin A. Beasley  1.0.1-32
- Fix a typo in a spec file comment




 geany-1.37-1.el7 (FEDORA-EPEL-2022-d21f0b3572)
 A fast and lightweight IDE using GTK3

Update Information:

This update brings a new version of Geany to a Fedora box near you.

ChangeLog:

* Fri Jul  8 2022 Dominic Hopf  - 1.37-1
- New upstream release: Geany 1.37

References:

  [ 1 ] Bug #2104341 - Please update geany to latest version, currently 1.38
https://bugzilla.redhat.com/show_bug.cgi?id=2104341




 seamonkey-2.53.13-1.el7 (FEDORA-EPEL-2022-463787a597)
 Web browser, e-mail, news, IRC client, HTML editor

Update Information:

Update to 2.53.13  Note that besides the ordinary builds for the current Fedora
and EPEL branches, there is an additional distro-independed build available at
https://buc.fedorapeople.org/seamonkey . So if you have friends who use other
Linux distro, but that distro does not provide SeaMonkey yet, you can recommend
it for them.

ChangeLog:

* Fri Jul  8 2022 Dmitry Butskoy  2.53.13-1
- update to 2.53.13
- add support for ffmpeg-5.0


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

[Christian Hergert]

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

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.

I don't know if this is limited to generating ORC data from DWARF, but the
orc-unwinder documentation also refers to difficulty when dealing with inline
assembly. That would perhaps mean that this could end up being a lot of work
and still not fix the minor-annoyance of strlen/etc not showing up correctly.

There is also a risk that ORC data cannot represent the ever-increasing
optimizations from GCC.
___
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: [Rust] Rust Stack Spring Cleaning (July 2022 Edition)

[Miro Hrončok]

On 09. 07. 22 0:26, Fabio Valentini wrote:

In addition, I would ask of all of you to make sure all your packages have been
added to the @rust-sig group on src.fedoraproject.org (at least with "commit"
access), unless there is a very good reason not to do so (and if that is the
case for a particular package on this list, I'd be interested in knowing the
reason).


Should we escalate this trough FESCo? It seems to me that this makes sense as a 
policy and the maintainers you list here are always the same (mostly 
pbrobinson, salimma, ignatenkobrain).


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

Rust Stack Spring Cleaning (July 2022 Edition)

[Fabio Valentini]

Hello Rust packagers,

Following up on my previous emails, there are still a lot of Rust packages that
were imported to Fedora, but the recommended "initial setup" for them was never
finished.

I have started by adding them all "rust-*" packages to koschei, which makes it
way easier for me to see at a glance whether there are any broken packages in
our Rust stack at any point in time.

There is also the question about whether anitya release-monitoring.org is
actually set up for those packages, but I don't have an easy way to make
scripted checks for this yet. If you add new Rust packages to Fedora, please
make sure to set up release-monitoring with these settings:

  project: $crate
  homepage: https://crates.io/crates/$crate
  backend: crates.io
  version scheme: semantic
  version filter: alpha;beta;rc;pre
  distro: Fedora
  Package: rust-$crate

In addition, I would ask of all of you to make sure all your packages have been
added to the @rust-sig group on src.fedoraproject.org (at least with "commit"
access), unless there is a very good reason not to do so (and if that is the
case for a particular package on this list, I'd be interested in knowing the
reason).

Without that, it makes it very hard for us to keep the Rust stack
up-to-date and in working order, because the "rust-sig" list / bugzilla account
does not get CC'd on new bugs that way, and your bugs do not show up in our
BugZilla queries.

If you want a scripted way of adding "@rust-sig" group to many packages, you
can generate an API token on src.fedoraproject.org (with "Modify an existing
project") access level, and use the simple Python script from this GitHub gist:

https://gist.github.com/decathorpe/9d128982cb00e2d345d9e397372538ec

Below is the list of "incompletely set-up" packages, in alphabetic order, and
at the bottom, is a list per package maintainer.

Thanks,
Fabio / decathorpe



Maintainers per package:

- rust-arrayvec0.5: eclipseo
- rust-atomic-traits: salimma
- rust-aws-nitro-enclaves-cose: pbrobinson
- rust-blsctl: javierm
- rust-ciborium: pbrobinson
- rust-ciborium-io: pbrobinson
- rust-ciborium-ll: pbrobinson
- rust-clap_generate: eclipseo
- rust-clap_generate_fig: eclipseo
- rust-clircle: eclipseo
- rust-cryptoki: pbrobinson
- rust-cryptoki-sys: pbrobinson
- rust-cty: nickblack
- rust-dbus-codegen: pbrobinson
- rust-dbus-crossroads: pbrobinson
- rust-derivative: pbrobinson
- rust-esphome: dcavalca
- rust-helvum: salimma
- rust-is_ci: salimma
- rust-is_debug: atim
- rust-josekit: pbrobinson
- rust-js-sys: pbrobinson
- rust-keccak: pbrobinson
- rust-kvm-bindings: slp
- rust-kvm-ioctls: slp
- rust-libspa: salimma
- rust-libspa-sys: salimma
- rust-mptcp-pm: cathay4t
- rust-nu-engine: salimma
- rust-nu-parser: salimma
- rust-nu-protocol: salimma
- rust-oid: pbrobinson
- rust-openssl-kdf: pbrobinson
- rust-owo-colors: salimma
- rust-parsec-client: pbrobinson
- rust-parsec-interface: pbrobinson
- rust-phf0.8: ignatenkobrain
- rust-phf_generator0.8: ignatenkobrain
- rust-phf_macros0.8: ignatenkobrain
- rust-phf_shared0.8: ignatenkobrain
- rust-picky-asn1: pbrobinson
- rust-picky-asn1-der: pbrobinson
- rust-picky-asn1-x509: pbrobinson
- rust-pipewire: salimma
- rust-pipewire-sys: salimma
- rust-pkcs11: pbrobinson
- rust-process_control: atim, petersen
- rust-prost: pbrobinson
- rust-prost-build: pbrobinson
- rust-prost-derive: pbrobinson
- rust-prost-types: pbrobinson
- rust-psa-crypto: pbrobinson
- rust-psa-crypto-sys: pbrobinson
- rust-rsa: pbrobinson
- rust-rustcat: dcavalca
- rust-sd-notify: pbrobinson
- rust-secrecy: pbrobinson
- rust-serde_with: pbrobinson
- rust-sha3: pbrobinson
- rust-shadow-rs: atim
- rust-signal: salimma
- rust-simple_asn1: pbrobinson
- rust-starship-battery: atim
- rust-supports-color: salimma
- rust-supports-hyperlinks: salimma
- rust-supports-unicode: salimma
- rust-tss-esapi-sys: pbrobinson
- rust-universal-hash: pbrobinson
- rust-version: pbrobinson
- rust-versions: atim

Packages per maintainer:

- atim (5): rust-is_debug, rust-process_control, rust-shadow-rs,
rust-starship-battery, rust-versions
- cathay4t (1): rust-mptcp-pm
- dcavalca (2): rust-esphome, rust-rustcat
- eclipseo (4): rust-arrayvec0.5, rust-clap_generate,
rust-clap_generate_fig, rust-clircle
- ignatenkobrain (4): rust-phf0.8, rust-phf_generator0.8,
rust-phf_macros0.8, rust-phf_shared0.8
- javierm (1): rust-blsctl
- nickblack (1): rust-cty
- pbrobinson (35): rust-aws-nitro-enclaves-cose, rust-ciborium,
rust-ciborium-io, rust-ciborium-ll, rust-cryptoki, rust-cryptoki-sys,
rust-dbus-codegen, rust-dbus-crossroads, rust-derivative,
rust-josekit, rust-js-sys, rust-keccak, rust-oid, rust-openssl-kdf,
rust-parsec-client, rust-parsec-interface, rust-picky-asn1,
rust-picky-asn1-der, rust-picky-asn1-x509, rust-pkcs11, rust-prost,
rust-prost-build, rust-prost-derive, rust-prost-types,
rust-psa-crypto, rust-psa-crypto-sys, rust-rsa, rust-sd-notify,
rust-secrecy, 

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Adam Williamson]

On Fri, 2022-07-08 at 12:40 -0400, Ben Cotton wrote:
> Discussion of Microsoft Store policies is off-topic for this list. The
> Water Cooler category[1] on Fedora Discussion would be a good place to
> have this conversation.

Sorry, I sent my last reply before seeing this one.
-- 
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Adam Williamson]

On Fri, 2022-07-08 at 17:59 +0200, Vitaly Zaitsev via devel wrote:
> On 08/07/2022 17:48, Adam Williamson wrote:
> > That's not what that story says. It says you can't charge for them.
> > 
> > Additionally, Microsoft says[1] the intent is not to stop F/OSS
> > developers from charging for their own software, but to stop others
> > passing off for a profit. I agree that the current proposed wording is
> > at least ambiguous, but it would seem reasonable to see if Microsoft
> > updates it as they say they will.
> 
> They dropped Krita. Check out Krita's developer comment[1].

Um. That comment does not say that "they dropped Krita".
> 
> A lot of OSS application uses Microsoft Store for donations.

A donation is voluntary, and would not be affected by the policy. If
you mean lots of OSS applications put paid versions on store fronts to
try and get some income, sure, this is true, but that is not at all
what you originally claimed.

>  Now they 
> will be forced to become free or disappear from the Store.

You're ignoring the part about Microsoft saying that's not the intent
of the policy and that they would change it, but if that didn't happen,
potentially yes. But this is still not what you claimed. You claimed -
direct quote - "last week they decided to kill all OSS applications
from the Microsoft Store".

>  The GPL 
> doesn't prohibit selling if you provide the source code to customers.

Indeed it doesn't. How is that relevant?
-- 
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Demi Marie Obenour]

On 7/8/22 15:29, Christian Hergert wrote:
>> Frank Ch. Eigler mentions that elfutils has a more modern unwinding library. 
>> Could that perhaps solve your performance issues with libunwind?
> 
> I don't think so. The problem is two-fold.
> 
> First, we have to capture enough of the stack to do offline unwinding. I 
> think the default many people do here is about 8kb of stack. While the 
> instruction pointer array might fit in a couple cachelines, you now have an 
> additional few pages to copy as well. And you probably want those pages 
> aligned in your capture format. So no you need to interleave multiple types 
> of data frames while padding for alignment.
> 
> Now do that a few thousand times a second.
> 
> The overhead here can be so great that it obscures what you're trying to 
> find. Furthermore, it's a good chance that you'll cause CPU packages to spin 
> up to a higher frequency, thusly hiding the exact performance issues you want 
> to find or reduce to avoid that.
> 
> Now, say you've done the work and captured stacks (what has now turned from a 
> few MB recording to a few GB recording) you need to decode them. We keep many 
> lookaside-maps/interval-trees in Sysprof to keep this overhead low, but now 
> you have to reference .eh/DWARF data. This is the slowest part of the whole 
> process. What currently takes a second or two could take you easily 10 
> minutes.

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.


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

[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? If
the answer is yes, then I think we might talk about it for Fedora, as
well.

If the answer is no (because people from CERN would come banging at
Red Hat's doors, or something like that), then I don't think we should
do it in Fedora, either. Because I don't think we should treat Fedora
first and foremost as a development target, at the cost of making it
less appealing to actual users.
All the profiling and performance optimizations that might (or might
not be) found by developing on Fedora won't help us, if our users move
to some other distro that benefitted from those performance
optimizations, but of course didn't add those compiler flags, and
didn't make packages from their own distro perform worse to enable
this kind of work.

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

[Bug 2102629] Add perl-Class-Accessor-Grouped to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-377a90dbd1 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-377a90dbd1


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102629
___
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 2102643] Add perl-Class-Unload to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102643
___
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 2102645] Add perl-Context-Preserve to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-104264989e has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-104264989e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102645
___
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 2102650] Add perl-Math-Base36 to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-14600e13e3 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-14600e13e3


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102650
___
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 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Christian Hergert]

> Frank Ch. Eigler mentions that elfutils has a more modern unwinding library. 
> Could that perhaps solve your performance issues with libunwind?

I don't think so. The problem is two-fold.

First, we have to capture enough of the stack to do offline unwinding. I think 
the default many people do here is about 8kb of stack. While the instruction 
pointer array might fit in a couple cachelines, you now have an additional few 
pages to copy as well. And you probably want those pages aligned in your 
capture format. So no you need to interleave multiple types of data frames 
while padding for alignment.

Now do that a few thousand times a second.

The overhead here can be so great that it obscures what you're trying to find. 
Furthermore, it's a good chance that you'll cause CPU packages to spin up to a 
higher frequency, thusly hiding the exact performance issues you want to find 
or reduce to avoid that.

Now, say you've done the work and captured stacks (what has now turned from a 
few MB recording to a few GB recording) you need to decode them. We keep many 
lookaside-maps/interval-trees in Sysprof to keep this overhead low, but now you 
have to reference .eh/DWARF data. This is the slowest part of the whole 
process. What currently takes a second or two could take you easily 10 minutes.

Now I understand not everyone has ADHD like me, but I wont even remember what I 
was doing 10 minutes later.
___
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)

[Christian Hergert]

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

There are certainly places where it falls down still. Things like libffi, libc, 
encryption, hand-rolled assembler, etc as you mention. But since we still 
capture those stack traces as counting against the proper pid, it's often 
enough to allow you to dive deeper or see collateral damage. You might need to 
sort your callgraph a bit differently, but it's certainly possible in sysprof 
given the flexibility of the callgraph display.

> Does profiling individual applications file under "profiling by intuition" 
> for you? Because that is what I would expect developers to go back to if 
> systemwide profiling stops being viable.

I would say yes because you have to be intuitive about which application(s) or 
libraries matter.

When sysprof is working correctly, you can click record and have a decent 
understanding of where things are going wrong. That's a tough thing to 
replicate in a handful of terminals simultaneously displaying information which 
likely exacerbate desktop workloads on their own.

> And is it such a problem to require the handful developers who need to do 
> systemwide profiling to do that, instead of slowing down the production 
> installation for all users?

I think our goal should be to make it so easy that it's not just a handful of 
people doing system-wide profiling like it is today.

Using sysprof (or similar tool) as the first step in triage makes a lot of 
sense to me because it gives upstream a way to capture correlating information 
and visualize it in a useful manner. Despite being the author of the modern 
incarnation of Sysprof, I'm not against using pretty much anything else that 
works.

But here we are at an existential choice of what Fedora is. Are we for 
developers creating the platform(s)? Are we an optimized end-user distribution? 
If so where do the developers go that need to build these systems? Because it's 
clear to me that the status quo is often getting in the way for some of us.
___
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 2102686] Add perl-Package-Variant to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102686
___
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 2102648] Add perl-DateTime-Format-Pg to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

[Ben Cotton]

It's been a while since we've had some Prioritized Bugs that are
stuck, but here we are. If you can help move these forward, you are a
hero.

1. cmake — https://bugzilla.redhat.com/show_bug.cgi?id=2079833 — NEW
Get rid of multiple source path definitions

Versions of cmake prior to 3.23 accidentally permitted the source path
to be defined twice. Some Fedora packages relied on this behavior.
Upstream re-enabled the behavior, but the Fedora package has not been
updated to include this fix. As a result, some packages fail to build
in Rawhide.


For more information about the Fedora Prioritized Bugs process, see
https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/

-- 
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: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Steven A. Falco]

I like this proposal.  Is the intent to use the raw.xz image or the "iso + 
UEFI" mechanism?

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

[Ben Beasley]

I don’t think we should be gatekeeping who can propose or discuss a 
Change. I do think that the opinions of the upstream and downstream GCC 
maintainers should be weighed quite heavily when considering a change to 
the default compiler flags.


As a FESCo member, I’m waiting to see if the Change owners can present 
broadly convincing benchmarks to characterize the full performance 
impact of the proposal. I’m also paying close attention to the (so far 
mostly negative) input from the GCC team and others that I recognize as 
experts on toolchains, glibc, and optimization.


– Ben Beasley

On 7/6/22 17:39, Kevin Kofler via devel wrote:

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

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

On Wed, Jul 6, 2022 at 7: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?

Because basically the RPi is a 10 times ratio over pretty much all the
other devices we support.

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

See point above, but we DO support dozens of those devices you mention already.

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

Not at all, for years we've not officially supported, even though some
features have long worked, it as things like accelerated graphics
didn't work, this is exactly like what we need back in around Fedora
26 for the RPi3, see the Fedora magazine article from the time.

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

We already fully support the RockPro64, and it's sibling the Pinebook
Pro, plus a lot of other rk3399 based devices. They are all pretty
awesome. I did a whole bunch of the upstream support for a bunch of
those 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?

We already support a lot of Lenovo HW, we've blocked releases when
some of their HW support is broken.

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

It's basically more popular that pretty much all of the other boards
combined. Also this is as much about the marketing to let people know
that tried to make the RPi4 work and went away because accelerated
graphics didn't work.

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

Re: Orphaning some packages

[Simon de Vlieger]

Hey Christopher,

I can take over:

python-tenacity
python-typeguard

From you, my FAS account name is: supakeen

Regards,

Simon

On Fri, Jul 8, 2022, at 6:38 PM, Christopher Brown wrote:
> Hello,
>
> I've been doing a terrible job of maintaining these recently. Please 
> let me know if you would like to take over. Will orphan otherwise.
>
> python-tenacity
> python-typeguard
> rubygem-asciidoctor-pdf
> rubygem-chunky_png
> rubygem-css_parser
> rubygem-font-awesome-rails
> rubygem-pdf-core
> rubygem-prawn-icon
> rubygem-prawn-manual_builder
> rubygem-prawn-svg
> rubygem-prawn-templates
> stress-ng
>
> Thanks
> Christopher
> ___
> 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: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Peter Robinson]

On Thu, Jul 7, 2022 at 2:37 PM Ron Olson  wrote:
>
> I have a Pi 4 that runs Fedora just fine; I use it to build Swift (takes 
> almost 24 hours, but ¯\_(ツ)_/¯) so what doesn’t work? What podcast was this 
> mentioned on?

Core things have worked for some time, I know, I did the work, but
we've not officially *supported it*, there is quite a difference For
example no accelerated graphics  worked, a key thing for a lot of
people's use cases.

> On 6 Jul 2022, at 4:55, Neal Gompa wrote:
>
> > 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
> ___
> 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: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Peter Robinson]

On Thu, Jul 7, 2022 at 11:23 PM Sally A. Haj via devel
 wrote:
>
> Fist of all, thank you for the big amazing news for Fedora.
> I have some questions about the new support of V3D in Fedora, is that support 
> goes to upstream mainline Linux kernel? If yes, which release of Kernel has 
> that included?

It will be in 5.20

> If the that supports goes to upstream kernel, does that mean all Linux 
> Distros will get benefits from that to support rpis?

Of course, we in Fedora arm don't do it any other way.

> Do RaspberryPi Foundation developers aware of this news? and will they 
> involve in supporting such things in upstream kernel instead of only their 
> downstream?

No idea if they're aware, no they weren't involved although someone
involved in their community is. You would have to ask them of their
intentions. Broadcom reviewed some of the patches.

Frankly though questions about other communities/distros is off topic.
___
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: Orphaning some packages

[Fabio Valentini]

On Fri, Jul 8, 2022 at 6:39 PM Christopher Brown  wrote:
>
> Hello,
>
> I've been doing a terrible job of maintaining these recently. Please let me 
> know if you would like to take over. Will orphan otherwise.
>
> python-tenacity
> python-typeguard
> rubygem-asciidoctor-pdf
> rubygem-chunky_png
> rubygem-css_parser
> rubygem-font-awesome-rails
> rubygem-pdf-core
> rubygem-prawn-icon
> rubygem-prawn-manual_builder
> rubygem-prawn-svg
> rubygem-prawn-templates
> stress-ng

Note that you no longer need to to turn this into a two-step process
(for yourself) just "to be nice":
Adopting an orphaned package is now an instant action that only
requires pushing a button, and it does no longer require manual
intervention by Fedora infra or releng.
Additionally, "giving" a package to somebody manually is actually
*more* work than orphaning it directly (which is also only one button
click away).

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

Re: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Peter Robinson]

On Thu, Jul 7, 2022 at 7:05 PM Alec Leamas  wrote:
>
> Hi,
>
> On 07/07/2022 17:36, Onuralp SEZER wrote:
> >
> > For example can you run wayland, or usage of fully supported GPU usage,
> > Rs-pi's Camera usage, SPI , I2C , GPIO usages (PWM,Analog and others)
>
>
> Indeed. Also, the installation process has room for some improvements...

Please provide some constructive feedback on this rather than a drive
by comment that provides no context how you believe it could be
improved?
___
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-20220708.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 10/236 (x86_64), 16/165 (aarch64)

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

ID: 1319040 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1319040
ID: 1319152 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1319152
ID: 1319202 Test: aarch64 Workstation-upgrade desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/1319202
ID: 1319307 Test: aarch64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/1319307
ID: 1319333 Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1319333

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

ID: 1319015 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1319015
ID: 1319038 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1319038
ID: 1319044 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1319044
ID: 1319057 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1319057
ID: 1319063 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1319063
ID: 1319065 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1319065
ID: 1319090 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1319090
ID: 1319091 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1319091
ID: 1319102 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1319102
ID: 1319129 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1319129
ID: 1319162 Test: aarch64 Workstation-raw_xz-raw.xz help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1319162
ID: 1319163 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1319163
ID: 1319175 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1319175
ID: 1319184 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1319184
ID: 1319203 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1319203
ID: 1319212 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1319212
ID: 1319215 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1319215
ID: 1319216 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1319216
ID: 1319249 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1319249
ID: 1319294 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1319294
ID: 1319313 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1319313

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-20220707.n.0):

ID: 1319026 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1319026
ID: 1319064 Test: x86_64 Silverblue-dvd_ostree-iso clocks
URL: https://openqa.fedoraproject.org/tests/1319064
ID: 1319067 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1319067
ID: 1319078 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1319078
ID: 1319157 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1319157
ID: 1319173 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1319173
ID: 1319208 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1319208
ID: 1319224 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1319224
ID: 1319260 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1319260
ID: 1319296 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1319296
ID: 1319320 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: 

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Ben Cotton]

Discussion of Microsoft Store policies is off-topic for this list. The
Water Cooler category[1] on Fedora Discussion would be a good place to
have this conversation.

[1] https://discussion.fedoraproject.org/c/fun/8

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

Orphaning some packages

[Christopher Brown]

Hello,

I've been doing a terrible job of maintaining these recently. Please let me
know if you would like to take over. Will orphan otherwise.

python-tenacity
python-typeguard
rubygem-asciidoctor-pdf
rubygem-chunky_png
rubygem-css_parser
rubygem-font-awesome-rails
rubygem-pdf-core
rubygem-prawn-icon
rubygem-prawn-manual_builder
rubygem-prawn-svg
rubygem-prawn-templates
stress-ng

Thanks
Christopher
___
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: You can't ask Lennart Poettering because that account is disabled.

[Kevin Kofler via devel]

Vitaly Zaitsev via devel wrote:
> For example, last week they decided to kill all OSS applications from
> the Microsoft Store:
> 
https://www.reddit.com/r/linux/comments/vtxr9r/software_freedom_conservancy_heads_up_microsoft/

Actually, what they did there actually makes sense to me. The rule prohibits 
you from charging for FOSS that is available at no cost elsewhere. So you 
cannot abuse the Microsoft Store monopoly to charge for otherwise free-as-
in-beer software. Now, this would not be an issue if there were not such a 
monopoly store in the first place, but in the current situation, it is 
actually a reasonable policy, and it would make sense for, e.g., Apple to 
enforce the same policy on their app store (but since it would also mean 
them losing out on their cut of the sales, I doubt they will do so any time 
soon).

Would you want upstreams to start charging Fedora users, and only Fedora 
users, for their software? Say, through some paid Flatpak distribution 
channel that gets added to "third-party software" the same way Flathub is 
being added now, and through not making RPMs or even Flathub Flatpaks 
available anymore? I guess 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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Vitaly Zaitsev via devel]

On 08/07/2022 17:48, Adam Williamson wrote:

That's not what that story says. It says you can't charge for them.

Additionally, Microsoft says[1] the intent is not to stop F/OSS
developers from charging for their own software, but to stop others
passing off for a profit. I agree that the current proposed wording is
at least ambiguous, but it would seem reasonable to see if Microsoft
updates it as they say they will.


They dropped Krita. Check out Krita's developer comment[1].

A lot of OSS application uses Microsoft Store for donations. Now they 
will be forced to become free or disappear from the Store. The GPL 
doesn't prohibit selling if you provide the source code to customers.


[1]: https://www.reddit.com/r/linux/comments/vtxr9r/comment/ifb7hgk/

--
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Adam Williamson]

On Fri, 2022-07-08 at 17:20 +0200, Vitaly Zaitsev via devel wrote:
> On 08/07/2022 16:14, Matthew Miller wrote:
> > And Microsoft is not the 1990s Microsoft. They know that
> > they need to do this differently and I know there are people (actual, real,
> > humans!) who care about open source and making Linux better for everyone.
> > And now that includes Lennart.
> 
> No. Microsoft will always be hostile to Open Source, no matter what they 
> say in public.
> 
> For example, last week they decided to kill all OSS applications from 
> the Microsoft Store:
> https://www.reddit.com/r/linux/comments/vtxr9r/software_freedom_conservancy_heads_up_microsoft/

That's not what that story says. It says you can't charge for them.

Additionally, Microsoft says[1] the intent is not to stop F/OSS
developers from charging for their own software, but to stop others
passing off for a profit. I agree that the current proposed wording is
at least ambiguous, but it would seem reasonable to see if Microsoft
updates it as they say they will.

[1]: https://twitter.com/gisardo/status/1544741955145502724
-- 
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

[EPEL-devel] Re: EL7 - Invalid version flag: or

[Justin Schoeman]

On 2022/07/08 16:54, Troy Dawson wrote:



On Fri, Jul 8, 2022 at 7:32 AM Justin Schoeman 
 wrote:


Good day,

Apologies if this is the wrong place to report this (or if this is
just
a piece of idiocy on my part).

Recently, I have started getting the following messages with 'yum
update
--security' on some of my Centos 7 installations:

"


  Package         Arch              Version Repository       Size


Updating:
  dkms            noarch            3.0.5-1.el7 epel             59 k

Transaction Summary


Upgrade  1 Package
Updates failed to install with the following error message:
Invalid version flag: or
"

This first occurred in chromium, and now dkms updates.

I have tried upgrading all the yum and rpm packages without any
luck.  Some googling shows that the 'or' flag is not (and will not
be) supported by the yum version in Centos 7.

Are the Epel builds indeed now being made with RPM flags not
supported by yum, or is something deeply fubar with my installation?

I have a sneaky feeling something is messed up on my side, or
there would be a lot of similar complaints on the internet, but I
find nothing.

Any feedback/advice would be appreciated,

Thanks,
Justin


I hate to say it's on your side, but I think it is.
I installed an old version of dkms on my centos 7 machine and got the 
following


# yum update --security
--> dkms-3.0.2-1.el7.noarch from @/dkms-3.0.2-1.el7.noarch removed 
(updateinfo)

--> dkms-3.0.5-1.el7.noarch from epel removed (updateinfo)
No packages needed for security; 1 packages available
Resolving Dependencies

My first guess at the problem is that something got tweaked with 
/etc/yum/version-groups.conf

There is a "yum version" command, and that is the file associated with it.
My second guess would be something in /etc/yum/vars/
After that, I'd get desperate and do greps of "or" in all /etc/yum/ 
/etc/yum.conf and /etc/yum.repos.d/


Troy

Oops. 'yum version' on its own returns the same error, so it is not to 
do with the package installation.


Sorry for bugging the list with a user error, and thanks for the tips.

Justin

___
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Vitaly Zaitsev via devel]

On 08/07/2022 16:14, Matthew Miller wrote:

And Microsoft is not the 1990s Microsoft. They know that
they need to do this differently and I know there are people (actual, real,
humans!) who care about open source and making Linux better for everyone.
And now that includes Lennart.


No. Microsoft will always be hostile to Open Source, no matter what they 
say in public.


For example, last week they decided to kill all OSS applications from 
the Microsoft Store:

https://www.reddit.com/r/linux/comments/vtxr9r/software_freedom_conservancy_heads_up_microsoft/

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

[Demi Marie Obenour]

On 7/7/22 16:13, Christian Hergert wrote:
> Sysprof has modular data collection backends, and not everything requires 
> linking against libunwind.
> 
> For those not familiar with Sysprof, or profiling the desktop at large, 
> generally a single program is not the problem. The performance problems often 
> exist across a number of processes. That can be anything from a library used 
> by multiple applications which cumulatively waste resources, IPC across 
> programs, thundering herds when files on disk change, GPU usage, CPU 
> frequency scaling, memory bandwidth, RAPL, etc.
> 
> So Sysprof has a binary logging format that is straight-forward, efficient, 
> and allows us to record many different types of information within a single 
> file. That file format is used by a number of tools in the stack from GLib, 
> Pango, Gtk, Mutter, GNOME Shell, GJS, various libraries, and applications on 
> top of it. It can capture counters, stack traces, file contents, marks, logs, 
> and a multitude of other data frames.
> 
> These capture files can also be muxed together at any point.
> 
> Some of the modular data collectors require libunwind, many do not. For 
> example, the memprof collector records the backtraces from malloc/free/etc. 
> But the GJS data-collector can use SpiderMonkey's internal APIs to get 
> backtraces from a SIGPROF sigaction. The most used collector, however, is the 
> perf collector which is just reading from a perf fd mmap'd into a ring buffer.
> 
> The perf collector doesn't record the whole stack because the amount of time 
> it takes to decode a 30 second system-wide capture with DWARF/etc is so slow 
> practically nobody would use it.
> 
> The best profiler is the one people will use.
> 
> We have an in-tree parser for ELF that allows us to avoid a lot of extraneous 
> code when extracting symbols. Partially because libunwind is incredibly slow 
> (by profiler requirements), and partially because historically we never had 
> to stash stack frames for contextual unwinding.
> 
> Could we write a new data collection module that does DWARF unwinding and 
> stashes some 8kb of stack? Sure. Would people use it? Probably not, because 
> again, it's so slow that people will start profiling by intuition again which 
> is probably the worst of all options.
Of course stashing the stack is not a good option.  I just don’t
think frame pointers are a good solution either.  The correct solution
(albeit the most difficult one) is to find a way to perform efficient
profiling without frame pointers.  I do not have the resources to
write such a solution, but I am almost certain that Meta does.

> Can we write a eBPF kernel module to decode symbols there? Maybe? Can I? 
> Probably not.

Somebody else could, though.  And it would not make the people who do
not do system-wide profiling pay the price that frame pointers enact.
Windows can do profiling without having to use frame pointers.
There is no reason that Linux cannot as well.

> Personally, I think some libraries should not be compiled with 
> -fno-omit-frame-pointer. However, I think that number is much smaller than 
> the opposite. Encryption, graphics drivers, etc all seem like good candidates 
> here to be explicit about performance requirements.

Many encryption libraries will generally not have a frame pointer
because much of the actual encryption code is hand-written assembler.
glibc string functions do not maintain a frame pointer either.
-- 
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 reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EL7 - Invalid version flag: or

[Troy Dawson]

On Fri, Jul 8, 2022 at 7:32 AM Justin Schoeman 
wrote:

> Good day,
>
> Apologies if this is the wrong place to report this (or if this is just
> a piece of idiocy on my part).
>
> Recently, I have started getting the following messages with 'yum update
> --security' on some of my Centos 7 installations:
>
> "
>
> 
>   Package Arch  VersionRepository
>  Size
>
> 
> Updating:
>   dkmsnoarch3.0.5-1.el7epel
>  59 k
>
> Transaction Summary
>
> 
> Upgrade  1 Package
> Updates failed to install with the following error message:
> Invalid version flag: or
> "
>
> This first occurred in chromium, and now dkms updates.
>
> I have tried upgrading all the yum and rpm packages without any luck.
> Some googling shows that the 'or' flag is not (and will not be) supported
> by the yum version in Centos 7.
>
> Are the Epel builds indeed now being made with RPM flags not supported by
> yum, or is something deeply fubar with my installation?
>
> I have a sneaky feeling something is messed up on my side, or there would
> be a lot of similar complaints on the internet, but I find nothing.
>
> Any feedback/advice would be appreciated,
>
> Thanks,
> Justin
>

I hate to say it's on your side, but I think it is.
I installed an old version of dkms on my centos 7 machine and got the
following

# yum update --security
--> dkms-3.0.2-1.el7.noarch from @/dkms-3.0.2-1.el7.noarch removed
(updateinfo)
--> dkms-3.0.5-1.el7.noarch from epel removed (updateinfo)
No packages needed for security; 1 packages available
Resolving Dependencies

My first guess at the problem is that something got tweaked with
/etc/yum/version-groups.conf
There is a "yum version" command, and that is the file associated with it.
My second guess would be something in /etc/yum/vars/
After that, I'd get desperate and do greps of "or" in all /etc/yum/
/etc/yum.conf and /etc/yum.repos.d/

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

[EPEL-devel] EL7 - Invalid version flag: or

[Justin Schoeman]

Good day,

Apologies if this is the wrong place to report this (or if this is just 
a piece of idiocy on my part).


Recently, I have started getting the following messages with 'yum update 
--security' on some of my Centos 7 installations:


"

 Package Arch  VersionRepository   Size

Updating:
 dkmsnoarch3.0.5-1.el7epel 59 k

Transaction Summary

Upgrade  1 Package
Updates failed to install with the following error message:
Invalid version flag: or
"

This first occurred in chromium, and now dkms updates.

I have tried upgrading all the yum and rpm packages without any luck.  Some 
googling shows that the 'or' flag is not (and will not be) supported by the yum 
version in Centos 7.

Are the Epel builds indeed now being made with RPM flags not supported by yum, 
or is something deeply fubar with my installation?

I have a sneaky feeling something is messed up on my side, or there would be a 
lot of similar complaints on the internet, but I find nothing.

Any feedback/advice would be appreciated,

Thanks,
Justin
___
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Paul Wouters]

On Fri, 8 Jul 2022, Kevin Kofler via devel wrote:


But upstream is now under a hostile corporation's control? Can we trust the
most privileged userspace program when it is effectively controlled by a
hostile corporation?


Yes we can, by reading and evaluating the code like we always do. If it
starts to deviate from our needs and requirements, we can change things.

If Fedora was too depending on one person, this change would be good as
in that case we should have diversified these things already before and
now we would be forced to do so if that is problem.

Lennart might not be the easiest person to work with, and I have had
my personal disagreements with him, but he has never been a malicious
person and I don't expect him to suddenly become one.

I wish him luck on his new adventures.

Paul
___
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: You can't ask Lennart Poettering because that account is disabled.

[Daniel P . Berrangé]

On Fri, Jul 08, 2022 at 04:08:55PM +0200, Kevin Kofler via devel wrote:
> Peter Robinson wrote:
> > Why? There's other maintainers, and he's not been the lead maintainer
> > in Fedora for some time.
> 
> But upstream is now under a hostile corporation's control? Can we trust the 
> most privileged userspace program when it is effectively controlled by a 
> hostile corporation?

Can you please stop with the baseless accusations and FUD.

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

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Kevin Kofler via devel]

Neal Gompa wrote:
> Microsoft has people working on a number of core Linux projects ever
> since they started making their own Linux distribution.

It is fun how the old
https://web.archive.org/web/20220312030903/http://www.mslinux.org/
joke has suddenly become reality.

I hope we are not getting Embraced…

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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Matthew Miller]

On Fri, Jul 08, 2022 at 04:08:55PM +0200, Kevin Kofler via devel wrote:
> But upstream is now under a hostile corporation's control? Can we trust the 
> most privileged userspace program when it is effectively controlled by a 
> hostile corporation?

Let's please not do this. Upstream is an LGPL project (without a CLA). It is
not a black box. And Microsoft is not the 1990s Microsoft. They know that
they need to do this differently and I know there are people (actual, real,
humans!) who care about open source and making Linux better for everyone.
And now that includes Lennart.

-- 
Matthew Miller

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

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Neal Gompa]

On Fri, Jul 8, 2022 at 10:09 AM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > Why? There's other maintainers, and he's not been the lead maintainer
> > in Fedora for some time.
>
> But upstream is now under a hostile corporation's control? Can we trust the
> most privileged userspace program when it is effectively controlled by a
> hostile corporation?
>

You missed the boat there. The systemd project has several upstream
maintainers, and Lennart isn't even the first one that works at
Microsoft. I know of at least one other that is in project leadership
there that has been working at Microsoft for a while.

The world didn't end, so *shrugs*



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

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Kevin Kofler via devel]

Peter Robinson wrote:
> Why? There's other maintainers, and he's not been the lead maintainer
> in Fedora for some time.

But upstream is now under a hostile corporation's control? Can we trust the 
most privileged userspace program when it is effectively controlled by a 
hostile corporation?

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: [Reminder] CfP open for Nest with Fedora

[Marie Nordin]

Hey folks,



The deadline for the Nest with Fedora CfP submissions is extended until
next Wednesday, July 13th! Make sure to submit your ideas on the Flock
Pagure repo: https://pagure.io/flock/issues



Registration is also open: https://hopin.com/events/nest-with-fedora-2022



Cheers!

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

IRC/Element: riecatnor





On Fri, Jun 24, 2022 at 10:26 AM Marie Nordin  wrote:

> Hi there Fedorans,
>
> It's time to submit your proposals for Nest with Fedora! The event will be
> held virtually on August 4th, 5th, and 6th. This is a great opportunity to
> share what you have been doing in the project and connect with your fellow
> Fedorans :)
>
> *The final deadline for the CfP is July 8th. *
>
> *Submit your proposals on the Flock pagure repo:*
> https://pagure.io/flock/issues
>
> *More info about the CfP:*
> https://communityblog.fedoraproject.org/nest-2022-cfp/
>
> *More info about Nest: *
>
> https://communityblog.fedoraproject.org/nest-with-fedora-fedora-hatch-announcing-dates-call-for-volunteers/
>
> Can't wait to see your proposals!
> Best,
>
> --
>
> Marie Nordin
>
> Fedora Community Action and Impact Coordinator
>
> Red Hat  • Fedora Project
> 
>
> She/Her/Hers
>
> IRC/Element: riecatnor
>
>
> 
>
___
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

Re: [Reminder] CfP open for Nest with Fedora

[Marie Nordin]

Hey folks,



The deadline for the Nest with Fedora CfP submissions is extended until
next Wednesday, July 13th! Make sure to submit your ideas on the Flock
Pagure repo: https://pagure.io/flock/issues



Registration is also open: https://hopin.com/events/nest-with-fedora-2022



Cheers!

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

IRC/Element: riecatnor





On Fri, Jun 24, 2022 at 10:26 AM Marie Nordin  wrote:

> Hi there Fedorans,
>
> It's time to submit your proposals for Nest with Fedora! The event will be
> held virtually on August 4th, 5th, and 6th. This is a great opportunity to
> share what you have been doing in the project and connect with your fellow
> Fedorans :)
>
> *The final deadline for the CfP is July 8th. *
>
> *Submit your proposals on the Flock pagure repo:*
> https://pagure.io/flock/issues
>
> *More info about the CfP:*
> https://communityblog.fedoraproject.org/nest-2022-cfp/
>
> *More info about Nest: *
>
> https://communityblog.fedoraproject.org/nest-with-fedora-fedora-hatch-announcing-dates-call-for-volunteers/
>
> Can't wait to see your proposals!
> Best,
>
> --
>
> Marie Nordin
>
> Fedora Community Action and Impact Coordinator
>
> Red Hat  • Fedora Project
> 
>
> She/Her/Hers
>
> IRC/Element: riecatnor
>
>
> 
>
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Neal Gompa]

On Fri, Jul 8, 2022 at 9:34 AM Chris Adams  wrote:
>
> Once upon a time, Kevin Kofler  said:
> > Luna Jernberg wrote:
> > > https://www.phoronix.com/scan.php?page=news_item=Systemd-Creator-Microsoft
> > > https://linuxactionnews.com/248
> >
> > Time to remove systemd from the distribution?
>
> What part of Free and Open says "judge people based on their employer"?
> That's a rude personal attack.

Microsoft has people working on a number of core Linux projects ever
since they started making their own Linux distribution. The likely
reality is that Microsoft made a compelling offer to employ him and
Red Hat just didn't want to counter to keep him. It happens.



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

Re: HEADS UP: tesseract-5.2.0 coming to rawhide

[Sandro Mani]

On 08.07.22 09:46, Sandro Mani wrote:


Hi

I'll update to tesseract-5.2.0 in rawhide, and rebuild affected 
packages as listed below. I'll do the work in the side tag 
f37-build-side-54886.



Done now, all build succeeded.

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

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Chris Adams]

Once upon a time, Kevin Kofler  said:
> Luna Jernberg wrote:
> > https://www.phoronix.com/scan.php?page=news_item=Systemd-Creator-Microsoft
> > https://linuxactionnews.com/248
> 
> Time to remove systemd from the distribution?

What part of Free and Open says "judge people based on their employer"?
That's a rude personal attack.
-- 
Chris Adams 
___
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 2105300] perl-Crypt-OpenSSL-RSA-0.33 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Crypt-OpenSSL-RSA-0.33-1.fc36.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=89236067


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105300
___
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 2105300] perl-Crypt-OpenSSL-RSA-0.33 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1895416
  --> https://bugzilla.redhat.com/attachment.cgi?id=1895416=edit
Update to 0.33 (#2105300)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105300
___
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 2105300] New: perl-Crypt-OpenSSL-RSA-0.33 is available

[bugzilla]

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

Bug ID: 2105300
   Summary: perl-Crypt-OpenSSL-RSA-0.33 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Crypt-OpenSSL-RSA
  Keywords: FutureFeature, Triaged
  Assignee: wjhns...@hardakers.net
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
wjhns...@hardakers.net
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.33
Upstream release that is considered latest: 0.33
Current version/release in rawhide: 0.32-5.fc37
URL: http://search.cpan.org/dist/Crypt-OpenSSL-RSA/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2748/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-RSA


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105300
___
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Peter Robinson]

On Fri, Jul 8, 2022 at 2:05 PM Kevin Kofler via devel
 wrote:
>
> Luna Jernberg wrote:
> > https://www.phoronix.com/scan.php?page=news_item=Systemd-Creator-Microsoft
> > https://linuxactionnews.com/248
>
> Time to remove systemd from the distribution?

Why? There's other maintainers, and he's not been the lead maintainer
in Fedora for some time.
___
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: You can't ask Lennart Poettering because that account is disabled.

[Kevin Kofler via devel]

Luna Jernberg wrote:
> https://www.phoronix.com/scan.php?page=news_item=Systemd-Creator-Microsoft
> https://linuxactionnews.com/248

Time to remove systemd from the distribution?

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: Fedora SCM requests on the weekend

[Mukundan Ragavan]

> 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?
___
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 2105287] New: Please branch and build perl-Net-SSH in epel9

[bugzilla]

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

Bug ID: 2105287
   Summary: Please branch and build perl-Net-SSH in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Net-SSH
  Assignee: jples...@redhat.com
  Reporter: dma...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Net-SSH in epel9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105287
___
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 2105286] New: Please branch and build perl-Net-SSH in epel8

[bugzilla]

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

Bug ID: 2105286
   Summary: Please branch and build perl-Net-SSH in epel8
   Product: Fedora EPEL
   Version: epel8
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Net-SSH
  Severity: medium
  Assignee: jples...@redhat.com
  Reporter: dma...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Net-SSH in epel8.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105286
___
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: Suggestion: Use a unified kernel image by default in the future.

[Simon Farnsworth via devel]

On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote:
> If it is really compromised, then you have to assume anything the vm sends
> you is fake. As far as the owner of guest knows, there could not even a a
> real vm, only a ssh shell that looks like it.
 
> In a real situation, the guest owner would send the host owner a "starting
> disk" or ISO. Then the host would tell the trusted cpu to boot a iso that
> sends the signature to the host, and also boot a modified iso in a normal
> hypervisor, and emulate the trusted part of the cpu. When the normal
> hypervisor vm wants the signature, the signature of vm1 is returned. The
> system in the normal hypervisor could also just lie to any connections
> outside the host system, so even if it knows its backdoored, it still test
> the guest owner its not.

This is a solved problem, and you need to read up on how remote attestation 
works in the presence of an attacker to understand fully how it's solved.

The core to the trick is that the CPU prevents the hypervisor from seeing into 
the state that belongs to the guest (measurements, memory content etc), unless 
the guest explicitly tells the CPU to share that memory. It does this using 
cryptographic primitives so that even an attacker who can monitor the DRAM bus 
externally to the CPU cannot see into guest state.

You can thus use key exchange protocols designed to work over a public channel 
(Diffie-Hellman for a simple example) to set up an encrypted channel between 
the 
guest and the remote system such that the hypervisor can only deny service - 
it cannot see into the channel, and thus cannot lie to the guest or its remote 
attestation service.

The same techniques are used in TLS to set up a secure channel between a 
service provider like https://start.fedoraproject.org/ and a user like my 
Fedora laptop

-- 
Simon Farnsworth

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

Theodore Papadopoulo wrote:
> gdb and similar tools are confused, notably because local variables are
> "optimsed out" (which I suspect is related to frame pointer).

It is not.

This is related to compiling with any optimization at all, and you 
definitely do not want production binaries compiled without optimization 
(with -O0), they would be extremely slow and large.

Local variables are allocated to registers for as long as they are needed, 
and then evicted (overwritten by other data that needs the register) when 
the compiler finds they are "dead", i.e., no longer referenced in the rest 
of the function. Only when no registers are left, the variables are 
"spilled" to the stack (which is the only place where the frame pointer 
makes a difference, and only in the way the variables are accessed, i.e., 
they can be accessed relative to %rfp rather than %rsp). And some variables 
can be optimized out entirely, e.g., by inlining them into the computation 
of some other variable.

If anything, enabling the frame pointer will make it *more* likely that 
variables get optimized out because there will be one fewer register to use 
to hold their contents.

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

Soliciting feedback for Nest talk proposal about Python rebuilds in Fedora

[Miro Hrončok]

Hello,

we have proposed a talk for Nest:

"Python rebuilds in Fedora: How do we do it, what changed with 3.11"
https://pagure.io/flock/issue/396

If it sounds interesting to you, please comment in the ticket.
If you have some ideas about what to include, feel free to share that as well.

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

Fedora rawhide compose report: 20220708.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220707.n.0
NEW: Fedora-Rawhide-20220708.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  3
Dropped packages:0
Upgraded packages:   123
Downgraded packages: 0

Size of added packages:  21.28 MiB
Size of dropped packages:0 B
Size of upgraded packages:   9.72 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20220708.n.0.iso
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20220708.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: ocaml-camlp-streams-5.0.1-1.fc37
Summary: Stream and Genlex libraries for OCaml
RPMs:ocaml-camlp-streams ocaml-camlp-streams-devel
Size:222.46 KiB

Package: ocaml-ppx-import-1.10.0-1.fc37
Summary: Syntax extension for importing declarations from interface files
RPMs:ocaml-ppx-import ocaml-ppx-import-devel
Size:18.72 MiB

Package: python-neatdend-0.9.2-4.fc37
Summary: NEAT (NEural Analysis Toolkit)
RPMs:python3-neatdend
Size:2.34 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  amanda-3.5.1-36.fc37
Old package:  amanda-3.5.1-33.fc36
Summary:  A network-capable tape backup solution
RPMs: amanda amanda-client amanda-libs amanda-server
Size: 8.19 MiB
Size change:  -40.28 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
3.5.1-34
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Wed Jun 01 2022 Jitka Plesnikova  - 3.5.1-35
  - Perl 5.36 rebuild

  * Thu Jul 07 2022 Jason L Tibbitts III  - 3.5.1-36
  - Add patch to fix bug which caused a failing test.  Thanks to Peter Bieringer
for the patch.


Package:  ansible-core-2.13.1-2.fc37
Old package:  ansible-core-2.13.1-1.fc37
Summary:  A radically simple IT automation system
RPMs: ansible-core ansible-core-doc
Size: 4.47 MiB
Size change:  -2.05 KiB
Changelog:
  * Thu Jul 07 2022 Miro Hron??ok  - 2.13.1-2
  - Don't put -- into Python shebangs


Package:  ansible-freeipa-1.8.1-1.fc37
Old package:  ansible-freeipa-1.8.0-1.fc37
Summary:  Roles and playbooks to deploy FreeIPA servers, replicas and 
clients
RPMs: ansible-freeipa ansible-freeipa-tests
Size: 401.77 KiB
Size change:  958 B
Changelog:
  * Thu Jul 07 2022 Thomas Woerner  - 1.8.1-1
  - Update to version 1.8.1
https://github.com/freeipa/ansible-freeipa/releases/tag/v1.8.1


Package:  ark-22.04.3-1.fc37
Old package:  ark-22.04.2-1.fc37
Summary:  Archive manager
RPMs: ark ark-libs
Size: 6.48 MiB
Size change:  666 B
Changelog:
  * Thu Jul 07 2022 Than Ngo  - 22.04.3-1
  - 22.04.3


Package:  blender-1:3.2.0-7.fc37
Old package:  blender-1:3.2.0-3.fc37
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 158.89 MiB
Size change:  145.56 KiB
Changelog:
  * Tue Jun 28 2022 Python Maint  1:3.2.0-4
  - Rebuilt for Python 3.11

  * Wed Jul 06 2022 Benjamin A. Beasley  1:3.2.0-5
  - Backport Python 3.11 support (close RHBZ#2098675)
  - Backport the fix for upstream bug T99277 ???Fails to compile on Python
3.11b3 due to opaque PyFrameObject???, along with a related commit
improving support for Python releases newer than 3.7.
  - Add an additional patch required for Python 3.11b3 but not for later
Python 3.11 pre-releases. This is downstream-only for now, but the
concept was suggested upstream as a potential general improvement.

  * Wed Jul 06 2022 Benjamin A. Beasley  1:3.2.0-6
  - Remove trailing whitespace in the spec file

  * Thu Jul 07 2022 Benjamin A. Beasley  1:3.2.0-7
  - Replace a downstream patch with an upstream one
  - Backport upstream commit 378f65f7d9843ea789a66623019163f935af141e as
0004-Fix-Py-driver-byte-code-access-with-Python-3.11.patch, replacing
downstream patch 0001-Support-Python-3.11b3.patch


Package:  ceph-2:17.2.1-3.fc37
Old package:  ceph-2:17.2.1-2.fc37
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards 
ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm 
ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents 
ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts 
ceph-radosgw ceph-resource-agents ceph-selinux ceph-test ceph-volume cephadm 
cephfs-java cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 
libcephfs_jni-devel libcephfs_jni1 libcephsqlite libcephsqlite-devel 
librados-devel librados2 libradospp-devel libradosstriper-devel 
libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 
python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados 
python3-rbd python3-rgw rados

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

[Daniel P . Berrangé]

On Thu, Jul 07, 2022 at 08:13:52PM -, Christian Hergert wrote:
> Sysprof has modular data collection backends, and not everything
> requires linking against libunwind.
> 
> For those not familiar with Sysprof, or profiling the desktop at
> large, generally a single program is not the problem. The performance
> problems often exist across a number of processes. That can be anything
> from a library used by multiple applications which cumulatively waste
> resources, IPC across programs, thundering herds when files on disk
> change, GPU usage, CPU frequency scaling, memory bandwidth, RAPL, etc.

That problem's not unique to the desktop space, it applies across
any non-trivial usage of the OS, whether down at the base infrastructure
level, or over at server applications too. IOW, don't think of 'sysprof'
as only a tool for the desktop developers, what you describe is broadly
applicable to any and all. Profiling on Linux is indeed an exercise in
frustration much of the time, and recently I find myself turning to
sysprof more than other options for analysing problems around the virt 
stack.

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

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

[Kevin Kofler via devel]

PS: One more question:

Christian Hergert wrote:
> We have an in-tree parser for ELF that allows us to avoid a lot of
> extraneous code when extracting symbols. Partially because libunwind is
> incredibly slow (by profiler requirements), and partially because
> historically we never had to stash stack frames for contextual unwinding.

Frank Ch. Eigler mentions that elfutils has a more modern unwinding library. 
Could that perhaps solve your performance issues with libunwind?

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]

Christian Hergert wrote:
> For those not familiar with Sysprof, or profiling the desktop at large,
> generally a single program is not the problem. The performance problems
> often exist across a number of processes.
[…]
> The most used collector, however, is the perf collector which is just
> reading from a perf fd mmap'd into a ring buffer.

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.

> The perf collector doesn't record the whole stack because the amount of
> time it takes to decode a 30 second system-wide capture with DWARF/etc is
> so slow practically nobody would use it.

So this is basically the same issue that Facebook is having.

> Could we write a new data collection module that does DWARF unwinding and
> stashes some 8kb of stack? Sure. Would people use it? Probably not,
> because again, it's so slow that people will start profiling by intuition
> again which is probably the worst of all options.

Does profiling individual applications file under "profiling by intuition" 
for you? Because that is what I would expect developers to go back to if 
systemwide profiling stops being viable.

> To my knowledge, we don't have this tooling anywhere else on Fedora. The
> sad part is, those who want to casually drive by and fix performance start
> with "recompile the stack with jhbuild" or I guess RPMs/koji if you're
> into that sort of thing.

And is it such a problem to require the handful developers who need to do 
systemwide profiling to do that, instead of slowing down the production 
installation for all users?

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

[Bug 2103076] perl-Devel-FindPerl-0.016 is available

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

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



--- Comment #3 from Michal Josef Spacek  ---
Changes:
0.016 2022-07-01 12:37:45+02:00 Europe/Amsterdam
  Delete %ENV entries after localizing them to bypass taint

For Fedora rawhide


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2103076
___
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 2105085] perl-HTTP-Daemon: HTTP::Daemon allows request smuggling

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

  Flags||needinfo?(amctagga@redhat.c
   ||om)



--- Comment #3 from Michal Josef Spacek  ---
@amcta...@redhat.com Could you please rename this ticket to mention
CVE-2022-31081 only? For issue with perl-HTTP-Daemon.


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

New zlib-1.2.12-3 in Fedora Rawhide

[Lukas Javorsky]

Hi,

After a few issues with the new zlib-1.2.12 release [1], we fixed the
incompatible issue spotted in ruby package [2].

I would like to announce the new zlib-1.2.12-3 package that is now present
in Fedora Rawhide [3].

This release also brings some new IBM performance optimizations which are
mentioned in the tracking Bugzilla [4].

[1] https://pagure.io/releng/issue/10875
[2] https://github.com/ruby/spec/issues/932#event-6933754688
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2022-1bd6fd68f5
[4] https://bugzilla.redhat.com/show_bug.cgi?id=2069002

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
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-35-20220708.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-20220707.0):

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

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

[Bug 2105100] perl-Chart-2.403.0 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Chart-2.403.0-1.fc37
 Status|ASSIGNED|MODIFIED



--- Comment #1 from Petr Pisar  ---
An enhancement release. It replaces a PDF documentation with PODs. Suitable for
Fedora ≥ 37.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105100
___
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 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Theodore Papadopoulo]

On 7/6/22 08:30, Vitaly Zaitsev via devel wrote:

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.

I agree that it works well  (at least better than with most competing 
OSes), but that does not mean it works perfectly and that it's not 
improvable.
I must say that global debugging capabilities have decreased with time 
since 20 years. More and more, one needs to rely on "debugging by 
printf" because
gdb and similar tools are confused, notably because local variables are 
"optimsed out" (which I suspect is related to frame pointer). This is a 
price to
pay to better optimisation and performance, but leads to more time spent 
to find the place of a bug.


So yes it works well, but it could be better Now at which cost for 
the overall community, this is another story.


  Theo.
___
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 2105100] perl-Chart-2.403.0 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105100
___
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 2105085] perl-HTTP-Daemon: HTTP::Daemon allows request smuggling

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
I think CVE-2022-31081  is for
HTTP-Deamon. CVE-2022-31082 
is for the unrelated GLPI.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2105085
___
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 2105085] perl-HTTP-Daemon: HTTP::Daemon allows request smuggling

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
The description is about a completely different bug in an unrelated software.

The HTTP-Deamon bug is reported to upstream at
.


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

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

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

HEADS UP: tesseract-5.2.0 coming to rawhide

[Sandro Mani]

Hi

I'll update to tesseract-5.2.0 in rawhide, and rebuild affected packages 
as listed below. I'll do the work in the side tag f37-build-side-54886.


Thanks

Sandro

---

Affected packages:

ffmpeg
gimagereader
mupdf
opencv
python-PyMuPDF
R-tesseract
zathura-pdf-mupdf

___
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 2105070] dovecot: Privilege escalation possible in dovecot when similar master and non-master passdbs are used

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC|jples...@redhat.com,|
   |perl-devel@lists.fedoraproj |
   |ect.org |



--- Comment #1 from Petr Pisar  ---
dovecot is not maintained by jplesnik, removing from CC.


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