From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13082 Path: news.gmane.org!.POSTED!not-for-mail From: Christopher Friedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: Timeline for 1.1.20? Date: Sun, 29 Jul 2018 07:40:25 -0400 Message-ID: References: <20180716172023.GM1392@brightrain.aerifal.cx> <9155e3b7-6bbc-e9cc-331a-9514d18023c0@landley.net> <20180728195537.GZ1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1532864333 31475 195.159.176.226 (29 Jul 2018 11:38:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2018 11:38:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13098-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 29 13:38:49 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fjk2B-00084l-AO for gllmg-musl@m.gmane.org; Sun, 29 Jul 2018 13:38:47 +0200 Original-Received: (qmail 30470 invoked by uid 550); 29 Jul 2018 11:40:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30450 invoked from network); 29 Jul 2018 11:40:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ANwiDYY1Cr3ZBENt28/JTN1XSRFYU8cD3SDsfc5QjvI=; b=i5hPs/n3d3xQC9Tcvu6RTN0488hM+zlk1naKO1AXI6064Ej64s3fPWRPegnq27nctQ aTUQKEuiufZ6FXQV910Wx5XrneEUw0wK8mIjaeXuYBXQf5hp7FM/Fofg7J9qqZnFpimA O8n8KfCT5pkPTIX8H1skQZWqt2ZNeNJYyWLvRpe9fcVSwZApHRMUPShcKI77gWAiJPRx dFZQK8DhALhFMLZy3h4VJA1qjS2RUW+Rrs1s9IeaOAj/jB2l2QIgjgMsHaKJ31aLQth0 uGc9tu4nVxmZLoZeKY2M0KswxcwLCUdGjrt+juaTWqxv52BzBUDuraWSMfWN1vgRTybA IX4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ANwiDYY1Cr3ZBENt28/JTN1XSRFYU8cD3SDsfc5QjvI=; b=XyAcbl3aNdHMyfMoO+AczsKo6ulVKdlsJ1JHyrGNJhp46iKAJmF5Z8pXot/k70qoO8 WZOoY54rxc4IpKf2Vgc/+4ymAMqVO/oiK3YwuR9tsIyUply3rkj75KnZLQuvVOpdCfuS /qC722TN50nfXeV7LFJ4XKwr89T+qKSMGG6cmYebGqwpRwy2hxMzYgOzjqr/yVdx6pR1 j7dZGTFbAm7HvTJGydXVcujtdiUDwfyTSBPc2rWh4NprD8z3OiEU0zuZ+ykG2FIQ/yVb Y825QZnx/59rf0UQA5YfasTCO6MQ3svANPoROMbydY07JAZZIpQzXuiILL0j4uQUZJYz AHGA== X-Gm-Message-State: AOUpUlEtIDVTfkiMbxq7SnOBf7cyEzHyetcg97r9xOoFQN/oysNiuvpY uzs+Ifi6QuoJGyh6NfNjHm5j5/grKHc8wRJrgg6lQHjn X-Google-Smtp-Source: AAOMgpfb32hW2sQ9SRtpYPUM4qStiVq9xLOE5BV0yPoaiF1A4DqY52N7yC+CPc/pyDy5KBktr/CEeualoB3wEUPLi3E= X-Received: by 2002:aca:4d87:: with SMTP id a129-v6mr14872347oib.256.1532864436644; Sun, 29 Jul 2018 04:40:36 -0700 (PDT) In-Reply-To: <20180728195537.GZ1392@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13082 Archived-At: On Sat, Jul 28, 2018 at 3:55 PM Rich Felker wrote: > 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. I'll set up a .gitlab-ci.yml file - likely will use one 'pipelilne' to trigger other pipelines that exercise all combinations here: https://github.com/richfelker/musl-cross-make#supported-targets Speaking of which, one of my eventual use-cases is an rtos that uses the same syscall numbers as linux for each arch. Originally I was using bionic libc, but it's just difficult to maintain a permanent fork. Beyond syscall numbers, is there any specific reason that musl requires linux? > 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. Reports are useful. The fancy processes (automation, etc) just make life easier in the end and they're pretty easy to set up after one or two projects. I usually prefer to get it out of the way early. The low-hanging fruit. For unit testing, it's helpful to adopt a framework. gtest is good, although it assumes you have a working c++ compiler. I get that you want to keep libc-test and musl separate for now, but normally test code is part of the same repository as the source it's testing. Maybe consider that in the future. > 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 You've just listed off a number of work tickets ;-) I'll set something up and then show you the results - my server is limited in horsepower though, and (in terms of actual hardware), I'm limited to x86_64, arm64, arm32 (various arch versions), and a mips32. C