We can't assume that time_t is 'long'. When building for win64 we get:
../f5.c: In function 'f5_configure':
../f5.c:690:63: warning: format '%ld' expects argument of type 'long int *', but argument 6 has type 'time_t *' {aka 'long long int *'} [-Wformat=]
690 | if (sscanf(cookie->value, "%dz%dz%dz%ldz%ld%c", &junk, &junk, &junk, &start, &dur, &c) >= 5
| ~~^ ~~~~~~
| | |
| long int * time_t * {aka long long int *}
| %lld
../f5.c:690:67: warning: format '%ld' expects argument of type 'long int *', but argument 7 has type 'time_t *' {aka 'long long int *'} [-Wformat=]
690 | if (sscanf(cookie->value, "%dz%dz%dz%ldz%ld%c", &junk, &junk, &junk, &start, &dur, &c) >= 5
| ~~^ ~~~~
| | |
| long int * time_t * {aka long long int *}
| %lld
Make it explicitly 'unsigned long long' instead.
Signed-off-by: David Woodhouse <email address hidden>
Merge branch 'optipng' of gitlab.com:openconnect/openconnect
eb479cf...
by
Dimitri Papadopoulos <email address hidden>
Ignore non-sensical NBNS/WINS server address
A VPN server sent the non-sensical NBNS/WINS server IP address 0.0.0.0.
I assume this is the default value in the VPN configuration. If so, it
could happen again. Do not pass this invalid default value to the script.
Depending on build options, libproxy-1.0.pc depends indirectly
on json-c.pc:
libproxy-1.0 -> gio-2.0 -> mount -> libcryptsetup -> json-c
This causes "pkg-config --cflags libproxy-1.0" to emit
"-I/usr/include/json-c".
json-c installs a "json.h" file that conflicts with the one provided by
json-parser. If json-c comes before json-parser on the compiler command,
we get a build failure:
openconnect-internal.h:1654:59: error: unknown type name 'json_value'
[ dwmw2: This is a combination of at *least* three different bugs in
three different packages conspiring to be my problem. See https://gitlab.com/openconnect/openconnect/-/merge_requests/476#note_1397129468
But still, working around it does no harm for now. Ironically, if the presence of json-c on the include path
wasn't *entirely* gratuitous then hiding it by putting it
last wouldn't actually work because then something would
fail to include the json-c version of <json.h> instead. ]
Bug: https://bugs.gentoo.org/906662
Signed-off-by: Mike Gilbert <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
We retrospectively added openconnect_set_sni() with the @OPENCONNECT_5_8
symbol version, *long* after API v5.8 was set in stone with the v9.00
release in April 2022.
Fix that by retconning it into a @OPENCONNECT_5_9 version which will be
part of the *next* release.
We have a unit test to prevent us from doing it again, and this commit
is the exception to the general rule that we should *never* commit to
libopenconnect5.symbols except as a side-effect of 'make tag' creating
a new release.
Fixes: 494edf49e628 ("Add openconnect_set_sni API function and Java setSNI() wrapper")
Signed-off-by: David Woodhouse <email address hidden>
Add dpkg-gensymbols template file and test for ABI violations
Symbol versioning is hard.
Add some sed magic to build a symbols file of the form consumed by
dpkg-gensymbols, which maps symbols+versions to the first version
of the package in which they appeared.
This serves two purposes.
Firstly it allows us to have a unit test which helps prevent us from
retrospectively adding symbols to a given version after it is first
released — as we did for example when we added openconnect_set_sni() to
OPENCONNECT_5_8 in the 9.10 release.
Secondly, it helps the Debian packaging to get dependencies right. In
RPM distributions, symbol versions map automatically to RPM dependencies
and everyhing Just Works. The package with the library gets a virtual
Provides: of e.g. 'libopenconnect.so.5(OPENCONNECT_5_8)(64bit)', any
package which *uses* symbols from the library will get a corresponding
virtual Requires: — for the symbols it's actually *using* — and it all
works out perfectly. Debian packages, on the other hand, appear to be
held together with duct tape and tears, and need the developer or the
packager to manually curate a file with the mapping of symbol versions
to the first version of the package in which they appeared.
Look Ma! I can sed!
Signed-off-by: David Woodhouse <email address hidden>
