Activating all these packages on live boot (especially live DVD where we
also have the write overlay eating up RAM) significantly increases
memory requirements for running Haiku, to the point that Installer may
fail to run. Move them outside the packages/ directory so they are not
activated.
Installer already skips the _sources_ directory when installing, and
lists the contents of _packages_ with checkbox to decide what to include
in the install (they are put in system/packages on the target disk).
Fixes#15621.
Change-Id: Ibfac14c43dbe708316a0d82ca1c9d49b5cba2aef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2157
Reviewed-by: Sergei Reznikov <diver@gelios.net>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I23db3cbb57fea1f9346db9477f72bcc164794926
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2282
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This is the bulk of the work. Anything else should be
minor cleanups and tweaking.
* riscv64 isn't a viable EFI platform yet.. just acting
as a stand-in to test a non-x86 EFI haiku_loader
Change-Id: Ib03de81e2b562e693987b86d7b4318209fb1c792
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2256
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: Idc50cfee16db5f7c0dbea625a7739ad42b2d7bf0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2249
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* "xorriso doesn't support much of the mkisofs options"
* Dropping the hfs map made our bootloader no-longer get
mapped as :tbxi which means qemu + Apple devices refused
to boot it.
* Switch to genisoimage which can generate the correct image.
(xorriso -as genisoimage doesn't work either)
Change-Id: Id71b97796f5004f6ddf6244644c51a5787f9bf8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2241
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
And remove Mouse, Keyboard and Touchpad.
Userguide and localizations will need to be updated.
Change-Id: I4543b2b63367cd13562c542610bad34b5934b103
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2210
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ie043af5b7471f626a1ffe100848151c832dcc439
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1853
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Needed for the sparc port, allows to build elf2aout which uses err() and
errx(). Allows to build the sparc port from Haiku.
Change-Id: Ia14dd9b1be1c03b36634a675f1a51eeac8d4aacf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2129
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Factor in types changes (introduction of intptr_t)
- Align JamFiles syntax with in progress architectures (arm/sparc)
- Xorriso doesn't support much of the mkisofs options (anymore ?)
- (After a correct bootstrap) one should be able to build @minimum-raw and haiku-boot-cd again
Change-Id: I4f779ad8f2210389fa9b7f7c0a98c3652a64c257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1983
Reviewed-by: François Revol <revol@free.fr>
* Add a link to the Quick Tour to the desktop.
* Remove the Welcome page from desktop. We don't want to clutter
the user's desktop more than necessary. As "Home" page of
WebPositive, it's still very visible.
* Mention the Quick Tour in the Welcome package description.
* Add a "quicktour" script similar to the welcome/userguide
that opens the online version if it's not installed locally.
* Add icons to the userguide and quicktour scripts. Fixes#14706.
* Add bookmark and launcher for the Quick Tour.
Adjust the AddFileDataAttributeRule to create its temporary file in
the "common" architecture, the file is not architecture specific.
Add a rule PrepareScriptWithIcon in src/data/bin/Jamfile to assign
an icon and make the script executable.
Change-Id: Ia7604ff4715a5aaf9a645c1b3333a954d6a4dafc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1924
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
So many Jamfiles to search through...runs also, but there
are lots of graphical glitches
Change-Id: Ibf9e64566a5b8c5742792ac9b1b0f9ccc6693c8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1753
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The "exec" tool can only handle one command with environs set at
the beginning of the line, so now we set the ADD_BUILD_COMPAT...
in this format. This also seems to be a general performance
improvement to builds using real shells, too.
Change-Id: If4b3117651b5475039d5e8116cd3de398582290a
Change-Id: I8084e0fa2ffbaf04242fa14617807d83abbd5586
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1556
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This makes pkgman functional in minimum-profile images.
Change-Id: I3578886743fecbf76779ac1b4b76762d8ce1be3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1715
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Now provided in the tnftp package.
Change-Id: I862b1ff98586aa0e5a9418cf26e30b7136140249
Reviewed-on: https://review.haiku-os.org/c/1641
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: If11a892665d08f61c46b5a6a5b4bf0453225c3ee
Reviewed-on: https://review.haiku-os.org/c/1533
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* haiku_loader.u-boot doesn't fit in fat32 like haiku_loader.ub
* Adjust when writing. Update u-boot scripts to expect new filename
* Shrink loader partition to 32M, add our filesystem to end
Change-Id: I62936526a7dea2c41e26a7c0f9e05a368622a6a3
* For tracking, there are *mega* hacked together using
llvm's linker and functionality isn't a sure thing.
* Thanks waddlesplash for the sketchy changes :-)
* Hopefully gets non-bootstrap arm builds working again
and let us work on the toolchain without blocking arm
development.
Change-Id: I0617ed83cc757d098e6464222405f75eed91196e
I am using this to use clang+lld for linking on ARM builds,
which seems to be more tolerant than binutils ld is, and
gets the build a bit farther for now.
We always want to use the shared one from the syslibs package,
never the shared one from this build.
Part of #14842: after this change, the ICU build now fails with
"cannot find libstdc++" instead of an invalid symbol.
* After the gcc 8 upgrade, during bootstrap sources attempt to
load limits.h from gcc before they use our limits.h override
resulting in undefined NAME_MAX, PATH_MAX, etc.
Change-Id: I9204410d0543a033e262124eaf7bcde09db26aa9
Reviewed-on: https://review.haiku-os.org/c/1498
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
It warns on snprintf's output "possibly" being truncated (e.g.,
two B_PATH_NAME_LENGTH chars being concatenated together) which may
be exactly the behavior the programmer wanted. So that's not very
helpful.
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
Just does what the name says
Change-Id: I6cf23f997ce544df83d4ef2f73a3b130dea8825c
Reviewed-on: https://review.haiku-os.org/c/1432
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Very simple for now, just reuses the Haiku one with some gradients
removed.
Add it to the haiku_extras package.
Change-Id: I41729ed65b147fed72bf56e7c5c89367b75563bb
Reviewed-on: https://review.haiku-os.org/c/1431
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The variable is used after a "cd" so it must be absolute.
Change-Id: I8d591b8642179603249ac56a1fcac082f29c870c
Reviewed-on: https://review.haiku-os.org/c/1387
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* I added this early on, but to be honest, any interesting
workstation class hardware would be riscv64.
* Since riscv32 is mostly embedded or low power, just drop.
Change-Id: Id36274c882c46e766268f2ab53eb1bd5f95227be
Reviewed-on: https://review.haiku-os.org/c/1352
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
By default, all targets support the "haiku" platform, and we no longer
support building for BeOS, Dan0, Zeta, or other BeOS-compatible targets,
so this is no longer needed.
Also remove all references to the non-Haiku compatible platforms, and
change all BEOS_COMPATIBLE checks to HAIKU_COMPATIBLE. Removal of
all SetSubDirSupportedPlatformsBeOSCompatible invocations
will be in the next commit.
This one had an uncertain "freeware" license, and the code quality
is not so great. BeOS didn't have an 'uptime' command, so we can
replace this with the coreutils one without worry.
Change-Id: I7aef31e72a826936c45e3644a72eb0598386f1ae
Reviewed-on: https://review.haiku-os.org/c/1309
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: Ia2a86d8814d06950ea2d2d19d966c642d26f81d6
Reviewed-on: https://review.haiku-os.org/c/1302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
On x86 and x86_64, this warning is never emitted because it is perfectly
fine to do unaligned access. On sparc, such accesses are not supported
by the hardware and will generate a SIGBUS. This must be caught by a
trap handler, and the unaligned access performed there, slowly, using
byte by byte access.
However, making this a Werror is annoying because it will trigger
everytime one casts a byte pointer to something larger, even when
alignment is actually preserved. So, removing all such warnings would be
nearly impossible (for example, just for the mergesort function, there
is a whole GSoC project for it at FreeBSD).
Keep it as a warning for now. The warning can be silenced by using
BytePointer, if desired. We should also investigate where the SIGBUS
trap is triggered a lot and consider improving the alignment of data
where possible.
Change-Id: I6b90025e8c6d69ef1ccda3c10eee270ccc1ebd29
Reviewed-on: https://review.haiku-os.org/c/1103
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some operating systems only ship with Python 3 and the
binary for this is 'python3' instead of 'python' which
causes the Jam build process to fail because it expects
to find 'python'. This change will mean that the
configure process will detect this case and configure
the build to use the correct binary name.
Fixes#14938
Change-Id: I30cd0df828792715a54d760b86dd79aee04e2b2f
Reviewed-on: https://review.haiku-os.org/c/1134
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Use the latest version of the compiler for bootstrap.
Change-Id: I43639b560de2d4f3dc3fed48c3d4bd32a544cb57
Reviewed-on: https://review.haiku-os.org/c/1104
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This went through review too fast, the wrong variable name was used so
the package name was not listed...
Change-Id: I81d4aa57fdb65297ae9f63ebf123d7a6395a99b6
Reviewed-on: https://review.haiku-os.org/c/1109
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There seems to be a problem with the way we set the gcc_bootstrap
package build to depend on the bootstrap package with haiku headers.
If said package cannot be built (for example some definitions are
missing for a new architecture), we end up passing an empty string as
the package to use to haikuporter.
The error message given by Haikuporter is confusing, and not easy to
investigate. So, intercept the error earlier to save time for the next
person to hit this problem.
Change-Id: I64f326e5cb3bb0d44632864ad38ad10bb88d0c7b
Reviewed-on: https://review.haiku-os.org/c/1082
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It warns when you try to use some standard library functions
without including the system headers, which we don't
care about as we are providing the system headers in the tree.
This just stops the errors from occuring rather than trying to
rebuild the files at all. This is much cleaner, and solves
a few cases that the other method did not.
Let's make the nightly builds consistent in a way that they would always
be recognized by libosinfo (and, consequently, by GNOME Boxes,
virt-manager, virt-install, ...) by explictly using "nightly" instead
of the $(HAIKU_VERSION) when generating nightly builds.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Change-Id: I6fc4f15be1e8e9244abf14e75308fc825f37b2e8
Reviewed-on: https://review.haiku-os.org/c/1053
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The current volume-id is "bootimg", does not matter which version of
haiku nor to which architecture the ISO is targetting.
Having a "too generic" name as volume-id directly affects the ISO's
recognition by libosinfo.
From now on, let's use:
haiku-$(HAIKU_VERSION)-$(TARGET_ARCH)
Which would generate an ISO with volume-id as:
Volume id: haiku-default-r1~beta1-x86_64
Fixes: #14695
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Change-Id: I25e2f5338403058a363872abd196d698764cc3c1
Reviewed-on: https://review.haiku-os.org/c/1034
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Our implementation of it now behaves properly after the last commit.
Change-Id: I6bebc91ae0f9512ea07ad6a7a4ccea9ee758e01b
Reviewed-on: https://review.haiku-os.org/c/908
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It has been unused since 2010, when the usb_port printer transport
was rewritten to use the USBKit.
Change-Id: I224e07fb35cd9696c07b8f22dd51d3c67d92e0a9
Reviewed-on: https://review.haiku-os.org/c/869
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Now that HAIKU_TOP is a relative path, nearly all paths Jam actually
has to deal with will never contain spaces, so this is now feasible.
Only one issue remains after this commit (namely, setting
HOST_BUILD_COMPATIBILITY_LIB_DIR.)
As Jam prints the entire erring command on failure, including this if-test
in the command itself makes the output somewhat difficult to decipher.
So instead we use two separate rules based on whether or not NO_DOWNLOADS
is set or not.
We don't include the wpa_supplicant on the minimum image, so
these aren't very useful (it seems one needs the wpa_supplicant
to connect even to an unsecured network, with our setup.)
Anyone who needs one of these and also has a reason to use the
minimum image can easily add them back via their UserBuildConfig.
It seems that not all Linux distributions ship an EFI-enabled
cdrtools (i.e. mkisofs takes -e option), Arch being one that
does not.
So instead, we now use xorriso universally, which is
as (or more, in most cases) widely available, and supports
emulating mkisofs with the EFI commands universally.
This also has the added benefit that we can drop genisoimage
support altogether.
FreeBSD 12's net80211 layer contains only 2 small KPI breaks from FreeBSD 11,
so we can upgrade it, apply those 2 changes to the drivers which are affected
(as the changes are in some lesser-used functions), and then upgrade all drivers
one at a time.
FreeBSD 12 has no major changes to the ifnet KPIs that constitute a
source compatibility break, save a single one related to locking
which doesn't really apply to us, and so we don't need to create
a "freebsd12_network" directory to work through the upgrades.
This replaces the old Haiku-native driver that was removed in the last commit.
It should support all the same chips that one did, in addition to the SiS 7014,
and the DP83815 also.
I don't have this hardware, so for anyone who does, please test.
Fixes#1657.
- USB pen drive seems to still work. More extensive testing welcome.
- USB floppies don't work yet, but they don't work anymore with the
current driver, either. I'm still investigating that part.
Fixes#9276
Change-Id: I8aa5ab828ad2ad867d0c187062d6e179372fc2ad
Reviewed-on: https://review.haiku-os.org/747
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In some LTO-related experiments, it came out empty due to GCC
not generating actual assembly but rather intermediate code,
resulting in various later targets failing with quite literally
thousands of errors.
I added this here so that one could set -Wextra in BuildConfig and
not be bombarded with useless warnings; but it seems that GCC2 chokes
on it instead of ignoring it. Oh well.
This doesn't fully work yet (the FS code in libroot_build
needs to be adapted, as some of the symlink-related calls
are not available on MinGW), but it gets much further than
the "Cygwin" target did.
These have been broken for a long time. Some Cygwin changes that
are relevant on MinGW are kept here, but users on Windows who
want to build Haiku should probably use WSL at this point.
However, now that we are using relative paths and don't need
to worry about drive path kludges, it's actually possible to
get some host tools built on MinGW. Changes for that coming.
We need to force -m32 here, and we also need to tell Clang that we
want to allow relocations in .text.
Clang builds now get to kernel entry, but the bootloader fails to
load the early-boot modules with strange remapping errors, and so
panics with "get boot partitions failed!"
