[14:54:58] MatmaRex: Hmm. I was trying to do something with oojs-ui, and thought that removing and reinstalling the node_modules might help. Now it's whining that 'grunt-contrib-concat-sourcemaps' is not in the npm registry. [14:55:47] anomie: as in, you did rm -rf node_modules && npm install, and it's borked? [14:55:51] anomie: Did you do `npm install`? [14:56:03] MatmaRex: Yes. [14:56:11] James_F: That error is *from* `npm install` [14:56:14] also, James_F knows this better than me, i try to steer clear of that stuff [14:56:18] anomie: Fun. [14:56:22] * James_F tries to replicate. [14:56:34] anomie: This is in your OOUI repo? [14:56:50] James_F: Checkout of https://gerrit.wikimedia.org/r/oojs/ui [14:56:57] * James_F nods. [14:57:15] * anomie decides to try a completely fresh clone, just in case [14:57:30] * anomie encounters the same error [14:59:10] * anomie notes that Google's cache at https://webcache.googleusercontent.com/search?q=cache:vav_HtHQSj0J:https://www.npmjs.com/package/grunt-contrib-concat-sourcemaps+&cd=1&hl=en&ct=clnk&gl=us shows content, while the current version at https://www.npmjs.com/package/grunt-contrib-concat-sourcemaps is just a 404. [14:59:19] James_F: ^ [14:59:21] Hmm. [14:59:30] Someone may have `npm unpublish`ed. [15:00:08] * James_F waits patiently for npm install to, well, install. Or fail. [15:01:44] anomie: Just completed. `rm -rf node_modules && npm install` completed successfully. [15:02:11] (Also npm unpublish is seriously not cool for people to use.) [15:03:34] James_F: Does npm cache downloaded stuff locally somehow, so you might be fetching it from cache while I'm not? [15:03:59] anomie: I don't think so; we had to do magic to cache npm stuff for the CI system. [15:04:16] it does on windows, at least. [15:04:43] (i know because i've had issues installing packages when it corrupted this cache.) [15:08:56] Interesting. [15:12:52] Krinkle: Did you break grunt-contrib-concat-sourcemaps ? [15:13:16] James_F: So I just brought up a fresh mediawiki-vagrant, `sudo apt-get install npm`, cloned oojs/ui, and did `npm install`. Slightly different message there: "Error: No dist in grunt-contrib-concat-sourcemaps package". [15:13:47] Yeah. [15:18:29] anomie, MatmaRex: Filed https://phabricator.wikimedia.org/T116594 [15:20:33] I wasn't an npm author so I can't republish without potentially breaking things, and Krinkle might have done it deliberately? [16:14:23] tgr, anomie: make a twitchy volunteer happy and +2 a patch? -- https://gerrit.wikimedia.org/r/#/c/248803/ [16:14:43] * bd808 poked it a bit so thought it better for another to +2 [16:15:14] James_F: I did. It was part of spring cleaning temporary and testing packages from my npm account. I didn't realise this was still used since it was merged upstream months ago. [16:15:17] Fixed :) [16:17:18] bd808: Seems sane, but I don't know enough about composer junk to really want to +2 it. [16:17:44] +1 it and I will +2? [16:18:05] the only thing worth even thinking about there is the ksort() [16:18:18] and it should be plenty cheep [16:18:50] Why throw in the ksort? [16:19:21] the data is unsorted otherwise (bascially random) and looked crappy on Special:Version [16:19:39] The lock file that was used before was sorted [16:19:48] * anomie was just about to ask that [16:20:27] Yeah, go ahead. The only uses would probably benefit from the ksort and aren't so performance-critical that we need to care about it. [16:21:00] More interesting might be that the "installed" version appears to include require-dev, if we care about that. [16:21:04] thx [16:21:41] The prior lock file would have included req-dev too [16:22:18] the difference between the two files is that the lock file could be versioned in git and not actually reflect the local install state [16:22:31] for MW I don't think there is really any difference today [16:24:17] It looks to me like the lock file has separate "packages" and "packages-dev" though. [16:24:55] For mediawiki/vendor repo, I don't think we include any require-dev so it probably makes no difference to WMF wikis. [16:26:02] oh, you are correct (packages & packaged-dev in the lock) [16:26:06] *shrug* [16:39:08] anomie: OOUI build should now work from master. [16:39:11] anomie: Sorry. [16:39:17] James_F: Thanks [18:26:44] bd808: why keep ComposerLock? it doesn't seem to be used anywhere [18:50:03] tgr: It's used in maintenance/checkComposerLockUpToDate.php which is called by update.php [18:51:04] hmm [18:51:14] shouldn't that also use installed.json now? [18:51:58] isn't that check hash based an properly handled by composer.lock? [19:13:29] bd808: yes, but we check the dependency versions because the hash changes whenever the contents of the file (like description...) changes [19:14:05] right. and installed.json has no hash to check [19:14:26] it is just a list of the packages that are in vendor (directly or indirectly) [19:15:00] well there are always there directly, but may be dependencies of dependencies [19:21:19] bd808: I finally figured out how to fix the "Recursion detected in RequestContext::getLanguage" bug. It's all very simple, actually. [19:21:33] So simple, in fact, it's obvious we missed it. [19:21:51] oh? That would be neat [19:21:55] "No deployments until this bug is fixed." [19:22:01] heh [19:22:23] i know how to fix it too. but first, we need to fix the "Recursion detected in RequestContext::getLanguage" bug. [19:22:40] (see what i did there?) [19:22:47] * ori is not funny. [19:22:59] anomie and I have talked about it recently actually. AuthManager will do some things that may make it mostly go away [19:23:06] ori: I saw what you did there, but then I needed to fix the recursion detected in RequestContext::getLanguage bug [19:23:32] but honestly I think the current behavior is right (eg detect the cycle and force it to stop) [19:23:57] so the bug is really that we yell about it as a warning [19:24:20] that sounds right to me [19:24:24] Then we should log better so it disappears from main channels. [19:24:25] Yeah [19:28:15] bd808: do you have a cycle or three to spare for looking at what is broken with your bzip2 stream backport patch? [19:28:27] it did not build successfully; i updated the task with the error [19:28:30] https://gerrit.wikimedia.org/r/#/c/243223/ will probably make the warning go away. Instead we might get 'User::loadFromSession called before the end of Setup.php' ;) [19:28:58] https://phabricator.wikimedia.org/T113932#1752593 [19:29:31] ori: I saw that you tested it. I can look at it for an hour or two. I don't know if my hhvm core fu will be strong enough to solve it [19:29:43] np, thanks a ton for doing this in the first place [19:30:24] * bd808 tries to remember if he has an hhvm build server laying around in labs somewhere [19:37:12] bd808: i think i may have figured it out [19:39:03] bd808: it was https://github.com/facebook/hhvm/commit/f4f799a566d8890efb2818f9b81b9562420088eb [19:39:15] you had req::ptr, we are still on SmartPtr [19:39:50] *nod* sounds reasonable [19:40:25] I just cherry-picked the upstream and didn't try it at all :/ [23:53:00] TimStarling: for your consideration : https://gerrit.wikimedia.org/r/#/c/249025/ [23:53:34] a top level project? [23:53:56] I will have a look [23:54:12] we don't have a gerrit namespace for PHP libraries [23:54:20] the convention has been to place them in the top level [23:54:42] thanks