Comment 1 Andre Klapper 2008-07-04 15:21:24 UTC

Thanks for reporting this.
starting from the commandline ('modest showui') might give some valuable
output - please post it here.

What are the exact settings to reproduce this? Are you using SSL or TLS in the
settings?

(In reply to comment #1)
> Thanks for reporting this.
> starting from the commandline ('modest showui') might give some valuable
> output - please post it here.
> 
> What are the exact settings to reproduce this? Are you using SSL or TLS in the
> settings?
> 

Settings:
Incoming: imap.gmx.net (no secure connection, port 143)
Outgoing: mail.gmx.net (secure authentication: login)

Neither using TSL nor SSL for connection.

'modest showui' doesn´t show anything, only thing happening is modest starting.

Comment 3 Andre Klapper 2008-07-04 20:23:39 UTC

But you can fetch your GMX mail by using IMAP on another computer?

Yes, I can fetch mails with my Nokia Communicator 9500 and Nokia 770 and prior
to Diablo, with my N800 running OS2008 4.0. So the settings are correct.

Comment 5 Eero Tamminen 2008-07-10 17:17:34 UTC

(In reply to comment #2)
> > starting from the commandline ('modest showui') might give some valuable
> > output - please post it here.
[...]
> 'modest showui' doesn´t show anything, only thing happening is modest
> starting.

I think this should be:
  /usr/bin/maemo-summoner /usr/bin/modest.launch showui

Otherwise it's launched using already running maemo-launcher daemon
(which output goes to /dev/null).

Thank you for the information, here is the output:

BusyBox v1.6.1 (2008-05-22 10:32:35 EEST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ /usr/bin/maemo-summoner /usr/bin/modest.launch showui
maemo-summoner: summoning '/usr/bin/modest.launch'
modest[2399]: GLIB DEBUG default - mission_control_get_presence_actual: MC not
running.
modest[2399]: GLIB DEBUG ConIc - con_ic_connection_send_event(0x42c08,
b6137d6a-ca2d-4cba-8bd8-a31164cb034a, WLAN_INFRA, 0)
modest[2399]: GLIB DEBUG default - on_connection_event: emiting is_online
(true)
modest[2399]: GLIB DEBUG default - conic_emit_status: emitting status
(0x1658c0, true) in 1000 ms
modest[2399]: GLIB DEBUG default - conic_emit_status_idle: destroying 0x1658c0
(idle)
modest[2399]: GLIB DEBUG default - conic_emit_status_idle: emitted
tny-device-connection-changed signal
modest[2399]: GLIB DEBUG default - conic_emit_status_destroy: destroying status
info (0x1658c0)
modest[2399]: GLIB DEBUG default - conic_emit_status_destroy: destroyed
0x1658c0
modest[2399]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line
1149 (modest_tny_account_store_alert): should not be reached
modest[2399]: GLIB WARNING ** Gdk - gdkdrawable-x11.c:878 drawable is not a
pixmap or window
modest[2399]: GLIB WARNING ** Gdk - gdkdrawable-x11.c:878 drawable is not a
pixmap or window

*** Bug 3431 has been marked as a duplicate of this bug. ***

Comment 8 Andre Klapper 2008-07-14 13:29:30 UTC

Confirming as per duplicate.

This line looks suspicious:

modest[2399]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line
1149 (modest_tny_account_store_alert): should not be reached


You're not using a GPRS connection by any chance? :-D

Could you maybe provide a syslog (also see
http://maemo.org/development/documentation/man_pages/hcidump.html )? It may
include more info, e.g. an errorcode (at least this was helpful to track down
Gmail IMAP bugs).

No, no GPRS connection at all, I'd be glad it's so easy ;-)

Can you tell me which command line switches you need from hcidump?

Comment 10 Andre Klapper 2008-07-14 14:22:49 UTC

(In reply to comment #9)
> Can you tell me which command line switches you need from hcidump?

Whoops, completely wrong link, garrr....
http://maemo.org/development/tools/doc/diablo/syslog/ should be right, hcidump
does not make sense here. :-)

Well, now I need some help because as a linux newbie (even though I'm a windows
system administrator) I need help how to start an configure the daemon.
Unfortunately the manpages weren't able to help me.

What I did up to now:

Entered "Red pill mode" and installed syslogkd package

I can confirm the problem with a T-Online and a Runbox IMAP account. Neither
unencrypted nor SSL configurations work. syslog just reports:
modest[2907]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line
1149 (modest_tny_account_store_alert): should not be reached

Comment 13 Andre Klapper 2008-08-04 16:19:27 UTC

(In reply to comment #11)
> I need help how to start an configure the daemon.

Starting? Basically it's just
http://maemo.org/development/tools/doc/diablo/syslog/ :-)

Comment 14 Eero Tamminen 2008-08-04 16:32:26 UTC

(In reply to comment #11)
> Entered "Red pill mode" and installed syslogkd package

Btw. it's better to uninstall syslog after it's not any anymore needed
and remove the log files it saves under /var/log/.  Syslog slows down
the device a bit, but larger issue is the size and frequent writing
of the logs.

Comment 15 Andre Klapper 2008-08-04 20:37:00 UTC

Created an attachment (id=855) [details]
syslog by reporter

Most interesting line seems to be

Aug  4 18:17:19 Nokia-N800-23-14 modest[1794]: GLIB CRITICAL ** default -
modest_folder_view_select_first_inbox_or_local: assertion `self &&
MODEST_IS_FOLDER_VIEW(self)' failed

Could we get a test account in that server? That way we could test it properly.

Unfortunately a GMX account (gmx.de) to use imap protocol is not free, but a
runbox account has a 30 day trial period, maybe that will help because Florian
Müller has the same problem on a runmap account.

After applying 4.2008.30-2 update, seems to be same error. I'm going to check
tomorrow if any new error messages will be shown.

Comment 19 Andre Klapper 2008-08-11 21:55:53 UTC

What is runbox/runmap? Any URL?

Look at Comment #12. It's another webmailer, address is runbox.com

Comment 21 Andre Klapper 2008-08-18 11:42:18 UTC

In short: I've tracked this down, could connect to Runbox.com IMAP Inbox.

Long version:
I have created a trial user named maemodebug (and the password might be quite
similar) on runbox.com.

According to http://doc.runbox.com/twiki/bin/view/RunboxHelp/IMAP I set the
following preferences in Modest:
   Incoming account type = IMAP4
   Incoming server: imap.runbox.com
   Secure Connection: Normal (TLS)
This will set the port to 143 and I don't receive mail (sending works). Runbox
FAQ says to use port 993 for TLS/SSL, but that also didn't help to get my mail.

Then I tried to connect to Runbox IMAP on my home computer (running Evolution
2.22.3.1) by choosing TLS.
I got the error "STARTTLS not supported" (why doesn't modest throw an error
message?).
So after choosing SSL instead of TLS, i got asked to accept the certificate and
after that i could access the IMAP Inbox.

Now back to Modest (latest updated version 4.2008.30-2): After setting "Secure
Connection: SSL (IMAP4S)" and Port 993 I can access the IMAP Inbox on
Runbox.com.


I think this is a bug in the Runbox documentation and tend to close this as
INVALID. Runbox users please contact Runbox to get that fixed.

Anybody able to play the same game with GMX IMAP to see if it works?
Please tell us your exact security settings and please confirm that you do use
the latest released update version of Modest. Thanks.

(In reply to comment #21)
> Anybody able to play the same game with GMX IMAP to see if it works?
> Please tell us your exact security settings and please confirm that you do use
> the latest released update version of Modest. Thanks.

I run the latest version of Modest (at least I looked for software updates
yesterday and there weren't any), and I am still not able to connect to GMX. I
cycled through all possible security settings (no security, TLS, SSL, secure
authentication), and the only response I get is either nothing at all or
"username and password wrong" (which they certainly are not).

So for me nothing changed in Modest's behaviour.

(In reply to comment #21)

> I think this is a bug in the Runbox documentation and tend to close this as
> INVALID. Runbox users please contact Runbox to get that fixed.

Doesn't work for me. I re-flashed the device and updated to 4.2008.30-2. All
attempts failed: with and without SSL, connection to imap.runbox.com and
secure.runbox.com, different email addresses.

Comment 24 Andre Klapper 2008-08-18 21:47:38 UTC

Hmm. Pity.

Can you please start an X Terminal window and type the following commands:
    export "CAMEL_DEBUG"="all"
to enable the debug mode of the mail library and after that run
    /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1
This will start Modest. Please try to connect to the IMAP server.
Close Modest and attach the logfile named "log" here (please check for
confidential data before attached).

(In reply to comment #24)

> Can you please start an X Terminal window and type the following commands:
>     export "CAMEL_DEBUG"="all"
> to enable the debug mode of the mail library and after that run
>     /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1

That results in a segmentation fault.

Created an attachment (id=882) [details]
Debug log file

(From update of attachment 882 [details])
Resolving the hostname eventually works but it takes a while.

Comment 28 Andre Klapper 2008-08-18 22:52:50 UTC

(In reply to comment #25)
> >     export "CAMEL_DEBUG"="all"
> >     /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1
> That results in a segmentation fault.

only if you forget the "/usr/bin/maemo-summoner" part here :)

It works!

I changed the nameserver in /etc/resolv.conf from 127.0.0.1 to the DNS server
of my ISP and the IMAP server hostname could be resolved in a fraction of a
second. Modest could connect to the IMAP server and started downloading my
emails.

I reset /etc/resolv.conf and replace in the account settings the IMAP server
hostname with its IP. That works too and is my workaround for now.

Any ideas why resolving the hostname takes so long? Why does Modest not wait or
show at least an error message?

Thanks everybody for your time and effort!

Comment 30 Eero Tamminen 2008-08-19 10:27:36 UTC

(In reply to comment #29)
> I changed the nameserver in /etc/resolv.conf from 127.0.0.1 to the DNS server
> of my ISP and the IMAP server hostname could be resolved in a fraction of a
> second. Modest could connect to the IMAP server and started downloading my
> emails.
> 
> I reset /etc/resolv.conf and replace in the account settings the IMAP server
> hostname with its IP. That works too and is my workaround for now.
> 
> Any ideas why resolving the hostname takes so long?

I don't know that much about networking, but I think the reason why
/etc/resolv.conf has 127.0.0.1 as DNS address is that this way the device
changes between networks (phone, wlan...) are transparent to the apps.

You could try checking with "strace"[1] what "dnsmasq" does when it's
being asked to resolve host name, for example like this:
   strace -p $(pidof dnsmasq) 2> dnsmasq.log &
   strace -e trace=network ping maemo.org 2> ping.log

And then check what ping does when /etc/resolv.conf points directly
to your ISP DNS.

[1] see http://maemo.org/development/tools/

Created an attachment (id=887) [details]
Debug log file

Unfortunately, entering the mail provider's IP instead of the hostname did not
work for me. I included the log file, which looks pretty much like the one
posted in comment #6. Additionaly, I re-created the mail account while writing
the log, which did not help either.

It doesn't work for me either entering the ip address instead of the hostname,
GMX mailbox. I'm going to supply you with a logfile as soon as possible.

Comment 33 Andre Klapper 2008-08-25 17:59:06 UTC

@ Stefan, Christian:
> I included the log file
Please make sure that you really set CAMEL_DEBUG as described when providing a
log. There's no output at all after launching Modest, but there must be output
when trying to access the server, see for example comment 26.

@Sergio:
  modest[1392]: GLIB CRITICAL ** default - file modest-tny-account-store.c:
  line 1156 (modest_tny_account_store_alert): should not be reached
Is that a known issue?

(In reply to comment #33)
> @ Stefan, Christian:
> > I included the log file
> Please make sure that you really set CAMEL_DEBUG as described when providing a
> log. There's no output at all after launching Modest, but there must be output
> when trying to access the server, see for example comment 26.
> 
> @Sergio:
>   modest[1392]: GLIB CRITICAL ** default - file modest-tny-account-store.c:
>   line 1156 (modest_tny_account_store_alert): should not be reached
> Is that a known issue?
> 

Yes, that's not really a problem in Modest, we shouldn't use a critical for
that, it's just an unmanaged error code.

Comment 35 Andre Klapper 2008-09-04 00:02:19 UTC

(In reply to comment #32)
> It doesn't work for me either entering the ip address instead of the hostname,
> GMX mailbox. I'm going to supply you with a logfile as soon as possible.

*ping* :)
As I said, I can't reproduce this unfortunately...

I do can reproduce it. It seems that it's the same problem than bug 3668,
because the error I get is the same

modest[7228]: GLIB WARNING ** default - err: You cancelled when you had to
enter a password

I'd mark as duplicate or at least a dependency

I have the exact same behaviour with GMX email. I've updated to the latest
feature update 4.2008.36-5, that didn't help.

Comment 38 Andre Klapper 2008-10-06 16:56:05 UTC

Can someone please re-test this with 4.2008.36-5 and add a comment? Also see
bug 3668.

Same problem occurs with OS2008 feature upgrade 4.2008.36-5.

Comment 40 Andre Klapper 2008-10-09 16:22:54 UTC

Sergio: If it's really the same issue, then bug 3668 has not been fixed yet...

Could it be possible to get some account for testing in that GMX server?
Otherwise it will be really difficult to debug that problem.

Comment 42 Andre Klapper 2008-11-18 18:55:03 UTC

I've sold my soul and got a 30 days trial GMX ProMail test account that
provides GMX IMAP access.
Everybody cross your fingers that I get out of that contract again without
paying, otherwise I should invoice Nokia. ;-)

Ok I found the issue, tinymail is issuing LIST "" while it should be LIST "*"
as evolution does. I'll try to find out why

Has there been any progress? The latest feature update 5.2008.43-7 does not fix
this ...

Comment 45 Andre Klapper 2009-01-02 15:53:38 UTC

(In reply to comment #44)
> Has there been any progress? The latest feature update 5.2008.43-7 does not fix
> this ...

This bug report includes the line "Status: NEW" so it's quite obvious that the
last update has not fixed this yet.
Also week 43 was way before Sergio found out the reason for this in December.

(In reply to comment #23)
> (In reply to comment #21)
> 
> > I think this is a bug in the Runbox documentation and tend to close this as
> > INVALID. Runbox users please contact Runbox to get that fixed.
> 
> Doesn't work for me. I re-flashed the device and updated to 4.2008.30-2. All
> attempts failed: with and without SSL, connection to imap.runbox.com and
> secure.runbox.com, different email addresses.

Runbox works perfectly at least with current code developed for Fremantle. I
don't know if it works as well with the latest feature upgrade for Diablo.

I'll try now with GMX. Could anyone provide a test account?

Assigning to me BTW

Hi guys,

I've just checked that after some changes we added to tinymail namespaces
management we can now read GMX IMAP mail.

It's already committed to tinymail's trunk. If you find brave enough you can
build tinymail packages for yourselves.

I don't know if Nokia is planning to release another update, but if people want
I can build the tinymail packages and place them in a public place for
downloading.

Comment 49 Andre Klapper 2009-02-09 12:34:22 UTC

setting a "definitely fixed in" target milestone then.

(In reply to comment #48)
> I don't know if Nokia is planning to release another update, but if people want
> I can build the tinymail packages and place them in a public place for
> downloading.

A bugfix for Diablo 5.2008.43-7 would be great since so far it's impossible to
use some IMAP servers, in particular GMX. I would appreciate if it was easy to
install via the package-manager.

Comment 51 Andre Klapper 2009-04-28 15:34:22 UTC

Setting Target Milestone to Fremantle SDK beta.

(In reply to comment #48)
> 
> I don't know if Nokia is planning to release another update, but if people want
> I can build the tinymail packages and place them in a public place for
> downloading.
> 

Yeah, the people want 8)
Is this new build available?

(In reply to comment #52)

> 
> Yeah, the people want 8)
> Is this new build available?
> 

This worked for me:
http://forums.internettablettalk.com/showpost.php?&p=305443&postcount=21

(In reply to comment #48)
> I've just checked that after some changes we added to tinymail namespaces
> management we can now read GMX IMAP mail.
> 
> It's already committed to tinymail's trunk. If you find brave enough you can
> build tinymail packages for yourselves.

Do you know if Diablo modest will work with tinymail trunk?  Otherwise,
pointers to the specific changesets that fix this would be welcome :-)

(In reply to comment #53)
> This worked for me:
> http://forums.internettablettalk.com/showpost.php?&p=305443&postcount=21

It shouldn't - the only difference from the official Diablo package is
<https://bugs.maemo.org/attachment.cgi?id=1275&action=view>, nothing to do with
LIST & namespaces.

(In reply to comment #54)
> Do you know if Diablo modest will work with tinymail trunk?

To answer my own question: yes, with a couple of changes (due to the old Diablo
glib):
- configure with --disable-demoui (debian/rules.maemo)
- s/g_strcmp0/strcmp/ in
libtinymail-camel/tny-camel-store-account.c:folder_opened()

The packages themselves are a bit too large to attach here (~1MB, not counting
-dev & -dbg), but if anyone wants to test with the GMX server email me and I'll
send you a copy.

Maybe I spoke to soon.  It seems to work fine generally, but once mail
retrieval is initiated (manually or periodic) it gets stuck with the status bar
in the "Retrieving" state.  Oh well.

*** Bug 5710 has been marked as a duplicate of this bug. ***

Reopening, as the log attached to bug 5710 shows LIST and LSUB requests being
sent with an empty mailbox name.  For LIST that has special meaning (RFC3501
6.3.8):

      An empty ("" string) mailbox name argument is a special request to
      return the hierarchy delimiter and the root name of the name given
      in the reference.

and for LSUB it doesn't make sense.

*** Bug 7651 has been marked as a duplicate of this bug. ***

*** Bug 7894 has been marked as a duplicate of this bug. ***

I asked Nokia for an IMAP account but as POP is delivered as default it seems
that they don't have much interest on that. If anybody wants to share their
credentials with me for testing purpouses just send me an email.

just FYI: Maemo5 on N900 works great with GMX IMAP. I've heard of a possible
backport of Maemo5 to N810. This might fix the problem.

hi,

any reason why this bug is deemed "low priority"? 
i can see several duplicates below which would indicate that 
this issue affects a lot of people and many IMAP servers without 
apparent workaround. I would vote at least medium...

(In reply to comment #62)
> just FYI: Maemo5 on N900 works great with GMX IMAP. I've heard of a possible
> backport of Maemo5 to N810. This might fix the problem. 
> 

Andre are you sure about that? Note that when you select GMX as a provider, we
use the POP server.

*** Bug 8334 has been marked as a duplicate of this bug. ***

Since the only info modest has at that stage is the CAPABILITY response, and
the one in bug 8334 is nearly as minimal as it can be, the common pattern is
probably the lack of some capability.  Looking at all the relevant reported
logs, likely suspects are NAMESPACE and LIST-EXTENDED.

(In reply to comment #66)
> Since the only info modest has at that stage is the CAPABILITY response, and
> the one in bug 8334 is nearly as minimal as it can be, the common pattern is
> probably the lack of some capability.  Looking at all the relevant reported
> logs, likely suspects are NAMESPACE and LIST-EXTENDED.
> 

The guy who leads the Oracle Beehive mobility team works in the office next to
me.   He told me that Nokia and Oracle have some kind of partnership, and there
is a test server set up already that has a few generic 'nokia0N' accounts on
it.  

Of course it doesn't sound like there are any official Nokia employees working
on this - so I'm not sure that helps.  If I'm wrong and there are Nokia
employees here, let me know and I can hook 'em up.

If not, I might be able to get him to create a new account for someone to use -
if so, let me know who the best person to create the account for is...

(In reply to comment #67)
> (In reply to comment #66)
> > Since the only info modest has at that stage is the CAPABILITY response, and
> > the one in bug 8334 is nearly as minimal as it can be, the common pattern is
> > probably the lack of some capability.  Looking at all the relevant reported
> > logs, likely suspects are NAMESPACE and LIST-EXTENDED.
> > 
> 
> The guy who leads the Oracle Beehive mobility team works in the office next to
> me.   He told me that Nokia and Oracle have some kind of partnership, and there
> is a test server set up already that has a few generic 'nokia0N' accounts on
> it.  
> 
> Of course it doesn't sound like there are any official Nokia employees working
> on this - so I'm not sure that helps.  If I'm wrong and there are Nokia
> employees here, let me know and I can hook 'em up.
> 
> If not, I might be able to get him to create a new account for someone to use -
> if so, let me know who the best person to create the account for is...

I'm not a Nokian so don't have a clue about what you're talking about. If
you're going to ask for an account then do it for me please.

(In reply to comment #68)
> 
> I'm not a Nokian so don't have a clue about what you're talking about. If
> you're going to ask for an account then do it for me please.
> 

Unfortunately it sounds like it might not be as easy as I thought to get the
account set up.

Fortunately, I discovered that the same server does have an ActiveSync
component also, and I was able to configure MfE to work with it, which seems so
far to work fine.

Getting this fix is now a much lower priority for me - I'm happy using MfE to
get at my work email.

Feel free to close this if it was only reopened on my account.

As far as Oracle Beehive is concerned a test account can be obtained from:

http://www.oracle.com/dm/beehive/index.html

The problem is easy to reproduce. I am using an N900 PR1.1.

(In reply to comment #66)
I do have same problem as described by Warren in Bug 8334, but with Server
imap.o2online.de (seemingly not Oracle beehive):
---
received: * OK O3SIS UMA Proxy IMAP4 Server 7.0.0
sending : A00000 CAPABILITY
received: * CAPABILITY IMAP4rev1 STARTTLS
received: A00000 OK CAPABILITY completed
sending : A00001 LOGIN xxx xxx
received: A00001 OK LOGIN completed
sending : A00002 CAPABILITY
received: * CAPABILITY IMAP4rev1
received: A00002 OK CAPABILITY completed
sending : A00003 LIST "" ""
received: * LIST (\Noselect) "/" ""
received: A00003 OK LIST completed
sending : A00004 LSUB "" ""
received: A00004 BAD arguments invalid
sending : A00005 LOGOUT
received: * BYE IMAP4rev1 Server logging out
---

product info
maemo 5
version 2.2009.51.1

(BTW: Warren has 2.2009.51.1-1.002 - did I miss anything?)

Using this IMAP account for years now with lots of different clients. Never had
any difficulties.

Since I have an unused O2-SIM-card (and hence an email address at o2online.de)
I could offer test account for it.

I would really much appreciate if this bug could be solved finally.

(In reply to comment #71)
> (In reply to comment #66)
> I do have same problem as described by Warren in Bug 8334, but with Server
> imap.o2online.de (seemingly not Oracle beehive):
> ---
> received: * OK O3SIS UMA Proxy IMAP4 Server 7.0.0
> sending : A00000 CAPABILITY
> received: * CAPABILITY IMAP4rev1 STARTTLS
> received: A00000 OK CAPABILITY completed
> sending : A00001 LOGIN xxx xxx
> received: A00001 OK LOGIN completed
> sending : A00002 CAPABILITY
> received: * CAPABILITY IMAP4rev1
> received: A00002 OK CAPABILITY completed
> sending : A00003 LIST "" ""
> received: * LIST (\Noselect) "/" ""
> received: A00003 OK LIST completed
> sending : A00004 LSUB "" ""
> received: A00004 BAD arguments invalid
> sending : A00005 LOGOUT
> received: * BYE IMAP4rev1 Server logging out
> ---
> 
> product info
> maemo 5
> version 2.2009.51.1
> 
> (BTW: Warren has 2.2009.51.1-1.002 - did I miss anything?)
> 
> Using this IMAP account for years now with lots of different clients. Never had
> any difficulties.
> 
> Since I have an unused O2-SIM-card (and hence an email address at o2online.de)
> I could offer test account for it.
> 
> I would really much appreciate if this bug could be solved finally.

You're lucky :-) as I have just fixed this issue, I'm just checking that
everything is fine and I'll commit the fix after that. I'd appreciate very much
that test account to check that the bug is indeed fixed

Thats good news, Sergio. Sent test account data to your igalia mail.

(In reply to comment #73)
> Thats good news, Sergio. Sent test account data to your igalia mail.
> 

Thx Ulle, I can confirm you that the fix also solves your problem.

I have just committed the long awaited fix for this bug. Thank you all for your
patience.

Fixed in tinymail:
releases/modest/modest-3-2: r4148 - r4149
trunk:                      r4146 - r4147

This fix will be shipped with the new sw update for the N900. For those of you
that feel brave enough you can always build packages *BUT* note that installing
new packages will *BREAK* your next system update. I strongly recommend to wait
for the official update. In the mean time you can use the trick of setting a
rule that copies emails from inbox in another folder (it's nasty I know but it
works)

(In reply to comment #75)
> This fix will be shipped with the new sw update for the N900.

Setting TM accordingly, and while I'm generating bugmail may I say thanks to
all the people who supplied logs and/or test accounts and especially to Sergio
for sharing progress (including relevant commits) here.  This is exactly what
bug 630 is about :-)

(In reply to comment #75)
> I have just committed the long awaited fix for this bug. Thank you all for your
> patience.
> 
> Fixed in tinymail:
> releases/modest/modest-3-2: r4148 - r4149
> trunk:                      r4146 - r4147
> 
> This fix will be shipped with the new sw update for the N900. For those of you
> that feel brave enough you can always build packages *BUT* note that installing
> new packages will *BREAK* your next system update. I strongly recommend to wait
> for the official update. In the mean time you can use the trick of setting a
> rule that copies emails from inbox in another folder (it's nasty I know but it
> works)

I will look at it to provide PR1.1 package with fix by my system-upgrades
repository.

(In reply to comment #77)
> 
> I will look at it to provide PR1.1 package with fix by my system-upgrades
> repository.
> 

Some stupid questions:
- How can I try the "system-upgrades" fix? 
- would it break the coming normal update? 
- Any idea when this fix is coming out as a regular Maemo update/fix?

(sorry for all the questions, I'm a "Maemo newbie")

(In reply to comment #64)
> > just FYI: Maemo5 on N900 works great with GMX IMAP. I've heard of a possible
> > backport of Maemo5 to N810. This might fix the problem. 
> 
> Andre are you sure about that? Note that when you select GMX as a provider, we
> use the POP server.

Sergio, yes, it works on the N900. Just used manual setup to configure IMAP
with imap.gmx.net.

(In reply to comment #78)

> Some stupid questions:
> - How can I try the "system-upgrades" fix? 

http://talk.maemo.org/showthread.php?p=480227#post480227

> - would it break the coming normal update? 

No.

> - Any idea when this fix is coming out as a regular Maemo update/fix?

In PR 1.2 it should be fixed.

Sorry to say that, but I tried modest with the fix in Marcins repository and
still get the same behaviour. Nothing changed for me. 

process 5077: arguments to dbus_bus_request_name() were incorrect, assertion
"_dbus_check_is_valid_bus_name (name)" failed in file dbus-bus.c line 1070.
This is normally a bug in some application using the D-Bus library.
received: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION
STARTTLS] Courier-IMAP ready. Copyright 1998-2008 Double Precision, Inc.  See
COPYING for distribution information.

sending : B00000 CAPABILITY

received: * CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS

received: B00000 OK CAPABILITY completed

received: * OK server ready. Unauthorized Access Prohibited.

sending : A00000 CAPABILITY

sending : B00001 LOGIN xxx xxx

received: B00001 OK connected to proxy server.

sending : B00002 CAPABILITY

received: * CAPABILITY IMAP4REV1 IDLE AUTH=PLAIN

received: A00000 OK CAPABILITY completed

received: * CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION

received: B00002 OK CAPABILITY completed

sending : A00001 LOGIN xxx xxx

sending : B00003 NAMESPACE

received: * OK server ready. Unauthorized Access Prohibited.

sending : C00000 CAPABILITY

received: * NAMESPACE (("INBOX." ".")) NIL (("#shared." ".")("shared." "."))

received: B00003 OK NAMESPACE completed.

received: A00001 OK LOGIN completed

sending : A00002 CAPABILITY

received: * CAPABILITY IMAP4REV1 IDLE AUTH=DIGEST-MD5 AUTH=PLAIN AUTH=CRAM-MD5

received: C00000 OK CAPABILITY completed

received: * CAPABILITY IMAP4REV1 IDLE AUTH=PLAIN

received: A00002 OK CAPABILITY completed

sending : A00003 LIST "" ""

sending : C00001 LOGIN xxx xxx

received: * LIST (\NoSelect) "/" ""

received: A00003 OK LIST completed

sending : A00004 LSUB "" ""

received: A00004 NO LSUB failed: Invalid folder name

sending : A00005 LOGOUT

received: C00001 OK LOGIN completed

sending : C00002 CAPABILITY

received: * CAPABILITY IMAP4REV1 IDLE AUTH=DIGEST-MD5 AUTH=PLAIN AUTH=CRAM-MD5

received: C00002 OK CAPABILITY completed

sending : C00003 LIST "" ""

received: * BYE Oracle Beehive IMAP server terminating connection

received: * LIST (\NoSelect) "/" ""

received: C00003 OK LIST completed

sending : C00004 LSUB "" ""

received: C00004 NO LSUB failed: Invalid folder name

sending : C00005 LOGOUT

sending : B00004 LOGOUT

(In reply to comment #81)
> Sorry to say that, but I tried modest with the fix in Marcins repository and
> still get the same behaviour. Nothing changed for me.

Sorry, but I did not had a time to check is this fix apply to 3.1 branch.

I tried some servers with same namespaces than yours and it works. Maybe
Marcin's packages were not correctly generated or something.

Can you provide a test account ?

@Sergio

I have send you an email.

(In reply to comment #83)
> I tried some servers with same namespaces than yours and it works. Maybe
> Marcin's packages were not correctly generated or something.
> 
> Can you provide a test account ?
>

Sorry I didn't remember that you were using Oracle Beehive. I have several test
accounts and I can confirm that it's working fine with the current code. As I
said the packages you used seem not to have the fixes.

(In reply to comment #84)
> @Sergio
> 
> I have send you an email.
> 
> (In reply to comment #83)
> > I tried some servers with same namespaces than yours and it works. Maybe
> > Marcin's packages were not correctly generated or something.
> > 
> > Can you provide a test account ?
> > 
>

With new Maemo 5 update 3.2 nothing has changed to me. Same problem as in 
comment #71 .

Current product info
Maemo 5
Version 3.2010.02-8

Quite disappointing ...

Comment 87 Andre Klapper 2010-02-16 14:47:45 UTC

(In reply to comment #86)
> With new Maemo 5 update 3.2 nothing has changed to me. 

Yes, the fix is not included in PR1.1.1, otherwise I would have reset the
Target Milestone (and please don't call this "3.2", no idea who came up with
it, but it's completely wrong)...

(In reply to comment #86)
> With new Maemo 5 update 3.2 nothing has changed to me. Same problem as in 
> comment #71 .
> 
> Current product info
> Maemo 5
> Version 3.2010.02-8
> 
> Quite disappointing ...

Ulle we fixed the issue upstream. We don't have control of what Nokia releases,
and AFAIK this 02-8 release is just a very minor release before the PR1.2 one

Comment 89 Andre Klapper 2010-03-15 20:55:43 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

Comment 90 Andre Klapper 2010-05-10 15:18:10 UTC

*** Bug 10147 has been marked as a duplicate of this bug. ***