Latest Bugs & Tasks
I've been using named pipes for a few things, and I typically just leave them sitting around. However, I'll go to copy a directory containing a FIFO, and the copy just stalls when it hits it.
Worse, I can't find any way to cancel the copy, except to reboot.
I think that the copy procedure could just ignore FIFOs, or if not, pop up an alert to either skip or cancel.
Edited and applied in hrev47464.
From the patch description:
* NUM_IO_VECTORS is not 256 on x86, but rather 224 as set by NUM_IO_VECTORS in "arch_int.h". * Jessicah mentioned hearing about MSI crashes before, but that was a few weeks ago. * These were the only CIDs in the MSI code.
Assigning to Pawel as he was the last one to touch MSI code, and Michael Lotz has not been seen in a while.
I got a kernel panic when a DVD was in the drive and I launched CD player. I am running hrev47449. I have attached a photo of the kernel panic.
It crashes in NetSurf code, there's nothing Tracker can do about that.
Please report the bug to NetSurf bugtracker instead.
This is hrev47449.
- Insert audio CD into drive
- Open CDPlayer
- CDPlayer claims it is playing but no sound comes out
- Open the "Audio CD" from the Desktop and open one of the tracks in MediaPlayer
- Sound comes out
I vote to wipe CDPlayer off the face of the earth and give the CD-as-WAV filesystem support to lookup CDDB, which is the only thing CDPlayer can do that it can't do right now.
This is hrev47449. Happens every time for me.
Crash report attached.
There is a mismatch between the gcc_bootstrap version listed in build/jam/repositories/HaikuPortsCross/arm and the recipe available in HaikuPorts which prevents the bootstrap-raw target from building successfully.
"pkgman install openjdk_x86" results in "name not found". Same thing happens in HaikuDepot.
A more descriptive error is in order at least...
Yes, that's how Linux does it IIRC.
Switching to "Unscheduled" as this will be at least after R1 due to breaking binary compatibility.
Applied in hrev47448
listimage displays 0 for these values. I'm not sure if this is suppose to happen in the kernel or runtime loader.
I understand this is not an official POSIX thing but rather a Linux thing; still, many applications use it and we should support it.
A recipe has been added for haikuporter some time ago.
The fix only hides the issue. Affects many other screensavers (Gravity is an example).
Tools->Refresh depots resets current depot to All depots, however, packages are still shown from the previously selected one.
When you download a file which has a the Content-Disposition header it ignores it. An example: https://megworld.co.uk/content_disposition.txt
This should download the file with the filename "test.txt" however webpositive doesn't download it as the "attachment" in the Content-Disposition header suggests and files which it does download it ignores the filename specified.
RFC2616 section 19.5.1 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html).
This is hrev47407.
HaikuDepot's "Depot" pop-up menu has an item "Local", that currently seems to filter the list to all locally installed packages. It's identical to choosing "Installed packages" from the "Show" pop-up menu that also holds the different categories.
I propose having a query for all HPKGs on all mounted volumes for the "Local" depot instead. All HPKGs that are not currently installed should show the status "Available" and should be installable, like any other (online) package.
committed as part of hrev47436