[kmail2] [Bug 348474] New: Case sensistive sorting in folder list for destination in POP settings

2015-05-30 Thread abrahams
https://bugs.kde.org/show_bug.cgi?id=348474

Bug ID: 348474
   Summary: Case sensistive sorting in folder list for destination
in POP settings
   Product: kmail2
   Version: 4.14.1
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: config dialog
  Assignee: kdepim-bugs@kde.org
  Reporter: abrah...@acm.org

It I go into configuration, then POP3 Account Settings, then Advanced, then
Destination Folder, the folder list is sorted with all uppercase entries
preceding all lowercase entries.  That is unlikely to be what a user wants; it
certainly isn't what I want.  The sort should be case insensitive.

If the folder list is long, a user may not realize why a lowercase folder
appears to be missing,

Reproducible: Always

Steps to Reproduce:
See details above

Actual Results:  
See details above

Expected Results:  
See details above

See details above

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs


[Akonadi] [Bug 348434] New: Akonadi doesn't start anymore

2015-05-30 Thread bugs5.kde.org
https://bugs.kde.org/show_bug.cgi?id=348434

Bug ID: 348434
   Summary: Akonadi doesn't start anymore
   Product: Akonadi
   Version: unspecified
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: kdepim-bugs@kde.org
  Reporter: bugs5.kde@sjau.ch

Hi there

I just updated my Kubuntu 15.04 with the Kubuntu Team KDE 5.3.1 PPA and now
Akonadi won't start anymore - hence I'm unable to check email and stuff.



Reproducible: Always


Actual Results:  

[QMYSQL]
Name=akonadi
Host=
Options="UNIX_SOCKET=/tmp/akonadi-hyper.FV8bti/mysql.socket"
ServerPath=/usr/sbin/mysqld-akonadi
StartServer=true

[Debug]
Tracer=null


Test 2:  SUCCESS


Akonadi is not running as root
Details: Akonadi is not running as a root/administrator user, which is the
recommended setup for a secure system.

Test 3:  SUCCESS


MySQL server found.
Details: You have currently configured Akonadi to use the MySQL server
'/usr/sbin/mysqld-akonadi'.
Make sure you have the MySQL server installed, set the correct path and ensure
you have the necessary read and execution rights on the server executable. The
server executable is typically called 'mysqld'; its location varies depending
on the distribution.

Test 4:  SUCCESS


MySQL server is executable.
Details: MySQL server found: /usr/sbin/mysqld  Ver 5.6.24-0ubuntu2 for
debian-linux-gnu on x86_64 ((Ubuntu))


Test 5:  ERROR


MySQL server log contains errors.
Details: The MySQL server error log file '/home/hyper/.local/share/akonadi/db_data/mysql.err'
contains errors.

File content of '/home/hyper/.local/share/akonadi/db_data/mysql.err':
2015-05-30 08:33:06 3848 [Note] Plugin 'FEDERATED' is disabled.
2015-05-30 08:33:06 7fb53755e740 InnoDB: Warning: Using
innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in
future releases, together with the option innodb_use_sys_malloc and with the
InnoDB's internal memory allocator.
2015-05-30 08:33:06 3848 [Note] InnoDB: Using atomics to ref count buffer pool
pages
2015-05-30 08:33:06 3848 [Note] InnoDB: The InnoDB memory heap is disabled
2015-05-30 08:33:06 3848 [Note] InnoDB: Mutexes and rw_locks use GCC atomic
builtins
2015-05-30 08:33:06 3848 [Note] InnoDB: Memory barrier is not used
2015-05-30 08:33:06 3848 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-05-30 08:33:06 3848 [Note] InnoDB: Using Linux native AIO
2015-05-30 08:33:06 3848 [Note] InnoDB: Using CPU crc32 instructions
2015-05-30 08:33:06 3848 [Note] InnoDB: Initializing buffer pool, size = 80.0M
2015-05-30 08:33:06 3848 [Note] InnoDB: Completed initialization of buffer pool
2015-05-30 08:33:06 3848 [Note] InnoDB: Highest supported file format is
Barracuda.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 212.
InnoDB: You may have to recover from a backup.
2015-05-30 08:33:06 7fb53755e740 InnoDB: Page dump in ascii and hex (16384
bytes):
 len 16384; hex


[]


InnoDB: End of page dump
2015-05-30 08:33:06 7fb53755e740 InnoDB: uncompressed page, stored checksum in
field1 31810981, calculated checksums for field1: crc32 3398403491, innodb
1971167555, none 3735928559, stored checksum in field2 2129773491, calculated
checksums for field2: crc32 3398403491, innodb 2129773491, none 3735928559,
page LSN 0 829873485, low 4 bytes of LSN at page end 829873485, page number (if
stored to page already) 212, space id (if created with >= MySQL-4.1.1 and
stored already) 0
InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 212.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also
http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
2015-05-30 08:33:06 7fb53755e740  InnoDB: Assertion failure in thread
140416294184768 in file buf0buf.cc line 4201
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
06:33:06 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it w