Bug#819503: --buffer-size does not affect read buffer size

2016-08-31 Thread Andrew Wood
s like --buffer-size does not do what I would have expected: [...] -- Andrew Wood

Bug#839796: Ability to specify size for --skip-errors

2016-10-20 Thread Andrew Wood
Severity: wishlist > [...] > So really it seems like -E ought to just skip 4k at once. > > Or at least there ought to be an option to specify the skip size. I'd > suggest -E should take an optional argument, the skip size, and default > to 4k. -- Andrew Wood

Bug#842978: pv FTCBFS: uses build architecture ld

2016-11-16 Thread Andrew Wood
oach could be linking with > > $CC rather than $LD as autotools supply a suitable $CC. If this change > > works natively, it'll also work for cross compilation. > > Thank you for the clarifications. > > I guess the next step is whether there should be a patch sent upstream, > what do you think? If you've got a patch I would gladly receive it - thanks. -- Andrew Wood

Bug#819503: --buffer-size does not affect read buffer size

2017-06-23 Thread Andrew Wood
on input), then one huge or several consecutive smaller write > operations. > > > In fact, I am not sure I understand what --buffer-size does at all. :) > > Add me. > > Some light to shed on this? -- Andrew Wood

Bug#839796: Ability to specify size for --skip-errors

2017-06-23 Thread Andrew Wood
s at the beginning of a block. So with > > "-E 4k", an error at 2k would skip to 4k, an error at 4k would skip to 8k, > > and so on. > > > > Does this seem reasonable? > > That sounds reasonable. Sensible, even. -- Andrew Wood

Bug#890901: multiple pv -c : terminal left in -icanon -echo tostop

2018-02-20 Thread Andrew Wood
d a work-around exists: just enclose the pipe containing pv > into stty_g=$(stty -g); pipe | goes | here; stty $stty_g > as I did in my reproducer above, > so "don't panic" ;-) > > But maybe you can find a nice place to add this in? > Or document the problem and the workaround? > > Cheers, > > Lars > > This mail was also sent > To: p...@ivarch.com, andrew.w...@ivarch.com > Date: Sat, 10 Feb 2018 19:07:42 +0100 > Subject: multiple pv -c : terminal left in -icanon -echo tostop > Message-ID: <20180210180728.GH19196@soda.linbit> -- Andrew Wood

Bug#920225: pv: replace ash shell with dash

2019-02-10 Thread Andrew Wood
suggestions. Don't expect a response immediately, however, they take > their time, which is fine. :) -- Andrew Wood

Bug#961370: pv: ETA is wildly off when transfer rate changes

2020-06-28 Thread Andrew Wood
> that to compute current average rate for ETA. Looks like it works pretty > well in this case. Also added a --rate-window option to change time window > (default: last 10s) (name isn't great, maybe could find a better one). -- Andrew Wood

Bug#1054018: splint: Segmentation violation in transferChecks.c

2023-10-15 Thread Andrew Wood
Package: splint Version: 1:3.1.2+dfsg-5 Severity: normal Dear Maintainer, I have been using splint to clean up the PV code[1], and after restructuring src/pv/display.c, found that splint now exits with a segmentation violation when processing that file: *** Segmentation Violation ***

Bug#1054018: Acknowledgement (splint: Segmentation violation in transferChecks.c)

2023-10-15 Thread Andrew Wood
hose local variable declarations out to the block enclosing the "switch" (line 769) stops splint from crashing out. So it was local variable declarations inside a "case" statement that were triggering the fault. -- Andrew Wood

Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf

2024-01-12 Thread Andrew Wood
valgrind itself behaves on that architecture. -- Andrew Wood