--- Log opened Mon Jan 11 06:47:27 2010
06:47 -!- ecrist [i=ecrist@pdpc/supporter/professional/ecrist] has joined ##openvpn-discussion
06:47 -!- Irssi: ##openvpn-discussion: Total of 7 nicks [1 ops, 0 halfops, 0 voices, 6 normal]
06:47 -!- Irssi: Join to ##openvpn-discussion was synced in 1 secs
07:23 -!- alibaba [n=xerox@goliath.hantsch.co.at] has joined ##openvpn-discussion
07:52 < reiffert> mattock: Would you please name the points for the today discussion again, I cant find them in my emails.
08:20 -!- alibaba [n=xerox@goliath.hantsch.co.at] has left ##openvpn-discussion ["Konversation terminated!"]
08:56 -!- ecrist changed the topic of ##openvpn-discussion to: Community Forum TODAY 1900UTC || http://users.utu.fi/sjsepp/openvpn/Community_site_requirements.mm.html
09:50 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
09:50 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
10:13 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [1 ops, 0 halfops, 1 voices, 6 normal]
10:21 <+Kas> Good Morning/Evening everyone!
10:26 < ecrist> hello, kas
10:27 < ecrist> fyi, if you identify to nickserv before joining, you will get +o
10:27 -!- rob0 [n=rob0@tuxaloosa.org] has joined ##openvpn-discussion
10:28 -!- Irssi: ##openvpn-discussion: Total of 9 nicks [1 ops, 0 halfops, 1 voices, 7 normal]
10:40 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has left ##openvpn-discussion ["Leaving"]
10:40 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
10:40 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
--- Log opened Mon Jan 11 12:43:21 2010
12:43 -!- ecrist [i=ecrist@pdpc/supporter/professional/ecrist] has joined ##openvpn-discussion
12:43 -!- Irssi: ##openvpn-discussion: Total of 11 nicks [2 ops, 0 halfops, 2 voices, 7 normal]
12:43 -!- Irssi: Join to ##openvpn-discussion was synced in 1 secs
12:47 -!- fkr [i=fkr@news.bytemine.net] has joined ##openvpn-discussion
12:53 -!- nneul [n=nneul@infinity.srv.mst.edu] has joined ##openvpn-discussion
12:57 -!- freezer [n=freezer@sd-89-84.stud.uni-potsdam.de] has joined ##openvpn-discussion
12:57 < freezer> hi
12:57 <@mattock> hi
12:58 -!- Bushmills [n=nnnBushm@verhau.de] has joined ##openvpn-discussion
13:00 -!- cron2 [n=gert@dhcp-174.greenie.muc.de] has joined ##openvpn-discussion
13:02 < reiffert> cum tempore?
13:02 <@mattock> hi all, I think we can start
13:03 <@mattock> first of all, have you had time to look at the requirements specification draft: http://users.utu.fi/sjsepp/openvpn/Community_site_requirements.mm.html
13:03 < vpnHelper> Title: Community site requirements (at users.utu.fi)
13:04 <@mattock> as I said in one email, I think it's best to keep the meeting loosely structured
13:04 <@mattock> here's what I think we should try to figure out, please comment:
13:06 <@mattock> - check if the existing requirements are sane
13:06 <@mattock> - discuss your concerns regardings the future community site and it's services (e.g. what thing you think are missing)
13:06 <@mattock> - discuss possible technical solutions (e.g. wiki)
13:06 <@mattock> - select a basic platform for the community site (e.g. a wiki-based site)
13:06 <@mattock> does that sound good?
13:07 < derRichard> sounds good to me
13:07 < cron2> yes
13:08 < dazo> ack .... but I would also like to hear from OpenVPN people their ideas for a broader and more inclusive community approach .... what do they try to achieve, and how
13:08 < reiffert> ack
13:08 <@mattock> dazo, sounds good
13:09 <@mattock> perhaps we should start with the company's ideas - what do you think James?
13:09 <@jamesyonan> sounds good
13:09 <@mattock> could you share your view, james?
13:09 <@mattock> views
13:10 <@jamesyonan> As far as a site specification, are there wiki packages that specialize in hosting open source projects?
13:11 <@mattock> jamesyonan, I'm not sure but I would not count on it... for example OpenSUSE uses plain Mediawiki with integrated services
13:12 <@mattock> then there are a few "Forge" applications, but those are pretty strictly focused on hosting tons of individual projects
13:13 <@mattock> this is worth checking out, though
13:13 < rob0> Wiki's a good idea, and most of them are probably adaptable to do what you want. The only one I ever ran personally is pmwiki, which I like (good support right here on Freenode), but I can't say what's best.
13:13 <@jamesyonan> It would be great if someone has developed an open source site package with normal wiki functionality but that also tries to tackle more specialized functionality, such as handling the patch queue, integrating with source control, letting people comment/vote on specific patches, etc.
13:13 <+Kas> mattock, what kind of integrated services have you looked at for mediawiki (if you have looked at any) as far a project hosting is concerned?
13:14 <@mattock> jamesyonan, Trac has such integration
13:14  * cron2 has used "trac" for that - wiki plus bug trackre
13:14 <@mattock> part of it, at least
13:14 < ecrist> the audience with such a software package is limited enough, I think you're going to find you're restricted to commercial solutions.
13:14 < cron2> exactly
13:14 < dazo> sourceforge.net do provide MediaWiki as a part of the project hosting, it just needs to be enabled
13:14 < dazo> in addition to trac as well
13:14 < ecrist> OSS packages are mostly geared toward general use
13:14 <@mattock> kas, I have not looked at any mediawiki plugins yet
13:14 < ecrist> trac has an integrated wiki, which may suit openvpn's need
13:14 < ecrist> and it integrates with svn
13:14 -!- rwscott [n=rwscott@207.236.169.155] has joined ##openvpn-discussion
13:14 < reiffert> Dont forget the search functionality trac comes with, searching through wiki pages as well.
13:15 <@mattock> ok, let's take a closer look at Wiki packages then
13:15 <@mattock> Trac is one good option
13:16 <@mattock> it is, however, limited to one project
13:16 <@mattock> according to my knowledge
13:16 < dazo> trac is probably one of the better ones in regards to software development .... but some people to complain about maintenance can be hard from time to time
13:16 <@mattock> so for subprojects we'd need other Trac instances or something else
13:16 < cron2> you can run multiple trac instances on a single server, for different projects
13:16 < dazo> what do you mean with limited to one project?
13:16 < dazo> cron2:  that's not a good approach if you want to have something which is decent to maintain
13:17 < cron2> dazo: never had to maintain a trac installation, so can't comment on that - from a user side, it "just worked" :)
13:17 <@mattock> dazo, I mean that it's not possible to host several projects using the same trac instance... only one set of milestones and such... unless that has changed
13:18 < dazo> mattock:  in regards to roadmap, and such things, you might be correct
13:18 <@jamesyonan> is trac agnostic about the back-end SCM?  I know that trac integrates well with svn, but what about other packages like git?
13:18 < ecrist> what other projects are there?  aren't we just concerned with openvpn?
13:18 < ecrist> http://trac-hacks.org/wiki/TracGitPlugin
13:18 < reiffert> There are git plugins for trac.
13:18 < vpnHelper> Title: TracGitPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
13:18 < dazo> there are a couple of git plug-ins to track ... and that works very well for one project I'm involved in (python-dmidecode)
13:18 < cron2> ecrist: things might get developed together with openvpn but independently so - like "gui for specific platforms" etc
13:19 <@mattock> ecrist, currently there are no other projects, but if we want to provide hosting for subprojects then it might be a problem
13:19 < cron2> ecrist: different release cycles, different platforms, ...
13:19 < ecrist> wouldn't those simply be different branches of the same tree?
13:19 < reiffert> As far as I understand http://trac.edgewall.org/wiki/TracEnvironment you can have several projects with a single trac instance.
13:19 < vpnHelper> Title: TracEnvironment – The Trac Project (at trac.edgewall.org)
13:20 <@mattock> ecrist, it may be difficult / cumbersome to limit access to the different SVN branches
13:20 < cron2> ecrist: not branches, if the source code is separate.  Like "Tunnelblick" for MacOS - it's a gui that runs the unmodified openvpn binary
13:20 -!- nneul [n=nneul@infinity.srv.mst.edu] has quit ["Leaving"]
13:20 < cron2> completely separate source, but some projects might like the idea of being hosted on the same server as openvpn itself
13:20 <@mattock> could we discuss non-technical issues a bit :)
13:20 < cron2> other stuff will be branch-like, like the various IPv6 patches floating around
13:20 <@jamesyonan> being able to support multiple projects might be a good thing -- for example, some people have suggested that the Windows TAP driver be a separate project
13:21 <@mattock> can we conclude that we need _support_ for multiple project hosting?
13:21 < dazo> but honestly .... wouldn't it in this case be better to more have an "index" where projects can register ... and they can be hosted wherever?
13:21 < ecrist> cron2: so just a different tree under trunk/
13:21 <@mattock> dazo, yes, that's one option
13:22 < dazo> then each project will select whatever environment which is optimal for them
13:22 < cron2> ecrist: yes
13:22 < cron2> dazo: yes, the index is definitely needed (and needs some maintaining to weed dead projects)
13:22 <@mattock> jamesyonan, do you think we (the company) would need to host multiple projects of our own?
13:22 < dazo> true .... but that job, you'll have anyway ... if it is a local hosting or not
13:23 < cron2> mattock: splitting "openvpn" into "openvpn, windows tap, ..." might help you with releasing different bits on different schedule (like "a windows TAP driver bug has been found and needs releasing")
13:23 < dazo> mattock:  I would recommend to consider that .... but in that case, the maintenance will be less for you, as you only have your own projects to maintain a system for
13:24 <@jamesyonan> probably not -- I think the main impetus for people wanting projects like the TAP driver to be separated is projects that only care about the TAP driver, and don't depend on OpenVPN itself
13:24 < dazo> +1
13:24 <@jamesyonan> But I don't see why we couldn't just take the different directories under trunk/ approach
13:24 < dazo> easy-rsa and the windows gui would be two other candidates
13:24 < cron2> +2
13:25 < dazo> jamesyonan:  that will work if you continue to stay in SVN .... if moving over to git, I'd recommend to split it up into different repositories
13:25 < ecrist> is easy-rsa developed by openvpn tech?
13:26 <@jamesyonan> yes
13:26 <@mattock> I think we should have some means of hosting multiple projects. Migrating data from one application to another is often hard, takes time and is very annoying in general
13:26 < dazo> in fact, I'd advocate a repository split anyhow .... even if continuing with svn
13:26 <@jamesyonan> why is a repository split better than the  different directories under trunk/ approach?
13:28 < dazo> svn and cvs are those who do work best in that approach, but it is to have a commit log which is connected to each project ... if you do svn log in trunk/ ... you'll get all data for all projects .... and the more commits you get in svn, the slower it gets
13:29 <@jamesyonan> We haven't had problems yet with svn performance
13:29 <@mattock> dazo, good point... if the projects (e.g. OpenVPN and OpenVPN GUI) are develop separately, it's nice to have a completely separate commit history
13:29 < ecrist> dazo: I know of svn repos with nearly 1M commits
13:30 <+Kas> dazo, I like that idea as well
13:30 <@mattock> I think it makes sense to try to develop loosely coupled projects separately
13:30 < derRichard> +1
13:30 <@jamesyonan> re: commit history, you can always isolate the commit history of a given branch in svn, i.e. svn log http://svn.openvpn.net/projects/openvpn/trunk
13:30 < vpnHelper> Title: Revision 5363: /trunk (at svn.openvpn.net)
13:30 < dazo> ecrist:  I've been using the SVN repo at Apache Qpid ... with 65000 commits .... it took me 20-30 seconds to get the changelog
13:31 <@mattock> ecrist, SVN can be really slow with high number of commits
13:31 <@jamesyonan> What are the opinions on svn vs. git?
13:32  * dazo is pro git .... easier, quicker/snappier than SVN in his opinion
13:32  * derRichard preferes git
13:32 < cron2> git seems to be much easier if you want to create a "local branch"
13:32 < dazo> cron2:  indeed
13:32 < cron2> as in "get openvpn checkout, work for weeks on local repository, with local change history etc, and then submit the result back"
13:32 <@jamesyonan> any downsides or weak points in git?
13:32 <@mattock> jamesyonan, I believe git could help a lot in branching and merging... meaning "local branches" for testing patches and new features
13:33 <+Kas> git FTW
13:33 < cron2> jamesyonan: git needs un-learning how cvs/svn work ("central repository")
13:33 < derRichard> jamesyonan: git is sometimes tricky when you don't know what you'r doig.
13:33 < derRichard> sometimes it is too powerful ;)
13:33 <@mattock> derRichard, isn't the basic Git workflow pretty easy, though
13:34 < derRichard> yes it is
13:34 < dazo> yeah ... but you'll never loose anything, unless you really do something incredibly stupid
13:34 -!- berniv6 [n=berni@2001:1b10:1000:0:0:0:26c3:1] has joined ##openvpn-discussion
13:34 <@mattock> and without the central repository you can just ask for the code in the mailinglists :)
13:34 -!- Irssi: ##openvpn-discussion: Total of 17 nicks [2 ops, 0 halfops, 2 voices, 13 normal]
13:35 <@mattock> jamesyonan, what are your thoughts about the amount of community involvement?
13:35 <+Kas> http://git.or.cz/gitwiki/GitSvnComparsion
13:35 < vpnHelper> Title: GitSvnComparsion - GitWiki (at git.or.cz)
13:35 <@mattock> dazo asked for this previously
13:35 < derRichard> in a first step we could use svn and git in parallel. git-svn is very nice
13:35 < dazo> http://whygitisbetterthanx.com/
13:35 < vpnHelper> Title: Why Git is Better Than X (at whygitisbetterthanx.com)
13:36 < dazo> git-svn is always my approach when I'm forced to svn .... but native git is easier to work with, but it does it the job pretty nicely, yes
13:36 <@mattock> I think Git makes a lot of sense especially if development becomes more distributed one way or another
13:36 <@jamesyonan> I would love to see more community involvement, and I think we can do that if we develop a structure around it that takes away myself as a bottleneck
13:37 -!- TCW__ [i=mschmitt@booster.qnetp.net] has joined ##openvpn-discussion
13:37  * ecrist agrees
13:37 < dazo> I believe git can help out in sharing the development phase .... as jamesyonan only needs to pull trees from people he can trust
13:37 <@mattock> jamesyonan, I believe you had some ideas how to accomplish that... could you tell about those?
13:38 < dazo> yes, please!
13:38 < cron2> I think what we need for good community involvement is a working way to get code back into the "master" repository, plus a working bug tracker :-)
13:38 -!- ribasushi [n=rabbit@dslb-084-063-042-037.pools.arcor-ip.net] has joined ##openvpn-discussion
13:38 <@mattock> by the way guys, we're supposed to have the "Development model" discussion tomorrow :)
13:38 <@mattock> surprising how easy it is to drift off course.
13:39 <@mattock> however, I think we can touch this a bit
13:39 <@jamesyonan> I think the git vs. svn question is very relevant here because with a distributed repository, it would be easier to create a development structure where patches could be vetted and tested by the community before making it into the master repository
13:39 < dazo> yes
13:40 <@mattock> jamesyonan, agreed
13:40 <@mattock> what do you think about having separate branches and branch maintainers? E.g. an "unstable" branch
13:41 < dazo> mattock:  I'd rather say that master branch is the development branch ... and when a release hits, you'll tag the master branch with a version number
13:42 < dazo> mattock:  and if there comes some patches which must in .... you'll branch out that tag, add the patch and a new patch-release can be made
13:42 < cron2> dazo: I think you'll need to have a stable-and-bugfix branch plus a fast-moving branch alive at the same time
13:42 < cron2> well, yes.
13:42 < dazo> cron2:  that's not needed ....really :)
13:42 < dazo> The Linux source tree have 1 master branch .... and a lot of tags
13:42 -!- Schlaubi [n=daniel@p5B0A1A24.dip0.t-ipconnect.de] has joined ##openvpn-discussion
13:43 < ecrist> dev model again, folks.  more on community site/etc
13:43 < cron2> dazo: what you described is effectively the same - a well-defined way to do patch-releases
13:43 < ecrist> we can think/discuss this tomorrow
13:43 < dazo> true
13:43 <@mattock> ecrist, good point
13:43 < derRichard> what bug tracker software shall we use? trac? bugzilla?
13:43 <@mattock> a summary so far, if you dont mind:
13:43 < ecrist> JIRA gives away full copies to OSS
13:44 <+Kas> ecrist, REALLY?
13:44 < ecrist> yes
13:44 <@mattock> - we need to maintain possibility for several projects
13:44 <@mattock> - we need to support Git
13:44 < ecrist> freeswitch uses it, and I just obtained a license for my own projects
13:44 <@mattock> agreed, everyone?
13:44 < derRichard> yes :)
13:44 < cron2> mattock: yes
13:44 < ecrist> I think the repository still needs discussion.
13:45 < dazo> trac - plain and easy .... bugzilla - advanced, big, might have too much features .... JIRA is not bad, but somewhere closer to bz
13:45 < dazo> mattock:  agreed
13:45 <@mattock> ecrist, shoot
13:45 <+Kas> Jira looks very nice, I was researching it a while back.
13:46  * derRichard preferes trac.
13:46 < dazo> ecrist:  that license .... does it also give the source code with the license?
13:46 < ecrist> mattock, tomorrow.
13:46 < ecrist> yes
13:46 <@mattock> ecrist, ok
13:46 < ecrist> dazo, yes, it does.
13:46 <@jamesyonan> Trac seems to have a serious community behind it with lots of plugins for everything
13:46 < ecrist> what I don't like about trac, is it's very slow.
13:47 < derRichard> but openvpn is not that big...
13:47 < reiffert> dazo: I think that your propasal made 3 years of no stable release on openvpn.
13:47 < reiffert> I've seen trac with many projects, I really like the way it works.
13:47 <@mattock> ok, so what do you think about this: we take a closer look at Wiki-based solutions (e.g. Trac) and see how they fit into the big picture
13:47 < ecrist> my personl trac is very slow, and it's on good hardware
13:47 < dazo> Trac can be slow .... but I believe that's just as much not well maintained database in many cases
13:48 < dazo> which also depends on the DB backend
13:48 <@jamesyonan> we use trac internally at OpenVPN Tech and it's acceptably fast
13:49  * dazo reads "it could be faster" between the words here ;-)
13:49 < reiffert> macports trac is running fast. Huge project.
13:49 < derRichard> trac has also a very nice wiki software
13:50 < ecrist> if we use something like trac, we get wiki, ticketing, and repo browser all in one
13:50 <@mattock> have agreed upon a Wiki-based community site?
13:50 <@mattock> are there other options?
13:50 <@jamesyonan> dazo: not really, I just never recall thinking that it was slow
13:50 < dazo> :)
13:51  * derRichard votes for a wiki-based site
13:51 < ecrist> in trac's defense, I've never bothered tuning it.
13:51 < dazo> jamesyonan:  that sounds good, indeed
13:52 <@mattock> ok, so a Wiki-based site with support for several projects and Git support
13:53 < cron2> +1
13:53 < dazo> +1
13:53 <@jamesyonan> +1
13:53 <+Kas> Is there a possibility of replacing tracs wiki with wikimedia?
13:53 <@mattock> so we decided the platform
13:53 < dazo> Kas:  not afaik
13:53 < ecrist> not without a bit of work
13:53 < reiffert> Kas: you might loose integration into dev process.
13:54 < ecrist> trac's wiki is heavily integrated in the package
13:54 < dazo> Kas:  it might be some plug-ins which gives mediawiki features into trac wiki, though
13:54 <@jamesyonan> there's actually a plugin that lets you use mediawiki's markup language in trac
13:54 <@mattock> as what comes to technical solutions... Trac is clearly the favorite and needs a closer look
13:55 <+Kas> jameyonan, I am aware of that, don;t we use that on internal?
13:55 <@jamesyonan> trac is much more oriented toward hosting development sites than mediawiki
13:55 <@jamesyonan> Kas: yes
13:55 < dazo> which is why I believe trac is a better choice, when looking for something with more integration towards development
13:56 < reiffert> List of trac wiki plugins: http://trac.edgewall.org/wiki/PluginList#WikiMacrosExtensions
13:56 < vpnHelper> Title: PluginList – The Trac Project (at trac.edgewall.org)
13:56 < ecrist> I would posit that we could have a couple distinct sites.  A developer site, utilizing trac's wiki, and a user site, using mediawiki.
13:56 <@mattock> jamesyonan, if we are commited to involving the community more a Wiki geared towards OSS development is a natural choice
13:56 <@mattock> ecrist, that's a good point
13:57 <@mattock> The OpenSUSE site is a good example of a pretty nice Mediawiki site: http://en.opensuse.org/Welcome_to_openSUSE.org
13:57 < dazo> but is there a particular need in the OpenVPN company which requires such things to be hosted internally?  When aiming for more community involvement?
13:57 < ecrist> in my experience, it's not a bad thing to keep typical users out of a development area, where they may only further confuse themselves.
13:57 < dazo> +1
13:58 < reiffert> Quoting the trac faq:
13:58 < reiffert> Can I convert MediaWiki pages to Trac? ¶
13:58 < reiffert> Yes.
13:58 <@mattock> ecrist, do you think the content for the users and developers can be entirel separate?
13:58 <@mattock> entirely
13:58 <@mattock> also, we need to integrate all of the stuff together
13:58 -!- rwscott [n=rwscott@207.236.169.155] has quit [Remote closed the connection]
13:59 <@mattock> Am I correct in assuming that people have asked for "official" forums?
13:59 < dazo> mattock:  I believe so ... developers version would (should?) have much more development oriented information, documentation for the coming versions which is not released yet .... code documentation, etc
13:59 < ecrist> I think there should be links, and possible references, but for the most part, they should be separate.
13:59 <@mattock> dazo, ok
13:59 <@mattock> ecrist, that's probably a good plan
13:59  * dazo agrees with ecrist
14:00 < reiffert> Have a look at macports.org
14:01 <@mattock> having a separate development area would probably make things easier... less integration
14:01 <@mattock> and probably better experience for both developers and users
14:02 < reiffert> a user wiki surely wants to point to tickets and its solutions.
14:02 < ecrist> that can easily be done, while maintaining separate wikis
14:03 <@mattock> reiffert, perhaps we could just use static URL without any magic?
14:03 <+Kas> I like the idea of seperate wikis for users and developers
14:03 <@mattock> kas, agreed
14:04 <@mattock> do we all agree?
14:04 < dazo> ack
14:04 <@jamesyonan> yes
14:04 < derRichard> ack
14:04 < reiffert> Personally I dislike having two different wiki engines.
14:04 <@mattock> reiffert, why is that?
14:04 < reiffert> In one engine "bold" is *** bold text here
14:05 <@mattock> oh, you mean formatting, right?
14:05 < reiffert> and in the other bold is <b> bold here   choose one.
14:05 < ecrist> reiffert: you can make those the same
14:05  * dazo believes the MediaWiki formatting plug-in to trac solves that
14:05 <@mattock> I think this is a problem we should try to solve... and I'm sure we can
14:06 <@jamesyonan> Aren't we agreed on using trac, but just having two different instances of trac for user and devel, not different wiki engines?
14:06 < ecrist> no, we were talking about trac for development and mediawiki for users
14:06 <@mattock> jamesyonan, that's possible... however I think Trac is too oriented for development
14:07 < reiffert> dazo: I cant see such a plugin.
14:07 <@mattock> I mean I have yet to see a Trac installation that does not immediately look like Trac
14:07 < ecrist> trac.macports.org
14:07 < ecrist> doesn't look (readily) like trac
14:07 < dazo> reiffert:  http://trac-hacks.org/wiki/MediaWikiPluginMacro
14:07 < vpnHelper> Title: MediaWikiPluginMacro - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
14:08 <@jamesyonan> I see -- I would tend to agree that having two different engines might suck
14:08 <@mattock> ecrist, that's pretty nicely formatted
14:09 <@mattock> how about this: we _try_ to avoid using two wiki engines
14:09 < dazo> ack
14:09 <@mattock> but go with two if we encounter big problems
14:09 < ecrist> I'm OK with whatever, so long as dev/users are separate
14:10 < reiffert> ecrist: assuring that devs dont write user pages?
14:10 < dazo> heh
14:10 <@mattock> reiffert, lol
14:10 < ecrist> reiffert: *most* importantly ;)
14:11 <@mattock> ok, we've made quite a lot of progress
14:11 <@mattock> how about some of the other requirements...
14:11 < Bushmills> how important would wiki<>irc interaction be?
14:12 < cron2> I'm not sure how that would look like
14:12 <@mattock> bushmills, what kind of interaction?
14:12 < reiffert> There is CIA integration for trac.
14:12 < reiffert> it's a notification plugin for irc
14:13 < cron2> what does it do?  send message to IRC if something changes in trac?
14:13 < ecrist> yes
14:13 < Bushmills> good part can probably be done by bots, such as, adding references to bugs or tickets in a way easy to access to irc users, or newsflashing new releases
14:13 < ecrist> we currently do similar with vpnHelper and the forum
14:13 < ecrist> that uses RSS feeds, however
14:13 < cron2> interesting
14:13 <@mattock> very much so
14:13 < dazo> thats probably more interesting in regards to bug trackers and project releases
14:14 < ecrist> however, if we had trac setup, we could just use trac's rss feed to do the same
14:15 < ecrist> this is what I do at my job, we have an XMPP bot which monitors nagios, trac, and wiki RSS feeds
14:15 < Bushmills> +1 xmpp
14:15 < dazo> mattock:  I just stumbled upon this one ..... http://www.redmine.org/
14:16 < vpnHelper> Title: Redmine - Overview - Redmine (at www.redmine.org)
14:16 <@mattock> dazo, we used Redmine in my previous job
14:16 <@mattock> a bit clunky but otherwise quite ok
14:16 <@mattock> we used Trac and migrated to Redmine
14:16 <@mattock> due to the multi-project support
14:16 < dazo> I've only used the wiki part at work ... didn't know it had multiple projects, issue tracking and git support ...
14:17 -!- cron2 [n=gert@dhcp-174.greenie.muc.de] has left ##openvpn-discussion ["-server freenode2 #openvpn"]
14:17 <@mattock> ok, so Trac and Redmine are two possible candidates for the developer area
14:17 -!- cron2_ [n=gert@dhcp-174.greenie.muc.de] has joined ##openvpn-discussion
14:17 <@mattock> btw. redmine does not support a "global" wiki
14:17 < dazo> good point
14:17 <@mattock> so user area would have to be on another engine
14:17 < reiffert> cron2_: CIA works with remote xml stuff ..
14:18 < dazo> mattock:  or ... there would be a "main page"-project in redmine
14:18  * cron2_ is too stupid for IRC today
14:18 < reiffert> cron2_: http://cia.vc/doc/
14:18 < vpnHelper> Title: CIA.vc - What is CIA? (at cia.vc)
14:18 <@mattock> I've seen a few OSS projects using Redmine
14:19 <@mattock> dazo, that's definitely a possibility, but I think having a different, wiki-only solution would be less work
14:19 < reiffert> some examples:
14:19 < dazo> might be
14:19 < reiffert> (from #freetz)
14:19 < reiffert> 13:41 < CIA-1> markuschen tickets/packages * #562 /: (http://trac.freetz.org/ticket/562#comment:21)
14:19 <@jamesyonan> does Redmine have a decent plugin library (or better yet, support trac plugins?)
14:19 < vpnHelper> Title: #562 (Ausblenden von warnings und build, configure logs) – Freetz (at trac.freetz.org)
14:19 < reiffert> `12:00 < CIA-1> oliver tickets/other * #471 /: status <- accepted (http://trac.freetz.org/ticket/471#comment:5)
14:19 < vpnHelper> Title: #471 (Umstrukturierung im Source Verzeichnis) – Freetz (at trac.freetz.org)
14:19 <@jamesyonan> I gotta run in 10 minutes
14:20 <@mattock> jamesyonan, there are lots of plugins for Redmine, but probably not as many as for trac
14:20 <@mattock> jamesyonan, ack
14:21 <@mattock> I think we're almost there... what about the forum issue? People have been asking us (the company) for "official" forums... and Francis wants those too. I want to maintain integratibility with external sites (such as ovpnforums and openvpn e.v.)
14:21 <@mattock> any preferences for forum software
14:21 <@mattock> ?
14:21 < Bushmills> irc, wiki + forum may introduce some risk of fragmentation
14:21 < Bushmills> irc+wiki or irc+forum together go well
14:21 < reiffert> Personally I dislike forums, so I would not take part.
14:22 < rob0> Well, I prefer mailing lists. :) I don't participate in Web forums.
14:22 <@mattock> reiffert, me too, but users want them for some reason I can't figure out :)
14:22 < Bushmills> tell them that the forum is called "wiki"
14:22 <@jamesyonan> can we do a forum that would bidirectionally replicate posts to/from mailing lists to avoid fragmentation?
14:22 < reiffert> mattock: they even use a browser for sending emails ...
14:22 < dazo> I would say that if there are *clear information* about *where* to get help .... whatever will work ... but it needs to be communicated
14:23 <@mattock> reiffert, that's true
14:23 <@mattock> dazo, ack
14:23 < Bushmills> some wikis allow blog style entries, making them a bit forum-alike
14:23 < rob0> The sad thing is, a Web forum might not attract anyone who is able to help answer questions.
14:23 < dazo> and the mailing-list are already working very well .... using wiki + mailing-list should cover a lot
14:23 <@mattock> I think forums are beneficial in that they allow users to help themselves...
14:24 < dazo> I personally find wiki's better than forums, as the information is better organised there
14:24 <@mattock> anyways, I think we can discuss the forum issue later on
14:25 <@mattock> In fact, I think we should discuss the forums on openvpn-users mailinglist
14:25 <@mattock> I think we covered quite a lot today... a summary
14:25 <@mattock> dev/user space separate
14:25 <@mattock> • wiki-based sites
14:25 <@mattock> • try to avoid having two wiki engines
14:25 <@mattock> • check out Trac and Redmine
14:25 <@mattock> anything else?
14:25 < dazo> what could be considered on the -users list is to lock it up, so that you don't have to register .... but spam can be an issue
14:26 < dazo> mattock:  ack
14:26 <@mattock> dazo, true
14:26 < Schlaubi> i think forums are good for users to help themselfes and other users, wikis are good for howtos and so on
14:26 < Bushmills> captchas are some help
14:26 <@mattock> sclaubi, agreed
14:26 < Bushmills> (blocking china too :D )
14:26 < dazo> heh
14:26 < dazo> Bushmills:  but most of our users are Chinese :-P
14:26 < rob0> Hmmm, is that really what openvpn should do? OpenVPN is an important tool there.
14:27 < Bushmills> link spam without any protection is really bad
14:27 <@mattock> I guess we'll touch these same issues tomorrow in the "development model" meeting
14:27 < dazo> rob0:  you mean we should connect to a openvpn based VPN to access all the gory details? ;-)
14:28 < dazo> "make yourself worthy to access our valuable info!"
14:28 <@mattock> dazo, lol :)
14:28 < rob0> Countries like China and Australia need openvpn to get around censorship.
14:28 <@mattock> talk about streamlines processes
14:29 <@jamesyonan> I gotta run
14:29 <@mattock> ok, I think were done for today. Agreed, everyone?
14:29 <@jamesyonan> thanks guys
14:29 < dazo> thank you too!
14:29 < derRichard> agreed
14:29 <@mattock> jamesyonan, very nice you could attend!
14:29 <+openvpn2009> bye James
14:29 < Schlaubi> bye
14:29 < derRichard> bye
14:29 -!- jamesyonan [n=jamesyon@c-76-120-71-74.hsd1.co.comcast.net] has left ##openvpn-discussion []
14:29 <+Kas> Seeya James, thanks for attending.
14:29 <@mattock> bye all!
14:30 <+Kas> Thanks for running this mattock!
14:30 < cron2_> yes - thanks & bye
14:30 <@mattock> kas, no probs!
14:30 <@mattock> see you guys tomorrow! I'm soon off to bed, it's getting late here (in Finland)
14:30 < ecrist> see /topic for channel log
14:31 <+Kas> This is an exciting new chapter for OpenVPN! I am glad we have such a supportive community, you guys are the best!
14:31 <@mattock> I agree!
14:31 < rob0> No we're not! We tell people to RTFM, what nerve!
14:32 <+Kas> lol!
14:32 <@mattock> rob0, that's not the way to do it, haven't you read the manual on how to help people?
14:33 < Bushmills> first he must read the manual about how to read the manual
14:33 < dazo> but still .... it would be good if you guys (openvpn ppl) could put words on what you would like to gain from the community, and how the community could gain from you .... because trying to make use of each other without a clearly defined strategy, it can be a painful road to walk
14:33 < rob0> What I do is say, "see $FOO in the $BAR man page." It upsets them. I'm fine with that.
14:33 < ecrist> it *has* been a painful road to walk for almost 2 years.
14:33 <@mattock> dazo, agreed
14:34 < dazo> to set the expectation levels right
14:34 <+Kas> agreed
14:34 < reiffert> :)
14:34 <@mattock> we should definitely discuss those issues more tomorrow
14:35 < cron2_> I'll be late tomorrow (conflicting appointments) but will read the log
14:35 -!- Schlaubi [n=daniel@p5B0A1A24.dip0.t-ipconnect.de] has quit ["Verlassend"]
14:35 < dazo> but remember that F/OSS is more than just the development of the code .... it is much more ...
14:35 <@mattock> dazo, please remind all of us about the strategy tomorrow
14:36 <@mattock> dazo, true... coding is only a small part
14:36 < dazo> mattock:  I'll do ... I'd appreciate some more concrete ideas
14:36 <@mattock> dazo, have you take a look at this: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html
14:36 < vpnHelper> Title: OpenVPN development requirements (at users.utu.fi)
14:37 < dazo> mattock:  not sure
14:37 <@mattock> dazo, I know, they all look the same :)
14:38 < dazo> :)
14:38 < cron2_> mattock: good list, now we need answers to that :-) - looking forward to read up on tomorrow's discussion
14:38 -!- ecrist changed the topic of ##openvpn-discussion to: Developer Forum January 12, 2010 1900UTC || Logs at http://secure-computing.net/logs/%23%23openvpn-discussion.log (updated every 10 mins)
14:39 < dazo> cron2_:  well said!
14:39 <@mattock> I like mindmaps, so please download Freemind, remove the .html from the URL and see the real deal
14:40 <@mattock> the HTML-formatted documents in Freemind are pretty cheesy
14:40 <@mattock> hard to read
14:40 <@mattock> anyways, gotta split, see you tomorrow
14:40 <@mattock> bye
14:40 < dazo> c'ya
14:40 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit ["Leaving."]
14:40 -!- Irssi: ##openvpn-discussion: Total of 16 nicks [0 ops, 0 halfops, 2 voices, 14 normal]
14:49 < derRichard> cu
14:49 -!- derRichard [n=derRicha@ununbium.nod.at] has left ##openvpn-discussion []
14:50 -!- cron2_ [n=gert@dhcp-174.greenie.muc.de] has left ##openvpn-discussion []
14:53 -!- cron2 [n=gert@2001:608:4:0:222:68ff:fe7f:7420] has joined ##openvpn-discussion
15:03 -!- tempuser [n=tempuser@72.22.215.114] has joined ##openvpn-discussion
15:04 < tempuser> are you guys still discussing hosting/projects?
15:05 < ecrist> no
15:05 < ecrist> logs are available in /topic
15:06 < tempuser> i saw that. thanks.
15:06 < tempuser> i looked through them....and didnt see anyting about a hosting provider.
15:07 < ecrist> openvpn isn't looking for a hosting provider...
15:07 < tempuser> i own/admin a small hosting company and was prepared to offer hosting services for free if they were needed.
15:07 < tempuser> ok
15:07 < tempuser> what about mirrors?
15:08 < tempuser> or distributed (aka supersparrow) hosting?
15:08 < dazo> tempuser:  nope ... that's not on the schedule now
15:09 < tempuser> is it in bad taste to offer contact details in the event it becomes part of the project goals?
15:10 < ecrist> yes
15:10 < ecrist> but kudos for asking.
15:11 -!- freezer [n=freezer@sd-89-84.stud.uni-potsdam.de] has quit [Read error: 60 (Operation timed out)]
15:13 < tempuser> fair enough. good day all.
15:13 -!- tempuser [n=tempuser@72.22.215.114] has quit ["[BX] The Power Rangers use BitchX. Shouldn't you?"]
15:21 -!- freezer [n=freezer@sd-89-69.stud.uni-potsdam.de] has joined ##openvpn-discussion
15:31 -!- freezer [n=freezer@sd-89-69.stud.uni-potsdam.de] has quit [Remote closed the connection]
15:42 <+openvpn2009> we should not worry about hosting
15:42 <+openvpn2009> we have our own resources for that
15:45 < rob0> FWIW I wouldn't think it's in bad taste to offer free hosting. :)
15:46 -!- dazo is now known as dazo_afk
17:19 -!- ribasushi [n=rabbit@dslb-084-063-042-037.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
17:25 -!- ribasushi [n=rabbit@dslb-084-063-012-137.pools.arcor-ip.net] has joined ##openvpn-discussion
17:34 -!- ribasushi_ [n=rabbit@dslb-084-063-041-247.pools.arcor-ip.net] has joined ##openvpn-discussion
17:39 -!- ribasushi_ [n=rabbit@dslb-084-063-041-247.pools.arcor-ip.net] has quit [Read error: 60 (Operation timed out)]
17:42 -!- ribasushi [n=rabbit@dslb-084-063-012-137.pools.arcor-ip.net] has quit [Connection timed out]
19:07 -!- theDoc [n=hex@69.10.59.166] has joined ##openvpn-discussion
19:38 -!- ribasushi [n=rabbit@dslb-084-063-001-106.pools.arcor-ip.net] has joined ##openvpn-discussion
--- Day changed Tue Jan 12 2010
02:18 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: ribasushi, vpnHelper
02:20 -!- Netsplit over, joins: ribasushi, vpnHelper
02:50 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has joined ##openvpn-discussion
03:00 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has quit ["Verlassend"]
04:10 -!- theDoc [n=hex@unaffiliated/thedoc] has quit [Read error: 60 (Operation timed out)]
04:37 -!- dazo_afk is now known as dazo
07:12 -!- Irssi: ##openvpn-discussion: Total of 14 nicks [0 ops, 0 halfops, 2 voices, 12 normal]
07:46 -!- theDoc [n=hex@unaffiliated/thedoc] has joined ##openvpn-discussion
07:47 < theDoc> Good evening you guys.
07:50 < ecrist> Good morning, young lady.
07:51 < TCW__> good afternoon you two :)
08:12 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has joined ##openvpn-discussion
08:24 -!- mattock [n=samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
08:24 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
08:29 < rob0> Are there donuts or other goodies to be had before the meeting?
08:30 < Bushmills> ah, extreme programming paradigm.  "There must be food"
08:31 < Bushmills> no chairs, though.
08:31 < rob0> indeed, I like my own chair best
08:31 < dazo> Yeah, you just come and pick it up yourself here ... http://farm3.static.flickr.com/2161/2090408846_65f5c4efb1_o.jpg ;-)
08:31 < Bushmills> sitting makes one sleepy and unconcentrated. meeting while standing.
08:32 < dazo> standing meetings tends to be shorter too
08:32 <@mattock> standing also cuts down unnecessary talk
08:32 < Bushmills> where's the food
08:32 <@mattock> especially if leaning towards a wall is not allowed
08:33 <@mattock> bushmills, perhaps you can find it with google? :)
08:34 < Bushmills> google's crawler hasn't scanned the buffet of this meeting yet.
08:38 <@mattock> oh yes, it takes a while
08:38 <@mattock> silly me
08:42 < Bushmills> it may be in time to scan empty bowls
08:44 < Bushmills> but, really, google seems to be quick with links posted in freenode irc channels
08:44 < Bushmills> can't be really coincidence that very often shortly after posting a link on freenode, google visits and scans the site.
08:45 -!- ecrist changed the topic of ##openvpn-discussion to: Developer Forum TODAY 1900UTC || Logs at http://secure-computing.net/logs/%23%23openvpn-discussion.log (updated every 10 mins)
08:46 < reiffert> Ah, there it is, the long awaited forum!
08:47 < ecrist> I should make the openvpn pages on my site public so they get indexed.
08:49 < reiffert> oh please dont.
09:02 < ecrist> already did
09:18 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has quit ["Verlassend"]
09:37 -!- mattock [n=samuli@sparkgw.utu.fi] has quit ["Leaving."]
09:58 -!- Kasx [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
09:58 -!- mode/##openvpn-discussion [+v Kasx] by ChanServ
10:14 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 110 (Connection timed out)]
10:45 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
10:45 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
11:23 -!- fkr [i=fkr@news.bytemine.net] has quit [Read error: 60 (Operation timed out)]
11:25 -!- fkr [i=fkr@news.bytemine.net] has joined ##openvpn-discussion
11:34 <@mattock> I just updated a document outlining some aspects of the new development model: it's goals, how to achieve them and what is required for it all to work. It's available here: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html
11:34 < vpnHelper> Title: OpenVPN development (at users.utu.fi)
11:35 <@mattock> now I'll relax for a while before the meeting, see you then :)
11:42 -!- dazo changed the topic of ##openvpn-discussion to: Developer Forum TODAY 1900UTC || Meeting outline: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html || Logs at http://secure-computing.net/logs/%23%23openvpn-discussion.log (updated every 10 mins)
11:56 -!- Kaspx [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:56 -!- mode/##openvpn-discussion [+v Kaspx] by ChanServ
11:59 -!- notneb_ [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:59 -!- mode/##openvpn-discussion [+v notneb_] by ChanServ
12:02 < ecrist> Applicable todays meeting: http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
12:02 < vpnHelper> Title: Bazaar vs CVS vs Git vs Mercurial vs Subversion Version control systems comparison (at versioncontrolblog.com)
12:04 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 60 (Operation timed out)]
12:07 < reiffert> I think trac will bind us to svn.
12:10  * ecrist is a fan with sticking with svn, anyhow.
12:14 < dazo> http://whygitisbetterthanx.com/
12:14 < vpnHelper> Title: Why Git is Better Than X (at whygitisbetterthanx.com)
12:15 -!- Kasx [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 110 (Connection timed out)]
12:16 < ecrist> dazo, to be noted, that article is written by someone who works for github
12:16 < dazo> true ... but the fact is that is that it's quite neutral despite that, IMHO
12:17 < dazo> all facts there is possible to verify
12:17 < ecrist> I found it one-sided in some areas.
12:18 < rob0> Emacs!!
12:18 < ecrist> for example, under the 'distributed' heading, he highlights Git with 1m 59s, although SVN is at 1m 4s
12:18 < Bushmills> svn repositiories need somebody well versed with svn, or it gets messy.
12:19 < Bushmills> but i suppose the same could be true for git
12:19 < dazo> the versioncontrolblog.com comparison is very CVS centric ... and compares things which is not really that relevant to what is not too much relevant in regards to development tasks in general
12:19 < ecrist> and he refers to a 53% difference as 'marginal'
12:20 < dazo> yeah, that section has changed since last time I went through this .... that's really odd, I'll give you that one!
12:21 < rob0> Emacs makes it easy, listen, all you have to do is ^X ^M ^I ^C ^K ^E ^Y and then ^X ^M ^O ^U ^S ^E. Spend a few years in the info pages, you'll be as good as Stallman.
12:21 < dazo> git can be messy if you don't know what you do ... indeed, but you only mess up your local copy ....
12:22 < ecrist> I've spent the past 5 hours looking at VCSs and feel like a change isn't needed until a change is needed.
12:22 < dazo> svn is centralised, so if one person screws up .... it's screwed up for everyone
12:22 < ecrist> it can always be reverted
12:23 < dazo> ecrist:  agreed ... but if you want to introduce a better development model, with more reviewers, it gives a lot less pain doing it in a good distributed model than a centralised one
12:23 < dazo> ecrist:  in regards to reverts, yes, if you know how to do it .... but that counts for most vcs's
12:24 < dazo> reiffert:  and trac+git is working very well
12:28 < dazo> for those who want a comparison .... "svn co http://svn.apache.org/repos/asf/qpid/trunk"  and "git clone git://git.apache.org/qpid.git qpid"  .... then poke around the code, modify, try to do commands like {svn,git} {log,diff,status}
12:30 < dazo> svn also claims that branching is cheap .... only costing the resources file copies takes ... fine enough, but how much time do you spend merging it afterwards?  and git branch is the matter of fact writing about 40 bytes to a file
12:32 < dazo> (ftr ... git clone of qpid took 2m55s on my computer .... svn checkout which I started before git, is still running)
12:34 < reiffert> dazo: are you absolutly _sure_?
12:34 < reiffert> dazo: show me one project running trac on git please.
12:34 < dazo> http://projects.autonomy.net.au/python-dmidecode/
12:34 < vpnHelper> Title: Python-DM (at projects.autonomy.net.au)
12:35 < ecrist> doesn't seem to be working well...
12:35 < ribasushi> also don't forget that a git repo pretty much needs a merge-king
12:35 < dazo> funny ... I see the maintainer have some issues now :-P ... not sure what that could be
12:35 < ribasushi> otherwise things get messy even faster
12:35 < ribasushi> with svn you have a single point of truth
12:35 < ribasushi> look at linus - he pretty much has a full time job pulling this and pulling that
12:35 < dazo> ribasushi:  but merging is something I can do 20 times a day if I need to ... it's so fast I don't even consider it a bad thing
12:35 < ecrist> if asked, at this point, my vote would be to stick with svn
12:36 < ribasushi> dazo: merging is fast in any vcs
12:36 < dazo> ribasushi:  that is not true
12:36 < ribasushi> dazo: it's the brainpower that goes into a merge that counts
12:36 -!- theDoc [n=hex@unaffiliated/thedoc] has quit [Read error: 60 (Operation timed out)]
12:36 < ribasushi> dazo: that's fanboi-ism now
12:37 < ribasushi> in fact git encouraging branching (which comes with additional merging) is one of the downsides for me
12:37 < ribasushi> as it taxes the "janitor on duty" with unneeded upkeep
12:38 < dazo> why is branching a bad thing?
12:38 < dazo> ribasushi:  http://www.youtube.com/watch?v=4XpnKHJAok8
12:38 < vpnHelper> Title: YouTube - Tech Talk: Linus Torvalds on git (at www.youtube.com)
12:38 < ribasushi> dazo: I explained everything, stop throwing links at people and think about the arguments for a second
12:39 < dazo> ribasushi:  I do ... I'm using resources as parts of my arguments, instead of saying exactly the same myself ... and I'd like to hear why branching is a bad thing?
12:39 < ribasushi> you want to make it easy for the contributors, but you also don't want to create hell for the maintainer
12:40 < dazo> http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/
12:40 < vpnHelper> Title: Git vs SVN for bosses | Floorplanner Tech Blog (at techblog.floorplanner.com)
12:40 < ecrist> I would still say that there's no need for a change until there is a need for a change.
12:40 < dazo> ribasushi:  come on .... do you think the linux kernel would be able to handle about 1000 patches a day if that was a bad approach?
12:41 < ribasushi> all of the "branching sucks in svn" is a <= 1.5 mantra
12:41 < ribasushi> ecrist++
12:41 < ecrist> The first question that needs to be asked/answered, is what isn't SVN doing that OpenVPN needs it to do.
12:41 < ribasushi> ecrist: 1) doesn't appease fanbois :)
12:42 < ecrist> if there is nothing in that list other than on potential contributor prefers git, a change does not make sense.
12:44 < dazo> ecrist:  first of all ... with svn you will need to have a commit policy, some people need to have commit access.  With git, all that goes away.  The main maintainer has his circle of people where he knows where he can get good code.  He pulls those trees, merges and publishes his changes as the official tree .... several trees can exist in parallel, where different approaches are tried out on the outside of the main repository, an
12:44 < dazo> d what is good will easily be merged into the main tree when the code is ready for it
12:44 < dazo> that is a working model which centralised solutions is not good at
12:45 < dazo> you need to have branches, commit access is defined on all branches in SVN
12:45 < dazo> svn is not as flexible, it is that easy
12:45 < ecrist> dazo: commit access can be garnered with simple .htaccess files with DAV/SVN
12:46 < ecrist> it sounds like you're creating a problem where an actual problem has yet to be presented.
12:46 < ecrist> the infamous, 'what if'
12:47 < rob0> And I resent that, because that's MY role, to create problems!
12:47 < ecrist> lol
12:48 <@mattock> does everybody agree that if there are real problems with SVN then we should consider Git?
12:48 <@mattock> or some other distributed VCS
12:48 < ribasushi> mattock: we don't agree on "real"
12:48 < ribasushi> the rest is an obvious question :)
12:49 <@mattock> ribasushi: bad choicing of words... "if there will be"
12:49 <@mattock> or "if we encounter"
12:49 < ecrist> mattock: as I've already said, there's no need for a change until there's a need for a change.
12:49 < ecrist> if SVN is working, all it does to change is create more work.
12:49 <@mattock> ecrist: agreed
12:50 <@mattock> problems will find us, if they exist
12:50 < ecrist> only change once SVN doesn't do something that's needed.
12:50 < dazo> but no one seems to be interested in looking into what git saves compared against svn
12:51 -!- derRichard [n=derRicha@ununbium.nod.at] has joined ##openvpn-discussion
12:51 < dazo> for example not needing to have a svn server running .... a pure http server is enough
12:51 < dazo> which is less maintainance
12:51 < ecrist> dazo, you're only suggesting git because you like it.  I'm sure it does some things better, but if those features aren't needed, and won't be used, there's a net loss involved in changing.
12:52 < ecrist> dazo: where I work we use SVN, we have no svn process running, only apache with mod_dav
12:52 < ecrist> you don't need to use the daemon binary to use svn
12:53 < dazo> I have experience with git, svn, tla (similar to bzr) and cvs ... and I've used mercurival in one project .... and I'm advocating git, because that's most known ... but I'd put mercurval as number 2, bzr as 3 and svn as 4 ...
12:53 < dazo> ecrist:  and you don't even need mod_dav with git
12:53 < ecrist> who cares?
12:54 < ecrist> this conversation is moot until a notable lack of feature or function is apparent in svn
12:54 < dazo> inside an organisation, centralised vcs can work exceptionally well ... I have no problems understanding that ... but in the moment you start working with a community, that slows down
12:55 < dazo> speed is obviously not a feature
12:56 <@mattock> I don't personally like using or maintaining SVN, so I'd prefer something else (e.g. Git). But I agree with ecrist that we should check if SVN works well enough first.
12:56 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has joined ##openvpn-discussion
12:56 < dazo> there are even stories about organisations which uses git-svn to pull down svn repos, do the merging in git and push it back to svn ... because svn is much harder with such tasks, which really should be easy
12:57 <@mattock> but move to Git if it solves real problems
12:57 < dazo> I follow that one
12:57 <@mattock> but we don't really know the development model yet, so
12:57 < rob0> James is not here yet. When he gets here we can tell him what we've decided, and adjourn!
12:58  * ecrist is but a peon and doesn't make decisions.
12:59 <@mattock> rob0, sounds like a plan :)
12:59 <@mattock> rob0: what was our decision again? :)
12:59 <@mattock> to move to Git?
13:00 -!- jamesyonan [n=jamesyon@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
13:00 < jamesyonan> hi
13:00 <@mattock> hi james
13:01 <+Kaspx> Hey Guys!
13:01 <@mattock> jamesyonan, I created a plan on what _I_ think we (the company) are trying to achieve with the development model change and how. Could you take a look: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html
13:01 < vpnHelper> Title: OpenVPN development (at users.utu.fi)
13:04 <@mattock> I hope we manage to find an agreement how to improve the OpenVPN development model so that, in the long run, everybody (company and community) as well as the application benefits
13:05 < dazo> what about to set some expectations first?  if you guys (openvpn ppl) could put words on what you would like to gain from the community, and how the community could gain from you
13:06 < dazo> in your point of view
13:06 <@mattock> dazo, some of that is outlined in the document I linked to
13:06 <@mattock> most of it should benefit the community, too
13:06 < dazo> yeah, I'm just trying to formulate it as a question
13:07 < dazo> but *what* should benefit for the community ... in your POV
13:07 < ecrist> perhaps, 'Why are you here.' works?
13:07 < dazo> yeah :)
13:07 <@mattock> ecrist: well put
13:07 < jamesyonan> Agreed.  I think the important thing is to find a model that is both open, but also protects the integrity of the code, given that so many people rely on OpenVPN as being a mature, stable project
13:08 < ecrist> I've tried to get OpenVPN staff involved in the community for nearly two years, and only been met with hostility.  This is a sudden change.  I'm curious as to why the change, and what are you looking to gain from the community.
13:08 <@mattock> I guess James is the best person to answer that one
13:08 <@mattock> I haven't been onboard that long
13:09 < jamesyonan> Well I think it's a problem that has beset other open source projects.  The founder becomes the bottleneck.
13:09 < ecrist> I've never dealt with James that I recall, only Francis Dinha.
13:09 < reiffert> Seen this on macports as well.
13:09 <@mattock> this is my impression of the main problem
13:09 < reiffert> Kepts progress off nearly 2 years.
13:11 < dazo> so, it is some expectations that the community will help out bringing openvpn further, more rapidly but maintaining the code quality?
13:11 <@mattock> ecrist: I don't believe there's ever been intended hostility from the company's part.
13:11 < jamesyonan> Certainly I've never intended to be hostile.
13:12 <@mattock> dazo: more rapidly, yes, and without OpenVPN falling apart
13:12 <@mattock> I'd like to your thoughts about all this... what benefits would a more open model give you (the community)?
13:12 < dazo> mattock:  falling apart ... like loosing quality?  Hurting the OpenVPN company?  forks?
13:13 <@mattock> dazo: I mean code quality and such
13:13 -!- frankbob [n=frankbob@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:13 -!- mode/##openvpn-discussion [+v frankbob] by ChanServ
13:13 < dazo> oki
13:14 < jamesyonan> But I've had to balance a lot of competing priorities.  A lot of what I've been involved with during the last two years is bringing up OpenVPN Tech to the point where we have the resources to properly manage OpenVPN as a community project without myself being the bottleneck.
13:14 < dazo> jamesyonan:  how can then a community help you out?  in your eyes
13:15 < jamesyonan> A few things... Certainly testing beta releases is a critical role.
13:16 < reiffert> :)
13:16 < rob0> Well, I ran 2.1 betas a long time, but never had a problem to report :)
13:16 < jamesyonan> Contributing to the development is important as well, with several caveats.
13:16 < dazo> :)
13:17 < fkr> which caveats?
13:17 < fkr> (good evening,  btw)
13:18 -!- nneul [n=nneul@infinity.srv.mst.edu] has joined ##openvpn-discussion
13:18 < jamesyonan> I think the major caveat is that with a project of OpenVPN's maturity, code quality becomes critical, especially with respect to security.
13:19  * ecrist agrees
13:19 < fkr> of course, it is.
13:19 < jamesyonan> I've had people submit patches to me that contained security vulnerabilities.
13:20 < dazo> which means that you need people helping out reviewing new code, which follows certain coding standards
13:20 < fkr> thats why becoming part of an active development group is always a process that takes it's time (from my perspective)
13:20 < dazo> +1
13:21 <@mattock> I think having more people working on the code will in the long run increase code quality... of course at first there'll be problems, but if the problems are communicated and fixed, things start to change
13:21 <@mattock> I mean problems with the code
13:21 < reiffert> jamesyonan: having an unstable tree helps getting from a first approximation towards a stable and secure solution.
13:22 < fkr> ugh
13:22 <@mattock> agreed
13:22 < fkr> unstable, insecure code will not turn stable and secure. I highly doubt that. if crap hits a source tree, it is hard to get rid off
13:23 < dazo> yes, unless people reviewing code have knowledge to catch such issues during the review process
13:23 -!- mintaka [n=kosmic@unaffiliated/spice] has joined ##openvpn-discussion
13:23 < reiffert> ack
13:24 < dazo> jamesyonan:  are there any defined coding rules which you follow for the development of openvpn which would help out people reviewing the code?
13:24 <@mattock> a code preview (static whitebox testing if you will) should catch some problems off the bat... the rest will show up later during live testing (or in regression tests, if any)
13:24 < dazo> jamesyonan:  another question ... how often do you receive patches from users?
13:24 < jamesyonan> can we look to other security projects to gain insight on best policies?  For example, how does OpenSSL manage patch submission?
13:25 <@mattock> jamesyonan, I think that's worth checking
13:25 < dazo> yes
13:25 < ecrist> most projects I've worked with have patches submitted via the ticket system
13:26 < ecrist> they are reviewed and either declined or accepted into the tree with changes.
13:26 < fkr> bugzilla and tech@openbsd.org (for OpenSSH)
13:26 < ecrist> some changes are made by the reviewer, others are required to be made by the submitter before further review
13:27 <@mattock> in any case, I guess we want to, a) increase the quality of the code that is contributed, b) detect problems as soon as possible, c) communicate the problems (to increase the quality of the code)
13:27 < dazo> patches goes into a ticketting system or a mailing list, would be really beneficial
13:27 <@mattock> a ticketing system definitely helps... at least problems (and fixes) are not lost in space and time (like in the mailinglists)
13:28 < derRichard> i think a public (and maintained!) bug tracker is most important
13:28 -!- Olrick [n=Olrick@unaffiliated/olrick] has joined ##openvpn-discussion
13:29 < dazo> actually a bug tracker and patch tracking goes hand in hand
13:29 <@mattock> jamesyonan, would it help if others could preview (and pre-approve) the patches before they get to you? To save some of your resources... for example, communicate any obvious problems to the author
13:30 < reiffert> Why should everything still run through the bottleneck?
13:31 <@mattock> reiffert: good question?
13:31 <@mattock> oops, remove the question mark :)
13:32 < jamesyonan> Yes, that would make sense -- I think the basic questions to ask about a new submission are: (a) is the code quality up-to-par, and (b) is this something important to enough people that it's justified to merge into the mainline
13:32 < ecrist> the community, I think, would be a good 'firewall' on a ticket systems
13:32 < ecrist> s/s$//
13:33 <@mattock> ecrist: could you elaborate?
13:33 < reiffert> ecrist: the user community like we are, or a possible development community, like .. ?
13:34 < ecrist> I would say the current community (IRC/Forum) with rights within the ticket system to elevate
13:34 < ecrist> OpenVPN Tech could ignore anything below a certain level, or within a certain category.
13:35 <@mattock> ecrist: sounds good
13:35 < ecrist> the community mods would promote a vetted ticket to an area OpenVPN Tech would notice
13:35 < dazo> jamesyonan:  the Linux kernel tree operates with different source trees, where each tree has a focus area with its own sub-tree maintainer .... would such an approach be valuable here?  Where you could take already tested and code which has gone through a first "review filter"
13:35 < reiffert> Never mind, IRC/Forum is still a user community with no coding skills.
13:35 < fkr> reiffert: ack
13:36 < ecrist> reiffert: most tickets coming in to a ticket system are user-level.
13:36 < ecrist> no matter the title of the ticket system
13:36 < ecrist> "SUPER DUPER DEVELOPER ONLY TICKET SYSTEM"  -> Ticket 1: How do I install openvpn on Windows?
13:37 < reiffert> follow the guide, wontfix.
13:37 < dazo> ecrist:  the failure here ... you use the words "SUPER DUPER" ;-)
13:37 <+Kaspx> haha
13:37 < jamesyonan> Yes, I think having different source trees makes sense.  I would like to see feature-addition patches actually used in an experimental branch and vouched for as being stable and useful by multiple users before they are considered to be merged into the trunk.
13:38 <@mattock> jamesyonan, I agree... I originally envisioned separate feature testing trees to speed up inclusion of new features... in the linux kernel style as dazo suggested. I'm not sure if that makes sense, but it's one possibility
13:40 <@mattock> jamesyonan, how does code end up in the "stable" branch currently? Do we have an experimental/unstable branch?
13:40 < reiffert> Where are all the billion of kernel coders that actually invent progress? It will end up in having 24 experimentell branches, no feedback and still no progress.
13:41 < jamesyonan> Leading up to 2.1, we had a "BETA21" branch where all the development was occurring.
13:41 < dazo> another issue here, is to have some good ways of getting feedback back from users of new features ... so that it can be documented that a particular feature is used and needed
13:41 < jamesyonan> That has since been promoted to 2.1 final.
13:41 < reiffert> jamesyonan: lemme recall how long it took getting from 2.0 stable to 2.1..
13:42 <@mattock> reiffert: that's definitely a problem if people are not using the experimental branches and/or not providing feedback
13:42 < reiffert> or .. how many fixed have there been, fixing two lines of code, coming right one day after the last release?
13:42 < jamesyonan> Well if you look at the change log, there were hundreds of bugs that were fixed.
13:42 < reiffert> s,fixed,fixes,
13:42 < dazo> I also think one problem in this period was that the community knew nothing about why it took so long time .... what the issues were which kept stalling it
13:43 < jamesyonan> The problem with bug fixes is that there's a long latency.
13:43 < jamesyonan> You put a fix out there, and if it breaks something, you might not hear about it for weeks.
13:44 < dazo> how can this be solved more efficiently?
13:44 <@mattock> jamesyonan, wouldn't it help if we had daily snapshots in a repository (e.g. Debian experimental)?
13:44 <@mattock> I guess it's too big hassle to always keep the OpenVPN installation updated
13:45 <@mattock> so few people do it, even if they are motivated to help the project
13:45 < dazo> mattock:  Not sure how quick you would get changes into repos .... for Fedora, that takes 2-3 days at best .... Debian has a similar thing with their repos
13:45 < reiffert> releasing stable versions will put them into linux distros, reaching tons of users...
13:45 <@mattock> dazo: we could have our own repo... for those who want to help. And I'm sure there are a few of those, if given the means
13:46 < dazo> I believe most people who want to do such help are able to grab the source code and compile it .... but nightly tarballs can make it easier for some
13:46 < ecrist> sorry, stepped away
13:48 < ecrist> building a freebsd package is easy enough
13:48 <@mattock> dazo: it's not so much if they can, but if they will... a longer process (svn co;./configure;make;make install...) is worse than a shorter process (automated Debian install)
13:48 < jamesyonan> The latency between fixing bugs and getting feedback on a new beta release is really key to accelerating the release process
13:48 < cron2> I think part of that is having focussed betas with shorter cycles.  As in "only 3 things have changed here"
13:48 < dazo> but I think then one of the issues here is that the community don't know which bugs you need to fix ...
13:48 <@mattock> so we need to get new code to run on people's computer as soon as possible
13:48 < ecrist> jamesyonan: given some communication paths, we would likely be successful pushing beta testing in IRC and on the forums
13:49 < cron2> has "automated testing" been discussed already?  (I've just joined, and not read up on the backlog)
13:49 < dazo> cron2:  nope, not yet
13:49 <@mattock> cron2: frequent releases are a good idea... most people won't install "non-stable" software, even if it is rock solid. Or that's my experience
13:49  * cron2 claims "automated testing would help"
13:50 <@mattock> cron2: agreed
13:50 < dazo> mattock:  exactly .... because
13:50 < reiffert> mhm, finding missing libraries, but what else?
13:50 < dazo> nobody want's to compromise VPN security
13:50 < jamesyonan> automated testing would be great, but how much effort would it take to develop it?
13:51 <@mattock> reiffert: regression tests come to mind
13:51 < derRichard> jamesyonan: we could use usermodelinux like strongswan does.
13:51 < cron2> it really depends on the extent you want to go
13:51 < dazo> jamesyonan:  automated testing is not difficult itself ... what is more difficult is to have defined what needs to be tested and how
13:51 < jamesyonan> Re: automated testing, one resource we already have is Coverity's compile-time checker
13:51 < cron2> there's "make check" style testing, running locally on a given platform (which is already there to some extent)
13:51 < cron2> and then there's "build farm testing", fanning out source to 20 different operating systems, all running interop tests - now *that* is tough...
13:51 < dazo> and Fedora's build does even more during build
13:52 < nneul> joining in late - is there some clear information on what the plan is as far as existing developers? i.e. is the community development effort going to be completely separate, or overlapping developers with the commercial product?
13:52 <@mattock> I think quite a few aspects of OpenVPN's operation could have automated (regression) tests, but building them takes time... and if we have tons of automated tests, they break when significant changes are made to how the application functions -> tests need fixing
13:53 < dazo> But such testing could maybe even be done in cooperation with f.ex Linux distributors as well .... Fedora/RHEL have their infrastructure, I bet Debian, Novell/openSuSE, Gentoo, etc also have similar setups
13:53 < nneul> current issue is that there doesn't appear to be any clear way to get information to/from active developers who know the internal details of the product - I was trying to submit an improvement, but no way to do it reasonably without getting some more information from someone who is familiar with the detailed internal implementation
13:53 < cron2> mattock: yes, it needs some effort.  But then you can do more dramatic code changes with the good feeling "if the tests all still work, I have not broken anything user-visible"
13:54 <@mattock> do we all agree that new code needs to get "out there" a.s.a.p.?
13:54 < cron2> +1
13:55 <@mattock> cron2: true
13:55 < jamesyonan> I've found from experience, that more people will test the release if the release cycles are less frequent
13:55 < dazo> I feel we are starting a bit skewed out now .... because we want code out .... but which code?  the community knows *nothing* about the further plans for OpenVPN, the direction jamesyonan would like to see openvpn go
13:55 < jamesyonan> that's just a caveat against what generally seems like a good idea, i.e. to release early and often
13:56 < dazo> we are missing info about which bugs that exists, which issues are being solved .... and which issues are on the task list
13:56 < cron2> jamesyonan: yes, that's true for manual testing - people lose interest if they have to test once a week.  OTOH, if the incremental changes are smaller, we might not need so many testers per release
13:56 < dazo> just by being more open here, you can also get more people helping out writing that code
13:56 < cron2> dazo: ack
13:57 <@mattock> cron2: I agree we don't need as many testers when there are only a few changes
13:57 < jamesyonan> I see OpenVPN 2.1 as being mature code that's suitable for incremental improvements.
13:58 < jamesyonan> I have some ideas for OpenVPN 3 that would involve redeveloping OpenVPN as a general purpose user-space network stack
13:59 < cron2> I agree with 2.1 being a good platform to go ahead
13:59 < derRichard> jamesyonan: btw: are there any plans to develop a openvpn client for smartphones? (iphone and such crap..)
14:00 < dazo> derRichard:  that's where the community comes in ;-)
14:00 < jamesyonan> yes, certainly the community can take the initiative on this
14:00 < derRichard> i don't think so.
14:00 <@mattock> derRichard: why is that?
14:00 < jamesyonan> OpenVPN Tech is also developing a new client for the Access Server and at some point when the code matures a bit, we plan to open source it
14:01 < derRichard> writing a vpn tool for the iphone is not that easy. a iphone app runs in a jail. we need apple to get access to a real network-device...
14:01 < dazo> jamesyonan:  do you have any reason why not open source it immediately?  And get more people looking at it sooner?
14:01 < jamesyonan> Well the community has ported OpenVPN to other client platforms, such as Windows Mobile
14:01 < derRichard> is this port stable?
14:02 < Schlaubi> some guys asked me for symbian clients
14:02 <@mattock> jamesyonan, why does the AS client have to mature before open sourcing it?
14:02 < derRichard> Schlaubi: that would be great :=)
14:03 < cron2> how are the AS server/client and OpenVPN related?  I thought that this is basically the same thing, with commercial coating or open source?
14:03 < jamesyonan> dazo: right now at OpenVPN Tech our plate is pretty much full.  We don't have the resources yet to put into the extra work that would be required to maintain the AS client as an open source project today.
14:03 < cron2> (so "why a new client?")
14:03  * cron2 is not criticizing anything, just trying to understand
14:04 < dazo> jamesyonan:  this is probably where I fall off ... because if the source is available, and let people test it and contribute code ... sharing a development plan, a roadmap and documentation, I would expect you could get more help getting things done
14:04 < fkr> actually, there are people working on an iphone client, but the tough one is to access routing table and such, which is something that will not be possible on not-jailbroken iPhones (just to sum that up)
14:05 < dazo> without spending more resources on managing it
14:05 < jamesyonan> This is mostly a commercial issue with the Access Server product -- and that's that people want a client that is (a) uniform across all platforms, and (b) has most of the configuration performed on the server side, where there's not so much functionality exposed on the client itself other than connect, disconnect.
14:05 < cron2> I see, thanks
14:06 < jamesyonan> The existing open source OpenVPN clients tend to be more full-featured.  Commercial customers on the other hand don't really want to give a full-featured client to their users.
14:06 < ecrist> jamesyonan: if it hasn't been passed to you yet, http://www.ovpnforum.com/viewforum.php?f=10
14:06 < vpnHelper> Title: OpenVPN Forum View forum - Wishlist (at www.ovpnforum.com)
14:07 < reiffert> how about starting with proper error messages?
14:07 <@mattock> dazo: I agree...  working openly would probably be beneficial with the AS client, too... I think the main issue is how to work openly _and_ effectively
14:08 < dazo> jamesyonan:  I would really applaud splitting the server and the client into to different applications, which I think I understand this as the first step .... as the code should be able to become simpler
14:09 < cron2> dazo: I'm not sure I agree with that.  Large parts of the seriously nasty stuff (system dependent, ifconfig, route, ...) would need to be shared anyway
14:09 < jamesyonan> Originally, OpenVPN was developed for site-to-site rather than client-server, hence the integration of both client and server in the same codebase
14:10  * dazo remember those days :)
14:11 < jamesyonan> To be honest, I think if there's something in OpenVPN that I consider difficult to maintain, it would be the event loop implementation.
14:11 <@mattock> jamesyonan, does OpenVPN have any easy extension point? For things like plugins... I know there are authentication modules and such...
14:12 < dazo> jamesyonan:  amen! ... I get easily lost in that code, I haven't really figured out how things work in there yet
14:12 < dazo> But .... how can we now get further ..... who will do what now for the next steps to follow?  How can the community be involved?
14:12 < jamesyonan> Yes, there are two extension layers:  (a) the management interface, and (b) the plugin model.
14:12 <@mattock> jamesyonan, ok
14:12 < dazo> the frustration which can be found in the community is that we really don't know whats going on .... the main reason there is a community is probably that the source code is avalable
14:13 <@mattock> dazo: so we need to communicate what we (the company) are doing much better, right?
14:13 < jamesyonan> The management interface is fairly well documented.
14:13 -!- notneb_ [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has left ##openvpn-discussion []
14:14 < dazo> mattock:  yes, that would really be a good first step ... with feature plans, milestones, release plans
14:14 <@mattock> in fact, I think good communication is the key...
14:14 < cron2> mattock: the community needs a way to feed input to you, and have some visible recognition
14:14 <@mattock> to successful co-operation
14:14 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
14:14 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
14:14 <@mattock> cron2: agreed
14:14 < dazo> cron2:  yes!
14:14 < cron2> as in "this is the process to get new code into openvpn" and "that is the process to report and track bugs"
14:15 < dazo> and that those reports and patches are publicly available for everyone
14:15 <@mattock> so we need to have clearly defined (and documented) processes
14:15 < cron2> mattock: yes!
14:15 < dazo> ack!
14:15 <@mattock> and most importantly we need to follow those processes :)
14:15 < dazo> jamesyonan:  are there more people than you doing the development in OpenVPN Tech?
14:16  * dazo gives mattock a bonus point for that comment
14:16 <@mattock> dazo: thanks :)
14:16 <@mattock> jamesyonan, do we have documented processes on "how to contribute" and such?
14:17 < jamesyonan> Yes, we have a few people doing development, though we are still very much a startup with the usual resource issues that startups have.
14:18 <@mattock> I think we should next define and document our development processes
14:18 <@mattock> and start following them
14:18 <@mattock> see how they work, adjusting as necessary
14:20 <@mattock> I also think we agreed that frequent releases and automated tests would be beneficial (code quality, inclusion of new features)... right?
14:20 < cron2> yes
14:21 < jamesyonan> make sense
14:21 <@mattock> and possibly have either an "unstable" tree, or separate "feature under test" trees _if_ people provide enough feedback
14:21 < jamesyonan> makes sense :)
14:22 <@mattock> could we begin the big reformation with these?
14:23 < jamesyonan> agree
14:23 < cron2> +1
14:23 < ecrist> +1
14:23 < dazo> +1 ... but can we set some deadlines on when things are supposed to be "ready"?
14:24 <@mattock> dazo: I can't see any reason why not
14:24 < ecrist> and a path, what's coming first, second, so on?
14:25 < rob0> Who's on first. What's on second.
14:25 <@mattock> ecrist: agreed, a good idea
14:25 -!- Olrick [n=Olrick@unaffiliated/olrick] has left ##openvpn-discussion []
14:25 <@mattock> dazo: what kind of deadlines are you thinking about?
14:25 <@mattock> I mean,when? :)
14:26 <@mattock> I think each of these issues should be discussed on the "devel" mailinglist
14:26 < dazo> well, I'm willing to give OpenVPN Tech the time which you need ... but not too long .... but if the documentation can be done within 8-10 days, that would be a good thing
14:27 <@mattock> dazo: I think I can write a draft of the core processes tomorrow, but I need help with finalizing it
14:27 < dazo> there are some things which might take longer time, and that's fair enough ... but OpenVPN Tech need to communicate some deadlines first
14:27 <@mattock> dazo: some of this is tied to  building of the community site, which might take a while (2 months?)
14:27 < dazo> mattock:  count on me, if you need help .... I can hang out here for those discussions
14:27 <@mattock> dazo: thanks!
14:27 < dazo> mattock:  exactly
14:28 < ecrist> this channel will be persistent
14:28 <@mattock> ecrist: did you set up this channel? If so, thanks!
14:28 <@mattock> wouldn't know what to do without the trusty vpnHelper :)
14:28 < ecrist> np
14:29 < ecrist> another bot, in addition/replacing vpnHelper at some point. vpnHelper does RSS feeds, but not well.
14:29 <@mattock> the automated testing thingy might be tricky, might take some time
14:30 <@mattock> as well the automated package building and repository setup (e.g. daily snapshots for Debian/Fedora/whatever)
14:30 < cron2> this is a long process :)
14:30 <@mattock> cron2: I'm sure we get there eventually :)
14:30 < dazo> mattock:  automated testing would actually be an own meeting, for brainstorming .... but as I said earlier, the core issue here is to first define and document what needs to be tested - automation is done by a script, basically
14:31 <@mattock> dazo: agreed
14:31 <@mattock> do you all think we're soon done for today? I think we now have a plan we can start elaborating
14:31 < reiffert> what do you think of creating a permanent #openvpn-devel channel? Samba runs one too.
14:32 <@mattock> reiffert: I think that'd be a good idea, #openvpn seems to have too many users (and usage-oriented questions)
14:32 <+Kaspx> I think that would be a good idea as well.
14:32 < cron2> reiffert: yes, sounds good
14:32 <@mattock> perhaps it could replace this one?
14:33 < Schlaubi> and a monthly /all 2 month meeting?
14:33 < dazo> that can work out .... if some hard core openvpn developers are also present there regularly
14:33 < reiffert> And I really like this discussion, can't we have one every week?
14:33 < dazo> if not ... it makes not so much sense
14:33 <@mattock> reiffert: I agree, we had weekly meetings in Adito/OpenVPN ALS and they were very useful
14:33 <+Kaspx> reiffert: At this time, I think that would be a great idea.
14:34 <@mattock> jamesyonan, what do you think about a weekly meeting? I think one hour should be enough if the meeting are frequent
14:34 < reiffert> jamesyonan: what are your current plans for the next week, can we expect getting trac on its feets?
14:35 < jamesyonan> Yes, I could do a weekly meeting.
14:36 <@mattock> reiffert: I don't think it'd be wise to just "spit" a Trac instance somewhere :)... I hope you understand, I have sysadmin background :). Also, one week is not that much
14:36 <@mattock> I think 1-2 months is more reasonable
14:36  * dazo agrees
14:36 <+Kaspx> mattock: I agree, this will take some time to do it right
14:36 < reiffert> mattock: I'm a system engineer, thanks.
14:37 <@mattock> reiffert: ok, point taken
14:37 -!- nneul [n=nneul@infinity.srv.mst.edu] has quit ["Leaving"]
14:37 < dazo> Having an open communication first, which states those milestones and deadlines will anyway be a big step forward, compared to where we stand today
14:38 <@mattock> the community site needs to be built fast and alongside these development... currently it's pretty difficult to put anything on our web pages... so I'm drooling for a wiki
14:40 < dazo> mattock:  will we have a discussion during tomorrow then about core processes?  and can we also manage to have a milestone overview, which includes all those things we've been discussing here?
14:41 <@mattock> dazo: yes, let's talk about that tomorrow... and we should outline our current plans and decisions too, and write them down somewhere
14:41 < dazo> mattock:  when can we see those plans?
14:41 -!- frankbob [n=frankbob@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit []
14:41  * dazo needs some hard facts :)
14:42 < ecrist> there are currently 3 IRC channels configured: ##openvpn, ##openvpn-discussion, and #openvpn-devel
14:42 <@mattock> dazo: I mean the plans we (here in IRC) have outlined yesterday and tomorrow... hopefully by early next week
14:42 < ecrist> fwiw
14:42 <@mattock> processes tomorrow, though
14:42 < dazo> mattock:  thx!  I can live with that now
14:43 <@mattock> dazo: I see you like to see some action, that's good :)
14:43 <@mattock> talk is not enough, eh ;)
14:43 < dazo> mattock:  I am a firm believer in deadlines and todo lists ;-)
14:44 < dazo> (in that order! :-P)
14:44 < dazo> I need to run now
14:44 <@mattock> one more thing... should we keep the (important) discussions on the devel mailinglist or in the IRC? I think timezones are a problem if we use IRC.
14:45 < fkr> mailinglists
14:45 < fkr> imho
14:45 < cron2> a focused discussion every now and then on IRC is good, but in general I prefer the list - it's easier to schedule
14:45 < fkr> since that allows even weird timezones to participate
14:45  * derRichard votes for mailinglists too
14:45 <@mattock> I agree mailinglists are best
14:45 < dazo> mattock:  mailinglist primarily .... but discussions can take many days then .... but to have supportive irc meetings in addition can help on the progress
14:46 <@mattock> dazo: sounds like a good compromise
14:46  * dazo need to run
14:46 <@mattock> I think it's pretty clear how we'll proceed from here - the work continues tomorrow
14:46 <@mattock> agreed, everyone?
14:46 < dazo> mattock:  catch you tomorrow then!
14:46 < ecrist> I think an IRC presence is ideal backup to mailing lists
14:47 <@mattock> dazo: bye! see you!
14:47 < dazo> mattock:  ack
14:47 < jamesyonan> take care everyone
14:47 <@mattock> bye james!
14:47 -!- jamesyonan [n=jamesyon@c-76-120-71-74.hsd1.co.comcast.net] has left ##openvpn-discussion []
14:49 -!- dazo is now known as dazo_afk
14:50 <@mattock> ecrist: is it possible to "tag" the IRC chatlogs somehow... e.g. "this was the meeting for week 2 in 2010"
14:50 < ecrist> mattock: I can manually do so sometime tonight and make them available
14:50 < ecrist> the logs in their current form is just from my IRC client
14:50 <@mattock> it'd be nice to have each meetings chatlog as a separate file/page
14:50 <@mattock> oh, the old-fashioned way I use, too :)
14:51 <@mattock> thanks guys, it's been great to talk to you! I gotta go now, it getting later (even more so than yesterday)
14:51 <@mattock> bye!
14:52 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit ["Leaving."]
14:58 -!- Irssi: ##openvpn-discussion: Total of 17 nicks [1 ops, 0 halfops, 1 voices, 15 normal]
15:24 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has quit ["Verlassend"]
15:31 < ribasushi> hm hm
15:31 < ribasushi> so how do I get a response to my bugreport now? :D
15:38 -!- TCW__ [i=mschmitt@booster.qnetp.net] has quit [Remote closed the connection]
15:51 -!- rob0 [n=rob0@tuxaloosa.org] has left ##openvpn-discussion ["bye"]
16:38 < reiffert> ribasushi: 1-2 Months.
16:39 -!- reiffert [n=thomas@mail.webersheim.de] has left ##openvpn-discussion []
17:08 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: berniv6, cron2
17:09 -!- Netsplit over, joins: cron2
17:10 -!- Netsplit over, joins: berniv6
18:21 -!- derRichard [n=derRicha@ununbium.nod.at] has left ##openvpn-discussion []
18:54 -!- theDoc [n=hex@unaffiliated/thedoc] has joined ##openvpn-discussion
19:02 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit ["ircN 8.00 for mIRC (20080809) - www.ircN.org"]
21:27 -!- Irssi: ##openvpn-discussion: Total of 12 nicks [0 ops, 0 halfops, 1 voices, 11 normal]
21:28 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has quit ["Ctrl-C at console."]
21:29 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has joined ##openvpn-discussion
--- Day changed Wed Jan 13 2010
01:49 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:49 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
02:07 -!- ribasushi [n=rabbit@dslb-084-063-001-106.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
02:07 -!- ribasushi [n=rabbit@dslb-084-063-050-203.pools.arcor-ip.net] has joined ##openvpn-discussion
02:30 -!- ribasushi_ [n=rabbit@dslb-084-063-038-130.pools.arcor-ip.net] has joined ##openvpn-discussion
02:45 -!- ribasushi [n=rabbit@dslb-084-063-050-203.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
03:40 -!- dazo_afk is now known as dazo
04:08 <@mattock> hi guys, anybody present?
04:08 < dazo> I'm here :)
04:08 <@mattock> great!
04:08 <@mattock> could you proofread my meeting summaries (community site and development model). I used wording such as "Agreed" and "Decided"... I'd like to know if we reached a consensus
04:09 <@mattock> I'll upload the files to my webpage
04:09 < dazo> mattock:  sure!
04:10 <@mattock> http://users.utu.fi/sjsepp/openvpn/openvpn_irc_meeting_2010-01-11.txt
04:10 <@mattock> http://users.utu.fi/sjsepp/openvpn/openvpn_irc_meeting_2010-01-12.txt
04:10 <@mattock> while you proofread, I'll start working on the core processes now
04:14 < dazo> mattock:  "Also there needs to ways for the community to ... " ... I believe it should be "Also there need to be ways for the community to ..." (4th paragraph, 2nd sentence)
04:14 <@mattock> dazo: fixed
04:16 -!- mintaka is now known as pimpatine
04:16 < dazo> they look good to me, it catches the important consensus which was discussed
04:18 <@mattock> ok, great!
04:18 <@mattock> thanks
04:24 -!- theDoc [n=hex@unaffiliated/thedoc] has quit [Read error: 110 (Connection timed out)]
04:26 <@mattock> sudden change change in plans, need to go to lunch now... be back in ~1 hour
04:30 < dazo> mattock:  no prob ... I'll be here quite some hours today :)
05:28 -!- ribasushi_ [n=rabbit@dslb-084-063-038-130.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
05:28 -!- ribasushi_ [n=rabbit@dslb-084-063-044-135.pools.arcor-ip.net] has joined ##openvpn-discussion
06:27 -!- d12fk [n=heiko@vpn.astaro.de] has quit [Remote closed the connection]
06:36 -!- d12fk [n=heiko@vpn.astaro.de] has joined ##openvpn-discussion
06:48 <@mattock> I draw a swimlane process diagram displaying a slightly modified "Contributing to OpenVPN" process. In that process James is still the only one with write access to the source repository. It's basically an enhanced version of the current process. Anyway, it's here: http://users.utu.fi/sjsepp/openvpn/process_contributing_to_openvpn.png
06:49 <@mattock> replace .png with .dia to get a Dia-file
06:50 < dazo> mattock:  that one looks very good .... and this has the distributed model behind it
06:50 < dazo> mattock:  but you want primarily patches to hit the -devel mailing list?   Or do you want it via a patch tracker?
06:51 < dazo> mattock:  I'd recommend only one of these .... both has pros and contras ....
06:54 <@mattock> dazo: perhaps we could start with this one and move to a patch tracker when we have one?
06:55 <@mattock> perhaps I draw a few other suggestions and send the links to the mailinglist
06:55 < dazo> mattock:  yeah ... I personally like patch tracking via email more, tbh .... but if the mailinglist sucks and rejects mails, it's not good
06:56 <@mattock> with mailinglists somebody has to reach to the patch at once, or it will probably be forgotten
06:56 <@mattock> the alternative is to bury the patches to a patch tracker :)
06:57 < dazo> mattock:  true, but without anyone fetching patches and putting them into a source tree
06:57 <@mattock> dazo: true
06:58 <@mattock> I think I'll draft a process where James is no longer the bottleneck (like in this one)
06:58 < dazo> if someone are grabbing them and putting them into a source tree which finally reaches James, it's no problem ..... I just think the review process is easier on mail, than via a patch tracker
06:58 <@mattock> dazo: agreed, less clicking
06:59  * dazo is thinking aloud
07:00 < dazo> if patches hits a mailing list which is followed by a "daemon" .... and then registers the patch in a database as well, that way, you'll have a double tracking ... and when included, it can be "tagged" as included and referenced against a commit
07:00 < dazo> and the discussion can flow on the mailing list
07:01 < dazo> likewise, a patch can be sent to a web page ... and a mail to -devel ML is sent, with the patch as well
07:01 < dazo> but in such a setup, it's important to isolate the discussion to one place .... where I'd prefer the ML
07:01 <@mattock> dazo: that sounds nice, unless it's terribly complex to implement
07:02 < dazo> mattock:  I have a script which grabs patches from an IMAP mail account .... similar approaches can be done against NNTP servers (like openvpn-devel on gmane.org's nntp server)
07:03 <@mattock> if the patches are reviewed and merged by someone, do we need a patch tracker at all? Besides being able to attach patches to bug reports?
07:03 <@mattock> I mean, if patches are not simply ignored (in the mailinglists)
07:05 <@mattock> ... got to go, will be back in the evening (hopefully)
07:06 < dazo> It's more to have an simple web page for people to see which patches are queued up, and which are implemented and merged into mainstream
07:08 < dazo> this update page could then also send the needed messages back to the contributor automatically, helping out the developers who prepares a "next tree" for James
07:09 < dazo> anyhow, I'm just thinking aloud .... on how to make the process more efficient
07:14 -!- ecrist changed the topic of ##openvpn-discussion to: OpenVPN Discussion Channel || No Meetings Currently Scheduled
07:19 -!- Irssi: ##openvpn-discussion: Total of 12 nicks [1 ops, 0 halfops, 1 voices, 10 normal]
07:25 -!- ribasushi_ is now known as ribasushi
07:37 < ribasushi> what about the folks who can not submit a patch?
07:38 < ribasushi> i.e. all I know that --multihome broke between rc19 and rc20 (breakage persists through last versions)
07:39 < dazo> then I'd say that should be tracked as a bug, if it is a bug ... or be discussed on a ML, and then someone comes up with a patch, shares the patch .... and it gets included
07:39 < dazo> if it is clearly a bug, like what you said (--multihome broke between rc19 and rc20), that's a clear candidate for a bug tracker
07:40 < dazo> but I think it would be beneficial to have discussions of bugs also going on a mailing list as well, as it's own thread
07:46 < ribasushi> dazo: I did that
07:46 < ribasushi> sent an email to both -user and -dev
07:46 < ribasushi> been about 3 weeks
07:46 < ribasushi> not a single response yet
07:47 < ribasushi> frustration ensuing :)
07:48 < ribasushi> as far as wether it is a bug - downgrading/upgrading between 19/20 make sthe problem appear/disappear
07:48 < ribasushi> without changing anything else
07:48 < ribasushi> so I'm pretty sure it did regress
07:49 < ecrist> JIRA or bugtrack or something similar needs to be implemented.
07:51 < dazo> yes, bugtracker needs to come in place .... but discussions would be beneficial on ML, IMHO
07:52 < dazo> also in regards to bugs
07:53 < ecrist> conversation is almost always a good idea.  The bug tracker is a starting point, and can be used to create a thread by auto-submitting a message to the mailing list when it's created.
07:53 < ecrist> easier to track that way
07:53 < dazo> agreed!  That's a good approach
07:55 < ecrist> if we used JIRA, a message such as: 'JIRA Created: (category-XX) my shit is broke, yo' would come across the list
07:55 < ecrist> help to maintain a consistent thread
07:56 < dazo> ribasushi:  you really have a clear indication of a regression .... unless the developers mean that the former behaviour was incorrect ... but I'd say you have spotted something
07:56 < ecrist> when a comment is made, or ticket is  closed, it keeps the first portion intact, and searchable: 'JIRA Closed: (category-XX) ...'
07:56 < ecrist> fwiw, bug discussions, at this point, should be discussed in ##openvpn, not here.
07:57 < dazo> ecrist:  I believe most trackers support that .... I'm having that in Bugzilla at work, and the same for a Trac bugtracker for python-dmidecode as well
07:57 < ecrist> i was just using jira as an example
07:58 < ribasushi> by the way as far as bug-testing
07:58 < ribasushi> if you work closer with the distro maintainers
07:58 < ribasushi> you'll get broader exposure
07:58 < dazo> yup!
07:59 < ribasushi> (e.g. I do not compile anything, whatever comes from debian sid is what I use)
07:59 < ribasushi> for debian the maintainer is 'agi' (he is online right now)
07:59 < dazo> ribasushi:  Alberto Gonzalez Iniesta?
08:00 < ribasushi> dazo: yup
08:00 < ribasushi> dazo: he provided me with earlier .deb packages to pinpoint where the regression occured
08:01 < dazo> Nice!  I'm not sure how much testing he does, expect some smoke testing .... I'd expect (hope?) Debian does a more heavy testing on all changed packages before next releases
08:01 < dazo> s/expect/except/
08:01 < ribasushi> well, it is hard to test multihoming without a multihoming host
08:01 < ribasushi> so I can see why nobody ever complained about it
08:03 < dazo> yeah ... that's one big thingy with openvpn which is difficult to tackle .... it's so flexible, and can do so much pretty easy ... but you have an pretty long list of unique combinations which a lot of users depends on
08:03 < dazo> testing all features and combinations of them, is not a small task
08:08 -!- theDoc [n=hex@unaffiliated/thedoc] has joined ##openvpn-discussion
09:10 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit [Read error: 60 (Operation timed out)]
10:08 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
10:09 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
10:10 < dazo> Kas == Kaspx?
10:10 <+Kas> Yes sir
10:10 < dazo> interesting
10:10 < dazo> :)
10:11  * dazo was just curious
10:12 -!- Kaspx [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 60 (Operation timed out)]
10:25 -!- Bushmills [n=nnnBushm@verhau.de] has left ##openvpn-discussion ["Leaving."]
12:37 -!- theDoc [n=hex@unaffiliated/thedoc] has quit [Read error: 60 (Operation timed out)]
13:09 -!- reiffert [n=thomas@mail.webersheim.de] has joined ##openvpn-discussion
13:22 -!- dazo is now known as dazo_afk
13:50 -!- reiffert [n=thomas@mail.webersheim.de] has left ##openvpn-discussion []
16:46 -!- Irssi: ##openvpn-discussion: Total of 10 nicks [0 ops, 0 halfops, 1 voices, 9 normal]
17:12 -!- pimpatine is now known as mintaka
--- Day changed Thu Jan 14 2010
07:11 -!- dazo_afk is now known as dazo
12:15 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
12:15 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
14:44 -!- Irssi: ##openvpn-discussion: Total of 11 nicks [1 ops, 0 halfops, 1 voices, 9 normal]
15:28 -!- dazo is now known as dazo_afk
--- Day changed Fri Jan 15 2010
02:10 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: d12fk, dazo_afk, mintaka, +Kas
02:10 -!- Netsplit over, joins: d12fk
02:11 -!- Netsplit over, joins: +Kas, mintaka, dazo_afk
02:14 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: cron2
02:15 -!- cron2 [n=gert@blue.greenie.muc.de] has joined ##openvpn-discussion
03:06 -!- dazo_afk is now known as dazo
05:15 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:15 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
07:13 -!- ribasushi [n=rabbit@dslb-084-063-044-135.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
07:14 -!- ribasushi [n=rabbit@dslb-084-063-002-197.pools.arcor-ip.net] has joined ##openvpn-discussion
07:41 -!- dazo [n=dazo@nat/redhat/x-hjlzmengnirgaqjc] has quit [Read error: 54 (Connection reset by peer)]
07:44 -!- dazo [n=dazo@nat/redhat/x-lshoztazovndqxix] has joined ##openvpn-discussion
07:44 -!- dazo is now known as Guest60666
07:45 -!- Guest60666 is now known as dazo
07:58 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit [Remote closed the connection]
10:04 -!- d12fk [n=heiko@vpn.astaro.de] has quit [Read error: 60 (Operation timed out)]
10:04 -!- d12fk [n=heiko@vpn.astaro.de] has joined ##openvpn-discussion
10:08 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 60 (Operation timed out)]
12:01 -!- ribasushi [n=rabbit@dslb-084-063-002-197.pools.arcor-ip.net] has left ##openvpn-discussion ["Leaving"]
12:55 -!- dazo is now known as dazo_afk
17:24 -!- mintaka [n=kosmic@unaffiliated/spice] has quit [Connection reset by peer]
17:24 -!- mintaka [n=kosmic@thefuckin.net] has joined ##openvpn-discussion
--- Day changed Sat Jan 16 2010
08:44 -!- Irssi: ##openvpn-discussion: Total of 9 nicks [1 ops, 0 halfops, 0 voices, 8 normal]
16:49 -!- mintaka [n=kosmic@thefuckin.net] has quit [SendQ exceeded]
--- Day changed Sun Jan 17 2010
00:10 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal]
08:56 -!- mintaka [n=kosmic@thefuckin.net] has joined ##openvpn-discussion
--- Day changed Mon Jan 18 2010
02:34 -!- d12fk [n=heiko@vpn.astaro.de] has quit [Remote closed the connection]
04:33 -!- dazo_afk is now known as dazo
13:31 -!- dazo is now known as dazo_afk
--- Day changed Tue Jan 19 2010
02:56 -!- dazo_afk is now known as dazo
07:08 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal]
12:52 -!- dazo is now known as dazo_afk
17:09 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: berniv6
17:16 -!- berniv6 [n=berni@2001:1b10:1000:0:0:0:26c3:1] has joined ##openvpn-discussion
--- Day changed Wed Jan 20 2010
01:49 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:49 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:55 -!- d12fk [n=heiko@vpn.astaro.de] has joined ##openvpn-discussion
06:28 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: d12fk
06:30 -!- Netsplit over, joins: d12fk
06:36 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: dazo_afk, d12fk, @mattock, berniv6, mintaka, cron2
06:45 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
06:45 -!- ServerMode/##openvpn-discussion [+o mattock] by irc.freenode.net
06:45 -!- d12fk [n=heiko@vpn.astaro.de] has joined ##openvpn-discussion
06:45 -!- berniv6 [n=berni@2001:1b10:1000:0:0:0:26c3:1] has joined ##openvpn-discussion
06:45 -!- mintaka [n=kosmic@thefuckin.net] has joined ##openvpn-discussion
06:45 -!- dazo_afk [n=dazo@nat/redhat/x-lshoztazovndqxix] has joined ##openvpn-discussion
06:45 -!- cron2 [n=gert@blue.greenie.muc.de] has joined ##openvpn-discussion
06:49 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: d12fk
06:49 -!- Netsplit over, joins: d12fk
06:52 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: @mattock
06:53 -!- Netsplit over, joins: @mattock
07:11 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: d12fk
07:14 -!- Netsplit over, joins: d12fk
07:14 -!- d12fk [n=heiko@vpn.astaro.de] has quit [Read error: 104 (Connection reset by peer)]
07:14 -!- d12fk [n=heiko@vpn.astaro.de] has joined ##openvpn-discussion
07:16 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: @mattock
07:17 -!- Netsplit over, joins: @mattock
07:29 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: dazo_afk, d12fk, @mattock, berniv6, mintaka, cron2
07:41 -!- Netsplit over, joins: @mattock, cron2, dazo_afk, mintaka, berniv6, d12fk
08:18 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit ["Leaving."]
12:53 -!- Irssi: ##openvpn-discussion: Total of 9 nicks [1 ops, 0 halfops, 0 voices, 8 normal]
15:18 -!- trispace [n=surfer@chello212017114137.18.11.vie.surfer.at] has joined ##openvpn-discussion
15:47 -!- trispace [n=surfer@chello212017114137.18.11.vie.surfer.at] has quit []
19:46 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 60 (Operation timed out)]
19:49 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
19:50 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
19:50 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
--- Day changed Thu Jan 21 2010
03:53 -!- mintaka is now known as kosmic
03:53 -!- kosmic is now known as mintaka
07:30 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: berniv6, d12fk, @openvpn2009, dazo_afk, mintaka, cron2
07:30 -!- Netsplit over, joins: d12fk
07:30 -!- Netsplit over, joins: @openvpn2009
07:34 -!- dazo_afk [n=dazo@nat/redhat/x-oqavtanzapelxkcm] has joined ##openvpn-discussion
07:34 -!- dazo_afk is now known as Guest88514
07:34 -!- Guest88514 is now known as dazo
07:35 -!- dazo is now known as Guest41804
07:35 -!- mintaka [n=kosmic@109.74.194.171] has joined ##openvpn-discussion
07:36 -!- berniv6 [n=berni@2001:1b10:1000:0:0:0:26c3:1] has joined ##openvpn-discussion
07:40 -!- cron2 [n=gert@blue.greenie.muc.de] has joined ##openvpn-discussion
08:30 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: Guest41804
08:30 -!- Netsplit over, joins: Guest41804
08:31 -!- Guest41804 [n=dazo@nat/redhat/x-oqavtanzapelxkcm] has quit [Success]
08:34 -!- Netsplit lindbohm.freenode.net <-> irc.freenode.net quits: berniv6, @openvpn2009, mintaka, cron2
08:34 -!- Guest23896 [n=dazo@nat/redhat/session] has joined ##openvpn-discussion
08:34 -!- Netsplit over, joins: cron2, berniv6, mintaka
08:35 -!- Netsplit over, joins: @openvpn2009
09:44 -!- ecrist [i=ecrist@pdpc/supporter/professional/ecrist] has left ##openvpn-discussion []
--- Log closed Thu Jan 21 09:44:51 2010
--- Log opened Wed Jan 27 07:52:00 2010
07:52 -!- ecrist [n=ecrist@mr.garrison.secure-computing.net] has joined ##openvpn-discussion
07:52 -!- Irssi: ##openvpn-discussion: Total of 9 nicks [2 ops, 0 halfops, 0 voices, 7 normal]
07:52 -!- Irssi: Join to ##openvpn-discussion was synced in 1 secs
07:52 -!- ecrist changed the topic of ##openvpn-discussion to: OpenVPN Discussion Channel || Meetings Held Thursdays, 1900UTC
07:54 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit ["Leaving."]
--- Day changed Thu Jan 28 2010
02:00 -!- Guest89799 is now known as dazo
08:07 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal]
10:36 -!- d12fk [n=heiko@vpn.astaro.de] has quit [Remote closed the connection]
11:05 -!- Kas [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:05 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
11:15 -!- d12fk [n=heiko@vpn.astaro.de] has joined ##openvpn-discussion
11:35 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
11:35 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
11:49 <@mattock> a few links regarding todays topics:
11:49 <@mattock> http://trac.edgewall.org/wiki/PluginList
11:49 <@mattock> http://trac-hacks.org/
11:49 < vpnHelper> Title: PluginList – The Trac Project (at trac.edgewall.org)
11:49 < vpnHelper> Title: Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:00 <@mattock> Discussion forums for Trac: http://trac-hacks.org/wiki/DiscussionPlugin
12:00 < vpnHelper> Title: DiscussionPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:00 <@mattock> and an example site where they are in use: http://blackhex.no-ip.org/discussion
12:00 < vpnHelper> Title: Forum List – BlackTrac (at blackhex.no-ip.org)
12:02 <@mattock> spam filtering: http://trac.edgewall.org/wiki/SpamFilter
12:02 < vpnHelper> Title: SpamFilter – The Trac Project (at trac.edgewall.org)
12:04 <@mattock> we might need csv import if we want to import the current SF.net bug reports: http://trac-hacks.org/wiki/TicketImportPlugin
12:04 < vpnHelper> Title: TicketImportPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:11 <@mattock> this might help maintain code quality (if buildbot itself works properly): http://trac-hacks.org/wiki/TracBuildbotIntegration
12:11 < vpnHelper> Title: TracBuildbotIntegration - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:15 <@mattock> some might be more comfortable with mediawiki syntax: http://trac-hacks.org/wiki/MediaWikiPluginMacro
12:15 < vpnHelper> Title: MediaWikiPluginMacro - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:17 <@mattock> I'd definitely like this one: http://trac-hacks.org/wiki/TocMacro
12:17 < vpnHelper> Title: TocMacro - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:25 -!- mode/##openvpn-discussion [+o ecrist] by ChanServ
12:25 -!- mode/##openvpn-discussion [-c] by ecrist
12:25 -!- mode/##openvpn-discussion [+c] by ChanServ
12:25 -!- mode/##openvpn-discussion [-n] by ecrist
12:25 -!- mode/##openvpn-discussion [+n] by ChanServ
12:25 -!- mode/##openvpn-discussion [-c] by ecrist
12:25 -!- mode/##openvpn-discussion [-n] by ecrist
12:26 -!- mode/##openvpn-discussion [+n] by ChanServ
12:26 -!- krzie [n=krzee@unaffiliated/krzee] has joined ##openvpn-discussion
12:26 -!- mode/##openvpn-discussion [-o ecrist] by ecrist
12:37 <@mattock> we want to provide downloads: http://trac-hacks.org/wiki/DownloadsPlugin
12:37 < vpnHelper> Title: DownloadsPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:37 <@mattock> also, it might be good if James was aware of all new tickets: http://trac-hacks.org/wiki/DefaultCcPlugin
12:37 < vpnHelper> Title: DefaultCcPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:41 -!- dazo [n=dazo@nat/redhat/x-vjnkmifkciediwzb] has quit [Read error: 60 (Operation timed out)]
12:50 <@mattock> irc announcements from trac: http://trac-hacks.org/wiki/IrcAnnouncerPlugin
12:50 < vpnHelper> Title: IrcAnnouncerPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:50 < ecrist> mattock: for IRC, I usually just use an RSS plugin
12:50 <@mattock> ecrist: in trac?
12:51 < ecrist> yep
12:51 <@mattock> ok
12:51 < ecrist> track has RSS, so I just use an RSS function in the bot
12:51 <@mattock> how about this: http://trac-hacks.org/wiki/IrcLogsPlugin
12:51 < vpnHelper> Title: IrcLogsPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org)
12:52 < ecrist> that looks pretty nice
12:52 <@mattock> my eyes hurt, trac has so many extensions... :)
12:52 <@mattock> gotta take another look at the multi-project support
12:54 < ecrist> vpnHelper is a supybot, so the irclogs would work well
12:54 < vpnHelper> ecrist: Error: "is" is not a valid command.
12:54 < ecrist> shut up vpnHelper 
12:55 < cron2_> *lol*
12:55 < krzie> hah
12:57 < ecrist> mattock: if you were to setup trac, you could simply use a crontab to fetch the log files you need.  I could put supybot logs somewhere publically accessible for fetching.
12:58 <@mattock> ecrist: whatever works :)
12:58 <@mattock> I think it'd be nice to have IRC logs in Trac... especially meeting logs
13:00 < ecrist> indeed.
13:00 < ecrist> I already make logs publically available, but those are just from my own irc client, not vpnHelper
13:00 <@mattock> yep
13:01 <@mattock> perhaps it'd be possible to automatically grab the meeting logs (e.g. 19:00 - 20:00 UTC on Thursdays) and put them to trac
13:01 < krzie> sure it is
13:01 < krzie> easy as well
13:02 <@mattock> great! only good manual work is no manual work
13:02 <@mattock> or something like that :)
13:02 < krzie> ;]
13:02 <@mattock> ok, shall we begin?
13:03 <@mattock> no objections I guess :)
13:03 < krzie> sounds good to me
13:03 < krzie> isnt james coming?
13:04 <@mattock> krzie: I assume not, we got this Thursday meeting idea yesterday... a little short notice
13:04 < krzie> gotchya
13:05 <@mattock> anyways, the idea is to decide how to set up our Trac so that somebody (patel?) can get to work
13:05 < krzie> if he hasnt seen this patch, pls pass it over
13:05 < krzie> http://www.greenie.net/ipv6/openvpn.html
13:05 < vpnHelper> Title: Gert Döring - IPv6 Payload Patch for OpenVPN (at www.greenie.net)
13:05 < krzie> never used it, but looks nice ;)
13:05 < cron2_> it was announced on the -devel mailing list (by Bernhard Schmidt)
13:05 <@openvpn2009> hey guys
13:05 <+Kas> Hello!
13:05 <@mattock> hi guys!
13:05 < krzie> cron2, oh ok
13:05 < krzie> hey all!
13:06 <@mattock> ok, so a few topics:
13:06 < cron2_> krzie: but of course I'm most interested in getting feedback - "this is crappy code, no way" or "it can be included if this-and-that is changed" :-)
13:07 <@mattock> cron2: I've discussed this with James - lack of comments is a big problem
13:07 <@mattock> and it's being fixed
13:07 < krzie> if i understand right thats one of the motivations for these meetings and getting a trac up
13:07 <@mattock> krzie: correct
13:07 < cron2_> mattock: yes, we've discussed this at the last IRC meeting already.  I'm not overly impatient, as I know you're working on it.
13:09 <@mattock> now there are a few problems: a) james is very busy trying make OpenVPN pay, b) He's not good at refocusing (e.g. checking and commenting on emails every morning and getting to coding _after_ that)
13:10 <@mattock> however, he's fine with less frequent participation, say twice a week (meeting + handling patches).
13:10 < krzie> that doesnt sound like a real problem
13:10 < krzie> once a week looking into patches and replying to code related stuff sounds reasonable to me
13:11 <@mattock> but he'd very much like others to preview the patches first and provide comments to the authors (e.g. tell of any obvious problems)
13:11 < cron2_> mattock: having james available once-a-week for e-mailing with the community would work for me
13:11 <@mattock> ok, so we'll work on that
13:11 <@mattock> perhaps we could discuss this in detail next week? what do you think?
13:12 < krzie> assuming hes here, sounds good
13:12 <@mattock> I'll make sure he is :)
13:12 < krzie> ;]
13:12 < cron2_> previewing by people with some insight in the code is something that should be doable - but parts of the code are quite hard to understand, so reviewing (or even "answering questions related to those") will not always be possible
13:12 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has quit ["Ctrl-C at console."]
13:12 <@mattock> cron2: I guess james will have to take responsibility of those
13:12 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has joined ##openvpn-discussion
13:12 < cron2_> for the reviewers, it would be tremendously helpful to have a coding style guide
13:13 <@mattock> cron2: agreed
13:13 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Client Quit]
13:13 <@mattock> anyways, regarding the trac installation...
13:13 < cron2_> both "how it is supposed to be formatted" and "how things are supposed to be done" (like "don't use alloca(), use the built-in gc_* garbage collector stuff)
13:13 <+Kas> :-)
13:13 < cron2_> sorry, back to trac :)
13:14 <@mattock> cron2: that's ok :)
13:14 <+Kas> We are anxiously awaiting to hear about trac
13:14 <@mattock> I checked the multiple project support in Trac and it's ok
13:14 <@mattock> not excellent, but ok
13:15 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has joined ##openvpn-discussion
13:15 <@mattock> and I don't think we need to do anything special initially... meaning that we can configure multi-project support later on
13:15 <@mattock> so a basic trac installation should suffice
13:15 <@mattock> oh, almost forgot the most important thing... the user/developer wiki idea
13:16 <+Kas> this will be done via tracs internal wiki, correct?
13:16 <+Kas> * internal = built in
13:16 <@mattock> there's one big problem with having separate user and developer wiki (e.g. mediawiki for users, trac for developers)
13:16 < krzie> we could have ecrist seperate his wiki from his personal one (he suggested it before) and use that
13:17 < krzie> since its alredy been the wiki for awhile now
13:17 < ecrist> that doesn't fit with the 'OpenVPN wants control' mandate.
13:17 <@mattock> there's no way to keep the content from splitting into two... some developer content here, some there
13:17 <+Kas> Would he be okay with hosting it on openvpn.net?
13:17 < krzie> would he have access to it on the shell level?
13:18 < krzie> (not that i can answer for him of course)
13:18 <@mattock> ecrist: this is something where francis won't budge... the core community site has to be on our servers
13:18 <+Kas> We could possibly host a seperate vm with the community wiki, so you have shell access
13:18 < krzie> mattock has he seen history of who does it better?
13:18 < krzie> cause i have, and i trust ecrist over openvpn.net
13:18 < krzie> (not to be rude)
13:18 <@mattock> I managed to convince him that we should integrate with other services where it makes sense (e.g. international wikis/forums)
13:19 <@mattock> krzie: I guess you have all the reason to
13:19 <@mattock> trust ecrist, that is
13:20 < krzie> well and distrust him not running it
13:20 < krzie> from historical standpoint
13:20 < krzie> nothing he has run while ive known him has had a single issue
13:20 < ecrist> there *was* that dead hooker in the closet that one time, though...
13:21 < krzie> thats an issue? i just call that "friday"
13:21 < ecrist> lol
13:21 <+Kas> ecrist: would you be okay with us hosting a wiki, and allowing you shell access to the vm?
13:21 < ecrist> at this point, I don't really care if you host a wiki, but I plan on maintaining my wiki
13:21 < ecrist> I told that to Francis nearly two years ago
13:22 <+Kas> My apologies if I am bringing up old stuff, I was not around, none of us were :-)
13:22 < krzie> at least that way he could off-site backup your wiki to his, in case yours goes kaput (again)
13:22 < ecrist> He and I had many email exchanges about this in the past.  He wanted to host and secure and run these public services, but wanted me to do all the work, with no real control
13:22 < cron2_> off-site backup sounds like a good plan
13:22 <@mattock> ecrist: I didn't know that... 
13:23 <@mattock> cron2: agreed, I spoke about off-site backups to existing community sites a while back
13:23 <+Kas> ecrist: we are trying to change that...
13:23 <@mattock> ecrist: are you ok if I ask francis what he feels about this?
13:23 < ecrist> This is what I was told on 01-Dec-2008:
13:23 < ecrist> I'm open to the idea of linking to your Wiki and forum as long as we can mirror the information on our server. We want to make sure the data is not lost if you decide to discontinue the support and hosting..
13:23 <@mattock> I mean I'll make sure that he understands that with responsibility you also need some power
13:24 <@mattock> ecrist: this sounds a very good idea
13:24 < ecrist> He later reneged and stated he wanted it hosted at openvpn
13:24 < ecrist> I'm not in it for power
13:24 < krzie> <ecrist> I'm not in it for power
13:24 < krzie> i hope that is clear to everyone
13:25 < krzie> we just want it to stay up reliably and always work right
13:25 < ecrist> in my experience, it is impossible to properly maintain a webserver and applications without full access to that host
13:25  * cron2_ thinks that having the wiki available both at the company and at a community site would protect us against either one going away...
13:25 <@mattock> perhaps power is a bit harsh word...
13:25 <+Kas> I am aware of that, I hope you guys understand, we are really trying to fix some of our past mistakes.
13:25 <@mattock> kas: hopefully most of them
13:25 <+Kas> :-)
13:26 <+Kas> Patel and I manage the servers, ecrist, krzie, we do not have an issue giving you guys control over the servers for wiki etc,
13:26 <@mattock> ecrist: I'll discuss this admin issue with Francis... he has already agreed to (well, I guess) to off-site backups
13:27 < krzie> i differ to ecrist, hes kept the community stuff up for awhile and done a very very good job at it
13:28 < krzie> and even with my bot, once i put it on a server he has access to, he improved it
13:29 <@mattock> anyways, the big question... how do we keep the content from splitting with multiple wikis (user/devel)? 
13:29 <@mattock> should we just have the Trac for both users and developers?
13:29 <@mattock> I fear developer content will end up in the user wiki and vice versa... and then it's a big mess
13:29 < krzie> well, isnt that the same deal with mailing list?
13:30 < cron2_> mattock: well, someone would have to supervise, and potentially move content
13:30 < cron2_> (as in "tell the author that he's in the wrong wiki")
13:30 <@mattock> krzie: yep, but mailing list content gets lost anyway :)
13:30 <@mattock> cron2: perhaps that's doable...
13:31 < cron2_> but I could live with a common wiki for "all openvpn content", as long as it has a somewhat structured index for developer topics...
13:31 <@mattock> perhaps we should start with "just trac" and see if it causes problems
13:31 <@mattock> if not, stick with it
13:31 < cron2_> I'm not sure how much developer content will be there anyway
13:31 <@mattock> cron2: that remains to be seen, hopefully a lot
13:31 <@mattock> at least the coding conventions, common issues etc
13:32 < cron2_> my imagination on "what could be developer content" is a bit limited :-) - so maybe 10 pages or such, and not much more
13:32 <@mattock> one more reason not to have separate developer wiki I guess :)
13:32 <@mattock> one wiki to rule them all
13:32 < cron2_> yes.  I was agreeing to that in a complicated way :)
13:33 <@mattock> any objections to starting with Trac?
13:33 < cron2_> go ahead
13:33 <@mattock> great!
13:33 <+Kas> Lets do it
13:33 <@mattock> ok, so a plain Trac installation, nothing special
13:33 < cron2_> how would access be organized?
13:34 <@mattock> you mean access control & authorization?
13:34 <@mattock> e.g. user accounts, permissions and such?
13:34 < cron2_> yes - is an account needed to open a trac ticket?  to edit wiki content?  if yes, who decides on who gets an account?
13:35 < ecrist> I will setup logging of IRC (all three openvpn channels) for vpnHelper today.
13:35 <@mattock> cron2: if we want lots of wiki content, we need automated registration (email -> click a link)
13:35 < ecrist> I will try to determine if there's an easy way to parse my current logs to the new format and do so, but no promises.
13:35 <@mattock> however, in that case we need some form of (human) spam prevention
13:36 < cron2_> mattock: I agree for the wiki, but I have no experience with the ticketing side here - is something like this typically abused?
13:36 <@mattock> cron2: I don't know, might be
13:36 <@mattock> we could try it out and extinguish the fire afterwards :)
13:36 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has quit ["Ctrl-C at console."]
13:36 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has joined ##openvpn-discussion
13:37 < krzie> i know the forum gets frequent spam, me ecrist and dougy deny them manually
13:37 < krzie> and we set that people must post 5 times (manually accepted) before its auto-accepted
13:37 <@mattock> I think it makes sense to make bug reporting, feature requests and wiki editing as easy as possible (without attracting all the spam in the world)
13:38 < krzie> never used trac tho, dunno if it has that
13:38 < cron2_> krzie: I like that approach.  "Show that you're a nice and helpful person, then get automatic access"
13:38 <@mattock> krzie: there are some spam prevention plugins for Trac
13:38 <@mattock> krzie: the approach you've taken is really nice - not overly taxing on admins
13:39 <@mattock> then we need to move bugs and such from SF.net to Trac... there's a CSV importer which might help
13:39 < ecrist> it's 2 valid posts, not 5, but he's got the right idea. ;)
13:39 < krzie> oh i thoguht 5 ;]
13:40 < krzie> like i said before, ecrist manages that stuff on server and config side
13:40 <@mattock> kas, openvpn2009: what do you need to know? I believe you're setting up the servers?
13:40 < krzie> hehe
13:40 <+Kas> Yes sir :-)
13:40 <@mattock> :)
13:41 <@mattock> kas: could Frank do some CSS and theme our Trac?
13:41 <@mattock> I mean, is he capable of :)
13:42 <+Kas> He is, and Patel and I could figure something out too.
13:42 <@mattock> is the current look of openvpn.net ok? Or has there been talk about changing that?
13:43 <@mattock> I mean, it does not make sense to make a theme that's going to be obsolete soon :)
13:43 <+Kas> There have been talks, we are still working on it.
13:43 <+Kas> It is staying current at least for awhile
13:43 <@mattock> kas: ok
13:43 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has quit ["Ctrl-C at console."]
13:44 <@mattock> what community services (wikis and forums) we have currently? and what are they running? I'm wondering how to integrate the content
13:45 -!- vpnHelper [n=vpn@unaffiliated/krzee/bot/vpnhelper] has joined ##openvpn-discussion
13:45 <@mattock> regarding forums... Trac has a forum plugin... any experience with it? Is it cheesy?
13:46 < ecrist> I would suggest vBulletin.  
13:46 <@mattock> or is a real forum software a better choice?
13:46 < krzie> we currently run a wiki, forum, and IRC channel
13:46 < ecrist> we're running phpBB3 currently, but it lacks in some regards.
13:46 < ecrist> I've been saving community donations to purchase a vB license
13:47 <@mattock> ecrist: aren't the good OSS options? 
13:47 < krzie> mattock, yes phpBB ;]
13:47 <@mattock> krzie: so nothing better :)
13:48 < krzie> if you find one, let us know
13:48 <@mattock> I'm sure you've looked already and I trust you ;)
13:48 < ecrist> phpBB is probably the most widely used, best supported open/free forum package
13:48 < ecrist> there are others, but they suck
13:49 <@mattock> how (in)secure phpbb is? hopefully not a typical php application :)
13:49 < ecrist> phpBB has ugly urls, and poor RSS support, however, which is why I'm looking to something else.
13:49 < ecrist> php is as secure as you write your code, mattock.
13:49 <+Kas> ecrist: Those can be fixed
13:49 < ecrist> don't blame the language, blame the developer
13:49 < ecrist> Kas: indeed, I put enough time into openvpn as it is, to spend more time rewriting plugins.
13:50 <@mattock> ecrist: I agree on blaming the developers :)
13:50 <+Kas> We can help, I don't mind working with the plugins
13:50 <@mattock> it's all their fault
13:50 < ecrist> I've now got vpnHelper logging channels, just fyi
13:51 < ecrist> it's currently logging ##openvpn, ##openvpn-discussion, and #openvpn-devel
13:52 <@mattock> ok, I think we've made some progress:
13:52 <@mattock> - start with plain Trac, no separate user wiki for now
13:52 <@mattock> - check how we arrange the backup / mirroring stuff
13:52 <@mattock> - check the forum software and how to integrate it into the Trac-based community site 
13:52 <@mattock> and worry about Trac plugins later
13:53 <@mattock> I'll add the potential Trac plugins to the meeting summary
13:53 < cron2_> *wake up* there are developers to blaim?  All for it!
13:53 <@mattock> cron2: I blame pidgin developers: they made this IRC chat possible for me. I could be watching movies or something instead of this crap ;)
13:54  * cron2_ blames the openvpn developers... :-)
13:55 <@mattock> they're the worst :)
13:55 <@mattock> what do you think about thinking about next week's topics?
13:56 <@mattock> like "what shall we discuss next week"... to give people some time to prepare (if necessary)
13:56 <@mattock> e.g. I think we should discuss (with James) if somebody wants to maintain an "unstable" tree for OpenVPN
13:56 < cron2_> "community developer <-> corporation interaction"
13:57 < cron2_> "which day is the day that James answers e-mail" :)
13:57 <@mattock> cron2: I'm expecting powerpoints from you next week :)
13:57 <@mattock> better make them good :)
13:57 < ecrist> mattock: please feel free to update the topic in this channel as appropriate
13:57 <@mattock> cron2: basically that, yes
13:57 < cron2_> can I do some OpenVPN patches instead?
13:57  * cron2_ has some very hacky AIX port brewing
13:58 <@mattock> cron2: no, we need to convince the management that these meetings are producing tangible results (=powerpoints) :)
13:58 < krzie> aix has tuntap!?
13:58 < cron2_> krzie: no, this is the nasty bit
13:58 < cron2_> I'm talking PPP via a pseudo-tty to AIX' pppd
13:59 < cron2_> (and I do not expect that *this* is ever going to go mainstream - it's seriously ugly, but we need it for a customer...)
13:59 < krzie> hacky was right, lol
13:59 < krzie> you arent behind the QNX64 support are you?
13:59 < cron2_> krzie: no.  what are they doing?
14:00 < cron2_> (we need a wiki to coordinate development efforts - who's working on what - and such stuff :) )
14:00 < cron2_> mattock: you really don't want to see my powerpoint skills :)
14:00 < ecrist> the advantage of the community, we're aware of most of these things, albeit loosely
14:01 < krzie> cron2: !factoids search qnx
14:01 <@mattock> cron2: agreed
14:01 < cron2_> !factoids search qnx
14:01 < vpnHelper> cron2_: No keys matched that query.
14:01 < krzie> (in ##openvpn)
14:01 <@mattock> I use wikis all the time ...
14:02 < cron2_> oh, it does different factoids per channel
14:02 < krzie> aye
14:02 <@mattock> I think the "official" portion is over... I'll discuss some architecture stuff with Patel and Kas - privately so that nobody sees our mistakes (except ecrist when he has root access to the servers :)
14:03 <+Kas> lol
14:03 < cron2_> mmmh, the qnx folks have a proper tun driver... can't do that on AIX, modify the standard kernel in any way
14:03 < cron2_> mattock: looking forward to be able to enter the first trac tickets and fiddle with the wiki :)
14:04 <@mattock> cron2: I'm confident we get a lot of content soon. At least bug reports from SF.net :)
14:04 <@mattock> and feature requests from there and ovpnforums
14:04 < krzie> <vpnHelper> krzie: "wishlist" is http://ovpnforum.com/viewforum.php?f=10 for
14:04 < krzie>             the openvpn wishlist
14:05 < vpnHelper> Title: OpenVPN Forum View forum - Wishlist (at ovpnforum.com)
14:12 < ecrist> mattock: I would encourage you to setup the IRCLogsPlugin for trac right away
14:16 <@mattock> ecrist: good idea, we'll do that
15:09 -!- krzie [n=krzee@unaffiliated/krzee] has left ##openvpn-discussion []
16:01 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit [Read error: 113 (No route to host)]
19:44 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit ["ircN 8.00 for mIRC (20080809) - www.ircN.org"]
--- Day changed Fri Jan 29 2010
03:39 -!- dazo_afk [n=dazo@nat/redhat/x-iyxxdnbqukoenzpg] has joined ##openvpn-discussion
03:40 -!- dazo_afk is now known as Guest24100
03:40 -!- Guest24100 is now known as dazo
05:34 -!- mattock [n=samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:34 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
07:07 <@mattock> hi guys, take a look here: http://users.utu.fi/sjsepp/openvpn/getting_code_to_openvpn.png
07:08 <@mattock> this development process would almost certainly get James' blessing and probably solve many of our current problems
07:08 <@mattock> what do you think?
07:15 < dazo> mattock:  that looks good!
07:16 <@mattock> great! I'll ask James if he can live with it :)
07:18  * dazo starts upgrading his workstation to F-12 .... hopefully back in a few hours
07:19 -!- dazo is now known as dazo_afk
08:22 -!- Irssi: ##openvpn-discussion: Total of 9 nicks [1 ops, 0 halfops, 1 voices, 7 normal]
09:15 -!- dazo_afk is now known as dazo
11:49 -!- dazo is now known as dazo_afk
13:08 -!- ecrist [n=ecrist@pdpc/supporter/professional/ecrist] has left ##openvpn-discussion []
--- Log closed Fri Jan 29 13:08:13 2010
--- Log opened Sun Jan 31 08:05:12 2010
08:05 -!- ecrist [ecrist@mr.garrison.secure-computing.net] has joined ##openvpn-discussion
08:05 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [1 ops, 0 halfops, 1 voices, 6 normal]
08:05 -!- Irssi: Join to ##openvpn-discussion was synced in 1 secs
13:53 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.]
--- Day changed Mon Feb 01 2010
02:31 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:31 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:37 -!- Guest65496 is now known as dazo
09:22 -!- dazo is now known as dazo_afk
10:13 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: Leaving]
11:21 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.]
11:26 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:26 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
12:11 -!- Irssi: ##openvpn-discussion: Total of 7 nicks [1 ops, 0 halfops, 0 voices, 6 normal]
--- Day changed Tue Feb 02 2010
04:59 -!- dazo_afk is now known as dazo
07:10 -!- dazo is now known as dazo_afk
07:14 -!- dazo_afk is now known as dazo
09:20 -!- reiffert [~thomas@mail.webersheim.de] has joined ##openvpn-discussion
11:09 -!- dazo is now known as dazo_afk
11:16 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal]
11:16 < ecrist> no mattock today?
11:16 < ecrist> I'm looking at purchasing a license for vB and setting up a forum <-> mailing-list bridge.
14:03 <@openvpn2009> ecrist, do you have his direct email address?
14:04 < ecrist> yeah, not that big of a deal, though
14:04 <@openvpn2009> okay he's also in finland so probably sleeping ;-)
14:04 < reiffert> it's 21:00 in finland.
14:06 < ecrist> s/sleeping/drunk/
14:06 <@openvpn2009> ahh!
14:11 < ecrist> I don't know if he, or who, was going to be setting up track, but I have vpnHelper logging things now, so I can make those available to whoever's handling that
14:11 < ecrist> mattock had mentioned an IRC log plugin.
14:17 < reiffert> omg, ml forum sync, irc logs ...
14:17 < reiffert> i really start disliking how it turns.
14:18 < reiffert> all the stuff just for keeping the bottleneck.
14:18 < reiffert> s,for,with,
14:22  * ecrist doesn't understand.
14:24 < ecrist> afaik, reiffert, you don't really frequent the forums anyhow.
14:25 < reiffert> ecrist: but I cant ignore them any further when every single fart gets send to the mailing list.
14:25 < ecrist> the mailing list and forums essentially have the same content, though.
14:26 < reiffert> I hate forums for all the farts. I love lists for the precise question(s).
14:27 < ecrist> not sure what you mean by 'farts'
14:27 < reiffert> check the forum of your choice and you will find farts at every single thread.
14:28 < ecrist> not sure what you mean by 'farts'
14:30 < reiffert> Can we have a suject tag like [forum] for those sync mails?
14:30 < ecrist> I'm sure we can.
14:30 < ecrist> can you tell me what you mean by 'fart' though?
14:30 < ecrist> I don't know why you think forum content is different from mailing list content
14:31 < reiffert> http://blogs.gnome.org/patrys/2008/06/23/why-forums-are-a-bad-way-to-help-the-community/
14:31 < vpnHelper> Title: Why forums are a bad way to help the community « Patryk Zawadzki (at blogs.gnome.org)
14:32 < ecrist> reiffert: in that article, a mailing list would be considered a forum.
14:34 < ecrist> for that matter, IRC would also be considered a forum.
14:35 < reiffert> graduation allowed?
14:48 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 252 seconds]
14:52 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
14:52 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
15:04 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 260 seconds]
15:08 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
15:08 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
15:08 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
16:05 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 256 seconds]
16:11 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
16:11 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
16:15 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds]
16:19 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
16:19 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
16:28 -!- reiffert [~thomas@mail.webersheim.de] has left ##openvpn-discussion []
--- Log closed Wed Feb 03 02:29:48 2010
--- Log opened Wed Feb 03 09:47:51 2010
09:47 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
11:20 -!- Netsplit *.net <-> *.split quits: dazo
11:22 -!- Netsplit over, joins: dazo
11:23 -!- dazo [~dazo@nat/redhat/x-tcsfeaxcoogruscu] has quit [Quit: ZNC - http://znc.sourceforge.net]
11:26 -!- dazo [~dazo@nat/redhat/x-brllznifwdqemddn] has joined ##openvpn-discussion
11:36 -!- dazo is now known as dazo_afk
--- Day changed Thu Feb 04 2010
02:23 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:23 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:27 -!- dazo_afk is now known as dazo
03:43 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
04:23 -!- mattock [~samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
04:23 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:25 -!- mattock [~samuli@sparkgw.utu.fi] has quit [Client Quit]
04:45 -!- reiffert [~thomas@mail.webersheim.de] has joined ##openvpn-discussion
08:32 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
08:32 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
11:30 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:30 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
12:46 -!- HotaruT [massar@bratwurst.unix-ag.uni-kl.de] has joined ##openvpn-discussion
12:54 -!- agi [~agi@manson.entorno-digital.com] has joined ##openvpn-discussion
12:54 < agi> hi
12:55 < cron2> hi
12:56 <@mattock> hi all
13:00 < dazo> Hi! :)
13:00 -!- jamesyonan [~jamesyona@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:00 -!- mode/##openvpn-discussion [+v jamesyonan] by ChanServ
13:00 <+jamesyonan> Hi
13:00 <@mattock> hi james
13:01 <@mattock> I think we're all set
13:01 <+jamesyonan> cool
13:02 <@mattock> james, david (dazo) has volunteered to maintain testing trees for OpenVPN
13:02 <+jamesyonan> great
13:02 <@mattock> did you have time to read through his vision in his email?
13:03 < cron2> mattock: yes, and I'm happy to see a volunteer
13:03 <@mattock> cron2: agreed!
13:03 <+jamesyonan> no, not yet -- I assume it's on openvpn-devel?
13:03 < dazo> yes
13:03 <@mattock> james, yes
13:03 < dazo> Subject: Re: [Openvpn-devel] New development process ready 
13:04 < ecrist> o/
13:04 < cron2> cool
13:04 < cron2> I volunteer to help with ACK/NACKing patches before they get into the testing tree
13:05 <@mattock> cron2: great!
13:05 < cron2> but I know myself - too much other stuff, so I'm not going to volunter for maintaining the testing tree
13:05 <@mattock> I'd ACK/NACK if I could :)
13:06 < dazo> That's actually a very important thing to have in place ... more people who can keep an eye on patches in addition to me
13:07 <@mattock> we should start writing developer documentation somewhere... as the community site wiki is not up, we could perhaps start with the secure computing wiki. Ecrist, are you the maintainer for it?
13:07 < dazo> Someone need to keep me straight as well, that I don't include "useless" patches 
13:07 <+jamesyonan> david -- just finished reading your email on openvpn-devel -- looks great
13:07 <@mattock> dazo: I think I can (sometimes) help with that, if the patch author explains what the patch does any why
13:07 < cron2> dazo: this is going to be tricky.  What's "useless" for some is "the most important patch ever" for others
13:07 <@mattock> can't comment on code quality, though
13:07 <+jamesyonan> I would add a couple things:
13:07 < dazo> jamesyonan:  thanks!  (man you're a quick reader ;-)) 
13:07 < ecrist> mattock: yes, I maintain that wiki
13:08 < cron2> dazo: if you look at today's patch (multipath iroute) - I have not yet fully read the code, but I wonder if that's a reasonable use case at all...  and it certainly complicates some of the code paths.
13:09 < dazo> cron2:  agreed ... "useless" is vague ... and can cause discussions
13:09 <+jamesyonan> (a) in most cases patches should have their functionality bracketed by #ifdefs so that people don't need to build them if they are not needed -- this is of importance in the embedded space where every byte of compiled code matters
13:09 < dazo> jamesyonan:  agreed
13:09 < cron2> jamesyonan: I'm actually quite unhappy about this.
13:09 < cron2> the code as it is is already quite hard to understand due to the high number of #ifdef's
13:10 < cron2> and every additional #ifdef increases the number of possible combinations that might not work
13:10 < cron2> (not that I couldn't understand the reasoning, but it's not without a price)
13:10 <+jamesyonan> (b) I know that linux-kernel popularized the idea of including patches inline in the email.  Personally, I think attachments work much better because there is no possibility of line breaks or other deviations messing up the patch
13:11 < dazo> I see the point of cron2 ... but we're having a lot of embedded users as well .... I'm worried they will require it ... then it's better to have such compile time enablement features
13:12 < dazo> jamesyonan:  I have no special feelings about how patches comes or not .... I will most probably prefer attachment myself, at least in the beginning
13:12 <+jamesyonan> linux seems fairly adamant about most features being ifdefable -- it seems to work for them
13:12 < cron2> I wonder how many bytes of difference some of these #ifdef really make - some are obviously big (like "reduce all the help texts"), but others should make only a few 100 bytes difference
13:12 < dazo> jamesyonan:  but there are some really neat scripts which parses the mail box and and applies patches very quickly ... not sure how they work with attachments .... but it's scriptable
13:13 < dazo> cron2:  trust me ... some embedded people count bytes .... when you have just 4MB flash and need to run a lot of other things there as well, it counts
13:14 < ecrist> attachments aren't really that different when parsing email
13:14 < dazo> jamesyonan:  cron2: but ... something can probably be done with cleaning up the code .... even though that's a project of its own, to make it more readable ..
13:14 <+jamesyonan> I think it's more than just a bytes difference -- it helps to understand which code is associated with which features and makes it easier to isolate functionality
13:14 < cron2> dazo: I'm running OpenVPN on my WRT, and if there's something I really dislike is to find that the one important feature for me is not in the precompiled binary...
13:15 < dazo> jamesyonan:  also beware that the linux source uses 8 spaces for tabs .... not 2 as I believe openvpn does ... that makes #ifdef look less intrusive
13:15 < cron2> jamesyonan: I'm worried about things like "feature X needs additional arguments to function Y" - which gets really messy with #ifdef
13:15 <+jamesyonan> yeah, but on WRT you're working with such a restricted space that adding a few kb could be the difference between having all of your packages fit or not fit
13:16 < dazo> cron2:  I see that one ... I share that pain .... but jamesyonan got the crucial point ...
13:16 < cron2> let's go for a specific example: the multipath iroute patch that was published today.  If you make that one conditional, you have twice the code to maintain for future changes in the iroute code
13:17 <+jamesyonan> "feature X needs additional arguments to function Y" -> I agree, ifdefs are not a panacea -- I think that changes that are sufficiently central to the core should not be ifdefed, but functionality on the periphery probably should
13:17 < cron2> now that's something I can agree to :-) (and yes, I can foresee that we're going to have this discussion for a number of individual patches)
13:18 < dazo> :)
13:18 <@mattock> this usage of #ifdefs needs to be documented properly... even though I'm sure discussions will arise even after that :)
13:18 <+jamesyonan> we have to be sensitive to bloat -- imagine someone is running 2.0.x fine on WRT and then 2.1 comes out and it's bigger and doesn't fit any more.  bloat shouldn't be a reason why people can't upgrade.
13:19 < cron2> mattock: agreed
13:19 < dazo> +1
13:19 <@mattock> jamesyonan, are there any embedded guys who could take part in the development? Or are they all system integrators or such?
13:20 < ecrist> I would suggest speaking with folks in the [open|dd-]wrt camps
13:20 < dazo> Not sure how much response dd-wrt developers would give (based on personal experiences)
13:20 <+jamesyonan> not sure if anyone is active right now -- but the whole #ifdef thing came about a couple years ago when a WRT guy complained on the list that 2.1 was too much bigger than 2.0
13:21 < ecrist> that beingn said, the amount of flash in more modern routers has gone up since then, as well.
13:21 < HotaruT> just a note wrt. linux-kernel.. they make heavy use of modules, ie. it is still possible to select which modules to take after compilation
13:21 <@mattock> jamesyonan, I guess we just need to create a proper balance here... 
13:22 <+jamesyonan> agreed
13:22 <@mattock> I think we have a kind of agreement on the #ifdef issue ... agreed?
13:22 < dazo> HotaruT:  you're suggesting module based features in OpenVPN?
13:23 < dazo> mattock:  agreed
13:23 < cron2> mattock: agreed
13:23 < cron2> dazo: well, maybe the point is "Linux kernel is not fully comparable to OpenVPN" :)
13:24 <@mattock> jamesyonan, could we host dazo's Git trees inside the "openvpn" project in SF.net?
13:24 < dazo> cron2:  yeah, I was thinking the same .... but it's an intriguing thought .... maybe something to consider for next version
13:25 < cron2> dazo: there be dragons... the system dependent part for dynamic module loading is likely going to be bigger than everything compiled in right away... :-)
13:25 <+jamesyonan> mattock: yes I think that makes sense
13:26 < dazo> cron2:  :) yeah ... a plug-in interface is already in place ....
13:26 <@mattock> jamesyonan: who shall manage the SF.net project? I can do it but I'll need admin access.
13:26 <@mattock> e.g. to activate the git support etc.
13:27 <+jamesyonan> I think dynamic modules make more sense for 3.0 when we move to a general purpose user-space network stack model
13:27 < dazo> mm
13:28 <@mattock> we'd need a roadmap for the project, too
13:29 < dazo> yes, please .... roadmap and developer docs is something I would really like to see 
13:29 < cron2> what is "the project" in this context?  "the new development model"?  or "openvpn future"?
13:30  * cron2 agrees with dazo
13:30 <+jamesyonan> Right -- we don't have a formal plan for 3.0 yet, but I think the basic idea is to generalize this notion of a userspace network stack where the VPN functionality really becomes just a module -- this internal organization will make it easier to do full IPv6 support, among other things.
13:30 <@mattock> cron2: I was thinking of where the OpenVPN is going (as an application)
13:30  * dazo understood project as OpenVPN 
13:31 < cron2> mattock: ok, the long-term plans.  Yes, this would be useful.
13:31 < cron2> jamesyonan: most IPv6 support is already available as patches today :-)
13:31 < dazo> jamesyonan:  the 3.0 plans ... are they reusing code from 2.1 ... or is it written mostly from scratch?
13:31 <+jamesyonan> for the transport layer, yes
13:32 <+jamesyonan> but running ipv6 over tun and getting all of the routing functionality I believe is still incomplete
13:32 < dazo> jamesyonan:  iirc ... cron2 have provided for tunnelling IPv6 .... and another one has IPv6 on the connection layer between openvpn apps
13:32 < cron2> jamesyonan: juanjo has OpenVPN-over-IPv6, I have IPv6-over-tun and server
13:33 < cron2> the latter needs more testing, and a few things smell funny right now :-)
13:34 < cron2> the routing functionality was actually the surprisingly easy part - the config handling and ifconfig stuff took the longest time
13:34 <+jamesyonan> I certainly don't have any problem merging ipv6 functionality in the 2.x base, but we will need a lot of testing and review for such a substantial change
13:34 < cron2> well-understood
13:34 < cron2> (and I'm happy to hear that :) )
13:35 <@mattock> what do you think if we proceed by writing the initial version of developer documentation, agree on coding conventions etc. and start reviewing (and merging) the ipv6 patchsets to dazo's trees?   
13:35 <@mattock> after proper testing they can be then moved to James' stable tree
13:35 < cron2> mattock: +1
13:35  * dazo see that as doable
13:35 <+jamesyonan> +1
13:35 <@mattock> ok, agreed then
13:36 < dazo> and it actually follows the newly working model we've agreed on :)
13:36 <@mattock> I suggest that for now we use the Secure computing OpenVPN wiki for this - until the community site is up. If that's ok with ecrist :)
13:37 <@mattock> for the initial developer documentation, that is
13:37 <@mattock> ecrist: is that ok?
13:37  * dazo can't answer for ecrist, but don't think he will reject that
13:37 <@mattock> dazo: I don't think that either
13:38 <@mattock> he can complain later if he does not agree :)
13:38 < dazo> yup :)
13:38 < ecrist> i think it would be a good idea, in terms of the development branch, to have a nightly 'release' for testing.  if not nightly, at some regular interval.
13:38 <@mattock> ok, so what process shall we use when merging stuff from testing to stable?
13:39 < ecrist> I'm ok with content on the SCN wiki
13:39 < dazo> It depends a little bit on how jamesyonan would like to do the merge on his side
13:39 <@mattock> ecrist: agreed, I'm working on this... preferably have apt/yum repos with latest snapshot available
13:40 <+jamesyonan> I would like to see a strong consensus among the development team that a particular patch should be merged
13:40 < ecrist> mattock: if now is not the right time, I'd like to discuss forum/mailing list 'stuff' at some point in the very near future.
13:41 < dazo> jamesyonan:  who is the development team in this scenario?
13:41 < agi> mattock: I could take care of the apt repo (since I'm the Debian maintainer)
13:41 < ecrist> I don't know of any examples, but perhaps some sort of 'voting' could be in place by the team?
13:41 <@mattock> ecrist: we could discuss that after the hardcore development issues perhaps?
13:41 < ecrist> X number of 'votes' to pass.  something that's trackable, so we can hold them over the flame later. ;)
13:41 < ecrist> ok
13:41 <@mattock> agi: that's great!
13:42 <@mattock> in fact, I almost managed to send you email about debian experimental... but let's discuss that later
13:42 < dazo> ecrist:  with the git web, not sure you need such nightly snapshot feature .... http://eurephia.git.sourceforge.net/git/gitweb.cgi?p=eurephia/eurephia.git;a=summary  .... look at the shortlog section, all the way to the right you have a "snapshot" link
13:42 < vpnHelper> Title: SourceForge - eurephia/eurephia.git/summary (at eurephia.git.sourceforge.net)
13:42 < agi> mattock: ok
13:43 < dazo> ecrist:  but for binary builds, it's another issue
13:43 <+jamesyonan> I'm thinking that the team consists of active developers who have taken some level of responsibility over various aspects of the development 
13:44 <@mattock> jamesyonan, how do you think stuff should move from "testing" to "stable"? Should we have a testing period (e.g. 2 weeks) before we even consider merging to stable?
13:44 < dazo> jamesyonan:  basically people who show up on  these irc meetings then?
13:44 < cron2> mattock: i think that really depends on the size and intrusiveness of the patch
13:44 < dazo> mattock:  in this case, we would really need to get some kind of feedback of those doing the tests 
13:44 < cron2> mattock: and a certain amount of "worksforme!" from other parties is needed, that have specifically tested this patch
13:45 <@mattock> dazo: I'd like that to change in the future... currently many can't attend due tz differences. But that's not an issue right now.
13:45 < cron2> "just because the patch is there for 2 weeks and hasn't immediately crashed someone's installation" is not good enough
13:45 <@mattock> cron2: agreed, we need at least semi-organized group of testers
13:45 < dazo> mattock:  agreed ... (and it's quite late for me as well)
13:46 < dazo> cron2:  +1
13:46 <+jamesyonan> I would want to be very conservative on this -- sometimes when a patch breaks something, you don't hear about it for months.  That's just the reality of doing development on a project which is considered "mature" by the user base.
13:46 < dazo> yes
13:47 < HotaruT> even not mature projects ... I did take me over a year to report basic bugs in dhcpv6 (o:
13:47 <@mattock> I'm currently - among other things - organizing this testing thingy... I think we need (at least) two things:
13:47 <@mattock> - shorter then time between introduction of a bug and the time when it's first reported
13:47 <@mattock> - organize the testing "workforce" properly (cron2's "worksforme"-guys)
13:47 <+jamesyonan> I want there to be a fairly significant isolation between the experimental code base, and the stable base that people expect to be truly stable
13:47 < dazo> jamesyonan:  but on the otherhand ... it's the final releases which needs to be stable ... that beta and rc releases are unstable, is not necessarily unexpected
13:47 <@mattock> jamesyonan, if the stable is really stable, you could release it pretty much at any given time
13:48 <@mattock> btw. what will be the difference between "stable" SVN and "stable" releases? Shall we have feature-freeze prior to each release?
13:49 < dazo> yes, that is a good idea .... I would probably suggest 2-3 months before a RC candidate is being planned ... so that the patches on the way into the RC can stabilise and manage a merge window
13:49 < ecrist> I think an annoying notice to stderr and to the log about 'this is a devel branch, report your bugs or we'll hunt you down' would help, possibly.
13:49 < dazo> heh .... ecrist: +1
13:49 < cron2> ecrist: +1 :-)
13:50 <@mattock> ecrist: agreed
13:50 < ecrist> I do that for some scripts I've written, and it's worked for me.
13:51 < dazo> I admit, I like that idea of such a nagger
13:51 < ecrist> my debug flags usually have a message such as, 'If you're using debug, there's probably something broken, why not notify the developer at awesome_dude@my-hero.com?'
13:52 <+jamesyonan> yeah, openvpn already has a tradition of error messages so verbose, they could be considered documentation
13:53 < dazo> lol
13:53 < cron2> I like that.
13:53 < cron2> it's really like "for the typical end-user misconfigurations, the error message will pinpoint the problem"
13:53 < dazo> I must say, I'd like an argument to disable some of them .... 
13:53 < cron2> (even though it horribly bloats options.c :-) )
13:53 <+jamesyonan> well, there's an ifdef for that :)
13:54 < cron2> ("bloat" with tongue-in-cheek :) )
13:54 -!- Irssi: ##openvpn-discussion: Total of 13 nicks [1 ops, 0 halfops, 3 voices, 9 normal]
13:54 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
13:54 <@mattock> let me try to summarize:
13:54 <@mattock> - obviously bad stuff is weeded out before it gets to "testing"
13:54 <@mattock> - somewhat stable stuff gets to "stable" SVN tree
13:54 <@mattock> - each release goes first to "feature freeze" - no new functionality is added at this point
13:54 <@mattock> - each release goes through a testing period (either based on time or number of problems being encountered) during which several RC's can be released
13:54 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
13:54 <@mattock> is this what we're all thinking of?
13:54 < cron2> ack
13:55 < dazo> ack
13:55 <+jamesyonan> sounds good
13:55 <@mattock> I think this should allow faster releases without compromising code quality
13:55 <@mattock> but testing the latest releases needs to made easier and the testing "workforce" organized
13:55 <@mattock> I'm working on that
13:56 <+jamesyonan> I gotta run in 5
13:56 <@mattock> ok
13:56 < dazo> mattock:  later on, the process for this testing period would need to be documented ... what should be tested how, how long time ideally used and what triggers a delay from the planned schedule
13:56  * dazo gotta run in 5 as well
13:56 <@mattock> dazo: agreed
13:56  * cron2 wants automated testing
13:56 < agi> (mattock: gotta go now, bb in 30 min. in case you want to talk about .debs)
13:56 <@mattock> cron2: me too
13:56 <@mattock> I think we covered most important things here
13:57 <@mattock> I'll write a summary of the meeting tomorrow and send it to devel
13:57 < cron2> thanks
13:57 < dazo> mattock:  jamesyonan: then I expect to hear from you when you have enabled access for me to the sf.net project, so that I can begin putting things together
13:57 < dazo> mattock:  looking fwd!  thanks!
13:58 <@mattock> I think we can now proceed to other issues with agi and ecrist
13:59 <@mattock> agi, could we use Debian experimental repositories for packages built from dazo's testing tree(s)? 
13:59 <@mattock> or what's Debian's policy on experimental?
14:00 <+jamesyonan> thanks guys, gotta run -- take care
14:00 <@mattock> bye james!
14:00 < dazo> jamesyonan:  c'ya!
14:00 < ecrist> l8r
14:00 < cron2> thanks and bye
14:00 -!- jamesyonan [~jamesyona@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: jamesyonan]
14:00  * dazo need to run as well
14:00 <@mattock> bye dazo!
14:00 < krzee> looks like talk of managing OS specific stuff like .deb and whatnot
14:00 < krzee> i think thats cool
14:01 < ecrist> mattock: agi had to run for 30 mins.
14:01 -!- dazo is now known as dazo_afk
14:01 <@mattock> ecrist: oh yes, of course
14:01 <@mattock> so you wanted to discuss the forum and mailinglist issues?
14:02 < ecrist> I was going to ask if you'd gotten around to looking further into trac and the irclog plugin for it
14:02 < ecrist> also, as to whether you'd explored any forum software
14:02 <@mattock> no, patel is still in the process of setting up the server
14:02 <@mattock> I'm going to do the Trac setup, incl. plugins
14:03 <@mattock> I did not take a look at forum software, but the vBulletin plugin/module you linked to looked interesting
14:04 < ecrist> I did some research, and the plugin is not available for 4.0 yet, but purchasing a 4.0 license grants access to older releases.
14:04 <@mattock> it'd solve(?) the forum/mailinglist problem pretty nicely
14:04 < ecrist> that being said, if we wanted to use the plugin, we'd just have to use 3.8.6 or whatever until 4.0 was finished.
14:04 < ecrist> indeed
14:04 < ecrist> there are some people who were complaining about forum/mailing merge, but I think overall it would be best.
14:05 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
14:05 -!- mode/##openvpn-discussion [+v Kasx] by ChanServ
14:05 <@mattock> I think vBulletin would be ok, it's pretty cheap and I don't think the data would be held hostage in it, either
14:05 < ecrist> also, we don't ahve to link 100% of the forum, so there can still be web stuff that doesn't pollute the mailing list
14:05 < ecrist> no, it just uses a standard back end
14:06 <@mattock> it seems to use MySQL... and I don't think there are any stupid tricks in the database contents/schema either
14:06 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 264 seconds]
14:06 < ecrist> right
14:06 <@mattock> I mean things like obfuscating the contents or such
14:06 <@mattock> you can never be too paranoid with proprietary software :)
14:06 < ecrist> nope, ther eis none
14:06 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 248 seconds]
14:07 < ecrist> let me rephrase, there is some encoding, but it's standard base64
14:07 <@mattock> as long as the data can be migrate to another solution then all is fine
14:07 <@mattock> I'm sure Francis will give us some pocket money for vBulletin, if required :)
14:08 < ecrist> if not, it's been in my ##openvpn donation budget for a while
14:08 <@mattock> ecrist: have you looked into other forum applications in depth? You're familiar with phpbb, but what about others?
14:08 < ecrist> I am not very familiar with many others
14:09 < ecrist> invasion powerboard is OK, but is on-par with phpBB and costs money
14:09 <@mattock> should we take a look together?
14:09 <@mattock> check out a few potential alternatives and then dig a little deeper into those
14:09 < ecrist> if you'd like.  the only plugin I've found for forum/mailman linking is with vB, though.
14:10 <@mattock> I guess that's a requirement for us
14:10 <@mattock> at least it's a _really_ nice feature
14:10 <@mattock> any idea how well it works?
14:10 < ecrist> I wouldn't say requirement, but it's something others have shown an interest in.
14:10 < ecrist> no, aside from the posts about that plugin from users indicating the 'live by' that plugin
14:10 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
14:10 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
14:10 < ecrist> it seems very mature, and is listed as 'Supported' by vB
14:11 <@mattock> ok
14:11 <@mattock> I think I'll take a quick look at potential forum alternatives in the OSS space
14:11 <@mattock> just to make sure
14:12 <@mattock> so is vBulletin "the" commercial forum software?
14:13 < ecrist> it seems to be.
14:13 < ecrist> but, I encourage a wider look at other software options
14:14 <@mattock> could you take a look at the commercial alternatives? I'll take a look at the OSS options
14:15 < ecrist> certainly.  I'll have some data for next thursday.
14:15 <@mattock> I'll do the same, then
14:15 < ecrist> feel free to email me directly if you have questions or want to discuss before hand.
14:15 <@mattock> will do!
14:15 <@mattock> btw the secure computing wiki...
14:16 <@mattock> can I (and others) register there ourselves?
14:16 <@mattock> or do you need to create accounts?
14:16 < ecrist> yes
14:16 <@mattock> ok
14:16 < ecrist> it is publicly editable, save some pages that have had spam problems.
14:17 < ecrist> my front-page, for example
14:17 <@mattock> If you don't mind, I'll add meeting summaries and such there, too
14:17 < ecrist> I monitor changes via an RSS feed.
14:17 < ecrist> feel free
14:17 <@mattock> one more thing... about the access to the community site
14:17 <@mattock> your access I mean
14:18 <@mattock> so you're mostly concerned with the data, right?
14:18 <@mattock> _if_ I have trouble convincing Francis to allow you root access
14:22 < ecrist> mostly, but overall configuration as well
14:23 < ecrist> really, I don't have that strong a stance in certain rgards
14:23 < ecrist> my only concern is that community resources are available and managed.
14:23 < ecrist> I'm only here because they aren't, currently
14:24 <@mattock> ok
14:25 <@mattock> did OpenVPN Technologies have some community services of their own earlier?
14:25 <@mattock> I don't know the history well enough...
14:25 < ecrist> yes, a wiki, official irc channel and forums
14:25 < ecrist> they all failed
14:26 <@mattock> oh, how did that happen?
14:26 <@mattock> failed in a technical sense or in political/social sense?
14:26 < ecrist> we before my time
14:26 < ecrist> technical
14:27 < ecrist> openvpn sites have not had a good reputation for stability
14:27 <@mattock> when was this?
14:27 < ecrist> even the latest site updates went wrong in terms of rewrites, etc.
14:27 < ecrist> about 3-5 years ago
14:27 <@mattock> ok
14:27 <@mattock> this is interesting... I don't know what was going on then, gotta take a look at the mailing list archives
14:28 < cron2> looong before I've ever used OpenVPN...
14:28 <@mattock> I'll try to get you root access to the community site server
14:28 <@mattock> that'd benefit everyone
14:29 < ecrist> ok
14:29 <@mattock> so what's your trade? are you a system administrator?
14:30 < ecrist> that is one of the hats I wear, the one that pays most of my bills.
14:30 < ecrist> I also do large access control/CCTV installations and burglar alarms.
14:30 <@mattock> I used to be a ~75% sysadmin (Linux/OpenBSD), too... for over 3 years.
14:31 < ecrist> 100% freebsd for me.
14:31 < ecrist> I manage about 50 freebsd servers for work, and have another 10 in my own posession
14:31 <@mattock> we used CentOS and OpenBSD mostly... and Ubuntu on the desktop
14:31 <@mattock> LTSP mostly
14:31 <@mattock> freebsd, neat!
14:31 <@mattock> are you familiar with Puppet?
14:32 < ecrist> heard of it, not famiilar with it, though
14:32 <@mattock> that's something worth checking out if you have tons of servers... 
14:32 < ecrist> we use ldap
14:32 <@mattock> we did, too
14:32 < ecrist> and network/pxe boot
14:33 <@mattock> puppet is great, just takes some adjusting to
14:33 < ecrist> aside from hardware-specific configs, everything that's common is in ldap now.
14:34 <@mattock> that's a good policy
14:36 <+openvpn2009> mattock, I will get the server up over the weekend
14:36 <@mattock> openvpn2009: great!
14:36 <@mattock> (the community site server)
14:36 <+openvpn2009> Either I can do the software installs or you guys can
14:37 <+openvpn2009> I will leave that decision up to you.
14:39 <@mattock> openvpn2009: have you discussed the server admin issues with francis? I mean is he ok with ecrist having root access, too?
14:39 <@mattock> I think that'd be a very good idea and I trust him
14:40 <@mattock> or shall I ask him?
14:42 < agi> re
14:42 <@mattock> agi: hi
14:43 < agi> mattock: re: Debian's experimental, yes we can use it
14:43 <@mattock> so is "experimental" completely separate from unstable, testing and stable?
14:44 <@mattock> or is experimental just the first phase?
14:44 < agi> yes
14:44 < agi> no, separate
14:44 <@mattock> ok, great!
14:45 < agi> and users are aware of the 'experimental' character of it
14:45 <@mattock> what stuff gets to "unstable"? is it just releases? or could it include snapshots from the "stable" (James') SVN tree?
14:45 < agi> it gets what I upload there
14:45 <@mattock> oh :)
14:46 < agi> it could include snapshot
14:46 < agi> s
14:46 <@mattock> what do you think would make most sense? I guess Debian stable should only include really stable stuff (=James' releases)
14:46 < agi> but having experimental to play with
14:46 <@mattock> I think experimental serves our purposes well
14:47 < agi> I'd rather upload to sid stuff that is consired a final product (all rc* were uploaded to sid)
14:47 < agi> *considered)
14:47 <@mattock> agi: I think that makes perfect sense
14:48 <@mattock> what about OpenVPN's feature-testing tree? E.g. an IPv6 tree... would it be feasible to have them in "experimental" under a different package name, e.g. "openvpn-ipv6"? 
14:49 < agi> it's not usual to have several flavours of the same software under the same repository
14:49 < ecrist> does anyone know Mathias Adree?
14:50 <@mattock> also, do you have some automated build system running? Or do you make the Debian packages manually?
14:50 < agi> there's not a rule againt that, but...
14:50 <@mattock> agi: I think starting with dazo's "allmerged" branch would be good enough
14:50 <@mattock> and having one Debian package
14:50 <@mattock> in experimental
14:51 < agi> I build them @home (i386) then upload to Debian where build daemon do the rest
14:51 < agi> mattock: yes, I agree
14:51 < agi> actually, dazo's IPv6 patch *is included* in Debian's package
14:51 <@mattock> ok
14:52 < cron2> agi: that's jjo's patch, not dazo - dazo is the authentication-plugin wrangler (IIRC)
14:52 < cron2> (jjo is not on IRC, as far as I know)
14:52 < agi> so for those features with real demand, and some testing already done, I don't mind including them
14:53 <@mattock> agi: I was just thinking that we'd need to build the packages automatically to make sure the latest versions are in "experimental" (with least manual effort)
14:53 <@mattock> any ideas how to accomplish that?
14:53 < agi> cron2: right, sorry. Debian had dazo's eurephia and jjo's IPv6
14:54 < agi> mattock: package uploads have to be gpg signed
14:54 <@mattock> ok, so some manual work is required in any case?
14:54 < cron2> so these two patches could move to "stable" pretty quickly, having had quite some testing :)
14:54 < agi> so manual intervention is required, yep
14:54 < agi> cron2: yep, sid and testing had them for some time now
14:55 < agi> Tue, 06 Oct 2009-> patches/jjo-ipv6-support.patch:
14:55 < agi> Thu, 19 Nov 2009-> debian/patches: Added eurephia.patch
14:55 <@mattock> agi: how difficult would it be to automate the Debian package build and push them to a custom repository?
14:56 < agi> should be pretty simple
14:56 <@mattock> that'd help testers use the latest version... and you would not have to do as much manual work
14:56 < agi> but we could loose some power testers from debian
14:57 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer]
14:57 <@mattock> true, unless we use "experimental", too
14:57 <@mattock> so my idea would be this:
14:57 < agi> do you *really* need to upload 1 revision each day?
14:57 < ecrist> probably weekly snapshots
14:57 < agi> 2 repos, ok
14:57 <@mattock> agi: how often can you upload new versions to Debian?
14:57 < agi> every hour?
14:57 <@mattock> =would be willing to
14:57 < agi> :)
14:58 < HotaruT> dinstall runs only twice a day? .. or is it 4 times already?
14:58 < agi> I guess I could manage ~ one a week
14:58 < agi> HotaruT: twice, yes. I was kidding :)
14:58 < ecrist> I'm willing/able to package a binary for freebsd weekly
14:59 < ecrist> the portstree takes longer than that to go live, unless you're good friends with a committer.
14:59 <@mattock> anyways, I think it would be beneficial to get the most recent version (e.g. a daily snapshot) to as many testers as possible as easily as possible
14:59 < ecrist> I'm good friends with a few committers, but don't really want to pushing to the ports tree that often.
14:59 < agi> mait can be done, no prob.
14:59 <@mattock> and I guess automated builds + custom repositories is the only way to achieve this 
14:59 < HotaruT> agi: ehm.. I see 4 pushs a day on my mirror.
15:00 <@mattock> ecrist: that'd be great!
15:00 < agi> HotaruT: then it'd be 4, I don't count them :)
15:00 <@mattock> agi: could help me a little with the Debian packaging if I get stuck? Also, any good starting points for the automated Debian package building?
15:01 < agi> mattock: you won't have to do (almost) anything
15:01 <@mattock> that's good news! what is it I _do_ need to do? :)
15:02 < agi> just a hook in the VCS of choice that triggers a package build with the new source
15:02 <@mattock> ok, so that'll be dazo's git then... however, I think SF.net does not allow arbitrary hooks to any VCS
15:03 <@mattock> git or otherwise
15:03 < ecrist> a hook can be as simple as a cronjob that pulls latest revision and compares to last...
15:03 < agi> it could also be pushed from an external host
15:03 < agi> right
15:03 <@mattock> yes, something like that
15:05 <@mattock> I guess we could easily use your packages (the dependency information etc.) as a good basis
15:05 <@mattock> anyways, it's getting late here... 
15:05 < agi> yes, I can help with all that
15:05 <@mattock> agi: do you hang around here daily?
15:05 < agi> mattock: mostly idling, but yes
15:06 <@mattock> ok, I'll be in touch!
15:06 < agi> ping me whenever you want
15:06 <@mattock> will do, thanks!
15:06 < agi> just don't expect to be online all the time :)
15:06 <@mattock> of course not ;)
15:06 < agi> ok, then talk to you later
15:07 < agi> time to have dinner
15:07 <@mattock> ecrist: I created a few new pages to the wiki
15:07 < agi> g'nite all
15:07 <@mattock> good night!
15:07 <@mattock> bye all!
15:08 < ecrist> ok
15:11 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
15:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
18:05 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 265 seconds]
--- Day changed Fri Feb 05 2010
02:17 -!- mattock [~samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
02:17 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:06 -!- mattock [~samuli@sparkgw.utu.fi] has quit [Ping timeout: 245 seconds]
03:10 -!- mattock [~samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
03:11 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:05 -!- mattock [~samuli@sparkgw.utu.fi] has quit [Ping timeout: 245 seconds]
04:25 -!- dazo_afk is now known as dazo
05:28 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:28 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
07:37 -!- reiffert [~thomas@mail.webersheim.de] has quit [Remote host closed the connection]
10:45 -!- dazo [~dazo@nat/redhat/x-brllznifwdqemddn] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:47 -!- dazo [~dazo@nat/redhat/x-trdcpaehnoxqbcwa] has joined ##openvpn-discussion
10:48 -!- dazo is now known as Guest86327
10:50 -!- Guest86327 is now known as dazo_
10:58 <+openvpn2009> mattock, you there
11:01 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
12:09 -!- dazo_ is now known as dazo
13:47 -!- dazo is now known as dazo_afk
15:18 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.]
--- Day changed Sat Feb 06 2010
02:18 -!- fkr [fkr@news.bytemine.net] has quit [Ping timeout: 240 seconds]
04:40 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
08:05 -!- fkr [fkr@news.bytemine.net] has joined ##openvpn-discussion
12:04 -!- HotaruT_ [massar@2001:638:208:3401:0:ff:fe00:16] has joined ##openvpn-discussion
12:06 -!- HotaruT [massar@bratwurst.unix-ag.uni-kl.de] has quit [Quit: Reconnecting]
12:06 -!- HotaruT_ is now known as HotaruT
12:41 -!- HotaruT [massar@2001:638:208:3401:0:ff:fe00:16] has quit [Quit: leaving]
13:17 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 264 seconds]
13:56 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
17:45 -!- fkr [fkr@news.bytemine.net] has quit [Ping timeout: 264 seconds]
--- Day changed Sun Feb 07 2010
04:50 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 264 seconds]
05:29 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
06:54 -!- fkr [fkr@news.bytemine.net] has joined ##openvpn-discussion
11:49 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer]
14:21 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
--- Day changed Mon Feb 08 2010
02:42 -!- fkr [fkr@news.bytemine.net] has quit [Quit: leaving]
02:44 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:45 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
02:51 -!- dazo_afk is now known as dazo
11:33 -!- dazo is now known as dazo_afk
15:24 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
15:24 -!- mode/##openvpn-discussion [+v Kaspx] by ChanServ
15:25 -!- openvpn_2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
15:25 -!- mode/##openvpn-discussion [+v openvpn_2009] by ChanServ
15:26 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 248 seconds]
15:28 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 272 seconds]
16:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
16:45 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
16:45 -!- mode/##openvpn-discussion [+v Kasx] by ChanServ
16:48 -!- openvpn_2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds]
16:48 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds]
16:53 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
16:53 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
18:06 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds]
18:06 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
18:06 -!- mode/##openvpn-discussion [+v Kaspx] by ChanServ
18:08 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 260 seconds]
18:10 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
18:10 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
23:20 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 260 seconds]
--- Day changed Tue Feb 09 2010
01:17 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:17 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:48 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
02:12 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 256 seconds]
02:22 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
02:46 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 240 seconds]
02:55 -!- dazo_afk is now known as dazo
04:33 -!- krzee [nobody@hemp.ircpimps.org] has joined ##openvpn-discussion
04:33 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host]
04:33 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
05:16 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
07:23 -!- Irssi: ##openvpn-discussion: Total of 9 nicks [0 ops, 0 halfops, 2 voices, 7 normal]
09:04 -!- mattock [~samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
09:04 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
10:02 -!- mattock [~samuli@sparkgw.utu.fi] has quit [Ping timeout: 245 seconds]
10:57 -!- dazo [~dazo@nat/redhat/x-trdcpaehnoxqbcwa] has quit [Read error: Connection reset by peer]
10:58 -!- dazo [~dazo@nat/redhat/x-tnjwdjqvamlntvrb] has joined ##openvpn-discussion
11:07 -!- dazo is now known as dazo_afk
13:26 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
19:20 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
19:43 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer]
--- Day changed Wed Feb 10 2010
01:06 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:07 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
02:22 -!- cron2 [~gert@blue.greenie.muc.de] has quit [Ping timeout: 248 seconds]
02:23 -!- cron2 [~gert@blue.greenie.muc.de] has joined ##openvpn-discussion
04:12 -!- dazo_afk is now known as dazo
05:55 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer]
05:55 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
05:55 -!- mode/##openvpn-discussion [+v Kaspx] by ChanServ
06:57 <@mattock> Git repo enabled, some developer documentation already available: http://www.secure-computing.net/wiki/index.php/OpenVPN/Developer_documentation
06:57 < vpnHelper> Title: OpenVPN/Developer documentation - Secure Computing Wiki (at www.secure-computing.net)
10:20 -!- d12fk [~heiko@vpn.astaro.de] has quit [Read error: Connection reset by peer]
10:22 -!- d12fk [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
11:17 -!- d12fk [~heiko@vpn.astaro.de] has quit [Read error: Operation timed out]
11:18 -!- d12fk [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
12:22 -!- dazo is now known as dazo_afk
16:31 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
--- Day changed Thu Feb 11 2010
00:29 -!- d457k [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
00:30 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 260 seconds]
01:54 -!- dazo_afk is now known as dazo
04:38 -!- mattock [~samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
04:38 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:42 -!- mattock [~samuli@sparkgw.utu.fi] has quit [Ping timeout: 245 seconds]
06:05 -!- d303k [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
06:06 -!- d457k [~heiko@vpn.astaro.de] has quit [Ping timeout: 246 seconds]
07:05 -!- Irssi: ##openvpn-discussion: Total of 8 nicks [0 ops, 0 halfops, 2 voices, 6 normal]
09:54 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
09:54 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
10:21 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer]
10:28 < ecrist> mattock: http://www.secure-computing.net/wiki/index.php/User_talk:Ecrist#OpenVPN_Notes
10:28 < vpnHelper> Title: User talk:Ecrist - Secure Computing Wiki (at www.secure-computing.net)
10:28 < ecrist> in case I can't be here in 2.5 hours
10:28 <@mattock> ecrist: I'll copy my notes there, too
10:29 <@mattock> I'll still do a little research before the meeting, but I have stuff ready
11:04 -!- dazo is now known as dazo_afk
11:11 -!- HotaruT [massar@bratwurst.unix-ag.uni-kl.de] has joined ##openvpn-discussion
11:18 <@mattock> dazo_afk: will you attend the meeting today?
11:27 <@mattock> some forum notes: http://www.secure-computing.net/wiki/index.php/User:Mattock
11:27 < vpnHelper> Title: User:Mattock - Secure Computing Wiki (at www.secure-computing.net)
11:31 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:31 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
11:56 -!- reiffert [~thomas@mail.webersheim.de] has joined ##openvpn-discussion
13:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
13:00 < ecrist> Quoting Chef, 'Hello, children!'
13:00 < jamesyonan> Hi everyone
13:02 <@mattock> hi james!
13:02 < jamesyonan> hi
13:03 <@mattock> dazo has been awfully quiet, I hope he'll attend too
13:03 <@mattock> shall we begin?
13:03 < ecrist> sure
13:03 -!- rob0 [~rob0@tuxaloosa.org] has joined ##openvpn-discussion
13:03 -!- upb [cmpxchg@88.80.13.92] has joined ##openvpn-discussion
13:03 < ecrist> dazo was around about 5 hours ago, haven't seen him since.
13:04 <@mattock> ecrist: ok
13:04 <@mattock> perhaps I can fill in for him... at least tell the basics
13:04 <@mattock> so a couple of things I'd like to mention
13:05 <@mattock> I did take a quick look at the community site forum software alternatives
13:05 <@mattock> a preliminary report is here: http://www.secure-computing.net/wiki/index.php/User:Mattock#FluxBB
13:05 < vpnHelper> Title: User:Mattock - Secure Computing Wiki (at www.secure-computing.net)
13:06 <@mattock> also, I started writing developer documentation here: http://www.secure-computing.net/wiki/index.php/OpenVPN/Developer_documentation
13:06 < vpnHelper> Title: OpenVPN/Developer documentation - Secure Computing Wiki (at www.secure-computing.net)
13:06 <@mattock> and IRC meeting logs are linked to from here:  http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings
13:06 < vpnHelper> Title: OpenVPN/IRC meetings - Secure Computing Wiki (at www.secure-computing.net)
13:06 <@mattock> my idea was to use this wiki until the community site is up
13:06 <@mattock> the community site server is now up, btw
13:07 < ecrist> neat
13:07 <@mattock> I intended to start installing trac on monday, but something came up so I'll start working on it tomorrow
13:07 <@mattock> (unless something else comes up :)
13:08 <@mattock> also, dazo initialized the "testing" git repo in SF.net 
13:08 < ecrist> why do you want LDAP auth in the forum software?
13:08 <@mattock> ecrist: so that all services (trac, forums, whatever) can use the same credentials
13:09 < cron2> hi
13:09 <@mattock> cron2: hi
13:10 <@mattock> one more thing about the testing tree... dazo said he'd initially include the ipv6 patches and eurephia patches
13:11 <@mattock> he also promised to put stuff into git in next few days 
13:11 <@mattock> a few days ago :)
13:12 <@mattock> I think my status update is now finished :)
13:13 < ecrist> fwiw, if we chose to go with mediawiki at a later date, it does support ldap fairly well
13:13 < ecrist> the only exception is admins, they need to have corresponding mediawiki accounts
13:13 <@mattock> ecrist: true
13:13 < jamesyonan> Where is eurephia discussued? -- the http://www.eurephia.net/ site isn't working for me
13:14 <@mattock> it seems that most applications require internal user accounts, so syncing with LDAP is necessary
13:14 <@mattock> james, seems to be broken for me, too
13:14 < ecrist> maybe that's what dazo is working on. heh
13:15 <@mattock> could be :)
13:15 <@mattock> are there any things you'd like to discuss in detail?
13:15 < ecrist> looks like it's been broken for a while, even the google cache shows the error.  That snapshot is from Feb 5th.
13:15 < ecrist> just the forum software, what you found
13:16 <@mattock> ok
13:16 <@mattock> I checked most (not all) PHP-based OSS forum applications against the five requirements in my wiki page (see above)
13:17 <@mattock> phpbb and fudforum seemed to have it all
13:17 <@mattock> even mailing list bridging
13:17 <@mattock> I don't know of the quality of the bridging feature (or LDAP auth or anything else)
13:17 <@mattock> but those are worth better look
13:17 <@mattock> then there are a few other potential solutions we could use
13:18 <@mattock> ... as I did not yet check all of the OSS solutions
13:18 <@mattock> ecrist: what about the commecial alternatives?
13:19 < ecrist> one thing I really dislike about phpBB, is it currently outputs the session id in the URL, and it doesn't have good RSS support.  We're doing it now, but the feed is second-rate, IMHO.
13:20 <@mattock> do you think that good RSS support is essential?
13:20 < ecrist> in regard to commercial software, vBulletin is the only one that has a solid mailing list gateway that is popular.  In terms of raw features for the price, Invasion Power Board seems pretty nice, as well.
13:20 < ecrist> I do.
13:21 <@mattock> why? :)
13:21 < ecrist> Most of the fourms I participate in have RSS feeds I watch.  Those that don't have RSS feeds, I find I don't participate as much in.
13:21 < ecrist> but, that's just me.
13:21 < ecrist> also, integrating into something like our IRC bot is difficult without a good RSS feed.
13:22 < ecrist> sure, I could do raw sql, since I currently control the server, but that's a hack, at best.
13:22 <@mattock> I think that's worth a requirement, I'll add it to the wiki page
13:23 < rob0> FWIW I don't like the idea of proprietary software for a free software project's community site ... just thought that might be worthy of mention.
13:23 < ecrist> why not?
13:24 < ecrist> personally, I'm a fan of using the right tool for the job, regardless of whether it's free or not.
13:25 < ecrist> the alternative, is to fix/write the code we need for the software that's chosen
13:25 <@mattock> I think we should use OSS if possibile... and revert to commercial offerings only if they're clearly better. And if there's no fear of vendor lock-in
13:26 <@mattock> by better I mean "OSS applications can't get the job done"
13:26 < ecrist> that pretty much sums up what I had to contribute.
13:27 <@mattock> ecrist: perhaps I'll check the remaining OSS forum application and then we'll take a better look together
13:27 <@mattock> you got more experience in forum maintanance than I
13:27 <@mattock> so I'd appreciate all the feedback you can provide
13:27 < ecrist> most of my experience is with phpBB
13:28 < ecrist> s/most/almost all\/vast majority/
13:28 <@mattock> then again, I have no experience :) 
13:28 <@mattock> so you're clearly the expert here ;)
13:29 < jamesyonan> would the forum be separate from mailing lists or would there be post replication between them?
13:29 <@mattock> it seems that depends...
13:30 < ecrist> the goal is to try and support that, at least for a trial, and judge from there.
13:30 < ecrist> there seems to be a mix of opinion on how well it works, and how much noise there is.
13:31 <@mattock> do we want to emphasize the mailing list <-> forum integration? 
13:31 <@mattock> meaning, do we make it a "must have"
13:31 <@mattock> that'd probably cut down the potential software choices
13:31 < reiffert> I dont think that having this sync will keep the quality high.
13:31 < jamesyonan> I would also be concerned about noise if we integrated them
13:32 < jamesyonan> more so with openvpn-devel
13:32 < rob0> ha, there's already a lot of noise in -users.
13:32 < ecrist> I dont think there would be an openvpn-devel interface
13:32 <@mattock> ecrist: agreed
13:32 < ecrist> honestly, there is more noise on the mailing list than there is on the forum
13:32 < ecrist> probably due to the moderation
13:33 <@mattock> what about matching a forum to a mailinglist... should we create new mailing lists for each new forum or what?
13:33 < jamesyonan> maybe forum <-> mailing list integration only makes sense when moderation is in place
13:34 <@mattock> you mean per-post moderation?
13:35 < ecrist> I was thinking of having a specific subforum for the mailing list, and only that subforum would be interfaced to both 
13:35 < ecrist> i.e. an OpenVPN-users Mailing List forum
13:36 <@mattock> would there be other more specific user forum boards too?
13:36 < ecrist> there could be.
13:36 < ecrist> http://www.ovpnforum.com/
13:36 < vpnHelper> Title: OpenVPN Forum Index page (at www.ovpnforum.com)
13:36 < ecrist> that's what we have now
13:37 <@mattock> things would get hairy if we had, say, 5 forum boards and needed to match them with 5 mailing lists
13:37 <@mattock> nobody would want to join those mailing lists - unless the mailing list functionality was integrated directly into the forum software
13:38 <@mattock> meaning they would not be separate... I think some forum applications support this
13:38 < ecrist> I think we're only concerned with one right now....
13:38 < ecrist> and, really, maybe not even one.
13:39 <@mattock> I'm just wondering whether it makes sense to have the "Users mailing list forum boards" and then a bunch of other, more specific user forum boards...
13:39 <@mattock> I fear forum users would not know where to post
13:40 < ecrist> now you're into the differences in the two cultures
13:40 <@mattock> I guess so
13:40 < ecrist> forums are compartmentalized threads, whereas mailing lists are a general broadcast.
13:41 < ecrist> what I would suggest is to setup a forum, or not, we can keep operating the one we have, too.
13:41 < ecrist> if we want to play with an interface, we can, but there's no requirement.
13:42 <@mattock> a sync from the mailing lists to forums would probably make sense, though
13:42 <@mattock> so that all content is searchable
13:44 <@mattock> anyways, I'll take a better look at the alternatives
13:44 <@mattock> ok, anything else we should discuss?
13:44 <@mattock> (too bad dazo could not share his git adventures)
13:44 < ecrist> not that I'm aware of.
13:45 <@mattock> oh, one thing I may not have mentioned... agi agreed to put the "testing" version of OpenVPN into Debian "experimental" repos ~once a week
13:46 < ecrist> do you know Mathias?  He does freebsd ports currently, I can contact him to see if he'd either do the same, or give me maintainer for -devel
13:47 <@mattock> he also agreed (if I remember correctly) to help me out when/if I start working on the Debian packaging (e.g. daily testing snapshots)
13:47 <@mattock> ecrist: nope, I don't
13:47 < cron2> ecrist: neither do I, sorry
13:48 <@mattock> does FreeBSD ports support "experimental"  software similarly to Debian?
13:48 < ecrist> I've had conversations with him in the past, so I'll talk to him, as well.
13:48 < ecrist> mattock: yes
13:48 <@mattock> I mean, isn't the basic ports stuff pretty stable
13:48 <@mattock> ?
13:48 <@mattock> ok, great!
13:48 < ecrist> that's what the -devel suffix is for
13:48 <@mattock> I'd need to contact Fedora and Ubuntu maintainers, too
13:49 <@mattock> it'd be good to have "testing" OpenVPN in wide circulation
13:49 < ecrist> If I can't do weekly, I can probably do biweekly or monthly.
13:49 <@mattock> I think that'd be great! If we want to minimize the latency we need to create daily snapshots and distribute them through our custom repos anyways
13:50 <@mattock> ok, I think that's all for today...
13:58 -!- cron2 [~gert@blue.greenie.muc.de] has quit [Quit: Lost terminal]
14:06 <@mattock> I'll write a summary tomorrow
14:08 -!- cron2 [~gert@kirk.greenie.muc.de] has joined ##openvpn-discussion
14:14 < reiffert> http://motorsport-aktuell.com/formel-1/news/vorzeitiges-ende-fuer-virgin-11915.html
14:14 < vpnHelper> Title: MOTORSPORT aktuell: Vorzeitiges Ende für Virgin (at motorsport-aktuell.com)
14:14 < reiffert> ww
14:14 < ecrist> man gmultipath
14:14 < ecrist> oops, sorry
14:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan]
14:54 -!- rob0 [~rob0@tuxaloosa.org] has left ##openvpn-discussion ["bye"]
15:15 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
16:07 -!- upb [cmpxchg@88.80.13.92] has left ##openvpn-discussion []
17:22 -!- Netsplit *.net <-> *.split quits: cron2
17:26 -!- Netsplit over, joins: cron2
21:18 -!- d12fk [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
21:18 -!- d303k [~heiko@vpn.astaro.de] has quit [Write error: Broken pipe]
--- Day changed Fri Feb 12 2010
05:52 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:52 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
12:37 -!- dazo_afk [~dazo@nat/redhat/x-tnjwdjqvamlntvrb] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:06 -!- cervicek [~cervicek@rzlx0901.hs-esslingen.de] has joined ##openvpn-discussion
17:53 -!- krzee [nobody@hemp.ircpimps.org] has joined ##openvpn-discussion
17:53 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host]
17:53 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
18:10 -!- reiffert [~thomas@mail.webersheim.de] has quit [Ping timeout: 260 seconds]
18:16 -!- reiffert [~thomas@mail.webersheim.de] has joined ##openvpn-discussion
18:35 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 245 seconds]
19:03 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds]
--- Day changed Sat Feb 13 2010
02:16 -!- reiffert [~thomas@mail.webersheim.de] has left ##openvpn-discussion []
13:06 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
15:00 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
--- Day changed Sun Feb 14 2010
01:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:53 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
06:33 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
14:04 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving]
14:20 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
20:56 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
21:55 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
--- Day changed Mon Feb 15 2010
01:52 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:52 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
02:43 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
05:19 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
05:35 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
08:01 -!- dazo_afk [~dazo@nat/redhat/x-tdbhaajxdrkprlfl] has joined ##openvpn-discussion
08:01 -!- dazo_afk is now known as Guest44788
08:02 -!- Guest44788 is now known as dazo
08:45 -!- dazo [~dazo@nat/redhat/x-tdbhaajxdrkprlfl] has quit [Read error: Connection reset by peer]
08:48 -!- dazo [~dazo@nat/redhat/x-bjkcerkabsnydzqk] has joined ##openvpn-discussion
08:49 -!- dazo is now known as Guest28846
11:07 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org]
11:49 -!- Guest28846 is now known as dazo
12:31 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
12:31 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
15:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
16:04 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
17:03 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
17:27 -!- dazo is now known as dazo_afk
20:12 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
--- Day changed Tue Feb 16 2010
02:25 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:25 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
02:39 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
02:51 -!- dazo_afk [~dazo@nat/redhat/x-bjkcerkabsnydzqk] has quit [Read error: Operation timed out]
03:50 -!- dazo_afk [~dazo@nat/redhat/x-eotqvidadipgeorz] has joined ##openvpn-discussion
03:50 -!- dazo_afk is now known as Guest97655
05:16 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
06:10 -!- Guest97655 is now known as dazo
08:01 -!- mattock [~samuli@sparkgw.utu.fi] has joined ##openvpn-discussion
08:01 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
10:03 -!- mattock [~samuli@sparkgw.utu.fi] has quit [Ping timeout: 245 seconds]
11:30 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer]
13:15 -!- dazo is now known as dazo_afk
18:26 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving]
21:36 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
23:44 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 265 seconds]
--- Day changed Wed Feb 17 2010
01:52 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:52 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:19 -!- dazo_afk is now known as dazo
10:08 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
12:19 -!- dazo is now known as dazo_afk
18:03 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
18:21 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving]
--- Log closed Wed Feb 17 23:34:01 2010
--- Log opened Thu Feb 18 03:42:41 2010
03:42 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
04:29 -!- dazo_afk is now known as dazo
--- Log closed Thu Feb 18 06:28:54 2010
--- Log opened Thu Feb 18 08:29:18 2010
08:29 -!- dazo_afk is now known as dazo
10:49 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
10:49 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
11:22 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
11:22 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
11:44 -!- dazo is now known as dazo_afk
12:15 -!- dazo_afk is now known as dazo
13:00 <@mattock> almost there...
13:00 < dazo> :)
13:01 < cron2> hi folks
13:02 <@mattock> hi cron2
13:02 <@mattock> but where is James? :)
13:03 < dazo> mattock:  no spies you can send out for him?
13:03 <@mattock> I have one
13:03 < dazo> :)
13:03 <@mattock> but perhaps we can wait for a couple of minutes and then get worried
13:03 < dazo> no prob :)
13:05 <@mattock> btw. I sent a short email regarding testers/testing procedures to devel a few minutes ago
13:05  * dazo checks mail
13:05 <@mattock> we got our first volunteer tester, btw
13:05 < dazo> \o/
13:05 < cron2> wohoo
13:06 <@mattock> do you think it'd be useful to have wiki pages for each _dedicated_ tester and his/her setup?
13:06 < cron2> yes
13:06 <@mattock> by dedicated I mean somebody who's willing to keep his wiki page (and openvpn installation) updated
13:07 < cron2> sounds very useful to be able to answer things like "who is using OpenBSD and could test this"?
13:07 < cron2> or "who is doing point-to-multipoint tap" etc
13:08 < cron2> it would be good to give them a template for this data, so the pages would look halfway alike
13:08 <@mattock> good idea
13:09 < dazo> From a development POV ... which features (and versions) being tested are probably more useful .... but the combination of features are also good to know when fixing bugs
13:10 <@mattock> could we assume that these dedicated testers are always using the latest "allmerged"? Or at least try it out before reporting problems
13:10 < dazo> mattock:  I think that should be a requirement, if we can enforce that ... it would be really beneficial to have them test that branch
13:11 <@mattock> I think we can expect them to use the latest version... after all, we're not speaking of people how randomly stumble upon problems, but the more dedicated type
13:12 <@mattock> after all, we can (and need to) make sure all developer follow same coding guidelines
13:12 <@mattock> I don't see much of a difference there
13:12 < dazo> if they could report the latest commit id of their allmerged branch, that would indicate the version
13:13 <@mattock> yep
13:13 < dazo> that's to identify if we have regressions as well
13:13 < cron2> yep
13:13 < dazo> (we know when it worked, and when it broke ... then bisect would be the next task to nail the commit which made it fail
13:13 < dazo> )
13:15 <@mattock> yeah, and the tester (if really dedicated) could even test older versions to pinpoint exactly when things went bad
13:15 <@mattock> and when we know his setup/features he uses, it shouldn't be that difficult to pinpoint the problem
13:15 <@mattock> I guess :)
13:15 < dazo> mattock:  yeah, the bisect feature in git can help you pin-point which versions to try to test out
13:16 < dazo> (so that you don't have to try "random" commits in between those two borders)
13:16 -!- tw [~silverfis@c-98-223-105-100.hsd1.in.comcast.net] has joined ##openvpn-discussion
13:16 <@mattock> (I sent my spy after James a while back, but still no response)
13:17 <@mattock> meanwhile, could you guys take a look at this: http://users.utu.fi/sjsepp/openvpn/Community_Authentication.dia or
13:17 <@mattock> http://users.utu.fi/sjsepp/openvpn/Community_Authentication.png (does not show 100% correctly)
13:17  * cron2 looks at png
13:17 <@mattock> it's a plan for central authentication services for the community site + other sites in the future (e.g. OpenVPN e.v.).
13:18 <@mattock> I found a nice Java webapp for managing user self-service registrations to LDAP: http://code.google.com/p/pwm/
13:18 < vpnHelper> Title: pwm - Project Hosting on Google Code (at code.google.com)
13:19 < dazo> mattock:  why not consider OpenID on the user front-end?
13:19 <@mattock> so basically users would register themselves to LDAP and all community services would use it work authentication
13:19 <@mattock> it's definitely a possibility
13:19 <@mattock> it would make things simpler
13:19 <@mattock> however, I have not looked at application support for it
13:19 <@mattock> Trac has openid support, but I'm not sure about the rest
13:20 < dazo> but I do see that if there's an API between all those "services", LDAP will be beneficial
13:20 < dazo> with OpenID you still need to register an account .... but you then connect that account to an OpenID account 
13:20 < cron2> if we go for LDAP, I'd go for a combination of 2+3+4
13:20 < cron2> LDAP at openvpn corp, and "other sites" can chose to get "local auth" or "use master ldap" or "use replicated slave ldap server locally"
13:21 < cron2> no exposure to OpenID yet
13:21 <@mattock> cron2: yes, I think that's a good idea
13:21 <@mattock> basically other community sites could either use the central LDAP server (and risk getting into trouble if that's offline) or have their own replicas
13:22 < dazo> that sounds good to me
13:22 < cron2> or maintain their own user authentication data, if they don't trust "the central authority"
13:22 <@mattock> they could, but then again their own replica would solve that
13:22 <@mattock> at least for the most part
13:23 < ecrist> ldap is very easy to replicate, as well
13:23 < cron2> yes
13:23 <@mattock> any experience with OpenLDAP and/or ApacheDS?
13:24 < ecrist> I do
13:24 <@mattock> which? or both?
13:24 < ecrist> http://www.secure-computing.net/wiki/index.php/OpenLDAP
13:24 < vpnHelper> Title: OpenLDAP - Secure Computing Wiki (at www.secure-computing.net)
13:24 < dazo> no experience, except from end user .... but here's another one as well .... http://directory.fedoraproject.org/
13:24 < vpnHelper> Title: 389 Directory Server (Open Source LDAP) (at directory.fedoraproject.org)
13:24 < ecrist> I have 'enough' OpenLDAP experience
13:25 <@mattock> ecrist: me too :)
13:25 <@mattock> or rather, enough _LDAP_ experience
13:25 < dazo> ecrist:  nice! :)  It will make me want to try to setup an LDAP server now :)
13:26 < cron2> we use OpenLDAP at the company with good success, but I'm just a user there, so no idea about its maintainability
13:26 < ecrist> dazo, I use ldap for system auth, sudo, jabber, mediawiki, and tons of other stuff.
13:27 < dazo> ecrist:  I know I will need to setup a shared address book at some point ... so LDAP is coming :)  ... just avoided it so far :-p
13:27 < ecrist> as a matter of fact, Dell's DRAC6 supports LDAP auth, so all our new hardware BMC checks LDAP for creds and access privs.
13:27 < dazo> nice
13:28 < cron2> wow
13:29 <@mattock> my local agent (Andrew) said James has disappeared. He has tendency to forget things, but he does not mean anything bad by it.
13:30 <@mattock> I suggest we send the patch issues to him by email - I'm sure embarrasment (of forgetting this meeting) will make him a little more responsive :)
13:32  * dazo recognise similar habits on himself ............
13:32 < cron2> hehe
13:32 <@mattock> I and Andrew decided to remind him of these meeting the day before and a few hours before the meeting
13:32 < cron2> so which day is the "James does reviews" day?
13:32 <@mattock> today/tomorrow was the goal
13:33 < cron2> so you need to remind him tomorrow :-) - quite a lot has happened last week
13:33 <@mattock> ecrist: do you mind checking out the LDAP schema I build? I have not _designed_ any schemas myself earlier
13:33 <@mattock> cron2: will do
13:34 < ecrist> sure
13:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
13:34 <@mattock> hi james!
13:34 < cron2> hey \o/ :-)
13:34 < dazo> talking 'bout the sun! :)
13:34 < jamesyonan> Hi everyone
13:34 < dazo> Hi! :)
13:34 <@mattock> we were afraid you had forgotten the meeting :)
13:34 <@mattock> which was of course not the case, right? ;)
13:35 < jamesyonan> sorry, I was just working late last night
13:35 <@mattock> no probs
13:35 <@mattock> ok, I'll let you guys discuss the patch/development issues
13:36 < dazo> jamesyonan:  I'll throw in the first question .... have you seen the -devel mailing today?  It's been a discussion about "FQDN for routes should expand to all IPs"
13:37 < dazo> jamesyonan:  and the usage of get_random() when returning it in getaddr() .... Karl O. Pinc managed to put words on the things which I do share .... but I'd like to hear your opinion about it as well
13:38  * cron2 doesn't like the way it's done, but given the way the existing code is built, it's hard to do it differently without larger intrusions
13:40 < jamesyonan> So is the idea to not randomize in the client, and let the DNS server control the order?
13:41 < dazo> jamesyonan:  yes, as most DNS servers today either do randomisation itself or round-robin 
13:41 < ecrist> randomizing is silly, since BIND (and some others) do round-robin already
13:42 < dazo> jamesyonan:  but of course, if taking it from the /etc/hosts, it's another issue .... so I'd probably at least recommend making this configurable
13:42 < jamesyonan> but what happens when DNS results are cached by an intermediate server?
13:42 < cron2> lemme test
13:43 < ecrist> I would suggest letting DNS do it's job, however that is.
13:44 < cron2> powerdns_recursor randomizes cached data, unbound does not
13:45 < cron2> bind randomizes
13:46 < dazo> sounds like when DNS is involved, it would be solved by the DNS server .... I remember having configured "simple load-balancing" with BIND-4.x.x as well, using round-robin
13:46 < dazo> (which was a decade ago)
13:47 < jamesyonan> to partially answer my own question, the recent remote-random-hostname option can be used to defeat caching even through DNS servers that ignore TTL
13:47 < cron2> remote-random-hostname?
13:47 < cron2> ah
13:47 < dazo> cron2:  came in 2.1_rc20
13:49 < cron2> it's not in openvpn.8 *complain*
13:49 < dazo> +/*
13:49 < dazo> + * Add a random string to first DNS label of hostname to prevent DNS caching.
13:49 < dazo> + * For example, foo.bar.gov would be modified to <random-chars>.foo.bar.gov.
13:49 < dazo> + * Of course, this requires explicit support in the DNS server.
13:49 < dazo> + */
13:50 < dazo> commit 8e9666d57550 / r4843
13:50 < cron2> I found it in the source, but it's not documented overly well :)
13:51 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:51 -!- mode/##openvpn-discussion [+v Kasx] by ChanServ
13:51 < dazo> jamesyonan:  but that do not really answer if we really should have get_random() in getaddr() ... or did I misunderstand?
13:51 < cron2> does it work?  I've seen this as a major problem actually(!) with people trying to poison DNS caches
13:52 < jamesyonan> well the fact that needs explicit support in the DNS server limits its usage
13:53 < cron2> what is the basic idea behind DNS randomization in OpenVPN?  to be able to specify "remote openvpn.my.corp.net" and have that DNS-balance to 5 OpenVPN server machines?
13:54 < jamesyonan> DNS cache poisoning shouldn't be a risk for OpenVPN due to SSL cert verification
13:54 < dazo> jamesyonan:  yes, that was my impression as well .... okay, I can write a patch for it and mail it to the -devel list 
13:54 < dazo> jamesyonan:  well, but you have those users who chose to not use certificates as well ... do we care about them?
13:54 < jamesyonan> What if we make the randomization behavior depend on the remote-random setting?
13:55 < dazo> that's a good approach
13:55 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 265 seconds]
13:55 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 265 seconds]
13:55  * cron2 still tries to understand the scenarios in which this would be beneficial
13:55 < cron2> dazo: nah.  that way you have more code and still the get_rand() in there
13:55 < dazo> so if remote-random is enabled in config ... then we enable get_random()
13:55 < cron2> all you have won is "more complicated code"
13:56 < cron2> (plus "a function that has no access to the config structure needs to look at a config var")
13:56 < cron2> worst of both worlds
13:56 < jamesyonan> right, but what do you tell people that depend on the old behavior?
13:56 < jamesyonan> isn't it just a trivial if statement?
13:57 < dazo> cron2:  I'm willing to look into this ... iirc, getaddr() isn't called from many places ... and I also vaguely remember that those places mostly had the option struct availabel
13:57 < cron2> it's a trivial if *if* you have access to the config struct, which getaddr() doesn't have
13:57 < cron2> I don't see the benefit
13:57 < dazo> jamesyonan:  I think cron2 is worried about having to rewrite more pieces to get the option struct into getaddr()
13:57 < cron2> if we want randomization, leave it there
13:57 < cron2> if we do not want randomization, kick it
13:57 < cron2> but not both
13:58 < cron2> and document the change in the release notes
13:58 <@mattock> jamesyonan: couldn't we just document the change... 
13:58 <@mattock> cron2: you beat me on this :)
13:58 < jamesyonan> I have no personal attachment to the randomization behavior -- I just want to look out for the possibility that people depend on it
13:59 < cron2> getaddr() is called in about 26 places in the code
13:59 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:59 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
13:59 < dazo> well, the current situation is .... get_random() can potentially mess up DNS servers round-robin/random features ... but might benefit those only depending on static host files 
14:01 <@mattock> is it possible that removing the randomization feature break something which people can't fix by changing configuration somewhere?
14:01 < cron2> I'm still waiting for someone to explain to me which scenarios this is used at all :-)
14:02 < cron2> "remote $host" with multiple addresses could be resolved with multiple "remote" and remote-random
14:02 < dazo> the /etc/hosts approach might not be a big problem ... but some embedded environments might not like that change
14:02 <@mattock> cron2: those will be reported when the feature is removed :)
14:04 < jamesyonan> the OpenVPN project has a long tradition of backward compatibility on even the most minor features :)
14:05 <@mattock> and we all know where that policy lead Microsoft ;)
14:05 < dazo> jamesyonan:  what about that we send out some information on the mailing lists .... "We plan to change this behaviour, will this affect you?"
14:05 <@mattock> dazo: sounds like a good idea
14:05 < dazo> there might even be some customers you can ask the same question as well
14:06 < dazo> and if we don't get any responses, then nobody cares .... and if they complain afterwards .... well, then it's easy to say "but we asked you for feedback"
14:06 <@mattock> and the change should be very visible in the release notes
14:06 < dazo> exactly!
14:06 < cron2> yes
14:07 <@mattock> the change should go through quite a lot of testing in "testing" tree, "stable" SVN tree and in beta and RC phases
14:07 <@mattock> I'd be surprised if somebody did not spot it during that time AND it was important to the users
14:08 < dazo> +1
14:09 < dazo> jamesyonan:  I do share your worries in regards to backward compatibility, I really do .... but if this is a feature nobody really "cares" about, then it is less clever to bloat the code with "useless" code
14:09 < jamesyonan> I don't see what the big deal is in just adding a new GETADDR_x flag for this
14:09 < dazo> oki ... I'll produce a patch and mail it today
14:09 < dazo> one more question
14:10 < dazo> This is openssl related .... X509_STORE_CTX and ctx->current_cert->sha1_hash ..... is that always a valid pointer? 
14:10 < cron2> jamesyonan: large parts of openvpn code are already overcomplicated with too many options, and options that set other options and such
14:11 < dazo> I've searched for this ... looked in man pages and in O'Reilly's OpenSSL book ... but not found anything clear
14:11 < cron2> for people trying to undestand the code, every extra option (especially indirect ones, config file options setting GETADDR_... flags) makes life harder
14:12 < dazo> it could really be solved as a compile-time configuration, for those really needing this feature
14:12 < dazo> it would be an #ifdef ... but that's not confusing most users
14:13 < jamesyonan> Yes, I believe that OpenSSL always defines sha1_hash on the cert objects
14:13 < cron2> dazo: in that case "ACK" :-)
14:13 < jamesyonan> BTW that code is essential for preventing various kinds of attacks on the mid-session TLS renegotiation
14:13 <@mattock> what if we make this randomization feature optional, but disabled by default and see what happens?
14:14 < dazo> jamesyonan:  the question was in regards to cron2's comment about it when he reviewed the eurephia patch .... so that means I don't need to make an extra check if that element is valid
14:14 < dazo> jamesyonan:  thanks!
14:14 < dazo> (btw! the eurephia website is up again ... sf.net had upgraded PHP and somehow and it broke my code, I had not caught that)
14:15 < dazo> mattock:  will you mention in the meeting minutes that cron2 gave his ACK to the eurephia patch based on the openssl discussion?
14:16  * dazo wants to be sure the ACK is documented
14:16 <@mattock> in the summary you mean?
14:16 < dazo> yeah
14:16 <@mattock> will do
14:22 < dazo> anything else we need to discuss today?
14:22 < ecrist> mattock: find anything on forum software?
14:22 <@mattock> should we have a process for removing old, deprecated features? I share cron2's concern that making everything a configuration option will eventually result in unnecessary complexity
14:23 <@mattock> ecrist: I spent my time setting up the server, so no
14:23 <@mattock> community server I mean
14:24 < dazo> yes, I agree to have a remote feature process ... that will be needed in the future anyway
14:25 <@mattock> something like this: when a feature is deprecated, make it a configuration option but disabled by default. If users complain, the change can be rolled back. If they don't, we can then remove it completely. And if the users complain then, we can put it back in, if the arguments in favor are good enough.
14:26 <@mattock> what do you think?
14:26 < dazo> I would probably prefer having it as an #ifdef
14:27 < cron2> I read mattock's proposal as "having it #ifdef'ed" - and I would agree with that
14:27 <@mattock> I was thinking about this on an abstract level, as I don't know the difference between an #ifdef and a configuration option :)
14:27 < dazo> or else it would be a lot of extra coding needed to pass the configuration to all parts of the functions where this is relevant
14:27 <@mattock> no C-fu for me
14:27 < dazo> :)
14:28 <@mattock> build-time option then
14:28 < dazo> I agree, when having it #ifdef'ed  :)
14:28 < cron2> mattock: yes, #ifdef is build-time
14:28 < cron2> and less intrusive in the code (because the knowledge "we don't want this" doesn't need to be passed around until it hits the relevant code parts)
14:29 <@mattock> jamesyonan: what do you think about this? I think this way users would have quite a lot of time (a year?) to react before "their" features get removed.
14:30 <@mattock> given all the delays before "testing" code becomes a stable release
14:30 <@mattock> and the delay between deprecating a feature and removing it altogether
14:32 < jamesyonan> re: #ifdef policy on feature deprecation -- yes I think that makes sense
14:33 <@mattock> what kind of release cycle are we aiming for? 6 months? 12 months?
14:34 <@mattock> or "when it's ready" release cycle
14:34 <@mattock> :)
14:34  * dazo just updated the git tree
14:34 < jamesyonan> I would say "when it's ready" but leaning more towards 12 months
14:34  * dazo just realised the randomize patch sneaked in ... ugh
14:35 < cron2> dazu: huh?
14:35 < cron2> oh, you committed to allmerged?
14:35 < dazo> cron2:  yeah, I wanted to wait for ACK's on it :)
14:35  * cron2 just sent a NAK
14:36 < dazo> cron2:  heh ... I merged it in, by a mistake
14:36 < cron2> code duplication detected :)
14:36 <@mattock> we could keep a deprecated feature around (but disabled) for one full release cycle and then dump it
14:36 <@mattock> shall I document this feature deprecation policy in the developer documentation page?
14:36 < dazo> mattock:  you just gave me a reason to create a deprecated_features branch ;-)
14:36 <@mattock> dazo: good to hear, we need all the branches we can get :)
14:37 < dazo> mattock:  yeah, that would be good ... and I will put all deprecated features into it's own branch ... to have an overview
14:37  * cron2 bows to dazo's git-fu
14:37 <@mattock> sounds good, we're making progress here
14:38 < dazo> any objections if I don't revert the randomisation patch from allmerged in this round?  (patch is already sent to mailing list)
14:38 < dazo> cron2:  good point!
14:38  * dazo read his answer
14:39  * dazo redoes the git tree now
14:39 < cron2> dazo: I'd like to see the assignment line removed (see mail), but that could be an extra patch.  The patch as it is now is not radical enough :-) - but it does not do harm, so consider this a half-ACK
14:39 < dazo> yeah
14:39  * dazo writes note-to-self: coding after being up over 13 hours is not clever
14:40 < cron2> nothing wrong with coding, but "get sleep before committing" :)
14:40 <@mattock> should the deprecated features output warnings to logs and/or console? E.g. "WARNING: this feature is deprecated and will be removed soon"
14:40 <@mattock> depending on the feature, of course
14:41 <@mattock> except if we use ifdefs
14:41 <@mattock> or could we do that even with ifdefs
14:41 <@mattock> ?
14:41 < cron2> especially if we use ifdef
14:41 < cron2> if it's on, print warning
14:41 <@mattock> oh yes, of course
14:41 < cron2> if it's not on, well, nothign to print :)
14:41 < dazo> for some features, that would be good ... I'd say this could be used when decided on meetings for features we know will affect many users .... so not by default, but on request by devels/users
14:41 <@mattock> I should make a note for myself, too :)
14:42 <@mattock> dazo: ack
14:42 < cron2> (we could do "if it's *not* on, print warning that feature has been removed", but I think that might be overdoing it)
14:42 < dazo> that would be a "warning patch" before it really is removed
14:42 < dazo> yeah
14:42 <@mattock> and how do we keep track of deprecated features so that we can disable and remove them when necessary?
14:42 <@mattock> with code comments?
14:44 < dazo> that's actually already documented in the changelog .... isn't it?
14:45 < ecrist> fwiw, Matthias Andree is handing openvpn-devel port to me as maintainer, and possibly main openvpn port
14:46 <@mattock> dazo: you make my brains twist... I guess we both should get some sleep, it's pretty late :)
14:46 <@mattock> ecrist: that's great!
14:47 <@mattock> are we done for today? everybody seemed to more or less agree about the feature deprecation policy, right?
14:47 < cron2> yes
14:47 < dazo> mattock:  agreed :)  my head is struggling now :)
14:47 < jamesyonan> agreed
14:47 <@mattock> I'll write the meeting summary tomorrow (unless I forget like last time) and update the developer documentation page
14:48 < dazo> one last quick comment ....
14:48 <@mattock> shoot
14:48 < dazo> would it be possible to move the meeting to earlier?
14:48 <@mattock> that'd be great for me, too
14:48 < cron2> no objection from me
14:48 < dazo> Just an hour or two would help me ... I'm in UTC+1 ... and then I might be able to attend every week
14:49 <@mattock> James is living in PST timezone, so the meeting begins at 11AM for him 
14:49 < dazo> now I see I can only do approx every other week
14:49 < jamesyonan> Moving it earlier would be more difficult for me
14:49 < dazo> can other days be more suitable?
14:50 < jamesyonan> sure
14:50 <@mattock> dazo: how much earlier?
14:50 <@mattock> one hour, two hours?
14:50  * dazo got meetings with people in Alabama and Boston on Tuesday and Thursdays .... usually between 15:00 and 18:00  UTC
14:51 < dazo> dazo:  even one hour is helping me ... but two might be better ... but I'm just asking .... if it's not possible, I'll do my best anyway
14:51 < jamesyonan> a different day of the week is fine for me, but moving it earlier would be problematic
14:52 <@mattock> james, would 18:00 UTC still be doable?
14:52 <@mattock> 10AM your time
14:52 < jamesyonan> yes, one hour is okay
14:52 < jamesyonan> mattock: yes
14:52 <@mattock> is Thursday still ok for all?
14:53 <@mattock> I can't do wednesdays but everything else is fine
14:53 < dazo> Thursday is fine for me
14:54 < jamesyonan> Thursdays works for me
14:54 <@mattock> ok, that's settled then
14:54 < dazo> thanks everyone!
14:54 <@mattock> thanks guys! great meeting once again
14:54 < cron2> thursday is fine
14:55 <@mattock> see you all later! I'll get some sleep now
14:55 <@mattock> bye!
14:55 < jamesyonan> bye
14:56 < dazo> byt
14:56 < dazo> bye*
14:56 < cron2> bye
14:57 -!- dazo is now known as dazo_afk
14:59 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
15:01 -!- Irssi: ##openvpn-discussion: Total of 12 nicks [0 ops, 0 halfops, 2 voices, 10 normal]
16:16 -!- cervicek [~cervicek@rzlx0901.hs-esslingen.de] has quit [Quit: leaving]
17:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan]
19:01 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
--- Day changed Fri Feb 19 2010
04:32 -!- dazo_afk is now known as dazo
05:30 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:30 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
05:31 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan]
10:33 -!- tw [~silverfis@c-98-223-105-100.hsd1.in.comcast.net] has left ##openvpn-discussion []
14:40 -!- dazo is now known as dazo_afk
14:53 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
15:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
17:24 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
22:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan]
--- Day changed Sat Feb 20 2010
01:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
04:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan]
--- Log closed Sat Feb 20 17:00:21 2010
--- Log opened Sat Feb 20 21:31:21 2010
21:31 -!- Irssi: Join to ##openvpn-discussion was synced in 26 secs
--- Day changed Sun Feb 21 2010
03:45 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 256 seconds]
03:46 -!- cron2 [~gert@kirk.greenie.muc.de] has joined ##openvpn-discussion
03:53 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 268 seconds]
03:53 -!- cron2 [~gert@kirk.greenie.muc.de] has joined ##openvpn-discussion
08:39 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
08:39 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
14:32 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
--- Day changed Mon Feb 22 2010
01:09 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:09 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:41 -!- dazo_afk is now known as dazo
02:58 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:58 -!- mode/##openvpn-discussion [+o mattock1] by ChanServ
02:59 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
04:36 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
04:36 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:36 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.]
04:56 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
05:10 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds]
05:47 -!- agi [~agi@manson.entorno-digital.com] has joined ##openvpn-discussion
06:01 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
06:01 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
06:51 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
06:54 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
06:54 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
08:29 -!- dazo is now known as dazo_afk
10:37 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
12:31 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
12:31 -!- mode/##openvpn-discussion [+v Kaspx] by ChanServ
12:33 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 256 seconds]
12:34 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 252 seconds]
12:37 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
12:37 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
--- Day changed Tue Feb 23 2010
01:12 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:12 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:31 -!- dazo_afk is now known as dazo
05:19 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds]
11:07 -!- dazo is now known as dazo_afk
16:30 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
--- Day changed Wed Feb 24 2010
01:28 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:28 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:44 -!- dazo_afk is now known as dazo
07:14 -!- dazo is now known as dazo_afk
07:43 -!- dazo_afk is now known as dazo
09:45 -!- mape2k [~mape2k@2001:638:904:ffc4:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
09:46 -!- mape2k [~mape2k@2001:638:904:ffc4:21e:37ff:fe90:fbfd] has quit [Client Quit]
09:46 -!- mape2k [~mape2k@2001:638:904:ffc4:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
10:53 -!- dazo is now known as dazo_afk
10:53 -!- mape2k [~mape2k@2001:638:904:ffc4:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
14:57 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
22:55 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
22:55 -!- mode/##openvpn-discussion [+v Kasx] by ChanServ
22:55 -!- Kaspx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer]
--- Day changed Thu Feb 25 2010
00:41 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
00:43 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Client Quit]
00:43 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
00:46 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
00:47 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:54 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
04:32 -!- dazo_afk is now known as dazo
05:46 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
08:06 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
08:08 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
09:47 < ecrist> dazo, why did you change the meeting time?
09:48 < ecrist> 1900 UTC is the correct time...
09:51 < dazo> nope ... changed to 18:00 UTC
09:51 < ecrist> I didn't see any discussion of this...
09:52 < ecrist> nm, I paged up
09:52 < dazo> it was discussed and agreed ... even mentioned in the meeting minutes ;-)  at the very top .... 
09:55 -!- mode/##openvpn-discussion [+o ecrist] by ChanServ
09:55 -!- ecrist changed the topic of ##openvpn-discussion to: OpenVPN Discussion Channel || Meetings Held Thursdays, 1800UTC
09:55 -!- mode/##openvpn-discussion [-o ecrist] by ecrist
10:02 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
11:14 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org]
11:23 < krzee> oh thats about to happen isnt it
11:24 < krzee> in like 30min
11:25 < cron2> yep
11:26 < cron2> (but I have to leave in 30 minutes... bad timing on my side)
11:27 < krzee> cool
11:27 < krzee> bout 4:30am here
11:27 < dazo> where are you?
11:27 < krzee> visiting australia
11:27 < dazo> ahh
11:27 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:27 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
11:29 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
11:50 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
11:50 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
11:53 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
11:55 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
12:00  * dazo gets ready 
12:00 <@mattock> me too
12:01 -!- |Mike| [mike@2001:1af8:2:444::2] has joined ##openvpn-discussion
12:02 < dazo> mattock:  do we have an agenda for today?
12:02 < |Mike|> discussion about what exactly?
12:02 < dazo> |Mike|:  in general, development and testing stuff ... James Yonan also joins usually
12:02 <@mattock> dazo: I think we should discuss the FRP a little
12:03 <@mattock> dazo: do we have any patches we should discuss with James (when he arrives)
12:03 < dazo> mattock:  Yeah, I got one patch which Gentoo includes 
12:04 <@mattock> the easyrsa thingy?
12:04 < dazo> nope ... #define _GNU_SOURCE .... seems to be related to older glibc's
12:04 <@mattock> ok
12:04 < dazo> easyrsa thing in Gentoo seems to be related to openssl builds without pkcs11 support
12:06 < dazo> mattock:  I'm also looking into some patches Fedora includes ... mostly updating the init script ... I'm considering if we should pull in some of the more generic patches here as well
12:06 <@mattock> has everybody taken a look at the FRP dazo and I have drafted:
12:06 <@mattock> http://www.secure-computing.net/wiki/index.php/OpenVPN/Developer_documentation#Feature_deprecation
12:06 < vpnHelper> Title: OpenVPN/Developer documentation - Secure Computing Wiki (at www.secure-computing.net)
12:07 <@mattock> dazo: ok
12:07 <@mattock> what other patches does fedora include?
12:08 < dazo> mattock:  for F-12, only sample-scripts/openvpn.init updates
12:08 <@mattock> what do you think about having the distro-specific stuff upstream (=in the "testing" tree)?
12:08 <@mattock> e.g. init script stuff
12:09 <@mattock> it would perhaps help in reusing the generally useful parts
12:09 < dazo> mattock:  I would try to avoid it as much as possible ... make it as generic as possible, distro-specific which only they need stuff should be patched by patched by them, IMHO
12:11 < dazo> mattock:  if we get stuff for specific distros, I'd rather give them a separate directory
12:11 <@mattock> yes, the stuff needs to be at least clearly separated from the generic stuff
12:12 < dazo> agreed :)
12:12 <@mattock> what about the FRP? Is it something we all can agree on?
12:13  * dazo would like to have James' accept on FRP as well ... and also his comment on the "nag logging patch" cron2 acked yesterday
12:14 <@mattock> dazo: I'd like to hear his thoughts, too
12:14 <@mattock> and we need to sort out how exactly stuff moves from testing to stable
12:15 < dazo> yes
12:15 <@mattock> my agent is after James
12:15 <@mattock> (thanks Kasx)
12:15 <+Kasx> np
12:16 <@mattock> regarding the community site...
12:17 <@mattock> the LDAP server is now up, I've configured access control settings and built a schema
12:17 <@mattock> I started working on the user registration webapp (http://code.google.com/p/pwm/) but did not get it working (yet)
12:17 < vpnHelper> Title: pwm - Project Hosting on Google Code (at code.google.com)
12:18 <@mattock> ecrist: are you available?
12:18 <@mattock> =there
12:18 < ecrist> for now, yes
12:18 <@mattock> may I ask a quick question about LDAP
12:18 <@mattock> ?
12:18 < ecrist> certainly
12:18 <@mattock> ok
12:19 <@mattock> I currently have something like this
12:19 <@mattock> user accounts are in ou=Accounts, dc=openvpn, dc=net
12:19 <@mattock> groups are in ou=Groups, dc=openvpn, dc=net
12:20 <@mattock> each account implements objectclasses posixAccount and inetOrgPerson
12:20 <@mattock> groups are of the posixGroup type
12:20 <@mattock> I'm guessing this is kind of basic setup
12:20 <@mattock> however, what do you think about putting the Accounts inside the Group tree?
12:21 < ecrist> what do you mean?
12:22 <@mattock> so that the dn for an account would be cn=Firstname Lastname, ou=Groupname, ou=Groups, dc=openvpn, dc=net
12:22 <@mattock> or something like that
12:22 <@mattock> is there any advantage to that approach?
12:22 -!- Schlaubi [~daniel@p5B0A2085.dip0.t-ipconnect.de] has joined ##openvpn-discussion
12:23 < ecrist> not really, it's all cosmetic
12:23 < ecrist> the hier really only helps with ACL generation and mental picturs. ;)
12:23 <@mattock> how do you handle group membership for users? do you have a member list attribute inside the group definition?
12:24 < ecrist> myself, I have ou=groups,ou=people,dc=company,dc=com and ou=staff,ou=people,dc=company,dc=com
12:24 < ecrist> and similar trees within
12:24 < ecrist> groups can be handled two ways, either you have a group object, with members listed within, or you list membership in the user object
12:24 < ecrist> it's simply a matter of how you structure your query
12:24 < ecrist> I opted for the group object listing membership
12:25 < ecrist> there are advantages and disadvantages to both
12:25 <@mattock> ok, thanks
12:25 < ecrist> on one side, you need to query each user to find a groups' members, and on the other, you need to query each group to find which groups a user belongs to
12:26 <@mattock> btw. I stumbled upon an interesting article regarding LDAP schema design: http://www.informit.com/articles/article.aspx?p=28786
12:26 < ecrist> for my use, we use object classes top, inetorgperson, posixaccount, shadowaccount, and a couple in-house ones.
12:26 < vpnHelper> Title: InformIT: Principles of LDAP Schema Design > Typical Problems with LDAP Schema Design (at www.informit.com)
12:27 <@mattock> it seems possible to normalize the LDAP schema similarly to what you can do with databases 
12:27 < ecrist> ldap is simply a database grossly optimized for reads
12:27 <@mattock> kind of, yes
12:28 <@mattock> btw. what LDAP client do you use for management (if I may ask)?
12:28 < ecrist> I deal with raw ldif
12:28 <@mattock> ok
12:29 <@mattock> I've used phpldapadmin which works nicely... however, I've heard horror stories about it's code from coders
12:29 < ecrist> however, you being on a mac, apache has a really nice one, Apache Dirctory Studio I use from time to time
12:29 <@mattock> I'm on Mac which runs Linux :)
12:29 < ecrist> actually, that one is in java, so it's cross platform
12:31 <@mattock> should we wait for James for a while?
12:31  * dazo got only about another 30min available unfortunately
12:31 <@mattock> or do we have any other topics to discuss?
12:32 < dazo> testing?
12:32 < ecrist> I'm unavailable in 20 mins
12:32 <@mattock> ok, testing
12:32 <@mattock> in fact, we could make a list of things we need the s.c. "dedicated testers" to document
12:32 < dazo> what's the status here?  FreeBSD is in place ... Gentoo is on the way ... Debian?
12:32 <@mattock> agi: are you there?
12:33  * dazo has located the Fedora packager on #fedora-devel .... silug
12:33 <@mattock> dazo: great!
12:33 < dazo> do we have anyone inside Mandrake and openSuSE?
12:33 <@mattock> dazo: is there any documentation for packagers?
12:33 < mape2k> i'll try to build the git-code for OpenWRT and Freetz (MIPS, Fritzbox, uclibc) these days
12:34 < dazo> mape2k:  perfect!
12:34 <@mattock> mape2k: great
12:34 < dazo> mattock:  not explicit ... but they should pay attention to the testers doc, especially the compile and configure section
12:34 < mape2k> i've to prepare for an oral exam, hope i'll find some free time ;)
12:34 < dazo> mape2k:  it's not *that* urgent that we expect it before your exams ;-)
12:35 < mape2k> hehe
12:35 <@mattock> I think it makes sense to move the compile & configure section to it's own page
12:35 <@mattock> it's useful to developers, testers and packages
12:35 < dazo> yeah, we can do that ... I plan to keep that updated in regards to disable deprecated features 
12:37 -!- Schlaubi [~daniel@p5B0A2085.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
12:37 < dazo> I'm also planning to do something more clever with the ./bootstrap.sh script ... so that it can be used for more than just ecrist FreeBSD packager as well
12:38  * dazo is actually really excited that we will get ovpn-testing on embedded also
12:38 <@mattock> regarding testing setup documentation... what exactly do we need? At least OS, ./configure output (=used features)
12:39 < dazo> We do need the ./configure line .... openvpn --version ... and configuration files 
12:39 < dazo> But I've been thinking if we should have some kind of standard config files in addition ... a couple of different test suites which can do really the most important feature testing of OpenVPN
12:40 <@mattock> I think we have two separate needs... part of that documentation can wait until problems are encountered, but part of it is useful to have online to see what setups are being tested actively
12:40 < dazo> yes
12:41 <@mattock> I think we decided that we _can_ assume testers use the latest OpenVPN version 
12:42 < dazo> yes, but it's good to keep track of the openvpn --version ... when I got a more clever bootstrap script up, it will put the HEAD commit ID in the version string
12:42 <@mattock> should the ./configure line be in the Wiki?
12:42 <@mattock> (I assume yes)
12:42 < dazo> giving is a good possibility to track which commit which gives troubles or is known to work
12:43 < dazo> ./configure in wiki ... I don't quite understand?
12:43 <@mattock> I mean, if we want to see what features are (supposedly) being tested (or covered) testers should probably put their ./configure line to the Wiki
12:43 <@mattock> to their own tester page
12:43 < dazo> yes, as a part of their report, yes, definitely!
12:44 < dazo> that's good for historical reasons ... as the requirement for that will change over time ... but good to know when looking on older reports
12:45 < ecrist> is there an option for the openvpn binary to list out configure and compile-time options?
12:45 < dazo> ecrist:  nope
12:45 <@mattock> that'd be quite useful
12:45 < ecrist> might be useful, at least in dev versions
12:45 <@mattock> wouldn't that be easy to implement, too?
12:45 < dazo> agreed ... I'll look into that ... could actually be a part of the --version screen
12:45 <@mattock> doesn't sound like black magic to me
12:45 < ecrist> so, if configure is run with debug or devel mode, add a -pr option or some-such to output that data
12:46 < ecrist> dazo, it may be too much for --version, keeping in mind embedded systems
12:46 < ecrist> with all the ifdefs, etc, that's a long set of strings to store.
12:46 < dazo> ecrist:  well, there is a --enable-small configure arg which these systems should use ... that can disable it on them
12:47 < ecrist> ok
12:47  * ecrist not a developer, so just typing idea.
12:47 < dazo> but ... that info should mainly only be visible when a kind of --debug mode is enable
12:47 < dazo> d
12:47 <@mattock> I think we should make bug reporting as easy as possible
12:47 < dazo> $ make bugreport
12:47 < dazo> ?
12:48 < dazo> ;)
12:48 <@mattock> yep ;)
12:48 < ecrist> openvpn -pr
12:48 <@mattock> anyways, I think ecrist's idea is good
12:49 <@mattock> the less manual steps are required for bug reporting (especially in "testing") the better
12:49 < dazo> yup
12:49 <@mattock> perhaps "make bugreport"?
12:49 <@mattock> as dazo said, actually :)
12:49 <@mattock> didn't get it earlier
12:49 < dazo> heh :)
12:50 < dazo> that was my thought yeah ... but adding make specific targets with autotools can be an adventure and experience ... but not impossible
12:50  * dazo will look into that in the near future
12:51 <@mattock> I created a _very_ limited section about bug reporting: http://www.secure-computing.net/wiki/index.php/OpenVPN/Documentation_for_testers#Reporting_bugs
12:51 < vpnHelper> Title: OpenVPN/Documentation for testers - Secure Computing Wiki (at www.secure-computing.net)
12:51 <@mattock> I think we can safely assume James is not coming today
12:51 <@mattock> too bad
12:52 <@mattock> dazo: could you mail him directly about the patches?
12:52 <@mattock> I can do the same for FRP
12:52 < dazo> Will do!
12:52 <@mattock> I'll add reminders about reminding James to my selfphone 
12:53 <@mattock> otherwise he might forget these meetings too often ;)
12:53 < dazo> mattock:  can you please also add a link to the "[PATCH] FRP: Present a warning on deprecated features during start-up" patch as well?
12:53 <@mattock> ok, will do
12:54 < dazo> then I'll pick up the Gentoo patch as well
12:54 <@mattock> regarding Debian Experimental... it seems "agi" is absent even though he's present
12:55 <@mattock> he said he could put "testing" into Debian Experimental ~once a week
12:55 < dazo> yeah :)
12:55 < dazo> that's more than fair enough ... that's about the same as what ecrist will do with FreeBDS
12:55 <@mattock> when the community site stuff is mostly done, I can move to packaging issues (e.g. daily snapshots)
12:56 <@mattock> one more thing...
12:56 <@mattock> what do you guys think about opening up the community site Trac instance as "beta"
12:56 <@mattock> meaning that you need to send me mail to get accounts
12:56 < dazo> mattock:  have you spotted any SuSE or Mandrake users?  I'd like to have more RPM distros tested as well
12:56 < dazo> mattock:  that sounds like a good idea
12:56 <@mattock> the "pwm" stuff (user self-service registration) will take a while
12:57 <@mattock> all that is needed then is getting a SSL cert and doing some hardening
12:57 < dazo> it's better to get it tested under a controlled environment
12:57 <@mattock> then it's "ready"
12:57 < dazo> as long as read-only access will be available for the rest 
12:57 <@mattock> dazo: I don't know of any SuSE or Mandriva users
12:58 <@mattock> dazo: yep, it will be
12:58  * dazo don't think there are many "writers" on secure-computing wiki today
12:58 <@mattock> true
12:58 <@mattock> the self-service registration becomes an issue when forums open
12:58 < dazo> I think that will work out then
12:58 < dazo> yes
12:59 <@mattock> ok, I'll open the community site when SSL certs are in place
12:59 <@mattock> there won't be any fancy themes or anything
12:59 <@mattock> but it should work
12:59 <@mattock> in fact, it can remain "beta" forever, like Google's services
13:00 < dazo> :)
13:00 < dazo> nah ... we can do better than Google :-P
13:00 <@mattock> yeah, we even have more muscle and brainpower
13:00 <@mattock> :)
13:00 <@mattock> oh, do you mean having it in "alpha" state always?
13:00 <@mattock> or in the "ship it if it builds"-state?
13:01 < dazo> :)
13:01 <@mattock> ok, so a summary
13:01 < dazo> compiles? check ... pass smoke-test?  check ... shipped?  check!
13:01 <@mattock> optionally smoke test can be skipped
13:02 < dazo> :)
13:02 <@mattock> if busy
13:02 <@mattock> and even if it does not build, you can add the files that _did_ compile to an earlier version
13:02 <@mattock> it might work
13:02 <@mattock> anyways, I'll take care of FRP+James
13:03 <@mattock> and dazo will send mail to James about the patches
13:03 < dazo> yup!
13:03 <@mattock> and community site will be opened when SSL cert is configured
13:03 <@mattock> and Trac LDAP auth is in place
13:03 <@mattock> we can then start adding Trac plugins to see how they work
13:04 <@mattock> I'll mail Francis about ecrist's root access
13:04 <@mattock> I guess we're done
13:05 <@mattock> I'll write the real summary tomorrow and this time add the full chatlog to the email
13:05 < mape2k> ;)
13:06 <@mattock> see you later, guys!
13:07 <@mattock> time for desert...
13:07 < dazo> c'ya!
13:07 <@mattock> no, just kidding, dessert
13:07 <@mattock> :)
13:08 < dazo> :)
13:24 -!- dazo is now known as dazo_afk
13:27 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
13:27 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
13:50 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 256 seconds]
13:51 -!- Kasx [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 252 seconds]
13:51 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:51 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
13:55 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:55 -!- mode/##openvpn-discussion [+v openvpn2009] by ChanServ
15:06 -!- dazo_afk [~dazo@nat/redhat/x-eotqvidadipgeorz] has quit [Read error: Operation timed out]
15:08 -!- dazo_afk [~dazo@nat/redhat/x-wbuewcupmncwnaaa] has joined ##openvpn-discussion
15:08 -!- dazo_afk is now known as Guest3546
15:08 -!- Guest3546 is now known as dazo
15:09 -!- dazo is now known as Guest38238
15:18 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
15:22 < cron2> re
15:26 < cron2> mape2k: OpenWRT sounds extremely cool (I was planning to do this for myself, but then I can focus on other stuff)
15:35 < mape2k> I'm running 2 Linksys/Asus-Routers with OpenWRT ... not the fastet systems but extremly robust and good powersaving ;)
15:38 < cron2> mape2k: I'm using Linksys WRT54GL in a few customer setups as OpenVPN gateways - nice, small, cheap, and does what the customer needs.
15:38 < cron2> (using OpenWRT Kamizake)
15:39 < cron2> my home router was a WRT54GL+OpenWRT for the last year, but got replaced by a system with more RAM+Flash last week (openrd client)
15:46 < mape2k> I'm searching for a system with more cpu power and more RAM. wrt54gl only route about 20MBit/s and encrypt only 4MBit/s
15:47 < mape2k> the asus wl500gP encrypt about 7-8MBit/s
15:47 < mape2k> but all my internet-upstreams are about 16MBit/s downstream ;) so the router is a bottleneck
15:54 < cron2> mape2k: look at sheevaplug / guruplug
15:54 < cron2> 1.2 GHz ARM CPU, 2x GigE on Guruplug (only 1GE on sheeva, which is kinda stupid)
15:54 < cron2> lemme google
15:54 < mape2k> price?
15:54 < cron2> http://www.globalscaletechnologies.com/t-guruplugdetails.aspx
15:55 < vpnHelper> Title: GuruPlug Server (at www.globalscaletechnologies.com)
15:55 < cron2> as far as I know, the GuruPlug Server Plus (2x GE) will be around 80-90 EUR
15:56 < cron2> twice the price of the WRT
15:56 < mape2k> hmmmk, my current switch can't really handle vlans 
16:41 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
19:36 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
20:08 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
--- Day changed Fri Feb 26 2010
00:13 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
00:13 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
00:40 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
02:07 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
04:32 -!- Guest38238 is now known as dazo
05:09 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:09 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
06:33 <@mattock> james had sent an email to me, saying he can't attend the meeting. Unfortunately our email server did not work so learned this too late.
06:39 < cron2> well, sometimes things just don't work out
06:39 < cron2> has james commented on some of the patches or proposed processes?
06:42 <@mattock> I just sent him email about the FRP and the FRP patch
06:42 <@mattock> I'd expect him to respond later today
06:42 <@mattock> dazo promised to mail him about the other patches
06:42  * dazo sent mail about the glibc-2.8 patch which Gentoo always implements
06:43 < dazo> Didn't really have any other patches in the queue yet
06:43 < dazo> not which I remember at least :-P
06:43 <@mattock> btw. was James ok with the details of the ipv6 stuff?
06:43 < cron2> mattock: no feedback from him
06:43 < dazo> that has never been discussed in details
06:43 <@mattock> ok
06:44 <@mattock> I have to make sure his silence is because he's ok with them
06:44 < cron2> I'm actually hoping for some feedback on the stuff that is already in -testing - "is this the right way to do IPv6?"
06:44 < dazo> mattock:  I began looking at the bugs registered sf.net  ... began categorising, answering the simple stuff
06:44 <@mattock> cron2: I think we need to discuss the ipv6 details next week
06:44 < dazo> it's now 86 open bugs .... a lot of gruff and things which probably should be closed ... but we would need some help here
06:45 < cron2> mattock: ok
06:46 <@mattock> what do you think if we'd try to compile a list of "these issues need James' feedback" before each meeting? and send the list to James
06:46 <@mattock> e.g. mails he should read and comment on
06:46 < dazo> mattock:  what about to contact Jan Just Keijser ... he's quite active on the -users mailing list ... and also do answer some forum posts on sf.net ... what about to ask if he have time to look at the bug tracker?  it's a lot there which really isn't bugs but just needs pointers to forums or mailing posts
06:47 < dazo> mattock:  agreed!  I've been thinking about the same as well
06:47 <@mattock> dazo: we could wait until Trac goes public and move the SF.net tickets there
06:47 <@mattock> they're exportable in XML format - and I guess trac can import them somehow
06:48 < dazo> mattock:  well, if we could close as much as possible before a move, it would be less to move over
06:48 <@mattock> true
06:48 < dazo> I think it's probably 20-25 bugs which are really worth considering ... out of the 86 open cases (over 180 bugs in total registered)
06:48 <@mattock> I just have to verify from James that it's ok to give Jan tracker admin rights
06:49 <@mattock> I doubt he'll object, though
06:49 < dazo> sure ... and probably also ask Jan first as well :)
06:49 <@mattock> was Jan willing to do this?
06:49 <@mattock> oh :)
06:49 < dazo> I have not asked ... I just thought he would be a good resource, as he gives a lot of good feedback
06:49 < dazo> and he knows a lot
06:50 <@mattock> agreed, we need to make use of our active members
06:50 <@mattock> and I'm sure they're more than happy to help out
06:50  * dazo sure hopes so :)
06:54 < ecrist> \o
06:57 <@mattock> ecrist: I'm writing mail to Francis and James about community site shell access... would you be interested in maintaining / helping to maintain the community site forums? Provided that you have shell access, of course (=access to the data).
06:59 < ecrist> sure, I can volunteer to do that.
07:00 < ecrist> I'm doing it all currently, already. ;)
07:02 <@mattock> yep, my thoughts exactly :)
07:05 <@mattock> ecrist: could you proofread my email before I send it further...
07:05 <@mattock> (it's not ready yet, though)
07:05 < ecrist> sure, send it to me and I'll read it when I can.
07:05 < ecrist> only at kb for another 30 mins - my company's in the middle of a datacenter migration, so I'll be jockeying hardware between them part of the day today
07:23 < krzee> [04:46]  <dazo> mattock:  what about to contact Jan Just Keijser ... he's quite active on the -users mailing list ... and also do answer some forum posts on sf.net ... what about to ask if he have time to look at the bug tracker?  it's a lot there which really isn't bugs but just needs pointers to forums or mailing posts
07:24 < dazo> krzee:  ?
07:24 < krzee> that would be cool to see jjk involved outside the mail list, ive kinda hoped to see him pop on irc
07:24 <@mattock> krzee: ok, I'll ask him if he's interested
07:24 < dazo> krzee:  agreed! :)
07:25 < dazo> krzee:  he has been responding to forum posts on sf.net as well ... so that's why it would be great to see him in the bug tracker there as well, to close those crappy bugs reports which are there 
07:25 < dazo> but on irc as well ... oh, yeah! :)
07:35  * ecrist heads out
07:36 < krzee> ahh i didnt know he was active on sf.net
07:43 <@mattock> ecrist: I sent the mail to you for proof-reading
07:43 <@mattock> krzee, dazo: I'll send mail to Jan now
07:47 < dazo> thx!
08:07 <@mattock> sent
08:10 <@mattock> hi, I have question about prepositions... is this correct:
08:10 <@mattock> "at irc.freenode.net each Thursday at 18:00 UTC"
08:11 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 265 seconds]
08:11 <@mattock> (we don't have prepositions in Finnish so those are a bit hard for us
08:12 < dazo> yeah, I'd use 'at' here ... but I'm neither a native speaker
08:15 <@mattock> I never seem to get the "logic" (if there is one)
08:16 <@mattock> expect for the obvious cases, like "on the table"
08:39 -!- janjust [~janjust@ardeche.nikhef.nl] has joined ##openvpn-discussion
08:40 -!- janjust [~janjust@ardeche.nikhef.nl] has left ##openvpn-discussion []
08:40 -!- janjust [~janjust@ardeche.nikhef.nl] has joined ##openvpn-discussion
08:46 < janjust> Samuli I got your email, just checking out this irc channel 
09:17 <@mattock> janjust: hi!
09:17 < janjust> Hi samuli
09:17 < janjust> I've just replied to your email
09:19 <@mattock> janjust: I'll ask James if I can grant you the rights to the SF.net tracker
09:20 <@mattock> I don't think he'll have any objections, but better be sure
09:44 -!- janjust [~janjust@ardeche.nikhef.nl] has left ##openvpn-discussion ["Leaving"]
10:26 < dazo> mattock:  something to discuss ... sf.net and the trackers ... should we enforce that users using it are registered users? ... just to avoid a lot of very vague reports/patches without a possibility to follow them up further ...
10:27  * dazo knows a new solution will come on the new server ... but in the mean time ...
11:01 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org]
12:06 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
12:52 -!- dazo is now known as dazo_afk
13:03 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
13:27 < ecrist> I would use 'on' instead of 'at' in that case.
13:32 < ecrist> mattock: email looks good.  very flattering. :)
15:32 -!- openvpn2009 [~email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
15:32 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
15:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
15:38 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
15:59 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
16:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
16:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
17:42 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
23:09 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
--- Day changed Sat Feb 27 2010
01:24 -!- sdredwingsfan [~cmwright@pool-74-100-32-108.lsanca.fios.verizon.net] has joined ##openvpn-discussion
01:50 -!- sdredwingsfan [~cmwright@pool-74-100-32-108.lsanca.fios.verizon.net] has quit [Quit: Ex-Chat]
03:25 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
03:25 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:32 <@mattock> ecrist: ok, I'll probably send it on Monday (quite busy during the weekend)
03:33 <@mattock> dazo: I think the community site can be opened within a few weeks. What we're essentially missing is a (paid) SSL cert and LDAP authentication configuration for Trac
03:34 <@mattock> then it's "good enough" for a wiki and bug tracker
07:22 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
08:59 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
14:56 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
--- Day changed Sun Feb 28 2010
04:04 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
11:55 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
11:56 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
12:57 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
12:58 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
13:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
--- Day changed Mon Mar 01 2010
01:30 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
01:32 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
02:37 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
02:58 -!- dazo_afk [~dazo@nat/redhat/x-wbuewcupmncwnaaa] has quit [Ping timeout: 258 seconds]
03:10 -!- dazo_afk [~dazo@nat/redhat/x-zskgdalwfqtwswag] has joined ##openvpn-discussion
03:10 -!- dazo_afk is now known as Guest10307
03:10 -!- Guest10307 is now known as dazo
03:11 -!- dazo is now known as Guest20744
03:12 -!- Guest20744 is now known as dazo_
03:23 -!- dazo_ [~dazo@nat/redhat/x-zskgdalwfqtwswag] has quit [Ping timeout: 240 seconds]
03:29 -!- dazo_ [~dazo@nat/redhat/x-uefaptlsnyfpfhgx] has joined ##openvpn-discussion
04:11 -!- dazo_ is now known as dazo
07:26 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
07:26 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
08:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
08:27 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
08:29 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
08:33 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
08:54 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Connection reset by peer]
08:55 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
10:57 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
10:57 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
12:39 < cron2> mattock: are you around?
12:50 <@mattock> cron2: now I am
13:17 < cron2> mattock: ah, good.  I have a few things that I'd like James to comment on and/or where I'm wondering whether "you" could give assistance
13:18 < cron2> those are the e-mails I sent yesterday about
13:19 -!- dazo is now known as dazo_afk
13:19 < cron2> Subject: [Openvpn-devel] special-case code for OpenBSD - advice needed
13:19 < cron2> Subject: [Openvpn-devel] Macos X / Darwin funny in the code
13:19 < cron2> Subject: [Openvpn-devel] Win XP problem with framedyn.dll and PATH settings
13:19 < cron2> - these are the one where feedback is needed, and I'm afraid only James is qualified to give it
13:20 < cron2> Subject: Re: [Openvpn-devel] [PATCH] make ipv6_payload compile under   windowze ( feat_ipv6_payload branch )
13:20 < cron2> - this is where I'm stuck porting the IPv6 payload stuff to Windows, as I need to work on the tapdrvr now (the openvpn.exe changes are nearly finished, but the driver does not support IPv6)
13:21 < cron2> so I'm hoping for some advice here [and I just claim that your commercial product will eventually need IPv6 as well, so the benefit is mutual :-) ]
13:23 < cron2> mattock: all this is material for Thursday, but telling you in advance might raise my chances that it will work out :-)
13:25 <@mattock> cron2: yep, I read those mails... I think we should send a list of the "needs feedback from James" patches to him before the meeting
13:26 < cron2> it's not actually "patches" yet, more "clarification of existing code" or "guidance for future work" things
13:27 <@mattock> I think in the long run James needs to participate a little more.... all the work you guys do in "testing" directly benefits the commercial product of OpenVPN Technologies
13:27 < cron2> couldn't agree more :-)
13:27 <@mattock> so it makes sense for James to participate more
13:28 <@mattock> I think it'll take some time, though... the guys at the company need to see the benefits of the new model
13:30 < cron2> yep.  (I'm the impatient sort, I know... :-) )
13:30 <@mattock> could you send James a mail with the list of things you need clarification for?
13:31 <@mattock> perhaps just provide links to the existing ml posts and add a short description, if necessary
13:31 < cron2> yep, will do - tomorrow.  For today, enough OpenVPN stuff.  I'll put you in CC:
13:31 <@mattock> and make subject line stand out, e.g. "Need James' comments on these issues/patches"
13:31 <@mattock> otherwise he might miss it
13:31 <@mattock> you know, you guys have been doing awful lot of work
13:32 <@mattock> it took me ~1 hour just to read through all the emails
13:32 < cron2> O
13:32 < cron2> I'm sure dazo has been VERY bored this weekend...
13:32 < cron2> I have not managed to read all the e-mails yet :-)
13:33 <@mattock> our devel model sure creates lots of them :)
13:33 <@mattock> but the feedback has been very good
13:33 <@mattock> feedback to patches, that is
13:33 <@mattock> lots of good points from several people
13:34 < cron2> yes, it seems to be working nicely indeed
13:34 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
14:13 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
--- Day changed Tue Mar 02 2010
00:57 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
00:57 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has left ##openvpn-discussion []
00:57 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
03:04 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
03:04 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:22 -!- dazo_afk is now known as dazo
04:01 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Remote host closed the connection]
04:03 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
05:22 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Connection reset by peer]
06:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
06:47 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
07:39 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: No route to host]
08:50 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
08:50 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
09:23 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
11:57 -!- dazo is now known as dazo_afk
14:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
--- Day changed Wed Mar 03 2010
00:20 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
00:20 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
00:52 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
00:54 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Client Quit]
00:54 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
01:48 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Remote host closed the connection]
01:48 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
02:44 -!- dazo_afk is now known as dazo
03:03 -!- mattock1 [~samuli@sparknet-agw0.abo.fi] has joined ##openvpn-discussion
03:03 -!- mode/##openvpn-discussion [+o mattock1] by ChanServ
03:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
03:11 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
03:11 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
03:13 -!- mattock1 [~samuli@sparknet-agw0.abo.fi] has quit [Ping timeout: 256 seconds]
09:02 -!- dazo is now known as dazo_afk
10:15 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has left ##openvpn-discussion []
--- Log closed Wed Mar 03 10:15:30 2010
--- Log opened Thu Mar 04 14:32:48 2010
14:32 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has joined ##openvpn-discussion
14:32 -!- Irssi: ##openvpn-discussion: Total of 12 nicks [1 ops, 0 halfops, 1 voices, 10 normal]
14:32 -!- Irssi: Join to ##openvpn-discussion was synced in 0 secs
14:40 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
16:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has left ##openvpn-discussion []
--- Day changed Fri Mar 05 2010
00:59 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
01:19 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:19 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:41 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
03:04 -!- d12fk [~heiko@vpn.astaro.de] has quit [Remote host closed the connection]
03:17 -!- d12fk [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
04:13 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Remote host closed the connection]
04:19 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
07:08 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
07:09 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
09:58 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
12:19 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer]
13:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
16:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
16:11 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
16:31 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds]
17:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
19:34 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 260 seconds]
19:36 -!- cron2 [~gert@kirk.greenie.muc.de] has joined ##openvpn-discussion
23:49 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer]
23:52 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
--- Day changed Sat Mar 06 2010
01:13 -!- mape2k [~mape2k@p5B287B5A.dip.t-dialin.net] has joined ##openvpn-discussion
01:18 -!- mape2k [~mape2k@p5B287B5A.dip.t-dialin.net] has quit [Ping timeout: 245 seconds]
01:20 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:20 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:42 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
03:24 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
07:44 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
11:49 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
15:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
16:27 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds]
--- Day changed Sun Mar 07 2010
03:30 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
07:25 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
07:25 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
07:25 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Client Quit]
08:00 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
08:27 -!- |Mike| [mike@2001:1af8:2:444::2] has left ##openvpn-discussion [""void exit() >& /dev/null""]
19:37 -!- Netsplit *.net <-> *.split quits: @openvpn2009
19:38 -!- Netsplit over, joins: @openvpn2009
--- Day changed Mon Mar 08 2010
01:04 -!- mape2k [~mape2k@p5B28703D.dip.t-dialin.net] has joined ##openvpn-discussion
06:21 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
06:21 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
06:33 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
06:39 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
06:40 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
07:12 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 246 seconds]
09:20 -!- Irssi: ##openvpn-discussion: Total of 10 nicks [2 ops, 0 halfops, 0 voices, 8 normal]
10:07 -!- mape2k [~mape2k@p5B28703D.dip.t-dialin.net] has quit [Ping timeout: 265 seconds]
10:47 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
12:55 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
14:28 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
15:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
16:16 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 258 seconds]
16:58 -!- reiffert [~thomas@mail.webersheim.de] has joined ##openvpn-discussion
--- Day changed Tue Mar 09 2010
01:06 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has joined ##openvpn-discussion
01:08 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:09 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:29 < reiffert> moin
01:30 < reiffert> mattock: are there any news from the bugtracker yet?
01:30 <@mattock> umm... which one do you mean? :)
01:32 < reiffert> trac
01:36 <@mattock> I only need to install the SSL certificate for Apache and then Trac is ready to go
01:36 <@mattock> I have to add user accounts manually at first
01:36 <@mattock> but we get to use it
01:37 <@mattock> I think I'll open the community site on Wed or Fri - Monday at latest
01:37 <@mattock> unless there's something wrong with the cert I've been given, of course
01:38 < reiffert> openssl x509 -in cert.pem -text -noout
01:39 < reiffert> User Account please add: Thomas Reifferscheid <thomas@reifferscheid.org>, Username: reiffert
01:39 <@mattock> will do
01:40 < reiffert> "cannot resolve trac.openvpn.net"
01:40 <@mattock> it's community.openvpn.net
01:40 <@mattock> and there's nothing visible to the outside yet
01:40 <@mattock> it's firewalled
01:40 <@mattock> it'll be
01:41 <@mattock> https://community.openvpn.net/openvpn
01:41 < reiffert> How unobvious.
01:41 <@mattock> if we later create new openvpn-related projects, they'll be
01:41 < reiffert> :)
01:41 <@mattock> yep :)
01:41 <@mattock> https://community.openvpn.net/projectname
01:41 <@mattock> forums will be at https://forums.openvpn.net
01:42 < reiffert> You need some rephrasing, "when the community creates a project" :p
01:42 <@mattock> by we I mean the community - remember my role :)
01:42 < reiffert> :)
02:44 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
05:05 -!- dazo_afk is now known as dazo
11:10 -!- mape2k [~mape2k@2001:6f8:997:1000:21e:37ff:fe90:fbfd] has quit [Read error: Operation timed out]
12:50 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
13:32 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
13:49 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
13:57 -!- dazo is now known as dazo_afk
15:28 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving]
21:56 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
--- Day changed Wed Mar 10 2010
01:09 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
01:09 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
01:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
01:43 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
02:28 -!- dazo_afk is now known as dazo
04:08 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
06:54 -!- dazo is now known as dazo|afk
08:03 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
08:03 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
09:04 -!- dazo|afk is now known as dazo
09:23 < dazo> mattock:  FYI: I've began to prepare the topics for next meeting ... http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings/Topics-2010-03-11
09:23 < vpnHelper> Title: OpenVPN/IRC meetings/Topics-2010-03-11 - Secure Computing Wiki (at www.secure-computing.net)
09:24 <@mattock> what about the HMAC thing that came up in -users (and was forwarded to -devel)?
09:25 <@mattock> should we discuss that - I don't think anyone has responded to the mails
09:25 <@mattock> ?
09:25 < dazo> Yeah, that should probably be looked at
09:25 < krzee> im wondering if that thing has to do with the fact that he whole HMAC file is not used
09:25 < krzee> but i dunno enough to respond to that one
09:25 < dazo> krzee:  you might have a point here
09:26 < dazo> I've not looked carefully enough on that HMAC issue at all yet ... have had my plate full so far this week
09:58 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
09:59 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
10:45 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
10:45 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
11:33 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
11:33 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
12:36 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
12:56 -!- dazo is now known as dazo_afk
13:05 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
13:05 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
14:15 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection]
14:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
14:50 -!- d457k [~heiko@vpn.astaro.de] has joined ##openvpn-discussion
14:52 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
14:54 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 256 seconds]
--- Day changed Thu Mar 11 2010
02:01 -!- dazo_afk is now known as dazo
02:11 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:11 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
04:07 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
05:33 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
06:09 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
09:42 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
09:42 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
10:21 < ecrist> mattock: you here?
10:21 <@mattock> yep
10:21 <@mattock> shoot
10:22 < ecrist> re: backups
10:22 < ecrist> those are only my copies.  if you leave a file in a directory, it stays there
10:22 < ecrist> i.e.  you can keep 2 years worth in your own heirarchy, but if you lose it, I"ll have the last six months of copies
10:30 <@mattock> ecrist: ok
10:30 <@mattock> are there any disk space limitations?
10:30 <@mattock> (not that I intend to fill your disk or anything :)
10:31 < ecrist> there's only 107G avail on that server
10:31 < ecrist> df -h
10:31 < ecrist>  /usr is where home partitions are
10:32 <@mattock> does your backup solution do deltas of the files?
10:33 <@mattock> if, say, I put 20MB SQL dumps there, will every change create a new 20MB file?
10:38 < ecrist> it's at the file leve
10:38 < ecrist> l
10:38 < ecrist> just uses rsync
10:44 <@mattock> ok
10:45 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 260 seconds]
10:47 < ecrist> don't worry about my backup space, I have the resources to fully back up all my servers
10:48 <@mattock> great!
11:57 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
12:00 <@mattock> hi james!
12:01 < dazo> Hi y'all!
12:01 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
12:01 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
12:01 <@mattock> so dazo made a list of todays topics here: http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings/Topics-2010-03-11
12:01 < vpnHelper> Title: OpenVPN/IRC meetings/Topics-2010-03-11 - Secure Computing Wiki (at www.secure-computing.net)
12:01 <@mattock> btw thanks dazo :)
12:02 < dazo> mattock:  you're welcome :)
12:02 <@mattock> what about this HMAC issue: http://sourceforge.net/mailarchive/forum.php?thread_name=COL113-W51C6B9F7CC25D3F2F3F11EBA330%40phx.gbl&forum_name=openvpn-devel
12:02 < vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net)
12:02 < jamesyonan> Hi all
12:03 <@mattock> is it something we should look at
12:03 <@mattock> ?
12:04 < dazo> This person sent me an e-mail directly today ... I asked if she (presume it's a she) knows that not the complete HMAC file is used
12:04 < dazo> (well, I got the mail 3AM my time)
12:05 <@mattock> ok, so things are under control then :)
12:06  * dazo suggests, if possible, that someone with knowledge either gives me needed info or takes direct contact with her
12:06 <@mattock> who has enough knowledge to troubleshoot this?
12:07 < jamesyonan> what exactly is she claiming?  That OpenVPN is computing the HMAC incorrectly?
12:07 <@mattock> james: I assume that's what she means
12:08 < dazo> I understood it a bit different ... that the calculations she does, do not give the expected results .... since OpenVPN do work here, at least, I'm using --tls-auth on 3 different setups myself ....
12:09 < dazo> that's why I'm wondering if she is using the complete contents of the tls-auth file .... or just the needed fragments of it
12:11  * dazo sent a reference to the official ovpn faq, about why the static key still works even if just a few bytes are changed
12:11 <@mattock> perhaps we should just wait and see what she says
12:11 < dazo> yeah, the information we have is a bit vague, tbh
12:11 <@mattock> her mail is a bit hard to understand, so I think clarifications are needed
12:12 <@mattock> perhaps we should move on to the ACK/NACK issues
12:12 < dazo> I'll keep the list updated when I get more info
12:12 < dazo> yes please :)
12:12 < jamesyonan> We are just calling the standard HMAC routines in OpenSSL. 
12:13 < dazo> I expected that (I've not looked at the code) ... that's why I have the feeling that it is related to using a wrong HMAC key
12:13 < jamesyonan> What she should do is look at the 'work' buffer in openvpn_encrypt, just prior to the HMAC calculation, and confirm that it matches her interpretation of the OpenVPN security model
12:13 <@mattock> dazo: that was my initial thought also, given keys are involved in the hash
12:14 < dazo> jamesyonan:  that's a good pointer!  I'll provide that info!
12:14 <@mattock> ok, on to next issue: [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined ("Gentoo patch")
12:15 <@mattock> ACK or NACK?
12:15 < dazo> that one threw off quite a generic discussion about autotools in general
12:15 <@mattock> dazo: I think we should discuss the autotools issue also, but keep it shorter than the email thread :)
12:16 < dazo> jamesyonan:  one question ... Alon says (and I can confirm) that you don't need to care about autotools versions in the tarballs when you use 'make dist'
12:16 < jamesyonan> is there a reason why this issue is not properly addressed by AC_GNU_SOURCE?
12:16 < dazo> is there a reason we need to support bootstrapping the source code on older autotools versions?
12:16 -!- d12fk [~quassel@88.130.204.210] has joined ##openvpn-discussion
12:17 < dazo> jamesyonan:  I honestly don't know why AC_GNU_SOURCE is not enough ... my autotools-foo is not high enough yet
12:17 < d12fk> re
12:17 < jamesyonan> dazo: but often OpenVPN is build from subversion directly, not from the tarball
12:18 < dazo> jamesyonan:  also on such old platforms as RHEL4.6?
12:19 < jamesyonan> I suppose I would ACK then -- it seems trivial enough.  Presumably it's been build-tested on a few distros?
12:20 <@mattock> perhaps the autotools issue would fit into our neat "Feature deprecation process"...
12:20 < dazo> I've tested it on RHEL4.6 and Fedora 12, so they are "related" .... so I've not done much testing on other ones ... but that's going to be tested elsewhere with the testing tree 
12:20 < dazo> mattock:  I'm not too sure about that .... as this is not a code related thing ... it's a build related thing ....
12:21 <@mattock> but for users it's a feature (=to be able to build with older autotools), right? 
12:21 < dazo> I can stretch myself to a build-feature ... it's definitely not an openvpn feature
12:22 <@mattock> true
12:22 < jamesyonan> currently, we only put source files in the svn, not machine-generated files
12:22 <@mattock> so first we'd ask people if they build OpenVPN from SVN/Git on Redhat 4.6 or similar
12:23 < dazo> jamesyonan:  and that's the right way to do it, IMHO
12:23 < jamesyonan> so with this approach, the configure.ac needs to be compatible with old autotools versions
12:24 < dazo> jamesyonan:  oki ... I'll accept this now ... we can have a more careful discussion about this topic at a later point
12:24 < d12fk> but wouldn't have ppl who build it on such old RHEL system also have a more recent Unix somewhere, where they could make a dist tarball?
12:24 <@mattock> d12fk: good point
12:24 <@mattock> btw. what problems does the support for old autotools cause?
12:24 <@mattock> meaning: why are we having this discussion ;)
12:25 < d12fk> old autotoola are buggy, and some nice features are missing
12:25 < dazo> +1
12:26 < dazo> and as Peter Stuge said in the mail thread .... newer versions might even give better tarballs for older distroes, just because of less bugs
12:26 <@mattock> I suggest we ask people in -users and -devel if they indeed build OpenVPN SVN/Git versions with Redhat 4.6 or older
12:27 <@mattock> then see what happens
12:27 < dazo> IMO, I don't see the need for supporting anything else than the latest autotools after the discussion with Alon ... older systems can be compiled, even with autotools not installed ... as long as make dist has been run
12:27 < dazo> mattock:  lets do that
12:27 < jamesyonan> I regularly build on RHEL 4 (4.6) just to test that changes do not break anything on early Linux versions
12:28 < jamesyonan> what are some of the "nice features" we would get by requiring autotools latest version?
12:28 <@mattock> jamesyonan: but that's not mandatory, right? You could create a Redhat 4.6 compatible tarball on another machine with latest autotools installed.
12:28 < d12fk> i honestly doubt that many users build from svn directly, unless they are developers themself
12:30 < dazo> jamesyonan:  I'm not necessarily concerned about features right now, but there are bug fixes which might complicate things .... but have a colleague who is a autotools expert, I'll drop him an e-mail and ask
12:30 <@mattock> d12fk: I think so too, but I'll send a few mails tomorrow to get a better picture
12:30 <@mattock> dazo: good idea
12:30 < jamesyonan> so if we decide to require latest autotools version, does that mean we don't need this patch?
12:31 < dazo> it could actually mean that, to some extent yes
12:31 <@mattock> dazo: so is it a NACK until the autotools issue is settled?
12:31 < dazo> mattock:  agreed!
12:32 <@mattock> ok, I'll send mails to -users and -devel tomorrow, explaining what we'd like to do
12:32 <@mattock> in the true FRP style ;)
12:32 < jamesyonan> But if Gentoo is using it, then presumably their build system isn't capable of building the ./configure script on a recent autoconf version for older distros?
12:32 < dazo> perfect!
12:33 <@mattock> good point, james
12:33 < dazo> it could be something like that ... I have not gotten into details ... as this patch was added early in the 2.1_rc cycles
12:33 < dazo> The ./configure script do not depend on autotools at all
12:34 < dazo> it is only needed in the moment the generated scripts notices the autotools source files have changed
12:34 < jamesyonan> so perhaps the existence of this patch means that people (i.e. Gentoo team) still need to build from svn with older autotools?
12:35 <@mattock> jamesyonan: you mean that with newer autotools build fails?
12:35 < jamesyonan> dazo: I don't understand... autotools generates ./configure 
12:36 < dazo> yes ... and that happens on the host you run autoreconf
12:37 < dazo> then you do 'make dist'  which creates a tarball, including all generated scripts .... like ./configure .... that tarball can be extracted on a box without any autotools at all, and it will work
12:37 < jamesyonan> dazo: no I'm saying that we should inquire a bit deeper before we assume that people don't need to be able to build from svn source on old platforms without duct-tape solutions such as regenerating ./configure on a newer distro
12:38 <@mattock> let's ask people what they think and go from there
12:38 < jamesyonan> dazo: but I'm talking about the svn co 	autoreconf -i -v
12:38 < jamesyonan> 	./configure
12:38 < jamesyonan> 	make dist
12:38 < jamesyonan> method
12:39 < jamesyonan> i.e. not building tarball as intermediate step
12:39 < dazo> jamesyonan: agreed!  Just a question, when you prepare the tarball for release/distribution .... I presume you use 'make dist' or 'make distcheck', right?
12:39 < jamesyonan> yes, sure
12:40 < jamesyonan> but automated build systems often want to build directly from svn
12:41 <@mattock> I'll ask what our users think about this
12:41 < jamesyonan> why don't we accept the patch for now, but float the idea of restricting to latest autoconf version, and see how it flies. 
12:41 < dazo> what I believe can be a cause of this needed patch in Gentoo, which is why I haven't seen it on my platforms (as I build from the git and svn tree) ... is that the distributed tarball then do have a bug (due to the older version) ... which do not make the right usage of AC_GNU_SOURCE .... which means, they added a patch to socket.c to get it compiled properly
12:42 <@mattock> jamesyonan: agreed
12:43 <@mattock> ACK the patch + discuss the autotools issue with our users? agreed? 
12:43 < jamesyonan> ACK
12:43 < dazo> ACK
12:44 <@mattock> ok, on to the next issue
12:44 <@mattock> this should be simpler :)
12:44 <@mattock> [PATCH] The man page needs dash escaping in UTF-8 environments
12:45 < dazo> to summarize it .... in openvpn.8, all -- is changed to \-\- ... for proper UTF-8 escaping .... but, I'm not sure how this influences non-utf8 environments
12:45 <@mattock> I assume the Debian fix has not caused any problems with non-UTF8 encodings
12:46 < jamesyonan> this is probably necessary, but it would be nice if we could re-source the man page source as a more human-readable document
12:46 < jamesyonan> are there automated tools that could convert the existing source to something like docbook?
12:46 < dazo> mattock:  that's often default distro settings .... if Debian switched to utf-8 and introduced this one ... they might not have ran this on non-utf8 in Debian after that switch at all
12:47 <@mattock> dazo: I'll check what happens on my Debian box
12:47 < dazo> jamesyonan:  I don't know ... but I know it is the other way around
12:47 <@mattock> perhaps you could discuss the next issue while I test this?
12:48 < cron2> re
12:48 < dazo> jamesyonan:  I presume this will be a one-time-job ... I'd presume copy-paste from xman or something like that is just as quick and efficient
12:48 < cron2> evening planning changed, I'm here after all :)
12:48 < dazo> \o/
12:48 < dazo> NON_CBC_CIPHER bug / [PATCH] Don't ASSERT() on stream cipher
12:49 <@mattock> hi cron2!
12:49 < dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3286
12:49 < vpnHelper> Title: Gmane Loom (at thread.gmane.org)
12:49 < dazo> (next topic)
12:49 < cron2> hi mattock, dazo, james, d12fk
12:50 < jamesyonan> So basically the assertion is bypassed when mode != EVP_CIPH_CBC_MODE
12:50 < dazo> yeah 
12:51 < jamesyonan> wouldn't it make more sense to modify the assertion so it makes sense for all modes?
12:51 < dazo> my concern is that this is hitting more than just stream ciphers .... so that !=  EVP_CIPH_CBC_MODE  is not the right solution
12:52 <@mattock> regarding the man-page UTF8 fix
12:52 < dazo> "And we found the bug:
12:52 < dazo> function EVP_CipherFinal() returns 0, when cipher has
12:52 < dazo> block_size == 1(stream cipher). So hear is the patch to
12:52 < dazo> fix the bug.
12:52 < dazo> "
12:52 <@mattock> seems to work on both fi_FI.UTF8 and C locales
12:52 < dazo> jamesyonan:  ^^
12:52 <@mattock> searching with less as the pages, e.g.
12:52 <@mattock> /--dev-type
12:52 < jamesyonan> Agreed.  The proper fix should be to assert the correct outlen value for any cipher mode.
12:53 <@mattock> finds everything correctly regardless of the locale
12:53 <@mattock> using Debian testing, ~2 weeks old
12:53 < jamesyonan> mattock:  did you test on old linux versions?
12:54 < dazo> jamesyonan:  I don't follow you now .... the original version does assert() check on all cipher modes, which hurts stream cipher .... the patch does only assert() check when mode == EVP_CIPH_CBC_MODE
12:54 <@mattock> jamesyonan: nope, Ubuntu 9.10 is the oldest I got
12:55 < dazo> mattock:  jamesyonan: RHEL4.6 is UTF-8 by default
12:55 < jamesyonan> dazo: the point of the assert is to verify that EVP_CipherFinal returns an outlen that makes sense to us
12:56 <@mattock> man page seems to work on Ubuntu 9.10 with both UTF8 and C locales
12:56 <@mattock> I can't do more testing than that
12:56 < jamesyonan> we want to establish that outlen makes sense regardless of whether EVP_CIPH_CBC_MODE is being used or not
12:57 < dazo> yes ... and then we're back at the starting point, without this patch, aren't we?
12:57 < dazo> -	  ASSERT (outlen == iv_size);
12:57 < dazo> +	  if (mode == EVP_CIPH_CBC_MODE)
12:57 < dazo> +            ASSERT (outlen == iv_size);
12:57 < dazo> (the patch itself)
12:58 < dazo> outlen != iv_size when a stream cipher is used, that's the core issue .... so, then this assertion needs to be modified then, and not only do this check when mode == EVP_CIPH_CBC_MODE
13:00 < jamesyonan> what is outlen when a stream cipher is used?
13:01 < dazo> "function EVP_CipherFinal() returns 0, when cipher has block_size == 1(stream cipher)."
13:01 < dazo> that's what the commit log says
13:01 < dazo> so I understand that as outlen is set to 0, in this case
13:01 <@mattock> Debian Lenny (stable) man pages seem to work with UTF8 and C, too
13:02 < jamesyonan> well then we should ASSERT(outlen==0) in this case
13:03 < jamesyonan> mattock: can someone test that the man page changes doesn't break early linux versions
13:03 < dazo> jamesyonan:  yeah, I can agree to that one .... which ciphers are stream modes then?
13:04 < jamesyonan> maybe there is an OpenSSL flag that indicates that?
13:04 <@mattock> jamesyonan: I'll send mail to the mailinglists and ask
13:05 <@mattock> [TESTING NEEDED]
13:05 <@mattock> that way we've at least done our best to avoid any problems with old distros
13:06  * dazo need to dig deep into OpenSSL then to figure out that then
13:06 < dazo> jamesyonan:  I'll suggest we NACK this patch, and we'll get either the patch submitter to look at it, or I'll put it into a TODO list
13:07 <@mattock> dazo: preferably let the submitter handle it
13:07 <@mattock> if he's available
13:07 < jamesyonan> +1
13:07 <@mattock> I would not like dazo's TODO-list to grow too long
13:07 < dazo> agreed, but it was submitted in 2006 .... so he might just ignore us now
13:07 <@mattock> dazo: perhaps it's worth the try anyways
13:08 < dazo> mattock:  I was thinking about a public TODO list, where people could take tasks ;-)
13:08 <@mattock> good idea, actually
13:08  * dazo got a way too long personal TODO list already :)
13:08 <@mattock> I think people often have difficulty knowing _how_ to help, even if they're willing
13:08 < dazo> yup!
13:08 <@mattock> what do you think about sending TESTING requests directly to -users ml?
13:09 < dazo> +1
13:09 <@mattock> or rather, both mailinglists
13:09 <@mattock> to reach widest possible audience
13:09 < jamesyonan> OpenSSL defines EVP_CIPH_STREAM_CIPHER
13:09 <@mattock> I don't think a couple of mails a week hurt anyone
13:10 -!- rob0 [~rob0@tuxaloosa.org] has joined ##openvpn-discussion
13:10 < jamesyonan> this can be used to determine if a stream cipher is being used
13:10 < rob0> oh I'm late :)
13:10 <@mattock> rob0: welcome!
13:10 < dazo> jamesyonan:  good one! I'll write it down .... and I'll respond with this info to the sf.net tracker 
13:10 < cron2> reb0: 70 minutes :-) - but welcome anyway!
13:11 < rob0> :)
13:11 < rob0> (I thought it was 1900)
13:11 <@mattock> dazo: so the cipher issue is settled (for now)?
13:11 < cron2> rob0: in MET, it is :)
13:11 < jamesyonan> In general, I think it's a good idea to support non-CBC cipher modes
13:11 < dazo> mattock:  yup!
13:12 <@mattock> ok, a brief summary at this point...
13:12 < cron2> rob0: we moved the meeting to "one hour earlier" two weeks ago, to better accomodate dazo's schedule
13:12 <@mattock> ACK the Gentoo patch, ask for old autotools support in ml 
13:12 <@mattock> the man page UTF8 patch: ask users to test on older distros (pre-Debian Lenny)
13:13 <@mattock> cipher bug is handled by dazo
13:13 <@mattock> should we try to cover a couple more?
13:14 <@mattock> oh, and the HMAC issue is waiting for more info from Jessica
13:14 <@mattock> what about this: "An update on the --passtos for tagged ethernet frames"
13:14 < dazo> mattock:  I'd like to hand-over the next phases of the --passtos patch ... I got in contact with the patch developer ... and I have a "test script" ... how to test docs .... 
13:14 < dazo> somebody up to follow up that one further?
13:15 < dazo> (the patch submitter is using the patch in a bigger environment with some 100 clients, if I understood it correctly)
13:16 <@mattock> dazo: what should be done next?
13:16 < dazo> mattock:  Development TODO list - http://www.secure-computing.net/wiki/index.php/OpenVPN/Development-TODO
13:16 < vpnHelper> Title: OpenVPN/Development-TODO - Secure Computing Wiki (at www.secure-computing.net)
13:16 <@mattock> I mean with --passtos patch :)
13:16 < dazo> mattock:  somebody should test out the test documentation I got ... put it on a wiki ... and ask for testers
13:17 <@mattock> where's the test documentation? could I do the job (=does it require programming in C :)
13:17 < dazo> the --passtos patch are in the git tree ... but not merged into allmerged yet ... we wanted some separated testing on it first, to see/check that it works and doesn't break anything for people not using tagged ethernet frames and/or --passtos
13:18 <@mattock> ok, I can organize the testing
13:18 < dazo> mattock:  I'll mail it to you .... no C programming ... it looks pretty easy, with example config files, tcpdump examples etc etc
13:18 <@mattock> dazo: ok
13:18 <@mattock> I'll do the documentation and send testing requests to ml's
13:19  * dazo mails testing docs to mattock 
13:19 <@mattock> we'd have this last one (before SF.net tracker stuff): Supporting "route-gateway dhcp" on non-Windows
13:19 <@mattock> rob0: the topics are here: http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings/Topics-2010-03-11
13:19 < vpnHelper> Title: OpenVPN/IRC meetings/Topics-2010-03-11 - Secure Computing Wiki (at www.secure-computing.net)
13:20 < dazo> here jamesyonan must have been flooded by mails :)
13:20 < d12fk> i have no real opinion, but the strong feeling that this should be "fixed" by the distributions or it might break more than it fixes
13:21 <@mattock> d12fk: I tend to agree
13:21 <@mattock> implementing a DHCP client in OpenVPN would cause problems if other DHCP clients are running (which is often the case)
13:22 < dazo> I tend to agree as well .... except ... I worry it will be a maintenance hell for OpenVPN to have a flexible enough solution to make this work with all kind of different solutions each distribution uses
13:22 <@mattock> I don't think anybody in the ml had a really good, generic solution to this problem
13:22 < cron2> mattock: on the ML, there are people that know how to do cross-platform portability, and people that know their own teeny little operating island...
13:22 < dazo> that's the thing ... we don't want to introduce a DHCP client for all interfaces .... just for the TAP device being created for openvpn
13:22 < cron2> and the teeny little island people all assume that the teeny little island way of doing things is "so easy that everbody must see this"
13:23 < rob0> Is this "route-gateway dhcp" thing only for tap, or also for tun?
13:23 < cron2> dazo: not just "distributions".  "Operating systems" as well (*BSD, MacOS, Solaris)
13:23 <@mattock> and "other" operating system distributions (DragonflyBSD, PC-BSD or whatever) 
13:24 <@mattock> tons and tons of different DHCP approaches
13:24 < dazo> when OpenVPN acts as a DHCP client .... it will not care about other devices on the box ... that way, it will be rather restricted
13:24 < dazo> but, the disadvantage .... what to do with /etc/resolv.conf updates?
13:24 < rob0> IIUC in Slackware Linux, the trigger for the rc.inet1 script (which configures interfaces) is sent by udevd.
13:25 < dazo> Many distributions (Fedora, RHEL, Novell SuSE, openSuSE, Ubuntu) uses NetworkManager
13:25 < jamesyonan> What if we implement an internal DHCP client within OpenVPN, but have it only activate on platforms known to not implement automatic binding between the TAP interface and a DHCP client
13:25 < rob0> Also, some folks might be running dnsmasq or similar, and not want any changes to resolv.conf ...
13:25 < dazo> jamesyonan: I believe that's basically the vast majority of *nix ....
13:25 <@mattock> is there any real disadvantage for letting OS/distribution guys handle the integration? After all, they all know their own environment so integration should not be a big chore. Compared to what we might encounter
13:26 < jamesyonan> The internal DHCP client would translate attributes received from the DHCP server into route, ifconfig, and dhcp-option
13:26 <@mattock> rob0: for example me
13:26 < dazo> mattock:  then I would suggest them to use --up script hook .... and OpenVPN don't need to be used
13:26 < dazo> s/used/changed/
13:26 < cron2> mattock: how will you get those OS/distribution guys todo that?
13:27 < jamesyonan> then the dhcp-options would follow the normal "foreign option" pathway within OpenVPN that is already defined for Mac OS X and other non-Windows OSes
13:27 < rob0> Maybe the documentation could provide a few distro-specific up scripts, and that's as good as it can be.
13:27 <@mattock> cron2: I guess we should just make it as easy for them as possible (document, provide examples etc)
13:27 <@mattock> as rob0 suggested
13:28 <@mattock> provided that the distro guys _would_ indeed do the integration with external DHCP clients - what benefits would an internal OpenVPN DHCP client provide
13:28 < rob0> I could do one for Slackware, but it might take a week or more to get a round tuit.
13:28 <@mattock> compared to that
13:29 < dazo> then somebody needs to maintain those scripts .... what to do when it breaks, the maintainer don't respond and nobody else comes up with a fix ?  we stop supporting it?
13:29 < rob0> yeah, that's about it, unfortunately
13:30 <@mattock> so no good solutions, eh :|
13:30 < cron2> mattock: adapting to ever-changing distributions and operating systems will always fall back to the package maintainer
13:30 < jamesyonan> dazo: are you familiar with the "foreign-option pathway" for etc/resolv.conf updates?  Tunnelblick uses it when dhcp-option directives are pushed 
13:30 < dazo> jamesyonan:  I have not looked at that one, tbh 
13:31 < dazo> I believe that's similar to what Debian might use, on second thought
13:31 <@mattock> cron2: so you think we should let them handle this issue?
13:31  * dazo looks up a long
13:31 < dazo> *link
13:31 < cron2> jamesyonan: where is that documented?  It's not in the openvpn.8 man page
13:31 < cron2> mattock: no, I find adaption to "the linux fancy of the week" too painful
13:33 < cron2> mattock: well.  What I wanted to say is: if we leave that to the distro and OS maintainers, some of them will do a good job, and others won't do anything.  So you have a long list of "this feature works on OS X, Y and Z, but not A and B".
13:33 < dazo> http://www.phocean.net/2006/12/07/openvpn-and-dns-on-a-linux-client.html ... the last script on the page
13:33 < vpnHelper> Title: Phocean.net » OpenVPN and DNS on a linux client (at www.phocean.net)
13:33 < cron2> Eventually, Z will change their setup to use DHCP client V instead of W, and the scripts will break.  Then who will adapt?
13:33 <@mattock> cron2: agreed, it's going to be painful... but if the distro's DHCP clients (e.g. NetworkManager, dhclient) autodetect the OpenVPN network adapter they might break things for the built-in OpenVPN DHCP client anyways
13:34 <@mattock> that's the impression I got from the ml discussions
13:35 < jamesyonan> cron2: foreign-option is briefly described in the man page
13:35 < jamesyonan> at the end of dhcp-option section
13:35 < cron2> mattock: if the distro's DHCP client starts messing with OpenVPN's interfaces, things will break in really exciting ways
13:35 < dazo> exactly .... and all this, is why I think it is a better solution in the end to have a simple DHCP client inside OpenVPN which only cares about the TAP device it has configured .... and with the upside, support for TUN devices might be closer as well - if the server side can act as a DHCP relay
13:36 < cron2> jamesyonan: it's spelled foreign_option here, so my search didn't find it.  Got it now, thanks.
13:36 < dazo> cron2:  that's a good point
13:36 < cron2> mattock: even if you have statically configured tun/tap devices within OpenVPN - and then the distro goes ahead and removes that and does DHCP.  Or whatever it feels like doing.
13:37 <@mattock> so a built-in DHCP client is the least bad solution?
13:37 < rob0> Could we be headed toward a split of openvpnd and openvpnc server/client?
13:38 < dazo> mattock:  in my opinion, yes
13:39 <@mattock> and it's worth the trouble I assume?
13:39 < jamesyonan> I'm not sure that splitting makes sense because there is so much shared code.  Of course if you just want a client or server-only build, you can use build options for that.
13:39 < dazo> mattock:  if we do that, we can at least document that no DHCP clients should be run on the TAP device when the internal DHCP client is enabled ... that way, people who try  that will fail - and it's not our fault
13:40 <@mattock> dazo: sounds like a good approach
13:40 <@mattock> so what to do about this then? what concrete steps to take?
13:41 < dazo> I believe jamesyonan asked the question on the ML to get some feedback ... and we've summarised it here now ... so, I'd probably hand it back to jamesyonan again for the next steps :)
13:41  * cron2 agrees
13:42 <@mattock> yeah, I was wondering where this issue originated from :)
13:42 < dazo> jamesyonan was did a brave move .... and probably got a full inbox as a result :)
13:42 < jamesyonan> I think this is an important feature, because it really allows for zero-configuration TAP-based VPNs
13:43 <@mattock> only ~35 mails
13:43 < dazo> agreed!  And it has been missed!
13:43 <@mattock> who shall get to work?
13:43 <@mattock> :)
13:43 <@mattock> dazo: you're excluded, you have too much work as it is :)
13:43 < dazo> lol
13:44 < dazo> \o/
13:44  * dazo is happy!
13:44 < jamesyonan> well I think the ML discussion was a good exercise because it shows that leveraging on the distro DHCP client is not a panacea.
13:45 <@mattock> yeah, it was a really good discussion
13:46 <@mattock> if we don't do anything concrete right now, I suggest I'll write a short summary of the ml discussions and this discussion... so that when somebody starts working on this he knows what is the best approach
13:46 < dazo> jamesyonan:  and you feel you now know enough to know which approach you will go for?
13:47 < jamesyonan> yeah, I'm definitely leaning towards the internal DHCP client approach
13:47 <@mattock> jamesyonan: is this something you're going to be implementing yourself?
13:47 < jamesyonan> it's definitely something I'm considering
13:48  * dazo would suggest putting all such tasks which has not been started to the Developer-TODO page ... if somebody wants a challenge, that's where to look
13:48 <@mattock> ok, I'll refrain myself from writing a lengthy summary of the findings, then
13:48 <@mattock> dazo: agreed - I can write a _short_ summary there :)
13:49 < dazo> mattock:  yeah ... just describe the feature we want .... then refer to discussions on ML and in this irc log ....
13:49 <@mattock> will do
13:49 <@mattock> I think we should leave SF.net patch tracker issues aside (again)
13:49 < dazo> mattock:  I'll also suggest the ML discussions to be linked against gmane.org ... it's way more organised and easier to read, IMHO
13:50 <@mattock> ok, I'll do that
13:50 <@mattock> it's a cleaner and faster interface
13:50 < dazo> mattock:  yeah .... I'm waiting for the community server ... with Trac ;-)
13:50 < dazo> (for TODO/Roadmap features)
13:50 <@mattock> me too :)
13:51 < dazo> I think that concludes today, or?
13:51 <@mattock> it should be up _really_ soon (when my Apache2 private key arrives)
13:51 <@mattock> dazo: agreed
13:52 < dazo> Thanks a lot, guys, for a great meeting again!
13:52 <@mattock> I'll summarize this meeting tomorrow, as usual
13:52 < d12fk> see you next week then
13:52 <@mattock> with links to gmane
13:52 <@mattock> see you all later!
13:52 < dazo> c'ya!
13:52 < jamesyonan> bye!
13:52 < cron2> good night :) and bye
13:52 < d12fk> take care
13:53 -!- d12fk [~quassel@88.130.204.210] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
13:53 -!- dazo is now known as dazo_afk
13:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has left ##openvpn-discussion []
14:18 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
15:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
15:49 -!- rob0 [~rob0@tuxaloosa.org] has left ##openvpn-discussion ["until next week"]
16:47 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
--- Day changed Fri Mar 12 2010
03:19 -!- dazo_afk is now known as dazo
03:39 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
04:32 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
05:04 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
05:04 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
06:42 -!- mape2k [~mape2k@150.200.116.85.dsl.manitu.net] has joined ##openvpn-discussion
06:47 -!- mape2k [~mape2k@150.200.116.85.dsl.manitu.net] has quit [Ping timeout: 260 seconds]
06:59 -!- mape2k [~mape2k@150.200.116.85.dsl.manitu.net] has joined ##openvpn-discussion
07:05 < dazo> mattock:  I saw your mail in regards to the DHCP client discussions ... I updated the wiki with some more details
07:05 <@mattock> great!
07:06 <@mattock> btw. do you have a "feature" tree for the man-page utf8 patch?
07:06 <@mattock> I'm going through the Debian testing patches to find if the manpage patch is included there
07:06 <@mattock> the idea being that I can provide really easy testing instructions for users
07:07 <@mattock> e.g. patching the git source is probably too much for most
07:07 < dazo> mattock:  I'll planned to put it into the bugfix2.1 branch ... or I could put it into feat_misc
07:07 <@mattock> anything goes as long as it's easy for the potential testers
07:07 < dazo> it's not a new feature in my opinion ... it's a bug fix
07:08 < dazo> :)
07:08 <@mattock> I'll check the debian package .diff and if debian testing includes that patch, I'll send the whole manpage for testing
07:08 <@mattock> man ./openvpn.x
07:08 < dazo> I won't have time to do much before the evening today ... but I plan to get ACKed stuff into allmerged when your meeting minutes comes out :)
07:08 <@mattock> can't get more straightforward than that
07:08 < dazo> nope :)
07:09 <@mattock> they minutes are already in the pipeline, so you're in a hurry
07:09 <@mattock> ;)
07:09 <@mattock> in fact, they just arrived
07:09 <@mattock> 9 minutes ago
07:09 < dazo> heh :-P
07:10 < dazo> Ahh ... now it popped in :)
07:10 <@mattock> ok, the man-page patch is also in debian testing, I'll sent the mail now
07:27 < dazo> agi:  patches begins to flow in ... thx a lot!  I'll look at it (very much) later today ... hopefully get several of them out for review to the ML ... some of them should really be included upstream!
07:36 <@mattock> sent [TESTING NEEDED] for the man-page
07:37 <@mattock> dazo: what about the --passtos thingy... did you send me the test documentation? (=did I overlook it :)
07:37 < dazo> mattock:  ahh ... sorry about that ... not come that far
07:37 <@mattock> that's fine, I'm almost done for today (~30 minutes left) :) 
07:38 < dazo> mattock:  no prob :) I'll dig it up and fwd you it
07:38 <@mattock> no probs, I have stuff to do for the rest of the day
07:39 < dazo> mattock:  mail sent
07:39 <@mattock> oh, the man-page was too big so -users rejected the mail
07:39 < dazo> mattock:  nah ... I need to keep your pipe full as well :-P
07:39 <@mattock> gotta put it to my web-pages
07:39 < dazo> mattock:  yeah ... remember that discussion with james on -devel?  it was the same patch ;-)
07:39 < dazo> mattock:  I'll update the git tree soon
07:39 <@mattock> yep :)
07:39 < dazo> mattock:  then it's just to pick it from there
07:40 <@mattock> you mean man-page or --passtos?
07:40 <@mattock> or both?
07:40 < dazo> mattock:  man-page
07:40 <@mattock> ok
07:40 < dazo> --passtos is already available in the feat_passtos branch ... but not merged into allmerged yet
07:42 < dazo> mattock:  ahh ... I re-read the minutes now .... and I thought the utf-8 patch got an ack
07:42 <@mattock> nope, only after more testing (or lack of volunteer testers :)
07:42 < dazo> yeah ... 
07:43  * dazo probably need to create a separate branch  then .... well, branches are cheap
07:45 < dazo> mattock:  manpage_utf8 branch ... there you go :)
07:46 <@mattock> I'll take a look
07:46 < dazo> mattock:  btw. agi sent me the latest version being used in Debian ... If there are sensible differences, I'll probably go for the Debian version in the end - as that's probably more updated
07:46 <@mattock> of the man page?
07:46 <@mattock> :)
07:48 < dazo> yeah
07:48 < dazo> but the manpage_utf8 stuff ... that's just to see if this -- -> \-\- breaks stuff ... that's what the whole patch does
07:50 <@mattock> is there a way to get only the man-page from Git manpage_utf8 branch (e.g. using the web-based Git browser)?  
07:55 <@mattock> for simplicity I'll put the Debian openvpn.8 to my web page and provide a link to that
07:55 < dazo> yeah, sure .... 
07:55  * dazo finds the URL
07:55 <@mattock> it does not seem to contain any other modifications besides \-\-
07:56 < dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob_plain;f=openvpn.8;hb=c410d6f1408b8c23c0fc2a6e0efc48c03c3dce42
07:56 < dazo> The way how to do find this is:
07:56 < dazo> - http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary
07:56 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/summary (at openvpn.git.sourceforge.net)
07:57 < dazo> - click on the branch you want to get a particular file from ... down on the screen
07:57 < dazo> - In the commit list you find the commit you are interested in ... and then click on "tree" to the right of the commit line
07:58 < dazo> - Find the file .... and click on "raw" to get it in a downloadable format
07:58 < dazo>  .... that's the version of the file as found in that commit
07:59 <@mattock> ok, thanks! I'll try that (the Git web UI was rather confusing)
07:59 < dazo> yeah, it can be a bit confusing when not being used to it :)
07:59 <@mattock> yep, works!
08:00 <@mattock> I'll link to that instead
08:00 <@mattock> (so now we get testing for the Debian version in -devel and the git version in -users
08:00 <@mattock> although they are probably the same
08:00 < dazo> in case you don't know .... by encapsulating URLs with <> in mails ... the mail client should not wrap long URLs when showing it
08:01 < dazo> yeah ... such things happens :-P
08:02 <@mattock> too bad I already sent the mail ;)
08:02 <@mattock> but a good tip for next time
08:08 -!- mape2k [~mape2k@150.200.116.85.dsl.manitu.net] has quit [Ping timeout: 260 seconds]
08:09 < dazo> I'm looking at this as the whole new working model is in need of some tweaks on the way .... we can't be experts from the very beginning :-P
08:28 <@mattock> woah, managed to send the autotools mail to -users
08:28 <@mattock> almost forgot, my internal todo-tracker is rather lousy
08:29 <@mattock> got to go fell some elms
08:30 <@mattock> =cut down trees ;)
08:36 < dazo> heh
08:37 < dazo> but that's not bad anyway ... they know something is happening, it might raise some attention with some more people who's not signed up to -devel as well
08:38 < dazo> And I think Alon Bar-Lev gets happy now to see this discussion finally surface
09:05 -!- mape2k [~mape2k@l208.fem.tu-ilmenau.de] has joined ##openvpn-discussion
09:23 < agi> re
09:23 < agi> back from lunch, will send the rest of the patches now
09:24 < dazo> agi:  cool, thx!
09:24 < agi> sure, thank you :)
09:55 < agi> now that you (both) are (kind of) around
09:56 < agi> where/how should I pull the source to build the weekly packages for experimental and the (daily) builds?
09:57 < agi> I'm *really* over worked these days, but I'll try to keep up with openvpn as much as possible
09:57 < agi> (yesterday I had to work till 22, that's why I missed the meeting)
09:59 < dazo> no prob ... well, ecrist has done some work on preparing a snapshot tarball ... that's one approach
10:00 < ecrist> dazo, is the tree currently stable?
10:00 < ecrist> looking at rolling a -devel port snapshot this weekend.
10:00 < dazo> or the other one is to clone the git tree, and update that .... bootstrap the source tree (in the allmerged branch, there's a bootstrap script, which is useful for weekly runs)
10:01 < dazo> ecrist:  a development tree is never stable ;-)   But it should be possible to compile cleanly from this tree
10:01 < agi> any (dis)advantage in choosing one or another?
10:01 < ecrist> I won't build against an unstable state, that's why I'm asking.
10:02 < dazo> ecrist:  might be we have different interpretations of stable/unstable .... for me, stable is what is in James SVN tree ... that's suitable for production .... unstable is the openvpn-testing tree which has experimental features which needs testing 
10:03 < dazo> ecrist:  I will always try to make sure that the allmerged branch will compile .... but if something breaks, due to bugs in the code, that's another issue - and that's what we want to figure out with the testing
10:03 < ecrist> 89 people downloaded week 7 rollup on freebsd
10:05 < dazo> agi:  well, using ecrists tarball might save you some time .... but I think he has a weekly schedule on that .... using git tree directly gives you the very latest changes when you roll your own packages
10:06 < ecrist> my last rollup was week 7
10:06 < dazo> agi: the only thing which would be beneficial ... is that you have a look at the bootstrap script ... it changes the version number of OpenVPN to the last allmerged commit ID, to more easily track where something broke
10:06 < dazo> ecrist:  you don't do weekly snapshots?  I thought that was your plan
10:07 < ecrist> it was, but I have a social life, as well.
10:07 < ecrist> the port commit process takes about a week, so i'd be a dog chasing his tail
10:08 < dazo> I see
10:08 < dazo> but would it be possible for you to create weekly tarballs at least for download?
10:10 < ecrist> sure, I can do that with cron
10:10 < dazo> (it's about 35 or so new commits during those three weeks)
10:10 < dazo> ecrist:  that'd be great, if you can
10:10 < ecrist> I'll set it up this weekend, dazo
10:10 < dazo> cool!
10:10 < ecrist> it's going to be bootstrapped on freebsd, if that matters
10:11 < agi> i guess the commit ID is something important if things break
10:11 < agi> so I guess I'll use the git repo
10:12 < dazo> agi:  that's right :)  Then it's easier to start bisecting to find the offending commit
10:12 < dazo> agi:  the tarball from ecrist also has that commit ID
10:12 < dazo> just to have mentioned that :)
10:12 < agi> heh, ok, so I'll trow a coin and 'decide'
10:13 < dazo> agi:  do what suites you best ... and if there are things we can automate or improve to make your life easier ... please send suggestions, especially if it can save others time as well :)
10:13 < agi> ecrist: could I check your cron/script when it's ready(tm)?
10:14 < ecrist> a current rollup is available now at ftp://ftp.secure-computing.net/pub/FreeBSD/ports/openvpn-devel/
10:32 < ecrist> I just sent a port update for 201010
10:32 < ecrist> agi, which script(s) do you want?
10:32 < dazo> thanks!
10:39 < agi> ecrist: what ever you use to create the tarballs, if that's ok with you. Just to figure out if it's easier to use your tarballs or to clone the git repo
10:44 -!- mape2k [~mape2k@l208.fem.tu-ilmenau.de] has quit [Ping timeout: 258 seconds]
10:49 < agi> gotta go, see you guys
12:10 < ecrist> would probably be easier to use mine
12:35 -!- fjutscha [~fjutscha@dslb-084-057-115-101.pools.arcor-ip.net] has joined ##openvpn-discussion
12:37 -!- fjutscha [~fjutscha@dslb-084-057-115-101.pools.arcor-ip.net] has quit [Client Quit]
12:41 -!- dazo is now known as dazo_afk
13:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
14:00 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has left ##openvpn-discussion ["Leaving"]
14:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
14:43 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds]
15:32 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer]
15:32 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
15:32 -!- mode/##openvpn-discussion [+v Kas] by ChanServ
16:30 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
16:43 < cron2> ecrist: as far as ipv6_payload goes, the current -testing is "stablish" - everything I committed last week has been tested on a number of OSes and *should* work.  This weekend, I have *no* time, so "no changes from my side"
22:26 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
--- Day changed Sat Mar 13 2010
02:43 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
02:50 -!- krzee [nobody@unaffiliated/krzee] has joined ##openvpn-discussion
02:52 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
03:22 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out]
04:39 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined ##openvpn-discussion
07:55 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has left ##openvpn-discussion []
--- Log closed Sat Mar 13 07:55:13 2010
--- Log opened Thu Mar 25 13:05:33 2010
13:05 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has joined ##openvpn-discussion
13:05 -!- Irssi: ##openvpn-discussion: Total of 13 nicks [1 ops, 0 halfops, 1 voices, 11 normal]
13:05 -!- Irssi: Join to ##openvpn-discussion was synced in 1 secs
13:05 <@mattock> james, here are some topics for this week, mostly leftovers from last week: http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings/Topics-2010-03-25
13:05 < vpnHelper> Title: OpenVPN/IRC meetings/Topics-2010-03-25 - Secure Computing Wiki (at www.secure-computing.net)
13:06 <@mattock> perhaps I'll give a brief update about community site status - it's been a while since last time
13:07 <@mattock> so there's only one thing missing, which is proper backups to our own backup server
13:07 -!- rob0 [~rob0@tuxaloosa.org] has joined ##openvpn-discussion
13:08 <@mattock> ecrist already provides us with backup service (thanks Eric), which is already in use
13:08 < ecrist> :)
13:08 <@mattock> the rest of the infrastructure (e.g. LDAP, OpenVPN VPN) is already in place and working properly
13:09 <@mattock> forums server is work in progress, as it requires that people can create user accounts themselves
13:10 <@mattock> this self-service registration will be accomplished with "pwm" (a Java webapp), which writes account information to LDAP, which all services (trac, forum software etc.) will be using
13:11 <@mattock> I'm currently configuring pwm and it's servlet container (tomcat)
13:11 <@mattock> so, in a nutshell, the Trac instance can be launched pretty soon, whereas forums will take a little longer
13:11 <@mattock> initially Trac accounts will have to be manually created (by me)
13:12 <@mattock> so it's mainly for core developer use at first
13:12 <@mattock> that's about it, I guess
13:13 -!- waldner [~waldner@unaffiliated/waldner] has joined ##openvpn-discussion
13:14 < jamesyonan> sounds good
13:15 <@mattock> I just send dazo email, just in case
13:15 <@mattock> I'll check if we could start discussing some of the issues without David 
13:16 <@mattock> did we get any resolution to this cn issue: https://sourceforge.net/mailarchive/forum.php?thread_name=d8e57f271003021006v36871150obc7080725bc6efb3%40mail.gmail.com&forum_name=openvpn-users
13:16 < vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-users (at sourceforge.net)
13:16 < jamesyonan> re: warnings -- these are mostly to help people out.  For example in pre-2.1 releases, we didn't have script-security.  Since the addition of script-security was not backwards compatible, the warning tells people immediately why their old config doesn't work.
13:18 < jamesyonan> someone was supposed to check if this issue is triggered by mid-session reauth
13:18 <@mattock> I think Jan volunteered for the job :)
13:18 <@mattock> I don't think he managed to reproduce the problem
13:18 <@mattock> I'll check
13:19 <@mattock> one thing not on the agenda is the HTTP proxy server issue
13:20 <@mattock> the bug reporter responded to me and the proxy server he encountered the problem with was T-mobile something
13:20 <@mattock> not a widely used one
13:21 <@mattock> given there are no other bug reports, I think dazo thought it best to close the report as wontfix
13:22 <@mattock> I think the autotools issue has not yet been covered fully... in a nutshell, nobody complained @openvpn-users when I asked about deprecating old autotools support
13:22 <@mattock> also, there are plenty of workarounds for old OS'es (use autoreconf on another host, install newer autotools version etc.)
13:23 <@mattock> so if new autotools makes sense for any reason, I think we should start using it
13:23 <@mattock> james, what do you think?
13:26 < jamesyonan> I'm not really gung-ho about the autotools change since I have some automated build scripts that need to extract from svn and build on many different linux platforms, including RHEL 4.  But I don't want to hold this back if I'm the only one complaining.
13:26 <@mattock> I agree that the newer version should provide some useful enhancements before the change is made
13:26 <@mattock> changing it for the sake of change does not make sense
13:28 <@mattock> what about this one: http://sourceforge.net/tracker/index.php?func=detail&aid=1933593&group_id=48978&atid=454719
13:28 < vpnHelper> Title: SourceForge.net: OpenVPN: Detail: 1933593 - 2.1rc7 - apphelp.dll missing on Vista dual OS installation (at sourceforge.net)
13:28 <@mattock> any idea whether this is still valid?
13:30 <@mattock> I suppose having a couple of Windows installations side-by-side is pretty common
13:30 < jamesyonan> I haven't heard about this issue recently.
13:31 <@mattock> any idea if it has been fixed?
13:31 <@mattock> actively I mean :)
13:31 <@mattock> or is it just that people are not reporting their problems
13:31 -!- d12fk_ [~quassel@88.130.205.253] has joined ##openvpn-discussion
13:33 < jamesyonan> usually if a problem is real, there will be many reports and it will be fixed quickly
13:34 <@mattock> also, where is "route.exe" coming from? is it built-in to Windows?
13:34 < jamesyonan> yes
13:34 <@mattock> does OpenVPN pass any parameters (e.g. dll locations to it)
13:34 <@mattock> ...locations) to it?
13:35 <@mattock> looks as if route.exe itself is messing things up
13:35 < jamesyonan> there is code that sets the PATH before calling route
13:36 <@mattock> ok, so that might be the problem
13:37 <@mattock> is there some common approach / piece of code in OpenVPN for detecting Windows settings such as the location of system32 directory?
13:37 < d12fk_> hi there
13:37 <@mattock> hi d12fk
13:38 < d12fk_> well, we had a report from a user abou this issue a while ago
13:38 < d12fk_> he had vista on C: and XP on D: and the route.exe from vista didn't run with the crt.ddl from XP iirc
13:38 < d12fk_> sry .dll
13:39 <@mattock> d12fk: did he use --win-sys env (as janjust suggests)
13:39 < d12fk_> no, we don't have that parameter in our default config
13:40 < d12fk_> win-sys would have probably fixed it, but why not make it work by default and get the right value from the registry?
13:40 <@mattock> james: so by default c:\windows is used, but "--win-sys env" can autodetect the correct directory?
13:40 < ecrist> hrm
13:40 <@mattock> d12fk: that would sound like a good approach
13:41 <@mattock> it would be "the Windows way" at least
13:41 <@mattock> and less prone to error I guess
13:42 < d12fk_> i plan to hack up a "registry" parameter for win-sys and make that the default
13:42 < d12fk_> but currently lacking the time to do it
13:42 < jamesyonan> mattock: yes
13:43 <@mattock> james: what do you think about checking the correct path from the registry by default as d12fk suggested?
13:43 <@mattock> any problems with that approach?
13:46 < jamesyonan> I'm fine with that if it can be done in a portable way that works on Win2K -> Win 7.
13:47 <@mattock> ok, I guess that would be an ideal candidate for an open task (http://www.secure-computing.net/wiki/index.php/OpenVPN/Open_tasks)
13:47 < vpnHelper> Title: OpenVPN/Open tasks - Secure Computing Wiki (at www.secure-computing.net)
13:47 <@mattock> I'll add it there
13:47 < d12fk_> jamesyonan: as far as I know MS they drive backwards compatibility to the max, so i guess it will be
13:48 <@mattock> then there's this, janjust closed it already, but perhaps we could drive a couple of more nails to it's coffin: http://sourceforge.net/tracker/?func=detail&aid=2078470&group_id=48978&atid=454719
13:48 < vpnHelper> Title: SourceForge.net: OpenVPN: Detail: 2078470 - multiple up scripts and no error (at sourceforge.net)
13:48 <@mattock> jamesyonan: do you agree with janjust's comment?
13:50 < jamesyonan> re: multiple up scripts, OpenVPN doesn't support it currently
13:50 < jamesyonan> mattock: which comment?
13:50 <@mattock> the one at the end of the bug report
13:51 <@mattock> actually it seems that the report was closed by SF.net robot, not janjust
13:51 <@mattock> so it's still open
13:53 < jamesyonan> yes, I generally agree with janjust's comment -- the ability to override options with subsequent options is important.  Maybe we just emit a warning in this case?
13:54 <@mattock> do you think extending the warnings to all options would make sense?
13:55 < d12fk_> but the cmdline options are parsed before the ones from the config file, aren't they?
13:56 < jamesyonan> d12fk: not really:  you could say openvpn --config foo.conf --up myscript
13:57 < jamesyonan> the --up myscript would override any "up" in foo.conf
13:58 < d12fk_> so the parser is descending? --up followed by --config would be the other way around?
14:00 < jamesyonan> yes, the parser is processing the command line from left to right
14:01 < jamesyonan> the --config option in the command line is like a macro that expands all the directives from the file at that point in the command line
14:02 <@mattock> could we check for duplicate directives when the config file is expanded?
14:02 <@mattock> or how does it work?
14:02 < d12fk_> ok, but then the warning should only appear if the redefinition happens at the same config "level" or depth
14:02 <@mattock> I think it'd be a good idea to warn about errors in the config file (regardless of whether the options are overridden later)
14:03 < d12fk_> mattock: thats what a meat
14:03 < d12fk_> jesus... i mean: what i meant =)
14:04 <@mattock> d12fk: do you mean depth like in <connection> blocks?
14:05 < jamesyonan> "the warning should only appear if the redefinition happens at the same config "level" or depth": that makes sense
14:05 < d12fk_> mattock: no, iirc the option parser works recursively, so it's the recursion depth i mean
14:06 <@mattock> ok
14:07 <@mattock> so we all agree that this is worth fixing?
14:07 <@mattock> =should not be closed as wontfix
14:08 < d12fk_> ack
14:08 < jamesyonan> +1
14:08 <@mattock> ok, I'll reopen the bug report
14:09 <@mattock> done
14:09 <@mattock> have we discussed this already: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574164
14:09 <@mattock> that's the last one, btw
14:09 < vpnHelper> Title: #574164 - openvpn: Assertion fails in socket.c:429 in p2p mode due to Debian ipv6 patch - Debian Bug report logs (at bugs.debian.org)
14:12 <@mattock> I'm not sure if that's valid - I think that report has to do with the old IPv6 patches which are now in "testing"
14:12 <@mattock> maybe valid for Debian, but not necessarily for testing tree in general
14:12 <@mattock> and definitely not for stable openvpn
14:13 <@mattock> I think we can't really do anything about that report right now...
14:13 <@mattock> agreed?
14:14 < jamesyonan> can someone indicate the source code line that corresponds to socket.c:429 in Debian build?
14:14 < d12fk_> let me take a look at the assertion
14:18 < d12fk_> hm, no ASSERT at 429 in allmerged or feat_ipv6_transport
14:18 <@mattock> I assume Debian is using an older version of the ipv6 transport patch?
14:19 < d12fk_> there are some close to 429
14:21 <@mattock> I'll quickly check the source package for Debian testing/unstable
14:24 <@mattock> ...takes a while
14:26 <@mattock> hmm... I downloaded the Debian testing sources and applied the patches manually
14:26 <@mattock> no assert on line 429
14:27 < d12fk_> probably best to talk to agi directly then
14:27 <@mattock> I think we should leave this alone until somebody can provide additional information
14:27 <@mattock> yep
14:28 <@mattock> Jamesyonan: there's still the little typo in http://openvpn.net/howto.html: mimimal instead of minimal
14:28 < vpnHelper> Title: Error 404: File not Found (at openvpn.net)
14:28 <@mattock> I think we covered everything we can for today
14:28 <@mattock> or is there something else we should cover?
14:30 < d12fk_> i might want to announce that i'm developing on openvpn-gui again
14:30 <@mattock> so is that the original OpenVPN GUI? It's just taht there are like ~100 GUI's out there ;)
14:30 <@mattock> that
14:30 < d12fk_> the one that openvpn.net ships
14:31 < d12fk_> mathias lost interest and didn't answer my mails so i moved i to sf.net
14:31 <@mattock> what's the URL?
14:32 < d12fk_> no web as of yet but you can start at openvpn-gui.sf.net
14:33 < d12fk_> will publically announce once i have the code cleaned up
14:33 < d12fk_> mattock: interested in translating to finnish?
14:33 < jamesyonan> are you going to use the management interface?
14:33 < d12fk_> yes
14:33 < jamesyonan> cool
14:33 < d12fk_> in the mid term
14:34 <@mattock> d12fk: how many strings are there?
14:34 <@mattock> translatable strings I mean
14:34 < d12fk_> many
14:35 <@mattock> many like in 200 or many like in 5000 (the biggest app I've translated)?
14:35 < d12fk_> let me grep
14:35 <@mattock> (or was it 3000, can't remember exactly)
14:35 <@mattock> it _was_ many, though ;)
14:37 <@mattock> I'd guess OpenVPN GUI would be around 100-300
14:37 < d12fk_> 141 strings
14:38 <@mattock> ok, it's a couple of hour's work 
14:38 <@mattock> plus some testing
14:38 <@mattock> I think that's doable :)
14:38 <@mattock> I can do it
14:38 < d12fk_> plus some dislogs
14:38 < d12fk_> dialogs
14:39 < d12fk_> ~15 strins each
14:39 <@mattock> ok, still not much
14:40 <@mattock> d12fk: let me know when you want OpenVPN GUI translated
14:40 < d12fk_> look at the .rc files in git
14:41 <@mattock> where shall I send the translated files?
14:41 < d12fk_> http://openvpn-gui.git.sourceforge.net/git/gitweb.cgi?p=openvpn-gui/openvpn-gui;a=blob;f=openvpn-gui-res-en.rc;h=a59f233f932a39f5270394f1714f769110931d13;hb=71a2b8fd2371d2d0a6f9141847433b7730a6e7de
14:41 < vpnHelper> Title: SourceForge - openvpn-gui/openvpn-gui/blob - openvpn-gui-res-en.rc (at openvpn-gui.git.sourceforge.net)
14:42 < d12fk_> i've chosen openvpn-devel as the mailing list for the prj so far... it's evil but convenient =)
14:43 <@mattock> I think openvpn-devel is a good place
14:43 <@mattock> it does not make sense for every small project to have it's own communication channel
14:44 < d12fk_> nope, and i figured openvpn-gui is close enough related to openvpn itself
14:44 <@mattock> agreed
14:44 <@mattock> ok, I'll do the translation in the next few weeks and let you know
14:44 <@mattock> are we done for today?
14:44 < d12fk_> great
14:45 < d12fk_> nothing left on my list
14:46 <@mattock> ok, I'll write summary tomorrow and send it the list
14:46 <@mattock> I think we managed to cover quite a lot even though dazo was not present
14:46 <@mattock> in fact, our backlog has emptied... nothing left to do anymore ;)
14:47 < rob0> We should take the opportunity to gossip behind his back.
14:47 < d12fk_> good night then, or whatever.. =)
14:47 <@mattock> d12fk: you too!
14:47 <@mattock> rob0: yes, especially as this channel is logged anyways :)
14:47 < rob0> uh, oops :)
14:48 <@mattock> anyways, good afternoon, evening and night, everyone! 
14:48 < rob0> good night
14:48 <@mattock> bye!
14:49 < d12fk_> see you around
14:49 -!- d12fk_ [~quassel@88.130.205.253] has left ##openvpn-discussion ["http://quassel-irc.org - Chat comfortably. Anywhere."]
14:56 -!- rob0 [~rob0@tuxaloosa.org] has left ##openvpn-discussion ["bye"]
14:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan]
14:59 -!- waldner [~waldner@unaffiliated/waldner] has left ##openvpn-discussion ["Leaving"]
15:31 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds]
--- Day changed Fri Mar 26 2010
02:23 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
02:23 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
02:55 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds]
06:06 -!- mattock [~samuli@dyn55-11.yok.fi] has joined ##openvpn-discussion
06:06 -!- mode/##openvpn-discussion [+o mattock] by ChanServ
06:17 -!- dazo_afk is now known as dazo
07:36 < dazo> mattock: I'm really sorry for having missed the meeting yesterday ... it completely slipped my mind in all the stress
07:36 <@mattock> no probs, I think the meeting went very well :)
07:37 < dazo> Yeah, I read the logs ... very good!
07:37 <@mattock> I think I managed to take charge on the fly pretty well
07:37 < dazo> :)
07:38 < dazo> you did! ... which is very good!   I'd be scared if we were so dependent on individuals ... well, James is the only one we should have dependency on in such meetings
07:57 <@mattock> yep, I've been thinking about handling situations like this...
07:57 <@mattock> for example, stuff does not get into "testing" without your concent, or to "stable" without James' consent
07:58 <@mattock> what do you think about appointing another developer to fill in for you in the meetings - in case you won't be able to attend
08:00 <@mattock> if the requirements for code entering "testing" are clearly documented, it should be possible for somebody else to say "let's include this in testing", even if you're not present
08:01 <@mattock> or is it better to just postpone that kind of  issues and/or discuss them on the mailinglists?
08:01 <@mattock> (hope I'm making sense here :)
08:03 < dazo> mattock: James' opinions mean a lot for my considerations.  But cron2's comments is also one I do rely on
08:04 < dazo> mattock: and if I do really object, I would do that clearly when the minutes are posted ... or I would just create an own branch with that patch without merging it into allmerged
08:47 <@mattock> d12fk: are you there?
08:49 < d12fk> yes, hi
08:52 < d12fk> mattock: but will be afk in 10 minutes for a meeting
08:52 <@mattock> ok, shouldn't take more than 2 mins
08:53 <@mattock> did I understand config parser recursion correctly: http://pastie.org/888250
08:53 <@mattock> ?
08:56 < d12fk> yes all well. there's a typo in the first sentence though: parses -> parser
09:00 <@mattock> ok, I'll fix it
09:00 <@mattock> thanks
09:00 < d12fk> welcome
09:01 <@mattock> ok, meeting summary on the way
09:02 < d12fk> got it thanks
09:23 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep]
10:04 < dazo> d12fk: re: openvpn-gui .... it's great that you're getting involved here!  And you may of course also use #openvpn-devel for development discussions too!
10:05 < dazo> d12fk: one question though, will you also open up for some bug trackers or similar?
10:07  * dazo got a friend who is not a "non-tech" guy (at least in regards to computers) who might have some very good feedbacks in regards to the overall user experience
10:08  * dazo would like to point him to a place where he can share his thoughts ... (he's already used to this, being a low-tech beta tester for some games already)
10:09 < d12fk> dazo: sure will. currently i'm at a very early stage, refactoring the existing code with is quite aweful at time. once i'm done with that i'll publically announce and let the thing go it's way
10:09 < d12fk> any feedback prior to that is of course welcome as well
10:10 < dazo> d12fk: cool! I'll get him ready then ... I'll just point him to your e-mail address then?
10:11 < d12fk> let have the discussion on the openvpn-devel list so that ppl can watch the progress
10:11 < dazo> not sure he's willing to sign up to that mailing list ... but I'll give it a shot :-P
10:12 < d12fk> i'll cc him anyways. or is it subscribe to post?
10:17 < d12fk> hm seems you can post from outside, iirc mailman tells you if you have to sign up to post
10:17 < d12fk> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
10:17 < vpnHelper> Title: Openvpn-devel Info Page (at lists.sourceforge.net)
10:23 < dazo> d12fk: exactly :)
10:24 < dazo> d12fk: I've sent an e-mail now, if he's interested ... so I'll see what he answers .... it's possible to also use nntp via Gmane as well, to avoid signing up, iirc
10:24 < d12fk> true
10:25 < d12fk> i'll open some trackers for the prj on the weekend
10:26 < dazo> d12fk: cool, thx!
10:30 < ecrist> I was thinking, shouldn't this channel simply be merged with #openvpn-devel?
10:30 < ecrist> since that's what it's mostly about?
10:32 < dazo> ecrist: yeah, right now, it kind of is .... on the other hand, I'm seeing ##openvpn more as support channel ... -discussion is more a generic discussion and "meeting" channel, while -devel would be where to find the developers
10:33 <@mattock> however, lots of development discussion happens @ -discussion, even between the meetings
10:34 < dazo> yeah, it was a long discussion a few days ago .... but that's about it, as far as I've seen
10:34 < ecrist> I think this channel should go away
10:34 < ecrist> anything in this channel can be split between the main and -devel
10:34 <@mattock> like ecrist, I think merging this channel to #openvpn-devel would make sense
10:35  * dazo got no strong opinions about keeping ##openvpn-discussion
10:35  * ecrist puts a forward in place
10:36 -!- mode/##openvpn-discussion [+o ecrist] by ChanServ
10:36 <@mattock> talk about lack of bureaucracy ;)
10:37 -!- mode/##openvpn-discussion [+ci] by ecrist
10:37 -!- mode/##openvpn-discussion [-c] by ChanServ
10:37 <@ecrist> grr
10:37 -!- d12fk [~heiko@vpn.astaro.de] has left ##openvpn-discussion ["cu in -devel"]
10:38 < dazo> heh
10:38 -!- ChanServ [ChanServ@services.] has joined ##openvpn-discussion
10:38 -!- ServerMode/##openvpn-discussion [+o ChanServ] by services.
10:39 -!- mode/##openvpn-discussion [+p] by ecrist
10:40 -!- mode/##openvpn-discussion [+f #openvpn-devel] by ecrist
10:40 -!- Irssi: ##openvpn-discussion: Total of 11 nicks [3 ops, 0 halfops, 1 voices, 7 normal]
10:40 -!- mattock was kicked from ##openvpn-discussion by ecrist [mattock]
10:40 -!- openvpn2009 was kicked from ##openvpn-discussion by ecrist [openvpn2009]
10:40 -!- cron2 was kicked from ##openvpn-discussion by ecrist [cron2]
10:40 -!- agi was kicked from ##openvpn-discussion by ecrist [agi]
10:40 -!- dazo was kicked from ##openvpn-discussion by ecrist [dazo]
10:41 -!- HotaruT was kicked from ##openvpn-discussion by ecrist [Kas ]
10:41 -!- Irssi: ##openvpn-discussion: Total of 5 nicks [2 ops, 0 halfops, 0 voices, 3 normal]
10:41 -!- mode/##openvpn-discussion [+kk M4g3 M4g3] by ecrist
10:41 -!- Irssi: ##openvpn-discussion: Total of 5 nicks [2 ops, 0 halfops, 0 voices, 3 normal]
10:41 -!- Kas was kicked from ##openvpn-discussion by ecrist [Kas]
10:42 -!- M4g3 was kicked from ##openvpn-discussion by ecrist [M4g3]
10:42 -!- Irssi: ##openvpn-discussion: Total of 3 nicks [2 ops, 0 halfops, 0 voices, 1 normal]
10:42 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has left ##openvpn-discussion []
--- Log closed Fri Mar 26 10:42:37 2010
--- Log opened Fri Mar 26 10:44:06 2010
10:44 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has joined ##openvpn-discussion
10:44 -!- Irssi: ##openvpn-discussion: Total of 3 nicks [1 ops, 0 halfops, 0 voices, 2 normal]
10:44 -!- Irssi: Join to ##openvpn-discussion was synced in 1 secs
10:44 -!- mode/##openvpn-discussion [+o ecrist] by ChanServ
10:44 -!- mode/##openvpn-discussion [+c] by ecrist
10:45 -!- mode/##openvpn-discussion [-ps] by ecrist
10:45 -!- ecrist [ecrist@pdpc/supporter/professional/ecrist] has left ##openvpn-discussion []
--- Log closed Fri Mar 26 10:45:15 2010