Fedora-Cloud-33-20210727.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-33-20210726.0):

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

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

PSA: partner-bugzilla to be replaced with bugzilla.stage on July 31st

[Kamil Paral]

If any of you uses https://partner-bugzilla.redhat.com (e.g. for
integration testing, etc, basically as a staging Bugzilla instance), please
note that it says:

"This instance of Bugzilla will be shut down permanently on July 31st at
12:30 AM UTC. You should use bugzilla.stage.redhat.com instead"

I noticed very recently as well, and I figured there might be more people
interested in it in this list.

Cheers,
Kamil
___
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: PSA: partner-bugzilla to be replaced with bugzilla.stage on July 31st

[Miro Hrončok]

On 27. 07. 21 10:34, Kamil Paral wrote:
If any of you uses https://partner-bugzilla.redhat.com 
 (e.g. for integration testing, etc, 
basically as a staging Bugzilla instance), please note that it says:


"This instance of Bugzilla will be shut down permanently on July 31st at 12:30 
AM UTC. You should use bugzilla.stage.redhat.com 
 instead"


I noticed very recently as well, and I figured there might be more people 
interested in it in this list.


At least in https://pagure.io/fedora-infra/ansible, there are quite a few 
occurrences.


inventory/group_vars/blockerbugs_stg
roles/bodhi2/base/templates/production.ini.j2
roles/bugzilla2fedmsg/templates/bugzilla2fedmsg.ini
roles/distgit/pagure/templates/pagure-sync-bugzilla.py.j2
roles/ipsilon/templates/saml2_data
roles/openshift-apps/review-stats/templates/config.cfg
roles/openshift-apps/review-stats/templates/cron.yml
roles/openshift-apps/the-new-hotness/files/deploymentconfig.yml
roles/openshift-apps/the-new-hotness/templates/config.toml
roles/packages3/web/templates/packages-app.ini.j2
roles/releng/templates/ftbfs.cfg.j2

--
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: PSA: partner-bugzilla to be replaced with bugzilla.stage on July 31st

[Kamil Paral]

On Tue, Jul 27, 2021 at 10:39 AM Miro Hrončok  wrote:

> On 27. 07. 21 10:34, Kamil Paral wrote:
> > If any of you uses https://partner-bugzilla.redhat.com
> >  (e.g. for integration testing,
> etc,
> > basically as a staging Bugzilla instance), please note that it says:
> >
> > "This instance of Bugzilla will be shut down permanently on July 31st at
> 12:30
> > AM UTC. You should use bugzilla.stage.redhat.com
> >  instead"
> >
> > I noticed very recently as well, and I figured there might be more
> people
> > interested in it in this list.
>
> At least in https://pagure.io/fedora-infra/ansible, there are quite a few
> occurrences.
>

I created https://pagure.io/fedora-infrastructure/issue/10131 to notify the
infra 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-34-20210727.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-34-20210726.0):

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

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

List of long term FTBFS packages to be retired in 1 week

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (i.e. in 
1 week).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 32.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know ASAP and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

 Package  (co)maintainersLatest build
==
cardpeek kalev   Fedora 32
percona-xtrabackup   slaanesh, slankes   Fedora 32
sugar-view-slidescallkalpa, chimosky, pbrobinson, tuxbrewr   Fedora 31

The following packages require above mentioned packages:
Depending on: percona-xtrabackup (1)
holland (maintained by: immanetize, jeffreyness, survient)
holland-xtrabackup.noarch requires /usr/bin/xtrabackup

Affected (co)maintainers
callkalpa: sugar-view-slides
chimosky: sugar-view-slides
immanetize: percona-xtrabackup
jeffreyness: percona-xtrabackup
kalev: cardpeek
pbrobinson: sugar-view-slides
slaanesh: percona-xtrabackup
slankes: percona-xtrabackup
survient: percona-xtrabackup
tuxbrewr: sugar-view-slides
___
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: 20210727.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210726.n.0
NEW: Fedora-Rawhide-20210727.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  2
Dropped packages:1
Upgraded packages:   104
Downgraded packages: 0

Size of added packages:  21.00 MiB
Size of dropped packages:33.38 KiB
Size of upgraded packages:   7.58 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: mqttcli-0.1.0-1.fc35
Summary: Simple MQTT CLI pub/sub client
RPMs:mqttcli
Size:10.58 MiB

Package: python-sqlalchemy1.3-1.3.24-1.fc35
Summary: Modular and flexible ORM library for python (legacy 1.3.x version)
RPMs:python-sqlalchemy1.3-doc python3-sqlalchemy1.3
Size:10.43 MiB


= DROPPED PACKAGES =
Package: python-pytest-relaxed-1.1.5-11.fc34
Summary: Relaxed test discovery for pytest
RPMs:python3-pytest-relaxed
Size:33.38 KiB


= UPGRADED PACKAGES =
Package:  FlightGear-2020.3.10-1.fc35
Old package:  FlightGear-2020.3.9-1.fc35
Summary:  The FlightGear Flight Simulator
RPMs: FlightGear
Size: 35.10 MiB
Size change:  190.70 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
2020.3.9-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Mon Jul 26 2021 Fabrice Bellet  - 2020.3.10-1
  - new upstream release


Package:  FlightGear-Atlas-0.5.0-0.71.cvs20141002.fc35
Old package:  FlightGear-Atlas-0.5.0-0.69.cvs20141002.fc35
Summary:  Flightgear map tools
RPMs: FlightGear-Atlas
Size: 3.50 MiB
Size change:  772 B
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
0.5.0-0.70.cvs20141002
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Mon Jul 26 2021 Fabrice Bellet  - 
0.5.0-0.71.cvs20141002
  - rebuild with newer SimGear


Package:  FlightGear-data-2020.3.10-1.fc35
Old package:  FlightGear-data-2020.3.9-1.fc35
Summary:  FlightGear base scenery and data files
RPMs: FlightGear-data
Size: 1.63 GiB
Size change:  371.84 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
2020.3.9-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Mon Jul 26 2021 Fabrice Bellet  - 2020.3.10-1
  - new upstream release


Package:  SimGear-2020.3.10-1.fc35
Old package:  SimGear-2020.3.9-1.fc35
Summary:  Simulation library components
RPMs: SimGear SimGear-devel
Size: 12.02 MiB
Size change:  71.78 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
2020.3.9-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Mon Jul 26 2021 Fabrice Bellet  - 2020.3.10-1
  - new upstream release


Package:  arc-theme-20210412-4.fc35
Old package:  arc-theme-20210412-2.fc35
Summary:  Flat theme with transparent elements
RPMs: arc-theme arc-theme-plank
Size: 628.44 KiB
Size change:  634 B
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
20210412-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Sun Jul 25 2021 Mukundan Ragavan  - 20210412-4
  - Fix graphical glitches


Package:  chessx-1.5.6-4.fc35
Old package:  chessx-1.5.6-3.fc35
Summary:  Chess Database and PGN viewer
RPMs: chessx
Size: 16.38 MiB
Size change:  747 B
Changelog:
  * Mon Jul 26 2021 Ondrej Mosnacek  - 1.5.6-4
  - Work around Wayland issue


Package:  combblas-1.6.2-0.13.beta2.fc35
Old package:  combblas-1.6.2-0.12.beta2.fc34
Summary:  The Combinatorial BLAS Library
RPMs: combblas-mpich combblas-mpich-devel combblas-openmpi 
combblas-openmpi-devel
Size: 6.42 MiB
Size change:  -57.71 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
1.6.2-0.13.beta2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild


Package:  containers-common-4:1-24.fc35
Old package:  containers-common-4:1-22.fc35
Summary:  Common configuration and documentation for containers
RPMs: containers-common
Size: 63.85 KiB
Size change:  2.32 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
4:1-23
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Mon Jul 26 2021 Dan Walsh  - 4:1-24
  - Add support for signed RHEL images, enabled by default


Package:  cross-gcc-11.1.1-1.fc35
Old package:  cross-gcc-10.2.1-3.fc35.2
Summary:  Cross C compiler
RPMs: cross-gcc-common gcc-aarch64-linux-gnu gcc-alpha-linux-gnu 
gcc-arc-linux-gnu gcc-arm-linux-gnu gcc-avr32-linux-gnu gcc-bfin-linux-gnu 
gcc-c++-aarch64-linux-gnu gcc-c++-alpha-linux-gnu gcc-c++-arc-linux-gnu 
gcc-c++-arm-linux-gnu gcc-c++-avr32-linux-gnu gcc-c++-bfin-linux-gnu 
gcc-c++-c6x-linux-gnu gcc-c++-frv-linux-gnu gcc-c++-h8300-linux-gnu 
gcc-c++-hppa-linux-gnu gcc-c++-hppa64-linux-gnu gcc-c++-ia64-linux-gnu 
gcc-c++-m32r-linux-gnu

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed, 1 result missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud

Failed openQA tests: 6/201 (x86_64), 5/138 (aarch64)

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

ID: 936109  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/936109
ID: 936150  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/936150
ID: 936301  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/936301
ID: 936316  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/936316
ID: 936355  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/936355
ID: 936381  Test: x86_64 universal install_multi@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/936381
ID: 936429  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/936429
ID: 936437  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/936437

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

ID: 936200  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/936200
ID: 936281  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/936281
ID: 936413  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/936413

Soft failed openQA tests: 18/138 (aarch64), 22/201 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 936291  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936291

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

ID: 936101  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/936101
ID: 936102  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936102
ID: 936157  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936157
ID: 936158  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/936158
ID: 936216  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/936216
ID: 936225  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936225
ID: 936234  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936234
ID: 936311  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/936311
ID: 936314  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/936314
ID: 936318  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/936318
ID: 936319  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/936319
ID: 936322  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/936322
ID: 936325  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/936325
ID: 936331  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/936331
ID: 936337  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/936337
ID: 936338  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/936338
ID: 936339  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/936339
ID: 936340  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/936340
ID: 936363  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/936363
ID: 936368  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/936368
ID: 936374  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/936374
ID: 936378  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/936378
ID: 936379  Test: x86_64 universal upgrade_server_64bit
URL: https://

Re: Free Pascal and F35 Mass Rebuild

[Artur Frenszek-Iwicki]

Thanks for the help, Florian. Unfortunately, I'll have to admit straight away 
that even though I co-maintain FPC, my knowledge of assembly, ELF and compilers 
in general is close to non-existent, so I don't really know how to apply the 
minimal patch you gave.

I wanted to submit a bug report upstream to FPC, but it just so happens that 
the project is currently moving from self-hosted SVN version control + Mantis 
bug tracker to GitLab, and while this is ongoing, both Mantis and GitLab issues 
are inaccessible.

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

Re: Fedora rawhide compose report: 20210727.n.0 changes

[Michael Schwendt]

Something in grep/sed/rpm is broken since today or yesterday.

On July 24th, a %global definition in a spec file still worked.
It still works with a local Mock build for Rawhide/F35.
It fails in koji Rawhide:
https://kojipkgs.fedoraproject.org//work/tasks/3604/72743604/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora rawhide compose report: 20210727.n.0 changes

[Petr Pisar]

V Tue, Jul 27, 2021 at 03:03:36PM +0200, Michael Schwendt napsal(a):
> Something in grep/sed/rpm is broken since today or yesterday.
> 
> On July 24th, a %global definition in a spec file still worked.
> It still works with a local Mock build for Rawhide/F35.
> It fails in koji Rawhide:
> https://kojipkgs.fedoraproject.org//work/tasks/3604/72743604/build.log

It's a locale in sed:

$ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
/usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=C.UTF-8 sed 
's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
48 /* 3.8-devel */
$ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
/usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=en_US.UTF-8 sed 
's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
48

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

Self Introduction: Peter Savage

[Pete Savage]

Hi all,

I was a MOTU for Ubuntu in the past, recently I've become interested in
composing music and there are a number of packages that I'd like to see in
Fedora's main repo. I'm tacklingthe sFizz package first, hoping you'll see
a package for review from me soon!

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

Re: Fedora rawhide compose report: 20210727.n.0 changes

[Florian Weimer]

* Petr Pisar:

> V Tue, Jul 27, 2021 at 03:03:36PM +0200, Michael Schwendt napsal(a):
>> Something in grep/sed/rpm is broken since today or yesterday.
>> 
>> On July 24th, a %global definition in a spec file still worked.
>> It still works with a local Mock build for Rawhide/F35.
>> It fails in koji Rawhide:
>> https://kojipkgs.fedoraproject.org//work/tasks/3604/72743604/build.log
>
> It's a locale in sed:
>
> $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
> /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=C.UTF-8 sed 
> 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
> 48 /* 3.8-devel */
> $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
> /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=en_US.UTF-8 sed 
> 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
> 48

Thanks.  I filed: .
Carlos is going to look into it.

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

Re: Fedora rawhide compose report: 20210727.n.0 changes

[Michael Schwendt]

On Tue, 27 Jul 2021 15:26:31 +0200, Petr Pisar wrote:

> It's a locale in sed:
> 
> $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
> /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=C.UTF-8 sed 
> 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
> 48 /* 3.8-devel */
> $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
> /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=en_US.UTF-8 sed 
> 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
> 48

What has changed and where?
Why does [0-9]+ cover more than the numerical part of the string?
___
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

Self Introduction: Ma Zheng

[Ma, Zheng]

Hi all,
This is Zheng, newly coming to Fedora community :)
I'm now working on the rpm packaging things, hoping to contribute a package 
soon!

Zheng

___
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

F35 mass rebuild is finished

[Tomas Hrcka]

Hi all, Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora
35 on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for:

https://fedoraproject.org/wiki/Changes/Autoconf_271
https://fedoraproject.org/wiki/Changes/RPM-4.17
https://fedoraproject.org/wiki/Changes/IBus_1.5.25
https://fedoraproject.org/wiki/Changes/F35Boost176
https://fedoraproject.org/wiki/Changes/F35MingwEnvToolchainUpdate
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
https://fedoraproject.org/wiki/Changes/golang1.17
https://fedoraproject.org/wiki/Changes/LLVM-13

The mass rebuild was done in a side tag (f35-rebuild) and moved over to
f35. Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html Things
still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html

21151 builds have been tagged into f35, there is currently 772 failed
builds that need to be addressed by the package maintainers. FTBFS bugs
will be filed shortly. Please be sure to let releng know if you see any
bugs in the reporting. You can contact releng in #fedora-releng on
libera.chat, by dropping an email to our list[2] or filing an issue in
pagure[3] Regards,
Tomas Hrcka
fas: humaton
libera.chat: jednorozec
[1] 
https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html [2]
https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 mass rebuild is finished

[Jonathan Wakely]

On Tue, 27 Jul 2021 at 15:37, Tomas Hrcka wrote:
>
> Hi all, Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora 35 
> on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for:
>
> [...]
> https://fedoraproject.org/wiki/Changes/F35Boost176

This change isn't in rawhide, so the rebuild won't achieve much for that change.
___
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: F35 mass rebuild is finished

[Milan Crha]

On Tue, 2021-07-27 at 16:23 +0200, Tomas Hrcka wrote:
> The mass rebuild was done in a side tag (f35-rebuild) and moved over to
> f35.
> 
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html
> 
> Things still needing rebuilding
> https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html

Hi,
looking on the libical build break [1], it looks like the ppc64le build
doesn't use _target_platform properly in the CMake macros, because, if
I read the build.log correctly, the build is done into
`redhat-linux-build`, while the `_target_platform` evaluates to
`ppc64le-redhat-linux-gnu` (it's used in the `make test` call in the
libical.spec file). The i686 also builds into `redhat-linux-build`, not
the i686 target platform directory. I did not look on other arches.

Is this change intentional or it's a bug in the build process/CMake
macros?

I searched for the "_target_platform" here and the latest discussion
mentioning it was almost a year ago.
Bye,
Milan

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=72392998
___
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

How to correctly handle scriptlets for systemd template unit instances

[Fabio Valentini]

Hi everybody,

I have a package (syncthing [0]) that provides both system and user
units, depending on how the user wants the service to start. The user
units are obviously specific to each user, but the system units are
templates that are instantiated for the user who wants to have the
service run at boot.

Now, this is the problem: I do not know how to adapt the systemd
scriptlets [1] for this. Wildcards are not supported, and systemd on
Fedora 34+ now warns when encountering such wildcards, so the way it's
done in the syncthing package right now is not correct (as reported on
BugZilla [2]).

Glob pattern passed, but globs are not supported for this.
Invalid unit name "syncthing@*.service" escaped as "syncthing@\x2a.service".

Does anybody know the correct way to handle this? Obviously those
system units can't (and shouldn't) be enabled for all users on update
or install, but I still want all service instances to be restarted on
update. The systemd scriptlet Guidelines do not cover this scenario at
all.

Thanks,
Fabio

[0]: 
https://src.fedoraproject.org/rpms/syncthing/blob/rawhide/f/syncthing.spec#_378
[1]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1986258
___
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: F35 mass rebuild is finished

[Michael Cronenworth]

On 7/27/21 10:20 AM, Milan Crha wrote:

Hi,
looking on the libical build break [1], it looks like the ppc64le build
doesn't use _target_platform properly in the CMake macros, because, if
I read the build.log correctly, the build is done into
`redhat-linux-build`, while the `_target_platform` evaluates to
`ppc64le-redhat-linux-gnu` (it's used in the `make test` call in the
libical.spec file). The i686 also builds into `redhat-linux-build`, not
the i686 target platform directory. I did not look on other arches.

Is this change intentional or it's a bug in the build process/CMake
macros?

I searched for the "_target_platform" here and the latest discussion
mentioning it was almost a year ago.


Hi Milan,

This is affectting many different packages that use the %cmake3 macro and try to 
enter its build directory. I traced the root of it.


The %cmake3 macro calls the %_vpath_builddir macro to set its build directory 
name.

F35 - %_vpath_builddir: "%{_vendor}-%{_target_os}-build" (generates: 
"redhat-linux")
F34 and earlier - %_vpath_builddir: "%_target_platform" (generates: 
"$ARCH-redhat-linux-gnu")


Why did this macro change in F35? (and only recently...)

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

Re: F35 mass rebuild is finished

[Michael Cronenworth]

On 7/27/21 10:37 AM, Michael Cronenworth wrote:


This is affectting many different packages that use the %cmake3 macro and try to 
enter its build directory. I traced the root of it.


The %cmake3 macro calls the %_vpath_builddir macro to set its build directory 
name.

F35 - %_vpath_builddir: "%{_vendor}-%{_target_os}-build" (generates: 
"redhat-linux")
F34 and earlier - %_vpath_builddir: "%_target_platform" (generates: 
"$ARCH-redhat-linux-gnu")


Why did this macro change in F35? (and only recently...) 


So Neal purposely made this change on July 10. @Neal?
___
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: F35 mass rebuild is finished

[Björn 'besser82' Esser]

Am Dienstag, dem 27.07.2021 um 16:23 +0200 schrieb Tomas Hrcka:
> Hi all,
> 
> Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora 35
> on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for:
> 
> https://fedoraproject.org/wiki/Changes/LTOBuildImprovements


This change hasn't been implemented as well.


signature.asc
Description: This is a digitally signed message part
___
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: coreos-diskimage-rehydrator

[Colin Walters]

On Fri, Jul 23, 2021, at 10:23 AM, Richard W.M. Jones wrote:
> 
> Yeah I saw it but as with many things I didn't necessarily understand
> it :-( So in fact it's nothing to do with streams as I was thinking
> about it.  I guess "stream" means something like "software stream", as
> in which distro and stable version series.

Right.  For us this is what a "release" is, and it's how we expect most people 
to find machine images to use.

> I gave a talk about this.  I don't know if it's at all relevant to
> what you're doing, but here it is:
> 
> "Disk image pipelines: Efficiently copying, sparsifying, modifying, 
> streaming multi-terabyte disk images between systems"
> http://oirase.annexia.org/tmp/disk-image-pipelines.mp4

Hmm.  I think the big difference here is that our "golden" OS images don't have 
any user data, so they're never¹ going to be measured in TB.  Most scenarios 
pulling down a ~1GB image just via `curl` (or our fancier `coreos-installer 
download` CLI) is going to be fine.

> > However, shipping tons of disconnected container images is chaos -
> > how do you CI test that?  (In the same way shipping lots of RPMs
> > independently is chaos) So a cool OpenShift 4 specific thing is this
> > concept of the "release image" which is a *single container image*
> > that contains @sha256 references to all the other containers
> > (including the OS updates).
> 
> (Sounds like git / docker / Fedora atomic...)

Since we're talking about 
https://github.com/cgwalters/coreos-diskimage-rehydrator to start...this would 
*fully* orient our release process around container images.  We never did 
anything like this in the Fedora Atomic days which used pungi i.e. the the 
baseline "disk images served via Apache directory listing".

This is related but also orthogonal to 
https://github.com/coreos/fedora-coreos-tracker/issues/812 which is 
encapsulating the in-place OS update (equivalent "set of RPMs" e.g. or for us 
"ostree commit") as a container image.

I just have to emphasize it's trying to orient how we deliver the OS (and how 
we CI test it, how we version it, how we store those versions, etc.) to be 
oriented around container images.

Nothing stops us from shipping a (traditional yum + cloud-init) qcow2 via this, 
or for that matter a Anaconda ISO.  But the assumption here is admins who want 
a CoreOS-style system want a "container native" flow.

> The "bootimage" here is (for example) the Fedora AMI that might be
> shipped in Amazon.  So it would contain the bootloader, kernel, and a
> base distribution?

This "bootimage" term is touched on in 
https://github.com/coreos/fedora-coreos-tracker/blob/main/internals/README-internals.md#ignitionplatformid
 as well as 
https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/

But basically: the AMI/OpenStack qcow2/etc. are just a "shell" or "wrapper" for 
the ostree commit which is 99% of the operating system.  And as that page says, 
crucially that ostree commit is *bit for bit identical* across platforms.  We 
don't have anything like "just tweak /etc/resolv.conf on OpenStack only".   An 
ostree commit is a pair of (kernel + userspace) but *not* the bootloader which 
is indeed part of the disk image. 

See https://github.com/coreos/bootupd for addressing bootloader updates.

¹ I hope.
___
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: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)

[Stephen Gallagher]

On Mon, Jul 19, 2021 at 12:18 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/WirePlumber
>
> == Summary ==
> PipeWire currently uses a simple example session manager. This
> proposal is to move to the more powerful WirePlumber session manager.
>

Has the Fedora Workstation Working Group made any recommendations
around this? Does that group feel that WirePlumber is mature enough to
replace the existing session manager?
___
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: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)

[Michael Catanzaro]

On Tue, Jul 27 2021 at 12:50:29 PM -0400, Stephen Gallagher 
 wrote:

Has the Fedora Workstation Working Group made any recommendations
around this? Does that group feel that WirePlumber is mature enough to
replace the existing session manager?


This change proposal is the first I've heard of it. But since this is 
being proposed by the author of Pipewire, I kind of assume it's good, 
and I doubt Workstation WG would see the need to get involved unless 
concerns are raised. Does WirePlumber have some sort of deficiencies 
compared to pipewire-session-manager?


___
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: F35 mass rebuild is finished

[Jeff Law]

On 7/27/2021 10:31 AM, Björn 'besser82' Esser wrote:

Am Dienstag, dem 27.07.2021 um 16:23 +0200 schrieb Tomas Hrcka:

Hi all,

Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora 35
on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for:

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

This change hasn't been implemented as well.
Correct.  I've changed jobs and not looking at this right now.  I likely 
will again in the future though, just got to get over certain higher 
priority hurdles.


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

Re: PSA: partner-bugzilla to be replaced with bugzilla.stage on July 31st

[Kevin Fenzi]

On Tue, Jul 27, 2021 at 10:43:01AM +0200, Kamil Paral wrote:
> On Tue, Jul 27, 2021 at 10:39 AM Miro Hrončok  wrote:
> 
> > On 27. 07. 21 10:34, Kamil Paral wrote:
> > > If any of you uses https://partner-bugzilla.redhat.com
> > >  (e.g. for integration testing,
> > etc,
> > > basically as a staging Bugzilla instance), please note that it says:
> > >
> > > "This instance of Bugzilla will be shut down permanently on July 31st at
> > 12:30
> > > AM UTC. You should use bugzilla.stage.redhat.com
> > >  instead"
> > >
> > > I noticed very recently as well, and I figured there might be more
> > people
> > > interested in it in this list.
> >
> > At least in https://pagure.io/fedora-infra/ansible, there are quite a few
> > occurrences.
> >
> 
> I created https://pagure.io/fedora-infrastructure/issue/10131 to notify the
> infra team.

We are well aware, but many thanks for following up! :) 

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

Re: Fedora Zuul had been integrated with Testing Farm and TMT

[Colin Walters]

On Wed, Jul 21, 2021, at 9:04 AM, Miroslav Vadkerti wrote:
> Dear all,
> 
> Today we are gladly announcing that the Zuul CI system for Fedora, 

Congrats!

> which is running checks for pull requests against 
> src.fedoraproject.org, will also run Test Management Tool (tmt) based 
> tests via the new `rpm-tmt-test` check, if they are available. The test 
> environment is the same as with Fedora CI, as both CI systems use our 
> Testing Farm service as the backend.
> 
> For more information about:
> 
> * Fedora Zuul: https://fedoraproject.org/w/index.php?title=Zuul-based-ci
> * Test Management Tool (tmt): https://docs.fedoraproject.org/en-US/ci/tmt/

I skimmed the docs and it's possible I'm missing it, but do you have
some links to recent nontrivial projects that are using this?  
The tmt docs show me how to run e.g. `bash --version` which isn't
very compelling.  I am particularly interested in things that reuse upstream CI 
tests.

(If Fedora used a unified git repo, I could easily just grep it, but...)
___
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: [Fedocal] Reminder meeting : Prioritized bugs and issues

[Ben Cotton]

On Tue, Jul 27, 2021 at 7:00 AM  wrote:
>
> You are kindly invited to the meeting:
>Prioritized bugs and issues on 2021-07-28 from 11:00:00 to 12:00:00 
> America/Indiana/Indianapolis
>At fedora-meetin...@libera.chat
>
> More information available at: 
> https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/

The following nominated bugs are on the agenda:
* SELinux is preventing gnome-session-c from 'write' accesses on the
sock_file dbus-7hye6voX3Y. —
https://bugzilla.redhat.com/show_bug.cgi?id=1949712

In addition, we will check in on the accepted bugs:
* A glibc test hangs upon pthread cancellation when glibc is compiled
with annobin turned on —
https://bugzilla.redhat.com/show_bug.cgi?id=1951492
* Akonadi does not start due to DB failure —
https://bugzilla.redhat.com/show_bug.cgi?id=1953675

--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Consider packaging Jello

[Kelly Brazil]

Thank you, but I'm not interested in becoming a package maintainer myself. I'm 
looking for someone to package and maintain a CLI app I developed. It is 
currently packaged or in process on some other platforms like homebrew, debian, 
AUR, etc.
___
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

Azure CLI + SDK packaging update and review swap request

[Major Hayden]

Hey folks,

Thanks to everyone who helped with package reviews and guidance as I 
cobbled together the Azure CLI and SDK packages. The work is almost 
complete!


There are a few remaining packages left to review:

  python-azure-appconfiguration (required SDK component)
  https://bugzilla.redhat.com/show_bug.cgi?id=1981573

  python-azure-devtools (for testing the Azure CLI/SDK)
  https://bugzilla.redhat.com/show_bug.cgi?id=1986414

  python-azure-mgmt-insights (required SDK component)
  https://bugzilla.redhat.com/show_bug.cgi?id=1981574

Once those are done, Azure CLI is ready to review:

  azure-cli
  https://bugzilla.redhat.com/show_bug.cgi?id=1986602

Then there are a couple of remaining SDK components that are 
nice-to-have, but not directly required for the CLI to function:


  python-azure-mgmt-azurestackhci
  https://bugzilla.redhat.com/show_bug.cgi?id=1982432

  python-azure-mgmt-hybridcompute
  https://bugzilla.redhat.com/show_bug.cgi?id=1982435

Most of the python-azure* packages are quite standardized using 
pyproject-rpm-macros. If someone has some spare cycles to look at any of 
these, I'll be happy to do a review swap with you. Most of my experience 
is around packaging C/C++ and Python applications, but I've done Ruby 
and Golang, too.


Thank you!

--
Major Hayden


OpenPGP_0x737051E0C1011FB1.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: squashfs-tools being updated in rawhide

[Bruno Wolff III]

The upstream fix looks good and squashfs-tools-4.5-2 has the patch and is 
in today's rawhide compose.
There will be a minor point release for squashfs-tools in the near future 
with the fix. But phillip is waiting a short bit to see if any other 
problems get discovered before making a new release.
There was one minor security issue noted in the release notes, so I will 
be looking at getting this into f34 and f35 eventually. The issue is 
with unsquashing untrusted squashfs images potentially writing files in 
unexpected locations, so I think we can wait a short bit to see if there 
are issues with the new version before getting it into f34 and f33.

___
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: Consider packaging Jello

[Blaise Pabon]

Hi Kelly,

Let's see if I can hook you up.
It would be a great excuse to get back in touch with you!
I'm in eastern time zone these days, so send me your favorite contact info
and we'll set something up.

Best,
blaise at gmail

On Tue, Jul 27, 2021 at 3:50 PM Kelly Brazil 
wrote:

> Thank you, but I'm not interested in becoming a package maintainer myself.
> I'm looking for someone to package and maintain a CLI app I developed. It
> is currently packaged or in process on some other platforms like homebrew,
> debian, AUR, etc.
> ___
> 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
>


-- 
LinkedIn   |  Quora
  |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
___
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: Consider packaging Jello

[Kelly Brazil]

Blaise! Awesome - long time, man! Will do.

Kelly
___
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-35-20210727.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/16 (x86_64), 3/15 (aarch64)

New failures (same test not failed in Fedora-IoT-35-20210726.0):

ID: 936467  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/936467
ID: 936484  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/936484

Old failures (same test failed in Fedora-IoT-35-20210726.0):

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

Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-35-20210726.0):

ID: 936457  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/936457
ID: 936459  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936459
ID: 936460  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/936460
ID: 936473  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936473

Passed openQA tests: 12/16 (x86_64), 11/15 (aarch64)

New passes (same test not passed in Fedora-IoT-35-20210726.0):

ID: 936463  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/936463
ID: 936465  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/936465
ID: 936471  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/936471
ID: 936474  Test: aarch64 IoT-dvd_ostree-iso base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/936474

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.43 to 0.26
Previous test data: https://openqa.fedoraproject.org/tests/935695#downloads
Current test data: https://openqa.fedoraproject.org/tests/936459#downloads
-- 
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: Fedora Zuul had been integrated with Testing Farm and TMT

[Miro Hrončok]

On 27. 07. 21 20:37, Colin Walters wrote:

(If Fedora used a unified git repo, I could easily just grep it, but...)


Here you go, it is 12 GB:

https://src.fedoraproject.org/repo/git-seed-latest.tar.xz

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

Standard version specification in Dockerfile's for 'x-pkg verrel'

[James Kunstle]

Hey y'all,

I'm a developer at Red Hat working on adding a user-requested feature to the 
'x-pkg' line of products.
Specifically, the user would like the 'x-pkg verrel' command to work for those 
projects under the 
container/* branch of Fedora targeted software in the same way that the command 
works for 
rpm/ software.

issue: https://pagure.io/rpkg/issue/547

However, different container maintainers include the metadata about their 
Dockerfile's in different ways.
Take nginx for example. Its Dockerfile contains both:

NGINX_VERSION=1.12

and 

VERSION=0

What would be the correct way to solve this collision for a hypothetical 
workflow that you might have?
Are there any ad hoc best-practices w.r.t Dockerfile standards involving 
specifying the version and release 
number?

Any feedback or suggestions would be helpful.

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

Standard version specification in Dockerfile's for 'x-pkg verrel'

[James Kunstle]

Hey y'all,

I'm a developer at Red Hat working on adding a user-requested feature to the 
'x-pkg' line of products.
Specifically, the user would like the 'x-pkg verrel' command to work for those 
projects under the 
container/* branch of Fedora targeted software in the same way that the command 
works for 
rpm/ software.

issue: https://pagure.io/rpkg/issue/547

However, different container maintainers include the metadata about their 
Dockerfile's in different ways.
Take nginx for example. Its Dockerfile contains both:

NGINX_VERSION=1.12

and 

VERSION=0

What would be the correct way to solve this collision for a hypothetical 
workflow that you might have?
Are there any ad hoc best-practices w.r.t Dockerfile standards involving 
specifying the version and release 
number?

Any feedback or suggestions would be helpful.

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

systemd-oomd blows away the gnome-shell desktop session

[David Airlie]

Hi,

I've been using f34 with gnome/wayland session on a 16MB machine which
has 8GB zram swap configured.

If I build anything large inside my desktop environment (llvm/clang)
from a gnome-terminal, systemd-oomd blows away my whole desktop slice.
This seems overly hostile.

Now in theory I can use systemd-run to run a shell but my
understanding is the DE is meant to be smarter here.

Is it at least launching firefox etc in new cgroups or are all
processes on my desktop in one big cgroup?

Even if it launched gnome-terminal in another group I assume this
would result in it blowing away all my open terminals just to kill the
compiler/linker that is consuming all the RAM/swap. Again this seems
overly hostile.

Any ideas other than campaigning for systemd-oomd to be turned off again?

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

Re: Self Introduction: Ma Zheng

[Robin Lee]

On Tue, Jul 27, 2021 at 10:29 PM Ma, Zheng  wrote:
>
> Hi all,
>
> This is Zheng, newly coming to Fedora community :)
>
> I’m now working on the rpm packaging things, hoping to contribute a package 
> soon!
Welcome! Hope for your first package!

- robin
>
>
>
> Zheng
>
>
>
> ___
> 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: systemd-oomd blows away the gnome-shell desktop session

[Aleksei Bavshin]

On 7/27/21 6:23 PM, David Airlie wrote:

Hi,

I've been using f34 with gnome/wayland session on a 16MB machine which
has 8GB zram swap configured.

If I build anything large inside my desktop environment (llvm/clang)
from a gnome-terminal, systemd-oomd blows away my whole desktop slice.
This seems overly hostile.

Now in theory I can use systemd-run to run a shell but my
understanding is the DE is meant to be smarter here.

Is it at least launching firefox etc in new cgroups or are all
processes on my desktop in one big cgroup?


IIRC, gnome-terminal supposed to put each tab into a new cgroup. And 
Gnome would create cgroup for each desktop application started via Gnome 
shell or glib functions.
While it's still a bit fragile and there's a lot of ways to escape (i.e. 
xdg-open, third-party application launchers, starting apps from the 
terminal, etc.), normal use in Gnome should work just fine.


---
From your description, something obviously went wrong: either 
assignment of cgroups has failed and everything is in the same big 
group, or sd-oomd made a bad shot. systemd-cgls should show which it is.



For the former, I happen to see at least one case where this outright 
fails - some SELinux user roles don't have access to the required 
systemd dbus interface and method call with cgroup assignment couldn't 
be sent.
For the latter, I noticed that on my old hw (8GB ram) sd-oomd always 
preferred to kill firefox instead of gcc. Something made cgroup with 
firefox less likeable ¯\_(ツ)_/¯



Even if it launched gnome-terminal in another group I assume this
would result in it blowing away all my open terminals just to kill the
compiler/linker that is consuming all the RAM/swap. Again this seems
overly hostile.

Any ideas other than campaigning for systemd-oomd to be turned off again?

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



--
With best regards,
Aleksei Bavshin
___
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: systemd-oomd blows away the gnome-shell desktop session

[David Airlie]

On Wed, Jul 28, 2021 at 12:14 PM Aleksei Bavshin
 wrote:
>
> On 7/27/21 6:23 PM, David Airlie wrote:
> > Hi,
> >
> > I've been using f34 with gnome/wayland session on a 16MB machine which
> > has 8GB zram swap configured.
> >
> > If I build anything large inside my desktop environment (llvm/clang)
> > from a gnome-terminal, systemd-oomd blows away my whole desktop slice.
> > This seems overly hostile.
> >
> > Now in theory I can use systemd-run to run a shell but my
> > understanding is the DE is meant to be smarter here.
> >
> > Is it at least launching firefox etc in new cgroups or are all
> > processes on my desktop in one big cgroup?
>
> IIRC, gnome-terminal supposed to put each tab into a new cgroup. And
> Gnome would create cgroup for each desktop application started via Gnome
> shell or glib functions.
> While it's still a bit fragile and there's a lot of ways to escape (i.e.
> xdg-open, third-party application launchers, starting apps from the
> terminal, etc.), normal use in Gnome should work just fine.
>
> ---
>  From your description, something obviously went wrong: either
> assignment of cgroups has failed and everything is in the same big
> group, or sd-oomd made a bad shot. systemd-cgls should show which it is.

Thanks for the hint, systemd-cgls at least makes it appear as if everything
is in different slice

─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ ├─session.slice

│   │ ├─app.slice

│   │ │ ├─app-org.gnome.Terminal.slice
│   │ │ │ ├─vte-spawn-f4a41678-fa09-4ab7-b6d4-d89e18bdb5f4.scope

I do find it strange it picks
Killed 
/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service

I might have to dig into systemd-oomd to see why it picks totally the
wrong option here.

Is there a command to list the current memory usage for each cgroup?

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

Re: systemd-oomd blows away the gnome-shell desktop session

[Chris Murphy]

Killed 
/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service
>Is there a command to list the current memory usage for each cgroup?

Yes, either in sysfs or you can use systemd-cgls -m, and you can pass
a path to eliminate extraneous processes and reveal more detail

$ systemd-cgtop -m /user.slice/user-1000.slice/user@1000.service/app.slice

Or
$ cd 
/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-cgroupify.slice
$ grep -R . cgroupify@app-gnome-firefox-2532.scope.service/

We're expecting to get more detailed logging information in the next
version of systemd slated for Fedora 35. But nevertheless what you're
describing could be a bug so I suggest filing one against systemd, and
ideally include the entire journal for this boot, e.g.
journalctl -b -o short-monotonic --no-hostname > journal.log
and attach it to the bug report. Or at least start 5 minutes of
logging before the unexpected behavior.

It is uresourced that includes the cgroupify utility that sticks
browser tabbed processes into their own cgroup. While uresourced is
enabled by default on Workstation, it's not on (yet) on other
desktops, but is considered safe to run. So if you're not using
Workstation edition you might want to install and enable uresourced,
which is itself intended to be temporary.


Chris Murphy
___
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: systemd-oomd blows away the gnome-shell desktop session

[Chris Murphy]

Also there's below:
https://github.com/facebookincubator/below

Hopefully it'll get packaged soon.
https://discussion.fedoraproject.org/t/article-proposal-below-an-interactive-resource-monitor-for-modern-linux-systems/31176/2


Chris Murphy
___
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