[users at i-scream] Cannot read file system stats
sno at NetBSD.org
Wed Apr 3 07:12:43 BST 2013
On 07.02.13 18:03, Tim Bishop wrote:
> On Thu, Feb 07, 2013 at 04:30:56PM +0100, Jens Rehsack wrote:
>> On 07.02.13 16:18, Tim Bishop wrote:
>>> On Thu, Feb 07, 2013 at 04:01:54PM +0100, Jens Rehsack wrote:
>>>> On 07.02.13 14:47, Tim Bishop wrote:
>>>>> I'm not aware of any packages. I'm also not too familiar with the debian
>>>>> package process, but I'd have thought the easiest starting point would
>>>>> be their package:
>>>>> And just make the change you need. The simplest change would just be to
>>>>> add ext4 to that define above.
>>>> I'm always open to help releasing a 0.18 - the way to the repositories
>>>> of the several distributions will make such a new release on it's own ;)
>>> Yes, we really should sort that out. It's been ages and I'm sorry for
>>> still not doing anything. Last I recall I wasn't happy that the code was
>>> in a releasable state, but I don't recall the details.
>> Problem was that I hacked a lot in configure.in and m4/ sources what
>> probably better was not in the repo - but hell, I'm not an autoconf
>> nor an m4 coder, I'm system developer and C developer (okay, and C++
>> and Perl). I would let the configure sources in a working state - and
>> maybe receive some feedback from other developers out there (or not
>> and when I find a tuit I improve it later).
> Yes, it's coming back to me now. It was the autoconf/m4 stuff that I was
> unsure about, and could work out how best to proceed with.
> So really that's the main sticking point. Making sure those changes to
> the build stuff are good. Then we can merge that branch and release
>>> If we can get that branch in to something that's sorted I'm happy to
>>> just release it. It's got to be better than doing nothing!
>> Beside the configure.in and m4/* content the sources are working
>> perfectly on any Unix except MacOS X. When you have some free
>> time (I know how time consuming a family is), I try to provide
>> all answers and fixes you need.
> Yes, I don't really have any issue with the sources themselves, just the
> build stuff around it. But them I'm not a strong C developer, so there
> could be things in there that I wouldn't even notice aren't right. I was
> hoping someone else might take a look at that part, but if nobody does
> we'll just go with what you've done.
>> BTW: Current customer let me enhance the memory manager in my
>> mega patch to allow several allocation stragegies per statistic
>> type and caching of results via mmap(2). It's far from being
>> finished, but maybe a nice feature for 0.19 ;)
> Yes, lets leave that until after the first lot are done ;-)
Just a minor ping before I forget it for the next months ...
What are the next steps? Who has which task (IIRC, I sent all requested
patches, it should be on you to merge ...)
BTW: You might think about a statgrab organization account on github
where all developers should be joined in so you're not the only one
who has to do the merger job ...
More information about the users