[00:10] kkrev, url? [00:11] do you mean on the server? [00:16] right on the server. I'm asuming shared repositories don't do anything with simlinks to save space or anything like that. [00:28] kkrev, almost all the data will be in the repository directory [00:28] with just one copy [00:28] the per-branch directories will be very small [01:27] jelmer: Concerning the removal of the bzrlib.util.configobj.configobj from the Debian package - I think we should import the system configobj to that name, as a compatibility measure. It's not unreasonable for people to consider it part of bzrlib's api [02:04] maxb, that sounds reasonable [03:15] Can anyone tell of success stories with bzr-git bridge? I can only get it to work over raw git: protocols, and I'm not sure if it's me or bzr-git [03:16] GHellings: what other protocols have you tried? [03:17] I have tried http: and git+ssh: [03:17] i know there have been bugs accessing branches from github over http [03:17] I've been accessing gitorious over http unsuccessfully - same repo over git: is fine. [03:17] Just tried a different, private repo over git+ssh: and it failed with the same error [03:21] I'd go in to take a look, but I'd be a bull in a China shop, as I know nothing about programming bzr or its plugins [03:22] which error? [03:22] bzr: ERROR: exceptions.AttributeError: 'RemoteGitRepository' object has no attribute '_git' [03:23] looks like https://bugs.launchpad.net/bugs/706990 which is claimed to be fixed in trunk [03:24] Ah, I see the fix is since my comment on there. It had also claimed fixed in 0.5.2 of the release on a different report. I'll try trunk and see how it works out. [03:25] great [03:36] poolie, looks like it's working now, at least for git-import. Thanks. :) [04:23] GHellings, great [05:52] spiv: Hi. [05:53] that thunks down to revisions.get_known_graph_ancestry [05:54] Yeah. [05:54] first thing we could do is try without the pyrex. [05:55] are we looking at .texts .chk_bytes or what here? [05:55] i.e. where would we expect to find a revision? [05:55] .revisions I assume? [05:55] .revisions, isn't it? [05:55] Yeah. [05:56] wgrant: good afternoon [05:57] spiv: Bug #715000 is giving Launchpad some issues. [05:57] Launchpad bug 715000 in Bazaar "Stacking is not fully transitive" [Undecided,New] https://launchpad.net/bugs/715000 [05:57] In particular, 3/4 of the new wheezy branches crash half way through scanning. [05:57] by some, he means brick-face. [05:57] Brick-face? [05:58] 'lots of pain' [05:58] Ah, yes. [05:59] lifeless: still happens without pyrex, FWIW. [06:00] ok, thats good to know [06:00] wgrant: hmm [06:00] http://paste.ubuntu.com/564235/ [06:00] groupcompress.py line 1315 certainly looks like it should DTRT [06:02] lifeless, that's a comment here, which line is it? [06:03] parent_map, missing_keys = self._index.find_ancestry(keys) [06:03] for fallback in self._fallback_vfs: [06:03] if not missing_keys: [06:03] right, it would do the right thing [06:04] if self._fallback_vfs was correctly populated [06:04] so thats a possibility; is it not populated properly? [06:04] my current hunch is that it adds natty as a fallback for maverick, and maverick as a fallback for lucid, when it should add both to lucid [06:04] vfs is 'versioned files' here. [06:05] so lucid -> maverick -> natty [06:05] ? [06:05] james_w: that chain should work [06:05] right, that's the stacking chain [06:05] it might not be optimal, but it should work. [06:05] oh [06:05] I think I see a bug [06:05] however, .revisions._fallback_vfs is [.revisions] [06:06] james_w: print the _fallback_vfs in maverick_repo.revisions [06:08] [] [06:08] presumably natty_repo.revisions [06:08] yes [06:09] and the code you pasted doesn't recurse [06:09] yes [06:09] so does GroupCompressVersionedFiles._index.find_ancestry recurse() [06:09] ? [06:09] no [06:09] then there is the bug [06:10] it shouldn't recurse either [06:10] the indices are below that layer [06:10] I would have assumed that most of this code didn't recurse at all call-sites, and just collected all the fallbacks when opening in to _fallback_vfs [06:10] we need to be able to figure out whats *in this repo* vs *accessible via the api* [06:10] each repo is mutable [06:10] so open is the wrong time [06:11] flattening at execution is probably appropriate [06:11] that or recursing via the public api [06:13] ok, I'll dump what I know in the bug and someone can take on the fix [06:13] What should we do for now? [06:13] Stop the importer? [06:16] probably a good idea [06:16] no need to add more and more branches to clean up later [06:17] So this is breaking the package importer? [06:17] The importer works fine. [06:17] But LP breaks when it tries to scan the branch. [06:18] Oh, ok. [06:18] it may break the importer at some later time though [06:18] Yeah. [06:18] so we should upgrade bzr there too when we have a fix [06:19] *nod* [06:19] I'll upgrade the bug's importance [06:19] LP will probably cope for now, but we may need to knock out the problematic branches if it can't keep up. [06:19] Since they stay in the scan queue. [06:23] james_w: Have you turned off the importer? [06:27] spiv: loom wants to user your newer api (re tag fetching) [06:27] spiv: it has many tips to snarf [06:30] wgrant, nope [06:30] lifeless: yeah. [06:35] hi all [06:45] spiv, are you, are you working on that? if you want to talk i'm here [06:45] GaryvdM, hi [06:45] Hi poolie [06:46] poolie: I'm going to look at mysql cases today [06:46] hey [06:46] that's a good idea [07:01] GaryvdM, hi, did you see my pm? [07:01] spiv, hi, are you still here? [07:01] poolie: not yet, just got tests passing for the 'reconfigure --unstacked should copied tagged revs' though [07:03] I'm trying to resist the temptation to start on new things while I still have other things half-done. [07:05] good for you [07:05] this one probably is critical so i'll look at it [07:06] wallyworld_: ^ btw - you'll want to hand out an rc stamp for including the fix to this in the rollout [07:11] lifeless: you saying that the rollout will require a new version of bzr? [07:11] i'm surprised we haven't seen complaints about similar things from users, or failures in lp, before [07:11] perhaps most people just branch and that doesn't hit it [07:11] poolie: we may have but not commonly enough to diagnose [07:12] for > 1 year the code team has been focused on applications not the core [07:12] (e.g. recipes) [07:12] wallyworld_: we have an Incident (I assume wgrant is writing it up) [07:12] wallyworld_: the solution requires a bzr code change; this has been latent forever. [07:13] poolie: I think more than one level of stacking hasn't been very common in the past [07:14] lifeless: ok. we sure are going down to the wire though with last minute changes. right atm the anticipated rollout rev is in builtbot on it's way to qastaging [07:15] wallyworld_: if we bless an earlier rev, thats fine. [07:15] is this change something we could do with a no downtime rollout post 11.02 release? [07:15] * spiv logs off for the day. [07:15] wallyworld_: we can, but what we release should be all the revs that are qa'd at the time - like if you bless N, and 5 more revs are qad by deploy time, we should deploy N+5 [07:16] wallyworld_: the point of the rc stamp is to let this into pqm as soon as this patch is ready rather than after you reopen pqm. [07:17] It's not a DB change, so it doesn't really affect anything. [07:17] exactly [07:17] If it's in stable by the time we need to deploy, we can deploy it. [07:17] and it will get landed via ec2test :) [07:17] If not, we deploy a few minutes later :) [07:18] lifeless: ok. it means though that pqm will need to stay in rc mode for a bit longer until this latest change is qaed [07:18] wallyworld_: why? [07:18] wallyworld_: it only needs to stay in rc mode until the the db rev is deployable [07:19] i thought pqm stayed in rc mode until the rev to rollout was chosen? [07:19] wallyworld_: I think the process hasn't been fully updated; the critical section is getting a db-change rev thats deployable (which may require more revs than that) [07:19] Once we are OK to release we are OK to open. [07:20] If we can add more stuff onto the release, all the better. [07:20] since if there's a qa issue and people have landed subsequent revs, then that may be an issue? [07:20] the hysteria around what rev to deploy during the downtime was back when we did a months worth of qa at once [07:20] Since if we don't, I will just request a nodowntime deploy like an hour after the release :) [07:20] wallyworld_: but *once* we have the db rev ok to deploy, thats not going to be changes by more landings is it ? [07:22] no. but the db rev is merged into devel and it's the devel rev that is qa'ed for rollout, no? [07:22] yes thats correct [07:22] and consistent with what I'm saying [07:23] * lifeless tries again [07:23] so qa is a pipeline [07:23] and the db deploy is a fixed event [07:23] to decrease the chance of foreign revisions interfering with fixes to the db revision === Ursinha is now known as Ursinha-away [07:23] once we merge db-* to devel [07:23] we enter a critical section [07:24] that critical section is relaxed once the devel deployment report shows that the db-* merge is deployable [07:24] which might be the merge itself [07:24] or require the merge plus a couple of fixup revisions [07:24] at that point, if we open pqm, there is *nothing* a new landing can do to break the point we had qaed up to. [07:25] which is why we now open pqm as soon as we have a candidate we *can* deploy. [07:25] We we *go* to deploy, the pipeline may have advanced. [07:26] we should deploy the highest deployable rev (again, what the report says is ok) [07:26] the interaction with this bzr patch is that its sufficiently important we'd be willing to let it land during that critical section [07:26] [not that the patch is ready] [07:26] however being willing to land it during that section does not imply that the section should be extended [07:29] i guess that my point - if a new landing breaks devel and we need to do a test fix for a rev prior due to a qa issue with a prior rev, then it's messy and better that merges to devel are frozen until after the rollout rev is chosen. i guess i've always worked that way in the past - freeze all new work while the rollout rev is qa'ed and only land test fixes [07:29] but that was then and this is now [07:29] so what I'm saying is still consistent with that [07:30] once you have *a* rollout rev, you are safe. [07:30] *and* [07:30] you can choose a new rollout rev at T-60. [07:30] based on the deploy report. [07:30] that last bit (choosing at T-60) i think is where we differ [07:31] ok; why? [07:31] i guess i've been more conservative in the past - lock down the rollout rev and qa and consider all change bad and needing justification so any changes not related to test fix for defined features in the release are verboten [07:32] until after rollout [07:34] what happens if we choose rev 12338 (the one going to qastaging now) and someone lands a bad change? and we find at the last minute a fix is needed for rev 12336? in my scenario, we would just land the fix to 12336 without any hassle of dealing with a later rev checked in on top [07:34] so [07:34] the critical section is intended to let us *actually qa* 12336 - which has worked this month, for instance ;) [07:34] but taking your scenario [07:35] we'd just rollback 12339 at the same time as landing whatever fix (assuming 12339 also qa failed) [07:36] but doing rollback is an extra step and any extra steps potentially introduce defects/issues [07:36] the way we reduce the risk of the db deployment is deploying all we can before it - like wgrants nodowntime yesterdayish [07:36] wallyworld_: in theory yes, in practice its trivial do to a merge -r . -1..-2 [07:36] wallyworld_: and be confident its rolling it back to a previously known ok state. [07:36] an extra step that would not be required if landings were verboten until the release rev were fully qaed [07:36] thats true [07:36] but i see your point tooo [07:37] but blocking landings is hugely expensive [07:38] we land 6 branches a day on avg [07:38] yes, so ones weighs up the pros and cons and perhaps your way is the better approach in terms of team velocity while still managing the risk [07:38] 10 per [mon-fri] [07:38] wallyworld_: yes, its a risk assessment problem. [07:39] wallyworld_: I generally prefer a risk recovery option rather than risk elimination [07:39] so now that today we finally have the db-devel rev sorted (pending a final qa) we can open up pqm again once rev 12338 lands on qastaging [07:39] wallyworld_: particularly with low-occurence risks [07:39] *once* 12338 is qa'd [07:39] but yes. [07:39] yes, i see your point. i think it comes down a lot to organisational culture [07:39] its been a bad cycle [07:40] yeah, i've been thrown in the snake pit as rm for sure :-) [07:40] good on you for doing it though [07:41] it's been a learning experience and i'm glad i did it actually [07:42] part of the issue was last week where i'm told issues with pqm/ec2/buildbot delayed a db-devel landing, which pushed everything back [07:42] so we really need to deal with those root cause issues [07:42] if they indeed are real issues [07:44] yes, they did and the pqm swallowing errors bit should be fixed now [07:44] hi all [07:48] hi vila [07:48] poolie: see my pm ? [08:01] vila, https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer/Operational etc [08:11] vila, i'll need to go at some point so if you get a chance please persist on 715000 [08:13] poolie: don't hold your breath, I'm already working on critical stuff and if I had yet another interrupted task on top of my stack... [08:13] s/had/add/ [08:13] damn tyops [08:14] ah fair enough [08:14] is https://devpad.canonical.com/~mbp/kanban/vila-kanban.html accurate? [08:14] at least in the middle columns? [08:17] the in progress yes, the needs review is... not important [08:18] and yes, my current branch should address both the in progress ones (and more as I discover them ;-/) [08:30] Hi [08:30] My TortoiseBzr ist Polish(?), how do I change that back again? [08:32] nil1, not sure, perhaps setting LANG in your environment then running it? [08:32] hi sidnei [08:33] hi poolie! [08:34] poolie: no that didn't help [08:35] I opened the command line, "set LANG=C", killed explorer.exe and restartet it on the command line [08:35] err, LANG=de [08:35] Please use bzr-2.3-setup.exe [08:36] * nil1 nods [08:37] https://bugs.launchpad.net/tortoisebzr/+bug/663258 [08:37] It is fixed but have not shipped with bzr-2.2.x [08:41] okay, thanks [08:41] * nil1 reboots [08:42] yay, i might have fixed 715000 [08:43] * vila hugs poolie [08:44] in some ways this is a dangerous fix [08:44] so it might be better to do it in 2.3 and move lp to that [08:45] or 2.4 even [08:45] not very dangerous, but not utterly obvious not to change something else [08:47] there are other good reasons to deploy 2.4 on lp (controversial) but I think it's the right path for the coming months [08:56] poolie: you're targeting 2.2 ?1/!! [09:01] vila, i did it based of 2.2 to keep our options open [09:01] haaa, pfew, you scared me [09:01] yeah, good point [09:02] and good thing the bzr/2.2 branch was already opened for bugfixes [09:02] is it even proposed yet? [09:02] or did you just click through? [09:03] hehe, I saw the bug email and fired 'bzr-review lp:~mbp....' ;) [09:06] ok [09:07] if you can review it that would be nice [09:07] maybe john should too [09:08] ok, i think i should stop [09:08] i'm running the whole test suite to see if this affected anything else [09:14] poolie: yup, you (I?) should probably do that after merging up, spiv modified fetch and there may be fallouts there [09:22] i think it's important we check for similar problems [09:22] and ideally match them up to bugs [09:22] but i'm running out of steam [09:25] poolie: quick review sent === Ursinha-away is now known as Ursinha [12:09] jelmer: about review: :D and thanks [12:09] you're welcome, glad I can return the favor(s) :) [12:28] jelmer: hmm, what needs to be done to get 2.3.0 on natty ? === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila) [12:39] vila: There's already a sync request in progress [12:39] * jelmer looks for the bug # [12:40] jelmer: good enough ! [12:40] thanks ! [12:40] bug 713038 [12:40] Launchpad bug 713038 in bzr (Ubuntu) "Sync bzr 2.3.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/713038 [12:41] rhaaa ! I read the related mails ! I knew ! What else will I forget next ? :D [12:41] (: [12:48] jelmer: oh, hi. I think we should put back bzrlib.util.configobj and .elementtree in the debian package, as imports of the system versions. Does that sound sensible to you, or did you explicitly choose not to? [12:55] maxb: hmm, that's a good question [12:56] maxb: on the one hand I think we should just have everything do the right thing and patch it to use configobj [12:56] on the other hand, pragmatism is useful too [12:57] I am mainly working on the basis that it's something included in bzrlib.*, so it's kind-of part of the bzrlib api [12:57] maxb: the configobj from the system is a different version and has slightly different semantics, etc [12:57] The situation is further confused by bzrlib's in-tree configobj being slightly modified [12:57] jelmer: just add "sys.modules['bzrlib.util.configobj'] = __import__('configobj')" to bzrlib/__init__.py ;) [12:58] spiv: Don't be evil :-) [12:58] * spiv wanders off to bed before he can do any real damage [13:01] Direct users of bzrlib.util.configobj that I can find are fastimport gtk loggerhead and qbzr [13:02] maxb: evil plugins [13:02] who says that bzrlib.util.* is off limits to plugins? [13:03] bzr-explorer conditionally uses bzrlib.util.elementtree on Python 2.4 [13:03] nobody ;) But I'm curious about what they need there and why bzrlib.config is not enough [13:04] maxb: some are already patched to support using the system configobj [13:04] indeed they are. [13:05] So, I guess the real question that needs answering is "Is bzrlib.util.* part of the API?" [13:05] maxb: yes, except for configobj :-D [13:05] maxb: seriously: yes [13:06] bzr mv bzrlib/util bzrlib/__compat__ :-) [13:06] but we should file a bug about forbidding it or provide alternatives I think (not sure and not sure I should think about that with a flu :-/) [13:07] at least the gtk case I'm looking at shouldn't use configobj [13:11] * vila files bug #715143 and resumes [13:11] Launchpad bug 715143 in Bazaar GTK+ Frontends "annotate.config should use bzrlib.config not bzrlib.util.configobj" [Medium,Confirmed] https://launchpad.net/bugs/715143 [13:20] ditto for fastimport and qbzr. Its less clear for loggerhead but probably true too [13:21] I agree. qbzr should not be using it. I used it because at the time, I did not know better. [13:23] yeah, I'm not throwing stones, bzrlib.config is still too hard to reuse IMHO [13:24] This was a gentle "evil plugins" :D === oubiwann is now known as oubiwann_ [14:41] vila: thanks for the review [14:41] hehe, I'm PP ! [14:41] vila: get_all() is different from items() in that it returns just the format objects, it doesn't return tuples with keys and values [14:41] did you mean values() rather than items() perhaps? [14:41] yeah [14:42] err, you're even more evil than I thougth then :) [14:42] use items and throw the keys :) [14:43] anyway, you got the point right ? [14:43] vila: in that case there's a slight disconnect though, as the extra formats don't have keys [14:43] so they would appear in values() but not in iteritems() or items() [14:43] haaa [14:44] hmm, key=None won't work either I suspect [14:44] vila: yeah, as most callers won't care about the non-metadir formats [14:44] I want a value that is less than None, guido ? [14:44] :) [14:45] vila: I think a separate method, different from values() makes sense here.. perhaps it just needs a better docstring? [14:45] jelmer: Is it really necessary that they don't have key ? [14:45] what is the key used for ? Can't that be an attribute instead ? [14:45] vila: even if they had a key, we would try to use them in cases where we couldn't [14:46] jelmer: most of the refactorings you've done in this area have been somehow to transform hard-coded references to formats into feature attributes on formats [14:47] I think this is really nice and The Right Thing [14:47] Can't the same pattern apply here ? [14:48] Since you're introducing registries, it would be nice it this was the case and that all formats can be properly registered and only from there diverge in what features they provide [14:48] vila: the interface here (having a format string) is already something these formats don't really have [14:49] vila: so I'm reluctant to expose them in the registry everywhere when they can't really be used as such [14:49] :-/ [14:49] Be bold ! [14:49] heh [14:50] Nobody is using this registry so far no ? Well, not the new one [14:50] vila: the class not, but the registry itself is used by lots of things [14:52] dev values(with_obsolete_stuff_yes_I_know=False) ? :-/ guido ? [14:52] bah [14:52] vila: that works, but that's why I'd rather add a separate method (probably with a more clearer docstring than I had earlier) [14:53] get_all = lambda self: self.values() + self.extra() [14:53] jelmer: yeah, will do, and clearly identify who is using it, sounds like a good case for a leading '_' too [14:53] vila: there's only one user of that method at the moment - bt.per_repository [14:55] good [14:59] vila: so improve the get_all docstring and rename remove -> unregister? [14:59] s/get_all/_get_whatever/ [15:00] and unregister yes, [15:00] ah, ok [15:00] another dech-debt is why Registry implements remove instead of unregister... [15:01] jelmer: these are all mostly suggestions, I'm open to discussion ;) [15:01] vila: that's why I used remove() as well, since Registry is the base class [15:03] yeah, I was *really* surprised to find it there, most of the registries uses I've seen have some sort of unregister and unregister really is more natural to my eyes [15:22] * jelmer is tempted to fix some registry tech debt [15:26] * vila pushes jelmer still hearing poolie saying the same this morning [15:37] jelmer: now I'm a bit lost... id I miss the extra-repo-formats mp earlier ? Or is it a new one ? [15:37] meh already 55 mins old >-/ [15:37] vila: it's a new one, on top of the one we just discussed [15:38] ah, argh.. it doesn't have the prerequisite bit set [15:38] but it still uses remove, did you postpone that ? [15:38] vila: no, this branch was submitted before our discussion [15:38] haa... pfew [15:38] https://code.launchpad.net/~jelmer/bzr/extra-repo-formats/+merge/48932 [15:40] (waiting for lp to refresh) it uses get_all + _get_extra, how about _get_all (not sure _get_extras is really needed unless you already know better) [15:41] jelmer: right, so my question still stand, you keep using remove or you plan to rename it later ? (There are arguments both ways...) [15:44] vila: I plan to rename it later, along with remove in registry itself [15:45] ok, good to go then [15:50] thanks [16:00] hello [16:00] hi Daiben [16:00] is there a turorial for a bazaar server [16:01] i'm messing with git for 3 days and it's still not working [16:01] so i'm moving to bazaar [16:01] Daiben: what kind of Bazaar server ? just plain anonymous readonly access over TCP/IP ? [16:01] read write [16:02] yes [16:02] and authentication [16:02] Daiben: any sftp/ssh enabled machine should be sufficient [16:02] but how does it work [16:03] Daiben: pretty well :) [16:03] Daiben: see http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/server.html [16:03] thanks [16:03] Daiben: as long as a user can connect with ssh and find a bzr in its path, there is nothing more to configure, the bzr client will send the right command [16:04] oke:) [16:04] i need to go home now i try tonight [16:04] ty [16:04] Daiben: you're welcome, come back for help if needed [16:09] jam: if you're around and k leave you some time, poolie ask for your help/feedback on bug #715000, there is already a mp with some leads [16:09] Launchpad bug 715000 in Bazaar "Stacking is not fully transitive" [Critical,In progress] https://launchpad.net/bugs/715000 [16:42] jelmer: the bzr daily builds failing are unrelated to the sync for 2.3.0 right ? [16:44] vila: that's a good question [16:44] * jelmer looks [16:44] vila: btw, 2.3.0 just hit natty [16:44] jelmer: fails with conflict in __init__ probably because the ~debian-bazaar/bzr.unstable needs to import trunk ? [16:45] \o/ [16:45] err, wait, whatdyoumean just hit ? rmadison doesn't see it yet [16:50] vila: jriddell just uploaded it, it's probably not been published yet [16:51] ha, ok, thanks for the timely feedback ;D [16:51] vila: ah, right.. I need to fix that conflict [16:54] vila, jelmer: the bzr dailys are failing because of a trivial conflict. We need to merge 2.3 to bzr.dev after any version bump on 2.3, to make the recipe merge cleanly [16:55] And we need to have a recipe-fixing-blitz [16:55] yeah - either that, or we need to merge it into the unstable branch [16:55] I've been looking at ways to make it easier to look after the recipes [16:55] but there aren't any web service API calls atm [16:56] oh, and we need to sync-request qbzr [16:57] maxb, jelmer: fwiw 2.3.1dev has been merged to bzr.dev today [16:58] maxb: which version of qbzr? [16:58] ooh [16:58] 0.20 [16:59] * maxb requests a recipe build [16:59] that's already in natty [16:59] ah. people are too efficient for me to keep up :-) [17:00] hehe, for once :D === beuno is now known as beuno-lunch [17:16] oh, boo [17:16] now application of patch 01_test_locale fails the recipe build [17:22] what is said patch? sounds interesting. [17:32] mgz: already merged in trunk ;) [17:33] mgz: you'll know if you weren't running such an old bzr ;-D [17:34] by the way, remind me my you're still on 2.1 ? What is missing in trunck to get you back there ? [17:34]