Bug#748567: FTBFS: 'top' unavailable

[Michael Tautschnig]

Hi Tony,

[...]
> That explains the problem.  It looks like your system has 256GB on it,

Yes :-)

> but the default for top is to display in KB, so the '+' (which indicates
> truncation) is tripping up the class that parses the output.
> 
> > KiB Mem:  26465643+total, 11191324 used, 25346510+free,  1385252 buffers
> > KiB Swap: 14483046+total,    40240 used, 14479022+free.  7171196 cached Mem
>                     ^
> 
> Currently, this test and class in general will fail on any system with
> more 96GB on it.  And it seems wrong to patch the code to just accept
> the truncated value. I don't see a way to set the scaling factor from
> the command-line invocation (and it introduces decimal points to the
> output anyway).  I don't have access to a system with that much memory
> on it (none of the public porterboxes appear to have more than 32GB),
> and am wondering if the -w (width) option will help.
> 
> If you are willing, the output of the following on your build system
> would helpful for creating a patch for large memory systems:
> 
> 	top -n1 -b -w256
> 
[...]

I did give this a try, but it has zero effect on the memory column, it seems
this is a fixed width column! (Reducing -w to something ridiculous like -w20
does have the expected effect.)

I'm afraid parsing the output of top is not going to get us anywhere here - why
does it have to be top after all? Wouldn't /proc/meminfo be much easier anyway?
(I don't see much portability with top after all...)

Best,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 859 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20140518/2fe98d8c/attachment-0001.sig>