[08:00] morning! [08:01] mgz: hey ! [08:01] mgz: already read your proposal for paths from env, will review shortly [08:04] thanks vila [08:42] mgz: done, update pending, will reboot shortly [08:45] thanks vila! [08:46] mgz: thanks to you, that proposal is really good [09:13] jelmer: so you fixed bug #pipi :) [09:14] jelmer: wait, no, you finished the fix from Riddell (the bug number is still funny though ;) [09:15] ...isn't LGPL entirely pointless for python? [09:16] no idea [09:16] mgz, jelmer : standup ? [09:16] standup now if jelmer's around would be good, I need to nip out over lunch [09:17] k, let's see when he comes up [09:19] jelmerctl start [09:19] jelmerctl alarm ring [09:22] hi vila, mgz [09:22] It Works !!!! [09:22] I'll be right there [09:22] :) [09:23] :) [09:28] jelmer, mgz: pad created, ready when you are [09:32] mgz: join us? [09:33] nearly with you, too many tabs to close [10:03] mgz, vila: bug 881142 [10:03] Launchpad bug 881142 in Bazaar "AssertionError: unversioned parent while creating working tree using pypy" [Medium,Confirmed] https://launchpad.net/bugs/881142 [10:06] hi http://paste.ubuntu.com/768793/ [10:06] I got this on precise just now [10:06] is this known? [10:14] mgz: ^ [10:14] zyga: please file a bug [10:14] zyga: we'll assign it to mgz :) [10:17] jelmer, will do [10:20] bug 903639 [10:20] Error: Launchpad bug 903639 could not be found [10:21] meh, private bug reports [10:21] jelmer, mgz: ^ [10:30] zyga: thanks [10:30] mgz: ^ [10:30] zyga: looks from the traceback like fallout from me removing some default options, should be easy to fix, thanks [10:31] mgz, this bug is highly annoying, I'd love to use a beta/trunk just to get rid of it [10:32] on the similar topic, when using bzr pressing tab for the first time takes a good 5-10 seconds to finish, have you seen this yourself? I think it's related to one of the foreign vcs plugins (perhaps svn, I did some digging around this a few months ago but my memory might be faulty now) [10:33] zyga: that's the hard disk cold cache, python loads a lot of stuff on startup [10:34] jelmer, I don't think so, it happens all the time throughout the day, it's not just pure disk cache (I can trigger this by going to another directory and pressing tab a few times) -- if anything it is related to a repository/working tree/branch [10:34] jelmer, and I'm 100% sure it does not happen if I get rid of all the foreign vcs plugins [10:35] (I remember this being x10-100 slower on windows when using a large repository) [10:35] anyway [10:35] separate bug [10:35] I can scratch my itch when tab works again [10:35] zyga: the foreign plugins only update a few dictionaries during bzr loading [10:36] zyga: so I'd be surprised if they actually have an impact on startup overhead [10:36] unless the bash_completion script is doing something weird [10:36] jelmer, interesting, I'll try to measure this sensibly if I can get tab complete to work [10:36] zyga: the issue there is I'm not sure which plugin has the problem option [10:36] jelmer, I'm 100% sure it's not as nice as you say, perhaps the interactions are less trivial than I thought [10:37] jelmer, but pure bzr was lightning fast on tab complete last time I've checked [10:37] mgz, I can help you track this down [10:37] mgz, is there a way to switch plugins on and off one by one? [10:37] vila: ^ [10:38] zyga: set BZR_DISABLE_PLUGINS=name1:name2:name3 in the environment [10:38] jelmer, ok, let's try this [10:38] jelmer, I'm getting plugin names from the output of `bzr plugins` [10:38] zyga: nevermind, I see what's going on here [10:39] oh [10:39] zyga: bash-completion is triggering the loading of all plugins [10:40] jelmer, It happens when I keep the 'git' plugin [10:40] jelmer, disabling it makes tab work [10:40] * zyga keeps digging [10:41] yup [10:41] okay, so, you can redo the bash-completion script sans plugins with: [10:41] only git seems to be affected [10:41] $ BZR_DISABLE_PLUGINS=git bzr bash-completion [10:41] mgz, this works [10:41] zyga: can you try with bzr-git trunk? [10:42] jelmer, sure, just a moment [10:42] do I need to get rid of the packaged plugin or will ~/.bzr/plugins take priority? [10:42] zyga: ~/.bazaar/plugins takes priority [10:42] good [10:43] this is controlled by BZR_PLUGIN_PATH [10:43] * zyga branches lp:bzr-git [10:44] jelmer, git trunk works [10:44] zyga: it works and it doesn't slow things down, or it just works ? :) [10:45] * zyga thinks that bzr needs firefox-style plugin compatibility system where plugins are NOT loaded if they are not marked as supporting certain version of bzr [10:45] jelmer, I'm just checking plain tab working [10:45] jelmer, let me check speed stuff now [10:45] zyga: we have that actually, but it's up to plugins themselves to sign up for that [10:46] jelmer, perhaps it would be saner to swap that responsibility [10:48] * jelmer files bug 903650 [10:48] Launchpad bug 903650 in bzr-builddeb "loads lots of modules in top-level of cmds module" [Medium,Triaged] https://launchpad.net/bugs/903650 [10:50] zyga: so, can run for each of those plugins in your list: [10:51] `bzr bash-completion --plugin launchpad >/dev/null` [10:51] mgz, sure [10:51] with 'launchpad' replaced in turn with a plugin [10:51] and see which one throws the error [10:51] (if any are very noticiably slower that's also interesting) [10:54] mgs, no crashes [10:55] all seem fast now [10:57] ...is that with any of the plugin envvars set? [10:57] I'm trying to work out which plugin I need to update, so I want the error :) [10:59] mgz, no, that's without any special environment [10:59] mgz, you probably want to look at the git plugin as I indicated above [11:00] ah, I did actually change bzr-git [11:00] so updating that would have been enough [11:00] * mgz wasn't following closely enough :) [11:02] yes, it seems to be enough [11:08] * jelmer will look at doing another bzr-git release [12:09] wgz: when you get back, down to 4 failures on babune's windows slave, expected or just lucky ? [12:11] Hi, I'm having a problem with a bzr repository of mine: [12:11] $ sudo bzr update [12:11] All changes applied successfully. [12:11] bzr: ERROR: An inconsistent delta was supplied involving 'gdm/failsafeBlacklist', 'failsafeblacklist-20101011211133-ux797y0aieyjrmnf-718' [12:11] How can I solve that issue? [12:12] johan: bzr version ? [12:12] vila: 2.4.2 [12:12] format 2a of the branch [12:14] hmm, better file a bug, we fixed some inconsistent delta bugs lately but 2.4.2 is recent enough to include them [12:14] you may try a 2.5 beta to be sure [12:14] do you know the ppa name in your head? [12:15] johan: also, .bzr.log will probably contain more detailed data that should help diagnosing the issue [12:15] vila: https://bugs.launchpad.net/bzr/+bug/855155 [12:15] Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [High,Confirmed] [12:15] less [12:15] oops :( [12:16] * vila blinks, kiko ? Is that you hiding behind johan ? You've got the *exact* same file reported in the error [12:17] including the file-id... [12:17] vila: I'm not kiko, but it's the same repository [12:17] hehe [12:18] vila: I added the relevant parts from .bzr.log to that bug [12:18] johan: did you try bzr repair-workingtree as suggested in the comments ? (Keeping a copy of .bzr/checkout/dirstate just in case ?) [12:18] johan: is that a public repo ? [12:19] vila: yes, I tried that, it does not work [12:19] ok, mention that in the bug report, that will help [12:19] ... others [12:19] vila: nope, it's /etc of a server I'd rather not expose the configuration in public for [12:19] hmm [12:20] anything special about this repo ? stacking ? [12:21] johan: can you paste bin an ls -lR of .bzr on paste.canonical.com ? (.bzr contains only bzr stuff, nothing confidential should be exposed by an ls) [12:22] just a sec, checking 2.5 beta [12:22] johan: and do you know if kiko find a way out for his own case ? [12:22] johan: sure, waiting [12:22] vila: it's the same case, we both maintain the same server [12:23] ok, 'bzr st' paste too ? [12:23] or is status already failing in this setup [12:24] maxb: 2.5b4 is out, could you update the beta ppa ? [12:24] vila: http://paste.ubuntu.com/768887/ [12:25] vila: and http://paste.ubuntu.com/768889/ for bzr st [12:25] g [12:26] gotta run, but I'll be back in 2h [12:27] johan: let us know when you're back [12:30] johan: just looking at your pastes, the first question that comes to mind is: is there a gdm/failsafeBlacklist in the tree ? [12:31] johan: the second one is: it's weird to see a file-id with '-20101011211133' and no pack file around this date (but may be it just get repacked into a more recent one), [12:32] the '-718' hints at a massive 'bzr add' (including at least 718 files) but that doesn't mean this get committed [12:33] johan: there are several things we can try to 1) get you out the problem, 2) better diagnose what is happending, but both need your hands ;) [13:00] I've got python-bzrlib 2.4.1-1ubuntu1 installed, but it doesn't come with bzrlib.tests. [13:00] Which is annoying, since I'm using code that depends on bzrlib.tests (lp:udd, fwiw) [13:20] jml: apt-get install python-bzrlib.tests [13:20] maxb: wow. thanks. [14:25] vila: there's no gdm/failsafeBlacklist in the tree [14:25] revisioned or not [14:26] johan: hmm, there was one at some point apparently [14:27] johan: what does 'bzr rm --keep gdm' says ? [14:27] johan: no wait, [14:27] johan: is 'gdm' still versioned (in itself or because other files into it are versioned) ? === yofel_ is now known as yofel [15:08] vila: gdm is versioned [15:09] gdm/failsafeBlacklist was versioned in revno 1 [15:09] $ sudo bzr rm --keep failsafeBlacklist [15:09] gdm/failsafeBlacklist is not versioned. [15:10] bzr log -p gdm|pastebinit - -> http://paste.ubuntu.com/769040/ [15:10] current revno is 306 fwiw [15:11] * vila scratches head [15:12] johan: what happens if you do 'bzr update' again ? [15:12] All changes applied successfully. [15:12] bzr: ERROR: An inconsistent delta was supplied involving 'gdm/failsafeBlacklist', 'failsafeblacklist-20101011211133-ux797y0aieyjrmnf-718' [15:12] reason: Unable to find block for this record. Was the parent added? [15:12] bzr missing ? [15:12] err, what does 'bzr missing' says ? [15:12] say even [15:13] Using saved parent location: /etc [15:13] Branches are up to date. [15:14] 'bzr info -v' ? [15:15] http://paste.ubuntu.com/769047/ [15:15] a different traceback [15:17] yup [15:17] 'bzr check' ? [15:17] could be long, heavily depends on revision graph size and repository size, but /etc.. shouldn't be that big [15:27] Checking working tree at '/etc'. [15:27] Checking branch at 'file:///etc/'. [15:27] Checking repository at 'file:///etc/'. [15:27] checked repository file:///etc/ format RepositoryFormat2a() [15:27] 347 revisions [15:27] 3288 file-ids [15:27] checked branch file:///etc/ format Branch format 7 [15:28] that's the output of bzr check [15:31] bzr: ERROR: The dirstate file (DirState(u'/home/lamont/foo/.bzr/checkout/dirstate')) appears to be corrupt: failed to find trailing NULL (\0). Trailing garbage: '\n' [15:31] is there a way to clean that up, I wonder? [15:32] lamont: "bzr repair-workingtree" might help [15:33] vila: the issue johan is running into sounds like a transform issue? [15:33] jelmer: what is that going to do to the working tree? [15:33] bzr: ERROR: unknown command "repair-workingtree" [15:33] lamont: its help probably describes it better than I can [15:33] lamont: it's a fairly recent command [15:34] lamont: another alternative is to rm -rf .bzr/checkout, and then run "bzr co" [15:34] but that might move some of your existing files that have changed out of the way [15:34] ew [15:35] * lamont starts with a backup [15:35] lamont: if you have lots of file metadata changes you care about, you have an issue, but just checking out the most last rev somewhere else and copying over the files in your tree would cover most things [15:35] jelmer: like a symlink -> dir issue you mean ? [15:36] lamont: or checkout somewhere else and copy the .bzr/checkout/dirstate only, then do 'bzr st' [15:37] I saved the tree did the rm/bzr co, and then did the rsync --exclude=.bzr to bring it all back. bzr st is now clean [15:37] I'm going to guess that we managed to reboot the machine in the middle of something in the way of a commit or so [15:38] lamont: sounds like a possible explanation [15:38] lamont: we never have such reports though [15:38] had [15:38] just during bzr st would be enough. dirstate isn't all that robust, but it's also easy enough to recover in most cases [15:39] vila: we had various ext4 reports, some of those were dirstate [15:39] mgz: really ? I can remember only repository related ones... But Alzheimer... [15:42] vila: IIRC repair-workingtree was added exactly for this reason [16:12] the mp for bug 898541 is sitting on its own crying, ever since it had a little blip from launchpad librarian dying... won't someone review him? [16:12] Launchpad bug 898541 in Bazaar " UnicodeEncodeError on mv of a deleted non-ascii file" [Low,In progress] https://launchpad.net/bugs/898541 [16:13] I'm really mad that I lost my text file with all my NULL_REVISION bug notes in it [16:13] must have put it under a branch that got rmrfed [16:14] spent a good half hour going through dupes and categorising failure types [16:32] bug 893495 again ;( [16:32] Launchpad bug 893495 in bzr-builddeb (Ubuntu) "Zero byte successful merge after error from dpkg-mergechangelogs" [Medium,Confirmed] https://launchpad.net/bugs/893495 [16:36] hrw: good (kinda), I wanted to look at that again and can't practically merge gcc locally [16:38] mgz: I'll have a look [16:38] this time I handled it with 'bzr diff -c72 >72.diff', extracting changelog.diff, applying it by hand and merging changes by hand [16:39] a good start would be to set BZR_PDB=1 and see what this_lines, other_lines, and base_lines are and how they get generated [16:41] ok, will branch, revert change and do merge again with this var set [16:46] from last time, with the right THIS OTHER and BASE the merge goes fine, so the problem happens before passing things off to dpkg-mergechangelogs [16:47] dpkg-mergechangelogs: błąd: ss-970814-1 is not a valid version [16:47] basically bug is same [16:47] I exported BZR_PDB=1 and then did merge - no extra log outputed [16:48] hm, but you didn't get the UnicodeDecodeError? I was relying on that to break into the debugger at a handy place [16:48] http://pastebin.com/nsWC2uLF is whole output [16:51] you still have my hack around that problem from last time? basically, I want to know what the merge_changelog.py sees for THIS OTHER and BASE so we know why it's generating 0 byte output (that's till the end symptom, right?) [16:51] shit. indeed. I forgot about it [16:51] that's fine [16:51] if you also remove the shutil.rmtree at the bottom of that file [16:51] it was in bzr-builddeb package? [16:52] that will leave the tempfiles that dpkg-mergechangelog is having problems with in place [16:52] ^yup [16:53] you can leave the hack around in, it's harmless [16:54] 17:53 hrw@puchatek:b$ bzr branch -r71 lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-native;cd gcc-linaro-ci-native;BZR_PDB=1 bzr merge lp:ubuntu/gcc-4.6 [16:54] this is all you need to reproduce [16:55] thanks hrw. [16:55] no problem [16:56] solving bug will help my work in ufutre [17:01] hrw: can you try this on your local bzr-builddeb? [17:02] vila: urhg, we're reading the user identity from a "email" file ?? [17:02] sure [17:03] it will be /usr/lib/python2.7/dist-packages/bzrlib/plugins/builddeb/merge_changelog.py file? [17:04] yes. [17:05] what I expect on the merge: the new message added should be output, and then in /tmp there'll be a dir with 'deb_changelog_merge' in it containing the interestingly broken changelogs [17:07] test in progress [17:16] changelog.base [17:16] http://paste.ubuntu.com/769169/ [17:16] changelog.other [17:16] http://paste.ubuntu.com/769170/ [17:16] changelog.this [17:16] http://paste.ubuntu.com/769171/ [17:20] those look not unreasonable, and `dpkg-mergechangelogs changelog.base changelog.this changelog.other > changelog` produces something reasonable? [17:20] 18:16 hrw@puchatek:tmpgUvyzWdeb_changelog_merge$ dpkg-mergechangelogs changelog.base changelog.this changelog.other [17:20] dpkg-mergechangelogs: błąd: ss-970814-1 is not a valid version [17:22] the warning/error about ss-970814-1 is expected, does it also fill out the changelog file? [17:23] ss-970814-1 exists as package version [17:23] looks like at 20 August 1997 it was valid version [17:23] right, it exists, but debian doesn't like it [17:24] for me, I get the warning but I also get a correctly merged 'changelog' output [17:24] no, bzr does not like it [17:24] when I 'LC_ALL=C' failure is same (but in English) [17:25] changelog is never generated here [17:25] okay. what does `dpkg-mergechangelogs --version` say? [17:26] Debian dpkg-mergechangelogs version 1.16.1.2. [17:27] dpkg-devii dpkg-dev 1.16.1.2ubuntu3 Debian package development tools [17:27] oh, I forgot to ask, when you ran the merge, did my new message print out after the old error? [17:28] Packaging branch status: CURRENT [17:28] dpkg-mergechangelogs: błąd: ss-970814-1 is not a valid version [17:28] Successful merge, but empty file? Dodgy... [17:28] if so, there's a simple enough work around in bzr-builddeb that will help you. [17:28] so yes, it did [17:28] yeay, okay, will fix today. [17:28] übercool [17:29] first, I'll work out what they broke in the newer dpkg versions that's causing things. [17:30] *this [17:32] `bzr branch apt:dpkg` ... is still really neat [17:34] thanks [17:34] * hrw -> off [17:43] ...then bzr-git nearly OOMs me to death [17:45] let's manually delete some caches and see if it can finish [17:47] mgz: what are ou trying to branch? [17:47] dpkg [17:47] (Pdb) self._group_cache._value_size [17:47] 44979584 [17:47] bye bye [17:49] hm, that didn't get me my 50MB back, needed to chase refs [17:52] ...will have to give in for now and cancel to do incremental pull [17:55] hah, commit over lightweight checkouts with pure HPSS \o/ [17:55] ehehe [17:56] urk, git:/ doesn't support -r incremental pull? [17:56] mgz: nope, because you can't introspect the revision graph remotely [17:56] okay, I'll just have to get the packaging branch rather than upstream I guess [17:57] most of that mem usage was probably overhead, pulling from git to bzr shouldn't need local groupcompress caches === supton is now known as supton|coffee === supton|coffee is now known as supton [18:43] that was a pain, but I have repo. [18:43] `PERL5LIB=~/.local/share/perl5 ~/.local/bin/dpkg-mergechangelogs` [18:48] jelmer: what email file ??? [18:51] vila: doesn't die in perl get you somehting other than 0 as a return code? [18:51] mgz: not fully sure but it should [18:52] mgz: on the other hand I think I remember than die can be caught... [18:52] oh, oh, whoops [18:53] the logic is bzr-builddep is `if retcode == 1: ... else: # assume all is well!` [18:53] -p+b [18:53] mgz: yup, man perlfunc says: ptrints LIST to "STDERR" and exits with a non-zero value. [18:53] geee [18:53] I managed to make tyops while pasting... [18:54] :D [18:54] anyway, that's followed by: If you need to exit the process with a specific exit code, see exit. [18:56] so, not dying on bad version numbers would be nice, as it doesn't in my older dpkg version, but this is nice and fixable in builddeb [19:15] johan: still there ? [19:23] vila: see bzrlib/config.py [19:23] vila: we try to read the user identity from .bzr/branch/email [19:24] ooooh, in the good old days you mean, not now ? [19:24] vila: we still do [19:24] vila: config.py:1400 [19:25] ;_; [19:25] jelmer: this is broken for remote branches right ? [19:26] jelmer: this code should die and nobody should ever talk about it anymore [19:26] vila: hehe [19:27] vila: it's not broken for remote branches, it works [19:27] Sounds like we need the ability to edit history :p [19:27] vila: but it triggers VFS access [19:27] jelmer: and who is able to create this file ? [19:28] vila: "echo" ? :-) [19:28] vila: we have tests that it still works [19:28] vila: but I'm all in favor of killing it, too. [19:28] * vila bangs head [19:29] decoded with user encoding though :) [19:29] I'm off, it makes me cry too much :) [19:30] jelmer: sorry, by 'who' I was thinking about launchpad, you think it's allowed there ? [19:31] vila: I doubt anybody is using it, but launchpad does allow creating that file. [19:32] yeah, same here, I doubt anybody even knows about it (I'm sure I've seen this code but I managed to forget until you mentioned it ! Shame on you ! ;) Too bad lp allows it to be created... [19:34] * vila really off === Quintasan_ is now known as Quintasan [19:44] Hi - is there a way to import a branch from repository X into a sub-directory of repository Y and keep the history of those files from repo X? [19:46] thomi: "bzr join" ? [19:46] * jelmer heads out [19:48] jelmer: it seems like that only works for branches from the same repo? [19:48] No, it works for any two. [19:49] "from the same repo" doesn't really mean much anyway. [19:49] hmm, when I try, I get this: [19:49] NoSuchRevision: CHKInventoryRepository('file:///home/thomi/code/unity/.bzr/repository/') has no revision thomir@gmail.com-20111208204500-9v1r9owjaz1qu6aa [19:49] I must be doing it wrong ;) [19:50] What command are you running? [19:50] bzr join subdir [19:51] Well, that's a new one in me. [19:51] Which branch is that rev from? [19:51] the target branch - i.e.- the 'subdir' [19:52] hmmm, I might try this with clean branches, see if I can reproduce it.... one second [19:53] Mmm. Works in a trivial example I tossed together, with 2.4.2 and .dev. [19:54] yeah, it works for me when I start from scratch... [20:13] fullermd: filed bug: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/903906 [20:13] Error: ubuntu bug 903906 not found [20:28] hi jelmer, life [20:29] hi Noldorin [20:29] I have to admit, no lifeless on IRC would surprise me too :) [20:29] jelmer, haha yeah. curse him for making me tab-fail. [20:29] how's your work going anyway? [20:30] hacking on HPSS, going well :) [20:30] with a bit of luck bzr 2.5 won't need any VFS calls anymore for normal operation [20:32] jelmer, not familiar with HPSS. is it like software raid? [20:32] or a protocol maybe [20:32] ? [20:33] Noldorin: high performance smart server [20:34] mwhudson, not storage system? wikipedia tells me this :-S [20:34] hmm [20:36] Noldorin: high performance smart server [20:37] what does it do? :-) [20:37] Noldorin: it's what powers bzr+ssh [20:37] Performs highly. [20:38] heh [20:38] fullermd, always a help :-) [20:38] * fullermd is a helper! [20:52] jelmer: what's traditional to do if I want to get something changed that has a debian upstream? [20:52] file a bug against debian? just post the patch to the relevent ml? [20:53] mgz: you mean something that is "debian native" ? [20:53] mgz: a good bet is to file a bug in the debian bts and attach a patch [20:56] ...the fun thing with that is the bug is not actually present on my system [20:57] I'm not sure how well reportbug copes with that [20:57] mgz: that's fine [20:58] mgz: it'll ask you whether you're sure you want to file a bug, but you can just answer yes :) [20:58] mgz: alternatively, you can send an email to submit@bugs.debian.org [21:38] bzr: ERROR: Could not acquire lock "(remote lock)": [21:38] jelmer, mgz any idea what this means ona bzr init? :-) [21:38] it's inside a symlink dir on windows [21:39] normal dirs work fine [21:39] not sure if it's to do with symlinks though... [21:39] or permissions or something else entirely [21:39] :-S [21:40] from inside cygwin? symlinks don't work gererally in bzr win32 certainly. [21:42] jelmer: still kicking? mind eyeballing a patch for me to see if I've done anything too stupid? [21:47] mgz, yeah, within cygwin [21:48] has to be to get ssh working heh ;-) [21:48] mgz: sure [21:51] jelmer: http://pastebin.ubuntu.com/769461/ [21:52] mgz, recommend any alternative for windows/cygwin if i want to specify a custom base path via bzr+ssh? [21:52] also, can i manually defien custom prefixes like lp:foo without recompiling bzr? [21:53] Noldorin: see the suggestions from the other evening, bzr-bookmarks is probably simpler than playing symlink games [21:54] mgz, how does that work though? [21:54] that's for [21:54] Debian bug 651993 in dpkg "dpkg-mergechangelogs fails if any changelog contains an invalid version" [Normal,Open] [21:55] mgz: try it and find out, it's not something I've ever needed [21:55] wait, that's me [21:55] mgz: oh perl.. joy :) [21:56]