vasilito
a399e7da08
Survey of the working tree found 83 tracked files
that no longer exist on disk (tracked-but-missing).
Most were inside source/ dirs (extraction differences
between git revisions) and are out of scope for this
commit. The 28 non-source tracked-but-missing files
fell into these categories:
1. Broken self-referential symlinks in driver and
tui recipes (5 files):
- local/recipes/drivers/ehcid/ehcid ->
../../local/recipes/drivers/ehcid (loops)
- local/recipes/drivers/ohcid/ohcid -> ...
- local/recipes/drivers/uhcid/uhcid -> ...
- local/recipes/drivers/usb-core/usb-core -> ...
- local/recipes/tui/mc/mc -> ...
These were created by the now-removed
apply-patches.sh symlink-overlay system. Per
AGENTS.md § 'NO OVERLAY-STYLE PATCHES', the
overlay pattern is retired. Recipes now use the
`path = 'source'` form in [source] blocks
pointing at the in-tree Red Bear fork. The
self-referential symlinks broke because the
overlay indirection was removed.
2. Broken absolute-path symlinks in gpu/driver
recipes (2 files):
- local/recipes/gpu/drivers/linux-kpi/source
-> /mnt/data/homes/kellito/Builds/rbos/...
- local/recipes/gpu/drivers/redox-driver-sys/source
-> /mnt/data/homes/kellito/Builds/rbos/...
These were committed on a different filesystem
layout. The actual source trees are in
`local/sources/{linux-kpi,redox-driver-sys}/`
and are loaded via `path = 'source'` config.
3. Tracked empty `~` (emacs backup) files in
autotools-generated source dirs (13 files).
Autotools regen produces `configure~`,
`config.h.in~`, etc. whenever a developer runs
`autoreconf` in the source dir. These are
ephemeral working files, not upstream source.
Re-running the cookbook's autoreconf will
regenerate them on the next fetch.
4. Tracked-but-missing upstream WIP recipes
(12 recipes, 596 files):
- recipes/wip/dev/build-system/{meson,ninja-build}
- recipes/wip/dev/other/{bison,flex}
- recipes/wip/libs/gnome/libepoxy
- recipes/wip/libs/other/m4
- recipes/wip/libs/qt/qt6/{qt6-sensors,
qt6-sensors-local}
- recipes/wip/wayland/qt6-wayland-smoke
- recipes/wip/x11/{libxau,libxcb,x11proto}
These were tracked in the upstream Redox WIP
area but the underlying dirs/files no longer
exist on disk (likely removed when upstream
WIP was reorganized). They were never
referenced by any `config/redbear-*.toml`
and have no surviving tree dependencies.
5. Top-level `gparted-git/` orphan (4 files):
A staging dir from a previous attempt to add a
gparted recipe (RBPKGBUILD + import/). The recipe
was never finished and the postmortem H-4 says
it was 'removed' but the dir persisted.
6. `recipes/gpu/drivers` tracked as a file blob
but working tree has it as a directory.
Tree conflict from a prior overlay layout.
.gitignore additions:
- `*\~` (emacs backup)
- `.*.swp`, `.*.swo` (vim swap)
These patterns prevent future accidental commits
of ephemeral editor / autotools-regen files.
Net effect: 617 files removed, 1,304,942 lines
deleted from tracked history, 0 lines added. The
working tree is now 0 tracked-but-missing files
outside of source/ dirs (source/ extraction
differences are out of scope for this commit).
This is the GNU gettext package. It is interesting for authors or
maintainers of other packages or programs which they want to see
internationalized. As one step the handling of messages in different
languages should be implemented. For this task GNU gettext provides
the needed tools and library functions.
It is also interesting for translators, because GNU gettext provides
the 'msgmerge' program, which prepares a message catalog before a
translation update.
Users of GNU packages should also install GNU gettext because some
other GNU packages will use the gettext program included in this
package to internationalize the messages given by shell scripts.
The homepage of this package is at
https://www.gnu.org/software/gettext/
The primary FTP site for its distribution is
https://ftp.gnu.org/pub/gnu/gettext/
Report bugs
- in the bug tracker at <https://savannah.gnu.org/projects/gettext>
- or by email to <bug-gettext@gnu.org>.
The configure script provides a non-standard option. It is also
available in other packages that use the functionality of GNU gettext.
Use
--disable-nls
if you absolutely don't want to have messages handling code. You will
always get the original messages (mostly English). You could consider
using NLS support even when you do not need other tongues. If you do
not install any messages catalogs or do not specify to use another but
the C locale you will not get translations.
The set of languages for which catalogs should be installed can also be
specified while configuring. Of course they must be available but the
intersection of these two sets are computed automatically. You could
once and for all define in your profile/cshrc the variable LINGUAS:
(Bourne Shell) LINGUAS="de fr nl"; export LINGUAS
(C Shell) setenv LINGUAS "de fr nl"
or specify it directly while configuring
env LINGUAS="de fr nl" ./configure
Consult the manual for more information on language names.
Other files you might look into:
COPYING - copying conditions
DEPENDENCIES - list of prerequisite packages, to be installed before this one
INSTALL - general compilation and installation rules
NEWS - major changes in the current version
THANKS - list of contributors
JOIN-GNU - invitation to join the GNU project