KP49 got stabled by its thread title, no? Also it always provides stock/nokia kernel app in menu with 100% verified back ups (correct me if I'm wrong here, but even my 10-15sec shutdown allowed me to flash stock kernel (takes around 7 seconds) and my only issues were with modest crashing thrice in all of its history plus 'Save as' dialog bug which also kp49 fixed). Compare that to endless threads of issues.

Man, me and pali are the guys behind KP for an year or so. And me and pali are the guys with most commits in CSSU for half an year or so (AFAIK). It just don't make sense to trust us for the KERNEL and not trust us for the USERLAND.

...or you are just trolling.

I trust you. KP is great. CSSU introduces a lot of things, so trust is not only factor. If you knew about killing backwards compatibility with libvte bugfix for ssh/screen/vim scenario would you still introduce it now?

I'm confused now. Does the CSSU include the OfflineIMAP program?

I thought the "Offline IMAP" option in modest relates to activating the e-mail caching (provided by Tinymail). Basically this involves two patches (one in modest, one in tinymail).

But then I see these mentions of offlineimap.org, which is a completely different thing, as (1) is a separate program, (2) needs a client with Maildir support, (3) which modest doesn't have, so it requires (4) a local IMAP server.

None of that is AFAIK included with the CSSU. At least I have seen no mention of it.

So please somebody clarify this. Otherwise the "documentation" (at least the wiki) will be spreading misinformation.

The thing is that we know which patches go or have gone to the kernel-power. You can list them on a single page. Besides, it's only one single "package".

With the CSSU there is no such list. It's either an incomplete Wiki page, where most "bug fixes" involve "reverting a previous bug fix" or adding apps to a no-portrait blacklist; OR referring to a huge thread where you may or may not be able to identify each single patch.

Until I get a full changelog of the CSSU (for each package each diff) I will not install the *full* CSSU.

Note 1: Some people on this thread have offered to make such a list (e.g. Copernicus). Kudos to him/them. I will not do or help with that list.

Note 2: For *individual* packages (e.g. modest, libvte) I may be convinced and actually install them. Still, seeing a new option called "mcenfiadvsetupofflinesync" doesn't awake my trust (OK, I didn't install the l10n package), especially when it's not even clear what this option actually does. No diff may be OK for most, but not even providing a (coherent) explanation of what it does is a no-go for me.

Ok, yes, it does seem to be the case that the offline imap mentioned in the Git log is different than the standalone command-line program described at http://offlineimap.org.

Checking the code: the patch submitted by Pali, with the description "Modest patch for Offline IMAP support from http://mat.exon.name/modest/" (sadly, that link no longer exists), is a set of modifications to Modest to add a new account setting check button for offline IMAP. When this button is checked, Modest will pass a pair of strings, "offline_sync" and the null string, as a new account option to the Tinymail backend. That is about it.

Modest is a gui front-end for the Tinymail email library. So, checking the Tinymail code, we find that this account option is a Camel-mail option. It turns out that Camel is an e-mail backend used by Tinymail, and in fact, I'm not sure that Tinymail actually is doing all that much more than just passing requests down to the Camel library and passing data back up. In any case, the Tinymail "tny_camel_account_add_option()" function appears to just forward this account option on to the Camel library.

Ok, now Camel appears to in fact be a backend library for Gnome's Evolution e-mail server. Following the trail of the "offline_sync" option leads to camel-offline-folder.c and camel-disco-folder.c. (It appears that "disco-folder" is an older, possibly deprecated, version of "offline-folder".) In any case, offline_sync seems to trigger "synchronization" of IMAP folders to the client, possibly as a background process. It'll take some time for me to discern exactly what is going on here, but in short, I would guess it's copying over the entire set of e-mail bodies for a given folder, rather than just the headers. Maybe all the folders.

In any case, yeah, this is not the stand-alone app. I'm not sure I'd want to use this option myself; I have a truly vast amount of messages stored in my own IMAP folders, I don't think I'd want to try and squeeze all of it onto my N900. Still, useful for some folks.

And man, I gotta say that "Tinymail" sure doesn't seem all that tiny. (And if Modest is just using it as a pass-through for Camel, why use it at all? Oh well.)

Thanks for catching this.

@Copernicus,

Thanks for the explanation. I knew it was not the offlineimap.org program, so I was wondering why it was being referred to in the Wiki.

I guess I'll also have to go down the recompilation route, to remove this and the tree view options, and just leave a clean modest with the patch to move up instead of down when deleting a message.

...but you trusted Nokia for every firmware release back then, or did you refrained from installation of them too? Did THEY provide you a full-fledged release log, with individual diffs? Man, it's a friggin' "phone" / mobile device that you have control of and can easily "restore" if you have to, not some security-restrained production server.

Get through the sources, that's almost all you get in FOSS as a means of an audit.

This thread seems getting ridiculously out of hand / way over board now.

BTW, the link http://mat.exon.name/modest/ is alive and working.

When I bought my N900 it came with PR1.2 already loaded (yeah, I took me *that* long to decide if the N900 was suitable for me. Now you see how I am). Right after the first boot I was offered to upgrade to PR1.3 over-the-air, which I did, because I had *already* (before buying the N900) read about it.

I only installed 1.3.1 once I knew exactly what was being modified.

I do this for every non-trivial package (heck, even for the trivial ones). I always look at the .deb to see where files are going to be placed and what the postinst is doing. Don't want a random deb (whether from extras or extras-devel, to me, they are equivalent) to screw my phone.

And given that we're talking about a COMMUNITY software update I would at the very least expect that this community provides (1) changelogs and (2) individual packages.

The way CSSU works at the moment is identical to how the SSU was working. Difference being that I *do* trust Nokia more than random developers (no offence, random to *me*) especially seeing the focus on portrait mode and fancy transitions, while actual solved bugs are few and messily handled (fix a bug, revert the fix, fix it again, break this, revert, the works..)

Sorry if I sound offensive. I want the best for my N900, so I want to know what I put in it. If the CSSU cannot give me this security, then my only choice is to do my own private [S]SU