Bug#846170: claws-mail handles IMAP UIDs incorrectly
Package: claws-mail
Version: 3.14.1-1.1
Severity: normal
Dear Maintainer,
The IMAP UIDs on one of my folders has increased to more than 2^31
which is causing claws-mail to repeatedly complain:
> folder.c:2265:Removed message 2147483647 from cache.
Upon examining folder.c I notice that, while cache_max_num,
folder_max_num, cache_cur_num and folder_cur_num ARE stored as unsigned
int (guint), in certain situations G_MAXINT is used as an "invalid
value". The attached patch changes this to G_MAXUINT. The patch also
changes usage of GPOINTER_TO_INT and GINT_TO_POINTER to their unsigned
variants.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages claws-mail depends on:
ii libatk1.0-0 2.22.0-1
ii libc62.24-5
ii libcairo21.14.6-1.1
ii libcompfaceg11:1.5.2-5
ii libdb5.3 5.3.28-12
ii libdbus-1-3 1.10.12-1
ii libdbus-glib-1-2 0.108-1
ii libenchant1c2a 1.6.0-11+b1
ii libetpan17 1.6-2
ii libfontconfig1 2.11.0-6.7
ii libfreetype6 2.6.3-3+b1
ii libgdk-pixbuf2.0-0 2.36.0-1
ii libglib2.0-0 2.50.2-1
ii libgnutls30 3.5.6-4
ii libgtk2.0-0 2.24.31-1
ii libice6 2:1.0.9-1+b1
ii libldap-2.4-22.4.44+dfsg-1
ii liblockfile1 1.09-6
ii libpango-1.0-0 1.40.3-3
ii libpangocairo-1.0-0 1.40.3-3
ii libpangoft2-1.0-01.40.3-3
ii libpisock9 0.12.5-dfsg-2+b2
ii libsasl2-2 2.1.27~72-g88d82a3+dfsg-1
ii libsm6 2:1.2.2-1+b1
ii xdg-utils1.1.1-1
ii zlib1g 1:1.2.8.dfsg-2+b3
Versions of packages claws-mail recommends:
pn aspell-en | aspell-dictionary
ii claws-mail-i18n3.14.1-1.1
ii xfonts-100dpi 1:1.0.4+nmu1
Versions of packages claws-mail suggests:
ii chromium [www-browser] 53.0.2785.143-1
pn claws-mail-doc
pn claws-mail-tools
ii firefox-esr [www-browser] 45.5.0esr-1
pn gedit | kwrite | mousepad | nedit
ii lynx [www-browser] 2.8.9dev11-1
-- no debconf information
diff -ur claws-mail-3.14.1.orig/src/folder.c claws-mail-3.14.1/src/folder.c
--- claws-mail-3.14.1.orig/src/folder.c 2016-11-28 19:28:22.869928915 +
+++ claws-mail-3.14.1/src/folder.c 2016-11-28 21:05:12.490606898 +
@@ -2196,22 +2196,22 @@
cache_list_last = g_slist_last(cache_list);
cache_max_num = ((MsgInfo *)cache_list_last->data)->msgnum;
} else {
- cache_cur_num = G_MAXINT;
+ cache_cur_num = G_MAXUINT;
cache_max_num = 0;
}
if (folder_list_cur != NULL) {
GSList *folder_list_last;
- folder_cur_num = GPOINTER_TO_INT(folder_list_cur->data);
+ folder_cur_num = GPOINTER_TO_UINT(folder_list_cur->data);
folder_list_last = g_slist_last(folder_list);
- folder_max_num = GPOINTER_TO_INT(folder_list_last->data);
+ folder_max_num = GPOINTER_TO_UINT(folder_list_last->data);
} else {
- folder_cur_num = G_MAXINT;
+ folder_cur_num = G_MAXUINT;
folder_max_num = 0;
}
- while ((cache_cur_num != G_MAXINT) || (folder_cur_num != G_MAXINT)) {
+ while ((cache_cur_num != G_MAXUINT) || (folder_cur_num != G_MAXUINT)) {
/*
* Message only exists in the folder
* Remember message for fetching
@@ -2240,8 +2240,8 @@
}
if (add) {
-new_list = g_slist_prepend(new_list, GINT_TO_POINTER(folder_cur_num));
-debug_print("Remembered message %d for fetching\n", folder_cur_num);
+new_list = g_slist_prepend(new_list, GUINT_TO_POINTER(folder_cur_num));
+debug_print("Remembered message %u for fetching\n", folder_cur_num);
}
/* Move to next folder number */
@@ -2249,9 +2249,9 @@
folder_list_cur = folder_list_cur->next;
if (folder_list_cur != NULL)
-folder_cur_num = GPOINTER_TO_INT(folder_list_cur->data);
+folder_cur_num = GPOINTER_TO_UINT(folder_list_cur->data);
else
-folder_cur_num = G_MAXINT;
+folder_cur_num = G_MAXUINT;
continue;
}
@@ -2262,7 +2262,7 @@
*/
if (cache_cur_num < folder_cur_num) {
msgcache_remove_msg(item->cache, cache_cur_num);
- debug_print("Removed message %d from cache.\n", cache_cur_num);
+ debug_print("Removed message %u from cache.\n", cache_cur_num);
/* Move to next cache number */
if (cache_list_cur)
@@ -2271,7 +2271,7 @@
if (cache_list_cur != NULL)
cache_cur_num = ((MsgInfo *)cache_list_cur->data)->msgnum;
else
-cache_cur_num = G_MAXINT;
+cache_cur_num = G_MAXUINT;
update_flags |= F_ITEM_UPDATE_MSGCNT | F_ITEM_UPDATE_CONTENT;
@@ -2291,7 +2291,7 @@
new_list =
Bug#822640: tmux: Please don't break configs when deprecating config items
Package: tmux Version: 2.2-1 Severity: important Dear Maintainer, I use powerline (Debian package: powerline) with tmux. This gives me a nicer-looking status line than the default for tmux. However, upon updating to version 2.2-1 this evening, I found that tmux started with just the basic status line and it also complained at startup that various options (namely, status-utf8, utf8 and mouse-uft8) were unknown. Now, in my own config, it's easy enough for me to remove those options, but still powerline doesn't start, due to it using the status-utf8 option. I'd like to complain about how tmux handles this removal of functionality. I understand that code changes, that options become unnecessary and that advising the user to remove stale cruft from their config files is useful. However, tmux gave no warning - to either me or, it would seem, the maintainers of software that works with tmux - that these options were going away. There is nothing in NEWS.Debian.gz and the only comment in changelog.Debian.gz is "New upstream release." Fair enough, changelog.gz notes these changes, but that isn't scanned by apt-listchanges. I think, in an ideal world, tmux should apply Postel's Law to its config files: Be strict in what you send, be generous in what you recieve. By this I mean that tmux should *ignore* config options that it doesn't understand. If the configuration file doesn't parse, that's a good candidate for failure, but if the file parses, but contains commands it doesn't understand, then this should just raise a warning and tmux should continue (in particular, it should return an error code of 0). -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tmux depends on: ii libc6 2.22-7 ii libevent-2.0-5 2.0.21-stable-2+b1 ii libtinfo5 6.0+20160319-1 ii libutempter01.1.6-3 tmux recommends no packages. tmux suggests no packages. -- no debconf information
Bug#670521: xnbd-server: fails to start, claiming glib thread not supported
Package: xnbd-server Version: 0.1.0-pre-hg17-c29967ffe2f3-1 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, I have been using XNBD-server for a while and only recently needed to restart it (due to changing address to serve on). While the server worked fine before, now it dies immediately as follows: 12:20:29 darac@crush ~ /usr/sbin/xnbd-server --target --daemonize --logpath /home/darac/logs/xnbd-server.log --lport 8520 /usr/local/share/rootnfs/remy/remy-01.img ** (process:11944): ERROR **: (tid:0x7f5af53b5700) (main) glib thread not supported Even just running /usr/sbin/xnbd-server (as myself OR as root) just returns the same error. Looking at the upstream code (https://bitbucket.org/hirofuchi/xnbd/src/e75b93a47722/trunk/xnbd_server.c#cl-800), I notice a rather odd consruction: if (g_thread_supported()) err(glib thread not supported); If the call returns true, raise an error? Anyway, I look forward to hearing back. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (550, 'testing'), (450, 'unstable'), (450, 'stable'), (445, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37.2 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xnbd-server depends on: ii libc6 2.13-27 ii libglib2.0-0 2.32.0-4 ii python2.7.2-10 ii xnbd-common 0.1.0-pre-hg17-c29967ffe2f3-1 xnbd-server recommends no packages. xnbd-server suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528700: Visible in 6.12.22, still?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, May 25, 2011 at 09:11:04PM +0200, Steffen Möller wrote: I just uploaded 6.12.27. Had not verified that the fix made it into the source tree. Does it fix the issue? Yes, that looks good. Boinc starts up happily now. - -- Paul Saunders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJN3j7bAAoJEKB7YbRsd8TG3hgP/0gJzUEkZ0s90hWoHydxieE2 IbkPJZs6vvzarXo+cwAyCdAo3ulv57fjmeKwrMGQkGVQLtVr7YZ/ej+tRRVvc/xr 2YQHJCE6lcdCG+wnbmyoAxhMRPjVLISeX+C/L/bZTAOaoHZoJtLUSnaK37nac72/ /3YinFAuUQik9FGgFiWkgdHGkLMjwOyOBacIjWhSqao9uu68CjAwCSPPHfAjgLBh D1QoZBEj2SdwrSv8VvqqHp7m1ZH+G1lZsbLIVGkgpUDspYKDsZXKHmtaQvZSDR9E YkXaltNcF7LI9oTeYdSvsvTcqGl9ectHDwVedOXt2I6wwXR3DOBAQ35Rz9k1UVzX qbYh4RVAEvs7J89Ns+AjDLrReGaVU/BnhAy56d89o19UZBDjovtNux5uC5f/ut+k rj1a393auLLypKjQBHQVa/gXiEzQKBggAEMcnOxkPGlJ451dxaNO5D6puvG8meSo 5+nsvqx2XdrZ3sgOh+cea6q8itPZvx6kzPfKrB8bbjSsGExdIRc/9Kmjjk3HfCtv M+Ze+IeZbKjzzVxxWGIp8qe4Er98eXbVR1SoaXPvF53nXO0bd+BUFbui8Mc6ZBBq bjCoA/HQQWnQjXyr+jyTvBx9FBloxWX4hZ8zXPghuIkCXaEXGMPKKQmOeYZnNkDV cJOsbpGcWBqXMxihMFka =+RHk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528700: Visible in 6.12.22, still?
On Sat, Apr 16, 2011 at 10:33:32PM +0200, Steffen Möller wrote: Hello, we had upstream fix something for the manager of 6.10.58, so maybe there is something for the client side of 6.10.58, too. It very much looks like it, indeed. There is a version 6.10.60 out and I'd need to get it confirmed for that first, I am afraid. Now, I don't have a package for it, yet. Could you please try confirming it on 6.12.22? Hello, I am experiencing this problem on boinc-client 6.12.26+dfsg-1. According to http://comments.gmane.org/gmane.comp.distributed.boinc.devel/4281, this is a problem when attached to the yoyo@home project which creates a recursive symlink under ~boinc/.wine Following the links suggests that the problem is fixed upstream by BOINC bug #1108. Presumably, though this needs to be patched into the sid version? -- Paul Saunders signature.asc Description: Digital signature
Bug#578047: IPv6 not enabled
Package: squid3 Version: 3.1.1-3 Tags: ipv6 Since updating to version 3.1.1-3, squid3 complains that IPv6 has not been enabled This is what happens when I try to restart squid3: [da...@fowler:/etc]$ sudo /etc/init.d/squid3 restart (04-16 12:15) Restarting Squid HTTP Proxy 3.x: squid32010/04/16 12:21:58| aclIpParseIpData: IPv6 has not been enabled. build with '--enable-ipv6' 2010/04/16 12:21:58| aclIpParseIpData: IPv6 has not been enabled. build with '--enable-ipv6' 2010/04/16 12:21:58| aclIpParseIpData: IPv6 has not been enabled. build with '--enable-ipv6' 2010/04/16 12:21:58| Warning: empty ACL: acl winterwolf_co_uk src 2001:470:1f08:118::/64 2010/04/16 12:21:58| aclIpParseIpData: IPv6 has not been enabled. build with '--enable-ipv6' 2010/04/16 12:21:58| aclIpParseIpData: IPv6 has not been enabled. build with '--enable-ipv6' FATAL: Bungled squid.conf line 78: http_port [2001:470:1f08:cb::2]:3128 Squid Cache (Version 3.1.1): Terminated abnormally. CPU Usage: 0.007 seconds = 0.004 user + 0.003 sys Maximum Resident Size: 0 KB Page faults with physical i/o: 0 failed! This used to work with previous versions of squid3. Let me know if I can supply any further information (reportbug's currently broken, too (Bug 577986), so I had to send this manually). signature.asc Description: Digital signature
Bug#559045: maildrop filter tolower() and toupper() functionality get optimized out by gcc
On Tue, 1 Dec 2009 15:38:34 +0100, Bastian Blank wa...@debian.org wrote: On Tue, Dec 01, 2009 at 03:26:29PM +0100, Josip Rodin wrote: Is there a bug in maildrop-2.2.0/maildrop/recipenode.C that causes it to get compiled differently with -O1, or is the problem with the compiler? Are you able to produce a minimal testcase? Certainly. If we have a filter test.mailfilter as follows: FOO=TestTestTest LOWERFOO = tolower($FOO) UPPERFOO = toupper($FOO) echo FOO is $FOO echo LOWERFOO should be testtesttest, is $LOWERFOO echo UPPERFOO should be TESTTESTTEST, is $UPPERFOO With the standard build, I do echo | maildrop test.mailfilter and get FOO is TestTestTest LOWERFOO should be testtesttest, is UPPERFOO should be TESTTESTTEST, is But with the -O1 build, I get FOO is TestTestTest LOWERFOO should be testtesttest, is testtesttest UPPERFOO should be TESTTESTTEST, is TESTTESTTEST Bastian -- Our way is peace. -- Septimus, the Son Worshiper, Bread and Circuses, stardate 4040.7. -- Darac Marjal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#396778: mpdscribble: Plugin bug triggered by bulk submissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Kuno Woudt wrote: On Thu, Nov 02, 2006 at 08:44:17PM +, Darac Marjal wrote: When attempting to submit a large number of songs, the submission may be rejected with the comment Plugin bug: Not all request variables are set - got 2 parameters. This sounds like the submit data was truncated, I'm not sure what last.fm does if that happens -- but I assume data could be lost, so I do not think throttling is a solution. I just looked it up in http://www.audioscrobbler.net/wiki/Protocol1.1 , which says If you try to submit more than 10 tracks at once, some of them may not be accepted.. So, I expect changing the MAX_SUBMIT_COUNT to 10 should solve the problem. I'll try to have a closer look this weekend. -- Kuno. It appears that, if the submission is rejected, the tracks remain in the cache (so the cache will grow without end), so data's not actually lost. But thanks for taking a look anyway. - -- Paul Saunders | PGP: 0xCC9A6F67 | http://www.darac.org.uk aka Darac Marjal | ICQ:4161505 |[EMAIL PROTECTED] - You're already carrying the sphere! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRUs/2qB7YbRsd8TGAQr1NxAAkrA6MxFwijA74towMYjlRSOy+srwVQPF f9V1/Ea3DxDNFJ0X2+K9BtNrJJN/gIn+Cnw+HImZ+WZ1Jjg8vPHr9rkYWBIGPyMt GUrFRE+GIzMpkVYyqQ5iNhaZytnFOGsaHZEH4mfk09s63KkS9Ysjfyih0RMrRUjh sGKyfnaOwbvRzsaDhPB/ChPd3EAQe1/IJ7pC606pwTXjg+Y/tFUynxZFbgNVPfes anXE3RsdiFkIojAtgQn5rW26g85XmWYrC5pq0+0VQ3dhFIq4JEpclClryW1hwUo7 /2eNmj6gSNk9TltWx9W59LHojWZFLYW/P3Zsfo3dbcP6XT2Xlt1F309XVHpFJCra XkNhifPQTCjvk5JeiEKQcK09sBdzjpOjkluFLAIZGn7N0YqW58g1LGVTnZv3V1Jd dvQVifNoN+FngX+atl767nlWIpRQv1Zs1HGr/QsX+uvTy8SM6iYY1igcxnzkMh02 B9dIbvAhaZK433Gm/xrztGVzuW+qAMheYuH+Qm8x5on/sCamysyPpKOuhFDxPWtn ZXtcqlM+w6LQnewRZb9jwLTZGGU1Xeo2/UVdw3wSzySO32Gr0tjLszLnGBttv4U/ xY+8ATBY2mkh9g35YLx+2p0fqreuAxqbdh+7sONISEW5QQlye0m2zOK3wOxtIAwV zLXIF/40qBM= =qjz/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
