mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Timeline for 1.1.20?
Date: Sat, 28 Jul 2018 15:55:37 -0400	[thread overview]
Message-ID: <20180728195537.GZ1392@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAF4BF-SJsSN-FZH3L7C9kcWnLznD_xc3JE_iFp8nqvm1A3=--w@mail.gmail.com>

On Sat, Jul 28, 2018 at 01:43:34PM -0400, Christopher Friedt wrote:
> Rich,
> 
> have you considered a CI environment of some kind (e.g. Travis, GitLab)?
> 
> GitLab is my favourite, particularly because it can be hosted locally (i.e.
> can interact with hardware if you so desire).
> 
> That means you can e.g. run quick unit tests inside of a Docker image for
> various arches, and then run integration & system tests natively before a
> release.
> 
> I'm particularly a big fan of the TDD approach, where unit tests are
> written and passing for new features (and unit tests continue to pass for
> old features) before a pull request is merge.

Yes, but I don't know how to set it up, and any proper approach to
setting it up really shouldn't require the project maintainer to know
how, since it should revolve around a separate CI project pulling
musl, libc-test, and possibly other sources (e.g. mcm) as either
subrepos or part of the build scripts, then evaluating the resutls.

As for the immediate need, though, it's *not* fancy CI processes but
actual test coverage. I'm really wary of projects that have fancy
process frameworks but nothing to show for it.

In particular, coverage for changes since 1.1.19 would include:

- getrandom/getentropy basic functionality check
- setvbuf non-stub inplementation: basic functionality, check for
  writes outside the buffer, etc.
- malloc interposition: check that partial replacement doesn't result
  in unsafe behavior.
- pthread_create: confirm that scheduling and other attributes still
  work as expected after refactoring work.
- getddrinfo AI_ADDRCONFIG (can't really be tested without network
  namespaces though)

Particular bugfixes that call for functionality or regression tests:

b123f23 fix getopt wrongly treating colons in optstring as valid option chars
0cf5058 fix nl_langinfo_l(CODESET, loc) reporting wrong locale's value
282b1cd fix fmaf wrong result
ae2a01d fix wrong result in casin and many related complex functions
10e4bd3 fix incorrect results for catan with some inputs
4bf0717 fix return value of nice function
3f6dc30 fix out of bounds write for zero length buffer in gethostname
9be4ed5 getopt_long_only: don't prefix-match long-options that match short ones
55a661f fix iconv buffer overflow converting to legacy JIS-based encodings
99f4237 fix iconv conversion to UTF-32 with implicit (big) endianness
165a1e3 fix iconv mapping of big5-hkscs characters that map to two unicode chars
029c622 fix output size handling for multi-unicode-char big5-hkscs characters
5c8e692 inet_ntop: do not compress single zeros in IPv6
8b8fb7f correctly handle non-matching symbols in dladdr
9cad27a fix writes outside buffer by ungetc after setvbuf
b3fa0f2 fix regression in alignment of dirent structs produced by readdir

Some fixes that would not be confirmed with just libc-test, but that
needs more of a framework for covering multiple build configurations:

a7c53e0 fix out-of-tree build of crt files with stack protector enabled
e3c682a work around arm gcc's rejection of r7 asm constraints in thumb mode

For now it will have to suffice that we tested them by hand at the
time of fixing.

Rich


  reply	other threads:[~2018-07-28 19:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11  7:17 ardi
2018-07-16 17:20 ` Rich Felker
2018-07-17  7:56   ` ardi
2018-07-28 17:22   ` Rob Landley
2018-07-28 17:43     ` Christopher Friedt
2018-07-28 19:55       ` Rich Felker [this message]
2018-07-29 11:40         ` Christopher Friedt
2018-07-29 15:49           ` musl "Linux-dependencies" info [was Re: [musl] Timeline for 1.1.20?] Rich Felker
2018-07-29 16:03           ` Timeline for 1.1.20? Rich Felker
2018-07-29 12:50         ` [RFC/RFT] musl: 1.1.20 prelease testing Christian Lamparter

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=20180728195537.GZ1392@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).