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.
This variable (and associated macro) exists to support systems where
symbolic links aren't supported, falling back to copying. It's pretty
safe to say that we don't need this feature.
Add a new --wildly-insecure mode that causes cockpit-client to spawn its
own cockpit-ws internally.
cockpit-client creates and listens to the port, passing it into
cockpit-ws, and avoiding races. We also write a config file to a
temporary location to tweak the defaults a bit, including enabling the
recently-added X-For-CockpitClient mode.
The main configuration tweak is that we hide the username and password
fields, showing only the server name field, and make use a new
conditionally-installed cockpit-client-ssh script in place of the normal
cockpit-ssh program. This script spawns ssh to make connections using
the user's ssh config.
Specifying the files directly to AC_OUTPUT stopped being cool some time
ago and these days automake will even complain about that:
configure.ac:502: warning: AC_OUTPUT should be used without arguments.
Use AC_CONFIG_FILES instead.
AC_HELP_STRING has been obsolete and replaced with AS_HELP_STRING since
2003. Since autoconf 2.70 obsolete construct warnings are enabled by
default, as autoconf < 2.70 is still widely used obsolete
warnings are now explicitly enabled in `./autogen.sh`.
https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Pretty-Help-Strings.html
AC_ISC_POSIX and AC_HEADER_STDC macros are both obsolete and no longer
required. AC_ISC_POSIX checks for "Interactive Corporation Unix" which
is no longer sold and Sun dropped support for it in 2006.
AC_HEADER_STDC checks if the system has C header files conforming to
ANSI C89, which all current systems should have now.
The obsolete AC_PROG_CC_C99 macro checks if the C compiler is in C99
mode and if not tried to make it so. Since at least GCC 5.4.0 is
-std=gnu11 if no options are provided.
This has never been part of glibc. The closest seems to be BSD's
proc_fdwalk(), but it has a different API. So in practice we've always
used our own implementation.
Commit e5c9ef92f8 introduced this configure check without any pointers
or justification, so just drop it.
Instead of checking for all of the individual tools in ./configure and
settings their paths, just check for xgettext (to make sure the package
is installed) and run them out of PATH.
I tried to move over to standard upstream gettext, but I noticed that
our gettext stuff is sufficiently "custom" that we don't actually use
this in any meaningful way. We even define our own "update-po" rule,
for example.
Just drop it.
Stop the split-out of the client certificate authentication to a PAM
module. The original reasons for doing so are no longer valid, and the
module design complicates passing additional information into the
authentication step.
The bulk of the logic in the PAM module is moved to a new file,
cockpit-session-client-certificate.[ch]. The PAM module is left around
as a stub, for those who still include it in their configs, but it is
removed from our PAM configs, and the manpage has been dropped (with its
content merged with an existing similar section in `src/tls/README.md`).
Some adjustments are made: we use the debug() macro from session-utils
and generally move over to logging to stderr instead of syslog. We also
replace pam status codes with success bools.
This already checks the header file, and it's not very realistic to have
a system with the header, but not the library. If so, it will just fail
later during build.
This will make it much easier to build a dist tarball in a limited
environment. The header check is easy enough to mock, but not the
library.
Marvin Schmidt