updates-testing pulls kdepim
by Reindl Harald
why is KDEPIM now a dependency?
i tried to post the whole yum output
but that post is under moderation
Message body is too big: 46501 bytes with a limit of 40 KB
40 KB? seriously?
Installing for dependencies:
baloo-akonadi
boost-thread
gnupg2-smime
grantlee
kaddressbook-libs
kdepim-common
kdepim-libs
kdepim-runtime
kdepim-runtime-libs
khotkeys
khotkeys-libs
kinfocenter
kleopatra
kmail
kmail-libs
kmenuedit
knotes
knotes-libs
libkfbapi
libkgapi
libkolab
libkolabxml
libksba
pinentry-qt
python-lockfile
spambayes
xerces-c
9 years, 2 months
Applications in a dual monitor situation.
by George R Goffe
Hi,
I have a system (Fedora 20 x86_64) with two monitors running KDE. I would like to start applications from one Konsole displaying on one monitor and have their GUI appear on this same monitor. ImageMagick functions this way but other applications do not.
Is there a way to get all my applications started in one monitor to have their GUI appear on that monitor.
Regards and THANKS for your help and time,
George...
9 years, 2 months
Re: criterion update: add "switch user" to Shutdown, reboot, logout
by Kamil Paral
> At the same time, our blocker criteria are generally interpreted to apply to
> common bugs. If user switching is broken for one guy with an obscure setup,
> that shouldn't be a blocker.
Yes, that's how release criteria usually work. It needs to be a general problem affecting everybody or a large part of the audience (best guesses applied here). We usually don't block on obscure setups, unless it has e.g. catastrophic consequences (severe data loss, etc).
> Is there a particularly strong use case for user switching when booted
> from live media? If not, can't this be fixed with an update?
Release criteria affect more things than just those which are important for LiveCD usage and/or can't be updated. For example, keyring functionality is not too much useful on LiveCD, it can be updated post-install, yet it has to work on the release day. The same goes for lot of apps which you're not likely to use from LiveCD, e.g. gnome-documents, gnome-contacts, etc.
But it's true that software which can be updated post-release gets lower severity when discussing the impact of the bugs (especially when it's not a general issue affecting everybody, but just a part of Fedora user base). The same would apply here, the point is not to block on obscure bugs but to block on widespread bugs.
> I agree with Matthias, user switching isn't worth considering a blocker.
> Besides, even if broken, it can easily be fixed by subsequent updates.
I proposed this criterion because history shows that the approach you mention (let's fix it with updates) didn't really work, at least for GNOME. So I'm trying something else, to make sure it gets the attention I believe it deserves. (We reached the same conclusion during our blocker bug review). It seems that people opinions on importance of this feature vary wildly, which is unfortunate. If we don't reach consensus, it can't be a criterion.
A thing to consider - if we know user switching is completely broken (not just broken in some use cases or for someone, but completely broken), are we OK with releasing Fedora like that? Should that feature deserve a prominent position in the system/user menu, if we're not willing to guarantee at least basic correctness?
In that case we would probably need to specify an explicit exemption for user switching in https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_p... . Please note the description box below the criterion where it says:
# The key question is "would this bug cause significant inconvenience or just a really bad first impression to a typical user or reviewer of the release?"
9 years, 2 months
crypt_set_algorithms2: no crypto algorithm function found for aes128-gcm@openssh.com
by Reindl Harald
the replacement of the kio-slave years ago instead continue sftp
wrappers still makes me *terrible angry* in Konqueror
crypt_set_algorithms2: no crypto algorithm function found for
aes128-gcm(a)openssh.com
WTF then take the next one in the list of /etc/ssh/ssh_config, hence it
is a list and not a stupid single value but don't force me to configure
weaker ciphers just becaus ethe kio-slave is too dumb
Ciphers
aes128-gcm@openssh.com,aes256-gcm(a)openssh.com,aes128-ctr,aes256-ctr,aes256-cbc
9 years, 2 months
Re: Plasma Desktop - An internal system error has occurred.
by Rex Dieter
I've seen it twice too since the latest batch of PackageKit related updates came in,
https://admin.fedoraproject.org/updates/FEDORA-2015-0921
-- rex
________________________________________
From: kde-bounces(a)lists.fedoraproject.org <kde-bounces(a)lists.fedoraproject.org> on behalf of Peter G. <pgueckel(a)gmail.com>
Sent: Thursday, January 22, 2015 11:35 AM
To: kde(a)lists.fedoraproject.org
Subject: Plasma Desktop - An internal system error has occurred.
My system is up-to-date every day. Yesterday, right
after logging in and again today, right after logging
in, the following pop-up appeared on the screen, before
I did anything:
A problem that we were not expecting has occurred.
Please report this bug with the error description.
Details:
Did not receive a reply. Possible causes include: The
remote application did not send reply, the message bus
security policy blocked the reply, the reply timeout
expired, or the network connection was broken.
When this occurs, I am unable to do anything: no right
click on the desktop, the task bar is inactive and
unresponsive, but I can still use the active screen
edges to change virtual desktops. I click around,
repeatedly clicking on the application tabs on the task
bar, click the fedora 'f' a number of times, and
presto! Suddenly it all works again. I don't notice any
problems with the session until, presumably, the same
error upon the subsequent login.
Wha?
_______________________________________________
kde mailing list
kde(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
9 years, 2 months
Plasma Desktop - An internal system error has occurred.
by Peter G.
My system is up-to-date every day. Yesterday, right
after logging in and again today, right after logging
in, the following pop-up appeared on the screen, before
I did anything:
A problem that we were not expecting has occurred.
Please report this bug with the error description.
Details:
Did not receive a reply. Possible causes include: The
remote application did not send reply, the message bus
security policy blocked the reply, the reply timeout
expired, or the network connection was broken.
When this occurs, I am unable to do anything: no right
click on the desktop, the task bar is inactive and
unresponsive, but I can still use the active screen
edges to change virtual desktops. I click around,
repeatedly clicking on the application tabs on the task
bar, click the fedora 'f' a number of times, and
presto! Suddenly it all works again. I don't notice any
problems with the session until, presumably, the same
error upon the subsequent login.
Wha?
9 years, 2 months
Plasma 5.2 beta live ISO and packages available
by Dan Vratil
Hi all,
KDE has released Plasma 5.2 beta on Tuesday, and If you want to take a sneak
peek into what's coming in Plasma 5.2 and do some testing to help upstream to
iron out all the issues before release, you can now do so on Fedora!
There's live ISO based on Fedora 21 available from here:
http://pub.dvratil.cz/plasma/iso/5.1.95/
If you want to install beta packages on your computer (or VM), you can do so
from plasma-5-beta Copr (see Installation Instruction on the Copr page for
details):
http://copr.fedoraproject.org/coprs/dvratil/plasma-5-beta
Note that you should install the beta only if you really want to help with
testing, or if you have serious issues with the stable Plasma 5.1.2 from
plasma-5 Copr that might be fixed in the upcoming 5.2 release. It's still just
a beta release, so you have to expect some unstability.
If you want to switch from KDE 4 to Plasma 5 for production use, we recommend
using the stable plasma-5 Copr which currently ships Plasma 5.1.2:
http://copr.fedoraproject.org/coprs/dvratil/plasma-5
We'll update the plasma-5 Copr to 5.2 once it is released. Plasma 5.2 final
release is scheduled on the end of January.
If you run into any issues or bugs, please DO REPORT them to upstream
bugtracker (bugs.kde.org), so that upstream can fix them.
Cheers,
Daniel
--
Daniel Vrátil | dvratil(a)redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.
GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
9 years, 3 months
Re: baloo-kcmadv in f20/kde-unstable repo
by Rex Dieter
I don't recall any formal decision being made about including it by default.
Do you remember otherwise?
If a decision hadn't been made, I'd make a counter-proposal:
* hide the default kcm by default (but keep installed, so callers to 'kcmshell4 baloofile' still works)
* install baloo-kcmadv (by default, via deps or comps or whatever, don't care about implementation details), but *keep* the existing description, ie, "(Advanced)" to make it clear it is not the default one
-- Rex
________________________________________
From: kde-bounces(a)lists.fedoraproject.org <kde-bounces(a)lists.fedoraproject.org> on behalf of Kevin Kofler <kevin.kofler(a)chello.at>
Sent: Thursday, January 15, 2015 9:15 AM
To: kde(a)lists.fedoraproject.org
Subject: Re: baloo-kcmadv in f20/kde-unstable repo
Rex Dieter wrote:
> It's an opt-in kind of thing, I think we chose not to install it by
> default.
It's not that we chose not to, it's just that nobody bothered to add the
Requires.
I still think that we should be shipping only baloo-kcmadv instead of the
crippled default KCM, changing the description to remove the "(Advanced)".
9 years, 3 months
Re: baloo-kcmadv in f20/kde-unstable repo
by Rex Dieter
It's an opt-in kind of thing, I think we chose not to install it by default.
-- rex
________________________________________
From: kde-bounces(a)lists.fedoraproject.org <kde-bounces(a)lists.fedoraproject.org> on behalf of Richard Z <rz(a)linux-m68k.org>
Sent: Wednesday, January 14, 2015 10:41 AM
To: colin(a)g6avk.demon.co.uk; KDE on Fedora discussion
Subject: Re: baloo-kcmadv in f20/kde-unstable repo
On Sat, May 03, 2014 at 01:05:23PM +0100, Colin J Thomson wrote:
> On Fri 2 May 2014 09:04:27 Rex Dieter wrote:
> > An alternative baloo-kcmadv with more features and closer to the nepomuk
> > kcm is under development, and has been packaged in f20/kde-unstable repo.
> >
> > Features include:
> > disable indexing button
> > whitelist/blacklist
> > mime/glob filtering
> >
> > Once installed, you'll see a new item "Desktop Search Advanced" in
> > systemsettings.
>
> Only done some basic testing but it seems to be working well here Rex, I guess
> in time it will obsolete/remove the basic baloo-kcmadv
noticed that id didn't get installed automatically when upgrading
with fedup from F19 - would be nice to have that done automatially
or advertise it somehow.
9 years, 3 months
baloo-kcmadv in f20/kde-unstable repo
by Rex Dieter
An alternative baloo-kcmadv with more features and closer to the nepomuk
kcm is under development, and has been packaged in f20/kde-unstable repo.
Features include:
disable indexing button
whitelist/blacklist
mime/glob filtering
Once installed, you'll see a new item "Desktop Search Advanced" in
systemsettings.
-- rex
9 years, 3 months
