[00:41] so.. is there any nice intuitive docs for using bzr-fastimport? [00:42] bazzar-vcs.org/BzrFastImport explains hwat it is but not how to use it.. [00:54] MTecknology: bzr help plugins/fast-import [00:55] (or maybe "bzr help plugins/fastimport", actually...) [00:58] hi spiv [00:58] hi bialix, igc, MTecknology [01:04] hi poolie [01:05] spiv: oh - thanks [01:06] poolie: hi [01:06] Oh, thanks for mentioning fastimport. Reminds me I wanted to prod the cvs2svn port maintainer about upgrading... [01:06] MTecknology: see http://doc.bazaar-vcs.org/plugins/en/fastimport-plugin.html [01:06] spiv: now - how about a bzr-fastdeb tool? [01:06] igc: thanks [01:06] and http://doc.bazaar-vcs.org/migration/en/data-migration/index.html [01:11] MTecknology: what do you mean by "fastdeb"? [02:04] Hello I've realised I've been working in the wrong branch =) how can I pull just the working tree from the other branch? Can I shelf it on one branch and unshelf in another working-tree/branch === MTecknology is now known as ALearing [02:06] xnox: perhaps "bzr merge --uncommitted" can do what you need [02:08] spiv: Awesome thanks =) === ALearing is now known as ALearing_ === ALearing_ is now known as AdamLearing === AdamLearing is now known as MTecknology [02:28] how can I push to parent branch instead of push branch without retyping it? [02:29] bzr push :parent, IIRC [02:29] spiv: thanks =) is it part of revspec? [02:29] And if you did "bzr push :parent --remember", then subsequent pushes of that branch you can do just "bzr push". [02:29] manual? [02:30] spiv: no I don't want that =) parent is svn repo. Push is bzr for me =) [02:30] Push is to lp ;-) [02:31] I'm not sure where it's documented. The defined aliases are :parent, :submit, :public, :push, :this, and :bound. [02:32] Hmm, I don't think it is documented. There's probably a bug about that... [02:34] It's bug 337834 [02:34] Launchpad bug 337834 in bzr "AliasDirectory locations are undocumented" [High,Confirmed] https://launchpad.net/bugs/337834 [02:35] igc: any progress on alias (:parent, etc) docs? [02:39] * xnox feels like he know bzr zen now =) working with undocumented tricks ;-) [02:39] xnox: spoilers welcome [02:39] spiv: is that one of mine ? [02:40] spiv: still on my todo list. Maybe this week all going well [02:53] SamB_XP: that bug? It doesn't have your name on it, but I suppose if you wrote a patch no-one would complain... ;) [02:57] Oooh Can I write a patch? =) [02:58] I'll poke around bzr code and try all of them ;-) Black-box testing for perfect documentation =) [03:01] xnox: well, you can just read the code rather than guess :) [03:01] xnox: bzrlib/directory_service.py has the relevant code :) [03:03] ok I'll see what I can come up with ;-) [03:05] * spiv -> lunch [03:09] * igc lunch [04:13] hey people [04:13] hello jfroy [04:13] I'm getting an core dump running a plan diff command in a working tree because of a missing revision (probably a ghost) [04:14] This being on machine B [04:14] and the branch having been acquired through bzr-svn [04:14] so, basically, to be expected [04:14] the question is, how do I 1) get a list of ghost revision IDs [04:14] 2) figure out in which branch a particular revision ID lives (on machine A which should have said rev ID) [04:15] poolie: and hi ! [04:15] hm [04:15] Also, as a suggestion, core dumping on a missing revision when doing a simple diff -> going to scare people away [04:15] !! [04:15] really should handle it better [04:15] yeah [04:15] do you mean actually dumping a core file? [04:15] or just a python stacktrace? [04:16] right, python stack trace [04:16] not an actual interpreter core dump [04:16] that'd be *very* scary :p [04:16] that's what i thought [04:16] sorry for the confusion :. [04:16] * :/ [04:17] Though I consider unhandled exceptions in bzr as "crashes" [04:17] they're just as unhelpful as plain old crashes to users [04:17] anyways, on the matter at hand... [04:17] bzr check lists the the number of ghost revisions [04:17] but I can't seem to find a command to actually give me the revids [04:18] jfroy: i agree, we should never show python crashes to user - this is the documented policy, that whenever this happens, it's a bug [04:18] although the backtrace does have one, which seems kind of silly -- "oh just use unhandled missing revision exceptions to find the ghost revision IDs!" [04:18] however, in 95% of cases, there is actually some more important underlying bug [04:19] yeah [04:19] so showing a crash is an appropriate way to represent it [04:19] not trying to fob you off but the best thing is probably to either look for or file a bug [04:19] it may already be known [04:19] about the ghost revision crash [04:19] and that bug may have better info than i have in my head [04:19] Oh I know why I'm getting it. [04:19] It's a ghost. [04:20] The bug already exists to handle them better in various commands. [04:20] well, bugs [04:20] I just want to get a list of them so I can turn around and find who has those revs... [04:24] mm, well that worked; used the revid from the backtrace with bzr log -c -r revid: [04:24] from a random branch [04:24] it found it, got me the branch nick, and I pulled that branch in [04:24] need a better workflow than that -- ghosts are going to be common for bzr-svn users [04:24] might be worth a plug-in... [04:56] bbiab [05:13] I have wrote some help for the urlspec and URL directories [05:13] nice [05:14] I have tried automating code just like with protocols and it showed up three directories [05:14] : Easy access to remembered branch locations [05:14] jam, how do you get into the breakin debugger on windows? [05:14] lp: Launchpad-based directory service [05:14] igc ^^? [05:14] and [05:14] deb: whitch uses Vcs-* fields. [05:15] But where did the deb: directory came from? [05:15] I don't remember installing such plugin and it sounds awesome [05:15] probably bzr builddeb? [05:16] xnox, poolie: yes, bzr-builddeb [05:18] Well I never new about it..... =( now with my improved documentation I found out about it =_ [05:18] =) [05:59] It seems that lp:do/0.8 has had a failed upgrade at some time in the past, so when I try to upgrade it now it complains that backup.bzr exists. How can I fix this? [06:01] RAOF: connect to it with an sftp client (lftp is a good one) and delete that dir and its contents. [06:03] RAOF: lftp -e 'rm -r backup.bzr' sftp://bazaar.launchpad.net/~do-core/do/0.8 [06:04] Aaah. It's the full specification that's strange. [06:05] Yeah. [07:06] spiv, in question 93050 and i think a couple of others recently we've seen things hang during a long body fetch [07:06] there may be nothing in common and there's not much to go on [07:07] but i wonder if it's more than a coincidence [07:10] poolie: hmm, the only other case I recall seeing recently was vila's VM at the sprint [07:10] (hi vila!) [07:11] hey :) Don't mention that VM hangs, not now, let me get some more coffee first :) [07:11] That case was due to misconfigured network(s) [07:11] * vila kicks babune hard hoping to un-hang gentoo and hardy and jaunty [07:11] Hi all [07:12] And in that question 93050 there was definitely a misconfigured network (dropping all ICMP!), pity that correcting that didn't make the problem go away :) [07:12] by the way, if anybody landed some patch related to log, the tests are failing for LOCALE=C (the part we don't run anymore on PQM) [07:13] It does seem fairly clear from the description that it's something to do with their firewall, which makes me think that it's not bzr's fault, but maybe there's something we can do to make us less susceptible? [07:13] hi vila [07:13] vila: I think r4868 [07:13] vila, maybe it was igc sponsoring marius's patch? [07:16] yeah I suspected so... or not, I seem to recall a discussions about tests during the review... I was hoping some long due refactoring there had started :-P [07:18] spiv oh my mistake [07:18] i thought there was another one where they hadn't specifically mentioned a firewall thought [07:28] poolie: hmm, it's confusing, 93050 is a dupe of 93043, although I realise now they misfiled that one against bzr-upload [07:29] poolie: but in a reply to 93043 they say "If i disable ufw firewall completely, then, i am able to do checkout from the external network." [07:29] er, 93045 I mean. [07:46] LC_ALL=C ./bzr selftest -s bb.test_log -s bb.test_commit is the recipe to get the 4 errors [07:51] vila, file a bug for igc, if you haven't already [07:51] poolie: sure [07:51] poolie: do you intend to land or work on https://code.edge.launchpad.net/~mbp/bzr/progress-output/+merge/14944 ? [07:52] if it's 'land' I can help, if it's 'work' let's put it back into wip (Work in progress) [07:53] vila, it has test failures [07:53] which i should fix, but i suck [07:53] lol, so wip ? Too many things are already falling from my plate to honestly propose help here :-> [07:58] nag me [07:58] i'll do it now [08:27] * igc1 dinner === igc1 is now known as igc [08:56] vila, sanity check wanted re that review [08:56] how about giving log code two file like objects, one for unicode and one for bytes (for the diffs) [08:57] it essentially does this internally but it gets them by peeking inside what it assumes is a codec wrapper [08:57] let me get the code [08:58] argh, marked wip I presume, it went out of the active review page :-/ [08:59] so, without the code, two file objects sounds weird, but if it's through an API, I think it's fine and if that's what the code needs anyway then that's the way to go [09:00] i know [09:00] there's a bug about that [09:00] one aspect I like a lot about TDD is that it gives more users to the code which is the best way to find the good design and APIs [09:00] mm [09:01] ha, found it back lp:~mbp/bzr/progress-output right ? [09:01] right [09:01] you can still use the url you pasted above [09:02] like this http://pastebin.ubuntu.com/337132/ [09:03] hmm, my gut feeling looking at that is: ui.ui_factory.make_output_stream(encoding) is all that is needed [09:03] each command can then decide how many file objects it wants [09:04] where? [09:04] http://pastebin.ubuntu.com/337132/ [09:04] i mean [09:04] are you suggesting i do that in cmd_log? [09:04] log -p is really a special beast AIUI, other commands will use a single file object, only log -p needs two [09:05] right [09:05] so i'm just doing this as a special case in log [09:05] yup, as long as the buffering is right [09:06] make_output_stream can then handle the special cases (tty, redirected, etc), the caller is still responsible for the encoding [09:07] hm [09:07] does that fly ? [09:07] oh you're saying one level for just 'give me a stream' and then another doing encoding? [09:07] make_output_stream takes an encoding parameter [09:08] right [09:08] encoding_type, sorry, hmm [09:08] so you're suggesting moving that into say make_encoded_output_stream? [09:08] it takes both [09:08] it can be eg 'utf-8', 'replace' [09:09] can i delete a branch from a remote host? (a branch i've pushed in the past which isn't needed anymore) [09:09] no, just using it, AIUI log requires different encodings for the commit messages and the diffs [09:10] Kamping_Kaiser: bzr doesn't provide a command for that, but you can delete the directory on the remote host (especially if you use a shared repo there) [09:10] vila: ah, so i have to ssh to the host and rm -f the branch? no worries. cheers. [09:11] Kamping_Kaiser: that's it, you're welcome [09:11] thanks :) [09:12] vila https://bugs.edge.launchpad.net/launchpad-code/+bug/489036 btw about wip mps [09:12] Ubuntu bug 489036 in launchpad-code "where do in-progress mps go to?" [Undecided,New] [09:16] poolie: comment added there [09:19] poolie: also since you're touching _setup_outf(), if you could call it at the right time so that using Command objects become less painful... you'll be my hero :-) [09:19] By 'less painful' I'm thinking about tests or plugins that override commands and have to call _setup_outf() explicitly when building Command objects [09:20] # XXX: is the caller supposed to close the resulting object? [09:20] yes [09:20] poolie: ^ [09:21] # XXX: this does not handle the case of writing part of a line [09:21] heh [09:21] caller responsibility, trying to address it there will be nightmarish [09:21] thanks lazyweb [09:22] lazyweb ? Literally a social network of lazy people ? [09:23] mm, the term for asking humans something that you could look up yourself but are to lazy to [09:23] too* [09:24] hmm, found it, yeah, got it [09:24] i'd like to land this but i'd be happy to look at that next [09:24] sure [09:28] ok [09:28] incremental diff posted - should be ok but will you have a quick look? [09:30] * vila reading [09:35] poolie: hmm, why not just self.to_exact_file = to_exact_file in LogFormatter.__init__ ? [09:35] and callers will fail if they try to use it without setting it [09:37] jelmer: hi :) [09:38] (phone) [09:39] * vila cries, vbox's bug is making scroll wheel unusable :-( [10:00] heya [10:01] hey vila :-) [10:01] 'moin bialix [10:02] moin jelmer! [10:02] bonjour vila! [10:02] hi bialix [10:04] escudero going down soon [10:28] * shyam_k trying out loggerhead [10:28] but gets the message "internal server error" as i try 127.0.0.1:8080/ [10:29] http://pastebin.ca/1706723 thats what "./serve-branches ~/Scheme" says where i have bazaar set to ~/Scheme [10:32] what is wrong here? i just untarred the logger head source and ran that command [10:32] as said in its README [10:35] ./serve-branches ~/Scheme/.bzr shows the directories inside the control directory but not the files.. [10:36] ah ic.. thats just the response it gives for any random directory.. [10:43] vila: should i send it? [10:45] poolie: hmm, why not just self.to_exact_file = to_exact_file in LogFormatter.__init__ ? [10:45] and callers will fail if they try to use it without setting it [10:45] you didn't answer that :) [10:46] but anyway, if the actual patch works and given it has already been approved, I don't want to delay it further, if you have enough info to do another submission, please land that one [10:46] mm [10:46] misguided conservatism [10:46] and replace some commas by periods in the sentence above, its unreadable :) [10:47] mm, from me or from you ? [10:47] me [10:47] leaving the old path [10:48] k [10:48] almost 10 [10:48] will fix that and send it tomorrow [10:48] poolie: excellent [10:48] enjoy your night ! [10:49] hmm, is there some example somewhere to use pqm for remote branches > [10:49] s/>/?/ [10:49] no [10:49] i couldn't work it out [10:49] LOL [10:49] ping spiv for some docs? [10:49] i meant to do that [10:50] spiv: your patch to pqm is great !!!! [10:50] spiv: Please add doc so all patch pilots can enjoy it ! [10:50] :D [10:52] what i am trying to do is to see a web frontend of my local bazaar files.. [10:52] bzr serve said its listening on port 4155 but then localhost:4155 just goes on "Transfering data from localhost.." [11:11] poolie, spiv: So the trick is to specify --public-location and --submit-branch and have a locations.conf setup so that it provides pqm_email... a bit tortuous [11:12] oh, and use http: not lp: [11:12] and --ignore-local [11:13] and then... it just works :D [11:15] i'm trying to checkout the grub trunk from savannah, but bzr [11:15] complains it's not a branch [11:15] how does one check it out ? [11:38] hey [11:39] anyones awake ? [11:41] vila: yeah [11:42] vila: I basically just hacked until it did just enough to work and then went back to doing something more directly productive [11:53] sepult: if it complains, it means you're not using the right url [11:53] spiv: yeah, I can understand that, but a one line example in the readme or somewhere would have addressed that ;) === weigon_ is now known as weigon [12:24] is Ian Clatworthy here? [12:24] or someone who manages feeds? [12:24] igc: You have a customer. :D [12:24] a post from Ian C is messed up, it has an empty URL for the article link. [12:25] Yeah, that's been going on for a while. You can go to http://bazaarvcs.wordpress.com/ directly. === jelmer_ is now known as jelmer === Toksyury1l is now known as Toksyuryel === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:36] poolie, spiv: I knew I read a working example somewhere: bug #487458 [13:36] Launchpad bug 487458 in bzr-pqm "lookup email target on the target branch not the submitted branch" [High,Confirmed] https://launchpad.net/bugs/487458 === NETabuse is now known as NET||abuse === MvG1 is now known as MvG === thunderstruck is now known as gnomefreak [16:05] If I'm making small changes in the docs to fix bugs (mostly just broken links) should I be putting something in the NEWS file? I haven't been, but I wasn't sure what should go in there. [16:27] rubbs: just file a merge proposal and reviewer or patch pilot will help you with this question [16:34] bialix: ok thanks, should I do something about the ones that were already merged? [16:34] rubbs: no, if they're merged you can forgot about 'em [16:35] if you don't plan to continue improve them of course [16:37] rubbs: The rule is that bugs are mentioned in NEWS when they imply a "significant" change in bzr usage, doc is a bit different but sometimes fixing a broken link can change the whole experience... [16:37] rubbs: so use common sense and do as you feel, the reviewer can still disagree if needed :) [16:40] vila: cool thanks a lot. that helps. That also means I've been correct so far as well. [16:40] rubbs: sure ! [16:40] rubbs: you could put one NEWS item that summarised the improvements, possibly with the list of bugs [16:40] rubbs: anwyay, the meta-rule is: when in doubt, ask the question in the cover letter [16:41] vila: james_w: cool, will do in the future. Most of my changes have been rather small nearly trivial stuff so far, so no need to add to NEWS [16:42] IMO, enough trivial changes can add up to something NEWSworthy. [16:43] maybe what I'll do is find all the doc bugs that have been done in the last few weeks and add them in (since the bzr-doc team has been created) [16:44] under a "various bug fixes" heading or something [16:44] It might be too much to list all the bug #'s even. [16:55] morning all [16:57] hi jam [16:57] hi bialix [16:58] jam, can you suggest some tool to log memory consumption of the linux system? [16:59] I need to log it to file, not to GUI [17:00] bialix: you might check 'trace.debug_memory()' [17:01] bialix: I also have this script: http://paste.ubuntu.com/337403/ [17:01] which spawns a command that you specify [17:02] and then sits and polls the memory consumption every N seconds [17:03] bialix: another hackish way to do it might be to use the 'free' command in a shell script like: watch -n 1 free >> log.txt [17:04] not sure how well that would work though [17:04] ok, I'll try to experiment with this, thanks guys [17:05] bialix: np. good luck! === ivan is now known as Guest2304 === deryck is now known as deryck[lunch] === Guest2304 is now known as ivan === ivan`` is now known as ivan === ivan is now known as Guest3951 === Guest3951 is now known as ivan === deryck[lunch] is now known as deryck [18:37] anyone know why t.path2id would return an id, but t.get_file_text(that_id) would say NoSuchFile? [18:37] symlink? [18:46] james_w: file deleted on disk but not removed via the api? [18:47] oh, this is a revision tree I think [18:47] or directory [18:47] thanks [18:48] also, I currently have a long running bzr process [18:48] `I usually think of NSF being for a physical file that we failed to read [18:48] not a missing file in a tree [18:48] strace appears to show it opening the dirstate and reading it, then copying some working tree files to limbo then repeating [18:49] any idea what it it might be doing? [18:49] it is a large tree [18:49] if you are looking at a symlink or a directory, I would expect you to get back an empty string for the content [18:50] from what I can see [18:50] james_w: if you are opening dirstate, then it isn't a revisiontree [18:50] james_w: do you have the traceback? [18:50] oh, two issues [18:51] http://launchpadlibrarian.net/35785267/merge-issue is the traceback for the NSF [18:52] ah, hmm.. I missed the translation [18:52] RevisionNotPresent => NoSuchFile [18:53] james_w: can you drop into the debugger, and give me the output of "pp repo_desired_files" ? [18:53] hmm.. I guess it is supposed to be [('changelog-20090616010821-kgsodu5lhwu5pm2i-145', 'james.westby@ubuntu.com-20090905094641-seag0w0dagb6q3m1') ] [18:53] so... [18:54] my best guess right now is that you have corrupted data [18:54] something thinks that its text should be found at X, but X isn't present in the repo [18:54] i certainly can't guarantee that [18:56] maybe it's just bzr-builddeb looking in the wrong repo [18:57] no, that's not it === Loginx is now known as Linkadmin [18:58] vila: ping for great justice [18:59] james_w: well the line: fix_ancestry_as_needed [18:59] concerns me [18:59] given that it looks like you are doing surgery on stored data... [18:59] I don't think it means what you think it means :-) [18:59] inconceivable [18:59] :) [18:59] granted, using ancestry to mean two things is likely to do that :-) [19:00] ok, your suspicion of corruption may be correct [19:00] % bzr branch lp:debian/sid/cwidget debian [19:01] I'm running Loggerhead 1.17, is there something I'm missing about getting the syntax highlighting support enabled? [19:01] bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('column_definition.cc-20090616010821-kgsodu5lhwu5pm2i-43', 'james.westby@ubuntu.com-20080120093711-23aliq7ki0te4l21')") [19:01] jam: NACK, dinner time, I'll read the logs and be back later (if time permits) [19:01] hi vila [19:01] eric_f: do you have pywotsit installed? [19:01] vila: just thinking about trying to get a win32 host running from babune again, and thought I'd chat with you about it. [19:02] can wait till tomorrow [19:02] eric_f: or "pygments" as it is more commonly known? [19:02] james_w: probably not, is that the answer? [19:02] I think that's the library used to do it [19:02] james_w: can that be installed via aptitude? [19:02] I think so [19:02] eric_f: python-pygments [19:02] eric_f: apt-cache search pygments [19:03] eric_f: Should start working automagically once you install Pygments and restart Loggerhead. [19:05] james_w, Peng, & jam: thanks! That all worked [19:08] vila: also, wondering the status of fixing the selftest is broken on win32 stuff [19:08] I'll put together a patch if you can't, at least for the "test suite should run" part [19:32] jam: sooo, I couldn't work on bug #492561 today but first thing tomorrow ! [19:32] Launchpad bug 492561 in bzr "Seftest fails to start on Windows" [Critical,Confirmed] https://launchpad.net/bugs/492561 [19:33] vila: I already have a patch that at least lets "bzr selftest" run [19:33] I'm putting it up for review now [19:33] It doesn't fix the failure [19:33] but at least I can get a failure :) [19:33] jam: I too thought about adding a win32 host to babune *but* babune is acting like crazy these days [19:34] jam: yeah, I saw your patch, you're right, put that up for review but let's leave the bug open [19:34] sure [19:34] I'll start from that anyway [19:35] I'm quite sure the failure is closely related to the ones I have from PQM or under emacs depending on details. The crux is that we lack tests :-) But it's damn hard to test these things :-/ [19:35] Let's have a call tomorrow, there are other things I like to discuss too anyway. Deal ? [19:35] jam: ^ [19:36] * vila hears family calling again [19:37] vila: sure [19:37] vila: enjoy yourc family time [19:37] your [19:38] vila: if you get a chance to approve: https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-win32-test-imports/+merge/15829 === EdwinGrubbs is now known as Edwin-lunch [20:50] hi, I've got this error message: bzr: ERROR: The method _generate_inventory is not supported on objects of type CHKInventoryRepository. [20:51] I can't find anything on the web about it [20:51] does anybody know what it means? [21:05] this is what i've done: i've splitted a subtree of my branch using the following commands (say 'trunk' is the main branch and 'foo' is the subtree to be splitted): [21:05] cd trunk [21:05] bzr split foo [21:05] cd .. [21:06] bzr join —reference trunk/foo [21:06] bzr commit [21:07] now, whenever i add a file to trunk and try to commit, or whenever i try to revert a change in trunk i get [21:07] bzr: ERROR: The method _generate_inventory is not supported on objects of type CHKInventoryRepository. [21:08] i'm using bzr 2.0.1 and my repository format is 2a [21:08] druido: I'm pretty sure that 2a format repos *don't* support subtrees [21:08] so you can't join --reference in them [21:09] I'm a bit surprising it isn't failing earlier with a 'supports_subtree' check [21:09] ah, ok, in fact that command didn't seem to have any effect [21:10] is it possible to change the format to fix the problem? [21:13] i've repeated the steps again right now, with a new repository and it works as i've explained [21:15] (of course, i forgot to add 'cd trunk' before 'bzr commit' in the steps above) [21:29] ok, here is a minimal set of commands to reproduce my problem: [21:29] bzr init-repo foo-repo [21:29] cd foo-repo [21:29] bzr init trunk [21:29] mkdir trunk/foo [21:29] bzr add trunk [21:29] bzr commit trunk -m "Added foo." [21:29] bzr split trunk/foo [21:29] bzr join --reference trunk/foo [21:29] mkdir trunk/bar [21:29] bzr add trunk [21:30] It seems that, without bzr join, the above works ok [21:30] The problem is, I have given that command, and I've got no error :( [21:30] jam: passing around, https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-win32-test-imports/+merge/15829 approved with minor tweaks [21:32] jam: and to clear any ambiguity, adding a win32 host is high on my list and I agree that any regression in the test suite there is as critical as anywhere else (but I've yet to re-activate the OSX slaves :-/) [21:33] druido: without 'bzr join' bzr add of a sub branch is a no-op, I believe [21:34]