[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343803

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC|kdeb...@fratti.ch   |

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

--- Comment #10 from Nicolas Frattaroli  ---
Actually, I already have previews turned off in the folders in which this
happens. The fact that it happens inconsistently would also indicate that the
problem is something else.

I'll try to mess around with gdb some more when I get the time to.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

--- Comment #7 from Nicolas Frattaroli  ---
Created attachment 101546
  --> https://bugs.kde.org/attachment.cgi?id=101546=edit
A different backtrace from another hanging kdialog process

Sorry for the many successive comments, but here's another backtrace, this time
hanging in libharfbuzz.

It looks like this might be an issue with my system's fonts, which would
explain why you might not be able to reproduce it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

--- Comment #6 from Nicolas Frattaroli  ---
Created attachment 101545
  --> https://bugs.kde.org/attachment.cgi?id=101545=edit
gdb backtrace of interrupted process while it hangs

Here's the gdb backtrace of a hanging kdialog process (built as debug), however
kde frameworks and Qt aren't built with debug symbols because Arch Linux
doesn't provide pre-compiled debug packages, I'll try to build everything with
debug symbols someday, but since this will probably take a long time I haven't
done so yet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

--- Comment #5 from Nicolas Frattaroli  ---
Correction: kdialog now seems to hang again, so seemingly this isn't
consistently reproducible.
It still only hangs if the folder has a lot of files in it, though.
After a few tries, I've also gotten it to hang on my /usr/bin/ (5490 items), so
it seems the filetype does not matter.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

--- Comment #4 from Nicolas Frattaroli  ---
This is with the side-panel preview on. The folder is full of mainly PNG
images. The images are sorted by filename.

I've just tried again with kdialog and compared it to a minimal file widget
application I wrote based on the kio tests, and while kdialog now seems to no
longer hang (although this isn't git HEAD), the test application still does.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 370156] digital clock font is tiny since plasma 5.8.0

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370156

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC||kdeb...@fratti.ch

--- Comment #8 from Nicolas Frattaroli  ---
Arch Linux on Plasma 5.8 here, on a ~168 DPI monitor. Regardless of the clock
font, the clock is tiny. However, if the panel height is changed to a certain
size, the clock's size suddenly jumps up.

Here's a video demo: https://fratti.ch/tmp/plasma58_clock.mp4 (1.6M H.264
yuv444p10)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 369420] After turning off external monitor, taskbar disappears on primary monitor

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369420

--- Comment #3 from Nicolas Frattaroli  ---
Created attachment 101319
  --> https://bugs.kde.org/attachment.cgi?id=101319=edit
log of plasma crashing as the second monitor gets plugged in, and then being
restarted but still messed up

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 369420] After turning off external monitor, taskbar disappears on primary monitor

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369420

--- Comment #2 from Nicolas Frattaroli  ---
Created attachment 101317
  --> https://bugs.kde.org/attachment.cgi?id=101317=edit
org.kde.plasma.desktop-appletsrc

Found where the applet parameters are saved in the elegantly named
"plasma-org.kde.plasma.desktop-appletsrc" inside .config.

As you can see, my original panel (referred to as [Containments][1]) has a
lastScreen value of 1, whereas my new panel (referred to as [Containments][16])
has one of 0.

What those numbers refer to, I do not know, but I'm fairly sure there's
something fucky going on with whatever screen 1 is.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 369420] After turning off external monitor, taskbar disappears on primary monitor

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369420

--- Comment #1 from Nicolas Frattaroli  ---
I've just tried connecting my laptop to the TV again. Everything went a bit
crazy. The taskbar disappeared, even though my laptop display was set as the
primary output. Plasma ended up crashing (sadly I could not get a crashdump),
and I had to reboot the system after disconnecting it from the external TV to
even get working compositing again, as windows did not refresh and the
background was replaced with black.

I've found some files of interest in my .local and .config:
1. Three files in .local/share/kscreen, which seem to list (in a duplicate
manner) configured screens. Here they are, tarred and gzipped:
https://fratti.ch/bugdemos/kscreen/kscreen.tar.gz
2. The following lines in .config/plasmashellrc:
[PlasmaViews][Panel 1][Horizontal1920]
length=3779
thickness=30

[PlasmaViews][Panel 16][Horizontal1920]
thickness=36

I'm assuming my original panel, Panel 1, still exists *somewhere*, just not on
any physical screens.
Panel 16 seems to be the one I'm currently using and have created after I've
encountered the bug, as it is indeed thicker.

Any ideas on how I can get my original panel back, or identify where it even
went? (Where does plasma store this info?)

-- 
You are receiving this mail because:
You are watching all bug changes.

[KScreen] [Bug 369422] New: Number in refresh rate dropdown is being rounded to one decimal digit, producing duplicate-looking entries

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369422

Bug ID: 369422
   Summary: Number in refresh rate dropdown is being rounded to
one decimal digit, producing duplicate-looking entries
   Product: KScreen
   Version: 5.7.5
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: kcm
  Assignee: se...@kde.org
  Reporter: kdeb...@fratti.ch

The refresh rate numbers in their dropdown menu of the advanced settings are
being rounded to one decimal digit, which is insufficient precision to
distinguish between some refresh rates.

As an example, 59.98 Hz would get rounded to 60.0 Hz, when there already is a
60.0 Hz entry in the list stemming from the screen supporting 60.00 Hz also.

This gets even worse with TVs which support several close refresh rates due to
different standards in video frame rates, such as 24.00 Hz and 23.98 Hz
(according to xrandr, but more likely to be 23.976 Hz).

Increasing the precision by as much as it needs should fix this issue.

Reproducible: Always

Steps to Reproduce:
1. Either get a display that supports weird fractional refresh rates or use
xrandr to check at which solutions your already connected display supports
weird fractional refresh rates
2. Check the advanced settings, and notice how there are now duplicate-looking
entries in the dropdown
3. After choosing them, note how xrandr's output will confirm that the two are
distinct refresh rate, and thus confirms this is merely a visual issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kfile] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

--- Comment #2 from Nicolas Frattaroli  ---
Moved this to the product kfile, since kdialog simply builds on top of that.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kfile] [Bug 346403] kdialog freezes when startDir in --getopenfilename contains a lot of files

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346403

Nicolas Frattaroli  changed:

   What|Removed |Added

Product|kdialog |kfile
  Component|general |general

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 367759] System occasionally unable to suspend if Dolphin left running with sshfs folder open

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=367759

--- Comment #1 from Nicolas Frattaroli  ---
Note that this is on the Arch Linux stock kernel 4.7.1 on x86_64, for all I
know this could be a kernel bug making fuse hang which makes file.so hang which
makes Dolphin hang which makes suspend hang which makes my system hang.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 367759] New: System occasionally unable to suspend if Dolphin left running with sshfs folder open

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=367759

Bug ID: 367759
   Summary: System occasionally unable to suspend if Dolphin left
running with sshfs folder open
   Product: dolphin
   Version: unspecified
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: critical
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: kdeb...@fratti.ch

Occasionally, if a user attempts to suspend the system, the entire system will
hang and cannot be recovered. This appears to be related to having Dolphin open
viewing a SSHFS mounted folder. Journal messages indicate that the file.so
component does not wish to be suspended, and its call trace shows references to
fuse.

Reproducible: Sometimes

Steps to Reproduce:
1. Mount an SSHFS
2. Open a folder on it in dolphin and watch some videos or something
3. Suspend the system while dolphin is still open

Actual Results:  
The system hangs on a black screen with only the mouse cursor showing and no
longer accepts mouse or keyboard inputs. A while later, the sddm lock screen
pops up, but does not react to any inputs. Switching VTs is impossible. The
only way to get the system running again is to do a hard reset.

Expected Results:  
The system actually suspends properly.

The journal logs the following information:

Aug 24 03:48:49 archbook kernel: Freezing user space processes ... 
Aug 24 03:48:49 archbook kernel: Freezing of tasks failed after 20.007 seconds
(5 tasks refusing to freeze, wq_busy=0):
Aug 24 03:48:49 archbook kernel: file.so D 88021ca8bbb8 0  5791
   641 0x0004
Aug 24 03:48:49 archbook kernel:  88021ca8bbb8 00ff8800a2fe1838
8180d500 8801aeade3c0
Aug 24 03:48:49 archbook kernel:  88021ca8bbc0 88021ca8c000
88021ca8bbe8 880064c89520
Aug 24 03:48:49 archbook kernel:  8800a2fe1840 fe00
88021ca8bbd0 815d9aac
Aug 24 03:48:49 archbook kernel: Call Trace:
Aug 24 03:48:49 archbook kernel:  [] schedule+0x3c/0x90
Aug 24 03:48:49 archbook kernel:  []
request_wait_answer+0x11a/0x270 [fuse]
Aug 24 03:48:49 archbook kernel:  [] ?
wake_atomic_t_function+0x60/0x60
Aug 24 03:48:49 archbook kernel:  []
__fuse_request_send+0x67/0x90 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_request_send+0x27/0x30 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_simple_request+0xcf/0x1a0 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_do_getattr+0x120/0x330 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_update_attributes+0x68/0x70 [fuse]
Aug 24 03:48:49 archbook kernel:  [] fuse_getattr+0x43/0x50
[fuse]
Aug 24 03:48:49 archbook kernel:  []
vfs_getattr_nosec+0x29/0x40
Aug 24 03:48:49 archbook kernel:  [] vfs_getattr+0x26/0x30
Aug 24 03:48:49 archbook kernel:  [] vfs_fstatat+0x78/0xc0
Aug 24 03:48:49 archbook kernel:  [] SyS_newstat+0x33/0x60
Aug 24 03:48:49 archbook kernel:  [] ?
exit_to_usermode_loop+0x5e/0xc0
Aug 24 03:48:49 archbook kernel:  [] ?
syscall_return_slowpath+0x4e/0x60
Aug 24 03:48:49 archbook kernel:  []
entry_SYSCALL_64_fastpath+0x1a/0xa4
Aug 24 03:48:49 archbook kernel: file.so D 880219263bb8 0  6439
   641 0x0004
Aug 24 03:48:49 archbook kernel:  880219263bb8 00ff8800a2fe1838
880225ecc740 880221d18e40
Aug 24 03:48:49 archbook kernel:  880219263bc0 880219264000
880219263be8 880064d30580
Aug 24 03:48:49 archbook kernel:  8800a2fe1840 fe00
880219263bd0 815d9aac
Aug 24 03:48:49 archbook kernel: Call Trace:
Aug 24 03:48:49 archbook kernel:  [] schedule+0x3c/0x90
Aug 24 03:48:49 archbook kernel:  []
request_wait_answer+0x11a/0x270 [fuse]
Aug 24 03:48:49 archbook kernel:  [] ?
wake_atomic_t_function+0x60/0x60
Aug 24 03:48:49 archbook kernel:  []
__fuse_request_send+0x67/0x90 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_request_send+0x27/0x30 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_simple_request+0xcf/0x1a0 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_do_getattr+0x120/0x330 [fuse]
Aug 24 03:48:49 archbook kernel:  []
fuse_update_attributes+0x68/0x70 [fuse]
Aug 24 03:48:49 archbook kernel:  [] fuse_getattr+0x43/0x50
[fuse]
Aug 24 03:48:49 archbook kernel:  []
vfs_getattr_nosec+0x29/0x40
Aug 24 03:48:49 archbook kernel:  [] vfs_getattr+0x26/0x30
Aug 24 03:48:49 archbook kernel:  [] vfs_fstatat+0x78/0xc0
Aug 24 03:48:49 archbook kernel:  [] SyS_newstat+0x33/0x60
Aug 24 03:48:49 archbook kernel:  [] ?
exit_to_usermode_loop+0x5e/0xc0
Aug 24 03:48:49 archbook kernel:  [] ?
syscall_return_slowpath+0x4e/0x60
Aug 24 03:48:49 archbook kernel:  []
entry_SYSCALL_64_fastpath+0x1a/0xa4
Aug 24 03:48:49 archbook kernel: file.so D 880215733bb8 0  6447
   641 0x0004
Aug 24 03:48:49 archbook kernel:  880215733bb8 00ff8800a2fe1838
88021cab9c80 880220d463c0
Aug 24 03:48:49 archbook kernel:  880215733bc0 880215734000

[Spectacle] [Bug 363672] Save As dialog don't use default KDE dialog

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363672

--- Comment #7 from Nicolas Frattaroli  ---
As it turns out, that other bug now has different behaviour. Instead of
choosing the wrong MimeType filter, it now chooses no MimeType filter, which
means that the only functionality broken with the native dialog now is that it
doesn't hide everything except for image/png, which I believe to be a better
behaviour anyway.

At any rate, at least on my system (which is also Arch Linux), the native
dialog is more functional than the Qt dialog right now. Perhaps the native
dialog should be re-enabled again?

-- 
You are receiving this mail because:
You are watching all bug changes.

[Spectacle] [Bug 363672] Save As dialog don't use default KDE dialog

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363672

--- Comment #6 from Nicolas Frattaroli  ---
Eh, you having to do the work to add a compile time option for this and me
having to then maintain my own package seems not worth the effort when we could
both invest that time in fixing the actual bug (which, by the way, should be
marked as a blocker for this bug).

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-frameworkintegration] [Bug 357865] The QPA file dialog does not respect mime type filters

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357865

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC||kdeb...@fratti.ch

--- Comment #1 from Nicolas Frattaroli  ---
If I comment out dialog.setOption(QFileDialog::DontUseNativeDialog); in
spectacle for the native dialog, I see that the Save As mimetype filter is not
set to "image/png", but it's not set to image/bmp like the original report
appears to imply. Was the behaviour of this changed at some point without the
ticket being mentioned in the commit?

Also, arguably this makes this bug quite a bit less severe. The image now
properly is a PNG, it's just not filtered for image/png.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Spectacle] [Bug 363672] Save As dialog don't use default KDE dialog

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363672

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC||kdeb...@fratti.ch

--- Comment #4 from Nicolas Frattaroli  ---
Is there a compile-time option to change this? One of the bugs has been
resolved, and the other one seems to be stuck in limbo, and using the Qt file
dialog which doesn't have places and for me doesn't show any icons for some
reason is a bit obnoxious.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 346826] Konsole crash during destruction of XCB connection

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=346826

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC|kdeb...@fratti.ch   |

-- 
You are receiving this mail because:
You are watching all bug changes.

[akregator] [Bug 365714] New: Akregator tray icon is very low resolution on high DPI displays

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365714

Bug ID: 365714
   Summary: Akregator tray icon is very low resolution on high DPI
displays
   Product: akregator
   Version: unspecified
  Platform: Archlinux Packages
   URL: https://fratti.ch/bugdemos/akregator/akregatortray.png
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: kdeb...@fratti.ch

On high DPI displays, the tray icon Akregator shows appears to be an upscaled
low-resolution one. Both the icon and the number drawn on top of it look very
blocky.


Reproducible: Always




✓ fratti@archbook ~ $ akregator --version
akregator 5.2.3
✓ fratti@archbook ~ $ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis)
290mm x 170mm
   1920x1080 60.00*+  40.00  
   1400x1050 59.98  
   1600x900  60.00  
   1280x1024 60.02  
   1280x960  60.00  
   1368x768  60.00  
   1280x720  60.00  
   1024x768  60.00  
   1024x576  60.00  
   960x540   60.00  
   800x600   60.3256.25  
   864x486   60.00  
   640x480   59.94  
   720x405   60.00  
   640x360   60.00  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 365215] New: Animated tray icons cause plasmashell to use up a lot of CPU time

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365215

Bug ID: 365215
   Summary: Animated tray icons cause plasmashell to use up a lot
of CPU time
   Product: plasmashell
   Version: 5.6.5
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: System Tray
  Assignee: plasma-b...@kde.org
  Reporter: kdeb...@fratti.ch

Should a tray icon be animated, e.g. the quassel icon when receiving a
highlight, or the Skype icon while logging in, the "plasmashell" process takes
up a good 15% of the total CPU time (25% being maximum for one core), with
additional CPU time used by Xorg as well. (So it's probably busy sending tons
of drawing commands)

This is pretty bad when I receive a quassel highlight while I'm not looking,
and then notice that plasmashell was busy draining my battery doing
god-knows-what to re-render that small area on the screen.

Reproducible: Always

Steps to Reproduce:
1. Have a tray icon which is animated
2. Watch plasmashell shoot up in CPU usage



xf86-video-intel 2.99.917+674+g9154dff-1
xorg-server 1.18.3
no special optimus setup
compositing vsync prevention set to "automatic"

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated
Graphics Controller (rev 09)

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksysguard] [Bug 364978] New: ksysguard shows negative relative start time due to getting the timezone wrong

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364978

Bug ID: 364978
   Summary: ksysguard shows negative relative start time due to
getting the timezone wrong
   Product: ksysguard
   Version: 5.6.5
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: ksysguard
  Assignee: ksysguard-b...@kde.org
  Reporter: kdeb...@fratti.ch

On recently started processes, ksysguard claims they have been launched -1 day
and some hours ago. Hovering over the entry in the relative start time column
reveals that it believes it has been started one hour in the future (possibly
due to timezone or DST), and then makes a bogus calculation.

Reproducible: Always




# hwclock
2016-07-01 16:32:37.140183+1:00

# hwclock -c
hw-time  system-time freq-offset-ppm   tick 
1467383595   1467383595.038249  
1467383605   1467383605.03872748  0
^C

$ locale 
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

$ timedatectl
  Local time: Fri 2016-07-01 16:34:23 CEST
  Universal time: Fri 2016-07-01 14:34:23 UTC
RTC time: Fri 2016-07-01 14:34:23
   Time zone: Europe/Zurich (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

The output of ps -o start_time is actually the correct start time.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 350661] Kate crashes if block of text is indented multiple times at once in vi mode

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=350661

--- Comment #2 from Nicolas Frattaroli  ---
The behaviour changed in recent versions, apparently. Instead of crashing, it
now claims multiple indents are an invalid command.

1. i activates insert mode. hit i, write some text, multiple lines.
2. Then hit escape to leave insert mode.
3. Enter visual line selection mode by hitting Shift+V
4. Use the cursor or vi movement keys (h, j, k, l) to select multiple lines
5. Hit :
6. Hit > twice
7. Hit Enter

Note how it says unrecognised command now. In earlier versions, it would crash.

It can be worked around by instead of doing steps 5 to 7, simply typing the
number of places to indent and >, e.g. "2>"

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 364503] plasmashell freezes if system is I/O bound

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364503

Nicolas Frattaroli  changed:

   What|Removed |Added

Summary|plasmashell freezes is  |plasmashell freezes if
   |system is I/O bound |system is I/O bound

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 364503] New: plasmashell freezes is system is I/O bound

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364503

Bug ID: 364503
   Summary: plasmashell freezes is system is I/O bound
   Product: plasmashell
   Version: 5.6.5
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: kdeb...@fratti.ch
CC: bhus...@gmail.com, plasma-b...@kde.org

If the system is I/O bound, such as when removing a lot of files, or if there
is a hung SSH process of a remotely mounted sshfs, plasmashell will hang. In
the ksysguard process list, it shows up as being in "disk sleep". As soon as
the heavy I/O operation finishes (or the hung ssh process is terminated),
plasmashell becomes responsive again.

Reproducible: Always

Steps to Reproduce:
1. Remotely mount something through sshfs
2. Put your system to sleep for a few minutes
3. Wake the system, the ssh process should now be hanging. Shortly afterwards,
plasmashell should enter disk sleep.

Alternatively,
1. Grab the GCC source through SVN
2. Build GCC
3. Run a recursive rm operation on the folder, and attempt to interact with
plasmashell

Actual Results:  
plasmashell hangs until the I/O issue is resolved. For a stuck SSHFS mount,
this usually means that the associated SSH task needs to be killed. plasmashell
will not react to SIGKILL while it's in disk sleep mode.

Expected Results:  
plasmashell should have a timeout on non-essential I/O operations, or perform
blocking I/O in a separate thread, as to ensure that user interactivity is not
lost.

While this happened, a Dolphin window into the SSHFS mounted folder was opened.
This might be related, so I'll add it here.

The system uses a Kingston SSD connected through mSATA, and uses ext4 as both
the root and the /home file system.

While plasmashell is frozen, Ctrl+Escape for opening the system activity window
still works, however, Alt+F2 to bring up KRunner doesn't. The volume keys also
no longer work, which is a bit awkward when I click on a video and then notice
that plasmashell is frozen.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363847] New: Measure tool should also show angle and distance using a tooltip at the cursor position

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363847

Bug ID: 363847
   Summary: Measure tool should also show angle and distance using
a tooltip at the cursor position
   Product: krita
   Version: 3.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: usability
  Assignee: krita-bugs-n...@kde.org
  Reporter: kdeb...@fratti.ch

Currently, the measure tool will only show distance and angle measurements in
the tool options docker. Sometimes, people may not currently see this though as
they start measuring, and either get confused as to where the measurement is
displayed or get annoyed at having forgotten to tab to the right docker again
before starting to line up their cursor just right.

By adding a small hovering tooltip displaying the angle and the distance near
the cursor position, this could be made more intuitive and make for a smoother
workflow.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363846] New: Krita crashes if a second window with a view into the first window is closed

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363846

Bug ID: 363846
   Summary: Krita crashes if a second window with a view into the
first window is closed
   Product: krita
   Version: 3.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: kdeb...@fratti.ch

If a second window is opened, and assigned the view of the document in the
first window, and then said second window is closed, Krita will crash.

Reproducible: Always

Steps to Reproduce:
1. Create a new document
2. Go to Window->New Window
3. In said new window, go to Window->New View->Unnamed
4. Close the new window.

Actual Results:  
Krita will close both windows as it crashes

Expected Results:  
Only the second window closes

This crash only happens if the window is opened after creating the document,
apparently. If I create a new window first, then create a new document, then
switch to the second window and assign the view there and close it, it won't
crash.

Here's the backtrace

Application: Krita (krita), signal: Segmentation fault
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f57567aa800 (LWP 2659))]

Thread 5 (Thread 0x7f5734bd9700 (LWP 2661)):
#0  0x7f57535b268d in poll () from /usr/lib/libc.so.6
#1  0x7f574d39cfd6 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x7f574d39d0ec in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#3  0x7f57540e974b in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/libQt5Core.so.5
#4  0x7f57540914ca in
QEventLoop::exec(QFlags) () from
/usr/lib/libQt5Core.so.5
#5  0x7f5753eb82f3 in QThread::exec() () from /usr/lib/libQt5Core.so.5
#6  0x7f574dae6a65 in ?? () from /usr/lib/libQt5DBus.so.5
#7  0x7f5753ebd1d8 in ?? () from /usr/lib/libQt5Core.so.5
#8  0x7f574d8bb474 in start_thread () from /usr/lib/libpthread.so.0
#9  0x7f57535bb69d in clone () from /usr/lib/libc.so.6

Thread 4 (Thread 0x7f571e78e700 (LWP 2662)):
#0  0x7f574d8c109f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f5753ebe08b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f5753eb6d53 in QSemaphore::acquire(int) () from
/usr/lib/libQt5Core.so.5
#3  0x7f57519540dd in ?? () from /usr/lib/libkritaimage.so.15
#4  0x7f5753ebd1d8 in ?? () from /usr/lib/libQt5Core.so.5
#5  0x7f574d8bb474 in start_thread () from /usr/lib/libpthread.so.0
#6  0x7f57535bb69d in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7f571df8d700 (LWP 2663)):
#0  0x7f574d8c109f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f5753ebe08b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f5753eb7046 in QSemaphore::tryAcquire(int, int) () from
/usr/lib/libQt5Core.so.5
#3  0x7f575197039a in KisTileDataSwapper::run() () from
/usr/lib/libkritaimage.so.15
#4  0x7f5753ebd1d8 in ?? () from /usr/lib/libQt5Core.so.5
#5  0x7f574d8bb474 in start_thread () from /usr/lib/libpthread.so.0
#6  0x7f57535bb69d in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7f571d78c700 (LWP 2665)):
#0  0x7f574d8c109f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f5753ebe08b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f5754fed139 in ?? () from /usr/lib/libQt5Widgets.so.5
#3  0x7f5753ebd1d8 in ?? () from /usr/lib/libQt5Core.so.5
#4  0x7f574d8bb474 in start_thread () from /usr/lib/libpthread.so.0
#5  0x7f57535bb69d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f57567aa800 (LWP 2659)):
[KCrash Handler]
#5  0x7f5753091ee0 in KisBrush::scale() const () from
/usr/lib/libkritalibbrush.so.15
#6  0x7f5729e6d4a2 in
KisBrushBasedPaintOpSettings::brushOutlineImpl(KisPaintInformation const&,
KisPaintOpSettings::OutlineMode, double, bool) const () from
/usr/lib/libkritalibpaintop.so.15
#7  0x7f5729e6da38 in
KisBrushBasedPaintOpSettings::brushOutline(KisPaintInformation const&,
KisPaintOpSettings::OutlineMode) const () from
/usr/lib/libkritalibpaintop.so.15
#8  0x7f57560a511a in KisToolFreehandHelper::paintOpOutline(QPointF const&,
KoPointerEvent const*, KisPaintOpSettings const*,
KisPaintOpSettings::OutlineMode) const () from /usr/lib/libkritaui.so.15
#9  0x7f575609fba1 in KisToolFreehand::getOutlinePath(QPointF const&,
KoPointerEvent const*, KisPaintOpSettings::OutlineMode) () from
/usr/lib/libkritaui.so.15
#10 0x7f57560acb1a in KisToolPaint::requestUpdateOutline(QPointF const&,
KoPointerEvent const*) () from /usr/lib/libkritaui.so.15
#11 0x7f5750fb93e0 in KoToolProxy::mouseMoveEvent(QMouseEvent*, QPointF
const&) () from /usr/lib/libkritaflake.so.15
#12 

[okular] [Bug 360830] New: Implement high quality scaling filters for pages

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360830

Bug ID: 360830
   Summary: Implement high quality scaling filters for pages
   Product: okular
   Version: unspecified
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: kdeb...@fratti.ch

Currently, pages are scaled with what appears to be bilinear filtering. While
fast, this can often result in a blurry picture. While this isn't too much of
an issue when reading a PDF document, it can be pretty annoying when reading
small text in a CBZ that's zoomed in to fit the page width.

Examples for scaling filters can be found in mpv's documentation:
https://mpv.io/manual/stable/#video-output-drivers-bilinear

I'd suggest Mitchell-Netravali, here's a PDF of the paper I found:
www.cs.utexas.edu/users/fussell/courses/cs384g/lectures/mitchell/Mitchell.pdf

Additionally, the current bilinear interpolation should be done using GPU
accelaration if available, if this isn't already the case, for performance and
power saving purposes.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 360526] New: Gwenview needs a long time to close when viewing a kdeconnect sftp image directly

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360526

Bug ID: 360526
   Summary: Gwenview needs a long time to close when viewing a
kdeconnect sftp image directly
   Product: gwenview
   Version: Git (add output of "git log -1 --oneline" to
description)
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: gwenview-bugs-n...@kde.org
  Reporter: kdeb...@fratti.ch
CC: myr...@kde.org

When opening an image which is accessed over kdeconnect's sftp functionality by
either double-clicking the file in Dolphin or opening it directly by passing it
as a parameter to gwenview on the command line, gwenview will need a long time
to close when the X on the window is hit. Long enough to trigger the KDE hung
application dialogue.

Surprisingly, if one navigates to said folder from within gwenview and opens an
image, gwenview shuts down just fine.

It seems that gwenview might be waiting on some redundant filesystem operation
to complete when closing.

Version information:
gwenview:
$ git log -1 --oneline
c8edede SVN_SILENT made messages (after extraction)
kdeconnect:
kdeconnect 0.9.g-1

Reproducible: Always

Steps to Reproduce:
1. Install kdeconnect on an Android phone and on your desktop.
2. Enable "Remote filesystem browser"
3. Browse the remote filesystem of your phone with dolphin
4. From within dolphin, open an image on your phone in gwenview
5. Click on the close window button.

Actual Results:  
gwenview needs around 20 seconds to close the window

Expected Results:  
gwenview closes instantly

This seems to not happen with things mounted over sshfs.

I have not tried reproducing with SFTP mounts other than kdeconnect's.
Both devices are connected to wifi.

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 353240] Day numbers are cropped at the bottom in month view in korganizer

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=353240

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC||kdeb...@fratti.ch

--- Comment #1 from Nicolas Frattaroli  ---
Same issue here on a 168 DPI monitor, Arch Linux, KOrganizer 15.12.1 (version
number in "About KOrganizer->Version" shows "5.1.1" and using frameworks
5.18.0)

The font sizes in the month view appear to be too big in general.

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 352645] kOrganizer 15.08.1-pre: Multiple issues with categories cause a huge mess and make using categories basically impossible

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352645

Nicolas Frattaroli  changed:

   What|Removed |Added

 CC||kdeb...@fratti.ch

--- Comment #7 from Nicolas Frattaroli  ---
I can also confirm this, assigning several ToDo items the same category
apparently makes duplicates of said category as well.

Arch Linux, Version 15.12.1
Help->About KOrganizer->Version mentions "Version 5.1.1", KDE Frameworks
5.18.0, Qt 5.5.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 353240] Day numbers are cropped at the bottom in month view in korganizer

[Nicolas Frattaroli via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=353240

--- Comment #2 from Nicolas Frattaroli  ---
Created attachment 97091
  --> https://bugs.kde.org/attachment.cgi?id=97091=edit
Screenshot of the monthly calendar view

-- 
You are receiving this mail because:
You are watching all bug changes.