[00:01] wgrant: Good enough, or you'd prefer other changes? [00:02] Looks quite reasonable to me. [00:02] Does it work? [00:02] The tests all pass [00:02] And I think I wrote enough of them. :-) [00:09] wgrant: https://code.launchpad.net/~stevenk/launchpad/bugs-information_type-mail/+merge/104483 has been updated. [00:14] StevenK: r=me [00:59] jcsackett, benji: ayt? [01:02] oh never mind === matsubara is now known as matsubara-afk [01:45] wgrant: when do you expect use_flat to be ripped out? [01:46] wallyworld: Of get_bug_privacy_filter? Undefined. [01:46] Hopefully within a week, but it's a bit hard to tell. [01:46] wgrant: ok. i want to use get_bug_privacy_filter() but it has no use_flat paparm; i'll add one [01:48] wallyworld: I have one added in one of my local branches, but it's like two lines and your branch will probably land before mine, so go ahead. [01:48] rightio [01:48] or if yours lands first, i'll deal with it. i have a few more branches to go yet [01:49] Yeah [01:49] It's going to be a pretty trivial conflict. [01:52] wgrant: it seems the gbpf doesn't have a term which queries on bugtaskflat.access_policies, only access_grants [01:53] wallyworld: Right, at present it doesn't use access_policies, because there are no policy grants. [01:53] There's a card in Next about making it do that [01:53] It's 3 lines of code, and if that function's used everywhere it'll apply everywhere [01:54] are there really no policy grants? [01:54] There are no policy grants yet. [01:54] That's an All permission [01:54] on qas there are :-) [01:54] Which don't exist on prod, because the UI isn't write-enabled. [01:55] True [01:55] wgrant: so if i want to use gpbf i will need that extra functionality. so i will have to pick up that card from the board and do that [01:55] wallyworld: Why? [01:55] i need it for the remove subscriptions job [01:56] No. [01:56] The current definition of access to bugs doesn't currently include policy grants. [01:56] yes, it was even in the query you pasted [01:56] It was, yes. [01:56] That'll be the final thing. [01:56] sure, but it's still correct to use it [01:56] But if you're going to use the existing function, you don't have to care about that stuff. [01:56] i will be writing tests which require it or else trhey will fail [01:57] Ah, right, it could make tests slightly awkward, indeed. [01:57] You can steal the clause pretty much verbatim from the query I pasted yesterday. [01:57] And stick it into the function. [01:57] yep [01:57] And it will Just Work™ [01:57] should do [01:57] hopefully [01:59] wgrant: is there a bug number? [02:00] Don't think so [02:01] ok, will raise one [02:01] You can probably find a bug search test to extend to cover APGs. [02:02] hope so :-) [02:17] wgrant: i can't find any bug search tests which create an artifact grant to give visibility; all the current tests seem to use subscription and reply on the triggers to update the artifact grant table. is that correct? [02:37] wallyworld: That's correct. Everything still assumes that subscriptions are the only things that confer access to bugs. [02:37] Now that legacy search is gone that can start to change. [02:37] wgrant: ok. i've found a doc test in bugtask.txt which i can add to i think [02:38] (there was no performant way to respect grants/policies in legacy search, so flat search was a prereq for all this) [04:46] wgrant: can you see why this test isn't working? the new one is the one at the bottom https://pastebin.canonical.com/65516/ [04:48] it fails because it still returns just the 3 bugs. perhaps it's not using the flat search? [04:54] wallyworld_: Non-flat search doesn't exist any more. [04:54] So it's probably using flat search. [04:54] wallyworld_: The bug isn't PROPRIETARY [04:54] wallyworld_: So the grant doesn't grant access to anything. [04:54] ah, USERDATA [04:55] doh [04:55] thanks [04:55] You'll want to ensure/find that, rather than create. [04:55] But yes. [04:55] USERDATA [04:55] yep [04:58] wallyworld_: Are you reviewing today? [04:58] StevenK: yes [04:58] wallyworld_: I have an MP up [04:58] It's only 221 lines, disappointing. [04:58] StevenK: sorry, wasn't running thunderbird [04:59] wallyworld_: Given your recent RAM issues ... :-P [04:59] yep :-( [04:59] I don't see why. [04:59] StevenK: i have to run out for 30mins to get kid from school [05:00] and buy ram on the way home [05:00] I have 4GiB of RAM with 64-bit, and I'm only 300MiB into swap with firefox, thunderbird, quod libet, gvim [05:01] wallyworld_: Given wgrant has wedged the deployment pipeline, it's not urgent. [05:01] ok. back soon. [05:01] I don't think I'll finish the garbo job this afternoon, sadly. [05:02] I wonder if the branch garbo job is doable using set [05:11] It should be, es. [05:11] yes [05:11] Since everything will just go to USERDATA [05:11] Everything? [05:12] It's either PUBLIC or USERDATA [05:12] Although I don't know if set() respects limits these days [05:12] Everything private. [05:12] Hm. [05:12] There may be few enough branches that a manual UPDATE is quick enough, too. [05:12] 500k on DF when I checked [05:12] And lifeless will smack us [05:14] Not sure how to use .set() against what I get back :-( [05:21] wgrant: Is "CASE WHEN Branch.explicity_private IS NOT NULL OR Branch.transitelvy_private IS NOT NULL THEN USERDATA ELSE PUBLIC" expressible in Storm? [05:22] StevenK: No, use an SQL(). [05:22] Also, that's redundant. [05:22] Oh? [05:22] explicitly_private implies transitively_private [05:22] And they're not likely to be NULL [05:22] They're boolean. [05:22] Oh, so just check transitively_private IS TRUE ? [05:23] s/ IS TRUE// [05:24] So if I need to use SQL, I need the entire statement. Bleh. === danhg_ is now known as danhg [05:46] StevenK: you will export IBranch.transitionToInformationType() later? [05:46] wallyworld_: After it does more than just blindly setting the information_type, yes. [05:46] ok [05:55] StevenK: i'm wondering if there needs to be a test like test_information_type_private_team to check that info type = public when required [05:56] wallyworld_: There is, that's why there is a few self.assertEqual(InformationType.PUBLIC, ...) scattered around the place. [05:56] ok [05:57] r=me, thanks [05:57] * wallyworld_ sighs. sometimes lp is so slow at updating diffs :-( [05:58] 528? When did that happen? [05:59] Mine, last night. [05:59] 526 527 were already taken [05:59] Ah [05:59] I suspect by stub test images, but that's merely a guess [05:59] didn't one of them go live? [06:00] wgrant: Do you think it's worthwhile adding self.log.debug() to the garbo job about progress? [06:00] StevenK: The looptuner should be enough output [06:00] At DEBUG2 [06:00] I think we run it at DEBUG2, too [06:00] Right, then I'll bug wallyworld_ again. :-) [06:00] stub: Your 525 was live. [06:03] wallyworld_: r=me [06:03] thanks! [06:09] Haha, 3 underscore Ian [06:09] wallyworld_{,__}: I have another one for you. [06:09] wallyworld_: A pretty quick dev-only one for you, if you still have time: https://code.launchpad.net/~wgrant/launchpad/easier-remote-access/+merge/104684 [06:09] Heh [06:09] me finds a screwdriver to add extra ramyou're so kind [06:09] sure [06:10] wgrant: You can review the garbo job branch, if you wish, it's +38 [06:11] I don't want to steal wallyworld________'s new non-swapping thunder. [06:11] But I might anyway. [06:11] Hahaha [06:11] StevenK: Your linebreaks are criminal, sqlvalues is evil, and you don't test public. [06:11] Also self.transaction wut? [06:12] wgrant: the branch looks ok but i'm not really sure i know enough to give it a proper +1 [06:12] The worst it can do is break new dev installations :) [06:12] And it doesn't break new dev installations. [06:12] WCPGW [06:13] r=me [06:13] Thanks. [06:13] np [06:13] wgrant: Without sqlvalues, it puts in 'User Data' which doesn't help [06:13] StevenK: Use the ? [06:13] SQL("foo ? bar ?", params=('whatever', 'oh look something else unsafe')) [06:14] Hm [06:14] Although it's possible that won't work for a dbenum [06:14] In which case I guess sqlvalues will have to do. [06:14] I can try ? if you wish [06:14] Or you could just use params= with .value directly. That's probably best. [06:16] Oh good [06:16] There's a third copy of those hostnames in lp-dev-utils [06:17] Hahaha [06:17] wgrant: http://pastebin.ubuntu.com/966263/ [06:17] wgrant: If it isn't duplicated it might be forgotten! [06:19] StevenK: Your linebreaking in the first hunk is still likely to draw criminal charges. [06:19] wgrant: http://pastebin.ubuntu.com/966266/ [06:20] Deindent line 13 and you're good [06:31] wgrant: Diff updated, please have a look. [06:34] StevenK: Branch.information_type is unindexed. [06:34] Hmmm [06:34] I sense a 2-statement DB patch in your fu=ture [06:34] Haha [06:35] wgrant: Two? [06:36] index + metadata [06:36] CREATE INDEX and INSERT INTO LDR [06:36] Yah [06:41] I think devel's versions.cfg still relies on some zope versions that are too old for Precise or something. I can't build on Precise, without bumping a bunch of versions in versions.cfg to the ones I actually have. [06:44] jtv: What's the error? [06:44] jtv: Perhaps it breaks if you have some old versions installed through apt (for maas)? [06:44] Otherwise you should use LXC. [06:44] Error: Couldn't find a distribution for 'zope.publisher==3.12.0' [06:44] etc. [06:45] Sure your download-cache is up to date? [06:45] No [06:45] I only have newer versions than what's in devel's versions.cfg. [06:46] wgrant@lamuella:~/launchpad/lp-branches/devel$ bzr ls download-cache/dist | grep zope.publisher [06:46] download-cache/dist/zope.publisher-3.12.0.zip [06:46] download-cache/dist/zope.publisher-3.12.1.tar.gz [06:46] wgrant@lamuella:~/launchpad/lp-branches/devel$ bzr ls download-cache/dist | grep zope.publisher [06:46] download-cache/dist/zope.publisher-3.12.0.zip [06:46] download-cache/dist/zope.publisher-3.12.1.tar.gz [06:46] Your download-cache must be bad [06:46] Bad in what way? [06:46] Bear in mind that I've been running Precise since January, and so haven't been able to run any Launchpad setup since then. [06:47] But I seem to get past this if I edit versions.cfg and bump z3c.ptcompat from 0.5.3 to 0.5.5; zope.app.component from 3.8.3 to 3.8.4; and so on. [06:47] stub: Can you have a look at https://code.launchpad.net/~stevenk/launchpad/db-branch-information_type-index/+merge/104689 ? [06:48] I can't seem to request a review of lifeless, but it's one index. [06:48] jtv: Which zope.publisher is in download-cache/dist in the branch you're trying to build? [06:48] jtv: Perhaps try make clean [06:48] jtv: It may still think it's using 2.6 or something [06:49] Crap — even “make clean” fails [06:49] rm: cannot remove `sourcecode/pygpgme/gpgme/*.so': Too many levels of symbolic links [06:49] StevenK: r=stub. That should go live? [06:49] jtv: I think your download-cache, eggs, sourcecode etc. symlinks might be a little screwed. [06:50] stub: As long as backups aren't in our way, yup. [06:50] They may well be. I haven't been able to run the rocketfuel scripts for so long. [06:50] They haven't changed since 2009, but maybe. [06:51] The scripts maybe, but I'm sure the data has! [06:51] load_cache fails: No JSON object could be decoded [06:51] * StevenK stabs Level3 [06:52] Trying more make clean & version bumps. [06:53] jtv: make clean and then cd into your download-cache and bzr up [06:53] The download-cache in the branch? [06:53] Which is a symlink [06:55] $ bzr up [06:55] Tree is up to date at revision 465 of branch bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-source-dependencies [06:56] Let's see what “make” does now. [06:56] stub: DB patch is on db-devel r11569. [06:56] ta. I've added it to my todo for when the backups complete [06:56] stub: Thanks. [06:56] wgrant: ^ Can haz approve for garbo job *now*? :-) [06:58] Wow, I managed to have a conflict in sourcedeps.cache. [06:58] Unsurprising [06:58] Really? And I was so proud. [06:58] StevenK: Why db-devel? [06:58] StevenK: Live patches go to devel [06:59] Bleh [06:59] wgrant: Merge it after Ian's FDT, then? [06:59] I guess. [07:00] \o/ I can “make.” Thanks guys. [07:00] It's the first step toward recovery :) [07:01] Our Makefile really needs work again. I had it doing parallel tasks, and not rebuilding mailman and css/js every time you rebuild the db schema at one point. :( [07:01] jtv: wallyworld___ has added things to prevent mailman building [07:02] I so hope I wasn't wrong in bug 994410. === almaisan-away is now known as al-maisan [07:26] StevenK: what did i do? [07:26] Hmm [07:26] Do I want to teach ec2 to preserve the buildout egg cache? [07:27] Hi people, is a tag added to an LP bug as soon as it is deployed to staging or qastaging? (we'd like to do integration testing as soon as bug 992691 lands on staging). [07:27] <_mup_> Bug #992691: Special permissions for 'Archive.commercial' are not needed < https://launchpad.net/bugs/992691 > [07:28] noodles785: Yes, it will have qa-needstesting added a few minutes after it's on either qastaging or staging. In this case you'll need to wait up to 12 more hours for it to hit staging, since it'll be on qastaging first. [07:28] wgrant: the egg cache is left pristine isn't it? I don't see why not. [07:28] wgrant: perfect, thanks! [07:28] However, the branch failed ec2 a couple of hours back. It's trivial to fix. [07:28] Also, you've been incremented by 10? [07:29] 10? 10 credits? [07:29] Ypi [07:29] Bah [07:29] You've traditionally been noodles775 [07:29] Hah, oh. === noodles785 is now known as noodles775 [07:30] noodles775: So, hopefully jml will be around to fix the test failure tonight. If not, I'll do it. Either way I'll reland it this evening, and it will be on staging when you start on Monday. [07:30] wgrant: great, thanks! [07:30] It's about 7-12 hours from landing to qastaging, and then another 13-20 after that until staging. [07:31] This'll hopefully be down to 90 minutes and 120 minutes once parallel testing is complete. [07:45] good morning [07:51] aloha [07:51] jtv: was bug 994410 supposed to be on LP rather than MAAS? [07:56] cjwatson: absolutely [07:56] And I work so hard to catch chromium at that. [07:56] Thanks. [10:12] Reviewer needed! https://code.launchpad.net/~jtv/launchpad/bug-994410-stop-using-latest_message/+merge/104703 [10:13] jtv: is there anything we need to be aware of when adding a new language in Ubuntu/lp [10:13] Yes: there are several very different things that people call “adding a language.” [10:14] https://answers.launchpad.net/launchpad/+question/195970 [10:14] wanted to add BRX [10:16] czajkowski: these people have really done their research. It answers all questions I might have; you're ready to go. [10:17] so the next bit is I've not added a langauge before and don't know where in lp I do this [10:17] so not sure I can also :/ [10:17] I don't think there's an ISO 639-2 code, so the 639-3 is fine. It's an Individual language code, not a Collective which we can't accept. [10:18] This is properly "adding a language" in Launchpad. Do you see the option just under “Available languages in Launchpad”? https://translations.launchpad.net/+languages [10:19] jtv: yes [10:19] Well there you go then. You've got the plural expression, language code, English name… [10:20] thank you [10:21] Please convey to them my appreciation for the care and effort they put into this request. [10:21] hello [10:21] I'm around to fix the test failure. [10:21] jml: Did you get the email? [10:21] wgrant: I think so. [10:21] I didn't realise my suggestion was so offensive to the test suite :( [10:24] jtv: thank for the help. [10:25] no worries [10:25] czajkowski: don't forget to enter the plural-form data! [10:25] wgrant: yeah. [10:26] wgrant: I like that we have auto-generated tests for IPersonRole, but that we don't auto-generate it ourselves. [10:26] czajkowski: there's 2 plural forms, and the formula is “n != 1” (I think entering it in that form will work) [10:26] jml: That is pretty cool, yeah. === al-maisan is now known as almaisan-away [10:28] stub: I want to drop a column from POFileTranslator, and stop the TranslationMessage trigger from writing it. Would it be best to do that in one patch? Or a sequence of smaller steps? [10:29] jtv: am trying but I keep getting an oops [10:29] Then I suppose the format isn't quite right. Have a look at other languages; see if you can crib the format. [10:29] jtv: One patch is fine, as long as the appservers have already stopped going near it. [10:30] OK thanks [10:30] Speaking of which, here's my MP for achieving that. :) https://code.launchpad.net/~jtv/launchpad/bug-994410-stop-using-latest_message/+merge/104703 [10:32] jtv: There is no problem doing both the column drop and the trigger change in one patch. Both are fast operations. [10:33] Thanks. Just wondering if there were multi-server rollout implications. [10:33] * jml fixes now [10:34] jtv: We *might* be able to twiddle the trigger live. The column drop has to go through fast downtime. Easier for everyone if it can go in one patch. [10:34] jtv: done [10:34] stub: very well [10:35] czajkowski: looking good [10:35] jtv: sorry about that peksy oops :) [10:35] Oh, the code change? Didn't take long to figure out. :) [10:36] stub: I suspect https://dev.launchpad.net/Database/LivePatching is far out of date [10:37] hey [10:37] are there any webservice tests written as unit tests? [10:38] is there any non-historical reason for writing them as doctests? [10:38] they clearly don't function as documentation for the actual users of the webservice. [10:38] jtv: Was this an example of a CRITICAL (genuine) bug drowned out by CRITICAL (policy) bugs? [10:39] jml: lib/lp/soyuz/browser/tests/test_archive_webservice.py comes to mind [10:39] (Quite a few others, 'find -name \*webservice\*') [10:39] cjwatson: thanks. [10:40] stub: arguably — in any case, we never actually seem to have made a decision to drive critical bugs to zero; we made a decision to allocate them some time, we announced that that would drive them to zero, and then we instated a policy for creating new ones at a faster rate. :) [10:40] :( [10:40] cjwatson, jml: Note that those tests use launchpadlib, and launchpadlib tests are *very* slow. [10:41] Most of the doctests avoid launchpadlib. I'm not sure if there are non-doctests that do. [10:41] Hmm. [10:41] Just thinking we knew this was a timebomb and we let it explode creating more work (cleanup) [10:41] stub: absolutely. [10:42] And the flood of policy-critical bugs gave us easier things to fix instead. [10:44] If you want to fill a bucket of dirty water with clean water, you can pour it out first and then refill it; or you can put it under the tap. But the latter is something you only do if you can't stand to be without a full bucket for a while. [10:44] wgrant: ok, that's fixed. r15203 [10:44] jtv: Are these tests you removing going to have to be rewritten when we maintain the latest translator asynchronously? [10:44] There will be other tests, but much simpler. [10:45] There won't be any complications from how data got where it is; it's either there or not there. [10:45] Dragging the data through the same changes as other data is what makes it difficult. [10:50] jml: It's in devel. [10:50] wgrant: oh, you just landed it directly? [10:50] jml: Yeah [10:50] No point re-ec2ing it [10:51] wgrant: I guess not. [10:55] Thanks for the review stub [10:56] Bah. Forgot the --incremental for r15204. :-( [10:56] Er… what's the current landing procedure? I've been away for a while. [10:57] jtv: bin/ec2 is now in lp:lp-dev-utils [10:57] So grab that, put it in your PATH, 'ec2 land' [10:57] Thanks. === Ursinha is now known as Guest7047 === adam_ is now known as aspiers === Ursinha_ is now known as Guest96131 === Ursinha__ is now known as Ursula === Ursula is now known as Ursinha === Ursinha is now known as Guest69236 [11:41] Grar. The bugs that come out of the woodwork when you start simplifying POFileTranslator. Should've done it years ago. [11:54] jtv: I know what you mean. [11:54] You've looked at it? Or seen the same thing elsewhere? [11:54] jtv: I don't think I've ever thought, "man, I'm glad I postponed cleaning that up, that made everything go so much better and faster" [11:54] jtv: same thing elsewhere. [11:54] Heh. [11:55] To be honest, I think by nature _not_ cleaning up pays off beforehand, unlike cleaning up which pays off afterwards. [11:56] But I don't think we've been sorry about having cleaned things up very often. :) [11:58] jtv: well, practically every time I've got some code and my understanding doesn't quite match it (or there's a clean up I can see), whenever I do finally fix it up, I *always* think I should have done it earlier. [11:58] mostly because it would have made everything between the realization and the cleanup easier. [11:59] Then I wonder: if you adjust to that and clean up earlier, what would be the signal that you've overshot? Or is there no such thing? [12:03] (I'm not entirely un-selfish in asking) [12:04] Sometimes cleanup is blocked on something else, and waiting means the cleanup is "delete big pile of stuff" rather than "spend two weeks fixing other stuff and then delete stuff". [12:05] My current situation in a nutshell. :) [12:05] But with a twist: I found a kind of circular dependency. [12:05] Which reminds me that I should keep dpm and Deryck updated. [12:06] jtv: hmm. [12:07] heya jtv, what's up? [12:07] Speak of the :) [12:07] jtv: perhaps decreased certainty about what to clean up? [12:07] dpm: I'm just dealing with some breakage during the Quantal opening. [12:07] jml: something to keep an eye out for next time. :) [12:08] dpm: no worries, we'll get it done. But I've gone off on a bit of a tangent cleaning things up that made it hard to fix these problems we've been having. And I found some things. [12:09] jtv: sometimes I get a certain circular mental motion / paralysis when I'm trying to clean things up when I really should just solve the damn problem. [12:09] * dpm worries that "things" are not "good things" [12:09] dpm: Well the bad things have already happened and now we can work on fixing them. Some deeply obscure PLPSQL code looks to me like this would happen: [12:10] jml: also a good thing to keep an eye out for then. I'll try to remember. [12:10] dpm: say you have two POFiles that share. [12:10] sorry, figuring this out myself now [12:10] And there's a record of your latest translation in one of them, but not in the other. [12:11] I think the tighter the loop, the less cost in overshooting either way [12:11] Probably. [12:11] dpm: now you enter a new translation, in either of them. [12:11] dpm: the obscure code is the code that keeps track of who's contributed to which POFiles. [12:12] And it says “oh good, I've just updated an existing contribution record (POFileTranslator is the actual table); that means I don't need to create a new one. I'm done.” [12:12] And so it never creates a similar record for that other POFile — even if that was the one you were translating in in the first plcae! [12:12] *place [12:12] dpm: sound familiar? [12:13] This is what users have been complaining about that we just couldn't figure out. === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugs: 3.47*10^2 [12:27] jtv, oh, so if I understand it correctly that's the bug we recently talked about? [12:27] dpm: I think it just might be. === Ursula is now known as Ursinha === matsubara-afk is now known as matsubara [12:59] anyone know what's up with Error: Couldn't find a distribution for 'pytz==2012c'. [12:59] ? [12:59] pulled source-deps, not there, reran buildout but can't find it [12:59] anyone know where I'm supposed to have gotten it from? [12:59] rick_h_: download-cache [12:59] bzr up it [12:59] hmm, did but said it was up to date [13:00] Tree is up to date at revision 465 of branch bzr+ssh://bazaar.launchpad.net/+branch/lp-source-dependencies [13:00] ? [13:01] 2012c is in there for 2.6 and 2.7 [13:01] ok, yea see it there, just buildout/make hating on me I guess. [13:01] ok, thanks for verifying it's where it should be [13:04] wgrant: doh, sorry was updating download-cache in ~/launchpad/ not realizing it wasn't symlinked into devel but was it's own copy [13:04] rick_h_: Hm, that's meant to be symlinked. [13:05] yea, that's what I thought. I know I did some hackery due to precise install fun so probably my fault [13:05] The default setup is that devel/download-cache is symlinked to ~/launchpad/lp-sourcedeps/download-cache, and all the other branches have theirs symlinked to devel [13:05] right [13:18] tabs :( [13:18] jml: Ew, where? [13:18] wgrant: soyuz/configure.zcml [13:19] Just the one. [13:19] Still, destroy. [13:21] wgrant: with enthusiasm [13:22] allenap, hi. You around? [13:22] ah, see the lunch afk message now. sorry, catch you later. [13:23] deryck: Hi. [13:23] deryck: I forgot to update my status. [13:32] adeuring, rick_h_ -- sorry, got busy chatting and missed it was standup time. [13:32] adeuring, rick_h_ -- be right there. === almaisan-away is now known as al-maisan [13:39] https://code.launchpad.net/~jml/launchpad/commercial-means-shut-up/+merge/104739 [13:39] patch to rename IArchive.commercial [13:44] deryck: https://code.launchpad.net/~rharding/launchpad/editstatus_timeout_874250/+merge/103912 [13:47]