=== kiko is now known as kiko-afk [00:17] * fullermd didn't get said hi to :( [00:21] Can aliases override commands? [00:21] yes [00:22] For instance, I've aliased 'rm' to 'rm --keep' since the option was added. [00:22] mmmm [00:22] commit to commit --strict :) [00:22] now... [00:22] yes I've just confirmed [00:22] 'course, maybe it's a bug that options aren't recursive so that actually works ;) [00:22] I saw some revert backup files in a directory [00:22] I'm trying to find the revno on trunk that introduced a particular change [00:22] and I have revert = revert --no-backup [00:23] was wondering if it wasn't working [00:23] but I guess they were old [00:23] thumper: annotate should be able to get you the revno at which a particular line was last modified [00:23] (or a list of revnos?) [00:24] it gives a dotted revno [00:24] I want the mainline revno [00:24] aaah [00:25] You'd have to track forward to where it was merged. [00:25] so it was modified in a merge revision and you want the merge revision? [00:25] yeah [00:25] Though ISTM there was some discussion about a flag to annotate to do just that... [00:25] *in a merged revision [00:26] is there a way to list merge revisions, incidentally [00:34] james_w: hi [00:38] hey lifeless [00:50] james_w: so where/how are you using stacked branches? [00:50] in bzr-builder [00:50] using shared-repos is a pain, so stacked branches seemed the obvious choice [00:51] it's just doing it as it needs the tree at minimum, and then perhaps enough history to do a merge [00:51] but never full history [00:51] it's not necessarily the best solution though [00:52] there is significant work needed in bzr to fix this bug [00:52] we're moving to shared repos or something like it as the main way of working [00:52] and downloading all the history should be faster than stacking anyway [00:52] actually thats the key point [00:52] stacking -> VFS operations -> slow. [00:53] stream all history -> fast. [00:53] stacking with a local tree requires downloading all the tree data over vfs *anyway* [00:53] so ignoring shared repositories, not stacking should be faster in this use case regardless [01:01] bzr-buildbot-net... a botnet for Bazaar? Cool. Er, um. [01:01] :) [02:30] hello all [02:30] hi [02:40] how's stuff? [02:40] it's hot and humid here [02:40] more humid than hot though [02:41] well [02:42] I've been landing lots of little 2a-default fixes [02:42] and spivs network delta thing is landable now [02:44] ah that is good [02:45] I spent some time with the u1 folk this morning - they are fsyncing in their dirstate equivalent... and its slow ;) [02:45] heh [02:45] i guess at least they know what platform it's running on [02:45] well, kinda [02:45] lynne, stephane and I are doing yum cha & a movie on sunday; the hoyts website is _terrible_ [02:46] Landable, and in PQM's queue! [02:46] that's nice [02:46] woo [02:48] jam: don't suppose you are still around [02:48] jam: WT3.update_basis wants xml inventories from the repo [02:49] lifeless: generally i think fsync is a poor deal: may not give you much protection and slow with it [02:49] yep [02:49] one property we can rely on is that files written a long time ago and not touched are unlikely to be affected by future writes [02:50] only by media failure [02:50] so something like obsolete_packs feels write except [02:50] - it might be nice not to remove them at all [02:50] right? :) [02:50] heh, thanks freud [02:50] and s/remove/move [02:51] - it would be good to automatically detect the latest consistent state, without relying on any fs access [02:51] blah my fingers are flaky today [02:51] i meant, without relying on any fs ordering guarantees [02:51] yes [02:51] thats the tricky bit [02:51] conceptually if you could read the whole file and compare it to a hash at the end [02:52] that would get away from assuming that if a file's been renamed, all the data previously written to it made it to disk [02:52] oh, complete tangent - http://eu.squid-cache.org:8081/ [02:52] and you wouldn't need to sync [02:52] thats the squid hudson instance [02:52] what I'd like to get away from is the root node [02:53] its the only really fragile bit today [02:53] (not that its failed ever as far as we know) [02:54] meaning the pack names? [02:54] .bzr/repository/pack-names, yes [02:54] mm [02:54] I don't mean 'dont have a root node' [02:54] the other thing that's reasonable to assume is that the fs can keep its own structures coherent, specifically directories [02:55] but then you get into trouble with places that can't list directories, so it may not help much [02:55] it's something to think about for wt metadata at least [02:55] wt metadata is less of a problem I think [02:55] much less at stake, and less likely to be over e.g. http [02:56] Corrupted dirstate would be even less of an issue if we had a revert --blat-me-out-a-fresh-dirstate-already... [02:56] fullermd: well, there are things that dirstate does today we will definitely fix ;) [02:56] true [02:57] fullermd: but over and above that there are cases repositories [and branches] are expected to handle gracefully that wt's aren't... [02:57] I mean, you'd lose add's... no big deal. Lose rm's with the file still around... not too bad. Lose mv's... that's the big hiccup. [02:57] or aren't-so-much [02:57] But when your alternative is to sit around with every op blowing up on the dirstate, or creating a new checkout and manually moving files around to simulate it, as people get told to do... [02:58] rebooting karmic, biab (i hope) [02:58] fullermd: i agree that revert op would be good [02:58] thought it's kind of a kludge [02:58] Oh, it totally is. But I like software that gives me big hammers to power through unpleasant situations once I'm in 'em. [02:59] hmm, do you use BSD? [02:59] :> [02:59] Sure, but that's not powering through; BSD is dying, everybody knows that. [03:00] oh [03:00] what BSD flavour/version do you use? [03:00] (and it's really BAD at it too, 'cuz it's been doing it for more'n a decade, and it's still twitching. Just can't do ANYTHING right...) [03:00] I'm on Free. [03:00] (given that macosx has ~= desktop share with linux, its hardly dying) [03:00] what version? [03:00] FreeBSD 8.0-BETA2 #0: Sat Aug 1 04:27:00 CDT 2009 to be Pacific. [03:01] and what arch [03:01] care to run a squid buildslave [03:01] (RELENG_7 from Feb on another box, an old REL_6 elsewhere.... bunches of 'em) [03:01] we have 6.4 under test [03:01] Workstation's amd64. [03:01] nothing recent [03:02] Oh, I can do occasional build/report type things. Not really in a position to lay out automation, though. [03:02] http://wiki.squid-cache.org/BuildFarm [03:03] read the 'Activating a slave machine (as the machine owner)' section [03:03] if that sounds ok; then woot [03:03] and if you want to run it sporadically thats fine too [03:12] Hm. Well, maybe I'll get a chance to look more at it. [03:13] It'd be nice to have some ballparks on resource utilization involved on that page. [03:14] theres ~ a commit a day [03:14] a build can be as short as 30 minutes [03:14] What does a run eat, though? 50 megs of disk? 2 gig? Does it churn the CPU for 10 minutes, or kill the IO subsystem for an hour? [03:15] good questions [03:16] the build includes make distcheck [03:16] and some tests [03:20] 3.1.0.13 build takes [03:20] 133.100u 40.812s 2:57.68 97.8% 6213+2442k 0+50io 997pf+0w [03:22] thats not the autotest :) [03:22] which does some more work [03:22] Yah, I expect so, seeing ~30+ minute times in some clicking around the buildfarm thing [03:22] the 2h one is a nuts slow machine [03:23] # du -sh 3.HEAD-i386-FreeBSD-6.4 [03:23] 119M 3.HEAD-i386-FreeBSD-6.4 [03:24] we do a minimal build [03:24] and a build with everything we can turn on turned on [03:30] lifeless: so I think you're saying that WT3 + 2a is broken... IIRC the WT3 code can handle when the basis inventory is not present, and just fetch it from the repo. [03:30] So can we just have it skip caching the inventory? [03:32] jam: btw, I'm not sure exactly what you fixed in InterDifferingSerializer recently, but I still see stacking-related test failures with a 2a target if I use IDS. Your test changes don't notice, but assertCanStreamRevision does. [03:33] jam: so I suspect something still isn't quite right. [03:33] spiv: I won't say I caught everything, but I certainly made it a lot better [03:33] Oh, I don't doubt you made it better :) [03:33] given that your change to IDS was causing it to store the current inventory under the name parent_id [03:34] jam: we have tests that test that it caches eventually [03:34] lifeless: if self.branch.repository.supports_chks: don't cache [03:36] jam: I'm submitting an implementation of _iter_inventory_xmls [03:36] so, given that caching the xml is probably going to end up *slower*, I don't see the benefit [03:37] and it sort of hurts in the long run [03:37] its for WT3 [03:37] its an extremely corner case [03:37] but it leaves a get_inventory_xml lying around [03:37] and now functional [03:37] I know, but we use it from two places [03:37] bundles and wt3 [03:38] we use the conceptual functionality, I mean. [03:38] honestly, having repository.deserialise_inventory != _serializer.read_inventory_from_string is more of an issue for me [03:39] when you say caching the xml is slower, do you mean 'merge etc operations on wt3 will be faster using CHKInventory' ? [03:40] because, I'm not entirely sure I buy that, not without profiling/testing. [03:40] lifeless: given how slow it is to build the xml... hard to say for sure [03:41] I suppose if merge has to read the whole inventory anyway [03:41] it would be paying that on each action [03:41] jam: so, I don't have a windows machine, which is kindof needed to properly measure this, as win32 is the only place we suggest/encourage wt3 [03:42] lifeless: hm... I don't use it there [03:42] 'diff', 'status' operations are both full tree [03:42] WT4 works just fine [03:42] jam: bialix often says he uses wt3 [03:42] I think that is more win98 [03:42] but now that isn't even true anymore [03:42] since we switched to CreateFile [03:43] LockFileEx doesn't exist in Win98 [03:43] which was how we took the os lock in the past [03:45] with that patch, we're down to FAILED (failures=19, errors=17, known_failure_count=22) [03:45] on my reduce workflow [03:45] when they are fixed, I'll be doing a full run [03:47] jam: I think https://bugs.edge.launchpad.net/bzr/+bug/336383 is fixed, do you? [03:47] Launchpad bug 336383 in bzr "branching dev6 when ghosts are present fails" [High,Triaged] [03:51] lifeless: given that --2a works with bzr.dev, I'm pretty confident it is fixed [04:06] Hm. So, if I have a branch that has revisions not on mainline, but there is nothing on mainline since the branch was taken, [04:07] why would merging that branch back create a mess? [04:07] (ie, I could pull, but I've been out of that habit) [04:07] what sort of mess? [04:07] I was astonished to see merge conflicts and worse highly incorrect choices on the stuff that didn't conflict. [04:07] lifeless: ^ [04:07] did it warn about criss-cross merge? [04:07] n [04:07] o [04:08] (at least, not recently. Few weeks ago) [04:08] check the scrollback please; its not very obvious [04:08] sorry? [04:08] in your console? [04:08] what's a scrollback [04:08] oh [04:08] gotcha. Checking [04:09] _oh_ [04:09] so, I was bad and didn't run `bzr status` in the 'mainline' branch before running the merge. [04:09] And surprise, it was "Run bzr update" [04:10] I hate that [04:10] I'm confuse - what commands did you run? [04:10] I would have thought it wouldn't let me merge or something. [04:10] lifeless: [04:10] $ bzr merge ../fix-text-replacement [04:10] lifeless: that's it [04:10] but then, just now, I ran [04:10] $ bzr status [04:10] and saw [04:11] working tree is out of date, run 'bzr update' [04:11] ah [04:11] so it got a mangled merge. [04:11] (there were some revert --no-backups in there) [04:11] I assume it won't bork now that I've run update [04:11] * AfC tries again [04:11] should be fine [04:12] All changes applied successfully [04:12] So as noted, I've backed myself into this corner before. Quite frequently, in fact. [04:12] you need a flashingblinkinbeepinlight [04:12] I must admit it's in the category of things I should like to think I couldn't do to myself with bzr [04:13] lifeless: I need it to say [04:13] working tree is out of date, run 'bzr update' before you run 'bzr merge', stopping now so you can fix it [04:13] lifeless: though if you've got a spare blinkenlight, I'll borrow it [04:14] yeah, it's clean. Build & test passed [04:14] Hm. [04:14] how long does a java-gnome program take to start [04:14] Not sure if that counts as a bug report, but it sure is a "experienced bzr user managing to screw up, fyi" [04:14] yeah [04:14] I'd love to make it better [04:14] lifeless: {shrug} < 1 second? [04:16] lifeless: but GTK & window manager & X sometimes take a long time to do first presentation of a new GtkWindow. That's not anything I can do anything about; http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Widget.html#showAll() :) [04:18] It also takes longer when the person who is supposed to be typing `make test` is typing in an IRC channel instead :) [04:18] :> [04:53] what is the bzr "equivalent" to svn's switch (for a branch, not a checkout)-- in terms of appropriateness for upgrading code to a new tagged version [04:54] switch [04:54] oh, not a checkout [04:54] bzr pull --overwrite [04:54] ah okay, i'll experiment with that. thanks [04:59] * igc1 lunch [05:16] Gar, PQM failed my branch after running about 90% of the tests (test_scenarios). Oh well, resubmitted... [05:16] spiv: :( [05:18] spiv: https://code.edge.launchpad.net/bzr/+activereviews - I'm trying to dominate the page :) [05:19] Heh. [05:20] failures=12, errors=16, [05:21] the numbers, they are shrinkin [05:23] I can resend my log of test failures if that'll help ;p [05:25] of wha [05:25] t [05:26] Well, bzr. [05:26] I presumed you were bemoaning the cursed fate of numeric shrinkage. I'm all about being helpful :) [05:26] thanks [05:44] Hello, I have dont a few commits on a system of which I forgot to set whoami on... is there a way to change the commiter name and email on past commits? [05:45] you can use uncommit + shelve to pop them off [05:45] then commit again [05:45] so [05:45] uncommit [05:45] shelve --all [05:45] uncommit [05:45] shelve --all [05:45] uncommit [05:45] commit [05:46] unshelve [05:46] commit [05:46] unshelve [05:46] commit [05:46] would be how you do it for 3 revisions [05:49] when doing shelve --all i'm getting an error to where it can't acquire a lock on .bzr/checkout/dirstate etc etc [05:50] doesn't look like anything has it open [05:51] lifeless: could https://bugs.edge.launchpad.net/bzr/+bug/377261 be resolved by your delta fixes? [05:51] Launchpad bug 377261 in bzr ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update"" [High,Confirmed] [05:52] yes, I expect it wouldn't wedge itself now [05:58] EODing [06:38] AfC: is libjava-gnome-java on ubuntu your project? [06:38] or the other one [06:40] lifeless: uh, [06:40] lifeless: http://java-gnome.sourceforge.net/4.0/get/ubuntu.php [06:40] lifeless: from that PPA, yes [06:40] (sync from Debian is rather behind, I gather) [06:42] Guillaume has done a nice job of that package, and I nudged him on the few things that caught my eye with respect to how it was being built. So as far as I know that's good to go. [06:44] lifeless: I'm going to be on my way out the door shortly, but we can always chat further in #java-gnome on gimpnet should you have project specific questions. [06:44] ok [06:44] karmic has 4.0.9 [06:46] debian has 4.0.7 only [06:46] so its something else [06:47] lifeless: I guess I should take an interest in bugging someone about that, then. [06:47] Where's Peter :) [06:48] http://packages.qa.debian.org/j/java-gnome.html [06:48] Hey look! Zero bugs :) [06:49] zaroo! [06:53] hi lifeless [06:53] do you want me to do anything more on 2a test failures, or is it all in flight in that branch? [06:53] i have probably about 3 hours here and am looking for some juicy fruit in small pieces [06:54] poolie: hi [06:54] I'm down to a small number of failures [06:54] there are two conceptual things to do [06:54] 1) drive that to zarooo [06:54] 2) run the full test suite again to find things missed in the first pass [06:54] both of those would be useful [06:54] i could probably do reviews or finish john's changes for apport [06:54] I'll be picking it up again on Monday. [06:55] I think getting this branch ready is essentially the most important thing we have; as its critical path for getting feedback from early testers of the impact of the change [06:55] theres also 3 or 4 more changes up for review from that branch [06:55] yep [06:56] and after we finish the branch it needs a review [06:56] i just don't want to churn by investigating or fixing things you've already done [06:56] I'd love it if you kept the branch rolling along [06:56] oh i guess you'll be finishing soon [06:56] its all either a) in the branch or b) not investigated [06:56] poolie: I finished an hour ago - the perks of starting at 6:15 [06:56] kk [06:57] I've been spinning off little branches; if you keep the branch moving I'd encourage you to do that so that the final thing isn't a review headache. [07:04] lifeless: [I commented the Ubuntu bug about java-gnome 4.0.12] [07:05] lifeless: yeah that's why i was splitting them off [07:06] poolie: right, I just made branches instead:) [07:06] instead of branches and bugs? [07:06] mm [07:07] if we really need a bug for every change that lands, I know a CMM lvl 3 consultant. :) [07:07] though that should be cmmi these days, I guess. [07:09] lifeless: if you pay me enough, I'll help you convince your boss not to do that :) [07:09] :P [07:10] i'm really thrilled wine was so easy [07:11] wine? [07:12] the win32 implementation [07:12] I'm totally lost :) [07:12] That would be pronounced whine. [07:12] i just sent mail [07:13] if you install it and then install win32 python you can run bzr in a win32 environment from within your regular unix workspace [07:14] oh right [07:14] poolie: you should have a chat with Erik de Castro Lopo about his experiences with that & automated builds & automated testing. Quite successful for libsoundfile and secret rabbit code, I gather. [07:14] cool [07:14] mm [07:14] he might have mentioned it [07:14] i anticipated it would be more trouble than it has been so far [07:15] of course that may just mean.... *splat* [07:15] but for example [07:15] % winepython ./bzr missing http://bazaar.launchpad.net/~mbp/bzr/doc [07:15] works [07:15] running ssh may be hard [07:15] Funny. I was kinda looking forward, when I built this workstation, to seeing how much better stuff through wine performed... didn't really think it through though. [07:17] Hello, today when trying to commit my project to LaunchPad I'm getting the following error: bzrlib.errors.TooManyConcurrentRequests [07:17] * AfC waves g'weekend [07:18] acestar: that's probably a followon from something else [07:18] did you get a previous weekend [07:18] cheerio afc [07:19] fullermd: how so? [07:20] Oh, I carefully avoided thinking about wine's stunning capabilities on a 64 bit OS... [07:20] lp is down [07:20] fullermd: I play WoW on wine on my i7 [07:20] Well, theoretically it might work if it were built as an i386 binary. [07:21] Hmmm, when I do a bzr update, I get a notice that says bazaar.launchpad.net has refused the SSH connection. Any ideas? [07:21] But that would take fiddling by itself, never mind that I'd also have to build 32 bit versions of half of X and a bunch of other stuff that it links to... [07:21] acestar: there's a problem with that system [07:21] people are working on it [07:21] acestar: launchpad has just suffered a problem, and we're fixing it now [07:21] (i hope) [07:22] poolie: lifeless: oh ok thanks for the info! will do local commit :) [07:22] we really need a system status page [07:24] lifeless: i'm *this* close to just creating a Launchpad system status page on help [07:26] google appserver + N buttons, anyone can click, everyone can see [07:26] and have it do a ping on request to the various servers. [07:27] i thought just on the wiki [07:27] even being manually updated would be an advance [07:27] if auth is down you can't update it [07:31] interesting point [07:31] is that common? [07:33] hi all [07:33] hi vila [07:34] greetings vila [07:34] power outage here ~4 hours ago, just finished restarting everything :-) [07:34] * fullermd waves at vila. [07:35] * vila waves back [07:35] hey pigy, poolie [07:36] vila, just you joke about my nick :p [07:36] rats, no, low coffee => typo :) [07:44] wow, ssh: connect to host bazaar.launchpad.net port 22: Connection refused ??? [07:47] vila: yeah. (hi btw! :-) ) cherry pick that went sour. should be good now. [07:47] vila: You're only allowed to connect via htpps ;> [07:47] hi spm ! Great, confirmed, works now [07:48] fullermd: got that wrong ! Should have been hhtps :) [07:48] Ah! No wonder it wasn't working for me... [07:48] anyway, I use a patched /etc/services just in case, so it works for me even with the typo.... [07:49] vila: you need: "apt-get install sl" as well then. for those "ls <--> sl" moments [07:49] tsk tsk, sl is aliased to show-loom around here, totally different beast :) [07:53] for shame. having a train scroll across one's screen is entertaining! [08:14] spiv, how did you go with the delta patch? [08:14] If I merge some specific changes, can I tell my target branch that it is up to date with source somehow? [08:14] I want to merge 1-4, 5-10 [08:15] err. 1-3, 5-10 [08:15] i.e., not bring in 4? [08:15] but pretend you did? [08:15] after doing the merges [08:15] do 'bzr merge source' [08:15] then 'bzr revert .' [08:16] this will keep the merge marker but revert the file changes [08:16] poolie: landed! [08:16] then commit [08:16] woo way to go [08:16] have a weekend on the house [08:16] Hah. [08:16] fullermd: exactly [08:16]