Latest Bugs & Tasks
Applied in hrev47590. Leaving the ticket open until the issue is actually fixed and we get the framebuffer going.
closing as per my previous comment.
I'm closing this one for now. I tried a 5xxx card a few weeks ago and it was working as expected.
Ok, found the problem (on our side obviously). Fixed in hrev47586. Thanks for reporting!
Running on an Atom processor:
launch WebPositive and navagate to http://haiku-os.org
Error loading http://haiku-os.org/;
Value too large for defined type
After digging I eventually figured out that the way to use the HTML5 Remote Desktop is to type e.g. this on the server (?) :
echo connected; export TARGET_SCREEN=html5:80; StyledEdit
And then browse to (in my case) http://192.168.1.10 from another computer.. And indeed I do get a blue "canvas", but in all cases (WebPositive on Haiku, Firefox on Windows7 ..etc) the canvas simply contains this error message:
onPageLoad() initDesktop() decodeCanvasMessage() u16:24930 0x6162 code: 24930 '''XHR has no multipart field!'''
It could very well be that I don't know what I'm doing even after spending a couple hours digging through the source, feel free to correct me if so ;-)
Yep, that build failure was indeed caused by hrev47577 - thanks for the heads up.
Should be fixed again in hrev47580.
Ticket #11076 (building haiku on haiku: "package cmake not available!", "don't know how ...) created
When starting to build hrev47579 gcc2 hybrid (jam -q @release-raw) I get the following message:
... Starting build of type regular ... Building Haiku R1/development preview AddHaikuImagePackages: package llvm not available! WebKit build feature not available for x86_gcc2 Gutenprint support not available on x86 qrencode support not available on x86 AddHaikuImagePackages: package cmake not available! ...patience... don't know how to make <x86_gcc2>crtbeginS.o don't know how to make <x86_gcc2>crtendS.o ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... don't know how to make <x86>crtbeginS.o don't know how to make <x86>crtendS.o ...found 113930 target(s)... ...updating 4268 target(s)... ...can't find 4 target(s)... ...can't make 1868 target(s)... ...
And at the end:
... ...skipped 1868 target(s)... ...updated 4023 target(s)...
Finally came around to add that one puny paragraph with a link to Chris Herborth's hey tutorial..
I found myself wishing checkfs had some examples in the help/default output to give me an idea exactly what it wanted for the given parameters, so I wrote a little patch to give 2 examples. One for each of the 2 ways you can specify which device or volume you wish to check.
These are based on the code from hrev47509
The original output looks like this;
Usage: checkfs <options> <device|volume name> Options: -h, --help - print this help text -c, --check-only - do not make any changes to the file system
I added 2 examples below that to show what we're looking for...
Usage: checkfs <options> <device|volume name> Options: -h, --help - print this help text -c, --check-only - do not make any changes to the file system Examples: checkfs -c /Haiku checkfs /dev/disk/ata/0/master/raw
I'm attaching the patch.
Broadcom Wifi network device bcm4312 needs a haiku driver.
There are many notebooks out there which have them onboard.
As I was told it's not working because of a bug but due to the lack(bug #6534) of a
FreeBSD module called siba_bwn which needs to be ported to Haiku.
Would be great if someone could get it working.
p.s. As it's not a Bug and since it hasn't been ported yet
ticket #6474 can be closed.
On hrev47509 I'm seeing pretty serious vanishing ActivityMonitor behavior when moving a window. This was on a bare metal install and tested using both the on-board nvidia video chip and an add-in radeon video card. Same behavior on both.
The behavior is much less noticeable in a virtualbox here, but that might be because I'm running the VM on a much more powerful computer and GPU, so it redraws a lot faster and makes it harder to notice.
But as you can see it's so profound on the bare metal install as to be rather distracting.
Middle clicking a bookmark in bookmark bar opens it in current tab instead of creating a new tab. Subsequent middle clicks work as intended.
~> pkgman list Haiku base-url: http://download.haiku-os.org/haiku-repositories/master/x86_gcc2/current/ priority: 1 HaikuPorts base-url: http://packages.haiku-os.org/haikuports/master/repo/x86_gcc2/current priority: 1 ~> pkgman search openjdk_x86 Status Name Description -------------------------------------------------------------------------------- openjdk_x86 Open-source implementation of the Java Platform, SE ~> pkgman install openjdk_x86 Downloading repochecksum-1... ################################################## Finished downloading repochecksum-1. Validating checksum for Haiku... Validating checksum for Haiku complete. Downloading repochecksum-1... ################################################## Finished downloading repochecksum-1. Validating checksum for HaikuPorts... Validating checksum for HaikuPorts complete. *** failed to find a match for "openjdk_x86": Name not found
I was using Fossil in Haiku, and noticed that its web interface via fossil ui no longer works in Web+. (Note that fossil ui automatically launches Web+ after it is entered in the terminal.)
I get the following error dialog box in Web+ after running fossil ui from the command line...
Error loading http://localhost:8080/doc/tip/www/index.wiki: Connection refused
If I run fossil ui --port 80, then it works perfectly. Any port other than 80 results in the "connection refused" error message. Qupzilla loads the URL just fine regardless of the port, so it only affects Web+. Also, using 127.0.0.1 instead of localhost does not at all remedy the problem, as I tried that as well to be thorough.
Steps to reproduce:
$ pkgman install fossil
$ mkdir repos fossil
$ cd repos
$ fossil clone http://fossil-scm.org fossil.fsl
$ cd ../fossil
$ fossil open ../repos/fossil.fsl
$ fossil ui
Please note this is a GCC2 hybrid build, hrev47571, running HaikuWebKit 1.4.1-3.
(The About window for Web+ needs updated, as it mentions HaikuWebKit 1.4.0 still.)
I looked over the report and Coverity is technically right in that a pointer to a freed object is passed as an argument. However the use is not problematic, as the only action happening is that the BObjectList or rather its base class _PointerList_ removes the pointer from the list (the list isn't owning so it also doesn't delete twice). There is no actual interaction with the pointed to (and freed) object. I closed the CID as "intentional" with this reasoning as a comment and will close this ticket as "no change required".
Specifically the four tagged as 1108467, these look somewhat related to various open tickets here.
I'm guessing that most of the RemoveItem() calls should be RemoveItem(..., false) calls in order to fix these bugs, but I'm not positive so I'll leave this here for Ingo to investigate.
When trying to setup the framebuffer, a floating point exception is raised. The fault is actually when a value is written to CM_CLKSEL_DSS. For now, the process has been disabled by setting gFramebuffer to NULL and a TODO has been included.
Currently, the kernel gets loaded at the virtual address where loader is present; this will cause problem later on. The patch attached with this report moves the entire memory map to a higher memory address which prevents the loader from being overwritten.