[00:00] there's no way of getting the parent rev or my user id in the text? [00:00] hg diff --git perhaps [00:02] ...seems not. ah well. [00:02] they'll just have to take it on trust that I wrote the test first and it failed, rather than having two seperate revisions [00:04] hi riddell, spiv, mgz, lifeless [00:20] gra, dealing with python-dev is such a pain. [00:22] I guess it's nice I got a response before I'd posted my patch, and that the fix was so obvious someone else landed the same thing right away. [00:52] mgz: thanks for getting that fixed in upstream! [01:47] spiv, robert asked if you had any outstanding work to do with the twisted haproxy availability stuff (mumble) [01:47] ithink it's just blocked on losas but is there anything else still with you? [01:48] Not that I can think of. [01:49] Oh, there's this near trivial, approved patch that still hasn't been landed: https://code.launchpad.net/~spiv/launchpad/haproxy-for-twisted-services/+merge/48427 :/ [02:16] i could try to land it [02:22] spiv, what should the commit message be? [02:22] just "fixes a cosmetic glitch in the text in the new web status page for codehosting SSH: it was always saying "Unavailable""? [02:25] ok i'm sending it [02:27] That sounds good. [02:27] Thanks! === yofel_ is now known as yofel [07:19] spiv: Hi. Is it time to roll back the UDD append revisions only change, or are you still hopeful of fixing shortly? [07:20] maxb: time to roll it back, I hope to get to that tomorrow my time, but it's dragged on long enough in the mean time I think [07:22] Unfortunately, even accounting for those failures, we have still acquired a several more in recent weeks, making the number in the topic a bit of a lie :-/ [07:23] Some of them are more packages switching to multiple upstream tarballs [07:23] Not sure what the rest are [08:04] lp downtime. [08:04] * maxb has paused the UDD importer [08:05] (echo 0 > max_threads) === gerard_1 is now known as gerard_ [08:51] hi maxb [08:59] ji [08:59] hi poolie, maxb [09:00] hey [09:00] welcome back [09:00] are you ok? [09:00] thanks, it's good to be back :) [09:01] I'm doing a lot better; my leg is still bandaged and contains traces of metal but I'm feeling well [09:02] No standing desk for me for the next little while :) [09:03] thanks for all the well wishes [09:03] :) [09:04] how has everything been here? [09:04] good [09:05] you might like to look at the standup notes [09:05] and my mail about next-quarter goals [09:05] hm i was going to feed pqm a bit but it's a little hard with lp readonly [09:05] those windows should be getting much shorter, which is great [09:06] ah, cool [09:07] ah [09:07] there was some fallout from your bzr & plugins updates into lp [09:07] i'm not sure if this started before your break [09:08] it might be useful if you check up with one of their developers about that [09:08] once the current update has finished [09:09] oh, ok [09:10] i wonder if we should actually have a short postmortem thread about it [09:10] i'm not sure if the operational postmortems currently practiced are good value [09:10] but, perhaps something about lessons to learn for next time would be good [09:11] yeah, that's probably a good idea [09:12] one thing from talking to robert was that it would be nice, all else being equal, if those changes can easily be rolled back [09:12] i think there was concern that the cache formats had changed so they could not roll back [09:12] i'm not sure if that would actually have been true [09:13] the cache formats haven't actually changed in backwards-incompatible ways, as we also allow people to use multiple plugin versions in parallel on the same system [09:13] that should probably be documented somewhere though, and not just be in my head [09:14] are you still on lp-dev? [09:14] yep, I need to catch up on the last week of email though [09:14] :) [09:15] i'll kick it off [09:15] i think a lot of it will be in your head and robert's head so getting it out may help [09:15] i should go and have dinner [09:15] that'd indeed be a good discussion to have on lp-dev [09:16] also, bon appetit! :) [09:16] :) [09:20] we're having a UDD meeting in 2h40m iirc [09:24] hello all [09:24] * maxb unpauses UDD imports [09:29] sigh, too soon [10:21] jelmer, Just got hit by #485601 [10:24] Happily I think I can work around it, it's just me working on the branch and I can push --overwrite from one repo and re-pull from the other. It does seem to be when you merge into the trunk and push it, and then pull that from SVN on another machine, and try to pull on the original machine [10:25] (from the second machine) [10:26] Ok, darn, that didn't fix it [10:31] Ok, so : removed repo on M2. Recreated empty repo. Pushed from M1 (machine that did the merges) to M2. Pulled new SVN-origin revisions from SVN on M2. Pulled these back from M1. Issue fixed. [10:54] awilkins: jelmer may not be around yet. He was supposed to be returning from vacation today. I think that means he'll be around tomorrow, or maybe late tonight. === jam1 is now known as jam [10:54] * jelmer waves [10:54] jam, Ok... it's not a fatal problem for me, just making some notes as to avoidance on the bug ticket [10:54] jam: H [10:54] hey jelmer [10:54] Hi John, how are you? [10:55] doing pretty good, feeling better yourself? [10:55] * jelmer is batch-processing email :) [10:55] I got maxb's code for finding the most-recent publication, and I'm poking at it to try to integrate it into something like "bzr branch" [10:56] jam: I'm doing a lot better, thanks; it'll take some more time for my leg to heal but seems to be going ok [10:57] jam: ah, cool [11:20] hi jam [11:26] jam: just passing around, see my last comments about the 2.3.4 blocking bug: I agree with you, just wanted to make sure you're ok with landing the patch as is and addressing the larger issues in a followup [11:27] jam: I won't be able to land it until later today anyway, so no urgency [11:27] poolie, jelmer: Hi ! [11:27] vila: hey! [11:48] If I start using loom to work on a project, am I going to regret it? [11:50] jml: there is no trap door - you can always go back (and just have your loom flattened) if you need to, in the future [11:50] jelmer: that's good to know. [11:50] jml: that said, looms need quite a bit more polish to be really usable IMHO [11:50] * jml nods [11:50] I thought you guys were doing that as part of UDD [11:51] jml: we are, but that's long term - short term we're looking at having merge just handle quilts more sanely than it does at the moment [11:51] jelmer: ok. thanks. [11:55] hi guys [11:55] udd meeting in 5m [12:02] Riddell, jam, #ubuntu-meeting? [12:17] I rather liked the look of Mercurial pbranches [12:18] I wanted to port it to bzr at one point but never got far enough to refactor it into the abstract and implementation-specific bits [12:57] jam, that's great [12:57] i think you could make the text a bit more clear [12:58] "branch not up to date" might confuse people with eg the tree just being out of date [12:58] so say something about ti being an ubuntu package branch === dobey_ is now known as dobey === mrevell_ is now known as mrevell [13:04] poolie: I'd certainly like some discussion about polish/wording/when-it-should-trigger/etc [13:04] but I think getting something is a good first step. [13:11] it absolutely is, that's great to see [13:12] thanks for pushing it through [13:31] good night === zyga is now known as zyga-afk [14:51] who is best to discuss branch locking issues with? === beuno is now known as beuno-lunch === zyga-afk is now known as zyga === beuno-lunch is now known as beuno === timrc is now known as timrc-lunch === med_out is now known as medberry === mrevell is now known as mrevell-afk === timrc-lunch is now known as timrc === mrevell-afk is now known as mrevell [19:15] what's the best way to copy the history for a specific file, from one branch to another, when copying that file to another branch? [19:16] or can i do that? [19:16] As described, no. [19:16] Files don't have history. History has files. [19:18] i guess i'll just lose the history, since i guess doing it right is probably infinitely hard [19:22] There are ways to copy the file-id, so at least the files would be associated if the branches were ever merged, but... [19:23] well the two branches wouldn't be merged, as they'd have different ancestors === yofel_ is now known as yofel [20:28] jam: The fixup_new_roots change is a regression, but a pretty minor one, so I didn't want to bother with the 2.4 series. The test change is just a waste of CPU time and lines of code. [20:30] abentley: hey. do you know much about locking in branches? [20:30] dobey: sure. What would you like to know? [20:31] abentley: i'm fixing an issue in tarmac, and was wondering if there's a sane way to avoid having to unlock/lock all the time, when wanting to do some specific actions in bzrlib. [20:32] abentley: the issue is that in certain cases, tarmac when run under cron, can end up being run multiple times simultaneously, and as tarmac itself isn't doing any specific locking in general, you can end up with two processes competing over the same branch [20:32] abentley: so i started a branch to add locking, but it seems i can't just do a lock_write() once, and then unlock() at the end, unfortunately [20:33] dobey: if you're doing locking, you need to lock at the beginning and unlock at the end. Why can't you? [20:34] abentley: i can't lock at the beginning, and then do branch.merge() or branch.commit() as they seem to try acquiring locks independently [20:34] dobey: Read locks are internal to bzrlib, but write locks will live on after the process ends. [20:34] so i have to unlock, then lock again, before/after the merge/commit [20:34] and then finally unlock at the end [20:35] dobey: If the branch is locked, taking another lock is fine. [20:35] i was also wondering why there is only one unlock() [20:35] abentley: i was getting errors about lock existing already [20:35] dobey: bzr tracks the number and kind of locks taken. [20:35] maybe it's due to the way tarmac is using bzrlib or something? [20:35] dobey: It sounds like maybe you have two instances of the branch. [20:36] abentley: it is a working tree only [20:37] dobey: I'm not sure what you mean. You're using working trees, not branches? Fine, but each working tree is associated with a branch. [20:37] abentley: a lightweight checkout [20:37] dobey: Yes, a lightweight checkout is still associated with a branch. [20:37] is what i meant. forgot the term [20:37] right [20:38] does that affect the locking though? [20:38] that it's a lightweight checkout vs a full branch w/ history? [20:39] dobey: A lightweight checkout behaves like a non-lightweight tree in almost every way. [20:39] dobey: Can I see the traceback you were getting from commit? [20:41] abentley: http://pastebin.ubuntu.com/643514/ [20:42] actually, in the test, i think that might be a full branch [20:42] so that would throw the lightweight theory out the window :)( [20:45] dobey: looking... [20:48] dobey: the Branch class looks very suspicious. It takes a branch as input, but commits to a working tree later. Creating that working tree will create a new instance of the branch. [20:51] dobey: I recommend retrieving the tree immediately, instead of in create_tree. [20:52] hmm, ok; that makes some sense. thanks [20:52] dobey: then you can use tree.branch. Locking the tree will also lock the branch, and you'll be locking the right instance of both. [20:53] right. i'll see if i can rearchitect it without breaking stuff. thanks :) [20:53] dobey: np [22:44] hi all [23:48] hi spiv? [23:48] hi abentley [23:49] Good morning poolie [23:52] hey there [23:52] did you see your lp branch failed? [23:52] are you ok to dig into it [23:57] I did, all in JS tests [23:57] probably some not-yet-updated dependency [23:58] Which is completely unrelated to my patch, so presumably spurious [23:58] let me know if you want me to re-fire it [23:58] Yeah, it looks like that. [23:58] They were all ImportError: No module named html5browser