Re: F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)

[Orion Poplawski]

On 4/19/22 09:54, Kevin Fenzi wrote:

This change has been reworked...

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

If folks could take a fresh look and see if this addresses their
concerns, that would be great.

kevin
It mentions dropping i686 Java in March.  We're past that :)  Bugs have 
been filed urging quick change.  Might be worth updating the Change page 
reflect that.


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

[Stewart Smith via devel]

Adam Williamson  writes:
> On Thu, 2022-07-07 at 10:49 -0700, Stewart Smith via devel wrote:
>> We actually have a skeleton design for such a thing (it says what
>> updates and upgrades are available), but we've lagged on
>> both posting to devel@ that it's something we've been working on, and I
>> need to go and poke the person who needs to click the "publish this repo
>> to github" button for the DNF plugin. I'll go do that now, as it would
>> certainly add to this conversation.
>
> The problem with this is that it's a very fuzzy, messy space that's
> hard to put limits and requirements on.
>
> The URL you mentioned is a case in point. That has more or less assumed
> the status of running joke among a small group of people who care about
> it. When you go to that URL, what you're getting now is a static JSON
> document that is hand-maintained in the fedora ansible tree:
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json
>
> when a release is branched, released, or EOLed, somebody from releng
> has to remember to edit that file, and get the edit right. These days
> that...usually...happens.

I cannot possibly imagine a process which relies on good intentions ever
failing :)

> Way back in the mists of time, what you got at that URL was a view on
> the release database of the pkgdb app, but that app hasn't existed for,
> uh, quite a lot of years now. When it was decommissioned, we discovered
> several things were relying on that API endpoint, which we replaced
> with a static JSON file just until it could be replaced with something
> less dumb. Yup, still here.
>
> The original planned replacement, IIRC, was PDC, which has now had an
> entire lifecycle (conceived, created, deployed, given up on, and nearly
> retired) without ever fully implementing all the release lifecycle
> tracking bits that various pkgdb consumers wanted. (It's been a while,
> but IIRC, there were issues with distinguishing between 'EOL', 'current
> stable', 'branched' and 'rawhide' releases from PDC data).
>
> There are various sources of some kind of truth regarding the Fedora
> release cycle. Bodhi has one - you can query
> https://bodhi.fedoraproject.org/releases/ with content-type JSON and
> you'll get some JSON back with some properties of various things Bodhi
> considers to be "releases", including a "state".

I've been converging on the thought that the same source of truth needs
to be the input to the big things on the web site and docs, and well
integrated into a regular release process that's as automated as humanly
possible.

By release, I mean "released any kind of package update" - i.e. the
thing you do *all the time*.

There's still the problem of people remembering to update it, but with
fewer places to change it, at least it's easier to get them all.

> I maintain one which is used by my 'fedfind' tool/library that various
> bits of infra (mostly QA things, but also a few others) use. It is a
> *different* hand-edited bit of JSON, which I created after being
> annoyed at the collections one being updated wrongly a few times:
> https://fedorapeople.org/groups/qa/metadata/release.json
>
> There's the CurrentFedoraVersion template on the wiki:
> https://fedoraproject.org/wiki/Template:CurrentFedoraVersion
>
> There's also, I think, some variables for 'current' releases in the
> Fedora infra ansible deployment.
>
> There are some fun issues you run up against when you play around in
> this sandbox long enough. One, for instance - when *exactly* is a new
> Fedora release "released"? Is it when the 'fedora' repo is frozen and
> Bodhi is kicked over to pushing new 'stable' updates to the 'updates'
> repo instead? (That's Bodhi's definition). Is it when the releases/NN
> tree on the public mirror system is available? (That's the one I use,
> more or less, for fedfind). Is it when the release announcement goes
> out? The point here being, if you think about it hard enough, the
> question of what 'states' a distro (or any software product) can be in
> is quite a difficult one and probably has a lot of answers.

We have a similar challenge even just entirely within AWS.

Our mirror model is very different from a typical linux
distribution. We're a completely push model rather than mirrors being
asynchronous copies. We do it this way so that we can be *certain* when
updates hit different locations, as well as control the release
velocity, and take action if we discover new sadness during a release.

It's the balance between:
1. Customers are frustrated if they know about a package that fixes a
   security bug but it isn't available in the region where they run
   their service.
2. Not wanting to have a blast radius of "all of EC2" when there's a
   problem with an update.

Due to our push based mirror model, we can follow the ethos of "once you
know about a release, you can get it anywhere you run Amazon Linux" and
have a different distribution rate for the 

RE: proposal idea: EOL notifications

[Stewart Smith via devel]

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

We've had this challenge for Amazon Linux as well, and thus our
approaches (detailed in other mail) have been to always point to a URL
for more up to date information, along with explanatory text to cover
different possible phases of support.

SuSE has some of this metadata already, but it is very SuSE specific
when I looked and we couldn't directly re-use it.
___
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 2103763] perl-Text-Bidi-2.18 is available

[bugzilla]

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



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

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

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

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-EPEL-2022-02eb71031a has been pushed to the Fedora EPEL 7 testing
repository.

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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102191
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-a19c0ce36d 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-a19c0ce36d

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

[Bug 2068801] Please build perl-Text-CSV for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Text-CSV-2.01-4.el9
Last Closed||2022-07-08 01:44:19



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2068801
___
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 2101943] perl-Text-Bidi-2.17 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Bidi-2.17-1.fc37  |perl-Text-Bidi-2.17-1.fc37
   |perl-Text-Bidi-2.17-1.fc36  |perl-Text-Bidi-2.17-1.fc36
   ||perl-Text-Bidi-2.17-1.fc35



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


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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Text-Bidi-2.17-1.fc37  |perl-Text-Bidi-2.17-1.fc37
   ||perl-Text-Bidi-2.17-1.fc36
 Resolution|--- |ERRATA
Last Closed||2022-07-08 01:16:03



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2101943
___
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 2103763] perl-Text-Bidi-2.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Sally A. Haj via devel]

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? 
If the that supports goes to upstream kernel, does that mean all Linux Distros 
will get benefits from that to support rpis?
Do RaspberryPi Foundation developers aware of this news? and will they involve 
in supporting such things in upstream kernel instead of only their downstream?

Cheers, 
Sally
___
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] New: perl-Chart-2.403.0 is available

[bugzilla]

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

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



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

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


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


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

amcta...@redhat.com changed:

   What|Removed |Added

 Blocks||2105086




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

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

[Demi Marie Obenour]

On 7/7/22 14:09, Sharpened Blade via devel wrote:
> Also, whats stops the owner of the machine to run the vm in a normal 
> hypervisor, then modify it so any attempts to check if it is "trusted" will 
> always look real.

They cannot fake the attestation without somehow extracting the needed secret 
keys from the CPU.
-- 
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

[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

amcta...@redhat.com changed:

   What|Removed |Added

 Blocks||2105072




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

[Bug 2105085] perl-HTTP-Daemon: HTTP::Daemon allows request smuggling

[bugzilla]

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

amcta...@redhat.com changed:

   What|Removed |Added

 CC||hho...@redhat.com,
   ||jor...@redhat.com,
   ||mspa...@redhat.com,
   ||perl-devel@lists.fedoraproj
   ||ect.org,
   ||perl-maint-l...@redhat.com,
   ||ppi...@redhat.com




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

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

[Demi Marie Obenour]

On 7/7/22 10:46, Frank Ch. Eigler wrote:
> 
> ngompa13 wrote:
> 
>> [...]
>> I agree, this is a completely unacceptable statement to make. The
>> problem isn't sysprof, the problem is that profiling is garbage on
>> Linux by default.
> 
> That's an overstatement.
> 
>> And while maybe most developers may not bother to do profiling right
>> now, we don't know if they wouldn't if profiling tools *worked*.
> 
> You said the problem isn't sysprof.  Userspace profiling tools can fully
> unwind with dwarf / .eh-frame if they make the effort.  Several do.

The problem is that doing so has unacceptable performance.  I believe
perf actually winds up doing so offline because doing so online is too
slow.  That is why a different solution is needed, one that allows the
unwinding to happen efficiently without requiring frame pointers.
-- 
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)

[Michael Catanzaro]

On Tue, Jul 5 2022 at 01:42:05 PM +0200, Fabio Valentini 
 wrote:

No - I think the problem is that adding those flags to the default
build configuration will affect the whole system - all executables and
shared libraries, not only "leaf" binaries. And that makes your
benchmarks (and those run by phoronix) basically useless for what
we're discussing here, because they only measure performance impact
when compiling the executables but not *the whole world* with those
flags, including all shared libraries that are used by executables
you're benchmarking.

So applying this change globally would, I assume, add to (or even
multiply) the negative effect wrt/ performance, so the effect will
likely be (much?) bigger than the few percent that were mentioned in
this thread?


This is a good point. I suppose we need further investigation here to 
understand the true performance impact.


That said, this point cuts both ways. Recompiling the entire distro in 
order to add frame pointers is a significant effort, and a very high 
burden to ask of anyone looking to do performance work.


Michael

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

[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

amcta...@redhat.com changed:

   What|Removed |Added

 CC||j...@grosjo.net,
   ||jples...@redhat.com,
   ||pampelm...@gmx.at,
   ||perl-devel@lists.fedoraproj
   ||ect.org




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

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

[Christian Hergert]

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.

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

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.

Sysprof's modular *and* system-wide profiling played a significant role in how 
GNOME Shell got faster over the past years. All of a sudden it's developers had 
a tool which could coalesce stack traces, counters, marks, logs, display timing 
information and GL command state both from apps and compositors, and track 
event propagation across processes.

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

Re: proposal idea: EOL notifications

[Adam Williamson]

On Thu, 2022-07-07 at 10:49 -0700, Stewart Smith via devel wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
> > notification when a Fedora stops being supported. Various proposals
> > for online checks were discussed in the bug, but I think we might make
> > do with something much simpler.
> 
> We've been thinking a lot in this space in Amazon Linux, and have done
> some things that are starting to be a bit wider in scope in the AL2022
> time frame, and that we've wanted to bring back as ideas to Fedora.
> 
> One of which is simply how you tell someone there's something new they
> could move to. If doing so by the command line, you need to somehow work
> out what X to pass to `dnf system-upgrade ... --releasever=X`, while I'd
> much rather be able to put it in, say, the motd, and have other tooling
> be able to know through the same system that "why yes, you are up to
> date on patches on version X, but version Y is available"
> 
> The GNOME Software Center parses the hard coded URL of
> https://admin.fedoraproject.org/pkgdb/api/collections/
> which does already have an EOL tag on older Fedora releases, so this
> could be used today to print warnings all over the place if the format
> was standard enough and documented... and that other distros could use
> it easily enough with a custom URL without patching gnome-software...
> 
> I would be totally in favor of some simple standard metadata we could host
> somewhere, easily configure into various bits of software that would
> prominently display it to users (or report back to some central thing,
> like various agents do with "dnf checkupdate" and "rpm -qa" output, that
> point to support statements about the OS.
> 
> We actually have a skeleton design for such a thing (it says what
> updates and upgrades are available), but we've lagged on
> both posting to devel@ that it's something we've been working on, and I
> need to go and poke the person who needs to click the "publish this repo
> to github" button for the DNF plugin. I'll go do that now, as it would
> certainly add to this conversation.

The problem with this is that it's a very fuzzy, messy space that's
hard to put limits and requirements on.

The URL you mentioned is a case in point. That has more or less assumed
the status of running joke among a small group of people who care about
it. When you go to that URL, what you're getting now is a static JSON
document that is hand-maintained in the fedora ansible tree:

https://pagure.io/fedora-infra/ansible/blob/main/f/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json

when a release is branched, released, or EOLed, somebody from releng
has to remember to edit that file, and get the edit right. These days
that...usually...happens.

Way back in the mists of time, what you got at that URL was a view on
the release database of the pkgdb app, but that app hasn't existed for,
uh, quite a lot of years now. When it was decommissioned, we discovered
several things were relying on that API endpoint, which we replaced
with a static JSON file just until it could be replaced with something
less dumb. Yup, still here.

The original planned replacement, IIRC, was PDC, which has now had an
entire lifecycle (conceived, created, deployed, given up on, and nearly
retired) without ever fully implementing all the release lifecycle
tracking bits that various pkgdb consumers wanted. (It's been a while,
but IIRC, there were issues with distinguishing between 'EOL', 'current
stable', 'branched' and 'rawhide' releases from PDC data).

There are various sources of some kind of truth regarding the Fedora
release cycle. Bodhi has one - you can query
https://bodhi.fedoraproject.org/releases/ with content-type JSON and
you'll get some JSON back with some properties of various things Bodhi
considers to be "releases", including a "state".

I maintain one which is used by my 'fedfind' tool/library that various
bits of infra (mostly QA things, but also a few others) use. It is a
*different* hand-edited bit of JSON, which I created after being
annoyed at the collections one being updated wrongly a few times:
https://fedorapeople.org/groups/qa/metadata/release.json

There's the CurrentFedoraVersion template on the wiki:
https://fedoraproject.org/wiki/Template:CurrentFedoraVersion

There's also, I think, some variables for 'current' releases in the
Fedora infra ansible deployment.

There are some fun issues you run up against when you play around in
this sandbox long enough. One, for instance - when *exactly* is a new
Fedora release "released"? Is it when the 'fedora' repo is frozen and
Bodhi is kicked over to pushing new 'stable' updates to the 'updates'
repo instead? (That's Bodhi's definition). Is it when the releases/NN
tree on the public mirror system is available? (That's the one I use,
more or less, for fedfind). Is it when the release announcement goes
out? The point here being, if you think about it 

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

[Sharpened Blade via devel]

That attack is a real thing, its called a mitm, but things use https now, so 
you would need a malicious CA.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Sharpened Blade via devel]

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.
___
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-IoT-36-20220707.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20220629.0):

ID: 1318684 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1318684

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

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

[Sharpened Blade via devel]

Also, whats stops the owner of the machine to run the vm in a normal 
hypervisor, then modify it so any attempts to check if it is "trusted" will 
always look real.
___
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)

[Alec Leamas]

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

Cheers!
--alec

PS: Please folks, no top-posting:

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

RE: proposal idea: EOL notifications

[Stewart Smith via devel]

Kevin Kofler via devel  writes:
> Zbigniew Jędrzejewski-Szmek wrote:
>> In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
>> notification when a Fedora stops being supported. Various proposals
>> for online checks were discussed in the bug, but I think we might make
>> do with something much simpler.
>
> That will just be perceived as an annoyance. It will not lead to users
> actually upgrading their Fedora any more quickly.
>
>> The advantage of this proposal that it is very simple and will work
>> even on machines that don't have network connectivity,
>
> How does EOL matter at all for machines that do not have network
> connectivity? They will not get any updates either way!

Cloud instances can be pretty special in this way: you may just be
launching the latest image for a particular major OS release, and at
some point in time, that is going to no longer get you any security
updates.

This is a pretty common use case on AWS with customers launching
instances in VPCs that only have external connectivity to the S3 repos
with OS packages (or not even that if they bake their own AMI with all
the packages they need in it), and connectivity to whatever other
service/instance that the instance needs to do its work.

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

Re: proposal idea: EOL notifications

[Stewart Smith via devel]

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

We've been thinking a lot in this space in Amazon Linux, and have done
some things that are starting to be a bit wider in scope in the AL2022
time frame, and that we've wanted to bring back as ideas to Fedora.

One of which is simply how you tell someone there's something new they
could move to. If doing so by the command line, you need to somehow work
out what X to pass to `dnf system-upgrade ... --releasever=X`, while I'd
much rather be able to put it in, say, the motd, and have other tooling
be able to know through the same system that "why yes, you are up to
date on patches on version X, but version Y is available"

The GNOME Software Center parses the hard coded URL of
https://admin.fedoraproject.org/pkgdb/api/collections/
which does already have an EOL tag on older Fedora releases, so this
could be used today to print warnings all over the place if the format
was standard enough and documented... and that other distros could use
it easily enough with a custom URL without patching gnome-software...

I would be totally in favor of some simple standard metadata we could host
somewhere, easily configure into various bits of software that would
prominently display it to users (or report back to some central thing,
like various agents do with "dnf checkupdate" and "rpm -qa" output, that
point to support statements about the OS.

We actually have a skeleton design for such a thing (it says what
updates and upgrades are available), but we've lagged on
both posting to devel@ that it's something we've been working on, and I
need to go and poke the person who needs to click the "publish this repo
to github" button for the DNF plugin. I'll go do that now, as it would
certainly add to this conversation.

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

This could already be done in Fedora with the data from the above URL,
but something more generic could be nice, as well as finer grained, as a
top level EoL date may not have the full picture.

For Amazon Linux, we're wanting finer grained information as well, down
to a per-package level, as that gives us the ability to do two things:
1. Clearly communicate an extended support period for a subset of the OS
2. Better ship and communicate life cycle  multiple options of major
   versions of some packages (like MariaDB, PHP, PostgreSQL, Python)
   with their own support periods following upstream.

We've done this by coming up with a "support_info.xml" kind of metadata,
to be seen as somewhat related to "updateinfo.xml" except that it
contains positive affirmations of support, as well as negative ones.

This way, it can be used by external security scanning tooling to work
out if there is any path to a particular installed RPM for ever getting
another security update.

Our first foray into this was with documenting the extension of EoL of
Amazon Linux 1: https://github.com/amazonlinux/al1-support-statements

and we've used the "explicitly no longer supported" mechanism
internally.

Our idea has been to use `system-release` (or some other yet to be
defined thing) to communicate general OS-wide statements, althoug the
nuance is important, and can be interpreted to be exactly what applies
to the host you're running on.

Arguably you want the warning of "hey, you have PHP7.4 installed, and
it's EoL in November" just as much as you want "this whole OS is going
out of support in X months".

While this per-package level is less relevant for Fedora, it could be a
useful mechanism to communicate things that are going to be deprecated
in a future release. e.g. we could warn people that at some point the
gtk1 they have installed is no longer going to be in Fedora, and where
to go to for more information.

I'm going to have to apologise for not all of ^ being written up sooner
to devel@ as something we've been working on.

But we did at least get the source code up for an initial DNF plugin
that can parse it and give some tools to users to work out what is (and
is not) supported:
https://github.com/amazonlinux/dnf-plugin-support-info

Our plan is to plug both of these into our update-motd package, which is
simply something that writes out motd snippets for pam_motd based on
running 

Re: Review swaps

[Jerry James]

On Thu, Jul 7, 2022 at 3:31 AM Richard W.M. Jones  wrote:
> I took this one, it's a core package needed all over the place.

Thank you!

> > ocaml-ppx-import: https://bugzilla.redhat.com/show_bug.cgi?id=2104693
>
> Do you know which other package(s) need this?

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

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

[Onuralp SEZER]

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)

For SBCs running just the OS itself won't be enough. It is a good start of
course but it also should support SBCs perks as well for (like access
hardware related drivers/libraries and create your own stuff)


On Thu, Jul 7, 2022 at 4:38 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?
>
> 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
>


-- 





--
Onuralp SEZER
Fedora Ambassadors  EMEA
 Member / Turkey
Fedora Translations Turkish Team Member

Fedora Design Member 
___
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.

[Luna Jernberg]

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

On Mon, Jul 4, 2022 at 10:08 AM Lennart Poettering 
wrote:

> On Sa, 02.07.22 00:15, Marius Schwarz (fedora...@cloud-foo.de) wrote:
>
> > Hi,
> >
> > I have some bug reports for PA opening BZ and only one ever got a
> response.
> >
> > Is it possible that this is the cause:
> >
> > You can't ask /Lennart Poettering / because that
> > account is disabled.
> >
> > I tried a needinfo request after a month long silence.
> >
> > Short: PAVU shows the input meter at the app output tab since the upgrade
> > from f34 to f35.
> > https://bugzilla.redhat.com/show_bug.cgi?id=2092513
>
> I haven't done audio stuff for a long time now.
>
> I should probably be honest and orphan that stuff in Fedora. Anyone
> wants to take this over?
>
> That said, I have now created a personal rhbz account, and moved the
> FAS stuff over. I am told that should fix the bugzilla mess. Let's
> see. That said, this doesn't mean I will look into your bug reports,
> audio is not my focus of work anymore, systemd is.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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)

[Luna Jernberg]

Was in this weeks LAN: https://linuxactionnews.com/248

On Thu, Jul 7, 2022 at 3: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?
>
> 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

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 20/236 (x86_64), 18/165 (aarch64)

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

ID: 1317812 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/1317812
ID: 1317817 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/1317817
ID: 1317928 Test: x86_64 Silverblue-dvd_ostree-iso clocks
URL: https://openqa.fedoraproject.org/tests/1317928
ID: 1317945 Test: aarch64 Minimal-raw_xz-raw.xz base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/1317945
ID: 1318020 Test: aarch64 Workstation-raw_xz-raw.xz clocks@uefi
URL: https://openqa.fedoraproject.org/tests/1318020
ID: 1318055 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1318055
ID: 1318064 Test: aarch64 Workstation-upgrade base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/1318064
ID: 1318070 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1318070
ID: 1318158 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1318158

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

ID: 1317807 Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1317807
ID: 1317823 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1317823
ID: 1317865 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1317865
ID: 1317872 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1317872
ID: 1317879 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1317879
ID: 1317884 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1317884
ID: 1317898 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1317898
ID: 1317902 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1317902
ID: 1317908 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1317908
ID: 1317921 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1317921
ID: 1317927 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1317927
ID: 1317929 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1317929
ID: 1317954 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1317954
ID: 1317955 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1317955
ID: 1317966 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1317966
ID: 1317993 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1317993
ID: 1318026 Test: aarch64 Workstation-raw_xz-raw.xz help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1318026
ID: 1318027 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1318027
ID: 1318028 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1318028
ID: 1318039 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1318039
ID: 1318048 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1318048
ID: 1318059 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1318059
ID: 1318067 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1318067
ID: 1318076 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1318076
ID: 1318078 Test: aarch64 Workstation-upgrade help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1318078
ID: 1318079 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1318079
ID: 1318080 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1318080
ID: 1318113 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1318113
ID: 1318177 Test: aarch64 universal 

Re: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

[Ben Beasley]

On 7/7/22 05:38, Miro Hrončok wrote:
In the spirit of other packaging guidelines, I believe we should use 
this instead:


  %pytest -n %{_smp_build_ncpus}


I agree that this is more strictly correct.

Should I do this in a mass change? Not so many packages use pytest -n 
auto in the spec:

I think this would be reasonable.
And, considering many other packages might want to benefit from that, 
should this be:


 1) encouraged in the Python packaging guidelines


I think it would be great to at least document how to do it in the 
guidelines. I had a vague sense that pytest-xdist allowed 
parallelization, but I didn’t know off the top of my head that it added 
a straightforward pytest option.


I’m torn on whether we should make this a SHOULD, and on whether we 
should try to automate it, expecting packagers to opt out as needed. On 
one hand, both would be consistent with the existing guidelines for 
Make[1]. On the other hand, I think it may be even more common in 
Python-land to encounter test suites that aren’t parallel-safe due to 
things like filesystem race conditions, and these issues can be 
difficult to diagnose and debug if one isn’t already looking for them.


Where upstream already pulls in pytest-xdist and uses “-n auto” or 
similar—but perhaps in a tox.ini, shell script, CI configuration, 
Makefile, etc. that isn’t used when running the tests for the RPM—it’s 
very safe to parallelize the tests in the RPM build, and a good idea to 
do so.


A good example of the ideal case and potential benefit is 
python-aws-sam-translator. It has a huge test suite; upstream brings in 
pytest-xdist via the “dev” extra; and there is a Makefile (not suitable 
for use in the RPM build) that uses “-n auto”, so I know the tests are 
safe to parallelize. Adding “-n %{_smp_build_ncpus}” to “%pytest” speeds 
up the tests from 130 seconds to 40 seconds on a 16-core machine.



 2) macronized (I was thinking %pytest_parallel, but TBD)
I’m not as certain about this; it usefully hides the extra option to 
pytest, but the abstraction leaks because the packager still has to 
understand that pytest-xdist is responsible and add the necessary BR (or 
verify that it is already generated).


[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_parallel_make


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

Re: Python 3.11 final release might be delayed to December

[Fabio Valentini]

On Thu, Jul 7, 2022 at 4:16 PM Miro Hrončok  wrote:
>
> What do you mean by "delay further progress of the F37 release process"?

I meant: Delay the upcoming F37 tasks by a week or two.
But apparently that won't be necessary, so maybe I misunderstood the problem.

> I assume that we will know more by the end of this week or very early next. 
> The
> options in the ticket would only matter if the release is indeed postponed.
>
> > I'd rather not make any
> > hasty actions that we could regret later, or that could cause much
> > more work for you Python guys later on, but I'd still like F37 to ship
> > with an up-to-date Python.
>
> Waiting for branching would hopefully give us more up to date information 
> about
> upstream release plans.

So you mean:
Do nothing until just before August 9 (F37 branch date) or until an
action is in any other way forced on us, whichever is earlier?

I'm guessing I'm just confused about how this is different from any
other Python rebase - other than the fact that the RC release might
happen later.

If I understand correctly, the problem that there might be ABI changes
between 1) the beta release that the mass rebuild is run with and 2)
the final RC, is not new, because the RC is *always* released too
late, so the mass rebuild is always before the point at which the ABI
is guaranteed to be stable?

I'm sorry if this is a stupid question, I'm just trying to understand
before making a decision.

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

[Frank Ch. Eigler]

ngompa13 wrote:

> [...]
> I agree, this is a completely unacceptable statement to make. The
> problem isn't sysprof, the problem is that profiling is garbage on
> Linux by default.

That's an overstatement.

> And while maybe most developers may not bother to do profiling right
> now, we don't know if they wouldn't if profiling tools *worked*.

You said the problem isn't sysprof.  Userspace profiling tools can fully
unwind with dwarf / .eh-frame if they make the effort.  Several do.

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

Re: Python 3.11 final release might be delayed to December

[Miro Hrončok]

On 07. 07. 22 15:56, Fabio Valentini wrote:

Thu, Jul 7, 2022 at 3:38 PM Miro Hrončok  wrote:


On 05. 07. 22 13:17, Miro Hrončok wrote:

Hello,
forwarding this  message to Fedora.

Will know more by the end of this week -- we might need to consider reverting
back to Python 3.10 if we don't want to ship Fedora 37 GA with a beta version
of Python :(

Fedora 37 mass rebuild is planned for 2022-07-20 -- I will make sure we know
what to do by then.

Too bad we haven't known this before we started the 3.11 mass rebuild :/


I've opened a FESCo issue: https://pagure.io/fesco/issue/2825


Not to pollute the FESco ticket with questions, I'm asking here:

Would it be possible to delay further progress of the F37 release
process (not covered by options 1-3), at least until we know what will
happen with Python 3.11's release schedule?


What do you mean by "delay further progress of the F37 release process"?

I assume that we will know more by the end of this week or very early next. The 
options in the ticket would only matter if the release is indeed postponed.



I'd rather not make any
hasty actions that we could regret later, or that could cause much
more work for you Python guys later on, but I'd still like F37 to ship
with an up-to-date Python.


Waiting for branching would hopefully give us more up to date information about 
upstream release plans.


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

Re: Python 3.11 final release might be delayed to December

[Fabio Valentini]

Thu, Jul 7, 2022 at 3:38 PM Miro Hrončok  wrote:
>
> On 05. 07. 22 13:17, Miro Hrončok wrote:
> > Hello,
> > forwarding this  message to Fedora.
> >
> > Will know more by the end of this week -- we might need to consider 
> > reverting
> > back to Python 3.10 if we don't want to ship Fedora 37 GA with a beta 
> > version
> > of Python :(
> >
> > Fedora 37 mass rebuild is planned for 2022-07-20 -- I will make sure we know
> > what to do by then.
> >
> > Too bad we haven't known this before we started the 3.11 mass rebuild :/
>
> I've opened a FESCo issue: https://pagure.io/fesco/issue/2825

Not to pollute the FESco ticket with questions, I'm asking here:

Would it be possible to delay further progress of the F37 release
process (not covered by options 1-3), at least until we know what will
happen with Python 3.11's release schedule? I'd rather not make any
hasty actions that we could regret later, or that could cause much
more work for you Python guys later on, but I'd still like F37 to ship
with an up-to-date Python.

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: Python 3.11 final release might be delayed to December

[Miro Hrončok]

On 05. 07. 22 13:17, Miro Hrončok wrote:

Hello,
forwarding this  message to Fedora.

Will know more by the end of this week -- we might need to consider reverting 
back to Python 3.10 if we don't want to ship Fedora 37 GA with a beta version 
of Python :(


Fedora 37 mass rebuild is planned for 2022-07-20 -- I will make sure we know 
what to do by then.


Too bad we haven't known this before we started the 3.11 mass rebuild :/


I've opened a FESCo issue: https://pagure.io/fesco/issue/2825


 Forwarded Message 
Subject: [Python-Dev] [Release] Status of Python 3.11 release
Date: Mon, 4 Jul 2022 23:36:39 +0100
From: Pablo Galindo Salgado 
To: Python Dev , python-committers 





Hi everyone,

# TLDR

We may be pushing the final release until December if the stability of Python 
3.11 doesn't improve.


# Long Explanation

Unfortunately, we cannot still release the next Python 3.11 beta release 
(3.11.0b4) because we still have a bunch
of pending release blockers. Unfortunately, this is still after several 
preexisting release blockers have been fixed,
some of them being discovered after I sent my last update. These are the 
current release blockers:


https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Arelease-blocker+label%3A3.11+ 
 



We also have some deferred blockers (some of them should actually be release 
blockers):


https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Adeferred-blocker+label%3A3.11 
 



Due to this and the fact that we are already 3 weeks delayed in the release 
schedule, the current stability of Python 3.11 is not as good
as it is supposed to be at this stage of the release schedule and more testing 
from end-users and library authors is required. After
discussing with the Steering Council, we are considering delaying the final 
release until December to allow for two more beta releases.

This is how we are going to proceed:

* If the current release blockers are not fixed by the end of this week, two 
more betas will be released (1 month per beta) and

we will *definitely* delay the final release until December.
* If the current release blockers are fixed we will proceed to release Python 
3.11.0b4 on Monday. We will target the current release
date (Monday, 2022-10-03) but if more release blockers that affect fundamental 
parts of the Python interpreter or the standard libraries
are raised, the release team will still consider adding two more betas nd 
pushing the final release to December.


One of the goals that we are going to try to achieve from the release team is 
that no substantial code changes are added between the last
beta and the first release candidate. This is so all the fixes that affect 
fundamental parts of the interpreter or the standard library can be
tested by end-users before the first release candidate is released (and not 
with it). This is also partially because once we release the first release
candidate, the ABI will be frozen and certain kinds of fixes will be more 
complicated.


Hopefully, this addresses some of you that have reached out with concerns over 
the stability of Python 3.11 and the release schedule.


I understand that delaying the release until December will complicate things 
for some Linux distributions and will affect end users and redistributors
targeting the original release, but please understand that our 
responsibility in the release team after all is to guarantee a stable final 
release
above all and unfortunately, we don't currently have the confidence that we 
would like given the current state of the release process.


Please do not hesitate in reaching out if you have any questions or concerns.

Thanks, everyone for your help and understanding and thanks a lot to all of you 
for your great work!


Cheers from cloudy London,
Pablo Galindo Salgado


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

Re: Python 3.11 final release might be delayed to December

[Miro Hrončok]

On 05. 07. 22 13:17, Miro Hrončok wrote:

Hello,
forwarding this  message to Fedora.

Will know more by the end of this week -- we might need to consider reverting 
back to Python 3.10 if we don't want to ship Fedora 37 GA with a beta version 
of Python :(


Fedora 37 mass rebuild is planned for 2022-07-20 -- I will make sure we know 
what to do by then.


Too bad we haven't known this before we started the 3.11 mass rebuild :/


I've opened a FESCo issue: https://pagure.io/fesco/issue/2825


 Forwarded Message 
Subject: [Python-Dev] [Release] Status of Python 3.11 release
Date: Mon, 4 Jul 2022 23:36:39 +0100
From: Pablo Galindo Salgado 
To: Python Dev , python-committers 





Hi everyone,

# TLDR

We may be pushing the final release until December if the stability of Python 
3.11 doesn't improve.


# Long Explanation

Unfortunately, we cannot still release the next Python 3.11 beta release 
(3.11.0b4) because we still have a bunch
of pending release blockers. Unfortunately, this is still after several 
preexisting release blockers have been fixed,
some of them being discovered after I sent my last update. These are the 
current release blockers:


https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Arelease-blocker+label%3A3.11+ 
 



We also have some deferred blockers (some of them should actually be release 
blockers):


https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Adeferred-blocker+label%3A3.11 
 



Due to this and the fact that we are already 3 weeks delayed in the release 
schedule, the current stability of Python 3.11 is not as good
as it is supposed to be at this stage of the release schedule and more testing 
from end-users and library authors is required. After
discussing with the Steering Council, we are considering delaying the final 
release until December to allow for two more beta releases.

This is how we are going to proceed:

* If the current release blockers are not fixed by the end of this week, two 
more betas will be released (1 month per beta) and

we will *definitely* delay the final release until December.
* If the current release blockers are fixed we will proceed to release Python 
3.11.0b4 on Monday. We will target the current release
date (Monday, 2022-10-03) but if more release blockers that affect fundamental 
parts of the Python interpreter or the standard libraries
are raised, the release team will still consider adding two more betas nd 
pushing the final release to December.


One of the goals that we are going to try to achieve from the release team is 
that no substantial code changes are added between the last
beta and the first release candidate. This is so all the fixes that affect 
fundamental parts of the interpreter or the standard library can be
tested by end-users before the first release candidate is released (and not 
with it). This is also partially because once we release the first release
candidate, the ABI will be frozen and certain kinds of fixes will be more 
complicated.


Hopefully, this addresses some of you that have reached out with concerns over 
the stability of Python 3.11 and the release schedule.


I understand that delaying the release until December will complicate things 
for some Linux distributions and will affect end users and redistributors
targeting the original release, but please understand that our 
responsibility in the release team after all is to guarantee a stable final 
release
above all and unfortunately, we don't currently have the confidence that we 
would like given the current state of the release process.


Please do not hesitate in reaching out if you have any questions or concerns.

Thanks, everyone for your help and understanding and thanks a lot to all of you 
for your great work!


Cheers from cloudy London,
Pablo Galindo Salgado


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

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

[Ron Olson]

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?

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

Re: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

[Major Hayden]

On 7/7/22 04:38, Miro Hrončok wrote:
> Should I do this in a mass change? Not so many packages use pytest -n
> auto in the spec:
> 
>   $ rg -l -- '(-n|--numprocesses)(\s*|=)auto(\s|$)'
>   azure-cli.spec

As the azure-cli maintainer, I'm okay with that change.

> (Other packages have that in tox.ini or pytest config file, but I am not
> aiming at changing that here.)
> 
> And, considering many other packages might want to benefit from that,
> should this be:
> 
>  1) encouraged in the Python packaging guidelines

Of course! I always forget the "%{_smp_build_ncpus}" macro and end up
digging through macros to find how to spell it.

>  2) macronized (I was thinking %pytest_parallel, but TBD)

That's a good idea, but I don't know how much use it would get. 路‍♂️

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

Re: Python 3.11 final release might be delayed to December

[Petr Viktorin]

On 05. 07. 22 15:54, Richard Shaw wrote:
On Tue, Jul 5, 2022 at 8:07 AM Richard W.M. Jones > wrote:


On Tue, Jul 05, 2022 at 01:17:39PM +0200, Miro Hrončok wrote:
 > Hello,
 > forwarding this  message to Fedora.
 >
 > Will know more by the end of this week -- we might need to consider
 > reverting back to Python 3.10 if we don't want to ship Fedora 37 GA
 > with a beta version of Python :(

Is there a reason why shipping a beta version of Python would be bad?
I've been using it on my main development machine for a few weeks and
for the (fairly limited) Python stuff I do it seems to be fine.

It'd be a problem if it was causing bugs.


Would it not make sense then to review the blocker bugs  and then 
determine if they are blockers for us?


The issue is not bug(s but ABI compatibility. We can't update from a 
Beta to (say) 3.11.1 in stable Fedora, because all PYC files and 
extension modules would break if the C-ABI or PYC files would break.

___
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: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

[Miro Hrončok]

On 07. 07. 22 14:00, Petr Viktorin wrote:

On 07. 07. 22 11:38, Miro Hrončok wrote:

Hello Pythonistats, packagers,

A handful of Fedora Python packages uses pytest-xdist to run tests in 
parallel like this:


   %pytest -n auto

-n auto means pytest will spawn a number of workers processes equal to the 
number of available CPUs.


In the spirit of other packaging guidelines, I believe we should use this 
instead:


   %pytest -n %{_smp_build_ncpus}

This means the same thing in most of the ceases, but will limit the number of 
workers depending on other constraints in the spec or in the environment.


Should I do this in a mass change? Not so many packages use pytest -n auto in 
the spec:


   $ rg -l -- '(-n|--numprocesses)(\s*|=)auto(\s|$)'
   ansible-bender.spec
   azure-cli.spec
   ocrmypdf.spec
   python-cartopy.spec
   python-GridDataFormats.spec
   python-hypothesis.spec
   python-matplotlib.spec
   python-mplcairo.spec
   python-rpmautospec.spec
   python-sqlalchemy.spec
   python-tox.spec
   python-xarray.spec
   python-zstandard.spec
   pythran.spec
   scipy.spec

(Other packages have that in tox.ini or pytest config file, but I am not 
aiming at changing that here.)


And, considering many other packages might want to benefit from that, should 
this be:


  1) encouraged in the Python packaging guidelines
  2) macronized (I was thinking %pytest_parallel, but TBD)


Or pytest-xdist could be taught to check an environment variable for `auto`, 
making this seamless for packagers?


This could work, except that sometimes pytest-xdist is installed and we don't 
want to run tests in parallel because they are not prepared for that. But I 
guess an opt-out would still exist, e.g. setting %{_smp_build_ncpus} to 1 in 
the %check section.


I will have a look if there is an environment variable we could use. We can 
probably adjust PYTEST_ADDOPTS if we detect pytest-xdist is available.


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

Re: libgphoto2 .so name bump announcement

[Josef Řídký]

Hi Peter,

thanks for the comparison, I have mis-interpreted the content of the
build.log file and compared file names instead of the Provides section.

In that case, I will update the libgphoto2 package in Fedora and no
side-tag or package rebuild will be needed.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Thu, Jul 7, 2022 at 2:04 PM Petr Pisar  wrote:

> V Thu, Jul 07, 2022 at 01:10:56PM +0200, Josef Řídký napsal(a):
> > Hi,
> >
> > upstream has released a new libgphoto2 with version number 2.5.30.
> > As part of this update, .so name has bumped to version 12.1.0.
> >
> I cannot see any of that soname in libgphoto2-2.5.30-1.fc37
> :
>
> libgphoto2.so.6()(64bit)
> libgphoto2_port.so.12()(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
>
> Compare to what we have in libgphoto2-2.5.29-1.fc37:
>
> libgphoto2.so.6()(64bit)
> libgphoto2_port.so.12()(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
>
> Could you be more specific what has changed?
>
> -- Petr
> ___
> 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: Python 3.11 final release might be delayed to December

[Charalampos Stratakis]

On Tue, Jul 5, 2022 at 4:33 PM Miro Hrončok  wrote:

> On 05. 07. 22 16:22, Kaleb Keithley wrote:
> > On Tue, Jul 5, 2022 at 9:45 AM Miro Hrončok  > > wrote:
> >
> > On 05. 07. 22 15:20, Kaleb Keithley wrote:
> >  >
> >  >
> >  > On Tue, Jul 5, 2022 at 9:07 AM Richard W.M. Jones <
> rjo...@redhat.com
> > 
> >  > >> wrote:
> >  >
> >  > On Tue, Jul 05, 2022 at 01:17:39PM +0200, Miro Hrončok wrote:
> >  >  > Hello,
> >  >  > forwarding this  message to Fedora.
> >  >  >
> >  >  > Will know more by the end of this week -- we might need to
> consider
> >  >  > reverting back to Python 3.10 if we don't want to ship
> Fedora 37 GA
> >  >  > with a beta version of Python :(
> >  >
> >  > Is there a reason why shipping a beta version of Python would
> be bad?
> >  > I've been using it on my main development machine for a few
> weeks and
> >  > for the (fairly limited) Python stuff I do it seems to be
> fine.
> >  >
> >  > It'd be a problem if it was causing bugs.
> >  >
> >  >
> >  > It broke the cephfs-shell subpackage. (Currently disabled as a
> temporary
> >  > work-around.)
> >
> > Could you please share some link?
> >
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=88847352
> > 
>
> """
> error: Multiple top-level packages discovered in a flat-layout: ['top',
> 'CMakeFiles'].
> To avoid accidental inclusion of unwanted files or directories,
> setuptools will not proceed with this build.
> If you are trying to create a single distribution with multiple packages
> on purpose, you should not rely on automatic discovery.
> Instead, consider the following options:
> 1. set up custom discovery (`find` directive with `include` or `exclude`)
> 2. use a `src-layout`
> 3. explicitly set `py_modules` or `packages` with a list of names
> To find more information, look for "package discovery" on setuptools docs.
> """
>
> This is a setuptools 61+ thing, not Python 3.11.
>
> You might find some context in
>
> https://setuptools.pypa.io/en/latest/history.html#id105
> https://github.com/pypa/setuptools/issues/3197
>
> https://bugzilla.redhat.com/showdependencytree.cgi?id=2064842_resolved=0
>
> No idea why ceph was not reported as impacted, the folks have reported
> *many*
> other failures.
>
> I am afraid we have not yet seen the end of breaking changes in setuptools
> :/
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
This is due to an oversight by me during the impact check of the latest
setuptools, as COPR default timeout is 5 hours and ceph requires more than
that, hence I skipped it, apologies for that.

You can add a py_modules = [] in setup.py to fix it usually.

The issue and the possible fix is described here:
https://github.com/pypa/setuptools/issues/3197#issuecomment-1078770109

-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
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: libgphoto2 .so name bump announcement

[Petr Pisar]

V Thu, Jul 07, 2022 at 01:10:56PM +0200, Josef Řídký napsal(a):
> Hi,
> 
> upstream has released a new libgphoto2 with version number 2.5.30.
> As part of this update, .so name has bumped to version 12.1.0.
>
I cannot see any of that soname in libgphoto2-2.5.30-1.fc37
:

libgphoto2.so.6()(64bit)
libgphoto2_port.so.12()(64bit)
libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)

Compare to what we have in libgphoto2-2.5.29-1.fc37:

libgphoto2.so.6()(64bit)
libgphoto2_port.so.12()(64bit)
libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)

Could you be more specific what has changed?

-- Petr


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

Re: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

[Petr Viktorin]

On 07. 07. 22 11:38, Miro Hrončok wrote:

Hello Pythonistats, packagers,

A handful of Fedora Python packages uses pytest-xdist to run tests in 
parallel like this:


   %pytest -n auto

-n auto means pytest will spawn a number of workers processes equal to 
the number of available CPUs.


In the spirit of other packaging guidelines, I believe we should use 
this instead:


   %pytest -n %{_smp_build_ncpus}

This means the same thing in most of the ceases, but will limit the 
number of workers depending on other constraints in the spec or in the 
environment.


Should I do this in a mass change? Not so many packages use pytest -n 
auto in the spec:


   $ rg -l -- '(-n|--numprocesses)(\s*|=)auto(\s|$)'
   ansible-bender.spec
   azure-cli.spec
   ocrmypdf.spec
   python-cartopy.spec
   python-GridDataFormats.spec
   python-hypothesis.spec
   python-matplotlib.spec
   python-mplcairo.spec
   python-rpmautospec.spec
   python-sqlalchemy.spec
   python-tox.spec
   python-xarray.spec
   python-zstandard.spec
   pythran.spec
   scipy.spec

(Other packages have that in tox.ini or pytest config file, but I am not 
aiming at changing that here.)


And, considering many other packages might want to benefit from that, 
should this be:


  1) encouraged in the Python packaging guidelines
  2) macronized (I was thinking %pytest_parallel, but TBD)


Or pytest-xdist could be taught to check an environment variable for 
`auto`, making this seamless for packagers?

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

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

[Neal Gompa]

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

I agree, this is a completely unacceptable statement to make. The
problem isn't sysprof, the problem is that profiling is garbage on
Linux by default. And while maybe most developers may not bother to do
profiling right now, we don't know if they wouldn't if profiling tools
*worked*.




--
真実はいつも一つ！/ 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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Matthias Clasen]

On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer  wrote:


> If the GNOME's sysprof does not
> work with Fedora, fix it or use something else.  Do not change how
> Fedora is built.
>

The result of that attitude is that performance work in the desktop space
is happening
on GNOME OS images, or in Flatpak runtimes instead of on Fedora. Which is a
bit
sad for Fedora as a supposedly developer-friendly environment.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Matthias Runge]

On 06/07/2022 13:55, Ali Erdinc Koroglu wrote:

Hello, I can take the rest thank you.

FAS: aekoroglu



Thank you!

I did not hand all packages over, such as python-django-nose, or 
python-django-piston because they should already be retired, but it 
still looks somewhat existing in pkgdb. Upstreams were gone for a couple 
of years, like django-piston had approx. the last commit 9 years ago.



Matthias




On 06/07/2022 11:50, Simon de Vlieger wrote:
you may or may not know, I have been maintaining python-django for 
quite

some time in the past, some time as part of my job. My role changed and
I really can not dedicate Django the time it deserves. I am looking for
someone or persons willing to take

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


I'm going to orphan the packages mid July. Ideally we'd find takers 
before?

If you are interested and able to maintain (any) of these packages,
please send me your FAS name and package(s) to maintain.
I don't know if I can apply as I am a relatively new maintainer but 
I'd like to

help out by taking over the following packages:

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

My FAS username is: `supakeen`.


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

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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
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

libgphoto2 .so name bump announcement

[Josef Řídký]

Hi,

upstream has released a new libgphoto2 with version number 2.5.30.
As part of this update, .so name has bumped to version 12.1.0.

I've requested a side-tag for smooth update of all dependent packages.

Side tag is 'f37-build-side-54858'.

Unfortunately, I am not able to update dependent packages by myself, so I
would like to ask for help from some kind proven-packager.
Please, let me know if you're willing to help me with the update.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220707.n.0 changes

[Fedora Rawhide Report]

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

= SUMMARY =
Added images:9
Dropped images:  0
Added packages:  7
Dropped packages:1
Upgraded packages:   156
Downgraded packages: 0

Size of added packages:  600.81 KiB
Size of dropped packages:24.09 KiB
Size of upgraded packages:   2.73 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220707.n.0.s390x.qcow2
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20220707.n.0.iso
Image: Cloud_Base tar-gz x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20220707.n.0.x86_64.tar.gz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20220707.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20220707.n.0.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20220707.n.0.s390x.tar.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20220707.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220707.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220707.n.0.s390x.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: openconnect-gateway-0-0.2.20170903git627468b.fc37
Summary: Connect to a VPN without routing everything through the VPN
RPMs:openconnect-gateway
Size:14.66 KiB

Package: pepc-1.3.9-1.fc37
Summary: Power, Energy, and Performance Configurator
RPMs:pepc python3-pepc
Size:265.64 KiB

Package: python-openapi-schema-validator-0.3.0-1.fc37
Summary: OpenAPI schema validator for Python
RPMs:python3-openapi-schema-validator 
python3-openapi-schema-validator+isodate 
python3-openapi-schema-validator+rfc3339-validator 
python3-openapi-schema-validator+strict-rfc3339
Size:48.40 KiB

Package: python-rfc3339-validator-0.1.4-1.fc37
Summary: Pure python RFC3339 validator
RPMs:python3-rfc3339-validator
Size:13.66 KiB

Package: rust-escape_string-0.1.2-1.fc37
Summary: Efficiently parse backslash-escaped strings
RPMs:rust-escape_string+default-devel rust-escape_string-devel
Size:18.09 KiB

Package: rust-mptcp-pm-0.1.1-1.fc37
Summary: Linux kernel MPTCP path manager netlink Library
RPMs:rust-mptcp-pm+async-std-devel rust-mptcp-pm+default-devel 
rust-mptcp-pm+smol_socket-devel rust-mptcp-pm+tokio-devel 
rust-mptcp-pm+tokio_socket-devel rust-mptcp-pm-devel
Size:55.63 KiB

Package: wl-mirror-0.11.2-1.fc37
Summary: Simple Wayland output mirror client
RPMs:wl-mirror
Size:184.73 KiB


= DROPPED PACKAGES =
Package: python-contextlib2-0.6.0.post1-4.fc36
Summary: Backports and enhancements for the contextlib module
RPMs:python3-contextlib2
Size:24.09 KiB


= UPGRADED PACKAGES =
Package:  Lmod-8.7.7-1.fc37
Old package:  Lmod-8.7.6-1.fc37
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 919.23 KiB
Size change:  1.15 KiB
Changelog:
  * Wed Jul 06 2022 Orion Poplawski  - 8.7.7-1
  - Update to 8.7.7


Package:  Singular-4.2.1p3-2.fc37
Old package:  Singular-4.2.1p3-1.fc37
Summary:  Computer Algebra System for polynomial computations
RPMs: Singular Singular-devel Singular-doc Singular-emacs 
Singular-libpolys Singular-libpolys-devel Singular-libs Singular-surfex factory 
factory-devel factory-gftables
Size: 91.51 MiB
Size change:  878.42 KiB
Changelog:
  * Tue Jul 05 2022 Jerry James  - 4.2.1p3-2
  - Rebuild for flint 2.9.0
  - Add bootstrap build mode that excludes qepcad-B


Package:  ags-3.6.0.29-1.fc37
Old package:  ags-3.6.0.27-1.fc37
Summary:  Engine for creating and running videogames of adventure (quest) 
genre
RPMs: ags
Size: 5.34 MiB
Size change:  8.03 KiB
Changelog:
  * Tue Jul 05 2022 Dominik Mierzejewski  - 3.6.0.29-1
  - update to 3.6.0.29 (#2100149)


Package:  antic-0.2.5-1.fc37
Old package:  antic-0.2.4-4.fc36
Summary:  Algebraic Number Theory In C
RPMs: antic antic-devel
Size: 357.21 KiB
Size change:  -1.94 KiB
Changelog:
  * Tue Jul 05 2022 Jerry James  - 0.2.5-1
  - Version 0.2.5


Package:  apptainer-1.0.3-1.fc37
Old package:  apptainer-1.0.2-1.fc37
Summary:  Application and environment virtualization
RPMs: apptainer
Size: 102.70 MiB
Size change:  4.07 MiB
Changelog:
  * Fri Jun 17 2022 Robert-Andr?? Mauchin  - 1.0.2-2
  - Rebuilt for CVE-2022-1996, CVE-2022-24675, CVE-2022-28327, CVE-2022-27191,
CVE-2022-29526, CVE-2022-30629

  * Wed Jul 06 2022 Dave Dykstra  - 1.0.3
  - Update to upstream 1.0.3


Package:  arb-2.23.0-1.fc37
Old package:  arb-2.22.1-1

[Bug 2104259] adapt perl to removal of java on i686

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
More importantly the five subchains identify a cut at a build-only dependency
which will remain available on all architectures even without openjdk. Perl
packages beyond that cut are not affected in any way.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2104259
___
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 2104259] adapt perl to removal of java on i686

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||2103921, 2104038, 2104257,
   ||2104097, 2103909
 Resolution|--- |NOTABUG
 Status|NEW |CLOSED
Last Closed||2022-07-07 10:19:02



--- Comment #1 from Petr Pisar  ---
None of these packages directly require java-11-openjdk.

There are five classes of the dependency chains:

autoconf<-erlang<-fop<-java-17-openjdk (bug #2103921, bug #2104038)
crypto-policies<-java-1.8.0-openjdk-devel (bug #2104257)
R-devel<-R-java-devel<-java-17-openjdk-devel (bug #2104097)
subversion<-java-11-openjdk-devel (bug #2103909)
subversion<-junit<-java-17-openjdk-headless (bug #2103909)

This issues should be fixed in components closest to opendjdk in their bug
reports.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2103909
[Bug 2103909] native subversion depends on to be removed i686 java-openjdk
packages
https://bugzilla.redhat.com/show_bug.cgi?id=2103921
[Bug 2103921] adapt autoconf to removal of java on i686
https://bugzilla.redhat.com/show_bug.cgi?id=2104038
[Bug 2104038] native erlang depends on to be removed i686 java-openjdk packages
https://bugzilla.redhat.com/show_bug.cgi?id=2104097
[Bug 2104097] native R depends on to be removed i686 java-openjdk packages
https://bugzilla.redhat.com/show_bug.cgi?id=2104257
[Bug 2104257] adapt crypto-policies to removal of java on i686
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2104259
___
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.

[Gerd Hoffmann]

On Wed, Jul 06, 2022 at 05:12:20PM +0200, Lennart Poettering wrote:
> On Mi, 06.07.22 16:13, Gerd Hoffmann (kra...@redhat.com) wrote:
> 
> > grub2 doesn't find it.  Support not implemented?
> 
> afics grub2 upstream has no native support for boot loader spec
> stuff. (or has that changed?)

Nope.  Which is a PITA when you want hack something in upstream
grub because it wouldn't boot fedora without hacks.

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

Suspected that.

> > systemd-boot doesn't find it either.  Double-checking.  ESP mounted at
> > /boot/efi.  Directory looks fine to me:
> >
> > root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux
> > total 77832
> > -rwx--. 1 root root 79698816 Jul  6 15:36 
> > unified-5.18.9-200.fc36.x86_64.efi
> >
> > Any clues?
> 
> I am not a grub guy, haven't used it in a long time. But my educated
> guess is this: I think grub might load the chainloaded binary into
> memory itself, and then execute it from there, instead of invoking it
> directly from the ESP file system. This matters because if sd-boot is
> invoked from a synthetic file in memory we cannot derive the directory
> tree of the ESP from it, and thus not find boot loader entries.

Adding a boot entry to the firmware to load sd-boot directly and take
grub out of the chain doesn't change the situation.

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

Re: proposal idea: EOL notifications

[Lennart Poettering]

On Mi, 06.07.22 21:05, Gary Buhrmaster (gary.buhrmas...@gmail.com) wrote:

> On Wed, Jul 6, 2022 at 3:45 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
>
> > https://github.com/systemd/systemd/pull/23924 proposes adding
> > SUPPORT_END=-MM-DD to /usr/lib/os-release.
>
> I like the concept, but
>
> (warning, taxonomy discussion)
>
> The announcement for os-release included
> the following statement:
>
>Please prefix your keys with your distribution's
>name however. Or even better: talk to us and
>we might be able update the documentation and
>make your field standard, if you convince us that
>it makes sense.
>
> And while I would prefer the effort to get
> the field standardized (perhaps END_OF_SUPPORT=?)
> any name in Fedora should be something of
> the form REDHAT_ or FEDORA_ I would
> probably also prefer the stanza be differently
> named (I prefer the term EOL or EOS) but the
> important point (to me) is the prefix.

It's an *upstream* PR, and the os-release format is defined by the
systemd project, so because this has been merged now it as as
"standard" as it can get now, across distros. Still up to each distro
individually if they actually want to implement it though.

Lennart

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

Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

[Miro Hrončok]

Hello Pythonistats, packagers,

A handful of Fedora Python packages uses pytest-xdist to run tests in parallel 
like this:


  %pytest -n auto

-n auto means pytest will spawn a number of workers processes equal to the 
number of available CPUs.


In the spirit of other packaging guidelines, I believe we should use this 
instead:

  %pytest -n %{_smp_build_ncpus}

This means the same thing in most of the ceases, but will limit the number of 
workers depending on other constraints in the spec or in the environment.


Should I do this in a mass change? Not so many packages use pytest -n auto in 
the spec:


  $ rg -l -- '(-n|--numprocesses)(\s*|=)auto(\s|$)'
  ansible-bender.spec
  azure-cli.spec
  ocrmypdf.spec
  python-cartopy.spec
  python-GridDataFormats.spec
  python-hypothesis.spec
  python-matplotlib.spec
  python-mplcairo.spec
  python-rpmautospec.spec
  python-sqlalchemy.spec
  python-tox.spec
  python-xarray.spec
  python-zstandard.spec
  pythran.spec
  scipy.spec

(Other packages have that in tox.ini or pytest config file, but I am not aiming 
at changing that here.)


And, considering many other packages might want to benefit from that, should 
this be:


 1) encouraged in the Python packaging guidelines
 2) macronized (I was thinking %pytest_parallel, but TBD)

?

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

Re: Review swaps

[Richard W.M. Jones]

On Wed, Jul 06, 2022 at 08:43:43PM -0600, Jerry James wrote:
> I need 2 OCaml package reviews in order to update existing packages to
> the most recent versions.
> 
> ocaml-camlp-streams: https://bugzilla.redhat.com/show_bug.cgi?id=2104283

I took this one, it's a core package needed all over the place.

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

Do you know which other package(s) need this?

Rich.

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

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

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

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

Re: With F36 systemd-nspawn test environment not usable, no login possible

[Petr Pisar]

V Tue, Jul 05, 2022 at 09:29:14AM +0200, Lennart Poettering napsal(a):
> On Di, 05.07.22 14:38, Dominique Martinet (asmad...@codewreck.org) wrote:
> > you'll see it complain that there is no /bin/login: you just need to
> > install util-linux (or possibly busybox) and you'll get a prompt,
> > login should work as well.
> 
> This smells as a bug in in the package providing getty. getty cannot
> work without /bin/login, hence the package should have a dep on it.
> 
If the getty is /usr/sbin/agetty from util-linux-core, then it's a known bug
.

-- Petr


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

[Bug 2103763] perl-Text-Bidi-2.18 is available

[bugzilla]

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



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


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

[bugzilla]

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



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


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

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Text-Bidi-2.18-1.fc37



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


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

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

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 2103763] perl-Text-Bidi-2.18 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2103763
___
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 2104311] Please build perl-Test-CheckDeps for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2104311
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure