I intend to update kpmcore and kde-partitionmanager in F24 to version
This will lead to libkpmcore soname bump, I don't expect to cause any
problem because at the moment the only package requiring libkpmcore is
I am very sorry that the recent build of gettext-0.19.8-1 package, which
has already been pushed to F24, had an unintentional soname bump of
libgettextpo that affected the following packages:
May I ask to rebuild those?
Just noticed this change on rawhide...
* systemd-logind will now by default terminate user processes that are
part of the user session scope unit (session-XX.scope) when the user
logs out. This behavior is controlled by the KillUserProcesses=
setting in logind.conf, and the previous default of "no" is now
changed to "yes". This means that user sessions will be properly
cleaned up after, but additional steps are necessary to allow
intentionally long-running processes to survive logout.
While the user is logged in at least once, user@.service is running,
and any service that should survive the end of any individual login
session can be started at a user service or scope using systemd-run.
systemd-run(1) man page has been extended with an example which shows
how to run screen in a scope unit underneath user@.service. The same
command works for tmux.
After the user logs out of all sessions, user@.service will be
terminated too, by default, unless the user has "lingering" enabled.
To effectively allow users to run long-term tasks even if they are
logged out, lingering must be enabled for them. See loginctl(1) for
details. The default polkit policy was modified to allow users to
set lingering for themselves without authentication.
Previous defaults can be restored at compile time by the
--without-kill-user-processes option to "configure".
So, now, I've read this and I could possibly remember to use systemd-run
or to set myself as lingering... Except that I don't want to have to go
through the pain of remembering to either change the system config on
all my servers or always starting stuff with systemd-run if it's a bit
long and I think I might want to ^Z/bg/disown it to let it finish.
Thinking further when my users get that update I don't see myself
telling them to do that when they want to start a screen/tmux/nohup-job,
users do not read every update changelogs (tbh I don't either unless
there's a problem); and they probably wouldn't think of systemd if they
ever get that particular issue.. heck they probably don't even know what
systemd and logind are (even if yes, they are "advanced" enough to ssh
into other servers to run *long* tasks that must continue overnight/when
the user logs out ; it doesn't mean they know what they're using
Sure, this change will work for the whole probably targetted audience of
simple desktop users on shared workstations where we probably want to
kill lingering processes; but how much is that compared to servers ?
I know that if this gets through I will have to change the system
default on all my servers... And while the big batches of thousands of
compute nodes are automated there's still quite a few places to update,
especially since this will be the first time we need to change
logind.conf so it's not just adding a line to a file already propagated
Anyway, I don't really want to start (yet) a(nother) troll on systemd, I
appreciate it's also brought good things; I'd just like the default
values to be sane for most of the users.
I did not see any discussion about this particular setting in the
systemd-devel mailing list so I have hope that it is still open to
change, but I'd rather start with a community where there are more
admins who will likely agree that this change will do more harm than
Even if nothing comes out of it, at least more people will be aware of
the issue and will be able to prepare to avoid most of the chaos that
will come if this stays like this...
Thanks for reading,
#fedora-meeting: FESCO (2016-06-10)
Meeting started by jsmith at 16:00:40 UTC. Full logs are available at
init process (jsmith, 16:00:40)
Follow-ups (jsmith, 16:03:32)
#1576 Evaluate Workstation graphical upgrade Change status (jsmith,
https://fedorahosted.org/fesco/ticket/1576 (jsmith, 16:03:43)
#1573 Docker Layered Image maintainer guildelines, naming guidelines
and review (jsmith, 16:07:05)
https://fedorahosted.org/fesco/ticket/1573 (jsmith, 16:07:05)
AGREED: #1573 Docker Layered Image maintainer guidelines, naming
guidelines and review are approved (+1: 7, +0:0, -1:0) (jsmith, 16:12:31)
New Business (jsmith, 16:12:53)
#1584 Please process systemd presets request, bz :1340061 (jsmith,
https://fedorahosted.org/fesco/ticket/1584 (jsmith, 16:13:05)
AGREED: Closing #1584, as there's nothing for FESCo to do about it
at this time (jsmith, 16:15:47)
#1568 F25 Self Contained Changes (jsmith, 16:16:06)
https://fedorahosted.org/fesco/ticket/1568 (jsmith, 16:16:07)
AGREED: #1568 Self Contained Changes: All three new requested
changes are approved (jsmith, 16:22:06)
Next Week's Chair (jsmith, 16:22:21)
Open Floor (jsmith, 16:22:53)
Meeting ended at 16:29:44 UTC.
People present (lines said)
Generated by MeetBot 0.1.4.
The upstream stable maintainers released kernels 4.5.7 and 4.6.2
yesterday. I thought I would send a brief word about how the rebase
of F24 to 4.6.y will happen.
We'll ship 4.5.7 as the final 4.5.y update and have that available as
the 0-day update for the F24 release on June 14th. That matches the
upstream lifetime of 4.5.y as well, as 4.5.y is no longer supported
Shortly thereafter we'll be rebasing F24 to 4.6.y, most likely
starting with 4.6.3. We may use 4.6.2 if 4.6.3 is delayed for some
reason, but it would be better to get the additional fixes that 4.6.3
For those of you that cannot wait, we do have a COPR with 4.6.y builds
included. You can find it here:
(4.6.1 was skipped for no particular reason.)
F23 will follow a week or two after the F24 rebase. F22 will likely
get one final 4.4.y kernel update and then go EOL per the Fedora
If you have any questions, please let us know.