[01:02:41] <hoo>	 legoktm: Around?
[01:08:05] <legoktm>	 hoo: hi
[01:08:35] <hoo>	 throw new PasswordError( 'Invalid hash given' );
[01:08:43] <hoo>	 in PasswordFactory::newFromCiphertext
[01:08:47] <hoo>	 a user is reporting to see that
[01:08:55] <hoo>	 but I can't find *anything* in the logs
[01:09:01] <hoo>	 newly migrated global account
[01:09:13] <hoo>	 can successfully log in according to CA logs
[01:09:27] <hoo>	 but he says, he ends up at a pick a new password form
[01:09:29] <hoo>	 and then that fails
[01:09:45] <hoo>	 https://de.wikipedia.org/wiki/Wikipedia:Benutzernamen_%C3%A4ndern#2014-12-23_Kann_Passwort_nach_dem_Globalisieren_nicht_.C3.A4ndern
[01:09:48] <hoo>	 I'm clueless
[01:10:02] <legoktm>	 umm, are they in the labsdb password reset list?
[01:10:06] <hoo>	 the password hash is ok and testing the passwords works fine from hhvm and zend
[01:10:15] <hoo>	 could be, no idea
[01:11:57] <hoo>	 yep, he is
[01:12:40] <hoo>	 legoktm: What to do now? Just delete the rows and tell them to reset the password manually?
[01:12:54] <hoo>	 Or do you need the user for debugging, or... ?
[01:12:57] <legoktm>	 have they gone through the password reset process?
[01:13:09] <hoo>	 It fails :/
[01:13:24] <legoktm>	 with an exception?
[01:13:36] <hoo>	 apparently
[01:13:42] <hoo>	 that text is only present in that one exception
[01:13:48] <hoo>	 but the exception is never logged
[01:14:10] <hoo>	 hasn't been logged a single time in the last 90d
[01:14:42] <hoo>	 dewiki: Aborting login until they reset password: Stilfehler
[01:15:27] <legoktm>	 just delete the row then?
[01:15:49] <hoo>	 Ok
[01:15:56] <hoo>	 shall we maybe disable that whole thing?
[01:22:41] <legoktm>	 or convert it to use the real password reset mechanism in core?
[01:22:52] <legoktm>	 the password expiry thing
[01:24:14] <hoo>	 If you think that's worth it
[01:25:54] <legoktm>	 well, it depends on how many users are left
[01:26:56] <hoo>	 More than 50%
[01:27:07] <hoo>	 25057 of 41079
[01:27:07] <legoktm>	 :|
[01:39:25] <hoo>	 legoktm: https://gerrit.wikimedia.org/r/181710
[01:39:51] <hoo>	 I would like to push taht today and not wait until next year
[01:40:26] <hoo>	 I'm afraid of breaking accounts where people don't know how to complain or just don't care enough and then give up :(
[01:41:22] <hoo>	 diff with --ignore-all-space to get a decent diff
[10:29:34] <Nikerabbit>	 _joe_: it looks like the default hhvm init script or the 'default file' is broken, where should I report that?
[11:26:42] <Nikerabbit>	 wtf Salt is weird
[11:29:40] <Nikerabbit>	 https://github.com/saltstack/salt/issues/13312
[11:35:20] <wikibugs>	 3MediaWiki-Core-Team: Look into Maria 10 parallel-replication - https://phabricator.wikimedia.org/T85266#942877 (10aaron) 3NEW
[11:35:32] <wikibugs>	 3MediaWiki-Core-Team: Look into Maria 10 parallel-replication - https://phabricator.wikimedia.org/T85266#942877 (10aaron)
[13:57:05] <_joe_>	 Nikerabbit: you mean in our package?
[13:57:20] <_joe_>	 sorry, I was travelling this morning
[13:57:28] <_joe_>	 Nikerabbit: to me is fine
[14:23:28] <Nikerabbit>	 _joe_: as far as I can see it does not even start with the default settings... not even if I change it to use server.ini
[14:24:02] <_joe_>	 Nikerabbit: sorry I meant "I am the right person to report this to"
[14:24:28] <_joe_>	 Nikerabbit: mmmh I'll check it out
[14:26:35] <_joe_>	 Nikerabbit: upstart or the traditional init?
[14:27:45] <Nikerabbit>	 _joe_: upstart I believe
[14:28:02] <_joe_>	 ok thanks, I suspected it
[14:29:44] <Nikerabbit>	 is there any way to get output or exit codes from the start-stop-daemon? It's pretty frustrating when it starts a service which dies/exists immediately with no output
[14:33:33] <_joe_>	 Nikerabbit: I'll remove that from the upstart script btw
[14:36:40] <Nikerabbit>	 _joe_: start-stop-daemon?
[14:48:56] <Nikerabbit>	 WARNING: Logging before InitGoogleLogging() is written to STDERR
[14:49:02] <Nikerabbit>	 suspicious I say?
[14:49:09] <Nikerabbit>	 -?
[14:50:48] <Nikerabbit>	 hmph, I'm just unable to start hhvm and unable to figure out why
[14:52:37] <Nikerabbit>	 I guess I need to read some http://upstart.ubuntu.com/cookbook/
[14:53:23] <_joe_>	 Nikerabbit: I'll fix that in the coming weeks, today I'm just trying to wrap a few things up 
[14:53:37] <_joe_>	 as I have a few days off until the new year
[15:16:58] <Nikerabbit>	 gosh I am so stupid!
[15:17:37] <Nikerabbit>	 I had mixed up /etc/init/hhvm{.conf}
[15:18:09] <Nikerabbit>	 hours wasted on that ;)
[15:27:16] <_joe_>	 if you have a bug report, please do it anyway
[16:56:08] <wikibugs>	 3MediaWiki-Core-Team, Librarization: Create RFC for library extraction (PHP & javascript) practices - https://phabricator.wikimedia.org/T1017#943155 (10bd808) Draft on wiki now! <https://www.mediawiki.org/wiki/Requests_for_comment/Guidelines_for_extracting,_publishing_and_managing_libraries>  I will announce on...
[16:57:36] <bd808>	 legoktm, ^demon|away, Krinkle|detached: ^ RFC draft on wiki now. Would love feedback and edits. I think all of you could become co-authors too but I didn't want to put you on without asking.
[17:05:03] <Reedy>	 bd808: https://gerrit.wikimedia.org/r/#/c/181730/
[17:06:48] <MatmaRex>	 bd808: legoktm: in fact, things like the API are already using the LoginForm class (which implements the special page) as if it was just such "login controller".
[17:07:02] <MatmaRex>	 i think we could totally split them up in a reasonable way in a few hours of work.
[17:21:57] <bd808>	 Reedy: good catch. {{done}]
[17:24:30] <wikibugs>	 3MediaWiki-Core-Team: Authn and authz as a service - https://phabricator.wikimedia.org/T84962#943201 (10bd808) I think we should consider issues like {T19312} to be in scope for this project. It seems reasonable to me that we will need to refactor/rethink the authn/authz stack inside MediaWiki in order to make i...
[18:11:05] <legoktm>	 bd808: so chris's jenkins job thing is "working" except he was waiting on monolog to accept his security patch to make sure it actually works...
[18:11:50] <bd808>	 legoktm: excellent.
[18:12:17] <legoktm>	 https://integration.wikimedia.org/ci/job/test-csteipp-sensiolabs-securityadvisorieschecker/
[18:12:36] <legoktm>	 https://github.com/Seldaek/monolog/pull/448 is disappointing though :(
[18:14:04] <bd808>	 Hmmm... I wonder why they don't care?
[18:16:01] <bd808>	 no comment on bug, no activity on code review. Not cool
[18:38:01] <wikibugs>	 3LabsDB-Auditor, Scrum-of-Scrums, MediaWiki-Core-Team, Security-Reviews: Manually verify whitelisted.yaml / graylisted.yaml to ensure completeness - https://phabricator.wikimedia.org/T78730#943314 (10bd808) Is there a gerrit review for this that needs attention?
[18:52:17] <bd808|LUNCH>	 Nothing surprising at SoS today. jdlrobson mentioned the lightncandy patch to vendor but I think legoktm is on top of the review for that.
[20:05:16] <ori>	 marry xmas everyone
[20:05:22] <ori>	 happy holidays
[20:06:41] * bd808 is fighting with travis-ci and losing
[20:13:46] <wikibugs>	 3MediaWiki-Installer, MediaWiki-Core-Team, Librarization: composer.json should be useable by WMF, core and extensions - https://phabricator.wikimedia.org/T67188#943399 (10bd808) The plugin is on packagist now (<https://packagist.org/packages/wikimedia/composer-merge-plugin>) so it should be a bit easier to test....
[21:27:48] <wikibugs>	 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Evaluate Titan as graph storage/query engine for Wikidata Query service - https://phabricator.wikimedia.org/T76373#943426 (10Smalyshev) Proposed storage format for dates:    # Dates are stored as long signed integers, representing number of seconds since 19...
[21:56:49] <Nikerabbit>	 will you merry me
[21:58:57] <legoktm>	 sure
[22:13:17] <bd808>	 argh. legoktm that crapy hack for importing plancake with composer breaks my cool new toy. :/
[22:13:26] <legoktm>	 awwwwww
[22:13:53] <legoktm>	 bd808: we should just move it into BounceHandler at this point...
[22:14:03] <bd808>	 yeah we really should
[22:14:16] <bd808>	 one class that has been abandoned basically
[22:14:33] <bd808>	 or get Tony to find something that's not abandonware
[22:16:02] <bd808>	 the plugin is really close to working. We it actually works now but I realized that I did something I don't love with the config
[22:18:10] <legoktm>	 oh?
[22:19:19] <bd808>	 I documented what I wanted for the config in the README but then wrote the code differently :/
[22:19:24] <legoktm>	 heh
[22:19:37] <bd808>	 https://github.com/wikimedia/composer-merge-plugin/issues/2
[22:20:14] <legoktm>	 :P
[22:20:14] * bd808 adds legoktm to a team that has access to push to that repo
[22:20:27] <legoktm>	 I think I already had push access?
[22:20:44] <legoktm>	 Or at least I can edit the description and url :P
[22:20:50] <bd808>	 oh probably. you're an admin right?
[22:20:54] <legoktm>	 I think so
[22:21:11] <bd808>	 I just made a "composer" team that consists of you an me at the moment
[22:21:16] <bd808>	 s/at/and/
[22:21:23] <bd808>	 whatever
[22:21:27] <bd808>	 typing sucks
[22:22:08] <bd808>	 Want to merge the first pull request there? https://github.com/wikimedia/composer-merge-plugin/pull/1
[22:22:38] <legoktm>	 done
[22:22:42] <bd808>	 I finally got travis beat into submission -- https://travis-ci.org/wikimedia/composer-merge-plugin
[22:23:58] <legoktm>	  Failed to download symfony/process from dist: You must enable the openssl extension to download files via https
[22:23:58] <legoktm>	 Now trying to download from source
[22:24:24] <bd808>	 is that at travis? I saw it do that the other day too
[22:24:29] <legoktm>	 yeah
[22:30:37] <legoktm>	 other projects I saw that use travis usually specify --prefer-source
[22:30:44] <legoktm>	 But why would travis just not enable the openssl extension?
[22:31:12] <bd808>	 *shrug*
[22:31:36] <legoktm>	 https://github.com/travis-ci/travis-cookbooks/pull/401 :||||||
[22:31:54] <bd808>	 yeah
[22:32:18] <bd808>	 I'm bad at nagging about those kinds of things :/
[22:32:33] <bd808>	 take my fix or don't, whatever jerk
[22:53:11] <Nikerabbit>	 bd808: oh cool that is the issue I was having
[22:54:07] <bd808>	 Nikerabbit: Yeah. The work around for the moment is to use the other syntax if you want to hunt for other bugs
[22:54:33] <bd808>	 I'll get it fixed "soon" but xmas family obligations start soon
[22:55:28] <Nikerabbit>	 bd808: good to know.. I might want to use it on my pet project soon
[22:55:52] <bd808>	 I want to get to "1.0" next week if possible
[22:56:30] <wikibugs>	 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Evaluate Titan as graph storage/query engine for Wikidata Query service - https://phabricator.wikimedia.org/T76373#943453 (10GWicke) >>! In T76373#943426, @Smalyshev wrote: > Proposed storage format for dates: >  >   # Dates are stored as long signed intege...
[23:02:40] <wikibugs>	 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Evaluate Titan as graph storage/query engine for Wikidata Query service - https://phabricator.wikimedia.org/T76373#943454 (10Smalyshev) @GWicke Do we really need per-second precision transitioning between year 292M and 292M+1? I'm not sure it is ever requir...
[23:08:30] <wikibugs>	 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Evaluate Titan as graph storage/query engine for Wikidata Query service - https://phabricator.wikimedia.org/T76373#943458 (10GWicke) >>! In T76373#943454, @Smalyshev wrote: > seconds(292M-12-31T23:59:59) < seconds(292M+1)  It's pretty likely that there were...
[23:11:23] <wikibugs>	 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Evaluate Titan as graph storage/query engine for Wikidata Query service - https://phabricator.wikimedia.org/T76373#943459 (10Smalyshev) For dates beyond real Gregorian calendar, the values more precise than years have little meaning anyway, so I don't think...
[23:27:14] <wikibugs>	 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Evaluate Titan as graph storage/query engine for Wikidata Query service - https://phabricator.wikimedia.org/T76373#943462 (10GWicke) >>! In T76373#943459, @Smalyshev wrote: > For dates beyond real Gregorian calendar, the values more precise than years have...