[07:38:27] I have a change request for WIkipedia for Iphone and how it retrieve coordinates what is the process? [07:38:43] My eamil salgo60msn.com [14:47:21] mdholloway: for when you are back. I really like your commit message for the android emulator plugin https://gerrit.wikimedia.org/r/#/c/366484/ :] [14:47:32] context / references etc. that is great :] [14:50:02] hashar: o/ thanks! [14:50:31] mdholloway: I am building the plugin with your two patches and I am going to upload it to Jenkins + restart jenkins [14:51:30] sounds great [14:52:49] it seems like the bigger issue (maybe something to propose upstream) is that these kinds of command-line options should really be user-configurable rather than inferred from the build environment [14:53:48] ideally yes [14:54:08] your latest patch might fix a warning stating that the emulator cant use SMP on Qemu 1 [14:54:15] so maybe it will start using multiple CPU and that will speed it up [14:56:18] had to cancel the peridoc job [14:56:26] and running again on https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1761/console [14:56:45] >> emulator: WARNING: Classic qemu does not support SMP. The hw.cpu.ncore option from your config file is ignored. [14:56:50] that is the warning I was referring to [14:57:11] and there is: [14:57:13] >> WARNING: Force to use classic engine to support snapshot. [15:02:40] hmmmmmmm.... we're not using snapshots so i'm not so worried about that one, but from the warning above it looks like the emulator may be opting for the classic engine even without being forced [15:04:52] yeah [15:05:07] reading the plugin code and the emulator -help [15:05:18] the plugin pass -no-snapshot-save -no-snapshot-load [15:05:27] apparently the emulator can be passed just -no-snapshot [15:05:46] there is probaqbly a glitch in emulator where it forces the classic engine unless -no-snapshot is passed [15:07:41] hmm no :( [15:16:35] * mdholloway is in standup but keeping an eye on that chat here... [15:18:38] nothing fancy [15:18:56] the job runs apparently fine with your two patches and android-24 ( https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1761/console ) [15:22:59] AHH [15:23:09] maybe it is the AVD that has snapshot enabled [15:24:28] .android/avd/hudson_en-US_240_WVGA_android-24_x86.avd/config.ini [15:24:31] it has: snapshot.present=true [15:24:56] src/main/java/hudson/plugins/android_emulator/EmulatorConfig.java: setAvdConfigValue(homeDir, "snapshot.present", "true"); [15:25:52] interesting... [15:28:04] and the same setting is there for the android-25 avd [15:43:28] ahh [15:43:44] android create avd -f -a -s WVGA800 -n hudson_en-US_240_WVGA_android-24_x86 -t android-24 --abi x86 [15:43:53] where -a == --snapshot Place a snapshots file in the AVD, to enable persistence. [15:48:49] hashar: mind if i start a job with android-25 just to see what comes of it? [15:48:56] mdholloway: yeah please do [15:49:01] mdholloway: but I think I found the issue [15:49:18] see my last reply on https://gerrit.wikimedia.org/r/#/c/366484/1 [15:49:27] basically the plugin always does: [15:49:31] android create avd -snapshot [15:49:37] thus the AVD has snapshot.present=true [15:49:45] even when we do not tick the "use snapshots" box in the job [15:49:54] (well that is how I believe it works) [15:50:02] yeah, it looks like it does that for any sdk version where sdkSupportsSnapshots() == true [15:50:07] then when the emulator starts, it find out there is a snapshot and thus forces the classic engine [15:50:10] (anywhere sdk >= 9) [15:50:13] yeah [15:50:30] in that block code a bit above there is a similar condition but with shouldUseSnapshots() [15:50:41] so maybe we can add that shouldUseSnapshots() to the condition [15:50:57] and if the job does not want to use snapshot, hopefully the avd would not be created with snapshot support [15:51:44] (all of that is purely speculative :D ) [15:57:49] hello all [15:58:39] I noticed a weird behaviour of wikipedia app while using it on an android 7 device [15:59:54] The app rotates *180* degrees while *no* other app on the device exhibits this behaviour! [16:00:25] that's intentional [16:01:03] https://gerrit.wikimedia.org/r/#/c/209954/ [16:03:59] hashar: no luck with android-25 (as expected). i reverted the job to android-24 and plain x86 [16:07:00] I see. It doesn't seem to be working out well in all cases, especially in a the mentioned mobile device (moto g5 plus). [16:08:04] Sorry I misspoke. [16:08:26] kaartic: no, it's ok -- it is kind of unusual [16:08:40] mdholloway: :-( [16:09:04] is it causing trouble on the moto g5 plus? [16:09:10] (kaartic ^) [16:09:11] mdholloway: and for that mysterious boot failure, maybe we can pass the option -verbose to the emulator. That seems to spam bunch of useful stuff [16:09:40] mdholloway: I am off for dinner. Will come back later tonight. Maybe I can craft an experimental job, that will makes debugging easier. [16:10:18] hashar: that would be awesome. thanks again and have a good dinner! [16:13:45] mdholloway: no. maybe this picture conveys what I'm trying to say [16:13:47] https://phabricator.wikimedia.org/F8807295 [16:14:33] Note that the *on screen* buttons for home back are *not present* [16:16:05] kaartic: hmm, that's not good [16:22:13] That's because it allows the user to hide them in favour of the gestures that the touch "button" cum fingerprint sensor recognizes [16:23:17] I guess it's better avoid allowing 180 degree rotation atleast on *mobile devices* as they aren't of much use and could have a variety of similar weird behaviours [16:24:44] kaartic: created T171322 [16:24:44] T171322: Soft hardware keys not present in upside-down rotation (moto g5 plus) - https://phabricator.wikimedia.org/T171322 [16:26:20] ok! [16:27:20] kaartic: thanks for reporting! that's an interesting issue [16:29:39] you're welcome! [16:38:46] one more thing I noted recently when using the alpha version is that the app seems to requesting for storage permission when I go offline (of course as I haven't granted it). [16:39:18] I think that's a consequence of the implementation of the *offline compilation* feature. [16:39:25] kaartic: exactly [16:40:26] It's a nice feature, indeed. but I was wondering if there would be a possibility to turn-off/disable the feature ? [16:41:07] kaartic: you're welcome to decline the permission. [16:43:14] we may implement an additional step where we show a dialog that explains the permission before we request it. [16:43:31] this is all experimental / prototype code so far. [16:45:26] That's true. At least currently, declining the permission has a displeasing consequence. The app shows a pretty big warning message when I go offline stating that it needs storage permission to browse offline. [16:47:05] I just wanted if there was / would be a possibility to hide that message altogether as I find it disturbing. [17:02:52] Related bug: https://phabricator.wikimedia.org/T171327 [17:54:23] o/ o/ reets, is this the latest android mock for the footer? https://phabricator.wikimedia.org/T143400 [17:54:39] reets: mhurd says design on ios wants the wikipedia logo to the side, for example [18:29:17] hey niedzielski: soz didn't see this msg but I commented on the PR and updated the mock to left-align [18:29:40] yayyyy! [18:29:42] thanks reets_afk !! [18:29:51] nw [18:30:51] oh niedzielski: just s/w Nirzar and Caroline and can we actually make the logo on Light mode be colored #54595D (as it currently is now on m.web)? [18:31:22] and recolor the same SVG asset to #FFF when in Dark mode [18:37:59] reets: i only have png assets for these. if you can give me them to me as svgs, i canrecolor them happily [18:38:17] reets: do you happen to have icons cut for the menu footer menu? If you don't, I will keep the edit history, talk page, and open in browser as links on the bottom. [18:52:36] niedzielski: i've uploaded the wordmark svg at [18:54:18] niedzielski: not sure what you mean by menu footer menu though? We are keeping the edit history, talk page and open in browser as links for now. [18:55:15] reets: thanks! i don't seem to have permission to access though [18:55:36] reets: ah, ok links sounds good [18:58:36] niedsielski: hmm there should be a download link [18:59:01] reets: mhurd is going to share a screenshot showing the footer menu items. these are in the page library now so i wasn't sure if you wanted to use those or if i should keep the links [18:59:07] niedzielski: try downloading the svg from the link added to the description in https://phabricator.wikimedia.org/T143400 [18:59:33] reets: link works now. thanks! [19:02:18] niedzieldski: IIRC iOS footer menu items are not the same as Android and the style of presentation of end sections on articles is quite different... but i can take a look if you'd like to share a screenshot [19:07:16] reets: (from mhurd) https://usercontent.irccloud-cdn.com/file/p9FewKzP/Screen%20Shot%202017-07-21%20at%2012.05.47%20PM.png [19:07:28] reets: the guys under "about this article" [19:07:42] reets: i can either move the links up in there or keep them at the bottom under read more [19:07:48] niedzielski: yes I figured that's what you meant. [19:08:08] https://usercontent.irccloud-cdn.com/file/gw3cCp8c/Screen%20Shot%202017-07-21%20at%2012.05.39%20PM.png [19:08:48] reets: or i can hide the menu altogether for now [19:09:08] niedzielski: Let's leave them where they are for now [19:09:20] reets: okey dokey, thanks so much rita! [19:10:20] since the links in Android all redirect out of the app to browser whereas the iOS ones navigate to in-app sections [19:11:39] no worries niedzielski! Peacing out now - enjoy the weekend! [19:12:22] ๐Ÿ‘๐Ÿ‘๐Ÿ‘reets [19:30:15] dbrant: are we agreed we'll need a db table to store compilation info? should i write up a ticket for it? [19:31:56] hasharDinner: i just kicked off a job with the old config since i'd apparently not changed it back earlier, but feel free to stop it for more testing [19:45:47] mdholloway: sorry, was in a meeting. do you want to batcave for a couple minutes? [19:45:58] dbrant: sure, omw [19:47:14] dbrant: oops, looks like batcave's occupied [19:56:40] mdholloway: back [19:57:55] mdholloway: I am upgrading the plugin again. This time to stop passing -snapshot to "avd create" [19:59:59] would be nicer to setup a dedicated Jenkins to play with that but I am being lazy :( [20:05:24] AHH the warning about classic engine is gone [20:09:43] qemu-system-i386: -audio: invalid option [20:09:44] :( [20:12:32] hashar: that's odd. but good news about the classic engine warning! [20:12:46] now trying without -no-audio [20:13:10] https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1770/console [20:13:15] and it says the emulator is out of date :( [20:14:59] ahhhh [20:18:55] 00:05:12.879 Starting 116 tests on hudson_en-US_240_WVGA_android-24_x86(AVD) - 7.0 [20:19:01] stuff happens somehow [20:19:31] the crazy thing is that niedzielski and I looked into that a year or so ago [20:19:43] but we were both hitting a wall of brick :( [20:19:46] (well I was for sure) [20:20:08] i remember that! [20:20:25] hashar: i want to say i used to have a comment in the JJB file that -no-audio was found to be necessary [20:20:44] niedzielski: yes I clearly remember that [20:21:14] then the job seems to now pass the hardware property: hw.audioInput: False [20:21:24] which might have the same effect? or not I dont know [20:23:39] hashar: a little info when running emulator -help-all [20:23:41] https://phabricator.wikimedia.org/P5783 [20:24:09] but i don't think we need audio at all. it just needs to stay off [20:24:49] wow [20:24:52] note the bit about passing these options as environment variables too [20:25:02] job finished already (downloading screenshots and diffing them and everything) [20:25:05] that is so much faster [20:25:19] 12 mins start to finish [20:25:26] QEMU 2 FTW? [20:25:40] yeah well [20:25:48] ah yes it is actually faster!!! [20:25:54] but then it has a shit ton of failures :( [20:26:55] I guess due to the audio thing [20:27:18] use '-audio none' to disable audio completely. [20:27:28] the failures are just for the screenshot diffs, though [20:27:45] but they passed just fine a few hours ago [20:28:03] yeah... [20:30:11] niedzielski: thx. Though passing "-audio none" causes:: qemu-system-i386: -audio: invalid option [20:36:13] hashar: it appears to accept the parameter locally on my system: `LD_LIBRARY_PATH=/home/stephen/opt/android/sdk/emulator/lib64:$LD_LIBRARY_PATH ~/opt/android/sdk/emulator/qemu/linux-x86_64/qemu-system-x86_64 -avd 24-nexus-s -audio none` [20:37:39] :( [20:37:56] hashar: i'm not sure if this is still the case but some options must appear after `-qemu` to specify that they go to QEMU, not the emulator wrapper (i think). however, this does not appear to be the case for `-audio` [20:38:32] https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1771/console [20:38:35] tried to pass "-audio none" [20:38:42] and fails with qemu-system-i386: -audio: invalid option [20:44:52] ah https://stackoverflow.com/questions/40272884/running-android-emulator-with-noaudio-option-returns-qemu-system-i386-exe-au [20:46:07] hashar: nice find [20:53:49] so the status is that the Jenkins plugin no more use snapshots [20:54:00] and manage to use QEMU2 instead of -engine classic/QEMU [20:54:25] the build is 3 or 4 times faster, apparently without snapshot multiple CPU can be used [20:54:36] and there are four CPU. Hence the build goes from 45 minutes to 11 minutes [20:54:56] but -no-audio is no more supported in QEMU2 [20:55:19] running the job fails due toa bunch of screenshot diffs that are faulty (maybe that is related to audio, maybe to qemu2) [20:55:20] https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1770/console [20:55:48] QEMU_AUDIO_DRV=none would disable the audio driver in QEMU2. That is running on https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1774/console [20:58:15] and that one pass [20:58:21] well the build is successfull [20:58:52] but the diff fails :( [21:02:11] mdholloway|mtg: niedzielski: shouldn't the screenshot diff be captured and attached to the build ? :] [21:03:10] mdholloway|mtg hashar: the format isn't as nice as it could be. https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1774/artifact/app/screenshots-diff/ [21:03:42] ahhh [21:03:56] oh geez i broke this first one with my dark mode changes [21:04:20] T170149? [21:04:21] T170149: Test screenshots render differently per platform - https://phabricator.wikimedia.org/T170149 [21:04:39] ah ok stephen [21:05:13] mdholloway|mtg: i think this is the divider color change i pushed earlier [21:05:13] er yesterday [21:05:13] i'll push a patch to update the screenshots shortly [21:05:29] and potentially we can run with audio. That seems to still pass just fine [21:05:39] the jenkins job is still on android-24 [21:06:30] mdholloway|mtg: do you want the shots on 24, 25, or 26? [21:09:08] and i think the speed up is that qemu2 allow multiple cpu so the screenshots might be retrieved in parallel [21:09:23] there was a task about adding some GPU hardware or that job being super long and slow [21:09:39] I could not find it, but the plugin patch address that! [21:10:01] ๐Ÿ‘ [21:16:57] niedzielski: since the job seem to pass with audio, I am tempted to just drop -no-audio (or for QEMU2 to not pass QEMU_AUDIO_DRV=none ) [21:17:01] that makes the job config simpler [21:17:17] but I am assuming the diff issue is related to some patch in the app / screenshots need to be updated [21:18:10] hashar: the diffs i looked at were due to my mistake and not platform specific [21:19:55] hashar: -no-audio can be addressed as needed later in my opinion [21:26:31] trying with android-25 and google_apis/x86 [21:50:45] niedzielski: mdholloway|mtg: and the "speed up tests plz" task was https://phabricator.wikimedia.org/T158014 [21:50:54] I have left a message there mentionning the job is 4 times faster [21:51:51] it is almost midnight [21:51:54] hashar: ๐Ÿ•ถthat's pretty cool [21:52:07] yeah it is definitely nice [21:52:10] hashar: thank you for putting in so much work with michael [21:52:31] I clearly remember how I was pissed off when investigating the slowdown back in febuary ( https://phabricator.wikimedia.org/T158014 ) [21:52:45] hashar: we should just go ahead and double the cores of the machine too...! :] [21:52:45] and mdholloway|mtg patch to enable qemu2 did all the magic :] [21:52:58] yeah maybe we can go with 6 cpu instead of 4 [21:53:13] I am not sure whether we can easily change the flavor of an instance without having to rebuild it [21:53:20] but you can ask #wikimedia-cloud about it [21:53:39] thanks hashar! [21:54:15] \o/ \o/ [21:59:48] hashar: niedzielski: yes, thank you, hashar! niedzielski, so the reference screenshots just need updating again? [22:00:01] mdholloway: yes [22:00:08] mdholloway: i wasn't sure what api i should target [22:00:23] niedzielski: let's go up to 25 [22:00:51] mdholloway: okey dokey [22:01:24] hashar: niedzielski: as for instance resizing, last i heard from andrew b. is that that almost never works :[ [22:01:31] mdholloway: it shouldn't matter but you're using the google apis variety? [22:01:37] niedzielski: yep [22:01:58] niedzielski: actually as far as i can tell, only google apis flavored-emulators are available starting with api 25 [22:02:03] then we would have to create a new one :]