=== medberry is now known as med_ou === med_ou is now known as med_out === jamesh_ is now known as jamesh === jr__ is now known as Riddell [09:05] bonjour === hunger_ is now known as hunger [09:41] Riddell: hello ! [09:57] vila: Hello. Now that fixit.sh is merged, shall I translate my existing commands from the bugreport to use it? [09:58] maxb: for extra clarity, it would be nice, but you don't have to [09:58] maxb: did you have confirmation of the deployment ? [09:58] err, off the lp side of things [09:58] s/off/of/ [09:58] Still waiting on that [09:58] ok [09:59] 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] maxb: I'll wait for your ping then [09:59] :) [10:00] maxb: oh, by the way, I did a launchpad-login on jubany and this seems to work [10:00] 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] s/any/&thing/ [10:49] hah, hello for real [11:44] jamesh: did you see my request about https://code.launchpad.net/~jr/bzr/bzr-gpgme/+merge/64859 ? === ubot5` is now known as ubot5 === smoser` is now known as smoser === med_out is now known as med === med is now known as medberry [15:25] hi all [15:25] thanks for that riddell [15:28] for the gpg stuff? you're welcome :) [15:28] hey poolie [15:29] hi vila [15:32] Riddell: One thing which occurred to me looking at your examples.... OK, 1 commit not valid..... which commit? :-) [15:33] the invalid one ;-P [15:34] maxb: you use -v to show you the invalid author and bzr log --signatures to find the commit [15:35] 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] Riddell: convenience [15:37] why use 3 commands if one is enough ? [15:39] in the log perhaps it would be good to show the key id [15:39] vila, i was wondering if you could share your todo list or plan for babune [15:39] or summarize it, if the current one is too cryptic or detailed [15:42] http://paste.ubuntu.com/630417/ [15:44] thanks [15:45] that looks good [15:45] i think it would be good to get it off your own personal hardware, for a couple of reasons [15:45] yes ! bug #688101 is almost dead ;) [15:45] Launchpad bug 688101 in Bazaar "Failing to bzr resolve multiple conflicts bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]" [High,In progress] https://launchpad.net/bugs/688101 [15:45] hooray [15:45] one being so it's not down if you're away [15:46] and it may be the last case where we have multiple conflicts for the same file... [15:46] also so we can run more builders [15:46] and, also, so other people can co-admin it [15:46] i'm setting up usertest again and it would be nice if that was actually driven by jenkins not cron === zyga is now known as zyga-food [15:46] (perhaps) [15:47] 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] sure, as long we keep the ability to admin it [15:48] ha, that would be mostly addressed if the sources were public [15:49] what is baboun? [15:50] i think probably our own machine, but on a server somewhere else [15:50] Riddell: http://babune.ladeuil.net:24842/ [15:50] Riddell: it re-tests bzr on other operating systems than that run by pqm [16:00] abentley: Hi, would you be able to offer some comments on bug 796748 when you have a moment? [16:00] Launchpad bug 796748 in Bazaar "TreeTransform canonicalises symlink-containing paths wrongly" [High,Confirmed] https://launchpad.net/bugs/796748 [16:01] maxb: what kind of comment are you looking for? [16:02] To start with, a quick sanity check - and maybe an explanation why treetransform is canonicalizing symlinked paths at all [16:04] maxb: paths are canonicalized so that you cannot get two trans_ids for the same path. [16:05] It makes sense to me to canonicalize /./, /../, // etc. - but I'm less convinced about expanding symlinks to their underlying path [16:06] maxb: symlinks themselves should not be transformed to the path they point at. Files under those symlinks should. [16:06] Why should they? [16:06] maxb: otherwise, you wind up with two references to the same file, and that will break TT. [16:07] 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] maxb: Another way to fix it would be to forbid traversal through symlinks, and perhaps that's what I should have done. [16:08] That sounds like a practical option for fixing this [16:09] maxb: I don't think you've found a situation where the same trans_id has been given to two different paths. [16:09] No, I really have. I hacked in some print statements and observed it [16:09] maxb: A trans-id can only refer to one path in the source tree. [16:10] Well, it's *supposed* to, yes. But that got violated [16:10] maxb: It cannot, unless you change the source tree while the TT is active. [16:10] maxb: Which is against the rules. [16:12] 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] 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] maxb: Right. [16:13] 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] maxb: How are you driving it? [16:14] via "bzr import-dsc" [16:15] maxb: without looking at the code, it sounds like a bug in bzr import-dsc. [16:16] I'm not really convinced [16:17] If I have this tree: [16:17] lenny/ [16:17] 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] lenny/some-file [16:17] squeeze -> lenny [16:18] 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] maxb: sure. This will take a sec. [16:19] maxb: Now, what do you want to do about the original some-file? [16:19] for the sake of this example, let's say we want to update its text content, only [16:20] maxb: so you want to create a new some-file at squeeze/some-file, and update the contents of lenny/some-file? [16:20] yes [16:24] maxb: http://pastebin.ubuntu.com/630431/ [16:27] 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] If so, import-dsc is running afoul of that [16:27] maxb: no. You can do tree transform operations in any order. That's part of the design. [16:28] Ah. [16:28] maxb: However, You cannot create squeeze/some-file at all using trans_id_tree_path. [16:28] Right... *that* is the violation going on here, then [16:28] maxb: Because in the tree, squeeze/some-file was lenny/some-file [16:29] 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] I'm unclear what you mean by "must be a new file" [16:31] Or why moving lenny/some-file should matter [16:32] maxb: by "must be a new file" I mean it must be a file with a new trans-id. [16:33] Well, quite. I want it to be. And it would be if trans_id_tree_path didn't follow symlinks [16:35] 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] hmm [16:35] maxb: I think you may not realize that trans_id_tree_path refers to paths in the source tree. [16:36] OK, so it sounds like import-dsc is being lazy in how it constructs the TT [16:36] maxb: and therefore nothing you do in the transform should change its output. [16:37] maxb: that seems possible. [16:37] 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] maxb: np. [16:39] (the same code is present in bzrtools, ftr) [16:45] 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] maxb: have you filed a bug on import-dsc or bzrtools? [16:54] No, only the one on bzr, at present [16:58] maxb: what's the project for import-dsc? [16:58] builddeb [16:59] maxb: I've filed bug #800270 [16:59] Launchpad bug 800270 in BzrTools "import-tar incorrectly handles symlinks turned into directories" [Medium,Triaged] https://launchpad.net/bugs/800270 [20:01] is there bzr webinterface that can generate static files as on-push hook, that could be then simply served via webserver? [20:02] ccxCZ, there was a bzr-html plugin that did that, though very rudimentary [20:06] hmm, nicehtml is 404 and htmllog is just commit message log [20:12] ccxCZ, what sort of information are you looking for? [20:13] well, mostly what loggerhead does, altough it doesn't have to be so fancy-ajaxy [20:16] I don't think there is anything like that (or even close to that). [20:17] 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] loggerhead IIRC has one page per revision of each file (including markup), and then some [20:25] hmm, when I do bzr log -n 0 -p on my projects it doesn't go over few megs [20:25] I think it should be reasonably doable for smaller projects [20:25] ccxCZ: That shows the diffs though, not the full file contents (like loggerhead) [20:29] yes. I expect it would be significantly larger than that, but it gives some estimate === yofel_ is now known as yofel === medberry is now known as med_out === med_out is now known as med === med is now known as medberry [23:53] Hurrah, LP fix is deployed. vila / james_w / spiv : If you happen to be around, requeue_package.py --all-of-type bzr please?