[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #7 from Martin Steigerwald  ---
Created attachment 101723
  --> https://bugs.kde.org/attachment.cgi?id=101723=edit
kscreen kcm after resuming

It completely lost state. Laptop display is disabled *and* not on the left of
the external display anymore.

After more testing I find that it does not happen on every suspend. And I have
a theory:

It might be a timing issue. I see that on closing the laptop it switched off
the laptop screen and *then* after some delay suspended. Maybe kscreen recorded
switching off the laptop display before the suspend started and now restores to
exactly this state. I don´t know whether the kscreen.log would reveal such a
timing issue.

However as I user I never *ever* want kscreen to disable my laptop screen *at
all*. There may be users who close the lid to only use external displays
however. And also users who don´t want laptop display switched on when using a
beamer. My own expectation is this: Whenever laptop display lid is open display
something there. Well actually remember the last configuration, which at some
and at work for me means: On the left is laptop display, on the right is
external display. Period. No discussions whatsoever asked for.

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

[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #5 from Martin Steigerwald  ---
Created attachment 101690
  --> https://bugs.kde.org/attachment.cgi?id=101690=edit
kscreen-console bug after enabling laptop display

This is the state I desire after resuming.

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

[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #6 from Martin Steigerwald  ---
Created attachment 101691
  --> https://bugs.kde.org/attachment.cgi?id=101691=edit
kscreen.log after enabling laptop display again

and moving it to the left side (instead of clone mode) as it was before. This
is the state I had before suspend and the state I desire to see after suspend.

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

[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #4 from Martin Steigerwald  ---
martin@merkaba:~> kscreen-doctor output.LVDS-1.enable
Enabling output 65
kscreen.doctor: setop exec returned

works, but enabled LVDS in clone mode. So it seems that kscreen completely
forgot that the laptop screen is left to the external screen. Before fiddling
further with kscreen-doctor arguments I fixed this using systemsettings kscreen
kcm.

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

[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
Created attachment 101687
  --> https://bugs.kde.org/attachment.cgi?id=101687=edit
kscreen.log

It appears to me that for whatever reason kscreen does not activate the second
output:

21.10.2016 17:35:39.548 ; kded ;  : KScreen::Output( 72   "DP-3" connected
enabled QPoint(0,0) QSize(1920, 1080) "112" )
21.10.2016 17:35:39.631 ; kscreen ;  : Requesting missing EDID for outputs (65,
72)
21.10.2016 17:44:54.258 ; kcm ;  : LOAD
21.10.2016 17:44:54.409 ; kcm ;  : Activate output 66

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

[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #3 from Martin Steigerwald  ---
Created attachment 101689
  --> https://bugs.kde.org/attachment.cgi?id=101689=edit
kscreen-console bug directly after resume

Dunno what it wanted to parse from kscreen.log, but I attached this separately
already.

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

[KScreen] [Bug 371447] laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #2 from Martin Steigerwald  ---
Created attachment 101688
  --> https://bugs.kde.org/attachment.cgi?id=101688=edit
kscreen-doctor -i --json after resume

internal laptop display LVDS-1 (65) is disabled.

However according to kscreen log it tries to activate output 66 (VGA) which
does not make any sense:

21.10.2016 17:35:39.548 ; kded ;  : KScreen::Output( 65   "LVDS-1" connected
disabled QPoint(0,0) QSize(1920, 1080) "" )
21.10.2016 17:35:39.548 ; kded ;  : KScreen::Output( 72   "DP-3" connected
enabled QPoint(0,0) QSize(1920, 1080) "112" )
21.10.2016 17:35:39.631 ; kscreen ;  : Requesting missing EDID for outputs (65,
72)
21.10.2016 17:44:54.258 ; kcm ;  : LOAD
21.10.2016 17:44:54.409 ; kcm ;  : Activate output 66

I, of course want output 65 and 72 enabled. 72 (the external display) is, but
65 isn´t.

Output: 65 LVDS-1 disabled connected  Panel Modes: 100:700x525@120
101:640x512@120 102:720x450@120 103:640x480@120 104:640x480@60 105:680x384@120
106:680x384@120 107:576x432@120 108:512x384@120 109:400x300@121 110:400x300@113
111:320x240@120 74:1920x1080@60! 75:1920x1080@60 76:1920x1080@50
77:1680x1050@60 78:1680x1050@60 79:1600x1024@60 80:1400x1050@60 81:1280x1024@60
82:1440x900@60 83:1280x960@60 84:1360x768@60 85:1360x768@60 86:1152x864@60
87:1024x768@120 88:1024x768@60 89:960x720@120 90:928x696@120 91:896x672@120
92:960x600@120 93:960x540@120 94:800x600@120 95:800x600@60 96:800x600@56
97:840x525@120 98:840x525@120 99:800x512@120 Geometry: 0,0 0x0
Output: 66 VGA-1 disabled disconnected  VGA Modes: Geometry: 0,0 0x0
Output: 67 HDMI-1 disabled disconnected  HDMI Modes: Geometry: 0,0 0x0
Output: 68 DP-1 disabled disconnected  DisplayPort Modes: Geometry: 0,0 0x0
Output: 69 HDMI-2 disabled disconnected  HDMI Modes: Geometry: 0,0 0x0
Output: 70 HDMI-3 disabled disconnected  HDMI Modes: Geometry: 0,0 0x0
Output: 71 DP-2 disabled disconnected  DisplayPort Modes: Geometry: 0,0 0x0
Output: 72 DP-3 enabled connected  DisplayPort Modes: 104:640x480@60
112:1920x1080@60*! 113:1920x1080@50 114:1920x1080@50 115:1920x1080@60
116:1920x1080@30 117:1920x1080@25 118:1920x1080@30 119:1600x900@60
120:1280x1024@75 121:1280x720@60 122:1280x720@50 123:1280x720@60
124:1024x768@75 125:800x600@75 126:720x576@50 127:720x480@60 128:720x480@60
129:640x480@75 130:640x480@60 131:720x400@70 77:1680x1050@60 81:1280x1024@60
82:1440x900@60 88:1024x768@60 95:800x600@60 Geometry: 0,0 1920x1080

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

[KScreen] [Bug 371447] New: laptop screen disabled after resume from suspend to RAM

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 371447
   Summary: laptop screen disabled after resume from suspend to
RAM
   Product: KScreen
   Version: 5.8.2
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: common
  Assignee: se...@kde.org
  Reporter: mar...@lichtvoll.de

With newest KScreen 5.8.2-1 (as packaged in Debian Sid) laptop screen is
disabled after resume from suspend to RAM (probably also suspend/hibernation to
disk). This didn´t happen with previous version 5.8.0 and I think also not
5.8.1 (not completely sure on that one)


Reproducible: Always

Steps to Reproduce:
1. Have laptop + external display.
2. Suspend to RAM by closing lid.
3. Resume

Actual Results:  
Laptop display is switched off.

Expected Results:  
Laptop display is switched on as it was before suspending.

ThinkPad T520 with Full HD internal and Full HD external display connected
through docking station. I will add further debug output as attachments.

> phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, Disk:
300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd Generation
Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, Network: Intel
82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-tp520-btrfstrim+ (x86_64), Desktop: KDE
Frameworks 5, Display Server: X Server 1.18.4, Display Driver: modesetting
1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161019, File-System:
btrfs, Screen Resolution: 3840x1080

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

[ksmserver] [Bug 368686] frozen session after swiching sessions when using two sessions

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de

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

[ksmserver] [Bug 368686] New: frozen session after swiching sessions when using two sessions

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 368686
   Summary: frozen session after swiching sessions when using two
sessions
   Product: ksmserver
   Version: 5.7.3
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: l.lu...@kde.org
  Reporter: martin.steigerw...@teamix.de

Using Plasma 5.7.4 on KF 5.25.

I use two Plasma sessions. One for the private user on tty7 and one for the
work related user on tty8. On work breaks I switch between sessions.

Sometimes it happens that either the work related or the private session is
"frozen" then (see below).

I seek help what I can do to find out what is going wrong with that frozen
session in order to provide more helpful details for this bug report.


Reproducible: Always

Steps to Reproduce:
1. Have to Unix users
2. Use two Plasma sessions
3. After a while switch between them

Note, it does not happen all the time.

Actual Results:  
Sometimes it happens that either the work related or the private session is
frozen then. "Frozen" means: It does not react to any user input. I cannot move
windows, I cannot open menus, I cannot type text.

I want to get back to work with the session quickly then, thus I then try to
stop all processes of the "frozen" session from the other, still working
session.

Like this:

merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser
merkaba:~> killall -u workuser

Yet ksmserver remains:

merkaba:~> ps aux | grep workuser
root45  0.0  0.0  0 0 ?S<   09:51   0:00 [vmstat]
privateuser2263  0.0  0.0  70088  4880 ?S09:51   0:00 kwrapper5
/
usr/bin/ksmserver
privateuser2264  0.0  0.1 618136 28000 ?Sl   09:51   0:00 /usr/bin/
ksmserver
workuser   21169  0.0  0.0 618160  9148 ?S13:21   0:00
/usr/bin/
ksmserver
root 21303  0.0  0.0  12724  1028 pts/0S+   13:21   0:00 grep workuser

And only goes away after:

merkaba:~> killall -9 -u workuser

Expected Results:  
Both sessions keep working over the whole duration I use them.

This happens regardless of whether I use the Intel xorg driver or as recently
the modesetting driver. On Debian Unstable on this ThinkPad T520:

> phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, Disk:
300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd Generation
Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, Network: Intel
82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-rc6-tp520-btrfstrim+ (x86_64), Desktop: KDE
Frameworks 5, Display Server: X Server 1.18.4, Display Driver: modesetting
1.18.4, OpenGL: 3.3 Mesa 12.0.2, Compiler: GCC 6.2.0 20160901, File-System:
btrfs (ecryptfs), Screen Resolution: 3840x1080

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

[Akonadi] [Bug 367892] During folder synchronisation Akonadi blocks out other operations like deleting or viewing mails

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #4 from Martin Steigerwald  ---
Hello Daniel. I am talking about the visible response in KMail. I did not check
if there is something happening on the IMAP server. For IMAP, in company with
Exchange, but I also tested with Dovecot IMAP on my private server, it is
really easy to trigger here: Hit delete key on mails in the same folder until
Akonadi starts folder synchronization. Then hit delete key again. KMail will
grey out the mail, but only remove it from the list after folder
synchronization is complete. To me it seems like Akonadi postpones any
interactive user requests until a folder synchronization is complete.

For me two things don´t make sense:

1) Why does it synchronize the folder anyway when I hit delete the folder mail
list several times? To make sure the IMAP server has done its work?

2) Postponing user input just leads to user frustration. As a user I expect
Akonadi to handle background tasks like folder synchronization as background
tasks.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #30 from Martin Steigerwald  ---
I just created

Bug 367892 - During folder synchronisation Akonadi blocks out other operations
like deleting or viewing mails

for blocking out other operations during folder synchronisation. Gunther, if
you feel like adding anything there, please do so. Please keep this bug to the
actual synchronisation performance from now on as per the title of the bug.

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

[Akonadi] [Bug 367892] During folder synchronisation Akonadi blocks out other operations like deleting or viewing mails

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #1 from Martin Steigerwald  ---
For the Maildir case this is just a minor annoyance as folder synchronisation
is pretty fast with Akonadi 16.04. But with IMAP this can easily cause delays
of a minute or more on large folders.

Gunther talks about 87 seconds for a Sent folder of 41000 mails in comment 18
of bug 338571 with a local !() IMAP server (see
https://bugs.kde.org/show_bug.cgi?id=338571#c18). I can easily can trigger
stalls of a minute or more with a remote Dovecot and folders of about
1-25000 mails. 

Bug #338571 is about the performance of the IMAP folder synchronisation itself.
This bug is about blocking out other operations during folder synchronisation.

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

[Akonadi] [Bug 367892] New: During folder synchronisation Akonadi blocks out other operations like deleting or viewing mails

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 367892
   Summary: During folder synchronisation Akonadi blocks out other
operations like deleting or viewing mails
   Product: Akonadi
   Version: 16.04
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: server
  Assignee: kdepim-b...@kde.org
  Reporter: mar...@lichtvoll.de

This is a split out from Bug #338571 (See comment 28 there
https://bugs.kde.org/show_bug.cgi?id=338571#c28).

During folder synchronisation KMail blocks out other operations. This causes
delays for the user of KMail when the folder synchronisation takes a long time.
This happens with IMAP and Maildir resources at least. I bet it would happen
with any resource.

Reproducible: Always

Steps to Reproduce:
IMAP:
1. Have some IMAP folder large enough (several ten thousand mail).
2. Hit delete key on mails in the folder mail list often enough, probably with
pauses to trigger a folder synchronisation. (Do so with a mails you can afford
to delete only of course!)

Maildir:
1. Have a POP3 account with mails from mailings or so and with filters sorting
them into different folders.
2. Download new mail.
3. Maildir resource starts to synchronize (I think this is unnecessary as well,
see bug 334216).

Of course there are other ways to trigger a folder synchronisation but these
worked quite reliably for me.

Then both Maildir and IMAP:
1. Do some operations like deleting or viewing mails while Akonadi is still
busy with the folder synchronisation.

Actual Results:  
Akonadi blocks on other operations. Operations that are more important for the
user I think, cause the other waits for KMail to view or delete mails, but it
does not until Akonadi is responsive again.

Expected Results:  
Akonadi can handles several operations at the same time. Bonus points if it
prioritizes short term interactive user requests over longer time background
operations.

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

[Akonadi] [Bug 279380] akonadi_mixedmaildir_resource crashes when synchronizing a folder with a large number of emails

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|--- |UNMAINTAINED
 CC||mar...@lichtvoll.de
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Steigerwald  ---
Shane, thank you for your report. It is about an ancient version of KMail which
is not maintained anymore. Also neither with Maildir nor with IMAP resource I
see any crashes on folder synchronisation. Thus I close this.

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

[kmail2] [Bug 307064] Mail folders "synchronized" once again every time it is opened

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|--- |UNMAINTAINED
 CC||mar...@lichtvoll.de
 Status|CONFIRMED   |RESOLVED

--- Comment #2 from Martin Steigerwald  ---
Hello Marcel. Thank you for your report. It is about an ancient version of
KMail. 

Akonadi developers implemented a lot of performance improvements for maildir
resource, and I think at least partly also for mixedmaildir resource and also
in general Akonadi folder synchronisation performance. Thus I close the report.

 If you still see this with KMail/Akonadi 16.04, tell me and I will reopen it.
Thank you, Martin

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

[Akonadi] [Bug 334216] synchronizes folder with filesystem after downloading and filtering mails needlessly

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
This still happens with KMail/Akonadi 16.04. Its not nearly as annoying as
Akonadi maildir resource is much faster now on synchronisation folders. Its
still synchronizing although it should know which mails mailfilter agent just
moved to a different folder, instead of asking the filesystem about it.

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

[Akonadi] [Bug 334209] synchronizes folder contents during runtime needlessly

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Martin Steigerwald  ---
I do not see this anymore on KMail/Akonadi 16.04 during switching folders. Thus
closed.

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

[Akonadi] [Bug 334206] While IMAP/maildir resource synchronizes a folder KMail blocks on switching to a different folder

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|REOPENED|RESOLVED
Summary|While maildir resources |While IMAP/maildir resource
   |synchronizes a folder KMail |synchronizes a folder KMail
   |blocks on switching to a|blocks on switching to a
   |different folder|different folder

--- Comment #9 from Martin Steigerwald  ---
Nope forget this. I made up a my mind. Thats no blockage on switching folders
and I don´t have this anymore. So… I make another bug report about folder
synchronisation blocking other operations. Sorry for noise.

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

[Akonadi] [Bug 334206] While maildir resources synchronizes a folder KMail blocks on switching to a different folder

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #8 from Martin Steigerwald  ---
Well, I closed this back then as it works for me as the folder synchronisation
in the maildir case got much better by the performance improvements made by Dan
and Millian. Yet, the issue is still there, I tested it on deleting 100-200
mails during mailfilter agent filtering mails to local maildir folders and
triggering folder synchronisations. Akonadi postponed the deleting until after
those few quite quick synchronisations were finished, but it easily took about
10 seconds, so that still introduces an delay.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #29 from Martin Steigerwald  ---
Okay, nope changing the title on the bug report I mentioned on the third issue
doesn´t make sense. I don´t see this bug anymore since performance improvements
made by Dan and Millian. It makes sense to split out the IMAP case, i.e. report
"During folder synchronisation Akonadi blocks out other operations like
deleting or viewing mails" for the IMAP case if not already done.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #28 from Martin Steigerwald  ---
There seem to be three issues in what you observe:

1) There is folder synchronisation when you enter a folder and click mails in
there to read them. I don´t have that and for me this operation is, except for
few second initial delay to open the folder (any eventual threading work of
KMail not counted), instant or almost instant. That may be something for a
different bug report to keep that one to the performance on folder
synchronisation itself. For Maildir I did a bug report about IMHO superfluous
synchronisation (bug #334209). For any excessive folder synchronisation reading
mails, if you really see this, this would be worth a different bug. But maybe
what you see is the initial folder synchronisation on after you switched to the
folder that you see there. Does it really synchronize the folder again and
again when reading mails in it? Then I would report this as a different bug (if
not already done by someone).


2) As per the title you choose folder synchronisation itself taking a lot of
time. And well I can see this here as well. Its easily taking up half a minute
or more. And generating a lot of queries. Its not creating much load on my
MySQL, but that may be due to creating a lot of load to my IMAP server. I see
both mysqld at about 20% of one core and akonadi_imap_resource at about 30% of
one core. Now your IMAP is local, and thus will be faster to access and that I
think easily explains the higher MySQL load you see. Actually synchroniszing
that 24500 mail inbox folder took as much time as typing all of this second
point. Easily more than a minute.


3) During folder synchronisation Akonadi blocks out other operations like
deleting or viewing mails. I reported this as:

[Akonadi] [Bug 334206] New: While maildir resources synchronrizes a folder
KMail blocks on switching to a different folder

and will change the title of the bug IMAP resources as well now. I bet it may
affect *any* resources.

I suggest to keep this report about the actual folder synchronisation speed
from now on for clarity.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #27 from Martin Steigerwald  ---
Created attachment 100801
  --> https://bugs.kde.org/attachment.cgi?id=100801=edit
excerpt of query log for folder synchronisation after deleting mails

I sometimes need to delete quite a bunch of mails to trigger a folder
synchronisation that takes long. But I made it. I made 2 second excerpt of the
log, and I agree with you, Gunther: The amount of queries made in this short
time is excessive.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #25 from Martin Steigerwald  ---
Okay, I seriously don´t get why its so different for you: One folder with about
1 mails about one second with cold caches and one with more than 24000
mails about 2-3 seconds with cold caches. This time on Dovecot based IMAP.
Regular IMAP, not disconnected. You do have double the amount of mails than the
larger one of my folders, Gunther, but opening your sent folder takes about
30-40 times longer than on my system.

So there is hope to fix your issue, I think, once it is clear what is causing
the high load on your system. I wonder how to find whats different tough. Care
to share more details of your setup? Also… do you have any search folders that
target mails of your sent folder?

My IMAP account setup is very basic. I just pointed it to my Dovecot IMAP, and
then let it autodetect the encryption. Thats it. No customizations so far. So
what you could try would be: Use a *new* user, recreate IMAP account from
scratch. And try then. Also are there any errors Akonadi shows in
~/.xsession-errors or Akonadi error log. Are there any errors in MySQL log?

Okay, just reading your mid air collision comment as well: So you have local
IMAP, that should be even faster. I also tried clicking folder and then
clicking mails. Its just instant with warm caches, i.e. folder already opened
before. Okay, and even with cold caches, after the initial delay of 1-3 seconds
and maybe an added second its instant. I click mail and its done. IMAP resource
doesn´t synchronize the folder on my setup when clicking mails in a folder that
it synchronized initially after starting it. What I know is that it does when
deleting mail and this can cause quite some slow downs, but not when reading
mails. So are you doing any other changes to the mail other than KMail setting
read flag on them?

I can reproduce huge delays when entering inbox for example and then hit delete
10-20 times. But but its not that MySQL heavy. It is just that Akonadi IMAP for
some reason resynchronizes folder content after deleting a mail. So I think
that is a different issue.

Okay, will post about query logs in next comment.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #26 from Martin Steigerwald  ---
Created attachment 100800
  --> https://bugs.kde.org/attachment.cgi?id=100800=edit
excerpt of query log, clicking mails in open folders for some seconds

This is what is almost instant on my machine.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #23 from Martin Steigerwald  ---
Hmmm, okay, now I notice there is an important difference. I tested this
against a local maildir resource, not with IMAP. I think… I bet that may cause
a difference in MySQL load. Do you use disconnected IMAP or regular IMAP? I
only have Exchange IMAP at work and it doesn´t make sense to test with it, as
with Exchange IMAP implementation its not really possible to access large
folders via IMAP consistently, not even with Trojita.

>From what I remember when I still had a kind of 1-2 week IMAP (maildir on
server cleaned by find -delete) access to folders have been quite snappy. I am
trying to reproduce it now by recreating the IMAP account. Akonadi still has to
synchronize on of the larger folders, so takes a time till I can test.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #22 from Martin Steigerwald  ---
Gunther, I am not sure what is going on on your system, cause when I access a
76000 mails folder it takes about 8 seconds to actually see KMail showing the
first mails and starting the threading operation. Or another example: About 10
seconds to access debian-devel-changes folder with slightly more than 133000
messages, this time flat view without threading. I don´t see why this couldn´t
even be faster… but its quite a bit faster from what you report.

This all after akonadictl stop, echo 3 > /proc/sys/vm/drop_caches, akonadictl
start, so without any in memory caching on a ThinkPad T520 Sandybridge i5, 2.5
to max 3.2 GHz, machine with Dual SSD BTRFS RAID 1. I use MariaDB 10.0.26, but
I don´t think it makes much of a difference to MySQL.

mysqld load a mere 60-80% for some of this time. I did not create a query log.
How did you create it, I may create one so we can compare whether on my setup
Akonadi does something different. Then after the MySQL activity KMail was at
about 80% on one core for a few seconds.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #19 from Martin Steigerwald  ---
Gunter, how big is your sent folder? How many mails are in there.

And, I am not sure whether it has been mentioned already, but my better
experience may (!) be related to some manual MySQL tuning. Especially:

# memory buffer InnoDB uses to cache data and indexes of its tables
(default:128M)
# Larger values means less I/O
innodb_buffer_pool_size=1024M

I have no scientific measurement, but I think I noticed slowdowns as after an
upgrade of Akonadi its replaced that file with a newer one. I made a bug report
about this quite some time ago, but the a dev declined my suggestion to raise
the ridiculously low 64M I think default to something higher with the argument
the configuration came from I think Kristian Köhntopp so it must be right.
Also, and I get that, there are smaller mail setups as well. From what I
understand about MySQL performance tuning, the default value set by Akonadi
MySQL standard config is way to low for larger setups. mysqltuner.pl agrees
there as well. I suggest you run mysqltuner against the socket of the Akonadi
database and then review the suggestions it makes. I am pretty sure it will
tell you to raise the InnoDB buffer pool size considerably.

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

[Akonadi] [Bug 367708] [Exchange 2013] Saving sent mail to IMAP folder: A000007 BAD Command Argument Error. 12 on UID STORE without parameters

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

Summary|[Exchange 2013] Error on|[Exchange 2013] Saving sent
   |saving sent mail to IMAP|mail to IMAP folder:
   |folder: A07 BAD Command |A07 BAD Command
   |Argument Error. 12  |Argument Error. 12 on UID
   ||STORE without parameters

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

[Akonadi] [Bug 367708] [Exchange 2013] Error on saving sent mail to IMAP folder: A000007 BAD Command Argument Error. 12

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
I intend to try to access Exchange server directly instead of by proxy to
determine whether its a proxy issue.

I also created IMAP log. Here is what I think the relevant excerpt of it:

C: A22 SELECT "INBOX"
S: * 380 EXISTS
S: * 0 RECENT
S: * FLAGS ( \Seen \Answered \Flagged \Deleted \Draft $MDNSent )
S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Answered \Flagged \Deleted
\Draft $MDNSent )  ]
S: * OK Is the first unseen message [ UNSEEN 251  ]
S: * OK UIDVALIDITY value [ UIDVALIDITY 14  ]
S: * OK The next unique identifier value [ UIDNEXT 21544  ]
S: A24 OK SELECT completed. [ READ-WRITE  ]
C: A25 APPEND "Sent Items" (\Seen) "23-Aug-2016 10:02:29 +" {464}
S: + Ready for additional command text.
C: From: Martin Steigerwald <[…]@teamix.de>
To: Martin <[…]@teamix.de>
Subject: Testmail
Date: Tue, 23 Aug 2016 12:02:29 +0200
Message-ID: <1732774.ZES84pjKtC@merkaba>
Organization: teamix GmbH
X-KMail-Identity: […]
X-KMail-Dictionary: de
User-Agent: KMail/5.2.3 (Linux/4.8.0-rc2-tp520-btrfstrim+; KDE/5.23.0; x86_64;
; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
S: A25 OK APPEND completed. [ APPENDUID 11 2420  ]
C: A26 SELECT "Sent Items"
S: * 2379 EXISTS
S: * 1 RECENT
S: * FLAGS ( \Seen \Answered \Flagged \Deleted \Draft $MDNSent )
S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Answered \Flagged \Deleted
\Draft $MDNSent )  ]
S: * OK Is the first unseen message [ UNSEEN 1921  ]
S: * OK UIDVALIDITY value [ UIDVALIDITY 11  ]
S: * OK The next unique identifier value [ UIDNEXT 2421  ]
S: A26 OK SELECT completed. [ READ-WRITE  ]
C: A27 UID STORE 2420 +FLAGS (\Seen)
S: * 2379 FETCH ( FLAGS (\Seen \Recent) )
S: A27 OK STORE completed.
C: A28 UID STORE 2420
S: A28 BAD Command Argument Error. 12
C: A29 UID STORE 2420
S: A29 BAD Command Argument Error. 12
C: A30 SELECT "INBOX"
S: * 381 EXISTS
S: * 0 RECENT
S: * FLAGS ( \Seen \Answered \Flagged \Deleted \Draft $MDNSent )
S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Answered \Flagged \Deleted
\Draft $MDNSent )  ]
S: * OK Is the first unseen message [ UNSEEN 251  ]
S: * OK UIDVALIDITY value [ UIDVALIDITY 14  ]
S: * OK The next unique identifier value [ UIDNEXT 21545  ]

It seems either proxy or Exchange does not like the additional UID STORE
commands. Why Akonadi issues UID STORE mutiple times (I am no expert of IMAP
protocol).

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

[Akonadi] [Bug 367708] New: [Exchange 2013] Error on saving sent mail to IMAP folder: A000007 BAD Command Argument Error. 12

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 367708
   Summary: [Exchange 2013] Error on saving sent mail to IMAP
folder: A07 BAD Command Argument Error. 12
   Product: Akonadi
   Version: 16.04
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: IMAP resource
  Assignee: chrig...@fastmail.fm
  Reporter: martin.steigerw...@teamix.de
CC: kdepim-b...@kde.org, vkra...@kde.org

After I sent a mail I receive the notifications:

Speichern fehlgeschlagen, die Serverantwort lautet: A07 BAD Command
Argument Error. 12

sometimes also after that:

Die Verbindung zum Server ist abgebrochen.

The mails are saved nonetheless.

Setup is Akonadi/KMail 4:16.04.3-2 from Debian unstable with Exchange 2013
behind Nginx proxy. Akonadi/KMail is configured to store sent mail in IMAP
folder on that account.

Reproducible: Always

Steps to Reproduce:
1. Have Exchange 2013, probably behind Nginx proxy.
2. Setup IMAP and SMTP.
3. Set it up to store sent mails in folder "Sent Items."
4. Send a mail.

Actual Results:  
After I sent a mail I receive the notifications:

Speichern fehlgeschlagen, die Serverantwort lautet: A07 BAD Command
Argument Error. 12 => Saving failed, server answer is: …

sometimes also after that:

Die Verbindung zum Server ist abgebrochen. => Connection to server aborted.

In ~/xsession-errors I also get:

kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/smtp.so'
from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/smtp.so'
Cannot pause an inactive timer
"Der Name des Hosts ist keiner aus der Liste der für dieses Zertifikat gültigen
Hosts" => THe name of the host is in not from the list of the hosts that are
valid for this certificate.
log_kimap: We asked for UID but the server didn't give it back, resultingFlags
not stored.
log_imapresource: Flag append failed:  "Speichern fehlgeschlagen, die
Serverantwort lautet: A07 BAD Command Argument Error. 12 " => Saving
failed, server answer is: …
log_imapresource: Flag remove failed:  "Speichern fehlgeschlagen, die
Serverantwort lautet: A08 BAD Command Argument Error. 12 "
Database "akonadi" opened using driver "QMYSQL"

And sometimes instead:

log_kimap: We asked for UID but the server didn't give it back, resultingFlags
not stored.
log_imapresource: Flag append failed:  "Speichern fehlgeschlagen, die
Serverantwort lautet: A11 BAD Command Argument Error. 12 "
log_imapresource: Flag remove failed:  "Die Verbindung zum Server ist
abgebrochen." => Connection to server aborted.
"Der Name des Hosts ist keiner aus der Liste der für dieses Zertifikat gültigen
Hosts"
kdeinit5: PID 8816 terminated.
kdeinit5: PID 8822 terminated.

(not sure whether the last two are related)


Expected Results:  
No error message and no occasional connection abort.

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

[Akonadi] [Bug 364114] moving a folder within one maildir resource is extremely slow and inefficient

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #5 from Martin Steigerwald  ---
https://phabricator.kde.org/T630

is somewhat related.

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

[kmail2] [Bug 170425] Detach attachments (save, remove, and link) from email

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de
 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #6 from Martin Steigerwald  ---
 I can confirm that I see no way to remove an attachment from a mail in KMail
5.2.1 from KDEPIM 16.04.

Yet according to the FAQ there should be one:

> 6.20. How can I remove attachments from messages without removing the message 
> itself?
>
>Open the context menu with a right mouse button click on an attachment and 
>select Delete Attachment

https://docs.kde.org/stable5/en/kdepim/kmail/faq.html#idp54668976

I don´t see this context menu entry when right clicking an attachment.

I´d like to have this feature in order to remove spam mails I attached to an
abuse report. I like to keep the abuse report for reference, but not the spam
mail. As a work-around I can just view source of mail and copy / paste only
headers.

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

[kmail2] [Bug 316107] big regression: kmail IMAP connection and message display problems

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|NEEDSINFO   |REOPENED
 Resolution|WAITINGFORINFO  |---

--- Comment #35 from Martin Steigerwald  ---
Did you make sure you also use KMail 5.1.3 with recent Akonadi version? (It
shouldn´t work with any Qt4 based Akonadi, but well, better make sure)

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

[Akonadi] [Bug 364114] moving a folder within one maildir resource is extremely slow and inefficient

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #4 from Martin Steigerwald  ---
I see how it is challenging to solve this within current Akonadi design. If
using a folder ID that is just stored within the database, it won´t detect
manual moves. But well, it could write a .folderinfo file into each folder
containing a unique hash of the folder. It would then store in database folder
xyz has this internal Akonadi ID and this hash and is currently located at this
path.

I wonder whether this changes the consequence of a database loss, but I don´t
think so, I think it can even provide a path to make filter handling much more
robust. If the filter rules stores the hash of the folder, akonadi mailfilter
agent can ask Akonadi about the internal database ID for the folder and thus as
long as the user does not remove the .folderinfo or whatever it is called file
from the folder, the filter rules would still work after a complete database
loss. (Of course that doesn´t solve this issue for IMAP accounts, but it would
be a start.)

For the individual mail items in the database Akonadi can still use an internal
ID, cause on database loss, this information is lost as well, so it will have
to reindex all the folders anyway.

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

[Akonadi] [Bug 364114] moving a folder within one maildir resource is extremely slow and inefficient

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #3 from Martin Steigerwald  ---
Okay, it took about 10 minutes and several GiB of disk traffic, but it seems it
is now done. Folders at their new location do not yet display amount of unread
mails and I expect Akonadi to create even more I/O and CPU usage when I click
on a folder there, so for now I just won´t and call it a day.

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

[Akonadi] [Bug 364114] moving a folder within one maildir resource is extremely slow and inefficient

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #2 from Martin Steigerwald  ---
And yeah, I bet I know what its doing: Its removing all the stale mails entries
from the mysqld database and then adding them again at the new location. Also
KMail still showed the folders at their old location for minutes. Now it
doesn´t display them there anymore, but in the new location they have no unread
mail count, maybe it indexes those folders then.

Honestly I´d expect Akonadi to reference the folder a mail is in by some *id*.
And if I ask to move it elsewhere, it notes that it is elsewhere now in some
mail folder table and *is* done with it.

Or in whatever other way: As a user I expect a folder move operation to be
*instant* or *almost* instant. And cause *next* to no disk I/O at all.

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

[Akonadi] [Bug 364114] moving a folder within one maildir resource is extremely slow and inefficient

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
Today I tried to be clever:

- I just stopped Akonadi and waited till it was gone (including mysqld
process).
- Then I manually moved several large folders with LKML mails, one with 26+
mails within the maildir to another directory within the very same local
folders resource, a directory/folder I use for archival purpose

But again, KMail is unresponsive when I ask it to display the contents of a
mail. It can display the list of mails that a folder contains, but displaying a
mail content does not work. While it is busy in the background with about
50-120% cpu usage for the mysqld process and about 120-140 MiB – in words more
than hundred MiB – of writes to the dual SSD BTRFS RAID 1 every 10 seconds.

So for a simple action of moving a folder it creates write I/Os in excess of
several GiB *easily*. Sorry, but this is just broke in my eyes.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 15.12 (actually in any release, starting with 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #17 from Martin Steigerwald  ---
I am running with 16.04 already, but it was already way faster with 15.12.

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

[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 15.12 (actually in any release, starting with 4.14) very slow, compared to kMail from KDE 4.13.x

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #16 from Martin Steigerwald  ---
Tore, two things:

1) AFAIK KMail 15.12 neeeds Akonadi 15.12 or at least any *other* Qt 5 based
Akonadi. Akonadi 1.13 to my knowledge is Qt 4 based. So I wonder why it works
at all on your system. It might be that in Fedora the Qt5 based Akonadi still
has a 1.13 version number, but I wouldn´t know why.

2) With Akonadi 15.12 there should be noticable performance improvements. Yet I
recommend testing with KMail + Akonadi 16.04.

I have a larger setup:

~/.local/share/akonadi> LANG=C du -sch * | sort -rh | head -4
6.9Gtotal
5.1Gdb_data
1.7Gsearch_db
117Mfile_db_data

yet, with Akonadi 15.12 I think a file leak with Akonadi´s file_db_data has
been fixed. You still seem to have it.

On any account: Akonadi 1.13 is too old. Please test more recent versions. They
old ones will not be fixed.

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

[akregator] [Bug 361588] Text of articles from certain websites displayed way too small

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED

--- Comment #6 from Martin Steigerwald  ---
I reopen this, as I didn´t look closely enough. The article text displayed in
the "Articles" tab directly is indeed large enough, but the one when I open an
article in a webpage often is not.

Example sites:
- http://www.pro-linux.de/
- http://amiga-news.de/

That is with Akregator 16.04. Once I can get Qt Webengine developer package
within Debian I can try with KDEPIM or just Akregator compiled from master, but
right now there is no Qt Webengine packaged for Debian and I´d rather not
compile it myself, so…

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

[akregator] [Bug 361588] Text of articles from certain websites displayed way too small

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |FIXED
 Status|NEEDSINFO   |RESOLVED

--- Comment #5 from Martin Steigerwald  ---
Now having Akregator 4:16.04.1-1 from Debian package font size for text in
articles seems to be okay. Thus closing. Thank you, Laurent, for fixing. Thanks
Christoph for reminding.

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

[Akonadi] [Bug 354056] Deleted emails stay, but greyed out

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 CC||mar...@lichtvoll.de
 Status|RESOLVED|REOPENED

--- Comment #42 from Martin Steigerwald  ---
Daniel, I reopen this. Please you advice whether users shall open a new bug
report about the remaining deleted mails stay but greyed out issues. If you
think it is better to open a new bug report, feel free to close this one again.

Also to all the users of KDEPIM + Akonadi 16.04 who it still doesn´t work, did
you try: "Accounts > Your account > advanced > automatically compress folders".

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

[neon] [Bug 363851] "A stop job is running for Session 1 of user neon" during shutdown

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC|mar...@lichtvoll.de |

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

[neon] [Bug 363851] "A stop job is running for Session 1 of user neon" during shutdown

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #20 from Martin Steigerwald  ---
I think one major issue here is that systemd then doesn´t seem to handle
shutdown different to log out, i.e. I and quite some other users I read from
prefer processes to be kept running on logout, but when I shutdown or reboot
the system I prefer it to first SIGTERM and then SIGKILL processes if any are
left over. Instead systemd seems to wait on processes on shutdown case, and
that requires the KillUserProcess switch be on which then also leads to user
processes being killed on logout which is the part that doesn´t make sense to
me.

Just as it worked with SysVInit. Sometimes I wonder why its necessary to break
stuff that has worked just fine for ages.

The most important question here is always "What do users want?". When I say
shutdown I mean it – I don´t mean wait for processes. When I say reboot I mean
it – I don´t mean wait for processes. When I say logout, I mean it as well – I
don´t mean kill my screen session. Instead of just changing things for the sake
of changing them, or only to the view of the world that is correct in systemd
developers terms, I wonder how about thinking of a new way to do it and
coordinate with any involved parties *before* matter-of-factly breaking
existing setups in inventive ways.

So in systemd world either the logout or the shutdown is broken depending on
the setting of the KillUserProcesses switch.

Well if its possible to some day have it working out of the box with scopes…
but hopefully in a portable way that will work on FreeBSD and other operating
systems as well.

*sorry for the rant, I will uncc me from this bug report now, as its better for
my mental sanity*

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

[neon] [Bug 363851] "A stop job is running for Session 1 of user neon" during shutdown

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #8 from Martin Steigerwald  ---
Entirely your choice and in the end I don´t care, cause I do not intend to use
Neon. Yet, you mask bugs this way.

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

[neon] [Bug 363851] "A stop job is running for Session 1 of user neon" during shutdown

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 CC||mar...@lichtvoll.de
 Ever confirmed|0   |1

--- Comment #5 from Martin Steigerwald  ---
In Debian there has been a lengthy discussion and bug report about
"KillUserProcesses=yes" since it basically breaks screen sessions started by
the user and many other things.

Bug#825394: systemd kill background processes after user logs out
https://bugs.debian.org/825394

As a consequence of this Ubuntu/Debian systemd maintainer Martin Pitt reverted
this change of default config for now.

I certainly would also disable it, cause in case I need to restart my Plasma
session due to a hangup which still happens, while in a screen a borgbackup is
running, I of course want that borgbackup to continue its work.

If processes of a user session do not shut down on session shutdown, it is a
bug – except for those where it is intended, like a screen session. Just
killing all processes just masks that bug and invites to write broken software
and makes it necessary to separate a screen or otherwise long running process
from the session where it was started from, in this case even probably by using
systemd specific API.

Also setting to confirmed, cause, well was confirmed here already by Jonathan.

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

[kmail2] [Bug 233069] Kmail loses mail bodies

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #16 from Martin Steigerwald  ---
Sad, but understandable Boudewijn. I had data losses myself, but the last has
been a very long time ago. I think Akonadi got much more stable related to data
safety, but I can understand you.

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

[kmail2] [Bug 297858] KMail crashes when moving a folder

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |UNMAINTAINED
 CC||mar...@lichtvoll.de

--- Comment #10 from Martin Steigerwald  ---
Thank you for your report. Although I still see this happening within a maildir
resource with KMail and Akonadi 16.04, I am closing this report as KDEPIM SC 4
and Akonadi 1 is unmaintained. So this bug report contains outdated backtraces.
I am intending to report the bug for KMail and Akonadi 16.04, but feel free to
beat me to it and note it here. Also please note whether you are moving folders
within a Maildir resource or within an IMAP account. Thanks, Martin

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

[kmail2] [Bug 233069] Kmail loses mail bodies

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de
 Resolution|--- |UNMAINTAINED
 Status|UNCONFIRMED |RESOLVED

--- Comment #14 from Martin Steigerwald  ---
Thank you for your report.Does this bug still happen to you with KMail and
Akonadi 16.04? If so, please reopen as a new bug as KDEPIM SC 4 and Akonadi 1
is unmaintained. Also always use one bug report for one problem. Thank you,
Martin

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

[Akonadi] [Bug 364114] New: moving a folder within one maildir resource is extremely slow and inefficient

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 364114
   Summary: moving a folder within one maildir resource is
extremely slow and inefficient
   Product: Akonadi
   Version: 16.04
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Maildir Resource
  Assignee: kdepim-b...@kde.org
  Reporter: mar...@lichtvoll.de

Today I dared moving .Computer.directory/mesa-dev-ml with about 86730 mails to
.Linux.directory by drag and drop within KMail. After the move operation
completed kmail crashed.

The operation took at least one and a half hour on a ThinkPad T520 with Intel
Sandybridge i5-2520m dual core CPU and dual SSD BTRFS RAID 1 and 16 GiB of RAM!

Reproducible: Always

Steps to Reproduce:
1. Have a large maildir folder inside another folder.
2. Move it to a different folder


Actual Results:  
1. Akonadi first moves all mails into database or file_db_data depending on
threshold. This process is extremely slow at a rate of about 2-4 mails
in half an hour. During that the mysqld database process frequently uses about
90-99% of one logical core. This process takes about 1,5 hours for 86000 mails.

martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 20:41:59 CEST 2016
30339
martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 20:42:07 CEST 2016
30473
martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 20:42:16 CEST 2016
30494
martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 20:42:32 CEST 2016
30708
martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 20:42:53 CEST 2016
31131
martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 20:45:58 CEST 2016
34562
martin@merkaba:~/.local/share/akonadi/file_db_data> date ; find -type f | wc -l
Mi 8. Jun 21:28:28 CEST 2016
67480

martin@merkaba:~/.local/share/akonadi/file_db_data> cd ..
martin@merkaba:~/.local/share/akonadi> date ; find file_db_data -type f | wc -l
; du -sh db_data 
Mi 8. Jun 21:28:58 CEST 2016
68099
4,9Gdb_data
martin@merkaba:~/.local/share/akonadi> date ; find file_db_data -type f | wc -l
; du -sh db_data
Mi 8. Jun 21:33:16 CEST 2016
74039
5,0Gdb_data
martin@merkaba:~/.local/share/akonadi> date ; find file_db_data -type f | wc -l
; du -sh db_data
Mi 8. Jun 21:45:13 CEST 2016
95529
5,1Gdb_data


2. Then after moving completed it copies the mails to the destination folder.
This is quite quick. The mains still remain in file_db_data:

martin@merkaba:~/.local/share/akonadi> date ; find file_db_data -type f | wc -l
; du -sh db_data
Mi 8. Jun 21:53:26 CEST 2016
98737
5,1Gdb_data

3. KMail crashes.

During the whole operation KMail does not respond to user input. It is
completely blocked.

Expected Results:  
When moving a folder within a local maildir resource, Akonadi does the
following:

1. Rename the folder.

2. Store the folder renaming within the database.

3. KMail remains responsive at all times.

In other words: The operation is completed within 10 seconds no matter how many
mails are in the folder. Specifically Akonadi does not move each mail one time
and then copying it.

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

[Akonadi] [Bug 290393] moving the contents of a mail folder is extremely slow

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de

--- Comment #4 from Martin Steigerwald  ---
Bruno, thank you for your report. Does it still happen for you with KDEPIM +
Akonadi 16.04.

I bet it may still happen as I find moving folder on maildir *extremely*
inefficient with that version still, but please confirm. Otherwise I intend to
close this bug report, as KDEPIM 4 and Akonadi 1 is unmaintained. Thanks,
Martin

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

[kmail2] [Bug 316107] big regression: kmail IMAP connection and message display problems

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #33 from Martin Steigerwald  ---
Sudhir, I have no idea what Zoho displays there. I only know zoho.com as a
source for spam that reaches my mailbox so far. I suggest you talk back with
Zoho support on this one.  Let us know is KDEPIM/Akonadi 15.12 or even better
16.04 resolves the issue for you.

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

[kmail2] [Bug 311184] Everlasting "Please wait while the message is transferred"

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #8 from Martin Steigerwald  ---
Johannes, thank you for the imformation. Please report a new bug tough in order
to have it being free of old and outdated information about an unmaintained
release of KDEPIM.

Also explain exactly what you are seeing there. What does "intermittently"
mean? I am not seeing this message much anymore and if so just for a few
seconds, but I also tuned my MySQL config. Can you make out in which situations
it happens?

So if you care, please report a new bug. Feel free to set me on Cc. Thanks,
Martin

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

[Akonadi] [Bug 361737] slowdown on pop3 download until it crawls to an halt on saving messages with leave mails on server enabled

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

Summary|duplicates values in|slowdown on pop3 download
   |SeenUidList and |until it crawls to an halt
   |SeenUidTimeList until it|on saving messages with
   |crawls to an halt on saving |leave mails on server
   |messages|enabled

--- Comment #24 from Martin Steigerwald  ---
You are completely right, Albert. The uid values are different. From the
*beginning*. I.e. even in the pop3 resource config file I uploaded. I didn´t
see this all the time as the beginning and the end has been the same. The brain
can read through a book where the middle letters of a word are mixed up while
the beginning and end letters are still right… seems I successfully tricked
myself into perceiving the uids were duplicate all the time while they were
not.

Sorry for all the noise about the duplicates. I just didn´t recognize that
there never where duplicates. Still the slowdown was for real. So retitling. I
am now enabling leave mails on server for 2 days again. If that works, I extend
to 7 days and observe performance. Maybe the performance regression has been
implemented after Applications/16.04.  I still cannot compile from master as
even tough I have Qt 5.6.0 now on my Debian box, the qt web engine cmake files
and headers are not yet packaged it seems, at least configuring messagelib,
kdepim-runtime and kdepim fails due to these missing.

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

[Akonadi] [Bug 361737] duplicates values in SeenUidList and SeenUidTimeList until it crawls to an halt on saving messages

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #22 from Martin Steigerwald  ---
Hmmm, no, the times are different. Oh, they have always been, just the same of
each retrieval attempt it seems. I completely missed that all the time cause
they looked all the same, as I usually have several hundred mails on each
download since I switched it to a 2 hour interval. Seems it gets the time once
for each "download mail" operation. But the uids are all the same.

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

[Akonadi] [Bug 361737] duplicates values in SeenUidList and SeenUidTimeList until it crawls to an halt on saving messages

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #21 from Martin Steigerwald  ---
This still happens with Applications/16.04. Since starting Akonadi + KMail
16.04 + setting to leave mail on server for one day it received six mails. This
is the result:

martin@merkaba:~/.config> cat akonadi_pop3_resource_0rc
[General]
host=[…]
intervalCheckEnabled=true
intervalCheckInterval=120
leaveOnServer=true
leaveOnServerDays=1
login=martin
pipelining=true
targetCollection=361
useTLS=true

[LeaveOnServer]
seenUidList=00320035446ce738,00320036446ce738,00320037446ce738,00320038446ce738,00320039446ce738,0032003a446ce738
seenUidTimeList=1462884349,1462884349,1462884349,1462884349,1462884392,1462884437

I´d expect the Uids and Times to be *different* for each item, but they are the
same again.

I checked it and for each mail it receives is just adds the same value to each
of the lists again, which doesn´t make any sense to me.

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

[Akonadi] [Bug 361737] duplicates values in SeenUidList and SeenUidTimeList until it crawls to an halt on saving messages

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #20 from Martin Steigerwald  ---
Thanks for the support, Michael. I never was clear on what to put into
branch-group to get the desired result. I somehow managed to have kdesrc-build
to build from an Applications branch.

Now rebuilding with globally with stable-kf-qt5 to have consistent versions for
everything. Will obviously take a while to complete even on Sandybridge i5
dualcore, 16 GiB RAM and Dual SSD BTRFS RAID 1 (or especially as the BTRFS
filesystem may not be running at optimal performance for being near full).

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

[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de

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

[kmail2] [Bug 362695] Kmail process continues running after exiting with File->quit.

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 CC||mar...@lichtvoll.de
 Ever confirmed|0   |1

--- Comment #1 from Martin Steigerwald  ---
Thank you for your report, Christoph.

I see this with KDEPIM compiled from master with Akonadi started MariaDB as
backend since quite a while as well. That means that the process keeps running.
I am not sure whether it can cause data loss or whether this the remoteId =
NULL is a different, probably unrelated bug. I think I have seen at least one
bug report about the remoteId = NULL thing here.

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

[Akonadi] [Bug 361737] duplicates values in SeenUidList and SeenUidTimeList until it crawls to an halt on saving messages

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #16 from Martin Steigerwald  ---
Hi Albert, from reading about branch and branch-group in kdesrc-build doc¹ I do
not get what to tell kdesrc build to build Applications/15.06 for me instead of
master.

In branch-group I can specify what modules to build, but not the branch (i.e.
version). In "branch"  I can specify what branch to build, but not the versions
to use. How do I turn

  1 global
  2 
  3 #qtdir /path/to/custom/qt  # Uncomment if you have your own qt
build
  4 source-dir  /home/kde/sources
  5 build-dir  /home/kde/build
  6 kdedir  /home/kde/install
  7 log-dir  /home/kde/logs
  8 
  9 git-repository-base kde-projects kde:   
 10 branch-groupkf5-qt5
 11 
 12 cmake-options -DCMAKE_BUILD_TYPE:STRING=debug
 13 
 14 cxxflags -pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING
-DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security -Werror=return-type
-Wno-variadic-macros -Wlogical-op -Wmissing-include-dirs
 15 
 16 # If you want to use ninja instead of make (it's faster!), add -GNinja
to cmake-options above
 17 # and uncomment the next line
 18 #custom-build-command ninja
 19 
 20 # Adjust to the number of  CPU cores
 21 make-options -j4
 22 
 23 ignore-kde-structuretrue# Downloads all modules directly
into the source folder instead of subdirectories
 24 #stop-on-failure true# Stop kdesrc-build when a build
fails.
 25 
 26 end global
 27 
 28 include /home/kde/sources/kdesrc-build/kf5-frameworks-build-include
 29 #include /home/kde/sources/kdesrc-build/kf5-workspace-build-include
 30 
 31 #Uncomment the next two lines to build application and PIM modules
 32 #include /home/kde/sources/kdesrc-build/kf5-applications-build-include
 33 include /home/kde/sources/kdesrc-build/kf5-kdepim-build-include

into building Applications/15.06 for me?

I did

diff --git a/kf5-kdepim-build-include b/kf5-kdepim-build-include
index 114d746..7242b02 100644
--- a/kf5-kdepim-build-include
+++ b/kf5-kdepim-build-include
@@ -27,6 +27,7 @@ module-set kde-pimlibs

 # The PIM Baloo code is now in akonadi-search
 use-modules kde/pim prison kdepimlibs akonadi-search libkgapi
+branch Applications/15.06
 end module-set

 module libkolab
@@ -37,5 +38,6 @@ end module
 module-set kde-pim
 repository kde-projects
 use-modules kde/kdepim kdepim-runtime
+branch Applications/15.06
 end module-set


but I get:

martin@merkaba:/home/kde/sources/kdesrc-build#1> ./kdesrc-build 
Updating kde-build-metadata (to branch master)
 * Downloading projects.kde.org project database...
 * Module kde/pim is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
72 inactive modules. Perhaps the git modules are not ready?
 * Module prison is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
1 inactive modules. Perhaps the git modules are not ready?
 * Module kdepimlibs is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
1 inactive modules. Perhaps the git modules are not ready?
 * Module akonadi-search is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
1 inactive modules. Perhaps the git modules are not ready?
 * Module libkgapi is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
1 inactive modules. Perhaps the git modules are not ready?
No modules were defined for the module-set kde-pimlibs
You should use the use-modules option to make the module-set useful.
 * Module kde/kdepim is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
1 inactive modules. Perhaps the git modules are not ready?
 * Module kdepim-runtime is apparently XML-based, but contains no
active modules to build!
Although no active modules are available, there were
1 inactive modules. Perhaps the git modules are not ready?

So I have no idea on how to accomplish the necessary build for now.

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

[Akonadi] [Bug 361737] duplicates values in SeenUidList and SeenUidTimeList until it crawls to an halt on saving messages

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #14 from Martin Steigerwald  ---
Albert, seenUidTimeList also contains duplicated values, but if its the value
in which it saw the uid in question and it saw them all at the same time, it
may be correct. I don´t know how the code works. I would have expected to see
different time stamps there as well.

As I first saw this happening, I removed the config file, and had it redownload
everything – working manually to remove all duplicated mails. It again filled
the config file with duplicate values. Then I worked around this by disabling
leaving mails on server. As I had some duplicates then still for whatever
reason, I enabled leaving mails on server again and it again filled the config
file with duplicate values. Then I retried to disable leaving mails on server
and this works okayish since then.

So I am pretty confident with the git master branch I self-compiled KF5 +
KDEPIM on top of rest from Debian Sid/Experimental packages from, this is
repeatable. I currently use:

- bf3b97e3e00706f6f743f186766f6e54152783c1 of kdepim
- 3badd8e0c8c4acd80c8d15068e9bb68670366459 of kdepim-runtime
- 77fc3fff200f2647b01a91e996e080beb1d9125c of akonadi

I intent to update everything once I have a working copy of Qt 5.6 + dev files
on my system. I intend to wait for distro packages of 5.6.1, which the Qt/KDE
team of Debian hopefully prepares beginning of May as I do not want to take the
extra effort and time to work out how to self-compile Qt and configure to use
self-compiled Qt as well in addition to self-compiling KF5 + KDEPIM at the
moment.

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

[akregator] [Bug 361588] Text of articles from certain websites displayed way too small

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #3 from Martin Steigerwald  ---
Thank you, Laurent. I plan to do a recompile of KDEPIM once I have a working Qt
5.6 setup. Right now I plan to wait for Debian packages of Qt 5.6.1, hopefully
beginning / mid of May. I think currently I do not want to work out how to
self-compile and configure to use self-compiled Qt in addition to KF 5 and
KDEPIM.

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

[Powerdevil] [Bug 353538] screen switches off when playing video in VLC or even when screen blanking is switched off

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #4 from Martin Steigerwald  ---
Thanks, Kai. Well, I have no idea about it then. I bet I wait till I get a more
consistent versioning state. I do use Debian Sid/Experimental packages + self
compiled KF5 from some weeks ago (in order to use self-compiled KDEPIM). I
think I wait till Qt 5.6.1 arrives in Debian with more up-to-date KF5 + Plasma
5 packages and a new recompile of the self-compiled stuff (or even just using
packages). And see from there. I do not have this movie watching scenario every
day, so… it can take some time for me to gather more data. What I would be
interested in would be how I can find out more about why it wouldn´t work? Any
logs or debug tools I can run in such a case?

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

[Powerdevil] [Bug 353538] screen switches off when playing video in VLC or even when screen blanking is switched off

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #2 from Martin Steigerwald  ---
This works now when I disable both powermanagement and screen locker.

Of course it would be nice if it detects VLC playing a video, but thats
probably something to report with VLC developers to tell Plasma to suspend
screen blanking (suspending locking… might be a security issue, if any app can
easily do that).

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

[Akonadi] [Bug 361737] duplicates values in SeenUidList and SeenUidTimeList until it crawls to an halt on saving messages

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #8 from Martin Steigerwald  ---
Created attachment 98669
  --> https://bugs.kde.org/attachment.cgi?id=98669=edit
excessive duplicates in akonadi_pop3_resource_0rc

Albert, the duplicates easily get excessive. Here an example of it with a
retention time of just 2 days.

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

[kmail2] [Bug 316107] big regression: kmail IMAP connection and message display problems

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #31 from Martin Steigerwald  ---
Additionally for "So, can you still reproduce this with KMail from KDEPIM 4.14
and Akonadi 1.13?" I´d update this to KDEPIM + Akonadi 15.12. Please test with
that version as KDEPIM 4 and Akonadi 1.13 are not supported by upstream
anymore. If you do have a distro that still uses it, feel free to use to report
it there but its maybe unlikely that it would be fixed there still for Qt4
based Akonadi + KDEPIM, so it may be better to wait till you can test with at
least KDEPIM + Akonadi 15.12. If you can even rather test with 16.04. So or so,
I personally think the issue has been fixed meanwhile. I didn´t see it in ages.

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

[kmail2] [Bug 316107] big regression: kmail IMAP connection and message display problems

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #30 from Martin Steigerwald  ---
Hello Sudhir, read comment #27. I specified what information I ask for there.
Thanks, Martin

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

[kwin] [Bug 361704] window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #10 from Martin Steigerwald  ---
Hmmm, thanks. I think it is of big importance to focus on the stability of the
whole stack. In the end no matter whether its Qt or KF5 / Plasma causing the
issue if the user experience is affected like that. I still think I do not yet
have back the same stability as with latest KDE SC 4.14 or KDE 3.x, even though
multiscreen always had issues for me. All the best to those who are into fixing
these issues. Maybe only with Wayland this multiscreen stuff will finally work.
Its about time. But what do I write there, I bet you know all this. Thanks
again, Martin

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

[kmail2] [Bug 343186] Timeout trying to get lock on start of kmail

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #3 from Martin Steigerwald  ---
Thanks, David. Together with my MySQL database config optimizations 30 seconds
are indeed enough to cold start KMail + Akonadi. Without the optimization
Akonadi startup takes longer than 30 seconds and I still get the notification.

My optimization mainly is:

innodb_buffer_pool_size=1024M

(As I noted in another bug report  the default value is ridiculously low for
larger mail setups.)

So or so the original issue is not solved by that patch, its merely a
workaround.

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

[kwin] [Bug 361704] window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #8 from Martin Steigerwald  ---
Any further info you´d still want for that unmapped Akregator window? Otherwise
I´d restart Akregator as well in order to use it again :)

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

[kwin] [Bug 361704] window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #7 from Martin Steigerwald  ---
I restarted kmail, but Akregator still hides away, seems the window is
unmapped:

> xwininfo -name "Akregator"

xwininfo: Window id: 0xa000ba "Akregator"

  Absolute upper-left X:  1920
  Absolute upper-left Y:  38
  Relative upper-left X:  1920
  Relative upper-left Y:  38
  Width: 1920
  Height: 1042
  Depth: 24
  Visual: 0xba
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0xa000b9 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: no
  Corners:  +1920+38  --1920+38  --1920-0  +1920-0
  -geometry 1920x1042+1920-0

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

[kwin] [Bug 361704] window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #5 from Martin Steigerwald  ---
Created attachment 98394
  --> https://bugs.kde.org/attachment.cgi?id=98394=edit
xwininfo -root -tree after external display disconnected, kmail window still
exists

Thomas, the kmail window still exists but is not shown in window bar in control
panel. I not reopening for now, since the QTBUG mentioned in bug #341497 also
talks about disappeared windows.

> xwininfo -root -tree

xwininfo: Window id: 0xd5 (the root window) (has no name)

  Root window id: 0xd5 (the root window) (has no name)
  Parent window id: 0x0 (none)
 150 children:
 0x240004d "krunner": ("krunner" "krunner")  756x171+582+0  +582+0
 0x781 (has no name): ()  1x1+0+0  +0+0
 0x141 (has no name): ()  1x1+0+0  +0+0
 0x481fa87 "Einrichten — KMail": ("kmail" "kmail2")  1181x797+2290+142 
+2290+142
 0x481fa85 "KMail": ("kmail" "kmail2")  484x462+2131+568  +2131+568
 0x481fa83 "KMail": ("kmail" "kmail2")  776x33+2401+188  +2401+188
 0x481fa81 "KMail": ("kmail" "kmail2")  348x131+2872+335  +2872+335
 0x481fa7f "KMail": ("kmail" "kmail2")  455x193+2872+304  +2872+304
 0x481fa7d "KMail": ("kmail" "kmail2")  334x645+2538+304  +2538+304
 0x481fa79 "KMail": ("kmail" "kmail2")  22x22+2109+343  +2109+343
 0x481fa77 "KMail": ("kmail" "kmail2")  477x207+2456+75  +2456+75
 0x481fa75 "KMail": ("kmail" "kmail2")  417x324+2366+75  +2366+75
 0x481fa73 "KMail": ("kmail" "kmail2")  484x631+2207+75  +2207+75
 0x481fa71 "KMail": ("kmail" "kmail2")  668x552+2132+75  +2132+75
 0xa000ba "Akregator": ("akregator" "akregator")  1920x1042+1920+38 
+1920+38
 0x481f9e8 "Lokale Ordner/[…]/_Posteingang — KMail": ("kmail" "kmail2") 
1920x1042+1920+38  +1920+38
8 children:
0x481fa0c "KMail": ("kmail" "kmail2")  24x24+1209+609  +3129+647
0x481fa0a "KMail": ("kmail" "kmail2")  1920x937+0+75  +1920+113
0x481fa08 "KMail": ("kmail" "kmail2")  1920x38+0+37  +1920+75
0x481fa06 "KMail": ("kmail" "kmail2")  1920x37+0+0  +1920+38
0x481fa04 "KMail": ("kmail" "kmail2")  709x148+1211+864  +3131+902
0x481fa02 "KMail": ("kmail" "kmail2")  1920x30+0+1012  +1920+1050
0x481f9ec "KMail": ("kmail" "kmail2")  1920x937+0+75  +1920+113
   1 child:
   0x481f9ee "KMail": ("kmail" "kmail2")  1920x937+0+0  +1920+113
  4 children:
  0x481fa00 "KMail": ("kmail" "kmail2")  1x1+0+0  +1920+113
  0x481f9fe "KMail": ("kmail" "kmail2")  5x937+478+0  +2398+113
  0x481f9f2 "KMail": ("kmail" "kmail2")  1439x937+481+0  +2401+113
 4 children:
 0x481f9fc "KMail": ("kmail" "kmail2")  5x937+748+0  +3149+113
 0x481f9fa "KMail": ("kmail" "kmail2")  100x30+0+0  +2401+113
 0x481f9f8 "KMail": ("kmail" "kmail2")  750x937+0+0  +2401+113
 0x481f9f4 "KMail": ("kmail" "kmail2")  688x937+751+0 
+3152+113
1 child:
0x481f9f6 "KMail": ("kmail" "kmail2")  688x937+0+0 
+3152+113
  0x481f9f0 "KMail": ("kmail" "kmail2")  480x937+0+0  +1920+113
0x481f9ea "KMail": ("kmail" "kmail2")  160x160+0+0  +1920+38
 0x1bab225 "KWin": ("kwin_x11" "kwin")  32x32+-32+-32  +-32+-32

Attached is the full window list with some window titles shortened due to
privacy.

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

[kwin] [Bug 341497] Segfault in Qt since the (at least) the xcb screen backend cannot deal with "no screen" conditions

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #57 from Martin Steigerwald  ---
Just to make it clear here, the QT-BUG –
https://bugreports.qt.io/browse/QTBUG-42985 – also refers to disappearing
windows, not just crashes. From reading from the QTBUG I bet the issue is fixed
in Qt 5.5.1 with patches and hopefully in 5.6.

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

[kwin] [Bug 361704] window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #3 from Martin Steigerwald  ---
Hmmm, I didn´t see any kwin_x11 crashes. Maybe not reported by Dr. Konqi?

I will try the xwinfo -root -tree thing next time and post here.

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

[kwin] [Bug 361704] window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
kscreen is also 5.5.4 on the system. KF5 is compiled from git master as of last
weekend. 5.6 Plasma is not yet available on Debian and free space on filesystem
is small, so compiling it from master might exceed available free space. Yet I
could compile parts of Plasma. I.e. just the window manager. I have
kdesrc-build installed and setup.

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

[kwin] [Bug 361704] New: window on external screen disappears when hibernating with external screen connected and resuming when it is not connected

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 361704
   Summary: window on external screen disappears when hibernating
with external screen connected and resuming when it is
not connected
   Product: kwin
   Version: 5.5.4
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: mar...@lichtvoll.de

I have KMail and Konsole and other apps on external screen. I hibernate the
laptop. Next morning I resume it at work, without external screen connected
(cause I hold a training where I don´t have one for the laptop). KMail window
is gone. Konsole window is gone.

Reproducible: Always

Steps to Reproduce:
1. Open an application window on external screen.
2. Hibernate.
3. Disconnect external screen
4. Resume

Actual Results:  
I had KMail and konsole window on external screen.

KMail window gone. It is visible on the laptop screen in any activity. It is
not even in window bar in control panel. Process still running.

Same with Konsole except process not running anymore.

Akregator which was on laptop screen at the time of hibernation still is
displayed correctly.

kscreen seems to have recognized properly that external screen is gone. At
least it is not displayed anymore in systemsettings. xrandr also only lists
laptop screen.

Expected Results:  
Windows that were on the external screen are relocated to the internal screen
when the external screen is not available anymore.

Basic rule for all of this: A window is always visible or minimized and can be
made visible. Never ever a window is not accessible as long as at least *one*
display is working.

kwin from Debian Experimental 4:5.5.4-2 on Debian Sid/Experimental. Qt 5.5.1.

system and xrandr info, for now without external display connected:

martin@merkaba:~> phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, Disk:
300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel HD 3000
(1300MHz), Audio: Conexant CX20590, Monitor: P24T-7 LED, Network: Intel 82579LM
Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.6.0-rc2-tp520-btrfstrim+ (x86_64), Desktop: KDE
Frameworks 5, Display Server: X Server 1.18.3, Display Driver: intel 2.99.917,
OpenGL: 3.3 Mesa 11.1.2, Compiler: GCC 5.3.1 20160409, File-System: btrfs,
Screen Resolution: 1920x1080


martin@merkaba:~> xrandr 
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS1 connected primary 1920x1080+0+0 (normal left inverted right x axis y
axis) 344mm x 193mm
   1920x1080 60.00*+  59.9350.00  
   1680x1050 59.9559.88  
   1600x1024 60.17  
   1400x1050 59.98  
   1280x1024 60.02  
   1440x900  59.89  
   1280x960  60.00  
   1360x768  59.8059.96  
   1152x864  60.00  
   1024x768  60.00  
   800x600   60.3256.25  
   640x480   59.94  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)


I am tempted to classify this as critical, cause making an application window
inaccessible could be a reason for data loss. Yet, one usually can still send
it a TERM signal and I´d hope it would prompt for any unsaved work to be saved
on the internal screen then. So leaving as normal for now.

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

[akregator] [Bug 361590] navigation buttons missing in internal webbrowser

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
Created attachment 98316
  --> https://bugs.kde.org/attachment.cgi?id=98316=edit
there are no navigation buttons next to the other three buttons in the toolbar

In older Akregator versions there have been navigation buttons (well, it was
broken there for some time as well, but before that…)

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

[akregator] [Bug 361590] New: navigation buttons missing in internal webbrowser

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 361590
   Summary: navigation buttons missing in internal webbrowser
   Product: akregator
   Version: GIT (master)
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: internal browser
  Assignee: kdepim-b...@kde.org
  Reporter: mar...@lichtvoll.de

Currently using Applications/16.04, but also happens with git master.

On web page article view back and forward navigation buttons are missing.

Reproducible: Always

Steps to Reproduce:
1. Add a feed.
2. Open an article.
3. View an article in internal webbrowser.
4. Click a link.

Actual Results:  
No back button at all (see attached screenshot). I reported the extremely smal
font size separately as bug 361588.

Expected Results:  
Back button is there and is made active (instead of ghosted) when I press first
link.

This issue first came up when Laurent implemented the wonderful WebEngine
support. I told Laurent then and he said would be looking into it, but issue is
still there, so I report bug.

It has been fixed in the meanwhile for some time, but since quite a while is
present again.

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

[akregator] [Bug 361588] Text of articles from certain websites displayed way too small

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
Created attachment 98315
  --> https://bugs.kde.org/attachment.cgi?id=98315=edit
This is how Akregator displays text from pro-linux.de

Also affected are Heise Open heise.de/open, as well as KDE Dot News
https://dot.kde.org/ and many other sites.

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

[akregator] [Bug 361588] New: Text of articles from certain websites displayed way too small

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 361588
   Summary: Text of articles from certain websites displayed way
too small
   Product: akregator
   Version: GIT (master)
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: internal browser
  Assignee: kdepim-b...@kde.org
  Reporter: mar...@lichtvoll.de

Currently running git Applications/16.04, but also happens with master.

Text of articles from feeds from certain websites is displayed way too small. I
meanwhile habitually press Ctrl + several times to make it readable.

Reproducible: Always

Steps to Reproduce:
1. Add rss feed of pro-linux.de (just visit site with Konqueror and use RSS
symbol) or use the URL http://www.pro-linux.de/backend/pro-linux.rdf

2. Let is receive some articles

3. View one article

4. Open article as webpage in internet browser

Actual Results:  
See attached screenshot.

Expected Results:  
Obviously way bigger text!

This is on ThinkPad T520, currently using even 24 inch external display, on
internal Full HD with 143 dpi display the text is really unreadable.

This issue first came up when Laurent implemented the wonderful WebEngine
support. I told Laurent then and he said would be looking into it, but issue is
still there, so I report bug.

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

[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #6 from Martin Steigerwald  ---
Knut, it is safe to remove them (but only the file_lost+found files not
file_db_data!). That Akonadi leaks files in file_db_data which akonadictl fsck
moves to lost+found is a known bug that has been fixed. There are references to
it in this bug tracker on on kdepim-users mailinglist (I don´t have the
references at hand atm and its late here). Make sure you have latest kdepim
15.12. The leakage of files in file_db_data should be fixed (maybe what you see
here are old leaked files and akonadictl fsck now cleaned.)

Please otherwise try to keep the bug clean and only to the original potential
data loss issue it reports. Use kdepim-users mailing list for further
questions. (Bugs that have comments of a lot of different issues are difficult
to follow for developers that why I set the duplicates this way around).

Thanks,
Martin

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

[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #4 from Martin Steigerwald  ---
I marked bug 344242 as a duplicate of this one and of course this thing is
confirmed, as Dan already wrote its a known issue.

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

[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||piedro.kul...@googlemail.co
   ||m

--- Comment #3 from Martin Steigerwald  ---
*** Bug 344242 has been marked as a duplicate of this bug. ***

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

[kmail2] [Bug 344242] Mails that are copied do not appear on my harddrive

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Martin Steigerwald  ---
Thanks, Guido, that confirms it. So basically my bug report is a duplicate of
this one, but as my bug report already contains a clear description on whats
the cause, I will mark this one as a duplicate of it. (piedro, no offense
meant, I know your report is sooner:).

For now there is a simple rule: Do *not* wipe your database *ever*. Otherwise
you would loose that items. Keep regular backups of both the resource data +
the database. Backup the database while Akonadi + MySQL are not running.

*** This bug has been marked as a duplicate of bug 360834 ***

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

[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #2 from Martin Steigerwald  ---
Oh and Dan later added that "server" actually means any resource, so "server"
could also be a local maildir or calender file or what not.

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

[kmail2] [Bug 344242] Mails that are copied do not appear on my harddrive

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de

--- Comment #7 from Martin Steigerwald  ---
Guido: Still very old. Yet, in this case it likely doesn´t matter:

Do you see  "item without rid" messages during an akonadictl fsck?

I do think what you see is basically

Bug 360834 - no mechanism to reattempt to store items without rid (just in db)
into the resource

So its currently still also in the newest Akonadi versions.

Can you verify that you have items without rid?

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

[Akonadi] [Bug 360834] no mechanism to reattempt to store items without rid (just in db) into the resource

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
Adding link to Dan´s mail in the thread "Akonadictl fsck" on kdepim-users where
he explains this:

https://mail.kde.org/pipermail/kdepim-users/2016-March/000113.html

Also this report might be a duplicate of bug #344242. For the sake of clearness
it may make sense to mark it the other way around.

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

[kate] [Bug 360811] markdown preview

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #2 from Martin Steigerwald  ---
Gregor, thanks for your input. That is a different, but related feature. I´d
like to see this as well. Please open a new bug about this and post a link
here. Thanks. (One issue / feature in one bug.)

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

[kmail2] [Bug 339181] moving mails from cached imap to local folder leaves mails without RID

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #18 from Martin Steigerwald  ---
Wow, thank you, Dan. I may even test if, if I configure my IMAP account again,
I removed it cause Akonadi was too slow, yet, I found it replaced mysql.conf in
a recent upgrade due to a setting deprecated in MySQL and thus it decreased my
InnoDB buffer settings and thats no good, now its faster again and I could put
it back in. Does it have to be a cached/disconnected IMAP for testing?

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

[kmail2] [Bug 339181] moving mails from cached imap to local folder leaves mails without RID

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #14 from Martin Steigerwald  ---
Added a bug report about the no rid, no option to reattempt  to push item into
server issue:

Bug 360834 - no mechanism to reattempt to store items without rid (just in db)
into the resource

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

[Akonadi] [Bug 360834] New: no mechanism to reattempt to store items without rid (just in db) into the resource

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 360834
   Summary: no mechanism to reattempt to store items without rid
(just in db) into the resource
   Product: Akonadi
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: mar...@lichtvoll.de

It can happen (see bug #339181) that akonadictl reports an item without rid.
Dan explains regarding it:

--
Those are Items (emails, events, contacts, ...) that you created locally but
were not synced to the server. 

Unfortunately we don't have a mechanism at this moment to force Akonadi to try
to sync those Items again to the server. If you wipe your Akonadi database,
those Items will be lost.
--

That means there will be a data loss in case the database is wiped or
corrupted.

Reproducible: Always

Steps to Reproduce:
See description of Ingo in 339181#c13 (bug 339181, comment 13 in case bugzilla
doesn´t make this into a link).

Actual Results:  
Data remains in database. In case db is wiped our corrupted data is gone.

Expected Results:  
- Akonadi attempts to store the item where it belongs, in the resource, again
at least for several times

- User agent warns about this where needed and gives option to retry pushing to
server at a later time.

I am leaving it as normal, as it *usually* doesn´t loose data, yet, I think the
issue has some higher priority than that.

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

[kmail2] [Bug 339181] moving mails from cached imap to local folder leaves mails without RID

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #13 from Martin Steigerwald  ---
Okay, Dan didn´t really confirm the bug, actually there are two bugs: The one
with moving mails from cached IMAP to local folder, the other is generally that
on failures there are items without RID, which are only stored in database, but
on in resource (IMAP, local folder or such). Yet Ingo just confirmed it:

--
I'm experiencing this bug since a long time and have learned to live 
with it.

Moving a single message from an IMAP account (cached or not makes no 
difference) to a local folder (maildir in mixed resource) works.

Copying multiple messages (even 1000s) also works (although it takes 
quite some time until the copied messages that are already listed in the 
destination folder appear on disk).

But if one tries to move multiple messages then only the first message 
appears on disk in the maildir folders. All other messages only appear 
"virtually" in the folder. Usually, there's a message that moving 
failed. But the messages are still gone from the source folder. This is 
100 % reproducible.
--
https://mail.kde.org/pipermail/kdepim-users/2016-March/000123.html

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

[kate] [Bug 360811] New: markdown preview

[Martin Steigerwald via KDE Bugzilla]

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

Bug ID: 360811
   Summary: markdown preview
   Product: kate
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: martin.steigerw...@teamix.de

I´d like a markdown preview in a separate view either side by side with the
text input or below it maybe. Ideally using Kate´s split view system as a base.

Version not in version list: 15.12.1

Reproducible: Always




Could be a plugin of course.

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

[kate] [Bug 360811] markdown preview

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de

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

[KScreen] [Bug 360563] black screen on session restore until removing ~/.local/share/kscreen

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #15 from Martin Steigerwald  ---
Alexey, okay, got confused by

4. The screen is modified. It copies current displayed image, moves it down
from top of monitor and fixed the image (system is still responsible and all
actoins and movements will be at top part of screen). I backuped the "kscreen"
directory as "kscreen.bad"

that didn´t sound like a black screen to me.

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

[KScreen] [Bug 360563] black screen on session restore until removing ~/.local/share/kscreen

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #13 from Martin Steigerwald  ---
Okay. Thank you for the detailed description. Which ~/.local/share/kscreen in
your archive correspondends to the black screen on login state?

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

[KScreen] [Bug 360563] black screen on session restore until removing ~/.local/share/kscreen

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #11 from Martin Steigerwald  ---
Alexey, I do not understand whether you are really seeing the *same* bug. Do
you have a *black* screen on session *login* with a certain kscreen
configuration?

If yes, thats the same bug.

If not, its likely a different bug and I kindly ask you to open a new bug
report instead of hijacking this one.

Thank you,
Martin

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

[KScreen] [Bug 360563] black screen on session restore until removing ~/.local/share/kscreen

[Martin Steigerwald via KDE Bugzilla]

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

--- Comment #1 from Martin Steigerwald  ---
Created attachment 97913
  --> https://bugs.kde.org/attachment.cgi?id=97913=edit
broken ~/.local/share/kscreen that led to black display

Fujitsu Siemens Computers GmbH-P24T-7 is home display connected via displayport
via Minidock.

Fujitsu Siemens Computers GmbH-P23T-6 is office display connected via
displayport to hdmi adapter.

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

[KScreen] [Bug 360563] black screen on session restore until removing ~/.local/share/kscreen

[Martin Steigerwald via KDE Bugzilla]

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

Martin Steigerwald  changed:

   What|Removed |Added

 CC||mar...@lichtvoll.de

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