Posts Tagged ‘reportbug-ng’

Porting rng to QT4

Sunday, July 13th, 2008

Today I was busy porting reportbug-ng to QT4. One really cool thing I noticed is the new QWebView widget, which is the main widget of the QWebKit module. It works surprisingly easy compared to the good old QTextBrowser of QT3 — now you can just throw an URL at it and it will render the page nicely complete with CSS, images, etc.

Here’s the obligatory screenshot:

reportbug-ng qt4

as you can see, the bugreport looks much better than in the old version of rng. WebKit does a really good job rendering the HTML, I think the fonts look even smoother than under firefox.

To ease the transition to from QT3 to QT4 I’ve extracted all the Debian BTS specific stuff to python-debianbts and uploaded it to unstable. Rng uses it to query our Bug Tracking System via it’s SOAP interface and get the data in Python’s native data types.

There is still the problem with rng (QT3) crashing when showing bugreports. I’ve investigated the problem a bit and found out that it is not rng’s fault but probably a problem with python-qt3 or one of it’s underlying libs. QTextBrowser causes segfaults in nearly 50% of the cases where you try to render html from a different thread: here’s an easy way to reproduce:

# crash.py
# Usage: python crash.py "some text"
#        python crash.py "some evil html”

from qt import *
import sys
import threading

class Form(QMainWindow):
    def __init__(self,parent = None,name = None,fl = 0):
        QMainWindow.__init__(self,parent,name,fl)
        self.browser = QTextBrowser(self, “browser”)
        self.setCentralWidget(self.browser)

if __name__ == ‘__main__’:
    if len(sys.argv) < 2:
        print 'Usage: %s "some text"' % sys.argv[0]
        sys.exit()
    s = str(sys.argv[1])

    # setup qt stuff with a browser
    app = QApplication(sys.argv)
    app.connect(app, SIGNAL("lastWindowClosed()"), app, SLOT("quit()"))
    form = Form()
    app.setMainWidget(form)
    form.show()

    # start a different thread and try to set the text in the browser
    # we wait 1.0 second -- just to make sure the change happens after the
    # start of app.exec_loop() below
    t = threading.Timer(1.0, form.browser.setText, (s, ))
    t.start()

    app.exec_loop()

QWebView doesn’t seem to have this problem, the QT4 version of rng didn’t crash a single time.

I’m not quite ready with the porting to QT4, and since I’ll be quite busy during the next weeks I suppose it will take a few weeks until the new version will be updated to unstable.

Segfaults Everywhere

Monday, July 7th, 2008

Dear Lazyweb,

A few weeks ago rng started to show some segfaulty behavior. I’ve absolutely no idea what’s going on, since Python code usually doesn’t segfault. I guess the problem lies in the qt3-bindings rng uses — does someone know how to verify this?

There is a backtrace which seems to show that the problem lies somewhere in /usr/lib/python2.5/site-packages/qt.so but I’m not entirely sure how to interpret that.

Lenny won’t ship rng

Monday, June 9th, 2008

Philipp thinks, the fact that rng is not using the information in /usr/share/bug renders rng “unfit for release” and upgraded the corresponding bugreport from wishlist to serious. Moreover: since I dared to downgrade the report back to wishlist he decided to remove rng from testing and block it until the bug is fixed.

I don’t want to heat the debate about this bug again, but Philipp’s decision seems arbitrary for me and I wonder if the same standard is applied to every other Debian package. I mean, rng has no release critical defects. It just does not use the aforementioned scripts as additional information in bugreports — does this really render the software “unfit for release”? For example: In Etch we shipped a famous email client with a known bug which lead reproducibly to loss of emails on IMAP accounts, just because removing the program, or one of it’s components was not possible in the remaining time.

Happy Birthday rng!

Thursday, March 27th, 2008

Hmm, better late then never, I guess. One year and two weeks ago, reportbug-ng was initially uploaded to Debian unstable. Happy birthday rng! I wish you a lot of ponies in the next year!

On #422085 and #417256

Tuesday, December 18th, 2007

Since I received a terrifying amount of insults via mail for not implementing this feature request after my last blog entry, where I asked for help developing rng, I’d like to make my position about this issue clear.

Why I was opposed to implement it:

  1. I personally hated that some packages sent a huge amount of unrelated info with every bugreport for this package, even if it’s not meaningful for this bugreport. I made a quick check against my favorite package with a very long output and thought (and still think) that this info is not even relevant for the majority of bugreports of this package. So I thought it was not too much to ask, to write the reporter a friendly mail to post the output of this script, if it’s really needed.
  2. I was personally very annoyed by packages with very long presubj text, which I doubt anyone reads anyway. Since I don’t want rng to be annoying to the users, I decided to leave that feature away. An implementation of this feature would mean to pop up a window with some text the user should read before continuing to report the bug. I don’t like popups and don’t want rng to make use of them.
  3. I’m definitely opposed to a feature which will pop up a terminal where a user has to do something before he can proceed reporting a bug. Sorry, but this won’t happen in rng. I might consider such a thing if it could be scripted to use QT or even GTK but a terminal popping up in a GUI application is a no-go for me, sorry.
  4. I was personally very annoyed by some of the reactions on this bugreport. Since we’re all volunteers and stuff and this feature is maybe a nice-to-have but definitely not a must-have, I decided to put this issue very low on my to do list.

However, I agree that the stuff in /usr/share/bug isn’t completely useless. The opposite is true, it makes the life of maintainers easier and rng should make use of it where possible.

So what can we do now? Maybe we can start all over and discuss this issue in a more friendly and constructive way?

Here’s my offer: rng will support bugscripts, but it will not feature a terminal popping up asking a user questions. I’m developing a GUI application and a popping up terminal is not very GUI’ish for me. What can we do about this? Is there a way to implement this?

Supporting presubj might be okay too, but I don’t want rng to be annoying. Popups are annoying and having to read the same stuff again and again when reporting multiple times on the same package is annoying too. Maybe rng could spawn a pop up with a checkbox “Don’t show this text again when reporting a bug against this package”? Maybe we could have an option in the (not yet implemented) preferences window where we could suppress those messages completely?

And please, don’t use abusive language or even insults when contacting me about this issue. My rng-time is currently very limited and my motivation to work especially on this issue is already very low. We’re speaking here about a fully optional feature. Providing the output of some scripts or having to read a presubj is helpful, but not mandatory when reporting a bug. So please, be nice! I really don’t need all that stress right now.

Want to get money for nothing and chicks for free, too?

Saturday, December 8th, 2007

Is anyone out there interested in helping me developing reportbug-ng? I’m currently very busy with my diploma thesis and can’t spend as much time on my pet bug reporting tool as I’d like to spend. The package itself has some small bugs, is not yet feature complete, but in a fairly good shape and quite popular too.

If you’re interested you should have experience with python, QT and maybe some SOAP-skills. You don’t have to be a Debian Developer or -Maintainer!

I haven’t done this before so I don’t know that the best practice for such a situation is. I’m currently thinking of something like:

  1. First you send me patches, which I’ll review, apply and upload
  2. After a while you get write access to the BZR repo
  3. Finally become co-maintainer of the package if you want

Interested? Then write me a mail to: venthur at debian org.

Oh, and please don’t write if you just want to get your pet-bug-which-I-still-refuse-to-fix fixed.

PS: If you prefer guys over chicks, you’re welcome too ;)

Deserializing SOAP replies with ZSI?

Monday, August 20th, 2007

Dear Lazyweb,

what is the most elegant way to read a SOAP reply containing a complex type into an object using ZSI? I’ve read the documentation several times and I guess there is an elegant way to solve this, but I still don’t get it.

I guess it should work like this:

  • Define a class Bugreport
  • Define Bugreport’s typecode
  • Parse (how?) the SOAP reply containing bugreport-data into a Bugreport object

What I’m currently doing with soappy in rng is rather crude: I take the SOAP response which is a dictionary holding many interesting facts about a bug report, take those elements I’m interested in and copy them into a bug report object. Not very elegant, but it works.

While I’m moving away from soappy to ZSI I’d like to implement the deserializion the ZSI way. Unfortunately I don’t understand their examples. So please Lazyweb, is there any ZSI expert out there who can provide a minimalistic example?

Rng and others temporary broken

Friday, August 10th, 2007

Just a short note to let you know that due a change in debbugs’ SOAP interface several applications including apt-listbugs and rng are temporary broken. The change was not too dramatic and I suppose the problem will be fixed shortly. Meanwhile you can use reportbug which is not affected, since it still uses the HTML interface.

Update: Don fixed the problem and everything should be working as usual again.

Implement two features and get the third for free!

Friday, August 3rd, 2007

Today I’ve implemented a feature which was long overdue: making the table sortable by the available table headers. The second feature I’ve added is that every bug report now has it’s “Last Action” date. While both features are useful for themselves, combining both result in a very handy bug triaging tool.

screenshot.png

A few months ago when I was trying to help the KDE team on their bug triage, I’ve missed the feature to sort bugs by their date of the last action in our BTS since I’ve noticed that many of the very old bugs (last action-, not bug number wise) where already fixed or could be closed for other obvious reasons. The problem was just to find all those “stale bugs”. I was able to close dozens of old bug reports but it took much more time to find them, than to decide whether they’re still active or not. And since I hadn’t the tools available to find the “easy targets” on a quick way, I gave up after a few days.

Today it’s just as easy as firing up rng and let it search for all bug reports belonging to the qt-kde team:

rng debian-qt-kde@lists.debian.org

and sorting the resulting list by last action… sweet!

The package was just uploaded and should be available tomorrow.

Update: Don pointed out that you can get the ordering in the web interface too by appending ordering=age to the URL. Neat.

Improved filtering for rng

Wednesday, July 18th, 2007

I’ve just uploaded a new version of reportbug-ng including an Italian and a Hebrew pony and a cool enhancement to the buglist filter: Now the filter doesn’t try to match the whole string anymore but splits the input by whitespaces and tries to match all words. Now you can even exclude words by prepending a leading minus to it.

The Syntax for the filter is: [-]keyword [[-]keyword2] …

Multiple keywords are separated by whitespaces and can have a leading minus. A leading minus means “exclude” the whitespaces represent the logical AND.

Some Examples:

  • foo bar -baz means all bugs containing the words foo, bar and not baz
  • outstanding -wishlist means all bugs which are outstanding and not wishlist
  • -resolved will show all open bugs

Please note the the filter does look into the actual bugreports (the fulltext), it currently tries to match against the packagename, the bugnumber, the summary, the status and the severity.

The best thing about this new filter? It’s not even slower than the old one, the only delay you’ll notice is when filtering packages with a huge amount of bugs (like wnpp) and even there the filter just needs a fraction of a second. The delay of a few secons comes acutally from the QTable when I remove all the rows not matching the filter. QTable.hideRow(int) and -showRow(int) seem to be very expensive even when I temporary disable all graphic updates for this widget during this operation. If someone knows a trick to circumvent this, please tell me (you may get a pony…).

This feature isn’t spectacular, but it should make filtering big buglists a lot easier.