[trojita] [Bug 377382] Unable to log in -- IMAP alert

[Jan Kundrát]

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

--- Comment #18 from Jan Kundrát <j...@kde.org> ---
> Yes, I followed, but there was nothing interesting.
> "Have you set an application-specific password?" --> No.

Set it, then, and configure Trojita to use this app-specific password you 
will have just created for Trojita..

> Evolution is working, I dont think there is any issue at my 
> gmail account side.

There's nothing "WRONG" with your GMail setup, except that it only allows 
applications which were modified to accommodate GMail's proprietary 
extension. Without such an app modification, login won't work with your 
regular GMail password. Evolution includes that modification, Trojita 
doesn't include it, hence Trojita "doesn't work". Your only chance is to 
set up an app-specific password for Trojita, or "allow less secure apps to 
access GMail" as Google calls it. Instructyions are at 
https://support.google.com/accounts/answer/6010255

> Is there any deeper traceing/logging possibility?

There is nothing to debug. You just have to follow the instructions we 
already gave you.

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

[trojita] [Bug 377382] Unable to log in -- IMAP alert

[Jan Kundrát]

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

--- Comment #16 from Jan Kundrát <j...@kde.org> ---
> After rebuild the version was v0.7-189-g7ca6cf83.
> Is this the latest?

Nope, the latest is v0.7-199-gdd2084d, but it doesn't matter, there were no 
changes to the IMAP LOGIN in there.

> 09:35:52.5837  <<<  y1 NO [ALERT] Please log in via your web browser:
> https://support.google.com/mail/accounts/answer/78754 (Failure)

Have you looked at this URL? What troubleshooting steps have you followed? 
What is your GMail setup -- do you use twofactor authentication? Have you 
set an application-specific password?

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

[trojita] [Bug 377416] Got FETCH that is out of bounds

[Jan Kundrát]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
I don't see any attachment at
https://bugzilla.redhat.com/show_bug.cgi?id=1424991 . I'm logged in as
j...@flaska.net.

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

[trojita] [Bug 377382] Unable to log in -- IMAP alert

[Jan Kundrát]

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

--- Comment #9 from Jan Kundrát <j...@kde.org> ---
(In reply to Szőgyényi Gábor from comment #8)
> Is there any way to trace the "server <--> Trojita IMAP client" handshaking?

Yes: Menu -> IMAP -> Debugging -> Show IMAP Protocol log.

(In reply to Szőgyényi Gábor from comment #6)
> My problem is, Trojita is not working, but evolution works with gmail.

Perhaps Evolution developers decided to invest their time to add support for
GMail's proprietary protocol extension to provide better user experience with
GMail out-of-box. Nobody from our developer pool decided that that would be a
great use of their time, so Trojita doesn't support AUTH=XOAUTH2 at this point.

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

[trojita] [Bug 377382] Unable to log in -- IMAP alert

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Thomas is spot-on, closing. This is a GMail anti-feature, there's nothing we
can do to change their authentication policies.

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

[trojita] [Bug 374830] Context menu on e-mail address should offer "Copy e-mail address"

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED
  Latest Commit||https://commits.kde.org/tro
   ||jita/434f677d4909e751ef59d2
   ||c8b5e2899b05eae022

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
Git commit d42deaec263c1a0cd00d0391f0b75b48c3471b0d by Jan Kundrát.
Committed on 05/02/2017 at 14:37.
Pushed by gerrit into branch 'master'.

GUI: Extracting e-mail addresses from a message body

Right now, we delegate link copying to WebKit, which means that it will
use URLs like "mailto:f...@example.org;. That is suboptimal from the
user's point of view; they typically just "want to have that e-mail
address".

This patch ensures that we do this fancy thing when the URL is really a
simple one -- pointing to exactly one recipient. As a fallback option,
all other cases are handled by the existing code which just copies the
URL as-is.

Please note that this does not fix the issue that the linked bugreport
complained about -- the header widget with e-mail addresses is a QLabel,
so we will have to do a slightly different dance for that.

Change-Id: I930f4eecd291af643c736701849d4c92fc8fc43d

M  +18   -3src/Gui/SimplePartWidget.cpp
M  +1-0src/Gui/SimplePartWidget.h

https://commits.kde.org/trojita/d42deaec263c1a0cd00d0391f0b75b48c3471b0d

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
Git commit 434f677d4909e751ef59d2c8b5e2899b05eae022 by Jan Kundrát.
Committed on 06/02/2017 at 11:29.
Pushed by gerrit into branch 'master'.

GUI: Clipboard copying of e-mail addresses from the header view

Previously, the context menu offered some options for accessing the
QLabel (this class is actually just a pretty QLabel)'s text, for
selecting all of it, and copying stuff.

The most important, IMHO, is to have access to the actual e-mail address
(as requested by the associated bugreport), and to the human readable
text for the sake of completeness.

The code is still a tad inconsistent because the List-Post header for
indicating an active mailing list does not currently use the
OneEnvelopeAddress class. Mailing list addresses will therefore remain
unaffected by this patch; their copy action is still going to copy a
complete mailto: URL.
Change-Id: I4e515045d0241e4c1064389aa777f58e72c7c999

M  +26   -2src/Gui/OneEnvelopeAddress.cpp
M  +2-0src/Gui/OneEnvelopeAddress.h

https://commits.kde.org/trojita/434f677d4909e751ef59d2c8b5e2899b05eae022

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

[trojita] [Bug 374830] Context menu on e-mail address should offer "Copy e-mail address"

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED
  Latest Commit||https://commits.kde.org/tro
   ||jita/434f677d4909e751ef59d2
   ||c8b5e2899b05eae022

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
Git commit d42deaec263c1a0cd00d0391f0b75b48c3471b0d by Jan Kundrát.
Committed on 05/02/2017 at 14:37.
Pushed by gerrit into branch 'master'.

GUI: Extracting e-mail addresses from a message body

Right now, we delegate link copying to WebKit, which means that it will
use URLs like "mailto:f...@example.org;. That is suboptimal from the
user's point of view; they typically just "want to have that e-mail
address".

This patch ensures that we do this fancy thing when the URL is really a
simple one -- pointing to exactly one recipient. As a fallback option,
all other cases are handled by the existing code which just copies the
URL as-is.

Please note that this does not fix the issue that the linked bugreport
complained about -- the header widget with e-mail addresses is a QLabel,
so we will have to do a slightly different dance for that.

Change-Id: I930f4eecd291af643c736701849d4c92fc8fc43d

M  +18   -3src/Gui/SimplePartWidget.cpp
M  +1-0src/Gui/SimplePartWidget.h

https://commits.kde.org/trojita/d42deaec263c1a0cd00d0391f0b75b48c3471b0d

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
Git commit 434f677d4909e751ef59d2c8b5e2899b05eae022 by Jan Kundrát.
Committed on 06/02/2017 at 11:29.
Pushed by gerrit into branch 'master'.

GUI: Clipboard copying of e-mail addresses from the header view

Previously, the context menu offered some options for accessing the
QLabel (this class is actually just a pretty QLabel)'s text, for
selecting all of it, and copying stuff.

The most important, IMHO, is to have access to the actual e-mail address
(as requested by the associated bugreport), and to the human readable
text for the sake of completeness.

The code is still a tad inconsistent because the List-Post header for
indicating an active mailing list does not currently use the
OneEnvelopeAddress class. Mailing list addresses will therefore remain
unaffected by this patch; their copy action is still going to copy a
complete mailto: URL.
Change-Id: I4e515045d0241e4c1064389aa777f58e72c7c999

M  +26   -2src/Gui/OneEnvelopeAddress.cpp
M  +2-0src/Gui/OneEnvelopeAddress.h

https://commits.kde.org/trojita/434f677d4909e751ef59d2c8b5e2899b05eae022

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

[trojita] [Bug 375822] Infinite login loop when wrong credentials are provided by a plugin

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
  Latest Commit||https://commits.kde.org/tro
   ||jita/430d6802f44e7262005c1d
   ||6413b290bd383c57f0

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Git commit 430d6802f44e7262005c1d6413b290bd383c57f0 by Jan Kundrát.
Committed on 02/02/2017 at 20:13.
Pushed by gerrit into branch 'master'.

GUI: Do not keep reusing wrong password

Since commit 76648e4248, Trojitá has started forgetting to forget a
cached password which proved to be wrong. When a password was provided
by some plugin, the UI would never ask the user for one after a login
failure. That's suboptimal, especially considering that the code would
just happily loop and issue many login requests using the same
credentials over and over again.

Thanks to Marc Lambrecht (whytrytofly on IRC) for reporting this.

Change-Id: I1920176ad71910bea6e8c83033e444dc01c076bf

M  +8-0src/Gui/Window.cpp

https://commits.kde.org/trojita/430d6802f44e7262005c1d6413b290bd383c57f0

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

[trojita] [Bug 376287] New: multipart/related with text/html should not hide all other parts

[Jan Kundrát]

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

Bug ID: 376287
   Summary: multipart/related with text/html should not hide all
other parts
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Core
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org
  Target Milestone: ---

A new bank just started sending me e-mails like this one:

Content-Type: multipart/related; 
boundary="=_Part_6487_1186403229.1486732952500"

--=_Part_6487_1186403229.1486732952500
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[html stuff here]
--=_Part_6487_1186403229.1486732952500
Content-Type: application/pdf; 
name="... .pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; 
filename="... .pdf"

[PDF]
--=_Part_6487_1186403229.1486732952500--

Unfortunately, our MIME interpreter deems stuff which is nested in the same
layer as the main HTML part within a multipart/related container to be a part
of the HTML message.

In this case, we should take a hint of the Content-Disposition header at least.
Our code also already correctly handles the attachment icon in the message
listing.

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

[trojita] [Bug 376173] Drafts stored on IMAP server

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Supporting at least the Trojita-produced drafts on the IMAP server and being
able to re-read them is a nice goal, I agree.

For other use cases, it might get a bit more difficult. We can do MIME parsing
semi-reasonably, IMHO, but there's a lot of corner cases which did not have to
be supported up to now.

Patches welcome either way.

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

[trojita] [Bug 374798] Add "Save link as" to context menu in messages

[Jan Kundrát]

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

--- Comment #8 from Jan Kundrát <j...@kde.org> ---
The path of the least resistance is probably to start Trojita in an env with a
custom `xdg-open` in your $PATH (and yes, that's pretty user-unfriendly) -- and
hope that Qt decides to use this xdg-open in preference to whatever DE
detection they might have in hand, too.

I am undecided on whether a patch for possibly overriding the platform support
belongs to Trojita. I definitely won't write one.

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

[trojita] [Bug 376100] Debian 9 "Stretch" packages of Trojita 0.7

[Jan Kundrát]

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

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
> Just add a repository in Meta configuration:

OK, right, you apparently know more than I do about this. Can you please 
provide a patch for this at OBS ("a request" or how they call it)? I do not 
want to invest my time into supporting yet-unreleased distros, but I'll be 
happy to merge results of your work and testing.

The name looks like something which might refer to something completely 
different in future, so please name it accordingly (i.e., not "Stretch").

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

[trojita] [Bug 376100] Debian 9 "Stretch" packages of Trojita 0.7

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |LATER
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Debian 9 is not available in OBS as far as I can tell -- the web UI only offers
me 7.0 and 8.0. Please reopen when they start offering it.

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

[trojita] [Bug 374830] Context menu on e-mail address should offer "Copy e-mail address"

[Jan Kundrát]

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
A series of patches which implement this is available at
https://gerrit.vesnicky.cesnet.cz/r/#/q/status:open+project:trojita+branch:master+topic:mailto-bug-374830
. Feedback is welcome

And so are patches which deprecate our X-Trojita-DisplayName, Pali :).

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

[trojita] [Bug 375151] Network Error: connection closed by remote host

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

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

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
The IMAP protocol states that the minimal timeout is 30 minutes. If your server
(or some network middlebox) imposes shorter, non-standard timeouts, you can as
a workaround use the timeout value as per comment #1. If that still doesn't
work as you suggest, please attach a new log and reopen.

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

[trojita] [Bug 375822] Infinite login loop when wrong credentials are provided by a plugin

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

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

[trojita] [Bug 375822] New: Infinite login loop when wrong credentials are provided by a plugin

[Jan Kundrát]

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

Bug ID: 375822
   Summary: Infinite login loop when wrong credentials are
provided by a plugin
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: IMAP
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org
  Target Milestone: ---

- save wrong login credentials into trojita's settings
- start trojita, try to go online
- watch the log for an endless loop of login attempts

I would say that this is pretty critical, there's essentially no UI indication
for this. That sucks, this definitely used to work in previous releases. It's
disappointing that our test suite didn't catch that.

Thanks to Marc Lambrecht (whytrytofly on IRC) for reporting this.

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

[trojita] [Bug 375179] Composer inserts hard line breaks to replies

[Jan Kundrát]

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

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
Before we go further, could you please clarify what you expect to see and why
so?

Trojita uses the format=flowed extension which affects the perceived line
breaks (and their on-the-wire form, too). If you reply to a flowed text, the
composer shows it with apparent line breaks because we have to somehow fit the
text into the composer window. The outgoing form is created using flowed
formatting once again, and will be re-flowed as needed. Maybe that is confusing
for you?

In order to reproduce this, please describe a real-world scenario which creates
some wrong or misleading result, carefully explain what you expect to get and
in what ways the actual result is broken. Then attach raw sample messages
including their MIME encoding. You can get these by right-clicking on a message
in Trojita and picking "Save Message" or "Save whole message". The resulting
.eml files with no additional manipulation or sanitization are important here.
Screenshots form both Trojita and maybe another MUA, if relevant, are good to
help clarify why the end result is wrong.

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

[trojita] [Bug 375179] Composer inserts hard line breaks to replies

[Jan Kundrát]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Could you please attach a sample of how the original message looks like and
what Trojita outputs?

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

[trojita] [Bug 375143] Running a deletion task takes ~10 seconds per deletion

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

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

--- Comment #7 from Jan Kundrát <j...@kde.org> ---
Thanks for the logs. This is the expected behavior in IMAP where message
deletion is a two-step process.

At first, a message is marked as deleted. This is tied to the user hitting the
Del key. The UI indicates this state of a message with a strike-trough font.

The second step is to permanently remove messages which are marked as deleted
from a given mailbox; this action is called Expunge. According to the logs
you've attached, "something" triggered expunge. As Thomas said, this can be
another client running in the background, or a server-side feature ("auto
expunge") which is configured to remove deleted messages after a short while.

You might be able to configure this in your server's settings. Apart from that,
Trojita works as designed.

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

[trojita] [Bug 375151] Network Error: connection closed by remote host

[Jan Kundrát]

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

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
Yeah, this is either the IMAP server imposing a ~150 second timeout for IDLE
(the standard requires at least thirty minutes), or some network middlebox
along the way breaking the TCP connection -- and that sounds much more likely,
given that the server doesn't send a "* BYE".

Are you sure that there's nothing like a crappy wifi router or an overly
restrictive NAT box on your connection? If so, then activating the option that
Thomas suggested will help Trojita work on despite the network flakiness.

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

[trojita] [Bug 375143] Running a deletion task takes ~10 seconds per deletion

[Jan Kundrát]

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
Hi Tao, could you please post a log where you actually attempt to delete some
messages as you usually do? The log which is attached here doesn't contain any
traffic related to message deleting. I'm trying to understand whether it's the
server auto-expunging for you and thereby imposing a non-IMAP delete model, or
something completely different.

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

[trojita] [Bug 375143] Running a deletion task takes ~10 seconds per deletion

[Jan Kundrát]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Please attach raw IMAP logs when this happens. You can get access to them from
IMAP -> Debugging -> Show IMAP protocol log; the last tab is probably going to
be the important one.

Also, how is this shown to the UI? How long does it take for a message to
appear in a strike-thourgh font in the listing of messages? How/when do you
invoke the Expunge action?

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

[trojita] [Bug 358485] CardDAV support

[Jan Kundrát]

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

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Yup, that's one possibility, too. I'll be happy to review patches which make it
possible to call out to external programs for address book management; check
src/Plugins/AddressbookPlugin.h for the required API.

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

[trojita] [Bug 374959] Error on 'Expunge': UnrecognizedResponseKind: -1

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |UPSTREAM
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Thanks. This is a bug in your IMAP server (Zimbra, right?). Please report this
issue to them.

If this isn't solved by a reconnect, please reopen this with full a IMAP
protocol trace (IMAP -> Debugging -> show IMGP protocol log). If it's just a
transient error, though, I would prefer to leave this diagnostics as-is.

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

[trojita] [Bug 341982] Messages in base64 with a trailer do not display

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
  Latest Commit||https://commits.kde.org/tro
   ||jita/dc563cf4f6476afad684b3
   ||c8e6ebd820233ab07f

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Git commit dc563cf4f6476afad684b3c8e6ebd820233ab07f by Jan Kundrát.
Committed on 02/01/2017 at 21:08.
Pushed by gerrit into branch 'master'.

IMAP: Retry by fetching the raw part on [UNKNOWN-CTE]

An IMAP server supporting the BINARY extension can return UNKNOWN-CTE
when decoding of a message part failed. In particular, Dovecot simply
says * NO [UNKNOWN-CTE] for these parts.

Let's go back to local decoding for those parts which actually failed to
load upon seeing the [UNKNOWN-CTE] response code. Try to check it
regardless if it came in an OK or NO response for the FETCH command.
Change-Id: Ie782f0c89879cc270234e7f057ab3fe38364a12d

M  +2-0src/Imap/Model/MailboxTree.cpp
M  +2-0src/Imap/Model/MailboxTree.h
M  +1-1src/Imap/Model/Model.cpp
M  +41   -3src/Imap/Tasks/FetchMsgPartTask.cpp
M  +1-0src/Imap/Tasks/FetchMsgPartTask.h
M  +106  -0tests/Imap/test_Imap_BodyParts.cpp
M  +2-0tests/Imap/test_Imap_BodyParts.h

https://commits.kde.org/trojita/dc563cf4f6476afad684b3c8e6ebd820233ab07f

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
Git commit 1faa911b5331ad6196165c739fa5f5f6134593a9 by Jan Kundrát.
Committed on 02/01/2017 at 22:07.
Pushed by gerrit into branch 'master'.

GUI: Show accurate error message when a part fails to load in the GUI

The code should distinguish between being offline and parts failing for
some other reason.
Change-Id: I858d79d88c4c51a25ca8cb3a493dd144f1cc366f

M  +17   -4src/Gui/EmbeddedWebView.cpp
M  +10   -2src/Imap/Network/MsgPartNetworkReply.cpp
M  +1-1tests/Imap/test_Imap_MsgPartNetAccessManager.cpp

https://commits.kde.org/trojita/1faa911b5331ad6196165c739fa5f5f6134593a9

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

[trojita] [Bug 341982] Messages in base64 with a trailer do not display

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
  Latest Commit||https://commits.kde.org/tro
   ||jita/dc563cf4f6476afad684b3
   ||c8e6ebd820233ab07f

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Git commit dc563cf4f6476afad684b3c8e6ebd820233ab07f by Jan Kundrát.
Committed on 02/01/2017 at 21:08.
Pushed by gerrit into branch 'master'.

IMAP: Retry by fetching the raw part on [UNKNOWN-CTE]

An IMAP server supporting the BINARY extension can return UNKNOWN-CTE
when decoding of a message part failed. In particular, Dovecot simply
says * NO [UNKNOWN-CTE] for these parts.

Let's go back to local decoding for those parts which actually failed to
load upon seeing the [UNKNOWN-CTE] response code. Try to check it
regardless if it came in an OK or NO response for the FETCH command.
Change-Id: Ie782f0c89879cc270234e7f057ab3fe38364a12d

M  +2-0src/Imap/Model/MailboxTree.cpp
M  +2-0src/Imap/Model/MailboxTree.h
M  +1-1src/Imap/Model/Model.cpp
M  +41   -3src/Imap/Tasks/FetchMsgPartTask.cpp
M  +1-0src/Imap/Tasks/FetchMsgPartTask.h
M  +106  -0tests/Imap/test_Imap_BodyParts.cpp
M  +2-0tests/Imap/test_Imap_BodyParts.h

https://commits.kde.org/trojita/dc563cf4f6476afad684b3c8e6ebd820233ab07f

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
Git commit 1faa911b5331ad6196165c739fa5f5f6134593a9 by Jan Kundrát.
Committed on 02/01/2017 at 22:07.
Pushed by gerrit into branch 'master'.

GUI: Show accurate error message when a part fails to load in the GUI

The code should distinguish between being offline and parts failing for
some other reason.
Change-Id: I858d79d88c4c51a25ca8cb3a493dd144f1cc366f

M  +17   -4src/Gui/EmbeddedWebView.cpp
M  +10   -2src/Imap/Network/MsgPartNetworkReply.cpp
M  +1-1tests/Imap/test_Imap_MsgPartNetAccessManager.cpp

https://commits.kde.org/trojita/1faa911b5331ad6196165c739fa5f5f6134593a9

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

[trojita] [Bug 374830] Context menu on e-mail address should offer "Copy e-mail address"

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
(In reply to Pali Rohár from comment #1)
> Now when I see this link, it should be changed to
> "mailto:?To=joe%20%3c...@example.com%3E; as X-Trojita-DisplayName means to
> create new email with header X-Trojita-DisplayName -- which is incorrect.

These links should never leave Trojita, so it's up to us to construct them in
whatever way we like.

Robert is right in that this particular item should be changed to only copy the
raw e-mail address.

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

[trojita] [Bug 374824] More user-configurable keys/key bindings for moving in list of messages vs scrolling a selected message

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

Summary|Configure moving in list of |More user-configurable
   |messages vs scrolling a |keys/key bindings for
   |selected message|moving in list of messages
   ||vs scrolling a selected
   ||message

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

[trojita] [Bug 374819] When dragging a collapsed thread, all messages in the thread should be moved

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
That makes sense. Note that there's been some changes in current master since
the v0.7 release which at least make actions such as "mark as read" or "mark as
deleted" work on an entire thread when operating on a collapsed root.

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

[trojita] [Bug 374821] Previously selected message should be shown when a mailbox is opened

[Jan Kundrát]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Selecting a message has side-effects such as starting a timer which marks it
read after a short while. I would like to wait for further feedback from other
users before we make a change here.

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

[trojita] [Bug 374820] Keyboard shortcuts should be active without clicking on a message in a mailbox

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |NEEDSINFO

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
What version is that? If it's from git, what exact commit is it?

https://gerrit.vesnicky.cesnet.cz/r/809 fixed this.

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

[trojita] [Bug 374859] Local e-mail threading

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1
Summary|Threaded view not really|Local e-mail threading
   |threaded|

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
(In reply to Robert Kratky from comment #2)
> Pardon my ignorance... what's a hamburger icon?

Ah, that's probably a KDE-ism. Since you haven't said what version you're on
and because newer versions of Trojita merged the main into the toolbar by
default, you have to click an icon in the toolbar to get access to it. It's on
a lower left corner on this screenshot,
http://trojita.flaska.net/img/2016-03-22-trojita-home.png, and someone
suggested that it looks like a hamburger :].

> > If you have suggestions on how to better reflect this state in the UI,
> > please propose them here.
> Not sure what you mean. If the client doesn't know about the threading, how
> could it be reflected in the GUI?

You invested time by opening a bugreport which means that you were surprised to
see broken threading -- I understand that, that makes sense, and I appreciate
the feedback. So maybe there's something that we can do so that we won't get a
similar bugreport in future? (Apart from actually implementing this :). )

Maybe a pop-up or a mouse-over text next to the action in the menu? Something
else? A color-coded icon showing the "level of suckiness" of the IMAP server?
I'm looking for suggestions.

> The code that supports this surely exists somewhere. Other clients, incl.
> Kmail, support this threading. Wouldn't it be possible to reuse it? (I'm not
> a programmer, so I can't contribute code, unfortunately.)

Yes, other projects have solved this, but taking code from an external project
or even simply using a well-maintained library needs integration work. And
because I don't really need this feature myself, I don't see me investing my
time to write this. Patch review and guidance, yes, writing code, no.

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

[trojita] [Bug 374798] Add "Save link as" to context menu in messages

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
(In reply to Robert Kratky from comment #5)
> The problem with the round trip through the browser is that I have my
> desktop environment configured in a way that only a certain limited subset
> of MIME types is opened through the browser when I click on them. For
> example, I use an image viewer to open images by default. So, when I click
> on a URL that points to an image in Trojita, the file is opened by the image
> viewer.
> 
> Now, that particular helper app that's used to open a specific type of file
> may or may not have the functionality to save that file to a disk (for
> example, my GIF viewer isn't capable of doing that). So, I'm stuck with two
> options:
> 
> * copy the URL from Trojita and use wget or similar
> * copy the URL from Trojita and open in a browser
> 
> Both are possible but both are annoying and the 'round trip' has gotten a
> lot more complicated than just clicking on a link.

The DE that I use (Plasma) has a switch which controls whether an URL is always
opened in a web browser, or whether the MIME type is guessed/checked (I don't
actually know, maybe it uses its generic network stack to download or HTTP HEAD
it first) and then an appropriate local application is used for its handling.
Perhaps you can use a similar feature as well?

I believe that it's the job of the "rest of the desktop environment" to provide
a wrapper which gets triggered when a user "just clicked a web link" to ask
what they intend to do. I don't want to manage filetype associations within
Trojita, either; these are bits which we simply delegate to the DE.

> I don't see that many examples of this in my workflow, but wouldn't it be
> possible for Trojita to time out in such cases and report something like
> 'Unable to access'? I don't know how Trojita handles HTML content in
> messages, but the fact that it's capable of displaying it properly rendered
> means that it must be capable of downloading arbitrary stuff from the
> Internet, or not?

Yes, the libraries which we use can be asked to download stuff from the
Internet. However, this is limited to e-mail display, there's no extra UI, no
download resuming and what not. There's no user-facing download manager tied to
the HTTP stack.

> That's a good point, but couldn't this be hidden, for example, behind the
> systray icon? And I don't mean progress bars or something like that. Just a
> note that Trojita is trying to access so and so. Just an idea.

It can be done for sure. But I do not think that this /should/ be done within a
MUA.

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

[trojita] [Bug 374832] Auto trimming of replies should be configurable

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

   Severity|normal  |wishlist
   Priority|NOR |LO
 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Yes, the reply is always quoting exactly what is shown to the user.

It's an interesting suggestion to have the quote collapsing parameters exposed
to the user in some way. Patches (or even suggestions) are welcome. The
implementation lives in src/UiUtils/PlainTextFormatter.cpp , the numeric
parameters can be found there.

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

[trojita] [Bug 374859] Threaded view not really threaded

[Jan Kundrát]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
This functionality depends on a server-side support ([1] and [2]) for e-mail
threads. Chances are that your IMAP server might only support
THREAD=ORDEREDSUBJECT which indeed sucks exactly like you described. You can
check the dialog under the hamburger icon -> IMAP -> Debugging -> IMAP Server
Information for a list of announced capabilities to confirm this.

We do not do client-side threading because doing that would require Trojita to
download a subset of header for each message in an entire mailbox. It is a
design decision -- we rely on IMAP features so that the server can do work on
our behalf and that we do not have to transfer data that we do not really need.
Unfortunately, this means that the end user experience is worse in case their
e-mail server leaves something to be desired. Right now for example we won't do
any threading on GMail because GMail servers have their own proprietary
extension for one-level-deep threading and because we don't have code to work
with this non-standard extension yet (patches welcome).

If you have suggestions on how to better reflect this state in the UI, please
propose them here.

If someone wants to contribute code which adds support for client-side
threading, I'll be happy to review the patches and to provide suggestions on
how to best approach the problem. However, I don't see myself actively working
on this.

[1] https://tools.ietf.org/html/rfc5256
[2] https://tools.ietf.org/html/draft-ietf-morg-inthread-01

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

[trojita] [Bug 374798] Add "Save link as" to context menu in messages

[Jan Kundrát]

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
> Right click on a URL, select 'Save link as', which opens a save-file dialog
> window that lets me choose where I want to save the file.

That was sort of obvious :), but I wonder what do you want/use this for. 
What's wrong with a roundtrip through your browser? Click a link -> your 
browser asks you what to do -> the browser performs the required work.

As an anecdotal data point about my specific usage patterns: when a link 
refers to something which is not a web page, it's very often something 
which requires authentication anyway. Trojita won't know what to do in that 
case.

We also do not want to deal with showing a progress GUI of possibly N 
concurrent downloads, to track their state, to make this list persistent 
and to recover from OS/session restarts, etc. In short, as Thomas said, 
Trojita is not a download manager.

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

[trojita] [Bug 374798] Add "Save link as" to context menu in messages

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

   Severity|normal  |wishlist

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Can you please explain what use case do you have in mind? How do you usually
use this feature in another MUA?

Technical stuff -- this is tricky to do in a cross-platform way. I've got no
clue how it works on Windows or Mac, but a XDG-compatible system ("desktop
Linux") usually uses `xdg-open` for accessing remote content, and that's what
Trojita uses as well. Technically, it's wrapped by a QDesktopServices::openUrl
and it might end up calling a DE-specific script and following the user's
preferences. These facilities however do not distinguish between a "please open
this URL" and a "please download content from this location".

When such a feature exists I'll be happy to use it, but I don't see us actually
driving and pushing the standardization effort.

But I see that our pop-up menu offers a lot of options when clicking a link;
that could probably be downscaled a bit.

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

[trojita] [Bug 374457] New: Unsafe iteration in void Model::responseReceived()

[Jan Kundrát]

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

Bug ID: 374457
   Summary: Unsafe iteration in void Model::responseReceived()
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: IMAP
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org
  Target Milestone: ---

Here's a real segfault, possibly triggered by network reconnects:

Thread 1 "trojita" received signal SIGSEGV, Segmentation fault.
QMapNodeBase::nextNode (this=0x31e7280) at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/tools/qmap.cpp:58
58 
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/tools/qmap.cpp:
No such file or directory.
(gdb) bt
#0  QMapNodeBase::nextNode (this=0x31e7280) at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/tools/qmap.cpp:58
#1  0x005747f3 in QMapNodeBase::nextNode (this=0x31e7280) at
/usr/include/qt5/QtCore/qmap.h:96
#2  QMapNode::nextNode
(this=0x31e7280) at /usr/include/qt5/QtCore/qmap.h:124
#3  QMap::iterator::operator++
(this=) at /usr/include/qt5/QtCore/qmap.h:432
#4  Imap::Mailbox::Model::responseReceived (this=) at
/home/jkt/work/prog/trojita/src/Imap/Model/Model.cpp:147
#5  0x73416a9a in QObject::event (this=0xae7fe0, e=)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qobject.cpp:1263
#6  0x73cae394 in QApplicationPrivate::notify_helper (this=, receiver=0xae7fe0, e=0x19543f0)
at
/var/tmp/portage/dev-qt/qtwidgets-5.7./work/qtwidgets-5.7./src/widgets/kernel/qapplication.cpp:3799
#7  0x73cb65a6 in QApplication::notify (this=0x7fffd620,
receiver=0xae7fe0, e=0x19543f0)
at
/var/tmp/portage/dev-qt/qtwidgets-5.7./work/qtwidgets-5.7./src/widgets/kernel/qapplication.cpp:3556
#8  0x733e6bd8 in QCoreApplication::notifyInternal2 (receiver=0xae7fe0,
event=event@entry=0x19543f0)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qcoreapplication.cpp:988
#9  0x733e98e7 in QCoreApplication::sendEvent (event=0x19543f0,
receiver=)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qcoreapplication.h:231
#10 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0,
event_type=event_type@entry=0, data=0x941fb0)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qcoreapplication.cpp:1649
#11 0x733e9ebe in QCoreApplication::sendPostedEvents
(receiver=receiver@entry=0x0, event_type=event_type@entry=0)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qcoreapplication.cpp:1503
#12 0x73440499 in postEventSourceDispatch (s=0x998770)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qeventdispatcher_glib.cpp:276
#13 0x7fffedf7980c in g_main_dispatch (context=0x7fffe00016f0) at
/var/tmp/portage/dev-libs/glib-2.48.2/work/glib-2.48.2/glib/gmain.c:3154
#14 g_main_context_dispatch (context=context@entry=0x7fffe00016f0) at
/var/tmp/portage/dev-libs/glib-2.48.2/work/glib-2.48.2/glib/gmain.c:3769
#15 0x7fffedf79b18 in g_main_context_iterate
(context=context@entry=0x7fffe00016f0, block=block@entry=1,
dispatch=dispatch@entry=1, self=)
at /var/tmp/portage/dev-libs/glib-2.48.2/work/glib-2.48.2/glib/gmain.c:3840
#16 0x7fffedf79c21 in g_main_context_iteration (context=0x7fffe00016f0,
may_block=1) at
/var/tmp/portage/dev-libs/glib-2.48.2/work/glib-2.48.2/glib/gmain.c:3901
#17 0x7344054d in QEventDispatcherGlib::processEvents (this=0x9b5c70,
flags=...)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qeventdispatcher_glib.cpp:423
#18 0x733e517a in QEventLoop::exec (this=this@entry=0x7fffd480,
flags=..., flags@entry=...)
at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qeventloop.cpp:212
#19 0x733ee116 in QCoreApplication::exec () at
/var/tmp/portage/dev-qt/qtcore-5.7./work/qtcore-5.7./src/corelib/kernel/qcoreapplication.cpp:1261
#20 0x00443758 in main (argc=, argv=) at
/home/jkt/work/prog/trojita/src/Gui/main.cpp:214

IMHO that generic responseReceived() should not exist -- it seems that we
should always know about what connection any response belongs to.

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

[trojita] [Bug 374000] Trojita fails to load, re-location error

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DOWNSTREAM

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

[trojita] [Bug 373374] Test failures with gnupg-2.1.16

[Jan Kundrát]

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
Git commit 60ad50c873679fb23f52eee6b4df6832889b1098 by Jan Kundrát.
Committed on 07/12/2016 at 12:05.
Pushed by gerrit into branch 'master'.

tests: GPG: Explicitly check that the crypto ops have finished

This is meant to improve the readability of the error messages during
eventual test failures.

Also unify the form of the check that we use among all of these tests.
Consistency is good.

Change-Id: I638607c0742a295cf29b61a1434d313e7618dc8a
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1401716

M  +4-2tests/Cryptography/test_Cryptography_PGP.cpp

https://commits.kde.org/trojita/60ad50c873679fb23f52eee6b4df6832889b1098

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

[gwenview] [Bug 347157] Color management with rendering intent and custom monitor profile support

[Jan Kundrát]

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

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
(In reply to DrSlony from comment #5)
> I would not consider this issue to be closable as Gwenview lacks the basic
> settings described in the first comment.

I believe that this bug is effectively a duplicate of these two:

- rendering intent: #359909
- custom monitor profiles: #360075

> colord-kde didn't work with Plasma last time I tried it, Argyll's dispwin
> simply sets the X11 atom, Oyranos didn't work with Plasma last time I tried
> it, kolor-manager is dead last time I checked, I don't recall any others...

FYI, I've been using colord-kde with Plasma 5 for several years. I'm seeing
some issues with auto-applying a monitor profile during hotplug events and
docking/undocking which sometimes require a restart of the KDE's color daemon
service. That's off-topic here, though.

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

[gwenview] [Bug 360075] No way to control color management

[Jan Kundrát]

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

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
> Random example for point 1: because you want to match what you see in
> Gwenview to what you see in your non-colormanaged web browser.

I do not consider a checkbox "ignore system settings and reproduce buggy
behavior of a non-color-managed web browser" to be a reasonable use case for a
basic image viewer.

Yes, I can think of use cases where this might be handy. As you say, one might
want to check what a different user with a different wide-gamut screen will see
in their non-color managed web browser. I might also want to check how my
printed pictures will look like. These are good use cases in general, but I
don't think that they are good use cases for Gwenview given the available
manpower.

Feel free to disagree and reopen this bug; maybe someone will tackle it.

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

[gwenview] [Bug 359909] Monitor profile should use relative colorimetric rendering intent by default

[Jan Kundrát]

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

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
(In reply to DrSlony from comment #5)
> "TL;DR"? What an attitude!

That was meant as a TL;DR summary of my comment for your convenience. It was
not a TL;DR reaction to the bugreport of course (note the colon). Apologies for
that ambiguity.

> perceptual screws the colors up, all of them. Not all people will experience
> this because not all ICC profiles support perceptual.

Yes, that's true. However, a similar argument can me made against relative
colorimetric rendering intent and in favor of perceptual: "relative
colorimetric rendering intent hides fine detail".

> You'd only want perceptual's complete gamut compression in rare cases.

The resources I was able to find suggest that there are reasons for both
relative colorimetric and perceptual when it comes to displaying photos (which,
I believe, is the main use case for Gwenview). I'm all for a patch which makes
this user-configurable for those who care, and I'm also interested in a
discussion about which one is better by default for photographs.

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

[gwenview] [Bug 373178] Blurry scaling on HiDPI

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 CC||j...@kde.org

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

[gwenview] [Bug 363906] Default extension for JPEG files should be JPG or JPEG

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DOWNSTREAM
 CC||j...@kde.org

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Please open a bug in your distribution's bugtracker. The file extension is not
specified by Gwenview, it comes indirectly from the shared-mime-info database
(/usr/share/mime/packages/freedesktop.org.xml etc).

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

[gwenview] [Bug 361887] gwenview shows wrong colours

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
You have probably installed a testing color profile for your screen. Ensure
that your system's settings do not have these profiles installed.

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

[gwenview] [Bug 361887] gwenview shows wrong colours

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 CC||j...@kde.org

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

[gwenview] [Bug 359091] Gwenview is taking >600MB of RAM when opening file.

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||j...@kde.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Hi Edwin,
what number are you looking at? By default, programs such as `top` show the
amount of mapped virtual memory which is irrelevant -- right now, a simple GTK
version of Vim is shown as "taking" 434MB of RAM on my system while its actual
exclusive memory usage ("RSS") is < 30MB.

See e.g.
http://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management
.

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

[gwenview] [Bug 360075] No way to control color management

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 CC||j...@kde.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
(In reply to DrSlony from comment #0)
> 1- A possibility to toggle color management on/off. Just because one has the
> _X11_PROFILE set doesn't mean one needs to use it. 

I disagree. To my understanding, this is what that atom is for. Why do you set
it when you do not plan to use it?

> 2- A possibility to select a different monitor profile. A very common
> misconception is that there is such a thing as "one correct profile", but
> that is not true. A monitor profile serves a purpose - you could have one
> for working on typical photos, one for working on photos with extreme colors
> where they must not be clipped, one for matching prints, etc.

Understood -- but perhaps you might want to use a tool which supports
soft-proofing when you want to soft-proof rather than changing your screen's
color profile.

(In reply to george from comment #1)
> I am using openSUSE Leap 42.1 and the latest gwenview from the official repo
> (in Help > About I get 4.14.0 pre)

That's two years old now.

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

[gwenview] [Bug 371637] gwenview

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |UNMAINTAINED
 CC||j...@kde.org

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Sorry, that version is two years old now and looks like a breakage due to
mismatches libexiv2. Talk to whoever provided you with gwenview and libexiv2
packages.

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

[gwenview] [Bug 373178] Blurry scaling on HiDPI

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 CC||wen...@gmail.com

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
*** Bug 354533 has been marked as a duplicate of this bug. ***

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

[gwenview] [Bug 354533] Support HiDPI in gwenview

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jan Kundrát <j...@kde.org> ---


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

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

[gwenview] [Bug 359909] Monitor profile should use relative colorimetric rendering intent by default

[Jan Kundrát]

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
TL;DR: Could you please explain why gwenview should use relative colorimetric
rendering intent?

I understand the reason for providing an option for the rendering intent
selection.

What I do not understand is your reasoning to use relative colorimetric
rendering intent by default for all users. I should probably add that I had to
look up the definitions of these two on a random website and I won't pretend
that I know much about colorimetry. (Stuff at
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm looks
usable.)

As a random data point, I asked what Darktable (my favorite RAW photo editor)
uses. It seems that by default they do absolute colorimetric for display. When
a setting to use LCMS is enabled, it defaults to perceptual.

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

[gwenview] [Bug 359909] Monitor profile should use relative colorimetric rendering intent by default

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 CC||j...@kde.org

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

[gwenview] [Bug 347157] Color management with rendering intent and custom monitor profile support

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
...which means that this bug can be closed. Yes, gwenview uses your systemwide
monitor profile which can be set by a plethora of tools (colord-kde, argyll,
etc).

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

[trojita] [Bug 373374] Test failures with gnupg-2.1.16

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
I'm having lots of fun so far.

I did some debugging and it seems to me that my gpg-agent started deadlocking:

(gdb) t a a bt

Thread 3 (Thread 0x7fcaa700 (LWP 23673)):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7fcab5369f65 in __GI___pthread_mutex_lock (mutex=0x7fcab5ecbd08
<pool_lock+8>) at ../nptl/pthread_mutex_lock.c:81
#2  0x0080 in ?? ()
#3  0x7fcaa8003aa0 in ?? ()
#4  0x7fcab60e6a20 in ?? ()
#5  0x7fcaafffeaf0 in ?? ()
#6  0x7fcab5c87b7a in _gcry_mpi_randomize (w=0x80, nbits=,
level=)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/mpi/mpiutil.c:655
#7  0x in ?? ()

Thread 2 (Thread 0x7fcab4fb3700 (LWP 23657)):
#0  0x7fcab536fb8b in futex_abstimed_wait_cancelable (private=0,
abstime=0x0, expected=0, futex_word=0x7fcab5782080 )
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x7fcab5782080 , abstime=0x0)
at sem_waitcommon.c:111
#2  0x7fcab536fc5c in __new_sem_wait_slow (sem=0x7fcab5782080
, abstime=0x0) at sem_waitcommon.c:181
#3  0x7fcab536fd0e in __new_sem_wait (sem=) at sem_wait.c:29
#4  0x7fcab557fdc1 in leave_npth () at
/var/tmp/portage/dev-libs/npth-1.2/work/npth-1.2/src/npth.c:134
#5  0x7fcab558061c in npth_usleep (usec=) at
/var/tmp/portage/dev-libs/npth-1.2/work/npth-1.2/src/npth.c:497
#6  0x7fcab5c7e302 in _gcry_rndlinux_gather_random (add=0x7fcab5c794e0
, origin=RANDOM_ORIGIN_SLOWPOLL, length=90, level=)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/rndlinux.c:205
#7  0x7fcab5c79092 in read_random_source
(origin=origin@entry=RANDOM_ORIGIN_SLOWPOLL, length=length@entry=120,
level=level@entry=1)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/random-csprng.c:1275
#8  0x7fcab5c7a184 in random_poll () at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/random-csprng.c:1101
#9  read_pool (level=0, length=, buffer=0x7fcab5ecc6a4
<nonce_buffer+20> "")
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/random-csprng.c:995
#10 _gcry_rngcsprng_randomize (buffer=, length=,
level=GCRY_WEAK_RANDOM)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/random-csprng.c:538
#11 0x7fcab5c78efb in _gcry_randomize (level=GCRY_WEAK_RANDOM, length=8,
buffer=0x7fcab5ecc6a4 <nonce_buffer+20>)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/random.c:341
#12 _gcry_create_nonce (buffer=buffer@entry=0x7fcab60e6228,
length=length@entry=128)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/random/random.c:466
#13 0x7fcab5c87b7a in _gcry_mpi_randomize (w=w@entry=0x7fcab0003ab0,
nbits=nbits@entry=1024, level=level@entry=GCRY_WEAK_RANDOM)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/mpi/mpiutil.c:655
#14 0x7fcab5c49e2d in secret_blinded (output=0x7fcab0003a90,
input=0x7fcab0001d70, sk=0x7fcab4fb2b90, nbits=1024)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/cipher/rsa.c:1067
#15 0x7fcab5c4a6d5 in rsa_decrypt (r_plain=0x7fcab4fb2d08,
s_data=, keyparms=0x7fcab0003880)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/cipher/rsa.c:1365
#16 0x7fcab5bd451f in _gcry_pk_decrypt
(r_plain=r_plain@entry=0x7fcab4fb2d08, s_data=s_data@entry=0x7fcab00030f0,
s_skey=s_skey@entry=0x7fcab00031a0)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/cipher/pubkey.c:377
#17 0x7fcab5bbe0d6 in gcry_pk_decrypt (result=result@entry=0x7fcab4fb2d08,
data=0x7fcab00030f0, skey=0x7fcab00031a0)
at
/var/tmp/portage/dev-libs/libgcrypt-1.7.3/work/libgcrypt-1.7.3/src/visibility.c:985
#18 0x55e5d82880e9 in agent_pkdecrypt (ctrl=ctrl@entry=0x55e5d89c7d60,
desc_text=, ciphertext=0x7fcab0001ed0
"(7:enc-val(3:rsa(1:a129:", 
ciphertextlen=156, outbuf=outbuf@entry=0x7fcab4fb2d90,
r_padding=r_padding@entry=0x7fcab4fb2d7c) at pkdecrypt.c:109
#19 0x55e5d8278412 in cmd_pkdecrypt (ctx=0x7fcab8f0, line=) at command.c:849
#20 0x7fcab578c60d in dispatch_command (ctx=0x7fcab8f0, line=, linelen=) at assuan-handler.c:675
#21 0x7fcab578ca7f in process_request (ctx=0x7fcab8f0) at
assuan-handler.c:871
#22 assuan_process (ctx=0x7fcab8f0) at assuan-handler.c:894
#23 0x55e5d827b31b in start_command_handler (ctrl=0x55e5d89c7d60,
listen_fd=, fd=) at command.c:3304
#24 0x55e5d82730b9 in do_start_connection_thread (ctrl=0x55e5d89c7d60) at
gpg-a

[trojita] [Bug 373374] Test failures with gnupg-2.1.16

[Jan Kundrát]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
OK, it seems that for those tests where validation should actually succeed, 
GnuPG::Context::decryptAndVerify never returns. Here's what remains running in
the system after these failures (two test rows actually happen):

jkt@kolibrik ~/work/prog/_trojita-build/qt5 $ ps -ef | grep gnupg
jkt  11066  3509  0 01:37 pts/500:00:00 grep --colour=auto gnupg
jkt@kolibrik ~/work/prog/_trojita-build/qt5 $ ps -ef | grep gpg
jkt   8492 1  0 01:15 ?00:00:00 gpg-agent --homedir
/home/jkt/work/prog/_trojita-build/qt5/keys --use-standard-socket --daemon
jkt  11017 1  0 01:37 pts/500:00:00 gpg2 --enable-special-filenames
--batch --no-sk-comments --status-fd 7 --no-tty --charset utf8
--enable-progress-filter --exit-on-status-write-error --display :0 --decrypt
--output - -- -&10
jkt  11023 1  0 01:37 pts/500:00:00 gpg2 --enable-special-filenames
--batch --no-sk-comments --status-fd 9 --no-tty --charset utf8
--enable-progress-filter --exit-on-status-write-error --display :0 --decrypt
--output - -- -&12
jkt  11074  3509  0 01:37 pts/500:00:00 grep --colour=auto gpg
jkt@kolibrik ~/work/prog/_trojita-build/qt5 $ lsof -p 8492
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
  Output information may be incomplete.
COMMANDPID USER   FD  TYPE DEVICE SIZE/OFF  NODE NAME
gpg-agent 8492  jkt  cwd   DIR  254,0  24896 /
gpg-agent 8492  jkt  rtd   DIR  254,0  24896 /
gpg-agent 8492  jkt  txt   REG  254,0   414360 274454906
/usr/bin/gpg-agent
gpg-agent 8492  jkt  mem   REG  254,0  1738328 410388282
/lib64/libc-2.22.so
gpg-agent 8492  jkt  mem   REG  254,0   105272 410395864
/lib64/libpthread-2.22.so
gpg-agent 8492  jkt  mem   REG  254,018248 269514259
/usr/lib64/libnpth.so.0.0.5
gpg-agent 8492  jkt  mem   REG  254,088112931164
/usr/lib64/libassuan.so.0.7.3
gpg-agent 8492  jkt  mem   REG  254,092128 134752584
/usr/lib64/libgpg-error.so.0.19.1
gpg-agent 8492  jkt  mem   REG  254,0  1166304 268688873
/usr/lib64/libgcrypt.so.20.1.3
gpg-agent 8492  jkt  mem   REG  254,0   148816 410388248
/lib64/ld-2.22.so
gpg-agent 8492  jkt  mem   REG  254,0  1745248 268688934
/usr/lib64/locale/locale-archive
gpg-agent 8492  jkt0r  CHR1,3  0t0  2051
/dev/null
gpg-agent 8492  jkt1w  CHR1,3  0t0  2051
/dev/null
gpg-agent 8492  jkt2w  CHR1,3  0t0  2051
/dev/null
gpg-agent 8492  jkt3u unix 0x88d6b3479800  0t0429639
/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent type=STREAM
gpg-agent 8492  jkt4u unix 0x88d6b3479c00  0t0429640
/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent.extra type=STREAM
gpg-agent 8492  jkt5u unix 0x88d6b3479400  0t0429641
/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent.browser type=STREAM
gpg-agent 8492  jkt6u unix 0x88d6b347a000  0t0429642
/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent.ssh type=STREAM
gpg-agent 8492  jkt7r  a_inode   0,110  8449
inotify
gpg-agent 8492  jkt8u unix 0x88d503b3e000  0t0429648
/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent type=STREAM
gpg-agent 8492  jkt9r  CHR1,9  0t0  2056
/dev/urandom
gpg-agent 8492  jkt   10u unix 0x88d9a0edf400  0t0427933
/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent type=STREAM
jkt@kolibrik ~/work/prog/_trojita-build/qt5 $ lsof -p 11017
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
  Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
gpg211017  jkt  cwdDIR  254,020480 174033037
/home/jkt/work/prog/_trojita-build/qt5
gpg211017  jkt  rtdDIR  254,0  24896 /
gpg211017  jkt  txtREG  254,0   991856 274761284
/usr/bin/gpg2
gpg211017  jkt  memREG  254,0   244416 402758332
/lib64/libtinfo.so.6.0
gpg211017  jkt  memREG  254,0  1738328 410388282
/lib64/libc-2.22.so
gpg211017  jkt  memREG  254,088112931164
/usr/lib64/libassuan.so.0.7.3
gpg211017  jkt  memREG  254,0   330624 135078460
/lib64/libreadline.so.6.3
gpg211017  jkt  memREG  254,092128 134752584
/usr/lib64/libgpg-error.so.0.19.1
gpg211017  jkt  memREG  254,0  1166304 268688873
/usr/lib64/libgcrypt.so.20.1.3
gpg211017  jkt  memREG  254,070520 402976937
/lib64/libbz2.so.1.0.6
gpg2

[trojita] [Bug 373374] New: Test failures with gnupg-2.1.16

[Jan Kundrát]

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

Bug ID: 373374
   Summary: Test failures with gnupg-2.1.16
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Cryptography
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org
  Target Milestone: ---

Continuing from https://bugzilla.redhat.com/show_bug.cgi?id=1401716 . It seems
that signature verification of our internal supposed-to-be-valid signature
doesn't conclude for some reason. Debug patch:

diff --git a/tests/Cryptography/test_Cryptography_PGP.cpp
b/tests/Cryptography/test_Cryptography_PGP.cpp
index 2d33a4d..bd9628c 100644
--- a/tests/Cryptography/test_Cryptography_PGP.cpp
+++ b/tests/Cryptography/test_Cryptography_PGP.cpp
@@ -110,6 +110,8 @@ void CryptographyPGPTest::testDecryption()
 }
 // allow for event processing, so that the model can retrieve the results
 QCoreApplication::processEvents();
+// ensure that we're done now
+QVERIFY(!data.data(Imap::Mailbox::RolePartCryptoNotFinishedYet).toBool());

 if (!qcaErrorSpy.isEmpty() && successful) {
 qDebug() << "Unexpected failure in crypto";


jkt@kolibrik ~/work/prog/_trojita-build/qt5 $ ninja && ctest -R
test_Cryptography_PGP -VV
[53/53] Linking CXX executable test_Cryptography_PGP
UpdateCTestConfiguration  from
:/home/jkt/work/prog/_trojita-build/qt5/DartConfiguration.tcl
UpdateCTestConfiguration  from
:/home/jkt/work/prog/_trojita-build/qt5/DartConfiguration.tcl
Test project /home/jkt/work/prog/_trojita-build/qt5
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 24
Start 24: test_Cryptography_PGP

24: Test command: /home/jkt/work/prog/_trojita-build/qt5/test_Cryptography_PGP
24: Environment variables: 
24:  UBSAN_OPTIONS=suppressions=/home/jkt/work/prog/trojita/tests/ubsan.supp
24: Test timeout computed to be: 9.99988e+06
24: * Start testing of CryptographyPGPTest *
24: Config: Using QtTest library 5.7.1, Qt 5.7.1 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 4.9.3)
24: PASS   : CryptographyPGPTest::initTestCase()
24: FAIL!  : CryptographyPGPTest::testDecryption(valid)
'!data.data(Imap::Mailbox::RolePartCryptoNotFinishedYet).toBool()' returned
FALSE. ()
24:Loc:
[/home/jkt/work/prog/trojita/tests/Cryptography/test_Cryptography_PGP.cpp(114)]
24: QDEBUG : CryptographyPGPTest::testDecryption(valid) We have 1 orphaned
crypto tasks
24: PASS   : CryptographyPGPTest::testDecryption(invalid)
24: FAIL!  : CryptographyPGPTest::testDecryption(expiredKey)
'!data.data(Imap::Mailbox::RolePartCryptoNotFinishedYet).toBool()' returned
FALSE. ()
24:Loc:
[/home/jkt/work/prog/trojita/tests/Cryptography/test_Cryptography_PGP.cpp(114)]
24: QDEBUG : CryptographyPGPTest::testDecryption(expiredKey) We have 1 orphaned
crypto tasks
24: PASS   : CryptographyPGPTest::testDecryption(unknownKey)
24: PASS   : CryptographyPGPTest::testDecryptWithoutEnvelope()
24: PASS   : CryptographyPGPTest::testVerification(valid-me)
24: PASS   :
CryptographyPGPTest::testVerification(my-signature-different-identity)
24: PASS   : CryptographyPGPTest::testVerification(my-signature-different-data)
24: PASS   :
CryptographyPGPTest::testVerification(invalid-implicit-content-type)
24: PASS   : CryptographyPGPTest::testMalformed(signed-missing-protocol-micalg)
24: PASS   :
CryptographyPGPTest::testMalformed(signed-ml-stripped-gpg-signature)
24: PASS   : CryptographyPGPTest::testOffline(signed)
24: PASS   : CryptographyPGPTest::testOffline(encrypted)
24: PASS   : CryptographyPGPTest::cleanupTestCase()
24: Totals: 13 passed, 2 failed, 0 skipped, 0 blacklisted, 21125ms
24: * Finished testing of CryptographyPGPTest *
1/1 Test #24: test_Cryptography_PGP ***Failed   21.14 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =  21.14 sec

The following tests FAILED:
 24 - test_Cryptography_PGP (Failed)
Errors while running CTest

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

[trojita] [Bug 368859] Use newer upstream gpgme to get rid of kf5-gpgmepp

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
FYI, genstorm has some patches for this, he'll probably Gerrit them over the
weekend. It seems that they only touch CMakeLists.txt, which is very cool.

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

[trojita] [Bug 366498] InvalidResponseCode due to a 64bit UIDNEXT

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |UPSTREAM

--- Comment #10 from Jan Kundrát <j...@kde.org> ---
Somebody else's bug -> closing.

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

[trojita] [Bug 342940] Replace popup dialog about network error with passive notification

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jan Kundrát <j...@kde.org> ---
Looks like something which is no longer an issue with these two commits.
Closing.

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

[trojita] [Bug 357679] Not enough shortcut key options

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
I think that the commit listed in comment #4 is as good as one can make it ->
closing. Please reopen if you disagree.

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

[trojita] [Bug 357677] Option to display brief headers

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
I think that the current state of the UI reflects some points originally
requested here. We won't be going for full configurability ("allow users to
specify arbitrary headers to show").

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

[trojita] [Bug 372168] Reply buttons are disabled when the MessageView is hidden

[Jan Kundrát]

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

--- Comment #17 from Jan Kundrát <j...@kde.org> ---
> 2 - if the message widget is hidden, one click open the message in the same 
> way 
> of the "One at Time" layout, instead of opening a second window.

I honestly do not think that this is discoverable without additional UI 
work. You would know how to use it because you offered this idea, but try 
to imagine someone new creating such a scenario by accident. IMHO, it would 
need some oobvious UI indication "hey, you should click here to go back".

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

[trojita] [Bug 321078] Save the state of the mailboxes treeview

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

  Latest Commit||8901a5c0465637e98bb998518ae
   ||644198d6728e2
 Resolution|--- |FIXED
   Version Fixed In||0.7
 Status|CONFIRMED   |RESOLVED

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
This has actually been fixed in a release for some time (v0.7).

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

[trojita] [Bug 321366] Dynamic and incremental mailbox discovery

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Blocks|321078  |


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=321078
[Bug 321078] Save the state of the mailboxes treeview
-- 
You are receiving this mail because:
You are watching all bug changes.

[trojita] [Bug 321078] Save the state of the mailboxes treeview

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Depends on|321366  |


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=321366
[Bug 321366] Dynamic and incremental mailbox discovery
-- 
You are receiving this mail because:
You are watching all bug changes.

[trojita] [Bug 372168] Reply buttons are disabled when the MessageView is hidden

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #14 from Jan Kundrát <j...@kde.org> ---
OK, this only happens when the message widget is hidden -- you're
double-clicking on messages to open them, that's why it happens.

Do you have a reason for this? We should probably prevent this widget hiding:

- there's no UI indicator of this,
- it has real support cost, as demonstrated by this bug.

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

[trojita] [Bug 372168] Reply buttons are disabled when the MessageView is hidden

[Jan Kundrát]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

Summary|trojita-0.7: can't use  |Reply buttons are disabled
   |reply.  |when the MessageView is
   ||hidden

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

[trojita] [Bug 372168] trojita-0.7: can't use reply.

[Jan Kundrát]

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

--- Comment #11 from Jan Kundrát <j...@kde.org> ---
Sorry, copy-paste error. The correct command is:

ACCEPT_KEYWORDS='**' EGIT_COMMIT=refs/changes/37/837/2 emerge -1 --nodeps 
=trojita-

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

[trojita] [Bug 372168] trojita-0.7: can't use reply.

[Jan Kundrát]

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

--- Comment #9 from Jan Kundrát <j...@kde.org> ---
Could you please emerge this, restart Trojita, see if you can reproduce this,
and post the console output?

ACCEPT_KEYWORDS='**' EGIT_BRANCH=refs/changes/37/837/2 USE=debug emerge -1
--nodeps =trojita-

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

[trojita] [Bug 372168] trojita-0.7: can't use reply.

[Jan Kundrát]

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

--- Comment #7 from Jan Kundrát <j...@kde.org> ---
Thanks for the logs.

- Do you use something for managing network? 
NetworkManager/connman/something else?

- What USE flags do you have for qtnetwork:5 ?

- If you're using NetworkManager, what is the output of `nmcli general 
status` when you see the behavior that you're describing?

- Please run Trojita from a terminal and provide its output.

- Please attach also logs from "Connection 0" (which should be the leftmost 
window).

- Does this get fixed when you reconnect (go offline, go back online, 
select another message)?

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

[trojita] [Bug 372168] trojita-0.7: can't use reply.

[Jan Kundrát]

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

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
- What Qt version is that?
- Do you have any selected e-mail? Can you please show us a screenshot of 
the whole window?
- Please attach the IMAP logs (IMAP -> Debugging -> ...)

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

[trojita] [Bug 372135] icon name for tray and notification

[Jan Kundrát]

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

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
Just FYI, the icon is being loaded through a theme-aware lookup already, so if
-- for example -- the Breeze icon theme starts including an appropriate themed
icon, it will be automatically used.

But I can see that it makes sense to use a slightly different icon for the
tray. I won't have time for this "soon", so if you can make a change, please go
for it. A correct place for changing the icon is
MainWindow::handleTrayIconChange in src/Gui/Window.cpp; the icons are defined
in src/icons.qrc.

Regarding a proper notification system, sure -- that will (eventually) come in
future. Help is appreciated.

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

[trojita] [Bug 371451] Default hyperlink color makes link unreadable with dark theme

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Trojita doesn't set up these colors on its own, it simply follows the
instructions of the platform theme, so it seems that the theme (or theme
engine?) you use fails to set a usable color for hyperlinks. There's nothing to
do on Trojita's side to fix this.

Not sure if this helps you:
https://wiki.archlinux.org/index.php/Uniform_look_for_Qt_and_GTK_applications

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

[trojita] [Bug 369832] PartStatusWidget hides additional lines of text

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Git commit 654188c2806c376a4c2b9cdf44e48172c2255a18 by Jan Kundrát.
Committed on 03/10/2016 at 20:09.
Pushed by gerrit into branch 'master'.

GUI: Prevent excessive newlines in the PartStatusWidget crypto messages

Previously, there were extra newlines in certain scenarios. The long
text should never begin with a stray newline.

This might make it easier to see the linked bug.

Change-Id: I72188b08f1562b6cdd30849f9958fdcc9f0504b7

M  +44   -21   src/Cryptography/GpgMe++.cpp

http://commits.kde.org/trojita/654188c2806c376a4c2b9cdf44e48172c2255a18

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

[trojita] [Bug 369832] PartStatusWidget hides additional lines of text

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
No joy (breeze on plasma from git, about a week old master, Qt 5.7 from 
about a week old git).

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

[trojita] [Bug 369558] Broken Encrypted Message

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
Thanks for debugging this and for reporting the result.

I tried to find a way for gpgme to forward the gpg's warning about the gnome
keyring so that we can display it, but I don't think there's a function for
that, unfortunately.

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

[trojita] [Bug 369832] New: PartStatusWidget hides additional lines of text

[Jan Kundrát via KDE Bugzilla]

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

Bug ID: 369832
   Summary: PartStatusWidget hides additional lines of text
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Desktop GUI
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org

Thomas, could you please take a look at this?

1) ensure that gpg-agent is not running or make it forget passwords (`echo
RELOADAGENT | gpg-connect-agent` or a SIGHUP should help)
2) open an encrypted e-mail, wait until a password prompt appears
3) cancel the password prompt
4) click "Show Details" to see just one line of text (no information about the
intended recipients)
5) resize the message widget so that its width becomes "small enough"
6) watch the new line appear
7) make that widget slightly wider
8) watch the line disappear once again

The long status should either be shown completely (when the status widget is
expanded), or not at all (when hidden by that button). Showing just one line of
text is wrong.

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

[trojita] [Bug 369558] Broken Encrypted Message

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
> "Decryption error: Decryption failed
> Encrypted to (my identity name and email here)"

Did you get a prompt asking for your GPG password?

What versions of GPG, gpgme and pinentry (and what flavor of pinentry) do 
you use?

> Is there any log I can view to diagnose this issue?

Sadly, this information is all that the gpgme library provides to the 
applications.

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

[trojita] [Bug 369556] Change "Development" link on website

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Oops :). I've now updated Redmine to make it more obvious, hopefully it helps.

We've got a new web in the works as well. Thanks for reporting this.

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

[trojita] [Bug 368859] New: Use newer upstream gpgme to get rid of kf5-gpgmepp

[Jan Kundrát via KDE Bugzilla]

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

Bug ID: 368859
   Summary: Use newer upstream gpgme to get rid of kf5-gpgmepp
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Cryptography
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org

The C++ bindings have moved upstream, so we should follow the suit. In
addition, there's a chance that their C++11 usage will fix the ASAN-reported
issues in boost::shared_ptr.

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

[trojita] [Bug 368003] CATENATE might produce invalid MIME messages

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

  Latest Commit||http://commits.kde.org/troj
   ||ita/d9a728d49cef4457afdf069
   ||6942a848e82951815
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Git commit d9a728d49cef4457afdf0696942a848e82951815 by Jan Kundrát.
Committed on 01/09/2016 at 18:48.
Pushed by gerrit into branch 'master'.

Use correct CTE when attaching IMAP parts

Because we are making a heavy use of the CATENATE extension which uses
the raw, undecoded data from the IMAP server without any transformation,
let's make sure that the attached part inherits its
Content-Transfer-Encoding from the original part. This ensures that the
attachment is added as-is, with no additional transformations and is
still correctly marked.

A potential problem is that when attaching a part which is
malformed/invalid or if it contains data which are not permitted by a
relying MTA, we might hit problems. However, in that case it would be a
garbage-in, garbage-out problem. There's a hypothetical scenario where
an IMAP message contains a binary, non-encoded part, which this patch
happily ignores. However, it isn't a regression but rather an
improvement -- at least such part is properly marked with a CTE that
reflects its actual content.

This patch still doesn't enforce a 100% byte-by-byte match of the
outgoing message (as submitted over SMTP) and the copy stored in the
Sent folder. If CATENATE is available (it is with Dovecot for example)
and BURL is not available (BURL is still a bit exotic today), and if
attaching something which is already available on the IMAP server, there
might be subtle differences such as the wrapping of the base64 content,
etc. That's the price one pays when offloading stuff to the IMAP server,
and I do not see any possibility of avoiding it (except maybe tying BURL
and CATENATE together and only ever using both or none of them...).

Change-Id: I53a2a186f308a9acab3b1d5f4e3e821e29bbb3ce

M  +30   -7src/Composer/ComposerAttachments.cpp
M  +1-0src/Composer/ComposerAttachments.h
M  +9-1src/Composer/MessageComposer.cpp
M  +39   -3tests/Composer/test_Composer_Submission.cpp

http://commits.kde.org/trojita/d9a728d49cef4457afdf0696942a848e82951815

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

[trojita] [Bug 368003] CATENATE might produce invalid MIME messages

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
Git commit 3501e8190d48735c2076f6a1c33607c100e4fa0c by Jan Kundrát.
Committed on 01/09/2016 at 13:43.
Pushed by gerrit into branch 'master'.

tests: Attaching IMAP parts with varying CTE

Just some refactoring to make the test more generic. In future, we'll
actually add more data (and fix bug 368003, too).

Change-Id: I1b7e4ff42c2b43cd8a8131dbb1d5c6753ac0a141

M  +48   -10   tests/Composer/test_Composer_Submission.cpp
M  +2-1tests/Composer/test_Composer_Submission.h

http://commits.kde.org/trojita/3501e8190d48735c2076f6a1c33607c100e4fa0c

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

[trojita] [Bug 367601] fake-dev-random should not be used unconditionally

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Latest Commit||http://commits.kde.org/troj
   ||ita/1311c5afd1f4b5a17c946c2
   ||45d7ec30d39a22eb4

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
Git commit 1311c5afd1f4b5a17c946c245d7ec30d39a22eb4 by Jan Kundrát.
Committed on 29/08/2016 at 11:06.
Pushed by gerrit into branch 'master'.

tests: Remove Linux-specific includes for dlsym

The dlsym(RTLD_NEXT) appears to be reasonably portable (it's POSIX,
except the minor RTLD_NEXT and _GNU_SOURCE on glibc), so let's use this
thing to fix a build failure on OpenBSD.

We are doing this because GnuPG 2.1+ is still not really that
mainstream and because faking the random generator just for the tests at
all platforms simplifies the test matrix. Alternatives such as GnuPG
version detection are IMHO too fancy.
Change-Id: Icf0001a20c6e2901a88b65a705059d687951b1fb

M  +1-4tests/Utils/fake-dev-random.c

http://commits.kde.org/trojita/1311c5afd1f4b5a17c946c245d7ec30d39a22eb4

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

[trojita] [Bug 367607] Compiled trojita asserts on startup when trojita has been installed with package manager

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Latest Commit||http://commits.kde.org/troj
   ||ita/fa23cf7f49abf2b3116cfb0
   ||286d744d688752bb8

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
Git commit fa23cf7f49abf2b3116cfb0286d744d688752bb8 by Jan Kundrát.
Committed on 30/08/2016 at 09:08.
Pushed by gerrit into branch 'master'.

Plugins: do not assert on plugins duplicated to several directories

As Caspar points out, the code asserts when a same-named plugin is found
both in the systemwide directory and in our current build directory.

This change makes sure that only one "instance" of a same-named file is
attempted for loading. This check happens early in the path and because
appdir-local plugins are actually attempted to load earlier than the
rest, it Should Work™.
Change-Id: Id0bb508a03708c1cbe8d43b8685c236a3292

M  +12   -1src/Plugins/PluginManager.cpp

http://commits.kde.org/trojita/fa23cf7f49abf2b3116cfb0286d744d688752bb8

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

[trojita] [Bug 368003] New: CATENATE might produce invalid MIME messages

[Jan Kundrát via KDE Bugzilla]

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

Bug ID: 368003
   Summary: CATENATE might produce invalid MIME messages
   Product: trojita
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Message Composer
  Assignee: trojita-b...@kde.org
  Reporter: j...@kde.org

When using drag-and-drop to attach a part stored on an IMAP server, the
composer migh produce malformed MIME messages if CATENATE is available and
used.

ImapPartAttachmentItem::suggestedCTE() makes this easy to see because it
hardcodes "Content-Transfer-Encoding: base64" for anything but message/rfc822.
So when attaching something like message/delivery-status or essentially
anything which is stored without any CTE on the IMAP server, Trojita's composer
writes out a CTE header which identifies the content as base64-encoded. When it
comes to adding the actual data, Trojita uses an IMAP URL mechanism which
points to a raw MIME part as-is, which in this case means a part stored with no
CTE which in turns is 7bit.

One approach at fixing this is to use the CTE header from the IMAP server, and
to hope that the original message was not malformed. This, however, might cause
trouble if we are about to send a message which is, say, in CTE: 8bit over an
SMTP server which does not support the CTE: 8bit. In that case, we will have to
transcode that part. If we are transcoding, there's a question on how a copy of
message which we are storing to the sent mailbox should look like -- either it
can use the most-efficient format, the CTE: 8bit, saving both bandwidth and
disk space, or it should match the outgoing message exactly, bite-wise, which
means that it must not use CATENATE in that case. Stuff gets messy because
right now, we prepare the full MIME structure beforehand, before even
connecting to the SMTP server which makes a lot of sense due to BURL. Maybe we
should detect that we cannot submit our message in this way, remove the
previously stored copy, upload a new one with no CTE: 8bit et al, and then use
this new 7bit version as an outgoing message in that case...

Or TL;DR, just disable CATENATE for now?

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

[trojita] [Bug 367601] fake-dev-random should not be used unconditionally

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
See https://bugs.kde.org/show_bug.cgi?id=367601 for a workaround. I'll be happy
to accept patches which skip the LD_PRELOAD use on OpenBSD -- simply skipping
the export in keygen.sh (and maybe its building in the cmake if you want to be
fancy) should be enough.

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

[trojita] [Bug 367607] Compiled trojita asserts on startup when trojita has been installed with package manager

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
OK, I wasn't getting this because my package manager installs to /usr. Will fix
shortly.

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

[trojita] [Bug 366498] InvalidResponseCode due to a 64bit UIDNEXT

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #8 from Jan Kundrát <j...@kde.org> ---
Yes, telling them that the following line violates
https://tools.ietf.org/html/rfc3501#section-2.3.1.1 might help them fix their
software.

  * OK [UIDVALIDITY 42036101441452023] UIDs valid␍␊

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

[trojita] [Bug 366498] InvalidResponseCode due to a 64bit UIDNEXT

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

Summary|InvalidResponseCode |InvalidResponseCode due to
   ||a 64bit UIDNEXT

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
(In reply to Thomas Lübking from comment #4)
> The main problem here though will be that UIDVALIDITY "slightly" exceeds 32 
> bits.

Yes, the IMAP server is violating the IMAP protocol specification in a pretty
basic aspect. The best we could do is treating this as if UIDVALIDITY was not
present at all which would mean that Trojita will re-download everything over
and over again anytime a mailbox gets opened.

I do not think that this is worth our time, but patches are welcome if someone
cares enough.

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

[trojita] [Bug 365299] make transition from qtwebkit to qtwebengine

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #6 from Jan Kundrát <j...@kde.org> ---
Opening an HTML e-mail in an external viewer won't work because the majority of
web browsers do not support stuff like the cid: URL scheme which is a must for
dealing with HTML mail.

I agree that a perfect solution for 2016 is offering both QtWebKit, QWebEngine
and QTextBrowser implementations as plugins. Patches which make this happen are
welcome. However, arguing for this on Bugzilla won't make it happen any sooner.

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

[plasmashell] [Bug 365394] Huge icons in the systray and huge font size for the clock applet

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

  Latest Commit||http://commits.kde.org/plas
   ||ma-workspace/9e0b065f7105c7
   ||36afc0a0c2c0fe009316c0c561

--- Comment #4 from Jan Kundrát <j...@kde.org> ---
Git commit 9e0b065f7105c736afc0a0c2c0fe009316c0c561 by Jan Kundrát.
Committed on 20/07/2016 at 15:02.
Pushed by jkt into branch 'master'.

Fix huge icons with vertical panel

There was a conflict between adding a config option [1] in master and a
fix to crop to the icon size [2] in the 5.7 branch. I still need the
cropping on my vertical panel, otherwise the icons are insanely big.

[1] https://git.reviewboard.kde.org/r/128400/
[2] https://phabricator.kde.org/D2160

Reviewed-By-Over-IRC: Marco Martin <notm...@gmail.com>

M  +1-1applets/systemtray/package/contents/ui/main.qml

http://commits.kde.org/plasma-workspace/9e0b065f7105c736afc0a0c2c0fe009316c0c561

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

[plasmashell] [Bug 365394] Huge icons in the systray and huge font size for the clock applet

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
The icon sizes are fixed by
https://quickgit.kde.org/?p=plasma-workspace.git=commit=6a3ea8abb5a545d7cad5c534ad3070e9165f3097
which is in 5.7, not in master (yet). The clock sizes have always been wrong
IIRC, so let's close this one as fixed.

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

[plasmashell] [Bug 365394] Huge icons in the systray and huge font size for the clock applet

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #2 from Jan Kundrát <j...@kde.org> ---
No change in behavior with the current master branch of KF and all of Plasma.
What information do you need in order to fix this? Alternatively, where should
I look in order to investigate this regression?

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

[plasmashell] [Bug 365394] Huge icons in the systray and huge font size for the clock applet

[Jan Kundrát via KDE Bugzilla]

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

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
Created attachment 100013
  --> https://bugs.kde.org/attachment.cgi?id=100013=edit
screenshot

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

[plasmashell] [Bug 365394] New: Huge icons in the systray and huge font size for the clock applet

[Jan Kundrát via KDE Bugzilla]

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

Bug ID: 365394
   Summary: Huge icons in the systray and huge font size for the
clock applet
   Product: plasmashell
   Version: master
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Panel
  Assignee: plasma-b...@kde.org
  Reporter: j...@kde.org

After updating all of KF5 and Plasma from git master as of 2016-06-21 to git
master as of 2016-07-08, the icon sizes in the System Tray and the font size in
my clock applet are now huge -- see the attached image. This only appears to
happen on vertical panel.

Reproducible: Always

Steps to Reproduce:
1. Trash ~/.config/plasma-org.kde.plasma.desktop-appletsrc to start from
scratch
2. Move panel to the right edge, triggering a vertical orientation

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

[trojita] [Bug 365149] parsing error in * STATUS "INBOX" (MESSAGES 702 UNSEEN 0 RECENT 0)

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED
  Latest Commit||http://commits.kde.org/troj
   ||ita/6c1702437b67c690d89
   ||2be0dc014b2ef0db3

--- Comment #5 from Jan Kundrát <j...@kde.org> ---
Git commit 6c1702437b67c690d892be0dc014b2ef0db3 by Jan Kundrát.
Committed on 07/07/2016 at 14:59.
Pushed by gerrit into branch 'master'.

IMAP: Accept more spaces when reading untagged responses

The IMAP standard is 100% clear on this one, but apparently there are
servers out there which get this thing wrong and send extra spaces every
now and then -- a "DevMail Gateway" is one of these, according to the
linked bug. That behavior is incorrect and in violation of RFC3501, but
whatever, we've added similar incompatibility quirks before and I'm
afraid that we'll have to keep adding them in future, too.

Let's see if this is enough to work with the above mentioned server
implementation.
Change-Id: Iff89b82ca3ca4be719076e3ee81176b8fc7d287c

M  +1-0src/Imap/Parser/Parser.cpp
M  +7-0tests/Imap/test_Imap_Parser_parse.cpp

http://commits.kde.org/trojita/6c1702437b67c690d892be0dc014b2ef0db3

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

[trojita] [Bug 365299] make transition from qtwebkit to qtwebengine

[Jan Kundrát via KDE Bugzilla]

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

Jan Kundrát <j...@kde.org> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Jan Kundrát <j...@kde.org> ---
We'll have to support both because we care about older Linux distributions
(right now, we support building against Qt 5.2). In addition to that, Trojita
requires certain features which only became available in the 5.6 webengine
(custom URL delegates, and detailed request filtering, for example). Patches
which make this happen are welcome.

Also please note that QtWebKit is still available in Qt 5.6, they just stopped
producing tarballs and the default `init-repository` build setp skips webkit.
It is still getting patches at the Qt project.

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