[00:38] <Twelf> Hi guys/girls, I'm confused as to how to restructure my repository to allow better developer visibility into each other's branches. I have set things up like this: http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#nested-style-project-branch-sub-branch
[00:39] <Twelf> If Alice creates a new feature branch in "project/alice/featureA", how can the other developers know that she created such a branch?
[00:40] <AuroraBorealis> i dont think bzr will tell you, just gotta look or something
[00:41] <Twelf> Hm yeah, this is not what I want then. Can you think of an alternate configuration (or some kind of plugin or web interface) that would make feature creation more visible?
[00:41] <AuroraBorealis> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html
[00:42] <poolie> Twelf, how do you want them to be told?
[00:42] <AuroraBorealis> so it seems you just write a simple plugin
[00:43] <AuroraBorealis> and then do in python however you want them to be notified, email, whatever
[00:43] <Twelf> poolie: well, ideally, just by pulling project/alice
[00:43] <Twelf> or some bzr command I'm not aware of
[00:43] <poolie> ok i thought you meant you wanted them to be mailed or something
[00:44] <AuroraBorealis> you could have it branch to their machine by using python right?
[00:45] <Twelf> hm, I'm not sure
[00:46] <Twelf> I think I am operating under the mistaken assumption that a shared repo enables this sort of functionality
[00:49] <Twelf> maybe multi-pull in bzrtools would help
[00:51] <poolie> yes i think that's what you want
[00:51] <poolie> that will soon be built in
[00:51] <poolie> as part of
[00:51] <poolie> https://lists.ubuntu.com/archives/bazaar/2012q1/074217.html
[00:51] <AuroraBorealis> what does multi pull do
[00:52] <poolie> pulls all the branches from one repository
[00:52] <AuroraBorealis> even if they are nested ?
[00:53] <AuroraBorealis> like in that workflow twelf linked, where you have a branch that contains another branch, etc
[00:54] <poolie> in a sub directory?
[00:54] <poolie> i think it only goes down one level
[00:54] <AuroraBorealis> http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#nested-style-project-branch-sub-branch
[00:54] <AuroraBorealis> i'm confused on if that workflow ^ means that every folder is its own branch or not, since bzr doesn't support that
[00:54] <AuroraBorealis> so i think feature1 and feature2 are just folders?
[00:55] <poolie> featureA will be a directory containing a .bzr/branch
[00:55] <Twelf> yep, that's what it looks like in my test
[00:56] <AuroraBorealis> so the top level directory has a 'trunk' folder too (thats not shown)?
[00:56] <AuroraBorealis> it says its a shared repo and a branch
[00:57] <Twelf> I created a shared repo at "project", and then "project/trunk", "project/alice", "project/bob", "project/bob/featureA", etc.
[00:58] <AuroraBorealis> yeah ok.
[00:58] <Twelf> I wonder if bzr_access will be compatible with the new colo stuff. I do need to restrict access for some developers to certain branches
[00:58] <AuroraBorealis> docs are slightly confusing in that regard, since it doesn't support nested branches (like svn)
[00:58] <poolie> biab
[00:58] <Twelf> thanks poolie
[07:32] <vila> hi all !
[09:12] <mgz> morning!
[09:13] <vila> morning mgz !
[09:55] <hariom> Hi, it appears that I have hit the bug where pycurl is not verifying the self signed cert. Is there any solution?
[09:57] <mgz> what version of bzr and what platform?
[09:59] <mgz> what you probably want is to install the self signed cert into your system's location for certificates
[10:01] <hariom> mgz:    bzr = 2.4; ubuntu: 10.04 LTS
[10:03] <mgz> so, try copying the .pem to /etc/ssl/certs then run update-ca-certificates
[10:03]  * mgz is just googling this
[10:25] <chmac> Can I see the history of a file if it was previously deleted, then a new file of the same name created?
[10:26] <mgz> yup.
[10:26] <mgz> ...what, you want to know how? :)
[10:26] <fullermd> Yes, although how is always the opposite of the way I want.
[10:27] <chmac> mgz: Yes please :-)
[10:28] <mgz> fullermd, please enlighten us.
[10:28] <fullermd> A number of commands can take a revision and a filename.  IME, they all lookup the fileid from the filename as of that revision, except for the ones where I want it to lookup the filename as of current and backtrack to that rev.
[10:29] <fullermd> And I think I meant "except that" there.  Dunno.  Viri stealing my brainz.
[10:29] <mgz> basically `bzr log -r<a revision the file existed> <the filename at that point>` should work
[10:30] <mgz> alternatively you can find the fileid, then use that in some places
[10:30] <fullermd> Probably have to dig through logs to find the rev where it was deleted, then do something like `log -r0..$THAT $FILE`.
[10:30] <fullermd> Or maybe ..before:$THAT, since in $THAT it's deleted.
[10:30] <fullermd> I've wished for the ability to explicitly pass fileid's to things like log/diff/etc a number of times in the past   :|
[10:32] <mgz> that might make a few things easier indeed.
[10:33] <chmac> mgz: Thanks, I'll look into it now
[10:36] <chmac> Awesome, thanks folks, I have my old my.cnf back thanks to etckeeper :-)
[10:37] <mgz> good good :)
[10:37] <mgz> hm, dulwich has a copy of the lru_cache module
[11:43] <libertas> hi, I have a conflict I've not been able to resolve: Path conflict: bin/update_bds.OTHER / <deleted>
[11:43] <libertas> the file is not there, how can I do this?
[11:49] <mgz> libertas: `bzr resolve bin/update_bds.OTHER` probably
[11:49] <mgz> though as it's an OTHER file you may have done something a little wrong during the merge, so I'd double check the diff of changes as well
[11:50] <libertas> it resolved now, strange, I guess I was inside bin/ and it wasn't doing it...
[11:50] <libertas> mgz thank you!
[11:51] <fullermd> That probably means that you deleted the file in your branch, and the branch you merged made changes to it.
[13:05] <mgz> okay, first upgrade pain, consolekit hung itself
[13:08] <fullermd> Luckily, that never happens to me.  At least, I don't think it does.  I dunno how I'd know if it did.  Or what it is...
[13:11] <mgz> I suspect freebsd saves you from such an 'upgrade'
[13:11] <fullermd> Well, as near as I can tell at a glance, it's some internal bit of gnome.  Not messing with such a thing also saves me  :p
[13:26] <crisb> can anyone recommend an approach to me regarding automatically updating a bug tracker when --fixes is specified on commit? ie should this be done at the repository side, if so how to do this from a push request?
[13:27] <crisb> i'm thinking it must be the repository side so that a public branch name is available
[15:39] <LarstiQ> crisb: trac-bzr might have some way of doing that?
[15:40] <LarstiQ> Jesdisciple: concerning your commit message, if I understood it correctly: an editor pops up, write your message, and save and quit the editor
[15:41] <LarstiQ> crisb: so you can have a hook local when the commit happens, or in some central location that gets pushed to (smart server hook if you use that, or then cron/inotify/something like that)
[17:27] <iamben> hello sirs.  is threads support on python required unconditionally for bzr?
[17:28] <mgz> no. but we use the logging module which imports it.
[17:29] <mgz> dummythreading should be enough
[17:29] <mgz> +_
[17:32] <iamben> so this logging module can be disabled? simple "bzr init-repository --no-trees <repo-addr>" errors w/o threads support
[17:34] <mgz> python should work still provided you have the dummy_threading module
[17:34] <mgz> what's the extact error?
[17:34] <mgz> !pastebin
[17:35] <iamben> http://paste.pocoo.org/raw/548446/
[17:35] <iamben> i know that i can fix it by adding threads support, i just want to make sure my distro has their dep list correct
[17:38] <mgz> ah, that looks like our fault
[17:38] <mgz> try hacking in something like:
[17:38] <mgz> import dummy_thread
[17:38] <fome> hi, im trying to branch a package of launchpad and i allways get this error: bzr: ERROR: Revision {package-import@ubuntu.com-20110812122506-zko6c7zfexvyg71q} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
[17:38] <fome> any idea what that means?
[17:38] <mgz> sys.modules['thread'] = dummy_thread
[17:49] <iamben> mgz: i'm no python guy but i hacked these 2 lines into /usr/lib64/python2.7/site-packages/bzrlib/bzrdir.py and it works, is that what you were thinking?
[17:49] <mgz> anywhere will do, it's a global change
[17:50] <mgz> I was thinking of the bzr script, but shows that dummy_thread is enough
[17:50] <mgz> grepping shows we only use thread.get_ident except in the smart server and testing using the smart server
[17:51] <jelmer> fome: hi
[17:51] <jelmer> fome: I think that can be avoided by disabling the up-to-date-ness check in bzr
[17:51] <iamben> mgz: /usr/bin/bzr is some kind of wrapper script on gentoo, i'll just report this and let our bzr and/or python maintainers decide what to do, thanks
[17:53] <fome> jelmer: how would i go about that?
[17:53] <iamben> mgz: is this dummy_thread module a kind of "safe fallback" that will use threads when available, or do we need to use it conditionally ONLY when threads are not wanted?
[17:54] <mgz> iamben: I'm not clear from the python documentation on who the onus to do this fallback is,
[17:54] <jelmer> fome: set launchpad.packaging_verbosity=False in the configuration
[17:54] <lifeless> iamben: I suggest you just require a threaded python
[17:54] <mgz> either every python module that uses either the thread or threading module,
[17:55] <lifeless> iamben: pretty much /every/ build of python out there that isn't on tiny embedded systems is threaded.
[17:55] <mgz> or the maintainers of python distributions that build without threading enabled
[17:55] <iamben> i'll just report with a suggestion to force threading, and mention the possibility of dummy_thread
[17:57] <jelmer> iff building without thread support is really something we want, then I'd argue this is a bug in the logging module
[17:58] <mgz> well, I think logging actually uses threading, which *does* fall back to dummy_threading correctly
[17:58] <mgz> but thread does not automatically fall back to dummy_threading
[17:58] <mgz> and a few of the smart bits import it just for get_ident (the actual smart server does want to start threads),
[17:59] <mgz> but for some reason we're pulling in enough in bzrdir to import thread in some train from there apparently
[18:01] <jelmer> hmm, odd
[18:01] <jelmer> anyway, EOD.. time for some lp hacking :)
[18:02] <mgz> that's what I'm guessing from the traceback and grepping around at any rate, I've not actually traced it
[18:03] <mgz> I need to finish bending twisted to my will first...
[18:44] <mgz> gah, that was a silly error to waste half an hour on
[19:02] <LarstiQ> mgz: twisted?
[19:04] <mgz> don't ask >_<
[19:05] <mgz> the best way I found of debugging this test was waiting the 120 seconds for the timeout
[19:05] <mgz> there was a timeout param on an object that din't actually change the duration
[19:23] <LarstiQ> mgz: d'oh
[19:27] <mgz> I think there are probably cleverer ways of doing lots of these things but I've yet to learn them
[19:28] <mgz> okay, done
[19:28] <mgz> time to head down
[19:32] <wgz> hm, now what
[19:38] <LarstiQ> wgz: should I close a bug as Inv
[19:39] <LarstiQ> alid if work somewhere else has already taking care of it?
[20:14] <wgz> LarstiQ: hm.
[20:15] <LarstiQ> s/taking/taken/
[20:15] <wgz> in this case that's probably the best option,
[20:15]  * LarstiQ was looking for a "Not For Us" option
[20:15] <wgz> as we want a record of the bug, but aren't going to be changing how we use os.listdir for this reason
[20:16]  * LarstiQ nods
[20:39] <bdmurray> I've noticed that the update-manager branch for lucid is out of date
[20:39] <bdmurray> Is there something that can be done to fix this?