[18:52] Keybuk: howgoezit? [18:55] sadmac2: slowly [18:56] Keybuk: what are you up against? [18:57] lack of time [18:57] what still needs doing? [18:59] all of the ipc work [19:01] anything you could hand off? I have plenty of time right now. [19:02] not unless you've already figured out how to write bindings with libnih-dbus? :) [19:03] is it difficult to pick up? [19:03] not especially [19:03] well then I may as well give it a shot [19:05] where should I pull from? [19:06] trunk [19:06] of both upstart and libnih [19:06] there's various notes in the irc logs of what we want to end up with [19:07] also will need a signed copy of http://upstart.ubuntu.com/wiki/CopyrightAssignment [19:07] assuming you're at RH now, probably by line manager or someone authorative? [19:07] interesting point. hmm... [19:22] http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080508182154-90pnmwt4j18ryzhk?start_revid=scott%40netsplit.com-20080508182154-90pnmwt4j18ryzhk [19:22] \o/ [19:23] ^ big milestone push [19:23] Keybuk: aand launchpad is being slow [19:23] ok [19:24] * sadmac2 goes to rebase or whatever you bzr people call it [19:26] "update" :) [19:26] (or pull if you branched instead of checked out) [19:26] Keybuk: I did "merge" and that seemed to get it [19:26] that works too [19:27] what's the difference between branch and checkout? [19:27] a branch is your own personal branch [19:27] any changes you make remain on your machine until you push them somewhere [19:27] a checkout is exactly like that, but any changes you make are pushed back to where you branched from [19:27] ie. it's the subversion/cvs model of working [19:28] whereas branch is the distributed model [19:28] ah [19:28] * sadmac2 likes branch [19:28] the nice thing being that if the push fails, the commit need not [19:28] so you can work centrally, and get on a plane, and carry on committing [19:28] when you have a connection again, you just merge in everyone else's changes, and push and rebind [19:28] I don't tend to checkout much myself [19:29] I tend to use branch/pull/push [19:29] even if I'm the only person with write access to the pull/push location [19:29] since then I can stage pushes [19:29] yes. I'm young enough and avant garde enough that git marks the vast majority of my version control experience. [19:29] heh [19:29] I dislike git strongly [19:29] well [19:29] it appears to dislike me strongly [19:29] it vastly overcomplicates things which should be simple [19:30] I havent' found such [19:30] you should try this 'eg' thing though. people seem to like it [19:32] * Jc2k has had a bad git experience today [19:32] eg? [19:33] Keybuk: "easy git." Its a little wrapper layer that's got a lot of people very pleased [19:33] Jc2k: what was it? [19:33] * Jc2k won't be ready to try playing with git again for a while [19:33] sadmac2: but bzr already does everything I need without any wrappers ;) [19:33] the amount of effort to add a new repository [19:33] and I know where the author lives, and haven't popped round to stab him in the face [19:33] this, to me, is a great achievement in revision control systems ;) [19:34] with bzr i just pushed to sftp (also a location http can see) [19:34] "Hi Scott, my name's Brian, I'm one of the authors of subver*ARRRRGH MY EYEE!!!!*" [19:34] Keybuk: as originally intended, it wouldn't be fair to compare git and bzr, any more than it would be fair to compare sysvinit and libnih [19:34] with git, i have to run git-update-this and add hooks so that git-update-that gets called every commit and... [19:34] git was a filesystem. it was never meant to be left on its own [19:34] this has become far less true [19:34] Jc2k: don't use webdav [19:34] sadmac2: git was always intended to be a revision control system ;) [19:35] Jc2k: stick to the custom daemon [19:35] Keybuk: it was not intended to be interacted with by the user directly [19:35] sadmac2: sure it was [19:35] where the user == Linus [19:35] sadmac2: i was meant to be quickly throwing some repos up so that the upstream debian maintainer of my ubuntu synce packages got some fixes [19:35] but then other people realised that Linus is quite, quite mad [19:35] and wrapped it with friendlier things [19:35] sadmac2: it took 4 attempts before he could finally access them. [19:36] and claimed that it was never intended to be unwrapped in the first place [19:36] Jc2k: using which method? webdav or git-daemon? [19:37] git reminds me a lot of arch [19:37] I think it's the first distributed revision control system that people try [19:37] sadmac2: does bog standard http really qualify as webdav? but yes, webdav. because i excpected it to be as simple as bzr. [19:38] and they fall in love with the idea of DVCS so much, and think it's so awesome, that they'll apologise for any user interface problems [19:38] Jc2k: webdav is not the way to do it. [19:38] Jc2k: use the git-daemon [19:38] what hg and bzr have shown is that you can do DVCS, and still have a simple client that largely does the right thing [19:38] sadmac2: i started working to set that up [19:38] without exposing its inner workings [19:39] it's still distributed, it's still awesome, but it feels less like having a spike pushed through your testicles [19:40] sadmac2: if i use git-daemon, do i still have to log on to the server, create a new repo, poke things into its hooks, ln it to /var/cache/git and such? [19:41] log on/create I believe still apply. The rest shouldn't [19:41] so i'll still be using bzr when i quickly want to share a branch. [19:42] bzr push sftp://hostname/home/scott/public_html/some-branch [19:42] ;) [19:42] Jc2k: remember: 1 git repo => many branches [19:42] Keybuk: doesn't it support ~ these days? [19:42] yeah probably [19:42] Jc2k: its a once-per-project operation, not once-per-branch [19:42] sadmac2: ssh hostname bzr init-repo public_html/bzr [19:42] bzr push sftp://hostname/home/scott/public_html/bzr/some-branch [19:43] (in fact, you can probably just init-repo the sftp url ;p) [19:43] Jc2k: and if you quickly want to share a branch, why on the server? Just share it off your own damn box like it was designed for [19:43] sadmac2: generally behind NAT [19:43] Jc2k: good point [19:44] that is one area where bzr is just better. Git's almost TOO distributed. The idea of ANY centralization was an afterthought. hence the trouble. [19:44] I've never seen anywhere that git is more distributed than bzr? [19:44] bzr's repository model was just designed from scratch to be flexible [19:45] any bzr repository is a branch someone can take [19:45] bzr branch ~someoneelse/work/foo -- will take a branch from their last committed change [19:45] Keybuk: well its more a mindset question than anything. The idea of a central git repo just didn't occur to anyone until late in the game [19:46] hell, the only difference between bzr branch and cp -a is that bzr branch doesn't take the .o files with it ;) [19:46] and the level of integration from bzr-svn astounds me [19:46] Remember, Linus doesn't even necessarily think there should be a single convergence point. [19:46] i'm a little surprised there isn't a bzr-git, but i don't think there is someone who wants to use both [19:47] there is? [19:47] sadmac2: is there actually any project where developers push/pull biderectionally from each others? there allways seems to be a central repository in projects ive been at. [19:47] Keybuk: but its not like bzr-svn, is it? last time i looked it wasn't as feature complete.. [19:47] s/any project/any git project/ [19:47] it's not as complete, no? [19:48] suihkulokki: Red Hat does it that way internally. When you pull in here, usually its coming directly from a folder in someone's NFS home [19:49] sadmac2: we tried to do that to a relatively small project and the repo was messed in not time.. [19:51] suihkulokki: we've been doing it without issues for all of IT for awhile now [19:52] heh, we just don't use revision control ;) [19:53] the debian archive system is kinda like a primitive rcs in of itself [19:54] One claim bzr made that's bugged me: They said on their webpage "bzr never commits a merge automatically, which is safer if it breaks things" [19:54] WHO CARES? [19:54] Without autocommit: git reset HEAD With autocommit: git reset HEAD^ [19:55] the workflow is nearly identical [19:55] sadmac2: it's just the CVS model [19:55] bzr merge ... bzr commit [19:55] svn follows the same pattern [19:56] anyhoo, skating time [19:56] bbl [19:56] Keybuk: I'm not saying its worse, its totally fine. but they go screaming for 20 minutes "git is unsafe because it does this!" [21:17] Keybuk: so basically these NihDBusInterface[] arrays need to be populated with whatever self-evident handlers [21:17] (which in turn need to exist) [21:20] Which is the real Keybuk ? [21:29] well, that pretty much confirms that it's just FreeNode that this hotel hates [21:30] heh [21:31] Keybuk: so what I'm gathering from the source here is that we have manager_interfaces[] and job_class_interfaces[] which need to be populated with appropriate handlers [21:31] pretty much [21:31] the handlers are all autogenerated though [21:31] ah yes. the magical mystery python script [21:32] crap, wrong button [21:32] heh [21:32] sadmac2: did you get the trunk libnih and upstart to build ok? [21:33] Keybuk: haven't built 'em. I'll want to build them under F9 at home I think [21:33] (Work box is RHEL 5) [21:33] ah right [21:34] wanted to see whether it worked ok [21:34] I added some compiler flags ;) [21:34] meh. I have a compiler. I can build it for the sake of building it [21:34] lets do this [21:34] :) [21:34] add CPPFLAGS=-DDEBUG [21:35] ../libnih/nihify [21:35] yeah, well [21:35] configure libnih [21:35] then nihify upstart [21:35] then configure and build upstart [21:37] aaand stopped [21:37] Autoconf version 2.61 [21:37] :( [21:37] don't have that in 5 [21:38] heh [21:38] why's the work box so out of date? [21:38] Keybuk: its RHEL. [21:38] The customers seem to prefer things this way [21:39] ...I could grab the f9 package out of koji.... [21:39] that's the latest release of RHEL?! :) [21:39] what is it?! Debian?! :p [21:40] RHEL releases are eons apart [21:40] how do you build stuff on there? [21:41] Keybuk: anything we're shipping builds with the versions available. Anything customers want to build themselves isn't within our direct support ring and they need to talk to the people that wrote it. [21:44] yeah, but how do you develop for fedora on RHEL? [21:45] Keybuk: I don't. I've been in sysadmin positions until... well two weeks from now [21:45] the fedora stuff has been free time [21:46] (which I have a lot of since the department I'm in now doesn't have much work for me) [21:46] ahh right [21:46] work != RH [21:46] ? [21:46] Keybuk: also ssh [21:46] Keybuk: yeah, I work at RH. I was an IT release engineer, now I'm engineering operations. [21:46] oh, got you [21:47] the former was mostly scripting, the latter consisted of lifting heavy objects and bolting them to high places. [21:48] :-) [21:51] I have to go dig up the 0.3.9 source so I can remember what all this stuff did [21:53] which stuff? :) [21:53] jusw what messages need to be responded to. [21:53] s/jusw/just [21:54] most of it probably won't be a 1:1 mapping [21:55] yeah. [21:55] Where is the script that does the autogenerating? [21:56] in libnih [21:56] ahh. was looking for green in ls [22:12] ahh, and my favoritest part about RHEL 5 [22:12] Python 2.4.3 [22:17] Keybuk: Your script keeps saying "Name may ot be null" [22:17] where do I put the name? I tried an attribute, I tried a tag... [22:19] nvm. I get it now [22:59] it's just d-bus introspect format as input [23:00] ah [23:00] * sadmac2 should RTFM on dbus [23:01] heh [23:01] I wish there was a d-bus style guide [23:01] like what should the primary interface be? [23:02] if it's /com/ubuntu/Upstart [23:02] should the interface be com.ubuntu.Upstart [23:02] or com.ubuntu.Upstart.Manager [23:02] or com.ubuntu.Upstart.Server [23:02] etc. [23:03] if either of the later two, what would the first then mean? [23:04] you'd just have one? [23:04] davidz services seem to use Manager [23:04] hughsie services seem to just use the dotted version of the path [23:05] It just seems to me that if com.ubuntu.Upstart is a valid option it should either be it, or it should be something with some sort of ownership relation to com.ubuntu.Upstart.{Manager,Server,whatever} [23:06] how do you mean? [23:06] as in you get from one to the other? [23:07] when I see com.ubuntu.Upstart.Manager, the relationship, to me, reads com.ubuntu.Upstart HAS A Manager [23:08] if something can HAVE A other thing, that implies that there is something doing the having, which suggests one could interact with com.ubuntu.Upstart directly [23:09] so what interface does com.ubuntu.Upstart present? and if none, why? [23:10] yeah that's my thinking too [23:10] the /com/ubuntu/Upstart object should have the com.ubuntu.Upstart interface [23:10] which allows you to do things like get jobs (com.ubuntu.Upstart.Job interface), etc. [23:12] plus Server kind of nods at an implementation detail, and Manager is a -er classname, which I have pages of angry rants about [23:13] ok, no -ers :p [23:13] Its fun to program in java when you have that disposition :) [23:13] BufferedStreamReader *shudder* [23:19] ;) [23:22] make[2]: Entering directory `/home/scott/co/upstart/init' [23:22] ../nih/nih-dbus-tool \ --mode=object --prefix=control --output=com.ubuntu.Upstart_object.c ../dbus/com.ubuntu.Upstart.xml [23:23] schweet [23:23] actually I should s/_object// for those [23:24] that was only for the test suite [23:24] yea [23:25] anything in that Upstart file yet? [23:30] not yet [23:32] hm. I'll see if I can populate it tonight [23:32] local lug meeting is in 1/2 hour downstairs. I'll probably be going to that. [23:40] Keybuk: did you ever integrate that RPM patch I sent? [23:51] err, which patch was that [23:51] I thought I did [23:51] Keybuk: it just added code to where you were ignoring .dpkg files to ignore some of rpm's weird things [23:51] hmm, not on this PC [23:51] let me commit that now [23:52] Keybuk: I don't know where it would be in the new design [23:52] Keybuk: I can't find even the dpkg stuff [23:52] same place [23:53] what was the ;[abcdefABCDEF0123456789] thing fabout? [23:54] Keybuk: when rpm first puts a file down on the system, it puts it into place with a ; appended to it. Then when everything is laid out, it moves them to the right name [23:54] Keybuk: its an atomicity thing [23:54] keybuk: I find com.ubuntu.Upstart nice. [23:54] ah right [23:55] So just ignore files with semicolons in addition to files with dots? [23:55] ion_: we don't ignore files with dots anymore [23:56] ion_: its ignoring files with ;. I was able to match the pattern fairly simply [23:56] the matching is somewhat smarter [23:56] Oh, ok. [23:56] wing-commander upstart% dbus-send --system --dest=com.ubuntu.Upstart --type=method_call --print-reply /com/ubuntu/Upstart com.ubuntu.Upstart.GetJobByName string:"foo" [23:56] method return sender=:1.1567 -> dest=:1.1571 reply_serial=2 object path "/com/ubuntu/Upstart/jobs/foo" [23:56] \o/ [23:56] Btw, now that Fedora is going the Upstart way, will Red Hat follow? Sorry for my ignorance, but i have no idea how Fedora and Red Hat relate to each other nowadays. [23:56] This calls for an image macro [23:57] ion_: The rule was "Every 3rd fedora release becomes a RHEL" which would have meant f9 -> RHEL 6, but customers aren't really demanding a new version, so we'll probably wait. [23:57] ion_: but yes, the next RHEL fork will almost certainly pick up Upstart [23:57] Alright, nice. [23:57] when is f9 out? [23:58] Keybuk: days. there may be a gold version floating about now [23:58] cool [23:59] Not topical, but: [23:59] http://people.fedoraproject.org/~sadmac/hula.jpg [23:59] And now to LUG. l8r