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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-463787a597   
seamonkey-2.53.13-1.el7


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

AMF-1.4.24-1.el7
barman-3.0.1-1.el7

Details about builds:



 AMF-1.4.24-1.el7 (FEDORA-EPEL-2022-9573f17a1c)
 Advanced Media Framework (AMF) SDK

Update Information:

New AMF 1.4.24 release.

ChangeLog:

* Thu Apr  7 2022 Simone Caronni  - 1.4.24-1
- Update to 1.4.24.




 barman-3.0.1-1.el7 (FEDORA-EPEL-2022-3dcfb59615)
 Backup and Recovery Manager for PostgreSQL

Update Information:

Update to 3.0.1

ChangeLog:

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

References:

  [ 1 ] Bug #2044338 - barman-3.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2044338


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

[Bug 2105729] pangzero and frozen-bubble won't launch and segfault on F36

[bugzilla]

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

Sergio Basto  changed:

   What|Removed |Added

Summary|pangzero and frozen-bubble  |pangzero and frozen-bubble
   |won't launch  segfault on   |won't launch and segfault
   |F36 |on F36
   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=2105729
___
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 2105729] New: pangzero and frozen-bubble won't launch segfault on F36

[bugzilla]

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

Bug ID: 2105729
   Summary: pangzero and frozen-bubble won't launch  segfault on
F36
   Product: Fedora
   Version: 36
Status: NEW
 Component: perl-SDL
  Assignee: hdego...@redhat.com
  Reporter: ser...@serjux.com
QA Contact: extras...@fedoraproject.org
CC: hdego...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:

pangzero segfault on Fedora 35 KDE X11 and F36 

frozen-bubble also segfault on F36 , but runs on F35 .

more details here 
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6325


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

MUMPS 5.5.0

[Antonio T. sagitter]

Hi all.

Next release of MUMPS is the 5.5.0, it will be built in Rawhide within 7 
days together with related dependencies.


Changelog: http://mumps.enseeiht.fr/index.php?page=dwnld

Best regards.
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/


OpenPGP_0xCC1CFEF30920C8AE.asc
Description: OpenPGP public key


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

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

[Gordon Messmer]

On 6/21/22 21:40, Gordon Messmer wrote:

On 6/21/22 13:10, Matthew Miller wrote:
Phoronix credits this to those distros shipping with P-state 
Performance by default.


Yes, but I doubt that for several reasons: First, it's a claim without 
evidence.  That setting isn't the only difference between any two 
systems tested.  Second, the claim doesn't make any *sense*.  Systems 
with intel_pstate balanced aren't supposed to be noticeably slower for 
sustained CPU intensive workloads.  The intel_pstate driver is supposed 
to scale the frequency up under load in the "balanced" configuration, 
delivering performance when it is needed and power saving when it 
isn't.  Third, I can run their tests on my own system in an intel_pstate 
performance mode and an intel_pstate balanced mode, and the test results 
are nearly identical, which is the expected outcome.


I did some work this week to see if I could learn anything from 
Phoronix's article [1], and came up pretty much dry.  I cannot replicate 
any of the differences that I would expect to be able to.  More than 
anything else, their results look like evidence of a bug in the Xeon 
Platinum 8380.


In retrospect, the first thing that should have stood out to me when I 
looked at this ~ 3 weeks ago (but which I missed) was that if I pull the 
phoronix/pts container image and "run pts/compress-zstd" with 
"Compression Level: 3, Long Mode", I get better results on my XPS 13 
laptop than they did on their Xeon.  And, while cpubenchmark.net does 
suggest that my i5 CPU [2] has a better single-core test results than 
the Xeon [3], the zstd test should not be limited to a single core.  On 
my laptop, top reported the zstd process typically using ~400% CPU time.


The first thing I tried to reproduce was a difference between 
"performance" and "powersave" settings in the intel_pstate cpufreq 
driver.  I used the zstd compression test on my only Intel CPU, which is 
in my XPS 13 laptop.  In the default Fedora WS configuration, 
scaling_driver is intel_pstate, scaling_governor is powersave, and (I 
believe) energy_performance_preference is balance_performance.  In that 
configuration, typical values for scaling_cur_freq were significantly 
lower than typical values after changing energy_performance_preference 
to performance, and scaling_governor to performance.  So on this laptop, 
I'm confident that the governor and EPP settings are behaving as 
expected.  But zstd benchmark results are essentially indistinguishable 
when running in one mode vs the other, because the powersave mode for 
the intel_pstate driver will scale CPU speed up on demand.


In addition, phoronix has benchmarked Intel systems in the past [4] to 
determine the effective difference between the intel_pstate powersave 
and performance modes, and found minimal differences on an Intel i9 CPU.


I also tested the svt-av1 benchmark on this system in both modes, as 
this was another CPU bound test that Phoronix reported as a significant 
difference and attributed to the P-State governor setting.  Again, I saw 
no significant difference between performance and powersave results.


All of this suggests that the Xeon was simply not scaling up for these 
tests.  Given its large number of cores, perhaps the benchmarks weren't 
putting enough load on the system to trigger scaling up.  Or (as a 
matter of *wild* speculation) maybe it was scaling up some cores, but 
Linux was shuffling tasks between cores and "missing" the fast ones. 
Whatever the case, the big differences between distributions reported by 
Phoronix are probably limited to this class of CPUs.


If this is *normal* behavior for those CPUs, then maybe the Fedora 
Server group would want to change the default governor, or emphasize the 
importance of the CPU governor selection in their documentation.


I also ran benchmarks on CentOS Stream 9 and Fedora Server 36, each 
installed in a VM under CentOS Stream 9 libvirt, running on a host with 
a AMD Ryzen 5 CPU [5], with the CPU configuration copied to the guests. 
 As VMs, these would not apply any cpufreq management of their own, and 
if there were any differences resulting from the CPU architecture 
target, they should be apparent in these tests.  Test results for these 
VMs 20-40% better than the Xeon's best results, but results under the 
CentOS Stream 9 VM were essentially the same as results under the Fedora 
Server 36 VM.  It's probably still interesting to run the full suite and 
see if any other tests do have significant differences, and I'll try to 
do that later.


I think that's enough to convince me that I was wrong to doubt that the 
intel_pstate configuration was the reason that these results differed, 
although I still believe that if that is the case, then the CPU's 
internal pstate selection is broken.



1: https://www.phoronix.com/scan.php?page=article=h1-2022-linux=1

2: 
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-1135G7+%40+2.40GHz=3830


3: 

Re: Fedora SCM requests on the weekend

[Kevin Fenzi]

On Fri, Jul 08, 2022 at 01:02:15PM -, Mukundan Ragavan wrote:
> > On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:
> > 
> > That said, until then I can try and run things on weekends. 
> 
> Is there a formal process to volunteer to hold the keys to the kingdom?

Yes. Basically one of the existing group members nominates someone, and
all the existing group members vote on adding them. 

However, at this point we are close to automating it, so not sure it's
worth adding more folks. We could though if it isn't automated soon...

kevin


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

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

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

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

ID: 1319946 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1319946
ID: 1320003 Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1320003
ID: 1320067 Test: aarch64 Workstation-raw_xz-raw.xz clocks@uefi
URL: https://openqa.fedoraproject.org/tests/1320067
ID: 1320072 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1320072
ID: 1320100 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1320100
ID: 1320102 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1320102
ID: 1320125 Test: aarch64 Workstation-upgrade help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1320125

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

ID: 1319926 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1319926
ID: 1319949 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1319949
ID: 1319955 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1319955
ID: 1319968 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1319968
ID: 1319974 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1319974
ID: 1319976 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1319976
ID: 1320013 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1320013
ID: 1320073 Test: aarch64 Workstation-raw_xz-raw.xz help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1320073
ID: 1320074 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1320074
ID: 1320086 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1320086
ID: 1320095 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1320095
ID: 1320113 Test: aarch64 Workstation-upgrade desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/1320113
ID: 1320114 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1320114
ID: 1320126 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1320126
ID: 1320160 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1320160
ID: 1320205 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1320205
ID: 1320224 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1320224

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

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

ID: 1319937 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1319937
ID: 1319975 Test: x86_64 Silverblue-dvd_ostree-iso clocks
URL: https://openqa.fedoraproject.org/tests/1319975
ID: 1319978 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1319978
ID: 1319989 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1319989
ID: 1320068 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1320068
ID: 1320084 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1320084
ID: 1320119 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1320119
ID: 1320135 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1320135
ID: 1320171 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1320171
ID: 1320207 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1320207
ID: 1320231 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1320231

Passed openQA tests: 218/236 (x86_64), 124/165 (aarch64)

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

ID: 1319951 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1319951
ID: 

Re: Rust Stack Spring Cleaning (July 2022 Edition)

[Davide Cavalca via devel]

On Sat, 2022-07-09 at 00:26 +0200, Fabio Valentini wrote:
> If you want a scripted way of adding "@rust-sig" group to many
> packages, you
> can generate an API token on src.fedoraproject.org (with "Modify an
> existing
> project") access level, and use the simple Python script from this
> GitHub gist:

I finally found some time to clean up my script for this and put it up
at https://pagure.io/fedora-sig-onboard . This takes care of adding the
SIG to the package ACL, set the BZ assignee and add the package to
Anitya with the right settings. It's pretty hacky and has minimal error
checking at the moment, but hopefully it can be useful to others as
well.

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

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

[Christian Hergert]

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

One of the primary values of system-wide profiling is being able to see how a 
particular library call might have caused undesirable code paths due to a 
syscall, and where/what was reached (given high enough sampling rate).

Does that need to happen in kernel space? I don't know, perse, other than perf 
needs to be able to do that work as it is what gives us the array of 
instruction pointers back. There was some chatter a number of years ago in perf 
about how to handle ORC from user-space, and if I'm summing this up correctly, 
it was basically..

 - When sampling in PERF_CONTEXT_KERNEL, stop unwinding at the syscall boundary
 - Append stacktrace samples to perf buffer ring
 - Upon rescheduling, backtrace a single time into user-space, and expect the 
consumer to know that N previous samples with matching task-id all have the 
user-space backtrace.

That's a pretty significant behavior change, and all tools would need surgery 
to support it. I have no idea if that is paletable to either side of the 
debate, but it was the one possible direction I saw.

It does have a number of pros, in that you can save a lot of unwinding time on 
syscall-heavy workloads by doing user-space unwinding once, and from scheduler 
task queues (so you can take faults), and can avoid the NMI context being the 
cost-center for accounting. But the cons are significant in that the behavior 
change is expansive, effects all tooling, and will require ORC data across the 
platform.

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

It might seem that way by the description I gave, but we're just talking an 
array of intptr_t or similar. There is no dereferencing or state machines like 
you have with DWARF. Runtime resolution is also essentially bsearch() on 
interval arrays. I really don't think it's the sort of thing that requires Rust.

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

> Christian, would this be sufficient for your needs?

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

It does pose some questions on what would happen with carefully crafted DWARF 
data.
___
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: Once again, more than 8 days delayed notifications

[Stephen Smoogen]

On Sat, 9 Jul 2022 at 11:18, Ralf Corsépius  wrote:

>
>
> Am 09.07.22 um 15:36 schrieb Stephen Smoogen:
> >
> >
> > On Sat, 9 Jul 2022 at 09:25, Ralf Corsépius  > > wrote:
> >
> > Hi,
> >
> > I thought the notification delay mess was fixed. Apparently, I was
> > wrong.
> >
> >
> >
> > No, I believe the service which is behind these emails is called FMN. It
> > is very fragile for multiple reasons where it falls over for different
> > reasons all the time. It is the reason why it is on the top of being
> > replaced by CPE in this quarter (aka by October-ish). Until that
> > happens, please be aware that these notifications are likely to come in
> > bursts as things go up and down. I would also suggest that turning off
> > as many notifications as you can would help the load as one of the
> > largest email problems Fedora Infrastructure has is the many people who
> > have turned on getting email on a lot of events.
>
> Why don't you turn this stuff off globally and send the guys behind it
> back to the drawing board?
>
> In its present shape it's just dysfunctional and not helpful at all.
>
>
I do apologize for this. Thank you for your feedback.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Once again, more than 8 days delayed notifications

[Ralf Corsépius]

Am 09.07.22 um 15:36 schrieb Stephen Smoogen:



On Sat, 9 Jul 2022 at 09:25, Ralf Corsépius > wrote:


Hi,

I thought the notification delay mess was fixed. Apparently, I was
wrong.



No, I believe the service which is behind these emails is called FMN. It 
is very fragile for multiple reasons where it falls over for different 
reasons all the time. It is the reason why it is on the top of being 
replaced by CPE in this quarter (aka by October-ish). Until that 
happens, please be aware that these notifications are likely to come in 
bursts as things go up and down. I would also suggest that turning off 
as many notifications as you can would help the load as one of the 
largest email problems Fedora Infrastructure has is the many people who 
have turned on getting email on a lot of events.


Why don't you turn this stuff off globally and send the guys behind it 
back to the drawing board?


In its present shape it's just dysfunctional and not helpful at all.

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

Re: Orphaning some packages

[Dominic Hopf via devel]

On Fri, 2022-07-08 at 17:38 +0100, Christopher Brown wrote:
> stress-ng

I'll be happy taking over stress-ng.

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

Re: Rust Stack Spring Cleaning (July 2022 Edition)

[Davide Cavalca via devel]

On Sat, 2022-07-09 at 00:26 +0200, Fabio Valentini wrote:
> - dcavalca (2): rust-esphome, rust-rustcat

Fixed, thanks for the reminder.

Cheers
Davide
___
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: Once again, more than 8 days delayed notifications

[Stephen Smoogen]

On Sat, 9 Jul 2022 at 09:25, Ralf Corsépius  wrote:

> Hi,
>
> I thought the notification delay mess was fixed. Apparently, I was wrong.
>
>

No, I believe the service which is behind these emails is called FMN. It is
very fragile for multiple reasons where it falls over for different reasons
all the time. It is the reason why it is on the top of being replaced by
CPE in this quarter (aka by October-ish). Until that happens, please be
aware that these notifications are likely to come in bursts as things go up
and down. I would also suggest that turning off as many notifications as
you can would help the load as one of the largest email problems Fedora
Infrastructure has is the many people who have turned on getting email on a
lot of events.


>
> I just received this:
>
> 
> Subject: corsepiu pushed 1 commit to rpms/perl-Sub-HandlesVia (rawhide)
> Date: Sat,  9 Jul 2022 10:39:46 + (GMT)
> From: notificati...@fedoraproject.org
> ...
> Notification time stamped 2022-07-01 05:57:40 UTC
> ...
> 
>
>
> Ralf
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Once again, more than 8 days delayed notifications

[Ralf Corsépius]

Hi,

I thought the notification delay mess was fixed. Apparently, I was wrong.


I just received this:


Subject: corsepiu pushed 1 commit to rpms/perl-Sub-HandlesVia (rawhide)
Date: Sat,  9 Jul 2022 10:39:46 + (GMT)
From: notificati...@fedoraproject.org
...
Notification time stamped 2022-07-01 05:57:40 UTC
...



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

CPE Weekly Update – Week 27 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 4th - 7th July 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update--week-27-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to docs: https://docs.fedoraproject.org/en-US/infra/

Update
--

### Fedora Infra
* Fas2 is scaled down to 0 instances since last week. Farewell!
* Openshift3 is ready for retirement, will be taking it down later today
* Got toddlers working in staging openshift
* Email thread on infra-sig packages, please contribute
* Koji hubs reinstalled with f36, and z/vm s390x builders upgraded to f36
* Business as usual items


### CentOS Infra including CentOS CI
* Issue with mirrors and dnf being out of sync. PR merged today to fix
* Mirror requests


### Release Engineering
* A few rawhide compose issues, already fixed


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Figured out the root cause of missing module components in CentOS 
Stream 8. Have a script to catch the cases, monitoring it.



## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* Finally happy enough with our code, that we started to port it back 
into the flask-oidc library itself.

* Working on a PR


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 is up to 6608 (+92) packages from 2956 (+45) source packages
* resolved "fails to install" bug for 
[xfce4-sensors-plugin-devel](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f8140103e3)

* filed various "fails to install" bugs for epel packages
* notable epel9 additions:
    * 
[chromium](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-002f30f00a)
    * 
[python-paramiko](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0bfb2c8312) 
(unblocks multiple other packages)



Kindest regards,
CPE Team
___
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-20220709.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-20220708.0):

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

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: [Rust] Rust Stack Spring Cleaning (July 2022 Edition)

[Fabio Alessandro Locati]

On Sat, Jul 9, 2022, at 01:35, Miro Hrončok wrote:
> On 09. 07. 22 0:26, Fabio Valentini wrote:
> > In addition, I would ask of all of you to make sure all your packages have 
> > been
> > added to the @rust-sig group on src.fedoraproject.org (at least with 
> > "commit"
> > access), unless there is a very good reason not to do so (and if that is the
> > case for a particular package on this list, I'd be interested in knowing the
> > reason).
> 
> Should we escalate this trough FESCo? It seems to me that this makes sense as 
> a 
> policy and the maintainers you list here are always the same (mostly 
> pbrobinson, salimma, ignatenkobrain).

I agree that FESCo should intervene and enforce (over time) the SIGs commit 
access on all packages that should be in the SIG scope.
The same applies for golang SIG/packages, in fact I was planning to do the 
similar reminder tomorrow.

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

Fedora-Cloud-36-20220709.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-20220708.0):

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

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