I was curious about something. KDE has its own crash handling system.
How does this community track any metrics around code stability if
upstream gets reports? Kontact has segfaulted 20 times on me today.
Each time it says it cannot generate a bug report. Abrtd does not seem
to pick up anything. Shouldn't it? How does this community track
when a recent update suddenly starts making things crash? Kontact was
fine 3 weeks ago. I updated today (3 weeks of patches) and its crashing
all the time to the point its unusable. It won't generate a bug report,
abrtd seems not to notice either.
I currently use t-bird with an nntp account pointing to gmane to read
this list and sereral others. Does kde have an nntp client program of
any sort? I don't see it as a possible new account type in kmail. Also,
search with kpackagekit yields nothing with "usenet" or "nntp" that is
Review Request: polkit-qt-1 - Qt bindings for PolicyKit -
Fyi, ^^ newer polkit-qt releases dropped support for qt4, so this new one
will track latest developments, and existing polkit-qt will (continue to)
track legacy/qt4 support only
Need to do some similar work for phonon (ie, latest phonon release dropped
support for qt4) affecting both phonon, and backends (gstreamer). will
consider to drop support for qt4-based vlc backend (for f32+)
Just wanted to give a heads up on the progress thus far.
EPEL8 expects to have modules by early December. That's a couple
months away, but still this year.
For non-KDE packages, I have started moving those over to regular
EPEL8. The normal maintainers are taking their packages, and for
those that don't want to be EPEL maintainers, I am taking the package.
This should not affect much, except for two things.
First - system-switch-displaymanager is going away. It is python2
based, and in the end, it's whole functionality can be run in one
simple systemctl command.
Second - There are a couple of packages that the Fedora maintainers
would rather not be in Fedora at all, let alone EPEL8. Example is
xorg-x11-drv-synaptics. I will be reaching out to the specific
package maintainers to see if we can/should update these.
Here is the (minorly) updated "How to install KDE on RHEL8/CentOS8"
## How to install
### First: install epel-release
rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
### Second: Enable epel-playground
dnf config-manager --enable epel-playground
### Third: Enable codeready-builder-for-rhel-8
#### If RHEL 8 do
subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
#### If CentOS 8 do
dnf config-manager --enable PowerTools
### Fourth: install KDE
dnf group install "KDE Plasma Workspaces"
(Optional) dnf group install kde-desktop
(Optional) dnf group install kde-apps
(Optional) dnf group install kde-media --skip-broken
(Optional) dnf group install kde-education
(Optional) dnf group install kde-software-development
(Optional) dnf group install kf5-software-development
### (Optional) Fifth: Set sddm as desktop manager
systemctl set-default graphical.target (Not-Optional if in multi-user.target)
(optional) dnf install sddm
(optional) systemctl enable sddm -f
 - Here is the list of non-KDE packages needed to build and/or run
KDE. Those marked DONE are already in regular EPEL 8.
imlib2 - DONE
libbsd - DONE
libid3tag - DONE
libupnp - DONE
lmdb - DONE
pngcrush - DONE
proj - DONE
re2 - DONE
system-switch-displaymanager - REMOVED
upower - In RHEL8 - REMOVED
2 high-profile KDE packages are currently orphaned (not in immediate danger
of retirement according to the time of orphaning, but still):
Miro Hrončok wrote:
> kig jreznik, kde-sig, orphan, 0 weeks ago
This is a current part of KDE Applications (as part of the KDE Edu project).
Surely this should not go away.
There is the issue that it depends on Python 2, which should probably be
taken up with upstream (though apparently OpenMandriva has it building with
Python 3, so that might work for us too). See:
> rkward orphan 3 weeks ago
While this is not a part of the KDE Applications bundle, it is a
KDE-Frameworks-5-based application, developed and released on KDE
infrastructure. It is also the best R IDE we currently have in Fedora.
Any takers for these two?
I occasionally have to type "international" (i.e. non-English)
characters but can often not remember where they are. System Settings
has an option to show a preview of the current keyboard layout, but it
takes a fair amount of pointing and clicking to get to.
Is there an easy way to create a shortcut to this, either via a key
combo or a widget?
Felix Miata composed on 2019-10-12 04:46 (UTC-0400) (on test list):
> Konsole window opens with toolbar, but there's no I/O pane to type in, just a lot
> of menubar background color. In IceWM session Konsole works normally.
Happens again on another 30 to 31 upgrade (host bug41 this time; hpg33 previously).
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
On Mon, 2019-09-30 at 15:19 -0400, Ben Cotton wrote:
> As we discussed in today's blocker review meeting, I am presenting
> a draft proposal for the toggle keys. I am proposing this as a *final*
> criterion, but would not object to adding it as a beta criterion.
> == Keyboard toggle keys ==
> For all release-blocking desktops, the Caps Lock and Num Lock keys
> must correctly toggle the relevant behavior for the desktop and all
> applications. The behavior must be consistent with the displayed
> status on physical or virtual keyboards, where applicable.
I think I'm on board with this; however, it'd also be good to get input
from the desktop teams, as the responsibility for this ultimately falls
on them. So CCing desktop@ and kde@. What do you folks think about this
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net