| [00:13:17] |
* |
srinidhi has left #trac |
| [00:23:49] |
* |
thm has joined #trac |
| [00:23:58] |
* |
prologic_ is now known as prologic |
| [00:24:39] |
* |
coocoon has joined #trac |
| [00:24:54] |
<coocoon> |
hello and good morning short question how to delete the wiki timeline |
| [00:53:18] |
* |
tsr2600 has left #trac |
| [01:04:00] |
* |
jrydberg has joined #trac |
| [01:05:58] |
<otaku42> |
coocoon: what do you mean by "delete" in that regard? what exactly do you want to delete? |
| [01:06:40] |
<coocoon> |
otaku42: i have "designed" my wiki for the start page so there are a lot of entries |
| [01:06:56] |
<coocoon> |
in the timelin and thiese i wanted to delete |
| [01:07:01] |
<coocoon> |
*e |
| [01:07:18] |
<coocoon> |
-i |
| [01:08:35] |
<otaku42> |
coocoon: so you want to get rid of the history of wiki pages? |
| [01:09:16] |
<coocoon> |
yes right |
| [01:09:23] |
<coocoon> |
sorry for confusing |
| [01:09:41] |
<otaku42> |
coocoon: hmm, and only for one page, or for all? |
| [01:10:08] |
<coocoon> |
only for the wiki |
| [01:10:26] |
<otaku42> |
coocoon: yes, but for all wiki pages, or just the start page of the wiki? |
| [01:10:29] |
<coocoon> |
there are the only changes i have made |
| [01:10:42] |
<coocoon> |
hm for all no problem |
| [01:10:51] |
<coocoon> |
i have started yesterday |
| [01:11:53] |
<otaku42> |
coocoon: well, one option that comes to my mind would be using the trac-admin tool. it has some commands to export, import and delete wiki pages. |
| [01:12:16] |
<otaku42> |
coocoon: you could use that to export the current version of all pages, remove them and import them from the previously exported version |
| [01:12:34] |
<otaku42> |
coocoon: never did that myself, but it could work |
| [01:12:46] |
<otaku42> |
coocoon: however, you should make a backup before you start with that, just to be sure |
| [01:13:15] |
<coocoon> |
hm the trac admin-tool will work with 0.9.5 |
| [01:13:18] |
<coocoon> |
? |
| [01:13:29] |
<otaku42> |
yes, it should |
| [01:13:41] |
<coocoon> |
but ok i can do it also in the hard way |
| [01:15:16] |
<coocoon> |
i have stored it there and also python setup.py done ../trac/foo/plugins/webadmin is the folder hierarchy also have enabled it in trac.config but have no options on the trac start page also http://foo/webadmin won't work |
| [01:15:29] |
<coocoon> |
i mena i have stored webadmin |
| [01:15:34] |
<otaku42> |
coocoon: it shouldn't be too hard to write a bash script that makes use of trac-admin to list all wiki pages, dump them to a temporary file, delete the page in the database and import the previously exported version. |
| [01:16:03] |
<coocoon> |
otaku42: ah ok thatnx a lot |
| [01:16:06] |
<otaku42> |
coocoon: but i don't mean webadmin. trac-admin is the command line tool that comes with trac |
| [01:16:28] |
<coocoon> |
ah ok that works fine ;-) |
| [01:17:30] |
<coocoon> |
otaku42: thanx |
| [01:20:47] |
<otaku42> |
coocoon: yw |
| [01:27:54] |
* |
dna has joined #trac |
| [01:43:01] |
<asmodai> |
Morning. |
| [01:46:58] |
* |
Ryan_ has joined #trac |
| [01:47:11] |
* |
Ryan_ has quit IRC |
| [02:12:27] |
<tic> |
PageOutline isn't working with ReStructuredText pages. Should I file a ticket? |
| [02:30:00] |
* |
tuxipuxi has joined #trac |
| [02:40:02] |
* |
maxb has quit IRC |
| [02:41:33] |
* |
maxb has joined #trac |
| [02:55:52] |
* |
MasterC has joined #trac |
| [03:18:41] |
* |
klando_ has joined #trac |
| [03:18:49] |
* |
klando_ is now known as cedricOB |
| [03:47:53] |
* |
coocoon has quit IRC |
| [04:26:26] |
* |
wkornew has joined #trac |
| [04:26:40] |
<wkornew> |
olla |
| [04:29:13] |
<wkornew> |
boorad: are you here? I'd like to discuss DbAuth |
| [04:30:11] |
* |
Synapse_ has joined #trac |
| [04:31:36] |
* |
Synapse has quit IRC |
| [04:31:44] |
* |
Synapse_ is now known as Synapse |
| [04:32:47] |
* |
MasterC has quit IRC |
| [04:43:30] |
* |
thm has left #trac |
| [05:00:15] |
* |
MasterC has joined #trac |
| [05:16:40] |
* |
tschabet has joined #trac |
| [05:34:53] |
* |
tkp has joined #trac |
| [05:34:59] |
<tkp> |
hi |
| [05:35:12] |
<tschabet> |
Hello! |
| [05:35:14] |
<tkp> |
I'm wondering if it's possile to install track without root permissions? |
| [05:35:19] |
<boorad> |
wkornew: I'm here |
| [05:35:26] |
<tkp> |
it says on the website it's not... |
| [05:35:31] |
<tkp> |
but I don't believe it! |
| [05:35:52] |
<wkornew> |
boorad: why does DbAuth have a special 'environment' field? this makes it more complicated to use the code for single-sign-on. I'd like to get rid of it (and possibly support a second global DB, instead). alternatively, I'd start a new plugin that is only about adding single-sign-on to Trac |
| [05:36:46] |
<boorad> |
wkornew: tell me more - tracenv field is to span multiple Trac environments with one auth database |
| [05:37:02] |
<tschabet> |
Maybe someone could help me? I used trac successfully for a couple of weeks. Today we upgraded subversion from 1.3.1 to 1.3.2. Now the source code browser does not work anymore |
| [05:37:22] |
<wkornew> |
boorad: instead of having the tracenv field we could just support two databases: local and global |
| [05:37:38] |
<tschabet> |
The error is: Trac detected an internal error: |
| [05:37:38] |
<tkp> |
is it really true? |
| [05:37:39] |
<tschabet> |
cannot import name SubversionRepository |
| [05:37:40] |
<wkornew> |
boorad: my actual concern is to add SSO |
| [05:37:57] |
<tkp> |
I just installed an apache2 installation in my home dir especially for trac! |
| [05:38:16] |
<boorad> |
wkornew: so the entries in the tables of the central db span all envs and the entries in the tables of the local db are for that db? |
| [05:38:20] |
<tschabet> |
The Python traceback reports: Python traceback |
| [05:38:22] |
<tschabet> |
Traceback (most recent call last): |
| [05:38:24] |
<tschabet> |
File "/usr/lib64/python2.3/site-packages/trac/web/modpython_frontend.py", line 206, in handler |
| [05:38:25] |
<tschabet> |
dispatch_request(mpr.path_info, mpr, env) |
| [05:38:27] |
<tschabet> |
File "/usr/lib64/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request |
| [05:38:28] |
<tschabet> |
dispatcher.dispatch(req) |
| [05:38:29] |
<wkornew> |
boorad: probably this goal does not fit with DbAuth, so I could as well just use your code to create a new plugin that supports a few major CMSes |
| [05:38:30] |
<tschabet> |
File "/usr/lib64/python2.3/site-packages/trac/web/main.py", line 107, in dispatch |
| [05:38:31] |
<tschabet> |
resp = chosen_handler.process_request(req) |
| [05:38:33] |
<tschabet> |
File "/usr/lib64/python2.3/site-packages/trac/versioncontrol/web_ui/browser.py", line 78, in process_request |
| [05:38:34] |
<tschabet> |
repos = self.env.get_repository(req.authname) |
| [05:38:36] |
<tschabet> |
File "/usr/lib64/python2.3/site-packages/trac/env.py", line 155, in get_repository |
| [05:38:38] |
<tschabet> |
from trac.versioncontrol.svn_fs import SubversionRepository |
| [05:38:39] |
<tschabet> |
ImportError: cannot import name SubversionRepository |
| [05:38:48] |
<boorad> |
tschabet: use pastebin please |
| [05:39:12] |
<boorad> |
wkornew: how many copies of username/password will this split in db's create? |
| [05:39:17] |
<wkornew> |
boorad: yes, one DB for all envs, one DB for current env. but we could as well just have only one DB for everything. |
| [05:39:29] |
<wkornew> |
boorad: none |
| [05:40:02] |
<wkornew> |
boorad: the local DB should get higher priority, so it's searched first. if there's a match that DB will be used. otherwise the global one will be used (same as with envs) |
| [05:40:15] |
<boorad> |
what is in the local db tables for SSO? |
| [05:40:36] |
<wkornew> |
boorad: but do we really need this env separation? I mean, does it not suffice to *either* share one DB for all envs *or* have one DB per env? |
| [05:41:04] |
<tschabet> |
boorad: sorry for flooding the channel with my error message. ?? what is pastebin ?? how can i use this ?? |
| [05:41:19] |
<tkp> |
does anyone know... is it possible to insttall track without root permissions? |
| [05:41:20] |
<wkornew> |
boorad: if at all, only the cookie stuff would exist for SSO. actually, the whole login and registration function should be taken over by the CMS |
| [05:41:27] |
<boorad> |
wkornew: sticking with the tables already in dbauth, cookies and perms? |
| [05:42:37] |
<wkornew> |
boorad: that would work, too, but I wanted to have SSOHandlers which know the DB layout of some CMS or forum or whatever and use that information to login |
| [05:42:50] |
<boorad> |
tschabet: http://trac.pastebin.com/ |
| [05:43:23] |
<boorad> |
tschabet: and then just post the resulting URL |
| [05:43:38] |
<wkornew> |
boorad: I'm not sure...I actually wanted to have a way to integrate Trac into a website (see http://code.djangoproject.com/) |
| [05:43:52] |
<boorad> |
wkornew: I'm kind of lost, kind of following |
| [05:44:34] |
<wkornew> |
boorad: I guess it's better to create a new plugin... |
| [05:45:28] |
<boorad> |
wkornew: not necessarily - more code, esp. duped code isn't a good thing |
| [05:45:35] |
<wkornew> |
boorad: I just wanted to suggest a simplification. having logins for all envs and env-specific logins mixed does not look very nice |
| [05:45:54] |
<boorad> |
are you talking about the 'all' env name? |
| [05:46:16] |
<wkornew> |
boorad: no, I'm talking about the whole env column |
| [05:46:23] |
<boorad> |
what about a users to envs xref table |
| [05:46:25] |
<wkornew> |
I'd like it to go away |
| [05:46:47] |
<wkornew> |
it makes SSO impossible |
| [05:46:57] |
<wkornew> |
(or requires a lot of hacks) |
| [05:46:58] |
<boorad> |
I agree it doesn't feel clean, but it's really convenient to add 'all' and any new envs created - the user has access |
| [05:47:41] |
<boorad> |
so what about that users to envs table? |
| [05:47:50] |
<wkornew> |
but why is it not sufficient to have all envs access the same DB? |
| [05:48:04] |
<boorad> |
lost me ^^ |
| [05:48:44] |
<wkornew> |
let's start simple: what is the env table intended for? |
| [05:48:44] |
<boorad> |
you want one copy of username/password for each user - one list of users across all envs, no? |
| [05:49:48] |
<boorad> |
wkornew: there is no env table |
| [05:49:53] |
<wkornew> |
env column :) |
| [05:50:35] |
<boorad> |
it is to assign a permission to a user, in that env |
| [05:50:55] |
<wkornew> |
why do you need that? |
| [05:51:20] |
<boorad> |
a user could have different perms in different envs |
| [05:51:46] |
<boorad> |
are you asking why there is an env field in the users table? that may be a valid question and I don't recall right now |
| [05:51:49] |
<wkornew> |
okay, but why do we need the 'env' column in the trac_users table? |
| [05:52:09] |
<boorad> |
but if I want to have TRAC_ADMIN in envA and only WIKI_VIEW in envB - the env field in the perms table allows me to accomplish that |
| [05:53:51] |
<boorad> |
env column in users table: - see _check_login() in auth.py |
| [05:54:16] |
<boorad> |
we could get rid of that column and replace with a table of user to env mapping |
| [05:54:35] |
<boorad> |
because I didn't want to rely on a record being present in the perms table that assigns a user to an env |
| [05:54:49] |
<boorad> |
some users might not have any access to certain envs, follow? |
| [05:55:15] |
<wkornew> |
yes...I just don't like it when using it with SSO... |
| [05:55:39] |
<boorad> |
you have not commented on getting rid of the column and having a users to env mapping table |
| [05:55:47] |
* |
ofri has joined #trac |
| [05:55:54] |
<wkornew> |
I mean, ideally the CMS should handle users and groups and Trac should handle Trac-related permissions |
| [05:56:18] |
<boorad> |
agreed, so you could swap out the plugin's users table with the CMS's tables |
| [05:56:19] |
<wkornew> |
what about group-to-env? |
| [05:56:38] |
<boorad> |
but then you have to put each user in a group |
| [05:57:37] |
<wkornew> |
yeah...we should probably not distinguish between users and groups too much...as long as the name matches it will work... |
| [05:57:46] |
<boorad> |
agreed |
| [05:57:55] |
<wkornew> |
isn't that already the way Trac works? |
| [05:57:59] |
<boorad> |
y |
| [05:58:38] |
<boorad> |
what was your django example above - what's that integration? |
| [05:58:39] |
<wkornew> |
alternatively, we could add a prefix "u:<username>" and "g:<groupname>"... |
| [05:59:08] |
<boorad> |
staying true to Trac is Simple, I wouldn't go down that road |
| [05:59:09] |
<wkornew> |
well, it's not really integrated on that site. it's just about integrating Trac within the website, too |
| [05:59:44] |
<wkornew> |
well, I'd prefer having something like groups == users, too |
| [05:59:49] |
<boorad> |
dsource.org has integrated phpBB, Trac, Drupal - all on the auth of phpBB (which was first, unfortunately) |
| [06:00:23] |
* |
chendo has joined #trac |
| [06:00:28] |
<chendo> |
anyone use the ticketdelete plugin? |
| [06:00:30] |
<boorad> |
users never have to log into Trac or Drupal - it's done for them by looking at the cookies |
| [06:00:48] |
<boorad> |
so that's SSO, in a sense |
| [06:01:05] |
<wkornew> |
okay, but Trac and Drupal are distrinct, aren't they? |
| [06:01:17] |
<wkornew> |
I'd like to have real website integration, too |
| [06:01:30] |
<boorad> |
distinct in what way - they're separate apps, yes |
| [06:01:43] |
<wkornew> |
ah, no...sorry. |
| [06:01:44] |
<boorad> |
they both give web pages, and share 'some' nav items, so you can get around |
| [06:01:51] |
<wkornew> |
that's what I'd like to have |
| [06:02:05] |
<chendo> |
i'm having trouble installing the ticketdelete plugin |
| [06:02:09] |
<chendo> |
i download the 2.4 egg |
| [06:02:12] |
<chendo> |
put it in the plugin dir |
| [06:02:15] |
<chendo> |
anything else i have to do? |
| [06:02:23] |
<chendo> |
also tried uploading it via the webadmin page |
| [06:02:27] |
<boorad> |
chendo: enable it in either local or global trac.ini |
| [06:02:44] |
<chendo> |
how? i have no clue what the component name is :/ |
| [06:03:19] |
<wkornew> |
boorad: it's totally unobvious how to register and login. do I really have to go to the forums? |
| [06:03:44] |
<boorad> |
wkornew: yes, and I don't like that about the site |
| [06:04:03] |
<boorad> |
chendo: it would be in the code |
| [06:04:09] |
<wkornew> |
there should be simple "Register" and "Login" links at the top of the page |
| [06:04:17] |
<boorad> |
wkornew: agreed - it's a work in progress |
| [06:04:32] |
<boorad> |
as my real job is kicking my ass now, I'm not finding a lot of time |
| [06:05:13] |
<wkornew> |
do you have the code for your SSO implementation somewhere? is it based on DbAuth? |
| [06:05:50] |
<chendo> |
boorad, what does it look like? |
| [06:06:06] |
<boorad> |
chendo: http://www.trac-hacks.org/browser/ticketdeleteplugin/0.10 - looks like the module name is 'ticketdelete' |
| [06:06:26] |
<boorad> |
wkornew: it's not based on DbAuth - until I had more DbAuth users like you who pushed the featureset |
| [06:06:28] |
<chendo> |
would it be ticketdelete.* = enabled ro just ticketdelete? |
| [06:06:31] |
<boorad> |
bbiam |
| [06:06:33] |
<wkornew> |
boorad: and which part of your website is Drupal? it all looks like Trac... |
| [06:06:45] |
<boorad> |
tango.dsource.org |
| [06:06:53] |
* |
bringa has left #trac |
| [06:06:54] |
<chendo> |
okay i got it nevermind |
| [06:11:26] |
<chendo> |
hmm |
| [06:11:33] |
<chendo> |
it showed up in the plugins list once |
| [06:11:35] |
<chendo> |
then disappeared |
| [06:12:25] |
<chendo> |
wait nvm, got it |
| [06:17:38] |
<ofri> |
hi |
| [06:17:50] |
<ofri> |
anyone willing to help me please? |
| [06:21:30] |
<boorad> |
wkornew: back now |
| [06:21:51] |
<wkornew> |
ok |
| [06:22:32] |
<wkornew> |
Durpal is too much distinct from the rest of the website. is it not possible to replace the wiki with a CMS? |
| [06:22:42] |
<wkornew> |
just a suggestion... |
| [06:23:25] |
<boorad> |
Drupal is only for that one project - if it works, though, others might use it |
| [06:23:25] |
* |
agile has quit IRC |
| [06:23:26] |
<wkornew> |
is your SSO code generic enough, so I could use it or is DbAuth better? |
| [06:23:49] |
<boorad> |
SSO code is really specific to phpBB because that was in place before anything else |
| [06:23:54] |
<boorad> |
I'd use DbAuth if I were you |
| [06:23:59] |
<wkornew> |
ok |
| [06:24:20] |
<boorad> |
and I would encourage you to fold your changes into DbAuth rather than start a new plugin |
| [06:24:26] |
<wkornew> |
so, should we create a second DbAuth branch that is mostly for SSO? |
| [06:24:36] |
<boorad> |
but that's up to you - I'm willing to include your changes to make this existing plugin better |
| [06:25:00] |
<wkornew> |
it's always better to work on a bigger project |
| [06:25:08] |
<wkornew> |
than code somehting for yourself |
| [06:25:10] |
<boorad> |
Nah, let's use the /trunk and have it serve SSO needs as well as basic DbAuth |
| [06:25:25] |
<wkornew> |
good. the problem is that we'd have to change DB layout |
| [06:25:46] |
<boorad> |
so eliminate the env column from users |
| [06:25:54] |
<boorad> |
add a user/group to env table |
| [06:26:08] |
<wkornew> |
the SSO code could be modular, so you can just use the "Trac-auth" module instead of "Drupal" or "phpBB", for example |
| [06:26:12] |
<boorad> |
leave the env column in the perms and cookies tables? |
| [06:26:42] |
<wkornew> |
can't the cookies table be replaced with the CMS auth's cookie? |
| [06:26:48] |
<boorad> |
it was my hope to start using Trac and modify Drupal and phpBB to use it |
| [06:27:10] |
<wkornew> |
I'd like Trac to use the cookie from the CMS (not the other way around) |
| [06:27:20] |
<boorad> |
from system to system that might change |
| [06:27:40] |
<boorad> |
sometimes it will be better to use the DbAuth cookie b/c the CMS doesn't have the right info, or whatever |
| [06:28:14] |
<boorad> |
I would lean toward the plugin being self-sufficient vs. assuming something is there in another package |
| [06:28:41] |
<boorad> |
also long-term goal is to make forums/discussion/newsgroup type plugin for Trac and jettison phpBB |
| [06:29:42] |
<wkornew> |
the self-sufficient stuff could be implemented by a special SSO handler (which assumes that there is nothing for handling the rest). I'd like to move the cookie stuff into handlers. the plugin should only know users, groups, and itself handle a permission mapping between users/groups and envs |
| [06:30:03] |
<boorad> |
sounds good |
| [06:30:18] |
<boorad> |
you will have more time to work on this than I will - do you have commit rights to the repos? |
| [06:30:41] |
<boorad> |
your sha-1 patch looks great, so you could commit that as well |
| [06:30:46] |
<wkornew> |
I'm just a Python newbie, so I don't know how to implement it such that it's modular, too (so you can load the DbAuth plugin for generic auth and the DbAuthDrupal plugin for Drupal interfacing) |
| [06:31:03] |
<wkornew> |
how do I get commit rights? |
| [06:31:07] |
<wkornew> |
I registered |
| [06:31:12] |
<wkornew> |
but I couldn't commit |
| [06:31:21] |
<boorad> |
alect would need to set you up, I think |
| [06:31:23] |
<wkornew> |
do you have to add me to some group? |
| [06:31:36] |
<boorad> |
he seems 'away' |
| [06:31:51] |
<boorad> |
btw, I'm a relative newbie to Python, too |
| [06:32:18] |
<boorad> |
but we would want to make extension points that our 'backends' could use (Drupal, phpBB, others) |
| [06:32:27] |
<wkornew> |
I really like the clean syntax. it's not perfect, but it's a lot better than those stupid C-like concepts |
| [06:32:50] |
<wkornew> |
please elaborate |
| [06:33:11] |
<wkornew> |
I was thinking of creating plugins for the CMS |
| [06:33:26] |
<wkornew> |
if that's needed, at all |
| [06:33:37] |
<boorad> |
http://projects.edgewall.com/trac/wiki/TracDev/ComponentArchitecture |
| [06:34:01] |
<boorad> |
just like Trac is a bunch of extension points and plugins, this SSO/DbAuth stuff could be, too |
| [06:34:23] |
<wkornew> |
okay, thanks for the link. I'll try to read everything... |
| [06:34:35] |
<boorad> |
wkornew: stupid C-like concepts - you should omit D from this, although it shares a lot of syntax |
| [06:35:02] |
<wkornew> |
heh, no, I don't really like D. it's just a minor step forward from C++ |
| [06:35:04] |
<boorad> |
D is like the power of C++ with the ease of Java/Ruby/Python |
| [06:35:29] |
<wkornew> |
when I read the D manual I was overwhelmed by all those features...it's overloaded |
| [06:35:46] |
<wkornew> |
I like Smalltalk a lot more |
| [06:35:47] |
<boorad> |
if you look deeper, it will end up being much more than a minor step forward from C++ but it will take time to win developers |
| [06:36:02] |
<boorad> |
and I really like Lisp, but we're OT |
| [06:36:08] |
<wkornew> |
but the syntax is not as nice as Python...a hybrid would be cool :) |
| [06:36:18] |
<wkornew> |
okay, back to DbAuth :) |
| [06:37:13] |
<boorad> |
actually, I have to get to work |
| [06:37:25] |
<wkornew> |
there is one problem: how can we keep the interface simple enough for SSO? for example, there should not be an admin interface and password changing should not be enabled, by default. |
| [06:37:48] |
<wkornew> |
too bad...I'll just implement something... |
| [06:37:55] |
<wkornew> |
who else can give me commit rights? |
| [06:38:02] |
<boorad> |
I'll send an email to alect |
| [06:38:06] |
<wkornew> |
thanks |
| [06:38:12] |
<wkornew> |
my nick is wkornew ;) |
| [06:38:19] |
<boorad> |
;) |
| [06:39:18] |
<wkornew> |
is it okay if I move the "change password" and other stuff to the "SelfHosting" handler? so, SSO handlers won't have this... |
| [06:40:21] |
<wkornew> |
okay...I'll just make that optional and let the handlers decide which defaults to use... |
| [06:40:26] |
<wkornew> |
bye boorad |
| [06:45:46] |
<boorad> |
be sure to read the ComponentArchitecture linky above - we are just implementing extension points now, but we could make our own, and then fill them with separated plugins to be activated or deactivated in the [dbauth] section of trac.ini |
| [06:45:58] |
<boorad> |
wkornew: sorry, should have put your nick ^^ |
| [06:45:59] |
* |
whitelynx|firest has joined #trac |
| [06:46:42] |
<wkornew> |
boorad: maybe we should just have a monolithic module? |
| [06:47:09] |
<wkornew> |
I mean, there is no point in creating extra modules if you can just extend our source and share your modular with us |
| [06:47:31] |
<wkornew> |
s/modular/module/ |
| [06:47:49] |
<boorad> |
but sometimes you want SSO and sometimes you don't |
| [06:47:58] |
<boorad> |
and SSO modules will be different plugins |
| [06:48:03] |
<boorad> |
we'll have a suite of auth plugins |
| [06:48:11] |
<wkornew> |
boorad: there will be a configuration option "handler = SelfHosting" or "handler = Drupal"... |
| [06:48:28] |
<boorad> |
ok, lemme take a look at what you come up with |
| [06:48:29] |
<wkornew> |
all handlers could be part of DbAuth |
| [06:48:43] |
<boorad> |
yes, just modular inside of DbAuth |
| [06:48:54] |
<boorad> |
module == handler, it seems |
| [06:49:06] |
<wkornew> |
I once was a big friend of �odularization, but for most apps it does not add any value. it just complicates everything |
| [06:49:28] |
<wkornew> |
independent classes, one per handler. yes |
| [06:49:50] |
<wkornew> |
boorad: but we don't need extension points for this, do we? |
| [06:49:56] |
<boorad> |
maybe not |
| [06:51:21] |
<wkornew> |
good, as simple as possible |
| [06:51:26] |
<boorad> |
If we will end up there anyway, then it is better to do it early - trac.core is a nice plugin system and DrupalHandler.* = enabled is nice for config |
| [06:52:04] |
<boorad> |
but you can try simple for a while - if it looks like we'll end up needing trac.core, then let's try to make that decision early |
| [06:52:37] |
<wkornew> |
I doubt that we'll need it. DrupalHandler will be *very* simple. it's not worth to create a special plugin for it |
| [06:53:00] |
<boorad> |
you're probably right |
| [06:53:27] |
<boorad> |
will we need to have Drupal patched? |
| [06:53:47] |
<wkornew> |
btw, could you please send me your SSO code? I'd like to see what I can reuse |
| [06:53:57] |
<wkornew> |
I'd prefer if the CMS would not need patching |
| [06:54:03] |
<boorad> |
email me - brad@dsource.org |
| [06:54:05] |
<wkornew> |
only Trac should need a plugin |
| [06:54:59] |
<wkornew> |
hmm, maybe someone would like to write an OpenID plugin? too early... :)) but it would be nice to get rid of this web auth hell |
| [07:04:46] |
<ofri> |
can anyone please help me with moving my trac environment to a different server? |
| [07:06:57] |
<tuxipuxi> |
yup |
| [07:07:13] |
* |
agile has joined #trac |
| [07:07:17] |
<ofri> |
thanks :) |
| [07:07:36] |
<ofri> |
so basically, i just installed trac on the new server and copied the env over |
| [07:07:48] |
<ofri> |
but it says something is wrong with the db |
| [07:08:02] |
<tuxipuxi> |
database is encrypted or not a database? |
| [07:08:02] |
<ofri> |
sec i'll give the right message |
| [07:08:29] |
<ofri> |
what do you mean? |
| [07:08:38] |
<tuxipuxi> |
if that's the error message :) |
| [07:09:53] |
<ofri> |
"Command failed: unsupported file format" |
| [07:09:54] |
* |
xjjk has joined #trac |
| [07:10:29] |
<tuxipuxi> |
is the new server running a different sqlite version? |
| [07:11:14] |
<ofri> |
the new one is using 3.3.6 and the old one used 3.1.3 |
| [07:12:08] |
<tuxipuxi> |
ah.. that should be fine. is there a more verbose error message in the error log? |
| [07:15:30] |
<ofri> |
not that i know of |
| [07:15:38] |
<ofri> |
is there a log file somewhere? |
| [07:16:15] |
<tuxipuxi> |
if you're using apache it's usually in /var/log/apache2/error.log. there should be a better error message |
| [07:16:27] |
* |
ofri takes a look |
| [07:17:06] |
<ofri> |
oh, what was i thinking |
| [07:17:13] |
<ofri> |
i get this message from trac-admin |
| [07:18:33] |
<ofri> |
trying to access the env through the web just times out (that's also what the log says) |
| [07:19:06] |
<tuxipuxi> |
uhm |
| [07:19:22] |
* |
danbeck has joined #trac |
| [07:19:41] |
* |
MasterC has quit IRC |
| [07:19:58] |
<ofri> |
creating a new env works fine, btw |
| [07:21:36] |
<tuxipuxi> |
ofri: could you try the following in your env's db directory: mv trac.db trac2.db && sqlite3 trac2.db .dump | sqlite3 trac.db? |
| [07:21:40] |
* |
MasterC has joined #trac |
| [07:23:25] |
<ofri> |
wow |
| [07:23:27] |
<ofri> |
it works! |
| [07:23:32] |
<tuxipuxi> |
great |
| [07:23:35] |
<ofri> |
thanks!! :D |
| [07:23:42] |
<tuxipuxi> |
np :) |
| [07:24:17] |
<ofri> |
what did i do, btw? if sqlite can dump the db it should be able to read it so i don't get it.. |
| [07:25:28] |
* |
tschabet has quit IRC |
| [07:26:07] |
<shawn_work> |
gug |
| [07:26:57] |
<tuxipuxi> |
ofri: the wiki says "This probably is symptomatic of a mismatch between the SQLite library and the SQLite database format" |
| [07:28:16] |
<ofri> |
hmm |
| [07:28:19] |
<ofri> |
ok |
| [07:28:20] |
<ofri> |
:) |
| [07:29:15] |
<ofri> |
strange.. |
| [07:29:37] |
<ofri> |
tuxipuxi: i can view the env but trac-admin still gives the same error |
| [07:29:58] |
* |
MasterC has quit IRC |
| [07:30:17] |
<ofri> |
(view in the web i mean) |
| [07:30:49] |
* |
wkornew has quit IRC |
| [07:31:12] |
<tuxipuxi> |
THAT's strange :) |
| [07:31:19] |
<ofri> |
yep |
| [07:31:29] |
<tuxipuxi> |
do you have multiple python versions installed? |
| [07:31:43] |
<ofri> |
yes |
| [07:32:13] |
<ofri> |
but i configured trac with --prefix |
| [07:32:16] |
<tuxipuxi> |
assuming that you're using mod_python, is mod_python probably using a different python version than your default version? |
| [07:32:40] |
<tuxipuxi> |
i.e. the version that trac-admin is running with |
| [07:32:51] |
<ofri> |
might be |
| [07:32:55] |
<ofri> |
sec, lemme check |
| [07:33:14] |
<tuxipuxi> |
i'd guess that you're having different pysqlite versions for your python versions thus this error message |
| [07:34:13] |
<ofri> |
yeah |
| [07:34:36] |
<ofri> |
the web server is even using sqlite 2.8.16 |
| [07:35:16] |
<ofri> |
but then how can it read a db created with sqlite 3? |
| [07:35:41] |
<tuxipuxi> |
are you sure? |
| [07:35:51] |
<ofri> |
yes |
| [07:35:57] |
<ofri> |
umm |
| [07:36:06] |
<ofri> |
probably not because it doesn't seem possible |
| [07:36:12] |
<tuxipuxi> |
yeah |
| [07:36:43] |
<ofri> |
how can i check the pysqlite version? |
| [07:36:51] |
<tuxipuxi> |
i'd suggest to install the same pysqlite version for all python versions and you should be fine. or you could simply run trac-admin with the python version the web server is running |
| [07:37:14] |
<tuxipuxi> |
hm dunno |
| [07:37:29] |
<ofri> |
the thing is, i'm on a shared host |
| [07:37:37] |
<ofri> |
so i have no idea what they have there |
| [07:37:56] |
<ofri> |
i just installed everything in my home from scratch |
| [07:38:19] |
<ofri> |
except the web server of course |
| [07:38:44] |
<tuxipuxi> |
ah i see |
| [07:38:53] |
<tuxipuxi> |
dreamhost? |
| [07:38:56] |
<ofri> |
yep |
| [07:39:08] |
<ofri> |
heh |
| [07:39:55] |
<ofri> |
the previous server was a os x server and i just installed trac using darwinports and used tracd |
| [07:40:13] |
<ofri> |
apache is a pain on os x |
| [07:40:25] |
<tuxipuxi> |
ah |
| [07:40:51] |
<tuxipuxi> |
can you execute trac-admin with the python version that apache is running? |
| [07:41:09] |
<ofri> |
how would i do that? |
| [07:41:52] |
<tuxipuxi> |
like python2.3 /path/to/trac-admin |
| [07:42:05] |
<ofri> |
'k |
| [07:43:55] |
<ofri> |
ImportError: No module named trac.scripts.admin |
| [07:45:08] |
<tuxipuxi> |
the python version of the web server actually must know trac hmhm |
| [07:46:05] |
<tuxipuxi> |
damned shared host environment :) |
| [07:46:24] |
<ofri> |
not sure.. i used the fast cgi hack suggested in http://wiki.dreamhost.com/index.php/Trac |
| [ |
