* Works a bit better with dark themes
* Has some interesting alternative design elements
* MIT licensed
Change-Id: I6cfd1d4d05016fb014d515d94cff3b8c8d0298b2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4508
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
On x86_64, the KERNEL_ARCH should really be "x86_64", but it was "x86"
as the architecture sources/headers directory is shared between 32 and 64 bit.
Should not be a functional change on any platform outside x86_64.
Some are still in-tree and need to be removed, but this takes care
of all recent Intel, Realtek, and also the old Ralink chips.
This cuts down the size of haiku.hpkg by close to 10MB.
Translators and media-plugins are the main source of dependencies in haiku.hpkg,
and thus the main source of packages being pulled into chroots, especially
HaikuPorter chroots. (FFmpeg pulls in a rather large array of sub-
dependencies, itself.) So, here we break all the translators into their
own sub-package.
For now, haiku.hpkg is declared to depend on haiku_datatranslators,
so that users will not suddenly update and have no translators.
In the future, this will be dropped.
Note that this is only done for the primary arch at present.
Secondary architecture translators remain in the main secondary package
for now.
Change-Id: Id0b352f34f7110b79ec7787792bf3ae0edab4054
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4477
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It has been since 2019. It seems to be added to images anyway,
probably because something else depends on it, but for correctness,
it belongs outside the REGULAR section.
This translator only supports still images for now, and supports both
decoding and encoding.
Encoding support has been tested only with aom, rav1e doesn’t build on
Haiku yet, see https://github.com/haikuports/haikuports/pull/5534 for
one of the missing dependencies.
Change-Id: I716f4b862ed316b89b227bfed38072d72074201f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3040
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The "update dependency versions" step automatically adds the requisite
versions to this file during the build based on whatever the build
system is actually using, so this is not necessary; and it seems
that some architectures besides GCC2 are still on a version of ICU
less than 66.
We do not actually need a SetupFeatureObjcetsDir here, as this build feature
is used unconditionally if it is available (unlike OpenSSL which is not,
and which needs a feature objects directory.) It appears FeatureObjectsDir
expects to be called unconditionally, i.e. in an "else" as well as "if",
so this actually caused some build oddities.
Additionally, since it is built unconditionally if available, we have
to put it outside the "regular" checks in the PackageInfo so that it
will be included in the images. This fixes booting @minimum images,
which was apparently broken at some point when "zstd" was inadvertently
removed.
* Merge all except the x86_gcc2 one into a single "generic" one.
It is now exactly the same on all architectures, save a single
ifdef for x86_64, which needs a different compat version, as there
are still some packages built that far back and never rebuilt since!
* Group the requires according to category: first any arch packages,
then commands, then the GCC syslibs, then packages always depended
upon if they are available, and finally packages only depended upon
in "regular" builds.
* Put all packages inside HAIKU_BUILD_FEATURE_* ifdef tests,
and order them alphabetically within their category.
If I have done this all correctly, at least x86_64 should get an
identically generated haiku .PackageInfo as before this commit, save
the reordering changes. Others may differ based on package availability,
as they were missing the requisite #ifdef sections.
- New text/markdown MIME type was added according to IANA registry.
- MIME types gained new extensions that weren't previously included.
- Resource definition files will now open up with Pe by default.
- text/x-vcard was renamed to text/vcard, as it's now a registered IANA MIME type.
- text/x-source-code had its sniffing rules increased in priority,
so that it would get precedence over text/plain and its own sniffing rules.
Change-Id: I28af24de8c0e96ef39dfc67703a0884e8d4c842e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4109
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This resolves the confusion about the "url" field in repository
definition files. However it changes the identifier of repositories. It
seems to be a good idea to do this with a new release, as users will
need to switch to new repos anyway and can accept special instructions
at that time (we will include the instructions in the release notes).
The new format uses a tag: uri as specified in https://tools.ietf.org/html/rfc4151
The rationale for this is:
- We need a way to uniquely identify repositories
- We want anyone to be able to create a repository easily, with no
central registration, and in a way that does not results in accidental
conflicts. We do not want to be running a registry to grant people an
identifier for their repository.
- Backwards compatibility with existing repositories and software should be
preserved: some code and file formats in Haiku package tools expect or
expected the identifier to be parsable as a BUrl. Existing 3rd-party
repositories use an http or https URL as an identifier and may
continue to do so (changing the identifier of existing repositories is
not desirable)
- Forwards compatibility if we want to change this again later
- Optional: repository identifiers should be user readable.
The tag: URI resolves this in the following way:
- Backwards compatibility: it is still an URI, as the identifier
previously was.
- Forward compatibility: We can change to another URI scheme if we want to.
In fact, each repository can decide what type of URI they want to use,
"tag" is only a recommendation and put in use for the repos we
provide.
- Uniqueness + no centralization: the tag: URI specifies namespaces tied
to a domain name (which is already needed to host a repository) and a
date at which the domain is owned by the entity generating a tag. Inside
that namespace, they can do as they wish.
- User readability: the format is simple and text-based.
Other possible alternatives are:
- keeping the current solution of using http URLs. It has proven
confusing because the repository hosting may be moved or mirrored
while preserving the identifier. There is also work in progress to
distribute packages using other protocols (eg. IPFS).
- Using an uuid. This provides unique, decentralized identifiers, but
is not user-readable. Backwards compatibility can be provided by
wrapping the uuid into an "urn:uuid:" URI (see
https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx).
- Using some other URI scheme such as "urn:oid:". I investigated some, but
found none that provide a decentralized namespacing solution (except
for "tag", of course).
- Using a custom URI scheme of our own. This would normally require declaring
it to the IANA (example: https://www.iana.org/assignments/uri-schemes/prov/apt
for Debian packages) in order to not make the internet more of a mess
than it already is. We would still need to define a way to generate
URIs that protects people from getting accidental conflicts. The
solution would probably be similar to what the "tag" URI scheme does, as
there doesn't seem to be many other ways to guarantee uniqueness in
(cyber)space and time without registration.
- Not using an URI scheme: in addition to the problems of a custom URI
scheme, this would break backwards compatibility (existing software
would not accept the new format) and forwards compatibility (without a
scheme in the identifier, it is hard to detect what it is supposed to
be if we change formats later on)
Change-Id: I970c23a546569994632c7bd570d11bdea95ba52e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4106
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Once change 2342 is in place (running first boot scripts exported from
packages), see https://review.haiku-os.org/c/haiku/+/2342,
remove data/system/boot/post_install/add_catalog_entry_attributes.sh
and related support infrastructure (magic files, launch_roster entries).
The work this script did can in fact be done at image creation time
instead of at first boot.
Change-Id: I485e1a0a87c3e6a6ba3f882e65996f2327134d37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3751
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Switch to Python3
- Switch to mawk instead of gawk
- Update ffmpeg (there are several new dependencies)
- Update ICU
- Fix various pre-existing problems with packages not being properly
declared for gcc2 (but somehow it ended up working)
- remove curl, subversion, mercurial
Confirmed that both nightly and release images are building fine on both
32 and 64bit. However, non-x86 architecture may require re-bootstrapping
to do a complete nightly or release image build (the minimal profile
should be fine)
Fixes #16751.
Change-Id: Iacac92923c4113b3e0a49a64b0b4cc1b8e2f5e2e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3871
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Point specifically to the SoftwareUpdater topic of the Haiku User Guide
to make the hint more useful.
Always use consistent spelling: "Haiku User Guide"
Translated the German User Guide package info.
Change-Id: I8f3b2a5a3f27caf9b5eea41a1a7a86c2e91e668a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3412
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
- libicule and libiculx do not exist anymore in newer ICU versions
(harfbuzz replaces them), but we didn't actually use them, so remove
them from the build feature and from the package dependencies
- Add namespace usage marcos since the newer ICU packages put ICU things
in a namespace, making it easier to have multiple versions of ICU used
side by side.
No functional change intended, but this makes it possible to build the
code with either ICU 57 (for gcc2) or 66 (for other architectures).
Some older repositories are having problems because
they are configured with a `url` (identifier) form
that is not actually a well-formed URL. This caused
problems when it was then interpreted as the
base-url because it did not start with "http". I
have changed this so that the base-url is not
derived from the url and can be missing.
Resolves #16149
Change-Id: I10acd8db65082ff6c72fcff1550eb63475e86133
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2931
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unfortunately this will rule out 15-samples MOD files, but it fixes #16035.
Change-Id: If3634c8ef4228ebe7ec5f8eac9f142ffff2ca30c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2703
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The way this rule works is it check two things:
- The document starts with "<?xml", "<svg", or "<DOCTYPE"
- In the first 512 bytes there is either an SVG or DOCTYPE SVG opening
tag (both casze insensitive)
This should allow to correctly detect most SVG files, all while not
misdetecting other things (for example xhtml with a nested SVG) too
easily. It's difficult to be completely accurate with just a sniffing
rule.
Change-Id: I66d6e21ff694c4a6349989db2685dffb44ef5767
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2681
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Depends on all the keymap files instead. If one is added, the header is
then re-generated.
Change-Id: I0adf37065d7c708e94c933a2044ceb56b1fd48fe
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2525
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The previous commits resulted in TOFU (black diagonal shape with
question mark in it). As per humdinger's suggestion and copying from how
€ sign was encoded, this is another try at fixing non-break space and
Turkish Lira Sign.
Previous PR: /c/haiku/+/2004/1
Change-Id: I3775c178b1921e7dff7ceb660c8fda1152050c94
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2148
Reviewed-by: humdinger <humdingerb@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Changed the keymap filename to match the ISO standard
Change-Id: I009640ed976f155cfba3925e852e543f03475bc7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2079
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
On Turkish F layout Shift+2 produces single quote, although it
should return double quotation mark. Probably this is a result
of an error whilst copying from Turkish Q layout.
Turkish Lira Symbol has been added to the both layouts,
produceable with ALT GR+T, as this is the standard combination
on Turkish layouts.
I've also noticed that most of the keys produce a whitespace with
the ALT+GR modifier, fixed that one as well.
This commit also adds non-breaking space to ALT GR+Space modifier
Change-Id: I9eb47ae70449c75b15b551f081f8767b1ab03cc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2004
Reviewed-by: John Scipione <jscipione@gmail.com>
* 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>
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
