[00:20] I have a revision id for a file that was merged into the branch. I try to get the revno of that revision id and I'm told there is no such revision. How can you get the revno without looping through all revisions and checking the inventory? [00:32] got a question about pushing a shared repo to a server [00:33] if i setup a shared repo locally: (e.g. bzr init-repo website ; bzr init website/trunk) [00:34] poolie: ping? [00:34] ... hack on the trunk, and then am ready to push the trunk to a server so others can access it, according to the docs I can do something like.... [00:35] bzr push --create-prefix bzr+ssh://host/path/to/repos/website/trunk [00:35] to create the branch on the remote server. so far so good... [00:36] what I don't get is that locally, in the top-level repo, there's a .bzr folder where (if I understand correctly), files will be shared amongst branches [00:37] there's no similar .bzr folder on the server, so it appears there's no sharing. [00:37] mmclark: the repo is for sharing _revisions_ between multiple branches [00:37] is that correct? is the approach above the best way to go? [00:37] ok [00:37] mmclark: you have to do init-repo on the server side to get the same thing there. [00:38] ok, so if i start by doing a bzr init-repo bzr+ssh://host/path/to/repos/website ... [00:38] haven't tried that, but it might work :) [00:38] and then push the branch as I did, then we've got the same scenario both locally and remotely [00:39] right [00:39] ok - i'll give that a try. thanks [00:59] hi maxb [01:03] poolie: hi [01:03] You mentioned that pitti said 2.2.1 needed to be a SRU - I was wondering if you had a link to that, as I got a verdict that a post-RC release pocket upload was still reasonable, said about 24 hours ago [01:04] either way, I've subscribed ~ubuntu-release and requested an official verdict [01:04] maxb, he said that in #ubuntu-devel about 16h ago [01:04] i think it will be in the irclogs.ubuntu.com scrollback [01:05] if we can do better that's brilliant [01:06] hmm [01:07] I think we're hearing a slightly different position from different ~ubuntu-release members, so I guess we'll see what they say in response to me subscribing them to the bug [01:08] from my experience you'll have to actually poll them not just subscribe them [01:08] Meanwhile, I think we should try to get some bzr selftest analysis of 2.2.0-1 vs. 2.2.1-0~bazaar1~maverick1 in the bug, in the spirit of the MicroReleaseException [01:10] it could be good to check the failures are a subset [01:23] maxb i'll try to do that soon [01:44] Anyone have a minute to help me out with the bzrlib API? I'm completley stumped. [01:45] * maxb is no expert, but perhaps... [01:45] jeremyw: sure, just ask [01:46] I have a revision_id and when I try to get its revno, I'm told there is no such revision. I guess that revision_id corresponds to another repository. [01:46] Is there any way to get the revno without iterating over the whole history and seraching each revision's inventory? [01:46] I asked this earlier but got no response. Pardon the asking to ask thing...didn't want to waste my time again. [01:47] What API? Branch.revision_id_to_dotted_revno ? [01:47] I got the revision_id using b.repository.get_inventory(youngest_revision)[file_id].revision [01:48] And I later use b.revision_id_to_revno() [01:48] b is a branch.Branch [01:49] revision_id_to_revno only consults the mainline [01:49] Use revision_id_to_dotted_revno [01:51] That helps. :) The numbers don't match what 'bzr log' would output but I'm sure I can figure out why. [01:51] How easy was that...ugh. [01:51] uh, they don't match?! [01:52] Well, basically I'm trying to find the last revision (local) a file was modified. If I use log.find_touching_revisions(), I get some revisions that I'm comparing this other work to. [01:52] Maybe find_touching_revisions() isn't right? I'll consult the log. [01:53] Okay...so 'bzr log setup.py' shows 425 as the last modified version while the revision_id_to_dotted_revno returns 424. [01:55] revision_id_to_dotted_revno returns a tuple doesn't it? [01:55] Maybe my approach is wrong. What I've done is I use branch.list_files(recursive=False) to get the file_id. I then use the file_id to get a revision_id it was last modified. I then am using this API you told me about. [01:56] that's certainly the approach that I would use [01:57] It returns a tuple...going to see what the pieces mean...maybe there is something I can do to get the exact same number that 'bzr log -l1 PATH' gives me. [01:58] The tuple woudl be the components of the [dotted] revno. [01:59] So it's 424.something.something; you see it listed on log in 425 because that's the rev that merged those changes. [01:59] If I use log.find_touching_revisions(file_id) and I get the last entry, I get a number that matches the same output as 'bzr log -l1 PATH'. [01:59] * jeremyw reads [01:59] fullermd: So how might I get 425 instead of 424? [02:00] Well, 425 is sorta a lie. Depending on semantics. [02:00] But I don't understand the semantics enough to figure out if my code/approach is borked or I've got it right and the CLI is giving you the lie. [02:01] 425 just copied in the changes from 424.whatever.whatever. Collapsed log shows it because otherwise it couldn't show anything, which is flat wrong. Expanded log shows it because it's too confusing to have a right-side path without showing where it walked off the left side. [02:02] Defining changes is a little tricky with branched history. In this case, 425 has different contents in that file from 424, so in one sense, it changed. But it's the same contents as 424.whatever.whatever, which is ALSO a parent of 425. So in another sense, it didn't change. [02:02] What bzrlib is telling you is that 424.something.something is the rev where that was actually changed. [02:03] log actually does a fair amount of work beyond that to try and make pretty-understandable output on top of the low-level facts. [02:04] Alright. [02:04] So let's pretend you had a repository browser and I showed you 424 but the cli showed you 425. You'd be confused right? [02:04] Any thought on how I might be able to remedy this? [02:05] 424 isn't the answer. The answer is 424.something.something. It's a dotted revno, not on the mainline. [02:05] I believe you just glue the tuple bits together to get the full thing. [02:06] Okay. I see what you mean. But if I wanted to only track mainline, how could I get 425 without doing it the same way log does, which is really expensive? [02:06] I want to lie. ;) [02:06] Well, I'd suspect if there were a cheaper way to lie, we wouldn't have made log expensive for no reason :) [02:06] I guess not. [02:07] At a high level, you'd need to take that rev you found, and walk forward until you first hit the left path. That's probably not going to be especially cheap. [02:08] I think that it's possible to do some things more cheaply if you only care about mainline. [02:08] Here's what I'm talking about: http://dpaste.com/250788/ [02:08] if you build the merge sorted revision graph it's easy enough [02:08] jeremyw: Yeah, you might just want to try using bzr-history-db? [02:08] If it works outside of loggerhead, that is. [02:09] jeremyw: 3.5 s seems awfully slow, are you read locking the branch? [02:09] Yes. [02:09] and it's a 2a format branch? [02:10] Yup. [02:10] Now you see why I'm trying to do this quicker. [02:10] I presume that's 3.5 seconds to do log __init.py ; log docs ; log loggerhead ; [...]. That doesn't sound all that slow to me. [02:10] there might be a Graph call to get first merged point of A in to B, which is what you want here [02:11] mwhudson: I've seen that sort of operation take 3.5s before, many times. Although usually on heavily-loaded systems when working with a large history. [02:11] This is the loggerhead sources...only 428 revisions. [02:11] Not really a large history. [02:12] I mean, I'm reporting against the loggerhead sources, the root of the branch only. [02:12] jeremyw: The loggerhead sources are deceptive. [02:12] jeremyw: They have lots of large merges. [02:13] Okay. [02:13] So the mainline history is short, yeah, but the full history is pretty complex. [02:14] Okay. [02:15] I guess I could save some time by only using the find_touching_revisions() for revision_id that aren't on the mainline. In the case here, it's roughly 60% of the files listed so maybe I could shave off 1.5 seconds from the 3.5 seconds. [02:15] Not a huge gain but, well, if it's the only way to do it... [02:16] Well, the most expensive part is probably building the graph. And once you do that once (in a single process), reusing it should be pretty cheap. [02:16] I can test this by running the same thing twice? [02:17] That wasn't really a question. [02:17] Shaved off .11s. [02:19] Well, sounds like I'm stuck for now. Using the log, I get cli/mainline accurate results but suffer a performance hit. I can dig that since it works and wouldn't prompt confusion. [02:21] One of the biggest hits for log.find_touching_revisions() is that it starts from oldest to newest to create the graph and since I want the last changed revision, I'd need to go backwards. [02:21] I'll try that and see if I can speed things up. [02:26] Thoughts? [02:27] jeremyw: i thought there was a way to go backwards? [02:27] i'm pretty sure log from newest to oldest doesn't buffer the whole thing [02:27] jeremyw: I think you want bzr-history-db. [02:27] jeremyw: Its purpose is to speed up that operation, IIRC. [02:28] jeremyw: It's jam1's baby. [02:47] maxb, there is bug 651706, does that sound familiar to you? [02:47] Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/651706 [02:54] You guys are going to laugh...writing my own version of find_touching_revisions() that goes backwards, does it in .79s instead of 3.5s and returns the same results. :) [02:56] http://dpaste.com/250801/ [02:56] mkanat | fullermd | mwhudson: ^^^ [02:56] Pretty fricking slick. [02:56] I see that the loggerhead directory entry is missing...I bet I can fix that. Other than that, it's identical and much faster. [02:57] jeremyw: Sounds like find_touching_revisions itself should be fixed? [02:57] that seems more like it [02:57] Well, my approach doesn't care about creating a log output for each revision where it's logged, only the last. [02:57] So I don't think find_touching_revisions is the problem. [02:58] jeremyw: In that case, isn't there a better way to do it already, iter_...something? [02:58] To do it backwards or to get the last without the rest? [02:59] I wonder why loggerhead is missing from the output in the third list... [03:02] It was my fault...bad range usage. [03:07] My last paste: http://dpaste.com/250802/ [03:07] That shows the final results. [03:09] That isn't fricking bad if you ask me. :) [03:11] jeremyw: Nice. [03:13] jeremyw: just to mention, find_touching_revisions looks to be a pretty terrible function in general, it grabs the full inventory of every revision in the mainline... going in reverse is an option, but it isn't exactly a great option, anyway yes, for your use case going in 'reverse' makes sense, but just loading "revision_history()" is pretty expensive (think emacs) [03:14] jeremyw: note that "find_touching_revisions" isn't actually used by log, there is only one user, a hidden command "cmd_touching_revisions" [03:14] definitely not what I would pick as my starting material [03:16] as reference, try doing the same thing for bzr's source tree [03:18] jeremyw: one option is to use "for rev_id in repo.iter_reverse_revision_history(branch.last_revision()): [03:19] possibly batch them, and then call deltas = repo.get_deltas_for_revisions(revison_ids, file_ids) [03:33] hi everyone [03:34] is there anyone here that might have a shoulder for crying on? [03:34] Will there be cake? 'cuz I'll take a lot of crying for good cake. [03:35] hmm [03:35] depends on whether i can get it out of bzr lol [03:35] so not likely :( [03:35] ... OK, I'll take crying for bad cake too. I'm not particular. [03:36] $: make cake [03:36] make: *** No rule to make target `cake'. Stop. [03:36] bugger [03:36] i dont have the source [03:37] jam1: I'll look into that. Would repo.iter_reverse_revision_history(branch.last_revision()) be any lighter than just doing what find_touching_revisions() in reverse would do? [03:37] That sounds like a bug in make. Something that important should be built-in. [03:37] i agree... i need to go raise a report i reckon [03:37] jam1: I'll probably spend some time with cmd_log.run() to make sure I'm not doing things completely wrong using any version of find_touching_revisions(). [03:38] jeremyw: I think that's the method I was thinking of. [03:38] jeremyw: there are a few things [03:38] jam1: If you know of any way to find the last revision a file was changed that is what you'd use, let me know. [03:38] 1) just doing it in reverse is a good start for you [03:38] 2) switching to iter_reverse_revision_history() will help *a lot* for large histories like emacs [03:38] (think 100k mainline revs, vs 400) [03:39] That's the end result here...based on a path, and potentially a revision, find out when it was last changed. [03:39] 3) Switching the api to do multiple file-ids at once will be a big win for your use case [03:39] since otherwise you iterate the same history multiple times [03:39] 4) If you just want the last modified revision tree.inventory[file_id].revision is that value, but it is the 'actually changed' value, not the last revision which merged the last change [03:40] 5) lp:bzr-history-db makes it fast to find the mainline revision that merged a given revision by writing out some cached info into a sqlite database [03:40] (as in, low ms not seconds) [03:41] I don't remember if I have that specific function encoded, but it would be pretty cheap in the datastructure [03:41] jeremyw: The loggerhead trunk branch has incorporated bzr-history-db into the main process now [03:42] jam1: Cool. [03:43] jam1: That's the next enhancement I was goign to make to my version of find_touching_revisions_in_reverse, to handle multiple file_ids at once. [03:44] What I'll probably do to finish this learning process is to enhance my version to do multiple file_ids at once and another version doing the iter_reverse_... [03:45] jeremyw: so if it was me, and I was really concerned about performance, I would grab bzr-history-db, use for file_id in file_ids: revision_id = inv[file_id].revision [03:45] and then look up the mainline revs for all of those in one go [03:45] peitschie: You don't have the source, because the cake is a lie. [03:45] def get_mainline_where_merged(self, revision_ids): [03:45] in history_db.py [03:46] jam1: Pretend that isn't an option right now, bzr-history-db. I'm trying to learn and add a feature at the same time. I'd deal with a little loss of performance at this state for a solid understanding by doing it myself. [03:46] jbowtie: the cake being a lie is the lie. If you play through the whole thing, there is a cake in the closing scene [03:46] fullermd: I'm sure you meant to say "baked in" [03:47] jam1: Yes, a plastic cake. It's a double-bluff. [03:48] On topic, I'm wondering how bzr-history-db interacts with foreign branches. [03:48] jbowtie: its a cache, it will read the whole history one time, and then incremental in the future [03:49] but some like bzr-git don't really like incremental for some things. Mostly require you to convert first [03:49] Damn...all attemps are horribly slow on larger repositories, like bzr itself. [03:50] dotted_revno was the fastest. Too bad there isn't some quick way to get from dotted to merged when there are changes off mainline. [03:50] Maybe that's where bzr-history-db comes in. [03:50] jeremyw: bzr-history-db [03:50] :) [03:50] I'm just wondering if I could use it to speed up some of the bzr-tfs operations, particularly those that require mapping back and forth between repositories. [03:50] Basically, bzr stores a map from child => parent, and you need parent => children [03:50] so you need a new index [03:51] Trust me, I'm hearing what you're saying. I just wish I understood enough to avoid it. [03:51] jeremyw: the problem is the only way to invert child => parent is to walk all revisions, which is expensive [03:52] there are some bits you can make cheaper, but a lot of things are "it may also be a child but you just don't know it yet" [03:52] jeremyw: I'd be happy to chat with you to increase your knowledge :) [03:52] Oh, it's easy; first you stick the history in a relational database... [03:52] Are there any shortcuts that could be made if it was a hosted, no real changes being made to the branch itself, repository? [03:53] if you were to say do "branch.repository.revisions.get_known_graph_ancestry([(branch.last_revision,)])" you'd end up with a Graph object that can be traversed bidirectionally very quickly [03:53] with the pain that it has to always load the whole ancestry [03:53] fullermd: oh wait, that's already been done :) [03:53] jam1: sorry for not calling before [03:54] thumper: np [03:54] jam1: got dragged out to get a new vacuum cleaner [03:54] I have a problem with some stacked branches [03:54] That sucks :p [03:54] where one branch is stacked on another but they share no history [03:55] particularly when I go reconfigure --unstacked [03:57] ah poo [03:57] it is worse [03:58] lp:ubuntu/language-pack-gnome-yo is stacked on lp:ubuntu/lucid/language-pack-gnome-tg [03:58] rev 1 of lp:ubuntu/language-pack-gnome-yo is dated after rev 2 [03:58] and rev 2 is a merge of lp:ubuntu/lucid/language-pack-gnome-tg [03:59] trying to reconfigure lp:ubuntu/language-pack-gnome-yo unstacked fails [04:00] poolie: any idea ^^? [04:00] http://pastebin.ubuntu.com/502991/ is the error [04:03] hi everyone... I am wondering if anyone could give me a hand trying to get out debug data for: https://bugs.launchpad.net/bzr/+bug/485601 [04:03] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 5)" [Medium,Incomplete] [04:09] anyone know what the issue is here: [04:09] $ bzr branch lp:ubuntu/maverick/ssh [04:09] bzr: ERROR: Server sent an unexpected error: ('error', ' cannot have linked branches.">') [04:18] smoser: yes [04:19] smoser: poor error message mostly [04:20] smoser: ssh isn't a package name [04:20] smoser: try openssh [04:20] https://code.edge.launchpad.net/ubuntu/maverick/+source/openssh [04:21] pfft. [04:21] luser error [04:21] sorry. thanks. === jamesh_ is now known as jamesh [04:47] thumper: hi there [04:47] hi poolie [04:48] thumper: not immediately obvious to me [04:49] :( === jam1 is now known as jam === Ursinha-bbl is now known as Ursinha-afk [06:16] Anyone having issues with the bzr branch on launchpad? I get to 14440k and it stops, every time. [06:42] probably being stupid, but what's the equivalent to git am? (There are lots of ways to /export/ patches as emails, but no obvious way I can see to import them with dates/headers automatically) [06:50] Is there a way to use the bzr source tree as a bzr installation without installing? [06:51] My first thought was to symlink bzrlib into site-packages like I do with mercurial. [06:51] jeremyw: that should work [06:51] jeremyw: if you're going to do that, why not do the regular install step? [06:52] sladen: "bzr send" can generate bundles that you can "bzr pull" or "bzr merge" like a branch. [06:52] dash: Well, I'm trying to just use the bleeding edge so that when my app is done, I can just say that I support the newest version instead of having to stay up to date. [06:52] jelmer: I was running into trouble with it previously...I'll try again. [06:53] jeremyw: what sort of trouble? [06:53] Failing to load compiled libs that would halt branching lp:bzr. [06:54] Hard stop every time at the same point. [06:56] jeremyw: none of the compiled modules are required to run bzr [06:57] I know but until I did a real install "./setup.py install --home PATH", it would stop at the same place everytime. [06:57] I can't explain it but I've been troubled by it for 3 hours. Only when I tried the full install on a whim did things work. [06:57] But that was after my machine crashed the first time because of it, losing about 3-4 hours of work. :-/ [06:57] My fault, I know... [07:14] I lost my work on making find_touching_revisions() 77% faster. Eff me. [07:16] That was bad math on my part. It's 3x faster. [07:26] jelmer: thanks. The "bundles" were coming from git, after git-bzr bzr-git, fast-export/fast-import all failed [07:26] jelmer: however, 'git format-patches -k' was working [07:28] sladen: hmm - I'd be interested in hearing why bzr-git didn't work [07:34] hi all ! [07:34] 'morning Vincent! [07:35] jelmer: welcome back in civilized TZ ;-) [07:37] vila: I don't think there is anything civilized about waking up at 7AM ;-) [07:37] * jelmer is still slightly jetlagged [07:40] hehe [07:50] hi there vila, jelmer [07:50] poolie: one word: http://pypi.python.org/pypi/bzr :) [08:00] hey all... [08:00] $ bzr push --remember lp:~haildb-core/ubuntu/maverick/haildb/trunk [08:00] This transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~haildb-core/ubuntu/maverick/haildb/trunk/. See 'bzr help working-trees' for more information. [08:01] um - I know that - why is it carping about that? [08:05] poolie: can you reproduce bug #651706 or is it sporadic ? [08:05] Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/651706 [08:05] mtaylor: good question [08:05] i wonder if it thinks that branch has a working tree for some reason [08:05] vila, i don't know yet, i've only tried once, will try again soon [08:06] poolie: yeah - it's weird. it doesn't recur, but I had it on one push yesterday too [08:07] mtaylor, poolie : Isn't it something that occur when a .bzr dir is left on the server in some corrupted state ? [08:07] like while a push is interrupted or aborted ? [08:08] vila: ah - that would make sense - I did interrupt a push earlier [08:08] mtaylor: IIRC the next push won't complain, but come back if they do [08:09] vila: they don't. just wanted to report in case that was something you guys didn't know about [08:09] mtaylor: thanks for that ! [08:10] mtaylor: really appreciated [08:10] anytime! [08:10] vila, do you think this issue with svn should block 2.2.1 into maverick? [08:11] poolie: the one involving people with 2.2.1 and 2.1.1 ? [08:12] Have we figured out why 2.2.0 is behaving differently to 2.2.1? [08:12] Since the bug has been fixed in 2.1.3... there is little we can do if people don't upgrade, so the question is what upgrade paths they can use. [08:13] poolie: so my answer to your initial question is: no, this shouldn't block 2.2.1 for maverick [08:14] poolie: i'm originator of the 2.2.0 => 2.2.1 svn email warning today if thats what you're discussing :) [08:14] peitschie: excellent ! [08:15] peitschie: so, about 2.1.1, what OS is this ? [08:15] vila: we're running windows boxes with clients at 2.1.1, 2.1.2 & 2.2.0... with a smart server (bzr+ssh) at 2.1.1 [08:16] vila: oh.. the server is debian lenny [08:16] vila: i'm working with server guys to get that updated to something more recent... potentially bzr 2.2.0... and all the devs will be jumping onto 2.2.1 tonight [08:17] peitschie: I'd kindly suggest upgrading your windows boxes to the same 2.2.1...you're typing and acting faster than I type ;) [08:17] vila: if it's related to https://bugs.launchpad.net/bzr/+bug/485601 or https://bugs.launchpad.net/bzr/+bug/522637 like we suspect, in "theory", reconciling the shared repo and getting all the devs to start clean again should fix it [08:17] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 5)" [Medium,Incomplete] [08:17] peitschie: that's the idea yes [08:17] :) [08:18] peitschie: I think spiv would have the definite answer here about which versions are compatible with which, but in this particular case, trying to ensure compatibility between all micro versions.... [08:18] sounds like a nightmare and a waste of time [08:18] vila: are there likely to be issues running 2.2.0 on the server and 2.2.1 on the clients? [08:19] vila: I agree... it's one of those things I should have been more attenative to at the time... unfortunateyl we are just getting people creeping into bzr at the moment. I was being a little too cautious about changing things that hadn't yet broken :) [08:19] AIUI the problem was ghosts coming from bzr-svn no ? [08:20] so if you're now using bzr only they shouldn't come back haunting you [08:20] that'd be nice... we've had a few discussions about that, but unfortunately we have several dev tools (TeamCity, JIRA to name a few) that don't play terribly well with bzr at this point [08:21] the discussions continue, but this project is a little late already and quite entrenched so I suspect moving to pure bzr may end up impractical... I am trying though :) [08:21] ha, so you're still using bzr-svn somewhere ? [08:22] svn is our main commit point actually :S [08:22] in this case, I think only the clients matter anyway [08:22] to stop the haunting i have a rather strange design setup here [08:22] basically, devs commit to a shared repository on a network server, and then merge these changes into svntrunk [08:22] so locally most devs have ghosts all over the place [08:23] but if you upgrade the server, stick to our stable releases, that would avoid this kind of weird interactions [08:23] but the shared repo on the server at least has a complete view [08:23] vila: is the stable the 2.1.X series? [08:23] 2.2 [08:23] so 2.2.1 [08:23] ahh... awesome [08:24] I'm getting the server upgraded to 2.2.0 I believe... all clients will be 2.2.X series on fear of me distributing their parts for them :P [08:25] poolie: I can reproduce #651706 with 2.2.*0* [08:26] vila: would there be a significant downside to using 2.2.0 rather than 2.2.1? [08:26] peitschie: well, the bug we're talking about has been fixed in 2.2.1 no ? :D [08:27] vila: assuming we both mean https://bugs.launchpad.net/bzr/+bug/522637 :)... it was in 2.2.0 [08:27] Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 66)" [Low,Triaged] [08:27] ha no ! 2.2.0 already for #522637 [08:27] peitschie: could type a little bit slower to stop making me look like a monkey ? :D [08:28] joke aside, also check the bzr-svn plugin version, but for windows 2.2.1 should be good too [08:29] hmm, jelmer wasn't able to reproduce it so I think this means this was a bzr only issue [08:30] vila, that's actually really good you can reproduce it there [08:30] that was going to be my next step [08:30] so we can just say that on 636930 [08:31] vila: heheh... if I type faster doesnt that make me *more* of the code monkey? [08:31] peitschie: :D [08:32] vila: so basically, 2.2.0 should have this fix, and as far as your aware, 2.2.0 in the server should be sufficient (i won't sue you if your wrong btw... just looking for a gut-feeling/opinion :) ) [08:32] peitschie: exactly [08:33] vila: much awesomeness! thanks :) [08:33] peitschie: thanks for helping sorting this out quickly ;) [08:34] vila: is it worth me sending around another email with the summary of our discussion here? i.e., the difficulty was caused by inconsistent clients... therefore probably a good idea to either bulk upgrade, or tread carefully? [08:34] peitschie: that would be awesome [08:35] maxb: this may sounds strange but can a ppa be used for lenny or any debian if we provide the right packages ? [08:36] vila: no, this isn't possible [08:36] darn [08:37] jelmer: can you elaborate a bit ? A on-line explanation would be enough :) [08:38] vila: https://bugs.edge.launchpad.net/soyuz/+bug/188564 [08:38] Launchpad bug 188564 in Soyuz "Build also packages for Debian in PPA's (affected: 38, heat: 274)" [Low,Triaged] [08:40] vila: it might be more useful to get newer bzr releases into the Debian backports though, as that would be the first place where debian stable users look [08:40] * vila reading the bug comments [08:41] Ha, right, build infra [08:43] ok, so this is a WIP [08:47] mgz: FYI, I'm going to revert from py27 on the babune's maverick slave [08:52] vila: oh... the bug (#522637) is fixed in the 2.2.0 series... but the 2.2.1 release... so it hasta be 2.2.1 I guess [08:54] vila: Well, I suggested that peitschie use the hardy packages on lenny. As I said in the email, it's a hacky kludge, but in the specific instance of the bzr package for hardy onto lenny, it seems to work [08:55] It's absolutely not something to recommend as a general procedure, though [08:56] max, peitschie : sounds like the cheapest alternative for the server admins no [08:56] ? [08:56] jelmer: Question for you - how would you feel about uploaded 2.2.1 to sid, as a feeder for backports? [08:56] sounds like our only option atm really [08:56] vila: cheapest alternative? It's an option which peitschie can use *right* now, if that's what you mean [08:57] max: are there likely to be issues updating to the official backport when that eventually makes it out? [08:57] i'm assuming no.. but it doesn't hurt to ask :) [08:57] peitschie: Well, you do have other options: you could install from source, or rebuild the packaged source on debian yourself :-) [08:57] upgrading... let me remind myself of backports versioning scheme..... [08:57] maxb: i'm assuming that isn't going to be much prettier from the ppa...? [08:58] worse comes to worse we can purge bzr and install the official one when it hits [08:58] peitschie: you're right and lp is wrong: http://paste.ubuntu.com/503077/ [08:59] vila: should I update the bug report at all or just leave things? [08:59] peitschie: ok, so: 1) I expect what hits backports will be an indentical source package, just rebadged with the appropriate version number, so the only difference will be the build environment, and 2) yes the version number should be greater, so apt should just do the right thing [08:59] peitschie: you mean marking it as fix released in 2.2.1 ? Refresh the page :) [09:00] vila: :O... you guys are so speedy here! [09:00] maxb: that sounds good. thanks for checking that for me :) [09:00] * vila try to type faster :) [09:01] maxb: That doesn't work, backports have to be created from packages in testing and we won't be able to do a new upload that will end up in testing. [09:02] maxb: see the backports FAQ [09:02] poolie: can't reproduce bug #651706 on maverick 8-) [09:02] Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,In progress] https://launchpad.net/bugs/651706 [09:02] * vila tries harder [09:02] vila, i thought you just said you could? [09:02] or you can't reproduce it in a source tree? [09:03] I can reproduce with 2.2.0 system install, I can't with 2.2.1 from sources, but both mention leaking tests... [09:04] ... which I could very easily be persuaded that they are the cause of the transient failure [09:05] I'll try again with the stable ppa installed [09:05] jelmer: There was mention of it being occasionally acceptable to backport from unstable, I was hoping we could convince people that it was a sensible thing to do [09:06] maxb: afaik that only applies to things like security uploads === spike_ is now known as spikeWRK [09:12] poolie: wow, reproduced when running from the ppa version 8-/ That would make the debugging interesting... [09:13] hmm, could that be the test ssl certs not installed correctly... [09:15] i suspect it's something like that [09:16] maybe ownership or permissions? [09:16] or not shipped at all? [09:16] shipped, permissions look correct [09:19] strace time? [09:19] good idea [09:21] maxb: still here? [09:21] hi [09:31] poolie: bingo, we don't install ca.crt... [09:34] poolie: the fix is a one-liner in setup.py, should I target 2.0 or 2.2 ? [09:35] 2.2, i would say [09:35] but, hang on, do we really need to install a certificate? [09:35] this is a made-up one just for running the tests? [09:36] for the test sever yes [09:37] let's make sure it's not installed anywhere someone could mistake it for a real one [09:37] We had a fix long ago for this, I don't understand why this file wasn't spotted earlier, I guess the fix itself wasn't properly tested or... unexpectedly succeeded :) [09:38] look at /usr/lib/python2.5/dist-packages/bzrlib/tests/ssl_certs [09:38] there is a create_ssls.py there that should make it clear enough [09:39] and the script defines... a rather fictional locality and country code, etc [09:40] even if someone pick it up I strongly doubt it will be able to certify anything dangerous [09:55] poolie: https://code.edge.launchpad.net/~vila/bzr/651706-test-ca-crt/+merge/37109 [09:55] go lp go, update this diff ;) [09:59] GaryvdM: it seems we should made release of qbzr 0.20b1 for bzr 2.3b1, shouldn't we? [10:00] bialix: as long as you release 0.20 for 2.3.0 [10:00] bialix: I don't think you strictly *need* to release it, but that will be good [10:01] vila: qbzr has switched to the 1 major release per 1 major bzr release [10:01]