Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Friday, December 23, 2022 1:34:48 PM EST Alexander Ploumistos wrote: > On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote: > > This is nice, but all I ever seen is a black screen and a spinning > > circle. No text of any kind. If something were written to the console, > > how do you see it? > > Have you tried hitting "Esc" when that happens? No. Why would I? There is no text on that screen that even mentions that is a possible option. If that is possible, advertise it. Or better, kill the graphical shutdown and explain why it's delayed. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c57a51c195 rxvt-unicode-9.30-2.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8362ddfe7c trafficserver-9.1.4-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing libmediainfo-22.12-1.el7 libzen-0.4.40-1.el7 mediainfo-22.12-3.el7 w3m-0.5.3-58.git20220429.el7 Details about builds: libmediainfo-22.12-1.el7 (FEDORA-EPEL-2022-d15fe76e0a) Library for supplies technical and tag information about a video or audio file Update Information: Update to 22.12. ChangeLog: * Fri Dec 23 2022 Vasiliy N. Glazov - 22.12-1 - Update to 22.12 * Sat Oct 29 2022 Vasiliy N. Glazov - 22.09-1 - Update to 22.09 * Sun Sep 25 2022 Rich Mattes - 22.06-3 - Rebuild for tinyxml2-9.0.0 * Thu Jul 21 2022 Fedora Release Engineering - 22.06-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Mon Jun 27 2022 Vasiliy N. Glazov - 22.06-1 - Update to 22.06 libzen-0.4.40-1.el7 (FEDORA-EPEL-2022-d15fe76e0a) Shared library for libmediainfo and medianfo* Update Information: Update to 22.12. ChangeLog: * Fri Dec 23 2022 Vasiliy N. Glazov - 0.4.40-1 - Update to 0.4.40 * Thu Jul 21 2022 Fedora Release Engineering - 0.4.39-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 0.4.39-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 0.4.39-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild mediainfo-22.12-3.el7 (FEDORA-EPEL-2022-d15fe76e0a) Supplies technical and tag information about a video or audio file (CLI) Update Information: Update to 22.12. ChangeLog: * Fri Dec 23 2022 Vasiliy N. Glazov - 22.12-3 - Update to 22.12 - Fix EPEL build * Sat Oct 29 2022 Vasiliy N. Glazov - 22.09-1 - Update to 22.09 * Thu Aug 4 2022 Scott Talbert - 22.06-3 - Rebuild with wxWidgets 3.2 * Thu Jul 21 2022 Fedora Release Engineering - 22.06-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Mon Jun 27 2022 Vasiliy N. Glazov - 22.06-1 - Update to 22.06 w3m-0.5.3-58.git20220429.el7 (FEDORA-EPEL-2022-65548d9891) Pager with Web browsing abilities Update Information: - Added upstream patch to address CVE-2022-38223 (#2126270) ChangeLog: * Fri Dec 23 2022 Robert Scheck - 0.5.3-58.git20220429 - Added upstream patch to address CVE-2022-38223 (#2126270) * Sat Jul 23 2022 Fedora Release Engineering - 0.5.3-57.git20220429 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Mon May 30 2022 Jitka Plesnikova - 0.5.3-56.git20220429 - Perl 5.36 rebuild References: [ 1 ] Bug #2126270 - CVE-2022-38223 w3m: an out-of-bounds write in checkType located in etc.c in w3m https://bugzilla.redhat.com/show_bug.cgi?id=2126270 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [apt-cacher-ng] Resurrect dead package
I've refreshed the packaging and fixed bugs. https://src.fedoraproject.org/fork/adetiste/rpms/apt-cacher-ng : -> this integrate and builds on Frédéric Pierret's fixes. https://copr.fedorainfracloud.org/coprs/adetiste/apt-cacher-ng/build/5178188/ (I need it for RHEL 8, so I'll need to backport c-ares somehow) Greetings ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?
> So you can do > $ eval `rpm -E '%set_build_flags'` > in a script to set the flags that RPM uses. Another solution could be something like: $ gcc $(rpm -E '%optflags') ... $(rpm -E '%build_ldflags') 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?
On Fri, Dec 23, 2022 at 1:21 PM Vít Ondruch wrote:
>
> Working with upstream on one issue [1], it seems that the culprit is in
> the Fedora compiler options. Is there some convenient way to set them
> up? Of course I can copy them from log, or somehow put together from the
> RPM macros, but I'd appreciate if there was some easier way. Can we e.g.
> distribute some script, which would set them up, as part or some RPM?
>
Now that we have the `set_build_flags` macro, it's somewhat
straightforward to do:
$ rpm -E '%set_build_flags'
CFLAGS="${CFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection}" ; export CFLAGS ;
CXXFLAGS="${CXXFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions
-g -grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection}" ; export CXXFLAGS ;
FFLAGS="${FFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
FCFLAGS="${FCFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules}" ; export FCFLAGS ;
LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 }"
; export LDFLAGS ;
LT_SYS_LIBRARY_PATH="${LT_SYS_LIBRARY_PATH:-/usr/lib64:}" ; export
LT_SYS_LIBRARY_PATH ;
CC="${CC:-gcc}" ; export CC ;
CXX="${CXX:-g++}" ; export CXX
So you can do
$ eval `rpm -E '%set_build_flags'`
in a script to set the flags that RPM uses.
>
> Vít
>
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote: > > This is nice, but all I ever seen is a black screen and a spinning circle. No > text of any kind. If something were written to the console, how do you see > it? Have you tried hitting "Esc" when that happens? ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Is there convenient way to setup Fedora compilation flags outside of the RPM build?
Working with upstream on one issue [1], it seems that the culprit is in the Fedora compiler options. Is there some convenient way to set them up? Of course I can copy them from log, or somehow put together from the RPM macros, but I'd appreciate if there was some easier way. Can we e.g. distribute some script, which would set them up, as part or some RPM? Vít [1] https://bugs.ruby-lang.org/issues/19248 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Hello, On Friday, December 23, 2022 9:48:22 AM EST Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Dec 23, 2022 at 08:09:56AM +0100, Tomasz Torcz wrote: > > On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote: > > > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote: > > > > 15 seconds feels very aggressive to me. I can think of some cases, > > > > like libvirtd automatically suspending or cleanly shutting down > > > > running VMs, that might well take longer than that. Could we not go > > > > for 30 seconds? Going all the way from 90/120 down to 15 seems pretty > > > > radical. > > > > > > I run across this with some regularity. PackageKit is not installed on > > > my system. What I wished was that when there is a stall shutting > > > down, a message to the console or a dialog box explains who is holding > > > up shutdown. If we knew who was holding things up, bugs might get > > > filed. > > > > But there already is such message! First "waiting for shutdown" with > > unit name and a timer. Then, in the last phase there's also "wating for > > process:" message. > > Yeah. We added printing of a lot of information in > https://github.com/systemd/systemd/commit/3889fc6fc347f0e12070f7b873d065508 > c8df816: > Example output: This is nice, but all I ever seen is a black screen and a spinning circle. No text of any kind. If something were written to the console, how do you see it? If stalls were detected, maybe the graphical shutdown should be suspended so that you can see the console. -Steve > Stopping user@1000.service... > [ OK ] Stopped dracut-shutdown.service. > [ OK ] Stopped systemd-logind.service. > [ OK ] Stopped systemd-logind.service - User Login Management. > [* ] Job user@1000.service/stop running (2s / 2min): (1 of 2) User job > slowstop.service/stop running (1s / 1min 30s)... > [*** ] Job > user@1000.service/stop running (3s / 2min): (2 of 2) User job > slowstop2.service/stop running (2s / 1min 30s)... [ ***] Job > user@1000.service/stop running (4s / 2min): (1 of 2) User job > slowstop.service/stop running (4s / 1min 30s)... [ *] Job > user@1000.service/stop running (5s / 2min): (1 of 2) User job > slowstop.service/stop running (5s / 1min 30s)... [ ***] Job > user@1000.service/stop running (6s / 2min): (2 of 2) User job > slowstop2.service/stop running (6s / 1min 30s)... [*** ] Job > user@1000.service/stop running (8s / 2min): (1 of 2) User job > slowstop.service/stop running (7s / 1min 30s)... [*** ] Job > user@1000.service/stop running (10s / 2min): (2 of 2) User job > slowstop2.service/stop running (9s / 1min 30s)... [ *** ] Job > user@1000.service/stop running (11s / 2min): (1 of 2) User job > slowstop.service/stop running (10s / 1min 30s)... [ *] Job > user@1000.service/stop running (12s / 2min): (2 of 2) User job > slowstop2.service/stop running (12s / 1min 30s)... [ ***] Job > user@1000.service/stop running (13s / 2min): (1 of 2) User job > slowstop.service/stop running (13s / 1min 30s)... [*** ] Job > user@1000.service/stop running (15s / 2min): (2 of 2) User job > slowstop2.service/stop running (14s / 1min 30s)... [* ] Job > user@1000.service/stop running (15s / 2min): (2 of 2) User job > slowstop2.service/stop running (14s / 1min 30s)... [*** ] Job > user@1000.service/stop running (16s / 2min): User job > slowstop.service/stop running (16s / 1min 30s)... [ ***] Job > user@1000.service/stop running (18s / 2min): User job > slowstop.service/stop running (17s / 1min 30s)... [ *] Job > user@1000.service/stop running (19s / 2min): User job > slowstop.service/stop running (18s / 1min 30s)... [ ***] Job > user@1000.service/stop running (20s / 2min): User job > slowstop.service/stop running (19s / 1min 30s)... [* ] Job > user@1000.service/stop running (22s / 2min): User job > slowstop.service/stop running (22s / 1min 30s)... [**] Job > user@1000.service/stop running (30s / 2min): User job > slowstop.service/stop running (29s / 1min 30s)... [ ***] Job > user@1000.service/stop running (32s / 2min): User job > slowstop.service/stop running (31s / 1min 30s)... [ *] Job > user@1000.service/stop running (33s / 2min): User job > slowstop.service/stop running (32s / 1min 30s)... [ ***] Job > user@1000.service/stop running (34s / 2min): User job > slowstop.service/stop running (33s / 1min 30s)... [**] Job > user@1000.service/stop running (37s / 2min): User job > slowstop.service/stop running (36s / 1min 30s)... [ *** ] Job > user@1000.service/stop running (41s / 2min): User job > slowstop.service/stop running (41s / 1min 30s)... [ OK ] Stopped > user@1000.service - User Manager for UID 1000. > Stopping user-runtime-dir@1000.service - User Runtime Directory > /run/user/1000... > [ OK ] Unmounted run-user-1000.mount - > /run/user/1000. > [ OK ] Stopped user-runtime-dir@1000.service - User Runtime Directory > /run/user/1000. > Futher ideas how to improve things are welcome…
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 23, 2022, at 12:56 AM, Demi Marie Obenour wrote: > Why cache mode unsafe? How big a performance win is it? Huge. In effect fsync is ignored. So if the host dies, write order is not guaranteed and can toast the guest file system. The guest dying shouldn't pose a problem because the write order is eventually honored by the host. There's a variety of complex journal replay behaviors of the various file systems that'll come into play (no pun intended). -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Hello, On Friday, December 23, 2022 6:52:02 AM EST Tom Hughes via devel wrote: > On 23/12/2022 11:45, Naheem Zaffar wrote: > > On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel > > mailto:devel@lists.fedoraproject.org>> > > wrote: > > On 23/12/2022 09:20, Mattia Verga via devel wrote: > > > I know this is way harder, but the right approach would be having > > a way > > > to tell systemd what processes can be killed and what other > > > processes > > > must not be forced off in any case, then display a user friendly > > message > > > which inform the user that the system cannot be forced off ATM > > "because > > > I'm doing this or that". In the worst case, the user can choose > > to pull > > > the plug themselves. > > > > I agree. Terminating the PackageKit service while updates are being > > installed can result in a broken system. > > > > Is there a way to be smarter about all this? > > > > 1. Set default at 15s or something short. > > 2. For services known to require longer (older pinephone modem firmware, > > libvirtd), allow a larger timeout for that specific service only > > 3. For services that should NOT be terminated have a mechanism for them > > to not be cut off > > Despite the title of this change I believe the proposal is only > to change the default timeout and a service would still be able to > set a different timeout in it's service file. I wonder if this proposal should also include verifying that known problem services have an appropriate override? -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
if you have persistent Journaling enabled, you'll find them in your last boot log On Fri, Dec 23, 2022, 08:55 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 23/12/22 15:48, Zbigniew Jędrzejewski-Szmek ha scritto: > > > > Yeah. We added printing of a lot of information in > > > https://github.com/systemd/systemd/commit/3889fc6fc347f0e12070f7b873d065508c8df816 > : > > > > Example output: > > > > Stopping user@1000.service... > > [ OK ] Stopped dracut-shutdown.service. > > [ OK ] Stopped systemd-logind.service. > > [ OK ] Stopped systemd-logind.service - User Login Management. > > [* ] Job user@1000.service/stop running (2s / 2min): (1 of 2) User > job slowstop.service/stop running (1s / 1min 30s)... > > [*** ] Job user@1000.service/stop running (3s / 2min): (2 of 2) User > job slowstop2.service/stop running (2s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (4s / 2min): (1 of 2) User > job slowstop.service/stop running (4s / 1min 30s)... > > [ *] Job user@1000.service/stop running (5s / 2min): (1 of 2) User > job slowstop.service/stop running (5s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (6s / 2min): (2 of 2) User > job slowstop2.service/stop running (6s / 1min 30s)... > > [*** ] Job user@1000.service/stop running (8s / 2min): (1 of 2) User > job slowstop.service/stop running (7s / 1min 30s)... > > [*** ] Job user@1000.service/stop running (10s / 2min): (2 of 2) User > job slowstop2.service/stop running (9s / 1min 30s)... > > [ *** ] Job user@1000.service/stop running (11s / 2min): (1 of 2) User > job slowstop.service/stop running (10s / 1min 30s)... > > [ *] Job user@1000.service/stop running (12s / 2min): (2 of 2) User > job slowstop2.service/stop running (12s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (13s / 2min): (1 of 2) User > job slowstop.service/stop running (13s / 1min 30s)... > > [*** ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User > job slowstop2.service/stop running (14s / 1min 30s)... > > [* ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User > job slowstop2.service/stop running (14s / 1min 30s)... > > [*** ] Job user@1000.service/stop running (16s / 2min): User job > slowstop.service/stop running (16s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (18s / 2min): User job > slowstop.service/stop running (17s / 1min 30s)... > > [ *] Job user@1000.service/stop running (19s / 2min): User job > slowstop.service/stop running (18s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (20s / 2min): User job > slowstop.service/stop running (19s / 1min 30s)... > > [* ] Job user@1000.service/stop running (22s / 2min): User job > slowstop.service/stop running (22s / 1min 30s)... > > [**] Job user@1000.service/stop running (30s / 2min): User job > slowstop.service/stop running (29s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (32s / 2min): User job > slowstop.service/stop running (31s / 1min 30s)... > > [ *] Job user@1000.service/stop running (33s / 2min): User job > slowstop.service/stop running (32s / 1min 30s)... > > [ ***] Job user@1000.service/stop running (34s / 2min): User job > slowstop.service/stop running (33s / 1min 30s)... > > [**] Job user@1000.service/stop running (37s / 2min): User job > slowstop.service/stop running (36s / 1min 30s)... > > [ *** ] Job user@1000.service/stop running (41s / 2min): User job > slowstop.service/stop running (41s / 1min 30s)... > > [ OK ] Stopped user@1000.service - User Manager for UID 1000. > > Stopping user-runtime-dir@1000.service - User Runtime > Directory /run/user/1000... > > [ OK ] Unmounted run-user-1000.mount - /run/user/1000. > > [ OK ] Stopped user-runtime-dir@1000.service - User Runtime Directory > /run/user/1000. > > > > Futher ideas how to improve things are welcome… But I think that right > now we > > report enough to narrow things down to system or user service that is > blocking > > shutdown. > > > > Zbyszek > > Is that output available in any log at the next system startup? I > usually hit the power button and then run away, but I would like to > check if anything went slow when I restart my PC. > > Mattia > > ___ > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Il 23/12/22 15:48, Zbigniew Jędrzejewski-Szmek ha scritto: > > Yeah. We added printing of a lot of information in > https://github.com/systemd/systemd/commit/3889fc6fc347f0e12070f7b873d065508c8df816: > > Example output: > > Stopping user@1000.service... > [ OK ] Stopped dracut-shutdown.service. > [ OK ] Stopped systemd-logind.service. > [ OK ] Stopped systemd-logind.service - User Login Management. > [* ] Job user@1000.service/stop running (2s / 2min): (1 of 2) User job > slowstop.service/stop running (1s / 1min 30s)... > [*** ] Job user@1000.service/stop running (3s / 2min): (2 of 2) User job > slowstop2.service/stop running (2s / 1min 30s)... > [ ***] Job user@1000.service/stop running (4s / 2min): (1 of 2) User job > slowstop.service/stop running (4s / 1min 30s)... > [ *] Job user@1000.service/stop running (5s / 2min): (1 of 2) User job > slowstop.service/stop running (5s / 1min 30s)... > [ ***] Job user@1000.service/stop running (6s / 2min): (2 of 2) User job > slowstop2.service/stop running (6s / 1min 30s)... > [*** ] Job user@1000.service/stop running (8s / 2min): (1 of 2) User job > slowstop.service/stop running (7s / 1min 30s)... > [*** ] Job user@1000.service/stop running (10s / 2min): (2 of 2) User job > slowstop2.service/stop running (9s / 1min 30s)... > [ *** ] Job user@1000.service/stop running (11s / 2min): (1 of 2) User job > slowstop.service/stop running (10s / 1min 30s)... > [ *] Job user@1000.service/stop running (12s / 2min): (2 of 2) User job > slowstop2.service/stop running (12s / 1min 30s)... > [ ***] Job user@1000.service/stop running (13s / 2min): (1 of 2) User job > slowstop.service/stop running (13s / 1min 30s)... > [*** ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User job > slowstop2.service/stop running (14s / 1min 30s)... > [* ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User job > slowstop2.service/stop running (14s / 1min 30s)... > [*** ] Job user@1000.service/stop running (16s / 2min): User job > slowstop.service/stop running (16s / 1min 30s)... > [ ***] Job user@1000.service/stop running (18s / 2min): User job > slowstop.service/stop running (17s / 1min 30s)... > [ *] Job user@1000.service/stop running (19s / 2min): User job > slowstop.service/stop running (18s / 1min 30s)... > [ ***] Job user@1000.service/stop running (20s / 2min): User job > slowstop.service/stop running (19s / 1min 30s)... > [* ] Job user@1000.service/stop running (22s / 2min): User job > slowstop.service/stop running (22s / 1min 30s)... > [**] Job user@1000.service/stop running (30s / 2min): User job > slowstop.service/stop running (29s / 1min 30s)... > [ ***] Job user@1000.service/stop running (32s / 2min): User job > slowstop.service/stop running (31s / 1min 30s)... > [ *] Job user@1000.service/stop running (33s / 2min): User job > slowstop.service/stop running (32s / 1min 30s)... > [ ***] Job user@1000.service/stop running (34s / 2min): User job > slowstop.service/stop running (33s / 1min 30s)... > [**] Job user@1000.service/stop running (37s / 2min): User job > slowstop.service/stop running (36s / 1min 30s)... > [ *** ] Job user@1000.service/stop running (41s / 2min): User job > slowstop.service/stop running (41s / 1min 30s)... > [ OK ] Stopped user@1000.service - User Manager for UID 1000. > Stopping user-runtime-dir@1000.service - User Runtime Directory > /run/user/1000... > [ OK ] Unmounted run-user-1000.mount - /run/user/1000. > [ OK ] Stopped user-runtime-dir@1000.service - User Runtime Directory > /run/user/1000. > > Futher ideas how to improve things are welcome… But I think that right now we > report enough to narrow things down to system or user service that is blocking > shutdown. > > Zbyszek Is that output available in any log at the next system startup? I usually hit the power button and then run away, but I would like to check if anything went slow when I restart my PC. Mattia ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
HEADS UP: tesseract-5.3.0 landing in rawhide with soname bump
Hi I'll be landing tesseract 5.3.0 in rawhide, building it in the f38-build-side-61405 side tag, along with the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract zathura-pdf-mupdf Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > A downstream configuration change to reduce the systemd unit timeout > from 2 minutes to 15 seconds. > > == Owner == > * Name: catanzaro > * Email: mcatanzaro at redhat dot com > * Name: aday > * Email: aday at redhat dot com > > > == Detailed Description == > Currently, a service that fails to stop at shutdown time can block > shutdown for up to 2 minutes. This is extremely frustrating for our > users - someone goes to shutdown or reboot their system, and then > unexpectedly has to wait for a long time before they can do anything > else. > > The most common service to cause this issue is PackageKit, but there are > others. > > When a service fails to shutdown when it is instructed to do so, it is > not behaving properly, and it is preventing the system from behaving > in an orderly and predictable manner. Desktop APIs exist for cases > when services or apps legitimately need to prevent shutdown, and these > allow the shutdown inhibit to be communicated to admins and users, so > they understand what is happening. When the user decides to shut down > anyway, services must terminate in a timely manner. The Workstation > Working Group feels that 15 seconds is the maximum appropriate time > for both system and user services, and that Fedora should be robust to > buggy and misbehaving services that do not shut down in an appropriate > manner. > > === History === > > The Workstation Working Group has been > [https://pagure.io/fedora-workstation/issue/163 working on this issue > for several years]. Investigations have revealed that it's not > possible to fix every misbehaving service: in some cases the > misbehaviour comes from design flaws that are difficult to resolve. > > An attempt has also been > [https://github.com/systemd/systemd/pull/18386 made to have the unit > timeout changed in upstream systemd]. That attempt did not go > anywhere, despite various efforts to move it along. We are no longer > comfortable waiting for upstream changes to land. > > To our knowledge, there are no issues that will result from forcing > services to stop after 15 seconds on typical systems. However, system > administrators may need to configure a higher timeout if waiting > longer for a particular service, which may be true for database > services, for example. I hope we can finally get this done. I'm sorry for my part in having this stalled for so long without any progress. It never seemed like it's safe to do. And as the discussion so far in this thread shows, there'll be some potential issues in specific setups (databases, VMs, pinephones), so I think that going through the Change process is the right way. At least it'll be visible enough to get feedback and add workarounds where necessary. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 23, 2022 at 08:09:56AM +0100, Tomasz Torcz wrote: > On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote: > > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote: > > > 15 seconds feels very aggressive to me. I can think of some cases, like > > > libvirtd automatically suspending or cleanly shutting down running VMs, > > > that might well take longer than that. Could we not go for 30 seconds? > > > Going all the way from 90/120 down to 15 seems pretty radical. > > > > I run across this with some regularity. PackageKit is not installed on my > > system. What I wished was that when there is a stall shutting down, a > > message > > to the console or a dialog box explains who is holding up shutdown. If we > > knew who was holding things up, bugs might get filed. > > But there already is such message! First "waiting for shutdown" with > unit name and a timer. Then, in the last phase there's also "wating for > process:" > message. Yeah. We added printing of a lot of information in https://github.com/systemd/systemd/commit/3889fc6fc347f0e12070f7b873d065508c8df816: Example output: Stopping user@1000.service... [ OK ] Stopped dracut-shutdown.service. [ OK ] Stopped systemd-logind.service. [ OK ] Stopped systemd-logind.service - User Login Management. [* ] Job user@1000.service/stop running (2s / 2min): (1 of 2) User job slowstop.service/stop running (1s / 1min 30s)... [*** ] Job user@1000.service/stop running (3s / 2min): (2 of 2) User job slowstop2.service/stop running (2s / 1min 30s)... [ ***] Job user@1000.service/stop running (4s / 2min): (1 of 2) User job slowstop.service/stop running (4s / 1min 30s)... [ *] Job user@1000.service/stop running (5s / 2min): (1 of 2) User job slowstop.service/stop running (5s / 1min 30s)... [ ***] Job user@1000.service/stop running (6s / 2min): (2 of 2) User job slowstop2.service/stop running (6s / 1min 30s)... [*** ] Job user@1000.service/stop running (8s / 2min): (1 of 2) User job slowstop.service/stop running (7s / 1min 30s)... [*** ] Job user@1000.service/stop running (10s / 2min): (2 of 2) User job slowstop2.service/stop running (9s / 1min 30s)... [ *** ] Job user@1000.service/stop running (11s / 2min): (1 of 2) User job slowstop.service/stop running (10s / 1min 30s)... [ *] Job user@1000.service/stop running (12s / 2min): (2 of 2) User job slowstop2.service/stop running (12s / 1min 30s)... [ ***] Job user@1000.service/stop running (13s / 2min): (1 of 2) User job slowstop.service/stop running (13s / 1min 30s)... [*** ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User job slowstop2.service/stop running (14s / 1min 30s)... [* ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User job slowstop2.service/stop running (14s / 1min 30s)... [*** ] Job user@1000.service/stop running (16s / 2min): User job slowstop.service/stop running (16s / 1min 30s)... [ ***] Job user@1000.service/stop running (18s / 2min): User job slowstop.service/stop running (17s / 1min 30s)... [ *] Job user@1000.service/stop running (19s / 2min): User job slowstop.service/stop running (18s / 1min 30s)... [ ***] Job user@1000.service/stop running (20s / 2min): User job slowstop.service/stop running (19s / 1min 30s)... [* ] Job user@1000.service/stop running (22s / 2min): User job slowstop.service/stop running (22s / 1min 30s)... [**] Job user@1000.service/stop running (30s / 2min): User job slowstop.service/stop running (29s / 1min 30s)... [ ***] Job user@1000.service/stop running (32s / 2min): User job slowstop.service/stop running (31s / 1min 30s)... [ *] Job user@1000.service/stop running (33s / 2min): User job slowstop.service/stop running (32s / 1min 30s)... [ ***] Job user@1000.service/stop running (34s / 2min): User job slowstop.service/stop running (33s / 1min 30s)... [**] Job user@1000.service/stop running (37s / 2min): User job slowstop.service/stop running (36s / 1min 30s)... [ *** ] Job user@1000.service/stop running (41s / 2min): User job slowstop.service/stop running (41s / 1min 30s)... [ OK ] Stopped user@1000.service - User Manager for UID 1000. Stopping user-runtime-dir@1000.service - User Runtime Directory /run/user/1000... [ OK ] Unmounted run-user-1000.mount - /run/user/1000. [ OK ] Stopped user-runtime-dir@1000.service - User Runtime Directory /run/user/1000. Futher ideas how to improve things are welcome… But I think that right now we report enough to narrow things down to system or user service that is blocking shutdown. 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:
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 10:40:23PM +0100, allan2016--- via devel wrote: > På Thu, 22 Dec 2022 10:29:29 -0800 > Adam Williamson skrev: > > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: > > > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > > > > > > > This document represents a proposed Change. As part of the Changes > > > > process, proposals are publicly announced in order to receive > > > > community feedback. This proposal will only be implemented if > > > > approved by the Fedora Engineering Steering Committee. > > > > > > > > == Summary == > > > > A downstream configuration change to reduce the systemd unit > > > > timeout from 2 minutes to 15 seconds. > > > > > > Great change, please do it! > > > Also, sometimes after reaching the timeout, systemd extends wait by > > > another 2 minutes (or 1m30). I wasn't able to find in the sources or > > > documentation why this happens, but this behaviour should be > > > blocked. Otherwise some services after 15s will get another 15, and > > > then another… > > > > 15 seconds feels very aggressive to me. I can think of some cases, > > like libvirtd automatically suspending or cleanly shutting down > > running VMs, that might well take longer than that. Could we not go > > for 30 seconds? Going all the way from 90/120 down to 15 seems pretty > > radical. > > 15 seconds will for sure kill the modem on the Pinephones for good. > When the shutdown command are sent to the modem, it takes 20-30 seconds > for the modem to shut down completely. Powering off the phone before the > modem has completely shut down is more or less a sure way to kill the > modem for good, as it can destroy the user space data in the modem. > You will get a lot of angry Pinephone users - if introducing this > "feature" in rawhide ! That's good feedback. I believe that in this case it'd be suitable for the pinephone to install an override that extends the timeout. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 11:00, Neal Gompa (ngomp...@gmail.com) wrote: > > OK, so what's left is exactly one issue you had: you tried to enroll 3 > > UEFI certs via mokutil and what exactly happened then? machine > > bricked how precisely? > > The UEFI environment failed to import without reporting failure and > the system failed to boot, showing garbage instead. By "uefi environment" you mean shim? Sounds like something to report to the shim project then. > > link for a bug report? > > Sorry, I can't. That makes it very hard to do anything about this. To fix a situation one needs actionable reports. > No one helped anyway, even back when I could provide more information. > They're even less likely now that I can't provide that information. You do realise that you are are complaining but not giving anyone the chance to do anything about your complaints. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Fr, 23.12.22 08:51, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 22/12/2022 21:29, Chris Murphy wrote: > > This is a rare but real problem. > > I don't think so. Power outage is a very common problem in some countries. > > I still remember how unreliable FAT32 was in the Windows 9x era. You needed > to run a scandisk check after every power failure or pressing the reset > button. And sometimes your documents or other files disappeared. I really > don't want a repeat of this. Nobody is proposing to run the full Linux OS from FAT. I mean, yeah, in /var and /home people usually do complex write patterns, and the files there basically are pinned all the time thus cannot be unmounted during runtime to ensure the file system stays clean most of the time. But this is different for XBOOTLDR: the autofs logic in systemd ensures it remains unmounted almost all of the time, and is only very briefly mounted whenever something actually accesses it. And the write patterns on XBOOTLDR are comparatively simple: drop in whole file, erase whole file, plus single-sector writes for some corner cases. This is *massively* different from the write patterns Windows 9x did on its file systems. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Fr, 23.12.22 09:01, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 22/12/2022 21:18, Chris Murphy wrote: > > XBOOTLDR in practice needs to be FAT. I don't like it. But I like > > it better than choosing batshit as the alternative, and having a > > bunch of signed efifs drivers on the ESP per distro sounds like > > batshit to me. And not in the good way. > > I don't think so. XBOOTLDR on FAT32 should be rejected as a defective by > design due to a FAT32 unreliability. It's not the best file system if you intend to do random access writes all the time. But if you don't do that, restrict your write patterns to a certain reasonably safe subset, and ensure that you keep the file system unmounted most of the time then it should be OK. I mean, UEFI effectively mandates FAT for one partition (i.e. the ESP), you can't avoid it. And at the bare minimum the boot loader is stored in the ESP, and you need to update that as regularly as any other software package, hence it's illusionary that you could avoid regular write patterns onto FAT if you just make XBOOTLDR something non-FAT. > I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode > and vice versa. After enrolling the Ubuntu key via mokutil that should be fine. Sure, if you have the shim belonging to distro X then this means only kernels of distro X can be just booted, since only X' certificate will be built-in. But once you enroll other certs things should be fine. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, 22 Dec 2022 at 10:24, Elizabeth K. Joseph wrote: > > This might not be as niche as you might think. I'm one of the > > Linux kernel maintainers for s390. Many of us do the vast majority of > > their development work natively on s390 systems via SSH from Fedora > > laptops. > > I first wanted to echo and confirm what Niklas says here. > > The crux of this issue seems to be "the code in the X server that does > this is virtually untested" so would more attention being paid to this code > help? I can't make any promises, but it would be valuable to know if this, > or something else, is needed. I will also bring this to the attention of > the Open Mainframe Project Linux Distributions Working Group, since all of > the distros use this byte-swapped code. > The people I learned coding and how to break code in the 80's always looked at byte-swapping in any project for problems. Most of the code was usually cargo culted from other projects or some sci.comp newsgroup. It might work but it would usually then be plastered in with fragile code or you would find that something 3 or 4 layers up broke. Currently there is only one byte-swapped architecture which Fedora runs on. There are about 82 Fedora instances on it and ~900 instances using EPEL. However, I think this request is coming more from the current maintainers of X. They also do not have ready access to byte-swapped systems so have no way to say 'oh this works' or not. I think X and other code fixed to deal with byte-swapping is going to need focus as I expect this change will 'filter' into other operating systems over time. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On 23/12/2022 11:45, Naheem Zaffar wrote: On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel mailto:devel@lists.fedoraproject.org>> wrote: On 23/12/2022 09:20, Mattia Verga via devel wrote: > I know this is way harder, but the right approach would be having a way > to tell systemd what processes can be killed and what other processes > must not be forced off in any case, then display a user friendly message > which inform the user that the system cannot be forced off ATM "because > I'm doing this or that". In the worst case, the user can choose to pull > the plug themselves. I agree. Terminating the PackageKit service while updates are being installed can result in a broken system. Is there a way to be smarter about all this? 1. Set default at 15s or something short. 2. For services known to require longer (older pinephone modem firmware, libvirtd), allow a larger timeout for that specific service only 3. For services that should NOT be terminated have a mechanism for them to not be cut off Despite the title of this change I believe the proposal is only to change the default timeout and a service would still be able to set a different timeout in it's service file. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 23/12/2022 09:20, Mattia Verga via devel wrote: > > I know this is way harder, but the right approach would be having a way > > to tell systemd what processes can be killed and what other processes > > must not be forced off in any case, then display a user friendly message > > which inform the user that the system cannot be forced off ATM "because > > I'm doing this or that". In the worst case, the user can choose to pull > > the plug themselves. > > I agree. Terminating the PackageKit service while updates are being > installed can result in a broken system. > Is there a way to be smarter about all this? 1. Set default at 15s or something short. 2. For services known to require longer (older pinephone modem firmware, libvirtd), allow a larger timeout for that specific service only 3. For services that should NOT be terminated have a mechanism for them to not be cut off -- > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221223.n.0 changes
OLD: Fedora-Rawhide-20221222.n.0 NEW: Fedora-Rawhide-20221223.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 3 Dropped packages:0 Upgraded packages: 71 Downgraded packages: 0 Size of added packages: 30.67 MiB Size of dropped packages:0 B Size of upgraded packages: 2.12 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 39.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20221223.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: libzonedetect-0~gitc65bc88-2.fc38 Summary: Find the timezone for a given latitude and longitude RPMs:libzonedetect libzonedetect-devel mingw32-libzonedetect mingw64-libzonedetect Size:30.41 MiB Package: python-openapi-core-0.16.4-2.fc38 Summary: OpenAPI client-side and server-side support RPMs:python3-openapi-core python3-openapi-core+django python3-openapi-core+flask python3-openapi-core+requests python3-openapi-core+starlette Size:246.94 KiB Package: rust-terminal_size0.1-0.1.17-1.fc38 Summary: Gets the size of your Linux or Windows terminal RPMs:rust-terminal_size0.1+default-devel rust-terminal_size0.1-devel Size:23.18 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: COPASI-4.38.268-2.fc38 Old package: COPASI-4.38.268-1.fc38 Summary: Biochemical network simulator RPMs: COPASI COPASI-data COPASI-doc COPASI-gui python3-COPASI Size: 56.28 MiB Size change: 19.47 KiB Changelog: * Wed Dec 21 2022 Sandro Mani - 4.38.268-2 - Rebuild (qwt) Package: ImageMagick-1:6.9.12.70-1.fc38 Old package: ImageMagick-1:6.9.12.67-2.fc38 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 33.80 MiB Size change: 26.37 KiB Changelog: * Thu Dec 22 2022 S??rgio Basto - 1:6.9.12.70-1 - Update ImageMagick to 6.9.12.70 (#2150658) Package: OpenImageIO-2.4.6.1-1.fc38 Old package: OpenImageIO-2.4.4.2-3.fc38 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 20.80 MiB Size change: 68.34 KiB Changelog: * Thu Dec 22 2022 Richard Shaw - 2.4.6.1-1 - Update to 2.4.6.1. Package: alglib-3.20.0-1.fc38 Old package: alglib-3.19.0-2.fc37 Summary: A numerical analysis and data processing library RPMs: alglib alglib-devel alglib-doc Size: 8.38 MiB Size change: 256.65 KiB Changelog: * Wed Dec 21 2022 Sandro Mani - 3.20.0-1 - Update to 3.20.0 Package: anaconda-38.14-1.fc38 Old package: anaconda-38.12-1.fc38 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-webui anaconda-widgets anaconda-widgets-devel Size: 19.78 MiB Size change: 711 B Changelog: * Thu Dec 22 2022 Packit - 38.13-1 - infra: Don't run scheduled events on forks (vslavik) - infra: Notify about tagged releases in gChat (vslavik) - infra: bump pylint from 2.15.6 to 2.15.8 in /dockerfile (49699333+dependabot[bot]) - update translations * Thu Dec 22 2022 Packit - 38.14-1 - Fix typo in the docs (jkonecny) - docs: corrections and additions to the history (msw) - Ignore SIGINT in D-Bus launcher and x11 too (iasunsea) - update translations Package: apr-util-1.6.1-23.fc38 Old package: apr-util-1.6.1-22.fc37 Summary: Apache Portable Runtime Utility library RPMs: apr-util apr-util-bdb apr-util-devel apr-util-ldap apr-util-mysql apr-util-odbc apr-util-openssl apr-util-pgsql apr-util-sqlite Size: 1.31 MiB Size change: 149 B Changelog: * Thu Dec 22 2022 Florian Weimer - 1.6.1-23 - Port configure script to C99 Package: audit-3.0.9-2.fc38 Old package: audit-3.0.9-1.fc38 Summary: User space tools for kernel auditing RPMs: audispd-plugins audispd-plugins-zos audit audit-libs audit-libs-devel python3-audit Size: 2.79 MiB Size change: -1.42 KiB Changelog: * Thu Dec 22 2022 Steve Grubb 3.0.9-2 - BuildRequires python-setuptools Package: bltk-1.1.0-27.fc38 Old package: bltk-1.1.0-26.fc37 Summary: The BLTK measures notebook battery life under any workload RPMs: bltk Size: 10.34 MiB Size change: -371 B Changelog: * Thu Dec 22 2022 Florian Weimer - 1.1.0-27 - Port to C99 (#2155784) Package: catimg-2.7.0-7.fc38 Old package: catimg-2.7.0-6.fc37 Summary: Print images in a terminal with 256 colors support RPMs: catimg Size: 221.97 KiB Size change: 2 B Changelog: * Thu Dec 22 2022 Florian Weimer - 2.7.0-7 - Improve C99
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote: > Different architectures have different boot loaders. In particular, s390x and > ppc64el are very different. The proposal is to add support for UKIs in grub2, > so > that we will cover UEFI and non-UEFI machines that use grub2. For other > architectures, we can in principle do the same thing… After all, the UKI is > just > a binary with a few sections appended. But it seems to early to think such > details far ahead. As extensively discussed, the support for separate initrds > is > not going anyway and the proposal only targets a small subset of the amd64 > space. Also, doesn't u-boot support those architectures? The latest u-boot UEFI interface seems to work quite well when I tried, including support for secure boot. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> On 22/12/2022 21:29, Chris Murphy wrote: > > I don't think so. Power outage is a very common problem in some countries. > > I still remember how unreliable FAT32 was in the Windows 9x era. You > needed to run a scandisk check after every power failure or pressing the > reset button. And sometimes your documents or other files disappeared. I > really don't want a repeat of this. As mentioned many times already, vfat here is not used to keep files open for continuous editing or things like that, where that experience might be repeated. It's single-block or as-atomic-as-it-can-be single-file swap (and with newer kernels it looks like there's actual atomic rename too). So "files disappearing" due to power outages are extremely unlikely in this particular use case. The worst case scenario is that you end up with both old-and-new UKIs, which means you can still boot (and there's no "valuable" data to be lost here, everything that goes in the ESP can be regenerated on the next boot). On the other hand reimplementing filesystem drivers in the bootloader can result in broken filesystems or worse, security vulnerabilities. This is something that actually happens and keeps happening. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> On 12/22/22 12:00, Luca Boccassi wrote: > > As Neal mentioned earlier, these mechanisms are often broken. Not only > does some firmware wind up bricking the machine when they are used, they > also may not support removing the key used to sign Windows. If the > attacker can boot Windows and measured boot is not in use, they have won. Nah, it's the other way around. Linux is severely behind Windows, and I mean really severely. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora 38 Rawhide 20221223.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 38 Rawhide 20221223.n.0. 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 - 20221217.n.0: anaconda-38.12-1.fc38.src, 20221223.n.0: anaconda-38.14-1.fc38.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/38 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_38_Rawhide_20221223.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221223.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221223.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221223.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221223.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221223.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221223.n.0_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, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/20/22 21:27, Simo Sorce wrote: Finally, unless this proposal harms Fedora I do not see why oppose it. If, as you fear, it won't work ... then it won't and we'll try something else. You do realize that the day that Lenovo started to sell it's hardware with Fedora pre-installed ( as it was convinced to do) , the days of Fedora doing somekind of experiments on it's users base to see what sticks or making decisions like hey people if this does not work let's try something else, were over right? ( atleast for the workstation working group ). JBG ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On 23/12/2022 09:20, Mattia Verga via devel wrote: I know this is way harder, but the right approach would be having a way to tell systemd what processes can be killed and what other processes must not be forced off in any case, then display a user friendly message which inform the user that the system cannot be forced off ATM "because I'm doing this or that". In the worst case, the user can choose to pull the plug themselves. I agree. Terminating the PackageKit service while updates are being installed can result in a broken system. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Il 22/12/22 18:35, Ben Cotton ha scritto: > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > I think this is not the right approach to solve the problem. Basically, we're saying "I don't know what's going on, just pull the plug, I don't care about data corruption", which is going to cause even more problems to workstation users if data corruption happens. I know this is way harder, but the right approach would be having a way to tell systemd what processes can be killed and what other processes must not be forced off in any case, then display a user friendly message which inform the user that the system cannot be forced off ATM "because I'm doing this or that". In the worst case, the user can choose to pull the plug themselves. Mattia ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote: > On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > > > In my case, I have Network Manager config files included in my initrd > > > and bootargs to bring up the network so that I get automatic disk > > > decryption while on my home network, and prompted for a password when > > > I am not at home. I think this a reasonable enough use case it should > > > be considered in the long term plan. There was an effort many years > > > ago that built the initramfs with the kernel, it was abandoned due to > > > not being able to guarantee sources for the binaries in the initramfs, > > > > If a UKI is built in koji, the initrd it embeds must also be built in koji. > > And > > when the initrd is built in koji, it is just taking some binaries from rpms > > and > > repacking them. We ensure that we have an srpm for any official srpm. Thus, > > going > > back from the UKI, you look up the initrd, and the logs for the initrd > > build, > > and get a list of rpms, and then look the appropriate srpms from that, and > > from > > the srpms you get the sources. There's a few more steps, but the > > availability of > > sources is guaranteed using the mechanism existing for normal rpms. > > In the past that was deemed to not be good enough. by legal as it is > too hard for the average user to do. Sorry, but that doesn't make any sense. Quoting Daniel Berrange from the other part of the thread: > This is the same situation we already have in Fedora with > libguestfs, where we're building a disk image inside Koji bundling > various binaries. Or for that matter, not really different from > building cloud disk images, or any other deliverable that bundles > together some binaries from other RPMs and spits out some kind of > image or archive. My understanding is that if any of those other things (including any of our installation media that also contain an kernel and programs in the initrd) are fine, UKIs must be fine too. > > > trying to dig up the details I am having trouble finding it, but legal > > > blocked it there is a reference to it in an old FESCo meeting > > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html. > > > Additionally, we should also consider > > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size > > > implications and why we moved to have kernel-core, kernel-modules, and > > > kernel-modules-extra for cloud and different use cases. > > > > Yes. That's why this proposal explicitly targets a narrow use case which > > doesn't > > need many drivers and will support many different machines with the same > > (relatively small) initrd. > > I think the proposal needs to be explicit in how other use cases and > all architectures will be handled. I think if we do not have a path > for all architectures to be supported we should spend more time > working out how to cover them all. Different architectures have different boot loaders. In particular, s390x and ppc64el are very different. The proposal is to add support for UKIs in grub2, so that we will cover UEFI and non-UEFI machines that use grub2. For other architectures, we can in principle do the same thing… After all, the UKI is just a binary with a few sections appended. But it seems to early to think such details far ahead. As extensively discussed, the support for separate initrds is not going anyway and the proposal only targets a small subset of the amd64 space. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On 22/12/2022 18:35, Ben Cotton wrote: A downstream configuration change to reduce the systemd unit timeout from 2 minutes to 15 seconds. +1 for this change. I've already reduced this timeout both on my desktop and laptop to even 10 seconds. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 22/12/2022 21:18, Chris Murphy wrote: XBOOTLDR in practice needs to be FAT. I don't like it. But I like it better than choosing batshit as the alternative, and having a bunch of signed efifs drivers on the ESP per distro sounds like batshit to me. And not in the good way. I don't think so. XBOOTLDR on FAT32 should be rejected as a defective by design due to a FAT32 unreliability. It's harder to fix this problem if XBOOTLDR is not FAT. efifs drivers need to be Secure Boot signed just like the bootloader. The firmware already trusts its built-in FAT driver, for better or worse, so what is the exact problem with just using that so we don't have to deal with UEFI SB signing efifs drivers, and the much harder job of expecting every distro to include signed efifs drivers *on the ESP* for multiboot to work? Who we are to make decisions for other Linux distributions? Every distribution can use whatever they want. I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode and vice versa. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
