Latest Bugs & Tasks

Fixed in hrev49247.

Duplicate of #2882.

gcc_syslibs package does provide libstdc++, see: ​https://bitbucket.org/haikuports/haikuports/src/master/sys-devel/gcc/gcc-4.8.4_2014_12_21.recipe#cl-313
Closing.

This is hrev49245.

The Network preference panel should include the last remaining settings files from /system/settings/network: hostname and hosts. Not sure if both should go into the "DNS" view, as I'm not that versed in all things netwok related...
Maybe, since the hosts entries could become quite a list for some, that should go into its own add-on/view.

Fixed with hrev49245.

Fixed in hrev49244.

In order to be able to write the MBR boot code when creating an Intel partition map on non-x86 Haiku installations, we first need to rewrite it to Intel syntax so that we can use NASM to compile it, as the gcc assembler won't understand x86 assembly for non-x86 builds (e.g. an ARM build).

The MBR boot code was previously written in Intel syntax and compiled with NASM; however, this was changed in hrev49240 in order to implement #4028.

Logs attached. Apparently something in ICU didn't build correctly.

Implemented in hrev49242!

Reported at the wrong place, sorry, it won't do.

Just tried to build ncurses for x86 and failed due to this. It was fixed for x86_gcc2 in ticket #11097 but the others weren't changed.

Closing as a dupe of #12083 which has a reproducible testcase

Most likely a dupe of #3011.

This is the wrong place to report but since I can't access haikuports site with either WebPositive or BeZilla it will have to do. (Ref: ticket #12013)

A few days ago I updated haikuporter and haikuports git repositories and a major change occurred. All packages built with the _x86 extension (eg GCC4 packages) were moved to haikuports/packages/.obsolete and I can no longer build for this target.

This is severely hampering development of some fairly complex stuff I'm working on, so I'd like the change reverted or a REALLY good reason why it was changed. Thanks.

I've been having my system lockup completely (however, the syslog doesn't show anything indicative of the causes), and not even KDL gets triggered, which has resulted in needing to run checkfs.

However, my latest run of checkfs resulted in Repairing failed: I/O error. I also see a few warnings about low resources in the syslog whilst it's running (and memory usage of checkfs continually climbing at a steady rate).

Implemented as of hrev49238.

• Open PowerStatus "battery info" window
• Remove battery from laptop

The window shows 'unused battery', but continues getting info from ACPI. The info is invalid resulting in random values being shown.

No response for 5 months. I can run pretty much any OS in VPC without any problem, so assuming this one is fixed.