Latest Bugs & Tasks

​http://www.freelists.org/post/haiku-commits/buildbot-failure-in-HAIKU-on-whole-buildset,128

With hrev49130 gcc2h，kernel panic after install haiku to mobile hard disk drive. I used to experence the same panic tens of commits before this one. So I think a ticket should be created.

I can't reproduce this either. Please reopen if you can.
Thanks.

Working on FontBoy I had installed hundreds of fonts, I had never experience this.
I close this ticket. Please reopen with the list of fonts if this still happen for you.
Thanks.

Fixed - now the last 50 nightlies are kept and then images are getting thinned out. This caused 220 from the 280 nightlies (per architecture and image variant) to get deleted, freeing a considerable amount of storage space on baron's home partition.

Yep. doesn't belong here. Besides, I couldn't reproduce the issues. Let's hope stippi has will check the issue for WonderBrush-NG... :)

The old analog TV application needs a modern replacement, since most of the world has shut this system down in favour of digital TV.

Suggest targeting the Realtek RTL2832U controller and Elonics E4000 tuner type USB sticks since these are cheap (~ $20) and can be used also for Software-Defined Radio.

Ref: ​http://sdr.osmocom.org/trac/wiki/rtl-sdr

Fixed in hrev48997.

Dup of #4868.

Implemented by Hamish in hrev49143.

The following devices need to be added to src/add-ons/kernel/drivers/common/usb_modeswitch.cpp

Huawei E5377 USB modem/router
Huawei HWD12 LTE USB modem stick

The required code follows:

{ /* MSG_HUAWEI_4 */
0x55, 0x53, 0x42, 0x43, 0x12, 0x34, 0x56, 0x78,
0x00, 0x00, 0x00, 0x00, 0x80, 0x01, 0x0a, 0x11,
0x06, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
},
...
	{{ 0, 0, 0, HUAWEI_VENDOR, 0x1f02}, MSG_HUAWEI_3}, // E5377
	{{ 0, 0, 0, HUAWEI_VENDOR, 0x1f03}, MSG_HUAWEI_4}, // HWD12 LTE

I also note that this file object isn't being created, but I'm fairly unfamiliar with Jam so can't debug it at this stage. Consequently this functionality is missing from the build.

Thanks for looking over it. Applied with hrev49142.

Periodic update BPose's are ones that get updated periodically through TTracker::Pulse() like the volume icons on the desktop with their free space bars. They are kept in a list managed by a global PeriodicUpdatePoses object.

TTracker::Pulse() calls PeriodicUpdatePoses::DoPeriodicUpdate() (Utilities.cpp:222) which locks the PeriodicUpdatePoses object and then locks the looper of each BPoseView where a BPose is to be updated.

When a volume is unmounted the FS notification triggers the BPose representing the volume on the desktop to be removed and destroyed. The BPose destructor then removes itself from the list via PeriodicUpdatePoses::RemovePose() (Utilities.cpp:200). This goes through the list and when it finds the item, it locks the object and removes the BPose. Locking is broken because items are added to the list without locking and the list traversal on remove doesn't happen locked. This should be fixed as well but doesn't affect the deadlock here.

The deadlock happens when DoPeriodicUpdate already holds the lock of PeriodicUpdatePoses but hasn't yet locked the looper of the BPoseView while the FS notification is handled (which means the looper is locked) but hasn't yet caused PeriodicUpdatePoses::RemovePose() to be called.

Attached is a KDL session showing more details. As I am tracking other issues currently and am unsure how this could be fixed cleanly, I'll leave this here without intention of fixing it myself.

A comment in the current virtual memory code states that differently from BeOS, in Haiku it's not possible to delete an area_id created by another team, this should be cleared out in the Haiku Book.

Dupe of #10924

The POSIX API provided by Haiku is missing the declaration and implementation of pthread_condattr_setclock (and maybe pthread_condattr_getclock), so even though Haiku provides a monotonic clock, it is not possible to inform the pthread implementation, that it shall be used.

Crashing when accessing a website. Report attached:

If I boot 49132 with my Focusrite Scarlett 2i4 attached I either get a garbled display or a KDL. The KDL seems to be caused by Haiku's USB midi support but I don't get a syslog when that happens.

I have attached a syslog dump from booting with the 2i4 attached which resulted in a messed-up display ie no desktop.

This is hrev49124.

The attached patch replaces "v" with "Version" as it's what all the other Translators do. Also some sentence casing. It all compiles and should work, but when I tested by putting the translators under non-packaged/ and rebooting with blacklisting the system JPEG translator, Tracker and all kinds of stuff crashed.
While I do think I converted the sprintf correctly to snprintf, I'd rather have someone else have a look and apply the patch. Thanks.

• Data at ​https://www.haiku-os.org/guides/building/compiling-arm is hopelessly out-of-date. e.g. target raspberri_pi no longer exists (now broken into rpi1 & rpi2), instructions to build the tools fail, etc etc.

• ReadMe.Compiling specifies that Mtools and mkimage are required, but does not detail how to build or install them.