2012-11-25 GnuCash IRC logs
01:15:37 *** nafg_ has quit IRC
01:25:52 *** nafg has joined #gnucash
04:19:54 *** aqua___ has joined #gnucash
04:32:41 *** aqua___ has quit IRC
04:57:43 *** fuzzybunny69y has quit IRC
05:06:29 <gjanssens> warlord: I have thought about migrating htdocs to git. You are correct it will need coordination with linas
05:06:40 <gjanssens> Basically these steps will be needed:
05:06:59 <gjanssens> - convert webdirectory from svn to git
05:11:32 <gjanssens> - modify the update trigger to run git pull instead of svn update
05:12:21 <gjanssens> On code: install a trigger in the htdocs git repository's post-commit hook instead of the svn trigger
05:14:19 <gjanssens> This requires the htdocs git repo to be active I think.
05:16:07 <gjanssens> It might be a good test candidate to learn how to use gitolite, and how/where to configure the proper triggers.
05:16:36 <gjanssens> There are two triggers I'm aware of right now concerning htdocs:
05:16:46 <gjanssens> - one to trigger a website update
05:16:58 <gjanssens> - one to trigger a push to github
05:18:00 <gjanssens> I know there are two website versions (in different checked out directories): trunk and beta
05:18:13 <gjanssens> I don't know if both are updated using the same trigger script
05:18:49 <gjanssens> How the triggers are configured exactly is probably private information for security reasons
05:20:46 <gjanssens> Dividing the migration to git into smaller steps will probably make it easier to debug
05:20:55 <gjanssens> So here's how I propose to proceed:
05:21:32 <gjanssens> 1. setup a htdocs repo it git, initially with the svn htdocs as upstream repo
05:22:01 <gjanssens> That allows us to test gitolite and overcome any initial hurdles there
05:23:17 <gjanssens> 2. setup a trigger in the svn htdocs repo that causes a git pull in the htdocs git repo each time svn htdocs is changed
05:23:59 <gjanssens> That will keep htdocs in sync with svn at all times and keep it ready to take over master status at any time
05:24:48 <gjanssens> 3. configure a git htdocs post-commit hook to update the live website
05:25:37 <gjanssens> I assume here that all that code currently does is a magic port-knock on the webserver and that the actual update script is installed on the webserver
05:26:13 <gjanssens> With that assumpion, we can have the git htdocs post-commit hook run the exact same trigger that the svn repo uses
05:26:38 <gjanssens> That svn post commit hook is disabled at the same time (on code).
05:27:09 <gjanssens> So the effect of step 3 is: a commit is added in the svn repo
05:27:23 <gjanssens> the svn repo triggers an update on the git repo (git pull)
05:27:55 <gjanssens> The git repo in turn triggers the webserver to update (which still updates against svn at this point)
05:28:16 <gjanssens> If all that works well, we can go one step further
05:28:53 <gjanssens> 4. replace the beta site with a git repo on the webserver and write an update script for it on the webserver
05:29:17 <gjanssens> This should get triggered together with the svn update trigger script on the webserver
05:29:36 <gjanssens> and allows us to test the git changes on the webserver
05:29:58 <gjanssens> 5. If it works for beta, we can do the same for the main website
05:31:04 <gjanssens> 6. In parallel to much of this, the trigger that is currently run by John to update github can now be installed on the htdocs git repo on code
05:31:27 <gjanssens> At least, for htdocs only initially.
05:32:14 <gjanssens> 7. if all the above is working svn htdocs should be disabled, and htdocs on gitolite declared master
05:32:49 <gjanssens> This could be done by disabling all write access to svn htdocs, removing the svn repo as upstream from htdocs git
05:33:19 <gjanssens> and asking anyone to use htdocs git from now on (either checked out from github or from code)
05:33:42 *** Topcat has joined #gnucash
05:33:51 <gjanssens> I think such a step by step proces will allow us to debug each small step in turn
05:36:28 <gjanssens> Hmm, I better post this on gnucash-devel as well for feedback...
05:42:15 *** ErKa has joined #gnucash
05:54:48 *** ErKa has quit IRC
06:01:24 <gjanssens> Ok, the mail is sent on gnucash-devel
06:02:28 <gjanssens> warlord: re the emails using gitolite
06:02:49 <gjanssens> wouldn't it be more interesting to use gnucash-devel as sender address ?
06:03:17 <gjanssens> If anyone then attempts to reply to the e-mail it automatically goes to the list.
06:03:39 <gjanssens> Or are we talking about internal mails that are sent to admins only ?
06:09:29 *** Topcat has quit IRC
06:09:51 *** Topcat has joined #gnucash
06:14:57 *** Topcat has quit IRC
06:15:20 *** Topcat has joined #gnucash
06:25:42 *** Topcat has quit IRC
06:26:05 *** Topcat has joined #gnucash
06:34:35 *** Topcat has quit IRC
06:34:58 *** Topcat has joined #gnucash
06:41:01 *** aqua___ has joined #gnucash
06:51:48 *** Topcat has quit IRC
06:52:11 *** Topcat has joined #gnucash
06:57:16 *** Topcat has quit IRC
06:57:39 *** Topcat has joined #gnucash
07:06:25 *** Jimraeh1 has quit IRC
07:18:50 *** aqua_ has joined #gnucash
07:19:28 <gjanssens> linas: is FileInfo also enabled for the beta website ? My recently added redirects don't seem to work there.
07:21:53 *** aqua___ has quit IRC
07:30:40 *** Topcat has quit IRC
07:31:03 *** Topcat has joined #gnucash
07:36:08 *** Topcat has quit IRC
07:36:31 *** Topcat has joined #gnucash
07:41:33 *** Topcat has quit IRC
07:41:56 *** Topcat has joined #gnucash
07:56:17 *** Topcat has quit IRC
07:56:40 *** Topcat has joined #gnucash
08:01:43 *** Topcat has quit IRC
08:02:06 *** Topcat has joined #gnucash
08:08:57 *** Topcat has quit IRC
08:09:19 *** Topcat has joined #gnucash
08:22:00 *** Topcat has quit IRC
08:22:23 *** Topcat has joined #gnucash
08:32:39 *** Topcat has quit IRC
08:33:02 *** Topcat has joined #gnucash
08:38:05 *** Topcat has quit IRC
08:38:28 *** Topcat has joined #gnucash
08:44:13 <warlord> gjanssens: I think we should migrate gnucash and gnucash-docs to git/gitolite first, and then worry about the website later.
08:44:30 <warlord> Re: email, I don't know how to configure that, yet.
08:44:36 <warlord> gitolite's backend is a "bare repo".
08:45:26 <gjanssens> perhaps that's not something to configure at the gitolite level
08:45:29 <warlord> I got it set up, and there are two git repos there, a testing repo and the gitolite-admin repo. Right now I'm the only user, but I was going to add the keys to re-add everyone else. I'm not sure how to best set up the git(olite) -> email messages
08:45:36 <gjanssens> you probably run your own mailserver
08:45:49 <warlord> Yes, it can be sent "locally".
08:45:53 <warlord> I just need to "send"
08:45:54 <gjanssens> you can easily do a canonical rewrite of git@code to gnucash-devel@gnucash.org
08:46:47 <warlord> The harder question would be: how do we set up the git-push, unless we create a special github account for 'code'?
08:47:05 <warlord> (I doubt there are IP-based ACLs)
08:47:17 <gjanssens> How does jralls do this ?
08:47:29 <gjanssens> I guess he just uses his own github account
08:47:42 <gjanssens> Which is probably fine
08:48:04 <warlord> I think that's what he does.
08:48:43 <warlord> I could try to setup a new account specifically for 'code'
08:49:17 <gjanssens> Why that instead of using one of the core dev's accounts, like yours ?
08:49:47 <warlord> So we don't have to have a core-dev password sitting on the code server.
08:50:08 <gjanssens> Ah, that's a good reason indeed.
08:50:22 <warlord> I don't mind code having its own password.
08:50:47 <gjanssens> So yes, creating an account specifically for code is probably a good idea
08:51:36 <gjanssens> On the other hand a git push is based on ssh public/private key security
08:51:58 *** aqua__ has joined #gnucash
08:52:16 <gjanssens> So what we need is a separate ssh keypair for code, rather than a separate password.
08:52:43 <warlord> Ah, that's doable.
08:52:44 <gjanssens> git push to github that is
08:52:56 <warlord> But isn't it tied to an account?
08:53:04 <warlord> Or is it tied to a project/repo?
08:53:10 <gjanssens> More or less to an account
08:53:18 <warlord> Can you git-push a 'bare repo'?
08:53:44 <warlord> How do you push to something that was 'cloned' from you? -- I'm not sure I understand how that works.
08:53:48 <gjanssens> Here we can choose whether you want a seperate account on github, or whether you want to add code's public key to your account
08:53:58 <gjanssens> You can add multiple public keys to one account
08:54:13 <gjanssens> It just depends on how separate you prefer to keep things
08:54:34 <gjanssens> Yes, you can push from a bare repo.
08:54:58 <gjanssens> push and pull work on branch level
08:55:20 <gjanssens> you push from one branch in one repo to a branch in another repo
08:55:42 <gjanssens> git will compare differences between the branches and try to apply any changes it finds
08:55:47 <gjanssens> (overly simplified)
08:55:54 <warlord> Oh, you don't push whole repos? Then how do we set up the fact that you created a new branch?
08:56:02 <gjanssens> no
08:56:07 *** aqua_ has quit IRC
08:56:31 <warlord> E.g., let's say we branch a 2.6 branch in git on code. How would the script know to send that info up to github?
08:57:09 <gjanssens> well, if you don't specify a branch to push, git will iterate over all branches and push one after the other to a branch of the same name remotely
08:57:28 <gjanssens> But tbh, I don't know what happens if the branch doesn't exist yet
08:57:35 <gjanssens> I'll do a little experiment locally
08:58:19 <warlord> I would expect it would DTRT.. Otherwise you would need to explicitly create a new branch everywhere.
09:01:53 <gjanssens> 'git push' will only push existing branches
09:02:09 <gjanssens> but 'git push --all' will also create non-existing branches to push to
09:02:21 <gjanssens> so git push --all is our command to use
09:06:43 <warlord> Okay
09:07:28 <warlord> How are the hooks managed?
09:08:27 <warlord> I'm guessing they are in git, but then we need to figure out how to get them to run only on code.
09:10:44 <gjanssens> http://git-scm.com/book/en/Customizing-Git-Git-Hooks
09:11:07 <gjanssens> I think we need to hook into pre-receive or post-receive in this case
09:12:31 <gjanssens> I suspect .git/hooks is local for each repo
09:12:58 <gjanssens> The .git directory is where each repo keeps track of its state.
09:13:18 <gjanssens> So if you only install the hooks on code, it will not propagate
09:14:03 <gjanssens> We could of course put the hooks under version control as well like we now have the meta repo
09:14:45 <gjanssens> In that case, we would have to create a local clone of that meta repo on code as well (not a bare version)
09:15:01 <gjanssens> create a hook that updates this repo with each commit
09:15:24 <gjanssens> and then use links from that repo to the proper hooks directory in the bare gitolite repos
09:15:42 <gjanssens> That would allow other devs to update the hooks at all times
09:16:25 <gjanssens> I also wonder if gitolite has its own mechanism for managing hooks.
09:16:34 <gjanssens> If so, we may be better using that
09:17:47 <warlord> I dont know if it can manage hooks.
09:18:02 <warlord> http://sitaramc.github.com/gitolite
09:19:15 <warlord> My goal for today is to get users keys into gitolite. Mia wants to get out for the day, so I might have limited time to hack on gnucashy things. I'll give you access to the admin repo, and I can add shell stuff as necessary. We can use the testing repo that exists to try things out before we migrate other stuff.
09:19:47 *** Topcat has quit IRC
09:23:05 <gjanssens> ok
09:23:20 *** mikee has quit IRC
09:24:17 <warlord> do you have to add a new directory before you can git mv a file into it?
09:24:56 *** mikee has joined #gnucash
09:25:12 <mikee> @op
09:25:12 <gncbot> mikee: Error: You don't have the #gnucash,op capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
09:26:32 <mikee> @op
09:26:33 *** gncbot sets mode: +o mikee
09:37:06 *** aqua__ has quit IRC
09:59:52 <gjanssens> warlord: no idea
10:01:30 <gjanssens> I haven't used git mv yet
10:02:58 <warlord> gjanssens: Apparently you can just use 'git mv' after 'mkdir'
10:07:29 <gjanssens> Ok, good to know
10:07:39 <warlord> I'm going to migrate all existing code user accounts into gitolite.
10:07:52 <warlord> (even those who might not be current active users)
10:08:03 <gjanssens> ok
10:11:56 *** ErKa has joined #gnucash
10:13:55 <warlord> gjanssens: about gitolite hooks: http://sitaramc.github.com/gitolite/cust.html#hooks
10:19:12 <gjanssens> ah, there it is
10:19:32 <gjanssens> I haven't read the details on gitolite itself
10:20:05 <gjanssens> (I'm still on-and-off on my wife's exhibition)
10:20:35 <gjanssens> so does this mean we should use the gitolite recommended locations
10:20:44 <gjanssens> or just put them per repo where we like ?
10:24:58 <warlord> Maybe a bit of both?
10:25:08 <warlord> I just added everyone's keys
10:25:16 <warlord> So all current devs have access.
10:25:45 <warlord> (not that "access" means anything, yet)
10:27:58 <warlord> okay, you have access to the gitolite-admin repo
10:28:25 <warlord> You should be able to git clone git@code.gnucash.org:gitolite-admin
10:36:51 * gjanssens will try this right now
10:38:11 <gjanssens> I'm asked for a password for git@code.gnucash.org
10:38:30 <gjanssens> Same if I try gjanssens@code.gnucash.org
10:40:00 <warlord> Are you sure you're not being asked for your ssh password?
10:41:51 <gjanssens> No, I actually had to tell ssh to use the proper identity file when connecting to code.gnucash.org
10:42:00 <gjanssens> That's working fine now
10:42:23 <warlord> Ah, okay.
10:42:23 * gjanssens has several ssh keypairs, depending on the job
10:42:31 <warlord> Gotcha.
10:42:37 <warlord> Luckily you didn't get locked out! ;)
10:42:52 <gjanssens> I have successfully cloned gitolite-admin
10:43:12 <warlord> Excellent.
10:43:21 <gjanssens> heh, in this case you were luckily still around to fix it if needed :)
10:43:29 <warlord> True.
10:43:36 <warlord> Gotta feed the baby. BIAB
10:43:52 <gjanssens> ok, see you later
10:53:46 <warlord> Yep ;)
11:00:11 *** Mer|in has joined #GnuCash
11:03:43 *** Mer|in_ has quit IRC
11:06:21 <warlord> Ah, looks like we can add a local-code directory to the admin repo and control system-wide hooks from there.
11:11:28 <gjanssens> cool...
11:11:51 <gjanssens> I don't have much knowledge of the hooks currently in place.
11:12:04 <gjanssens> Are there hooks that are relevant for all our repos ?
11:12:12 <warlord> email
11:12:17 <gjanssens> Right
11:12:46 <gjanssens> And pushing to github can probably be a generic script as well ?
11:12:47 <warlord> maybe, eventually, the push-to-github? (at least for all repos except the admin repo)
11:12:54 <warlord> :)
11:19:39 <warlord> i just need to configure the local code dir in the rcfile to enable it.
11:25:23 <gjanssens> I suppose the scripts would the be visible to any dev we give read access to the gitolite-admin repo
11:27:18 <warlord> yes.
11:27:28 <warlord> I would suggest we limit write access to the admin repo
11:27:46 <warlord> (similar to how we limit access to the meta svn repo)
11:27:57 <warlord> we might be able to give each dev write access to their own keydir
11:45:29 *** pnema has joined #gnucash
11:51:22 <gjanssens> can a dev have more than one key in the keydir ?
11:51:49 <gjanssens> ok for me to have limited write access in the admin repo
11:52:15 <warlord> Yes.
11:52:33 <warlord> See how it was done for, e.g. plongstaff
11:53:35 <gjanssens> cool :)
11:53:56 <warlord> The base name of the file needs to be the user's name. but the keyfile can have an @-descriminator. the name can also be an email address, e.g. foo@bar.com.pub, or even email+descriminator, foo@bar.com@key1.pub
11:54:27 <gjanssens> that will allow a dev to manage multiple keys without necessarily locking himself out in the process
11:54:33 <warlord> Right
11:54:41 <gjanssens> clumsy fingers can still result in that though :)
11:55:01 <warlord> Er.. .wait.. then a dev could add a key as any user, because the filename implies the username. Hmm
11:55:57 <gjanssens> oh, the directory names are arbitrary then ?
11:56:53 <warlord> Yes
11:57:02 <warlord> It's the filename that matters. :(
11:58:36 <gjanssens> bummer :(
11:59:01 <warlord> We could possibly make the limit such that they can edit <name>/<name>[@.*].pub
11:59:17 <warlord> I'm just not sure how to setup a regex for that.
11:59:55 <gjanssens> ok
12:00:08 <gjanssens> it can be done later as well, it's not the most important feature
12:00:32 <warlord> right
12:01:06 <warlord> I think let's get the hooks working, like email..
12:26:21 *** kpreid has quit IRC
12:26:48 *** kpreid has joined #gnucash
12:43:27 *** Jimraeh1 has joined #gnucash
12:48:34 *** Jimraeh1 has left #gnucash
12:49:56 *** ErKa has quit IRC
12:57:53 *** Jimraeh1 has joined #gnucash
13:02:21 *** Getty has joined #gnucash
13:15:40 *** shade304 has joined #gnucash
13:26:25 *** pnema has quit IRC
13:29:11 *** pnema has joined #gnucash
13:38:31 *** shade304 has left #gnucash
13:38:49 *** gjanssens has quit IRC
13:55:39 *** nomeata has joined #gnucash
13:55:54 *** aqua__ has joined #gnucash
13:56:11 <nomeata> Hi. How do you get fast compile-run cycles? Here, even after a small change to one .c file, "make && make install" takes quite long.
13:58:53 *** Getty is now known as Getty2
14:10:14 *** benoitg has joined #gnucash
14:15:25 *** aqua__ has quit IRC
14:29:44 *** shade304 has joined #gnucash
14:30:17 *** shade304 has left #gnucash
14:57:33 *** bobbrush3 has joined #gnucash
14:58:20 *** bobbrush3 has left #gnucash
14:58:38 *** bobbrush3 has joined #gnucash
14:59:05 *** bobbrush3 has left #gnucash
15:06:18 *** bobbrush3 has joined #gnucash
15:55:51 *** ErKa has joined #gnucash
16:22:23 <warlord> nomeata: define "quite long"? What OS/Distro are you using?
16:22:28 <warlord> If you say Windows I'll laught
16:25:00 <nomeata> warlord: 30s
16:25:13 <nomeata> on Debian unstable
16:25:25 <warlord> 30s is not "quite long"
16:25:32 <warlord> It has to go re-link all the libraris.
16:25:34 <warlord> libraries
16:25:55 <nomeata> Hmm, even if I change only one file like src/register/ledger-core/split-register-model-save.c?
16:26:02 <warlord> however, you can short-circuit -- if you only change a .c you really only need to "make all install" in that directory
16:26:34 <nomeata> ok
16:26:44 <warlord> if you run the build from the top-level, yes, because that one change cascades down the dependency chain.
16:28:36 <nomeata> ah, much better. thx
16:32:47 <warlord> what are you hacking on?
16:37:10 <nomeata> https://bugzilla.gnome.org/show_bug.cgi?id=120854
16:37:28 <nomeata> It has been bugging me so long, I thought I give it a shot
16:43:38 <nomeata> anyways, enough for today. good night
16:43:47 *** nomeata has quit IRC
16:45:53 <warlord> good luck
17:30:00 *** bobbrush3 has quit IRC
17:43:28 *** ErKa has quit IRC
17:46:46 *** bobbrush3 has joined #gnucash
17:48:52 *** bobbrush3 has left #gnucash
18:36:35 *** Getty2 is now known as Getty
19:13:00 *** Jimraeh1 has quit IRC
19:36:30 *** phunyguy_t430s has joined #gnucash
19:57:17 *** kpreid has quit IRC
20:48:04 *** kpreid has joined #gnucash
21:42:05 *** pnema has left #gnucash
22:46:28 *** phunyguy_t430s has quit IRC
22:49:30 *** phunyguy_t430s has joined #gnucash
22:55:09 *** bobbrush3 has joined #gnucash
22:55:15 *** bobbrush3 has left #gnucash
23:00:12 *** phunyguy_t430s has quit IRC
23:00:40 *** phunyguy_t430s has joined #gnucash