Re: Bloodhound Wiki and Issue Tracker is Live again
That is fantastic, John. Great work. I'm going to have a go at making some firm proposals for how I would like to move us to rebase upon django. I think at the moment I am going to look to going with a bit of a redesign from scratch. Hopefully we can make use of migrations from the current model. Cheers, Gary On Fri, 16 Feb 2018, at 12:19 AM, John Chambers wrote: > Hello, > > Just a quick note to say that the Bloodhound Project's Live wiki and > issue tracker is available again.> It has been migrated to version 0.8 and so > we now have the option of > creating new products for different areas of the project.> > The url has been changed at the request of Apache INFRA but you should > be able to access it here:> > https://live.bloodhound.apache.org/bloodhound > > The user registration has been initially disabled but if you have had > a previous login that should work and if you have forgotten your > password then it can be reset via the link on the login page.> > You can also request registration by posting on > d...@bloodhound.apache.org and we will manually register you.> > If you see any problems then please post on d...@bloodhound.apache.org > and we will work to resolve them.> > Cheers > > John Chambers
Re: Is it alive?
I wouldn't want to discourage users from being demanding in some senses,
though obviously it would be excellent to see people providing patches.
That would also put anyone on the road to joining the project if they
wished.
We would obviously be happy to see developers contributing who were paid
for their efforts. Finding a company willing to do this might not be
simple of course.
Cheers,
Gary
On 11/09/15 08:49, Vijay Varadan wrote:
+1 to the point about users being demanding.
What are the chances of getting a company to sponsor a developer to
work on this full-time? I ask coz I think this project is totally
worth doing and would be willing to stop what I’m doing to work on
this full time if I could be compensated reasonably. I suspect there
might be others that would be up for it as well.
-Vijay Varadan
*From:*Oscar Edvardsson [mailto:os...@monivent.se]
*Sent:* Friday, September 11, 2015 12:52 PM
*To:* user@bloodhound.apache.org
*Subject:* Re: Is it alive?
And we went with Redmine (multi product support was a requirement).
If you don’t need multi product support, I think Trac has the
advantage that if/when Bloodhound becomes under active development, it
is easy to make the switch. We never experienced any bugs with
Bloodhound (v0.7 and v0.8) during the 6-12 months of using it, but we
needed something that was regularly maintained so any bugs would
eventually be resolved.
That aside, I think we as users are sometimes more demanding than
fair. It is an open source project, and as far as I have understood
it, all development (now) occurs on the developers' free time and
without compensation. The nature of open source allows anyone to fix
bugs, to their best of their abilities, which in turn allows you to
patch issues that are important to you, but not prioritised by the
core development team. (But for us who do not have the ability or time
to do it - regular maintenance is a big thing)
Sorry for the short rant, keep up the good work!
Regards,
On 11 Sep 2015, at 08:28, Joseph D. Wagner mailto:j...@josephdwagner.info>> wrote:
I went with Request Tracker. It has a different set of problems
-- every ticket system does -- but it seems more manageable and
definitely has active support.
https://www.bestpractical.com/rt/
In fairness to the BH team, this is a symptom of a systemic
problem with Apache projects that aren't considered "hip."
* James http://james.apache.org/. Email server with no active
development since 2012. It died right in the middle of
beta-testing it's next major release.
* SpamAssassin http://spamassassin.apache.org/. No active
development between 2011 and 2014, but might be picking up again.
* Geronimo http://geronimo.apache.org/. Java EE 6 application
server with no development since 2013. However, in Apache's
defense, it could be said that Oracle killed Java.
Joseph D. Wagner
On 09/10/2015 10:50 PM, Hoiniji Rosonye wrote:
I think going to Trac is a good decision. With all due
respect to the BH team, I think it still has a long way to
go. I first gave BH a try, but it had too many bugs or
configuration limits. I then decided to try Trac, and I found
that it was very rock solid.
On Sep 10, 2015 9:42 PM, "Torben Lauritzen" mailto:t...@bios.au.dk>> wrote:
Hi.
Thank you for your replies - I will go with the standard
Trac for the moment then. But I will be following Bloodhound.
/Torben
> -Original Message-
> From: Olemis Lang [mailto:ole...@gmail.com
<mailto:ole...@gmail.com>]
> Sent: 11. september 2015 05:57
> To: user@bloodhound.apache.org
<mailto:user@bloodhound.apache.org>
> Subject: Re: Is it alive?
>
> JFTR , I am working on a private fork of Bloodhound that
I use for my
> deployments . Nonetheless I've had to slow down my dev
speed because I'm
> contributing with code to the Brython project , and I've
not had all the time
> I'd like these days for BH dev .
>
>
> On 9/10/15, Ryan J Ollos mailto:rjol...@apache.org>> wrote:
> > On Thu, Sep 10, 2015 at 6:38 AM, Torben Lauritzen
mailto:t...@bios.au.dk>> wrote:
> >
> >> Hi.
> >>
> >> I was just about to install Trac, when I found
Bloodhound. I have
> >> tried installing it, and it seems ok. But at the same
time it also
> >> looks like the project is more or less dead - last
re
Re: Is it alive?
The project is not dead but it has definitely slowed to a crawl for the moment. I have the intention of working through bugs, creating a new release and then working on some new features but it is difficult to put a realistic time-frame on this right now. The relative hip-ness of this project might well be a factor in the attempt to get developers interested in joining the project. I would, of course always be interested in hearing from people who want to get involved. Cheers, Gary On 11 September 2015 at 07:28, Joseph D. Wagner wrote: > I went with Request Tracker. It has a different set of problems -- every > ticket system does -- but it seems more manageable and definitely has > active support. > > https://www.bestpractical.com/rt/ > > In fairness to the BH team, this is a symptom of a systemic problem with > Apache projects that aren't considered "hip." > * James http://james.apache.org/. Email server with no active > development since 2012. It died right in the middle of beta-testing it's > next major release. > * SpamAssassin http://spamassassin.apache.org/. No active development > between 2011 and 2014, but might be picking up again. > * Geronimo http://geronimo.apache.org/. Java EE 6 application server with > no development since 2013. However, in Apache's defense, it could be said > that Oracle killed Java. > > Joseph D. Wagner > > > On 09/10/2015 10:50 PM, Hoiniji Rosonye wrote: > > I think going to Trac is a good decision. With all due respect to the BH > team, I think it still has a long way to go. I first gave BH a try, but it > had too many bugs or configuration limits. I then decided to try Trac, and > I found that it was very rock solid. > On Sep 10, 2015 9:42 PM, "Torben Lauritzen" wrote: > >> Hi. >> >> Thank you for your replies - I will go with the standard Trac for the >> moment then. But I will be following Bloodhound. >> >> /Torben >> >> > -Original Message- >> > From: Olemis Lang [mailto:ole...@gmail.com] >> > Sent: 11. september 2015 05:57 >> > To: user@bloodhound.apache.org >> > Subject: Re: Is it alive? >> > >> > JFTR , I am working on a private fork of Bloodhound that I use for my >> > deployments . Nonetheless I've had to slow down my dev speed because I'm >> > contributing with code to the Brython project , and I've not had all >> the time >> > I'd like these days for BH dev . >> > >> > >> > On 9/10/15, Ryan J Ollos wrote: >> > > On Thu, Sep 10, 2015 at 6:38 AM, Torben Lauritzen >> wrote: >> > > >> > >> Hi. >> > >> >> > >> I was just about to install Trac, when I found Bloodhound. I have >> > >> tried installing it, and it seems ok. But at the same time it also >> > >> looks like the project is more or less dead - last release was >> > >> 2014-12-11, the documentation has unfinished things, e.g. the >> > >> section about git here: >> > >> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall (the >> page >> > >> was last edited 7 months ago), there is a warning >> > >> (SubversionException) at the top of the Wiki pages etc. >> > >> >> > >> So, I just wanted to know if the project is still alive? Are anybody >> > >> working actively on the project? >> > >> >> > > >> > > Yeah there hasn't been much activity lately. I don't have any >> > > immediate plans or time to work on Bloodhound in the near future, but >> > > I'd be interested to hear if any other developers will be working on >> it. >> > > >> > > - Ryan >> > > >> > >> > >> > -- >> > Regards, >> > >> > Olemis - @olemislc >> > >> > Apache™ Bloodhound contributor >> > http://issues.apache.org/bloodhound >> > http://blood-hound.net >> > >> > Brython committer >> > http://brython.info >> > http://github.com/brython-dev/brython >> > >> > Blog ES: http://simelo-es.blogspot.com/ >> > Blog EN: http://simelo-en.blogspot.com/ >> > >> > Featured article: >> > >
Re: upgrading to 0.8
On 17 March 2015 at 14:11, Tim Tisdall wrote:
> On Mon, Mar 16, 2015 at 7:58 PM, Gary Martin
> wrote:
> > Just been looking at the area of the code that I think the error is
> coming
> > from. Coming to this for the first time, and blind to the means by which
> > this error is triggered, I'd probably want to know what the value of
> > path_info on line 78 of bloodhound_multiproduct/multiproduct/web_ui.py
>
> Okay, when I try to access "/products/accesspoint/ticket/37" the
> path_info is "/ticket/37".
>
> I don't understand the code chunk at all, though... Basically if
> pathinfo has a value other than "/" you're going to get an error of
> some sort. Here's my very dumb fix that appears to be working:
>
> diff bloodhound_multiproduct/multiproduct/web_ui.py web_ui.py
> 78c78
> < path_info = req.args.get('pathinfo')
> ---
> > '''path_info = req.args.get('pathinfo')
> 87c87
> < _('Unable to render product page. Wrong setup?'))
> ---
> > _('Unable to render product page. Wrong setup?'))'''
>
> So, that's why "/products/myproduct/" works, but anything else doesn't.
>
Tim,
Hmm... I think I found one way to replicate the error but it is not clear
that it matches your problem yet. If on my test server I hit a path like
products/DEF/products/DEF/somethingelse then I get that error (where DEF is
the prefix for my default product).
Under this circumstance the path_info would be turning up as
"/somethingelse"
Not sure if I should go as far as admitting that this is suggestive of a
bug but it does make it look like you might have a strange setup. I'll have
another look at this in a bit but if you happen to spot anything odd about
your setup, that might be helpful.
Cheers,
Gary
Re: "/bloodhound/[^/]+/login"
Chris, That is great to hear! I'll still need to look into this further of course to see if there is an appropriate fix for our documentation. It might also be nice for us to add specific notes for installing with LDAP but I'll need to get a test setup for that. Thanks for prompting all this! Cheers, Gary On 17 March 2015 at 06:33, Harris, Christopher P wrote: > Hi, Gary. > > > > Thanks for getting back to me. > > > > Yes, I tried /bloodhound/login, and that works for me. > > > > /bloodhound/([^/]+/)?login works for me too. > > > > Thanks! > > > > -Chris Harris > > > > *From:* Gary Martin [mailto:gary.mar...@wandisco.com] > *Sent:* Monday, March 16, 2015 6:25 PM > *To:* user@bloodhound.apache.org > *Subject:* Re: "/bloodhound/[^/]+/login" > > > > Hi Chris, > > Sorry about the delay. I should probably take some time to look into what > the exact issue is but here are my initial thoughts. > > If you are just after a regex that will match /bloodhound/login you could > experiment with just using /bloodhound/login in that location. If it turns > out it is better to keep some of the flavour of what the original > LocationMatch is attempting, the next obvious thing would be to try > /bloodhound/([^/]+/)?login or something that allows for 0 or 1 matches of > the whole section. > > It is quite possible that this is a mistake in our documentation and the > intention of the match is so that you can serve a set of trac projects such > that the [^/]+ is matching the trac project while we are only really > intending there to be a single trac project (with one or more bloodhound > products). > > I'll have to investigate a bit further but I hope that is of some use. > > Cheers, > > Gary > > > > On 10 March 2015 at 23:01, Harris, Christopher P > wrote: > > After some Googling, I read the following: > > ([^/]+) > > Which means match text of 1 or more characters until a forward slash is > found. > > So, that would match a URL such as: > > http://localhost/bloodhound/blah/login > > > > > > So, I tried the following: > > /bloodhound/[^/]*/login > > …but that didn’t work either. Basic auth is effectively disabled, and I’m > not greeted with a Basic auth dialog box by the browser. > > > > Do I really need “/bloodhound/[^/]+/login” as my RegEx pattern to catch > whatever it is that the Trac/Bloodhound authors intend for me to catch? > > > > -Chris Harris > > > > *From:* Harris, Christopher P > *Sent:* Tuesday, March 10, 2015 5:42 PM > *To:* 'user@bloodhound.apache.org' > *Subject:* "/bloodhound/[^/]+/login" > > > > Hi. > > > > Since I started using Bloodhound, around v0.4, I’ve had issues with the > RegEx pattern "/bloodhound/[^/]+/login" that’s defined in my Apache HTTPd > web server’s virtual hosts config. > > > > Specifically, my issue is that it never works! > > If I click on the Login link on the Bloodhound home page, I’m redirected > to the login page, but I’m not greeted with a basic auth dialog box by the > browser. Yes, my basic auth creds from previous sessions are being > cleared…in case that’s what you’re thinking. Ironically, I’ve had much > success with IE 8 in regard to clearing my basic auth credentials. > > > > I’ve only had success with the following RegEx patterns: > > /bloodhound/login ß this pattern being the most ideal out of these 2 > patterns > > /bloodhound > > > > Still, I can circumvent the basic auth dialog box if I type in more than 1 > forward slash in between bloodhound and before login. That’s not ideal. > > > > I think I understand that the pattern in question means to catch URL’s > that have any number of forward slashes after bloodhound and before login. > > Ex – http://localhost/bloodhound//login > <http://localhost/bloodhound/login> > > > > Is my understanding correct? > > > > I know…this is not exactly Bloodhound-specific. It’s more Apache > HTTPd-specific or RegEx-specific. > > > > In any case, can someone please explain to me why > "/bloodhound/[^/]+/login" is not working? > > > > Here’s my httpd-vhosts.conf (and, in any case, I can at least share my > working config that auths with Active Director groups in Apache 2.4 J ): > > > > WSGIPythonHome C:/apache/bloodhound/installer/bloodhound > > WSGIPythonPath > C:/apache/bloodhound/installer/bloodhound/site;C:/apache/bloodhound/installer/bloodhound/Lib/site-packages > > > > #NOTEThe following virtual h
Re: upgrading to 0.8
Hi, Just been looking at the area of the code that I think the error is coming from. Coming to this for the first time, and blind to the means by which this error is triggered, I'd probably want to know what the value of path_info on line 78 of bloodhound_multiproduct/multiproduct/web_ui.py I'm not entirely sure how much that will help at the moment. Oscar's question about the database backend is not unreasonable though. Cheers, Gary On 16 March 2015 at 21:22, Oscar Edvardsson wrote: > Not an expert at all, but what database backend are you using? I > successfully upgraded from Version 0.7 to 0.8 using MySQL. > > I also have the mentioned base_url-warning, but it hasn't affected me, > afaik. > > Can you create another (empty) install? > > > 16 mar 2015 kl. 21:49 skrev Tim Tisdall : > > > > I'm kind of stuck with a useless install here... Is there nothing I > > can do to fix this? > > > >> On Mon, Mar 9, 2015 at 3:47 PM, Tim Tisdall wrote: > >> Any debugging commands (ie inserting of logging statements, etc) I > >> could run to give you some additional information on this? > >> > >>> On Fri, Mar 6, 2015 at 2:28 PM, Tim Tisdall wrote: > >>>> On Fri, Mar 6, 2015 at 2:27 PM, Ryan J Ollos > wrote: > >>>> What version are you upgrading from? > >>> > >>> I'm upgrading from 0.7 >
Re: "/bloodhound/[^/]+/login"
Hi Chris,
Sorry about the delay. I should probably take some time to look into what
the exact issue is but here are my initial thoughts.
If you are just after a regex that will match /bloodhound/login you could
experiment with just using /bloodhound/login in that location. If it turns
out it is better to keep some of the flavour of what the original
LocationMatch is attempting, the next obvious thing would be to try
/bloodhound/([^/]+/)?login or something that allows for 0 or 1 matches of
the whole section.
It is quite possible that this is a mistake in our documentation and the
intention of the match is so that you can serve a set of trac projects such
that the [^/]+ is matching the trac project while we are only really
intending there to be a single trac project (with one or more bloodhound
products).
I'll have to investigate a bit further but I hope that is of some use.
Cheers,
Gary
On 10 March 2015 at 23:01, Harris, Christopher P
wrote:
> After some Googling, I read the following:
>
> ([^/]+)
>
> Which means match text of 1 or more characters until a forward slash is
> found.
>
> So, that would match a URL such as:
>
> http://localhost/bloodhound/blah/login
>
>
>
>
>
> So, I tried the following:
>
> /bloodhound/[^/]*/login
>
> …but that didn’t work either. Basic auth is effectively disabled, and I’m
> not greeted with a Basic auth dialog box by the browser.
>
>
>
> Do I really need “/bloodhound/[^/]+/login” as my RegEx pattern to catch
> whatever it is that the Trac/Bloodhound authors intend for me to catch?
>
>
>
> -Chris Harris
>
>
>
> *From:* Harris, Christopher P
> *Sent:* Tuesday, March 10, 2015 5:42 PM
> *To:* 'user@bloodhound.apache.org'
> *Subject:* "/bloodhound/[^/]+/login"
>
>
>
> Hi.
>
>
>
> Since I started using Bloodhound, around v0.4, I’ve had issues with the
> RegEx pattern "/bloodhound/[^/]+/login" that’s defined in my Apache HTTPd
> web server’s virtual hosts config.
>
>
>
> Specifically, my issue is that it never works!
>
> If I click on the Login link on the Bloodhound home page, I’m redirected
> to the login page, but I’m not greeted with a basic auth dialog box by the
> browser. Yes, my basic auth creds from previous sessions are being
> cleared…in case that’s what you’re thinking. Ironically, I’ve had much
> success with IE 8 in regard to clearing my basic auth credentials.
>
>
>
> I’ve only had success with the following RegEx patterns:
>
> /bloodhound/login ß this pattern being the most ideal out of these 2
> patterns
>
> /bloodhound
>
>
>
> Still, I can circumvent the basic auth dialog box if I type in more than 1
> forward slash in between bloodhound and before login. That’s not ideal.
>
>
>
> I think I understand that the pattern in question means to catch URL’s
> that have any number of forward slashes after bloodhound and before login.
>
> Ex – http://localhost/bloodhound//login
> <http://localhost/bloodhound/login>
>
>
>
> Is my understanding correct?
>
>
>
> I know…this is not exactly Bloodhound-specific. It’s more Apache
> HTTPd-specific or RegEx-specific.
>
>
>
> In any case, can someone please explain to me why
> "/bloodhound/[^/]+/login" is not working?
>
>
>
> Here’s my httpd-vhosts.conf (and, in any case, I can at least share my
> working config that auths with Active Director groups in Apache 2.4 J ):
>
>
>
> WSGIPythonHome C:/apache/bloodhound/installer/bloodhound
>
> WSGIPythonPath
> C:/apache/bloodhound/installer/bloodhound/site;C:/apache/bloodhound/installer/bloodhound/Lib/site-packages
>
>
>
> #NOTEThe following virtual host uses mod_authz_ldap.so to handle
> auth access to Bloodhound.
>
> # Go to http://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html for
> documentation.
>
>
>
>
>
>WSGIScriptAlias /bloodhound
> C:/apache/bloodhound/installer/bloodhound/site/cgi-bin/trac.wsgi
>
> C:/apache/bloodhound/installer/bloodhound/site/cgi-bin>
>
> WSGIApplicationGroup %{GLOBAL}
>
> Require all granted
>
>
>
> Require all granted
>
>
>
>
>
>LogLevel debug
>
>
>
> AuthLDAPURL
> "ldap://:3268/??sub?(objectClass=)"
>
> AuthLDAPBindDN "”
>
> AuthLDAPBindPassword ""
>
>
Re: AttributeError: 'Ticket' object has no attribute 'duplicate'
Hi,
That is interesting. I wonder if this has already been 'fixed' in
https://issues.apache.org/bloodhound/ticket/710
If that is so, are we ignoring the setting of the duplicate now?
Cheers,
Gary
On 15/01/14 08:09, Dominik Enkelmann wrote:
When i try to "*reject*" a ticket in "assigned" state, setting the
reason "*duplicate*", i get this error.
When rejecting with another reason, for example "invalid" everything
works fine.
Any ideas?
Dominik
I have the following workflow defined:
reassign = new,assigned,accepted,reopened -> assigned
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reject = new,assigned, accepted -> closed
reject.operations = set_resolution
reject.permissions = TICKET_MODIFY
Request parameters:
{{{
{'__FORM_TOKEN': u'94ca7d05eb05732286c165fd',
'action': u'reject',
'action_reject_resolve_resolution': u'duplicate',
'comment': u'',
'edit-comment': u'',
'field_cc': u'',
'field_component': u'component1',
'field_description': u'',
'field_keywords': u'',
'field_milestone': u'',
'field_priority': u'major',
'field_reporter': u'vpu...@gmail.com',
'field_summary': u'Non funziona il reject con causa: duplicate',
'field_type': u'defect',
'field_version': u'1.0',
'id': u'104',
'start_time': u'1389772418764191',
'submit': u'Submit changes',
'view_time': u'1389772418764191'}
}}}
User agent: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0)
Gecko/20100101 Firefox/26.0`
System Information
|| '''`Trac`''' || `1.0.1` [[br]] `` ||
|| '''`Babel`''' || `0.9.6` ||
|| '''`Bloodhound Trac`''' || `1.0.1` ||
|| '''`Genshi`''' || `0.6.1 (without speedups)` ||
|| '''`Pygments`''' || `1.6` ||
|| '''`pysqlite`''' || `2.4.1` ||
|| '''`Python`''' || `2.6.6 (r266:84292, Nov 22 2013, 12:16:22) `
[[br]] `[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]` ||
|| '''`pytz`''' || `2013b` ||
|| '''`setuptools`''' || `0.9.8` ||
|| '''`SQLite`''' || `3.6.20` ||
|| '''`Subversion`''' || `1.8.5 (r1542147)` ||
|| '''`jQuery`''' || `1.7.2` ||
Enabled Plugins
|| '''`BloodhoundDashboardPlugin`''' || `0.7.0` ||
|| '''`BloodhoundMultiProduct`''' || `0.7.0` ||
|| '''`BloodhoundRelationsPlugin`''' || `0.7.0` ||
|| '''`BloodhoundSearchPlugin`''' || `0.7.0` ||
|| '''`BloodhoundTheme`''' || `0.7.0` ||
|| '''`TracAccountManager`''' || `0.4` ||
|| '''`TracPermRedirect`''' || `3.0` ||
|| '''`TracThemeEngine`''' || `2.2.1` ||
Python Traceback
{{{
Traceback (most recent call last):
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/web/main.py",
line 477, in _dispatch_request
dispatcher.dispatch(req)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/web/main.py",
line 214, in dispatch
resp = chosen_handler.process_request(req)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/multiproduct/ticket/web_ui.py",
line 64, in process_request
return self._process_ticket_request(req)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/web_ui.py",
line 614, in _process_ticket_request
self._do_save(req, ticket, action)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/web_ui.py",
line 1328, in _do_save
replyto=req.args.get('replyto'))
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/model.py",
line 366, in save_changes
listener.ticket_changed(self, comment, author, old_values)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/bhrelations/api.py",
line 503, in ticket_changed
self.rls.add(ticket, ticket.duplicate,
AttributeError: 'Ticket' object has no attribute 'duplicate'
}}}
Re: Contact Info should be linked from more pages
On 07/08/13 18:12, Joachim Dreimann wrote: On 6 August 2013 13:36, Felipe G. Nievinski <mailto:fgnievin...@gmail.com>> wrote: This page: <https://issues.apache.org/bloodhound/wiki/BloodhoundContactInfo> could be linked from at least these pages: <http://bloodhound.apache.org/> <https://issues.apache.org/bloodhound/wiki/> <https://issues.apache.org/bloodhound/wiki/BloodhoundContributing> Thanks for the feedback Felipe, I've now added the link to both the /wiki/ and /wiki/BhContributing pages. The b.a.o page already contained a link to it -> [IRC channel], but I've also changed the text [mailing list] to link directly to the BhContactInfo page. Cheers, Joe Thanks for that Joe. I was wondering if it would be too intrusive for us to have the link in our page footer. Cheers, Gary
Re: Bloodhound Login Error
On 31/07/13 12:48, Matevž Bradač wrote: On 31. Jul, 2013, at 10:54, Pedro Estrela wrote: I did that command: tracd -p 8000 /var/www/bloodhound/installer/bloodhound/environments/main and i get this errors on localhost:8000/main : " Warning: Unknown theme bloodhound configured. Please check your trac.ini. You may need to enable the theme's plugin." and " Trac detected an internal error: DataError: invalid input syntax for integer: "trac.wiki.api.WikiSystem.pages" LINE 1: SELECT generation FROM cache WHERE id=E'trac.wiki.api.WikiSy... ^" From the looks of it, it seems like you have a corrupt virtual environment or something in that direction. I would suggest recreating the environment from scratch, under the same user account that will be used for running Apache. Note that you may have to manually remove Babel and replace it with an older version (use Babel==0.9.6 with pip), as the newer versions may not work. After the new environment has been set up, running a standalone tracd should work properly. Once this is fixed we can continue debugging the Apache issues. This seems sensible. It might also be worth removing the system installed versions of the packages though if we can work out which they are. I may not have been exhaustive in this list and it may be that some of these are installed from the CentOS repositories so you may need to be careful in case other programs need some of these.. however unless you expect to have Trac itself installed alongside, the following will hopefully be safe enough (deactivate included in case you are starting from an activated virtualenv): deactivate pip uninstall Babel pip uninstall BloodhoundDashboardPlugin pip uninstall BloodhoundMultiProduct pip uninstall BloodhoundRelationsPlugin pip uninstall BloodhoundSearchPlugin pip uninstall BloodhoundTheme pip uninstall Genshi pip uninstall Pygments pip uninstall Trac pip uninstall TracAccountManager pip uninstall TracPermRedirect pip uninstall TracThemeEngine pip uninstall Whoosh pip uninstall sqlparse Cheers, Gary
Re: Bloodhound Login Error
On 30/07/13 17:48, Pedro Estrela wrote: No problem. I use PostgreSQL 2013/7/30 Olemis Lang mailto:ole...@gmail.com>> On 7/30/13, Pedro Estrela mailto:p.estr...@campus.fct.unl.pt>> wrote: > this is what happen when I run tracd: > > " > (bloodhound)[root@lbtvmcentosbug bloodhound]# dir > bin bloodhound environments include lib lib64 site > (bloodhound)[root@lbtvmcentosbug bloodhound]# cd environments/ > (bloodhound)[root@lbtvmcentosbug environments]# dir > main > (bloodhound)[root@lbtvmcentosbug environments]# tracd --port=8000 /main > Server starting in PID 46169. > Serving on 0.0.0.0:8000 <http://0.0.0.0:8000> view at http://127.0.0.1:8000/ > Using HTTP/1.1 protocol version > 127.0.0.1 - - [30/Jul/2013 12:25:53] "GET /main HTTP/1.1" 500 - > 127.0.0.1 - - [30/Jul/2013 12:25:53] "GET > /main/chrome/site/your_project_logo.png HTTP/1.1" 404 - > 127.0.0.1 - - [30/Jul/2013 12:26:00] "GET /main/login HTTP/1.1" 500 - > 127.0.0.1 - - [30/Jul/2013 12:26:00] "GET > /main/chrome/site/your_project_logo.png HTTP/1.1" 404 - > 127.0.0.1 - - [30/Jul/2013 12:26:07] "GET /main HTTP/1.1" 500 - > 127.0.0.1 - - [30/Jul/2013 12:26:08] "GET > /main/chrome/site/your_project_logo.png HTTP/1.1" 404 - > " > > and here is a screen of localhost:8000/main > I had never seen that error before . It is bizarre . What DB backend have you deployed ? SQLite ? PostgreSQL ? MySQL ? Part of my confusion is why "tracd --port=8000 /main" even worked. Is there a /main at the root of the filesystem? Cheers, Gary
Re: Bloodhound Login Error
On 30/07/13 12:13, Pedro Estrela wrote:
Here is the result:
"(bloodhound)[root@lbtvmcentosbug bloodhound]# python
Python 2.6.6 (r266:84292, Feb 22 2013, 00:00:18)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from trac.env import open_environment as oe
>>> env = oe('/var/www/bloodhound/installer/bloodhound/environments/main')
>>> import acct_mgr.web_ui
>>> env[acct_mgr.web_ui.LoginModule]
>>> "
Sorry to intervene again but to try to keep this discussion on track, I
gather that when you run the code through tracd in the activated
environment you are not seeing this error but the problem manifests
itself when running through the webserver. Is this still the case?
Cheers,
Gary
Re: Bloodhound Login Error
Can we be careful to distinguish which environments you are trying this in. Is this in the activated bloodhound virtualenv? Cheers, Gary On 30/07/13 10:17, Pedro Estrela wrote: Yes i did all as root. [root@lbtvmcentosbug Desktop]# python Python 2.6.6 (r266:84292, Feb 22 2013, 00:00:18) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import genshi >>> import babel >>> import themeengine >>> import acct_mgr Traceback (most recent call last): File "", line 1, in ImportError: No module named acct_mgr >>> import bhtheme >>> import bhdashboard >>> import bhsearch >>> import multiproduct >>> import bhrelations >>> this is my output, i guess i'm having some troubles with acct_mgr 2013/7/30 Matevž Bradač mailto:mat...@digiverse.si>> On 30. Jul, 2013, at 10:45, Pedro Estrela wrote: > I'm running as root. > > Here is the result of pip freeze: > > " > Warning: cannot find svn location for BloodhoundMultiProduct==0.7.0dev-r1506070 > Warning: cannot find svn location for BloodhoundRelationsPlugin==0.7.0dev-r1503571 > Warning: cannot find svn location for BloodhoundTheme==0.7.0dev-r1506038 > Warning: cannot find svn location for BloodhoundSearchPlugin==0.7.0dev-r1503560 > Warning: cannot find svn location for BloodhoundDashboardPlugin==0.7.0dev-r1505871 > Warning: cannot find svn location for PEAK-Rules==0.5a1.dev-r2582 > AddOns==0.6 > Babel==0.9.4 > Beaker==1.3.1 > ## FIXME: could not find svn URL in dependency_links for this package: > BloodhoundDashboardPlugin==0.7.0dev-r1505871 > ## FIXME: could not find svn URL in dependency_links for this package: > BloodhoundMultiProduct==0.7.0dev-r1506070 > ## FIXME: could not find svn URL in dependency_links for this package: > BloodhoundRelationsPlugin==0.7.0dev-r1503571 > ## FIXME: could not find svn URL in dependency_links for this package: > BloodhoundSearchPlugin==0.7.0dev-r1503560 > ## FIXME: could not find svn URL in dependency_links for this package: > BloodhoundTheme==0.7.0dev-r1506038 > BytecodeAssembler==0.5.1 > Cheetah==2.4.1 > DecoratorTools==1.7 > Extremes==1.1 > FormEncode==1.2.2 > Genshi==0.6 > Magic-file-extensions==0.1 > Mako==0.3.4 > Markdown==2.0.1 > MarkupSafe==0.9.2 > MySQL-python==1.2.3c1 > Myghty==1.1 > ## FIXME: could not find svn URL in dependency_links for this package: > PEAK-Rules==0.5a1.dev-r2582 > Paste==1.7.4 > PasteDeploy==1.3.3 > PasteScript==1.7.3 > PyGreSQL==3.8.1 > Pygments==1.1.1 > Pylons==0.9.7 > Routes==1.10.3 > SQLAlchemy==0.5.5 > SSSDConfig==1.9.2 > SetupDocs==1.0.5 > SymbolType==1.0 > Tempita==0.4 > ToscaWidgets==0.9.8 > Trac==1.0.1 > TracAccountManager==0.4.3 > TracPermRedirect==3.0 > TracThemeEngine==2.2.0 > TurboGears2==2.0.3 > TurboJson==1.2.1 > WebError==0.10.2 > WebFlash==0.1a9 > WebHelpers==0.6.4 > WebOb==0.9.6.1 > WebTest==1.2 > Whoosh==2.4.1 > cas==0.15 > cups==1.0 > cupshelpers==1.0 > decorator==3.0.1 > distribute==0.6.10 > ethtool==0.6 > firstboot==1.110 > freeipa==2.0.0.alpha.0 > iniparse==0.3.1 > iotop==0.3.2 > ipapython==3.0.0 > iwlib==1.0 > kerberos==1.0 > luci==0.26.0 > lxml==2.2.3 > matplotlib==0.99.1.1 > netaddr==0.7.5 > nose==0.10.4 > numpy==1.4.1 > paramiko==1.7.5 > pexpect==2.3 > policycoreutils-default-encoding==0.1 > prioritized-methods==0.2.1 > psycopg2==2.0.14 > pyOpenSSL==0.10 > pyasn1==0.0.12a > pycrypto==2.0.1 > pycurl==7.19.0 > pygpgme==0.1 > python-dateutil==1.4.1 > python-default-encoding==0.1 > python-ldap==2.3.10 > python-meh==0.11 > python-memcached==1.43 > python-nss==0.13 > pytz==2010h > pyxdg==0.18 > qpid-python==0.14 > qpid-tools==0.14 > repoze.tm2==1.0a4 > repoze.what==1.0.8 > repoze.what-pylons==1.0 > repoze.who==1.0.18 > repoze.who-friendlyform==1.0.8 > repoze.who-testutil==1.0rc1 > scdate==1.9.60 > sckdump==2.0.5 > scservices==0.99.45 > scservices.dbus==0.99.45 > setools==1.0 > simplejson==2.0.9 > slip==0.2.20 > slip.dbus==0.2.20 > slip.gtk==0.2.20 > smbc==1.0 > sqlparse==0.1.7
Re: Bloodhond Instalation and Configuration CentOS 6.4
All things being equal - that running through tracd, it should only be a problem with the system installed packages at this point. I've not managed to get a working CentOS 6.4 to try to replicate yet. If problems continue then this may be quite difficult to sort it out without more information. Is this an error that you are not getting when you are running without the webserver? If so, can you turn on logging by going to the admin interface and click "Logging" on the left-hand menu. On the assumption that Type is set to None, change it to "File" and apply the changes. That page should also show the path to the log file so you can correct the next commands.. Now you can either tail -f /var/www/bloodhound/installer/bloodhound/environments/main/log/trac.log or just examine the file after you replicate the error. Cheers, Gary On 29/07/13 12:58, Pedro Estrela wrote: I already solve this problem, it was a miss configuration on httpd.conf. The problem now is that i have: "Internal Server Error" :( 2013/7/29 Pedro Estrela <mailto:p.estr...@campus.fct.unl.pt>> Good morning Gary, I followed your instrutions but, when add the WSGIPythonHometo my VirtualHost configurations i get this error: "WSGIPythonHome cannot occur within section" then when i change to Directory or LocationMatch sections i get this one: "WSGIPythonHome not allowed here" 2013/7/25 Pedro Estrela mailto:p.estr...@campus.fct.unl.pt>> Thanks for your help Gary! I can'l on this until Monday. But i will folow your advices. Once again thank you! Pedro 2013/7/25 Gary Martin mailto:gary.mar...@wandisco.com>> On 25/07/13 17:58, Gary Martin wrote: I prefer to recommend installation as a user without admin privileges which is partly the reason for using virtualenv - that and it means that you can have python programs with conflicting package requirements by doing this. Any accidental installation outside of an activated virtualenv - and particularly as root or similar - will install to the system instead. So, your choices here would be one of: 1. install all the packages as admin 2. use pip to uninstall the system packages that were introduced 3. don't worry too much about the system packages that were accidentally installed but still try to make sure that the virtualenv packages are used in preference to system packages Actually it is possible to combine options 2 and 3 - it would make things a bit more robust against other accidental installation events. If you want to go down this route you will still need to work out whether you have the right python-path. It seems likely that it would be correct but you should confirm to yourself that /var/www/bloodhound/installer/bloodhound/lib/python2.6/site-packages does actually exist and it may be worth checking all the other paths to various files are correct. Something else that springs to mind here is that the VirtualHost setup that we suggest also sets user=bloodhound for the WSGIDaemonProcess. I believe this user (or whatever user you have replaced it with) needs to have appropriate access to the installed files. There are notes to this effect in https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer I'll try to get some notes together unless someone beats me to it! Cheers, Gary OK, looks like I have worked out what the wsgi documentation is talking about, though I am actually struggling to replicate an aspect of the problem on my ubuntu server at the moment to see if it is doing what I expect. Perhaps someone else can verify this.. So, *IF* you believe that there are no other programs served through your webserver that this will mess up (that is any other mod_wsgi applications that are running correctly at the moment) then you can do something like the following: sudo mkdir -p /opt/local/apachepythonenv cd /opt/local/apachepythonenv sudo virtualenv --no-site-packages BASELINE sudo vi /etc/apache2/httpd.conf and add the following to that file:
Re: Bloodhond Instalation and Configuration CentOS 6.4
On 25/07/13 17:58, Gary Martin wrote: I prefer to recommend installation as a user without admin privileges which is partly the reason for using virtualenv - that and it means that you can have python programs with conflicting package requirements by doing this. Any accidental installation outside of an activated virtualenv - and particularly as root or similar - will install to the system instead. So, your choices here would be one of: 1. install all the packages as admin 2. use pip to uninstall the system packages that were introduced 3. don't worry too much about the system packages that were accidentally installed but still try to make sure that the virtualenv packages are used in preference to system packages Actually it is possible to combine options 2 and 3 - it would make things a bit more robust against other accidental installation events. If you want to go down this route you will still need to work out whether you have the right python-path. It seems likely that it would be correct but you should confirm to yourself that /var/www/bloodhound/installer/bloodhound/lib/python2.6/site-packages does actually exist and it may be worth checking all the other paths to various files are correct. Something else that springs to mind here is that the VirtualHost setup that we suggest also sets user=bloodhound for the WSGIDaemonProcess. I believe this user (or whatever user you have replaced it with) needs to have appropriate access to the installed files. There are notes to this effect in https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer I'll try to get some notes together unless someone beats me to it! Cheers, Gary OK, looks like I have worked out what the wsgi documentation is talking about, though I am actually struggling to replicate an aspect of the problem on my ubuntu server at the moment to see if it is doing what I expect. Perhaps someone else can verify this.. So, *IF* you believe that there are no other programs served through your webserver that this will mess up (that is any other mod_wsgi applications that are running correctly at the moment) then you can do something like the following: sudo mkdir -p /opt/local/apachepythonenv cd /opt/local/apachepythonenv sudo virtualenv --no-site-packages BASELINE sudo vi /etc/apache2/httpd.conf and add the following to that file: WSGIPythonHome /opt/local/apachepythonenv/BASELINE and restart apache with something like sudo apachectl graceful Doing this should ensure that all wsgi applications will be using a clean python environment without any system installed files at the base so that all those system files that were installed should be completely ignored unless in turn you specify a python-path to the WSGIDaemonProcess option of your VirtualHost that happens to have included the system site packages (which of itself is not a problem if that happens to be what you need). So, now if the VirtualHost definition is otherwise correct, everything should work (I say with my fingers crossed). The question at this point is whether the missing sqlparse error will reappear. If it does, at the moment I would still be suspecting a problem with the VirtualHost configuration. As I say, my failure to replicate the issue does not fill me with confidence with this but I have seen similarly odd behaviour due to accidental sudo pip installs. Cheers, Gary
Re: Bloodhond Instalation and Configuration CentOS 6.4
I prefer to recommend installation as a user without admin privileges which is partly the reason for using virtualenv - that and it means that you can have python programs with conflicting package requirements by doing this. Any accidental installation outside of an activated virtualenv - and particularly as root or similar - will install to the system instead. So, your choices here would be one of: 1. install all the packages as admin 2. use pip to uninstall the system packages that were introduced 3. don't worry too much about the system packages that were accidentally installed but still try to make sure that the virtualenv packages are used in preference to system packages Actually it is possible to combine options 2 and 3 - it would make things a bit more robust against other accidental installation events. If you want to go down this route you will still need to work out whether you have the right python-path. It seems likely that it would be correct but you should confirm to yourself that /var/www/bloodhound/installer/bloodhound/lib/python2.6/site-packages does actually exist and it may be worth checking all the other paths to various files are correct. Something else that springs to mind here is that the VirtualHost setup that we suggest also sets user=bloodhound for the WSGIDaemonProcess. I believe this user (or whatever user you have replaced it with) needs to have appropriate access to the installed files. There are notes to this effect in https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer I'll try to get some notes together unless someone beats me to it! Cheers, Gary On 25/07/13 16:37, Pedro Estrela wrote: You are right. I did all the instalation of bloodhound and trac as admin user and I also didn't know that was as problem. Is there anyway to get over this? The python-path on WSGIDaemonProcess is this /var/www/bloodhound/installer/bloodhound/lib/python2.6/site-packages Thanks, Pedro 2013/7/25 Gary Martin <mailto:gary.mar...@wandisco.com>> Obviously it is a solution of sorts but I don't think it can be recommended so I would quite like to continue investigating how this might have happened if that is OK. Your setup may become confusing on the assumption that you wish to upgrade in the future. At the moment I suspect that you were attempting to have a virtualenv setup but at some point you installed packages as the admin user (or with sudo) by mistake. As the sqlparse package was missing, I think that may suggest that the python-path specified in the WSGIDaemonProcess is not correct. All suspicions so far of course. Cheers, Gary On 25/07/13 15:44, Pedro Estrela wrote: When i ran the tracd i didn't had any troubles. I already fix this problem by manualy copy and past sqlparser to /usr/lib/python2.6/site-packages, although i had this folder on the bloodhound project. 2013/7/25 Gary Martin mailto:gary.mar...@wandisco.com> <mailto:gary.mar...@wandisco.com <mailto:gary.mar...@wandisco.com>>> On 25/07/13 11:47, Pedro Estrela wrote: Hi, I'm new with Apache Web Server. I was told to install Bloodhound on CentOS, I did all steps in https://issues.apache.org/bloodhound/wiki/BloodhoundInstall and also did the steps at https://issues.apache.org/bloodhound/wiki/BloodhoundDetailedInstallation . I have some troubles at the https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer. After the configuration of the Virtual Host and restart of apache i get this unhelpful error: "TracError: ImportError: No module named sqlparse" The weird part is that i have sqlparse module on the project. I already have search a lot on the web but i can't get any help to my problem. Can you help me or give me some guidelines? Thanks. It looks like sqlparse is one of the modules that is installed with the pip install -r requirements.txt command so I would expect you to have seen errors much earlier if it was missing. I would normally suspect that you are using the virtualenv as we suggest in the instructions but the webserver is not using the correct python environment as I expect that to be a relatively common issue. We could attempt to fix that but at this point I am not yet sure if that is the route of your problem. I don't suppose you could confirm that you do not see this problem when you run the tracd standalone server? Cheers, Gary
Re: Can't Login
On 25/07/13 16:28, Pedro Estrela wrote: I need to try Bloodhound's Ticket System, but when i to login I'm getting this message: "No handler matched request to /login" Can you help me how to figure out how to solve it? Thanks I strongly suspect that this is going to be related to your previous issue at this point. Is this only the case when running through the webserver setup? Cheers, Gary
Re: Bloodhond Instalation and Configuration CentOS 6.4
Obviously it is a solution of sorts but I don't think it can be
recommended so I would quite like to continue investigating how this
might have happened if that is OK. Your setup may become confusing on
the assumption that you wish to upgrade in the future.
At the moment I suspect that you were attempting to have a virtualenv
setup but at some point you installed packages as the admin user (or
with sudo) by mistake. As the sqlparse package was missing, I think that
may suggest that the python-path specified in the WSGIDaemonProcess is
not correct.
All suspicions so far of course.
Cheers,
Gary
On 25/07/13 15:44, Pedro Estrela wrote:
When i ran the tracd i didn't had any troubles.
I already fix this problem by manualy copy and past sqlparser
to /usr/lib/python2.6/site-packages, although i had this folder on the
bloodhound project.
2013/7/25 Gary Martin <mailto:gary.mar...@wandisco.com>>
On 25/07/13 11:47, Pedro Estrela wrote:
Hi,
I'm new with Apache Web Server. I was told to install
Bloodhound on CentOS, I did all steps in
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall
and also did the steps at
https://issues.apache.org/bloodhound/wiki/BloodhoundDetailedInstallation
. I have some troubles at the
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer.
After the configuration of the Virtual Host and restart of
apache i get this unhelpful error:
"TracError: ImportError: No module named sqlparse"
The weird part is that i have sqlparse module on the project.
I already have search a lot on the web but i can't get any
help to my problem. Can you help me or give me some guidelines?
Thanks.
It looks like sqlparse is one of the modules that is installed
with the pip install -r requirements.txt command so I would
expect you to have seen errors much earlier if it was missing. I
would normally suspect that you are using the virtualenv as we
suggest in the instructions but the webserver is not using the
correct python environment as I expect that to be a relatively
common issue.
We could attempt to fix that but at this point I am not yet sure
if that is the route of your problem.
I don't suppose you could confirm that you do not see this problem
when you run the tracd standalone server?
Cheers,
Gary
Re: Bloodhond Instalation and Configuration CentOS 6.4
On 25/07/13 11:47, Pedro Estrela wrote: Hi, I'm new with Apache Web Server. I was told to install Bloodhound on CentOS, I did all steps in https://issues.apache.org/bloodhound/wiki/BloodhoundInstall and also did the steps at https://issues.apache.org/bloodhound/wiki/BloodhoundDetailedInstallation . I have some troubles at the https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer. After the configuration of the Virtual Host and restart of apache i get this unhelpful error: "TracError: ImportError: No module named sqlparse" The weird part is that i have sqlparse module on the project. I already have search a lot on the web but i can't get any help to my problem. Can you help me or give me some guidelines? Thanks. It looks like sqlparse is one of the modules that is installed with the pip install -r requirements.txt command so I would expect you to have seen errors much earlier if it was missing. I would normally suspect that you are using the virtualenv as we suggest in the instructions but the webserver is not using the correct python environment as I expect that to be a relatively common issue. We could attempt to fix that but at this point I am not yet sure if that is the route of your problem. I don't suppose you could confirm that you do not see this problem when you run the tracd standalone server? Cheers, Gary
