guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#54036] [PATCH] gnu: gnunet: Update to 0.15.3.


From: Maxim Cournoyer
Subject: [bug#54036] [PATCH] gnu: gnunet: Update to 0.15.3.
Date: Tue, 22 Feb 2022 13:30:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi Tanguy,

Tanguy LE CARROUR <tanguy@bioneland.org> writes:

> Hi Maxim,
>
> Thanks for taking some time to review!
>
>
> Quoting Maxim Cournoyer (2022-02-21 22:23:28)
>> tags 54036 moreinfo
>
> "moreinfo" indeed! ^_^'
>
>
>> Tanguy Le Carrour <tanguy@bioneland.org> writes:
>> > The lint command reports problems that I don't know how and if I have to 
>> > fix:
>> >
>> > ```
>> > […]/gnu/packages/gnunet.scm:268:4: gnunet@0.15.3: label 'gnutls' does not 
>> > match package name 'gnutls-dane'
>> > […]/gnu/packages/gnunet.scm:268:4: gnunet@0.15.3: label 'libidn' does not 
>> > match package name 'libidn2'
>> > […]/gnu/packages/gnunet.scm:268:4: gnunet@0.15.3: label 'libjpeg' does not 
>> > match package name 'libjpeg-turbo'
>> > […]/gnu/packages/gnunet.scm:360:14: gnunet@0.15.3: permanent redirect from 
>> > https://gnunet.org/ to https://www.gnunet.org/en/
>> > ```
>> 
>> Running './pre-inst-env guix style gnunet' should take care of the first 3.
>
> It didn't scream `style` to me, but OK. I'll do that.

You'll find out that it doesn't rewrite the inputs as I'd hope, but you
could do so by hand (see:
https://guix.gnu.org/en/blog/2021/the-big-change/), which would take
care of the lint warnings.

[...]

>> > @@ -301,6 +301,8 @@ (define-public gnunet
>> >                (("test_transport_api_manipulation_cfg\\$\\(EXEEXT\\) 
>> > \\\\\n") "")
>> >                (("test_transport_api_udp_nat\\$\\(EXEEXT\\) \\\\\n") "")
>> >                
>> > (("test_transport_blacklisting_multiple_plugins\\$\\(EXEEXT\\) \\\\\n") 
>> > ""))
>> > +            (substitute* "src/cadet/Makefile"
>> > +              (("test_cadet_2_speed_reliable\\$\\(EXEEXT\\) \\\\\n") ""))
>> >              (substitute* "src/testbed/Makefile"
>> >                (("test_testbed_api_2peers_1controller\\$\\(EXEEXT\\) 
>> > \\\\\n") "")
>> >                (("test_testbed_api_statistics\\$\\(EXEEXT\\) \\\\\n") "")
>> > @@ -308,13 +310,24 @@ (define-public gnunet
>> >                (("test_testbed_api_test_timeout\\$\\(EXEEXT\\) \\\\\n") "")
>> >                (("test_testbed_api_topology\\$\\(EXEEXT\\) \\\\\n") "")
>> >                (("test_testbed_api_topology_clique\\$\\(EXEEXT\\) \\\\\n") 
>> > ""))
>> > +            (substitute* "src/testing/Makefile"
>> > +              (("test_testing_api_cmd_netjail\\$\\(EXEEXT\\) \\\\\n") "")
>> > +              (("test_testing_peerstartup\\$\\(EXEEXT\\) \\\\\n") "")
>> > +              (("test_testing_peerstartup2\\$\\(EXEEXT\\) \\\\\n") ""))
>> >              (substitute* "src/topology/Makefile"
>> >                (("^check_PROGRAMS.*") "\n")
>> >                (("test_gnunet_daemon_topology\\$\\(EXEEXT\\)\n") ""))
>> >              (substitute* "src/namestore/Makefile"
>> > -              (("\\$\\(am__append_2\\)") ""))
>> > +              (("\\$\\(am__append_2\\)") "")
>> > +              ((" test_namestore_lookup\\.sh ") " "))
>> > +            (substitute* "src/fs/Makefile"
>> > +              (("test_fs_search_with_and\\$\\(EXEEXT\\) \\\\\n") ""))
>> >              (substitute* "src/gns/Makefile"
>> > -              (("\\$\\(am__append_4\\)") ""))
>> > +              (("\\$\\(am__append_4\\)") "")
>> > +              (("test_gns_caa_lookup.sh test_gns_mx_lookup.sh") 
>> > "test_gns_caa_lookup.sh"))
>> > +            (substitute* "src/revocation/Makefile"
>> > +              (("^check_SCRIPTS.*") "")
>> > +              (("  test_local_revocation.py\n") ""))
>> >              (substitute* "contrib/Makefile"
>> >                (("^check_PROGRAMS.*") "\n"))
>> >              ;; 'test' from coreutils doesn't behave as the test expects.
>> 
>> These needs to be commented to show that we understand why they fail and
>> why it's OK/expected in our build environment.  If we don't understand
>> why we need to investigate more/seek support from the GNUnet authors so
>> that they can help us figure it out or fix real problems on their end.
>
> Actually, I had a ticket [1] open for the upgrade to 0.12.2 a year ago.
>
> [1]: https://bugs.gnunet.org/view.php?id=6114
>
> I'll have to update it and mention it in our package definition.
>
> Actually, I should try to enable the previously disabled tests see if
> they now pass, but… running GNUnet's tests is sooooo long!!!
>
> I'll keep you posted when I send the new patch!

*If* the reason these tests fail is because they rely on network, it'd
be best if upstream (the GNUnet team) could provide an easy way to opt
out of network-relying tests; we could open a ticket with them for that.

Thanks,

Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]