[14:30:23] mdholloway: good morning; I think I will merge the android plugin patches you made in gerrit as well as the couple CI config change [14:30:43] I have sent your patches to upstream, and I guess when they release a new version I will sort out the repo in Gerrit :} [14:30:44] hashar: ok! [14:31:04] I am gonna create a wmf branch in the Gerrit repo and move the change to that [14:31:05] so that master reflects the upstream one [14:31:07] or something like that [14:31:20] (or just create an upstream branch) [14:31:25] yes, thanks for pushing those, i have been meaning to, but preoccupied with other things... [14:31:55] I think the reason the screenshot tests went from 45 to 11 is that your patches allow to use QEMU2 and thus take advantage of multiple CPU [14:31:59] and there are four of them [14:32:25] specially the retrieval of screenshots was the longest time ( ~30 minutes) which now happens 4 x time faster [14:32:39] yes, makes sense. [14:33:19] I have no idea why retrieving files from the emulator is so slow though [14:35:33] done [14:35:44] at least for the android patches [14:36:50] i hope they're open to both changes upstream [14:37:58] i'd like to take the time to sit down and figure out a broader upstream patch to reduce the amount of options enforced based on the build env and make configuration from the web interface simpler. but, too many projects, too little time... [14:43:09] yeah there is a limit to what we can upstream :( [14:43:49] at least the screenshot are faster, and maybe we can add them to the test: job that acts everytime a patch is sent in Gerrit [14:49:17] hashar: they're fast enough now that it's within the realm of possibility! [14:52:30] * dbrant twitches a bit [14:56:30] ;) [15:32:01] I refreshed the periodic jenkins job and running it again https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1789/console [15:32:11] with android-25 google/apis-x86 :D [15:41:56] mdholloway: I have marked the task as fixed :-} [15:42:12] mdholloway: congratulations really, specially the java parts which is way over my grade [15:43:21] hashar: \o/ sweet! thanks! [15:49:53] pfff [15:50:13] seriously how come someone that barely know anything about dev and lack 5+ years of experience can even start to even gasp our daily work [15:50:24] the android app use a gradle plugin from facebook [15:50:34] which define bunch of task as a Groovy script [15:50:40] which apparently shell out to a python script [15:50:47] that is already E_TOO_MANY_LANGUAGES [15:50:56] plugin/src/main/groovy/com/facebook/testing/screenshot/build/ScreenshotsPlugin.groovy: project.task('pullScreenshots') { [15:50:56] plugin/src/main/groovy/com/facebook/testing/screenshot/build/ScreenshotsPlugin.groovy: project.task('pullScreenshotsFromDirectory') { [15:51:07] the last one sounds promising, might be faster than retrieving them one by one [15:51:09] will fil a task [16:07:04] https://phabricator.wikimedia.org/T171754 [16:07:09] off for meeting [16:52:10] jdlrobson: are you using the current MCS references endpoint in anywhere? I assume those would be only from prototypes since this endpoint is not exposed through RB. I'm thinking of repurposing the name for the new endpoint I'm working on. It would provide a JSON structure for the reference lists. (https://phabricator.wikimedia.org/T170690) [18:16:56] dbrant: lol: https://stackoverflow.com/questions/43228017/4-1-android-emulator-not-detecting-sd-card [18:51:19] genymotion emulator OOMs trying to open a 20mb zim even after beefing up the RAM in the options [18:51:21] sigh [18:59:59] mdholloway: the app OOMs, or the emulator itself? [19:00:21] dbrant: actually the app, not the emulator [19:01:09] o_o interesting, i'll try to reproduce. It shouldn't be reading the whole file into memory. [19:02:01] https://www.irccloud.com/pastebin/TVd8G0hV/ [19:03:23] what API level is it? [19:04:01] dbrant: 16 [19:09:36] mdholloway: reproduced; will work on a fix at the library level. [21:39:25] mdholloway: the memory issue is in the LZMA library that the ZIM library is using internally. I'll need to make some optimizations there. The library is using a 64MB dictionary by default (!) [21:39:31] Good thing you caught it! [22:02:49] Volker_E: around?