gmane.comp.version-control.subversion.trac.devel

[Trac-dev] Re: t.e.o maintenance

Jonas Borgström — 2013-05-19T21:58:40

t.e.o should be back online now. Let me know if anything seems broken.

Cheers,
Jonas

[Trac-dev] t.e.o maintenance

Jonas Borgström — 2013-05-19T19:57:36

Hi all,

the t.e.o server will soon be offline for some maintenance work. I 
expect the server to be back online in around 1-3 hours if things go 
according to plan.

Cheers,
Jonas

Re: [Trac-dev] Trac l10n not available after setup.py develop

Remy Blank — 2013-05-09T16:25:17

Mmh... I thought that the JS messages were also compiled with "make
compile", but indeed that doesn't seem to be the case. I think that's a
bug in Makefile, as "make compile-fr" does compile JS messages.

Re: [Trac-dev] Trac l10n not available after setup.py develop

Olemis Lang — 2013-05-09T15:53:38

AFAICS , the whole story is

{{{
#!sh

$ make compile
$ python setup.py generate_messages_js

}}}

Now it works . Thanks .

Re: [Trac-dev] Trac l10n not available after setup.py develop

Remy Blank — 2013-05-08T18:04:01

make compile

should do the trick. Look at the top of Makefile for more targets.

Re: [Trac-dev] Trac l10n not available after setup.py develop

Olemis Lang — 2013-05-08T15:34:21

[...]

Well actually it does not quite fit into my original message .
easy_install will setup.py install Trac et al. and my question is
about achieving the same result with Trac package in editable state
(i.e. setup.py develop) . Is that possible ? What is the exact l10n
dist command sequence executed by setup.py install that are not
performed by setup.py develop ?

Re: [Trac-dev] Trac l10n not available after setup.py develop

Olemis Lang — 2013-05-08T15:21:46

I confirm I did install Babel before Trac , and it still doesn't
generate i18n files .


I'll take a look , thanks :)

Re: [Trac-dev] Trac l10n not available after setup.py develop

Olaf Meeuwissen — 2013-05-08T08:21:27


Even with Babel installed _before_ installing Trac, you will not be
able to run a localized version according to the note at the end of

  http://trac.edgewall.org/wiki/TracInstall#Usingeasy_install


Hope this helps,

Re: [Trac-dev] Trac l10n not available after setup.py develop

Steffen Hoffmann — 2013-05-08T07:54:29

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07.05.2013 20:40, Olemis Lang wrote:

Sure you installed Babel [1] before? That is the required, yet optional
external dependency. Missing it to install _before_ Trac would knowingly
[2] lead to the situation you describe here.

Steffen Hoffmann


[1] http://babel.edgewall.org/
[2] http://trac.edgewall.org/ticket/9439#comment:19
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlGKBLAACgkQ31DJeiZFuHdqQwCgolc8VKUIfFZ7RpU5ABhAi3cO
8tIAoJRgyVlDtJbj7qB4GLjQbMwLTVTq
=rtRs
-----END PGP SIGNATURE-----

[Trac-dev] Trac l10n not available after setup.py develop

Olemis Lang — 2013-05-07T18:40:45

After installing Trac with setup.py develop translations are not
available . Nevertheless I noticed that there are some l10n distribute
commands at hand ...

{{{
#!sh

$ /srv/venv/python/trac/trac-mq/bin/python setup.py --help-commands
[...]

Extra commands:
  update_catalog_tracini    update message catalogs from a POT file
  setopt                    set an option in setup.cfg or another config file
  check_catalog_tracini     check message catalog files, like `msgfmt --check`
  saveopts                  save supplied options to setup.cfg or
other config file
  update_catalog_js         update message catalogs from a POT file
  compile_catalog_js        compile message catalogs to binary MO files
  init_catalog_tracini      create a new catalog based on a POT file
  rotate                    delete older distributions, keeping N newest files
  check_catalog             check message catalog files, like `msgfmt --check`
  install_egg_info          Install an .egg-info directory for the package
  compile_cat

Re: [Trac-dev] Error building Trac API docs in PDF format

Olemis Lang — 2013-05-05T03:24:42

Thanks for the pointer . It worked for me . Nevertheless jftr , it
will not work with Sphinx==1.2b1 (<=latest < at > PyPI) . Another kind of
error is raised .

[...]

;)

Re: [Trac-dev] Error building Trac API docs in PDF format

Christian Boos — 2013-05-02T07:06:50


I just tried ...

  Sphinx error:
  Builder name pdf not registered

Then I easy_install'ed rst2pdf (0.93 is current):

  Running Sphinx v1.1.3
  ...
  build succeeded, 4 warnings.

$ ls build/doc/pdf/
trac_dev.pdf

It looks fine and nicer than the last time I tried.

[Trac-dev] Error building Trac API docs in PDF format

Olemis Lang — 2013-05-01T22:37:05

How could I generate API docs in PDF format . At present I noticed the
following error . Is this possible at all ? Do I need to install
something else ? ... Or is it that api apidoc-pdf make target is not
working ?

{{{
#!sh

$ make apidoc-pdf
 It looks like you don't have a Makefile.cfg file yet.
 You can get started by doing `cp Makefile.cfg.sample Makefile.cfg'
 and then adapt it to your environment.
Running Sphinx v1.0.1
loading pickled environment... done
loading intersphinx inventory from http://docs.python.org/2.7/objects.inv...
building [pdf]: targets for 34 source files that are out of date
updating environment: 0 added, 0 changed, 0 removed
looking for now-outdated files... none found
processing trac_dev... index api/index api/trac_attachment
api/trac_cache api/trac_core api/trac_db_api api/trac_db_util
api/trac_env api/trac_mimeview api/trac_ticket_roadmap api/trac_util
api/trac_util_datefmt api/trac_util_html api/trac_util_presentation
api/trac_util_text api/trac_util_datefmt api/trac_util_html
a

[Trac-dev] Debugging functional tests using Eclipse PyDev

Olemis Lang — 2013-04-26T00:54:06

Hi !

I'm running the Trac XmlRpcPlugin test suite (i.e. functional tests)
using Eclipse PyDev . I'm able to intercept execution by setting
breakpoints in test code itself . Nevertheless they will not work
neither in plugin code nor in Trac core because it's executed in
another (tracd) process .

Q:

  - Is there any way to hook into tracd server process
    to enable the Eclipse PyDev debugger so as to intercept
    and debug RPC calls inside Eclipse IDE ?

Thanks in advance for your help . I look forward to your replies .

Re: Internal errors < at >t.e.o WAS: [Trac-dev] Re: IResourceChangeListener listener interface

Olemis Lang — 2013-04-23T03:36:50

Ok . JFTR I detected this after submitting (i.e. not AJAX)
comment:17:ticket:11148 and comment:18:ticket:11148 using (Ubuntu
10.04)

{{{
About Opera
Version information
Version
12.02
Build
1578
Platform
Linux
System
x86_64, 2.6.32-40-generic
Browser identification

Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.10.289 Version/12.02
}}}

Maybe some AJAX requests failed too , but those I did not notice ...
I'll follow up by creating a new ticket if I notice this happening
once again .

Thanks

Re: Internal errors < at >t.e.o WAS: [Trac-dev] Re: IResourceChangeListener listener interface

Christian Boos — 2013-04-22T18:02:37

From the logs, it's mostly you... or other people running some outdated
browser (undisclosed ;-) ). In that case, Trac can't read the XHR
properly and fails with a read error.
If you're able to reproduce this with a recent browser, please open a
ticket.

Internal errors < at >t.e.o WAS: [Trac-dev] Re: IResourceChangeListener listener interface

Olemis Lang — 2013-04-22T17:20:32

JFTR , while posting messages to trac:ticket:11148 I've received a
substantial number of ''Internal Server Error'' responses . Perhaps
something valuable is discovered in that instance if logging is turned
on .

[Trac-dev] Re: IResourceChangeListener listener interface

Andrej Golcov — 2013-04-22T15:03:30

IMO, passing context data (such as perm, user, resource and href) as events 
args brings a few problems:
 - That will bloat interfaces, complicates logic and introduce a lot of 
repeatable code because this parameter(s) have to be sent almost to each 
method and be part of almost each interface.
 -  As you said, it defines a minimum set. What if a plugin requires some 
data out of this minimum?
 - That breaks Single Responsibility Principle 
(http://en.wikipedia.org/wiki/Single_responsibility_principle) - a class 
have to be aware of context data even if it is not required by the class 
functionality.
 - obtaining backward compatibility brings additional effort

I suggest the different approach:
Trac ComponentManager already provides component resolving functionality 
with the only supported visibility scope - singleton per environment. 
ComponentManager could go a step forward and support additional scopes 
(lifestyles) e.g. per request, transient etc.

Let's take an example: a plugin wants to get a source

Re: [Trac-dev] Re: IResourceChangeListener listener interface

Olemis Lang — 2013-04-19T06:38:41

what if there's no such context e.g. trac admin command ?


maybe usefull yes .


what would these be for ?


I disagree especially considering your example. On ticket change
you'll only be able to figure out the permissions context of the actor
performing such action , which is guaranteed to be allowed before
actually changing the entity . Now that it was successfully changed ,
as it's private what needs to be considered is the permissions of
*other* interested (subscribed) parties .

The way I see it now (but I might be missing something) it's
impossible to design the listeners API based by cluttering it with
data reflecting external influences . In your example ticket ID is
well known by listener (be it in model , resource, ...), access rules
may be retrieved somehow . So just let the listener put all the pieces
together to get thins done .


+1 ... somehow we've been decoupling handling of certain things in
Bloodhound multi-product plugin by implementing product listeners .
What you mention is much more

[Trac-dev] Re: IResourceChangeListener listener interface

osimons — 2013-04-18T19:21:33

I've added a brief comment, and as far as I can see this works exactly
like Listeners do today?

Anyway, let's take a step back first:

I'm not saying the current *Listener interfaces are perfect. Far from
it. The main problem in my mind is that they are already way to
limited due to the limited data they get passed. Like no request
context, no user, no permissions. The things you can do in and around
Trac without user and permission information is very, very limited.
Really restricted to just doing 'bookkeeping' in plugins that create
related data structures behind the scenes - like how deleting a ticket
could also delete tags pointing to it, for instance.

The need for 'generic' notification and similar user-facing needs has
been mentioned many times in this thread, but that seems to not quite
see the whole picture as without user and permission you cannot
notify. If you change a ticket that is marked as 'private' through
some security policy, no listener (generic or otherwise) have the
required informati

Re: [Trac-dev] Re: IResourceChangeListener listener interface

Andrej Golcov — 2013-04-18T13:18:12

I've just added an alternative proposal as comment on the ticket:
http://trac.edgewall.org/ticket/11148#comment:5

Please share what do you think on this.

Cheers, Andrej