=== wgrant_ is now known as wgrant === BasicPRO is now known as BasicOSX [01:01] hi, I'm just investigating the bzr-svn plugin features and associated worklflows... [01:02] now I wonder how the workflow for dealing with svn branches is like...? [01:03] I've seen blog posts telling to branch the 'trunk', then branch from the local 'trunk' branch, commit to the latter, and finally merge to the former [01:05] But how can I deal with branches tracked within svn? Will it be possible to work on a svn branch using bzr-svn, and finally merging that svn branch to trunk? will it look like I did a merge from a branch to trunk using svn? [01:06] jonnydee: hi [01:07] hi jelmer :) [01:07] jonnydee: they're much like "normal" bazaar branches, and you can pull from them merge into them and push into them as you would expect to with a regular bzr branch [01:09] so it should be possible to emulate a branch-merge workflow of users using svn only? [01:10] I'm asking because we have svn, but I would like to use Bazaar and this should completely be transparent to the other svn users [01:11] jonnydee: yes, although bzr-svn does add revision properties with bzr metadata that can't be represented in svn natively [01:13] jelmer: I think that shouldn't be an issue... So I would co "trunk" using bzr, do my commits to a local branch of it, then I push to svn using an svn-url pointing to ../branches/my-branch [01:14] then I merge my local my-branch into my local "trunk" checkout and push to svn "trunk"? [01:15] jonnydee: there's no need for the local mirrors [01:15] svn users will then see my branch commits for ../branches/my-branch, and they will realize that I merged that branch into "trunk"? [01:16] no need for local mirrors? [01:16] jonnydee: You'll have to push that branch into /branches/my-branch in svn manually [01:16] jonnydee: otherwise it won't show up there in svn [01:17] there is an option in bzr-svn to do that for you, but it's experimental [01:17] ok, that's what I assumed, but will they somehow realize that I finally did a merge from /branches/my-branch to /trunk ? [01:18] not anymore than they currently will [01:18] AFAIK svn >1.5 does merge-tracking and I wonder if this information will be propagated when I push my merge to the svn /trunk [01:20] bzr-svn does set svn:merge-info, but it won't use it for the bzr revision graph [01:21] ok, so that's good news. It means that svn users will be able to see, that I merged /branches/my-branch to /trunk, right? [01:22] yes, the metadata will be there if they care to look for it [01:22] jelmer,maxb: thank your very much for your fast and helpful feedback :) [01:26] I am toying with trying to get bzr-svn to build a bzr revision graph based on svn:mergeinfo [01:26] I don't think it'll ever be roundtrippable, but it would be a boon for people doing a one-time convert out of svn [01:27] maxb: I think that would be really helpful in such cases [01:27] I wish you good progress [01:28] it's been a pleasure to talk to you! bye, and thanks once more for your attention :) [01:54] Why does bzrlib.tag._merge_tags_if_possible exist? [01:54] I'm trying to see what functionality it provides over tags1.merge_to(tags2), and there doesn't seem to be any [01:58] maxb: it does wha tthe comment says [02:00] maxb: if you want to pass the ignore_master=True arg, but aren't sure the tags implementation supports that API (new in 2.3), then it will try pass the flag, but if it can't it emits a warning and just give the pre-2.3 behaviour (by not passing the flag). [02:00] maxb: it's backwards-compat paranoia, basically [02:01] spiv: ok..... but I know it existed before ignore_master did .... so why? Prescience? :-) [02:01] maxb: when I added the ignore_master param as part of a bug fix I added that function so that cmd_merge (and possibly other bits of bzrlib?) can use it to avoid breaking with e.g. bzr-svn branches if the user is running with an un-updated plugin. [02:01] Are you sure? [02:02] Yes, because I remember looking at its pre-ignore_master implementation, which was more obviously mystifyingly pointless [02:02] I'm pretty sure I remember adding it :) [02:02] hm :-) [02:02] Or, perhaps, updating it to be its current useful form ;) [02:03] right [02:03] But I think I added it. [02:04] * spiv looks [02:05] no, it's existed since poolie first implemented tags in branches in 2007 :-) [02:05] Ah, well, probably a hangover from an early implementation of tags. [02:05] I'm guessing it predates the merge_to method. [02:06] Anyway, it serves a useful purpose in 2.3 :) [02:08] Now that's planning ahead :-) [02:51] to roll bzr patches i am using diff --diff-options -up so that i get @@ -136,6 +136,10 @@ function user_pass_reset($form, &$form_s now this is good but now I need patches suitable for patch -p1 and this created patch -p0 patches [02:56] bzr diff -p1 gives me a patch -p1 but that does not do what diff -p does (--show-c-function) [02:59] there is a largely undocumented option to bzr diff: --format [03:00] I think that's used by plugins. [03:04] fullermd: hi. any solution? I am happy to hack a plugin if necessary :) just dont know where [03:04] Well, my solution has been to point and laugh at people screaming for -p1 patches. Not sure that helps you ;) [03:05] Does bzr's -p take effect before --using? That sounds like it would be possible... [03:05] If possible, it probably should, and would be a bug if it didn't. And surely it's possible; where else is an external diff getting filenames but from trusting what bzr says? [03:07] i am reading diff.py and external_diff has http://paste.pocoo.org/show/343131/ in it [03:07] this makes me suspect that the prefix is not taken into account [03:09] As if showing python code to me is gonna do anything :p [03:09] I woulda approached it by just trying it to see... [03:09] You could try passing the diff throught filterdiff [03:09] It's got a --addprefix option [03:10] spiv: <3 you. [03:11] spiv: now, how can i tell bzr that bzr diff is alias for bzr diff --options -up | filterdiff --addprefix a/ [03:11] (or more elegantly --addoldprefix a/ --addnewprefix b/ ) [03:11] chx: for that I think you need a shell alias :) [03:12] spiv: sniff i need to figure out bash code that on bzr foo runs bzr foo but on bzr diff runs the aforementioned ugliness. [03:13] Nah, just make a 'bzrdiff' alias. [03:13] Aliases don't allow for control-flow, command line arguments, or additional trickery that makes the command line so useful. [03:13] Personally I'd go with fullermd's suggestion [03:13] fullermd: i guess. [03:14] * fullermd still says that -p should affect external diff... [03:14] bzr () { if [ "$1" = "diff" ]; then shift; command bzr diff "$@" | diffstat; else command bzr "$@"; fi; } [03:14] Because as you say making bash treat 'bzr diff' differently to 'bzr foo' is going to be fiddly, and I'm fairly lazy. [03:15] * mwhudson has been doing too much shell lately [03:15] Or, just hang out for 3 minutes, either way. [03:15] :) [03:15] * fullermd huddles mwhudson up in the corner with a blanket and a bowl of hot soup. [03:15] thanks [03:15] fullermd: thanks [03:16] mwhudson: good god [03:16] mwhudson: thanks [03:16] off to the gym === chx is now known as chx_afk === chx_afk is now known as chx === chx is now known as chx_afk === chx_afk is now known as chx_sleep === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [09:08] vila: bzr check still running (laptop with 2 cores + flash disk).... [09:09] montywi: single core used, lots of CPU needed, did it output some progress (even flaky) ? [09:09] montywi: or something in .bzr.log (more likely) [09:09] yes, its progressing [09:10] ha good, damn, I just realized I didn't recommend -'v' :-( /me bangs head [09:10] stupid stupid stupid [09:10] it's now in 'checking graphs 42000/85000 [09:11] this is increasing with 1 per 3 seconds [09:11] hmm, I don't remember the order in which the checks are performed :-/ [09:11] 1 out of the 85 000 ? O_o [09:12] 85.000 more or less correspond to the number of revisions ? [09:12] (not the mainline revs, all the revisions I mean) [09:17] i think so [09:17] so if it continues like now, it will take 43000*3 seconds more to do the check [09:17] or 1.5 days [09:17] (for this stage) [09:18] yeah, for this stage :-/ [09:19] on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ? [09:20] montywi: the format used is 2a right ? [09:23] yes [09:23] on both counts ? [09:23] both counts ? [09:23] on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ? [09:24] no problem found with repro during the last 2 days [09:24] k [09:24] but i will continue to do rsync backups to be able to repeat any problems that is found [09:24] of course 2 days (or even 3) is ridiculously too long for a check... [09:24] thanks [09:26] montywi: before I forget and in case you need to re-run a check (cough, hopefully not) use BZR_LOG= bzr check -v [09:26] ok and thanks for tip [09:26] montywi: so we get a clean log with all collected data (-v shouldn't make it really slower ;-/) [09:27] i would like to use the laptop after 2 weeks... [09:28] oh good, Apple will be announcing some new models tomorrow, you'll be able to buy a new one, no problem :-} [09:28] [09:35] Apple? Why on earth would I want to buy an Apple? I am using *real* machines ;) [09:36] (Machines which software I can use, modify and extend without having to talk with lawyers) [09:36] oh, but you can install Ubuntu on them :D [10:45] actually, ubuntu is really nice on my macbook pro [11:54] jelmer: make sure you always mentions bug numbers in news entries (how a veteran packager can miss that is beyond my understanding ;-D) [11:54] * vila lunch [11:55] vila: *nod* [11:55] vila: did I miss one somewhere? [11:56] jelmer: hmm, yes, but... I can't remember where right now :-( if you don't find it, don't worry, I'll fix it at release time anyway [11:56] I noticed it yesterday if that helps, may be already landed, not sure [11:57] * vila really out :) [11:59] bon appetit :) [12:16] Hi, Where I can delete the config for bazaar explorer with Windows XP? [12:19] bzr: ERROR: bzrlib.util.configobj.configobj.ParseError: Invalid line at line "1" with bzr 2.3.0 and I need delete de .conf file or whatever file that store the corrupt file [12:21] somebody? [12:22] shakaran: hi [12:22] shakaran: it's either the .bzr/branch/branch.conf file or the locations.conf or bazaar.conf in your bzr home directory [12:25] I have a C:\Archivos de programa\Bazaar for bzr home directory [12:25] I search *.conf files but it dont found any file with conf [12:26] Archivos de programas = Program files (sorry for the spanish) [12:27] I have all my local branch's with Eclipse on C:\workspace If I search .conf file there I get: [12:27] a branch.conf with: [12:28] parent_location = ../../Earth%20Wars/ [12:28] push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/ [12:28] submit_branch = file:///C:/workspace/Earth%20Wars/ [12:28] [commit_data] [12:29] hmm, that all looks reasonable [12:29] I have other 3 files with branch.conf [12:29] parent_location = ../../Earth%20Wars/ [12:29] push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/ [12:29] [commit_data] === Ursinha-afk is now known as U [12:30] third file: === U is now known as Ursinha [12:30] bound_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/ [12:30] bound = True [12:30] parent_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/ [12:30] submit_branch = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/ [12:30] [commit_data] [12:30] last file: [12:30] bound_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/ [12:30] bound = True [12:30] (sorry about the flooding) [12:31] shakaran: only the file in the branch you were working in should be relevant [12:32] I dont see the problems on line 1 for the files. The problem is that bzr-explorer fails on start with a bug [12:33] http://pastebin.com/azDjMfjm [12:33] it dont show the invalid file, so I dont know what file is it bad parsed [12:41] shakaran: one sec, I'll look at the source [12:42] shakaran: do you have a qbzr.conf file anywhere? [12:44] on whick folder should be? on bzr home? [12:44] I report the bug too https://bugs.launchpad.net/bzr/+bug/723691 [12:45] not found a qbzr.conf (on all system) [12:48] shakaran: It seems like a qbzr issue, hopefully one of the qbzr folks can help out [13:08] jelmer: I report the bug, I wait then, thanks for your great help [13:47] jelmer: that one: https://code.launchpad.net/~jelmer/bzr/multiprocessing-cpu_count/+merge/50812 [13:48] vila: Will fix - thanks for the reminder :) [13:52] np ;) === chx_sleep is now known as chx [13:59] how can you tell what commands a plugin provides? [14:01] jml: bzr help commands | grep plugin-name [14:02] jml: I don't think we have anything fancier than that to discover it [14:02] jelmer: thanks. [14:03] jelmer: I have just discovered how awesome bzr-stats is. [14:06] jml: :) [14:06] it could be a lot more awesome though [14:06] Yeah, agreed. [14:07] I was just thinking, wouldn't it be nice if I could run a command and have it tell me how actively developed this project is [14:07] jml: Ohloh-style, e.g.: [14:08] "Decreasing year-over-year activity." / "Large development team" / ... ? [14:09] yeah, maybe [14:09] well, actually that would be pretty cool [14:09] but also something like "6 commits to trunk in the last month" [14:10] or maybe a little ascii art graph of num commits per chunk of time [14:10] ah, hmm [14:10] I quite like the (new?) blurb on the code.launchpad.net/PROJECT pages with that data [14:12] yeah [14:12] it's not that new, I think. [14:13] jml: didn't launchpad also have tiny graphs with the branch activity for a while? [14:13] jelmer: it did. [14:13] jml: Do you know why that was removed? [14:14] jelmer: we removed them because showing them on a branch listing for a project is generally uninteresting [14:14] and that's where they were shown [14:14] e.g. all of the branches for bzr will have almost exactly the same graph [14:14] because they are all short-lived branches of trunk. [14:14] jelmer: and so rather than rehabilitate the feature, we killed it. [14:15] ah, ok [14:17] jml: any feedback about bzrlib.transform.orphan_policy=move ? [14:17] jelmer: do you know how to tell bzr-stats that two people are the same? [14:17] vila: no. I'm a loser. [14:18] vila: do I just add that line to my bazaar.conf? [14:18] jml: yup [14:18] bzr.transform.orphan_policy=move [14:18] grr don't paste ! [14:18] jml: it looks for similar email addresses/fullnames [14:18] :) [14:19] vila: thanks. added, will let you know how it goes. (I have a couple of branches up that delete directories) [14:19] jml: it doesn't support a rename map of any sort (yet) [14:19] jelmer: ahh ok. [14:19] jml: cool, will fix any related bug [14:20] jml: especially the ones with reproducing recipes ;) [14:20] vila: heh. will do. :) [14:22] jelmer: I have now filed many bugs on bzr-stats. I might actually try to fix them, but, you know how it is. === Vorpal_ is now known as Vorpal [14:30] jml: :) [14:30] jelmer: I also just filed a bug asking for reviewer stats. I think that's kind of a tough one that might require some kind of hook thing. [14:30] jml: with regard to reviewers, I think it would be really nice if we can start sticking them in a revision property [14:30] +1 [14:37] jml: https://bugs.launchpad.net/bzr/+bug/723740 [14:38] jelmer: hi. Am I having the honor to talk to the author of bzr-git :) ? If yes, then https://bugs.launchpad.net/bzr-git/+bug/719238 what does this... mean? there is support for push now but it's experimental and shouldnt be...? [14:43] chx: hi :) [14:47] chx: looking.. [14:48] chx: so, there has been some initial work on proper push (as opposed to dpush) but it's not ready for prime time use yet [14:48] chx: it should by default be disabled but doesn't appear to be [14:49] ah i see [14:50] next question, when i use bzr git-import http://git-testing.drupal.org/project/drupal.git it creates an empty directory with .bzr in it [14:50] oh it created a repo? [14:53] Hi - can someone help me out with bug 723735? It's blocking me from submitting code prior to todays feature freeze. [14:53] Bug 723735 on http://launchpad.net/bugs/723735 is private [14:54] jelmer: http://web.dodds.net/~vorlon/wiki/blog/bzr-git_case_study.html from reading this i am under the impression that bzr git-import http://git-testing.drupal.org/project/drupal.git should actually download something but it dosnt. [14:55] jhunt: I can't see that bug because it's private. [14:55] chx: It should, but that URL is a bit strange (it gives me a 404) [14:55] jelmer: weird. git clone works with it unless i am blind. [14:56] jelmer: yeah it does [14:56] AH ha! [14:56] jelmer: that's a git:// url [14:57] jelmer: it's just that git ... works with http [14:57] bzr git-import git://git-testing.drupal.org/project/drupal.git is downloading. [14:57] chx: can you file a bug against bzr-git? [14:58] jelmer: https://bugs.launchpad.net/bzr-git/+bug/723751 [15:02] ah, I think I see what's happening [15:02] jelmer: yes - the bug was created as private by default, but I am unclear as to why. [15:08] jhunt: can you make it public or pastebin the information you can make public? === Ursinha is now known as Ursinha-lunch [15:09] jhunt: I often see bug created private when apport is involved... === chx is now known as chx_afk [15:18] jelmer: bug 723735 is now public [15:18] Launchpad bug 723735 in bzr (Ubuntu) "bzr crashed with NoSuchRevision in _translate_error()" [Undecided,New] https://launchpad.net/bugs/723735 === marienz_ is now known as marienz [15:26] jhunt: so, it seems like the "-v" is the bit that breaks [15:26] jhunt: does it still break if you run without -v ? [15:35] jelmer: well, I just pushed the same branch using "bzr push -v lp:~jamesodhunt/+junk/foo" and that was fine ? [15:36] jhunt: no stacking involved in +junk [15:36] jhunt: I guess it's stacking related. [15:36] hmm, gmta :) [15:37] jhunt: can you perhaps try with the latest bzr (2.3.0) ? === deryck is now known as deryck[lunch] [15:56] jelmer: You haven't (yet) used the lazy registration of branch formats in the foreign plugins right ? [15:57] jelmer: argh, gmta again, loom trunk: branches have diverged :D [16:01] jelmer: additional tweak pushed [16:01] vila: I have, bzr-{hg,svn,git} use it [16:02] vila: it's not in any releases yet though, so changing things should be possible [16:02] jelmer: while you're warmed up, care to use it for looms too ? [16:03] jelmer: do you remember if jam is already moving today ? === Ursinha-lunch is now known as Ursinha [16:08] vila: sure, I'd be happy to [16:08] vila: I'm not sure [16:08] heya all [16:09] heya bialix [16:09] hey bialix, how's your day? [16:09] jelmer: I wish something better [16:09] jelmer: could you give your input on https://code.launchpad.net/~vila/bzr/config-expand-options/+merge/50355 ? [16:09] vila: if you have a minute to talk about configs and qbxt [16:09] qbzr [16:10] don't ask to ask :) [16:11] Pushed up to revision 404. [16:11] Huh ? What do you mean file not found ? [16:11] errr [16:11] :) [16:11] vila: currently qbzr/lib/util.py has its own Config object which is kinda caching object [16:11] it does not try to re-read the real config every time [16:12] *Config class [16:12] it's used to work with qbzr.conf [16:12] this class is using to work with qbzr.conf [16:12] vila: sure [16:13] vila: what I need to switch to using bzrlib.config instead [16:13] bialix: looking at it, it seems to have anticipated bzrlib.config.LockableConfig... except save is explicit [16:14] hmm, and {set|get}_option here is {set|get}_user_option there :-/ [16:14] wow, and BOOKMARKS [16:15] bialix: forget it, too early to migrate === beuno is now known as beuno-lunch [16:24] vila: forget what? [16:24] sorry, I had a call [16:25] bialix: qbzr needs to save only once, this is not yet available (unless you don't want atomicity anymore) [16:25] so you can't migrate yet... unless [16:25] vila: I don't think it's the main goal [16:25] ha, ok [16:25] it saves data here and there all the time [16:25] no atomicity, as I can see [16:26] another point to consider: [16:26] I need to dig through the history of that code to understand why it written in the way it's written [16:26] instead of using a separate config file, you may want to prefix your options with 'qbzr.' [16:27] :-/ [16:27] and use bazaar.conf or branch.conf [16:27] that'd be bad [16:27] maxb recently said against this [16:27] vila: I'll have a look at the expand options branch and your udd MPs when I get back [16:27] that would mean that in the future, some options may be defined in branch.conf, locations.conf, bazaar.conf [16:27] actually I don't like how it's designed today [16:27] bialix: not for all variables [16:27] jelmer: great [16:28] we have a lot of runtime variables which is not user editable [16:28] jelmer: err, back from what ? :D [16:28] vila: need to run some errands [16:28] jelmer: np was kidding :) [16:28] The thing I objected to was 'bzr viz' storing window sizes in pixels in bazaar.conf, thus making it impractical to version-control my bazaar.conf [16:28] maxb: yup, I understood that [16:28] maxb: exactly [16:28] vila: ^ see [16:29] bialix: see ^ :D [16:29] vila: I don't like how we store our data in qbzr.conf [16:29] that doesn't mean it applies to *all* qbzr config options ;) [16:29] yes, of course [16:29] there are about 5-10 options which are not pixels [16:29] I think it's fine for plugins to rewrite bazaar.conf so long as they only do it in response to the user actually reconfiguring sometime [16:29] *something [16:30] yeah, I'll go as far as saying that 'bzr config' should be almost the only one to modify config options [16:30] if we start talking about bzr-explorer then it has a ton of options grouped into subdir [16:31] the execptions being --remember, window sizes, bookmarks, aliases, but even bookmarks and aliases should be defined with 'bzr config' and just use special names [16:31] bialix: I discovered that a couple of days ago, but most of them are in xml files [16:32] there is one horror there still, file extensions are associated with executables by using the list of extensions as the key and the application as the value... [16:32] vila: I'm very dislike code like that in the qbzr: [16:32] I wonder why it's not the reverse... [16:33] config.set_option(name + "_window_size", "%dx%d" % size) [16:33] config.set_option(name + "_window_maximized", is_maximized) [16:33] size = config.get_option(name + "_window_size") [16:33] those concatenations make me feel bad [16:34] bialix: use helpers [16:34] and dots instead of _ [16:34] no, I'm trying to say: why we haven't put them into subsections [16:35] if you start thinking about option names as python identifiers [16:35] or even into database [16:35] registry [16:35] eeerk [16:35] and so on [16:35] no subsections please [16:35] that's bad [16:35] I don't think we need more than python identifiers here [16:35] I can't agree [16:36] that's far more user friendly than subsections with [[[[[very embbeded section]]]]]] [16:36] bzrlib.config has hidden ConfigObj too deeply [16:36] not enough obviously [16:36] I need only one layer down [16:36] every q-window should have dedicated section [16:37] for their pixel settings [16:37] qbzr..size [16:37] great! can I have one of this? [16:37] just do it ! [16:37] it works today ! [16:37] really? [16:37] in 2.3? [16:37] in 2.0 even [16:37] ??? [16:38] '.' has always been valid in an option name [16:38] I never seen it [16:38] ha [16:38] you again put me bacj [16:38] back [16:38] ? [16:38] one sec, I'm pastebining [16:39] vila: http://pastebin.com/XQ9PiW7P [16:40] do you like it? [16:40] I'm NOT [16:40] that's a mess [16:40] sorry for my french [16:40] :) [16:41] Yeah and the user has no idea who is spamming his config file... [16:41] subsections won't make it less spammy [16:41] the syntax you have shown "qbzr..size" recalls me about git configs [16:41] just because it's like git doesn't mean it's bad [16:41] dot syntax is using to navigate through sections, IIRC [16:42] no, sections are used for something else ! [16:42] that's the whole point [16:42] I thought you said we can navigate through our sections as well [16:42] if you use sections to define the name space you can't reuse it to define values for more specific cases [16:42] let's draw a line: I want those automatic pixel settings to be stored separately of user options [16:42] 'specific' can be a path, a user name, an url, whatever [16:43] vila: so I need [GEOMETRY] section and q-window names as subsections [16:43] bialix: right, put them in a qbzr.windows.conf file then [16:43] haaa [16:43] scratch above [16:43] qbzr.internals.pixels.settings.dont.edit.it.please.and.even.dont.look.inside.conf [16:43] What do we use sections for at the moment, other than locations.conf ? [16:43] a qbzr.windows.conf with window names as sections then [16:44] maxb: nothing, exactly my point ;) [16:44] oh, and branch.conf [commit_data] [16:44] yep, famous commit_data [16:44] maxb: kill that one, I don't even want to know it has ever existed :) [16:44] (palm face) [16:45] bialix: windows size are user specific right ? It's a bit sad it can't be project or even branch specific no ? [16:45] * bialix wonders where is the Gary. maybe in the long and sunny vacation on Taiti [16:45] vila: yep [16:46] nahhh, in a basement with someone whipping him [16:46] nm [16:46] hmm [16:47]