[ubu24/22] add system libcivetweb

[ferdymercury]

No description provided.

[ferdymercury]

@linev ubu26 passed the httpserver test, should we enable now the other ubuntus and see?
https://github.com/root-project/root/actions/runs/26145752669/job/76900908168?pr=21947

[linev]

Important test is still missing - with WebSocket.
Let me try to implement it before we enable more platforms.

[ferdymercury]

Important test is still missing - with WebSocket.

Should we also add sth like this, after a system-wide civetweb is found?

if (civetweb_FOUND)
  get_target_property(CIVETWEB_DEFS civetweb::civetweb-c INTERFACE_COMPILE_DEFINITIONS)
  if(NOT "USE_WEBSOCKET" IN_LIST CIVETWEB_DEFS)
    message(STATUS "Force-enabling builtin_civetweb since found system-wide version does not include websocket component")
    set(builtin_civetweb FORCE ON)
  endif()
endif()

[linev]

Should we also add sth like this, after a system-wide civetweb is found?

If it works - yes.
Without WebSocket support use of external civetweb makes no sense.

[ferdymercury]

If it works - yes.

Attempt here: root-project/root@f04d8ae

[ferdymercury]

If it works - yes.

what I initially suggested does not work, but I've fixed it now here:
root-project/root@77492ec

Question: apart from websocket, do we mandatorily need to check for some extra features that are off by default?

For example, Ubuntu 22 returns 151 as bit mask (in the PR now printed by ROOT configure script to terminal), which means https, cgi, websocket are enabled but ipv6, zlib, serverstats, uselua and useduktape are disabled.

       The value is a bit mask. The individual bits are defined as:
         1  serve files (NO_FILES not set)
         2  support HTTPS (NO_SSL not set)
         4  support CGI (NO_CGI not set)
         8  support IPv6 (USE_IPV6 set)
        16  support WebSocket (USE_WEBSOCKET set)
        32  support Lua scripts and Lua server pages (USE_LUA is set)
        64  support server side JavaScript (USE_DUKTAPE is set)
       128  support caching (NO_CACHING not set)
       256  support server statistics (USE_SERVER_STATS is set)
       512  support for on the fly compression (USE_ZLIB is set)

In Ubuntu 26 it's 158, so IPV6 enabled there in contrast to ubu22

[linev]

SSL is optional and not directly used in the root
But civetweb has extra feature to support unix sockets - see in cmake:

target_compile_definitions(RHTTP PRIVATE -DUSE_X_DOM_SOCKET)

It is important and used by rootssh utility.

[ferdymercury]

support unix sockets

Detection fixed now via root-project/root@e1c7d63

[ferdymercury]

@tillea would it be possible to add

-DCIVETWEB_ENABLE_X_DOM_SOCKET=ON
To
https://salsa.debian.org/med-team/civetweb/-/blob/master/debian/rules?ref_type=heads#L21
?

It's required so that ROOT does not need to build its own copy

Thanks in advance

[tillea]

@tillea would it be possible to add

-DCIVETWEB_ENABLE_X_DOM_SOCKET=ON To https://salsa.debian.org/med-team/civetweb/-/blob/master/debian/rules?ref_type=heads#L21 ?

Sure its possible: https://salsa.debian.org/med-team/civetweb/-/commit/7562286db61418a43dd111df331161b5f106bd25

The "traditinal" way to request such things is to file a bug report via reportbug - but well I just did it.

Is your request urgent and should I upload this change soonish?

Kind regards, Andreas.

[ferdymercury]

The "traditinal" way to request such things is to file a bug report via reportbug

Ahh ok, i will note it down, sorry

Is your request urgent and should I upload this change soonish?

It's not urgent, thanks a lot anyway for the prompt reply

[tillea]

Ahh ok, i will note it down, sorry

No need to sorry - just mentioning it since this results in a better documentation from the Debian side. If some change in a package closes a bug this is documenting the change in a standard way.

It's not urgent, thanks a lot anyway for the prompt reply

Feel free to let me know if it becomes urgent. ;-)

[linev]

I add several basic tests for THttpServer - including websocket and unix socket test.
So one can now add system-wide civetweb and see how it behaves

[ferdymercury]

So one can now add system-wide civetweb and see how it behaves

Thanks Sergei.
Is there a way to modify packages.txt to install the Ubuntu civetweb system package from the 'unstable' Debian channel? Otherwise it will still have XDOM sockets off.

[linev]

Is there a way to modify packages.txt to install the Ubuntu civetweb system package from the 'unstable' Debian channel? Otherwise it will still have XDOM sockets off.

I have no idea how it works with Debian package manager.

[ferdymercury]

Sure its possible: https://salsa.debian.org/med-team/civetweb/-/commit/7562286db61418a43dd111df331161b5f106bd25

@tillea sorry, I just noticed that, for this to work,
we would need also that this post 1.16 patch is backported into the Debian repo:
civetweb/civetweb@08b7241 (or this one for a clean patch without conflicts ferdymercury/civetweb@c501621)

Or alternatively, temporarily add a flag to the gcc compilation options as done eg in opensuse: https://code.opensuse.org/package/civetweb/blob/master/f/civetweb.spec#_80

[tillea]

Sure its possible: https://salsa.debian.org/med-team/civetweb/-/commit/7562286db61418a43dd111df331161b5f106bd25

@tillea sorry, I just noticed that, for this to work, we would need also that this post 1.16 patch is backported into the Debian repo: civetweb/civetweb@08b7241 (or this one for a clean patch without conflicts ferdymercury/civetweb@c501621)

Or alternatively, temporarily add a flag to the gcc compilation options as done eg in opensuse: https://code.opensuse.org/package/civetweb/blob/master/f/civetweb.spec#_80

Any chance to rather tag a new upstream release? This would be more convenient than assembling a lot of patches.

[ferdymercury]

Any chance to rather tag a new upstream release?

That's currently blocked by: civetweb/civetweb#1351 (comment)

(Which is why openSuse has switched to a git commit version rather than a specific version https://build.opensuse.org/requests/1354158)