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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list
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?
On Sunday 29 May 2016 10:38 AM, devel-request(a)lists.fedoraproject.org wrote:
> Send devel mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> 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
On 29 May 2016 5:02 a.m., "Nico Kadel-Garcia" <nkadel(a)gmail.com> wrote:
> On Sat, May 28, 2016 at 9:41 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> 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
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.