Fedora 34 90 second timeout in initrd / dbus ordering issue

[Hans de Goede]

Hi Zbigniew, Justin,

I assume you are familiar with $subject, also see e.g. :

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

I have just come back from a week vacation and I see that this is
still not resolved, what is the current status of this ?

This is really making Fedora look bad, IMHO we really need to
get this fixed ASAP. Are there any ideas what is necessary to
fix / who we need to poke to get this fixed?

Regards,

Hans
___
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: Standard version specification in Dockerfile's for 'x-pkg verrel'

[Casper]

James Kunstle a écrit :
> 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?
> 

Hi James,

As far I can see in the Docker images produced by the Cloud SIG
(http://fedoraproject.org/wiki/Cloud), it seems to be this rule:

_VERSION=

you saw NGINX_VERSION=1.12

I saw MYSQL_VERSION=10.5.9 because I'm using mariadb Docker image.

But personnaly, I think it is not a good idea to do this. It gives a
lot of issue and make it harder to maintain the Dockerfile.

Perhaps it is useful on database softwares, to keep compatibility, but
for something else, I think it's useless. If you specify the version
in the Dockerfile, this info will be obsolete and false by the
time. If you add tests in your Dockerfile to be sure you're installing
this version exactly, the Docker image will fail to build by the
time... then you need to fix the Dockerfile.

So, where do I specify the version of the software (because I need
this information, anyway) ?

I put it in the tag of the image during the build (or after), like
that:

poezio:0.13.1-9

:-

regards,
Casper
-- 
GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org
CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der
Jabber/XMPP Messaging: cas...@casperlefantom.net


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: F35 Change: libffi 3.4 (late System-Wide Change proposal)

[Ben Cotton]

On Wed, Jul 14, 2021 at 2:28 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/LIBFFI34
>
This proposal has been deferred to Fedora Linux 36.

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

[Anita Zhang]

I suspect that this may have been a swap-based kill and gnome-shell was using 
the most swap at the time. If you do `journalctl --unit systemd-oomd` do you 
see "systemd-oomd[]: Killed  due to "
___
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: Peter Savage

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 27 July 2021 at 15:31, Pete Savage wrote:
> 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!

Welcome to Fedora!
It's nice to see an Ubuntu maintainer in Fedora, too.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Gary Buhrmaster]

On Wed, Jul 28, 2021 at 5:28 PM Vitaly Zaitsev via devel
 wrote:
>
> On 28/07/2021 15:07, Ben Cotton wrote:
> > Updates of user services take effect immediately (if so configured in
> > the providing packages).
>
> Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will
> cause a DE crash with termination of all running desktop applications
> (including terminal with DNF).

As I understand it, this is a opt-in proposal,
and if a package does not choose to opt-in,
nothing changes (for them).

And I would certainly expect that those
plasma services will choose not to opt-in
by add a _with_restart to their scriptlets.
___
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: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 28/07/2021 15:07, Ben Cotton wrote:

Updates of user services take effect immediately (if so configured in
the providing packages).


Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will 
cause a DE crash with termination of all running desktop applications 
(including terminal with DNF).


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

Heads-up: grpc 1.39.0 coming to Rawhide with C and C++ so-version bumps

[Ben Beasley]

In one week (2021-08-03), I will merge 
https://src.fedoraproject.org/rpms/grpc/pull-request/5 (which will build 
on all architectures by then) and build it into a side tag. This will 
bring grpc 1.39.0 to Rawhide, bumping the C so-version to 18 and the C++ 
so-version to 1.39, prior to F35 branching.


Maintainers of the following packages, which depend on the C and/or C++ 
libraries, should expect to receive a PR to rebuild into the side tag at 
that time. These maintainers should have received this email directly.


  - bear (admins: defolos)
  - frr (admins: mruprich)
  - perl-grpc-xs (admins: ppisar, @perl-maint-sig)

If you are a maintainer of one of the above packages, expect rebuilds 
for grpc updates in Rawhide (and perhaps sometimes branched) to happen 
at least one or two times per Fedora release cycle in the future, since 
upstream always bumps the C++ so-version and often bumps the C 
so-version on minor releases. I’m not a provenpackager, so if you think 
you will frequently be unable to respond to these rebuild PRs within a 
few days, please consider giving me (FAS: music) enough permissions on 
your package to do these routine rebuilds myself, rather than having to 
ask for provenpackager help and/or keep the side tag open for a long time.


The following packages use one of the Python APIs provided by grpc, or 
require the “grpc” extra of an intermediate Python dependency. These 
will not require rebuilding. I have confirmed I can build each 
successfully into 
https://copr.fedorainfracloud.org/coprs/music/grpc-1.39/, and grpc 
Python bindings are historically mostly forward-compatible, so it is 
likely that no action should be required by these packages’ maintainers. 
Still, they should have also received this email directly.


  - buildstream
  - python-chirpstack-api
  - python-etcd3
  - python-google-api-core
  - python-google-cloud-iam
  - python-googleapis-common-protos
  - python-opencensus
  - python-opencensus-proto
  - python-proto-plus
  - python-xds-protos

The following package does not rebuild successfully, but it is orphaned 
and the problems appear unrelated to grpc:


  - python-opentelemetry
___
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: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Miroslav Suchý]

Dne 28. 07. 21 v 15:07 Ben Cotton napsal(a):

Note from the change owner: I'm submitting this as very-very-late
change for F35. The implementation in systemd is mostly done, so it'll
become available in rawhide pretty soon. To actually make use of the
new functionality, individual packages should be changed to use
_with_restart in their scriptlets and rebuilt. This will happen over
time, and it's fine if each package does that on its own schedule. We
still do not have that many user services, and restarting from
packaging scriptlets will be possible and appropriate only for some of
them. I think it's important to make the functionality available,
without trying to use it everywhere immediately.


What will happen with services defined by user in |$HOME/.config/systemd/user ?
|

|Miroslav
|

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

Fedora-Rawhide-20210728.n.3 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 43 required test results missing
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: 7/138 (aarch64), 3/201 (x86_64)

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

ID: 936743  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/936743
ID: 936748  Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/936748
ID: 936817  Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/936817
ID: 936831  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/936831
ID: 936879  Test: x86_64 universal memtest
URL: https://openqa.fedoraproject.org/tests/936879
ID: 936903  Test: aarch64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/936903
ID: 936923  Test: aarch64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/936923

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

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

Soft failed openQA tests: 20/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-20210727.n.0):

ID: 936933  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/936933
ID: 936941  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/936941

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

ID: 936605  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/936605
ID: 936606  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936606
ID: 936661  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936661
ID: 936662  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/936662
ID: 936720  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/936720
ID: 936729  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936729
ID: 936738  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936738
ID: 936786  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936786
ID: 936795  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936795
ID: 936815  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/936815
ID: 936818  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/936818
ID: 936822  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/936822
ID: 936823  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/936823
ID: 936826  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/936826
ID: 936829  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/936829
ID: 936835  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/936835
ID: 936841  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/936841
ID: 936842  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/936842
ID: 936843  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/936843
ID: 936844  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/936844
ID: 936867  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/936867
ID: 936872  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/936872
ID: 936878  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/936878
ID: 936882  Test: x86_64 universal upgrade_realm

Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Miroslav Suchý]

Dne 28. 07. 21 v 15:07 Ben Cotton napsal(a):
== Benefit to Fedora ==

This fixes a long-standing missing feature. We certainly wanted to
have this, but the technical implementation is not trivial, because we
need to (safely and robustly) reach from the a privileged context into
unprivileged user manager instances. Such functionality has been added
in systemd, so finally we are able to do this in a fairly clean
manner.


Only partially true. There is `tracer` with dnf plugin. It have been here for few years. Users are suggested which 
services need to be restarted (and are safe to be restarted), if they need to logoff/login or even restart a machine.



User services are becoming more and more important. In particular, we
want to be able to restart services such as `pipewire.service` during
upgrades, without requiring a restart of the machine for the upgrade
to take effect. Systemd only provides the general functionality.
Package maintainers will need to mark their services for restart using
`%systemd_postun_with_restart` if appropriate.


I think that this needs to be expanded.

1) It will be good to expand what is actually an user service. I had to look it 
up. Hint for others:

 systemctl --user status

2) Do you want to restart all user services? Or just these which are marked by maintainers to be safe to be restarted 
(e.g., pipewire)? Because


  systemctl --user restart plasma-ksmserver.service

is not what I want to see to happen in rpm transaction as that immediately kills my session and interrupt the rpm 
transaction.


3) Can we have some discussions which user services are safe to restart and which not? E.g., the Tracer configuration is 
a good start point.




== How To Test ==
Upgrade packages with user services that should be restarted. Look at
logs or otherwise verify that the new version is running.


Can the guidance be more specific here?



== User Experience ==
Updates of user services take effect immediately (if so configured in
the providing packages).


Can this be expanded too? What will be the **practical** impact? Will my audio stops? Or has just little glitch? What 
about my bluetooth connections? Etc.


Miroslav

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

Fedora-IoT-35-20210728.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/15 (aarch64)

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

ID: 936963  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/936963
ID: 936968  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/936968

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

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

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

ID: 936945  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/936945
ID: 936947  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/936947
ID: 936948  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/936948
ID: 936961  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/936961

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

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

ID: 936955  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/936955
ID: 936967  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/936967
ID: 936972  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/936972

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 207 MiB to 186 MiB
System load changed from 0.18 to 0.30
Previous test data: https://openqa.fedoraproject.org/tests/936457#downloads
Current test data: https://openqa.fedoraproject.org/tests/936945#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 216 MiB to 191 MiB
Previous test data: https://openqa.fedoraproject.org/tests/936459#downloads
Current test data: https://openqa.fedoraproject.org/tests/936947#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Used mem changed from 208 MiB to 184 MiB
System load changed from 0.64 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/936473#downloads
Current test data: https://openqa.fedoraproject.org/tests/936961#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: Free Pascal and F35 Mass Rebuild

[Nikolay Nikolov]

On 7/27/21 3:59 PM, Artur Frenszek-Iwicki wrote:

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.


Yeah, it's best to report it upstream. The GitLab transition should be 
ready in a day or two, I hope. Alternatively, you can send mail to the 
[fpc-devel] mailing list.


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

[Test-Announce] Fedora 35 Rawhide 20210728.n.3 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 35 Rawhide 20210728.n.3. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20210724.n.0: anaconda-35.20-1.fc35.src, 20210728.n.3: 
anaconda-35.20-2.fc35.src
python-blivet - 20210724.n.0: python-blivet-3.4.0-4.fc35.src, 20210728.n.3: 
python-blivet-3.4.0-5.fc35.src
pyparted - 20210724.n.0: pyparted-3.11.7-3.fc35.src, 20210728.n.3: 
pyparted-3.11.7-4.fc35.src
parted - 20210724.n.0: parted-3.4-4.fc35.src, 20210728.n.3: 
parted-3.4-5.fc35.src
pykickstart - 20210724.n.0: pykickstart-3.34-1.fc35.src, 20210728.n.3: 
pykickstart-3.34-2.fc35.src
lorax - 20210724.n.0: lorax-35.6-1.fc35.src, 20210728.n.3: lorax-35.6-2.fc35.src
pungi - 20210724.n.0: pungi-4.2.9-2.fc35.src, 20210728.n.3: 
pungi-4.2.9-3.fc35.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/35

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210728.n.3_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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: systemd-oomd blows away the gnome-shell desktop session

[Benjamin Berg]

Hi,

On Wed, 2021-07-28 at 13:33 +1000, David Airlie wrote:
> >  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.

It is mostly going by the rate of "pgscan" in the memory statistics.
So, if you are in a heavy swap situation and the kernel tries to evict
pages from gnome-shell, then it is perfectly viable for it to become
the victim.

The main guard we have against that currently is the assigned
uresourced memory protection (which is only a very partial guard). i.e.
on Fedora Workstation, you should have "uresourced" running, which will
assign a memory allocation of 250MiB to the current user and their
session.slice.

$ cat /sys/fs/cgroup/user.slice/memory.min
262144000
$ cat /sys/fs/cgroup/user.slice/user-1000.slice/memory.min
262144000
$ cat /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/memory.min
262144000
$ cat 
/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/memory.min
262144000

Basically, right now we Hope (TM), that this gives gnome-shell enough
space to keep its working set in memory, so that it continues running
smoothly and systemd-oomd does not consider it as a candidate.
Note that you can configure the size of this memory allocation by
editing /etc/uresourced.conf[1].

For now, we don't have another solution. A better solution requires
reworking the systemd-oomd victim selection algorithm so that users can
steer it away from important processes (i.e. exclude session.slice).

I have some ideas for that, but that is pending on having some
heuristic whether the killing a cgroup is going to improve the
situation.

Benjamin

[1] To apply, you'll need to run
  systemctl restart uresourced.service
and
  systemctl --user daemon-reload


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: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Ben Cotton]

On Wed, Jul 28, 2021 at 9:07 AM Ben Cotton  wrote:
>
> Note from the change owner: I'm submitting this as very-very-late
> change for F35. The implementation in systemd is mostly done, so it'll
> become available in rawhide pretty soon. To actually make use of the
> new functionality, individual packages should be changed to use
> _with_restart in their scriptlets and rebuilt. This will happen over
> time, and it's fine if each package does that on its own schedule. We
> still do not have that many user services, and restarting from
> packaging scriptlets will be possible and appropriate only for some of
> them. I think it's important to make the functionality available,
> without trying to use it everywhere immediately.
>
For what it's worth, I would argue this is actually a self-contained
change since it it doesn't modify any default behavior. This would
make it very late instead of very-very-late.


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

[Registration Open & Schedule Live] Nest with Fedora 2021 - Contributor Conference

[Marie Nordin]

Hi Fedora Friends,

As you may have noticed, Nest with Fedora 2021 is coming up quick. Our
annual contributor conference is next week August 5th-7th, virtual, and we
would love for you to attend!

Make sure to register here:
https://hopin.com/events/nest-with-fedora-2021

Check out the schedule here:
https://fedoraproject.org/wiki/Nest_with_Fedora_2021_Schedule#

Our schedule is packed full of sessions on all things Fedora. The sessions
range from technical, to how to get started on different teams, to a
variety of collaborative panels & more- the Fedora community showed up with
great topics! There is also a *fancy & fedorable* Fedora Museum themed
custom WorkAdventure map in the works that we will be using for our social
sessions.

Of course, there will be a Nest Attendee Fedora Badge to earn.
Additionally, there is a unique swag pack created specially for Nest with
Fedora 2021. The swag pack will include items with the new Fedora logo,
surprise items from our sponsors and a ton of stickers! You will receive
updates about claiming your Nest attendee swag pack via the email you use
to register in Hopin.

Cheers, and I can't wait to see you there!

--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

T: +1.973.800.4967

IRC: riecatnor



___
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 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Ben Cotton]

Note from the change owner: I'm submitting this as very-very-late
change for F35. The implementation in systemd is mostly done, so it'll
become available in rawhide pretty soon. To actually make use of the
new functionality, individual packages should be changed to use
_with_restart in their scriptlets and rebuilt. This will happen over
time, and it's fine if each package does that on its own schedule. We
still do not have that many user services, and restarting from
packaging scriptlets will be possible and appropriate only for some of
them. I think it's important to make the functionality available,
without trying to use it everywhere immediately.

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


== Summary ==
User services (services running under systemd user instances) will be
restarted as part of the rpm upgrade. This mirrors what is done for
system services.

== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek AT in.waw.pl


== Detailed Description ==
We have rpm packaging scriptlets to reexecute systemd and restart
system services as part of the rpm update transaction. But we didn't
have equivalent services for the user manager. With this change,
individual system managers will be reexecuted, and various packages
can mark their user services to be restarted. The restart of services,
similarly to the restart of system services, is done after all
packages have been installed, using a transfiletrigger.


== Benefit to Fedora ==
This fixes a long-standing missing feature. We certainly wanted to
have this, but the technical implementation is not trivial, because we
need to (safely and robustly) reach from the a privileged context into
unprivileged user manager instances. Such functionality has been added
in systemd, so finally we are able to do this in a fairly clean
manner.

User services are becoming more and more important. In particular, we
want to be able to restart services such as `pipewire.service` during
upgrades, without requiring a restart of the machine for the upgrade
to take effect. Systemd only provides the general functionality.
Package maintainers will need to mark their services for restart using
`%systemd_postun_with_restart` if appropriate.

== Scope ==
* Proposal owners:
** implement appropriate functionality
(https://github.com/systemd/systemd/pull/17967,
https://github.com/systemd/systemd/pull/20157,
https://github.com/systemd/systemd/pull/20276,
https://github.com/systemd/systemd/pull/20334)
** make a pull request to adjust the packaging guidelines
(https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets)

* Other developers:
** Switch from `%systemd_user_postun` to
`%systemd_user_postun_with_restart` if appropriate.
** Make sure that their user services behave properly during restart.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change, all the
relevant policies were already in place, but the implementation was
missing)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: no


== Upgrade/compatibility impact ==
This makes upgrades better in general. Various updates can take effect
immediately without requiring a restart. There should be no noticeable
effect on upgrades, barring bugs.

== How To Test ==
Upgrade packages with user services that should be restarted. Look at
logs or otherwise verify that the new version is running.

== User Experience ==
Updates of user services take effect immediately (if so configured in
the providing packages).

== Dependencies ==
None.

== Contingency Plan ==

Status quo is that various services are not restarted. Actually I
don't expect this to be fully implemented at any point in time. If
some service need to not be restarted, e.g. because the restart does
not work, change `%systemd_user_postun_with_restart` to
`%systemd_user_postun` and rebuild the package. If the whole system is
broken, the command that actually does the restart in the systemd
transfiletrigger can be disabled.

* Contingency deadline: any time
* Blocks release? No.


== Documentation ==
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets
(TBD)



-- 
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: How to correctly handle scriptlets for systemd template unit instances

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 27, 2021 at 05:30:24PM +0200, Fabio Valentini wrote:
> 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".

I'll copy my reply from the bug:

This is an omission from my side. The easiest solution (longer-term)
is to allow such globs in systemd. I filed a simple patch to do this
[1]. When it goes through, I'll push it to F34+ where the new
scriptlet is used

[1] https://github.com/systemd/systemd/pull/20334

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

Short reply: 
https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade

I hope I could convince people to do this for F35…
It sounds like it would be very useful for the syncthing case.

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

[Neal Gompa]

On Wed, Jul 28, 2021 at 7:44 AM Stephen Gallagher  wrote:
>
> 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?

With my WG hat on, we've elected to trust Wim on this and we're
generally excited to see how this goes in F35. He had brought up
WirePlumber when we originally did the PipeWire change last cycle and
told us then that he was planning to have it ready for F35. So from
that perspective, we're okay with it.

Taking my WG hat off, I've been testing it for about as long as it's
existed in the repositories in Rawhide and it's been pretty good thus
far. The user experience is no worse than before, as far as I can
tell, and having the programmability and flexibility for applications
to leverage opens the doors for all kinds of interesting use-cases. My
understanding is that it's also a prerequisite for eventually doing
similar stuff for video sources that we're doing with audio sources
today too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Neal Gompa]

On Wed, Jul 28, 2021 at 7:14 AM Chris Murphy  wrote:
>
> 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
>

This is packaged in Fedora already.

"dnf install below" brings you the tool. I'm already using it. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20210728.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-20210727.0):

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

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

Fedora-Cloud-33-20210728.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-20210727.0):

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

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