Re: [Trac] Re: How to customise the report.css templates for all managed trac projects

[Eirik Schwenke]

Remy Blank skrev 26. okt. 2011 08:10:
 osimons wrote:
(...)
 http://trac.edgewall.org/wiki/TracInterfaceCustomization#SiteAppearance
 
 I have always found that this was a lot of effort just to add a custom
 stylesheet.
(...)
 Moreover, I don't think we can  expect admins to understand Genshi
 templates.

I don't think it's unreasonable to expect admins to understand Genshi
templates (enough to cut and paste) -- but it should be unessecary for
admins to *have* to deal with templates just to change a few colours.

It kind of defies the purpose of using css for (part of) the styling in
the first place if you have to rewrite document structure to set a few
styles.

 Couldn't we add the custom stylesheet to the layout.html file
 automatically, based on the presence of the style.css file in htdocs?
 We could even add an option to configure the path to the file. Then
 again, the mapping from file path to URL is non-trivial if the file is
 outside of htdocs, which is often the case in large(er) installations,
 so maybe that's a bad idea.

Well, by that argument we should remove [header_logo]. I'd rather see
[custom_css] added, allowing to inculde a single css-file in all pages.

Eg:

[custom_css]
src = /site/style/local.css

After all, when you change the logo to something with a different
colour-selection than red/black/white you absolutely *have* to change
the color theme :-)

I couldn't find a ticket on this -- should we make one?


Best regards,

-- 
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C



signature.asc
Description: OpenPGP digital signature

Re: [Trac] Configuring Trac with mod_python(Apache) inside of Virtual Hosts

[Eirik Schwenke]

-
# service, should be reasonably safe, IMO.

 SSLEngine   on
 SSLCertificateFile  /path/to/mydomain.crt
 SSLCertificateKeyFile   /path/to/*.mydomain.com.key
 SSLCertificateChainFile /path/to/gd_bundle.crt

#
# RequestHeader set X_FORWARDED_PROTO 'https'

# I think you mean:
SSLRequireSSL
# http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrequiressl


# Redirect any /trac/changeset to /trac/myproject/changeset to handle
# any old URLs
  RedirectPermanent /trac/changeset/ https://dev.mydomain.com/changeset/
  RedirectPermanent /trac/changeset/ https://dev.mydomain.com/changeset/

#This is ok, I think ?

 # Subversion-related Location-based directives
 Location /
   DAV svn
   SVNPath /svnrepos/myproject/
   SVNReposName MyProject
   AuthType Digest
   AuthName Company
   AuthUserFile /path/to/the.htdigest
   Require valid-user
   AuthzSVNAccessFile /path/to/the.authz
 /Location


# Should be ok? But I'd recommend using mod_wsgi.

 # Trac-related Location-based directives
 IfModule mod_python.c
 Location /trac
   SetHandler mod_python
   PythonInterpreter main_interpreter
   PythonHandler trac.web.modpython_frontendi
   PythonPath sys.path + ['/trac']
   PythonOption TracEnvParentDir /trac
   PythonOption TracEnv /trac/myproject
   PythonOption TracUriRoot /trac
 /Location

 LocationMatch /trac/[^/]+/login
   AuthType Digest
   AuthName Shotgun
   AuthUserFile /path/to/the.htdigest
   Require valid-user
 /LocationMatch

 ErrorLog /var/log/httpd/error_log
 LogLevel warn
 CustomLog /var/log/httpd/access_log combine
 ServerSignature Off
/VirtualHost



Mod_rewrite is quite powerful, but usually not needed when you have full
access to the server/setup -- unless you need to do something really
crazy. See: http://wiki.apache.org/httpd/WhenNotToUseRewrite

Hope that helps.


Best regards,

-- 
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C



signature.asc
Description: OpenPGP digital signature

Re: [Trac] Is anyone using Trac as a helpdesk tool?

[Eirik Schwenke]

Dan North skrev 04/01/11 11:45:
 Hi folks.
 
 As the subject says, I'm looking at using Trac as a helpdesk tool and I
 wondered if anyone else was using it in this way? Have you tried it and
 abandoned it, or better yet tried it and found it does everything you need?
 
 I searched the list archives for helpdesk and help desk and only found
 only a handful of threads, from 2009 and earlier. Google doesn't turn up
 much either.
 
 Does this seem like a sensible use of Trac or should I be considering
 something else entirely to manage helpdesk ticket lifecycle?
 

We are using trac as a help desk tool of sorts -- and it fits our (very
limited) needs well. We are still mostly using trac internally to share
and document information among administrators, not so much as a user
facing (visible) tool.

We are planning to move our support-(email)-list over to defaulting to
creating trac-tickets, but are still doing this on a case by case basis,
triaging out trivial issues that we don't need to document for posterity.

Depending on your needs, and idea of what a help desk system is --
trac can work well -- it's very customizable, and has reasonable email
integration via email2trac[1].

To the best of my knowledge the main missing feature is an easy,
automated way of escalating tickets based on age. But various
workarounds should be possible, perhaps using the xmlrpc-plugin[2] in
combination with a few scripts run by cron.


[1] https://subtrac.sara.nl/oss/email2trac
[2] http://trac-hacks.org/wiki/XmlRpcPlugin


Best regards,

-- 
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C



signature.asc
Description: OpenPGP digital signature

Re: [Trac] Trac + Ldap - Restricted mode error

[Eirik Schwenke]

Noah Kantrowitz skrev 14. sep. 2010 19:51:
 -Original Message-
 From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
 On Behalf Of Jon Hadley
 Sent: Tuesday, September 14, 2010 12:41 AM
 To: trac-users@googlegroups.com
 Subject: [Trac] Trac + Ldap - Restricted mode error

 I'm trying to setup Trac, using mod_wsgi, LDAP and a xml theming proxy
 called collective.xdv.

(...)

  2) LDAP on Trac only works via port 8202, not via 8022. Fairly
 obviously because that's where the rule is set-up. But the rest of the
 site on 8022 doesn't need to be LDAP protected. How do I apply the
 LDAP authentication behind the proxy? Can the proxy somehow inherit
 the authentication rule when Trac is requested? (More detail regarding
 this problem is also here: http://serverfault.com/questions/180845 )

 To answer #2, HTTP authentication is a local system only, it does not
 work with proxies like that.


I first thought you wanted the following:

 , ldap auth --  trac
 user - (xml theme proxy ) 
 ' cms website

In addition, you want to map /trac into the url-space under your other
site, so that:

1: All requests arrive at www.example.com
2: All requests are transformed/formatted by the xml proxy
3: An url starting with /trac:
   1: should be served from the trac instance
   2: should be authenticated via ldap

However, as far as I can tell collective.xdv is just a post-hook for
plone ? So all you want is to have separate mapping of /trac, and
everything else, going through an apache server, with the /trac part
authenticated by ldap ?

Should be as easy as:


  VirtualHost www.example.com
ServerName www.example.com

ProxyRequests Off

# Do not proxy /trac using mod_http_proxy, use wsgi (which is a kind
of reverse proxy)
ProxyPass /trac !
Location /trac
  AuthBasicProvider ldap
  AuthType Basic
  AuthzLDAPAuthoritative off
  AuthName Login
  AuthLDAPURL ldap://127.0.0.1:389/dc=foo-bar,dc=org?uid;
  AuthLDAPBindDN cn=admin, dc=foo-bar, dc=org
  AuthLDAPBindPassword secretword
  require valid-user
/Location

Location /
  #Assuming you’ve got plone running on port 8001
  ProxyPass 127.0.0.1:8001
  ProxyPassReverse 127.0.0.1:8001
/Location
  /VirtualHost

  #WSGIDaemonProcess causes prob if this not outside
  WSGIDaemonProcess trac stack-size=524288
  python-path=/usr/lib/python2.5/site-packages
  WSGIScriptAlias /trac /home/web/foo/parts/trac/tracwsgi/cgi-bin/trac.wsgi
  WSGIProcessGroup trac #changed from global
  WSGIApplicationGroup %{GLOBAL}

I’m not entirely sure I’ve really grasped your problem though. In
general, if you want a more complicated setup,  I would suggest not
cramming everything into one apache config instance, but rather set
everything up as if you were setting up seperate servers.

Then you’d have one apache in front, as reverse proxy, and
possibly doing url rewrite and/or ssl-proxy “accelleration” – and other
instances mounting up wsgi etc.

It might be more overhead, but a lot easier to manage (and scale out to
new servers).


Best regards,

-- 
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C



signature.asc
Description: OpenPGP digital signature

Re: [Trac] Trac + Ldap - Restricted mode error

[Eirik Schwenke]

Jon Hadley skrev 15. sep. 2010 14:51:
 Hi Eirik,
 
 Thanks for the time you've spent looking into my problem, it's much
 appreciated.

NP :)

 I first thought you wanted the following:
 
 , ldap auth --  trac
 user - (xml theme proxy ) 
 ' cms website
 
 Exactly what I want.

Ok -- then I can better understand why you're having problems ;-)

 3: An url starting with /trac: 1: should be served from the trac
 instance 2: should be authenticated via ldap
 
 Should be served from the trac instance, *VIA* the xml theme proxy.
 
 However, as far as I can tell collective.xdv is just a post-hook
 for plone ?
 
 No, it sits in front of Trac too. (In fact it can sit in front of any
 website, which is where it's potential power comes from).
 
 But this is where my trouble begins. As soon as collective.xdv is in
 front of Trac, the authentication system fails. I'm not sure if
 collective.xdv is stripping authentication headers, or if there is a
 better way of Apache controlling the route of the authentication
 requests.

From the collective.xdv-page (and as far as I can tell from your configs
posted here, and at stackoverflow) -- it isn't obvious how you've set
this up -- this is a python script that acts as a proxy ?

Are you using:

  http://pypi.python.org/pypi/dv.xdvserver

wrapped around trac ? Do you run that via mod_wsgi, or some other means ?

Based on:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

13.5.1 End-to-end and Hop-by-hop Headers

 For the purpose of defining the behavior of caches and non-caching
 proxies, we divide HTTP headers into two categories:

  - End-to-end headers, which are  transmitted to the ultimate
recipient of a request or response. End-to-end headers in
responses MUST be stored as part of a cache entry and MUST be
transmitted in any response formed from a cache entry.

  - Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.

 The following HTTP/1.1 headers are hop-by-hop headers:

  - Connection
  - Keep-Alive
  - Proxy-Authenticate
  - Proxy-Authorization
  - TE
  - Trailers
  - Transfer-Encoding
  - Upgrade


 All other headers defined by HTTP/1.1 are end-to-end headers. 

As far as i can tell a reverse proxy actually should forward http
authorization headers -- so it would appear collective.xvd is the
problem, not mod_proxy (Note authorization and proxy-authorization are
different headers).

 Should be as easy as:
 
 Your included configuration works great, if I don't want Trac themed
 by the collective.xdv proxy but have it appear on the same address,
 but as detailed above, this isn't my end goal (although it might have
 to be Plan B)
 
 I would suggest not cramming everything into one apache config
 instance, but rather set everything up as if you were setting up
 seperate servers.
 
 Good advice :)

This does remind me a bit about:

  http://apache.webthing.com/mod_proxy_html/

by the way -- but that or mod_proxy_xml might not be able to do quite
what you want (apply your xml styles).

Perhaps collective.xvd can be made to work with mod_ext_filter ?:

  http://httpd.apache.org/docs/2.2/mod/mod_ext_filter.html


Best regards,

-- 
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C



signature.asc
Description: OpenPGP digital signature

Re: [Trac] About AccountManager plugin

[Eirik Schwenke]

Draulio Neto skrev 11. juni 2010 16:02:

I've managed to correct the problem with the account, now appears:

 Account/Name/Email/Last Login.

But I still can't create an account via trac.

What is missing?



Does trac/apache have write-permissions to your password store? On linux 
you would typically have to do something like:


{{{
chgrp www-data passwd
chgrp www-data group
chmod g+rwx passwd
chmod g+rwx group
}}}

Note assuming the user-store is called passwd, and group-file is
group. In general the same user/group that has write-access to the
trac-install, needs write access to the password-file in order to 
add/edit users.



Best regards,

--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] I just want to tinker with the CSS and change the banner

[Eirik Schwenke]

Ben Miller skrev 03. juni 2010 21:32:

Excellent, I'll give that a shot. Thanks Noah.

How about the main banner? I tried changing the relevant entry in the
trac.ini file (I forget the name of the exact setting, but it was the
logo one specified on the trac wiki), but it didn't work. It appears
to be expecting the image to be in the site-packages/trac folder. How
do specify a file in my own trac project folder?


We have trac setup with an ini-file that's included for all projects, 
with a logo setting of:


{{{
[header_logo]
;height  Height of the header logo image in pixels.
;width   Width of the header logo image in pixels.
;linkURL to link to from header logo.
;src URL of the image to use as header logo.
alt = '(Please make a wiki-page logo, and attach logo.png)'
src = site/../../raw-attachment/wiki/logo/logo.png
}}}

In other words -- the default logo is missing, with an alt-text 
instructing users to set up a page in the wiki, and attach an image.


Works nicely for us.


I suppose the src-attribute might be changed to make the include a 
little safer/robust -- any thoughts would be appreciated. Would perhaps 
just: /raw-attachment/... work as well ?



Best regards,


--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] [trac] empty Browse Source

[Eirik Schwenke]

Cooke, Mark skrev 28. mai 2010 11:18:

I'm sorry but I do not speak English very well!


Seems good to me!

I have successfully installed Trac and can manage multiple 
projects without problems.
I create a project with: 
trac-admin /path/projectname initenv 
and svn repository with: 
svnadmin create /path/projectname/svn



...I would recommend that you keep the svn and trac trees separate.  At
the moment you are embedding the svn files in the same directory, that
makes me feel uncomfortable.

trac-admin /path/projectname/trac initenv 
svnadmin create /path/projectname/svn


...would be better.  However, I don't know that that is your problem.



Agreed -- and it would make more sense to set up svn first, then trac?:

svnadmin create /path/projectname/svn
trac-admin /path/projectname/trac initenv

(...)

Perhaps you can provide more information about your configuration...
 
All the examples in the guide shows a list of files and 
folders, but I have only an empty table and root as main

directory. Why?


Perhaps your webserver serves files from the /svn/-directories, not trac ?


I can't spot any obvious errors based on the information you've posted 
so far.



Best regards,


--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] Re: New Job, new trac setup...recommendations

[Eirik Schwenke]

yoheeb skrev 14. mai 2010 20:12:

Thanks,

I'll give it a go with 0.12., subversion 1.6, python 2.6 and look at
the build server parts a little bit down the road.



I know you stated that you'll be using svn -- I'd really consider 
looking at git or mercurial. Personally I find it very hard to consider 
going back to svn after working with those two dvcs'.


I can't comment on how well mercurial/trac works with 0.12 -- but 
judging from list traffic (user and dev) -- it should be ready to go.


We'll be trying out mercurial with 0.12 shortly here -- but we have 
mostly tickets and configuration changes in the instance we'll migrate 
first (we have some other installs with considerable source code -- but 
we'll test how the migration goes first).



Best of luck:)

-e

--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] FW: Trac session info behind apache authetication

[Eirik Schwenke]

Cooke, Mark skrev 26. mars 2010 11:46:

Dear List,


Can no-one help me understand and/or access session info when using
apache for authentication?  Is there a FAQ I missed or a good write up
somewhere?



(...)

 in (and when), the Admin  Accounts Users page just warns
 This password store does not support listing users.

 Does Trac store session info (username, full name, email 
 time of last login) when using  apache to authenticate?  If
 so, is there a plug-in or configuration of tracaccountmanager
 that allows me to view this info?

Disclaimer, I am *not* a trac developer.

Looking at:

http://trahttp://trac.edgewall.org/browser/tags/trac-0.11rc2/trac/web/auth.py 


(Especially the top, and on):
http://trac.edgewall.org/browser/tags/trac-0.11rc2/trac/web/auth.py#L140

it would appear the auth-cookie contains some of the information you 
want, but the logout method deletes this info -- I can't see any hints 
that this stuff is logged anywhere by trac.


Apache would/can log this info -- but for plugins to access this info, 
it probably should be made available through the database, or some sort 
of trac log facility.


You might also want to look at:

  http://trac.edgewall.org/ticket/2456
  Implement API for user management

Hopefully someone that's looked more carefully at this, can be of more help.

-e

--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] TracCasPlugin performs unwanted logout (or single sign out)

[Eirik Schwenke]

Giuseppe Sollazzo skrev 09. mars 2010 10:43:

Eirik Schwenke wrote:

(...)
I guess the reason why you'd want this is because you've given up on 
single sign on, and use CAS simply as a way to synchronize login names 
and passwords across several servers. I guess this is fine -- it's 
just a bit different from what CAS really is intended to do.



No, actually what I've been requested to do is to implement just a 
single Sign On to be a single entry point for all our webapps. The idea 
is that SSout is automatic when someone disconnects from the corporate 
network, whereas SSon can be performed by any of the webapps (different 
users initiate their sessions in different ways).




If so -- why don't you just hide the log-out function from the trac gui?

As far as I can tell changing the logout-url in the cas-plugin (as Noah 
suggested) would lead to a situation where the user might *think* 
they're logged out -- but if a CAS session is still active, they're 
still *actually* considered logged in by trac? I might be wrong about 
how the plugin interacts with trac sessions, but that's how I interpret 
the code.


IMNHO it's worse to let users *think* they're logged out when they're 
not, than to simply hide the logout functionality (or change the logout 
link to a link to the CAS server logout page).



Best regards,

--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] TracCasPlugin performs unwanted logout (or single sign out)

[Eirik Schwenke]

Giuseppe Sollazzo skrev 08. mars 2010 09:54:

Hi Noah,
well... theoretically you are at least partially right. But that's not 
the case when discussing a real implementation and I can explain why.


The point with CAS is that it offers an *optional* single sign out 
procedure. Most applications/implementations won't log out the full CAS 
session. In most installs I've seen, there is no interest for a single 
sign out, or when such interest is valid, single sign out is performed 
using a centralized logout web application (generally it's the 
corporate portal).


There are many reasons for doing this, but the very simple one (the one 
most sysadmin give when asked) is that most users are fine with a 
centralized login, but would not assume to have logged out globally. In 
environment with thousands of users, all of them very diverse (wrt to IT 
skills), it's not advisable (and it's common practice) to have a single 
sign out, but just a single sign on.


That's why configuring most applications (I've had experience with 
Moodle, Plone, Apache, and some others) you get asked, in the 
configuration files/gui, to specify entry points for both /login and 
/logout. Actually, all apps so far allow that, except trac.


end-of-day-off-topic-rant
The above (varying levels of IT competence) is *exactly* why Single Sign 
On without  Single Sign Out is always going to be a huge security issue.


I think the general reason for requiring Single Sign Out via a global 
portal is that most enterprise system is horrible, broken insecure 
crap -- and the contractors couldn't be bothered to care about security 
of the sytems involved, or read enough of a spec to be able to actually 
*provide* single sign out...

/rant

So the question is still valid :-) Is there a known way of avoiding 
single sign out?


Looking at:

http://trac-hacks.org/browser/traccasplugin/0.11/traccas/traccas.py

it would appear the way the cas plugins check to see if a user i logged 
in, is by checking for a valid CAS ticket (which is exactly what you 
would expect it to do).


And the logout-call invalidates the CAS ticket.

According to (one cas implementation):
http://www.ja-sig.org/wiki/display/CASUM/Single+Sign+Out

it appears the way to deal with broken CAS clients, that maintain a 
separate session from the CAS session, is to disable single sign out on 
the CAS server.



I guess the reason why you'd want this is because you've given up on 
single sign on, and use CAS simply as a way to synchronize login names 
and passwords across several servers. I guess this is fine -- it's just 
a bit different from what CAS really is intended to do.


Either way -- as far as I can tell the trac plugin is behaving correctly 
(even without any option to turn off SSOut).


-e

--
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

[Trac] Re: Trac VS Bugzilla

[Eirik Schwenke]

Иван Бессарабов skrev 02. juli 2009 08:42:
 I've had a task - every morning I needed to send list of task to the owners
 of that tikets.
 
 I've written the small script in perl language. The script is avaliable in
 my blog, but the blog is in russian language
 http://blog.bessarabov.ru/2008/07/23/send-active-trac-tickets-to-mail/
 
 I've placed that script into the crontab.
 
 Feel free to contact me on any questions about this script.
 

I made a minor change, and translated the comments to English (I hope, I
don't speak russian ;-). Just in case it's usefull for someone on this list.

I tested the script briefly, and it appears to work correctly.


Best regards,

-- 
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
#! /usr/bin/perl
use strict;
use warnings;
use DBI;

# Cron script for sending regular reminders to ticket owner.
#
# Call from Cron, or Windows Scheduler.
#
# Original author: Иван Бессарабов
# Upstream version: http://blog.bessarabov.ru/2008/07/23/send-active-trac-tickets-to-mail/
#
# Simplisting translation to English and minor modifications by
# Eirik Schwenke eirik.schwe...@nsd.uib.no . Any errors in this version is not the fault of
# the original author.
#
# Help with transalation provided by http://babelfish.yahoo.com/

###
### Start - configuration settings
# Path to trac install:
my $trac = /var/trac/test;
# Ticket owner
my $owner = some_user;
# Email address where reminder is sent
my $email = some_us...@example.com;
### End - configuration settings
###

# Attempt to connect to trac database:
my $file = $trac . /db/trac.db;
my $dbh = DBI-connect(dbi:SQLite:dbname=$file,,, { RaiseError = 1, PrintError = 0 }) or
die Failed to connect to SQLite filesystem digest cache database at $file:  . DBI-errstr;
$dbh-{unicode} = 1;
# The query to be executed. This searches for all active tickets. 
my $sth = $dbh-prepare(
SELECT id, summary
 FROM ticket
 WHERE
  status IN ('new', 'assigned', 'reopened')
  AND owner = '$owner'
 ORDER BY id);
$sth-execute();

# Slurp all result into $content variable. 
my $content;
while (my $result = $sth-fetchrow_hashref) {
	$content .= # . $result-{id} .  - . $result-{summary} . \n;
}
# If the there is at least one ticket... 
if ($content) {
	# ... then we construct the message to be sent to owner:
	$content = All active tickets for user $owner\n\n . $content;
	# ... and attemt to send the email
  open(MAIL, |mail $email -s 'All active tickets for user $owner') or
die Cannot open mail: $!;
  binmode MAIL, :utf8;
  print MAIL $content;
  close(MAIL);
}
$sth-finish;


signature.asc
Description: OpenPGP digital signature

[Trac] Re: What documentiondto we want, were do we put it and how do we maintain it

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Cross-posted to trac-dev, as this thread should be moved there
 please reply only to trac-dev]

Olemis Lang skrev 04. juni 2009 22:29:
 On Thu, Jun 4, 2009 at 2:07 PM, Eirik Schwenke
 eirik.schwe...@nsd.uib.no wrote:

 I think we need to rethink (or document plainly on the wiki) the terms
 trac user and trac developer. trac end user and trac contributor
 might be better labels, a contributor being anyone that submits code
 (python, javascript, html and templates) or documentation (wiki,
 newhelp) changes.

 
 Let me see if I get the idea :
 
 - Contributor : a contributor being anyone that submits code
   (python, javascript, html and templates) or documentation (wiki,  newhelp)
   changes. (This one seems to be ok for me)
 - Trac developer : What's the difference between a Trac dev and a contributor
   that submits code ( checkin permissions ?)

Yes, my thinking was that trac-dev would be someone with commit access.
Apparently there should be no such thing as a trac dev, only trac
commiters  ...

 - trac user : ¿?
 - trac end user: ¿?  What's the difference

No difference, trac user and trac dev are the only old/legacy
terms that I've seen used before -- and my point was that those terms
weren't all that helpful for discussion.

As a side note, the term trac dev might be relevant as in: trac-dev:
someone that has a working knowledge of the internals of trac.

These are all small details - I believe my original comments had
something to do with defining the workflow, and the notion that not all
contributors (eg: doc writers) are / should be trac devs.

(...)

 I found: http://trac.edgewall.org/wiki/TranslationRu/TracAdmin, does
 this mean that case 4) would involve creating /TranslationJp/xx ?

 
 What about using Wiki Negotiation plugin ?

Is that plugin alive/working ? I had forgotten all about it -- I assume
you refer to: http://trac-hacks.org/wiki/TracWikiNegotiatorPlugin

The example site appears to be down -- but that doesn't mean the plugin
is dead.


There's still a question of managing all this stuff, which is somewhat
related to tagging/branching of documentation -- and possibly suggests
some changes to the wiki in future releases of trac.


An interesting project I worked with at the University of Trondheim had
some useful features for managing documentation:

 a) each article is contained in an xml-file (analogous to a wiki page)
 b) each has an author/owner
 c) the system sends out mail to each owner after x months, asking them
to verify that the article is still relevant, and either:
1) sign off (click ok)
2) update and sign off (ie: edit, sign off)
3) delete it

This is mostly workflow related, and could probably be implemented on
top of either rest/sphinx and/or the wiki.

The system is open, and has some multilingual content:

  http://infoweb.ntnu.no/about+infoweb/help/about.html
  (unfortunately it appears development is better maintainted
   than documentation, as can be seen from the warning on top of
   the following page):
  http://infoweb.ntnu.no/about+infoweb/info/technical.html

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkos+7sACgkQxUW7FIqjOSxJ+gCgoCXQ0gjIfkF04aVx1ciLP2SI
7WwAn3dH104+1Z2HEgkKM01heVodO2KU
=cIT9
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noah Kantrowitz skrev 04. juni 2009 22:13:
 Link to the last discussion on this (or at least one of the last)
 http://groups.google.com/group/trac-dev/browse_thread/thread/f79a1cbb894fe079/8e7d047d0c9fcf16
 
 --Noah

Thanks for the link -- didn't think to include it -- my questions re
syntax was partly motivated by the points made in that thread. I'd be
very interested to hear some more detailed views on ReST vs wiki markup
- -- right now I see two points in favour of the wiki markup:

  1) It's what a great number of trac users already know
  2) Existing trac macros already integrated with the trac
 wiki processor.

I'd be interested in hearing other points of view, especially against
ReST, as I might be blind to any real deficiencies others find crippling ?

Christian Boos mentioned the WikiEngine refactoring which will make it
possible to generate structured output (e.g. Genshi events or docutils
nodes, so that we could hijack the docutils writers for generating the
static documentation)

Has this taken place in trunk ?  I think the consensus is that there are
problems with managing documentation (exclusively) in the (any) wiki,
due to difficulties with maintaining separate versions (0.11, 0.12 as
well as multiple languages) -- but making it easier to do general
transforms on the wiki content would be great either way.

This is beginning to sound a bit like reinventing xml and xlst -- even
though I personally think working with either of those tend to be painful.


Christian further mentions: (Trac has) Much improved table markup (the
reST table markup is unbearable).

This would be:
http://trac.edgewall.org/wiki/WikiFormatting#Tables

vs:
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#simple-tables
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#grid-tables

I agree the trac simple syntax is easier than the rest simple syntax,
but I think unreadable is a bit strong ?

It does illustrate a major difference between ReST and TracWiki-markup:
Underline-markup vs side-by-side/inline-markup:

ReST:Trac:

Headline =Headline=


= = =||Cell1||Cell2||Cell3||
Cell1 Cell2 Cell3||Cell4||Cell5||Cell6||
Cell4 Cell5 Cell6
= = =


Mentioned in the thread on trac-dev is also the external dependencies
problem -- and I agree that that needs to be taken into accounts. I'm
not aware of any good way to ensure pdf-generation with included images
that does not touch a wide range of dependencies, however.

Also while a lot of the default ReST templates are horribly ugly -- the
ability to seamlessly generate LaTeX is a great benefit -- this is of
course something eg. docutils also would grant us.


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotBeEACgkQxUW7FIqjOSwwzgCbB9INW793O1X+5jzG+dD/cire
KI0AoIEOPqXQR5aDjtvp0zLZKorFAlRp
=y77G
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: New CookBook Page

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

abalter skrev 04. juni 2009 23:19:
 It is probably a bit premature, but I started this:
 http://trac.edgewall.org/wiki/CookBook/About
 
 I suggest we start making some recipes, and see how it goes.  Once we
 have a couple dozen, we might have a better idea for how to do the
 cookbook.
 
 In the mean time, should we use trac-wiki or ReST?

I think stuff in the wiki, as a rule should be wiki markup ?

While I might come off as a rambling rest champion in the other threads,
that is mostly related to permanent documentation, and offline editing
with a real editor.

I'm sure I can help with converting from Trac to ReST markup as a
penance for my heretic comments if a new consensus develops ;-)


- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotB0YACgkQxUW7FIqjOSzxTgCgnjOa32oFay8jUq7StXSO3QxQ
SE8AoMG2M0ifL8H10mdJiFycUvUI/cNY
=rPNa
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeff Hammel skrev 08. juni 2009 14:46:
 On Mon, Jun 08, 2009 at 02:36:49PM +0200, Eirik Schwenke wrote:
 Noah Kantrowitz skrev 04. juni 2009 22:13:
 
[ Note somehow icedove chokes on mutt's quoting, apologies if the
  indendation/quotemarkers are still wrong. Pretty sure this is a
  problem with icedove not mutt --- anyway:]

 I'd be interested in hearing other points of view, especially
 against ReST, as I might be blind to any real deficiencies others
 find crippling ?
 
 (this is all MHO, if that wasn't obvious).

Indeed, I might have made that explicit for my thoughts as well --- All
IMHO :-)

 
 Its easier to write Trac wiki than ReST.  I also find it more human
 readable.  As a big fan of markdown languages, I was very enamored
 with ReST a few years ago.  Now, I think its mostly awful, not that
 there aren't things about Trac wiki that I would change.
 

Interesting, maybe I'm at the point you were a few years ago. One great
advantage I failed to mention in favour of TracWikiMarkup, is ofcourse
wiki links -- it's perhaps one of the biggest failings of ReST.

On the other hand I've come to enjoy being able to have links/footnotes
in one place in the text, and link to them like: [LinkToNamedFootnote]_.

It does depend a bit on what one is writing.

I often find myself moving text around, and parts of ReST syntax is
better for that (section linking, footnotes/citations), and part of
trac-syntax is better (better support for auto numbered lists).

(...)

 I've come to the conclusion than doing any sort of complicated
 table with any markdown language is just horrible.  The whole
 reason to use a markdown language, vs WYSIWYG + HTML, is that it
 should be easy to read as text and easy to write.  I've seen tables
 in both Trac wiki and ReST that are just boggling.

Indeed. While I have little love for text editors, there's a definitive
need for rich content, that can accompany (hyper)text. I feel csv-tables
is a possible compromise -- but any table beyond the simplest ones needs
a rich editor IMHO.

(...)

 I do agree that it would be nice to use something standard-ish,
 which is a plus for ReST.  That being said, I would miss Trac wiki
 syntax greatly.  The other alternative is to spin off Trac wiki
 (the markdown syntax, not the linking or macros or what not) into
 its own product.  I'd probably use it.  If other people would...I
 wouldn't want to guess.  ReST has a long history and people are
 reluctant to change.

One of the benefits I see with ReST is that it seems to be solid design,
with great room to improve. It merges a lot of good ideas from
Markdown/Structured Text/LaTeX with reasonable readability.


I'd still like to see some example of ReST vs Trac that you feel
illustrates the readability issues. We'll probably still view them
differently though ;-)


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotDMUACgkQxUW7FIqjOSzS9gCgjn8V5KUGKLQDC0NM/6LCqH4y
dvEAnRG+4Rgdn+qJDaT6xl/uY98aHRws
=VEJK
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac wiki markup vs ReST

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Boos skrev 08. juni 2009 16:26:
 Eirik Schwenke wrote:
 Christian Boos mentioned the WikiEngine refactoring which will make it
 possible to generate structured output (e.g. Genshi events or docutils
 nodes, so that we could hijack the docutils writers for generating the
 static documentation)

 Has this taken place in trunk ? 
 
 No, this is not yet started (0.13?).
 

Ok, thanks for the update.


(...)
 Christian further mentions: (Trac has) Much improved table markup (the
 reST table markup is unbearable).
   
 
 The (Trac has) shortcut is quite misleading. I never said that the 
 current Trac table markup is any better than the reStructuredText one...
 What I actually said was:
 ...
 I don't see why we should stop improving Trac abilities in this domain 
 (producing documentation).
 Here are some of the relevant *work items*:
 - the WikiEngine refactoring which will make it possible to generate
 structured output (e.g. Genshi events or docutils nodes, so that we
 could hijack the docutils writers for generating the static documentation)
 - Section editing (#1024) so that big pages like the FAQ could be
 easily edited
 - *Much improved table markup* (the reST table markup is unbearable)
 - Lots of possible minor improvements to the syntax and rendering, in
 order to make writing documentation a more enjoyable experience (i.e. we
 have full control over the feature set)
 ...
 (from http://groups.google.com/group/trac-dev/msg/4d2ae7546c67fba4?hl=en)
 
 ... so this was instead recognizing the weaknesses of both markups when 
 it comes to tables.

Ah, my apologies. I must've read through that thread at too high
speed... Not sure how I managed to misread you so completely.

If it helps, I did find it very strange of you to make such an
out-of-character seemingly nonsensical comment ;-)


 
 = = =||Cell1||Cell2||Cell3||
 Cell1 Cell2 Cell3||Cell4||Cell5||Cell6||
 Cell4 Cell5 Cell6
 = = =
   
 
 The reStructuredText markup is easier to read, but a pain to write (the 
 cells have to line up). The current Trac wiki is less trouble to write, 
 but harder to read in the wiki source.

Agreed. As mentioned in this thread already, there are (currently) no
*good* alternatives -- personally I think the trac syntax has better
potential here -- but i'd like to see table headers.

 
 There are several improvements I'd like to do in the specific case of 
 tables. One is to make it possible to use a wiki processor for big 
 cells, e.g.
 {{{
 #!td
 any multiline wiki markup here ...
 (much like #!div)
 }}}

Hm... not sure if I agree
alternative-syntax-x-which-is-just-a-wrapper-for-html is better than just:

{{{
#!html
table
(...)
}}}

Both html and LaTeX have powerful (but IMNHO painful to read/write)
table markup.

I think that some kind of csv-table might be better -- in general I lean
quite strongly towards What-You-Mean vs What-You-Get syntax for markup.
This is somewhat related to the render-as-anything functionality which I
think is quite essential both for wiki and documentation.

(Eg: pdf/ps w/inline rich content such as vector/bitmap images, graphs,
tables, links; slideshows (ppt or s5), html, infotex etc).

 Also, I just took the occasion of this mail to dump some some Wiki 
 syntax enhancement ideas in 
 http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiFormatting 
 and there are some more ideas related to tables there.

Many interesting points.


I still think there is some disagreement (or non-explicitness) whether
wiki-markup shows meaning or appearance. Personally I prefer to mark up
meaning, even if that will always be abused for visual gain by
creative users.

Perhaps a strict, not-quite-so-friendly wiki markup coupled with a
simple-yet-powerful rich html/js-editor might be a good idea ?

That way, those that prefer to use eg It'sAllText-plugin with vim and
syntax-highlighting should be able to stay happy, as well as the more
casual users using only the web front-end ?

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotTfsACgkQxUW7FIqjOSxa3QCfYbOQ3vNHRysAMWtnesobrG3N
xdsAni6oh58zSUenHXff+iWywYcyGyIp
=RrhG
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac Recipies

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Boos skrev 03. juni 2009 23:37:
 yoheeb wrote:
 One of the things I've found very useful in MoinMoin wikis (and
 certainly many other wikis have this feature but Trac), is the ability
 to have e-mail notifications upon changes to pages. This enables small
 expert communities to form and aggregate around topics and so there's
 a better chance that a given page will get maintained.

Indeed - this is very useful -- and possible in trac:

  http://trac-hacks.org/wiki/WikiNotificationPlugin
  http://trac-hacks.org/wiki/AnnouncerPlugin

However - it's not enabled on trac.edgewall.org ?

Some of these features run parallel to how the all-new google wave works:

  http://wave.google.com/

Personally I'm not convinced mega jabber server clusters is a viable (or
even desirable) alternative to the web browse + email
announce-architecture -- but there is always room for improvements and
new/refined ideas.

Is the reason WikiNotificationPlugin isn't installed on t.e.o lack of a
email validation feature (ie: risk of being abused for spamming) ?


Best regards,
- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkon6nYACgkQxUW7FIqjOSxzsQCfTA4ozWA06ldceRLepO2nZwnd
MCIAoIVWsxggakIT6LrzRzVOKFtYurhM
=IT7Q
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Trac Recipies

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ariel Balter skrev 04. juni 2009 19:49:
 Eirik Schwenke wrote:
 Christian Boos skrev 03. juni 2009 23:37:  
 yoheeb wrote:
 One of the things I've found very useful in MoinMoin wikis (and
 certainly many other wikis have this feature but Trac), is the ability
 to have e-mail notifications upon changes to pages. This enables small
 expert communities to form and aggregate around topics and so there's
 a better chance that a given page will get maintained.
 
 Indeed - this is very useful -- and possible in trac:
 
   http://trac-hacks.org/wiki/WikiNotificationPlugin
   http://trac-hacks.org/wiki/AnnouncerPlugin
 
 Why is this in the Trac Recipies thread?


Because relates to how we can facilitate keeping pages under
trac.edgewall.org/wiki/howto/xx up-to-date and in high quality -- if we
place them in the wiki on t.e.o.


Maybe I should have included more context.


- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkooDYsACgkQxUW7FIqjOSygrQCgsA6oNg/FY5/FiMnbNjT1HmSw
rOUAn0+ambbAUKRils6rB9qY4gSz1wjk
=h0Tq
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

What documentiondto we want, were do we put it and how do we maintain it [Was: Re: [Trac] Re: Trac Recipies]

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Snip Cookbook def - it's a collection of Howto's/recipes]

Noah Kantrowitz skrev 04. juni 2009 20:01:
 What you describe _is_ documentation. It belongs with the rest of the
 documentation. If you would like to contribute such docs, we would welcome
 it. Just type them up and put them on the wiki or in a ticket. 
 

After reading this thread, and the older trac-dev sphinx thread, as well
as looking at the latest t.e.o wiki -- I'm actually still confused as to
what documentation should go where, how to best contribute, and how to
balance tickets vs wiki vs documentation sourcecode (in the repo).

I think we need to rethink (or document plainly on the wiki) the terms
trac user and trac developer. trac end user and trac contributor
might be better labels, a contributor being anyone that submits code
(python, javascript, html and templates) or documentation (wiki,
newhelp) changes.

This so that the many knowledgeable trac users can help with
translating, extending and end user proofing the documentation.

This may be as easy as making sure that there is a natural and direct
path from the t.e.o front page to the various dev-guides *also* for
those wanting to write a howto, proof-read or translate documentation.

We need to remember that not everyone will equate document trac-admin
in Norwegian with how do I check in my python patches to trac-core. I
think the developers' hearts are in the right place, but we might have a
bit of a culture gap between core devs and the growing group of trac users.

I tried to put myself in the mind of a trac user with little or no
interest/knowledge of coding, and came up with a couple of simple use-cases:

A Trac user/contributor might want to:

 1) Correct spelling errors in existing documentation

 2) Update a documentation section to reflect new behaviour after
a new release (eg: 0.10 - 0.11)

 3) Translate a documentation section to Japanese or Norwegian

 4) Write a short hand-holding end-user-proof HOWTO on setting up
trac for windows 7 with plugins a b and c, for workflow X, with
users in AD.


The workflow should(?) then be:

 * search to see if a ticket exists
   - if not: Make ticket (eg: spelling errors OR request for
 translation)

 * Check out documentation tree (trunk/doc in rst/sphinx format ?)

 * Update relevant section (eg: fix spelling errors,
branch-and-translate-to Japanese)
 * Generate patch

 * attach patch to ticket

 * A developer commits patch, public documentation updated,
   ticket closed

(This is http://trac.edgewall.org/wiki/HowToContribute +
 http://trac.edgewall.org/wiki/TracDev/SubmittingPatches )


Or: to 4) create a new howto on installing trac on windows 7:

 * search to see if a ticket exists
   - if not make one

 * (Write the text, take the screenshots)

 * Make a page on the wiki, attach screenshots

 * link from ticket to page/doc

 * Someone (tm) sanitychecks, converts to rst, updates repo ?


What would be the best approach to 3) Translate a documentation section
to Japanese ? Where would that documentation go ? Or a Norwegian
translation ?

I guess the workflow for any Trac stuff should be:

  1: Search wiki/bug db
  2: Make/update ticket
  3: Solve ticket (ie: apply patch)

This is more-or-less how things work now ?

Is this about right / how the devs want it ?

What do we actually want to have in the wiki vs newhelp ?

Should we have /trunk/doc/contrib/howto|coobook etc ?

I found: http://trac.edgewall.org/wiki/TranslationRu/TracAdmin, does
this mean that case 4) would involve creating /TranslationJp/xx ?


Maybe we need a short summary like the workflow above, on the trac front
page or on the How to contribute page ?

It's not that it's a great evil to have trac howtos on personal blogs,
other wikis, and other documentation sites -- but I believe we should
allow those willing to help, to have a clear and easy path to do so.

I know I personally quickly abandon all hope of donating free work to
projects, if I must spend half a day figuring out how to submit my changes.

I don't usually need to do that any more, as I'm aware most developers
love patches, and hate just about everything else -- but those seeing
Trac as a project management tool and a wiki need a quick up-front hint
on how to proceed.


See also my *other* thread hijack regarding ReST vs Trac wiki markup.

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkooG3QACgkQxUW7FIqjOSzRDQCgzPF1jWPSVSb4zbhkpw73uSdi
EXAAoMvesdTeGcpjgPRBqVNxvZR3fqnA
=rI1f
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users

[Trac] Re: Trac Recipies

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

yoheeb skrev 04. juni 2009 21:05:
 On Jun 4, 10:38 am, Eirik Schwenke eirik.schwe...@nsd.uib.no wrote:
 Christian Boos skrev 03. juni 2009 23:37:
 yoheeb wrote:
 One of the things I've found very useful in MoinMoin wikis (and
 certainly many other wikis have this feature but Trac), is the ability
 ...for the record, I didn't write that, so no, I can't elaborate on
 what I meant, but it does sound rather insightful... :D  I have been
 misquoted!  oh no, it's on the internet, it must be true!
 

Apparently I (or someone before me) failed miserably when trying to
clean up attributions and quotes in the thread. My apologies.

 As an observation, here's is what I think seems to of washed out of
 this hijacked thread so far in terms of intent
 
 maybe we should have an adopt-a-wiki-page type thing, similar to
 adopt-a-hack on track hacks.

(...)
 
 Also, we could, for example, standardize on a convention for recipe
 naming:
 SomeWikiTopic/Recipes/HowtoDoSomethingCool
 SomeWikiTopic/Recipes/HowtoDoSomethingMoreCool
 SomeOtherTopic/Recipes/HowtoDoSomethingLame
(...)

 What'cha think?

This is one approach. I think it is sound -- but see my other post on
what we want where wrt documentation -- and also how we deal (or if we
should attempt to deal) with translations and the possibility of
different versions of a documentation-section for different releases of
trac.

Maybe enhancing your naming scheme to:

 ReleaseOrTag/SomeWikiTopic/Recipes/HowtoDoSomethingCool

and/or:

2LetterLanguageCode/ReleaseOrTag/SomeWikiTopic/Recipes/HowtoDoSomethingCool

Eg:
  no/0.11/SomeWikiTopic/Recipes/HowtoCoolness
  en/0.11/SomeWikiTopic/Recipes/HowtoCoolness
  /0.11/SomeWikiTopic/Recipes/HowtoCoolness (maps to defined default
 language, eg en or
no ?)
  en/trunk/SomeWikiTopic/Recipes/HowtoCoolness

There's still a question of resources and links from these pages to the
sourcecode repository (images, code), eg make sure links form the
/wiki/trunk goes to /svn/trunk, and /wiki/0.10/ goes to the right
versions... Maybe simple mapping would be enough.

These are old arguments/questions that led in the direction of the
newhelp branch (as far as I remember, can tell from a bit of googling).

However: We do *have* a wiki -- presumably we want something in it.
Possibly more than discussions... I don't think we need a
black-and-white test for what goes in the wiki and what goes in the
proper version controlled documentation -- but clearly the current
state of the wiki has severe limitations as a document management system.

That might be a design decision (or perhaps non-decision).

Maybe this is actually a new / distinct feature, and the direction
forward should be that a trac project has:

  tickets (in db)
  source code (in vcs)
  documentation (in vcs with possibility of web editing/wiki)
  tests (via bitten)
  discussion (wiki/mailinglist/usenet news/irc)

The point being that source code and documentation might not be well
served by viewing them as the same.

I'm not sure what seeing wiki as a vehicle for discussion actually
implies. But it is an interesting observation if we take it seriously,
and at face value.

Again see the google wave presentation (wave.google.com) for some ideas
on this. I don't think we want to abandon http/svn for a jabber based
protocol (certainly not for 0.12!) -- but there are some ideas there
that are interesting.

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkooIGkACgkQxUW7FIqjOSwcJACfUEARQHroN++uHHOQ3IZRHvOA
hYkAnjzWijZXQ3iYg00Iy6xHOQ1GSy8x
=qHDC
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

Trac wiki markup vs ReST [Was: Re: [Trac] Re: Trac Recipies]

[Eirik Schwenke]

 it though -- I don't know how well the web/wiki
interface plays along with checking out the code, doing some changes
with a real text editor and checking them in -- it *seems* perfectly
feasible.

Christian also says that:

  The second argument is that if the TracTeam (tm) doesn't use its own
   wiki formatting and rendering chain, why should others trust it for
   writing their own documentation?

   If there are problems with that formatting or the rendering chain
   which makes it a sub-optimal solution compared to other tools (in the
   same category), then our job would be to fix it. Otherwise by
   the same kind of argument we could have switched to say, Roundup for
   our bug tracking needs, if some had considered it would have been
   better than Trac in this respect.

Noah points to earlier discussion, which concluded with wikis being good
for discussion, but not documentation -- but I still think this is a
vital discussion; what roles should the wiki-part of trac fill ? Should
it be better integrated in trac (eg: wikipages in rst, in it's own repo,
or its own subfolder of a repo) ? The latter would place strong
emphasis  on a one right way to use trac -- which is generally against
the open spirit of Trac.

Still, *not* having some features (eg: rendering pdfs with figures from
the wiki) is a serious problem. We really should have a system that
allows us to integrate tabular data, graphs, diagrams and bitmap
graphics into the stuff that is truly collaboratively edited.

This is *not* an easy problem though -- note that wikipedia, google wave
among others still have *not* got this right. Collaborative editing of
non-textual data isn't easy.

For some inspiration on what is possible with regards to
richer-than-text data, have a look at http://dabbledb.com , the google
chart api and the Inkscape whiteboard extention (the latter uses xmpp,
just as google wave does).

LaTeX ofcourse the canoical example of how to design a documentation
framework. It's not perfect, but it's solid enough that one needs a
good reason to do something differently from LaTeX (eg: I don't
particularily like aestetics of the TeX/LaTeX markup -- but then I don't
really enjoy writing ((ht)|s|x)ml by hand either).


Christian also states, somewhat out-of-context:

  I think it will eventually be possible to bridge this gap by having
   Trac generate .rst markup from wiki markup

Which is proably true (in general mapping from one in-memory document
tree to another shouldn't be all that hard). But this might not be the
best way to go forward.

I actually think that if we want to keep the Trac markup as primary,
mapping to docutils should be done on the document-tree level. That is
we parse TracMarkup - DocumentGraph, then map that to the internal RST
representation of a document (this is my impression from looking briefly
into how docutils/rst is extended using plugins, and how rst generates
documents).

Phew,

  apologies for the thread-hijacks today -- but I think the original
  question has formed an interesting catalyst for discussing trac
  documentation, and contribution guidelines.


Also of interest regarding reStrcuturedText and documentation:

http://jimmyg.org/blog/2009/my-experience-of-using-restructuredtext-to-write-the-definitive-guide-to-pylons.html



Footnotes:

.. [RstQuickRef]
http://docutils.sourceforge.net/docs/user/rst/quickstart.html

.. [SphinxThread]
http://groups.google.com/group/trac-dev/browse_thread/thread/f79a1cbb894fe079/22740041300c5873#22740041300c5873

.. [GrokTut]
http://grok.zope.org/documentation/tutorial/contribute-to-the-grok-documentation/restructured-text-rest-extensions

.. [MoinBackend]
http://moinmo.in/ChristopherDenter/HelpOnStorageConfiguration

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkooJmMACgkQxUW7FIqjOSzg7ACeM7eWWD+IBdwmQOY03SpOunM2
MvQAnRTD0dNgbglb6QivA/3gD1Yf2fqw
=Yz86
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: read only Trac ?

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alain Miniussi skrev 25. mai 2009 15:02:
 
 Hi,
 
 So, I upgraded to 11.4 with an easy_install, 
(...)

 And so fare, everything seems to be ok, I can modify and see the  
 modifications.
 
 The only thing that suprises me is that I did not even had to install the  
 traccas
 pluggin (I use CAS for authetication) but I won fix it if it's not broken  
 :-)

Assuming you don't have apache set up to directly talk to CAS (been a
while since I looked at the CAS-documentation -- don't even know if that
is possible :-) -- you might have the plugin installed from before (from
your 10.x install).

Have a look at: /usr/lib/python*/site-packages and your
trac-env/plugins folders.

This is a good reason to use virtual-env btw -- it will allow you to
have everything trac managed by easy_install, and everything else
managed by aptitude, without running into (too much of) a problem on the
next dist-upgrade to Debian/Squeeze.

 Thank to every one for the help.
 

No problem. Without starting a great posting-style flamewar on this
list, allow me to point out that top-posting is generally
counter-productive on mailing lists, or:

  A: Because it messes up the order in which people normally read text.
  Q: Why is top-posting such a bad thing?
  A: Top-posting.
  Q: What is the most annoying thing in e-mail?

See also: http://en.wikipedia.org/wiki/Top-posting#Top-posting and
probably half of all archived technical mailing lists.


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoa2c0ACgkQxUW7FIqjOSxRNwCgrjPPX0RZltGb5Sr+pe2Ingup
m/kAoIPln690uD/ndJOWEXz/nBmQ0C4B
=oHwu
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: read only Trac ?

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alain Miniussi skrev 22. mai 2009 23:04:
 On Fri, 22 May 2009 13:54:34 +0200, Emmanuel Blot manu.b...@gmail.com
 wrote:

(...)

 It's trac 0.10.3
 SO old!
 Moreover, 0.10.3 has some security issue that has been fixed in 0.10.3.1.
 Check out http://trac.edgewall.org/wiki/ChangeLog#a0.10.3.1

 Anyway, you should definitely think about installing Trac 0.11.4,
 rather than starting up with an ancient Trac release.
 
 Well, I first had a look at the dependency constraints on the web page and
 though that using the default (the one you get with apt-get) package for
 debian would at least deal with that part of the problem :-) moreover,
   from a maintenance perspective, (and I am not alone on that one) working
 with the default packages is close to a no brainer. Now, if there is a
 security
 issue, I'll probably move to the last stable version.
 
 Does anyone kown of an alternate, up to date, source for trac on debian ?

Currently we run upstream trac0.11. It is handily installed with:

  aptitude install python-setuptools
  easy_install trac

on Debian. You might want to look at virtualenv and friends -- as long
as trac is a moving target, the latest version will never be in Debian
stable.

Whether packages such as python eggs, ruby gems, perl or php PEAR
modules are best handled with aptitude or their various non-distribution
counterparts is a matter of some debate -- personally I use
setuptools/easy_install for trac, but not for other python modules.

You might want to have a look at linux-vserver, the schroot package,
xstow and/or apt-pinning and see which suits you better.

Bottom line is that Debian Stable tries to guarantee
feature/behaviour-freeze across the entire life of a release -- which is
a very good thing, but does not work well with rapidly changing
software, like trac (or various Ruby on Rails solutions, many small
php-frameworks etc).


I'd have a look at the section

http://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetup#Setupavirtualenvironment

and below on the trac wiki -- I find this works quite nicely for
managing trac installs. It does force you to use more than aptitude
(unless you implement your own backport-mirror...) -- but that is hard
to avoid with a fast-moving target like trac.

Hopefully you have some way to manage your apache-config outside
aptitude (even if that process consists of editing the files when needed).

Also have a look at yolk (easy_install yolk), for managing python eggs
(and trac) -- in particular yolk --show-updates, that will give you an
idea of packages that might need upgrading (always good to check the
various dev-lists and debian-changelogs though -- packages in main
gets security backports, after all).

Btw, if you get CAS to play nice with Trac and svn, a small howto would
be greatly appreciated -- might save me (and many ohters) some
trial-and-error :-)


- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoZW7sACgkQxUW7FIqjOSzgBgCfYdqk8j+KdiiZo2aZDnqQjU4A
mXwAn3Exjlsp3eLl+/zObQmsfdc3nPWb
=svy6
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Quote code snippets in Wiki from source file

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ted Gifford skrev 12. mai 2009 21:01:
 Andrew Gehring wrote:
 On Tue, May 12, 2009 at 7:06 AM, jevans  wrote:
 Since line numbers can shift so easily, how about something like:
  [[Include(source:trunk/somefile.cpp, '// Important section', 20)]]

 where the second parameter could be a regex matching something in the
 file.

 Why not have a regex for the end line as well?

I believe that is called a patch... While a regexp might be easier
sometimes that linenumbers -- I think reffering to trunk wouldn't be a
very good idea -- reffering to an actual version might be better (then
line-numbers would never change).

The real problem here is synchronizing documentation in the wiki with
code in the repository -- I'd say either move documentation closer to
the source (same repo, same changeset) -- or keep the documentation in
the wiki do something that's less prone to change -- i.e. API documentation.

I don't have a problem with improvements to the includeplugin to make
all this stuff possible -- just thought it worth pointing out that this
might be solving the right problem in the wrong place...

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoK2DwACgkQxUW7FIqjOSwzaACgr3YEt45ObNwyAHEvUHXgEoLC
eIQAn22rJ1Kp92xkPxgU4mAJuF2HCZlH
=RMH1
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

OT: MVC history - Get off my lawn [Was: Re: [Trac] Re: Requirements for a new and improved Gantt plugin]

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Olemis Lang skrev 09. april 2009 15:54:
 On Thu, Apr 9, 2009 at 8:43 AM, Olemis Lang ole...@gmail.com wrote:
(...)
 To be more precise in this point. Trac Gantt may be considered a 
 potential example of MVC architecture. In other words :

It was, in fact, used in the first ever paper on MVC:

  http://folk.uio.no/trygver/2007/MVC_Originals.pdf

  I made the first implementation and wrote the original MVC reports
   while I was a visiting scientist at Xerox Palo Alto Research
   Laboratory (PARC) in 1978/79.

  (...)

  They are described in my first note of May 12, 1979:
   THING-MODEL-VIEW-EDITOR -.an Example from a planningsystem.

  (...)

  Date12 MAY 1979

   The purpose of this note is to explore the thing-model-view-editor
   metaphors through a coherent set of examples. The examples are all
   drawn from my planningsystem, and illustrate the above four notions.

  (...)

  The diagram is an instance of class GanttView, which is a subclass of
   ChartView. ChartView knows about the diagram background: axis with
   legend, gridding etc. It does not know anything about the information
   to be put into the diagram, in this case the horizontal bars.


Still an interesting read, almost 40 years later, to the day.


You might also find the newest paper by Trygve Reenskaug (same author)
and James Coplien interesting:

http://www.artima.com/articles/dci_vision.html
The DCI Architecture: A New Vision of Object-Oriented Programming


- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkneDtoACgkQxUW7FIqjOSyaiQCgnXGSJlpsFhLp1dUAmbaxewNR
++IAoKHUN8EpvCit8QyjK0kuKTfNQ7gI
=52s3
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

Re: OT: MVC history - Get off my lawn [Was: Re: [Trac] Re: Requirements for a new and improved Gantt plugin]

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eirik Schwenke skrev 09. april 2009 17:06:
 Olemis Lang skrev 09. april 2009 15:54:
 On Thu, Apr 9, 2009 at 8:43 AM, Olemis Lang ole...@gmail.com wrote:
 (...)
 To be more precise in this point. Trac Gantt may be considered a
 potential example of MVC architecture. In other words :
 

(...)
 
   Date12 MAY 1979
(...)
 
 Still an interesting read, almost 40 years later, to the day.

Erm. Lets see. 2009-1979=30 ... oh well. Still a good while back.

- -e

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkneD7QACgkQxUW7FIqjOSx+uACgiA7XmZ9KNmEJB2dtZTc4D0gU
c4kAniVOmxva2zyt8BDriHov/mFwuTut
=fUwQ
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Two trac versions, one box

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Oliver Marshall skrev 10. feb. 2009 09:58:
 Hi chaps,
 
 Is it possible to run two versions of Trac on one server? We are using a 
 normal Trac install at the moment with SVN. However we are working on a new 
 product for some clients which is based on a highly modified version of Trac. 
 Currently we are looking at a separate box each, though this is only because 
 the tech's don't know if (how) we can run both versions on one server.
 
 The current Trac setup is more than enough to handle all the requests so I'm 
 keen to save some budget and get the one box working for it's dinner.
 
 Anyone know whether this is possible at all ?

If the system now is able to run a newer version of trac (ie you have a
reasonably up to date python available) -- there shouldn't be a problem.

You have a couple of options, depending on how much separation you want/need
between the to instances. You might want to look at:

  http://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetup

for a general overview of how to use trac and python's virtualenv together.
It's a great way to set up test-environments for trac, without creating
problems for your regular installs.

If you want more separation than this, you might look at runnig a chroot or a
vserver/jail if your server is a linux or *bsd box. Personally I'm a great fan
of Debian, and the combination of cdebootstrap and the schroot or vserver
packages is a great way to run certain packages from eg. sid/unstable on a
server running mainly etch/stable code.


Hope this helps to get you started.


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmRVmIACgkQxUW7FIqjOSy0kACeNJbU9873GB+NntsrRnLenSy4
h8UAoIdmIw1W5NFxrW5H4tdCK1IGNQCc
=Lp+Y
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Add diff renderer?

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeff Hammel skrev 07. jan. 2009 16:20:
 On Tue, Jan 06, 2009 at 11:49:21PM -0800, Noah Kantrowitz wrote:
 I don't know of any libraries or other ways to parse Word documents,  
 so no. If you are running on Windows and server has Word installed,  
 you might be able to rig something up with COM (via the win32com  
 module), but this isn't enough of a general case to bother IMO. All  
 the new Office 2007 files are just zipped XML I think, so you might be  
 able to make an HTML converter for that. Not a small task though.

 --Noah
 
 There is also antiword 
 
 http://www.winfield.demon.nl/
 
 This could be made into a plugin.  Or I have heard rumors that OpenOffice can 
 be driven computationally...somehow.  I avoid word documents like the plague 
 but realize this is a luxury that not everyone has.
 
 Jeff

Note: None of the following is a solution to the problem, just some notes on
alternate solutions;


There is also catdoc (and xls2csv):

  http://vitus.wagner.pp.ru/software/catdoc/

For simple text documents, the strings-command also works nicely. That couldn't
be too hard to reimplement in python, (for easier portability to win32 -- I
believe OS X already has a strings command).

However, as Noah says, even if a plugin was was made based on that, I don't
think the results would've been very good.

A better alternative might be to turn on change-control in word/office.


After a bit of googling, it turns out the tortoise svn project has it's own
diff/merge tools, from http://tortoisesvn.net/downloads:

 Our diff/merge tools TortoiseMerge (for text file diffs and merges),
  TortoiseIDiff (for diffing image files) are zipped into one package, and
  SubWCRev is also available.

The sf-page only lists the binaries, but the code can be found at:

http://gu...@tortoisesvn.tigris.org/svn/tortoisesvn/

I don't think the ImageDiff referenced over is of much interest, but apparently
TortoiseSvn uses a couple of javascripts to diff doc and docx files:

http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/contrib/other/diff-scripts/

I'm afraid I don't see any useful way this could be integrated to standard trac
- -- I guess my recommendation would be to use tortoise svn against the
repository trac uses.



For anyone wanting to make a win-only/requires word plugin for trac, the
following link might be useful:

http://nicolas.lehuen.com/index.php/post/2005/06/30/60-comparing-microsoft-word-documents-stored-in-a-subversion-repository


Also, while I have no experience with it myself, Diff doc migh also be of 
help:

  http://www.softinterface.com/MD\Document-Comparison-Software.htm

(This would be similar to comparing the documents within word, though, not in
the web front-end).


Still, apart from policy, the only times it makes sense to use a rich format
(be it open document, rtf, pdf, word or even html) for documentation, is when
the content is in fact multimedia -- tables or images/figures adds something to
the document that cannot easily be gleaned from a docbook/tex/structured text 
file.

Then you really would need a diff-tool that understands the format in order
to get meaningful diffs.


See also:

http://blogs.msdn.com/buckh/archive/2005/11/28/497556.aspx
http://www-verimag.imag.fr/~moy/opendocument/


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl5/1cACgkQxUW7FIqjOSyByQCeMU7OGGOkQgm6umn0pERvTCxY
FIoAoJyPaICFFukBud65RRy5n3KRHWHb
=qtUq
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: HTML Entities in wik pages

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Erik Bray skrev 22. jan. 2009 19:23:
 I think the main point is that it would be nice to be able to somehow
 type in named HTML entities in a wiki page, and have them unescaped.
 It's easier to type lte; than it is to configure an easy to use input
 method for arbitrary symbols.  I'm not saying it's Trac's job to solve
 that problem.  It's just something I've run into before myself.

Well, surely there must be some kind of js-editor-thingy or firefox plugin that
will do this for you ? I recently ran into the opposite problem on OS X; it
generously turns regular quote-marks (), into start-end-quotes. Not very
helpful when trying to post shell-code in a blog.

Anyway, every reasonable OS I've ever worked with has a nice visual keyboard
with all kinds of glyphs available -- any reason not to use that ?


Lastly a tip -- one lazy way to get around this, is to search for the character
on wikipedia, and then simply cut'n'paste the glyph you want, eg:

  http://en.wikipedia.org/wiki/Less-than_sign#Less-than_sign_plus_equals_sign
  http://en.wikipedia.org/wiki/Quotation_mark_glyphs
  (etc)

(This assumes your terminal is able to actually *render* the glyph, ofcourse).


Best regards,

- --
 .---.  Eirik Schwenke eirik.schwe...@nsd.uib.no
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl6BGYACgkQxUW7FIqjOSzBNQCgoP2SLK5SW9gkTLHmUshTTu85
CJAAn3HlF2gNDvIpi4eEkFcuWu3+hfhQ
=Y7fx
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Exporting Japanese wiki pages to PDF

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Erik Bray skrev 05-12-2008 17:56:
 On Thu, Dec 4, 2008 at 7:58 PM, Olaf Meeuwissen
 [EMAIL PROTECTED] wrote:
 Olaf Meeuwissen [EMAIL PROTECTED] writes:

 I've been looking for ways to export (a set of) wiki pages to PDF and
 come across TracWikiToPdfPlugin and PageToPdfPlugin.  Both seem to be
 quite useful but for a limitation in HTMLDOC.

 The current stable version of HTMLDOC (1.8.27) doesn't support UTF-8.
 The development snapshot has basic UTF-8 support but no support yet
 for Asian and other complex languages.  That's a big show-stopper
 because part of my wiki pages are in Japanese.

 I anyone here aware of a plugin that can export Japanese wiki pages to
 PDF?
 Based on the lack of follow-ups, I guess not.

 For now I'll just have to settle for printing individual wiki pages
 from a browser (and maybe tweak the stylesheet for print media).  That
 way, I can at least create a PDF file but it doesn't look too great.

 Hope this helps,
 
 I took a quick look around for other html to PS or PDF utilities,
 because I found it curious that there was *nothing* that supported
 Japanese well.  There may be some non-free products that do it, but I
 came up emptyhanded otherwise.  It's unfortunate :/

This was my initial impression too. As seen other places is this thread, things
are not as hopeless as they appear at first sight -- there are ways to get from
wiki to LaTeX/docbook.

But -- as far as other html-pdf/ps converters, I found:

  http://cutycapt.sourceforge.net/

It uses Webkits rendering engine to convert html/webpages to, among other
things, pdf. I verified that a quick capture of http://www.tokyo-np.co.jp/ got
me a useable multi-page pdf, with text as text (eg I could copy-paste
kankji/kana) and in-line images.

It might be worth a look.

Binaries are available for win32 -- And I got it to build easily enough on
Ubuntu Hardy with backports enabled in /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu hardy-backports main universe multiverse
restricted
deb-src http://archive.ubuntu.com/ubuntu hardy-backports main universe
multiverse restricted


A similar utility using IEs rendering engine also exists:

  http://iecapt.sourceforge.net/


Please note that cutycapt has support for javascript, java and plugins -- and
is really meant as an automatic screen-capture tool. I do like the fact that it
allows seamless integration of inline images -- but you might want to disable
everything else if this is used in an automated script of some sort.

I guess you'd need to add a few css rules for optimal output, and probably you
won't get any clickable table of contents etc.


Either way -- please keep us posted with your conclusions.


Best regards,

- --
 .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJP6OVxUW7FIqjOSwRAin0AKDJnJOJdnRWETJDr+2MHbQSEwG0CACeOG0E
INeS+FFf5PmjMeFTN8QdKA8=
=uVLx
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: AccountManager woes

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert C Corsaro skrev 01-10-2008 20:02:
 Graham Dumpleton wrote:
 Doubt that version of mod_wsgi here is the problem if they had the
 problem with tracd as well.

 If it was just mod_wsgi and AccountManager uses sessions/cookies, then
 would be asking what version of Python is being used. Debian broke md5
 stuff in some versions in as much as if PHP mhash is loaded at same
 time, can cause problems like what is being see. See:

 http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_MD5_Hash_Module_Conflict


For posterity, according to:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440272

This was fixed Thu, 03 Jan 2008 13:02:05 +, in unstable.

The patch was apprently not merged back to etch (stable), though:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 4.0 (etch)
Release:4.0
Codename:   etch
$  nm -D /usr/lib/python2.4/lib-dynload/md5.so |grep MD5
1b90 T MD5Final
1170 T MD5Init
11b0 T MD5Transform
1c70 T MD5Update


It is fixed in the package in lenny (testing - soon to be stable):

 $ wget -O -
ftp://ftp.no.debian.org/debian/dists/lenny/main/binary-i386/Packages.bz2|bzcat|grep
Package: python2.4-minimal -A10|grep Version| awk '{print $2}'
 (...)
 2.4.5-5

 $ wget
ftp://ftp.no.debian.org/debian/pool/main/p/python2.4/python2.4-minimal_2.4.5-5_i386.deb
 $ mkdir pyth
 $ dpkg -x python2.4-minimal_2.4.5-5_i386.deb pyth
 $ nm -D pyth/usr/lib/python2.4/lib-dynload/md5.so |grep MD5
1740 T _PyDFSG_MD5Final
1020 T _PyDFSG_MD5Init
1060 T _PyDFSG_MD5Transform
1810 T _PyDFSG_MD5Update


Regards,

- --
 .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI49GNxUW7FIqjOSwRAjILAJwNNLgbDsYtCka0RZiU9gzwZPT7vwCgwa3S
CmXbLUMV8h7Hpur0uebwNAE=
=1I0x
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Migrate to TRAC

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pavan Balaji skrev 16-07-2008 22:52:
|
| Lots of scripting fun with Python, basically. Nothing available right now.
|
| Is there some documentation on how tickets can be injected into TRAC
| from the command line (does it use a SQL back-end)? I can probably
| script up something to do this.

The link recently posted[1] by Noah on this list might get you started:

~  http://trac.edgewall.org/wiki/TracDev/DataModels


[1]
http://groups.google.com/group/trac-users/browse_thread/thread/aabfa62d676a1a53/108c1a284823c3bb


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIgeLcxUW7FIqjOSwRAu0MAKDOS99T1EC3RVVSBc3yi8HqYtZMuACgtun/
mS0eCeOvq8OU29CiVNRobX4=
=1QFf
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: OT: python for automating tasks, Was: Re: [Trac] Re: Global trac.ini not effective after upgrade to 0.11

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noah Kantrowitz skrev 23-06-2008 21:56:
|
| On Jun 23, 2008, at 3:54 PM, Noah Kantrowitz wrote:
|
|
| On Jun 23, 2008, at 3:41 PM, Eirik Schwenke wrote:
|
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Noah Kantrowitz skrev 23-06-2008 16:54:
| | On Jun 23, 2008, at 5:28 AM, Jani Tiainen wrote:
| | So I need to do it by hand to all about 60 of my trac configs.. :D
| |
| | I wouldn't say it more flexible while upgrading, when creating
| new
| | instances it might be more flexible.
| |
| | for f in `ls /var/trac`
| | do
| |  echo -e '\n[inherit]\nfile = /usr/share/trac/conf/trac.ini\n'
| /
| | var/trac/$f
| | done
|
| Indeed. And I imagine most people running 60 parallel instances of
| trac would
| have a posix shell available.
|
| However, does anyone know of a reasonable package that would
| allow a
| similarly short example in python, that remained somewhat portable ?
|
| I'm not looking for something like ipython, the defunct pysh or
| pythonShell --
| just some helpful filesystem iterators that aren't quite as verbose
| as os.path.*
|
| Maybe a utility package that would the above be done in some
| reasonably
| intuitive 5-6 lines of python.
|
| Any ideas?
|
| Using IPython:
|
|   for file in iglob('/var/trac/*/conf/trac.ini'):
|   open(file, 'a').write('\n[inherit].')
|
| Apparently the normal glob.glob works fine too here (I just like ipipe
| stuffs).

Hm,

as I just commented off-list to someone else, I guess what I'm really missing
is something like:

import find

for file in find(/var/trac,iname=trac.ini):
~  with open(file, 'a') as f:
~f.writelines([[inherit], blah=something])

(or. better yet, a nice appendline()/appendlines()-convenience method on all
file objects that allows for doing the same thing (ie equivalent to the shell
 operator):

for file in find(/var/trac,iname=trac.ini):
~  file.appendlines([[inherit], blah=something])


But I suppoose the meme i was missing was glob and/or os.walk. So coding
around the lack of a find module:

import os

for root, files, dirs in os.walk(/var/trac):
~  for file in files:
~if file.lower() == trac.ini:
~  with open(os.path.join(root,file), a) as f:
~f.writelines([[inherit], blah=something])


I suppose I can live with glob and os.walk -- but it's a bit painful that
os.walk returns only names as strings, and that there are no reasonable
file/path objects (note the main reason that this is necessary is of course the
fact that not all os' agree on path separators and/or 
mountpoints/driveletters).

Still a python find-module seems like a good (and pretty simple) idea.


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIYMaFxUW7FIqjOSwRAv+bAKC+eE+MeLkXa/zISCjXs466B3hsWQCfRCAk
jzk9MU9OJiutQgeRgeAuxNg=
=Hfxa
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: OT: python for automating tasks, Was: Re: [Trac] Re: Global trac.ini not effective after upgrade to 0.11

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noah Kantrowitz skrev 24-06-2008 14:13:
| On Jun 24, 2008, at 6:03 AM, Eirik Schwenke wrote:
| Noah Kantrowitz skrev 23-06-2008 21:56:
| On Jun 23, 2008, at 3:54 PM, Noah Kantrowitz wrote:
| On Jun 23, 2008, at 3:41 PM, Eirik Schwenke wrote:
| Noah Kantrowitz skrev 23-06-2008 16:54:
| On Jun 23, 2008, at 5:28 AM, Jani Tiainen wrote:

(... tidying up a bit ...)

#posix shell solution - noah
for f in `ls /var/trac`
do
~  echo -e '\n[inherit]\nfile = /usr/share/trac/conf/trac.ini\n'\
~var/trac/$f
done

| [D]oes anyone know of a reasonable package that would
| allow asimilarly short example in python, that remained somewhat
| portable ?
|
| I'm not looking for something like ipython, the defunct pysh or
| pythonShell --
| just some helpful filesystem iterators that aren't quite as
| verbose as os.path.*

(...)

| import os
|
| for root, files, dirs in os.walk(/var/trac):
| ~  for file in files:
| ~if file.lower() == trac.ini:
| ~  with open(os.path.join(root,file), a) as f:
| ~f.writelines([[inherit], blah=something])
|
|

(...)

| Still a python find-module seems like a good (and pretty simple) idea.
|
| See `iwalk | filter`.

I did have a look at ipipe (http://ipython.scipy.org/moin/UsingIPipe), but in
some ways i think it's the wrong solution to the right problem.

While borrowing syntax from the shell might be a nice fit for working from
within ipython - it feels a bit bolted on -- especially when working from say
an install script.

I'm perfectly happy using bash, awk, grep and find on the command line -- and
ipython is a fine python debug/eval/test-tool; but adding that interface to
python directly leads down the path to perl IMNHO.

Python already has list comprehensions, map, lamda and filter -- I'd much
rather have a first rate object/graph mapping of the filesystem in a way that
feels natural to standard python, than a half-baked shell meta-language (not
that there's anything wrong with a half-baked meta-languages in and of
themselves, but I'd rather have one obvious and suitably lazy way to do things,
while still being readable :-)

Anyway, thanks for all the input -- I'll leave this alone until I get around to
implementing a correct solution ;-)


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIYQNkxUW7FIqjOSwRAlx2AJ4qe5lqtrm6AI9E/11bVrKHnopd0wCgknKA
X2IVJyBlS700wh6ybC0rcR0=
=XRxi
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] OT: python for automating tasks, Was: Re: [Trac] Re: Global trac.ini not effective after upgrade to 0.11

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noah Kantrowitz skrev 23-06-2008 16:54:
| On Jun 23, 2008, at 5:28 AM, Jani Tiainen wrote:
| So I need to do it by hand to all about 60 of my trac configs.. :D
|
| I wouldn't say it more flexible while upgrading, when creating new
| instances it might be more flexible.
|
| for f in `ls /var/trac`
| do
|  echo -e '\n[inherit]\nfile = /usr/share/trac/conf/trac.ini\n' /
| var/trac/$f
| done

Indeed. And I imagine most people running 60 parallel instances of trac would
have a posix shell available.

However, does anyone know of a reasonable package that would allow a
similarly short example in python, that remained somewhat portable ?

I'm not looking for something like ipython, the defunct pysh or pythonShell --
just some helpful filesystem iterators that aren't quite as verbose as os.path.*

Maybe a utility package that would the above be done in some reasonably
intuitive 5-6 lines of python.

Any ideas?


(I can already hear someone snickering perl ;-)

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIX/xNxUW7FIqjOSwRAl3SAKCfVJzSK9odaeMXeNzuSdThGXaz7gCgttIn
z1Q9Dp4uZFh1HWfufw6sbNE=
=Edwh
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: graphviz plugin not working

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georg skrev 10-06-2008 23:24:
| I installed the graphviz plugin into .../plugins, and it appears to be found
| ok:
|
| 2008-06-10 23:18:22,192 Trac[loader] DEBUG: Loading trac.ticket.report from
|
/usr/local/trac-multirepos/lib/python2.5/site-packages/Trac-0.12multirepos-py2.5.egg
| 2008-06-10 23:18:22,197 Trac[loader] DEBUG: Loading macropost.web_ui from
| /opt/trac/SimManager-Multi/plugins/TracMacroPost-0.2-py2.5.egg
| 2008-06-10 23:18:22,199 Trac[loader] DEBUG: Loading addcomment.macro from
| /opt/trac/SimManager-Multi/plugins/TracAddCommentMacro-0.3-py2.5.egg
| 2008-06-10 23:18:22,200 Trac[loader] DEBUG: Loading graphviz from
| /opt/trac/SimManager-Multi/plugins/graphviz-0.7.2-py2.5.egg
| 2008-06-10 23:18:22,202 Trac[loader] DEBUG: Loading file plugin Siebel from
| /opt/trac/SimManager-Multi/plugins/Siebel.py
| 2008-06-10 23:18:22,202 Trac[loader] DEBUG: Loading file plugin ISBN from
| /opt/trac/SimManager-Multi/plugins/ISBN.py
|
|
| Yet, when I enter in a wiki page
|
| {{{
| #!graphviz
| digraph G {Hello-World-Graphviz-Rules}
| }}}
|
| I still get
|
| *Error: Failed to load processor graphviz*
|
| No macro or processor named 'graphviz' found
|
| Trac is the multi-repository branch (0.12dev).
|
| What's the next to try in troubleshooting?

I believe you'll need to install the graphviz binary/library

If you're on a distro with apt/aptitude:

~  aptitude install graphviz

If you're on windows, things might be a bit more complicated:

~  https://networkx.lanl.gov/wiki/pygraphviz
~  https://networkx.lanl.gov/wiki/pygraphviz/FAQ


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIUAUOxUW7FIqjOSwRAo/hAKCTc352oyW3zBkvkbppd6DRs+pL0gCdGexq
hMN6WYEZGyWkxa8PqmVAl1k=
=zWbS
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: BitNami Trac Installer now for Windows too :)

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Antonio Santos skrev 02-06-2008 17:57:
| Hi folks,
|
| I just released the BitNami Trac Stack for Windows today. For those of
| you that didn't read any previous mail about this, the Stack is an
| easy to use installer which installs and configures Trac and its
| dependencies: Apache, SQLite, Subversion and Python.
|
| Until now only Linux and OSX versions were available, so I'm happy to
| announce that it will work on Windows too from now on. The installer
| won't mess with anything in the system (no path or registry needs to
| be modified) and it's open source, distributed under the Apache 2.0
| license.
|
| Our goal is to make open source applications as easy to use as
| possible (we have installers for other projects like Liferay, Drupal,
| WordPress, etc.)

(...)

A noble goal indeed. I'm a bit confused about the license issue though -- in
this mail it appears you license the installer under the apache 2.0 license,
and the various software under its respective licenses -- but from the
bitnami.org homepage it appears you re-license the entire stack to the apache
license ?

~  Open Source
~   All Bitnami Stacks are free to download and use under the terms of the
~   Apache License 2.0

I realise this might just be a simplification for end-users -- but as
especially the Gnu Public/lesser Gnu Public licenses have some very specific
demands on (re)distributors it's something you can't really gloss over.

I was unable to find any clarification on this in your faq, or a quick browse
of your site/forums, including:

http://bitnami.org/article/bitnami-easy-to-install-open-source-applications
http://bitnami.org/faq

The individual stacks do list licences, such as:

~  http://bitnami.org/stack/wordpress
~  http://bitnami.org/stack/wampstack

But it would appear there's no link to the source-code code for eg mysql, which
I assume you distribute under the GPL ? As for the wampstack, I again assume
you distribute apache under apl, php under the php licence and and the
installer under apl?


I just thought this was an issue that might need a little bit more attention on
your otherwise beautiful and very useful site. On a side note; what are you
using for managing the content on your site ?


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIRCrYxUW7FIqjOSwRAnMuAJ9uKWpnk0tbAV5EgIav8Yn9el/wGgCeIJLA
UreZ1SK4i9nVkPtBqSJtETs=
=gmYr
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Repurposing Trac for course management (?)

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] skrev 07-05-2008 20:09:
| On May 7, 11:56 am, Aaron Watters [EMAIL PROTECTED] wrote:
| Hi folks.  I'm interested in tools for online education
| and it occurs to me that in many ways online courses
| can be a bit like development projects.
|
| Would it be feasible to set up Trac to support managing
| assignments and deliverables between an instructor
| and a group of students?

I'd say it all depends -- chiefly on security/privacy concerns, see below.

|  Or maybe have a Trac
| project for each student in class for managing that
| student's work?

As far as I can tell, this might be a better approach. It all depends on the
type of assignments etc -- but at least a personal trac for each student at a
course/university would hands down beat all kinds of e-learning tools I've had
the misfortune to be exposed to.

If there is enough resources in your project to realize this, it would have the
added potential benefit of merging personal student homepages, version control
and backup of data, with a nice way to trac assignments...

With an ldap backend it should be fairly simple to allow professors/teachers
access to all the students' tracs, and giving each student a personal trac/svn.

One might expand this to have project-level tracs for group assignments,
providing a few easy scripts to automate the setup of trac-installations.

(...)

| A key concern, of course, would be privacy and security
| -- only the student and the instructor(s) should see the
| deliverables and grading comments for that student, and
| it would be great if there was a special field called grade
| that could only be modified by the intructor...  Also, a
| university would probably like to manage usernames
| and passwords centrally and stuff like that...

I'd be very careful about this -- in my experience adding privacy to a system
designed for openness can be difficult in the extreme. Before even attempting
such a project be sure you've carefully modelled what privacy and security
demands you will have.

The classic problem is search indexinging and retrieval leaking sensitive
information.

(...)

| -potentially: rather than attachment, use subversion for submissions
| of class assignments.  Not sure the nature of the courses, and it DOES
| put the burden of requiring the students to create a working copy, no
| big deal for CS classes etc., might be overkill for say, Literature
| 101. TortiseSVN is pretty easy to use.

With some effort, it would be possible to use svn with auto-versioning and
webdav, allowing less technical students to ignore the versioning aspect.

I'd say they'd miss out -- but it might be difficult to introduce a new system
(trac), a new way of thinking about versions (svn/mercurial) *and* forcing
people to use something like LyX for writing essays.

I'm sure the students would be *much* better off, than if they use
Word/Openoffice -- but it might be a though sell.

If you do get this approved, please let me know where you work, I might apply
for a masters exchange program there! :-)

(...)

| That said, it could be quite a big task to get it in place, working,
| and also working with/on your internal campus IT system.

Absolutely. If you force this through administration without talking it over
with IT, I suspect you'll have to do your own system administration, bugfixing
and software installs for the foreseeable future -- and you can probably forget
about hardware upgrades :-)

| Good luck.

Indeed, best of luck with your project.

As an aside, I think trac has great potential for use in schools and colleges,
and I think the community would benefit hugely down the road, both from English
lit majors (documentation) and the more obvious computer science graduates.

Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIyqRxUW7FIqjOSwRAjxjAJ9fSx7x6ZAV05YHBSXnqalsBwadYACcCLr6
7omzsqDE9W7YllKL58/yMOc=
=Rtik
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Unsupported version control system svn

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeroen Ruigrok van der Werven skrev 08-05-2008 09:24:
| -On [20080508 06:22], Noah Kantrowitz ([EMAIL PROTECTED]) wrote:
| arrowes wrote:
| I installed Trac 0.11rc1 from easy_install on debian etch with
| python2.5 and apache2 with mod_wsgi and I get this message when I try
| to load Trac:

(...)

For more on getting python2.5+mod_wsgi to work, see below

I have trac 0.11rc1 running on Debian etch with apache2, mod_python and
python2.4. I recently did an upgrade (easy_install -U Trac), to follow along
with upstream. If you are able to either run a different apache instance, or
use mod_python, you shouldn't have any problems running trac 0.11rc1 on Debian.

Note that you can have both python2.5 and python2.4 installed on Debian.

Whether or not this helps you, depends on your reason for running mod_wsgi, of
course.

| I really hope you just sent this before asking the exact same question in
| #trac, and receiving a clear answer.
|
| Which was the following, summarized:
|
| Debian Etch' system Python is 2.4, so basically moving to 2.5 brings you in
| not-vendor (Debian) supported territory. (You want up to date packages?
| Don't follow Debian. At least that's my impression of witnessing Linux from
| the side of the BSDs.)

Well, no. If you want stable packages follow Debian stable. If you want to
follow along with upstream and can live with potential api-changes and other
problems between upgrades, run Debian testing.

(For example, Debian would never allow the kind of changes made to genshi in
~ a stable release -- now I *know* that genshi isn't considered to be stable
~ yet, just making the point that if you tested your package on a given Debian
~ stable release a year ago it will work (or fail:) the same way today as then).

If you want binary packages that are essentially following upstream, use Debian
unstable.

(Ok, I'm a Debian fan, so I get a bit too easily annoyed when people comment on
~ the state of packages i Debian -- Please do not think that I'm
~ flaming/trolling, I've for a long time wanted to give *bsd a serious try, but
~ haven't gotten around to it yet).

You are of course correct in your assertion that running anything outside of
Debian stable, moves you into non-vendor territory. But it's not a bad such
place to be, at least not on Debian :-)

Besides, using easy_install/source-packages directly from upstream puts you in
this position regardless of you distribution. If you can't live with the level
of testing done in Debian Testing, you probably shouldn't be using any upstream
packages at all.

| Also, there is no Debian Etch supported mod_wsgi for 2.5.
|
| So all in all the conclusion was that trying to compile things by yourself
| on Debian gets hairy at best.

Well, being on Debian stable, means living with a stable feature set, frozen in
time, waiting for next release. There are a couple of ways around this:

* It's very easy to run a chroot with testing or unstable on your otherwise
~  stable server, I'd recommend using this with the linux-vserver patch, but
~  that is optional. Running a xen vm is also an option, ofcourse.

* You could install lenny packages directly on your stable server, pulling only
~  needed dependencies from lenny (this is hard to do for things like python,
~  that are so tightly integrated with the distribution, and depends on newer
~  libc...)

* You could pull source-packages from testing, and build them on your stable
~  system - this usually works quite well.

* You could simply run lenny (testing) on the server serving trac

Unfortunately http://www.debian-administration.org appears to be down at the
moment, for some information on vserver on Debian see:

~ http://wiki.debian.org/LinuxVserver

For some information on Debootstrap see:

~  http://wiki.debian.org/Debootstrap

Note that all these solutions, with the possible exception of just sticking
with debian testing -- might be considered advanced. One important thing to
keep in mind if you choose to go with testing (or especially unstable) is that
you cannot like in stable, simply update and forget every night -- things
might break!

So list the updates, have a look at the changelogs, before upgrading your
packages, and you should be fine.


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIzlixUW7FIqjOSwRAvMeAKDFN/SFT5to3AMweRTcUW+CQrglYACfUbpe
Z+RTGDGGg6TKyoBGkNPnK5o=
=srkK
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL

[Trac] Re: Team / Group email plugin

[Eirik Schwenke]

Noah Kantrowitz skrev 05-05-2008 07:35:

[EMAIL PROTECTED] wrote:

I'm seeking to integrate Trac more accessibly to co-workers who
(still) love email updates.

One of our developers wants to be able to get notifications of any
ticket with a given component or tag.

Is there a plugin which allows people (or a group?) to subscribe to
any ticket marked with a specific component or tag, rather than having
them add themselves manually to each ticket's CC?


Check out the AnnouncerPlugin. It can do this I think.


Which reminds me -- I have a local patch to email_distributor.py, I've attached 
it, I'll see about registering a ticket w/patch on trac-hacks.


Basically the problem is that email_distributor.py tries to do authenticated 
smtp, even if there's no smtp_username defined in the configuration -- which 
fails on smtp-servers with smtp-auth disabled.


I'm not sure if my patch is the best way to fix this -- but it works.


Best regards,

--
 .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
 '---'  N-5007 Bergentlf: (555) 889 13

  GPG-key at pgp.mit.edu  Id 0x8AA3392C
Index: distributors/email_distributor.py
===
--- distributors/email_distributor.py	(revision 3540)
+++ distributors/email_distributor.py	(working copy)
@@ -273,7 +273,8 @@
 def _transmit(self, smtpfrom, addresses, message):
 smtp = smtplib.SMTP()
 smtp.connect(self.smtp_server)
-smtp.login(self.smtp_user, self.smtp_password)
+if (self.smtp_user != ''):
+smtp.login(self.smtp_user, self.smtp_password)
 smtp.sendmail(smtpfrom, addresses, message)
 smtp.quit()
 
@@ -313,4 +314,4 @@
 preferences = prefs,
 )
 
-return prefs_announcer_email.html, data
\ No newline at end of file
+return prefs_announcer_email.html, data


signature.asc
Description: OpenPGP digital signature

[Trac] Re: Problem to install trac on Debian Etch

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kai Behncke skrev 30-04-2008 14:35:
| Dear users,
|
| I try to install trac on my Debian-Etch system. Many steps went well.
| I did like it`s written in
| http://dev.e-taxonomy.eu/trac/wiki/TracInstallDebianEtch
|
|
| But in the end I try
| trac-admin /var/www/trac/trac-example initenv and answer the questions and
then I get:
|
|
| Creating and Initializing Project
|  Installing default wiki pages
|  /usr/share/trac/wiki-default/RecentChanges = RecentChanges
|  /usr/share/trac/wiki-default/CamelCase = CamelCase
|
| Failed to initialize environment. (File not found: revision 0, path
'test/', 160013)

Not entierly sure, but did you specify the correct and full path to the
repository you created with

~  svnadmin create /full/path/to/repositiory ?

when responding to the prompts made by tracadmin ? Looks like you just typed in
test/ and not /var/local/subversion/test --- or whatever path you chose for
your subversion repository.


I tried locally with trac-0.11 and it gives a different error with invalid an
repository -- but that might be a change from 10.x to 11.


Best regards,

Eirik


PS: Without having looked at the test-suite(s) for trac 0.11b -- do you (trac
devs/testers) remeber to sanitycheck things like these before release ? I.e.
that common usage errors gives a reasonable and readable error messages ?

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIGKfixUW7FIqjOSwRArR9AJ9IDlHfAEAt6GqyKbMLsfjX1FuEZQCdEwO9
uEb2n9FsgzUWHNREKsFupCE=
=TZRl
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Tutorial on customizing the new ticket form

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Isaac.PEG skrev 18-04-2008 03:33:
| Could someone point me to a simple (perhaps even step-by-step)
| tutorial or help page explaining exactly how to add static content to
| the wiki edit / new ticket / ticket edit forms?
|
| I read through the following page, and found it inadequate (and a bit
| confusing on exactly where that example snippet is supposed to go).
| http://trac.edgewall.org/wiki/TracInterfaceCustomization

I agree this documentation could use an update -- but I'm afraid I don't have
the time to do anything about it right now.

| I also skimmed through the Genshi tutorial, but it seemed way more
| complex than what I want to do.  I have never used a templating system
| before (except through MS Word), though I understand the philosophy
| behind it.

Well, the upside is that the simple stuff actually *is* simple with genshi. If
you're using trac version 0.11b, with Genshi-templates, you can simply copy

~  /trac-install-path/ticket/templates/ticket.html

to the template folder of your trac-instance(s), and edit it in a normal text
editor.

Personally I find these templates include way too much logic in the view (in
model-view-controller terminology) -- but if you look at the file you'll notice
some familiar sections, such as:

~   Create ticket (...) on line 85.

and

~  Note: see (...) for help on using tickets on line 387


You can basically include any text you'd like here, probably adding a
paragraph-tag -- or better yet -- just a link to a wiki-page -- eg:

~  h2a href=${href.wiki('TracTickets')}READ THIS FIRST!/a/h2

| I'm using Trac as an issue tracker for the undergraduate curriculum
| written by the Physics Education Research Group at the University of
| Washington, and would like to have clear instructions on the naming
| conventions for tickets and wiki pages we are establishing.
|
| Thanks for any help or pointers you can share.

Again, I'd recommend keeping most of this documentation in the wiki, and just
make prominent links to it on the trac front-page, and maybe a help-link on
the ticket-page.

As you'll see if you follow the help-link -- you're free to edit all these
pages as you see fit.


Hope this gets you started.


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIDJnvxUW7FIqjOSwRAkEjAJ9GyBfO4tS5dJ9fawv6+0bDY0aJiwCgq3F0
UuOu1pDPrrle6ZnCCRCsKXw=
=WwVU
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: [Trac 0.11b2] [apache+mod_python] Basic authentication configuration issue

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Virtual Dust skrev 21-04-2008 08:27:
| Eirik Schwenke wrote:
| Does the webserver/webclient prompt for http-login on the url?
|
| No, there is no prompt at all.
| As I understand it, in the standard configuration, with basic http-auth
| enabled, and python running through mod_python, trac acquires the 
http-username
| from apache.
|
| Still, the locationmatch looks correct to me, which leaves an error in the
| passwd-file name -- as apache should refuse to start if you're missing
| mod_authn_file in the apache config.
|
| if the passwd-file was not found (or in the wrong format), apache would
| prompt for authentication anyway, but never success.
| Anything in the apache error.log ?
|
| You could try setting the log_level to DEBUG in trac.ini also -- might shed
| some light on what goes wrong, and when.
|
|
| I made some tests. At first, I explicitly set only one project:
| ...
| Location /test
| ...
| PythonOption TracEnv /home/httpd/trac-env/test
| ...
| LocationMatch /test/login
| ...
|
| With that, apache prompts for authentication and login process completes
| succesfully.
| Next, without reloading my browser, i restored my previous apache
| configuration and restarted the server : i reloaded the page in the
| browser. Login information was kept, and everything worked fine. But
| when I restarted the browser... No prompt, only the same error as
| ever... There is no relevant information in the log (Debug level is
| set). Only a WARNING: 500 Trac Error.
|
| This error persists even with an explicit LocationMatch /test/login in
| place of the regexp.

You have diagnosed the problem -- your apache config is wrong, and does not
demand/request authentication from the client.

But apache is successfully forwarding the request username to trac, so once you
figure out what's wrong with the LocationMatch-stuff, you should be home free.

| Note that I did this test with several browsers (firefox 2, firefox 3,
| lynx, opera), to be sure it was not a bug in it.

Unfortunately that's redundant in this case. For help debugging problems like
this I recommend the firefox liveheaders extention:

~ http://livehttpheaders.mozdev.org/

It's more convenient that just telneting to port 80 and trying to remember how
to speak http/1.1 fluently -- if not as much fun ;-)

| I will try with Trac 0.10 this afternoon or tomorrow to see if the
| problem may come from Trac 0.11b2.

It most likely won't - The problem is with apache not requesting authentication.

| I keep you informed.

I just now tested with the following in my local apache-config:

~ LocationMatch /[^/]+/login$
~  AuthType Basic
~  AuthName Projects
~  AuthUserFile /home/httpd/trac-env/trac.htpasswd
~  Require valid-user
~  /LocationMatch

And it demanded login-credentials for all /foo/bar/login-urls i threw at it.

(Note the trailing $ didn't make any difference wrt wether or not the section
worked, but it's best to be reasonably specific about LocationMatch-directives,
in case they're included in a complex apache-config).

I'd double-check my apache-config for typos and see if the apache error.log has
anything helpful to add -- because as far as I can understand the code you
posted earlier *should* work.


Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIDJRfxUW7FIqjOSwRAu02AKDM0eL7rERAWXfcuJfBwtd64/D9gQCgge0A
A2nkCdrVfZO8o3rA5NXoj8Y=
=cxZd
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: [Trac 0.11b2] [apache+mod_python] Basic authentication configuration issue

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Virtual Dust skrev 16-04-2008 21:54:
| Erik Bray wrote:
| On Wed, Apr 16, 2008 at 11:59 AM, Virtual Dust [EMAIL PROTECTED] wrote:
|
|  After browsing mailing-list archives and checking so many times my
|  configuration, i failed to resolve this Authentication information not
|  available error on http://projects.arcanes/myproject/login
|
| I didn't notice anything immediately wrong with your configuration.
| Just to ask a possibly stupid question: Did you try restarting Apache?
|
| Yes i did. After any modification in apache configuration. If only it
| could have been so simple. :)

Does the webserver/webclient prompt for http-login on the url?

As I understand it, in the standard configuration, with basic http-auth
enabled, and python running through mod_python, trac acquires the http-username
from apache.

Still, the locationmatch looks correct to me, which leaves an error in the
passwd-file name -- as apache should refuse to start if you're missing
mod_authn_file in the apache config.

Anything in the apache error.log ?

You could try setting the log_level to DEBUG in trac.ini also -- might shed
some light on what goes wrong, and when.


- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICPucxUW7FIqjOSwRAj+aAKCjqR3yljXAjrejBWbg8brIlOjN0wCfTvOE
RO0s0z6N6GEgbORAaVwAzGQ=
=C2eI
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Installing Trac on Leopard Server

[Eirik Schwenke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

M. Beckley Roberts skrev 15-04-2008 19:25:
| On Apr 15, 2008, at 1:13 PM, Emmanuel Blot wrote:
|
| I followed the wiki instructions and installed everything.
| ...
|AuthuserFile /dev/null
| Is THIS line in the wiki instructions ? If so, some fixes are
| required...
|
| yes it is. that line instructed to be in the Location section of
| both httd-subversion.conf and httpd-trac.conf.
|
| http://trac.edgewall.org/wiki/TracOnLeopardServer
|

It looks like the wiki-instructions attempt to use mod_apple_auth, for
authenticating against the standard ldap/kerberos backend provided by Leopard
- -- I don't know why someone thought adding a dummy AuthUserFile to the config
would help -- but then it seems that the mod_apple_auth module is very poorly
documented.

You might have better luck using either just basic auth (See the general
instructions) -- or try to use ldap:

~  http://www.macosxhints.com/article.php?story=20071024161139559


If you're new to trac and/or apache -- I'd suggest following the normal
instructions, using a passwd-file -- you might also have better luck following
the article linked at the top of the wiki:

~  http://sonzea.com/articles/subversion-trac.html


Sorry I can't be of more help, but as I don't have any Apple systems to test
this on, I can't be sure what the best way to set up Apache with authentication
through the built in user database is.

Maybe one of the trac developers can be of more help.

Best regards,

- --
~ .---.  Eirik Schwenke [EMAIL PROTECTED]
( NSD ) Harald Hårfagresgate 29Rom 150
~ '---'  N-5007 Bergentlf: (555) 889 13

~  GPG-key at pgp.mit.edu  Id 0x8AA3392C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIBPaWxUW7FIqjOSwRAvt3AJ9e8/3BZJzNHbYN8UKjMmI9YyIjYACfVKlQ
44+qrwNuzdEOUFmHO1wZ6bw=
=GKxr
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: using genshi =0.5

[Eirik Schwenke]

On Apr 10, 4:44 pm, didley [EMAIL PROTECTED] wrote:
 On Apr 8, 6:01 pm, John Hampton [EMAIL PROTECTED] wrote: didley wrote:
   the same message again. To use the easy_install seems the same as to
   usehttp://genshi.edgewall.org/browser/trunkandcooking a egg.

  Assuming that you downloaded a zip from the above link, it should be the
  same.  However, you said in your first email that you were using Genshi
  0.4.5dev.  If you actually installed trunk, this should not be the case.

 I told you I can't use genshi=0.5 . So I went back to 0.4.5dev. And
 my question about cooking a egg was just for interesting if there any
 different between cook an egg or use easy_install.

 http://genshi.edgewall.org/browser/trunk/setup.py#L70

  Clearly shows that the version you should be seeing is 0.5.  So if you
  really are seeing 0.4.5dev, then you must have that version lying around
  someplace and it's being loaded instead of trunk.

 See above. I can't see because I can't connect to the webserver. The
 egg after using easy_install is named Genshi-0.5dev-py2.5-win32.egg

  Also, you original message just said that you're getting a The site
  can't be displayed message.  Are you sure that this is actually related
  to Genshi?

 I'm not sure. after installing Genshi 0.5 I can't connect to the
 webserver. When I go back to 0.4.5dev than it works.


Hi,

I think I found the problem (and the solution) - please see:

http://trac-hacks.org/attachment/ticket/2907/genshi-0.5.patch


best regards,

Eirik Schwenke

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---