Regarding the Inbox issue, I've found that some services do not subscribe to the INBOX by default, and Kube only shows subscribed folders.
I think having INBOX not subscribed by default is a very bad default, but I've worked around that particular issue by ignoring the subscription state for that particular folder, so inbox is always shown.

My bad, I forgot to adjust the download urls accordingly. Should be fixed now.

https://kube-project.com/getit.html advertises nightly macOS builds, but all I ever get is the same July 7 build. What gives? I want to try the fix for the Inbox issue. Also where is Kube storing user data on macOS? I can't find it in any of the usual places.

Kube will remember passwords for as long as it runs. There is currently no keyring integration to save passwords for longer. It looks like the recommended way by google would be to simply regenerate a new password whenever you need one, kube won't care.

A separate field for a username has now been implemented (will appear in the next builds, probably tomorrow).

given that I've tested fastmail and we have not recieved further debug output (such as from "sinksh list folder") I'm assuming it's also a subscription issue.

at least on mailbox.org there is the problem that INBOX is not subscribed by default (which seems like a weird choice).
To counter that kube now ignores the subscription state for inbox and always enables it.
Building a new macos image is still pending.

It was because of gpg's auto-key-retrieve feature. Not much we can do about it.

This is actually just an invalid From: header.

https://dmorgan.info/posts/encoded-word-syntax/

Looks like the implicit width of the label of the button is too small.

Right now we simply support regular passwords. Fastmail contains a similar mechanism and at least there I tested it that it works, no idea about google.
There is no keyring integration atm. so you will indeed have to remember the password and enter it every time.

Messages are now correctly marked as read. We'll keep the highlighting for now, even though you will rarely see it since we immediately mark as read.

Strategies to avoid the problem:

• Rebase local changes when new changes from the server appear. This would break with the current concept of an always increasing revision number and would thus require changes in how query updates are handled. Probably not a good idea.
• Always apply modifications to a specific revision so we can detect conflicts, generate a diff, and hope that there is no conflict.

The problem of lost updates due to missing some revisions in the incremental update has just been fixed. The problem of modifications being overwritten by fetching the full payload is a separate issue that remains to be fixed.

There might be a race between marking as read and fetching the full payload. If the full payload arrives after the local modification we potentially revert the previous modification.

I have the same issue for an imap account on mailbox.org (using the macOS build of Kube) with the Inbox simply not showing in the list of folders.

Correct! This is no longer the case

As far as I can tell this is no longer the case? Please close the ticket if you agree.

We will:

• Not download images by default
• Add a button per message to trigger the download of messages
• Add a switch visible in the conversation view (as floating button), to alter the global default of not downloading.

It needs to remember the password, I guess, because it's a generated password, and there doesn't seem to be a way to get it again later, only to generate a new one.

Oh it started working after restarting kube, with these addresses:

In the case of Dreamhost email https://help.dreamhost.com/hc/en-us/articles/215612887#Example_setup_using_a_secure_IMAP_connection the username should be the full email address. E.g. my working mutt config has

This would be useful as counter-spam measure and in light of T8699.

Thanks for the report.

http://dogmamix.com/MimeHeadersDecoder/

Can't reproduce, please reopen if you can and provide a backtrace.

I think this was caused by the newly added webdavcommon library. It lacked a dependency on sink_common, but depended on the generated headers.

Apologies for lack of clarity.

At the very least we are not doing very well with reporting what the actual problem is.

In my case everything but Kolab Now works. Gmail won't work, nor Fastmail.

After upgrading to the new version, Kube no longer chokes. Everything syncs just fine. We could close this now.

This is from the commit "highlight unread mails in conversation view"

We'll track the potential cmake dependency issue in a separate ticket: T8442

Great, thanks for the info, I'll add a note to the documentation.

If there's an apt package for Ubuntu, I couldn't find it. Even searched on Launchpad to see if it was for an older version, since I'm on Kubuntu 18.04 Beta. No luck.

Great =)
Yeah, I'd be interested in what problems you were facing. Normally you shouldn't have to do anything else than installing it from your distro.

Hard to believe that my puny Core i5 1.6gHz chip can be too fast ;)

I think I've had this problem when enabling parallel building, it would sometimes compile files that uses thing_generated.h before it is created, but I haven't looked into it. Can you try building with 1 job, or building in parallel several times in a row?

Will do. I'll pull fresh copies and give it another shot.

Hey Scott, that file should be generated by the sink build system and ends up in the common subdirectory of the sink build directory for me. So I'm not sure why that isn't working.
To track development please build the develop branch on both the sink and kube repository, but that file should be generated on all branches...

Fixed by using QApplication again.

Haven't seen this in forever.

Right, sorry about that.

We linked against an ancient readline version.

fwiw, we're using libcurl, so if you manage to send a mail with the curl commandline utility it should work with kube (barring some setting adjustments).

The paste is no longer available, please always add stacktraces to the bugreport directly.

I just fixed a crash that was triggered in the resource while indexing some html mails, which was probably the problem. I have otherwise no problem with mailboxes with 50k+ mails inside.
The fix is not yet available on osx, but will be within the week.

How does this problem show up? I get my INBOX just fine and a "sinksh list folder" gives me an INBOX folder with a specialpurpose value of "inbox".

Nevermind, after generating a new app password (mail, calendar, contacts) it works. Seems to have been a problem on the fastmail side.

fastmail and curl don't mix right now. I don't know right now why fastmail claims that the credentials are incorrect.

as suspected:
#0 0x00007f94a9c30431 in nanosleep () from /lib64/libc.so.6
#1 0x0000000000409b00 in std::this_thread::sleep_for<long, std::ratio<1l, 1l> > (__rtime=...)

at /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/thread:373

#2 0x0000000000406a4b in crashHandler (signal=11) at /src/sink/synchronizer/main.cpp:107
#3 <signal handler called>
#4 0x00007f94aafa5f0c in initPalette() () from /lib64/libQt5Gui.so.5 #5 0x00007f94aafa72d9 in QGuiApplication::palette() () from /lib64/libQt5Gui.so.5 #6 0x00007f94ab0b3a85 in standardDeclarationForNode(QTextHtmlParserNode const&) () from /lib64/libQt5Gui.so.5 #7 0x00007f94ab0b438c in QTextHtmlParser::declarationsForNode(int) const () from /lib64/libQt5Gui.so.5
#8 0x00007f94ab0b7993 in QTextHtmlParser::parseTag() () from /lib64/libQt5Gui.so.5
#9 0x00007f94ab0b7eb0 in QTextHtmlParser::parse() () from /lib64/libQt5Gui.so.5 #10 0x00007f94ab0d474c in QTextHtmlImporter::QTextHtmlImporter(QTextDocument*, QString const&, QTextHtmlImporter::ImportMode, QTextDocument const*) ()

from /lib64/libQt5Gui.so.5                                                                                                                                  #11 0x00007f94ab09a3dd in QTextDocument::setHtml(QString const&) () from /lib64/libQt5Gui.so.5                                                                 #12 0x00007f94ac2683a6 in processPart (content=0x1230680) at /src/sink/common/mailpreprocessor.cpp:62                                                          #13 0x00007f94ac267809 in MailPropertyExtractor::updatedIndexedProperties (mail=...,                                  
 data="Return-Path: <msprvs1=17619nlLgu19x=bounces-28140@spmailtechno.com>\r\nReceived: from compute1.internal (compute1.nyi.internal [10.202.2.41])\r\n\t b

y sloti36d2t28 (Cyrus 3.1.3-345-gfe48802-fastmail) with "... = {...}) at /src/sink/common/mailpreprocessor.cpp:134