[Rpm-metadata] createrepo: huge memory consumption?

[Ryan Lynch]

On Mon, Aug 24, 2009 at 11:33, Seth Vidal <skvidal at fedoraproject.org> wrote:

>
> On Mon, 24 Aug 2009, Ryan Lynch wrote:
>
>  On Mon, Aug 24, 2009 at 10:54, Seth Vidal <skvidal at fedoraproject.org>
>> wrote:
>>
>>      On Mon, 24 Aug 2009, Ryan Lynch wrote:
>>            BTW: I have a couple of patches, now, that I wrote while trying
>> to
>>            log, parse, and handle 'cobbler reposync' with large numbers
>>            directories. One affects output formatting, to make logging and
>>            parsing easier, and the other helps to handle an annoying
>> error:
>>
>>            Any interest in either of these functions?
>>
>>
>> possibly, but send them over on yum-devel list - since they aren't related
>> to createrepo.
>>
>>
>>  I wasn't too clear, there, or maybe I'm misunderstanding how the codebase
>> is structured.  These are patches against
>> createrepo, itself, not reposync.  (That's a whle 'nother Oprah--I have
>> some local tweaks to that stuff, too.)
>>
>> My changes affect these two files:
>>
>>  * /usr/lib/python2.6/site-packages/createrepo/__init__.py
>>  * /usr/share/createrepo/genpkgmetadata.py
>>
>> The way these are packaged under F10/F11, they're part of the 'createrepo'
>> package.  I assumed the distinction held,
>> upstream.  Am I wrong about that?
>>
>>
> if they are to createrepo then send the patches and we'll have a look.


I've been making one-off patches, locally, which I don't think you want.
I'll clone the git repo, tonight, and do it the right way.


wrt to the logging output one - you know about createrepo -v, right


I do. '--verbose' addresses a slightly different issue (debugging), I
think.  My issue relates to logging the normal, non-verbose output.  The
terminal-control trick (writing a line of '\r' chars to stdout) complicates
logging and parsing the output.

-R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/rpm-metadata/attachments/20090824/726340b5/attachment.htm>