=== slank is now known as slank_away [07:56] hey mmrazik, do you have some logs about the issues we are currently having in corrupted checkouts? [07:56] (knowing that we just started fresh from trunk) [07:57] pretty much just the output of "bzr branch lp:~mrazik/libdbusmenu/xvfb-run-a" [07:57] let me pastebing that [07:57] err.. sorry.. output of " bzr checkout lp:~mrazik/libdbusmenu/xvfb-run-a [07:57] " [07:57] bzr branch works fine [07:58] http://pastebin.ubuntu.com/1512096/ [07:58] vila: jelmer: hey! would you have any idea of what can be the cause of this? ^ [07:58] the steps to reproduce are: 1. bzr branch lp:libdbusmenu [07:58] 2. make your changes + commit [07:59] 3. bzr push [07:59] 4. bzr checkout (from the same location where you just pushed) [08:00] mmrazik: easier, bzr checkout lp:libdbusmenu has the same issue [08:00] so something not correct in the launchpad repo? [08:03] didrocks, mmrazik : weird, when tried locally I got an additional hint in the error message: "Run 'bzr reconcile --canonicalize-chks' on the affected repository." [08:04] which doesn't appear in your paste... [08:04] vila: I tried that on my xvfb-run-a repo (locally) and then pushed to xvfb-run-a2 but it didn't help [08:04] vila: I don't see this hint as well [08:05] mmrazik: well, if the lp repo has the issue, fixing your local one won't help (and you may be additionally tricked if the offended repo is stacked on on lp) [08:06] vila: so bzr reconcile --canonicalize-chks :parent? [08:07] hmm, "bzr info -v lp:libdbusmenu" erroring is suspicious, is the lp branch properly configured ? [08:07] ah interesting, indeed [08:07] bzr config -d lp:libdbusmenu [08:07] branch: [08:07] stacked_on_location = /+branch-id/590782 [08:07] parent_location = ../../../+branch/dbusmenu/ [08:08] the project was renamed [08:08] that parent_location is really weird... [08:08] from dbusmenu to libdbusmenu [08:08] and I guess when renaming a project, trunk branch naming follows but not the configuration [08:08] but shouldn't really matter in fact [08:08] vila: there should be no parent location for lp:libdbusmenu, it's the real trunk [08:09] I start to recall an issue with the rename. Trying to recall what additional bzr command we were running [08:09] yeah, I don't think it's ever used [08:09] anyway, can you run reconcile on that lp branch ? [08:10] if :parent doesn't work, use the lp url instead [08:10] will do [08:12] vila: bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/libdbusmenu/.bzr/) cannot canonicalize CHKs. [08:13] btw. what we have done in CPH had something to do with unstacking but I can't figure out the exact command [08:14] CPH ? [08:14] vila: copenhagen [08:14] I believe we did the renaming there [08:15] but then checkout of the trunk didn't work due to some stacking errors [08:15] and somebody (I believe from the launchpad team) helped us with that [08:15] right, I was about to say that lp guys may have better access... [08:16] that error seems really vague.. [08:16] bzr reconfigure --unstacked [08:16] ? [08:16] is there no more descriptive error? [08:16] didrocks: yep... thats the one we were using [08:16] mmrazik: maybe try this on lp:libdbusmenu ? [08:16] didrocks: thats what we did [08:17] mgrandi: I guess that's what bzr is giving :/ [08:17] is there a stack trace? [08:17] either in the output or in bzrlog [08:17] mgrandi: http://pastebin.ubuntu.com/1512096/ [08:18] i meant for one that says "cannot canonicalize chks" [08:18] so lp:libdbusmenu is stacked on lp:libdbusmenu/12.10 indeed so the error may be there for all we know [08:19] bah and that one is stacked on lp:dbusmenu/0.6 ... [08:19] and finally stacked on 0.5 [08:20] russian dolls, bzr style [08:20] well having a stack trace [08:20] for that 'cannot canonicalize' would help... [08:20] btw. I just did the reconfigure and I can checkout lp:libdbusmenu now [08:20] but bzr info -v still gives errors [08:20] mgrandi: grep shows only one call site [08:21] bzr checkout lp:libdbusmenu/12.10 succeeds [08:21] mmrazik: confirms about checkouting working now [08:22] having trunk stacked on another branch... is kind of wrong, you generally want trunk's repo to contain most of the history [08:22] vila: I think that the indicator team is normally doing at the end of a release, something like: [08:23] bzr branch lp:libdbusmenu [08:23] bzr push lp:~…/libdbusmenu/13.10 [08:23] and then, set lp:libdbusmenu to …/libdbusmenu/13.10 [08:23] so that's why we have branches stacked an previous releases I guess [08:24] I probably miss why you need such a workflow... [08:24] vila: I don't know why they are doing that, but it seems to be there one :) [08:25] but that's not the best way to use stacked branches [08:25] I think they don't know (and arguagly, they shouldn't have to know) about stacking [08:25] arguably* [08:25] anyway, you're unblocked right ? [08:25] vila, didrocks: yes [08:26] vila: I think, yeah :) [08:26] ok, cool [08:26] thanks vila, mgrandi! [08:26] I'll try to have them changing their workflow :) [08:26] mmrazik: btw, it's part of the things we should write on a wiki, like process to create a new release [08:26] didrocks: sounds like a good idea [08:26] mmrazik: because the unity team is doing one way, the indicator team is doing another… [08:27] haha, not sure i did anything but ok [08:27] but that "canoot canonicalize" error is worth a bug report, it sounds like something really weird is going on there [08:28] vila: ok, we'll open one with those info, hoping that we can recreate it :) [08:28] mgrandi: well, you pointed out that the error message was weird and that's often the way to detect bugs ;) [08:28] yeah [08:28] why i try to always give as much info in error messages, vague stuff hurts to look at =( [08:29] almost worse then microsoft saying "error code 21124124XABB" [08:31] here, the message is triggered by an attribute check on the repo object, so probably something jelmer did for foreign repos except we are dealing with a bzr repo here... so I'm a bit lost [08:31] i noticed that it was saying osmething about sha1:blahblah [08:31] those are for git right? [08:32] vila: it's not necessarily something to do with foreign repos [08:32] vila: just that we happened to have a known bug in bzr-svn that was related to this [08:33] jelmer: that was just a feeling ;) A bzr repo object missing a bzr method... [08:33] some borked inheritance path ? [08:38] vila: possibly === yofel_ is now known as yofel === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik === slank_away is now known as slank === mmrazik is now known as mmrazik|otp [16:51] Can somebody push https://code.launchpad.net/~xnox/bzr-dbus/pygi/+merge/137173 ? === deryck is now known as deryck[lunch] [17:47] xnox: done [17:48] mgz: thanks === deryck[lunch] is now known as deryck === slank is now known as slank_away === slank_away is now known as slank === gthorslund is now known as gthorslund__ === gthorslund__ is now known as gthorslund === gthorslund___ is now known as gthorslund_