[00:00] morning [00:01] goooooooood morning igc [00:01] igc: you in australia or something? [00:03] Pilky: yes, Brisbane [00:04] morning beuno! [00:04] jelmer: ping [00:08] thumper, pong [00:09] jelmer: lp:~jelmer/python/trunk is this still wanted? [00:09] jelmer: it is having problems scanning [00:26] jelmer: around? [00:28] thumper: no, should be ok to remove [00:28] LaserJock, hi [00:28] jelmer: it's me again :-) [00:28] jelmer: I'm trying to get bzr-svn going on Fedora 9 [00:28] jelmer: do you want to delete it or shall I? [00:30] jelmer: when I try to use bzr-svn it gives me "Installed Subversion version does not have updated Python bindings." [00:30] thumper: I don't think I can, can I? [00:30] jelmer: you should be able to [00:31] I looked in the bzr-svn README about the issue, but I'd like to avoid having to build my own Subversion 1.5 if I can [00:32] jelmer: I wondered if you'd had other people wondering about bzr-svn on Fedora. Surely somebody must use it [00:33] LaserJock: you do really need to have subversion 1.5 or 1.4 with the patch, there's no way around that [00:33] afaik everybody who has used bzr-svn on fedora has done the patching [00:34] jelmer: ok, do you know where the patch is? [00:34] LaserJock, yes, it's linked from the bzr-svn wiki page [00:34] doh [00:36] thumper: hmm, it's mirrorred so it'll just be recreated next time I run my register branches command :-/ [00:37] thumper: I'll see if I can create a new branch from python svn and upload that [00:37] jelmer: ok [00:39] jelmer: lp:~jelmer/bzr-gtk/AUTHORS?? [00:39] thumper: yeah, error in my script that did the registration :-/ [00:39] jelmer: are you going to clean up those branches? [00:40] jelmer: https://code.edge.launchpad.net/~jelmer/ shows lots of mirror failures [00:50] thumper: are the failures a problem? The web ui doesn't make deleting them very easy [00:51] jelmer: no not really a problem, it just looks messy :) [01:23] moin [01:27] how do i remove a stale bzr lock? [01:28] "bzr break-lock URL" [01:28] awesome, thanks! [01:28] spiv, maybe we should add that to the message that says the repo is locked? [01:29] beuno: yeah. I think there's even a bug about that :/ [01:29] * beuno goes look [01:36] found it, bug #139202 [01:36] Launchpad bug 139202 in bzr ""Could not acquire lock" error doesn't tell you how to fix it" [Medium,Triaged] https://launchpad.net/bugs/139202 [01:39] * beuno diggs into the code [01:40] heh, i thought from the summary that that was probably an mpt bug [01:41] does it take a while for launchpad to recognise a push to it on the site? [01:41] Pilky: it can take a minute or two [01:41] ah there we go [01:50] jelmer: woot! I finally built new Fedora 9 subversion rpms and bzr-svn now loads [01:51] LaserJock, nice [01:51] would you perhaps be interested in putting them up somewhere and linking to them from the wiki? [01:51] I was just thinking of that [01:51] it'd be a shame for me to horde them all to myself ;-) [02:14] jelmer: alright, all done, have a look at http://bazaar-vcs.org/BzrForeignBranches/Subversion#fedora-9-i386 and see if it looks ok [02:17] jam, did you work out what was wrong with your ssh keys? [02:17] unfortunately right now I can only make i386 rpms [02:56] Hi Folks. I have a repo (via init-repo) with no files in it, and I'd like to create a new repo style branch (NOT in init-repo) that also has no files in it. [02:56] Sort of like I had "branched" from the original, then "pushed" elsewhere. Possible? [02:57] I don't see a --no-tree option on a lot of these things. [02:58] yeah, i think that must be possible but not necessarily from the command line [02:58] Ah. [02:58] Hm. [02:58] probably easy-ish to do it in a plugin [02:58] how badly do you want it? :) [02:59] I just have a bash script. Running it against the output of a cvsps conversion to arrange the repo how I want it. [02:59] So it's not really worth it. [02:59] I can just "branch" to a staging area, then from there, "push" it to the "source-of-truth" area. [03:00] Hm. Can I do a push from a repo with just a .bzr in it and end up in the same place? [03:01] I think that works, actually. [03:01] Yep! [03:03] yes [03:03] Faster, too. [03:03] you can also do a regular branch, then 'bzr remove-tree' i think it is [03:04] though this is obviously a bit of a waste of effort :) [03:04] Yes. I'm glad I didn't see that earlier. [03:05] My experiment here is to see if we can organize project repos by releases. [03:05] Sort of ruins the shared-branch repo thing, but ah well. [03:16] another way: mkdir foo ; bzr init foo ; bzr reconfigure --branch foo ; bzr push ~/repo/blah foo [03:18] Cool. [03:19] The push method (just have bash cd in and push) worked, but, alas, the branches are not consistently named. Still, it mostly worked and was slow only on the project with 8000 revisions. [03:55] * igc lunch [04:23] spiv, i'm reading your patch [05:00] poolie, lifeless, are you guys coming to DebConf after all? [05:09] beuno: i am not, i think robert may be [05:11] poolie, ah, ok. Because I just saw you guys didn't send a talk for bzr [05:11] man, using bzr on launchpad on an old-ish os x/ppc laptop hurts a bit [05:42] * igc pick up kids [06:48] beuno: poolie: I'm not as far as I know; we had discussed my going to talk but that was all [06:49] lifeless, well, you can still organize one or two BoFs [06:50] are you registered? [06:51] no [06:53] au, I suppose you don't need to get sponsored anyway [06:54] well, if you do decide to come, let me know and I'll do as much as I can to help out [06:55] unless canonical actively wants me to go, I doubt I will at this point [06:57] well, poolie, ball's in your court now :) [07:00] any loggerhead users? [07:00] i am a loggerhead developer, for my sins [07:01] can I serve non-public branches? [07:01] i think i need more context [07:01] before i can answer that question [07:02] my first problem is noone can see whats in my repo [07:03] secondly I have two private clients [07:03] i don't understand the first problem at all [07:03] 'see'? [07:04] for the second, i'd run loggerhead behind apache and do authorization type stuff in apache [07:04] so they need to see what in my repo, but not what is in eachothers reps [07:05] iam thinking tubogers is too much hassle [07:05] i love my isp! [07:06] keithy: it's getting late here, so if you mail the bazaar list i can try to help there [07:06] or you can try to get life out of someone else here :) [07:06] keithy, I'll give it a try [07:07] you want to setup loggerhead, which gives access to different branches depending on the user? === jml` is now known as jml [07:09] beuno: yes thats about it [07:09] last time I tried I gave up at turbogears [07:10] keithy, I can't think of a straight forward way of doing that, unless you run multiple loggerhead instances in different ports, and do some magic from apache [07:10] man [07:11] why are bzr branches so invisible [07:11] keithy, invisible in what sense? [07:11] well on mac os x all you see is an empty directory [07:12] keithy, that's because it's a hidden directory [07:12] .bzr [07:12] right... [07:12] ls -a should show it to you [07:12] so how is anyone able to know what branches you have to push to? [07:12] keithy, either where you branched from, or you specify it once, and bzr remembers it [07:18] arg I dont want to have to install XCode on my server [07:18] keithy: I would run three loggerhead instances: [07:18] so how do I install turbogears? [07:19] keithy: 1) with your branches that are public, 2) with client A's branches, 3) with client B's branches [07:21] why cant I install turbogears without having to put 2Gb worth of XCode on my server [07:23] is there a simple way to find all revisions that change a particular file from python, or do I have to look through all revisions and filter them? [07:33] that's it for me [07:33] g'night all [07:38] arg even fink wants xcode [07:40] igc, thanks for the reviews! [07:45] poolie: np [08:03] igc: see https://bugs.launchpad.net/bzr-fastimport/+bug/232177 [08:03] Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New] [08:03] lifeless, so... the bzr process is still running on add universe, RSS is 6.7 GiB, and strace tells me it does brk occasionally, but nothing much else [08:03] liw, hi [08:04] poolie, greetings and salutations! [08:05] gour: thanks for putting that issue in and collecting your progress [08:05] * igc dinner [08:05] liw, if you're wanting to see where it's spending its time try pressing C-\ but be aware there is some chance this may make it crash [08:05] poolie, I'm going to wait for lifeless to come and do that :) [08:05] :) [08:06] although I may have to find \ for him on this keyboard [08:24] mneptok: ping, can you have a look at bug #229076 and enlighten us ? [08:24] Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Fix released] https://launchpad.net/bugs/229076 [08:38] vila: enlighten you in what regard? [08:39] what is the setup of www.gnome.org, what is the server that close the connection when the header is 'User-agent' instead of 'User-Agent' ? [08:42] AFAIK, "User-agent" is non-RFC for HTTP1.1 [08:42] http://www.faqs.org/rfcs/rfc1945.html [08:42] http://www.faqs.org/rfcs/rfc2068.html [08:43] i agree it's a bit strict, but is is understandable, IMO [08:43] https://bugs.edge.launchpad.net/bzr/+bug/229076/comments/13 [08:43] Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Fix released] [08:43] it's a bit clear that header names are case-insensitive :) [08:44] taken straight from rfc2616 [08:44] anyway, the bug has been fixed, what I'd like to know is what is the server that triggered it since that the first time we encounter such strictness [08:44] well "strictness" [08:46] the reply from www.gnome.org, port 80, includes: Server: Apache/2.2.3 (Red Hat) [08:47] lifeless, update: bzr is now continuing past the place it was stuck, I didn't do anything except kill the interactive python process I had open (the one on which you counted files/tips/whatever it was) [08:47] liw: yes, but apache2 itself has always been perfectly happy with that [08:47] vila, indeed [08:48] vila, could be a (transparent) proxy somewhere, perhaps [08:50] liw: hence the question :) My 8-ball doesn't reveal that transparent one :) Which by the way could at least politely answer with 400 or any 5xx :) [08:50] that's why I'd like to contact it to report the problem even if we fixed it on our side [08:51] yeah [08:52] vila: it looks like the case sensitivity is a deliberate change to the GNOME infrastructure [08:52] vila: it was put in place after DDoS attacks [08:52] it's not an optimal fix, but it works. [08:53] mneptok: rfc2616 - any captilisation is valid for field names [08:54] liw: interesting [08:54] lifeless: OK I'LL READ THAT AFTER I HAVE SOME COFFEE. THANKS FOR POINTING ME AT IT. [08:54] >:) [08:54] lifeless, now doing pool/universe/p/portsentry [08:54] Ok i SeE iF i CaN hElP yOu [08:54] :) [08:54] lifeless, I guess bzr was stuck into swapping mode for a while, but eventually got past that [08:55] lifeless, typical bzr processes are right now in the 20-30 megabyte range (for RSS) [08:55] * vila find the coffee idea too tempting to resist [08:55] liw: how long is it taking for each package? [08:55] liw: and what is the repo size up to ? [08:55] lifeless, a couple of seconds for most small packaes [08:55] poolie: got a few? [08:56] liw: (just du -sH .bzr/repository/packs) [08:56] lifeless, 17 GiB total in the directory, with 16 GiB in one big pack file [08:57] liw: I think it was paused doing a full pack :P [08:57] that's absolutely no history, right? [08:57] yeah [08:57] can you time doing a branch from one of those packages to a standalone branch ? [08:57] liw: ^ [08:59] lifeless, sure [08:59] aalib: real 0m2.370s [08:59] user 0m1.332s [08:59] sys 0m0.128s [09:00] (now I'm busy for a while) [09:02] liw: awesome [09:02] lifeless: the liw experiment is for all universe packages in hardy ? Sources ? [09:02] vila: unpacked sources, yes [09:04] awesome, 17GiB is cheap for that IMHO, is that an hint that one of my dream will come true ? Having all sources available in sync with my install ? [09:04] vila, it's still running [09:05] liw: ok, you will report here isn't it ? [09:05] vila, yup [09:05] great [09:07] lifeless: bzr-email is failing tests, I have a patch, should I send it to you or push to lp ? [09:10] send to the list with Merge/bzr-email [09:12] bzr-email/MERGE isn't it? [09:20] sounds plausible [09:24] james_w, lifeless: grr, so not only did I forget the /bzr-email and re-send it, but now I read that ;-/ [09:25] : [09:26] what's the difference between Branch.pull & Branch.clone? I'm guessing that the latter preserves format and the former doesn't? [09:26] also, clone needs a bzrdir it seems -- is this right? [09:27] pull mirrores between existing branches [09:27] clone makes a new branch [09:27] vila: what is should_send returning ?!1 [09:28] lifeless: I guess I meant in the case where a branch has just been created. [09:28] the email itself [09:28] eg.g bzr init; bzr pull [09:28] vila: then i don't think the fix is appropriate; for starts the method is wrongly named [09:29] lifeless: hey man, I fix the tests as they are because I'm tired of adding --no-plugins to selftest :) [09:30] vila: well, this is what review is for no? To identify slippery-slope events :) [09:30] LOL [09:31] lifeless: ok, you won. My daughters also found my weak point when I'm angry about them: make me laugh. [09:31] :) [09:32] seriously though, it sounds like something has creeped here, and that the method has come to have a different purpose - thats fine, but it should be trivial to give it a better name and then the test and code won't be confusing [09:33] def should_send(self): [09:33] return self.to() and self.from_address() [09:35] so it can return None or to() [09:35] + return bool(self.to() and self.from_address()) [09:35] 'return self.to() is not None and self.from_address() is not None' would be wrong, because '' is wrong for an email address [09:35] yes, thats good [09:35] that would avoid changing the tests [09:36] and about the name ? should_send seems to capture "check that we have enough info before sending" [09:36] I think the name is ok given the details we've just looke at [09:36] if it had been returning the email body as I thought you meant it would have been an issue [09:37] lifeless: Is there a way to pull stacked branches such that I only pull the stacked bit, and not the whole thing. [09:37] jml: I think you want init --stacked=url && pull in command line terms [09:37] jml: in library terms, doing branch.bzrdir.clone(target) should DTRT I think [09:38] lifeless: and pull as well? or just clone the bzrdir? [09:38] just clone [09:39] subsequent pulls will preserve the stacking bit and add data not accessible as one would expect [10:02] if one uses 'restricted' subscription policy on launchpad, what is restricted to other lp members? [10:03] /to/for [10:07] gour: is this a restricted team? [10:08] poolie: ping [10:08] pong [10:08] poolie: i'm reading lp feature high. document, team managament section --> subscription policies [10:09] gour: restricted means that you hasve to invite people [10:09] poolie: and i'm interested if i create a project, how it can be managed...in the beginning we want a smaller number of devs to discuss and commit [10:10] lifeless: that's clear. but what will be seen by non-invited people? code, bugs, blueprints?... [10:10] gour: it des not affect visibility of the team, just how to get into it [10:11] lifeless: hmm, so everything is visible except commit rights? [10:12] gour: everything is visible, full stop. [10:13] lifeless: everyone can commit his stuff in main trunk? strange... [10:13] gour: no [10:14] gour: *membership* and *visibility* are differewnt [10:14] gour: membership grants commit rights [10:14] gour: everything is visible [10:14] lifeless: ahh, ok. that makes sense [10:17] I am trying to setup loggerhead [10:17] its complainging about no module sqllite [10:17] no mention of anything in the eadme's etc [10:17] readmes* [10:17] It hought squeak was bad at dependencies [10:18] I am beginning to feel there is some python initiation ritual I havent been through [10:18] or are you guys just used to things not working? [10:21] turbogears is rather painful; I believe the loggerhead devs such as mwhudson would like to use a different toolchain to ease the pain [10:21] seaside? [10:21] in this case I can help; there are sql alchemy optional modules or something under the hood there [10:22] so I need sql lite? [10:22] no mention of this in the docs [10:24] so not what do I do? [10:24] so now what do I do? [10:25] install pysqlite2 [10:25] how? [10:26] how do you normally install libraries on your OS? [10:26] download dmg and double click on an installer! [10:26] how else [10:26] so far I have needed c compilers [10:26] and all sorts [10:27] fink, darwinports? I don't use os x, sorru. [10:27] and they require xcode and xcode is 1G install [10:30] keithy: by a different toolchain I mean cleaner and more self containined python libraries [10:31] keithy: I suggest that you file a bug on loggerhead; I too have had trouble installing it [10:31] is python2.5's included 'sqlite3' module the same as 'sqlite'? [10:31] like seaside! ;p; [10:31] lol [10:31] it looks pretty dbapi2-y [10:31] bob2: it's sqlite [10:31] ah so it is loaded! [10:32] I winder where it si [10:32] I wonder where it is [10:37] would someone please to upload bzr-svn 0.4.10 to the bzr ppa? [10:38] lifeless, 39619 seconds total run time (real time), 21 G total pack directory size, 16 G for the biggest pack file, then 1.7, 1.6, 1.2, 0.39, and then pretty smal ones [10:38] so do I need to install sqllite3 separately? [10:41] so fink doesnt work [10:43] keithy: I'm sorry I can't be more help right now, I'm in a week long sprint of meetings [10:43] np [10:43] keithy: if you can put a bug/question against loggerhead in launchpad I think its likely you can attract mwhudon's attention in his workday which is GMT+12 or so [10:44] the dependency on sqllite is already in the bugs list [10:47] well I am talking about docs on how to get it going largely [10:47] -> going for a while [10:47] k cya [10:47] lifeless: is there a way to use the test machinery to create a branch with a specific branch format? [10:50] format= [10:50] lifeless: it's unclear whether that's a bzrdir format, a repo format or a branch format. [10:51] lifeless: I'm guessing there's something about the interrelation between formats that I don't get. [10:53] sqlite3 is included in pythin, why does loggerhead want sqlite [10:55] jml: format='dirstate' [10:55] bah, I have been sucked back into IRC. let me outta here! [10:58] lifeless: feel free to talk to me IRL. [11:03] lifeless, http://files.liw.fi/temp/output.log -- I forgot to capture theoutput of the universe run, but that's the one for the main run [11:13] after all that! loggerhead renders my hierarchical branches structure as flat! [11:19] I am dissappointed [11:21] Do you just add stuff to the top of NEWS when pathcing? [11:22] And does a small extra option for a command count as a feature or an improvement :-) [11:41] hi [11:41] "This transport does not update the working tree" means that there is another transport that support it ? [11:42] only file:// [11:42] or ssh if you have the update-after-push plugin installed (which just does 'ssh remotehost bzr co /path' [11:46] lifeless: ping [12:00] vila:I have noticed yours recent commit to bzr-gtk. Could you please merge https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? [12:01] One-line chages but close two bugs (I think). TIA, regards [12:04] matkor: better ping bzr-gtk@lists.canonical.com, it looks like I didn't really respect the process by pushing that way [12:05] if someone wants to migrate repos from darcs, no matter whether darcs-1 or darcs-2 format, and no matter how old are they, tailor is the only player which does the job atm - pull latest tailor and latest darcs. both darcs-to-git and darcs2git fails with either darcs-2 repo format or older date-format in darcs [12:05] matkor: wow, looks like your patch doesn't even appear on http://bundlebuggy.vernstok.nl/bzr-gtk/ [12:06] matkor: what you should do is send it to bzr-gtk@lists.canonical.com with [MERGE] in the subject or nobody will be informed of its existence, I'm not a core bzr-gtk dev, just an occasional contributor [12:07] ...or new tailor-0.9.33 [12:07] vila: should I subscribe or can I just send e-mail out of ist ? [12:09] matkor: I don't know for sure, look at https://lists.canonical.com/mailman/listinfo/bzr-gtk [12:11] ok tnx [12:19] igc: i updated 'darcs support' bug with latest info... [12:29] Is it OK to send bundle intendent to merge having target_branch: file:///home/users/matkor/src/bzr-gtk/trunk/ ? Which is checkout of http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ ? [12:35] matkor: taget_branch yes, that's how bzr calculated it, bonus points if public_branch is set though, look at bzr help send [12:42] vila: I got confused with: bzr send ./ http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ -r -3.. giving me: bzr: ERROR: No mail-to address specified. [12:43] matkor: add --mail-to bzr-gtk@lists.canonical.com [12:44] matkor: or use -o my.patch [12:45] matkor: but your public_branch is wrong, you should use *your* branch here, it's where the bundle can be merged from [12:46] errr, wait [12:47] bob2: any possiblity to get it on bzr:// transport ? [12:48] bzr send [12:48] matkor: ^ [12:49] visik7: not supported as yet, as far as I know [12:50] visik7: the idea is that you have working tree where you can.. work. So you need at least a shell access there, and then you can just do bzr co or bzr update [12:52] yes I'm in the process of misusing bzr as a deploy tool :) [12:53] 'couse I work with some pigs&dogs that puts their hands on the server so I need to track them [12:53] ghetto workarounds include push-after-update and bzr co from cron [12:55] ok, I have finished writing a storage plugin for my wiki that uses bzr repository to keep the pages and history. Would anyone want to take a look at it and maybe suggest doing some things differently? [12:55] TheSheep: based on some web framework ? [12:56] visik7: no, just wsgi [12:56] the code for the plugin is here (sorry that it's Mercurial) http://sheep.art.pl/devel/dandelion/file/tip/dandelion/plugin/bzrstore.py [12:56] :) [12:56] ahahah [12:56] funny [12:58] I had trouble for example with getting the list of all files that were changed in a revision [12:58] TheSheep: from the bzrlib or from the command line tool ? [12:59] visik7: from bzrlib [12:59] maybe whatching in the command line tool you got how it does [12:59] no ? [12:59] in the end I did [entry.name for path, entry in entries if [13:00] entry.revision == rev_id] [13:00] :) [13:00] repository.get_revision_delta or something like that [13:00] bzr: ERROR: Please specify smtp_server. No server at default localhost - how can I do it ? [13:00] bzr send does not mention any option for that ... [13:00] TheSheep: working_tree.commit(message="imported existing pages", author="wiki") [13:00] er, maybe you meant committer there? [13:00] and unicode(revision.message, "utf-8") [13:01] the decoding there is wrong, it's already unicode [13:01] luks: ah, I thought it stores bytes, cool [13:01] no, most things in bzrlib are unicode [13:01] matkor: -o foo.patch, then send it using your mail client [13:01] luks: isn't delta just another tree? [13:02] TheSheep: delta is the list of files that changed in a revision [13:02] great [13:03] I'm sure some parts of this code can cause nightmares for anyone familiar with bzrlib :) [13:03] not bzrlib relased, but you have some locking problems in try/finally there [13:04] it should be lock(); try: ... finally: unlock() [13:04] you have try: lock(); ... finally: unlock(), which might call unlock even if lock failed [13:04] ah, right, so that it doesn't try to unlock when the lock fails [13:04] thanks [13:04] bob2: Thats last option, seems $HOME/.bazaar is place where I should specify smtp server ... [13:05] matkor: yes, ~/.bazaar/bazaar.conf - it presumably defaults to localhost [13:07] ok .. it went ... I doubt it gets through to bzr-gtk@lists.canonical.com with strange from adress ... [13:08] usually you want 'bzr send' to just launch an external mail client [13:08] How often http://bundlebuggy.vernstok.nl/bzr-gtk/ is updated ? [13:09] matkor: you need to set mail_client in bazaar.conf for that, smtp_server is adifferent beast [13:10] matkor: presumably http://bundlebuggy.vernstok.nl/bzr-gtk/ get the mails from bzr-gtk list so if you don't see your mail here neither does it [13:11] vila: I do not see even my subscribe confirmation mail .. but I am postgreyed so might have delays .. [13:12] matkor: just be patient then, may be an admin need to validate your subscription, [13:27] i'm new with bzr, but somehow feel strange that bzr status reports nothing when there is no change. what do you think about something like darcs' "No changes!" ? [13:30] gour: I dunno, I think you'll find you just adjust to the lack of output. [13:31] Odd_Bloke: i consider that providing some output is nice HIG [13:31] It does provide output, a newline followed by a prompt. [13:32] well, i'm serious [13:32] Me too, I don't want our UI cluttered up for no reason. [13:33] Just create a file and never add it. Then you'll always have output :) [13:34] Regardless, if you think something about bzr should be different, submitting a patch to the ML is a much better way of getting it discussed than IRC (especially as most of the core devs are probably in bed ATM). :) [13:34] pickscrape: i'm not interested for *any* output, but info that nothing changed [13:35] will do [13:42] hmm. let's say I cherry pick r3..6 from some branch, and later I just "bzr merge" from it, what would happen? [13:43]