these are pv's test results on an intel mac: >>> Test phase [check]: app-misc/pv-1.0.1 000-cat: FAILED 001-interval: OK 002-rate: FAILED 003-progress: OK 004-timer: OK 005-eta: OK 006-ratecount: OK 007-bytes: OK 008-numeric: OK 009-quiet: OK 010-dd: FAILED >>> Test phase [check]: app-misc/pv-0.9.9 000-cat: OK 001-interval: OK 002-rate: OK 003-progress: OK 004-timer: OK 005-eta: OK 006-ratecount: OK 007-bytes: OK 008-numeric: OK 009-quiet: OK 010-dd: FAILED >>> Test phase [check]: app-misc/pv-0.9.6 000-cat: OK 001-interval: OK 002-rate: OK 003-progress: OK 004-timer: OK 005-eta: OK 006-ratecount: OK 007-bytes: OK 008-numeric: OK 009-quiet: OK I talked to the developer a while back (the mails got lost somewhere though) and from what i remember test 10 would probably never pass on a mac. However, now the test results are getting significantly worse and 1.0.1 should probably be masked unless/until we find the test results can be ignored.
pv 1.0.1 is completely broken on x86-macos. I used the example from the homepage (see URL), only that I used a different file (3.3 GB bzip2 file). When I issue this command: % ./pv -cN source < ~/Desktop/sol-nv-b64a-x86-dvd.iso.bz2 | bzcat | \ pipe pipe> ./pv -cN bzcat | gzip -9 | ./pv -cN gzip > sol-nv-b64a-x86-dvd.iso.gz with pv 0.9.6 and 0.9.9 the output looks like this: source: 11.2MB 0:00:08 [1.85MB/s] [> ] 0% ETA 0:38:45 gzip: 11.8MB 0:00:08 [1.83MB/s] [ <=> ] bzcat: 102MB 0:00:08 [10.8MB/s] [ <=> ] and the resulting file is perfectly fine, whereas with pv 1.0.1 the command finishes immediately, the output looks like this: source: 384kB 0:00:00 [4.53MB/s] [> ] 0% and the resulting file is only garbage.
pv-1.0.1 masked for x86-macos in r8655[1]. [1] http://overlays.gentoo.org/proj/alt/changeset/8655
I like to remind you that you are using the ~x86-macos keyword. I disagree with the masking for that reason. If you want stable utilities, then it's better to start on a stable keyword.
since the utility is severely broken on OSX, it's ok to package.mask. However, a fix would be nice (of course I understand the limitations there)
(In reply to comment #3) > I like to remind you that you are using the ~x86-macos keyword. I disagree > with the masking for that reason. If you want stable utilities, then it's > better to start on a stable keyword. > Sorry, I don't understand what you're saying.
(In reply to comment #4) > since the utility is severely broken on OSX, it's ok to package.mask. However, > a fix would be nice (of course I understand the limitations there) > Is pv 1.0.1 broken on ppc-macos, too?
(In reply to comment #5) > (In reply to comment #3) > > I like to remind you that you are using the ~x86-macos keyword. I disagree > > with the masking for that reason. If you want stable utilities, then it's > > better to start on a stable keyword. > > > Sorry, I don't understand what you're saying. > I was basically not reading the full bug. But ~arch keywords are "unstable" keywords, having possible bugs, and not being tested and proven stable.
(In reply to comment #6) > (In reply to comment #4) > > since the utility is severely broken on OSX, it's ok to package.mask. However, > > a fix would be nice (of course I understand the limitations there) > > > Is pv 1.0.1 broken on ppc-macos, too? > I have no clue. Neither do I know if it's broken on Linux or Solaris.
the error occurs on ppc-macos, too, as I've just confirmed, so I'll move the mask up to the darwin level
please move it up to the macos level.
fixed in r8658[1] (by Andrew Wood upstream - thanks a lot!) [1] http://overlays.gentoo.org/proj/alt/changeset/8658
