Team Chat Logs

April 21, 2010

2010 3
Mo Tu We Th Fr Sa Su
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
<< <   > >>

[00:01:31.008438]<Sacho>when I use changeset_collapse_events in trac 0.12, instead of showing [rev1]-[rev2] it just shows [rev2]
[00:01:43.604485]<Sacho>Any idea why that could be happening?
[00:15:00.150793]<sivang>Hi All
[00:15:15.312281]<sivang>I'm reading over http://trac.edgewall.org/wiki/TracMultipleProjects/MultiTrac
[00:15:24.034230]<sivang>Has there any work done in that direction already ?
[00:24:34.425724]<sivang>I am also curious why this proposal is not well accpeted ?
[00:24:45.424462]<sivang>http://trac.edgewall.org/wiki/TracMultipleProjects/ByProductAndSearch
[00:24:47.172204]<sivang> ^^^^
[00:37:34.900106]<Mitar>how can i do a defition list with terms starting with number and a dot? Like 42. foobar?
[00:59:52.619458]<slam>sivang: this proposal is good, but old. there has been some work via plugins, but all of them not 100% complete. as we needed it hardly, we actually hacked it ourselves for http://code.zikula.org/ (multi-project, multi-svn, hudson and pootle integration). but most of the part we did is done by an hand full of bash scripts.
[01:00:50.789832]<slam>sivang: the only missing part is single login/auth - which is possible via openid-plugin, but we did not like it after testing
[01:08:11.194540]<sivang>slam: so is ther esomething to be shared or should I use the MultiProduct plugin ?
[01:08:28.720391]<sivang>slam: what is preventing us from representing a software component in a product rather than in a project?
[01:08:44.418957]<sivang>slam: shared by you with me, for my purpose , that is :)
[01:09:59.907748]<sivang>slam: what is Zikula ?
[01:14:10.005400]<slam>sivang: multiproduct-plugin is a good idea - but it will not give you one entire trac environment per sub-project
[01:14:39.932442]<slam>sivang: we needed extra wiki, milestones, timeline, tracker by sub-project
[01:14:52.252562]<sivang>slam: this does not allow wiki per each product ?
[01:19:48.397613]<sivang>slam: how does corss project queries work ?
[01:19:55.787993]<sivang>slam: s/corss/cross/
[01:20:30.647184]<slam>sivang: you talk about this plugin? http://trac-hacks.org/wiki/TracForgePlugin
[01:20:37.926469]<slam>sivang: or our hack?
[01:22:43.271555]<slam>sivang: in ours we use searchall-plugin, superuser-plugin, openid-plugin and several others
[01:26:32.840293]<slam>sivang: and for sub-project creation scripts like this one https://noc.sidux.com/website/browser/trunk/trac/trac-create (simple variant)
[01:29:00.532524]<sivang>slam: that plugin looks nice
[01:29:06.228669]<sivang>slam: what does it entail so far?
[01:29:22.811468]<sivang>slam: I will now also look at the sub project creation script
[01:30:16.441880]<slam>sivang: a quite similar approach was doen here http://trac-hacks.org/wiki/AdminToolkitScript
[01:31:01.849939]<sivang>slam: your script looks good
[01:31:28.215848]<sivang>slam: so again, all I am missing is cross-project queries, what's the state of that with your stuff or others?
[01:31:44.693823]<slam>sivang: there is also a plugin for that
[01:32:57.147505]<slam>http://trac-hacks.org/wiki/MultipleProjectQueryFilterPlugin
[01:33:54.663939]<slam>sivang: see also this link http://trac-hacks.org/tags/%27multi-projects%27
[01:33:59.261024]<sivang>slam: I see, is there somewhere a doc how to setup it all to achieve a multi project env? I see it also uses one htpasswd for all the projects
[01:34:08.625582]<sivang>slam: which for me is good, I want one login for all the projects
[01:34:36.513683]<sivang>slam: maybe we can write such a doc together?
[01:34:42.848125]<sivang>slam: for the benefit of the community ?
[01:35:46.932778]<slam>sivang: well, the trac-create script is already documented - there is not much more to say. also be careful, it needs to be adapted for every different server (paths, database, ...)
[01:36:19.263689]<sivang>slam: yes I saw, okay I will start with that and come back here if I have questions. I will try to take notes so eventually we will have a document somewhere for others that come after me,.
[01:36:26.819294]<sivang>slam: do you have gtalk ?
[01:36:27.536047]<slam>sivang: i use it on debian and centos, with sqlite and postgresql
[01:36:41.547032]<sivang>slam: I have all these dependencies
[01:36:53.889903]<sivang>slam: but I use centos as the server OS, IT policies
[01:37:48.663080]<slam>sivang: trac is no fun on centos - outdated stoneage versions of almost everthing you need
[01:38:29.990357]<slam>sivang: specially python, but also apache itself, the database - all that performs much better with newer versions
[01:39:20.874220]<slam>sivang: i mostly use sidux/debian sid for those servers. that ensures modern versions, easy to administer, performance and security
[01:40:19.540752]<slam>sivang: a multi-trac multi-svn thingy does eat some ressources, so you really need performace
[01:41:15.805712]<sivang>slam: I have all hardware I can eat, and they build everything for me from source, so no worries on the outdated thing
[01:41:29.907395]<slam>sivang: ok
[01:41:39.577149]<slam>sivang: if you have slaves ;-)
[01:41:46.054530]<sivang>slam: heh
[01:41:56.245963]<sivang>slam: they just not willing to let someone from R&D do it
[01:41:57.642194]<sivang>;)
[01:42:03.696926]<sivang>slam: so they have to put up work
[01:42:47.563265]<sivang>slam: to anal about security and server uptime
[01:43:21.364863]<slam>my favorite setup: centos xen host system, and all the trac/svn stuff in a debian sid guest like this one:
[01:43:23.370718]<slam>Host/Kernel/OS "rcs2.zikula.net" running Linux 2.6.32-4-xen-amd64 x86_64 [ sidux 2010-01 Σύρος - xen-server - (201001101630) ]
[01:43:24.891313]<slam>CPU Info 4x Dual-Core AMD Opteron 2212 1024 KB cache flags( sse3 ht nx lm ) clocked at [ 1994.999 MHz ]
[01:43:26.359391]<slam>Videocard tty resolution ( 180x64 )
[01:43:27.855378]<slam>Processes 156 | Uptime 3days | Memory 906.7/2556.8MB | HDD Size unknown.. () | Runlevel 2 | Client Shell | Infobash v3.30
[01:43:40.859388]<sivang>wow cool
[01:43:46.489707]<sivang>do you need some PHP help ?
[01:43:52.951695]<slam>that's the zikula server for example
[01:44:00.399479]<sivang>very cool
[01:44:13.868373]<sivang>what's the project alla bout? has it some relation to the ZF ?
[01:44:52.714027]<slam>sivang: zikula (formerly known as postnuke) is a web application framework, with hundreds of 3rd party plugins
[01:45:03.576094]<sivang>slam: all in pure PHP ?
[01:45:11.974294]<slam>sivang: and the server i linked to you is our service for 3rd party plugin developers
[01:45:36.652312]<slam>sivang: yes, plus xml/css/html/javascript
[01:45:44.666604]<sivang>slam: I see, does Zeev and Andi know about this? :)
[01:46:10.329446]<slam>sivang: http://zikula.org/CMS/Zikula/
[01:47:28.811959]<FlaPer87>hey guys, Is it possible to show just a sub page title index using the TitleIndex macro? I mean, I have wiki/people and I want to show all pages under wiki/people
[01:47:55.586214]<sivang>slam: you use distro php or zend server?
[01:48:06.535835]<sivang>slam: I was one of the guys of Zend Core btw :)
[01:48:20.507537]<slam>sivang: stock php5.3 from debian sid
[01:48:29.110168]<sivang>slam: I see.
[01:48:45.119221]<slam>sivang: with some - security related - adaption in config
[01:49:00.480650]<sivang>slam: right, so in ZS you're getting this through an automatic subscription
[01:49:40.077182]<sivang>slam: have you had any experience with trac - admin ?
[01:50:06.417852]<sivang>slam: s/trac - admin/Admin Toolkit/
[01:50:23.585021]<sivang>slam: I'm trying to guess at which approach to hit on first, your script or that "Toolkit"
[01:52:05.784878]<osimons>FlaPer87: take a look at the TocMacro - it is a more flexible alternative: http://trac-hacks.org/wiki/TocMacro
[01:53:33.537567]<slam>sivang: i have never used the toolkit - it was developed after my stuff was done and deployed already
[01:53:56.075249]<slam>sivang: but it looks quite similar to my approach - done in python, though
[01:54:08.355819]<slam>sivang: i prefer bash, c
[01:54:10.577591]<sivang>slam: I see, also the toolkit seen to not provide cross-project queries and wikis
[01:54:17.964571]<sivang>slam: your a PHPinst :)
[01:54:24.452306]<sivang>slam: I love them both
[01:54:25.488121]*slam shuts up as this channel is python territory ;-)
[01:54:29.004070]<sivang>hehe
[01:54:37.754450]<sivang>I am a former Zend employee ;)
[01:54:59.309319]<sivang>I've done something in PHP the other day that would have taken me 3 times the time in python
[01:55:26.641530]<slam>i got used to pyhton via trac, actually
[01:55:53.891455]<slam>we needed trac to get rid of our old gforge setup, so i needed to pick up python :-)
[01:57:43.632428]<hasienda>hello all
[01:59:29.029920]<sivang>slam: the toolkit looks like the tracish way to it, do you know if it supports cross project queries ?
[02:00:07.021740]<hasienda>if anyone cares, I've put some effort into fixing issues with proposed implementation of custom time fields support, at least all I'm aware of
[02:01:23.004084]<hasienda>not it comes to beta-testing, I think. Only task for myself is notification stuff, to be tested and adapted for custom time field values, if needed
[02:02:51.783533]<hasienda>I recommend taking a look at http://trac.edgewall.org/wiki/TracTicketsCustomTimeFields for development notes and get patches from http://bitbucket.org/hasienda/custom-time
[02:07:02.354591]<hasienda>next on my ToDo is to rebase to Trac trunk >= r9478 - the latest change to trac/ticket/model.py
[02:07:09.980771]<sivang>slam: PHP is greared highly at web dev
[02:11:49.586059]<Mitar>how can i do a defition list with terms starting with number and a dot? Like: 42. foobar:: ?
[02:17:20.125258]<osimons>hasienda: is that a proper hg patch queue? it looks like a bunch of patches in a repos as I can't see a 'series' file. checking it out, it provides patches against an empty repos - 'qpush' onto an empty repos is not so useful...
[02:19:25.575571]<hasienda>osimons: Mercurial / MQ beginner, sorry. This is _meant_ to be a valid hg patch queue.
[02:19:57.094149]<hasienda>osimons: I need to include series file, well? Anything else missing?
[02:20:13.091879]<osimons>what you want to do is make a patch queue based directly on the Trac repos clone, and in that patch queue add your patches in correct order in the series - that way i can check out your repos, run "hg qpush -a" to apply all your patches and test your code
[02:21:06.910379]<hasienda>osimons: make a patch queue based directly on the Trac repos clone - done, this is from rblanks repo, stated in the devel docs
[02:21:27.189989]<osimons>- and then rebasing is just a matter of a) hg qpop -a to pop all the patches, b) fetch new revs from rblanks clone, and c) do hg qpop on each patch to make sure it applies, and finally a d) hg qcommit if patches have chaned
[02:21:46.392443]<osimons>hasienda: no, it isn't - i see that the patches are against that, but the repos is not available
[02:21:49.946326]<osimons>hasienda: look at hg qclone http://bitbucket.org/osimons/trac-rpc-mq
[02:22:07.692811]<osimons>hasienda: sorry, http://bitbucket.org/osimons/trac-rpc-mq
[02:22:42.609734]<osimons>that is a clone of the XmlRpc plugin that I got, but when you check out the repos you get BOTH the base plugin code AND the patches
[02:23:13.767422]<osimons>bitbucket has done some clever tricks here that lets you get all the code through one clone
[02:23:26.326690]<hasienda>osimons: well, I simply didn't see the use for just another repo, since rblanks was already good enough for me. But now I get your point.
[02:23:32.332560]<osimons>(qclone = clone repos with patch queue)
[02:24:26.276631]<osimons>hasienda: yeah, and the point is that it is so easy to a) apply and use, and b) rebase at certain points by fetching new revisions from rblank
[02:25:01.129137]<hasienda>osimons: will fix this right away and come back then, but still
[02:25:31.941146]<osimons>patch queues are great, btw - like the initiative :-)
[02:25:55.435135]<hasienda>osimons: Do you see anything else but the series file, I'd need to push from my local repo and patch queue?
[02:27:50.365782]<osimons>that's it i think - for the patch queue at least
[02:31:21.591349]<Mitar>so there is no way to define a defition list with terms starting with number and a dot? Like: 42. foobar:: ?
[02:31:56.385240]<osimons>Mitar: huh. it sees that as a numbered list, then?
[02:32:22.508594]<Mitar>yes
[02:34:45.150713]<osimons>Mitar: hmm, can't have both - problem supporting both, i can see that. other way would be problems having lists that end in '::'
[02:35:19.386835]<Mitar>yes, but there could be some way arond this
[02:35:25.450342]<Mitar>i think it is easier to write !:: then
[02:35:32.056263]<Mitar>(to suppress ::)
[02:35:38.561812]<Mitar>then now where there is no way around it
[02:36:02.974938]<osimons>Mitar: yeah, perhaps. no way of escaping the list now then? prefix your number?
[02:36:18.939207]<Mitar>! stays :-(
[02:36:53.031972]<Mitar>it makes a definition list, but ! is displayed
[02:41:45.495623]<osimons>Mitar: yeah. i'd suggest a new ticket with brief intro to the issue. ideally the escaping of both !42. and !:: should be possible, imho - let the order be as it is (most people write lists after all), and allow escaping of either.
[02:43:53.283382]<osimons>hasienda: btw, i remember reading this blog post before actually catching what went on at bitbucket. recommended: http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org
[02:46:07.639270]<hasienda>hasienda: well, that's what I startet with, actually more confusing than helpful I think, but thanks anyway for the note
[02:47:55.181776]<osimons>hasienda: hehe :-)
[02:57:37.905461]<slam>does acct_mgr.web_ui.EmailVerificationModule = enabled actually check if exisitng accounts do have an email adress?
[02:58:24.351124]<slam>e.g. is it reinforced if a user removes his email adress from his account after verification?
[03:50:05.343046]<hasienda>osimons: did the necessary arrangements from what I understood to be needed, should work now.
[03:50:50.422354]<hasienda>osimons: and a major edit to improve http://trac.edgewall.org/wiki/TracTicketsCustomTimeFields
[03:52:03.324471]<hasienda>osimons: now hg qclone https://hasienda@bitbucket.org/hasienda/custom-time works for me
[03:52:34.524183]<osimons>me too, hasienda - get both repos and patch queue. better? :-)
[03:53:01.731639]<hasienda>osimons: yes sir, thank you for spotting and helping me.
[03:53:07.258317]<hasienda>:-)
[03:53:29.881348]<osimons>hasienda: no probs - just pointers. glad you figured it out. it is really a useful way of working, i find.
[03:54:32.586626]<hasienda>osimons: amazing, how bitbucket.org does the mapping of repo and corresponding MQ.
[03:55:29.051349]<osimons>hasienda: i keep a patch queue that may contain all kinds of stuff - and just use the series file as a scratchpad, commenting things and more. see for instance http://bitbucket.org/osimons/trac-rpc-mq/src/tip/series
[03:56:47.499753]<osimons>- my local patch queue for Trac 0.11 and Trac Trunk contains 100's of patches, basically my recent history of changes as well as all the patches of others i've tested and so on. work in progress + history of committed changes with notes and todos
[03:58:26.065555]<hasienda>osimons: yes, I'm just digging into it, but already feel the power. :-)
[03:58:31.701011]<hasienda>osimons: pushing my clone of rblanks repo I got this reported back: Entfernt: added 5317 changesets with 14947 changes to 1026 files | Entfernt: bb/acl: hasienda is allowed. accepted payload. | Entfernt: quota: 41.4 KB in use, 1.0 GB available (0.00% used) - well amazing.
[03:58:56.933252]<osimons>hasienda: that way you can for instance also make a 'plugins' directory, and store the patches in the queue but commented out with a note to not apply them directly here... - would for instance allow me to keep an eye on your patch for my customfieldadmin plugin that the wiki page says you have somewhere
[03:59:39.941432]<osimons>hasienda: nice.
[03:59:49.518691]<hasienda>osimons: will do, was already wondering where to put it.
[04:00:26.996795]<hasienda>osimons: will inform you right after uploading
[04:00:49.418344]<osimons>goodie.
[04:01:59.082254]<hasienda>osimons: certainly customfieldadmin plugin is not a pre-requisite for custom time fields, but nice to have it, since it makes setup really easy. - I like it.
[04:03:05.564210]<osimons>hasienda: it is a simple thing, and unobtrusive. i needed it as no project admins has access to command line on my hosted service. should get it into trac core at some stage - feel it belongs there...
[04:04:21.464072]<hasienda>osimons: btw, since you praised MQ, rblank mentioned lately, he would try again to wrap his head arround it, after I announced I would use it too. :-)
[04:05:31.930197]<osimons>hehe.
[04:08:50.231440]<hasienda>osimons: > ... make a 'plugins' directory, and store the patches (for customfieldadmin plugin)
[04:09:10.867233]<hasienda>osimons: how about the existing ./contrib?
[04:09:32.652929]<osimons>hasienda: nope - not in the trac repos, in your patches repos
[04:10:22.880852]<osimons>hasienda: the patches are just files, so you can cd .hg/patches and treat that as a regular repos
[04:11:09.057082]<hasienda>osimons: you ment, I should put customfieldadmin plugin code AND my patch for it into ./patches ?
[04:11:57.123488]<hasienda>osimons: that is ./<local-repo-root>/.hg/patches
[04:12:11.210601]<osimons>like; cd .hg/patches; mkdir plugins; # copy your patches there; hg addremove; # vi your series file and add notes there about the patches; hg commit -m "adding patches for plugins, not enabled in series file"
[04:13:16.060244]<osimons>hasienda: right, just the patch but not the plugin code itself - that would be too many things. this is basically just a simple way of tracking changes to these "external" patches in one place as you make your main changes
[04:13:55.462302]<hasienda>osimons: ah, just the patches, without qnew or qimport, well thats clear now.
[04:14:10.915450]<osimons>i can pull out the patch individually and apply it to my plugin to test if i want to. but for you it is just using the patch repos as storage
[04:14:49.237928]<hasienda>osimons: I'm not familiar with making notes to series file, but will look into above mention repo, like you did it.
[04:15:01.757180]<osimons>hasienda: even if you do qnew or qimport, you can just qpop them and edit the plain text 'series' file and comment out the patches (with notes as other comments)
[04:15:20.301882]<osimons>hasienda: it is plain text - any line starting with # is a comment
[04:15:42.004915]<osimons>makes it really nice and flexible - just copy and paste lines to reorder patches or whatever
[04:16:48.350944]<osimons>hg will put qnew/qimport patches at the top of the file, but will not change location of any other lines meaning your comments wll stay intact over time and follow the lines where they are applied
[04:17:26.222845]<hasienda>osimons: ok, just what I wanted to ask about, but as long as I don't qnew/qimport, there is even no need to edit series, since ./patches will be just storage tracked by hg without interfering with MQ parts
[04:17:37.140866]<osimons>hasienda: seeing you have so many patches, the series file could also document what each patch does.
[04:17:45.132451]<osimons>hasienda: correct. it is just a repos.
[04:18:45.790719]<hasienda>osimons: well, since you helped me understanding it, I'll do that and make the purpose of each more clear
[04:19:01.521785]<hasienda>osimons: wanted to do that in Trac wiki before
[04:19:02.871207]<osimons>hasienda: when editing or changing manually, just make sure to do qpop -a first to make sure no patches are applied, to not risk confusing hg
[04:20:12.590753]<hasienda>osimons: well, now it seems series file is a really great place to describe the patches in detail
[04:20:25.262826]<osimons>hasienda: ah ok, still just linking to the series file may be easier when developing? jotting down # TODO items as you develop and remember things to fix etc. however, you decide on your own flow - i'm just suggesting based on what works for me
[04:22:23.141491]<hasienda>osimons: your suggestions are much appreciated :-) After all I'm with Mercurial and MQ for less than three weeks now.
[04:25:18.755794]<osimons>hasienda: also, the notes i add to each patch as i develop makes it easy to get a good commit message when i commit the patch days, weeks or even months later...
[04:25:18.996303]<osimons>
[04:33:09.653847]<vlt>Hello. I want to install trac 0.12dev to get i18n support. I installed genshi and babel, but when I try to run `./setup.py compile_catalog -f` I get "babel.core.UnknownLocaleError: unknown locale 'ja'". Any idea how to fix this?
[04:33:53.528315]<vlt>(as the last line of a Traceback)
[04:34:17.646329]<sivang>rehi
[04:34:23.012158]<sivang>is coderanger here?
[04:34:32.492161]<sivang>or is he at PDT ?
[04:35:08.117417]<osimons>vlt: how did you install babel?
[04:35:16.718738]<osimons>@seen coderanger
[04:35:16.728747]<evil_twin>coderanger was last seen on irc.freenode.net at Wed, 14 Apr 2010 22:34:35 +0100, quitting: *.net *.split
[04:35:40.146178]<osimons>@seen coderanger_
[04:35:41.146224]<evil_twin>coderanger_ was last seen on irc.freenode.net at Sat, 10 Apr 2010 23:35:33 +0100, quitting: Client Quit
[04:35:57.179166]<osimons>sivang: ^^ all we know, i think
[04:36:24.994314]<vlt>osimons: First I tried svn tags/0.9.5, then trunk and got the same error.
[04:37:20.543380]<hasienda>osimons: find the patch for http://trac-hacks.org/wiki/CustomFieldAdminPlugin in ./opt/customfieldadminplugin_customtimefields-support.patch
[04:37:28.949833]<osimons>vlt: if running from an svn checkout, babel won't include the cldr data - see http://babel.edgewall.org/wiki/SubversionCheckout
[04:38:01.364707]<vlt>osimons: What's the recommended way to install Babel (on Debian)?
[04:38:02.971750]<osimons>vlt: it gets packaged into releases, so best thing is just to easy_install babel
[04:38:07.383182]<sivang>osimons: okay, thanks
[04:38:09.923378]<hasienda>osimons: and thanks again for help with series file and MQ alltogether.
[04:39:21.040872]<osimons>cool stuff, hasienda - all in one place :-)
[04:40:20.484167]<hasienda>osimons: yes, indeed, will do the same for announcer plugin stuff
[04:41:12.699624]<hasienda>osimons: Well, I need to go for now, will be back in some hours (what is evening in old Europe here), maybe we'll join in then again.
[04:41:35.222716]<osimons>hasienda: same timezone then i suppose - i'm CET
[04:42:07.218707]<vlt>osimons: Thank you. When using easy-install now I get "Babel 1.0dev-r545 is already the active version in easy-install.pth" (because I installed from svn). Is there a --force-packed-version option?
[04:42:21.010500]<osimons>easy_install -U babel
[04:42:30.401144]<osimons>-U = force upgrade
[04:42:39.002956]<vlt>osimons: Already tried this, didn't help :(
[04:43:25.908183]<osimons>vlt: then find your site-packages, and remove babel directory + the entry from easy_install.pth in there => "uninstalls"... :-)
[04:43:30.296718]<hasienda>osimons: almost, CEST - Germany, still with the time zone switching idiots :-(
[04:43:51.560287]<osimons>hasienda: same though? I'm in Norway.
[04:44:34.925623]<hasienda>osimons: I see, well I'll go now. - Over and out ...
[04:44:41.530047]<osimons>later.
[04:50:59.858519]<vlt>osimons: Can you help? I found /usr/share/pycentral/python-setuptools/site-packages/, but not a single file there contains "babel" ...
[04:51:29.975066]<osimons>vlt: run this; python -c "import babel; print babel.__file__"
[04:51:42.647354]<osimons>=> should tell you where it finds the babel source
[04:52:09.992574]<vlt>osimons: Thanks
[04:58:16.587109]<vlt>Next problem: `trac-admin <project> upgrade` => "OperationalError: no such table: repository"
[04:58:45.682566]<vlt>The old project is from 0.10.3
[05:03:21.653483]<vlt>Every attempt creates an sqlite....bak file. What could be missing here?
[05:06:19.966815]<vlt>I checked the sqlite3 db file. There's indeed no such table "repository".
[05:06:23.107959]<osimons>vlt: don't know really. you are then upgrading a 0.10.3 database to a version for the latest trac trunk? and the upgrade bombed?
[05:06:40.960984]<vlt>osimons: At least I try to, yes.
[05:06:43.396654]<osimons>in the system table, what version does it say for trac
[05:06:50.791777]<osimons>ie. trac db version
[05:08:01.808755]<vlt>osimons: There's a "database_version" = "19" row
[05:09:31.342785]<vlt>There's an empty "version" table
[05:09:45.150095]<osimons>vlt: likely something originally crashed on the first upgarde you ran, and the db is not in the correct state for subsequent backup routines. hope you have a copy of the db, and i'd try running it again and carefully watch output... http://trac.edgewall.org/browser/trunk/trac/upgrades
[05:10:17.474448]<osimons>link to the upgrade scripts being run, and if you are at 19 it should try to run 20 and up to latest in turn
[05:11:09.593133]<vlt>osimons: I'm trying to upgrade a copy of the DB first, of course. I'll make a new one. Thank you
[05:20:31.678760]<vlt>osimons: Hmmm, even on a fresh copy of the project I get this error. No further output.
[05:20:53.659076]<vlt>When I try to `trac-admin <project> repository add ...` I get the same error
[05:21:30.593254]<vlt>Maybe I should just create the table manually.
[05:22:27.066349]<osimons>vlt: so, if you do trac-admin $newproject initenv, the database is not usable?
[05:22:55.313224]<osimons>or "fresh" as in upgraded ok?
[05:24:47.767840]<vlt>osimons: No, sorry, "fresh" copy means a clean copy of a 0.10.3 project dir where no upgrade attempt could have messed things up before ...
[05:25:28.703169]<osimons>vlt: and that db is the upgraded to latest - and trac reports all to be fine & dandy (before erroring)?
[05:25:29.391870]<vlt>osimons: A really fresh project created by 0.12's initenv contains the repository table.
[05:26:14.946365]<osimons>vlt: that needs investigation - a beta is being scheduled shortly, and upgrades will need to work 100% correct
[05:26:15.148004]<vlt>osimons: That db runs fine on 0.10.3, I want to upgrade it to 0.12
[05:27:13.680583]<osimons>vlt: then "trac-admin $env upgrade" is what should be run, and where trac-admin is of course the one from trunk
[05:27:57.243296]<vlt>trac-admin is r9505 from trunk
[05:28:17.097128]<osimons>that sounds fine then. and it upgrades and reports all ok?
[05:28:21.107783]<vlt>In 0.10.3 there was no need for a repositoy table because you could only manage one repo, right?
[05:28:31.362281]<osimons>right - it is a 0.12 feature
[05:29:22.949526]<vlt>osimons: No, when I try to run r9505's `trac-admin $env upgrade` I get that error ("missing repo table")
[05:29:41.798610]<osimons>does it say what script number it is running?
[05:29:51.969048]<osimons>it gets added in db23: http://trac.edgewall.org/browser/trunk/trac/upgrades/db23.py
[05:30:28.614687]<osimons>you start at db version 19, and should then run 20 -> 26 without failing...
[05:31:08.809504]<vlt>osimons: It says nothing but the error message. Is there a --verbose mode?
[05:32:49.468851]<osimons>vlt: think i got it... http://trac.edgewall.org/browser/trunk/trac/upgrades/db26.py changes the table added in db23 - but that table is not yet committed and can't be found
[05:34:28.916528]<osimons>vlt: try this trick.... locate this file http://trac.edgewall.org/browser/trunk/trac/db_default.py
[05:34:38.092142]<osimons>(in your running code)
[05:35:04.672314]<osimons>and change line 20 to: db_version = 25
[05:35:47.749550]<osimons>that means it will run up to 25 and stop when upgrading, allowing table to be committed. then bump back to 26 again and run upgrade again for last change
[05:36:38.357857]<osimons>=> then most importantly if this works, create the bug report and explain the issue: http://trac.edgewall.org/newticket?type=defect
[05:36:53.382590]<osimons>(even if it won't work of course...)
[05:37:13.094642]<osimons>this just has to work for beta users....
[05:43:53.849692]<vlt>osimons: I found the file in my working copy, changed db_version to 25 and ran `./setup.py install --force`. I got a new /usr/bin/trac-admin` but the same error when running the upgrade.
[05:44:37.528269]*vlt tries setting it to 20 first
[05:45:24.453367]<osimons>vlt: python -c "import trac.db_default; print trac.db_default.__file__"
[05:46:13.645268]<osimons>=> should tell you the installed db_default.py file - you can just edit that directly, so no need to keep installing. re-running trac-admin (python) will use the new version
[05:46:41.410465]<osimons>but, good idea - try running each upgrade in turn up to latest
[05:47:16.391095]<vlt>osimons: Even 19->20 fails.
[05:48:28.688366]<osimons>oh. i see. something in trac-admin expects the table to exist when it initiates the env. not good.
[05:48:42.857886]<osimons>@logging
[05:48:42.872522]<evil_twin>logging is http://trac.edgewall.org/wiki/TracLogging <-- Enable debug logging to file, ensure your environments log/ directory is writeable by your web server user, check for errors.
[05:48:58.079586]<vlt>Running your print command from within the working copy (which I did first) returns "trac/db_default.pyc", from somewhere else it returns that file in an /usr/lib/.../.egg file
[05:49:30.683100]<osimons>vlt: ^^ could you enable debug logging for the env, and it should contain the full traceback for what goes wrong
[05:49:41.561868]<osimons>(when rerunning the upgrade)
[05:50:07.855888]<osimons>basically [debugging] log_level = DEBUG & log_type = file (IIRC)
[05:50:37.552008]<osimons>move to strike.... [logging] it is called :-)
[06:06:17.254732]*sivang waits for coderanger to come online
[06:23:10.312158]<vlt>osimons: "2010-04-21 15:15:15,779 Trac[__init__] INFO: Trac database schema version is 19, should be 20"
[06:23:13.830844]<vlt>http://pastebin.org/165613
[06:26:26.398617]<slam>!fp
[06:26:31.652344]<slam>!frickel
[06:32:12.700702]<osimons>vlt: as expected. that is a bug.
[06:34:15.839243]<osimons>vlt: would really appreciate you reporting this bug - that way you would also be in the loop for when it is fixed (which really should be quickly). copy lines 48-71 of the log you pasted, and update the "should be 20" to "should be 26" to make it actually correct.
[06:35:52.796234]<osimons>basic issue: trac-admin $env upgrade tries to load the environment, finds it needs upgrade, and then preceeds to load an environment that requires new-style repository with own tables.
[06:36:13.152458]<osimons>commonly known as "catch-22"
[06:36:19.499261]<osimons>vlt: ^^ would you mind?
[06:43:58.664433]*vlt reports the bug
[06:48:27.414446]<vlt>(after I found out what catch-22 stands for)
[06:51:00.451108]<Sacho>Is there a way to prevent emails getting masked in ticket descriptions?
[06:53:17.809326]<Sacho>sorry, found it
[07:35:05.783653]<sivang>so
[07:35:09.929352]<sivang>I need to be TRAC_ADMIN
[07:35:16.105829]<sivang>how do I do that without using Apache?
[07:35:27.912510]<sivang>I need to have the WebAdmin enabled for TracForge
[07:35:46.333519]<sivang>How do I enable authentication without apache or htpasswd ?
[07:37:06.103127]<cmc>sivang: those are two different questions
[07:37:12.988297]<cmc>to answer the first, look at trac-admin
[07:37:40.188014]<sivang>cmc: right so I did the add user thing in trac admin but there was not way to set up the password ?
[07:38:53.510067]<cmc>the password is based on your authentication scheme: http://trac.edgewall.org/wiki/TracCgi#AddingAuthentication describes the basic options
[07:39:20.401115]<cmc>there are plugins to handle ldap and in the db
[07:39:32.949874]<cmc>i think there's even an openid one
[08:04:30.531000]<sivang>cmc: how do you go about setting authentication through the standalone server?
[08:04:34.181873]<sivang>cmc: that is not on the docs
[08:04:51.010563]<cmc>it is, one moment
[08:05:18.418009]<cmc>http://trac.edgewall.org/wiki/TracStandalone#UsingAuthentication
[08:06:45.359518]<sivang>cmc: okay, so this is the instructions for apache'less auth ?
[08:09:38.860567]<osimons>vlt: thanks. and looks like a fix should be forthcoming. goodie.
[08:10:37.120159]<cmc>sivang: yes, those are instructions for using tracd
[08:14:52.661323]<sivang>cmc: thanks
[08:14:53.849427]<cboos>retracile: around? I was trying to get figleaf working, but I obviously have some issues (on Windows); any catch I should be aware of?
[08:15:10.243405]<cmc>sivang: no problemo
[08:16:00.542849]<cboos>retracile: e.g. for the unit test coverage, the only green lines correspond to the module load, all the rest is red
[08:17:15.703732]<cboos>retracile: also, for the functional tests, the following command (taken from the Makefile) seems suspicious:
[08:17:17.587060]<cboos>FIGLEAF=figleaf python trac/tests/functional/__init__.py -v
[08:19:04.059548]<cboos>hm, well, actually I see now where it should be used, but I get no .figleaf generated
[09:25:26.944672]<retracile>cboos: hrm.....
[09:26:28.436611]<retracile>cboos: on trunk, I presume
[10:05:25.961361]<cboos>retracile: yes, trunk; I've gone a bit further;
[10:05:40.140746]<cboos>running: PYTHONPATH=. figleaf trac/test.py
[10:05:53.840337]<cboos>then: figleaf2html -d figleaf/ .figleaf --exclude-patterns=trac/tests/figleaf-exclude
[10:06:20.299582]<cboos>I see in ..._trunk_trac_test.py.html the following strange effect
[10:08:43.419301]<cboos>(waiting for paste.lisp - well here it is anyway http://paste.lisp.org/display/98096)
[10:09:25.706367]<cboos>but on stdout, I see "Ran 1192 tests in 227.391s OK"
[10:10:10.288231]<cboos>so the tests are indeed run, but not for figleaf which stops at doctest.testmod(sys.modules[__name__])
[10:10:28.578529]<cboos>... could it be the weird "del __builtins__._" that follows?
[10:10:47.344723]<retracile>cboos: hm...
[10:11:08.724561]<cboos>I'll continue investigating, I was just wondering if you had already seen this, apparently not ;-)
[10:11:29.682109]<cboos>(when running figleaf trac/tests/allwiki.py for example, it works fine)
[10:13:09.189443]<retracile>cboos: it's been a while since I looked at this in depth. http://paste.lisp.org/display/98097 is the script I run; the (../trac-setup script adds stuff to PYTHONPATH and makes sure the egginfo is created, etc.)
[10:13:38.068150]<retracile>I get some errors at the end of the run that I haven't run into yet
[10:13:42.632695]<retracile>s/run/looked/
[10:13:42.642584]<evil_twin>retracile meant: I get some errors at the end of the looked that I haven't run into yet
[10:14:02.262421]<retracile>bah. I get some errors at the end of the run I haven't looked into yet.
[10:16:08.481388]<cboos>figleaf-latest-ejc, which one is this?
[10:16:30.600275]<cboos>I have 0.6.1
[10:19:41.928424]<retracile>Hm... 0.6.1, but probably has something patched since I have my initials on it. Heh; it's been nearly 2 years since I changed anything in it; let me look.
[10:21:18.036365]<retracile>Hm... but I don't see any deltas.
[10:25:11.669544]<cboos>the problem was actually with the doctest.testmod(sys.modules[__name__]) line - after commenting that out, the coverage info was as expected
[10:32:53.014094]<cboos>retracile: have you tested coverage also? (instead of figleaf)
[10:55:35.396577]<retracile>cboos: You might ping thatch about it, but no, I don't think we tried coverage.
[10:56:11.025892]<cboos>ok - but I think I've fixed it
[10:57:17.974453]<cboos>(the unit test part, at least)
[10:57:38.280092]<cboos>now I have to see why I don't get a .figleaf for the functional tests...
[11:00:03.717825]<retracile>cboos: try running "python trac/tests/functional/testcases.py -v" instead of the __init__.py
[11:08:50.831744]<rblank>Hello everyone!
[11:09:05.231939]<retracile>hey rblank :)
[11:09:36.457049]<cboos>hello and bye ... have to go, maybe later this evening
[11:09:45.221034]<retracile>cboos: c-ya
[11:10:07.401222]<cboos>(will wait for the end of "python trac/tests/functional/testcases.py -v" though ;-) )
[11:10:24.662337]<cboos>as it's quite slower than usual, I suppose it works ...
[11:10:36.293793]<rblank>cboos: So, where's 0.12beta1? :)
[11:11:05.275955]<retracile>cboos: ha! Yeah, you've got a half-hour to wait, if your machine is comparable to mine....
[11:11:05.479369]<cboos>I still have a small todo list ... testing your patches on #9230 among others ;-)
[11:11:27.019800]<rblank>Right. Anything else where I can help out?
[11:11:46.018741]<rblank>I've got some free time tomorrow and Friday.
[11:11:48.390550]<cboos>yeah, for the translation, you made one mistake in default_workflow.py
[11:11:54.629932]<rblank>Did I?
[11:11:58.236665]<retracile>Yeah, what is taking you two so long to get this done? ... wait, why are you looking at me like that? I haven't done anything... OH.
[11:12:27.693543]<cboos>rblank: see the 3 fuzzy or untranslated I left on purpose in trac/locale/fr/.../messages.po
[11:12:38.218339]<rblank>Ok, will do.
[11:13:20.559626]<cboos>you have a tag_("as ", tag(...)) instead of tag_("as %(something)s", something=tag(...)) (from memory)
[11:13:40.483132]<cboos>you did the two others correctly though ;-)
[11:13:56.268857]<rblank>cboos: I've got only two fuzzies in the french translation, none of which is the case you describe.
[11:14:10.614667]<cboos>so it must be the untranslated one, search for "as "
[11:14:12.099019]<rblank>But I should be able to find it nevertheless. The whole translation stuff is still pretty new to me.
[11:14:36.473054]<rblank>Right, there it is.
[11:14:47.381915]<cboos>and I think we should as well wait for Genshi 0.6 now, which shouldn't be that far away now ;-)
[11:15:00.049494]<rblank>So it will be a rc1 then?
[11:15:04.447450]<rblank>Just kidding :)
[11:15:25.085168]<cboos>I'm running r1115 on t.e.o, but there are some new changes, among them a fix for the <?python ?> extraction hack (we should get rid of it)
[11:15:40.845461]<cboos>(if possible, i.e. if the problem is really fixed)
[11:17:24.539500]<cboos>retracile: so if indeed doing the coverage on testcases.py works, what do I lose from not doing it on __init__.py?
[11:17:38.079315]<cboos>(must go)
[11:17:41.597912]<retracile>cboos: off the top of my head, I don't know.
[11:17:50.273499]<retracile>cboos: ok, I'll be on later.
[11:17:53.093298]<cboos>Ran 115 tests in 1000.426s
[11:17:57.823863]<cboos>let's see...
[11:18:05.687723]<retracile>cboos: you have a better machine than I :)
[11:18:13.258383]<cboos>.figleaf !
[11:18:31.912501]<retracile>yay! :)
[11:18:33.951394]<cboos>136 files total: 26 files > 90%, 45 files > 75%, 89 files > 50%
[11:18:38.990092]<cboos>great
[11:19:16.395143]<cboos>ok, it's on the right path, see you later!
[11:21:36.348983]<hasienda>rblank: hello, I understand busy times before 0.12, appreciate the focus on I18n issues and the improvements done, since all my use cases need German env.
[11:21:50.518168]<rblank>hasienda: But...
[11:23:50.100433]<cmc>hasienda's just here to be thankful, duh
[11:25:19.837532]<hasienda>cmc: no, not the only reason ...
[11:25:28.465496]<cmc>;)
[11:25:44.582443]<hasienda>rblank: however, just want to inform, that there is progress towards custom time fields, just doing rebase to Trac trunk r9478 in a minute. Got help from osimons this morning, who happened to be the maintainer of customfieldadmin plugin too.
[11:26:38.188253]<rblank>hasienda: I'm following your work with great interest. Haven't had a chance to try your patches yet, though.
[11:26:57.145464]<hasienda>rblank: Mercurial repo is prepared, setting up a quickstart HowTo for easy testing with MQ without need to know it this evening.
[11:27:49.947223]<rblank>hasienda: Cool.
[11:29:00.854915]<hasienda>rblank: reward comes from the work itself, even beeing a freshman with Python I already got a whole new view at Trac insides.
[11:30:07.499182]<rblank>hasienda: You'll see that having one's work actually applied to the project code is even more rewarding.
[11:30:21.749045]<retracile>gotta run; be back in a while....
[11:30:35.658538]<rblank>hasienda: I still remember the day when cboos applied my first patches, about... almost 2 years ago I think.
[11:31:30.948699]<rblank>hasienda: It felt great. I hope that I'll be able to produce the same feelings for you. Sorry about the delay.
[11:33:26.732391]<hasienda>rblank: Inspired me to start work on some numeric fields for trac, that would ease the use with numbers, i.e. currency (calculation) with support for multiple units (g|kg|t), etc.
[11:34:09.124511]<hasienda>rblank: Remember having read about it in a Trac ticket, will have to look it up, once custom time fields are mature enough.
[11:34:38.308897]<rblank>hasienda: Make sure you keep the patches separate, so as to make them easier to review.
[11:35:23.015468]<hasienda>rblank: sure, that was just to mention another related enhancement proposal
[11:36:44.124467]<hasienda>rblank: once you look at it, you'll see it is quit well organized.
[11:37:25.312254]<hasienda>rblank: not to say, there could and will be lots of possibilities for improvement
[11:38:57.293697]<hasienda>rblank: osimons suggested putting docu about individual patched in .hg/patched/series, where info on MQ resides too.
[11:39:25.416306]<rblank>hasienda: osimons is very good with Mercurial, so do follow his advice.
[11:40:07.462110]<hasienda>rblank: you might wish to look at it, once I've pushed the next rev with some more content in there
[11:40:54.398392]<hasienda>rblank: yeah, he was of great help with few word indeed.
[11:41:04.578056]<rblank>hasienda: As I said, top priority is 0.12 at the moment.
[11:42:58.651051]<hasienda>rblank: np. At least I have an alternative to skip date/time strings for my new project right from the start, and there is a starting point for others now
[11:45:19.632422]<hasienda>rblank: and you don't mind me pinging you from time to time, please.
[11:45:29.314156]<hasienda>:-)
[11:45:52.008514]<rblank>hasienda: np
[11:55:24.971296]<hasienda>rblank: just did rebase on pull from your repo, Trac trunk r9478, and all patches still apply cleanly. Looks like I can keep up for a while like this. ;-)
[11:55:45.508186]<hasienda>rblank: Thanks for your repo, in fact I wanted to go exactly for the very same revision when looking through the latest changesets before.
[11:56:02.018563]<rblank>hasienda: Wait, that's not the latest. Let me push...
[11:56:43.018216]<rblank>hasienda: There you go, latest is r9507.
[11:57:33.193065]<hasienda>rblank: not the latest, I know, but regarding ticket system there was nothing more of interest between r9478 and r9507
[11:57:44.035825]<rblank>hasienda: Right.
[11:58:20.258295]<hasienda>so it was good for me
[12:03:17.048812]<osimons>evening, good people.
[12:24:36.565803]<svm_invictvs->Hey, is there a way to increase the file attachment size limit?
[12:29:19.879519]<pacopablo>hello
[12:29:24.132255]<pacopablo>finally!
[12:29:33.859435]<pacopablo>so, svm_invictvs-, look at the trac.ini
[12:29:38.150311]<pacopablo>@wiki TracIni
[12:29:38.158396]<evil_twin>http://trac.edgewall.org/wiki/TracIni
[12:30:22.495947]<pacopablo>specifically: http://trac.edgewall.org/wiki/TracIni#attachment-section
[12:30:26.279742]<pacopablo>look at max_size
[12:37:44.282045]<retracile>pacopablo: "finally!" ???
[12:41:31.319367]<pacopablo>retracile: wasn't able to post to the channel
[12:41:41.690952]<retracile>pacopablo: ah, I see.
[12:41:42.720201]<cboos>rblank: congrats for the 100%
[12:41:53.899415]<pacopablo>was due to not being authenticated with nickserv
[12:42:18.089143]<rblank>cboos: Thanks. Back in an hour, must go play the Wii :)
[12:42:18.371583]<retracile>pacopablo: ah, yeah, I've had that happen when it didn't seem to make sense for it to have happened.
[12:42:26.354326]<retracile>rblank: have fun :)
[12:42:27.636852]<cboos>rblank: I'll do some more tests this evening and then upgrade t.e.o to r9512 (and latest Genshi)
[12:42:41.021863]<cboos>rblank: good luck!
[13:51:10.433982]<hasienda>osimons: evening to you too.
[13:53:32.952389]<hasienda>osimons: filed an enhancement pointing to the patch for customfieldadmin as a reminder http://trac-hacks.org/ticket/7015
[13:57:16.027237]<osimons>hasienda: got it.
[13:58:57.721587]<cboos>hasienda: hi, I've tried to look at your patch queue - however commenting on them doesn't seem to be easy; or I missed some feature on BitBucket
[14:00:53.480941]<hasienda>cboos: might actually want to push as a fork of my MQ repo? Want me try to give you needed rights?
[14:01:37.284404]<cboos>well, I'm just wondering what would be the best way to comment on those patches
[14:01:57.900513]<cboos>(I don't want to rework them myself yet ;-) )
[14:02:31.740251]<hasienda>cboos: I could even activate issue tracker (not done by now), but I'd prefer comments to ticket just mentioned.
[14:24:55.020344]<cboos>hasienda: if the issue tracker on bitbucket has some review facilities, it might be worth it ... otherwise, this is just going to give me more ideas about how we could do something about reviews in trac proper ;-)
[14:28:19.231816]<hasienda>cboos: issue tracker activated.
[14:28:56.951526]<cboos>hasienda: good! I'll try to have a look tomorrow, unfortunately have to disconnect for now... bye!
[14:29:22.707953]<hasienda>well, to me it looks quite simple, poor; better use Trac there ;-)
[15:10:38.220431]<vlt>Hello. I want to contribute to i18n. I found the messages.po file and for example the msgid "Changed %(date)s ago by %(author)s". How can I define the format of %(date)?
[15:11:42.597068]<cmlenz>the date format is orthogonal to the message translation
[15:12:52.943101]<cmlenz>someone else can hopefully chime in to explain how date format localization currently works in trac, all I can tell you is that you don't get to determine it when translating messages (nor should you)
[15:17:04.727072]<vlt>cmlenz: I'm translating to German where you need to put %(date) in the dative case when using it with "ago". Any idea where to change that?
[15:17:58.320513]<cmlenz>example? I'm german :)
[15:18:04.408034]<vlt>heh
[15:18:15.888890]<vlt>"vor 3 Tagen"
[15:18:39.472121]<vlt>not "vor 3 Tage"
[15:19:32.058069]<cmlenz>ok that's tricky
[15:20:42.539265]<cmlenz>%(date)s isn't really a date here, it's a string based on http://trac.edgewall.org/browser/trunk/trac/util/datefmt.py#L78
[15:20:52.895380]<cmlenz>which is pretty limited when it comes to such issues
[15:23:29.013726]<cmlenz>I would suggest you either append to the ticket concerning german translations, or create a new ticket altogether
[15:23:56.759032]<cmlenz>although wait
[15:25:02.029669]<cmlenz>those "timedelta" strings are, AFAIK, always used in one of the two forms: "XXX ago" or "in XXX"
[15:25:36.180598]<cmlenz>both should be the same in german, I think: "in 3 Tagen" and "vor 3 Tagen"
[15:25:48.888633]<cmlenz>so you should be able to fix *those* strings in the message catalog
[15:26:23.712190]<cmlenz>i.e. look for the msgid "%(num)d day" etc
[15:27:12.600744]<cmlenz>damn, they're also used as age
[15:27:26.029173]<cmlenz>i.e. without either "ago" or "in"
[15:27:38.780421]<vlt>But how to tell if it's singular/plural in the message catalog? We'd need a change in the string genrating unit: pseudo* code: $unit = 'day'; return $count . ' ' . ($count > 1 ? $units['unit'][$lang]['plural'] : $units[$unit][$lang]['singular']);
[15:27:49.609355]<vlt>(*pseudo means php here ;-)
[15:28:31.859337]<cmlenz>pluralization is taken care of by gettext, look at msgid "%(num)d day" in the de PO
[15:28:47.252408]<cmlenz>still…
[15:28:56.002894]<vlt>the age problem
[15:30:06.052694]<cmlenz>ideally this whole timedelta i18n business would differentiate between the three cases in use: "%(delta)s ago", "in %(delta)" and just "%(delta)"... those would need to be separate translatable in the catalog
[15:30:12.349726]<cmlenz>I would suggest creating a ticket for that
[15:30:44.400810]<cmlenz>I'm pretty sure there are languages where "in XXX" is different from "XXX ago", too
[15:31:09.009723]<vlt>cmlenz: Yes. Ok, I'll do that ... tomorrow ...
[15:32:42.756097]<cmlenz>cool
[15:44:55.555288]<osimons>vlt: i see rblank has taken care of your upgrade issue from this morning. goodie. i suppose that is why you now have arrived at translations :-)
[16:07:47.163495]<vlt>osimons: Yes, cboos's patch also worked (though I don't know if it was just ignoring a thrown exception ...). And you're right: The main reason for me to run 0.12dev is my co-workers's repeated demand "wir wolln das aber in deustch ham" ;-)
[16:08:13.531874]<vlt>deutsch, even
[16:14:18.548797]<siebo>I've installed Trac on one of my ubuntu machines, and create an environment, but when I point apache at it it gives me:
[16:14:24.411345]<siebo>Environment not found
[16:15:41.950184]<siebo>here's what my vhost looks like
[16:15:43.639906]<siebo>http://pastie.org/928921
[16:21:29.243295]<rblank>vlt: My fix wasn't completely correct, even though it seemed to work. Would you mind also testing my second patch?
[16:38:56.035273]<osimons>rblank: still hanging in there? got a question about those pesky translations...
[16:39:08.355578]<rblank>osimons: Go ahead
[16:39:55.722255]<osimons>rblank: various messages are obviously log messages, aren't they? or is it pure UI messages?
[16:40:39.744080]<rblank>osimons: Log messages are never translated. Which messages did you have in mind?
[16:41:02.446123]<osimons>things like msgid "Can't use %(annotator)s annotator: %(error)s" just feel like log messages
[16:41:46.463097]<osimons>i should perhaps look them up, but as long as we agree on anything logged should be english only, then i'm fine with putting my trust in the work done.
[16:43:44.862921]<rblank>That particular message is in an add_warning(). Preceded with a logging statement with the same message, but untranslated.
[16:45:27.188615]<osimons>so.... many.... messages....
[16:46:24.686902]<osimons>must.... keep.... sanity.... gaaaaaaaah....
[16:47:28.583453]<rblank>osimons: You're doing the Norwegian translation?
[16:47:56.808728]<osimons>yes. trying.
[16:48:27.567605]<rblank>1086 messages sure are a *lot* :)
[16:49:25.762300]<osimons>down to: 584 translated messages, 219 fuzzy translations, 283 untranslated messages.
[16:52:34.578412]<rblank>osimons: Keep going!
[16:54:28.040747]<osimons>rblank: heh. just noticed my use of "down to" and suppose if I had been slightly more motivated for this I might have said "up to" instead - there is something going for the old "half empty vs half full" arguments...
[16:54:57.738938]<rblank>:)
[16:56:51.244860]*rblank -> bed
[20:00:16.696142]<retracile>rblank: I'll point you at this again tomorrow, if you don't find it in the logs, but:
[20:00:31.122534]<retracile>rblank: Rubik's Cube + Lego + SNOT = Awesome
[20:00:48.529547]<retracile>rblank: And I have proof: https://retracile.net/wiki/2010/04/21/21.30