Will yawp yet work with plasma 5/Newer KDE in Fedora 22? I know it
was built for it back in August I think, but it requires an obsoleted
kde-workspace-libs or whatever.
Or am I missing something?
"Best lil town on Earth!"
I'm running Fedora-21/KDE on my laptop.
The window I'm watching frequently disintegrates
into 8 separate windows, corresponding to my 8 virtual desktops.
I know this is caused by moving the mouse into some area.
But I cannot think of any occasion when it would actually help.
Is there any way of turning this facility off?
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin
It would be very helpful if 'move to screen' was on the menu on the panel.
In the window decorations there is 'move to desktop' as well as 'move to
screen', but on the panel there is only 'move to desktop. Is this possible?
Those who fail to understand recursion are doomed to repeat it
trying to add an event I get the message
"select a valid collection first"
There is nothing obvious in the dialog where I could select
any collection. On top of the dialog window is a "Calendar"
dropdown which unfortunately does not drop down when clicked.
I did use the Calender in previous versions of Fedora but not
since I upgraded to F21.
Thanks for any hints,
Name and OpenPGP keys available from pgp key servers
Last thread about unrar talks about unrar of rpmfusion , but to work
correctly we should have unar (without one r) that is free .
repoquery unar -i
URL : http://unarchiver.c3.cx/commandline
Source : unar-1.8.1-5.fc21.src.rpm
The command-line utilities lsar and unar are capable of listing and
files respectively in several formats including RARv3. unar can serve as
a free and open source replacement of unrar.
BTW ark from Fedora 21 just works with unar and shouldn't be a package
require of ark ?
Sérgio M. B.
Are there plans to allow for both Plasma 5 and KDE Workspaces to coexist in F22?
Currently, that seems not possible due to, at least, Network Manager components being obsoleted by Plasma 5 installation.
If you can't laugh at yourself, others will gladly oblige.
I've seen some mention of the new settings panel not having all the
features yet, is there any way to disable all notification sounds in
plasma5 short of individually turning them off?
Hey, folks. I'm writing with my Server SIG member hat on, here. We've
been discussing password policy changes at our meeting today.
So the Great Password Policy Bunfight of 2015 was resolved by anaconda
creating a mechanism for products/spins to set their own password
I'm slightly worried, however, about the possibility that everyone
goes out and picks a more lenient policy more or less at random and we
wind up with different policies on every Fedora medium. That seems
like it'd be needlessly confusing to users and difficult to document.
I'm wondering if those products/spins intending to set a policy weaker
than the default could all agree on the same one, so there'd only be
at most two policies to care about (and if all products/spins overrode
the upstream default, there'd only be one).
The obvious choice would be the pre-F22 policy, which I believe should
--nostrict --minlen=6 --minquality=50 --nochanges --emptyok
(though it's not *entirely* clear from the code - I think it used
pwquality upstream defaults - so I may be a bit off).
What's the general feeling here? Have other SIGs discussed this yet?
Come to any decisions? Thanks!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
On Tue, 2015-03-24 at 12:51 -0500, Michael Catanzaro wrote:
> the system is installed. It doesn't make sense for Anaconda to
> enforce a
> different policy than will be enforced after installation, so it
> that we should all use --minquality=1 and just have different
> pwquality.conf to adjust the strength of the passwords if need be. I
> think that should be acceptable for all products.
You're pointing out the same thing I was wondering about when I read
about this kickstart mechanism: We don't want to configure password
policies in two places - thats only going to lead to anaconda
disagreeing with the installed system.
> We also need to make sure that our solution is acceptable to the
> gnome-initial-setup developers, which currently uses pwquality to
> display password strength but allows setting any password. If they
> accept any form of password strength enforcement, then I would favor
> ripping pwquality out of the PAM stack to resolve the problem.
> that could move to a subpackage.) I suspect a very lenient
> pwquality.conf may be the only way to reach a compromise here.
I think the difference of opinion is only about the enforcement part.
If pwquality gives us useful information about that quality of the
password then we absolutely show that to the user and help her to come
up with a better password.