Hi, guys. I've been working with a Bugzappers group community member, Brennan Ashton, who has written a great tool in Python for generating a range of graphical metrics of Bugzilla information, which would be very useful to us. The tool is basically written and we have space provided by Infrastructure to host it on a permanent basis, but unfortunately, Infrastructure's servers all run RHEL and so have Python 2.4, while the tool has a small but important section of code which relies on a Python 2.5-only function to work. Brennan's very busy at present and might not have time to port the code to Python 2.4 for a while, so - as we want to have it up and running ASAP - I thought I'd ask this list if anyone would be kind enough to help out in tweaking the code to work on Python 2.4.
The code is all up in the Bugzappers git repository:
http://git.fedoraproject.org/git/triage.git
it's the 'triageweb' subdirectory, and some things in 'scripts' as well I believe. If anyone would be kind enough to help, Brennan (in CC) can point out the relevant bit of code that needs changing - I don't have the reference myself, I'm afraid. Thanks, all!
On Fri, May 1, 2009 at 11:11 AM, Adam Williamson awilliam@redhat.com wrote:
Hi, guys. I've been working with a Bugzappers group community member, Brennan Ashton, who has written a great tool in Python for generating a range of graphical metrics of Bugzilla information, which would be very useful to us. The tool is basically written and we have space provided by Infrastructure to host it on a permanent basis, but unfortunately, Infrastructure's servers all run RHEL and so have Python 2.4, while the tool has a small but important section of code which relies on a Python 2.5-only function to work. Brennan's very busy at present and might not have time to port the code to Python 2.4 for a while, so - as we want to have it up and running ASAP - I thought I'd ask this list if anyone would be kind enough to help out in tweaking the code to work on Python 2.4.
The code is all up in the Bugzappers git repository:
http://git.fedoraproject.org/git/triage.git
it's the 'triageweb' subdirectory, and some things in 'scripts' as well I believe. If anyone would be kind enough to help, Brennan (in CC) can point out the relevant bit of code that needs changing - I don't have the reference myself, I'm afraid. Thanks, all!
I might have a few spare cycles today and monday. instructions on how to run the code locally?
-jef
On Fri, 2009-05-01 at 11:31 -0800, Jeff Spaleta wrote:
I might have a few spare cycles today and monday. instructions on how to run the code locally?
Heh, I thought people might start wanting actual details like that, and I'm really sorry I can't provide 'em :( I just wanted to get the email done ASAP before I forgot about the issue over the weekend. Brennan should be able to provide details - hopefully he'll get in touch with you directly. I'll try and catch him on IRC to check on your and Kyle's questions. If you want to keep an eye out, his IRC nick is 'comphappy'.
On Fri, May 1, 2009 at 11:50 AM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2009-05-01 at 11:31 -0800, Jeff Spaleta wrote:
I might have a few spare cycles today and monday. instructions on how to run the code locally?
Heh, I thought people might start wanting actual details like that, and I'm really sorry I can't provide 'em :( I just wanted to get the email
I got it up and running on a fedora box... db created...cherrypy server running. But I need to know how to fire off the specifically broken things so I can make sure they work for me on Fedora before I go testing them under Centos and python2.4.
-jef
On Fri, 2009-05-01 at 11:53 -0800, Jeff Spaleta wrote:
On Fri, May 1, 2009 at 11:50 AM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2009-05-01 at 11:31 -0800, Jeff Spaleta wrote:
I might have a few spare cycles today and monday. instructions on how to run the code locally?
Heh, I thought people might start wanting actual details like that, and I'm really sorry I can't provide 'em :( I just wanted to get the email
I got it up and running on a fedora box... db created...cherrypy server running. But I need to know how to fire off the specifically broken things so I can make sure they work for me on Fedora before I go testing them under Centos and python2.4.
I'm sorry, I can't remember :|. Brennan showed it to me at LFNW over the weekend but I just forgot to take a note. Would've made this easier, sigh! As I said, he should get in touch and let you know soon. I remember him saying it was a pretty small bit of code, but because it relied on something that just isn't there in 2.4, rewriting it wouldn't be entirely trivial (but certainly possible).
I have some time to look at it this weekend (I'm Fedora contributor "kylev"). Brennan, drop me a line directly if you have hints as to what particular 2.5 feature(s) you're using. I deal with this sort of crap in MySQLdb frequently, and should be able to help.
On Fri, May 1, 2009 at 12:11 PM, Adam Williamson awilliam@redhat.comwrote:
Hi, guys. I've been working with a Bugzappers group community member, Brennan Ashton, who has written a great tool in Python for generating a range of graphical metrics of Bugzilla information, which would be very useful to us. The tool is basically written and we have space provided by Infrastructure to host it on a permanent basis, but unfortunately, Infrastructure's servers all run RHEL and so have Python 2.4, while the tool has a small but important section of code which relies on a Python 2.5-only function to work. Brennan's very busy at present and might not have time to port the code to Python 2.4 for a while, so - as we want to have it up and running ASAP - I thought I'd ask this list if anyone would be kind enough to help out in tweaking the code to work on Python 2.4.
The code is all up in the Bugzappers git repository:
http://git.fedoraproject.org/git/triage.git
it's the 'triageweb' subdirectory, and some things in 'scripts' as well I believe. If anyone would be kind enough to help, Brennan (in CC) can point out the relevant bit of code that needs changing - I don't have the reference myself, I'm afraid. Thanks, all! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
On Fri, 2009-05-01 at 12:11 -0700, Adam Williamson wrote:
Hi, guys. I've been working with a Bugzappers group community member, Brennan Ashton, who has written a great tool in Python for generating a range of graphical metrics of Bugzilla information, which would be very useful to us. The tool is basically written and we have space provided by Infrastructure to host it on a permanent basis, but unfortunately, Infrastructure's servers all run RHEL and so have Python 2.4, while the tool has a small but important section of code which relies on a Python 2.5-only function to work. Brennan's very busy at present and might not have time to port the code to Python 2.4 for a while, so - as we want to have it up and running ASAP - I thought I'd ask this list if anyone would be kind enough to help out in tweaking the code to work on Python 2.4.
The code is all up in the Bugzappers git repository:
http://git.fedoraproject.org/git/triage.git
it's the 'triageweb' subdirectory, and some things in 'scripts' as well I believe. If anyone would be kind enough to help, Brennan (in CC) can point out the relevant bit of code that needs changing - I don't have the reference myself, I'm afraid. Thanks, all!
[dmalcolm@radiator triage]$ find -name *.py ./scripts/createTriageDB.py ./scripts/triagestatus.py ./scripts/bzTriageReport.py ./scripts/saveReport.py ./scripts/test.py ./scripts/bzReviewReport.py ./triageweb/createdb.py ./triageweb/fedoratriage/json.py ./triageweb/fedoratriage/model.py ./triageweb/fedoratriage/release.py ./triageweb/fedoratriage/commands.py ./triageweb/fedoratriage/templates/__init__.py ./triageweb/fedoratriage/config/__init__.py ./triageweb/fedoratriage/controllers.py ./triageweb/fedoratriage/tests/test_controllers.py ./triageweb/fedoratriage/tests/test_model.py ./triageweb/fedoratriage/tests/__init__.py ./triageweb/fedoratriage/__init__.py ./triageweb/updateGroups.py ./triageweb/start-fedoratriage.py ./triageweb/setup.py ./triageweb/bzTriageReport.py ./triageweb/bzTriageReportHistory.py ./triageweb/bzTriageTotalReport.py ./triageweb/test.py
So where's the 2.5-only code?
triagedb uses sqlalchemy, and that API changed a bit between 0.3 and 0.4. EPEL5 contains 0.3, and I see "SQLAlchemy>=0.3.10" in the ./triageweb/setup.py. However most of the Fedora Infrastructure uses 0.4 on EL5 IIRC (please correct me if I'm wrong).
It's TurboGears, so run the app by invoking "start-fedoratriage.py". One gotcha that confused me for a while, "dev.cfg" has: server.webpath = "/triageweb/" so the URL you have to browse to is http://0.0.0.0:8080/triageweb , not http://0.0.0.0:8080/ as prompt from start-fedoratriage.py suggests (the latter gives a 404)
Hope this helps Dave
On Fri, May 1, 2009 at 11:57 AM, David Malcolm dmalcolm@redhat.com wrote:
So where's the 2.5-only code?
Im getting python import errors trying to use the triager link off the main page when running on Centos no such error running under Fedora 9. Something's different. But I need more background on the problem.
-jef
On Fri, May 1, 2009 at 12:03 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Fri, May 1, 2009 at 11:57 AM, David Malcolm dmalcolm@redhat.com wrote:
So where's the 2.5-only code?
Im getting python import errors trying to use the triager link off the main page when running on Centos no such error running under Fedora 9. Something's different. But I need more background on the problem.
Collections module in python 2.5 does not define a defaultdict class.
That's the first problem -jef
On Fri, May 1, 2009 at 12:06 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Fri, May 1, 2009 at 12:03 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Fri, May 1, 2009 at 11:57 AM, David Malcolm dmalcolm@redhat.com wrote:
So where's the 2.5-only code?
Im getting python import errors trying to use the triager link off the main page when running on Centos no such error running under Fedora 9. Something's different. But I need more background on the problem.
Collections module in python 2.5 does not define a defaultdict class.
That's the first problem
Err reverse that.. python 2.4 no defaultdict class in collections module python 2.5 collections does have it
-jef
On Fri, May 1, 2009 at 12:06 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Err reverse that.. python 2.4 no defaultdict class in collections module python 2.5 collections does have it
well a simple change defaultdict=dict in controllers.py seems not to cause any damage. It really depends on if you need the minor changes between defaultdict and a regular dict.
I could go though the trouble of building out the defaultdict subclass by hand and overriding _missing_ in a similar way to make use of defaultfactory. That would be the correct fix. But is it needed? Do you ever actually use defaultfactory functionality in the codebase?
So one problem down? anything else? The other errors im getting exist on both my F9 and Centos5 setup so they arent python2.5 specific... just me not having everything configured correctly.
-jef
Jeff Spaleta wrote:
On Fri, May 1, 2009 at 12:06 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Fri, May 1, 2009 at 12:03 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Fri, May 1, 2009 at 11:57 AM, David Malcolm dmalcolm@redhat.com wrote:
So where's the 2.5-only code?
Im getting python import errors trying to use the triager link off the main page when running on Centos no such error running under Fedora 9. Something's different. But I need more background on the problem.
Collections module in python 2.5 does not define a defaultdict class.
That's the first problem
Err reverse that.. python 2.4 no defaultdict class in collections module python 2.5 collections does have it
Yeah, defaultdict is useful but not in python-2.4.
Python-2.4 does have "setdefault" which is a misleading name (it doesn't "set" a "default") for something that can be made to replace defaultdict sometimes.
Here's an example of making a replacement in python-fedora: http://bzr.fedorahosted.org/bzr/python-fedora-python-fedora-devel?cmd=revisi...
Usually, if I was going to rewrite some code, I'd use a try: except: as it's clearer what's going on. Here's an example:
variable = {} for key, index, data in [('one', 'a', '1'), ('two', 'b', 2), ('two', 'c', 3)]: try: variable[key][index] = data except KeyError: variable[key] = {index: data}
-Toshio
On Fri, May 1, 2009 at 12:23 PM, Toshio Kuratomi a.badger@gmail.com wrote:
Python-2.4 does have "setdefault" which is a misleading name (it doesn't "set" a "default") for something that can be made to replace defaultdict sometimes.
Here's an example of making a replacement in python-fedora: http://bzr.fedorahosted.org/bzr/python-fedora-python-fedora-devel?cmd=revisi...
Usually, if I was going to rewrite some code, I'd use a try: except: as it's clearer what's going on. Here's an example:
I just try: except: the import.
What's not clear to me is why defaultdict is needed at all in this case. There is no call to default_factory and its default_factory which lets you define a default value when a key is missing. I dont see that going on in the code so it looks to me like defaultdict can just be replaced with dict with no pain defaultdict=dict
-jef
Jeff Spaleta wrote:
On Fri, May 1, 2009 at 12:23 PM, Toshio Kuratomi a.badger@gmail.com wrote:
Python-2.4 does have "setdefault" which is a misleading name (it doesn't "set" a "default") for something that can be made to replace defaultdict sometimes.
Here's an example of making a replacement in python-fedora: http://bzr.fedorahosted.org/bzr/python-fedora-python-fedora-devel?cmd=revisi...
Usually, if I was going to rewrite some code, I'd use a try: except: as it's clearer what's going on. Here's an example:
I just try: except: the import.
What's not clear to me is why defaultdict is needed at all in this case. There is no call to default_factory and its default_factory which lets you define a default value when a key is missing. I dont see that going on in the code so it looks to me like defaultdict can just be replaced with dict with no pain defaultdict=dict
I think you'll get exceptions at places like this when just replacing defaultdict with dict::
http://git.fedoraproject.org/git/triage.git?p=triage.git;a=blob;f=triageweb/...
-Toshio
On Fri, 2009-05-01 at 12:36 -0800, Jeff Spaleta wrote:
On Fri, May 1, 2009 at 12:23 PM, Toshio Kuratomi a.badger@gmail.com wrote:
Python-2.4 does have "setdefault" which is a misleading name (it doesn't "set" a "default") for something that can be made to replace defaultdict sometimes.
Here's an example of making a replacement in python-fedora: http://bzr.fedorahosted.org/bzr/python-fedora-python-fedora-devel?cmd=revisi...
Usually, if I was going to rewrite some code, I'd use a try: except: as it's clearer what's going on. Here's an example:
I just try: except: the import.
What's not clear to me is why defaultdict is needed at all in this case. There is no call to default_factory and its default_factory which lets you define a default value when a key is missing.
The value or callable passed to the constructor sets it.
On Fri, May 1, 2009 at 1:02 PM, Ignacio Vazquez-Abrams ivazqueznet@gmail.com wrote:
The value or callable passed to the constructor sets it.
Should we just cobble together a pure python subclass that mimics this behavior to use as a drop in replacement for the missing defaultdict?
-jef
Jeff Spaleta wrote:
On Fri, May 1, 2009 at 1:02 PM, Ignacio Vazquez-Abrams ivazqueznet@gmail.com wrote:
The value or callable passed to the constructor sets it.
Should we just cobble together a pure python subclass that mimics this behavior to use as a drop in replacement for the missing defaultdict?
Jef's found some code for defaultdict with a suitable license. We'll put it in python-fedora for now and look at spinning out a compat library if there's more problems. Between that and the python-sqlalchemy update from:
http://infrastructure.fedoraproject.org/el/5/i386/python-sqlalchemy-0.4.7-1....
he seems to have all the EL-5 specific errors ironed out.
kylev noticed some additional problems that are not related to python-2.4.
* There's lots of methods defined with default arguments like this:
component(self, start='1990-01-01', end=time.strftime("%Y-%m-%d"), component='kernel', status=[]):
Default arguments are evaluated when the method is created. This means there's two problems with this code: 1) The time.strftime() is only going to be run once, when the program starts instead of every time the method is called (which is probably what's wanted). 2) The list created for status will be reused every time the method is called so it will only be a fresh, empty list the first time through.
To solve these, use something like this:
def component(self, start='1990-01-01', end=None, component='kernel', status=None):
end = end or time.strftime("%Y-%m-%d") status = status or []
* This code would be clearer if rewritten: if str(status) == status: status = [status]
instead do this: if isinstance(status, str): status = [status]
* Code like this: triageByDate.c.keys()[k] are going to fail at some point. They assume that the list returned by .keys() will always put the keys in the same order. This is not guaranteed and adding and taking away other values in the dictionary can change the key at position k.
-Toshio
On Fri, May 1, 2009 at 2:23 PM, Toshio Kuratomi a.badger@gmail.com wrote:
Jef's found some code for defaultdict with a suitable license. We'll put it in python-fedora for now and look at spinning out a compat library if there's more problems. Between that and the python-sqlalchemy update from:
http://infrastructure.fedoraproject.org/el/5/i386/python-sqlalchemy-0.4.7-1....
he seems to have all the EL-5 specific errors ironed out.
I can only do very shallow testing. I think I need to actually have a useful sql db locally to test any of the plotting. With the defaultdict emulation I can get past the server errors and the tracebacks..but there's nothing really useful going on.
I could probably help a little more in terms of testing if the development code came with a small pre-filled dummy sqlite db.
-jef
On Fri, 2009-05-01 at 14:51 -0800, Jeff Spaleta wrote:
On Fri, May 1, 2009 at 2:23 PM, Toshio Kuratomi a.badger@gmail.com wrote:
Jef's found some code for defaultdict with a suitable license. We'll put it in python-fedora for now and look at spinning out a compat library if there's more problems. Between that and the python-sqlalchemy update from:
http://infrastructure.fedoraproject.org/el/5/i386/python-sqlalchemy-0.4.7-1....
he seems to have all the EL-5 specific errors ironed out.
I can only do very shallow testing. I think I need to actually have a useful sql db locally to test any of the plotting. With the defaultdict emulation I can get past the server errors and the tracebacks..but there's nothing really useful going on.
I could probably help a little more in terms of testing if the development code came with a small pre-filled dummy sqlite db.
Hey, guys. I've been following the thread - thanks for your excellent contributions and suggestions. I'm definitely going to try my hardest to pin down Brennan on IRC and pass everything from this thread on, if he hasn't been following it himself. Thanks again for everything!
I know Brennan has a snapshot of Bugzilla he was using for testing of his implementation, and it was actually up on his server for a while, but unfortunately it's not any more (he has technical issues keeping it up). I'll definitely suggest that a sample data set be added to the code.
On Fri, 2009-05-01 at 22:37 -0700, Adam Williamson wrote:
I can only do very shallow testing. I think I need to actually have a useful sql db locally to test any of the plotting. With the defaultdict emulation I can get past the server errors and the tracebacks..but there's nothing really useful going on.
I could probably help a little more in terms of testing if the development code came with a small pre-filled dummy sqlite db.
Hey, guys. I've been following the thread - thanks for your excellent contributions and suggestions. I'm definitely going to try my hardest to pin down Brennan on IRC and pass everything from this thread on, if he hasn't been following it himself. Thanks again for everything!
I know Brennan has a snapshot of Bugzilla he was using for testing of his implementation, and it was actually up on his server for a while, but unfortunately it's not any more (he has technical issues keeping it up). I'll definitely suggest that a sample data set be added to the code.
Just wanted to send another update on this - Brennan did get the code ported to Python 2.4, and it's now up live and running on the infrastructure servers. It's at http://publictest14.fedoraproject.org/triageweb/ , if anyone's interested in taking a look. I'm not sure if Brennan used the work you guys contributed for the Python 2.4 port or re-did it himself before he saw it, but either way, thanks a lot for your time on this! Of course, if anyone's interested in helping develop the system further, I'm sure Brennan would welcome the assistance.
thanks again, guys.
It doesn't look like much (if anything) has been pushed back up to the public git repo...
https://fedorahosted.org/triage/browser/triageweb
Everything there is at least 3 months old (and still includes .pyc and .pyo files if you clone the repo).
On Fri, Jun 5, 2009 at 3:02 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2009-05-01 at 22:37 -0700, Adam Williamson wrote:
I can only do very shallow testing. I think I need to actually have a useful sql db locally to test any of the plotting. With the defaultdict emulation I can get past the server errors and the tracebacks..but there's nothing really useful going on.
I could probably help a little more in terms of testing if the development code came with a small pre-filled dummy sqlite db.
Hey, guys. I've been following the thread - thanks for your excellent contributions and suggestions. I'm definitely going to try my hardest to pin down Brennan on IRC and pass everything from this thread on, if he hasn't been following it himself. Thanks again for everything!
I know Brennan has a snapshot of Bugzilla he was using for testing of his implementation, and it was actually up on his server for a while, but unfortunately it's not any more (he has technical issues keeping it up). I'll definitely suggest that a sample data set be added to the code.
Just wanted to send another update on this - Brennan did get the code ported to Python 2.4, and it's now up live and running on the infrastructure servers. It's at http://publictest14.fedoraproject.org/triageweb/ , if anyone's interested in taking a look. I'm not sure if Brennan used the work you guys contributed for the Python 2.4 port or re-did it himself before he saw it, but either way, thanks a lot for your time on this! Of course, if anyone's interested in helping develop the system further, I'm sure Brennan would welcome the assistance.
thanks again, guys.
Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
On Sat, 2009-06-06 at 11:54 -0700, Kyle VanderBeek wrote:
It doesn't look like much (if anything) has been pushed back up to the public git repo...
https://fedorahosted.org/triage/browser/triageweb
Everything there is at least 3 months old (and still includes .pyc and .pyo files if you clone the repo).
Thanks - not sure what's going on there then. I'll ask him.
On Mon, 2009-06-08 at 12:22 -0700, Adam Williamson wrote:
On Sat, 2009-06-06 at 11:54 -0700, Kyle VanderBeek wrote:
It doesn't look like much (if anything) has been pushed back up to the public git repo...
https://fedorahosted.org/triage/browser/triageweb
Everything there is at least 3 months old (and still includes .pyc and .pyo files if you clone the repo).
Thanks - not sure what's going on there then. I'll ask him.
Brennan says "I am in the heart of sillicon valley with failing wifi access and poor cell reception. The irony. Right now the Internet I have won't let me ssh out" - so technical difficulties are what's preventing him from sticking the code into git for now. We'll try and make sure it gets up there ASAP.
Tell Brennan he can swing by my place in Potrero Hill to do the upload. I have *great* internet access. :-)
On Mon, Jun 8, 2009 at 1:39 PM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2009-06-08 at 12:22 -0700, Adam Williamson wrote:
On Sat, 2009-06-06 at 11:54 -0700, Kyle VanderBeek wrote:
It doesn't look like much (if anything) has been pushed back up to the public git repo...
https://fedorahosted.org/triage/browser/triageweb
Everything there is at least 3 months old (and still includes .pyc and .pyo files if you clone the repo).
Thanks - not sure what's going on there then. I'll ask him.
Brennan says "I am in the heart of sillicon valley with failing wifi access and poor cell reception. The irony. Right now the Internet I have won't let me ssh out" - so technical difficulties are what's preventing him from sticking the code into git for now. We'll try and make sure it gets up there ASAP. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
On Tue, 2009-06-09 at 22:19 -0700, Kyle VanderBeek wrote:
Tell Brennan he can swing by my place in Potrero Hill to do the upload. I have great internet access. :-)
It's done now :). git should be in sync with the latest code.
On Thu, Jun 11, 2009 at 10:54 PM, Adam Williamson awilliam@redhat.comwrote:
On Tue, 2009-06-09 at 22:19 -0700, Kyle VanderBeek wrote:
Tell Brennan he can swing by my place in Potrero Hill to do the upload. I have great internet access. :-)
It's done now :). git should be in sync with the latest code.
Oof. He uploaded it in a new directory? Now there are two copies of the code (triageweb and triageweb-0.1), no labels, and .pyc, .pyo, and ~ files all checked in.
Brennan, if you want some assistance/tutorials with source control workflows and using git to work with others, contact me.
On Thu, 2009-06-11 at 23:03 -0700, Kyle VanderBeek wrote:
On Thu, Jun 11, 2009 at 10:54 PM, Adam Williamson awilliam@redhat.com wrote: On Tue, 2009-06-09 at 22:19 -0700, Kyle VanderBeek wrote: > Tell Brennan he can swing by my place in Potrero Hill to do the > upload. I have great internet access. :-)
It's done now :). git should be in sync with the latest code.
Oof. He uploaded it in a new directory? Now there are two copies of the code (triageweb and triageweb-0.1), no labels, and .pyc, .pyo, and ~ files all checked in.
Yeah, someone pointed out that it should've been a branch and not a directory (if that's what he was aiming for).
Brennan, if you want some assistance/tutorials with source control workflows and using git to work with others, contact me.
Thanks for the offer...Brennan, go for it if you've got time :)
David Malcolm wrote:
triagedb uses sqlalchemy, and that API changed a bit between 0.3 and 0.4. EPEL5 contains 0.3, and I see "SQLAlchemy>=0.3.10" in the ./triageweb/setup.py. However most of the Fedora Infrastructure uses 0.4 on EL5 IIRC (please correct me if I'm wrong).
You are correct. There's a python-sqlalchemy-0.4 package in http://infrastructure.fedoraproject.org that we use.
-Toshio
python-devel@lists.fedoraproject.org