Closed Apteryks closed 1 year ago
For the latest 0.6.17 release, the summary is like:
53% tests passed, 28 tests failed out of 60
Total Test time (real) = 3.75 sec
The following tests FAILED:
14 - _unit.test.socket_options (Failed)
16 - _unit.test.handle_requests.method (Failed)
17 - _unit.test.handle_requests.echo_body (Failed)
18 - _unit.test.handle_requests.timeouts (Failed)
19 - _unit.test.handle_requests.throw_exception (Failed)
20 - _unit.test.handle_requests.slow_transmit (Failed)
21 - _unit.test.handle_requests.user_controlled_output (Subprocess aborted)
22 - _unit.test.handle_requests.chunked_output (Subprocess aborted)
23 - _unit.test.handle_requests.output_and_buffers (Failed)
24 - _unit.test.handle_requests.notificators (Failed)
25 - _unit.test.handle_requests.remote_endpoint (Failed)
26 - _unit.test.handle_requests.connection_state (Failed)
27 - _unit.test.handle_requests.ip_blocker (Failed)
28 - _unit.test.handle_requests.upgrade (Failed)
29 - _unit.test.handle_requests.chunked_input (Failed)
30 - _unit.test.handle_requests.acceptor_post_bind_hook (Failed)
31 - _unit.test.handle_requests.incoming_msg_limits (Failed)
32 - _unit.test.handle_requests.connection_count_limit (Subprocess aborted)
33 - _unit.test.handle_requests.user_data_simple (Failed)
34 - _unit.test.handle_requests.chained_handlers (Failed)
35 - _unit.test.run_on_thread_pool (Subprocess aborted)
36 - _unit.test.http_pipelining.sequence (Failed)
37 - _unit.test.http_pipelining.timeouts (Failed)
38 - _unit.test.sendfile (Failed)
50 - _unit.test.transforms.zlib_body_appender (Failed)
51 - _unit.test.transforms.zlib_body_handler (Failed)
56 - _unit.test.ws_connection (Failed)
60 - _unit.test.socket_options_tls (Failed)
Errors while running CTest
Hi! If you use Docker for isolated build could you please provide a Dockerfile that I can experiment?
Hi! This was tested in the Guix build container; assuming you have Guix installed, basically:
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
yes | sudo ./guix-install.sh
Then you should be able to reproduce the problem as I see it via:
guix time-machine --disable-authentication --url=https://gitlab.com/Apteryks/guix --branch=restinio-test-issues-reproducer -- build -K restinio
I can't reproduce the build. I'm trying to use the following Dockerfile to get Guix container:
FROM ubuntu:22.04
RUN apt-get update
RUN apt-get -qq -y install wget
RUN apt-get -qq -y install gnupg
RUN apt-get -qq -y install xz-utils
RUN wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
RUN chmod +x guix-install.sh
RUN yes '' | ./guix-install.sh
RUN guix time-machine --disable-authentication --url=https://gitlab.com/Apteryks/guix --branch=restinio-test-issues-reproducer -- build -K restinio
The error I've got:
guix time-machine: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
The command '/bin/sh -c guix time-machine --disable-authentication --url=https://gitlab.com/Apteryks/guix --branch=restinio-test-issues-reproducer -- build -K restinio' returned a non-zero code: 1
Hmm, I doubt you'll be able to install Guix and run it inside a Docker container easily; I'd try on your host system; Guix will only install files under /gnu/store
and keep its database under /var/guix
, so it's easy to remove it if you want to (something like systemctl stop gnu-store.mount && systemctl stop guix-daemon && rm -rf /gnu/store /var/guix
)
I have problems accessing https://guix.gnu.org/ and https://ci.guix.gnu.org/ They do not respond. May be I can access them from my country.
Anyway it seems that the problem doesn't related to RESTinio itself. I think an exception is thrown here: https://github.com/Stiffstream/restinio/blob/v.0.6.17/dev/test/common/pub.hpp#L35-L38
This part is implemented in Asio and Asio (I suppose) uses something like gethostbyname. Maybe gethostbyname
can't work properly in Guix at the stage when a new package is being configured?
@eao197 Hi! Thanks for pursing my repro suggestion, and apologies that the guix.gnu.org host is not currently reachable from your country. Since then at least the web site is now hosted from a different machine/network so should hopefully be available to you. There's also a 2nd build farm for binary substitutes that can be added manually that hopefully is also reachable from your location, https://bordeaux.guix.gnu.org/.
I have things to try on my side and it might take some time before I get to the bottom of it, but when I have something interesting to report I will do so! Thank you for your help thus far.
Hi, @Apteryks !
I'm not a Guix user so I don't understand instructions from https://bordeaux.guix.gnu.org/. There are a couple of examples of scheme code but I have no idea what to do with them. I suppose it's required to insert those fragments somewhere but I don't want to study a lot of Guix docs to find the answer.
On my test machine I did:
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
then ran yes '' | ./guix-install.sh
.
When I'm trying to do:
guix install glibc-utf8-locales
I can't get updates from ci.guix.gnu.org
.
What should I do to use bordeaux.guix.gnu.org instead of ci.guix.gnu.org?
Hi eao197!
You'll want to have a recent version of guix-daemon
running. On a foreign GNU/Linux distribution (not Guix System), this is accomplished with:
sudo -i guix pull
sudo systemctl restart guix-daemon.service
(e.g., updating the 'guix' copy of the root user and restarting the guix service, which makes use of this copy)
You'll also then need to authorize the bordeaux public key (the pre-built binaries it distributes are signed); which can be done with:
sudo guix archive --authorize \
< $HOME/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
If I understand correctly the restart guix-daemon.service will be useless because I don't know what to do with those code fragments:
(define %my-desktop-services
(modify-services
%desktop-services
(guix-service-type
config =>
(guix-configuration
(inherit config)
(substitute-urls
(append (list "https://bordeaux.guix.gnu.org/")
%default-substitute-urls))
(authorized-keys
(append
(list
(plain-file
"bordeaux.guix.gnu.org.signing.key"
"
(public-key
(ecc
(curve Ed25519)
(q #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F#)
)
)"))
%default-authorized-guix-keys)))))))
(operating-system
...
(services (append (list (service dhcp-client-service-type)
(service openssh-service-type
(openssh-configuration
(openssh openssh-sans-x)
(port-number 2222))))
%my-desktop-services)))
I suppose they have to be inserted somewhere.
Hey!
Since you used the guix-install.sh
script, what you have is guix
the package manager running atop your GNU/Linux distribution. Guix can also be installed as a distribution, replacing Debian or the likes completely; this is called Guix System
. The above Scheme fragments are to be used for configuring a Guix System, so you need not concern yourself with them.
I hope this clears things a bit? :-)
Always happy to help, so don't hesitate.
I hope this clears things a bit? :-)
Yes, thanks.
But I have problems with this command:
sudo -i guix pull
It can't complete:
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 9b714ec (28,839 new commits)...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git 9b714ec
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out
substitute:
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
Hi!
By using VPN I successfully did:
sudo -i guix pull
sudo systemctl restart guix-daemon.service
But this command failed:
sudo guix archive --authorize \
< $HOME/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
because there is no such a file.
Anyway, it seems that I can do something with guix via VPN and will try to experiment with:
guix time-machine --disable-authentication --url=https://gitlab.com/Apteryks/guix --branch=restinio-test-issues-reproducer -- build -K restinio
Hi! About why $HOME/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
is not available, I guess that's because you haven't yet updated your Guix command for your user (guix is usable per user, and so far we've updated the root user's Guix only).
It's a lot to wrap one's head around at first, so kudos for making it this far :-).
The bordeaux machine public key should be available from /root/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
. If it's not, you can put the following in a bordeaux.pub
file:
(public-key
(ecc
(curve Ed25519)
(q #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F#)
)
)
And then sudo guix archive --authorize < bordeaux.pub
, and you should be good. The key should appear in the list of authorized keys in the file /etc/guix/acl
.
If the https://ci.guix.gnu.org host still gives you problems, you can override the substitute URLs used, for example via guix pull --substitute-urls=https://bordeaux.guix.gnu.org
. As long as the machine is authorized, it should work.
Hi!
I did
guix time-machine --disable-authentication --url=https://gitlab.com/Apteryks/guix --branch=restinio-test-issues-reproducer -- build -K restinio
and received the same failures in tests.
So now I want to understand how I can experiment with Guix and modified RESTinio sources.
Can I copy the content of restinio-test-issues-reproducer branch of https://gitlab.com/Apteryks/guix to my machine and instruct Guix to take the content from my local copy?
How should I modify the content of gnu/packages/networking.scm to get RESTinio sources from my machine but not from GitHub? (Is it possible at all?)
you should be able to test using modified sources from your machine using something like guix time-machine --disable-authentication --url=https://gitlab.com/Apteryks/guix --branch=restinio-test-issues-reproducer -- build -K restinio --with-source=restinio=file:///home/user/src/restinio
, where the absolute path is adjusted to point to your restinio sources. Alternatively, if your changes are committed, you could replace --with-source
with --with-git-url
, which should be more efficient.
Hi!
As I said earlier the problem in this fragment (https://github.com/Stiffstream/restinio/blob/v.0.6.17/dev/test/common/pub.hpp#L35-L38):
restinio::asio_ns::ip::tcp::resolver resolver{ io_context };
restinio::asio_ns::ip::tcp::resolver::query
query{ restinio::asio_ns::ip::tcp::v4(), addr, std::to_string( port ) };
restinio::asio_ns::ip::tcp::resolver::iterator iterator = resolver.resolve( query );
It's Asio-related code, not RESTinio. I don't know why Asio fails at resolving attempts here (the addr is just "127.0.0.1"), maybe there are some restriction from Guix environment. Maybe something else.
Hi! Thanks for the confirmation that the problem stems from Asio. I'll try to dedicate some time digging into this too, perhaps with minimal reproducer that makes use of Asio. Cheers!
Hi!
As a workaround you can try a version from "issue-172-workaround-1" branch.
It seems that we don't use any domain names except "localhost" (and addresses except "127.0.0.1") in tests. So this workaround should work (I hope). But I don't know yet is it a good idea to merge this change into the main branch.
Hello!
I gave this a try, and I confirm it works :-)
make[1]: Leaving directory '/tmp/guix-build-restinio-git.issue-172-workaround-1.drv-0/source/build'
/gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4/bin/cmake -E cmake_progress_start /tmp/guix-build-restinio-git.issue-172-workaround-1.drv-0/source/build/CMakeFiles 0
phase `build' succeeded after 143.7 seconds
starting phase `check'
Running tests...
/gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4/bin/ctest --force-new-ctest-process
Test project /tmp/guix-build-restinio-git.issue-172-workaround-1.drv-0/source/build
Start 1: _unit.test.metaprogramming
1/60 Test #1: _unit.test.metaprogramming ........................... Passed 0.00 sec
Start 2: _unit.test.tuple_algorithms
2/60 Test #2: _unit.test.tuple_algorithms .......................... Passed 0.00 sec
Start 3: _unit.test.utf8_checker
3/60 Test #3: _unit.test.utf8_checker .............................. Passed 0.00 sec
Start 4: _unit.test.http_field_parser
4/60 Test #4: _unit.test.http_field_parser ......................... Passed 0.00 sec
Start 5: _unit.test.try_parse_field
5/60 Test #5: _unit.test.try_parse_field ........................... Passed 0.00 sec
Start 6: _unit.test.multipart_body
6/60 Test #6: _unit.test.multipart_body ............................ Passed 0.00 sec
Start 7: _unit.test.default_constructed_settings
7/60 Test #7: _unit.test.default_constructed_settings .............. Passed 0.00 sec
Start 8: _unit.test.ref_qualifiers_settings
8/60 Test #8: _unit.test.ref_qualifiers_settings ................... Passed 0.00 sec
Start 9: _unit.test.header
9/60 Test #9: _unit.test.header .................................... Passed 0.00 sec
Start 10: _unit.test.buffers
10/60 Test #10: _unit.test.buffers ................................... Passed 0.00 sec
Start 11: _unit.test.response_coordinator
11/60 Test #11: _unit.test.response_coordinator ...................... Passed 0.00 sec
Start 12: _unit.test.write_group_output_ctx
12/60 Test #12: _unit.test.write_group_output_ctx .................... Passed 0.00 sec
Start 13: _unit.test.uri_helpers
13/60 Test #13: _unit.test.uri_helpers ............................... Passed 0.00 sec
Start 14: _unit.test.socket_options
14/60 Test #14: _unit.test.socket_options ............................ Passed 0.00 sec
Start 15: _unit.test.start_stop
15/60 Test #15: _unit.test.start_stop ................................ Passed 0.00 sec
Start 16: _unit.test.handle_requests.method
16/60 Test #16: _unit.test.handle_requests.method .................... Passed 0.00 sec
Start 17: _unit.test.handle_requests.echo_body
17/60 Test #17: _unit.test.handle_requests.echo_body ................. Passed 0.00 sec
Start 18: _unit.test.handle_requests.timeouts
18/60 Test #18: _unit.test.handle_requests.timeouts .................. Passed 4.01 sec
Start 19: _unit.test.handle_requests.throw_exception
19/60 Test #19: _unit.test.handle_requests.throw_exception ........... Passed 0.00 sec
Start 20: _unit.test.handle_requests.slow_transmit
20/60 Test #20: _unit.test.handle_requests.slow_transmit ............. Passed 0.19 sec
Start 21: _unit.test.handle_requests.user_controlled_output
21/60 Test #21: _unit.test.handle_requests.user_controlled_output .... Passed 0.19 sec
Start 22: _unit.test.handle_requests.chunked_output
22/60 Test #22: _unit.test.handle_requests.chunked_output ............ Passed 0.06 sec
Start 23: _unit.test.handle_requests.output_and_buffers
23/60 Test #23: _unit.test.handle_requests.output_and_buffers ........ Passed 0.01 sec
Start 24: _unit.test.handle_requests.notificators
24/60 Test #24: _unit.test.handle_requests.notificators .............. Passed 0.00 sec
Start 25: _unit.test.handle_requests.remote_endpoint
25/60 Test #25: _unit.test.handle_requests.remote_endpoint ........... Passed 0.00 sec
Start 26: _unit.test.handle_requests.connection_state
26/60 Test #26: _unit.test.handle_requests.connection_state .......... Passed 0.00 sec
Start 27: _unit.test.handle_requests.ip_blocker
27/60 Test #27: _unit.test.handle_requests.ip_blocker ................ Passed 0.00 sec
Start 28: _unit.test.handle_requests.upgrade
28/60 Test #28: _unit.test.handle_requests.upgrade ................... Passed 0.00 sec
Start 29: _unit.test.handle_requests.chunked_input
29/60 Test #29: _unit.test.handle_requests.chunked_input ............. Passed 0.00 sec
Start 30: _unit.test.handle_requests.acceptor_post_bind_hook
30/60 Test #30: _unit.test.handle_requests.acceptor_post_bind_hook ... Passed 0.00 sec
Start 31: _unit.test.handle_requests.incoming_msg_limits
31/60 Test #31: _unit.test.handle_requests.incoming_msg_limits ....... Passed 0.00 sec
Start 32: _unit.test.handle_requests.connection_count_limit
32/60 Test #32: _unit.test.handle_requests.connection_count_limit .... Passed 19.94 sec
Start 33: _unit.test.handle_requests.user_data_simple
33/60 Test #33: _unit.test.handle_requests.user_data_simple .......... Passed 0.00 sec
Start 34: _unit.test.handle_requests.chained_handlers
34/60 Test #34: _unit.test.handle_requests.chained_handlers .......... Passed 0.01 sec
Start 35: _unit.test.run_on_thread_pool
35/60 Test #35: _unit.test.run_on_thread_pool ........................ Passed 0.27 sec
Start 36: _unit.test.http_pipelining.sequence
36/60 Test #36: _unit.test.http_pipelining.sequence .................. Passed 0.11 sec
Start 37: _unit.test.http_pipelining.timeouts
37/60 Test #37: _unit.test.http_pipelining.timeouts .................. Passed 0.10 sec
Start 38: _unit.test.sendfile
38/60 Test #38: _unit.test.sendfile .................................. Passed 0.07 sec
Start 39: _unit.test.router.easy_parser_router_dsl
39/60 Test #39: _unit.test.router.easy_parser_router_dsl ............. Passed 0.00 sec
Start 40: _unit.test.router.easy_parser_path_to_tuple
40/60 Test #40: _unit.test.router.easy_parser_path_to_tuple .......... Passed 0.00 sec
Start 41: _unit.test.router.easy_parser_path_to_params
41/60 Test #41: _unit.test.router.easy_parser_path_to_params ......... Passed 0.00 sec
Start 42: _unit.test.router.express
42/60 Test #42: _unit.test.router.express ............................ Passed 0.02 sec
Start 43: _unit.test.router.express_router
43/60 Test #43: _unit.test.router.express_router ..................... Passed 0.01 sec
Start 44: _unit.test.router.express_router_user_data_simple
44/60 Test #44: _unit.test.router.express_router_user_data_simple .... Passed 0.01 sec
Start 45: _unit.test.router.express_pcre
45/60 Test #45: _unit.test.router.express_pcre ....................... Passed 0.01 sec
Start 46: _unit.test.router.express_router_pcre
46/60 Test #46: _unit.test.router.express_router_pcre ................ Passed 0.01 sec
Start 47: _unit.test.router.express_pcre2
47/60 Test #47: _unit.test.router.express_pcre2 ...................... Passed 0.01 sec
Start 48: _unit.test.router.express_router_pcre2
48/60 Test #48: _unit.test.router.express_router_pcre2 ............... Passed 0.01 sec
Start 49: _unit.test.transforms.zlib
49/60 Test #49: _unit.test.transforms.zlib ........................... Passed 2.60 sec
Start 50: _unit.test.transforms.zlib_body_appender
50/60 Test #50: _unit.test.transforms.zlib_body_appender ............. Passed 0.35 sec
Start 51: _unit.test.transforms.zlib_body_handler
51/60 Test #51: _unit.test.transforms.zlib_body_handler .............. Passed 0.11 sec
Start 52: _unit.test.encoders
52/60 Test #52: _unit.test.encoders .................................. Passed 0.01 sec
Start 53: _unit.test.from_string
53/60 Test #53: _unit.test.from_string ............................... Passed 0.04 sec
Start 54: _unit.test.websocket.parser
54/60 Test #54: _unit.test.websocket.parser .......................... Passed 0.00 sec
Start 55: _unit.test.websocket.validators
55/60 Test #55: _unit.test.websocket.validators ...................... Passed 0.00 sec
Start 56: _unit.test.ws_connection
56/60 Test #56: _unit.test.ws_connection ............................. Passed 4.66 sec
Start 57: _unit.test.file_upload
57/60 Test #57: _unit.test.file_upload ............................... Passed 0.00 sec
Start 58: _unit.test.basic_auth
58/60 Test #58: _unit.test.basic_auth ................................ Passed 0.00 sec
Start 59: _unit.test.bearer_auth
59/60 Test #59: _unit.test.bearer_auth ............................... Passed 0.00 sec
Start 60: _unit.test.socket_options_tls
60/60 Test #60: _unit.test.socket_options_tls ........................ Passed 0.02 sec
100% tests passed, 0 tests failed out of 60
Total Test time (real) = 32.93 sec
phase `check' succeeded after 33.0 seconds
With the local diff to enable the tests:
$ git diff
diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index e7ad1c5599..11540c90c6 100644
--- a/gnu/packages/networking.scm
+++ b/gnu/packages/networking.scm
@@ -3726,7 +3726,7 @@ (define-public restinio
(list
;; Multiple tests fail to run in the build container due to host name
;; resolution (see: https://github.com/Stiffstream/restinio/issues/172).
- #:tests? #f
+ #:tests? #t
#:configure-flags #~(list "-DRESTINIO_FIND_DEPS=ON"
"-DRESTINIO_INSTALL=ON"
"-DRESTINIO_TEST=ON"
And building the package with:
$ ./pre-inst-env guix build --with-branch=restinio=issue-172-workaround-1
Thanks for the investigation! Do you think such a workaround could be applied directly to restinio, or perhaps I should dig the root cause first ? (why asio can't resolve in the guix build container).
Hi! If you don't mind I would come back to this problem on Monday.
I'm not in a place to expect anything, having taken 4 months myself to produce feedback on your branch (sorry!) :-).
Hi!
Do you think such a workaround could be applied directly to restinio, or perhaps I should dig the root cause first ? (why asio can't resolve in the guix build container).
I think it's simple to apply this workaround to the RESTinio main development branch. I plan to do it today or tomorrow and then fix a version of RESTinio that contains this patch (it seems that it could be v.0.6.18.1).
I dug a bit on my side, and the implementation of resolve for POSIX/Unix in Asio appears to be:
// Resolve a query to a list of entries.
results_type resolve(implementation_type&, const query_type& qry,
asio::error_code& ec)
{
asio::detail::addrinfo_type* address_info = 0;
socket_ops::getaddrinfo(qry.host_name().c_str(),
qry.service_name().c_str(), qry.hints(), &address_info, ec);
auto_addrinfo auto_address_info(address_info);
return ec ? results_type() : results_type::create(
address_info, qry.host_name(), qry.service_name());
}
In its include/asio/detail/resolver_service.hpp
file, with socket_ops::getaddrinfo
being just the libc-provided getaddrinfo for that platform.
I also can reproduce the error simply with Guix with the following C++ bit of code, asio-resolve-in-guix-container.cpp
:
// Build with: g++ -O0 -g3 -lpthread asio-resolve-in-guix-container.cpp
#include <asio.hpp>
using asio::ip::tcp;
int main() {
asio::io_context io_context;
tcp::socket s{ io_context };
tcp::resolver resolver{ io_context };
tcp::resolver::query query { tcp::v4(), "localhost", "80" };
tcp::resolver::iterator iterator = resolver.resolve( query );
connect( s, iterator );
s.close();
}
E.g.,
$ guix shell -C asio gcc-toolchain bash -- sh -c 'g++ -O0 -g3 -lpthread asio-resolve-in-guix-container.cpp && gdb -ex "run;bt" ./a.out'
The following derivation will be built:
/gnu/store/yc3g641r30c7wq7b9xfbppkkgcav74a4-profile.drv
[...]
building profile with 3 packages...
terminate called after throwing an instance of 'std::system_error'
what(): resolve: Host not found (authoritative)
So the question I now have is: How could a minimal DNS resolver apparently always used by getaddrinfo be made to work in the Guix container, for resolving loopback domains such as "localhost" ?
So the question I now have is: How could a minimal DNS resolver apparently always used by getaddrinfo be made to work in the Guix container, for resolving loopback domains such as "localhost" ?
Sorry, I can't help here :(
No worries, I'll dig this on the Guix/glibc side of things. The change in restinio would be very welcome; as it enables running the full test suite without any glitch in a containerized environment. Thank you for working toward enabling that!
Hi! The changes is in the master branch.
Would it be OK for you if I create a tag with a name like 0.6.18-guix-workaround
(and without making of a separate release)?
All those changes will be a part of future release of RESTinio.
Sounds good! Don't worry about a custom tag; I can reference a direct commit in the package until the next release. Thanks again for working on this!
Hi, @Apteryks , there is a new tag: https://github.com/Stiffstream/restinio/releases/tag/v.0.6.18-guix-workaround
The restinio
package in Guix is now at 0.6.18-0.eda471e
and passes its whole test suite. Thank you for the fruitful collaboration! :-).
Hello,
When attempting to run the test suite of 0.6.15 on GNU Guix, it fails like so:
It seems most test fails due to failing to resolve the host name, although I only see localhost (127.0.0.1) being used, so it should work (there is networking support for the loopback interface in the Guix build environment).
Would you have any idea on how to make it work?
Thanks!