* Reorganize things a bit:
- BSolver is now an abstract base class.
- A libsolv based implementation, LibsolvSolver, lives in a new
add-on, which is loaded lazily.
- Get rid of libpackage_solver. Save for LibsolvSolver everything
is moved to libpackage.
- This is a nicer solution for the cyclic dependency caused by
libsolv (libsolvext to be precise) using the package kit for
reading repositories and package files.
* Add a solver result data structure and and an accessor the solver.
* Add problem reporting support to the solver. There aren't data
structures for the problem solutions yet and support for selecting
solutions and re-solving is missing as well.
* The call to the dummy actions isn't needed
* The calls to Extract{Zip,Tar,HPKG}Archive1 couldn't work like that.
The directory has to be the main target, since ExtractArchive is
potentially invoked multiple times with different extracted file
targets and the Extract*Archive1 is only invoked the first time.
Tested only with the HPKG actions, but they others should work as
well.
* Updated to version 2.0 of vendor code.
* Reliability improvements in controlling the underlying devices.
* Implement leaving networks.
* Better timeout handling.
* Usability enhancements like cancel on escape, ok button being the
default and the password field having focus on start.
* Storing of the password using BKeyStore.
It is now declared with architecture x86_gcc2, though it probably
has been built with gcc4. That issue has to be solved for real
eventually, since the package resolver won't allow mixing of gcc2
and gcc4 packages.
It's sufficient to simply check if the gcc version is 4 or higher since
we enforce the use of the latest ported compiler for the build anyways,
and these multi-level checks would fail in their current state if gcc
moved to e.g. version 5.0.
Added the optional package for system sounds that
were collected for GCI 2012. Also added the demo
packges to the "contents" at the top of OptionalPackages.
* Tried to use EFI::Header class, but there doesn't seem to be an easy
way to actually hit the disk -- which we'll have to do to find out
how large the GPT table is.
* Initialization of GPT disks is now working which is why I added the disk
system add-on to the image. However, there is a caveat, as the backup
header and table aren't written yet.
* Partitions can be deleted.
* Creating partitions does not work yet, but I don't know yet why; in
theory it could already work.
..and Haiku64Image. While I'm at it split the commands so each letter
in the alphabet gets it's own line(s). This will make these kinds of
changes more atomic in the future.
* Version of Vim package for x86_64 added;
* Version of KeymapSwitcher package for x86_64 added;
* KeymapSwitcher package fixed to preserve Cmd <-> Ctrl swap settings on
keymaps switch. Fixes#9142;
* UnRAR updated from 3.7.8 to 4.2.4, fixed for multibyte characters
support and build for x86_64. Partially fixes#4879;
If no hrev tags are found the revision is blank and shows up as
0 in About System. This commit updates the revision function so that
it falls back to the current short hash instead. Only affects devel
builds and only if you've deleted your tags.
* Try to keep each renderer designed
the same.
* swrast will build... swpipe won't
build until we have an llvm build
package. (should in a few days once
llvm 3.2 is released)
* libmesa and libgallium no longer live in libGL
* opengl kit gets libglapi for dispatch
* swrast will get libmesa
* swpipe will get libmesagallium + gallium drivers + llvm
Work I did at Begeistert, trying to use the new driver manager and
detecting display controls. It should probably be a good example of
how a new driver is built. It currently loads and detects
display controls correctly but doesn't do any actual work yet.
Not sure when I have the time to finish the driver, it shouldn't be
that hard but I currently have have other priorities. Feel free to
work on it in the meantime.
Got rid of X86_ONLY and friends in HaikuImage, FloppyBootImage, etc.
Instead we use build feature specification annotated lists with
FFilterByBuildFeatures (either explicitly or implicitly where passing
the list directly to the image rules).
I just translated the variables to the respective annotatation in most
cases, though in some cases different annotation would be more correct
(e.g. for the OpenGL stuff).
Provides a simple framework for addressing #3798. The interested reader
may add the build features and add/adjust the annotations accordingly.
An archive (ramfs) to be loaded can be specified in the raspberry pi
config.txt with a certain base address. We can use this to put our
floppy boot archive into memory on startup.
During the start procedure we now map that archive so we can later
load the kernel from it.
* As of Mesa3D 9.0+, GLU is a seperate project
* Our in-tree GLUT builds with GLU-9.0 without
modification.
* We ignore the GLU libraries that Mesa-7.8.2 and
Mesa-8.1-devel provide and use the glu-9.0 ones
* This is kind of a limbo state, but works for now.
* Eventually we will be on Mesa 9.0 (which requires
the external GLU) and Mesa 7.8.2 (which works with
the newer external GLU) and will rip GLU out of the
7.8.2 OptionalBuildPackage.
* I don't *think* we are using the Mesa GLU headers...
we will know for sure when I pull'em out of the
OptionalBuildPackages :D
Currently hardcoded to Verdex target. Code prepared to pick up configuration
details from FDT when implemented. Only enabled in FloppyImage for ARM.
This actually enables the kernel to read the content of the image file
passed using the "-pflash" parameter to QEMU....
* Fixed issue with unwanted keymap switching in case UnZip started in
* background (expanding optional packages during Haiku build, for
* example). UnZip executable has no background application flag
* for unknown reason.
+alpha4
Introduce HAIKU_DOWNLOAD_CACHE variable that can point to a directory.
containing optional packages to check first before downloading.
Missing packages are also added to the cache.
This allows sharing and reusing them to make builds without a connection.
* Puri wouldn't work after the update to libpng 1.5
* It was still looking for libpng.so.1.4
* Not intended for r1alpha4 branch, as it's still on libpng 1.4
* These were updated again due to recent changes to the buildtools
* Packages are based on btrev43045, whereas the previous set was based on btrev43040
+alpha 4 (GCC2 package needed to match recent date versioning change to configure script)
* This package is current as of btrev43040
* Primarily did this rebuild to assure the GCC4 package was made with the latest buildtool sources
* This invalidates the need to cherry pick hrev44704 for R1A4
+alpha4
* This package is smaller in size than the previous due to the fix in btrev43038
* This package addresses issue building code with SSP due to fix in btrev43039
* This commit along with btrev43039 fixes#8931
+alpha4 (and hopefully last update to GCC before R1A4 release)
Setting 'HAIKU_STRIP_DEBUG_FROM_OPTIONAL_PACKAGES = 1' will enable the
mechanism. By default all packages will be stripped. Passing anything
other than '1' or 'true' in the InstallOptionalHaikuImagePackage call
will disable it for a particular package.
* added optional feature package for libpng 1.5.12 gcc4/gcc2 x86 and ppc
* drop libpng sources and headers from the tree.
* added optional feature package for jpeg 8d gcc4/gcc2 x86 and ppc
* drop jpeg sources and headers from the tree.
The original package was cross-compiled to Haiku, turns out flex's
build system uses paths to stuff from the host system, so the package
was broken. Rebuilt from Haiku.
Added autoconf, automake, libtool, texinfo, perl, gettext and nano.
Building an image with the nightly targets should give you an image
with these included.
