We're not going to replace deprecated functions here, similar to commit
88e0ccb2 in the dbus-1.10 branch.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These were in git but not distributed in source tarballs, and in fact
not hooked up to the Autotools build system at all.
test/data/valid-introspection-files was mentioned in the CMake build
system (copied from the source directory to the build directory), but
according to `git grep` is not used for anything.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
Our official source releases are Autotools "make dist" tarballs, but
there's no reason why CMake users can't use those too, and we already
include the CMake build files.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
If we distribute the entire directory in "make dist" tarballs, then
we include the generated files cmake/DBus1Config.cmake and
cmake/DBus1ConfigVersion.cmake, which we should not.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
test-bus exercises the parser by trying to parse every file in these
directories. A couple of files were accidentally left out, meaning
those parsing code paths are tested when we build from git, but not
when we build from a tarball release.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
cmake/DBus1Config.cmake, cmake/DBus1ConfigVersion.cmake and dbus-1.pc
are all generated by AC_CONFIG_FILES, so they are automatically listed
in $(CONFIG_CLEAN_FILES) and cleaned in "make distclean" without further
help from us.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
It's generated by configure, so we should not distribute it.
Because it's generated by configure, it is automatically cleaned up
by "make distclean" via $(CONFIG_CLEAN_FILES).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
I'm hoping for 1.11.24 to act as 1.12rc1, with a remarkably similar
1.12.0 release shortly after if all goes well.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previous cmake versions seemed to be more tolerant.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Simon McVittie <smcv@collabora.com>
- include <windows.h> to be able to use constants
- let versioninfo be visible in explorer by adding a "Translation" value
- change FILEOS from VOS_NT_WINDOWS32, which was intended for Windows NT,
to VOS__WINDOWS32
- stop setting FILEFLAGS 0x20 (VS_FF_SPECIALBUILD), which is not
appropriate here because we build the normal version, not a special
version
- use constants
- fix strings
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Simon McVittie <smcv@collabora.com>
The recent implementation generates a timestamp containing eol on
linux hosts, which generates unparseable versioninfo.rc.
This commit raises the minimal required cmake version to 3.0.2.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Simon McVittie <smcv@collabora.com>
That's what is checked for by LT_LANG([Windows Resource]) further
up, and is what we now use during the build. Its value is typically
i686-w64-mingw32-windres.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
We have two variables that both expand to i686-w64-mingw32-windres,
namely WINDRES and RC, and we might as well use the same one as
in dbus/ here. However, it seems we can't wrap windres in libtool
when producing an executable: if we use .rc.lo, my Automake 1.15.1
doesn't realise that it needs to include disable-uac.lo in the
list of objects, whereas if we use .rc.o, Ralf's libtool 2.4.2 and
Automake 1.13.4 disagree on where the output should go
(.libs/disable-uac.o vs. disable-uac.o) and the link fails.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
If __LINE__ doesn't work in MSVC's resource compiler, then removing
the #line directive altogether seems a simpler fix than redefining
__LINE__ to the wrong value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The resource file used to #include this, but it was unnecessary,
and Ralf removed it in commit e3a14eb.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
libtool has built-in support for Windows resources, and we even
enable it in configure.ac. What it doesn't have is a built-in rule
for generating Libtool objects using that built-in support, but
we can add one.
We have to generate Libtool pseudo-objects (.lo) rather than native
object files (.o) so that we get both a PIC object for the shared
library and a non-PIC object for the static library.
This mimics the libtool invocations used for compiling C and C++.
Note that $(RC) is typically i686-w64-mingw32-windres, the same as
our project-specific variable $(WINDRES) which was previously used here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This is nicer for cross-compiling, because AC_RUN_IFELSE can't work
there. In practice abstract sockets are supported on Linux since
2.2 (so, all relevant versions), and on no other platform; so it
seems futile to keep this complexity.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This was presumably once used in constructs like
"unix:" DBUS_PATH_OR_ABSTRACT "=/var/run/dbus/foo", but git grep says
there are no remaining uses, so it can go.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
libdbus isn't localized, so we have no use for libintl. We always
link libdbus-1 with -no-undefined, so we have no use for
putting that flag in no_undefined on Windows only. export_symbols
seems to be left over from before fd.o#83115 was fixed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
It appears this has been wrong ever since the versioninfo machinery
was first added in 2009, and nobody noticed until now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
We want this to apply to files ending with ".rc", but not to files
ending with just "rc", like .arc or something.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This explicitly sets the execution level to 'asInvoker', preventing
Windows' UAC heuristics from deciding that because its name mentions
"update", it probably needs to escalate privileges.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102558
Reviewed-by: Simon McVittie <smcv@collabora.com>
None of the things we rely on in POSIX async signal handlers, such
as the existence of async-signal-safe write(), are portable to Windows,
so the async signal handlers that use this function are #ifdef
DBUS_UNIX anyway. Remove the unused stub function from the
Windows side, and move the declaration to the Unix-specific header.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103010
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
If an async signal interrupts some function, we can have this
anti-pattern:
/* in normal code */
result = some_syscall (); /* fails, e.g. errno = EINVAL */
/* interrupted by async signal handler */
write (...); /* fails, e.g. errno = ENOBUFS */
/* back to normal code */
if (errno == EINVAL) /* problem! it should be but it isn't */
The solution is for signal handlers to save and restore errno.
This is unnecessary for signal handlers that can't touch errno (like
the one in dbus-launch that just sets a flag), and for signal handlers
that never return (like the one in test-utils-glib for timeouts).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103010
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Some test-cases in the dbus-daemon and relay tests spam the bus with
thousands of messages, which can take 25 seconds on slower CPUs like
MIPS. Similarly, the refs test spams millions of refcount operations,
which it appears might take more than a minute on PA-RISC (HPPA).
To get an idea of how close we are to having a problem on other
architectures, log a message and start a timer when we reset the
timeout in setup(), and log the elapsed time when we reach teardown().
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103009
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
We can't use normal I/O in a signal handler, so resort to write().
"Bail out!" is a special syntactic token in TAP. If I artifically force
the tests to time out by reducing timeouts and increasing the number of
operations, I get results like this:
ERROR: test-sd-activation - Bail out! Test timed out (GLib main loop timeout callback reached)
ERROR: test-refs - Bail out! Test timed out (SIGALRM received)
which is a lot easier to understand than "Not enough tests run" or
"nonzero exit status". The differing output is because test-sd-activation
iterates the main loop, whereas test-refs just blocks (it is joining a
series of worker threads, each of which is spamming refcount operations).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103009
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Use STDOUT_FILENO as per Philip's review]
Signed-off-by: Simon McVittie <smcv@collabora.com>
LSB-style (SysV-style) init scripts have not historically been
portable between distributions, as evidenced by the presence of both
"Red Hat" and "Slackware" init scripts in dbus. Many distributors
prefer to maintain them downstream, as is done in Debian (and its
derivatives) and in Slackware, so that the init script can follow
OS conventions (for example regarding boot messages) and make use
of OS-provided facilities (for example, the Debian init script uses
dpkg's start-stop-daemon utility).
The Slackware and Red Hat init scripts removed by this commit are not
tested or maintained in practice, and so are likely to have bugs. The
Slackware init-script provided here is not used on actual Slackware
systems, which provide a different implementation of rc.messagebus in
their packaging, while the Red Hat init script has been superseded by
the systemd unit in current Fedora, CentOS and RHEL versions.
The Cgywin messagebus-config provided here does appear to be used in
production in cygwin-ports, but it's full of Cygwin-specifics with which
the dbus maintainers are not familiar, so it is probably more appropriate
for it to be tracked downstream as part of the Cygwin packaging.
The systemd unit is not removed, since it is used on multiple Linux
distributions with little or no modification, and receives regular
testing and maintenance; this makes it appropriate to maintain upstream.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101706
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This feature is now compile-time conditional, and off by default.
pam_console appears to have been in Fedora and Gentoo until 2007.
pam_foreground seems to be specific to Debian and Ubuntu, where it was
unmaintained since 2008 and removed in 2010. The replacement for both
was ConsoleKit, which has itself been superseded by systemd-logind and
ConsoleKit2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101629
Reviewed-by: Philip Withnall <withnall@endlessm.com>
