Create the script's tempdir before displaying the initial alert.
Fixes#5509.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35695 a95241bf-73f2-0310-859d-f6bbb57e9c96
been part of r35691, where I applied a patch by mmadia taken from ticket #5457
(which was previously closed by bonefish), with some modifications by me.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35692 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added iprowifi4965 driver to the image.
* Add the firmware for the Wifi drivers that need it to the image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35687 a95241bf-73f2-0310-859d-f6bbb57e9c96
* updated optional package ICU-devel to include links to make the libs available
for development (only links for the current abi are being created)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35680 a95241bf-73f2-0310-859d-f6bbb57e9c96
the haiku-anyboot-image pseudo target. As I'm not too much at home with Jam I'd
appreciate any input. Especially for the TODO where removing the MBR using
RmTemps seems to cause a failure to get it built again every other time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35668 a95241bf-73f2-0310-859d-f6bbb57e9c96
and a Haiku image and fuses everything to a hybrid MBR/ISO image. Since it
contains a valid MBR, partition table and el-torito CD boot record such an image
should be pretty universally bootable. It can be written to disks, USB sticks or
CDs/DVDs. Since it has a partition table in place it is also possible that it
helps with the non-booting USB sticks where the BIOS (wrongly) assumes a
partition table.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35667 a95241bf-73f2-0310-859d-f6bbb57e9c96
certain conditions indicate that we might deal with a fixed 512 bytes MBR on
a non 512 byte block size medium. One condition is that at least one partition
had to be shrunk to fit the available size (which usually happens with larger
block sizes). We retry with a fixed 512 block size once and compare the result
if it didn't improve the situation it is reverted again. This is mostly a
preparation for the upcoming "anyboot" hybrid MBR/ISO images.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35664 a95241bf-73f2-0310-859d-f6bbb57e9c96
--Cette ligne, et les suivantes ci-dessous, seront ignorées--
M data/catalogs/preferences/opengl/pt.catkeys
M data/catalogs/preferences/keymap/pt.catkeys
M data/catalogs/preferences/mouse/pt.catkeys
M data/catalogs/preferences/fonts/pt.catkeys
M data/catalogs/preferences/network/pt.catkeys
M data/catalogs/preferences/appearance/pt.catkeys
M data/catalogs/preferences/locale/pt.catkeys
M data/catalogs/preferences/keyboard/pt.catkeys
M data/catalogs/preferences/bluetooth/pt.catkeys
M data/catalogs/preferences/touchpad/pt.catkeys
M data/catalogs/preferences/cpufrequency/pt.catkeys
M data/catalogs/apps/mail/pt.catkeys
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35655 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add file map and cache and do reads through the file_cache for file ICBs.
* Move the private _Read() backend from the header to the implementation file.
* Read() is now only used for directory iteration.
* Turned off the verbose debug output.
* Minor cleanup.
This fixes the abuse of the block_cache, should allow executables on UDF and
won't panic on protected content.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35652 a95241bf-73f2-0310-859d-f6bbb57e9c96
multiple blocks at a time which it doesn't do as it always only returns one
block (and actually completely ignores the provided offset and length).
It only didn't crash after that because it would in the end always only memcpy
length >> block shift bytes which ends up being pretty small in most cases.
Since it does block wise mapping it can't do multiple blocks anyway, and really
using the block cache for this is all wrong because this should really use a
file map to resolve the block mapping and then use the file cache instead.
Still this at least gets it working. Beware though that protected DVD content
will make the block cache panic, as reading these blocks without prior setting
the drive up correctly will fail (the drive will stall the reads).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35651 a95241bf-73f2-0310-859d-f6bbb57e9c96
remove the block from an unlocked cache and the cache->lock would be unlocked
twice when the calling function unlocked. It panics in that case anyway, but
this should make it continuable and is more correct.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35648 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Set the _type as well, this gets file listings work.
* Some cleanup and debug output moves/fixes/additions.
Yet crashes when accessing files though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35647 a95241bf-73f2-0310-859d-f6bbb57e9c96
it is fully initialized.
* arch_vm_translation_map_is_kernel_page_accessible(): Check whether
sPhysicalPageMapper has already been initialized.
If a panic() during or before the initialization of the physical page mapper
occurred, we no longer access a partially initialized object or a NULL pointer.
This should fix the triple fault part of #1925.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35644 a95241bf-73f2-0310-859d-f6bbb57e9c96
