[00:03] on karmic, have bzr 1.18-0ubuntu1 and python-paramiko 1.7.4-0.1 installed, trying to pull from sftp url and getting "Unable to import paramiko (required for sftp support): No module named paramiko". Clues? [00:06] hmm, did "apt-get install --reinstall python-paramiko" and that fixed it. weird! [00:13] Wasn't there a plan to quiet all of the muttering in groupcompress's _trim_block and _rebuild_block? [00:13] "creating new compressed block on-the-fly in 0.177s 618357 bytes => 293599 bytes" and all. [00:19] "bzr branch hg.hg hg.bzr" now works and takes less than 5 minutes :-) [00:19] it still needs more work (corner cases, tests, memory usage improvements) but the basis is there [00:20] hg -> bzr? Wow. [00:21] Peng_: yep. It's a local conversion though, not sure what it would take to clone a remote hg repo [00:22] Does it use the Mercurial Python library or what? [00:22] Peng_: Yeah [00:23] Very cool. :) [00:23] Is it read-only? [00:27] Peng_: we had it 3 years back, but it bitrotted :) [00:27] jelmer: I'm very glad you've cleaned it up and made it work well [00:36] hello bzr devs and users, I'm trying to do the following: 'bzr branch lp:gwibber' and I get a strange error [00:36] bzr: ERROR: Invalid url supplied to transport: "lp:gwibber": OOPS-1362ED11069 [00:36] https://lp-oops.canonical.com/oops.py/?oopsid=1362ED11069 [00:37] launchpad is in maintenance at the moment [00:37] thumper: ^ bugworthy? [00:37] ubottu: auth required =( [00:37] Error: I am only a bot, please don't think I'm intelligent :) [00:38] lifeless: I noticed, but the repos are read only, so it should work, right? [00:40] the lp: shortcut uses the smart server, i guess it would work if you use a http: url manually [00:40] at least that's what i observed last time i had problems being behind a proxy and firewall [00:41] zsquareplusc: thats not really connected to this issue [00:41] peng_: yeah, it's read-only for now [00:41] hoelzro: yes it should work [00:43] lifeless: the lp-resolution problem is already reported [00:43] lifeless: my idea was that http should work as it's guaranteed read only. "lp:" doesn't use http i think [00:43] (reported by me, just after the last rollout) [00:43] zsquareplusc: lp: will use http if you're not logged in, and http still does db access [00:43] zsquareplusc: all of launchpad *should* work in readonly mode, with write *attempts* failing. branching isn't a write attempt. [00:44] But codehosting is entirely down during read-only mode ATM. [00:47] lifeless: LP is in readonly [00:47] lifeless: we need better errors [00:47] lifeless: so yes, bug worthy [01:13] igc: did you see ej around at all? [01:34] morning [01:34] poolie: I didn't [01:49] I upgraded to 1.18 from 1.14 and I got this error when I ran `bzr version`: "Key 'foreign-mapping-upgrade' already registered" [01:49] Unable to load plugin 'rebase' from '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bzrlib/plugins' [01:52] you need to upgrade your plugins too [01:53] I thought I did [01:54] lifeless: Doesn't the installer do that? [01:54] (Mac OS X 10.4) [02:03] hi again [02:04] if you use fast-import to filter a directory out, does it work on all files within it? [02:08] hmm... unusually quiet tonight... [02:10] hm [02:11] GPHemsley: only the plugins it included; you may have installed others [02:11] GPHemsley: also I think there was a bug in the 1.18 installer or something, now that I think about it [02:11] meh [02:12] I seem to recall that being the case a couple of version ago, too :( [02:21] actually, yeah, this problem was causing trouble the last time I was here [02:21] when I was trying to get svn-bzr (or bzr-svn, I forget) to work [02:22] your bzr.log should show the path to the failin import === SamB_XP_ is now known as SamB_XP [02:24] lifeless: http://gphemsley.pastebin.com/d20033a0a [02:32] GPHemsley: it does look like an old rebase to me [02:33] lifeless: It's 0.5.4, from what I can gather [02:34] oh [02:34] hmm [02:34] bzr_plugin_version = (0, 5, 4, 'dev', 0) [02:34] bzr_compatible_versions = [(1, 14, 0), (1, 15, 0), (1, 16, 0), (1, 17, 0)] [02:34] I may have compiled this myself when I was having the problem with svn [02:40] lifeless: WCS, how do I uninstall these plugins? [02:42] igc, i'll try to set up the site somewhere on orcadas this afternoon [02:46] GPHemsley: delete the directory [02:46] lifeless: hi, it seems that the diff generated by bzr diff -r ancestor:lp:moin-solenoid on the update-merged branch is exactly the same for -r 22..23 on rebased one :) [02:46] oh, that simple? [02:46] GPHemsley: yes, plugins are discovered bywalking the directory layout on disk [02:47] lifeless: but the problem is: how to make that diff --after merging with trunk-- :( [02:48] lifeless: in the rebased branch, the diff can be extracted from the trunk, even after deleting the feature branch [02:49] lifeless: unsing branch diff, I need to keep all feature branches forever even after merging them into trunk [02:50] Is there a way to run a bzr diff -r ancestor:$trunk *after merging into trunk*? that is, some command on trunk that will result in the same diff [02:52] ok, i successfully removed the contents of my examples/ directory from every revision of my project with the fast-import, but how do i actually remove the directory? [02:53] >.< scratch that, i still have a 10 MB .pack file [02:53] sorry if I'm being unclear, am I? [02:54] hm, seems like everything is smaller though [02:54] RenatoSilva: it can without rebase too [02:54] RenatoSilva: diff -c -1 [02:55] i did this bzr fast-import-filter ame.fi -x examples/ > amethyst-mm/new.fi [02:55] should i do bzr fast-import-filter ame.fi -x examples/ -x examples > amethyst-mm/new.fi [02:56] Is there a way to edit the information of a commit after it's already been committed? [02:56] specifically, the committer info [02:57] (`bzr whoami`) [02:58] you can reroll the whole repository, but i think that's overkill [02:58] poolie: that would be great. I need to head off around 3pm for a medical appointment but I should be back later [02:58] GPHemsley: imediatelt after you can use uncommit + commit [02:59] * igc lunch [03:00] lifeless: oh! it's just a single diff command :) [03:01] excellent, thanks, lifeless [03:02] lifeless: bzr diff -r 22..23, bzr knows here that 22 is a merge and switch to a branch diff, right [03:03] lifeless: I'll try to understand it later, what matters atm is that it just works :) [03:05] but because of the clearer history, it still seems to me that rebasing is a good option for "unbranchable" branches :) [03:18] ugh :/ [03:18] how do you filter out a directory with fast-export [03:20] meoblast001: I don't know; I'm not answering because I don't know. [03:20] meoblast001: if the docs don't tell you, file a bug about that; then ask a question on the project :) [03:20] i read the help page [03:23] lifeless: i honestly don't know if i'm understanding the docs [03:27] I also couldn't figure that out the other day, so I'd go ahead and file the bug [03:27] meoblast001: if you can't understand it, it needs to be clearer :) [03:29] if you can't TELL, they still need to be clearer ;-P [03:29] i'm not sure if it's actually addressing the point i'm wondering about, or not [03:29] i don't think it is though [03:29] i think it's just saying you need a trailing slash on directories (which i did) [03:32] again, you're not sure. So its a bug. [03:32] please file it? Pretty please? [03:33] lifeless: i have to double check things before i file a bug, so i'll reread it again to make sure i didn't just have a "brain fart" [03:34] meoblast001: we like bugs. [03:34] ok, i checked it over, i understand it [03:34] meoblast001: the fact that you can have a brain fart is usually a sign of something we can improve. Please share these opportunities with us! [03:34] meoblast001: well, file one anyway [03:34] but i think the problem is that it's not deleting the directory [03:34] only the contents of the directory [03:35] lifeless: if i file a bug we'll hit 4294967296 bugs [03:35] and we all know what happens then [03:35] meoblast001: there's another line of thinking where you just file a bug, even if it is invalid. In lp it can be converted to a question/answer. The point here is have a documentation of the issue itself, so that other people can find iformation about the same problem [03:36] meoblast001: for example you file a bug because you want Ubuntu blue. Then it's marked as won't fix. When other people go file the same bug, they'll find that bug and know that it won't be implemented. They can comment and ask please please. Maybe if millions of people do that Ubuntu could become blue someday :) [03:38] RenatoSilva: i want Ubuntu to be blue to be honest [03:38] ouch, my eyes [03:38] meoblast001: well, me too :) [03:38] i want to switch to gNewSense sort of, it's a stripped down Ubuntu [03:38] i wonder if Canonical would ever make gNewSense official :) [03:39] they would need permission from it's creators (one of which i know on IRC) [03:41] I'm pretty sure we'd be delighted to be able to stop shipping firmware etc, but its very bad for users to do that at the moment. [03:43] bad for users to do? [03:44] someone on Ubuntu brainstorm thinks i'm RMS :P [03:44] * RenatoSilva don't want Ubuntu blue, maybe [03:47] is there any way to ignore spaces / tabs /line-break style on bzr diff? [03:47] meoblast001: users being unable to use their own hardware [03:47] RenatoSilva: content filters can do it; you need to be using 2.0.0 [03:47] ah yes [03:48] i recently had to use a firmware (i switched from NVIDIA to ATI) [03:48] at least my drivers are freed now :) [03:48] lifeless: I'm worried about plugin compatibility like bzr-xmloutput and bzr-email [03:49] lifeless: I wonder whether UNIX diff command can do that too, it should I think [03:49] lifeless: if you just s/\r\n/\n, diff will think yo've replaced the file completely, when in fact it is semantically equal [03:50] only for some languages [03:50] other languages consider them semantically different [03:50] [many of which are 'binary'] [03:50] because of style of line breaks ? o.O [03:51] this is so strange [03:52] well a diff ignoring \s and kind of \n wouldn't be a real diff, e.g. for patching, it's just a nice view of the diff for the user [03:52] my examples/ directory still exists :/, i wonder if specifying "examples/./" would help? [03:53] meoblast001: filed the bug ? [03:53] i'm not sure if it's a bug though [03:54] lifeless: you asked before 'did i commit a conflict' and i didn't mean to commit a conflict [03:54] and now i see spiv has also got conflict markers in his cleanups mp [03:55] so i suspect a bug in lp [03:55] thumper: ^^ [03:55] poolie: merge proposal diffs are merge --preview style diffs now [03:55] poolie: so conflicts are possible [03:56] Huh. [04:04] lifeless: so you want me to file a bug? [04:05] yes! [04:05] even if it might not be one [04:05] on bazaar? [04:05] i should probably do it on this plugin [04:06] mwhudson: thumper: will they update now? [04:06] meoblast001: bug reports are a sign that something might be wrong, not a statement. [04:06] lifeless: yes [04:06] meoblast001: and yes, on the plugin please. [04:06] mwhudson: _THANKS_ [04:06] lifeless: thank abentley, i had nothing to do with it! [04:07] it was to the team :) [04:07] abentley: thanks [04:07] lifeless: is this related https://bugs.launchpad.net/bzr-fastimport/+bug/410140 [04:07] Launchpad bug 410140 in bzr-fastimport "pruning of empty directories" [Medium,Fix committed] [04:07] it looks like a similar problem [04:11] it appears from that bug that it should be fixed [04:11] but i'm not seeing it here, and this is a fresh checkout [04:13] lifeless: the script isn't running [04:13] lifeless: but it should soon [04:13] lifeless: the losas have been busy [04:13] thumper: naturally [04:23] lifeless: https://bugs.launchpad.net/bzr-fastimport/+bug/435621 happy now? :P [04:23] Launchpad bug 435621 in bzr-fastimport "Specifying Directories to Filter only Deletes Subdirectories/Files, Not the Directory Itself" [Undecided,New] [04:23] meoblast001: thank you [04:23] :) [04:24] lifeless: i was just kidding, you're the one who helped m [04:24] me* [04:24] my only problem is that i planned to fix this by tonight >.< [04:34] what's a submit branch in zbr info? [04:36] *bzr [04:38] RenatoSilva: the default branch used by "bzr send", any maybe other things. [04:38] ok thanks [04:39] I sometimes use "bzr diff -r submit:" in my feature branches to see what I've changed vs. that branch (which is usually lp:bzr, for me). [04:40] isn't it bzr diff -r ancestor:$trunk? [04:41] Yes, that's often the same. [04:42] or rather, if $trunk in your example is the submit branch, then it's exactly the same. [04:43] But "submit:" is shorter to type :) [04:43] true, gotta write it down somewhere :) [04:45] lifeless: i fixed it now :/ [04:45] so the bug report was useless [04:46] * RenatoSilva doesn't like bugs that much either [04:53] how to find revisions that fixed certain bug (committed with --fixes=) [04:53] can't find anything in bzr help diff [04:54] *log [04:58] sleep time, good night [05:26] vila: nice [05:27] lifeless: ? [05:49] bbl [06:00] hi vila === BasicPRO is now known as BasicOSX [06:16] poolie: not really there yet :-) I'll say 'hi' then... [06:17] ok :) [06:26] reading your new shell-like diff now === oubiwann_ is now known as oubiwann [06:58] What's the proper way to get a revision's timestamp into a datetime? [06:58] (I should say timestamp plus timezone) [07:00] Oh god. Just thinking about that makes my brain shut down. [07:02] Peng_: I take it that's a "no" on an easy solution? [07:02] ugh, where has the day gone [07:02] jtv: it is one ? [07:02] lifeless: it's gone over here, to the west of you [07:02] jtv: That's my standard reaction to mention of datetime. [07:03] lifeless: that's what I thought, but when I try to subtract a timedelta, I get an error saying the timestamp was a float. [07:03] There shouldn't be anything bzr-specific about converting timestamp + tzoffset into a datetime. [07:03] Unless bzr has a nice API for it or something. [07:04] Peng_: the timezone offset doesn't seem to be the one that datetime.fromtimestamp expects. [07:05] jtv: pydoc bzrlib.osutils [07:05] datetime.fromtimestamp can take timezone offsets? [07:05] Peng_: yup [07:05] jtv: has bits in there. [07:06] lifeless: they all seem to involve turning it into text and then parsing that text though [07:06] seems brittle [07:07] jtv: well, I"m not saying there is exactly what you need [07:07] just that you should find the closest function, and then refactor it;) [07:07] I think I can use datetime.utcfromtimestamp [07:07] but then should I add the timezone to the timestamp, or subtract it? [07:08] Hmm... contrary to reason it also seems to produce a timezone-naïve datetime. [07:09] the python datetime module? [07:10] hi all [07:10] you need to subclass tzinfo [07:10] lifeless: yes [07:10] !? [07:10] have I mentioned I hate that module? [07:11] have a look at subunit.iso8601 [07:11] or if its bundled on your system is8601 [07:11] lifeless: you haven't mentioned it to me yet, but I'll have you know it wouldn't shock me [07:12] what is subunit? [07:12] * vila takes a deep breath and restart yet another build failing on a time related issue... [07:13] its a testing protocol library I develop [07:13] its relevance here is simply that iso8601 is an MIT licenced module I embedded [07:13] . o 0 ( The common cause between all of them seems to be..... using a virtual host.... ) [07:14] lifeless: I have an iso8601.py lying around. [07:14] look for Yoinked [07:14] lifeless: nope [07:14] not found [07:15] class Utc(tzinfo) [07:15] lifeless: got it on google [07:16] okayyyy... what's wrong with regular UTC? [07:17] datetime.fromtimestamp(revision.timestamp + revision.timezone, UTC) does complete successfully... the + is a guess though. [07:18] jtv: where is UTC defined? its not in the datetime module ... [07:19] lifeless: pytz [07:19] ah [07:19] not in the stdlib :) [07:23] vila, shell-like-ears +1 [07:23] also http://www.phrases.org.uk/meanings/414550.html [07:26] poolie: wow :D A bit of explanation may be ? Should I continue or should I stop using "shell-like" ? [07:26] continue :) [07:26] it's a nice name [07:26] jtv: timezones [07:27] Can it be interpreted as "we listen to you: we help you write tests" ? :D [07:27] lifeless: ? [07:27] jtv: the offset is the offset of the time when it was recorded; so if it was recorded at +3600, you would subtract 3600 to get UTC [07:27] however, what you probably want [07:28] is fromtimestamp(timestamp, magic_tzinfo(offset)), [07:28] magic_tzinfo? [07:28] you get to write that [07:28] a factory to get the right thing from pytz, or curry a class on the fly [07:29] datetime is _not_ a good example of easy to use API [07:29] poolie: that's the kind of surprise I love after using a word (shell here) for more than 20 years without realizing some of its other meanings [07:30] lifeless: seems overkill... I don't give a rat's kidneys about the timezone—all I want is the UTC time. [07:31] * jtv fondly reminisces the lady who tried to get "the real time" from a stewardess on a transcontinental flight... [07:31] (The continent in question being Eurasia) [07:32] "Yes but what time is it on the plane?" [07:33] * vila giggles about the TRUE things (time is a funny example of that, but many people also have strong views about pasta, chocolate, ice cream, you name it ;) [07:33] vila: don't get me started about True Internet, basically the only alternative to state-run internet here... [07:36] jtv: hehe [07:50] kfogel: ah! I'm going to look at your merge proposal today (after all my lectures are over in ~9 hours). Sorry it took so long [07:59] jelmer: whats the purpose of subvertpy.NODE_NONE/NODE_UNKNOWN [08:00] jelmer: oh, and RemoteAccess.check_path doesnt normalize leading '/' [08:15] back [08:21] lifeless: printf debugging tells me that the timestamp in a revision is already in UTC, so I can ignore the timezone. Just datetime.fromtimestamp(revision.timestamp, pytz.UTC) does the trick. [08:21] jtv1: hmm, I'll have to check the source to be sure. [08:22] time to learn more RDF [08:23] lifeless: I commit to a branch, then I look up the revision and run its timestamp through that, and it gives me (roughly) the current UTC time. === jtv1 is now known as jtv [09:11] Can anyone besides abently do a bzrtools release? [09:13] jelmer: will you be doing a bzr-svn 1.0 release before tomorrow? [09:17] hi johnf! [09:17] poolie: howdy [09:17] hello bzr [09:18] johnf: i don't think anyone but abentley regularly _does_ releases [09:18] this is a drawback of having them version-locked and recommended by the package... [09:18] yeah [09:18] bzrtool 2.0.0 is released [09:18] but it expects bzr to be version 2.0 not 2.0.0 [09:19] I'll just fix it manually for now in the PPA [09:19] good idea [09:20] johnf: no, I doubt I will have time for that. [09:20] I'd love to move to a process where when bzr goes rc1 all the plugins aim to do a final release or something. Trying to keep plugins in synx seems to be the most difficult task [09:20] jelmer: no probs I'll just use the rc [09:21] johnf: there's still a couple of test failures that have to be fixed before a final release [09:21] jelmer: Are they major enough to not copy it to ~bzr PPA? [09:23] johnf: no [09:24] * bialix shocked by new LP UI [09:24] they killed Kenny! [09:24] bialix: you don't like it? [09:25] mmm, not really [09:25] I'm very conservative perhaps [09:25] and used to old UI [09:25] this new UI is TOO radical change for me [09:26] but my first reaction was not positive, sorry [09:28] although big green button for release downloads is definitely cool [09:29] never mind me [09:31] Is it...chartreuse? [09:54] * igc dinner === doko_ is now known as doko [11:19] Hi all [11:20] Please will someone take a look at https://code.edge.launchpad.net/~garyvdm/bzr/get_trees_and_branches_to_diff/+merge/12077 [11:22] garyvdm: There's no newline at the end of test_diff.py. :P [11:22] Peng_: Ok - I'll fix that. [11:25] I don't have the knowledge to do real reviews, but I figure my nitpicking makes things a little cleaner, and saves someone else from having to think about it... [11:25] Thus Peng_ explains the justification for his existence. [11:26] I should've gone with "In which Peng_ attempts to justify his existence." instead. [11:27] Peng_ is clearly attempting to pass the Turing test. [11:29] Superseded request: https://code.edge.launchpad.net/~garyvdm/bzr/get_trees_and_branches_to_diff/+merge/12341 [11:30] error: must supply either home or prefix/exec-prefix -- not both [11:30] ^^^ following instructions in the INSTALL file [11:30] being: python setup.py install --home ~ [11:30] bzr-2.0rc2 [11:30] Python 2.6 [11:37] strk: That's exactly the command line you ran? [11:38] python setup.py install --home $HOME [11:38] python setup.py install --home ~ [11:38] tried both.. [11:38] same error [11:38] .....Huh. [11:39] strk: I think what you want is python setup.py install --home [11:39] hi garyvdm [11:40] Hi Alex [11:40] can you refresh my memory: why qbzr needs branches for diff? [11:41] error: option --home requires argument [11:41] garyvdm: ^^ [11:41] for: python setup.py install --home [11:41] To get the revno for the revisions to display in the title, and if the branches are different, it also show the locations of the branches. [11:42] strk: sorry - I don't know then. [11:42] garyvdm: ok, understood [11:42] * garyvdm -> lunch [11:42] * bialix too [11:44] Does installing other Python apps work? [11:44] haven't tried [11:45] lemme try paramiko... [11:47] alright, same error with that command line for paramiko [11:48] using --prefix instead of --home seems to work fine for bzr [11:49] worth noticing in the INSTALL file === strk is now known as strk_lunch [12:25] hi all [12:25] I have a small query concerning qbzr [12:26] maybe qbzr log should sort revisions based on the commit timestamp when there is a tie about what to show [12:26] I have got multiple release branches that represent the release series, and that are not merged in the mainline and will never be [12:27] qlog shows the release branches at the top of the graph even if the commit is 2 months old [12:38] jelmer: what should I be branching off to create debian packages of bzr-svn? http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable [12:52] asabil: https://bugs.launchpad.net/qbzr/+bug/321389 [12:52] Launchpad bug 321389 in qbzr "bzr visualise: sort by date" [Low,Confirmed] [12:52] garyvdm: ah thanks, didn't see that one [13:21] johnf: yeah === strk_lunch is now known as strk [13:22] johnf: I've just released 1.0 btw [13:22] johnf: theres a new loom release too :) [13:22] jelmer: Also I finally got back my DD status today. So when you have a moment would like to talk about the bzr-pkg team and how to start helping out [13:22] * lifeless shoves work johnf's way [13:22] johnf: package shit & up load it ;) ? [13:23] lifeless: I'm in total package mode and aim to keep working through plugins till midnight :) Feel free to prioritise. bzr-svn is at the top of the list [13:23] johnf: loom isn't high, but would be nice to have; it breaks switch -b rather badly using the packaged version :) [13:24] johnf: bzr-loom in debian needs some work in particular [13:24] jelmer: what does it need? [13:24] lifeless: somebody to keep an eye on it mainly [13:24] Although I fell I'm about to be sidetracked by continuing jelmer's work from a year ago and making autoppa use builddeb [13:24] lifeless: and I think you have an open bug about it being out of date [13:27] johnf: I've also orphaned trac-bzr earlier, you might want to pick it up if it interests you. [13:28] yay johnf [13:30] johnf: I would like to get qbzr in to debian. I got to run now, so I'll send you a mail... [13:31] johnf: I'm half inclined to start a bzr-miscplugins package. [13:32] I'd shove bookmarks and extcommand into there. [13:32] jelmer: its out of date cause it hasn't been updated ;P [13:32] What I'd like to do is plugin-info -> debian/control [13:32] and bzr-log -> debian/changelog [13:33] possibly wants doap rather than plugin-info [13:33] lifeless: we did a simple script that does the first bit (plugin-info -> debian/control) at debconf [13:33] lifeless: basically will update dependencies on bzr based on info in plugin-info [13:33] jelmer: cool [13:34] jelmer: have you seen moap? [13:34] lifeless: yes [13:34] lifeless: I mentioned it in my reply to you about doap [13:34] Bye all. [13:38] jelmer: oh hmm, must have dropped that mail somewhere [13:39] I spent this avo looking at rdf tools; rather a sad landscape after so many years [13:39] lifeless: indeed [13:40] lifeless: I can forward that email again if you can't find it. It contains some complaints about moap :-) [13:40] please [13:41] ah found it [13:41] you did a pile of bug noise after it [13:42] I'm crashingish, too tired to reason well [14:13] How do you find out what version a checkout is on? [14:14] bzr revno [14:17] thats tells you the latest revno of the tree not what the local checkout is updated to... [14:21] The branch, not the tree. revno --tree tells yo uabout the working tree. [14:22] hmm, could it be that 2.0rc2 isn't tagged yet? [14:31] fullermd: ty :) [14:31] IslandUsurper: thank you (should of looked up its parameters) === strk is now known as strk_away [14:57] is it possible to update just one file in bzr like you can in svn? [14:59] тщ [14:59] no [15:00]