Bug#1027959: transition: libkiwix

[Kunal Mehta]

Hi,

On 6/19/23 18:36, Sebastian Ramacher wrote:

Let's do this one properly during the trixie release cycle.


What's the status here?


I think we're ready to go. libzim is sorted (the ABI change was 
reverted, unstable is now at 8.1.1).


I just uploaded libkiwix 12.0.0-2 (to fix 2 RC bugs) and kiwix-tools 
3.5.0-1 (new upstream version) to experimental, those two plus kiwix 
2.3.1-1 should be set.


-- Kunal

Bug#1027959: transition: libkiwix

[Kunal Mehta]

Hi,

On 1/5/23 04:48, Sebastian Ramacher wrote:


I'd like to do the transition for libkiwix (and sibling libzim) in time
for bookworm, it's fully self-contained.

I uploaded src:zimlib 8.1.0 to unstable last week, which unintentionally
had a breaking change in it (sorry!). libkiwix 12.0.0 is waiting in 
experimental.


If it had an ABI breaking change, you also have to do a transition for
it. Please revert in unstable in the meantime and prepare the transition
in experimental.


Ack and done. libzim 8.1.0 is in experimental now, and unstable is back 
to 8.0.0.


Thanks,
-- Kunal

Bug#1027959: transition: libkiwix

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hi,

I'd like to do the transition for libkiwix (and sibling libzim) in time
for bookworm, it's fully self-contained.

I uploaded src:zimlib 8.1.0 to unstable last week, which unintentionally
had a breaking change in it (sorry!). libkiwix 12.0.0 is waiting in 
experimental.

Status of reverse dependencies for compatibility with new libkiwix+libzim:
* zim-tools: needs binNUM for libzim 8.1.0
* python-libzim: fixed with 2.1.0, currently in unstable
* kiwix-tools: fixed with 3.4.0, waiting in experimental
* kiwix: fixed with 2.3.1, waiting in experimental


Ben file:

title = "libkiwix";
is_affected = .depends ~ "libkiwix11" | .depends ~ "libkiwix12";
is_good = .depends ~ "libkiwix12";
is_bad = .depends ~ "libkiwix11";


Thanks,
-- Kunal

Bug#1017886: transition: zimlib

[Kunal Mehta]

Hi,

On 8/28/22 11:18, Sebastian Ramacher wrote:

I'd like to do a transition of libzim 7->8. I've done local rebuilds
of all the reverse dependencies, python-libzim needs a patch (ready in
experimental), and all the rest (zim-tools, libkiwix, kiwix-tools, kiwix)
will need binNMUs.


Please go ahead


Thanks, I've uploaded both zimlib and python-libzim; should be ready for 
the binNMUs now.


-- Kunal

Bug#1017886: transition: zimlib

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hi,

I'd like to do a transition of libzim 7->8. I've done local rebuilds
of all the reverse dependencies, python-libzim needs a patch (ready in
experimental), and all the rest (zim-tools, libkiwix, kiwix-tools, kiwix)
will need binNMUs.

Ben file:

title = "zimlib";
is_affected = .depends ~ "libzim7" | .depends ~ "libzim8";
is_good = .depends ~ "libzim8";
is_bad = .depends ~ "libzim7";

Thanks!
-- Kunal

Bug#1016393: transition: libkiwix

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hi,

I would like to upgrade libkiwix from v10 to v11. The two reverse
dependencies are kiwix and kiwix-tools. All three packages look
good in experimental (still waiting on mips builds, but usually that's
not a problem).

Ben file:

title = "libkiwix";
is_affected = .depends ~ "libkiwix10" | .depends ~ "libkiwix11";
is_good = .depends ~ "libkiwix11";
is_bad = .depends ~ "libkiwix10";

Thanks,
-- Kunal

Bug#1004717: transition: libkiwix and libzim

[Kunal Mehta]

Hi,

On 2/1/22 23:57, Sebastian Ramacher wrote:

Please go ahead


Thanks, everything has been uploaded.

-- Kunal

Bug#1004717: transition: libkiwix and libzim

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hello,

libkiwix and libzim have new major versions with SONAME bumps, requiring
a transition. Both are maintained by the same upstream and basically in
sync with each other, so it makes sense to do as one transition.

All reverse dependencies have new upstream versions as well,
which I've prepared and tested in experimental.

Ben file:

title = "libkiwix and libzim";
is_affected = .depends ~ /(libzim6|libkiwix9)/ | .depends ~ 
/(libzim7|libkiwix10)/;
is_good = .depends ~ /(libzim7|libkiwix10)/;
is_bad = .depends ~ /(libzim6|libkiwix9)/;


Thanks,
-- Kunal

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Kunal Mehta]

Hi,

On 1/19/22 14:08, Bryce Harrington wrote:

On Wed, Jan 19, 2022 at 09:58:52PM +0100, Paul Gevers wrote:

Hi Bryce,

On 19-01-2022 10:28, Bryce Harrington wrote:


With [4] applied, I'm seeing the following dumped on armhf:

## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
cat: /var/log/mediawiki/error.log: No such file or directory
2022-01-19 09:16:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[e33d1ec89af515673078437e] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:27 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[1284cbae5a84eb5387f33003] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 152 of /usr/share/mediawiki/includes/HookContainer/HookContainer.php: 
Maximum execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[31731278ed6070e946af4fbe] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
cat: /var/log/mediawiki/fatal.log: No such file or directory


Thanks for applying the patch and testing it!


As this issue seems intermittent (as mediawiki passed at one point) I guess
you're trying to say that you think mediawiki got slower with php8.1? Or is
this timeout new with php8.1?


The failing cases are mostly ones with triggers for
php-defaults/84~0ubuntu1 or newer, which marks where php8.1 is set as
default.  The ones that pass and don't specify that are thus running
php8.0.  So it looks like the pass-vs-fail correlates to php8.0-vs-8.1
and is something specific to armhf.

Unfortunately I don't have i386 builds to compare with (due to
dependency issues), so it's just a hunch that this is the same problem
Debian sees on i386.  It'd be illuminating to doublecheck on your i386
builds that it's also hitting this same timeout situation.


Obviously the code that fails to finish is mediawiki's code, so it
doesn't seem to be a generic issue with php8.1 except if the timeout
happens because of something inside php8.1.


Line 110 that the error points to appears to be a json_encode() call.


Can anybody shed a light on if it's reasonable to time out on what
mediawiki is trying to do here. And why doesn't it happen on other
architectures (in Debian, as far as I checked)?


MediaWiki is just loading the page, which in theory should be cheap 
(<1s), but since it's the first page load it will be filling empty 
caches and running background tasks which could be expensive. When I 
grepped for FormatJson::encode, I came up with SpecialRunJobs 
(background tasks) and MessageBlobStore (caching) as code paths that 
would get hit, and both have the potential to be slow/add extra time to 
page loads.



I can't tell what it may be trying to encode, but presumably it's either
Main_Page or something used by Main_Page, which I'm guessing should only
take a fraction of a second to encode.  I suppose we could test
increasing max_execution_time.  But my suspicion is that the encoder is
getting stuck in a loop or a recursion.


30 seconds seems a bit absurd, but given an empty opcache/jit, empty 
caches, on 32-bit VMs, it's within the realm of possibility...I think 
bumping max_execution_time is a good next step. Should the test add a 
php.ini snippet or something?


I read through the 8.1 changelog 
() and couldn't find 
anything relevant that wasn't already in PHP 8.0.8 (specifically 
 
looked suspect, but that was included in 8.0.7).


Just to give some expectations, I won't have time to dig into this until 
the weekend. I did drop a pointer to the bug in the MediaWiki developers 
IRC channel in case anyone there had suggestions.


-- Kunal

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Kunal Mehta]

Hi,

On 1/16/22 11:52, Paul Gevers wrote:

On 12-01-2022 21:16, Paul Gevers wrote:
Priority may lay with the mediawiki* regression on i386: "Internal 
Server Error" doesn't sound great, and other non-horde package.


Did anybody already take a look at this [1, 2, 3]? It's the last thing 
before I'll add a hint to ignore the autopkgtest regressions. 
Intermittent "Internal Server Error" sounds more like something in 
php8.1 than in mediawiki* hence my reluctance to let php-defaults 
migrate. What do you think?


Sorry, didn't get a chance to look at this until now. All 3 failures are 
most likely the same underlying cause. As for whether this is a 
MediaWiki or PHP 8.1 issue, I'm not sure. Upstream in MW we don't run 
any 32-bit CI, so it's entirely possible some 8.0 or 8.1 change broke 
something we were doing.


I don't have any i386 hardware, I tried pulling down a i386 Debian 
unstable Docker container on my amd64 laptop and installing the 
mediawiki+php8.1 packages on that but it didn't trigger the test 
failure. Do you have any other suggestions/tips on how I could debug this?


As an alternative I just committed [4] which would hopefully dump the 
underlying error message upon failure. Please let me know if it's OK for 
me to upload that without it being disruptive.



[1] https://ci.debian.net/packages/m/mediawiki-skin-greystuff/testing/i386/
[2] 
https://ci.debian.net/packages/m/mediawiki-extension-youtube/testing/i386/

[3] https://ci.debian.net/packages/m/mediawiki/testing/i386/


[4] 
https://salsa.debian.org/mediawiki-team/mediawiki/-/commit/20a94e6971be6b06d5f41338ec2811cc8572e05f


-- Kunal

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Kunal Mehta]

Hi,

On 1/8/22 13:38, Paul Gevers wrote:

php-wmerrors [7], owfs [8].


These two need upstream update.


I see no activity and no bug reports. Can somebody please update these 
packages or file appropriate bugs?


Filed #1003432 for php-wmerrors, and am working on it upstream since 
it's more involved than I initially expected. I assume it's fine if it 
drops out of testing for a bit.


-- Kunal

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Kunal Mehta]

Hi,

On 1/1/22 00:01, Paul Gevers wrote:
It seems I don't understand how PHP packaging works. I scheduled 
rebuilds of several packages that were yesterday on the tracker page [1] 
when that still only had the phpapi-* listed. Several packages can't be 
build yet it seems (because they depend on packages that need new 
uploads), but e.g. wikidiff2 built fine *but disappeared* from the 
tracker. I looked at a build log [2] and noticed that the binary has 
files in /etc/php8.1 (and not in /etc/php7.4), but doesn't tell 
otherwise (in package relations) that it's meant for php8.1 and not for 
php7.4. Why did that phpapi-* thing disappear? Is that intended? The 
built binaries already migrated to testing, while the default there is 
still php7.4. I assume we can consider php-wikidiff2 (partially?) broken 
now *in testing*? Same for php-luasandbox [3], php-geos [4], and 
php-excimer [5] (which also FTBFS on mipsel).


Previously the dh_php step would add the phpapi- dependency, 
however this was removed[1] and the new php-common dependency 
is added via pkg-pecl.mk[2]. The packaging for 
wikidiff2/luasandbox/excimer/wmerrors (all basically identical) only 
uses the dh_php step, and not pkg-pecl.mk.


If it's intentional that using dh_php alone is no longer enough, I can 
figure out how to switch those to using pkg-pecl.mk, though last I 
checked it wasn't straightforward to use for packages not actually on 
PECL, which is still the case for wikidiff2/wmerrors.


The php-excimer test failure on mipsel is most likely just a race 
condition in the test, I'll look into it in the next few days.



Some rebuilds failed, e.g. php-horde-lz4 [6], php-wmerrors [7], owfs [8].


I filed [3] upstream for wmerrors, will poke the author if I can't 
figure out the fix myself.


[1] 
https://salsa.debian.org/php-team/dh-php/-/commit/87f1657c1b26ad10b7cb919336d998b59d137313
[2] 
https://salsa.debian.org/php-team/dh-php/-/commit/fdea4536adfbb28fb55ac3e3d0a247faae2b597b

[3] https://phabricator.wikimedia.org/T298421

-- Kunal

Bug#963988: transition: zimlib and libkiwix

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

zimlib and libkiwix are ready to be upgraded to their latest upstream major
versions. Since both are maintained by the same upstream and basically in sync
with each other, I thought it would make sense to do as one transition.

I prepared/tested all of the packages in experimental and it should be good to
go. The zimwriterfs build failures are because it built against and earlier,
buggy zimlib that was missing a dependency.

Ben files:

title = "zimlib";
is_affected = .depends ~ "libzim4" | .depends ~ "libzim6";
is_good = .depends ~ "libzim6";
is_bad = .depends ~ "libzim4";

title = "libkiwix";
is_affected = .depends ~ "libkiwix3" | .depends ~ "libkiwix9";
is_good = .depends ~ "libkiwix9";
is_bad = .depends ~ "libkiwix3";



-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.125-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#930089: unblock: mediawiki/1:1.31.2-1

[Kunal Mehta]

My original mail didn't make it to the debian-release mailing list due
to the size of the debdiff, so here it is, without the attachment.

-- Kunal

On Thu, 06 Jun 2019 13:40:46 -0400 Kunal Mehta  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package mediawiki
> 
> This new upstream security release fixes the following CVEs:
> CVE-2019-12466, CVE-2019-12467, CVE-2019-12468, CVE-2019-12469,
> CVE-2019-12470, CVE-2019-12471, CVE-2019-12472, CVE-2019-12473,
> CVE-2019-12474. The bundled jQuery was also updated, fixing
> CVE-2019-11358.
> 
> The bugfix for #928716 is also included.
> 
> As done with stretch, we will be following the upstream 1.31.x releases for
> buster-security.
> 
> unblock mediawiki/1:1.31.2-1
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.1.6-300.fc30.x86_64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
> to C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

Bug#913705: transition: zimlib

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to upgrade zimlib to v4 to get up to date with upstream once again.

The only dependency affected is libkiwix, which will require a new major
upstream release as well (I've prepared and tested it locally). The new
libkiwix will also fix #913506 for the ICU transition.

https://release.debian.org/transitions/html/auto-zimlib.html looks correct
AFAIK.

Ben file:

title = "zimlib";
is_affected = .depends ~ "libzim2" | .depends ~ "libzim4";
is_good = .depends ~ "libzim4";
is_bad = .depends ~ "libzim2";

This is my first time doing a transition - please let me know if I missed
anything.

Thanks,
- -- Kunal

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.17-300.fc29.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvr1CITHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8onlOD/41NmzL33NCHSa3570H5lI1oLsCy/ed
LwwB94fKh4cTYnkEYo4lc7AjK7EUhU4plfhaWttKRPc8sYdFCWzrsOEnVhmpD5Od
WP8vE1rdggUpYlHqkDvwx75Rj5hF2Boge4kgzCQ8yk+/c8hqNupeY+hbhF1dsiEi
iln6MXL/7sSu/A5urKLDJplBe1q9YYjre8FeqALI3M/Z56CHtO0HDEaHpiWI6OKx
XkNOnDkMffyUPfiM/qo44vmaS7RwV2knHhYYnS82oBKUrz65Jpiqp5Yv2DK+cLQE
zeqMdV+yOOju5qoJhk43xI9zLRte6vgSJzmp6pCPhbCMafQOnrO5v7b5yhvM775+
ULPiiTkJ8M3ZIL/mkdP8l860pLS/kOHUtbifIZS0OIxU95QUu7FkWB7jVvfBMTqb
rBq/ElM25mruPcAh/pJ7Kar/q1BcLe/y7FPcRNsXdZbNFrPXWPPqPOwGMoCNYQ+O
h9IZLUNlH9zmrDy9utHZle92pdg/Dh95uUf8Be2MFB/b8E5/xSoa4qRkhwAda626
Agx31uq+nfX21+0GSr3jcfzNN9N4sKAoO9xF1u5pl6qkKwmwB4ebx+io/ra0w+ZM
SjyNPInMbT7hoov0zHQ+4Y1Sw5wG9cJaKH1uETqVzm5eFke/vQKm9uMIdbOtP/0X
Wv6s10m6UL6eRA==
=vkOO
-END PGP SIGNATURE-

Bug#861628: unblock: mediawiki/1:1.27.3-1

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mediawiki

1.27.3 is a security release of MediaWiki that fixes
CVE-2017-0372. It was supposed to be included in the
last release but wasn't included by upstream.

unblock mediawiki/1:1.27.3-1

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.10.11-200.fc25.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru mediawiki-1.27.2/composer.json mediawiki-1.27.3/composer.json
--- mediawiki-1.27.2/composer.json  2017-04-06 11:54:24.0 -0700
+++ mediawiki-1.27.3/composer.json  2017-04-30 12:13:55.0 -0700
@@ -51,6 +51,7 @@
"nikic/php-parser": "1.4.1",
"nmred/kafka-php": "0.1.5",
"phpunit/phpunit": "4.8.24",
+   "wikimedia/testing-access-wrapper": "~1.0",
"wikimedia/avro": "1.7.7"
},
"suggest": {
diff -Nru mediawiki-1.27.2/debian/changelog mediawiki-1.27.3/debian/changelog
--- mediawiki-1.27.2/debian/changelog   2017-04-06 14:04:24.0 -0700
+++ mediawiki-1.27.3/debian/changelog   2017-05-01 13:20:11.0 -0700
@@ -1,10 +1,17 @@
+mediawiki (1:1.27.3-1) unstable; urgency=medium
+
+  * Imported Upstream version 1.27.3 (security release), that
+actually contains the fix for CVE-2017-0372 (Closes: #861585)
+
+ -- Kunal Mehta <lego...@member.fsf.org>  Mon, 01 May 2017 13:20:11 -0700
+
 mediawiki (1:1.27.2-1) unstable; urgency=medium
 
   * Improve NEWS file (Closes: #852862, #854352)
   * Imported Upstream version 1.27.2 (security release), fixing
 CVE-2017-0363, CVE-2017-0364, CVE-2017-0365, CVE-2017-0361,
 CVE-2017-0362, CVE-2017-0368, CVE-2017-0366, CVE-2017-0370,
-CVE-2017-0369, CVE-2017-0367, CVE-2017-0372
+CVE-2017-0369, CVE-2017-0367
 
  -- Kunal Mehta <lego...@member.fsf.org>  Thu, 06 Apr 2017 14:04:24 -0700
 
diff -Nru mediawiki-1.27.2/docs/hooks.txt mediawiki-1.27.3/docs/hooks.txt
--- mediawiki-1.27.2/docs/hooks.txt 2017-04-06 11:54:24.0 -0700
+++ mediawiki-1.27.3/docs/hooks.txt 2017-04-30 12:13:55.0 -0700
@@ -212,9 +212,13 @@
# ...
function protect() {
global $wgUser;
-   if ( Hooks::run( 'ArticleProtect', array( &$this, 
&$wgUser ) ) ) {
+
+   // Avoid PHP 7.1 warning from passing $this by reference
+   $article = $this;
+
+   if ( Hooks::run( 'ArticleProtect', [ &$article, 
&$wgUser ] ) ) {
# protect the article
-   Hooks::run( 'ArticleProtectComplete', array( 
&$this, &$wgUser ) );
+   Hooks::run( 'ArticleProtectComplete', [ 
&$article, &$wgUser ] );
}
}
}
diff -Nru 
mediawiki-1.27.2/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php
 
mediawiki-1.27.3/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php
--- 
mediawiki-1.27.2/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php
   2017-04-06 11:55:03.0 -0700
+++ 
mediawiki-1.27.3/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php
   2017-04-30 12:14:30.0 -0700
@@ -263,8 +263,8 @@
}
 
// Starting line number
-   if ( isset( $args['start'] ) ) {
-   $options['linenostart'] = $args['start'];
+   if ( isset( $args['start'] ) && ctype_digit( $args['start'] ) ) 
{
+   $options['linenostart'] = (int)$args['start'];
}
 
if ( $inline ) {
diff -Nru mediawiki-1.27.2/includes/DefaultSettings.php 
mediawiki-1.27.3/includes/DefaultSettings.php
--- mediawiki-1.27.2/includes/DefaultSettings.php   2017-04-06 
11:54:29.0 -0700
+++ mediawiki-1.27.3/includes/DefaultSettings.php   2017-04-30 
12:13:55.0 -0700
@@ -75,7 +75,7 @@
  * MediaWiki version number
  * @since 1.2
  */
-$wgVersion = '1.27.2';
+$wgVersion = '1.27.3';
 
 /**
  * Name of the site. It must be changed in LocalSettings.php
diff -Nru mediawiki-1.27.2/includes/MagicWord.php 
mediawiki-1.27.3/includes/MagicWord.php
--- mediawiki-1.27.2/includes/MagicWord.php 2017-04-06 11:54:24.0 
-0700
+++ mediawiki-1.27.3/includes/MagicWord.php 2017-04-30 12:13:55.0 
-0700
@@ -525,7 +525,7 @@
$this->mFound = false;
$text = preg_replace_callback(
$this->getRegex(),
-

Bug#859754: unblock: mediawiki/1:1.27.2-1

[Kunal Mehta]

'SpecialFilepath' => __DIR__ . '/includes/specials/SpecialFilepath.php',
+   'SpecialGoToInterwiki' => __DIR__ . 
'/includes/specials/SpecialGoToInterwiki.php',
'SpecialImport' => __DIR__ . '/includes/specials/SpecialImport.php',
'SpecialJavaScriptTest' => __DIR__ . 
'/includes/specials/SpecialJavaScriptTest.php',
'SpecialLinkAccounts' => __DIR__ . 
'/includes/specials/SpecialLinkAccounts.php',
diff -Nru mediawiki-1.27.1/debian/changelog mediawiki-1.27.2/debian/changelog
--- mediawiki-1.27.1/debian/changelog   2016-09-13 04:17:42.0 -0700
+++ mediawiki-1.27.2/debian/changelog   2017-04-06 14:04:24.0 -0700
@@ -1,3 +1,13 @@
+mediawiki (1:1.27.2-1) unstable; urgency=medium
+
+  * Improve NEWS file (Closes: #852862, #854352)
+  * Imported Upstream version 1.27.2 (security release), fixing
+CVE-2017-0363, CVE-2017-0364, CVE-2017-0365, CVE-2017-0361,
+CVE-2017-0362, CVE-2017-0368, CVE-2017-0366, CVE-2017-0370,
+CVE-2017-0369, CVE-2017-0367, CVE-2017-0372
+
+ -- Kunal Mehta <lego...@member.fsf.org>  Thu, 06 Apr 2017 14:04:24 -0700
+
 mediawiki (1:1.27.1-3) unstable; urgency=medium
 
   * Ensure mediawiki depends upon the same version of mediawiki-classes
diff -Nru mediawiki-1.27.1/debian/mediawiki.NEWS 
mediawiki-1.27.2/debian/mediawiki.NEWS
--- mediawiki-1.27.1/debian/mediawiki.NEWS  2016-09-13 04:17:42.0 
-0700
+++ mediawiki-1.27.2/debian/mediawiki.NEWS  2017-03-08 22:54:53.0 
-0800
@@ -1,13 +1,27 @@
 mediawiki (1:1.27.0-1) unstable; urgency=medium
 
 MediaWiki has been updated to the 1.27 upstream release branch, which
-brings in about 6 years of upstream changes. Release notes may be found
+brings in about 4 years of upstream changes. Release notes may be found
 in /usr/share/doc/mediawiki/RELEASE-NOTES-1.27 and
 /usr/share/doc/mediawiki/changelog. Please see the "Upgrading" section
 of README.debian and /usr/share/doc/mediawiki/UPGRADE for details on
 what manual steps need to be taken to upgrade.
 
+Some highlights of new features:
+* Improvements to the appearance and performance of diffs
+* Better defaults for email notifications
+* Performance improvements in client-side JavaScript
+* Secure storage for passwords
+* Improved patrolling and anti-spam features out of the box
+* Additional language and internationalization support
+* Common extensions are bundled and can be enabled from the installer
+
 Note that the mediawiki-extensions* packages are no longer compatible
 with this version of MediaWiki, and are no longer supported.
 
+If you are upgrading from wheezy, you may encounter issues with prior
+apache2 configuration preventing the new one from being installed.
+Disabling the old one and copying over the new one from
+/etc/mediawiki/mediawiki.conf is recommended.
+
  -- Kunal Mehta <lego...@member.fsf.org>  Tue, 27 Sep 2016 12:45:06 -0700
diff -Nru mediawiki-1.27.1/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php 
mediawiki-1.27.2/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php
--- mediawiki-1.27.1/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php   
2016-08-22 13:53:17.0 -0700
+++ mediawiki-1.27.2/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php   
2017-04-06 11:54:43.0 -0700
@@ -599,7 +599,7 @@
$newLinks = $this->findLinks( $title, $newtext 
);
}
 
-   $unknownLinks = array_filter( $newLinks, [ &$this, 
'filterLink' ] );
+   $unknownLinks = array_filter( $newLinks, [ $this, 
'filterLink' ] );
$addedLinks = array_diff( $unknownLinks, $oldLinks );
$numLinks = count( $addedLinks );
 
diff -Nru mediawiki-1.27.1/extensions/ConfirmEdit/extension.json 
mediawiki-1.27.2/extensions/ConfirmEdit/extension.json
--- mediawiki-1.27.1/extensions/ConfirmEdit/extension.json  2016-08-22 
13:53:17.0 -0700
+++ mediawiki-1.27.2/extensions/ConfirmEdit/extension.json  2017-04-06 
11:54:43.0 -0700
@@ -86,6 +86,9 @@
"APIEditBeforeSave": [
"ConfirmEditHooks::confirmEditAPI"
],
+   "TitleReadWhitelist": [
+   "ConfirmEditHooks::onTitleReadWhitelist"
+   ],
"UnitTestsList": [
"ConfirmEditHooks::onUnitTestsList"
]
diff -Nru mediawiki-1.27.1/extensions/ConfirmEdit/includes/ConfirmEditHooks.php 
mediawiki-1.27.2/extensions/ConfirmEdit/includes/ConfirmEditHooks.php
--- mediawiki-1.27.1/extensions/ConfirmEdit/includes/ConfirmEditHooks.php   
2016-08-22 13:53:17.0 -0700
+++ mediawiki-1.27.2/extensions/ConfirmEdit/includes/ConfirmEditHooks.php   
2017-04-06 11:54:43.0 -0700
@@ -172,24 +172,29 @@
 * Set up $wgWhitel

Bug#828097: Possible to keep old tidy?

[Kunal Mehta]

Hi,

The upgrade of tidy to the newer version breaks what MediaWiki expects
(see test failures:
), and updating
MediaWiki to be compatible with the newer tidy isn't an option either:
.

So is it possible to keep the older version of tidy around? Preferably
also via the php-tidy library, though I'm not sure exactly how that
integration would work.

Thanks,
-- Kunal



signature.asc
Description: OpenPGP digital signature