[00:00] uh-huh [00:00] bob2: I have many files (work related) that I don't want out there.. [00:00] malibu: rdiff-backup. [00:00] tahoe in no way implies storing data with random people [00:01] if you choose to do so, they are carefully encrypted [00:01] rdiff-backup is awesome. [00:01] it does sound more like you want unison, though [00:02] bob2: Lol.. well I saw "cloud" in the summary and it turned me off@! [00:06] Yes, unison does sound interesting [00:10] poolie: http://github.com/droundy/iolaus looks interestingish [00:19] interesting [00:22] yep! [00:23] the thing that makes me leery about unison (and now I remember being here before) is that it points to some guys user directory to download it [00:23] Although the documentation seems to be really good [00:32] mwhudson, pong [00:32] jelmer: hi [00:32] hello [00:32] jelmer: i'd very much like a reply to the latest "plan for incremental code imports" mail [00:34] mwhudson, a recent one, from after friday ? [00:37] jelmer: hm, i don't have anything from you on the subject since tuesday [00:37] jelmer: can you resent your latest? [00:38] perhaps I missed an email [00:38] * jelmer looks [00:38] jelmer: lots of worrying about topological sorting [00:39] I'm writing a small app in 2.7.0 that generates a SQLite DB but chokes when I try to add foreign key constraints. What version of SQLite DBs does Mono.Data.SqliteClient generate? [00:39] ed-209: Wrong channel? [00:39] oh ya [00:39] Reading is Fundamental I guess [00:42] mwhudson, found it [00:47] jelmer: anything to talk about now? [00:48] mwhudson, I'm replying to your email [00:49] jelmer: cool [00:49] also, I just switched to dvorak - so a bit slow still :) [00:50] Enjoying it so far? [00:51] :-) [00:54] peng: typing 8 times slower than usual is *really* frustrating [00:54] hopefully it'll get better soon [00:55] sent [00:55] mwhudson, ^ [00:56] If I typed 8 times slower than usual, wow, I couldn't use a computer at all. [00:57] jelmer: thanks [00:57] mwhudson, that's exactly what it feels like [00:57] jelmer: you can't even talk to the right person in irc! [00:57] s/mwhudson/peng [00:57] mwhudson, :) [01:01] hi [01:01] I tried to switch to Dvorak a couple of years ago, but never got really fast, so I switched back. [01:02] i'm told git does not store old revisions of binary files, is this true for Bazaar? [01:02] But now whenever I think about typing, I unknowingly switch to Dvorak. [01:02] meoblast001: Bazaar does not distinguish between text and binary files. [01:02] meoblast001: I don't think that's true of git, let alone bazaar [01:03] ah, so i've been lied to [01:03] Indeed. I'd be very surprised if Git did that. [01:03] It would make Git pretty useless. [01:03] wgrant, this is my 4th try :) [01:05] spiv: ping [01:05] hi all [01:05] spiv: are you on today? I'd like to point you at some polish on the merge hook you did [01:06] jelmer: in import_git_objects, can we just limit the times we go around the last for loop? [01:06] jelmer: i'm not sure what the "while heads:" loop is doing [01:20] How do I retrieve older versions of files with unison? [01:20] you don't [01:20] it's a sync tool [01:20] Oh but I want versions.. unison won't work for me [01:21] So unison isn't much more then rsync then [01:22] mwhudson, yeah [01:22] jelmer: cool [01:23] jelmer: any idea how to test this? [01:27] I basically want protection from anything... such as deleting a file by accident [01:27] I think I might use unison, but also take an incremental backup of the repo a few times a day [01:49] * wgrant wishes that bzr would warn when it had a bad email address set. [02:59] <_Andrew> Hi [03:01] <_Andrew> Anyone else have a problem where you can't commit through a mounted smb partition unless you do it as root? [03:02] <_Andrew> My /etc/fstab line looks like this... [03:02] <_Andrew> /computer/repo /mnt/repo cifs rw,username=user,password=pass,noauto,users,group,exec,dev,suid 0 0 [03:02] <_Andrew> Any ideas? [03:02] well, what error do you get? [03:03] <_Andrew> It says permissions denied code 13 [03:03] <_Andrew> Cannot lock lock dir [03:04] <_Andrew> I'm guessing it's how I setup the mount? [03:04] that suggests that you don't have permission to lock things [03:04] if your working tree is on the mount, this could be an OS lock, or a dirlock, where we rename a directory to take the lock. [03:05] if your working tree is not on the mount, then its only going to be a dirlock; check your users permissions to .bzr/repository/ .bzr/repository/lock and .bzr/branch and .bzr/repository/lock [03:06] <_Andrew> ok [03:06] <_Andrew> thanks [03:08] <_Andrew> Could it be because when I crate a file on the mount it create is with no permissions to write? [03:08] <_Andrew> create** [03:09] that would be a problem [03:39] poolie: I don't know the number that its a dupe of [03:39] poolie: but I'm very sure its a dupe [03:42] mm it looked familiar [03:42] it was a smart server code path [03:42] issue [03:47] * igc lunch [04:03] igc, around? [04:32] hi poolie: back from lunch now [04:50] just to confirm, if a bug was fixed for 2.0.1 it was also in the 2.1.x branch? [04:54] check the bug, it should have separate tasks [04:54] but generally, yes. it would have been fixed in trunk as well. and trunk became 2.1.x recently [04:57] lifeless: https://bugs.edge.launchpad.net/launchpad-code/+bug/3918 [04:57] Ubuntu bug 3918 in bzr "bzr can be caused to error with filenames containing newlines" [High,Fix released] [04:57] lifeless: only one bzr task [04:58] should be fixed in 2.1.x then [04:58] ta [04:58] damn I love noise cancelling headphones [05:33] lifeless: not today, thu and fri [05:35] so on tue,wed only? [05:36] lifeless: no, off mon,tue,wed, and on thu,fri currently. [05:36] kk [05:37] How come `bzr ls` shows .~N~ revert files? It's not a problem, of course. Just a bit weird. [05:37] with no options it acts like 'ls' [05:37] AIUI [05:37] lifeless: damn ambiguous language :) [05:38] spiv: I thought it was lovely and clear... and possibly wrong :) [05:38] :) [05:51] lifeless: er, not really. [when recursing] it leaves out [children of] ignored file paths. So why would it show ~ files? [05:52] AfC: file a bug please ;) [05:53] anyway, I just thought it was weird. [05:53] it is - thus me wanting a bug ;) [05:53] seeing as how there is a --ignored flag [05:53] ok [06:03] lifeless: https://bugs.launchpad.net/bzr/+bug/522015 filed for you [06:03] Ubuntu bug 522015 in bzr "bzr ls shouldn't show .~1~ revert files" [Undecided,New] [06:05] thanks [06:17] AfC, so the problem is actually that it shows ignored files but does not recurse into them? [06:17] spiv, lifeless, https://lists.launchpad.net/launchpad-dev/msg02590.html may be of interest [06:18] poolie: have you seen ground control ? [06:18] (i'm glad hydrazine is coming along) [06:19] only briefly [06:19] does it cover bug stuff? [06:19] poolie: I should think that the problem is that it's showing unversioned files. The recursion interaction may be complicating things [06:19] so the bug is 'i wish bzr ls excluded ignored files by default'? [06:20] igc, so regarding annotate [06:20] it would be good to fix [06:20] um isn't it supposed to? [06:20] I mean, otherwise, why the --ignored option? [06:20] I'd say that being inconsistent is a bug [06:20] either recurse into and show ignores, or do neither [06:20] poolie: hi poolie [06:20] and meanwhile, if you do `bzr ls -R` it does not list contents of ignored [top level] directories] [06:21] igc, so we should probably ask first whether you have anything else yet unfinished [06:21] you, or we [06:21] afc, ls --ignored means "only ignored" [06:21] which is what you'd expect given the whole "ls me what's versioned" expectation [06:21] i don't know if that's really the ideal behaviour [06:21] poolie: [oh] [06:22] AfC: poolie is being very reflective ;) [06:22] lifeless: just so long as he's not being recursive [06:22] iow shiny [06:22] anyway, I would have thought it wouldn't list any ignored files at all. Seeing as how it seems to ignore some (but not others) I'd say that's the bug [06:22] poolie: (re hydrazine) interesting! I was just realising earlier today that I can slowly read email and browse the web while holding the baby by carefully driving my laptop with my toes :) [06:23] poolie: a mail client with good key bindings certainly helps when doing that! [06:23] or, carefully hold the baby between your knees and type faster :) [06:23] so i do think in principle one ought to be able to get through bug triage faster by typing than clicking [06:23] it may even be possible on top of this [06:24] s/on top of this/starting from the basic approach of hydrazine [06:24] (Turns out http://en.wikipedia.org/wiki/Morton%27s_toe is not just a random mutation but a distinct advantage ;) [06:26] spiv: so, you and the statue of liberty huh [07:06] What is the difference between a "master branch" and a "parent branch" and are there any other types of branches? === JesseW__ is now known as JesseW [07:07] a master branch is the branch a bound branch synchronises with [07:07] a parent branch is the branch that 'pull' and 'merge' will read from by default if you don't supply a url [07:11] spiv, can the cleanup work systematically get rid of TooManyConcurrentRequests etc? [07:11] or could we turn them into eg a warning? [07:12] lifeless: thanks -- and there are no other kinds? [07:15] It's not like they're different _types_ of branches. A branch just has e.g. "parent_location = foo" in its branch.conf. [07:16] There are several others -- submit (bzr send's default destination), public (used as the public location by 'bzr send' and Loggerhead), and probably more. [07:16] The stacked-on branch, if you're using stacking. [07:17] Peng: great, that was the sort of thing I wanted to know... so, these are effectively branch properties, that specify various relationships with other branches? Is there a full list anywhere? [07:26] JesseW: Dunno if there's a full list, aside from digging through the source dode. We definitely listed most of them. :P [07:30] poolie: off the top of my head, only if we get pretty strict about replacing try/finally blocks that might issue smart requests in finallys with the more robust cleanup helpers [07:30] Peng: cool, thanks. [07:30] poolie: and that's pretty hard to do short of forbidding finally: entirely in test_source [07:30] poolie: but, [07:31] poolie: I think the only_raises decorator that is already on unlock methods in 2.1 will have fixed the majority of cases [07:31] poolie: so 100% seems very hard, but we may already be Good Enough [07:32] (also, potentially except clauses could be troublesome too, so even banning finally perhaps wouldn't be sufficient) [07:32] poolie: I'll be very interested to see how many reports of TMCR we get involving 2.1 [08:07] * igc dinner [09:11] hola [09:11] is bug 522041 known already? [09:11] Launchpad bug 522041 in bzr "ERROR: exceptions.TypeError: merge_text() takes exactly 2 arguments (3 given)" [Undecided,New] https://launchpad.net/bugs/522041 [09:20] Yes, and I'm 99% sure it's been fixed. [09:20] dholbach: https://launchpad.net/bugs/515597 [09:20] Ubuntu bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released] [09:20] nice, hope the fix gets into Ubuntu quickly! :) [09:22] dholbach: Ehh, you could edit your bzr install -- it's a _really_ trivial change. [09:23] Peng: I'm sure I'm not the only one having the problem [09:25] dholbach: Yeah, you're not the only one. [09:26] If you didn't read them, the bugs say the fix will be in 2.1.0 final. I dunno when that will get into Ubuntu. [09:26] It was also said that the bug probably isn't in 2.0, so backporting is not a concern. [09:27] yep, seems to be a problem "only" in ubuntu lucid and debian experimental right now [09:28] dholbach, it may be fixed in the nightly ppa [09:28] anyhow, good night [11:37] jelmer: ewww, dvorak [11:37] it's snake oil, don't believe it [11:39] malibu: have you looked at that git-based FS thing? [11:44] woo dvorak [11:45] dvorak ftw [11:46] but yeah, learning a new keyboard layout is painful [11:46] it gets easier after the first 5 layouts, though ;) [11:46] * marienz blinks [11:46] that is a lot of layouts [11:48] Well, compared to 101!, it's a pretty small sampling of the choices :p [11:48] I don't actually know 5 layouts; but languages get easier after the first 5, so I figure keyboard layouts should be the same ;) [12:45] lifeless: did you unban the guy that kept rejoining and leaving? === 18VAAD4Y4 is now known as SamB === SamB is now known as SamB_XP [13:26] somehow I have gotten to branches on lp linked. I have a project branch that has my dotfiles repo lited as its parent [13:26] i am sure this is soemthign I did, but I do not want to merge these two. [13:27] could someone pls help me sep these two? [13:27] this is the branch in question, https://code.launchpad.net/~slestak989/+junk/pt [13:27] bzr info shows dotfiles as its parent which is not correct [13:28] I don't think the parent of a launchpad branch actually has any meaning [13:28] If you actually care to look for it, you can find all kinds of people's random local paths in there [13:29] but if I try to sync my workstation to this, it will try to pull in vimrc and whatnot [13:29] huh? [13:30] This was not liek this on Friday, so I thought I would be able to rollback whatever transaction did this [13:30] in the pt dir, if I do bzr missing, it says i am missing every revision in dotfiles [13:31] The value in the launchpad branch is irrelevant for that [13:31] It's the value in your local branch that you're running 'bzr missing' in that matters there [13:32] so that is what I need to correct [13:32] Just do a 'bzr pull --remember' from whatever branch you actually want [13:33] this workign dir is actually the most receent, so I need to push. [13:33] i wonder if this will try to push to dotfiles? [13:34] the help for pull says it will only work for non-diverged branches. I think these can be considered diverged. [13:37] so try the merge to resolve diverge, or try the pull --remember? either can be reverted right? [13:44] Wait... is the actual _problem_ anything other than "this branch's 'parent' doesn't make sense"? [13:44] 'cuz if that's the whole problem, there's not a problem... [13:44] fullermd: i am concerned that on my workstation, If I do bzr pull it will pull down src from lp that doesnt belong in this bracnh [13:45] i can revert it if it doesnt work out right? just try it and dont commit until verify? [13:46] Well, first off, pull won't pull unless what you're pulling is a superset of what you have (unless you --overwrite of course). So if two branches are unrelated, pull won't do anything. [13:46] Second, if you're worried about the effect of the parent branch of the _branch on lp_, on anything you do locally, don't. [13:47] but when I say bzr missing, it lists every revision for dotfiles [13:47] Saved locations like 'parent' (and 'push', etc) don't imply any linkage between the branches. They just provide defaults for certain commands. [13:47] add a -v and it shows all of my vim setup. [13:48] I think I see what maxb was saying, do a pull --remember to set it to the pt branch on lp i want [13:48] The parent branch of a branch on LP wouldn't matter. [13:48] Parent just sets the default for pull (and sometimes a few other commands) [13:48] this is the parent branch on my workstation I an discussing [13:49] Ah. Well, don't pull then 8-} [13:50] (not that it'll do anything unless the branches are related, as above) [13:50] too late, lol [13:50] sokay. it did what both of you said, pulled nothing. [13:51] and --remember did what was expected [13:51] sorry for drama, trying to work bzr into my workflow [14:09] night all [14:10] night [14:17] hi ... what does "format: unnamed" mean? [14:22] It means there's no name for the combination of formats at the given location. [14:23] Try info -v for the details. [14:25] fullermd: hmm. how can that happen? [14:25] Oh, any number of ways. [14:25] for example? [14:25] if i merge a branch with a different format? [14:26] can i get the branch straight again ;)? [14:26] Branch format from upstream. Upgrading one parts but not another. Various combinations of formats given to init and init-repo. [14:26] It's not un-straight. It's just unnamed. [14:28] asac: The most common way it happens is when bzr 2.x combines the latest working tree format with an older branch/repo format. [14:29] This is an unfortunate UI wart, since it obscures the interesting information unless you know to read bzr info -v and interpret it [14:31] hmm [14:31] so the problem is that i got a branch submission that i cant merge. it seems to use rich-root, but the guy did it on a recent checkout - i assume it means he ran upgrade before submission? [14:32] Not necessarily. He could have branched it into an existing RR repository. [14:32] sigh [14:33] asac: Is there a reason you can't upgrade to 2a or another rich root format yourself? [14:33] since when does 2a exist? [14:34] asac: karmic. [14:34] asac: it was introduced in bzr 2.0 [14:34] right [14:34] so until hardy is eol i dont want to do that ;) [14:34] but i guess its already too late :( [14:34] since our branch somehow morphed into unnamed from pack-0.92 [14:34] 2a isn't the only rich root format. rich-root-pack dates to 1.0 for instance. [14:34] asac: alternatively you could switch to 1.0-rich-root, that's bidirectionally compatible with 2a [14:35] asac: that was introduced before 1.3.1 which is in hardy [14:36] thx will think about it ... but i just want to stay on pack-0.92 ... why is bzr so bad to me :( [14:39] is there a way to prevent changes to branch format on commits of a branch? [14:39] like the "always on top" ... a "never morph branch format" ? [14:40] Being distributed is kinda antithecal to being able to tie down what other people can do on other branches. [14:40] well i dont mind of what the peers do on their own [14:40] i just want to ensure that the online branch doesnt change his format [14:40] asac: fwiw you can always communicate branches in other formats freely, the only situation in which this doesn't work is from a rich root format to a non-rich-root format [14:41] Branches don't just change their format; somebody changes 'em. An existing branch won't change unless you upgrade it. [14:41] right [14:41] but when i do a bzr merge lp:dirtybranch [14:41] bzr commit [14:41] asac: That won't upgrade your branch [14:41] and that changes my local branch format without a warning its not really an explicit decision [14:42] then how did the online firefox-3.6 branch got upgraded to unnamed? [14:42] asac: what's the url of that branch? [14:42] anyway ... i guess i need to live with this and hope for the best :( [14:42] asac: Somebody must've run bzr upgrade on it [14:42] http://launchpad.net/~mozillateam/firefox/firefox-3.6.head [14:43] i only ran bzr upgrade --pack-0.92 on it [14:43] i doubt someone else did [14:43] Standalone branch (format: pack-0.92) [14:43] asac: according to bzr info that's still pack-0.92 [14:43] oh [14:43] its xulrunner-1.9.2.head [14:44] i think [14:44] heh [14:45] seems its all fine ... hell do i feel bad. sorry [14:45] let me complain to the guy that confirmed it was unnamend ;) [14:46] asac: it may be that when he cloned that branch locally he ended up in an "unnamed" format [14:46] probably [14:46] * asac happy [14:46] asac: the "unnamed" bit is confusing indeed [14:50] so the reporter has this for fresh checkout: http://pastebin.com/f13c46178 [14:51] i have http://pastebin.com/f230277fa [14:51] in one case its Working tree format 6 [14:51] (the unnamed one that is) [14:51] That's what you'd expect from a 2+ version of bzr. [14:51] for me its working tree format 4 [14:51] fullermd: i have Bazaar (bzr) 2.1.0rc2 [14:51] he has 2.0.4 [14:52] seems 2.0 upgrades the working tree format to 6 while 2.1.0 doesnt [14:52] so guess that was a bug in karmic bzr? [14:52] thats 2.0.4 [14:54] No, 2.1 does it too. [14:54] why not for me? [14:54] 15:51 < asac> i have http://pastebin.com/f230277fa [14:54] Because you're using http; it's preserving it over that. [14:54] thats bzr info -v [14:54] omg [14:55] Probably some side effect of the format hiding over the smart server. Dunno. [14:55] Anyway, WT format doesn't matter anywhere except locally. [14:55] * asac happy that thats the case [14:56] you are right [14:56] over ssh i get the unnamed thing [14:56] * asac scared [14:56] ok thanks === beuno is now known as beuno-lunch [15:46] I'm doing "bzr check -v" on a shared repository (which should take 40 hours), I wonder if -vv would have given interesting info? Or is -v ok? [15:46] I thought bzr's -v was just on/off, not level based? [15:47] ah, maybe... :-) [15:47] ok, I'll see after 40 hours. [16:04] I'm not sure -v does anything on check anyway... [16:12] Are there any plans or is anybody working on providing context managers for Tree locks? [16:12] henninge: I'm not aware of any plans. [16:13] I just implemented one locally in a Launchpad branch and thought this should really be in Tree code. [16:14] jelmer: I am not too familiar with the class structure in bzr but is Tree the class that implementes the locking? [16:14] * henninge goes to browse bzr code. [16:15] henninge: no - a Branch, Repository and Tree are all three lockable but they call out to another class to worry about the actual locks [16:16] ok, now I remember reading the tree locks use branch locks. [16:16] jelmer: should I file a bug about it to start with? [16:16] henninge, please do [16:16] cool [16:26] jelmer: https://bugs.edge.launchpad.net/bzr/+bug/522195 [16:26] Ubuntu bug 522195 in bzr "bzrlib should provide context managers for locking" [Undecided,New] === henninge is now known as henninge-afk [16:30] henninge-afk, thanks === beuno-lunch is now known as beuno [17:35] hi [17:35] how I can set a branch as default branch? [17:36] Do you mean on launchpad? [17:36] yes [17:37] IIRC you set it as the development focus [17:37] visit the project page and click "edit details" [17:37] scroll to near the bottom [17:37] see the dev focus dropdown? [17:37] select something from there [17:37] That should do it [17:38] in that part [17:38] show [17:38] Development focus: [17:38]

trunck [17:40] but when I try: bzr co lp: it say me that there is not default branch [17:43] What is your package project called? [17:43] * Kinnison will look [17:44] Kinnison: shareit-server [17:44] Azag: go to https://code.launchpad.net/ and there should be a link you can click to set the branch for htat [17:45] I see [17:45] thnx [17:45] cool [17:45] jeje, I was looking in the worng page [17:45] thanks Kinnison and james_w [17:45] :) [17:45] tbf, it's not completely obvious to me because all my projects already have focusses :-) === radoe_ is now known as radoe [18:39] how I can download a bzr branch without a rsa directory [18:39] Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to the list of known hosts. [18:39] Permission denied (publickey). [18:39] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [18:39] [18:40] jelmer: test_log_verbose (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) just errored for me, is this bzr's fault? [18:41] bah [18:44] mwhudson, no idea - what's the error exactyl? [18:45] jelmer: http://pastebin.ubuntu.com/377039/ [18:46] mwhudson, ah [18:46] mwhudson, that's a bzr bug [18:46] ok [18:46] mwhudson, I submitted a merge request for it, not sure what the current status is [18:50] jelmer: shoving this information about how many revisions to import through all the layers is no real fun :/ [19:25] gerard_1: thanks [19:27] lifeless: I was happy to remember it ;) === froosch_ is now known as froosch [19:33] james_w: ping, bzr-builder ppa watching; hows that going? [I'm sure its a case of ETIME [19:33] :)] [19:35] <__monty__> Could someone have a look at this, the last comment in particular? [19:36] <__monty__> *https://code.launchpad.net/~toonn/bzr/no-repo-error-message/+merge/17039 This of course. (forgot the link) [20:02] hi all. Can anyone tell me why the shared-repository (bzr init-repo PROJECT) is needed when using the distributed development approach? [20:03] It's not strictly needed. It's useful for saving space when you [would otherwise] have multiple copies of the same history. [20:05] fullermod: humm.. what do you mean? [20:05] fullermd: might be clearer to say its optional [20:06] aleksander_m: its optional; shared repository lets multiple branches reuse the same storage database ('repository') [20:06] aha, understood [20:13] another question... when using bzr push to publish commits in the main branch, it happened to me that one of my colleagues didn't do a pull in the mirror branch first, so he pushed his changes but overwrote already pushed changes... is there any way to avoid this? [20:14] It wouldn't discard other existing changes unless he did push --overwrite; that requires intention. [20:14] Or do you mean that the existing changes are now showing up in a merge, rather than on mainline like they previously were? [20:15] hum.... you got me [20:15] can't remember [20:15] Look at `bzr log -n0`. If the already-pushed changes you're thinking are overwritten show up in some of the indented revs, it's the latter case. [20:15] If the problem is actually the former... smack your colleague around for using --overwrite :) [20:16] Either situation can also be prevented by setting a branch config option to preserve the mainline. I'll remember what it's called in a second... [20:16] append_revisions_only I think? [20:17] Yeah, that's it. [20:20] will take a look at it [20:20] fullermod: thanks [20:21] s\fullermod\fullermd [20:42] james_w: hi [20:43] hi lifeless [20:44] james_w: did you see my ping about builder? [20:45] I did [20:45] it's still on my list [20:45] kk [20:45] I have spent time on it [20:46] I'm just not happy with some of the interaction that the oauth stuff forces on the user [20:46] so I'm thinking of better ways to structure it [20:46] ok. if you want a sounding board let me know [20:47]