From: Petr Vorel <petr.vorel@gmail.com>
To: Romain Naour <romain.naour@gmail.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [RFC][PATCH 1/1] package/glibc: bump version to 2.34-5-g9995d0588f4f9adc68419224d2b3698e2ca4f77e
Date: Wed, 18 Aug 2021 23:53:55 +0200 [thread overview]
Message-ID: <YR2Bc4t7UMIDUhgb@pevik> (raw)
In-Reply-To: <e85b8610-6f8c-c581-138a-a73d6131f521@gmail.com>
Hi Romain,
> Hello,
> Le 04/08/2021 à 21:30, Thomas Petazzoni a écrit :
> > Hello Petr,
> > On Wed, 4 Aug 2021 19:22:59 +0200
> > Petr Vorel <petr.vorel@gmail.com> wrote:
> >> Also upgrade to on RISC-V (that could have been done in d5ce3b5db5)
> >> Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
> >> ---
> >> Hi,
> >> I tested it with building pc_x86_64_efi_defconfig, adding nfs-utils,
> >> ltp-testsuite and few other tools. Not sure if this is enough for
> >> testing.
> > I think that what Romain Naour typically does is run all qemu_*
> > defconfigs (of course tweaked to use glibc instead of uclibc), and push
> > them to Gitlab, so that they get build tested *and* boot tested under
> > Qemu.
> Indeed, the runtime test is only a boot test. I've looked at the glibc testsuite
> but it's difficult to setup with a cross-compiled system running under Qemu in a
> CI (glitlab).
I hoped there would be some setup ready, but understand there is nothing.
> For testing, upstream suggest to use a NFS to share the glibc sources between
> the host and the target (not very handy):
> https://sourceware.org/glibc/wiki/Testing/Testsuite
Indeed not very handy.
> Some tests requires a minimal amount of RAM that is not always provided by Qemu
> target.
> There is also libc-test project from musl project:
> https://wiki.musl-libc.org/libc-test.html
Interesting, although not sure how relevant is for glibc (would require to
compare with old release).
> Indeed running some tests from ltp-testsuite would be better than nothing.
> On the other hand we can detect enough boot issue related to toolchain upgrade
> to keep us busy.
Thanks for all suggestions. I'm not sure when I get to it, but the max which
time allows will probably be just to boot with qemu and run LTP syscalls.
Kind regards,
Petr
> Best regards,
> Romain
> > Thomas
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
next prev parent reply other threads:[~2021-08-18 21:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 17:22 [Buildroot] [RFC][PATCH 1/1] package/glibc: bump version to 2.34-5-g9995d0588f4f9adc68419224d2b3698e2ca4f77e Petr Vorel
2021-08-04 19:30 ` Thomas Petazzoni
2021-08-18 19:46 ` Romain Naour
2021-08-18 21:53 ` Petr Vorel [this message]
2021-08-21 13:26 ` Romain Naour
2021-08-22 18:19 ` Petr Vorel
2021-08-04 21:35 ` Alistair Francis
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YR2Bc4t7UMIDUhgb@pevik \
--to=petr.vorel@gmail.com \
--cc=buildroot@buildroot.org \
--cc=fido_max@inbox.ru \
--cc=romain.naour@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.