[Piuparts-devel] What are we optimizing for? (cf. dwke + -report)
anbe at debian.org
Fri Feb 22 11:43:45 UTC 2013
On 2013-02-22 01:58, Dave Steele wrote:
> Concerning what is currently in Holger's queue:
> After our discussion, do you have any current concerns with
> sort-issues-by-rdep, as a drop-in replacement for
>+ or (ctime(logdict[pkgspec]) > ctime(cachedict[pkgspec])
You want os.path.getmtime() here. ctime is inode change (c=change, not
c=creation!) time, updated e.g. every time we hardlink the logfile to
htdocs/ or recycle/
You introduce two classes Problem (I'd probably call it KnownProblem)
and FailureManager, that should probably go to piupartslib/
And I would restrict the keys accepted while parsing a
known_problem.conf to a predefined list.
create_problem_list should probably be a library function, too
x.endswith(".conf") should be equivalent to and faster as
Problem.has_problem() should be postponed to a second commit.
And with these two classes it should be possible to generate the .tpl
inside piuparts-report (and write out the full page immediately), still
using the hardcoded list of problems found there ...
That should be easier because most of the infrastructure should already
Then we can just remove that part from the shell script. It's not a bash
script (as in it "requiring bash-specific extensions").
Adding rrdeps sorting at that point should be easy as well.
> Given sort-issues-by-rdep, should sort-issues-by-rdep-fast be
> considered as a stand-alone patch set?
I'd prefer s/INCLUDE/PATTERN/ or s/INCLUDE/REGEX/
There is no need to generate an exact grep command line - just
presenting the pattern properly is enough. (And it should be usable for
And rename the branch to something more descriptive like
parse-logfiles-with-python-re (but of course leave it on top of the
Anyway, that should be the base for any improvements to logfile parsing.
More information about the Piuparts-devel