From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jeff King'" <peff@peff.net>
Cc: "'Junio C Hamano'" <gitster@pobox.com>, <git@vger.kernel.org>,
"'Linux Kernel'" <linux-kernel@vger.kernel.org>,
<git-packagers@googlegroups.com>
Subject: RE: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)
Date: Fri, 8 Feb 2019 13:47:04 -0500 [thread overview]
Message-ID: <002501d4bfde$b26e6050$174b20f0$@nexbridge.com> (raw)
In-Reply-To: <20190208180321.GB27673@sigill.intra.peff.net>
On February 8, 2019 13:03, Jeff King wrote:
> To: Randall S. Becker <rsbecker@nexbridge.com>
> Cc: 'Junio C Hamano' <gitster@pobox.com>; git@vger.kernel.org; 'Linux
> Kernel' <linux-kernel@vger.kernel.org>; git-packagers@googlegroups.com
> Subject: Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)
>
> On Fri, Feb 08, 2019 at 12:49:59PM -0500, Randall S. Becker wrote:
>
> > > We did discuss this at the time of the patch, but it seems we
> > > already use /dev/zero in a bunch of places:
> > >
> > >
> > > https://public-inbox.org/git/xmqqbm57rkg5.fsf@gitster-ct.c.googlers.
> > > com/
> > >
> > > Were you just skipping the other tests before?
> >
> > I did not catch the implications of the review at the time - my bad. We
> were not intentionally skipping the tests. It looks like some are automatically
> skipped. t4153 automatically skips (missing TTY), and t5562 fails also but for
> a different reason (hang - we don't have apache2 to serve up http content).
> >
> > Would you object to something like this:
> >
> > if [ ! -e /dev/zero ]; then
> > # use shred or some other mechanism (still trying to figure out a
> > solution) else
> > # existing dd
> > fi
>
> That's fine, as long as it's wrapped up in a function in order to keep the tests
> readable.
>
> Though I suspect we may be able to just find a solution that works
> everywhere, without having two different implementations. If we know we
> need $count bytes for dd, we could probably just generate a file with that
> many NULs in it.
For this, we could use truncate -s count file instead of dd to get a fixed size file of nulls. This would remove the need for /dev/zero in t5318 (the patch below probably will wrap badly in my mailer so I can submit a real patch separately.
@@ -383,7 +383,7 @@ corrupt_graph_and_verify() {
cp $objdir/info/commit-graph commit-graph-backup &&
printf "$data" | dd of="$objdir/info/commit-graph" bs=1 seek="$pos" conv=notrunc &&
dd of="$objdir/info/commit-graph" bs=1 seek="$zero_pos" count=0 &&
- dd if=/dev/zero of="$objdir/info/commit-graph" bs=1 seek="$zero_pos" count=$(($orig_size - $zero_pos)) &&
+ truncate -s $orig_size "$objdir/info/commit-graph" &&
test_must_fail git commit-graph verify 2>test_err &&
grep -v "^+" test_err >err &&
test_i18ngrep "$grepstr" err
This passes on my platform.
> Other cases don't seem to actually care that they're getting NULs, and are
> just redirecting stdin from /dev/zero to get an infinite amount of input. They
> could probably use "yes" for that.
What about reading from /dev/null?
Regards,
Randall
next prev parent reply other threads:[~2019-02-08 18:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 11:08 [Breakage] Git v2.21.0-rc0 - t5318 (NonStop) Randall S. Becker
2019-02-08 16:50 ` Jeff King
2019-02-08 17:49 ` Randall S. Becker
2019-02-08 18:03 ` Jeff King
2019-02-08 18:29 ` Johannes Sixt
2019-02-08 19:31 ` Junio C Hamano
2019-02-08 18:47 ` Randall S. Becker [this message]
2019-02-08 19:15 ` Jeff King
2019-02-08 19:26 ` Randall S. Becker
2019-02-08 19:31 ` Jeff King
2019-02-08 20:38 ` Randall S. Becker
2019-02-08 21:00 ` Jeff King
2019-02-08 21:44 ` Randall S. Becker
2019-02-08 22:07 ` brian m. carlson
2019-02-08 22:12 ` Randall S. Becker
2019-02-08 22:18 ` brian m. carlson
2019-02-08 22:36 ` Randall S. Becker
2019-02-08 22:35 ` Jeff King
2019-02-08 22:53 ` Randall S. Becker
2019-02-09 4:24 ` Jeff King
2019-02-09 8:39 ` Johannes Sixt
2019-02-09 16:55 ` Randall S. Becker
2019-02-09 23:29 ` Jeff King
2019-02-10 9:40 ` Johannes Sixt
2019-02-09 16:53 ` Randall S. Becker
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='002501d4bfde$b26e6050$174b20f0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git-packagers@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peff@peff.net \
/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.