From: Florian <florhizome@posteo.net>
To: 60013@debbugs.gnu.org
Subject: [bug#60013] [PATCH 1/3] gnu: Add libmodule
Date: Tue, 13 Dec 2022 11:51:29 +0000 [thread overview]
Message-ID: <87tu1zr072.fsf@posteo.net> (raw)
In-Reply-To: <86tu20b2uu.fsf@gmail.com>
Hi all,
thanks for your comments.
A revamped patch-set should be on the way soon, depending mostly on
your's truly input on how to go on with the tests, but see below :)
T B-R: That's how it was! Although these days my mails were as fast as a
couple hours to appear on the mailing list, who could complain ;)
unmatched-paren: I checked the projects for configure flags before I
sent them. Unfortunately I am pretty sure, the remaining patches are not
avoidable, since the variables are set by cmakes pkg-config
queries, but correct me if wrong! I am no expert in any build system,
but these things are often detectable I think :). (btw if there was an effort to write a blog post to document
problems for nix/guix packaging, the use of pkg-config queries those should be explicitly
mentioned, it's a pest!).
About tests:
I also can't find any tests in clight and clightd's repos. At least for
libmodule I found how to build and enable tests
https://github.com/FedeDP/libmodule/tree/16435d57b7600610313dc21301f3b5717480a3a8/tests
So by setting this flag and packing valgrind and cmocka into
'native-inputs', two tests will be built and run. The one using valgrind
will fail though:
starting phase `check'
Running tests...
/gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4/bin/ctest --force-new-ctest-process
Test project /tmp/guix-build-libmodule-5.0.1.drv-0/build
Start 1: ModuleTest
1/2 Test #1: ModuleTest ....................... Passed 1.21 sec
Start 2: ModuleTest_valgrind
2/2 Test #2: ModuleTest_valgrind ..............***Failed 0.02 sec
==258== Memcheck, a memory error detector
==258== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==258== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==258== Command: ./ModuleTest
==258==
valgrind: Fatal error at startup: a function redirection
valgrind: which is mandatory for this platform-tool combination
valgrind: cannot be set up. Details of the redirection are:
valgrind:
valgrind: A must-be-redirected function
valgrind: whose name matches the pattern: strlen
valgrind: in an object with soname matching: ld-linux-x86-64.so.2
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
valgrind: that exports the above-named function using the standard
valgrind: calling conventions for this platform. The package you need
valgrind: to install for fix (1) is called
valgrind:
valgrind: On Debian, Ubuntu: libc6-dbg
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind: Note that if you are debugging a 32 bit process on a
valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo
valgrind: package (e.g. libc6-dbg:i386).
valgrind:
valgrind: Cannot continue -- exiting now. Sorry.
50% tests passed, 1 tests failed out of 2
Total Test time (real) = 1.23 sec
And I'm not sure how to help with that. including (list glibc "debug")
didn't do it. Do we need really need this test?
The next question is then if the tests that are automatically run are
those mentioned in the README on the projects wiki (see url
above). Chime-in!
zimoun: I think I have been leaving that indentation after (description
in everything I contributed so far. I seriously hope I don't need to rework all of
those just for that. But for the future, I know now ;)
These also would be those "prerequisite-patch-ids" hanging around, that
are generated by the --base=auto flag I use with git send-email like a
good manual follower. I don't want to operate on multiple guix repos or branches, I find
the workflow to keep one updated time-consuming enough so far... So I
guess, to be frank, what can I actually do about that?
Side Note: Of course this list would become smaller the more previous patches are
actually merged *cough cough* most of whom are simple, one-hunk patches
that should require the least amount of time :)
next prev parent reply other threads:[~2022-12-13 11:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-12 16:53 [bug#60013] [PATCH] gnu: Add clight Florian
2022-12-12 19:16 ` zimoun
2022-12-12 20:51 ` Tobias Geerinckx-Rice via Guix-patches via
2022-12-12 20:31 ` [bug#60013] [PATCH 1/3] gnu: Add libmodule florhizome
2022-12-12 20:31 ` [bug#60013] [PATCH 2/3] gnu: Add clightd florhizome
2022-12-12 21:53 ` ( via Guix-patches via
2022-12-12 20:31 ` [bug#60013] [PATCH 3/3] gnu: Add clight florhizome
2022-12-12 21:57 ` ( via Guix-patches via
2022-12-12 21:00 ` [bug#60013] [PATCH 1/3] gnu: Add libmodule ( via Guix-patches via
2022-12-12 23:48 ` zimoun
2022-12-13 11:51 ` Florian [this message]
2022-12-15 11:31 ` zimoun
2022-12-20 16:33 ` Florian
2022-12-21 11:22 ` ( via Guix-patches via
2022-12-30 12:45 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tu1zr072.fsf@posteo.net \
--to=florhizome@posteo.net \
--cc=60013@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).