This allows packages to place files in data/profile.d to manipulate
the shell environment. They could already use settings/etc/profile.d,
but since there's no point in editing those files in most cases, placing
them there nonetheless doesn't make much sense.
We can't reliably set contemporary processors to an arbitrary frequency.
There are dependencies between cores and thechnologies like Turbo Boost
which may make actual frequency significantly different than the requested.
Moreover, it is the scheduler job to decide how much CPU performance is
needed and user shouldn't interfere with that.
Use findpaths to find the makefile-engine to include. This addresses the
remaining aspect of #10011. I.e. the package can now also be installed
in home.
A hpkg will be created locally, which contains the firmwares. This hpkg will
be copied to system. IIRC, the firmware must live in their respective
subdirectories.
To note, once the approve_license flags are implemented on the end-user
applicacation side, the Intel ipw2100 and Intel ipw2200 could be moved
to a separate package. However (and IIRC) the Broadcom involves using a closed
binary blob, that should not become a pre-made package.
README.iwlwifi-3945-ucode and LICENSE.iwlwifi-3945-ucode were mistakenly marked
as an executable. Was uncertain if iwlwifi-3945-2.ucode should or should not
be marked as an executable and was unchanged.
* find_directory() and hard-coded paths use /boot/system instead of
/boot/common.
* The build system creates the writable directories in /boot/system
instead of /boot/common.
* The build system no longer installs any packages in /boot/common.
* This was a script relying on a working /etc/profile, which may not be
there
* Instead, use GNU which, available as an haikuport recipe
* Since the command does not seem to be needed for Haiku to run (and
also because I don't know how to do it), GNU which isn't in the default
install.
* Typing "which" in a terminal still works, as that uses an alias
defined directly in /etc/profile.
Similar to stored queries, files of the virtual directory type behave
like directories -- i.e. they open in a list-mode Tracker window and
show up as an item with submenu in navigation menus. The file itself is
a plain text file in driver settings format. It can have an arbitrary
number of "directory" entries, which specify the paths of (actual)
directories for which the virtual directory provides a merged view. The
view will not show duplicate entries. For non-directory entries the
first one encountered (according to the order the directory paths are
specified in the file) will be shown. A subdirectory entry will again
behave like a virtual directory.
The support in Tracker isn't perfect yet. I'm afraid major refactoring
would be necessary to get it there.
The virtual directory file type uses a differently colored version of
the folder icon. Alternatives welcome.
* After examining MacOS toolbox roms, I think i've got
this nailed down. The MacOS Toolbox rom contains chrp
code at the top and binary code at the bottom.
* The Raw format for the chrp seemed to cause issues with the
OpenFirmware boot process on some systems. NetBSD uses a '-'
file type.
* The format of the chrp seems a lot more sensitive across machines
than described. Ensure our returns and spaces are even.
* Booting with the 'c' key is still working on my older OpenFirmware
machine with the chrp script. The bitmap logo is a half black, half
white box.
* I removed the &device; alias for now for troubleshooing. It also may
of been causing compatibility issues. More testing is needed.
