[09:15:15] anyone awake at this hour? [09:17:49] jdlrobson: o/ welcome back! [09:18:10] hey codezee :) [09:18:20] i'm having issues with my internet right now, do you have skype by any chance? [09:19:06] I do, but I've not configured it, do you mean it for tonight's meeting, in which case I can get it up [09:21:13] codezee: also if we can do tonights meeting a bit earlier that would also be great - i didnt realise but it's 1am my time :) [09:21:32] jdlrobson: :D sure, when? [09:22:01] codezee: ummm lemme check [09:22:17] a lot of discussions on deployemnt took place at https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Consensus_for_deploying_the_new_banners_extension [09:23:00] one or two issues might still need to be resolved before going for review [09:25:36] codezee: would 2 hours time work? [09:25:49] codezee: yup you are one of my top priorities today :) [09:26:14] jdlrobson: 2 hours meaning? 2 hours earlier? [09:26:30] codezee: 2 hours from now? [09:26:38] 7.26pm UTC+8 [09:26:47] yes, sure [09:26:54] codezee: awesome [09:27:00] did you see my comment on your patchset about the blurry banners? [09:28:17] saw just now, will reply in a moment [11:23:56] jdlrobson: I'm on skype but I do not know your username [11:24:29] codezee: hey there! i'll message [11:29:29] codezee: sure [11:29:56] codezee: i'm trying the hangout as well [11:34:22] codezee: hey sorry about that [11:34:41] jdlrobson: its ok :) [11:34:57] codezee: so what were you saying about the monobook skin? [11:35:40] jdlrobson: I said that I'll test it after https://phabricator.wikimedia.org/T97839 is resolved because that one is already making structural changes [11:36:10] codezee: okay makes sense. I'll add a dependency to remind me :) [11:36:27] codezee: i made a comment on https://phabricator.wikimedia.org/T105127 did you see? [11:36:47] it occured to me earlier that we might not need any bot to transfer pages to use our extension, see my comment at https://phabricator.wikimedia.org/T102537 [11:37:46] jdlrobson: yes, so I guess closing https://phabricator.wikimedia.org/T105127 would be the best option here as you said [11:37:59] codezee: i saw! yeh that makes total sense. [11:38:33] jdlrobson: therefore when it is decided that extension is good to go, all thats needed is change the template code, which makes our work a lot easier! [14:01:15] coreyfloyd: just seeing message. for apps we do not have explicit session time, but recently 4 week rolling window data for session length, pageviews per session, and number of sessions became available from extrapolation via an oozie scheduled scala job. the resultsets are exposed via two tables in the wmf namespace in hadoop. [15:33:04] niedzielski: hey! got 2 sec. for batcave? [15:33:20] dbrant: sure thing! [16:15:04] dbrant|brb: hi from mexico city! have a few minutes to hop in the batcave and talk about the lite app? [16:15:50] Deskana|Away: Dan! Mexico! [16:29:59] are any mobile folk at the hackathon? [16:30:06] viviana here would like to talk to some mobile people [16:38:14] cscott: yes, there is me an joakino [16:38:29] bmansurov: do you have a table in don diego [16:38:37] viviana is interested in writing apps for mobile os [16:38:41] thought i'd introduce her to you [16:38:48] cscott: no, but there are some empty tables in here [16:39:00] cscott: sure, were can we meet? [16:39:31] hm, she wandered off, she was over with the wikidata people a second ago [16:39:44] i'll send an introduction email and maybe she'll find you [16:39:49] cscott: ok, cool [16:39:51] thanks [16:46:15] cscott: there's also mhurd here who does iOS, that may be more what she's looking for. there was some android folk too, not sure who [16:47:06] joakino: mdholloway i think [16:48:10] she's interested in firefox os mostly, i think. [16:48:21] bmansurov: yep, just me from the android team. i'm at a table with Deskana and Rashiq who works on the Wikia app [17:01:31] jdlrobson: rmoen are we standing...or not? [17:04:43] I'm gonna make a call: no :-) [17:05:04] * kristenlans got too lonely in the hangot [17:20:39] coreyfloyd: are you coming to standup? [17:27:26] gwicke: do you guys reject patches submitted via gerrit and force people to use github? [17:28:11] dr0ptp4kt: that sounds worse than it is ;) [17:28:35] so far we only had that happen once, and we explained that we are working on github [17:28:45] it wasn't an issue really [17:29:17] we also had the reverse happen, with patches being submitted to a github mirror of a gerrit repo [17:29:24] gwicke: okay. yeah, i know most people are fine with it. i just wanted to know what sop would be if mirroring the approach [17:30:04] you can always pull & push such patches manually [17:31:26] are you still thinking about where to work primarily? [17:32:35] mbinder: bgerstle whoops. Sorry went to workout late and totally spaced on standup. Will send a n update via email [17:33:06] gwicke: yeah. the basic question is whether gerrit based submissions would expressly not be supported. [17:34:51] dr0ptp4kt: it's two commands and one click to transplant a gerrit patch to a github PR (git review -d, git push and hitting the 'open PR' link), so it's not too hard to still accept those [17:35:39] gwicke: yeah, i know :) i realize this is talking hypotheticals more than reality [17:35:40] we are generally avoiding to have review happen in two places [17:36:37] gwicke: so in summary: you occasionally push GH master to gerrit master, and move patches in to GH PR's [17:36:55] yeah [17:36:56] gwicke: this is basically what we're doing now for GH on iOS [17:37:24] with the exception that we actually will review GH PR's, and after getting +1's _on github_ will create a gerrit patch to merge it [17:38:22] but you're actually moving people to GH in advance, thinking that they would continue working on GH? [17:38:22] interesting.. so you create a gerrit patch (with collapsed history?) *after* finishing the review on github? [17:38:43] gwicke: yeah, just because there's no way i'm going to say "you have to change this, but do it as an amendment in gerrit" [17:38:51] because then we've probably lost their interest [17:39:11] gwicke: dr0ptp4kt basically it's up to the contributor [17:39:15] we generally work on github, so do all the tweaking and merging there [17:39:45] if they initially submit on gerrit, we'll say "we mainly work on GH, would you mind moving to a PR or would you rather continue here?" [17:39:46] in the rare case where somebody creates a gerrit PR (once so far), we move it to github and follow up there [17:40:11] gwicke: that's the ideal switchover [17:40:19] because then we'll be able to leverage feedback from travis [17:40:45] yeah, travis was why we started with github in the first place [17:40:58] sounds familiar ;-) [17:41:12] gwicke: and you've never had an instance of someone saying "no i only work in gerrit"? [17:41:29] no, not yet [17:41:38] but, sample size of one patch ;) [17:42:09] true, but still representative of the overall demand for gerrit contributions to your repo [17:42:09] I think things would be slightly differently if we were working on parts of mw core [17:42:44] sure, if you were working w/ people who might prefer gerrit [17:42:55] *nod* [17:42:56] but anyway, bike-shedding aside [17:43:15] overall I think things have gotten less dogmatic over time [17:43:36] it seems the precedent is: manual pushes to maintain sync between releases (or every week)? [17:43:48] w/o separate emails to announce the changes [17:43:59] we push to gerrit for each deploy [17:44:11] but it's just open push, without extra review [17:44:15] not the same as every merge to master? [17:44:23] gwicke: right, that's what i figured [17:44:34] i already enabled push access to our gerrit repo for iOS repo owners [17:44:37] we haven't bothered to set up auto-push hooks [17:44:42] right [17:44:57] gwicke: and you deploy, how often roughly? [17:45:23] when things are moving along normally, about twice a week [17:46:06] I have a gerrit remote, so all I do is 'git push gerrit' when I'm about to deploy [17:46:23] gwicke: yep [17:46:32] gwicke: i already have remotes setup for gerrit, gh, and my gh fork [17:46:40] so that's easy to do manually on a biweekly basis [17:46:48] we'd probably do less often since we release less often [17:47:39] curious what oojs does to maintain their mirror, but i'm fine w/ manually pushing [17:47:40] it would also be easy to automate, only minor issue is setting up an extra key / user for that [17:47:48] yeah, not our problem ;-) [17:47:57] bgerstle: ? [17:48:05] cost of figuring that out is not worth it to me [17:48:11] would rather push manually [17:48:23] of _me_ figuring that out [17:48:24] James_F has a watch on 'oojs' ;) [17:48:28] oh lol [17:48:29] Yup. :-) [17:48:46] James_F: i only mentioned that i was mildly curious how oojs maintains gerrit-github sync [17:49:00] but not important [17:49:04] didn't intend to summon you [17:49:08] bgerstle: It's just the normal gerrit -> github slave script that RelEng runs. [17:49:17] uh huh, interesting [17:49:17] bgerstle: There's no github -> gerrit functionality. [17:49:27] right [17:49:38] not a big problem [17:49:44] "git push" is sufficient [17:49:46] Except for the static release tarballs of OOjs which I manually put in GitHub. [17:49:52] ah, interesting [17:50:07] i guess they're expected to be there for npm? [17:50:07] But we only do an OOjs release once every 3–4 months, so… [17:50:10] dbrant: Do you have time for a quick hangout? Trying to debug a problem. [17:50:12] right [17:50:18] ok [17:50:29] Deskana: i was just about to ask you! [17:51:14] No, npm manages to pull from the repo's tag; this is for … actually, I don't know why we're doing it. [17:51:30] I'm doing it because the release instructions in the README tell me so to do. :-) [17:51:44] dbrant: I'll call you in a sec. [17:52:14] James_F: right, npm rebuilds the package? that's interesting... anyway. thanks for chiming in! [17:52:21] No worries. :-) [17:52:21] gwicke: and thanks for answering our questions [17:53:17] bgerstle: yw! [17:55:23] gwicke: sorry, one quick clarification [17:55:30] when you push to gerrit, do you send an email announcing the change? [17:55:43] or, announcing that sync was performed? [17:56:11] no, we treat the gerrit repo more like an internal backup [17:56:22] gotchya, many thanks! [17:56:23] we don't even send out mails for the deploy [17:56:43] only record it in https://wikitech.wikimedia.org/wiki/Server_Admin_Log [17:57:11] (unless it's a big change, in which case we might write an announcement) [17:57:20] ah interesting [18:16:24] bgerstle: ok! ready for questions [18:18:10] dbrant: so, when you get the response from pageimages, how do you filter out things like the Wikipedia logo? [18:18:14] and various other icons on the page [18:19:26] bgerstle: all we do is: if it's not a .jpg file, then don't show it. (e.g. svg, png) [18:19:46] bgerstle: that's proved pretty effective so far [18:20:11] bgerstle: (unless the user explicitly clicked on a .svg file in the article, then we show it along with the other content in the gallery) [18:25:07] dbrant: interesting.. so if you click on a specific image, you insert that into the "normal" gallery items? [18:25:25] bgerstle: that's right [18:25:46] hm, seems a bit strange, tbh [18:26:05] only showing items in the gallery if someone clicks on it [18:26:15] but i guess you have to choosen between lesser evils at this point [18:26:30] bgerstle: i don't disagree [18:27:01] dbrant: how tactful ;-) [18:27:20] bgerstle: but really, it's the pageimages api that should be improved to include only the actual images in the page (and filter out the icons and logos) [18:27:33] dbrant: don't think i haven't thought about that already ;-) [18:27:51] dbrant: what i'm wondering at this point is, if that's a tree worth barking up, or if i should just wait until our great cloud service in the sky can do it [18:27:57] content service* [18:28:02] based on parsoid or something [18:28:51] bgerstle: yeah, i would definitely welcome that [18:29:05] might as well ask... bd808, how hard would it be to make a patch to pageimages so that it only returns images related to a page's content, ideally in the order they appear? [18:29:59] how does pageimages even work?.. [18:30:00] bgerstle: MaxSem would be a better person to ask. He wrote that [18:30:04] ah [18:30:14] it hooks the parser and looks for stuff [18:30:18] i see [18:30:35] i guess joakino et. al too [18:30:38] joakino: you there? [18:31:25] or sorry i misspoke [18:31:29] bd808: not pageimages, "images" [18:32:27] e.g. https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=images&format=json&imlimit=500&titles=Albert%20Einstein [18:32:47] includes things that aren't really relevant, like the Wiktionary logo, Wikiversity logo, etc. [18:34:29] bd808: any idea who maintains that? [18:34:49] "everybody" or "nobody" [18:34:56] those images are in the page [18:35:12] sister project template [18:36:30] bd808: sure, i don't know what the original intent of the "images" module was, but at least for our purposes, we don't want to know about things that aren't related to the page's content [18:36:40] or maybe "directly embedded in the page's content" [18:37:00] so nothing that comes from template expansion? [18:37:26] Defining "related to the page content" sounds like a hard AI problem [18:37:31] bd808: that might be the implementation detail that solves it [18:37:59] bd808: i played a bit w/ parsoid and filtering img tags the selectors for Image/Thumbnail and Image/Frameless yielded some promising results [18:38:03] does that tell you anything? [18:38:27] filtering img tags to select the classes* [18:38:28] dbrant: So should I add extra code to getAppError to handle editing-related errors? [18:39:43] bd808: specifically "figure, [typeof~='mw:Image/Thumbnail'], [typeof~='mw:Image/Frameless']" [18:40:43] Deskana: yes, that's probably best. [18:40:55] bd808: i would assume MW has access to some of the information that parsoid uses to annotate images w/ those selectors [18:41:29] bd808: or if parsoid simply doesn't support template expansion/transclusion/whatever, and would run into the same issues as MW [18:42:45] bgerstle: it is probably possible. I'm not the guy to write the patches :) [18:42:45] api.php doesn't know anything about parsoid so that's not going to help [18:43:07] not about parsoid specifically, but whatever data parsoid is using from the article content to derive those tags [18:43:31] bd808: ok, didn't think you would, but who might i talk to if I were interested in such a thing being done? [18:46:32] bgerstle: nobody "owns" that really. It would be a feature request for core and then we'd need to find someone with time, inclination and expertise to work on it [18:46:48] ok [18:46:54] which is going to be the case with every api action you want to change [18:46:56] bd808: who would be good to consult? [18:47:34] bd808: if, for example, i wanted to pitch "reliable, user-friendly image gallerys on all platforms" as something we should do [18:47:41] and wanted to incorporate that functionality in MW API [18:48:09] bgerstle: JK? Toby? [18:48:31] bd808: i meant who would you ask to serve as the "MW API consult" to inform what is/isn't feasible to accomplish this [18:49:10] thinking we'd have one guy familiar w/ MW and one guy familiar w/ parsoid (and ideally restbase) [18:49:51] dbrant: I presume the Lite app was loading things last time you took a look at it. Any idea why it wouldn't be now, or should I just start debugging away? [18:49:56] bd808: actually... who owns mediaviewer? [18:50:20] because interestingly enough, they suffer the same problem [18:50:47] https://en.wikipedia.org/wiki/Albert_Einstein#/media/File:Speaker_Icon.svg [18:50:52] oh hai speaker icon [18:51:19] bgerstle: the multimedia group in editing, marktraceur [18:51:25] ok cool [18:51:33] i'll ask them if this is something on their radar [18:51:40] marktraceur: hi! [18:51:47] Uh oh. [18:51:53] Wait wait [18:51:57] I don't own MMV anymore [18:52:01] Just ask James_F [18:52:05] ha [18:52:07] ah [18:52:10] James_F: we meet again... [18:52:17] mdholloway: well, as the code is right now, it's configured to fetch content from localhost. So you'll need to update it to point to beta labs. [18:52:17] so more abandonware on the wikis? [18:52:26] But also, what do you need answered? [18:52:43] marktraceur: how mediaviewer is implemented, specifically where it gets the list of images from [18:52:46] mdholloway: (or launch the service locally) [18:52:58] i'm also curious how they do low-to-high-res fallbacks [18:52:59] dbrant: ah, i see. i haven't even looked at the code yet, just built it at the airport yesterday while waiting to board and wasn't getting anywhere. [18:53:00] bgerstle: Locally via the DOM, then fetches imageinfo from the API IIRC [18:53:07] marktraceur: VERY interesting [18:53:11] we do the same exact thing in iOS [18:53:22] marktraceur: "via the DOM" how exactly? [18:53:39] we use some XPath wizardry [18:53:52] bgerstle: Something like $( 'a.thumb' ) then there's some magical URL parsing that happens [18:54:01] See e.g. mw.Title.newFromImg [18:54:02] marktraceur: sounds alllll too familiar [18:55:03] marktraceur: https://github.com/wikimedia/apps-ios-wikipedia/blob/81b3e560ab56ad06cbc0e00414dbe618bcc4b622/Wikipedia/mw-utils/WMFImageURLParsing.m#L3 [18:55:12] it's deja vu.. [18:55:24] IIRC the parsoid folks were debating to add the original image dimensions as well [18:55:40] generally their spec is at https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images [18:56:07] dbrant: Handling error codes in a central place for both editing and login is either going to make things significantly more complex, or significantly simpler. I'm unsure which right now! [18:56:11] gwicke: yeah, i mentioned earlier that i got promising results from using an XPath that selected for "figure" & typeof~=mw:Image/{Thumbnail|Frameless} [18:56:20] https://phabricator.wikimedia.org/T64881 [18:56:45] it sounds like that's actually already live [18:57:03] data-file-width/data-file-height [18:58:04] yeah [18:58:09] i just noticed it was resolved [18:58:23] Deskana: looking at it a bit more, we can probably keep the current Editing error logic within the editing fragment (just update it to make it work with the updated mwapi library)... [18:59:00] I'll stash what I've got for now, and work on that. [18:59:39] bgerstle, I think for improving on icons we'd need some way to classify images as should-not-show-in-gallery [19:00:08] at some point we were discussing using categories on the image page for that, but afaik it hasn't come to anything [19:00:20] gwicke: i'm not sure whether it's that, explicitly INcluding gallery images, or both [19:00:29] gwicke: I tried to use the specs there for sticking data into the DOM but got shouted down I think [19:01:20] gwicke: marktraceur: i'm wondering if 3 is the magic number of redundant implementations that it takes to finally galvanize us into solving this problem [19:01:36] hehe [19:01:39] Take 5, they're small [19:02:17] marktraceur: at least let us reuse the same JS for parsing images out of the DOM.. [19:02:22] now that the PHP parser and Parsoid is owned by the same group I have high hopes that we'll see progress [19:02:29] there is https://gerrit.wikimedia.org/r/#/c/196532/ already [19:02:51] interesting [19:04:00] also, it seems like mobile-web doens't have a gallery yet either [19:04:07] they just blow up the image you clicked on [19:04:11] ohhhhh kaity! [19:04:17] how's mexico? :-) [19:04:25] bgerstle: its great! [19:05:00] urrently working out on the hotel roof [19:05:03] https://plus.google.com/u/0/photos/albums/pdocoms8ovvpl7uu5eucq7lr89o20pkmv?pid=6171806385776931762&oid=117759633392604919279 [19:05:06] what do you think of fixing image gallery across platforms (including mobile web?) [19:05:15] kaity: can't view :-( [19:05:33] kaity: isn't there an effort to add gallery to mobileweb? [19:06:08] bgerstle: that sounds good, yes there is an image gallery in alpha [19:06:13] ah [19:06:20] kaity: do you know who's been working on it? [19:07:18] bgerstle: checking with bmansurov now [19:07:41] https://www.dropbox.com/s/9pwlrel508p699z/2015-07-15.jpg?dl=0 [19:07:56] ^ the roof in mexico city venue [19:10:09] awesome [19:10:19] bgerstle: bmansurov yes the image gallery is currently in beta but needs backend work before it can be pushed to stable [19:10:47] bgerstle: did you have something else in mind about fixing across platforms? [19:10:51] bmansurov: what back-end work specifically? [19:11:21] kaity: currently there's no standard way to get images that "should be shown in a gallery" [19:11:41] i.e. excluding things like Wiki* logos, icons, misc. images in expanded templates [19:11:58] some platforms do interesting things to get around this [19:12:29] iOS (and desktop) parse the HTML to get "img" tags that fit a certain description, then mark a separate network request for each to get the higher-resolution image & other metadata (caption, license, uploader, etc.) [19:13:01] android uses another MW API that returns _all_ files for a page, but only shows JPEG images in the gallery, unless the user originally clicked on a non-JPEG image, which is manually inserted into the other "JPEG" gallery items [19:13:10] bgerstle: hey, i'm not exactly sure, but if I'm not mistaken one of the reasons the feature was developed in beta was that the we couldn't afford making an ajax request on every page load to get the banner image. [19:13:29] bmansurov: are you talking about lead image or image _gallery_? [19:13:36] bgerstle: let me check the code, maybe we're just getting the image from the page, in which case there is no backend poblem [19:13:51] bgerstle: ohh, i'm talking about lead image [19:14:05] bmansurov: are you working on the gallery too? [19:14:56] bgerstle: no, i don't think there is any more work left [19:15:08] bmansurov: how are you getting images for the gallery? [19:15:21] bgerstle: i think looping through the images on the page [19:15:35] doing some selector query on elements in the page? [19:15:44] bgerstle: yes, let me double check [19:16:03] sounds familiar.. marktraceur ☝️ [19:16:20] that makes 4 ;-) (unless they're reusing code from MMV) [19:19:21] bgerstle: yes, the list of images are the result of $('a.image, a.thumbimage') [19:19:26] is [19:19:29] fantastic [19:19:52] bmansurov: cool, thanks for looking ito it [19:19:53] into* [19:19:59] np [19:21:28] i guess web is a long way from having to solve the problem of showing the gallery w/o access to the entire DOM [19:22:01] even still, you guys probably have the same problems as us (showing seemingly random images in the gallery like logos & speaker icons) [19:22:11] MMV has that problem [19:25:39] dbrant: Alright, finally I think I've got the error handling migrated over to the new way it's done. [19:27:38] Deskana: excellent [19:28:50] Deskana: did you move tables? [19:29:15] mdholloway: I'm sat at the window by the lunch hall. I needed a change of environment. Feel free to join me! [19:29:45] mdholloway: There are plugs here if you need power. [19:30:29] Deskana: Thanks, that will probably be useful shortly. Probably shouldn't take off just now since Rashiq just showed up, but I'll probably be by a bit later [19:30:38] mdholloway: Great! [19:39:14] dbrant: Not the most satisfying solution because it breaks error handling logic into two separate classes, but it does work and it's a small change: https://gerrit.wikimedia.org/r/#/c/224874/ [19:40:17] hey -- does anyone have info on Apple's Siri integration. It looks like they have some cached info and we'd like to clarify [20:19:26] bearND mdholloway dbrant: I believe the gradlization patches are ready for review at your convenience. [20:40:10] niedzielski: have some comments for you on the first java-mwapi patch [20:40:16] bearND: thanks [20:42:57] vibha: just saw your phab comment. you mean the categories appearing at the bottom of some articles? [21:05:02] dbrant: i'm going to take the cards assigned to you in the qa column, cool? [21:05:11] niedzielski: totally [21:05:36] dbrant: do they move to done or ready for signoff when they pass? [21:05:58] niedzielski: eh... Done, in this case. [21:06:06] dbrant: sounds good, thanks [22:53:41] niedzielski: How are you building java-mwapi from gradle in your patches? I'm getting javadoc related build errors with "./gradlew clean build" [22:54:16] bearND: sorry, i was looking into that. i always use assemble, checkstyle, and test separately [22:54:37] bearND: for some reason, checkstyle was working but checkstyle invoked through build was not [22:56:19] niedzielski: hmm, assemble spits out the same javadoc errors for me [22:56:52] bearND: hm, i guess i meant assembleDevDebug specifically but i didn't think that would matter [22:57:34] niedzielski: oh, i see you mean building from the app. I was building the library standalone [22:58:24] bearND: the pathing was different which my latest patch revisions fix [23:00:20] bearND: for the readme changes (since i don't have a mac), is it correct to just change the java version numbers? [23:01:39] bearND: or maybe we don't need any of that? [23:04:10] niedzielski: I think just changing the JDK version to 7+ would be good to have, esp. since we added the 1.7 compatibility flag. So, Java 6 definitely wouldn't cut it. Anything higher should be fine. [23:06:38] bearND: ok i think all comments should be addressed [23:14:31] niedzielski: ok, i think we can remove the Mac OS specific block. I don't think it's needed. Sorry for the misunderstanding earlier [23:14:46] bearND: sounds good to me. will zap [23:15:30] niedzielski: In addition to running tests it would be good to also add to the REAME how to run the build, and add a link to the publish to OSSRH process on our wiki [23:15:44] niedzielski: Lastly, I still get the build error: https://phabricator.wikimedia.org/P974 [23:16:51] niedzielski: I'm using JDK 8 btw. If you want I can try it with 7 [23:18:36] bearND: weird. i have not seen that error. we do force (?) JDK7 in the gradle file so i *thought* it didn't matter. i do see this ominous-esque warning in your output: warning: [options] bootstrap class path not set in conjunction with -source 1.7 [23:19:03] bearND: do you have both JDK7 and JDK8 installed? [23:20:02] niedzielski: yes, (and more). I can switch back and forth by updating some sym links [23:20:28] niedzielski: ok, switching to JDK 7 did the trick [23:20:36] :( [23:27:52] bearND: hm, would you mind trying something for me? switch to jdk8 and edit lib/build.gradle [23:27:55] bearND: compileJava { [23:27:55] sourceCompatibility = JavaVersion.VERSION_1_7 [23:27:55] targetCompatibility = JavaVersion.VERSION_1_7 [23:27:55] } [23:28:11] bearND: so just wrapping the existing lines in a compilejava block [23:28:21] niedzielski: ok, will do [23:31:23] niedzielski: it looked promising when I loaded the Gradle file into Android Studio. The warning for the 1.7 compat level stuff (that it was unused) went away. But it still gives me the same errors [23:36:44] niedzielski: oh wait. It works. [23:37:02] \o/ [23:37:21] bearND: gr8, i'm going to push that change [23:37:28] niedzielski: strangely enough, i get the same warning "warning: [options] bootstrap class path not set in conjunction with -source 1.7" but the javadoc errors went away [23:37:50] bearND: i wonder if the warning is for non-compileJava based tasks? [23:37:57] completely a guess [23:38:55] niedzielski: doesn't look like it. In STDOUT it came right after ":lib:compileJava" [23:39:16] bearND: even with parallel off? [23:40:23] niedzielski: yes, I just tried with parallel off, too (had it on earlier) [23:40:46] bearND: hm, ok then yep, weird stuff :) [23:46:15] bearND: patches are ready again. gotta check out for a bit (we're getting ready for moving day this weekend). will be back later tonight to follow up on any comments. thanks for all your help [23:48:41] niedzielski: sounds good. I'll leave comments in Gerrit [23:49:53] bearND: thanks, see ya in a bit