Hi everyone
We have another ArchCom-RFC IRC office hour coming up tomorrow. This
week, we plan to discuss what parts of the notification infrastructure
in Echo we can/should move into MediaWiki Core (T128351). Brion is
shepherding this RFC, and pointed out on the task that we need "good
enough interfaces in core that other extensions don't have to depend
on Echo; also agreed that shipping Echo with core as a default
extension makes sense." Much of the recent discussion on that task
has been about what a reasonable level of abstraction, and avoiding
generalizing from a sample set of 1 (as Tgr puts it)
Discussion time/place:
#wikimedia-office: 2016-08-03 (Wednesday) 21:00 UTC (2pm PDT, 23:00 CEST)
More details about the meeting: <https://phabricator.wikimedia.org/E251>
More details about the topic: <https://phabricator.wikimedia.org/T128351>
Rob
p.s. ArchCom status updates continue on
<https://www.mediawiki.org/wiki/Architecture_committee/Status>
Hey,
This is the 15th weekly update from revision scoring team that we have sent
to this mailing list.
*New developments:*
- We'll no longer unnecessarily load the models into memory on the web
workers[1].
- We can now score multiple models against the same revision ID for
(essentially) free[2].
- Our precaching system will take advantage of this to drop load by
about 3X[3].
- Update wmflabs deploy repo for new version of ORES[4].
*Documentation & maintenance:*
- We completed deployment and maintenance docs for Wiki labels[5], which
means we've now got complete docs for our systems[6].
- We implemented basic continuous integration tests for the ORES
extension[7].
*Downtime:*
- We had a 1 hour long downtime while trying to deploy new code to
ores.wikimedia.org[8]. We've filed two critical tasks for making sure
we don't make the mistake again[9,10].
1. https://phabricator.wikimedia.org/T134606 - Score multiple models with
the same cached dependencies
2. https://phabricator.wikimedia.org/T139407 - Don't load models into
memory of web workers
3. https://phabricator.wikimedia.org/T141376 - Update precached to group
requests by model
4. https://phabricator.wikimedia.org/T141377 - Update wmflabs deploy repo
for new version of ORES
5. https://phabricator.wikimedia.org/T131768 - Wikilabels deployment docs
6. https://phabricator.wikimedia.org/T106271 - Document maintenance tasks
7. https://phabricator.wikimedia.org/T140455 - CI test for ORES extension
8. https://wikitech.wikimedia.org/wiki/Incident_documentation/20160801-ORES
9. https://phabricator.wikimedia.org/T141823 - Set up password on ORES Beta
redis server
10. https://phabricator.wikimedia.org/T141825 - Config beta ORES extension
to use the beta ORES service
Sincerely,
Aaron from the Revision Scoring team
Hi,
i just have a problem with confirmAccount. I would like to understand.
I use this extension. Just to confirm when someone ask createAccount, with
confirm email.
(My version of mediawiki 1.27)
1. User ask createAccount
2. i have this message in specialpage, BUT NOT in my MAIL
However i have in my localsettings.php :
$wgConfirmAccountContact = *"myemail**(a)gmail.com <http://gmail.com>"*;
3. In the email of user, he have confirmation and link to do it
==> Click and we can see on specialpage he confirmed.
4. Administrateur have to approuvate.
But when he do that, system return :
"Soit une erreur s’est produite sur la base de données d’authentification,
soit vous n’êtes pas autorisé à mettre à jour votre compte externe." (in
french, because i am)
Someone can help me to understand ?
thank's for all
yonnel
--
adresse mail : yonnel.kurtz(a)gmail.com
mobile : 07 61 72 79 12
Identifiant de société : Siren : 501 161 384
Code NAF : 722C
Siret : 501 161 384 00018
Code Insee : C75017862440
Hi,
i just have a problem with confirmAccount. I would like to understand.
I use this extension. Just to confirm when someone ask createAccount, with
confirm email.
(My version of mediawiki 1.27)
1. User ask createAccount
2. i have this message in specialpage, BUT NOT in my MAIL
However i have in my localsettings.php :
$wgConfirmAccountContact = *"myemail**(a)gmail.com <http://gmail.com>"*;
3. In the email of user, he have confirmation and link to do it
==> Click and we can see on specialpage he confirmed.
4. Administrateur have to approuvate.
But when he do that, system return :
"Soit une erreur s’est produite sur la base de données d’authentification,
soit vous n’êtes pas autorisé à mettre à jour votre compte externe." (in
french, because i am)
"An error occurred on the basis of authentication database or you are not
allowed to update your external account."
I don't understand, because i m sysop with *myemail**(a)gmail.com
<http://gmail.com/>*
can you hemp me ?
thank's !
yonnel
--
adresse mail : yonnel.kurtz(a)gmail.com
mobile : 07 61 72 79 12
Identifiant de société : Siren : 501 161 384
Code NAF : 722C
Siret : 501 161 384 00018
Code Insee : C75017862440
Hello,
I'm trying to include some output from
https://wikimedia.org/api/rest_v1/?doc into a Wikipedia
(xy.wikipedia.org) via a Javascript AJAX call.
Is it possible to have a JSONP output? I have not found any
documentation so far. Otherwise, would there be any other way (avoiding
a backend part, of course)?
Thanks,
--
Toni Hermoso Pulido
http://www.cau.cathttp://www.similis.cc
tl;dr: WMF Continuous Integration will have downtime on Tuesday August
2nd starting at about 16:00 UTC due to a WMF Labs infrastructure
upgrade. Don't expect Jenkins to report test failure/passing on your
changes during this time.
Apologies for the disruption,
Greg on behalf of the Release Engineering team
----- Forwarded message from Andrew Bogott <abogott(a)wikimedia.org> -----
> Date: Mon, 25 Jul 2016 11:57:15 -0500
> From: Andrew Bogott <abogott(a)wikimedia.org>
> To: labs-announce(a)lists.wikimedia.org, Release Engineering <releng(a)lists.wikimedia.org>, Operations Engineers <ops(a)lists.wikimedia.org>
> Subject: [RelEng] Labs Openstack upgrade next Tuesday, 2016-08-02, 16:00 UTC
> Reply-To: andrewbogott(a)gmail.com
>
> I'm going to upgrade our Openstack install from version 'Kilo' to
> version 'Liberty' next Tuesday. I've scheduled a 3-hour window for the
> process, although noticeable service interruptions should be shorter.
> Here's what to expect:
>
> - Tools services and existing Labs uses should be unaffected apart from
> brief ( < 1 minute) interruptions in network service.
>
> - Continuous Integration tests (Jenkins, Zuul, etc.) will be disabled for
> most of the upgrade window.
>
> - Creation/Deletion of new instances will be disabled for most of the
> window.
>
> - Wikitech and Horizon may error out occasionally and/or display
> inconsistent information. Users may need to refresh their web logins after
> the upgrade.
>
> Apart from fixing a few seldom-seen bugs, this upgrade shouldn't result in
> noticeable changes for Labs users. It will lay the groundwork for an
> upcoming Horizon upgrade, but that will be announced in a future email.
>
> -Andrew
>
>
>
> _______________________________________________
> RelEng mailing list
> RelEng(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/releng
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
On Tue, Aug 2, 2016 at 5:57 PM, Jefsey <jefsey(a)jefsey.com> wrote:
> At 02:44 02/08/2016, John wrote:
>>
>> For mass imports, use importDump.php - see
>> <<http://www.mediawiki.org/wiki/Manual:Importing_XML_dumps>http://www.mediawiki.org/wiki/Manual:Importing_XML_dumps>
>> for details.
>
>
> Dear John,
>
> Thank you for your response. But I am dump myself and I am still lost.
>
> I am not sure I made my need clear enough. I had wikis under MySQL I dumped
> in XML. So I have n XML files to create n separate SQLite wikis. One file
> one SQLite wiki (n is around 35).
>
> When I try to read with an XML viewer these files, they tell me that some
> character in line 295 or so is wrong and they cannot read it, so I do not
> really know how they are structured.
>
> Therefore, my question is about how to create the n SQLwikis I need and
> import in each the pages which are in XML dumped from MySQL.
>
> Also, further on, I understand that the manual is reporting about MySQL
> dumps, not about SQLite dumps? Does that mean that I should consider their
> backup with SQLite tools rathere than mediwiki tools? Hence my question
> about a mediawiki SQLite section/mailing list?
>
> Sorry I am pretty new to this and need to take care of a lot of small
> Libre/Citizen/locally oriented wikis, with more to come. So I try to figure
> out the best way to manage all this ....
>
> Thank you !
>
> jfc
>
>
Note, that there is an XML dump format used by MediaWiki, but there is
also an xml dump format used by mysqldump. Its unclear from your email
which one of those you have. The previous people in the thread are
assuming you're talking about a MediaWiki xml dump file, but if you
are talking about a mysql XML dump file, things are probably going to
be much harder to convert to sqlite.
--
brian
XML dumps are xml dumps regardless of the backend used. The importdump.php
tool that I referenced takes care of the minor differences between the
versions. Go ahead and follow the process for importing XML databases.
On Tue, Aug 2, 2016 at 1:57 PM, Jefsey <jefsey(a)jefsey.com> wrote:
> At 02:44 02/08/2016, John wrote:
>
> For mass imports, use importDump.php - see <
> http://www.mediawiki.org/wiki/Manual:Importing_XML_dumps> for details.
>
>
> Dear John,
>
> Thank you for your response. But I am dump myself and I am still lost.
>
> I am not sure I made my need clear enough. I had wikis under MySQL I
> dumped in XML. So I have n XML files to create n separate SQLite wikis. One
> file one SQLite wiki (n is around 35).
>
> When I try to read with an XML viewer these files, they tell me that some
> character in line 295 or so is wrong and they cannot read it, so I do not
> really know how they are structured.
>
> Therefore, my question is about how to create the n SQLwikis I need and
> import in each the pages which are in XML dumped from MySQL.
>
> Also, further on, I understand that the manual is reporting about MySQL
> dumps, not about SQLite dumps? Does that mean that I should consider their
> backup with SQLite tools rathere than mediwiki tools? Hence my question
> about a mediawiki SQLite section/mailing list?
>
> Sorry I am pretty new to this and need to take care of a lot of small
> Libre/Citizen/locally oriented wikis, with more to come. So I try to figure
> out the best way to manage all this ....
>
> Thank you !
>
> jfc
>
>
> On Mon, Aug 1, 2016 at 8:37 PM, Jefsey <jefsey(a)jefsey.com> wrote:
> I am not familiar with databases. I have old MySQL based wikis sites I
> cannot access anymore due to a change in PHP and MySQL versions. I have old
> XML dumps. Is it possible to reload them under SQLight wikis? These were
> working group wikis: we only are interested in restoring texts. We have the
> images. We are not interested in the access rights: we will have to rebuild
> them anyway.
>
> Thank you for the help !
> jefsey
>
> PS. We dedicate to light wikis which are OK under SQLight, would there be
> a dedicated list to SQLight mangement (and further on development)?
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
At 02:44 02/08/2016, John wrote:
>For mass imports, use importDump.php - see
><<http://www.mediawiki.org/wiki/Manual:Importing_XML_dumps>http://www.mediawiki.org/wiki/Manual:Importing_XML_dumps>
>for details.
Dear John,
Thank you for your response. But I am dump myself and I am still lost.
I am not sure I made my need clear enough. I had wikis under MySQL I
dumped in XML. So I have n XML files to create n separate SQLite
wikis. One file one SQLite wiki (n is around 35).
When I try to read with an XML viewer these files, they tell me that
some character in line 295 or so is wrong and they cannot read it, so
I do not really know how they are structured.
Therefore, my question is about how to create the n SQLwikis I need
and import in each the pages which are in XML dumped from MySQL.
Also, further on, I understand that the manual is reporting about
MySQL dumps, not about SQLite dumps? Does that mean that I should
consider their backup with SQLite tools rathere than mediwiki tools?
Hence my question about a mediawiki SQLite section/mailing list?
Sorry I am pretty new to this and need to take care of a lot of small
Libre/Citizen/locally oriented wikis, with more to come. So I try to
figure out the best way to manage all this ....
Thank you !
jfc
>On Mon, Aug 1, 2016 at 8:37 PM, Jefsey
><<mailto:jefsey@jefsey.com>jefsey(a)jefsey.com> wrote:
>I am not familiar with databases. I have old MySQL based wikis sites
>I cannot access anymore due to a change in PHP and MySQL versions. I
>have old XML dumps. Is it possible to reload them under SQLight
>wikis? These were working group wikis: we only are interested in
>restoring texts. We have the images. We are not interested in the
>access rights: we will have to rebuild them anyway.
>
>Thank you for the help !
>jefsey
>
>PS. We dedicate to light wikis which are OK under SQLight, would
>there be a dedicated list to SQLight mangement (and further on development)?
>
>_______________________________________________
>Wikitech-l mailing list
><mailto:Wikitech-l@lists.wikimedia.org>Wikitech-l(a)lists.wikimedia.org
>https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hi all,
With some help from Brandon, I've changed deployment-prep to use Let's
Encrypt instead of the self-signed cert I added last year (to get HTTPS
working - albeit improperly-signed - instead of nothing, and nginx/puppet
working on the Varnish instances again).
It should now behave much more like production - TLS redirects are enabled
in Varnish, and you shouldn't have to ignore cert warnings to use it now.
Details for HTTPS in deployment-prep are spread out over various tickets,
but the main one now is https://phabricator.wikimedia.org/T50501
The puppetisation still needs some work, but it's cherry-picked on
deployment-puppetmaster and seems to be working reliably.
Pages with images may need to be null-edited to make MediaWiki generate
HTTPS URLs for them so browsers don't block the images.
Please let me know if you find any beta.wmflabs.org domains that aren't
covered by the cert or aren't redirecting HTTP to HTTPS in Varnish.
--
Alex Monk