kde April 2019

kde@lists.fedoraproject.org

19 participants
18 discussions

Okular lost duplex printing option in F30
by Mattia Verga 16 Apr '19

16 Apr '19

After the upgrade to F30 I cannot print double sided in Okular with my HP printer. I used to have dulex options enabled in the printing dialog, but they're now disabled. Anyone can confirm this issue with other printers? Okular 1.6.2 KDE framework 5.55.0 Qt 5.12.1 HP Color Laserjet Pro M252dw

5 6

F30 beta breeze-icon-theme issue
by Roderick Johnstone 09 Apr '19

09 Apr '19

Hi I'm testing F30 beta with a kickstart install. The installation is failing with: 06:29:29,105 ERR dnf.rpm: Error in <unknown> scriptlet in rpm package breeze-icon-theme Excluding this package causes many dependency issues for plasma. Does anyone else see this issue? Thanks Roderick Johnstone

2 2

QT 5.12 is not in F30
by Sérgio Basto 07 Apr '19

07 Apr '19

Hi, Have you notice that QT 5.12 is not in F30 anymore ? any reason ? References: https://bodhi.fedoraproject.org/updates/FEDORA-2019-74ad6b133a https://bugzilla.redhat.com/show_bug.cgi?id=1661849 Thanks -- Sérgio M. B.

4 3

missing application icons in tray applet after upgrade to f30 beta
by Alexey Mednyy 06 Apr '19

06 Apr '19

Hi, can't figure out what happened, for some reason I'm missing all my applications icons, but I have network configuration, notifications, mixer etc. All good except for apps. On fresh account icons showed up. So something wrong with my config maybe not sure.

1 0

KTorrent on NTFS
by Syam Krishnan 06 Apr '19

06 Apr '19

Hi I have a problem with KTorrent downloading files on to an NTFS partition. When I download, KTorrent first creates a file (I have selected to fully allocate disk space) in the destination directory. If the destination is on a NTFS partition, this process is extremely slow. After reading lot of documents on Internet and ntfs-3g documentation, I am using the following mount options in fstab: defaults,rw,umask=000,uid=1000,gid=1000,lazytime,big_writes,async But mount command shows: /dev/sda2 on /mnt/vault1 type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) I get the same results if I mount manually using: ntfs-3g -o rw,umask=000,uid=1000,gid=1000,lazytime,big_writes,async,debug /dev/sda2 /mnt/vault1 Is this normal? I mean the mount options that I pass (specifically big_writes) are not reflected in the mount command output. How is NTFS performance for you all? Am I doing something wrong here? Thanks, Syam

1 0

Different applications and menu items in Netinst and LiveCD
by Lukas Ruzicka 06 Apr '19

06 Apr '19

Hello, I have seen that there are differences in Menus and also in installed applications in KDE Desktop installed from the Netinst iso using the KDE Desktop package selection in Anaconda, and in KDE Desktop installed from Live CD. I filed a bug for one such discrepancy ( https://bugzilla.redhat.com/show_bug.cgi?id=1672312), but there are definitely more. We believe that both installation methods should result in the same version of KDE desktop. Can you please clarify? -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzicka(a)redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

2 1

Re: "Basic graphics mode" feature and criterion discussion
by Adam Williamson 02 Apr '19

02 Apr '19

On Tue, 2019-04-02 at 12:07 -0600, Chris Murphy wrote: > On Tue, Apr 2, 2019 at 4:19 AM Kamil Paral <kparal(a)redhat.com> wrote: > > On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson <adamwill(a)fedoraproject.org> wrote: > > > "The boot menu for all release-blocking installer and live images > > > should include an entry which causes both installation and the > > > installed system to use a generic, highly compatible video driver (such > > > as 'vesa')." > > > > Maybe change "causes" to "attempts", so that it's clear it has to > > do something (e.g. add a kernel cmdline option), but the thing > > doesn't have to succeed ("causes" sounds to me like a successful > > attempt). > > Agree. > > > > At Final we would add this requirement: > > > > > > "The generic video driver option ('basic graphics mode') on all > > > release-blocking installer and live images must function as intended > > > (launching the installer or desktop and attempting to use a generic > > > driver), and there must be no bugs that clearly prevent the installer > > > or desktop from being reached in this configuration on all systems or > > > on wide classes of hardware." > > > > Here I'd probably remove "attempting" in favor of a stricter "using > > a generic driver". But even your version sounds ok. > > I agree. OK, I'm gonna go ahead and push this change out with both of Kamil's proposed changes. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Re: "Basic graphics mode" feature and criterion discussion
by Adam Williamson 02 Apr '19

02 Apr '19

On Tue, 2019-03-26 at 14:30 -0600, Chris Murphy wrote: > My two cents: > > If there's a fallback option, and if the user selects it, they > shouldn't end up in an unambiguous state. Right now we're seeing > systems hanging. I'd rather see a crash than a hang where the user > can't get to a shell, and sees no useful information on the screen > that tells them why they're hung up; or even generically that "by now > you should see a login screen and if you don't we've faceplanted > somewhere, sorry". > > Maybe split the criterion: > > Basic criterion: installation media must have a basic video boot entry > that uses the accepted fallback boot parameter(s), e.g. nomodeset. The > criterion just means the media must have the menu entry, and that it > passes something intentional for this purpose as a boot parameter. > > Final criterion: installation media's basic video boot entry should > either work (we get a successful graphical boot), or it should > faceplant in some unambiguous way. > > If it's not possible to ensure basic video either works as intended or > faceplants unambiguously; then I suggest dropping any beta or final > criterion. And also I wonder if it's at all useful to include some > kind of heads up description for the basic video boot entry? Like, > "this may not work at all" or "wait 5 minutes for graphical boot, > after 10 minutes assume it failed". Haha - I have no idea. Just > something so they aren't waiting around going WTF? Now what? So kinda aggregating all the response to this discussion, I propose we go with a modified version of Chris' proposal. 1. We retain the 'entry must exist' part of the criterion at Basic (but at that point it does not have to *work* - the idea is to ensure it's testable so we catch bugs in it at that point) 2. We move the rest of the criterion to Final and tweak it a bit to specify that it must be at least somewhat capable of reaching the installer or desktop. We do not adopt Chris' "or faceplant unambiguously" proposal, people seemed to prefer just requiring it to work. So, here's the specific text I propose. At Basic we would change this requirement: "The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver." To read only: "The boot menu for all release-blocking installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa')." i.e. remove the second sentence (and change 'supported' to 'release- blocking' - that is a better form of words that should have been used all along). At Final we would add this requirement: "The generic video driver option ('basic graphics mode') on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware." How does that sound to everyone? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde April 2019