Hi,
On Dienstag, 26. Februar 2013, Andreas Beckmann wrote:
I'm primarily concerned about reimplementing a bad piece of code (the
second half of dwke that creates the .tpl files) in order to build a new
feature on top of it. The perfectionist in me would like to fix things
properly first.
On 2013-02-25 20:24, Dave Steele wrote:
On Mon, Feb 25, 2013 at 8:45 AM, Andreas Beckmann a...@debian.org wrote:
In general I think we should allow the flexibility to have a per-section
known-problems-directory setting, so each report Section should generate
its own problem list and not get a
On Tue, Feb 26, 2013 at 5:50 PM, Andreas Beckmann a...@debian.org wrote:
In branch report-problem_integration you have
4db22544 piuparts-report - add known Problems class list to Section.
That should be dropped, ...
This is where we have been talking past each other for the last week.
That
another random bit I just stumbled upon:
- if (state == failed-testing and template[-9:] != issue.tpl) \
- or (state == successfully-tested and template[-9:] ==
issue.tpl):
+ if (state == failed-testing and problem.short_name[-5:] !=
issue) \
+ or
On Mon, Feb 25, 2013 at 8:45 AM, Andreas Beckmann a...@debian.org wrote:
In general I think we should allow the flexibility to have a per-section
known-problems-directory setting, so each report Section should generate
its own problem list and not get a global one passed
OK, but out of
Hi Dave,
On Samstag, 23. Februar 2013, Dave Steele wrote:
I've reworked based on Andreas' issues related to
detect_well_known_errors and rdeps.
thanks! (extra bonus points if you could tell how many commits it are in each
branch, due to rebase its rather easy for me to find out, but becoming
On Sat, Feb 23, 2013 at 5:40 AM, Holger Levsen hol...@layer-acht.org wrote:
extra bonus points if you could tell how many commits it are in
each branch, due to rebase its rather easy for me to find out, but becoming
this told would be even better ;)
As I have been keeping up with the changes
Hi,
On Samstag, 23. Februar 2013, Dave Steele wrote:
Ok. It would have been easier for me if this had been established
before you asked for my rebase.
I believe Andreas should be done (with his current batch) soon.
cheers,
Holger
On Fri, Feb 22, 2013 at 6:43 AM, Andreas Beckmann a...@debian.org wrote:
On 2013-02-22 01:58, Dave Steele wrote:
Concerning what is currently in Holger's queue:
I've reworked based on Andreas' issues related to
detect_well_known_errors and rdeps. Comments related to piupartslib
and
[ Hint: While replying to the BTS, delete the [Piuparts-devel] marker
from the subject as well as any duplicate bug numbers. ]
On 2013-02-21 03:09, Dave Steele wrote:
On Wed, Feb 20, 2013 at 8:42 PM, Dave Steele dste...@gmail.com wrote:
On Mon, Feb 18, 2013 at 5:44 AM, Holger Levsen
+if self.inc_re.search( logbody, re.MULTILINE ):
+for line in logbody.splitlines():
+if self.inc_re.search( line ):
+if self.exc_re == None \
+ or not self.exc_re.search(line):
+
On Thu, Feb 21, 2013 at 4:24 AM, Andreas Beckmann a...@debian.org wrote:
this work looks really promising and I'm curious to try it some day on
my instance.
But as I wrote before there is no need to reimplement the .tpl
generation in python. Instead these intermediate files should go away
On Thu, Feb 21, 2013 at 5:02 AM, Andreas Beckmann a...@debian.org wrote:
+if self.inc_re.search( logbody, re.MULTILINE ):
+for line in logbody.splitlines():
+if self.inc_re.search( line ):
+if self.exc_re == None \
+
On 2013-02-21 16:35, Dave Steele wrote:
The MULTILINE search is pure optimization - it can be remove with no
change to the results. DOTALL is off to match grep.
OK, I didn't realize that the outer search is just for optimization.
There simply aren't enough failure cases (even in 62 sections
On Mon, Feb 18, 2013 at 5:44 AM, Holger Levsen hol...@layer-acht.org wrote:
...
these are quite some different changes, can you please isolate the commits for
Sort known issues by reverse dependency count and rebase them onto current
develop?!
The new serial branches sort-issues-by-rdep and
On Wed, Feb 20, 2013 at 8:42 PM, Dave Steele dste...@gmail.com wrote:
On Mon, Feb 18, 2013 at 5:44 AM, Holger Levsen hol...@layer-acht.org wrote:
...
these are quite some different changes, can you please isolate the commits
for
Sort known issues by reverse dependency count and rebase them
Hi Dave,
On Sonntag, 27. Januar 2013, Dave Steele wrote:
The rest of my proposed changes for known problem handling are pushed,
for review.
A rebase is needed before merging. I will do this at your request.
The following serial branch heads are involved:
well-known - I've added
The rest of my proposed changes for known problem handling are pushed,
for review.
A rebase is needed before merging. I will do this at your request.
The following serial branch heads are involved:
well-known - I've added tolerance for missing files and packages, and
added PTS links
On 2013-01-20 04:02, Dave Steele wrote:
Yes, but it would involve duplicating a bit of code from
piuparts-report. What are you thinking, replace e.g.
pass/python-support_1.0.15.log with pass/python-support_1.0.15, and
link to the source page instead of the log?
I just want to extend the
Hi,
On Samstag, 19. Januar 2013, Andreas Beckmann wrote:
Without having looked at the code yet, I like the idea
:-)
same here :)
Now that you have access to the package DB, can you
add a PTS link for
each failing package? These need to be src based ...
I'd prefer this as well...
Hi,
thinking about this again, there are currently two tasks performed by
detect_well_known_errors:
1. generating .kpr files
2. generating .tpl files
(1) is the really time comsuming part and needs to be run independently
from piuparts-report from time to time (with the recheck options ...),
so
On Sun, Jan 20, 2013 at 6:56 AM, Andreas Beckmann deb...@abeckmann.de wrote:
...
What I'd like to see is (in probable order of implementation)
* piuparts-report discovering all existing known problem descriptions
instead of hardcoding them
- need to add ordering information somehow, perhaps
Package: piuparts
Severity: wishlist
Tags: patch
thanks
Packages with high reverse dependency counts can cause known problem
issue lists to balloon. Providing rdep visibility in the issue report
can highlight these problems, making it much easier to pare the list
down.
The well-known git branch
On 2013-01-19 22:06, Dave Steele wrote:
The well-known git branch implements a version of
detect_well_known_errors to accomplish this. The script is ported from
bash to python, to take advantage of the rdep capability of
piupartsdb. It was developed alongside the bash script to support
On Sat, Jan 19, 2013 at 5:19 PM, Andreas Beckmann deb...@abeckmann.de wrote:
On 2013-01-19 22:06, Dave Steele wrote:
...
Now that you have access to the package DB, can you add a PTS link for
each failing package? These need to be src based ...
Yes, but it would involve duplicating a bit of
25 matches
Mail list logo
