Patch for Python 3 Support
by Ralph Bean
Hello all,
I created a patch to update python-bugzilla to work on both python 2
and python 3. The unit tests all pass under both py2.7 and py3.2.
I have tested the login and query commands by hand on py2.6, py2.7,
and py3.2.
http://threebean.org/patches/python-bugzilla-Python3-support.patch
The patch is against the master branch (7ca8a60). If I should
recreate it against another branch, please let me know.
I'm also willing to update and maintain a spec file supporting both
versions if and when that time comes.
Cheers-
-Ralph
10 years, 9 months
[PATCH] Update the data package for setting bug depdendencies
by Bryan Kearney
---
bugzilla/rhbugzilla.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bugzilla/rhbugzilla.py b/bugzilla/rhbugzilla.py
index b3ec9de..6b4523a 100644
--- a/bugzilla/rhbugzilla.py
+++ b/bugzilla/rhbugzilla.py
@@ -300,8 +300,8 @@ class RHBugzilla(Bugzilla4):
'''
if action not in ('add','delete'):
raise ValueError, "action must be 'add' or 'delete'"
- update={'%s_blocked' % action: blocked,
- '%s_dependson' % action: dependson}
+ update={'blocks' : {action : blocked},
+ 'depends_on' : {action: dependson}}
self._update_bug(id,update)
def _updatecc(self,id,cclist,action,comment='',nomail=False):
--
1.7.11.7
11 years, 5 months
python-bugzilla mods for new bugzilla.redhat.com fields
by Jared Morgan
Hi there all.
Firstly, thank you *so* much for this awesome tool.
In Red Hat Engineering Content Services, we depend on this tool to be able to extract Release Note content from Bugzilla. It saves us days of hand-writing release notes in XML.
We can edit the CCFR directly in bugzilla then export the contents using a wrapper script around the python-bugzilla tool. The wrapper script was initially devised by Lee Carlon, and has recently undergone significant rework by Scott Mumford.
With the recent changes to Bugzilla Release Note fields, I've had to get some mods done to the fields the tool supports. Lee Newson made these changes for us in short order so we could produce release notes using the new fields to meet a GA deadline.
Now the dust has settled, I wanted to share the work Lee Newson has done to the python-bugzilla tool with the list.
His email with an overview of mods done to the script is forwarded below for reference.
If you want to get your hands on these mods and implement them officially in the tool, we would love to help make that happen.
I think the mods Lee has done add real value to the already excellent tool, and I feel it would benefit people who use other bugzilla instances (maybe not the Doc_Type and Doc_Text fields specifically, but certainly the Target_Release field).
Hope you find this info interesting at a minimum, and worthy enough to perhaps serve as a basic RFE with solution.
Cheers, and thanks again for your work.
Jared Morgan
EPP Docs Lead | PressGang Lead | RHCSA (120-008-248)
Red Hat Asia Pacific
1/193 North Quay
BRISBANE QLD 4000
P: +61 7 3514 8242
M: +61 413 005 479
Too brief? Here's why! http://emailcharter.org
----- Forwarded Message -----
> From: "Lee Newson" <lnewson(a)redhat.com>
> To: "Jared Morgan" <jmorgan(a)redhat.com>, "Scott Mumford" <smumford(a)redhat.com>
> Sent: Tuesday, September 11, 2012 9:45:58 PM
> Subject: Bugzilla Release Notes Script
>
>
> Hey Guys,
>
>
> I've fixed up the python-bugzilla app in three ways:
>
>
>
>
> The first is a fix for the doc_text and doc_type parameters. This was
> my fault as when I did it originally I did it on the source and to
> make sure I didn't change anything important I did a diff and added
> the new content to the custom release_notes bugzilla python app.
> However I missed one part and as such it was ignoring these
> parameters, so sorry about any issues that caused :(
>
>
>
>
>
>
> Secondly, there is currently no target_release option. So i've added
> one in the same way as the doc_type. eg --target_release="6.0.x".
>
>
>
>
>
>
>
> Lastly, this is just a quick hack to do at least what you need to do
> (I do have a plan to do it properly but if I don't need to then I'd
> prefer to save the time as I'd have to learn some more python as
> well). You need to specify multiple target releases, so the
> parameters need to be able to add a nested statement to the bugzilla
> query. Currently you were doing:
>
>
> ./bugzilla query --product="JBoss Enterprise Portal Platform 6"
> --component="" --flag="requires_doc_text+"
> --boolean_query="target_release-6.0.x & target_release-6.0.0.GA &
> target_release-6.0.0.DR01" --doc_type="Enhancement"
>
>
> As I explained to Jared this afternoon this has a few issues with the
> boolean query. The statement there equates to looking for bugs that
> have the 6.0.x, 6.0.0.GA and 6.0.0.DR01 target releases which I
> highly doubt you wanted, I believe you wanted to use OR. The second
> is that the syntax is invalid the correct syntax should have been:
>
>
> ./bugzilla query --product="JBoss Enterprise Portal Platform 6"
> --component="" --flag="requires_doc_text+"
> --boolean_query="target_release-substring-6.0.x &
> target_release-substring-6.0.0.GA &
> target_release-substring-6.0.0.DR01" --doc_type="Enhancement"
>
>
> Jared mentioned that you removed the substring since it said it was
> the default for the --booleantype variable, which as we both agreed
> was what the docs made it look like. However this isn't quite the
> case, the --boolean_query value must always specify the "condition"
> and the --booleantype variable is used for items like: flags,
> whiteboard, alias, doc_type, etc... One thing to note is because I
> went with the quick implementation you can only use one logic type
> for the boolean_query variable. eg you can't do:
>
>
> --boolean_query= "target_release-substring-6.0.x &
> target_release-substring-6.0.0.GA |
> target_release-substring-6.0.0.DR01"
>
>
> Simply because to do that requires parsing the boolean_query value
> and a lot more processing to break it up to an equivalent bugzilla
> search, for which I'd have to learn more python to be able to do.
>
>
>
>
>
>
>
> So to finish it up, below is the new query that I believe you guys
> need with the python-bugzilla app I committed back into the
> repository tonight:
>
>
> ./bugzilla query --product="JBoss Enterprise Portal Platform 6"
> --flag="requires_doc_text+" --target_release="6.0.x | 6.0.0.GA |
> 6.0.0.DR01" --doc_type="Enhancement"
>
>
> (Note: The doc_type & doc_text can't take in multiple parameters
> because the normal method split on spaces and these parameters would
> normally take variables with spaces. If you do need to do this, let
> me know and I'll come up with another solution)
>
>
> If you have any questions feel free to hit me up tomorrow on IRC or
> email me back.
>
>
> Cheers Lee
>
> Associate Software Engineer, RHCE
> Red Hat Asia Pacific Pty Ltd
> Level 1, 193 North Quay
> Brisbane, QLD 4000, Australia
>
>
11 years, 5 months
Can't set multicall=False
by Jason L Tibbitts III
I'm doing some work with the Red Hat bugzilla and really need the
performance increase of calling getbugs with a big list of bugs instead
of letting it do the multicall. So I figure I'd just pass
multicall=False to the constructor, but it fails:
TypeError: __init__() got an unexpected keyword argument 'multicall'
I have limited understanding of python, but it seems that the kwargs get
passed all the way down to BugzillaBase.__init__ which bails if it gets
anything other than user, password, url or cookiefile.
Also, I really need to get flags back from getbugs, which requires you
pass an extra_fields argument containing 'flags'. Is it at all possible
to do this with python-bugzilla or should I just bypass it and make an
xmlrpc call myself?
- J<
11 years, 5 months