[00:21] Crud [00:22] shelve ate my changes :( [00:22] i'm using loom, I shelved some changes, then did down-thread [00:22] after doing up-thread and reverting the files, unshelve complains that a file id doesn't exist in the tree [00:24] dash: :( [00:24] is there a way to read stuff out of a pack file [00:24] or partially apply this shelf [00:34] probably [00:34] that's great [00:34] i guess. [00:36] dash, I don't think there's a way to partially unshelve from the UI. [00:37] ah well, it's only 7 conflicts anyway, i'll just redo it and be careful this time. :) [00:55] dash: please file a bug [00:55] dash: on bzr [00:55] ok [01:03] Hey there. [01:04] It seems reviewboard 1.0 has some trouble handling patches whose base is not in the main history of a branch. [01:05] hello ddaa [01:05] Here, I'm submitting reviews with diffs produced by merging repo/feature into repo/trunk, and I base them in reviewboard on repo/feature. [01:06] It works okay the first time. Then I have a branch "cowbell" which gets an additional commit for review fixes, [01:07] Then "cowbell" is merged to trunk (where a conflict is resolved). And a branch "moreso", initially based on "cowbell", merges trunk back. [01:07] Then I cannot find how to give an updated diff to reviewboard for the changes in "moreso" over trunk. [01:08] poolie: hello pal [01:08] So, anyone here has experience with reviewboard and could help me? [01:09] poolie: What's up on down under? [01:11] ddaa: statik does [01:12] * ddaa takes a kitty and rubs it on statik [01:12] * ddaa loves to have fun with statik electricity [01:12] ddaa: I think he even wrote the reviewboard bzr stufff [01:17] * ddaa tries pushing to moreso a merge from moreso into trunk. [01:21] Nope, I get again "The file id "None" is not present in the tree I guess there might be a way to make it work by providing a parent diff, but in this case I have no idea what it should be. [01:24] Mh... I guess maybe statik in on the wrong hemisphere to be up at this time. [01:24] is there a bug tracker for the reviewboard bzr plugin [01:24] ? [01:25] there's probably launchpad [01:26] actually, it seems not [01:26] I guess it's sharing bug tracker with reviewboard itself. [01:28] lifeless, can you please create a pqm-managed branch for the 1.17 rc? [01:28] or maybe http://doc.bazaar-vcs.org/bzr.dev/developers/cycle.html needs to be updated to say 'ask a losa'. [01:35] lifeless: I'm producing the diagnostic data you asked me a few weeks back. [01:36] The throughput appears to be a bit better now with 1.16.1 on both sides. [01:36] But it's still very variable. [01:37] no clear stalling though [01:38] much better, 4m9s real time [01:39] Comparing now to an upload of a tar of the .bzr in the repo [01:44] scp of tar of .bzr, 4m39s real time [01:44] meh... it's actually slower than bzr push [01:45] my uplink officially sucks so much they could it in the LHC [01:46] lifeless: so nothing to see, bzr push in 1.16 with 1.9 format repo is as fast as uplink. Maybe it was a temporary internet problem, or something to with the structure of the repo just after fast-import runs. [01:47] I guess you are not interested in the -Dhpss log then. [02:02] jml: it should say losa preferentially [02:34] hullo jml [02:34] ddaa, things are good here [02:34] barcelona was nice [02:34] ddaa has logged :P [02:39] ah, i have that squelched in irssi [02:39] too noisy otherwise [03:10] verterok: https://bugs.eclipse.org/bugs/show_bug.cgi?id=282226 [03:10] bugs.eclipse.org bug 282226 in CVS "CVS feature abstraction" [Enhancement,New] [03:56] * spiv -> lunch === NfNitLoo` is now known as NfNitLoop [04:31] abentley: ping [04:31] abentley: nm [04:48] hello thumper [04:48] hi poolie [04:48] * thumper wishes quassel was smarter with tab completion [04:50] thumper: hi. [04:50] abentley: I was just wanting a reminder of the bzr send command to send relative to the pipe below, but I found it in my command history [04:50] bzr send -r branch::prev.. for those interested [04:51] thumper: It's also in "bzr help pipelines". [04:51] s/pipelines/pipeline [04:52] thumper: Well, the version for diff is. [04:52] abentley: right, that is what I wanted [05:10] thumper: glad you like the idea [05:10] thumper: it came out of a discussion with poolie about 'targetting' reviews [05:10] thumper: I'm very keen to mae it easy for people to get engaged without us having to know a-priori who they are === poolie_ is now known as poolie [05:24] args [05:24] (Pdb) locals()['args'][1] [05:24] AssertionError(u"path_utf8 is not a str: base/\u65e5\u672c\u4eba",) [05:24] (Pdb) str(locals()['args'][1]) [05:24] *** UnicodeEncodeError: 'ascii' codec can't encode characters in position 46-48: ordinal not in range(128) [05:24] so [05:24] test suite epic fail [05:24] another reason not to raise AssertionError - it won't always format sanely >< [05:33] Yeah, exception formatting in Python isn't perfect. [05:34] thumper: I'm thinking the "take-changes" command we talked about adding to pipeline should actually be "merge --interactive", i.e. part of core. [05:34] abentley: but I only want text changes not any merge revisions [05:35] as long as it does that [05:35] I'd be happy [05:35] thumper: when we do partial merges, we don't set pen ding merges, if that's what you mean. [05:35] s/pen ding/pending [05:35] what about an interactive merge that takes everything? [05:36] I'd love to see that [05:37] I did a hacky one for bzrtools but never wrote enough tests to get it accepted ;P [05:37] thumper: it could ask about full merges [05:37] thumper: well, the theory is that it would set pending merges. [05:37] thumper: why don't you want merge revisions though? [05:38] (we plan to eventually record partial merges too, in some fashion, to aid reporting of cherrypicks) [05:39] abentley: jml has work in progress for a cleaned up merge interactive I believe [05:39] There's always bzr revert --forget-merges if you really don't want merges recorded. [05:40] jml: did you get the branch made? [06:05] lifeless: those decorator generators are kind of cute [06:05] maybe almost too cute [06:07] poolie: we have many delta appliers [06:07] I was hoping to structure things to allow reuse [06:08] they could be structed as 'here, check this list', but that then requires that we have a list [06:14] mm [06:15] so you could have an explicit 'fan out this iterable' function [06:15] there may be one in itertools? [06:15] which calls some things for side effects and then yields the results of the original iterable [06:15] this is essentially just to split out the 'for thing:... yield thing' from those functions [06:15] to make it clear they don't change [06:16] but i'm not sure that's much better [06:16] anyhow, +1 [06:18] thanks [06:18] I have the test fallout fixed [06:20] http://pastebin.ubuntu.com/214176/ [06:20] k [06:20] if you could eyeball that [06:20] i'm going back to bug 391411 [06:20] Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411 [06:20] oh ok [06:20] I just got that done before saying 'thanks' ;) [06:21] it corrects a couple of bugs in the validation code I added by testing against unicode entries, and cleans up some other tests that were expecting a different interface [06:22] and removes a doctest error case that really wasn't very helpful where it was. I did some doc cleanup at the same time. [06:22] so in the 'parents = set()' thing [06:22] can you explain in the comment which parents will be in this list [06:22] sure. Its all of them. [06:22] all in the whole dirstate? [06:22] ok [06:23] all in the delta [06:23] we don't know parents for removed items [06:23] I'll add some text [06:24] maybe change dirname and basename to dirname_utf8 and basename_utf8, as they seem to be [06:24] roger [06:24] will do the same in check_parents too [06:27] poolie: anything else? and I'll let you get back to 391411 [06:31] still reading [06:32] looks good [06:32] thanks [06:33] i might put up a patch sometime that renames the other directories to per_workingtree etc [06:33] spiv, in bug 391411 i'm thinking about how to do reconfigure --unstacked to an hpss branch [06:33] Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411 [06:34] it needs to fetch from the fallback repository into the to-be-unstacked one [06:34] poolie: I would like that; making them consistent again would be nice [06:35] i think, unless you know something really clever, i need a new Client [06:35] do you know a tasteful way to get one? [06:35] k [06:35] SmartServerClient? [06:36] they are coupled to the transport; the most robust way would be 'b2 = bzrlib.branch.Branch.open(self.base)' [06:39] yeah [06:40] that's what i had in mind too - we don't implicitly share by url, so going back to a url should force a new connection [06:40] I think you should be able to solve this without writing specific code in remote.py at this point in time [06:42] i think so too [06:43] as i said on the phone it would almost be possible to do it over one connection [06:43] but simple=good [06:45] I suggest a comment about the rationale [06:45] for review streamlining :) [06:46] poolie: yes, I think you need a new client, well a new medium really... [06:47] poolie: It might be nice to have a method on _SmartClient that can make a new connection for you, but as lifeless says taking the URL and constructing a new transport from that will work. [06:57] How do I change the user to checkout stuff with? [06:57] GungaDin: what do you mean? [06:58] my account user is X and I'd like to checkout from the repository as user Y. [06:58] over ssh? [06:58] you can put Y@ into the url [06:59] if its launchpad however, you should use groups to manage this sort of thing, rather than impersonation [07:03] yeah, alright. [07:03] it's working now. [07:03] thx [07:03] happy to help [07:09] poolie: EOD; ciao [07:10] well, nearly [07:10] ringing jml first [07:23] cheerio [07:35] hi all [07:41] hi vila [07:44] hey poolie ! [07:50] vila does bug 397716 ring any bells with you? [07:50] Launchpad bug 397716 in bzr "timezone-dependent annotation test failures" [High,Confirmed] https://launchpad.net/bugs/397716 [07:51] hmm, indirectly yes [07:51] it's "It's yesterday in California" again :) [07:52] again :) [07:52] so, I think there is a TZ arg somwehere that can be used (it was the case for log, not sure for annotate) [07:53] arguably we should just set it in the tests for the sake of isolation [07:53] however i think in some environments setting it after the program starts is not enough [07:55] I think the case you're encountering is only relevant in tests (it was the case for log when I saw that), if I'm not mistaken the problem here is that the TZ is not used coherently between commit and annotate, you can't do that from command-line [07:56] * vila . o O ( TZ... Yet another interesting test farm variation...) [07:58] wow, 'tranche' is used in English ? [07:58] yes [07:59] And it applies to ham as well as building houses ? [07:59] lol [07:59] :) [07:59] it mostly applies to finance actually [07:59] but it would be a nice word to use for ham [08:00] where did you see that? [08:00] bzr.dev@4524 commit message :) [08:00] no connection to money here :) [08:02] "a portion of something " says my gnome-dictionary-applet... The french word come from "trancher" i.e. cut with a knive or sword, so I think literal translation should be slice :) [08:02] yes, i was just going to say that [08:02] i guess with the connotation that, perhaps, you eventually intend to eat all of it [08:03] Really ? Interesting, not the case in French :) [08:03] Did somebody say 'eat'? [08:03] * fullermd perks up. [08:03] mm, actually i do think that's why you'd use that word specifically [08:04] that there are a small finite number and you expect them all to be taken [08:04] well, it's really used for ham and you really don't want to eat a full ham, 2 tranches, maybe 3 but no more :-) [08:05] ha, yes, the set of tranches is expected to be all eaten :) [08:05] * fullermd thinks you underestimate his stomach for swine... [08:06] * vila wonders what happens when you feed fullermd after midnight.... [08:07] * poolie gets undistracted [08:07] That's where adjusting TZ helps, see ;) [08:07] poolie: regarding bug 3977716, looking at test_annotate it looks like the timezone parameter get lost in the refactoring, good diagnosis [08:07] Error: Launchpad bug 3977716 could not be found [08:11] what.. too much 7 ? Can't you just fix such obvious typos on the fly ? Come on... bug #397716 [08:11] Launchpad bug 397716 in bzr "timezone-dependent annotation test failures" [High,Confirmed] https://launchpad.net/bugs/397716 [08:15] poolie: I can reproduce the bug, are you working on it or should I assign it to me ? [08:15] i'm not now [08:15] i'm trying to finish 391411 before s gets home :) [08:16] poolie: ok, go ! [08:16] poolie: interestingly, wiktionary has the finance definition as the 2nd meaning [08:17] begone, forces of distraction [08:17] its friday [08:17] friday night [08:17] :) [08:17] yeah, they are stronger :) [08:18] well, it is the more specific use [08:18] i think it's also the place you most commonly see it [08:18] * vila just feels the difference since he changes its TZ to utc+10... [08:18] nothing wrong with your use of course [08:38] * vila blesses the one who removed ctrl-alt-backspace *default-and-hard-to-get-rid-of* shorcut that used to kill the X server, thank you, thank you, thank you [08:38] vila: why lol? :D [08:39] don't be silly, shooting xserver is cool [08:41] pygi: because the shorcut was too close to alt-backspace which I use a lot and killing my X server without confirmation (yeah I know, non-sense, but yet) and bringing down my http client, mail client, chat client, bunch of emacses just because I mystyped 'delete-word-backwards' is a not excessive for my taste [08:41] s/not/bit/.... some typos... are... not understandable :) [08:45] * vila looks its keyboard... yes io and bn are contiguous on qwerty... clap-clap-clap, well seen big brain :) [08:45] s/its/his/ [09:01] that was quick :) [09:29] poolie: still there ? Regarding lp:~mbp/bzr/trivial into lp:bzr, let me know before leaving if you want me to do the tweaks and merge [09:47] hi [09:47] i am [09:48] i think i fixed 391411 [09:50] thanks for reviewing it [09:51] oh you didn't need to spend so long making all those dittos [09:52] i probably should leave so if you'd like to sort them that would be nice [09:53] i actually have mixed feelings about sorting them as part of an otherwise-mechanical change [10:10] poolie: you actually have or had ? The intent of your patch is to be more coherent in naming IMO, that's good reason to *not* break another convention :) [10:10] :) [10:10] have [10:10] just in having less risk of breaking things [10:11] but you're probaly right [10:11] ha ! That should be guarded by a full test suite passing :) [10:16] :) true [10:16] ok, good night === sabdfl1 is now known as sabdfl [12:01] hi, i'am completely new to bazaar and version control system. One thing i don't understand from the manual. I want to ignore to directories completely by "bzr add" [12:01] as i understood correctly i can use .bzrignore for this task. I tried for example "org_icons/*.*" but still files in that directory will be added. Where do i have to put the file ".bzrignore"? thank you! [12:05] .bzrignore goes in the root of the tree. [12:06] And you probably want 'org_icons/*' more, though I guess it likely doesn't make a huge difference in this case... [12:14] Hi, i just ran bzr upgrade on my repo and now I get this -> bzr: ERROR: The branch lp:do-plugins has no revision None. [12:15] fullermd. ok i think i got it [12:15] thank you [12:16] this is mm .. kind of serious [12:23] wtfff I can do a merge frm lp:do-plugins but i cant branch [12:27] lamalex: I can branch lp:do-plugins without problem from here, what bzr version are you using ? [12:28] vila: really? [12:28] what does bzr info -v say for you? [12:28] lamalex: do you always reply to a question by another question ? [12:28] vila: almsost always [12:28] Bazaar (bzr) 1.16.1 [12:29] with bzr.dev I got a repository: Packs containing knits without subtree support, branch format 6 [12:30] and the remote branch has the same repo/branch characteristics [12:30] hmm... what the hell [12:30] i just bzr upgraded it to 1.6.1-rich-root [12:30] so that's pack-0.92, it's pretty old now, what did you upgrade from ? And when ? [12:30] and now I can't branch, but you can, and you have the wrong format [12:32] lamalex: ha, we are not seeing the same branch then, certainly due to the fact that you have write access, so I still see the old one because it hasn't been mirrored yet [12:33] i wonder what wnet wrong [12:33] * lamalex restores backup [12:33] what is your .bzr.log saying ? [12:34] vila: http://paste2.org/p/314256 [12:35] 1) try without --stacked, 2) try with bzr.dev [12:35] ive tried without --stacked [12:35] same thing [12:35] will try bzr.dev [12:36] wwait what is bzr.dev [12:36] with and without --stacked (although if you have a local mirror using --stacked doesn't gain you much compared to a shared repo) [12:36] bzr.dev is lp:bzr [12:36] lamalex: what OS are you using ? [12:37] ubuntu 9.04 with bzr ppa [12:38] hmm, I can try to help you setup bzr from sources but you may prefer switching temporarily to the nightly ppa [12:38] i just reverted it to the pack-0.92 [12:39] going to try this again.. [12:39] is there anything special i should know aobut upgrading? [12:39] i've gotta be doing something wrong [12:40] what did you do ? Why did you chose 1.6.1-rr instead of say --1.9-rr ? [12:40] or even 1.14-rr or --default-rr ? [12:41] and why do you want to upgrade to start with ? :-) Mainly curious but it may help understand the issue... [12:42] we want stacked branches [12:42] locally or on lp ? [12:48] and we chose 1.6.1-rich-root because I think it was the greatest that jaunty bzr supported [12:48] vila: on lp [12:49] would you say not to use 1.6.1? [12:49] hooo, yes sorry, so used to ppas, I forgot about the version shipped with jaunty, but are you sure it's 1.6 that sounds really old... [12:50] RAOF said 1.6, I didnt check myself. I trusted his opinion on 1.6.1 [12:50] http://packages.ubuntu.com/jaunty/bzr says 1.13 [12:51] RAOF ? [12:51] a person [12:51] ha, ok :) [12:51] does our packaging, is generally more or less knowledgable about things like this [12:51] so you think we should do 1.13-rr [12:52] lamalex: no :-) that one doesn't exist but you can use 1.9-rich-root [12:52] heh [12:52] try 'bzr help current-formats' [12:53] whats the advantage of rich-root over normal besides svn/git [12:54] yo! is there a way to ignore executables in my code repository other than marking them with .exe (or smth) extension? [12:54] npoektop: .bzrignore? [12:54] none, but since you are migrating you'd better take the rich-root route once because it will become the default once we reach 2.0 [12:55] vila: ok :) [12:55] lamalex: how to ignore executables? [12:55] the problem is that converting to rich-root is a one-way street, you can't come back nor interoperate with non-rr [12:55] so for upgrading- bzr upgrade --format=1.9-rich-root lp:do-plugins /should/ work? [12:56] lamalex: yes [12:56] hm [12:56] * lamalex runs a check and a reconcile first just to be safe [12:56] but then you should also upgrade all branches you want to interact with it [12:56] right, we know that [12:56] good reflex, sorry, should have mentioned it :-/ [12:57] then you need to make sure the branch is mirrored (see #launchpad for that, I'm not sure what the right procedure is needed here) [12:57] will do [12:58] since you have write access to lp:do-plugins, you cant really see the mirror yourself (that's why we got different results) [12:58] i can use a different account [12:58] that should do the trick as long as the other account doesn't have write access :) [12:59] heh :) [13:01] Is there a LOSA around ? I've got a very stange failure on PQM, as if some old python modules were still present in the working tree... a make clean there may address that [13:03] how to ignore executables in .bzrignore? [13:04] npoektop: by listing them either explicitly or by using a regexp, but there are no way to automatically recognize executables (so far) [13:05] now i mark them with .exe, but it looks ugly [13:05] npoektop: to you a lot of them ? [13:05] npoektop: do you a lot of them ? [13:06] yes, i have ~/code with many small projects [13:07] well, bzr does know which are marked executable (if you're on a filesystem that supports this) but there's no way to use that info in .bzrignore [13:07] I wonder if a plugin could add that [13:08] good idea === kiko-fud is now known as kiko [13:30] vila: did you want me to change that test or can I just go ahead and resubmit? [13:30] (I need to leave soon for the weekend) [13:31] amanica: just a sec, how long soon ? [13:31] 20 minutes [13:35] amanica: it's ok, these tests could use more love anyway, if only to stop matching texts when we can use LogCatcher to get more precise comparisons [13:35] vila: I didn't mean to rush you, but thanks. yes that makes sense. [13:36] amanica: if you keep working on log, I'd really appreciate if you could try to put more tests in tests/test_log.py and less in tests/blackbox/test_log.py :-D Not a requirement, but I'll appreciate :) [13:36] vila, thats a pet peeve of me too [13:36] but that sounds like a project on its own [13:36] amanica: no problem, nagging was perfectly reasonable here, I read the whole thread and then forgot that mentioned waiting for a feedback, sorry :-/ [13:37] amanica: nahh, once test a time :) [13:37] cool [13:37] amanica: I'd like the log tests to be as concise as the ones I lastly wrote for push and send (if you're interested) [13:38] too many tests try to test too many aspects of log, each time we tweak a particular aspect we have to fix a bunch of not directly related tests: that's a clear sign of bad defect localization :) [13:38] vila: cool, an new chalenge! I won't mind doing that if I get time [13:39] amanica: great ! [13:39] it helps if someone is interested enough to review quickly.. thanks [13:39] statik: ping [13:39] amanica: I know... [13:40] vila: if you have some thought you are welcome to write a short bug on this and assign it to me [13:40] /thought/thoughts [13:41] amanica: ok [13:43] amanica: I need to look at it again, but from memory, some tests can be refactored as is, some needs some refactoring of the code itself to better separate the various aspects, so I need to re-read some code, feel free to ping me again on the subject if I forget to file that bug [13:43] vila: cool, and you me [13:43] ok :) [13:44] \me need to go soon [13:44] whoops [13:44] amanica: enjoy your week-end ! [13:44] vila: thanks, you too [13:47] bye === vila is now known as vila-away [14:06] Ok, I found a way to make reviewboard work with my branching and merging situation. [14:06] It something involving a "parent diff" [14:07] If I understand correctly, reviewboard expects to have all diffs in the same review to have the same base. [14:07] So. I have trunk-base as a common base. [14:08] Then I have "feature" revision, and the first diff is trunk-base..feature. [14:09] Then if I have a some more commits in trunk, leading to trunk-new. [14:09] And I merge trunk-new in my feature branch, leading to feature-new. [14:09] I must update the diff in the review by specifying the "feature" branch as repository path. [14:09] trunk-new..feature-new diff as the new diff [14:10] and the trunk-base..trunk-new diff as its parent diff [14:10] Geez, that's so fricking complicated! [14:10] Is there a simpler way to say the same thing? [14:10] (jargon welcome) [14:11] I'm going to wildly guess you might be looking for "ancestor:" but I haven't actually parsed your problem description [14:11] mzz: half of my problem is that i find the procedure to make revie [14:11] to make reviewboard happy very difficult to explain. [14:11] So I'm looking for better ways of explaining it. [14:26] there is an option for commit: --unchanged, it makes it commit even if no changes in repository. i don't want to commit with no changes and i don't want to see the error message that no changes. it is for crontab task. i don't want to 2>&1 /dev/null because i want to see sufficient errors. how to do that? === abentley1 is now known as abentley [14:31] npoektop: why dont you do bzr stat -V first and only commit if there are changes? [14:32] * npoektop reading docs === mishok__ is now known as mishok13 [14:33] lamalex: thanx [14:44] jam, does TestCaseInTmpDir clean up after itself? [14:44] rockstar: yes [14:44] jam, great, thanks. [14:48] jam, I should be more specific. Does it remove the temp dir it creates? [14:52] * ddaa still talking alone about reviewboard [14:53] To state it better, I think what's needed is providing branch-point..ancestor as the parent diff, and ancestor..last as the review diff. [14:54] But there does not seem to be a way to select the branch point. [14:54] I need something that allows me to find the latest revision that common to the mainline of the current branch and another branch. [14:55] s/that common/that is common/ [14:55] ddaa: based on -rancestor: ? [14:55] * ddaa thinks more... no actually I need something different. [14:56] LarstiQ: kind of. I'm trying to figure a way to state how to feed diffs to reviewboard. [14:58] But common mainline ancestor does not work when the initial diff is feature-1->feature-2, and a later diff is trunk->feature-2-updated, because feature-1 was merged in trunk. === vila-away is now known as vila [15:03] rockstar: with some help from atexit, yes [15:04] vila, yes, but the TestCase registers that handler right? I don't have to do anything special? [15:04] rockstar: nothing special... except exiting from your python script :) [15:05] rockstar: since you were more specific in your last question I thought you had special use case (or bug) in mind, so I tried to be extra-precise [15:06] vila, thanks! :) === mishok__ is now known as mishok13 [15:50] What version of bzr introduced HookPoint? [15:51] jam, ^^ Which version did you need for your Windows work yesterday? [16:02] Hi all [16:18] I'm having some weird issues. we use centralized workflow, and 1 person is having an issue when he does bzr up, he regularly gets conflicts that others don't get. On files that he has not touched at all. [16:20] most recently its "file already exists" and moving them to .moved files and showing that as a conflict. [18:17] rockstar: sorry about the delay.. I don't know what version introduced it. I'll check [18:17]