Antora uses a dedicated folder structure which we need to adhere to for
it to work as it should. Makefiles has moved to `doc/` root to simplify
the approach needed with Antora and AsciiDoctor.
Existing bundling of documentation with help of AsciiDoctor works as
normal and does not interfere with the directory change.
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
The bridge, and also some parts of pkg/lib/ are GPL-3.0-and-later
licensed, not LGPL-2.1. At some point we should clean this up, but for
now accept the status quo and ship the GPL 3 text.
The four patternfly react-templates copies in pkg/lib are MIT licensed.
Rename/add them to "LICENSES/<spdx>.txt" as recommended by
https://reuse.software/spec-2.0/
Note: pkg/storaged/icons/gnome-icons.jsx is CC-BY-SA-3.0 licensed (or
LGPL-3.0). This does not have a canonical plaintext format, just the
webpage. So don't copy that, retaining the current license header in
that file is good enough.
Adjust the .spec accordingly.
There's an awful lot of code in `src/common` and `src/websocket` which
is used only by `cockpit-ws`. Move all of those files (and the tests
for them) into `src/ws`.
Assisted-by: Claude <noreply@anthropic.com>
When we build images we get a warning like:
/bin/sh: line 2: @echo: command not found
from the expansion of `$(AM_V_GEN)` in the `tools/debian/copyright`
rule. This expansion can contain a `@` in front of it but that's only
valid at the start of a Makefile command, not in the middle of a
shellscript. Move it out front to fix it, dropping the `@` that was
there (which means that we'll now correctly see the command when we run
with `V=1`).
We want NODE_CACHE to be a built file in the build dir. So declare that
properly and use it at face value, instead of mangling the path in the
`node-modules runtime-tar` output argument.
This fixes tools/make-dist if the project root already contains the
tarballs. That happens when a previous `packit propose-downstream`
already ran and moved the tarballs to the project root.
Fixes#22675
Now that we ship the node modules tarball as part of the source, we need
to document its copyrights and licenses. Update
tools/build-debian-copyright to the version in cockpit-{files,podman}
(we can drop their copies and import from cockpit afterwards), and
adjust the copyright template accordingly: add missing licenses and
update the comment about `dist/`.
The next commit we will require the `node-modules runtime-tar` tarball
for building the debian/copyright file. Similarly to what
cockpit-{podman,files} already do, change `make dist` to produce the
node tarball as well, instead of making this a separate action.
In tools/release, wrap the two generated tarballs into an outer `tar` so
that we can squeeze both through the build container's stdout.
Our package.json's `dependencies` has transitive/optional dependencies
which don't actually end up in the bundle, e.g. `argparse`,
`attr-accept`, or `js-tokens`; or `react-dropzone` which is a
`@patternfly/react-table` dependency, but not actually used in
cockpit.
The next commit will aggravate this further.
So make the computation of the `Provides: bundled(npm(..))` lines more
precise: Ask esbuild about which modules it actually included, which it
tells us via the "metafile". Change build.js to always output that (drop
the `--metafile` option), compute a ./runtime-npm-modules.txt list, and
use that to build the spec file.
Ported from https://github.com/cockpit-project/cockpit-files/commit/e15a518fddad1
It conceptually fits better there, as it's shared by all external
projects. That makes importing easier as it doesn't have to be
enumerated separately in COCKPIT_REPO_FILES any more.
Nothing is using this code anymore. All that's left in this directory
are a few test resources: we'll deal with those in the next commit.
Clean up a few stray references in the build system and packaging: in
paticular, remove --enable flags for both PCP and PolKit.
Nothing uses this any more, superseded by cockpit-beiboot. This gets rid
of the libssh build dependency.
Drop the `Provides: cockpit-ssh` from Debian. No package ever related to
that virtual package name, and it's meaningless these days.
It's not necessary any more for running integration tests.
Running the browser unit tests isn't supported from release tarballs
anyway as we don't ship the pre-built quint tests.
This isn't supported on the main branch any more since we dropped
supprot for RHEL 8. This was already cleaned up in the spec file and
tests. `HACK_SPEC_FOR_PYTHON` is also not a thing any more.
Also clean up the four ws tests which we haven't run any more since
then.
Much of src/bridge can also go now, but we'll leave that for #20000. As
automake requires a defined conditional for `if`, define an always-false
`WITH_OLD_BRIDGE` for now.
The Python bridge is now default enabled in 14c07d7087 and
this also removed cockpit_enable_python in favour of explicitly enabling
the old bridge. As RHEL 8 ships the old bridge by default we need to
toggle this for the pybridge scenario.
Replace --enable-pybridge with --enable-old-bridge, and flip the logic.
That way, it will slowly disappear as old distro releases become
unsupported. This also means that builders from upstream now get the
Python bridge by default.
The distcheck scenarios now apply to the Python bridge. Add a
`$DEB_PYTHON_INSTALL_LAYOUT` hack to work around
https://bugs.debian.org/1035546 to unbreak the installation of the
generated wrapper binaries, as by default they'd go into
prefix/usr/local/bin on Debian.
Add a new distcheck scenario for the C bridge, to ensure that we don't
break that.
https://issues.redhat.com/browse/COCKPIT-1037
Drop our dependency on setuptools and write our own PEP 517 build
backend. This turns out to be relatively straightforward — only ~100
lines, and avoids the workarounds we had to do to prevent setuptools
from trying to write to the source tree. It's also dramatically
faster.
While we're at it, we can now fix a long-standing nag: we now have a
proper place to make sure that `modules/checkout` gets called before
building an sdist or a wheel. That means that you can run `tox` or `pip
install .` in a freshly checked-out tree and expect correct results.
We have to add a command-line interface to support wheel creation on
RHEL8, where pip is not yet PEP517-aware.
We don't implement any optional features of PEP 517 and we also don't
support editable installs.
Instead of building and injecting a wheel after-the-fact, add a tiny
little hook to our `make dist` which tweaks the specfile to enable the
Python bridge by default.
This is some pretty ugly stuff, but it avoids us having to invent a way
to smuggle -D options into image-customize and also avoids having to
patch the spec file in the tarball after building it.
Tweak some tests, mostly to adjust to cockpit-bridge moving from
/usr/local/bin to /usr/bin.
Add `tools/dist-setuptools`: a new command to copy all of the source
files that setuptools would include in its sdist to a different
directory. We use that during `make dist` to make sure those files end
up in the primary automake dist tarball. This lets the Python build
system decide what gets included.
We also take the chance to tweak the version number in `_version.py` in
the distdir to be equal to the version number of the main package.
Note: our first attempts here involved building and unpacking an sdist
but that failed because setuptools tries to write to the source
directory, which automake (particularly, `make distcheck`) dislikes.
Finally, we have to adjust our debian packaging a bit to suppress a
false-positive lintian warning.
`FORCE` is also a dependency of the `version.m4` target in the top-level
Makefile.am, so it's confusing to only define it in the pkg/
subdirectory. Now it's only used in the top-level Makefile.am.
`package-lock.json` is also a dependeny of po/Makefile.am, so it should
also be shared and move to the top-level file. Consistently refer to it via
`$(srcdir).
`node_modules/*` also only gets referred to in the top-level Makefile.am
for the EXTRA_DIST of the integration test dependencies. Move it next to
that.
This gives a massive speedup compared to building them individually, as
parsing/compiling `node_modules/` takes by far the most time:
`node_modules/.bin/webpack` is able to build the whole dist/ in 2
minutes (production with terser), instead of 27 linear minutes, or ~ 4
minutes with 8 parallel processes.
It's even faster in development mode without linters, then it just takes
about 40s.
`make` will now rebuild the whole dist/ if anything in pkg/ changes --
the same approach that starter-kit and friends have used for years. That
is already faster for a full "make dist" or jumpstart CI build. It is
slower for incremental builds, but (1) the documented and recommended
way to do that is with tools/webpack-watch and just building a single
page; and (2) it will not matter any more once we switch to esbuild.
We keep tools/webpack-{make.js,watch} for the time being. They are now a
rather shallow wrapper around invoking webpack, which we can simplify
further -- but that will require changing our habits and the
documentation, let's keep this for a follow-up.
This also paves the way for esbuild, as we don't have a mechanism to
generate Makefile.deps there.
Automatically checking all of the tags in order to construct our version
history has always been a bit gross. It means that what lands in the
release tarball is determined by more than just the current commit.
On top of that, the script to do this nasty bit of work just produced an
output which failed to validate, owing to the recent out-of-sequence
release of 264.2.
Version history really ought to be tracked downstream, so let's rip all
of this out and replace it with a very simple approach to writing a
single release line into the file. This is the minimum required for the
file to validate. Any additional history can be handled downstream
(manually, for the time being).
Using `$HTML_LOG_FLAGS` to inject valgrind is conceptually brittle, as
it's not clear where exactly that gets shoved into the command line.
At least Fedora 35's and Debian stable's automake versions (1.16.2 and
.3) generate the test command with
HTML_LOG_COMPILE = $(HTML_LOG_COMPILER) $(AM_HTML_LOG_FLAGS) $(HTML_LOG_FLAGS)
which makes sense in general, but produces a command like
tap-cdp ./test-server valgrind /source/dist/base1/test-user.html
This makes no sense: valgrind immediately exits with "no program
specified" and tests just hang. What we want is to run test-server
under valgrind.
It's not actually clear how this ever worked. Let's make the CLI
ordering explicit: Stop using `$HTML_LOG_FLAGS` and use our own
`$HTML_TEST_WRAPPER` variable, and inject it into the correct position
between tap-cdp and test-server.
Change `$VALGRIND_ARGS` to `$VALGRIND` and include the actual valgrind
program, so that the whole wrapper is self-contained. With that, we can
potentially run test-server under other tracers.
Add support for creating cockpit-bridge.pyz as a zipapp, containing the
Python bridge, systemd_ctypes, plus a full set of packages from dist/.
Add a target `make pycheck` to run the QUnit tests against this new
bridge package.
*.po files are already validated by the po-refresh bot, there is no need
to do that again.
Move the AppStream data validation directly into the Makefile, to avoid
a separate shell script with just a single line. This also reduces
confusion with the *other* check-dist script that we have in test/.
Keep `Version: 0` in the spec file. This works fine with `autogen rpm`, `dnf
builddep, and Packit. It was the last macro, so now it's a real working .spec.
This avoids having to invoke this script all the time.
This simplifies our packit config a bit and stops swimming against the stream.
The only place where we want a real version is `make dist`, so that built RPMs
have a correct version. Rework the rule to modify the file in-place in distdir.
Unfortunately this uncovers another packit bug: If the .spec file is not
in the same directory as the tarball, `packit srpm` gets upset:
<https://github.com/packit/packit/issues/1621>. Work around that by
copying the spec to the root directory, and pointing to it.
The logic is broken for builddir != srcdir builds, since it doesn't
include $(srcdir). It's also a bit silly to explicitly list all of the
files when we can easily do it with `$(wildcard)`.
Switch to `$(wildcard)`, include `$(srcdir)` and inline the whole thing.
If we're building a dist from a tarball release, the script won't be
present, but that's OK: we already have the release info in the .xml
file in that case.
Currently, we choose the version number that we use at the time that
./autogen.sh is first run. That means that if you configure your tree
and hack on it for a while, making commits as you go, the
overly-specific version number will soon be out of date. This version
number is the number used when building tarballs for testing. Even
switching to old branches on previous versions can result in the version
number not being updated.
Let's move to automake's suggested approach[1] to dynamic versioning by
introducing a `version.m4` file. We write that file from two places:
- `./autogen.sh` writes an approximate version number (the last release)
appended by +git (eg. "270+git")
- from `make dist` we write the value we find in `$(VERSION)` and call
autoreconf to update the configure script accordingly
The expectation is now that anyone who calls `make dist` should specify
the VERSION explicitly. That's two places:
- from `tools/make-dist` we specify the full `git describe` style
version
- from the release workflow we specify the tag name
Since the only thing that uses `make dump-dist` anymore is
`tools/make-dist`, and since it now provides its own version number, we
can drop the rule and print the filename directly.
Since we move to `version.m4`-style versioning, our tarballs will no
longer contain the `.tarball` file.
Finally, since we're going to end up having more tarballs created, with
various version numbers, add `cockpit-*.tar.xz` to `CLEANFILES` to help
keep things under control.
[1] https://www.gnu.org/software/automake/manual/html_node/Rebuilding.html
Move all of our packaging-related files that we create at `make dist`
out of `dist-hook` and into their own rules, with nice `$(AM_V_GEN)`
output.
Turn `dist-hook` into a pure list of dependencies on those files.
Move the remaining rules into the main `distdir` target, which we were
already overriding anyway. These will be dealt with in following
commits.
This code contains hard-to-fix bugs and doesn't really get us much: the
extra output it produces actually makes the `make check` output harder
to read.
Let's just rely on the `test-suite.log` output on failure, and use the
default automake driver instead.
Fixes#17307
This causes the test-suite.log to be output at the end of the parallel
test run, if any test failed. That log file contains only the failing
tests, which makes it easier to find out exactly what went wrong.
We can remove code from two unit-tests container scenarios that was
basically doing exactly this.
Create a tool to turn the point form notes in our tags into a proper set
of <release/> tags for metainfo and fill this information in when
building a tarball.
Install the metainfo if building with --enable-client. Validate it
at install time as part of building the flatpak — since we no longer
handle it separately, it's more difficult to do that from the outside
now.
Strip the old metainfo handling out of the containers/flatpak scripts.
Add a nice automake-style output for generating the manifest .yml.
This will simplify the process of releasing the flatpak.
The version of Python we have on the GitHub `ubuntu-latest` runner is
lacking the `indent` function in ElementTree, so add a hack to disable
it. We do it this way to make it easier to back this out in the future.
Run tools/make-compile-commands on build, and re-run it in response to
Makefile changes.
We might also consider to create this as a result of running
./configure, but let's keep this simple for now.
Add automake "silent rules"-style messages for autogen and configure
invocations from tools/make-dist.
Add an output from disthook in Makefile.am for preparing the tarball.
