As part of a previous PR we dropped `py-asciidoc` completely in favor of
pre-bundling the documentation for distros where AsciiDoctor is not
available. At the time none of the code for building with `asciidoc` was
removed as I was unsure whether we'd need `py-asciidoc` or not.
With little reason to keep `py-asciidoc` as the maintenance burden to be
compatible with both `py-asciidoc` and `asciidoctor` is high, and it
making the integration with Antora more difficult, this commit drops all
code related to the Automake config and technical implmenetation
differences between the two.
This also drops the leveloffset helper as it was added as a way to
handle `py-asciidoc` and `asciidoctor` discrepancies when it comes to
going up and down the level offset for headings. Since we no longer use
AsciiDoc this is no longer relevant and can be dropped completely.
Related-to: https://github.com/cockpit-project/cockpit/pull/22693
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
Replace full LGPL/GPL/MIT/BSD license header with
SPDX-License-Identifier in all source files. This is more concise and
makes the license information machine readable.
Keep the full text of ISC for src/common/cockpitbase64.[hc], it's small
enough and only used in this pair of files. Also keep the CC-BY-SA
paragraph in pkg/storaged/icons/gnome-icons.jsx as explained in the
previous commit.
See https://reuse.software/spec-2.0/#2-include-a-copyright-notice-and-license-in-each-filehttps://issues.redhat.com/browse/COCKPIT-1742
Drop cockpithacks-glib by increasing our dependency to 2.68:
- the stderr logging hack was only needed before 2.67
- g_assert_no_error is available since 2.66
The oldest glib version we need to contend with is 2.68.4 on rhel-9-2,
so this should be fine.
Change a g_memdup() call to g_memdup2() to avoid a warning: the new API
is the same as the old one except that it takes `gsize` instead of
`guint`, avoiding integer overflow problems.
We have a cockpithacks.h file which is meant to collect various
workarounds/polyfills that we have for older operating systems. This
currently only contains a single polyfill: for closefrom(), which we can
replace with the now-widely-available close_range(). Make that change,
and drop the files.
With the created AsciiDoc files for documentation we can now update our
build structure to generate the HTML and Manpage files both during build
and package distribution.
Changes
- Uses AsciiDoctor or asciidoc-py and a2x to generate HTML and Manpages.
- Generated HTML and Manpage files moved to `doc/output/`.
- Support packaging docs on all distributions Cockpit deploys to.
- Add package dependencies for AsciiDoctor and asciidoc-py.
- Safety fallback in automake file to search for either asciidoctor or
asciidoc-py in terms of priority.
Known issues
- Links in guide pages goes to new files for the pages themselves, which
meant we now generate HTML files for all `.adoc` files and not just
`index.html`.
With the removal of fonts we also managed to break the build pipeline
that automake generated for us. As the doc guide fonts make rule was
removed, which relied on `$(DIST_STAMP)` rule, automake optimized the
build process and in turn broke the workflow. As a workaround the
`$(DIST_STAMP)` rule was added to the index rule as a dep to help
automake generate it the way we want it.
As the workaround is a hack and not a real solution, this needs to be
fixed in another PR to make sure these dependency issues do not occur if
we were to remove `$(DIST_STAMP)` from a rule.
We also need the `$(DIST_STAMP)` to appear last in the doc generation or
something, likely race condition, may cause the `index.html` to only
contain `{}`.
Related-to: https://github.com/cockpit-project/cockpit/issues/22648
Related-to: https://github.com/cockpit-project/cockpit/issues/22647
Co-authored-by: Aleksandra Fedorova <afedorova@redhat.com>
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
We can get a reliable, PID recycling resistant, /proc query for
cockpit-session's ws peer (i.e. the far end of its stdin Unix socket) by
getting a pidfd instead of an ucred. This is always the pidfd for the
process that started the communication, it cannot be recycled. If the
original process does go away, querying the pidfd will just fail, even
if a new process with the same pid comes along.
We still need to "resolve" the pidfd to a pid to open /proc/pid/cgroup
(there is no direct kernel API to get a pidfd's cgroup). But validate
the pid *after* that query to ensure it didn't get recycled.
This is much easier and safer to do than parsing /proc/pid/stat.
However, this requires kernel 6.5, so is not yet available in e.g.
Debian 12 or RHEL 9. So keep the pid+time comparison fallback for these
older OSes.
Thanks to @bluca for the helpful technical advice!
https://github.com/cockpit-project/cockpit/pull/16808#discussion_r1853116322https://issues.redhat.com/browse/COCKPIT-1207
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.
We will want to refer to that setting in more places than the shell,
so it's good to be prepared for that. At least the login page will
also needs it.
The default for the setting is now a ./configure option, with a
default default of "host switcher is off".
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.
All distributions use the same value anyway, and this paves the way for
unifying them further with moving to systemd-sysusers.
We never test the upstream default of running them as root, so it might
not even work and we also don't want to support/encourage that.
Co-Authored-By: Martin Pitt <mpitt@redhat.com>
The build of `cockpit-tls` otherwise fails with a linker error on systems using
the musl C library:
```
[...]
CCLD cockpit-tls
ld.lld: error: undefined symbol: argp_parse
>>> referenced by main.c:103 (/home/marv/devel/cockpit/src/tls/main.c:103)
>>> src/tls/main.o:(main)
ld.lld: error: undefined symbol: argp_error
>>> referenced by main.c:51 (/home/marv/devel/cockpit/src/tls/main.c:51)
>>> src/tls/main.o:(arg_parse_int)
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
```
On systems with musl C library the build of cockpit-bridge otherwise fails with
a linker error:
```
[...]
CCLD cockpit-bridge
ld.lld: error: undefined symbol: fts_open
>>> referenced by cockpitcgroupsamples.c:230 (/home/marv/devel/cockpit/src/bridge/cockpitcgroupsamples.c:230)
>>> libcockpit_metrics_a-cockpitcgroupsamples.o:(notice_cgroups_in_hierarchy) in archive libcockpit-metrics.a
ld.lld: error: undefined symbol: fts_read
>>> referenced by cockpitcgroupsamples.c:233 (/home/marv/devel/cockpit/src/bridge/cockpitcgroupsamples.c:233)
>>> libcockpit_metrics_a-cockpitcgroupsamples.o:(notice_cgroups_in_hierarchy) in archive libcockpit-metrics.a
ld.lld: error: undefined symbol: fts_close
>>> referenced by cockpitcgroupsamples.c:254 (/home/marv/devel/cockpit/src/bridge/cockpitcgroupsamples.c:254)
>>> libcockpit_metrics_a-cockpitcgroupsamples.o:(notice_cgroups_in_hierarchy) in archive libcockpit-metrics.a
```
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
The Python bridge was released some time ago and proven to be stable
enough. So drop the obsolete cockpit-client-ssh bridge, reducing our SSH
bridges from three to two.
This makes `--enable-cockpit-client` depend on `--enable-pybridge`;
enforce this in configure. In the near future, we'll flip this around,
make the Python bridge the default, and add an option for the C bridge
instead.
Giving --enable-pybridge to configure works as intended, but there
will be a warning as well because it is mispelled in one place:
configure: WARNING: unrecognized options: --enable-pybridge
This disables building and installing the C version of the
cockpit-bridge and cockpit-askpass.
Instead, it runs `pip install .` to install the equivalent Python
versions.
Actually check for the "xgettext" binary in the relevant section.
xsltproc is already checked further down, conditionalized by
--enable-docs. The latter is also in a different package.
See https://github.com/cockpit-project/cockpit/discussions/18408
Specifically, this omits /usr/sbin and /sbin from PATH, which are
symlinks to /usr/bin on Arch. This avoids resolving "pkexec
cockpit-bridge" to "pkexec /usr/sbin/cockpit-bridge", which would miss
our Polkit rule, which expects /usr/bin/cockpit-bridge.
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
Our attempts to translate strings generated by C code in cockpit are
hopelessly complicated and currently ineffectual.
There are only three strings that have been marked for translation, and
they're all in the bridge. Meanwhile, the code to compile the
translations only considers files found in `src/ws`, which skips the
files in the bridge, but includes the translations found in the
`cockpit-ws` appdata. That might be helpful, except that we already use
`msgfmt` to merge these translations at build time.
Drop the rules for creating and installing the filtered .mo files.
I created `cockpit.pot` before and after this change and confirmed that
exactly the three expected strings disappeared, and that (except for
timestamps) nothing else changed.
This makes sure we get the executable with the correct `--host` prefix,
allowing us to successfully cross-compile. Without this, `AR` gets
hard-coded to `ar`.
Thanks to Timo Gurr for reporting the problem.
Clean up the pkg-config and some `--enable-` flags usage in
configure.ac. Stop defining AC_SUBST rules like COCKPIT_WS_CFLAGS and
just let the pkg-config results go through. The Makefiles can decide
for themselves which bits they want to use for each component.
Create a new library, libcockpit-test.a, from the files in src/testlib/.
This library gets linked from all test programs.
Adjust all of the Makefiles in src/ to these two changes, and perform
general cleanup. One major goal of this cleanup is to make standalone
segments of the file for separate build targets. For example, adding a
new unit test shouldn't involve adding it to a list in one place and
then defining variables in another: this should all be done in one set
of adjacent lines.
This used to be important with the overlinking caused by `pkg-config
--lib` returning all of the dependency libraries, but this has been
cleaned up quite well these days, via `Requires.private` (which is
well-used).
The only library that --as-needed was actually dropping for us was -lm,
which we were spuriously hardcoding, for ourselves, in configure.ac (now
dropped).
Take the SELinux policy building out of the spec file and add a proper
set of Makefile rules for it. Stop blanket-disting the selinux/
subdirectory, and treat it more like a normal source directory.
The new rules are only enabled if --enable-selinux-policy=<type> is
explicitly given.
From the parts remaining in the spec file, clean them up a bit: remove
the with_selinux conditional and use the pre- and post- rules
unconditionally: we're only building the cockpit-ws package, anyway, in
exactly the case that we'd want SELinux policy enabled.
We can also make use of the macro provided by the selinux-policy package
to avoid having to guess the version number for ourselves. We need to
keep our own dependencies (instead of using %selinux_requires), though
for two reasons:
- chicken and egg problem: without a static BuildRequires on
selinux-policy, the macros themselves wouldn't be available during
the SRPM build, which means that we don't know that we need
selinux-policy.
- the post dependencies defined by the macro are a bit too aggressive
and aren't conditional on selinux being available at all. This
would break container builds, for example.
Our %build stage now consists of a single %configure invocation and a
single %make_build invocation.
Commit c66a65feac caused Fedora koji builds to break on finding the
debug symbols. Revert it for now. Let's figure this out after the
release: Debian builds probably already supply the flag as part of their
reproducible build efforts, and we can put it back into the .spec file
when/where needed.
Also revert the corresponding unit test from commit 59e173100.
Add -ffile-prefix-map to CFLAGS, which is a way to prevent the full
absolute path of build-time source filenames from ending up in (the
debugging symbols of) the binaries we install.
The RHEL8 version of the code (in /usr/lib/rpm/find-debuginfo.sh) for
scanning for the list of source files to include in the -debugsource
package is confused by the remapping, so disable it.
4cfc28a09d introduced our own version of
close_range(), but this turned out to be the wrong API. closefrom() is
meanwhile available on modern versions of glibc. It features a
simplified API, with no chance of failure.
Rename cockpitcloserange.c to cockpitclosefrom.c and move the definition
into cockpithacks.h. Introduce a configure check for closefrom() and
port all users to the closefrom() API. In case that's not available, we
redirect those calls to our own cockpit_closefrom() (which is now only
conditionally-built).
Since neither the glibc API nor our own code have any chance of failure,
we can drop all the error checking we were doing before.
Incidentally, this should fix warnings we were occasionally seeing from
Valgrind that we were finding and attempting to close its log fd.
Modern Valgrind wraps closefrom() and prevents this from happening.
This results in `_LARGE_FILES` and related macros in config.h, which are
now applied to all of our source files. In particular, this fixes large
file support for ws certificate scanning.
Fixes#16778
We do this by creating our own tar command which adjusts the timestamps
to values based on the commit date, and then calls tar.
We use ustar format to void storing atime and ctime (which we don't have
precise control over).
This was the first approach I took to solve this problem, and the
following commits will immediately change the approach. I include it
here so that it's in our history, in case we ever want to return to it.
https://bugs.kde.org/show_bug.cgi?id=361770 got fixed a while ago now
and has since found its way into Fedora 35 and our unit-tests container,
which are the two places where we're likely to run `make check-memory`.
Drop the hack.
AM_PROG_AR is for including tools/ar-lib in our tarballs, which is
useful (only) for helping compile .lib libraries on Windows.
AC_PROG_CC is implied through the use of other macros.
