[09:05] <Riddell> bonjour
[09:41] <vila> Riddell: hello !
[09:57] <maxb> vila: Hello. Now that fixit.sh is merged, shall I translate my existing commands from the bugreport to use it?
[09:58] <vila> maxb: for extra clarity, it would be nice, but you don't have to
[09:58] <vila> maxb: did you have confirmation of the deployment ?
[09:58] <vila> err, off the lp side of things
[09:58] <vila> s/off/of/
[09:58] <maxb> Still waiting on that
[09:58] <vila> ok
[09:59] <maxb> it will be easy enough to translate the commands - I will just rewrite my version of the shell functions to ones which echo code in the new format
[09:59] <vila> maxb: I'll wait for your ping then
[09:59] <vila> :)
[10:00] <vila> maxb: oh, by the way, I did a launchpad-login on jubany and this seems to work
[10:00] <vila> maxb: just one more thing to keep an eye open for for a few days (in case this triggers something (not that I can think of any though))
[10:01] <vila> s/any/&thing/
[10:49] <jelmer> hah, hello for real
[11:44] <Riddell> jamesh: did you see my request about https://code.launchpad.net/~jr/bzr/bzr-gpgme/+merge/64859 ?
[15:25] <poolie> hi all
[15:25] <poolie> thanks for that riddell
[15:28] <Riddell> for the gpg stuff?  you're welcome :)
[15:28] <vila> hey poolie
[15:29] <poolie> hi vila
[15:32] <maxb> Riddell: One thing which occurred to me looking at your examples.... OK, 1 commit not valid..... which commit? :-)
[15:33] <vila> the invalid one ;-P
[15:34] <Riddell> maxb: you use -v to show you the invalid author and bzr log --signatures to find the commit
[15:35] <Riddell> I did think of having  bzr verify -vv  or something for very verbose which showed each commit but then why not just use bzr log
[15:37] <vila> Riddell: convenience
[15:37] <vila> why use 3 commands if one is enough ?
[15:39] <poolie> in the log perhaps it would be good to show the key id
[15:39] <poolie> vila, i was wondering if you could share your todo list or plan for babune
[15:39] <poolie> or summarize it, if the current one is too cryptic or detailed
[15:42] <vila> http://paste.ubuntu.com/630417/
[15:44] <poolie> thanks
[15:45] <poolie> that looks good
[15:45] <poolie> i think it would be good to get it off your own personal hardware, for a couple of reasons
[15:45] <vila> yes ! bug #688101 is almost dead ;)
[15:45] <poolie> hooray
[15:45] <poolie> one being so it's not down if you're away
[15:46] <vila> and it may be the last case where we have multiple conflicts for the same file...
[15:46] <poolie> also so we can run more builders
[15:46] <poolie> and, also, so other people can co-admin it
[15:46] <poolie> i'm setting up usertest again and it would be nice if that was actually driven by jenkins not cron
[15:46] <poolie> (perhaps)
[15:47] <poolie> oh, also i was remembering that thing at our recent sprint of "i have to wait until i get home to do this"
[15:47] <vila> sure, as long we keep the ability to admin it
[15:48] <vila> ha, that would be mostly addressed if the sources were public
[15:49] <Riddell> what is baboun?
[15:50] <poolie> i think probably our own machine, but on a server somewhere else
[15:50] <vila> Riddell: http://babune.ladeuil.net:24842/
[15:50] <poolie> Riddell: it re-tests bzr on other operating systems than that run by pqm
[16:00] <maxb> abentley: Hi, would you be able to offer some comments on bug 796748 when you have a moment?
[16:01] <abentley> maxb: what kind of comment are you looking for?
[16:02] <maxb> To start with, a quick sanity check - and maybe an explanation why treetransform is canonicalizing symlinked paths at all
[16:04] <abentley> maxb: paths are canonicalized so that you cannot get two trans_ids for the same path.
[16:05] <maxb> It makes sense to me to canonicalize /./, /../, // etc. - but I'm less convinced about expanding symlinks to their underlying path
[16:06] <abentley> maxb: symlinks themselves should not be transformed to the path they point at.  Files under those symlinks should.
[16:06] <maxb> Why should they?
[16:06] <abentley> maxb: otherwise, you wind up with two references to the same file, and that will break TT.
[16:07] <maxb> In that bug, I've found a situation where the current canonicalization gives the same trans_id to two paths which are actually distinct, and that breaks it too
[16:07] <abentley> maxb: Another way to fix it would be to forbid traversal through symlinks, and perhaps that's what I should have done.
[16:08] <maxb> That sounds like a practical option for fixing this
[16:09] <abentley> maxb: I don't think you've found a situation where the same trans_id has been given to two different paths.
[16:09] <maxb> No, I really have. I hacked in some print statements and observed it
[16:09] <abentley> maxb: A trans-id can only refer to one path in the source tree.
[16:10] <maxb> Well, it's *supposed* to, yes. But that got violated
[16:10] <abentley> maxb: It cannot, unless you change the source tree while the TT is active.
[16:10] <abentley> maxb: Which is against the rules.
[16:12] <abentley> maxb: Maybe "paths" is incorrect.  I don't think you've found a situation where the same trans_id has been given to two different files.
[16:13] <maxb> OK, that's partially true. There was one trans_id, assigned to two paths, which both led to the same file in the source tree
[16:13] <abentley> maxb: Right.
[16:13] <maxb> But, the intent was to drive the TT to remove the symlink involved, and put two distinct files at the two paths concerned
[16:14] <abentley> maxb: How are you driving it?
[16:14] <maxb> via "bzr import-dsc"
[16:15] <abentley> maxb: without looking at the code, it sounds like a bug in bzr import-dsc.
[16:16] <maxb> I'm not really convinced
[16:17] <maxb> If I have this tree:
[16:17] <maxb> lenny/
[16:17] <abentley> maxb: I'm not either.  But since I don't know what the code is trying to do, I don't know what the bug is.
[16:17] <maxb> lenny/some-file
[16:17] <maxb> squeeze -> lenny
[16:18] <maxb> Can you describe a valid way to drive TT to remove the squeeze symlink, create a squeeze directory, and a file squeeze/some-file ?
[16:18] <abentley> maxb: sure.  This will take a sec.
[16:19] <abentley> maxb: Now, what do you want to do about the original some-file?
[16:19] <maxb> for the sake of this example, let's say we want to update its text content, only
[16:20] <abentley> maxb: so you want to create a new some-file at squeeze/some-file, and update the contents of lenny/some-file?
[16:20] <maxb> yes
[16:24] <abentley> maxb: http://pastebin.ubuntu.com/630431/
[16:27] <maxb> abentley: OK.... is it considered technically invalid to attempt to create squeeze/some-file in a way involving a call to tt.trans_id_tree_path('squeeze/some-file'), before the squeeze directory is real on disk?
[16:27] <maxb> If so, import-dsc is running afoul of that
[16:27] <abentley> maxb: no.  You can do tree transform operations in any order.  That's part of the design.
[16:28] <maxb> Ah.
[16:28] <abentley> maxb: However, You cannot create squeeze/some-file at all using trans_id_tree_path.
[16:28] <maxb> Right... *that* is the violation going on here, then
[16:28] <abentley> maxb: Because in the tree, squeeze/some-file was lenny/some-file
[16:29] <abentley> maxb: Since you're replacing squeeze with a directory, squeeze/some-file must be a new file, or you must move lenny/some-file.
[16:30] <maxb> I'm unclear what you mean by "must be a new file"
[16:31] <maxb> Or why moving lenny/some-file should matter
[16:32] <abentley> maxb: by "must be a new file" I mean it must be a file with a new trans-id.
[16:33] <maxb> Well, quite. I want it to be. And it would be if trans_id_tree_path didn't follow symlinks
[16:35] <abentley> maxb: No, it would be an existing id in that case, too.  You'd just have two existing ids for trans_id_tree_path, one for squeeze/some-file and one for lenny/some-file.
[16:35] <maxb> hmm
[16:35] <abentley> maxb: I think you may not realize that trans_id_tree_path refers to paths in the source tree.
[16:36] <maxb> OK, so it sounds like import-dsc is being lazy in how it constructs the TT
[16:36] <abentley> maxb: and therefore nothing you do in the transform should change its output.
[16:37] <abentley> maxb: that seems possible.
[16:37] <maxb> Alright, this conversation has clarified that the code in import-dsc was written cutting some corners in how to properly drive TT, and needs an overhaul - thanks.
[16:39] <abentley> maxb: np.
[16:39] <maxb> (the same code is present in bzrtools, ftr)
[16:45] <abentley> maxb: Yes, I think I didn't anticipate the problems with replacing a symlink with a file.  Aside from that, using the tree paths seems fine.
[16:53] <abentley> maxb: have you filed a bug on import-dsc or bzrtools?
[16:54] <maxb> No, only the one on bzr, at present
[16:58] <abentley> maxb: what's the project for import-dsc?
[16:58] <maxb> builddeb
[16:59] <abentley> maxb: I've filed bug #800270
[20:01] <ccxCZ> is there bzr webinterface that can generate static files as on-push hook, that could be then simply served via webserver?
[20:02] <jelmer> ccxCZ, there was a bzr-html plugin that did that, though very rudimentary
[20:06] <ccxCZ> hmm, nicehtml is 404 and htmllog is just commit message log
[20:12] <jelmer> ccxCZ, what sort of information are you looking for?
[20:13] <ccxCZ> well, mostly what loggerhead does, altough it doesn't have to be so fancy-ajaxy
[20:16] <jelmer> I don't think there is anything like that (or even close to that).
[20:17] <jelmer> More than just dumping the current contents to disk would also require an insane amount of disk space for any project with a nontrivial amount of history or a non-trivial tree.
[20:17] <jelmer> loggerhead IIRC has one page per revision of each file (including markup), and then some
[20:25] <ccxCZ> hmm, when I do bzr log -n 0 -p on my projects it doesn't go over few megs
[20:25] <ccxCZ> I think it should be reasonably doable for smaller projects
[20:25] <jelmer> ccxCZ: That shows the diffs though, not the full file contents (like loggerhead)
[20:29] <ccxCZ> yes. I expect it would be significantly larger than that, but it gives some estimate
[23:53] <maxb> Hurrah, LP fix is deployed. vila / james_w / spiv : If you happen to be around, requeue_package.py --all-of-type bzr please?