Latest Bugs & Tasks

Implemented in hrev45627.

Haiku does not support Greek Polytonic for my greek language, but Windows, Linux and MacOS can. A long time ago I started my own project for Haiku in order to support Greek Polytonic keyboard. My source code increased the 5 dead-keys up to 32 dead-keys and also each dead key array can contain up to 19 pairs of dead key characters. Of course it does not break compatibility.

The project is finished and I have attached my patches.
If you accept my patches, please also close the other ticket:

​https://dev.haiku-os.org/ticket/2098#

Here is the video showing the possibilities.

​http://www.youtube.com/watch?v=rICUMM1gQls

2013-05-04 15:13:29,246 INFO No information found about language code
2013-05-04 15:13:29,323 INFO Running update_against_templates over /nb/haiku/
2013-05-04 15:13:29,336 DEBUG cache miss for /nb/haiku/add-ons/disk_systems/bfs/nb.catkeys:get_mtime
2013-05-04 15:13:29,432 DEBUG cache miss for /nb/haiku/:getquickstats
2013-05-04 15:13:29,633 DEBUG Cache miss for /srv/pootle-production/catalogs/haiku/add-ons/disk_systems/bfs/en.catkeys
2013-05-04 15:13:29,636 DEBUG Cache miss for /srv/pootle-production/catalogs/haiku/add-ons/disk_systems/bfs/nb.catkeys
2013-05-04 15:13:29,642 DEBUG Updating /nb/haiku/add-ons/disk_systems/bfs/nb.catkeys
2013-05-04 15:13:29,665 ERROR Failed to run update_against_templates over /nb/haiku/:
'ascii' codec can't encode character u'\xe5' in position 4: ordinal not in range(128)

I use a hrev45516 nightly. When I add files to project in BeIDE show me a KDL
with vm_page_fault.

Running make check in hrev45614 (containing a fix for #9734 which I needed), causes the following KDL:

Last message repeated 8 times.
PANIC: _mutex_unlock() failure: thread 2779 is trying to release mutex 0x801b6384 (current holder 2218)
Welcome to Kernel Debugging Land...
Thread 2779 "postgres" running on CPU 1
stack trace for thread 2779 "postgres"
    kernel stack: 0xccf44000 to 0xccf40000
      user stack: 0x61b28000 to 0x62b28000
frame               caller     <image>:function + offset
 0 ccf47d58 (+  32) 80132aa2   <kernel_x86> arch_debug_stack_trace + 0x12
 1 ccf47d78 (+  16) 80092db3   <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
 2 ccf47d88 (+  12) 8012553e   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
 3 ccf47d94 (+  48) 80094856   <kernel_x86> debug_call_with_fault_handler + 0x5e
 4 ccf47dc4 (+  64) 80092fd3   <kernel_x86> kernel_debugger_loop(0x801718f7 "PANIC: ", 0x8016ebe0 "_mutex_unlock() failure: thread %ld is trying to release mutex %p (current holder %ld)
", 0xccf47e70 "
", int32: 1) + 0x21b
 5 ccf47e04 (+  48) 80093337   <kernel_x86> kernel_debugger_internal(0x801718f7 "PANIC: ", 0x8016ebe0 "_mutex_unlock() failure: thread %ld is trying to release mutex %p (current holder %ld)
", 0xccf47e70 "
", int32: 1) + 0x53
 6 ccf47e34 (+  48) 80094be2   <kernel_x86> panic + 0x36
 7 ccf47e64 (+  64) 800894cc   <kernel_x86> _mutex_unlock + 0x74
 8 ccf47ea4 (+ 160) 800f669f   <kernel_x86> _user_xsi_semop + 0x8f3
 9 ccf47f44 (+ 180) 801281e0   <kernel_x86> handle_syscall + 0xcd
user iframe at 0xccf47fa8 (end = 0xccf48000)
 eax 0x1e          ebx 0x23ba188      exc 0x62b27884  edx 0x610e8114
 esi 0x17cd0fc     edi 0x549b19b0     ebp 0x62b278b0  esp 0xccf47fdc
 eip 0x610e8114 eflags 0x3202    user esp 0x62b27884
 vector: 0x63, error code: 0x0
10 ccf47fab (+   0) 610e8114   <commpage> commpage_syscall + 0x04
11 62b278b0 (+  64) 015162w9   <postgres> PGSemaphoreLock + 0x65
12 62b278f0 (+  64) 0155d4be   <postgres> LWLockAcquireOrWait + 0x14e
13 62b27930 (+  80) 013a2e38   <postgres> XLogFlush + 0x80
14 62b27980 (+ 272) 01396092   <postgres> ForceSyncCommit (nearest) + 0x526
15 62b27a90 (+  48) 01396aab   <postgres> ForceSyncCommit (nearest) + 0xf3f
16 62b27ac0 (+  48) 013974b5   <postgres> CommitTransactionCommand + 0x121
17 62b27af0 (+  32) 0156a484   <postgres> check_log_duration (nearest) + 0x8e0
18 62b27b10 (+ 176) 015686a9   <postgres> pg_plan_queries (nearest) + 0x435
19 62b27bc0 (+ 144) 0156c409   <postgres> PostgresMain + 0x839
20 62b27c50 (+  80) 01525fe3   <postgres> ClosePostmasterPorts (nearest) + 0x290b
21 62b27ca0 (+  48) 015257d2   <postgres> ClosePostmasterPorts (nearest) + 0x20fa
22 62b27cd0 (+ 336) 015224f6   <postgres> PostmasterMain (nearest) + 0x19ee
23 62b27e20 (+ 272) 01521df6   <postgres> PostmasterMain + 0x12ee
24 62b27f30 (+  64) 014b903c   <postgres> main (nearest) + 0x208
25 62b27f70 (+  48) 0134bd3b   <postgres> _start + 0x5b
26 62b27fa0 (+  48) 0117f586   </boot/system/runtime_loader@0x01170000> <unknown> + 0xf506
27 62b27fd0 (+   0) 618e825e   <commpage> commpage_thread_exit + 0x00

I don't know yet if it is reproducible as Haiku now gives another KDL when I try to start it.
I will have a look at the other KDL and reinstall Haiku again to see if I can reproduce this one.
There might be some typos in the KDL output as I made a photo of the KDL and typed it over. I still have the photo, so I can look back if the KDL above contains something odd.

When defining a user build profile that writes the image to a local partition, e.g. /dev/sda57, on Linux one needs to run sudo to do so.

However, running the entire build under sudo is inadvisable. I've created a patch that would allow a user build profile to specify HAIKU_REQUIRES_SUDO = 1 such that at the image writing stage, it will invoke the build_haiku_image script using sudo.

Implemented in hrev45612.

I use a single button 2008 Macbook Pro Trackpad and it'd be nice to be able to right click by using two fingers on the track pad while pressing the left mouse button. That's how the typical Macbook right clicks.
At the moment I can't right click at all unless I use a usb mouse.

Terminal exhibits a very long lag before returning to normal, when tab completition is used and accidentially the string cannot be completed, e.g. because there is no file with the given starting string.

Thanks a lot! Applied in hrev45610.

Sorry, didn't notice you assigned it to yourself already! In any case, it's fixed in hrev45609 - I just use B_RELATIVE_TIMEOUT in case the timeout is 0.

When a BMenu is large enough to require scrolling, the marked item may not be in view.

I've attached a patch that will scroll the marked item into view. The patch also behaves like a BMenuField, scrolling the item to be immediately under the cursor when the menu is opened if possible.

Currently, there are two mimetypes (mid & midi) whose descriptions are the same ("MIDI File").

In Tracker's Find Panel, as they both have the same label, the marked item doesn't necessarily get cleared correctly, leading to inconsistent UI state.

I have attached a patch to correct this, using similar logic to that used in the FileTypes preflet.

hrev45606
I was searching for "Microsoft PowerPoint Presentation Macro-enabled Document" and this file type name is truncated in the popup menu of "Find" window.
Screenshot attached:

Duplicated.
See #8801.

When trying to receive data from a nonblocking socket, I get an "Operation timed out" error, while I am expecting a EWOULDBLOCK error as there is no data to read. Changing the socket to blocking does block as expected.
I expanded my test case from #9678 and attached it to this ticket.

This happens with href45525.