[00:17] lifeless, subunit was accepted into sid === Kissaki is now known as Kissaki^0ff === Toksyury1l is now known as Toksyuryel === Kissaki^0ff is now known as Kissaki === TheJosh is now known as TheJosh1337 [13:40] Hi I have a quick question about bazaar. How can I set up access control for my bazaar repository? I am running the repo on a server, and I want control on who can commit to what branches. [13:43] TheJosh1337: bazaar doesn't get into that business itself [13:43] TheJosh1337: one option is using unix accounts and ssh [13:44] can I write a plugin? [13:45] it's currently going through bzr:// [13:46] yes, you can [13:46] it's probably not super easy though [13:47] All I want is for each user to have as many branches as they want [13:47] but they can only commit to their branches. [13:48] with the branch name containing the user name (e.g., /TheJosh/sandbox for TheJosh's 'sandbox' branch [13:49] but you don't want to create a unix account for each user? [13:51] I could do that [13:51] it's a bit sucky, but that's easiest for now [13:51] although the plan is that the users will only be able to commit to their branch(es) [13:51] well sure [13:51] then a web tool will allow merging of branches into trunk [13:52] so use unix permissions [13:52] so the user accounts are only on the web tool. [13:52] i.e. create /code/Bob that's owned by bob anx rwxr--r-- [13:52] there are bits and pieces in launchpad we should probably factor out and open source to make this easier [13:52] so my web tool has to create a unix account on the server for every user account created, and set the correct permissions as well, correct [13:53] but, well, that takes time [13:53] ah i see [13:53] see I want to do something slightly radical. I want to allow anyone with an account commit access to trunk straight away [13:53] as long as they go through a branch, and as long as the code compiles [13:54] you can play tricks with ~/.ssh/authorized_keys to avoid creating an actual account for each user [13:54] kinda like wikipedia - it doesn't make sense, but it works [13:54] TheJosh1337: have you seen pqm? [13:54] Yeah [13:54] that allows an email driven way of doing what you want [13:54] but I couldn't find any useful docs [13:54] like how to install or set up or anything like that [13:55] and for a anyone-can-commit system to work it has to be easy to use - really easy to use [13:55] wikipedia wouldn't work if it wasn't brain-dead easy to use [13:57] mwhudson, ill look into hooks, to begin with I only have to prevent commits to trunk, that should be fairly easy I hope. [14:05] thanks [17:42] anyone has a recording or slides of "Plans for Bazaar after 2.0" from UDS 2009? === sdboyer_ is now known as sdboyer [20:59] I have a Bazaar branch I just made that has an Audacity project with nearly 2:30 hours of audio in it. It's about 2.6 GB and has 2679 files in it. I've already put it in a regular branch but was thinking it would be better to put it into a repository, though I'm not sure the best route to go with that. [21:00] Should I use the --no-trees option? [21:00] can I move the already existing branch into a shared repo or do I have to branch it in? [21:06] hey there, is it me or the bzr-gtk packages are broken with bazaar 1.15? [21:16] nekohayo: define broken? [21:17] pygi: bzr viz doesn't start, neither does olive [21:17] nekohayo: what's the traceback? [21:17] Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module but the minimum exported version is (1, 15, 0), and the maximum is (1, 15, 0) [21:17] pastie pls [21:17] that's all of it [21:17] nekohayo: moment :P [21:18] bzr-gtk comaintainer is in the next room [21:18] but he's busy :-/ [21:18] hmmm [21:18] seems like there's a version mismatch [21:18] nekohayo: are you using bzr checkout of bzr-gtk? [21:18] nah, just the PPA [21:18] nekohayo: could you try the bzr checkout pls? [21:19] we'll get better at keeping it up to date, I know :p [21:19] don't quite know how to do that :) [21:19] well if it's just a matter of the bzr-gtk package not being yet updated in the archive.. [21:19] I guess I can simply wait for it to appear? [21:31] nekohayo: yes :) [21:31] nekohayo: I think the thing is that there isn't yet a new release :P [21:31] I'll bug szi tomorrow [21:33] nekohayo: I think we'll get a bit more better at bzr-gtk after this week [21:33] :) [21:49] pygi: ah, why is that? :) [21:50] nekohayo: we had some discussions about bzr-gtk specifically during bazaar sprint [21:50] at UDS? [21:51] any way for a simple user like me to have access to stuff that was discussed, or presentations such as "Plans for Bazaar after 2.0" ? [21:51] nekohayo: yes [21:51] uhm, there are some notes, but unfortunately its just a list of things for discussion from monday [21:51] some updates were sent during UDS to the mailing list [21:51] but I guess most are still expected [21:52] I vaguely heard someone raving about that "Plans for Bazaar after 2.0" talk on planet gnome, but couldn't find it [21:52] uh? Not sure, I didn't follow planet gnome really [21:53] I was busy with windows stuff :-/ [21:54] :] [21:54] it was quite hard to spot [21:54] in the middle of a list of bullet points [22:01] nekohayo: not featured in planet.bazaar-vcs.org? [22:02] LarstiQ: nope, haven't seen that there [22:02] and the post in question on p.g.o. is http://bloc.eurion.net/archives/2009/uds-2009/ [22:02] which briefly mentions 2.0, but no details [22:03] hah [22:03] nekohayo: that is just a reference to the `bzr rocks` command [22:04] well with a session title like that, I'm still interested in those "plans after 2.0" [22:04] nekohayo: http://doc.bazaar-vcs.org/devnotes/wishlist.html is a brief list [22:05] nekohayo: you can look at other documents in that dir for more of an idea [22:05] cool [22:08] nekohayo: I think there will be a lot work on UI [22:08] and the plan is to have one stable and one development format in the entire 2.0 cycle [22:09] you mean, olive/nautilus will be usable? :P [22:09] some of the plans also include merging qt/gtk logic behind GUIs [22:09] nekohayo: I meant UI of the "bzr" [22:09] oh [22:10] nekohayo: why is say olive not usable? [22:11] well my general impression from having used it a while ago is that it's not feature-complete, and not much attention/love is given to it because the devs are busy with other things? [22:11] nekohayo: specifics specifics [22:12] * nekohayo finds his bug list [22:12] if you could write a detailed mail to the mailing list, that would be great for example [22:13] well I think this is part of it: https://bugs.launchpad.net/bzr-gtk/+bugs [22:15] the bugs don't seem to be fixed much or the app doesn't "feel" maintained, but this is just a subjective, personal perception [22:16] nekohayo: that's true, I admit it [22:16] but I do understand the time/workforce constraints [22:17] over time I just got accustomed to using bzr on the command line and not hoping for olive or nautilus integration, basically :| [22:17] nekohayo: I really really really hope that will change [22:17] me too :) [22:17] but I have no idea when it will happen? [22:18] nekohayo: this year :p [22:18] I remember about 5-10 bug reports I did back 1-2 years ago on olive AND bzr-gtk (because there was some kind of mess regarding their status in launchpad) [22:18] and I even provided patches which sat there for months [22:18] (for basic 1-2 lines stuff) [22:18] nekohayo: ok, if you'll have patches now I'll process them in like a week at most :p [22:18] that kinda depressed me ;) [22:19] nice [22:19] unless they're 10000lines :P [22:25] nekohayo: so when can I expect patches? :D [22:37] whats the 1.14 format and whats the relation to brisbane-core? [22:41] None, 1.14 adds a WT format for the IO filters. [22:41] ronny: and 1.14 release added a brisbane core as --development-rich-root [22:46] pygi: does that mean the on-disk structures will be stable now? [22:47] ronny: if you're thinking of 2.x having a stable format, then yes