Re: systemd 230 change - KillUserProcesses defaults to yes
On 29 May 2016 5:02 a.m., "Nico Kadel-Garcia" wrote: > > On Sat, May 28, 2016 at 9:41 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, May 27, 2016 at 07:03:23PM -0400, Paul Wouters wrote: > >> On Fri, 27 May 2016, Chris Murphy wrote: > >> > >> >It seems to me systemd should be able to know the difference between > >> >a program that's zombie or unresponsive but isn't doing anything or is > >> >unresponsive but is doing something; and if not then some way for > >> >programs to say "hey wait just a minute, I need to clean things up" or > >> >whatever, rather than just abruptly killing them. > >> > >> That invention is otherwise known as "unix signals". > >> > >> systemd should not be the process police. If there is a systematic > >> problem of badly written code leaving orphaned code running when > >> a user logs out, then that broken code should be fixed instead of > >> adding another layer of process management. systemd is not capable > >> of interpreting the user's intent. > > > > systemd *is* process police. That's the job of init. > > daemon poloce != process policie, especially user processes which have > nothing whatsoever to do with system daemons. If it's gong manage user > personal environments, it should be a separate set of tools called > "userd". > Now whilst a support a reversion of the behaviour in Rawhide right now whilst a FESCO F25 change ticket goes through let's not be silly... and at any rate this is technically logind managing this aspect ;) > > The sentiment of fixing processes which cause a problem is nice, > > but it's a game of whack-a-mole that you cannot win. For example in > > https://bugs.freedesktop.org/show_bug.cgi?id=94508#c10 > > it's hp-systray and some ibus related processes. Another time it'll be > > some other random process that is hung or misimplemented or confused. > > Once you have at least one process staying around, the login session > > remains in "closing" state. As long as the session stays around, the > > user's user@.service stays around, and this means many more processes > > staying around. It's a problem on a single-user system because when > > the user logs in again the state is not clean and processes from the > > old session are still holding files and resources. On a multi-user > > system it's also a problem, for the same reasons, and also because by > > default you don't want users consuming resources after they have > > logged out. > > It can be a problem. Enable this kind of aggressive userland > manipulation by *request*, instead of by default, and you're far less > likely to break longstanding procedures such as the ssh-agent > configurations I just mentioned, and the user-activation of other > credentials such as Java keystore. > Well that's what the Change process and Release Notes are about so when the way to handle something changes (and as mentioned there are ways of initiating a separate scope for these to be in their own session) admins and users are able adapt their configurations during a release upgrade. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 23 Rescue Grub Entry Remains after Upgrading to Fedora 24
Hello Everyone, Yesterday, I upgraded my fully updated Fedora 23 Workstation installation to Fedora 24 using dnf system upgrade plugin without any issues. However, I noticed that though Fedora 24 kernel (currently 4.5.5-300.fc24.x86_64) is installed and present at the top of the list in grub entries, the rescue entry for the system is not updated to use the current Fedora 24 kernel. It is still based on the last Fedora 23 kernel with fc23 in its name. Is it the way it should be or is it something that should have been taken care of by the upgrade process? If that is the case, I think I should open a bug in Bugzilla. I tried running dracut -fv and after that grub2-mkconfig -o /boot/grub2/grub.cfg, it updated the text of the rescue entry to read Fedora 24 Workstation, but still after booting, uname -a shows fc23 kernel. Anybody got any idea about how can I regenerate it? Thanks. Regards, Sumit Bhardwaj On Sunday 29 May 2016 10:38 AM, devel-requ...@lists.fedoraproject.org wrote: Send devel mailing list submissions to devel@lists.fedoraproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org or, via email, send a message with subject or body 'help' to devel-requ...@lists.fedoraproject.org You can reach the person managing the list at devel-ow...@lists.fedoraproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of devel digest..." Today's Topics: 1. Re: Packages to be Retired because of Broken Dependencies (2016-05-27) (Sérgio Basto) 2. Re: Packages to be Retired because of Broken Dependencies (2016-05-27) (Sérgio Basto) 3. Re: DNF Issue, packages being incorrectly removed - was: Re: corebird (Gerald B. Cox) 4. Re: DNF Issue, packages being incorrectly removed - was: Re: corebird (Gerald B. Cox) 5. Re: systemd 230 change - KillUserProcesses defaults to yes (Nico Kadel-Garcia) 6. Re: New PyPI link format for Python packages (Ken Dreyer) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Review swap requested
Hello team, I am willing to do a review in exchange of the following packages: gimp-layer-via-copy https://bugzilla.redhat.com/show_bug.cgi?id=1329923 radeontop: https://bugzilla.redhat.com/show_bug.cgi?id=1089962 Thanks in advance, -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap requested
hi take! for swap see comment in your review requests regards .g Il 29/05/2016 10:52, Luya Tshimbalanga ha scritto: Hello team, I am willing to do a review in exchange of the following packages: gimp-layer-via-copy https://bugzilla.redhat.com/show_bug.cgi?id=1329923 radeontop: https://bugzilla.redhat.com/show_bug.cgi?id=1089962 Thanks in advance, -- Luya Tshimbalanga Graphic & Web Designer E:l...@fedoraproject.org W:http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20160529.n.0 changes
OLD: Fedora-Rawhide-20160528.n.0 NEW: Fedora-Rawhide-20160529.n.0 = SUMMARY = Added images:2 Dropped images: 2 Added packages: 0 Dropped packages:0 Upgraded packages: 24 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 1.70 GiB Size of downgraded packages: 0.00 B Size change of upgraded packages: 3.86 MiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20160529.n.0.iso Image: SoaS live i386 Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20160529.n.0.iso = DROPPED IMAGES = Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20160528.n.0.iso Image: Xfce live i386 Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20160528.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: PackageKit-1.1.1-2.fc25 Old package: PackageKit-1.1.1-1.fc25 Summary: Package management service RPMs: PackageKit PackageKit-command-not-found PackageKit-cron PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin PackageKit-gtk3-module Size: 3672606 bytes Size change: -4568 bytes Changelog: * Sat May 28 2016 Kalev Lember - 1.1.1-2 - Require admin authorisation to trigger a distro upgrade (#1335458) Package: ascii-design-1.1.1-1.fc25 Old package: ascii-design-1.1.0-4.fc23 Summary: A tool to create ascii arts RPMs: ascii-design Size: 231814 bytes Size change: -5590 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 1.1.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Sat May 28 2016 Fabio Alessandro Locati - 1.1.1-1 - Update to 1.1.1 Package: atomic-1.10-2.git1d6aecf.fc25 Old package: atomic-1.9-1.git72cdbef.fc25 Summary: Tool for managing ProjectAtomic systems and containers RPMs: atomic Size: 3301862 bytes Size change: 1436908 bytes Changelog: * Sat May 28 2016 Antonio Murdaca - 1.10-2.git1d6aecf - build atomic 1.10 commit 1d6aecf - update skopeo to 0.1.12 Package: awscli-1.10.34-1.fc25 Old package: awscli-1.10.7-1.fc24 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 866782 bytes Size change: 30044 bytes Changelog: * Sat May 28 2016 Fabio Alessandro Locati - 1.10.34-1 - Update to current upstream version Package: edgar-1.24-1.fc25 Old package: edgar-1.23-1.fc24 Summary: A platform game RPMs: edgar Size: 383611634 bytes Size change: 161328 bytes Changelog: * Tue May 24 2016 Andrea Musuruane - 1.24-1 - Updated to upstream 1.24-1 Package: gammu-1.37.3-1.fc25 Old package: gammu-1.37.2-1.fc25 Summary: Command Line utility to work with mobile phones RPMs: gammu gammu-devel gammu-libs Size: 4485854 bytes Size change: 1320 bytes Changelog: * Sun May 29 2016 S??rgio Basto - 1.37.3-1 - Update gammu to 1.37.3 Package: gd-2.2.1-2.fc25 Old package: gd-2.2.1-1.fc25 Summary: A graphics library for quick creation of PNG or JPEG images RPMs: gd gd-devel gd-progs Size: 691294 bytes Size change: 692 bytes Changelog: * Sat May 28 2016 Remi Collet - 2.2.1-2 - remove unneeded sources Package: libhif-0.2.2-4.fc25 Old package: libhif-0.2.2-3.fc25 Summary: Simple package library built on top of hawkey and librepo RPMs: libhif libhif-devel Size: 353004 bytes Size change: 2340 bytes Changelog: * Sat May 28 2016 Kalev Lember - 0.2.2-4 - Check for available disk space before downloading packages (#1336400) Package: libreoffice-1:5.2.0.0-7.beta1.fc25 Old package: libreoffice-1:5.2.0.0-5.alpha1.fc25 Summary: Free Software Productivity Suite RPMs: autocorr-af autocorr-bg autocorr-ca autocorr-cs autocorr-da autocorr-de autocorr-en autocorr-es autocorr-fa autocorr-fi autocorr-fr autocorr-ga autocorr-hr autocorr-hu autocorr-is autocorr-it autocorr-ja autocorr-ko autocorr-lb autocorr-lt autocorr-mn autocorr-nl autocorr-pl autocorr-pt autocorr-ro autocorr-ru autocorr-sk autocorr-sl autocorr-sr autocorr-sv autocorr-tr autocorr-vi autocorr-zh libreoffice libreoffice-base libreoffice-bsh libreoffice-calc libreoffice-core libreoffice-data libreoffice-draw libreoffice-emailmerge libreoffice-filters libreoffice-gdb-debug-support libreoffice-glade libreoffice-graphicfilter libreoffice-gtk2 libreoffice-gtk3 libreoffice-impress libreoffice-kde4 libreoffice-langpack-af libreoffice-langpack-ar libreoffice-langpack-as libreoffice-langpack-bg libreoffice-langpack-bn libreoffice-langpack-br libreoffice-langpack-ca libreoffice-langpack-cs libreoffice-langpack-cy libreoffice-langpack-da libreoffice-langpack-de libreoffice-langpack-dz libreoffice-langpack-el libreoffice-langpack-en libreoffice
Fedora Rawhide-20160529.n.0 compose check report
Missing expected images: Kde live i386 Kde live x86_64 Cloud_base raw-xz i386 Atomic raw-xz x86_64 Kde raw-xz armhfp Minimal raw-xz armhfp Failed openQA tests: 44/67 (x86_64), 10/16 (i386) ID: 19464 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19464 ID: 19465 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/19465 ID: 19466 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19466 ID: 19467 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/19467 ID: 19468 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/19468 ID: 19473 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19473 ID: 19474 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/19474 ID: 19475 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/19475 ID: 19476 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19476 ID: 19477 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19477 ID: 19478 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19478 ID: 19479 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/19479 ID: 19481 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/19481 ID: 19485 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/19485 ID: 19487 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/19487 ID: 19489 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/19489 ID: 19490 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/19490 ID: 19491 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/19491 ID: 19492 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/19492 ID: 19493 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/19493 ID: 19494 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/19494 ID: 19498 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/19498 ID: 19500 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/19500 ID: 19501 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/19501 ID: 19502 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/19502 ID: 19504 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/19504 ID: 19505 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/19505 ID: 19510 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/19510 ID: 19511 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/19511 ID: 19512 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/19512 ID: 19515 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/19515 ID: 19516 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/19516 ID: 19517 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/19517 ID: 19518 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/19518 ID: 19519 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/19519 ID: 19520 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/19520 ID: 19521 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/19521 ID: 19522 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/19522 ID: 19523 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/19523 ID: 19524 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/19524 ID: 19525 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/19525 ID: 19526 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/19526 ID: 19527 Test: x86_64 universal upgrade_
Fedora 24 compose report: 20160529.n.0 changes
OLD: Fedora-24-20160528.n.0 NEW: Fedora-24-20160529.n.0 = SUMMARY = Added images:4 Dropped images: 2 Added packages: 0 Dropped packages:0 Upgraded packages: 18 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 61.61 MiB Size of downgraded packages: 0.00 B Size change of upgraded packages: 1.47 MiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-24-20160529.n.0.iso Image: LXDE live i386 Path: Spins/i386/iso/Fedora-LXDE-Live-i386-24-20160529.n.0.iso Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-24-20160529.n.0.iso Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-24-20160529.n.0.iso = DROPPED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-24-20160528.n.0.iso Image: SoaS live i386 Path: Spins/i386/iso/Fedora-SoaS-Live-i386-24-20160528.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ccsm-1:0.8.12.4-1.fc24 Old package: ccsm-1:0.8.12.3.0-2.fc24 Summary: Plugin and configuration tool - Compiz Fusion Project RPMs: ccsm Size: 800394 bytes Size change: 16 bytes Changelog: * Fri May 27 2016 Wolfgang Ulbrich - 1:0.8.12.4-1 - update to 0.8.12.4 release Package: cinnamon-3.0.4-1.fc24 Old package: cinnamon-3.0.2-2.fc24 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 8697032 bytes Size change: 105052 bytes Changelog: * Sun May 22 2016 Leigh Scott - 3.0.3-1 - update to 3.0.3 release * Tue May 24 2016 Leigh Scott - 3.0.4-1 - update to 3.0.4 release Package: cinnamon-desktop-3.0.2-1.fc24 Old package: cinnamon-desktop-3.0.1-2.fc24 Summary: Shared code among cinnamon-session, nemo, etc RPMs: cinnamon-desktop cinnamon-desktop-devel Size: 919204 bytes Size change: 444 bytes Changelog: * Sat May 21 2016 Leigh Scott - 3.0.2-1 - update to 3.0.2 release Package: cinnamon-menus-3.0.1-1.fc24 Old package: cinnamon-menus-3.0.0-1.fc24 Summary: A menu system for the Cinnamon project RPMs: cinnamon-menus cinnamon-menus-devel Size: 242472 bytes Size change: 1412 bytes Changelog: * Tue May 24 2016 Leigh Scott - 3.0.1-1 - update to 3.0.1 release Package: cinnamon-session-3.0.1-1.fc24 Old package: cinnamon-session-3.0.0-3.fc24 Summary: Cinnamon session manager RPMs: cinnamon-session Size: 833882 bytes Size change: 312 bytes Changelog: * Sat May 21 2016 Leigh Scott - 3.0.1-1 - update to 3.0.1 release Package: cinnamon-translations-3.0.2-1.fc24 Old package: cinnamon-translations-3.0.0-1.fc24 Summary: Translations for Cinnamon and Nemo RPMs: cinnamon-translations Size: 2860570 bytes Size change: 74492 bytes Changelog: * Tue May 24 2016 Leigh Scott - 3.0.1-1 - update to 3.0.1 release * Tue May 24 2016 Leigh Scott - 3.0.2-1 - update to 3.0.2 release Package: emerald-themes-1:0.8.12.1-1.fc24 Old package: emerald-themes-1:0.8.12-1.fc24 Summary: Themes for Emerald, a window decorator for Compiz Fusion RPMs: emerald-themes Size: 3113794 bytes Size change: 1851500 bytes Changelog: * Fri May 27 2016 Wolfgang Ulbrich - 1:0.8.12.1-1 - update to 0.8.12.1 release Package: engrampa-1.14.1-2.fc24 Old package: engrampa-1.14.1-1.fc24 Summary: MATE Desktop file archiver RPMs: engrampa Size: 3769098 bytes Size change: 104 bytes Changelog: * Thu May 26 2016 Wolfgang Ulbrich - 1.14.1-2 - switch to gtk3 for f24 - https://github.com/mate-desktop/engrampa/commit/6a3dba Package: gd-2.2.1-1.fc24 Old package: gd-2.1.1-7.fc24 Summary: A graphics library for quick creation of PNG or JPEG images RPMs: gd gd-devel gd-progs Size: 700662 bytes Size change: -25000 bytes Changelog: * Fri May 27 2016 Marek Skalicky - 2.2.1-1 - Upgrade to 2.2.1 release - Upstream moved to github.com Package: libXfixes-5.0.2-2.fc24 Old package: libXfixes-5.0.1-6.fc24 Summary: X Fixes library RPMs: libXfixes libXfixes-devel Size: 123424 bytes Size change: 912 bytes Changelog: * Fri May 27 2016 Benjamin Tissoires 5.0.2-1 - libXfixes 5.0.2 * Fri May 27 2016 Benjamin Tissoires 5.0.2-2 - require libX11 1.6 Package: libimobiledevice-1.2.0-7.fc24 Old package: libimobiledevice-1.2.0-6.fc24 Summary: Library for connecting to mobile devices RPMs: libimobiledevice libimobiledevice-devel libimobiledevice-utils Size: 1088602 bytes Size change: 840 bytes Changelog: * Fri May 27 2016 Peter Robinson 1.2.0-7 - Fix CVE-2016-5104 Package: libusbmuxd-1.0.10-5.fc24 Old package: libusbmuxd-1.0.10-4.fc24 Summary
Fedora 24-20160529.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Cloud_base raw-xz i386 Minimal raw-xz armhfp Failed openQA tests: 3/73 (x86_64), 4/17 (i386) ID: 19567 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/19567 ID: 19603 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/19603 ID: 19621 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/19621 ID: 19623 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/19623 ID: 19634 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/19634 ID: 19635 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/19635 ID: 19636 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/19636 Passed openQA tests: 70/73 (x86_64), 13/17 (i386) -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2016-05-30 Fedora QA Meeting
Hi folks! I'm proposing we cancel tomorrow's QA meeting. We're into Final validation mode now, and I don't think there are any urgent topics to discuss. If anyone has anything that we should meet about, please do reply to this email and we can go ahead and schedule the meeting. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] 2016-05-30 @ 16:00 UTC - Fedora 24 Blocker Review
# F24 Blocker Review meeting # Date: 2016-05-30 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 4 proposed Final blockers to review. There are also 5 accepted blockers to check in on, and 5 proposed freeze exception issues to review since the freeze will kick in on Tuesday. If you have time tonight, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember to check each outstanding milestone (Beta and Final). We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F24 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good evening and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Fri, 27.05.16 19:03, Paul Wouters (p...@nohats.ca) wrote: > On Fri, 27 May 2016, Chris Murphy wrote: > > >It seems to me systemd should be able to know the difference between > >a program that's zombie or unresponsive but isn't doing anything or is > >unresponsive but is doing something; and if not then some way for > >programs to say "hey wait just a minute, I need to clean things up" or > >whatever, rather than just abruptly killing them. > > That invention is otherwise known as "unix signals". > > systemd should not be the process police. If there is a systematic > problem of badly written code leaving orphaned code running when > a user logs out, then that broken code should be fixed instead of > adding another layer of process management. systemd is not capable > of interpreting the user's intent. Sorry, but systemd is pretty exactly this: a process babysitter. In fact, before it was named "system" it actually was called "BabyKit", in reference to its job of babysitting processes. It's job is to run processes in clean and well-defined execution environments, and to ensure these execution environments are cleaned up properly afterwards. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
yumex-dnf
24 yumex in Fedora has been removed place it in yumex-dnf . I have a question where Russian language . -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yumex-dnf
here I do not speak English I now to guess where to click or to sit with a dictionary -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
jwm
Hi . Started to update one of the computers on which stands jwm and surprise he's not in the fedora repository 24 . -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
It was orphaned in late February. https://admin.fedoraproject.org/pkgdb/package/rpms/jwm/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
your I should follow packet . I just want to enjoy and not to think what else is there to remove in the new issue -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
Il 29/05/2016 19:18, mastaiza ha scritto: Hi . Started to update one of the computers on which stands jwm and surprise he's not in the fedora repository 24 . Hi, It was retired 2016/05/19, because it was orphaned for more than six weeks. Regards .g -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
it is necessary in advance to warn about the deletion . or do I have to guess about this myself -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
No capslock indication on LVM boot password entry
I use a LUKS-LVM setup to encrypt my whole drive. Something within `/boot` then asks me to enter the password and boots after that. On some occasions, especially with the laptop keyboard, I accidentally hit the capslock key. After that all password attempts are wrong, of course. The problem is that the capslock indicator light on my keyboard does not light up. Also the screen content has no indicator for that. I would really like for either feedback to work. It has cost me a couple of hard resets after `systemd` got into a state where it failed to mount `/` since I exhausted the number of trials for the password entry. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
I'm guessing you are subscribed to this mailing list. Every now and then you get messages with subject lines like "Orphaned packages in rawhide". You could have seen it quite some time ago. http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/219062 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: No capslock indication on LVM boot password entry
On Sun, May 29, 2016 at 11:44 AM, Martin Ueding wrote: > I use a LUKS-LVM setup to encrypt my whole drive. Something within > `/boot` then asks me to enter the password and boots after that. > > On some occasions, especially with the laptop keyboard, I accidentally > hit the capslock key. After that all password attempts are wrong, of > course. The problem is that the capslock indicator light on my keyboard > does not light up. Also the screen content has no indicator for that. > > I would really like for either feedback to work. It has cost me a couple > of hard resets after `systemd` got into a state where it failed to mount > `/` since I exhausted the number of trials for the password entry. I think it's plymouth that presents the UI for entering in the passphrase. Maybe search for an RFE for this, and file one if it doesn't already exist. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
So, my 2 cents... Some questions for upstream: * I assume killed processes are logged in the journal, but Is there any way to have a 'permissive' version? ie, simply log what would have been killed, but not do anything? That would be very helpful to folks to identify things that would be affected here without disrupting them at first. It would also allow bugs in other packages to get fixed up. * Does 'loginctl enable-linger ' take effect in the current session? Or do you have to start a new one? does it persist over sessions or only affects the current/next one? * How can I tell if linger is enabled or disabled on a user? * enable-linger/disable-linger need root? So, the only way the user can exclude things is to use systemd-run? For the Fedora side: I agree that it should be a F25 change so things can be coordinated and so it has higher visibility for users. This would also allow time/a chance for working groups to decide if they want to have a per edition default that's different from the base one. If something like a 'permissive' mode is possible, I would think it would be nice to move rawhide to that for now, if not, I don't feel too strongly either way on leaving it enabled for now. (On one hand disruption for users, on the other hand rawhide users should all be subscribed to this list and can change the default if they wish). If we can handle the common cases, I think this is a lovely step forward. kevin pgpL9mvxob3CS.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Sun, May 29, 2016 at 11:53 AM, Kevin Fenzi wrote: > > * Does 'loginctl enable-linger ' take effect in the current > session? Or do you have to start a new one? does it persist over > sessions or only affects the current/next one? > Also, what exactly does linger do? Does it turn off the kill thing entirely? Does it allow services to survive but not scopes? Or do services survive even without linger? The docs are IMO very unclear here. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
but what about the people who used this window Manager . I think its not respectful to the users -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
On 29 May 2016 21:02, "mastaiza" wrote: > > > but what about the people who used this window Manager . I think its not respectful to the users > -- All packagers in Fedora ultimately are volunteers and we don't get too tell people they have maintain any given package. Your options are find an existing packager willing to maintain this, follow the process to become a packager yourself and maintain this, do builds yourself in COPR or for your personal use. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
and I think that at least half of the works on redhat faster to find a new distro -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: jwm
On 29 May 2016 at 17:05, mastaiza wrote: > and I think that at least half of the works on redhat > Just because someone is paid by Red Hat does not mean they are paid to work on Fedora. They usually have a 60 hour a week job doing some other thing on some other product. Only around 20 people are paid to work on Fedora directly. Everyone else is volunteering when they have time with the energy they have. Red Hat also sees no direct revenue from Fedora so this is mainly Research and Development work. > faster to find a new distro That is always an option. Ubuntu may be more aimed at the type of usecase you are looking for. SuSE may be a better community fit. Arch may be the OS which moves at the speed you want. That is the beauty of many distributions... if you are not happy, it is very easy to find the distribution which meets your needs better. So please go find the distribution and community that meets your needs better. > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Fri, May 27, 2016 at 5:03 PM, Paul Wouters wrote: > If there is a systematic > problem of badly written code leaving orphaned code running when > a user logs out, then that broken code should be fixed instead of > adding another layer of process management. systemd is not capable > of interpreting the user's intent. That isn't working. Users are constantly running into restart and shutdown delays. Troubleshooting this to find out what process is holding things up is totally non-obvious. Identifying the process is half the problem, and then getting it fixed and released to Fedora can be months, by which time some other process is affected. The latest one I've run into [1] I can't figure out what the culprit is. All processes have a status of S or derivative thereof. Clearly it's something in session-c1.scope since in the end that's what systemd forcibly kills. But it only does that after 90 seconds, which is just untenable. And as you can see, does the user blame gnome-shell because that's where the hang occurs? Or is it gdm because that's what owns the scope that won't quit? Or is it some process within that scope that's the problem, and if so how to find it? Non-obvious. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1337307 -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Sun, May 29, 2016 at 12:53:26PM -0600, Kevin Fenzi wrote: > So, my 2 cents... > > Some questions for upstream: > > * I assume killed processes are logged in the journal, but Is there > any way to have a 'permissive' version? ie, simply log what would > have been killed, but not do anything? That would be very helpful to > folks to identify things that would be affected here without > disrupting them at first. It would also allow bugs in other packages > to get fixed up. No, the killed processes are not logged, even at debug level, afaik. PID1 simply loops over the control cgroup and sends signals. I see how having a 'permissive' option could be useful. > * Does 'loginctl enable-linger ' take effect in the current > session? Or do you have to start a new one? does it persist over > sessions or only affects the current/next one? Lingering applies to the systemd --user instance, a.k.a. systemd@.service, not to the session. Lingering means that systemd@.service is present even if you are not logged in. If lingering is disabled, it is started on login, and stopped on logout of that user. Killing processes which are part of the session (session-.scope) doesn't have anything to do directly with lingering. It is controlled by the global KillUserProcesses= setting. The connection between KillUserProcesses= and long-running processes is that if KillUserProcesses=yes is set (the new default), to successfully create a process which survives logout two steps are needed: 1. move it out of the session into a systemd --user unit, 2. make that systemd --user instance persistent, i.e. enable lingering. Setting lingering is done over dbus, takes effect immediately, and is persistent (/var/lib/systemd/linger/ is created). Setting KillUserProcesses can be done by modifying /etc/systemd/logind.conf, and also takes effect immediately, if systemd-logind is reloaded (using SIGHUP). > * How can I tell if linger is enabled or disabled on a user? loginctl user-status or loginctl show-user -p Linger > * enable-linger/disable-linger need root? So, the only way the user can > exclude things is to use systemd-run? It is controlled through polkit. There are two operations: org.freedesktop.login1.set-user-linger which by default requires admin privileges, and org.freedesktop.login1.set-self-linger which by default allow any user to enable lingering for themselves. So lingering (with the default policy) requires no privileges, just an explicit enabling. > For the Fedora side: > > I agree that it should be a F25 change so things can be coordinated and > so it has higher visibility for users. This would also allow time/a > chance for working groups to decide if they want to have a per edition > default that's different from the base one. > > If something like a 'permissive' mode is possible, I would think it > would be nice to move rawhide to that for now, if not, I don't feel too > strongly either way on leaving it enabled for now. (On one hand > disruption for users, on the other hand rawhide users should all be > subscribed to this list and can change the default if they wish). > > If we can handle the common cases, I think this is a lovely step > forward. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
So there's tmux, screen, curl, wget, and probably quite a few others that don't necessarily get daemonized that are probably affected. It may be that most problems are processes instantiated by the DE running in the user session; and if that's true then maybe the DE needs to be more aggressive with cleanup rather than depending on systemd? Found this related thread, which is now closed for comments but it's interesting perspectives. https://github.com/tmux/tmux/issues/428 --- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Sun, May 29, 2016 at 5:06 PM, Zbigniew Jędrzejewski-Szmek wrote: >> * Does 'loginctl enable-linger ' take effect in the current >> session? Or do you have to start a new one? does it persist over >> sessions or only affects the current/next one? > Lingering applies to the systemd --user instance, a.k.a. systemd@.service, > not to the session. Lingering means that systemd@.service is present > even if you are not logged in. If lingering is disabled, it is started > on login, and stopped on logout of that user. > > Killing processes which are part of the session (session-.scope) > doesn't have anything to do directly with lingering. It is controlled by > the global KillUserProcesses= setting. > > The connection between KillUserProcesses= and long-running processes is > that if KillUserProcesses=yes is set (the new default), to successfully > create a process which survives logout two steps are needed: > 1. move it out of the session into a systemd --user unit, > 2. make that systemd --user instance persistent, i.e. enable lingering. > > Setting lingering is done over dbus, takes effect immediately, and is > persistent (/var/lib/systemd/linger/ is created). > > Setting KillUserProcesses can be done by modifying /etc/systemd/logind.conf, > and also takes effect immediately, if systemd-logind is reloaded > (using SIGHUP). Can you clarify how systemd-run --user --scope fits in to this? While I certainly understand the motivation of running services in a clean environment (as systemd-run without --scope would do), there are cases where that's the wrong thing to do. For example, if nohup were adjusted to work in the new regime, it would *not* want a clean environment. But I still don't understand how scopes work, what they have to do with lingering, whether every scope lives strictly within a service, or pretty much anything else about them. The systemd.scope(5) manpage isn't particularly helpful. --Andy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
You know, it seems to me that systemd doing this to work around a Gnome problem (and a problem I have not seen outside of Gnome), is sort of like glibc working around a bug in Firefox and at the same time breaking bash. We're taking a bug in the Gnome stack and putting a 'fix' in systemd that breaks all sorts of applications. In turn, the 'fix' to those breakages is to add new, systemd specific code. I fail to see how this is even acceptable. I know right off that projects such as Mediagoblin are going to refuse to include such code, and rightfully so. There are distros, such as Void, that exist specifically to avoid systemd. While obviously the systemd developers do not care about such distros, it is really not cool to force dependencies that they would rather avoid on them. Here's an idea. How about Gnome fix their broken crap, and let's not enable this missfeature in systemd? All these problems (including the true, root problem!) go away. Alas, this seems to be too difficult a solution. John. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Mon, 30 May 2016 01:43:30 - "John Dulaney" wrote: > You know, it seems to me that systemd doing this to work around a > Gnome problem (and a problem I have not seen outside of Gnome), is > sort of like glibc working around a bug in Firefox and at the same > time breaking bash. We're taking a bug in the Gnome stack and > putting a 'fix' in systemd that breaks all sorts of applications. In > turn, the 'fix' to those breakages is to add new, systemd specific > code. I fail to see how this is even acceptable. I know right off > that projects such as Mediagoblin are going to refuse to include such > code, and rightfully so. I've seen lingering processes/applications pretty much from all desktop envs at various times and places. I don't think this is Gnome specific IMHO. I think it would be helpful if it could log these offenders and we could actually gather data on them instead of speculating. kevin pgpER2lLjmteu.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Mon, May 30, 2016 at 01:43:30 -, John Dulaney wrote: Here's an idea. How about Gnome fix their broken crap, and let's not enable this missfeature in systemd? All these problems (including the true, root problem!) go away. Alas, this seems to be too difficult a solution. Let's be excellent to each other. Everyone here wants Fedora to be better and we should keep that in mind when discussing problems. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
