[00:18] igc: I would like to recommend that you reuse the error handling infrastructure from qbzr in bzr-explorer. [00:19] I'll put the details in a mail. [00:19] garyvdm: do you mean something more than the try/except at the app level? [00:19] garyvdm: thanks [00:20] Yes - you need a sys.excepthook to catch everything. [00:20] lalala, releasing bazaar [00:28] igc: No mailing list for bzr-explorer :-( [00:28] Can I create one? [00:30] garyvdm: sure. Another option is the bzr-desktop mailing list I proposed a few weeks back (but I don't recall getting feedback on) [00:30] Ok [00:40] igc: is it ok to import from qbzr in bzr-explorer? [00:42] garyvdm: absolutely. explorer reuses lots of stuff from qbzr including i18n support [00:42] igc: cool [00:50] igc: Did you go on vacation? How was it? [00:51] garyvdm: restful thanks [00:51] Thats good! [00:51] garyvdm: being the middle of Winter here, we had the beach pretty much to ourselves :-) [00:51] Installed Bazaar version 1.16.1 is too old to be used with plugin [00:51] "Bzrtools" 1.17.0. [00:51] :( [00:52] I guess I'd better get releasing [00:52] igc, welcome back! [00:52] hi jml - thanks! [00:55] Seems like everybody makes that mistake on their vacation... it's all going so well, and then they end it. [01:03] fullermd: indeed [01:04] I don't see anything in the NEWS file about fixing 2a bugs. [01:04] there are quite a few nice performance things though. [01:04] igc: Quick! Uncommit leaving the beach before you get more revs on top of it! [01:14] HPSS calls: 45 (17 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None) [01:14] :\ [01:14] jml: which operation? [01:14] spiv, pushing a new, stacked 2a branch [01:15] Ah ok. [01:15] with tags? [01:16] yeah, one tag. [01:16] without (new) tags is HPSS calls: 43 (17 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None) [01:17] whats the backtrace of the vfs trigger? [01:17] or, have we landed the patch that disables that :( [01:18] there are two of them. [01:18] (I really think folk should either not care about hpss calls, or care about vfs triggers) [01:18] hi lifeless, spiv [01:18] igc: good morning! [01:19] http://paste.ubuntu.com/216536/ [01:19] Yeah. tags causing vfs calls is pretty high on my hit list. [01:19] spiv: are you open to being convinced to keep vfs triggers tied to -Dhpss? [01:20] lifeless: no, not really [01:20] lifeless: they irritate *me* :) [01:20] lifeless: but more importantly, it means that other people have started turning off -Dhpss [01:20] why are they displayed, rather than logged? [01:21] how to list the remebered locations? [01:21] So if someone on the launchpad-dev team gets unexpected bad performance, and I ask for the -Dhpss log, they'll have to re-run the slow, painful operation before they can give me an answer. [01:22] Which is I think is a net loss compared to making the vfs triggers in-your-face. [01:22] spiv: are they still logged to ~/.bzr.log with the patch that stopped showing them? [01:23] spiv: because I think its still a net loss if we don't get the trigger [01:23] lifeless: I'm not sure, poolie did that patch. I'm fine with them still being logged. [01:23] (even though that makes debugging test failures more irritating, that only really affects me) [01:27] RenatoSilva, 'bzr info' [01:27] jml: thanks [01:27] Hi I just installed Bazaar and in the $HOME/.bazaar directory the only file is "ignore" [01:27] jml: please file two bugs [01:27] spiv, lifeless: anyway, I only mention it because it's something of a regression from the glory days of 8 or 9 hpss calls & no vfs ops. [01:28] jml: a) your scenario writes tags twice [01:28] jml: b) writing tags causes _ensure_real [01:28] jml: yeah. life was better when bzr.dev had no tags ;) [01:28] lifeless, the pasted stack traces were from pushing a branch that has no new tags. [01:28] I was expecting bazaar.conf - any ideas what causes this? [01:28] jml: no new tags != no tags, unfortunately. [01:29] (and the branch was launchpad) === ircleuser is now known as Ebro [01:29] ircleuser: If you do bzr whoami "User Name " it will create it. [01:30] spiv, wow, that sucks. [01:30] Ebro ^^^ [01:30] jml: pushing a new launchpad branch has never had no vfs ops [01:30] mwhudson, really? maybe it was only 1 or 2 then [01:30] sweet! Thanks! [01:30] jml: pushes between existing branches are still 0 vfs [01:31] (i think, anyway) [01:31] mwhudson, nope [01:31] oh [01:31] $ bzr push lp:~jml/launchpad/test-branch-47-2 [01:31] No new revisions to push. [01:31] HPSS calls: 14 (2 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None) [01:31] jml: please file the bugs ;) [01:32] lifeless, yeah, that's what I'm doing. [01:32] although they'll probably be crappy bugs. [01:33] jml: pull is 0 vfs at least, it seems [01:33] anyway, i'm not here right now [01:36] jml: there's a cheap optimisation in push atm where if you have 0 local tags it doesn't even need to read the remote tags, let alone write any tags. But as soon as there are any tags that obviously doesn't work... [01:40] spiv, makes sense [01:56] hello [01:58] hai [02:00] karmic is booting again, yay :) [02:10] poolie: your patch to mute -Dhpss on vfs events [02:10] poolie: does it make the trace get logged to ~/.bzr.log? [02:11] it moves the existing code to a different debug flag [02:11] so if it was not unconditionally logging them before, it's not doing it now [02:11] poolie: I would like, and I think spiv would do, if someone has -Dhpss, those events should get captured *somewhere* [02:12] why not just set the other flag? [02:12] poolie: because otherwise they have to reproduce the event [02:12] who? [02:12] the person reporting [02:12] the reason we added that flag was to get more data in bug reports [02:12] so we're talking about people who do have hpss set in their config options? [02:12] yes [02:12] but they can't be told to set the other flag? [02:13] well, ok [02:13] setting the other flag means they have to reproduce it again [02:13] rather than grabbing their log and attaching [02:13] i can see a lot of lp people probably do have Dhpss set, and it would be annoying to do it all over again [02:13] i don't really object, please yourself [02:14] ok [02:14] it's just that spewing it to stderr was way too much [02:14] I did that on the basis that noone would have Dhpss set unless they were working on the network stack [02:14] yeah [02:14] however it seems we have a bunch of voyuers ;) [02:14] a reasonable assumption but not actually true :) [02:14] i like having it on for background awareness [02:15] 'care about networking' is not precisely 'working on networking right now' [02:15] its kind of like the big display in windows defrag programs [02:16] hm [02:16] Perhaps we have voyuers, but also we frequently ask bug reporters and psuedo beta testers (like people on the lp team) to use it. [02:16] maybe a bit more useful than that [02:16] like i did actually use the trace while testing stacking against launchpad to see what it was doing [02:17] spiv: sure, the point is that if they have it set by default rather than on-request. [02:17] but that's not the same as looking for new things to fix [02:17] spiv: I'm not arguing against the change thats been made; I'm arguing for capturing sufficient data in a reasonable place. [02:17] lifeless: right. [02:17] actually maybe that's the difference, are you looking for trouble in the sense of open to being told about new things to improve [02:17] anyhow by all means capture it [02:17] even capture it unconditionally if you like [02:18] two other ideas re bug reporting: [02:18] one is, maybe we should record the reason why plugins failed to load and show it from 'bzr plugins' [02:18] at least the actual error message [02:18] i think at the moment failed ones are not shown at all [02:18] I think of the VFS trace as being the same as the HPSS trace; they are both showing whats going on. I appreciate that the noise was too much [02:19] and as a further step maybe don't show anything to stderr, just put it in there [02:19] and the second was, maybe have a global weak dict of open repositories etc [02:19] and show it in the error reporting tb [02:19] so we don't need to go back and ask for bzr info [02:19] hm [02:19] possibly that could be subsumed by just getting a full traceback through something like apport [02:20] I'm not keen on the word global there [02:21] I like the idea about plugins [02:22] i guess rather than being global we could look for things on the relevant stack [02:24] i might file a bug for that at least then [02:24] spiv, how's your stuff today? [02:47] thanks for the knockon errors review [02:47] what was that prefix you put in bzr selftest :plugin ? [02:47] bzr selftest -s :plugin [02:54] foodink [03:03] back [03:04] mwhudson: hi [03:04] jelmer: hi [03:04] jelmer: i was going to ask about the python2.4 subvertpy bug [03:11] hello jelmer [03:13] hi poolie, jelmer === jml changed the topic of #bzr to: Bazaar version control system | 1.17rc1 released 13th July, 2009 -- please test it! | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ [03:16] 'moin mwhudson, poolie, igc [03:16] g'day jelmer [03:17] hey jml [03:17] hi jelmer [03:17] lifeless: hi [03:17] mwhudson: Not much news yet, but I'm pretty sure I'll have it fixed before the end of the week [03:19] I've made this diff after merging the 1.17 branch into trunk: http://paste.ubuntu.com/216582/ [03:19] can someone quickly sanity check that for me [03:19] please [03:19] . [03:19] . [03:20] looks good to me [03:20] thanks. [03:20] * jml pqm-submits [03:21] poolie: good, I have literally only two issues left on my todo list for the inventory-deltas streaming branch. [03:21] cool [03:23] poolie: 1) two tests failing with pack already exists error when an autopack happens on a 2a repo (maybe bug 382463 ?), 2) making a new get_stream verb so that old clients won't receive inventory-delta records they can't handle (and arrange for deltas not to be streamed via the old verb, of course). [03:23] Launchpad bug 382463 in bzr "'bzr pack' of an already packed dev6 or 2a repo fails with Pack exists" [Medium,Triaged] https://launchpad.net/bugs/382463 [03:24] Oh, and I'd like to do a bunch of manual testing, but that can happen concurrently with the code being reviewed. Once I fix 2) I'll make the merge proposal. [03:25] * igc lunch [03:50] spiv: 382463 occurs on fully packed repos [03:50] spiv: it shouldn't ever happen on autopack [03:51] spiv: do you perhaps have an empty pack? [03:51] thats unlikely as we have guards for it [03:51] spiv: also we want to push verbs [03:52] spiv: sorry rephrasing. Could you add 3) a new insert_stream verb, please. [03:53] I don't think the pack is empty, as the name changes from test run to test run, which implies content. [03:53] ack [03:53] It's triggered by the self.target_repo.pack call in _locked_insert_stream [03:53] oh [03:53] I bet I know [03:54] you've one stream right? [03:54] and a new repo? [03:54] If you grab lp:~spiv/bzr/inventory-delta and selftest test_fetch_parent_inventories_at_stacking_boundary_smart you'll see it. [03:54] spiv: I'll give you a couple of hints now. If they don't help ping me later and I'll push stack and look at it with you [03:55] I suspect the following conditions are occuring: [03:55] - you upload a single pack [03:55] Off the top of my head, I think one stream + new repo is true. [03:55] - the pack is sufficiently simple that the sort order for its contents are the same as the upload order happened to generate [03:56] - the group splitting heuristics happen to line up at the same boundaries [03:56] It's also likely that this is a code path that wasn't being hit before (because InterDifferingSerializer was covering this case). [03:56] -> collision, with the same content. [03:56] so this is natural. [03:56] Yeah. [03:56] some possibilities to avoid id: [03:56] FWIW, if I replace the raise with a return the offending tests are happy. [03:57] (unsurprisingly) [03:57] - deliberately send in a slightly different order, to force the pack to do it in a different order [03:57] (ugh) [03:57] Yeah, I don't like the sound of that one. [03:57] - fix the long standing 'genuine collisions error rather than checking the content is the same' bug [03:58] (note that this needs to also check the indices are the same, I *think* the bug notes that) [03:58] That sounds like the right fix, but I'd be happy for someone else to do it ;) [03:59] - make the pack(hints...) method pass a flag down that means the repo can recognise that it just repacked pack FOO and got FOO and back it out rather than actually replacing at all. [03:59] I think the third will perform best [03:59] Hmm. [04:00] Can you elaborate on that third option? [04:00] I'm not really sure what the hint does (I haven't dug very deeply into this yet). [04:00] the hint says 'repack these specific packs' [04:01] I think it's just a "hey I just added this new data, so just focus on packing that bit" arg? [04:01] its allowed to be ignored if the repo can't do partial packs or whatever. [04:02] Ok, thanks. [04:03] Doing that pack-with-hints is what stops a delta inserted into a 2a repo from being GB's in size ;) [04:15] lifeless: btw, the branch already adds a new insert_stream verb. [04:15] spiv: cool [04:15] spiv: scratch 3) then :P [04:29] hey spiv [04:29] thanks for the update [04:31] jelmer: cool [04:32] jelmer: it looks like launchpad on 2.5 is going to take a little longer than we would like, so fixing the bug would be really nice :) [04:32] \o/ 24/27 inventories fail to error when the path is mismatched with the parent id [04:56] How can I check what revision I'm on in a branch? [04:57] bzr revno [04:57] thx [05:19] bbiab [05:45] jml: when adding the empty sections to NEWS at the start of a release, ... [05:45] I think "Internals" belongs later, e.g. after "API Changes" [05:46] igc, I think you're right. [05:46] jml: I'm about to tweak and land the Upgrade Guide [05:46] jml: so I'll tweak that while I'm at it [05:46] igc, thanks. [05:46] the 'releasing' guide should be updated to say 'add empty sections to the NEWS file' and probably should include a template for doing so. [05:46] I'll file a bug for that. [06:14] hello igc, welcome back! [06:14] well done on the release jono [06:14] and welcome back too [06:14] hi poolie! [06:15] lifeless: intercepting http proxies are not the answer, 'no' is the answer :) [06:20] lifeless, where's your whitepaper on interface testing? [06:20] poolie, thanks. [06:27] pygi, g'day [06:28] good morning jml :) [06:34] jml: I should update. Its on people.ubuntu.com. [06:34] poolie: they may be the cause though :P [06:35] lifeless, I find myself having to describe the concept increasingly often. An updated version would be nice. [06:36] jml: its time has come! [06:36] I want to add prose about balancing costs and fragility === thumper_laptop is now known as thumper [07:09] ok, EOD for me, a bit late (don't ask when I started :P) [07:10] currently fixing tree.apply_inventory_delta to not corrupt dirstate with duplicate file ids. [07:18] hi all [07:23] hello vila [07:23] writing a post about 2.0 and beyond [07:23] great [08:39] * igc dinner [09:21] is it possible to do a diff against the previous revision without knowing the revision number? like something like bzr diff -r -1 ? [09:22] yes [09:22] but -r -1 means the most recent revision [09:22] anywho: you probably want diff -r -2 [09:22] (that'll be the difference between the most recent but 1 commit and the tree as it is now) [09:24] that works but so what is the purpose of -1 in this case? it would never work, right? [09:36] anywho: It will show you the difference between the last committed revision and your working tree, i.e. the changes that are not yet committed [09:38] anywho: Basically -1 == HEAD [09:38] got it [09:39] thanks [09:48] good night all [10:21] night poolie [13:27] Anyone know why branch we create on our remote repository are created without group write? I have umask 022 in my /etc/profile, am I missing something? [13:27] *branches [13:32] awmcclain: 1) maybe you meant umask 0002 and 2) you probably want sticky group bit on the remote repo directory? [13:32] AfC: Yeah, I _just_ realize that about the umask, and the sticky bit is set. [13:33] Thank you.l [13:33] realized. [13:33] Ug, one of those typing days. [13:34] Hrm... do I need to restart a daemon for that /etc/profile change to happen? [13:38] Hrm... no, i have umask set to 0002 now, and I'm still getting the same permissions problems. [13:46] Does bzr not use /etc/profile? [13:58] awmcclain: It is not bzr's job to use or not use /etc/profile. That is up to the shell [13:59] maxb: Ubiquitous! [13:59] :-) [14:00] maxb: So, PAM is...what, a kernal module? My linux-fu is quite poor, I'm unfamiliar. [14:01] pam came from solaris ;) [14:04] maxb: So, if I'm reading the man page correctly, I'm going to add a line to my /etc/pam.d/login to alter the umask? [14:27] awmcclain: Doubtful that "login" has anything to do with ssh-based connections [14:35] login is for the 'login' binary.. which is used by getty et.al. for virtual consoles [14:38] If you're using ssh+bzr or bzr+ssh or whatever it's called, then surely it's up to your shell's non-interactive startup to set umask? [14:50] morning all [14:57] Hi! With which bzr command can I find out which files in the Working tree are version-controlled? [15:02] homy: bzr ls --versioned ‽ [15:05] wow, it's not often you see an interrobang used in conversation :-) [15:06] Talk: thanks.I didn't find that in the Bazaar User Guide http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html. [15:07] maxb: it is when I'm around :-P [15:10] i want to create a branch from a repo that includes all but some intermediate revisions, e.g., r1..100 and r105..200, which is the best way to do it? [15:10] s/best/proper/ [15:51] abeaumont_: branch in the normal way, then merge out those revisions? [15:51] or maybe branch the first revision group, then merge in each successive group === abeaumont_ is now known as abeaumont === michaelforres is now known as michaelforrest === kiko is now known as kiko-fud === obstriege is now known as obst === maxb_ is now known as maxb [17:29] Hi all. Is there a mailing list where I can post a feature proposal (and possibly work on it)? [17:32] Any launchpad staff here at the moment? I have a question that regards launchpad ignoring my mail address during registration [17:39] Adys: there is just the main development mailinglist: https://lists.ubuntu.com/mailman/listinfo/bazaar [17:40] amanica_: is it better to write a blueprint about it, or an email first? [17:40] Adys: maybe mail first [17:40] Ok [17:41] Adys: sometimes feature requests are submitted as wishlist bugs, but blueprints sounds better [17:41] Adays: btw. put [RFC] as the start of your mail [17:41] subject [17:41] Ok, thanks a lot :) Ill send it tonight [17:41] cool [17:50] jelmer: you have an interesting definition of "four" [18:00] SamB: hmm? === kiko-fud is now known as kiko [18:09] jelmer: bzr-svn also adds four new commands to Bazaar: [18:09] - bzr svn-import [18:09] - bzr svn-layout [18:09] For more information about bzr-svn, see the bzr-svn FAQ. [18:09] oh, right [18:09] two were integrated into bzr [18:10] SamB: fixed, thanks [18:11] hmm, you might want to mention those on that page because they're probably particularly useful for SVN repositories? [18:12] jelmer: I'm trying to narrow an exception down in bzr-svn that occurs on our repo if you start without a cache [18:13] jelmer: I think it is because layout.get_tags(self, from_revnum, project) returns [] [18:13] * LarstiQ files bug with traceback [18:15] amanica_: Ok. sent the mail. I gotta run for a couple of hours now. thanks again :) [18:17] jelmer: bug 398908 [18:17] Launchpad bug 398908 in bzr-svn "branching results in: ValueError: need more than 3 values to unpack" [Undecided,New] https://launchpad.net/bugs/398908 [18:19] * LarstiQ prepares to go home [18:20] LarstiQ: is this also with current bzr-svn ? [18:21] LarstiQ: since I fixed an issue like that recently [18:21] LarstiQ: yeah, I'm pretty sure this one is fixed [18:22] * LarstiQ checks [18:22] What's ETA for 1.17, or is that an annoying FAQ that does not have an answer? [18:23] kfogel: Usually the release manager posts a timeline for the release cycle before it starts, not sure if that happened for 1.17 [18:23] jelmer: timemachien yay :) [18:23] kfogel: I can't find anything, but usually it's about a week or so after the rc [18:24] kfogel: barring any release critical bugs that would require a new rc [18:24] SamB: They just happened to be commands that were hard to integrate into Bazaar, I don't think that's a valid reason for listing them there. [18:25] jelmer: right [18:25] SamB: for the record, these two commands were svn-push and svn-set-revprops (now: push and reconcile) [18:25] jelmer: ah. [18:26] svn push doesn't really need listing there, true [18:26] jelmer: was that revno 3097? [18:26] and I guess reconcile neither [18:27] though I'd never have guessed that it altered revprops in the SVN repository -- you do have that in the FAQ somewhere? [18:27] and I'm also not sure how svn push works when you've a complicated tangle of Bzr revisions to push -- what branches do they all get pushed on? [18:30] jelmer: applying 3097 to 0.6.2 fixes it for me, cheers! [18:55] SamB: it does a similar thing to what reconcile does in bazaar repositories - fix revision metadata; in this case that revision metadata happens to be stored in revisin properties [18:57] why bzr st sometimes reports file names with '*' at end? it breaks my scripts [19:08] hsn_: * means a change in the executable bit === davidstrauss_ is now known as davidstrauss [19:27] Hi all. I am new to bzr and have a basic question: I have a branch that I have run the "bind" command on to convert to a checkout, but when I got to try to edit a file it is locked. [19:28] What is the correct process to follow so my branch is unlocked and editable? [19:28] thanks [19:28] Skoorbulous: could you provide a bit more information? [19:29] It is a website and I am trying to starty with a simple bzr model whereby I simpy bind a branch to convert to checkout, make edits, unbind, commit [19:30] not sure if that makes sense but I do not want to create a whole local copy of it to make changes [19:31] Skoorbulous: what specifically do you mean with 'it is locked'? [19:32] it is locked by root so when I try to edit it with a text editor it tells me I do not have write priveleges [19:32] I thought that bzr probably locked everything up [19:33] Skoorbulous: could you please pastebin a transcript of the command you run and it's output? (http://pastebin.com) [19:34] I am trying to edit with a text editor on my mac - so there is not really a command that I can paste [19:34] Skoorbulous: as is you are leaving out the information from which to determine what is going on [19:34] Skoorbulous: and this text editor has bzr integration? [19:34] Skoorbulous: or what is the message it comes up with? [19:34] no its just a standard text editor. Can I not use standard software to edit my files if I use bzr? [19:34] jelmer: wow, SVN uses a dumb protocol ... [19:34] Skoorbulous: are you just having regular unix permission problems? [19:35] Skoorbulous: yes you can, but now I think your issue has nothing to do with bzr [19:36] It says "Are you sure you want to unlock entry.php that doucment is owned by "root"" [19:36] SamB: ? [19:36] I did not have permission problems until just now when I added bzr [19:36] jelmer: oh, maybe it's not quite as dumb as it looks ... but this server is being silly, at least: === sidnei__ is now known as sidnei [19:37] Transfer-Encoding: chunked [19:37] Content-Type: text/xml; charset="utf-8" [19:38] Skoorbulous: well, why is entry.php owned by root? [19:39] I guess I must have been in root when I added the directory to bzr - would that have done it? [19:40] hmm, I wonder why the SVN client doesn't send an Accept-Content-Type header? [19:41] Skoorbulous: I wouldn't think so [19:41] hmm [19:42] thanks for your help - this is a stupid question, but how do I convert everything back to ownership by a different user? [19:42] jelmer: I don't suppose it would be possible for bzr-svn to pipeline it's requests? [19:43] SamB: it is, see the bug report about replay in bzr-svn's bugtracker [19:43] ah [19:43] that's nicer than I somehow expected === fbond_ is now known as fbond [19:44] though it's obviously feasible from the protocol POV, at least for the HTTP protocol [19:45] !bugs bzr-svn [19:45] Sorry, I don't know anything about bugs bzr-svn [19:45] aww. [19:45] Skoorbulous: chown user -R [19:45] SamB: https://launchpad.net/bzr-svn/+bugs [19:45] jelmer: ah, thanks [19:45] would be nice to have a bot command for that or something though ;-) [19:45] SamB: svn isn't "standard" http, it uses REPORT to fetch revision delta's [19:46] jelmer: I can see it does that [19:46] I just happened to catch some of it's requests in wireshark when I was looking for something else [19:49] any bzrtools deveoper here? [19:49] jelmer: afaik, HTTP pipelining is possible iff you can make multiple requests on one connection, and that's sure what seems to be happening here [19:49] s/eo/elo [19:49] SamB: sorry, I should rephrase. with replay pipelining should not be necessary afaik [19:51] jelmer: ah [19:53] * SamB wishes he could profile bzr-svn's heap traversal ... [19:53] * jelmer wishes he could, too [19:54] I would think it had a space leak if it didn't keep swapping that stuff back in [19:55] * SamB wonders how impossible it would be to actually implement such a thing [19:55] I mean, it's not actually impossible [19:56] ... you could do something with valgrind ... [19:56] verterok: it breaks bzr-eclipse too [19:56]